Database Systems Labs
Qué problema resuelve un gestor de bases de datos, qué hay dentro de él y cómo se monta un entorno donde cada afirmación pueda comprobarse.
4 clases · 12 horas · 19 conceptos · 11 fuentes
Esta parte se apoya en lo trabajado antes. Si vienes de fuera del programa, revisa al menos el vocabulario de:
La parte 00 mostró qué se hace con una base de datos. Esta pregunta por qué existe y qué hay dentro. Es la transición de usuario a persona que puede razonar sobre el sistema, y sin ella las partes 08 y 09 —transacciones y planes de ejecución— son magia con nombres técnicos.
Las cuatro clases responden a cuatro preguntas encadenadas. Qué garantiza un gestor y qué no, para no atribuirle poderes que no tiene. Qué componentes lo forman, del analizador al gestor de almacenamiento, para saber después en cuál vive cada problema. Por qué se separan tres niveles de esquema, que es la idea de Codd de la que depende toda la evolución del esquema sin caída. Y cómo se monta un entorno donde cada afirmación se pueda comprobar, que es el método de trabajo del resto del programa.
La clase 014 no es un anexo técnico: es la que define qué cuenta como evidencia en este programa. A partir de ella, ninguna afirmación de rendimiento se acepta sin comando, versión, semilla y salida.
| # | Clase | Nivel | Horas | Fuentes |
|---|---|---|---|---|
| 011 | Qué resuelve un sistema de bases de datos y qué no | Fundamentos | 3 | 4 |
| 012 | Arquitectura interna de un gestor, del cliente al disco | Fundamentos | 3 | 3 |
| 013 | Independencia de datos y los tres niveles de esquema | Fundamentos | 3 | 3 |
| 014 | Entorno reproducible y evidencia comprobable | Fundamentos | 3 | 4 |
La misma pregunta de la clase 002, ahora con el vocabulario de sistemas: qué garantiza un gestor —persistencia, concurrencia, integridad, recuperación— y, con la misma seriedad, qué no garantiza. La independencia de datos aparece aquí como la idea de Codd que ordena todo lo demás.
persistencia concurrencia integridad recuperación independencia de datos
El recorrido completo de una consulta desde el cliente hasta el disco: analizador, planificador, ejecutor, gestor de almacenamiento y buffer. Es el mapa mental que después permite leer un plan de ejecución sin adivinar, y saber en qué componente vive cada problema de rendimiento.
analizador planificador ejecutor gestor de almacenamiento buffer pool
Los tres niveles de esquema —externo, conceptual y físico— y por qué separarlos es lo que permite añadir un índice, particionar una tabla o dividir una entidad sin reescribir las aplicaciones. La independencia lógica que se define aquí es el fundamento técnico de las migraciones sin caída de la parte 11.
esquema conceptual esquema físico vista externa independencia lógica
El método de trabajo del resto del programa: entorno en contenedor con la versión fijada, datos generados con semilla declarada, invariantes escritos y evidencia que otra persona pueda reproducir. Es la clase que convierte «me funcionó» en un resultado defendible.
reproducibilidad semilla contenedor invariante evidencia
Cada uno de estos es una creencia habitual y su corrección.
Los 19 términos que esta parte introduce. Todos están también en el glosario del programa con sus términos relacionados.
| Término | Qué significa | Se trabaja en |
|---|---|---|
| analizador | Primer componente del gestor: convierte el texto SQL en un árbol sintáctico y comprueba que los objetos citados existen y que los tipos encajan. Aquí mueren los errores de sintaxis, antes de tocar un solo dato. (En la clase 041 la misma palabra nombra otra cosa: el analizador de texto que parte un documento en términos indexables.) | 012 |
| buffer pool | La memoria donde el motor mantiene las páginas leídas para no volver a pedirlas al disco. Su tasa de acierto explica la mayor parte de la diferencia entre una consulta de 2 ms y la misma consulta de 200 ms. | 012 |
| concurrencia | Varias sesiones leyendo y escribiendo a la vez sobre los mismos datos. Un archivo compartido no la resuelve: el último en guardar pisa al anterior. Un gestor la resuelve con transacciones, bloqueo o versiones. | 011 |
| contenedor | Entorno de ejecución aislado con el motor y su versión congelados. Elimina el «en mi máquina funciona» y convierte la versión del motor en parte de la evidencia, no en un detalle olvidado. | 014 |
| ejecutor | Recorre el plan elegido operador a operador y produce las filas. Es donde `EXPLAIN ANALYZE` muestra los tiempos reales frente a los que el planificador había estimado. | 012 |
| esquema conceptual | La descripción del qué: entidades, atributos y relaciones del dominio, sin decir cómo se guardan. Es el nivel en el que se discute con quien conoce el negocio. | 013 |
| esquema físico | Cómo se materializan realmente los datos: ficheros, páginas, índices, particiones, compresión. Debe poder cambiar —añadir un índice, particionar una tabla— sin que ninguna consulta se reescriba. | 013 |
| evidencia | La salida real de un comando, con su versión y sus parámetros, que respalda una afirmación. Una captura sin comando no es evidencia, porque no se puede repetir. | 014 |
| gestor de almacenamiento | La capa que traduce filas a páginas en disco y de vuelta, y que sostiene el registro, el buffer y las estructuras de índice. Es donde se decide si el motor es B-Tree o LSM, y con ello su perfil de lectura y escritura. | 012 |
| independencia de datos | Poder cambiar cómo se guardan los datos sin reescribir las aplicaciones que los consultan. Es la idea central del artículo de Codd de 1970 y la razón de que exista un nivel lógico separado del físico. | 011 |
| independencia lógica | Poder cambiar el esquema conceptual —dividir una tabla, renombrar una columna— sin romper las aplicaciones, apoyándose en vistas que preservan el contrato anterior. Es más difícil de lograr que la independencia física y es la base técnica de las migraciones sin caída. | 013 |
| integridad | Que los datos cumplan siempre las reglas del dominio, incluidas las que ninguna aplicación recordó comprobar. El gestor la sostiene con restricciones declaradas y con transacciones. | 011 |
| invariante | Algo que tiene que ser verdad siempre en el sistema: «ningún pedido sin cliente», «el saldo nunca es negativo». Un invariante que no está comprobado por una restricción o una prueba es un deseo. | 014 |
| persistencia | Que el dato siga existiendo cuando el proceso que lo escribió ya no está. Es el requisito mínimo de una base de datos y la única de sus funciones que un archivo también cumple. | 011 |
| planificador | Decide *cómo* ejecutar la consulta: qué índice usar, en qué orden reunir las tablas, con qué algoritmo. Elige por costo estimado a partir de estadísticas, no por el orden en que está escrita la consulta. | 012 |
| recuperación | Volver a un estado correcto después de una caída, descartando lo no confirmado y rehaciendo lo confirmado. Es lo que distingue una base de datos de un archivo que se corrompió a medio escribir. | 011 |
| reproducibilidad | Que otra persona, en otra máquina, obtenga el mismo resultado con las instrucciones dadas. Exige fijar versión del motor, datos de partida y semilla; sin eso, una medición es una anécdota. | 014 |
| semilla | El número que fija la secuencia de un generador pseudoaleatorio. Declararla convierte un conjunto de datos «aleatorio» en uno reproducible, que es la condición para poder comparar dos ejecuciones. | 014 |
| vista externa | La porción del esquema que ve cada aplicación o cada rol, normalmente mediante vistas. Permite dar acceso a lo necesario y solo a eso, y absorber cambios del esquema sin romper a quien consulta. | 013 |
11 obras distintas sostienen lo que se afirma en estas 4 clases.