Modelo Relacional

51
Modelo Relacional

description

Modelo Relacional. E. F. Codd - modelo relacional en1970. Antes: punteros físicos (direcciones de disco) relacionaban registros de distintos archivos. Relacionar registro A con registro B -> añadir a registro A un campo conteniendo la dirección en disco de registro B. - PowerPoint PPT Presentation

Transcript of Modelo Relacional

Page 1: Modelo Relacional

Modelo Relacional

Page 2: Modelo Relacional

E. F. Codd - modelo relacional en1970.

Antes: punteros físicos (direcciones de disco) relacionaban registros de distintos archivos. Relacionar registro A con registro B -> añadir a registro A un campo conteniendo la dirección en disco de registro B. Este campo siempre señalaría desde el registro A al registro B.

Vulnerabilidad: añadir un nuevo disco y mover los datos de una localización física a otra ->conversión de los archivos de datos.

Sistemas basados en modelo de red y modelo jerárquico, primera generación de los SGBD.

Page 3: Modelo Relacional

Modelo relacional: segunda generación de los SGBD.

Datos estructurados a nivel lógico como tablas formadas por filas y columnas.

A nivel físico pueden tener una estructura completamente distinta.

Tablas pueden ser construidas:

•Crear conjunto de tablas iniciales y aplicar ciertas operaciones hasta conseguir el esquema más óptimo. •Convertir diagrama MER a tablas y posteriormente aplicar también estas operaciones hasta conseguir el esquema óptimo.

Page 4: Modelo Relacional

Primera técnica: de las primeras en existir.Segunda, más reciente, mucho más conveniente:

• Partir de un diagrama visual es muy útil para apreciar los detalles (modelo conceptual).

• Crear tablas es mucho más simple a través de las reglas de conversión (MER-Relacional).

• En ambos casos hay que aplicar operaciones a las tablas; al partir del MER éstas son mínimas.

• Aún con normalizacion deficiente, se garantiza un esquema aceptable, no así en la primera técnica.

Modelo relacional ve tres aspectos de los datos: • Estructura de datos. (Aquí estamos)• Integridad de datos. • Manejo de datos.

Page 5: Modelo Relacional
Page 6: Modelo Relacional
Page 7: Modelo Relacional

Cliente Cuentanombre_clien te

ca lle_c lien te

id_clien te

c iudad_clien tetiene

sa ldonúmero_ cuen ta

(1 ,n )(1 ,n )

Page 8: Modelo Relacional

Estructura

La relación es el elemento básico del modelo relacional y se representa por una tabla.

Tablas se representan gráficamente como una estructura rectangular formada por filas y columnas.

Cada columna almacena información sobre una propiedad determinada de la tabla (atributo): nombre, carnet, apellidos, edad,.... Cada fila posee una ocurrencia o ejemplar de la instancia representada por la tabla (tuplas).

Page 9: Modelo Relacional

Relación Tabla

Tupla Fila

Atributo Columna

Numero de tuplas

Cardinalidad

Numero de atributos

Grado

Dominio Colección de valores, de los cuales uno o más atributos obtienen sus valores reales.

Clave primaria Identificador único para la tabla: una columna o combinación de columnas con la propiedad de que nunca existen 2 filas de la tabla con el mismo valor en esa columna o combinación de columnas.

Page 10: Modelo Relacional

título año duración Tipo

Star Wars 1977 124 color

Mighty Ducks 1991 104 color

Wayne's World 1992 95 color

Pelicula

Page 11: Modelo Relacional

Onum Calle Area Población Teléfono Fax

O5 Enmedio, 8 Centro Castellón 964 201 240 964 201 340

O7 Moyano, s/n Centro Castellón 964 215 760 964 215 670

O3 San Miguel, 1 Villarreal 964 520 250 964 520 255

O4 Trafalgar, 23 Grao Castellón 964 284 440 964 284 420

O2 Cedre, 26 Villarreal 964 525 810 964 252 811

Enum Nombre Apellido Dirección Teléfono PuestoFecha_nac

Salario DNI Onum

EL21 Amelia Pastor Magallanes, 15 Castellón

964 284 560

Director 12/10/62 30000 39432212 O5

EG37 Pedro Cubedo Bayarri, 11 Villarreal

964 535 690

Supervisor

24/3/57 18000 38766623 O3

EG14 Luis Collado Borriol, 35 Villarreal

964 522 230

Administ. 9/5/70 12000 24391223 O3

EA9 Rita Renal Casalduch, 32 Castellón

964 257 550

Supervisor

19/5/60 18000 39233190 O7

EG5 Julio Prats Melilla, 23 Villarreal

964 524 590

Director 19/12/50 24000 25644309 O3

EL41 Carlos Baeza Herrero, 51 Castellón

964 247 250

Supervisor

29/2/67 18000 39552133 O5

Oficina

Plantilla

Page 12: Modelo Relacional

Dominio

Cada atributo de una base de datos relacional se define sobre un dominio.Varios atributos pueden estar definidos sobre el mismo dominio. Permiten especificar los posibles valores válidos para uno o varios atributos.

Un dominio D es un conjunto finito de valores homogéneos y atómicos caracterizados por un nombre. Homogéneo significa que los valores son todos del mismo tipo y atómicos significa que son indivisibles.

El dominio "Nacionalidades" tiene valores: España, Francia, Chile, Argentina... Si descompusiéramos España en E,s,p,... perdería la semántica. (indivisible)

Page 13: Modelo Relacional

Ejemplos:

•Colores: Es el conjunto de los colores D={rojo, verde, azul}•Números de DNI: Es conjunto de números del DNI válidos (0-9), formados por ocho dígitos.•Edad: Edades posibles de los empleados entre 18 y 80 años.

Cada domino debe tener un tipo de datos.El tipo de datos del dominio "nacionalidades" es un conjunto de caracteres de longitud 10.

Se considera que los dominios no incluyen nulos, ya que nulo (NULL) no es un valor.

Page 14: Modelo Relacional

Atributo Nombre del

Dominio Descripción Definición

Onum NUM_OFICINA Posibles valores de

número de oficina 3 digitos; rango O1-

O99

Calle NOM_CALLE Nombres de calles de

España 25 caracteres

Area NOM_AREA Nombres de áreas de

las poblaciones de España

20 caracteres

Población NOM_POBLACIO

N

Nombres de las poblaciones de España

15 caracteres

Teléfono NUM_TEL_FAX Números de teléfono

de España 9 digitos

Fax NUM_TEL_FAX Números de teléfono

de España 9 dígitos

Page 15: Modelo Relacional

Tipos de Datos

Cada dominio debe definirse sobre algún tipo de dato:

Entero (Integer) Números enteros sin parte decimal.

Carácter (Char) Caracteres del código ASCII, de 0-255

Boleano (Boolean) Pueden contener los valores de falso o verdadero

Real Números que pueden incluir una parte decimal

Cadena (String)En una secuencia de caracteres que se trata como un solo dato.

Page 16: Modelo Relacional

Cuál utilizar dependerá del problema: qué valores se desea almacenar.Los tipos de datos a utilizar dependerán del SGBD. Otros: Fecha/Hora: para introducir datos en formato fecha u horaMoneda: introducir datos en formato número y con el signo monetario Autonumérico: se numera automáticamente el contenido

Tipo Rango de valores

que acepta 

Integer  (Entero) -32,768 a 32,767 

Word     (Palabra) 0 a 65535 

ShortInt  (Entero corto)

-128 a 127 

Byte  0 a 255 

LongInt  (Entero largo)

-2,147,483,648 a 2,147,483,648 

Tipo Rango de valores que

acepta 

Real 2.9E-39 a 1.7E38

Single  1.5E-45 a 3.4E38

Double  5.0E-324 a 1.7E308

Extended  1.9E-4851 a 1.1E4932

Comp  -9.2E18 a 9.2E18

Enteros Reales

Page 17: Modelo Relacional

Nulos (NULL)

Un nulo no representa el valor cero ni la cadena vacía.El nulo implica ausencia de información.

Necesidad de valores nulos cuando:•Tuplas con atributos desconocidos en ese momento.•Añadir un nuevo atributo a una tabla ya existente; atributo que en el momento de introducirse no tendrá ningún valor para las tuplas de la relación.•Posibilidad de atributos inaplicables a ciertas tuplas, como la editorial para un artículo.

En claves foráneas indican que el registro actual no está relacionado con ninguna tabla.

Page 18: Modelo Relacional

Atributo

Un atributo A es el papel que tiene un determinado dominio en una relación. D es el dominio de A y se denota dom(A).

Es muy usual dar mismo nombre al atributo y al dominio. Si varios atributos de una misma tabla están definidos sobre el mismo dominio, hay que darles nombres distintos:una tabla no puede tener dos atributos con el mismo nombre.

Atributos edad_física y edad_mental pueden estar definidos sobre el mismo dominio edad; atributos precio_compra y precio_venta pueden estar definidos sobre el mismo dominio precio, enteros de longitud 5 mayores que 0.

Page 19: Modelo Relacional

Relación

Una relación se compone de una cabecera y un cuerpo.Cabecera: formada por un conjunto de atributos, cada uno corresponde a un único dominio.No hay dos atributos que se llamen igual.

Cuerpo: formado por un conjunto de tuplas que varía en el tiempo; conjunto de pares atributo:valor.Cantidad de atributos: grado Cantidad de tuplas: cardinalidad.

•Cabecera de relación OFICINA:•{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA), (Población:NOM_POBLACION),(Teléfono:NUM_TEL_FAX), Fax:NUM_TEL_FAX)}.

•Una tupla: •{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro), (Población:Castellón), (Teléfono:964 201 240), (Fax:964 201 340)}.

Page 20: Modelo Relacional

Claves

•Clave candidata: conjunto no vacío de atributos que identifican univoca y mínimamente a una tupla. Toda relación siempre tendrá una.•Clave primaria: clave candidata escogida para identificar a las tuplas de una relación.•Clave alternativa: claves candidatas no elegidas como primarias.•Clave ajena o foránea de una relación R2: conjunto no vacío de atributos cuyos valores han de coincidir con los valores de la clave primaria de otra relación R1. Clave foránea y clave primaria han de estar definidas sobre los mismos dominios.

Ningún componente de la clave primaria puede en algún momento no tener valor (aceptar nulos).

Page 21: Modelo Relacional

Transformación MER-Relacional

Se transformará el esquema conceptual (MER) a un esquema relacional.

Este esquema sigue siendo independiente de SGBD.

El paso del esquema MER al relacional se basa en los siguientes principios:

Page 22: Modelo Relacional

1. Todo tipo de entidad se convierte en relación.

Cada entidad del MER da lugar a una nueva relación. •Identificador principal: atributo(s) que forman la clave primaria de la nueva relación. Se subrayan.Cada atributo de una entidad se transforma en un atributo de esta relación. Tomar en cuenta:•Atributos obligatorios: atributos que deben contar con un valor en la tabla, no debe aceptar valores nulos. (restricción NOT NULL.)•Atributos opcionales: atributos que pueden tomar valores nulos (no se conoce el valor, etc, NULL)•Identificador alternativo: atributo alternativo en la entidad que debe ser único en la relación (restricción UNIQUE).•Atributos monovaluados: dan lugar a un atributo de la relación.

Page 23: Modelo Relacional

Cliente (id_cliente, nombre_cliente, calle_cliente, ciudad_cliente) PK: id_cliente

(PK: primary key->clave primaria)

Clienteno mbre _ clien te

ca lle _clien te

id_ clien te

c iud ad _ clien te

Page 24: Modelo Relacional

•Atributos multivaluados: dan lugar a una nueva relación cuya clave primaria es la concatenación de la clave primaria de la entidad en la que está el atributo multivaluado mas el nombre del atributo multivaluado.

Cliente (id_cliente, nombre_cliente, direccion_cliente) PK: id_cliente

Teléfonos_cliente (id_cliente, telefono_cliente) PK: id_cliente, telefono_cliente; FK: id_cliente referencia a Cliente.

FK: foreign key->clave foranea)

Cliente

id_c lientenombre_c liente

direc c ion_c lientetelefono_c liente

Page 25: Modelo Relacional

•Atributos compuestos: se pueden transformar según las siguientes alternativas:•Eliminar el atributo compuesto considerando todos sus componentes como atributos individuales.

Cliente (id_cliente, nombre_cliente, calle, numero, ciudad, telefono_cliente) PK: id_cliente

•Eliminar los componentes individuales y considerar el atributo compuesto entero como un sólo atributo. Cliente (id_cliente, nombre_cliente, direccion_cliente, telefono_cliente) PK: id_cliente

Cliente

id_c lientenombre_c liente

direc c ion_c lientetelefono_c liente

c alle

numero

c iudad

Page 26: Modelo Relacional

Atributos derivados: atributos que se obtienen como resultado de un calculo sobre otros atributos. No existe para los atributos derivados una representación directa y concreta en el modelo relacional y sus SGBD. En este caso, los atributos se tratan de la forma usual.

Se calcula el valor del atributo derivado cada vez que se inserten o borren las ocurrencias de los atributos que intervienen en el cálculo de este. Para esto se implementan los procedimientos del caso y se añaden las restricciones correspondientes.

Page 27: Modelo Relacional

Atributos de Interrelaciones

Si la interrelación se transforma en una relación, todos sus atributos pasan a ser columnas de la relación.

En caso de que la relación se transforme mediante propagación de clave, sus atributos migran junto con la clave a la relación que corresponda

Page 28: Modelo Relacional

Dependencia por identidad.

Una interrelación 1:N de dependencia en identificación da lugar a una propagación de clave desde la entidad fuerte a la entidad débil. La entidad débil requiere de la clave de la entidad fuerte para su identificación. La clave queda formada por la concatenación de la clave foránea y la clave de la entidad débil.

Libro (codigo, nombre, nr_hojas, editorial) PK: codigoEjemplar (codigo, numero, estado, posición) PK: codigo, numero FK: codigo referencia a Libro.

ti eneL ib ro E je m pla r(1 , N)( 1 ,1 )

Có d igoNo mb re

Nr_ h oja sE dito ria l

Núm er oE st adoP os ic ió n

E je m p la rI

Page 29: Modelo Relacional

2.Todo tipo de interrelación N:M se transforma en relación.

Las interrelaciones N:M dan lugar a una nueva relación cuya clave serán las claves primarias de las entidades que enlaza la interrelación.

Los atributos que forman la clave primaria de esta nueva relación son claves foráneas respecto a las tablas en donde son claves primarias.

Page 30: Modelo Relacional

Cliente (id_cliente, nombre_cliente, calle_cliente, ciudad_cliente) PK: id_clienteCuenta (numero_cuenta, saldo) PK: numero_cuentaTiene (id_cliente, numero_cuenta) PK. Id_cliente, numero_cuenta FK: id_cliente referencia a Cliente, numero_cuenta referencia a Cuenta.

Cliente Cuentan o mb re _ clie n te

ca lle _ c lie n te

id _ c lie n te

c iu d a d _ clie n tetie n e

sa ld on ú me ro _ cu e n ta

(1 ,n )(1 ,n )

Page 31: Modelo Relacional

Cliente (id_cliente, nombre_cliente, calle_cliente, ciudad_cliente) PK: id_clienteCuenta (numero_cuenta, saldo) PK: numero_cuentaTiene (id_cliente, numero_cuenta, privilegio) PK. Id_cliente, numero_cuenta FK: id_cliente referencia a Cliente, numero_cuenta referencia a Cuenta.

Cliente Cuentan o mb re _ clie n te

ca lle _ c lie n te

id _ c lie n te

c iu d a d _ clie n tetie n e

sa ld on ú me ro _ cu e n ta

(1 ,n )(1 ,n )

p r iv ile g io

Page 32: Modelo Relacional

3.Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de la clave.

Se propaga la clave primaria de la entidad que se encuentra en el lado 1 a la entidad que se encuentra en el lado N.

Region (numero_region, nombre_region, habitantes_region) PK: numero_regionCiudad (nombre_ciudad, habitantes_ciudad, numero_region) PK: nombre_ciudad, FK: numero_region referencia a Region.

Ciudad Regionesta(1,n) (1,1)nombre_c iudad

habitantes_c iudad

numero_regionnombre_region

habitantes_region

Page 33: Modelo Relacional

Proveedor (codigo, nombre, direccion) PK: codigoVendedor (codigo, nombre, precio_unitario, codigo_prov, fecha) PK: codigo, FK: codigo_prov referencia a Proveedor

Un aspecto importante en estas interrelaciones tiene que ver con las cardinalidades mínimas. Si la cardinalidad mínima de la entidad que se propaga es 1, significa que no pueden admitirse valores nulos en la clave foránea (clave propagada). En cambio, si es 0, si se admiten valores nulos.

Proveedor Produc tos umin is tran o mb recó d ig o

p re c io _ u n ita r io(1 ,1 ) (1 ,n )

n o mb recó d ig o

d ire cc io n

fec ha

Page 34: Modelo Relacional

•Si en la parte de cardinalidad minima hay una participación parcial:

Vendedor (nombre_vendedor, fono_vendedor) PK: nombre_vendedorPedido (numero_pedido, fecha, tasa_descuento, nombre_vendedor) PK: numero_pedido, FK: nombre_vendedor referencia a Vendedor

En este caso puede ocurrir que tasa_descuento y nombre_vendedor tomen valores nulos.

Pedido Vendedors umin is tra

nombre _vendedo r(1 ,n ) (0 ,1 )

fechanumero _ped ido

tasa_desc uento

fono

Page 35: Modelo Relacional

•Si el número relativo de esos pedidos es grande, y no se puede admitir valores nulos, una mejor alternativa:

Se crea una nueva relación para la interrelación cuyo tratamiento seria igual que el de las interrelaciones N:M con la salvedad de que la clave primaria de la nueva relación constara de la clave primaria de la entidad que se encuentra en el lado N de la interrelación. Vendedor (nombre_vendedor, fono_vendedor) PK: nombre_vendedorPedido (numero_pedido, fecha) PK: numero_pedidoPedido_Ventas (numero_pedido, nombre_vendedor, tasa_descuento) PK: numero_pedido, FK: numero_pedido referencia a Pedido, nombre_vendedor referencia a Vendedor

Pedido Vendedors umin is tra

nombre_vendedo r(1 ,n ) (0 ,1 )

fechanumero_ped ido

tasa_desc uento

fono

Page 36: Modelo Relacional

•Si en la parte de cardinalidad maxima hay una participación parcial se necesitan tres tablas:

Auto (patente_auto, marca_auto) PK: patente_autoPersona (CI_persona, nombre_persona, direccion_persona) PK CI_personaAuto_persona (CI_persona, patente_auto) PK: patente_auto, CI_persona, FK: patente_auto referencia a Auto, CI_persona referencia a Persona

Se podría propagar también la clave de la entidad que tiene la cardinalidad minima a la que tiene máximo N:Auto (patente_auto, marca_auto, CI_persona) PK: patente_auto, FK CI_persona referencia a PersonaPersona (CI_persona, nombre_persona, direccion_persona) PK CI_persona

Auto Personaes_prop(0,n) (1,1)patente_auto

marc a_auto

C I_personanombre_persona

direc c ion_persona

Page 37: Modelo Relacional

•Interrelaciones 1:1•Si la relación es del tipo 1:1 y es obligatorio (total), cada entidad se transforma en una tabla con clave principal el identificador de la entidad correspondiente y cada tabla tendrá como clave ajena el identificador de la otra tabla con la cual está relacionada.

Empresa (codigo_empresa, direccion_empresa, CI_director) PK codigo_empresa, FK CI_director referencia a DirectorDirector (CI_director, nombre, codigo_empresa) PK CI_director, FK codigo_empresa referencia a Empresa

Empresa D irec tortiene

C I_ d irecto r(1 ,1 ) (1 ,1 )

d irecc ion _ empresacod igo _ empresa nombre

Page 38: Modelo Relacional

•Una de las entidades tiene cardinalidad (0,1) y la otra (1,1), conviene propagar la clave de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1). Esta clave foránea no debe aceptar valores nulos.

Empleado (codigo_empleado, nombre_empleado) PK: codigo_empleadoDepto (codigo_depto, nombre_depto, codigo_empleado) PK: codigo_depto, FK: codigo_empleado referencia a Empleado.

Empleado Deptore sp o n sa b le

co d ig o _ d e p to(1 ,1 ) (0 ,1 )

n o mb re _ e mp le a d oco d ig o _ e mp le a d o nombre_depto

Page 39: Modelo Relacional

•Si las entidades que se asocian tienen ambas cardinalidades (0,1) se generan tres tablas, una para cada entidad y otra para la relación que deberá contener como atributos las claves primarias de las entidades que participan en la relación.Se evitan los valores nulos que aparecerian en caso de propagar una de las claves primarias.

Persona (codigo_persona, nombre_persona) PK: codigo_personaAnimal (codigo_animal, nombre_animal) PK: codigo_animalPersona_Animal (codigo_persona, codigo_animal, fecha) PK: codigo_persona, codigo_animal FK: codigo_persona referencia a Persona, codigo_animal referencia a Animal.

Persona Animalp o se e

co d ig o _ a n ima l(0 ,1 ) (0 ,1 )

n o mb re _ p e rso n aC I_ p e rso n a n o mb re _ a n ima l

fe ch a

Page 40: Modelo Relacional

•Relaciones reflexivasPara transformarlas se debe suponer que se trata de una relación binaria con la particularidad que las dos entidades son iguales y aplicar las reglas vistas.

Persona (CI_persona, nombre_persona, CI_o_persona) PK: CI_persona FK: CI_o_persona referencia a Persona

La clave foránea no puede aceptar nulos (todas las personas tienen un padrino). Todas las personas de la base son padrinos de al menos una persona.

Persona

(1 ,n )

nombre _ pe rsonaC I_pe rsona

apad rina

(1 ,1 )

Page 41: Modelo Relacional

• El siguiente caso es igual que el anterior, con la diferencia que la clave foránea si puede aceptar nulos (una persona puede o no tener padrino).

Persona

(1 ,n )

n o mb re _ p e rso n aC I_ p e rso n a

a p a d r in a

(0 ,1 )

Page 42: Modelo Relacional

• Los mismos esquemas se darán para los siguientes casos. Aquí la diferencia es que una persona de la base puede no aparecer como padrino de alguien (0,n). (No todas las personas de la base son padrinos)

Persona

(0 ,n )

nombre _ pe rsonaC I_pe rsona

apad rina

(1 ,1 )

Page 43: Modelo Relacional

• En el siguiente caso una persona de la base puede no aparecer como padrino y una persona puede no tener padrino, por lo que debe aceptar valor nulo en la clave foránea.

Persona

(0 ,n )

n omb re _ p e rso n aC I_ pe rso n a

a pa d rin a

(0 ,1 )

Page 44: Modelo Relacional

•Casos N:M

Se tendria una tabla por entidad persona, y una tabla representando la relación “apadrina”:

Persona (CI_persona, nombre_persona) PK: CI_persona

Apadrina (CI_persona, CI_o_persona) PK: CI_persona, CI_o_persona FK: CI:persona, CI_o_persona referencia a Persona

Page 45: Modelo Relacional

Generalizaciones

Las generalizaciones no son objetos que puedan representarse directamente en el modelo relacional.

Ante una entidad y sus subtipos caben varias soluciones de transformación, con la consiguiente pérdida de semántica dependiendo de la estrategia elegida, las cuales son 3:

Page 46: Modelo Relacional

Integrar la jerarquía de generalización en una sola entidad uniendo los atributos de las subentidades y añadiendo estos atributos a los de la superentidad. Se añade un atributo discriminativo para indicar el caso al cual pertenece la entidad en consideración. Es aplicable a todos los casos, con todas las coberturas.El problema es tener que manejar en algunos casos demasiados valores nulos.Las operaciones que sólo actuaban sobre una subentidad tendrán que buscar ahora los casos correspondientes dentro del conjunto completo de casos.

Page 47: Modelo Relacional

Estudiante (matricula_estudiante, nombre_estudiante, carrera, titulo_tesis, tipo) PK: matricula_estudiante

matric ula_estudiantenombre_estudiante

titulo_tesisc arrera

Page 48: Modelo Relacional

Eliminar la superentidad reteniendo las subentidades.Aquí los atributos heredados deben propagarse entre las subentidades. No es práctica para generalizaciones superpuestas o parciales; sólo lo es para jerarquías totales y exclusivas. Si el número de atributos de la superentidad (comunes a toda las subentidades) es excesivo, su duplicación en el esquema de cada subentidad no se justifica.

Page 49: Modelo Relacional

Ingeniero (rut_empleado, nombre_empleado, especialidad) PK: rut_empleado

Gerente (rut_empleado, nombre_empleado, nr_supervisados) PK: rut_empleado

rut_empleadonombre_empleado

nr_supervisadosespec ialidad

Page 50: Modelo Relacional

Retener todas las entidades y establecer explícitamente las interrelaciones entre la superentidad y las subentidades. Esta alternativa se puede considerar como la más general de las tres, ya que siempre es posible. Las desventajas de este enfoque son que el esquema resultante es bastante complejo y hay una redundancia inherente al representar cada eslabón ES-UN en la jerarquía original a través de una relación explícita. Las ventajas, por otra parte, son que modela todos los casos, lo que la hace más flexible ante cambios de requerimientosEs conveniente si la mayoría de las operaciones son estrictamente locales respecto a la superentidad o a una de las subentidades.

Page 51: Modelo Relacional

Proyecto (nr_proyecto, nombre_proyecto) PK: nr_proyecto Desarrollo_Sw (nr_proyecto, nr_módulos) PK: nr_proyecto FK: nr_proyecto referencia a ProyectoSubcontrato (nr_proyecto, contratista_principal) PK: nr_proyecto FK: nr_proyecto referencia a Proyecto

nr_proy ec tonombre_proy ec to

c ontratista pr inc ipalnr_modulos