6.1

Chapter 6: Database Design and the ER Chapter 6: Database Design and the ER ModelModel

Skip 6.5.3, 6.10, 6.11

6.2

What is involved in database design?What is involved in database design?

Understand the information of interest

Understand what you want to do with it

Steps: understand needs of prospective users → requirements specification

conceptual design → ER model

logical design → logical model

physical design → file organization, internal storage,...

Focus on the information

Not part of this but important later: queries

application programs

What can go wrong? leaving out information you will need

misunderstanding the information

6.3

Your ProjectYour Project

What is the enterprise

What is the information of interest

What do you want to do with it

6.4

ModelingModeling

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

6.5

Entity Sets Entity Sets customercustomer and and loanloancustomer_id customer_ customer_ customer_ loan_ amount name street city number

6.6

Relationship Set Relationship Set borrowerborrower

Distinction between relation (relational model) and relationship set (ER model)This is the set of links between two entity sets

6.7

Relationship Sets (Cont.)Relationship Sets (Cont.)

A relationship set can have an attribute

E.g. the depositor relationship may have attribute access_date

6.8

Degree of a Relationship SetDegree of a Relationship Set

Relationship sets may involve more than two entity sets

Example: employees of a bank may have jobs at different branches

Ternary relationship set among entity sets employee, job, and branch

employee(name,..) job(title,...) branch(name, city, assets)

Smith.. (employee info) teller ...(duties etc.) CNLB Aurora 10000

Jones ... custodian ... First Bank Auburn 1000 loan officer ...

Degree: number of entity sets that participate in a relationship set

Most relationship sets are binary

6.9

AttributesAttributes

An entity has attributes (like a relation) customer = (cust_id, cust_name, cust_street, cust_city

loan = (loan_number, amount )

Attribute types: simple and composite

single-valued and multi-valued

multivalued: phone_numbers

derived: can be computed from other attributes

example: age, given date_of_birth

6.10

Mapping CardinalitiesMapping Cardinalities

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 is one to one (monogamy)

one to many (polygyny)

many to one (polyandry)

many to many (group marriage)

6.11

Mapping Cardinalities Mapping Cardinalities

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

one to one one to many many to one many to many

6.12

KeysKeys

Super key, candidate key, primary key for entity sets as before

Keys for relationship sets?

Combining primary keys of the participating entity sets forms a super key of a relationship set

(customer_id, account_number) is the super key of borrower

6.13

E-R DiagramsE-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

6.14

E-R Diagram With Composite, Multivalued, and E-R Diagram With Composite, Multivalued, and Derived AttributesDerived Attributes

6.15

Relationship Sets with AttributesRelationship Sets with Attributes

6.16

RolesRoles

Entity sets of a relationship need not be distinct

Labels “manager” and “worker” are roles

Roles are indicated by labeling the lines that connect diamonds to rectangles (optional)

6.17

Cardinality ConstraintsCardinality Constraints

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

6.18

Indicating Cardinality ConstraintsIndicating Cardinality Constraints

By directed ( = “one”) or undirected lines (— = “many”)

One-to-one: a customer is associated with at most one loan via relationship

borrower

a loan is associated with at most one customer via borrower

6.19

One-To-Many (a) and Many-To-One (b)One-To-Many (a) and Many-To-One (b)

(a) a loan is associated with at most one customer via borrower, a customer many have several (including 0) loans (b) a loan is associated with several (including 0) customers via borrower...

6.20

Many-To-Many RelationshipMany-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

6.21

Participation of an Entity Set in a Participation of an Entity Set in a Relationship SetRelationship Set

Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set

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

6.22

Participation of an Entity Set in a Participation of an Entity Set in a Relationship SetRelationship Set

Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set. participation of loan in borrower is total: every loan must have a

customer associated with it.

Partial participation: some entities may not participate in any relationship in the relationship set. participation of customer in borrower is partial: some customers have

no loans.

6.23

Alternative Notation for Cardinality LimitsAlternative Notation for Cardinality Limits

Cardinality limits can also express participation constraints

6.24

E-RE-R Diagram with a Ternary Relationship Diagram with a Ternary Relationship

6.25

Cardinality Constraints on Ternary Cardinality Constraints on Ternary RelationshipsRelationships

At most one arrow out of a ternary (or greater degree) relationship. e.g. an arrow from works_on to job indicates each employee works on at

most one job at any branch.

More than one arrow allows two meanings. e.g. an arrow from works_on to job and branch R between A, B and C

with arrows to B and C could mean

1. each employee works on most one job at one branch or

2. each (employee, job) pair is associated with a unique

branch entity, and each (employee, branch) pair is associated with a

unique job

To avoid confusion, allow only one arrow

6.26

Design IssuesDesign Issues

Use of entity sets vs. attributes exercise: construct a diagram for a child with mother and father as

attributes. Is there a better way?

Use of entity sets vs. relationship sets exercise: replace job by attributes of works_on in slide 24

compare the two

Binary versus n-ary relationship sets is there a neat way to represent slide 24 using binary relationships?

Placement of relationship attributes can access_date in slide 15 be an attribute of loan under an

conditions?

6.27

Binary Vs. Non-Binary RelationshipsBinary 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, might

best be replaced by two binary relationships, father and mother

using two binary relationships allows partial information (e.g. only mother being known)

some relationships are naturally non-binary (works_on, slide 24)

Non-binary relationships can be converted to binary:

(don't bother)

6.28

Mapping Cardinalities affect ER DesignMapping 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

6.29

Weak Entity SetsWeak 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 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.

6.30

Weak Entity SetsWeak Entity Sets

Weak entity set: An entity set that has no primary key.

Its existence depends on the existence of a strong entity set. There is no payment without an associated loan.

If a loan entity is deleted, all associated payments must be deleted.

Depicted by double rectangles

double lines (total participation)

one-to-many cardinality (one loan may have many payments).

6.31

Weak Entity Sets (Cont.)Weak Entity Sets (Cont.)

The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes it among all the other entities dependent on the same strong entity. payment_number – discriminator of the payment entity set

The primary key of a weak entity set: the primary key of the associated strong entity set plus the discriminator. primary key for payment – (loan_number, payment_number)

Exercise: Construct an ER diagram for strong entity course and weak entity course_offering. What are the primary and partial keys?

6.32

More Weak Entity Set ExamplesMore 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

6.33

Extended E-R Features: SpecializationExtended E-R Features: Specialization

Top-down design process; we designate sub groupings within an entity set that are distinctive from other entities in the set.

These sub groupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set.

Depicted by a triangle component labeled ISA (E.g. customer “is a” person).

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.

6.34

SpecializationSpecialization

Analogous to inheritance in C++.

Top-down design process. Designate sub groupings within an entity set.

These become lower-level entity sets that have attributes or relationships that do not apply to the higher-level entity set.

Depicted by a triangle component labeled ISA (i.e., saving_account “is an” account).

Attribute inheritance: a lower-level entity set inherits the attributes and relationship participation of the higher-level entity set.

6.35

Specialization ExampleSpecialization Example

6.36

GeneralizationGeneralization

Bottom-up: combine entity sets that share some features into a higher-level entity set.

Specialization and generalization are inverses.

Represented in an E-R diagram in the same way.

The terms are used interchangeably.

Can have multiple specializations based on different features. E.g. permanent_employee vs. temporary_employee

officer vs. secretary vs. teller

An employee would be in each specialization

The ISA relationship also referred to as superclass - subclass relationship

6.37

Specialization/Generalization Specialization/Generalization Design Constraints Design Constraints

Which entities can be in a given lower-level entity set. condition-defined. E.g. all customers over 65 are members of

senior_citizen entity set. user-defined

Whether or not entities may belong to more than one lower-level entity set. disjoint

an entity can belong to only one lower-level entity set

noted in E-R diagram by writing disjoint next to the ISA triangle overlapping

an entity can belong to more than one lower-level entity set

Completeness – whether an entity in the higher-level entity set must belong to at least one of the lower-level entity sets. total: an entity must belong to one of the lower-level entity sets partial: an entity need not belong to one of the lower-level entity sets

6.38

AggregationAggregation

Suppose we have a ternary relationship works_on and want to record managers for tasks performed by an employee at a branch

6.39

Aggregation (Cont.)Aggregation (Cont.)

works_on and manages represent redundant information every manages relationship corresponds to a works_on relationship

some works_on relationships may not correspond to any manages

So we can’t discard works_on

eliminate this redundancy via aggregation

The diagram represents: an employee works on a

particular job at a particular branch

an employee, branch, job combination may have an associated manager

6.40

Another Aggregation ExampleAnother Aggregation Example

Loan customers may be advised by a loan_officer. How do we relate

the customer/loan with the loan_officer?

6.41

E-R Diagram for a Banking EnterpriseE-R Diagram for a Banking Enterprise

6.42

Reduction Relation SchemasReduction Relation Schemas

An E-R diagram for a database can be represented by a collection of relation schemas.

Each entity set schema (table) with same name

Each relationship schema with same name

Each schema has attributes

Process: E-R diagram relation schemas relational database.

6.43

Example:Example:

customer(customer_id, customer_name, customer_street, customer_city)

account(account_number, balance)

depositor(customer_id, account_number, access_date)

6.44

What about this one?What about this one?

Option 1:

account(account_number, balance, branch_name)

branch (branch_name, branch_city, assets)

account_branch (account_number, branch_name)

Option 2:account (account_number, balance, branch_name)branch(branch_name, branch_city, assets)

(Many-to-one and one-to-many relationship sets that are total on the many-side can be represented by adding the primary key of the one side to the many side)

6.45

This one?This one?

Option 1:

customer (customer_id, customer_name, customer_street, customer_city), loan (branch_name, branch_city, assets), borrower (account_number, branch_name)

Option 2:

customer (customer_id, customer_name, customer_street, customer_city,

branch_name, branch_city, assets)Why?

6.46

Representing Weak Entity SetsRepresenting Weak Entity Sets

The strong entity becomes a schema with all its attributes.

The weak entity includes a column for the primary key of the identifying strong entity set.

loan(loan_number, amount)

payment(loan_number, payment_number, payment_date, payment_amount)

6.47

Composite AttributesComposite Attributes

Composite attributes are flattened out by creating a separate attribute for each component attribute

customer(customer_id, ..., name.first_name, name,middle_initial,

name,last_name, address.street.street_number, ...)

6.48

Multivalued AttributesMultivalued Attributes

Multivalued attribute M of entity E is represented by a separate schema EM with attributes corresponding to the primary key of E and multivalued attribute M

Suppose a customer has multiple names

customer(customer_id, customer_name, customer_street, customer_city)

becomes

customer(customer_id, customer_street, customer_city)

names(customer_id, customer_name)

6.49

Representing Generalization as SchemaRepresenting Generalization as SchemaMethod 1:

A schema for the higher-level entity(person)

A schema for each lower entity set with the primary key of the generalized entity set.

person(name, street, city)

employee(name, salary)

customer(name, credit_rating)

employer(name, salary)

officer(name, office_number)

...

Drawback: getting information about, a customer requires accessing two or more relations, the one corresponding to the low-level schema and the one corresponding to the high-level schema

6.50

Representing Generalization as SchemaRepresenting Generalization as SchemaMethod 2:

A schema for each lower entity set with all

attributes of the generalized entity set.

officer(name, street, city, salary,

office_number)

customer(name, street, city, credit_rating)

...

If specialization is total, the schema for the

generalized entity set (person) not required

to store information

Drawback: street and city may be stored redundantly for people who are both customers and officers

Why might one be preferable?

6.51

Relations Corresponding to Aggregation Relations Corresponding to Aggregation

Create a table containing

1. primary key of the aggregated relationship,

2. primary key of the associated entity set, 3. any descriptive attributes

manages(employee_id, branch_name, title, manager_name).

works_on is redundant if we are willing to store null values for attributemanager_name in table manages

6.52

UML (Unified Modeling Language) NotationUML (Unified Modeling Language) Notation

See CS 310 Chapter 7, slide 13

6.53

UML Class Diagram Notation (Cont.)UML Class Diagram Notation (Cont.)

*Note reversal of position in cardinality constraint depiction*Generalization can use merged or separate arrows independent of disjoint/overlapping

overlapping

disjoint

6.54

E-R Diagram for Exercise 6.11E-R Diagram for Exercise 6.11

6.55

E-R Diagram for Exercise 6.21E-R Diagram for Exercise 6.21