Unidad 2 parte 6 Modelo Relacional I

Download Report

Transcript Unidad 2 parte 6 Modelo Relacional I

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.
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.
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.
id_cliente
nombre_cliente
calle_cliente
ciudad_cliente
Cliente
(1,n)
tiene
(1,n)
número_cuenta
saldo
Cuenta
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).
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.
Pelicula
título
año
duración
Tipo
Star Wars
1977
124
color
Mighty Ducks
1991
104
color
Wayne's World
1992
95
color
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
Castellón
964 284 440
964 284 420
O2
Cedre, 26
Villarreal
964 525 810
964 252 811
Grao
Plantilla
Enum
Nombre
Apellido
Dirección
Teléfono
Puesto
Fecha_nac
Salario
DNI
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
Onum
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)
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.
Atributo
Nombre del
Dominio
Descripción
Definición
Onum
NUM_OFICINA
Posibles valores de
número de oficina
3 digitos; rango O1O99
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
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.
Enteros
Reales
Tipo
Integer (Entero)
Word
(Palabra)
ShortInt (Entero
corto)
Byte
LongInt (Entero
largo)
Rango de valores
que acepta
Tipo
Rango de valores que
acepta
-32,768 a 32,767
Real
2.9E-39 a 1.7E38
0 a 65535
Single
1.5E-45 a 3.4E38
-128 a 127
Double
5.0E-324 a 1.7E308
0 a 255
-2,147,483,648 a
2,147,483,648
Extended
Comp
1.9E-4851 a 1.1E4932
-9.2E18 a 9.2E18
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 hora
Moneda: introducir datos en formato número y con el signo monetario
Autonumérico: se numera automáticamente el contenido
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.
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.
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),
(Teléfono:964 201 240), (Fax:964 201 340)}.
(Población:Castellón),
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).
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:
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.
id_cliente
nombre_cliente
calle_cliente
ciudad_cliente
Cliente
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 está el atributo
multivaluado mas el nombre del atributo multivaluado.
id_cliente
nombre_cliente
direccion_cliente
telefono_cliente
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:
•Eliminar el atributo compuesto considerando todos sus
componentes como atributos individuales.
calle
numero
id_cliente
nombre_cliente
direccion_cliente
telefono_cliente
Cliente
ciudad
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
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
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.
Código
Nombre
Nr_hojas
Editorial
Libro
(1,1)
I
ti ene
(1,N)
E je mplar
Ejemplar
Número
Est ado
Posición
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.
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.
id_cliente
nombre_cliente
calle_cliente
ciudad_cliente
Cliente
(1,n)
tiene
(1,n)
número_cuenta
saldo
Cuenta
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.
privilegio
id_cliente
nombre_cliente
calle_cliente
ciudad_cliente
Cliente
(1,n)
tiene
(1,n)
número_cuenta
saldo
Cuenta
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.
nombre_ciudad
habitantes_ciudad
Ciudad
(1,n)
esta
(1,1)
Region
numero_region
nombre_region
habitantes_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.
fecha
código
nombre
direccion
Proveedor
(1,1)
(1,n)
suministra
Producto
código
nombre
precio_unitario
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:
tasa_descuento
numero_pedido
fecha
nombre_vendedor
Pedido
(1,n)
(0,1)
suministra
Vendedor
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.
fono
•Si el número relativo de esos pedidos es grande, y no se
puede admitir valores nulos, una mejor alternativa:
tasa_descuento
numero_pedido
fecha
nombre_vendedor
Pedido
(1,n)
(0,1)
suministra
Vendedor
fono
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:
patente_auto
marca_auto
Auto
(0,n)
es_prop
(1,1)
Persona
CI_persona
nombre_persona
direccion_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: 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
•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.
codigo_empresa
direccion_empresa
CI_director
Empresa
(1,1)
(1,1)
tiene
Director
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
•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.
codigo_empleado
nombre_empleado
codigo_depto
Empleado
(1,1)
responsabl
e
(0,1)
Depto
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.
•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.
fecha
CI_persona
nombre_persona
Persona
(0,1)
(0,1)
posee
codigo_animal
nombre_animal
Animal
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.
•Relaciones reflexivas
Para 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.
apadrina
(1,n)
CI_persona
nombre_persona
Persona
(1,1)
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.
• 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).
apadrina
(1,n)
CI_persona
nombre_persona
Persona
(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)
apadrina
(0,n)
CI_persona
nombre_persona
Persona
(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.
apadrina
(0,n)
CI_persona
nombre_persona
Persona
(0,1)
•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
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:
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.
Estudiante (matricula_estudiante, nombre_estudiante,
carrera, titulo_tesis, tipo) PK: matricula_estudiante
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.
Ingeniero (rut_empleado, nombre_empleado,
especialidad) PK: rut_empleado
Gerente (rut_empleado, nombre_empleado,
nr_supervisados) PK: rut_empleado
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
Es conveniente si la mayoría de las operaciones son
estrictamente locales respecto a la superentidad o a una
de las subentidades.
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