capitulo 6- diseño de bases de datos y modelo e-r

5/16/2018 Capitulo 6- Dise o de bases de datos y modelo E-R

1/

PAR TE 2

Disefio de bases de datos

Los sistemas de bases de datosestan disefiados para gestionar grandes cantidades de informacion. Estas .grandes cantidades de informacion no se encuentran aisladas. Forman parte del funcionamiento dealguna empresa cuyo producto final puede ser la informacion obtenida de la base de datos 0 algunproducto 0 servicio para el que la base de datos solo desempefia un papel secundario.Los dos primeros capitulos de esta parte se centran en el disefio de los esquemas de las bases de datos.El modelo entidad-relacion (E-R)descrito en el Capitulo 6 es un modelo de datos de alto nivel. En lugar

de representar todos los datos en tablas, distingue entre los objetos basicos, denominados entidades, y lasrelaciones entre esos objetos. Suele utilizarse como un primer paso en el disefio de los esquemas de lasbases de datos.El disefio de las bases de datos relacionales-el disefio del esquema relacional-se trato informalmen-

te en los capitulos anteriores. No obstante, existen criterios para distinguir los buenos diserios de basesde datos de los malos. Estos se formalizan mediante varias "formas normales" que ofrecen diferentescompromisos entre la posibilidad de inconsistencias y la eficiencia de determinadas consultas. El Capi-tulo 7 describe el disefio formal de los esquemas de las relaciones.El diseno de un entorno completo de aplicaciones para bases de datos, que responda a las necesidades

de la empresa que se modela, exige prestar atencion a un conjunto de aspectos mas amplio, muchos delos cuales se tratan en el Capitulo 8. Este capitulo describe las interfaces para bases de datos basadas enWeb y amplia el estudio de capitulos anteriores sobre la integridad de los datos y la seguridad.


2/

CAPfTUL06

Hasta este punto se ha dado por supuesto un determinado esquema de la base de datos y se ha estudiadola manera de expresar las consultas y las actualizaciones. Ahora se va a considerar en primer lugar lamanera de disefiar el esquema de la base de datos. En este capitulo nos centraremos en el modelo dedatos entidad-relacion (E-R), que ofrece una manera de identificar las entidades que se van a representaren la base de datos y el modo en que se relacionan entre si, Finalmente, el disefio de la base de datos seexpresara en terrninos del diseno de bases de datos relacionales y del conjunto de restricciones asociado.En este capitulo se mostrara la manera en que el diserio E-R puede transformarse en un conjunto deesquemas de relaci6n y el modo en que se pueden incluir algunas de las restricciones en ese disefio.Luego, en el Capitulo 7, se considerara en detalle si el conjunto de esquemas de relaci6n representa undisefio de la base de datos bueno 0malo y se estudiara el proceso de creaci6n de buenos disenos usandoun conjunto de restricciones mas amplio. Estos dos capitulos tratan los conceptos fundamentales deldisefio de bases de datos.

6.1 Vision general del proceso de dlsenoLa tarea de creaci6n de aplicaciones de bases de datos es una labor compleja, que implica varias fases,como el disefio del esquema de la base de datos, el diserio de los programas que tienen acceso a losdatos y los actualizan y el disefio del esquema de seguridad para controlar el acceso a los datos. Lasnecesidades de los usuarios desempefian un papel central en el proceso de disefio. En este capitulo noscentraremos en el disefio del esquema de la base de datos, aunque se esbozaran brevementealgunas delas otras tareas mas adelante en este capitulo.El disefio de un entorno completo de aplicaciones de bases de datos que responda a las necesidades

de la empresa que se esta modelando exige prestar atenci6n a un amplio conjunto de consideraciones.Estos aspectos adicionales del uso esperado de la base de datos influyen en gran variedad de opcionesde diseno en los niveles ffsico, l6gico y de vistas.6.1.1 Fases del disefioPara aplicaciones pequenas puede resultar factible para un disefiador de bases de datos que comprendalos requisitos de la aplicaci6n decidir directamente sobre las relaciones que hay que crear, sus atributosy las restricciones sobre las relaciones. Sin embargo, un proceso de disefio tan directo resulta dificilpara las aplicaciones reales, ya que a menu do son muy. complejas. Frecuentemente no existe una solapersona que comprenda todas las necesidades de datos de la aplicaci6n. El disefiador de la base dedatos debe interactuar can los usuarios para comprender las necesidades de la aplicacion, realizar unarepresentaci6n de alto nivel de esas necesidades que pueda ser comprendida por los usuarios y luegotraducir esos requisitos a niveles inferiores del diseno. Los modelos de datos de alto nivel sirven alos disefiadores de bases de datos ofreciendoles un marco conceptual en el que especificar de forma

157


3/

158 Capitulo 6 Disefiodebases de datos y el modelo E-R

sistematica los requisitos de datos de los usuarios de la base de datos y una estructura _para la basedatos que satisfaga esos requisitos.

La fase inicial del diserio de las bases de datos es la caracterizaci6n completa de las necesidadde datos de los posibles usuarios de la base de datos. El diseriador de la base de datos dinteractuar intensamente con los expertos y los usuarios del dominio para realizar esta tarearesultado de esta fase es una especificaci6n de requisitos del usuario. Aunque existen tecnipara representar en diagramas los requisitos de los usuarios, en este capitulo s610 se describirtextualmente esos requisites, que se ilustraran posteriormente en el Apartado 6.8:2.

A continuaci6n, el disefiador elige el modelo de datos y , aplicando los conceptos del modelodatos elegido, traduce estos requisites en un esquema conceptual de la base de datos. El esquemdesarrollado en esta fase de disefio conceptual proporciona una visi6n detallada de la empreSe suele emplear el modelo entidad-relaci6n, que se estudiara en el resto de este capitulo, parapresentar el diserio conceptual. En terminos del modelo entidad-relacion, el esquema conceptuespecifica las entidades que se representan en la base de datos, sus atributos, las relaciones enellas y las restricciones que las afectan. Generalmente, la fase de disefio conceptual da lugarcreaci6n de un diagrama entidad-relaci6n que ofrece una representaci6n grafica del esquema.El disefiador revisa el esquema para confirmar que realmente se satisfacen todos los requisity que no entran en conflicto entre sf. Tarnbien puede examinar el disefio para eliminar caracter

ticas redundantes. Su atenci6n en este momento se centra en describir los datos y sus relacionmas que en especificar los detalles del almacenamiento fisico.

Un esquema conceptual completamente desarrollado indica tambien los requisites funcionalde la empresa. En la especificacion de requisitos funcionales los usuarios describen los tide operaciones (0 transacciones) que se llevaran a cabo sobre los datos. Algunos ejernplosoperaciones son la modificaci6n 0 actualizaci6n de datos, la busqueda y recuperaci6n de daconcretos y el borrado de datos. En esta fase de disefio conceptual el disenador puede revisaresquema para asegurarse de que satisface los requisitos funcionales.

El proceso de paso desde el modelo abstracto de datos a la implementaci6n de la base de dase divide en de dos fases de disefio finales.o En la fase de disefio logico el diseriador traduce el esquema conceptual de alto nivel < 1 1delo de datos de la implementaci6n del sistema de bases de datos que se va a usar. El modde implementaci6n de los datos suele ser el modele relacional, y este paso suele consistirla traducci6n del esquema conceptual definido mediante el modelo entidad-relaci6n enesquema de relaci6n.

o Finalmente, el disefiador usa el esquema de base de datos resultante propio del sistemala siguiente fase de disefio fisico, en la que se especifican las caracteristicas fisicas debase de datos. Entre estas caracteristicas estan la forma de organizaci6n de los archivos yestructuras de almacenamiento interno; se estudian en el Capitulo 11.

El esquema fisico de la base de datos puede modificarse con relativa facilidad una vez creadaaplicaci6n. Sin embargo, las modificaciones del esquema l6gico suelen resultar mas diftciles de Iiea cabo, ya que pueden afectar a varias consultas y actualizaciones dispersas pOl' todo el c6digo daplicaci6n. Por tanto, es importante llevar a cabo con cuidado la fase de diserio de la base de datos ande crear el resto de la aplicaci6n de bases de datos.6.1.2 Alternativas de dlsefioUna parte importante del proceso de disefio de las bases de datos consiste en decidir la manerarepresentar en el disefio los diferentes tipos de "cosas", como personas, lugares, productos y similarSe usa el terrnino entidad para hacer referencia a cualquiera de esos elementos claramente identificableLas diferentes entidades tienen algunos aspectos en comun y algunas diferencias. Se desea aprovechlos aspectos en cormm para tener un disefio concise, facilmente comprensible, pero hay que conservarsuficiente flexibilidad como para representar las diferencias entre las diferentes entidades existentes


4/

6.2 El modelo entidad-relacion 159

el momento del disefi.o 0 que se puedan materializar en el futuro. Las diferentes entidades se relacionanentre sf de diversas maneras, todas las cuales deben incluirse en el disefi.o de la base de datos.Al disefi.ar el esquema de una base de datos hay que asegurarse de que se evitan dos peligros impor-

tantes:1. Redundancia. Un mal disefi.o puede repetir informacion. En el ejemplo bancario que se ha veni-do usando, se tiene una relaci6n con la informaci6n sobre los clientes y una relaci6n separada conla informaci6n sobre las cuentas. Sup6ngase que, en lugar de eso, se repitiera toda la informaci6nsobre los clientes (nombre, direcci6n, etc.) una vez por cada cuenta 0 prestamo que tuviera cadacliente. Evidentemente, sena redundante. Lo ideal seria que la informaci6n apareciera exacta-mente en un solo lugar.

2. Incompletitud. Un mal disefi.o puede hacer que determinados aspectos de la empresa resultendiftciles 0 imposibles de modelar. Por ejernplo, sup6ngase que se usa un disefi.o de base de datospara el escenario bancario que almacena la informacion del nombre y de la direccion del clientecon cada cuenta y con cada prestamo, pero que no tiene una relacion separada para los clientes.Resultaria imposible introducir el nombre y la direcci6n de los clientes nuevos a menos queya tuvieran abierta una cuenta 0 concedido un prestamo. Se podria intentar salir del paso coneste disefi.o problematico almacenando valores nulos para la informacion de las cuentas 0de losprest amos, como puede ser el numero de cuenta 0 el importe del prestamo. Este parche no s610resulta poco atractivo, sino que puede evitarse mediante restricciones de clave primaria.

Evitar los malos disefios no es suficiente. Puede haber gran numero de buenos disefios entre los quehaya que escoger. Como ejemplo sencillo, considerese un cliente que compra un producto. LLa ventade este producto es una relaci6n entre el cliente y el producto? Dicho de otra manera, Les la propiaventa una entidad que esta relacionada con el cliente y con el producto? Esta eleccion, aunque simple,puede suponer una importante diferencia en cuanto a los aspectos de la empresa que se pueden modelarbien. Considerando la necesidad de tomar decisiones como esta para el gran numero de entidades yde relaciones que hay en las empresas reales, no es dificil vel' que el disefio de bases de datos puedeconstituir un problema arduo. En realidad, se vera que exige una combinaci6n de conocimientos y de"buen gusto".

6.2 EI modelo entidad-relaci6nEl modelo de datos entidad-relaci6n (E-R) se desarrollo para facilitar el diserio de bases de datos per-mitiendo la especificaci6n de un esq uem a d e la em pre sa que representa la estructura logica global de labase de datos. El modelo de datos E-R es uno de los diferentes modelos de datos semanticos: el aspectosemantico del modelo radica en la representacion del significado de los datos. El modele E-R resultamuy util para relacionar los significados e interacciones de las empresas reales con el esquema concep-tual. Debido a est a utili dad, muchas herramientas de disefio de bases de datos se basan en los conceptosdel modelo E-R. El modele de datos E-R emplea tres conceptos basicos: los conjuntos de entidades, losconjuntos de relaciones y los atributos.

6.2.1 Conjuntos de entidadesUna entidad es una "cosa" u "objeto" del mundo real que es distinguible de todos los demas objetos. Porejemplo, cada persona de una empresa es una entidad. Una entidad tiene un conjunto de propiedades,y los valores de algun conjunto de propiedades pueden identificar cada entidad de forma uruvoca. Porejemplo, el DNI 67.789.901 identifica univocamente una persona concreta de la empresa. Analogamente,los prestamos se pueden considerar entidades, y el numero de prestamo P-15 de la sucursal de Navace-rrada identifica univocamente una entidad de prestamo, Las entidades pueden ser concretas, como laspersonas 0 los libros, 0abstractas, como los prestamos, las vacaciones 0 los conceptos.Un conjunto de entidades es un conjunto de entidades del mismo tipo que comparten las mismas

propiedades, 0 atributos. El conjunto de todas las personas que son clientes en un banco dado, por


5/

162 Capitulo 6 Disefio de bases de datos y el modelo E- R

i m po su o ri je cn a a cc es o)

clientei nombre.idiente) cueniat numero _cuenta)

17 junio 200528mayo 200528mayo 2005 -...J-----::::::""'iL _ _24 junio 200523 mayo 2005

24 mayo 20053 junio 200521 junio 2005

'--1--- 10 junio 2005

Figura 6.3 Fecha_acceso como atributo del conjunto de entidades impositor.

en que cada entidad participa en cada ejemp1ar de 1a re1aci6n. Por ejernplo, considerese un conjuntde entidades empleado que a1macena informaci6n sobre todos los emp1eados del banco. Se puede tenerun conjunto de re1aciones trabaja_para que se mode1a mediante pares ordenados de entidades emp leado .E1primer emp1eado de cada par adopta e1ro1 de t rabaiador, mientras e1segundo desempefia el ro1 dejefe. De esta manera, todas las re1aciones trabaja_para se caracterizan mediante pares (trabajador, jefe); lospares (jefe, trabajador) quedan excluidos.Una re1aci6npuede tambien tener atributos denominados atributos descriptivos. Considerese el con-junto de relaciones imposi ior con los conjuntos de entidades cliente y cuenta. Sepuede asociar el atributo

fecha_acceso con esta relaci6n para especificar la fecha mas reciente de acceso del cliente a 1acuenta. Larelaci6n imposi tor entre las entidades correspondientes al cliente Santos y la cuenta C-217 tiene el valor"23 mayo 2005" para el atributo fecha_acceso, 10que significa que el Ultimo dia en que Santos accedi6 a 1acuenta C-217 fue e123 de mayo de 2005.La Figura 6.3 muestra e1conjunto de re1aciones impositor con e1atributo descriptivo fecha_acceso; enaras de la sencillez, s610se muestran algunos atributos de los dos conjuntos de entidades.Como ejemplo adicional de los atributos descriptivos de las relaciones, sup6ngase que se tienen 10conjuntos de entidades es iudianie y as ignaiura que participan en el conjunto de relaciones matr iculado .Puede que se desee almacenar el atributo descriptivo creditos con la relacion, para registrar si el estu-diante se ha matriculado en la asignatura para obtener creditos 0 s610como oyente.Cada ejemplar de una relaci6n de un conjunto de relaciones determinado debe identificarse univo-camente a partir de sus entidades participantes, sin usar los atributos descriptivos. Para comprenderesto, sup6ngase que deseemos representar todas las fechas en las que un cliente ha tenido acceso a unacuenta. El atributo monovalorado fecha_acceso s610puede almacenar una fecha de acceso. No se puedenrepresentar varias fechas de acceso mediante varios ejemplares de 1arelaci6n entre el mismo cliente yla misma cuenta, ya que los ejemplares de la relaci6n no quedarfan identificados univocamente usandosolarnente las entidades participantes. La forma correcta de tratar este caso es crear e1atributo multiva-lorado fechas_acceso, que puede almacenar todas las fechas de acceso.Sin embargo, puede haber mas de un conjunto de relaciones que implique a los mismos conjuntosde entidades. En nuestro ejemplo, los conjuntos de entidades clienie y presiamo participan en el conjuntode relaciones presia iario . Ademas, sup6ngase que cada prestamo deba tener otro cliente que sirva comoavalista del prestamo. Entonces los conjuntos de entidades clienie y pres iamo pueden participar en otroconjunto de relaciones: aoalisia.


6/

6.2 E1modeloentidad-relacion 163

Los conjuntos de relaciones prestatario y sucursaipr t s tamo proporcionan un ejemplo de conjunto derelaciones binario-es decir, uno que implica dos conjuntos de entidades. La mayor parte de los con-juntos de relaciones de los sistemas de bases de datos son binarios. A veces, no obstante, los conjuntosde relaciones implican a mas de dos conjuntos de entidades.Por ejemplo, considerense los conjuntos de entidades em p le ad o , s u cu r sa l y trabaio. Ejemplos de entida-des trabajo pueden ser director, cajero, interventor, etc. Las entidades trabajo pueden tener los atributos

puesio y nioel. El conjunto de relaciones trabaja_en entre em p le ad o , s uc u rs al y irabaio es un ejemplo de re-laci6n ternaria, Una relaci6n ternaria entre Santos, Navacerrada y director indica que Santos trabaja dedirector de la sucursal de Navacerrada. Santos tambien podria actuar como interventor de la sucursalde Centro, 1 0 que estaria representado por otra relaci6n. Podria haber otra relacion entre G6mez, Centroy cajero, que indicaria que Gomez trabaja de cajero en la sucursal de Centro.El numero de conjuntos de entidades que participan en un conjunto de relaciones es tambien elgrado

de ese conjunto de relaciones. Los conjuntos de relaciones binarios tienen grado 2; los conjuntos derelaciones ternarios tienen grado 3.

6.2.3 AtributosPara cada atributo hay un conjunto de valores permitidos, denominados dominic 0conjunto de val oresde ese atributo. Eldominio del atributo nombreclienie puede ser elconjunto de todas las cadenas de textode una cierta longitud. Analogamente, el dominio del atributo numero prestamo puede ser el conjunto detodas las cadenas de caracteres de la forma "P-n",donde n es un entero positive.Formalmente, cada atributo de un conjunto de entidades es una funci6n que asigna el conjunto de

entidades a un dominio. Dado que elconjunto de entidades puede tener varios atributos, cada entidad sepuede describir mediante un conjunto de pares (atributo.valor), un par por cada atributo del conjunto deentidades. Por ejemplo, una entidad cliente concreta se puede describir mediante el conjunto (id_cliente,67.789.901), (nombre_cliente , Lopez), (calle_cliente, Mayor), (ciudad_cliente , Peguerinos), 1 0 que significaque esa entidad describe a una persona llamada Lopez que tiene elDNInumero 67.789.901 y que resideen la calle Mayor de Peguerinos. Ahora se puede ver que existe una integraci6n del esquema abstractocon la empresa real que se esta modelando. Los valores de los atributos que describen cada entidadconstituyen una parte significativa de los datos almacenados en la base de datos.Cada atributo, tal y como se usa en el modelo E-R, se puede caracterizar por los siguientes tipos deatributo . Atributos simples y compuestos. En los ejemplos considerados hasta ahora los atributos han si-do simples; es decir, no estaban divididos en subpartes. Los atributos compuestos, en cambio, sepueden dividir en subpartes (es decir, en otros atributos). Por ejemplo, el atributo nombre puedeestar estructurado como un atributo compuesto consistente en n omb re , p rim e r apellido y segundo_apellido. Usar atributos compuestos en un esquema de disefio es una buena elecd6n si el usua-rio desea referirse a un atributo completo en algunas ocasiones y, en otras, solamente a algUncomponente del atributo. Sup6ngase que hubiera que sustituir para el conjunto de entidadescliente los atributos calle_cliente y c iudad cliente por el atributo compuesto direcci6n, con los atribu-tos calle, c iudad , provincia, y c6digo_postaI2. Los atributos compuestos ayudan a agrupar atributosrelacionados, 1 0 que hace que los modelos sean mas claros.Observese tambien que los atributos compuestos pueden aparecer como una jerarquia. Enel atributo compuesto direcci6n, el componente calle puede dividirse a su vez en numerocalle,

nombrecalie y piso. LaFigura 6.4muestra estos ejemplos de atributos compuestos para el conjuntode entidades c ii en te .

Atributos monovalorados y multivalorados. Todos los atributos que se han especificado en losejemplos anteriores tienen un unico valor para cada entidad conereta. Por ejemplo, el atributonumeroprestamo para una entidad prestamo especifica hace referenda a un unico numero deprestamo. Se dice que estos atributos son monovalorados. Puede haber ocasiones en las que

2. Se asume el formato de callediente y dircccion. usado en Espana, que incluye un c6digo postal numerico llamado "codigopostal".


7/

164 Capitulo 6 Disefio de bases de datos y el modelo E-R

Atributoscompuestos

nomine azreCClOn

nombre prim er _apellido segundo upellido calle ciudad provincia

~

c6d igo _pos ta lAtributoscomponentes

numero calle nombre calle visoFigura 6.4 Atributos compuestos nombre y direccion.

un atributo tenga un conjunto de valores para una entidad concreta. Considerese un conjde entidades empleado con el atributo n ume ro t el ej on o . Cada empleado puede tener cere, uvarios numeros de telefono, y empleados diferentes pueden tener diferente cantidad de telefoSe dice que este tipo de atributo es multivalorado. Como ejemplo adicional, el atributo no_subordinado del conjunto de entidades empleado es multivalorado, ya que cada empleado potener cero, uno 0mas subordinados.Si resulta necesario. se pueden establecer apropiadamente limites inferior y superior al m

ro de valores en el atributo multivalorado. Por ejemplo, el banco puede limitar ados el numde ruimeros de telefono que se guardan por cliente. EI establecimiento de Iimites en esteexpresa que el atributo numero_telefono del conjunto de entidades cliente puede tener entre cdos valores .

Atributos derivados. EI valor de este tipo de atributo se puede obtener a partir del valor deatributos 0entidades relacionados. Por ejemplo, sup6ngase que el conjunto de entidades cque tiene un atributo prestamos que representa el numero de prestamos que cada clienteconcedidos en el banco. Ese atributo se puede obtener contando el numero de entidades preeasociadas con cada cliente.Como ejemplo adicional, sup6ngase que el conjunto de entidades cliente tiene el atributo

que indica la edad del cliente. Si el conjunto de entidades cliente tiene tambien un atributo fe ch_nacimiento, se puede calcular edad a partir de fecha denadmiento y de la fecha actual. Por tedad es un atributo derivado. En este caso, fecha_de_nacimiento puede considerarse un atribasico, 0almacenado. EI valor de los atributos derivados no se almacena, sino que se calculavez que hace falta,

Los atributos toman valores nulos cuando las entidades no tienen ningun valor para ese atributovalor nulo tambien puede indicar "no aplicable" -es decir, que el valor no existe para esa entidad.ejemplo, una persona puede no tener un segundo nombre de pila. Nulo puede tambien designar qvalor del atributo es desconocido. Un valor desconocido puede ser falta (el valor existe pero no seesa informaci6n) 0 desconocido (no se sabe si ese valor existe realmente 0no).Por ejemplo, si el valor nombre de un cliente dado es nulo, se da por supuesto que el valor es faltque todos los clientes deben tener nombre. Un valor nulo para el atributo piso puede significar qdirecci6n no incluye un piso (no aplicable), que existe el valor piso pero no se conoce cual es (falque no se sabe si el valor piso forma parte 0no de la direcci6n del c1iente (desconocido).

6.3 RestriccionesUn esquema de desarrollo E-R puede definir ciertas restricciones a las que el contenido de la base dtos se debe adaptar. En este apartado se examinan la correspondencia de cardinalidades, las restricciode claves y las restricciones de participaci6n.


8/4

(a )

6. 3 Restricciones 165

(b)Figura 6.5 Correspondencia de cardinalidades. (a) Uno a uno. (b) Uno a varios.

6.3.1 Correspondencia de cardinalidadesLa correspondencia de cardinalidades, 0 razon de cardinalidad, expresa el nurnero de entidades a lasque otra entidad se puede asociar mediante un conjunto de relaciones.La correspondencia de cardinalidades resulta muy util para describir conjuntos de relaciones bina-

rias, aunque pueda contribuir a la descripci6n de conjuntos de relaciones que impliquen mas de dosconjuntos de entidades. En este apartado se centrara la atenci6n unicamente en los conjuntos de relacio-nes binarias.Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia

de cardinalidades debe ser una de las siguientes: Uno a uno Cada entidad de A se asocia, a 1 0 s umo , con una entidad de B, y cada entidad en Bseasocial a 1 0 s umo , con una entidad de A (vease la Figura 6.5a).

Uno a varios Cada entidad de A se asocia con cualquier numero (cero 0mas) de entidades deB. Cada entidad de B, sin embargo, se puede asociar, a 1 0 s umo , con una entidad de A (vease laFigura 6.5b).

Varios a uno Cada entidad de A se asocia, a 1 0 s umo , con una entidad de B.Cada entidad de B,s inembargo, se puede asociar con cualquier numero (cera 0mas) de entidades de A (vease la Figura6.6a).

Varios a varios Cada entidad de A se asocia con cualquier numero (cero 0mas) de entidades deB, y cada entidad de Bse asocia con cualquier numero (cero 0mas) de entidades de A (vease laFigura 6.6b).

La correspondencia de cardinalidades adecuada para un conjunto de relaciones dado depende, obvia-mente, de la situaci6n del mundo real que el conjunto de relaciones modele.Como ilustracion, considerese el conjunto de relaciones prestatario . Si, en un banco dado, cada presta-

mo s610puede pertenecer a un cliente y cada cliente puede tener varios prestamos, entonces el conjuntode relaciones de cl iente a pres tamo es uno a varios. Si cada prestamo puede pertenecer a varios clientes(como los prestamos solicitados conjuntamente por varios socios de un negocio) el conjunto de relacio-nes es varios a varios. La Figura 6.2 muestra este tipo de relaci6n.

6.3.2 ClavesEs necesario tener una forma de especificar la manera de distinguir las entidades pertenecientes a unconjunto de entidades dado. Conceptualmente cada entidad es distinta; desde el punto de vista de lasbases de datos, sin embargo, la diferencia entre elias se debe expresar en terminos de sus atributos.Por 1 0 tanto, los valores de los atributos de cada entidad deben ser tales que permitan identificar

un ivocamen te a esa entidad. En otras palabras, no se permite que ningun par de entidades de un conjuntode entidades tenga exactamente el mismo valor en todos sus atributos.


9/4

Capitulo 6 Diseno de bases de datos y el modelo E-R

(a) (b)Figura 6.6 Correspondencia de cardinalidades. (a) Varios a uno. (b) Varios a varios.

Las claves permiten identificar un conjunto de atributos que resulta suficiente para distinguir las e -tidades entre si. Las claves tambien ayudan a identificar univocamente las relaciones y, por tanto, a .distinguir las relaciones entre sf.

6.3.2.1 Conjuntos .de entidadesUna superc1ave es un conjunto de uno 0 mas atributos que, tornados conjuntamente, perrniten ider -tificar de forma univoca una entidad del conjunto de entidades. Por ejemplo, el atributo id_cliente de,conjunto de entidades cliente es suficiente para distinguir una entidad clienie de las dema. Por tanto, i:_cliente es una superc1ave. Analogamente. la combinaci6n de nombre_cl iente e id_cliente es una superclavsdel conjunto de entidades clienie. EI atributo nombre_cl iente de cliente no es una superclave, ya que variaspersonas pueden tener el mismo nombre.El concepto de superclave no es suficiente para 10que aqui se prop one ya que, como se ha vistc

las superclaves pueden contener atributos innecesarios. Si C es una superclave, entonces tambien 10~cualquier superconjunto de C. A menudo interesan las superclaves para las que ningun subconjuntpropio es superclave. Esas superclaves minimas se denominan claves candidatas,Es posible que conjuntos distintos de atributos puedan servir como clave candidata. Sup6ngase q1..;

una combinaci6n de nombre_cl iente y calle_cliente sea suficiente para distinguir entre los miembros de:conjunto de entidades cliente. Entonces, tanto id_cliente como nombre cliente, calle_cliente son claves car-didatas. Aunque los atributos id_cliente y nombre_cl iente juntos puedan diferenciar las entidades client:su combinaci6n no forma una clave candidata, ya que el atributo id_cliente por sf solo es una clave car-didata.Se usa el termino clave primaria para denotar la clave candidata elegida por el disefiador de la bas-

de datos como elemento principal de identificaci6n de las entidades pertenecientes a un conjunto .Eentidades. Las claves (primarias, candidatas y superclaves) son propiedades del conjunto de entidadesmas que de cada una de las entidades. Dos entidades cualesquiera del conjunto no pueden tener e.mismo valor de los atributos de su clave al mismo tiempo. La designaci6n de una clave representa unarestricci6n de la empresa real que se esta modelando.Las claves candidatas se deben escoger con cuidado. Como se ha indicado, el nombre de cada personses obviamente insuficiente, ya que puede haber muchas personas con el rnismo nombre. En Espana, -

atributo DNI de cada persona puede ser una clave candidata. Como los no ciudadanos de en Espana r.ctienen DNI, las empresas con trabajadores extranjeros deben generar sus propios identificadores UniC05Una altemativa es usar como clave alguna combinaci6n unica de otros atributos.La clave primaria se debe escoger de manera que sus atributos nunca, 0 muy raramente, carnbien,

Por ejemplo, el campo direcci6n de cada persona no debe formar parte de la clave primaria, ya que esprobable que cambie. El ntimero de DNI, por otra parte, es seguro que no cambiara. Los identificadoresunicos generados por las empresas generalmente no cambian, excepto si se fusionan dos empresas; er ;tal caso, las dos empresas pueden haber ernitido el mismo identificador y sera necesario reasignar 105identificadores para asegurarse de que sean unicos.


10

6.3 Restricciones 167

6.3.2.2Conjuntos de relacionesLa clave primaria de cada conjunto de entidades permite distinguir entre las diferentes entidades delconjunto. Se necesita un mecanisme parecido para distinguir entre las diferentes relaciones de cadaconjunto de relaciones.Sea R un conjunto de relaciones que involucra los conjuntos de entidades E l, E2,"" En . Sea clave_ prim a ria (E i) el conjunto de atributos que forman la clave primaria del conjunto de entidades E i. Porahora se dara por supuesto que los nombres de los atributos de todas las claves primarias son unicosy que cad a conjunto de entidades participa 5610 una vez en la relaci6n. La composici6n de la claveprimaria de un conjunto de relaciones depende del conjunto de atributos asociado con el conjunto derelaciones R.Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto de atributos

clave_primaria(Ed U clave_primaria(E 2) U ... U clave_primaria(En)describe una relaci6n concreta del conjunto R.Si el conjunto de relaciones R tiene asociados los atributos (J,l, (J,2, ... , am, entonces el conjunto de

atributosclave_primaria(E J ) U clave_primaria(E 2) U ... U clave_primaria(E n) U{al' a'2, ... , a m}

describe una relaci6n concreta del conjunto R.En ambos cas os, el conjunto de atributos

clave_primaria(E 1) U c/ave_primaria(E 2) U ... U clave_primaria(En)forma una superclave del conjunto de relaciones.En el caso de que los nombres de los atributos de las claves primarias no sean unicos en todos los

conjuntos de entidades, hay que renombrar los atributos para distinguirlos; el nombre del conjunto deentidades combinado con el del atributo forrnara un nombre unico. En el caso de que un conjunto deentidades participe mas de una vez en el conjunto de relaciones (como en la relaci6n trabaja_para delApartado 6.2.2), se usa el nombre del rol en lugar del nombre del conjunto de entidades para formar unnombre de atributo unico.La estructura de la clave primaria para el conjunto de relaciones depende de la correspondencia de

cardinalidades del conjunto de relaciones. Como ejemplo, considerense los conjuntos de entidades cl ien-te y cuenta y el conjunto de relaciones imposi tor , con el atributo fecha_acceso del Apartado 6.2.2. Sup6ngaseque el conjunto de relaciones es varios a varios. Entonces, la clave primaria de imposiior consiste en launi6n de las claves primarias de cliente y de cuenta. Sin embargo, si un cliente s610 puede tener unacuenta-es decir, si la relaci6n imposi ior es varios a uno de cliente a cuenta-entonces la clave prima riade impositor es simplemente la clave prima ria de clienie. Analogamente, si la relaci6n es varios a uno decuenia a cliente-es decir, cada cuenta pertenece, a 10 sumo, a un cliente- entonces la clave prima ria deimposi tor es simplemente la clave primaria de cuenta. Para relaciones uno a uno se puede usar cualquierade las claves primarias.Para las relaciones no binarias, si no hay restricciones de cardinalidad, la superclave formada como se

ha descrito anteriormente en este apartado es la unica clave candidata, y se elige como clave primaria. Laelecci6n de la clave primaria resulta mas complicada si hay restricciones de cardinalidad. Dado que nose ha estudiado la manera de especificar las restricciones de cardinalidad en relaciones no binarias, nose estudiara mas este aspecto en este capitulo. Se considerara este aspecto con mas detalle en el Aparta-do 7.4.6.3.3 Restricciones de partlclpaclonSe dice que la participaci6n de un conjunto de entidades E en un conjunto de relaciones R es total sicada entidad de E participa, al menos, en una relaci6n de R. Si s610 algunas entidades de E participan enrelaciones de R, se dice que la participaci6n del conjunto de entidades E en la relaci6n R es parcial. Parejemplo, se puede esperar que cada entidad prestamo este relacionada, al menos, con un cliente mediante


11


la relaci6n prestatario. Por tanto, la participaci6n de prestamo en el conjunto de relaciones prestatario estotal. En carnbio, un individuo puede ser cliente del banco tenga 0 no tenga concedido algun prestamoen el banco. Por tanto, es posible que s610 algunas de las entidades cliente esten relacionadas con e : .conjunto de entidades prestamo mediante la relaci6n presiaiario, y la participaci6n de clienie en la relaci6prestatario es, por tanto, parcial.

6.4 Diagramas entidad-relaci6nComo se vio brevemente en el Apartado 1.3.3, los diagramas E-R pueden expresar graiicamente la es-tructura l6gica general de las bases de datos. Los diagramas E-R son sencillos y claros-cualidades qUEpueden ser responsables en gran parte de la popularidad del modelo E-R.Estos diagramas constan delos siguientes componentes principales:

Rectangulos, que representan conjuntos de entidades. Elipses, que representan atributos.e Rombos, que representan conjuntos de relaciones. Lineas, que unen los atributos con los conjuntos de. entidades y los conjuntos de entidades canlos conjuntos de relaciones.

Elipses dobles, que representan atributos multivalorados. Elipses discontinuas, que denotan atributos derivados. Lineas dobles, que indican participaci6n total de una entidad en un conjunto de relaciones. Rectangulos dobles, que representan conjuntos de entidades debiles (se describiran posterior-mente en el Apartado 6.6).

Considerese el diagrama entidad-relaci6n de la Figura 6.7, que consiste en dos conjuntos de entida-des, cliente y presiamo, relacionados mediante el conjunto de relaciones binarias prestatario. Los atributosasociados con c l i e n i e son i d c li e n te , n om b re c l i e n ie , c a ll e c l i e n te , y c iu da d c li e n t e . Los atributos asociadoscan presiamo son numero prestamo e impor te . En Ia Figura 6.7 los atributos del conjunto de entidades queson rniembros de la clave primaria estan subrayados.El conjunto de relaciones presiaiario puede ser varios a varies, uno a varios, varios a uno a uno a uno.

Para distinguir entre estos tipos, se dibuja 0 una linea dirigida (- 0una linea no dirigida (-) entre eiconjunto de relaciones y el conjunto de entidades en cuesti6n.

Una linea dirigida des de el conjunto de relaciones prestaiario al conjunto de entidades prestamcespecifica que prestatario es un conjunto de relaciones uno a uno 0 varios a uno desde clienie apr es iamo ; p r es ta ia ri o no puede ser un conjunto de relaciones varios a varios niuno a varios desdecliente a prestamo.

prestatario

Figura 6.7 Diagrama E-R correspondiente a clientes y prestamos.


12

6.4 Diagramasentidad-relacion '69

prestatario

(a)

(b)

( c)Figura 6.8 Relaciones. (a) Uno a varios. (b)Varios a uno. (c)Uno a uno .

Una linea no dirigida desde elconjunto de relaciones prestatario al conjunto de relaciones prestamoespecifica que prestatario es un conjunto de relaciones varios a varios 0 uno a varios desde clientea pres iamo.

Volviendo al diagrama E-R de la Figura 6.7, puede verse que el conjunto de relaciones prestatarioes varios a varios. Si el conjunto de relaciones prestatario fuera uno a varios, desde cliente a presiamo,entonces la linea desde prestatario a cliente seria dirigida, con una flecha que apuntarfa al conjunto de

Figura 6.9 Diagrama E-R con un atributo unido a un conjunto de relaciones.


13


Figura 6.10 Diagrama E-R con atributos compuestos, multivalorados y derivados.

entidades clienie (Figura 6.8a). Analogamente, si el conjunto de relaciones prestatario fuera varios a uncdesde cliente a presiamo, entonces la linea desde presiaiario a presiamo tendria una flecha que apuntariaal conjunto de entidades prestamo (Figura 6.8b). Finalmente, si el conjunto de relaciones preetaiario fuerauno a uno, entonces las dos lineas que salen de presiaiario tendrian flecha: una que apuntaria al conjuntcde entidades presiamo y otra que apuntaria al conjunto de entidades cliente (Figura 6.8c).Si un conjunto de relaciones tarnbien tiene asociados algunos atributos, entonces esos atributos -

unen con el conjunto de relaciones. Por ejemplo, en la Figura 6.9, se tiene el atributo descriptivo fecl~_acceso unido al conjunto de relaciones imposi ior para especificar la fecha del Ultimo acceso del cliente aesa cuenta.La Figura 6.10 muestra como se pueden representar los atributos compuestos en la notaci6n E-R.

En este caso, el atributo compuesto nombre , con los atributos componentes nombrepila, primerppetlid:y segundo_apellido sustituye al atributo simple nombreclienie de cliente. Ademas, el atributo compuestdirecci6n, cuyos atributos componentes son c a ll e , c i ud a d , provincia y c6digo_JJostal, sustituye a los atribut :calle_cliente y c iu da d c lie nie de cliente. El atributo calle es por S 1 mismo un atributo compuesto cuyo~atributos componentes son n um er o c alle , nombre_cal le y n u m ero p is o.La Figura 6.10 tambien muestra un atributo multivalorado, numero_ te le fono, indicado por una elipdoble, y un atributo derivado, edad, indica do por una elipse discontinua.En los diagramas E-R los roles se indican mediante etiquetas en las lineas que unen los rombos cor,

los rectangulos. La Figura 6.11muestra los indicadores de roles director y irabaiador entre el conjunto deentidades empleado y el conjunto de relaciones trabaja para.Los conjuntos de relaciones no binarias se pueden especificar facilmente en los diagramas E-R.La.

Figura 6.12 consta de tres conjuntos de entidades empleado, trabajo y sucursal, relacionados mediante e;conjunto de re1aciones ira ba ja en .

trabajador

Figura 6.11 Diagrama E-R con indicadores de roles.


14

6. 4 Diagramas entidad-relaci6n 171

nombre_empleado

Figura 6.12 Diagrama E-R con una relaci6n ternaria.En el caso de conjuntos de relaciones no binarias se pueden especificar algunos tipos de relaciones

varios a uno. Sup6ngase que un empleado puede tener, a 10sumo, un trabajo en cada sucursal (porejemplo, Santos no puede ser director e interventor en la misma sucursal). Esta restricci6n se puedeespecificar mediante una flecha que apunte a t rabajo en el arco de t rabaja_en .Como maximo se permite una flecha desde cada conjunto de relaciones, ya que los diagramas E-Rcon dos 0mas flechas salientes de cada conjunto de relaciones no binarias se pueden interpretar de dosformas. Sup6nganse que hay un conjunto de relaciones Rentre los conjuntos de entidades AI, Az, ... , Any que las unicas flechas estan en los arcos de los conjuntos de entidades Ai+l: Ai+2, ... , An. Entonces,las dos interpretaciones posibles son:

1. Una combinaci6n concreta de entidades de AI: A2, ... ,Ai se puede asociar, a 10 sumo, con unacombinaci6n de entidades de Ai+l, Ai+2: .... An. Por tanto, la clave primaria de la re1aci6nR sepuede crear mediante la uni6n de las claves primarias de A i) A 2: .. ) A .i.

2. Para cada conjunto de entidades Ab i< k S; n, cada combinaci6n de las entidades de losotros conjuntos de entidades se puede asociar, a 10sumo, can una entidad de Ak. Cada conjunto{AI) Az,: Ak-I, Ak+I), An}, para i< k S; n, forma, entonces, una clave candidata.

Cada una de estas interpretaciones se ha usado en diferentes libros y sistemas. Para evitar confusiones,s610se permite una flecha saliente de cada conjunto de relaciones, en cuyo caso las dos interpretacionesson equiva1entes. En e1Capitulo 7 (Apartado 7.4) se estudia el concepto de dependencia [uncional, quepermite especiicar cualquiera de estas dos interpretaciones sin ambiguedad.En los diagramas E-R se usan Iineas dob1es para indicar que la participaci6n de un conjunto de en-

tidades en un conjunto de relaciones es total; es decir, cada entidad del conjunto de entidades aparece,al menos, en una relaci6n de ese conjunto de relaciones. Por ejemplo, considerese la relaci6n prestatarioentre clientes y prestamos. Una linea doble de pres iamo a prestaiario, como en la Figura 6.13, indica quecada prestamo debe tener, almenos. un cliente asociado.Los diagramas E-R tambien ofrecen una manera de indicar restricciones mas complejas sobre el nu-

mere de veces que cada entidad participa en las relaciones de un conjunto de relaciones. Un segmentoentre un conjunto de entidades y un conjunto de relaciones binarias puede tener unas cardinalidades

Figura 6.13 Participaci6n total de un conjunto de entidades en un conjunto de relaciones.


15


Figura 6.14 Limites de cardinalidad en los conjuntos de relaciones.minima y maxima asociadas, que se muestran de la forma min ..max, donde min es la cardinalidadminima y max es la maxima. Un valor minimo de 1 indica una participaci6n total del conjunto de enti-dades en el conjunto de relaciones. Un valor maximo de 1 indica que la entidad participa, a 1 0 sumo, enuna relacion, mientras que un valor maximo de * indica que no hay limite. Tengasc en cuenta que unaetiqueta 1..* en un segmento es equivalente a una linea doble.Por ejemplo, considerese la Figura 6.14. EI segmento entre presiamo y prestatario tiene una restriccionde cardinali dad de 1..1, que significa que tanto la cardinalidad minima como la maxima son 1.Es decircada prestamo debe tener exactamente un cliente asociado. El limite 0..* en el segmento de cLiente aprestatario indica que cada cliente puede no tener ningun prestamo 0 tener varios. Por tanto, la relacionprestatario es uno a varios de clienie a pres iamo y, ademas, la participaci6n de pres tamo en prestatario estotal.Es facil malinterpretar 0..* en el segmento entre clienie y prestatario y pensar que la relaci6n prestatarioes varios a uno de clienie a presiama= esu: es exactamente 10 contrario a la interpretaci6n correcta.Si los dos segmentos de una relaci6n binaria tienen un valor maximo de 1, la relaci6n es uno a unSi se hubiese especificado un limite de cardinalidad de 1..* en el segmento entre cLiente y presiaiario.seestarfa diciendo que cada cliente debe tener, al menos, un prestamo.

6.5 Aspectos del diseiio entidad-relaci6nLos conceptos de conjunto de entidades y de conjunto de relaciones no son precisos, yes posible definirel conjunto de entidades y las relaciones entre ellas de diferentes formas. En este apartado se examinanaspectos basicos del disefio de esquemas de bases de datos E-R.El Apartado 6.7.4 trata el proceso dedisefio con mas detalle.

6.5.1 Uso de conjuntos de entidades y de atributosConsiderese el conjunto de entidades e m p l e a d o con los atributos n om b r e e m p le a do y n u m e r o i e u f o n o . -puede argumentar que un telefono es una entidad en sf misma con los atributos numerotelejono y u l : : -caci6n; la ubicaci6n puede ser la sucursal 0 el domicilio donde el telefono esta instalado, y se puederrepresentar los telefonos m6viles (celulares) mediante el valor "rnovil". Sise adopta este punto de vistahay que redefinir el conjunto de entidades empleado como:

El conjunto de entidades e m p l e a d o con los atributos i d e m p l e ad o y n o m b r e e m p l e a d o . El conjunto de entidades telefono con los atributos numero te ie jono y ubicacion. La relaci6n i e i e f onoemp leado , que denota la asociaci6n entre los empleados y sus telefonos.

Estas alternativas se muestran en la Figura 6.15.LCual es, entonces, la diferencia principal entre estas dos definiciones de empleado? Tratar el telefonocomo el atributo numero_telefono implica que cada empleado tiene exactamente un numero de telefonoTratar el telefono como la entidad telejono permite que los empleados tengan varies numeros de tele-


16

6.5 Aspectosdeldiserioentidad-relaci6n 173

(a)

(b)Figura 6.15 Alternativas para empleado y ielefono.

fono (0 ninguno) asociados. Sin embargo, se puede definir en su lugar numerotelejono como atributomultivalorado para permitir varios telefonos por empleado.La diferencia principal es que tratar el telefono como entidad modela mejor una situaci6n en la quesepuede querer guardar informaci6n extra sobre el telefono, como su ubicaci6n, su tipo (movil, videote-

lefono 0 fijo)0 las personas que 1 0 comparten. Por tanto, tratar el telefono como entidad es mas generalque tratarlo como atributo y resulta adecuado cuando la generalidad pueda ser util.En cambio, no seria apropiado tratar el atributo nombre empleado como entidad; es dificil argumentar

que n om b re e m ple ad o sea una entidad en sf misma (a diferencia de 1 0 que ocurre con teMfono) . Asi pues,resulta adecuado tener n om b re e mp le ad o como atributo del conjunto de entidades empleado.Por tanto, se suscitan naturalmente dos preguntas: lque constituye un atributo? y lque constituye

un conjunto de entidades? Desafortunadamente no hay respuestas sencillas. Las distinciones depend enprincipalmente de la estructura de la empresa real que se este modelando y de la semantica asociadacon el atributo en cuesti6n.Un error comun es usar la claveprimaria de un conjunto de entidades como atributo de otro conjunto

de entidades en lugar de usar una relaci6n. Por ejemplo, es incorrecto modelar idclienie como atributode pres iamo, aunque cada prestamo tenga s6lo un cliente. La relaci6n prestatario es la forma correcta derepresentar la conexi6n entre los prestamos y los clientes, ya que hace explicita su conexi6n, en lugar dedejarla implicita mediante un atributo.Otro error relacionado con este que se comete a veces es escoger los atributos de clave primaria de

los conjuntos de entidades relacionados como atributos del conjunto de relaciones. Por ejemplo, numero_pres tamo (el atributo de clave primaria de pres iamoi e id c lie nie (la clave primaria de cliente) no debenaparecer como atributos de la relaci6n prestatario. Esto no es adecuado, ya que los atributos de claveprimaria estan implicitos en el conjunto de relaciones''.3. Cuando se crea un esquema de relacion a partir del esquema E-R los atributos pueden aparecer en una tabla creada a partirdel conjunto de relaciones prestatario, como se vera mas adelante; no obstante, no deben aparecer en el conjunto de relacionesprestaiario.


17

174 Capitulo 6 Diseno de bases de datos y el modele E-R

numero _pre st amo

Figura 6.16 pres iamo como conjunto de relaciones.

6.5.2 Usode losconjuntos de entidades y de los conjuntos de relacionesNo siempre esta claro si es mejor expresar un objeto mediante un conjunto de entidades 0meun conjunto de relaciones. En el Apartado 6.2.1 se dio por supuesto que los prestamos bancarmodelaban como entidades. Una alternativa es modelar los prestamos no como entidades, sinorelaciones entre los clientes y las sucursales, con numeropresiamo e importe como atributos descripcomopuede verse en la Figura 6.16. Cada prestamo se representa mediante una relaci6n entre uny una sucursal.Si cada prestamo se concede exactamente a un cliente y se asocia exactamente con una SU

se puede encontrar satisfactorio el disefio en el que cada prestamo se representa como una reSin embargo, con este disefio, no se puede representar convenientemente una situaci6n en la qprestamo se conceda a varios clientes conjuntamente. Para tratar esta situaci6n se debe definrelaci6n para cada prestatario de ese prestamo conjunto. Entonces habra que replicar los valolos atributos descriptivos numeropre s t amo e impor ie en cada una de esas relaciones. Cada una drelaciones debe, pOl'supuesto, tener el mismo valor para los atributos descriptivos n um ero presiaimporte .Seplantean dos problemas como resultado de esta replica: (1) los datos se almacenan varias

10que hace que se desperdicie espacio de almacenamiento, y (2) las actualizaciones pueden dedatos en un estado inconsistente, en el que los valores de atributos que se supone que tienen e1mvalor difieran. El problema de c6mo evitar esta replica se trata formalmente mediante la ieorinormalizacion, que se aborda en el Capitulo 7.El problema de la replica de los atributos numeropresiamo e impor te no aparece en el disefio o

del Apartado 6.4,ya que alli prestamo esun conjunto de entidades.Un criterio para determinar si se debe usar un conjunto de entidades 0 un conjunto de rela

puede ser escoger un conjunto de relaciones para describir las acciones que ocurran entre entiEste enfoque tambien puede ser util para decidir si ciertos atributos se pueden expresar mejorrelaciones.

6.5.3 Conjuntos de relaciones binarias y n-ariasLas relaciones en las bases de datos suelen ser binarias. Puede que algunas relaciones que no parecbinarias sepuedan representar mejor mediante varias re1acionesbinarias. Por ejemplo, sepuede cre1aci6nternaria padres, que relaciona a cada hijo con su padre y con su madre. Sin embargo, esa rese puede representar mediante dos relaciones binarias, padre y madre , que relacionan a cada hijopadre y con su madre por separado. El uso de las dos relaciones padre y madre permite el registrmadre del nino almque no se conozca la identidad del padre; si se usara en la relaci6n ternaria panecesitarta un valor nulo. En este caso es preferible usar conjuntos de relaciones binarias.


18/

6.5 Aspectos del disefio entidad-relacion 175

De hecho, siempre es posible sustituir los conjuntos de relaciones no binarias (naria, para 11, > 2) porvarios conjuntos de relaciones binarias. Por simplificar, considerense el conjunto de relaciones abstractoternario ( 1 1 , = 3) R Y los conjuntos de entidades A, B, Y C. Se sustituye el conjunto de relaciones R porun conjunto de entidades E y se crean tres conjuntos de relaciones como se muestra en la Figura 6.17:

PA, que relaciona E y A PB, que relaciona E y B Pc, que relaciona E y C

Si el conjunto de relaciones R tiene atributos, estes se asignan al conjunto de entidades E; adem as, se creaun atributo de identificacion especial para E (ya que se debe poder distinguir las diferentes entidadesde cada conjunto de entidades con base en los val ores de sus atributos). Para cada relacion (ai) b. , c.) delconjunto de relaciones R se crea una nueva entidad ei del conjunto de entidades E. Luego, en cada unode los tres nuevos conjuntos de relaciones. se inserta una relacion del modo siguiente:

(e., ( .Li) en RA (e., bi) en Rn (e., Ci) en He

Este proceso se puede generalizar de forma directa a los conjuntos de relaciones n-arias. Por tan-to, conceptualmente, se puede restringir el modelo E-R para que solo incluya conjuntos de re1acionesbinarias. Sin embargo, esta restriccion no siempre es deseable.

Es posible que sea necesario crear un atributo de identificacion para que el conjunto de entidadesrepresente el conjunto de relaciones. Este atributo, junto con los conjuntos de relaciones adicio-nales necesarios. incrementa la complejidad del disefio y (como se vera en el Apartado 6.9) losrequisitos globales de almacenamiento.

Un conjunto de relaciones n-arias muestra mas claramente que varias entidades participan enuna sola relacion.

Puede que no haya forma de traducir las restricciones a la relacion ternaria en restricciones a lasrelaciones binarias. Por ejemplo, considerese una restriccion que dice que R es varios a uno de A,B a C; es decir, cada par de entidades de A y de B se asocia. a 1 0 sumo, con una entidad de C.Esta restriccion no se puede expresar mediante restricciones de cardinalidad sobre los conjuntosde relaciones RA, H B YRe

Considerese el conjunto de relaciones t rabaja_en del Apartado 6.2.2, que relaciona emp le a do , s u cu r sa ly t rabajo. No se puede dividir directamente t rabajaen en relaciones binarias entre empleado y sucursaly entre empleado y t rabajo. Si se hiciese, se podna registrar que Santos es director e interventor y queSantos trabaja en Navacerrada y en Centro; sin embargo, no se podria registrar que Santos es director deNavacerrada e interventor de Centro, pero que no es interventor de Navacerrada ni director de Centro.

Figura 6.17 Una relacion ternaria y tres relaciones binarias ..


19/

176 Capitulo 6 Diseno de bases de datos y el modelo E-R

clienie (nombre clienie) cuenta \numera cuenta, Jecna_acceso)

3 junio 200524 mayo 2005

Lopez10 junio 2005

Abril 28 mayo 2005

Santos17 junio 200524 junio 2005

Ruperez 23 mayo 2005

Figura 6.18 f echa_acceso como atributo del conjunto de entidades cuenia.

El conjunto de relaciones trabajaen se puede dividir en relaciones binarias mediante la creaci6nnuevos conjuntos de entidades como se ha descrito anteriormente. Sin embargo, no serfa muy natura

6.5.4 IUbicad6n de 50S atrlbutos de las relacionesLa raz6n de cardinalidad de una relaci6n puede afectar a la ubicaci6n de sus atributos. Por tanto,atributos de los conjuntos de relaciones uno a uno 0uno a varios pueden estar asociados con uno deconjuntos de entidades participantes, en lugar de can el conjunto de relaciones. Por ejemplo, especquemos que imposi tor es un conjunto de relaciones uno a varios tal que cada cliente puede tener vacuentas, pero cad a cuenta s610 puede tener un cliente como titular. En este caso, el atributo [echa acceque especifica la fecha en que el cliente tuvo acceso a la cuenta por ultima vez, podna estar asocicon el conjunto de entidades cuenta, como se describe en la Figura 6.18; para simplificar la figurase muestran algunos de los atributos de los dos conjuntos de entidades. Dado que cada entidad cuparticipa en una relaci6n con un ejemplar de cliente, como maximo, hacer esta designaci6n de atributendria el mismo significado que colocar f echa_acceso en el conjunto de relaciones imposi tor. Los atribude un conjunto de relaciones uno a varios s610 se pueden recolocar en el conjunto de entidades dparte "varios" de la relaci6n. Por otra parte, para los conjuntos de entidades uno a uno, los atributos1arelaci6n se pueden asociar can cualquiera de las entidades participantes.La decisi6n de diserio sabre la ubicaci6n de los atributos descriptivos en estos casos-como atrib

de la relaci6n 0 de la entidad-debe reflejar las caractensticas de la empresa que se modela. El disedar puede elegir mantener [echaacceso como atributo de imposi tor para expresar explfcitamente quproduce un acceso en el punto de interacci6n entre los conjuntos de entidades cliente y cuenia.La elecci6n de la ubicaci6n del atributo es mas sencilla para los conjuntos de relaciones varios a

rios. Volviendo al ejemplo, especifiquemos el caso, quiza mas realista, de que imposi tor sea un conjude relaciones varios a varios que expresa que cada cliente puede tener una a mas cuentas, y que ccuenta puede tener a varios clientes como titulares. Si hay que expresar la fecha en que un cliente dtuvo acceso por ultima vez a una cuenta concreta, f echa_acceso debe ser atributo del conjunto de rciones imposi tor, en lugar de serlo de cualquiera de las entidades participantes. Si f echa_acceso fueseatributo de cuenta, por ejemplo, no se podria determinar que cliente llev6 a cabo el acceso mas reciea una cuenta conjunta. Cuando un atributo se determina mediante la combinaci6n de los conjuntosentidades participantes, en lugar de por cada entidad por separado, ese atributo debe estar asocicon el conjunto de relaciones varios a varios. La Figura 6.3 muestra la ubicaci6n de f echa_acceso coatributo de la relaci6n; de nuevo, para simplificar la figura, s610 se muestran algunos de los atributoslos dos conjuntos de entidades.


20

6 .6 Conjuntos de entidades debiles 177

6.6 Conjuntos de entidades debllesPuede que un conjunto de entidades no tenga suficientes atributos para formar una clave primaria. Eseconjunto de entidades se denomina conjunto de entidades debiles. Los conjuntos de entidades quetienen una clave primaria se denominan conjuntos de entidades fuertes.Como ilustraci6n, considerese el conjunto de entidades pago, que tiene tres atributos: numero pago,fecha_pago e impor ie pago. Los numeros de pago suelen ser nurneros secuenciales, a partir de I, generadosindependientemente para cada prestamo. Por tanto, aunque cada entidad pago es distinta, los pagos dediferentes prestamos pueden compartir el mismo numero de pago. Asi, este conjunto de entidades notiene clave primaria: es un conjunto de entidades debiles,Para que un conjunto de entidades debiles tenga sentido, debe estar asociado con otro conjunto deentidades, denominado conjunto de entidades identificadoras 0 propietarias. Cada entidad debil de-be estar asociada con una entidad identificadora: es decir, se dice que el conjunto de entidades debilesdepende existencialmente del conjunto de entidades identificadoras. Se dice que el conjunto de enti-dades identificadoras posee el conjunto de entidades debiles al que identifica. La relaci6n que asocia elconjunto de entidades debiles con el conjunto de entidades identificadoras se denomina relacion iden-tificadora. La relaci6n identificadora es varios a uno del conjunto de entidades debiles al conjunto deentidades identificadoras y la participacion del conjunto de entidades debiles en 1arelaci6n es total.En nuestro ejemplo, el conjunto de entidades identificador de pago es presiamo, y la relaci6n pago

_prestamo que asocia las entidades pago con sus correspondientes entidades pres iamo es la re1aci6n iden-tificadora.Aunque los conjuntos de entidades debiles no tienen clave primaria, hace falta un medio para dis-

tinguir entre todas las entidades del conjunto de entidades debiles que dependen de una entidad fuerteconcreta. El discriminante de un conjunto de entidades debiles es un conjunto de atributos que perrniteque se haga esta distinci6n. Por ejemplo, el discriminante del conjunto de entidades debiles pago es elatributo numeropago ya que, para cada prestamo, el numero de pago identifica de forma {mica cadapago de ese prestamo. El discriminante del conjunto de entidades debiles se denomina c lave parcial delconjunto de entidades.La clave primaria de un conjunto de entidades debiles se forma con la clave primaria del conjunto deentidades identificadoras y el discriminante del conjunto de entidades debiles. En el caso del conjunto

de entidades pago, su clave prima ria es i numeropres tamo, numero_pago}, donde numeropresiamo es laclave prima ria del conjunto de entidades identificadoras, es decir, presiamo, y numero_pago distingue lasentidades pago de un rnismo prestamo.El conjunto de entidades identificadoras no deber tener atributos descriptivos, ya que cualquier atri-

buto requerido puede estar asociado con el conjunto de entidades debiles (vease 1a discusi6n sobre eltraslado de los atributos del conjunto de re1aciones a los conjuntos de entidades participantes en e1Apartado 6.5.4).Los conjuntos de entidades debiles pueden participar en otras relaciones aparte de la relaci6n iden-tificadora. Por ejemplo, 1a entidad paga puede participar en una relaci6n can el conjunto de entidadescuenta, identificando la cuenta desde la que se ha realizado el pago. Los conjuntos de entidades debi-les pueden participar como propietario de una relaci6n identificadora con otro conjunto de entidadesdebiles, Tambien es posible tener conjuntos de entidades debiles con mas de un conjunto de entidadesidentificadoras. Cada entidad debil se identificaria mediante una combinaci6n de entidades, una de ca-da conjunto de entidades identificadoras. La clave primaria de la entidad debil consistiria de la unionde las claves primarias de los conjuntos de entidades identificadoras y el discriminante del conjunto deentidades debiles.En los diagramas E-Rlos rectangulos con lineas dobles indican conjuntos de entidades debiles, mien-

tras que un rombo con Iineas dobles indica la correspondiente re1aci6n de identificaci6n. En la Figu-ra 6.19, el conjunto de entidades debiles pago depende del conjunto de entidades fuertes prestamo me-diante el conjunto de relaciones pago_pl 'estamo.La figura tambien ilustra el uso de Iineas dobles para indicar par ti cipac i6n total -l a participacion del

conjunto de entidades (debiles) pago en 1arelaci6n pago_pl 'estamo es total, 10 que significa que cada pagodebe estar relacionando mediante pago_prestamo con alguna cuenta. Finalmente, la flecha de pago_pres-


21

180 Capitulo 6 Disef\o de bases de datos y el modelo E-R

Figura 6.20 Especializaci6n y generalizaci6n.

n iv el s u pe ri or y uno 0varios conjuntos de entidades de n iv el i nf er io r. En este ejemplo, persona es el con-junto de entidades de nivel superior y clienie y empleado son conjuntos de entidades de nivel inferior. E1-este caso, los atributos que son conceptualmente iguales tienen nombres diferentes en los dos conjunt sde entidades de nivel inferior. Para crear generalizaciones los atributos deb en tener un nombre comur,y representarse mediante la entidad de nivel superior persona . Se pueden usar los nombres de atribut sidp erson a, nom bre, ca lle y ciudad, como se vio en el ejemplo del Apartado 6.7.1.Los conjuntos de entidades de nivel superior e inferior tambien se pueden denominar con los ter-minos superc1ase y subclase, respectivamente. El conjunto de entidades persona es la superclase de lassubclases clienie y emp leado .A todos los efectos practices, la generalizaci6n es una inversi6n simple de la especializacion, Se apli-caran ambos procesos, combinados, en el transcurso del disefio del esquema E-R de una empresa. Er

terminos del propio diagrama E-R no se distingue entre especializaci6n y generalizaci6n. Los nivelesnuevos de representaci6n de las entidades se distinguen (especializaci6n) 0 sintetizan (generalizaci6ncuando el esquema de diseno llega a expresar completamente la aplicaci6n de la base de datos y 1 srequisitos del usuario de la base de datos. Las diferencias entre los dos enfoques se pueden caracterizarmediante su punto de partida y su objetivo global,La especializaci6n parte de un unico conjunto de entidades: destaca las diferencias entre las entidadesdel conjunto mediante la creaci6n de diferentes conjuntos de entidades de nivel inferior. Esos conjunt sde entidades de nivel inferior pueden tener atributos 0 participar en relaciones que no se aplican c .todas las entidades del conjunto de entidades de nivel inferior. Realmente, la raz6n de que el disenado:aplique la especializaci6n es poder representar esas caracteristicas distintivas. Si cliente y en tp leado notuvieran atributos que no tuvieran las entidades persona ni participaran en relaciones diferentes de 1 3 0 'relaciones en las que participan las entidades persona, no habrfa necesidad de especializar el conjunto de-entidades persona .La generalizaci6n parte del reconocimiento de que varios conjuntos de entidades comparten algi-mascaracterfsticas comunes (es decir, se describen mediante los mismos atributos y participan en los mismosconjuntos de relaciones). Con base en esas similitudes, la generalizaci6n sintetiza esos conjuntos deentidades en un solo conjunto de nivel superior. La generalizaci6n se usa para destacar las similitudes


22

6.7 Caracterfsticas del modelo E-R extendi.i. 181

entre los conjuntos de entidades de nivel inferior y para ocultar las diferencias; tambien permite unaeconomia de representaci6n, ya que no se repiten los atributos compartidos.6.7.3 Herencia de los atributosUna propiedad crucial de las entidades demyel superior e inferior creadas mediante la especializacion yla generalizaci6n es la herencia de los atributos. Sedice que los atributos de los conjuntos de entidadesde nivel superior son heredados por los conjuntos de entidades de nivel inferior. Por ejemplo, clienie yempleado heredan los atributos de persona. Asi, cliente se describe mediante sus atributos n om b re , c alle yciudad y, adicionalmente, por el atributo i d_ c li en te ; emp le a do se describe mediante sus atributos nombre ,calle y ciudad y, adicionalmente, por los atributos i d_empleado y sueldo.Los conjuntos de entidades de nivel inferior (0 subclases) tambien heredan la participaci6n en los

conjuntos de relaciones en los que participa su entidad de nivel superior (0superclase). Los conjuntosde entidades o f ic ia l , ca je ro y secreiaria pueden participar en el conjunto de relaciones t rabaja_para , ya quela superclase empleado participa en la relaci6n t rabaiapara . Laherencia de los atributos se aplica a todaslas capas de conjuntos de entidades de nivel inferior. Los conjuntos de entidades anteriores puedenparticipar en cualquier relaci6n en la que participe el conjunto de entidades persona.Tanto si se llega a una porci6n dada del modele E-R mediante la especializaci6n como si se hacemediante la generalizaci6n, el resultado esbasicarnente elmismo: Un conjunto de entidades de nivel superior con los atributos y las relaciones que se aplican atodos sus conjuntos de entidades de nivel inferior.

Conjuntos de entidades de nivel inferior con caracteristicas distintivas que s6lo se aplican en unconjunto dado de entidades de nivel inferior.

En 10que sigue, aunque a menudo 5610sehaga referencia a la generalizaci6n, las propiedades que seestudian corresponden completamente a ambos procesos.LaFigura 6.20 describe una jerarquia de conjuntos de entidades. En la figura, empleado esun conjunto

de entidades de nivel inferior de persona y un conjunto de entidades de nivel superior de los conjuntosde entidades o f ic ia l , ca ie ro y secretaria. En las jerarquias un conjunto de entidades dado s610puede estarimplicado como conjunto de entidades de nivel inferior en W1arelaci6n ES;es decir, los conjuntos deentidades de este diagram a 5610tienen herencia unica, Siun conjunto de entidades es un conjunto deentidades de nivel inferior enmas de una relaci6n ES,el conjunto de entidades tiene herencia multiple,y la estructura resultante se denomina reticulo.6.7.4 Restriccionesa las generalizacionesPara modelar una empresa con mas precisi6n, el disefiador de la base de datos puede decidir imponerciertas restricciones sobre una generalizaci6n concreta. Un tipo de restricci6n implica la determinacionde las entidades que pueden formar parte de un conjunto de entidades de nivel inferior dado. Esapertenencia puede ser una de las siguientes:

Definida por la condicion. En los conjuntos de entidades de nivel inferior definidos por la condi-ci6n, la pertenencia se evalua en funci6n del cumplimiento de una condici6n 0predicado explf-citopor la entidad. Por ejemplo, sup6ngase que elconjunto de entidades de nivel superior cuentatiene el atributo t ipo_cuenta. Todas las entidades cuenta se evaluan segun el atributo t ipo_cuentaque las define. S6lo las entidades que satisfacen la condici6n t ipo_cuenta = "cuenta de ahorro"pueden pertenecer al conjunto de entidades de nivel inferior cuenta_ahorro . Todas las entidadesque satisfacen la condici6n t ipo_cuenta = "cuenta corriente" se incluyen en cuenta_corriente. Dadoque todas las entidades de nivel inferior se evaluan en funci6n del mismo atributo (en este caso,t ipo_cuenta) , se dice que este tipo de generalizaci6n esta definida pOI'el atributo.

Definida por el usuario. Los conjuntos de entidades de nivel inferior definidos par el usuariono estan restringidos por una condici6n de pertenencia; mas bien, el usuario de la base de datosasigna las entidades a un conjunto de entidades dado. Por ejemplo, sup6ngase que, despues detres meses de trabajo, los empleados del banco se asignan a uno de los cuatro grupos de trabajo.


23

182 Capitulo 6 Diseno de bases de datos y elmodelo E-R

En consecuencia, los grupos se representan como cuatro conjuntos de entidades de nivel inferiordel conjunto de entidades de nivel superior empleado. No se asigna cada empleado a una entidacgrupo concreta automaticamente de acuerdo con una condici6n explfcita que 1 0 defina. En vez deeso, la asignaci6n al grupo la lleva a cabo el usuario que toma persona a persona. La asignaci6.se implementa mediante una operaci6n que afiade cada entidad a un conjunto de entidades.

Un segundo tipo de restricciones tiene relaci6n con la pertenencia de las entidades a mas de un co -junto de entidades de nivel inferior de la generalizaci6n. Los conjuntos de entidades de nivel inferiorpueden ser de uno de los tip?S siguientes:

Disjuntos. La r es tr ic cio n s ob re la c on dic io n d e d is iu nc io n exige que cada entidad no pertenezca amas de un conjunto de entidades de nivel inferior. En el ejemplo, cada entidad cuenia s610puedecumplir una condici6n del atributo i ipocuenia; cada entidad puede ser una cuenta de ahorro ouna cuenta corriente, pero no ambas cosas a la vez.

Solapados. En las genero li zac ione s so lapadas la misma entidad puede pertenecer a mas de un con-junto de entidades de nivel inferior de la generalizaci6n. Como ilustraci6n, considerese el ejemplcdel grupo de trabajo de empleados y sup6ngase que algunos directores participan en mas de ur.grupo de trabajo. Cada empleado, por tanto, puede aparecer en mas de uno de los conjuntosde entidades grupo que son conjuntos de entidades de nivel inferior de empleado. Por tanto, lageneralizaci6n es solapada.Como ejemplo adicional, sup6ngase que 1ageneralizaci6n aplicada a los conjuntos de entida-

des cliente y empleado conduce a un conjunto de entidades de nivel superior persona. La generali-zaci6n es solapada si los empleados tambien pueden ser clientes.

El solaparniento de las entidades de nivel inferior es el caso predeterminado; la restricci6n sobre la condi-ci6n de disjunci6n se debe imponer explfcitamente a la generalizaci6n (0 especializaci6n). La restriccionsobre condici6n de disjunci6n se puede denotar en los diagramas E-R afiadiendo la palabra disjunta juntoal simbolo del triangulo.Una ultima restriccion, la restricci6n de completitud sobre una generalizaci6n 0 especializaci6n, e -

pecifica si una entidad del conjunto de entidades de nivel superior debe pertenecer, a1menos, a uno delos conjuntos de entidades de nivel inferior de la generalizaci6n 0especializaci6n. Esta restricci6n puedeser de uno de los tipos siguientes:

Generalizaci6n 0 especializaci6n total. Cada entidad de nivel superior debe pertenecer a urconjunto de entidades de nivel inferior.

Generalizaci6n 0 especializaci6n parcial. Puede que alguna entidad de nivel superior no perte-nezca a ningun conjunto de entidades de nivel inferior.

La generalizaci6n parcial es la predeterminada. Se puede especificar la generalizaci6n total en los dia-grama E-R usando uria linea doble para conectar el rectangulo que representa el conjunto de entidadesde nivel superior con el simbolo del triangulo. (Esta notaci6n es parecida ala usada para la participacio ..total en una relaci6n).La generalizaci6n de cuenta es total: todas las entidades cuenia deben ser cuentas de ahorro a cuenta

corrientes. Como el conjunto de entidades de nivel superior al que se llega mediante la generalizaci6nsuele estar compuesto unicamente de entidades de los conjuntos de entidades de nivel inferior, la res-tricci6n de completitud para los conjuntos de entidades de nivel superior generalizados suele ser total.Cuando la restricci6n es parcial, las entidades de nivel superior no estan limitadas a aparecer en losconjuntos de entidades de nivel inferior. Los conjuntos de entidades grupo de trabajo ilustran una espe-cializaci6n parcial. Como los empleados s6lo se asignan a cada grupo despues de llevar tres meses en eltrabajo, puede que algunas entidades empleado no pertenezcan a ninguno de los conjuntos de entidadesgrupo de nivel inferior.Los conjuntos de entidades equipo se pueden caracterizar mejor como especializaci6n de empleado

parcial y solapada. La generalizaci6n de c u en ia c o rr ie n te y c ue nia a h or ro en cuenia es W1ageneralizaci6ntotal y disjunta. Las restricciones de completitud y sobre la condici6n de disjunci6n, sin embargo, no


24

6.7 Caracterfsticas del modelo E-R extendido 183

dependen una de la otra. Las caracteristicas de las restricciones tambien pueden ser parcial-disjunta ytotal-solapada.Es evidente que algunos requisitos de inserci6n y de borrado son consecuencia de las restricciones

que se aplican a una generalizaci6n 0 especializaci6n dada. Por ejemplo, cuando se impone una res-tricci6n de completitud total, las entidades insertadas en un conjunto de entidades de nivel superior sedeben insertar, al menos, en uno de los conjuntos de entidades de nivel inferior. Con una restricci6nde definici6n por condici6n, todas las entidades de nivel superior que cumplen Ia condici6n se debeninsertar en ese conjunto de entidades de nivel inferior. Finalmente, las entidades que se borren de losconjuntos de entidades de nivel superior, se deben borrar tambien de todos los conjuntos de entidadesde nivel inferior asociados a los que pertenezcan.

6.7.5 AgregacionUna limitaci6n del modelo E-R es que no es posible expresar relaciones entre las relaciones. Para ilustrarla necesidad de estos constructores, considerese la relaci6n ternaria irabaia en, que se ya se ha vistoanteriormente, entre em ple ad o, s uc ur sa l y t rabajo (vease la Figura 6.12). Sup6ngase ahora que se desearegistrar el director responsable de las tareas realizadas por cada empleado de cada sucursal; es decir, sedesea registrar al director responsable de las combinaciones ( em p le ad o, s uc ur sa l, tr ab a jo ). Sup6ngase queexiste un conjunto de entidades director.Una alternativa para representar esta relaci6n es crear una relaci6n cuaternaria dirige entre emplea-

d o, su cu rsa l, tra ba jo y director (se necesita una relaci6n cuaternaria-una relaci6n binaria entre directory empleado no perrnitiria representar las combinaciones ( su cu rs al, tr ab a jo ) de cada empleado que sonresponsabilidad de cada director). Mediante los construct ores de modelado basicos del modelo E-R seobtiene el diagrama E-R de la Figura 6.21(por simplificar se han omitido los atributos de los conjuntosde entidades).Parece que los conjuntos de relaciones t rabaja_en y dirige se pueden combinar en un solo conjunto de

relaciones. No obstante, no se deben combinar en una sola relacion, ya que puede que algunas combi-naciones e mp le ad o, s uc ur sa l, tra ba jo no tengan director.No obstante, hay informaci6n redundante en la figura obtenida, ya que cada combinaci6n empleado ,s uc ur sa l, tr ab ajo de dirige tambien esta en t rabaja_en. Siel director fuese un valor en lugar de una entidad

director, se podria hacer que director fuese un atributo multivalorado de la relaci6n i raba iaen . Pero esodificulta (tanto l6gicamente como en coste de ejecuci6n) encontrar, por ejemplo, las tripletas empleado-sucursal-trabajo de las que es responsable cada director. Como el director es una entidad director, estaalternativa queda descartada en cualquier caso.

Figura 6.21 Diagrama E-R can relaciones redundantes.


25

184 Capitulo 6 Diserio de bases de datos y el modelo E-R

Figura 6.22 Diagrama E-R con agregaci6n.La mejor forma de modelar una situaci6n como la descrita es usar la agregaci6n. La agregaci6n es

una abstracci6n a traves de la cual1as relaciones se tratan como entidades de nivel superior. Asi, paraeste ejemplo, se considera el conjunto de relaciones t rabajac_en (que relaciona los conjuntos de entidadesemple ado , s uc ur sa l y trabajo) como el conjunto de entidades de nivel superior denominado t rabaja_en. Eseconjunto de entidades se trata de la misma forma que cualquier otro conjunto de entidades. Se puedecrear entonces 1arelaci6n binaria dirige entre t rabaja_en y director para representar al responsable de cadatarea. La Figura 6.22 muestra una notaci6n para la agregaci6n que se usa habitualmente para representaresta situaci6n.

6.7.6 Notaciones E-R alternativasLa Figura 6.23 resume el conjunto de simbolos que se ha usado en los diagramas E-R. No hay una normauniversal para la notaci6n de los diagramas E-R, y cada libra y cada programa inforrnatico de diagrarnasE-R usa notaciones diferentes.La Figura 6.24 indica alguna de las notaciones alternativas que mas se usan. Los conjuntos de entida-

des se pueden representar como rectangulos con el nombre por fuera, y los atributos relacionados unosdebajo de los otros dentro del rectangulo. Los atributos clave prima ria se indican relacionandolos en laparte superior, con una linea que los separa de los demas atributos.Las restricciones de cardinalidad s pueden indicar de varias formas, como se muestra en la Figu-

ra 6.24. Las etiquetas * y 1 en los segmentos que salen de las relaciones se usan a menudo para denota:relaciones varios a varios, uno a uno y varios a uno, como muestra la figura. El caso de uno a varios essimetrico con el de varios a uno y no se muestra. En otra notaci6n alternativa de la figura los conjuntosde relaciones se representan mediante Iineas entre los conjuntos de entidades, sin rombos; por tanto, s610se podran mode1ar relaciones binarias, Las restricciones de cardinalidad en esta notaci6n se muestranmediante 1anotaci6n "pata de gallo", como en la figura.Desafortunadamente no existe una notaci6n E-R normalizada. La nota cion que se usa en este libro

con rectangulos. rombos y elipses se denomina notaci6n de Chen, y la usa Chen en el articulo que intro-dujo el concepto de model ado E-R. El Instituto Nacional de EEUU para Norrnalizacion y Tecnologfa (U, .National Institute for Standards and Technology) definio una norma denominada IDEFIX en 1993, queusa la notaci6n de pata de gallo. IDEFIX tambien incluye gran variedad de notaciones diferentes que nose han mostrado, incluidas las barras vertic ales en los segmentos de las relaciones para indicar partici-pacion total y los circulos vacios para denotar participacion parcial. Hay gran variedad de herramientaspara la construcci6n de diagramas E-R, cada una de las cuales tiene sus propias variantes en cuanto a lanotaci6n. Veanse las referencias en las notas bibliograficas para obtener mas informacion.


26

6.8 Disefiode una base de datos para un banco 185

6.8 Disefio de una base de datos para un bancoAhora se centrara la atenci6n en los requisitos de disefio de la base de datos de una entidad bancaria conmas detalle y se desarrollara un disefio mas realista, aunque tambien mas complicado, de 10que se havis to en los ejemplos anteriores. No obstante, no se intentara modelar cada aspecto del disefio de la basede datos para el banco; se consideraran s610 unos cuantos aspectos para ilustrar el proceso de diseno debases de datos.Se aplicaran las dos fases iniciales del disefio de bases de datos, es decir, la recopilaci6n de los requi-

sitos de datos y el disefio del esquema conceptual, al ejemplo de entidad bancaria. Se usara el modelede datos E-R para traducir los requisitos de los usuarios a un esquema de disefio conceptual que serepresentara como diagrama E-R.Finalmente, el resultado del proceso de disefio E-R sera el esquema de una base de datos relacional.

En el Apartado 6.9 se considerara el proceso de generaci6n del diserio relacional a partir de un disenoE-R.

0 conjunto de C:J atributoentidadesOJ conjunto de ~ atributo multivaloradoentidades debiles0 conjunto de A atributo derivadorelaciones~

conjunto de participaci6nrelaciones 0==0 total del conjuntoidentificador de de entidades en laun conjunto de relacionentidades debiles

~ ~atributo discriminadorclave primaria de un conjunto deentidades debiles

relacion variosa varios

relacionuno a uno

~~~~~r~~~ indicador de rol

generalizaciontotal

~ _ relacion varios a~uno0~ limites de cardinalidad

ES(Especializacion 0generalizaci6n)

generalizaciondisjuntasjunta

Figura 6.23 Simbolos usados en la notaci6n E-R.


27

186 Capitulo 6 Diseno de bases de datos y el modelo E-R

conjunto de entidades Econ atributos A I, A 2 Y A3,Y clave primaria Al

relacion variosa varios

relacion unoa uno D,-R-:Drelacion varios ~_:!___a uno -V-

Figura 6.24 Notaciones E-R alternativas.Antes de comenzar con el disefio de la base de datos de la entidad bancaria se describiran brevemente

las alternatives de disefio E-R entre las que pueden escoger los disenadores de bases de datos.6.8.1 Alternativas de dlseno E-REl modelo de datos E-R permite gran flexibilidad en e1disefio de los esquemas de las bases de datos parmode1ar una empresa dada. A continuaci6n se sugiere la manera en que el disefiador de bases de datepuede escoger entre una amplia garna de alternativas. Entre las decisiones que debe tomar el disenado:estan:

Si usar atributos 0 conjuntos de entidades para representar los objetos (se ha estudiado enApartado 6.5.1). Si los conceptos del mundo real se expresan mejor mediante conjuntos de entidades 0medianteconjuntos de relaciones (Apartado 6.5.2).

Si usar relaciones ternarias 0pares de re1aciones binarias (Apartado 6.5.3). Si usar conjuntos de entidades fuertes 0debiles (Apartado 6.6); cada conjunto de entidades fuertes y sus conjuntos de entidades debiles se puede considerar como un solo "objeto" de la basedatos, ya que las entidades debiles dependen existencia1mente de 1a entidad fuerte.

Si es adecuado usar la generalizaci6n (Apartado 6.7.2); la generalizaci6n, ala jerarqufa de relaciones ES,contribuye a la modularidad al permitir que los atributos comunes de entidades parecidasse representen en un solo sitio del diagrama E-R.

Si es adecuado usar la agregaci6n (Apartado 6.7.5); la agregaci6n agrupa parte del diagrama E-en un solo conjunto de entidades, 1 0 que permite tratar el conjunto de entidades agregadas Call.una sola unidad sin necesidad de preocuparse por los detalles de su estructura interna.

Se puede ver que los disefiadores de bases de datos necesitan tener una buena comprensi6n deempresa que se mode1a para poder adoptar las diferentes decisiones de disefio necesarias.6.8.2 Requisitos de datos de la base de datos banc:ariaLa especificaci6n inicia1 de los requisitos de los usuarios se puede basar en entrevistas con los usuaride la base de datos y en el analisis propio del disefiador de 1a empresa. La descripci6n que surge de est


28/

6.8

fase de diserio sirve de base para concretar la estructura conceptual de la base de datos. La sig i2:-.:2lista describe las principales caracteristicas de la entidad bancaria. "E l banco esta orgamzaco en sucursaies. Caa.a s\ .\cU'rsa.\ es 'l .i-u \ ) ' ica .Qa. 'Cl \Ul\a . C\ \ . .\Qa.~c~l\c \IC\a . 'J SICidentifica con un nombre unico. El banco supervisa los activos de cada sucursal.

(9 Los clientes del banco se identifican mediante su valor de idclienie. El banco almacena cada nom-bre de cliente. y la calle y la ciudad donde vive cada cliente. Los clientes pueden tener cuentas ypueden solicitar prestamos. Cada cliente puede estar asociado con un empleado del banco con-creto, que puede actuar como responsable de prestamos 0 como asesor personal de ese cliente.

Los empleados del banco se identifican mediante su valor de id_empleado . La administraci6n delbanco almacena el nornbre y el numero de telefono de cada empleado, el nombre de los subordi-nados de cada empleado, y el numero id_empleado del jefe de cada empleado. El banco tarnbienmantiene un registro de la fecha de incorporaci6n a la empresa del empleado y , por tanto, de suantiguedad.

El banco ofrece dos tipos de cuentas: cuentas de ahorro y cuentas corrientes. Las cuentas puedentener como titular a mas un cliente, y cada cliente puede tener mas de una cuenta. Cada cuentatiene asignado un numero de cuenta unico. El banco mantiene un registro del saldo de cadacuenta y de la fecha mas reciente en que cada titular de la cuenta tuvo acceso a esa cuenta.Adcmas, cada cuenta de ahorro tiene un tipo de interes y para cada cuenta corriente se registranlos descubiertos generados.

" Cada prestamo se genera en una sucursal concreta y pueden solicitarlo 1.U100 mas clientes. Cadaprestamo se identifiea mediante un nurnero de prestarno unico. Para cada prestamo el bancomantiene un registro del importe del prestamo y de los pagos realizados y pendientes. Aunquelos mimeros de los pagos del prestamo no identifican de forma univoca cada pago entre los detodos los prestamos del banco, el numero de pago sf que identifica cada pago de un prestamoconcreto. De cada pago se registran la fecha y el importe.

En las entidades bancarias reales, el banco realiza un seguimiento de los abonos y cargos realizadosen las cuentas de ahorros y en las cuentas corrientes, igual que mantiene un registro de los pagos delos prestamos. De

capitulo 6- diseño de bases de datos y modelo e-r

Documents