Describe Attribute Domains

In database design, the statement "each attribute of an entity contains a domain" means that every attribute (or column) in an entity (or table) must have a defined set of possible values that it can hold. This set of values is referred to as the domain of the attribute.
Key Concepts:

1. Entity: In database modeling, an entity represents a real-world object or concept, such as a Customer, Employee, Product, etc.
2. Attribute: Attributes define the properties or characteristics of an entity. For example, an entity Customer may have attributes like CustomerID, Name, Email, and PhoneNumber.
3. Domain: The domain of an attribute specifies the allowed set of values for that attribute, including:
   • Data Type: Integer, String, Date, Boolean, etc.
   • Constraints: Length restrictions, unique values, allowed ranges.
   • Business Rules: A phone number must follow a specific format, a percentage must be between 0 and 100, etc.

Example: Consider an Employee entity with the following attributes:

Attribute	Domain
EmployeeID	Integer (positive, unique)
Name	String (1-100 characters)
Age	Integer (18-65)
Salary	Decimal (greater than 0)
Email	String (valid email format)

In this case:

• EmployeeID has a domain restricting it to positive unique integers.
• Age has a domain restricting it to values between 18 and 65.
• Email has a domain ensuring it follows a valid email format.

Why is Defining a Domain Important?

1. Data Integrity: Ensures only valid data is stored.
2. Data Consistency: Prevents inconsistent or out-of-range values.
3. Optimization: Helps the database optimize storage and indexing.
4. Validation and Constraints: Helps define Primary Keys, Foreign Keys, Unique Constraints, and Check Constraints.

---

• Definition: In database design, the domain of an attribute is the set of all possible values that the attribute can take. It's essentially the data type combined with any constraints or rules that govern what values are valid for that attribute.
• Purpose:
  • Data Integrity: By defining a domain for each attribute, you ensure that only valid data can be entered into that field. This helps maintain data integrity across the database.
  • Consistency: Ensures that all instances of data for a given attribute are of the same type and meet the same criteria, promoting consistency in data handling and interpretation.
  • Error Prevention: Reduces data entry errors since the database can enforce these constraints at the input level.
• Examples of Domains:
  • Numeric Domain: For an attribute like Age, the domain might be defined as positive integers between 0 and 120.
  • String Domain: For Email, the domain could include string values that must conform to an email format regex.
  • Date Domain: For BirthDate, the domain would be all valid date values within a reasonable range.
• Implementation:
  • Data Types: At the most basic level, the domain is reflected by the data type (e.g., INT, VARCHAR, DATE in SQL).
  • Constraints: Further refinement comes through constraints like:
    • Check Constraints: To limit the range or type of data (e.g., CHECK (Age >= 0 AND Age <= 120)).
    • Foreign Key Constraints: To ensure referential integrity, which can also be seen as defining a domain relative to another table's primary key.
    • User-Defined Types: Some databases allow for custom types to be defined, which encapsulate domain logic.
• Domain in ER Model:
  • When designing an Entity-Relationship (ER) diagram, while attributes are commonly drawn with their names, the domain is an implicit part of the attribute definition. In some advanced ER tools or notations, domains might be explicitly noted or linked to attribute definitions.
• Domain Evolution:
  • Over time, as business rules change or as the database evolves, the domain of an attribute might need to be redefined or expanded, which can involve altering constraints or even database schemas.

Conclusion In summary, each attribute in a database entity is associated with a domain that defines its allowed values and constraints, ensuring structured, reliable, and meaningful data storage in relational database design. Understanding and defining domains correctly from the outset of database design is crucial for ensuring that the database not only stores data efficiently but also maintains the integrity and validity of the data over time.

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

1. characters,
2. numerals,
3. currency,
4. dates,
5. times, and
6. 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.

• Enforcing Domains:
  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.

Before moving on to the next lesson, click the Exercise link below to test your understanding of domains.
Attribute Domains Database - Exercise

[1] domain constraints: Rules that require values of attributes to come from specific domains (e.g., text, numbers, date, etc.).