NORMALIZACIÒN
Técnica para diseñar la estructura lógica de los datos de un sistema de información
en el modelo relacional, desarrollada por E. F. Codd en 1972.
Al tener las tablas ya relacionadas se deben de aplicar reglas de
normalización de todas las tablas.
• Las bases de datos relacionales se normalizan para:
• Evitar la redundancia de datos.
• Evitar problemas de actualización de los datos en las
tablas.
• Proteger la integridad de los datos.
Siempre que se diseña un
sistema no solo una base
de datos, si no también
cualquier tipo de solución
informática, se ha de
medir la calidad de la
misma, y sino cumple
determinados criterios de
calidad, hay que realizar,
de forma iterativa,
sucesivos refinamiento en
el diseño., para alcanzar la
calidad deseada.
Uno de los parámetros que
mide la calidad de una
base de datos es la forma
normal en la que se
encuentra su diseño. Esta
forma normal puede
alcanzarse cumpliendo
ciertas restricciones que
imponen cada forma
normal al conjunto de
atributos de un diseño.
El proceso de obligar a los
atributos de un diseño
cumplir ciertas formas
normales se llama
NORMALIZACIÒN.
Refinamiento de un diseño de base de datos
CONCEPTUALIZACIÒN
La normalización es el proceso
mediante el cual se transforman
datos complejos a un conjunto
de estructuras de datos más
pequeñas, que además de ser
más simples y más estables, son
más fáciles de mantener.
También se puede entender la
normalización como una serie
de reglas que sirven para
ayudar a los diseñadores de
bases de datos a desarrollar un
esquema que minimice los
problemas de lógica.
La normalización se adoptó
porque el viejo estilo de poner
todos los datos en un solo lugar,
como un archivo o una tabla
de la base de datos, era
ineficiente y conducía a errores
de lógica cuando se trataban
de manipular los datos
El proceso de normalización
tiene un nombre y una serie de
reglas para cada fase. Esto
puede parecer un poco
confuso al principio, pero poco
a poco se va entendiendo el
proceso, así como las razones
para hacerlo de esta manera.
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 columna 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.
Dependencia funcional
Relación
entre
atributos de
una misma
tabla.
Si x e y son atributos de la relación R, se dice que y es
funcionalmente dependiente de x (se denota por x → y) si cada
valor de x tiene asociado un solo valor de y (x e y pueden constar
de uno o varios atributos).
A x se le denomina determinante, ya que x determina el valor de
y. Se dice que el atributo y es completamente dependiente de x
si depende funcionalmente de x y no depende de ningún
subconjunto de x.
La dependencia funcional es una noción semántica. Si hay o no
dependencias funcionales entre atributos no lo determina una serie
abstracta de reglas, sino, más bien, los modelos mentales del usuario y
las reglas de negocio de la organización o empresa para la que se
desarrolla el sistema de información. Cada dependencia funcional es
una restricción y representa una relación de uno a muchos (o de uno a
uno).
Dependencia funcional
En el proceso de normalización se debe
ir comprobando que cada tabla
cumple una serie de reglas que se
basan en la clave primaria y las
dependencias funcionales. Cada regla
que se cumple aumenta el grado de
normalización. Si una regla no se
cumple, la tabla se debe descomponer
en varias tablas que sí la cumplan.
La normalización se lleva a cabo en una
serie pasos. Cada paso corresponde a
una forma normal que tiene unas
propiedades. Conforme se va
avanzando en la normalización, las
tablas tienen un formato más estricto
(más fuerte) y, por lo tanto, son menos
vulnerables a las anomalías de
actualización.
El modelo relacional sólo requiere un
conjunto de tablas en primera forma
normal (en caso contrario no se pueden
implementar). Las restantes formas
normales son opcionales. Sin embargo,
para evitar las anomalías de
actualización, es recomendable llegar
al menos a la tercera forma normal.
(Y no depende de X)
Ejemplo 1
PRODUCTOS (CódigoProducto, Nombre,
Fabricante, País)
CódigoProducto Fabricante
Fabricante → País
CódigoProducto - → País, es decir,
CódigoProducto depende transitivamente
de País
Ejemplo 2:
PRODUCTOS (CódigoProducto,
Nombre, Fabricante, País)
CódigoProducto Nombre
Nombre → CódigoProducto
CódigoProducto - → Nombre
FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas norlames
Primera Forma Normal 1FN
•Una tabla está en primera forma normal
(1FN) si, y sólo si, todos los dominios de sus
atributos contienen valores atómicos, es
decir, no hay grupos repetitivos. Un grupo
repetitivo es un atributo que puede tener
múltiples valores para cada fila de la
relación.
Si se tiene la relación Alumnos con los siguientes campos:
codigo_alum, nombre_alum y asignaturas_alum, de los
cuales el campo asignaturas_alum, almacena las
asignaturas en las que recibe clases cada alumno.
Se observa en la relación Alumnos, los registros dos y tres
tienen dominios que contienen varios valores por tanto la
relación no se encuentra en primera forma normal. Para
convertir esta relación en la primera forma normal se crea
una nueva relación Asignatura, en donde cada asignatura
responderá a una clave principal.
Ejemplo
FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Segunda Forma Normal 2FN
•Una tabla está en segunda forma normal
(2FN) si, y sólo si, está en 1FN y, además, cada
atributo que no forma parte de la clave
primaria es completamente dependiente de
la clave primaria.
•La 2FN se aplica a las tablas que tienen claves
primarias compuestas por dos o más atributos.
Si una tabla está en 1FN y su clave primaria es
simple (tiene un solo atributo), entonces
también está en 2FN.
•Las tablas que no están en 2FN pueden sufrir
anomalías cuando se realizan actualizaciones
sobre ellas.
Ejemplo
la relación Pedidos ya se encuentra en su segunda forma normal
inicialmente por el hecho de estar en primera forma normal y contar
como clave principal con un único atributo
Mientras que en lo que respecta a la relación denominada
Linea_pedidos, para que logre estar en su segunda forma normal se
deberá verificar que todos sus atributos que no son considerados
clave, como lo son la descrip_art, cantidad_art y pvp_art, respondan
completamente a la clave principal, por lo tanto, lo siguiente quiere
decir que deben tener totalmente una dependencia funcional con
relación al par de atributos (codigo_ped, codigo_art):
(codigo_ped, codigo_art) ⇒ Descrip_art
(codigo_ped, codigo_art) ⇒ cantidad_art
(codigo_ped, codigo_art) ⇒ pvp_art
Ejemplo
Primera dependencia funcional total: No es verdadera ya que la descripción del
artículo responde únicamente al código del mismo y no al código del pedido que lo
solicita, por ende, es considerada como verdadera la dependencia parcial entre
codigo_art → descrip_art. Por este motivo se puede asegurar que la relación
Linea_pedidos no se encuentra en su segunda forma normal.
Segunda dependencia funcional total: Es considerada como verdadera ya que la
cantidad que es solicitada de un artículo por un pedido no está determinada
únicamente por el pedido con el que se está tratando o el artículo que es
requerido, sino por los dos. Es decir que se tendría lo siguiente codigo_ped →
cantidad_art, puesto que en un pedido sería posible solicitar varias y distintas
cantidades de artículos el que se está tratando o el artículo que es requerido, sino
por los dos. Es decir que se tendría lo siguiente codigo_ped → cantidad_art, puesto
que en un pedido sería posible solicitar varias y distintas cantidades de artículos.
Tercera dependencia funcional total: Es considerada verdadera cuando los valores
correspondientes a los artículos no son siempre los mismos para los pedidos. Es
común que el valor de cada artículo sea el mismo para todos y cada uno de los
clientes, es por esto que se comprueba la dependencia funcional codigo_art →
pvp_art, motivo por el cual tampoco se cumple que aquel atributo que no es clave
pvp_art vaya totalmente a depender de la clave, lo cual indicaría otra razón para
que la relación no se encuentre en su segunda forma normal. Otra manera de
observar cuando una relación se encuentra en su segunda forma normal es
examinando su diagrama de dependencias funcionales.
FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Tercera Forma Normal 3FN
•Una tabla está en tercera forma normal (3FN) si, y sólo si, está en
2FN y, además, cada atributo que no forma parte de la clave
primaria no depende transitivamente de la clave primaria. La
dependencia x −→ z es transitiva si existen las dependencias x
−→ y, y −→ z, siendo x, y, z atributos o conjuntos de atributos de
una misma tabla.
•La tercera forma normal se fundamenta del concepto de
dependencia transitiva, por lo tanto, se dice que una relación
está en tercera forma normal solo si sus atributos dependen
únicamente a la clave principal mas no de otros atributos.
•Para renunciar a las dependencias transitivas se debe descartar
de la relación que no se encuentra en tercera forma normal el
atributo que genera la dependencia transitiva y se crea una
relación que contenga los atributos transitivos conjuntamente
con el atributo del que requiere es decir mediante el cual
conserva su transitividad.
PRODUCTOS (CódigoProducto, Nombre, Fabricante, País).
CódigoProducto → Fabricante
Fabricante → País
CódigoProducto - -/→País
País depende transitivamente de CódigoProducto, por tanto, no está en
tercera
forma normal.
FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Forma normal de Boyce/Codd
• Una tabla está en la forma normal de Boyce–Codd
(BCFN) si, y sólo si, todo determinante es una clave
candidata.
• La 2FN y la 3FN eliminan las dependencias parciales y las
dependencias transitivas de la clave primaria. Pero este
tipo de dependencias todavía pueden existir sobre otras
claves candidatas, si éstas existen. La BCFN es más fuerte
que la 3FN, por lo tanto, toda tabla en BCFN está en 3FN.
• La violación de la BCFN es poco frecuente ya que se da
bajo ciertas condiciones que raramente se presentan.
• Se debe comprobar si una tabla viola la BCFN si tiene
dos o más claves candidatas compuestas que tienen al
menos un atributo en común.
NOTAS (DNIAlumno, DNIProfesor,NombreProfesor, Nota)
DNIProfesor → NombreProfesor
NombreProfesor → DNIProfesor
DNIProfesor,DNIAlumno → Nota
En este caso, la tabla está en 3FN porque no hay dependencias funcionales
transitivas, y sin embargo no está en FNBC porque NombreProfesor y DNI
Profesor son implicantes, y no son claves candidatas. Para obtener la tabla en
FNBC habría que quitar de la tabla los atributos DNIProfesor y NombreProfesor.
FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Otras formas normales
• Existen más formas normales (FN4, FN5, FNDK, FN6...)
• Las formas normales 4 y 5, se ocupan de las
dependencias entre atributos multivaluados, la Forma
Normal Dominio Clave (FNDK) trata las restricciones y los
dominios de los atributos, y finalmente la FN6 trata ciertas
consideraciones con las bases de datos temporales.
Referentes
• López, I, Castellano, M. y Ospino, J. (2013). Bases de datos. Desarrollo de aplicaciones
multiplataforma y web DAM y DAW. Elfaomega, México.
• Marqués, M. (2009). Bases de datos. [Material online]. Departamento de Ingeniería y Ciencia de la
Computación, UNIVERSITAT JAUME I DE CASTELLÓ. España.
• Zea, M., Honores, J. y Rivas, W. (2015). Fundamentos de base de datos. Ediciones utmach, Ecuador.

Normalizacion

  • 1.
    NORMALIZACIÒN Técnica para diseñarla estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972.
  • 2.
    Al tener lastablas ya relacionadas se deben de aplicar reglas de normalización de todas las tablas. • Las bases de datos relacionales se normalizan para: • Evitar la redundancia de datos. • Evitar problemas de actualización de los datos en las tablas. • Proteger la integridad de los datos.
  • 3.
    Siempre que sediseña un sistema no solo una base de datos, si no también cualquier tipo de solución informática, se ha de medir la calidad de la misma, y sino cumple determinados criterios de calidad, hay que realizar, de forma iterativa, sucesivos refinamiento en el diseño., para alcanzar la calidad deseada. Uno de los parámetros que mide la calidad de una base de datos es la forma normal en la que se encuentra su diseño. Esta forma normal puede alcanzarse cumpliendo ciertas restricciones que imponen cada forma normal al conjunto de atributos de un diseño. El proceso de obligar a los atributos de un diseño cumplir ciertas formas normales se llama NORMALIZACIÒN.
  • 4.
    Refinamiento de undiseño de base de datos
  • 5.
    CONCEPTUALIZACIÒN La normalización esel proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera. 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 columna 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.
  • 6.
    Dependencia funcional Relación entre atributos de unamisma tabla. Si x e y son atributos de la relación R, se dice que y es funcionalmente dependiente de x (se denota por x → y) si cada valor de x tiene asociado un solo valor de y (x e y pueden constar de uno o varios atributos). A x se le denomina determinante, ya que x determina el valor de y. Se dice que el atributo y es completamente dependiente de x si depende funcionalmente de x y no depende de ningún subconjunto de x. La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre atributos no lo determina una serie abstracta de reglas, sino, más bien, los modelos mentales del usuario y las reglas de negocio de la organización o empresa para la que se desarrolla el sistema de información. Cada dependencia funcional es una restricción y representa una relación de uno a muchos (o de uno a uno).
  • 7.
    Dependencia funcional En elproceso de normalización se debe ir comprobando que cada tabla cumple una serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple aumenta el grado de normalización. Si una regla no se cumple, la tabla se debe descomponer en varias tablas que sí la cumplan. La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las tablas tienen un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un conjunto de tablas en primera forma normal (en caso contrario no se pueden implementar). Las restantes formas normales son opcionales. Sin embargo, para evitar las anomalías de actualización, es recomendable llegar al menos a la tercera forma normal.
  • 8.
    (Y no dependede X) Ejemplo 1 PRODUCTOS (CódigoProducto, Nombre, Fabricante, País) CódigoProducto Fabricante Fabricante → País CódigoProducto - → País, es decir, CódigoProducto depende transitivamente de País Ejemplo 2: PRODUCTOS (CódigoProducto, Nombre, Fabricante, País) CódigoProducto Nombre Nombre → CódigoProducto CódigoProducto - → Nombre
  • 9.
    FORMAS NORMALES •Primera forma normal •Segundaforma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas norlames Primera Forma Normal 1FN •Una tabla está en primera forma normal (1FN) si, y sólo si, todos los dominios de sus atributos contienen valores atómicos, es decir, no hay grupos repetitivos. Un grupo repetitivo es un atributo que puede tener múltiples valores para cada fila de la relación.
  • 11.
    Si se tienela relación Alumnos con los siguientes campos: codigo_alum, nombre_alum y asignaturas_alum, de los cuales el campo asignaturas_alum, almacena las asignaturas en las que recibe clases cada alumno. Se observa en la relación Alumnos, los registros dos y tres tienen dominios que contienen varios valores por tanto la relación no se encuentra en primera forma normal. Para convertir esta relación en la primera forma normal se crea una nueva relación Asignatura, en donde cada asignatura responderá a una clave principal. Ejemplo
  • 12.
    FORMAS NORMALES •Primera forma normal •Segundaforma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Segunda Forma Normal 2FN •Una tabla está en segunda forma normal (2FN) si, y sólo si, está en 1FN y, además, cada atributo que no forma parte de la clave primaria es completamente dependiente de la clave primaria. •La 2FN se aplica a las tablas que tienen claves primarias compuestas por dos o más atributos. Si una tabla está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. •Las tablas que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones sobre ellas.
  • 13.
    Ejemplo la relación Pedidosya se encuentra en su segunda forma normal inicialmente por el hecho de estar en primera forma normal y contar como clave principal con un único atributo Mientras que en lo que respecta a la relación denominada Linea_pedidos, para que logre estar en su segunda forma normal se deberá verificar que todos sus atributos que no son considerados clave, como lo son la descrip_art, cantidad_art y pvp_art, respondan completamente a la clave principal, por lo tanto, lo siguiente quiere decir que deben tener totalmente una dependencia funcional con relación al par de atributos (codigo_ped, codigo_art): (codigo_ped, codigo_art) ⇒ Descrip_art (codigo_ped, codigo_art) ⇒ cantidad_art (codigo_ped, codigo_art) ⇒ pvp_art
  • 14.
    Ejemplo Primera dependencia funcionaltotal: No es verdadera ya que la descripción del artículo responde únicamente al código del mismo y no al código del pedido que lo solicita, por ende, es considerada como verdadera la dependencia parcial entre codigo_art → descrip_art. Por este motivo se puede asegurar que la relación Linea_pedidos no se encuentra en su segunda forma normal. Segunda dependencia funcional total: Es considerada como verdadera ya que la cantidad que es solicitada de un artículo por un pedido no está determinada únicamente por el pedido con el que se está tratando o el artículo que es requerido, sino por los dos. Es decir que se tendría lo siguiente codigo_ped → cantidad_art, puesto que en un pedido sería posible solicitar varias y distintas cantidades de artículos el que se está tratando o el artículo que es requerido, sino por los dos. Es decir que se tendría lo siguiente codigo_ped → cantidad_art, puesto que en un pedido sería posible solicitar varias y distintas cantidades de artículos. Tercera dependencia funcional total: Es considerada verdadera cuando los valores correspondientes a los artículos no son siempre los mismos para los pedidos. Es común que el valor de cada artículo sea el mismo para todos y cada uno de los clientes, es por esto que se comprueba la dependencia funcional codigo_art → pvp_art, motivo por el cual tampoco se cumple que aquel atributo que no es clave pvp_art vaya totalmente a depender de la clave, lo cual indicaría otra razón para que la relación no se encuentre en su segunda forma normal. Otra manera de observar cuando una relación se encuentra en su segunda forma normal es examinando su diagrama de dependencias funcionales.
  • 15.
    FORMAS NORMALES •Primera forma normal •Segundaforma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Tercera Forma Normal 3FN •Una tabla está en tercera forma normal (3FN) si, y sólo si, está en 2FN y, además, cada atributo que no forma parte de la clave primaria no depende transitivamente de la clave primaria. La dependencia x −→ z es transitiva si existen las dependencias x −→ y, y −→ z, siendo x, y, z atributos o conjuntos de atributos de una misma tabla. •La tercera forma normal se fundamenta del concepto de dependencia transitiva, por lo tanto, se dice que una relación está en tercera forma normal solo si sus atributos dependen únicamente a la clave principal mas no de otros atributos. •Para renunciar a las dependencias transitivas se debe descartar de la relación que no se encuentra en tercera forma normal el atributo que genera la dependencia transitiva y se crea una relación que contenga los atributos transitivos conjuntamente con el atributo del que requiere es decir mediante el cual conserva su transitividad. PRODUCTOS (CódigoProducto, Nombre, Fabricante, País). CódigoProducto → Fabricante Fabricante → País CódigoProducto - -/→País País depende transitivamente de CódigoProducto, por tanto, no está en tercera forma normal.
  • 16.
    FORMAS NORMALES •Primera forma normal •Segundaforma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Forma normal de Boyce/Codd • Una tabla está en la forma normal de Boyce–Codd (BCFN) si, y sólo si, todo determinante es una clave candidata. • La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si éstas existen. La BCFN es más fuerte que la 3FN, por lo tanto, toda tabla en BCFN está en 3FN. • La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. • Se debe comprobar si una tabla viola la BCFN si tiene dos o más claves candidatas compuestas que tienen al menos un atributo en común. NOTAS (DNIAlumno, DNIProfesor,NombreProfesor, Nota) DNIProfesor → NombreProfesor NombreProfesor → DNIProfesor DNIProfesor,DNIAlumno → Nota En este caso, la tabla está en 3FN porque no hay dependencias funcionales transitivas, y sin embargo no está en FNBC porque NombreProfesor y DNI Profesor son implicantes, y no son claves candidatas. Para obtener la tabla en FNBC habría que quitar de la tabla los atributos DNIProfesor y NombreProfesor.
  • 17.
    FORMAS NORMALES •Primera forma normal •Segundaforma normal •Tercera forma normal •Forma normal de Boyce/Codd •Otras formas normales Otras formas normales • Existen más formas normales (FN4, FN5, FNDK, FN6...) • Las formas normales 4 y 5, se ocupan de las dependencias entre atributos multivaluados, la Forma Normal Dominio Clave (FNDK) trata las restricciones y los dominios de los atributos, y finalmente la FN6 trata ciertas consideraciones con las bases de datos temporales.
  • 18.
    Referentes • López, I,Castellano, M. y Ospino, J. (2013). Bases de datos. Desarrollo de aplicaciones multiplataforma y web DAM y DAW. Elfaomega, México. • Marqués, M. (2009). Bases de datos. [Material online]. Departamento de Ingeniería y Ciencia de la Computación, UNIVERSITAT JAUME I DE CASTELLÓ. España. • Zea, M., Honores, J. y Rivas, W. (2015). Fundamentos de base de datos. Ediciones utmach, Ecuador.