Entity Relationship

Diagram
 Database Design Strategies
 Two classical approaches to database design:

– Top-down design
• Identifies data sets
• Defines data elements for each of those sets
• Involves the identification of different entity types and the
definition of each entity's attributes
– Bottom-up design
• Identifies data elements (items)
• Groups them together in data sets
• First defines the attributes and then groups them to form
entities

6
Top-Down vs. Bottom-Up Design Steps

7
 Basic Modeling Concepts
 Part art and part science - good judgment coupled with powerful design
tools
 Models
– "a simplified representation of a system or phenomenon" http://
dictionary.reference.com/

 Data Model
– Relatively simple representation of complex real-world data
structure
 Entity Relationship (ER) Model
– Represents global view of data
– Main Components
• Entities – things we wish to record
• Attributes – properties of the things (entities), and
• Relationships – connections between entities
8
 The Entity Relationship (E-R) Model
 Purpose
– Design
• Model the 'real world' data providing a blueprint/map for the
'optimal' storage of the data within the DBMS
– Communication
• With managers, other designers
 Can be illustrated using many different notations
– Text uses Chen and Crow's Foot
– The important issue is the CONCEPTS, not the notation (you
should be able to easily swap notation)
– Many different diagram notations exist, we will use Crow's Foot

9
 Relationships
 Association between entities
 Connected entities are called participants
 Relationships between entities always operate in both directions
 Connectivity
– describes relationship classification
• 1:1
• 1:M
• M:N
 Cardinality
– expresses number of entity occurrences associated with one
occurrence of related entity

21
 Relationship Connectivity and Cardinality

Uses (Min,Max)
to express the
specific number
of entity
occurrences
associated with
one occurrence
of the related
entity

22
 The M:N Relationship
Between STUDENT and CLASS

Conceptual Model
(ERD)

Logical
Relational Model

Software tools modelling at the Logical level do not allow the

designer to draw M:N relations (two 1:M relationships must be used)
37
Crow's Foot Participation

In some variations of Crows Foot symbols (1,1) is shown as a single

crossing line to represent one and only one

30
Stage 1: Conceptual Model

Expressed via Entity

Relationship Diagram (ERD)
Sometimes non-key attributes
are also shown

Representation:
generalised, non
implementation model specific
(e.g., no FKs) and non DBMS
specific

10
Stage 2: Logical Model
Relational Logical
Model
Representation:
now specific to a
implementation model,
here Relational (FKs
have been added) but
not specific to a
particular DBMS (e.g.,
Oracle)
Expressed visually via
Extended Bachman
diagram (shown here)
or ERD like structures

11
 Stage 3: Physical Model
Expressed as a Or
DBMS Schema: Visually using ERD like structures:
CREATE TABLE CUSTOMER (
cust_no NUMBER(5) NOT NULL,
cust_family CHAR(20) NOT NULL,
cust_given CHAR(20) NOT NULL,
cust_street CHAR(20) NOT NULL,
cust_town CHAR(20) NOT NULL,
cust_postcode CHAR(4) NOT NULL,
cust_phone CHAR(10),
CONSTRAINT pk_CUSTOMER
PRIMARY KEY (cust_no)); …, etc.

Representation now specific to a particular relational

DBMS, here Oracle. Schema file can be run against
database to create table structures
12
 Model Levels: Stages 1, 2 and 3
 Some design methodologies have a strong separation of these
levels
 Many design methodologies combine the conceptual and logical into
a single level or view the stages in slightly different manners
– Text uses
• Conceptual – analogous to our conceptual, ER based
• Logical – in part closer to our physical level, text
identifies logical as DBMS dependent
• Physical – our physical level with strong hardware
specifics
 Commercially, design supported by CASE tools
– Understanding of the principles involved at each step is
essential, CASE (Computer-Aided Software Engineering) tool
is just a 'program'; any design produced must be verified by
designer
13
 Basic Building blocks
 Entities
– Each entity refers to the entity set and not to a single entity
occurrence (instance) eg. the 'set' of all students
– Each entity corresponds to a table and not to a row in the
relational environment
– In both the Chen and Crow's Foot models, an entity is
represented by a rectangle containing the entity's name
– Entity name, a noun, is usually written in capital letters and in
singular form - e.g., STUDENT not STUDENTS
 Attributes
– Characteristics of entities
– Domain is the set of all possible values
– Primary keys underlined

14
Attributes

Note: no PK has been selected/shown as yet

15
 Types of Attributes
 Simple  Multi-valued
– Cannot be subdivided – Can have many values
– Age, sex, marital status – Person may have several
university (or college)
 Composite
degrees
– Can be subdivided into
additional attributes  Derived
– Address into street, city,
postcode (or zip) – Can be derived with
algorithm
 Single-valued – Age can be derived from
– Can have only a single date of birth
value
– Person has one social
security number
16
A Multivalued Attribute in an Entity

17
 Resolving Multivalued Attribute Problems
 Although the conceptual model can depict multivalued attributes, you
cannot implement them directly in the relational model. Instead we can:
– Within original entity, create several new attributes, one for each
of the original multivalued attribute's components
• Can lead to major structural problems in the table
– Or better, create a new entity composed of original multivalued
attribute's components

18
Derived Attribute

19
Derived Attribute continued

20
 Existence Dependence
 Existence dependence
– An entity exists in a database only when it is associated with
another related entity occurrence
• e.g., CUSTOMER places ORDER
 Existence independence
– Entity can exist apart from one or more related entities
– Sometimes refers to such an entity as strong or regular entity
 Many (most) entities on an ER are existence dependant

23
 Relationship Strength
 Weak (non-identifying) relationships
– Exists if PK of related entity does not contain
PK component of parent entity

 Strong (Identifying) Relationships

– Exists when PK of related entity contains PK
component of parent entity

24
A Weak (Non-Identifying) Relationship

25
A Strong (Identifying) Relationship

26
 Weak Entities
 A weak entity meets two conditions
– Existence-dependent
• Cannot exist without entity with which it has a
relationship
– Strong Relationship exists between entity and parent
• Child (weak entity) has primary key that is partially or
totally derived from parent entity in relationship
 Database designer usually determines whether an entity
can be described as weak based on business rules
– customer pays monthly account
• PK payment_no, or
• PK cust_no, date_paid

27
A Weak Entity in an ERD

28
Three Types of Relationships

33
 Recursive Relationships
 Relationship can exist between occurrences of the same entity set
 Naturally found within a unary relationship

34
 Specialisation and Generalisation
 Specialisation
– Top-down process of identifying lower-level, more specific entity
subtypes from higher-level entity supertype
– Based on grouping unique characteristics and relationships of the
subtypes
 Generalisation
– Bottom-up process of identifying higher-level, more generic entity
supertype from lower-level entity subtypes
– Based on grouping common characteristics and relationships of
the subtypes

39
A Specialisation Hierarchy

42
 Database Implementation
 Inheritance enables entity subtype to inherit attributes and
relationships of supertype
 All entity subtypes inherit their primary key attribute from their
supertype
 At implementation level, supertype and its subtype(s) depicted
in specialization hierarchy maintain a 1:1 relationship

43
 Disjoint and Overlapping Subtypes
 Disjoint subtypes
– Also known as non-overlapping subtypes
– Subtypes that contain unique subset of supertype entity set

 Overlapping subtypes
– Subtypes that contain non-unique subsets of supertype entity set

44
A Specialisation Hierarchy with Overlapping
Subtypes

45
 Developing an E-R Diagram
 Iterative Process
1. List the major entities in the system.
2. Represent the entities graphically by a rectangle.
3. Search for relationships between the entities and represent
them graphically with the proper symbol (e.g., a diamond if
Chen’s notation is used). Determine if there are supertype and
subtype relationships between entities.
4. Add primary key for every entity (sometimes non-primary key
attributes also shown on ERD).
5. Model relationship connectivity between each pair of entities.

46
 Developing an E-R Diagram (cont’d)
 Iterative Process

6. Model relationship cardinalities between each pair of entities

(i.e. the minimum and maximum participation).
7. Determine if composite entities are to be created. If required,
refine the connectivity and cardinality of entities affected.
8. Verify the ERD you have created by going through each
component you have created from Steps (1) to (7). Ensure that
they properly represent the business rules of the system you
are developing the database for. Repeat this process until your
ER diagram is complete.

47