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 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 156: Línea 147:


==== 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”
&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 ====
==== 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 ====
==== 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 ====
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)