COS 346
Day 7
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-1
Agenda
•
•
Questions?
Assignment Two is Corrected
– 1 A, 3 C’s, 2 D’s and 1 F (didn’t answer all the questions)
– We will go through the entire assignment in class
•
•
•
Assignment 3 Due Monday
Assignment 4 will be assigned next week and will due after Winter Break
Quiz one will be on Feb 15 (change from Syllabus)
– DP chap 1-4, Oracle Chap 1-2
– 15 M/C @ 4 points each,
– 5 Short essays @ 8 points each.
– Open Book, Open notes, 50 Min
•
Capstone Proposals Due next Thursday, Feb 15
– Capstone Project Description sp 07.htm
•
Begin Discussion on Data Modeling with the Entity-Relationship Model
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-2
Assignment 2
• CUSTOMER (Phone, FirstName, LastName)
Explain the conditions under which each of the
following are true:
1.
2.
3.
4.
5.
6.
7.
Phone  (FirstName, LastName)
(Phone, FirstName)  LastName
(Phone, LastName)  FirstName
(LastName, FirstName)  Phone
Phone  LastName
Phone  FirstName
Phone  (FirstName, LastName)
Is condition 7 the same as conditions 5 and 6?
Why or why not?
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-3
Scenario
• Two Phones - 5 People
–
–
–
–
–
–
–
Tony Gauvin
Ray Albert
Rachael Albert
Ray Gauvin (Caribou)
Tony Albert (Presque Isle)
834-7519
832-7696
• “Who <> number” for each of the 7 conditions
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-4
Assignment 2
CUSTOMER (Phone, FirstName,
LastName)
ORDER (OrderNumber, DateIn, DateOut,
Phone)
State an appropriate referential integrity
constraint.
ORDER.Phone must exist in
CUSTOMER.Phone
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-5
Assignment 2
CUSTOMER (Phone, FirstName, LastName)
ORDER (OrderNumber, DateIn, DateOut, FirstName, LastName)
• What does the following referential integrity constraint mean?
ORDER (FirstName, LastName) must be in CUSTOMER
(FirstName, LastName)
•
Is this constraint the same as:
ORDER (FirstName) must be in CUSTOMER (FirstName)
and
ORDER. (LastName) must be in CUSTOMER (LastName)
Do you prefer the design in B or the design in C? Explain your
reasoning.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-6
Assignment 2
• ORDER (CustomerNumber, FirstName,
LastName, Phone, OrderNumber, DateIn,
DateOut, ItemType, Quantity, ItemPrice,
ExtendedPrice, SpecialInstructions)
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-7
Assignment 2
ORDER_4 (CustomerNumber, OrderNumber, DateIn,
DateOut)
WHERE ORDER_4.CustomerNumber must exist in
CUSTOMER.CustomerNumber
ORDER_ITEM (OrderNumber, ItemType, Quantity,
ItemPrice, ExtendedPrice, SpecialInstructions)
WHERE ORDER_ITEM.OrderNumber must exist in
ORDER_4.OrderNumber
CUSTOMER (CustomerNumber, FirstName, LastName)
CUSTOMER_PHONE (CustomerNumber, Phone)
WHERE CUSTOMER_PHONE.CustomerNumber must exist in
CUSTOMER.CustomerNumber
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-8
Assignment 2
• Explain how your answer to question E changes
depending on whether you assume CustomerNumber 
(FirstName, LastName) or CustomerNumber 
(FirstName, LastName)
• The only difference to the design solution shown in E
would be to the CUSTOMER table:
• CUSTOMER (CustomerNumber, FirstName, LastName)
• If CustomerNumber  (FirstName, LastName), the
table must be put into 4NF with all fields as part of the
primary key:
• CUSTOMER_2 (CustomerNumber, FirstName,
LastName)
• Nothing else in the solution changes.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-9
David M. Kroenke’s
Database Processing:
Fundamentals, Design, and Implementation
Chapter Five:
Data Modeling with the
Entity-Relationship Model
Part One
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-10
The Data Model
• A data model is a plan, or blueprint, for a
database design.
• A data model is more generalized and
abstract than a database design.
• It is easier to change a data model than it
is to change a database design, so it is the
appropriate place to work through
conceptual database problems.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-11
E-R Model
• Entity-Relationship model is a set of concepts and
graphical symbols that can be used to create conceptual
schemas.
• Versions
– Original E-R model — Peter Chen (1976).
– Extended E-R model — Extensions to the Chen model.
– Information Engineering (IE) — James Martin (1990); it uses
“crow’s foot” notation, is easier to understand and we will use it.
– IDEF1X — A national standard developed by the National
Institute of Standards and Technology [see Appendix B]
– Unified Modeling Language (UML) — The Object Management
Group; it supports object-oriented methodology [see Appendix C]
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-12
Entities
• Something that can be identified and the
users want to track
– Entity class — a collection of entities of a
given type
– Entity instance — the occurrence of a
particular entity
• There are usually many instances of an
entity in an entity class.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-13
CUSTOMER:
The Entity Class and Two Entity Instances
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-14
Attributes
• Attributes describe an entity’s
characteristics.
• All entity instances of a given entity class
have the same attributes, but vary in the
values of those attributes.
• Originally shown in data models as
ellipses.
• Data modeling products today commonly
show attributes in rectangular form.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-15
EMPLOYEE:
Attributes in Ellipses
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-16
EMPLOYEE:
Attributes in Entity Rectangle
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-17
Identifiers
• Identifiers are attributes that name, or identify, entity
instances.
• The identifier of an entity instance consists of one or
more of the entity’s attributes.
• Composite identifiers: Identifiers that consist of two or
more attributes
• Identifiers in data models become keys in database
designs:
– Entities have identifiers.
– Tables (or relations) have keys.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-18
Entity Attribute Display
in Data Models
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-19
Relationships
• Entities can be associated with one another in
relationships:
– Relationship classes: associations among entity classes
– Relationship instances: associations among entity instances
• In the original E-R model, relationships could
have attributes but today this is no longer done.
• A relationship class can involve two or more
entity classes.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-20
Degree of the Relationship
• The degree of the relationship is the number of
entity classes in the relationship:
– Two entities have a binary relationship of degree
two.
– Three entities have a ternary relationship of degree
three.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-21
Binary Relationship
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-22
Ternary Relationship
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-23
Entities and Tables
• The principle difference between an entity
and a table (relation) is that you can
express a relationship between entities
without using foreign keys.
• This makes it easier to work with entities in
the early design process where the very
existence of entities and the relationships
between them is uncertain.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-24
Cardinality
• Cardinality means “count,” and is
expressed as a number.
• Maximum cardinality is the maximum
number of entity instances that can
participate in a relationship.
• Minimum cardinality is the minimum
number of entity instances that must
participate in a relationship.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-25
Maximum Cardinality
• Maximum cardinality is the maximum
number of entity instances that can
participate in a relationship.
• There are three types of maximum
cardinality:
– One-to-One [1:1]
– One-to-Many [1:N]
– Many-to-Many [N:M]
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-26
The Three Types of
Maximum Cardinality
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-27
Parent and Child Entities
• In a one-to-many relationship:
– The entity on the one side of the relationship is called
the parent entity or just the parent.
– The entity on the many side of the relationship is
called the child entity or just the child.
• In the figure below, EMPLOYEE is the parent
and COMPUTER is the child:
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-28
HAS-A Relationships
• The relationships we have been
discussing are known as HAS-A
relationships:
– Each entity instance has a relationship with
another entity instance:
• An EMPLOYEE has one or more COMPUTERs.
• A COMPUTER has an assigned EMPLOYEE.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-29
Minimum Cardinality
• Minimum cardinality is the minimum number of
entity instances that must participate in a
relationship.
• Minimums are generally stated as either zero or
one:
– IF zero [0] THEN participation in the relationship by
the entity is optional, and no entity instance must
participate in the relationship.
– IF one [1] THEN participation in the relationship by
the entity is mandatory, and at least one entity
instance must participate in the relationship.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-30
Indicating Minimum Cardinality
• As shown in the examples in a following
slide:
– Minimum cardinality of zero [0] indicating
optional participation is indicated by placing
an oval next to the optional entity.
– Minimum cardinality of one [1] indicating
mandatory (required) participation is
indicated by placing a vertical hash mark
next to the required entity.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-31
Reading Minimum Cardinality
• Look toward the entity in question:
– IF you see an oval THEN that entity is
optional (minimum cardinality of zero [0]).
– IF you see a vertical hash mark THEN that
entity is mandatory (required) (minimum
cardinality of one [1]).
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-32
The Three Types of
Minimum Cardinality
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-33
Data Modeling Notation
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-34
Data Modeling Notation:
ERwin
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-35
Data Modeling Notation:
N:M and O-M
Note that:
(1) ERwin cannot
indicate true
minimum
cardinalities on
N:M relationships
(2) Visio introduces
the intersection
table instead of
using a true N:M
model
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-36
ID-Dependent Entities
• An ID-dependent entity is an entity (child)
whose identifier includes the identifier of another
entity (parent).
• The ID-dependent entity is a logical extension or
sub-unit of the parent:
– BUILDING : APARTMENT
– PAINTING : PRINT
• The minimum cardinality from the ID-dependent
entity to the parent is always one.
• ID Dependant entity has a identifying
relationship with parent (solid line)
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-37
ID-Dependent Entities
A solid line
indicates an
identifying
relationship
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-38
Weak Entities
• A weak entity is an entity whose existence
depends upon another entity.
• All ID-Dependent entities are considered
weak.
• But there are also non-ID-dependent weak
entities.
– The identifier of the parent does not appear in
the identifier of the weak child entity.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-39
Weak Entities (Continued)
A dashed line
indicates a
nonidentifying
relationship
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
Weak entities must be
indicated by an
accompanying text box in
Erwin – There is no
specific notation for a
nonidentifying but weak
entity relationship
5-40
ID-Dependent and Weak Entities
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-41
Subtype Entities
• A subtype entity is a special case of a
supertype entity:
– STUDENT :
UNDERGRADUATE or GRADUATE
• The supertype contains all common
attributes, while the subtypes contain
specific attributes.
• The supertype may have a discriminator
attribute that indicates the subtype.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-42
Subtypes with a Discriminator
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-43
Subtypes: Exclusive or Inclusive
• If subtypes are exclusive, one supertype
relates to at most one subtype.
• If subtypes are inclusive, one supertype
can relate to one or more subtypes.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-44
Subtypes: Exclusive or Inclusive
(Continued)
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-45
Subtypes: IS-A relationships
• Relationships connecting supertypes and
subtypes are called IS-A relationships,
because a subtype IS A supertype.
• The identifier of the supertype and all of its
subtypes must be identical, i.e., the
identifier of the supertype becomes the
identifier of the related subtype(s).
• Subtypes are used to avoid valueinappropriate nulls.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-46
ERwin Symbol Summary
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-47
ERwin Symbol Summary (Continued)
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-48
David M. Kroenke’s
Database Processing
Fundamentals, Design, and Implementation
(10th Edition)
End of Presentation:
Chapter Five Part One
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-49
David M. Kroenke’s
Database Processing:
Fundamentals, Design, and Implementation
Chapter Five:
Data Modeling with the
Entity-Relationship Model
Part Two
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-50
Strong Entity Patterns:
1:1 Strong Entity Relationships
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-51
Strong Entity Patterns:
1:1 Strong Entity Relationships
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-52
Strong Entity Patterns:
1:N Strong Entity Relationships
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-53
Strong Entity Patterns:
1:N Strong Entity Relationships
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-54
Strong Entity Patterns:
N:M Strong Entity Relationships
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-55
Strong Entity Patterns:
N:M Strong Entity Relationships
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-56
Strong Entity Patterns:
N:M Strong Entity Relationships
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-57
ID-Dependent Relationships:
The Association Pattern
Note the Price column,
which has been added.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-58
ID-Dependent Relationships:
The Association Pattern
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-59
ID-Dependent Relationships:
The Multivaled Attribute Pattern
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-60
ID-Dependent Relationships:
The Multivaled Attribute Pattern
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-61
ID-Dependent Relationships:
The Multivaled Attribute Pattern
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-62
ID-Dependent Relationships:
The Multivaled Attribute Pattern
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-63
ID-Dependent Relationships:
The Archtype/Instance Pattern
• The archtype/instance pattern occurs
when the ID-dependent child entity is the
physical manisfestation (instance) of an
abstract or logical parent:
– PAINTING : PRINT
– CLASS : SECTION
– YACHT_DESIGN : YACHT
– HOUSE_MODEL: HOUSE
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-64
ID-Dependent Relationships:
The Archtype/Instance Pattern
Note that these are
true ID-dependent
relationships - the
identifier of the
parent appears as
part of the
composite
identifier of the IDdependent child.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-65
ID-Dependent Relationships:
The Archtype/Instance Pattern
Note the
use of
weak, but
not IDdependent
children.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-66
David M. Kroenke’s
Database Processing
Fundamentals, Design, and Implementation
(10th Edition)
End of Presentation:
Chapter Five Part Two
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
5-67