Diseño de Bases de Datos Normalización

Modelo Entidad Relación Extendido Proceso de Construcción de una base de datos Minimundo OBTENCION Y ANALISIS DE REQUERIMIENTOS DISEÑO CONCEPTUAL Modelo Entidad Relación Extendido NORMALIZACION Independiente del SGBD DISEÑO LOGICO Tablas Específico para cada SGBD DISEÑO FISICO

Modelo Entidad Relación Extendido ¿Cómo utilizamos la normalización nosotros? Minimundo OBTENCION Y ANALISIS DE REQUERIMIENTOS DISEÑO CONCEPTUAL Modelo Entidad Relación Extendido Independiente del SGBD DISEÑO LOGICO Tablas NORMALIZACION Específico para cada SGBD DISEÑO FISICO

elegir “buenas” estructuras de relaciones Normalización Objetivo elegir “buenas” estructuras de relaciones permitiendo Expresar formalmente las razones por las que una agrupación de atributos es mejor que otra

Normalización “Bondad” de las relaciones Nivel de implementación Nivel lógico Forma en la que los usuarios interpretan: las estructuras de las relaciones el significado de sus atributos Forma en la que se manipulan: cómo se almacenan las tuplas de la relación cómo se actualizan las tuplas de la relación

Aspectos importantes a considerar a la hora de diseñar Semántica de los atributos Cada atributo debe contener un único valor Reducción de valores redundantes en las tuplas

Semántica de los atributos: Aspectos importantes a considerar a la hora de diseñar Semántica de los atributos: Agrupación de atributos dentro de una relación Supone un cierta relación semántica entre los atributos

Cada atributo debe ser monovaluado Aspectos importantes a considerar a la hora de diseñar Cada atributo debe ser monovaluado Sucursales no es válido no es válido grupo repetitivo atributo compuesto

Aspectos importantes a considerar a la hora de diseñar Cada atributo debe ser monovaluado: Esto implica que la relación anterior debiera reemplazarse por las siguientes: Sucursales

Aspectos importantes a considerar a la hora de diseñar Cada atributo debe ser monovaluado: Telefonos_Suc

Reducción de valores redundantes: Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes: Dentro de los principales objetivos en el diseño de relaciones Minimizar el espacio de almacenamiento que ocupan las relaciones base (archivos) Evitar anomalías de actualización

Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes: Clientes_de_Sucursal

Analicemos la redundancia: Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes: Analicemos la redundancia: ¿Cuantas veces aparece la información correspondiente a cada sucursal? ¿Qué problemas puede acarrear?

Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes: ¿Qué sucede si queremos ingresar un nuevo cliente? De que debemos asegurarnos? ¿Qué sucede si queremos ingresar una sucursal nueva que todavía no tiene clientes? ¿Es posible? Analicemos las inserciones:

Analicemos las supresiones: Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes: ¿Qué sucede si queremos eliminar el cliente Miguel Gomez? Analicemos las supresiones:

Analicemos las modificaciones: Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes: ¿Qué sucede si queremos registrar que la sucursal Espigas cambio su dirección? Analicemos las modificaciones:

Aspectos importantes a considerar a la hora de diseñar Estos problemas son denominados Anomalías de actualización

Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes Analicemos los mismos interrogantes con las siguientes relaciones: Sucursales Clientes Es_cliente_de

Evitar la inconsistencia Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes: Debemos diseñar las relaciones de manera de evitar las anomalías de inserción, eliminación y modificación en las relaciones Evitar la inconsistencia de la base de datos

Normalización Formas Normales (1FN a la 5FN): - Dependencia Funcional - Dependencia Multivaluada - Dependencia Join

Universo de todas las relaciones Normalización (Formas Normales) Universo de todas las relaciones 2FN 3FN FNBC 4FN 1FN 5FN

Toda relación R está en 1FN, por definición Primera Forma Normal Una relación R está en 1FN si los dominios de todos sus atributos son atómicos Toda relación R está en 1FN, por definición

Dependencia Funcional si para 2 tuplas cualesquiera t1 y t2 de R tales que t1(X)= t2(X) entonces t1(Y)= t2(Y) en todo estado de R X Y o expresado de otra manera si para cada valor de X le corresponde sólo un valor de Y en todo estado de R X Y

es Trivial si X contiene a Y Dependencia Funcional Trivial y No Trivial es Trivial si X contiene a Y X Y Z+Y Y es Trivial Caso contrario, es no Trivial X Y

Claves Dada una relación R, un subconjunto de atributos S de R es superclave si su valor es único dentro de la relación en todo momento. Formalmente, si no existe un par de tuplas t1, t2 tal que t1[S]= t2[S], para todo estado permitido de la relación.

Claves Dada una relación R, un subconjunto de atributos K de R es clave candidata o simplemente clave si cumple: Unicidad: No existe un par de tuplas que tengan el mismo valor para K, es decir, es superclave. Minimalidad: Si se quita algún atributo de la misma deja de cumplir la unicidad. Entonces, sea K={A1, A2, …, Ak}, si K es clave entonces K –{Ai} no es clave para 1≤i ≤k

Claves Una relación puede contener más de una clave, llamadas claves candidatas: Se elige una como clave primaria A las restantes, se las denomina claves secundarias o alternativas.

Atributo Primo Un atributo de R se denomina atributo primo de R si es miembro de alguna clave de R. “Un atributo de R se denomina atributo no primo de R si no es atributo primo”

Se basa en el concepto de dependencia funcional completa o total: Segunda Forma Normal Se basa en el concepto de dependencia funcional completa o total: - Una dependencia funcional es completa si la eliminación de cualquier atributo A de X hace que la dependencia no sea válida. Es decir, X-A no determina funcionalmente a Y. X Y - Una dependencia funcional es parcial si es posible eliminar algún atributo A de X y la dependencia sigue siendo válida. X Y

Segunda Forma Normal Una relación R está en 2FN si todo atributo no primo A de R depende funcionalmente en forma completa de la clave primaria de R.

Segunda Forma Normal Solución: Si una relación no está en 2FN, descomponerla y crear una nueva relación para cada clave parcial con su/s atributo/s dependiente/s.

Descomposiciones válidas Toda descomposición debe cumplir una restricción (no sólo para la 2FN, sino para todas) No provocar pérdida de información, es decir, el join (union) de las proyecciones genera la relación original Inclusive, provocan ganancia de información. Permiten registrar información que en la relación original era imposible.

Tercera Forma Normal Una relación R está en 3FN si está en 2FN y ningún atributo no primo de R depende en forma transitiva de la clave primaria.

Tercera Forma Normal Definición General Una relación R está en 3FN si para toda dependencia funcional no trivial se cumple: X Y X es superclave de R o Y es un atributo primo

Nota: “Tener cuidado con las posibles descomposiciones” Tercera Forma Normal Solución: Si una relación no está en 3FN, descomponerla creando otra relación que contenga el/los atributo/s no clave que determinen funcionalmente a otro/s atributo/s no clave. Nota: “Tener cuidado con las posibles descomposiciones”

Forma Normal de Boyce y Codd Una relación R está en FNBC si todo determinante es clave candidata. Una relación que está en 3FN No necesariamente está en BCNF Una relación que está en BCFN Está en 3FN

Forma Normal de Boyce y Codd Otra Definición Una relación R está en FNBC si para toda dependencia funcional no trivial X es superclave de R. X Y,

Cada parcela es identificada por su nro. catastral Forma Normal de Boyce y Codd DF2 Cada parcela es identificada dentro de un municipio, por su nro. de parcela Veamos un ejemplo: DF1 Cada parcela es identificada por su nro. catastral DF3 Las sup. de las parcelas de cada municipio son diferentes, pero, no existe una sup.que corresponda a más de un municipio. Nro_Catastral Nombre_Municipio+Parcela Superficie Determinantes: Claves candidatas: No es clave candidata FNBC

Forma Normal de Boyce y Codd Al descomponer: Determinantes: Determinantes: Nro_Catastral Superficie Claves candidatas: Claves candidatas: Nro_Catastral Superficie BCNF

Se basa en el concepto de dependencia multivaluada (DMV) Cuarta Forma Normal Se basa en el concepto de dependencia multivaluada (DMV) Dada una relación R con atributos (X,Y,Z), X multidetermina a Y, y se simboliza , si se cumple que dado un par (X,Z) el conjunto de valores de {Y} que coinciden con ese par, dependen de X y no dependen de Z. X Y

Cuarta Forma Normal Una relación R está en 4FN sii está en FNBC y no existen DMV no funcionales. DMV DMV no funcionales DF

Una relación R está en 4FN sii está en FNBC y toda DMV es DF. Cuarta Forma Normal Otra definición: Una relación R está en 4FN sii está en FNBC y toda DMV es DF. DMV DF

Cada curso puede ser dictado por varios profesores. Cuarta Forma Normal Veamos un ejemplo: Cada curso puede ser dictado por varios profesores. Cada curso tiene libros asignados, independientemente del profesor que lo dicte. Es decir, el profesor no decide los libros que usa en un curso determinado.

Cuarta Forma Normal ¿Curso Libro? Curso Libro Dado un par (Curso, Profesor), por ejemplo (Bases de Datos I, Castro) el conjunto de valores de Libro {Fundamentos de Bases de Datos, Introducción a los DBMS}: ¿Depende del Curso? ¿Depende del Profesor? Sí depende Curso Libro No depende

Cuarta Forma Normal En esta relación se verifican: DMV1 DMV2 Las dos dependencias multivaluadas no son funcionales. Por lo tanto, la relación no está en 4FN.

Cuarta Forma Normal Solución: No presenta DMV No presenta DMV Está en BCNF No presenta DMV Está en BCNF No presenta DMV Está en 4FN Está en 4FN

Quinta Forma Normal Se basa en el concepto de Dependencia Join (DJ) Dependencia Join = n-descomponible n>2

Cada proyección de la DJ contiene a la clave primaria Quinta Forma Normal Una relación R está en 5FN sii está en 4FN y toda DJ es consecuencia de la clave primaria. Cada proyección de la DJ contiene a la clave primaria

¿La relación Proveedores está en 5FN? Quinta Forma Normal Proveedores ¿La relación Proveedores está en 5FN?

Quinta Forma Normal ¿Es posible descomponerla en al menos 3 proyecciones sin perder información? ¿Existe al menos una Dependencia Join? Contiene la clave primaria Contiene la clave primaria Contiene la clave primaria

Quinta Forma Normal Está en 5 FN

Quinta Forma Normal Ahora analicemos esta otra relación: Supongamos que satisface la siguiente restricción en todo estado válido: Si (S1,P1), (P1,J1) y (S1,J1) entonces debe aparecer la tupla (S1,P1,J1) en la relación. Restricción cíclica

Quinta Forma Normal Esta restricción genera la siguiente situación: La inserción de la tupla

Quinta Forma Normal 5FN Analicemos ahora si está en 5FN… Clave primaria No contiene la clave primaria No contiene la clave primaria No contiene la clave primaria Join de las 3 proyecciones genera la relación original 5FN

Quinta Forma Normal Solución: 5FN 5FN 5FN No posee DJs No posee DJs

Normalización Bibliografía: Date - Introducción a los Sistemas de Bases de Datos Elmasri - Fundamentos de Bases de Datos