b. information technology (hons.) cmpb245: database design logical database design

B. Information Technology (Hons.)CMPB245:

Database Design

Logical Database Design

2

Objective

Build and Validate Local Logical Data Model

Build and Validate Local Logical Data Model

Objective 1

SecretarySecretarySecretarySecretary SupervisorSupervisorSupervisorSupervisor

StaffStaffStaffStaff BranchBranchBranchBranch

LeaseLeaseAgreementAgreement


PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent

AdvertAdvertAdvertAdvert NewspaperNewspaperNewspaperNewspaper

OwnerOwnerOwnerOwner

BusinessBusinessOwnerOwner


PrivatePrivateOwnerOwnerPrivatePrivateOwnerOwner

ClientClientClientClient

SupportsSupports SupervisesSupervises

HasHas

OrganizesOrganizes

ManagesManages

AssociatedAssociatedWithWith

DescribedDescribedInIn

OwnsOwns dd

OffersOffers

HoldsHolds

RentsRents

ViewsViews

ListsLists

dd

11 11

InterviewInterviewInterviewInterview SetsUpSetsUp

CarryOutCarryOut

InspectionInspectionInspectionInspection

UndergoesUndergoes

WithWith

1111

1111 111111

11

1111

11

11

MMMM

MM

MM

MMMM

MM

MMMM

MM

MM

NN

NN

MM

MM MM MM

1111

MM

LocalLocalConceptualConceptualData ModelData Model

5

Logical Data Model

The local conceptual model is refined to remove data structures that are difficult to implement using RDBMS

When that is done, the model is referred to as the Logical Data Model

6

Logical Data ModelThe Tasks Involved

2.1 Map logical conceptual data model to local logical data model

2.2 Derive relations from local logical data model

2.3 Validate model using normalization

2.4 Validate model against user transac-tion

2.5 Draw entity-relationship diagram

2.6 Define integrity constraints

2.7 Review local logical data model with user

7

2.1 Map LCD to LD Model

This step is required to– remove M:N relationships– remove complex relationships– remove recursive relationships– remove relationships with attributes– re-examine 1:1 relationships– remove redundant relationships

8

ViewsViewsViewsViewsClientClientClientClient

Client_NoClient_NoClient_NoClient_No


Property_NoProperty_NoProperty_NoProperty_No

MM NN

(1) Remove M:N relationship

From Fig. 11.1, we can see that Client Views Property_for_Rent has M:N cardinality ratio

Decompose M:N relations into 1:M relations by creating new (usually weak) entities

4444

9


Decompose the Views relation into two one-to-many (1:M) relationships (Attends and Takes)– A new entity Viewing is created

10

MM



ViewingViewingViewingViewing

AttendsAttendsAttendsAttends TakesTakesTakesTakes

MM



11 11


WeakWeakentityentityWeakWeakentityentity

WeakWeakrelationshiprelationship

WeakWeakrelationshiprelationship

11

(2) Remove complex relationships

A Complex relationship involves more than two entity types; ternary or quarter-nary

If there is such a case, decompose the relationship to 1:M (binary) relationships– No complex relationships are found in Fig. 10.8

4444

12

PropertyPropertyPropertyProperty

RenterRenterRenterRenter

StaffStaffStaffStaff LeasesLeasesLeasesLeases

Renter_NoRenter_NoRenter_NoRenter_No

Staff_NoStaff_NoStaff_NoStaff_No Property_NoProperty_NoProperty_NoProperty_No

MMMM

MM


For an example, consider a relation whereby a staff organizes the leasing of a property by a renter

13

HoldsHoldsHoldsHolds

OrganizesOrganizesOrganizesOrganizes AssociatedAssociatedWithWith



LeaseLeaseAgreementAgreement PropertyPropertyPropertyProperty


StaffStaffStaffStaff

Staff_NoStaff_NoStaff_NoStaff_No

RenterRenterRenterRenter Renter_NoRenter_NoRenter_NoRenter_No


The original relationship can be decomposed as follows:

14

(3) Remove recursive relationships

A Recursive relationship is one in which an entity has a relationship with itself

Remove it to 1:M relationships In Fig. 10.8, Supervisor Supervises Staff and

Secretary Supports Staff are examples of recursive relations

4444

15


These relationships are removed by creat-ing a weak entity called Allocated_Staff

See Fig. 11.2, pg. 330

16

dddd

SupervisorSupervisorSupervisorSupervisorSecretarySecretarySecretarySecretary



SupportsSupportsSupportsSupports

SupervisesSupervisesSupervisesSupervises

JoinsJoinsJoinsJoins

AllocatedAllocatedStaffStaff


11

11

11 11

MM

MM


17

Branch_NoBranch_NoBranch_NoBranch_NoStaff_NoStaff_NoStaff_NoStaff_No

StaffStaffStaffStaff BranchBranchBranchBranchWorksAtWorksAtWorksAtWorksAtMM NN

(4) Remove relationships with attributes

If a relationship has attributes associated with it, we should decompose it to iden-tify an entity

Consider the following relationship:

18


We wish to record the number of hours worked by temporary staff at each branch

The relationship Staff WorksAt Branch has an attribute called Hours_Worked

HoursHoursWorkedWorkedHoursHours

WorkedWorked Branch_NoBranch_NoBranch_NoBranch_NoStaff_NoStaff_NoStaff_NoStaff_No

StaffStaffStaffStaff BranchBranchBranchBranchWorksAtWorksAtWorksAtWorksAtMM NN

19

AssignedAssignedToTo

AssignedAssignedToTo

MM

11

MMRequiresRequiresRequiresRequires

11


We decompose the WorksAt relationship into an entity called Branch_Allocation

HoursHoursWorkedWorkedHoursHours

WorkedWorked

BranchBranchAllocationAllocation

BranchBranchAllocationAllocation

Branch_NoBranch_NoBranch_NoBranch_No

BranchBranchBranchBranch



20


In the Client Views Property_for_Rent re-lationship, we are supposed to store the Date_View and Comments about the clients

The Views relationship has already been decomposed from M:N relationship to produce the Viewing entity

444411111111

21

Date_ViewDate_ViewDate_ViewDate_View CommentsCommentsCommentsComments




11



11

MM ViewingViewingViewingViewing

AttendsAttendsAttendsAttends TakesTakesTakesTakes

MM

22

(5) Re-examine 1:1 relationships

In some cases, entities related through 1:1 relationship can be merged to form a common entity

In Fig. 11.2 a new entity Allocated Staff is in fact the same as Staff

Can we merge these entities? In this case, decide to leave as it is.

17171717

23

(6) Remove redundant relationships

A relationship is considered redundant if the same information can be obtained from other relationships

In Fig. 10.8, Client Rents Property_for_Rent is a redundant relationship

4444

24


The relationship is already represented through– Client Holds Lease_Agreement – Lease_Agreement Associated With Property_

for_Rent

A client cannot rent a property without first holding a lease agreement for the property

4444

25


Remove Client Rents Property_for_Rent from the data model

See Fig. 11.3, pg. 332

RentsRents

MM

NN

SecretarySecretarySecretarySecretary

SupervisorSupervisorSupervisorSupervisor

dd

JoinsJoins



SupportsSupports

SupervisesSupervises

11

11

11

MM

MM

11

TakesTakes

ViewingViewingViewingViewingAttendsAttends

MMMM

11

11












HasHas

OrganizesOrganizes

ManagesManages



OwnsOwns dd

OffersOffers

HoldsHolds

ListsLists


CarryOutCarryOut


UndergoesUndergoes

WithWith

11

11

1111

111111

11

1111

11

11

MM

MM

MMMM

MM

MMMM

MM

MM MM MM

1111

MM



dd

JoinsJoins



SupportsSupports


11

11

11

MM

MM

11

TakesTakes


MMMM

11

11












HasHas

OrganizesOrganizes

ManagesManages



OwnsOwns dd

OffersOffers

HoldsHolds

ListsLists


CarryOutCarryOut


UndergoesUndergoes

WithWith

11

11

1111

111111

11

1111

11

11

MM

MM

MMMM

MM

MMMM

MM

MM MM MM

1111

MM

28

2.1 Map LCD to LD Model

We have simplified the local conceptual data model by removing data structures that are difficult to implement in a rela-tional database– By doing so it is correct to say that we have

constructed a logical data model Why can we say so?

– Because this model can now be implemented in a database software package

29


To represent the entities and relationships described in the user’s view– This relation is represented as the primary

key/foreign key mechanism We have to identify the parent and child

entities of a relationship– The parent entity posts a copy of its primary key

into the child entity to establish the rela-tion

DegreeDegree

AttributesAttributes

BNoBNo StreetStreet AreaArea CityCity PostCodPostCodee

Tel_NoTel_No Fax_NoFax_No

B5B5

B7B7

B3B3

B4B4

22 Deer Rd22 Deer Rd

16 Argyll 16 Argyll St.St.163 Main 163 Main St.St.32 Manse 32 Manse Rd.Rd.

SidcuSidcuppDyceDyce

PatricPatrickkLeighLeigh

LondonLondon

AberdeAberdeenenGlasgoGlasgowwBristolBristol

SW1 SW1 4EH4EHAB2 3SUAB2 3SU

G11 G11 9QX9QXBS99 BS99 1NZ1NZ

0171-0171-8861212886121201224-01224-67125671250141-0141-339217833921780117-0117-91611709161170

0171-0171-8861214886121401244-01244-67111671110141-0141-339443933944390117-0117-77611147761114

SNoSNo FNamFNamee

LNamLNamee

AddressAddress Tel_NoTel_No SeSexx

BNoBNo

SL21SL21 JohnJohn WhiteWhite 19 Taylor St.,19 Taylor St.,Cranford, Cranford, LondonLondon

0171-884-0171-884-51125112

MM B5B5

SG3SG377

AnnAnn BeechBeech 81 George 81 George St.,St.,GlasgowGlasgow

0141-848-0141-848-33453345

FF B3B3

SG1SG144

DavidDavid FordFord 63 Ashby St.,63 Ashby St.,Patrick, Patrick, GlasgowGlasgow

0141-339-0141-339-21772177

MM B3B3Rela

tion

sR

ela

tion

sBRANCHBRANCH

TuplesTuples

Card

inality

Card

inality

Primary KeyPrimary Key Foreign KeyForeign KeySTAFFSTAFF

31


At this stage we describe the composition of each relation using the Database Definition Lan-guage (DDL) to:

– specify the name of the relation– list the attributes– identify primary/alternate keys and foreign keys

The relation containing the foreign key must also be defined

32


As an example consider the Client Attends Viewing and Property for Rent Takes Viewing

ClientClient (Client_No, FName, (Client_No, FName, LName, AddressLName, Address

Tel_No, Pref_Type, Max_Rent)Tel_No, Pref_Type, Max_Rent)Primary KeyPrimary Key Client_NoClient_No

22222222

The relations are as follows:

33


PropertyProperty (Property_No, Street, Area, City, (Property_No, Street, Area, City, Postcode,Postcode,for Rentfor Rent Type, Rooms, Rent)Type, Rooms, Rent)Primary KeyPrimary Key Property_NoProperty_No

ViewingViewing (Property_No, Client_No, (Property_No, Client_No, Date_View Date_View Comments)Comments)

PrimaryPrimary Key Key Property_No, Client_No, Property_No, Client_No, Date_ViewDate_ViewForeign KeyForeign Key Property_No, references Property_No, references Property_for_Rent Property_for_Rent (Property_No)(Property_No)Foreign KeyForeign Key Client_No references Client Client_No references Client (Client_No)(Client_No)

34


This process must be repeated for all the entities of the model

Document all relations and foreign keys– See Appendix 11.1, pg. 348

Update data dictionary to record all key attributes that are identified

35


In this step, we validate the composition of the relations derived from the previous step

This is done to ensure that the model is a closer representation of the enterprise model

Particular attention should be given to relations which are not in BCNF

36


Consider the functional dependencies of Client, Lease_Agreement and Property_for_Rent rela-tion

Client_NoClient_NoFNameFNameLNameLNameAddressAddressTel_NoTel_NoPref_TypePref_TypeMax_RentMax_Rent

28282828

Any non-keyAny non-keyattributes whichattributes which

depends ondepends onother non-keyother non-key

attributesattributes

Any repeatingAny repeatingattributes?attributes?


AnyAnydeterminantsdeterminantswhich are notwhich are not

candidatecandidatekeys?keys?

Any non-keyAny non-keyattributes whichattributes whichdepends on partdepends on part

of the key?of the key?

37




Consider the Property_for_Rent relations

Property_NoProperty_NoStreetStreetAreaAreaCityCityPostcodePostcodeTypeTypeRoomsRoomsRentRentOwner_NoOwner_NoManaged_By_Staff_NoManaged_By_Staff_NoBranch_NoBranch_No





Any determinantsAny determinantswhich are notwhich are not

candidate keys?candidate keys?

38


Consider the Lease_Agreement relations

Lease_NoLease_NoClient_NoClient_NoProperty_NoProperty_NoRentRentPayment_MethodPayment_MethodDeposit_PaidDeposit_PaidRent_StartRent_StartRent_FinishRent_Finish

Lease_NoLease_NoClient_NoClient_NoProperty_NoProperty_NoRentRentPayment_MethodPayment_MethodDeposit_PaidDeposit_PaidRent_StartRent_StartRent_FinishRent_Finish







Yes,Yes,Rent depends onRent depends on

Property_NoProperty_No

39


It is not necessary to remove the Rent attribute as it has been represented in the Property_for_Rent relation

Just remove it from the Lease_Agreement relation to normalize it to 3NF

The process of validation should be re-peated for all the relations

40

2.4 Validate model against user transactions

To ensure that the model supports the transactions required by the user view

Try manual transactions using the data model

Transactions can include:– insert new details– delete existing details

41


The second approach involves checking the database transactions– shown in Section 10.1.2, pg. 278, – against the data model of Fig. 11.4, pg. 336

The model does not provide the pathways for transactions (g) and (h)

42


Solve this problem by creating a relation Branch Registers Client

See Fig. 11.4, pg. 336

43


Turn back to Fig. 11.4, pg. 336 There are no transactions associated with

– Staff SetsUp Interview– Interview With Client– Staff Organizes Lease Agreement

44


Consult with users on these discrepancies and redraw data model

See Fig. 11.5 pg. 337

45

2.5 Draw ER diagram

Draw an ER diagram of the user’s view which has been validated using– normalization– transactions it must support

This diagram is a refinement of earlier dia-grams

See Fig. 11.5 pg. 337













ManagesManages



OwnsOwns dd

HoldsHolds

TakesTakes

ListsLists

dd

BranchBranchBranchBranch HasHas

CarryOutCarryOut


UndergoesUndergoes

RegistersRegisters

MM

11

1111

MM

1111

11

11

MM

MM

MM

MMMM

MM MM MM

1111

11

OffersOffers

MM

11


MMMM

11

11

JoinsJoins



SupportsSupports


11

11

11

MM

MM

11

Local LogicalLocal LogicalData ModelData Model

(Final)(Final)

47


These are controlled conditions imposed on the relations so that the database is al-ways consistent

At this stage we identify what constraints are required, not how to do it– This will then represent a complete and accu-rate

user view

48


Consider the following five types of cons-traints at this stage:– required data (e.g. Staff have Position)– attribute domain constraints (e.g. M or F)– entity integrity (NOT NULL)– referential integrity (parent-child relation)– enterprise constraints (the business rules)

49

Integrity ConstraintsOn Required Data

Identify the attributes that must contain a valid value at all times

Attributes like Staff_No, Property_No, Name cannot be blanks or nulls

But attributes like Tel_No does not always need to hold a value

See Appendix 11.2, pgs. 349 - 349

50

Integrity ConstraintsOn Attribute Domain

This defines a set of valid values that an attribute may hold– e.g. the set of values for Client_No attributes of

the Client entity is a 5-character variable string containing values ranging from CR1 to CR999

See Appendix 10.4, pg. 326

51

Integrity constraintsOn Entity Integrity

This means that the primary key must al-ways hold a value and not allowed to have blanks or nulls

Some DBMS will caution users if data for primary key is not entered


52

Integrity constraintsOn Referential Integrity

If the foreign key of a child relation con-tains a value, that value must refer to an existing valid data in the parent relation

Referential integrity must be established for all relations in the model


29292929

53

Integrity constraintsOn Enterprise Constraints

These are the rules of the enterprise that must be upheld within the model– e.g. a Supervisor should supervise a min. of 5

and a max. of 10 members of staff– See Appendix 8.6, pg. 320

All integrity constraints must be documen-ted

54

2.7 Review local logical data model with user

To complete this stage, review with the user– the data model– any supporting documentation

It is critical that the model is a ‘true’ rep-resentation of the ‘real world’ as viewed by the Supervisor

b. information technology (hons.) cmpb245: database design logical database design

Documents

worksat relationship

following relationship

local logical data model2

local logical data modelbuild

clientsthe views relationship

data structures

worked4remove relationships

n relationshipdecompose