© 2002 by Prentice Hall 1 SI 654 Database Application Design Winter 2003 Dragomir R. Radev.

© 2002 by Prentice Hall1

SI 654

Database Application DesignWinter 2003

Dragomir R. Radev

© 2002 by Prentice Hall2

David M. Kroenke

Database ProcessingEighth Edition

Chapter 3

The Entity-Relationship

Model

© 2002 by Prentice Hall3

Data Modeling

• Process of creating a logical representation of the structure of the database

• The most important task in database development

© 2002 by Prentice Hall4

Entity-Relationship Model (E-R Model)

• An Entity-Relationship Model (E-R Model) consists of:– Entities– Attributes– Identifiers– Relationships

© 2002 by Prentice Hall5

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.

© 2002 by Prentice Hall6

An Entity Example

© 2002 by Prentice Hall7

Attributes

• An attribute describes a characteristic of an entity

• For example– An entity: Employee – Has attributes:

•EmployeeName•Extension•DateOfHire

© 2002 by Prentice Hall8

Identifier

• An identifier uniquely identifies a row in a table.

• For an Employee, the SocialSecurityNumber may serve as the Indentifier.

© 2002 by Prentice Hall9

Relationships

• A relationship describes how one or more entities are related with each other.

© 2002 by Prentice Hall10

Relationship Cardinality

• Entity-Instance Participation in relationships is shown by– maximum cardinality– minimum cardinality

© 2002 by Prentice Hall11

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)

© 2002 by Prentice Hall12

Relationship Examples Showing Maximum

Cardinality Alternatives

© 2002 by Prentice Hall13

Minimum Cardinality

• The minimum cardinality indicates/depicts whether participation in the relationship is mandatory or optional.

• Alternatives include– 0 (optional)– 1 (mandatory)

© 2002 by Prentice Hall14

A Relationship Example Showing Minimum and Maximum Cardinality

© 2002 by Prentice Hall15

A Recursive Relationship

• A recursive relationship is when an entity has a relationship with itself.

© 2002 by Prentice Hall16

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

© 2002 by Prentice Hall17

An Entity-Relationship Diagram (E-R Diagram)

Example

© 2002 by Prentice Hall18

Weak Entity

• A weak entity is an entity whose instance survival depends (logically) on an associated instance in another entity

© 2002 by Prentice Hall19

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.

© 2002 by Prentice Hall20

CLIENT with Subtype Entities

© 2002 by Prentice Hall21

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

© 2002 by Prentice Hall22

E-R Diagram Example: Jefferson Dance Club

© 2002 by Prentice Hall23

E-R Diagram Example: San Juan Charters

© 2002 by Prentice Hall24

David M. Kroenke

Database ProcessingEighth Edition

Chapter 5

The Relational Model and

Normalization

© 2002 by Prentice Hall25

The Relational Model

• Broad, flexible model• Basis for almost all DBMS products• E.F. Codd defined well-structured

“normal forms” of relations, “normalization”

© 2002 by Prentice Hall26

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

© 2002 by Prentice Hall27

Terminology

© 2002 by Prentice Hall28

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.

© 2002 by Prentice Hall29

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

© 2002 by Prentice Hall30

Functional Dependency – an Example

• EmployeeNumber Name• EmployeeNumber Age• EmployeeNumber Sex

© 2002 by Prentice Hall31

A Key

• A key is a group of one or more attributes that uniquely identifies a tuple

© 2002 by Prentice Hall32

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.

© 2002 by Prentice Hall33

Example of a Combination Key

© 2002 by Prentice Hall34

Normalization

• Normalization is a process of evaluating and converting a relation to reduce modification anomalies

• Essentially, normalization detects and eliminates data redundancy

© 2002 by Prentice Hall35

An Anomaly

• An anomaly is an undesirable consequence of a data modification.

© 2002 by Prentice Hall36

Normal Forms

• Normal forms are state-classes of relations which identify the level of anomaly-avoidance

© 2002 by Prentice Hall37

Normal Forms Levels

• 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 Hall38

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

© 2002 by Prentice Hall39

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)

© 2002 by Prentice Hall40

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)

© 2002 by Prentice Hall41

Violation of 3NF

© 2002 by Prentice Hall42

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.

© 2002 by Prentice Hall43

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.

© 2002 by Prentice Hall44

Fifth Normal Form (5NF)

• The Fifth Normal Form concerns dependencies that are obscure and beyond the scope of this text.

© 2002 by Prentice Hall45

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.

© 2002 by Prentice Hall46

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

© 2002 by Prentice Hall47

DK/NF Example

Domain/Key Definition of Example Above

© 2002 by Prentice Hall48

DK/NF Example

© 2002 by Prentice Hall49

DK/NF Example

© 2002 by Prentice Hall50

Summary of Normal Forms

© 2002 by Prentice Hall51

Synthesis of Relations

A B and B A one-to-oneA B but B not A many-to-

oneA not B and B not A many-to-

many

© 2002 by Prentice Hall52

Summary of Attribute Relationships

© 2002 by Prentice Hall53

Optimization

• De-Normalization (a.k.a., Controlled Redundancy)