dbd unidad 2 parte 6 modelo relacional i · el modelo relacional, como todo modelo de datos, tiene...
TRANSCRIPT
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