APT1050

Modeling Data in the

Organization

11:05 Dr. Patrick Wamuyu

 Database Design
The process of creating a design for a database
that will support the enterprise’s mission
statement and mission objectives for the required
database system.
Before we create and use a database we’ll look at
how to design one
One need to consider
What is the database going to be used for?
How will the database be accessed?
What tables and constraints are needed?
11:05 Dr. Patrick Wamuyu
 Database Design
Main purposes of data modeling include:
to assist in understanding the meaning (semantics) of the
data;
to facilitate communication about the information
requirements.
Building data model requires answering questions
about entities, relationships, and attributes.
A data model ensures we understand:
Each user’s perspective of the data;
Nature of the data itself, independent of its physical
representations;
Use of data across user views.
11:05 Dr. Patrick Wamuyu
 Data Modeling
Three phases of database design:
Conceptual design: Build a model independent of the choice of
DBMS
Logical design: Create the database in a given DBMS
Physical design: How the database is stored in hardware
Conceptual Database Design
Process of constructing a model of the data used in an enterprise,
independent of all physical considerations.
Data model is built using the information in users’ requirements
specification.
Conceptual data model is source of information for logical
design phase.

11:05 Dr. Patrick Wamuyu

 Data Modeling
Logical Database Design
Process of constructing a model of the data used in an enterprise
based on a specific data model (e.g. relational), but independent
of a particular DBMS product and other physical
considerations.
Conceptual data model is refined and mapped on to a logical
data model.
Physical Database Design
Process of producing a description of the database
implementation on secondary storage.
Describes base relations, file organizations, and indexes used to
achieve efficient access to data.
Also describes any associated integrity constraints and security
measures.
Tailored to a specific DBMS system.
11:05 Dr. Patrick Wamuyu
 Why Create a Conceptual Model?
It describes exactly the information needs of
the business
It facilitates discussion
It helps to prevent mistakes,
misunderstanding
It forms important “ideal system”
documentation
It forms a sound basis for physical database
design
11:05 Dr. Patrick Wamuyu
Goals of Entity Relationship Modeling
It is a very good practice with many
practitioners
Capture all required information
Information appears only once
Model no information that is derivable
from other information already modeled
Information is in a predictable, logical
place
11:05 Dr. Patrick Wamuyu
 Entity-Relationship Model
Entity-Relationship Model(E-R Model)
A logical representation of the data for an organization
or for a business area, using entities for categories of
data and relationships for associations between entities
Entity Type–collection of entities (often corresponds to
a table)
Entity-Relationship Diagram (E-R Diagram or
ERD)
A graphical representation of an entity-relationship model
Give a conceptual view of the database
Is independent of the choice of DBMS product
E-R Modelling is used for conceptual design
11:05 Dr. Patrick Wamuyu
 Entity-Relationship Model
Three key elements in E-RD
Entities: Objects or items of interest
Attributes: Facts about, or properties of an entity
Relationships: Links between entities
Example
In a University database we might have entities for
Students, Courses and Lecturers.
Students might have attributes such as their ID
number, Name, and Major, and could have
relationships with Courses (enrolment) and Lecturers
11:05
(tutor/tutee) Dr. Patrick Wamuyu
Entity Relationship Model Constructs
Entity type
Group of objects with same properties, identified by enterprise
as having an independent existence.
Entity occurrence
Uniquely identifiable object of an entity type.
Physical existence
Staff, property, customer, supplier, product, part
Conceptual existence
Viewing, Sale, Inspection, Work experience, courses, projects
Entity instance–person, place, object, event, concept (often
corresponds to a row in a table)
Entity Type–collection of entities (often corresponds to a table)

11:05 Dr. Patrick Wamuyu

Entity Relationship Model Constructs
An entity represents a set of instances that are of interest
to a particular business.

11:05 Dr. Patrick Wamuyu

Entity Relationship Model Constructs
Diagramming Entities
In an E-R Diagram, an entity is usually drawn as a box with
rounded corners
The box is labelled with the name of the class of objects
represented by that entity

11:05 Dr. Patrick Wamuyu

 An Entity…
SHOULD BE:
An object that will have many instances in the
database
An object that will be composed of multiple attributes
SHOULD NOT BE:
A user of the database system
An output of the database system (e.g. a report)
The company/enterprise

11:05 Dr. Patrick Wamuyu

Entity Relationship Model Constructs
Relationship type
Set of meaningful associations among entity types.
Relationship occurrence
Uniquely identifiable association, which includes one
occurrence from each participating entity type.
Relationships:
Relationship instance–link between entities (corresponds to
primary key-foreign key equivalencies in related tables)
Relationship type–category of relationship…link between entity
types
Relationships are an association between two
or more entities
11:05 Dr. Patrick Wamuyu
Entity Relationship Model Constructs
The name is given in a diamond box
The ends of the link show cardinality

11:05 Dr. Patrick Wamuyu

Entity Relationship Model Constructs
Attribute
Property of an entity or a relationship type.
Often corresponds to a field in a table.
Attributes are facts, aspects, properties, or
details about an entity
Students have IDs, names, courses, addresses,
Modules have codes, titles, credit weights, levels, …
Attribute Domain
Set of allowable values for one or more
11:05
attributes (Domains of possible values).
Dr. Patrick Wamuyu
Entity Relationship Model Constructs
Simple Attribute
Attribute composed of a single component with an
independent existence. ID Number
Composite Attribute
Attribute composed of multiple components, each
with an independent existence.
Name(FirstName, MiddleName, LastName).
Multi-valued Attribute
Attribute that holds multiple values for each occurrence of an
entity type.
Color of a CAR or Previous Degrees of a STUDENT.
11:05 Dr. Patrick Wamuyu
Entity Relationship Model Constructs
Derived Attribute
Attribute that represents a value that is derivable from
value of a related attribute, or set of attributes, not
necessarily in the same entity type.
The value of Age can be determined from the
current date and the value of Birth_date.
Number_of_employees of a DEPARTMENT
entity can be derived by counting the number of
employees working for that department.

11:05 Dr. Patrick Wamuyu

Entity Relationship Model Constructs
An entity relationship model, also known as an
ERM, helps identify the database's main entities
and their relationships.
Because the ERM components are graphically
represented, their role is more easily understood.
Using the ER diagram, it’s easy to map the ERM to
the relational database model’s tables and
attributes.
This mapping process uses a series of well-defined
steps to generate all the required database
structures.
11:05 Dr. Patrick Wamuyu
Entity Relationship Model Constructs
A company purchases parts from suppliers and assembles
these parts into a variety of products. Information stored
about products includes a unique product number, a
product description, and a price. Information stored about
parts includes a unique part number and a part
description. Each product is assembled from many
different parts. Some parts are used more than once in the
same product. As a result, there is a need to keep track of
the quantity of each part found in each product. Suppliers
supply parts. Information stored about suppliers includes
a unique supplier number, supplier name, address, and
phone number.
Identify the entities, attributes and relationships
11:05 Dr. Patrick Wamuyu
Entity Relationship Model Constructs
In an E/R Diagram attributes may be drawn as ovals
Each attribute is linked to its entity by a line
The name of the attribute is written in the oval

11:05 Dr. Patrick Wamuyu

ER diagram of Staff and Branch entities
and their attributes

11:05 Dr. Patrick Wamuyu

 A composite attribute

An attribute
broken into
component parts

Entity with multivalued attribute (Skill)

and derived attribute (Years Employed)

Multivalued
an employee can have Derived
more than one skill from date
employed and
current date

11:05 Dr. Patrick Wamuyu

 Identifiers (Keys)
Identifier (Key)–an attribute (or combination of
attributes) that uniquely identifies individual
instances of an entity type
Candidate Key
Minimal set of attributes that uniquely identifies each
occurrence of an entity type.
Primary Key
Candidate key selected to uniquely identify each
occurrence of an entity type.
Composite Key
A candidate key that consists of two or more attributes.
11:05 Dr. Patrick Wamuyu
 Criteria for Identifiers
Choose Identifiers that
Will not change in value
Will not be null
Avoid intelligent identifiers (e.g., containing
locations or people that might change)
Substitute new, simple keys for long, composite
keys

11:05 Dr. Patrick Wamuyu

 Simple and composite identifier attributes

The identifier
is boldfaced
and
underlined

11:05 Dr. Patrick Wamuyu

Entity Relationship Model Constructs

11:05 Dr. Patrick Wamuyu

 Relationship types and instances

a) Relationship type
(Completes)

b) Relationship
instances

11:05 Dr. Patrick Wamuyu

 Degree of Relationships
Each entity in a relationship can
participate in zero, one, or more than
one instances of that relationship
Degree of a relationship is the number
of entity types that participate in it
Unary Relationship
Binary Relationship
Ternary Relationship
11:05 Dr. Patrick Wamuyu
 Degree of relationships

Entities of
One entity two different
related to types related Entities of three
another of to each other different types
the same
related to each
entity type
other
11:05 Dr. Patrick Wamuyu
Examples of relationships of different degrees
a) Unary relationships

PERSON

father of/

Recursive Relationships child of

Instances of entities may have relationships with other instances

of the same entity.
Common occurrences of these recursive relationships include
parent/child relationships:
11:05 Dr. Patrick Wamuyu
Examples of relationships of different degrees (cont.)
b) Binary relationships

11:05 Dr. Patrick Wamuyu

Examples of relationships of different degrees
c) Ternary relationship

Note: a relationship can have attributes of its own

11:05 Dr. Patrick Wamuyu
 Cardinality Constraints
Cardinality
Describes maximum number of possible relationship
occurrences for an entity participating in a given relationship
type.
Participation or Optionality
Determines whether all or only some entity occurrences
participate in a relationship.
“Optionality” expresses whether the relationship is optional or
mandatory.
As a relationship line is followed from an entity to another,
near the related entity two symbols will appear.
The first of those is the optionality indicator.
A circle (  ) indicates that the relationship is optional—the minimum
number of relationships between each instance of the first entity and
instances of the related entity is zero.
11:05 Dr. Patrick Wamuyu
 Cardinality Constraints
The second symbol indicates cardinality.
A stroke ( | ) indicates that the maximum number of
relationships is one.
A “crows-foot” ( ) indicates that many such
relationships between instances of the related entities
might exist.
E a c h in s t a n c e o f A is r e la t e d t o a m in im u m o f
A B
z e r o a n d a m a x im u m o f o n e in s t a n c e o f B

E a c h in s t a n c e o f B is r e la t e d t o a m in im u m o f
A B
o n e a n d a m a x im u m o f o n e in s t a n c e o f A

E a c h in s t a n c e o f A is r e la t e d t o a m in im u m o f
A B
o n e a n d a m a x im u m o f m a n y in s ta n c e s o f B

E a c h in s t a n c e o f B is r e la t e d t o a m in im u m o f
A B
z e r o a n d a m a x im u m o f m a n y in s t a n c e s o f A
11:05 Dr. Patrick Wamuyu
 Cardinality of Relationships
One-to-One
Each entity in the relationship will have exactly one related
entity
Each lecturer has a unique office
One-to-Many
An entity on one side of the relationship can have many related
entities, but an entity on the other side will have a maximum of
one related entity
Many-to-Many
Entities on both sides of the relationship can have many related
entities on the other side
Each student takes several modules, and each module is taken by
several students
11:05 Dr. Patrick Wamuyu
 Cardinality Constraints
Cardinality Constraints—the number of
instances of one entity that can or must be
associated with each instance of another entity
Minimum Cardinality
If zero, then optional
If one or more, then mandatory
Maximum Cardinality
The maximum number

11:05 Dr. Patrick Wamuyu

Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have recorded

recorded for one and only at least one history, and can
one patient have many
11:05 Dr. Patrick Wamuyu
Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be assigned An employee can be assigned

to at least one employee, to any number of projects, or
and may be assigned to may not be assigned to any
many at all
11:05 Dr. Patrick Wamuyu
Examples of cardinality constraints (cont.)

c) Optional cardinalities

A person is married
to at most one other
person, or may not
be married at all

11:05 Dr. Patrick Wamuyu

Cardinality constraints in a ternary relationship

11:05 Dr. Patrick Wamuyu

 Examples of multiple relationships

a) Employees and departments

Entities can be related to one another in more than one way

11:05 Dr. Patrick Wamuyu

Examples of multiple relationships (cont.)

b) Professors and courses (fixed lower limit constraint)

Here, min cardinality constraint is 2.

At least two professors must be qualified to teach each course.
Each professor must be qualified to teach at least one course.
11:05
Dr. Patrick Wamuyu
 Strong vs. Weak Entities, and
Identifying Relationships
Strong entity
Exists independently of other types of entities
Has its own unique identifier
Identifier underlined with single line
Weak entity
Dependent on a strong entity (identifying owner)…cannot exist
on its own
Does not have a unique identifier (only a partial identifier)
partial identifier underlined with double line
entity box has double line
Identifying relationship
Links strong entities to weak entities

11:05 Dr. Patrick Wamuyu

Example of a weak identity and its identifying relationship

Strong entity Weak entity

 Associative Entities
Many to many relationships are difficult to represent
We can split a many to many relationship into two one to
many relationships
An associative entity is a relationship transformed into
an entity
provides/
SUPPLIER PRODUCT
offered by

PROVIDES/
SUPPLIER PRODUCT
OFFERED BY

11:05 Dr. Patrick Wamuyu

 Associative Entities
Often many-to-many relationship types are resolved to two many-
to-one relationship types by inserting an intersection entity type.
This entity is the Associative entity
When should a relationship with attributes be an associative entity?
All relationships for the associative entity should be many
The associative entity could have meaning independent of the
other entities
The associative entity preferably has a unique identifier, and
should also have other attributes
The associative entity may participate in other relationships
other than the entities of the associated relationship
Ternary relationships should be converted to associative entities

11:05 Dr. Patrick Wamuyu

A binary relationship with an attribute on a relationship (Link Attribute/Associative)

Here, the date completed attribute pertains specifically to the employee’s completion
of a course…it is an attribute of the relationship

11:05 Dr. Patrick Wamuyu

An associative entity (CERTIFICATE)

Associative entity is like a relationship with an attribute, but it is

also considered to be an entity in its own right

Note that the many-to-many cardinality between entities has been

replaced by two one-to-many relationships with the associative
entity

11:05 Dr. Patrick Wamuyu

 An Example of an E-R Diagram

11:05 Dr. Patrick Wamuyu

 A Comparison of E-R modeling Symbols

11:05 Dr. Patrick Wamuyu

 Class Example
The Software House employs a number of programmers. Each
programmer is allocated with their own terminal and they work
on one or more systems at the same time. Each office within the
company can contain up to 10 terminals and each terminal has
its own operational manual as their specification is different.
Each office has a manager who is in charge of the programmers
in that office
a) Identify the main entity types for the company
b) Identify the main relationship types and specify the multiplicity for each
relationship. State any assumptions you make about data.
c) Using your answers for a. and b., draw a single ER diagram to represent
the data requirements for the company
d) Convert your ERD to a relational database schema
e) Implement it using SQL*Plus

11:05 Dr. Patrick Wamuyu

 Transforming ER Diagrams into
Relations
Mapping Regular Entities to Relations
1. Simple attributes: E-R attributes map directly onto
the relation
2. Composite attributes: Use only their simple,
component attributes
3. Multi-valued Attribute - Becomes a separate
relation with a foreign key taken from the superior
entity

11:05 Dr. Patrick Wamuyu

 (a) CUSTOMER entity type with
simple attributes

(b) CUSTOMER relation

11:05 Dr. Patrick Wamuyu

 (a) CUSTOMER entity type with
composite attribute

(b) CUSTOMER relation with address detail

11:05 Dr. Patrick Wamuyu

 Multivalued attribute becomes a
separate relation with foreign key

1 – to – many relationship between original

entity and new relation

11:05 Dr. Patrick Wamuyu

Transforming ER Diagrams into
Relations
Mapping Weak Entities
Becomes a separate relation with a foreign
key taken from the superior entity
Primary key composed of:
Partial identifier of weak entity
Primary key of identifying relation (strong entity)

11:05 Dr. Patrick Wamuyu

 NOTE: the domain constraint
for the foreign key should
NOT allow null value if
DEPENDENT is a weak
entity

11:05 Dr. Patrick Wamuyu

 Transforming ER Diagrams into
Relations
Mapping Binary Relationships
One-to-Many - Primary key on the one side becomes
a foreign key on the many side
Many-to-Many - Create a new relation with the
primary keys of the two entities as its primary key
One-to-One - Primary key on the mandatory side
becomes a foreign key on the optional side

11:05 Dr. Patrick Wamuyu

(a) Relationship
between customers
and orders

11:05 Dr. Patrick Wamuyu

 (a) ER diagram (M:N)

The Supplies relationship will need to become a separate relation

11:05 Dr. Patrick Wamuyu

 (b) Three resulting relations

Composite primary key

New
Foreign key intersection
relation
Foreign key

11:05 Dr. Patrick Wamuyu

 Transforming ER Diagrams into
Relations
Mapping Associative Entities
Identifier Not Assigned
Default primary key for the association relation is
composed of the primary keys of the two entities (as
in M:N relationship)
Identifier Assigned
It is natural and familiar to end-users
Default identifier may not be unique

11:05 Dr. Patrick Wamuyu

11:05 Dr. Patrick Wamuyu
 Problems with ER Models
Problems may arise when creating an ER model.
These problems are referred to as connection
traps, and normally occur due to a
misinterpretation of the meaning of certain
relationships.
The two main types of connection traps, called fan
traps and chasm traps, and illustrate how to
identify and resolve such problems in ER models

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Fan Traps
Where a model represents a relationship between entity
types, but the pathway between certain entity occurrences
is ambiguous.
A fan trap may exist where two or more 1:M relationships
fan out from the same entity.
A potential fan trap is illustrated on the Figure in the next
slide, which shows two 1:* relationships (Has and
Operates) emanating from the same entity called Division.

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Fan Traps
This model represents the facts that a single division operates
one or more branches and has one or more staff.
However, a problem arises when we want to know which
members of staff work at a particular branch.

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Chasm Traps
Where a model suggests the existence of a relationship between
entity types, but the pathway does not exist between certain
entity occurrences.
A chasm trap may occur where there are one or more
relationships with a minimum multiplicity of zero (that is,
optional participation) forming part of the pathway between
related entities.
A potential chasm trap is illustrated on the Figure in the next
slide, which shows relationships between the Branch, Staff, and
PropertyForRent entities.
This model represents the facts that a single branch has one or
more staff who oversee zero or more properties for rent. We also
note that not all staff oversee property, and not all properties are
overseen by a member of staff. A problem arises when we want
to know which properties are available at each branch.
11:05 Dr. Patrick Wamuyu
 Problems with ER Models
Chasm Traps
This model represents the facts that a single branch has one or
more staff who oversee zero or more properties for rent.
We also note that not all staff oversee property, and not all properties are
overseen by a member of staff.
A problem arises when we want to know which properties are available
at each branch.

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Chasm Traps
This model represents the facts that a single branch has one or
more staff who oversee zero or more properties for rent.
We also note that not all staff oversee property, and not all properties are
overseen by a member of staff.
A problem arises when we want to know which properties are available
at each branch.

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Implementation
Implementing Recursive Relationship
A recursive relationship is one in which a relationship
can exist between occurrences of the same entity set.
(Naturally, such a condition is found within a unary
relationship.)
For example, a 1:M unary relationship can be expressed by
“an EMPLOYEE may manage many EMPLOYEEs, and
each EMPLOYEE is managed by one EMPLOYEE.”
An M:N unary relationship can be expressed by “a course
requires a perquisite course” i.e. “COURSE requires
COURSE”

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Implementation
Implementing Recursive Relationship
For example, a 1:M unary relationship can be expressed by
“an EMPLOYEE may manage many EMPLOYEEs, and
each EMPLOYEE is managed by one EMPLOYEE.”
Implementation of the 1:M recursive relationship
“EMPLOYEE manages EMPLOYEE”

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Implementation
Implementing Recursive Relationship
The M:N recursive relationship might be more familiar in a
school environment.
Courses have Perquisites
M:N “COURSE requires COURSE” relationship
MATH-243 is a prerequisite to QM-261 and QM-362, while both MATH-
243 and QM-261 are prerequisites to QM-362.

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Implementation
Implementing Associative (Composite) Entities
Implementing the M:N relationship, particularly in the
relational model, requires the use of an additional
entity.
The ER model uses the associative entity to represent
an M:N relationship between two or more entities.
This associative entity, also called a composite or bridge
entity in a 1:M relationship with the parent entities and is
composed of the primary key attributes of each parent entity.,
is

11:05 Dr. Patrick Wamuyu

 Problems with ER Models
Implementation
Implementing Associative (Composite) Entities

11:05 Dr. Patrick Wamuyu

 Class Exercise 1
The Tuskys Ltd. operates many Supermarket Outlets. Each
Outlets is located in a Town. Each Town can be “home” to
many of Tuskys’ Outlets. Each Outlets employs many
employees, but each of those employees is employed by
only one Outlets.
a) Identify each relationship type and write all of the
business rules.
b) Create the basic Crow’s Foot ERD for Tuskys Ltd.

11:05 Dr. Patrick Wamuyu

 Class Exercise 2
A school has decided to start two sports teams for its students. The Sports teams are
categorized based on the type of sport and there are only two teams: cricket team,
football team. A student can join any one of these two sports teams. Each sports
team has a coach. There is always one coach appointed to supervise the other
coaches. Each student can be identified using id no., name and phone. The teams are
identified using team id, name and league status while the coach is identified by
coach id, name, address, salary and multiple certifications (CPR certification; First
aid certification, High School Coaches Diploma, etc.). The school also tracks
dependents of each coach for the school’s health insurance benefits. A dependent
must be associated with one and only one coach. Some coaches will not have
dependents, while others will have many dependents. For all dependents, dependent
number, first and last names and gender are recorded.
a) Identify the main entity types for the company
b) Identify the main relationship types and specify the multiplicity for each
relationship. State any assumptions you make about data.
c) Using your answers for a. and b., draw a single ER diagram to represent the
data requirements for the company
d) Convert your ERD to a relational database schema.
11:05 Dr. Patrick Wamuyu
 Class Exercise 3
A university consists of a number of departments.
Each department offers several majors. A number of
Courses make up each major. Students enroll in a
particular major and take courses towards the
completion of that major. Each course is taught by a
lecturer from the appropriate department, and each
lecturer tutors a group of students.
a) Identify the main entity types for the company
b) Identify the main relationship types and specify the multiplicity for each
relationship. State any assumptions you make about data.
c) Using your answers for a. and b., draw a single ER diagram to represent the
data requirements for the company
d) Convert your ERD to a relational database schema.
11:05 Dr. Patrick Wamuyu
 Review Questions
Describe what attributes represent in an ER model and
provide examples of simple, composite, multi-valued, and
derived attributes.
When is the concept of a weak entity used in data
modeling?
What is meant by recursive relationship type?
Give some examples
What is meant by Associative entity?
Give an example of an associative entity

11:05 Dr. Patrick Wamuyu