Revisión actual |
Tu texto |
Línea 21: |
Línea 21: |
|
| |
|
| ==== Pregunta 1 ==== | | ==== 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 ==== | | ==== 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. | | Una clave candidata es una de las posibles claves de una relación. Una clave 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). |
|
| |
|
| 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. | | 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. |
Línea 107: |
Línea 98: |
|
| |
|
| ==== Pregunta 4 ==== | | ==== 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 ==== | | ==== 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 ==== | | ==== 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”
| |
|
| |
| π<sub>idEstudiante, nombreFacultad</sub>(σ<sub>year(fechaNac) > 1980</sub>(Estudiantes ⨝ 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 ⨝ 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 ==== | | ==== 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>: σ<sub>region = reg<sub>i</sub></sub>(Universidades)
| |
| * Estudiantes<sub>i</sub>: π<sub>idEstudiante, nombreEstudiante, idFacultad, fechaNac</sub>(σ<sub>region = reg<sub>i</sub></sub>(Estudiantes ⨝ 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: ∪<sub>i=1->4</sub> Universidades<sub>i</sub>
| |
| * Estudiantes: ∪<sub>i=1->4</sub> Estudiantes<sub>i</sub>
| |
|
| |
|
| ==== Pregunta 8 ==== | | ==== 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.
| | ==== Pregunta 9 ==== |
| | |
| 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.
| | ==== Pregunta 10 ==== |