Chapter 5
Data Modeling with the E-R Model
General strategies
To build a database and related applications, the development team must become
thoroughly familiar with the users' model.
Before you can create a database, you must have an accurate model of the users' view of
their data.
This is the most important step in developing an effective database!!!
Data modeling is the basis for all subsequent work in the development of databases and
their applications. One of the tools for data modeling is something called the entityrelationship model.
All that the entity-relationship model (E-R model) is, is a tool for helping you describe the
users' data model. It is a tool, just like flow-charts and pseudo-code are tools used in
programming.
The key elements in the E-R model are entities, attributes, identifiers, and
relationships.
ENTITY: "An entity is something that can be identified in the users' work environment,
something that the users want to track." (Kroenke) Basically, it's a noun (object) that has
information attached to it.
ENTITY CLASS: An entity class is a collection of entities (a table).
ENTITY INSTANCE: An instance of an entity is a particular item in the class (a row in the
table).
2/8/2016
Document1
Page 1 of 6
ATTRIBUTE: an attribute of an entity is a property that describes the entity's
characteristics (a field or column).
One way to draw an entity's attributes:
A cleaner way to draw an entity's attributes:
IDENTIFIERS: An identifier is an attribute that identifies an entity. Examples are Social
Security number, student ID number, part number, name, etc. May or not be unique (name
in the previous list is probably NOT unique, but the other 3 identifiers probably are).
COMPOSITE IDENTIFIER: A composite identifier is an identifier that consists of two or
more attributes. For example, last name and first name.
2/8/2016
Document1
Page 2 of 6
RELATIONSHIP: an association between two entities.
BINARY RELATIONSHIP: a relationship between exactly two entities or tables.
The author talks about "ternary relationships" but we will ignore these.
2/8/2016
Document1
Page 3 of 6
TYPES OF BINARY RELATIONSHIPS
One-to-one.
Consider the relationship between an employee and a badge. A single entry of one type is
related to a single entry of another type. This is called a one-to-one relationship and is
denoted by 1:1. No employee has more than one badge, and no badge has more than one
employee assigned to it.
Crow's foot model ("Information Engineering", or "IE" model):
Another example of a one-to-one relationship is FacultyID and FacultyName. (There is an
assumption here that no two faculty members will have the same name.)
Attributes that have a one-to-one relationship must exist together in at least one relation in
order to establish their equivalence.
However, it is generally undesirable to have them occur together in more than one relation
because this causes needless data duplication.
When a one-to-one relationship occurs, one of the two attributes (fields) should be chosen
to represent the pair in all other relations (tables). This will almost always be the value that
is numeric, or if not numeric, a short string. In the examples above, we would choose Badge
Number to represent the employee, and FacultyID to represent the faculty member.
Although it would be possible to use FacultyID as an identifier in some tables and
FacultyName as an identifier in others, this is considered a bad practice. It is inconsistent
and confusing. Pick one of the fields and use it consistently throughout the database.
2/8/2016
Document1
Page 4 of 6
One-to-many.
Example 1
Consider the relationship between a dormitory and the students who live in the dormitory. A
single instance of a dormitory will be related to many instances of students, but a student
will be related to only one dormitory. This is called a one-to-many relationship and is
denoted by 1:N. A crow's foot is used to indicate the many side.
Crow's foot model:
This is expressed as Student  Dormitory
Example 2
Another example of a one-to-many relationship is that of advisors to students. There will be
many students for a single advisor. Given a student, we can find the advisor, but given an
advisor, we cannot determine a specific student.
This is expressed as Student  Advisor
Since Student determines Advisor, the only other attributes (fields) that you can add to the
Student relation (table) are attributes that are determined by SID.
In general terms, "if A determines B, the only other attributes you can add to the relation
must also be determined by A."
2/8/2016
Document1
Page 5 of 6
Many-to-many.
Example 1
Consider the relationship between students and clubs. A student can belong to more than
one club, and a club can have more than one student as a member. This is called a manyto-many relationship and is denoted by N:M.
Crow's foot model:
The "O" and the "|" indicate "optional" and "mandatory". Below, this means that a student
does not have to belong to a club, but a club must have at least one student.
NOTATION: I like to think of the "O" as the number 0 and the | as the number 1.
So the above diagram says that "a club can have 1, or more students (referring to the
marks on the student side)" and "a student can belong to 0 or more clubs (referring to the
marks on the club side)."
Example 2
Another example of a many-to-many relationship is the relationship of professors to classes
taught. In the example below, the "|" means that a class must have at least one professor,
but a professor does not necessarily have to have any classes (e.g. if he is on sabbatical, or
only does research).
In a many-to-many relationship, both attributes must be a key of the relation. All other
attributes of the relation must be functionally dependent on the entire key. If an attribute is
not dependent on the entire key, it does not belong in the relation.
MySQL Workbench
MySQL Workbench is a tool for creating ER diagrams.
2/8/2016
Document1
Page 6 of 6