Examples
We will now revisit each of our figures and add an English description to each one. First, reconsider Figure 2.3. There are no multi-valued or
composite attributes. Entity = STUDENT, att(1) = name, att(2) = school, etc. (j assigned arbitrarily). The English "translation" of the entity diagram using the above templates would be:
The Entity
This database records data about STUDENTS. For each STUDENT in the database, we record a name, a school, an address, a phone number, and a major.
The Attributes
For each name, there always will be one and only one name for each STUDENT. The value for name will not be subdivided.
For each major, there always will be one and only one major for each STUDENT. The value for major will not be subdivided. (Note that in Figure 2.3 we did not divide name.)
For each address, there always will be one and only one address for each STUDENT. The value for address will not be subdivided.
For each school, there always will be one and only one school for each STUDENT. The value for school will not be
subdivided.
For each phone number, there always will be one and only one phone number for each STUDENT. The value for phone number will not be subdivided.
The Keys
For each STUDENT, we do not assume that any attribute will be unique enough to identify individual entities. (Remember that we are describing Figure 2.3.)
Sample Data
In addition to the above descriptions, some sample data is often very helpful in showing the user what you have proposed:
STUDENT
Now consider Figure 2.4. This figure has a composite attribute — name. The English "translation" of this entity diagram would be as follows:
The Entity
This database records data about STUDENTS. For each STUDENT in the database, we record a name, a school, and an address.
The Attributes
For each name, there always will be one and only one name for each STUDENT. The value for name will be subdivided into a first name, a last name, and a middle initial.
For each address, there always will be one and only one address for each STUDENT. The value for address will not be subdivided.
For each school, there will be one and only one school for each STUDENT. The value of the school will not be subdivided.
The Keys
For each STUDENT, we do not assume that any attribute will be unique enough to identify individual entities.
Sample Data
Next consider Figure 2.5. This figure has a composite as well as a multi- valued attribute. The English "translation" of this entity diagram would be as
Smith Cosc 123 4th St St. Helens 222–2222 Jones Acct 222 2nd St PS 123 333–3333 Saha Eng 284 3rd St Canton 345–3546 Kapoor Math 20 Living Cr High 435–4534
STUDENT
name.first name.last name.mi school address
Richard Earp W U. Alabama 222 2nd St
Boris Backer Heidleburg 333
Dreistrasse Helga Hogan H U. Hoover 88 Half Moon
Ave Arpan Bagui K Northern
School
33 Bloom Ave
Hema Malini South Bend 100 Livingstone
follows:
The Entity
This database records data about STUDENTS. For each STUDENT in the database, we record a name, a school, and an address.
The Attributes
For each name, there always will be one and only one name for each STUDENT. The value for name will be subdivided into a first name, a last name, and a middle initial.
For each address, there always will be one and only one address for each STUDENT. The value for address will not be subdivided.
For each STUDENT, we will record schools. There may be more than one school recorded for each student.
The Keys
For each STUDENT, we do not assume that any attribute will be unique enough to identify individual entities.
Sample Data
Consider Figure 2.6. This figure has a composite, multi-valued, as well as key attribute. The English "translation" of this entity diagram would be as follows:
The Entity
This database records data about STUDENTS. For each STUDENT in the database, we record a name, schools, an address, and a student number.
The Attributes
STUDENT
name.first name.last name.mi school address
Richard Earp W U. Alabama, Mountain
222 2nd St
Boris Backer Heidleburg, Volcano
333 Dreistrasse Helga Hogan H U. Hoover, St.
Helens
88 Half Moon Ave Arpan Bagui K Northern
School
33 Bloom Ave Hema Malini South Bend 100
For each name, there always will be one and only one name for each STUDENT. The value for name will be subdivided into a first name, a last name, and a middle initial.
For each address, there always will be one and only one address for each STUDENT. The value for address will not be subdivided.
For each STUDENT, we will record schools. There may be more than one school recorded for each student.
The Keys
For each STUDENT, we will assume that there is an attribute — student number — that will be unique enough to identify individual entities.
Finally, consider Figure 2.7 (top). This figure shows a strong entity. We will combine the grammar a little to keep the methodology from being overly repetitive. The English "translation" of this entity diagram would be as follows:
The Entity
This database records data about AUTOMOBILEs. For each AUTOMOBILE in the database, we record a make, body style, year, color, and vehicle-id.
The Attributes
Each AUTOMOBILE will have one and only one make, body style, year, color, and vehicle-id. None of these attributes will be subdivided.
The Keys
For each AUTOMOBILE, we assume that attribute vehicle-id will be unique enough to identify individual entities.
Figure 2.7 (bottom) shows a weak entity. The only difference between the strong and weak entity description involves the key phrase, which may not exist in the weak entity.
Figure 2.8 shows a relationship between two entities, an AUTOMOBILE and a STUDENT. The concept of relationships is discussed in more detail in
Figure 2.8: An ER Diagram of the STUDENT-AUTOMOBILE
Database
ER Design Methodology
Step 1: Select one primary entity from the database requirements description and show attributes to be recorded for that entity. Label key if appropriate.
Step 2: Use structured English for entities, attributes, and keys to describe the database that has been elicited.