CAPTULO 7 Diseo de bases de datos relacionales

por mapeado ER- y EER-a-relacional

ste captulo se centra en cmo disear el esquema de una base de datos relacional basndose en un Ediseo de esquema conceptual. Esto corresponde al diseo lgico de la base de datos o mapeado del modelo de datos que explicamos en la Seccin 3.l (vase la Figura 3.1). Presentamos los procedimien-tos para crear un esquema relacional a partir de un esquema Entidad-Relacin (ER) o un esquema ER mejo-rado (EER). Nuestra explicacin relaciona las construcciones de los modelos ER y EER, presentadas en los Captulos 3 y 4, con las construcciones del modelo relacional, presentadas en los Captulos 5 y 6. Muchas herramientas de ingeniera de software asistidas por computador (CASE) estn basadas en los modelos ER o EER, o en otros modelos similares, como hemos explicado en los Captulos 3 y 4. Los diseadores de bases de datos utilizan interactivamente estas herramientas computerizadas para desarrollar un esquema ER o EER para una aplicacin de base de datos. Muchas herramientas utilizan los diagramas ER o EER, o variaciones de ellos, para desarrollar grficamente el esquema, y despus lo convierten automticamente en un esquema de base de datos relacional en el DDL de un DBMS relacional especfico, empleando algoritmos parecidos a los presentados en este captulo. En la Seccin 7.l esbozamos un algoritmo en siete pasos para convertir las estructuras de un modelo ER bsi-co (tipos de entidades [fuertes y dbiles], relaciones binarias [con distintas restricciones estructurales], rela-ciones 11-a1Y y atributos [simples, compuestos y multivalor]) en relaciones. Despus, en la Seccin 7.2, con-tinuamos el algoritmo de mapeado describiendo cmo mapear construcciones del modelo EER (especializa-cin/generalizacin y tipos de unin [categoras]) a relaciones.

7.1 Diseo de una base de datos relacional utilizando el mapeado ER-a-relacional

7.1.1 Algoritmo de mapeado ER-a-relacional A continuacin describimos los pasos de un algoritmo para el mapeado ER-a-relacional, para lo que utiliza-remos la base de datos EMPRESA. El esquema ER de esta base de datos se muestra de nuevo en la Figura 7.1, mientras que en la Figura 7.2 mostramos el esquema de la base de datos relacional EMPRESA correspondien-te para ilustrar los pasos del mapeado.

190 Captulo 7 Diseo de bases de datos relacionales por mapeado ER- y EER-a-relacional

Figura 7.1. Diagrama del esquema conceptual ER para la base de datos EMPRESA.

TRABAJA PARA 1

ADMINISTRA CONTROLA

CONTROL

SUBORDINADOS_DE Nmero

Relacin

Paso 1: Mapeado de los tipos de entidad regulares. Por cada entidad (fuelie) regular E del esquema ER, cree una relacin R que incluya todos los atributos simples de E. Incluya nicamente los atributos sim-ples que conforman un atributo compuesto. Seleccione uno de los atributos clave de E como clave principal para R. Si la clave elegida de E es compuesta, entonces el conjunto de los atributos simples que la forman constituirn la clave principal de R. Si durante el diseo conceptual se identificaron varias claves para E, la informacin que describe los atribu-tos que forman cada clave adicional conserva su orden para especificar las claves (nicas) secundarias de la relacin R. El conocimiento sobre las claves tambin es necesario para la indexacin y otros tipos de anlisis. En nuestro ejemplo, creamos las relaciones EMPLEADO, DEPARTAMENTO Y PROYECTO en la Figura 7.2 como correspondientes a los tipos de entidad regulares EMPLEADO, DEPARTAMENTO Y PROYECTO de la Figura 7.1. La foreign key y los atributos de relacin, si los hay, no se incluyen an; se aadirn durante los pasos posteriores. Nos referimos a los atributos SuperDn y Dno de EMPLEADO, DniDirector y Fechalngreso-Director de DEPARTAMENTO, y NumDptoProyecto de PROYECTO. En nuestro ejemplo, seleccionamos Dni, NmeroDpto y NumProyecto como claves principales para las relaciones EMPLEADO, DEPARTAMENTO Y tir

i,

7.1 Diseo de una base de datos relacional utilizando el mapeado ER-a-relacional 191

Figura 7.2. Resultado de mapear el esquema ER de EMPRESA dentro de un esquema de base de datos relacional.

EMPLEADO

t t + ~ DEPARTAMENTO I NombreDpto I NmeroDQto I DniDirector FechalngresoDirector I

t + LOCALlZACIONES_DPTO I NmeroDQto I UbicacionDQto I

I PROYECTO

I NombreProyecto I NumProy:ecto I UbicacionProy:ecto I NumDptoProyecto I t I TRABAJA_EN

I DniEmQleado I NumProy: I Horas I I I

SUBORDINADO

I DniEml2leado I NombSubordinado Sexo I FechaNac I Relacin I I

PROYECTO, respectivamente. Recuerde que NombreDpto de DEPARTAMENTO y NombreProyecto de PRO-YECTO son claves secundarias, pues es posible que las utilicemos ms tarde en el diseo. Las relaciones que se crean a partir del mapeado de tipos de entidad se conocen a veces como relaciones de entidad porque cada tupla representa una instancia de entidad. En la Figura 7.3(a) se muestra el resultado tras este paso del mapeado.

Paso 2: Mapeado de los tipos de entidad dbiles. Por cada tipo de entidad dbil W del esquema ER con el tipo de entidad propietario E, cree una relacin R e incluya todos los atributos simples (o componen-tes simples de los atributos compuestos) de W como atributos de R. Adems, incluya como atributos de la foreign key de R, el(los) atributo(s) de la o las relaciones que correspondan al o los tipos de entidad propieta-rios; esto se encarga de identificar el tipo de relacin de W. La clave principal de R es la combinacin de la(s) clave( s) principal( es) del o de los propietarios y la clave parcial del tipo de entidad dbil W, si la hubiera. Si hay un tipo de entidad dbil E2 cuyo propietario tambin es un tipo de entidad dbil El' entonces El debe asignarse antes que E2 para determinar primero su clave principal. En nuestro ejemplo, creamos la relacin SUBORDINADO en este paso como correspondencia con el tipo de entidad SUBORDINADO (vase la Figura 7.3[b]). Incluimos la clave principal Dni de la relacin EMPLEADO (que corresponde al tipo de entidad propietario) como un atributoforeign key de SUBORDINADO; lo renom-bramos como DniEmpleado, aunque no es necesario. La clave principal de la relacin SUBORDINADO es la combinacin {DniEmpleado, NombreSubordinado} porque NombreSubordinado (tambin renombrado a par-tir de Nombre en la Figura 7.1) es la clave parcial de SUBORDINADO.

192 Captulo 7 Diseo de bases de datos relacionales por mapeado ER- y EER-a-relacional

Figura 7.3. Ilustracin de algunos pasos del mapeado. (a) Relaciones de entidad despus del paso 1. (b) Relacin de entidad dbil adicional despus del paso 2. (c) Relacin de relacin despus del paso 5. (d) Relacin que representa el atributo multivalor despus del paso 6. (a) EMPLEADO

DEPARTAMENTO

I NombreDpto NmeroDpto PROYECTO

NombreProyecto NumProyecto UbicacinProyecto

(b) SUBORDINADO DniEmpleado NombSubordinado FechaNac Relacin

(e) TRABAJA_EN I DniEmpleado NumProy Horas

(d) LOCALlZACIONES_DPTO I Nmeroppto I UbicacinDpto

Es normal elegir la opcin de propagacin (CASCADA) para la accin de activacin referencial (consulte la Seccin 8.2) en laforeign key en la relacin correspondiente al tipo de entidad dbil, pues la existencia de una entidad dbil depende de su entidad propietaria. Esto se puede utilizar tanto para ON UPDATE como para ON DELETE.

Paso 3: Mapeado de los tipos de relacin 1:1 binaria. Por cada tipo de relacin 1:1 binaria R del esquema ER, identifique las relaciones S y T que corresponden a los tipos de entidad que participan en R. Hay tres metodologas posibles: (1) la metodologa de laforeign key, (2) la metodologa de la relacin mezclada y (3) la metodologa de referencia cruzada o relacin de relacin. La primera metodologa es la ms til y la que debe seguirse salvo que se den cielias condiciones especiales, como las que explicamos a continuacin:

1. Metodologa de la foreign key. Seleccione una de las relaciones (por ejemplo, S) e incluya como foreign key en S la clave principal de T. Lo mejor es elegir un tipo de entidad con participacin total en R en el papel de S. Incluya todos los tributos simples (o los componentes simples de los atributos compuestos) del tipo de relacin 1: 1 R como atributos de S. En nuestro ejemplo, mapeamos el tipo de relacin 1: 1 ADMINISTRA de la Figura 7.1 eligiendo el tipo de entidad participante DEPARTAMENTO para que desempee el papel de S porque su participacin en el tipo de relacin ADMINISTRA es total (cada departamento tiene un director). Incluimos la clave principal de la relacin EMPLEADO como foreign key en la relacin DEPARTAMENTO y la renombra-mos como DniDirector. Tambin incluimos el atributo simple Fechalnicio del tipo de relacin ADMI-NISTRA en la relacin DEPARTAMENTO y lo renombramos como FechalngresoDirector (vase la Figura 7.2). Es posible incluir, en lugar de esto, la clave principal de S como unaforeign key en T. En nuestro ejem-plo, esto equivale a tener un atributo deforeign key, digamos DepartamentoAdministrado en la relacin EMPLEADO, pero tendr un valor NULL para las tuplas empleado que no dirijan un departamento. Si

1. 5.

la na

N

el y y la

o

s

o

n

'e

1-a

n

7.1 Diseo de una base de datos relacional utilizando el mapeado ER-a-relacional 193

slo ellO por ciento de los empleados administra un departamento, entonces en este caso el 90 por ciento de las foreign keys seran NULL. Otra posibilidad es recurrir a la redundancia al tener foreign keys en las relaciones S y T, pero esto malogra el mantenimiento de la coherencia.

2. Metodologa de la relacin mezclada. Una asignacin alternativa de un tipo de relacin 1: 1 es posi-ble al mezclar los dos tipos de entidad y la relacin en una sola relacin. Esto puede ser apropiado cuando las dos participaciones son totales.

3. Metodologa de referencia cruzada o relacin de relacin. La tercera opcin consiste en configurar una tercera relacin R con el propsito de crear una referencia cruzada de las claves principales de las relaciones S y T que representan los tipos de entidad. Como veremos, esta metodologa es necesaria para las relaciones M:N binarias. La relacin R se denomina relacin de relacin (y, en algunas oca-siones, tabla de bsqueda), porque cada tupla de R representa una instancia de relacin que relacio-na una tupla de S con otra de T.

Paso 4: Mapeado de tipos de relaciones 1:N binarias. Por cada relacin l:N binaria regular R, iden-tifique la relacin S que representa el tipo de entidad participante en el lado N del tipo de relacin. Incluya comoforeign key en S la clave principal de la relacin T que representa el otro tipo de entidad participante en R; hacemos esto porque cada instancia de entidad en el lado N est relacionada, a lo sumo, con una instancia de entidad del lado 1 del tipo de relacin. Incluya cualesquiera atributos simples (o componentes simples de los atributos compuestos) del tipo de relacin l:N como atributos de S. En nuestro ejemplo, vamos a asignar ahora los tipos de relacin l:N TRABAJA_PARA, CONTROLA Y CON-TROL de la Figura 7.1. Para TRABAJA_PARA incluimos la clave principal NmeroDpto de la relacin DEPAR-TAMENTO comoforeign key en la relacin EMPLEADO y la denominamos Ono. En CONTROL, incluimos la clave principal de la relacin EMPLEADO comoforeign key en la propia relacin EMPLEADO (porque la rela-cin es recursiva) y la denominamos SuperDni. La relacin CONTROLA est asignada al atributo de foreign key NumDptoProyecto de PROYECTO, que hace referencia a la clave principal NmeroDpto de la relacin DEPARTAMENTO. Estasforeign keys se muestran en la Figura 7.2. De nuevo, una metodologa alternativa es la opcin de relacin de relacin (referencia cruzada), como en el caso de las relaciones 1: 1 binarias. Creamos una relacin R separada cuyos atributos son las claves de S y T, Y cuya clave principal es la misma que la clave de S. Esta opcin puede utilizarse si pocas tuplas de S parti-cipan en la relacin para evitar excesivos valores NULL en laforeign key. Paso 5: Mapeado de tipos de relaciones M:N binarias. Por cada tipo de relacin M:N binaria R, cree una nueva relacin S para representar a R. Incluya como atributos de laforeign key en S las claves principa-les de las relaciones que representan los tipos de entidad participantes; su combinacin formar la clave prin-cipal de S. Incluya tambin cualesquiera atributos simples del tipo de relacin M:N (o los componentes sim-ples de los atributos compuestos) como atributos de S. No podemos representar un tipo de relacin M:N con un atributo de foreign key en una de las relaciones participantes (como hicimos para los tipos de relacin 1: 1 o 1 :N) debido a la razn de cardinalidad M:N; debemos crear una relacin de relacin S separada. En nuestro ejemplo, mapeamos el tipo de relacin M:N TRABAJA_EN de la Figura 7.1 creando la relacin TRABAJA_EN de la Figura 7.2. Incluimos las claves principales de las relaciones PROYECTO y EMPLEADO como foreign keys en TRABAJA_EN y las renombramos como NumProy y DniEmpleado, respectivamente. Tambin incluimos un atributo Horas en TRABAJA_EN para representar el atributo Horas del tipo de relacin. La clave principal de la relacin TRABAJA_EN es la combinacin de los atributos de la foreign key {DniEmpleado, NumProy}. Esta relacin de relacin se muestra en la Figura 7 .3( c). La opcin (CASCADA) de propagacin para la accin de activacin referencial (consulte la Seccin 8.2) debe especificarse en las foreign keys de la relacin correspondiente a la relacin R, puesto que la existencia de cada instancia de relacin depende de cada una de las entidades que relaciona. Esto se puede utilizar tanto para ON UPDATE como para ON DELETE.

194 Captulo 7 Diseo de bases de datos relacionales por mapeado ER- y EER-a-relacional

Siempre podemos asignar las relaciones 1: 1 o 1:N de un modo similar a las relaciones M:N utilizando la meto-dologa de la referencia cruzada (relacin de relacin), como explicamos anteriormente. Esta alternativa es particularmente til cuando existen pocas instancias de relacin, a fin de evitar valores NULL en las foreigl1 keys. En este caso, la clave principal de la relacin de relacin slo ser una de lasforeign keys que hace refe-rencia a l~s relaciones de entidad participantes. Para una relacin 1:N, la clave principal de la relacin de rela-cin ser laforeign key que hace referencia a la relacin de la entidad en el lado N. En una relacin 1:1, cada foreign key se puede utilizar como la clave principal de la relacin de relacin, siempre y cuando no haya entradas NULL en la relacin.

Paso 6: Mapeado de atributos multivalor. Por cada atributo multivalor A, cree una nueva relacin R. Esta relacin incluir un atributo correspondiente a A, ms el atributo clave principal K (como foreign key en R) de la relacin que representa el tipo de entidad o tipo de relacin que tiene A como un atributo. La clave principal de R es la combinacin de A y K. Si el atributo multivalor es compuesto, incluimos sus componen-tes simples. En nuestro ejemplo, creamos una relacin LOCALlZACIONES_DPTO (vase la Figura 7.3[dJ). El atributo UbicacinDpto representa el atributo multivalor UBICACIONES de DEPARTAMENTO, mientras que NmeroDpto (comoforeign key) representa la clave principal de la relacin DEPARTAMENTO. La clave prin-cipal de LOCALlZACIONES_DPTO es la combinacin de {NmeroDpto, UbicacionDpto}. En LOCALlZACIO-NES_DPTO existir una tupla separada para cada ubicacin que tenga un departamento. La opcin (CASCADA) de propagacin para la accin de activacin referencial (consulte la Seccin 8.2) debe especificarse en laforeign key en la relacin R correspondiente al atributo multivalor para ON UPDATE y ON DELETE. La clave de R, cuando se mapea un atributo compuesto multivalor, requiere cierto anlisis del sig-nificado de los atributos simples. En algunos casos, cuando un atributo multivalor es compueto, slo son nece-sarios algunos de los atributos simples para que formen parte de la clave de R; estos atributos son parecidos a una clave parcial de un tipo de entidad dbil que corresponda al atributo multivalor (consulte la Seccin 3.5). La Figura 7.2 muestra el esquema de la base de datos relacional EMPRESA obtenido con los pasos 1 a 6, y la Figura 5.6 muestra un ejemplo del estado de la base de datos. Todava no hemos explicado el mapeado de los tipos de relacin n-ary (n > 2) porque en la Figura 7.1 no existe ninguno; se asignan de una forma parecida a los tipos de relacin M:N aadiendo el siguiente paso (adicional) al algoritmo de asignacin. Paso 7: Mapeado de los tipos de relacin n-ary. Por cada tipo de relacin n-ary R, donde n > 2, cree una nueva relacin S para representar R. Incluya como atributos de laforeign key en S las claves principales de las relaciones que representan los tipos de entidad participantes. Incluya tambin cualesquiera atributos simples del tipo de relacin n-my (o los componentes simples de los atributos compuestos) como atributos de S. Normalmente, la clave principal de S es una combinacin de todas lasforeign keys que hacen referencia a las relaciones que representan los tipos de entidad participantes. No obstante, si las restricciones de cardina-lidad en cualquiera de los tipos de entidad E que participan en Res 1, entonces la clave principal de S no debe incluir el atributo de la foreign key que hace referencia a la relacin E' correspondiente a E (consulte la Seccin 3.9.2). Por ejemplo, considere el tipo de relacin SUMINISTRO de la Figura 3.17: se puede asignar a la relacin SUMINISTRO de la Figura 7.4, cuya clave principal es la combinacin de las tres foreign keys {Nombre-Proveedor, NumeroRep, NombreProyecto}.

7.1.2 Explicacin y resumen del mapeado para las construcciones del modelo ER

La Tabla 7.1 resume las correspondencias entre las construcciones y las restricciones de los modelos ER y relacional.

y

7.1 Diseo de una base de datos relacional utilizando el mapeado ER-a-relacional 195

Figura 7.4. Asignacin del tipo de relacin n-ary SUMINISTRO de la Figura 3.17(a). PROVEEDOR

NombreProveedor

PROYECTO

NombreProyecto l. . .. I REPUESTO

NumeroRep

SUMINISTRO

NombreProveedor NumeroRep Cantidad

Uno de los puntos principales del esquema relacional, en contraste con un esquema ER, es que los tipos de relacin no estn explcitamente representados; en su lugar, estn representados con dos atributos A y B, uno como clave principal y otro como foreign key (en el mismo dominio) incluidos en las dos relaciones S y T. Dos tuplas de S y Testn relacionadas cuando tienen el mismo valor para A y B. Al utilizar la operacin EQUI-JOIN (o concatenacin natural si los dos atributos de concatenacin tienen el mismo nombre) sobre S.A y T.B, podemos combinar todas las parejas de tuplas relacionadas de S y T Y materializar la relacin. Cuando se ve implicado un tipo de relacin 1: 1 o l:N binaria, normalmente slo se necesita una operacin de concatena-cin. En el caso de un tipo de relacin M:N binaria, se necesitan dos operaciones de concatenacin, mientras que para los tipos de relacin n-ary, se necesitan n concatenaciones para materializar completamente las ins-tancias de relacin. Por ejemplo, para formar una relacin que incluya el nombre del empleado, el nombre del proyecto y las horas que el empleado trabaja en cada proyecto, tenemos que conectar cada tupla EMPLEADO con las tuplas PROYECTO relacionadas a travs de la relacin TRABAJA_EN de la Figura 7.2. Por tanto, debemos aplicar la operacin EQUIJOIN a las relaciones EMPLEADO y TRABAJA_EN con la condicin de concatenacin Dni

Tabla 7.1. Correspondencia entre los modelos ER y relacional.

Modelo ER Modelo relacional

Tipo de entidad Relacin de entidad

Tipo de relacin 1: l o I:N Foreign key (o relacin de relacin) Tipo de relacin M:N Relacin de relacin y dos foreign keys Tipo de relacin n-ary Relacin de relacin y n foreign keys Atributo simple Atributo

Atributo compuesto Conjunto de atributos simples Atributo multivalor Relacin y foreign key Conjunto de valores Dominio Atributo clave Clave principal (o secundaria)

196 Captulo 7 Diseo de bases de datos relacionales por mapeado ER- y EER-a-relacional

= DniEmpleado, y despus aplicar otra operacin EQUIJOIN a la relacin resultante y a la relacin PROYEC_ TO con la condicin de concatenacin NumProy = NumProyecto. En general, cuando hay que atravesar varias relaciones, hay que especificar numerosas operaciones de concatenacin. El usuario de una base de datos rela-cional siempre debe tener cuidado con los atributos de laforeign keya fin de utilizarlos correctamente al com-binar las tuplas relacionadas de dos o ms relaciones. En ocasiones, esto se considera un inconveniente del modelo de datos relacional, porque las correspondencias foreign key/clave principal no siempre resultan obvias al inspeccionar los esquemas relacionales. Si se lleva a cabo una EQUIJOIN entre los atributos de dos relaciones que no representan una relacinforeign key/clave principal, el resultado a menudo puede carecer de sentido y conducir a datos falsos. Por ejemplo, el lector puede intentar concatenar las relaciones PROYEC-TO Y LOCALlZACIONES_DPTO con la condicin UbicacionDpto = UbicacionProyecto y examinar el resulta-do (consulte el Captulo 10). En el esquema relacional creamos una relacin separada por cada atributo multivalor. Para una entidad en par-ticular con un conjunto de valores para el atributo multivalor, el valor del atributo clave de la entidad se repi-te una vez por cada valor del atributo multivalor en una tupla separada, porque el modelo relacional bsico no permite valores mltiples (una lista, o un conjunto de valores) para un atributo en una sola tupla. Por ejem-plo, como el departamento 5 tiene tres ubicaciones, hay tres tuplas en la relacin LOCALlZACIONES_DPTO de la Figura 5.6; cada tupla especifica una de las ubicaciones. En nuestro ejemplo, aplicamos EQUIJOIN a LOCALlZACIONES_DPTO y DEPARTAMENTO en el atributo NmeroDpto para obtener los valores de todas las ubicaciones junto con otros atributos DEPARTAMENTO. En la relacin resultante, los valores de los otros atributos DEPARTAMENTO estn repetidos en tuplas separadas por cada una de las ubicaciones que tiene un depatiamento. El lgebra relacional bsica no tiene una operacin ANIDAR (NEST) o COMPRIMIR (COMPRESS) que pudie-ra producir un conjunto de tuplas de la forma {, , } a paliir de la relacin LOCALlZACIONES_DPTO de la Figura 5.6. Esto es un serio inconvenien-te de la versin normalizada o plana del modelo relacional. En este sentido, el modelo orientado a objetos y los modelos de herencia jerrquica y de red ofrecen ms posibilidades que el modelo relacional. El modelo relacional anidado y los sistemas de objetos relacionales (consulte el Captulo 22) intentan remediar esto.

7.2 Mapeado de construcciones del modelo EER a las relaciones

A continuacin explicamos el mapeado de las construcciones del modelo EER a las relaciones, extendiendo el algoritmo de asignacin ER-a-relacional que presentamos en la Seccin 7.1.1.

7.2.1 Mapeado de la especializacin o generalizacin Ha varias opciones para mapear una cierta cantidad de subclases que juntas forman una especializacin (o, alternativamente, que estn generalizadas en una subclase), como las subclases {SECRETARIA, TCNICO, INGENIERO} de EMPLEADO de la Figura 4.4. Podemos aadir un paso ms a nuestro algoritmo de mapea-do ER-a-relacional de la Seccin 7.1.1, que tiene siete pasos, para manipular el mapeado de la especializa-cin. El paso 8, que se detalla a continuacin, ofrece las opciones ms comunes; tambin son posibles otros mapeados. Explicamos las condiciones bajo las que debe utilizarse cada opcin. Utilizamos Atrs(R) para denotar los atributos de la relacin R, y CPr(R) para referirnos a la clave principal de R. En primer lugar, des-cribimos formalmente el mapeado, y despus lo ilustramos con unos ejemplos. Paso 8: Opciones para mapear la especializacin o generalizacin. Convierta cada especializa-cin con J11 subclases {SI' S2' ... , Sm} y la superclase (generalizada) e, donde los atributos de e son {k, al' . . . all } Y k es la clave (principal), en esquemas de relacin utilizando alguna de las siguientes opciones:

II1II

II1II

II1II

c-ias la-

c-ta-

ar-

pi-no

m-

O a

as

'os

un

ie-a',

n-, y lo

do

(o,

l' .

7.2 Mapeado de construcciones del modelo EER a las relaciones 197

111 Opcin 8A: Varias relaciones (superclase y subclase). Cree una relacin L para e con los atributos Atrs(L) = {k, al' ... , all } Y la CPr(L) = k. Cree una relacin Li para cada subclase Si' 1 ~ i ~ 111, con los atributos Atrs(Li ) = {k} U {atributos de Si} y CPr(Li) = le Esta opcin funciona para cualquier especializacin (total o parcial, disjunta o solapada).

111 Opcin 8B: Varias relaciones (slo relaciones de subclase). Cree una relacin Li por cada subclase Si' 1 ~ i ~ 111, con los atributos Atrs(L i) = {atributos de Si} U {k, al' ... , all } Y la CPr(Li) = le Esta opcin slo funciona para una especializacin cuyas subclases sean totales (cada entidad de la super-clase debe pertenecer [al menos] a una de las subclases). Si la especializacin es solapada, una enti-dad se puede duplicar en varias relaciones.

111 Opcin 8e: Una sola relacin con un atributo de tipo. Cree una sola relacin L con los atributos Atrs(L) = {k, al' ... ,all } U {atributos de SI} U ... U {atributos de Sm} U {t} y CPr(L) = k. El atri-buto t se denomina atributo de tipo (o discriminatorio) que indica la subclase a la que pertenece cada tupla, si la hay. Esta opcin slo funciona para una especializacin cuyas subclases son disjuntas, y tiene el potencial de generar muchos valores NULL si en las subclases existen muchos atributos espe-cficos.

111 Opcin 8D: Una sola relacin con varios atributos de tipo. Cree un solo esquema de relacin L con los atributos Atrs(L) = {k, al' ... ,all } U {atributos de SI} U ... U {atributos de Sm} U {tI' t2, ... , tm} Y la CPr(L) = le Cada ti' 1 ~ i ~ 111, es un atributo de tipo booleano que indica si una tupla per-tenece a la subclase Si' Esta opcin funciona para la especializacin cuyas subclases sean solapadas (pero tambin funcionar para una especializacin disjunta).

Las opciones 8A y 8B se pueden denominar opciones de relacin mltiple, mientras que las opciones 8C y 8D se pueden denominar opciones de una sola relacin. La opcin 8A crea una relacin L para la supercla-se e y sus atributos, ms una relacin Li por cada subclase Si; cada Li incluye los atributos especficos (o loca-les) de Si' ms la clave principal de la superclase e, que se propaga a Li y se convierte en su clave principal. Tambin se convierte en unaforeign key a la relacin de la superclase. Una operacin EQUIJOIN en la clave principal entre cualquier Li y L produce todos los atributos especficos y heredados de las entidades de Si' Esta opcin se ilustra en la Figura 7.5(a) para el esquema EER de la Figura 4.4. La opcin 8A funciona para cualesquiera restricciones de la especializacin: disjunta o solapada, total o parcial. Observe que la restriccin

7T(L i ) ~ 7T(L) se debe mantener por cada Li' Esto especifica una foreign key de cada Li a L, as como una dependencia de inclusin LJ( < L.k (consulte la Seccin 11.5). En la opcin 8B, la operacin EQUIJOIN se crea sobre el esquema y se elimina la relacin L, como se ilustra en la Figura 7.5(b) para la especializacin EER de la Figura 4.3(b). Esta opcin slo funciona bien cuando se mantienen las dos restricciones (disjunta y total). Si la especializacin no es total, una entidad que no perte-nece a cualquiera de las subclases Si se pierde. Si la especializacin no es disjunta, una entidad que pertene-ce a ms de una subclase tendr sus atributos heredados de la superclase e almacenados redundantemente en ms de una Li' Con la opcin 8B, ninguna relacin mantiene todas las entidades de la superclase e; en con-secuencia, debemos aplicar una operacin de concatenacin externa (OUTER UNION, o FULL OUTER JOIN) a las relaciones Li para recuperar todas las entidades de e. El resultado de la unin externa ser parecido a las relaciones de las opciones 8C y 8D, salvo que desaparecern los campos de tipo. Siempre que busquemos una entidad arbitraria en e, tenemos que buscar todas las 111 relaciones Li' Las opciones 8C y 8D crean una sola relacin para representar la superclase e y todas sus subclases. Una enti-dad que no pertenece a alguna de las subclases tendr valores NULL para los atributos especficos de esas sub-clases. Estas opciones no son recomendables si se definen muchos atributos especficos para las subclases. No obstante, si slo existen unos pocos atributos de subclase, estos mapeados son preferibles a las opciones 8A

198 Captulo 7 Diseo de bases de datos relacionales por mapeado ER- y EER-a-relacional

Figura 7.5. Opciones para el mapeado de la especializacin y la generalizacin. (a) Mapeado del esquema EER de la Figura 4.4 utilizando la opcin 8A. (b) Mapeado del esquema EER de la Figura 4.3(b) utilizando la opcin 8B. (c) Mapeado del esquema EER de la Figura 4.4 utilizando la opcin 8C. (d) Mapeado de la Figura 4.5 utilizando la opcin 80 con los campos de tipo booleano Mflag y Pflag.

(a) EMPLEADO Apellid01 Apellido2 FechaNac Direccin Tipo Trabajo

TCNICO INGENIERO GradoT Tipolng

(b) COCHE IdVehculo Matrcula Precio VelocidadMx NumPasajeros

CAMiN IdVehiculo Matricula Precio NumEjes Tonelaje

(e) EMPLEADO

(d) REPUESTO

y 8B, porque eliminan la necesidad de especificar operaciones EQUIJOIN y OUTER UN ION; por consiguien-te, pueden ofrecer una implementacin ms eficaz. La opcin 8C se utiliza para manipular las subclases disjuntas, incluyendo un solo atributo (o imagen o dis-crimina torio) de tipo t para indicar la subclase a la que pertenece cada tupla; por tanto, el dominio de t podra ser {l, 2, ... , 1I1}. Si la especializacin es parcial, t puede tener valores NULL en las tuplas que no pertene-cen a cualquier subclase. Si la especializacin est definida por atributo, sirve con el propsito de t y ya no se necesita t; en la Figura 7.5(c) se ilustra esta opcin para la especializacin EER de la Figura 4.4. La opcin 8D est diseada para manipular el solapamiento de subclases incluyendo 111 campos de tipo boo-leano, uno por cada subclase. Tambin se puede utilizar para las subclases disjuntas. Cada campo de tipo ti puede tener un dominio {s, no}, donde un valor de "s" indica que la tupla es miembro de la subclase Si' Si utilizamos esta opcin para la especializacin EER de la Figura 4.4, incluiramos tres atributos de tipo (EsSecretaria, Eslngeniero y EsTcnico) en lugar del atributo TipoTrabajo de la Figura 7.5(c). Tambin es posible crear un solo atributo de tipo de 111 bits en lugar de m campos de tipo. Cuando tenemos una jerarqua de especializacin (o generalizacin) multinivel o entramado, no tenemos que seguir la misma opcin de mapeado para todas las especializaciones. En su lugar, podemos utilizar una opcin de mapeado para parte de la jerarqua o entramado y otras opciones para otras partes. La Figura 7.6 muestra un posible mapeado en las relaciones para el entramado EER de la Figura 4.6. Aqu hemos utilizado la opcin 8A para PERSONAl {EMPLEADO, EX_ALUMNO, ESTUDIANTE}, la opcin 8C para EMPLEADO/ {ADMINISTRATIVO, DOCENTE, ADJUNTO}, Y la opcin 8D paraADJUNTO/{ADJUNTO_INVESTIGACIN, ADJUNTO_ENSEANZA}, ESTUDIANTE/ADJUNTO (en ESTUDIANTE), y ESTUDIANTE/{ESTUDIANTE_ DIPLOMADO, ESTUDIANTE_NO_DIPLOMADO}. En la Figura 7.6, todos los atributos cuyos nombres termi-nan con tipo o flag son campos de tipo.

7.2 Mapeado de construcciones del modelo EER a las relaciones 199

Figura 7.6. Mapeado del entramado de especializacin EER de la Figura 4.8 utilizando varias opciones.

PERSONA Nombre FechaNac Direccin

EMPLEADO

GRADOS_ALUMNOS

Dni Ao Grado I Especialidad I t

ESTUDIANTE DptoPrinc NoGrad_flag ProgGrado

7.2.2 Mapeado de subclases compartidas (herencia mltiple) Una subclase compartida, como INGENIERO_JEFE de la Figura 4.7, es una subclase de varias superclases, indicando la herencia mltiple. Estas clases deben tener todas el mismo atributo clave; en caso contrario, la subclase compartida se modelara como una categora. Podemos aplicar cualquiera de las opciones explica-das en el paso 8 para una subclase compartida, sujeta a las restricciones explicadas en el paso 8 del algoritmo de mapeado. En la Figura 7.6 se utilizan las opciones 8C y 8D para la subclase compartida ADJUNTO. La opcin 8C se utiliza en la relacin EMPLEADO (atributo TipoEmpleado) y la opcin 8D para la relacin ESTUDIANTE (atributo Adjunto_flag).

7.2.3 Mapeado de categoras (tipos de unin) Aadimos otros paso al procedimiento de mapeado (paso 9) para manipular las categoras. Una categora (o tipo de unin) es una subclase de la unin de dos o ms superclases que puede tener diferentes claves, porque pueden ser de distintos tipos de entidad. Un ejemplo es la categora PROPIETARIO de la Figura 4.8, que es un subconjunto de la unin de tres tipos de entidad PERSONA, BANCO Y EMPRESA. La otra categora de esta figura, VEHCULO_REGISTRADO, tiene dos superclases que tienen el mismo atributo clave.

Paso 9: Mapeado de tipos de unin (categoras). Para mapear una categora cuyas superclases defi-nitorias tienen claves diferentes, es costumbre especificar un nuevo atributo de clave, denominado clave sus-tituta, al crear una relacin correspondiente a la categora. Las claves de las clases de definicin son diferen-tes, por lo que no podemos utilizar una de ellas exclusivamente para identificar todas las entidades de la cate-gora. En nuestro ejemplo de la Figura 4.8, podemos crear una relacin PROPIETARIO para corresponderse con la categora PROPIETARIO, como se ilustra en la Figura 7.7, e incluir cualquier atributo de la categora en esta relacin. La clave principal de la relacin PROPIETARIO es la clave sustituta, que denominamos IdPropietario. Tambin incluimos el atributo de clave sustituta IdPropietario comoforeign key en cada relacin correspondiente a una superclase de la categora, para especificar la correspondencia en los valores entre la clave sustituta y la clave de cada superclase. Observe que si una entidad PERSONA (o BANCO o EMPRESA) en particular no es miembro de PROPIETARIO, tendra un valor NUll para su atributo Id Propietario en su correspondiente tupla de la relacin PERSONA (o BANCO o EMPRESA), y no tendra una tupla en la rela-cin PROPIETARIO.

200 Captulo 7 Diseo de bases de datos relacionales por mapeado ER- y EER-a-relacional

Figura 7.7. Mapeado de las categoras EER (tipos de unin) de la Figura 4.8 en relaciones. PERSONA

Dni Matrcula Nombre Direccin Id Propietario

BANCO

I NombreB DireccinB Id Propietario EMPRESA

I NombreE DireccinE IdPropietario PROPIETARIO

I IdProgiela[iQ Of VEHCULO_REGISTRADO

Matrcula

IdVehculo EstiloV MarcaV ModeloV

MarcaC ModeloC Tonelaje

PROPIETARIOS

IdPropietarQ FechaCompra GravamenONormal

En el caso de una categora cuyas superclases tengan la misma clave, como VEHCULO en la Figura 4.8, no es necesaria una clave sustituta. El mapeado de la categora VEHCULO_REGISTRADO, que ilustra este caso, tambin se muestra en la Figura 7.7.

7.3 Resumen En la Seccin 7.1 vimos cmo el diseo de un esquema conceptual en el modelo ER se puede mapear en un esquema de base de datos relacional. Hemos ofrecido e ilustrado con ejemplos de la base de datos EMPRE-SA un algoritmo para el mapeado ER-a-relacional. La Tabla 7.1 resume las correspondencias entre los mode-los ER y relacional. A continuacin, en la Seccin 7.2 aadimos algunos pasos al algoritmo para mapear las estructuras del modelo ER al modelo relacional. En las herramientas grficas de diseo de bases de datos se incorporan algoritmos parecidos para crear automticamente un esquema relacional a partir del diseo de un esquema conceptual.

Ejercicios 201

Preguntas de repaso 7.1. Explique las correspondencias entre los modelos ER y relacional. Muestre cmo cada construccin

del modelo ER se puede mapear al modelo relacional y explique los mapeados altemativos. 7.2. Explique las opciones que hay para mapear las construcciones del modelo EER en relaciones.

Ejercicios 7.3. Intente mapear el esquema relacional de la Figura 6.14 a un esquema ER. Esto es parte de un pro-

ceso conocido como ingeniera inversa, donde se crea el esquema conceptual para una base de datos implementada ya existente. Detalle las suposiciones que haga.

7.4. La Figura 7.8 muestra un esquema ER para una base de datos que se puede utilizar para que las autoridades martimas puedan hacer el seguimiento de los buques mercantes y sus ubicaciones. Mapee este esquema a un esquema relacional y especifique todas las claves principales y fOl'eign keys.

7.5. Mapee el esquema ER de BANCO del Ejercicio 3.23 (y mostrado en la Figura 3.21) a un esquema relacional. Especifique todas las claves principales y foreign keys. Reptalo para el esquema de AEROLNEA (vase la Figura 3.20) del Ejercicio 3.19 y para los otros esquemas de los Ejercicios 3.16 a 3.24.

Figura 7.8. Un esquema ER para una base de datos SEGUIMIENTO_BARCOS.

N

PUERTO_ ORIGEN

N

(0,*)

Fecha

Hora

TIPO

(1,1)

N~r1 __________ -L __________ ~ N

POR >-------1 L-______ ---'

202 Captulo 7 Diseo de bases de datos relacionales por mapeado ER- y EER-a-relacional

7.6. Mapee los diagramas EER de las Figuras 4.9 y 4.12 a esquemas relacionales. Justifique sus eleccio-nes.

7.7. Es posible mapear satisfactoriamente un tipo de relacin M:N sin necesidad de una nueva relacin? Por qu, o por qu no?

7.8. Utilizando los atributos que proporcion para el diagrama EER en el Ejercicio 4.27 del Captulo 4, mapee el esquema completo a un conjunto de relaciones. Elija una de las opciones (8A a 8D) de la Seccin 7.2.1 para realizar el mapeado de las generalizaciones y defienda su eleccin.

Ejercicios de prctica 7.9. Considere el diseo ER para la base de datos UNIVERSIDAD que se model utilizando una hena-

mienta como ERWin o Rational Rose en el Ejercicio de prctica 3.31. Con la funcin de genera-cin del esquema SQL de la henamienta de modelado, genere el esquema SQL para una base de datos Oraele.

7.10. Considere el diseo ER para la base de datos PEDIDOS_CORREO que se model utilizando una herramienta como ERWin o Rational Rose en el Ejercicio de prctica 3.32. Con la funcin de gene-racin del esquema SQL de la henamienta de modelado, genere el esquema SQL para una base de datos Oraele.

7.11. Considere el diseo ER para la base de datos AEROLNEA que se model utilizando una henamien-ta como ERWin o Rational Rose en el Ejercicio de prctica 3.34. Con la funcin de generacin del esquema SQL de la henamienta de modelado, genere el esquema SQL para una base de datos Oraele.

7.12. Considere el diseo EER para la base de datos UNIVERSIDAD que se model utilizando una hena-mienta como ERWin o Rational Rose en el Ejercicio de prctica 4.28. Con la funcin de genera-cin del esquema SQL de la herramienta de modelado, genere el esquema SQL para una base de datos Oraele.

7.13. Considere el diseo EER para la base de datos PEQUEO_AEROPUERTO que se model utilizan-do una henamienta como ERWin o Rational Rose en el Ejercicio de prctica 4.29. Con la funcin de generacin del esquema SQL de la herramienta de modelado, genere el esquema SQL para una base de datos Oraele.

Bibliografa seleccionada El algoritmo de mapeado ER-a-relacional se describi en el ensayo elsico de Chen (Chen 1976) que presen-t el modelo ER original. Batini y otros (1992) explica varios algoritmos de mapeado de los modelos ER y EER a modelos heredados, y viceversa.