Modelo Relacional

1. BASE DE DATOS
(IV)
Prof. Omar A. Rivera Zarate

2. MODELO RELACIONAL

3. MODELO RELACIONAL
Edgar Frank Codd a finales definió las
bases del modelo relacional a finales de los
60.Trabajaba para IBM empresa que tardó
un poco en implementar sus bases. Pocos
años después el modelo se empezó a
implementar cada vez más, hasta ser el
modelo de bases de datos más popular.

4. OBJETIVOS DEL MODELO
 Independencia física. La forma de almacenar los datos,
no debe influir en su manipulación lógica
 Independencia lógica. Las aplicaciones que utilizan la
base de datos no deben ser modificadas por que se
modifiquen elementos de la base de datos.
 Flexibilidad. La base de datos ofrece fácilmente distintas
vistas en función de los usuarios y aplicaciones.
 Uniformidad. Las estructuras lógicas siempre tienen una
única forma conceptual (las tablas)
 Sencillez.

5. EVOLUCION DEL MODELO
Año Hecho
1970 Codd publica las bases del modelo relacional
1971-72 Primeros desarrollos teóricos
1973-78 Primeros prototipos
1978 Aparece el lenguaje QBE
1979 Aparece Oracle
1980 Aparece Ingres
1981 Aparece SQL
1982 Aparece DB2
1986 ANSI normaliza el SQL (SQL/ANSI)
1987 SQL de ISO
1990 Versión dos del modelo relacional (RM/V2)
1992 SQL 92
1998 SQL 3

6. TABLAS
Las bases de datos relacionales se basan en el
uso de tablas (también se las llama relaciones).
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 (se
le llama también atributo), nombre, dni, 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).

7. TABLAS

8. TERMINOLOGIA RELACIONAL
 Tupla. Cada fila de la tabla (cada
ejemplar que la tabla representa)
 Atributo. Cada columna de la tabla
 Grado. Número de atributos de la tabla
 Cardinalidad. Número de tuplas de una
tabla
 Dominio. Conjunto válido de valores
representables por un atributo.

9. TIPOS DE TABLAS
Persistentes. Sólo pueden ser borradas por los usuarios:
 Base. Independientes, se crean indicando su estructura y sus
ejemplares.
 Vistas. Son tablas que sólo almacenan una definición de
consulta, resultado de la cual se produce una tabla cuyos datos
proceden de las bases o de otras vistas e instantáneas. Si los
datos de las tablas base cambian, los de la vista que utiliza
esos datos también cambia.
 Instantáneas. Son vistas (creadas de la misma forma) que sí
que almacenan los datos que muestra, además de la consulta
que dio lugar a esa vista. Sólo modifican su resultado
(actualizan los datos) siendo refrescadas por el sistema cada
cierto tiempo.
Temporales. Son tablas que se eliminan
automáticamente por el sistema. Pueden ser de
cualquiera de los tipos anterior.

10. DOMINIOS
Los dominios suponen una gran mejora en este
modelo ya que permiten especificar los posibles
valores válidos para un atributo. Cada dominio
incorpora su nombre y una definición del mismo.
Ejemplos de dominio:
 Dirección: 50 caracteres
 Nacionalidad: Español, Francés, Italiano,...
Los dominios pueden ser también compuestos a
partir de otros (año, mes y día = fecha)

11. CLAVES
Clave candidata
Conjunto de atributos de una tabla que
identifican unívocamente cada tupla de la tabla.
Clave primaria
Clave candidata que se escoge como
identificador de las tuplas.
Clave alternativa
Cualquier clave candidata que no sea primaria
Clave externa o secundaria
Atributo de una tabla relacionado con una clave
de otra tabla.

12. VALORES NULOS
Los valores nulos indican contenidos de atributos
que no tienen ningún valor. En claves secundarias
indican que el registro actual no está relacionado
con ninguno. En otros atributos indica que no se
puede rellenar ese valor por la razón que sea.
Las bases de datos relacionales admiten utilizar
ese valor en todo tipo de operaciones. Eso
significa definir un tercer valor en la lógica.
Además de el valor verdadero o falso, existe el
valor para los nulos.

13. LOGICA DEL VALOR NULO
verdadero Y (AND) nulo da como
resultado, nulo
falso Y (AND) nulo da como resultado,
falso
verdadero O (OR) nulo da como
resultado, verdadero
falso O nulo da como resultado nulo
la negación de nulo, da como resultado
nulo

14. RESTRICCIONES
Se trata de unas condiciones de obligado
cumplimiento por los datos de la base de
datos.
Las hay de varios tipos.
 Inherentes
 Semánticas

15. RESTRICCIONES INHERENTES
Son aquellas que no son determinadas por los
usuarios, sino que son definidas por el hecho de
que la base de datos sea relacional.
Por ejemplo:
 No puede haber dos tuplas iguales
 El orden de las tuplas no importa
 El orden de los atributos no importa
 Cada atributo sólo puede tomar un valor en
el dominio en el que está inscrito

16. RESTRICCIONES SEMANTICAS
El modelo relacional permite a los usuario incorporar
restricciones personales a los datos. Las principales son:
 Clave primaria. Hace que los atributos marcados como
clave primaria no puedan repetir valores.
 Unicidad. Impide que los valores de los atributos
marcados de esa forma, puedan repetirse.
 Obligatoriedad. Prohíbe que el atributo marcado de esta
forma no tenga ningún valor
 Integridad referencial. Prohíbe colocar valores en una
clave externa que no estén reflejados en la tabla donde ese
atributo es clave primaria.
 Regla de validación. Condición que debe de cumplir un
dato concreto para que sea actualizado.

17. LAS 12 REGLAS DE CODD
Preocupado por los productos que decían
ser sistemas gestores de bases de datos
relacionales (RDBMS) sin serlo, Codd
publica las 12 reglas que debe cumplir todo
DBMS para ser considerado relacional.
Estas reglas en la práctica las cumplen
pocos sistemas relacionales.

18. LAS 12 REGLAS DE CODD
1.Información. Toda la información de la base de datos
debe estar representada explícitamente en el esquema
lógico. Es decir, todos los datos están en las tablas.
2.Acceso garantizado. Todo dato es accesible sabiendo el
valor de su clave y el nombre de la columna o atributo
que contiene el dato.
3.Tratamiento sistemático de los valores nulos. El
DBMS debe permitir el tratamiento adecuado de estos
valores.
4.Catálogo en línea basado en el modelo relacional. Los
metadatos deben de ser accesibles usando un esquema
relacional.

19. LAS 12 REGLAS DE CODD
5.Sublenguaje de datos completo. Al menos debe de
existir un lenguaje que permita el manejo completo de la
base de datos. Este lenguaje, por lo tanto, debe permitir
realizar cualquier operación.
6.Actualización de vistas. El DBMS debe encargarse de
que las vistas muestren la última información
7.Inserciones, modificaciones y eliminaciones de dato
nivel. Cualquier operación de modificación debe actuar
sobre conjuntos de filas, nunca deben actuar registro a
registro.
8.Independencia física. Los datos deben de ser
accesibles desde la lógica de la base de datos aún
cuando se modifique el almacenamiento.

20. LAS 12 REGLAS DE CODD
9.Independencia lógica. Los programas no deben verse
afectados por cambios en las tablas
10.Independencia de integridad. Las reglas de integridad
deben almacenarse en la base de datos (en el diccionario
de datos), no en los programas de aplicación.
11.Independencia de la distribución. El sublenguaje de
datos debe permitir que sus instrucciones funciones
igualmente en una base de datos distribuida que en una
que no lo es.
12.No subversión. Si el DBMS posee un lenguaje que
permite el recorrido registro a registro, éste no puede
utilizarse para incumplir las reglas relacionales.

21. PASO DEL ESQUEMA E/R AL
MODELO RELACIONAL
TRANSFORMACION DE ENTIDADES FUERTES
En principio las entidades fuertes del modelo.
Entidad Relación son transformados al modelo
relacional siguiendo estas instrucciones:
Entidades. Las entidades pasan a ser tablas
Atributos. Los atributos pasan a ser columnas.
Identificadores principales. Pasan a ser
claves primarias
Identificadores candidatos. Pasan a ser
claves candidatas.

22. PASO DEL ESQUEMA E/R AL
MODELO RELACIONAL

23. TRANSFORMACION DE
RELACIONES
RELACION VARIOS A VARIOS
En las relaciones varios a varios, la
relación se transforma en una tabla cuyos
atributos son: los atributos de la relación y
las claves de las entidades relacionadas
(que pasarán a ser claves externas). La
clave de la tabla la forman todas las
claves externas:

24. TRANSFORMACION DE
RELACIONES
RELACION VARIOS A VARIOS

25. TRANSFORMACION DE
RELACIONES
RELACIONES 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 todas las
claves externas:

26. TRANSFORMACION DE
RELACIONES
RELACIONES DE ORDEN N

27. TRANSFORMACION DE
RELACIONES
RELACIONES DE UNO A VARIOS Y DE
UNO A UNO
Las relaciones binarios de tipo uno a
varios no requieren ser transformadas en
una tabla en el modelo relacional. En su
lugar la tabla del lado varios (tabla
relacionada) incluye como clave externa1
el identificador de la entidad del lado uno
(tabla principal):

28. TRANSFORMACION DE
RELACIONES
RELACIONES DE UNO A VARIOS Y DE
UNO A UNO

29. TRANSFORMACION DE
RELACIONES
Así en el dibujo, el identificador2 en la tabla
Entidad1 pasa a ser una clave externa. En el
caso de que el número mínimo de la relación
sea de cero (puede haber ejemplares de la
entidad uno sin relacionar), se deberá permitir
valores nulos en la clave externa. Así en el
dibujo, el identificador2 en la tabla Entidad1
pasa a ser una clave externa. En el caso de que
el número mínimo de la relación sea de cero
(puede haber ejemplares de la entidad uno sin
relacionar), se deberá permitir valores nulos en
la clave externa

30. TRANSFORMACION DE
RELACIONES
RELACIONES RECURSIVAS
Las relaciones recursivas se tratan de la
misma forma que las otras, sólo que un
mismo atributo puede figurar dos veces
en una tabla como resultado de la
transformación:

31. TRANSFORMACION DE
RELACIONES
RELACIONES RECURSIVAS

32. TRANSFORMACION DE
RELACIONES
RELACIONES RECURSIVAS

33. TRANSFORMACION DE
RELACIONES
ENTIDADES DEBILES
Toda entidad débil incorpora una relación
implícita con una entidad fuerte. Esta relación
no necesita incorporarse como tabla en el
modelo relacional. Sí se necesita incorporar la
clave de la entidad fuerte como clave externa en
la entidad débil. Es más, normalmente esa clave
externa forma parte de la clave principal de la
tabla que representa a la entidad débil.

34. TRANSFORMACION DE
RELACIONES
ENTIDADES DEBILES

35. TRANSFORMACION DE
RELACIONES
ENTIDADES DEBILES
En ocasiones el identificador de la entidad
débil es suficiente para identificar los
ejemplares de dicha entidad, entonces
ese identificador quedaría como clave
principal, pero el identificador de la
entidad fuerte seguiría figurando como
clave externa en la entidad débil.