Oracle Normalization

Name Description
An entity is in First Normal Form (1NF) when all tables are two-dimensional
with no repeating groups.

A row is in first normal form (1NF) if all underlying domains contain atomic
values only. 1NF eliminates repeating groups by putting each into a separate
table and connecting them with a one-to-many relationship. Make a separate
First Normal Form table for each set of related attributes and uniquely identify each record with a
primary key.
• Eliminate duplicative columns from the same table.

• Create separate tables for each group of related data and identify
each row with a unique column or set of columns (the primary key).
An entity is in Second Normal Form (2NF) when it meets the requirement of
being in First Normal Form (1NF) and additionally:
• Does not have a composite primary key. Meaning that the primary key
can not be subdivided into separate logical entities.
• All the non-key columns are functionally dependent on the entire
primary key.
Second Normal
• A row is in second normal form if, and only if, it is in first normal form
Form
and every non-key attribute is fully dependent on the key.

• 2NF eliminates functional dependencies on a partial key by putting the

fields in a separate table from those that are dependent on the whole
key. An example is resolving many:many relationships using an
intersecting entity.
An entity is in Third Normal Form (3NF) when it meets the requirement of
being in Second Normal Form (2NF) and additionally:
• Functional dependencies on non-key fields are eliminated by putting
them in a separate table. At this level, all non-key fields are dependent
on the primary key.
Third Normal Form
• A row is in third normal form if and only if it is in second normal form
and if attributes that do not contribute to a description of the primary
key are move into a separate table. An example is creating look-up
tables.
Boyce Codd Normal Form (BCNF) is a further refinement of 3NF. In his later
writings Codd refers to BCNF as 3NF. A row is in Boyce Codd normal form if,
and only if, every determinant is a candidate key. Most entities in 3NF are
already in BCNF.
Boyce-Codd
Normal Form BCNF covers very specific situations where 3NF misses inter-dependencies
between non-key (but candidate key) attributes. Typically, any relation that is
in 3NF is also in BCNF. However, a 3NF relation won't be in BCNF if (a) there
are multiple candidate keys, (b) the keys are composed of multiple attributes,
and (c) there are common attributes between the keys.
Fourth Normal An entity is in Fourth Normal Form (4NF) when it meets the requirement of
Form being in Third Normal Form (3NF) and additionally:
• Has no multiple sets of multi-valued dependencies. In other words,
 4NF states that no entity can have more than a single one-to-many
relationship within an entity if the one-to-many attributes are
independent of each other.

• Many:many relationships are resolved independently.

An entity is in Fifth Normal Form (5NF) if, and only if, it is in 4NF and every
Fifth Normal Form
join dependency for the entity is a consequence of its candidate keys.

Oracle Codd's 12 Rules

All information in a relational database is represented explicitly

Rule 1: The Information
at the logical level and in exactly one way - by values in tables.
Each and every datum (atomic value) in a relational database is
guaranteed to be logically accessible by resorting to a
Rule 2: Guaranteed Access
combination of table name, primary key value, and column
name.
Null values (distinct from the empty character string of blank
Rule 3: Systematic Treatment of characters and distinct from any zero or other numbers) are
Null Values supported in fully relational DBMS for representing missing
information and inapplicable information in a systematic way.
The database description is represented at the logical level in
Rule 4: Dynamic Online Catalog the same way as ordinary data, so that authorized users can
Based on the Relational Model apply the same relational language to its interrogation as they
apply to the regular data.
A relational system may support several languages and various
Rule 5: Comprehensive Data modes of terminal use (for example, the fill-in-the-blanks
Sub-language mode). However, there must be at least one language whose
statements are expressible, per some well-defined syntax, as
character strings, that is comprehensive in supporting all of the
following items:
• Data Definition
• View Definition
• Data manipulation (interactive and by program)
• Integrity Constraints
• Authorization

• Transaction boundaries (begin, commit, and rollback)

All views that are theoretically updateable are also updateable
Rule 6: View Updating
by the system.
The capability of handling a base relation or a derived relation
Rule 7: High-Level Insert, Update,
as a single operand applies not only to the retrieval of data but
and Delete
also to the insertion, update, and deletion of data.
Rule 8: Physical Data Application programs and terminal activities remain logically
Independence unimpaired whenever any changes are made in either storage
 representations or access methods.
Application programs and terminal activities remain logically
Rule 9: Logical Data unimpaired when information-preserving changes of any kind
Independence that theoretically permit unimpairment are made to the base
tables.
Integrity constraints specific to a particular relational database
Rule 10: Integrity Independence must be definable in the relational data sub-language and
storable in the catalog, not in the application programs.
Rule 11: Distribution
A relational DBMS has distribution dependence.
Independence
If a relational system has a low-level (single record at a time)
language, that low level cannot be used to subvert or bypass
Rule 12: Nonsubversion
the integrity rules and constraints expressed in the higher-level
relational language (multiple records at a time).