Modelo Relacional.

En 1970, el modo en que se veían las bases de datos cambió por completo cuando E.

F. Codd introdujo el modelo relacional.

En aquellos momentos, el enfoque existente para la estructura de las bases de datos

utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos

archivos. Si, por ejemplo, se quería relacionar un registro con un registro , se

debía añadir al registro un campo conteniendo la dirección en disco del registro .

Este campo añadido, un puntero físico, siempre señalaría desde el registro al

registro . Codd demostró que estas bases de datos limitaban en gran medida los

tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas

bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los

controladores de un nuevo disco al sistema y los datos se movían de una localización

física a otra, se requería una conversión de los archivos de datos. Estos sistemas se

basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que

constituyeron la primera generación de los SGBD.

El modelo relacional representa la segunda generación de los SGBD. En él, todos los

datos están estructurados a nivel lógico como tablas formadas por filas y columnas,

aunque a nivel físico pueden tener una estructura completamente distinta. Un punto

fuerte del modelo relacional es la sencillez de su estructura lógica.

Estas tablas, pueden ser construidas de diversas maneras:

• Creando un conjunto de tablas iniciales y aplicar ciertas operaciones

(normalización) hasta conseguir el esquema más óptimo.

• Convertir el diagrama MER a tablas y posteriormente aplicar también estas

operaciones hasta conseguir el esquema óptimo.

La primera técnica fue de las primeras en existir y, como es de suponerse, la segunda

al ser más reciente es mucho más conveniente en varios aspectos:

• El partir de un diagrama visual es muy útil para apreciar los detalles, de ahí que

se llame modelo conceptual.

• El crear las tablas iniciales es mucho más simple a través de las reglas de

conversión (MER-Relacional).

• Se podría pensar que es lo mismo porque finalmente hay que aplicar

operaciones (normalización) a las tablas de todas formas, pero la ventaja de

partir del MER es que estas operaciones son mínimas por lo general.

• Lo anterior tiene otra ventaja: aún cuando se normalice de manera deficiente,

se garantiza un esquema aceptable, lo que en la primera técnica no es así.

El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de

los datos:

• Estructura de datos.

• Integridad de datos.

• Manejo de datos.

Nos avocaremos por ahora al primer punto.

A continuación se presenta un ejemplo de modelo relacional correspondiente a

clientes de un banco y sus cuentas.

Se puede apreciar la tabla cliente y los datos del mismo, así como la tabla cuenta y los

datos de cada cuenta. Pero, se puede saber quién es el dueño de cada cuenta? O

bien a quién le pertenece alguna de esas cuentas?

Este diagrama está incompleto, ya que no hay como relacionar estas tablas. Se

presenta a continuación el esquema que sí corresponde al problema referido:

Qué información se puede obtener? Claramente la información de cada cliente, la

información de cada cuenta y se puede conocer a quien pertenece cada cuenta.

Podría querer conocer por ejemplo el nombre y dirección de los clientes que

mantienen saldos mayores a 500.

¿Cómo se relacionan? A través de la tabla cliente-cuenta.

Este esquema corresponde al MER que se encuentra a continuación. Como se

mencionó, es posible obtenerlo directamente a partir del MER, como también generar

las tablas partiendo de cero.

Nótese que ambas cardinalidades son (1,N), lo que significa que los clientes de la

base tienen una o más cuentas y que las cuentas de la base tienen uno o más clientes

propietarios.

Cliente Cuentanombre_cliente

calle_cliente

id_cliente

ciudad_clientetiene

saldonúmero_cuenta

(1,n)(1,n)

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

Las 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 o relación representada por la tabla (a las

filas se las llama también tuplas).

Elementos importantes:

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, es decir, 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.

Ejemplo Tabla (relación) Película

título año duración Tipo

Star Wars 1977 124 color

Mighty Ducks 1991 104 color

Wayne's World 1992 95 color

Por ejemplo, la información de las oficinas de una empresa inmobiliaria se representa

mediante la relación OFICINA, que tiene columnas para los atributos Onum (número

de oficina), Calle, Area, Población, Teléfono y Fax.

La información sobre el staff se representa mediante la relación PLANTILLA, que tiene

columnas para los atributos Enum (número de empleado), Nombre, Apellido,

Dirección, Teléfono, Puesto, Fecha_nac, Salario, DNI, Onum (número de la oficina a la

que pertenece el empleado).

A continuación se muestra una instancia de la relación OFICINA y una instancia de la

relación PLANTILLA. Como se puede observar, cada columna contiene valores de un

solo atributo. Por ejemplo, la columna Onum sólo contiene números de oficinas que

existen.

OFICINA

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

PLANTILLA

Enum Nombre Apellido Dirección Teléfono Puesto Fecha_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

Superviso

r 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

Superviso

r 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

Superviso

r 29/2/67 18000 39552133 O5

Dominio Los dominios constituyen una poderosa característica del modelo relacional. Cada

atributo de una base de datos relacional se define sobre un dominio, pudiendo haber

varios atributos 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.

Ejemplos de dominios serían:

• 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.

Todo dominio ha de tener un nombre por el cual nos podamos referir a él. Por ejemplo

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)

Cada domino debe tener también un tipo de datos; así 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.

La siguiente tabla muestra los dominios de los atributos de la relación OFICINA.

Nótese que en esta relación hay dos atributos que están definidos sobre el mismo

dominio: Teléfono y Fax.

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_POBLACION 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

Tipos de Datos Como se menciono, cada dominio debe definirse sobre algún tipo de dato, es decir

cada atributo tendrá que estar definido de acuerdo a un tipo de datos. Veamos

algunos:

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.

En relación a los datos numéricos, existen diversos tipos, que consideran rangos

específicos que pueden abarcar. La elección de uno u otro dependerá del problema: el

rango que alcanza el valor del atributo debe definir cual utilizar.

Entero

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

Real

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

Los tipos de datos a utilizar dependerán del SGBD que se utilice. Algunos manejan

otro tipo de datos como

• Fecha/Hora: para introducir datos en formato fecha u hora

• Moneda :para introducir datos en formato número y con el signo monetario

• Autonumérico: se numera automáticamente el contenido

Nulos Un nulo no representa el valor cero ni la cadena vacía; éstos son valores que tienen

significado. El nulo implica ausencia de información.

Se puede definir el valor nulo como una marca utilizada para representar información

desconocida. La necesidad de valores nulos es evidente por diversas razones:

Existencia de tuplas con ciertos atributos desconocidos en ese momento.

Necesidad de 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.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo que puede

causar problemas de implementación.

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 el mismo nombre al atributo y al dominio. En el caso de que sean

varios los atributos de una misma tabla definidos sobre el mismo dominio, habrá que

darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo

nombre.

Por ejemplo los atributos edad_física y edad_mental pueden estar definidos sobre el

mismo dominio edad; o los atributos precio_compra y precio_venta pueden estar

definidos sobre el mismo dominio precio, enteros de longitud 5 mayores que 0.

Relación Una relación R sobre un conjunto de valores D1, D2,…Dn se compone de 2 partes: una

cabecera y un cuerpo.

La cabecera esta formada por un conjunto de atributos. Cada atributo corresponde a

un único dominio, y todos los atributos son distintos, es decir, no hay dos atributos que

se llamen igual.

El cuerpo esta formado por un conjunto de tuplas que varía en el tiempo. Cada tupla

es un conjunto de pares atributo:valor:

La cantidad de atributos se le conoce como grado y la cantidad de tuplas se le conoce

como cardinalidad.

La relación OFICINA tiene la siguiente cabecera:

{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),

(Población:NOM_POBLACION),(Teléfono:NUM_TEL_FAX), Fax:NUM_TEL_FAX)}.

Siendo la siguiente una de sus tuplas:

{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro),

(Población:Castellón), (Teléfono:964 201 240), (Fax:964 201 340)}.

Claves Una clave candidata de una relación R es un conjunto no vacío de atributos que

identifican univoca y mínimamente a una tupla. Toda relación siempre tendrá una

clave candidata.

Clave primaria: es aquella clave candidata que el usuario escogerá, por

consideraciones ajenas al modelo relacional, para identificar a las tuplas de una

relación.

Clave alternativa: son aquellas claves candidatas que no han sido elegidas como

primarias.

Clave ajena o foránea de una relación R2 es un conjunto no vacío de atributos cuyos

valores han de coincidir con los valores de la clave primaria de otra relación R1. La

clave foránea y la correspondiente clave primaria han de estar definidas sobre los

mismos dominios.

Ningún componente de la clave primaria de una relación puede en algún momento no

tener valor (aceptar nulos); no tiene sentido modelar una entidad que no podemos

identificar ni distinguir una de otra.

Transformación MER-Relacional Se transformara el esquema conceptual (MER) obtenido en la fase anterior a un

esquema relacional. Este esquema sigue siendo independiente del SGBD a ser

utilizado en la siguiente etapa.

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

1. Todo tipo de entidad se convierte en relación. Cada entidad del esquema MER dará lugar a una nueva relación cuya clave primaria

es el identificador principal de la entidad.

Identificador principal: atributo(s) que forman la clave primaria de la nueva relación.

Se deben subrayar en la relación.

Cada atributo de una entidad se transforma en un atributo de la relación creada para la

entidad. 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)

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.

Clientenombre_cliente

calle_cliente

id_cliente

ciudad_cliente

La relación sería la siguiente:

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

(PK: primary key->clave primaria)

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 se sitúa el atributo

multivaluado mas el nombre del atributo multivaluado.

Cliente

id_clientenombre_cliente

direccion_clientetelefono_cliente

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)

Atributos compuestos: se pueden transformar según las siguientes alternativas:

a. Eliminar el atributo compuesto considerando todos sus componentes como

atributos individuales.

Cliente

id_clientenombre_cliente

direccion_clientetelefono_cliente

callenumero

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

id_cliente

b. 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

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.

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, aunque puede ser mejor crear

una nueva relación para representar una interrelación que tiene atributos.

Dependencia por existencia.

Una interrelación 1:N de dependencia en existencia origina una propagación de clave

desde la relación que representa a la entidad fuerte a la relación que representa a la

entidad débil. No puede existir ninguna ocurrencia de la entidad hijo (débil) que no este

relacionada con una ocurrencia de la entidad padre (fuerte).

Edificio Plantatiene(1,n)(1,1)codigo_edificio

direccion_edificio

codigo_plantanumero_habitaciones

PlantaE

Edificio (codigo_edificio, direccion_edificio) PK: codigo_edificio

Planta (codigo_planta, numero_habitaciones, codigo_edificio) PK: codigo_planta FK:

codigo_edificio referencia a Edificio.

Dependencia por identidad. Una interrelación 1:N de dependencia en identificación da lugar a una propagación de

clave desde la relación que representa a la entidad fuerte a la relación que representa

a la entidad débil, de tal forma que la entidad débil requiere de la clave de la entidad

fuerte para su identificación. La clave de la relación que representa a la entidad débil

queda formada por la concatenación de la clave foránea y la clave de la entidad débil.

ti eneLibro E jemplar

(1 ,N)(1,1 )Có d igo

No mb reNr_h oja sEdito rial

Númer oEst adoPosició n

Ejempla rI

Libro (codigo, nombre, nr_hojas, editorial) PK: codigo

Ejemplar (codigo, numero, estado, posición) PK: codigo, numero FK: codigo

referencia a Libro.

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. De esta forma 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.

Cliente Cuentanombre_cliente

calle_cliente

id_cliente

ciudad_clientetiene

saldonúmero_cuenta

(1,n)(1,n)

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

Cuenta (numero_cuenta, saldo) PK: numero_cuenta

Tiene (id_cliente, numero_cuenta) PK. Id_cliente, numero_cuenta FK: id_cliente

referencia a Cliente, numero_cuenta referencia a Cuenta.

Si la interrelación tiene atributos, estos pasaran a formar parte de la relación creada

para la interrelación.

Cliente Cuentanombre_cliente

calle_cliente

id_cliente

ciudad_clientetiene

saldonúmero_cuenta

(1,n)(1,n)

privilegio

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

Cuenta (numero_cuenta, saldo) PK: numero_cuenta

Tiene (id_cliente, numero_cuenta, privilegio) PK. Id_cliente, numero_cuenta FK:

id_cliente referencia a Cliente, numero_cuenta referencia a Cuenta.

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. Si existen atributos en la interrelación, estos también se

propagaran.

Ciudad Regionesta(1,n) (1,1)nombre_ciudad

habitantes_ciudad

numero_regionnombre_regionhabitantes_region

Region (numero_region, nombre_region, habitantes_region) PK: numero_region

Ciudad (nombre_ciudad, habitantes_ciudad, numero_region) PK: nombre_ciudad, FK:

numero_region referencia a Region.

Proveedor Productosuministranombrecódigo

precio_unitario(1,1) (1,n)nombre

código

direccion

fecha

Proveedor (codigo, nombre, direccion) PK: codigo

Vendedor (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.

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

Pedido Vendedorsuministra

nombre_vendedor(1,n) (0,1)fecha

numero_pedido

tasa_descuento

fono

Se podrían generar las siguientes tablas:

Vendedor (nombre_vendedor, fono_vendedor) PK: nombre_vendedor

Pedido (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.

Si el número relativo de esos pedidos es grande, y no se puede admitir valores nulos, una mejor alternativa sería establecer tres relaciones (lo cual es el caso más

general):

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_vendedor

Pedido (numero_pedido, fecha) PK: numero_pedido

Pedido_Ventas (numero_pedido, nombre_vendedor, tasa_descuento) PK:

numero_pedido, FK: numero_pedido referencia a Pedido, nombre_vendedor referencia

a Vendedor

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

tablas: una para representar cada entidad y una para representar la relación.

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

marca_auto

CI_personanombre_personadireccion_persona

Auto (patente_auto, marca_auto) PK: patente_auto

Persona (CI_persona, nombre_persona, direccion_persona) PK CI_persona

Auto_persona (CI_persona, patente_auto) PK: patente_auto, CI_persona, FK: PK:

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 Persona

Persona (CI_persona, nombre_persona, direccion_persona) PK CI_persona

4. Interrelaciones 1:1 Son casos en donde se puede crear una relación o bien propagar la clave. Esto último

puede ser en ambas direcciones:

a) Si la relación es del tipo 1:1 y es obligatorio (total) tipo de participación de ambas

entidades, 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 Directortiene

CI_director(1,1) (1,1)direccion_empresa

codigo_empresa nombre

Empresa (codigo_empresa, direccion_empresa, CI_director) PK codigo_empresa, FK

CI_director referencia a Director

Director (CI_director, nombre, codigo_empresa) PK CI_director, FK codigo_empresa

referencia a Empresa

b) 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 Deptoresponsable

codigo_depto(1,1) (0,1)nombre_empleado

codigo_empleado nombre_depto

Empleado (codigo_empleado, nombre_empleado) PK: codigo_empleado

Depto (codigo_depto, nombre_depto, codigo_empleado) PK: codigo_depto, FK:

codigo_empleado referencia a Empleado.

c) Si las entidades que se asocian tienen ambas cardinalidades (0,1) entonces es

necesario generar 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.

Asi se evitan los valores nulos que aparecerian en caso de propagar una de las

claves primarias. No todas las personas tienen animales, en el ejemplo.

Persona Animalposee

codigo_animal(0,1) (0,1)

nombre_personaCI_persona nombre_animal

fecha

Persona (codigo_persona, nombre_persona) PK: codigo_persona

Animal (codigo_animal, nombre_animal) PK: codigo_animal

Persona_Animal (codigo_persona, codigo_animal, fecha) PK: codigo_persona,

codigo_animal FK: codigo_persona referencia a Persona, codigo_animal referencia a

Animal.

5. Relaciones reflexivas Para transformar una relación reflexiva al modelo relacional, 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

(1,n)

nombre_personaCI_persona

apadr ina

(1,1)

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

CI_o_persona referencia a Persona

En este caso 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.

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)

nombre_personaCI_persona

apadr ina

(0,1)

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_personaCI_persona

apadr ina

(1,1)

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)

nombre_personaCI_persona

apadr ina

(0,1)

Una persona apadrina a una persona y una persona es apadrinada por solo una

persona.

Persona

(1,1)

nombre_personaCI_persona

apadr ina

(1,1)

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

CI_o_persona referencia a Persona

No se deben aceptar valores nulos. Todas las personas son padrinos de una persona.

Si persona apadrina a (0,1) persona y persona puede ser apadrinado por solo una

persona el esquema es el mismo. Si una persona apadrina a una sola persona, y una

persona puede apadrinar o no (0,1) se deben aceptar valores nulos en la clave

foránea. Lo mismo pasa en el caso en que la cardinalidad sea (0,1) en ambos lados.

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

6. 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:

a. 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. Esta alternativa es aplicable a todos los casos, con todas las

coberturas, teniendo el problema de tener que manejar en algunos casos

demasiados valores nulos y que las operaciones que sólo actuaban sobre una

subentidad tendrán que buscar ahora los casos correspondientes dentro del

conjunto completo de casos.

matricula_estudiantenombre_estudiante

titulo_tesiscarrera

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

PK: matricula_estudiante

b. Eliminar la superentidad reteniendo las subentidades. Aquí los atributos heredados

deben propagarse entre las subentidades. Esta alternativa no es práctica para

generalizaciones superpuestas o parciales; sólo lo es para jerarquías totales y

exclusivas. Además, 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.

rut_empleadonombre_empleado

nr_supervisadosespecialidad

Ingeniero (rut_empleado, nombre_empleado, especialidad) PK: rut_empleado

Gerente (rut_empleado, nombre_empleado, nr_supervisados) PK: rut_empleado

c. 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 requerimientos, y es

conveniente si la mayoría de las operaciones son estrictamente locales respecto a

la superentidad o a una de las subentidades.

nr_proyectonombre_proyecto

contratista principalnr_modulos

Proyecto (nr_proyecto, nombre_proyecto) PK: nr_proyecto

Desarrollo_Sw (nr_proyecto, nr_módulos) PK: nr_proyecto FK: nr_proyecto referencia

a Proyecto

Subcontrato (nr_proyecto, contratista_principal) PK: nr_proyecto FK: nr_proyecto

referencia a Proyecto

Esquema de una base de datos relacional Una base de datos relacional es un conjunto de relaciones normalizadas. Para

representar el esquema de una base de datos relacional se debe dar el nombre de sus

relaciones, los atributos de éstas, los dominios sobre los que se definen estos

atributos, las claves primarias y las claves ajenas.

El esquema de la base de datos de la empresa inmobiliaria es el siguiente:

OFICINA (Onum, Calle, Area, Población, Teléfono, Fax)

PLANTILLA (Enum, Nombre, Apellido, Dirección, Teléfono, Puesto, Fecha_nac, Salario, DNI, Onum)

INMUEBLE (Inum, Calle, Area, Población, Tipo, Hab, Alquiler, Pnum, Enum, Onum)

INQUILINO (Qnum, Nombre, Apellido, Dirección, Teléfono, Tipo_pref, Alquiler_max)

PROPIETARIO (Pnum, Nombre, Apellido, Dirección, Teléfono)

VISITA (Qnum, Inum, Fecha, Comentario)

En el esquema, los nombres de las relaciones aparecen seguidos de los nombres de

los atributos encerrados entre paréntesis. Las claves primarias son los atributos

subrayados. Las claves ajenas se representan mediante los siguientes diagramas

referenciales.

PLANTILLA

OFICINA : Oficina a la que pertenece el empleado.

INMUEBLE

PROPIETARIO : Propietario del inmueble.

INMUEBLE

PLANTILLA : Empleado encargado del inmueble.

INMUEBLE

OFICINA : Oficina a la que pertenece el inmueble.

VISITA

INQUILINO : Inquilino que ha visitado el inmueble.

VISITA

INMUEBLE : Inmueble que ha sido visitado.

A continuación se muestra un estado (instancia) de la base de datos cuyo esquema se

acaba de definir.

OFICINA

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

PLANTILLA

Enum Nombre Apellido Dirección Teléfono Puesto Fecha_nac Salario DNI Onum

EL21 Amelia Pastor Magallanes, 15 964 284 560 Director 12/10/62 30000 39432212E O5

Castellón

EG37 Pedro Cubedo Bayarri, 11 964 535 690 Supervisor 24/3/57 18000 38766623X O3

Villarreal

EG14 Luis Collado Borriol, 35 964 522 230 Administ. 9/5/70 12000 24391223L O3

Villarreal

EA9 Rita Renau Casalduch, 32 964 257 550 Supervisor 19/5/60 18000 39233190F O7

Castellón

EG5 Julio Prats Melilla, 23 964 524 590 Director 19/12/50 24000 25644309X O3

Villarreal

EL41 Carlos Baeza Herrero, 51 964 247 250 Supervisor 29/2/67 18000 39552133T O5

Castellón

INMUEBLE

Inum Calle Area Población Tipo Hab Alquiler Pnum

IA14 Enmedio, 128 Centro Castellón Casa 6 600 P46

IL94 Riu Ebre, 24 Ronda Sur Castellón Piso 4 350 P87

IG4 Sorell, 5 Grao Castellón Piso 3 300 P40

IG36 Alicante,1 Segorbe Casa 3 325 P93

IG21 San Francisco, 10 Vinaroz Piso 5 550 P87

IG16 Capuchinos, 19 Rafalafena Castellón Piso 4 400 P93

PROPIETARIO

Pnum Nombre Apellido Dirección Teléfono

P46 Amparo Felip Asensi 24, Castellón 964 230 680

P87 Manuel Obiol Av. Libertad 15, Vinaroz 964 450 760

P40 Alberto Estrada Av. del Puerto 52, Castellón 964 200 740

P93 Yolanda Robles Purísima 4, Segorbe 964 710 430

INQUILINO

Qnum Nombre Apellido Dirección Teléfono Tipo Alquiler

Q76 Juan Felip Barceló 47, Castellón 964 282 540 Piso 375

Q56 Ana Grangel San Rafael 45, Almazora 964 551 110 Piso 300

Q74 Elena Abaso Navarra 76, Castellón 964 205 560 Casa 700

Q62 Alicia Mori Alloza 45, Castellón 964 229 580 Piso 550

VISITA

Qnum Inum Fecha Comentario

Q56 IA14 24/11/99 muy pequeño

Q76 IG4 20/10/99 muy lejos

Q56 IG4 26/11/99

Q62 IA14 14/11/99 no tiene salón

Q56 IG36 28/10/99