Database Management Systems

CS 5200

Dr. Tehmina Amjad

Spring 2024
Enhanced ER Modeling

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

2
Outline
• EER stands for Enhanced ER or Extended ER
• EER Model Concepts
• Includes all modeling concepts of basic ER
• Additional concepts:
• subclasses/superclasses
• specialization/generalization
• categories (UNION types)
• attribute and relationship inheritance
• Constraints on Specialization/Generalization
• The additional EER concepts are used to model applications more
completely and more accurately
• EER includes some object-oriented concepts, such as inheritance
• Knowledge Representation and Ontology Concepts

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

3
Subclasses and Superclasses
• 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 (the role they play)
• 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 4

Subclasses and Superclasses

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 5

Subclasses and Superclasses
• Each of these subgroupings is a subset of EMPLOYEE entities
• Each is called a subclass of EMPLOYEE
• EMPLOYEE is the superclass for each of these subclasses
• These are called superclass/subclass relationships:
• EMPLOYEE/SECRETARY
• EMPLOYEE/TECHNICIAN
• EMPLOYEE/MANAGER
• …

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 6

Subclasses and Superclasses
• These are also called IS-A relationships
• SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, ….
• Note: An entity that is member of a subclass represents the same real-world
entity as some member of the superclass:
• The subclass member is the same entity in a distinct specific role
• An entity cannot exist in the database merely by being a member of a subclass;
it must also be a member of the superclass
• A member of the superclass can be optionally included as a member of any
number of its subclasses

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 7

Subclasses and Superclasses
• Examples:
• A salaried employee who is also an engineer belongs to the two subclasses:
• ENGINEER, and
• SALARIED_EMPLOYEE
• A salaried employee who is also an engineering manager belongs to the three
subclasses:
• MANAGER,
• ENGINEER, and
• SALARIED_EMPLOYEE
• It is not necessary that every entity in a superclass be a member of some
subclass

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 8

Representing Specialization in EER Diagrams

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 9

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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 10

Specialization
• 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.
• Example: MANAGER is a specialization of EMPLOYEE
based on the role the employee plays
• May have several specializations of the same superclass

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 11

Specialization
• 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 12

Specialization

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 13

Generalization
• Generalization is the reverse of the specialization process
• Several classes with common features are generalized into a superclass;
• original classes become its subclasses
• Example: CAR, TRUCK generalized into VEHICLE;
• both CAR, TRUCK become subclasses of the superclass VEHICLE.
• We can view {CAR, TRUCK} as a specialization of VEHICLE
• Alternatively, we can view VEHICLE as a generalization of CAR and TRUCK

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 14

Generalization

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 15

Constraints on Specialization and
Generalization
• 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 18

Constraints on Specialization and
Generalization
• 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 19

Displaying an attribute-defined specialization
in EER diagrams

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 20

Constraints on Specialization and
Generalization
• Two basic constraints can apply to a specialization/generalization:
• Disjointness Constraint:
• Completeness Constraint:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 21

Constraints on Specialization and
Generalization
• 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 22

Constraints on Specialization and
Generalization
• Completeness (Exhaustiveness) 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 23

Constraints on Specialization and
Generalization
• 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.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 24

Example of disjoint partial Specialization

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 25

Example of overlapping total Specialization

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 26

Specialization/Generalization Hierarchies, Lattices
& Shared Subclasses
• 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)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 27

Shared Subclass “Engineering_Manager”

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 28

Specialization/Generalization Hierarchies, Lattices
& Shared Subclasses
• 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)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 29

Specialization/Generalization Hierarchies,
Lattices & Shared Subclasses
• 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 30

Specialization / Generalization Lattice Example
(UNIVERSITY)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 31

Categories (UNION TYPES)
• All of the superclass/subclass relationships we have seen thus far have a
single superclass
• A shared subclass is a subclass in:
• more than one distinct superclass/subclass relationships
• each relationships has a single superclass
• shared subclass leads to multiple inheritance
• In some cases, we need to model a single superclass/subclass relationship
with more than one superclass
• Superclasses can represent different entity types
• Such a subclass is called a category or UNION TYPE

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 32

Categories (UNION TYPES)
• Example: In a database for vehicle registration, a vehicle owner can be a
PERSON, a BANK (holding a lien on a vehicle) or a COMPANY.
• A category (UNION type) called OWNER is created to represent a subset of the
union of the three superclasses COMPANY, BANK, and PERSON
• A category member must exist in at least one (typically just one) of its
superclasses
• Difference from shared subclass, which is a:
• subset of the intersection of its superclasses
• shared subclass member must exist in all of its superclasses

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 33

Two categories (UNION types): OWNER,
REGISTERED_VEHICLE

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 34

Formal Definitions of EER Model
• Class C:
• A type of entity with a corresponding set of entities:
• could be entity type, subclass, superclass, or category
• Note: The definition of relationship type in ER/EER should have 'entity type'
replaced with 'class‘ to allow relationships among classes in general
• Subclass S is a class whose:
• Type inherits all the attributes and relationship of a class C
• Set of entities must always be a subset of the set of entities of the other class C
• S⊆C
• C is called the superclass of S
• A superclass/subclass relationship exists between S and C

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 35

Formal Definitions of EER Model
• Specialization Z: Z = {S1, S2,…, Sn} is a set of subclasses with
same superclass G; hence, G/Si is a superclass relationship for i =
1, …., n.
• G is called a generalization of the subclasses {S1, S2,…, Sn}
• Z is total if we always have:
• S1 ∪ S2 ∪ … ∪ Sn = G;
• Otherwise, Z is partial.
• Z is disjoint if we always have:
• Si ∩ S2 empty-set for i ≠ j;
• Otherwise, Z is overlapping.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 36

Formal Definitions of EER Model
• Subclass S of C is predicate defined if predicate (condition) p on attributes of
C is used to specify membership in S;
• that is, S = C[p], where C[p] is the set of entities in C that satisfy condition p
• A subclass not defined by a predicate is called user-defined
• Attribute-defined specialization: if a predicate A = ci (where A is an attribute
of G and ci is a constant value from the domain of A) is used to specify
membership in each subclass Si in Z
• Note: If ci ≠ cj for i ≠ j, and A is single-valued, then the attribute-defined
specialization will be disjoint.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 37

Formal Definitions of EER Model
• Category or UNION type T
• A class that is a subset of the union of n defining superclasses
D1, D2,…Dn, n>1:
• T ⊆ (D1 ∪ D2 ∪ … ∪ Dn)
• Can have a predicate pi on the attributes of Di to specify entities of Di that
are members of T.
• If a predicate is specified on every Di: T = (D1[p1] ∪ D2[p2] ∪…∪ Dn[pn])

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 38

UML Example for Displaying Specialization /
Generalization

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 40

[More info about UML]
• UML Association vs Aggregation vs Composition
• https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/uml-aggregation-vs-composition/
• WATCH: Data Modeling with UML Class Diagrams
• https://northeastern.hosted.panopto.com/Panopto/Pages/Viewer.aspx?i
d=9c848a68-1897-4106-a2a8-abe301506266&start=0
• https://northeastern.hosted.panopto.com/Panopto/Pages/Viewer.aspx?i
d=5be58a7b-186f-40d3-8351-abe301506c9a&start=0

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 41

Summary
• Introduced the EER model concepts
• Class/subclass relationships
• Specialization and generalization
• Inheritance
• Constraints on EER schemas
• These augment the basic ER model concepts introduced in Chapter 3
• EER diagrams and alternative notations were presented
• Knowledge Representation and Ontologies were introduced and compared
with Data Modeling

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 42

Class activity
• Enhanced Entity Relationship diagram

• A book has a unique ISBN number, a title and one or more authors. The library service may own several
copies of a given book, each of which is located in one of the service’s libraries. A given library contains
many books, and in order to distinguish different copies of the same book a library assigns a different copy-
number to each of its copies of a given book; the price that was paid for each copy is also recorded. Every
library has a unique name and is either a main library or a branch library. A main library may have zero
or more branch libraries and every branch library is a branch of exactly one main library. A borrower has
a name and a unique ID code. A borrower can have many books on loan, but each copy of a book can only be
on loan to one borrower. A borrower could borrow the same book on several occasions, but it is assumed that
each such loan will take place on a different date.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 43

ERD-to-Relational Mapping
Relational Model Concepts
• The relational Model of Data is based on the concept of a Relation
• The strength of the relational approach to data management comes from the
formal foundation provided by the theory of relations

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 45

Relational Model Concepts
• 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 in the following paper:
• "A Relational Model for Large Shared Data Banks," Communications of the
ACM, June 1970
• The above paper caused a major revolution in the field of
database management and earned Dr. Codd the coveted ACM
Turing Award

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 46

https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://dl.acm.org/doi/10.1145/362384.362685
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 47
Informal Definitions
• Informally, a relation looks like a table of values.
• A relation typically contains a set of rows.
• The data elements in each row represent certain facts that
correspond to a real-world entity or relationship
• In the formal model, rows are called tuples
• Each column has a column header that gives an indication of the
meaning of the data items in that column
• In the formal model, the column header is called an
attribute name (or just attribute)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 48

Example of a Relation

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 49

Informal Definitions
• Key of a Relation:
• Each row has a value of a data item (or set of items) that uniquely
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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 50

Formal Definitions - Schema
• The Schema (or description) of a Relation:
• Denoted by R(A1, A2, .....An)
• R is the name of the relation
• The attributes of the relation are A1, A2, ..., An
• Example:
CUSTOMER (Cust-id, Cust-name, Address, Phone#)
• CUSTOMER is the relation name
• Defined over the four attributes: Cust-id, Cust-name, Address, Phone#
• Each attribute has a domain or a set of valid values.
• For example, the domain of Cust-id is 6 digit numbers.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 51

Formal Definitions - Tuple
• A tuple is an ordered set of values (enclosed in angled brackets ‘< … >’)
• Each value is derived from an appropriate domain.
• A row in the CUSTOMER relation is a 4-tuple and would consist of four values,
for example:
• <632895, "John Smith", "101 Main St. Atlanta, GA 30332", "(404) 894-2000">
• This is called a 4-tuple as it has 4 values
• A tuple (row) in the CUSTOMER relation.
• A relation is a set of such tuples (rows)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 52

Formal Definitions - Domain
• A domain has a logical definition:
• Example: “USA_phone_numbers” are the set of 10 digit phone numbers valid in the U.S.
• A domain also has a data-type or a format defined for it.
• The USA_phone_numbers may have a format: (ddd)ddd-dddd where each d is a decimal
digit.
• Dates have various formats such as year, month, date formatted as yyyy-
mm-dd, or as dd mm,yyyy etc.

• The attribute name designates the role played by a domain in a relation:

• Used to interpret the meaning of the data elements corresponding to that
attribute
• Example: The domain Date may be used to define two attributes named “Invoice-date”
and “Payment-date” with different meanings

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 53

Formal Definitions - State
• The relation state is a subset of the Cartesian product of the
domains of its attributes
• each domain contains the set of all possible values the attribute can take.
• Example: attribute Cust-name is defined over the domain of
character strings of maximum length 25
• dom(Cust-name) is varchar(25)
• The role these strings play in the CUSTOMER relation is that of the
name of a customer.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 54

Formal Definitions - Summary
• Formally,
• Given R(A1, A2, .........., An)
• r(R) Ì dom (A1) X dom (A2) X ....X dom(An)
• R(A1, A2, …, An) is the schema of the relation
• R is the name of the relation
• A1, A2, …, An are the attributes of the relation
• r(R): a specific state (or "value" or “population”) of relation R – this is a set of
tuples (rows)
• r(R) = {t1, t2, …, tn} where each ti is an n-tuple
• ti = <v1, v2, …, vn> where each vj element-of dom(Aj)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 55

Formal Definitions - Example
• Let R(A1, A2) be a relation schema:
• Let dom(A1) = {0,1}
• Let dom(A2) = {a,b,c}
• Then: dom(A1) X dom(A2) is all possible combinations:
{<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> }

• The relation state r(R) Ì dom(A1) X dom(A2)

• For example: r(R) could be {<0,a> , <0,b> , <1,c> }
• this is one possible state (or “population” or “extension”) r of the relation R,
defined over A1 and A2.
• It has three 2-tuples: <0,a> , <0,b> , <1,c>

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 56

Definition Summary
Informal Terms Formal Terms
Table Relation
Column Header Attribute
All possible Column Values Domain
Row Tuple

Table Definition Schema of a Relation

Populated Table State of the Relation

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 57

Example – A relation STUDENT

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 58

Characteristics Of Relations
• Ordering of tuples in a relation r(R):
• The tuples are not considered to be ordered, even though they appear to
be in the tabular form.
• Ordering of attributes in a relation schema R (and of values within each
tuple):
• We will consider the attributes in R(A1, A2, ..., An) and the values in t=<v1,
v2, ..., vn> to be ordered .
• (However, a more general alternative definition of relation does not require this
ordering. It includes both the name and the value for each of the attributes ).
• Example: t= { <name, “John” >, <SSN, 123456789> }
• This representation may be called as “self-describing”.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 59

Same state as previous Figure (but with
different order of tuples)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 60

Characteristics Of Relations
• Values in a tuple:
• All values are considered atomic (indivisible).
• Each value in a tuple must be from the domain of the attribute for that
column
• If tuple t = <v1, v2, …, vn> is a tuple (row) in the relation state r of R(A1, A2, …, An)
• Then each vi must be a value from dom(Ai)

• A special null value is used to represent values that are unknown or not
available or inapplicable in certain tuples.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 61

Characteristics Of Relations
• Notation:
• We refer to component values of a tuple t by:
• t[Ai] or t.Ai
• This is the value vi of attribute Ai for tuple t
• Similarly, t[Au, Av, ..., Aw] refers to the subtuple of t containing the values
of attributes Au, Av, ..., Aw, respectively in t

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 62

CONSTRAINTS
Constraints determine which values are permissible and which are not in the
database.
They are of three main types:
1. Inherent or Implicit Constraints: These are based on the data model itself.
(E.g., relational model does not allow a list as a value for any attribute)
2. Schema-based or Explicit Constraints: They are expressed in the schema
by using the facilities provided by the model. (E.g., max. cardinality ratio
constraint in the ER model)
3. Application based or semantic constraints: These are beyond the
expressive power of the model and must be specified and enforced by the
application programs.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 63

Relational Integrity Constraints
• Constraints are conditions that must hold on all valid relation
states.
• There are three main types of (explicit schema-based) constraints
that can be expressed in the relational model:
• Key constraints
• Entity integrity constraints
• Referential integrity constraints
• Another schema-based constraint is the domain constraint
• Every value in a tuple must be from the domain of its attribute (or it could
be null, if allowed for that attribute)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 64

Key Constraints
• Superkey of R:
• Is a set of attributes SK of R with the following condition:
• No two tuples in any valid relation state r(R) will have the same value for SK
• That is, for any distinct tuples t1 and t2 in r(R), t1[SK] ¹ t2[SK]
• This condition must hold in any valid state r(R)
• Key of R:
• A "minimal" superkey
• That is, a key is a superkey K such that removal of any attribute from K results in
a set of attributes that is not a superkey (does not possess the superkey
uniqueness property)
• A Key is a Superkey but not vice versa

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 65

Key Constraints (continued)
• Example: Consider the CAR relation schema:
• CAR(State, Reg#, SerialNo, Make, Model, Year)
• CAR has two keys:
• Key1 = {State, Reg#}
• Key2 = {SerialNo}
• Both are also superkeys of CAR
• {SerialNo, Make} is a superkey but not a key.
• In general:
• Any key is a superkey (but not vice versa)
• Any set of attributes that includes a key is a superkey
• A minimal superkey is also a key

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 66

Key Constraints (continued)
• If a relation has several candidate keys, one is chosen arbitrarily to be the
primary key.
• The primary key attributes are underlined.
• Example: Consider the CAR relation schema:
• CAR(State, Reg#, SerialNo, Make, Model, Year)
• We chose SerialNo as the primary key
• The primary key value is used to uniquely identify each tuple in a relation
• Provides the tuple identity
• Also used to reference the tuple from another tuple
• General rule: Choose as primary key the smallest of the candidate keys (in terms
of size)
• Not always applicable – choice is sometimes subjective

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 67

CAR table with two candidate keys –
LicenseNumber chosen as Primary Key

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 68

Relational Database Schema
• Relational Database Schema:
• A set S of relation schemas that belong to the same database.
• S is the name of the whole database schema
• S = {R1, R2, ..., Rn} and a set IC of integrity constraints.
• R1, R2, …, Rn are the names of the individual relation schemas within the
database S
• Following slide shows a COMPANY database schema with 6
relation schemas

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 69

COMPANY Database Schema

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 70

Relational Database State
• A relational database state DB of S is a set of relation states DB = {r1,
r2, ..., rm} such that each ri is a state of Ri and such that the ri relation
states satisfy the integrity constraints specified in IC.
• A relational database state is sometimes called a relational database
snapshot or instance.
• We will not use the term instance since it also applies to single tuples.
• A database state that does not meet the constraints is an invalid state

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 71

Populated database state
• Each relation will have many tuples in its current relation state
• The relational database state is a union of all the individual relation states
• Whenever the database is changed, a new state arises
• Basic operations for changing the database:
• INSERT a new tuple in a relation
• DELETE an existing tuple from a relation
• MODIFY an attribute of an existing tuple
• Next slide (Fig. 5.6) shows an example state for the COMPANY database
schema shown in Fig. 5.5.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 72

Populated database state for COMPANY

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 73

Entity Integrity
• Entity Integrity:
• The primary key attributes PK of each relation schema R in S cannot have
null values in any tuple of r(R).
• This is because primary key values are used to identify the individual tuples.
• t[PK] ¹ null for any tuple t in r(R)
• If PK has several attributes, null is not allowed in any of these attributes
• Note: Other attributes of R may be constrained to disallow null values,
even though they are not members of the primary key.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 74

Referential Integrity
• A constraint involving two relations
• The previous constraints involve a single relation.
• Used to specify a relationship among tuples in two relations:
• The referencing relation and the referenced relation.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 75

Referential Integrity
• Tuples in the referencing relation R1 have attributes FK (called
foreign key attributes) that reference the primary key attributes PK
of the referenced relation R2.
• A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK].
• A referential integrity constraint can be displayed in a relational
database schema as a directed arc from R1.FK to R2.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 76

Referential Integrity (or foreign key)
Constraint
• Statement of the constraint
• The value in the foreign key column (or columns) FK of the the referencing
relation R1 can be either:
• (1) a value of an existing primary key value of a corresponding primary key PK in the
referenced relation R2, or
• (2) a null.
• In case (2), the FK in R1 should not be a part of its own primary
key.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 77

Displaying a relational database schema and
its constraints
• Each relation schema can be displayed as a row of attribute names
• The name of the relation is written above the attribute names
• The primary key attribute (or attributes) will be underlined
• A foreign key (referential integrity) constraints is displayed as a directed arc
(arrow) from the foreign key attributes to the referenced table
• Can also point the the primary key of the referenced relation for clarity
• Next slide shows the COMPANY relational schema diagram with referential
integrity constraints

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 78

Referential Integrity Constraints for COMPANY database

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 79

Update Operations on Relations
• INSERT a tuple.
• DELETE a tuple.
• MODIFY a tuple.
• Integrity constraints should not be violated by the update
operations.
• Several update operations may have to be grouped together.
• Updates may propagate to cause other updates automatically.
This may be necessary to maintain integrity constraints.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 81

Update Operations on Relations
• In case of integrity violation, several actions can be taken:
• Cancel the operation that causes the violation (RESTRICT or REJECT
option)
• Perform the operation but inform the user of the violation
• Trigger additional updates so the violation is corrected (CASCADE option,
SET NULL option)
• Execute a user-specified error-correction routine

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 82

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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 83

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 (see Chapter 6
for more details)
• RESTRICT option: reject the deletion
• CASCADE option: attempt to cascade (or propagate) the deletion by deleting tuples that
reference the tuple that is being deleted.
• 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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 84

Possible violations for each operation
• UPDATE may violate domain constraint and NOT NULL constraint on an
attribute being modified
• Any of the other constraints may also be violated, depending on the attribute
being updated:
• Updating the primary key (PK):
• Similar to a DELETE followed by an INSERT
• Need to specify similar options to DELETE
• Updating a foreign key (FK):
• May violate referential integrity
• Updating an ordinary attribute (neither PK nor FK):
• Can only violate domain constraints

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 85

Summary
• Presented Relational Model Concepts
• Definitions
• Characteristics of relations
• Discussed Relational Model Constraints and Relational Database Schemas
• Domain constraints
• Key constraints
• Entity integrity
• Referential integrity
• Described the Relational Update Operations and Dealing with Constraint
Violations

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 86

Class activity
Consider the following relations for a database that keeps track of student
enrollment in courses and the books adopted for each course:
STUDENT(SSN, Name, Major, Bdate)
COURSE(Course#, Cname, Dept)
ENROLL(SSN, Course#, Quarter, Grade)
BOOK_ADOPTION(Course#, Quarter, Book_ISBN)
TEXT(Book_ISBN, Book_Title, Publisher, Author)
Draw a relational schema diagram specifying the foreign keys for this
schema.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 87

Mapping
• ER-to-Relational Mapping Algorithm
• Step 1: Mapping of Regular Entity Types
• Step 2: Mapping of Weak Entity Types
• Step 3: Mapping of Binary 1:1 Relation Types
• Step 4: Mapping of Binary 1:N Relationship Types.
• Step 5: Mapping of Binary M:N Relationship Types.
• Step 6: Mapping of Multivalued attributes.
• Step 7: Mapping of N-ary Relationship Types.

• Mapping EER Model Constructs to Relations

• Step 8: Options for Mapping Specialization or Generalization.
• Step 9: Mapping of Union Types (Categories).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 88

GOALS during Mapping
• Preserve all information (that includes all attributes)
• Maintain the constraints to the extent possible (Relational Model
cannot preserve all constraints- e.g., max cardinality ratio such as
1:10 in ER; exhaustive classification into subtypes, e.g.,
STUDENTS are specialized into Domestic and Foreign)
• Minimize null values
The mapping procedure described has been implemented in many
commercial tools.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 89

The ER conceptual schema diagram for the
COMPANY database.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 90

Result of mapping the COMPANY ER schema into a
relational schema.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 91

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.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 92

ER-to-Relational Mapping Algorithm
(contd.)
• 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.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 93

ER-to-Relational Mapping Algorithm
(contd.)
• 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 ( 2 relations) 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 (1 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 ( 3 relations) 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.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 94

ER-to-Relational Mapping Algorithm
(contd.)
• 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.
• An alternative approach is to use a Relationship relation (cross referencing
relation) – this is rarely done.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 95

ER-to-Relational Mapping Algorithm (contd.)
• 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. This is a relationship relation.
• 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.
• Also include any simple attributes of the M:N relationship type (or simple components
of composite attributes) as attributes of S.
• Example: The M:N relationship type WORKS_ON from the ER diagram is
mapped by creating a relation WORKS_ON in the relational database
schema.
• The primary keys of the PROJECT and EMPLOYEE relations are included as foreign keys
in WORKS_ON and renamed PNO and ESSN, respectively.
• Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation type.
The primary key of the WORKS_ON relation is the combination of the foreign key
attributes {ESSN, PNO}.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 96

ER-to-Relational Mapping Algorithm (contd.)
• Step 6: Mapping of Multivalued attributes.
• For each multivalued attribute A, create a new relation R.
• This relation R will include an attribute corresponding to A, plus the primary key
attribute K-as a foreign key in R-of the relation that represents the entity type of
relationship type that has A as an attribute.
• 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}.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 97

ER-to-Relational Mapping Algorithm (contd.)
• Step 7: Mapping of N-ary Relationship Types.
• For each n-ary relationship type R, where n>2, create a new relationship S to
represent R.
• Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types.
• Also include any simple attributes of the n-ary relationship type (or simple
components of composite attributes) as attributes of S.
• Example: The relationship type SUPPY in the ER on the next slide.
• This can be mapped to the relation SUPPLY shown in the relational schema, whose
primary key is the combination of the three foreign keys {SNAME, PARTNO,
PROJNAME}

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 98

Result of mapping the COMPANY ER schema into a
relational database schema.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 99

TERNARY RELATIONSHIP: SUPPLY

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 100

Mapping the n-ary relationship type
SUPPLY

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 101

Summary of Mapping constructs and
constraints

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 102

Mapping of Generalization and
Specialization Hierarchies
to a Relational Schema

103
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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 104

Mapping EER Model Constructs to Relations
• Option 8A: Multiple relations-Superclass and subclasses
• Create a relation L for C with attributes Attrs(L) = {k,a1,…an} and PK(L) = k. 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).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 105

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

• Option 8D: Single relation with multiple type attributes

• Create a single relation schema L with attributes Attrs(L) = {k,a1,…an} 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.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 106

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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 107

Mapping the EER schema using option 8A

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 108

Mapping the EER schema using option 8C

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 109

Generalizing CAR and TRUCK into the
superclass VEHICLE.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 110

Mapping the EER schema using option 8B.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 111

An overlapping (non-disjoint) specialization.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 112

Mapping using option 8D with Boolean
type fields Mflag and Pflag.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 113

Different Options for Mapping Generalization
Hierarchies
• Next Slide :Options for mapping specialization or
generalization.
(a) Mapping the EER schema using option 8A.
(b) Mapping the EER schema using option 8B.
(c) Mapping the EER schema using option 8C.
(d) Mapping using option 8D with Boolean type fields
Mflag and Pflag.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 114

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 115
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 116
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 117
Different Options for Mapping Generalization
Hierarchies - summary

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 118

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.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 119

A specialization lattice with multiple
inheritance for a UNIVERSITY database.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 120

Mapping the EER specialization lattice
using multiple options.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 121

Mapping EER Model Constructs to Relations
(contd.)
• Step 9: Mapping of Union Types (Categories).
• For mapping a category whose defining superclass have different keys, it
is customary to specify a new key attribute, called a surrogate key, when
creating a relation to correspond to the category.
• In the example below we can create a relation OWNER to correspond to
the OWNER category and include any attributes of the category in this
relation. The primary key of the OWNER relation is the surrogate key,
which we called OwnerId.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 122

Two categories (union types): OWNER and
REGISTERED_VEHICLE.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 123

Mapping the EER categories (union types) to
relations.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 124

Mapping Exercise-1
Exercise 9.4 : Map this schema into a set of relations.

FIGURE 9.8
An ER schema for a
SHIP_TRACKING
database.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 125

Mapping Exercise-2
Exercise 9.9 : Map this schema into a set of relations

FIGURE 9.9
EER diagram for a
car dealer

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 126

Chapter Summary
• ER-to-Relational Mapping Algorithm
• Step 1: Mapping of Regular Entity Types
• Step 2: Mapping of Weak Entity Types
• Step 3: Mapping of Binary 1:1 Relation Types
• Step 4: Mapping of Binary 1:N Relationship Types.
• Step 5: Mapping of Binary M:N Relationship Types.
• Step 6: Mapping of Multivalued attributes.
• Step 7: Mapping of N-ary Relationship Types.

• Mapping EER Model Constructs to Relations

• Step 8: Options for Mapping Specialization or Generalization.
• Step 9: Mapping of Union Types (Categories).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 127

Homework
• Exercise Lab 3: MySQL on GCP
• GCP setup
• Create MySQL instance on GCP,
• Submit a screenshot of GCP console that shows a created MySQL
database instance on Canvas
• Homework 3:
• Mapping EER to Relational Schema Diagram
• SQL Workshop
• Submit WS3-3.sql
• Project Phase 1 due on Jan 24, 2024
128
• Read Textbook
• B1: Ch 3
• B2: Ch 13
• B3: Ch 5,9

129
[Optional Assignments]
• WATCH: WATCH: Defining a Relational Schema
• https://northeastern.hosted.panopto.com/Panopto/Pages/Viewer.aspx?i
d=55c2e37d-db99-40e4-9d82-abed011f6e5e&start=0
• WATCH: The Relational Model
• https://northeastern.hosted.panopto.com/Panopto/Pages/Viewer.aspx?i
d=2a9ea958-34af-4f7a-87a4-abe900fd79e7&start=0

130