Download Lecture 7 part 1

Database Design
Lecture 7
Entity-relationship modeling
Text 3.1-3.7, 7.1
Database Designsemester
Slide 1
Overview



Entity-Relationship (ER) model is a popular high-level
conceptual data model.
Based on a perception of a real world that consists of a
collection of basic objects, called entities, and of the
relationships among these objects.
The ER model can be directly translated into relational tables.
Database Designsemester
Slide 2
Entities
A database can be modeled as:
– a collection of entities,
– relationship among entities.
 An entity is an object that exists and is distinguishable from
other objects.
Example: person, company, event, plant
 Entities have attributes
Example: people have names and addresses
 An entity set (aka entity type, entity class) is a set of entities of
the same type that share the same properties.
Example: set of all persons, companies, students.
Entity instance: a specific element in the entity set.

Database Designsemester
Slide 3
Attributes


An entity is represented by a set of attributes, that is, descriptive properties
possessed by all members of an entity set.
Example:
customer = (customer-id, customer-name,
customerstreet, customer-city)
Attribute Domain – the set of permitted values for each attribute
Attribute types:
– Simple and composite attributes.
 Eg composite attribute: address consists of street and city.
– Single-valued and multi-valued attributes
 E.g. multivalued attribute: phone-numbers
– Derived attributes
 Can be computed from other attributes
 E.g. age, given date of birth
Database Designsemester
Slide 4
Keys of Entity


Superkey
– subset of attributes which uniquely identify an entity (many
possibilities, eg, all attributes in relation, …...)
Candidate Key
– minimal superkey - unable to remove any attributes and still provide
unique identification of the entity
– EMPLOYEE (empno, ……, taxfileno)
– one is select as Primary Key (eg. empno)
– remaining candidate key/s known as Alternate Keys (taxfileno)
– PK’s may be
 simple PK (single attribute)
 CUSTOMER (custno, ….)
 composite PK (multiple attributes)
 ORDERLINE (orderno, prodno, quantity,…)
Database Designsemester
Slide 5
Drawing Entities and Attributes

Chen's Notation
stu_id
name
dob
age
phone
student
address
Rectangles represent entity sets.
rectangles represent entities
street
oval represent attributes
derived attributes use dotted line
multi-valued attributes use double line
primary key attribute indicated with underline
Database Designsemester
city
Slide 6
Relationship

Relationship
– association between two (or more) entities
Examples
Students Register for Subjects
School Has Staff
Driver Commits Traffic Offence
Customer Orders Product
Supplier Supplies Parts To Projects

Relationship type (aka relationship set)
– Set of similar associations among entity sets.
Database Designsemester
Slide 7
Types of Relationships


Degree of relationship
– UNARY – between entities from one entity set, recursive
– BINARY – between entities from two entity sets
– N-ARY – among entities from more than two entity sets
Relationship may have attributes
– eg, customer orders a product
 quantity is attribute of orders relationship
– A requirement of our text on attributes of relationship:
A relationship must be uniquely identifiable by the
participating entities without using the descriptive attributes
of the relationship.
Database Designsemester
Slide 8
Drawing Relationships

relationships represented by diamond
customer
product
orders
quantity
Database Designsemester
Slide 9
Example Relationships
Database Designsemester
Slide 10
Constraints on Relationships

Cardinality
– Given an entity instance e of some entity type, how many entity
instances of the related entity type can have the relationship with e.
– Example:
 Each student enrolls in 1 to 4 subjects,
 Each subject may be enrolled by 0 to 300 students.
Student
Database Designsemester
(1,4)
EnrolIn
(0,300)
Subject
Slide 11
Cardinality Ratio

Relationships can be classified as
– one-to-one (1:1)
One entity of type A corresponds to at most one entity of
type B, and vice versa
– one-to-many (1:M)
One entity of type A corresponds to more than one
entities in B, but one entity of type B may only
correspond to at most one entity of type A.
– Many-to-one: opposite to one-to-many
– many-to-many (M:N)
One entity of type A corresponds to more than one
entities of type B, and vice versa
Database Designsemester
Slide 12
Participation

Participation of entity instances in relationship can be
– Optional (partial)
eg, an employee may not have a spouse
 not every staff manages a department
– Mandatory (total)
eg, every spouse must be that of an employee
Every department is managed by some staff.

Mandatory participation is represented by double line
Database Designsemester
Slide 13
Examples
1
1
has
employee
1
CUSTOMER
N
place
(0,M)
STUDENT
ORDER
(1,1)
M
N
enrol
(1:M)
Database Designsemester
spouse
SUBJECT
(0:N)
Slide 14
Weak Entity



Existence depends on the existence of other entities
primary key partially or totally derived from owner entity
The relationship between the weak entity and its owner entity is
called weak relationship.
– Eg: Employee Has Dependent
Dependent can be regarded as a weak entity—only when
the attributes of Dependent can not uniquely identify a
dependent. Eg, Dependent has the attributes d_name and
d_birthdate only, but two employees may have
dependents with the same name and date of birth.
However employee_no and d_name uniquely identify
each dependent.
Employee is the owner entity
Has is the weak relationship
Database Designsemester
Slide 15
Representing Weak Entities and Relationships

Weak entity is indicated by a double line rectangle, and weak
relationship is represented by a double line diamond.
Employee
Has
1


M
Dependent
Participation of weak entity in weak relationship is always
mandatory.
A weak entity type may have more than one owner entity types.
Database Designsemester
Slide 16
Modelling with E-R Diagram






list the major entity sets in the system
represent the entity sets graphically by a rectangle
search for relationships between the entities and represent them
graphically by a diamond
add attributes, underline PK attribute/s
model relationship cardinality and participation
Do not include Foreign Keys (FK's) on ER Diagram
– FK used to depict relationship BUT relationship is already
present in ER due to relationship - thus never show FK on
ER
Database Designsemester
Slide 17
Example COMPANY Database

Requirements for the Company database
– The company is organized into DEPARTMENTs. Each
department has a name, number, and an employee who
manages the department. We keep track of the start date of
the department manager. A department may have several
locations
– Each department controls a number of PROJECTs. Each
project has a name, number, and is located at a single
location.
Database Designsemester
Slide 18
Example COMPANY Database (continued)
– We store each EMPLOYEE's social security number,
address, salary, sex, and birth date. Each employee works
for one department but may work on several projects. We
keep track of the number of hours per week that an
employee currently works on each project. We also keep
track of the direct supervisor of each employee.
– Each employee may have a number of DEPENDENTs. For
each dependent, we keep their name, sex, birth date, and
relationship to the employee.
Database Designsemester
Slide 19
Database Designsemester
Slide 20
Database Designsemester
Slide 21