5/28/2021

Data Modeling Using the

Entity-Relationship (ER) Model
 Entity-Relationship (ER) model
 Popular high-level conceptual data model
Chapter 3  used to define the data elements and relationship for
a specified system. It develops a conceptual design
Database Modeling for the database. It also develops a very simple and
easy to design view of data
 ER diagrams
 Diagrammatic notation associated with the ER
model

Using High-Level Conceptual Data Models for Database

Design
ER model
 Requirements collection and analysis
 ER model describes data as:
 Database designers interview prospective database users to
understand and document data requirements  Entities
 Result: data requirements, Functional requirements of the  Relationships
application
 Attributes
 Conceptual schema: Conceptual design. Description of data requirements
 Includes detailed descriptions of the entity types, relationships, and  A Sample Database Application
constraints  COMPANY
 Transformed from high-level data model into implementation data model • Employees, departments, and projects
 Logical design or data model mapping • Company is organized into departments
 Result is a database schema in implementation data model of DBMS • Department controls a number of projects
 Physical design phase • Employee: store each employee’s name, Social Security
 Internal storage structures, file organizations, indexes, access paths, number, address, salary, sex (gender), and birth date
and physical design parameters for the database files specified • Keep track of the dependents of each employee

Entities and Attributes

 Entity: Thing in real world with independent existence
 People: staff, clients/customers, patients, members, owners,
contacts, other individuals,
 Objects: stock items, real estate, offices, . . .
 Organisations: firms (suppliers or customers), departments,
charities, clubs, committees,
 Object classes: recordings, films, books, types of stock, biological
species, work roles,
 Events: concerts, examinations, lecture courses, consultations,
sales, . . .
 Entities are specific objects or things in the mini-world that are
represented in the database.
• For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT

1

Entities and Attributes (cont..)
 Attributes: Particular properties that describe entity
 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, subrange, enumerated type, …
 Types of attributes:
• Composite versus simple (atomic) attributes
• Single-valued versus multivalued attributes
• Stored versus derived attributes
• NULL values
• Complex attributes
Types of Attributes … Cont’d
Stored Vs. Derived Attribute:
Stored : not possible to derive or compute E.g. Name, Address
 Derived: The value may be derived (computed) from the values of other attributes.
E.g. Age (current year – year of birth), Length of employment (current date-
start date), Profit (earning-cost) , G.P.A (grade point/credit hours)
Null Values
NULL applies to attributes which are not applicable or which do not have values.
You may enter the value NA (meaning not applicable)
Value of a key attribute can not be null.
Default value - assumed value if no explicit value
Entity Types, Entity Sets, Keys, and Value Sets
 Entity type
 Collection (or set) of entities that have the same attributes.
 Is the category to which the entity belongs
 Entity Set: Each entity type will have a collection of entities
stored in the database
 Is the current state of the entities of that type that are stored in
the database. The complete data set of all entities is called
the entity set. In the above table, the entity set consists of
all the records
5/28/2021
Types of Attributes (1)
 Composite Vs. simple (atomic) attributes
 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.
 Composite attributes can be divided into subparts. For example, an
attribute name could be structured as a composite attribute consisting of first-name,
middle-initial, and last-name.
 Single-valued Vs. multivalued attributes
 Multi-valued: An entity may have multiple values for that attribute. have more than
one value. For example: Color of a CAR or PreviousDegrees of a STUDENT, Denoted as {Color}
or {PreviousDegrees}, Address, dependent-name
• Person may have several college degrees
 Instances where an attribute has a set of values for a specific entity. Consider an employee
entity set with the attribute phone-number. An employee may have zero, one, or several
phone numbers, and different employees may have different numbers of phones.
 Single-valued : have only single value(the value may change but has only one value at one
time)
E.g. Name, Sex, Id. No. color_of_eyes
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
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.
 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
2
 5/28/2021

Displaying an Entity type

Entity Type CAR with two keys and a corresponding
 In ER diagrams, an entity type is displayed in a rectangular Entity Set

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

 See CAR example on next slide

Initial Design of Entity Types for the Initial Design of Entity Types:
COMPANY Database Schema EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

 Based on the requirements, we can identify four

initial entity types in the COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT
 Their initial design is shown on the following slide
 The initial attributes shown are derived from the
requirements description

Entity Types, Entity Sets, Keys, and Value Sets (cont’d.)

Relationship Types, Relationship Sets, Roles,
 Key or uniqueness constraint
and Structural Constraints
 Attributes whose values are distinct for each individual entity
in entity set  Relationship
 Key attribute  When an attribute of one entity type refers to another
entity type
• Uniqueness property must hold for every entity set of the
entity type  Represent references as relationships not attributes

 Value sets (or domain of values)
 Specifies set of values that may be assigned to that attribute
for each individual entity
 Some aspects in the requirements will be represented as
relationships
 ER model has three main concepts:
 Entities (and their entity types and entity sets)
 Attributes (simple, composite, multivalued)
 Relationships (and their relationship types and
relationship sets)

3
 5/28/2021

Relationship instances of the WORKS_FOR N:1 relationship between

EMPLOYEE and DEPARTMENT and M:N between EMPLOYEE and
Relationships and Relationship Types (1) PROJET

 A relationship relates two or more distinct entities with a

specific meaning.
 For example, EMPLOYEE John Smith works on the ProductX
PROJECT, or EMPLOYEE Abebe Alemu manages the
Research DEPARTMENT.
 Relationships of the same type are grouped or typed into
a relationship type.
 For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and DEPARTMENTs
participate.
 The degree of a relationship type is the number of
participating entity types.
 Both MANAGES and WORKS_ON are binary relationships.

Relationship type vs. relationship set (1)

 Relationship Type: Is the schema description of a relationship
 Identifies the relationship name, the participating entity types and
certain relationship constraints
 Relationship Set: The current set of relationship instances
represented in the database
 The current state of a relationship type
 Previous figures displayed the relationship sets
 Each instance in the set relates individual participating entities –
one from each participating entity type
 In ER diagrams, we represent the relationship type as follows:
 Diamond-shaped box is used to display a relationship type
 Connected to the participating entity types via straight lines
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: Discussion on Relationship

WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Types
 In the refined design, some attributes from the initial entity
types are refined into relationships:
 Manager of DEPARTMENT -> MANAGES
 Works_on of EMPLOYEE -> WORKS_ON
 Department of EMPLOYEE -> WORKS_FOR
 etc
 In general, more than one relationship type can exist
between the same participating entity types
 MANAGES and WORKS_FOR are distinct relationship
types between EMPLOYEE and DEPARTMENT
 Different meanings and different relationship instances.

4
 5/28/2021

Recursive Relationship Type Weak Entity Types

 An relationship type whose with the same participating
entity type in distinct roles
 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
 An entity that does not have a key attribute
 A weak entity must participate in an identifying relationship type
with an owner or identifying entity type
 Entities are identified by the combination of:
 A partial key of the weak entity type
 The particular entity they are related to in the identifying
entity type
 Example:
 A DEPENDENT entity is identified by the dependent’s first
name, and the specific EMPLOYEE with whom the
dependent is related
 Name of DEPENDENT is the partial key

 One employee in supervisee role  DEPENDENT is a weak entity type

 EMPLOYEE is its identifying entity type via the identifying
relationship type DEPENDENT_OF

Constraints on Relationships Many-to-one (N:1)

Many-to-many (M:N)
Relationship
Relationship
 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)

Recursive Relationship Type is: SUPERVISION

Displaying a recursive relationship (participation role names are shown)

 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.

5
 5/28/2021

Attributes of Relationship types Example Attribute of a Relationship Type:

Hours of WORKS_ON
 A relationship type can have attributes:

 For example, HoursPerWeek of WORKS_ON

 Its value for each relationship instance describes the number

of hours per week that an EMPLOYEE works on a PROJECT.

• A value of HoursPerWeek depends on a particular

(employee, project) combination

 Most relationship attributes are used with M:N relationships

• In 1:N relationships, they can be transferred to the entity

type on the N-side of the relationship

Alternative (min, max) notation for relationship

Notation for Constraints on Relationships
 Cardinality ratio (of a binary relationship):
 1:1, 1:N, N:1, or M:N
 Shown by placing appropriate numbers on the relationship
edges.
 Participation constraint (on each participating entity type): total
(called existence dependency) or partial.
 Total shown by double line, partial by single line.
 NOTE: These are easy to specify for Binary Relationship Types.
structural constraints:
 Specified on each participation of an entity type E in a relationship type R
 Specifies that each entity e in E participates in at least min and at most
max relationship instances in R
 Default(no constraint): min=0, max=n (signifying no limit)
 Must have minmax, min0, max 1
 Derived from the knowledge of mini-world constraints
 Examples:
 A department has exactly one manager and an employee can manage
at most one department.
• Specify (0,1) for participation of EMPLOYEE in MANAGES
• Specify (1,1) for participation of DEPARTMENT in MANAGES
 An employee can work for exactly one department but a department
can have any number of employees.
• Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
• Specify (0,n) for participation of DEPARTMENT in WORKS_FOR

The (min,max) notation for relationship constraints COMPANY ER Schema Diagram using (min, max)
notation

Read the min,max numbers next to the entity type and looking away from the entity type

6
 5/28/2021

Relationship Degree..Cont.
Relationship Degree
Another important point about relationship is the range of instances that can be
Related entities require setting of LINKS from one part of the database to associated with a single instance from one entity in a single relationship.
another. The number of instances participating or associated with a single instance from
A relationship should be named by a word or phrase which explains its another entity in a relationship is called the CARDINALITY of the relationship.
function ONE-TO-ONE, e.g. Building - Location,
Role names are different from the names of entities forming the relationship:
ONE-TO-MANY, e.g. hospital - patient,
one entity may take on many roles, the same role may be played by different
MANY-TO-ONE, e.g. Employee - Department
entities.
MANY-TO-MANY, e.g. Author - Book.
An important point about a relationship is how many entities participate in it.
The number of entities participating in a relationship is called the DEGREE of
the relationship type.
UNARY/RECURSIVE RELATIONSHIP: Single entity
BINARY RELATIONSHIPS: Two entities associated
TERNARY RELATIONSHIP: Three entities associated
N-NARY RELATIONSHIP: arbitrary number of entity sets

Role Names and Recursive Relationships ER Diagrams, Naming Conventions, and

 Role names and recursive relationships Design Issues
 Role name signifies role that a participating entity
plays in each relationship instance
 Recursive relationships
 Same entity type participates more than once in a
relationship type in different roles
 Must specify role name

The Enhanced Entity-Relationship (EER) Model Subclasses, Superclasses, and Inheritance

 Enhanced ER (EER) model  Enhanced ER or EER diagrams
 Diagrammatic technique for displaying these concepts in an EER
 Created to design more accurate database schemas schema
• Reflect the data properties and constraints more precisely  Subtype or subclass of an entity type
 Subgroupings of entities that are meaningful
 More complex requirements than traditional applications
 Represented explicitly because of their significance to the database
 EER model includes all modeling concepts of the ER model application
 In addition, EER includes:  Terms for relationship between a superclass and any one of its
subclasses
 Subclasses and superclasses  Superclass/subclass
 Specialization and generalization  Supertype/subtype
 Class/subclass relationship
 Category or union type
 Type inheritance
 Attribute and relationship inheritance  Subclass entity inherits all attributes and relationships of superclass

7
 5/28/2021

Subclasses and Superclasses (1)

 An entity type may have additional meaningful subgroupings of
its entities
 Example: EMPLOYEE may be further grouped into:
• SECRETARY, ENGINEER, TECHNICIAN, …
• Based on the EMPLOYEE’s Job
• MANAGER
• EMPLOYEEs who are managers
• SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
• Based on the EMPLOYEE’s method of pay
 EER diagrams extend ER diagrams to represent these additional
subgroupings, called subclasses or subtypes

Subclasses and Superclasses (2)

 Each of these subgroupings is a subset of EMPLOYEE entities Subclasses and Superclasses (4)
 Each is called a subclass of EMPLOYEE
 EMPLOYEE is the superclass for each of these subclasses
 Examples:
 These are called superclass/subclass relationships:
 A salaried employee who is also an engineer belongs to the
 EMPLOYEE/SECRETARY two subclasses:
 EMPLOYEE/TECHNICIAN • ENGINEER, and
 EMPLOYEE/MANAGER • SALARIED_EMPLOYEE
 These are also called IS-A relationships  A salaried employee who is also an engineering manager
 SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, …. belongs to the three subclasses:
 Note: An entity that is member of a subclass represents the same real- • MANAGER,
world entity as some member of the superclass: • ENGINEER, and
 The subclass member is the same entity in a distinct specific role
• SALARIED_EMPLOYEE
 An entity cannot exist in the database merely by being a member of a
subclass; it must also be a member of the superclass  It is not necessary that every entity in a superclass be a
 A member of the superclass can be optionally included as a member of member of some subclass
any number of its subclasses

Representing Specialization in EER Diagrams Attribute Inheritance in Superclass / Subclass Relationships

 An entity that is member of a subclass inherits
 All attributes of the entity as a member of the superclass
 All relationships of the entity as a member of the superclass
 Example:
 In the previous slide, SECRETARY (as well as TECHNICIAN
and ENGINEER) inherit the attributes Name, SSN, …, from
EMPLOYEE
 Every SECRETARY entity will have values for the inherited
attributes

8

Specialization (1)
 Specialization is the process of defining a set of subclasses of a
superclass
 The set of subclasses is based upon some distinguishing characteristics of
the entities in the superclass
 Example: {SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of EMPLOYEE based upon job type.
• May have several specializations of the same superclass
 Example: Another specialization of EMPLOYEE based on method of pay
is {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.
 Superclass/subclass relationships and specialization can be
diagrammatically represented in EER diagrams
 Attributes of a subclass are called specific or local attributes.
• For example, the attribute TypingSpeed of SECRETARY
 The subclass can also participate in specific relationship types.
• For example, a relationship BELONGS_TO of
HOURLY_EMPLOYEE
Displaying an attribute-defined specialization in EER
diagrams
5/28/2021
Specialization and Generalization
 Specialization: Process of defining a set of subclasses of an entity type
 Defined on the basis of some distinguishing characteristic of the
entities in the superclass
 Subclass can define: Specific attributes and Specific relationship
types
 Certain attributes may apply to some but not all entities of the
superclass
 Some relationship types may be participated in only by members of the
subclass
 Generalization
 Reverse process of abstraction
 Generalize into a single superclass
• Original entity types are special subclasses
 Generalization: Process of defining a generalized entity type from
the given entity types
Constraints and Characteristics of Specialization and
Generalization Hierarchies
 Constraints that apply to a single specialization or a single generalization
 Differences between specialization/ generalization lattices and hierarchies
 If we can determine exactly those entities that will become members of each
subclass by a condition, the subclasses are called predicate-defined (or
condition-defined) subclasses
 Condition is a constraint that determines subclass members
 Display a predicate-defined subclass by writing the predicate condition
next to the line attaching the subclass to its superclass
 If all subclasses in a specialization have membership condition on same
attribute of the superclass, specialization is called an attribute-defined
specialization
 Attribute is called the defining attribute of the specialization
 Example: JobType is the defining attribute of the specialization
{SECRETARY, TECHNICIAN, ENGINEER} of EMPLOYEE
 If no condition determines membership, the subclass is called user-defined
 Membership in a subclass is determined by the database users by
applying an operation to add an entity to the subclass
 Membership in the subclass is specified individually for each entity in the
superclass by the user
Constraints on Specialization and Generalization (3)
 Two basic constraints can apply to a
specialization/generalization:
 Disjointness Constraint:
 Completeness Constraint:
 Disjointness Constraint:
 Specifies that the subclasses of the specialization must be
disjoint:
• an entity can be a member of at most one of the
subclasses of the specialization
 Specified by d in EER diagram
 If not disjoint, specialization is overlapping:
• that is the same entity may be a member of more than one
subclass of the specialization
 Specified by o in EER diagram
9

Constraints on Specialization and Generalization (5)
 Completeness Constraint:
 Total specifies that every entity in the superclass must be a
member of some subclass in the specialization/generalization
 Shown in EER diagrams by a double line
 Partial allows an entity not to belong to any of the subclasses
 Shown in EER diagrams by a single line
 Hence, we have four types of specialization/generalization:
 Disjoint, total
 Disjoint, partial
 Overlapping, total
 Overlapping, partial
 Note: Generalization usually is total because the superclass is derived
from the subclasses.
Specialization/Generalization Hierarchies, Lattices &
Shared Subclasses (1)
 A subclass may itself have further subclasses specified on it
 forms a hierarchy or a lattice
 Hierarchy has a constraint that every subclass has only one superclass
(called single inheritance); this is basically a tree structure
 In a lattice, a subclass can be subclass of more than one superclass
(called multiple inheritance)
Shared Subclass “Engineering_Manager”
Specialization / Generalization Lattice Example (UNIVERSITY)
5/28/2021
Example of disjoint partial Specialization
Example of overlapping total Specialization
Specialization/Generalization Hierarchies, Lattices &
Shared Subclasses (2)
 In a lattice or hierarchy, a subclass inherits attributes not only of its direct
superclass, but also of all its predecessor superclasses
 A subclass with more than one superclass is called a shared subclass
(multiple inheritance). Can have:
 specialization hierarchies or lattices, or
 generalization hierarchies or lattices,
 depending on how they were derived
 We just use specialization (to stand for the end result of either specialization
or generalization)
 In specialization, start with an entity type and then define subclasses of the
entity type by successive specialization
 called a top down conceptual refinement process
 In generalization, start with many entity types and generalize those that have
common properties
 Called a bottom up conceptual synthesis process
 In practice, a combination of both processes is usually employed
Relational Database Design by ER- and EER-to-
Relational Mapping
Relational Database Design Using ER-to-Relational Mapping:
10
 5/28/2021

ER-to-Relational Mapping Algorithm

 Step 1: Mapping of Regular Entity Types: For each regular (strong) entity type
E in the ER schema, create a relation R that includes all the simple attributes of
E.
 Choose one of the key attributes of E as the primary key for R.
 If the chosen key of E is composite, the set of simple attributes that form it
will together form the primary key of R.
 Example: We create the relations EMPLOYEE, DEPARTMENT, and PROJECT
in the relational schema corresponding to the regular entities in the ER diagram.
SSN, DNUMBER, and PNUMBER are the primary keys for the relations
EMPLOYEE, DEPARTMENT, and PROJECT as shown.
 Step 2: Mapping of Weak Entity Types: For each weak entity type W in the ER
schema with owner entity type E, create a relation R & include all simple
attributes (or simple components of composite attributes) of W as attributes of R.
 Also, include as foreign key attributes of R the primary key attribute(s) of the
relation(s) that correspond to the owner entity type(s).
 The primary key of R is the combination of the primary key(s) of the owner(s)
and the partial key of the weak entity type W, if any.
 Example: Create the relation DEPENDENT in this step to correspond to the
weak entity type DEPENDENT. Include the primary key SSN of the EMPLOYEE
relation as a foreign key attribute of DEPENDENT (renamed to ESSN).
 The primary key of the DEPENDENT relation is the combination {ESSN,
DEPENDENT_NAME} because DEPENDENT_NAME is the partial key of
DEPENDENT.

ER-to-Relational Mapping Algorithm (cont’d.)

ER-to-Relational Mapping Algorithm (cont’d.)  Step 3: Mapping of Binary 1:1 Relation Types: For each binary 1:1 relationship type R in
the ER schema, identify the relations S and T that correspond to the entity types participating
in R.
 There are three possible approaches:
1. Foreign Key approach: Choose one of the relations-say S-and include a foreign key in
S the primary key of T. It is better to choose an entity type with total participation in R in
the role of S.
• Example: 1:1 relation MANAGES is mapped by choosing the participating entity type
DEPARTMENT to serve in the role of S, because its participation in the MANAGES
relationship type is total.
2. Merged relation option: An alternate mapping of a 1:1 relationship type is possible by
merging the two entity types and the relationship into a single relation. This may be
appropriate when both participations are total.
3. Cross-reference or relationship relation option: The third alternative is to set up a
third relation R for the purpose of cross-referencing the primary keys of the two relations
S and T representing the entity types.
 Step 4: Mapping of Binary 1:N Relationship Types: For each regular binary 1:N
relationship type R, identify the relation S that represent the participating entity type at the N-
side of the relationship type.
 Include as foreign key in S the primary key of the relation T that represents the other
entity type participating in R.
 Include any simple attributes of the 1:N relation type as attributes of S.
 Example: 1:N relationship types WORKS_FOR, CONTROLS, and SUPERVISION in the
figure. For WORKS_FOR we include the primary key DNUMBER of the DEPARTMENT
relation as foreign key in the EMPLOYEE relation and call it DNO

ER-to-Relational Mapping Algorithm (cont’d.) ER-to-Relational Mapping Algorithm (cont’d.)

 Step 5: Mapping of Binary M:N Relationship Types: For each regular binary M:N
relationship type R, create a new relation S to represent R.
 Step 7: Mapping of N-ary Relationship Types.
 Include as foreign key attributes in S the primary keys of the relations that represent the
participating entity types; their combination will form the primary key of S.  For each n-ary relationship type R, where n>2, create a new
 Also include any simple attributes of the M:N relationship type (or simple components of relationship S to represent R.
composite attributes) as attributes of S.
 Example: The M:N relationship type WORKS_ON from the ER diagram is mapped by  Include as foreign key attributes in S the primary keys of the
creating a relation WORKS_ON in the relational database schema. relations that represent the participating entity types.
 The primary keys of the PROJECT and EMPLOYEE relations are included as foreign  Also include any simple attributes of the n-ary relationship type (or
keys in WORKS_ON and renamed PNO and ESSN, respectively.
 Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation type.
simple components of composite attributes) as attributes of S.
The primary key of the WORKS_ON relation is the combination of the foreign key
attributes {ESSN, PNO}.
 Example: The relationship type SUPPY in the ER on the next
 Step 6: Mapping of Multivalued attributes: For each multivalued attribute A, create a new
slide.
relation R. This relation R will include an attribute corresponding to A, plus the primary key  This can be mapped to the relation SUPPLY shown in the relational
attribute K-as a foreign key in R-of the relation that represents the entity type of relationship schema, whose primary key is the combination of the three foreign keys
type that has A as an attribute.
{SNAME, PARTNO, PROJNAME}
 The primary key of R is the combination of A and K. If the multivalued attribute is
composite, we include its simple components.
 Example: The relation DEPT_LOCATIONS is created.
 The attribute DLOCATION represents the multivalued attribute LOCATIONS of
DEPARTMENT, while DNUMBER-as foreign key-represents the primary key of the
DEPARTMENT relation.
 The primary key of R is the combination of {DNUMBER, DLOCATION}.

11
 5/28/2021

EER diagram notation for an attribute-defined specialization on JobType.

Mapping EER Model Constructs to Relations
 Step8: Options for Mapping Specialization or Generalization.
 Convert each specialization with m subclasses {S1, S2,….,Sm} and
generalized superclass C, where the attributes of C are {k,a1,…an} and k is
the (primary) key, into relational schemas using one of the four following
options:
• Option 8A: Multiple relations-Superclass and subclasses
• Option 8B: Multiple relations-Subclass relations only
• Option 8C: Single relation with one type attribute
• Option 8D: Single relation with multiple type attributes
 Option 8A: Multiple relations-Superclass and subclasses Options for mapping specialization or generalization.
 Create a relation L for C with attributes Attrs(L) = {k,a1,…an} and PK(L) = k. (a) Mapping the EER schema in the above figure using option 8A.
Create a relation Li for each subclass Si, 1 < i < m, with the
attributesAttrs(Li) = {k} U {attributes of Si} and PK(Li)=k. This option works
for any specialization (total or partial, disjoint of over-lapping).
 Option 8B: Multiple relations-Subclass relations only
 Create a relation Li for each subclass Si, 1 < i < m, with the attributes Attr(Li)
= {attributes of Si} U {k,a1…,an} and PK(Li) = k. This option only works for a
specialization whose subclasses are total (every entity in the superclass
must belong to (at least) one of the subclasses).
 Specialization has disjointedness constraint

Generalization. (b) Generalizing CAR and TRUCK into the superclass VEHICLE.
Mapping EER Model Constructs to Relations (contd.)
 Option 8C: Single relation with one type attribute
 Create a single relation L with attributes Attrs(L) = {k,a1,…an} U
{attributes of S1} U…U {attributes of Sm} U {t} and PK(L) = k. The
attribute t is called a type (or discriminating) attribute that indicates
the subclass to which each tuple belongs
 Subclasses are disjoint
 Option 8D: Single relation with multiple type attributes
Options for mapping specialization or generalization.
 Create a single relation schema L with attributes Attrs(L) = {k,a1,…an}
(b) Mapping the EER schema in the above Figure using option 8B.
U {attributes of S1} U…U {attributes of Sm} U {t1, t2,…,tm} and PK(L) = k.
Each ti, 1 < I < m, is a Boolean type attribute indicating whether a tuple
belongs to the subclass Si.
• Subclasses are overlapping
• Will also work for a disjoint specialization

EER diagram notation for an attribute-defined specialization on JobType. EER diagram notation for an overlapping (non-disjoint) specialization.

Options for mapping specialization or generalization.

Options for mapping specialization or generalization. (d) Mapping the above figure using option 8D with Boolean type fields Mflag and Pflag.
(c) Mapping the EER schema in the above Figure using option 8C.

12
 5/28/2021

FIGURE: A specialization lattice with multiple inheritance for a UNIVERSITY database.

Mapping EER Model Constructs to Relations (contd.)
 Mapping of Shared Subclasses (Multiple Inheritance)
 A shared subclass, such as STUDENT_ASSISTANT, is a subclass
of several classes, indicating multiple inheritance. These classes
must all have the same key attribute; otherwise, the shared
subclass would be modeled as a category.
 We can apply any of the options discussed in Step 8 to a shared
subclass, subject to the restriction discussed in Step 8 of the
mapping algorithm. Below both 8C and 8D are used for the shared
class STUDENT_ASSISTANT.

FIGURE: Mapping the EER specialization lattice in Figure 4.6 using multiple options. The Relational Data Model and
Relational Database, Constraints

 A Relation is a mathematical concept based on the ideas of sets

 The model was first proposed by Dr. E.F. Codd of IBM Research
in 1970

 First commercial implementations available in early 1980s

 Has been implemented in a large number of commercial system

Relational Model Concepts Domains, Attributes, Tuples, and Relations

 Represents data as a collection of relations  Domain D
 Set of atomic values
 Informally, a relation looks like a table of values
 Table of values  Atomic
 Each value indivisible
 Row
• Represents a collection of related data values  Specifying a domain
• Fact that typically corresponds to a real-world entity or relationship  Data type specified for each domain
 In the formal model, rows are called tuples  Key of a Relation:
 Table name and column names  Each row has a value of a data item (or set of items) that uniquely
• Interpret the meaning of the values in each row attribute identifies that row in the table
• Called the key
 In the STUDENT table, SSN is the key
 Sometimes row-ids or sequential numbers are assigned as keys to identify
the rows in a table
• Called artificial key or surrogate key

13
 5/28/2021

Domains, Attributes, Tuples, and Relations (cont’d.) Characteristics of Relations

 Relation schema R: Denoted by R(A1, A2, ...,An)  Ordering of tuples in a relation
 Made up of a relation name R and a list of attributes, A1, A2, ..., An  Relation defined as a set of tuples
 Attribute Ai : Name of a role played by some domain D in the relation schema  Elements have no order among them
R
 Ordering of values within a tuple and an alternative definition of a
 Degree (or arity) of a relation: Number of attributes n of its relation schema
relation
 Relation (or relation state)
 Order of attributes and values is not that important
 Set of n-tuples r = {t1, t2, ..., tm}
 As long as correspondence between attributes and values
 Each n-tuple t
maintained
• Ordered list of n values t =<v1, v2, ..., vn
 Alternative definition of a relation
• Each value vi, 1 ≤ i ≤ n, is an element of dom(Ai) or is a special NULL
value  Tuple considered as a set of (<attribute>, <value>) pairs
 Cardinality: Total number of values in domain  Each pair gives the value of the mapping from an attribute Ai to a
 Current relation state: Relation state at a given time value vi from dom(Ai)
 Reflects only the valid tuples that represent a particular state of the real  Use the first definition of relation
world  Attributes and the values within tuples are ordered
 Attribute names: Indicate different roles, or interpretations, for the domain  Simpler notation

Characteristics of Relations (cont’d.)

Characteristics of Relations (cont’d.)  Values and NULLs in tuples
 Each value in a tuple is atomic
Figure: The relations Student from the previous figure with a different  Flat relational model
order of tuples
• Composite and multivalued attributes not allowed
• First normal form assumption
 Multivalued attributes: Must be represented by separate relations
 Composite attributes: Represented only by simple component
attributes in basic relational model
 NULL values: Represent the values of attributes that may be unknown
or may not apply to a tuple
 Meanings for NULL values: Value unknown
• Value exists but is not available
• Attribute does not apply to this tuple (also known as value
undefined)

Relational Model Notation Domain Constraints

 Name of a relation schema: STUDENT  Typically include:
 Indicates the current set of tuples in that relation
 Numeric data types for integers and real numbers
 Notation: STUDENT(Name, Ssn, ...)
 Refers only to relation schema  Characters
 Attribute A can be qualified with the relation name R to which it  Booleans
belongs
 Fixed-length strings
 Using the dot notation R.A
 Variable-length strings
 n-tuple t in a relation r(R)
 Denoted by t = <v1, v2, ..., vn>  Date, time, timestamp
 vi is the value corresponding to attribute Ai  Money
 Component values of tuples:  Other special data types
 t[Ai] and t.Ai refer to the value vi in t for attribute Ai
 t[Au, Aw, ..., Az] and t.(Au, Aw, ..., Az) refer to the subtuple of values
<vu, vw, ..., vz> from t corresponding to the attributes specified in the
list

14

Key Constraints and Constraints on NULL Values
 No two tuples can have the same combination of values for all their
attributes.
 Superkey: No two distinct tuples in any state r of R can have the same
value for SK
 Key: Superkey of R
 Removing any attribute A from K leaves a set of attributes K that is not
a superkey of R any more
 Key satisfies two properties:
 Two distinct tuples in any state of relation cannot have identical values
for (all) attributes in key
 Minimal superkey: Cannot remove any attributes and still have
uniqueness constraint in above condition hold
 Candidate key: Relation schema may have more than one key
 Primary key of the relation: Designated among candidate keys
 Underline attribute
 Other candidate keys are designated as unique keys
Relational Constraints/Integrity Rules
Other Types of Constraints (cont’d.)
 Functional dependency constraint
 Establishes a functional relationship among two sets of attributes X
and Y
 Value of X determines a unique value of Y
 State constraints
 Define the constraints that a valid state of the database must satisfy
 Transition constraints
 Define to deal with state changes in the database
5/28/2021
Key Constraints and Constraints on NULL Values (cont’d.)
Relational Integrity
Domain Integrity: No value of the attribute should be beyond the allowable
limits
Entity Integrity: In a base relation, no attribute of a primary key can be null
Referential Integrity: If a foreign key exists in a relation, either the foreign key
value must match a candidate key in its home relation or the foreign key value
must be null foreign key to primary key match-ups
Enterprise Integrity: Additional rules specified by the users or database
administrators of a database are incorporated
Integrity, Referential Integrity, and Foreign Keys
 Entity integrity constraint
 No primary key value can be NULL
 Referential integrity constraint
 Specified between two relations
 Maintains consistency among tuples in two relations
 Foreign key rules:
 The attributes in FK have the same domain(s) as the primary key
attributes PK
 Value of FK in a tuple t1 of the current state r1(R1) either occurs as a
value of PK for some tuple t2 in the current state r2(R2) or is NULL
 Diagrammatically display referential integrity constraints
 Directed arc from each foreign key to the relation it references
 All integrity constraints should be specified on relational database
schema
Update Operations, Transactions, and Dealing with Constraint
Violations
 Operations of the relational model can be categorized into retrievals and
updates
 Basic operations that change the states of relations in the database:
 Insert, Delete, Update (or Modify)
15
 5/28/2021

The Insert Operation The Delete Operation

 Provides a list of attribute values for a new tuple t that is to be inserted into a
relation R
 Can violate any of the four types of constraints
 If an insertion violates one or more constraints
 Default option is to reject the insertion
 Possible violations for each operation: INSERT may violate any of the
constraints:
 Domain constraint: if one of the attribute values provided for the new tuple
is not of the specified attribute domain
 Key constraint: if the value of a key attribute in the new tuple already exists
in another tuple in the relation
 Referential integrity:
• if a foreign key value in the new tuple references a primary key value
that does not exist in the referenced relation
 Entity integrity:
• if the primary key value is null in the new tuple
 Can violate only referential integrity, If tuple being deleted is referenced by
foreign keys from other tuples
 Restrict: Reject the deletion
 Cascade: Propagate the deletion by deleting tuples that reference the
tuple that is being deleted
 Set null or set default: Modify the referencing attribute values that cause
the violation
 Possible violations for each operation: DELETE may violate only
referential integrity: If the primary key value of the tuple being deleted is
referenced from other tuples in the database. Can be remedied by several
actions: RESTRICT, CASCADE, SET NULL
• RESTRICT option: reject the deletion
• CASCADE option: propagate the new primary key value into the
foreign keys of the referencing tuples
• SET NULL option: set the foreign keys of the referencing tuples to
NULL
 One of the above options must be specified during database design for
each foreign key constraint

The Update Operation

 Necessary to specify a condition on attributes of relation In-Class Exercise
 Select the tuple (or tuples) to be modified
 If attribute not part of a primary key nor of a foreign key
Consider the following relations for a database that keeps track of student
 Usually causes no problems enrollment in courses and the books adopted for each course:
 Updating a primary/foreign key STUDENT(SSN, Name, Major, Bdate)
 Similar issues as with Insert/Delete
COURSE(Course#, Cname, Dept)
 Possible violations for each operation: UPDATE may violate domain
constraint and NOT NULL constraint on an attribute being modified ENROLL(SSN, Course#, Quarter, Grade)
 Any of the other constraints may also be violated, depending on the attribute BOOK_ADOPTION(Course#, Quarter, Book_ISBN)
being updated:
TEXT(Book_ISBN, Book_Title, Publisher, Author)
 Updating the primary key (PK): Similar to a DELETE followed by an
INSERT Need to specify similar options to DELETE Draw a relational schema diagram specifying the foreign keys for this
schema.
 Updating a foreign key (FK): May violate referential integrity
 Updating an ordinary attribute (neither PK nor FK):
• Can only violate domain constraints

16
 5/28/2021

The University Database: The university database stores details about

university students, courses, the semester a student took a particular course
(and his mark and grade if he completed it), and what degree program each
student is enrolled in. Consider the following requirements list:
 The university offers one or more programs.
 A program is made up of one or more courses.
 A student must enroll in a program.
 A student takes the courses that are part of her program.
 A program has a name, a program identifier, the total credit points required to
graduate, and the year it commenced.
 A course has a name, a course identifier, a credit point value, and the year it
commenced.
 Students have one or more given names, a surname, a student identifier, a date
of birth, and the year they first enrolled. We can treat all given names as a
single object—for example, “John Paul.”
 When a student takes a course, the year and semester he attempted it are
recorded. When he finishes the course, a grade (such as A or B) and a mark
(such as 60 percent) are recorded.
 Each course in a program is sequenced into a year (for example, year 1) and a
semester (for example, semester 1).
The Music Database: The music database is used to store details of a music
collection, including the albums in the collection, the artists who made them,
the tracks on the albums, and when each track was last played.
The music database stores details of a personal music library, and could be
used to manage your MP3, CD, or vinyl collection. Because this database is for
a personal collection, it’s relatively simple and stores only the relationships
between artists, albums, and tracks. A clear list of requirements for the
database are:
 The collection consists of albums.
 An album is made by exactly one artist.
 An artist makes one or more albums.
 An album contains one or more tracks
 Artists, albums, and tracks each have a name.
 Each track is on exactly one album.
 Each track has a time length, measured in seconds.
 When a track is played, the date and time the playback began (to the nearest
second) should be recorded; this is used for reporting when a track was last
played, as well as the number of times music by an artist, from an album, or a
track has been played.

The Flight Database

The flight database stores an airline timetable of flight routes, times, the plane
types, an airline’s fleet, flights, and seat bookings details. Again, it’s a hugely
simplified version of what a real airline would use, but the principles are the
same.
Consider the following requirements list:
• The airline has one or more airplanes.
• An airplane has a model number, a unique registration number, and the
capacity to take one or more passengers.
• An airplane flight has a unique flight number, a departure airport, a
destination airport, a departure date and time, and an arrival date and
time.
• Each flight is carried out by a single airplane.
• A passenger has given names, a surname, and a unique email address.
• A passenger can book a seat on a flight.

17