Database Reference
In-Depth Information
same data, or nearly the same type. Later we talk more about the difficulty
surrounding payments.
Last but not least, we need to determine the relationships that exist be-
tween our entities. Once more, we need to go through the statement to
look for ownership or action key words as they relate to entities. This time,
we create a list that describes the relationship in a natural language (in our
case, English), and later we translate it to an actual modeling relationship.
This step can be a bit trickier than determining entities and attributes, and
you have to do a little inferring to find all the detail about the relationships.
The following list shows all the relationships we can infer from the data; in
each case the suspected parent of the relationship is shown in italics.
Customers
place Orders
■
Employees
place Orders
■
Orders
contain Order Details
■
Order Details have some quantity of
Products
■
Orders
contain Payments
■
Once we have the initial list, we can translate these relationships into
modeling terms. Then we will be ready to put together a high-level
entity
relationship diagram
(ERD). Much of the data you need is right here in
the CEO's statement, but you may have to go back and ask some clarifying
questions to get everything correct.
Let's look at the first relationship: Customers place Orders. In this
case, the Customer and the Order entity are related, because Mountain
View Music's customers place orders via the Web or the phone. We can as-
sume that customers are allowed to have multiple orders and that each
order was placed by a single customer. This means that there exists a one-
to-many relationship between the Customer and Order entities.
Using this same logic, we can establish our relationship list using mod-
eling terms. The relationships as they exist so far are shown in the follow-
ing list:
Customer-1:M-Order
■
Employee-0:M-Order
■
Order-1:M-Order Detail
■
Products-1:M-Order Detail
■
Payments-1:M-Order
■
Search WWH ::
Custom Search