Tema – 2Modelo relacional
Índice
1. Introducción.2. Relación: dominio, atributo, tupla, grado,
cardinalidad, valores nulos, comparación con ficheros, llaves.
3. Reglas de integridad: de entidad y referencial.4. Traducción del modelo E-R al modelo
relacional.5. Representación gráfica.
2
2.1. Introducción
• Modelo definido por Edgar Frank Codd en 1970.• Se basa en las matemáticas: teoría de conjuntos.• Enfoque revolucionario: los usuarios deben trabajar
de forma sencilla y independiente del funcionamiento físico de la BD.
• A IBM no le gusta la idea. Otras empresas, como Oracle, son las primeras en implementar estas teorías.
• Hoy en día (casi) todas las BD siguen este modelo.
3
2.1. Introducción
• Objetivos:– Independencia física: la forma de almacenar los datos no
debe influir en su manipulación lógica. Si cambia, los usuarios no deben apreciarlo.
– Independencia lógica: las aplicaciones que usan la BD no se deben modificar si se modifican los datos de la BD.
– Flexibilidad: la BD ofrece diversas vistas en función de los usuarios y aplicaciones.
– Uniformidad: las estructuras lógicas siempre tienen una única forma conceptual (tablas).
– Sencillez: facilidad de manejo.
4
2.1. IntroducciónAño Hecho
1970 Codd publica las bases del modelo relacional.
1971-72 Primeros desarrollos teóricos.
1973-78 Primeros prototipos de BBDD relacionales: System R (IBM). En este sistema se desarrolla Sequell que con el tiempo cambiaría su nombre a SQL.
1974 La Universidad de Berkeley desarrolla Ingres, un SGBD relacional. Utiliza el lenguaje Quel.
1978 Aparece el lenguaje de acceso relacional QBE (Query By Example) para los ficheros VSAM de IBM.
1979 Aparece Oracle, primer SGBD relacional comercial. Implementa SQL y se convertirá en el SGBD relacional líder.Codd revisa el modelo y sale el modelo RM/T
1981 Aparece Informix como SGBD per Unix.
5
2.1. IntroducciónAño Hecho
1983 Aparece DB2, el SGBD relacional de IBM.
1984 Aparece la BD Sybase (llega a ser la segunda más popular).
1986 ANSI normaliza SQL (SQL/ANSI). Ya es el lenguaje principal de gestión de BBDD relacionales.
1987 ISO normaliza SQL. SQL ISO (9075).
1988 La versión 6 de Oracle incorpora el lenguaje procedimental PL/SQL.
1989 ISO publica el estándar SQL Addendum.Microsoft y Sybase desarrollan SQL Server.
1990 Versión 2 del modelo relacional (RM/V2) por Codd.Propuesta de Michael Stonebraker para añadir al modelo relacional capacidades de orientación a objetos.
1992 ISO publica el estándar SQL 92 (el más utilizado).
6
2.1. IntroducciónAño Hecho
1995 Aparece el modelo objeto/relacional.Aparece MySQL, una BD relacional de código abierto con licencia GNU, que se hace muy popular entre desarrolladores web.
1996 ANSI normaliza el lenguaje procedimental basado en SQL: SQL/PSM.Aparece PostgreSQL (de código abierto).
1999 ISO publica SQL 99 (o SQL 200).
2003 ISO publica el estándar SQL 2003 (incluye SQL/PSM).
2006 Estándar ISO. SQL 2006.
2008 Estándar ISO. SQL 2008.
2008 Sun compra MySQL
2009 Oracle compra Sun
7
2.2. Relación (o tabla)
• Elemento fundamental en el modelo relacional.• Relación (Codd) ≠ Relación (Chen)• Las relaciones constan de:
• Atributos: referidos a cada propiedad de los datos que se almacenan en la relación.
• Tuplas: referido a cada elemento de la relación.
8
2.2. Relación (o tabla)
• Se representa en forma de tabla.• Las columnas son los atributos.• Las filas son las tuplas.
9
2.2. Relación: tupla
• Cada una de las filas de la relación.• Se corresponde con la idea clásica de registro.• Representa cada elemento individual de la relación.
• Ejemplo: relación que almacena personas, una tupla representa una persona en concreto.
• Características:• Cada tupla se corresponde con un elemento del mundo
real.• No pueden haber dos tuplas iguales (con todos los valores
iguales).
10
2.2. Relación: dominio
• Conjunto de todos los valores posibles que puede tomar un determinado atributo. Dos atributos diferentes pueden tener el mismo dominio.
• Técnicas para indicar el contenido de un dominio:• Intención: se define el dominio indicando la definición exacta de sus
posibles valores. Por ejemplo, edad de los trabajadores: entre 16 y 65.• Extensión: se indican algunos valores y se sobreentiende el resto. Por
ejemplo, dominio de localidad: Barcelona, L’Hospitalet de Llobregat, Sabadell, Sant Boi de Llobregat...
• Tipos:• Generales: los valores están comprendidos entre un máximo y un
mínimo.• Restringidos: solo pueden tomar un conjunto de valores.
11
2.2. Relación: dominio y atributo
• Ejemplo 1:Define Dominio expediente entero (4) Fin definición;Define Dominio primer-nombre carácter (15) Fin definición;Define Dominio final-nombre carácter (40) Fin definición;Define Dominio estudios entero (2) Fin definición;Define Dominio nota real (4) Fin definición;Define Relación Alumno
(matricula#: Dominio expediente,nombre: Dominio primer-nombre,apellidos: Dominio final-nombre,curso: Dominio estudios,nota: Dominio nota);
12
2.2. Relación: dominio y atributo
• Ejemplo 2:Define Dominio expediente entero (4) Fin definición;Define Dominio primer-nombre carácter (15) Fin definición;Define Dominio final-nombre carácter (40) Fin definición;Define Dominio estudios entero (2) Fin definición;Define Dominio nota real (4) Fin definición;Define Relación Alumno
(matricula#: Dominio expediente,nombre: Dominio primer-nombre,apellidos: Dominio final-nombre,curso: Dominio estudios,nota: Dominio notaedad Dominio estudios);
13
2.2. Relación: dominio y atributo
• Ejemplo 1: se han definido cinco dominios y, basándose en ellos definimos cinco atributos de la relación. El dominio puede, o no, tener asignado el mismo nombre que el atributo mediante el cual se define la relación.
• Ejemplo 2: pueden definirse más de un atributo sobre un mismo dominio.
14
2.2. Relación: grado y cardinalidad
• Grado: indica el tamaño de una relación en base al número de atributos (columnas) de la misma.• Mayor grado → Mayor complejidad de manejo.• Podemos tener relaciones unarias, binarias, ternarias, etc.
• Cardinalidad: indica el tamaño de una relación en base al número de tuplas (filas) de la misma.
Cardinalidad depende del momentoGrado no
15
2.2. Relación
• Los términos anteriores tienen diferentes sinónimos dependiendo de la nomenclatura utilizada.
TÉRMINOS 1(nomenclatura relacional)
TÉRMINOS 2(nomenclatura tabla)
TÉRMINOS 3(nomenclatura ficheros)
Relación = Tabla = Fichero
Tupla = Fila = Registro
Atributo = Columna = Campo
Grado = Nº columnas = Nº campos
Cardinalidad = Nº filas = Nº registro
16
2.2. Relación
• Ejemplo: indicar el grado, la cardinalidad, y los dominios de los atributos de la siguiente relación.
ALUMNO matricula# nombre apellidos curso nota
3456 José Pérez Fernández 1 5.25
0101 María Abad Sastre 2 7.80
8743 Lourdes Sánchez Ramos 1 4.50
1234 Antonio Santiago Viñas 3 6.35
5674 Luis González Sillas 1 3.20
0678 Pilar González Badajoz 2 5.50
0345 Dolores Martín Márquez 3 7.30
2985 Manuel Martínez Fuentes 3 3.50
17
ALUMNO matricula# nombre apellidos curso nota
3456 José Pérez Fernández 1 5.25
0101 María Abad Sastre 2 7.80
8743 Lourdes Sánchez Ramos 1 4.50
1234 Antonio Santiago Viñas 3 6.35
5674 Luis González Sillas 1 3.20
0678 Pilar González Badajoz 2 5.50
0345 Dolores Martín Márquez 3 7.30
2985 Manuel Martínez Fuentes 3 3.50
Nombre relaciónRelación de grado 5
Relación decardinalidad 8
Dominio de nota: de 0 a 10.
2.2. Relación
18
2.2. Relación: definición formal
• Formada por:• Nombre: identifica la relación.• Cabecera: conjunto de todos los pares atributo-dominio
de la relación.• Cuerpo: conjunto de m tuplas que forman la relación. Cada
tupla es un conjunto de pares atributo-valor.• Esquema: se forma con el nombre de la relación y la
cabecera.• Estado de la relación: se forma con el esquema y el
cuerpo.
19
2.2. Relación: definición formal
• Ejemplo:
Esquema: Cliente(DNI: DNI, Nombre: Nombre, Edad: Edad)Cuerpo: {(DNI: “12333944C”, Nombre: “Ana”, Edad: 52), (DNI: “12374678G”, Nombre: “Eva”, Edad: 27), (DNI: “28238232H”, Nombre: “Martín”, Edad: 33)}
Cliente
DNI Nombre Edad
12333944C Ana 52
12374678G Eva 27
28238232H Martín 33
20
2.2. Relación: propiedades
• Cada relación tiene un nombre diferente.• Cada atributo de la relación tiene un único valor en
cada tupla.• Cada atributo tiene un nombre diferente en cada
tabla (aunque pueden coincidir en tablas diferentes).• Cada tupla es única (no hay tuplas duplicadas).• El orden de los atributos no importa.• El orden de las tuplas no importa.
21
2.2. Relación: clave
• Clave candidata: conjunto de atributos que identifican inequívocamente cada tupla de la relación. Toda relación debe tener al menos una clave candidata (pueden haber más).
• Clave primaria (principal): clave candidata que se coge como identificador de las tuplas. Se elige como primaria la candidata que identifica mejor a cada tupla en el contexto de la BD.
• Clave alternativa: cualquier clave candidata que no sea primaria.
22
2.2. Relación: claves
• Clave secundaria(externa, foránea, ajena): son los atributos de una relación (tabla), los valores de los cuales están relacionados con atributos de otra relación (tabla).
23
2.2. Relación: claves
• Ejemplo:Equipo Número equipo
F.C. Barcelona 1
Real Madrid 2
Sevilla C.F. 3
Número jugador Nombre jugador Número equipo
1 Jesús Navas 3
2 Villa 1
3 Cristiano Ronaldo 2
4 Messi 1
24
2.2. Relación: claves
• Ejemplo:• La clave primaria de la relación Equipo es el número de
equipo.• El número de equipo de la relación Jugador sirve para
relacionar el jugador con el equipo al que pertenece.
• El atributo número de equipo de la relación Jugador es una clave secundaria.
25
2.3. Reglas de integridad
• Reglas para garantizar la consistencia de la información.
• Integridad de la clave: ningún atributo que forme parte de una clave candidata de una relación podrá tomar valores nulos en ninguna tupla de la relación.
• Integridad de referencia: los atributos que sean claves secundarias sólo podrán tener valores que estén relacionados con la llave primaria de la relación (tabla) que relacionen, o bien valores nulos.
26
2.3. Reglas de integridad
• Ejemplo de integridad de referencia:
• En la relación Alquiler no se podrá incluir ningún código que no esté en la relación Cliente. Lo prohíbe la integridad referencial.
Alquiler
Cod_alquiler Fecha Cod_cliente
1 12/9/2009 121
2 12/9/2009 121
3 15/9/2009 97
4 16/9/2009 113
5 16/9/2009 129
Cliente
Cod_cliente Nombre Apellidos
97 Arturo Crespo
113 Sara Álvarez
121 Josu Lopetegui
123 Alba Pereira
129 Gonzalo Pérez
27
2.3. Reglas de integridad• ¿Qué pasa si borramos o modificamos datos de la
relación Cliente?• Pueden quedar tuplas de la relación Alquiler con la clave
secundaria haciendo referencia a un valor que ya no existe en Cliente.
• Opciones:• Prohibir la operación.• Transmitir la operación en cascada: si se modifica o se borra un
cliente, también se modificarán o se borrarán los alquileres relacionados con él.
• Colocar nulos.• Utilizar un valor por defecto.
28
2.3. Reglas de integridad
• Regla de validación: condición que debe cumplir un atributo en concreto para ser válido. Por ejemplo, valor mínimo y máximo, lista de valores, etc.
• Disparadores o triggers: pequeños programas almacenados en la BD que se ejecutan automáticamente cuando se cumple una determinada condición. Permiten realizar restricciones muy potentes, pero difíciles de crear.
29
2.4. Traducción del modelo E-R a relacional • Trabajo previo: preparación del modelo E-R.
1. Eliminación de atributos múltiples.
LIBRO
LIBRO
isbn
editorial
autor#
AUTOR(1,n) (1,n)
N:N
isbneditorial
autor
30
nombre_completo
2.4. Traducción del modelo E-R a relacional • Trabajo previo: preparación del modelo E-R.
2. Eliminación de atributos compuestos.
PERSONA
dni
nombre
primer_apellido
segundo_apellido
PERSONA
dni
nombre
primer_apellido
segundo_apellido
31
2.4. Transformación de entidades
• Entidades: pasan a ser tablas.• Atributos: pasan a ser columnas o atributos de la
tabla.• Identificadores principales: pasan a ser claves
primarias.• Identificadores candidatos: pasan a ser claves
candidatas.
32
2.4. Transformación de relaciones
• Idea general: transformamos cada relación del modelo E-R en una tabla en el modelo relacional.
• Casos:– Relaciones 1:N– Relaciones N:M– Relaciones 1:1– Relaciones reflexivas– Relaciones jerárquicas
33
2.4. Transformación de relaciones
• Relaciones 1:N: las relaciones binarias de tipo uno a varios no requieren ser transformadas en una tabla al modelo relacional. La tabla del lado varios (tabla relacionada) incluye como clave secundaria el identificador de la entidad del lado uno (tabla principal).
34
2.4. Transformación de relaciones
• Relaciones 1:N. Ejemplo:
Entidad 1(identificador_1, atributo_1, identificador_2, atributo_2)
Entidad 2(identificador_2, atributo_3)
Entidad 1 Entidad 2
identificador_1 identificador_2
atributo_1
atributo_2
atributo_3
({0|1},n) (1,1)
35
2.4. Transformación de relaciones
• Relaciones 1:N: si la entidad que interviene con cardinalidad máxima 1 participa en la relación de forma parcial (cardinalidad mínima 0), podemos crear una tabla para cada entidad y otra para la relación. Ésta estará formada por los identificadores de las entidades relacionadas y por los atributos de la relación.– La regla vista con anterioridad también describirá el
problema correctamente.
36
2.4. Transformación de relaciones
• Relaciones 1:N. Ejemplo:
A. Entidad 1 (identificador_1, atributo_1, identificador_2, atributo_2)Entidad 2 (identificador_2, atributo_3)
B. Entidad 1 (identificador_1, atributo_1)Entidad 2 (identificador_2, atributo_3)Relación (identificador_1, identificador_2, atributo_2)
Entidad 1 Entidad 2
identificador_1 identificador_2
atributo_1atributo_2
atributo_3
({0|1},n) (0,1)
37
2.4. Transformación de relaciones
• Relaciones 1:N:– Opción A: el atributo identificador_2 de la tabla Entidad 1
podrá tomar valores nulos.– Opción B: el atributo identificador_2 de la tabla Relación
no podrá tomar valores nulos.
38
2.4. Transformación de relaciones
• Relaciones N:M: cada entidad que participa en la relación se transforma en una tabla, y se genera una nueva tabla para la propia relación. Esta tabla estará formada por los identificadores de las entidades y por todos los atributos asociados a la relación. La clave principal de esta tabla será la agregación de los identificadores de las entidades que participan en la relación.
39
2.4. Transformación de relaciones
• Relaciones N:M. Ejemplo:
Entidad 1 (identificador_1, atributo_1)Entidad 2 (identificador_2, atributo_2)Relación (identificador_1, identificador_2, atributo_2)
Entidad 1 Entidad 2
identificador_1 identificador_2
atributo_1
atributo_2
atributo_3
(1,n) (1,n)
40
2.4. Transformación de relaciones
• Relaciones N:M de orden n: las relaciones ternarias, cuaternarias y n-arias, que unen más de dos relaciones se transforman en una tabla que contiene los atributos de la relación más los identificadores de las entidades relacionadas. La clave la forman las claves externas.
41
2.4. Transformación de relaciones
• Relaciones N:M de orden n. Ejemplo:
Entidad 1 (identificador_1, atributo_1) Enditad 2 (identificador_2, atributo_3)Entidad 3 (identificador_3, atributo_4) Entidad 4 (identificador_4, atributo_5)Relación (identificador_1, identificador_2, identificador_3, identificador_4,
atributo_2)
Entidad 1 Entidad 2
identificador_1 identificador_2
atributo_1atributo_2
atributo_3
(1,n) (1,n)
Entidad 3 Entidad 4
identificador_3 identificador_4
atributo_5atributo_4
42
2.4. Transformación de relaciones
• Relaciones 1:1: la transformación de las relaciones binarias en que las entidades participan con cardinalidad máxima 1 dependerá del valor de la cardinalidad mínima.– Las dos entidades participan de forma completa en la
relación: cardinalidad mínima de ambas = 1.– Una entidad participa de forma parcial en la relación:
cardinalidad mínima = 0.– Las dos entidades participan de forma parcial: cardinalidad
mínima de ambas = 0.
43
2.4. Transformación de relaciones
• Relaciones 1:1: participación completa.– Las dos entidades tienen el mismo identificador:
• Obtenemos una única tabla formada por la agregación de los atributos de las dos entidades. La clave de la tabla es el identificador de las entidades.
– Las dos entidades tienen diferente identificador:• Cada entidad se convierte en una tabla con sus
identificadores y atributos propios. Además, cada tabla tendrá como clave secundaria el identificador de la otra entidad con la que se relaciona.
44
2.4. Transformación de relaciones
• Relaciones 1:1: participación completa.– Las dos entidades tienen el mismo identificador. Ejemplo:
Entidad_1 (identificador_1, atributo_1, atributo_2, atributo_3, atributo_4)
(*) Normalmente estas relaciones no tienen atributos que les cualifiquen.
Entidad_1 Entidad_2(1,1) (1,1)
identificador_1 identificador_1
atributo_2
atributo_1
atributo_4
atributo_3
45
2.4. Transformación de relaciones
• Relaciones 1:1: participación completa.– Las dos entidades tienen diferente identificador. Ejemplo:
Entidad_1 (identificador_1, atributo_1, atributo_2, identificador_2)Entidad_2 (identificador_2, atributo_3, atributo_4, identificador_1)
Entidad_1 Entidad_2(1,1) (1,1)
identificador_1 identificador_2
atributo_2
atributo_1
atributo_4
atributo_3
46
2.4. Transformación de relaciones
• Relaciones 1:1: participación parcial de una entidad.– Cada entidad se convierte en una tabla y...– 2 opciones:
• Opción A: en la tabla con cardinalidad mínima 0 se coloca como clave secundaria la clave primaria de la otra tabla. No se construye tabla para la relación. Si ésta tenía algún atributo, éste se pondría en la tabla de la entidad que participa de forma parcial.
• Opción B: se construye una tabla para la relación formada por los identificadores de las entidades que participan.
47
2.4. Transformación de relaciones
• Relaciones 1:1: participación parcial de una entidad. Ejemplo:
A. Entidad_1 (identificador_1, atributo_1, atributo_2)Entidad_2 (identificador_2, atributo_3,atributo_4, identificador_1,
atributo_5)B. Entidad_1 (identificador_1, atributo_1, atributo_2)
Entidad_2 (identificador_2, atributo_3, atributo_4)Relación (identificador_1, identificador_2, atributo_5)
Entidad_1 Entidad_2(1,1) (0,1)
identificador_1 identificador_2
atributo_2
atributo_1
atributo_4
atributo_3
atributo_5
48
2.4. Transformación de relaciones
• Relaciones 1:1: participación parcial de una entidad:– Opción A: el atributo identificador_1 de la tabla Entidad_2
no tomará nunca valores nulos, ya que todas las entidades_2 siempre estarán relacionadas con al menos una entidad_1.
– Opción B: no habrá valores nulos, pero el esquema creado es más grande (una tabla más).
49
2.4. Transformación de relaciones
• Relaciones 1:1: participación parcial de ambas entidades.– Cada entidad se convierte en una tabla.– Se construye una tabla para la relación. Sus atributos
serán los identificadores de las entidades relacionadas, definidos como claves secundarias. La clave primaria será el identificador de una de las entidades, dejando la otra como clave alternativa.
50
2.4. Transformación de relaciones
• Relaciones 1:1: participación parcial de ambas entidades. Ejemplo:
Entidad_1 (identificador_1, atributo_1, atributo_2)Entidad_2 (identificador_2, atributo_3, atributo_4)Relación (identificador_1, identificador_2, atributo_5)
Entidad_1 Entidad_2(0,1) (0,1)
identificador_1 identificador_2
atributo_2
atributo_1
atributo_4
atributo_3
atributo_5
51
2.4. Transformación de relaciones
• Relaciones recursivas: se pueden presentar dos casos:– La entidad participa en los dos roles con cardinalidad máxima
N: se procede de la misma forma que con las relaciones N:N.– La entidad participa en uno de sus roles, o en ambos, con
cardinalidad máxima 1: hay dos opciones.• Opción A: se crea una tabla para la entidad y se añade como clave
secundaria el identificador de la entidad para representar la relación recursiva
• Opción B: se crea una tabla para la entidad y otra para la relación con el identificador de la entidad como clave primaria, y otra vez este identificador como clave secundaria.
52
2.4. Transformación de relaciones
• Relaciones recursivas: cardinalidades máximas N. Ejemplo:
Objeto(id, tamaño, color)Objeto_Objeto (id_continente, id_contenido, capa)
Objeto(1,n)id
color
tamaño
capa
(1,n)
Está_formado
Forma_parte_de
53
2.4. Transformación de relaciones
• Relaciones recursivas: cardinalidad máxima 1. Ejemplo:
A. Objeto(id_contenido, tamaño, color, id_continente, capa)B. Objeto (id, tamaño, color)
Objeto_Objeto (id_contenido, capa, id_continente)
Objeto(1,1)id
color
tamaño
capa
(1,n)
Está_formado
Forma_parte_de
54
2.4. Transformación de relaciones
• Eliminación de las relaciones jerárquicas: tres reglas.– Eliminación del supertipo de entidad.– Eliminación de los subtipos de entidad.– Eliminación de la jerarquia.
55
2.4. Transformación de relaciones
• Ejemplo:Cultivo Herbicida
Secano Regadio
Subvención Abastecimiento
nombrecomposición
precio
nombre
lugar
htrias
cantidad
Uso_comercial
clase_regadio
Ayuda
cantidad
organismo
empresa
coste
litros
(1,n)(1,n)
(1,1)
(0,1)(0,1)
(1,1) (1,n)
(0,n) (1,n)
tipo
56
2.4. Transformación de relaciones
• Eliminación del supertipo de entidad: se borra la superentidad transfiriendo todos sus atributos a cada uno de los subtipos, además de las relaciones en las que participaba la superentidad. El atributo calificador se puede eliminar. Si la relación jerárquica es exclusiva, los subtipos intervienen de forma parcial (cardinalidad mínima 0) en las relaciones transferidas desde el supertipo de entidad.
57
2.4. Transformación de relaciones
• Ejemplo:Herbicida
Secano Regadio
Subvención Abastecimiento
nombre
precio
composición
cantidad
uso_comercial clase_regadio
Ayuda
cantidad
organismo
empresa
coste
litros
(0,n)(0,n)
(1,1) (1,n)
(0,n) (1,n)
cantidad
(1,n) (1,n)
nombre
lugar
htrias
nombre
lugar
htrias
58
2.4. Transformación de relaciones
• Ejemplo: el esquema relacional sería el siguiente:Herbicida (nombre, composición, preu)Secano (nombre, lugar, htrias, uso_comercial)Regadío (nombre, lugar, htrias, clase_regadio)Subvención (ayuda#, organismo, cantidad, nombre_cultivo,
lugar)Abastecimiento (empresa, coste)Herb_Rega (nom_herb, nom_cult, lugar, cantidad)Herb_Seca (nom_herb, nom_cult, lugar, cantidad)Rega_Abas (nom_cult, lugar, empresa, litros)
59
2.4. Transformación de relaciones
• Eliminación del supertipo de entidad: sólo se utilizará esta norma cuando:– La relación jerárquica es exclusiva total.– El número de atributos del supertipo sea pequeño y no
existan muchas relaciones en las que participe el supertipo.
60
2.4. Transformación de relaciones
• Eliminación de los subtipos de entidad: se borran los tipos de entidad transfiriendo todos los atributos al supertipo, además de las relaciones en las que participaban los subtipos. Si la jerarquía es exclusiva, el supertipo participará de forma parcial (cardinalidad mínima 0) en las relaciones transferidas desde los subtipos. Si la jerarquía es inclusiva, el supertipo participará en las relaciones con las mismas cardinalidades que lo hacían los subtipos.
61
2.4. Transformación de relaciones
• Eliminación de los subtipos de entidad: el atributo calificador pasará a formar parte del supertipo de la siguiente forma:– Si la jerarquía es exclusiva no formará parte de la clave.– Si la jerarquía es inclusiva formará parte de la clave.– Si la jerarquía es parcial podrá tomar valores nulos.
62
2.4. Transformación de relaciones
• Ejemplo:
CultivoHerbicida
Subvención Abastecimiento
nombrecomposición
precio
nombre
lugar
htrias
cantidaduso_comercial
clase_regadio
Ayuda
cantidad
organismo
empresa
coste
litros
(1,n)
(1,n)
(0,n) (0,n)
tipo
(0,1) (0,n)
63
2.4. Transformación de relaciones
• Ejemplo: el esquema relacional sería el siguiente:Herbicida (nombre, composición, precio)Cultivo (nombre, lugar, tipo, htrias, uso_comercial,
clase_regadio)Subvención (ayuda, organismo, cantidad, nom_cult, lugar, S)Abastecimiento (empresa, coste)Abas_Cult (nom_cult, lugar, R, empresa, litros)Herb_Cult (nom_herb, nom_cult, lugar, tipo, cantidad)
64
2.4. Transformación de relaciones
• Eliminación de los subtipos de entidad: esta regla se puede utilizar en cualquiera de los cuatro tipos de relaciones jerárquicas.– Obtendremos un esquema más simple.– En el caso de relaciones exclusivas y/o parciales habrá
muchos posibles valores nulos para los atributos transferidos desde los subtipos de entidad.
65
2.4. Transformación de relaciones
• Eliminación de la jerarquía: transformamos la relación jerárquica en tantas relaciones uno a uno como subtipos estén presentes, manteniéndose todas las relaciones en las que participan tanto los subtipos como el supertipo. En las nuevas relaciones creadas, los subtipos participarán:– Con cardinalidad mínima 0 si la jerárquica es exclusiva.– Con cardinalidad mínima 0 o 1 si la jerárquica es inclusiva.
El supertipo participa con cardinalidades (1,1) en estas nuevas relaciones.
66
2.4. Transformación de relaciones
• Ejemplo:
CultivoHerbicida
Subvención Abastecimiento
nombrecomposición
precio
nombre
lugar
htrias
cantidad
uso_comercial clase_regadio
ayuda
cantidad
organismo
empresa
coste
litros
(1,n)
(1,n)
(0,n) (1,n)
tipo
Secano Regadío
(1,1) (1,1)
(0,1) (0,1)nombre nombre
lugar lugar
(1,1) (1,n)
67
2.4. Transformación de relaciones
• Ejemplo: el esquema relacional sería el siguiente:Herbicida (nombre, composición, precio)Cultivo (nombre, lugar, htrias, tipo)Secano (nombre, lugar, uso_comercial)Regadio (nombre, lugar, clase_regadio)Subvención (ayuda, organismo, cantidad, nom_cult, lugar)Abastecimiento (empresa, coste)Herb_Cult (nom_herb, nom_cult, lugar, cantidad)Abas_Cult (nom_cult, lugar, empresa, litros)
68
2.4. Transformación de relaciones
• Eliminación de la jerarquía: es la regla de aplicación más general.– Se puede utilizar en cualquiera de los cuatro tipos de
relaciones jerárquicas.– El esquema resultante preserva la representación de las
relaciones existentes entre el supertipo y los subtipos.– En el caso de relaciones exclusivas y/o parciales habrá
muchos posibles valores nulos para los atributos transferidos desde los subtipos de entidad.
69
2.5. Representación gráfica
• Grafos relacionales: hay líneas que enlazan las claves primarias con las claves secundarias para representar las relaciones:Existencias (tipo, modelo, n_almacen, cantidad)
Pieza (tipo, modelo, nombre)
Suministro (tipo, modelo, cod_empresa, precio)
Empresa (CIF, cod_empresa, nombre, dirección)
70
2.5. Representación gráfica
• Esquema relacional con Access:
71