DATABASE MANAGEMENT SYSTEM

Entity-Relationship Model

Subject Coordinator
Dr. Yatendra Sahu
Department of CSE

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 STEPS IN DATABASE DESIGN

• Requirements collection and analysis

• DB designers interview prospective DB users to understand and document data requirements
• Data requirements

• Functional requirements of the principal applications

• Conceptual or logical DB design

• Description of data requirements

• Detailed descriptions of components and constraints

• Transformed into implementation data model

• Result: DB schema in implementation data model of DBMS

• Conceptual DB design
• External or view design

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 A SAMPLE DATABASE APPLICATION

• Requirements gathered for COMPANY

• Employees, departments, and projects
• Company is organized into departments
• Department controls several projects
• Employee: require each employee’s name, Social Security number, address, salary, sex
(gender), and birth date
• Keep track of the dependents of each employee

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 ER MODEL OVERVIEW

• ER model describes data in terms of:

• Entities and entity sets
•Objects
• Relationships and relationship sets
• Connections between objects
• Attributes
• Properties that characterize or describe entities or relationships

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 ENTITIES AND ATTRIBUTES EXAMPLE

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 ENTITY SETS

• Entity type or set

• Collection (or set) of similar entities that have the same attributes

• ER model defines entity sets, not individual entities

• But entity sets described in terms of their attributes

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 CATEGORIES OF ATTRIBUTES

• Simple (atomic) vs. composite attributes

• Single-valued vs. multivalued attributes
• Stored vs. derived attributes
• Key or unique attributes
• Attribute values constrained to be distinct for Individual entities in entity set

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 ER DIAGRAM SYMBOLS

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 ER DIAGRAM SYMBOLS

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 INITIAL ER DIAGRAM FOR COMPANY
• Four entity types
• Most attributes are simple, single-valued, and stored
• Works on and Locations are multivalued
• Employee’s Name is composite
• Employee has one key, department and project have two keys, dependent has none

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 WEAK ENTITY TYPES

• Entity types that do not have key attributes of their own

• Identified by their relationship to specific entities from another entity type

•Dependent is meaningless in COMPANY DB

independently of Employee
•Identified by relationship to Employee
•Dependent_name distinguishes one
dependent from other dependents for the
same employee: partial key

•Identifying relationship
Relates a weak entity type to the identifying entity, which has the rest of the key

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 RELATIONSHIPS IN GENERAL

• Relationship
• Interaction between entities
• Indicator: an attribute of one entity refers to another entity
• Represent such references as relationships not attributes

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 RELATIONSHIPS
• Relationship
• Interaction between entities
• Indicator: an attribute of one entity refers to another entity
• Represent such references as relationships not attributes
• Relationship type R among n entity types E1, E2 , ..., En
• Defines a set of associations among entities from these entity types
• Relationship instance ri
• Each ri associates n individual entities (e1 , e2 , ..., en )
• Each entity ej in ri is a member of entity set Ej
• Relationships uniquely identified by keys of participating entities
• Degree of a relationship type
• Number of participating entity types
• e.g., binary, ternary

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 RELATIONSHIPS & RELATIONSHIP SETS

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 DIAGRAMMING RELATIONSHIP TYPE

•Diamond for relationship type

• Connected to each participating entity
type
• Could be binary, ternary, or higher
degree
•Remember:
• Represents a set of entities of each
type, some of which are related to
entities of the other type(s)
• Some entities might participate in
several relationships
• Some entities might not participate in
the relationship at all

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 RELATIONSHIPS WITH REPEATED ENTITY SETS

• Some relationships involve multiple entities from the same entity set
• e.g., games (two teams)
• e.g., recursive relationships, such as supervises (two employees)
• Role name
• Signifies role that participating entity plays in relationship instance
• Required when entity type participates multiple times in a relationship

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 Roles

• Entity sets of a relationship need not be distinct

• The labels “manager” and “worker” are called roles; they specify how employee
entities interact via the works-for relationship set.
• Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to
rectangles.
• Role labels are optional, and are used to clarify semantics of the relationship

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 Design Issues

• Use of entity sets vs. attributes

Choice mainly depends on the structure of the enterprise being modeled,
and on the semantics associated with the attribute in question.
• Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship set to describe an action
that occurs between entities
• Binary versus n-ary relationship sets
Although it is possible to replace a nonbinary (n-ary, for n > 2) relationship
set by a number of distinct binary relationship sets, a n-ary relationship set
shows more clearly that several entities participate in a single relationship.

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 Mapping Cardinalities
• 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
• We distinguish among these types by drawing either a directed line (→), signifying “one,”
or an undirected line (—), signifying “many,” between the relationship set and the entity
set.

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 One-To-One Relationship

• A customer is associated with at most one loan via the relationship

borrower
• A loan is associated with at most one customer via borrower

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 One-To-Many and Many-to-One Relationships

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 One-To-Many and Many-to-One (Cont.)

• In the one-to-many relationship (a), a loan is associated with at most

one customer via borrower; a customer is associated with several
(including 0) loans via borrower
• In the many-to-one relationship (b), a loan is associated with several
(including 0) customers via borrower; a customer is associated with
at most one loan via borrower

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 Many-To-Many Relationship

• A customer is associated with several (possibly 0) loans via borrower

• A loan is associated with several (possibly 0) customers via borrower

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 USING ROLE NAMES

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 RELATIONSHIP CONSTRAINTS
• Cardinality ratio
• Specifies maximum number of relationship instances in which each entity can participate
• Types 1:1, 1:N, or M:N
• Participation constraint
• Specifies whether existence of entity depends on its being related to another entity
• Types: total and partial
• Thus minimum number of relationship instances in which entities can participate: thus1 for
total participation, 0 for partial
• Diagrammatically, use a double line from relationship type to entity type

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 RELATIONSHIP CONSTRAINTS

• Alternative: Structural constraint

• Generalization: specifying any min and max participation
• Replaces cardinality ratio numerals and single/double line notation
• Associate a pair of integer numbers (min, max) with each participation of an entity type E in a
relationship type R, where 0 ≤ min ≤ max and max ≥ 1
• max=N finite, but unbounded

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 RELATIONSHIP ATTRIBUTES

• Relationship types can also have attributes

• Property that depends on both/all participating entities
• Example: Percentage of control that department has on a project

• Attributes of 1:1 or 1:N relationship types can be migrated to one of the

participating entity types
• For a 1:N relationship type, relationship attribute can be migrated only to entity
type on N-side of relationship
• Attributes on M:N relationship types must be specified as relationship attributes

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 REFINING EXAMPLE ER DESIGN
• Recall preliminary ER design

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 REFINING EXAMPLE ER DESIGN

• Change attributes that reference entity types into relationship types

• Weak entities use identifying relationship
• Determine cardinality ratio and participation constraints for each relationship type
• Weak entity type always has structural constraint of (1,1) participation in identifying relationship

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 APPROPRIATE ER MODEL DESIGN

• Choose names that convey meanings attached to various constructs.

• Nouns give rise to entity type names
• Verbs indicate names of relationship types
• Choose binary relationship names to make ER diagram readable from left to right and from top to
bottom
• Review all attributes
• Refine into a relationship if attribute references an entity type
• Attribute that exists in several entity types may be better modelled as an independent entity type

• Entities that must participate in a relationship with another entity type and with cardinality constraint
of 1 might be better modelled as weak entity

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 REVIEW HIGH-DEGREE RELATIONSHIPS

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 :Keys:

• A super key of an entity set is a set of one or more attributes whose values uniquely determine each entity
• A candidate key of an entity set is a minimal super key.
• social-security is candidate key of customer
• account-number is candidate key of account

• Although several candidate keys may exist, one of the candidate keys is selected to be the primary key.
• The combination of primary keys of the participating entity sets forms a candidate key of a relationship set.
• must consider the mapping cardinality and the semantics of the relationship set when selecting the
primary key.
• (social-security, account-number) is the primary key of depositor

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: DBMS(CSE-224) Semester: 4th
 Thank
You

Subject Coordinator: Dr. Yatendra Sahu Subject Name&Code: