Database

Management
DATABASE DESIGN AND ER
MODELING
 Overview of Database Design Process
Conceptual Data Model
Data Modeling and SDLC
The Conceptual Data Modeling Process
Overview of Database Design Process
ER Model Concepts
Contents
Types of Attributes (1)
Entity Types and Key Attributes (1)
Recursive Relationship Type
Cardinalities in Relationships
Conceptual Data Modeling and the E-R Model
References
Overview of Database Design Process
Two main activities:
◦ Database design
◦ Applications design
Conceptual database design
◦ To design the conceptual schema for a database
application
Applications design focuses on the programs and
interfaces that access the database
◦ Generally considered part of software engineering
Conceptual Data Model
➢Detailed data model that captures the overall
structure of data in an organization
➢Independent of any DBMS or other
implementation considerations
Data Modeling and SDLC
The Conceptual Data Modeling
Process
■Develop a data model for the current system.
■Develop a new conceptual data model that
includes all requirements of the new system.
■Develop an ER model with attributes in the
Analysis phase
■The conceptual data model is translated into a
logical data model and physical design in the
Design phase

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 6

Overview of Database Design Process
Example COMPANY Database
We need to create a database schema design based on the following
(simplified) requirements of the COMPANY Database:
◦ The company is organized into DEPARTMENTs. Each department has a name,
number and an employee who manages the department. We keep track of
the start date of the department manager. A department may have several
locations.
◦ Each department controls a number of PROJECTs. Each project has a unique
name, unique number and is located at a single location.
 Example COMPANY Database
(Continued)
◦ The database will store each EMPLOYEE’s social security number,
address, salary, sex, and birthdate.
◦ Each employee works for one department but may work on several projects.
◦ The DB will keep track of the number of hours per week that an employee currently
works on each project.
◦ It is required to keep track of the direct supervisor of each employee.
◦ Each employee may have a number of DEPENDENTs.
◦ For each dependent, the DB keeps a record of name, sex, birthdate, and relationship
to the employee.
ER Model Concepts
Entities and Attributes
◦ Entity is a basic concept for the ER model. Entities are specific
things or objects in the mini-world that are represented in the
database.
◦ For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT
◦ Attributes are properties used to describe an entity.
◦ For example an EMPLOYEE entity may have the attributes Name,
SSN, Address, Sex, BirthDate
◦ A specific entity will have a value for each of its attributes.
◦ For example a specific employee entity may have Name='John
Smith', SSN='123456789', Address ='731, Fondren, Houston, TX',
Sex='M', BirthDate='09-JAN-55‘
◦ Each attribute has a value set (or data type) associated with it –
e.g. integer, string, date, enumerated type, …
Types of Attributes (1)
Simple
◦ Each entity has a single atomic value for the attribute. For example, SSN
or Sex.
Composite
◦ The attribute may be composed of several components. For example:
◦ Address(Apt#, House#, Street, City, State, ZipCode, Country), or
◦ Name(FirstName, MiddleName, LastName).
◦ Composition may form a hierarchy where some components are
themselves composite.
Multi-valued
◦ An entity may have multiple values for that attribute. For example, Color
of a CAR or PreviousDegrees of a STUDENT.
◦ Denoted as {Color} or {PreviousDegrees}.
Types of Attributes (2)
In general, composite and multi-valued attributes may be nested
arbitrarily to any number of levels, although this is rare.
◦ For example, PreviousDegrees of a STUDENT is a composite multi-valued
attribute denoted by {PreviousDegrees (College, Year, Degree, Field)}
◦ Multiple PreviousDegrees values can exist
◦ Each has four subcomponent attributes:
◦ College, Year, Degree, Field
Example of a composite
attribute
Entity Types and Key
Attributes (1)
Entities with the same basic attributes are
grouped or typed into an entity type.
◦ For example, the entity type EMPLOYEE and
PROJECT.
An attribute of an entity type for which each
entity must have a unique value is called a
key attribute of the entity type.
◦ For example, SSN of EMPLOYEE.
Displaying an Entity type
In ER diagrams, an entity type is displayed in a rectangular box
Attributes are displayed in ovals
◦ Each attribute is connected to its entity type
◦ Components of a composite attribute are connected to the oval representing
the composite attribute
◦ Each key attribute is underlined
◦ Multivalued attributes displayed in double ovals
Entity Types and Key
Attributes (2)
A key attribute may be composite.
◦ VehicleTagNumber is a key of the CAR entity type
with components (Number, State).
An entity type may have more than one key.
◦ The CAR entity type may have two keys:
◦ VehicleIdentificationNumber (popularly called VIN)
◦ VehicleTagNumber (Number, State), aka license plate number.

Each key is underlined (Note: this is different from the relational schema
where only one “primary key is underlined).
Value Sets (Domains) of
Attributes
Each simple attribute is associated with a value set
◦ E.g., Lastname has a value which is a character string of
upto 15 characters, say
◦ Date has a value consisting of MM-DD-YYYY where each
letter is an integer
A value set specifies the set of values associated
with an attribute
Entity Type CAR with two keys and a
corresponding Entity Set
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Refining the COMPANY database schema by
introducing relationships
By examining the requirements, six relationship types are
identified
All are binary relationships( degree 2)
Listed below with their participating entity types:
◦ WORKS_FOR (between EMPLOYEE, DEPARTMENT)
◦ MANAGES (also between EMPLOYEE, DEPARTMENT)
◦ CONTROLS (between DEPARTMENT, PROJECT)
◦ WORKS_ON (between EMPLOYEE, PROJECT)
◦ SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
◦ DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
Constraints on Relationships
Constraints on Relationship Types
◦ (Also known as ratio constraints)
◦ Cardinality Ratio (specifies maximum participation)
◦ One-to-one (1:1)
◦ One-to-many (1:N) or Many-to-one (N:1)
◦ Many-to-many (M:N)
◦ Existence Dependency Constraint (specifies minimum
participation) (also called participation constraint)
◦ zero (optional participation, not existence-dependent)
◦ one or more (mandatory participation, existence-dependent)
Many-to-one (N:1) Relationship
Many-to-many (M:N) Relationship
Recursive Relationship Type
A relationship type between the same participating entity type in
distinct roles
Also called a self-referencing relationship type.
Example: the SUPERVISION relationship
EMPLOYEE participates twice in two distinct roles:
◦ supervisor (or boss) role
◦ supervisee (or subordinate) role
Each relationship instance relates two distinct EMPLOYEE entities:
◦ One employee in supervisor role
◦ One employee in supervisee role
Displaying a recursive relationship
In a recursive relationship type.
◦ Both participations are same entity type in
different roles.
◦ For example, SUPERVISION relationships
between EMPLOYEE (in role of supervisor or
boss) and (another) EMPLOYEE (in role of
subordinate or worker).
In following figure, first role participation labeled with 1 and second role
participation labeled with 2.
In ER diagram, need to display role names to distinguish participations.

Slide 3- 26
A Recursive Relationship Supervision`
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)
Introduction to Entity-
Relationship (E-R) Modeling

■The E-R model is expressed in terms of:

◻Data entities in the business environment.
◻Relationships or associations among those
entities.
◻Attributes or properties of both the entities and
their relationships.
Introduction to E-R Modeling
(Cont.)

■Entity: a person, place, object, event or

concept in the user environment about
which data is to be maintained
■Entity type: collection of entities that
share common properties or characteristics
■Entity instance: single occurrence of an
entity type

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 30

Relationships

■Relationship: an association between the

instances of one or more entity types that is
of interest to the organization
■Degree: the number of entity types that
participate in a relationship
 Figure 8-10
Relationship type and
instances
(a) Relationship type
(Completes)
(b) Relationship
instances

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 32

Cardinalities in Relationships
■Cardinality: the number of instances of
entity B that can (or must) be associated
with each instance of entity A
■Minimum Cardinality
◻The minimum number of instances of entity B that
may be associated with each instance of entity A
■Maximum Cardinality
◻The maximum number of instances of entity B
that may be associated with each instance of
entity A

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 33

Cardinalities in Relationships
(Cont.)
■Mandatory vs. Optional Cardinalities
◻Specifies whether an instance must exist or can
be absent in the relationship

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 34

Sample conceptual data model
 FIGURE 8-14 Examples of cardinality constraints

(a) Mandatory cardinalities

(b) One optional, one mandatory cardinality

(c) Optional cardinalities

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 36
Conceptual Data Modeling and
the E-R Model

■Unary relationship: a relationship between the

instances of one entity type
◻Also called a recursive relationship
■Binary relationship: a relationship between
instances of two entity types
◻Most common type of relationship encountered in data
modeling
■Ternary relationship: a simultaneous relationship
among instances of three entity types

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 37

 Unary relationships

Binary relationships

FIGURE 8-11
Examples of relationships of different
Ternary relationships degrees

Chapter 8 © 2014 Pearson Education, Inc. Publishing as Prentice Hall 38

Logical Design
Logical Database Design
• The process of deciding how to arrange the attributes of
the entities in the business environment into database
structures, such as the tables of a relational database.
• The goal is to create well structured tables that properly
reflect the company’s business environment.

39
Data Modeling
Data Modeling is a creative, dynamic and evolving
process for:
◦ Exploring the different ways that entities can
relate to each other as they would in the real
world
◦ Recording or drawing entities as they would
behave in a business environment

40
Data Modeling Notations:
A set of symbols used to
construct the ERD
There are many different
notations available but they
all communicate the same
idea
We will follow Barker’s
notation in this course

41
The Entity Relationship (E-R)
Model:
◦ Is a diagramming technique best known as ERD
◦ Is a series of Diagrams listing entities (with
attributes) and the relationships between
entities
◦ Is subject to many variations of representing
entities and relationships

42
The Entity Relationship (E-R)
Model:
An entity is drawn as a
rounded rectangle
Entity’s name appears singular - at
top - in capital letters
Entity’s attributes are
shown below its Name
The primary key attribute is
indicated by a solid underline

43
Relationships:
• The process of connecting any two entities in a
data model.
• The Associations between entities to enforce
Business Rules or Organizational Policies
• Different kinds:
◦ Binary relationships
◦ Unary relationships
◦ Ternary relationships

44
Binary Relationships

Simplest kind of relationship

Relationship between two entity types
A salesperson “sells” products
A product “sold by” by salespersons

45
 Relationships
▪ 1-1 (1:1)
▪ A single occurrence of one entity type can be associated with a
single occurrence of the other entity type and vice versa
▪ 1-M or M-1 (1:M, M:1)
▪ Use “Barker’s Notation” to represent the multiple association
▪ “many” = the maximum number of occurrences that can be
involved; means a number that can be: 1,2...N
▪ Sometimes the “M” can be represented by “N”
▪ M-N (M:N)
▪ “many” can be either an exact number or have a known
maximum
▪ Sometimes the “M” can be represented by “N”

46
 C.Cardinality in Relationships:

Cardinality specifies how many instances of an entity relate

to one instance of another entity.
(“outer” symbol is cardinality)

47
Ordinality in Relationships
▪Ordinality ( = Modality = Optionality )
▪ The minimum number of entity occurrences that can be
involved in a relationship.
▪ “inner” symbol on E-R diagram
▪Mandatory relationship: each instance from an entity
must be related to another instance.
▪ Represented by a straight line
▪Optional Relationship each instance from an entity may be
related to another instance
▪ Represented by a dashed line

48
C.Cardinality and Ordinality in
Relationships:
▪ Ordinality is closely coupled with Cardinality.
▪ While Cardinality specifies the occurrences of a
relationship, Ordinality describes the relationship as
either mandatory or optional.
▪ Cardinality specifies the maximum number of
occurrences.
▪ Ordinality specifies the absolute minimum number of
occurrences.
▪ When the minimum number is zero, the relationship is
usually called optional and when the minimum
number is one or more, the relationship is usually
called mandatory.
49
Relationships: One to many

Each SALESPERSON must sell to one or many CUSTOMERs

Each CUSTOMER must buy from one SALESPERSON

50
 Relationships: many to many

Each SALESPERSON must sell one or many PRODUCTs

Each PRODUCT must be sold by one or many SALESPERSONs

51
C.Relationships: one to one –
in action:

Each SALESPERSON must work in one OFFICE

Each OFFICE may be occupied by one SALESPERSON

52
Relationships Explained

53
 References
1. Fundamentals of Database Systems, Seventh
Edition, Elmasri and Navathe(Copyright@ 2017)
2. Modern Systems Analysis and Design, Seventh
Edition. Jeffrey A. Hoffer Joey F. George Joseph
S. Valacich, Chap 8