Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

Tema 6: Diseo de bases de datos relacionales.

6.1 Introduccin. Las dificultades inherentes al diseo de una base de datos han de afrontarse con procedimientos ordenados y metdicos. En el proceso de diseo de una base de datos hemos de distinguir tres grandes fases: Diseo conceptual, cuyo objeti o es obtener una representacin de la informacin con independencia de usuarios y aplicaciones en particular, y fuera de consideraciones sobre la eficiencia del ordenador. Diseo lgico, cuyo objeti o es transformar el diseo conceptual obtenido y adaptarlo al modelo de datos en el que se apoya el !"#D que se a a utili$ar. En nuestro caso, el !"#D es relacional, por lo cual nos referiremos a este modelo de datos. Diseo f%sico, cuyo objeti o es conseguir una instrumentacin lo m&s eficiente posible del diseo lgico.

En este tema nos centraremos principalmente en el diseo conceptual y el diseo lgico, pues el diseo f%sico depende de cada !"#D y cada computadora en particular. 'ara desarrollar el diseo de una base de datos, tomaremos como ejemplo el diseo de una base de datos relacional que permita la gestin de prestamos de libros de una biblioteca. 6.2 Diseo conceptual. El diseo conceptual, bre emente e(presado, consiste en e(traer del trabajo de la empresa aquellas entidades y acciones que son de uso habitual en la misma y que an a formar parte de la base de datos. 'ara ello, la forma habitual de diseo es mediante la consulta con los empleados de la empresa, pues a partir de la misma se ha de obtener el conjunto de entidades que an a formar parte de la base de datos, as% como las acciones rele antes que pueden afectar al diseo de la base de datos. En nuestro ejemplo de estudio, partimos de que la forma actual de trabajo de la biblioteca, la cual consiste en una serie de fichas de tres tipos: )ichas con las caracter%sticas de los libros *nombre, cdigo, tipo, etc.+. )ichas con las caracter%sticas de los lectores *nombre, apellidos, domicilio, etc.+. )ichas con la informacin de los prestamos de libros que se han efectuado, incluyendo el lector a qui,n se le ha prestado, la fecha, etc.

-iencias y .,cnicas Estad%sticas

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

Adem&s de estas fichas, en nuestras con ersaciones con los empleados, obtenemos algunas informaciones y comentarios 0tiles para el diseo como los siguientes: De cada libro pueden e(istir arios ejemplares. !, esta interesado en tener informacin sobre el idioma del libro. 1nteresa reflejar los temas de los libros, pudiendo cada libro pertenecer a arios temas y2o subtemas. 1nteresa conocer el nombre de los autores.

A partir de esta informacin podemos obtener el siguiente diseo conceptual, donde se incluye la cardinalidad entre las entidades. En dicho diseo, los rect&ngulos representan entidades y los rombos representan relaciones entre entidades, constando al lado de las mismas la cardinalidad de la relacin.
Autor

Escribe

3:4

/:3 Ejemplar .iene Libro

3:4 .rata .ema

'resta

3:4

Escrito en

/:3

!ocio

1dioma

Figura 6.2.1: Esquema del diseo conceptual de una base de datos. La cardinalidad es obtenida en base a las posibilidades de relacin entre las entidades, e(istiendo tres tipos de cardinalidad: -ardinalidad /:/, que es cuando una entidad A se relaciona solo con otra entidad # y ice ersa. 'or ejemplo, el identificador de un coche *n0mero de bastidor+ se corresponde con una matr%cula y esa matr%cula con ese identificador del coche. -ardinalidad /:3, que es cuando una entidad A se puede relacionar con 3 entidades # pero no al re ,s. 'or ejemplo un libro puede tener 3 ejemplares, pero un ejemplar es solo de un libro. -ardinalidad 3:4, que es cuando una entidad A se relaciona con 3 entidades # y ice ersa. 'or ejemplo, un libro puede ser escrito por arios autores distintos y un autor puede escribir arios libros distintos.

-iencias y .,cnicas Estad%sticas

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

As%, un libro puede haber sido escrito por arios autores *relacin /:3+, pero adem&s, un autor puede haber escrito arios libros *relacin /:3 en sentido in erso+, por lo cual, la relacin resultante es 3:4. -on la obtencin del esquema de la figura, puede considerarse por reali$ado el diseo conceptual, pues tenemos identificados los elementos y las relaciones entre ellos as% como sus cardinalidades, pudiendo pasar al diseo lgico. 6.3 Diseo lgico. La con ersin del diseo conceptual al diseo lgico est& basada en los tres principios siguientes: .odo tipo de entidad del modelo conceptual se con ierte en una tabla. .odo tipo de relacin entre tablas /:3 se traduce en una propagacin de la cla e *se crea una cla e primaria o for&nea+ o bien se crea una nue a tabla intermedia. .odo tipo de relaciones entre tablas 3:4 *muchos a muchos+ origina la creacin de una nue a tabla intermedia.

En primer lugar, se obser a que de la aplicacin de las reglas anteriores, en el paso del diseo conceptual al diseo lgico se pierde informacin sem&ntica, pues tanto las entidades como las relaciones son con ertidas en tablas, sin que e(ista una diferencia entre las pro enientes de entidades o de relaciones. Apliquemos las tres reglas anteriores a nuestro diseo conceptual. Aplicando la primera regla, obtenemos que como e(isten seis entidades *autor, libro, ejemplar, tema, idioma y socio+, hemos de crear seis tablas, una por cada entidad, obteniendo las siguientes seis tablas con su correspondiente cla e primaria:
A6.78 -odigo9autor 3ombre L1#87 -odigo9libro .itulo Ao E:E4'LA8 -odigo9ejemplar

1D174A -odigo9idioma Descripcin

.E4A -odigo9tema Descripcin

!7-17 D31 3ombre Domicilio .elefono

Figura 6.3.1: Tablas de la base de datos obtenidas a partir de las entidades existentes. Apliquemos ahora la segunda regla. .enemos dos relaciones /:3, lo cual nos origina la propagacin de las cla es. La propagacin se efect0a desde la tabla de cardinalidad / a la tabla de cardinalidad 3. Adem&s, la propagacin es de cla e primaria

-iencias y .,cnicas Estad%sticas

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

si la cla e primaria de la tabla a la que se propaga la cla e no identifica un% ocamente la entidad, en caso contrario se propaga en forma de cla e for&nea. En nuestro caso, la propagacin de cla e es: La cla e codigo9libro de la tabla L1#87 se propaga a la tabla E:E4'LA8 como cla e primaria. La cla e codigo9idioma de la tabla 1D174A se propaga a la tabla L1#87 como cla e for&nea.
A6.78 -odigo9autor 3ombre L1#87 -odigo9libro .itulo Ao -odigo9idioma E:E4'LA8 -odigo9libro -odigo9ejemplar

1D174A -odigo9idioma Descripcin

.E4A -odigo9tema Descripcin

!7-17 D31 3ombre Domicilio .elefono

Figura 6.3.2: Modificaci n de las entidades al aplicar las relaciones 1:!. Apliquemos ahora la tercera regla. .enemos tres relaciones 3:4, cada una de las cuales dar& lugar a una nue a tabla que estar& compuesta por las cla es primarias de las tablas que relaciona as% como por todos aquellos datos que identifican la relacin entre las entidades. De esta forma obtendremos la siguiente relacin final de tablas:
E:E4'LA8 -odigo9libro -odigo9ejemplar '8E!.A -odigo9libro -odigo9ejemplar D31 )echa9prest )echa9de !7-17 D31 3ombre Domicilio .elefono E!-81#E -odigo9autor -odigo9libro L1#87 -odigo9libro .itulo Ao -odigo9idioma A6.78 -odigo9autor 3ombre .8A.A -odigo9libro -odigo9tema

1D174A -odigo9idioma Descripcin

.E4A -odigo9tema Descripcin

Figura 6.3.3: Modificaci n de las entidades al aplicar las relaciones !:M.

-iencias y .,cnicas Estad%sticas

<

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

6.4 Teora de la normalizacin. En el desarrollo del diseo lgico obtenemos una serie de tablas finales que son las candidatas a formar nuestra base de datos. !in embargo, dichas tablas han sido obtenidas a partir de un diseo conceptual elaborado sin ning0n tipo de reglas, por lo que podemos obtener un diseo de tablas m&s o menos heterog,neo. La teor%a de la normali$acin consiste en un conjunto de reglas formales que nos permiten asegurar que un diseo lgico cumple una serie de propiedades, corrigiendo la estructura de los datos de las tablas y e itando una serie de problemas como: 1ncapacidad de almacenar ciertos hechos. 8edundancias y, por tanto, posibilidad de inconsistencias. Ambig=edades. ',rdida de informacin. Aparicin en la base de datos de estados no &lidos en el mundo real, es lo que se llama anomal%as de insercin, borrado y modificacin.

Las reglas formales de la teor%a de la normali$acin son conocidas con el nombre de formas normales. E(isten seis formas normales, de forma que cuando la base de datos cumple las reglas de la primera forma normal se considera que est& en primera forma normal */)3+, cuando pasan la segunda, que est& en segunda forma normal *5)3+, etc. Adem&s, una base de datos de la que se afirme que est& en 5)3, est& tambi,n en /)3, pues las formas normales se aplican de forma sucesi a. De las seis formas normales, generalmente solo se aplican sobre las bases de datos las tres primeras, considerando que una base de datos que est& en ;)3 es una base de datos correctamente diseada. 'or ello, e(pondremos a continuacin est&s tres primeras formas normales. 'ara desarrollar la teor%a de normali$acin de una base de datos tomaremos como ejemplo el diseo de la gestin de una empresa considerando solo la parte de facturacin a los clientes. 6.4.1 Primera forma normal (1FN). 6na base de datos se considera que est& en /)3 si cada atributo *campo+ de una tabla contiene un solo alor atmico *simple+. 6n atributo que contiene arios alores puede deri ar en una perdida de datos. .omando el ejemplo propuesto, hemos reali$ado un an&lisis y hemos obtenido que para identificar la factura hemos creado como cla e primaria el cdigo de la factura y hemos establecido adem&s la necesidad de que una factura posea los siguientes campos:

-iencias y .,cnicas Estad%sticas

>

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

)A-.68A Codigo_factura -odigo9cliente 3ombre9cliente Direccion9cliente 'oblacion9cliente )echa9factura )orma9pago -odigo9articulo9/ Descripcion9/ -antidad9/ 1mporte9/ .ipo91?A9/ @ -odigo9articulo93 Descripcion93 -antidad93 1mporte93 .ipo91?A93

Figura 6.".1.1: #iseo inicial de las facturas. Anali$ando el diseo inicial de la tabla )A-.68A, obser amos la e(istencia de m0ltiples alores para los atributos *campos+ siguientes: -odigo9articulo, descripcion, cantidad, importe e 1?A. Anali$ando la tabla, obser amos que no cumple la condicin de /)3. La solucin consiste en crear una nue a tabla, que podemos llamar DE.ALLE9)A-.68A a la cual se trasladan los datos repetiti os, en nuestro caso los datos referentes a los art%culos *codigo9articulo, descripcin, cantidad, importe e 1?A+.
)A-.68A -odigo9factura -odigo9cliente 3ombre9cliente Direccion9cliente 'oblacion9cliente )echa9factura )orma9pago DE.ALLE9)A-.68A -odigo9factura -odigo9articulo Descripcion -antidad 1mporte .ipo91?A

Figura 6.".1.2: #iseo de las facturas aplicando la 1F!. -uando se produce la separacin de datos de la tabla original en una nue a tabla, ,sta adem&s de los atributos necesarios, traslada la cla e primaria de la tabla original como parte de su nue a cla e primaria, que estar& formada, generalmente, por dos atributos. 6.4.2 Segunda forma normal (2FN). La segunda forma normal, como la tercera que eremos a continuacin, se relaciona con el concepto de dependencia funcional. Entendemos como dependencia funcional a la relacin que tienen los atributos *campos+ de una tabla con otros atributos de la propia tabla. 6n campo tiene dependencia funcional si necesita informacin de otro2s campo2s para poder contener un alor. 6na tabla se dice que esta en segunda forma normal *5)3+ si sucede que: Est& en /)3

-iencias y .,cnicas Estad%sticas

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

-ada atributo *campo+ no cla e depende de la cla e completa, no de parte de ella. 'or supuesto, una base de datos estar& en 5)3 si todas sus tablas lo est&n.

La idea intuiti a de la 5)3 es identificar todas las tablas con una cla e compuesta, pues todas las tablas con cla e simple est&n por defecto en 5)3 si est&n en /)3, y comprobar que cada uno de los campos de esta tabla depende de la cla e completa. En nuestro ejemplo, la tabla )A-.68A se encuentra en 5)3 pues est& en /)3 y su cla e es simple. !in embargo la tabla DE.ALLE9)A-.68A ha de ser anali$ada pues su cla e es compuesta *esta formada por dos atributos+. Anali$ando la tabla DE.ALLE9)A-.68A, obser amos que el atributo descripcion depende 0nicamente del atributo codigo9articulo *la descripcin de un articulo depende 0nicamente de que articulo se trate y es completamente independiente de la factura+, por lo cual la descripcion ha de ser lle ada a una nue a tabla junto con el atributo cla e codigo9articulo. !upongamos adem&s, que el cliente nos indica que en la factura, aunque cada articulo posee calculado su 1?A, el tipo de 1?A que aplica es com0n a toda la factura y no depende en cada factura de los art%culos, por lo cual, emos que el atributo .ipo91?A solo depende funcionalmente del codigo9factura y no depende de codigo9articulo, por lo cual ha de ser de uelta a la tabla )A-.68A como un 0nico atributo .ipo91?A que depende solo de la cla e de )A-.68A *codigo9factura+.
)A-.68A -odigo9factura -odigo9cliente 3ombre9cliente Direccion9cliente 'oblacion9cliente )echa9factura )orma9pago .ipo91?A DE.ALLE9)A-.68A -odigo9factura -odigo9articulo -antidad 1mporte A8.1-6L7 -odigo9articulo Descripcion

Figura 6.".2.1: #iseo de las facturas aplicando la 2F!. 6.4.3 Tercera forma normal (3FN). 6na tabla se dice que est& en tercera forma normal *;)3+ si: Est& en 5)3. .odos los atributos que no son cla es deben ser mutuamente independientes, es decir, un atributo no debe depender de otro atributo no cla e de su tabla.

!i un atributo que no es cla e depende de otro atributo que no es cla e, la tabla posiblemente contiene datos acerca de mas de una entidad, contradiciendo el principio de que cada tabla almacene informacin de una entidad.

-iencias y .,cnicas Estad%sticas

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

En nuestro ejemplo, podemos obser ar que las tablas A8.1-6L7 y DE.ALLE9)A-.68A se encuentran en ;)3. !in embargo, la tabla )A-.68A no est& en ;)3, pues los atributos 3ombre9cliente, Direccion9cliente y 'oblacion9cliente dependen funcionalmente del atributo -odigo9cliente, campo que no es cla e. 'or ello, debemos e(traer estos atributos de la tabla )A-.68A e incluirlos en una nue a tabla que haga referencia al cliente, tabla que llamaremos -L1E3.E y que contendr& como cla e primaria el -odigo9cliente y como atributos el 3ombre9cliente, Direccion9cliente y 'oblacion9cliente. Aplicando esto, nuestro diseo de las facturas da lugar a las tablas que pueden erse en la siguiente figura.
)A-.68A -odigo9factura -odigo9cliente )echa9factura )orma9pago .ipo91?A -L1E3.E -odigo9cliente 3ombre9cliente Direccion9cliente 'oblacion9cliente

DE.ALLE9)A-.68A -odigo9factura -odigo9articulo -antidad 1mporte

A8.1-6L7 -odigo9articulo Descripcion

Figura 6.".3.1: #iseo de las facturas aplicando la 3F!. 6.4.4 Consideraciones finales y pro lemas de la normali!aci"n. La teor%a de la normali$acin nos ayuda a estructurar mejor las tablas de la base de datos, e itando posibles redundancias. 'or otra parte, si seguimos la metodolog%a de diseo e(puesta en los puntos A.5 y A.; del tema, obteniendo un diseo conceptual que despu,s es con ertido en diseo lgico, este diseo lgico resultante estar& en ;)3 siempre que todo el proceso se haya reali$ado de forma correcta, sir iendo en este caso la teor%a de la normali$acin para comprobar que el diseo ha sido reali$ado correctamente. !i no lo fuese, podremos aplicar las formas normales para corregir los errores que hubieran podido producirse. 4ientras la normali$acin resuel e los problemas relacionados con la estructuracin de los datos en tablas, crea problemas aadidos a su propio concepto, como son la duplicacin de datos y la ineficacia en la recuperacin de informacin. As%, el proceso de normali$acin en uel e la descomposicin de una tabla en tablas m&s pequeas, lo cual requiere que la cla e primaria de la tabla original se incluya, como una cla e for&nea, en la tabla2s que se forman. Esto significa que a medida que se an creando estas cla es for&neas se a incrementando las probabilidades de poner en peligro la integridad de la base de datos. 7tro efecto adicional del n0mero creciente de tablas en la base de datos, es que se e disminuido el rendimiento del sistema en la recuperacin de la informacin contenida. Esta disminucin del rendimiento puede ser particularmente importante en
-iencias y .,cnicas Estad%sticas C

Adquisicin y tratamiento de datos

Diseo de bases de datos relacionales

sistemas basados en microordenadores. 'or tanto, en ciertas ocasiones es necesario llegar a un compromiso entre el ni el de normali$acin de la base de datos y el rendimiento del sistema. 6.5 E ercicios de diseo de !ases de datos. 6.#.1 $%ercicio. 6na empresa pretende desarrollar una base de datos de empleados y proyectos. La empresa esta estructurada en departamentos, cada uno de los cuales posee uno o arios proyectos, de forma que un proyecto solo depende de un departamento. 'or otro lado cada departamento consta de uno o arios empleados, que trabajan de forma e(clusi a para ese departamento, pero pueden trabajar simult&neamente en arios proyectos. -ada empleado tiene un jefe encargado de super isar su trabajo, pudiendo cada jefe super isar el trabajo de arios empleados. Dada la descripcin anterior, desarrollar la base de datos normali$ada hasta ;)3. 6.#.2 $%ercicio. Dada el siguiente diseo de una tabla de una base de datos, aplicar las tres primeras formas normales y lle ar el diseo a ;)3.
E3?17 Codigo_envio 4atricula9camion 4odelo9camion -apacidad9camion -liente9/ Direccion9cliente9/ 'edido9cliente9/ Articulo9/9pedido9cliente9/ ?olumen9articulo9/9pedido9cliente9/ @ Articulo919pedido9cliente9/ ?olumen9articulo919pedido9cliente9/ @ -liente93 Direccion9cliente93 'edido9cliente93 Articulo9/9pedido9cliente93 ?olumen9articulo9/9pedido9cliente93 @ Articulo9:9pedido9cliente93 ?olumen9articulo9:9pedido9cliente93

-iencias y .,cnicas Estad%sticas