Scribd
Upload
9 views15 pages

Lecture 6

The document discusses database normalization, specifically focusing on the First Normal Form (1NF), which requires tables to contain only atomic values and no repeating groups. It outlines the rules for achieving 1NF, such as ensuring unique rows and fields, and provides examples of unnormalized tables and how to correct them. Additionally, it introduces the concept of functional dependency, explaining how the value in one field can determine the value in another.

Uploaded by

kbjoash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
9 views15 pages

Lecture 6

The document discusses database normalization, specifically focusing on the First Normal Form (1NF), which requires tables to contain only atomic values and no repeating groups. It outlines the rules for achieving 1NF, such as ensuring unique rows and fields, and provides examples of unnormalized tables and how to correct them. Additionally, it introduces the concept of functional dependency, explaining how the value in one field can determine the value in another.

Uploaded by

kbjoash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

Database Systems

Normalisation – First Normal


Form
Solving Data Problems

 Database design theory includes design standards


called normal forms.
 The process of making your data and tables match
these standards is called normalizing data or data
normalization. By normalizing your data, you eliminate
redundant information and organize your table to make
it easier to manage the data and make future changes
to the table and database structure.
 This process removes the insertion, deletion, and
modification anomalies you may see. In normalizing
your data, you usually divide large tables into smaller,
easier to maintain tables. You can then use the
technique of adding foreign keys to enable connections
between the tables.
 Data normalization is part of the database design
process and is not specific nor unique to any
particular RDBMS.
 There are, in order, first, second, third, Boyce-Codd,
fourth, and fifth normal forms.
 Each normal form represents an increasingly
stringent set of rules; that is, each normal form
assumes that the requirements of the preceding
forms have been met.
 Many relational database designers feel that, if their
tables are in third normal form, most common
design problems have been addressed.
First Normal Form (INF)

 A database is in first normal form if it satisfies the


following conditions:
 Contains only atomic values
 There are no repeating groups
 An atomic value is a value that cannot be divided.
 For a database to be in 1NF, the following rules have
to be met for each table in the database
1NF Rules

 There are no columns with repeated or similar data


 Each data item cannot be broken down any further
 Each row is unique i.e it has a primary key
 Each field has a unique name
 How do we bring an unnormalized table into first
normal form? Consider the following example:
Example 1

 This table is not in first normal form because the


[Color] column can contain multiple values. For
example, the first row includes values "red" and
"green."
 To bring this table to first normal form, we split the
table into two tables and now we have the resulting
tables:
Example 2
EMPLOYEES_PROJECTS_TIME

So why is this one a problem?


If an employee was assigned to a fourth project,
you would have to add two new fields to the
table.
Also, it would be very difficult to total the amount
of time devoted to a particular project.
The design problems addressed are very
common-particularly among new designers who
are customed to tracking data in a spreadsheet.
Often, when building a spreadsheet, we arrange
the data horizontally, laying it out across the
spreadsheet.
When designing tables, we have to think more
vertically. Similar data belongs in the same
column or field with a single value in each row.
EMPLOYEES

EmployeeID Last Name First Name


EN1-26 O'Brien Sean
EN1-33 Guya Amy
EN1-35 Baranco Steven
EN1-36 Roslyn Elizabeth
EN1-38 Schaaf Carol
EN1-40 Wing Alexandra
PROJECTS_EMPLOYEES_TIME

ProjectNum EmployeeID Time


30-328-TC EN1-33 0.35
30-452-T3 EN1-26 0.25
30-452-T3 EN1-33 0.05
30-452-T3 EN1-35 0.15
31-238-TC EN1-35 0.80
30-457-T3 EN1-26 0.40
31-238-TC EN1-40 0.20
31-241-TC EN1-40 0.70
32-244-T3 EN1-33 0.60
35-152-TC EN1-36 0.90
36-272-TC EN1-38 0.75
Functional Dependency
A functional dependency is a relationship between fields so that the value in Field A determines the
value in Field B,
and there can be only one value in Field B.
In that case, Field B is functionally dependent on Field A.
Consider the following sample table:

Airport City
National Washington, DC
JFK New York
LaGuardia New York
Logan Boston
Dulles Washington, DC
Each airport name is unique and each airport can be in only one
city.
Therefore, City is functionally dependent on Airport.
The value in the Airport field determines what the value will be
in the City field (making Airport the determinant field) and there
can be only one value in the City field.
This does not need to work in the reverse.
As shown in the table, a city can have more than one airport, so
Airport is not functionally dependent on City;
the value in City does not necessarily determine what the value
in Airport will be.
You will sometimes see a functional dependency written in this
format:
Determinant field(s) >> Functionally dependent field
as in:
Airport >> City

You might also like