Unidad 4; Diseño de bases de datos relacionales
4.1 Características del diseño relacional
En el modelo relacional las dos capas de diseño conceptual y lógico, se parecen mucho. Generalmente se implementan mediante diagramas de Entidad/Relación (modelo conceptual) y tablas y relaciones entre éstas (modelo lógico). Este es el modelo utilizado por los sistemas gestores de datos más habituales (SQL Server, Oracle, MySQL...).
Nota: Aunque mucha gente no lo sabe, a las bases de datos relaciones se les denomina así porque almacenan los datos en forma de "Relaciones" o listas de datos, es decir, en lo que llamamos habitualmente "Tablas". Muchas personas se piensan que el nombre viene porque además las tablas se relacionan entre sí utilizando claves externas. No es así, y es un concepto que debemos tener claro. (Tabla = Relación).
El modelo relacional de bases de datos se rige por algunas normas sencillas:
Todos los datos se representan en forma de tablas (también llamadas "relaciones", ver nota anterior). Incluso los resultados de consultar otras tablas. La tabla es además la unidad de almacenamiento principal.
Las tablas están compuestas por filas (o registros) y columnas (o campos) que almacenan cada uno de los registros (la información sobre una entidad concreta, considerados una unidad).
Las filas y las columnas, en principio, carecen de orden a la hora de ser almacenadas. Aunque en la implementación del diseño físico de cada SGBD esto no suele ser así. Por ejemplo, en SQL Server si añadimos una clave de tipo "Clustered" a una tabla haremos que los datos se ordenen físicamente por el campo correspondiente.
El orden de las columnas lo determina cada consulta (que se realizan usando SQL).
Cada tabla debe poseer una clave primaria, esto es, un identificador único de cada registro compuesto por una o más columnas.
Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave externa. Ambos conceptos de clave son extremadamente importantes en el diseño de bases de datos.
Basándose en estos principios se diseñan las diferentes bases de datos relacionales, definiendo un diseño conceptual y un diseño lógico, que luego se implementa en el diseño físico usando para ello el gestor de bases de datos de nuestra elección (por ejemplo SQL Server).
Por ejemplo, consideremos la conocida base de datos Northwind de Microsoft.
Esta base de datos representa un sistema sencillo de gestión de pedidos para una empresa ficticia. Existen conceptos que hay que manejar como: proveedores, empleados, clientes, empresas de transporte, regiones geográficas, y por supuesto pedidos y productos.
El diseño conceptual de la base de datos para manejar toda esta información se puede ver en la siguiente figura, denominada diagrama Entidad/Relación o simplemente diagrama E-R:
Como vemos existen tablas para representar cada una de estas entidades del mundo real: Proveedores (Suppliers), Productos, Categorías de productos, Empleados, Clientes, Transportistas (Shippers), y Pedidos (Orders) con sus correspondientes líneas de detalle (Order Details).
Además están relacionadas entre ellas de modo que, por ejemplo, un producto pertenece a una determinada categoría (se relacionan por el campo CategoryID) y un proveedor (SupplierID), y lo mismo con las demás tablas.
Cada tabla posee una serie de campos que representan valores que queremos almacenar para cada entidad. Por ejemplo, un producto posee los siguientes atributos que se traducen en los campos correspondientes para almacenar su información: Nombre (ProductName), Proveedor (SupplierID, que identifica al proveedor), Categoría a la que pertenece (CategoryID), Cantidad de producto por cada unidad a la venta (QuantityPerUnit), Precio unitario (UnitPrice), Unidades que quedan en stock (UnitsInStock), Unidades de ese producto que están actualmente en pedidos (UnitsOnOrder), qué cantidad debe haber para que se vuelva a solicitar más producto al proveedor (ReorderLevel) y si está descatalogado o no (Discontinued).
Los campos marcados con "PK" indican aquellos que son claves primarias, es decir, que identifican de manera única a cada entidad. Por ejemplo, ProductID es el identificador único del producto, que será por regla general un número entero que se va incrementando cada vez que introducimos un nuevo producto (1, 2, 3, etc..).
Los campos marcados como "FK" son claves foráneas o claves externas. Indican campos que van a almacenar claves primarias de otras tablas de modo que se puedan relacionar con la tabla actual. Por ejemplo, en la tabla de productos el campo CategoryID está marcado como "FK" porque en él se guardará el identificador único de la categoría asociada al producto actual. En otras palabras: ese campo almacenará el valor de la clave primaria (PK) de la tabla de categorías que identifica a la categoría en la que está ese producto.
Los campos marcados con indicadores que empiezan por "I" (ej: "I1") se refieren a índices. Los índices generan información adicional para facilitar la localización más rápida de registros basándose en esos campos. Por ejemplo, en la tabla de empleados (Employees) existe un índice "I1" del que forman parte los campos Nombre y Apellidos (en negrita además porque serán también valores únicos) y que indica que se va a facilitar la locación de los clientes mediante esos datos. También tiene otro índice "I2" en el campo del código postal para localizar más rápidamente a todos los clientes de una determinada zona.
Los campos marcados con indicadores que empiezan con "U" (por ejemplo U1) se refieren a campo que deben ser únicos. Por ejemplo, en la tabla de categorías el nombre de ésta (CategoryName) debe ser único, es decir, no puede haber -lógicamente- dos categorías con el mismo nombre.
4.2 Dominios Atómicos y la Primera Forma Normal
Se debe considerar que cada atributo (columna) debe ser atómico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos.
Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante.
Así mismo el orden de los atributos tampoco es relevante
año
título
tipo
duración
1991
Mighty Ducks
color
104
1992
Wayne's World
color
95
1977
Star Wars
color
124
Otra representación de la relación Películas
Normalización
Una vez creadas las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna manera.
Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relación son llamados anomalías. Los principales tipos son:
Redundancia: la información se repite innecesariamente en muchas tuplas.
Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra.
Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a perder información relacionada como un efecto de la eliminación.
Primera forma normal
Una tabla se encuentra en 1a FN, si todos sus atributos son atómicos (indivisibles)
nombre
dirección
teléfono
El ejemplo clásico:
En 1a. NF
nombre
apellido_paterno
apellido_materno
dirección
teléfono
4.3 Dependencias Funcionales
Hay veces en que los atributos están relacionados entre sí de manera más específica que la de pertenecer a una misma relación. Hay veces en que es posible determinar que un atributo depende de otro funcionalmente, como si existiera una función f en el "mundo", tal que t[A] = f(t[B]).
A --> B, la dependencia funcional, que se lee "A determina B".
Utilidad en el diseño de bases de datos
Las dependencias funcionales son restricciones de integridad sobre los datos. Conocer las dependencias funcionales en el momento del diseño de la base de datos permite crear mecanismos para evitar la redundancia (y los potenciales problemas de integridad que eso conlleva) y mejorar la eficiencia.
Un ejemplo real
Por ejemplo, sea la siguiente relación: Vehículo(serie, nombre, motor, carrocer´ıa, peso, eficiencia). Aquí, serie es la llave. Por ende, hay sólo un [modelo de] motor por serie, sólo una [forma de] carrocería por serie, sólo un peso por serie y sólo una eficiencia [energética] por serie: nombre = nombre( serie), motor = motor(serie), etcétera. O sea, serie -->nombre, motor, carrocera, peso, eficiencia (la relación es función de su llave; sólo hay una tupla por llave).
Otra observación, que requiere mucho más conocimiento del problema, nos indica que la eficiencia energética del vehículo es una función del motor, la carrocería y el peso. Considerando esto, tenemos que motor, carrocera, peso --> eficiencia. ¿Por qué? La eficiencia energética consiste en la distancia que puede recorrer un vehículo por litro, a una velocidad moderadamente alta. La potencia del vehículo reside en el motor: el modelo de motor indica la fuerza que imprime el vehículo. Sin embargo, esta fuerza es contrarrestada por el roce aerodinámico del vehículo, que es una función del roce viscoso del aire (es un dato fijo) y de la forma de la carrocería. Y el peso entrega la masa del vehículo (masa = 9, 8m/s2 × peso). Si se divide la fuerza resultante del vehículo por la masa, se obtiene la aceleración (y en un equilibrio de velocidades se obtiene la eficiencia). Luego, existe una función tal que
eficiencia = eficiencia(motor, carrocera, peso).
Un ejemplo más sencillo
A veces es fácil encontrar dependencias en un esquema. Esto es un indicado de un mal modelo entidad-relación o de una mala conversión a relacional. Por ejemplo, sea Película(título, año, estudio, presidente, fono presidente). Digamos que "título" es llave de la relación (determina todo). Sin embargo, notemos que el presidente de un estudio se puede determinar conociendo el estudio y el año (idealmente).
Luego, estudio, año --> presidente. Además, es claro que presidente --> fono_presidente. La relación "Película" fue mal modelada desde un principio. En un modelo entidad-relación,"Película", "Estudio" y "Presidente" habrían sido entidades distintas, luego relaciones distintas en el modelo relacional.
Una dependencia funcional en una relación R es un enunciado de la forma "si dos tuplas de R concuerdan en los atributos A1,A2,...An (tienen los mismos valores para cada atributo), entonces deben concordar también con otro atributo B" . Esta FD se escribiría como A1,A2,....An --> B y se dice que "A1, A2,....An determina funcionalmente a B".
Movies(title, year, length, filmType, studioName, starName)
title
year
length
filmType
studioName
starName
Star Wars
1977
124
color
Fox
Carrie Fisher
Star Wars
1977
124
color
Fox
Mark Hamill
Star Wars
1977
124
color
Fox
Harrison Ford
Mighty Ducks
1991
104
color
Disney
Emilio Estevez
Wayne's World
1992
95
color
Paramount
Dana Carvey
Wayne's World
1992
95
color
Paramount
Mike Meyers
title, year --> length
title, year --> filmType
title, year --> studioName
title, year -/-> starName
Podemos entonces afirmar que: title, year --> length, filmType, studioName
Quizás las dependencias funcionales más evidentes sean las llaves.
4.4 Segunda Forma Normal
Una tabla está en la Segunda Forma Normal si:
· Está en la Primera Forma Normal, y
· Cada atributo que no es una clave es funcionalmente dependiente de la clave completa.
Las tablas en la Primera Forma Normal suelen presentar características que tienden a dificultar su uso. Estas características son reconocibles, y suelen eliminarse sometiendo a las tablas a una o más transformaciones.
Considere la tabla siguiente, que contiene información que describe a un grupo de estudiantes y sus clases, y que se encuentra en la Primera Forma Normal:
ESTUDIANTES_CLASES [NOMBRE,ID-ESTUDIANTE, PROMEDIO, ID-CLASE, CALIFICACION]
Interpretaremos esto de la forma siguiente: cada fila representa un estudiante matriculado en una cláse. Si una fila determinada tiene un cierto valor para CALIFICACION, entonces el estudiante ha completado con éxito esa clase. En caso contrario, el estudiante está cursando todavía la clase. La figura siguiente contiene unos datos de muestra para esta tabla. Los tres primeros atributos contienen información específica de cada estudiante, mientras que el resto de la información es específica de la clase. El último atributo representa la calificación alcanzada por el estudiante en esa clase concreta, y se dejará en blanco si aún no ha concluido.
Tabla ESTUDIANTES-CLASES
NOMBRE
(Clave)
ID-ESTUDlANTE
PROMEDIO
(Clave)
ID-CLASE
CALIFICACION
Huertas, J.
01234
5.4
FIS-1A
A
Ferrero, A.
22346
5.1
FIS-1A
B
Soriano, P.
11349
4.8
QUIM-2B
A
Huertas, J.
01234
5.4
QUIM-2B
A
Clemente, C.
08349
5.9
MUS-5
B
Pérez, R.
03472
5.1
ARTE-3A
-
Ferrero, A.
22346
5.1
QUIM-1A
C
Huertas, J.
01234
5.4
MUS-5
B
Vázquez, H.
33461
4.9
ARTE-3A
-
Pérez, R
03472
5.1
MUS1
-
Redundancia de datos
Un examen de esta tabla revela varios problemas bastante serios, el primero de ellos es que una gran cantidad de información está siendo almacenada de forma redundante. Por ejemplo, los valores de NOMBRE, ID-ESTUDlANTE y PROMEDIO están siendo almacenados por triplicado para el estudiante "Huertas, J.".
También existen otras duplicaciones.
Siempre que sea posible, deberían evitarse las duplicaciones de datos, por diversas razones:
Espacio de almacenamiento de datos. La información duplicada requiere un espacio extra de almacenamiento, habitualmente en los dispositivos de disco magnético. Aunque el coste de las unidades de disco está descendiendo con rapidez, aún no resultan gratuitas, y una buena base de datos debe siempre intentar conseguir la mínima cantidad de espacio de almacenamiento que sea capaz de satisfacer los requerimientos del usuario.
Costes de introducción de datos. Una gran parte de la información de la base de datos debe ser introducida de forma manual, por personal específico. La existencia de datos redundantes suele implicar un tiempo de introducción de datos extra, que en el análisis final se traduce en costes adicionales.
Inconsistencias de la base de datos. Si se introduce información redundante, las posibilidades de inconsistencias aumentan de forma proporcional. Por ejemplo, el PROMEDIO de "Huertas, J." se introduce tres veces en la tabla ESTUDIANTES-CLASES, con lo cual se triplica la probabilidad de introducción de un valor incorrecto para este dato.
Anomalías de modificación
La presencia de redundancia de datos viene casi siempre acompañada de varias dificultades predecibles; estas dificultades saldrán a la luz cuando comience a manipularse la información del interior de la tabla. Estos problemas, conocidos colectivamente bajo el nombre de anomalías de modificación, aparecen durante la actualización, borrado e inserción de datos.
Anomalías de actualización. Suponga que el PROMEDIO del estudiante "Huertas, J." cambia de 5.4 a algún otro valor, quizá como resultado de un cambio en la calificación de una clase. Como el valor de PROMEDIO está almacenado en varias columnas de ESTUDIANTES-CLASES, es necesario buscar en toda la tabla, y realizar cambios cada vez que aparece PROMEDIO para "Huertas, J.". Este procedimiento de búsqueda y modificación no sólo consume una gran cantidad de tiempo, sino que también facilita la posibilidad de inconsistencias, bien debidas a error humano, si se realiza de forma manual, o bien debida a fuentes del sistema, tales como interrupciones hardware durante el proceso de actualización. En cualquiera de los casos, el resultado sería una tabla con información inconsistente.
De cualquier forma, la alteración de un único hecho, en este caso la modificación del valor de un PROMEDIO, requiere la modificación de varias entradas de la tabla, proceso que consume gran cantidad de tiempo y es propenso a los errores. Este tipo de situaciones es lo que se conoce como anomalías de actualización, y su existencia sugiere que el diseño de la tabla podría mejorarse.
Anomalías de borrado. Supongamos que un estudiante que acaba de matricularse deja de asistir a todas sus clases. pero sin abandonar la escuela. Todas las filas de dicho estudiante habrán de ser borradas de la tabla ESTUDIANTES-CLASES. Sin embargo, cuando se ha hecho esto, la información básica relativa a dicho estudiante, como el nombre y el número de ID, se han perdido de la tabla. En otras palabras, en lo que concierne a la base de datos, el estudiante ha dejado de existir, incluso aunque de hecho todavía esté matriculado en la escuela. La información de la base de datos no se corresponde ya con los hechos del mundo real, y decimos que ha ocurrido una anomalía de borrado.
Anomalías de inserción. Supongamos que un nuevo alumno se matricula en la escuela, pero que, por diversas razones, no se matricula de inmediato en ninguna clase concreta. Debido al diseño de la tabla ESTUDIANTES-CLASES, cada fila representa a un estudiante matriculado en una clase. Por lo tanto, cada fila debería contener un valor para ID-CLASE. Sin embargo, la fila del nuevo estudiante puede ser introducida con un valor especial para ID-CLASE, que indica que el estudiante no está asistiendo a nunguna clase. Más adelante, cuando el estudiante se matricule en algún curso concreto, esta fila original pasará a ser un estorbo en la base de datos, y tendrá que ser eliminada. De hecho, el permitir la existencia de este tipo especial de fila complica casi todas las operaciones que se efectúan con la tabla.
Este tipo de situación se denomina anomalía de inserción: el hecho del mundo real, en este caso el registro de un nuevo estudiante, no puede ser descrito convenientemente por la base de datos, debido a su diseño.
La fuente de las anomalías de modificación
Los diversos tipos de anomalías de modificación descritos no son problemas imposibles de abordar, pero pueden complicar de forma seria el uso eficiente de una base de datos. Sería preferible si las anomalías pudieran ser eliminadas, y de hecho, esto puede hacerse, mediante el estudio de la fuente original de las dificultades.
Veremos que el comportamiento anómalo está relacionado directamente con la presencia de la redundancia de datos: ambos problemas surgen de la forma en que está estructurada la tabla ESTUDIANTES-CLASES, y ambos pueden ser eliminados mediante una transformación adecuada de la tabla.
Para atacar el problema, formúlese la siguiente pregunta: ¿cuáles son los hechos básicos representados por la tabla ESTUDIANTES-CLASES? La respuesta es sencillamente que cada fila de la tabla representa a un estudiante concreto matriculado en una clase específica. Existe, por tanto, un segundo hecho independiente contenido en cada fila: la propia existencia del estudiante. Es decir, cada fila contiene información que es específica del estudiante, tal como el PROMEDIO, y estos datos son independientes de las clases representadas en cada fila. Este es el núcleo del problema: cuando hay varias filas que corresponden a un estudiante determinado, los datos específicos del estudiante se repiten en cada una de ellas.
A la vista de esto, y estudiando los datos de la tabla de la figura 1, se llega a la siguiente conclusión: el problema de la redundancia de datos y de las anomalías de actualización de la tabla ESTUDIANTES-CLASES surge específicamente porque cada fila de la tabla contiene dos hechos independientes.
Otro punto de vista: Antes de ilustrar la transformación de la tabla que elimina tanto la redundancia de datos como las anomalías de modificación, volvemos a examinar la misma situación desde una perspectiva diferente: la de las claves, y sus dependencias funcionales. Esta aproximación proporcionará una forma mucho más abreviada y directa de tratar las mismas situaciones. Considere las dos preguntas siguientes:
1. ¿Cuál es la clave de la tabla ESTUDIANTES-CLASES?
2. ¿Qué dependencias funcionales existen dentro de esta tabla?
Como cada fila representa una combinación determinada de clase y estudiante, una elección razonable como clave sería la combinación de ID-ESTUDIANTE + ID-CLASE.
A continuación enumeramos todas las dependencias funcionales existentes entre los atributos de la tabla:
ID-ESTUDIANTE + ID-CLASE ® CALIFICACION
ID-STUDIANTE ® NOMBRE
PROMEDIO
Vamos a examinar ahora las dos nuevas tablas, ESTUDIANTE y ESTUDIANTE-CLASE, para comprobar si ha mejorado alguno de los problemas asociados con la tabla original ESTUDIANTES-CLASES. Un cambio que puede verse inmediatamente es que la situación de redundancia de datos ha mejorado enormemente. En concreto, los datos básicos de cada estudiante aparecen ahora una única vez, en la tabla ESTUDIANTE.
Tabla: ESTUDIANTE
NOMBRE
(Clave) ID-ESTUDlANTE
PROMEDIO
Huertas, J.
01234
5.4
Ferrero, A.
22346
5.1
Soriano, P.
11349
4.8
Clemente, C.
08349
5.9
Pérez, R.
03472
5.1
Vázquez, H.
33461
4.9
Tabla: ESTUDIANTE-CLASE
(Clave) ID-ESTUDlANTE
(Clave) ID-CLASE
CALIFICACION
01234
FIS-1A
A
22346
FIS-1A
B
11349
QUIM-2B
A
01234
QUIM-2B
A
08349
MUS-5
B
03472
ARTE-3A
-
22346
QUIM-1A
C
01234
MUS-5
B
33461
ARTE-3A
-
03472
MUS1
-
Podría parecer que existe aún alguna redundancia en las nuevas tablas. Por ejemplo, un valor de ID-ESTUDIANTE de "01234" aparece tres veces en ESTUDIANTE-CLASE. Sin embargo, esto es una consecuencia inevitable del hecho de que este estudiante está asociado con tres clases. Uno de los objetivos del proceso de normalización consiste en reducir la cantidad de redundancia de datos al mínimo absoluto, que se ha conseguido mediante las tablas ESTUDIANTE y ESTUDIANTE-CLASE.
La descomposición de la tabla ESTUDIANTE-CLASE ha eliminado asimismo la posibilidad de anomalías de modificación, tratada anteriormente. A continuación examinaremos cada tipo de anomalía realizada anteriormente a la luz de las nuevas tablas.
Anomalías de actualización: Si es necesario cambiar el valor del PROMEDIO de un estudiante determinado, sólo es preciso alterar el valor de una única fila de la tabla ESTUDIANTE. Recuerde que en la tabla original había que modificar gran número de entradas para cada estudiante.
Anomalías de borrado: Si un estudiante abandona todas sus asignaturas, pero sigue aún matriculado en la escuela, puede existir aún una entrada en la tabla ESTUDIANTE, incluso aunque no existan entradas para ese estudiante en ESTUDIANTE-CLASE.
Anomalías de inserción: También han desaparecido las posibilidades que existían de anomalías de inserción: es posible crear una entrada en la tabla ESTUDIANTE para un estudiante nuevo que aún no se haya matriculado en ninguna clase. A medida que el estudiante se vaya matriculando en cursos nuevos, se pueden ir creando entradas nuevas en la tabla ESTUDIANTE-CLASE.
