Introduction

DBMS is nothing but a computerized data keeping system and market prefers to use
relational model for database design as it is tested and proven as good implementation over
more than 2 decades.
(Source: Database systems: a pragmatic approach, Book by Elvis C. Foster; Shripad
Godpole 2015, Pg No 37)
Relational database depicts easy to understand maintained data integrity and eliminate data
redundancy. We can design resultant relational database based on 2 approaches such as
top down & bottom up.
These modelling techniques represent graphical representation of underlying business
requirements gathered through Fact finding.

Top Down modelling approach to produce an Entity-Relationship (E-R) Diagram

Below are the steps from top down modelling approach to generate resultant ERD.
1. Identify Entities, attributes
2. Allocate set of attributes to each listed entities and form table-column structure
3. Establish logical relationships amongst these entities
4. Define constraints in the form of Primary key, foreign key, and composite key
5. Define cardinalities for all these relationships.
6. Produce graphical design model.
We have to try not to introduce any loop in model as this is generalised design based on
high level requirement description and assumptions (if any).
For the assignment case study, please find below list of entities also known as ‘business
objects’ as per top down approach.

1
List of Entities

List out Attributes per Entity

Attributes are classified as simple or composite, single valued or multivalued / derivate and
strong-weak entities. Below top down approach consists of all kinds of attributes in the
design. Few are described in below image.
(Source: Database systems: a practical approach to design, implementation, and
management Book by Thomas M. Connolly; Carolyn E. Begg, 2015, Pg No 414)

2
3
4
Now we will look at Bottom Up approach by normalizing data based on functional
dependencies. Normalization not only minimizes redundancy of data but also establishes
close relationships amongst defined business objects (database tables) and makes them
easy to use, maintain with optimum use of database.

5
Sr No Normalized Table Name Purpose Of Table
1 Customer It holds Customer data and connects to
Order table to place order, and connects
to Address table
2 Employee It contains employee's basic data and
connects to Order_Entry_Type and
Department table
3 Order This table connects to Customer,
Order_Detail and Order_Entry_Type
table.
4 Order_Detail There could be multiple tools inside an
order and therefore this table exists. If
we will connect Order table to
Manufacturing_Batch table directly, it will
be M : M relationship. To break it , we
have introduced this table.
It connects to tables - Order and
Manufacturing_Batch.

6
 5 Tool This table connects to multiple tables like
- Manufacturing_Batch (Reason: Order
from this table will be having multiple
tools),
Tool_Pricing (Reason : Normalization),
Product_Catalogue, Test_Report.
6 Address This table is result of normalization of
customer's data, separating address
related columns. It is connected to
Customer, City.
7 Department It shows department per employee.
Assumption is each employee works in 1
department only.
8 Order_Entry_Type This table is result of normalization of
Order's data to fetch Order_Entry_Type.
This EntryType is dependent on
Customer_Id and Order_Id, therefore it
is connected to Order table. If
Order_Entry_Type is 'sales person' then
only Emp_Id will fetch data from
Employee table.
9 Fault_Report As name suggest, this table connects to
Tool, Tool_Return and Problem_Code
tables.
10 Tool_Return This is leaf node / outer table in relations
and it connects to Fault_Report. So only
those tools will be returned for whom
there would be fault report.
11 City This table is result of normalization of
address's data, separating city related
columns. It is connected to address &
country. This table acts as Reference
table, so any new city per country added
in this table will be replicated in other
tables.
12 Country This table is result of normalization of
city data, separating country related
columns. It is connected to city. This
table acts as Reference table, so any
new country added in this table will be
replicated in other tables.
13 Raw_Material_Ordered_From_Supplier As we don’t we have much Supplier
related requirement, we are just
considering this table as Raw Material
Orders receiving from Suppliers. It
connects to table -
RM_Required_Per_Tool.
14 Raw_Material_Inventory This table contains available quantity of
raw materials date wise. It is connected
to RM_Required_Per_Tool table.

7
15 RM_Required_Per_Tool
16 Test_Report
17 Test_Detail
18 Product_Catalogue
19 Tool_Size_Detail
20 Raw_Material_Price_Detail
21 Tool_Pricing
if we will connect
Raw_Material_Ordered_From_Supplier
and Raw_Material_Inventory table
dierectly, it will generate M :M
relationship. To break this we have
introduced RM_Required_Per_Tool
table. This table contains raw material
required for each tool. Multiple tools will
require different raw material and
therefore this table is required. For
example, For Tool_Id 'T001' there are 2
raw materials required 'RM001', 'RM002'
and their quantity is also different like 2
units of 'RM001' and 3 units of 'RM002'.
So this table will show similar data.
It connects to different tables such as -
Raw_Material_Inventory,
Raw_Material_Ordered_From_Supplier,
Raw_Material_Price_Detail.
This table connects to Test_Detail and
Tool. Assumption: For every Tool there
will be 1 Test_Report for quality
maintainance.
This is leaf node / outer table in relations
and it connects to Test_Report. This is
also normalized table connects to
Test_Report.
This is leaf node / outer table in relations
and it connects to Tools. There could be
multiple tools belonging to 1 catalogue
and there could be multiple catalogues.
But 1 Tool can belong to only 1
catalogue.
This is leaf node / outer table in
relations. It connects to Tool_Pricing
table. This table is result of normalization
of Tool table.
This table also decides Tool price as it
holds underlying raw material's prices.
This normalized table connects to
Tool_Pricing and
RM_Required_Per_Tool tables.
This table is result of normalization of
Tool table. It connects to
Tool_Size_Detail and Tool table.
8
22 Manufacturing_Batch
23 Manufacturing_Line_Schedular
24 Manufacturing_Line
25 Tool_Finished_Goods_Inventory
26 Shipping_Box
27 Shipment_Log
28 Shipment
29 Problem_Code
As per requirement, Multiple Orders
forms a batch and each order may have
multiple tool. Therefore to encapsulate
no of tools we have formed this table
which can be connected to
Manufacturing_Line_Schedular for
actual production scheduling.
It connects to
Manufacturing_Line_Schedular, Tools,
Oder_Detail tables. We can check status
of any batch along with given order and
no of tools involved with this table.
This is intermedairy table used to break
M:M relationship of Manufacturing_Batch
and Manufacturing_Line tables as
multiple batches can be produced at
multiple lines.Therefore It acts as
schedular as per one the requirement. It
tells if previous batch execution is done
or not. It is connected to
Manufacturing_Batch and
Manufacturing_Line tables.
This table holds no of finished goods at
each manufacturing line date wise and
transfers finished goods to respective
inventory.
It connects to
Manufacturing_Line_Schedular and
Tool_Finished_Goods_Inventory.
This table connect to
Manufacturing_Line and Shipping_Box
tables. This inventory is present as
warehouse of multiple finished goods
coming from multiple manufacturing
lines.
Here we are applying Serial_No
(important tracker) to fecth shipping
information along with manufacturing
date. There will be multiple shipping
boxes, ready for shipment.
To break M : M relationship between
Shipping_Box and Shipment, this table
exists and it acts as log/schedular. It
connects to tables - Shipping_Box and
Shipment. It schedules multiple shipping
boxes as per arrival, departure time and
allocates shipment accordingly.
This is final table in the requirement,
which connects to Shipment_Log and
holds shipping information along with
shipment label.
This is leaf node / outer table in
relations. It connects to Fault_Report
9
 table. This table is result of normalization
of Fault_Report table.

In Bottom Up approach, we will create 1st, 2nd, 3rd normal forms as below.
In this case, we have to keep track of functional dependencies and divide table furthermore
till it reaches a structure where every determinant is only 1 primary key as per Boyce-Codd
Rule.

10
11
 Address Order_Entry_Type

PK Address_Id PK Order_Entry_Type_Id
Country City Department Problem_Code
Order_Entry_Type Employee
FK City_Id
PK City_Id PK Dept_Id PK Problem_Code_Id
PK Country_Id Street PK EMP_Id
FK EMP_Id
FK Country_Id Dept_Name Problem_Description
FK Country_Name Post_Code Emp_First_Name
City_Name Last_Update FK EMP_Id Decision_Made
Last_Update Phone
Last_Update Emp_Last_Name
Email

Raw_Material_Price_Detail Customer Order Order_Detail Fault_Report

Initiates Return Tool_Return
Places Includes
PK RM_Price_Detail_Id PK Customer_Id PK Order_Id PK Order_Detail_Id PK Fault_Report_Id
PK Tool_Return_Id
FK RM_Required_Per_Tool_Id Customer_Name FK FK Order_Id FK Tool_Id
Customer_Id
FK Fault_Report_Id
Corporate (Y/N) Generated For
Price FK Order_Entry_Type_Id Order_Serial_No FK Problem_Code_Id
Account_Opening_Date Return_Flag
Order_Creation_DateTime Fault_Report_DateTime
FK Address_Id Return_Date

Forms
Raw_Material_Ordered_From_Supplier
RM_Inventory_Id
RM_Required_Per_Tool
PK Raw_Material_Ordered_From_Supplier_Id Makes up Manufacturing_Line_Schedular
PK RM_Inventory_Id
PK RM_Required_Per_Tool_Id
Raw_Material_Name PK Manufacturing_Line_Schedular_Id Manufacturing_Line
FK RM_Required_Per_Tool_Id
Raw_Material_Type FK Raw_Material_Ordered_From_Supplier_Id
FK Manufacturing_Batch_Id PK Manufacturing_Line_Id
Raw_Material_Quantity_Available
Raw_Material_Feature Supplies RM FK Tool_Id
Raw_Material_Quantity_Ordered Quantity_RM_Required_Per_Tool Raw_Material_Quantity_Available_On_DateTime FK Manufacturing_Line_Id No_Of_Finished_Goods

Raw_Material_Quantity_Ordered_Date Last_Update Finished_Goods_Sent_To_Inventory_DateTime

Raw_Material_Quantity_Red_Flag Manufacturing_Line_Execution_StartDateTime
Scheduled By Manufacturing_Line_Location
Raw_Material_Quantity_Red_Flag_DateTime
Manufacturing_Line_Execution_EndDateTime
FK Tool_Finished_Goods_Inventory_Id
Manufacturing_Line_Execution_Duration
Test_Report Tool Manufacturing_Batch
Test_Detail Manufacturing_Line_Scheduling_Flag Transfer Goods
PK Test_Report_Id PK Tool_Id PK Manufacturing_Batch_Id
PK Test_Detail_Id Tool_Name
Test_Report_DateTime Determines
FK Order_Detail_Id
Test_Type FK Manufacturing_Batch_Id Tool_Finished_Goods_Inventory
Test_Report_Locat Manufacturing_Batch_ Shipping_Box
Test_Result ion Tests Execution_Completion_Status PK Tool_Finished_Goods_Inventory_Id
FK Product_Catalogue_Id Consists Of
PK Shipping_Box_Id
Test_Description Test_Comments Last_Update FK Shipping_Box_Id
FK Tool_Id Serial_No
Tool_Finished_Goods_Available_Quantity
FK Test_Detail_Id Tool_Pricing Shipment_Box_Label
Tool_Finished_Goods_Quantity_Available_On_DateTime
PK Tool_Pricing_Id Manufacturing_DateTime Prepares
Product_Catalogue
Belongs To

FK Order_Detail_Id Shipment Tool_Finished_Goods_Inventory_Location

PK Product_Catalogue_Id Scheduled by
Tool_Size_Detail_Id PK Shipment_Id
FK
FK Tool_Id Tool_Size_Detail
FK RM_Price_Detail_Id Shipment_Label
Catalogue_Type Shipment_Log
PK Tool_Size_Detail_Id
FK Tool_Id Shipment_Location
Last_Update PK Shipment_Log_Id
Size_of_Tool
Unit_Price Estimated_Delivery_DateTime_Of_Shipment Ships Goods
Type_of_Size FK Shipment_Id

FK Shipping_Box_Id

Shipping_Box_Arrival_DateTime

Shipping_Box_Departure_DateTime

No_of_Shipent_Boxes

12
Conclusion
Even though top down & bottom up approaches are different, both area actually
complimentary to each other, working in cyclical manner.
Therefore by gathering observable entities along with attributes, we can lay foundation to
proceed with normalization of data, covering all facets of requirement.
With the assumption that customer’s address entity is slowly changing dimension (Customer
won’t change his address frequently, it will be an occasional event), we would like to remove
normalised address related tables from final design and keep all address related information
in customer table. Even though there will be duplicate address related entries per customer,
it’s easy to maintain all entries in 1 table.
In this way, we would like to conclude the above design which normalises entities listed out
in top down approach, in addition adds more required/normalised tables to the list and it
suffice the given case study requirement.
Order_Entry_Type

Customer PK Order_Entry_Type_Id
Department Problem_Code
PK Customer_Id Order_Entry_Type Employee
PK Dept_Id PK Problem_Code_Id
FK EMP_Id PK EMP_Id
Customer_Name
Dept_Name Problem_Description
Emp_First_Name
Corporate (Y/N) Last_Update FK EMP_Id Decision_Made
Account_Opening_Date Emp_Last_Name
City
Country
Raw_Material_Price_Detail Order Order_Detail Fault_Report
Initiates Return Tool_Return
Street
Places Includes
PK RM_Price_Detail_Id PK Order_Id PK Order_Detail_Id PK Fault_Report_Id
Phone PK Tool_Return_Id
FK RM_Required_Per_Tool_Id Post_Code FK FK Order_Id FK Tool_Id
Customer_Id
FK Fault_Report_Id
Generated For
Price Email FK Order_Entry_Type_Id Order_Serial_No FK Problem_Code_Id
Return_Flag
Order_Creation_DateTime Fault_Report_DateTime
Return_Date
Forms
Raw_Material_Ordered_From_Supplier
RM_Inventory_Id
RM_Required_Per_Tool
PK Raw_Material_Ordered_From_Supplier_Id Makes up Manufacturing_Line_Schedular
PK RM_Inventory_Id
PK RM_Required_Per_Tool_Id
Raw_Material_Name PK Manufacturing_Line_Schedular_Id Manufacturing_Line
FK RM_Required_Per_Tool_Id
Raw_Material_Type FK Raw_Material_Ordered_From_Supplier_Id
FK Manufacturing_Batch_Id PK Manufacturing_Line_Id
Raw_Material_Quantity_Available
Raw_Material_Feature Supplies RM FK Tool_Id
Raw_Material_Quantity_Ordered Quantity_RM_Required_Per_Tool Raw_Material_Quantity_Available_On_DateTime FK Manufacturing_Line_Id No_Of_Finished_Goods

Raw_Material_Quantity_Ordered_Date Last_Update Finished_Goods_Sent_To_Inventory_DateTime

Raw_Material_Quantity_Red_Flag Manufacturing_Line_Execution_StartDateTime
Scheduled By Manufacturing_Line_Location
Raw_Material_Quantity_Red_Flag_DateTime
Manufacturing_Line_Execution_EndDateTime
FK Tool_Finished_Goods_Inventory_Id
Manufacturing_Line_Execution_Duration
Test_Report Tool Manufacturing_Batch
Test_Detail Manufacturing_Line_Scheduling_Flag Transfer Goods
PK Test_Report_Id PK Tool_Id PK Manufacturing_Batch_Id
PK Test_Detail_Id Tool_Name
Test_Report_DateTime Determines
FK Order_Detail_Id
Test_Type FK Manufacturing_Batch_Id Tool_Finished_Goods_Inventory
Test_Report_Locat Manufacturing_Batch_ Shipping_Box
Test_Result ion Tests Execution_Completion_Status PK Tool_Finished_Goods_Inventory_Id
FK Product_Catalogue_Id Consists Of
PK Shipping_Box_Id
Test_Description Test_Comments Last_Update FK Shipping_Box_Id
FK Tool_Id Serial_No
Tool_Finished_Goods_Available_Quantity
FK Test_Detail_Id Tool_Pricing Shipment_Box_Label
Tool_Finished_Goods_Quantity_Available_On_DateTime
PK Tool_Pricing_Id Manufacturing_DateTime Prepares
Product_Catalogue
Belongs To

FK Order_Detail_Id Shipment Tool_Finished_Goods_Inventory_Location

PK Product_Catalogue_Id Scheduled by
Tool_Size_Detail_Id PK Shipment_Id
FK
FK Tool_Id Tool_Size_Detail
FK RM_Price_Detail_Id Shipment_Label
Catalogue_Type Shipment_Log
PK Tool_Size_Detail_Id
FK Tool_Id Shipment_Location
Last_Update PK Shipment_Log_Id
Size_of_Tool
Unit_Price Estimated_Delivery_DateTime_Of_Shipment Ships Goods
Type_of_Size FK Shipment_Id

FK Shipping_Box_Id

Shipping_Box_Arrival_DateTime

Shipping_Box_Departure_DateTime

No_of_Shipent_Boxes

Appendix
Tables-Columns from Top_Down_Approach

13
14
15
Tables-Columns from Bottom_Up_Approach

16
17
18
19
References
Connolly, T. & Begg, C. (2015) "Database Systems. A practical approach to design,
implementation and management" (6th Ed.) Essex: Pearson.
Foster, E. C. & Godbole, S. V. (2014). "Database systems" New York: Apress
Top-Down vs. Bottom-Up Approaches to Data Science (dataiku.com)

Thank you

20