P. 1
dbdesign-logdgnpart2

dbdesign-logdgnpart2

|Views: 105|Likes:
Published by sambashivarao

More info:

Published by: sambashivarao on Oct 24, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

05/09/2014

pdf

text

original

Chapter 3 Database Design: Logical Design-Part2

Introduction

Steps For Designing Database
Conceptual Design

STEP 1

STEP 2
Logical Design

STEP 3

STEP 4 STEP 5
Physical Design

STEP 6 STEP 7

STEP 8 STEP 9

Methodology Overview Conceptual Database Design
 Step
  

1 Build local conceptual data model for each user view
Step 1.1 Identify entity types Step 1.2 Identify relationship types Step 1.3 Identify and associate attributes with entity or relationship types Step 1.4 Determine attribute domains Step 1.5 Determine candidate and primary key attributes Step 1.6 Consider use of enhanced modeling concepts (optional step) Step 1.7 Check model for redundancy Step 1.8 Validate local conceptual model against user transactions Step 1.9 Review local conceptual data model with user

  

  

Methodology Overview - Logical Database Design for Relational Model
 Step

2 Build and validate local logical data model for each view
Step 2.1 Remove features not compatible with the relational model (optional step)  Step 2.2 Derive relations for local logical data model  Step 2.3 Validate relations using normalization  Step 2.4 Validate relations against user transactions  Step 2.5 Define integrity constraints  Step 2.6 Review local logical data model with user

Methodology Overview - Logical Database Design for Relational Model(cont)
 Step

3 Build and validate global logical data model
Step 3.1 Merge local logical data models into global model  Step 3.2 Validate global logical data model  Step 3.3 Check for future growth  Step 3.4 Review global logical data model with users

Methodology Overview - Physical Database Design for Relational Databases

Step 4 Translate global logical data model for target DBMS  Step 4.1 Design base relations  Step 4.2 Design representation of derived data  Step 4.3 Design enterprise constraints Step 5 Design physical representation  Step 5.1 Analyze transactions  Step 5.2 Choose file organization  Step 5.3 Choose indexes  Step 5.4 Estimate disk space requirements

Methodology Overview - Physical Database Design for Relational Databases(cont)
Step 6 Design user views  Step 7 Design security mechanisms  Step 8 Consider the introduction of controlled redundancy  Step 9 Monitor and tune the operational system

Normalization

Normalization
 Main

objective in developing a logical data model for relational database systems is to create an accurate representation of the data, its relationships, and constraints.  To achieve this objective, must identify a suitable set of relations.

Normalization(cont)
 Four

most commonly used normal forms are first (1NF), second (2NF) and third (3NF) normal forms, and Boyce–Codd normal form (BCNF).  Based on functional dependencies among the attributes of a relation.  A relation can be normalized to a specific form to prevent possible occurrence of anomalies and data redundancy.

Data Redundancy

Data Redundancy(cont)
 StaffBranch

relation has redundant data: details of a branch are repeated for every member of staff.  In contrast, branch information appears only once for each branch in Branch relation and only branchNo is repeated in Staff relation, to represent where each member of staff works.

Normalization(cont)

A bad database design may suffer from anomalies that make the database difficult to use: COMPANIES(company_name, owner_id, company_address, date_founded,owner_name, owner_title, #shares ) Suppose Primary Key (company_name, owner_id) Anomalies:  update anomaly occurs if changing the value of an attribute leads to an inconsistent database state.  insertion anomaly occurs if we cannot insert a tuple due to some design flaw.  deletion anomaly occurs if deleting a tuple results in unexpected loss of information. Normalization is the systematic process for removing all such anomalies in database design.

Update Anomaly
 If a company has three owners, there are three tuples in the COMPANIES relation for this company.  If this company moves to a new location, the company’s address must be updated consistently in all three tuples  updating the company address in just one or two of the tuples creates an inconsistent database state  It would be better if the company name and address were in a separate relation so that the address of each company appears in only one tuple

COMPANIES(company_name, company_address, date_founded, owner_id, owner_name, owner_title, #shares )

Example of Update Anomalies
To insert a new staff with branchNo B007 into the StaffBranch relation; To delete a tuple that represents the last member of staff located at a branch B007; To change the address of branch B003.
StaffBranch
staffNo
SL21 SG37 SG14 SA9 SG5 SL41

sName
John White Ann Beech David Ford Mary Howe Susan Brand Julie Lee

position
Manager Assistant Supervisor Assistant Manager Assistant

salary
30000 12000 18000 9000 24000 9000

branchNo
B005 B003 B003 B007 B003 B005

bAddress
22 Deer Rd, London 163 Main St,Glasgow 163 Main St,Glasgow 16 Argyll St, Aberdeen 163 Main St,Glasgow 22 Deer Rd, London

Figure 1 StraffBranch relation

Example of Update Anomalies (cont)
Staff
staffNo
SL21 SG37 SG14 SA9 SG5 SL41

sName
John White Ann Beech David Ford Mary Howe Susan Brand Julie Lee

position
Manager Assistant Supervisor Assistant Manager Assistant

salary
30000 12000 18000 9000 24000 9000

branceNo
B005 B003 B003 B007 B003 B005

Branch
branceNo bAddress
B005 B007 B003 22 Deer Rd, London 16 Argyll St, Aberdeen 163 Main St,Glasgow

Figure 2 Straff and Branch relations

Insert Anomaly
 Suppose that three people have just created a new company:  the three founders have no titles yet  stock distributions have yet to be defined  The new company cannot be added to the COMPANIES relation because there is not enough information to fill in all the attributes of a tuple  at best, null values can be used to complete a tuple  It would be better if owner and stock information was stored in a different relation COMPANIES(company_name, company_address, date_founded, owner_id, owner_name, owner_title, #shares )

Delete Anomaly
 Suppose that an owner of a company retires so is no longer an owner but retains stock in the company  If this person’s tuple is deleted from the COMPANIES relation, then we lose the information about how much stock the person still owns  If the stock information was stored in a different relation, then we can retain this information after the person is deleted as an owner of the company
COMPANIES(company_name, company_address, date_founded, owner_id, owner_name, owner_title, #shares )

Relationship Between Normal Forms

Steps For Normalization
Unnormalized Form
Remove Repeating Groups

First Normalized Form (1NF)
Remove Partial Dependencies

Second Normalized Form (2NF)
Remove Transitive Dependencies

Third Normalized Form (3NF)

Unnormalized Form (UNF) First Normal Form (1NF) Full Functional Dependency

A table that contains one or more repeating groups A relation in which the intersection of each row and column contains one and only one value Indicates that if A and B are attributes of a relation, B is fully functionally dependent on A if B is functionally dependent on A, but not on any proper subset of A. A relation that is in 1NF form and every nonprimary-key attribute is fully functionality dependent on the primary key. A condition where A, B, C are attributes of a relation such that if A->B and B->C then C is transitively dependent on A via B (provided that A is not functionally dependent on B or C) A relation that is in 1NF and 2NF, and in which no non-primary key attribute is transitively dependent on the primary key

Second Normal Form (2NF)

Transitive Dependency

Third Normal Form (3NF)

Unnormalized Table/Relation
SALESPERSON NUMBER SALESPERSON NAME SALES AREA CUSTOMER NUMBER CUSTOMER NAME WAREHOUSE NUMBER WAREHOUSE LOCATION SALES AMOUNT

3462

Waters

West

18765 18830 19242 18841 18899 19565

Delta Sys. Levy & Sons Ranier Com R.W.Flood Seward Stodola

4 3 3 2 2 1

Fargo Bismarck Bismarck Superior Superior Plymouth

13540 10600 9700 11560 2590 8800

3593

Dryne

East

First Normal Form (1NF)
SALESPERSON-CUSTOMER
{PK} SALESPERSON NUMBER CUSTOMER NUMBER

SALESPERSON
{PK} SALESPERSON NUMBER SALESPERSON NAME SALES AREA

3462 3593 …

Waters Dryne …

West East …

CUSTOMER NAME

WAREHOUSE NUMBER

WAREHOUSE LOCATION

SALES AMOUNT

3462 3462 3462

18765 18830 19242

Delta Sys. Levy & Sons Ranier Com

4 3 3

Fargo Bismarck Bismarck

13540 10600 9700

3593 3593 3593

18841 18899 19565

R.W.Flood Seward Stodola

2 2 1

Superior Superior Plymouth

11560 2590 8800

A Data Model Diagarm (SALESPERSON-CUSTOMER)
SALES AMOUNT CUSTOMER NAME

SALESPERSON NUMBER

CUSTOMER NUMBER

WAREHOUSE NUMBER

WAREHOUSE LOCATION

Second Normal Form (2NF)
CUSTOMER-WAREHOUSE
{PK} CUSTOMER NUMBER 18765 18830 19242 CUSTOMER NAME

SALES

SALESPERSON NUMBER 3462 3462 3462 3593 3593 3593

CUSTOMER NUMBER 18765 18830 19242 18841 18899 19565

SALES AMOUNT 13540 10600 9700 11560 2590 8800

WAREHOUSE NUMBER 4 3 3

WAREHOUSE LOCATION Fargo Bismarck Bismarck

Delta Sys. Levy & Sons Ranier Com

18841 18899 19565

R.W.Flood Seward Stodola

2 2 1

Superior Superior Plymouth

SALESPERSON
{PK} SALESPERSON NUMBER SALESPERSON NAME SALES AREA

SALES

SALESPERSON NUMBER 3462 3462 3462 3593 3593 3593

CUSTOMER NUMBER 18765 18830 19242 18841 18899 19565

SALES AMOUNT 13540 10600 9700 11560 2590 8800

3462 3593 …

Waters Dryne …

West East …

CUSTOMER-WAREHOUSE
{PK} CUSTOMER NUMBER 18765 18830 19242 CUSTOMER NAME WAREHOUSE NUMBER 4 3 3

WAREHOUSE LOCATION Fargo Bismarck Bismarck

Delta Sys. Levy & Sons Ranier Com

18841 18899 19565

R.W.Flood Seward Stodola

2 2 1

Superior Superior Plymouth

A Data Model Diagram (CUSTOMER-WAREHOUSE)
CUSTOMER NUMBER CUSTOMER NAME

WAREHOUSE NUMBER

WAREHOUSE LOCATION

WAREHOUSE

Third Normal Form (3NF)
CUSTOMER
{PK} {FK}

{PK}

WAREHOUSE NUMBER 4 3 2

WAREHOUSE LOCATION Fargo Bismarck Superior

CUSTOMER NUMBER 18765 18830 19242

CUSTOMER NAME Delta Sys. Levy & Sons Ranier Com

WAREHOUSE NUMBER 4 3 3

1 …

Plymouth …

18841 18899 19565

R.W.Flood Seward Stodola

2 2 1

SALESPERSON
{PK} SALESPERSON NUMBER SALESPERSON NAME SALES AREA

SALES
SALESPERSON NUMBER 3462 CUSTOMER NUMBER 18765 18830 19242 18841 18899 19565 SALES AMOUNT 13540 10600 9700 11560 2590 8800

3462 3593 …

Waters Dryne …

West East …
{FK}

3462 3462 3593 3593 3593

CUSTOMER
{PK}

CUSTOMER NUMBER 18765 18830 19242

CUSTOMER NAME Delta Sys. Levy & Sons Ranier Com

WAREHOUSE NUMBER 4 3 3
{PK}

WAREHOUSE
WAREHOUSE NUMBER 4 3 2 WAREHOUSE LOCATION Fargo Bismarck Superior

18841 18899 19565

R.W.Flood Seward Stodola

2 2 1

1 … … … …

Plymouth …

Boyce-Codd Form (BCNF)
 A more restricted version of 3NF (known as BoyceCodd Normal Form) A relation is in BCNF, if and only if, every determinant is a candidate key.  Consider the following relation: StaffProject(StnNo,PjcNo, StaffNo); StnNo,PjcNo -> StaffNo (primary key) StaffNo,StnNo -> PjcNo (candidate key) StaffNo -> PjcNo (not a candidate key)  Boyce-Codd Normal Form for above: Project(PjcNo, StnNo); Staff(StaffNo, PjcNo)

Conceptual Level, Conceptual Schema, Logical Design, Logical Data Model

CASE 1
DreamHome Case Study – An Overview Pls refer to Connolly, T., Begg, C.(2002).“Database System: A Practical Approach to Design, Implementation, and Management”, Addision Wesley, USA Chapter 10, Section 10.4.1, pp 309

Functional Dependencies
Functional dependency describes the relationship between attributes in a relation. For example, if A and B are attributes of relation R, and B is functionally dependent on A ( denoted A B), if each value of A is associated with exactly one value of B. ( A and B may each consist of one or more attributes.)
B is functionally dependent on A

A Determinant

B

Refers to the attribute or group of attributes on the left-hand side of the arrow of a functional dependency

First Normal Form (1NF)
Unnormalized form (UNF) A table that contains one or more repeating groups.
ClientNo cName propertyNo PG4 PG16 pAddress 6 lawrence St,Glasgow 5 Novar Dr, Glasgow 6 lawrence St,Glasgow 2 Manor Rd, Glasgow 5 Novar Dr, Glasgow rentStart 1-Jul-00 rentFinish 31-Aug-01 rent 350 ownerNo CO40 oName Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw

CR76

John kay

1-Sep-02 1-Sep-99

1-Sep-02 10-Jun-00

450 350

CO93 CO40

PG4 Aline Stewart

CR56

PG36

10-Oct-00

1-Dec-01

370

CO93

PG16

1-Nov-02

1-Aug-03

450

CO93

Figure 3 ClientRental unnormalized table

1NF ClientRental relation with the first approach
The ClientRental relation is defined as follows:
ClientRental ( clientNo, propertyNo, cName, pAddress, rentStart, rentFinish, rent, ownerNo, oName)
ClientNo
CR76 CR76 CR56

propertyNo
PG4 PG16 PG4

cName
John Kay John Kay Aline Stewart Aline Stewart Aline Stewart

pAddress
6 lawrence St,Glasgow 5 Novar Dr, Glasgow 6 lawrence St,Glasgow 2 Manor Rd, Glasgow 5 Novar Dr, Glasgow

rentStart
1-Jul-00 1-Sep-02 1-Sep-99

rentFinish
31-Aug-01 1-Sep-02 10-Jun-00

rent
350 450 350

ownerNo
CO40 CO93 CO40

oName
Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw

CR56

PG36

10-Oct-00

1-Dec-01

370

CO93

CR56

PG16

1-Nov-02

1-Aug-03

450

CO93

Figure 4 1NF ClientRental relation with the first approach

1NF ClientRental relation with the second approach
Client PropertyRentalOwner (clientNo, cName) (clientNo, propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName)

ClientNo
CR76 CR56

cName
John Kay Aline Stewart

With the second approach, we remove the repeating group (property rented details) by placing the repeating data along with a copy of the original key attribute (clientNo) in a separate relation.
pAddress
6 lawrence St,Glasgow 5 Novar Dr, Glasgow 6 lawrence St,Glasgow 2 Manor Rd, Glasgow 5 Novar Dr, Glasgow

ClientNo
CR76 CR76 CR56 CR56 CR56

propertyNo
PG4 PG16 PG4 PG36 PG16

rentStart
1-Jul-00 1-Sep-02 1-Sep-99 10-Oct-00 1-Nov-02

rentFinish
31-Aug-01 1-Sep-02 10-Jun-00 1-Dec-01 1-Aug-03

rent
350 450 350 370 450

ownerNo
CO40 CO93 CO40 CO93 CO93

oName
Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw

Figure 5 1NF ClientRental relation with the second approach

2NF ClientRental relation
The ClientRental relation has the following functional dependencies:
fd1 fd2 fd3 fd4 fd5 fd6 clientNo, propertyNo  rentStart, rentFinish (Primary Key) clientNo  cName (Partial dependency) propertyNo  pAddress, rent, ownerNo, oName (Partial dependency) ownerNo  oName (Transitive Dependency) clientNo, rentStart  propertyNo, pAddress, rentFinish, rent, ownerNo, oName (Candidate key) propertyNo, rentStart  clientNo, cName, rentFinish (Candidate key)

2NF ClientRental relation
Client (clientNo, cName) Rental (clientNo, propertyNo, rentStart, rentFinish) PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)
Client
ClientNo
CR76 CR56

Rental
cName
John Kay Aline Stewart

ClientNo
CR76 CR76 CR56 CR56 CR56

propertyNo
PG4 PG16 PG4 PG36 PG16

rentStart
1-Jul-00 1-Sep-02 1-Sep-99 10-Oct-00 1-Nov-02

rentFinish
31-Aug-01 1-Sep-02 10-Jun-00 1-Dec-01 1-Aug-03

PropertyOwner
propertyNo
PG4 PG16 PG36

pAddress
6 lawrence St,Glasgow 5 Novar Dr, Glasgow 2 Manor Rd, Glasgow

rent
350 450 370

ownerNo
CO40 CO93 CO93

oName
Tina Murphy Tony Shaw Tony Shaw

Figure 6 2NF ClientRental relation

3NF ClientRental relation
The functional dependencies for the Client, Rental and PropertyOwner relations are as follows:
Client
fd2 clientNo  cName (Primary Key)

Rental
fd1 fd5 fd6 clientNo, propertyNo  rentStart, rentFinish clientNo, rentStart  propertyNo, rentFinish propertyNo, rentStart  clientNo, rentFinish (Primary Key) (Candidate key) (Candidate key)

PropertyOwner
fd3 fd4 propertyNo  pAddress, rent, ownerNo, oName (Primary Key) ownerNo  oName (Transitive Dependency)

3NF ClientRental relation
The resulting 3NF relations have the forms: Client (clientNo, cName) Rental (clientNo, propertyNo, rentStart, rentFinish) PropertyOwner (propertyNo, pAddress, rent, ownerNo) Owner (ownerNo, oName)

3NF ClientRental relation
Client
ClientNo
CR76 CR56

Rental
cName
John Kay Aline Stewart

ClientNo
CR76 CR76 CR56 CR56 CR56

propertyNo
PG4 PG16 PG4 PG36 PG16

rentStart
1-Jul-00 1-Sep-02 1-Sep-99 10-Oct-00 1-Nov-02

rentFinish
31-Aug-01 1-Sep-02 10-Jun-00 1-Dec-01 1-Aug-03

PropertyOwner
propertyNo
PG4 PG16 PG36

Owner
rent
350 450 370

pAddress
6 lawrence St,Glasgow 5 Novar Dr, Glasgow 2 Manor Rd, Glasgow

ownerNo
CO40 CO93 CO93

ownerNo
CO40 CO93

oName
Tina Murphy Tony Shaw

Figure 7 2NF ClientRental relation

Boyce-Codd Normal Form (BCNF)
Boyce-Codd normal form (BCNF) A relation is in BCNF, if and only if, every determinant is a candidate key. The difference between 3NF and BCNF is that for a functional dependency A  B, 3NF allows this dependency in a relation if B is a primary-key attribute and A is not a candidate key, whereas BCNF insists that for this dependency to remain in a relation, A must be a candidate key.

Boyce-Codd Normal Form (BCNF)(cont)
 To test whether a relation is in BCNF, we identify all the determinant is an attribute, or a group of attributes, on which some other attribute is fully functionally dependent.  Violation of BCNF is quite rare, since it may only happen under specific condition. The potential to violate BCNF may occur in a relation that:
 Contains two (or more) composite candidate keys;  The candidate keys overlap, that is have at least one attribute in common.

Example of BCNF
fd1 clientNo, propertyNo  rentStart, rentFinish fd2 clientNo, rentStart propertyNo, rentFinish fd3 propertyNo, rentStart  clientNo, rentFinish
3NF already BCNF
cName
John Kay Aline Stewart

(Primary Key) (Candidate key) (Candidate key)
3NF already BCNF

Client
ClientNo
CR76 CR56

Rental
ClientNo
CR76 CR76 CR56 CR56

propertyNo
PG4 PG16 PG4 PG36 PG16

rentStart
1-Jul-00 1-Sep-02 1-Sep-99 10-Oct-00 1-Nov-02

rentFinish
31-Aug-01 1-Sep-02 10-Jun-00 1-Dec-01 1-Aug-03

PropertyOwner
propertyNo
PG4 PG16 PG36

3NF already BCNF

CR56

Owner
rent
350 450 370

pAddress
6 lawrence St,Glasgow 5 Novar Dr, Glasgow 2 Manor Rd, Glasgow

ownerNo
CO40 CO93 CO93

ownerNo
CO40 CO93

oName
Tina Murphy Tony Shaw

3NF already BCNF

Example of BCNF
fd1 fd2 fd3 fd4 clientNo, interviewDate  interviewTime, staffNo, roomNo (Primary Key) staffNo, interviewDate, interviewTime clientNo, roomNo (Candidate key) roomNo, interviewDate, interviewTime  clientNo, staffNo (Candidate key) staffNo, interviewDate  roomNo (not a candidate key)

As a consequece the ClientInterview relation may suffer from update anomalies. For example, two tuples have to be updated if the roomNo need be changed for staffNo SG5 on the 13-May-02.

ClientInterview
ClientNo
CR76 CR56 CR74 CR56

interviewDate
13-May-02 13-May-02 13-May-02 1-Jul-02

interviewTime
10.30 12.00 12.00 10.30

staffNo
SG5 SG5 SG37 SG5

roomNo
G101 G101 G102 G102

Figure 8 ClientInterview relation

Example of BCNF
fd1 fd2 fd3 fd4 clientNo, interviewDate  interviewTime, staffNo, roomNo (Primary Key) staffNo, interviewDate, interviewTime clientNo, roomNo (Candidate key) roomNo, interviewDate, interviewTime  clientNo, staffNo (Candidate key) staffNo, interviewDate  roomNo (not a candidate key)

As a consequece the ClientInterview relation may suffer from update anomalies. For example, two tuples have to be updated if the roomNo need be changed for staffNo SG5 on the 13-May-02.

ClientInterview
ClientNo
CR76 CR56 CR74 CR56

interviewDate
13-May-02 13-May-02 13-May-02 1-Jul-02

interviewTime
10.30 12.00 12.00 10.30

staffNo
SG5 SG5 SG37 SG5

roomNo
G101 G101 G102 G102

Figure 8 ClientInterview relation

Example of BCNF(cont)
To transform the ClientInterview relation to BCNF, we must remove the violating functional dependency by creating two new relations called Interview and StaffRoom as shown below, Interview (clientNo, interviewDate, interviewTime, staffNo) StaffRoom(staffNo, interviewDate, roomNo)
Interview
ClientNo
CR76 CR76 CR74 CR56

interviewDate
13-May-02 13-May-02 13-May-02 1-Jul-02

interviewTime
10.30 12.00 12.00 10.30

staffNo
SG5 SG5 SG37 SG5

StaffRoom
staffNo
SG5 SG37 SG5

interviewDate
13-May-02 13-May-02 1-Jul-02

roomNo
G101 G102 G102

Figure 9 BCNF Interview and StaffRoom relations

Questions

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->