Introduction to Database Management

Entity Relationship Model

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Database Design for a University
● A real university database would be much more complex than this design

● However, use this simplified model to help you understand conceptual ideas
without getting lost in details of a complex design

● The initial specification of user requirements may be based on interviews

with the database users, and on the designer’s own analysis of the
organization

● The description that arises from this design phase serves as the basis for
specifying the conceptual structure of the database

Database System Concepts - 6th Edition 7.2 ©Silberschatz, Korth and Sudarshan
 Database Design for a University
● The major characteristics of the university
● The University is organized into departments
● Each department is identified by a unique name (dept name), is located
in a particular building, and has a budget
● Each department has a list of courses it offers
● Each course has associated with it a course id, title, dept name, and
credits, and may also have associated prerequisites
● Instructors are identified by their unique ID
● Each instructor has name, associated department (dept name), and
salary
● Students are identified by their unique ID
● Each student has a name, an associated major department (dept name),
and tot cred (total credit hours the student earned thus far)

Database System Concepts - 6th Edition 7.3 ©Silberschatz, Korth and Sudarshan
 Database Design for a University
● The university maintains a list of classrooms, specifying the name of the
building, room number, and room capacity
● The university maintains a list of all classes (sections) taught
● Each section is identified by a course id, sec id, year, and semester, and
has associated with it a semester, year, building, room number, and time
slot id (the time slot when the class meets)
● The department has a list of teaching assignments specifying, for each
instructor, the sections the instructor is teaching
● The university has a list of all student course registrations,
specifying, for each student, the courses and the associated sections
that the student has taken (registered for)

Database System Concepts - 6th Edition 7.4 ©Silberschatz, Korth and Sudarshan
 Entity-Relationship Model
Entity-relationship Model
Typically used for conceptual database design
Information
System specific database Schema includes file
organization and choice of index structures

Relational Model Conceptual DB design

Typically used for logical database design
Mapping the conceptual schema defined using the
Conceptual Data Model
entity-relationship model into a relation schema

Logical DB design

Three Levels of Modeling

Logical Data Model

Physical DB design

Physical Data Model

Database System Concepts - 6th Edition 7.5 ©Silberschatz, Korth and Sudarshan
 ER Model
● How to design a database schema
● ER-data model
● Identify entities
● How those entities are related
● Associated set of constraints
● How to transform an E-R design into a set of basic relation schemas and
how to capture constraints

Database System Concepts - 6th Edition 7.6 ©Silberschatz, Korth and Sudarshan
 ER-Model
● Developed to facilitate database design by allowing specification of an
enterprise schema that represents the overall logical structure of a database
● Very useful in mapping the meanings and interactions of real-world enterprises
onto a conceptual schema
● Because of this usefulness, many database-design tools draw on concepts
from the ER model
● The ER data model employs three basic concepts:
● Entity sets,
● Relationship sets,
● Attributes

Database System Concepts - 6th Edition 7.7 ©Silberschatz, Korth and Sudarshan
 ER-Model
● Diagrammatic representation of a high-level data model
● Instead of representing all data in tables, it distinguishes between basic
objects, called entities, and relationships among these objects
● Often used as a first step in database-schema design
● A database can be modeled as:
● A collection of entities and
● Relationship among entities

Database System Concepts - 6th Edition 7.8 ©Silberschatz, Korth and Sudarshan
 ER-Model Entity
● An entity is a “thing” or “object” in the real world that is distinguishable
from all other objects
● Example: specific person, company, event, plant
● Entity has a set of properties, and the values for some set of properties may
uniquely identify an entity
● For example, person in a university is an entity
● Have a person id property whose value uniquely identifies that person
● Value 677-89-9011 for person id would uniquely identify one particular
person in the university
● Another example, courses can be thought of as entities, and course id
uniquely identifies a course entity in the university

Database System Concepts - 6th Edition 7.9 ©Silberschatz, Korth and Sudarshan
 ER-Model Entity Set
● A set of entities of the same type that share the same properties, or
attributes
● Entity set instructor: The set of all people who are instructors at a given
university
● Entity set student: The set of all students in the university
● Entity set song: The collection of all songs in a database
● Other Example: set of all persons, companies, trees, holidays

Database System Concepts - 6th Edition 7.10 ©Silberschatz, Korth and Sudarshan
 ER-Model Attributes

● An entity is represented by a set of attributes

● Attributes are descriptive properties possessed by each member of an entity
set
● Each entity may have its own value for each attribute
● Possible attributes of the instructor entity set are
ID, name, dept name, and salary
● In real life, there would be further attributes, such as
street number, apartment number, state, postal code, country
but we omit them to keep our examples simple
● Possible attributes of the course entity set are
course id, title, dept name, and credits
● A subset of the attributes form a primary key of the entity set; i.e., uniquely
identifying each member of the set

Database System Concepts - 6th Edition 7.11 ©Silberschatz, Korth and Sudarshan
 Entity Sets instructor and student

instructor_ID instructor_name student-ID student_name

Database System Concepts - 6th Edition 7.12 ©Silberschatz, Korth and Sudarshan
 Relationship Sets

● To manipulate the data better way

● To enforce constraint(s)

● A relationship is an association among several entities

● 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

Database System Concepts - 6th Edition 7.13 ©Silberschatz, Korth and Sudarshan
 Relationship Set advisor

Database System Concepts - 6th Edition 7.14 ©Silberschatz, Korth and Sudarshan
 Relationship Sets (Cont.)

● An attribute can also be property of 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

Database System Concepts - 6th Edition 7.15 ©Silberschatz, Korth and Sudarshan
 Degree of a Relationship Set
● Binary relationship
● Involve two entity sets (or degree two)
Most relationship sets in a database system are binary
Example: Student registers a course
● Relationships between more than two entity sets are rare
Example: students work on research projects under the guidance of
an instructor
Relationship proj_guide is a ternary relationship between
instructor, student, and project

Database System Concepts - 6th Edition 7.16 ©Silberschatz, Korth and Sudarshan
 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

Database System Concepts - 6th Edition 7.17 ©Silberschatz, Korth and Sudarshan
 Mapping Cardinalities
One to one

An entity in A is associated with

at most one entity in B, and
An entity in B is associated with
at most one entity in A

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

Example
An instructor is associated with at most one student via advisor
and a student is associated with at most one instructor via advisor

Database System Concepts - 6th Edition 7.18 ©Silberschatz, Korth and Sudarshan
 Mapping Cardinalities
One to many

An entity in A is associated with any number

(zero or more) of entities in B
And
An entity in B, however, can be associated with
at most one entity in A

Example
An instructor can advise several students and a student can be advised by only one instructor

The relationship set from instructor to student is one-to-many

Database System Concepts - 6th Edition 7.19 ©Silberschatz, Korth and Sudarshan
 Mapping Cardinalities
Many to one

An entity in A is associated with at most one entity

in B
And
An entity in B, however, can be associated with
any number (zero or more) of
entities in A

Example
An instructor may advise at most one student,
But a student may have many advisors

The relationship set from instructor to student is

many-to-one

Database System Concepts - 6th Edition 7.20 ©Silberschatz, Korth and Sudarshan
 Mapping Cardinalities
Many to many

An entity in A is associated with any

number (zero or more) of entities in B, And
an entity in B is associated with any
number (zero or more) of entities in A

Example
A student can be advised by several instructors (as in the
case of students advised jointly)

Database System Concepts - 6th Edition 7.21 ©Silberschatz, Korth and Sudarshan
 Attributes

● An entity is represented by a set of attributes, that is descriptive properties

possessed by all members of an entity set
● Example:
instructor = (ID, name, street, city, salary )
course= (course_id, title, credits)
● Domain – the set of permitted values for each attribute
● Attribute types:
● Simple and composite attributes
● Single-valued and multivalued attributes
● Derived attributes

Database System Concepts - 6th Edition 7.22 ©Silberschatz, Korth and Sudarshan
 Attributes

● Attribute types:
● Simple - Example: First_Name, Salary
● Composite

= Simple Attributes

Database System Concepts - 6th Edition 7.23 ©Silberschatz, Korth and Sudarshan
 Attribute Types

● Simple - Example: First Name, Salary

● Composite - Example: Name, Address
● Single-valued - Example: phone_number
● Multivalued attributes - Example: phone_numbers
● Derived attributes
● Can be computed from other attributes
● The value of a derived attribute is not stored but is computed when
required
● Example
Age, derived from given date_of_birth
Students advised (Represents how many students an instructor
advise) derived by counting the number of student entities
associated with that instructor

Database System Concepts - 6th Edition 7.24 ©Silberschatz, Korth and Sudarshan
 Keys
● Used to specify how entities within a given entity set are distinguished
● In other words, no two entities in an entity set are allowed to have exactly
the same value for all attributes
● Key are applicable to relation schemas also to identify relationships
uniquely, and thus distinguish relationships from each other
Types:
● Super key
● Candidate key
● Primary key
● Foreign key

Database System Concepts - 6th Edition 7.25 ©Silberschatz, Korth and Sudarshan
 Keys

● Super key
● A set of one or more attributes taken collectively whose values
uniquely determine each entity in the entity set
● Example
ID and name of instructor
ID and title of course
Course_ID and title of course

Database System Concepts - 6th Edition 7.26 ©Silberschatz, Korth and Sudarshan
 Keys

● Candidate key
● Requires super keys for which no proper subset is a super key
● A minimal super key of an entity set is called candidate key
● Example
ID is candidate key of instructor, Course_ID is candidate key of
course
● Several distinct sets of attributes can also serve as a candidate key

Database System Concepts - 6th Edition 7.27 ©Silberschatz, Korth and Sudarshan
 Keys
● Primary key
● Although several candidate keys may exist, one of the candidate keys is
selected to be the Primary Key by the database designer to identify
tuples within a relation
● Must be chosen with care, avoid repeated value attribute
● Select attribute whose values are never, or very rarely, changed
● NOTE: Primary key attributes in entity, relation should be underlined in
the model and listed before the other attributes in schema
● Example:
Instructor ID
In the United States, the social-security number attribute of a person
would be a candidate key
In India, VoterID, PAN ID

Database System Concepts - 6th Edition 7.28 ©Silberschatz, Korth and Sudarshan
 Keys
● Foreign key
● An entity, say e1, may include among its attributes the primary key of
another entity, say e2
● This attribute is called a foreign key from e1, referencing e2
● Entity e1 is called “referencing entity” of the foreign key
dependency
● Entity e2 is called “referenced entity” of the foreign key
● Example
Attribute dept name in instructor is a foreign key from instructor,
referencing department, since dept name is the primary key of
department
– In any database instance, given any tuple, say ta, from the instructor
entity, there must be some tuple, say tb, in the department entity such
that the value of the dept name attribute of ta is the same as the value
of the primary key, dept name, of tb

Database System Concepts - 6th Edition 7.29 ©Silberschatz, Korth and Sudarshan
 Redundant Attributes
● Suppose we have entity sets
● instructor, with attributes including dept_name
● a relationship inst_dept relating instructor and department
● Attribute dept_name in entity instructor is redundant since there is an explicit
relationship inst_dept which relates instructors to departments

Database System Concepts - 6th Edition 7.30 ©Silberschatz, Korth and Sudarshan
 University Schema- Entity Set, Attributes, Primary Key
1. Student
● Student (SID, name, tot cred) A good entity-relationship
2. Instructor design does not contain
● Instructor (IID, name, salary) redundant attributes
3. Department
● Department(dept name, building, budget)
4. Classroom
● Classroom(building, room number, capacity)
5. Course
● Course(cid, title, credits)
6. Section
● Section( cid, sid, semester, year)
7. Time slot
● Timeslot(tid, {(day, start time, end time) })

Database System Concepts - 6th Edition 7.31 ©Silberschatz, Korth and Sudarshan
 University Schema- Relationship Sets
1. inst dept: relating instructors with departments
2. stud dept: relating students with departments
3. teaches: relating instructors with sections
4. takes: relating students with sections, with a descriptive attribute
grade
5. course dept: relating courses with departments
6. sec course: relating sections with courses
7. sec class: relating sections with classrooms
8. sec time slot: relating sections with time slots
9. advisor: relating students with instructors
10. prereq: relating courses with prerequisite courses

Database System Concepts - 6th Edition 7.32 ©Silberschatz, Korth and Sudarshan
 E-R Diagrams

● Rectangles represent entity sets

● Diamonds represent relationship sets
● Attributes listed inside entity rectangle
● Underline indicates primary key attributes

Database System Concepts - 6th Edition 7.33 ©Silberschatz, Korth and Sudarshan
 Entity With Composite, Multivalued and Derived
Attributes

Database System Concepts - 6th Edition 7.34 ©Silberschatz, Korth and Sudarshan
 Relationship Sets

Database System Concepts - 6th Edition 7.35 ©Silberschatz, Korth and Sudarshan
 Relationship Sets with Attributes

Database System Concepts - 6th Edition 7.36 ©Silberschatz, Korth and Sudarshan
 Roles
● The function that an entity plays in a relationship is called that entity’s role
● Almost, entity sets participating in a relationship set are generally distinct
● Roles are implicit and are not usually specified

Database System Concepts - 6th Edition 7.37 ©Silberschatz, Korth and Sudarshan
 Roles
● But, if same entity set is used for the relationship i.e. the same entity set
participates in a relationship set more than once, in different roles
● Example, Course has Prerequisite Course

● Roles are useful when the meaning of a relationship needs clarification

● In this type of relationship set, sometimes called a recursive relationship set,
explicit role names are necessary to specify how an entity participates in a
relationship instance

Database System Concepts - 6th Edition 7.38 ©Silberschatz, Korth and Sudarshan
 Roles

● For example, consider the entity set course that records information about all
the courses offered in the university
● The first course of a pair takes the role of courseC1, whereas the second
takes the role of prerequisite course C2
● All relationships of prereq are characterized by (C1, C2) pairs; and (C2,
C1) pairs are excluded
● The labels “course_id” and “prereq_id” are called roles

Database System Concepts - 6th Edition 7.39 ©Silberschatz, Korth and Sudarshan
 Cardinality Constraints
● Express the number of entities to which another entity can
be associated via a relationship set
● 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

Database System Concepts - 6th Edition 7.40 ©Silberschatz, Korth and Sudarshan
 One-to-One Relationship

● One-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 at most one instructor via advisor

Database System Concepts - 6th Edition 7.41 ©Silberschatz, Korth and Sudarshan
 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
And
● A student is associated with at most one instructor via advisor,

Database System Concepts - 6th Edition 7.42 ©Silberschatz, Korth and Sudarshan
 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

Database System Concepts - 6th Edition 7.43 ©Silberschatz, Korth and Sudarshan
 Many-to-Many Relationship

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

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

Database System Concepts - 6th Edition 7.44 ©Silberschatz, Korth and Sudarshan
 Exercise
1. Identify the Entity Attributes and Primary Key for
1. Car
2. Player
2. Discover Primary key for the following:
1. Match(TeamA, TeamB, Date, TeamAScore, TeamBScore, RefID)
3. Describe the following Relationship:

4. Draw the following relationship:

1. A vehicle has many wheels, each wheel has one vehicle

Database System Concepts - 6th Edition 7.45 ©Silberschatz, Korth and Sudarshan
 Identify the Entity Attributes and Primary Key

1.Identify the Entity Attributes and Primary Key for

1.Car
2.Player

● Entity Car
● Colour
● Number of doors
● Convertible
● Registration number

● Car(Registration number, Colour, Number of doors, Convertible)

Database System Concepts - 6th Edition 7.46 ©Silberschatz, Korth and Sudarshan
 Identify the Primary Key for Entity Attributes:

● Entity:Player
● Name: string, Position: string, Number: integer, injured: boolean, Team:
string
Attribute Unique Reason

might have several players

Name No
with the same name

Position No might have two goalies

might be storing the details

of multiple teams, in which
Number No case each number has
several players from
different teams

several people might be

Injured No
injured at the same time
several players can play for
Team No
the same team
● Introduce another attribute that is unique for each player
● Player(PlayerID, Name, Position, Number, Injured, Team)

Database System Concepts - 6th Edition 7.47 ©Silberschatz, Korth and Sudarshan
 Discover Primary keys
2. Discover Primary key for the following:
● Match(TeamA, TeamB, Date, TeamAScore, TeamBScore, RefID)
Match(TeamA, TeamB, Date, TeamAScore, TeamBScore, RefID)

Database System Concepts - 6th Edition 7.48 ©Silberschatz, Korth and Sudarshan
 Describe the following Relationships:

Answer :
An animal has one genome
h A genome describes only one animal
a
s

Database System Concepts - 6th Edition 7.49 ©Silberschatz, Korth and Sudarshan
 Draw the following relationships:
● A vehicle has many wheels, each wheel has one vehicle
vehicle wheel

Database System Concepts - 6th Edition 7.50 ©Silberschatz, Korth and Sudarshan
 Weak Entity Sets

● An entity set that does not have a primary key

● The existence of a weak entity set depends on the existence of a
identifying entity set
● It must relate to the identifying entity set via a total,
one-to-many relationship set from the identifying to the weak
entity set
● Identifying relationship depicted using a double diamond
● The discriminator (or partial key) of a weak entity set is the set of
attributes that distinguishes among all the entities of a weak entity
set
● The primary key of a weak entity set is formed by the primary key
of the strong entity set on which the weak entity set is existence
dependent, plus the weak entity set’s discriminator

Database System Concepts - 6th Edition 7.51 ©Silberschatz, Korth and Sudarshan
 Weak Entity Sets (Cont.)
● Underline the discriminator of a weak entity set with a dashed line
● Put the identifying relationship of a weak entity in a double diamond
● Primary key for section – (course_id, sec_id, semester, year)

Database System Concepts - 6th Edition 7.52 ©Silberschatz, Korth and Sudarshan
 Participation of an Entity Set in a Relationship Set

● Total participation (indicated by double line): every entity in the entity

set participates in at least one relationship in the relationship set
● E.g., Participation of section in sec_course is total
Every section must have an associated course

● Partial participation: some entities may not participate in any

relationship in the relationship set
● Example: Participation of instructor in advisor is partial

Database System Concepts - 6th Edition 7.53 ©Silberschatz, Korth and Sudarshan
 Weak Entity

● Suppose a shop owner maintains the records of sell and customer

contact number only. Customer may have multiple contact numbers
and may provide one contact number or many contact numbers. With
the help of E-R diagram, show the entities and their attributes with
justification.

Database System Concepts - 6th Edition 7.54 ©Silberschatz, Korth and Sudarshan
 One of solutions

● Customer
● Strong entity, primary key: Cust_ID
● ContactNos
● Weak Entity, no primary key
● Relation
● CustomerContactNos

Database System Concepts - 6th Edition 7.55 ©Silberschatz, Korth and Sudarshan
 E-R Diagram with a Ternary Relationship

Database System Concepts - 6th Edition 7.56 ©Silberschatz, Korth and Sudarshan
 Extended ER Features

Database System Concepts - 6th Edition 7.57 ©Silberschatz, Korth and Sudarshan
 Extended E-R Features: Specialization

● Top-down design process

● subgrouping within an entity set that are distinctive from other entities in
the set
● These subgroupings become lower-level entity sets that have attributes or
participate in relationships that do not apply to the higher-level entity set
● Attribute inheritance – a lower-level entity set inherits all the attributes
and relationship participation of the higher-level entity set to which it is
linked

Database System Concepts - 6th Edition 7.58 ©Silberschatz, Korth and Sudarshan
 Extended ER Features: Generalization
● A bottom-up design process – combine a number of entity sets that
share the same features into a higher-level entity set
● Specialization and generalization are simple inversions of each other;
they are represented in an E-R diagram in the same way
● The terms specialization and generalization are used interchangeably

Database System Concepts - 6th Edition 7.59 ©Silberschatz, Korth and Sudarshan
 Specialization Example

Database System Concepts - 6th Edition 7.60 ©Silberschatz, Korth and Sudarshan
 Aggregation

● Consider the ternary relationship proj_guide

● Suppose wanted to record evaluations of a student by a guide on a project

Database System Concepts - 6th Edition 7.61 ©Silberschatz, Korth and Sudarshan
 Aggregation (Cont.)

● Relationship sets eval_for and proj_guide represent overlapping

information
● Every eval_for relationship corresponds to a proj_guide relationship
● So we can’t discard the proj_guide relationship
● Eliminate this redundancy via aggregation
● Treat relationship as an abstract entity
● Allows relationships between relationships
● Abstraction of relationship into new entity

Database System Concepts - 6th Edition 7.62 ©Silberschatz, Korth and Sudarshan
 Aggregation (Cont.)
● Without introducing redundancy, the following diagram represents:
● A student is guided by a particular instructor on a particular project
● A student, instructor, project combination may have an associated evaluation

Database System Concepts - 6th Edition 7.63 ©Silberschatz, Korth and Sudarshan
 department (dept name,
building, budget)
ER instructor (ID, name, salary) student (ID, name, tot cred)

Diagram
for a
University
Enterprise
course (course id, title, credits)

classroom (building, room number, capacity)

Database System Concepts - 6th Edition 7.64 ©Silberschatz, Korth and Sudarshan
 Reduction to Relational Schemas

Database System Concepts - 6th Edition 7.65 ©Silberschatz, Korth and Sudarshan
 Reduction to Relation Schemas
● Entity sets and relationship sets can be expressed uniformly as relation
schemas
● To represent the contents of the database
● A database which conforms to an E-R diagram can be represented by a
collection of schemas
● For each entity set and relationship set there is a unique schema that is
assigned the name of the corresponding entity set or relationship set
● Each schema has a number of columns (generally corresponding to
attributes), which have unique names

Database System Concepts - 6th Edition 7.66 ©Silberschatz, Korth and Sudarshan
 Mapping of an ER-Diagram to a Relational
Database
Five rules are defined to govern how relation/tables are
constructed:
– Rule for entity types
– Rule for relationships
– Rule for attributes
– Rule for generalization/specialization hierarchies
– Rule for participation constraint

Database System Concepts - 6th Edition 7.67 ©Silberschatz, Korth and Sudarshan
 Rule for Entity Types

• Each entity set is implemented with a separate relation

Strong Entities:- Strong, or regular, entities are mapped to their
own relation. The PK (Primary Key) is chosen from the set of
keys available
Weak Entities:- Weak entities are mapped to their own relation.
The PK of the weak entity is the combination of the PKs of
entities related through identifying relationships and the
discriminator (partial key) of the weak entity

Database System Concepts - 6th Edition 7.68 ©Silberschatz, Korth and Sudarshan
 Rule for Entity Types
Design Issue: Representing Strong Entity Set (Atomic attributes)

ID nam
● A strong entity set tot_cr
e
ed
A

● Reduces to a schema with the same attributes

student(ID, name, tot_cred)

student
ID name tot_cred

Database System Concepts - 6th Edition 7.69 ©Silberschatz, Korth and Sudarshan
 Rule for Entity Types
Design Issue: Representing Weak Entity Set (Atomic attributes)

● A weak entity set

● Becomes a table that includes a column for the primary key of the identifying
strong entity set ( no need of separate sec_course)
section ( course_id, sec_id, sem, year )

Database System Concepts - 6th Edition 7.70 ©Silberschatz, Korth and Sudarshan
 Rule for relationships
Design Issue: Representing Many to Many Relations

● A many-to-many relationship set

● Represented as a schema with attributes for the primary keys
of the two participating entity sets, and any descriptive
attributes of the relationship set
● Example: schema for relationship set advisor
advisor = (s_id, i_id)

Database System Concepts - 6th Edition 7.71 ©Silberschatz, Korth and Sudarshan
 Rule for relationships
Design Issue: Representing Many to 1 and 1 to Many Relations
● Many-to-one and one-to-many relationship sets that are total
Participation on the many-side
● Represented by adding an extra attribute to the “many” side,
containing the primary key of the “one” side
● Example: Instead of creating a schema for relationship set
inst_dept, add an attribute dept_name to the schema arising
from entity set instructor

Database System Concepts - 6th Edition 7.72 ©Silberschatz, Korth and Sudarshan
 Rule for relationships
Design Issue: Representing 1 to 1 Relations

● For one-to-one relationship sets, either side can be chosen to act as the
“many” side
● That is, extra attribute can be added to either of the tables
corresponding to the two entity sets

Database System Concepts - 6th Edition 7.73 ©Silberschatz, Korth and Sudarshan
 Rule for attributes
Design Issue: Entity Sets vs. Attributes (Multi Valued)
● An Example: Employees can have multiple phones
● Ignore multivalued attributes, if possible

(a) (b)

Employee vs Employee Use Phone

Ph_No no loc

Database System Concepts - 6th Edition 7.74 ©Silberschatz, Korth and Sudarshan
 Rule for attributes
Design Issue: Composite Attribute
● Example: Employee phone having std code + no
Address having Flat no, Apt, street, road
Employee
Employee
address
Flatno Apt …..
Flatno Apt

Solution
Composite attributes are flattened out by creating a separate attribute
for each attribute
Example: The entity set has four attributes addr_FlatNo, addr_Aprt,
addr_Street, and addr_road

Database System Concepts - 6th Edition 7.75 ©Silberschatz, Korth and Sudarshan
 Rule for Entity/Relationship
Design Issue: Entity Sets vs. Relationship Sets

An Example: How to model bank loans

Customer Loa Branch

Borr Loan
Customer ns
ows vs
ssn name bname bcity
ssn name lno amt
lno amt

(a)
(b)

Database System Concepts - 6th Edition 7.76 ©Silberschatz, Korth and Sudarshan
 Rule for Specialization
Design Issue: Specialization

● Method 1:
● Form a schema for the higher-level entity
● Form a schema for each lower-level entity set, include primary key of
higher-level entity set and local attributes

schema attributes
person ID, name, street, city
student ID, tot_cred
employee ID, salary

● Drawback: getting information about, an employee requires accessing two

relations, the one corresponding to the low-level schema and the one
corresponding to the high-level schema

Database System Concepts - 6th Edition 7.77 ©Silberschatz, Korth and Sudarshan
 Rule for Specialization
Design Issue: Specialization
● Method 2:
● Form a schema for each entity set with all local and inherited attributes
schema attributes
person ID, name, street, city
student ID, name, street, city, tot_cred
employee ID, name, street, city, salary

● If specialization is total, the schema for the generalized entity set (person) not
required to store information
● Can be defined as a “view” relation containing union of specialization
relations
● But explicit schema may still be needed for foreign key constraints
● Drawback: name, street and city may be stored redundantly for people who
are both students and employees

Database System Concepts - 6th Edition 7.78 ©Silberschatz, Korth and Sudarshan
 Rule for Aggregation
Design Issue: Aggregation
● To represent aggregation, create a schema containing
● primary key of the aggregated relationship,
● the primary key of the associated entity set
● any descriptive attributes

Database System Concepts - 6th Edition 7.79 ©Silberschatz, Korth and Sudarshan
 Rule for Aggregation
Design Issue: Aggregation
● For example,
eval_for (s_ID, project_id, i_ID, evaluation_id)

Database System Concepts - 6th Edition 7.80 ©Silberschatz, Korth and Sudarshan
 E-R Design Decisions
● The use of an attribute or entity set to represent an object.
● Whether a real-world concept is best expressed by an entity set or a
relationship set.
● The use of a ternary relationship versus a pair of binary relationships.
● The use of a strong or weak entity set.
● The use of specialization/generalization – contributes to modularity in the
design.
● The use of aggregation – can treat the aggregate entity set as a single unit
without concern for the details of its internal structure.

Database System Concepts - 6th Edition 7.81 ©Silberschatz, Korth and Sudarshan
 Normalization
A large database defined as a single relation may result in data duplication. This repetition of data
may result in:
1. Making relations very large.
2. It isn't easy to maintain and update data as it would involve searching many records in
relation.
3. Wastage and poor utilization of disk space and resources.
4. The likelihood of errors and inconsistencies increases.

To handle these problems, we should analyze and decompose the relations with redundant data
into smaller, simpler, and well-structured relations that are satisfy desirable properties.
Normalization is a process of decomposing the relations into relations with fewer attributes.

Normalization is the process of organizing the data in the database. Normalization is used to
minimize the redundancy from a relation or set of relations. It is also used to eliminate undesirable
characteristics like Insertion, Update, and Deletion Anomalies.

Normalization divides the larger table into smaller and links them using relationships. The normal
form is used to reduce redundancy from the database table.

Database System Concepts - 6th Edition 7.82 ©Silberschatz, Korth and Sudarshan
 Normalization
Why do we need Normalization?

The main reason for normalizing the relations is removing these anomalies.

Failure to eliminate anomalies leads to data redundancy and can cause data integrity and other
problems as the database grows.

Data modification anomalies can be categorized into three types:

Insertion Anomaly: Insertion Anomaly refers to when one cannot insert a new tuple into a
relationship due to lack of data.

Deletion Anomaly: The delete anomaly refers to the situation where the deletion of data results in
the unintended loss of some other important data.

Updation Anomaly: The update anomaly is when an update of a single data value requires
multiple rows of data to be updated.

Database System Concepts - 6th Edition 7.83 ©Silberschatz, Korth and Sudarshan
 Types of Normal Forms
Normalization works through a series of stages called Normal forms. The normal forms
apply to individual relations. The relation is said to be in particular normal form if it
satisfies constraints.

Database System Concepts - 6th Edition 7.84 ©Silberschatz, Korth and Sudarshan