| Revisión actual |
Tu texto |
| Línea 1: |
Línea 1: |
| {{Back|Bases de Datos}}
| | == Preguntas == |
| | |
| = Preguntas = | |
| Se aprueba con 14.5 de 23.5 puntos | | Se aprueba con 14.5 de 23.5 puntos |
|
| |
|
| Línea 18: |
Línea 16: |
| # Indique tres usos que la Base de Datos le da al System Catalog (1.5 puntos) | | # Indique tres usos que la Base de Datos le da al System Catalog (1.5 puntos) |
|
| |
|
| = Respuestas = | | == Respuestas == |
| # Isolation.
| |
| # Serial vs Serializable:
| |
| #* Serial: {R1(A),W1(A),R1(B),W1(B),R2(A),W2(A)}
| |
| #* Serializable: {R1(A),W1(A),R1(B),R2(A),W1(B),W2(A)}
| |
| # El problema del lost update ocurre cuando una transacción lee un valor (por ejemplo para incrementarlo en uno) y antes de que pueda escribirlo, otra transacción lo modifica. La primer transacción, sin darse cuenta que el valor cambió, le escribe el valor nuevo, "sobreescribiendo" lo escrito por la segunda transacción. El lockeo binario impide que dos transacciones accedan al mismo objeto en una tabla al mismo momento. Luego, si la primer transacción pide un lock del objeto, la segunda no tiene la posibilidad de leerlo y sobreescribirlo hasta que la primera termine (satisfactoriamente o no) y libere el lock.
| |
| # Cuando sus clausuras transitivas son el mismo conjunto. Equivalentemente, cuando ambas se fuerzan mutuamente.
| |
| # {codigoDepto,nroAmbiente,codigoBarrio,descripcionBarrio,largoAmbiente,anchoAmbiente}
| |
| #* Transitiva: codigoDepto => codigoBarrio => descripcionBarrio
| |
| #* Parcial: nroAmbiente,codigoBarrio => descripcionBarrio
| |
| #* Total: codigoBarrio => descripcionBarrio
| |
| #* Clave: codigoDepto
| |
| # La operación de proyección de álgebra relacional permite filtrar atributos de interés de una relación. Por ejemplo π(edad) ({codEmpleado, nombre, apellido, edad}) contiene el conjunto de todas las edades SIN REPETIR. Se traduce como un select, aunque este si admite repetidos. O sea se traduce en realidad como un SELECT DISTINCT.
| |
| # Dos partes:
| |
| #* El optimizador de consultas es el encargado de recibir una query en lenguaje SQL y armar un plan de ejecución eficiente (aunque no necesariamente el más eficiente) para obtener los datos requeridos. Para eso utiliza el catalog.
| |
| #* El recovery manager es el encargado de restaurar la base de datos a un estado consistente en caso de falla. Para eso utiliza el log.
| |
| # Dos heurísticas que usa el optimizador de consultas:
| |
| #* Bajar las selecciones lo más cerca de las hojas posible: de esta forma se reduce la cantidad de tuplas a reescribir a archivos intermedios (particularmente problemático a la hora de hacer joins o productos cartesianos)
| |
| #* Evitar los productos cartesianos: para eso se reemplazan los productos cartesianos seguidos de selecciones por joins.
| |
| # Permisos de usuarios:
| |
| #* DROP: permite al usuario dropear tablas.
| |
| #* CREATE: permite al usuario crear tablas
| |
| # Para que una transacción tenga que se re-hecha, debe haber hecho commit antes del end checkpoint:
| |
| #*<StartCKPT>
| |
| #*<T1, A, 10>
| |
| #*<Commit T1>
| |
| #*CRASSSSSHHHHHHHHH
| |
| # Se guardan
| |
| #* Esquema de la tabla.
| |
| #* Selectividad aproximada de los atributos.
| |
| #* Permisos de la tabla
| |
| # Un algoritmo de aprendizaje supervisado es un algoritmo de machine learning que utiliza un set de entrenamiento etiquetado (pares <entrada, respuesta>) con el objetivo de inferir una función que se usa posteriormente para predecir el resultado de entradas no conocidas a priori. Ejemplo: árboles de decisión. (Los nodos internos son preguntas sobre los atributos, las hojas representan las etiquetas o clases resultantes)
| |
| # Usos del system catalog:
| |
| #* Obtener el esquema de una tabla a la hora de verificar una query.
| |
| #* Obtener la selectividad esperada de un atributo a la hora de optimizar una query.
| |
| #* Obtener una vista para resolverla si esta es usada en una query.
| |
| #* Obtener los permisos de un usuario a la hora de verificar un acceso.
| |
