• Partial Dependency A type of functional dependency where an

Normalization attribute is functionally dependent on only part of the primary key

Normalization is a method for organizing data elements in a database into tables. (primary key must be a composite key).
• Create separate table with the functionally dependent data and the part
Normalization Avoids of the key on which it depends. Tables created at this step will usually
• Duplication of Data – The same data is listed in multiple lines of the contain descriptions of resources.
database Second Normal Form Example
• Insert Anomaly – A record about an entity cannot be inserted into the
table without first inserting information about another entity – Cannot The new table will contain the following fields:
enter a customer without a sales order ItemNo, Description
• Delete Anomaly – A record cannot be deleted without deleting a record All of these fields except the primary key will be removed from the original table.
about a related entity. Cannot delete a sales order without deleting all The primary key will be left in the original table to allow linking of data:
of the customer’s information. SalesOrderNo, ItemNo, Qty, UnitPrice
• Update Anomaly – Cannot update information without changing Never treat price as dependent on item. Price may be different for different sales
information in many places. To update customer information, it must orders (discounts, special customers, etc.)
be updated for each sales order the customer has placed Along with the unchanged table below, these tables make up a database in second
normal form:
Normalization is a three stage process – After the first stage, the data is said to be SalesOrderNo, Date, CustomerNo, CustomerName, CustomerAdd,
in first normal form, after the second, it is in second normal form, after the third, it ClerkNo, ClerkName
is in third normal form What if we did not Normalize the Database to Second Normal Form?
Before Normalization
• Repetition of Data – Description would appear every time we had an
1. Begin with a list of all of the fields that must appear in the database. Think order for the item
of this as one big table. • Delete Anomalies – All information about inventory items is stored in
2. Do not include computed fields the SalesOrderDetail table. Delete a sales order, delete the item.
3. One place to begin getting this information is from a printed document used • Insert Anomalies – To insert an inventory item, must insert sales order.
by the system. • Update Anomalies – To change the description, must change it on
4. Additional attributes besides those for the entities described on the document every SO.
can be added to the database.
Normalization: Third Normal Form
Before Normalization – Example
• Remove transitive dependencies.
See Sales Order from below:
• Transitive Dependency A type of functional dependency where an
attribute is functionally dependent on an attribute other than the
S a le s O r d e r primary key. Thus its value is only indirectly determined by the
primary key.
• Create a separate table containing the attribute and the fields that are
F ic tio n C o m p a n y functionally dependent on it. Tables created at this step will usually
2 0 2 N . M a in contain descriptions of either resources or agents. Keep a copy of the
M a h a tta n , K S 6 6 5 0 2 key attribute in the original file.

C u s to m e r N u m b e1r0:0 1 S a le s O rd e r N u m b e r: 4 0 5 Third Normal Form Example

C u s to m e r N a m e A: B C C o m p a n y S a le s O rd e r D a te : 2 /1 /2 0 0 0 The new tables would be:
C u s to m e r A d d re1ss0 :0 P o in ts C le r k N u m b e r: 210 CustomerNo, CustomerName, CustomerAdd
M a n h a tta n , K S 6 6 5 0 2 C le r k N a m e : M a rtin L a w re n c e
ClerkNo, ClerkName
All of these fields except the primary key will be removed from the original table.
It e m O rd e reDde sc rip t io n Q u a n t ityU n it P ric eT o ta l The primary key will be left in the original table to allow linking of data as
800 w id g it s m a ll 40 6 0 .0 0 2 ,4 0 0 .0 0 follows:
801 t in g im a jig g e r 20 2 0 .0 0 4 0 0 .0 0 SalesOrderNo, Date, CustomerNo, ClerkNo
805 t h in g ib o b 10 1 0 0 .0 0 1 ,0 0 0 .0 0 Together with the unchanged tables below, these tables make up the database in
third normal form.
ItemNo, Description
SalesOrderNo, ItemNo, Qty, UnitPrice
What if we did not Normalize the Database to Third Normal Form?
• Repetition of Data – Detail for Cust/Clerk would appear on every SO
3 ,8 0 0 .0 0 • Delete Anomalies – Delete a sales order, delete the customer/clerk
O r d e r T o ta l
• Insert Anomalies – To insert a customer/clerk, must insert sales order.
Fields in the original data table will be as follows: • Update Anomalies – To change the name/address, etc, must change it
SalesOrderNo, Date, CustomerNo, CustomerName, CustomerAdd, on every SO.
ClerkNo, ClerkName, ItemNo, Description, Qty, UnitPrice Completed Tables in Third Normal Form
Think of this as the baseline – one large table
Customers: CustomerNo, CustomerName, CustomerAdd
Normalization: First Normal Form Clerks: ClerkNo, ClerkName
• Separate Repeating Groups into New Tables. Inventory Items: ItemNo, Description
Sales Orders: SalesOrderNo, Date, CustomerNo, ClerkNo
• Repeating Groups Fields that may be repeated several times for one SalesOrderDetail: SalesOrderNo, ItemNo, Qty, UnitPrice
document/entity
• Create a new table containing the repeating data
• The primary key of the new table (repeating group) is always a
composite key; Usually document number and a field uniquely
describing the repeating line, like an item number.
First Normal Form Example
The new table is as follows:
SalesOrderNo, ItemNo, Description, Qty, UnitPrice
The repeating fields will be removed from the original data table, leaving the
following.
SalesOrderNo, Date, CustomerNo, CustomerName, CustomerAdd,
ClerkNo, ClerkName
These two tables are a database in first normal form
What if we did not Normalize the Database to First Normal Form?
Repetition of Data – SO Header data repeated for every line in sales order.
Normalization: Second Normal Form
• Remove Partial Dependencies.
• Functional Dependency The value of one attribute in a table is
determined entirely by the value of another.
 [edit]Logical Modeling Benefits

Logical data model

From Wikipedia, the free encyclopedia  Clarifies functional specifications and avoids assumption

A logical data model (LDM) in systems engineering is a representation of an  Confirms business requirements
organization's data, organized in terms entities and relationships and is independent
of any particular data management technology.
 Facilitates business process improvement

Overview
 Focuses on requirements independent of technology
 Decreases system development time and cost
Logical data models represent the abstract structure of some domain of information.
They are often diagrammatic in nature and are most typically used in business
 Becomes a template for the enterprise
processes that seek to capture things of importance to an organization and how they  Facilitates data re-use and sharing
relate to one another. Once validated and approved, the logical data model can
become the basis of a physical data model and inform the design of a database.  Faster ROI

Logical data models should be based on the structures identified in a  Gathers metadata
preceding conceptual data model, since this describes the semantics of the
information context, which the logical model should also reflect. Even so, since the
 Foster seamless communication between applications
logical data model anticipates implementation on a specific computing system, the  Focuses communication for data analysis and project team members
content of the logical data model is adjusted to achieve certain efficiencies.
 Establishes a consistent naming scheme
The term 'Logical Data Model' is sometimes used as a synonym of 'Domain Model' or
as an alternative to the domain model. While the two concepts are closely related,
and have overlapping goals, a domain model is more focused on capturing the [edit]Logical & Physical Data Model
concepts in the problem domain rather than the structure of the data associated with
Logical data models are sometimes incorrectly called a "physical data model", which
that domain.
is not what the ANSI people had in mind. The physical design of a database involves
History deep use of particular database management technology. For example, a
table/column design could be implemented on a collection of computers, located in
different parts of the world. That is the domain of the physical model.
When ANSI first laid out the idea of a logical schema in 1975[2] , the choices
were hierarchical and network. The relational model – where data is described in People often get confused with the fact that logical and physical data models are very
terms of tables and columns – had just been recognized as a data organization theory different in their objectives, goals and content. Following are some key differences.
but no software existed to support that approach. Since that time, anobject-
oriented approach to data modelling – where data is described in terms of classes,
attributes, and associations – has also been introduced.
Logical Data Model Physical Data Model

Includes entities/tables, Includes tables, columns, keys, data types, validation

attributes/columns/fields and rules, database triggers, stored procedures, domains, and
relationships access constraints

Uses business names for Uses abbreviated column names limited by the database
attributes management system (DBMS)

Is independent of technology
Includes primary keys and indices for fast data access.
(platform, DBMS)

May be de-normalized to meet performance

requirements based on the nature of the database. If the
Is normalized to fourth normal nature of the database is Online Transaction
form Processing(OLTP) or Operational Data Store (ODS) it is
usually not de-normalized. De-normalization is common
in Datawarehouses.

The ANSI/SPARC three level architecture, which "shows that a data model can
be an external model (or view), a conceptual model, or a physical
model. This is not the only way to look at data models, but it is a useful
way, particularly when comparing models".[

Logical data model topics

[edit]Why Build Logical Data Model

 Helps common understanding of business data elements and

requirements
 Provides foundation for designing a database
 Facilitates avoidance of data redundancy and thus prevent data &
business transaction inconsistency
 Facilitates data re-use and sharing
 Decreases development and maintenance time and cost
 Confirms a logical process model and helps impact analysis.