Resumen Clases 2do Parcial – Sistema de Datos

CLASE 04/05
Lenguaje de Consultas y Actualización de Base de Datos

¿Qué es el Álgebra Relacional?

- Es un lenguaje de consulta procedimental. Es decir, podemos hacer consultas de una base de datos a través de un sistema lógico de
consultas y establecer cuáles son los resultados que queremos buscar a través de un conjunto de lógicas determinantes.
- Conjunto de operaciones que describen paso a paso como computar una respuesta sobre las relaciones definidas en el modelo
relacional.
- Relacionadas con SQL-DML (manipulación de datos). Es la base de consultas de la base de datos y manipulación
- Se usan como una representación intermedia de una consulta a una base de datos. Es una representación intermedia de consulta de
una base de datos porque es una representación teórica, en términos lógicos, de acerco como se hace una consulta en una base. Si bien
podemos hacer una consulta que determinamos que tiene cierto grado de eficiencia, el algebra relacional se especializa en el estudio a
partir del cual podemos eficientizar lo mayor posible el procedimiento. Si bien no es tan fácil plasmarlo en una consulta SQL, es más
visualizable cuando lo escribimos en una consulta de algebra relacional
- Permite obtener una versión más optimizada y eficiente

RELACIONES
Son las tablas que contienen atributos que contienen tuplas que contienen registros que contiene
información. Estas relaciones van a intervenir en las operaciones, que se caracterizan como
- UNARIAS: son aquellas que toman una relación como la base de la búsqueda o la operación, para
poder comprender como un resultado una relación
- BINARIAS: requieren de la presencia de dos o mas relaciones para poder obtener como resultado
una relación
 NINGUNA OEPRACION DE SQL VA A TERMINAR DANDO COMO RESULTADO MAS DE UNA
RELACION FINAL

OPERACIONES FUNDAMENTALES DEL ALGEBRA RELACIONAL

- SELECCIÓN (unaria)
- PROYECCION (unaria)
- RENOMBRAMIENTO (unaria)
- UNION (binaria)
- DIFERENCIA (binaria)
- PRODUCTO CARTESIANO (binaria)
- INTERSECION (binaria)
- REUNION NATURAL (binaria)
- REUNION EXTERNA (binaria)

Conceptos adicionales
- relación/Entidad: es una o más tablas que están interviniendo en el proceso. Estas tablas tienen información que puede estar
organizada y estructurada de una manera específica, y que a través de una consulta pueden moldearse o adaptarse para poder obtener
el resultado deseado
- condición: elemento en la consulta a partir del cual se establece cual es el resultado que estamos tratando de buscar. Se puede
determinar un espectro de resultados deseados a través de una o más condiciones. Cuantas más condiciones se use, menos abstracto
va a ser el resultado que estamos obteniendo.
- atributo: columnas que tienen un tipo de dato especifico y tienen información especifica para un registro

Operaciones

1) SELECCIÓN: permite seleccionar un conjunto de tuplas de una relación, siempre y cuando estas tuplas cumplan una condición o
condiciones p.
 Las filas en verde, dentro de una relación que comprende todas estas filas que incluye, son las que cumplen la condición que
estamos estableciendo, que vendría a ser la condición p. Nombre de escuela tiene que ser “Normal 5”. Por lo cual, las filas en verde
deben tener en su nombre “Normal 5”. Son las seleccionadas en verde.
2) PROYECCION: permite establecer columnas o atributos de una relación, que dan como resultado un subconjunto vertical de atributos
de la relación. Es decir, nosotros tenemos una relación con múltiples atributos, de esos múltiples atributos, deseamos obtener un
conjunto especifico. En ejemplo, de los 5 atributos existentes, solo deseamos ver dos. Entonces, a través de una operación de
proyección para la relación escuela, solo queremos proyectar los atributos código_escuela y nombre_escuela

3) RENOMBRAMIENTO: les permite poder poner nombres a las expresiones del algebra relacional, según lo que se desee. Si una
relación a la que se esta haciendo objetivo tiene un nombre especifico, se puede usar una operación de renombramiento para que
automáticamente cambie el nombre.

Ejemplo Práctico SQL Server

4) UNION: conjunto de tuplas que se encuentran en dos o mas relaciones establecidas que, para que sean objetivo de esta operación,
tienen que encontrarse en una relación, en otra o en ambas relaciones. Estamos hablando de dos tablas diferentes con resultados
diferentes. La palabra “unión” hace referencia a la operación binaria de la unión, que nos va a permitir concatenar estas dos relaciones
como un resultado final
 Compatibilidad: dos relaciones son compatibles entre sí si se cumplen dos cosas:
- cantidad de atributos: cuantos atributos deseo proyectar en ambos casos. Que, si en una consulta estoy tratando de proyectar dos
atributos, en la otra lo mismo.
- dominios compatibles: si trato de concatenar dos operaciones entre sí, los dominios que van a emparejarse tienen que tener
compatibilidad. Si trato de pegar dos relaciones y una es un dato tipo texto y el otro dato tipo fecha, esa unión no va a ser compatible.
Ambas listas tienen que tener el mismo formato en relación a los datos que muestra. NO LA TABLA TIENE QUE SER DE LA MISMA
DIMENSION, solo tengo que traer los atributos iguales, las columnas que quiero unir deben ser de la misma dimensión.

5) DIFERENCIA: es agarrar una relación y restarle los resultados de la otra relación. Si tengo una relación R, quiero ver todo lo que esta
en esa relación, pero si algo que esta en R esta en S, no lo quiero ver.
 También tiene que existir compatibilidad en las relaciones.

6) INTERSECCION: corresponde a lo que sería la intercalación de dos o mas relaciones y los resultados que se encuentran en ambas a la
vez. Estamos apelando solamente a la zona que esta en rojo, es decir, lo que se encuentra en ambas, y no solo en una de las dos. Se
deben encontrar en las dos consultas
 Alumno y Docente deben ser relaciones compatibles para que pueda funcionar.

7) PRODUCTO CARTESIANO: dadas dos o más relaciones, nos va a devolver como resultado una nueva, cuyo esquema sea una
combinación de todas las tuplas de la primera relación, con cada una de las tuplas de la segunda relación, y cuyos atributos sea una
combinación de ambas relaciones. Agarrar las dos tablas y multiplicarlas entre sí.

8) REUNION NATURAL: hace un producto cartesiano de sus dos argumentos y realiza una selección forzando la igualdad de atributos
que aparecen en ambas relaciones, eliminando repetidos. En el cual, vamos a multiplicar dos o mas relaciones y vamos a hacer una
selección que fuerza la igualdad de atributos en ambas relaciones, lo que nos permite eliminar repeticiones y eliminar registros
irrelevantes (registros que no tiene sentido que se interconecten).

 Lo único que cambia con el producto cartesiano tiene la misma lógica que la reunión natural. La única diferencia, es la
optimización de la base de datos. Conviene la reunión natural ya que es más performante que el producto cartesiano.

9) REUNION EXTERNA:
- Es una variante de la reunión (join) en la que se intenta mantener toda la información de los operandos, incluso para aquellas filas que
no participan en la reunión. Es decir, si trato de hacer una reunión natural entre dos tablas, voy a traer todo lo que tengan ambas tablas
en conjunto, y voy a ignorar esa información que no se encuentre en una tabla y si en la otra, y viceversa. Si uso una externa, lo que voy
a hacer es llenar con NULOS aquellas columnas que no corresponden en la reunión.
- Se “rellenan con nulos” las tuplas que no tienen correspondencia en la reunión

Tres variantes
- Izquierda: se tienen en cuenta todas las filas del primer operando  LEFT JOIN
- Derecha: se tienen en cuenta todas las filas del segundo operando  RIGHT JOIN
- Completa: se tienen en cuenta todas las filas de ambos operando  FULL JOIN

Estructura SQL

- SELECT: es un listado de selección. Permite proyectar todas aquellas columnas que yo estoy buscando. Puede ser una o muchas
* ALL: lo mismo que poner *
* DISTINCT: es un prefijo que le pueden poner a los atributos que sirve para poder traer datos únicos, que no sean iguales. Ignora los
registros que se repiten.
* TOP N: trae como resultado la cantidad de registros que necesites. Útil para ver como se ve una tabla que tiene miles de registros.
- FROM: determino cual es el origen de los datos. Si voy a usar una o mas relaciones, las tengo que identificar acá. Las puedo
concatenar con comas, haciendo un producto cartesiano, o las puedo unir entre si con reuniones naturales (INNER JOIN, LEFT JOIN,
ETC.)
- WHERE: pongo la condición de selección que voy a usar. Es decir, si tengo algún filtro que quiero usar, lo voy a establecer en acá.
- GROUP BY: me permite agrupar todos los registros en una relación final, a través de un parámetro que yo establezca. Tiene
información calculada. Me permite hacer operaciones matemáticas y aritméticas dentro de la consulta. Si hago un GROUP BY, no puedo
hacer una selección común y corriente.
- HAVING: es una condición de selección como el WHERE, pero se utiliza si o si después del group by. Se utiliza para poder obtener
información que si o si obtuvimos luego de hacer un agrupamiento. Funciona exactamente igual que el WHERE
- ORDER BY: ordenar en base a lo que se especifique. Puede haber más de un orden. Es totalmente opcional. Puede ser ascendente o
descendente.

Orden de Resolución

CLASE 07/05
IN: buscar todos los casos que se estipulo dentro de un atributo. Se usa cuando estoy buscando más de un valor.
OR: que me busque un dato u otro dato.
Consultas Nuevas

1) INSERCION: agregar a una tabla, registros nuevos, agregarle contenido.

INSERT INTO NombreTabla

VALUES ()
 Voy a agregar valores a una tabla. No puedo agregar valores ya existentes, si es una clave primaria.

Consideraciones:
- Tengo que pasar los valores con el mismo tipo de dato
- Tengo que pasarle la misma cantidad de registros que tengo en la tabla ya existente. Al insertar, tengo que agregar todos los datos de
la tabla.
- Si no tengo datos, tengo que poner valor NULL
- No puedo agregar valores con clave primaria ya existente. IMPORTANTE
- Cuando uno no aclara entre paréntesis a la derecha del nombre de la tabla los atributos que se le va a insertar, el motor
automáticamente va a decir “como me puso la tabla escuela, tengo que insertar valores desde la izquierda hasta la derecha, sin saltar,
con ese nombre especifico). Si no pones el atributo ni el dato a agregar, te pone NULL automáticamente.

En caso de que quiera insertar mas de 1 registro dentro de una tabla:

2) CREATE TABLE: crear la estructura de una tabla. Permite definir las columnas que tiene y ciertas restricciones que deben cumplir esas
columnas.

3) ALTER TABLE: modificar la estructura de una tabla que ya existe. Mediante esta instrucción podemos añadir columnas nuevas,
eliminar columnas.

4) DROP TABLE: eliminar una tabla. No se puede eliminar una tabla si está abierta, tampoco la podemos eliminar si el borrado infringe
las reglas de integridad referencial

5) DELETE
Borrar registros.
- Viene seguido por un FROM
- Tengo que aclarar de que tabla voy a estar borrando
- Uso el WHERE para especificar qué datos quiero eliminar
BEGIN TRAN  Para empezar un simulacro. En caso de que haya ejecutado una acción y tenga que volver para atrás. Es una
SIMULACION DE BORRADO, Cuando ingreso este comando, todavía el sistema no lo registra. Si lo podés visualizar, pero no lo va a tomar
el sistema.
Para eso usamos el BEGIN TRANSACTION O BEGIN TRAN
- El BEGIN TRAN siempre se cierra con un COMMIT o un ROLLBACK
- Si lo dejan corriendo y no lo cierran, le traban la base a todo el mundo.

BEGIN TRAN
DELETE FROM Escuela WHERE Codigo_Escuela = ‘7’

ROLLBACK  Si me arrepiento, puedo poner ROLLBACK

- Se ejecuta siempre y cuando hiciste un BEGIN TRAN, sino el sistema entiende que no hay nada que revertir.

BEGIN TRAN
DELETE FROM Escuela WHERE Codigo_Escuela = ‘7’
ROLLBACK

COMMIT  Para poder asentar la operación. Si se que está todo bien, quiero asentar la operación, quiero terminarla. Dejo asentado el
cambio que hice.

BEGIN TRAN
DELETE FROM Escuela WHERE Codigo_Escuela = ‘7’
COMMIT

6) UPDATE: para modificar o actualizar valores de una tabla

- Siempre va seguida de la tabla que yo estoy modificando
- Se igualan en el SET. No tiene sentido, es redundante. El valor de la izquierda se tiene que convertir en el valor de la derecha
- Lo podemos depurar cuantas veces queramos

UPDATE Tipo_Visita
SET Arancel_Por_Alumno = Arancel_Por_Alumno * 1.4
WHERE Arancel_Por_Alumno > 7 (es opcional, es una condición que me piden)

CLASE 11/05
SUBCONSULTAS
- Es una consulta anidada en una instrucción SELECT, INSERT, UPDATE o DELETE, o bien en otra subconsulta.
- Aparecen siempre entre paréntesis, para que el motor de base de datos pueda interpretar y identificar la consulta principal y la
subconsulta.
- Sólo pueden incluir ORDER BY cuando incluyen una cláusula TOP
- Tenemos un proceso mayor, y dentro de alguna de las sentencias internas, tenemos un proceso menor que a su vez, ese proceso
menor es una consulta SQL que puede tener la estructura normal
- Existen subconsultas dentro de subconsultas dentro de subconsultas.

Las subconsultas en la instrucción SELECT, pueden estar:

- En la lista de selección SELECT: nos simula una columna nueva
- En el FROM: nos simula una tabla lógica
- Como condición en el WHERE o en el HAVING: como si fuesen condiciones. La diferencia es que se ejecutan en momentos distintos
* Operadores Lógicos (>,<,=,<>)
* IN (not IN): restricción de dominio. Permite poder comparar el resultado con un conjunto de valores que especificamos.
* ANY-ALL: es similar al IN en el sentido de que le vamos a especificar un conjunto de valores, pero lo que buscamos es que se cumplan,
en el caso del ANY, que al menos uno de los valores se encuentre. En caso del ALL, queremos que eso asuma todos los valores posibles
dentro del dominio.
* EXISTS (not exists): hace un control de verdad, en el cual corrobora que el resultado de la consulta principal se encuentre dentro de
los resultados de la subconsulta. Con que al menos uno de los escenarios se cumpla, entonces la condición exists se da. Sirve
principalmente cuando estamos haciendo un pasaje de registros entre la consulta principal y la subconsulta, y queremos ver que al
menos una circunstancia de cumple.

REFERENCIA EXTERNA
Es un nombre de columna que no se refiere a ninguna de las tablas de la cláusula FROM de la subconsulta, sino a las de la consulta
principal. Como la subconsulta se ejecuta una vez por cada fila de la principal, el valor de la referencia externa va cambiando.
 Consiste en que, voy a tener alguno de los atributos de la subconsulta y, en vez de compararlo con otro atributo de esa subconsulta,
el atributo A va a estar en la consulta y el atributo B va a estar en la subconsulta. Mientras hagamos esa igualdad en la cláusula de la
subconsulta, vamos a estar haciendo una referencia externa.
Es decir, cuando tenemos una subconsulta que se ejecuta dentro de una consulta principal, la primera se ejecuta tantas veces como se
la llame a través de esta referencia externa. Cuando usamos referencias externas, el valor que puede estar usándose como base va a
estar cambiándose constantemente porque hay interacciones nuevas.

Nos permite que una subconsulta vaya caminando en como funciona o como opera respecto que se le esta pasando a partir de la
consulta principal. Cada vez que ejecutamos la consulta en su totalidad, cada registro que se corre de la principal puede estar
pasándome un valor diferente a la referencia externa.

Ejemplos Prácticos

1) SUBCONSULTAS EN EL SELECT

Ejemplo: Listar todos los tipos de visita en conjunto con dos columnas que indiquen, respectivamente, la cantidad de veces que los
guías con código 1 y 2 dieron esos paseos.

SELECT * FROM Jurasik_Park.INFORMATION_SCHEMA.COLUMNS

SELECT DESCRIPCION_TIPO_VISITA,
(SELECT COUNT(*) FROM RESERVA_TIPO_VISITA AS RTV
WHERE TV.CODIGO_TIPO_VISITA = RTV.CODIGO_TIPO_VISITA
AND RTV.CODIGO_GUIA = 1
AND RTV.CANTIDAD_ALUMNOS_REALES IS NOT NULL
GROUP BY CODIGO_GUIA) AS GUIA_1, --ES UNA COLUMNA
(SELECT COUNT(*) FROM RESERVA_TIPO_VISITA AS RTV
WHERE TV.CODIGO_TIPO_VISITA = RTV.CODIGO_TIPO_VISITA
AND RTV.CANTIDAD_ALUMNOS_REALES IS NOT NULL
AND RTV.CODIGO_GUIA = 2
GROUP BY CODIGO_GUIA) AS GUIA_2 --ES UNA COLUMNA
FROM TIPO_VISITA AS TV
-- La columna guia_1 y guia_2 me dice cuántas veces en total cada guía terminó proporcionando una visita
sino me lo está desagregando según el tipo de visita del guía

 En el SELECT, la subconsulta nos permite hacer un calculo a partir de un conjunto de valores que le vamos a estar pasando. Usando la
referencia externa, dicha consulta puede ir mutando de resultado.

SQL Server mejores teclas rápidas / SQL Server short cuts | John Harold Belalcazar Lozano (wordpress.com)

2) SUBCONSULTAS EN EL FROM

 Consiste en hacer una subconsulta, meterla entre paréntesis, y renombrarla como si fuera su propia tabla.

Ejemplo: listar nombre de las escuelas y cantidad total de alumnos reservados para su próxima visita.
SELECT E.NOMBRE_ESCUELA, SUM(RTV.CANTIDAD_ALUMNOS_RESERVADOS) AS TOTAL
FROM ESCUELA AS E
INNER JOIN RESERVA AS R ON R.CODIGO_ESCUELA = E.CODIGO_ESCUELA
INNER JOIN RESERVA_TIPO_VISITA AS RTV ON RTV.NUMERO_RESERVA = R.NUMERO_RESERVA
INNER JOIN (SELECT CODIGO_ESCUELA, MIN(FECHA_VISITA_RESERVADA) AS FECHA_RESERVA FROM RESERVA
--WHERE FECHA_VISITA_RESERVADA > GETDATE() --Si tuviésemos fechas posteriores, funcionaría
GROUP BY CODIGO_ESCUELA) AS RESERVA_PROXIMA ON RESERVA_TOTAL.CODIGO_ESCUELA = E.CODIGO_ESCUELA
GROUP BY E.NOMBRE_ESCUELA

3) SUBCONSULTAS EN EL WHERE

Ejemplo 1: Listar los códigos de guías que hayan guiado, al menos, una visita cuya cantidad de alumnos reservados haya superado al
promedio de cantidad de alumnos reservados para una visita.

SELECT CODIGO_GUIA, COUNT(*) FROM RESERVA_TIPO_VISITA

WHERE CANTIDAD_ALUMNOS_RESERVADOS >= (SELECT AVG(CANTIDAD_ALUMNOS_RESERVADOS) FROM RESERVA_TIPO_VISITA)
GROUP BY CODIGO_GUIA

 Esta consulta NO TIENE REFERENCIA EXTERNA

Ejemplo 2: Listar los códigos de guías que hayan guiado, al menos, una visita cuya cantidad de alumnos reservados haya superado al
promedio de cantidad de alumnos reservados para las visitas de ese tipo.

SELECT RTV1.CODIGO_GUIA, COUNT(*) FROM RESERVA_TIPO_VISITA AS RTV1

WHERE CANTIDAD_ALUMNOS_RESERVADOS > (
SELECT AVG(RTV2.CANTIDAD_ALUMNOS_RESERVADOS) FROM RESERVA_TIPO_VISITA AS RTV2
WHERE RTV1.CODIGO_TIPO_VISITA = RTV2.CODIGO_TIPO_VISITA
GROUP BY RTV2.CODIGO_TIPO_VISITA)
GROUP BY CODIGO_GUIA

 Esta consulta SI TIENE REFERENCIA EXTERNA

Ejemplo 3 (IN): Listar guías que hayan guiado a visitas con 40 alumnos o más.

SELECT G.CODIGO_GUIA, G.APELLIDO_GUIA, G.NOMBRE_GUIA FROM GUIA AS G

WHERE G.CODIGO_GUIA IN (SELECT RTV.CODIGO_GUIA FROM RESERVA_TIPO_VISITA AS RTV
WHERE RTV.CANTIDAD_ALUMNOS_REALES >= 40)

Ejemplo 4 (EXISTS): Listar código y nombre de las escuelas que hayan tenido alguna reserva con más de 40 alumnos reservados

SELECT E.CODIGO_ESCUELA, E.NOMBRE_ESCUELA

FROM ESCUELA E
WHERE
EXISTS (SELECT 1 FROM RESERVA_TIPO_VISITA RTV
INNER JOIN RESERVA R ON RTV.NUMERO_RESERVA = R.NUMERO_RESERVA
WHERE RTV.CANTIDAD_ALUMNOS_RESERVADOS > 40
AND R.CODIGO_ESCUELA = E.CODIGO_ESCUELA)

Ejemplo 5 (ANY): Listar los números de las reservas cuya cantidad real de visitantes sea mayor que la menor de las cantidades
reservadas

SELECT DISTINCT RTV.NUMERO_RESERVA

FROM RESERVA_TIPO_VISITA RTV
WHERE RTV.CANTIDAD_ALUMNOS_REALES > ANY
(SELECT CANTIDAD_ALUMNOS_RESERVADOS FROM RESERVA_TIPO_VISITA)

CLASE 14/05
Taller Práctica SQL
CLASE 18/05
PROCEDIMIENTOS ALMACENADOS (STORED PROCEDURES)
Un Procedimiento Almacenado es un programa escrito en lenguaje del DBMS, almacenado como parte de la Base de Datos.
- Aceptan parámetros de entrada y entregan valores en forma de parámetros de salida. Puede estar codificado de tal forma que acepte
parámetros ingresados por el usuario o no, dependiendo del caso, y el mismo criterio aplicaría para parámetros de salida. El
procedimiento almacenado puede devolver una tabla, de la misma manera que una consulta del SELECT, puede devolver parámetros
que se pasan a otros procedimientos, o tranquilamente puede no devolver nada y que su ejecución consista en que haga cambios en
el fondo de los cuales el usuario no esté precisamente al tanto, a menos que se ponga a leer todas las instrucciones contenidas dentro
de ese procedimiento externo.
- Contienen instrucciones de programación que realizan operaciones en la base de datos
- Manejan errores, devolviendo un valor de estado que indica si la operación se ha realizado correctamente o ha habido un error. Es
decir, como un control adicional de seguridad, los procedimientos almacenados pueden están diseñados de tal manera que manejen
múltiples escenarios, de los cuales se encuentren escenarios en los que haya ocurrido algún error a la hora de hacer una carga o una
modificación de datos y ese error, con tal de transmitírselo al usuario, se puede manifestar a través de estos parámetros de salida, que
pueden devolverle al usuario un código de error. Los errores pueden estar codificados de tal forma que un usuario puede estar al tanto
de qué significa cada error.

 Es un procedimiento que consiste en una o un conjunto de instrucciones, sencillas o complejas, que están codificadas dentro de la
base de datos, simulando lo que sería una o varias consultas realizadas por un usuario, que se ejecutan de manera automática o
mecánicamente en el momento en que nosotros iniciamos este procedimiento almacenado, llamándolo de manera manual o de
manera automática de cualquiera de las circunstancias que lo fuese a llamar.

Ventajas
- Permiten una programación modular. En vez de realizar operaciones complejas, todas concatenadas dentro de una misma consulta o
un mismo proceso, un procedimiento almacenado nos permite iterar distintas operaciones que se encuentran dentro del mismo
proceso. Ejemplo, tenemos la opción de hacer una modificación de datos (UPDATE) con 20 millones de criterios, un procedimiento nos
permitiría poder incluir unas 20 diferentes operaciones de UPDATE sencillas dentro del mismo procedimiento, que estén armadas de tal
forma que no se pisen entre sí, no se contradigan, etc. Esto se puede atomizar aún más si hiciéramos un procedimiento almacenado
para cada operación, en donde todos los procedimientos podrían conectarse con un procedimiento general que lo llame a todos los
procesos (mismo sentido que las subconsultas, las cuales se ejecutan dependiendo de la consulta principal y pueden ejecutarse tantas
veces como la consulta principal les arroje datos).
- Se puede crear el procedimiento una vez, almacenarlo en la base de datos y llamarlo desde el programa tantas veces como desee. Los
procedimientos almacenados, a diferencia de una consulta tradicional donde tenemos que escribir en el motor y ejecutar, se almacenan
dentro de la base de datos. Procesos codificados dentro del mismo servidor de la base de datos. De tal forma que no solo el usuario que
los creo, sino también cualquier otro usuario que tenga accesos y permisos para poder ejecutarlo, pueden llamarlo y ejecutar sus pasos
de manera automática, con una simple llamada dentro de una consulta, que pide ejecutar un procedimiento especifico.
- Permiten una ejecución más rápida: Los procedimientos son analizados y optimizados después de haberlos ejecutado una primera vez,
y es posible utilizar una versión compilada del procedimiento que se encuentra en la memoria. Es más rápida, porque un procedimiento
mientas más complejo sea, mas instrucciones contiene, y más tiempo y tráfico de red le ahorra al usuario a la hora de tener que
ejecutar todos estos pasos en la base.
- Pueden reducir el tráfico de red: Una operación que necesite centenares de líneas de código SQL puede realizarse mediante una sola
instrucción que ejecute el código en un procedimiento, en vez de enviar cientos de líneas de código por la red. De la misma manera que
nosotros en un procedimiento podemos incorporar unas 100 instrucciones diferentes, llamar al procedimiento almacenado nos permite
ahorrar mucho tráfico de red, minimizando todas esas instrucciones en 1 sola, siempre y cuando todas esas instrucciones que queremos
llamar sean equivalentes al procedimiento mismo.
- Pueden utilizarse como mecanismo de seguridad: Es posible conceder permisos a los usuarios para ejecutar un procedimiento
almacenado. Nos permiten poder establecer un nuevo parámetro de seguridad, dado que podemos aplicar permisos específicos a los
usuarios de un servidor de base de datos, de tal forma de que no solamente no puedan ejecutar instrucciones de modificación, sino que
también puedan ejecutar procedimientos almacenados específicos con tal de poder ahorrarnos problemas para poder traquear todos
los cambios que se hicieron para poder preservar cambios para auditorias y demás. Los procedimientos almacenados, como
instrucciones especificas que son, tranquilamente pueden ser limitadas a un conjunto de usuarios con la responsabilidad suficiente para
ejecutarlos.

 Ejemplo, si todos los días tuvieses que actualizar los precios un 5%, si tuvieses que actualizarlo en unas 10 tablas, significa que
tendrías que modificar manual esas 10 tablas. Ahora, si quisiera simplificar ese proceso, podría crear un procedimiento que contenga
unas 10 instrucciones de actualización y, en vez de tener que escribir una y otra vez esas 10 instrucciones de actualizados, podemos
incorporarlas dentro de un procedimiento, en cual puedo ya armarlo y que de manera automática haga esas 10 ejecuciones, y yo, en
vez de escribirlo 10 veces, escribir una línea de texto que dice “llama a este proceso”. Seria el SIMIL DE UNA MACRO EN VISUAL BASIC u
otro lenguaje de programación.

Sintaxis
CODIGO SQL: si un procedimiento contiene tal info para ejecutar, va a estar dentro de la sección SQL.

Ejemplo 1

Crear un procedimiento almacenado que liste los nombres de las escuelas que comiencen con una cadena de texto determinada por un
parámetro de entrada (con valor predeterminado: comienza con “Esc”).

 Creo un procedimiento que este diseñado para que yo pueda ejecutar esta instrucción de SELECT una y otra vez, sin tener que
escribir la consulta. Simplemente lo único que hago es pasarle un parámetro de entrada con la cadena de texto que dicer “Esc”.

CREATE PROCEDURE ListaEscuelas @Nombre char(20)

AS
SELECT Nombre_Escuela
FROM Escuela WHERE Nombre_Escuela LIKE @Nombre

Ejecucion: EXEC ListaEscuelas ‘Inst%' –

TRIGGERS
- Un Triggers o disparador es una rutina autónoma asociada con una tabla o vista que automáticamente realiza una acción cuando se
inserta (INSERT), se actualiza (UPDATE), o se borra (DELETE) una fila en la tabla.
- Un Trigger nunca se llama directamente. A diferencia de los procedimientos almacenados que yo los defino, los armo, y puedo hacer
una instrucción para poder ejecutarlo, basándome en un parámetro o lo que fuese, el trigger siempre actúa las sombras. Desde el
momento en que yo lo creo, solamente va a funcionar dentro de la base de datos cuando haga operaciones que lo llamen. Fuera de eso
no hace nada.

 Son rutinas que se ejecutan de manera automática dentro del motor de base de datos. Van a actuar, en principio, dentro de una
tabla en la cual están definidos. Se va a encargar de hacer un conjunto de instrucciones que están demarcadas dentro del trigger
mismo, que solamente van a realizarse cuando se lo llame al trigger, y se lo va a llamar si se hacen operaciones de modificación dentro
de tabla en la que está basada (INSERT, UPDATE, DELETE). Es decir, el trigger está definido dentro de una tabla. Si yo hago alguna
operación de modificación, esas operaciones van a llamar al trigger que va a hacer su propia operación.

Componentes de un trigger
- Evento: es la modificación de datos que se controla con el trigger, y hará que este se dispare. Si se hace un INSERT, UPDATE o DELETE
dentro de la tabla en el cual está basada el trigger, entonces el trigger va a actuar, ya sea por un usuario o un procedimiento que hace
esas operaciones.
- Condición: debe verificarse para que el trigger se dispare. Lo que va a determinar si un trigger actúa o no. Las condiciones de acción.
- Acción: La acción (normalmente una modificación de datos o evitar que la operación en curso se realice) que se produce como
reacción de la BD ante el cambio. Todo lo que está contenido dentro del trigger mismo. Es todo lo que va a actuar en respuesta a una
acción que se esté haciendo en la base.
Ventajas del Trigger
- Evitan el almacenamiento de información errónea en la base de datos. En el caso de que alguien empiece a insertar registros en la
tabla, si hay un trigger diseñado para acciones de inserción en la tabla, este trigger puede tener un conjunto de reglas que dicen si esto
pasa o no pasa. Entonces, incluso si yo inserte mil registros, el trigger solo me permite pasar 10, y los demás me los borra (ejemplo tipos
de datos equivocados, controles de texto, de fecha, numéricos, etc.)
- Aumentan la integridad referencial o conseguir una seguridad adicional. Pueden actuar en base a operaciones de inserciones de
datos, pero si esta inserción de datos va de una manera referencial con otras tablas y yo no ingreso los datos consecuentes de las itras
tablas, el trigger puede empezar a actuar. Ejemplo, si cargo una escuela en la tabla de Jurassic Park y hay un modelo de negocio que me
dice que todas las escuelas tienen que traerme un número de teléfono, puede existir un trigger que, en base a que yo cree una nueva
escuela, me cree un número de teléfono y quizás le pone 1111, pero con tal de que exista el registro, lo crea, y lo que se espera es que
luego el usuario modifique ese teléfono.
- Controlar restricciones de usuario: por ejemplo, una regla de negocio de una empresa puede especificar que un empleado no puede
ganar más que su jefe. Los triggers pueden estar armados de tal forma de que las cargas de datos que haga un usuario estén limitadas a
las reglas de negocio que dice acá. Ejemplo, tales personas nunca pueden tener más salario que otra, etc. De una manera u otra, se
controla la carga de datos.
- Mantenimiento de valores deducidos: Si tenemos una tabla con valores parciales de ventas y otra con totales, al insertar, borrar o
modificar un valor parcial, automáticamente se actualizará el valor total.
- Mantener coherentes las tablas replicadas en una BD distribuido. Contengan los mismos datos a pesar de que estén distribuidas. Si
tengo tablas espejadas, el trigger realiza ese espejo de la base original, y lo replica en la tabla espejada.
- Registrar en tablas de auditoria las actualizaciones de la base de datos. Para cualquier usuario que haga cualquier tipo de cambio
dentro de la base de datos, un trigger puede identificar el usuario qué realizo el cambio, en qué fecha, en que hora y en qué tabla. Uso
mas frecuente que se le da a todos los triggers

Circuito de operación de los triggers

Ya sea un usuario o un procedimiento, hace las operaciones de inserción, actualización o borrado en una base de datos, esto puede o
no llamar a un trigger, que actúe de manera automática y que ejecute un conjunto de acciones que están definidas dentro de un mismo
trigger.
Hay dos modos de operaciones que puede llegar a tener un trigger.
a) INSTEAD OF (REEMPLAZA): el trigger está definido de tal forma de que reemplace la operación que lo llamó. Si inserte un registro en
la tabla escuela, y tengo un trigger en la tabla escuela que esté armado con un INSTEAD OF, el trigger lo que va a hacer es obviar lo que
acabo de insertar en la tabla y realizar sus propias operaciones
b) AFTER/FOR (DESPUES): las acciones del trigger se van a ejecutar después de las acciones que lo llamaron. Es decir, si hago un INSERT
INTO escuela, y tengo un trigger sobre esa tabla, primero espera a hacer la inserción y luego se ejecuta el trigger

 Todos los datos que intervienen están en una especie de nebulosa. Hasta que no se termine de ejecutar el trigger, no ocurre la
acción inicial. Acá entran en juego tablas intermedias.
- TABLA INSERTED: va primero a esta tabla y luego a la tabla que se va a modificar/insertar
- TABLA DELETED: va primero a esta tabla y luego va a parar de DELETED a la nada misma, porque se borra. La crea con el trigger de ese
momento. Luego la borra. Es temporaria.

Sintaxis de los Triggers

1) CREATE TRIGGER/ALTER/DROP (su creación)

2) Nombre del Trigger (el nombre)
3) ON
4) Se especifica cual va a ser la TABLA O VISTA sobre la cual va a estar basado este trigger (en qué tablas va a actuar)
5) FOR, AFTER, INTEAD OF (en qué momento va a actuar)  FOR y AFTER es lo mismo
6) INSERT, UPDATE O DELETE (con qué operación va a actuar)
7) Línea de definición para ver lo que va a ser el trigger arranca con un AS
8) IF: condición que se tiene que cumplir para que se arranque un procedimiento
9) CODIGO SQL (Código SQL que va a conformar el TRIGGER)
Ejemplo

Crear un trigger sobre la tabla Reserva_Tipo_Visita que en caso de que se borre una fila de ésta elimine las respectivas filas de la tabla
Guía.

CREATE TRIGGER trig_delete ON reserva_tipo_visita FOR DELETE

AS

DELETE FROM reserva_tipo_visita

WHERE codigo_guia IN ( SELECT codigo_guia FROM deleted ) ;

La única forma de saber lo que se borró, es ir a la tabla DELETED. Es una tabla temporaria. En este caso, DELETED tiene la estructura de
la tabla “reserva_tipo_visita”. Lo que hace es buscar todos los código_guia que se encuentran en la tabla DELETED, y lo elimino.

Resumen
1) PROCEDIMIENTO ALMACENADO: es un programa almacenado en la base para la realización de operaciones específicas. Estos
pueden estar armados de tal forma que un usuario los use por su cuenta o también pueden estar armados de tal forma de que actúen
de manera automática por estar incorporados a un procedimiento mayor. De la misma manera que con las subconsultas, el
procedimiento almacenado puede anidar procedimientos almacenados, y a su vez, los parámetros de entrada y de salida pueden hacer
que estos procedimientos se comuniquen entre si pasándose códigos, pasándose valores, etc. Pueden venir desde afuera o desde
dentro, a través de archivos de entrada. Un procedimiento bien armado también puede tener un control de errores, en caso de que
pase algo, por ejemplo, si un procedimiento esta diseñado de tal forma que se espere que se le pasen valores específicos, puede haber
un control de errores que chequee si el parámetro de entrada que se le paso fue un valor nulo. Si pasa eso, lo que puede hacer el
procedimiento almacenado es que puede estar diseñado para que pare todo, arroje como parámetro de salida un código de error. El
usuario ve ese código de error y lo soluciona.
 Instrucciones de programación de estos procedimientos almacenados tienen que ver con la eficiencia detrás de estas operaciones,
que como todo procedimiento que esta codificado dentro de la base, va a estar armado de tal forma que actúe de la manera más
eficiente y de que consuma la menor cantidad de recursos posible. Una vez que esta indexado, actúa con una eficiencia mayor que si
nosotros lo ejecutáramos de una manera manual.
- Parámetro IN-OUT
- Manejo de Errores
- Instrucciones de Programación

2) TRIGGERS: rutinas autónomas que están asociadas a una tabla o vista, y que actúan de manera automática en el caso de que un
evento los despierte. Esta asociado a una tabla, solo a UNA tabla, y que hay una o mas acciones que van a hacer que ese trigger se
active. Fuera de eso esta completamente “dormido” y no hace nada. Tampoco se puede llamar de manera manual, SOLO DE MANERA
AUTOMATICA en caso de que haya un INSERT, ALTER O DELETE que lo llame.
Los triggers pueden estar relacionados a las reglas de negocio que mencionamos, es decir, pueden llegar a ser acciones ante acciones.

Propósitos:
- Reglas de negocio
- Validaciones
- Restricciones
- Integridad Referencial: mantener la integridad referencial. En vez de eliminar datos de varias tablas, el trigger me hace borrarlo solo
de una y automáticamente se borre de la otra.
- Auditoría

CLASE 21/05
Procesamiento de consultas – Etapas

1) ANALIZADOR Y TRADUCTOR: para poder realizar el punto 2, tiene que pasar por esta etapa para, por un lado, traducir esto que está
en una sentencia que, en la mayoría de los casos es SQL, lenguaje pensado para que un usuario pueda comentar que es lo que quiere
obtener como resultado, a un lenguaje del algebra relacional que le sea lo más fácilmente posible trabajarlo, con la posibilidad de
optimizarlo.
Para eso hace distintas actividades:
a) Análisis sintaxis en instrucciones: relacionadas más a operaciones que hace cualquier lenguaje de programación
b) Traducción al algebra relacional extendido (árbol invertido). Traducido a sentencias del algebra relacional, con el cual puede empezar
a hacer distintas operaciones que le permitan justamente optimizar la consulta. En estas operaciones del algebra relacional, está
planteado como árbol invertido, donde se plantea en forma alborea, que se lee de abajo hacia arriba y de derecha a izquierda.

c) Valida nombres objetos en catalogo y operaciones válidas

d) Análisis semántico (ej.: predicados contradictorios: Sucursal.Ciudad = ‘Londres’ AND Sucursal.Ciudad <> ‘Londres’)
e) Resolver vistas y simplificación

2) OPTIMIZADOR: la etapa más significativa ya que es donde, sin importar como hayan escrito la consulta, trata de realizarla de una
manera que tenga el menor tiempo de respuesta a la hora de ejecutar esa consulta. Por lo tanto, desde que tiro la consulta hasta que
tengo el resultado, tarde la menor cantidad posible de tiempo.
 Luego del este proceso de análisis y traducción, llego a una expresión del algebra relacional, es donde, a través del optimizador, el
motor va a evaluar distintos posibles planes de ejecución de la consulta para terminar llegando a una expresión o plan de ejecución,
que es la forma de ejecutarlo que finalmente va a elegir. Se basa en tres elementos, para poder armar estos N planes de ejecución, para
finalmente elegir el que considere óptimo:
a) Expresiones equivalente: va a poder, aplicando determinadas reglas del algebra relacional, generar distintas expresiones que se
llaman equivalentes. Todas estas expresiones son equivalentes del algebra relacional que terminan dando el mismo resultado.
b) Primitivas de cada operación: es decir, cada una de esas operaciones que veíamos que existen en las expresiones equivalentes, las
operaciones del algebra relacional. Para poder hacer esa operación de selección, puedo hacerlo de distintas maneras, de distintos
algoritmos, distintas formas de recorrer esa tabla e ir seleccionando cuales cumplen tal condición (ejemplo índice clúster). La primitiva
entonces quiere decir que, para cada una de las expresiones equivalentes, cada una de las operaciones a su vez se podrían realizar de
distinta manera. Esa combinación entre expresiones equivalentes, y por cada expresión equivalente, distintas formas de realizar cada
una de las operaciones, lo que se llama las primitivas de cada operación, da un conjunto grande de posibles planes de ejecución
alternativos sobre los cuales el optimizador va a elegir cual va a ser el más eficiente.
c) Materialización o encauzamiento: último aspecto que puede usar al plantear los distintos planes de ejecución que es lo que se llama
materialización, que quiere decir que va a ser con el resultado de cada una de esas operaciones que planteábamos recién. Siempre, lo
que tenemos en las expresiones del algebra relacional, tenemos un conjunto de operaciones donde siempre, el resultado de una
operación es una tabla, que va a ser el input de la operación siguiente. Entonces, según que haga con esta tabla, es lo que hagamos, si la
materializa significa que la va a almacenar en disco, si puede encauzarla, es que no necesita este resultado intermedio estar
guardándolo en disco, por lo tanto, la operación 2 va usando directamente lo que va saliendo de la operación 1.
 El encausamiento es mucho más performante que la materialización porque la materialización, uno de los tiempos principales en
toda consulta, tiene que ver con la lectura y escritura en disco rígido. Entonces, en la medida que no pueda encauzar y tenga que
materializar, ahí voy a tener tiempos adicionales. En la consulta no solo tengo los tiempos de lectura de las tablas para estar
generando la consulta, sino que entre operación y operación tengo que estar escribiendo el resultado de una de las operaciones.
Esto me suma tiempos a la consulta. Esto es contemplado por el optimizador y va a ver determinados planes de ejecución que
pueden encauzarse en la medida que previamente haga una operación. Ejemplo, si necesito que los datos vengan ordenados, quizás
necesito que se ejecute toda la operación antes de que se haga la siguiente, por lo cual no puedo estar encauzando, necesito terminarlo
todo. Ahora, si previamente si hice una operación de ordenamiento, entonces la siguiente operación va a poder ser encauzada y no
necesita ser materializada. Este aspecto se introduce dentro del diseño de los posibles planes de ejecución.
 Como a partir de estos tres elementos se generan n planes de ejecución, el optimizador después, a través de lo que va a evaluar,
principalmente basado en costo, va a poder seleccionar un plan de ejecución que va a ser el que se va a finalmente ejecutar.

Diferencia entre heurística y costo:

- La heurística no trata de ver cuál es la estimación del tiempo que va a tardar cada uno de estos planes, sino, lo que trata de hacer es
seleccionar el mejor plan respecto de determinadas reglas, porque sabe que hacer determinadas operaciones antes que otras suelen
ser más rápido que de otra forma. No es que evalúa cual seria el posible costo, sino que, de alguna manera, elimina planeas siguiendo
determinadas reglas. La mayoría de los motores, actualmente, si bien son basados en costos, usan también la heurística para eliminar
planes que no tendría sentido de evaluar porque todo este proceso de optimización lleva tiempo, para el usuario final es tiempo de
ejecución, entonces va a tratar de minimizar los planes que tenga y luego si minimizar el costo.
- El costo:
 Relación con el catálogo de estadísticas:

¿Si tuviese distintos planes alternativos y tendría que elegir el mejor, siendo el optimizador, cómo lo haría? Hay 50 posibles planes de
ejecución, ¿cuál sería el más conveniente?
Lo que queremos minimizar, el costo, es el tiempo de cada uno de los planes de ejecución. Para saber cuánto tarda cada plan, lo tendría
que ejecutar. Entonces no tendría sentido que ejecute 50 planes de ejecución para ver cuánto tarda cada uno y luego elegir el mejor,
porque sería el peor de los mundos. No es que piensan en estadísticas, sino que van guardando en un catálogo de estadísticas datos
acerca de los datos que están guardados. Estos datos le sirven, para sin ejecutar cada uno de los planes, trata de estimar cual podría
tardar más y cuál podría tardar menos. Principalmente tomando estos parámetros para saber qué plan de ejecución va a tardar más
que otro. Lo hace estimando:
- E/S disco: cada uno de estos planes, cuantas entrada y salida de discos va a tener
- CPU: que nivel de procesamiento de CPU voy a necesitar hacer
- Conectividad: este también puede ser un componente significativo si tenemos la base de datos distribuida en distintas localizaciones o
particiones. Los principales son el disco y la CPU.

 ¿Qué quiere decir que evalúa el costo? Quiere decir estimar, que solo la puede hacer con estadísticas. No es cuanto tardo una
consulta anterior, sino que son datos que le permiten estimar cuanto va a tardar un plan respecto de otro.

Entonces, si puedo hacer una consulta y escribirla de distintas maneras, el optimizador debería, en base a las estadísticas, darle a todas
el mismo plan de ejecución porque el resultado es el mismo, y debería ver de usar el plan de ejecución que menos tarde.
 Este plan de ejecución, a su vez, lleva tiempo. El tiempo que tarda en hacer esa optimización tendría que tener relación con el
tiempo total de la consulta. Es decir, si a mi una consulta me tarda 2 milisegundos, no tiene sentido que yo use 2 milisegundos
adicionales del plan de ejecución para optimizarla a 1 milisegundo, porque en total me va a tardar 3 milisegundos. Entonces, ese tiempo
extra de optimización tiene que ir en relación con lo que decimos que va a tardar la consulta. Hay veces que el optimizador puede optar
por no necesariamente usar el mejor de todos los planes de ejecución, porque quizás tratar de optimizar al máximo nivel le lleva mas
tiempo que el tiempo que le puede llevar la consulta optimizándolo menos.
Las ESTADISTICAS lo que van a estar guardando son:
- A nivel Tablas:
Número de filas, factor de bloqueo, bytes por fila, número de páginas.
- A nivel Índices:
Número de filas, cantidad de niveles, factor de bloqueo, número de páginas.
- A nivel Atributos: histogramas (muestreo o full)

Histograma: se usa esos como estadísticas sobre los distintos atributos de una tabla, para saber que cantidad de valores hay de cada
uno del dominio. Esto sirve al optimizador para la hora de estimar, ya que, si tiene el histograma puede saber el resultado de la
selección. Si no tuviese este histograma, se pensaría que existe una distribución normal, por lo cual va a ser mucho menos preciso los
cálculos que va a poder hacer. Esto no es gratuito, implica espacio en disco y tiempo extra de actualización ya que, cada vez que se
actualiza la base de datos, podría estar actualizando estas estadísticas. Se hace generalmente asincrónico por intervalos de tiempo. Se
busca un justo equilibro entre poder estimar lo mejor posible y no arruinar la performance por estas estadísticas.

3 expresiones equivalentes, diferencias:

- 1 opción: 101.050 accesos a disco
- 2 opción: 3.050 accesos a disco
- 3 opción: 1.160 accesos a disco

Cuando hablamos de que vamos a hacer una selección, va a tener distintas primitivas de hacer esa selección. En realidad, para todas las
operaciones pasa lo mismo.
 Cuando se evalúan las distintas estimaciones de cada primitiva, es distinto si el atributo es clave primaria si el atributo no es clave
primaria.

SELECCION

Ejemplo

Ej 1: Legajo = 3000. Ej 2: Puesto = ´Gerente´ . Consulta en SQL donde se busca al empleado donde legajo es igual a 3000

Tabla empleado: 1000 filas / factor de bloqueo 20: total de bloques (b) 50 (Bloques de 8 kb y filas de 400 bytes)
 Entran 20 filas en cada bloque, en total entran 50 bloques.

a) Búsqueda lineal: empezábamos por la primera fila, y vamos recorriendo uno a uno, buscando el criterio legajo = 3000. Bajas fila a fila
hasta encontrarlo. Nos permite encontrar un registro y hacer una selección que primero se puede usar solamente cuando los registros
de un archivo, como en este caso las filas de una tabla, están ordenados. Si no están ordenados, no podría usarlo. Partiendo del lugar
que están ordenando, hace saltos de a mitades. Entonces va a la mitad y se fija si legajo, que en este caso es igual a 3000, es mayor o
menor a lo que llegué. Descarto la parte en donde no se encuentra. Luego, vuelve a saltar a la mitad de esa parte en el medio, y vuelve
a preguntar, y así sucesivamente. Va partiendo el archivo de a mitades, por eso tiene que estar ordenado por el criterio de búsqueda
que estoy haciendo.
 La estimación que va a hacer el optimizador es la siguiente (el resultado son bloques, cuantos accesos a disco que son cuantos
bloques tiene que leer):
- Para clave primaria: b/2: son 50 bloques el total. Como es una búsqueda lineal, empieza a buscar todo. Ahora, como es la clave
primaria puede ser que lo encuentre en el primer bloque como en el último bloque. Lo que se hace es 50/2, para estimar. En este caso
serían 25 bloques. En este caso, cuando encontró el 3000, frena el proceso porque no puede existir otro.
- Para <> clave primaria: b: si usáramos puesto = gerente, estimaríamos 50 veces. No me queda otra porque no es clave primaria. En
este caso, cuando llego a “gerente” no frena porque no le queda otra porque no puede ir hasta el final. Necesariamente va a ser la
cantidad total de bloques

b) Búsqueda binaria:
- Para clave primaria: Log2 b: llegar a la primera fila que sea gerente (log2). División n veces por mitades hasta llegar al que cumple la
condición. Es de base 2 porque voy dividiendo de a mitades. Voy partiendo a la mitad y veo si es mayor o menor y accedo a un bloque, y
vuelvo a partir, y así sucesivamente. Llego a la fila que estoy buscando. Una vez que llegue a ese bloque, termine.
- Para <> clave primaria: Log2 b + n/Fb: Se hacen las distintas particiones para llegar al valor. Van a tener que sumarle (n seria la
cantidad de filas que cumplen la condición, que en nuestro caso son 50 gerentes) 50 sobre factor de bloqueo. Van a estar todos juntos
en el mismo bloque. Vas a ser + tantos bloques como entren + 3 bloques (gerentes divididos en tres bloques). N es la cantidad de filas
que cumplen el criterio de selección. En este caso, tengo que ver cuantos bloques tengo que sean cargo = gerente.

c) Índice primario: entramos a hacer una búsqueda de una tabla que tenga un índice primario. En las base de datos relacionales, el
índice primario se aplica a través del índice clúster (no es sinónimo de índice primario, sino un tipo). Quiere decir que los datos están
ordenados por el mismo criterio que ese índice. Tener datos ordenados que no sean de manera arbórea no serian eficientes para un
procesamiento en línea. Solo funciona en base a un índice clúster, pero no es que esta todo ordenado, sino que están ordenados dentro
del nodo hoja, y accesos a través de un índice B+. El índice clúster es un índice B+, donde el nodo hoja, en vez de tener punteros, tiene
todas las columnas, filas y datos de la tabla, pero que previamente se puede acceder a través de un índice multinivel con punteros en
los nodos, ramas y raíz.
- Para una clave primaria: N (Para un índice clúster, si quiero buscar legajo = 3000, y existe un índice clúster por legajo. Va a empezar
por el nodo raíz, y una vez que accedió a ese bloque es el primer nivel, ve si es mayor o menor, y así sigue saltando al segundo nivel y
sucesivamente, la cantidad de niveles que tenga. Cada nivel va a ser un bloque que tiene que leer. Cuando llega al nodo hoja, que es el
último de los niveles, ahí llega al legajo, porque ahí está el dato. Para clave primaria es igual a la cantidad de niveles)
- Para <> clave primaria: N + n/Fb (cuando quiero buscar puesto = gerente, N mayúscula para llegar al nodo hoja, dentro del nodo hoja,
como es un índice clúster por puesto, en ese nodo hoja están todos los gerentes, entonces tiene que ver el factor de bloque porque
quizás están en otros bloques. Como el índice clúster es un índice B+, tiene puntero al siguiente bloque y el siguiente bloque, como esta
ordenado por puesto, también va a ser alguien que tenga gerente, entonces son simplemente saltos de bloque, tantos como n/fb (fb es
factor de bloqueo))

d) Índice secundario: N + 1. Voy a hacer una selección, donde tengo un índice secundario de la columna legajo, lo que quiere decir esto
es que voy a tener un índice por el legajo, pero los datos no están ordenados por ese mismo criterio, ya sea porque tienen un índice
clúster por otro atributo o los datos están ordenados de montón, es decir, no están ordenados, entonces l que van a tener cuando
tienen un índice son todos índices secundarios, pero no hay ningún índice primario porque se decidió que no estén ordenados los datos.
En nuestro caso el legajo tiene un índice que es solamente índice pero que los datos no están ordenados por ese mismo criterio.
- Para una clave primaria: cantidad de niveles. Es igual que el otro, porque los índices secundarios también son índices B+, que son
multinivel, y que tardan en llegar al nodo hoja la cantidad de niveles. Lo que pasa es que cuando llegaron al nodo hoja, ¿ya llegaron al
bloque donde está el legajo 3000? No, hay que leer ese (N + 1). Cuando tienen el puntero, le falta todavía un bloque más para llegar a
los valores. N es la cantidad de niveles, +1 es llegar a los datos dentro del bloque final.
- Para <> clave primaria: N + n. Hay que tener en cuenta que, en los índices secundarios, los registros están ordenados por la clave de
búsqueda, pero el puntero me manda a cualquier lado. Los datos no están ordenados por ese criterio. Entonces, en un caso me va a
mandar uno, en otro caso me va a mandar otro. En cada caso me esta mandando a uno distinto.

 Todo esto lo calcula el optimizador a la hora de elegir distintas primitivas. Esto muestra como distintas expresiones equivalente
pueden impactar mucho en los accesos, y a su vez, cada expresión equivalente según la primitiva que usen para hacer cada una de esas
operaciones también puede generar costos totalmente distintos a niveles de accesos. Estas estimaciones se hacen también, no solo de
acceso a disco, sino también de CPU, porque hay primitivas que son mucho mas intensivas en procesamiento, entonces puede hacer
también un calculo respecto de eso.
Por otro lado, es obvio que algunos serian menos lógicos que otros, pero no siempre se pueden usar todos. La búsqueda lineal se
puede usar siempre, pero el índice clúster solo se puede usar si hay un índice clúster por ese atributo. Lo mismo con el índice
secundario. La búsqueda binaria la puedo hacer solo si está ordenado. Si es muy bueno, quizás primero puedo hacer una función de
ordenación, y luego esta búsqueda. O si es muy bueno con un índice, tengo que ver cuan costoso es generar un índice, para poder
aplicar el índice clúster.
Todo esto lo hace el optimizador, va optimizando los planes para finalmente elegir uno.
REUNION NATURAL

Bucle anidado: por cada fila de la tabla externa, va a recorrer todas las filas de la tabla interna, y viendo donde machea. Pasa fila por
fila. Esto me permite hacer un estimativo según la cantidad de filas y bloques de la tabla interna y de la tabla externa. Se puede usar con
un índice, en donde, cuando yo recorro por cada fila, en vez de recorrer toda la tabla, esto lo hago a través de un índice. Entonces, el
costo no es a nivel de todos los bloques sino de los niveles del índice.
Mezcla: si las filas estuvieran ordenadas por el atributo por el cual se hace la reunión natural, en vez del cálculo sea la multiplicación de
los bloques, pasa a ser la suma. Pero para eso tienen que estar ordenados por el mismo criterio.
Reunión por asociación: es la de hashing. En realidad, lo que hace es aplicar el algoritmo de hash, en donde, a un valor, le aplicamos un
algoritmo que me genera otro valor, pero dentro de un rango menor de valores. Entonces lo que se hace es aplicar para el atributo con
el cual se hace la reunión, en nuestro caso el código de sucursal, aplico para este valor y lo guardo en un determinado valor esta fila,
porque me da el valor que me da el hash. Lo mismo hago con todas las filas de la otra tabla. En conclusión, van a quedar almacenados
en forma conjunta las filas de la tabla 1 con las filas de la tabla 2, relacionando por código en común. Aplicando esto, es recorrer todos
los bloques de ambas tablas tres veces, pero que es mucho menor que el de la multiplicación de los bloques. Va a depender del tamaño
de las tablas y si tienen índices.

En resumen:
El criterio es el mismo, hay distintas primitivas que usan distintos algoritmos para hacer la operación, que tienen mas o menos costos, y
que a veces se pueden usar y a veces no.
 Vamos a tener, ante una consulta, un proceso de traducción, para llevarlo a una expresión de algebra relacional. Una vez que tengo
dicha expresión, se pueden generar n posibles planes de ejecución alternativos, usando expresiones equivalentes del algebra relacional,
usando distintas primitivas, usando la opción de materialización o encausamiento. A partir de ahí, y en base a las estadísticas, va a
poder el optimizador calcular costos de los distintos planes para elegir el mejor. Va a poder seleccionar algunos a través de la heurística,
porque también tiene que cuidar que ese proceso de calcular el mejor, lleve el menor tiempo posible, porque ese proceso es parte del
tiempo que el usuario final ve como tiempo de ejecución de la consulta. Entonces también tiene que minimizar ese tiempo que lleva la
optimización.

CLASE 28/05
Por lo general, la reunión natural, que es cuando se hace una consulta inner join en SQL, van a tener distintas primitivas. La más común
es de bucle anidado, que de alguna manera tiene que ver con tener alguna tabla que se toma como externa, y una tabla que se toma
como interna. Entonces, de alguna manera va a recorrer una a una la fila en la tabla 1 (tomo la primer fila de la tabla 1) y voy a recorrer
una a una las filas de la tabla 2, para ver cuál de esas tiene el mismo código de sucursal que la que tenia la primera fila de la tabla 1. Una
vez que termine con la ultima fila de la tabla 2, voy a la segunda fila de la tabla 1 y vuelvo a recorrer todas las filas de la tabla 2, y así
sucesivamente recorriendo todas las filas de la tabla 1.
 Cuando hacen el cálculo es una operación muy costosa, porque vamos a tener las n filas de la tabla 1 (tabla externa) por la cantidad
de bloques de la tabla 1 (tabla interna), multiplico, más la cantidad de bloques de la tabla empleado, pensando en que voy a
materializar y finalmente me quedan la cantidad de filas de la tabla 1. Me queda la cantidad de filas de la tabla 1 porque son los datos
de la tabla 1, enganchando lo que encontré en a la tabla 2.

Esto se puede mejorar, con un cambio mínimo del algoritmo, por lo cual no se usa mucho bucle anidado, sino que se usa bucle anidado
por bloque, porque en vez de tomar fila a fila de la tabla externa (tabla 1), lo que hace es ver todas las filas del bloque y una vez que las
tiene hace un recorrido de la tabla 2 para ver cuales se relacionan. Una vez que termino con todo eso, si va al siguiente bloque,
entonces, en este caso, en vez de multiplicar las filas por los bloques, multiplica los bloques por los bloques, que obviamente la cantidad
de bloques es menor a la cantidad de filas.

- Para clave primaria: no tiene que buscar el total de la cantidad de bloques, sino, una vez que lo encontró, ya puede frenar. Entonces,
cuando del lado de la tabla interna es una clave primaria, ese cálculo es menor.
Otra forma de hacer este algoritmo es usar, para la parte de adentro, un índice. Entonces, lo que vamos a tener es la cantidad de
bloques de la tabla externa, pero para la tabla interna, en vez de recorrerla uno a uno, lo que va a hacer es buscar a través del índice,
entonces no tiene que recorrer toda la tabla sino, lo que tiene que recorrer es, en el árbol B+, la cantidad de niveles para llegar y
encontrar cual es en nuestro caso este dato buscado.
 Cuando tengo un índice por lo que sería la clave de búsqueda de la tabla interna, va a tener una estimación más corta que si
tuviéramos que recorrer todos los bloques.

Reunión por Mezcla: necesita que las tablas estén necesariamente ordenadas, por lo cual, si no están ordenadas, debería haber una
operación previa por el mismo criterio. El orden de las dos tablas tiene que estar dado por el atributo por el cual se está haciendo el
join. En nuestro caso, la tabla empleado (tabla 1) debería estar ordenada por código de sucursal, y la tabla sucursal (tabla 2) también
debería estar ordenada por código de sucursal. De esa manera, lo que va a poder hacer es recorrer, tomo el primer bloque de la tabla
externa, de la tabla empleados en nuestro ejemplo (del legajo 45 al legajo 235), y una vez que tomo ese bloque, toma el primer bloque
de la tabla sucursal. Como esta ordenado, no tiene que seguir recorriendo todos los bloques, sino se va a quedar en el primer bloque de
sucursal, pero cuando continua, no vuelve a leer para atrás, ya que ambos están ordenados. En vez de ser la multiplicación de la
cantidad de bloques de uno por la cantidad de bloques del otro, va a ser la suma de bloques de uno por bloques de otro, porque solo
recorre una vez los distintos bloques

Reunión por Hashing: el hashing es una función que, ante un valor de entrada, aplica ese algoritmo, y nos da un valor de salida, pero
siempre de la misma longitud. Me sirve para achicar un valor más grande, en un numero de valores más chicos. Entonces, en el caso de
las bases de datos, se usa para poder asignar una dirección especifica en base a un valor. Cuando se habla de acceso directo, se suele
usar esta técnica de hashing para que un valor, que sería la clave de búsqueda, de algún manera es la que asigna la dirección en la cual
va a estar guardado esa fila, pero según el valor que tome ese atributo, entonces, por ejemplo, si estuviese ordenado por el número de
cliente, va a haber un hashing que, según el número de cliente, le asigna un número. Ese número es la dirección donde se va a estar
guardando ese registro. Me sirve para guardarlo y para consultarlo. Se llama de acceso directo porque puede ir directo a la dirección,
sin necesidad de tener que recorrer una tabla.
 Se puede usar para las reuniones porque, de alguna manera, lo que hace es que, el atributo de ambas tablas por el cual se va a hacer
el join, en nuestro caso por código de sucursal de la tabla empleado y tabla sucursal, lo que hace es, a todas las filas de la tabla
empleado, le aplica el hashing por el código de sucursal y las guarda en determinados bloques temporales que los usa para hacer el join.
Lo mismo hace con la tabla sucursal, también corre el hashing por el mismo código, y los guarda en los mismo bloques. Quiere decir que
las filas de empleado y las filas de sucursal que pertenecen a la misma sucursal van a estar todas en los mismos bloques. Luego puede
hacer el join recorriendo esos bloques. Por eso se considera que es la suma de los bloques de uno más lo bloques de otro, porque tiene
que recorrerlos para hacer el hashing, después tiene que recorrerlos para hacer el join y luego para materializarlos.

Planes de Ejecucion

CONSULTA INICIAL  PROCESOS  EJECUCION DE LA CONSULTA

La ejecución de la consulta se realiza recién al final, por lo cual, todo el resto de las actividades que se están realizando son un tiempo
extra a la ejecución real, pero para el usuario, el tiempo de ejecución es todo. Por lo tanto, siempre que se pueda se trata de evitar. Por
eso, una vez que se ejecuta un plan de ejecución, ese plan de ejecución queda guardado en cache, en memoria. Si detecta que estoy
ejecutando la misma consulta, no vuelve a hacer el mismo proceso, porque ya sabe cuál es el plan de ejecución (lo hace directamente).
En memoria puedo tener los resultados, y en ese caso es más rápido.
 Si el texto de la consulta es exactamente el mismo, no hace todo el proceso y lo ejecuta directamente.

Hay un concepto que se llama Blind de Variables que quiere decir que, a veces la consulta no es una consulta estática solo texto, sino
que de repente ustedes tienen determinados valores que pueden ir cambiando, más allá de que la consulta es la misma. Quiere decir
que, si yo tengo, donde puesto = gerente, pero ahora hago una consulta exactamente igual pero donde puesto = cajero, si bien la
consulta es la misma, no es exactamente lo mismo, entonces me haría todo el proceso de nuevo y no podría tomar la estimación previa.
Entonces, si yo quisiera que tome la estimación previa, es ese concepto de Blind de Variables donde en el fondo se lo toma como una
variable donde el texto es el mismo y usa el mismo plan de ejecución. Ahora, eso tiene un beneficio que es que ahorra el tiempo extra
de todo el analizador y el optimizador, pero que no puede usar el histograma, porque de alguna manera está para cada valor especifico.
Si se quiere evitar eso, vamos a perder la posibilidad de usar, si existiera, un histograma. Tendría que ser la media.

Cuando se guarda una consulta a través de un procedimiento almacenado, ese procedimiento almacenado ya está compilado, ya que
para estar compilado tengo que tener un plan de ejecución definido, porque tiene que tener claro que es lo que tiene que hacer.

Ajustes de rendimiento

¿Qué actores son los que van a estar asegurando un buen desempeño de la base de datos?¿Qué cosas se puede hacer cuando tenga una
base de datos productiva y quiero mejorar el desempeño?

Distintos niveles:
1) NIVEL HARDWARE: vamos a poder mejorar y hacer modificaciones en la arquitectura del hardware que hace el procesamiento y el
almacenamiento de la base de datos para mejorar el desempeño. Procesador, memoria principal ya acceso a disco.
2) NIVEL SOTFWARE DE GESTION DE BASE DE DATOS: a nivel del motor de base de datos, ajustar parámetros y configuraciones, o
ampliar memoria en determinadas gestiones, o repensar algunos índices, etc. Ya sean configuraciones o adecuaciones de la forma de
organización de los archivos.
3) DISEÑO DEL ESQUEMA: determinados aspectos del diseño de la base de datos que nos pueden ayudar a que la base de datos se
desempeñe de manera más performante. Cuando vimos diseño pusimos mucho foco en la claridad semántica, en que represente
adecuadamente la realidad que nos interesa que esa base de datos ayude a la organización a trabajar. Pero hay determinados aspectos
del diseño que podríamos adaptar para que además sea performante. Tiene que ver con el diseño de la base de datos, pero teniendo
en cuenta un mejor diseño.

Estas cuestiones están relacionadas con las tareas del DBA (ADMINISTRADOR DE LA BASE DE DATOS). Es el responsable de ir
planteando estas cosas. Lo del HW con interacción quien esté a cargo de la parte de infraestructura, pero en general, el que debería
plantear los criterios a modificar debería ser el DBA
 Hay una parte que no va a ser propia del DBA, pero donde el DBA debería trabajar en forma conjunta y colaborativa que es en como
esta escritas las transacciones en las aplicaciones que interactúan contra la base de datos. La mayor interacción contra la base de datos
se da desde el software, desde distintas aplicaciones que consulta y actualizan la base de datos. Si bien el optimizador trata de
independizarse de como estén escritas las transacciones, hay veces que hay aspectos que si van a implicar en como este escrita al
desempeño. El que escribe esas transacciones es el desarrollador de la transacción. El DBA trabaja en forma conjunta con el
desarrollador para mejorar como está escrita esa transacción y así mejorar el desempeño de la base de datos.

1) Ajustes de hardware: tiene que ver con:

- Procesador: mejorar procesadores
- Memoria principal: Tipo, cantidad y asignaciones  mejorar memoria principal.
- Acceso a disco: Tipos de discos – Configuración – Arquitecturas - Asignaciones (log, temporales, datos)>
 configuración del equipamiento que va a encargarse de la base de datos, que, al mejorarse, va a mejorar el desempeño. Debería ser
lo último en tocarse, porque a veces el principal aspecto no pasa por acá. Se debería iniciar analizando otros aspectos relacionados al
motor de la base de datos o en como estén escritas las transacciones.

Ajustes del DBA con el DBMS

 Algunos aspectos que se pueden modificar a nivel de la base de datos:
- Tamaño de memoria intermedia: asignaciones de cache para datos, para procedimientos almacenados, etc.
- Tamaño de bloques y de extensiones
- Asignación a discos de los archivos
- Actualización de estadísticas
- Reorganización de archivos de páginas de datos, porque se van fragmentando, al igual que pasa con los discos, y son subóptimos
cuando se recorren, es decir, ocupan mayor cantidad de bloques de los que deberían
- Regeneración de índices.
- Creación, modificación o eliminación de índices

1. Reorganizaciones
2. Regeneración de índices
3. Actualización de estadísticas. Recompilar

Diseño de esquema

Plantear las modificaciones a nivel del diseño de la base de datos

A nivel lógico:
- Dividir tablas mediante relaciones 1 a 1: puedo transformar a relación de 1 a 1 son distintos atributos de una misma tabla. Si tengo una
tabla cliente que tiene 50 atributos con 50 características del cliente, yo podría dividir en dos o tres relaciones de 1 a 1, con una tabla
con 5 atributos del cliente y otra con 45 atributos. Esto podría tener sentido, esta subdivisión, si yo voy a ser consultas de esos 5
atributos, en cambio, si voy a consultar atributos de ambas tablas, no tendría sentido, debería joinear, no genera un beneficio. Si uso
mucho los 5 atributos principales, y rara vez sobre los otros, si tuviese sentido.
- Elección de tipos de datos: hay que tener en cuenta que cuando veíamos que se puede usar para guardar lo mismo distintos tipos de
datos, ejemplo usar un int, smallint o bigint, eso afecta en la performance en el tamaño de los bloques, ya que, cuanto mayor cantidad
de bytes ocupa cada atributo, mayor cantidad de bytes ocupa cada fila y el factor de bloqueo es menor. Eso quiere decir que entran
menos filas por cada bloque. Es decir, la tabla va a ocupar mayor cantidad de bloques. Todo lo que tenga que hacer manipulando esos
bloques de esa tabla va a tener un peor desempeño.
- Datos desnormalizados (redundantes): aplicar redundancia siempre nos trae beneficios de performance positivos a nivel de escritura
porque, si tenemos dos tablas de la tabla ventas y la tabla de item_ventas, u en item_ventas tengo cantidad y precio, en ventas podría
tener un atributo redundante que sea el importe total de la venta, es redundante porque podría calcularlo recorriendo las distintas filas
de ítem ventas de esa venta y multiplicando cantidad por precio. Es más rápido para consultar porque no tengo que hacer todo ese
cálculo, directamente consulto ese atributo que está en venta. Ahora, a nivel de escritura tiene dos defectos, el primero es la mayor
posibilidad de generar inconsistencia, es decir, que no sea consistente lo que está en un lado de lo que está en el otro. En segundo
lugar, es más lento, más costoso, porque cuando tengo que actualizar no tengo que actualizar solo en un lugar, sino en dos lugares, por
lo cual lo hace más lento.
Pero, a nivel de desempeño puedo plantear aplicar algo de redundancia si quiero priorizar la consulta, mejorar la performance a nivel
de consulta, ateniéndome a las consecuencias de que tenga mayor probabilidad de inconsistencia y mayores tiempos de escritura. Pero
es una estrategia básica de aplicar redundancia.

Diseño lógico/físico
- Uso de vistas materializadas. Datos calculados
- Manejo de Particiones
- Índices: generacion de índices. Herramienta principal para mejorar la performance de una consulta. Contantemente se van a ir
generando índices, y se revisará si conviene que sea un índice clúster o índices secundarios. Cada vez que creo un archivo de índice, lo
que estoy mejorando es mi performance de las consultas, pero al mismo tiempo, estoy empeorando la escritura (la inserción en la
escritura), ya que, si tengo un índice nuevo, tengo que actualizar además de lo anterior ese nuevo índice. Toda inserción va a ser mas
lenta. Modificación si afecta a ese atributo, sino no afecta. Eliminación un poco menos. Principalmente me afecta mucho en las
inserciones nuevas de esa tabla.

En el desarrollo de transacciones
 Transacciones que el optimizador no tiene forma de saber si se podría hacer mejor.

Escritura de las consultas

1. Traer la menor cantidad de datos posible (Evitar el *, solo los datos que se usan, etc.): no se debería usar el *, solo deberían traerse
los atributos necesarios. Esas cosas, el optimizador no va a saberlo, porque quien sabe si se necesitan o no es quien esta escribiendo la
sentencia.
2. Tratar de evitar las iteraciones: Consultas anidadas complejas: reemplazar por Inner Join: tratar de evitar ciertas consultas anidadas
complejas que se podrían evitar con un join. Esto, por lo general, el optimizador se da cuenta y lo reemplaza. Las consultas anidadas
deberíamos destinarlas solo cuando no queda otra opción, seria siempre mejor usar el inner join.

Que el Optimizador use al máximo su potencial

1. Uso de cursores limitado: recorre la tabla registro a registro, realizando operaciones en cada uno (en todos o en aquellos que
cumplan cierta condición).
2. Trabajo con abstracción de datos desde la aplicación.
3. Usar hints en casos muy específicos (orden del join, uso de índices, etc.): los hints son sentencias específicas que se pueden agregar
motores en las sentencias SQL para forzar distintos aspectos del plan de ejecución. Cuando pongo un hintz le digo “esto hacelo como yo
te digo”. En este caso le dice que use determinado índice. Puede ser útil pero peligroso porque queda hardcodeado, queda escondido
dentro de una transacción dentro de la aplicación. Dentro de un tiempo dejo de tener sentido y nadie entiendo por qué no está
actuando como debería. En resumen, el hintz es forzar determinadas cuestiones en el plan de ejecución.
 Traerse los datos y trabajar mucho del procesamiento de los datos en la aplicación. Conviene trabajar lo más posible en la consulta
de SQL, y no tratarse datos y trabajarlo desde la aplicación ya que, de esa forma, no le damos tiempo al optimizador de mejorar el
desempeño. Ejemplo, si queremos tener el promedio del importe vendido de todos nuestros cliente. Podría tirárselo como un inner join
entre clientes, ventas e ítem ventas, y que genere todo en una sola consulta. Otra opción es manejarlo a través de un cursor. Que no lo
resuelva el motor. Lo que hace es traer todos los cliente, y hace una interacción dentro de la aplicación y cuando los trajo, por cada
cliente tira el promedio, va a la tabla ventas e ítem ventas y lo guarda. Si yo tengo 100 mil cliente, el motor lo que está viendo es que
tiro 100.001 consultas (la primera para traer los clientes) contra la base de datos pidiéndole el promedio de ese cliente. Esto puede
tardar minutos u horas en vez de milisegundos. A veces se hace porque queda más prolijo el código donde la aplicación maneja todo el
proceso, pero puede ser mucho menos performante que si trato de pensar todo eso como una consulta que resuelva la base de datos.
 Cuestiones que quien desarrolla la transacción puede estar haciéndolo muy bien desde un criterio de programación, pero desde el
desempeño de la base de datos es muy malo. Por lo cual, se deberá interactuar con el DBA y plantearle el problema ocasionado.

Manejo especial de Niveles de aislamiento en las transacciones.

Herramientas:
 Hay herramientas que le permiten al DBA poder monitorear el desempeño de todo lo que pasa en la base de datos. Tiempo que
tardan las consultas, etc.
1) Ir midiendo la performance, ver cómo se va desempeñando la base de datos. Muestra la actividad de la base de datos
2) Herramienta que es como un asistente que sirve para mejorar los aspectos de la base de datos.

Particiones: distribuir lógicamente una tabla. Particiones físicas de una tabla en distintos archivos en base a un criterio.

CLASE 01/06
Transacción: Conjunto de operaciones que forman una unidad lógica de trabajo. Unidad lógica que esta compuesta por un conjunto de
distintas operaciones, ya sea de actualización o escritura, consulta de determinados valores dentro de la base de datos, de elementos.
Para que este completa esa transacción, se deben completar todos los pasos.
Propiedades (ACID): es importante que se aseguren estas propiedades dentro de las bases de datos relacionales, donde almacenan sus
datos dentro de filas y columnas, en formato de tabla. En el caso de las bases de datos no relacionales, no respetan estas propiedades,
pero si a nivel de base de dato relacional es obligatorio que se respeten.
- Atomicidad (A): implica que la transacción se ejecuta en forma completa o no se ejecuta nada. O se ejecutan todas esas operaciones
que conforman esa transacción, o no se ejecuta nada. Si se ejecuta por la mitad, me dejaría la base de datos en un estado de
inconsistencia. Es importante que se asegure esta propiedad ya que, ante un fallo, se interrumpe la transacción, al momento de
restablecerse el sistema después del fallo, hay que volver para atrás todas las operaciones que se hubiesen ejecutado hasta el
momento. O se hace la transacción en forma completa o no se ejecuta nada.
- Consistencia (C): producto de la ejecución de una transacción, no genere inconsistencias dentro de la base de datos. La
responsabilidad de asegurar esta consistencia es, por un lado, del sistema de administración de base de datos en el punto en que debe
aplicar las restricciones que se hayan establecido a nivel del esquema de la base de datos y, por otro lado, de quien desarrolla la
transacción, que no genere, producto de la lógica de la transacción, inconsistencias dentro de la base de datos. Después de una nueva,
transacción, se garantice que siga existiendo esa consistencia.
- Aislamiento (I): tiene que ver con la concurrencia de la base de datos, con la ejecución de forma simultánea de muchas transacciones
al mismo tiempo. En este caso, esta propiedad trata de asegurar que, a pesar de esta ejecución simultanea que se da de las
transacciones, se mantenga la consistencia, es decir, que no se interfieran las transacciones entre si porque las transacciones pueden
estar escribiendo y leyendo sobre las mismas bases. Trata de que, con los protocolos de concurrencia que implemente el sistema de
administración de la base de datos, se pueda llegar a realizar una ejecución de estas transacciones como si estuviesen aisladas, del
efecto del resto de las transacciones que se estén ejecutando en el sistema. Responsabilidad del motor de ejecutarlos, a partir de estos
protocolos o reglas que se implementan a nivel del motor, y que nos permiten asegurar esta propiedad
- Durabilidad (D): una vez que una transacción termina con éxito, estos efectos que generó en la base de datos, es decir, los resultados
de todas esas modificaciones que realizo a nivel de la base de datos perduren en el tiempo, a pesar de que pueda existir algún tipo de
fallo. Esto es responsabilidad del subsistema de recuperación, propio del motor del sistema de administración de la base de datos.

Cuando inicia la transacción está en un estado ACTIVA, cuando termina de ejecutar la última operación de esa transacción está en un
estado PARCIALMENTE COMPROMETIDA. Luego, está COMPROMETIDA cuando efectivamente se impacta todos los resultados y las
operaciones a nivel de la base de datos y termino con éxito la transacción. El estado FALLIDA significa si hubo alguna interrupción por
algún tipo de fallo, ya sea del sistema operativo, a nivel de hardware, etc. (si es que la transacción no puede continuar con su operación
normal). Y, por último, estado ABORTADA donde, finalmente si no hay posibilidad de que esa transacción pueda continuar con su
ejecución normal, tiene que deshacerse los efectos para asegurar la atomicidad, deshacerse todos los efectos que hubiese provocado
en la base de datos, todos los cambios que hubiese realizado hasta ese momento, hasta el momento del fallo, se tienen que retroceder,
hacer un rollback (retroceder la transacción para deshacer los efectos de todas las operaciones que se hayan hecho hasta el momento).
Luego de hacerse todos esos efectos, se dice que está en un estado “abortada”, cuando no logra finalizar con éxito la transacción.

Acceso a los Datos

 Cuando necesitamos ejecutar alguna transacción que requiera acceder a determinados datos que están en los bloques del disco, lo
que necesita hacer, como cualquier operación dentro de un sistema informático, necesitamos llevarlo a la memoria principal como para
poder trabajarlo. En este caso, si el buffer de la base de datos estaba completo, tenemos que liberar espacio del buffer, lo que implica
un tipo de estrategia de sustitución de los bloques para persistirlos en el disco. En este caso, íbamos a necesitar liberar el buffer,
ejemplo estrategia de primero entrado, primero salido del bloque B1, o del menos recientemente utilizado. En ese caso, haría llevar el
bloque mas antiguo que hace mucho no se le realiza una modificación, se persiste en el disco, y recién ahí, liberando espacio, podemos
llevar a la memoria principal el bloque B2 sobre el cual tenemos que hacer algún tipo de consulta u operación.

Ejemplo: Lectura del bloque B2

Tipos de Almacenamiento

1) Volátil:
- Memoria principal / cache (ej. RAM)
- Acceso rápido
- No sobrevive a las caídas

2) No volátil:
- Memoria secundaria (ej. discos o cintas magnéticas)
- Acceso más lento
- Sobrevive a las caídas

3) Estable: no es un disco ni una tecnología en particular, sino más bien un concepto que se tiene que tratar de asegurar, sobre todo
cuando hablamos de recuperación de datos, que existe una cierta redundancia en el almacenamiento de determinados datos que nos
interesan, sobre todo resguardar.
- Se implementa a través de soluciones como los sistemas RAID o los Sistemas de Copia de Seguridad Remota.
- La información “nunca” se pierde

Clasificación de los Fallos

 Hay fallos que son más fácil de recuperar que otros. Un fallo a nivel de disco, que puede comprometer los datos ahí almacenados, es
más difícil de recuperar que, por ejemplo, un fallo a nivel de la memoria volátil de ese momento, que puede ser más fácilmente
recuperado.
a) Fallo en la transacción
- Error lógico
- Error del sistema

b) Fallo del sistema

- Error en el hardware
- Error en el software de la BD o del SO

c) Fallo de disco

Técnicas de Recuperación

Fallos con pérdida de memoria volátil: son fallos más sencillos de recuperar
- Técnicas basadas en el registro histórico
* Técnica de actualización diferida
* Técnica de actualización inmediata

- Paginación en la sombra o páginas en espejo

Fallos con pérdida de memoria no volátil: si hay un daño o una destrucción del disco, requiere recurrir adicionalmente a un back up de
la base de datos.
- Restauración del último volcado de la BD (backup de BD)
- Lectura del registro histórico y ejecución de operaciones rehacer necesarias.
1) FALLOS CON PÉRDIDA DE MEMORIA

Registro Histórico

 Ejemplo: registro de actualización de una transacción, donde existe un identificador de la transacción, un tipo de identificador de
datos a continuación (A), que es una dirección y un corrimiento dentro del bloque para ubicar ese campo o elemento de datos, luego
está el valor anterior que tenía dentro de la actualización y el valor posterior (anterior y posterior porque es mucho más fácil para
recuperar tenes esa información).
Además registros de esa transacción. Más información al momento de requerirse para una recuperación.

1) Técnica de Actualización Diferida:

Garantiza la atomicidad de las transacciones mediante el almacenamiento de las modificaciones en el registro histórico, pero
retardando la actualización en la BD hasta que la transacción se compromete parcialmente
 No se impactan en los bloques correspondientes de bases de datos todas estas modificaciones, sino que toda modificación se va a ir
registrando en el log. Dejamos todo el registro en este log, pero no llegamos a impactar ningún bloque de la base de datos, entonces, si
ocurre algún fallo, no tenemos que deshacer nada, lo que sí es necesario hacer es rehacer las transacciones que están impactadas para
asegurarme que esas modificaciones efectivamente se hayan impactado en la base de datos, a nivel de lo que es el disco. Si ocurrió un
fallo y yo encuentro en el registro histórico que la transacción está iniciada y comprometida, por las dudas voy a rehacer la transacción
de cero, para quedarme tranquila que esa información quedo almacenada en el disco. No tengo que deshacer, porque sé que, si
encuentro una transacción que esta iniciada y no comprometida, seguro que no hay nada que se haya impactado a nivel de la base de
datos, ni siquiera en un bloque de memoria principal.

 Esta técnica de actualización funciona primero a nivel de la memoria y después del disco. Puede estar impactada en el buffer de la
base de datos dentro de la memoria principal, pero eso nunca llega a almacenarse definitivamente en la base de datos
(almacenamiento secundario), entonces por ese motivo hay que rehacer.
Se dice que es una operación de rehacer es una operación idempotente porque tantas veces como la ejecute, siempre va a ser el
mismo resultado. Si, durante el mismo proceso de recuperación se llega a cortar por algún motivo (ocurre otro fallo o el mismo), tantas
veces como ejecute esta operación rehacer, el resultado no va a cambiar. Se da que es idempotente porque estoy plasmando ese
resultado a nivel de la base de datos fijando un determinado valor. No estoy realizando un cálculo, no hay lugar a equivocación.

En este ejemplo, vemos que el valor anterior no se guarda. Eso ocurre porque no lo necesito, porque si no llega a estar comprometida,
nunca modifique el valor anterior, sigo manteniéndolo a nivel de la base de datos. Si llega a estar comprometida, ahí se realiza la
modificación por el valor anterior y si voy a necesitar esos datos para hacer la operación de rehacer. Esta técnica nunca va a deshacer,
entonces nunca va a necesitar el valor anterior. Por ese motivo es que no se guarda.

2) Técnica de Actualización Inmediata:

Permite realizar escrituras en la BD mientras la transacción aún se encuentra en estado activo.
 En este caso, se va escribiendo en el buffer (primero se escribe en el buffer y luego se pasa al disco) y se va registrando
inmediatamente. Es decir, a medida que voy registrando las operaciones que se van ejecutando a nivel del log, voy impactando las
modificaciones en el buffer de la base de datos. Ejemplo, si estoy debitando 50 pesos de los 1000 de una cuenta, le sumamos 50 al
saldo de la cuenta b (se va impactando en el mismo momento) y se agrega al final que la transacción esta comprometida en el log.
En este caso si hace falta la operación de deshacer. Si ocurre algún fallo, cuando se recupera el sistema, tendríamos que deshacer la
operación que se ejecutó de la actualización del saldo de la cuenta inicial. Y volverlo al valor anterior (de 950 a 1000), para justamente
deshacer ese debito que se hizo. En este caso si se necesita la operación deshacer.

En este caso, si encontramos la situación de que en realidad la transacción figura como comprometida, es el mismo caso que
comentamos en el anterior. Tenemos que rehacer en caso de que esos datos no se hayan impactado definitivamente en los bloques de
base de datos del disco.

 Son las dos operaciones idempotentes, porque trabajan en la fijación de determinados valores y no sobre algún tipo de calculo
sobre los mismos.

Puntos de Revisión
Son registros del registro histórico que evitan tener que recorrerlo totalmente en cada recuperación y deshacer o rehacer transacciones
que ya se han reflejado en la BD. Es para ambas técnicas de recuperación.
Lo utilizan las técnicas de revisión que lo que hace es hacer mas eficiente la recuperación, porque cuando el sistema se recupera luego
de algún tipo de fallo, tiene que ir a buscar dentro del log, recorrerlo, y ver que operaciones tiene rehacer o deshacer, dependiendo del
tipo de técnica que se usa, si es inmediata o diferida. Tiene que ir ejecutando todo este tipo de operaciones, pero ¿hasta dónde tiene
que hacerlo? Quizás va a estar rehaciendo un montón de transacciones que ya estén impactadas en el disco, y no tiene sentido volver a
rehacerlas. Eso conlleva un costo, un tiempo de procesamiento, que va a afectar lógicamente la performance de este sistema. Para
hacer más eficiente esta operación se implementan estos check point o puntos de revisión, que implica que hasta tal punto, para atrás
no tengo que mirar nada, y empezar a ejecutar las operaciones luego de ese punto.
 Se hace un corte en un momento (un check point), un párate, y, al momento de revisar ese check point para asegurarme que lo que
está detrás está seguro y consistente, lo que se hace es un persistir de todos bloques que están a nivel de la memoria principal, tanto
del log de las transacciones (de este registro histórico que es mi herramienta de recuperación, lo primero que tengo que asegurar), se
lleva esos bloques de memoria principal donde está el log a memoria secundaria, es decir al disco. Posteriormente se llevan los bloques
de memoria principal, lo que es el buffer de la base de datos, los bloques de datos donde están los datos que estuve modificando,
también se persisten en el disco. Y, a continuación, se agregan un log en el disco que dice que se ejecuto en ese momento un check
point. Con esa información, me voy a asegurar que todo lo que esta para atrás esta impactado en almacenamiento secundario. Todas
las modificaciones que fueron realizando hasta ese momento, estoy segura de que están en el disco.

Cuando se recupera esa transacción producto de esa falla, se empieza a ver que operaciones se van a rehacer o deshacer hasta el punto
de revisión.

EJEMPLO CON TECNICA DE ACTUALIZACION INMEDIATA:

- La T1 la puedo ignorar porque ya esta revisada (estoy segura de que esas modificaciones ya están en el disco, no tengo por que
rehacer esa transacción). Esta iniciada y comprometida pero no la tengo que rehacer porque esta antes del punto de revisión
- La T2 y T4 encuentro que esta iniciada y comprometida, pero se comprometió entre el punto de revisión y la falla, entonces debería
rehacerla, porque no estoy segura. Puede llegar a estar en el disco, es probable, pero para asegurarme la tendría que rehacer.
- La T3 y T5, donde una inicia antes del punto de revisión y una después, ninguna se llega a comprometer, ninguna llega a finalizar hasta
el momento del fallo, entonces ahí debo deshacer, tengo que hacer un rollback de esas transacciones. Implicará impactar el valor
anterior que tengo almacenado en el registro histórico.

EJEMPLO CON TECNICA DE ACTUALIZACION DIFERIDA:

 Es eficiente en el caso de la técnica de recuperación diferida porque sabes que las transacciones que ya están comprometidas, antes
de ese punto, no tenes que rehacerlas. Entonces agiliza mucho más la carga de trabajo en la recuperación.
- La T1 no hago nada
- T2 y T4 las debo rehacer
- T3 y T5 las podría ignorar. Al no estar registradas, las ignoras, porque nunca se llegaron a impactar ni siquiera en el buffer de la
memoria principal.

El registro histórico, la BD y el almacenamiento

Primero se debe guardar el registro histórico antes que los datos, porque si no no tengo forma de recuperar. Es clave resguardar el
registro histórico hablando de almacenamiento estable. Aplica directamente al registro histórico. Al ser la herramienta fundamental
para una recuperación, tiene que estar en almacenamiento estable. Tengo que tener un seguro o redundancia de que esa información
la tengo de alguna manera como para poder recuperarme ante cualquier fallo que pueda ocurrir en la base de datos.
 Siempre lo primero que tengo que guardar, antes que los bloques de la base de datos son los bloques de buffer del registro histórico
en almacenamiento secundario. Y deseable y recomendable en almacenamiento estable.

Backups de Base de Datos

 Se pueden utilizar varios tipos de back ups a la vez dentro de una base de datos.

Full Backups
- Incluyen toda la base de datos, partes del registro histórico, el esquema de base de datos, y la estructura de archivos.
- Sirve como base para realizar otro tipo de backups

Diferenciales
- Permiten respaldar los datos modificados desde el último Backup Full.
- Requiere que haya sido realizado un Full Backup.

Incremental
- Realiza un respaldo de todos los datos modificados desde el último respaldo, es decir, si tuviese un back up full y un incremental
diario, para recuperar los datos a un día especifico, tendré que restaurar un back up full más los incrementales de cada uno de los días.
- Toma menos tiempo de respaldo que un Diferencial.
- Toma más tiempo de recuperación y es más complejo de manejar que un Diferencial.

Esquema de recuperación ARIES

 Se utiliza generalmente en los motores de bases de datos que conocemos. Algoritmo de recuperación avanzado que intenta reducir
el tiempo de recuperación. Se basa en la técnica de recuperación inmediata más el uso de la funcionalidad de check point.

Conceptos fundamentales:
- Cada registro del registro histórico tiene un número de secuencia del registro histórico (NSR). También utiliza estos números en las
páginas de la BD (NSRPágina) para identificar operaciones realizadas sobre ellas. El log lleva una secuencia con un número.
- Tabla de páginas desfasadas o sucias (páginas actualizadas en memoria, pero no en disco), para minimizar las operaciones rehacer
innecesarias durante la recuperación. Son los bloques que, al momento de realizar ese punto de comprobación, estaban en la memoria,
pero no habían sido impactados en disco
- Esquema de revisión difusa. Lo que hace es tratar de hacer más eficiente la ejecución de este check point, tratando de no frenar las
operaciones en forma completa cuando hace este punto de comprobación, porque lógicamente, al momento de hacer este punto de
comprobación, hay un párate a nivel de la base de datos porque frena toda la ejecución y empieza a hacer este volcado y persistencia
de los datos de memoria al disco.

Procedimiento de recuperación en 3 fases:

- Fase de Análisis: En este paso se determina las transacciones que hay que deshacer, las páginas que estaban desfasadas al momento
de la caída y el NSR en el que debería comenzar el paso rehacer. Lo que hace es, en un proceso de recuperación, empezar a revisar el
log, ir de atrás para adelante, con esta fase de análisis. Empieza a revisar desde el ultimo check point que haya encontrado todas las
transacciones, fijándose cuales tiene que deshacer y cuales tiene que rehacer. Se arma una lista.
- Fase Rehacer: Este paso comienza en una posición determinada durante el análisis y realiza las operaciones rehacer para llevar a la
asiento al estado anterior a la caída. Desde atrás para adelante, va a empezar a rehacer todas las transacciones que encuentre iniciadas
y comprometidas.
- Fase Deshacer: se deshacen todas las transacciones de la lista-deshacer. Opera al revés, desde lo mas nuevo a lo mas viejo. Empieza a
deshacer, desde lo mas nuevo a lo mas viejo, para asegurar la consistencia, en todas las transacciones que encuentra iniciadas y no
comprometidas.

Cuando hace un check point va a listar las transacciones activas hasta ese momento y, por otro lado, la tabla de las paginas desfasadas,
que son los bloques sucios, que estaban a nivel de la memoria y no llegaron a almacenarse en el disco.

2) FALLOS CON PÉRDIDA DE MEMORIA NO VOLÁTIL

 Por ejemplo, un daño en el disco, una rotura en el disco, que implique un poco más que la recuperación a partir del log, lo que vamos
a necesitar es:
- BACK UP (visto anteriormente)
- Log de transacciones o registro histórico: no es que solamente me baso en el back up, sino que realizo una estrategia combinada, de
tomar lo que tengo en el back up, que lógicamente no lo tengo en el log, porque estos log son archivos que tienen un esquema de
rotación, porque sino son archivos que pesan un montón y de un volumen muy grande. Entonces, tengo que tener bien definida esta
estrategia como para poder recuperar la información. En resumen, voy a ir a recuperar el ultimo back up, el más reciente que tenga, y
desde el momento del back up hasta el momento del fallo, tengo que basarme en lo que tengo en el log de transacciones o en el
registro histórico. De esa manera, en forma conjunta, voy a poder recuperar la información hasta lo último que tenga.
 En lo que es pérdida de memoria no volátil, le adiciono, a lo que es las técnicas basadas en el log, el back up, que es fundamental
para incorporar la información y los cambios mas viejos.

Ejercicio
(a) No se hace nada porque no esta comiteada.
(b) La T0 hay que rehacerla y la T1 no porque no está comiteada
(c) Hay que rehacer ambas

(a) Se deshace la T0 que implica llevar a B al valor de 2000 y a A al valor de 1000

(b) Se rehace la T0 y se deshace la T1
(c) Se rehacen las dos (están todas comiteadas o comprometidas)

CONTROL DE CONCURRENCIA

Ejecución Concurrente
 Cuando hablamos de las propiedades de las transacciones, dijimos que se tenía que asegurar el aislamiento de estas transacciones,
en el sentido de que teníamos que tratar de asegurar que se ejecuten en forma coherente estas transacciones.
- Aspectos positivos
* Mayor Productividad: hay que tratar se asegurar que se ejecuten en forma coherente estas transacciones, simultáneamente con
otras, para lograr mayor productividad. Si estuviésemos ejecutando una transacción atrás de la otra, sin ningún tipo de concurrencia, y
sin hacerlo de manera simultánea, sería muy poco eficiente. Estaríamos ejecutando, en el mismo momento, una única transacción, en
forma secuencial, una atrás de la otra. Así si nos aseguramos de que no hay ningún tipo de inconsistencia, porque ninguna transacción
podría interferir con otra, pero es poco eficiente y la productividad es muy baja. Entonces, un aspecto positivo de poder ejecutar en
forma concurrente y simultanea es mayor productividad.
* Mejor utilización de los recursos del sistema: es así porque, lógicamente, cuando una transacción está ejecutando algún tipo de
escritura del buffer al disco, otra puede estar utilizando el tiempo de procesamiento a nivel del procesador de ese servidor, etc. Pueden
estar usando distintos recursos dentro de un mismo sistema informático, por lo cual se hace un mayor aprovechamiento de esos
recursos
* Tiempo de espera reducido: si tengo una transacción muy corta que quiere ejecutarse y hay otra muy larga que llega varios minutos
ejecutándose, ahí se habilita que una transacción muy corta que tiene que hacer una modificación puntual en la base de datos, pueda
rápidamente ejecutarse y comprometerse, y no tenes que esperar toda la ejecución de otra transacción más larga.

- Aspectos negativos
* Mayor probabilidad de inconsistencias: esto es producto de que pueden estar operando sobre los mismos datos y algunas
transacciones pueden estar viendo o consultando determinados valores que actualizo otra base de datos que, al momento que los esta
consultando, no debiera podido acceder. Se van a tratar de limitar y reglamentar con protocolos.

Conceptos Generales
- Planificaciones: secuencias de ejecución de las instrucciones componentes de las transacciones. El orden o la secuencia de ejecución.

En este caso hay una transacción que se ejecuta en forma completa, y atrás viene la otra, sin generar ningún tipo de inconsistencia.
 Lo que se va a atender a hacer, si habilitamos a que exista concurrencia en la base de datos, llegar a planificaciones que no sean
secuenciales. Pero, se va a tener que tener especial cuidado de que, gracias a protocolos, siempre se llegue a planificaciones que sean
equivalente (el resultado final sea igual) a que si se hubiesen ejecutado una detrás de la otra. Tengo que llegar a planificaciones no
secuenciales pero que cuyo resultado final sea igual a una planificación secuencial (los valores de A y de B, que son los elementos de
datos que se están modificando, al final de todo sean los mismos, ya sea que se hubiese ejecutado en forma secuencial que si no lo
hubiesen hecho).

No equivalente: un caso en el cual no se cumple. El error que se esta cometiendo es que no se escribió A en T1 antes de que la T2 la lea.
En este caso, el problema es que se pierde la actualización de A que hizo T1 porque nunca se leyó en el caso de T2. De hecho, se
sobrescribe el valor de A, T1 lo sobrescribe más adelante. Este tipo de problemáticas no pueden ocurrir, no podemos permitir que, si T1
inicia antes que T2, nunca podemos permitir que T2 no lea, sobre todo cuando trabajan sobre el mismo elemento de datos, la T1 tiene
que escribirse antes que la T2 lo lea, sobre todo para asegurar la consistencia de la base de datos (ACTUALIZACION PERDIDA).

CLASE 04/06
Ejecución concurrente: esas transacciones puedan realizarse de manera simultánea, porque de alguna manera, si no lográramos que las
transacciones se pudieran realizar todas juntas, estaríamos perdiendo productividad, haríamos un peor uso de esos recursos de datos, y
haría que aumentar entonces los tiempos de espera que tienen los usuarios al trabajar con estas bases de datos. Esa posibilidad de que
se estén ejecutando varias transacciones de manera concurrente, no tenes que esperar que termine una para empezar otra, genera
mayor probabilidad de generar inconsistencias.

Planificaciones
 Detrás del control de la concurrencia, hay un concepto de planificaciones, que quiere decir cómo se realiza una transacción. Se habla
de planes cuando se está refiriendo al orden en que se realizan las instrucciones de las distintas transacciones.
La planificación son varias transacciones ejecutadas en una determinada secuencia.

1) Planificaciones secuenciales: es secuencial porque se realizan todas las instrucciones de la T1 y a continuación todas las instrucciones
de la T2. No hay concurrencia en una planificación secuencial.
2) Planificaciones no secuenciales:
- Equivalentes: son planificaciones no secuenciales, porque queremos lograr concurrencia, pero equivalentes a una planificación
secuenciales. Se llaman planificaciones secuencializables. Equivalente quiere decir que el resultado es el mismo que si hubiese tenido
una planificación secuencial.
En el ejemplo, estamos teniendo las mismas instrucciones que tenemos en la secuencial, pero en el eje del tiempo, se intercalan
instrucciones de la T2 con instrucciones de la T1, y viceversa. Es equivalente porque el dato A, que se trata en la T1 y el dato B que se
trata en la T1 que también se trata en la T2, cuando terminan las dos transacciones, tiene que ser exactamente el mismo valor.
 Para ser equivalente y llamarse secuencializables tiene que tener los mismos resultados que si la hubiese hecho secuencial.

- No equivalentes: cuando lee los valores que todavía no están escritos en la base de datos, se pierden los valores. No tiene el mismo
resultado final que hacerlo secuencial. Generaría inconsistencias en la base de datos por el hecho de haber trabajado de manera
concurrente.

Problemas de la concurrencia
1) Actualización perdida: Ocurre cuando dos transacciones que intentan modificar un elemento de datos, ambas leen el valor antiguo
del elemento, una de ellas (T1) actualiza el dato, pero esa actualización se pierde dado que la otra transacción (T2) sobrescribe ese valor
sin siquiera leerlo. Se da cuando tengo una planificación NO SECUENCIAL pero que sería NO EQUIVALENTE, no secuencializables.

2) Dependencia no confirmada (lectura sucia): Ocurre cuando una transacción T1 lee o actualiza un elemento de datos que ha sido
actualizado por otra transacción T2 que aún no ha sido confirmada. Por lo tanto, existe la posibilidad de que se deshaga T2 y T1 haya
visto un valor que ya no existe. T1 opera sobre una suposición falsa
 Tengo una transacción que escribe un dato pero que todavía no fue confirmada. En un momento del tiempo x se puede deshacer.
Me va a quedar inconsistente porque esta transacción actuó como si ese dato sea válido, pero cuando desaparece porque se deshacer
esa transacción, quedo de manera inconsistente esa base de datos. Leer datos que aún no haya estado confirmados más allá de que si
los haya guardado en ese momento en la base de datos.
3) Análisis inconsistente: Se produce cuando una transacción T1, producto de haber leído un dato actualizado por otra transacción T2
ya confirmada, incurre en un análisis inconsistente.
 Esto se da cuando una transacción está haciendo una lectura de múltiples datos, para generar algún calculo (en este caso, sumatoria
de distintos datos de la base de datos que involucran un dato A, B y C) y, en el medio, hay otra transacción que es la que hace que uno
de esos datos, que todavía no había leído, le esté restando, pero que a uno de los que había leído, le esté sumando, porque hace un
traspaso entre dos datos. Ahora, la suma total va a ser inconsistente, porque A lo había leído y C no lo había leído, entonces la suma de
todo va a dar distinto a lo que tendría que dar. Antes o después de que se ejecute la transacción.

4) Lectura no repetible: Se produce cuando una transacción T vuelve a leer un elemento de datos que ya había leído previamente pero
que, luego fue modificado por otra transacción. Así, la transacción T estará leyendo dos valores distintos para el mismo elemento de
datos.
 Si de alguna manera leo un dato dentro de una transacción, más tarde tengo que volver a leer el mismo dato pero que ya tiene un
valor distinto porque en el medio hubo una transacción que actualizo ese dato. Esta lectura no repetible también es una inconsistencia
porque tengo dos valores del mismo dato en dos momentos del tiempo, que son distintos, y me podría eso generar algún nivel de
inconsistencia.

5) Lectura fantasma: Se produce cuando una transacción T vuelve a ejecutar una consulta que extrae una cantidad de tuplas de una
relación, que ya había ejecutado anteriormente, pero que ahora devuelve una tupla adicional (fantasma), que fuera insertada por otra
transacción.
 Es cuando, hay un dato que no existía, y que a partir de esto existe porque existe alguna inserción de algún dato. No es que se lee,
porque es una inserción que se escribe.

Secuencialidad
 Como podemos, a través de algunas reglas, asegurar esa secuencialidad. Como podemos hacer que las planificaciones sean
secuencializables. Se quiere que existan algunas reglas para lograrlo, que tengan que seguir las transacciones, que yo no las pueda
ejecutar de cualquier manera. Solo las voy a poder ejecutar siguiendo algunas reglas, y si las sigo, me va a permitir que, si bien sean
concurrentes, sean secuencializables. Son las que después usan los protocolos para asegurar tener transacciones secuencializables.

1) EN CUANTO A CONFLICTOS
Una planificación P es secuenciable en cuanto a conflictos si es equivalente en cuanto a conflictos a una planificación secuencial
Si una planificación P se puede transformar en otra P’ por medio de una serie de intercambios de instrucciones no conflictivas.
 Si una planificación, que llama P, se va a poder transformar en otra planificación (P’) con una serie de intercambios de instrucciones
que sean no conflictivas, quiere decir que esta planificación P’ podría ser secuencializable, es decir, equivalente a una secuencial, si
sigue estos intercambios de sus instrucciones que sean no conflictivas. No conflictivas quiere decir que, yo las puedo intercambiar de
lugar en el tiempo si no trabajan con el mismo elemento de datos. Si en el fondo, son el mismo dato (una habla del A y otra habla del B)
intercámbialo todo lo que quieras, no es conflictiva, no me esta afectando que sea equivalente a una secuencial.

Si las instrucciones (de las distintas transacciones) a intercalar:

- No operan sobre el mismo elemento de datos
- Operan sobre el mismo elemento de datos, pero ninguna de ellas constituye una operación escribir.

 SI TIENE CONFLICTOS NO ES SECUENCIALIZABLE

 SI NO TIENE CONFLICTOS, ENTONCES VA A PODER SER SECUENCIALIZABLE

Ejemplos

Imagen 1: planificación secuencial

Imagen 2: planificación secuenciable en cuanto a conflictos: porque cuando escribe sigue la misma lógica, primero hace lo de la T1 y
luego lo de la T2. Si leyera no me preocupa, pero si escribiera esta siguiendo la misma lógica.
Imagen 3: planificación no secuenciable en cuanto a conflictos: esta trayendo conflictos

 Aplicaciones que están trabajando sobre datos. Podrían o no ser distintos usuarios. Sesiones de aplicaciones que están ejecutando
transacciones contra la base de datos (transacción: conjunto de operaciones que son una unidad lógica). Cuando tira ejecutar esa
transacción, que por lo general esta dentro de una aplicación, el motor entiende que se está ejecutando una transacción contra la base
de datos. Cuando el otro inicia otra, dice “ahora inicio esta otra” (a nivel de cuando detecta que hay transacciones queriendo trabajar
sobre la base de datos). Para detectar si existen conflictos o no lo hace a través de los protocolos (lo que estamos viendo ahora es en
donde nos vamos a centrar que van a fundamentar que se van a usar distintos protocolos).
EL MOTOR NO RECONOCE POR TENER UNA SESION ABIERTA, SINO POR ESTAR EJECUTANDO UNA TRANSACCION EN LA BASE DE DATOS.

2) EN CUANTO A VISTAS
Una planificación P es secuenciable en cuanto a vistas si es equivalente en cuanto a vistas a una planificación secuencial
 Secuencialidad que mido en cuanto a vistas. Va a ser secuencializable en cuanto a vistas si sigue otras condiciones. Reglas que
implican que de repente puede haber planificaciones secuencializables en cuanto a vistas que a veces no sean secuencializables en
cuanto a conflictos. Quiere decir que esta secuencialidad, si bien es un poco más compleja, me permitiría que algunas planificaciones
que entrarían en conflicto cuando hago las reglas de la planificación que sea equivalentes en cuanto a conflictos, en realidad si serian
secuencializables en cuanto a vistas.

3 condiciones:
- Si la transacción Ti lee el valor inicial de Q en P, entonces debe hacerlo también en P’: si tengo una transacción Ti, que lee un valor
inicial de un dato Q en la planificación original (secuencial), entonces también tendría que leer el valor inicial de la planificación
secuencializable en cuanto a vistas.
- Si la transacción Ti lee(Q) en P, y el valor lo ha producido Tj , entonces debe hacerlo también en P’: si la transacción Ti lee cualquier
dato (Q) en P, y el valor lo produjo la transacción Tj, entonces también tendría que hacerlo en la secuencializable.
- La transacción que realice la última operación escribir(Q) en P, debe hacerlo también en P’: la transacción que realice la última
operación de escribir en la planificación secuencial también tendría que hacerlo en la secuencializable.

HAY PLANIFICACION EN CUANTO A CONFLICTO LO VA A SER EN CUANTO A VISTAS, PERO HAY PLANIFICACIONES QUE SON
SECUENCIALIZABLES EN CUANTO A VISTAS, PERO NO EN CUANTO A CONFLICTOS.
Recuperabilidad

1) Planificación no recuperable
Cuando se alguna manera no puede abortarse, se pierde lo que se hizo de alguna forma. No es deseable. La idea es que de alguna
forma pueda generar que sea consistente. Ejemplo, la T2 lee un dato de la T1. T2 ya terminó, esta comprometida. Uso el dato y ya lo
aplico. T1 falla y no logra comprometerse. Entonces, la idea si esta fallo y no se pudo comprometer, es que de alguna manera vuelva
para atrás, porque esta mal. Esto es no recuperable. Hay que evitarlo para que nadie lea una transacción que no esta confirmada. No
puedo dejar leer datos que haya escrito otra transacción que no este confirmada.

2) Planificación con retroceso en cascada

T2 lee lo que escribió T1. T3 lee el dato escrito por T2. Ahora, si T1 falla y no logra comprometerse, de alguna manera debería
retroceder T2 y T3. Lo puedo hacer porque no las había comprometido, se pueden abortar. Pero, cuando falla uno estar deshaciendo
transacciones que estaban avanzadas es lo que se llama un retroceso en cascada. Eso de alguna manera es lo que se llama una
planificación que permite retrocesos en cascada (una falla puede ser que hay un error en la lógica de la aplicación y que termina
inesperadamente la aplicación cuando estaba ejecutando esa transacción, otro ejemplo puede ser por un corte eléctrico, o falla en el
equipo, etc.)

- Si tenemos transacciones y tenemos un fallo, nos dice que, si Tj lee elementos de datos que escribió Ti, entonces, para que sea
recuperable, Ti debe comprometerse antes que Tj. Esto es si quiero que sea recuperable
- Si Tj lee elementos que escribió Ti, Ti tiene que comprometerse antes que Tj lea los elementos de datos. Quiere decir que, si yo quiero
que no haya planificaciones que tengan recuperación en cascada, lo que tengo que hacer es que esté comprometida la transacción que
escribió el dato antes de que lea, porque yo cuando leo algo que otro comprometió, me aseguro de que no va a volver para atrás. Esto
si quiero que sea sin cascada. Si es sin cascada, es recuperable.

Protocolos
Como aseguran los motores de bases de datos que no se generen inconsistencias por el uso de transacciones de manera concurrente.
En el fondo se basa en los conceptos previos.
- Bloqueos: tipo de esquema que usan los protocolos. Los bloqueos, de alguna manera, lo que hacen es determinados recursos, a los
cuales pueden acceder las transacciones, les va a poner una marca. A esa marca, que podría ser un tipo de marca una C, se llama
bloqueo porque a través de una lógica de reglas de compatibilidad, deja o no deja acceder a otra transacción a ese dato en la medida
que tenga una marca, que vamos a llamar bloque. En el fondo, es una marca que pone cada transacción a los recursos de datos para
bloquear o no bloquear que otra transacción también acceda a ese tipo de datos. Para eso va a existir, en el motor de la base de datos,
un componente que es el gestor de bloqueos. Este gestor lo que hace es conceder bloqueos a las transacciones y después, según si
existe compatibilidad o no, a otra transacción que quiere usar ese mismo dato, ve si se lo concede o no se lo concede. Esta permitiendo
o no el uso de los recursos y yendo a este concepto de si deja o no deja que usar la operación que es conflictiva con otra.
Tipos de bloqueo:
- Compartido (C): permite lectura.
- Exclusivo (X): permite lectura y escritura.
 Cuando una transacción planteo un bloqueo de tipo compartido, el gestor le va a permitir a otra transacción también pedir un
bloqueo de tipo compartido, pero no le va a permitir cuando necesite bloqueo de tipo exclusivo. Es decir, si tengo una transacción T1,
que necesitaba leer un dato y pidió un bloqueo compartido, y viene otra transacción que necesita leer un dato lo va a dejar, ahora viene
una transacción T2, que lo que necesita es escribir un dato, y quiere pedir un bloqueo exclusivo, lo va a rechazar porque ya tiene un
bloqueo compartido por esta transacción T1. Recién cuando esa transacción termine y libere ese bloqueo, ahí si le va a dejar entrar a la
otra, porque no va a tener ninguna, y va a poder pedir un exclusivo. Si pide un exclusivo, ya cualquier otra transacción no lo va a poder
usar, ni compartido ni exclusivo. Lo único que se puede compartir son dos compartidos, todo el resto me lo niega, mientras que lo tenga
pedido uno. Tiene que esperar a que lo libere para que otro lo pueda pedir y ahí si usarlo. Todo uso que haga una transacción lo va a
poder hacer posterior a haber pedido el bloqueo, si no pasa por este no puede hacer uso del dato.

Protocolo de dos fases: un protocolo que usa bloqueos. La forma en que lo va a usar es de la siguiente manera: en una fase de
crecimiento y una fase de decrecimiento. Lo va a obligar a trabajar este protocolo a las transacciones es que tiene una fase en que
puede ir tomando los bloqueos, es decir, que puede ser incremental, no tiene que pedir todos los bloqueos. Una transacción va a usar
el dato A, el dato B y el dato C. Puede pedir primero el dato A, puede pedir un bloqueo del dato B y mas adelante un bloqueo del dato
C. Eso es durante la fase de crecimiento que va pidiendo bloqueos. Ahora, una vez que soltó un bloqueo (no tiene que soltarlos todos
juntos) no puede volver a tomar un nuevo bloqueo.

Características de este bloqueo:

- Secuencialidad en cuanto a conflictos
- Probabilidad de Interbloqueos
- Probabilidad de retroceso en cascada

Hay dos variaciones que se hacen de este protocolo según yo quiera resolver mas o menos de los problemas que habíamos visto al
inicio de las inconsistencias. Todos resuelven el de la actualización perdida pero no necesariamente resuelven los otros.
Si yo voy al Riguroso o al Estricto, evitan el retroceso en cascada.
- Estricto: Una transacción debe conservar todos los bloqueos exclusivos hasta que se comprometa. Si bien sigue conservando estas
fases de crecimiento y decrecimiento, lo que haces es que las transacciones, los bloqueos exclusivos los tiene que conservar hasta el
final. No es que va bajando escalonadamente. Si fui tomando bloqueos, cuando llegue al punto de bloqueo, los exclusivos los tengo que
conservar hasta el final hasta que se compromete la transacción, no los puedo ir dejando uno si otro no. Esto me asegura que, cuando
yo un bloqueo exclusivo no lo suelto, significa que nadie va a poder usar ese dato hasta que yo no lo comprometa.
- Riguroso: Una transacción debe conservar todos los bloqueos hasta que se comprometa . Tiene que conservar todos hasta el final,
ya sean exclusivos o compartidos.

Protocolo de bloqueo de dos fases con intención de bloqueo

Concepto de granularidad: en los bloqueos es con qué nivel de detalle de recursos de la base de datos estoy haciendo el bloqueo.
Podría hacer, con un mínimo nivel de granularidad, bloquear toda la base de datos. Si la marca es a nivel de la base de datos, lo que
lograría o sería igual a tenerlo a nivel secuencial (porque si una transacción me bloquea esta, ninguna otra transacción puede ejecutarse
al mismo tiempo). Lo que estoy viendo con la granularidad es ver a qué nivel bloqueo.

Concepto de intenciones de bloqueo: trabajar con bloqueos, pero usando también este criterio de que hay distintos niveles de
granularidad. Toda esta gestión de los bloqueos no es gratis, cuidar la consistencia de la base de datos no me sale gratis, a nivel de
complejidad y de tiempo, porque estoy gastando recursos y tiempo en guardar datos y controlar datos antes de poder actuar (leer o
escribir) sobre los datos. Cuanto mayor nivel de granularidad, mas detalle tengo que estar chequeando a nivel de los datos. Si solo
guardara a nivel de filas, por decir algo, y quisiera hacer un bloqueo a nivel de la base de datos, tendría que recorrer todos los bloqueos
a nivel de filas para ver si puedo o no puedo hacerlo. Lo que hace es guardar intenciones de bloqueo, que significa que antes de
bloquear algo de nivel inferior, hago intenciones de bloqueo a nivel superior. Si quisiera hacer un bloqueo exclusivo de un registro, se
haría una intención de bloqueo de base de datos, de zona, de archivo y un bloqueo exclusivo de registro. Con este criterio se me amplia
la tabla de compatibilidad respecto de intenciones de bloqueo con bloqueos propiamente dichos.

Esquemas multiversión

Manejar el control de concurrencia no por bloqueos, sino por lo que se llama marcas temporales. El otro esta mas orientado a ordenar
la secuencia de operaciones para que cumplan el criterio de ser secuencializables en cuanto a conflictos, acá de alguna manera le esta
agregando un tema de tiempo, de secuencialidad, para poder lograr mas una secuencialidad en cuando a vista
 Se agrega un concepto que son las marcas temporales

Marcas temporales: poder tener, cuando inicia una transacción (cada transacción tiene una marca temporal) se le pone una marca. Lo
va aumentando con cada transacción que inicia. Sirve para asegurarse y saber si una transacción empezó antes que otra. Esas marcas
las vamos a usar para tener n versiones del mismo dato. Son esquemas multiversión. La marca temporal es de la transacción, que le dio
un numero por el contador lógico.
 Por cada versión siempre tengo: un numero de escritura que es el que lo creó, y un numero de lectura que es el último que lo leyó.

Protocolos que hacen uso de las marcas temporales para asegurar planificaciones secuencializables
1) Ordenación por marcas temporales multiversión: lo que va a hacer es ordenar las operaciones de lectura y escritura con el siguiente
criterio: no necesita poner ningún bloqueo a nivel de la lectura porque cuando quiere leer un dato, lo que de alguna manera va a hacer
es que, se va a mostrar el contenido de la versión mas reciente respecto a la transacción que lo esta queriendo escribir.

Sea Qk una versión donde la marca temporal de la escritura de este valor, de esta versión de Q, es menor que la marca temporal de Ti.
Es decir, tengo una transacción Ti que se inicio con posterioridad a que se haya escrito este valor de Q. Me dice que esta transacción (Ti)
que inicio después de que se había escrito este valor de Q, esta queriendo leer un valor de Q. No tiene que bloquear nada. Le va a
mostrar el contenido de la versión mas reciente.
- Para leer es fácil, muestra la última.
- Para escribir, lo que tiene que ver es que pasó con las versiones anteriores. Va a mirar si esta versión es anterior a lo que alguien ya
leyó, entonces va a retroceder la transacción, porque no tiene forma de hacerlo consistente. De alguna manera, alguien posterior ya
leyó un dato que ya habían escrito, por lo cual hay posibilidades de generar inconsistencias, ya que quiere decir que hubo otra
transacción que pudo haber leído un dato que él tiene que usar para escribirlo, entonces se estaría pisando ese valor. No le queda otra
que retroceder (se llama protocolo optimista. Se juega de que alguna manera lo va a poder usar. No bloquea, deja que lo usen. Si se
jugó y en realidad se da cuenta que esta mal, lo hace retroceder, porque no bloquea, por eso se llama que es optimista). Siguiendo
estos criterios lo que va a hacer es sobrescribir el contenido de Q o escribir una nueva versión de Q.
 Con estas reglas ve si tiene que escribir un nuevo valor, sobre escribir un valor, o si tiene que retroceder directamente la transacción.

Este protocolo (no se suele usar mucho):

- Asegura la secuencialidad en cuanto a vistas
- Las peticiones de lectura no fallan y no tienen que esperar, porque siempre puede encontrar el valor que le correspondería.
- Las lecturas requieren actualizar el campo mt-L(Q) (acceso extra al disco).
- Los conflictos se resuelven por medio de retrocesos.
- Probabilidades de planificaciones no recuperables y retrocesos en cascada.

2) Bloqueo de dos fases multiversión: es una combinación entre el uso de bloqueos para algunas cosas y el uso de multiversión para
otras. Permite bases de datos con mucha concurrencia, que no necesitaba siempre estar bloqueando, porque para las transacciones de
lectura no necesita bloquear nunca porque usa el esquema de las marcas temporales.

Usa como marca temporal un valor de un contador, que se va aumentando cuando se van generando las transacciones. Pero no tiene
dos marcas temporales, solo tiene una que es por valor. Vamos a tener n versiones de cada dato, asociadas con esas marcas
temporales, y lo que va a hacer es:
- si ejecuto una operación de leer, va a mostrar el contenido mas reciente que tenga que ver, donde esta marca temporal sea menor a
la marca temporal de la transacción que esta requiriendo en esa lectura
- en el caso de actualización, usa el protocolo de dos fases riguroso, quiere decir que en primera instancia ejecuta la operación de leer,
con un bloqueo compartido, sobre el dato Q, que va a ser el mas reciente y, a la hora de escribir, pone un recurso exclusivo que lo tiene
hasta el final sobre una nueva versión de Q. Crea una nueva versión de este dato cuando va a escribir, con un bloqueo exclusivo que va
a mantener hasta el final (por eso hablamos de riguroso)

Este protocolo:
- Asegura secuencialidad.
- Las transacciones de sólo lectura no tienen que esperar, porque usa las distintas versiones y no hay bloqueos.
- Planificación recuperables y sin cascada.
- Probabilidad de Interbloqueos (igual que el resto)

Niveles de Aislamiento en SQL

Se puede ajustar el nivel de aislamiento entre las transacciones y determinar para una transacción el grado de aceptación de datos
inconsistentes. A mayor grado de aislamiento, mayor precisión, pero a costa de menor concurrencia.
 Niveles de aislamiento de las transacciones. Uno, no necesariamente, cuando este trabajando las transacciones puede plantearse el
mayor nivel de aislamiento (Concepto de aislamiento: con esa propiedad se pretende que una transacción llegue a los mismos
resultados que si se estuviera ejecutando de manera aislada, sin que existiera ninguna otra transacción en el mismo momento).
Cuanto mayor nivel de aislamiento se plantea en una base de datos, menor nivel de disponibilidad está ofreciendo esa base de datos.
De alguna manera me permite poder configurar y decir que no se quiere ir al mayor nivel de aislamiento porque, si bien es lo que me
aseguraría consistencia total, algo totalmente aislado como si fuera una planificación totalmente secuencial, eso me haría que tengo
una base de datos con menor productividad, por lo cual voy a ir a un nivel intermedio. La mayoría de las bases de datos por default
están al nivel de lectura comprometida.

Uno puede, a nivel de la base de datos y a nivel de la transacción, puede configurar que tenga mayor nivel de aislamiento. Si no lo
configura, por default, esta en nivel de lectura comprometida.

Interbloqueos
Existe un interbloqueo cuando existe un conjunto de transacciones, tal que toda transacción del conjunto está esperando un elemento
de datos bloqueado por otra transacción del conjunto.
 Es un efecto no deseado por usar bloqueos. La mayoría de las bases de datos usan el concepto de bloqueos para solucionar el
problema de las inconsistencias en la concurrencia. Pero estos bloqueos pueden traer un efecto no deseado que es el interbloqueo.

T1 y T2 necesitan bloqueos del dato B y del dato A. Tenemos T1 que primero bloquea el B, pide un bloqueo del B y, después, va a pedir
el dato A. Cuando va a pedir el dato A, se da cuenta que hay una transacción T2 que previo a él pidió el dato A. Entonces, T1, si bien
pidió el dato B, se va a quedar esperando que desbloqueen el dato A, para poder tomarlo y proseguir su transacción. Ahora, la T2, antes
que la transacción T1, había pedido el dato A, y como estaba libre se lo dieron, por lo tanto, estaba bloqueado él. Ahora lo que hace con
el bloqueo incremental, va a necesitar, para terminar, el dato B, pero éste no lo va a poder tomar porque lo pidió T1, lo tiene
bloqueado, pero está a la espera de que le den este, esta esperando. Esta situación hace que T1 no pueda avanzar, y por lo tanto no
puede soltar el dato B, pero T2 tampoco puede avanzar, y por lo tanto puede soltar el dato A, pero como ninguno de los dos puede
avanzar ninguno de los dos va a soltar el dato. Esto se llama un INTERBLOQUEO. Se quedarían indefinidamente esperando y tendríamos
bloqueadas esas transacciones indefinidamente. Se da porque los bloqueos se van haciendo de manera incremental.
 Esto lo tiene ya planteado, se sabe que puede pasar cuando usan bloqueos.

Las estrategias son:

- Detección de interbloqueos y métodos para salir del interbloqueo. Sale del mismo “matando” a alguna de las transacciones. El
interbloqueo se detecta a través de grafos, cuando detecta que hay un bucle. El interbloqueo se puede dar entre mas de 2
transacciones. Cuando detecta esos bucles, detecto el interbloqueo. Lo soluciona haciendo retroceder alguna de las transacciones.
Detectando y matando alguna de las transacciones. Dentro de ese protocolo tiene que elegir cual mata (a la menos costosa, a la que
inicio después, etc.), la que es menos perjudicial.
- Tratar de prevenir los interbloqueos. Esto implicaría mayor de restricciones.

Métodos para tratar el problema:

- Temporizaciones
- Prevención de interbloqueos
- Detección y recuperación de interbloqueos.

CLASE 08/06
Datawarehouse

Las soluciones de BI intentan brindar información para apoyar la toma de decisiones, principalmente de los niveles tácticos y
estratégicos. Es por eso tenemos que considerar que existen distintos tipos de decisiones a lo largo de las distintas áreas y niveles
organizacionales y que, justamente, estos niveles organizaciones van a hacer que esas características que tienen los tipos de decisiones
que se suelen tomar en esos niveles hagan que la información, como insumo principal que apoya a esa toma de decisiones, también
sean distintas. Y es por eso, que nos vamos a basar en características

Características de la información:
- AH HOC
- Ocasional
- Integral: visión integral tanto reuniendo datos internos como externos de la organización.
- Resumida: información resumida de la visión de toda la organización
- Externa e interna

 Son el tipo de información que necesitan los decisores tácticos y estratégicos. Las herramientas asociadas a los sistemas
transaccionales, en general, lo suelen solucionar. Entonces, las soluciones de BI tratan de apuntar a brindar información para estos
actores y estos tipos de decisiones de los niveles mas altos de una organización.

La realidad de las organizaciones en cuestión de datos es que, los datos que dan soporte a los sistemas de nivel operativo por lo general
son múltiples repositores heterogéneos que si bien, dan un adecuado soporte a estos sistemas, no suelen dar soporte a las necesidades
de operación de los niveles mas altos.

Base de datos OLTP: se llama al tipo de procesamiento de los datos cuando el tipo de procesamiento es para actualizar o consultar
pequeñas porciones de datos de cada proceso, independientemente que podamos tener múltiples procesamientos de datos actuando
de manera concurrente. Existen en la mayoría de las organizaciones, en general.
Base de datos OLAP: se suele necesitar para procesar y brindar información para este tipo de información para la toma de decisiones,
va a ser principalmente de consultas de grandes porciones de la base de datos, pero que no necesita una actualización en línea de los
datos, sino una actualización de datos puede ser BATCH.

Los tres problemas del OLTP

Problemas que hacen que se necesite una solución como una base de datos como Datawarehouse:

1) Información no integrada: Esta realidad, con múltiples repositorios heterogéneos, hace que no puedan darse respuesta a
necesidades de información integrada que cubran aspectos de múltiples de estos sistemas, y que, por otro lado, esa dispersión de los
datos hace que determinada información, por mas que sea puntual, pueda obtenerse de distintos repositorios de datos, y eso haga a
que distintos actores, según donde tomen los datos, van a tener información del mismo aspecto pero que es distinta.

2) Inadecuados tiempos de respuesta: estas bases de datos, que responden a los sistemas OLTP, si bien dan adecuados tiempos de
respuesta para estos procesos, cuando necesitan hacer procesamiento OLAP para brindad información para la toma de decisiones, se
encuentran con que no lo pueden hacer, por un lado, porque estas consultas compiten en recursos contra los procesos de las
transacciones y eso hace que no tengan un adecuado tiempo de respuesta y, por otro lado, porque justamente determinados
mecanismos que se usan para cuidar la consistencia en los sistemas OLTP, hacen que se bloqueen muchos de estos procesos y se
demoren aun mucho más. Y, por último, porque determinados criterios, como buenos criterios en los sistemas OLTP, como evitar la
redundancia o archivos de índice que funcionan bien para la actualización veloz, no son los mejores para este otro tipo de
procesamiento.

3) Inexistencia de herramientas: No disponer de herramientas que visualicen o brinden la información como la necesiten los decisores
según ciertas características. Si bien, esta asociado principalmente a que no existan herramientas de visualización, también tenemos un
problema a nivel de los datos, porque los datos que responden a los sistemas transaccionales no están preparados para una exploración
sencilla, según las temáticas que se necesitan en la adhesión, sino que principalmente están estructurados para dar un buen soporte.

Estos tres problemas se solucionan a través de una solución de BI

Arquitectura de la solución de BI:

1) Existen distintas fuentes de datos que existen en la org de manera interna o que están disponibles que son del contexto. El
2) Datawarehouse va a integrar todos esos datos en una única base de datos, por lo tanto, va a haber redundancia, porque van a seguir
existiendo los datos que antes existían, pero además vamos a crear una nueva base de datos que es el Datawarehouse que, a través de
procesos ETL, que son procesos de integración de datos, van a actualizar el Datawarehouse. Esta actualización, por lo general, se realiza
mediante procesos batch.
3) Distintas herramientas de FRONT END, por las cuales los usuarios acceden a la información a través de distintos estilos formales. Las
mismas van a consultar ya una base de datos integrada que es el Datawarehouse.

¿Por qué soluciona los tres problemas?

1) El DH ayuda a integrar en una única base de datos la totalidad de los datos que se encuentran dispersos, ya sea internos como
externos
2) Como es otra base de datos y su objetivo es el procesamiento OLAP, puedo aplicar determinados criterios de diseño y administración
para que sea eficiente.
3) Estas herramientas están preparadas para que los datos estén modelados y preparados de determinada manera que faciliten su
exploración.

DATAMART
También es una base preparada para un procesamiento OLAP de manera eficiente, pero a diferencia del DH cubre solamente algún
proceso o temática dentro de la organización. El DH trata de representar la realidad de toda la organización, y cuando se usan
DATAMART, son específicos y temáticos (es un especie de Datawarehouse, pero temático), ejemplo, datamart de ventas, de RRHH, etc.

ETL: extracción, transformación y carga. Es uno de los aspectos más complejos en la construcción del DH porque implica pensar
procesos que puedan mapear, desde la fuente de datos hasta el DH, pero tratando de homogeneizar modelos que son totalmente
heterogéneos. Se les incorpora dentro de estos procesos de integración de datos aspectos para tratar de eliminar errores y corregir
datos faltantes para asegurar una calidad de datos en el Datawarehouse. Parte de esa transformación va a implicar estructurar los datos
para que se puedan usar de una manera mas eficiente.
 ETL: permite la extracción de cargar distintas fuentes de datos, la transformación para homogeneizar formatos, codificaciones,
niveles de agregación y aspectos de calidad, y finalmente cargarlo todo en un Datawarehouse.

Estos procesos, principalmente son BATCH, pero puede existir que alguno se pueda generar en tiempo real.

Estas herramientas de acceso a la información tienen tres categorías:

- ANALISIS Y EXPLOTACION: herramientas para análisis dinámico de la información, a través de lo que se llama análisis
multidimensional.
- CONSULTA INFORMACION: herramientas planteadas para tener algunos formatos bien preparados, pero más estáticos, de consultas
preplaneadas, como son los reportes, dashboards, etc.
- DESCUBRIMIENTOS DE PATRONES: existen una serie de modelos que se pueden incorporar para tratar de describir algunos patrones
significativos, tratando de encontrar o reversiones o inclusive la posibilidad de generar modelos predictivos y poder entender cómo
podrían ser determinadas variables en el futuro.

Todos estos estilos de acceso a la información van a tomar los datos del DH o del DATAMART, según corresponda.

DATAWAREHOUSE: es un concepto que crea Inmon, donde plantea 4 características.

1) Base de datos no orientada a los procesos sino orientada a los temas en las cuales se van a tomar las decisiones
2) Base de datos totalmente integrada
3) Datos no volátiles, debería ser una base de datos donde siempre se van actualizando y solo haciendo insert de datos a través de los
ETL, pero nunca eliminando lo que existía previamente.
4) Datos históricos, porque estén o no estén los datos guardados históricos en OLTP, porque a veces se pueden ir pisando, el DH si tiene
que ir guardando toda esa historia para poder hacer comparaciones.

El Datawarehouse:
1) Integra datos de los distintos sistemas OLTP
2) Incorporar datos externos
3) Incorpora datos históricos, que no existían en OLTP
4) Permite el diseño y la administración pensando en un procesamiento OLAP eficiente, ya sea a través de incorporar redundancia o a
través de índices específicos.
- guardar datos pre calculados
- índices que optimicen este tipo de consultas
- estructuras de datos redundantes
- independizar la base de dato de la alta concurrencia del OLTP
5) Posibilita incorporar determinados diseños a nivel de modelado de datos que faciliten su exploración por parte de los usuarios

CLASE 11/06
- Datos: Representación simbólica, atributo o característica de una entidad. No tiene valor semántico (sentido) en sí mismo.
- Información: Dato tratado, útil para realizar una tarea (cálculos, informes, toma de decisiones, etc.). Soporta el negocio y/o actividad
de la organización. La información tiene un tipo de tratamiento que la hacen útil, sobre todo para la toma de decisiones y para
incorporarlo en determinados procesos del negocio.

DATO  PROCESAMIENTO  INFORMACION

La información, como cualquier otro activo dentro de la organización, es un activo estratégico dentro de las organizaciones y que tiene
que recibir un tratamiento adecuado y una protección adecuada, sobre todo aquellos datos que son mas sensibles dentro de la
organización.
Seguridad de la información

CID
Hay que asegurar tres principios fundamentales
1) C (confidencialidad): se tienen que asegurar que se protegen los datos sensibles, contra la revelación no autorizada. Que no
cualquiera pueda tener acceso a determinados datos que se consideran sensibles o confidenciales
2) I (Integridad): determinados datos no puedan ser alterados, ya sea de forma intencionada como no intencionada.
3) D (Disponibilidad): la información siempre este en tiempo y forma cuando se la quiera consultar. Que no ocurra algún tipo de
siniestro o fallo que haga que no se pueda acceder a determinada base de datos o información porque se cayó algún sistema o hubo
algún fallo.

Amenazas contra los datos

Se analiza los activos de la empresa para entender que vulnerabilidades puede llegar a presentar. Lo que se va a hacer es analizar los
activos y ver que vulnerabilidades pueden llegar a presentar (una vulnerabilidad es alguna debilidad que puede tener el sistema que
hace susceptible que ese activo pueda materializarse determinada amenaza provocando algún tipo de impacto. El riesgo es la
probabilidad que se materialice esa amenaza por el impacto. Se va a prestar mayor atención a los riesgos que tengan mayor
probabilidad de ocurrir y mayor impacto, y, a partir de eso, se van a aplicar determinados controles para mitigar ese riesgo que existe).

Niveles de Seguridad
Se pueden aplicar medidas de seguridad a distintos niveles, para proteger los datos y la información de una organización.
- DBMS: a nivel de la base de datos.
- S.O: a nivel del Sistema Operativo. Porque esa base de datos va a ser accedida por un sistema operativo determinado. Va a tener que
contar con las medidas de seguridad adecuadas. Estar actualizado con las ultimas actualizaciones que existan
- APP: a nivel de las aplicaciones. A nivel del aplicativo por el cual se acceden a esos datos. Las APP tendrán que contar con un análisis
de seguridad del código.
- Red: aplicaciones web, que acceden los datos a través de una red. Tenemos que considerar ese canal de comunicación por el cual se
transmiten esos datos.
- A nivel físico: esos datos generalmente son almacenados en algún medio de almacenamiento físico. Por ejemplo, dentro de algún
servidor. En este caso, también contar con las medidas de seguridad en el acceso físico a ese equipamiento donde residen esos datos
físicamente.
- Humano: es la cadena se corta por el eslabón mas débil, que muchas veces son las personas, las personas que pueden ser engañadas,
o ejercer determinada influencia, y pueden brindar determinados datos que son sensibles. Esas personas deben ser concientizadas en
seguridad y contar con los accesos adecuados para no vulnerar la información, los datos, con los que cuenta la organización. Puedo
contar con un montón de medidas de seguridad en los otros niveles, pero tenes falencias a nivel humano.

Medidas de Seguridad (BD)

- Restricciones: para asegurar la integridad de los datos. Las restricciones de la unidad temática 3, donde hay restricciones de dominio,
triggers, etc.
- Medidas de recuperación ante fallos/Backups: unidad temática 7. Ayudan a asegurar las propiedades de disponibilidad e integridad.
- Control de la concurrencia: trata de lograr, a través de los protocolos, que no haya inconsistencia, por tanto, asegurar la precisión y la
validez de esos datos, la integridad de esos datos.
- Autorizaciones: tiene que ver con los permisos que se otorgan a nivel de la base de datos. Lo que hacen es restringir los accesos a los
datos de acuerdo con los perfiles que tiene cada uno de los usuarios y el rol que cumplen dentro de la organización.
- Vistas/SP: en las vistas elijo que información mostrar y que no. Porque justamente podría otorgar permiso a una vista y no a una
tabla. Ejemplo, tabla de empleado con dato de sueldo. Es mejor darle acceso a determinado usuario a una vista (cuando se crea la vista
se oculta el dato de sueldo). Por otro lado, los SP, permiten que, si determinado usuario debiera realizar o ejecutar determinadas
acciones, que tenga que modificar determinados datos, se le podría dar acceso al SP que ejecuta determinadas acciones y no a la tabla
completa para que pueda tener acceso a todos los datos, asegurando también la integridad, no solo la confidencialidad que no pueda
ver cualquier dato, sino la integridad en el sentido de que no pueda modificar algún dato de forma accidental que no deba.
- Cifrado: esta medida aseguraría que los datos viajen seguros a través de la red, en algún repositorio de la base de datos, que no sean
fácilmente inteligibles, que no se puedan ver en claro, para poder asegurar la confidencialidad de los datos.

Autorizaciones
Tiene que ver con los permisos que se van a otorgar a los determinados usuarios que tiene que acceder a las bases de datos, para poder
realizar determinadas operaciones, de consulta o de actualización, ya sea desde los datos o del esquema.
* Se pueden otorgar acceso a los datos:
- Consulta (SELECT)
- Inserción (INSERT)
- Borrado (DELETE)
- Actualización (UPDATE)

* Se pueden otorgar acceso al esquema de la base de datos (apunta no al acceso o la modificación del contenido de esas tablas, sino a
la estructura de estas). Lo puede tener el DBA o el desarrollador del aplicativo:
- Crear tablas/atributos (CREATE)
- Eliminar tablas (DROP)
- Alterar tablas/atributos (ALTER)
- Crear y eliminar índices (INDEX)

* Usuarios y Roles:
Se asignan y administran los accesos de los usuarios mediante roles o grupos de privilegios. Un rol puede tener 1 o más autorizaciones.
 Modelo de acceso basado en roles, que permite una administración mas eficiente de lo que son los permisos y de las autorizaciones
dentro de una base de datos. Lo que se crea es un determinado rol dentro de la base de datos, de acuerdo con los roles que existen
dentro de la organización, por ejemplo, el gerente, el jefe, el supervisor, etc. Se van a crear estos roles y se van a asignar permisos
directamente a esos roles. Y luego se le van a asignar esos roles a los usuarios. Se le asigna determinado rol, el cual hereda todos los
permisos que tiene ese rol asignado.

Vistas
La vista proporciona un modelo personalizado de la BD, ocultando datos que un usuario no necesita o debe ver.

Store Procedure
El SP es una programación de una o varias tareas en la base de datos, que se otorga al usuario.

Esquema General de Accesos

 En general no se otorgan accesos directos a las bases de datos a sus usuarios finales, sino que lo realizan a través de distintos
aplicativos. Ejemplo, SAP, Oracle, etc. Van a acceder a través de software aplicativos, no van a acceder directo a la base de datos. Van a
hacer determinadas consultas que le va a presentar el propio aplicativo al que le están consultando. Solo pocos usuarios puede tener
acceso directo a hacer consultas o modificaciones a la base de datos en sí, el resto de los usuarios van a acceder a través del software
aplicativo. Este SA se va a conectar con la base de datos a través de algún usuario de servicio o de transporte, que son usuarios
específicos que van a tener estas aplicaciones para conectarse a la base de datos. Finalmente, los permisos de acceso se le van a
otorgar a los usuarios dentro de los aplicativos y no tanto desde el lado de la base de datos. El DBA si tiene un acceso directo.

Medidas de Seguridad (BD)

 Esta asignación de los permisos se hace a través de lo que son determinadas sentencias, también del SQL, que se le llama DCL (Data
Control Language), que permiten otorgar permisos, denegarlos, o revocar los permisos que ya se hayan concebido.

SQL (DCL):
Con el nombre de lenguaje de control de datos se hace referencia a la parte del lenguaje SQL que se ocupa de los apartados de
seguridad y de la integridad en el procesamiento concurrente.

Cifrado
Técnica que protege o autentica a un dato, mensaje o usuario al aplicar un algoritmo criptográfico. Es mejor práctica conocer una clave
específica para cifrar/descifrar el dato
 Es para asegurar la confidencialidad de los datos.

Técnicas de cifrado:

Cómo funciona el cifrado en el DBMS

Saber que existen, a nivel de la base de datos, funcionalidades que nos permiten hacer uso de estas funcionalidad de cifrado, creando
claves y permitiendo cifrar determinados campos o tablas enteras de la base de datos. Existen otras técnicas como el tokenizado de los
datos (como un token de seguridad que sirve para proteger determinados datos. típicamente se usa, por ejemplo, en lo que son las
entidades financieras para proteger lo que son el panda y el numero de la tarjeta de crédito, etc. O enmascaramiento de datos, por
ejemplo)

Unidad 10

Base de datos distribuida

Distribución de las Bases de Datos

1) Esquema independiente: una empresa puede tener sedes en distintos países, los cuales tienen el mismo sistema,
pero trabajan sobre repositorios locales, bases que son propias de ese sitio o de ese nodo, pero que no tienen ningún
tipo de relación sincrónica o asincrónica entre sí. No se comunican de ninguna manera, y son repositorios
independientes de información. Cada sitio consulta sus datos de sus clientes dentro de su repositorio local, pero sin
acceder a repositorios externos. Es un esquema descentralizado. Son bases de datos física y lógicamente separadas.
2) Esquema Centralizado: va a existir un único repositorio, es una única base de datos que va a estar en una
localización física, y todo el resto de las sedes se van a conectar desde los sistemas a este repositorio centralizado y
único. No existen bases de datos en distintas localizaciones sino es un único repositorio en la cual todas acceden. Todo
va a impactar en una única base de datos, situada en un país especifico. Acá se requiere de una conexión de red
 sincrónica, porque para poder operar van a necesitar acceso de consulta o de actualización a la base de datos del país
donde se encuentra situada la sede.
3) Independiente con Acceso Compartido: no es a lo que se llama base de datos distribuida, ya que es un esquema
independiente pero que puede llegar a brindar algún tipo de compartición de datos, es decir, se le da un acceso
compartido desde alguna localización, a determinados repositorios que están en otra localización. Se le da acceso para
poder usar los datos de otra localización. O también, este esquema, se puede dar a través de los que son web service
(no estoy linkeando las bases de datos a un servidor), que va a permitir que ese servicio web reciba una consulta
desde un país, se va a conectar a la base de datos que se requiera, y es el web service el que le va a responder al país a
través de un formato de un archivo XML. No tiene acceso directo a través de la base de datos, pero si se pueden
relacionar a través de esquema de web service. NO HAY TRANSACCIONES GLOBALES. Ya sea a través de links de base
de datos o a través de web service, son esquemas descentralizados pero que admiten algún tipo de acceso para
compartir datos entre las distintas geografías o distintos sitios. No aplica el concepto de transacción global.
4) Independiente con Acceso Compartido Web Service
5) Esquema Distribuido: hay una conexión, no están desconectadas como se está en el esquema independiente, sino
que hay una conexión generalmente sincrónica (puede ser asincrónica también) de la base de datos. Son repositorios
físicos distintos, pero se dice que lógicamente forman una única base de datos. A diferencia del esquema
descentralizado (1), donde son repositorios lógica y físicamente distintos, no hay ningún tipo de conexión, acá son
repositorios físicos distintos, pero lógicamente conforman una única base de datos. No es un esquema
descentralizado.

Centrándonos en el concepto de bases de datos distribuidas 

La distribución aplica en si distintas técnicas (la distribución se puede hacer a través de réplica o de fragmentación):
1) Fragmentación: distribuye los datos a nivel de las filas o de las columnas, pero no haciendo copias. En si la tabla es única, entonces,
por ejemplo, la asignación de ID de cliente es único. Es una única tabla pero que físicamente esta distribuida en distintos repositorios.
Se podría acceder a la tabla completa desde cualquier geografía.

Fragmentación Horizontal: si estoy haciendo una fragmentación horizontal, parte de la tabla de clientes la voy a almacenar en algunas
localizaciones determinados registros y otra en otras. Por ejemplo, un criterio puede ser que cada geografía guarde los datos de sus
propios clientes (los clientes de argentina en la base de Argentina). En este caso hago una distribución a nivel de las filas de una tabla.
Es decir, distribuyo a nivel de las filas.

Fragmentación Vertical: es a nivel de las columnas. Por ejemplo, podría llegar a tener determinados atributos que tienen sentido dentro
de ese sitio o esa geografía. En este caso, el numero de seguridad social que solo se utiliza en EEUU, por ejemplo. O, el CUIT que tiene
sentido en Argentina. Determinados datos los voy a almacenar en determinada base, pero si tienen que almacenarse en los dos
repositorios el numero de cliente, que es el atributo común. Si quiero acceder a la tabla completa de otra geografía, si desde Rusia
quiero ver la tabla completa de Argentina, el ID es el atributo común que me va a poder traer el resto de los datos.

Ventajas:
a) Disminuye el tráfico de la red: es menor el trafico de red con respecto al tema de la replica porque no envías todos los datos, sino
envías solo una parte.
Desventaja
a) Operaciones globales: son más complejas porque lógicamente vamos a tener transacciones que son globales que, para insertar el
dato de un nuevo cliente, esa transacción va a tener distintas partes que se van a tener que ir actualizando en distintos repositorios.
Introduce una complejidad adicional en lo que tiene que ver con este tipo de transacciones que son consideradas globales.
2) Replica: determinada tabla o tablas, no tiene que ser una réplica de toda la base de datos completa, se hace una copia exacta de esta
tabla en la base local de cada país. La distribución lo que hace es copiar los datos en distintos sitios. Seria un esquema de base de datos
distribuida aplicando la réplica. Consiste copiar en la base de datos completa o alguna de las tablas que se quiera en otra localización.
Acá no tengo copias, solo voy a tenerlo en una base de datos, si aplico la fragmentación. Distribuyo a nivel de las filas, por eso voy a
tener distintos registros en distintas localizaciones.

Ventajas:
a) Optimizan las consultas: se optimizan las consultas, porque se paraleliza el acceso a distintos repositorios, y porque, además, dentro
de determinada geografía, se puede hacer una consulta a la base de datos local, y no acceder al repositorio que esta en otra geografía.
Acelera los tiempos de determinadas consultas, porque todo los tiempos de latencia para acceder a determinadas operaciones en otras
localizaciones.
b) Disponibilidad: tengo mayor disponibilidad de los datos, porque si se cae uno de los nodos o localizaciones, puedo acceder a otro,
entonces me da o me otorga una solución que tiene mayor disponibilidad que si contara con los datos en un repositorio centralizado. Si
se cae la base de datos de argentina, por ejemplo, puedo consultar los datos de otra sede.

Desventaja:
a) Sobrecarga: tiene una sobrecarga sobre todo en transacciones globales. Esta complejidad que introduce estas transacciones globales
genera una sobrecarga mayor en el sistema.

Uso de la partición/fragmentación y distribución de los datos

¿Qué hacer si hay problemas de conexión entre los nodos?

Si ir por asegurar la disponibilidad o la consistencia de los datos (Disponibilidad vs consistencia del Sistema de Datos)

Durante una actualización, se generan estados inconsistentes que pueden ser incompatibles con lo que tiene almacenado otro nodo (ya
sea en fragmentación o replica). Puedo tener inconsistencia entre los nodos, entre la información que tengo almacenada en las distintas
localizaciones. Si tengo problemas de conexión y no puedo validarlo/controlarlo en línea.

¿Qué hago?
a) Puedo reducir las operaciones disponibles (no permitir la lectura y escritura de datos relacionados) y reducir la disponibilidad del
Sistema de Datos. Sacrifico un poco de disponibilidad y no permito que se lean esos datos hasta que vuelva esa conexión y pueda
validar esos datos con el otro sitio. En pos de lograr mayor consistencia sacrificamos disponibilidad.
b) Puedo permitir las operaciones, pero hay que tener recaudos adicionales respecto a cómo se resuelven problemas de inconsistencia
que puedan surgir. Permito que se ejecuten determinadas operaciones de consulta, por ejemplo, pero hay que tener recaudos
adicionales en base a problemas de inconsistencias que puedan surgir. Sacrificamos consistencia en pos de lograr disponibilidad.

Teorema de CAP
En los sistemas distribuidos de datos, no se pueden lograr estas tres propiedades al mismo tiempo. No se pueden lograr asegurar estas
tres propiedades al mismo tiempo, sino que solo podrán asegurar dos de ellas.
a) Asegurar la consistencia (distinto concepto de ACID): tiene que ver con que la misma información la tengamos almacenada en los
distintos nodos de la base de datos. Ejemplo, en caso de que tengamos replicas, que tenga los mismos datos en los distintos nodos y
que no haya disparidades en la información.
b) Disponibilidad: la información siempre este en tiempo y forma cuando se la necesite consultar o acceder
c) Tolerancia a las particiones: el sistema en sí, en su conjunto, funcione bien a pesar de estar particionado en la red. Considerando que
tenemos distintos nodos y que en algún momento puedan llegar a perder la conexión entre si
No secuenciable

Partición y fallos en RDBMS (BASE DE DATOS RELACIONAL)

Se considera, en un sistema de base de datos distribuida, un conjunto de componentes.

- Sitio de la localización: donde esta esa base de datos local
- Red: si tenemos una base de datos distribuida, dependemos totalmente de la conexión de red que tengamos
- Coordinador de transacciones: es un actor nuevo dentro de este sistema, que coordina todas las transacciones globales que se vayan a
realizar cuando se hace una réplica o una fragmentación que involucran a distintos sitios. Es el que va a poner orden para lograr que
estas transacciones se puedan o comprometer o abortar en todos los sitios o realizarse nada en ninguno de ellos. Para que se valide que
determinada transacción se llegó a ejecutar en un sitio y en otro no. Funciones: Inicio de la ejecución de la transacción. División de la
transacción en subtransacciones y distribución a los sitios. Coordinación de la terminación de la transacción (Comprometer o Abortar)
- Gestor de transacciones: es el que va a ir almacenando y llevando un registro histórico, y ejecutando las acciones de rehacer o
deshacer para asegurar la atomicidad de los datos y también la durabilidad. También, todas las cuestiones que hacen al control de
concurrencia dentro del sitio. Funciones: Mantenimiento de un registro histórico con fines de recuperación. Control de la concurrencia
en el sitio.

Fallos que pueden provocarse

- Caída De Un Sitio: Problemas relacionados con el hardware o software del sitio
- Pérdida Del Enlace: Problemas con las comunicaciones hacen que se pierda la conexión a un sitio.
- Pérdida De Mensajes: Pérdida de paquetes transmitidos a través de la red

Consistencia de Transacciones

 Protocolo De Compromiso: Garantiza la propiedad de consistencia, ya que en todos los sitios en los cuales se ejecuta una transacción
la misma se comprometerá o abortará. Garantiza que se asegure la atomicidad de las transacciones, que en este caso son globales,
tanto para el caso de las replicamos como para la fragmentación.
- Dos fases (C2F): Es uno de los más sencillos y más utilizado en bases distribuidas.
- Tres fases (C3F): Variante del C2F, evita ciertos inconvenientes del C2F, pero añade complejidad y sobrecarga

BIG DATA – Problemática de las 3V (variedad, velocidad y volumen)

1. Grandes volúmenes: hablamos de sistemas de datos que almacenan grandes volúmenes de información.
2. Acceso concurrente multitudinario: Miles o millones de usuarios que acceden de forma concurrente a determinados repositorios de
datos y cuya recuperación muchas veces tiene que ser en tiempo real. Pone el ejemplo de los sistemas que dan soporte a redes sociales
3. Alta disponibilidad (7x24): tienen que ser tolerantes a fallas. No pueden estar no disponibles por mucho tiempo
4. Datos semi o no estructurados: manejan datos semi o no estructurados. Tema de la variedad de los formatos.

Este tipo de desafíos que se plantean del BIG DATA, generalmente las bases de datos relacionales no pueden dar solución, aun
hablando de sistemas de bases de datos distribuidos relacionales. Lógicamente porque las bases de datos relacionales, lo que tratan de
cuidar siempre es asegurar la consistencia de los datos. En ese caso, no asegurando la tolerancia de fallos ni la alta disponibilidad, pero
si priorizando mucho la consistencia de los datos. Típicamente son bases de datos que se usan para llevar las transacciones y la
operativa diaria de una organización, soporte de sistemas de información transaccionales.
 Para lo que plantea el BIG DATA si se quedan un poco atrás porque, si necesitamos asegurar rendimiento y alta disponibilidad, en
este caso, sin tener en cuenta o restándole más importancia a la consistencia, acá es donde surgen otras alternativas de bases de datos
no relacionales, que, si pueden dar solución a muchas de estas problemáticas, pero sacrificando la consistencia. Estos esquemas
distribuidos lo hacen aplicando fragmentación y replicación, muchas veces en forma combinada (partición y replica a la vez).

¿Como es que logran dar soporte de alta concurrencia y performance? Lo hacen escalando en forma horizontal. Que una solución escale
en forma horizontal significa que se agregan distintos nodos, generalmente mas chicos que no tienen que tener un gran nivel de
procesamiento o almacenamiento, pueden ser nodos no muy sofisticados y no con mucha tecnología, pero que agregando muchos de
estos nodos, permite implementar estos sistemas distribuidos, aplicando la fragmentación y la replicación
 A diferencia de lo que seria escalar una solución en forma vertical, significa agregar mas potencialidad, mas cantidad de
procesadores, mas capacidad de almacenamiento, mas memoria. Esto tiene un límite. Además, el tener estos nodos en forma
distribuida, me permite tener una alta disponibilidad que, en caso de tener un nodo muy potente, si ese nodo falla o se cae,
lógicamente no tengo mucha disponibilidad, ya que la disponibilidad esta dada por la redundancia.
- Crecer en forma horizontal: agregar más nodos, aunque sean chicos, es escalar en forma horizontal una solución. Muchos nodos
donde se va a aplicar la distribución de los datos en cuanto a replica y a fragmentación.
- Crecer en forma vertical: es crecer en capacidades, ser mas potentes, en un único nodo.

En resumen: Las bases de datos relacionales no pueden dar solución a este tipo de problemáticas. Lo que tratan de hacer estas bases de
datos relacionales, y sobre todo a través de ACID, es asegurar la consistencia de los datos. Su fuerte es asegurar la consistencia de los
datos. Para lograr mas performance y disponibilidad, necesitamos sacrificar la consistencia en pos de ello. Entonces, ahí es donde
surgen o aparecen este tipo de soluciones de bases de datos no relacionales (no SQL como sinónimo, pero no es lo mismo).

En caso de las bases de datos no relacionales, vamos a estar trabajando el concepto de consistencia eventual, que quiere decir que
puede llegar a tener inconsistencias temporales, es decir, es tolerante a determinadas inconsistencias temporales. El sistema va a
tender en algún momento, en unos pocos segundos, a volver a un estado consistente, pero en algún momento puede ser que un nodo
tenga diferencias con la información que esta almacenada en otro nodo de esa misma solución. Esto es algo aceptable para lograr y
brindar una mayor disponibilidad y rendimiento a esta solución.

Procedimiento Almacenado
Ejemplo: adivinar la edad en función a un año que le pasamos por parámetro.

CREATE PROCEDURE CALCULA_EDAD(AÑO_NACIMIENTO int)

-- CALCULA_EDAD (nombre del procedimiento)
-- AÑO NACIMIENTO (nombre del parámetro de entrada + tipo de dato)

BEGIN
-- Donde comienza el bloque de ejecución

DECLARE AÑO_ACTUAL INT DEFAULT 2016;

DECLARE EDAD INT;
-- DECLARE (declarar la variable dentro de un procedimiento almacenado)
-- AÑO_ACTUAL Y EDAD (nombre de la variable + tipo de dato)
-- 2016 (es el año actual que va a traer para comparar con el año de nacimiento)

SET EDAD = AÑO_ACTUAL-AÑO_NACIMIENTO;

-- SET (indicar el cálculo en donde se utilizarán mis variables declaradas)

SELECT EDAD;
-- SELECT = RETURN (nos devuelve lo que hay almacenado en el valor EDAD. Nos devuelve la variable)

END
-- Donde termina el bloque de ejecución

Resumen

CREATE PROCEDURE CALCULA_EDAD(AÑO_NACIMIENTO int)

BEGIN

DECLARE AÑO_ACTUAL INT DEFAULT 2016;

DECLARE EDAD INT;

SET EDAD = AÑO_ACTUAL-AÑO_NACIMIENTO;

SELECT EDAD;

END

Trigger
Crear trigger para nuestra tabla de productos. Actualizar precios. Queremos que no se puedan actualizar instrucciones de UPDATE con
precios extraños (precio negativo, o precio muy alto). Trigger que en su interior tenga una estructura en la cual, antes de actualizar,
debe ver si el precio está comprendido entre dos valores. Si ocurre, que lo ejecute el UPDATE, sino que haga lo que queramos (deje el
precio como esta, le indique otro precio, etc.)

CREATE TRIGGER REVISA_PRECIO BEFORE UPDATE ON PRODUCTOS FOR EACH ROW

-- REVISA_PRECIO (nombre del trigger)
-- BEFORE UPDATE (indicar cuando tiene que ejecutar este trigger)
-- ON PRODUCTOS (en que tabla debe ejecutarlo, en este caso la tabla PRODUCTOS)
-- FOR EACH ROW (para cada fila de la tabla)
BEGIN
 IF(NEW.PRECIO < 0) THEN
SET NEW.PRECIO = 0;

ELSE(NEW.PRECIO > 1000) THEN

SET NEW.PRECIO = 1000;

END IF;
-- Condición de trigger

END