1. 1
UNIVERSIDAD NACIONAL DEL CALLAO -
FIIS
MODELO RELACIONAL
BASE DE DATOS
Clase 3
Profesora: Dra. Bertila García Díaz
2. 2
MODELO RELACIONAL -
El modelo Relacional, fue presentado por E.F. Codd,
quién lo desarrolló en IBM- San José (California) en
el año 1970.
Una tabla bidimensional mediante la cual se
representan tanto los objetos como las relaciones
existentes en el dominio del problema.
Se basa en que la representación física deberá
satisfacer y representar, de alguna forma, las
relaciones y restricciones lógicas del esquema
relacional.
Presenta la Base de Datos como una colección de
relaciones, cuyo contenido varía en el tiempo.
3. 3
MODELO RELACIONAL -
Con respecto a la parte dinámica del modelo, se
propone un conjunto de operadores que se aplican a
las relaciones (Algebra relacional y cálculo
relacional)
La teoría de normalización, cuyas 3 primeras formas
normales fueron introducidas por Codd, elimina
dependencias entre atributos que originan anomalías
en la actualización de la base de datos.
A partir de 1980, el modelo relacional ha tenido un
auge espectacular, gracias al desarrollo tecnológico,
han ido apareciendo productos comerciales que
corren en las más diversas plataformas con
rendimientos aceptables: ORACLE, SQL, DB2,
SYBASE
4. 4
PROPIEDADES
No existen tuplas repetidas.
Corolario: Siempre existe una clave primaria
Las tuplas no están ordenadas de arriba hacia abajo.
Los atributos no están ordenados de izquierda a
derecha)
Todos los valores de los atributos son atómicos
Los atributos multivaluados se deben representar
con relaciones individuales.
Las relaciones no contienen grupos repetitivos.
5. 5
TIPOS DE RELACIONES
Relación base
Vistas o relaciones virtuales
Instantáneas (snapshot)
Temporales (base temporales, vistas temporales,
instantáneas temporales)
Nota.- las relaciones base, las vistas y las
instantáneas son permanentes, solo se destruyen
como resultado de una acción directa explícita.
6. 6
TIPOS DE RELACIONES
Relación base.- Representan entidades o relaciones
entre entidades.
Vista.- se define en base a otra relación base. Son
relaciones derivadas que se definen dando un
nombre a una expresión de consulta. Son relaciones
virtuales, porque no tienen datos almacenados.
Ej: create tabla empleado
(cod_emp integer.
nombre varchar(50),
salario decimal(10,2) )
create viewjunior as select cod_emp
from empleado
where salario < 2000
7. 7
7Instantánea.- guarda información sobre un
conjunto
de la Base de Datos, hasta cierta condición y tiempo
Ej: en planilla, cuánto ganaba hasta ayer, ya que hoy día
la Base de Datos se actualizó
No se actualizan cuando cambian los datos, pero se
refrescan.
Temporales.- desaparecen de la Base de Datos en
un cierto momento sin necesidad de una acción de
borrado específica. Ej: al terminar una sesión.
Podría ser una vista o una instantánea.
8. 8
ASPECTOS
El Modelo Relacional se le puede estudiar a
través de 3 aspectos:
-Estructura
-Integridad
-Manipulación
9. 9
POR SU ESTRUCTURA
Por su estructura se define al Dominio como la base
a partir de la cuál se construyen las relaciones,
compuestas a su vez de una cabecera (esquema) y
un cuerpo (ó extensión) de tuplas, así como de una
clave primaria.
Un esquema de relación R, denotado por
R(A1,A2,..An) se compone de un nombre de relación
R y una lista de atributos A1,A2,..An.
Ej: ESTUDIANTE(Nombre, NSS, TelPârticular, Dirección.Edad, Prom).
Los dominios son estáticos, las relaciones dinámicas
(el contenido cambia en el tiempo)
10. 10
POR SU ESTRUCTURA
DEFINICIÓN DE RELACIÓN
Dada una serie de conjuntos D1,D2,...Dn, se
dice que R es una relación entre estos n
conjuntos si es un conjunto de n tuplas no
ordenadas (d1,d2,..dn) tales que d1 € D1, d2 €
D2,...dn € Dn. A los conjuntos D1,D2,...DN se
les denomina dominios de R y el valor n es el
grado de la relación R
11. 11
Conceptos y equivalencias:
Relación: tabla
Tupla: Fila de la Tabla
Cardinalidad: # de tuplas de una relación
Grado: # de atributos de una relación
Dominio: Colección de valores de un atributo
Atributo: Columna de la tabla
Ej: codAg activo ciudad
1 500,000 Lima
2 300,000 Ica
Relación:AGENCIA Cardinalidad = 2 Grado = 3
Dominio de ciudad = Lima, Ica, Arequipa, Tacna....
Atributo = codAg, activo, ciudad
12. 12
POR SU INTEGRIDAD
Se la puede ver como las propiedades que se
encuentran en las definiciones de:
- Reglas de Entidad: unicidad, minimalidad
- Reglas de Integridad Referencial
- Reglas de Integridad de dominio
13. 13
POR SU MANIPULACIÓN
Se le puede ver como las operaciones que se
ejecutan: El Algebra Relacional, el Cálculo
Relacional.
14. 14
POR SU INTEGRIDAD
La Unicidad y la Minimalidad son 2 principios
básicos asociados a la integridad de entidad.
La unicidad: En cualquier momento no existen dos
tuplas en R (relación) con el mismo valor de clave
K.
La minimalidad: Si la clave K es compuesta, no
será posible eliminar ningún componente de K sin
destruir la propiedad de unicidad.
Debe haber la menor cantidad de campos en la clave
primaria
15. 15
POR SU INTEGRIDAD
Regla de integridad de entidades: Ningún
componente de la clave primaria (PK) de una
relación base puede aceptar nulos (NULL) que
significa información faltante, desconocida.
Regla de integridad referencial: La clave foránea
(FK) es un atributo de una relación R2, cuyos
valores deben concordar con los de la clave primaria
de alguna relación R1, con la cual existe un vínculo.
Ej: Agencia (Referida) Depósito (Referencial)
CodAg(PK) CodAg(FK)
01 05
02
03
R1 no concuerda R2
16. 16
POR SU INTEGRIDAD
Regla de integridad referencial: con el
término “valores ajenos sin concordancia”
queremos decir aquí un valor no nulo de
clave ajena para el cual no existe un valor
concordante de la clave primaria en la
relación objetivo pertinente.
17. 17
Regla de integridad referencial.-
garantiza que la base de datos no incluya valores
no válidos de una clave foránea.
R2(referencial) R1(Relación referida)
Relación Referencial.- es la relación que
contiene la clave foránea (FK).
Relación Referida.- es la relación que contiene la
clave primaria (PK).
La clave foránea y primaria deben definirse
sobre el mismo dominio.
si B hace referencia a A entonces A debe existir.
18. 18
Reglas para claves foráneas a nivel operaciones
:
El aceptar valores nulos por parte d’la clave foránea,
depende de las políticas vigentes del negocio o de la
empresa, que se reflejan en el modelo de datos.
Qué puede ocurrir cuando se intenta eliminar el
objeto de una referencia de clave foránea DELETE
Restricted.- se elimina cuando no existen tuplas con
este valor en la relación que contiene la clave ajena.
Cascade.- se propaga en cascada eliminando sus
dependientes.
Nullifies.- Solo se asignan valores nulos a todos los
dependientes y luego se elimina el padre, sólo es
posible cuando el atributo que es clave ajena admite
valores nulos.
19. 19
POR SU INTEGRIDAD
Reglas para claves foráneas a nivel operaciones:
Ej:Eliminar la tupla TRABAJA_EN con
NSSE=‘999887777’ y NUMP = 10.
- Esta eliminación es aceptable.
Eliminar la tupla EMPLEADO con NSS =
‘999887777’
Esta eliminación no es aceptable porque 2 tuplas
de TRABAJA_EN hacen referencia a esta tupla.
Eliminar la tupla EMPLEADO con NSS =
‘333445555’
Esta eliminación no es aceptable porque tuplas de
las relaciones EMPLEADO, DEPARTAMENTO,
TRABAJA_EN y DEPENDIENTE hace referencia
a la tupla en cuestión
20. 20
POR SU INTEGRIDAD
Reglas para claves foráneas a nivel operaciones:
Qué puede ocurrir cuando se intenta modificar la
clave primaria del objetivo de una referencia de
clave foránea (operación UPDATE):
Restricted: Restringida en el caso de que exista
dependientes. No es permitida el cambio de clave
primaria.
Cascade: Se propaga en cascada la modificación.
Nullifies: Se asignan valore nulos a los dependientes
y luego se modifica la relación padre.
sólo es posible cuando el atributo que es clave ajena
admite valores nulos.
21. 21
POR SU INTEGRIDAD
Reglas para claves foráneas a nivel operaciones:
Ej: Modificar el SALARIO de la tupla
EMPLEADO con NSS = ‘999887777’
cambiándolo a 28000
aceptable.
Modificar el ND de la tupla EMPLEADO con
NSS = ‘99988777’ cambiándolo a 1.
aceptable.
Modificar el ND de la tupla EMPLEADO con
NSS = ‘99988777’ cambiándolo a 7.
inaceptable, porque viola la integridad referencial.
22. 22
POR SU INTEGRIDAD
CONCLUSIÓN
Por tanto, para cada clave ajena incluida en el
diseño, el diseñador de la Base de Datos deberá
especificar, no sólo la clave ajena y la relación
objetivo a la cual hace referencia esa clave ajena,
sino también las respuestas a :
1.- Puede aceptar nulos una clave ajena?
2.- Qué sucede si elimino la clave primaria del
objetivo de una referencia de clave ajena?
3.- Qué sucede si modifico la clave primaria del
objetivo de una referencia de clave ajena?
23. 23
OTRAS RESTRICCIONES
Existen otras restricciones que podríamos llamar de
rechazo, las cuales deben ser verificadas en toda
operación de actualización.
Verificación (CHECK).- comprueba si el predicado
es cierto o falso y, en el segundo caso, rechaza la
operación. Se define sobre un único elemento.
Ej: Use ejemplo
go
alter table RepVentas
add constraint ck_rv_100
check(num_empl > 100)
go
24. 24
OTRAS RESTRICCIONES
Aserción (ASSERTION).- actúa igual que el
CHECK, pero puede afectar a varios elementos
( 2 relaciones distintas)
Ej: No hay ningún empleado que trabaje en el
Departamento de contabilidad que gane más de
3,000 soles.
Disparadores (TRIGGER).- son procedimentales
, el usuario escribe el procedimiento que ha de
aplicarse en caso de que se cumpla la condición.
Ej: Un disparador que “informará al administrador
de la BD cuando haya un empleado que gane más
de $1000. Y que trabaje en el Dpto de Marketing.