I’m currently in the process of learning (Relational) Database Design based on two popular books, online tutorials and articles.
Some places, when they talk about attributes constraints, they call it an Attribute Domain.
Some other places, when they talk about attribute specification, they call it a Field specification.
However, some other places, they say that they are both the same, but attribute domain seems to me to be part of the field specifications since by definition, attribute domain sounds like the Physical Element part of field specification:
Physical elements: Data type, Length, Decimal Places, Character support, input mask, display format
What is it now?
Attribute domain defines the range of acceptable values for an attribute at the logical model level, e.g. “an arbitrary string representing a person’s name”, “a non-negative integer”, “a boolean (true or false) value” etc.
Column specification defines SQL properties of a database column that is used to store the corresponding attribute values in an SQL database (i.e. at the physical model level). Sometimes they are more restrictive than the attribute specification, e.g. you must specify the maximum length of a character column, although the attribute domain may not prescribe it). Sometimes they are less restrictive, for example you cannot represent a “non-negative integer” by an SQL
INTEGER data type without additional constraints. Some column specifications, such as input mask or display format, have nothing at all to do with the domain specification and exist solely as technical implementation details of the application in question.
I prefer not to use the term “field” when discussing relational databases. Relational tables have rows and columns. Using “fields” and “columns” interchangeably often brings confusion. Input elements of a user interface or components of a sequential file records can be referred to as “fields”.