Edición de «Final del 11/11/19 (Bases de Datos)»

Fueron 8 preguntas/ejercicios, dio 2hs exactas. No todos los puntos valían lo mismo y no sabías cuánto valía cada punto. Es probable que el orden de las preguntas no haya sido exactamente así.

== Consigna ==

# Definir transacciones y dar y explicar las propiedades ACID.
# Definir clave candidata. Definir clave primaria. Cuando un esquema está en 2FN?
# Definir dependencia funcional. ¿Para qué sirve que la normalización? ¿Cómo esta relacionado con la calidad de un diseño de bases de datos? ¿Qué problemas puede presentar una base desnormalizada? Ejemplifique
# Dada la siguiente relación (idEstudiante, nombreEstudiante, nroCurso, idProfesor). En base a su conocimiento del dominio, detalle cuales son las dependencias funcionales en ese esquema. ¿Está en 3FN? Justifique. En caso de no estarlo dar una descomposición que sea 3FN.
# Defina bases de datos distribuida. Qué nuevos niveles de transparencia aparecen junto a estas bases?
# No me acuerdo exactamente el enunciado, pero era asi: Tenias dos tablas: Estudiantes E: (idEstudiante, nombreEstudiante, idFacultad, fechaNac), Facultad F: (idFacultad, nombreFacultad, region). Un estudiante va a 1 y solo 1 facultad. La tabla Estudiantes tiene 10000 registros de 30 bytes cada uno. La tabla universidad tiene 100 regitros de 20 bytes cada uno. Suponga una base de datos distribuida de 3 nodos N1, N2 y N3 donde N1 tiene la tabla estudiantes, N2 tiene la tabla universidades y N3 no tiene nada.
## Expresar en álgebra relacional la consulta: “devolver id de estudiante y nombre de la facultad para los estudiantes que hayan nacido despues de 1980”
## Dar dos estrategias de resolución de esta query, indicando cuantos bytes se transfieren por la red entre las maquinas. Por ejemplo “N1 y N2 mandan todo a N3”
## Esta no me la acuerdo mucho pero era algo como “de forma general, cual es la estrategia óptima?”
# (Creo que este era exactamente el enunciado, con un 90% de seguridad): Se tienen 4 servidores N1, N2, N3 y N4, y 4 regiones reg1, reg2, reg3, reg4 tal que cada servidor Ni está en la región regi.
## Indicar como sería la query en algebra relacional que fragmentaría a la tabla Facultades del insiso anterior para que cada facultad vaya al server de su región (todas las facultades pertenecen a una y solo una de esas 4 regiones) y la query que fragmente a la tabla Estudiantes por la region a la que pertenece su facultad.
## Qué tipo de fragmentación utilizó?
## Indicar en algebra relacional como sería la query que reconstruya las tablas originales
# Dar 2 heuristicas que use el optimizador de consultas. Ejemplifique.

== Respuestas posiblemente incorrectas ==

==== Pregunta 1 ====

Una transacción es un conjunto de instrucciones que se ejecutan formando una unidad lógica de procesamiento. Una transacción puede incluir uno o más accesos a la BD a través del uso de diversas operaciones (inserción, eliminación, modificación, etc.).

Las bases de datos se encargan de garantizar las propiedades ACID de las transacciones:

# Atomicity: Las operaciones de una transacción se ejecutan en su totalidad o no se ejecuta ninguna.
# Consistency preservation: Si la transacción se ejecuta completamente sin interferencia de otra transacción, entonces mueve a la BD de un estado consistente a otro también consistente.
# Isolation: La ejecución de una transacción no debe interferir con la de otra transacción que se ejecute de manera concurrente. Una transacción debe aparentar ser ejecutada como si lo hiciera de forma aislada a las otras incluso si varias de ellas son ejecutadas a la vez.
# Durability: Los cambios aplicados a la BD por una transacción commiteada deben persistir en la BD incluso ante fallos.

==== Pregunta 2 ====

Una clave candidata es una de las posibles claves de una relación. Una superclave S es un subconjunto de atributos de R con la propiedad de que no hay dos tuplas t<sub>1</sub>, t<sub>2</sub> en un estado legal r(R) que cumplan t<sub>1</sub>(S) = t<sub>2</sub>(S). Una clave es una superclave minimal; es decir, una que si se le saca un atributo deja de ser superclave.

La clave primaria es una clave candidata designada arbitrariamente como tal. Por ejemplo, en una tabla donde se tienen los atributos DNI y Pasaporte de una persona, uno podría elegir tanto DNI como Pasaporte como PK.

2FN es una forma normal que, además de ser 1FN (prohíbe relaciones dentro de relaciones, atributos multivaluados), cumple que todo atributo no primo A de R depende funcionalmente de manera completa de la PK de R. Esto es, que la PK es una DF minimal para todos los atributos que no pertenecen a alguna CK.

==== Pregunta 3 ====

Una dependencia funcional X -> Y entre dos conjuntos de atributos X e Y de una BD indica que cualquiera dos tuplas t<sub>1</sub> y t<sub>2</sub> en R tal que t<sub>1</sub>[X] = t<sub>2</sub>[X], se debe cumplir t<sub>1</sub>[Y] = t<sub>2</sub>[Y].

La normalización es una herramienta que se apoya en las DFs para evaluar y comparar distintas formas de agrupar atributos en un esquema. Al diseñar una base de datos normalizada siguiendo las formas normales, se busca que el resultado sea conceptualmente bueno (e.g entendible) y también físicamente bueno (e.g minimizar duplicación).

Para esto se siguen cuatro pautas fundamentales, que si bien no siempre pueden alcanzarse al mismo tiempo, dan una medida informal de la calidad del diseño:

# semántica clara
# reducir información redundante
# reducir la cantidad de valores NULL
# no permite generar tuplas espúreas

Una base de datos desnormalizada puede presentar distintos problemas, como por ejemplo:

* Anomalías de modificación: el nombre del departamento 33 es inconsistente (Compras/Adquisiciones):

{|
! idEmpleado
! idDepartamento
! nombreDepartamento
|-
|1
|33
|Compras
|-
|2
|34
|Ventas
|-
|3
|33
|Adquisiciones
|}

* Anomalías de deleción: al borrar el empleado 2 desaparece el departamento Ventas

{|
! idEmpleado
! idDepartamento
! nombreDepartamento
|-
|1
|33
|Compras
|-
|3
|33
|Adquisiciones
|}

* Anomalías de inserción: este esquema no permite agregar información de departamentos que aún no tienen empleados. Lo siguiente es inválido:

{|
! idEmpleado
! idDepartamento
! nombreDepartamento
|-
|NULL
|35
|Ingeniería
|-
|NULL
|36
|Calidad
|}

==== Pregunta 4 ====

Asumimos que este esquema representa una relación del estilo "inscripción a cursada" y consideramos que la PK está compuesta por { idEstudiante, nroCurso }. Las DFs que vemos son:

# idEstudiante -> nombreEstudiante: cada alumno tiene un único id asignado
# nroCurso -> idProfesor: asumiendo que un curso representa una instancia de materia + profesor + cuatrimestre de cursada

En este caso no se llega a 2FN (ni a 3FN) pues los atributos nombreEstudiante e idProfesor dependen parcialmente de la PK.

Proponemos el esquema normalizado en 3FN:

Estudiantes

{|
! idEstudiante (PK)
! nombreEstudiante
|-
|...
|...
|}

Cursos

{|
! nroCurso (PK)
! idProfesor
|-
|...
|...
|}

Profesores

{|
! idProfesor (PK)
|-
|...
|}

EstudiantesEnCursos

{|
! nroCurso (PK)
! idEstudiante (PK)
|-
|...
|...
|}

==== Pregunta 5 ====

Una base de datos distribuída (DDB) es una colección de múltiples BD que están lógicamente relacionadas y se encuentran distribuídas en una red de computadoras. Este tipo de DBs presentan características nuevas como la distribución de los datos, la replicación, la fragmentación horizontal y vertical.

A la hora de elegir una DDB, se deberán tener en cuenta las características de transparencia en estos aspectos (que facilitan el desarrollo), y cómo se relacionan con la flexibilidad y el grado de control que se requieran para alcanzar la performance, disponibilidad y tolerancia a fallos que se precise (entre otras cosas).

==== Pregunta 6 ====

1. Expresar en álgebra relacional la consulta: “devolver id de estudiante y nombre de la facultad para los estudiantes que hayan nacido despues de 1980”

&pi;<sub>idEstudiante, nombreFacultad</sub>(&sigma;<sub>year(fechaNac) > 1980</sub>(Estudiantes &#x2a1d; Universidades))

2. Dar dos estrategias de resolución de esta query, indicando cuantos bytes se transfieren por la red entre las maquinas. Por ejemplo "N1 y N2 mandan todo a N3"

Asumo que los datos deben finalmente a arribar a N3. Asumo que no voy a hacer un pre-filtro por edad pues no tengo datos para hacer los cálculos.

¿Cuánto espacio ocupa cada relación?

* Estudiantes: 10.000 registros * 30 bytes/registro = 300.000 bytes
* Universidades: 100 registros * 20 bytes/registro = 2.000 bytes

¿Cuánto ocupa la unión natural?

* Estudiantes &#x2a1d; Universidades: 10.000 registros * (30 + 20) bytes/registro = 500.000 bytes (cota superior)

Si se mandan todos los datos a N3 (obviando que los estudiantes podrían pre-filtrarse antes de mandarse), deberemos enviar 302.000 bytes por la red.

Si se mandan los datos de universidades a N1 y luego los resultados joineados a N3 (obviando que los estudiantes podrían pre-filtrarse antes de mandarse), deberemos enviar 502.000 bytes por la red.

300.000

3. Esta no me la acuerdo mucho pero era algo como "de forma general, cual es la estrategia óptima?"

Hay tan pocos datos que es imposible responder. Lo único que se me ocurre es decir que conviene hacer el join en el sitio destino, pues la desnormalización agrega datos redundantes que no se quieren enviar por la red.

==== Pregunta 7 ====

1. Indicar como sería la query en algebra relacional que fragmentaría a la tabla Facultades del insiso anterior para que cada facultad vaya al server de su región (todas las facultades pertenecen a una y solo una de esas 4 regiones) y la query que fragmente a la tabla Estudiantes por la region a la que pertenece su facultad.

Las queries que seleccionan los estudiantes y facultades para el servidor N<sub>i</sub> son:

* Universidades<sub>i</sub>: &sigma;<sub>region = reg<sub>i</sub></sub>(Universidades)
* Estudiantes<sub>i</sub>: &pi;<sub>idEstudiante, nombreEstudiante, idFacultad, fechaNac</sub>(&sigma;<sub>region = reg<sub>i</sub></sub>(Estudiantes &#x2a1d; Universidades))

2. Qué tipo de fragmentación utilizó?

En este caso estamos haciendo una partición horizontal (o sharding).

3. Indicar en algebra relacional como sería la query que reconstruya las tablas originales

Ambas se reconstruyen haciendo UNION de todos los fragmentos.

* Universidades: &cup;<sub>i=1->4</sub> Universidades<sub>i</sub>
* Estudiantes: &cup;<sub>i=1->4</sub> Estudiantes<sub>i</sub>

==== Pregunta 8 ====

El optimizador de consultas aplica heurísticas que, junto con datos estadísticos que colecciona, permiten elegir planes de ejecución probablemente muy buenos.

Una de estas heurísticas consiste en llevar las selecciones lo más cerca posible de las hojas. Si la condición que se evalúa tiene un alto grado de selectividad, entonces podremos descartar rápidamente datos que serán innecesarios.

Por ejemplo, si queremos hacer

 SELECT FirstName, SubjectName
 FROM Students, PassedSubjects
 WHERE Students.ID = PassedSubjects.StudentID
   AND Students.FirstName = 'Edgar'

Es posible que el optimizador note que Students.FirstName = 'Edgar' es muy selectivo, y convenga hacer esta selección antes que el JOIN con la tabla de PassedSubjects.

Otra heurística, que usualmente conflictúa con la anterior, es evitar bajar las selecciones a las hojas para poder aprovechar índices sobre los datos.

Por ejemplo, si cambiamos la condición

 SELECT FirstName, SubjectName
 FROM Students, PassedSubjects
 WHERE Students.ID = PassedSubjects.StudentID
   AND Students.Gender = 'F'

En este caso podemos pensar que la selectividad es bastante baja (˜50%). Es posible que el optimizador viendo esto elija no hacer esta selección sino hasta después de hacer el JOIN, aprovechando para esta operación índices que existan sobre Students.ID (probablemente índice cluster) y PassedSubjects.StudentID.
Revisión actual		Tu texto
Línea 1:		Línea 1:
	Fueron 8 preguntas/ejercicios, dio 2hs. No todos los puntos valían lo mismo y no sabías cuánto valía cada punto. Es probable que el orden de las preguntas no haya sido exactamente así.		Fueron 8 preguntas/ejercicios, dio 2hs exactas. No todos los puntos valían lo mismo y no sabías cuánto valía cada punto. Es probable que el orden de las preguntas no haya sido exactamente así.

	== Consigna ==		== Consigna ==