2 1 - ProblemasDeMalosDisenos

Grao en Informacin e Documentacin: Bases de datos documentais Curso 2013 2014
Autor: Juan Ramn Lpez Rodrguez 1

Problemas de malos diseos
Sabemos ya que la gran mayora de los SGBDs comerciales son relacionales, es decir,
basados en la organizacin de la informacin por medio de tablas. Si contamos con un
gestor de este tipo, disear una BD consistir, por lo tanto, en disear las tablas (y su
estructura) que nos permitirn representar y almacenar la informacin que necesitemos
mantener en la BD.
Desgraciadamente, el proceso de diseo de esas tablas no es tan sencillo como pudiera
parecer en un principio. Un mal diseo puede conducir a graves problemas de redundancia
de informacin, que en ltimo extremo puede dar lugar a su vez a problemas de
inconsistencia ms graves an. 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
informacin sobre un instituto. Ms en concreto, deseamos almacenar informacin sobre
los profesores del instituto y las asignaturas que se imparten. Hablando de datos ms
concretos, debemos registrar el DNI de los profesores, su nombre y apellidos, y su telfono;
y de cada asignatura, almacenaremos su cdigo, nombre completo, y su tipo (optativa u
obligatoria).
Asumiremos tambin que un profesor puede tener asignada docencia en cuantas asignaturas
sea necesario; que una asignatura puede ser impartida por ms 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 diseo
Un primer diseo de la BD que podra satisfacer las necesidades de informacin del
ejemplo es el que se muestra en la figura siguiente.
Cdigo Nombre Obligatoria DNI Nombre Apellidos Tlf

En este primer diseo se opta por una nica tabla que permite mantener toda la
informacin. Esa tabla cuenta con columnas suficientes para representar el cdigo, 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 Lpez).
01 BDDOC Si 35X Mon Lpez 666


Los problemas surgen cuando comenzamos a rellenar la tabla con nuevos datos. Existen
tres operaciones bsicas de actualizacin del contenido de una tabla:
Insercin de informacin
Borrado de informacin
Modificacin de informacin
Veremos que, en el contexto de un mal diseo de la base de datos, cada una de estas tres
operaciones tiene intrnsecamente asociado una serie de problemas o anomalas
especficas:
Anomalas de insercin
Anomalas de borrado
Anomalas de modificacin
Anomalas de insercin
Veremos a continuacin que podemos encontrarnos con problemas al agregar nueva
informacin al contenido de una tabla mal diseada.
Supongamos que una nueva profesora (Marta Barbeito) se incorpora al centro. En
principio, podramos pensar que aadir nueva informacin, como esta, a la BD, debera
implicar una simple adicin de nuevas filas a nuestra tabla. Nada ms lejos de la realidad:
aadir, tal y como est estructurada la tabla, nueva informacin sobre la profesora es ms
complicado.
Si no se le ha asociado todava la docencia de ninguna asignatura, se puede aadir,
efectivamente, una nueva fila con sus datos personales, pero nos veremos obligados
a dejar en blanco la informacin sobre las materias en las que impartir docencia.
47B Marta Barbeito 333

Cuando queramos, ms adelante, aadir una asignatura a la lista de las impartidas
por Marta, se nos plantear una disyuntiva:
o Aadir 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 informacin, que slo podr ser anulada eliminando la
fila inicial con informacin sobre Marta.
02 DRI No 47B Marta Barbeito 333

o Modificar la fila ya existente con los datos de Marta, y aadir los datos de
la asignatura?

02 DRI No 47B Marta Barbeito 333
Eso implica que para aadir nueva informacin 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 informacin
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 operacin de insercin aparentemente sencilla
se convierte en compleja: la operacin se complica por un mal diseo 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 informacin
correspondiente a la asignatura. De no hacerlo as, aperecera informacin diferente
sobre la misma materia en dos filas distintas Cmo saber entonces cul es la
buena? Y al hacerlo as, estamos introduciendo redundancia en la tabla para
mantener su consistencia.
01 BDDOC Si 47B Marta Barbeito 333
Conclusiones
Cul es la conclusin que podemos extraer del anlisis de estos ejemplos? La insercin de
informacin en una tabla mal diseada puede conllevar problemas de diferente tipo:
El ms grave de ellos: una simple operacin de adicin de informacin puede
complicarse en demasa: aadir nueva informacin a una tabla no implica aadir
simplemente una nueva fila (que sera lo deseable), sino que puede ser necesario
tambin modificar o eliminar la informacin previamente incluida en otras ya
existentes previa comprobacin, adems)
El ms leve: podemos vernos obligados a repetir la misma informacin varias veces
en diferentes filas de la tabla (redundancia), algo que va a provocar anomalas de
otro tipo, como veremos ms adelante

Ejercicio propuesto

Buscar algn ejemplo de anomala de insercin en el caso de que se quiera dar de alta una
nueva asignatura en la BD
Anomalas de borrado
Asumamos que tenemos registrada en nuestra BD la siguiente informacin:
02 DRI No 35X Mon Lpez 666
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.
El estado de la tabla ser ahora el siguiente:
Supongamos ahora que Mon tambin deja de ser el profesor de la asignatura de DRI: se nos
presenta un problema, ya que no podemos eliminar sin ms la fila que asocia al profesor
con la materia. Perderamos la informacin relativa al profesor, y a la asignatura!
La nica solucin que nos queda, para no perder esa informacin, es dar de alta dos nuevas
filas con informacin (por separado) relativa a la materia y al profesor.
02 DRI No
35X Mon Lpez 666

Conclusiones

Dar de baja informacin en una tabla mal diseada no siempre se reduce a eliminar ciertas
filas: puede implicar la insercin (paradjicamente) de nuevas filas en la tabla, para evitar
perder ms informacin de la debida.
Ejercicio propuesto
Comprobar si, partiendo de la tabla original de este apartado, la baja de una persona
como profesor del centro podra dar lugar a anomalas de borrado.
Anomalas de modificacin.
Para presentar un ejemplo de anomalas de modificacin, volveremos a utilizar la tabla de
partida de la seccin anterior.
En esa tabla, dos filas indican que Mon Lpez es el profesor de un par de asignaturas. En
ambas filas nos vemos obligados, en principio, a repetir exactamente toda la informacin
correspondiente a Mon, para mantener la consistencia de la tabla.
Supongamos que la extensin de telefnica de Marta (como las del resto de los profesores,
por cambios en la gestin del centro) es modificada, pasando a ser de cuatro dgitos. Un
cambio en un cierto dato debera restringirse en la tabla, idealmente, a un cambio en la
informacin recogida en una nica fila. Y, en efecto, dado que la extensin de Marta
aparece en una nica fila, ese es el nico cambio que hay que realizar.
Y qu sucede con Mon? Cambiar su extensin no es sencillo: aparece en varias filas (una
por cada asignatura impartida por este profesor). El nmero de filas afectadas por la
modificacin de un nico dato es, pues, difcil de prever. As, podemos afirmar que la
redundancia de informacin puede dar lugar a anomalas de modificacin.

Conclusiones

La modificacin de informacin elemental en una tabla mal diseada se complica cuando el
diseo induce la redundancia de informacin: la modificacin de un nico dato puede
requerir la modificacin de mltiples filas.
Ejercicio propuesto
Comprobar si la redundancia introducida en las tablas de la primera seccin de este
documento (anomalas de insercin) podra dar lugar a anomalas de modificacin.
Diseo alternativo
Hemos dicho (y demostrado) que el mal diseo de las tablas de una BD puede producir
todo tipo de anomalas a la hora de actualizar la informacin almacenada en dicha BD. Sin
embargo por qu el diseo propuesto en este documento es un mal diseo?
Bsicamente, el problema se reduce a lo siguiente: estamos incluyendo, en la misma tabla,
informacines de diferente naturaleza, que deberan ser tratadas de forma independiente.
Las propiedades esenciales de un profesor (DNI, nombre completo, extensin) poco tienen
que ver con las propiedades esenciales de una asignatura (cdigo, nombre, obligatoriedad).
El nico nexo de unin entre los dos es la posibilidad de que un profesor imparta un
asignatura. Pero que profesor y asignatura estn relacionados (o no) no modifica en modo
alguno sus caractersticas esenciales y definitorias. Mezclar informaciones tan dispares en
una tabla conduce a la necesidad de introducir redundancia (ver ejemplos anteriores) en la
informacin registrada, redundancia que termina por dar lugar a las anomalas descritas.
Un buen diseo de nuestra BD debe pasar, por lo tanto, por la descomposicin de la tabla
de partida, separando los diferentes componentes de informacin y manteniendo unidos
slo aquellos ntimamente ligados. Por eso, descomponemos la tabla original en dos tablas:
una con informacin exclusiva de las asignaturas, y otra con informacin sobre los
profesores.
Cdigo Nombre Obligatoria
01 BDDOC Si
Asignaturas
DNI Nombre Apellidos Tlf
35X Mon Lpez 666
Profesores
Para poder saber qu profesores imparten qu asignaturas, estas dos tablas no son
suficientes. Creamos pues una tabla nueva en la que combinamos la mnima informacin
imprescindible sobre ambos elementos.
Cdigo DNI
01 35X
Imparticin
Es fcil comprobar que, con este diseo, las anomalas antes expuestas desaparecen:
I nsercin:
Es sencillo dar de alta, en esta BD, a la nueva profesora Marta Barbeito, aadiendo una
nica nueva fila en la tabla de profesores.


01 BDDOC Si
Asignaturas
35X Mon Lpez 666
Profesores
Cdigo DNI
01 35X
Imparticin
Aadir una nueva materia tambin implica aadir una nica fila, esta vez en la tabla de
asignaturas:
01 BDDOC Si
02 DRI No
Asignaturas
35X Mon Lpez 666
Profesores
Cdigo DNI
01 35X
Imparticin
Y asignar nuevas materias a Marta y Mon implica tambin aadir, respectivamente, una
nica fila en otra de las tablas:
01 BDDOC Si
02 DRI No
Asignaturas
35X Mon Lpez 666
Profesores
Cdigo DNI
01 35X
02 35X
01 47B
Imparticin
Como se puede ver, en ningn 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 ms informacin de la necesaria. Seguimos
manteniendo informacin sobre el profesor y sobre las asignaturas (ahora por separado). Y,
por supuesto, no es necesario ningn otro tipo de operacin adicional al borrado de filas:
01 BDDOC Si
02 DRI No
Asignaturas
35X Mon Lpez 666
Profesores
Cdigo DNI
01 35X
02 35X
01 47B
Imparticin
Modificacin:

Modificar la extensin de Mon o de Marta implica la modificacin de dos filas (una por
cada uno de ellos). Ya no hay redundancia, y las anomalas desaparecen.
01 BDDOC Si
02 DRI No
Asignaturas
35X Mon Lpez 1666
Profesores
Cdigo DNI
01 35X
02 35X
01 47B
Imparticin
Conclusiones
El diseo de las tablas que componen la estructura de una BD no es sencillo. Es ms que
probable, si la BD presenta una complejidad relativamente alta, realizar un diseo que de
lugar a anomalas de insercin, modificacin o borrado. Con relativo esfuerzo, podemos
llegar a un diseo correcto, pero qu pasar cuando llegue el momento de realizar algn
cambio en el diseo? Convertirn las modificaciones al diseo en incorrecto?
Dado que el diseo directo de las tablas resulta una tarea complicada, lo normal es proceder
de forma gradual: para disear una base de datos, lo que haremos ser desempear una
metodologa en varias etapas, que nos permitir llegar a un diseo de tablas correcto de una
forma intuitiva y sencilla: comenzaremos por un anlisis a alto nivel de las necesidades de
informacin, sin tener en cuenta inicialmente cuestiones de implementacin, y iremos
descendiendo progresivamente de nivel, hasta llegar a los detalles fsicos de construccin
de la base de datos. Las fases genricas que comprende habitualmente una metodologa de
este tipo son:
Anlisis de requerimientos
Diseo conceptual
Diseo lgico
Diseo fsico
Durante la fase inicial de anlisis de requerimientos, deberemos determinar qu
informacin deseamos recoger en nuestra base de datos, sin prestar atencin, por el
momento, a cmo vamos a almacenarla. Y, dado que la informacin se almacena por algn
motivo, deber ser determinados tambin el uso que se le va a dar a esa informacin: la
utilidad que se le va a dar. Eso implica decidir la funcionalidad de los programas y
aplicaciones informticas que van a acceder a la BD. Toda la informacin que se necesita
durante esta fase se determina principalmente a travs de entrevistas y reuniones con los
futuros usuarios (que son los que habitualmente conocen mejor que nadie sus propias
necesidades). En ocasiones ser oportuno tambin 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
diseo conceptual. Esta etapa est destinada a la elaboracin un modelo de datos de alto
nivel (el esquema conceptual), que constituya una fiel descripcin de la informacin que

se almacenar en la base de datos, incluyendo todos los elementos de informacin
necesarios y las dependencias y relaciones entre los mismos. La idea es que el esquema
conceptual describa, en trminos 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 ningn
concepto, detalles de implementacin; eso significa que la definicin de las tablas que
estructurarn la base de datos debe dejarse para ms adelante. Adems, se deber huir en lo
posible del uso de cualquier tipo de terminologa informtica. Esto permitir a los futuros
usuarios de la BD, personas no familiarizadas con ese tipo de conceptos, colaborar en su
validacin final, para asegurarse que refleje realmente todas sus necesidades de
informacin.
Comenzar a disear la informacin a nivel conceptual tiene dos ventajas: por un lado, al
obviar las cuestiones de implementacin, la descripcin es independiente de la eleccin de
cualquier tipo de SGBD, que puede ser pospuesta hasta un momento ms avanzado del
proceso de desarrollo de la BD. Por otro lado, realizar una descripcin a alto nivel de los
datos simplifica inicialmente el problema de organizar la informacin: para nosotros ser
ms asequible describir un problema utilizando conceptos y trminos con los que nos
encontremos plenamente familiarizados - cindonos a la descripcin de la informacin en
s - en lugar de tener que emplear cualquier clase de jerigonza informtica, y estar
obligados a disear estructuras tales como unas tablas, de acuerdo con unas reglas y un
formato determinado. Quin piensa en tablas en la vida real? Estamos acostumbrados a
manejar conceptos como el de libro, biblioteca, socio, prstamo, alumno, asignatura,
matrcula, empleado, contrato...
Lamentablemente, una organizacin de los datos a tan alto nivel ser difcilmente
interpretable y manipulable por un programa informtico, o por un SGBD. Por lo tanto no
ser posible utilizarla directamente para nuestro propsito de construir una BD. Sin
embargo, es posible realizar la definicin del esquema conceptual de tal modo que sirva
como base o referencia para un diseo de ms 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 diseo lgico en la que se lleva a cabo esa tarea. El esquema lgico
constituye una descripcin a un nivel menor de abstraccin de las estructuras que
permitirn almacenar la informacin. Esta etapa implica ya la seleccin de un determinado
tipo de SGBD (normalmente un SGBD relacional) que prescriba las estructuras a definir
(normalmente tablas).
Adems, al tiempo que se disee el esquema lgico de la BD ser realizado el diseo de los
programas que accedern a la base de datos.
La ltima etapa es la de diseo fsico de la BD. En esta fase, habiendo ya seleccionado un
SGBD concreto, es necesario adaptar el diseo lgico de la BD a la organizacin interna
del sistema: deben definirse las estructuras de almacenamiento internas, el formato de los
archivos en los que el SGBD almacenar la informacin, y los mtodos de acceso a los
mismos, que permitirn la manipulacin de la informacin. El diseo fsico de la BD va
acompaado, habitualmente, de la construccin e implementacin de los programas
informticos que accedern a la misma.

Modelos de datos
Hemos visto que el diseo de una BD comprende varias fases, siendo el resultado de cada
una de ellas una descripcin (a diferente nivel de abstraccin) de la informacin a
representar en la BD.
La pregunta que surge es cmo deben ser esas descripciones? Para facilitar su realizacin,
contamos con diferentes modelos de datos de referencia. Esos modelos constituyen una
gua para la realizacin de las descripciones, proporcionndonos los conceptos, estructuras
y elementos a emplear, y la forma de utilizarlos y presentarlos.
El modelo entidad-relacin (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 vinculacin entre un socio y una
biblioteca, por ejemplo). Y esa debe ser la visin que debe reflejar toda descripcin
realizada en base al modelo. Su cercana al modo humano de percibir e interpretar la
realidad lo convierte en un modelo idneo para utilizar en la definicin del esquema
conceptual de una base de datos.
El modelo relacional es un modelo mucho ms cercano a una interpretacin de la realidad
asequible para un programa informtico. 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 ms utilizado para la definicin del esquema lgico de una BD.


Bibliografa

- R. Elmasri y S. Navathe. Fundamentos de los Sistemas de Bases de Datos (3 edicin).
Addison-Wesley, 2002.
- A. Silberschatz, H. F. Korth y S. Sudarshan. Fundamentos de Bases de Datos (4
edicin). McGraw Hill, 2002

2 1 - ProblemasDeMalosDisenos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

2 1 - ProblemasDeMalosDisenos

Cargado por

Copyright:

Formatos disponibles

Grao en Informacin e Documentacin: Bases de datos documentais Curso 2013 2014

Autor: Juan Ramn Lpez Rodrguez 1

También podría gustarte