Diseñar una estructura de datos eficiente en bases de datos relacionales

BASE DE DATOS

Unidad 4: Diseñar una estructura de datos eficiente

Prof. Mg. Ing. Roxana Martínez Prof. Esp. Lic. Silvia Salgado UAI UAI Universidad Abierta Interamericana UAIOnline Ultra»BASE DE DATOS

Diseño de una estructura de datos eficiente

Unidad 4: Objetivos

Dependencias funcionales y normalización par Bases de Datos Relacionales. Pautas informales de diseño. Primera, segunda y tercera forma normales. Proceso para la normalización. Determinantes. Forma Normal de Boyce / Codd. UAI Universidad Abierta Interamericana

Introducción al diseño de bases de datos

Cuando se diseña una base de datos se busca generar un conjunto de esquemas que permitan almacenar información sin redundancias, permitiendo modificaciones sin ambigüedades y, por supuesto, facilitando el recupero de dicha información en forma eficiente.

En general, se supone que partiendo de un buen trabajo de relevamiento y de un buen diagrama de entidad-relación debería llegarse en forma directa a un diseño correcto de una base de datos. Sin embargo, no siempre nos vamos a encontrar involucrados en la etapa de diseño. Es probable que nos presenten un sistema ya armado para corregir o bien que nos pidan migrar un sistema hacia otra plataforma, siendo responsables de efectuarle los cambios pertinentes para que luego funcione correctamente.

Anomalías de actualización en bases de datos relacionales

Base de datos relacional es un conjunto de esquemas relacionados y sus restricciones. La mala representación de la información, como puede ser la redundancia de datos, produce ciertas anomalías en la actualización (inserción, modificación y borrado) de los mismos.

Ejemplo de base de datos mal diseñada

Base mal diseñada y evidenciaremos las distintas anomalías ALUMNO legajo nombre direccion nroActa nota Materia 400 Ana Lopez Santa Fé 235 1103 2 Programacion I 400 Ana Lopez' Santa Fé 235 1104 2 Programacion I 400 'Ana Lopez® Santa Fé 235 1108 7 Algebra Lineal 1300 'Raul Sosa' Gurruchaga 3015 1333 9 Matematica II 1300 'Raul Sosa' Gurruchaga 3015 1103 2 Programacion | 1300 'Raul Sosa Gurruchaga 3015 1106 4 Programacion I 1300 'Raul Sosa Gurruchaga 3015 1108 5 Algebra Lineal 2000 'Ana Lopez' Maure 1925 1103 2 Programacion I

Ejemplo de anomalía de inserción

Supongamos que el alumno Raúl Sosa rinde un examen de Programación II y resulta ser evaluado con 7 puntos, quedando constancia en el acta 1406, para lo cual deberíamos insertar la tupla: ( 1300, 'Raul Sosa', Gurruchaga 3015, 1406, 7, Programación II ) Es evidente que estamos repitiendo información, ya que el nombre y la dirección del alumno con legajo 1300 resultan ajenos al examen que haya rendido el mismo. Dicha repetición, además de malgastar espacio, complica la inserción. Se trata de una redundancia de datos.

Tipos de anomalías en el diseño de bases de datos

Anomalía de inserción

Otro problema de nuestro diseño es que no se puede tener información de un alumno que no haya rendido algun examen, a menos que se completen número de Acta, nota y materia con NULL o datos ficticios. El inconveniente radica en que la información inherente al alumno debería estar disponible independientemente de que éste haya rendido o no exámenes. Estamos frente a la llamada anomalía de inserción.

Anomalía de modificación y borrado

Hay otro problema grave que está ligado a la modificación de la información. Pensemos que el alumno Sosa cambia su dirección. Con este diseño estaríamos obligados a realizar el cambio en todas las tuplas donde figure Raúl Sosa, complicándose la actualización de la información y corriendo el riesgo de incurrir en alguna inconsistencia. Este hecho evidencia la llamada anomalía de modificación. Por otra parte, pensemos que si se borraran todas las apariciones de Programación I, perderíamos simultáneamente toda la información respectiva a la alumna Ana López, de legajo 2000. Esto presenta una muestra de la llamada anomalía de borrado.

Diseño de bases de datos: Dependencias y redundancia

Intuitivamente, lo que ocurre es que para un determinado legajo sólo hay un nombre y una dirección posibles, es decir, nombre y dirección dependen de legajo. En cambio, un mismo alumno (identificado por legajo) puede haber dado muchos exámenes, con lo cual un mismo legajo puede tener muchos números de acta asociados. Evidentemente se trata de un mal diseño.

Objetivo del buen diseño y la Teoría de Normalización

El objetivo de un buen diseño de una base de datos es eliminar toda redundancia de datos y reducir o eliminar anomalías de manipulación de datos. La Teoría de Normalización es una teoría completa que le permite al diseñador eliminar problemas de diseño por medio de la descomposición o reorganización de la estructura de tablas existentes.

Dependencias funcionales

Definición de dependencia funcional

Sean X e Y dos conjuntos de atributos de un esquema de relación R. Se dice que X determina funcionalmente a Y o que Y depende funcionalmente de X, lo cual se denota X -> Y, si se cumple: Que para dos tuplas t1, t2 en una relación r, si se cumple que t1[X] = t2[X] entonces t1[Y] = t2[Y]

Ejemplos de dependencias funcionales

En un sistema de biblioteca: ISBN ) tituloLibro (no puede haber dos libros de igual ISBN con distinto título). En un sistema estatal: nroCuil > nombre (dos personas distintas no pueden tener el mismo CUIL). En un sistema de facturación: articulo cantidad >montoVenta La venta de la misma cantidad de un determinado artículo no puede acusar distinto montos (sin tener en cuenta descuentos). Las dependencias funcionales son una propiedad de la semántica de los atributos, ya que tienen relación con el significado de dichos datos y de cómo se influencian entre sí.

Independencia de los datos

Es el objetivo esencial de un DBMS. Consiste en mantener la inmunidad de las aplicaciones ante los cambios en la estrategia de acceso o en la estructura de almacenamiento de los datos. . Data ... 0 O 0 DBMS programming

Dependencias funcionales: Ejemplo de esquema

Para el esquema dado como ejemplo, podemos determinar el conjunto de dependencias funcionales F a través del significado de los atributos. F = { legajo >nombre, legajo >dirección, nroActa >materia, legajo +nroActa >nota }

Otras dependencias funcionales

También podemos determinar que tiene clave compuesta: legajo + nroActa Sin embargo hay muchas otras dependencias funcionales que también se cumplen, como por ejemplo: legajo > nombre + dirección legajo + nroActa > materia legajo + nombre > nombre etc.

Formas normales

TABLAS 1º FN 2º FN 3º FN FN BOYCE/CODD 4º FN 5º FN o FN PR

Primera Forma Normal (FN1)

Una relación está en FN1 si y solo si todos sus dominios subyacentes sólo contienen valores atómicos. Una relación está en FN1 si no tiene grupos repetitivos

Ejemplo de tabla no en FN1

Columnas cuyos Datos -- presentan sólo un valor Columnas que presentan Datos -- con más de un valor !! No atomicos! IdPedido Fecha Id Cliente Nombre Cli idProducto NombrePrd Cantidad 123 23/11/1998 010 E Metálicas P2 P4 Lic.Contab Lic. Planilla y RRHH 20 5 1 P9 Mantenimiento AnualLP2 246 13/10/1998 020 M.Soldadura P2 P9 Lic. Contab 10 Mantenimiento Anual P2 1 280 5/12/1998 010 E.Metálicas P8 P12 Mantenimiento Anual P4 Lotus Notes 1 5

Identificación de grupos repetitivos

IdPedido Fecha IdCliente Nombre Cli IdProducto NombrePrd Cantidad 123 23/11/1998 010 E.Metálicas P2 Lic.Contab Lic. Planilla y RRHH 20 P4 5 P9 Mantenimiento Anual P2 1 246 13/10/1998 020 M.Soldadura P2 Lic.Contab 10 P9 Mantenimiento Anual P2 1 280 5/12/1998 010 E.Metálicas P8 Mantenimiento Anual P4 1 P12 Lotus Notes 5 Para pasar a FN1 debo cortar por alli, Grupo repetitivo

Conversión a FN1

IdPedido Fecha IdCliente Nombre Cli 123 23/11/1998 010 E.Metálicas 246 13/10/1998 020 M.Soldadura 280 5/12/1998 010 E.Metálicas Al pasarlo a FN1 de esa tabla original desnormalizada obtengo el siguiente par de tablas normalizadas: Las tablas obtenidas deben relacionarse para que yo pueda volver a obtener la informacion original Detalle de pedido IdPedido IdProducto Nombre Prd Cantidad 123 P2 Lic. Contab 20 necesito clave anterior 123 P4 Lic Planilla y RRHH F 123 P9 Mantenimiento Anual P2 1 246 P2 Lic.Contab 10 246 P9 Mantenimiento Anual P2 1 280 P8 Mantenimiento Anual P4 1 280 P12 Lotus Notes 5 Pedido

Segunda Forma Normal (FN2)

A partir de aquí retomamos con los conceptos de dependencias funcionales vistos anteriormente: Una relación está en FN2 si y solo si está en FN1 y cada atributo no primo (o sea que no conforma la clave primaria) es completamente dependiente de la clave primaria. Es decir: Una relación está en FN2 si está en FN1 y todos los atributos no primos dependen de la clave completa.

Ejemplo de tabla no en FN2

clave NombrePrd depende de Idproducto solo una parte de la clave) IdPedido IdProducto Nombre Prd Cantidad 123 P2 Lic Contab 20 Detalle de pedido 123 4 I ir Planilla y RRHH 5 123 P9 Mantenimiento Anual P2 1 246 P2 Lic.Contab 10 246 P9 Mantenimiento Anual P2 1 280 P8 Mantenimiento Anual P4 1 280 P12 Lotus Notes 5

Conversión a FN2

Una vez realizado el pasaje a FN2 obtenemos de la tabla desnormalizada original este par de tablas normalizadas: Detalle de pedido Notar nuevamente que: La parte de la clave IdProducto de la cual dependía el atributo nombreProd, ahora se convierte en clave de una nueva tabla. Las nuevas tablas se relacionaran a través del atributo idProducto. IdPedido Id Producto Cantidad 123 P2 20 123 P4 5 123 P9 1 246 P2 10 246 P9 1 280 P8 1 280 P12 5 Producto dProducto Nombre Prd P2 Lic.Contab P4 Lic. Planilla y RRHH P9 Mantenimiento Anual P2 P8 Mantenimiento Anual P4 P12 Lotus Notes

Tercera Forma Normal (FN3)

Una relación está en FN3 si y solo si está en FN2 y ningún atributo no primo (los que no forman parte de la clave primaria)depende de otro atributo no primo. Una relación esta en FN3 si y solo si está en FN2 y ningun atributo depende de la clave a través de otro atributo no primo(transitividad) · Dependencia transitiva: X > Y solo si X > Zy Z > Y

Ejemplo de dependencia transitiva

Dependencia transitiva: X > Y solo si X > Zy Z > Y Clave 1 NombreCli depende de IdPedido indirectamente a través de IdCliente IdPedido Fecha IdCliente Nombre C 123 23/11/1998 010 E.Metálicas Pedido 246 13/10/1998 020 M.Soldadura 280 5/12/1998 010 E.Metálicas X es idPedido y determina a Y que es idCliente. Pero también X determina a Z que es NombreCliente. Por lo tanto vemos que también se cumple que Y determina a Z. Esta es la transitividad en esta tabla desnormalizada. Ambos'no primos y uno depende del otro