Problemas de malos diseños Sabemos ya que la gran mayoría de los SGBDs comerciales son relacionales, es decir, basados en la organización de la información por medio de tablas. Si contamos con un gestor de este tipo, diseñar una BD consistirá, por lo tanto, en diseñar las tablas (y su estructura) que nos permitirán representar y almacenar la información que necesitemos mantener en la BD. Desgraciadamente, el proceso de diseño de esas tablas no es tan sencillo como pudiera parecer en un principio. Un mal diseño puede conducir a graves problemas de redundancia de información, que en último extremo puede dar lugar a su vez a problemas de inconsistencia más graves aún. Este documento esta destinado a presentar algunos de esos problemas a partir de un ejemplo ilustrativo. El ejemplo El ejemplo que utilizaremos es el de una base de datos en la que pretendemos almacenar información sobre un instituto. Más en concreto, deseamos almacenar información sobre los profesores del instituto y las asignaturas que se imparten. Hablando de datos más concretos, debemos registrar el DNI de los profesores, su nombre y apellidos, y su teléfono; y de cada asignatura, almacenaremos su código, nombre completo, y su tipo (optativa u obligatoria). Asumiremos también que un profesor puede tener asignada docencia en cuantas asignaturas sea necesario; que una asignatura puede ser impartida por más de un profesor en un momento dado; y que, si un profesor imparte una asignatura, dará clase a todos los alumnos matriculados en esa asignatura. Pretendemos mantener los datos de todos los profesores en plantilla, tengan docencia asignada o no en el momento actual. El primer diseño Un primer diseño de la BD que podría satisfacer las necesidades de información del ejemplo es el que se muestra en la figura siguiente. En este primer diseño se opta por una única tabla que permite mantener toda la información. Esa tabla cuenta con columnas suficientes para representar el código, nombre y tipo de cada asignatura, y el DNI, nombre y apellidos de cada uno de los profesores de esa asignatura. En esta otra figura, la tabla contiene una fila con los datos de una asignatura (BDDOC) impartida por un determinado profesor (Mon López). Autor: Juan Ramón López Rodríguez 1
Los problemas surgen cuando comenzamos a rellenar la tabla con nuevos datos. Existen tres operaciones básicas de actualización del contenido de una tabla: Inserción de información Borrado de información Modificación de información Veremos que, en el contexto de un mal diseño de la base de datos, cada una de estas tres operaciones tiene intrínsecamente asociado una serie de problemas o anomalías específicas: Anomalías de inserción Anomalías de borrado Anomalías de modificación Anomalías de inserción Veremos a continuación que podemos encontrarnos con problemas al agregar nueva información al contenido de una tabla mal diseñada. Supongamos que una nueva profesora (Marta Barbeito) se incorpora al centro. En principio, podríamos pensar que añadir nueva información, como esta, a la BD, debería implicar una simple adición de nuevas filas a nuestra tabla. Nada más lejos de la realidad: añadir, tal y como está estructurada la tabla, nueva información sobre la profesora es más complicado. Si no se le ha asociado todavía la docencia de ninguna asignatura, se puede añadir, efectivamente, una nueva fila con sus datos personales, pero nos veremos obligados a dejar en blanco la información sobre las materias en las que impartirá docencia. Cuando queramos, más adelante, añadir una asignatura a la lista de las impartidas por Marta, se nos planteará una disyuntiva: o Añadir una nueva fila con los datos de Marta y la asignatura nueva? Eso implica repetir los datos de Marta en dos filas diferentes: se trata de un caso de redundancia de información, que sólo podrá ser anulada eliminando la fila inicial con información sobre Marta. 02 DRI No o Modificar la fila ya existente con los datos de Marta, y añadir los datos de la asignatura? Autor: Juan Ramón López Rodríguez 2
02 DRI No Eso implica que para añadir nueva información a la BD (el hecho de que Marta imparte DRI) nos vemos obligados a: 1. Comprobar si ya existe una fila en la tabla con información sobre Marta. 2. Si la hay, modificarla. 3. Si no, dar de alta una nueva fila con los datos de Marta y la asignatura de DRI. Como se puede apreciar, una operación de inserción aparentemente sencilla se convierte en compleja: la operación se complica por un mal diseño de la tabla. Otro caso: supongamos que al dar de alta a Marta ya sabemos que va a impartir docencia en una asignatura: BDDoc, que casualmente ya aparece en la tabla como impartida por Mon. Creamos una nueva fila en la tabla con los datos de Marta; y nos vemos obligados a repetir en ella exactamente toda la información correspondiente a la asignatura. De no hacerlo así, aperecería información diferente sobre la misma materia en dos filas distintas Cómo saber entonces cuál es la buena? Y al hacerlo así, estamos introduciendo redundancia en la tabla para mantener su consistencia. Conclusiones Cuál es la conclusión que podemos extraer del análisis de estos ejemplos? La inserción de información en una tabla mal diseñada puede conllevar problemas de diferente tipo: El más grave de ellos: una simple operación de adición de información puede complicarse en demasía: añadir nueva información a una tabla no implica añadir simplemente una nueva fila (que sería lo deseable), sino que puede ser necesario también modificar o eliminar la información previamente incluida en otras ya existentes previa comprobación, además) El más leve: podemos vernos obligados a repetir la misma información varias veces en diferentes filas de la tabla (redundancia), algo que va a provocar anomalías de otro tipo, como veremos más adelante Ejercicio propuesto Autor: Juan Ramón López Rodríguez 3
Buscar algún ejemplo de anomalía de inserción en el caso de que se quiera dar de alta una nueva asignatura en la BD Anomalías de borrado Asumamos que tenemos registrada en nuestra BD la siguiente información: 02 DRI No Como se puede apreciar, se indica que un profesor, Mon imparte dos asignaturas (DRI y BDDOC) y que otra profesora (Marta) comparte la docencia de BDDOC. Supongamos que en este momento debemos dar de baja a Mon como profesor de BDDOC. En principio, para hacerlo es suficiente con eliminar de la tabla la fila que asocia a Mon con la asignatura. 02 DRI No El estado de la tabla será ahora el siguiente: 02 DRI No Supongamos ahora que Mon también deja de ser el profesor de la asignatura de DRI: se nos presenta un problema, ya que no podemos eliminar sin más la fila que asocia al profesor con la materia. Perderíamos la información relativa al profesor, y a la asignatura! 02 DRI No La única solución que nos queda, para no perder esa información, es dar de alta dos nuevas filas con información (por separado) relativa a la materia y al profesor. 02 DRI No Conclusiones Autor: Juan Ramón López Rodríguez 4
Dar de baja información en una tabla mal diseñada no siempre se reduce a eliminar ciertas filas: puede implicar la inserción (paradójicamente) de nuevas filas en la tabla, para evitar perder más información de la debida. Ejercicio propuesto Comprobar si, partiendo de la tabla original de este apartado, la baja de una persona como profesor del centro podría dar lugar a anomalías de borrado. Anomalías de modificación. Para presentar un ejemplo de anomalías de modificación, volveremos a utilizar la tabla de partida de la sección anterior. 02 DRI No En esa tabla, dos filas indican que Mon López es el profesor de un par de asignaturas. En ambas filas nos vemos obligados, en principio, a repetir exactamente toda la información correspondiente a Mon, para mantener la consistencia de la tabla. Supongamos que la extensión de telefónica de Marta (como las del resto de los profesores, por cambios en la gestión del centro) es modificada, pasando a ser de cuatro dígitos. Un cambio en un cierto dato debería restringirse en la tabla, idealmente, a un cambio en la información recogida en una única fila. Y, en efecto, dado que la extensión de Marta aparece en una única fila, ese es el único cambio que hay que realizar. 02 DRI No 47B Marta Barbeito 1333 Y qué sucede con Mon? Cambiar su extensión no es sencillo: aparece en varias filas (una por cada asignatura impartida por este profesor). El número de filas afectadas por la modificación de un único dato es, pues, difícil de prever. Así, podemos afirmar que la redundancia de información puede dar lugar a anomalías de modificación. 02 DRI No 35X Mon López 1666 35X Mon López 1666 47B Marta Barbeito 1333 Conclusiones Autor: Juan Ramón López Rodríguez 5
La modificación de información elemental en una tabla mal diseñada se complica cuando el diseño induce la redundancia de información: la modificación de un único dato puede requerir la modificación de múltiples filas. Ejercicio propuesto Comprobar si la redundancia introducida en las tablas de la primera sección de este documento (anomalías de inserción) podría dar lugar a anomalías de modificación. Diseño alternativo Hemos dicho (y demostrado) que el mal diseño de las tablas de una BD puede producir todo tipo de anomalías a la hora de actualizar la información almacenada en dicha BD. Sin embargo por qué el diseño propuesto en este documento es un mal diseño? Básicamente, el problema se reduce a lo siguiente: estamos incluyendo, en la misma tabla, informaciónes de diferente naturaleza, que deberían ser tratadas de forma independiente. Las propiedades esenciales de un profesor (DNI, nombre completo, extensión) poco tienen que ver con las propiedades esenciales de una asignatura (código, nombre, obligatoriedad). El único nexo de unión entre los dos es la posibilidad de que un profesor imparta un asignatura. Pero que profesor y asignatura estén relacionados (o no) no modifica en modo alguno sus características esenciales y definitorias. Mezclar informaciones tan dispares en una tabla conduce a la necesidad de introducir redundancia (ver ejemplos anteriores) en la información registrada, redundancia que termina por dar lugar a las anomalías descritas. Un buen diseño de nuestra BD debe pasar, por lo tanto, por la descomposición de la tabla de partida, separando los diferentes componentes de información y manteniendo unidos sólo aquellos íntimamente ligados. Por eso, descomponemos la tabla original en dos tablas: una con información exclusiva de las asignaturas, y otra con información sobre los profesores. Código Nombre Obligatoria DNI Nombre Apellidos Tlf Para poder saber qué profesores imparten qué asignaturas, estas dos tablas no son suficientes. Creamos pues una tabla nueva en la que combinamos la mínima información imprescindible sobre ambos elementos. Código DNI Es fácil comprobar que, con este diseño, las anomalías antes expuestas desaparecen: Inserción: Es sencillo dar de alta, en esta BD, a la nueva profesora Marta Barbeito, añadiendo una única nueva fila en la tabla de profesores. Autor: Juan Ramón López Rodríguez 6
Código DNI Añadir una nueva materia también implica añadir una única fila, esta vez en la tabla de asignaturas: Código Nombre Obligatoria 02 DRI No Código DNI DNI Nombre Apellidos Tlf Y asignar nuevas materias a Marta y Mon implica también añadir, respectivamente, una única fila en otra de las tablas: Código Nombre Obligatoria 02 DRI No Código DNI 02 35X 01 47B DNI Nombre Apellidos Tlf Como se puede ver, en ningún caso se introduce redundancia ni es necesario modificar o eliminar filas ya existentes. Borrado: Dar de baja a Mon como profesor de DRI y BDDOC implica eliminar únicamente las dos filas correspondientes. No se pierde más información de la necesaria. Seguimos manteniendo información sobre el profesor y sobre las asignaturas (ahora por separado). Y, por supuesto, no es necesario ningún otro tipo de operación adicional al borrado de filas: Modificación: Código Nombre Obligatoria 02 DRI No Código DNI 02 35X 01 47B DNI Nombre Apellidos Tlf Autor: Juan Ramón López Rodríguez 7
Modificar la extensión de Mon o de Marta implica la modificación de dos filas (una por cada uno de ellos). Ya no hay redundancia, y las anomalías desaparecen. Código Nombre Obligatoria 02 DRI No Código DNI 02 35X 01 47B DNI Nombre Apellidos Tlf 35X Mon López 1666 47B Marta Barbeito 1333 Conclusiones El diseño de las tablas que componen la estructura de una BD no es sencillo. Es más que probable, si la BD presenta una complejidad relativamente alta, realizar un diseño que de lugar a anomalías de inserción, modificación o borrado. Con relativo esfuerzo, podemos llegar a un diseño correcto, pero qué pasará cuando llegue el momento de realizar algún cambio en el diseño? Convertirán las modificaciones al diseño en incorrecto? Dado que el diseño directo de las tablas resulta una tarea complicada, lo normal es proceder de forma gradual: para diseñar una base de datos, lo que haremos será desempeñar una metodología en varias etapas, que nos permitirá llegar a un diseño de tablas correcto de una forma intuitiva y sencilla: comenzaremos por un análisis a alto nivel de las necesidades de información, sin tener en cuenta inicialmente cuestiones de implementación, y iremos descendiendo progresivamente de nivel, hasta llegar a los detalles físicos de construcción de la base de datos. Las fases genéricas que comprende habitualmente una metodología de este tipo son: Análisis de requerimientos Diseño conceptual Diseño lógico Diseño físico Durante la fase inicial de análisis de requerimientos, deberemos determinar qué información deseamos recoger en nuestra base de datos, sin prestar atención, por el momento, a cómo vamos a almacenarla. Y, dado que la información se almacena por algún motivo, deberá ser determinados también el uso que se le va a dar a esa información: la utilidad que se le va a dar. Eso implica decidir la funcionalidad de los programas y aplicaciones informáticas que van a acceder a la BD. Toda la información que se necesita durante esta fase se determina principalmente a través de entrevistas y reuniones con los futuros usuarios (que son los que habitualmente conocen mejor que nadie sus propias necesidades). En ocasiones será oportuno también contar con el asesoramiento de especialistas en el tema considerado. Una vez determinados los requerimientos de la base de datos, será el turno de la fase de diseño conceptual. Esta etapa está destinada a la elaboración un modelo de datos de alto nivel (el esquema conceptual), que constituya una fiel descripción de la información que Autor: Juan Ramón López Rodríguez 8
se almacenará en la base de datos, incluyendo todos los elementos de información necesarios y las dependencias y relaciones entre los mismos. La idea es que el esquema conceptual describa, en términos asequibles y sencillos, aquella parte del mundo real que nos interesa representar o reflejar en la BD. Para preservar la claridad y sencillez del esquema, este no deberá incluir, bajo ningún concepto, detalles de implementación; eso significa que la definición de las tablas que estructurarán la base de datos debe dejarse para más adelante. Además, se deberá huir en lo posible del uso de cualquier tipo de terminología informática. Esto permitirá a los futuros usuarios de la BD, personas no familiarizadas con ese tipo de conceptos, colaborar en su validación final, para asegurarse que refleje realmente todas sus necesidades de información. Comenzar a diseñar la información a nivel conceptual tiene dos ventajas: por un lado, al obviar las cuestiones de implementación, la descripción es independiente de la elección de cualquier tipo de SGBD, que puede ser pospuesta hasta un momento más avanzado del proceso de desarrollo de la BD. Por otro lado, realizar una descripción a alto nivel de los datos simplifica inicialmente el problema de organizar la información: para nosotros será más asequible describir un problema utilizando conceptos y términos con los que nos encontremos plenamente familiarizados - ciñéndonos a la descripción de la información en sí - en lugar de tener que emplear cualquier clase de jerigonza informática, y estar obligados a diseñar estructuras tales como unas tablas, de acuerdo con unas reglas y un formato determinado. Quién piensa en tablas en la vida real? Estamos acostumbrados a manejar conceptos como el de libro, biblioteca, socio, préstamo, alumno, asignatura, matrícula, empleado, contrato... Lamentablemente, una organización de los datos a tan alto nivel será difícilmente interpretable y manipulable por un programa informático, o por un SGBD. Por lo tanto no será posible utilizarla directamente para nuestro propósito de construir una BD. Sin embargo, es posible realizar la definición del esquema conceptual de tal modo que sirva como base o referencia para un diseño de más bajo nivel (donde ya se defina, por ejemplo, la estructura de aquellas tablas en las que se vayan a almacenar los datos). Es en la etapa de diseño lógico en la que se lleva a cabo esa tarea. El esquema lógico constituye una descripción a un nivel menor de abstracción de las estructuras que permitirán almacenar la información. Esta etapa implica ya la selección de un determinado tipo de SGBD (normalmente un SGBD relacional) que prescriba las estructuras a definir (normalmente tablas). Además, al tiempo que se diseñe el esquema lógico de la BD será realizado el diseño de los programas que accederán a la base de datos. La última etapa es la de diseño físico de la BD. En esta fase, habiendo ya seleccionado un SGBD concreto, es necesario adaptar el diseño lógico de la BD a la organización interna del sistema: deben definirse las estructuras de almacenamiento internas, el formato de los archivos en los que el SGBD almacenará la información, y los métodos de acceso a los mismos, que permitirán la manipulación de la información. El diseño físico de la BD va acompañado, habitualmente, de la construcción e implementación de los programas informáticos que accederán a la misma. Autor: Juan Ramón López Rodríguez 9
Modelos de datos Hemos visto que el diseño de una BD comprende varias fases, siendo el resultado de cada una de ellas una descripción (a diferente nivel de abstracción) de la información a representar en la BD. La pregunta que surge es cómo deben ser esas descripciones? Para facilitar su realización, contamos con diferentes modelos de datos de referencia. Esos modelos constituyen una guía para la realización de las descripciones, proporcionándonos los conceptos, estructuras y elementos a emplear, y la forma de utilizarlos y presentarlos. El modelo entidad-relación (o modelo ER) es un modelo de datos de alto nivel, que permite utilizar conceptos muy cercanos a los utilizados por el razonamiento humano. De acuerdo con este modelo, la realidad está constituida por entidades (objetos del mundo real con existencia tangible y distinguible, tales como un libro, un alumno, una biblioteca o un socio de la biblioteca) y relaciones entre esas entidades (la vinculación entre un socio y una biblioteca, por ejemplo). Y esa debe ser la visión que debe reflejar toda descripción realizada en base al modelo. Su cercanía al modo humano de percibir e interpretar la realidad lo convierte en un modelo idóneo para utilizar en la definición del esquema conceptual de una base de datos. El modelo relacional es un modelo mucho más cercano a una interpretación de la realidad asequible para un programa informático. Los elementos manejados por el modelo relacional son las relaciones (no confundir con las relaciones del modelo ER), una suerte de tablas que contienen datos sobre la realidad a representar en la BD. Es por ello que suele ser el modelo de referencia más utilizado para la definición del esquema lógico de una BD. Autor: Juan Ramón López Rodríguez 10
Bibliografía - R. Elmasri y S. Navathe. Fundamentos de los Sistemas de Bases de Datos (3ª edición). Addison-Wesley, 2002. - A. Silberschatz, H. F. Korth y S. Sudarshan. Fundamentos de Bases de Datos (4ª edición). McGraw Hill, 2002 Autor: Juan Ramón López Rodríguez 11