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

De Cuba-Wiki
Advertencia: no has iniciado sesión. Tu dirección IP se hará pública si haces cualquier edición. Si inicias sesión o creas una cuenta, tus ediciones se atribuirán a tu nombre de usuario, además de otros beneficios.

Puedes deshacer la edición. Antes de deshacer la edición, comprueba la siguiente comparación para verificar que realmente es lo que quieres hacer, y entonces publica los cambios para así efectuar la reversión.

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 ==


# Definir transacciones y dar y explicar las propiedades ACID.
# Definir transacciones y dar y explicar las propiedades ACID.
Línea 17: Línea 15:
## Indicar en algebra relacional como sería la query que reconstruya las tablas originales
## Indicar en algebra relacional como sería la query que reconstruya las tablas originales
# Dar 2 heuristicas que use el optimizador de consultas. Ejemplifique.
# 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.
Ten en cuenta que todas las contribuciones a Cuba-Wiki pueden ser editadas, modificadas o eliminadas por otros colaboradores. Si no deseas que las modifiquen sin limitaciones, no las publiques aquí.
Al mismo tiempo, asumimos que eres el autor de lo que escribiste, o lo copiaste de una fuente en el dominio público o con licencia libre (véase Cuba-Wiki:Derechos de autor para más detalles). ¡No uses textos con copyright sin permiso!

Para editar esta página, responde la pregunta que aparece abajo (más información):

Cancelar Ayuda de edición (se abre en una ventana nueva)
Obtenido de «https://www.cubawiki.com.ar/index.php/Final_del_11/11/19_(Bases_de_Datos)»