Database Reference
In-Depth Information
and combining some of the attributes, entities, and relationships within the model into more
generic terms.
The general question that needs to be asked is:
“Are there any entities, relationships, or data elements that should be made more generic to
accommodate future requirements?”
For example, we can take our normalized data model from the prior section and abstract
Employee
into
Party
and
Role
to get this model:
Where did our employees go? They are now a particular role that a
Party
can play. Party
can be any person (and usually also any organization, but in this example, only person),
and a person can play many roles such as employee, tennis player, or student. Which model
do you like better, the 3NF model we built or this abstract model? Most of us like the 3NF
model better because the abstract model has several disadvantages:
•
Loss of communication
. The concepts we abstract are no longer represented ex-
plicitly on the model. That is, when we abstract, we often convert column names
to entity instances. For example,
Employee is no longer an explicit entity
, but is,
instead, an entity instance of
Party Role
, with a Role Type Code value of
03
for
Employee
. One of the main reasons we model is for communication, and abstract-
ing can definitely hinder communication.
