UNIDAD 3:

EL MODELO RELACIONAL

UTN – FRRe
Gestión de Datos
Para Sistemas de Información
Modelo Relacional
 Edgar Frank Codd (1923-2003) - 1970
 12 reglas de Codd
 Normalización
 Álgebra Relacional

 Base matemática simple y bien definida

 Base de Datos Relacional: un conjunto de

relaciones.
¿Por qué el modelo relacional?
 Modelo mas ampliamente utilizado
 IBM, Oracle, Sybase, Informix, Microsoft, Open
Source
 Convive con “Legacy Systems”
 Modelo Jerarquicos/Red: Ej. IBM IMS
 Competidores mas recientes: Modelo orientado
a objetos.
 ObjectStore, Versant, Ontos (puros)
 Un modelo emergente (objeto-relacional): Oracle,
DB2, Informix, etc.
Definiciones
 Relación: consta de 2 partes
 Esquema de relación: especifica un nombre para la
relación, y un nombre y tipo para cada campo de la misma,
consiste en la lista de atributos de la relación.
 Ej.: Alumnos(ide: string, nombre: string, usuario: string NO
NULO, edad: int, nota: real)
 Instancia o ejemplar de relación: es una tabla, con filas
y columnas.
 Ej.:
CAMPOS (ATRIBUTOS, COLUMNAS)

Nombre de campos

ide nombre usuari edad nota

50000 David David@inf 19 6,6

TUPLAS 53666 Jiménez jumenez@inf 18 6,8

(REGISTROS, 52688 Sánchez sanchez@inf 18 6,4
FILAS)
53650 Sánchez sanchez@mat 19 7,6
53831 Martínez martinez@musica 11 3,6
53832 García grcia@musica 12 4,0
Definiciones
• Se puede decir que una relación es un conjunto de filas
o tuplas (donde todas las filas son distintas).

Comparación de la Terminología Relacional

Relación Tabla Archivo

Tupla Fila Registro

Atributo Columna Campo

Numero de
Grado Numero de Campos
Columnas
Numero de
Cardinalidad Numero de Filas
Registros
Ejemplo de Instancia

ide nombre usuari edad nota

50000 David David@inf 19 6,6
53666 Jiménez jumenez@inf 18 6,8
52688 Sánchez sanchez@inf 18 6,4

 Cardinalidad = 3, Grado = 5, todas las filas distintas

¿Deben ser todas las columnas de la relación
distintas?
Lenguajes de Consultas Relacionales

 La mayor fortaleza del modelo relacional:

soporta lenguajes de consulta potentes.
 Las consultas se pueden escribir en forma
casi intuitiva, y el SGBD es responsable
de la ejecución eficiente.
 La clave: semántica precisa para consultas
relacionales.
 Permite al optimizador reordenar
operaciones, y seguir asegurando que la
respuesta no cambiará.
SQL: Structures Query Languaje

 Desarrolado por IBM en los 70s

 Necesitó de un standard a partir del auge
de las base de datos relaciones.
 Standards:
 SQL-86
 SQL-89 (revisiones menores)
 SQL-92 (revisión mayor, standard actual)
 SQL-99 (extensiones)
 SQL-2003/2006 (XML)
 SQL-2008
SQL: Structures Query Languaje

 Para encontrar todos los estudiantes de mas de

18 años, podemos escribir:

SELECT * ide nombre usuario edad nota

FROM Alumnos A 53666 Jiménez jumenez@inf 18 6,8

WHERE A.edad = 18 52688 Sánchez sanchez@inf 18 6,4

 Para proyectar solo los nombres y usuarios,

reemplazar la 1ra linea por
SELECT A.nombre, A.usuario
Consultando múltiples relaciones
 ¿Qué hace la siguiente consulta?
SELECT A.nombre, M.ida
FROM Alumnos A, Matriculados M
WHERE A.ide = M.idalum AND M.nota = „SB‟
 Creando Relaciones con SQL
 Crear la relación Alumnos. Observe como se especifica el tipo
(dominio) de cada fila, y que esto se chequea por el DBMS cada
vez que una tupla es insertada o modificada.
CREATE TABLE Alumnos (ide CHAR(20),
nombre CHAR(30),
usuario CHAR(20),
edad INTEGER,
nota REAL)
 Como otro ejemplo, la tabla Matriculados contiene información
sobre los cursos que toman los alumnos.

CREATE TABLE Matriculados

(idalum CHAR(20),
ida CHAR(20),
nota CHAR(10))
Borrado y Modificación de Relaciones
DROP TABLE Alumnos

 Elimina la relación Estudiantes. La información

de esquema y las tuplas que contiene son
borradas.
ALTER TABLE Alumnos
ADD COLUMN primer_año: INTEGER
 Se altera el esquema Estudiantes agregando,
en este caso, un nuevo campo; cada tupla de la
instancia se extiende con un valor null en el
campo nuevo.
Agregando y Borrando Tuplas

 Se puede insertar una tupla usando:

INSERT
INTO Alumnos (ide, nombre, usuario, edad, nota)
VALUES (53688, „Sánchez‟, „sanchez@inf‟, 18, 6.4)

 Se pueden borrar todas las tuplas que

satisfagan una condición. (Ej. Nombre=„Sanchez‟)
DELETE
FROM Alumnos A
WHERE A.nombre = „Sánchez‟
Modificar Tuplas

 Se puede modificar los valores de las

columna de una fila ya existente, por ej.:
UPDATE Alumnos A
SET A.edad = A.edad + 1, A.nota = A.nota - 2
WHERE A.ide = 53688

 Se pueden modificar los valores de varias

filas existentes
UPDATE Alumnos A
SET A.nota = A.nota – 0.1
WHERE A.nota >= 6.6
Restricciones de Integridad (RIs)
 RI: Condición que debe ser verdadera para cada
instancia de la base de datos; ej.: Restricciones de
Dominio.
 Ris se especifican cuando se define el esquema.
 Ris se chequean cuando las relación son alteradas (insert,
delete, update, etc.).
 Una instancia “legal” de una relación dada es aquella
que satisface todas las Ris
 SGBD no debe permitir instancias “ilegales”
 La finalidad es que los datos almacenados sean mas
confiables y representen “la realidad” de una empresa.
 Impide ingreso erroneo de datos, borrados de tuplas que pueden
dejar inconsistenta la base de datos, etc.
Restricción de Clave Primaria
 Una restricción de clave es una declaración de que
cierto subconjunto mínimo de los campos de una relación
constituye un identificador único de cada tupla.
 Un campo (conjunto de campos) es una clave si y solo si:
1. No hay dos tuplas que puedan tener los mismos valores
en el/los campos claves.
2. Ningún subconjunto del conjunto de campos de una clave
es identificador único de una tupla, entonces
 Ej. ide es una clave de Alumnos. (¿Qué podemos decir
del campo nombre?). El conjunto {ide,nota} es una
superclave. ¿Existen claves candidatas?
 Si hay mas de 1 clave para la relación, una de ellas se
designa como primaria y las restantes son claves
candidatas.
 Claves Primarias y Candidatas
 Mediante la restricció UNIQUE se puede declarar que un
subconjunto de las columnas de una tabla constituye una
clave.
 Y con PRIMARY KEY se puede declarar que una de esas
claves es la clave principal. También muestra la manera
Aquí se indica que ide es la
enclave
que principal
se puedeydenominar
que la
CREATE TABLE Alumnos una restricciónde
combinación (CONSTRAINT
nombre y
(ide CHAR(20), nombre-restricción),
edad también es una así, si se
clave
nombre CHAR(30), viola
(dosesa restricción,
alumnos pueden se tener el
usuario CHAR(20), devuelve el nombre-restricción
mismo nombre o la misma
edad INTEGER, y edad,
así sepero
identifica
no lascual
doses el a
cosas
nota REAL, error.
la vez)
UNIQUE (nombre, edad),
CONSTRAINT ClaveAlumnos PRIMARY KEY (ide))
 Claves Foráneas (Integridad Referencial)
 Clave Fóranea o Externa: Conjunto de campos en una
relación que se usa para “referenciar” a una tupla en otra
relación. (Debe corresponder con una clave primaria de la
segunda relación.)
 Si se modifica una de las relaciones el SGBD debe
comprobar la otra.
Ej.: Dada
Para la relación
garantizar Matriculados
que solo se puedan matricular a las
asignaturas auténticos alumnos
CREATECREATE
TABLE TABLE Matriculados
Matriculados
(idalum (idalum
CHAR(20), CHAR(20),
ida idaCHAR(20), CHAR(20),
nota
nota CHAR(10), CHAR(10))
PRIMARY KEY (idalum, ida),
FOREIGN KEY (idalum) REFERENCES Alumnos)
Forzando la Integridad Referencial
 Considerar Alumnos y Matriculados; ida en Matriculados
es una clave foránea que referencia a Alumnos.
 ¿Qué debería hacerse si se inserta una tupla en
Matriculados con un ida que no existe en Alumnos?
 ¿Qué debería hacerse si se borra un alumno en la tabla
Alumnos?
 Borrar todos las tuplas de Matriculados que hagan referencia.
 Impedir el borrado de alumnos que estén matriculados en algún
curso.
 Modificar los ida’s borrados de la tabla Matriculados a un valor
por defecto.
 (Variante en SQL, reemplazar los ida’s por un valor especial
NULL, que denota vacío / inaplicable / desconocido)
Integridad Referencial en SQL/92
 SQL/92 soporta las 4
opciones de CREATE TABLE Matriculados
borrado/modificación (idalum CHAR(20),
anteriores. ida CHAR(20),
 Por defecto NO ACTION nota CHAR(10),
(rechazo) PRIMARY KEY (idalum, ida),
 CASCADE (borra todas FOREIGN KEY (idalum)
las tuplas que son REFERENCES Alumnos
referenciadas por la tupla ON DELETE CASCADE
borrada) ON UPDATE NO ACTION)
 SET NULL / DEFAULT
(modifica el campo calve
foráneo a un valor nulo o
por defecto.)
Implementando las restricciones
 Las RIs se basan en la semántica del mundo real y de
las reglas de negocio que queremos describir en el
modelo relacional.
 Podemos chequear una instancia para ver si alguna RI
fue violada, pero nunca podemos inferir que una RI es
cierta a partir de una instancia.
 Una RI es una declaración sobre todas las instancias posibles.
 Ej.: sabemos que nombre no es una clave, pero la afirmación
que ide es una clave nos lo da el escenario.
 Las restricciones de clave y clave foránea son las mas
comunes; pero se soportan otros tipos de restricciones
(Generales).
 Restricciones Generales
 Ej.: si necesitamos que la
edad de los estudiantes
este dentro de un rango CREATE TABLE Alumnos
adecuado de edades. (ide CHAR(20),
nombre CHAR(30),
 Las bases de datos usuario CHAR(20),
actuales soportan este tipo edad INTEGER,
de restricciones en la forma avanzada CHAR(10) NOT NULL,
de “restricciones a nivel de nota REAL,
tabla” o bien a “nivel de PRIMARY KEY (ide),
múltiples tablas” CHECK (edad >= 18 AND edad <= 30))
(assertions)
 Transacciones y Restricciones
 Supongamos que se exige que todos los alumnos tengan
una asignatura avanzada y que cada asignatura tenga un
alumno como mínimo.
CREATE TABLE Alumnos (ide CHAR(20),
nombre CHAR(30),
usuario CHAR(20),
edad INTEGER,
avanzada CHAR(10) NOT NULL,
nota REAL,
PRIMARY KEY (ide),
FOREIGN KEY (avanzada) REFERENCES Asignaturas (ida))

CREATE TABLE Asignaturas (ida CHAR(10),

nombrea CHAR(10),
creditos INTEGER,
alumno CHAR(20) NOT NULL,
PRIMARY KEY (ida),
FOREIGN KEY (alumno) REFERENCES Alumnos (ide))
 Transacciones y Restricciones

 Siempre que se inserte una tupla se debe comprobar que la

asignatura avanzada exista o el alumno exista.
 Pero, ¿cómo insertamos el primer alumno, o la primer asignatura?
 La única forma es DIFERIR la comprobación de la restricción.

SET CONSTRAINT Restriccion DEFERRED

 Las restricciones en modo diferido se comprueban en el momento

del completada la transacción (compromiso)
 El modo INMEDIATE hará que la restricción se compruebe al final
de la instrucción involucrada, en nuestro ejemplo INSERT
Del DER al Modelo Relacional

 Entidades a Tablas nombre

dni plaza

Empleados

CREATE TABLE Empleados (dni CHAR(10),

nombre CHAR(30),
plaza INTEGER,
PRIMARY KEY (dni))
Vínculos a Tablas
 Se deben incluir los atributos del vínculo
 Las claves de cada entidad participante (como claves foráneas).

 Este conjunto de atributos forman una superclave para la

nueva relación
 Todos los atributos descriptivos
Vínculos a Tablas

CREATE TABLE Trabaja_en2

(dni CHAR(10),
idd INTEGER,
direccion CHAR(20),
desde DATE,
PRIMARY KEY (dni, idd, direccion),
FOREIGN KEY (dni) REFERENCES Empleados,
FOREIGN KEY (direccion) REFERENCES Ubicaciones,
FOREIGN KEY (idd) REFERENCES Departamentos)
 Vínculos a Tablas

Obsérvese que hay que nombrar de

manera explícita el campo de
Empleados al que se hace referencia
porque el nombre el campo no
coincie con el nombre de los campos
que hacen la referencia.

CREATE TABLE Informa_a

(dni_supervisor CHAR(10),
dni_subordinado CHAR(10),
PRIMARY KEY (dni_supervisor, dni_subordinado),
FOREIGN KEY (dni_supervisor) REFERENCES Empleados (dni),
FOREIGN KEY (dni_subordinado) REFERENCES Empleados (dni))
 Repaso: Restricciones de Clave
Cada departamento tiene al menos un administrador, de acuerdo a la restricción
de clave en “Dirige”
Traducción de los conjuntos de relaciones con
Restricciones de Clave
Como cada departamento tiene, como máximo, un encargado, no pueden haber
dos tuplas que tengan el mismo valor de idd y no coincidan el valor de dni; por
ello es idd la clave de Dirige.
CREATE TABLE Dirige (dni CHAR(10),
idd INTEGER,
desde DATE,
PRIMARY KEY (idd),
FOREIGN KEY (dni) REFERENCES Empleados,
FOREIGN KEY (idd) REFERENCES Departamentos)
Otra alternativa es, para no crear tantas tablas diferentes, incluir la información
sobre el conjunto de relaciones en la tabla correspondiente al conjunto de
entidades con la clave, aprovechando la restricción de integridad.
CREATE TABLE Dept_Enc (idd INTEGER,
nombred CHAR(20),
presupuesto REAL,
dni CHAR(10),
desde DATE,
PRIMARY KEY (idd),
FOREIGN KEY (dni) REFERENCES Empleados)
Traducción de los conjuntos de relaciones con
Restricciones de Participación

Aquí existe una restricción de

participación que exige que
todos los departamentos
CREATE TABLE Dept_Enc tengan un encargado (y solo
(idd INTEGER, uno, debido a la restricción de
nombred CHAR(20),
clave)
presupuesto REAL,
dni CHAR(10) NOT NULL,
desde DATE,
PRIMARY KEY (idd),
FOREIGN KEY (dni) REFERENCES Empleados
ON DELETE NO ACTION)
Repaso: Entidades débiles

 Una entidad débil puede ser identificada solo si

consideramos la clave primaria de otra entidad (padre).
 La entidad padre o propietaria y la entidad débil de esta solo
puede participar en un vínculo 1 a muchos (1 del lado del
padre, muchos del lado de la entidad débil)
 La entidad débil debe tener participación total. Se conoce
como “Relación identificante”
Traducción de los conjuntos de
entidades débiles
 Las entidades débiles y las relaciones identificantes se
pueden traducir en una sola tabla:
 Cuando se borra una tupla de la entidad padre, todos las
tuplas de la entidad débil referenciadas también deben ser
borradas.

CREATE TABLE Poliza_Dep

(nombrep CHAR(20),
edad INTEGER,
costo REAL,
dni CHAR(10),
PRIMARY KEY (nombrep, dni),
FOREIGN KEY (dni) REFERENCES Empleados
ON DELETE CASCADE)
Repaso: Jerarquía de Clase
 Como en los lenguajes orientados a objetos los atributos se heredan.

 Restricciones de Solapamiento (Overlap):

 ¿Puede José ser un empleado por horas
asi como un empleado por contrato?

 Restricciones de Cobertura (Covering):

 ¿Tienen que pertenecer todas las
entidades a alguna de sus subclases?
 Jerarquía de Clases a Relaciones
 Aproximación general (siempre aplicable)
 3 entidades => 3 relaciones
Empleados, Empleados_Temp y Empleados_fijos
 Empleados: como cualquier entidad común
 Empleados_Temp: Se incluyen los atributos de sueldo_hora y horas_trabajadas.
También contiene los atributos de la clave de la superclase (dni en este caso), que
sirve de clave principal de Empleados_Temp, así como de clave externa que hace
referencia a la superclase Empleados. Idem para Empleados_fijos.
 Las consultas que involucran todos los empleados se resuelven fácilmente, y las
que involucran solo a jornalizados requiere una junta para obtener atributos
adicionales.
 Alternativa
(no es válida cuando hay empleados que no están en ninguna de estas categorías)
 2 entidades => 2 Relaciones
Empleados_Temp y Empleados_fijos
 Cada relación incluye todos los atributos de la misma, más los de Empleados
 Cada empleado debe pertenecer a una de estas dos clases en forma excluyente.
Traducción de los diagramas ER con agregación
Traducción de los diagramas ER con agregación

 Como ya se vió antes

Traducción de los diagramas ER con agregación

 Se crea una relación con los atributos:

 Los de la clave de Empleados (dni), los de Financia
(idd, idp) y los atributos descriptos en Controla (hasta)