© pearson education limited, 20041 chapter 9 logical database design – step 1 transparencies

© Pearson Education Limited, 2004

1

Chapter 9

Logical database design – Step 1

Transparencies


2

Chapter 9 - Objectives

What a design methodology is. Database design has two main

phases: logical and physical design.

Critical success factors in database design.


3

Chapter 9 - Objectives About a methodology for logical

and physical database design. The tasks in Step 1 of the

database design methodology, which build an ER model.

The documentation produced during Step 1 of database design, including Entity–Relationship (ER) diagrams and a data dictionary.


4

Introduction to the database design methodology If the database is reasonably

complex, a systematic approach is needed to design and build the database to ensure that it satisfies users’ requirements and achieves stated performance requirements.

This systematic approach is called a database design methodology.


5

What is a design methodology?

A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design.


6

Phases of database design Two main phases: logical and

physical database design. Logical database design is the

process of constructing a model of data used in an organization based on a specific data model, but independent of a particular DBMS and other physical considerations.


7

Phases of database design Physical database design is the

process of producing a description of the implementation of the database on secondary storage; it describes the base tables, file organizations, and indexes used to achieve efficient access to the data, and any associated integrity constraints and security restrictions.


8

Critical success factors in database design Work interactively with the users

as much as possible. Follow a structured methodology

throughout the data modeling process.

Employ a data-driven approach. Incorporate structural and integrity

considerations into the data models.


9

Critical success factors in database design

Use normalization and transaction validation techniques in the methodology.

Use diagrams to represent as much of the data models as possible.

Use a database design language (DBDL).


10

Critical success factors in database design

Build a data dictionary to supplement the data model diagrams.

Be willing to repeat steps.


11

Overview of the database design methodology


12

Step 1 Create and check ER model

Objective is to build an ER model of the data requirements of an organization (or part of an organization) to be supported by the database.


13

Step 1 - Tasks

Step 1.1 Identify entities Step 1.2 Identify relationships Step 1.3 Identify and associate

attributes with entities or relationships

Step 1.4 Determine attribute domains


14

Step 1 - Tasks

Step 1.5 Determine candidate, primary, and alternate key attributes

Step 1.6 Specialize/Generalize entities (optional step)

Step 1.7 Check model for redundancy


15

Step 1 - Tasks

Step 1.8 Check model supports user transactions

Step 1.9 Check model with users


16

Step 1.1 Identify entities One method is to examine the

users’ requirements specification for nouns or noun phrases

Also look for major objects such as people, places, or concepts of interest, excluding those nouns that are merely qualities of other objects.

Document entities


17

StayHome entities

Branch StaffVideo VideoForRentMember RentalAgreementActor Director


18

Extract from data dictionary for StayHome


19

Step 1.2 Identify relationships One method is to examine users’

requirements specification for verbs or verbal expressions.

Use entity–relationship (ER) modeling

Determine the multiplicity constraints of relationships

Check for fan and chasm traps Document relationships


20

First ER diagram of StayHome


21

First draft of relationships for StayHome


22

Multiplicity constraints for relationships


23

Adding multiplicity constraints to ER diagram


24

Extract from the data dictionary showing descriptions of relationships


25

Step 1.3 Identify and associate attributes with entities or relationships

Attributes can be identified where noun or noun phrase is a property, quality, identifier, or characteristic of one of the entities or relationships previously found.

Document attributes


26

Documenting attributes

attribute name and description; data type and length; any aliases that the attribute is

known by; whether the attribute must

always be specified (in other words, whether the attribute allows or disallows nulls);


27

Documenting attributes whether the attribute is multi-

valued; whether the attribute is composite,

and if so, which simple attributes make up the composite attribute;

whether the attribute is derived and, if so, how it should be computed;

default values for the attribute (if specified).


28

Associate attributes with entities

Branch (branchNo, address(composite street, city state, zipCode), telNo (multi-valued))

Staff (staffNo, name, position, salary)Video (catalogNo, title, category, dailyRental, price)Director (directorName)Actor (actorName)Member (memberNo, name (composite: fName,

lName), address)RentalAgreement (rentalNo, dateOut, dateReturn)VideoForRent (videoNo, available)


29

Extraction of data dictionary showing descriptions of attributes


30

Step 1.4 Determine attribute domains

A domain is a pool of values from which one or more attributes draw their values

A domain specifies: allowable set of values for the

attribute; size and format of the attribute.

Document attribute domains


31

Step 1.5 Determine candidate, primary, and alternate key attributes

Identifying candidate key(s) for an entity and then selecting one to be the primary key.

Candidate keys can never be null. Remaining candidate keys are

called alternate keys. Document candidate, primary,

and alternate keys


32

Guidelines for choosing a primary key

Select the candidate key the minimal set of attributes; that is less likely to have its

values changed; that is less likely to lose

uniqueness in the future;


33

Guidelines for choosing a primary key

Select the candidate key with fewest characters (for those

with textual attribute(s)); with the smallest maximum value

(for numerical attributes); that is easiest to use from the

users’ point of view.


34

ER diagram showing primary keys


35

Extract from data dictionary showing attributes with primary and alternate keys


36

Step 1.6 Specialize/Generalize entities (optional step)

Objective is to identify superclass and subclass entities, where appropriate.

The modeling of superclasses and subclasses adds more information to the data model, but also adds more complexity as well.


37

Step 1.7 Check model for redundancy

Examine the ER model and if redundancy found, remove from model.

The three activities in this step are: (1) re-examine one-to-one (1:1)

relationships; (2) remove redundant relationships; (3) consider the time dimension when

assessing redundancy.


38

Remove redundant relationships


39

Non-redundant relationships


40

Step 1.8 Check model supports user transactions

ER model represents the data requirements of the organization

Objective is to check that ER model supports the required transactions.

Two possible approaches: (1) Describing the transaction (2) Using transaction pathways


41

Using pathways to check ER model supports user transactions


42

Step 1.9 Check model with users

Objective is to review the ER model with the user to ensure that the model is a ‘true’ representation of the data requirements of the organization (or the part of the organization) to be supported by the database.

© pearson education limited, 20041 chapter 9 logical database design – step 1 transparencies

Documents

database design methodologyif

logical database design

database designbuild

database designwork

physical design

process of design

database design language

model of data