BSC (HONS) IN BUSINESS INFORMATION SYSTEMS

BSC (& HONS) IN COMPUTING

UNIVERSITY OF PORTSMOUTH

DATABASE DESIGN & MANAGEMENT (IT354)

TERM 2, 2016

ASSIGNMENT

INSTRUCTIONS

Answer ALL questions.

Marks will be awarded for good presentation and thoroughness in your approach.

NO marks will be awarded for the entire assignment if any part of it is found to be copied
directly from printed materials or from another student. If any part of this assignment is
found to be copied from any sources without the correct citations, marks may be deducted,
and in cases of extensive plagiarism, the assignment may have all the marks withheld
pending a plagiarism hearing.

Complete this cover sheet and attach it to your assignment.

IGC coursework checklist Tick when included

MS word or RTF document (not PDF)
Front cover attached
Student number on every page
Student number included in title
Plagiarism check done in Turnitin
Turnitin Score %
Score discussed with facilitator (if over 20%)
[email protected],
https://turnitin.com/dv?s=1&o=68938
2849&u=1050187288&student_user=
Turnitin ID + URL (paste here) 1&lang=en_us&

013600001084 1
References:-
Quotes are referenced
Reference list provided
Has an ECF been submitted for any reason

Student Declaration:

I declare
that:
I understand what is meant by plagiarism.
The implications of plagiarism have been explained to me by my
institution.
This assignment is all my own work and I have acknowledged any use
of the published or unpublished works of other people.
In submitting this form and assignment I state that all work carried
out is my own, in content, words and ideas, unless otherwise shown
using correct citations and quotation marks. In checking the boxes
above, I declare that these items have been checked and are correct.

Student's signature: Date:

NABEEL ASGHAR 16th July 2016
. ..

Total number of pages including this cover page.

Submission 16th July 2016 16th July 2016

Due Date
Date

Student's ID 013600001084 Class Code IT354

Student's NABEEL ASGHAR

Full Name

Lecturer's Dr. N. Krishnamoorthy

Name

013600001084 2
Table of Contents

Question1 Designing Relational Database using Top-Down Method..................................................... 4

Question2 Translation of EERD into Relational Schema (Anon., n.d.) .................................................. 7

Question 3. Data Dictionary ...................................................................................................................... 9

Question 4. Bottom up Method of Relational Database Design ............................................................ 11

Question 5. De-Normalization.................................................................................................................. 13

References .................................................................................................................................................. 15

013600001084 3
Question1 Designing Relational Database using Top-Down Method

i) Entity with primary key and attributes

Services-S_ID (Primary Key), S_Type

Accommodation-Acc_No (Primary Key), ACC_Type, ACCName, Location, #bedrooms,

Contact#

Resident-R_ID (Primary Key), ACC_No, R_Name, DOB, Gender, Email, Contact#

Guardian G_ID, Name, Address, Contact#

Employees-E_ID (Primary Key), E_Name, Address, DOJ, Salary, Email, Contact#

FoodMenu-FM_No (Primary Key), FM_Type, Day, Timings, Item

Clinic-C_Name, Location, Contact#

Doctor- D_ID (Primary Key), D_Name, Address, Specialty, Contact#

Checkup-C_ID (Primary Key), R_ID, D_ID, C_Date, C_next, Treatment

Events- E_No (Primary Key), E_Name, E_Artist, E_Date, E_Time

ii)

Super Type Entities

Services

Sub type Entities

Kitchen, Medical, Entertainment, Cleaning

iii)

Weak Entity-CheckUp

Entity Checkup depends upon the Doctor Entity as it cannot identify all the attributes by itself.

iv)
Accommodation-Has many multi-valued attributes
Acctype (type of accommodation flat or villa)
#bedrooms (1BHk, 2BHk)
Contact# (Landline, mobile)

013600001084 4
v) Relationship with Cardinality 1:1

Each resident has a Guardian

vi) Relationship with Cardinality 1: M

GWS has Employees

Kitchen Has FoodMenu

Clinic has Doctor

vii) Relationship with Cardinality N: M

viii) Ternary Relationship-Not Available

ix)EERD

013600001084 5
 GRAND WORLD SERVICE

Location #bedrooms DOB

ACCName ACC_No
R_Name

Multivalued Contact#
ACC_Type Gender
Attribute R_ID

Accommodation Has Resident Email

DOJ ACC_No
Address

Salary Has Contact#

Has
E_Name Visits
Email
G_Name
GWS Guardian
E_ID Employees
Has

Address
Contact# Provides S_ID G_ID
Multivalued
Attribute Multivalued Contact#
Super Entity S_Type
Services Attribute
Sub Entity
Kitchen
Cleaning Cleans
Sub Entity Medical
Entertainment
Has

Has Conduct Events

FM_No s
FM_Type

C_Name E_time
Weak Entity
Clinic
FoodMenu Item Has

Location R_ID E_No E_Date

Contact#
Timing

Day D_ID E_Name

Address Doctor Performs CheckUp
E_Artist
C_ID
D_ID 013600001084
D_Name Contact# Specialty C_Date C_next Treatment 6
Question2 Translation of EERD into Relational Schema (Anon., n.d.)

i)Translation of Real World Entity

Accommodation
ACC_No ACC_Type ACCName Location #Bedrooms Contact#

Resident
R_ID Acc_No R_Name R_FirstName R_lastname DOB Gender Email Contact#

Guardian
G_ID R_ID Name Address Contact#

Employees
E_ID E_Name E_Firstname E_Lastname Address DOJ Salary Email Contact#

FoodMenu
FM_No FM_Type Day Timing Item

Clinic
C_Name Location Contact#

Doctor
D_ID D_Name D_FirstName D_Lastname Address Specialty Contact#

CheckUp
C_ID R_ID D_ID C_date C_next Treatment

Events
E_No E_Name E_Artist E_Date E_Time

After Translation

Accommodation
ACC_No ACC_Type ACCName Location #Bedrooms Contact#

ResidentDetails
R_ID Acc_No R_Name DOB Gender Email Contact# Name Address GContact#

013600001084 7
 ii) Translation of the Weak Entity
Weak Entity always depend on the strong entity. Primary key formed is a composite
key combining 1 attribute of weak-entity and primary-key of strong entity.

Doctor-D_ID, D_Name, Address, Specialty, Contact# Primary key: D_ID

CheckUp-C_ID, D_ID, R_ID, C_date, C_next, Treatment Primary key: C_ID,
D_ID

iii) Translation of 1:1 Relationship

1:1 Cardinality relationship between two entities, the translation will form foreign key
which is primary key of the other relation
Resident and Guardian have Cardinality 1:1
Resident: R_ID, G_ID, ACC_No, R_Name, DOB, Gender, Email, Contact#
Primary Key-R_ID Foreign Key-G_ID
Guardian: G_ID, Name, Address, Contact# Primary Key-G_ID

iv) Translation of 1:M Relationship

Clinic has Doctor
Before
Clinic- C_ID, C_Name, Location, Contact#
Doctor-D_ID, D_Name, Address, Specialty, Contact# Primary key: D_ID

After
Clinic- C_ID, C_Name, Location, Contact#
Doctor-D_ID, C_ID, D_Name, Address, Specialty, Contact# Primary key: D_ID

v) Translation of N:M Relationship

Accommodation has Residents

Accommodation-ACC_No, ACC_Type, ACCName, Location, #Bedrooms, Contact#

013600001084 8
 Residents- R_ID, G_ID, ACC_No, R_Name, DOB, Gender, Email, Contact#
After Translation
Guardian: Record_No, G_ID, ACC_No Name, Address, Contact#

vi) Translation of Multivalued Attributes

Employees, Accommodation, Resident, Doctor all the entities have Contact# that is
formed by multiple values like Mobile, Office, Resident or landline no.
Before
C_ID, C_Name, Location, Mobile, Office, landline
After
Clinic- C_ID, C_Name, Location, Contact#

vii) Translation of Ternary Relationship

No Entities have Ternary relationship.
viii) Translation of Super/Sub type Entities
Kitchen
Medical
Entertainment
Cleaning
All the sub type entities mentioned above were grouped together to form the super
entity Services.

Question 3. Data Dictionary

Relation Attributes DataType size Primary-Key Foreign-key

Employees E_ID smallint 5 E_ID

E_Name varchar 200
Address varchar 200
DOJ(date of date
Joining)
Salary decimal 4,2
Email varchar 200
Contact# smallint 10

013600001084 9
Relation Attributes DataType size Primary-Key Foreign-key

Accommodation ACC_No smallint 5 ACC_No

ACC_Type varchar 200
ACCName varchar 200
Location varchar 200
#bedrooms varchar 200
Contact# smallint 10

Relation Attributes DataType size Primary-Key Foreign-key

Resident R_ID smallint 5 R_ID

ACC_No ACC_No(Accommodation)
R_Name varchar 200
DOB(date date
of birth)
Gender varchar 10
Email varchar 200
Contact# smallint 10
G_ID smallint 5
G_Name varchar 200
G_Contact# smallint 10

Relation Attributes DataType size Primary-Key Foreign-key

FoodMenu FM_No smallint 5 FM_No

FM_Type varchar 200
Day varchar 200
Timing varchar 200
Item varchar 200

Relation Attributes DataType size Primary-Key Foreign-key

Doctor D_ID smallint 5 D_ID

D_Name varchar 200
Speciality varchar 200
Address varchar 200
Contact# smallint 10

013600001084 10
Relation Attributes DataType size Primary-Key Foreign-key

Event E_No smallint 5 E_No

E_Name varchar 200
E_Artist varchar 200
E_Date varchar 200
E_time varchar 200
Email varchar 200
Contact# smallint 10

Question 4. Bottom up Method of Relational Database Design

a) Un-normalized relation for the Car Parking System Scenario

b) Primary key: Cust_ID, Parking_ID, Card_ID

c) Functional Dependencies:
For the given X, Y attributes in a relation X if only one of the values of Y correspond to
X then Y is said to be functionally dependent upon X. (Anon., 2012)
X->Y
Functional dependency can also be based upon a composite attribute.
X, Z->Y
Cust_ID-> {Cust_Name, Cust_Address, Cust_ContactNo}
Customer name, address and contact no is dependent upon the customer ID.

ParkingID-> {ParkingName, Parkinglane, ParkingStatus}

Parking name, lane, status is dependent upon the parking ID

Card_ID, Cust_ID-> {ParkingName, ParkingLane, Cust_Entry, Cust_Exit}

013600001084 11
 ParkingName, parkingLane, Customer entry and exit is dependent upon the composite
key Card_ID and the Cust_ID

Card_ID-> {Card_Type, Card_Issue, Card_Balance}

CardType, Issue date and the balance amount is dependent upon the Card_ID

Card_ID-> {Cust_ID, Cust_Name, Card_Balance}

Balance remaining for particular Customer is dependent upon the Card_ID

d) Boyce Codd Normal Form

013600001084 12
Question 5. De-Normalization

DE normalization is a process to optimize the performance of a database by adding up redundant

data or grouping of data without any loss of data.

Parking Area can be split up into two relations parking and parking lane

Parking
P_ID P_Name
1 DeMontFort
2 BrookField
ParkingLane
P_ID P_Lane P_Status
1 D1 Occupied
1 D2 Occupied
2 B1 Vacant
2 B2 Occupied
1 D3 Vacant
2 B3 Occupied
2 B4 Occupied
1 D4 Vacant

Show the ParkingLanes vacant at DeMontFort

Select P_Lane from ParkingLane inner join Parking on ParkingLane.P_ID=Parking.P_ID where

P_Status=Vacant

R1= P_ID, P_Lane, P_Status=Vacant ParkingLane

R2= P_ID R1

R3= P_Name R2

013600001084 13
 Show CustomerName whose Card_ID=501

Select CustomerName from CustomerDetails INNER JOIN CardDetails on

CustomerDetails.Cust_ID=CardDetails.Cust_ID Where CardDetails.Card_ID=501

R1= Cust_ID, Card_ID=501 from CardDetails

R2= Cust_ID R1

R3= Cust_Name R2

013600001084 14
References
1. Anon., 2012. System Analysis and Design. [Online]
Available at: http://nptel.ac.in/courses/Webcourse-contents/IISc-
BANG/System%20Analysis%20and%20Design/pdf/Lecture_Notes/LNm8.pdf
[Accessed 10 July 2016].

2. Anon., n.d. ER to Relational Schema. [Online]

Available at: https://www.student.cs.uwaterloo.ca/~cs338/slides/13%20ER%20to%20Rel.pdf
[Accessed 05 July 2016].

3. R.Elmasri and S.B.Navathe, Fundamentals of Data Base Systems, 6th Edition Pearson

Chapter 7 Data Modelling Using ER Model Section 7.7 page 222

Chapter 9 Relational Database Design by ER-to-Relational Mapping section 9.1 page 287

013600001084 15