740 likes | 1.35k Views
Diseño de Bases de Datos. Normalización. 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.
E N D
Diseño de Bases de Datos Normalización
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
¿Cómo utilizamos la normalización nosotros? Minimundo OBTENCION Y ANALISIS DE REQUERIMIENTOS DISEÑO CONCEPTUAL Modelo Entidad Relación Extendido Independiente del SGBD NORMALIZACION DISEÑO LOGICO Tablas Específico para cada SGBD DISEÑO FISICO
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 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 Sucursales no es válido no es válido grupo repetitivo atributo compuesto
Cada atributo debe ser monovaluado:Esto implica que la relación anterior debiera reemplazarse por las siguientes: Aspectos importantes a considerar a la hora de diseñar 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 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
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?
Analicemos las inserciones: • ¿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? Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes:
Analicemos las supresiones: • ¿Qué sucede si queremos eliminar el cliente Miguel Gomez? Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes:
Analicemos las modificaciones: • ¿Qué sucede si queremos registrar que la sucursal Espigas cambio su dirección? Aspectos importantes a considerar a la hora de diseñar Reducción de valores redundantes:
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
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
1FN FNBC 4FN 5FN 2FN 3FN Normalización (Formas Normales) Universo de todas las relaciones
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
X Y X Y Dependencia Funcional 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 o expresado de otra manera si para cada valor de X le corresponde sólo un valor de Y en todo estado de R
es Trivial Z+Y Y X Y X Y Dependencia Funcional Trivial y No Trivial es Trivial si X contiene a Y Caso contrario, es no Trivial
Claves Dada una relación R, un subconjunto de atributos Sde R es superclavesi 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 clavesi 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”
X Y X Y Segunda Forma Normal Se basa en el concepto de dependencia funcional completa o total: - Una dependencia funcional es completasi 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. - Una dependencia funcional es parcialsi es posible eliminar algún atributo A de X y la dependencia sigue siendo válida.
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.
X Y Tercera Forma Normal Definición General Una relación R está en 3FN si para toda dependencia funcional no trivial se cumple: • X es superclave de R • o • Y es un atributo primo
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
X Y, 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.
Cada parcela es identificada dentro de un municipio, por su nro. de parcela Cada parcela es identificada por su nro. catastral Las sup. de las parcelas de cada municipio son diferentes, pero, no existe una sup.que corresponda a más de un municipio. DF1 DF2 DF3 Determinantes: Claves candidatas: • Nro_Catastral • Nombre_Municipio+Parcela • Superficie • Nro_Catastral • Nombre_Municipio+Parcela Forma Normal de Boyce y Codd Veamos un ejemplo: FNBC No es clave candidata
BCNF BCNF Forma Normal de Boyce y Codd Al descomponer: Determinantes: Determinantes: • Nro_Catastral • Superficie Claves candidatas: Claves candidatas: • Nro_Catastral • Superficie
X Y 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.
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
Cuarta Forma Normal Otra definición: Una relación R está en 4FN sii está en FNBC y toda DMV es DF. DMV DF
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.
Libro Curso Cuarta Forma Normal ¿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 Nodepende
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: • 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
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
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