0% found this document useful (0 votes)
6 views

Database Management Systems Week 2

Database Management Systems

Uploaded by

matt.0.porter
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

Database Management Systems Week 2

Database Management Systems

Uploaded by

matt.0.porter
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 60

Adapted for SEN2104 – DBMS

Week 2: Entity-Relationship Model

Database System Concepts


©Silberschatz, Korth and Sudarshan
2

Modeling
• 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: specific person, company, event, plant
• Entities have attributes
• Example: people have names and addresses
• 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
3

Entity Sets customer and loan


customer_id customer_ customer_ customer_ loan_ amount
name street city number
4

Relationship Sets
• A relationship is an association among several entities
Example:
Hayes borrower L-15
customer entity relationship set loan 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:
(Hayes, L-15)  borrower
5

Relationship Set borrower


customer_id customer_ customer_ customer_ loan_ amount
name street city number
6

Relationship Sets (Cont.)


• An attribute can also be a property of a relationship set.
• For instance, the takes relationship set between entity sets
student and section may have the attribute letter.

student
section
takes
7

Degree of a Relationship Set


• Refers to number of entity sets that participate in a
relationship set.
• Relationship sets that involve two entity sets are binary (or
degree two). Generally, most relationship sets in a database
system are binary.
• Relationship sets may involve more than two entity sets.

Example: Suppose employees of a bank may have jobs


(responsibilities) at multiple branches, with different jobs at
different branches. Then there is a ternary relationship set
between entity sets employee, job, and branch
• Relationships between more than two entity sets are rare.
Most relationships are binary. (More on this later.)
8

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,
customer_street, customer_city )
loan = (loan_number, amount )
• Domain – the set of permitted values for each attribute
• Attribute types:
• Simple and composite attributes.
• Single-valued and multi-valued attributes
• Example: multivalued attribute: phone_numbers
• Derived attributes
• Can be computed from other attributes
• Example: age, given date_of_birth
9

Composite Attributes
10

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
11

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
12

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
13

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
• customer_id 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.
14

Example
• Identify possible super keys, candidate keys and
primary keys for the given entity set below:

ssn sid lname fname telephone

432-86-4013 S1 Sharp James 276-633-5562

579-92-2233 S2 Ross Lily 618-369-1926

524-24-1011 S3 Adams Abby 978-834-6780

035-20-8796 S4 Ross James 618-369-1926

767-32-9182 S5 Briggs Linda 704-990-3447

213-21-3748 S6 Adams Abby 303-693-6395


15

Keys for Relationship Sets


• The combination of primary keys of the participating
entity sets forms a super key of a relationship set.
• (customer_id, account_number) is the super key of depositor
• NOTE: this means a pair of entity sets can have at most one
relationship in a particular relationship set.
• Example: if we wish to track all access_dates to each account by
each customer, we cannot assume a relationship for each access.
We can use a multivalued attribute though
• Must consider the mapping cardinality of the
relationship set when deciding what are the candidate
keys
• Need to consider semantics of relationship set in
selecting the primary key in case of more than one
candidate key
16

E-R Diagrams

• 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 (will study later)
17

E-R Diagram With Composite, Multivalued, and


Derived Attributes
18

Relationship Sets with Attributes


19

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
20

Cardinality Constraints
• 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:
• A customer is associated with at most one loan via the relationship
borrower
• A loan is associated with at most one customer via borrower
21

One-To-Many Relationship
• In a 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
22

Many-To-One Relationships
• In a many-to-one relationship, a loan is associated with
several (including 0) customers via borrower, a
customer is associated with at most one loan via
borrower
23

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
24

Cardinality Constraints

(a) (b)

(c) (d)

(a) one-to-one (b) one-to-many (c) many-to-one (d) many-to-many


25

Alternative Notation for Cardinality Limits


• Cardinality limits can also express participation constraints
26

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 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
• Example: participation of customer in borrower is partial
27

Existence Dependencies
• If the existence of entity x depends on the existence
of entity y, then x is said to be existence dependent
on y.
• y is a dominant entity (in example below, loan)
• x is a subordinate entity (in example below, payment)

loan loan-payment payment

If a loan entity is deleted, then all its associated payment entities


must be deleted also.
28

E-R Diagram with a Ternary Relationship


29

Binary vs. Non-Binary Relationships


• Some relationships that appear to be non-binary may
be better represented using binary relationships
• E.g. A ternary relationship parents, relating a child to his/her
father and mother, is best replaced by two binary relationships,
father and mother
• Using two binary relationships allows partial information (e.g. only
mother being know)
• But there are some relationships that are naturally non-binary
• Example: works_on
30

Example: Instructor Project Student

A design with one ternary (non-binary) relationship set.


31

Example: Instructor Project Student (Cont.)

iid pid sid


I1 P1 S2
I1 P2 S1
I2 P1 S3

iid name room pid title sid name


I1 Preston D400 P1 Project 1 S1 Jones
I2 Walters D411 P2 Project 2 S2 Conley
.. .. .. .. .. .. ..

Instructor Project Student


32

Example: Instructor Project Student (Cont.)


iid pid sid
I1 P1 S2
I1 P2 S1
I2 P1 S3
I2 P3 null
null P4 S4
null P5 S6
I3 P6 null
R

iid name room pid title sid name


I1 Preston D400 P1 Project 1 S1 Jones
I2 Walters D411 P2 Project 2 S2 Conley
.. .. .. .. .. .. ..

Instructor Project Student


33

Example: Instructor Project Student (Cont.)

A design with two binary relationship sets.


34

Example: Instructor Project Student (Cont.)


iid pid pid sid
I1 P1 P1 S2
I1 P2 P2 S1
I2 P1 P1 S3
I2 P3 P4 S4
I3 P6 P5 S6
R1 R2

iid name room pid title sid name


I1 Preston D400 P1 Project 1 S1 Jones
I2 Walters D411 P2 Project 2 S2 Conley
.. .. .. .. .. .. ..

Instructor Project Student


35

Mapping Cardinalities affect ER Design


• Can make access-date an attribute of account, instead of a relationship
attribute, if each account can have only one customer
• That is, the relationship from account to customer is many to one, or
equivalently, customer to account is one to many
36

Example

One-to-many

aid lname bid title aid

101 Taylor 1 Digital Design 101

102 Wilson 2 The Engineer's Guide 101

… … 3 The Art of Design 102

Author 4 Data Science Explained 101

… … …

Book (including R)
37

Example (Cont.)

Many-to-many

aid lname aid bid bid title

101 Taylor 101 1 1 Digital Design

102 Wilson 101 2 2 The Engineer's Guide

… … 102 1 3 The Art of Design

Author … … 4 Data Science Explained

… …
R
Book
38

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 any 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.
• Placement of relationship attributes
39

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 an 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.
40

Weak Entity Sets (Cont.)


• We depict a weak entity set by double rectangles.
• We underline the discriminator of a weak entity set with a
dashed line.
• payment_number – discriminator of the payment entity set
• Primary key for payment – (loan_number, payment_number)
41

Weak Entity Sets (Cont.)

loan_number amount payment payment payment


_number _date _amount
L1 1000
1 1/1/2023 300
L2 600
2 1/2/2023 300
Loan
3 1/3/2023 400

Payment (containing data for L1 only)


42

Weak Entity Sets (Cont.)

loan_number amount payment payment payment


_number _date _amount
L1 1000
1 1/1/2023 300
L2 600
2 1/2/2023 300
Loan
3 1/3/2023 400

1 1/1/2023 300

2 1/2/2023 300

Payment (containing data for L1 and L2)


43

Weak Entity Sets (Cont.)

loan_number amount loan payment payment payment


_number _number _date _amount
L1 1000
L1 1 1/1/2023 300
L2 600
L1 2 1/2/2023 300
Loan
L1 3 1/3/2023 400

L2 1 1/1/2023 300

L2 2 1/2/2023 300

Payment (including Loan_Payment)


44

Strong Entity Set Alternative

loan_number amount payment payment payment payment


_id _number _date _amount
L1 1000
P1 1 1/1/2023 300
L2 600
P2 2 1/2/2023 300
Loan
P3 3 1/3/2023 400

P4 1 1/1/2023 300

P5 2 1/2/2023 300

Payment
45

Strong Entity Set Alternative (Cont.)

loan loan payment payment payment payment


amount
_number _number _id _number _date _amount
L1 1000 L1 P1 1 1/1/2023 300
L2 600
L1 P2 2 1/2/2023 300
Loan
L1 P3 3 1/3/2023 400

L2 P4 1 1/1/2023 300

L2 P5 2 1/2/2023 300

Payment (including Loan_Payment)


46

More Weak Entity Set Examples


• In a university, a course is a strong entity and a
course_offering can be modeled as a weak entity.

• The discriminator of course_offering would be semester


(including year) and section_number (if there is more
than one section).

• If we model course_offering as a strong entity, we would


model course_number as an attribute. Then the
relationship with course would be implicit in the
course_number attribute
47

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

E-R Diagram for a Banking Enterprise


49

Reduction to Relation Schemas


• Primary keys allow entity sets and relationship sets
to be expressed uniformly as relation schemas that
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.
50

Representing Entity Sets as Schemas


• A strong entity set reduces to a schema with the same attributes.

• A weak entity set becomes a table that includes a column for the
primary key of the identifying strong entity set

payment = ( loan_number, payment_number, payment_date,


payment_amount )
51

Representing Relationship Sets as


Schemas
• A many-to-many relationship set is 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 borrower

borrower = ( customer_id, loan_number )


52

Storing Single-valued Attributes


• Each single-valued attribute has its own column.

eid fname lname telephone

1 Emma Johnson 3134411

2 Alex Harris 6762211

3 James Smith null

Employee

Single-valued attribute for


the telephone number.
53

Storing Multi-valued Attributes


• First attempt: Multiple values in one cell.
• Is this a good design?

eid fname lname telephone

1 Emma Johnson 3134411

2 Alex Harris 6762211;8881122;1894546

3 James Smith null

Employee

Multi-valued attribute for


the telephone number.
54

Storing Multi-valued Attributes (Cont.)


• Second attempt: Multiple columns.
• Is this a good design?

eid fname lname telephone1 telephone2 telephone3

1 Emma Johnson 3134411 null null

2 Alex Harris 6762211 8881122 1894546

3 James Smith null null null

Employee
55

Storing Multi-valued Attributes (Cont.)


• Third attempt: The “telephone” attribute goes in a different set.
56

Storing Multi-valued Attributes (Cont.)


• Third attempt: The “telephone” attribute goes in a different set.

eid fname lname pid telephone eid

1 Emma Johnson 1 3134411 1

2 Alex Harris 2 6762211 2

3 James Smith 3 8881122 2

Employee 4 1894546 2

Phone
57

Storing Composite Attributes


• Each component in the composite attribute has its own column.

eid fname lname

1 Emma Johnson

2 Alex Harris

3 James Smith

Employee Composite attribute


“fullname”
58

Storing Derived Attributes


• Derived attributes are not directly stored but are calculated from
stored attributes when needed.

eid fname lname date_of_birth

1 Emma Johnson 15.02.1990

2 Alex Harris 03.06.2004

3 James Smith 07.03.1989

Employee Derived attribute “age”


59

Example: Bookstore
60

Alternative E-R Notations

You might also like