Sei sulla pagina 1di 33

Lecture Notes on Database

Chapter Two

ENTITY RELATIONSHIP MODELING

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

Lecture Notes on Database

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

Lecture Notes on Database

Chapter Two

Entity & Entity Class


An ENTITY is an object or event that the analyst wants to document. Remember that
this object or event is being and happening in and/or out of the organization. The analyst
has to discover and represent these things, first, diagrammatically in an ERD, and then in
data. The entity is represented diagrammatically by a box with a name. The name is in
all capitals and is singular.
NAME

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

Lecture Notes on Database

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

While it is not essential to show attributes on an entity relationship diagram, it is helpful


to clarify the nature of the entity and identify attributes early, for later use when defining
database tables.
An attribute describes only one entity, and it must describe only the entity against which
it is shown. This may seem obvious at first glance, but we may find in a real organization
that different entities may have attributes that appear to be similar. For example, both the
entity student and the entity lecturer may have an attribute that may be called address.
As a rule of thumb, do not use more than seven attributes to describe an entity.
Sometimes relationships may be disguised as attributes, or attributes of one entity may be
masquerading as attributes of another. For example, consider the case of employees and
their departments in an organization. The entity EMPLOYEE may be shown as having
an attribute department number, this is wrong. Department number is really an
attribute of the entity DEPARTMENT.

Terrence Brunton

23

Lecture Notes on Database

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

Lecture Notes on Database

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

It is important that we understand the difference between type


and instance. The definitions we were looking at; for entity, for
relationship, for attribute and for unique identifier are all
definitions that represent a type or class of concept not an
instance. Each class would have many instances, and each
instance would belong to a specific class.

25

Lecture Notes on Database


Layout Rules

Chapter Two

These are designed to make the diagrams easy to read and to


maximize the quality and accuracy.

* 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

Lecture Notes on Database

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

Lecture Notes on Database

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

Lecture Notes on Database

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

Lecture Notes on Database

Chapter Two

Example Caribbean Air Travel*


To illustrate the use of Entity Relationship Diagrams we will now look at an example.
Caribbean Air Travel is an imagined passenger airline plying routes throughout the
Caribbean and between the Caribbean and a few large cities, such as Miami and New
York.
A central document used in the airline information system is the ticket. A ticket is made
up of coupons, each of which is used to record information pertaining to a flight
between two airports.
A Caribbean Air ticket is shown below in Figure 2.1.

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]

Subject to conditions of contract contained herein.

Figure 2.1 An Airline Ticket

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

Lecture Notes on Database

Chapter Two

Entity Relationship Model of the ticket:

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.

Figure 2.2 ERD of the ticket


The nucleus of this simple system is the coupon. It is significant as the lowest common
denominator and has vital information such as its class and status. It can only exist
within the context of a ticket, from which it inherits the date of issue and fare.
Each of the boxes in the ERD in Figure 2.2 above is an entity and the line between is a
relationship. The line has a forked (many) ending on the left and a single (one) ending on
the right, indicating that there can be many coupons on one ticket: a many to one
relationship. The line is solid to show that the relationship is mandatory. The
relationship can be read from the left to right to tell us that:
Each COUPON must be on one and only one TICKET
And reading from right to left:
Each TICKET must be made up on one or more COUPONs.
Notice that the phrase must be is used to tell us that this is a mandatory relationship.
Let us now look at the same information from the perspective of the aircraft. Each
aircraft will typically make several flights each day, identified by the date and time of
departure, the flight number and the departure airport. The flight number (e.g. CAT426)
gives us two pieces of information. The first part tells us the airline in this case CAT
means the Caribbean Air Travel airline. The second part uniquely identifies a route that
the airline flies. We therefore need to know which aircraft have been assigned to which
flights, how many tickets have been sold, whether the flights have been confirmed and
which seats have been allocated.

Terrence Brunton

31

Lecture Notes on Database

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

Figure 2.3 ERD of TICKET to FLIGHT Relationship


This shows that a coupon is in some way related to a flight. The diagram now reads from
left to right:
Each COUPON must be for one and only one FLIGHT
And conversely from right to left:
Each FLIGHT may be the subject of one or more COUPONs.
Notice that the flight may not be the subject of any coupons at all! This is shown by the
dotted part of the line, which means that the relationship is optional. This could be
because the flight has only just been put into the schedule, or we have not sold any
coupons for it yet. In either case, starting at flight and looking along the relationship to
coupon gives us some useful information.
We now have a strong relationship between a ticket and a flight, via the coupon. In fact,
this is a many to many relationship, as is shown in Figure 2.3, which reflects the true
business situation. `

Terrence Brunton

32

Lecture Notes on Database

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:

****

Each TICKET has a date of issue and a fare.

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

Figure 2.4 Core model of airline operations

Example - Credit Card


Terrence Brunton

33

Lecture Notes on Database

Chapter Two

CONDITION

CREDIT
CARD

CARD TYPE

PERSON

ACCOUNT

COMPANY

Naming a Relationship

Terrence Brunton

34

Lecture Notes on Database

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

ONE AND ONLY ONE ENTITY B (ever)


(is that true?)
ONE OR MORE ENTITY B plural

And conversely:
must be
Each (and every) ENTITY B

end-name-1
may be

ONE AND ONLY ONE ENTITY A (ever)


(is that true?)
ONE OR MORE ENTITY A plural

Entity Relationship Diagrams

Terrence Brunton

35

Lecture Notes on Database

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

Definition and Use

An Entity Relationship Diagram (ERD) is a graphical representation of the


relationships among tables in a database
This representation can also be referred to as the 'data model,' 'database schema,'
or 'database diagram' among other names
An ERD represents the logical relationships between tables; it has nothing to do
with the way the data is physically stored in the database
There is no standard way to represent an ERD, however some common
conventions discussed below
SQL Server 7.0, includes a database diagramming tool that can easily create
ERDs
Prior to version 7.0, SQL Server did not have this capability so ERDs were
typically created in Microsoft Access or with a third-party product like Visio
Note that unlike Access, the SQL Server 7.0 diagram tool does not draw
relationships lines directly connecting to keys (i.e., the columns used to establish the
relationship); however, you can manipulate their position on the screen to point to the
appropriate location
There is no standard way to draw an ERD; several different conventions are used

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

Lecture Notes on Database

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

Relationship are represented by lines between the table boxes


A one-to-one relationship may be represented by a line without an endpoint;
sometimes it will be annotated with a '1' or, in SQL Server, with a 'key' icon on either
end
A one-to-many relationship may be represented by a line with a dot on the 'many'
end; sometimes the line will be annotated with an 'N' or, in SQL Server, with an
infinity symbol on the 'many' end
As discussed in Relationships, a many-to-many relationship is simply two oneto-many relationships as show below:

Terrence Brunton

37

Lecture Notes on Database

o
o
o

Chapter Two

Sometimes the ERD graphically distinguishes between dependent and


independent relationships
A dependent relationship is one where the PK of a dependent table is also a FK;
typically the dependent table box is drawn with rounded corners
Independent tables are drawn with square corners
The SQL Server diagram tool does not distinguish between independent and
dependent relationships
Other designations sometimes used include:
Z - means 'one to zero or one' relationship
P -means 'one to one or more' relationship
n - means 'one to exactly n' relationship

ERD for the 'Pubs' Database

Terrence Brunton

38

Lecture Notes on Database

Chapter Two

ERD for the 'Northwind' Database

Terrence Brunton

39

Lecture Notes on Database

Chapter Two

Relationships

Terrence Brunton

40

Lecture Notes on Database

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

Basic Characteristics of Relationships

In a relational database all data is organized into tables often referred to as


entities or relations.
An advantage of the relational database model is its ability to establish
associations or 'relationships' between the tables.
A relationship is a logical linking between two entities (tables) that describe how
they are associated with each other.
Relationships are used to enforce data integrity and facilitate joins to provide
access to multiple tables at the same time.
Other database models (e.g., hierarchical or network) use explicit pointers to
associate pieces of data.
Relationships are represented by common data values stored in two tables.
Example: a relationship is established between the customer and orders tables by
placing a customer ID column in both tables; each 'order' can then be 'related' to a
particular customer by the value in this common column.
The common columns that relate two tables are called keys (primary or foreign
key).
In some cases a key can consist of one or more column in which case it is referred
to as a composite key.
A primary key (PK) is a column (s) that uniquely identifies each row in the
primary or 'parent' table.
The PK not only ensures there are no duplicate rows but it also provides a
mechanism that allows you to reference all of the attributes (columns) of a specific
row simply by referring to one numeric value.
Example: You can reference any information about a particular customer simply
by referring to that customer's ID.
The PK should be a small numeric key so that it is easy to sort, store and search.
A foreign key (FK) in related or 'child' table inherits the primary key of the
'parent' or primary table.
Thus, a PK-FK combination establishes a relationship between the parent and
child tables.

Terrence Brunton

41

Lecture Notes on Database

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

When designing a database, an entity (table) is anything that contributes to the


business operation and can be described in terms of accessible data.
In other words, if you were describing the activity being modeled by the database,
the entities would typically be the nouns in your description.
Relationships between entities (tables) are logical, not physical (i.e., they dont
exist as separate objects in a database).
Relationships are defined as a logical link between the primary key (PK) of the
parent table with the foreign key (FK) of the child table.
When a relationship is created, the parent table contributes its primary key to the
child table where it is referred to as a foreign key.
In other words, the relationship is created by storing the value of the PK for the
parent in the FK column of the child.
The general SQL syntax for adding a primary key to a table is:
CONSTRAINT constraint_name PRIMARY KEY (column_name)
The general SQL syntax for adding a foreign key to a table is:
CONSTRAINT constraint_name FOREIGN KEY (column_name)
REFERENCES parent_table_name (column_name_in_parent_table)
Note that the FK must references a column in another table.
A FK can only reference a column that has either a PRIMARY KEY constraint or
a UNIQUE constraint.
Hence, a FK can implement a one-to-one or many-to-one relationship but cannot
implement a one-to-many relationship.

One-to-Many (1-N)

A one-to-many relationship is the most common type of relationship.


One instance of an entity (the parent) is associated with zero or several
instances of another entity (the child).

Terrence Brunton

42

Lecture Notes on Database

Chapter Two

The classic example of a one-to-many relationship is that of 'customers' and


'orders;' each customer (parent) can have many orders, but each order (child) can be
related to only one customer.

To implement this relationship, a 'customer ID' column is added to the 'orders'


table (FK) and referenced to 'customer ID' column in the 'customers' table (PK).

Many-to-Many (N-N)

In a many-to-many relationship, many instances of one entity are associated


with many instances of another entity.
The classic example of a many-to-many relationship is that of 'orders' and 'parts'.
Each order can consist of many parts and each part can be used in many orders.
This type of relationship cannot be established directly.
A third table, called a junction table or associating table, is used to establish the
relationship.
A junction table typically has a composite PK that consists of two or more
columns that also serve as FKs.
In effect you have two one-to-many relationships linked via the junction table that
together produce a single many-to-many relationship.

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

Lecture Notes on Database

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 a one-to-one relationship, one instance of one entity is associated with a


single instance of another entity.
This type of relationship is not very common.
In order to evaluate the need for a one-to-one relationship, ask yourself why you
can't just use one large table.
By implementing a one-to-one relationship you are in effect vertically partitioning
a table (splitting it into two pieces).
There are typically two reasons for vertically partitioning a table by implementing
a one-to-one relationship: 1) security and 2) performance.
Example: You split the employee table into two pieces so that salary and other
sensitive information can be stored in separate table (security).
Example: Some columns in a large table are not accessed frequently or contain
large data types so they are moved to a separate table (performance).

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

A recursive relationship refers to a relationship established within a table.


In other words, a table is 'related' to itself.
Recursive relationships are usually established in situations where it is useful to
perform a self-join.
The classic example of a self-join is the 'employee-manager' report. In this
situation, the 'employees' table contains name, ID and 'reports to' columns. The
'reports to' column contains the ID (not the name) of the employee's manager. In order

Terrence Brunton

44

Lecture Notes on Database

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.

Establishing this internal relationship allows referential integrity to be enforced


(e.g., you cannot insert a manager ID into the 'reports to' column that does not exist
in the employee ID column).
A recursive relationship is sometimes referred to as a reflexive relationship.

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

Lecture Notes on Database

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

Lecture Notes on Database

Chapter Two

b. The customer order process.


c. The vendor order process.
d. The shipping process.
e. The back-order process.
f. The product return process.

Business Rules & ERDs


The Job Order Module
A customer is someone who has purchased a Toyota vehicle in the past.
1. Customers of Toyota own cars. This business rule establishes two entities,
CUSTOMER and CAR. A customer may own many cars but a car is owned by only
one primary customer. Therefore a 1:M relationship exists between customer and car.
When servicing is due the customer brings the car in for servicing.
2. Customers interact with an EMPLOYEE initially when a car is brought in for
servicing. This employee can only be of EMP_TYPE service advisor.
3. Service advisor generates a JOB_ORDER. This establishes a 1:M relationship
between service advisor and job order as a service advisor can generate more than one
job order.
4. When a customer brings in a car for servicing, the car is entered on a job order. A
relationship is created between CAR and JOB_ORDER. Only one car can be entered
on one job order but over time, one car can generate many job orders.
The Job Order Module ERD

CUSTOMER

owns

interacts
with

EMP_TYPE

Terrence Brunton

CAR

enters

writes

JOB ORDER

47

Lecture Notes on Database

Chapter Two

The Invoicing Module


The invoicing module will be based on the following business rules.
1. An invoice is generated only when a customer makes a purchase. This business rule
establishes that CUSTOMER is mandatory to INVOICE, i.e. you cannot generate an
invoice unless a customer buys something. Also, an INVOICE is optional to
CUSTOMER as a customer may not have bought anything from Toyota.
2. A customer may generate many invoices, but each invoice is generated by only one
customer. This business rule establishes a 1:M relationship between CUSTOMER
and INVOICE.
3. Each invoice must be generated by a service advisor. Here, this business rule
establishes a new entity SERVICE ADVISOR. Also, it establishes that
SERVICE_ADVISOR is mandatory to INVOICE.
4. Each service advisor may generate many invoices but each invoices is generated by
one service advisor. Hence, this business rule establishes a 1:M relationship between
SERVICE_ADVISOR and INVOICE.
5. A service advisor is an employee though not all employees are service advisor. This
business rule establishes that the SERVICE_ADVISOR entity is optional to the
EMPLOYEE entity. There exists a 1:1 relationship between EMPLOYEE and
SERVICE_ADVISOR.
6. An invoice contains at least one invoice line and each invoice line belongs to a
specific invoice. This business rule establishes a new entity called INV_LINE and
establishes a 1:M relationship between INVOICE and INV_LINE. Clearly, an
invoice line cannot exist without an invoice and an invoice must contain at least one
invoice line to reflect the sales of at least one type of service.
7. Each invoice line references one product, but a product may be found in many
invoice lines. This business rule establishes a 1: M relationship between INV_LINE
and PART. Each invoice line references a product and each invoice line is also
associated with a given invoice. Therefore the INV_LINE is the connector between
the INVOICE and PART entities.
8. A service that is never sold to a customer will never appear on an invoice line. This
business rule establishes an optional relationship between INV_LINE and PART.

Terrence Brunton

48

Lecture Notes on Database

Chapter Two

The Invoicing Module ERD


EMPLOYEE

has
JOB SHEET

is returned to

SERVICE
ADVISOR

writes

CUSTOMER

generates

INVOICE

contains

PART

is written in

INVOICE LINE

The Servicing Module


1. There are different types of employees. This establishes the entity of
EMPLOYEE_TYPE. Each employee is of one employee type. This establishes a 1:1
relationship between EMPLOYEE and EMPLOYEE_TYPE.
2. The employee of type garage foreman accepts the vehicle and the job order from the
service advisor. This business rule establishes three entities, CAR, JOB ORDER and
EMPLOYEE. There is a mandatory relationship between job order and car and an
optional relationship between JOB ORDER and EMPLOYEE, in that vehicle is
mandatory to JOB ORDER and JOB ORDER is optional to EMPLOYEE. There is
only one vehicle per job order. There is a 1:M relationship between JOB ORDER and
EMPLOYEE as an employee could have performed many service jobs on one
vehicle.
3. The garage foreman analyses the job order information and assigns the job or job
segments to the appropriate technical team. This establishes the entity of TEAM, and

Terrence Brunton

49

Lecture Notes on Database

Chapter Two

establishes that TEAM is mandatory to JOB ORDER. Also, this establishes a


relationship between TEAM and EMPLOYEE such that the TEAM is made up of as
many as five EMPLOYEES and each EMPLOYEE belongs to only one TEAM.
There is a 1:M relationship between TEAM and JOB_ORDER as one TEAM can
work on more than one JOB_ORDER.
4. Parts required for the service job are sourced from Toyotas on-site warehouse. These
parts are used in the car. This rule shows the relationship between PARTS and CAR
and establishes that more than one part can be used on a car.
5. PARTS are assigned to the job they are to be used for. This establishes a relationship
between PARTS and JOB_ORDER, since PARTS used on the car will be placed on
the JOB_ORDER.
6. Specialized tools used in a job must be signed for by the technician using the
equipment. This creates the entity TOOLS, and established that JOB_ORDER is
mandatory to TOOLS as such tool used must be tied to a service job performed. There
is a 1:M relationship between JOB_ORDER and TOOLS as one JOB_ORDER may
require more than one TOOL. receives
JOB ORDER

EMPLOYEE

is of

is
assigned
to

EMPLOYEE
TYPE

The Servicing Module ERD

make up

TEAM

works
on

Terrence BruntonPART

used on

CAR

uses

TOOL

50

Lecture Notes on Database

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

Lecture Notes on Database

Terrence Brunton

Chapter Two

52