Coit20247 : Database Design And Assessment Answers

1). Normalization

a). Map the ERD, from the sample solution, into a set of relations in at least Third Normal Form (3NF). You must ensurethat your relations meet 3NF. There is no need to show your

b). Select any two (2) of your relations from the previous step, 1a), and perform the following for each ofthose two relations:

List all the functional dependencies exist in the

Demonstrate that the relation meets Third Normal Form (3NF).

For your help, an example for a Student relation’s 3NF justification has been provided below:

STUDENT (StudentID, Name, Address, DateOfBirth)

1). The primary key is StudentID which identifies a student. There will be one student name per Student ID because only one nameis recorded for each student. Even though a student may have multiple addresses (e.g. a home address and a work address), the case study states that there is a need to record the home address only and hence there will be only one address for each student. There will be only one date of birth for each student. Thus, there are no repeating groups. Hence, this relation is in 1NF.

2). The primary key is StudentID. This is the only candidate key since Name is not guaranteedto be unique (two different students may have the same name). Address is also not guaranteed to be unique. This means that Student ID functionally determines every other attribute in the table. There is a single valued simple candidate key (StudentId) and therefore no partial dependencies are possible. Hence, the relation is in 2NF.

 3). Name cannot be used tofunctionally determine any other attribute in the table since two different students may have the same name; likewise for address and date of birth. Therefore there are no transitive dependencies in the table. Therefore it meets the requirements of first, second and third normal 

2Relational databaseimplementation

Note: Use the relations that you created in the above step 1-Normalization to create a database. The recommended tool for this work is Microsoft Access, version 2010 or later. One reason for recommending Microsoft Access is that your unit lecturer/tutor will be able to provide adequate support to you in the use of this tool. If you choose to use a different DBMS, then there is no guarantee that your lecturer/tutor will be able to provide enough support to you. The remainder of this document assumes that you are using MS-Access.

In implementing the ER model provided, you must complete the following tasks:

• Create all the relations in a Microsoft Access database. Consider each attribute in every tableand make appropriate choices regarding data types & sizes, indexes, required/not requiredandvalidation rules. Your choices should be appropriate for each attribute and should support data integrity. (Note: see the Data Integrity section below for specific data integrity requirements)
• Create relationships as appropriate. Enforce referential integrity for all appropriaterelationships in the database. Apply cascade update and/or deleteoptions wherever necessary.
• Review the default index created by Access for each table. You should ensure that theindexes follow the guidelines given in the unit 
• Populate the database with sample data of your own. You must include sufficient sample data to testyour queries and report. Please note that the expected result of query questions may depend on the actual sample data 

Answer:

1 Normalization

a) Set of 3NF relations

CLAIM (claimID, lodgedDate, status, policyID) Foreign key (policyID) references POLICY (PolicyID)

CLAIM_ITEMS (itemID, quantity, status,claimID) Foreign Key (claimID) references CLAIM (claimID)

SETTLED_CLAIM (claimID, settledDate, amountSettled) Foreign Key (claimID) references CLAIM (claimID)

REJECTED_CLAIM (claimID, rejectedDate, rejectedReason) Foreign Key (claimID) references CLAIM (claimID)

POLICY (policyID, effectiveFromDate, paidDate, isHomBuilding, isContentPolicy, TotalPolicy, propertyID) Foreign key (propertyID) References PROPERTY (propertyID)

HOME_BUILDING (HBpolicyID, houseType, yearBuilt, isAlarmFitted, windowLocks, insuredAmount, buildingPremiumAmount) Foreign key (HBPolicyID) references POLICY (PolicyID)

HOME_CONTENT (HCpolicyID, contentPremiumAmount) Foreign key (HCPolicyID) references POLICY (PolicyID)

CONTENT_ITEM (itemID, name, manufacturer, model, purchasePrice, quantity, claimedStatus, HCpolicyID) Foreign key (HCpolicyID) References HOME_CONTENT (HCPolicyID)

PERSON (personID, personName, street, city, postcode, personType)

PROPERTY (propertyID, street, city, postcode, personID) Foreign key (PersonID) References PERSON (PersonID)

ASSESSMENT (reportID, reportDate, initilaRecommendation, reportType, claimID, assessorID) Foreign key (assessorID) references ASSESSOR (assessorID)

FINALASSESSMENT (reportID, assessmentDate, reportType) Foreign key (reportID) References ASSESSMENT (reportID)

ASSESSOR (assesorID, name, street, city, postcode)

ASSESSORQUALIFICATIONS (assessorID, qualificationName, dateQualified) Foreign key (assessorID) references ASSESSOR (assessorID)

b). Functional dependencies

• Claim(claimID, lodgedDate, status, policyID)

(claimID)à (lodgedDate, status, policyID )

This means claimID determines all lodgedDate, status and policyID as shown below;

ClaimIDàlodgedDate

claimIDàstatus

claimIDàpolicyID

• Person(personID, personName, street, city, postcode, personType)

(personID)à (personName, street, city, postcode, personType)

This means that personID determines personName, street, city, postcode and personType

personIDàpersonName

personIDàstreet

personIDàcity

personIDàpostcode

personIDàpersonType

Demonstration of 3NF

• Claim

Claim (claimID, lodgedDate, status, policyID)

1. The relation is in 1NF because it has a primary key which identifies every claim. Every claim has one lodgedDate, one status and belongs to only one policy thus there are no repeating groups.
2. The relation is 2NF because there is only candidate key which is claimID. All the other attributes are dependent on the claimID because the lodgedDate can be the same for two different claims, the status can be the same and a policy can have more than one claim thus this attributes cannot be guaranteed to be unique for a claim that is why the claimID is the only candidate key.

• The relation is in 3NF because claimID determines all the other attributes in the relation. THe lodgedDate cannot be used to determine the status and policyID because it is not unique thus claimID is the key attribute meaning there are no transitive dependencies present in the relation.
• Person

person (personID, personName, street, city, postcode, personType)

1. THe relation is in 1NF because there are no repeating groups in the relation. The personID is the primary key and a person has only one name, street, city, postcode and is of only one type thus no attribute has repeating data.
2. The relation is in 2NF because there are no partial dependencies in the relation. There is only one candidate key in the relaton which is the personID. All the attributes depend on the personID since the two people ca have the same name, same address and can be of the same type thus this cannot be guaranteed to be unique for every person.

• The relation is in 3NF because there are no transitive dependencies in the relation. THe key attribute is personID and determines all the other attributes. A personName cannot be used to determine the address nor can the address determine the name because these attributes are not unique for every person thus only the claimID can determine all the attributes.

The implementation of the database using Microsoft Access was very informative and challenging at the same time. I learnt a lot of things while implementing the database but the most two noticeable two lessons are;

• Enforcing referential integrity in a database and how it is important on ensuring data consistency. While creating the relationships between different tables, I realized that enforcing data integrity either for deleting or updating of records ensures that the transaction is done for both the child table and the parent table depending on what was specified during the creation of the relationship between the two tables.
• Using access to create a report from a query. By writing a query using SQL Access Query Builder I learnt that generating a report is very easy and can be done from any type of query. After generating the report from a query the next step is to design it depending on the fields making up the report.

While undertaking the task I found some tasks easy to solve while other parts of the task were difficult to implement. One of the most difficult part for me was writing complex queries using Access Query Builder. However, by doing research I was able to write highly efficient queries that produced the desired results.