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.

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.

(iv) 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.

Page 1 of 8

Table of Content

Question 1………………………………………………………………………………1

Question 2………………………………………………………………………………5

Question 3………………………………………………………………………………7

Page 2 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 Product and Prod_Photo

Strong Entity Product

Weak entity Prod_Photo

Partial Key Phot_Id

(c) Ratio 1:1 relationships in the scenario

Relationship between Vehicle and Driver

(d) Ratio 1: M relationships in the scenario

Relationship between Customer and Order_detail

Relationship between Customer and Credit_card

Relationship between Credit_card and Order_detail

Relationship between Driver and Order_detail

Relationship between Prod_Photo and Product

(e) Ratio N:M relationships in the scenario

Relationship between Order_detail and Product

Relationship between Warehouse and Product

Page 3 of 8

Relationship between Warehouse and Supplier

Relationship between Supplier and Product

Relationship between Expense and Driver

Relationship between Expense and Vehicle

(f) Super/ Subtype entities and constrains on the globalization / specialization as either

disjointed or overlapped

Super Entity Customer

Sub Entities Corporate_cus, Individual_cus

(g) Ternary Relationships in the scenario

Relationship between Warehouse and Product

Relationship between Warehouse and Supplier

Relationship between Supplier and Product

Page 4 of 8

(h) EER Diagram

Page 5 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)

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)

Page 6 of 8

Vehicle (Vehi_no, Vehi_make, Vehi_year_mani)

Expense (Exp_code, Exp_type, Exp_amount)

The referential integrity among the relations can be represented as below

Customer

Cus_id Cus_name Cus_gender Cus_dob Cus_address Cus_contact Email

Order_detail

Cus_order_num Qty_ordered Prod_id Cus_id Card_no Driv_no

Credit_card

Card_no Exp_date

Product

Prod_id Prod_name Prod_make Prod_price Phot_Id Wh_code Sup_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

Prod_Photo

Phot_Id

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

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.

Figure 1 - Network architecture of ABC centralized database

Page 8 of 8

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

Prod_Photo (Phot_Id)

Figure 2 -Network architecture of ABC distributed database

Page 9 of 8

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)

Vehicle (Vehi_no, Vehi_make, Vehi_year_mani)

Expense (Exp_code, Exp_type, Exp_amount)

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 Cus_name Cus_gender Cus_dob Cus_contact email Cus_type Cus_Country

C0001 AA Male 1777 1888 Aab Corporate Singapore

C0002 BB Male 1888 1999 Bbc Corporate Singapore

C0003 CC Female 1999 7771 Ccd Corporate Hong Kong

C0004 DD Female 1222 6661 Dde Individual Hong Kong

C0005 EE Female 1333 4441 eef Individual Hong Kong

C0006 FF Male 1444 8881 ffg Individual 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 Sin_Customer σ Cus_Country = Singapore (Customer)

o Hong _Customer σ Cus_Country = Hong Kong (Customer)

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

:- Cus_Country = Singapore :- Cus_Country = Hong Kong

:- Cus_Country = Malaysia

Page 10 of 8

o Hong_Corporate_cus σ Cus_Country = Hong Kong (Corporate_cus)

o Mala_Corporate_cus σ Cus_Country = Malaysia (Corporate_cus)

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

o Sin_Individual_cus σ Cus_Country = Singapore (Individual_cus)

o Hong_Individual_cus σ Cus_Country = Hong Kong (Individual_cus)

o 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 visa_Sin_Corporate_cus σ Cus_cardType = visa (Sin_Corporate_cus)

o master_Sin_Corporate_cus σ Cus_cardType = master (Sin_Corporate_cus)

o visa_Hong_Corporate_cus σ Cus_cardType = visa (Hong_Corporate_cus)

o master_Hong_Corporate_cus σ Cus_cardType = master (Hong_Corporate_cus)

o visa_Mala_Corporate_cus σ Cus_cardType = visa (Mala_Corporate_cus)

o 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 visa_Sin_Individual_cus σ Cus_cardType = visa (Sin_Individual_cus)

o master_Sin_Individual_cus σ Cus_cardType = master (Sin_Individual_cus)

o visa_Hong_Individual_cus σ Cus_cardType = visa (Hong_Individual_cus)

o master_Hong_Individual_cus σ Cus_cardType = master (Hong_Individual_cus)

o visa_Mala_Individual_cus σ Cus_cardType = visa (Mala_Individual_cus)

o 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 11 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 12 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