© 2002 by prentice hall 1 si 654 database application design winter 2003 dragomir r. radev

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

Upload: tracy-fowler

Post on 14-Dec-2015

217 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: © 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

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

© 2002 by Prentice Hall2

David M. Kroenke

Database ProcessingEighth Edition

Chapter 3

The Entity-Relationship

Model

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

© 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

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

© 2002 by Prentice Hall4

Entity-Relationship Model (E-R Model)

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

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

© 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.

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

© 2002 by Prentice Hall6

An Entity Example

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

© 2002 by Prentice Hall7

Attributes

• An attribute describes a characteristic of an entity

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

•EmployeeName•Extension•DateOfHire

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

© 2002 by Prentice Hall8

Identifier

• An identifier uniquely identifies a row in a table.

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

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

© 2002 by Prentice Hall9

Relationships

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

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

© 2002 by Prentice Hall10

Relationship Cardinality

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

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

© 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)

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

© 2002 by Prentice Hall12

Relationship Examples Showing Maximum

Cardinality Alternatives

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

© 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)

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

© 2002 by Prentice Hall14

A Relationship Example Showing Minimum and Maximum Cardinality

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

© 2002 by Prentice Hall15

A Recursive Relationship

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

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

© 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

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

© 2002 by Prentice Hall17

An Entity-Relationship Diagram (E-R Diagram)

Example

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

© 2002 by Prentice Hall18

Weak Entity

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

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

© 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.

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

© 2002 by Prentice Hall20

CLIENT with Subtype Entities

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

© 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

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

© 2002 by Prentice Hall22

E-R Diagram Example: Jefferson Dance Club

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

© 2002 by Prentice Hall23

E-R Diagram Example: San Juan Charters

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

© 2002 by Prentice Hall24

David M. Kroenke

Database ProcessingEighth Edition

Chapter 5

The Relational Model and

Normalization

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

© 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”

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

© 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

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

© 2002 by Prentice Hall27

Terminology

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

© 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.

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

© 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

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

© 2002 by Prentice Hall30

Functional Dependency – an Example

• EmployeeNumber Name• EmployeeNumber Age• EmployeeNumber Sex

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

© 2002 by Prentice Hall31

A Key

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

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

© 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.

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

© 2002 by Prentice Hall33

Example of a Combination Key

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

© 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

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

© 2002 by Prentice Hall35

An Anomaly

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

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

© 2002 by Prentice Hall36

Normal Forms

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

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

© 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

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

© 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

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

© 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)

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

© 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)

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

© 2002 by Prentice Hall41

Violation of 3NF

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

© 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.

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

© 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.

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

© 2002 by Prentice Hall44

Fifth Normal Form (5NF)

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

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

© 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.

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

© 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

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

© 2002 by Prentice Hall47

DK/NF Example

Domain/Key Definition of Example Above

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

© 2002 by Prentice Hall48

DK/NF Example

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

© 2002 by Prentice Hall49

DK/NF Example

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

© 2002 by Prentice Hall50

Summary of Normal Forms

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

© 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

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

© 2002 by Prentice Hall52

Summary of Attribute Relationships

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

© 2002 by Prentice Hall53

Optimization

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