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
Rule 2: Guaranteed Access
Rule 3: Systematic Treatment of
Null Values
Rule 4: Dynamic Online Catalog
Based on the Relational Model
Rule 5: Comprehensive Data
Sub-language
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
combination of table name, primary key value, and column
name.
Null values (distinct from the empty character string of blank
characters and distinct from any zero or other numbers) are
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
the same way as ordinary data, so that authorized users can
apply the same relational language to its interrogation as they
apply to the regular data.
A relational system may support several languages and various
modes of terminal use (for example, the fill-in-the-blanks
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

Rule 9: Logical Data
Independence
Rule 10: Integrity Independence
Rule 11: Distribution
Independence
Rule 12: Nonsubversion
representations or access methods.
Application programs and terminal activities remain logically
unimpaired when information-preserving changes of any kind
that theoretically permit unimpairment are made to the base
tables.
Integrity constraints specific to a particular relational database
must be definable in the relational data sub-language and
storable in the catalog, not in the application programs.
A relational DBMS has distribution dependence.
If a relational system has a low-level (single record at a time)
language, that low level cannot be used to subvert or bypass
the integrity rules and constraints expressed in the higher-level
relational language (multiple records at a time).