DATABASE DESIGN AND MANAGEMENT - By Hansa Edirisinghe

774 views

Published on

CASE STUDY - 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: - By Hansa Edirisinghe

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
774
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
30
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DATABASE DESIGN AND MANAGEMENT - By Hansa Edirisinghe

  1. 1. DATABASE DESIGN AND MANAGEMENT BSc(Hons) Assignment 2011 DATABASE DESIGN AND MANAGEMENT Hansa K. Edirisinghe BSc (Hons) University of Portsmouth, UK 10/17/2013
  2. 2. 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.
  3. 3. 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).
  4. 4. 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:
  5. 5. (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.
  6. 6. Table of Content Question 1………………………………………………………………………………1 Question 2………………………………………………………………………………5 Question 3………………………………………………………………………………7 Page 1 of 8
  7. 7. 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 Relationship between Vehicle and Driver (d) Ratio 1: M relationships in the scenario Relationship between Relationship between Relationship between Relationship between Relationship between 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 Relationship between Relationship between Order_detail and Product Warehouse and Product Page 2 of 8
  8. 8. Relationship between Relationship between Relationship between Relationship between 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 Relationship between Relationship between Relationship between Warehouse and Product Warehouse and Supplier Supplier and Product Page 3 of 8
  9. 9. (h) EER Diagram Page 4 of 8
  10. 10. 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 5 of 8
  11. 11. 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 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
  12. 12. 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
  13. 13. 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) Prod_Photo (Phot_Id) Page 8 of 8
  14. 14. 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 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
  15. 15. 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
  16. 16. 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
  17. 17. 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

×