The Entity-Relationship Model

Conceptual Data Modeling

Lecture 3
The Entity-Relationship model
The E-R model is a detailed, logical representation of the
data for an organisation or business area
It should be understandable to both the user and to the IT
technologist
The model must be as open as possible and not tied to
any technology or to any particular business methodology
It must be flexible enough so that it can be used and
understood in practically any environment where
information is modelled

The ER model
It is expressed in terms of entities in the business
environment, the relationships (or associations) among
those entities and the attributes (properties) of both the
entities and their relationships
The E-R model is usually expressed as an E-R diagram

E-R Model Constructs
Entity - person, place, object, event, concept
Entity Type - is a collection of entities that share common
properties or characteristics. Each entity type is given a
name, since this name represents a set of items, it is always
singular. It is placed inside the box representing the entity
type (Fig. 3-1)
Entity instance is a single occurrence of an entity type.
An entity type is described just once (using metadata) in a
database, while many instances of that entity type may be
represented by data stored in the database. e.g. there is
one EMPLOYEE entity type in most organisations, but
there may be hundreds of instances of this entity stored in
the database


Sample E-R Diagram
Entity type versus system input,
output or user
A common mistake is to confuse data entities with other
elements of the IS model
A simple rule is that a true data entity will have many
possible instances, each with a distinguishing characteristic
Treasurer is the person entering data and data about the
treasurer need not be kept


Entity type versus system input,
output or user
Is the expense report entity necessary? It is only the result
of extracting data from the database. Even though there
will be multiple instances of expense reports given to the
treasurer over time, data needed to compute the report
contents each time are already represented by the
ACCOUNT and EXPENSE entity types
Gives-to and Receives are business activities, not
relationships between entities.
Example of inappropriate entities
(a) System user (Treasurer) and output
(Expense Report) shown as entities
(b) E-R model with only the necessary entities
Strong versus Weak entity type

Most of the basic entity types are classified as strong
entity types [Rectangle] one that exists independently
from other entity types (such as EMPLOYEE)
Always have a unique characteristic (identifier) an
attribute or combination of attributes that uniquely
distinguish each occurrence of that identity
A weak entity type [[Double Rectangle]] existence
depends on some other entity type. It has no meaning in
the ER diagram without the entity on which it depends
(such as DEPENDENT)
The entity type on which the weak entity type depends is
called the Identifying owner (or owner for short).
Strong versus Weak entity type
Identifying relationship is the relationship
between a weak entity type and and its owner
(such as Has in the following Fig.)
Weak entity identifier is its partial identifier
(double underline) combined with that of its
owner. During a later design stage dependent
name will be combined with Employee_ID (the
identifier of the owner) to form a full identifier
for DEPENDENT.


Example of a weak entity
Attributes
An attribute is a property or characteristic of an entity type,
for example the entity EMPLOYEE may have attributes
Employee_Name and Employee_Address.
In ER diagrams place attributes name in an ellipse with a
line connecting it to its associated entity
Attributes may also be associated with relationships
An attribute is associated with exactly one entity or
relationship
Simple versus composite
attributes (following Fig.)
Some attributes can be broken down into meaningful
component parts, such as Address, which can be broken
down into Street_Address, City..etc.
The component attributes may appear above or below the
composite attribute on an ER diagram
Provide flexibility to users, as can refer to it as a single unit
or to the individual components
A simple (atomic) attribute is one that cannot be broken
down into smaller components
A composite attribute
Single-Valued versus
Multivalued Attribute
It frequently happens that there is an attribute that may
have more than one value for a given instance, e.g.
EMPLOYEE may have more than one Skill.
A multivalued attribute is one that may take on more than
one value it is represented by an ellipse with double lines


Entity with a multivalued attribute (Skill)
and derived attribute (Years_Employed)
Stored versus Derived Attributes
Some attribute values can be calculated or derived from
others
e.g., if Years_Employed needs to be calculated for
EMPLOYEE, it can be calculated using Date_Employed
and Today's_Date
A derived attribute is one whose value can be calculated
from related attribute values (plus possibly other data not
in the database)
A derived attribute is signified by an ellipse with a dashed
line (see previous Fig.)
Identifier attribute
Identifier attribute or Key is an attribute (or combination of
attributes) that uniquely identifies individual instances of
an entity type, such as Student_ID
To be a candidate identifier, each entity instance must have
a single value for the attribute, and the attribute must be
associated with each entity
The identifier attribute is underlined, such as Student_ID
Simple and composite key attributes
(a) Simple key attribute
Composite Identifier
A Composite Identifier is when there is no single (or
atomic) that can serve as an identifier
Flight_ID is a composite identifier that has component
attributes Flight_Number and Date this combination is
required to uniquely identify individual occurrences of
Flight
Flight_ID is underlined, whilst its components are not

(b) Composite key attribute
Criteria for selecting identifiers
Some entities have more than one candidate identifier, so the
following criteria should be used:
Choose identifier that will not change in value over the life of
each instance of the entity type
Choose identifier that is guaranteed to have valid values and
Will not be null (or unknown). If composite, make sure all
parts will have valid values
Criteria for selecting identifiers
Avoid the use of intelligent identifiers whose structure
indicates classifications, locations or people that might
change. e.g. the first two digits of an identifier may
indicate a warehouse location, but such codes are often
changed as conditions change, which renders them invalid.
Consider substituting new, simple identifiers for long,
composite ones, e.g. an attribute called Game_Number
could be used for the entity type GAME instead of
Home_Team and Away_Team

Relationships (following Fig.)
A relationship is an association among the instances of one
or more entity types that is of interest to the organisation
Relationship Type is a meaningful association between (or
among) entities implying that the relationship allows us
to answer questions that could not be answered given only
the entity types. It is denoted by a diamond symbol

Relationship types and instances
(a) Relationship type (Completes)
Relationship instance
Is an association between (or among) entity instances,
where each relationship includes exactly one entity from
each participating entity type.
For example, in the following figure each line represents a
relationship instance between one employee and one
course, indicating that the employee has completed that
course
(b) Relationship instances
Attributes on relationships
Attributes may be associated with a many-to-many (or
one-to-one) relationship, as well as with an entity
e.g., an organisation may want to record the date when an
employee completes each course
In the following diagram, the relationship Completes
joins the EMPLOYEE and COURSE entities, and
Date_Completed is joined to this as it is a property of the
relationship Completes
An associative entity
(a) Attribute on a relationship
Associative entities (gerunds)
The presence of one or more attributes on a relationship
suggests that the relationship should perhaps be
represented as an entity type
An associative entity is an entity type that associates the
instances of one or more entity types and contains
attributes that are peculiar to the relationship between
those entity instances.
The associative entity type CERTIFICATE is represented
with the diamond relationship symbol enclosed within the
entity rectangle
Associative entities (gerunds)
The purpose of this special symbol is to preserve the
information that the entity was initially specified as a
relationship on the ER diagram
There is no relationship diamond on the line between an
associative entity and a strong entity, because the
associative entity represents the relationship

Associative entities
How do you know when to convert a relationship to an
associative entity type? Four conditions should exist:
All of the relationships are many relationships
The resulting associative identity type has independent
meaning to end-users, and can preferably be identified with
a single-attribute identifier

Associative entities
The associative entity has one or more attributes in
addition to the identifier
The associative entity participates in one or more
relationships independent of the entities related in the
associated relationship
The following figure shows the relationship Completes
converted to an associative entity type
A CERTIFICATE is awarded to each EMPLOYEE who
completes a COURSE, each certificate has a
Certificate_Number that serves as the identifier
(b) An associative entity (CERTIFICATE)
Degree of a relationship
Is the number of entity types that participate in it.
Thus Completes has degree 2, since there are two
participating entity types, EMPLOYEE and COURSE
The three most common relationship degrees are unary
(degree 1), binary (degree 2) and ternary (degree 3 see
following Fig.)
Higher degree relationships are possible but rarely
encountered in practice

Unary relationship
Is between the instances of a single entity type (also called
recursive relationships)
Is_Married_To is a one-to-one relationship between
instances of the PERSON entity type
Manages is a one-to-many relationship between instances
of the EMPLOYEE entity type
Binary relationships
Between the instances of two entity types, and is the most
common type of relationship encountered in data
modelling. e.g. (one-to-one) an EMPLOYEE is assigned
one PARKING_PLACE, and each PARKING_PLACE is
assigned to one EMPLOYEE
e.g. (one to many) a PRODUCT_LINE may contain many
PRODUCTS, and each PRODUCT belongs to only one
PRODUCT_LINE
e.g. (many-to-many) a STUDENT may register for more
than one COURSE, and each COURSE may have many
STUDENTS
Ternary relationships
A ternary relationship is a simultaneous relationship
among the instances of 3 entity types
It is the most common relationship encountered in data
modelling
The following Fig. shows a typical ternary relationship
Here, vendors can supply various parts to warehouses

Ternary relationships
The relationship Supplies is used to record the specific
PARTs supplied by a given VENDOR to a particular
WAREHOUSE
There are two attributes on the relationship Supplies,
Shipping_Mode and Unit_Cost
e.g. one instance of Supplies might record that VENDOR
X can ship PART C to WAREHOUSE Y, that the
Shipping_Mode is next_day_air and the Unit_Cost is 5-
00 per unit
Ternary relationships
Ternary relationships
We do not use diamond symbols on the lines from
SUPPLY_SCHEDULE to the three entities, because these
lines do not represent binary relationships
It is recommended that all ternary (or higher) relationships
are converted into associative entities (as in the Fig.), as it
makes the representation of participation constraints
(discussed later) easier
Many CASE tools cannot represent ternary relationships,
so you must represent the ternary relationship with an
associative entity and three binary relationships
Cardinality constraints
The number of instances of one entity that can or must be
associated with each instance of another entity.
If we have two entity types A and B, the cardinality
constraint specifies the number of instances of entity B that
can (or must) be associated with entity A
e.g. a video store may stock more than one VIDEOTAPE
for each MOVIE, this is a one-to-many relationship as in
the following Fig.

Introducing cardinality constraints
(a) Basic relationship
Minimum cardinality
Yet there may be a more precise way of saying this
The minimum cardinality of a relationship is the
minimum number of instances of an entity B that may
be associated with each instance of an entity A
In our example, the minimum number of
VIDEOTAPES of a MOVIE is zero (entity B is an
optional participant in the Is_Stocked_As
relationship)
This is signified by the symbol zero through the arrow
near the VIDEOTAPE entity in the following Fig.


Maximum cardinality
Is the maximum number of instances of an entity B that
may be associated with each instance of entity A
In the following Fig., the maximum cardinality for the
VIDEOTAPE entity type is many (an unspecified
number greater than 1)
This is indicated by the crows foot symbol on the
arrow next to the VIDEOTAPE entity symbol

Mandatory one cardinality
Relationships are bi-directional, so there is also
cardinality notation next to the MOVIE entity
Notice that as the minimum and maximum are both
one, this is called mandatory one cardinality (i.e., each
VIDEOTAPE of a MOVIE must be a copy of exactly
one movie)
In the following Fig. Some attributes have been added.
VIDEOTAPE is represented as a weak entity because it
cannot exist unless the original owner movie also exists

Mandatory one cardinality
The identifier of the MOVIE is Movie_Name
VIDEOTAPE does not have a unique identifier,
however the partial identifier Copy_Number together
with Movie_Name would uniquely identify an instance
of VIDEOTAPE

(b) Relationship with cardinality constraints
Example of mandatory
cardinality constraints
Each PATIENT has one or more PATIENT_HISTORIES
(the initial patient visit is always recorded as an instance of
PATIENT_HISTORY)
Each instance of PATIENT_HISTORY Belongs to
exactly one PATIENT (see following Fig.)
Mandatory cardinalities
Example of one optional, one
mandatory cardinality constraint
EMPLOYEE Is_Assigned_To PROJECT
Each PROJECT has at least one EMPLOYEE assigned to
it (some projects have more than one)
Each EMPLOYEE may or (optionally) may not be
assigned to any existing PROJECT, or may be assigned to
one or more PROJECTs (see following Fig.)
One optional, one mandatory cardinality
An example using a ternary
relationship
PART and WAREHOUSE are mandatory participants in
the relationship, whilst VENDOR is an optional participant
The cardinality of each of the participating entities is
mandatory one, since each SUPPLY_SCHEDULE
instance must be related to exactly one instance of each of
these participating entity types
An example using a ternary
relationship
Each VENDOR can supply many PARTs to any number of
WAREHOUSES, but need not supply any parts
Each PART can be supplied by any number of VENDORs
to more than one WAREHOUSE, but each part must be
supplied by at least one vendor to a warehouse
Each WAREHOUSE can be supplied with any number of
PARTS from more than one VENDOR, but each
warehouse must be supplied with at least one part
Cardinality constraints in a ternary relationship
An example using a ternary
relationship
A ternary relationship is not equivalent to three binary
relationships
Unfortunately you cannot draw ternary relationships with
many CASE tools
Instead you must represent ternary relationships as three
binaries
If you are forced to do this, then do not draw the binary
relationships with diamonds and make sure the cardinality
next to the three strong entities are mandatory one
Modelling time-dependent data
Some database values change over time (e.g. price)
We may need to preserve a history of the prices and the
time period over which each was in effect
We can think of a series of prices and the effective date
(see Fig.), giving a (composite) multivalued attribute
Price_History (that has components Price and
Effective_Date)
Simple example of time stamping
Time stamps
Are simply time values associated with a data value
May be recorded to indicate the time the value was entered
(transaction time), time the value becomes valid or stops
being valid, or the time when critical actions were
performed (such as updates, corrections or audits)
More complex time-dependent data
Suppose that in the middle of the year some PRODUCTS are
reassigned to different PRODUCT_LINES, so all sales
reports will show cumulative sales for a product based on its
current product line, rather than the one at the time of the
sale
To model this, a new relationship Sales_for_Product_Line
has been added between ORDER and PRODUCT_LINE, so
that as customer orders are processed, they are credited to
both the correct product and the correct product line as the
time of the sale
Many current data models are inadequate in handling time-
dependent data, but some data-warehousing systems provide
explicit designs for time dependent data
Multiple relationships
In some situations an organisation may want to model
more than one relationship between the same entity types
The following figure shows two relationships between
PROFESSOR and COURSE
The relationship Is_Qualified associates professors with
the courses they are qualified to teach
A given course may have more than one person qualified
to teach it, or (optionally) may not have any qualified
instructors (such as a new course)
Each professor should be qualified to teach at least one
course (we hope!)
Multiple relationships
The second relationship in this figure associates professors
with the courses they actually teach during a given
semester (where the maximum cardinality for a given
semester is 4)
This shows how a fixed constraint (upper or lower) can be
recorded
The attribute Semester (which could be a composite
attribute with components Semester_Name and Year) is
on the relationship Is_Scheduled)

(b) Professors and courses (fixed upon constraint)
Review of Basic E-R Notation
Data integrity controls
Referential integrity constraint that ensures that foreign
key values of a table must match primary key values of a
related table in 1:M relationships
A value in the matching column on the many side must
correspond to a value in the primary key for some row in
the table on the one side, or be NULL.
The REFERENCES clause prevents a foreign key value
from being added if it is not already a valid value in the
referenced primary key column, but there are also other
integrity issues
If a CUSTOMER_ID value is changed, the connection
between that customer and orders placed by that customer
will be ruined
Data integrity controls
The REFERENCES clause prevents making such a key in
the foreign value, but not in the primary key value
Can be handled by asserting that the primary key values
cannot be changed once they are established. In this case,
updates to the customer table will be handled by including
an ON UPDATE RESTRICT clause - so any updates to a
primary key value will be rejected unless no foreign key
references that value in any child table (see Fig.)
Another solution is to pass the changes through to the child
tables by using ON UPDATE CASCADE

Data integrity controls
A third solution is to allow the update on CUSTOMER_T
but to change the involved CUSTOMER_ID value in the
ORDER_T table to NULL using the ON UPDATE SET
NULL option - here the connection between the order and
the customer would be lost (not good) so probably the best
option would be the second, ON UPDATE CASCADE
Similar options are available for DELETE, such as as ON
DELETE RESTRICT where the customer record could not
be deleted unless there were no orders from the customer
With DELETE CASCADE, removing the customer would
remove all associated order records
Ensuring data integrity through updates
Changing tables
ALTER TABLE statement allows you to change column
specifications (not in views). e.g. a customer type column
may be added to the CUSTOMER table:
ALTER TABLE CUSTOMER_T
ADD (TYPE VARCHAR(2))
May include keywords such as ADD, DROP or ALTER
and allows changing the columns names, datatype, length
and constraints
Usually its null status will be NULL.When the new
column is created, it is added to all of the instances in the
table and the value of NULL would be the most reasonable
Removing tables
The DROP TABLE statement allows you to remove tables
from your schema:
DROP TABLE CUSTOMER_T
Views are dropped by using the similar DROP VIEW
command
The DROP TABLE command will drop the table and save
any pending changes to the database
It can be qualified with RESTRICT (will fail if there are
any dependent objects such as views or constraints that
currently reference the table) or CASCADE (all dependent
objects will also be dropped)

Removing tables
Can retain the tables structure but remove
all the data in the table using the
TRUNCATE_TABLE command.
Insert statement
Adds data to a table and is used to populate tables. If inserting a value
for every column into a table could use (must be in correct order):
INSERT INTO CUSTOMER_T VALUES
(001, CONTEMPORARY Casuals, 1355 S. Himes Blvd.,
Gainesville, FL, 32601);
When data will not be entered into every column either the value
NULL can be used for the empty fields or we can specify the columns
to which data are to be added:
INSERT INTO PRODUCT_T (PRODUCT_ID,
PRODUCT_DESCRIPTION,PRODUCT_FINISH,
STANDARD_PRICE, PRODUCT_ON_HAND)
VALUES (1, End Table, Cherry, 175, 8);

Insert statement
Can insert from another table. e.g. when wanting to
populate a table CA_CUSTOMER_T with only
Californian customers, can do the following:
INSERT INTO CA_CUSTOMER_T
SELECT * FROM CUSTOMER_T
WHERE STATE = CA;
The table identified in the INSERT command may be a
view, but the view must be updateable so that data inserted
through the view is also inserted into the base table on
which the view is based
Delete statement
Removes rows from a table, individually or in groups.
Supposing we can no longer deal with customers in
Hawaii, we could delete the correct rows using:
DELETE FROM CUSTOMER_T
WHERE STATE = HI;
To delete all rows from a table:
DELETE FROM CUSTOMER_T;
Delete statement
Deletion should be done with care when rows from several
relations are involved. If we delete a CUSTOMER_T row
before deleting associated ORDER_T rows, we will have a
referential integrity violation
Using the ON DELETE clause with a field definition can
solve such problems
As SQL actually eliminates all records selected by a
DELETE statement, it is always best to execute a SELECT
command first to display the records first and verify you
are doing the right thing!

Update statement
To modify data in existing rows we must specify what
relation, columns and rows are involved
e.g., to update the price for the dining table (Product 7) in
the PRODUCT_T table we would use:
UPDATE PRODUCT_T
SET UNIT_PRICE = 775
WHERE PRODUCT_ID = 7;
The SET command can also change a value to NULL
As with DELETE, the WHERE clause in an UPDATE
command may contain a subquery, but the table being
updated may not be referenced in the subquery (see later)
Commit and rollback
A sequence of database modifications (insert, update and
delete) is called a transaction
Modifications of tuples are temporarily stored in the
database system
They become permanent only after the statement
COMMIT has been issued
As long as the user has not issued the COMMIT statement,
it is possible to undo all modifications since the last
COMMIT
To undo modifications we use the ROLLBACK statement
Commit and rollback
It is advisable to complete each modification of the
database with a COMMIT (as long as the modification has
the expected effect)
Note that any data definition command such as CREATE
TABLE results in an internal COMMIT
A COMMIT is also implicitly executed when the user
terminates an Oracle session