Final del 30/07/13 (Bases de Datos)

Preguntas

1. Defina detalladamente el problema de la falsa sumarizacion (2 puntos)
2. Defina equivalencia de dos transaccions (1? punto)
3. Dada la siguiente relación {NROPEDIDO; CODART, NOMART, CANTPEDIDA, PRECIO, CODEMP. NOMEMP., FECHA}. Indicar :
   1. Una dependencia funcional completa
   2. Una dependencia funcional parcial.
   3. Una dependencia funcional transitiva.( 1.5 puntos)
4. ¿Que es un plan de ejecucion?(1)
5. Defina super clave y cual es la diferencia con la clave candidata(?)
6. De dos restricciones que modelen cosas del mundo real que haya en el modelo de entidad relacion y como se implementan en la base (2 puntos)
7. Defina lo que es un select en algebra relacional y de 2 propiedades (1? puntos)
8. Algo con GRANT (1 punto)
9. ¿Cómo se recupera la BD con undo/redo?(2 puntos)
10. Instruccion para actualizar el catalog(1 punto)
11. 2 operaciones que se realice(o haga, no me acuerdo bien la palabra) el DW ( algo asi era la pregunta, no me la acuerdo bien, yo lo defini lo que era un DW y para que se usaba y me puso 0/2 puntos)(2 puntos)
12. ¿Por qué el DBA tiene que conocer el crecimiento de la base?(1 punto)

Respuestas

1. El problema de la falsa sumarizacion consiste en tener una consulta que sumariza registros (ej: SUM) y en el medio se produce un UPDATE sobre los registros sumarizados. Luego, el resultado de la consulta no va a corresponder con la sumarizacion antes ni despues de la modificación a la tabla, es decir, es inconsistente.
2. Se refiere a las historias de las transacciones. Es decir, las historias son equivalentes cuando estan ambas definidas sobre el mismo conjunto de transacciones y cuando dos operaciones conflictivas tienen el mismo orden (Ti<Tj) y operan sobre un mismo registro y al menos una de ellas es una escritura.
3. Dependencias:
   1. DF Completa: NROPEDIDO -> FECHA
   2. DF Parcial: NROPEDIDO,CODART -> NOMART (donde CODART -> NOMART)
   3. DF Transitiva: NROPEDIDO -> CODEMP y CODEMP-> NOMEMP => NROPEDIDO => NOMEMP
4. Un plan de ejecucion es la estrategia que genera el motor de bases de datos para resolver una consulta. Este plan incluye las proyecciones, las selecciones y las uniones que se van a hacer en cada tabla involucrada en la consulta. Adicionalmente, se definen las estrategias para resolver cada subarbol mediante heuristicas basadas en las estadisticas de uso de las tablas (el tipo de join, donde llevar las proyecciones y selecciones, pipelining, etc.)
5. Una superclave es un conjunto de atributos que su clausura transitiva funcional da como resultado el total de la relacion. Una clave candidata es una superclave tal que ningun subconjunto de ella es superclave.
6. Una persona puede hablar muchos idiomas. Es una relacion 1:N entre "Personas" e "Idiomas". Se modela con una tabla HABLA(id_Persona, Idioma). Un profesor tiene muchos alumnos y un alumno tiene muchos profesores. Es una relacion N:M entre "Alumnos" y "Profesores". Se modela con tres tablas: "Alumnos", "Profesores", "Comparten_Clase", donde "Comparten_Clase"(id_Alumno, id_Profesor).
7. Un select en el algebra relacional es una operacion que aplica un predicado a todas las tuplas, y devuelve las tuplas que lo cumplan. Sigma_1(Sigma_2(X)) = Sigma_2(Sigma_1(X)) y Sigma_1(Sigma_2(X)) = Sigma_(1 ^ 2)(X)
8. GRANT es la palabra clave en SQL que se usa para administrar los permisos de un usuario sobre un objeto de la base. Por ejemplo, a algunas tablas se les puede dar READ ONLY para la mayoria de empleados y READWRITE solo para los encargados de modificarlas. Algunos StoredProcedures pueden ser EXECUTEd solo por los DBA y nadie mas deberia poder leerlos siquiera.
9. La base de datos se recupera de manera distinta con undo que con redo. Con UNDO, se tienen que deshacer unicamente las transacciones no finalizadas (las que no tienen ni COMMIT ni ABORT). Se va de la ultima operacion de transaccion hacia el comienzo, deshaciendo paso a paso, y al final se agrega un ABORt y se flushea. Con REDO se tiene que rehacer unicamente las transacciones COMMITEADAS. Se va desde el comienzo del log file y se rehacen todas las operaciones de todas las transacciones que tengan commit. Para las incompletas se agrega un ABORT y se flushea.
10. Para actualizar el catalog, se puede hacer UPDATE STATISTICS, pero en la gran mayoria de los casos, los operadores de la base de datos no deberian tocar las estadisticas porque pueden arruinar la performance de la base de datos enteras. Son mecanismos que se autoajustan y no se deben hacer cambios sin realmente analizarlo con los DBA.
11. Un Datawarehouse debe poder realizar operaciones para obtener la informacion precisa que necesita el operario. Dos de las mas comunes son ROLL UP y DRILL DOWN, que sirven para visualizar en mayor o menor detalle algunas dimensiones. Por ejemplo, dadas las ventas por provinca, se puede hacer DRILL DOWN para separar las ventas por local se vendio mas o se puede hacer ROLL UP para agregar todas las ventas de un pais y asi poder comparar distintos paises.
12. El DBA debe saber todo lo posible sobre el crecimiento de la base para poder definir correctamente cosas como los parametros de crecimiento por tabla (si crecer de a bloques de 1MB o de a bloques de 1GB), las politicas de backup correctas (si hacer muchos o pocos por dia, cada cuanto hacer un full dump). Debe saber tambien el crecimiento en cantidad de usuarios posibles, para poder hacer un correcto control de privilegios.