DATABASE DESIGN AND MANAGEMENT - By Hansa Edirisinghe

DATABASE DESIGN AND MANAGEMENT

BSc(Hons) Assignment
2011
DATABASE DESIGN AND MANAGEMENT
Hansa K. Edirisinghe
BSc (Hons) University of Portsmouth, UK
10/17/2013

CASE STUDY

ABC ONLINE ORDERING AND DELIVERY SYSTEM
ABC, a multinational hypermarket based in Singapore, is intending to implement an online ordering and
delivery system. To do this, it needs to design and build a database with the following functional
requirements:
(i)

Maintaining Customer Details
It maintains customer records with their identification number, names and addresses, (including the
country in which they live), date of birth, gender, telephone no, and email address. ABC has both
corporate customers and individual customers.

(ii)

Order processing
Customers are to be able to browse the product catalogue and place orders over the Internet. After
reaching the website, customers should first identify themselves by their unique customer
identification number and password. Then they should be able to browse the catalogue and to place
orders online.
The Product catalogue includes all the products sold by ABC. For each product there is a unique
product number recorded as well as the product name, make and unit price. An additional attribute
of photograph number will also used so that photographs of the items can be displayed on the web
site.

(iii) Payment particulars
On receipt of the order the system produces a delivery note that contains the product details,
quantity ordered, customer details etc. This information is confirmed with the customer via the
website at the time of ordering.

(iv)

All payments are made by credit card. Once payment is confirmed by the payment site, the delivery
is confirmed and details sent to the dispatch department.
Delivery system
ABC uses its own delivery vehicles for delivery.
For delivery fleet, it records information about its own vehicles. It also records information about
its Drivers, who are identified by a unique driver number. Each driver has a name, home address,
date of birth and country.
A vehicle (identified by vehicle number, make and year of manufacture) may be used whenever it is
available. It is possible for any vehicle to be used more than once on a given day. Any vehicle can
be used by any driver any number of times each day.
Each time a driver takes out a vehicle, he/she takes several delivery orders. Any number of
deliveries can be made during a trip. An address of the delivery order is recorded for each stop,
together with the delivery order number. A driver will stop at an address only once during one trip.
However, it is possible for stops to be made at the same address on different trips.

Each time a vehicle is taken out, the driver can incur expenses of allowed types (eg. fuel cost). Each
expense type has code number. The amount and code number are recorded each time an expense is
incurred. There may be one or more expenses incurred during the same trip.
(v)

Inventory
ABC has a number of warehouses in different countries. Stocks are maintained at these warehouses.
Each warehouse is identified by a unique number.
ABC maintains the records of its suppliers with Supplier id, Supplier name, address and contact no.
When a particular product‟s quantity on hand falls below a predefined value, a purchase order is
issued by the dispatch to the supplier. If a product has multiple suppliers, the purchase order is sent
to the supplier currently charging the least for the product and who has sufficient stock to meet the
order.
Although in most cases only one supplier would supply a particular product, there are some cases
where the same product is obtained from more than one supplier.

QUESTION 1
In the design of the centralized database the first step is drawing the conceptual model, the EER
diagram.
With reference to the case study given above, perform the following tasks:
(a)

Identify all the real world entities giving a candidate key and suitable attributes for each
entity).
(N.B. A maximum of 6 attributes should be given for each entity)

(b)

Identify a weak entity present in the case study and determine its owning relationship.

(c)

Identify any one relationship with a cardinality ratio1: 1.

(d)

Identify any one relationship with cardinality ratio 1: M.

(e)

Identify any one relationship with cardinality ratio N: M.

(f)

Identify the Super/ subtype entities available in the given scenario. Also identify the constraints on
the generalization/specialization as either disjointed or overlapped.

(g)

Identify any one possible ternary relationship in the given scenario.

(h)

Draw a complete EER diagram.
Marks will be awarded for all the relationships (with the cardinality ratio of the relationships)
among the entities and all the components of the EERD as answered in Q1a to Q1 g).

Entities and weak entities
Relationships (1:1, 1: M and N: M)
Super type/subtype entities
Ternary relationship

QUESTION 2: Design of centralized relational database using bottom up method
(a)

Identify a single un-normalized relation for the above scenario.

(b)

Identify the primary key for the un-normalized relation.

(c)

Identify all functional dependencies available in the above scenario.

(d)

From identified functional dependencies, produce a set of Boyce Coad Normal form relations.
BCNF. (No need to do 1NF, 2NF and 3NF).

QUESTION 3
ABC is planning to start two more branches in Hong Kong and Malaysia. The branch at Singapore will
remain as the main branch. ABC proposes to establish a distributed database instead of the centralized
database. The system requirements for this are given below.
(i) Customers have to be attached to the branches based on the country in which they are living.
(ii) Each branch will be linked to the warehouses in its country.
(iii) Each branch will maintain its own inventory. When the products on hand go below a permitted
value, each branch will send their requirements to the main branch which will purchase the
products from the suppliers.
(iv) The main branch will prepare the Product catalogue. The products are priced once a year by the
main branch.
(v) ABC branches will take over the delivery function in these countries and hence vehicles and drivers
are to be maintained by the branches.
(vi) A Customer can place an order at any branch .The order will be transmitted to the respective branch
to which the customer is attached and delivery will be handled by that branch.
(vii) The products sold will be identical in all the three branches as in the main branch.
Write a report to the senior management of ABC, detailing the design of fragments, allocation of
fragments, advantages of the proposed distributed database over the existing centralized database and its
limitations.
Your report should be between 500 and 750 words long. You will be penalized if your report lies outside
these boundaries.
Report must include the followings:

(a)

Design of suitable fragments of the distributed database for ABC.
List of fragments includes necessary horizontal and derived horizontal fragments.

(b)

Allocation of fragments to the Branches.

(c)

Advantages and limitations of using distributed database.

Table of Content

Question 1………………………………………………………………………………1
Question 2………………………………………………………………………………5
Question 3………………………………………………………………………………7

Page 1 of 8

Question 1
(a) Realworld entities, candidate keys and suitable attributes for each entities.
Customer (Cus_id, Cus_name, Cus_gender, Cus_dob, Cus_address (address, Country),
{Cus_contact}, email)
Corporate_cus
Individual_cus
Order_detail (Cus_order_num, Qty_ordered)
Product (Prod_id, Prod_name, Prod_make, Prod_price)
Prod_Photo (Phot_Id)
Supplier (Sup_id, Sup_name, Sup_address, Sup_contact)
Credit_card (Card_no, Exp_date)
Warehouse (Wh_code, Wh_address (address, country))
Driver (Driv_no, Driv_name, Driv_address, Driv_dob, Driv_country)
Vehicle (Vehi_no, Vehi_make, Vehi_year_mani)
Expense (Exp_code, Exp_type, Exp_amount)
(b) Weak entity and its owning relationships
Prod_Photo is the weak entity and Product would be its strong entity. The Phot_Id of
Prod_Photo cannot exist without a product. But a product can exist without a photo.
Assumption: One product can have several photos in the database
Relationship between
Strong Entity
Weak entity
Partial Key

Product and Prod_Photo
Product
Prod_Photo
Phot_Id

(c) Ratio 1:1 relationships in the scenario

Vehicle and Driver

(d) Ratio 1: M relationships in the scenario

Customer and Order_detail
Customer and Credit_card
Credit_card and Order_detail
Driver and Order_detail
Prod_Photo and Product

(e) Ratio N:M relationships in the scenario

Order_detail and Product
Warehouse and Product

Page 2 of 8


Warehouse and Supplier
Supplier and Product
Expense and Driver
Expense and Vehicle

(f) Super/ Subtype entities and constrains on the globalization / specialization as either
disjointed or overlapped
Super Entity
Sub Entities

Customer
Corporate_cus, Individual_cus

(g) Ternary Relationships in the scenario

Warehouse and Product
Warehouse and Supplier
Supplier and Product

Page 3 of 8

Question 2
(a) Un-normalized relation
Order(Cus_id, Cus_order_num, Prod_id, Sup_id, Card_no, Wh_code, Driv_no, Vehi_no,
Exp_code, Cus_name, Cus_gender, Cus_dob, Cus_address, Cus_contact, email,
Qty_ordered, Prod_name, Prod_make, Prod_price, Phot_Id, Sup_name, Sup_address,
Sup_contact, Exp_date, Wh_address, Driv_name, Driv_address, Driv_dob, Driv_country,
Vehi_make, Vehi_year_mani, Exp_type, Exp_amount, Cus_password)
(b) Primary key for un-normalized relation
Cus_id, Cus_order_num, Prod_id, Sup_id, Card_no, Wh_code, Driv_no, Vehi_no, Exp_code
Above primary key is a composite primary key.
Assumptions: There should not contain any NULL values for the primary key. So if a record
exists with not values applicable to its composite primary keys the cell value contains with
“N/A”
e.g. When we enter an order we will get values to Cus_id, Cus_order_num, Prod_id, Card_no
But we do not get values for the Sup_id, Wh_code, Driv_no, Vehi_no, Exp_code in the same
record. So we can fill them with “N/A” because they are composite primary keys.
(c) Functional dependencies
Cus_order_num  { Qty_ordered, Cus_id, Prod_id, Driv_no}
Cus_order_num, Cus_id  { Cus_password}
Cus_id  { Cus_name, Cus_gender, Cus_dob, Cus_address, Cus_contact, email, Card_no }
Card_no  { Card_no, Exp_date, Cus_id }
Prod_id  { Prod_name, Prod_make, Prod_price, }
Wh_code  { Wh_address }
Sup_id  { Sup_name, Sup_address, Sup_contact }
Driv_no  { Driv_name, Driv_address, Driv_dob, Driv_country }
Vehi_no  { Vehi_make, Vehi_year_mani, Driv_no }
Exp_code  { Exp_type, Exp_amount }
(d) Set of Boyce Coad Normal form relation
Order_detail (Cus_order_num, Qty_ordered, Prod_id, Cus_id, Card_no, Driv_no)
Credit_card (Card_no, Exp_date)
Customer (Cus_id, Cus_name, Cus_gender, Cus_dob, Cus_address, Cus_contact, Email)
Product (Prod_id, Prod_name, Prod_make, Prod_price, Phot_Id, Wh_code, Sup_id)
Warehouse (Wh_code, Wh_address)
Driver (Driv_no, Driv_name, Driv_address, Driv_dob, Driv_country, Vehi_no, Exp_code)

Page 5 of 8

The referential integrity among the relations can be represented as below
Order_detail
Cus_order_num Qty_ordered Prod_id

Cus_id

Card_no Driv_no
Credit_card
Card_no Exp_date

Customer
Cus_id Cus_name Cus_gender Cus_dob Cus_address Cus_contact Email

Product
Prod_id Prod_name Prod_make Prod_price Phot_Id Wh_code Sup_id

Prod_Photo
Phot_Id

Supplier
Sup_id Sup_name Sup_address Sup_contact

Warehouse
Wh_code Wh_address

Driver
Driv_no Driv_name Driv_address Driv_dob Driv_country Vehi_no

Exp_code

Vehicle
Vehi_no Vehi_make Vehi_year_mani

Expense
Exp_code Exp_type

Exp_amount

Page 6 of 8

Question 3
Centralized database
The data which are stored in one database in a single a location is call centralized database.
Because of that all the client machines access to the main database to retrieve the data. All the
data entries, update and delete functions should be done to the centralized database. If centralized
database corrupted, it will affect to the whole system. This situation will affect to the function of
Hong Kong, Malaysia and Main branch in Singapore. This may be loose the all the production
and inventory history, if they did not maintain backups correctly. As a solution, if we use cluster
server if the WAN down it will affect the clients to get the information.

Figure 1 - Network architecture of ABC centralized database

Why do centralized database not suitable for ABC ?
There are three branches for ABC Company including the main branch. There are lots of
members‟ accesses to the database at the same time from different locations. If some problem
occurs with the central database, customers can not access and order products from any branch
through the system. It will put customers in a trouble and customers could be work no longer
with them.
Distributed database
Distributed database is collection of logically interrelated databases that contains collection of
data files which are physically located in different sites in a computer network. Distributed
database management system synchronizes all the data periodically and it will check whether the
changes in database are update automatically in all the places. So the users can access the
relevant data without interfering with one and another.

Page 7 of 8

Figure 2 -Network architecture of ABC distributed database

(a)

Suitable fragments of the distributed database for ABC

When using distributed database, we have to concern on how to distribute the database among
the regions. Several techniques are used to perform the fragmentation, replication and allocation
of the database into each branch. Fragmentation mean dividing the database into logical units
called fragments that can be stored in various branch locations. Storing of same data in several
lactations is called the data replication and allocating the fragments/replicas in the branch
locations is called the allocation.
Following database is derived from the question 1ABC online ordering and delivery system and
changed it to fulfill the given branch needs.
Customer (Cus_id, Cus_name, Cus_gender, Cus_dob, Cus_address, Cus_contact,email,
Cus_type)
Corporate_cus (Cus_id, Cus_name, Cus_gender, Cus_dob, Cus_address, Cus_contact,email,
Cus_type)
Individual_cus (Cus_id, Cus_name, Cus_gender, Cus_dob, Cus_address, Cus_contact,email,
Cus_type)
Credit_card (Card_no, Exp_date, Cus_cardType)
Order_detail (Cus_order_num, Qty_ordered)
Product (Prod_id, Prod_name, Prod_make, Prod_price)

Page 8 of 8

Warehouse (Wh_code, Wh_address)
Driver (Driv_no, Driv_name, Driv_address, Driv_dob, Driv_country)
Branch (Branch_id, Br_country, Type, Pro_id)
Product_catalog(Pro_id, Pro_name, Pro_price, price_year)
Good_requirement(Req_id, qty_request, request_date, total_cost, Branch_id, Sup_id)
Assumptions:



Good_requirement can only exist with the Branch_id wish belongs to main branch.
Product_catalog records does only exists with Branch_id wish belongs to main branch.
Fields contains with “N/A”

In the above relational schema „Corporate_cus‟ and „Individual_cus‟ are „Customer‟. Therefore
we can consider „Customer‟ as a relation to distribute the database to horizontal fragments
Cus_id
C0001
C0002
C0003
C0004
C0005
C0006

Cus_name
AA
BB
CC
DD
EE
FF

Cus_gender
Male
Male
Female
Female
Female
Male

Cus_dob
1777
1888
1999
1222
1333
1444

:- Cus_Country = Singapore

Cus_contact
1888
1999
7771
6661
4441
8881

email
Aab
Bbc
Ccd
Dde
eef
ffg

Cus_type
Corporate
Corporate
Corporate
Individual
Individual
Individual

Cus_Country
Singapore
Singapore
Hong Kong
Hong Kong
Hong Kong
Malaysia

:- Cus_Country = Hong Kong

:- Cus_Country = Malaysia

By using the bellow fragmentation we can fragment the database according to branch wise. It
will split the redundant data which that particle branch not using, and the fragmentation will
filter only the data which the branch need.


Horizontal fragmentation of „Customer‟ table to Singapore, Hong Kong and Malaysia
Branches
o
o
o



Sin_Customer  σ Cus_Country = Singapore (Customer)
Hong _Customer  σ Cus_Country = Hong Kong (Customer)
Mala_Customer  σ Cus_Country = Malaysia (Customer)

Using the same method the „Corporate_cus‟ Relation can be horizontally fragmented as
below
o

Sin_Corporate_cus  σ

Cus_Country = Singapore (Corporate_cus)

Page 9 of 8

o
o


Hong_Corporate_cus  σ Cus_Country = Hong Kong (Corporate_cus)
Mala_Corporate_cus  σ Cus_Country = Malaysia (Corporate_cus)

Similarly we can fragment „Individual_cus‟ also using horizontal fragmentation.
o
o
o

Sin_Individual_cus  σ Cus_Country = Singapore (Individual_cus)
Hong_Individual_cus  σ Cus_Country = Hong Kong (Individual_cus)
Mala_Individual_cus  σ Cus_Country = Malaysia (Individual_cus)

The „Customer‟, „Corporate_cus‟ and „Individual_cus‟ are the primary relations that have the
„Credit_card‟ attribute which was used to fragment the database. As the patient relation is the
super type of visa, master relations, and the primary relation (Credit_card) is related to those
secondary relations (visa, master) via a foreign key. So those secondary relations can also be
fragmented in the same way. That is called „derived horizontal fragmentation‟
o
o
o
o
o
o


visa_Sin_Corporate_cus  σ Cus_cardType = visa (Sin_Corporate_cus)
master_Sin_Corporate_cus  σ Cus_cardType = master (Sin_Corporate_cus)
visa_Hong_Corporate_cus  σ Cus_cardType = visa (Hong_Corporate_cus)
master_Hong_Corporate_cus  σ Cus_cardType = master (Hong_Corporate_cus)
visa_Mala_Corporate_cus  σ Cus_cardType = visa (Mala_Corporate_cus)
master_Mala_Corporate_cus  σ Cus_cardType = master (Mala_Corporate_cus)

By using the same derived horizontal fragmentation, we can fragment Individual_cus as
bellow.
o
o
o
o
o
o

visa_Sin_Individual_cus  σ Cus_cardType = visa (Sin_Individual_cus)
master_Sin_Individual_cus  σ Cus_cardType = master (Sin_Individual_cus)
visa_Hong_Individual_cus  σ Cus_cardType = visa (Hong_Individual_cus)
master_Hong_Individual_cus  σ Cus_cardType = master (Hong_Individual_cus)
visa_Mala_Individual_cus  σ Cus_cardType = visa (Mala_Individual_cus)
master_Mala_Individual_cus  σ Cus_cardType = master (Mala_Individual_cus)

(b) What is allocation of fragmentation to the branches?
The whole database will be allocated to main branch in order to make the decision making, and
report generation easy. The other branches will have no replicated fragments stored.
(c) Advantages and limitations of using distributed database


Advantages of using distributed database

o Faster Response
When the use tries to access a particular data, the nearest location distributed database provides
the information to the user. So it will save the time.

Page 10 of 8

o Local autonomy
If anything happened to a branch database or if there is a maintenance going with branch
database, the branch cannot operate with its database. Each country controls its data, security,
logging and recovery.
o Location Transparency
There is no chance for the user to get to know about the data location.
o Increased Reliability and availability
If one branch database down, it will not affect to the other branches. So the data will available all
the time.
o Sharer ability
It will allow the user to access the data which is stored in the other sites.
o Expandability
If ABC wants to add some more branches they can easily add without interruption to the other
branches.
o Lower communication cost
Operating cost will be reduced
o More Flexible
It will increase the security since the database access from the various locations and different
applications.


Limitations of using distributed database

o Waste of storage place
As for the each branch, a new database storage place should be designed, it will be a waste of the
storage place.
Reference
http://www.bremuz.ru/ (2011) Received on 24th July 2011from
http://www.bremuz.ru/webdbapps2-APP-E-SECT-2.html
OPEN Process Framework (2011) Received on 25th July 2011from
http://www.opfro.org/Components/WorkProducts/DiagramSet/Design/DataDesignDiagram/Data
DesignDiagram.html
about.com (2011) Received on 29th July 2011from
http://databases.about.com/od/specificproducts/a/normalization.htm

Page 11 of 8

www.emunix.emich.edu/ (2011) Received on 30th July 2011from
http://www.emunix.emich.edu/~khailany/files/Normalization.htm
Elmasri, R. & Navathe S. B. (2009) Fundamentals of Database Systems, 5th edition, India :
Dorling Kindersley

Page 12 of 8

DATABASE DESIGN AND MANAGEMENT - By Hansa Edirisinghe

More Related Content

Similar to DATABASE DESIGN AND MANAGEMENT - By Hansa Edirisinghe (20)

Recently uploaded (20)

DATABASE DESIGN AND MANAGEMENT - By Hansa Edirisinghe