6.1 chapter 6: database design and the er model skip 6.5.3, 6.10, 6.11
TRANSCRIPT
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