Base de Datos (75.15 - 95.

05)
Resumen

Esta obra está bajo una Licencia Creative Commons

fiuba-apuntes.github.io
Atribución-NoComercial-CompartirIgual 4.0 Internacional.

Última actualización: 16/12/2016

LICENCIA
Este es un resumen (y no un sustituto) de la licencia. Este resumen destaca sólo algunas de las
características clave y los términos de la licencia real. No es una licencia y no tiene valor legal. Usted
debe revisar cuidadosamente todos los términos y condiciones de la licencia actual antes de usar el
material licenciado.

Usted es libre para:

Compartir — copiar y redistribuir el material en cualquier medio o formato

Adaptar — remezclar, transformar y crear a partir del material

El licenciante no puede revocar estas libertades en tanto usted siga los términos de la licencia

Bajo los siguientes términos:

Atribución — Debe reconocer adecuadamente la autoría, proporcionar un enlace a la licencia
e indicar si se han realizado cambios. Puede hacerlo de cualquier manera razonable, pero no de
una manera que sugiera que tiene el apoyo del licenciador o lo recibe por el uso que hace.

NoComercial — Usted no puede hacer uso del material con fines comerciales.

CompartirIgual — Si usted mezcla, transforma o crea nuevo material a partir de esta obra,
usted podrá distribuir su contribución siempre que utilice la misma licencia que la obra original.

No hay restricciones adicionales — Usted no puede aplicar términos legales ni medidas tecnológicas que
restrinjan legalmente a otros hacer cualquier uso permitido por la licencia.

Aviso:
Usted no tiene que cumplir con la licencia para los materiales en el dominio público o cuando su uso esté
permitido por una excepción o limitación aplicable.

No se entregan garantías. La licencia podría no entregarle todos los permisos que necesita para el uso que
tenga previsto. Por ejemplo, otros derechos como relativos a publicidad, privacidad, o derechos morales pueden
limitar la forma en que utilice el material.
ÍNDICE

Índice
Acerca del proyecto 4

I Introducción a las Bases de Datos 5

1. Modelo de datos 5

2. BDs y SGBDs 5
2.1. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. ¿Por qué una base de datos y no un sistema de archivo? . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Diseño de una base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Modelos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Operaciones en una base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Modelos de bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Modelo Entidad-Interrelación (E-R) 10

3.1. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Interrelaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Tipos de interrelaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. Restricciones de participación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Restricciones de cardinalidad de correspondencia . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. Restricciones de dependencia existencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4. Restricciones de identificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Diagramas E-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5. Cuestiones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Reducción de un esquema E-R a un modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . 17

4. Modelo Relacional 18
4.1. Estructura del modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Restricciones del modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Operaciones del modelo relacional: álgebra relacional . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. Operadores básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2. Operadores secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Operadores extendidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5. Actualizaciones a bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.1. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.2. Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6. Vistas (views) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5. Cálculo relacional 24

6. Lenguajes de consulta 24

7. Integridad y seguridad 24
7.1. Restricciones de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Restricciones de integridad referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.1. Acciones referenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Seguridad y autorizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8. Triggers 25

II Diseño de bases de datos 26

Página 1 de 75 Base de Datos (75.15 - 95.05) - Resumen

 ÍNDICE

9. Dependencias funcionales 26
9.1. Axiomas de Armstrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Clausura y superclaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3. Cubrimiento minimal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

10.Primera forma normal (1FN) 30

11.Descomposición de una relación 30

11.1. Descomposición SPI en 2 relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.2. Descomposición SPI en más de 2 relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

12.Segunda forma normal (2FN) 33

13.Forma normal Boyce-Codd (FNBC) 33

14.Tercera forma normal (3FN) 34

15.Dependencias multivaluadas 36
15.1. Propiedades de las DMVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.2. Preservación de dependencias multivaluadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.3. Base minimal de Dependencias e Implicación de DMVs . . . . . . . . . . . . . . . . . . . . . . . . 38

16.Cuarta forma normal (4FN) 39

16.1. Descomposición SPI en 2 relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.2. Descomposición SPI en más de 2 relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

17.Dependencias de junta 40
17.1. Dependencias de junta embebidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

18.Quinta forma normal (5FN) 41

18.1. Implicación de dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

III SQL 44
19.DDL 44
19.1. Tipos de dominios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
19.2. Create table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
19.3. Drop table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
19.4. Alter table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

20.DML 45
20.1. Consultas anidadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
20.2. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
20.3. Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
20.4. Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

IV Procesamiento de Consultas 49
21.Índices 50
21.1. Estructuras de índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

22.Formas de realizar consultas 51

22.1. Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

23.Algoritmos 52
23.1. Selección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
23.2. Junta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Base de Datos (75.15 - 95.05) - Resumen Página 2 de 75

ÍNDICE

24.Evaluación de expresiones 54

25.Optimización de consultas 54
25.1. Reglas de equivalencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
25.2. Heurísticas de optimización de consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

26.Estimación de tamaño de consultas 55

26.1. Cálculo de juntas con histogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

V Control de Concurrencia 58
27.Transacciones 58

28.Problemas de concurrencia 59
28.1. Atributos de una transacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

29.Schedules de transacciones 61

30.Protocolos de Control de Concurrencia: Protocolo de Locking 62

30.1. Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
30.1.1. Tipos de locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
30.1.2. Problemas con el uso de locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
30.2. Lock de update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
30.3. Matriz de compatibilidad de locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
30.4. Lock table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
30.5. Protocolo de dos fases (two-phase locking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
30.6. Protocolo de árbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

VI Técnicas de Recuperación 67
31.Necesidad de Recuperación 67

32.Archivo de Log 67
32.1. Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
32.1.1. Checkpoints bloqueantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
32.1.2. Checkpoints no bloqueantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

33.Protocolos de Recuperación 69
33.1. Deferred update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
33.2. Immediate update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
33.2.1. UNDO/REDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
33.2.2. UNDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Colaboradores 74

Historial de cambios 75

Página 3 de 75 Base de Datos (75.15 - 95.05) - Resumen

 ACERCA DEL PROYECTO

Acerca del proyecto

FIUBA Apuntes nació con el objetivo de ofrecer en formato digital los apuntes de las materias que andan
rondando por los pasillos de FIUBA y que los mismos sean fácilmente corregidos y actualizados.

Cualquier persona es libre de usarlos, corregirlos y mejorarlos.

Encontrarás más información acerca del proyecto o más apuntes en fiuba-apuntes.github.io.

¿Por qué usamos LaTeX?

LaTeX es un sistema de composición de textos que genera documentos con alta calidad tipográfica, posi-
bilidad de representación de ecuaciones y fórmulas matemáticas. Su enfoque es centrarse exclusivamente en el
contenido sin tener que preocuparse demasiado en el formato.

LaTeX es libre, por lo que existen multitud de utilidades y herramientas para su uso, se dispone de mucha
documentación que ayuda al enriquecimiento del estilo final del documento sin demasiado esfuerzo.

Esta herramienta es muy utilizado en el ámbito científico, para la publicación de papers, tesis u otros docu-
mentos. Incluso, en FIUBA, es utilizado para crear los enunciados de exámenes y apuntes oficiales de algunos
cursos.

¿Por qué usamos Git?

Git es un software de control de versiones de archivos de código fuente desde el cual cualquiera puede obtener
una copia de un repositorio, poder realizar aportes tanto realizando commits o como realizando forks para ser
unidos al repositorio principal.

Su uso es relativamente sencillo y su filosofía colaborativa permite que se sumen colaboradores a un proyecto
fácilmente.

GitHub es una plataforma que, además de ofrecer los repositorios git, ofrece funcionalidades adicionales muy
interesantes como gestor de reporte de errores.

Base de Datos (75.15 - 95.05) - Resumen Página 4 de 75

Parte I
Introducción a las Bases de Datos
1. Modelo de datos
Un fenómeno o idea usualmente refiere a un objeto y a algún aspecto del objeto, el cual captura un deter-
minado valor en un cierto momento.

Dato tupla <nombre de objeto, propiedad de objeto, valor de la propiedad del objeto, instante>.

Dato elemental terna <nombre de objeto, propiedad de objeto, valor de la propiedad del objeto>.

Modelo de datos herramienta intelectual que provee una interpretación del mundo real. Es un dispositivo de
abstracción.

Figura 1: Datos, información y conocimiento

Ejemplos de modelos de representación simbólica de la información: lenguaje natural, fórmulas matemáticas,

mapas, partituras.
La pieza más elemental de información es el dato. Un dato solo es de utilidad si está vinculado a otros
datos. La estructura y el contexto le dan significado a los datos.

2. BDs y SGBDs
Sistema de Base de Datos está formado por cuatro componentes:

1. Hardware

2. Software

3. Datos

4. Personas

a) Administradores: definen el esquema de la base de datos, definen permisos de acceso, ejecutan

mantenimientos de rutina (backups, ampliando la capacidad de los discos, monitoreando la perfor-
mance)

b) Usuarios

Página 5 de 75 Base de Datos (75.15 - 95.05) - Resumen

 2 BDs y SGBDs

Tipo de usuario Descripción Interfaz que utiliza

Ingenuos Consultan la base de datos Rellenando formularios de
consulta, o leyendo reportes
generados de la base de datos.
Usan aplicaciones
Sofisticados Consultan la base de datos
mediante un lenguaje, sin Herramientas OLAP (Onli-
programar aplicaciones ne Analytical Processing)
Herramientas de data mi-
ning

Programador de Crean programas para acceder a Herramientas RAD (Rapid

aplicaciones la base de datos Application Development)
Especializados Programan aplicaciones
especiales (knowledge bases,
sistemas expertos, etc.)

Sistema de Gestión de Base de Datos (SGBD) Ejemplos: Oracle, MySQL, SQL Sever, DB2, Access, Pos-
greSQL. Sistema formado por datos y los programas que acceden a los datos. Su objetivo es almacenar y
permitir consultas en formas convenientes y eficientes.
Está formado por tres capas, las abstracciones:
1. Nivel exterior : “vistas” que ven los usuarios. Solo ven una parte de la base de datos, la que les interesa
2. Nivel lógico: cómo se agrupan lógicamente los datos, las entidades y sus relaciones. Ejemplo: tablas,
grafos.
3. Nivel físico: como se organizan físicamente los datos. Ejemplos: bitmaps, árboles.
Gestión de Base de Datos está formada por las siguientes herramientas:
1. Compiladores: proveen el lenguaje de consulta.
2. Catálogo: provee información de la base de datos; por ejemplo, para sacar estadísticas de consultas.
3. Optimizador de consultas
4. Manejador de transacciones: asegura que una transacción se ejecute completamente o permita una
vuelta atrás.
5. Manejador de concurrencia: asegura la integridad de la base de datos ante usuarios concurrentes.
6. Manejador de seguridad :
a) Contra hechos no intencionales. Ejemplo: fallas de energía.
b) Contra hechos intencionales. Ejemplo: ataques de terceros para robar información.

(a) Los datos se almacenan en una base de datos, que

es administrada por un sistema de gestión de bases
de datos
(b) Estructura general de un sistema de base de datos

Figura 2: SGBD

Base de Datos (75.15 - 95.05) - Resumen Página 6 de 75

2.1 Base de datos

2.1. Base de datos

Base de Datos (BD) conjunto de datos interrelacionados.

Instancia de la base de datos colección de información en la base de datos en un momento particular.

Esquema de la base de datos descripción de la base de datos. La base de datos física varía con el tiempo
(porque se producen altas, bajas y modificaciones), pero el esquema es fijo (o se cambia en raras ocasiones).

Modelo conceptual: representación de alto nivel, que concentra los requerimientos del cliente. Utiliza
el modelo Entidad-Relación.

Modelo lógico: representación de bajo nivel. Utiliza el modelo relacional.

Modelo físico: utiliza SQL.

Figura 3: Base de datos

2.2. ¿Por qué una base de datos y no un sistema de archivo?

Desventajas de usar un sistema de archivo:

Inconsistencia y redundancia, porque se usan muchos archivos, y tal vez tienen distintos formatos

Dificultad para acceder a los datos, porque se necesitan programas para acceder a los archivos

Problemas de integridad, porque es difícil cambiar todos los programas para que adopten restricciones de
consistencia

Dificultad para asegurar la atomicidad de las transacciones

Problemas para garantizar el acceso concurrente

Problemas de seguridad

Página 7 de 75 Base de Datos (75.15 - 95.05) - Resumen

 2.3 Diseño de una base de datos

2.3. Diseño de una base de datos

Figura 4: Metodología de diseño de una base de datos

2.4. Modelos de datos

Modelo de datos guía para organizar los datos de una base de datos. Formado por tres componentes:

1. la estructura de los datos (tablas, árboles, redes, etc.),

2. las operaciones sobre las estructuras, y
3. las restricciones sobre las estructuras o sobre las operaciones (para que los datos mantengan su
integridad semántica).

La potencia semántica de un modelo de datos está determinada por su capacidad de representar, además
de la estructura de los datos, el significado de los mismos y sus interrelaciones.

Base de Datos (75.15 - 95.05) - Resumen Página 8 de 75

2.5 Modelos de bases de datos

2.4.1. Operaciones en una base de datos

Estado de una BD valor de todos los atributos de todos los objetos de la base de datos.
Operadores los hay de dos tipos:

1. De consulta (no modifican el estado de la base de datos)

2. De actualización (modifican el estado de la base de datos)
Transacción conjunto de operaciones elementales. Ejemplo: la transferencia a una cuenta.
leer ( cuenta_a )
cuenta_a <- cuenta_a + 100
escribir ( cuenta_a )
leer ( cuenta_b )
cuenta_b <- cuenta_b - 100
escribir ( cuenta_b )

2.4.2. Restricciones
Tipos de restricciones sobre una base de datos:

Inherentes: determinado por la estructura de la base de datos

Explícitas: provienen del mundo real
Implícitas: se derivan de las explícitas
De estado: restringen los posibles valores de los atributos. Ejemplo: la edad de una persona no puede ser
negativa.
De actualización: restringen las posibles operaciones sobre los atributos. Ejemplo: no se puede disminuir
la edad de una persona.
De entidad: Ejemplo: no puede haber dos objetos iguales en la misma base de datos.

De integridad referencial: Ejemplo: no se puede referenciar a un objeto que no existe en la base de

datos.

2.5. Modelos de bases de datos

1. Entidad-Interrelación: para el diseño conceptual
2. Relacional: para el modelo lógico. La relaciones se representan a través de claves foráneas
3. Jerárquico (árbol): el acceso a niveles inferiores sólo es posible a través de sus padres
4. De red: las relaciones entre los datos se representan con referencias físicas

5. De objetos: existe una persistencia de los objetos más allá de la existencia en memoria

Página 9 de 75 Base de Datos (75.15 - 95.05) - Resumen

 3 Modelo Entidad-Interrelación (E-R)

3. Modelo Entidad-Interrelación (E-R)

Nota importante: no podemos tener nombres de entidades o interrelaciones repetidos.

3.1. Entidades
El modelo entidad-interrelación se basa en la idea de que el mundo real está compuesto por objetos (las
entidades) y las interrelaciones que hay entre las entidades.

Entidad algo que existe, concreto o abstracto. Ejemplo: una persona Juan, la cuenta bancaria n°4500011.
Conjunto de entidades / tipo de entidad conjunto de entidades del mismo tipo. Ejemplo: el conjunto de
entidades “cliente” abarca todas las personas que tienen cuenta en un banco.

Un conjunto de entidades E tiene un predicado asociado p para probar si una entidad e pertenece al conjunto.

E = {e/p(e)}

Los conjuntos de entidades no necesitan ser disjuntos. Ejemplo: “animales” y “mamíferos” no son disjuntos.
Un tipo de entidad queda definido por:
1. Nombre: en singular o frase simple en singular. Ejemplos: “cliente”, “cuenta corriente”
2. Significado: texto preciso, conciso y claro. Debe indicar, si existieran, dependencias con otros tipos de
entidades
3. Atributos: características de todas las entidades de ese tipo. Ejemplo: para el conjunto de entidades
“cliente”, posibles atributos son “nombre”, “DNI”, “calle”, “ciudad”, etc. Cada atributo tiene un conjunto
de valores permitidos, denominado el dominio del atributo. Ejemplo: el DNI debe ser un número positivo.
Los atributos deben ser atómicos (es decir, que no se pueden descomponer), y no pueden estar repetidos.
Formalmente, un atributo es una función que hace corresponder un conjunto de entidades a un dominio o
producto cartesiano de dominios. Ejemplo: una entidad “empleado” está descrita por el conjunto {(nombre,
Juan), (apellido, Cancela), (DNI, 5.678.901)}.
Un atributo puede tener el valor nulo, por varias razones:
a) No aplica
b) Faltante
c) Desconocido
Tipos de atributos:
a) Simple vs compuesto. Ejemplo: nombre puede descomponerse en primer nombre, segundo nombre, y
apellido.
b) Un valor vs Multivaluado: se repite varias veces en la entidad. Ejemplo: número de teléfono.
c) Derivable: su valor puede calcularse a partir de otros atributos. Debe evitarse. Ejemplo: si tengo el
atributo “fecha de nacimiento”, “edad” es un atributo derivable.
4. Identificador: atributo o conjunto de atributos que permiten distinguir a cada entidad dentro del conjunto
de entidades del mismo tipo.

3.2. Interrelaciones
Interrelación asociación entre dos o más conjuntos de entidades.
Conjunto de interrelaciones / tipo de interrelación conjunto de interrelaciones del mismo tipo. Si E1 , E2 , . . . , En
son conjuntos de entidades, entonces el conjunto de interrelaciones R es un subconjunto del producto car-
tesiano
{(e1 , e2 , . . . , en ) /e1 ∈ E1 , e2 ∈ E2 , . . . , en ∈ En }

donde la tupla (e1 , e2 , . . . , en ) es una interrelación.

Base de Datos (75.15 - 95.05) - Resumen Página 10 de 75

3.2 Interrelaciones

Figura 5: “Tenencia” es una interrelación entre dos entidades

Un tipo de interrelación puede tener atributos descriptivos. Ejemplo: la interrelación “tenencia” puede
tener un atributo “fecha último movimiento”.

Características:

Grado de una interrelación cantidad de tipos de entidades que participan en la relación.

Figura 6: Grado de una interrelación

Cardinalidad de una interrelación cantidad de tipos de entidades con las que puede estar relacionado.

Rol función que desempeña una entidad en una interrelación. Normalmente no se especifica porque está implí-
cito. Ejemplos: un cliente “tiene” una cuenta, un empleado “es jefe de” n empleados.

Instancia de una interrelación asociación entre dos o más entidades. Debe ser unívocamente identificable
sin usar los atributos descriptivos de la interrelación.

Un tipo de interrelación puede identificarse por:

1. Un atributo propio, o

2. Una clave primaria, formada por los atributos de las claves primarias de los tipos de entidad que asocian.
Ejemplo: “DNI” es la clave primaria de “cliente”, y “nro cuenta” es la clave primaria de “cuenta”. La clave
primaria del tipo de interrelación “tenencia” es (DNI, nro cuenta)

La estructura de la clave primaria de una interrelación R depende de las restricciones de cardinalidad del
conjunto de interrelaciones.

Página 11 de 75 Base de Datos (75.15 - 95.05) - Resumen

 3.2 Interrelaciones

3.2.1. Tipos de interrelaciones

Especialización un conjunto de entidades se divide en grupos de entidades que son distintivas. Ejemplo: en
el contexto de un banco, una persona puede ser “especializada” en un empleado o un cliente, o ambas, o
ninguna
Generalización la inversa de especialización. Existe una superclase y una o más subclases.
Puede haber restricciones de pertenencia:
1. ¿Qué tipos de entidades pueden ser miembros de una subclase?
a) Definido por condición: existe una condición o predicado explícito que decide la pertenencia o
no pertenencia.
b) Definido por el usuario: el usuario de la BD asigna entidades a una subclase.
2. ¿Las entidades pueden pertenecer a más de una subclase dentro de una superclase?
a) Sí =⇒ Generalizaciones superpuestas
b) No =⇒ Generalizaciones disjuntas
3. ¿Una entidad en la superclase debe pertenecer a al menos una entidad en la subclase?
a) Sí =⇒ Generalización total
b) No =⇒ Generalización parcial
En la especialización y en la generalización, las subclases heredan atributos de la superclase.
Agregación abstracción mediante la cual un conjunto de interrelación es tratado como una superclase.

Base de Datos (75.15 - 95.05) - Resumen Página 12 de 75

3.3 Restricciones

3.3. Restricciones
3.3.1. Restricciones de participación
Se dice que la participación de un conjunto de entidades E en un conjunto de interrelaciones R es total
cuando cada entidad en E participa en al menos una interrelación en R. Si solo algunas entidades participan,
la participación es parcial.

3.3.2. Restricciones de cardinalidad de correspondencia

Cardinalidad de correspondencia cantidad mínima y máxima de entidades a las cuales puede asociarse una
entidad a través de un tipo de interrelación.

Para una interrelación binaria R entre dos tipos de entidades A y B, la cardinalidad puede ser:

1. Uno a uno (1 : 1): Una entidad en A está asociada como máximo a una entidad en B, y una entidad en
B está asociada como máximo a una entidad en A.

Figura 7: Cardinalidad 1 : 1

2. Uno a muchos (1 : M ): Una entidad en A está asociada como máximo con cualquier cantidad de entidades
en B, y una entidad en B está asociada como máximo a una entidad en A.
También existe la restricción “muchos a uno” (M : 1).

Figura 8: Cardinalidad 1 : M

3. Muchos a muchos (M : M ): Una entidad en A está asociada como máximo con cualquier cantidad de
entidades en B, y una entidad en B está asociada como máximo con cualquier cantidad de entidades en
A.

Figura 9: Cardinalidad M : M

Para una interrelación ternaria R entre tres tipos de entidades A, B y C, la cardinalidad puede ser:

Página 13 de 75 Base de Datos (75.15 - 95.05) - Resumen

 3.3 Restricciones

N:N:N

Figura 10: Las fábricas le compran insumos a proveedores.

Claves candidatas de “Compra”: {idf ábrica , idinsumo , idproveedor }

N:N:1

Figura 11: Las fábricas le compran insumos a proveedores. Una fábrica no puede comprar el mismo insumo a
más de un proveedor.

Claves candidatas de “Compra”: {idf ábrica , idinsumo }

N:1:1

Figura 12: Las fábricas le compran insumos a proveedores. Una fábrica no puede comprar el mismo insumo a
más de un proveedor. Un proveedor no puede venderle el mismo insumo a más de una fabrica.

Claves candidatas de “Compra”: {idf ábrica , idinsumo } ; {idproveedor , idinsumo }

1:1:1

Figura 13: Las fábricas le compran insumos a proveedores. Una fábrica no puede comprar el mismo insumo a
más de un proveedor. Un proveedor no puede venderle el mismo insumo a más de una fabrica. Una
fábrica no puede comprarle más de un insumo a cada proveedor.

Base de Datos (75.15 - 95.05) - Resumen Página 14 de 75

3.3 Restricciones

Claves candidatas de “Compra”: {idf ábrica , idinsumo } ; {idproveedor , idinsumo } ; {idf ábrica , idproveedor }

Teorema: en las relaciones ternarias, las restricciones de cardinalidad no imponen restricciones en las
relaciones binarias. En el ejemplo anterior, una fábrica puede comprar N insumos. Una fábrica puede comprarle
a N proveedores. Un proveedor puede proveer N insumos.

3.3.3. Restricciones de dependencia existencial

Si la existencia de la entidad S depende de la existencia de la entidad D, entonces se dice que S tiene

dependencia existencial de D. Operacionalmente, esto significa que si D es borrado, también S es borrado.
La entidad D es la entidad dominante y S es la entidad subordinada.

3.3.4. Restricciones de identificación

Superclave conjunto de uno o más atributos que, tomados en conjunto, permiten identificar unívocamente
una entidad o una interrelación en el conjunto de entidades o interrelaciones del mismo tipo.

Si K es una superclave, cualquier superconjunto de K también es una superclave.

Clave candidata superclaves minimales; aquellas para las cuales ningún subconjunto propio es una superclave.

Sea R un esquema de relación con atributos A1 , . . . , An . El conjunto de atributos K = (A1 , . . . , Ak ) es

una clave candidata de R sí y sólo sí satisface:

1. Unicidad : en todo momento, no existen dos tuplas distintas de R que tengan el mismo valor para
Ai , donde i ∈ [1, k].

2. Minimalidad : ningún atributo de K puede ser eliminado sin que se pierda la propiedad de unicidad.

Clave primaria aquella clave candidata que es elegida por el diseñador del modelo de datos para identificar
entidades dentro del conjunto de entidades. Esta clave no debería cambiar en el tiempo. Ejemplo: la
dirección de un cliente no es una buena clave primaria, porque se puede mudar

Clave foránea atributo o conjunto de atributos que es clave primaria en otra relación. Ejemplo: en una relación
“autos”, puede haber una clave foránea “DNI” que es la clave primaria en otra relación “personas”, y que
indica el dueño de ese auto

Entidad débil entidad que tiene dependencia de identificación, porque no es identificable por sus propios
atributos. Está subordinada a otro tipo de entidad, la entidad fuerte.

Entidad fuerte entidad que tiene una clave primaria propia.

El concepto de entidades fuertes y débiles está relacionado con el concepto de dependencia de existencia.
Una entidad débil es, por definición, una entidad subordinada a la entidad dominante de la cual depende
su identidad. Toda dependencia de identidad es una dependencia de existencia, pero una dependencia de
existencia no implica necesariamente una dependencia de identidad.

Discriminador atributo o conjunto de atributos de una entidad débil que lo distingue de otras entidades
débiles que dependen de la misma entidad fuerte.

Para una entidad débil, su clave primaria está formada por su identificador más la clave primaria de la
entidad fuerte de la cual depende.

Página 15 de 75 Base de Datos (75.15 - 95.05) - Resumen

 3.4 Diagramas E-R

3.4. Diagramas E-R

Figura 14: Simbología en los diagramas E-R

Figura 15: Simbología en los diagramas E-R para entidades fuertes (cuenta) y débiles (transacción). La clave
primaria de la entidad fuerte se identifica con el atributo subrayado (nro. cuenta). La dependencia a
la entidad fuerte se identifica con arcos dobles. El discriminador de la entidad débil se identifica con
el atributo subrayado a medias (nro. transacción). El identificador de la entidad débil es la suma
de su discriminador y de la clave primaria de la entidad fuerte (nro. cuenta + nro. transacción)

3.5. Cuestiones de diseño

1. ¿Conjuntos de entidades vs. Atributos?

a) Algunos atributos no pueden transformarse en entidades. Ejemplo: el nombre de una persona

b) Algunos atributos están mejor representados como entidades, para permitir atributos. Ejemplo: te-
léfonos de una persona

2. ¿Conjuntos de entidades vs. Conjuntos de interrelaciones?

Las interrelaciones modelan “acciones” que ocurren entre entidades.

3. ¿Conjuntos de interrelaciones binarias vs. n-arias?

Teorema: es posible reemplazar cualquier conjunto de interrelaciones n−aria (con n > 2) con un número
de interrelaciones binarias.

4. Localización de atributos de interrelaciones

a) Relaciones 1 : 1 =⇒ en cualquiera de las dos entidades participantes

b) Relaciones 1 : N =⇒ en la segunda entidad
c) Relaciones N : N =⇒ en la interrelación

Base de Datos (75.15 - 95.05) - Resumen Página 16 de 75

3.6 Reducción de un esquema E-R a un modelo relacional

3.6. Reducción de un esquema E-R a un modelo relacional

Para cada entidad y para cada interrelación, se construye una única tabla. Cada tabla contiene múltiples
columnas.

Representación de conjuntos de entidades fuertes

Sea E un conjunto de entidad fuerte con atributos a1 , . . . , an . Se representa a la misma con una tabla
llamada E con n columnas. Cada fila de la tabla es una entidad. El conjunto de todas las posibles filas de
la tabla es el producto cartesiano entre los dominios de cada atributo:

D1 × . . . × Dn

Representación de conjuntos de entidades débiles

Sea A un conjunto de entidad débil con atributos a1 , . . . , am . Sea B el conjunto de entidad fuerte del cual
depende A. La clave primaria de B está formada por los atributos b1 , . . . , bn . Se representa a A con una
tabla con m + n columnas a1 , . . . , am , b1 , . . . , bn .
Representación de conjuntos de interrelaciones
Sea R un conjunto de interrelaciones entre las entidades E1 , . . . , En con atributos r1 , . . . , rm . Sean a1 , . . . , an
el conjunto de atributos formado por la unión de las claves primarias de cada entidad participante. Se
representa a R con una tabla con columnas a1 , . . . , an , r1 , . . . , rm .
Si la interrelación relaciona un conjunto de entidades débil y otro fuerte, la tabla de R no es necesaria,
es redundante.

Representación de interrelaciones 1 : N entre entidades A y B

Si la participación de A en R es total (i.e. cada entidad en A debe participar en la relación R), se pueden
unir las tablas de A y R.
Representación de atributos compuestos
Sea el atributo compuesto x formado por x1 , . . . , xn . Se debe generar una columna para cada x1 , . . . , xn ,
pero no para x.
Representación de atributos multivaluados
Sea el atributo multivaluado x. Se debe crear una tabla T con una columna C que corresponde a x y
el resto de las columnas son la clave primaria del conjunto de entidades o interrelación del cual x es un
atributo.

Representación de generalización
Hay dos métodos:
1. Una tabla para la superclase + una tabla para cada subclase, que incluya una columna con la clave
primaria de la superclase
2. Si la generalización es disjunta y completa, no se crea una tabla para la superclase. Se crea una tabla
para cada subclase, que incluya todos los atributos de la superclase.
Representación de agregación
La tabla de la interrelación R entre la agregación A y el conjunto de entidades B incluye una columna
por cada clave primaria de B y A.

Página 17 de 75 Base de Datos (75.15 - 95.05) - Resumen

 4 Modelo Relacional

4. Modelo Relacional
4.1. Estructura del modelo relacional
El modelo relacional es un ejemplo de modelo basado en registros. Usa un grupo de tablas para representar
los datos y las relaciones entre los datos. Cada tabla tiene múltiples columnas. Cada tabla contiene registros de
un tipo en particular. Cada registro tiene atributos (las columnas).

Figura 16: Tablas

Dominio valores posibles de un conjunto. Ejemplo: Dpadron = {1, 2, . . . 100000}

Existe un valor que es posible en cualquier dominio: el valor nulo. Este valor significa “atributo descono-
cido” o “atributo inexistente”. Se puede prohibir, para un atributo, que este tenga el valor nulo, ya que
puede causar problemas al realizar consultas.

Esquema de relación descripción de una relación. Es el nombre de la relación seguido de la lista de los
atributos con sus dominios. Ejemplo: Estudiante (Padrón, nombre, dirección, fechaIngreso)

Relación instancia de un esquema. Subconjunto del producto cartesiano de una lista de dominios. Sea el
esquema de relación R, denotamos a la instancia r mediante r(R).

Tabla representación de una relación. Se pueden relacionar entre sí al compartir atributos. Una tabla de n
atributos es un subconjunto de D1 × D2 × · · · × Dn . Notar que al ser un conjunto, el orden no interesa.

Atributo nombre de cada columna de una tabla.

Esquema de BD relacional conjunto de esquemas de relación.

Tupla miembro de una relación. Son las filas de una tabla.

4.2. Restricciones del modelo relacional

Regla de integridad de entidad
Ningún atributo de la clave primaria de un esquema de relación puede tomar valor nulo.

Regla de integridad referencial

Si la relación r incluye una clave foránea F que es la clave primaria P de una relación s, entonces todo
valor de F en r debe ser totalmente nulo o ser igual al valor de P en alguna tupla de s.

Base de Datos (75.15 - 95.05) - Resumen Página 18 de 75

4.3 Operaciones del modelo relacional: álgebra relacional

4.3. Operaciones del modelo relacional: álgebra relacional

Es un lenguaje formal y procedural que permite realizar consultas sobre un conjunto de relaciones, y
produce relaciones como resultado.

4.3.1. Operadores básicos

Los siguientes operadores son linealmente independientes. Se utilizan para filtrar, cortar y combinar relacio-
nes.

Operaciones unarias
Proyección

Proyección: πa1 ,...,an (r)

Dados los atributos a1 , . . . , an que pertenecen a r, devuelve una relación de esquema {a1 , . . . , an }.
Se eliminan las tuplas repetidas.

ℵ
Selección

Selección: σp (r)
Devuelve una relación r0 con el mismo esquema que r, en la que las tuplas son aquellas pertenecientes
a r que satisfacen la condición o el predicado p. La condición puede ser de dos estilos:
1. Atómica: expresión lógica simple del tipo que utiliza un operador de comparación θ, tal que
θ ∈ {=, 6=, <, >, ≤, ≥}. Se permiten dos tipos de expresiones:

a) Atributo θ atributo
b) Atributo θ constante
2. Compuesta: utiliza conectores and, or, not.

ℵ
Renombre

Renombre: ρR(A1 ,A2 ,...,An ) (E)

Cambia el nombre de la relación E a R, y también cambia el nombre de sus atributos a A1 , A2 , . . . , An .

Página 19 de 75 Base de Datos (75.15 - 95.05) - Resumen

 4.3 Operaciones del modelo relacional: álgebra relacional

Operaciones binarias
Unión
[
Unión: r s
Sean r y s instancias homogéneas a de las relaciones R y S respectivamente. r contiene m tuplas y s
contiene n tuplas. La unión se define como:
[
r s = {x : x ∈ r ∨ x ∈ s}

Las tuplas repetidas se eliminan.

a Las
relaciones homogéneas tienen: (a) la misma cantidad de atributos, y (b) para todo i, el dominio del atributo
i de r es el mismo que el dominio del atributo i de s

ℵ
Diferencia

Diferencia: r − s
Sean r y s instancias homogéneas de las relaciones R y S respectivamente. La diferencia se define
como:
r − s = {x : x ∈ r ∧ x 6∈ s}

ℵ
Producto cartesiano

Producto cartesiano: r × s
Sean r y s instancias de las relaciones R y S respectivamente. El producto cartesiano es el conjunto
de tuplas que resulta de concatenar cada tupla de r con cada tupla de s.

r × s = {(r1 , s1 ) ; . . . ; (r1 , sm ) ; . . . ; (rn , s1 ) . . . , (rn , sm )}

Si r tiene n tuplas y s tiene m tuplas, r × s tendrá n · m tuplas. El grado de r × s es la suma de los

grados de r y s.

4.3.2. Operadores secundarios

No proporcionan nuevas funcionalidades, solo simplifican las consultas.
1. Intersección (r s)
T

Dadas las relaciones r1 y r2 con el mismo esquema, devuelve una relación r con igual esquema, tal que
r = {x : x ∈ r1 ∧ x ∈ r2 } \
r s ≡ r − (r − s)

2. Junta (join) (r ./ s)
La junta de dos relaciones r y s según un predicado P es una relación de esquema igual al producto
cartesiano r × s, cuyas tuplas son el conjunto de tuplas de r × s que satisfacen el predicado P .
r ./p s ≡ σp (r × s)
a) Equi-join: dadas las relaciones r y s, es el join según el predicado r.Ai = s.Aj
b) Auto-join: dada la relación r, es el join de r consigo mismo según el predicado 1.Ai θ 2.Ai donde 1
y 2 son aliases de r.

Base de Datos (75.15 - 95.05) - Resumen Página 20 de 75

4.3 Operaciones del modelo relacional: álgebra relacional

c) Natural
T join (r ∗ s). Requiere que haya atributos compartidos entre las relaciones r y s, y además
que R S 6= ∅.
r ∗ s ≡ πR∪S (σr.c1 =s.c1 ∧r.c2 =s.c2 ∧···∧r.ch =s.ch (r × s))
El join natural es una operación asociativa, por lo tanto, (r ∗ s) ∗ t = r ∗ (s ∗ t).

Figura 17: Junta natural

3. División (r/s).
Sean las relaciones r ∈ R con n atributos y s ∈ S con m atributos, tal que m < n y S ⊂ R. La división
son todas las tuplas t tales que, multiplicadas por todas las filas u de s, me dan filas que están en r. El
esquema de la división es R − S.

r/s ≡ π1,...,n−m (r) − π1,...,n−m ((π1,...,n−m (r) × s) − r)

Figura 18: División

4. Asignación (r ← s)
r no cambia al ejecutar operaciones de actualización sobre s.

Página 21 de 75 Base de Datos (75.15 - 95.05) - Resumen

 4.4 Operadores extendidos

4.4. Operadores extendidos

1. Proyección generalizada: permite operadores aritméticos como parte de una proyección.

πF1 ,F2 ,...,Fn (E)

donde E es una expresión de álgebra relacional, y Fi es una expresión aritmética que involucra constantes
y atributos del esquema E.

2. Funciones agregadas: son funciones que toman como parámetro un multiconjunto 1 .

sum
count
min
max
avg

La forma general es:

G1 ,...Gn GF1 (A1 ),...,Fm (Am ) (E)

donde E una expresión de álgebra relacional; Gi es un atributo para formar grupos, Fi es una función
agregada, y Ai es un atributo. Las tuplas de la relación resultado de E se particionan en grupos de tal
forma que

a) Todas las tuplas en un grupo tienen el mismo valor para Gi ∀i ∈ [1, n]

b) Tuplas en distintos grupos tienen distinto valor para Gi ∀i ∈ [1, n]

Para cada grupo, la relación tendrá una tupla (g1 , . . . , gn , a1 , . . . , am ) donde para cada i, ai es el resultado
de aplicar la función Fi en el multiconjunto, para el atributo Ai del grupo.
Ejemplo: dada la relación EmpleadosPartTime(nombre,sucursal,salario), la siguiente expresión devuelve
una relación con un solo atributo (sin nombre) y una sola fila, que contiene el valor de la suma de todos
los salarios:
Gsum(salario) EmpleadosP artT ime

Se puede usar el operador distinct para eliminar múltiples ocurrencias de un valor.

Ejemplo: con la misma relación anterior, la siguiente expresión devuelve una relación con un solo atributo
(sin nombre) y una sola fila, que contiene la cantidad de sucursales:

Gcount−distinct(sucursal) EmpleadosP artT ime

Se puede usar el operador de grupos para particionar una relación y computar una función agregada a
cada grupo.
Ejemplo: con la misma relación anterior, la siguiente expresión devuelve una relación con dos atributos
(sin nombres), que contiene la suma de salarios de cada sucursal:

sucursal Gsum(salario) EmpleadosP artT ime

3. Join externo (outer join): es una extensión de la operación de join que lidia con información faltante
(null s).

a) Left outer join (r1 ./ r2 ): hace un join natural, y toma todas las tuplas de r1 que no matchearon con
ninguna tupla de r2 , les agrega valores null a los atributos de r2 , y los agrega al resultado.
b) Right outer join (r1 ./ r2 ): hace un join natural, y toma todas las tuplas de r2 que no matchearon
con ninguna tupla de r1 , les agrega valores null a los atributos de r1 , y los agrega al resultado.
1 Un multiconjunto es un conjunto en el que un valor puede aparecer muchas veces.

Base de Datos (75.15 - 95.05) - Resumen Página 22 de 75

4.5 Actualizaciones a bases de datos

c) Full outer join (r1 ./ r2 ): combina las dos operaciones anteriores.

Figura 19: Ejemplo de full outer join

4.5. Actualizaciones a bases de datos

4.5.1. Delete
En álgebra relacional se expresa como r ← r − E, donde r es una relación y E es una expresión de consulta.
Solo se pueden borrar tuplas completas, no valores de atributos.

4.5.2. Insert
En álgebra relacional se expresa como r ← r ∪ E, donde r es una relación y E es una expresión de consulta,
o una relación constante con una sola tupla.

4.5.3. Update
En álgebra relacional se expresa como r ← πF1 ,...,Fn (r), donde r es una relación y cada Fi es, o el atributo
i-ésimo de r, o una expresión que involucra solo constantes y el nuevo valor de r, que da el nuevo valor del
atributo i-ésimo.

4.6. Vistas (views)

Vista relación que no es parte del modelo lógico de la base de datos, pero que es visible para el usuario como
una relación “virtual”.

1 CREATE VIEW v AS < expresion de consulta >

Limitaciones:
No se pueden ejecutar operaciones de update sobre una vista, salvo que la vista sobre la relación R cumpla
lo siguiente:
• Deben usar SELECT, y no SELECT DISTINCT
• La cláusula WHERE no debe incluir a R en una consulta anidada
• La cláusula WHERE no debe incluir a otra relación
• Los atributos del SELECT deben ser NOT NULL
El update solo se ejecutará sobre los atributos del SELECT.
A las operaciones de delete sobre una vista se les pasa la cláusula WHERE de la vista (para borrar solo las
tuplas que se pueden ver en la vista).
Si las relaciones subyacentes son modificadas, la vista queda desactualizada. Por eso, en los motores, en
una expresión que involucra una vista, la relación de la vista se recalcula al evaluar la expresión.

Vista materializada vista que se evalúa y se almacena físicamente. Los cambios a estas vistas se realizan de
forma incremental (no se reconstruye toda la vista desde cero)

Página 23 de 75 Base de Datos (75.15 - 95.05) - Resumen

 5 Cálculo relacional

5. Cálculo relacional
COMPLETAR

6. Lenguajes de consulta
Query expresión que solicita una porción de información.

Hay dos tipos de lenguajes de consulta (query languages):

1. Procedurales: el usuario indica una serie de operaciones a ejecutar sobre una base de datos para producir
el resultado deseado. Ejemplos: SQL.
2. No procedurales: el usuario indica la información deseada, sin especificar el procedimiento para obte-
nerla. Ejemplos: Datalog (similar a Prolog).

7. Integridad y seguridad
En SQL, tenemos las siguientes restricciones:
NOT NULL: indica que un atributo no puede tener el valor null
UNIQUE: asegura que para todas las tuplas, el valor del atributo es único
PRIMARY KEY: asegura que una o varias columnas tengan una identidad única, no nula
FOREIGN KEY: asegura la integridad referencial de una tabla
CHECK: asegura que el valor de un atributo satisface una condición especificada
DEFAULT: especifica un valor por defecto cuando no se especifique ninguo

7.1. Restricciones de dominio

1 CREATE DOMAIN color AS VARCHAR (10)
2 DEFAULT ’ SinColor ’
3 CHECK ( value IN ( ’ SinColor ’ , ’ Azul ’ , ’ Rojo ’) ) ;
4
5 CAST relacion . Atributo AS < dominio >;
6
7 DROP DOMAIN < dominio >;
8
9 ALTER DOMAIN < dominio >;

7.2. Restricciones de integridad referencial

Ejemplo:
1 CREATE TABLE hospital (
2 IdHosp SMALLINT ,
3 PRIMARY KEY ( IdHosp ) ) ;
4
5 CREATE TABLE medico (
6 IdHosp SMALLINT ,
7 IdMedico SMALLINT ,
8 Nombre VARCHAR (40)
9 PRIMARY KEY ( IdMedico ) ) ;
10
11 ALTER TABLE medico
12 ADD CONSTRAINT FK_medico
13 FOREIGN KEY IdHosp
14 REFERENCES hospital ( IdHosp ) ;

Base de Datos (75.15 - 95.05) - Resumen Página 24 de 75

7.3 Seguridad y autorizaciones

7.2.1. Acciones referenciales

Son llamadas SQL que se ejecutan de forma automática ante la eliminación o actualización de una restricción
de integridad referencial, para mantener la misma.
1 ALTER TABLE medico
2 ADD CONSTRAINT FK_medico
3 FOREIGN KEY IdHosp
4 REFERENCES hospital ( IdHosp )
5 ON [ DELETE | UPDATE ] [ SET DEFAULT | SET NULL | CASCADE | NO ACTION ];
De esta forma, cuando se elimine o actualice una fila en la tabla Hospital, el sistema de base de datos
ejecutará la acción especificada en la tabla Medico:

SET DEFAULT / SET NULL: se fija el valor predeterminado o nulo en la fila referenciante.
CASCADE: al eliminar una tupla referenciada, las tuplas referenciantes son eliminadas. Al modificar la clave
en la tabla referenciada, el correspondiente valor de la clave foránea es actualizado.

7.3. Seguridad y autorizaciones

Para brindar autorizaciones, se brindan privilegios. Los privilegios son tipos de autorizaciones para leer,
insertar, actualizar o borrar datos. También existe el privilegio references, que permite declarar claves foráneas
al crear relaciones nuevas.
Con la opción WITH GRANT OPTION se permite que el usuario que recibe el permiso se lo conceda a alguien
más. El pase de autorizaciones de un usuario a otro se representa con un grafo de autorización, donde cada
nodo es un usuario (la raíz es el DBA), y las aristas representan autorizaciones concedidas.
Un usuario tiene autorización sí y solo sí existe un camino desde la raíz del grafo hacia el nodo usuario.
1 GRANT < privilegios >
2 ON <[ relacion | vista ] >
3 TO <[ usuario | rol ] >
4 [ WITH GRANT OPTION ];

Para eliminar autorizaciones se usa el comando REVOKE. Por defecto, este comando tiene el efecto de revocar
los privilegios que el usuario le brindó a otros. Para evitar este efecto cascada, se usa la opción RESTRICT.
1 REVOKE < privilegios >
2 ON <[ relacion | vista ] >
3 FROM <[ usuario | rol ] >
4 [ RESTRICT ];

Para crear roles:

1 CREATE ROLE instructor ;

8. Triggers
Trigger: comando que el sistema ejecuta automáticamente si un evento satisface cierta condición. Son un
conjunto de acciones; por ejemplo, enviar un e-mail, ejecutar el rollback de una transacción, o crear una copia
de la base de datos.
1 CREATE TRIGGER chequear_horario
2 [ BEFORE | AFTER ] [ UPDATE | INSERT | DELETE ] [ OF atributo ] ON curso
3 WHEN condicion
4 BEGIN
5 acciones
6 END

Página 25 de 75 Base de Datos (75.15 - 95.05) - Resumen

Parte II
Diseño de bases de datos
Objetivos de diseño de base de datos

Reducir la redundancia de la información (porque ocupa espacio y es más difícil de actualizar):

repetición de información en varias tuplas
Eliminar las anomalías:
• De actualización: podría darse el caso de que actualizamos una tupla y no actualizamos
otra tupla con el mismo dato
• De inserción: no es posible insertar ciertos datos sin insertar otros (posiblemente no rela-
cionados)
• De eliminación: podría darse el caso de que eliminamos una tupla y, sin querer, borramos
un dato importante

Devolver información rápidamente

ℵ
Notación

Nombre de esquemas: R, S, R1 , . . . , Rn , S1 , . . . , Sn

Instancias de esquemas: r, s, r1 , . . . rn , s1 , . . . , sn
Conjuntos de atributos: α, β, γ
Atributos: A, B, C

Tuplas: t1 , t2

9. Dependencias funcionales
Dependencia funcional sea el esquema R, y sean α ⊆ R y β ⊆ R. La dependencia funcional α → β se cumple
si para cada par de tuplas t1 , t2 tal que t1 [α] = t2 [α], también se cumple que t1 [β] = t2 [β].
Una dependencia funcional es trivial si β ⊆ α. En particular, α → α es trivial.
Un conjunto K es superclave de R si K → R.
Un conjunto J es clave candidata de R si J → R y además 6 ∃γ ⊂ J/γ → R.
Una dependencia funcional, a diferencia de una diferencia multivaluada o de junta, prohíbe que ciertas
tuplas existan.

Dependencias funcionales implicadas sea el esquema R. Una dependencia funcional f está lógicamente
implicada por un conjunto de dependencias F , si para cada instancia de relación r(R) que cumple F ,
también cumple f .

9.1. Axiomas de Armstrong

Se utilizan para hallar las dependencias funcionales implicadas, es decir, F + de un conjunto F .

Base de Datos (75.15 - 95.05) - Resumen Página 26 de 75

9.2 Clausura y superclaves

Axiomas de Armstrong

1. Regla de reflexividad
Si α es un conjunto de atributos y β ⊆ α, entonces (α → β) ∈ F +

2. Regla de aumento
Si α → β es una dependencia funcional y γ es un conjunto de atributos, entonces (γα → γβ) ∈
F+
3. Regla de transitividad
Si α → β es una dependencia funcional y β → γ es otra dependencia funcional, entonces
(α → γ) ∈ F +

ℵ
Propiedades deducidas de los axiomas de Armstrong

1. Regla de unión
Si se cumplen α → β y α → γ, entonces también se cumple α → βγ
2. Regla de descomposición
Si se cumple α → βγ, entonces también se cumplen α → β y α → γ
3. Regla de pseudotransitividad
Si se cumplen α → β y γβ → δ, entonces también se cumple γα → δ

ℵ
Teorema: R satisface la dependencia funcional X → Y sí y sólo sí R descompone sin pérdida sobre los
esquemas XY y X(R − XY ), es decir, si R satisface la dependencia de junta ∗ (XY, X(R − XY ))

9.2. Clausura y superclaves

Clausura de F sea F un conjunto de dependencias funcionales sobre el esquema R. F + es el conjunto de
dependencias funcionales implicadas por F .
F + = {α → β/F  α → β}

Algoritmo 1 Computar F +
Entrada: relación R, conjunto de dependencias funcionales F
Salida: F +
1. F + = F
2. Repetir hasta que F + no varíe:
a) Para cada dependencia funcional f en F + :
Aplicar reglas de reflexividad y aumentación a f
Agregar las dependencias funcionales restantes a F +
b) Para cada par de dependencias funcionales f1 , f2 en F + :
Si f1 , f2 pueden combinarse usando el axioma de transitividad:
Agregar la dependencia funcional resultante a F +

3. Devolver F +

Para un esquema R con n atributos, hay 2n+1 posibles dependencias funcionales.

Página 27 de 75 Base de Datos (75.15 - 95.05) - Resumen

 9.2 Clausura y superclaves

Clausura de α bajo F es el conjunto de atributos de R que dependen funcionalmente de α.

+
αF = {β/β ⊂ R ∧ F  α → β}

Algoritmo 2 Computar α+
Entrada: relación R, conjunto de dependencias funcionales F , atributo α
Salida: αF
+

1. a+ = a
2. Repetir hasta que a+ no varíe:
a) Para cada dependencia funcional B → Y ∈ F :
Si B ⊆ a+ : a+ = a+ ∪ Y

3. Devolver a+

Usos del algoritmo de cálculo de la clausura de a+

1. Para determinar si α es una superclave de R: debe cumplirse que α+ = R.

2. Para determinar si la dependencia funcional α → β ∈ F + : debe cumplirse que β ⊆ α+ .

3. Es una forma alternativa de calcular F +

Clave y Superclave

Dado un esquema R(A1 , . . . , An ) y un conjunto de dfs F asociado, se dice que X ⊆ R es una

clave para el esquema R si se cumple:

1. F implica que X → A1 . . . An o abreviadamente X → R.

2. No existe ningun Z ⊆ X/F implica Z → R (condición de minimalidad).

Y es superclave para R si solo cumple la condición 1, otra manera de decirlo es que Y es superclave si
es superconjunto de una clave.

Algoritmo 3 Cálculo de claves candidatas mediante un grafo

Entrada: relación R, conjunto de dependencias funcionales F
Salida: claves candidatas de R
1. Dibujar el grafo de dependencias funcionales (si X → Y ∈ F , dibujar una arista entre X e Y )
2. Vni = atributos sin aristas entrantes
3. Voi = atributos que solo tienen aristas entrantes

4. K = {}
5. Repetir hasta que no se pueda agregar nada a K:
a) CC = todos los atributos de Vni
b) Agregar a CC un atributo de R que no esté en Voi ni Vni
c) K = K ∪ CC
6. Devolver K

Base de Datos (75.15 - 95.05) - Resumen Página 28 de 75

9.3 Cubrimiento minimal

9.3. Cubrimiento minimal

Atributo extráneo atributo de una dependencia funcional que se puede quitar de la misma sin cambiar la
clausura del conjunto de dependencias funcionales.
Sea el conjunto de dependencias funcionales F y la dependencia funcional α → β en F .
El atributo A es extráneo en α si, cuando lo sacamos de α, la dependencia funcional se sigue cum-
pliendo (B ∈ (α − A)+F ). Formalmente:
• A ∈ α, y
• F implica lógicamente a (F − {α → B}) ∪ {(α − A) → β}
El atributo B es extráneo en β si, cuando lo sacamos de β, la dependencia funcional se sigue cum-
pliendo (α → (β − B)) Formalmente:
• B ∈ β, y
• El conjunto (F − {α → β}) ∪ {α → (β − B)} implica lógicamente a F
Cubrimiento minimal: El cubrimiento minimal Fmin para F es un conjunto de dependencias funcionales
tales que F implica todas las dependencias en Fmin , y Fmin implica todas las dependencias en F .
Fmin debe tener las propiedades siguientes:
Ninguna dependencia funcional en Fmin contiene un atributo extráneo
No existen dos dependencias funcionales α1 → β y α2 → γ en Fmin tales que α1 = α2 . Es decir, los
lados izquierdos deben ser únicos

Algoritmo 4 Cálculo de cubrimiento minimal

Entrada: conjunto de dependencias funcionales F
Salida: cubrimiento minimal Fmin
1. Usar el axioma de la descomposición para dejar un solo atributo en el lado derecho de cada dependencia
funcional.

2. Eliminar los atributos extráneos de los lados izquierdos.

Sea Y → B una dependencia funcional en F , con al menos dos atributos en Y . Sea Z igual a Y pero con
algún atributo de menos. Si F implica a Z → B, entonces reemplazar Y → B con Z → B.
3. Eliminar las dependencias funcionales redundantes (es decir, que se deducen de los axiomas de Armstrong).

Ejemplo: sea el conjunto de dependencias F = {A → BD, B → CD, AC → E}. Calcular el cubrimiento

minimal.
1. Dejar todos los lados derechos con un único atributo.
Fmin = {A → B, A → D, B → C, B → D, AC → E}
2. Eliminar todos los atributos redundantes del lado izquierdo.
a) Hay que analizar solamente la dependencia que tiene lado izquierdo compuesto: AC → E.
b) ¿C es redundante en AC → E? Hay que verificar si E está en A+
F . Como AF = ABCDE, entonces
+

C es redundante en AC → E y podemos reemplazar esta dependencia funcional por A → E.

Fmin = {A → B, A → D, B → C, B → D, A → E}
3. Eliminar las dependencias redundantes.
Hay que revisar una por una todas las dependencias de Fmin . En caso de que una sea redundante, se
la elimina de Fmin y se sigue analizando el resto tomando como referencia el nuevo Fmin .
¿A → D es redundante en Fc ? Hay que verificar si D está en A+
Fc −{A→D}

• Fmin − {A → D} = {A → B, B → C, B → D, A → E}

Página 29 de 75 Base de Datos (75.15 - 95.05) - Resumen

 10 Primera forma normal (1FN)

• A+
Fmin −{A→D} = ABCDE

• Como D ∈ Fmin − {A → D}, A → D es redundante

Fmin = {A → B, B → C, B → D, A → E}

Puede comprobarse que el resto de las dependencias funcionales no es redundante.

10. Primera forma normal (1FN)

Dominio atómico los elementos del dominio se consideran unidades indivisibles.

Primera forma normal (1FN)

Una relación con esquema R está en 1FN si los dominios de sus atributos son atómicos, y si no hay
atributos similares repetidos.

ℵ
Ejemplo: la siguiente relación no está en 1FN.

Título Libro Autor 1 Autor 2 Autor 3

Database System Concepts Avi Silberschatz Henry Korth S. Sudarshan
Applied Cryptography Bruce Schneier NULL NULL

Para normalizarla, hay que dividirla en dos relaciones.

ID libro Autor
ID libro Título Libro 1 Avi Silberschatz
1 Database System Concepts 1 Henry Korth
2 Applied Cryptography 1 S. Sudarshan
2 Bruce Schneier

11. Descomposición de una relación

Descomposición de una relación

Sea el esquema relacional R. El conjunto de esquemas {R1 , R2 , . . . , Rn } es una descomposición de R

si
R = R1 ∪ R2 ∪ · · · ∪ Rn
Sea la relación r(R). Sean ri = πRi (r) para i = 1, 2, . . . , n. Es decir, {r1 , r2 , . . . , rn } es la base de
datos que resulta de descomponer R en {R1 , R2 , . . . , Rn }. Siempre se verifica que

r ⊆ r1 ./ r2 ./ . . . ./ rn

Es decir, r es un subconjunto de la junta de la descomposición (la junta podría tener tuplas que no
están en r).

Base de Datos (75.15 - 95.05) - Resumen Página 30 de 75

11.1 Descomposición SPI en 2 relaciones

Propiedades deseadas de la descomposición

1. Sin pérdida de información

Verifica que r = πR1 (r) ./ πR2 (r) ./ . . . ./ πRn (r).
2. Preservación de dependencias
Una descomposición que verifica que F 0+ = F + preserva dependencias, donde F 0 = F1 ∪ F2 ∪
· · · ∪ Fn son las dependencias proyectadas.
Esta propiedad es deseable porque significa que podemos chequear si se cumple la dependencia
con solo verificarla en una relación individual, y no necesitamos hacer un join de las relaciones
de la descomposición.

3. Poca o nula redundancia de información

Algoritmo 5 Cálculo de la proyección de dependencias Fi

Entrada: relación R, relación Ri , conjunto de dependencias funcionales F
Salida: conjunto de dependencias funcionales que se verifican en Ri (Fi )

1. Fi = {}
2. Para cada conjunto de atributos X que es un subconjunto de atributos de Ri :
a) Calcular XF+
b) Fi = Fi ∪ {X → A}, tal que A ⊆ XF+ y A ⊆ Ri

3. Devolver Fi

Algoritmo 6 Cálculo para saber si una descomposición preserva una dependencia

Entrada: dependencia funcional A → B, conjunto de dependencias funcionales F , descomposición {R1 , . . . , Rn }
Salida: “verdadero” si la descomposición preserva A → B
1. Z = A

2. Repetir hasta que Z no varíe o hasta que Z incluya a B:

h i
+
Para cada Ri : Z = Z ∪ (Z ∩ Ri ) ∩ Ri

3. Si B ⊆ Z: devolver “verdadero”
4. Si no: devolver “falso”.

11.1. Descomposición SPI en 2 relaciones

Sea el esquema relacional R, y sea F el conjunto de dependencias funcionales sobre R. Sean R1 y R2 una
descomposición de R. Esta descomposición es sin pérdida de información (SPI) si al menos una de las siguientes
dependencias funcionales está en F + :

R1 ∩ R2 → R1 − R2

R1 ∩ R2 → R2 − R1

Ejemplo: ¿La descomposición de R(A, B, C, D, E, F ) en R1 = (A, D, E, F ) y R2 = (B, C, D) es SPI respecto

de F = {A → BD, B → CD, AC → E}?

R1 ∩ R2 = D

Página 31 de 75 Base de Datos (75.15 - 95.05) - Resumen

 11.2 Descomposición SPI en más de 2 relaciones

R1 − R2 = AEF
R2 − R1 = BC
Como DF+ = {D}, vemos que no se cumplen ni R1 ∩ R2 → R1 − R2 ni R1 ∩ R2 → R2 − R1 . Por lo tanto,
esta descomposición no es SPI.

11.2. Descomposición SPI en más de 2 relaciones

El algoritmo Chase Tableau se utiliza para verificar si una descomposición de R en R1 , . . . , Rk (k > 2)
es SPI. Es decir, si la proyección de un esquema restringido por dependencias en una descomposición, puede
recuperarse haciendo el join de las proyecciones.

Algoritmo 7 Algoritmo Chase Tableau

Entrada: esquema de relación R, conjunto de dependencias funcionales F , descomposición {R1 , . . . , Rk }
Salida: “verdadero” si {R1 , . . . , Rn } descompone SPI.
1. Armar una matriz T (0) con las relaciones Ri en las filas (i = 1, . . . , k) y los atributos Aj en las columnas.
Cada elemento de la matriz tendrá valor:
(
aj si Aj ∈ Ri (variable distinguida)
mij =
bij si Aj 6∈ Ri (variable ligada)

2. i = 1
3. Obtener T (i) :

Para cada dependencia funcional X → Y ∈ F :

• Si ∃ tuplas t1 , t2 tal que t1 [X] = t2 [x], realizar un cambio de variable en t1 [Y ] y en t2 [Y ]
◦ Variables ligadas por distinguidas
◦ Si hay dos ligadas, poner la de menor subíndice

4. Si hay una fila sólo con variables distinguidas, devolver “verdadero”.

5. Si T (i) = T (i−1) y además no hay una fila sólo con variables distinguidas, devolver “falso”.
6. Si no, i ← i + 1 y volver a 3.

Ejemplo: sea el esquema de relación R(A, B, C, D) con F = {A → B, B → C, CD → A}. Sea la descompo-

sición R1 = (A, D), R2 = (A, C), R3 = (B, C, D). ¿La descomposición es SPI?
A B C D
R1 (A, D) a1 b12 b13 a4
R2 (A, C) a1 b22 a3 b24
R3 (B, C, D) b31 a2 a3 a4
Aplicamos A → B. Como a1 es igual en las primeras dos filas, pero b12 y b22 no, cambiamos b22 por b12 en
la segunda fila.
A B C D
R1 (A, D) a1 b12 b13 a4
R2 (A, C) a1 b12 a3 b24
R3 (B, C, D) b31 a2 a3 a4
Aplicamos B → C. Las filas 1 y 2 coinciden en b12 pero no en c. Entonces, cambiamos b13 por a3 en la fila 1.
A B C D
R1 (A, D) a1 b12 a3 a4
R2 (A, C) a1 b12 a3 b24
R3 (B, C, D) b31 a2 a3 a4

Base de Datos (75.15 - 95.05) - Resumen Página 32 de 75

12 Segunda forma normal (2FN)

Aplicamos CD → A. Las filas 1 y 3 tienen mismo valor para c y d, pero distinto valor para a. Por lo tanto,
cambiamos b31 por a1 en la tercera fila.
A B C D
R1 (A, D) a1 b12 a3 a4
R2 (A, C) a1 b12 a3 b24
R3 (B, C, D) a1 a2 a3 a4
En este punto notamos que la fila 3 tiene valores de la forma aj . Como son todas variables distinguidas, la
descomposición es sin pérdida de información.

12. Segunda forma normal (2FN)

Atributo primo atributo de R que pertenece a una clave candidata.
Segunda forma normal (2FN)

Sea R una relación y F el conjunto de sus dependencias funcionales. R estará en 2FN si para
toda dependencia funcional X → Y que está en en F + , se cumple al menos una de las siguientes
condiciones:

1. X → Y es trivial
2. Y es un atributo primo,
3. X no es un subconjunto de una clave candidata

ℵ
Ejemplo: la siguiente relación no está en 2FN porque Dirección de local depende sólo de ID de local, que
no es una clave.
ID de cliente ID de local Dirección de local
1 1 Los Angeles
1 3 San Francisco
2 1 Los Angeles
F = {Id cliente, Id local → Direccion local; Id local → Direccion local}.
La segunda dependencia funcional no es trivial, el lado derecho no pertenece a una clave candidata, y el lado
izquierdo es un subconjunto de la clave candidata.
Para normalizarla, hay que dividirla en dos relaciones.

ID de cliente ID de local
ID de local Dirección de local
1 1
1 Los Angeles
1 3
3 San Francisco
2 1

13. Forma normal Boyce-Codd (FNBC)

Forma normal Boyce-Codd (FNBC)

Un esquema de relación R está en FNBC con respecto a un conjunto de dependencias funcionales

F si, para todas las dependencias funcionales en F + de la forma α → β, donde α ⊆ R y β ⊆ R, se
cumple alguna de las siguientes:
α → β es trivial (es decir, β ⊆ α)
α es una superclave para R

Página 33 de 75 Base de Datos (75.15 - 95.05) - Resumen

 14 Tercera forma normal (3FN)

Propiedades de la forma normal Boyce-Codd (FNBC)

Cualquier relación de dos atributos está en FNBC

Brinda eliminación de anomalías

Brinda una descomposición SPI

No garantiza que se preserven las dependencias funcionales

Para verificar si una dependencia funcional α → β viola FNBC, alcanza con computar α+ y ver si es R.

Para verificar si una relación R está en FNBC, alcanza con ver si las dependencias de F no violan FNBC.

Para verificar si una descomposición Ri está en FNBC, para cada subconjunto α de atributos de Ri , verificar
que αF
+
o no incluya atributos de Ri − α, o incluya todos los atributos de Ri .

Algoritmo 8 Descomposición FNBC

Entrada: una relación R, un conjunto de dependencias funcionales F
Salida: una descomposición ρ = {R1 , . . . , Rn } tal que Ri está en FNBC con respecto a Fi
1. ρ = R
2. Repetir hasta que no haya esquemas en ρ que violen FNBC

a) Elegir una dependencia funcional X → Y que viole FNBC sobre ρi

b) Descomponer ρi en dos relaciones:
R1 (XY )
R2 (X(R − XY ))
c) En ρ, reemplazar ρi por R1 y R2
3. Devolver ρ

14. Tercera forma normal (3FN)

A statement of Codd’s definition of 3NF, paralleling the traditional pledge to give true evidence in a
court of law, was given by Bill Kent: [Every] non-key [attribute] must provide a fact about the key,
the whole key, and nothing but the key. A common variation supplements this definition with the
oath: so help me Codd.

Requiring existence of the key ensures that the table is in 1NF; requiring that non-key attributes be
dependent on the whole key ensures 2NF; further requiring that non-key attributes be dependent on
nothing but the key ensures 3NF.

Base de Datos (75.15 - 95.05) - Resumen Página 34 de 75

14 Tercera forma normal (3FN)

Tercera forma normal (3FN)

Un esquema de relación R está en 3FN con respecto a un conjunto de dependencias funcionales F

si, para todas las dependencias funcionales en F + de la forma α → β, donde α ⊆ R y β ⊆ R, se
cumple alguna de las siguientes:

α → β es trivial (es decir, β ⊆ α)

α es una superclave para R
β es un atributo primo

Dicho de otra forma, R no debe tener dependencias funcionales transitivas: todos los atributos que
no son clave deben depender funcionalmente de la clave primaria.

ℵ
Propiedades de la tercera forma normal (3FN)

No tiene pérdida de información

No hay pérdida de dependencias

No garantiza la eliminación de anomalías (es decir, tiene redundancia)

Es menos estricta que FNBC (FNBC =⇒ 3FN)

Algoritmo 9 Descomposición 3FN

Entrada: una relación R, un cubrimiento minimal Fmin
Salida: una descomposición ρ = {R1 , . . . , Rn } tal que Ri está en 3FN con respecto a Fi

1. ρ = {}
2. Para cada dependencia funcional X → Y ∈ Fmin :
ρ = ρ ∪ Ri (XY )
3. Si existen Ri , Rj ∈ ρ tal que Ri ⊆ Rj :
ρ = ρ − Ri
4. Si ninguna relación es una superclave de R, y K es una clave para R
ρ=ρ∪K
5. Devolver ρ

Ejemplo: la siguiente relación no está en 3FN porque Fecha de nacimiento del ganador depende sólo de
Ganador, que depende de la clave candidata {Torneo, Año}.
Torneo Año Ganador Fecha de nacimiento de ganador
Indiana Invitational 1998 Al Fredrickson 21 Julio 1975
Cleveland Open 1999 Bob Albertson 28 Septiembre 1968
Des Moines Masters 1999 Al Fredrickson 21 Julio 1975
Indiana Invitational 1999 Chip Masterson 14 Marzo 1977
F = {T orneo, Año → Ganador, Ganador → F echa nacimiento ganador}. La segunda dependencia funcio-
nal no es trivial, el lado derecho no pertenece a una clave candidata (no es atributo primo), y el lado izquierdo
no es una superclave.
Para normalizarla, hay que dividirla en dos relaciones.

Página 35 de 75 Base de Datos (75.15 - 95.05) - Resumen

 15 Dependencias multivaluadas

Torneo Año Ganador

Ganador Fecha de nacimiento
Indiana Invitational 1998 Al Fredrickson
Chip Masterson 14 Marzo 1977
Cleveland Open 1999 Bob Albertson
Al Fredrickson 21 Julio 1975
Des Moines Masters 1999 Al Fredrickson
Bob Albertson 28 Septiembre 1968
Indiana Invitational 1999 Chip Masterson

15. Dependencias multivaluadas

Una dependencia multivaluada expresa que dos conjuntos de atributos en un esquema son mutuamente
independientes.
Sean los conjuntos de atributos disjuntos A y B de la relación R(A, B, U − A − B). Sean las tuplas t1 y t2 .
La dependencia multivaluada A  B indica que si t1 [A] = t2 [A], entonces podemos encontrar tuplas t3 y t4
tales que:

t1 [A] = t2 [A] = t3 [A] = t4 [A]

t3 [B] = t1 [B]

t3 [U − A − B] = t2 [U − A − B]

t4 [B] = t2 [B]

t4 [U − A − B] = t1 [U − A − B]

Figura 20: Dependencia multivaluada α  β

Ejemplo: sea R(curso, libro, prof esor) una relación que indica una lista de cursos universitarios, los libros
que se usan en el curso, y los profesores que la dictan.

Curso Libro Profesor

Álgebra II David Lay - Algebra Lineal Acero
Álgebra II Strang - Algebra Lineal Acero
Álgebra II David Lay - Algebra Lineal Piortrowsky
Algebra II Strang - Algebra Lineal Piortrowsky

Dado que los profesores de un curso y los libros de un curso son independientes entre sí, esta relación tie-
ne una DMV. Si tuviésemos que agregar un nuevo libro al curso “Álgebra II”, deberíamos agregar una tupla
para cada profesor del curso. Es decir, formalmente, hay dos DMV en esta relación: {curso}  {libro} y
{curso}  {prof esor}. Esta relación exhibe redundancia.

Dependencia multivaluada: no existen en el esquema original pero son satisfechas por la descomposición
del mismo.

15.1. Propiedades de las DMVs

α  β es trivial si β ⊆ α ó si R = αβ.

Una dependencia multivaluada garantiza que ciertas tuplas existan.

Regla de transitividad multivaluada: Si α  β y β  c, entonces α  c − β

Base de Datos (75.15 - 95.05) - Resumen Página 36 de 75

15.2 Preservación de dependencias multivaluadas

Regla de replicación: si α → β, entonces α  β. La inversa no es cierta.

( (
αβ Z⊆β
Regla de interacción : si
2
y existe un γ tal que , entonces α → Z
γ→Z γ∩β =∅

Regla de aumentación: si α  β entonces αw  β.

Regla del complemento: si α  β, entonces α  R − αβ

Regla de unión: si α  β, y α  c, entonces α  βc


α  β − c

Regla de descomposición: si α  β, y α  c, entonces α  c − β

αβ∩c


Regla de pseudotransitividad: si α  β y βc  γ, entonces αc  γ − βc

Si R = {A1 , . . . , An , B1 , . . . , Bm }, entonces {A1 , . . . , An }  {B1 , . . . , Bm }

Teorema: las únicas DMVs implicadas por un conjunto de DFs son de la forma X  Y , donde Y ⊆ X + o
R − XY ⊆ X + .
Teorema: las únicas DFs implicadas por un conjunto de DMVs son las triviales.
Teorema: un conjunto de DFs de tipo xi → yi sólo implica DMVs de tipo xi  yi .
Teorema: sea r una instancia del esquema de relación R, X, Y subconjuntos de R, y Z = R − XY . La
relación r satisface la DMV X  Y sí y solo sí R1 = XY y R2 = X ∪Z descomponen sin pérdida de información
a r.

Algoritmo 10 Verificar si r satisface la dependencia multivaluada X  Y

Entrada: relación r(R)
Salida: “verdadero” si la dependencia multivaluada X  Y se satisface
1. Proyectar r en R1 (XY ) y R2 (X, R − XY )

2. Calcular R1 ./ R2
3. Si r = R1 ./ R2 devolver “verdadero”

Algoritmo 11 Proyección de dependencias funcionales y multivaluadas

Entrada: conjunto de dependencias funcionales y multivaluadas D+ , descomposición {R1 , . . . , Rn }
Salida: conjunto de dependencia funcionales y multivaluadas Di que se satisfacen en Ri
1. Z = {}

2. Agregar a Z las dependencias funcionales de D+ que solo incluyan atributos de Ri

3. Agregar a Z las dependencias multivaluadas de la forma A → B ∩ Ri , donde A  B esté en D+ y A ⊆ Ri
4. Devolver Z

15.2. Preservación de dependencias multivaluadas

Una descomposición de R en los esquemas R1 , . . . , Rn es una descomposición que preserva las depen-
dencias con respecto a un conjunto D de dependencias funcionales y multivaluadas si, para cada relación
r1 (R1 ), . . . , rn (Rn ) tal que para cada i, ri satisface Di , entonces existe una relación r(R) que satisface D y para
el cual ri = πRi (r) para todo i.
2 Esta regla puede agregar dependencias funcionales a M

Página 37 de 75 Base de Datos (75.15 - 95.05) - Resumen

 15.3 Base minimal de Dependencias e Implicación de DMVs

15.3. Base minimal de Dependencias e Implicación de DMVs

Base minimal sea la colección de conjuntos S = {S1 , . . . , Sp } donde U = S1 ∪ . . . ∪ Sp . La base minimal de S
es Base(S) y es una partición de U {T1 , . . . , Tq } tal que:

1. Cada Si es la unión de algunos de los Tj .

2. No existe una partición de U con menos elementos que cumpla la primera propiedad.

Ejemplo: sea S = {ABCD, CDE, AE} y U = ABCDE. Entonces la base de S es Base(S) = {A, B, CD, E}.

Base de dependencias sea M un conjunto de dependencias multivaluadas sobre R, y sea X ⊆ R. Sea G =

{Y /M |= X  Y }. La base de dependencias de X con respecto a M es:

Bdep(X) = Base (G)

Ejemplo: sea M = {A  BC, DE  C} un conjunto de dependencias multivaluadas sobre R(ABCDE).

Entonces G = {A, BC, DE, C, BDE, B, BCDE, CDE}y la base de A es

Base(A) = {A, B, C, DE}

Algoritmo 12 Cálculo de la base de dependencias de X

Entrada: conjunto de dependencias multivaluadas M , conjunto de atributos X
Salida: Bdep(X)

1. T = R − X
2. Mientras T varíe:
Si ∃V ∈ T y Y  Z ∈ M tal que (V ∩ Y = ∅) y (V ∩ Z 6= ∅)
Reemplazar V por {V ∩ Z} y {V − Z}
3. Bdep(X) = T ∪ {A/A ∈ X}

Implicación de dependencias dado un conjunto M de dependencias multivaluadas, una dependencia multi-

valuada X  Y pertenece a M + sí y solo sí Y se puede expresar como la unión de algunos componentes
de Bdep(X).

Ejemplo: sea R(A, B, C, D, E, I), M = {A  EI, C  AB}. ¿Se cumple AC  BI?

La base de dependencias de AC es:

1. T (0) = BDEI

a) V = BDEI. Entonces A  EI, Y = A, Z = EI

b) V ∩ Z = EI
c) V − Z = BD

2. T (1) = {EI, BD}

a) Si V = EI, Y = A, Z = EI, V ∩ Z = EI, V − Z = {} y no nos aporta nada.

b) V = BD. Entonces C  AB, Y = C, Z = AB
c) V ∩ Z = B
d) V − Z = D

3. T (2) = {EI, B, D}

Bdep(AC) = {EI, B, D, A, C} y entonces AC  BI no se cumple porque BI no se puede expresar como la

unión de componentes de Bdep(AC).

Base de Datos (75.15 - 95.05) - Resumen Página 38 de 75

16 Cuarta forma normal (4FN)

16. Cuarta forma normal (4FN)

Cuarta forma normal (4FN)

Un esquema de relación R está en 4FN con respecto a un conjunto de dependencias funcionales y

multivaluadas M si, para todas las dependencias multivaluadas en M + de la forma α  β, donde
α ⊆ R y β ⊆ R, se cumple alguna de las siguientes:
α  β es trivial
α es una superclave para R

ℵ
Propiedades de la cuarta forma normal (4FN)

No tiene pérdida de información

Una descomposición 4FN no garantiza la preservación de dependencias

ℵ
Ejemplo: la siguiente relación no está en 4FN. La clave es {N ° V uelo, Dia de la semana, T ipo de avión}.

N° Vuelo Dia de la semana Tipo de avión

106 Lunes B737
106 Martes B737
106 Lunes A380
106 Martes A380

F = {N ° V uelo  Dia de la semana, N ° V uelo  T ipo de avión}. La primera dependencia multivaluada no

es trivial, y el lado izquierdo no es una superclave de R.
Para normalizarla, hay que dividirla en dos relaciones.

N°Vuelo Dia de la semana N° Vuelo Tipo de avión

106 Lunes 106 B737
106 Martes 106 A380

16.1. Descomposición SPI en 2 relaciones

Sea el esquema relacional R, y sea M el conjunto de dependencias funcionales y multivaluadas sobre R. Sean
R1 y R2 una descomposición de R. Esta descomposición es sin pérdida de información (SPI) si al menos una
de las siguientes dependencias multivaluadas está en M + :

1. R1 ∩ R2  R1 − R2

2. R1 ∩ R2  R2 − R1

16.2. Descomposición SPI en más de 2 relaciones

El algoritmo es idéntico al de descomposición en BCFN, excepto que se usan dependencias multivaluadas y
se restringe Ri al conjunto M + .

Página 39 de 75 Base de Datos (75.15 - 95.05) - Resumen

 17 Dependencias de junta

Algoritmo 13 Descomposición 4FN

Entrada: una relación R, un conjunto de dependencias multivaluadas M +
Salida: una descomposición ρ = {R1 , . . . , Rn } tal que Ri está en 4FN con respecto a Mi
1. ρ = R
2. Repetir hasta que no haya esquemas en ρ que violen 4FN
a) Elegir una dependencia multivaluada X  Y que viole 4FN sobre ρi
b) Descomponer ρi en 2 relaciones:
R1 (XY )
R2 (X(R − XY ))
c) En ρ, reemplazar ρi por R1 , R2
3. Devolver ρ

17. Dependencias de junta

Sea un esquema de relación R y sea la descomposición R1 , . . . , Rn . La dependencia de junta ∗ (R1 , . . . , Rn )
restringe el conjunto de relaciones posibles a aquellas para las cuales R1 , . . . Rn es una descomposición sin
pérdida de información.
Formalmente, si R = R1 ∪ · · · ∪ Rn , una relación r(R) satisface la dependencia de junta ∗ (R1 , . . . , Rn ) si

r = πR1 (r) ./ · · · ./ πRn (r)

La dependencia de junta ∗ (R1 , . . . , Rk ) se satisface para R si restringe los valores de toda instancia r(R) tal
que, si existen k tuplas t1 , . . . , tk que satisfacen ti [Ri ∩ Rj ] = tj [Ri ∩ Rj ], luego también existe en r otra tupla
tk+1 definida por tk+1 [Ri ] = ti [Ri ] para 1 ≤ i ≤ k.
Propiedades:
Si una de las Ri es R, la dependencia de junta es trivial.
Toda dependencia de junta ∗(R1 , R2 ) es equivalente a la dependencia multivaluada R1 ∩ R2  R2 .
No existen un conjunto de reglas para inferir dependencias de juntas.
Teorema: R satisface la dependencia multivaluada X  Y sí y sólo sí R descompone sin pérdida sobre los
esquemas X ∪ Y y X(R − XY ), es decir, si R satisface la dependencia de junta ∗ (XY, X(R − XY ))
Teorema: si una relación R puede descomponerse SPI en 3 esquemas, pero no puede hacerlo sobre 2, esa
relación solo satisface DMVs triviales.  

Ejemplo: sea la relación R(A, B, C) y la dependencia de junta ∗ |{z}

AB , |{z} AC . ¿Qué tupla debe tener
BC , |{z}
R1 R2 R3
r para satisfacer la misma?

r A B C
t1 1 2 3
4 5 6
t2 4 2 7
t3 1 8 7

Dado que se cumplen:

t1 [R1 ∩ R2 ] = t2 [R1 ∩ R2 ] = 2
t1 [R1 ∩ R3 ] = t3 [R1 ∩ R3 ] = 1
t2 [R2 ∩ R3 ] = t3 [R2 ∩ R3 ] = 7
Entonces para que se satisfaga la dependencia de junta deberá existir una tupla t4 tal que:

Base de Datos (75.15 - 95.05) - Resumen Página 40 de 75

17.1 Dependencias de junta embebidas

t4 [R1 ] = t1 [R1 ] = {1, 2}

t4 [R2 ] = t2 [R2 ] = {2, 7}

t4 [R3 ] = t3 [R3 ] = {1, 7}

Es decir, deberá existir la tupla (1, 2, 7).

17.1. Dependencias de junta embebidas

Un esquema de relación r(R) satisface la dependencia de junta embebida DJE ∗ (R1 , . . . , Rp ) si πS (r)
satisface la dependencia de junta ∗ (R1 , . . . , Rp ), donde S = R1 R2 . . . Rp .
Notar que r puede no satisfacer la DJE.

18. Quinta forma normal (5FN)

Quinta forma normal (5FN)

Una relación R está en 5FN con respecto a un conjunto de dependencias funcionales, multivaluadas
y de junta D, si para todas las dependencias de junta en D+ de la forma ∗ (R1 , . . . , Rn ) donde cada
Ri ⊆ R y R = R1 ∪ · · · ∪ Rn , al menos una de las siguientes condiciones se cumple:

La dependencia de junta ∗ (R1 , . . . , Rn ) es trivial

Cada Ri es una superclave de R

ℵ
Propiedades de la quinta forma normal (5FN)

Toda relación que está en 5FN está en 4FN, y está en BCNF.

Una descomposición 5FN no garantiza la preservación de dependencias.

Algoritmo 14 Descomposición 5FN

Entrada: una relación R, un conjunto de dependencias D+
Salida: una descomposición ρ = {R1 , . . . , Rn } tal que Ri está en 5FN con respecto a Di
1. ρ = R
2. Repetir hasta que no haya esquemas en ρZ que violen 5FN

a) Elegir una dependencia de junta ∗ (DJ1 , . . . DJk )que viole 5FN sobre ρi
b) Descomponer ρi en k relaciones:
R1 (DJ1 )
Rk (DJk )
c) En ρ, reemplazar ρ por R1 , . . . , Rk
3. Devolver ρ



 ∗ (ABCD, CDE, BDI)

∗ (AB, BCD, AD)
Ejemplo: sea D = sobre el esquema de relación R = ABCDEI.


 A → BCDE
BC → AI

Las clave candidata de R son, por las dependencias funcionales, {A, BC}.

Página 41 de 75 Base de Datos (75.15 - 95.05) - Resumen

 18.1 Implicación de dependencias

R no está en 5FN porque la dependencia de junta ∗ (ABCD, CDE, BDI) no es trivial, y CDE, BDI no
son superclaves de R.

R1
 = ABCD
La descomposición R = R2 = CDE sí está en 5FN porque:

R3 = BDI


Para R1 aplica la dependencia de junta ∗ (AB, BCD, AD), y todos los miembros son superclaves de R,
por lo tanto está en 5FN.

Para R2 solo aplican dependencias de junta triviales.

Para R3 solo aplican dependencias de junta triviales.

18.1. Implicación de dependencias

Utilizar el algoritmo Chase Tableau

Aclaración del Ejemplo

Convertir A →→ C en |x|(AC, ABD)

La primer fila representa AC y la segunda ABD
Aplicar las dependencias

Base de Datos (75.15 - 95.05) - Resumen Página 42 de 75

18.1 Implicación de dependencias

Página 43 de 75 Base de Datos (75.15 - 95.05) - Resumen

Parte III
SQL
Componentes:

1. DDL (Data Definition Language)

2. DML (Data Manipulation Language)

3. CL (Control Language)

Para identificar unívocamente a una relación, se utiliza el formato <catalogo>.<esquema>.<relación>

19. DDL
DDL: Lenguaje de definición de datos para especificar el esquema de la base de datos, eliminar relaciones,
modificar esquemas, crear vistas, crear restricciones de integridad, especificar derechos de acceso, etc.

19.1. Tipos de dominios

char(n): texto de longitud n

varchar(n): texto de longitud variable, con un máximo de n caracteres

nvarchar(n): texto de longitud variable, con un máximo de n caracteres, utilizando el formato Unicode

int

smallint

numeric(p,d): p dígitos con signo, y d de los p dígitos están a la derecha del punto decimal.

real, double precision

float(n)

date

time

timestamp

clob(n): character large object de n bytes

blob(n): binary large object de n bytes

19.2. Create table

1 CREATE TABLE r ( A1 D1 , A2 D2 , ... , An Dn ,
2 < restriccion - integridad1 > ,
3 ... ,
4 < restriccion - integridadK >) ;

La instrucción anterior crea una tabla llamada r con atributos Ai , y Di es el dominio del atributo Ai .
Las restricciones de integridad pueden ser:
primary key (Aj1 , Aj2 , . . . , Ajm ): los atributos Aji , con i ∈ [1, m] forman la clave primaria de cada tupla.
No pueden ser null, y deben ser únicos.

check (P ): todas las tuplas de r deben satisfacer el predicado P .

foreign key:

Base de Datos (75.15 - 95.05) - Resumen Página 44 de 75

19.3 Drop table

1 FOREIGN KEY ( atr ) REFERENCES rel

2 ON [ UPDATE | DELETE ] [ CASCADE | SET NULL | SET DEFAULT ];

Se establece que el atributo atr es una clave primaria en la relación rel. Se puede especificar lo que sucede
si se produce una actualización o un borrado de dicho valor en la relación rel:

• Cascade: se actualiza/elimina la tupla en esta relación

• Set null: la clave foránea se establece en null
• Set default: la clave foránea se establece en su valor por default

assert: define una restricción aplicable a varias tablas.

1 CREATE ASSERTION nombre_asercion
2 CHECK P

19.3. Drop table

La instrucción DROP TABLE r elimina todas las tuplas de la tabla r y el esquema de relación r.

19.4. Alter table

La instrucción puede utilizarse para agregar atributos nuevos (con valor null ) o para eliminarlos.
1 ALTER TABLE r
2 ADD < Atributo > < Dominio >;
3 ALTER TABLE r
4 DROP < Atributo >;

Diccionario de datos: contiene metadatos (información sobre los datos), en particular, sobre el esquema
de la misma.

20. DML
DML: lenguaje de manipulación de datos para expresar las consultas a la base de datos.
Operaciones CRUD (Create, Read, Update, Delete)

Álgebra relacional SQL

πattr (r) SELECT attr FROM r
σcond (r) SELECT * FROM r WHERE cond
r×s SELECT * FROM r,s

La expresión
1 SELECT a1 , a2 , ... , an
2 FROM r1 , r2 , ... , rm
3 WHERE p ;

es equivalente a la expresión πa1 ,a2 ,...,an (σp (r1 × r2 × · · · × rm )).

El resultado de una expresión SQL puede contener tuplas duplicadas. Para eliminar los duplicados, se
utiliza la cláusula SELECT DISTINCT.

Las funciones agregadas no se pueden componer. Por ejemplo, max(count(*)) no es válido.

Una cláusula de tipo SELECT * indica que se seleccionan todos los atributos de las relaciones en la cláusula
FROM.

El operador de renombre as: SELECT viejo-nombre AS nuevo-nombre

El operador like se puede usar dentro de una cláusula where para buscar valores que cumplan un patrón,
especificado con los siguientes caracteres especiales:

Página 45 de 75 Base de Datos (75.15 - 95.05) - Resumen

 20.1 Consultas anidadas

• %: matchea cualquier sub string

• _: matchea un caracter cualquiera

El operador order by <atributo(s)>[asc|desc] ordena el resultado de una consulta por uno o varios
de los atributos, de forma ascendente o descendente (ascendente por default).

Operadores sobre conjuntos:

• Union
• Intersect
• Except

El operador group by permite agrupar tuplas en base a uno o más atributos (las tuplas con el mismo valor
para los atributos en esta cláusula se ponen en un mismo grupo). Los atributos en la cláusula select, por
fuera de las funciones agregadas, deben estar en el operador group by. La sintaxis es:
1 SELECT expr1 , ... , exprN , funcionAgregada ( expr )
2 FROM tablas
3 WHERE condiciones
4 GROUP BY expr1 , ... , exprN ;

Ejemplo: encontrar el promedio del saldo de las cuentas en cada sucursal de un banco.
1 SELECT sucursal - nombre , AVG ( saldo )
2 FROM cuentas
3 GROUP BY sucursal - nombre ;

El operador having permite seleccionar a grupos formados con group by que cumplan una condición.
Cualquier atributo que esté presente en la cláusula having sin agregar, debe aparecer en el operador group
by.
1 SELECT columna , funcion_agregada ( columna )
2 FROM tabla
3 WHERE columna operator value
4 GROUP BY columna
5 HAVING funcion_agregada ( columna ) operator value ;

Ejemplo: encontrar los nombres de las sucursales del banco que tengan un promedio general de saldo mayor
a $1200.
1 SELECT sucursal - nombre
2 FROM cuentas
3 GROUP BY sucursal - nombre
4 HAVING AVG ( saldo ) > 1200

Nota: si se utilizan el operador where y el operador having, primero se aplica el where y luego se filtra por
having.

20.1. Consultas anidadas

En una consulta anidada, el select interno puede tener variables de tuplas definidas dentro del select, o
en cualquier consulta que incluya a ésta.

El conector in permite verificar la pertenencia de un valor a un conjunto que es resultado de una cláusula
select. De forma equivalente, existe el conector not in.
Ejemplo: encontrar los nombres de los clientes que tienen un préstamo y una cuenta en el banco.
1 SELECT DISTINCT cliente - nombre
2 FROM pidio - prestamo
3 WHERE cliente - nombre IN ( SELECT cliente - nombre
4 FROM tiene - cuenta ) ;

Base de Datos (75.15 - 95.05) - Resumen Página 46 de 75

20.1 Consultas anidadas

El operador de comparación some en una cláusula where de un select externo devuelve verdadero si el
valor del atributo en cuestión es mayor o menor que al menos un valor de la cláusula select interna.
Ejemplo: encontrar los nombres de las sucursales del banco que tienen activos mayores que los de al menos
una sucursal en Brooklyn.
1 SELECT sucursal - nombre
2 FROM sucursales
3 WHERE activos > SOME ( SELECT activos
4 FROM sucursales
5 WHERE sucursal - nombre = ’ Brooklyn ’) ;

El operador de comparación all en una cláusula where de un select externo devuelve verdadero si el
valor del atributo en cuestión es mayor a todos los valores de la cláusula select interna.
Ejemplo: encontrar los nombres de las sucursales del banco que tienen activos mayores que los todas las
sucursales en Brooklyn.
1 SELECT sucursal - nombre
2 FROM sucursales
3 WHERE activos > ALL ( SELECT activos
4 FROM sucursales
5 WHERE sucursal - nombre = ’ Brooklyn ’) ;

El operador any devuelve verdadero si existe al menos un valor para

Ejemplo: encontrar los clientes que pidieron un préstamo de monto mayor a al menos los activos de una
sucursal.
1 SELECT cliente - nombre
2 FROM pidio - prestamo
3 WHERE cantidad > ANY ( SELECT activos
4 FROM sucursales ) ;

El operador exists devuelve verdadero si la consulta interna no es vacía.

Ejemplo: encontrar los clientes que tienen una cuenta y un préstamo en el banco.
1 SELECT cliente - nombre
2 FROM pidio - prestamo
3 WHERE EXISTS ( SELECT *
4 FROM tiene - cuenta
5 WHERE pidio - prestamo . cliente - nombre =
tiene - cuenta . cliente - nombre ) ;

El operador unique devuelve verdadero si la consulta interna no contiene tuplas duplicadas.

SQL no ofrece en forma nativa la posibilidad de ejecutar el operador división. Sin embargo, este se puede
implementar usando consultas anidadas.
Ejemplo: dados los siguientes esquemas relacionales
Estudiante ( Enro , Enombre , Carrera , Anio_cursa , Edad )
Curso ( Cnombre , Horario , Aula , Pid )
Cursa ( Enro , Cnombre )
Profesor ( Pid , Pnombre , departamento )
Hallar los nombres de todos los profesores que enseñan en todas las aulas en las que se dicta algún curso.
1 SELECT P . Pnombre
2 FROM Profesor P
3 WHERE NOT EXISTS ( SELECT C . Aula
4 FROM Curso C1
5 WHERE NOT EXISTS ( SELECT *
6 FROM Curso C2
7 WHERE C2 . Aula = c1 . Aula
8 AND C2 . Pid = P . Pid ) ) ;

Página 47 de 75 Base de Datos (75.15 - 95.05) - Resumen

 20.2 Delete

20.2. Delete
Sintaxis para el borrado de tuplas de la relación r para las cuales P es verdadera:
1 DELETE FROM r
2 WHERE P

Sólo se borra de una relación.

Sólo se borran tuplas (no atributos de tuplas).

Primero se buscan todas las tuplas que satisfacen P , y luego se borran todas ellas.

20.3. Insert
Sintaxis para la inserción de tuplas en la relación r:
1 INSERT INTO r ( nombreAtributo1 , ... , nombreAtributoN )
2 VALUES ( valor1 , ... , valorN )

1 INSERT INTO r
2 SELECT (...)

Primero se buscan todas las tuplas que satisfacen el select, y luego se insertan todas ellas.

20.4. Update
Sintaxis para la actualización de un atributo de una tupla de r:
1 UPDATE r
2 SET atributo = valor
3 WHERE condicion

1 UPDATE r
2 SET atributo = CASE
3 WHEN condicion1 THEN valor1
4 WHEN condicion2 THEN valor2
5 ELSE valor3
6 END

Base de Datos (75.15 - 95.05) - Resumen Página 48 de 75

Parte IV

Procesamiento de Consultas

Figura 21: Pasos en el procesamiento de consultas

Asumimos que toda la relación se almacena de forma contigua en disco.

Metadatos que se almacenan para cada base de datos:

1. nr = cantidad de tuplas en la relación r

2. lr = tamaño de una tupla, en bytes

3. br = cantidad de bloques que ocupa la relación r.

lr × n r
br =
tam bloque en bytes

4. fr = factor de bloqueo de la relación r (es decir, cuantas tuplas caben en un bloque)

 
nr
fr =
br

5. V (A, r) =cantidad de valores distintos que toma el atributo A en la relación r

6. M IN (A, r) =mínimo valor que toma el atributo A en la relación r

7. M AX(A, r) =máximo valor que toma el atributo A en la relación r

Página 49 de 75 Base de Datos (75.15 - 95.05) - Resumen

 21 Índices

Figura 22: Estadísticas que se almacenan de la base de datos

21. Índices
Ciertas consultas sobre algunos atributos son más frecuentes que otras. Para acelerar estas consultas, se
utilizan los índices. Podemos tener más de un índice sobre una relación.

Índice Estructura de datos (usualmente árbol B+) que permiten encontrar rápidamente las tuplas de una
relación que tengan un valor especifico para un atributo o atributos (el/los que el índice almacena), con
la desventaja de que cada modificación a la relación requiere actualizar el índice.
Un registro de un índice tiene un valor de la clave de búsqueda, y punteros a uno o más tuplas con esa
clave de búsqueda.

1 CREATE [ CLUSTERED ] INDEX estudianteID_indice

2 ON estudiante {
3 ID ASC
4 };

Tipos de índices:

Según la clave:

• Clusterizado / primario: índice cuya clave de búsqueda define el orden secuencial del archivo de
la tabla. Sólo puede haber uno de estos índices para cada relación
• Clusterizado / secundario.
◦ El orden físico de las tuplas no es igual al orden del índice
◦ Las columnas que se indexan son, típicamente, atributos no claves
◦ Siempre son densos

Según la cantidad de registros que tiene:

• Denso: tiene un registro para cada valor posible de la clave de búsqueda. Si es clusterizado, tiene
un puntero al primer registro con ese valor. Si es no clusterizado, tiene punteros a todos los registros
con ese valor.
• Esparcido: tiene registros para algunos valores de la clave de búsqueda. Solo se pueden usar si el
archivo de datos está ordenado por la clave de búsqueda.

Esparcido =⇒ P rimario

Secundario =⇒ Denso

Base de Datos (75.15 - 95.05) - Resumen Página 50 de 75

21.1 Estructuras de índices

(a) Índice denso (b) Índice esparcido

Figura 23: Índices densos y esparcidos

Índice compuesto índice cuya clave de búsqueda está formada por más de un atributo. Conviene que los
atributos de más a la izquierda sean más discriminantes que los de la derecha. Ejemplo: para una relación
pelicula(nombre, año), es esperable que haya más consultas sobre el nombre que sobre el año. Entonces,
un índice (nombre, año) sería mejor que (año, nombre).

Índice cubridor Es un índice que contiene todas las columnas de una consulta, y por ende no se necesita
realizar búsquedas adicionales en el índice clusterizado.

21.1. Estructuras de índices

Árbol B+

Tabla de hash

Ventajas Desventajas
Árbol B+ Soporta búsquedas por rango Operaciones más costosas
Tabla de hash La búsqueda típica requiere solo No soporta búsquedas por rango.
una operación de I/O

22. Formas de realizar consultas

1. Búsqueda lineal sobre toda la relación

2. Usando índices

3. Hashing

4. Ordenamiento

Los algoritmos pueden asumir que una relación entra completamente en memoria, o que son muy grandes.

22.1. Operadores
Scan

• Table scan: se leen todos los bloques de la relación en disco.

• Index scan: se leen todos los bloques de la relación en disco, utilizando un índice.
• Sort scan: ordena una relación R sobre un atributo a.
◦ Si hay un índice sobre a, se lo usa.
◦ Si R entra en memoria, se la trae a memoria con table o index scan, y se la ordena en memoria
◦ Si R no entra en memoria, se la ordena externamente.

Página 51 de 75 Base de Datos (75.15 - 95.05) - Resumen

 23 Algoritmos

23. Algoritmos
23.1. Selección
σA=a (r)

Búsqueda lineal sobre r:

• Si la relación es clusterizada: br
• Si la relación no está clusterizada: nr

Búsqueda con índice sobre los atributos de A:

• Si el índice es clusterizado: costo br

V (A,r)

• Si el índice no es clusterizado: costo V (A,r)

nr

23.2. Junta
R(X, Y ) ./ S(Y, Z), donde R es la relación más pequeña. Suponemos que la memoria está formada por M
buffers.

Iteración ingenua (tuple based nested-loop join):

• costo ns × nr

1 para cada tupla s en S :

2 para cada tupla r en R :
3 si ( s join r = t ) :
4 devolver t

Iteración por bloques (block based nested-loop join):

• Costo br + br
m−1 × bs (R se lee una vez, S se lee por cada pedazo de R, cada pedazo es de tamaño
m−1 )
br

• Conviene que la relación del ciclo externo sea la más pequeña

1 desde i =1 hasta i =( bR / m -1) :

2 leer R en memoria ( ocupar M -1 buffers )
3 para cada bloque bs en S :
4 leer bs en memoria ( ocupar 1 buffer )
5 para cada tupla t en bs :
6 buscar las tuplas de R en que hacen join con t
7 devolver t

Indexed nested-loop join: suponer que se tiene un índice sobre S del atributo Y .

• Si el índice es clusterizado: costo br + nr bs

V (Y,S)

• Si el índice no es clusterizado: costo br + Vn(Y,S)

r ns

• Este método es eficiente cuando S no está almacenada en forma contigua en disco.

1 para cada bloque br de R :

2 para cada tupla t de br :
3 buscar con el indice las tuplas de S que hacen join con t
4 para cada tupla s join t :
5 agregar <s ,t > al resultado

Sort-merge (sort based join):

• Costo bs + br + bs log(bs ) + br log(br )

Base de Datos (75.15 - 95.05) - Resumen Página 52 de 75

23.2 Junta

1 ordenar R con respecto a Y

2 ordenar S con respecto a Y
3 mergear R y S :
4 encontrar min ( R ) y min ( S )
5 si min ( R ) > min ( S )
6 quitar las tuplas de S con Y como atributo
7 leer S
8 si min ( R ) < min ( S )
9 quitar las tuplas de R con Y como atributo
10 leer R
11 si min ( R ) == min ( S )
12 agregar r join s al resultado
13 leer R
14 leer S

Método Simple de Junta Hash: utiliza una función de hash h. Requiere que la relación R entre en memoria.
h → [0, M − 1].
• Costo: br + bs

1 TH = {} // en memoria
2
3 // fase constructiva . Costo : bR
4 para cada bloque de R :
5 para cada tupla r del bloque :
6 calcular h ( r [ Y ])
7 guardar TH [ Y ] = r
8
9 // fase exploratoria . Costo : bS
10 para cada bloque de S :
11 para cada tupla s del bloque :
12 calcular h ( s [ Y ])
13 agregar al resultado las tuplas de TH [ Y ] join " s "

Método GRACE:
El método de junta Hash versión GRACE se usa para calcular la junta R ./R.A=S.A S cuando ninguna
de las tablas entran en memoria. Lo que se hace es generar 2 conjuntos de M particiones. Se utilizan dos
funciones de hash: una para generar las particiones h : A → [0, M − 1], y otra para calcular qué tuplas
hacen join.
Etapa 1: Particionamiento
- Por cada tupla t de R se aplica la función de hashing h(t) para saber a qué partición enviar la
tupla, sí la partición se completa se graba en disco. Al finalizar la etapa, se graban las M particiones a
disco.
- Se hace lo mismo con S, pero con otros M archivos. La clave está en que si dos tuplas hacen join,
entonces necesariamente deben estar en el mismo número de partición.
De este modo R queda particionada en Ri subconjuntos con 0 ≤ i ≤ M − 1, del mismo modo que S queda
particionada en Si subconjuntos.
Etapa 2: Junta (para cada i)
- Para cada tupla de un Ri se le aplica la función de hash h2 para saber dónde guardarla en una
tabla de hash en memoria (T H).
- Se calcula h2 para cada tupla de un Si y se verifica si en T H existe alguna tupla juntable, si es
así se emite una tupla de resultado y se continua con la siguiente tupla de Si .
• Costo: 3 (bs + br )

1 // particionamiento de R . Costo : 2 bR (1 por lectura y 1 por escritura )

2 para cada tupla r de R :
3 num buffer = calcular h1 ( r [ Y ])

Página 53 de 75 Base de Datos (75.15 - 95.05) - Resumen

 24 Evaluación de expresiones

4 guardar " r " en el buffer

5 si ( buffer completo )
6 guardarlo en disco Ri
7 // particionamiento de S . Costo : 2 bS (1 por lectura y 1 por escritura )
8 para cada tupla s de S :
9 num buffer = calcular h1 ( s [ Y ])
10 guardar " s " en el buffer
11 si ( buffer completo )
12 guardarlo en disco Si
13
14 // metodo simple de hash . Costo : bR + bS
15 para i desde 0 a M -1:
16 leer Ri
17 para cada tupla r en Ri :
18 calcular h2 ( r [ Y ])
19 guardar TH [ r [ Y ]] = r
20 leer Si
21 para cada tupla s en Si :
22 calcular h2 ( s [ Y ])
23 agregar al resultado las tuplas de TH [ r [ Y ]] join " s "

24. Evaluación de expresiones

La forma obvia de evaluar una expresión que tiene varias operaciones es evaluar cada operación en el orden
indicado, materializando en disco cada resultado intermedio como relaciones temporales.
Otra alternativa, más eficiente, es evaluar las operaciones en simultáneo en un pipeline, donde los resultados
de una operación pasan a la próxima, y se elimina la necesidad de almacenar relaciones temporales. Esto se
puede utilizar para evaluar juntas múltiples: R1 ./ R2 ./ · · · ./ Rk .
Ventajas de pipeline:
1. Elimina el costo de leer y escribir relaciones temporales.
2. Puede empezar a generar resultados inmediatamente.
Uso de pipelining:
Sort: no se puede aplicar. El resultado del sort no se puede mostrar hasta que no se hayan procesado
todas las tuplas.
Join: el método GRACE no se puede aplicar porque requiere leer y particionar todas las tuplas antes
de que pueda producirse un resultado. Sin embargo, el método indexed nested-loop puede aprovechar del
pipelining. Si las relaciones están ordenadas por los atributos de join, merge join también puede aprovechar
del pipelining.

25. Optimización de consultas

Plan de evaluación conjunto de operaciones de álgebra relacional a ejecutar, junto con las instrucciones para
llevarlas a cabo (por ejemplo, los índices a usar).
Optimización de consultas proceso de seleccionar el mejor plan de evaluación. El costo de cada plan se evalúa
teniendo en cuenta información estadística de las relaciones. Lo que se busca minimizar es la cantidad de
transferencias de bloques del disco a la memoria y la cantidad de seeks que se hacen en el disco.
Para ello se tiene en cuenta:
1. ¿Cuál de la de las expresiones equivalentes a la consulta es más eficiente para resolver la misma?
2. ¿Qué algoritmo se utilizará para implementar la operación?
3. ¿Cómo deberían las operaciones pasarse datos entre sí? (Pipeline, buffers de memoria, disco)

1 EXPLAIN consulta

Base de Datos (75.15 - 95.05) - Resumen Página 54 de 75

25.1 Reglas de equivalencia

25.1. Reglas de equivalencia

Reglas relacionadas con la selección:
1. σa∧b (r) = σa (σb (r)) = σb (σa (r))
2. σa∨b (r) = σa (r) ∪ σb (r)
3. σa (r ∪ s) = σa (r) ∪ σa (s)
4. σa (r − s) = σa (r) − s = σa (r) − σa (s)
5. σa (r ./ s) = σa (r) ./ σa (s)
6. Si a solo tiene atributos de S: σa (r × s) = r × σa (s)
Reglas relacionadas con la proyección:
1. πL (R ∪ S) = πL (R) ∪ πL (S)
2. πL (σa (R)) = πL (σa ((πM (R)))) donde M es la lista de atributos que figuran en L o en a
Reglas relacionadas con el join:
1. r1 ./ r2 = r2 ./ r1
2. (r1 ./ r2 ) ./ r3 = r1 ./ (r2 ./ r3 )

25.2. Heurísticas de optimización de consultas

1. Ejecutar las selecciones (σ) lo antes posible
2. Ejecutar las proyecciones (π) lo antes posible
3. El orden de las operaciones de join (./) es importante
4. Evitar cuando sea posible los productos cartesianos (×)

26. Estimación de tamaño de consultas

A continuación se describe la estimación de cantidad de tuplas para cada tipo de consulta.
Se utiliza el concepto de selectividad de una condición A como la “probabilidad de que una tupla satisfaga
una condición A”. Sea si = V (σi , r) la cantidad de tuplas que satisfacen la condición σi . La probabilidad de
satisfacer σi es nsir .
Selección
• σA=a (r)
◦ Si A distribuye uniformemente: nr
V (A,r)
f reqrango (A,r)
◦ Si se dispone de un histograma para A, y a ∈ rango: cantrangos
• σA≤v (r) con v conocido
◦ Si A distribuye uniformemente y v < mı́n(A, r): 0
◦ Si A distribuye uniformemente y v ≥ máx(A, r): nr
v−min(A,r)
◦ En cualquier otro caso: nr · max(A,r)−min(A,r)
• σa∧b∧···∧z (r) donde hay x selectores: nr × P (a) × · · · × P (z) = nr · sa ·sb ···sz
(nr )x
• σa∨b∨···∨z (r) donde hay x selectores independientes entre sí:
    
sa sz
nr × [P (a) + · · · + P (z)] = nr · 1 − 1 − × ··· × 1 −
nr nr
• σ¬a (r): nr − V (a, r)
Junta natural3
3 Se introducen dos simplificaciones:

Página 55 de 75 Base de Datos (75.15 - 95.05) - Resumen

 26.1 Cálculo de juntas con histogramas

• Si R ∩ S = ∅: nr × ns
• Si R ∩ S = P KR : ≤ nS (porque podría haber nulls)
• Si R ∩ S = P KS : ≤ nR (porque podría haber nulls)
• Si R ∩ S = F KS : nS
• Si R ∩ S = F KR : nR
• Si #(R ∩ S) = 1: ns ×nr
máx(V (S,R∩S),V (R,R∩S)) ≈ ns ×nr
V (S,R∩S) ≈ ns ×nr
V (R,R∩S)
• Si #(R ∩ S) = 2 y el join es de tipo R.A1 = S.A2 ∧ R.B1 = S.B2 :
nr × ns
máx (V (R, A1 ), V (S, A2 ) × máx (V (R, B1 ), V (S, B2 ))

Proyección: πA (r) : V (A, r)

Agregación A %f (r) : V (A, r)
Unión R ∪ S: nr + ns
Intersección R ∩ S : mı́n (nr , ns ) (cota superior)
Diferencia R − S : r (cota superior)
V (A, σA op v (r)) : V (A, r) × sA op v
V (A, r ./ s) :
• Si A ∈ R: mı́n (V (A, r), nr./s )
• Si a1 ∈ A y a2 ∈ A, mı́n (V (a1 , r) × V (a2 − a1 , s); V (a1 − a2 , r) × V (a2 , S); nr./s )

26.1. Cálculo de juntas con histogramas

Un sistema de bases de datos puede computar un histograma de valores para un atributo dado. Si V (R, A) no
es muy grande, el histograma puede consistir de la cantidad de tuplas que tienen cada posible valor del atributo.
Si V (R, A) es muy grande, entonces podría guardarse solamente los valores más frecuentes, o agruparlos en
rangos.
Los tipos de histogramas más frecuentes son:
1. Igual ancho: se escoge un ancho w y una constante v0 . Se almacena la cantidad de tuplas con valores v
en los rangosv0 ≤ v < v0 + w, v0 + w ≤ v < v0 + 2w, etcétera.
2. Valores más frecuentes: se listan los valores más frecuentes y la cantidad de tuplas que tienen esos
valores. También se puede proporcionar la cantidad de tuplas que tienen “otros” valores.
Ejemplo: sea la junta R(A, B) ./ S(B, C). Sabemos que V (R, B) = 14 y que V (S, B) = 13. Tenemos los
histogramas de valores más frecuentes para R ∩ S = B.

0 1 2 5 “Otros”
R.B 150 200 ? 100 550 (11 valores)
S.B 100 80 70 ? 250 (10 valores)

Suponemos que cada valor que aparece en la relación con menos valores de B (en este caso, S) también
aparecen en la otra relación (en este caso, R). También suponemos que la distribución de los valores dentro de
“Otros” es uniforme, y estimamos la frecuencia de los datos desconocidos:

0 1 2 5 Otros
R.B 150 200 550
11 = 50 100 550 (10 valores)
S.B 100 80 70 250
10 = 25 250 (9 valores)
1. Si R(X, Y ) y S(Y, Z), y V (R, Y ) ≤ V (S, Y ) entonces cada valor de Y en R será un valor de Y en S.
2. Si A es un atributo de R pero no de S, V (R ./ S, A) = v (R, A)

Base de Datos (75.15 - 95.05) - Resumen Página 56 de 75

26.1 Cálculo de juntas con histogramas

Entonces, el tamaño de la junta es:

T [R ./ S] = T [R ./B=0 S] + T [R ./B=1 S] + T [R ./B=2 S] T [R ./B=5 S] + T [R ./B6=0,1,2,5 S]

 
550 250
= (150 × 100) + (200 × 80) + (50 × 70) + (100 × 25) + mı́n(9, 10) × ×
11 10
= 15,000 + 16,000 + 3,500 + 2,500 + 9 × 1250
= 48,250

Ejemplo: sean las relaciones Enero(dia, temp) y Julio(dia, temp). Sea la consulta
1 SELECT Enero . dia , Julio . dia
2 FROM Enero , Julio
3 WHERE Enero . temp = Julio . temp

Suponer los siguientes histogramas de igual ancho:

Rango C° Enero Julio

-17, -13 0 40
-13, -9 0 60
-8, -4 0 80
-3, 1 0 50
2, 6 5 10
7, 11 20 5
12, 16 50 0
17, 21 100 0
22, 26 60 0
27, 31 10 0

Sabemos que si dos bandas tienen T1 y T2 tuplas respectivamente, y la cantidad de valores de la banda es V ,
entonces la estimación del tamaño de la junta es T1VT2 .
En el ejemplo anterior, las únicas bandas que contribuyen al resultado son las de [2,6] y [7,11]. Entonces, el
tamaño de la junta es:

   
T [R ./ S] = T R ./temp∈[2,6] S + T R ./temp∈[7,11] S
5 × 10 20 × 5
= +
4 4
= 12, 5 + 25
= 37, 5

Página 57 de 75 Base de Datos (75.15 - 95.05) - Resumen

Parte V
Control de Concurrencia
Ítem de dato elemento al que accede una transacción. Puede ser un registro de una base de datos, un bloque
de disco, un campo de un registro, o incluso toda la base de datos. Cada ítem tiene un nombre único que
lo identifica (por ejemplo, la dirección física de un bloque de disco).
Modelo de concurrencia intercalada la CPU ejecuta una transacción a la vez, pero varias transacciones en
un período de tiempo.

Figura 24: El manejador de transacciones (a) le emite órdenes al manejador del log, (b) se asegura que tran-
sacciones concurrentes no interfieran entre ellas. El scheduler permite o bloquea transacciones

27. Transacciones
Transacción unidad lógica de procesamiento. Está formada por una o más operaciones que acceden a la base
de datos. Tiene un identificador único de transacción.

Debe tener las siguientes propiedades ACID:

Responsabilidad del gestor de
recuperación, que mantiene un
La transacción debe ejecutarse en su
Atomicity log donde guarda los valores
totalidad o no debe ejecutarse
viejos sobrescritos por una
transacción
La transacción debe llevar a la base de datos
de un estado consistente a otro (i.e. que Responsabilidad de los
Consistency
respeten las reglas de integridad de la base programadores
de datos)
La ejecución de una transacción no debe Responsabilidad del gestor de
Isolation
interferir con otras concurrencia
Los efectos de una transacción commiteada Gestor de recuperación, que
deben persistir en la base de datos. Es decir, debe garantizar que el log esté
Durability
luego de commiteada, no deberíamos en disco antes de que termine la
necesitar ejecutar un rollback transacción
How transactions interact with the database. There are three address spaces that interact in important ways:
1. The space of disk blocks holding the database elements.
2. The virtual or main memory address space that is managed by the buffer manager.
3. The local address space of the transaction.

Base de Datos (75.15 - 95.05) - Resumen Página 58 de 75

28 Problemas de concurrencia

Cada transacción está formada por una o más operaciones:

start

leer(X): lee un item de dato de la base de datos a una variable local a la transacción, que está en memoria

escribir(X): escribe una variable de programa en memoria, en la base de datos

commit: marca el fin exitoso de una transacción. Los cambios que introdujo son seguros para guardar en
la base de datos.

abort: marca el fin con errores de una transacción. Los cambios que introdujo se deben revertir.

Estados posibles de una transacción:

Partially committed : luego de que se ejecutó la última instrucción pero antes de ejecutar el commit o
abort

Commited : sus efectos fueron almacenados permanentemente en la base de datos

Aborted : se ejecutó un roll back de la transacción y la base de datos se restauró a su estado original

Figura 25: Diagrama de estados de una transacción

Una transacción llega al punto de commit cuando todas sus operaciones se ejecutaron correctamente y se
grabaron todos sus registros de operaciones en el log. Luego de este punto, la transacción está commiteada y
se debe almacenar permanentemente en la base de datos. Esto se marca agregando un registro [commit,T] en
el log.

1. Si ocurre una falla y la transacción aún no grabó [commit,T], se debe ejecutar un rollback de esta
transacción.

2. Si ocurre una falla y la transacción ya había grabado [commit,T] en el log, se debe rehacer esta transacción.

El protocolo WAL (Write-Ahead Logging ) indica que antes de commitear una transacción se debe guardar
el log en memoria al log en disco.

28. Problemas de concurrencia

1. The Lost Update Problem: una Escritura que sobrescribe a otra.

2. The Dirty Read Problem: una Lectura de un valor incorrecto.

3. The Incorrect Summary Problem: una Lectura de muchos valores incorrectos.

4. The Unrepeatable Read Problem: dos Lecturas consecutivas que producen resultados distintos, por
haber una transacción intermedia que cambió el valor.

Página 59 de 75 Base de Datos (75.15 - 95.05) - Resumen

 28.1 Atributos de una transacción

(a) Lost Update (b) Dirty Read

(c) Incorrect Summary

Figura 26: Probemas de concurrencia

28.1. Atributos de una transacción

Modo de acceso: READ ONLY, READ WRITE

Nivel de isolation:

Nivel de Tipo de violación que se puede producir para dos transacciones T y S

isolation
Escritura sucia Lectura Sucia (T Lectura No Phantoms (T lee
(T escribe el valor lee el valorX Repetible (T lee varios datos que
X después de que después de una el valor X, luego S cumplen una
una transacción S transacción S que lo actualiza, luego condición, luego S
lo escribiera, y S no comitió ni T lee X y es un agrega un dato que
no comitió ni abortó) nuevo valor) también lo verifica. Si
abortó) T lee de nuevo,
encontrará un nuevo
dato que antes no
estaba)
READ UN- No Si Si Si
COMMITTED
READ No No Si Si
COMMITTED
REPEATABLE No No No Si
READ
SERIALIZABLE No No No No

Cuadro 1: Violaciones que se pueden producir en cada nivel

Base de Datos (75.15 - 95.05) - Resumen Página 60 de 75

29 Schedules de transacciones

29. Schedules de transacciones

(a) Schedules equivalentes (b) Schedule no recuperable

Figura 27: Schedules de Transacciones

Schedule ordenamiento cronológico de las operaciones de n transacciones. Se pueden intercalar operaciones de

distintas transacciones, pero las operaciones de una transacción se deben ejecutar en forma secuencial.
Un schedule es recuperable si, para cada par de transacciones Ti y Tj tal que Tj lee un ítem de dato
previamente escrito por Ti , el commit de Ti aparece antes del commit de Tj .
Un schedule es sin cascada (avoids cascading rollback , AVR) si, para cada par de transacciones Ti
y Tj tal que Tj lee un ítem de dato previamente escrito por Ti , el commit de Ti aparece antes del read de
Tj .
Un schedule que usa locks es estricto si cada transacción commitea o aborta, y luego libera todos sus
locks exclusivos.

estricto =⇒ sin cascada =⇒ recuperable

estricto =⇒ serializable

Figura 28: Relación de schedules

Conflicto dos operaciones en un schedule entran en conflicto cuando se cumplen todas las condiciones siguien-
tes:
1. Corresponden a distintas transacciones
2. Acceden al mismo ítem de dato X
3. Al menos una de esas operaciones es escribir(X)
Dicho de otra forma, están en conflicto cuando, si alteramos el orden de ejecución, cambia el resultado
final de X.

Página 61 de 75 Base de Datos (75.15 - 95.05) - Resumen

 30 Protocolos de Control de Concurrencia: Protocolo de Locking

Un schedule es serial cuando ejecuta primero todas las operaciones de T1 , luego todas las operaciones de
T2 , ..., y finalmente todas las operaciones de Tn . Cualquier esquema serial preserva la consistencia de la base de
datos.
Un schedule es serializable cuando es equivalente a algún schedule serial con las mismas transacciones.
Dos schedules son conflicto-equivalentes si el orden de las operaciones en conflicto es la misma en ambos.
Es decir, si podemos transformar uno en el otro mediante una secuencia de swaps de acciones adyacentes que
no están en conflicto.

Figura 29: Convirtiendo un schedule conflicto-serializable en uno serial mediante swaps de acciones adyacentes.
A cada paso están subrayadas las acciones a punto de ser swappeadas

Un schedule es conflicto-serializable si es conflicto-equivalente a algún schedule serial.

Conf licto serializable =⇒ Serializable
Para verificar si un schedule S es conflicto-serializable se utiliza un grafo dirigido G = (N, E):
N es el conjunto de transacciones {T1 , T2 , . . . , Tn } que forman el schedule
E es el conjunto de aristas de la forma Ti → Tj . Cada arista significa que Ti debe preceder a Tj en
cualquier schedule serial equivalente a S

Algoritmo 15 Verificación de serializabilidad de un schedule

1 Entrada : schedule S
2 Salida : " verdadero " si es conflicto serializable
3
4 para cada transaccion Ti en S :
5 crear un nodo Ti en el grafo de precedencia
6 para cada caso donde Ti ejecuta READ ( X ) y luego Tj ejecuta WRITE ( X ) :
7 agregar una arista ( Ti -> Tj ) en el grafo de precedencia
8 para cada caso donde Ti ejecuta WRITE ( X ) y luego Tj ejecuta READ ( X ) :
9 agregar una arista ( Ti -> Tj ) en el grafo de precedencia
10 para cada caso donde Ti ejecuta WRITE ( X ) y luego Tj ejecuta WRITE ( X ) :
11 agregar una arista ( Ti -> Tj ) en el grafo de precedencia
12
13 si el grafo es aciclico :
14 devolver " verdadero "
15 si el gafo es ciclico :
16 devolver " falso "

Si el grafo de precedencia es acíclico, el schedule serial equivalente puede construirse utilizando un orden
topológico de la siguiente forma: siempre que exista una arista Ti → Tj , Ti debe preceder a Tj en el schedule
serial.
En la práctica, los DBMS no utilizan este algoritmo para garantizar la serializabilidad (porque habría que
verificarlo para cada schedule).

30. Protocolos de Control de Concurrencia: Protocolo de Locking

Una forma de garantizar el aislamiento de transacciones y prevenir comportamiento no serializable es me-
diante el uso de locks. Notar que este mecanismo no funciona bien cuando los locks se mantienen durante días,

Base de Datos (75.15 - 95.05) - Resumen Página 62 de 75

30.1 Lock

o cuando las decisiones humanas son parte de una transacción.

30.1. Lock
Lock variable que se asocia a un ítem de dato. Describe el estado del ítem con respecto a las posibles operaciones
que pueden aplicarse a el. Generalmente hay un lock por item de dato.

30.1.1. Tipos de locks

1. Binarios: pueden tener dos valores: locked (1) o unlocked (0). Un lock binario impone la exclusión mutua
en el item de dato asociado, porque solo puede haber a lo sumo una transacción con un lock para un
mismo dato.
El registro de este tipo de lock tiene la forma <Item de dato, LOCK, Transacción con lock>
Reglas que deben aplicarse a cada transacción:

a) lock(X) antes de cualquier leer(X) o escribir(X)

b) unlock(X) después de todos los leer(X) y escribir(X)
c) no se permite ejecutar lock(X) si ya se tiene un lock de X
d ) no se permite ejecutar unlock(X) si no se tiene el lock de X

2. Compartidos/Exclusivos (Lectura/Escritura): es más laxo que los locks binarios porque permite que
varias transacciones que solo van a ejecutar leer(X) tengan acceso a X. El lock puede tener dos valores:
read-locked o write-locked.

Lock exclusivo: puede leer y escribir el dato X.

Lock compartido: puede leer pero no puede escribir X.

El registro este tipo de lock tiene la forma <Item de dato, LOCK, # de lecturas, Transaccion(es)
con lock>
Reglas que deben aplicarse a cada transacción:

a) read_lock(X) o write_lock(X) antes de cualquier leer(X)

b) write_lock(X) antes de cualquier escribir(X)
c) luego de todos los leer(X) y escribir(X), ejecutar unlock(X)
d ) si ya tiene un lock (compartido o exclusivo) de X, no se puede ejecutar ni read_lock(X) ni write_lock(X)
e) no se permite ejecutar unlock(X) si no se tiene un lock de X (compartido o exclusivo)

30.1.2. Problemas con el uso de locks

1. El uso por sí solo de locks no garantiza la serializabilidad de schedules.

Figura 30: El uso de locks no garantiza la serializabilidad. Si se produce una actualización a A entre unlock(A)
y lock(B), A + B sería incorrecto

Página 63 de 75 Base de Datos (75.15 - 95.05) - Resumen

 30.2 Lock de update

2. Deadlock : ocurre cuando cada transacción en un schedule está esperando que se libere un lock que fue
adquirido por otra transacción del schedule.
Para detectar y/o prevenir un deadlock, el gestor de concurrencia puede mantener un grafo de espera.
Cuando una transacción T está esperando a que la transacción S libere un lock, se dibuja una arista
T → S. Cuando S libera el lock, la arista se borra. El deadlock se detecta cuando el grafo es cíclico.
Cuando ocurre un deadlock, el sistema debe ejecutar el rollback de alguna de las dos transacciones, y
liberar los locks que ésta poseía.
También se pueden arreglar deadlocks especificando un timeout para cada transacción. Si se ejecutan por
más tiempo que este timeout, es abortada y sus locks se liberan.
3. Starvation: ocurre cuando una transacción se queda esperando indefinidamente a que se libere un lock.
Se puede evitar de la siguiente forma: cuando una transacción Ti solicita un lock sobre X en un modo M ,
el gestor de concurrencia se lo provee si se verifica que:
a) No hay otra transacción con un lock sobre X en un modo que conflictúe con M .
b) No hay otra transacción esperando obtener un lock sobre X antes que Ti

30.2. Lock de update

Lock de update un lock de update le da a una transacción el privilegio para leer X, pero no para escribirlo.
Sin embargo, este tipo de lock se puede actualizar a un lock exclusivo más tarde.

30.3. Matriz de compatibilidad de locks

Matriz de compatibilidad de locks se puede otorgar un lock de tipo C si y solo si, para cada fila R tal que
ya se otorgó a otra transacción un lock de tipo R, hay un “Si” en la columna C.

Se solicita un lock de tipo....

Exclusivo Compartido
Exclusivo No No
Se otorgó un lock de tipo...
Compartido No Si
(a) Para locks compartidos y exclusivos
Se solicita un lock de tipo....
Exclusivo Compartido Actualización
Exclusivo No No No
Se otorgó un lock de tipo... Compartido No Si Si
Actualización No No No
(b) Para locks compartidos, exclusivos y de actualización

Cuadro 2: Ejemplos de matrices de compatibilidad

Base de Datos (75.15 - 95.05) - Resumen Página 64 de 75

30.4 Lock table

30.4. Lock table

Lock table tabla que utiliza el gestor de concurrencia para almacenar el estado de los locks activos.

Para cada ítem de dato con locks activos, mantiene una lista de transacciones que solicitaron el lock, en
el orden en que llegaron los pedidos. Se registra qué transacción es y qué modo de lock solicitó. También
se registra si el lock le fue concedido.

Figura 31: Lock table

30.5. Protocolo de dos fases (two-phase locking)

Una transacción cumple con el protocolo two-phase locking (2PL) si todas las operaciones de lock
(read_lock, write_lock) preceden al primer unlock de la transacción. Se dice entonces que la transacción
se divide en dos fases: la creciente (donde se adquieren los locks) y la decreciente (donde se liberan los locks).
Si cada transacción de un schedule cumple el protocolo 2PL, se garantiza que el schedule es serializable.
De hecho, las transacciones se pueden ordenar de acuerdo a sus lock points (el punto donde termina la fase
creciente).
Este protocolo limita la cantidad de concurrencia que se permite, porque una transacción no puede liberar
un lock hasta que haya adquirido un lock para todos los demás ítems, y entonces puede haber muchas otras
transacciones esperando que se libere el primer lock. Además, no se previene el deadlock, ni los rollbacks en
cascada.

Figura 32: 2PL

Página 65 de 75 Base de Datos (75.15 - 95.05) - Resumen

 30.6 Protocolo de árbol

(b) Schedule 2PL con cascading rollback si T5 falla al final

(a) Schedule 2PL con deadlock
de todo

Figura 33: Schedule 2PL

Para prevenir el problema de deadlock, este protocolo puede ampliarse y exigir que las transacciones adquieran
por adelantado todos los locks que se necesitan; si un lock no se puede conseguir, no se adquiere ninguno. Esto
limita aún más la concurrencia.
Para prevenir el problema de rollbacks en cascada, existe el protocolo 2PL estricto. Este modo, además de
requerir lo mismo que 2PL, requiere que todos los locks exclusivos adquiridos por una transacción se mantengan
hasta que la misma ejecute commit.

30.6. Protocolo de árbol

Protocolo de árbol protocolo especializado para transacciones que acceden a datos en forma de árbol (ejem-
plo: un índice B). El protocolo viola 2PL, pero utiliza el hecho de que acceder a elementos debe ser hacia
abajo para garantizar serializabilidad.

Si una transacción quiere insertar un registro, debería adquirir un lock exclusivo de la raíz, ergo de todo el
árbol, y por ende estaría bloqueando a todas las demás transacciones.
Puede aprovecharse la estructura de árbol del índice de la siguiente forma:

Cuando se adquiere un read_lock en un nodo hijo, el lock del nodo padre puede liberarse porque no se
usará más.
Cuando se adquiere un write_lock en un nodo hoja (para realizar una inserción), se debe adquirir un lock
exclusivo en el nodo hoja.
Utilizar la técnica de index locking soluciona el problema de registros phantom.
El protocolo de árbol garantiza un orden serial en las transacciones. El orden de precedencia se define así:
si Ti y Tj adquieren un lock sobre X y Ti adquiere el lock primero, entonces Ti → Tj .

Algoritmo 16 Protocolo de árbol

1. El primer lock de una transacción puede hacerse sobre cualquier nodo del árbol.

2. Los locks subsiguientes pueden otorgarse sólo si se posee un lock sobre el nodo padre.
3. Se puede ejecutar unlock de un nodo en cualquier momento.
4. No se puede adquirir lock de un nodo 2 veces, incluso cuando se tiene un lock sobre el nodo padre.

Base de Datos (75.15 - 95.05) - Resumen Página 66 de 75

Parte VI
Técnicas de Recuperación
31. Necesidad de Recuperación
Tipos de fallas que pueden ocurrir:
1. Fallas de la computadora: por ejemplo, una desconexión en la red
2. Fallas de transacciones: por ejemplo, una transacción que intenta dividir por cero
3. Errores locales: por ejemplo, una transacción que no encuentra datos
4. Aplicación de procedimientos de control de concurrencia: por ejemplo, una transacción abortada porque
viola la serializabilidad o para resolver un estado de deadlock
5. Fallas del disco
6. Catástrofes
Los algoritmos de recuperación tienen dos partes:
1. Acciones que se toman durante el procesamiento normal de transacciones, para asegurar que, en caso de
falla, se dispone de suficiente información para recuperar
2. Acciones que se toman después de una falla para devolver la base de datos a un estado consistente.
Idealmente, la base de datos en disco debería contener, para cada ítem de dato, el último valor escrito por
una transacción que ejecutó commit.
En la práctica, la base de datos podría:
Contener valores escritos por transacciones no commiteadas
No contener valores escritos por transacciones commiteadas

32. Archivo de Log

La base de datos se almacena en disco. Éste está formado por bloques. Como todos los bloques no caben en
memoria principal, se necesita una forma de trabajar con la base de datos en memoria. Por ende, se necesita
una forma de organizar los bloques en memoria y luego copiarlos en el disco (flush).

Figura 34: Operaciones sobre bloques

Para alcanzar el objetivo de transacciones atómicas, primero se debe guardar en disco información sobre las
modificaciones, sin modificar la base de datos en sí. Para eso se utiliza un archivo de log. Este archivo permite:

Página 67 de 75 Base de Datos (75.15 - 95.05) - Resumen

 32.1 Checkpoints

Deshacer (undo) cambios hechos por transacciones que deben ser abortadas
Rehacer (redo) cambios hechos por transacciones que ejecutaron commit pero cuyos cambios no fueron
almacenados en la base de datos en disco.
Log archivo secuencial al que solo se le pueden agregar registros.
Decimos que una transacción ejecutó commit cuando su registro [commit,T] fue almacenado en disco. Si
hay una falla luego de esto, se ejecuta un redo. Si hay una falla antes de esto, se hace undo.
Redo debe hacerse en el orden en el que los cambios fueron hechos originalmente.
Undo escribe registros especiales llamados “redo-only”, que no tienen el valor viejo del item de dato. Al
finalizar las escrituras, se escribe un registro <abort,T> para indicar que el undo finalizó.

32.1. Checkpoints
Cuando se produce una caída del sistema, hay que consultar el log para determinar aquellas transacciones que
deben rehacerse o deshacerse. En principio, habría que buscar en todo el log para determinar esta información.
Hay dos grandes dificultades con este enfoque:
1. El proceso de búsqueda lleva mucho tiempo.
2. La mayor parte de las transacciones ya han escrito sus actualizaciones en la base de datos.
Para reducir este tipo de gastos generales, se usan los checkpoints. La periodicidad con que se ejecutan
checkpoints la decide el administrador de base de datos.

32.1.1. Checkpoints bloqueantes

Se describe a continuación un esquema de control simple que (a) no permite realizar ningún cambio mientras
la operación está en curso, y (b) se escriben en disco todos los buffers en memoria modificados.

Algoritmo 17 Checkpoint bloqueante en un log UNDO

1. Stop accepting new transactions.
2. Wait until all currently active transactions commit or abort and have written a COMMIT or ABORT record on
the log.
3. Flush the log to disk.
4. Write a log record <CHECKPOINT>, and flush the log again.
5. Resume accepting transactions.

32.1.2. Checkpoints no bloqueantes

Algoritmo 18 Checkpoint no bloqueante en un log UNDO

1. Write a log record <START CHECKPOINT (T1, ... , Tk)>. Here, T1 , . . . , Tk are the identifiers for all the
active transactions (i.e., transactions that have not yet committed and written their changes to disk).
2. Flush the log.
3. Wait until all of T1 , . . . , Tk commit or abort, but do not prohibit other transactions from starting.
4. When all of T1 , . . . , Tk have completed, write a log record <END CHECKPOINT>.
5. Flush the log.

Algoritmo 19 Checkpoint no bloqueante en un log REDO

1. Write a log record <START CHECKPOINT (T1, ... , Tk)>. Here, T1 , . . . , Tk are the identifiers for all the
active transactions (i.e., transactions that have not yet committed).
2. Flush the log.
3. Write to disk all database elements that were written to buffers but not yet to disk by transactions that had
already committed when the <START CHECKPOINT>record was written to the log.
4. Write a log record <END CHECKPOINT>.
5. Flush the log.

Base de Datos (75.15 - 95.05) - Resumen Página 68 de 75

33 Protocolos de Recuperación

Algoritmo 20 Checkpoint no bloqueante en un log UNDO/REDO

1. Write a log record <START CHECKPOINT (T1, ... , Tk)>. Here, T1 , . . . , Tk are the identifiers for all the
active transactions (i.e., transactions that have not yet committed).
2. Flush the log.
3. Write to disk all buffers that are dirty (not just those written by committed transactions).
4. Write a log record <END CHECKPOINT>.
5. Flush the log.

33. Protocolos de Recuperación

Para fallas de tipo 5 y 6, se necesita haber grabado con anterioridad un backup de la base de datos y
reconstruir la misma con el archivo de log hasta el momento de la falla.

Para fallas de tipo 1 a 4, existen dos técnicas de recuperación:

• Deferred update
• Immediate update

33.1. Deferred update

Las transacciones y el manejador de buffers obedecen 1 regla:

Write-Ahead Logging (WAL): se deben grabar en disco todos los registros de log sobre las actualización
(incluyendo <UPDATE T,X,Nuevo_valor> y <COMMIT T>), y luego actualizar X en disco.

Tipos de registros

<START T>

<COMMIT T>

<ABORT T>

<UPDATE T,X,Valor_Nuevo>

Algoritmo 21 Procedimiento de recuperación REDO sin checkpoints

1 t r a n s a c c i o n e s _ c o m mi t e a d a s = identificarlas
2 t r a n s a c c i o n e s _ i n c om p l e t a s = identificarlas
3
4 desde el comienzo del log hasta el fin :
5 si hay un registro < UPDATE <T ,X , Valor_Nuevo >:
6 si T esta en ‘‘ transacciones_commiteadas ’ ’:
7 escribir ‘‘ Valor_Nuevo ’ ’ en X
8 si no :
9 no hacer nada
10
11 para cada T en ‘‘ transacciones_incompletas ’ ’:
12 escribir < ABORT T >
13
14 flush_log ()

Página 69 de 75 Base de Datos (75.15 - 95.05) - Resumen

 33.2 Immediate update

Algoritmo 22 Procedimiento de recuperación REDO con checkpoints no bloqueantes

1 t r a n s a c c i o n e s _ c o m mi t e a d a s = identificarlas
2 t r a n s a c c i o n e s _ i n c om p l e t a s = identificarlas
3
4 desde el comienzo del log hasta el fin :
5 si hay un registro < UPDATE <T ,X , Valor_Nuevo >:
6 si T esta en " t r a n sa c c i o n e s _ c om m i t e a d a s ":
7 escribir " Valor_Nuevo " en X
8 si no :
9 no hacer nada
10 si el ultimo registro de checkpoint es < END CHECKPOINT >:
11 // se debe mirar el log hasta el < START Ti > que se ejecuto primero
12 si el ultimo registro de checkpoint es < START CHECKPOINT T1 ,... , TK >:
13 // la caida se produjo durante el checkpointing
14 // buscar el registro < END CHECKPOINT > anterior y su par < START CHECKPOINT
S1 ,... , SK >
15 // rehacer todas las transacciones commiteadas que empezaron despues de ese
START
16 // o son Si
17 // ( si no hay , rehacer desde el principio del log )
18
19 para cada T en t r a n sa c c i o n e s _ i nc o m p l e t a s :
20 escribir < ABORT T >
21
22 flush_log ()

El algoritmo anterior puede ser más eficiente si se ejecuta, para cada item de dato, sólo el último REDO
existente (porque todos los anteriores serían sobrescritos por éste).

Este mecanismo garantiza

Que no se deban hacer rollbacks de transacciones (porque las mismas sólo escriben en la base de datos
luego de ejecutar commit)
Que no se deban hacer rollbacks en cascada (porque los ítems tienen locks que no permiten leerlos antes
de que una transacción que los escribió no ejecute commit)

33.2. Immediate update

Immediate update tiene a su vez tiene dos variantes:
1. UNDO/REDO
2. UNDO

33.2.1. UNDO/REDO
Las transacciones y el manejador de buffer obedecen 1 regla:
Si la transacción T modifica el ítem de dato X, el registro de log <UPDATE T,X,Valor_Viejo,Valor_Nuevo>
debe ser escrito al disco antes que el ítem X sea escrito al disco.

Tipos de registros
<START T>
<COMMIT T>
<ABORT T>
<UPDATE T,X,Valor_Viejo,Valor_Nuevo>

Base de Datos (75.15 - 95.05) - Resumen Página 70 de 75

33.2 Immediate update

Algoritmo 23 Procedimiento de recuperación UNDO/REDO

1 mantener dos listas de transacciones :

2 1) transacciones commiteadas desde el ultimo checkpoint
3 2) transacciones activas
4
5 ejecutar REDO de todos los ESCRIBIR de las transacciones de la primera lista ,
6 en el orden en que fueron escritos en el log
7
8 ejecutar UNDO de todos los ESCRIBIR de las transacciones de la segunda lista ,
9 en el orden inverso en que fueron escritos en el log

33.2.2. UNDO

Las transacciones y el manejador de buffer obedecen 2 reglas:

1. Si la transacción T modifica el ítem de dato X, el registro de log <UPDATE T,X,Valor_Viejo> debe ser
escrito al disco antes que el ítem X sea escrito al disco.

2. Force Log at Commi t (FLC): si la transacción ejecuta commit, los ítems de datos actualizados por la
transacción se deben escribir en el disco, y luego el registro de log <COMMIT T> debe ser escrito al disco.

Tipos de registros

<START T>

<COMMIT T>

<ABORT T>

<UPDATE T,X,Valor_Viejo>

Algoritmo 24 Procedimiento de recuperación UNDO con checkpoints bloqueantes

1 t r a n s a c c i o n e s_ c om pl e ta s = {}
2 t r a n s a c c i o n e s _ i n c om p l e t a s = {}
3
4 desde el fin del log hasta el comienzo : // o hasta que se encuentre un registro
< CHECKPOINT >
5 si hay un registro < COMMIT T > o < ABORT T >:
6 t r a n s a c c io ne s_ c om pl e ta s += T
7 si hay un registro < UPDATE <T ,X , Valor_Viejo >:
8 si T esta en " tr an sa c ci on e s_ co mp l et as ":
9 no hacer nada
10 sino :
11 t r a n s a c c i o n e s _ i n c om p l e t a s += T
12 escribir " Valor_Viejo " en " X "
13
14 para cada T en " t r a ns a c c i o n e s _ in c o m p l e t a s ":
15 escribir < ABORT T >
16
17 flush_log ()

Página 71 de 75 Base de Datos (75.15 - 95.05) - Resumen

 33.2 Immediate update

Algoritmo 25 Procedimiento de recuperación UNDO con checkpoints no bloqueantes

1 t r a n s a c c io ne s _c om pl e ta s = {}
2 t r a n s a c c i o n e s _ i n c om p l e t a s = {}
3
4 desde el fin del log :
5 si hay un registro < COMMIT T > o < ABORT T >:
6 t r a ns a cc io ne s _c om pl e ta s += T
7 si hay un registro < UPDATE <T ,X , Valor_Viejo >:
8 si T esta en " tr an sa c ci on es _ co mp le t as ":
9 no hacer nada
10 sino :
11 t r a n s a cc i o n e s _ i n c om p l e t a s += T
12 escribir " Valor_Viejo " en " X "
13 si hay un registro < END CHECKPOINT >:
14 // se debe mirar el log hasta el < START CHECKPOINT > correspondiente
15 si hay un registro < START CHECKPOINT T1 ,... , TK > pero no un < END CHECKPOINT >:
16 // la caida se produjo durante el checkpointing
17 // se debe mirar el log hasta el comienzo de la primera transaccion incompleta
18
19 para cada T en " t r a ns a c c i o n e s _ i nc o m p l e t a s ":
20 escribir < ABORT T >
21
22 flush_log ()

Es necesario que las operaciones de UNDO y REDO sean idempotentes: ejecutarlas una vez debe ser igual
a ejecutarlas muchas veces. De hecho, todo el proceso de recuperación debe ser idempotente para garantizar
que si existe una falla durante la recuperación de una falla, la misma se pueda recuperar también.
Es necesario que el DBMS mantenga:
Lista de transacciones activas
Lista de transacciones que ejecutaron commit
Lista de transacciones abortadas desde el último checkpoint

(a) Log UNDO (b) Log REDO

(c) Log UNDO/REDO

Figura 35: Ejemplos de logs

Base de Datos (75.15 - 95.05) - Resumen Página 72 de 75

33.2 Immediate update

UNDO REDO UNDO/REDO

Logs X =⇒ Bd X =⇒ Commit al log Logs X & Commit al log =⇒ Bd X Log X =⇒ Bd X
Immediate update Deferred update Immediate update

Página 73 de 75 Base de Datos (75.15 - 95.05) - Resumen

 COLABORADORES

Colaboradores
Quienes se mencionan a continuación han colaborado y aportado tanto al proyecto FIUBA Apuntes como
en este apunte, redactándolo, corrigiéndolo, agregando gráficos, etc.

María Inés Parnisari ([email protected])

Ezequiel Pérez Dittler

¿Querés colaborar en el proyecto? Conocé más sobre el proyecto en fiuba-apuntes.github.io.

Base de Datos (75.15 - 95.05) - Resumen Página 74 de 75

HISTORIAL DE CAMBIOS

Historial de cambios

08/03/2015 Versión inicial

Página 75 de 75 Base de Datos (75.15 - 95.05) - Resumen