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

2 Objective Build and Validate Local Logical Data Model

Objective 1

LocalConceptual Data 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 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

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

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

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 M Property for Rent Property_No Viewing AttendsTakes M Client_No Client 11 (1)Remove M:N relationship Weakentity Weakrelationship

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

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

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:

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 d Supervisor Secretary Staff_No Staff Supports Supervises Joins AllocatedStaff M M (3)Remove recursive relationships

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:

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

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

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

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

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

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

Rents MN

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

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

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 SNoFNameLNameAddressTel_NoSexBNo SL21JohnWhite 19 Taylor St., Cranford, London MB5 SG37AnnBeech 81 George St., Glasgow FB3 SG14DavidFord 63 Ashby St., Patrick, Glasgow MB3 Relations BRANCH Tuples Cardinality Primary Key Foreign Key STAFF

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

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:

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)

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

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

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?

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?

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

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

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

41 2.4Validate model against user transactions The second approach involves checking the database transactions – shown in Section , 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.4Validate model against user transactions Solve this problem by creating a relation Branch Registers Client See Fig. 11.4, pg. 336

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

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

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 pg. 337

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 M M M M M M MM M Offers M 1 Viewing Attends M M 1 1 Joins AllocatedStaff Supports Supervises M M 1 Local Logical Data Model (Final)

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

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)

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

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

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

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

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

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