1 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre...
-
Upload
enrique-gamon -
Category
Documents
-
view
105 -
download
0
Transcript of 1 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre...
1 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
NORMALIZACIÓN DE DATOSNORMALIZACIÓN DE DATOS
2 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Diseño RelacionaDiseño Relacionall
• El diseño de una BD Relacional puede abordarse de dos formas distintas:– Obteniendo el esquema relacional
directamente:Objetos y reglas captadas del análisis del mundo real, representadas por un conjunto de esquemas de relación, sus atributos y restricciones de integridad.
– Realizando el diseño del esquema "conceptual" de la BD (modelo E/R) y transformándolo a esquema relacional.
3 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Ejemplo de diseño inadecuadoEjemplo de diseño inadecuado
• Redundancia de información: ciudad, distancia (ciudad); precio (artículo).
• Anomalías de modificación: !podemos tener el mismo artículo con dos precios! (igual argumento para ciudad y distancia). inconsistencias
• Anomalías de inserción: ¿Podemos registrar nuevo artículo?, ¿Nuevo cliente?, ¿Nueva ciudad, distancia?
• Anomalías de borrado: Si eliminamos tupla de pedido de artículo A3 o cliente C4 pérdida de información.
4 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Ejemplo de diseño inadecuadoEjemplo de diseño inadecuado
• Redundancia de información: – datos repetidos– desperdicio de espacio, actualización complicada
• Mal diseño:– anomalías, redundancia e inconsistencias de la
información– imposibilidad para representar cierta información– pérdida de información
• Normalización– conversión de una relación con ciertos problemas
a dos o más relaciones que no tienen tales problemas
5 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Principio básico de diseño:Principio básico de diseño:
• "hechos distintos se deben almacenar en objetos distintos"
6 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Teoría de NormalizaciónTeoría de Normalización
• Técnica formal de análisis y organización de datos; trata de evitar la redundancia y anomalías de actualización.– Introduce formalización en el diseño lógico de las
Bases de Datos Relacionales. – Además permite mecanizar parte del proceso al
disponer de instrumentos algorítmicos de ayuda al diseño.
– Proceso de normalización: disminuye las anomalías de actualización, pero penaliza las consultas (combinación consume muchos recursos).
7 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Formas normalesFormas normales
• Un esquema de relación está en una determinada forma normal si satisface un determinado conjunto específico de restricciones definidas sobre los atributos del esquema (dependencias).
– 1ª FN (Codd, 1970)• Concepto de relación normalizada.
– 2ª, 3ª FN (Codd, 1970), FNBC (Boyce/Codd, 1974)
• Basadas en análisis de dependencias funcionales.
– 4ª FN. Fagin, 1977• Basada en análisis de dependencias multivaluadas.
– 5ª FN. Fagin, 1979 • Basada en análisis de dependencias de proyección /
combinación.
8 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Relaciones en 5ªFN
Relaciones en 4ªFN
Relaciones en FNBC
Relaciones en 3ªFN
Relaciones en 2ªFN
Relaciones normalizadas
Relaciones
Formas normalesFormas normales
9 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
DependenciasDependencias
• Restricciones de integridad impuestas por el usuario.
• Propiedades inherentes al contenido semántico de los datos.
• Se han de cumplir para cualquier extensión del esquema de una relación.
No se pueden demostrar, pero sí afirmar por observación del mini mundo a representar.
Del análisis de la extensión de un esquema relacional sólo podremos deducir que no existe una determinada dependencia.
Si una dependencia es cierta para un determinado esquema de relación, una extensión no será válida si no la cumple.
10 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Dependencia funcionalDependencia funcional
• Sean A y B atributos de una misma tabla o relación R. Se dice que B es funcionalmente dependiente de A y se denota A B si todo posible valor de A tiene asociado un único valor de B,
o lo que es lo mismo, en todas las tuplas de r(R) en las que el atributo A toma el mismo valor “v1”, el atributo B toma también un mismo valor “v2”.
11 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Dependencia funcional Dependencia funcional DefDefinicióninición• Sean X e Y subconjuntos de A (A,
conjunto de atributos de R). Decimos que X determina o implica
a Y en R (equivale a Y depende funcionalmente de X) si para dos tuplas cualesquiera de r(R) que tengan iguales valores en X, también son iguales los valores en Y.
• Se representa por X Y
12 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Diagrama de dependencias Diagrama de dependencias funcionalesfuncionales• Ejemplo: R ( A, DF ).
R: pedidosA: {artículo, cliente, cantidad, precio, ciudad, distancia}. DF: ({artículo,cliente} {cantidad,precio,ciudad, distancia},
artículo precio,cliente {ciudad, distancia},ciudad distancia )
Diagrama de DependenciasFuncionales
13 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Dependencia funcional plena o Dependencia funcional plena o completacompleta• Sea X (conjunto de atributos). Se dice que Y tiene
dependencia funcional plena o completa de X,– si depende funcionalmente de X – pero no depende de ningún subconjunto del
mismo• X Y sii X' X | X' Y (X determina
completamente "" a Y si y solo si no existe un subconjunto X' de X tal que ese subconjunto X' determine funcionalmente a Y)
• P.e. (artículo, cliente) cantidad es una DF completa, pero
• (artículo, cliente) precio no es una DF completa puesto que artículo precio;
14 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Dependencia funcional transitivaDependencia funcional transitiva
• Si XY, Y-/X, YZ entonces Z depende transitivamente de X (X--Z)
• Por ejemplo:– Cliente ciudad, – ciudad -/ cliente (no determina
funcionalmente), y– cliente distancia,– por tanto, ciudad --- distancia – (cliente determina “transitivamente” a
distancia).
15 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Normalización de un esquema Normalización de un esquema de BD Relacionalde BD Relacional
16 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Segunda Forma Normal (2ªFN).Segunda Forma Normal (2ªFN).
• Un esquema de relación R(A,DF) está en 2ª FN si y sólo si – está en 1ª FN (es decir, si la relación está normalizada) – y sus atributos no primarios dependen completamente de
la clave primaria de R.(atributos no primarios: que no formen parte de la clave primaria).
• Si una relación R no está en 2ª FN, se puede normalizar descomponiendo esa relación en:– Una relación con los atributos de clave primaria, más los
atributos con dependencia completa de ella. – Una relación para cada "parte" de la clave primaria, más los
atributos que dependan funcionalmente de esa parte.
17 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Descomposición a 2ª FN Descomposición a 2ª FN (informal)(informal)• Ejemplo: PEDIDOS se descompone en:
PEDIDOS'({artículo,cliente, cantidad}, {[artículo,cliente] cantidad})
ARTICULOS ({artículo, precio}, {artículo precio} )CLIENTES({cliente,ciudad,distancia},
{clienteciudad,ciudaddistancia})
18 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Tercera Forma Normal (3ªFNTercera Forma Normal (3ªFN))
• Un esquema de relación R(A,DF) está en 3ª FN si y sólo si – está en 2ª FN y – ninguno de sus atributos no primarios depende
transitivamente de la clave primaria de R.• Es decir no hay DF transitivas.• Descomposición informal: Si una relación no está
en 3ª FN, y tenemos los conjuntos de atributos X,Y,Z tales que XY, YZ (por tanto X --- Z ):– Una relación formada por la clave primaria (X) más
los atributos que dependen directamente de ella.– Una relación para los atributos de Y y Z.
19 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Descomposición a 3ª FN Descomposición a 3ª FN (informal)(informal)
• Ejemplo: CLIENTES se descompone en:
CLIENTES' ({cliente, ciudad}, {cliente ciudad})CIUDADES ({ciudad, distancia}, {ciudad distancia})
20 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Implicación lógica de DFs.Implicación lógica de DFs.
• Dado un esquema relacional R, una dependencia funcional df de R está implicada lógicamente por un conjunto de dependencias DF de R si cada ejemplar de la relación r(R) que satisface DF también satisface df.
• R({ABCGHI}, {AB, AC, CGH, CGI, BH} ¿ AH ?Si t1[A]=t2[A], AB t1[B]=t2[B], BH t1[H]=t2[H] AH
• Cierre (clausura) de DF: Dado un conjunto de dependencias funcionales DF, llamaremos cierre de DF, y lo representaremos por DF+, al conjunto de todas las dependencias funcionales posibles que implicadas lógicamente en DF.
21 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Reglas de inferencia de DFsReglas de inferencia de DFs
• Dado un conjunto DF de dependencias funcionales, podemos probar que se cumplen otras ciertas dependencias funcionales inferidas de DF.
• "Axiomas" de Armstrong:Sea R (A:D); X ,Y, Z, W subconjuntos de A. Se verifica:
1) Reflexividad. Si X, conjunto de atributos, Y X, entonces se verifica que X Y.
2) Aumentatividad. Si X Y, Z conjunto de atributos, entonces se verifica que XZ YZ.
(XY es lo mismo que X Y, unión)
3) Transitividad. Si X Y e Y Z, entonces se verifica que X Z.– Estas reglas forman un sistema completo de reglas de inferencia,
porque dado DF permiten calcular DF+ – Son correctas (seguras) puesto que no generan dependencias
funcionales incorrectas.
22 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Técnicas principales para elTécnicas principales para el Diseño RelacionaDiseño Relacionall
• Diseño del esquema conceptual en un modelo de datos de alto nivel (como el ER) y su posterior transformación en un conjunto de relaciones. – En esta técnica podemos aplicar
informalmente los principios de normalización comentados (evitar dependencias parciales o transitivas), tanto durante la fase de diseño conceptual, como posteriormente al conjunto de relaciones obtenidas mediante el proceso de transformación.
23 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Técnicas principales para el Técnicas principales para el Diseño RelacionaDiseño Relacionall• Considerar el diseño de la BD relacional estrictamente en
términos de dependencias (funcionales y de otros tipos que veremos) entre los atributos de la BD. – Este proceso es denominado algunas veces como síntesis
relacional, puesto que los esquemas de relación son “sintetizados” mediante el adecuado agrupamiento de atributos.
– Cada esquema de relación representaría a un grupo de atributos lógicamente coherente y poseería las ventajas asociadas con la normalización (no redundancia, no anomalías, ...).
– Durante el proceso de normalización descompondremos un determinado esquema de relación que no esté en una determinada forma normal en múltiples esquemas de relación hasta un diseño final con relaciones en las que se hubiese alcanzado la forma normal deseada.
– Caso extremo (descomposición estricta): • comenzamos sintetizando un único esquema de relación (relación
universal), que incluye todos los atributos de la BD.
24 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Objetivos de la normalización.Objetivos de la normalización.
• Dado un conjunto A de atributos y el conjunto DF de dependencias existentes entre ellos, R(A, DF), se trata de transformar este esquema origen en un conjunto de n esquemas de relación {Ri (Ai, DFi)}, 1 i n [esquemas resultantes], equivalentes y mejores que R:
a) Conservación de la información.
b) Conservación de dependencias.
c) Mínima redundancia de los datos (mayor grado de normalización).
25 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
a. Conservación de la información:a. Conservación de la información:
a.1. Conservación de atributos: el conjunto de atributos de los esquemas resultantes ha de ser igual al conjunto de atributos del esquema origen.
a.2. Conservación del contenido (tuplas): para toda extensión r de R, la reunión natural (natural join, * ) de las relaciones resultantes
tiene que producir la relación origen. – (nota: * operador de reunión natural, operador
de proyección)
A = Ai
i 1
n
U
Si la descomposición no cumple esta propiedad, e.d. no es una descomposición y reunión sin pérdidas (de información), cuando se aplica la operación de reunión natural a las relaciones resultantes, aparecen tuplas espúreas en la relación resultado
i= 1
n
Rir r ( )
26 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Descomposición y Reunión Descomposición y Reunión con pérdida con pérdida
LIBROS COD-LIBRO EDITORIAL PAIS 9030 RAMA ESPAÑA 9040 RAMA ESPAÑA 9110 PARANINFO ESPAÑA 9234 ANAYA ESPAÑA 9567 ADDISON EE.UU.
LIBROS_NUEVA COD-LIBRO PAIS 9030 ESPAÑA 9040 ESPAÑA 9110 ESPAÑA 9234 ESPAÑA 9567 EE.UU.
EDITORIAL PAIS RAMA ESPAÑA RAMA ESPAÑA PARANINFO ESPAÑA ANAYA ESPAÑA ADDISON EE.UU.
COD-LIBRO EDITORIAL PAIS 9030 RAMA ESPAÑA 9030 PARANINFO ESPAÑA 9030 ANAYA ESPAÑA 9040 RAMA ESPAÑA 9040 PARANINFO ESPAÑA 9040 ANAYA ESPAÑA 9110 RAMA ESPAÑA 9110 PARANINFO ESPAÑA 9110 ANAYA ESPAÑA 9234 RAMA ESPAÑA 9234 PANANINFO ESPAÑA 9234 ANAYA ESPAÑA 9567 ADDISON EE.UU.
*
27 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Tercera Forma Normal (Tercera Forma Normal (3ª FN3ª FN).).
• Definiciones generales,
– atributo primo: atributo que forma parte de una clave candidata.
– Un esquema de relación R está en 2ª FN si está en 1ª FN y todo atributo no primo A de R depende funcionalmente de manera completa de toda clave candidata de R.
– Un esquema de relación R está en 3ª FN si está en 2ª FN y ningún atributo no primo depende transitivamente de alguna clave candidata de R.
28 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Tercera Forma Normal (3ª FNTercera Forma Normal (3ª FN).).
• Redefinición de 3ª FN: Un esquema de relación R(A,DF) está en 3ª FN si X Y DF+ se verifica alguna de las siguientes condiciones:– X Y trivial.– X es superclave de R.– X no es superclave y cada atributo A (Y - X) está contenido
en una clave candidata de R.
• Un diseño de BD está en 3ª FN si cada esquema de relación de la BD está en 3ª FN.
FNBC
29 2006Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - Erik Sacre
Ejemplo: 3ª FN y FNBCEjemplo: 3ª FN y FNBC
• imparte (estudiante, curso, profesor)– DF: (1) estudiante, curso profesor;
(2) profesor curso
– K: { (estudiante, curso), (estudiante, profesor)}
– No en FNBC pues antecedentes de (2) no es superclave,
– pero si en 3ª FN pues los consecuentes son atributos primos.
• Descomposición a FNBC por profesor curso:
Imparte R-(Y) XY ESTUD CURSO PROF ESTUD PROF PROF CURSO Díaz Bases de Datos Roberto Díaz Roberto Alberto Redes Fernández Bases de Datos Gonzalo Fernández Gonzalo Alonso Redes Fernández Redes Alberto Fernández Alberto Fulgencio Algoritmia Fernández Algoritmia Fulgencio Fernández Fulgencio Gonzalo Bases de Datos García Bases de Datos Marcos García Marcos Marcos Bases de Datos García Redes Alonso García Alonso Roberto Bases de Datos López Bases de Datos Marcos López Marcos Rueda Bases de Datos Gonzalo Rueda Gonzalo
PC
E