Professional Documents
Culture Documents
1
Agenda
1 Session Overview
4 Case Study
2
Session Agenda
Session Overview
Data Modeling Using the Entity-Relationship (ER) Model
Data Modeling Using the Enhanced Entity-Relationship
(EER) Model
Case Study
Summary & Conclusion
3
What is the class about?
Textbooks:
Fundamentals of Database Systems (7th Edition)
Ramez Elmasri and Shamkant Navathe
Addition Wesley
ISBN-10: 0133970779, ISBN-13: 978-0133970777 7th Edition (06/18/15)
4
Icons / Metaphors
Information
Common Realization
Knowledge/Competency Pattern
Governance
Alignment
Solution Approach
5
Agenda
1 Session Overview
4 Case Study
6
Agenda
7
Overview of Database Design Process
8
Overview of Database Design Process
9
Methodologies for Conceptual Design
10
Using High-Level Conceptual Data Models for Database Design (1/2)
11
Using High-Level Conceptual Data Models for Database Design (2/2)
12
Purpose Of ER Model And Basic Concepts (1/2)
13
Purpose Of ER Model And Basic Concepts (2/2)
14
Example COMPANY Database
16
Basic Concepts
17
ER Model Concepts
18
Entities and Attributes
19
Entity Types, Entity Sets, Keys, and Value Sets (1/2)
Entity type
Collection (or set) of entities that have the
same attributes
20
Entity Types and Key Attributes (1)
21
Entity Types and Key Attributes (2)
22
Entity Types, Entity Sets, Keys, and Value Sets (2/2)
23
Entity And Entity Set (1/3)
24
Entity And Entity Set (2/3)
Person
26
Entity Set
27
Attribute (1/3)
FN LN DOB
Person
28
Attribute (2/3)
Attributes can be
Base (such as DOB); or derived denoted by dashed ellipses (such as
Age, derived from DOB and the current date)
Simple (such as DOB); or composite having their component
attributes attached to them (such as Address, when we think of it
explicitly as consisting of street and number and restricting ourselves
to one city only)
Singlevalued (such as DOB); or multivalued with unspecified in
advance number of values denoted by thick-lined ellipses (such as
Child; a person may have any number of childrenwe do not consider
children as persons at this point, this means that they are not entities,
just attributes of persons)
Number Street
Person
29
Attribute (3/3)
Person
30
Types of Attributes (1)
Simple
Each entity has a single atomic value for the attribute. For
example, SSN or Sex.
Composite
The attribute may be composed of several components. For
example:
Address(Apt#, House#, Street, City, State, ZipCode, Country),
or
Name(FirstName, MiddleName, LastName).
Composition may form a hierarchy where some components
are themselves composite.
Multi-valued
An entity may have multiple values for that attribute. For
example, Color of a CAR or PreviousDegrees of a STUDENT.
Denoted as {Color} or {PreviousDegrees}.
31
Types of Attributes (2)
32
Example of a composite attribute
33
Value Sets (Domains) of Attributes
34
Attributes and Value Sets
35
Displaying an Entity type
37
Entity Type CAR with two keys and a corresponding Entity Set
38
Keys (1/2)
City
39
Keys (2/2)
In our example:
Longitude and Latitude (their values) identify (at most) one City,
but only Longitude or only Latitude do not
(Longitude, Latitude) form a superkey, which is also a key
(Longitude, Latitude, Size, Name) form a superkey, which is not
a key, because Size and Name are superflous
(Country, State, Name) form another key (and also a superkey,
as every key is a superkey)
For simplicity, we assume that every country is divided
into states and within a state the city name is unique
City
40
Primary Keys
City
City
41
Initial Conceptual Design of Entity Types for COMPANY Database Schema
43
Refining the initial design by introducing relationships
44
Relationships and Relationship Types (1)
45
Relationship instances of the WORKS_FOR N:1 relationship between EMPLOYEE and
DEPARTMENT
46
Relationship instances of the M:N WORKS_ON relationship between EMPLOYEE
and PROJECT
47
Relationship type vs. relationship set (1)
Relationship Type:
Is the schema description of a relationship
Identifies the relationship name and the
participating entity types
Also identifies certain relationship constraints
Relationship Set:
The current set of relationship instances
represented in the database
The current state of a relationship type
48
Relationship Types, Relationship Sets, Roles, and Structural Constraints
Relationship
When an attribute of one entity type refers to
another entity type
Represent references as relationships not
attributes
49
Relationship Types, Sets, and Instances
50
Relationship Degree
51
Sample Ternary Relationship
52
Relationship type vs. relationship set (2)
53
Refining the COMPANY database schema by introducing relationships
54
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)
55
Discussion on Relationship Types
56
Recursive Relationship Type
57
Constraints on Relationships
58
Many-to-one (N:1) Relationship
59
Many-to-many (M:N) Relationship
60
Displaying a recursive relationship
61
A Recursive Relationship Supervision`
62
Role Names and Recursive Relationships
63
Sample Recursive Relationships
64
Constraints on Binary Relationship Types
65
Cardinality Constraints (1/8)
66
Cardinality Constraints (2/8)
67
Cardinality Constraints (3/8)
Vendor
68
Cardinality Constraints (4/8)
69
Cardinality Constraints (5/8)
71
Cardinality Constraints (7/8)
0..1
Person Born Country
72
Cardinality Constraints (8/8)
0..1
Person Born Country
0..1 0..1
Person Heads Country
73
Attributes of Relationship Types
74
Weak Entity Types
An entity that does not have a key attribute and that is identification-
dependent on another entity type.
A weak entity must participate in an identifying relationship type with
an owner or identifying entity type
Entities are identified by the combination of:
A partial key of the weak entity type
The particular entity they are related to in the identifying
relationship type
Example:
A DEPENDENT entity is identified by the dependents first name,
and the specific EMPLOYEE with whom the dependent is related
Name of DEPENDENT is the partial key
DEPENDENT is a weak entity type
EMPLOYEE is its identifying entity type via the identifying
relationship type DEPENDENT_OF
75
Weak Entity Types
76
Attributes of Relationship types
77
Example Attribute of a Relationship Type:
Hours of WORKS_ON
78
Notation for Constraints on Relationships
79
Relationship Summarized (1/2)
80
Sample Relationship (2/2)
81
Alternative (min, max) notation for relationship structural constraints:
82
The (min,max) notation for relationship constraints
83
COMPANY ER Schema Diagram using (min, max) notation
84
Alternative diagrammatic notation
85
Binary Relationship
Lets look at Likes, listing all pairs of (x,y) where person x Likes
product y, and the associated ER diagram
First listing the relationship informally (we omit article a):
Joe likes computer
Joe likes monitor
Tom likes computer
Max likes computer
Note
Not every person has to Like a product
Not every product has to be Liked
A person can Like many products
A product can be Liked by many persons
86
More on Relationships (1/2)
Let us elaborate
E1 E2 was the universe
It listed all possible pairs of a person liking a
product
At every instance of time, in general only
some of this pairs corresponded to the
actual state of the universe, R was the
set of such pairs
88
Relationships of Higher Degree
89
Discussion of n-ary relationships (n > 2)
90
Ternary Relationship
Vendor
91
Example of a ternary relationship
92
Discussion of n-ary relationships (n > 2)
93
Another example of a ternary relationship
94
Relationship With Non-Distinct Entity Sets (1/4)
Person Likes
95
Relationship With Non-Distinct Entity Sets (2/4)
Again:
Joe likes Tom
Joe likes Max
Tom likes Max
Tom likes Mike
Tom likes Tom
Max likes Tom
Formally Likes is a subset of the Cartesian product
Person Person, which is the set of all ordered pairs of
the form (person,person)
Likes is the set { (Joe,Tom), (Joe,Max), (Tom,Max),
(Tom,Mike), (Tom,Tom), (Max,Tom) }
Likes is an arbitrary directed graph in which persons
serve as vertices and arcs specify who likes whom
96
Relationship With Non-Distinct Entity Sets (3/4)
97
Relationship With Non-Distinct Entity Sets (4/4)
98
Refining the ER Design for the COMPANY Database
99
ER Diagrams, Naming Conventions, and Design Issues
100
ER Diagrams
City
Likes Person
SSN Name
101
Proper Naming of Schema Constructs
102
Design Choices for ER Conceptual Design
103
Alternative Notations for ER Diagrams
104
Sample Use of Alternative Notations for the COMPANY Schema
105
Example of Other Notation: UML Class Diagrams
UML methodology
Used extensively in software design
Many types of diagrams for various software
design purposes
UML class diagrams
Entity in ER corresponds to an object in UML
106
UML class diagrams
107
UML Class Diagram for the COMPANY Conceptual Schema
108
Other alternative diagrammatic notations
109
Example of Other Notation: UML Class Diagrams (1/2)
111
Relationship Types of Degree Higher than Two
112
Choosing between Binary and Ternary (or Higher-Degree) Relationships
113
Sample Ternary Relationships
114
Constraints on Ternary (or Higher-Degree) Relationships
115
Displaying constraints on higher-degree relationships
116
Further Refinements To The ER Model
117
Relationship With Attributes (1/2)
118
Relationship With Attributes (2/2)
Vendor
119
Entity Versus Attribute
120
Other Choices For Modeling Buys (1/2)
Vendor Vendor#
Vendor Vendor#
121
Other Choices For Modeling Buys (2/2)
Buys
Person R Country
123
Binary Relationships And Their Functionality (2/8)
The picture on the right describes the universe of four persons and
three countries, with lines indicating which person was born in
which country
We will have similar diagrams for other examples
124
Binary Relationships And Their Functionality (3/8)
125
Binary Relationships And Their Functionality (4/8)
126
Binary Relationships And Their Functionality (5/8)
127
Binary Relationships And Their Functionality (6/8)
Date
Date
Date
128
Binary Relationships And Their Functionality (7/8)
129
Binary Relationships And Their Functionality (8/8)
130
Alternate Designs
Date
Date
131
Aggregation: Relationships As Entities
132
Strong And Weak Entities
133
Man As A Strong Entity
134
Man As A Weak Entity (1/6)
135
Man As A Weak Entity (2/6)
137
Man As A Weak Entity (4/6)
138
Man As A Weak Entity (5/6)
SSN Name
First
Man Woman
Son
139
Man As A Weak Entity (6/6)
140
From Weaker To Stronger
143
Data Modeling Tools (Additional Material )
144
Automated Database Design Tools
145
Extended Entity-Relationship (EER) Model (in the next section)
146
Summary
147
Agenda
1 Session Overview
4 Case Study
148
Agenda
149
The Enhanced Entity-Relationship (EER) Model
150
Subclasses, Superclasses, and Inheritance (1/3)
151
Subclasses and Superclasses
152
Subclasses, Superclasses, and Inheritance (2/3)
153
Subclasses, Superclasses, and Inheritance (3/3)
154
Subclasses and Superclasses
155
Subclasses and Superclasses (1)
156
Subclasses and Superclasses (2)
157
Subclasses and Superclasses (3)
Examples:
A salaried employee who is also an engineer belongs to
the two subclasses:
ENGINEER, and
SALARIED_EMPLOYEE
A salaried employee who is also an engineering manager
belongs to the three subclasses:
MANAGER,
ENGINEER, and
SALARIED_EMPLOYEE
It is not necessary that every entity in a superclass be a
member of some subclass
158
The ISA Relationship (1/7)
159
The ISA Relationship (2/7)
ISA
160
The ISA Relationship (3/7)
161
The ISA Relationship (4/7)
162
The ISA Relationship (5/7)
D, P
163
The ISA Relationship (6/7)
Name SSN
Salary Mother
ISA
Woman
164
The ISA Relationship (7/7)
165
Representing Specialization in EER Diagrams
166
Sample EER Diagram
167
Specialization and Generalization
Specialization
Process of defining a set of subclasses of an
entity type
Defined on the basis of some distinguishing
characteristic of the entities in the superclass
Subclass can define:
Specific attributes
Specific relationship types
168
Instances of a Specialization
169
Specialization and Generalization (continued)
170
Generalization
171
Attribute Inheritance in Superclass / Subclass Relationships
173
Specialization (2)
174
Specialization (3)
175
Generalization
176
Generalization (2)
177
Generalization and Specialization (1)
178
Generalization and Specialization (2)
179
Types of Specialization
Predicate-defined ( or condition-defined) :
based on some predicate. E.g., based on
value of an attribute, say, Job-type, or
Age.
Attribute-defined: shows the name of the
attribute next to the line drawn from the
superclass toward the subclasses (see
Fig. 4.1)
User-defined: membership is defined by
the user on an entity by entity basis
180
Constraints and Characteristics of Specialization/Generalization Hierarchies
181
Constraints on Specialization and Generalization (1/2)
182
Constraints on Specialization and Generalization (2/2)
Disjointness constraint
Specifies that the subclasses of the specialization must
be disjoint
Completeness (or totalness) constraint
May be total or partial
Disjointness and completeness constraints are
independent
183
Constraints on Specialization and Generalization (1)
184
Constraints on Specialization and Generalization (2)
185
Displaying an attribute-defined specialization in EER diagrams
186
Constraints on Specialization and Generalization (1)
187
Constraints on Specialization and Generalization (2)
Disjointness Constraint:
Specifies that the subclasses of the
specialization must be disjoint:
an entity can be a member of at most one of the
subclasses of the specialization
Specified by d in EER diagram
If not disjoint, specialization is overlapping:
that is the same entity may be a member of more
than one subclass of the specialization
Specified by o in EER diagram
188
Constraints on Specialization and Generalization (3)
Completeness (Exhaustiveness)
Constraint:
Total specifies that every entity in the
superclass must be a member of some
subclass in the specialization/generalization
Shown in EER diagrams by a double line
Partial allows an entity not to belong to any of
the subclasses
Shown in EER diagrams by a single line
189
Constraints on Specialization and Generalization (4)
190
Example of disjoint partial Specialization
191
Example of overlapping total Specialization
192
Specialization/Generalization Hierarchies, Lattices & Shared Subclasses (1)
193
Specialization and Generalization Hierarchies and Lattices (1/2)
Specialization hierarchy
Every subclass participates as a subclass in
only one class/subclass relationship
Results in a tree structure or strict hierarchy
Specialization lattice
Subclass can be a subclass in more than one
class/subclass relationship
194
Shared Subclass Engineering_Manager
195
Sample Specialization Lattice
196
Specialization and Generalization Hierarchies and Lattices
Multiple inheritance
Subclass with more than one superclass
If attribute (or relationship) originating in the same
superclass inherited more than once via different paths
in lattice
Included only once in shared subclass
Single inheritance
Some models and languages limited to single
inheritance
197
Utilizing Specialization and Generalization in Refining Conceptual Schemas
Specialization process
Start with entity type then define subclasses by
successive specialization
Top-down conceptual refinement process
Bottom-up conceptual synthesis
Involves generalization rather than specialization
198
Specialization/Generalization Hierarchies, Lattices & Shared Subclasses (1)
199
Specialization/Generalization Hierarchies, Lattices & Shared Subclasses (2)
200
Specialization / Generalization Lattice Example (UNIVERSITY)
201
Modeling of UNION Types Using Categories
202
Categories (UNION TYPES) (1)
203
Categories (UNION TYPES) (2)
204
Two categories (UNION types): OWNER, REGISTERED_VEHICLE
205
A Sample UNIVERSITY EER Schema, Design Choices, and Formal Definitions
206
Sample EER Conceptual Schema for a University Database
207
Design Choices for Specialization/Generalization (1/3)
208
Design Choices for Specialization/Generalization (2/3)
209
Design Choices for Specialization/Generalization (3/3)
210
Formal Definitions for the EER Model Concepts (1/2)
Class
Set or collection of entities
Includes any of the EER schema constructs of group
entities
Subclass
Class whose entities must always be a subset of the
entities in another class
Specialization
Set of subclasses that have same superclass
211
Formal Definitions for the EER Model Concepts (2/2)
Generalization
Generalized entity type or superclass
Predicate-defined
Predicate on the attributes of is used to specify which
entities in C are members of S
User-defined
Subclass that is not defined by a predicate
Category
Class that is a subset of the union of n defining
superclasses
Relationship type
Any class can participate in a relationship
212
Formal Definitions of EER Model (1)
Class C:
A type of entity with a corresponding set of entities:
could be entity type, subclass, superclass, or category
Note: The definition of relationship type in ER/EER
should have 'entity type' replaced with 'class to allow
relationships among classes in general
Subclass S is a class whose:
Type inherits all the attributes and relationship of a class C
Set of entities must always be a subset of the set of entities
of the other class C
SC
C is called the superclass of S
A superclass/subclass relationship exists between S and C
213
Formal Definitions of EER Model (2)
214
Formal Definitions of EER Model (3)
215
Formal Definitions of EER Model (4)
216
Alternative diagrammatic notations
217
Example of Other Notation
218
Sample UML Class Diagram
219
Alternative Diagrammatic Notations
220
Data Abstraction, Knowledge Representation, and Ontology Concepts
221
Classification and Instantiation (1/2)
Classification
Systematically assigning similar objects/entities to
object classes/entity types
Instantiation
Inverse of classification
Generation and specific examination of distinct objects
of a class
222
Classification and Instantiation (2/2)
Exception objects
Differ in some respects from other objects of class
KR schemes allow such class properties
One class can be an instance of another class
(called a meta-class)
Cannot be represented directly in EER model
223
Identification
Abstraction process
Classes and objects are made uniquely
identifiable by means of some identifier
Needed at two levels
To distinguish among database objects and classes
To identify database objects and to relate them to their
real-world counterparts
224
Specialization and Generalization
Specialization
Classify a class of objects into more
specialized subclasses
Generalization
Generalize several classes into a higher-level
abstract class
Includes the objects in all these classes
225
Aggregation and Association
Aggregation
Abstraction concept for building composite objects from
their component objects
Association
Associate objects from several independent classes
Main structural distinction
When an association instance is deleted
Participating objects may continue to exist
226
Sample EER Model Illustrating Aggregation (1/2)
227
Sample EER Model Illustrating Aggregation (2/2)
228
Knowledge Representation (KR)-1
229
Knowledge Representation (KR)-2
230
Knowledge Representation (KR)-3
DIFFERENCES (continued):
KR schemes typically include rules and
reasoning mechanisms for inferencing
Most KR techniques involve data and metadata.
In data modeling, these are treated separately
KR is used in conjunction with artificial
intelligence systems to do decision support
applications
231
General Basis for Conceptual Modeling
232
Ontologies
234
Summary
235
Agenda
1 Session Overview
4 Case Study
236
A Case Study
237
Our Application (1/2)
238
Our Application (2/2)
239
Building The ER Diagram
Person
Automobile Likes
Date
Title Author
Monitors
0..1
Name Grade Took Taught
MaxSize
Horse Prereq
3..50
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
240
Horse
241
Our ER Diagram
Name
Horse
242
Horse
243
Person
244
Our ER Diagram
FN LN
Person
Name
Horse
245
Person
246
Automobile
247
Our ER Diagram
FN LN
Person
Automobile
Name
Horse
248
Likes
Likes; relationship
Relationship among/between:
Person
Automobile
Attributes
Constraints
249
Our ER Diagram
FN LN
Person
Automobile Likes
Name
Horse
250
Likes
251
Car
252
Our ER Diagram
FN LN
Person
Automobile Likes
Car
VIN Color
Name
Horse
253
Type
Type; relationship
Relationship among/between:
Automobile
Car
Attributes
Constraints
Cardinality: 1..1 between Car and Type
This tells us for each physical car what is the
automobile catalog entry of which it is an
instantiation
Each car is an instantiation of a exactly one catalog
entry
254
Our ER Diagram
FN LN
Person
Automobile Likes
1..1
Type Car
VIN Color
Name
Horse
255
Type
256
Has
Has; relationship
Relationship among/between
Person
Car
Attributes
Date
Constraints
Cardinality: 2..* between Person and Has
Cardinality: 0..1 between Car and Has
Date tells us when the person got the car
Every person has at least two cars
Every car can be had (owned) by at most one person
Some cars may have been abandoned
257
Our ER Diagram
FN LN
Person
Automobile Likes
Date
VIN Color
Name
Horse
258
Has
259
Student
FN LN
Person
Automobile Likes
Date
GPA ISA
VIN Color
Student
Name
Horse
261
Professor
262
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Name
Horse
263
Course
264
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Name
Horse
Course
C# Title Description
265
Prereq
Prereq; relationship
Relationship among/between:
Course; role: First
Course; role: Second
Attributes
Constraints
We have a directed graph on courses, telling us
prerequisites for each course, if any
To take second course every first course related to it must
have been taken previously
We needed the roles first and second, to be clear
Note how we model well that prerequisites are not between
offerings of a course but catalog entries of courses
266
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Name
Horse Prereq
First Second
Course
C# Title Description
267
Book
268
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
Name
Horse Prereq
First Second
Course
C# Title Description
269
Required
Required; relationship
Relationship among/between:
Professor
Course
Book
Attributes
Constraints
A professor specifies that a book is
required for a course
270
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
Name
Horse Prereq
First Second
Course
C# Title Description
271
Required
272
Section
273
Section
274
Offered
Offered; relationship
Relationship among/between:
Course
Section
Attributes
Constraints
Course has to be related to at least one section (see
above)
Section has to be related to exactly one course (this
automatically follows from the fact that section is
identified through exactly one course, so maybe we
do not need to say this)
275
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
Name
MaxSize
Horse Prereq
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
276
Took
Took; relationship
Relationship among/between
Student
Section
Attributes
Grade
Constraints
Cardinality: 3..50 between Section and Took
(this means that a section has between 3 and
50 students)
277
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
MaxSize
Horse Prereq
3..50
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
278
Taught
Taught; relationship
Relationship among/between
Professor
Section
Attributes
This tells us which professor teach which sections
Note there is no cardinality constraint: any number of
professors, including zero professors can teach a section (no
professor yet assigned, or hypothetical situation)
If we wanted, we could have put 1..* between Section and
Taught to specify that at least one professor has to be assigned
to each section
279
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
MaxSize
Horse Prereq
3..50
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
280
Taught
281
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
MaxSize
Horse Prereq
3..50
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
282
Monitors
Monitors; relationship
Relationship among/between
Professor
Taught (considered as an entity)
Attributes
Constraints
Cardinality: 0..1 between Taught and Professor
This models the fact that Taught (really a teaching
assignment) may need to be monitored by a professor
and at most one professor is needed for such
monitoring
We are not saying whether the professor monitoring the
assignment has to be different from the teaching professor in
this assignment (but we could do it in SQL DDL, as we shall see
later)
283
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
Monitors
0..1
Name Grade Took Taught
MaxSize
Horse Prereq
3..50
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
284
What Can We Learn From The Diagram?
Lets look
We will review everything we can learn
just by looking at the diagram
285
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
Monitors
0..1
Name Grade Took Taught
MaxSize
Horse Prereq
3..50
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
286
GPA
287
Our ER Diagram
FN LN
Person
Automobile Likes
Date
Title Author
Monitors
Name Grade Took Taught 0..1
MaxSize
Horse Prereq
3..50
First Second
Sec#
Section 1..1 1..*
Offered Course
Year
C# Title Description
Semester
288
Some Constraints Are Difficult To Specify
Taught
MaxSize
Sec#
Section 1..1 Offered 1..* Course
Year
C# Title Description
Semester
289
Annotate, Annotate, Annotate
290
Hierarchy For Our ER Diagram
291
Hierarchy For Our ER Diagram
Monitors
292
Agenda
1 Session Overview
4 Case Study
293
Summary
294
Assignments & Readings
Readings
Slides and Handouts posted on the course web site
Textbook: Chapters 3 & 4
295
Next Session: Practical Database Design
296
Any Questions?
297