l2 - CLAIR

SI 654
Database Application Design
Winter 2003
Dragomir R. Radev
1
© 2002 by Prentice Hall
Database Processing
Eighth Edition
The EntityRelationship
Model
2
Chapter 3
David M. Kroenke
© 2002 by Prentice Hall
Data Modeling
• Process of creating a logical
representation of the structure of
the database
• The most important task in database
development
3
© 2002 by Prentice Hall
Entity-Relationship Model
(E-R Model)
• An Entity-Relationship Model (E-R
Model) consists of:
– Entities
– Attributes
– Identifiers
– Relationships
4
© 2002 by Prentice Hall
An Entity
• An entity is an object that can be
identified in the users’ work
environment & that users want to
track.
• Entities of a given type are grouped
into entity classes.
5
© 2002 by Prentice Hall
An Entity Example
6
© 2002 by Prentice Hall
Attributes
• An attribute describes a characteristic of
an entity
• For example
– An entity: Employee
– Has attributes:
• EmployeeName
• Extension
• DateOfHire
7
© 2002 by Prentice Hall
Identifier
• An identifier uniquely identifies a row
in a table.
• For an Employee, the
SocialSecurityNumber may serve as
the Indentifier.
8
© 2002 by Prentice Hall
Relationships
• A relationship describes how one or
more entities are related with each
other.
9
© 2002 by Prentice Hall
Relationship Cardinality
• Entity-Instance Participation in
relationships is shown by
– maximum cardinality
– minimum cardinality
10
© 2002 by Prentice Hall
Maximum Cardinality
• The maximum cardinality
indicates/depicts the maximum
number of instances involved in a
relationship.
• Alternatives include
– 1:1 (one-to-one)
– 1:N (one-to-many)
– N:M (many-to-many)
11
© 2002 by Prentice Hall
Relationship Examples
Showing Maximum
Cardinality Alternatives
12
© 2002 by Prentice Hall
Minimum Cardinality
• The minimum cardinality
indicates/depicts whether
participation in the relationship is
mandatory or optional.
• Alternatives include
– 0 (optional)
– 1 (mandatory)
13
© 2002 by Prentice Hall
A Relationship Example
Showing Minimum and
Maximum Cardinality
14
© 2002 by Prentice Hall
A Recursive Relationship
• A recursive
relationship is when
an entity has a
relationship with
itself.
15
© 2002 by Prentice Hall
Entity-Relationship Diagram
(E-R Diagram)
• An entity-relationship diagram (E-R
Diagram) is a graphical representation
of the E-R model using a set of
‘somewhat’ standardized conventions
16
© 2002 by Prentice Hall
An Entity-Relationship Diagram
(E-R Diagram) Example
17
© 2002 by Prentice Hall
Weak Entity
• A weak entity is an entity whose
instance survival depends (logically)
on an associated instance in another
entity
18
© 2002 by Prentice Hall
Subtype Entities
• Some entities may have many common
attributes and a few unique
attributes.
• The common attributes may be
grouped together in a supertype
entity and the unique attributes may
be grouped together in a subtype
entity.
19
© 2002 by Prentice Hall
CLIENT with
Subtype Entities
20
© 2002 by Prentice Hall
E-R Diagram
Computer Assisted Software
Engineering (CASE) Tools
• Several Computer Assisted Software
Engineering (CASE) Tools exist to help
create E-R Diagrams and the resulting
physical database elements. Products
include:
– IEW
– IEF
– DEFT
– ER-WIN
– Visio
21
© 2002 by Prentice Hall
E-R Diagram Example:
Jefferson Dance Club
22
© 2002 by Prentice Hall
E-R Diagram Example:
San Juan Charters
23
© 2002 by Prentice Hall
Database Processing
Eighth Edition
The
Relational
Model and
Normalization
24
Chapter 5
David M. Kroenke
© 2002 by Prentice Hall
The Relational Model
• Broad, flexible model
• Basis for almost all DBMS products
• E.F. Codd defined well-structured
“normal forms” of relations,
“normalization”
25
© 2002 by Prentice Hall
Components of the
Relational Model
• Relation
– A two-dimensional table consisting
of rows and columns
• Tuples
– The rows (or records) in a relation
• Attributes
– The columns (or fields) in a relation
26
© 2002 by Prentice Hall
Terminology
27
© 2002 by Prentice Hall
Functional Dependency
• Functional dependencies are the
relationships among the attributes
within a relation.
• If attribute A functional depends on
attribute B, then for every instance
of B you will know the respective
value of A.
28
© 2002 by Prentice Hall
Functional Dependency
Notation
• Major is functionally dependent on
SID
• SID  Major
• Grade is functionally dependent on
the combination of SID and ClassID
• (SID, ClassID)  Grade
29
© 2002 by Prentice Hall
Functional Dependency
– an Example
• EmployeeNumber  Name
• EmployeeNumber  Age
• EmployeeNumber  Sex
30
© 2002 by Prentice Hall
A Key
• A key is a group of
one or more
attributes that
uniquely identifies
a tuple
31
© 2002 by Prentice Hall
A Combination Key
• Sometimes more than one attribute
will be required to uniquely identify a
tuple.
• If a key consists of more than one
attribute, it is called a combination
(or composite) key.
32
© 2002 by Prentice Hall
Example of a Combination
Key
33
© 2002 by Prentice Hall
Normalization
• Normalization is a process of
evaluating and converting a relation to
reduce modification anomalies
• Essentially, normalization detects and
eliminates data redundancy
34
© 2002 by Prentice Hall
An Anomaly
• An anomaly is an undesirable
consequence of a data modification.
35
© 2002 by Prentice Hall
Normal Forms
• Normal forms are state-classes of
relations which identify the level of
anomaly-avoidance
36
© 2002 by Prentice Hall
Normal Forms Levels
•
•
•
•
•
•
•
37
1NF –First Normal Form
2NF –Second Normal Form
3NF –Third Normal Form
BCNF –Boyce-Codd Normal Form
4NF –Fourth Normal Form
5NF –Fifth Normal Form
DK/NF –Domain/Key Normal Form
© 2002 by Prentice Hall
First Normal Form (1NF)
• To be in First Normal Form (1NF) a
relation must have only single-valued
attributes -- neither repeating groups
nor arrays are permitted
38
© 2002 by Prentice Hall
Second Normal Form (2NF)
• To be in Second Normal Form (2NF)
the relation must be in 1NF and each
nonkey attribute must be dependent
on the whole key (not a subset of the
key)
39
© 2002 by Prentice Hall
Third Normal Form (3NF)
• To be in Third Normal Form (3NF) the
relation must be in 2NF and no transitive
dependencies may exist within the relation.
• A transitive dependency is when an
attribute is indirectly functionally
dependent on the key (that is, the
dependency is through another nonkey
attribute)
40
© 2002 by Prentice Hall
Violation of 3NF
41
© 2002 by Prentice Hall
Boyce-Codd Normal Form
(BCNF)
• To be in Boyce-Codd Normal Form
(BCNF) the relation must be in 3NF
and every determinant must be a
candidate key.
42
© 2002 by Prentice Hall
Fourth Normal Form (4NF)
• To be in Fourth Normal Form (4NF)
the relation must be in BCNF and the
relation may not contain multi-valued
dependencies.
43
© 2002 by Prentice Hall
Fifth Normal Form (5NF)
• The Fifth Normal Form concerns
dependencies that are obscure and
beyond the scope of this text.
44
© 2002 by Prentice Hall
Domain/Key Normal Form
(DK/NF)
• To be in Domain/Key Normal Form
(DK/NF) every constraint on the
relation must be a logical consequence
of the definition of keys and domains.
45
© 2002 by Prentice Hall
DK/NF Terminology
• Constraint
– A rule governing static values of
attributes
• Key
– A unique identifier of a tuple
• Domain
– A description of an attribute’s
allowable values
46
© 2002 by Prentice Hall
 DK/NF Example
Domain/Key
Definition
of Example
Above 
47
© 2002 by Prentice Hall
DK/NF Example
48
© 2002 by Prentice Hall
DK/NF Example
49
© 2002 by Prentice Hall
Summary of Normal Forms
50
© 2002 by Prentice Hall
Synthesis of Relations
A  B and B  A
A  B but B not  A
A not  B and B not  A
51
one-to-one
many-to-one
many-to-many
© 2002 by Prentice Hall
Summary of Attribute
Relationships
52
© 2002 by Prentice Hall
Optimization
• De-Normalization (a.k.a., Controlled
Redundancy)
53
© 2002 by Prentice Hall