concepts of database management, fifth edition chapter 6: database design 2: design methodology

Concepts of Database Concepts of Database Management, Fifth Management, Fifth

EditionEdition

Chapter 6: Chapter 6: Database Design 2:Database Design 2:Design MethodologyDesign Methodology

2Concepts of Database Management, 5th Edition

Objectives Discuss the general process and goals of

database design

Define user views and explain their function

Define database design language and use it to document database designs

Create an entity-relationship diagram to visually represent a database design

Present a methodology for database design at the information level and view examples illustrating this methodology


Objectives

Explain the physical-level design process

Discuss top-down and bottom-up approaches to database design and examine the advantages and disadvantages of both methods

Use a survey form to obtain information from users prior to beginning the database design process

Review existing documents to obtain information prior to beginning the database design


Objectives Discuss special issues related to implementing

one-to-one relationships and many-to-many relationships involving more than two entities

Discuss entity subtypes and their relationships to nulls

Learn how to avoid potential problems when merging third normal form relations

Examine the entity-relationship model for representing and designing databases


Database Design Information-level Design – building a database that

satisfies the organization’s requirements as cleanly as possible

Physical-level design – designers transform the information-level design into a design for the specific DBMS used by the organization

User Views – requirements necessary to support a particular user’s operations

Cumulative design – supports all user views encountered so far in the design process


Information-Level Design Methodology

Information-level Design Methodology

Represent user view as collection of tables

Normalize these tables

Identify all keys

Merge the result into design


Represent User View as Collection of Tables

Step 1: Determine entities involved and create separate table for each type

Step 2: Determine primary key for each table

Step 3: Determine properties for each entities

Step 4: Determine relationships among entities


Types of Relationships

One-to-Many Relationships – created by including the primary key of the “one” table as a foreign key in the “many” table

Many-to-Many Relationships – created with a new table whose primary key is the combination of the primary keys of the original tables

One-to-One Relationship – created with a single relationship from one record in a table to a single record in another table


Normalize the Tables

Represent all keys

Primary, alternate, secondary, foreign

Database Design Language (DBDL)

Mechanism for representing tables and keys

DBDL Example

Figure 6.1


Types of Primary Keys Three types of primary keys used in database

design

1. Natural key (logical key or intelligent key) – consists of a column that uniquely identifies an entity

2. Artificial key – column created for an entity to serve solely as the primary key; visible to users

3. Surrogate key (synthetic key) – system-generated primary key usually hidden from users


DBDL Notation

Table name followed by columns in parentheses

Primary key column(s) underlined

AK identifies alternate keys

SK identifies secondary keys

FK identifies foreign keys


Entity-Relationship Diagrams

Diagram that visually represents database structure

Rectangle represents each entity in the E-R diagram

Primary key for each entity appears above the line in the rectangle for each entry


Entity-Relationship Diagrams

Other columns that comprise each entity appear below the line within each rectangle

The letters AK, SK, and FK appear in parentheses following the alternate key, secondary key, and foreign key respectively

For each foreign key, there is a line leading from the rectangle that corresponds to the table being identified to the rectangle that corresponds to the table containing the foreign key


Figure 6.2: Entity-Relationship Diagrams


Merge the Result into the Design

As soon as Steps 1 through 3 for a given user view have been completed, the results can be merged into the cumulative design

If the working view is the first user view, the cumulative design will be identical to the design for the first user

Otherwise, all the tables for this user with those that are currently in the cumulative design


Merge the Result into the Design (con’t)

Next, you combine tables that have the same primary key to form a new table

New table has the same primary key as those tables you have combined

New table also contains all the columns from both tables

In the case of duplicate columns, you remove all but one copy of the column


Figure 6.4:User View Examples

View #1: Sales Rep View

Rep (RepNum, LastName, FirstName, Street, City, State, Zip, Commission, Rate)


View #2: Customer View

Figure 6.5:User View Examples


Entities

Independent entity - an entity that does not require a relationship to another entity for identification

Dependent entity - an entity that does require a relationship to another entity for identification


Physical-Level Design

Undertaken after information-level design completion

Most DBMSs support primary, candidate, secondary, and foreign keys

DB programmers must include logic to ensure the uniqueness of primary keys and enforce other conditions


Top-Down vs. Bottom-Up

Bottom-up

Design starts at low level

Specific user requirements drive design process

Top-down

Begins with general database that models overall enterprise

Refines the model until design is achieved


Survey Form

Used to collect information from users

Must contain particular elements

Entity information

Attribute information

Relationships

Functional dependencies

Processing information


Existing Documents

Aid in collecting user requirements

Collect information similar to that collected with survey forms

Entity information

Attribute information

Relationships

Functional dependencies

Processing information


Figure 6.14: Example Invoice


Figure 6.15: List of Possible Attributes


Figure 6.16:Tentative List of Functional Dependencies


Figure 6.17:Revised List of

Functional Dependencies


Figure 6.18:Tentative List of Entities


Figure 6.19:Expanded List of Entities


One-to-One Relationship Considerations

Implementing a one-to-one relationship by simply including the primary key of each table as a foreign key in the other table

A problem is that there is no guarantee that the information will match


One-to-One Relationship Considerations (con’t)

One possible solution is to create a single table

Although workable, two features are not particularly attractive:

1. Combines columns of two different entities into a single table

2. If possible for one entity to exist without the other


One-to-One Relationship Considerations (con’t)

Better solution

Create two separate tables for customers and sales reps and to include the primary key of one of them as a foreign key in the other

This foreign key would also be designated as an alternate key


Figure 6.20:1:1 Relationship Considerations

Include primary key of each table as foreign key in the other



Implementation when information does not match



Implemented in a single table


Figure 6.23:

1:1 Relationship Considerations

1:1 relationship implemented by including primary key of one table as foreign key (and alternative key) in the other


Many-to-Many Relationship Considerations

Complex issues arise when more than two entities are related in a many-to-many relationship

Many-to-many-to-many relationship – involves multiple entities

Crucial issue in making the determination between a single many-to-many-to-many relationship and two (or three) many-to-many relationships is the independence


Figure 6.24: M:M Relationship Considerations

Sample Sales Data


Figure 6.25:M:M Relationship Considerations

Result obtained by splitting Sales table into three tables


Figure 6.26:M:M Relationship Considerations

Result obtained by joining three tables--2 rows are in error. Must be converted to 4NF


Nulls

Null - a special value

Null - actually represents the absence of a value in a field

Nulls - used when a value is either unknown or inapplicable


Nulls are absence of values

Figure 6.27: Table SplitTo Avoid Nulls


Figure 6.28: Sample DBDL


Entity Subtypes

Entity subtype – table that is a subtype of another table

Incomplete category – records that do not fall into the subtype

Complete categories – all records fall into the categories


Figure 6.29: Entity Subtypes


Figure 6.32:Two Entity Subtypes—Incomplete Categories


Figure 6.33: Two Entity Subtypes—Complete Categories


Avoiding Problems with 3NF When Merging Tables

When combining third normal form tables, the result need not be in third normal form

To avoid the problem of creating a table that is not in third normal form, be cautious when representing user views

If you always attempt to determine whether determinants exist and include them in the tables, the problem is often avoided


Entity-Relationship Model

An approach to representing data in a database

Entities are drawn as rectangles

Relationships are drawn as diamonds with lines connecting the entities involved in relationships


Figure 6.34:One-to-many relationship


Figure 6.35:Many-to-Many Relationship


Figure 6.36:Many-to-Many Relationship


Figure 6.37:One-to-Many Relationship


Figure 6.38: Many-to-Many Relationship with Attributes


Composite Entity

Composite entity - an entity that exists to implement a many-to-many relationship

Essentially both an entity and a relationship

Represented in an E-R diagram by a diamond within a rectangle


Figure 6.39:Composite Entity


Figure 6.40: Complete E-R Diagram


E-R Diagram with an Existence Dependency and Weak Entity

Existence dependency - when the existence of one entity depends on the existence of another related entity

Indicate an existence dependency by placing an “E” in the relationship diamond

Weak entity - an entity that depends on another entity for its own existence

A double rectangle encloses a weak entity


Figure 6.41: E-R Diagram with an Existence Dependency and Weak Entity


Cardinality

Cardinality - the number of items that must be included in a relationship

An entity in a relationship with minimum cardinality of zero plays an optional role in the relationship

An entity with a minimum cardinality of one plays a mandatory role in the relationship


Figure 6.43: E-R Diagram that Represents Cardinality


Summary Database design is a two-part process of

determining an appropriate database structure to satisfy a given set of requirements

A user view is the set of necessary requirements to support a particular user’s operations

A database design is represented in a language called Database Design Language (DBDL)

Designs can be represented pictorially using entity-relationship (E-R) diagrams


Summary

Advantages to both top-down and bottom-up approaches

Survey form is useful for documenting the information gathered for database design process

One-to-One and One-to-Many relationships require attention to primary keys

Entity-relationship (E-R) model is a method of representing the structure of a database using an E-R diagram

concepts of database management, fifth edition chapter 6: database design 2: design methodology

Documents

database designpresent

database designscreate

database structurerectan

intelligent key

information level

entityartificial key

entityrelationship model

single relationship