Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Agenda
11 Session
Session Overview
Overview
22 ER
ER and
and EER
EER to
to Relational
Relational Mapping
Mapping
33 Database
Database Design
Design Methodology
Methodology and
and UML
UML
44 Mapping
Mapping Relational
Relational Design
Design to
to ER/EER
ER/EER Case
Case Study
Study
55 Summary
Summary and
and Conclusion
Conclusion
2
Session Agenda
Session Overview
ER and EER to Relational Mapping
Database Design Methodology and UML
Mapping Relational Design to ER/EER Case Study
Summary & Conclusion
Textbooks:
» Fundamentals of Database Systems (6th Edition)
Ramez Elmasri and Shamkant Navathe
Addition Wesley
ISBN-10: 0-1360-8620-9, ISBN-13: 978-0136086208 6th Edition (04/10)
4
Icons / Metaphors
Information
Common Realization
Knowledge/Competency Pattern
Governance
Alignment
Solution Approach
55
Agenda
11 Session
Session Overview
Overview
22 ER
ER and
and EER
EER to
to Relational
Relational Mapping
Mapping
33 Database
Database Design
Design Methodology
Methodology and
and UML
UML
44 Mapping
Mapping Relational
Relational Design
Design to
to ER/EER
ER/EER Case
Case Study
Study
55 Summary
Summary and
and Conclusion
Conclusion
6
Agenda
Sets
Relations and tables
Relational schema
Primary keys
Relational Database Design Using ER-to-Relational
Mapping
Mapping EER Model Constructs to Relations
Design a relational database schema
Based on a conceptual schema design
Seven-step algorithm to convert the basic ER model
constructs into relations
Additional steps for EER model
8
Sets
Sets
Two sets A and B are equal iff (if and only if) they have the
same elements
In other words, for every x: x is an element of A iff (if and
only if) x is an element of B
“More mathematically,”
∀ x { x ∈ A ⇔ x ∈ B } if and only if A = B
Therefore, as sets: {2, 5, 3, 7} = {2, 7, 5, 3, 5, 3, 3}
This reiterates what we have said previously
10
Relation
S A B
a 2
a 2
b 3
c 4
d 3
A relation is such a table
We will also write S(A,B) for table S with columns A and B
11
Relational Schema
12
Relational Schema
13
Relational Schema
Let’s verify
» A all lower case letters in English
» B all positive integers less than 100
» S(A,B) satisfies the condition that any two tuples that
are equal on A must also be equal on B
Our example was an instance of this relational
schema
S A B
a 2
a 2
b 3
c 4
d 3
14
Relations (1/8)
Relations (2/8)
S A B S B A
a 2 56 a
a 56 2 a
b 2 2 b
56 a
2 a
56 a
16
Relations (3/8)
Relations (4/8)
18
Relations (5/8)
Relations (6/8)
21
Relations (8/8)
22
Relational Databases
23
24
Sample Mapping of ER Schema to Relational Database Schema
25
26
ER-to-Relational Mapping Algorithm (2/9)
27
28
ER-to-Relational Mapping Algorithm (4/9)
29
30
ER-to-Relational Mapping Algorithm (6/9)
Alternative approach
• Use the relationship relation (cross-reference)
option as in the third option for binary 1:1
relationships
31
32
ER-to-Relational Mapping Algorithm (8/9)
33
34
Discussion and Summary of Mapping for ER Model Constructs (1/2)
35
36
Mapping EER Model Constructs to Relations
37
38
Mapping of Specialization or Generalization (2/2)
39
40
Mapping of Categories (Union Types)
41
42
Summary
43
Agenda
11 Session
Session Overview
Overview
22 ER
ER and
and EER
EER to
to Relational
Relational Mapping
Mapping
33 Database
Database Design
Design Methodology
Methodology and
and UML
UML
44 Mapping
Mapping Relational
Relational Design
Design to
to ER/EER
ER/EER Case
Case Study
Study
55 Summary
Summary and
and Conclusion
Conclusion
44
Agenda
45
Design methodology
Target database managed by some type of database
management system
Various design methodologies
Large database
Several dozen gigabytes of data and a schema with
more than 30 or 40 distinct entity types
46
The Role of Information Systems in Organizations (1/3)
47
48
The Role of Information Systems in Organizations (3/3)
49
50
The Information System Life Cycle (2/4)
51
52
The Information System Life Cycle (4/4)
Application conversion
Testing and validation
Operation
Monitoring and maintenance
53
54
The Database Design and Implementation Process (2/4)
55
56
The Database Design and Implementation Process (3/4)
Parallel activities
Data content, structure, and constraints of the
database
Design of database applications
Data-driven versus process-driven design
Feedback loops among phases and within
phases are common
57
58
Phase 1: Requirements Collection and Analysis (1/2)
Activities
Identify application areas and user groups
Study and analyze documentation
Study current operating environment
Collect written responses from users
59
60
Phase 2: Conceptual Database Design (1/3)
61
62
Phase 2: Conceptual Database Design (3/3)
63
Costs to consider
Software acquisition cost
Maintenance cost
Hardware acquisition cost
Database creation and conversion cost
Personnel cost
Training cost
Operating cost
Consider DBMS portability among different types
of hardware
64
Phase 4: Data Model Mapping (Logical Database Design)
65
66
Phase 6: Database System Implementation and Tuning
67
68
UML for Database Application Design
Advantages of UML
Resulting models can be used to design relational,
object-oriented, or object-relational databases
Brings traditional database modelers, analysts, and
designers together with software application
developers
69
Structural diagrams
Class diagrams and package diagrams
Object diagrams
Component diagrams
Deployment diagrams
70
Different Types of Diagrams in UML (2/4)
Behavioral diagrams
Use case diagrams
Sequence diagrams
Collaboration diagrams
Statechart diagrams
Activity diagrams
71
72
Different Types of Diagrams in UML (3/4)
73
74
Modeling and Design Example: UNIVERSITY Database
75
76
Sample Class Diagram
77
78
Data Modeling Using Rational Rose Data Modeler (1/4)
Reverse engineering
Allows the user to create a conceptual data model
based on an existing database schema specified in a
DDL file
Forward engineering and DDL generation
Create a data model directly from scratch in Rose
Generate DDL for a specific DBMS
79
80
Data Modeling Using Rational Rose Data Modeler (3/4)
81
82
Automated Database Design Tools (1/3)
83
84
Automated Database Design Tools (3/3)
85
Summary
86
Agenda
11 Session
Session Overview
Overview
22 ER
ER and
and EER
EER to
to Relational
Relational Mapping
Mapping
33 Database
Database Design
Design Methodology
Methodology and
and UML
UML
44 Mapping
Mapping Relational
Relational Design
Design to
to ER/EER
ER/EER Case
Case Study
Study
55 Summary
Summary and
and Conclusion
Conclusion
87
A Case Study
88
From ER Diagrams To Relational Database
89
Small ER Diagram
90
More About The Example
91
Country
» RU
We create a table for Country “in the most
obvious way,” by creating a column for
each attribute (underlying the attributes
of the primary key) and this works:
92
Animal
Employee
There are five employees, listing for them: ID#, Name, (name of)
Child (note there may be any number of Child values for an
Employee, zero or more):
» 1, Alice, Erica, Frank
» 2, Bob, Bob, Frank
» 4, Carol
» 5, David
» 6, Bob, Frank
We create a table for Employee in the most obvious way, and this
does not work:
Replace (incorrect)
Employee ID# Name Child Child
1 Alice Erica Frank
2 Bob Bob Frank
4 Carol
5 David
6 Bob Frank
96
Employee And Child
97
Foreign Key
Note:
» Every row of Child has a single value of a primary
key of Employee, so every row of Child “maps” to a
single row of Employee
» Every row of Employee has zero or more rows of
Child mapped into it
In other words, no constraint
99
Likes (1/3)
100
Likes (2/3)
101
Likes (3/3)
» 2, IN 1 US
2 IN
» 5, IN 5 IN
» 6, CN 6 CN
103
Born (2/3)
104
Born (3/3)
105
Using Visio
106
Specifying A Relational Implementation
107
108
Relational Implementation For The Example
109
Cardinality Constraints
110
Specifying These Constraints (Revisited)
111
112
Crow’s Feet: Improved Arrow Notation
113
Crow’s Feet
114
Relational Implementation For The Example
116
Ends Of Lines (2/2)
118
Born Versus Likes (2/2)
Note that the many-to-one relationships are not of the same type in
both cases
The relationship between Likes and Employee indicates than when
you start from a row of Employee you end up in between 0 and
unbounded number of rows of Likes: no restriction
An employee can like any number of animals
The relationship between Born and Employee indicates that when
you start from a row of Employee you end up in between 0 and 1
rows of Born
An employee can be born in at most one country and therefore from
a row of Employee you end up in between 0 and 1 rows of Born: a
restriction
Born is really a (partial) one-to-one relationship
Such relationships are considered “strange”
119
120
Alternative For Born
Replace
Employee ID# Name Born ID# Cname
1 Alice 1 US
2 Bob 2 IN
4 Carol
5 IN
5 David
6 CN
6 Bob
121
Zebra Africa
122
Alternative Relational Implementation For The Example
123
The line between Animal and Likes is solid because the primary
key of the “many side”, Likes, includes the primary key of the “one
side”, Animal, so it “cannot exist” without it
The line between Employee and Likes is solid because the primary
key of the “many side”, Likes, includes the primary key of the “one
side”, Employee, so it “cannot exist” without it
The line between Employee and Child is solid because the primary
key of the “many side”, Child, includes the primary key of the “one
side”, Employee, so it “cannot exist” without it
The line between Country and Employee is dashed because the
primary key of the “many side”, Employee, does not include the
primary key of the “one side”, Country, so it “can exist” without it
124
Pattern Of Lines (2/2)
125
Example
126
Which Implementation To Use For Born?
127
To Remember!
128
Very Bad Diagram
129
Terrible Diagram
130
From ER Diagram To Relational Database
131
Our ER Diagram
132
Hierarchy For Our ER Diagram
133
We Will Produce
134
Horse (1/2)
135
Horse (2/2)
136
Person (1/3)
137
Person (2/3)
138
Person (3/3)
139
Child
140
Person And Child (1/2)
141
142
Automobile (1/2)
143
Automobile (2/2)
144
Likes (1/2)
145
Likes (2/2)
146
Car (1/2)
147
Car (2/2)
148
Type
149
Car
150
Type
151
Has
Has
154
ISA
155
Student
156
Student And ISA
157
Professor
158
Professor And ISA
159
Course (1/2)
160
Course (2/2)
161
Prerequisite (1/3)
162
Prerequisite (2/3)
Prerequisite (3/3)
164
Book (1/2)
165
Book (2/2)
166
Required (1/3)
Required (2/3)
168
Required (3/3)
169
Section (1/2)
171
Offered
172
Section + Offered
173
Took (1/3)
174
Took (2/3)
175
Took (3/3)
176
Taught (1/2)
177
Taught (2/2)
178
Monitors
179
Taught
180
Monitors
181
We Are Done
182
Arrow Notation
183
184
Additional Points
185
186
Recursive Relationships: Example (2/2)
187
A user accesses the database and attempts to delete row (or all
rows like this, recall that duplicates are permitted) 5,1 from
Professor
What should happen, as there is a row in Taught referencing this
row in Professor?
A user accesses the database and attempts to delete row 7,2 from
Professor?
What should happen, as there is a row in Taught referencing this
row in Professor?
189
190
Referential Integrity: Another Example
191
Temporal Databases
192
Summary: Strong Entity (1/2)
Example: Person
Create a table for the entity without multivalued and
derived attributes, flattening composite attributes
The primary key of this table will consist of the attributes
serving as primary key of the entity
Example table: Person
If there is a derived attribute, describe how it is
computed, but do not store it
If there is a multivalued attribute, create a table for it
consisting of it and attributes of the primary key of the
entity; do not put it in the table for the entity
Example table: Child
The primary key of this table will consist of all its
attributes
193
194
Summary: ISA And A Subclass
195
196
Summary: A Relationship That Is Not Binary Many-To-One
Example Took
The tables for the participating entities have already
been created
Create a table consisting of the primary keys of the
participating tables and the attributes of the relationship
itself
Of course, treat attributes of the relationship that are
derived, multivalued, or composite, appropriately, not
storing them, producing additional tables, flattening
them
The primary key consists of all the attributes of the
primary keys of the participating tables
Example table: Took
197
Example: Has
Do not create a table for this relationship
Put the attributes of the primary key of the “one” side
and the attributes of the relationship itself into the table
of the “many” side
Of course, treat attributes of the relation that are
derived, multivalued, or composite, appropriately, not
storing them, producing additional tables, flattening
them, as the case may be
You may decide to treat such a relationship the way you
treat a relationship that is not binary many to one (but
not in our class)
If the relationship is one-to-one, choose which side to
treat as if it were “many”
Example table: Has 198
Summary: Treating A Relationship As An Entity
199
Agenda
11 Session
Session Overview
Overview
22 ER
ER and
and EER
EER to
to Relational
Relational Mapping
Mapping
33 Database
Database Design
Design Methodology
Methodology and
and UML
UML
44 Mapping
Mapping Relational
Relational Design
Design to
to ER/EER
ER/EER Case
Case Study
Study
55 Summary
Summary and
and Conclusion
Conclusion
200
Summary
201
Readings
» Slides and Handouts posted on the course web site
» Textbook: Chapters 9 & 10
Assignment #2
» Textbook exercises: Textbook exercises: 7.17, 7.27, 7.30, 8.19, 8.21,
8.24
202
Next Session: Relational Algebra, Relational Calculus, and SQL
203
Any Questions?
204