Chapter Two
Overview
Introduction
Entity & Entity Class
Attributes
Unique Identifier
Relationships
Example Caribbean Air Travel
Example Credit Card
Naming a Relationship
Introduction
The Systems Analyst uses education, experience, his own judgement and proven
methodologies to make sense of and to model organization behavior. He may then go on
to represent such behavior/activity/event/structure in data. He may use DFDs to create a
model of the activities (processes) taking place in an organization. This includes
identifying the information that flows in the organization, where it flows to and from, and
where it is stored. Despite the nomenclature, the DFD does not focus on the details of
data, so these data stores are not well defined in the DFD. To create models which
would provide a picture of data stores we have to turn to Entity Relationship Modeling.
Terrence Brunton
20
Chapter Two
In the 1970s there were several competing data modeling tools; the file system model, the
hierarchical model (IBMS IMS database system), and the Network model (CODASYL,
Honeywells IDS database system) developed by Charles Bachman. In 1970, the
relational model was introduced by E.F. Codd. In 1976, Peter Chen introduced EntityRelationship Modeling, which was a unifying methodology for file and database design
(ACM Transactions on Database Systems, March, 1976).
Entity-Relationship Modeling allows us to define the requirements for data storage. It
involves identifying the significant things or ENTITIES in an organization, the relevant
properties or ATTRIBUTES of those things, and the RELATIONSHIPS between the
ENTITIES.
Let us look more closely at these ENTITIES, ATTRIBUTES and RELATIONSHIPS.
Entity
A data entity is anything real or abstract about which we want to store data. Entity
types fall into five classes: roles, events, locations, tangible things or concepts.
E.g. employee, payment, campus, book. Specific examples of an entity are called
instances. E.g. the employee John Jones, Mary Smith's payment, etc.
Attribute
A data attribute is a characteristic common to all or most instances of a particular
entity. Synonyms include property, data element, field. E.g. Name, address,
Employee Number, pay rate are all attributes of the entity employee. An attribute
or combination of attributes that uniquely identifies one and only one instance of
an entity is called an identifier. E.g. Employee Number is a primary key for
Employee.
Relationship
A data relationship is a natural association that exists between one or more
entities. E.g. Employees process payments. Cardinality defines the number of
occurrences of one entity for a single occurrence of the related entity. E.g. an
employee may process many payments but might not process any payments
depending on the nature of her job.
Terrence Brunton
21
Chapter Two
The box may be of any size or shape. The analyst (you) gets to choose the size and
shape. By stretching or shrinking the box, you find an appropriate size, large enough to
hold any text you wish to enclose, and small enough to fit enough boxes on one page to
represent the system you wish to depict. You must also allow enough size to connect
relationship lines to the box.
The analyst, through a study of the organization, discovers and identifies the things which
populate the organization space. These things are then classified by putting them in
boxes and giving the boxes names. So that the entity name (the name in the box), is the
name for a class of thing, not a single occurrence of the thing. So that the entity
AIRPORT, represents a class of thing we call airport, and consists of one or more things
such as Piarco, Vigie, and Vere Bird, each of which is an occurrence of the entity
AIRPORT.
AIRPORT
e.g. Piarco
Vigie
Vere Bird
Attributes
You would have considered attributes earlier when searching for entities. The
characteristics of entities, the things that draw them to your attention, are their attributes.
For instance if we are talking about air travel, the first thing that you will probably notice
on the ticket is the name of the passenger, then the destination, the date and the flight
Terrence Brunton
22
Chapter Two
information. These are the attributes of ticket, or more specifically, as we shall soon see
in the example, coupon. Formally stated, an attribute is any detail that serves to qualify,
identify, classify, quantify or express the state of an entity, or provide a description of a
thing of significance.
An attribute could be text, or numbers. It may also be a picture, as provided for in
Microsoft Access database management software. Less obviously, it may be a feel, a
smell, or some other intangible. For data processing purposes, we tend to concentrate on
text and numbers, but other attribute types could be represented, particularly in the
emerging area of multimedia.
An ellipse is used in the ERD to represent attributes. The ellipse is connected to the
entity using a line. The attributes name, a noun, is written within the ellipse. (In MS
Word, the ellipse shape with a text box inside). This style of notation is used here since it
is the simplest type that most clearly identifies the attributes. Later we will discard this
style in favour of a more compact style.
time issued
BOARDING PASS
date issued
Terrence Brunton
23
Chapter Two
A Composite Attribute consists of other attributes and connects to its constituents using a
solid line:
street
STUDENT
address
city
phone#
state
A Multi-Valued Attribute is one that may have multiple values. It connects to the entity
using a double line:
PERSON
degrees
NOTE: After Normalization, an entity may have only one value for an attribute at any
time. Repeated attributes must be removed from the entity. This is the first rule of
normalization, the removal of repeating attributes. We will look at Normalization more
closely later on.
A Derived Attribute is one whose value may be calculated (derived) from other attributes.
Since it can be derived, there is no need to store it. It connects to the entity using a
dashed line.
ORDER
total cost
Terrence Brunton
24
Chapter Two
An attribute name must be in the singular. If, when naming, it appears that the attribute
should be plural, this is an indication that missing entities with their own attributes may
be hiding here. An attribute can become an entity when it is a thing of significance,
which has its own attributes and relationships.
Unique Identifier
Each unique instance of an entity must be uniquely identifiable by a combination of
attribute(s) and/or relationships (key). You must seek out candidate attributes that may
uniquely identify an entity. Student ID, invoice number, etc. are good candidate
attributes that would uniquely identify the entities STUDENT and INVOICE. The
attribute, which serves as a unique identifier, is underlined.
STUDENT
student ID
INVOICE
invoice #
TIPS:
Type and Instance
Terrence Brunton
25
Chapter Two
* Arrange your diagram so the entity boxes line up and relationship lines are
mainly straight and horizontal or vertical. Minimize crossing lines. When relationship
lines must cross, try to reduce clutter and use diagonal lines. Avoid using many closely
parallel lines. These are often difficult to follow. Use plenty of white space to reduce
clutter and facilitate understanding.
* Add a title and date and identify the author(s) of each diagram.
* Ensure that all the text is unambiguous. Avoid abbreviations and jargon. Use
the reading conventions described and read all around the diagram to ensure it is
complete and accurate. A good Entity Relationship Diagram should be semantically
complete. Add adjectives and examples when reading it, if necessary, to improve
understanding and accuracy.
* Most of the text should be horizontally aligned to make it easier to read. You
may use more than one line for a name to ease layout problems. If necessary write the
relationship names along the lines, but normally you should put the names at the ends of
the line and on opposite sides of the line.
* There is no special significance given to the size or shape of an entity. Boxes
may be stretched, enlarged or shrunk to help the layout of the diagram. If using
Microsoft Word, you should use the group function on the Drawing toolbar to tie all the
objects in your diagram together. This will save formatting headaches later.
Relationships
We find the entities and name them, having classified examples of the things which
comprise the entity. We then look for associations between entities. These entities may
be associated with one another or with themselves. We call such associations
relationships. So we may say that an entity EMPLOYEE has a relationship with
another entity COMPUTER.
A relationship is an association between entities that the analyst selects and names. It is
represented as a solid named line on the ERD interacting with, and thus connected to, one
or more entities using a solid line. Connections to two entities are described as Binary,
connections to itself are described as Unary, and connections with three entities are
described as Ternary.
The Binary relationship is the most commonly used type of relationship:
PROFESSOR
Terrence Brunton
teaches
CLASS
26
Chapter Two
Less common is the Unary relationship, that shows an entity related to itself. It is
typically used to describe hierarchical type relationships:
EMPLOYEE
manages
A Ternary relationship includes three entities in the relationship. It is used for more
complex relationships and is best illustrated with a shipping example as shown:
SUPPLIERS
ship
JOBS
PARTS
The cardinality of Relationships is the term given to the number of entity instances
involved in a relationship. It may be:
1:1 (One-to-One)
Terrence Brunton
27
Chapter Two
1:N (One-to-Many)
N:1 (Many-to-One)
N:M (Many-to-Many)
Example of 1:1:
A Professor teaches MANY Classes.
A Class is taught by ONE and only one Professor.
PROFESSOR
teaches
CLASS
Example of M:N:
A Student enrolls in MANY classes.
A Class contains MANY Students.
STUDENT
Meeting
Times
Grade
Last Name
CLASS
enrolls
Student ID
Terrence Brunton
Class Room #
28
Chapter Two
Many to Many (N:M) Relationships must be transformed into two separate One to Many
(1:N) Relationships. To do this a Composite Entity is created. It is represented by a new
entity box.
Last Name
STUDENT
Meeting
Times
Grade
ENROLLMENT
Student ID
CLASS
Class Room #
Student ID
Terrence Brunton
Class Room #
29
Chapter Two
Airline: .Origin/Destination: .
Airline: ..Origin/Destination: MIA/P.O.S..
Airline:.Origin/Destination: P.O.S./MIA
Passenger: . Date of Issue: ..
Passenger Ticket and Baggage Check
[IATA]
The ticket consists of a cover, two coupons, and a copy. The coupons refer to specific
legs of the journey, such as, one from POS to Miami and the other from Miami to POS.
The third sheet is the copy which is retained and which shows the entire round trip
journey.
*This example is adapted from Barker, Case Method Entity Relationship Modeling (1990) (the notation is
different from that shown earlier). The notation which we now introduce and will use subsequently is
called the crows-foot notation.
Terrence Brunton
30
Chapter Two
COUPON
*class
*status
on
made up of
TICKET
*date of issue
*fare
Each COUPON must be on one and only one TICKET and each TICKET
must be made up of one or more COUPONs.
Terrence Brunton
31
Chapter Two
Let us look at the ERD of the relationship between the TICKET and the FLIGHT.
COUPON
FLIGHT
for
the subject of
*class
*date of departure
*time of departure
*status
on
TICKET
made
up of
*date of issue
*fare
Terrence Brunton
32
Chapter Two
Each TICKET must be made up of one or more COUPONs, each of which is for a
different FLIGHT, and conversely, each FLIGHT may be the subject of one or more
COUPONs, each of which must be on a different TICKET.
Other useful information is shown by the words inside the boxes. These attributes
provide a more detailed description of the entities. This can be read as follows:
****
COUPON
TICKET
on
made
up
of
*class
*status
*confirmed
indicator
*comment
*date of issue
*fare
*currency
PASSENGER
for
shown on
*title
*surname
*initial
FLIGHT
for
the
subject
of
*date of departure
*time of departure
of
scheduled as
AIRLINE
AIRLINE
ROUTE
the source of
from
operated by
*code
*name
the
carrier
for
*flight number
*scheduled
departure time
to
AIRPORT
*code
*name
the destination of
33
Chapter Two
CONDITION
CREDIT
CARD
CARD TYPE
PERSON
ACCOUNT
COMPANY
Naming a Relationship
Terrence Brunton
34
ENTITY A
Chapter Two
ENTITY B
end-name-1
end-name-2
The name for each end of the relationship is placed near the appropriate end in lower case
as shown above.
To read any relationship simply but definitively, the following syntax is used:
must be
Each (and every) ENTITY A
end-name-1
may be
And conversely:
must be
Each (and every) ENTITY B
end-name-1
may be
Terrence Brunton
35
Chapter Two
Overview
This section discusses the following topics with respect to Entity Relationship Diagrams
Definition and Use
(ERDs):
Tables
Relationships
ERD for Pubs Database
ERD for Northwind Database
Tables
Tables (a.k.a. entities or relations) are drawn as boxes
Columns ( a.k.a. fields or attributes) are listed as rows by name inside the table
box
Keys are usually annotated as PK - primary key; FK - foreign key; and AK alternative key (an AK is a column that meets the requirements of a PK but is not
designated as such; it is a good candidate for sorts and indexes)
Terrence Brunton
36
Chapter Two
The SQL Server diagram tool does not follow this convention; instead, the
primary key column(s) is designated with a 'key' icon to the left as shown below:
Within the SQL Server diagram tool, you can right-click on the table name bar
and choose 'Column Properties' to display detail for each column (data type,
nullability, etc.); there are also other display options available
Relationships
Terrence Brunton
37
o
o
o
Chapter Two
Terrence Brunton
38
Chapter Two
Terrence Brunton
39
Chapter Two
Relationships
Terrence Brunton
40
Chapter Two
Overview
This section discusses the following topics with respect to relationships:
Basic Characteristics
Implementing Relationships in a Database
One-to-Many Relationships
One-to-One Relationships
Recursive Relationships
Terrence Brunton
41
Chapter Two
The cardinality of a relationship defines how many instances of each entity relate
to each other.
There are three primary types of cardinality: one-to-one; one-to-many; and manyto-many.
A recursive or reflexive relationship is a relationship within a single table; i.e.,
the same table acts as both the child and parent.
The relationships among tables (entities) are shown graphically in an Entity
Relationship Diagram (ERD).
Implementing Relationships
One-to-Many (1-N)
Terrence Brunton
42
Chapter Two
Many-to-Many (N-N)
In the classic 'Order Entry' database example, the junction table is referred to as
the 'order detail' table; it implements the many-to-many relationship between 'orders'
and 'parts'.
The 'order detail' table contains an 'order_ ID' column that functions as a FK and
relates it to the 'orders' table; the result is a one-to-many relationship between 'orders'
and 'order details'.
The 'order detail' table also contains a 'part_ ID' column that functions as a FK
and relates it to the 'parts' table; the result is a one-to-many relationship between
'parts' and 'order details'.
Terrence Brunton
43
Chapter Two
Within the 'order detail' table, the 'order_ ID' and the 'part_ ID' together are
defined as a composite primary key.
Taken all together, the two one-to-many relationships (orders->order_detail and
parts->order_ detail) constitute a many-to-many relationship between 'orders' and
'parts'.
One-to-One (1-1)
In the illustration above, the 'publishers' table is split into two pieces; one to hold
the smaller, more commonly accessed fields and another to hold the less frequently
requested data fields that include large data types (the 'logo' field is an image data
type and the 'pr_info' field is a text data type).
Recursive Relationship
Terrence Brunton
44
Chapter Two
to prepare a report that lists employees and their managers by their names, a self-join
is required..
In this situation, the 'reports to' column is typically made a FK that references the
PK 'employee ID' field.
The above was adapted from a website by David R. Frick & Co., CPA (http://www.frickcpa.com)
EXAMPLE TWO
TOYOTA TRINIDAD AND TOBAGO LIMITED
BACKGROUND
Toyota Trinidad and Tobago Limited (TTTL) business type is classified as an automotive
dealership. TTTL. specializes in providing sales and services of their vehicles that are of
high quality, safe, reliable and durable. Thus, they offer a range of vehicles to meet the
needs of their customers, from the adventurous to the business type.
To support its sales and services, TTTL puts its customers at the center of everything it
does by delivering custom made vehicles to the buyers specifications and providing
quality service in the timeliest manner. Hence, the company has developed a vast
Terrence Brunton
45
Chapter Two
database on its customers that includes their preferences for styling, model types, colours,
prices and other features.
The building compound is partitioned into a reception area, sales area (which includes a
showroom), a service bay (including a garage), warehousing facilities, offices and ample
parking for its customers.
Toyotas computers and peripherals are connected through a local area network. This
network enables the departments and the people within those departments to share
information and resources. The primary purpose for maintaining and operating the
network is to share identical data that is always available to, and modifiable by, different
people simultaneously.
In dealing with the service aspect of TTTL, the database structure will support the heavy
flow of transactions that take place on a daily basis. Although this project considers only
the service aspect of TTTL, the description of the business operations helps to establish
several processes namely, inventory, job orders, invoicing.
Each transaction will generate a set of procedures supported by a database design module
and within each module a set of entities will be defined. The remaining description of
operations will add the required detail and will help define other processes, entities,
attributes, relationships, etc.
It is true that in order for any business to survive and thrive, its business objectives must
be synchronized with its business type. With this in mind, the business objectives must
be defined precisely and in detail. Since the business objectives are so closely tied to the
business type, they help audit the initial database components. For example, while the
business objectives are likely to add attributes and entities to the database design, they
should not yield database components that are in conflict with those required by the
business type.
Company Objectives
1. To maintain and manage sustainable sales growth
This objective requires designing Toyotas operations to foster customer loyalty
and to attract new customers by:
a. Maintaining an inventory of products that meet customer needs.
b. Maintaining and improving order response time.
c. Delivering ordered products quickly and efficiently.
d. Maintaining customer contact through follow-up actions.
e. Maintaining price competitiveness through operational cost control.
2. To maximize net sales returns by maintaining and improving cost controls through:
a. Efficient data access and data-to-information transformation to improve
inventory management
Terrence Brunton
46
Chapter Two
CUSTOMER
owns
interacts
with
EMP_TYPE
Terrence Brunton
CAR
enters
writes
JOB ORDER
47
Chapter Two
Terrence Brunton
48
Chapter Two
has
JOB SHEET
is returned to
SERVICE
ADVISOR
writes
CUSTOMER
generates
INVOICE
contains
PART
is written in
INVOICE LINE
Terrence Brunton
49
Chapter Two
EMPLOYEE
is of
is
assigned
to
EMPLOYEE
TYPE
make up
TEAM
works
on
Terrence BruntonPART
used on
CAR
uses
TOOL
50
Chapter Two
Employee Type
Customer
Customer ID
First Name
Last Name
Address
Phone
Mobile
Title
Town
Job Order
Job Order ID
Date
Customer ID
License Plate
Employee ID
Complaint
Periodic Maintenance
Relational
Schema
General Service
Body Repair
Particular Repair
PreDelivery Service
Accessories Job
Warranty Repair
Inspection
Repeat Repair
Other
Maintenance Level
Employee Type ID
Employee Type
Description
Car
VIN Number
License Plate
Model
Year
Engine
Customer ID
Employee
Employee ID
Title
First Name
Last Name
Address
Town
Birthdate
Recruitment Date
Termination Date
Phone Number
Mobile Number
Employee Type ID
Invoice
Invoice ID
Customer ID
License Plate
Invoice Date
Employee ID
Job Order ID
Team
Team ID
Employee 1
Employee 2
Employee 3
Employee 4
Employee 5
Invoice Line
Part
Part ID
Part Description
Part Cost
Part Price
Part Quantity
Part Min. Quantity
Terrence Brunton
Invoice Line ID
Line Number
Part ID
Unites
Price
Amount
Sub Total
Invoice Total
Tax
Service Charge
Repair Order
Tool
Tool ID
Tool Name
Purpose
Team ID
Repair Order ID
Job Order ID
Work Done
Tool 1
Tool 2
Employee ID
Date in
Date out
Team ID
51
Terrence Brunton
Chapter Two
52