Page 214 -

213
Q5-5 How Are Data Models Used for Database Development?

the Unified Modeling Language (UML). We will not describe that tool here. However, if you learn
how to interpret E-R models, with a bit of study you will be able to understand UML models as well.
Entities

An entity is some thing that the users want to track. Examples of entities are Order, Customer,
Salesperson, and Item. Some entities represent a physical object, such as Item or Salesperson; others
represent a logical construct or transaction, such as Order or Contract. For reasons beyond this dis-
cussion, entity names are always singular. We use Order, not Orders; Salesperson, not Salespersons.
Entities have attributes that describe characteristics of the entity. Example attributes of Order
are OrderNumber, OrderDate, SubTotal, Tax, Total, and so forth. Example attributes of Salesperson are
SalespersonName, Email, Phone, and so forth.
Entities have an identifier, which is an attribute (or group of attributes) whose value is associ-
ated with one and only one entity instance. For example, OrderNumber is an identifier of Order because
only one Order instance has a given value of OrderNumber. For the same reason, CustomerNumber is
an identifier of Customer. If each member of the sales staff has a unique name, then SalespersonName
is an identifier of Salesperson.
Before we continue, consider that last sentence. Is the salesperson’s name unique among
the sales staff? Both now and in the future? Who decides the answer to such a question? Only the
users know whether this is true; the database developers cannot know. This example underlines
why it is important for you to be able to interpret data models because only users like you will
know for sure.
Figure 5-18 shows examples of entities for the Student database. Each entity is shown in a
rectangle. The name of the entity is just above the rectangle, and the identifier is shown in a section
at the top of the entity. Entity attributes are shown in the remainder of the rectangle. In Figure 5-18,
the Adviser entity has an identifier called AdviserName and the attributes Phone, CampusAddress, and
EmailAddress.
Observe that the entities Email and Office_Visit do not have an identifier. Unlike Student or
Adviser, the users do not have an attribute that identifies a particular email. We could make one
up. For example, we could say that the identifier of Email is EmailNumber, but if we do so we
are not modeling how the users view their world. Instead, we are forcing something onto the
users. Be aware of this possibility when you review data models about your business. Do not
allow the database developers to create something in the data model that is not part of your
business world.

Relationships
Entities have relationships to each other. An Order, for example, has a relationship to a Customer
entity and also to a Salesperson entity. In the Student database, a Student has a relationship to an
Adviser, and an Adviser has a relationship to a Department.

Student Department
StudentNumber DeptName
StudentName Admin
HW1 Email Phone
HW2 Email
MidTerm
Date
Adviser Message Office_Visit
AdviserName
Phone Date
CampusAddress Notes
Figure 5-18 EmailAddress
Student Data Model Entities