B. Information Technology (Hons.) CMPB245: Database Design Logical Database Design
Jan 02, 2016
SecretarySecretarySecretarySecretary SupervisorSupervisorSupervisorSupervisor
StaffStaffStaffStaff BranchBranchBranchBranch
LeaseLeaseAgreementAgreement
LeaseLeaseAgreementAgreement
PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent
AdvertAdvertAdvertAdvert NewspaperNewspaperNewspaperNewspaper
OwnerOwnerOwnerOwner
BusinessBusinessOwnerOwner
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
PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent
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
(1) Remove M:N relationship
Decompose the Views relation into two one-to-many (1:M) relationships (Attends and Takes)– A new entity Viewing is created
10
MM
PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent
Property_NoProperty_NoProperty_NoProperty_No
ViewingViewingViewingViewing
AttendsAttendsAttendsAttends TakesTakesTakesTakes
MM
Client_NoClient_NoClient_NoClient_No
ClientClientClientClient
11 11
(1) Remove M:N relationship
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
(2) Remove complex relationships
For an example, consider a relation whereby a staff organizes the leasing of a property by a renter
13
HoldsHoldsHoldsHolds
OrganizesOrganizesOrganizesOrganizes AssociatedAssociatedWithWith
AssociatedAssociatedWithWith
LeaseLeaseAgreementAgreement
LeaseLeaseAgreementAgreement PropertyPropertyPropertyProperty
Property_NoProperty_NoProperty_NoProperty_No
StaffStaffStaffStaff
Staff_NoStaff_NoStaff_NoStaff_No
RenterRenterRenterRenter Renter_NoRenter_NoRenter_NoRenter_No
(2) Remove complex relationships
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
(3) Remove recursive relationships
These relationships are removed by creat-ing a weak entity called Allocated_Staff
See Fig. 11.2, pg. 330
16
dddd
SupervisorSupervisorSupervisorSupervisorSecretarySecretarySecretarySecretary
Staff_NoStaff_NoStaff_NoStaff_No
StaffStaffStaffStaff
SupportsSupportsSupportsSupports
SupervisesSupervisesSupervisesSupervises
JoinsJoinsJoinsJoins
AllocatedAllocatedStaffStaff
AllocatedAllocatedStaffStaff
11
11
11 11
MM
MM
(3) Remove recursive relationships
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
(4) Remove relationships with attributes
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
(4) Remove relationships with attributes
We decompose the WorksAt relationship into an entity called Branch_Allocation
HoursHoursWorkedWorkedHoursHours
WorkedWorked
BranchBranchAllocationAllocation
BranchBranchAllocationAllocation
Branch_NoBranch_NoBranch_NoBranch_No
BranchBranchBranchBranch
Staff_NoStaff_NoStaff_NoStaff_No
StaffStaffStaffStaff
20
(4) Remove relationships with attributes
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
(4) Remove relationships with attributes
Client_NoClient_NoClient_NoClient_No
ClientClientClientClient
11
PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent
Property_NoProperty_NoProperty_NoProperty_No
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
(6) Remove redundant relationships
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
(6) Remove redundant relationships
Remove Client Rents Property_for_Rent from the data model
See Fig. 11.3, pg. 332
RentsRents
MM
NN
SecretarySecretarySecretarySecretary
SupervisorSupervisorSupervisorSupervisor
dd
JoinsJoins
AllocatedAllocatedStaffStaff
AllocatedAllocatedStaffStaff
SupportsSupports
SupervisesSupervises
11
11
11
MM
MM
11
TakesTakes
ViewingViewingViewingViewingAttendsAttends
MMMM
11
11
StaffStaffStaffStaff
BranchBranchBranchBranch
LeaseLeaseAgreementAgreement
LeaseLeaseAgreementAgreement
PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent
AdvertAdvertAdvertAdvert NewspaperNewspaperNewspaperNewspaper
OwnerOwnerOwnerOwner
BusinessBusinessOwnerOwner
BusinessBusinessOwnerOwner
PrivatePrivateOwnerOwnerPrivatePrivateOwnerOwner
ClientClientClientClient
HasHas
OrganizesOrganizes
ManagesManages
AssociatedAssociatedWithWith
DescribedDescribedInIn
OwnsOwns dd
OffersOffers
HoldsHolds
ListsLists
InterviewInterviewInterviewInterview SetsUpSetsUp
CarryOutCarryOut
InspectionInspectionInspectionInspection
UndergoesUndergoes
WithWith
11
11
1111
111111
11
1111
11
11
MM
MM
MMMM
MM
MMMM
MM
MM MM MM
1111
MM
SecretarySecretarySecretarySecretary
SupervisorSupervisorSupervisorSupervisor
dd
JoinsJoins
AllocatedAllocatedStaffStaff
AllocatedAllocatedStaffStaff
SupportsSupports
SupervisesSupervises
11
11
11
MM
MM
11
TakesTakes
ViewingViewingViewingViewingAttendsAttends
MMMM
11
11
StaffStaffStaffStaff
BranchBranchBranchBranch
LeaseLeaseAgreementAgreement
LeaseLeaseAgreementAgreement
PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent
AdvertAdvertAdvertAdvert NewspaperNewspaperNewspaperNewspaper
OwnerOwnerOwnerOwner
BusinessBusinessOwnerOwner
BusinessBusinessOwnerOwner
PrivatePrivateOwnerOwnerPrivatePrivateOwnerOwner
ClientClientClientClient
HasHas
OrganizesOrganizes
ManagesManages
AssociatedAssociatedWithWith
DescribedDescribedInIn
OwnsOwns dd
OffersOffers
HoldsHolds
ListsLists
InterviewInterviewInterviewInterview SetsUpSetsUp
CarryOutCarryOut
InspectionInspectionInspectionInspection
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
2.2 Derive relations from local logical data model
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
2.2 Derive relations from local logical data model
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
2.2 Derive relations from local logical data model
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
2.2 Derive relations from local logical data model
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
2.2 Derive relations from local logical data model
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
2.3 Validate model using normalization
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
2.3 Validate model using normalization
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?
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
Any non-keyAny non-keyattributes whichattributes whichdepends on partdepends on part
of the key?of the key?
2.3 Validate model using normalization
Consider the Property_for_Rent relations
Property_NoProperty_NoStreetStreetAreaAreaCityCityPostcodePostcodeTypeTypeRoomsRoomsRentRentOwner_NoOwner_NoManaged_By_Staff_NoManaged_By_Staff_NoBranch_NoBranch_No
Any non-keyAny non-keyattributes whichattributes which
depends ondepends onother non-keyother non-key
attributesattributes
Any repeatingAny repeatingattributes?attributes?
Any determinantsAny determinantswhich are notwhich are not
candidate keys?candidate keys?
38
2.3 Validate model using normalization
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
Any non-keyAny non-keyattributes whichattributes whichdepends on partdepends on part
of the key?of the key?
Any non-keyAny non-keyattributes whichattributes which
depends ondepends onother non-keyother non-key
attributesattributes
Any repeatingAny repeatingattributes?attributes?
Yes,Yes,Rent depends onRent depends on
Property_NoProperty_No
39
2.3 Validate model using normalization
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
2.4 Validate model against user transactions
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
2.4 Validate model against user transactions
Solve this problem by creating a relation Branch Registers Client
See Fig. 11.4, pg. 336
43
2.4 Validate model against user transactions
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
2.4 Validate model against user transactions
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
SecretarySecretarySecretarySecretary
SupervisorSupervisorSupervisorSupervisor
StaffStaffStaffStaff
LeaseLeaseAgreementAgreement
LeaseLeaseAgreementAgreement
PropertyPropertyfor Rentfor RentPropertyPropertyfor Rentfor Rent
AdvertAdvertAdvertAdvert NewspaperNewspaperNewspaperNewspaper
OwnerOwnerOwnerOwner
BusinessBusinessOwnerOwner
BusinessBusinessOwnerOwner
PrivatePrivateOwnerOwnerPrivatePrivateOwnerOwner
ClientClientClientClient
ManagesManages
AssociatedAssociatedWithWith
DescribedDescribedInIn
OwnsOwns dd
HoldsHolds
TakesTakes
ListsLists
dd
BranchBranchBranchBranch HasHas
CarryOutCarryOut
InspectionInspectionInspectionInspection
UndergoesUndergoes
RegistersRegisters
MM
11
1111
MM
1111
11
11
MM
MM
MM
MMMM
MM MM MM
1111
11
OffersOffers
MM
11
ViewingViewingViewingViewingAttendsAttends
MMMM
11
11
JoinsJoins
AllocatedAllocatedStaffStaff
AllocatedAllocatedStaffStaff
SupportsSupports
SupervisesSupervises
11
11
11
MM
MM
11
Local LogicalLocal LogicalData ModelData Model
(Final)(Final)
47
2.6 Define integrity constraints
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
2.6 Define integrity constraints
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
See Appendix 11.1, pg. 348
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
See Appendix 11.1, pg. 348
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