Database Reference
In-Depth Information
Vehicle table contains the Employee Number of the employee who has been
assigned any given Vehicle. The actual attributes in the referencing entity
can be either a key or a non-key attribute. That is, the FK in the referencing
entity could be composed of the same attributes as its PK, or they could be
a completely different set of attributes. This combination of PKs and FKs
helps ensure consistency in the logical relationships between entities.
Domains
As you begin building a model, you'll likely notice that, within the context
of the data you are working with, several entities share similar attributes.
Often, application- or business-specific pieces of data must remain identi-
cal in all entities to ensure consistency. Status, Address, Phone Number,
and Email are all examples of attributes that are likely to be identical in
multiple entities. Rather than painstakingly create and maintain these at-
tributes in each individual entity, you can use domains.
A
domain
is a definition of an attribute that is maintained as part of
the logical model but outside a given entity. Whenever an attribute that is
part of a domain is used, that domain is added to the entity. Generally, a
data model does not provide a visual indication that a given attribute is ac-
tually part of a domain. Most data modeling tools provide a separate sec-
tion or document, such as a
data dictionary,
to store domain information.
Whenever there are changes to that domain, the related attributes in all
entities are updated, as is the documentation that stores the domain
information.
For example, consider the Phone Number attribute. Often, logical
models are designed with localized phone numbers in mind; in the United
States, this is generally notated with a three-digit area code, followed by a
three-digit prefix, followed by a four-digit suffix (XXX-XXX-XXXX). If later
in the design you decide to store international numbers as well, and if a
phone number attribute has been added to multiple entities, it may be nec-
essary to edit every entity to update the attribute. But if instead you create
a Phone Number domain and add it to every entity that stores phone num-
bers, then updating the Phone Number domain to the new international
format will update every entity in the model.
Thus, to reduce the chance that identical attributes will vary from en-
tity to entity in a logical design, it's a good idea to use domains whenever
possible. This practice will help enforce consistency and save design time,
not only during the initial rollout but also throughout the lifetime of the
database.
Search WWH ::
Custom Search