Revisión actual |
Tu texto |
Línea 191: |
Línea 191: |
|
| |
|
| ==== 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.
| |
|
| |
| 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.
| |