NORMALIZACIÓN

La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

· Evitar la redundancia de los datos.

· Disminuir problemas de actualización de los datos en las tablas.

· Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

· Cada tabla debe tener su nombre único.

· No puede haber dos filas iguales. No se permiten los duplicados.

· Todos los datos en una columna deben ser del mismo tipo.

TERMINOLOGÍA

· Relación = tabla

· Registro = registro, o tupla

· Atributo = columna o campo

· Clave = llave o código de identificación

· Clave Candidata = superclave mínima

· Clave Primaria = clave candidata elegida

· Clave Externa = clave ajena o clave foránea

· Clave Alternativa = clave secundaria

· Dependencia Multivaluada = dependencia multivalor

· RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.

· 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.

Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo relacional, que constituyen la fuente teórica del modelo de base de datos relacional.

Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominios.

DEPENDENCIAS

Dependencia funcional

B es funcionalmente dependiente de A.

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de DNI tiene una conexión con Apellido o Nombre .

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento Edad

De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener estas dependencias funcionales para lograr la eficiencia en las tablas.

Propiedades de la dependencia funcional

Existen tres axiomas de Armstrong:

Dependencia funcional reflexiva

Si "y" está incluido en "x" entonces x y

A partir de cualquier atributo o conjunto de atributos siempre puede deducirse él mismo. Si la dirección o el nombre de una persona están incluidos en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.

Dependencia funcional Aumentativa

entonces

DNI nombre

DNI,dirección nombre,dirección

Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.

Dependencia funcional transitiva

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces queZ depende transitivamente de X. Simbólicamente sería:

X Y Z entonces X Z

FechaDeNacimiento Edad

Edad Conducir

FechaDeNacimiento Edad Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, una persona necesita ser mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este ejemplo).

"C será un dato simple (dato no primario), B, será un otro dato simple (dato no primario), A, es la llave primaria (PK). Decimos que C dependerá de B y B dependerá funcionalmente de A."

Propiedades deducidas

Unión

y entonces

Pseudo-Transitiva

y entonces

Descomposición

y está incluido en entonces

Claves

Una clave primaria es aquella columna (o conjunto de columnas) que identifica unívocamente a cada fila. La clave primaria es un identificador que va a ser siempre único para cada fila. Se acostumbra a poner la clave primaria como la primera columna de la tabla pero es más una conveniencia que una obligación. Muchas veces la clave primaria es numérica auto-incrementada, es decir, generada mediante una secuencia numérica incrementada automáticamente cada vez que se inserta una fila.

En una tabla puede que tengamos más de una columna que puede ser clave primaria por sí misma. En ese caso se puede escoger una para ser la clave primaria y las demás claves serán claves candidatas.

Una clave ajena (foreign key o clave foránea) es aquella columna que existiendo como dependiente en una tabla, es a su vez clave primaria en otra tabla.

Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que también puede identificar de forma única a una fila dentro de una tabla. Ejemplo: Si en una tabla clientes definimos el número de documento (id_cliente) como clave primaria, el número de seguro social de ese cliente podría ser una clave alternativa. En este caso no se usó como clave primaria porque es posible que no se conozca ese dato en todos los clientes.

Una clave compuesta es una clave que está compuesta por más de una columna.

La visualización de todas las posibles claves candidatas en una tabla ayudan a su optimización. Por ejemplo, en una tabla PERSONA podemos identificar como claves su DNI, o el conjunto de su nombre, apellidos, fecha de nacimiento y dirección. Podemos usar cualquiera de las dos opciones o incluso todas a la vez como clave primaria, pero es mejor en la mayoría de sistemas la elección del menor número de columnas como clave primaria.

FORMAS NORMALES

Diagrama de inclusión de todas las formas normales.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.¹

Segunda Forma Normal (2FN)

Artículo principal: Segunda forma normal

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).

En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que . Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es .

Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente funcional dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.

Tercera Forma Normal (3FN)

Artículo principal: Tercera forma normal

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

Formalmente, un esquema de relación está en 3 Forma Normal Elmasri-Navathe,² si para toda dependencia funcional , se cumple al menos una de las siguientes condiciones:

1. es superllave o clave.

2. es atributo primo de ; esto es, si es miembro de alguna clave en .

Además el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.

Forma normal de Boyce-Codd (FNBC)

Artículo principal: Forma normal de Boyce-Codd

La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave candidata. Deberá registrarse de forma anillada ante la presencia de un intervalo seguido de una formalización perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya planificadas, dejan de existir.

Formalmente, un esquema de relación está en FNBC, si y sólo si, para toda dependencia funcional válida en , se cumple que

1. es superllave o clave.

De esta forma, todo esquema que cumple FNBC, está además en 3FN; sin embargo, no todo esquema que cumple con 3FN, está en FNBC.

Cuarta Forma Normal (4FN)

Artículo principal: Cuarta forma normal

Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.

Quinta Forma Normal (5FN)

Artículo principal: Quinta forma normal

Una tabla se encuentra en 5FN si:

· La tabla está en 4FN

· No existen relaciones de dependencias de reunión (join) no triviales que no se generen desde las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación de dependencia de reunión (join) se encuentra definida por claves candidatas. Por lo que si se aplicara una consulta entre al menos tres relaciones independientes entre sí dentro de la 4FN y se obtuvieran tuplas espurias, entonces no estaría dentro de la 5FN.

EJEMPLO

Id_orden	Fecha	Id_cliente	Nom_cliente	Estado	Num_art	nom_art	cant	Precio
2301	23/02/11	101	Martin	Caracas	3786	Red	3	35,00
2301	23/02/11	101	Martin	Caracas	4011	Raqueta	6	65,00
2301	23/02/11	101	Martin	Caracas	9132	Paq-3	8	4,75
2302	25/02/11	107	Herman	Coro	5794	Paq-6	4	5,00
2303	27/02/11	110	Pedro	Maracay	4011	Raqueta	2	65,00
2303	27/02/11	110	Pedro	Maracay	3141	Funda	2	10,00

Un dato sin normalizar no cumple con ninguna regla de normalización. Para explicar con un ejemplo en qué consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla.

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art, cant, precio)

Ordenes

PRIMERA FORMAL NORMAL (1FN)

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ART, NOM_ART, CANT y PRECIO. La 1FN prohíbe los grupos repetidos, por lo tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son:

· Tenemos que eliminar los grupos repetidos.

· Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.

Los registros quedan ahora conformados en dos tablas que llamaremos ORDENES y ARTICULOS_ORDENES

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado)

Articulos_ordenes (id_orden, num_art, nom_art, cant, precio)

Ordenes

Id_orden	Fecha	Id_cliente	Nom_cliente	Estado
2301	23/02/11	101	Martin	Caracas
2302	25/02/11	107	Herman	Coro
2303	27/02/11	110	Pedro	Maracay

Articulos_ordenes

Id_orden	Num_art	nom_art	cant	Precio
2301	3786	Red	3	35,00
2301	4011	Raqueta	6	65,00
2301	9132	Paq-3	8	4,75
2302	5794	Paq-6	4	5,00
2303	4011	Raqueta	2	65,00
2303	3141	Funda	2	10,00

SEGUNDA FORMAL NORMAL (2FN)

Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir son:

· Determinar cuáles columnas que no son llave no dependen de la llave primaria de la tabla.

· Eliminar esas columnas de la tabla base.

· Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen.

La tabla ORDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN.

Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas PRECIO y NOM_ART son dependientes de NUM_ART, pero no son dependientes de ID_ORDEN. Lo que haremos a continuación es eliminar estas columnas de la tabla ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria de la que dependen.

Las tablas quedan ahora de la siguiente manera.

Articulos_ordenes (id_orden, num_art, cant)

Articulos_ordenes

Id_orden	Num_art	cant
2301	3786	3
2301	4011	6
2301	9132	8
2302	5794	4
2303	4011	2
2303	3141	2

Articulos ( num_art, nom_art, precio)

Articulos

Num_art	nom_art	Precio
3786	Red	35,00
4011	Raqueta	65,00
9132	Paq-3	4,75
5794	Paq-6	5,00
3141	Funda	10,00

TERCERA FORMAL NORMAL (3FN)

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que sea dependiente de otra columna no llave. Los pasos a seguir son:

· Determinar las columnas que son dependientes de otra columna no llave.

· Eliminar esas columnas de la tabla base.

· Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes.

Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTICULOS, como la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ORDENES no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria.

Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ORDENES se muestran a continuación.

ordenes (id_orden, fecha, id_cliente)

Ordenes

Id_orden	Fecha	Id_cliente
2301	23/02/11	101
2302	25/02/11	107
2303	27/02/11	110

Clientes (id_cliente, nom_cliente, estado)

Ordenes

Id_cliente	Nom_cliente	Estado
101	Martin	Caracas
107	Herman	Coro
110	Pedro	Maracay

Por lo tanto la base de datos queda de la siguiente manera:

ordenes (id_orden, fecha, id_cliente)

Clientes (id_cliente, nom_cliente, estado)

Articulos ( num_art, nom_art, precio)

Articulos_ordenes (id_orden, num_art, cant)

RESUMEN

NORMALIZACIÓN

Las bases de datos relacionales se normalizan para:

· Evitar la redundancia de los datos.

· Disminuir problemas de actualización de los datos en las tablas.

· Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

· Cada tabla debe tener su nombre único.

· No puede haber dos filas iguales. No se permiten los duplicados.

· Todos los datos en una columna deben ser del mismo tipo.

DEPENDENCIAS

Dependencia funcional

B es funcionalmente dependiente de A.

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de DNI tiene una conexión con Apellido o Nombre .

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento Edad

De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener estas dependencias funcionales para lograr la eficiencia en las tablas.

Propiedades de la dependencia funcional

Existen tres axiomas de Armstrong:

Dependencia funcional reflexiva

Si "y" está incluido en "x" entonces x y

Dependencia funcional Aumentativa

entonces

DNI nombre

DNI,dirección nombre,dirección

Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.

Dependencia funcional transitiva

Dependencia funcional transitiva.

X Y Z entonces X Z

FechaDeNacimiento Edad

Edad Conducir

FechaDeNacimiento Edad Conducir

"C será un dato simple (dato no primario), B, será un otro dato simple (dato no primario), A, es la llave primaria (PK). Decimos que C dependerá de B y B dependerá funcionalmente de A."

FORMAS NORMALES

Diagrama de inclusión de todas las formas normales.

Primera Forma Normal (1FN)

Artículo principal: Primera forma normal

Una tabla está en Primera Forma Normal si:

· Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son simples e indivisibles.

Segunda Forma Normal (2FN)

Artículo principal: Segunda forma normal

Tercera Forma Normal (3FN)

Artículo principal: Tercera forma normal

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

Forma normal de Boyce-Codd (FNBC)

Artículo principal: Forma normal de Boyce-Codd

Formalmente, un esquema de relación está en FNBC, si y sólo si, para toda dependencia funcional válida en , se cumple que

2. es superllave o clave.

De esta forma, todo esquema que cumple FNBC, está además en 3FN; sin embargo, no todo esquema que cumple con 3FN, está en FNBC.

Cuarta Forma Normal (4FN)

Artículo principal: Cuarta forma normal

Quinta Forma Normal (5FN)

Artículo principal: Quinta forma normal

Una tabla se encuentra en 5FN si:

· La tabla está en 4FN

SUMMARY

STANDARDIZATION

The database normalization is a process of designating and apply a set of rules to relations obtained after the passage of entity-relationship model to relational model.

The relational databases are normalized to:

• Avoid data redundancy.

• Reduce problems updating the data in the tables.

• Protect the data integrity.

In the relational model is often called table to a relationship, but for a table is considered a relationship has to comply with some restrictions:

• Each table must have a unique name.

• There can not be two equal rows. duplicates are not allowed.

• All data in a column must be the same type.

DEPARTMENTS

functional dependence

B is functionally dependent on A.

A functional dependency is a connection between one or more attributes. For example if the value is known DNI has a connection with last name or name.

The functional units of the system are written using an arrow, as follows:

dateOfBirth Age

Normalization (logical) to the (physical or real) implementation can be sugerible have these functional units to achieve efficiency in the tables.

Properties of functional dependence

There are three axioms of Armstrong:

reflective functional dependence

If "and" it is included in "x" then x and

From any attribute or set of attributes you can always be deduced himself. If the address or name of a person are included in the DNI, then with the DNI we can determine the address or name.

Augmentative functional dependence

DNI name

DNI, address, name, address

If the DNI the name of a person the direction is determined, then the DNI plus the name and address is also determined.

Transitive functional dependency

Transitive functional dependency.

Let X, Y, Z three attributes (or groups of attributes) of the same entity. If Y functionally depends on X and Z Y, X but not functionally dependent on Y, then X says Quez transitively depends Symbolically would be:

X Y Z then X Z

dateOfBirth Age

Driving age

Driving Age dateOfBirth

Then we have to dateOfBirth determined and the age determined Driving, indirectly we know through dateOfBirth to Drive (In many countries, a person needs to be over a certain age to drive a car, so this example is used).

"C is a simple data (no primary data), B is another simple fact (not primary data), A is the primary key (PK). We say that C depends on B and B depend functionally A."

NORMAL FORMS

Diagram inclusion of all normal forms.

In general, the first three normal forms are sufficient to meet the needs of most databases. The creator of these first 3 normal forms (or rules) was Edgar F. Codd.1

First Normal Form (1NF)

Main article: First Normal Form

A table is in First Normal Form if:

• All attributes are atomic. An attribute is atomic if the domain elements are simple and indivisible.

Second Normal Form (2NF)

Main article: Second Normal Form

Functional dependence. A relation is in 2NF if it is in 1NF and if the attributes that are not part of any key completely dependent on the primary key. It is that there are no partial dependencies. (All attributes that are not primary key must rely solely on the primary key).

Third Normal Form (3NF)

Main article: Third Normal Form

The table is in 3NF if 2NF and if there is no transitive functional dependency between the attributes that are not key.

An example of this concept would be that a functional dependency X-> Y in a relation schema R is a transitive dependency if there is a set of attributes Z that is not a subset of any key R, where it remains X-> Z and Z-> Y.

Boyce-Codd Normal Form (BCNF)

Main article: Boyce-Codd Normal Form

The table is in BCNF if every determinant attribute that completely determines another, is a key candidate. You must register for Ringed in the presence of an interval followed by a perpetual formalization, ie the variants created in a table they do not show, if already planned, cease to exist.

Formally, a relation schema is in BCNF if and only if for every valid functional dependency, it holds that

2. is superkey or key.

Thus, any scheme that meets BCNF is also in 3NF; however, not all 3NF compliant scheme is in BCNF.

Fourth Normal Form (4NF)

Main article: fourth normal form

A table is in 4NF if and only if for each of its nonfunctional multiple dependencies X -> -> Y, where X is a super-key, X is either a candidate key or set of primary keys.

Quinta Normal Form (5FN)

Main article: Fifth normal form

A table is in 5FN if:

• The table is in 4NF

• There are no meeting dependency relationships (join) nontrivial that are not generated from the keys. A table that is in the 4FN is said in 5FN if and only if every meeting dependency ratio (join) is defined by key candidates. So if a consultation of at least three independent relationships were applied to each other within the 4FN and spurious tuples is obtained, then it would not be within the 5FN.

RECOMENDACIONES

Se debe tener un buen conocimiento sobre este tema de normalización ya que nos ayuda aplicar una serie de reglas en las relaciones obtenidas del modelo entidad relación al modelo relacional.

CONCLUSIONES

Al saber aplicar bien la normalización en una base de datos, esta nos ayudara a evitar la redundancia de datos, disminuirá los problemas de actualización de los datos, y sobre todo ayudara a proteger la integridad de los datos, lo cual nos conllevara a poder realizar y obtener un buen modelamiento en una base de datos.

GLOSARIO

Redundancia: Empleo de palabras innecesarias para expresar una idea o concepto por estar ya expresado con otras palabras o por sobreentenderse sin ellas.

Dominio: Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "cualquier valor de este atributo debe ser elemento del conjunto especificado"

LINKOGRAFÍA

https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos