Concepts of Database ManagementSeventh Edition

Chapter 6

Database Design 2: Design Method

Objectives

• Discuss the general process and goals of database design

• Define user views and explain their function

• Define Database Design Language (DBDL) and use it to document database designs

• Create an entity-relationship (E-R) diagram to visually represent a database design

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

2

Objectives (continued)

• 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

3

Objectives (continued)

• 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

4

Introduction

• Two-step process for database design

• Information-level or conceptual level design: completed independently of any particular DBMS

• Physical-level design: information-level design adapted for the specific DBMS that will be used– Must consider characteristics of the particular DBMS

5

User Views

• User view: set of requirements necessary to support operations of a particular database user

• Cumulative design: supports all user views encountered during design process

6

Information-Level Design Method• For each user view:

1. Represent the user view as a collection of tables. Use the EAR method to do this.a) Entity – identify the entities (e.g. Students, Courses)

b) Attributes – identify the attributes for each entity

c) Relationship – create relationship among related tables

2. Normalize these tables

3. Identify all keys in these tables

4. Merge the result of Steps 1 through 3 into the cumulative design

Mnemonics : RaNK Me

7

Represent the User View As a Collection of Tables

• Step 1: Determine the entities involved and create a separate table for each type of entity

• Step 2: Determine the primary key for each table

• Step 3: Determine the properties for each entity

• Step 4: Determine relationships between the entities– One-to-many– Many-to-many– One-to-one

8

Represent the User View As a Collection of Tables (continued)

• One-to-many relationship: include primary key of the “one” table as a foreign key in the “many” table

• Many-to-many relationship: create a new table whose primary key is the combination of the primary keys of the original tables

• One-to-one relationship: simplest implementation is to treat it as a one-to-many relationship

9

Normalize the Tables

• Normalize each table

• Target is third normal form– Careful planning in early phases of the process

usually rules out need to consider fourth normal form

10

Identify All Keys

• For each table, identify:– Primary key– Alternate keys– Secondary keys– Foreign keys

• Alternate key: column(s) that could have been chosen as a primary key but was not

• Secondary keys: columns of interest strictly for retrieval purposes

11

Identify All Keys (continued)

• Foreign key: column(s) in one table that is required to match value of the primary key for some row in another table or is required to be null– Used to create relationships between tables– Used to enforce certain types of integrity constraints

12

Types of Primary Keys

• Natural key: consists of a column that uniquely identifies an entity– Also called a logical key or an intelligent key

• Artificial key: column created for an entity to serve solely as the primary key and that is visible to users

• Surrogate key: system-generated; usually hidden from users– Also called a synthetic key

13

Database Design Language (DBDL)

• Table name followed by columns in parentheses – Primary key column(s) underlined

• AK identifies alternate keys

• SK identifies secondary keys

• FK identifies foreign keys– Foreign keys followed by an arrow pointing to the

table identified by the foreign key

14

Database Design Language (DBDL) (continued)

FIGURE 6-1: DBDL for the Employee table

15

Entity-Relationship (E-R) Diagrams

• Visually represents database structure or the conceptual model of the Database

16

Building Blocks of ERD

17

Type English Grammar Equivalent Example

Entity Proper Noun Student, Employee, Instructor, Courses, Room

Relationship Verb has, teaches, belongs, handles

Attribute Adjective Height, Age, Gender, Nationality, First name

ERD Popular Notation

• Chen Notation• Crow’s Foot Notation

18

Chen Notation - Symbol

19

1 M

Rectangle represents an Entity

Diamond represents a Relationship

Lines with labels represents Cardinality

Entity (Chen Notation)

• is a real-world object distinguishable or unique from other objects.

• An entity can be a concrete or physical object like employee, student, faculty, customer etc. Or it could also be conceptual or abstract like transaction, order, course, subjects etc.

• It can be thought of as a noun like student, employee etc.

• It is normally represented by a rectangle shape.

20

Database Background• Remember in Chapter 1 Entity could be a :

21

Person

Place

(ex. Teacher, Student, Physician)

(ex. School, Hotel, Store )

Object(ex. Mouse, Books, Bulding )

Event (ex. Enroll, Withdraw, Order )

Idea or Concept (ex. Courses, Account, Delivery )

Entity - Example

• For example in our Premiere Database the different Entities are the following:

22

Customer Sales Rep

Order

Parts

Relationship

• is a way of relating one entity to another. Entities can therefore participate in a relationship.

• it is commonly thought as a verb connecting the entities or nouns.

• It is normally represented by a diamond shape.

23

Relationship - Example

• For example in our Premiere Database again we have this relationships among entities:

24

represents CustomerSales Rep

Order

has

Could be read as : A Sales RepRepresents a Customer. And aCustomer has an Order.

Cardinality

• Cardinality: 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

25

Cardinality - Symbols

26

One-is-to-many Relationship

1 M

M N

Many-to-many Relationship

Cardinality Symbols - Example

27

represents CustomerSales Rep

Could be read as : A Sales Rep could represent1 or Many Customers.

1 M

Cardinality Symbols – Example (Cont’d)

28

has PartsOrder

Could be read as : An Order could have many Parts (e.g. ProductsOrdered) and a Part could have many Orders.

M N

Degree of Relationship

• There are three Degree of Relationships in ERD notation, namely:– Unary– Binary– Ternary

29

Degree of Relationship (Cont’d)

30

Unary

Binary

Ternary

Degree of Relationship (Cont’d)

31

Employee

Unary

Customer Orders Binary

Vendor Warehouse

Part

Ternary

Manages

makes

supplies

Attribute

• Refers to the characteristic or basic fact or field of an Entity or Relationship.

• For example a Student entity could have the following attributes ID Number, Last Name, First Name, Address, Birth Date etc.

• A relationship could also have an attribute for example an Entity name Student enrolls (relationship) to a Course/Program. Now, when you enroll you enroll on a certain date so you will have an attribute of Enrollment Date under Enroll relationship.

• It is normally represented by an oval.

32

Attribute - Example

33

RepNum

Sales Rep

LastnameFirstname

Street

City

State

Zip CommissionRate

Take note thata Primary Keyis underlined.

Attribute – More Example

34

RepNum

Sales Rep

LastnameFirstname

Street

City

State

Zip CommissionRate

Customerrepresents

CustomerNum

CustomerName

CreditLimit

Balance

Street

City

State

Zip

1 M

Crow’s Foot notation - Symbol

35

Entity name

Attribute 1Attribute 2Attribute 3Attribute 4

Crow’s Foot notation - Example

36

Student

StudentIDFirstnameLastnameGenderProgram

Entity

Attributes

Crow’s Foot notation - Keys

37

Student

StudentID (PK)Firstname (SK)Lastname (SK)GenderProgramID (FK)

PK – Primary Key

FK – Foreign Key

SK – Secondary Key

Crow’s Foot Cardinality - Symbols

38

One and only one included in the relationship

Zero or many could be included in the relationship. This is optional mode.

One or many could be included in the relationship.This is mandatory mode.

Crow’s Foot notation – with Cardinality

39

Rep

Repnum (PK)FirstnameLastnameCommissionRate

Customer

Customernum(PK)CustomernameStreetCityStateZipBalanceCreditLimitRepnum (FK)

ERD for Department/Employee example

40

Department

DepartmentNum(PK)NameLocation

Customer

EmployeeNum(PK)Lastname (SK)Firstname (SK)StreetCityStateZipWageRateSocSecNum (AK)DepartmentNum (FK)

Graded Seatwork

41

• Make an ERD using both Chen and Crow’s Foot notation for Question No. 6 letter c on Page 224 of your Textbook – c. An employee can work on many projects and a

project can be worked on many employees

Merge the Result into the Design

• Combine tables that have the same primary key to form a new table

• New table:– Primary key is same as the primary key in the tables

combined– Contains all the columns from the tables combined– If duplicate columns, remove all but one copy of the

column

• Make sure new design is in third normal form

42

Merge the Result into the Design (continued)

FIGURE 6-3: Information-level design method

43

Database Design Examples

• Develop an information-level design

• Company stores information about sales reps, customers, parts, and orders

• User view requirements

• Constraints

FIGURE 6-4: Cumulative design after first user view

44

Database Design Examples (continued)

FIGURE 6-6: Cumulative design after third user view

45

Database Design Examples (continued)

FIGURE 6-8: Final information-level design46

Database Design Examples (continued)

• Henry Books database: information about branches, publishers, authors, and books

• User view requirements

FIGURE 6-9: DBDL for Book database after first user view

47

Database Design Examples (continued)

FIGURE 6-10: DBDL for Book database after second user view

48

Database Design Examples (continued)

FIGURE 6-13: Cumulative design after fifth user view49

Physical-Level Design

• Undertaken after information-level design completion

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

• To enforce restrictions, DB programmers must include logic in their programs

50

Top-Down Versus Bottom-Up

• Bottom-up design method– Design starts at low level – Specific user requirements drive design process

• Top-down design method– Begins with general database that models overall

enterprise– Refines model until design supports all necessary

applications

51

Survey Form

• Used to collect information from users

• Must contain particular elements– Entity information– Attribute (column) information– Relationships– Functional dependencies– Processing information

52

Obtaining Information from Existing Documents

• Existing documents can furnish information about database design

• Identify and list all columns and give them appropriate names

• Identify functional dependencies

• Determine the tables and assign columns

53

Obtaining Information from Existing Documents (continued)

FIGURE 6-14: Invoice for Holt Distributors

54

Obtaining Information from Existing Documents (continued)

FIGURE 6-15: List of possible attributes for the Holt Distributors invoice

55

Obtaining Information from Existing Documents (continued)

FIGURE 6-17: Revised list of functional dependencies for the Holt Distributors invoice

56

Obtaining Information from Existing Documents (continued)

FIGURE 6-19: Expanded list of entities

57

One-to-One Relationship Considerations

• Simply include the primary key of each table as a foreign key in the other table– No guarantee that the information will match

• One solution: create a single table– Workable, but not the best solution

• Better solution– Create separate tables for customers and sales reps– Include the primary key of one of them as a foreign

key in the other

58

One-to-One Relationship Considerations (continued)

FIGURE 6-23: One-to-one relationship implemented by including the primary key of one table as the foreign key (and alternate key) in the other table

59

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

• Deciding between a single many-to-many-to-many relationship and two (or three) many-to-many relationships– Crucial issue: independence

60

Many-to-Many Relationship Considerations (continued)

FIGURE 6-25: Result obtained by splitting the Sales table into three tables61

Many-to-Many Relationship Considerations (continued)

FIGURE 6-26: Result obtained by joining three tables—the second and third rows are in error!

62

Nulls and Entity Subtypes

• Null– Special value– Represents absence of a value in a field– Used when a value is unknown or inapplicable

• Splitting tables to avoid use of null values

• Entity subtype: table that is a subtype of another table

63

Nulls and Entity Subtypes (continued)

FIGURE 6-27: Student table split to avoid use of null values64

Nulls and Entity Subtypes (continued)

• Subtype called a category in IDEF1X terminology

• Incomplete category: records that do not fall into the subtype

• Complete categories: all records fall into the categories

65

Nulls and Entity Subtypes (continued)

FIGURE 6-29: Entity subtype in an E-R diagram

66

Nulls and Entity Subtypes (continued)

FIGURE 6-32: Two entity subtypes—incomplete categories

67

Nulls and Entity Subtypes (continued)

FIGURE 6-33: Two entity subtypes—complete categories

68

Avoiding Problems with Third Normal Form When Merging Tables

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

• Be cautious when representing user views

• Always attempt to determine whether determinants exist and include them in tables

69

The 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

• Composite entity: exists to implement a many-to-many relationship

• Existence dependency: existence of one entity depends on the existence of another related entity

• Weak entity: depends on another entity for its own existence

70

The Entity-Relationship Model (continued)

FIGURE 6-34: One-to-many relationship

71

The Entity-Relationship Model (continued)

FIGURE 6-35: Many-to-many relationship

72

The Entity-Relationship Model (continued)

FIGURE 6-36: Many-to-many-to-many relationship

73

The Entity-Relationship Model (continued)

FIGURE 6-37: One-to-many relationship with attributes added

74

The Entity-Relationship Model (continued)

FIGURE 6-38: Many-to-many relationship with attributes

75

The Entity-Relationship Model (continued)

FIGURE 6-39: Composite entity

76

The Entity-Relationship Model (continued)

FIGURE 6-40: Complete E-R diagram for the Premiere Products database

77

The Entity-Relationship Model (continued)

FIGURE 6-41: E-R diagram with an existence dependency and a weak entity

78

The Entity-Relationship Model (continued)

• Cardinality: 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

79

The Entity-Relationship Model (continued)

FIGURE 6-43: E-R diagram that represents cardinality

80

Summary

• Database design is a two-part process: information-level design (not dependent on a particular DBMS) and physical-level design (appropriate for the particular DBMS being used)

• User view: set of necessary requirements to support a particular user’s operations

• Information-level design steps for each user view: represent the user view as a collection of tables, normalize these tables, represent all keys (primary, alternate, secondary, and foreign), and merge the results into the cumulative design

81

Summary (continued)

• Database design is represented in Database Design Language (DBDL)

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

• Physical-level design process consists of creating a table for each entity in the DBDL design

• Design method presented in this chapter is bottom-up

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

82

Summary (continued)

• To obtain information from existing documents, list all attributes present in the documents, identify potential functional dependencies, make a tentative list of tables, and use the functional dependencies to refine the list

• To implement a one-to-one relationship, include primary key of one table in the other table as a foreign key and indicate the foreign key as an alternate key

83

Summary (continued)

• If a table’s primary key consists of three (or more) columns, determine whether there are independent relationships between pairs of these columns

• If a table contains columns that can be null and the nulls mean that the column is inapplicable for some rows, you can split the table, placing the null column(s) in separate tables

• The result of merging third normal form tables may not be in third normal form

• Entity-relationship (E-R) model represents the structure of a database using an E-R diagram

84