Lecture2 ERModel

Entity-Relationship Model
Lecture # 2
Imran Siddiqi imran.siddiqi@mcs.edu.pk Computer Science Department College of Telecommunication Engineering National University of Sciences and Technology
Recap
Data Models
A collection of tools for describing:

Data Data relationships Data semantics Data constraints
Entity-Relationship model Relational model
CPS 480 Database Systems
CS Dept, MCS-NUST
Recap
ER Model
A high level data model based on perception of a real world comprising a collection of entities and of relationships among these entities
Relational Model
A lower level data model that uses a collection of tables to represent both data and relationships among those data
CS Dept, MCS-NUST
Recap
ER and Relational Models

Both are Conceptual data models Designers formulate the database schema by first modeling the data at a high level, using the ER model and then translate it into the relational model
CS Dept, MCS-NUST
ER Model
A popular data model useful to database designers
Graphical representation of miniworld
ER design is translated to Relational model Elements of ER Model

Entities Entity Sets Attributes Relationships
CS Dept, MCS-NUST
Entity & Entity Sets
Entity

An entity is a thing or object in the real world that is distinguishable from other objects. E.g. A person, a car, a bank account
Entities have attributes
E.g. People have names, addresses etc.
Entity Set

An entity set is a set of entities of the same type that share the same properties. E.g. set of customers in a bank, set of all students in a college etc.
CS Dept, MCS-NUST 6
Entity & Entity Sets
Examples of entities:

Person: EMPLOYEE, STUDENT, PATIENT Place: STORE, WAREHOUSE Object: MACHINE, PRODUCT, CAR Event: SALE,REGISTRATION, RENEWAL Concept: ACCOUNT, COURSE
Guidelines for naming and defining entity types:

An entity type name is a singular noun An entity type should be descriptive and specific An entity name should be concise
Entity Set Represented by a rectangle

CS Dept, MCS-NUST
Department Student
Attributes
An entity is represented by a set of attributes, that is descriptive properties possessed by all members of an entity set
E.g. name, address, weight, height are properties of a Person entity.
Guidelines for naming attributes:

An attribute name is a noun An attribute name should be unique To make an attribute name unique and clear, each attribute name should follow a standard format Similar attributes of different entity types should use similar but distinguishing names
CS Dept, MCS-NUST
Attributes
Properties of entities in entity set

Like fields in a struct Like columns in a table/spreadsheet Like data members in an object
Domain the set of permitted values for each attribute
E.g Name can take can be text strings of a certain length
Represented by Ovals
ID
Name Student
CS Dept, MCS-NUST
Attributes: Types
Simple & Composite Attributes
Simple attributes contain a single value

EmpNo Employee Name
ID
CS Dept, MCS-NUST
10
Attributes: Types
Simple & Composite Attributes
Composite attributes can be divided into sub-parts

EmpNo Employee FirstName Name MidName ID LastName
CS Dept, MCS-NUST
11
Attributes: Types
Single-Valued & Multi-Valued attributes
Multi-Valued attributes contain more than one value
Phone Employee
Email
CS Dept, MCS-NUST
12
Attributes: Types
Derived attributes
Computed from other attributes
Can be derived from DoB

Age Employee
Bonus
Can be derived from salary

CPS 480 Database Systems CS Dept, MCS-NUST 13
Attributes: Types
Key Attributes
Uniquely identify an entity

EmpNo Employee Name
ERD
EmpNo
Name John Wong Mary Cheung John Wong

CS Dept, MCS-NUST
... ... ... ...

14
Tabular
123456 456789 146777
Attributes: Types
Composite key
Name or Address alone cannot uniquely identify an employee, but together they can!
Address Employee Name
CS Dept, MCS-NUST
15
Attribute: Types

An entity can have more than one candidate keys One of them is selected as key the primary key In many cases, a key is artificially introduced (e.g., EmpNo) to make applications more efficient
Unique EmpNo Employee Name Primary Key
Unique
SS_Number
16
CS Dept, MCS-NUST
Relationship
A relationship is an association among several entities

Relationship name is an active or a passive verb.
Relationship name: writes Author Book
An author writes a book A book can be written by an author
CS Dept, MCS-NUST
17
Relationship
Given a customer and an account, the relationship deposits between them indicates that the customer deposits money into the account Hayes customer entity deposits relationship A-102 account entity
Students enroll in courses Students Enroll Courses
Represented by a diamond
Relationships

Students enroll in courses Courses are held in rooms
Students
Enroll
Courses
ID
Name
held Rooms
CS Dept, MCS-NUST
19
Relationship Sets

A relationship set is a set of relationships of the same type Mathematically, a relationship set is a relation among n 2 entity sets. If E1,E2,En are entity sets then a relationship set R is a subset of:
where (e1, e2, , en) is a relationship
{(e1, e2, en) | e1 E1, e2 E2, , en En}
Example:
(Hayes, A-102) Deposits
CS Dept, MCS-NUST
20
Representation of a Relationship
Deposits CustomerNo AccountNo A123456 B456789 B456789 A-101 A-201 A-302
A123456
A-101
B456789
A-201 A-302
CS Dept, MCS-NUST
21
Relationship Sets

Relationships can have descriptive attributes For instance, the deposits relationship set between entity sets customer and account may have the attribute access-date
Can we add multiple access dates? CustomerNo AccountNo A123456 B456789 B456789 A-101 A-201 A-302 AccessDate 25 Aug 2010 3 June 2009 2 Mar 2010
Note: A relationship instance in a relationship set must be uniquely identifiable from its participating entities without using the descriptive attributes
CS Dept, MCS-NUST
22
Degree of Relationships

Degree: number of entity types that participate in a relationship Three cases

Unary: between two instances of one entity type Binary: between the instances of two entity types Ternary: among the instances of three entity types
CS Dept, MCS-NUST
23
Unary/Recursive Relationships
A relationship relating entitles of the same type

manager
Employee
worker
work-for
Employees play different roles: manager or worker You can unfold a recursive relationship to understand it:
manager
worker
Employee
work-for
Employee
CS Dept, MCS-NUST
24
Unary/Recursive Relationships
Without Role Names
EmployeeNo EmployeeNo A1234 A1234 A6543 A8734
With Role Names
ManagerNo WorkerNo A1234 A1234 A6543 A8734
Where ManagerNo and WorkerNo are Valid EmployeeNo

Binary & Ternary Relationships
Employee works in a Department

- Binary Employee
Works_In
Department
Employee works in a Department at a particular location
- Ternary
Employee
Works_In
Department
Location
CS Dept, MCS-NUST
26
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
CS Dept, MCS-NUST
27
One to One (1:1)
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
CS Dept, MCS-NUST
28
One to One (1:1)
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
Customer
Borrows
Loan
Some elements in A and B may not be mapped to any elements in the other set
A customer can borrow 1 loan and vice versa

29
CS Dept, MCS-NUST
One to Many (1:M)
An entity in A is associated with any number (zero or more) of entities in B. An entity in B, however, can be associated with at most one entity in A
CS Dept, MCS-NUST
30
One to Many (1:M)
An entity in A is associated with any number (zero or more) of entities in B. An entity in B, however, can be associated with at most one entity in A
Customer
Borrows
Loan
Customer
Loan
A Customer can borrow more than 1 loan, whereas a loan has only one borrower
CS Dept, MCS-NUST 31
Many to One (M:1)
An entity in A is associated with at most one entity in B. An entity in B, however, can be associated with any number (zero or more) of entities in A
CS Dept, MCS-NUST
32
Many to Many (M:N)
An entity in A is associated with any number (zero or more) of entities in and an entity in B is associated with any number (zero or more) of entities in A
CS Dept, MCS-NUST
33
Many to Many (M:N)
An entity in A is associated with any number (zero or more) of entities in and an entity in B is associated with any number (zero or more) of entities in A
Customer
Borrows
Loan
Customer
Loan
A customer can borrow more than one loan A loan can have more than one borrower.
Participation Constraints
Total Participation The participation of an entity set E in a relationship set R is said to be total if every entity in E participates in at least one relationship in R
Partial Participation If only some entities in E participate in relationships in R, the participation of entity set E in relationship R is said to be partial
CS Dept, MCS-NUST
35
Participation Constraints
Example
Total
Customer
Borrows
Loan
Partial Every loan must have a customer Every customer (of the bank) does not borrow a loan
CS Dept, MCS-NUST
36
Keys
Super Key A set of one or more attributes that, taken collectively, allow us to identify uniquely an entity in the entity set
Customer_ID Customer_ID, Customer_Name Customer_ID, Customer_Address Customer_Name
If K is a super key so is any superset of K

Keys
Candidate Key The minimal superkeys for which none of its proper subsets is a superkey are called candidate keys
Customer_ID Customer_ID, Customer_Name
Primary Key: The principle key chosen by the DB designer

Keys for Relationship Sets

R Relationship set involving entities E1,E2, , En The set of attributes: primary-key(E1) U primary-key(E2) U U primarykey(En) Forms a superkey for the relationship set R
CS Dept, MCS-NUST
39
Keys for Relationship Sets
Example
Customer Borrows Loan
Key of Borrows? If the relationship is M:N If the relationship is 1:M If the relationship is 1:1 primary-keys of Customer & Loan primary-key of Loan primary-key of either entity
CS Dept, MCS-NUST
40
Reading Assignment
2.4.1 Use of Entity Sets versus Attributes 2.4.2 Use of Entity Sets versus Relationship Sets
CS Dept, MCS-NUST
41
Placement of Relationship Attributes
Design Decision
Access_Date
Customer
holds
Account
If the relationship is 1:1 Access_Date can be attribute of either entity If the relationship is 1:M Access_Date can be attribute of Account
If the relationship is 1:M Attributes of the relationship can be placed at the many side

If the relationship is M:N Access_Date must be associated with the relationship
Holds(Access_Date) Customer(Customer_Name) Account(Account_Number)
CS Dept, MCS-NUST
44
Entity Relationship Diagram
Rectangles represent entity sets. Diamonds represent relationship sets. Lines link attributes to entity sets and entity sets to relationship sets. Ellipses represent attributes Double ellipses represent multivalued attributes. Dashed ellipses denote derived attributes. Underline indicates primary key attributes
ER Diagram
Representing Cardinalities
Directed line represents 1 Un-directed line represents M

Relationship from customer to loan is one to many

46
CS Dept, MCS-NUST
ER Diagram: Cardinality Constraints
We express cardinality constraints by drawing a directed line (), signifying one, and an undirected line (), signifying many, between the relationship set and the entity set.
Directed line represents 1 Un-directed line represents M
CS Dept, MCS-NUST
47
One to One Relationships

A customer is associated with at most one loan via the relationship borrower A loan is associated with at most one customer via borrower
CS Dept, MCS-NUST
48
One to Many Relationship
In the one-to-many relationship a loan is associated with at most one customer via borrower, a customer is associated with several (including 0) loans via borrower
CS Dept, MCS-NUST
49
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
CS Dept, MCS-NUST
50
ER Diagram: Composite, Derived & Multivalued Attributes
CS Dept, MCS-NUST
51
ER Diagram: Relationship Set with Attributes
CS Dept, MCS-NUST
52
Recap
ER Diagram: Participation Constraints

Total Participation (Double line)
Every entity in the entity set participates in at least one relationship in the relationship set E.g. participation of loan in borrower is total every loan must have a customer associated to it via borrower
Partial Participation
Some entities may not participate in any relationship in the relationship set E.g. participation of customer in borrower is partial
ER Diagram: Participation Constraints
CS Dept, MCS-NUST
54
ER Diagram: Alternative Notation for Cardinality Limits
Cardinality limits can also express participation constraints Min..Max
Min = 1 indicates total participation Max= 1 indicates entity participates in at most 1 relationship Max = * indicates no limits
1..1 = Each loan will have only one customer 0..* = Customer can have zero or more loans What is the relationship? 1:1 or 1:m or m:n
CS Dept, MCS-NUST
56
1..1 = Each loan will have only one customer 0..* = Customer can have zero or more loans What if the customer edge was 1..* ? What if the customer edge was 1..1?
Weak Entity Sets
An entity set that does not have a primary key is referred to as a weak entity set.
The existence of a weak entity set depends on the existence of a identifying entity set
CS Dept, MCS-NUST
58
Weak Entity Sets

A
loan may have 240 payments, each identified by a payment no 1 - 240.

The
PaymentNo is unique given a particular loan but not unique globally
PaymentNo is called partial key or discriminator The primary key of Payment is the combination of LoanNo and PaymentNo.
CS Dept, MCS-NUST
59
Weak Entity Sets

Question 1 What is the cardinality of a weak relationship? Question 2 What is the participation of weak entity set? The identifying relationship is MANY TO ONE from the weak entity set to the identifying entity set and the participation of the weak entity set is TOTAL
Class Hierarchies
Entity Set Person
Name, DoB, Street, City
Person can be classified into Customer and Employee
Entity Set Customer
Name, DoB, Street, City, CustomerID
Entity Set Employee
Attributes of entity person
Name, DoB, Street, City, EmployeeID, Salaray
CS Dept, MCS-NUST
61
Class Hierarchies
Sometimes we need to define entities as derivations of others The attributes of an entity are those of another entity (its parent) plus other ones A class hierarchy can be seen in two different ways:

Specialization Generalization
CS Dept, MCS-NUST
62
Specialization

Top-down design process Depicted by a triangle component labeled ISA (E.g. customer is a person) The ISA relationship also referred to as superclass subclass relationship Can be applied repeatedly
CS Dept, MCS-NUST
63
Example
CS Dept, MCS-NUST
64
Generalization

Simple Inversion of Specialization Bottom-Up Approach Entity Set Customer
Name, DoB, Street, City, CustomerID
Entity Set Employee
Commone Attributes
Name, DoB, Street, City, EmployeeID, Salaray
Create an entity person with these common attributes
CS Dept, MCS-NUST
65
Class Hierarchies
In terms of ERD, no distinction is made between Specialization and Generalization
CS Dept, MCS-NUST
66
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.
Employee and Customer have attributes of person If person participates in a relationship so do Employee and Customer
CS Dept, MCS-NUST
67
Constraints on Specialization & Generalization

Constraints on which entities can be members of a given lower-level entity set
Condition-defined
E.g. all customers over 65 years are members of senior-citizen entity set; senior-citizen ISA person. Not assigned automatically Implemented by the designer
User-defined

CS Dept, MCS-NUST
68

Constraint on whether or not entities may belong to more than one lower-level entity set within a single generalization
Disjoint

An entity can belong to only one lower-level entity set An account type can be savings or checking Noted in E-R diagram by writing disjoint next to the ISA triangle An entity can belong to more than one lower-level entity set A customer can be employee as well
Overlapping

CS Dept, MCS-NUST
69

Completeness constraint -- specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within a generalization
Total

An entity must belong to one of the lower-level entity sets E.g. The account generalization is total An entity need not belong to one of the lower-level entity sets Example
Partial

Bank employees are assigned to one of four teams after a certain job duration Some employees might not be part of any team
Aggregation

Sometimes a relationship needs to relate one relationship with a collection of entities or other relationships Aggregation allows us to indicate that a relationship set participates in another relationship set
Department
Sponsors
Projects
Employees
Related to
Department assigns employees to monitor the sponsorship

Aggregation
Illustrated by drawing a dashed box around the set of related entities and relationships
CS Dept, MCS-NUST
72
ERD Banking Enterprise
CS Dept, MCS-NUST
73
ERD Symbol Summary
CS Dept, MCS-NUST
74
ERD Symbol Summary
CS Dept, MCS-NUST
75
ERD Alternative Notations
CS Dept, MCS-NUST
76
References
Chapter 2, Database System Concepts, Silberschatz, Korth, Sudarshan
CS Dept, MCS-NUST
77

Lecture2 ERModel

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture2 ERModel

Uploaded by

Copyright:

Available Formats

Entity-Relationship Model

A collection of tools for describing:

Data Data relationships Data semantics Data constraints

Entity-Relationship model Relational model

CPS 480 Database Systems

CPS 480 Database Systems

ER and Relational Models

CPS 480 Database Systems

A popular data model useful to database designers

Graphical representation of miniworld

ER design is translated to Relational model Elements of ER Model

Entities Entity Sets Attributes Relationships

CPS 480 Database Systems

Entity & Entity Sets

Entities have attributes

E.g. People have names, addresses etc.

CPS 480 Database Systems

Entity & Entity Sets

Guidelines for naming and defining entity types:

Entity Set Represented by a rectangle

CPS 480 Database Systems

E.g. name, address, weight, height are properties of a Person entity.

Guidelines for naming attributes:

CPS 480 Database Systems

Properties of entities in entity set

Domain the set of permitted values for each attribute

E.g Name can take can be text strings of a certain length

CPS 480 Database Systems

Simple & Composite Attributes

Simple attributes contain a single value

CPS 480 Database Systems

Simple & Composite Attributes

Composite attributes can be divided into sub-parts

CPS 480 Database Systems

Single-Valued & Multi-Valued attributes

Multi-Valued attributes contain more than one value

CPS 480 Database Systems

Computed from other attributes

Can be derived from DoB

Can be derived from salary

Uniquely identify an entity

Name John Wong Mary Cheung John Wong

... ... ... ...

123456 456789 146777

CPS 480 Database Systems

Address Employee Name

CPS 480 Database Systems

A relationship is an association among several entities

Relationship name: writes Author Book

An author writes a book A book can be written by an author

CPS 480 Database Systems

Students enroll in courses Students Enroll Courses

Students enroll in courses Courses are held in rooms

CPS 480 Database Systems

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

{(e1, e2, en) | e1 E1, e2 E2, , en En}

(Hayes, A-102) Deposits

CPS 480 Database Systems

CPS 480 Database Systems

Degree: number of entity types that participate in a relationship Three cases

CPS 480 Database Systems

A relationship relating entitles of the same type