Section- 2(PART-1)

Database Design Using the E-R Model

 Relation Schema and Instance

 A1, A2, …, An are attributes

 R = (A1, A2, …, An ) is a relation schema
Example:
instructor = (ID, name, dept_name, salary)
 A relation instance r defined over schema R is denoted by r (R).
 The current values a relation are specified by a table
 An element t of relation r is called a tuple and is represented by
a row in a table

2.4
 Attributes

 The set of allowed values for each attribute is called the domain of the
attribute
 Attribute values are (normally) required to be atomic; that is, indivisible
 The special value null is a member of every domain. Indicated that the
value is ―unknown‖
 The null value causes complications in the definition of many operations

2.5
 Relations are Unordered

 Order of tuples is irrelevant (tuples may be stored in an arbitrary order)

 Example: instructor relation with unordered tuples

2.6
 Database Schema

 Database schema -- is the logical structure of the database.

 Database instance -- is a snapshot of the data in the database at a given
instant in time.
 Example:
• schema: instructor (ID, name, dept_name, salary)
• Instance:

2.7
 Relational Integrity Constraints

 Constraints are conditions that must hold on all

valid relation states.
 There are three main types of constraints in the
relational model:
• Key constraints
• Entity integrity constraints
• Referential integrity constraints
 Another implicit 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)

2.8
 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

2.9
 Keys

 Let K  R
 K is a superkey of R if values for K are sufficient to identify a unique tuple
of each possible relation r(R)
• Example: {ID} and {ID,name} are both superkeys of instructor.
 Superkey K is a candidate key if K is minimal
Example: {ID} is a candidate key for Instructor
 One of the candidate keys is selected to be the primary key.
• Which one?
 Foreign key constraint: Value in one relation must appear in another
• Referencing relation
• Referenced relation
• Example: dept_name in instructor is a foreign key from instructor
referencing department

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

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

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

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

2.14
 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

2.15
Referential Integrity Constraints for COMPANY database

2.16
Schema Diagram for University Database

2.17
 Other Types of Constraints

 Semantic Integrity Constraints:

• based on application semantics and cannot be expressed by the
model per se
• Example: ―the max. no. of hours per employee for all projects he or
she works on is 56 hrs per week‖
 A constraint specification language may have to be used to express
these
 SQL allows triggers and ASSERTIONS to express for some of these

2.18
 Design Phases

 Initial phase -- characterize fully the data needs of the prospective

database users.
 Second phase -- choosing a data model
• Applying the concepts of the chosen data model
• Translating these requirements into a conceptual schema of the
database.
• A fully developed conceptual schema indicates the functional
requirements of the enterprise.
 Describe the kinds of operations (or transactions) that will be
performed on the data.

2.19
 Design Phases (Cont.)

 Final Phase -- Moving from an abstract data model to the implementation

of the database
• Logical Design – Deciding on the database schema.
 Database design requires that we find a ―good‖ collection of
relation schemas.
 Business decision – What attributes should we record in the
database?
 Computer Science decision – What relation schemas should we
have and how should the attributes be distributed among the
various relation schemas?
• Physical Design – Deciding on the physical layout of the database

2.20
 Design Alternatives

 In designing a database schema, we must ensure that we avoid two

major pitfalls:
• Redundancy: a bad design may result in repeat information.
 Redundant representation of information may lead to data
inconsistency among the various copies of information
• Incompleteness: a bad design may make certain aspects of the
enterprise difficult or impossible to model.
 Avoiding bad designs is not enough. There may be a large number of
good designs from which we must choose.

2.21
 Design Approaches

 Entity Relationship Model (covered in this chapter)

• Models an enterprise as a collection of entities and relationships
 Entity: a ―thing‖ or ―object‖ in the enterprise that is distinguishable
from other objects
• Described by a set of attributes
 Relationship: an association among several entities
• Represented diagrammatically by an entity-relationship diagram:
 Normalization Theory
• Formalize what designs are bad, and test for them

2.22
Outline of the ER Model

2.23
 Entity Sets

 An entity is an object that exists and is distinguishable from other

objects.
• Example: specific person, company, event, plant
 An entity set is a set of entities of the same type that share the same
properties.
• Example: set of all persons, companies, trees, holidays
 An entity is represented by a set of attributes; i.e., descriptive properties
possessed by all members of an entity set.
• Example:
instructor = (ID, name, salary )
course= (course_id, title, credits)
 A subset of the attributes form a primary key of the entity set; i.e.,
uniquely identifying each member of the set.

2.25
 Representing Entity sets in ER Diagram

 Entity sets can be represented graphically as follows:

• Rectangles represent entity sets.
• Attributes listed inside entity rectangle
• Underline indicates primary key attributes

2.27
 Relationship Sets

 A relationship is an association among several entities

Example:
44553 (Peltier) advisor 22222 (Einstein)
student entity relationship set instructor entity
 A relationship set is a mathematical relation among n  2 entities, each
taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}

where (e1, e2, …, en) is a relationship

• Example:
(44553,22222)  advisor

2.28
 Relationship Sets (Cont.)

 Example: we define the relationship set advisor to denote the

associations between students and the instructors who act as their
advisors.
 Pictorially, we draw a line between related entities.

2.29
 Representing Relationship Sets via ER Diagrams

 Diamonds represent relationship sets.

2.30
 Relationship Sets (Cont.)

 An attribute can also be associated with a relationship set.

 For instance, the advisor relationship set between entity sets instructor
and student may have the attribute date which tracks when the student
started being associated with the advisor

76766 Crick 98988 Tanaka

45565 Katz 3 May 2008 12345 Shankar
10 June 2007
10101 Srinivasan 00128 Zhang
12 June 2006

98345 Kim 6 June 2009 76543 Brown

76543 Singh 30 June 2007
76653 Aoi
31 May 2007
22222 Einstein 23121 Chavez
4 May 2006

instructor 44553 Peltier

student

2.31
Relationship Sets with Attributes

2.32
 Roles

 Entity sets of a relationship need not be distinct

• Each occurrence of an entity set plays a ―role‖ in the relationship
 The labels ―course_id‖ and ―prereq_id‖ are called roles.

2.33
 Degree of a Relationship Set

 Binary relationship
• involve two entity sets (or degree two).
• most relationship sets in a database system are binary.
 Relationships between more than two entity sets are rare. Most
relationships are binary. (More on this later.)
• Example: students work on research projects under the guidance of
an instructor.
• relationship proj_guide is a ternary relationship between instructor,
student, and project

2.34
 Non-binary Relationship Sets

 Most relationship sets are binary

 There are occasions when it is more convenient to represent
relationships as non-binary.
 E-R Diagram with a Ternary Relationship

2.35
 Complex Attributes

 Attribute types:
• Simple and composite attributes.
• Single-valued and multivalued attributes
 Example: multivalued attribute: phone_numbers
• Derived attributes
 Can be computed from other attributes
 Example: age, given date_of_birth
 Domain – the set of permitted values for each attribute

2.36
 Composite Attributes

 Composite attributes allow us to divided attributes into subparts (other

attributes).

composite name address

attributes

first_name middle_initial last_name street city state postal_code

component
attributes
street_number street_name apartment_number

2.37
Representing Complex Attributes in ER Diagram

2.38
 Mapping Cardinality Constraints

 Express the number of entities to which another entity can be associated

via a relationship set.
 Most useful in describing binary relationship sets.
 For a binary relationship set the mapping cardinality must be one of the
following types:
• One to one
• One to many
• Many to one
• Many to many

2.39
 Mapping Cardinalities

One to one One to many

Note: Some elements in A and B may not be mapped to any

elements in the other set

2.40
 Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any

elements in the other set

2.41
 Representing Cardinality Constraints in ER Diagram

 We express cardinality constraints by drawing either a directed line (),

signifying ―one,‖ or an undirected line (—), signifying ―many,‖ between the
relationship set and the entity set.

 One-to-one relationship between an instructor and a student :

• A student is associated with at most one instructor via the relationship
advisor
• A student is associated with at most one department via stud_dept

2.42
 One-to-Many Relationship

 one-to-many relationship between an instructor and a student

• an instructor is associated with several (including 0) students via
advisor
• a student is associated with at most one instructor via advisor,

2.43
 Many-to-One Relationships

 In a many-to-one relationship between an instructor and a student,

• an instructor is associated with at most one student via advisor,
• and a student is associated with several (including 0) instructors via
advisor

2.44
 Many-to-Many Relationship

 An instructor is associated with several (possibly 0) students via advisor

 A student is associated with several (possibly 0) instructors via advisor

2.45
 Total and Partial Participation

 Total participation (indicated by double line): every entity in the entity set
participates in at least one relationship in the relationship set

participation of student in advisor relation is total

 every student must have an associated instructor
 Partial participation: some entities may not participate in any relationship
in the relationship set
• Example: participation of instructor in advisor is partial

2.46
Notation for Expressing More Complex Constraints

 A line may have an associated minimum and maximum cardinality, shown

in the form l..h, where l is the minimum and h the maximum cardinality
• A minimum value of 1 indicates total participation.
• A maximum value of 1 indicates that the entity participates in at most
one relationship
• A maximum value of * indicates no limit.
 Example

• Instructor can advise 0 or more students. A student must have 1

advisor; cannot have multiple advisors

2.47
 Alternative (min, max) notation for
relationship 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

2.48
 The (min,max) notation for relationship
constraints

Read the min,max numbers next to the entity

type and looking away from the entity type

2.49
COMPANY ER Schema Diagram using
(min, max) notation

2.50
 Primary Key

 Primary keys provide a way to specify how entities and relations are
distinguished. We will consider:
• Entity sets
• Relationship sets.
• Weak entity sets

2.51
 Primary key for Entity Sets

 By definition, individual entities are distinct.

 From database perspective, the differences among them must be
expressed in terms of their attributes.
 The values of the attribute values of an entity must be such that they can
uniquely identify the entity.
• No two entities in an entity set are allowed to have exactly the same
value for all attributes.
 A key for an entity is a set of attributes that suffice to distinguish entities
from each other

2.52
 Primary Key for Relationship Sets

 To distinguish among the various relationships of a relationship set we use

the individual primary keys of the entities in the relationship set.
• Let R be a relationship set involving entity sets E1, E2, .. En
• The primary key for R is consists of the union of the primary keys of
entity sets E1, E2, ..En
• If the relationship set R has attributes a1, a2, .., am associated with it,
then the primary key of R also includes the attributes a1, a2, .., am
 Example: relationship set ―advisor‖.
• The primary key consists of instructor.ID and student.ID
 The choice of the primary key for a relationship set depends on the
mapping cardinality of the relationship set.

2.53
 Choice of Primary key for Binary Relationship

 Many-to-Many relationships. The preceding union of the primary keys is a

minimal superkey and is chosen as the primary key.
 One-to-Many relationships . The primary key of the ―Many‖ side is a
minimal superkey and is used as the primary key.
 Many-to-one relationships. The primary key of the ―Many‖ side is a minimal
superkey and is used as the primary key.
 One-to-one relationships. The primary key of either one of the participating
entity sets forms a minimal superkey, and either one can be chosen as the
primary key.

2.54
 Weak Entity Set

 An entity that does not have a key attribute and that is

identification-dependent on another entity type.
 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
relationship 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
• DEPENDENT is a weak entity type
• EMPLOYEE is its identifying entity type via the identifying
relationship type DEPENDENT_OF
2.55
 Weak Entity Sets (Cont.)

 An entity set that is not a weak entity set is termed a strong entity set.
 Every weak entity must be associated with an identifying entity; that is,
the weak entity set is said to be existence dependent on the identifying
entity set.
 The identifying entity set is said to own the weak entity set that it
identifies.
 The relationship associating the weak entity set with the identifying entity
set is called the identifying relationship.

2.56
 Expressing Weak Entity Sets

 In E-R diagrams, a weak entity set is depicted via a double rectangle.

 We underline the discriminator of a weak entity set with a dashed line.
 The relationship set connecting the weak entity set to the identifying
strong entity set is depicted by a double diamond.
 Primary key for section – (course_id, sec_id, semester, year)

2.57
E-R Diagram for a University Enterprise

2.58