© pearson education limited, 20041 chapter 9 logical database design – step 1 transparencies
TRANSCRIPT
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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).
© Pearson Education Limited, 2004
10
Critical success factors in database design
Build a data dictionary to supplement the data model diagrams.
Be willing to repeat steps.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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
© Pearson Education Limited, 2004
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
© Pearson Education Limited, 2004
15
Step 1 - Tasks
Step 1.8 Check model supports user transactions
Step 1.9 Check model with users
© Pearson Education Limited, 2004
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
© Pearson Education Limited, 2004
17
StayHome entities
Branch StaffVideo VideoForRentMember RentalAgreementActor Director
© Pearson Education Limited, 2004
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
© Pearson Education Limited, 2004
24
Extract from the data dictionary showing descriptions of relationships
© Pearson Education Limited, 2004
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
© Pearson Education Limited, 2004
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);
© Pearson Education Limited, 2004
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).
© Pearson Education Limited, 2004
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)
© Pearson Education Limited, 2004
29
Extraction of data dictionary showing descriptions of attributes
© Pearson Education Limited, 2004
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
© Pearson Education Limited, 2004
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
© Pearson Education Limited, 2004
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;
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
35
Extract from data dictionary showing attributes with primary and alternate keys
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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.
© Pearson Education Limited, 2004
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