Normalization

Presented by : Tessy Badriyah, SKom. MT.

First Bad Design: Multi-Row

Approach
The first design is approach is
the one most novice database
designers will start with
A row or 'record' is added for
each line item on the order
If an order is for 3 parts, then 3
rows are added to the database
The main problem with this
design is data redundancy

First Bad Design: Multi-Row

Approach

Second Bad Design: MultiValue Column Approach

The second design is an attempt to solve
some of the problems of the first design
We can eliminate some of the data
redundancy by 'rolling up' the order detail
In other words, each order will be limited to
a single row
This creates the problem of what to do with
the order detail
In this case it is placed into a single multivalue column

Second Bad Design: MultiValue Column Approach

Third Bad Design: MultiColumn Approach

The third design is an attempt to solve the
main problem with the second design
It provides order detail (information about
the individual parts in the order) by adding
a separate column for each part
It is now possible to create reports that
provide quantity and pricing data on
ordered parts
But there are two flaws with this design:
wasted storage space and an flexible data
structure

Third Bad Design: MultiColumn Approach

A Normalized Relational
Database Solution
All of the previously identified problems (wasted
storage space, high data maintenance, and
inflexible storage structure) can be eliminated with a
normalized relational database design
As is often the case, normalization of the database
is achieved by separating the data into tables
In this case we take the orders file and the customer
and parts files (which were not discussed), move
some columns around, and make them 'tables'
We also create a fourth table, called order_details,
to implement the many-to-many relationship
between parts and orders

A Normalized Relational
Database Solution

A Normalized Relational
Database Solution
There is no wasted storage space in this
design; every column/row intersection has a value
associated with it
There is no redundant data; customer name and
part description are entered in only one place and
referenced in other places by their associated 'keys'
or identifiers (cust_id and part_id)
Data maintenance is simplified because now if I
want to change a customer name, I do so in one
place (the customers table) and the change
propagates throughout the entire database (Note in
some cases, such as with historical data, this may
not be what we want, but, because of limited space,
we don't address that issue here)