2. B. Information Technology (Hons.) CMPB245: Database Design Logical Database Design

3. 2 Objective Build and Validate Local Logical Data Model

4. Objective 1

5. LocalConceptual Data Model

6. 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

7. 6 Logical Data Model The Tasks Involved 2.1Map logical conceptual data model to local logical data model 2.2Derive relations from local logical data model 2.3Validate model using normalization 2.4Validate model against user transac-tion 2.5Draw entity-relationship diagram 2.6Define integrity constraints 2.7Review local logical data model with user

8. 7 2.1Map 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

9. 8 Views Client Client_No Property for Rent Property_No MN (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

10. 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

11. 10 M Property for Rent Property_No Viewing AttendsTakes M Client_No Client 11 (1)Remove M:N relationship Weakentity Weakrelationship

12. 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

13. 12 Property Renter Staff Leases Renter_No Staff_NoProperty_No M M M (2)Remove complex relationships For an example, consider a relation whereby a staff organizes the leasing of a property by a renter

14. 13 Holds OrganizesAssociatedWith LeaseAgreement Property Property_No Staff Staff_No Renter Renter_No (2)Remove complex relationships The original relationship can be decomposed as follows:

15. 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

16. 15 (3)Remove recursive relationships These relationships are removed by creat-ing a weak entity called Allocated_Staff See Fig. 11.2, pg. 330

17. 16 d Supervisor Secretary Staff_No Staff Supports Supervises Joins AllocatedStaff 1 1 1 1 M M (3)Remove recursive relationships

18. 17 Branch_NoStaff_No StaffBranch WorksAt MN (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:

19. 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 HoursWorked Branch_NoStaff_No StaffBranch WorksAt MN

20. 19 AssignedTo M 1 M Requires 1 (4)Remove relationships with attributes We decompose the WorksAt relationship into an entity called Branch_Allocation HoursWorked BranchAllocation Branch_No Branch Staff_No Staff

21. 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 4444 11

22. 21 Date_ViewComments (4)Remove relationships with attributes Client_No Client 1 Property for Rent Property_No 1 M Viewing AttendsTakes M

23. 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. 17

24. 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

25. 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

26. 25 (6)Remove redundant relationships Remove Client Rents Property_for_Rent from the data model See Fig. 11.3, pg. 332

27. Rents MN

29. 28 2.1Map 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

30. 29 2.2Derive 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

31. Degree Attributes BNoStreetAreaCityPostCodeTel_NoFax_No B5 B7 B3 B4 22 Deer Rd 16 Argyll St. 163 Main St. 32 Manse Rd. Sidcup Dyce Patrick Leigh London Aberdee n Glasgow Bristol SW1 4EH AB2 3SU G11 9QX BS99 1NZ 0171-8861212 01224-67125 0141-3392178 0117-9161170 0171-8861214 01244-67111 0141-3394439 0117-7761114 SNoFNameLNameAddressTel_NoSexBNo SL21JohnWhite 19 Taylor St., Cranford, London 0171-884-5112MB5 SG37AnnBeech 81 George St., Glasgow0141-848-3345FB3 SG14DavidFord 63 Ashby St., Patrick, Glasgow 0141-339-2177MB3 Relations BRANCH Tuples Cardinality Primary Key Foreign Key STAFF

32. 31 2.2Derive 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

33. 32 2.2Derive relations from local logical data model As an example consider the Client Attends Viewing and Property for Rent Takes Viewing Client(Client_No, FName, LName, Address Tel_No, Pref_Type, Max_Rent) Primary KeyClient_No 22 The relations are as follows:

34. 33 2.2Derive relations from local logical data model Property(Property_No, Street, Area, City, Postcode, for Rent Type, Rooms, Rent) Primary KeyProperty_No Viewing(Property_No, Client_No, Date_View Comments) Primary KeyProperty_No, Client_No, Date_View Foreign KeyProperty_No, references Property_for_Rent (Property_No) Foreign KeyClient_No references Client (Client_No)

35. 34 2.2Derive 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

36. 35 2.3Validate 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

37. 36 2.3Validate model using normalization Consider the functional dependencies of Client, Lease_Agreement and Property_for_Rent rela-tion Client_NoFNameLNameAddressTel_NoPref_TypeMax_Rent 28 Any non-key attributes which depends on other non-key attributes Any repeating attributes? Anydeterminants which are not candidatekeys? Any non-key attributes which depends on part of the key?

38. 37 Any non-key attributes which depends on part of the key? 2.3Validate model using normalization Consider the Property_for_Rent relations Property_NoStreetAreaCityPostcodeTypeRoomsRentOwner_NoManaged_By_Staff_NoBranch_No Any non-key attributes which depends on other non-key attributes Any repeating attributes? Any determinants which are not candidate keys?

39. 38 2.3Validate model using normalization Consider the Lease_Agreement relations Lease_NoClient_NoProperty_NoRentPayment_MethodDeposit_PaidRent_StartRent_Finish Any non-key attributes which depends on part of the key? Any non-key attributes which depends on other non-key attributes Any repeating attributes? Yes, Rent depends on Property_No

40. 39 2.3Validate 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

41. 40 2.4Validate 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

42. 41 2.4Validate 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)

43. 42 2.4Validate model against user transactions Solve this problem by creating a relation Branch Registers Client See Fig. 11.4, pg. 336

44. 43 2.4Validate 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

45. 44 2.4Validate model against user transactions Consult with users on these discrepancies and redraw data model See Fig. 11.5 pg. 337

46. 45 2.5Draw 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

47. Secretary Supervisor Staff LeaseAgreement Property for Rent AdvertNewspaper Owner BusinessOwnerPrivateOwner Client Manages AssociatedWith DescribedIn Owns d Holds Takes Lists d Branch Has CarryOut Inspection Undergoes Registers M 1 1 1 M 1 1 1 1 M M M M M MM M 1 1 1 Offers M 1 Viewing Attends M M 1 1 Joins AllocatedStaff Supports Supervises 1 1 1 M M 1 Local Logical Data Model (Final)

48. 47 2.6Define 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

49. 48 2.6Define 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)

50. 49 Integrity Constraints On 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

51. 50 Integrity Constraints On 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

52. 51 Integrity constraints On 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

53. 52 Integrity constraints On 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 29

54. 53 Integrity constraints On 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

55. 54 2.7Review 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