Chapter 5 - Personal.kent.edu

Download Report

Transcript Chapter 5 - Personal.kent.edu

Database Processing

Tenth Edition

Chapter 5

Data Modeling ER Model

David M. Kroenke DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1

Database Development Approaches

• Top-down development • Prototype • Bottom-up development DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-2

Top-down Development

• General requirements to specific requirements • A global perspective DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-3

Systems Development Life Cycle

Project Identification and Selection Project Initiation and Planning Analysis Logical Design Physical Design Implementation Maintenance DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-4

Database Development Activities During SDLC

1. Project Id/Selection 2. Initiation/Planning 3. Analysis 4. Logical Design 5. Physical Design 6. Implementation 7. Maintenance 1. Enterprise Data Modeling 2. Conceptual Data Modeling 3. Logical DB Design 4. Physical DB Design 5. DB Implementation 6. Maintenance DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-5

1. Project ID/Selection

• •

Enterprise Modeling

Analyze current DP Justify need for new DB DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-6

2-3. Project Initiation/Planning & Analysis

• • •

Conceptual Data Modeling

ID scope of DB requirements Analyze overall data requirements Develop preliminary data model DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-7

4. Logical Design

• • •

Logical Database Design

Detail transactions, applications, views etc required by DB system ID security, backup, concurrency issues Create stable, well-defined structure (normalization) DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-8

5. Physical Design

• •

Physical Database Design

Define DB to DBMS Develop DB applications DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-9

6. Implementation

• • •

Physical Implementation

Load data Install & test DB applications Complete documentation & training DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-10

7. Maintenance

• • •

DB Maintenance

Ensure DB meeting needs/reqs Performance tuning Backup/Recovery DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-11

Prototype Development

• Develop portions of the database and submit to users for feedback, refinement, and enhancement DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-12

ID Problem Develop Prototype Implement Prototype Convert to Production DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall Revise Prototype 5-13

Bottom-up Development

• Specific requirements to general requirements • Typically faster and less risky DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-14

Data Modeling Creation

• Interviewing users • Documenting requirements • Building a data model • Building a database prototype • A process of inference – Working backwards DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-15

The Data Model

• A

data model

is a plan, or blueprint, for a

database design

.

• A data model defines and graphically depicts the data structure and relationships among the data • A data model is more generalized and abstract than a database design.

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-16

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-17

Entities

• Something that can be identified and the users want to track –

Entity class

given type — a collection of entities of a –

Entity instance

particular entity — the occurence of a • 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-18

CUSTOMER:

The Entity Class and Two Entity Instances DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-19

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-20

EMPLOYEE: Attributes in Ellipses

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-21

EMPLOYEE: Attributes in Entity Rectangle

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-22

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

more attributes : Identifiers that consist of two or • 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-23

Entity Attribute Display in Data Models

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-24

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.

Really an issue of semantics

• A relationship class can involve two or more entity classes.

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-25

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

three.

of degree DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-26

Binary Relationship

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-27

Ternary Relationship

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-28

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-29

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-30

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-31

The Three Types of Maximum Cardinality

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-32

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-33

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-34

Minimum Cardinality

Minimum cardinality

entity instances that relationship.

is the minimum number of

must

participate in a • 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-35

Indicating Minimum Cardinality

• As shown in the examples in a following slide: –

Minimum cardinality of zero [0]

indicating

optional

an

oval

participation is indicated by placing next to the optional entity.

Minimum cardinality of one [1] mandatory (required)

indicating 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-36

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-37

The Three Types of Minimum Cardinality

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-38

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.

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-39

A solid line indicates an

identifying relationship

ID-Dependent Entities

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-40

Weak Entities

• A weak entity is an entity whose existence depends upon another entity.

• All ID-Dependent entities are considered weak.

• Weak entities not necessarily ID Dependent.

– 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-41

Weak Entities (Continued)

A dashed line indicates a

nonidentifying relationship

Weak entities must be indicated by an accompanying text box in Erwin – There is no specific notation for a nonidentifying but weak entity relationship DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-42

Subtype Entities

• A

subtype entity supertype entity

: is a special case of a – 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-43

Subtypes with a Discriminator

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-44

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-45

Subtypes: Exclusive or Inclusive

(Continued) DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-46

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

value inappropriate nulls

.

DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-47

Unified Modeling Language (UML)

• The Unified Modeling Language is a set of structures and techniques for modeling and designing object-oriented programs (OOP).

• A primary difference between UML and E-R diagrams is that UML includes information about object constraints and methods. • Conversion between E-R and UML – Figure C-1(b) in Appendix C has a mistake DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-48