Every attribute has a
domain. A domain determines the type of data values that are permitted for that attribute, and thus serves as an attribute constraint.
Attribute domains can be very large (long company names, for example), or very short such as the single-letter abbreviations, for example
S, M, L
can be used to indicate clothing sizes).
SQL provides a number of domain types to assign to attributes. The standard domain types include data values for characters, numerals, currency, dates, times, and Boolean entries (a logical value of either true or false).
Most RDBMSs also accept the BLOB (binary large object) domain type, which stores binary objects such as graphics.
Choosing the correct domain type is critical to the accuracy of a database.
It is important to choose the right domain type for an attribute. For example, zip codes appear as numbers to us, so there is the temptation to attach the numerical domain to them.
However, zip codes in the northeastern section of the United States begin with a zero. This would pose problems in a database since the numerical domain drops leading zeros.
Do not think of time periods, such as “1st Quarter Profits,” “2nd Quarter Profits,” as distinct entities.
Instead, create an entity called 'Profits' and use attributes with the date domain to distinguish time periods.
The RDBMS uses
domain constraints[1] to enforce attribute domains. When a user enters a data value, the RDBMS checks to verify that the domain assigned to that attribute permits that value.
For example, if a user entered letters into a field with a currency domain, that data entry would be rejected. Likewise, a domain that accepted only dates would reject non-date entries. Additionally, most RDBMSs reject impossible dates, such as February 30th.
The next lesson explains the problem with multi-valued attributes.
[1] domain constraints: Rules that require values of attributes to come from specific domains (e.g., text, numbers, date, etc.).
