Glosario

Los términos del curso con una definición breve, ordenados por parte del curso. Siguen la regla de la guía de estilo:

La mayoría de los términos técnicos se dicen en inglés, como los usan los programadores y los administradores de bases de datos, y como aparecen en la documentación de PostgreSQL y en los mensajes de error (join, buffer pool, commit, lock). Esas entradas están en inglés y se explican en español.
Los que de verdad se usan en español (tabla, consulta, clave primaria, índice, transacción) van en español, con el término en inglés entre paréntesis.

Las definiciones siguen la terminología de Silberschatz, Korth y Sudarshan, Database System Concepts (7.ª ed.). Cuando PostgreSQL hace algo distinto, se indica.

Herramientas

Término	Definición
Sistema de gestión de bases de datos (database management system, DBMS)	El software que guarda una o varias bases de datos y da acceso a ellas: ejecuta consultas, controla el acceso concurrente y recupera los datos después de un fallo.
PostgreSQL	El DBMS relacional de código abierto que usamos en el curso (versión 18). Su documentación oficial es la referencia del dialecto SQL del curso.
psql	El cliente de línea de comandos de PostgreSQL. Además de SQL acepta metacomandos que empiezan con `\` (`\d`, `\dt`, `\i archivo.sql`, `\timing`).
Contenedor (container)	Un proceso aislado que corre a partir de una imagen de Docker con su propio sistema de archivos; el del curso trae PostgreSQL 18, `psql` y Node.js 26.
Volumen de Docker (Docker volume)	Un espacio de almacenamiento que Docker administra fuera del contenedor. Ahí vive el directorio de datos de PostgreSQL, así que los datos sobreviven al borrar o recrear el contenedor.
driver	La biblioteca que habla el protocolo de red del DBMS y le permite a un programa enviar consultas y recibir resultados.
pg (node-postgres)	El driver de PostgreSQL para Node.js que usamos. Ofrece `Client` (una conexión) y `Pool` (un connection pool).
connection pool	Un conjunto de conexiones abiertas que la aplicación presta y reutiliza, porque abrir una conexión por consulta es caro. En `pg`, una transacción debe usar un solo cliente (`pool.connect()`), porque dos llamadas a `pool.query` pueden ir por conexiones distintas.
Migración (migration)	Un script versionado que cambia el esquema de la base de datos (crear una tabla, agregar una columna) y que se aplica en orden, una sola vez.
seed	Un script que carga datos de ejemplo o iniciales en una base de datos recién creada.
`node:test`	El runner de pruebas que trae Node.js; junto con `node:assert/strict` es el que usa `make test`.

Parte 1 — Modelo relacional y SQL

Término	Definición
Relación (relation)	En el modelo relacional, un conjunto de tuplas sobre un esquema; en SQL corresponde a una tabla. No confundir con la relación del modelo E-R (relationship).
Tupla (tuple)	Un elemento de una relación: un valor para cada atributo. En SQL corresponde a una fila.
Atributo (attribute)	Un nombre de columna de una relación, con su dominio.
Dominio (domain)	El conjunto de valores permitidos para un atributo. Es atómico si sus valores no se dividen en partes que el modelo use por separado.
Tabla, fila, columna (table, row, column)	Los nombres de SQL para relación, tupla y atributo. A diferencia de una relación, una tabla de SQL puede tener filas repetidas (es un multiconjunto).
Esquema, instancia (schema, instance)	El esquema es la estructura lógica (relaciones, atributos, dominios, restricciones); la instancia es el contenido en un momento dado. En PostgreSQL, schema es además un namespace dentro de una base de datos (`public`).
DDL / DML	Data definition language (`CREATE TABLE`, `ALTER TABLE`, `DROP`) define el esquema; data manipulation language (`SELECT`, `INSERT`, `UPDATE`, `DELETE`) consulta y modifica los datos.
Superclave (superkey)	Conjunto de uno o más atributos cuyos valores identifican una sola tupla en cualquier instancia válida de la relación. Todo superconjunto de una superclave también lo es.
Clave candidata (candidate key)	Una superclave minimal: ninguno de sus subconjuntos propios es superclave. Una relación puede tener varias.
Clave primaria (primary key)	La clave candidata que el diseñador elige como forma principal de identificar las tuplas. En SQL, `PRIMARY KEY` implica `UNIQUE` y `NOT NULL`.
Clave foránea (foreign key)	Conjunto de atributos de una relación r1 cuyos valores, en cada tupla, deben aparecer en la clave primaria (o en columnas `UNIQUE`) de una relación r2.
Integridad referencial (referential integrity)	La condición de que todo valor no nulo de una clave foránea exista en la relación referenciada. Se mantiene con `ON DELETE` / `ON UPDATE` (`RESTRICT`, `CASCADE`, `SET NULL`).
Restricción (constraint)	Una condición que la base de datos debe cumplir siempre y que el DBMS verifica en cada modificación: `NOT NULL`, `UNIQUE`, `CHECK`, `PRIMARY KEY`, `FOREIGN KEY`.
`NULL`	Marca de valor desconocido o inexistente. SQL usa una lógica de tres valores: una comparación con `NULL` da `unknown`, y `WHERE` solo conserva las filas cuya condición da `true`; por eso se pregunta con `IS NULL`.
Álgebra relacional (relational algebra)	Lenguaje formal de consultas cuyas operaciones (σ, Π, ×, ⋈, ∪, −, ρ) reciben relaciones y devuelven una relación, así que se pueden componer.
Selección (selection)	La operación σ_P(r): devuelve las tuplas de r que cumplen el predicado P. Corresponde al `WHERE` de SQL, no al `SELECT`.
Proyección (projection)	La operación Π_A(r): devuelve solo los atributos A de cada tupla, sin repetidos. Corresponde a la lista del `SELECT` (con `DISTINCT`).
Producto cartesiano (Cartesian product)	La operación r × s: combina cada tupla de r con cada tupla de s; en SQL, `CROSS JOIN` o varias tablas en el `FROM`.
join	Combinar tuplas de dos relaciones que cumplen una condición: r ⋈_θ s = σ_θ(r × s). Se dice hacer un join; un self join es el join de una tabla consigo misma con dos alias.
natural join	Join que iguala todos los atributos con el mismo nombre en las dos relaciones y deja una sola copia de cada uno. Es frágil: agregar una columna con un nombre repetido cambia el resultado.
inner join / outer join	Un inner join devuelve solo los pares que cumplen la condición; un outer join (left, right, full) agrega además las tuplas sin pareja de un lado o de ambos, completadas con `NULL`.
Subconsulta (subquery)	Un `SELECT` dentro de otra sentencia: en el `WHERE` (con `IN`, `EXISTS`, `ANY`, `ALL`), en el `FROM` o como valor escalar.
Subconsulta correlacionada (correlated subquery)	Subconsulta que usa atributos de la consulta externa; conceptualmente se evalúa una vez por cada fila externa.
Agregación (aggregation)	Calcular un valor a partir de un conjunto de filas: `count`, `sum`, `avg`, `min`, `max`. Salvo `count(*)`, las funciones de agregación ignoran los `NULL`.
Agrupamiento (grouping)	Dividir las filas en grupos con el mismo valor de las columnas del `GROUP BY` y calcular una agregación por grupo. `WHERE` filtra filas antes de agrupar; `HAVING` filtra grupos.
Vista (view)	Una consulta guardada con nombre que se usa como una tabla; su resultado se calcula cada vez que se consulta.
Vista materializada (materialized view)	Una vista cuyo resultado se guarda en disco. En PostgreSQL no se actualiza sola: hay que ejecutar `REFRESH MATERIALIZED VIEW`.
CTE	Common table expression: una subconsulta con nombre definida con `WITH` antes de la consulta principal. Con `WITH RECURSIVE` permite consultas recursivas, como recorrer una red de rutas.
window function	Función que calcula un valor para cada fila a partir de un conjunto de filas relacionadas (su ventana, definida con `OVER (PARTITION BY ... ORDER BY ...)`), sin juntarlas en una como `GROUP BY`. También se dice función de ventana.
stored procedure	Código guardado y ejecutado en el servidor. En PostgreSQL hay funciones (`CREATE FUNCTION`, devuelven un valor) y procedimientos (`CREATE PROCEDURE`, se llaman con `CALL` y pueden hacer commit); se escriben en SQL o en PL/pgSQL.
trigger	Una acción que el DBMS ejecuta automáticamente antes o después de un `INSERT`, `UPDATE` o `DELETE` sobre una tabla, por fila o por sentencia.
prepared statement	Una sentencia que el servidor analiza una vez, con parámetros (`$1`, `$2`), y que se ejecuta después con distintos valores.
Consulta parametrizada (parameterized query)	Una consulta en la que los valores del usuario se envían aparte del texto SQL, como parámetros, así que el servidor nunca los interpreta como SQL.
Inyección SQL (SQL injection)	Ataque en el que un texto del usuario, concatenado en una consulta, cambia su significado (`' OR '1'='1`). Se evita con consultas parametrizadas.

Parte 2 — Diseño de bases de datos

Término	Definición
Modelo entidad-relación (entity-relationship model, E-R)	Modelo para el diseño conceptual que describe el dominio con conjuntos de entidades, conjuntos de relaciones y atributos, y se dibuja en un diagrama E-R.
Entidad (entity)	Un objeto del mundo que se distingue de los demás: una agencia, un envío, un cliente.
Conjunto de entidades (entity set)	Las entidades del mismo tipo, con los mismos atributos; en el diagrama, un rectángulo.
Relación (relationship)	En el modelo E-R, una asociación entre varias entidades (un cliente envía un paquete). No confundir con la relación del modelo relacional, que es una tabla.
Conjunto de relaciones (relationship set)	Las relaciones del mismo tipo entre los mismos conjuntos de entidades; en el diagrama, un rombo. Puede tener atributos propios.
Cardinalidad (cardinality)	En E-R, con cuántas entidades de un conjunto se puede asociar una entidad del otro: uno a uno, uno a muchos, muchos a uno o muchos a muchos. En la parte 3, la cardinalidad de una relación es su número de tuplas.
Entidad débil (weak entity)	Entidad que no tiene atributos suficientes para formar una clave propia y se identifica por su relación con una entidad fuerte más un discriminador (por ejemplo, el número de paquete dentro de un envío).
Especialización (specialization)	Definir subgrupos de un conjunto de entidades con atributos o relaciones propias (un cliente es persona o empresa); se diseña de arriba hacia abajo.
Generalización (generalization)	El proceso inverso: juntar conjuntos de entidades que comparten atributos en uno más general; se diseña de abajo hacia arriba.
Agregación (aggregation)	En E-R, tratar un conjunto de relaciones como si fuera un conjunto de entidades para que participe en otra relación. No confundir con la agregación de SQL.
Redundancia (redundancy)	Guardar el mismo dato en varios lugares. Produce anomalías: al actualizar una sola copia, al insertar sin poder representar un hecho y al borrar perdiendo otro.
Dependencia funcional (functional dependency)	α → β se cumple en un esquema R si, en toda instancia válida de R, dos tuplas que coinciden en α coinciden también en β. Es trivial si β ⊆ α.
Axiomas de Armstrong (Armstrong’s axioms)	Reflexividad, aumentación y transitividad: reglas correctas y completas para deducir todas las dependencias funcionales que se siguen de un conjunto F, y solo esas.
Clausura (closure)	F⁺ es el conjunto de todas las dependencias que se deducen de F. La clausura de un conjunto de atributos, α⁺, son todos los atributos que α determina; α es superclave de R si α⁺ = R.
Cubierta canónica (canonical cover)	Un conjunto Fc con la misma clausura que F en el que ninguna dependencia tiene atributos extraños (que se puedan quitar sin cambiar F⁺) y no hay dos dependencias con el mismo lado izquierdo.
Descomposición (decomposition)	Reemplazar un esquema R por esquemas R1, …, Rn cuya unión de atributos es R.
Descomposición sin pérdida (lossless decomposition)	Una descomposición en la que, para toda instancia válida r, el natural join de las proyecciones devuelve exactamente r, sin tuplas espurias. R1, R2 es sin pérdida si R1 ∩ R2 → R1 o R1 ∩ R2 → R2 está en F⁺.
Descomposición que preserva dependencias (dependency-preserving decomposition)	Una descomposición en la que la unión de las restricciones de F⁺ a cada Ri tiene la misma clausura que F; así cada dependencia se verifica dentro de una sola tabla, sin joins.
Normalización (normalization)	Descomponer un esquema sin pérdida hasta que cumpla una forma normal (1NF, 3NF, BCNF, 4NF), que limita la redundancia que puede tener.
1NF	Primera forma normal: todos los dominios son atómicos.
BCNF	Forma normal de Boyce-Codd: R está en BCNF respecto de F si para toda dependencia α → β de F⁺ con α, β ⊆ R, o es trivial o α es superclave de R. Siempre se llega a BCNF sin pérdida, pero no siempre preservando dependencias.
3NF	Tercera forma normal: como BCNF, pero también se acepta α → β si cada atributo de β − α está en alguna clave candidata de R (no necesariamente la misma). Siempre existe una descomposición en 3NF sin pérdida y que preserva dependencias.
Dependencia multivaluada (multivalued dependency)	α →→ β se cumple si, para cada valor de α, el conjunto de valores de β no depende de los valores del resto de los atributos. Toda dependencia funcional es también multivaluada.
4NF	Cuarta forma normal: para toda dependencia multivaluada no trivial α →→ β de D⁺, α es superclave. Todo esquema en 4NF está en BCNF.
`jsonb`	El tipo de PostgreSQL que guarda datos semiestructurados (JSON) en un formato binario ya analizado: sin espacios ni claves repetidas, más rápido de consultar que `json` y con soporte de índices GIN.
GIN	Generalized inverted index: índice de PostgreSQL que, para cada elemento (una clave de `jsonb`, una palabra, un valor de un arreglo), guarda la lista de filas que lo contienen. Sirve para consultas de contención (`@>`).

Parte 3 — Almacenamiento, índices y consultas

Término	Definición
Página (page)	La unidad en la que el DBMS organiza sus archivos y transfiere datos entre el disco y la memoria (un bloque). En PostgreSQL mide 8 KB. El costo de una operación se mide sobre todo en páginas leídas y escritas.
Registro (record)	La representación física de una tupla dentro de una página: una cabecera más los valores de los atributos, de longitud fija o variable.
slotted page	Organización de una página con una cabecera, un arreglo de slots (desplazamiento y tamaño de cada registro) y los registros al final. Un registro se puede mover dentro de la página sin cambiar su record id.
record id (RID)	El identificador físico de un registro: (número de página, número de slot). En PostgreSQL se llama tuple id y se ve en la columna `ctid`.
heap file	Un archivo cuyos registros no siguen ningún orden: cada uno va en cualquier página con espacio libre, que se encuentra con el free space map. Las tablas de PostgreSQL son heap files.
row store / column store	Un row store guarda juntos todos los atributos de una fila (bueno para transacciones); un column store guarda junta cada columna (bueno para análisis que leen pocas columnas de muchas filas).
buffer pool	La zona de memoria, dividida en marcos (frames) del tamaño de una página, donde el DBMS guarda copias de las páginas del disco. En PostgreSQL, su tamaño es `shared_buffers`.
buffer manager	El componente que atiende los pedidos de páginas: si la página está en el buffer pool la devuelve; si no, elige un marco sin pin con la política de reemplazo, escribe la página anterior si está sucia y lee la nueva.
Página sucia (dirty page)	Una página del buffer pool modificada que todavía no se escribió en el disco.
Política de reemplazo (replacement policy)	La regla con la que el buffer manager elige qué página sacar: LRU, clock (una aproximación de LRU con un bit de referencia) u otras. PostgreSQL usa un clock sweep con contador de uso y anillos de buffers para los scans grandes.
Índice (index)	Una estructura auxiliar que, dado un valor de la clave de búsqueda, encuentra las filas que lo tienen sin leer toda la tabla.
Clave de búsqueda (search key)	El atributo o conjunto de atributos por el que se busca en un índice. No tiene que ser una clave de la relación; en un índice de varias columnas, el orden es primero por la primera.
Índice denso / disperso (dense / sparse index)	Un índice denso tiene una entrada por cada valor de la clave de búsqueda; uno disperso, solo para algunos, y solo es posible si el archivo está ordenado por esa clave.
clustered index	Índice cuya clave de búsqueda define el orden físico del archivo (Silberschatz lo llama clustering index o índice primario); un archivo tiene a lo más uno. PostgreSQL no mantiene ese orden: `CLUSTER` reordena la tabla una vez y las inserciones posteriores no lo respetan.
Índice secundario (secondary index)	Índice cuya clave de búsqueda no coincide con el orden del archivo (nonclustering). Es siempre denso, y leer muchas filas por él cuesta un acceso aleatorio por fila.
B+ tree	Árbol balanceado: todas las hojas están a la misma profundidad, cada nodo salvo la raíz está al menos a la mitad y las hojas, enlazadas, guardan las entradas en orden. Busca e inserta en O(log n) lecturas, permite consultas por rango y crece con splits que suben hasta la raíz. El índice B-tree de PostgreSQL es una variante.
fan-out	El número de hijos de un nodo interno de un árbol. Con un fan-out de cientos, un B+ tree de tres o cuatro niveles alcanza millones de filas.
hash table	Estructura que aplica una función de hash a la clave para elegir un bucket. Responde búsquedas por igualdad en tiempo casi constante, pero no sirve para rangos.
bucket	En un índice hash, la unidad de almacenamiento (una o más páginas) donde van las entradas con el mismo valor de hash; si se llena, se encadenan páginas de overflow.
extendable hashing	Hashing dinámico con un directorio de 2^i punteros que usa i bits del hash (profundidad global). Al llenarse un bucket se divide solo ese, y el directorio se duplica solo si la profundidad local del bucket es igual a la global.
LSM tree	Log-structured merge tree: las escrituras van a una estructura en memoria (memtable) que se vuelca al disco como archivos ordenados e inmutables, y estos se fusionan en segundo plano (compaction). Escribe rápido a cambio de lecturas que revisan varios niveles, ayudadas por bloom filters.
sequential scan	Leer una tabla completa, página por página. En PostgreSQL aparece como `Seq Scan`.
index scan	Recorrer un índice para encontrar las filas que cumplen la condición y leer cada una en la tabla.
index-only scan	Responder una consulta solo con el índice, sin leer el heap; necesita un covering index, que contenga todas las columnas de la consulta como columnas de la clave o con `INCLUDE`. En PostgreSQL solo se evita el heap en las páginas que el visibility map marca como visibles para todos.
bitmap scan	En PostgreSQL, recorrer uno o varios índices para armar un mapa de bits de las páginas que tienen filas candidatas y leer después esas páginas en orden físico.
query plan	Un árbol de operadores físicos (scans, joins, ordenamientos) que dice exactamente cómo evaluar una consulta. También se dice plan de ejecución.
iterator	Un operador del plan con la interfaz `open`, `next` y `close`: cada llamada a `next` pide tuplas a sus hijos y devuelve la siguiente tupla del resultado.
pipeline	Pasar cada tupla de un operador al siguiente sin escribir el resultado intermedio. Lo contrario es la materialización, en la que cada operador guarda su resultado completo antes de que el siguiente lo lea.
external sort	Ordenar datos que no caben en memoria: con M bloques de memoria, primero se crean runs ordenados de M bloques y después se fusionan de M − 1 en M − 1 hasta que queda uno.
nested loop join	Para cada tupla de la relación externa, recorrer toda la interna. Sirve para cualquier condición; en el peor caso cuesta n_r · b_s + b_r transferencias de bloques. En un index nested loop join, la interna se recorre con un índice.
block nested loop join	Variante que recorre la relación interna una vez por cada bloque (o grupo de bloques) de la externa en lugar de una vez por tupla; en el peor caso cuesta b_r · b_s + b_r.
sort-merge join	Ordenar las dos relaciones por los atributos del join y recorrerlas a la vez, juntando las tuplas iguales. Solo para equi-joins y natural joins.
hash join	Construir una hash table con la relación más pequeña (build) y recorrer la otra buscando cada tupla en ella (probe). Solo para equi-joins; si la tabla no cabe en memoria, ambas relaciones se particionan antes con la misma función de hash.
query optimizer	El componente que, entre los planes equivalentes de una consulta, elige el de menor costo estimado. El de System R elige el orden de los joins con programación dinámica.
cost model	La fórmula que usa el optimizador para estimar el costo de un plan a partir de las estadísticas: páginas leídas, accesos aleatorios, tuplas procesadas. En PostgreSQL se ajusta con `seq_page_cost`, `random_page_cost` y otros.
cardinality estimation	Estimar cuántas tuplas producirá cada operador del plan. Es la principal fuente de errores del optimizador, porque los errores se multiplican de un join al siguiente.
selectivity	La fracción de las tuplas de una relación que cumple un predicado. Sin más información, el optimizador supone que los predicados son independientes y multiplica sus selectividades.
histogram	Estadística que divide el rango de valores de una columna en intervalos y guarda cuántos valores caen en cada uno. PostgreSQL usa histogramas de igual frecuencia más una lista de valores más comunes.
Estadísticas (statistics)	Lo que el DBMS sabe de cada tabla para estimar costos: número de filas y páginas, valores distintos, valores más comunes, histogramas. En PostgreSQL las calcula `ANALYZE` y se ven en `pg_stats`.
`EXPLAIN`	El comando de PostgreSQL que muestra el plan elegido con sus costos y filas estimadas; `EXPLAIN ANALYZE` además lo ejecuta y muestra el tiempo y las filas reales de cada nodo.

Parte 4 — Transacciones y sistemas distribuidos

Término	Definición
Transacción (transaction)	Una secuencia de operaciones que el DBMS trata como una unidad lógica de trabajo: termina con commit (todos sus efectos quedan) o con abort (ninguno queda).
ACID	Atomicidad (todo o nada), consistencia (una transacción sola deja la base consistente), aislamiento (cada una se comporta como si estuviera sola) y durabilidad (lo confirmado sobrevive a los fallos). Atomicidad y durabilidad las da la recuperación; aislamiento, el control de concurrencia.
commit	Terminar una transacción haciendo permanentes sus cambios. Se dice hacer commit; la sentencia es `COMMIT`.
rollback	Deshacer los cambios de una transacción que aborta, por pedido propio o porque el DBMS la cancela (deadlock, error de serialización). Se dice hacer rollback; la sentencia es `ROLLBACK`.
savepoint	Un punto marcado dentro de una transacción al que se puede volver con `ROLLBACK TO SAVEPOINT` sin abortar la transacción entera.
schedule	El orden en el tiempo de las operaciones (lecturas, escrituras, commits) de varias transacciones concurrentes. Es serial si las transacciones se ejecutan una tras otra, sin intercalarse.
Serializabilidad (serializability)	Un schedule es serializable si su efecto es equivalente al de algún schedule serial de las mismas transacciones.
Operaciones en conflicto (conflicting operations)	Dos operaciones de transacciones distintas sobre el mismo ítem en las que al menos una es una escritura. Su orden no se puede cambiar sin cambiar el resultado.
conflict serializability	Un schedule es conflict serializable si se puede transformar en uno serial intercambiando operaciones consecutivas que no están en conflicto. Equivale a que su grafo de precedencia (arista Ti → Tj si una operación de Ti está en conflicto con una posterior de Tj) no tenga ciclos.
Schedule recuperable (recoverable schedule)	Si Tj lee un dato escrito por Ti, Ti hace commit antes que Tj. Si no, un abort de Ti dejaría a Tj confirmada con un dato que nunca existió.
cascadeless	Un schedule es cascadeless si cada transacción solo lee datos escritos por transacciones que ya hicieron commit; así el abort de una nunca provoca un rollback en cascada (cascading rollback) de las que leyeron sus datos. Todo schedule cascadeless es recuperable.
dirty read	Leer un dato escrito por una transacción que todavía no hizo commit.
non-repeatable read	Una transacción lee dos veces la misma fila y obtiene valores distintos, porque otra transacción la modificó y confirmó en medio.
phantom	Una transacción lee las filas que cumplen un predicado y otra inserta o borra una fila que también lo cumple; si la primera repite la lectura, el conjunto cambia. El conflicto es sobre el predicado, no sobre una fila existente, así que no se evita con locks de fila sino con predicate locks o index locking. También se dice fantasma.
lost update	Dos transacciones leen el mismo valor, cada una calcula un valor nuevo y lo escribe; la segunda escritura borra la primera como si nunca hubiera ocurrido.
write skew	Dos transacciones concurrentes leen datos que se solapan y cada una escribe un ítem distinto según lo que leyó; juntas violan una restricción que ninguna viola sola. No hay conflicto de escritura, así que snapshot isolation no lo detecta.
Nivel de aislamiento (isolation level)	Cuánta interferencia entre transacciones se acepta. SQL define `READ UNCOMMITTED`, `READ COMMITTED`, `REPEATABLE READ` y `SERIALIZABLE` según qué anomalías permite cada uno. PostgreSQL usa `READ COMMITTED` por defecto y no permite dirty reads en ningún nivel.
Control de concurrencia (concurrency control)	Los mecanismos del DBMS que restringen el intercalado de las transacciones para que los schedules sean serializables (o cumplan el nivel de aislamiento elegido) y recuperables.
lock	Un permiso que una transacción obtiene sobre un ítem antes de usarlo. Un shared lock (S) permite leer y es compatible con otros S; un exclusive lock (X) permite escribir y no es compatible con ningún otro. Si el lock pedido no es compatible, la transacción espera.
two-phase locking (2PL)	Protocolo en el que cada transacción tiene una fase de crecimiento (solo obtiene locks) y una de contracción (solo los libera). Garantiza conflict serializability, pero no evita deadlocks ni rollbacks en cascada.
strict 2PL	2PL en el que además la transacción guarda todos sus exclusive locks hasta el commit o el abort, así que los schedules son cascadeless. Rigorous 2PL guarda todos los locks, no solo los exclusivos, hasta el final.
deadlock	Un conjunto de transacciones en el que cada una espera un lock que tiene otra del mismo conjunto, así que ninguna puede avanzar. Se rompe abortando una víctima.
waits-for graph	Grafo con una arista Ti → Tj si Ti espera un lock que tiene Tj. Hay deadlock si y solo si el grafo tiene un ciclo.
wait-die / wound-wait	Esquemas de prevención de deadlocks con timestamps. En wait-die, si la que pide el lock es más antigua que la que lo tiene, espera; si es más joven, aborta. En wound-wait, si la que pide es más antigua, aborta a la más joven que tiene el lock; si es más joven, espera.
Lock de intención (intention lock)	En granularidad múltiple (base, tabla, página, fila), un lock IS, IX o SIX sobre un nodo indica que la transacción tiene o pedirá locks S o X más abajo, así que se puede decidir un lock de tabla sin revisar cada fila.
MVCC	Multiversion concurrency control: cada escritura crea una versión nueva del ítem y cada lectura ve la versión adecuada para su transacción, así que los lectores no bloquean a los escritores ni al revés. En PostgreSQL, cada versión de fila lleva `xmin` (la transacción que la creó) y `xmax` (la que la borró o reemplazó).
snapshot	La vista de la base de datos que ve una transacción en MVCC: los cambios de las transacciones que hicieron commit antes de cierto momento, y ninguno posterior.
snapshot isolation	Cada transacción lee de un snapshot tomado al empezar, y solo puede hacer commit si ninguna transacción concurrente ya confirmada escribió los mismos ítems. Evita dirty reads, non-repeatable reads, phantoms y lost updates, pero permite write skew. En PostgreSQL es el nivel `REPEATABLE READ`.
serializable snapshot isolation (SSI)	Snapshot isolation más la detección de los patrones de dependencias lectura-escritura que pueden producir un schedule no serializable; aborta una transacción con un error de serialización (SQLSTATE `40001`). Es el nivel `SERIALIZABLE` de PostgreSQL.
`VACUUM`	El proceso de PostgreSQL que recupera el espacio de las versiones de fila que ya ninguna transacción puede ver (dead tuples) y congela ids de transacción antiguos para evitar el wraparound.
crash	Un fallo que detiene el sistema y borra la memoria principal, pero no el disco. También se dice caída. Después, la recuperación (recovery) deja la base con todas las transacciones confirmadas y ninguna de las incompletas.
log	Archivo secuencial, de solo agregar, guardado en almacenamiento estable, donde el DBMS anota cada cambio antes de aplicarlo en las páginas de datos. Es la base de la recuperación.
Registro del log (log record)	Una entrada del log. Un registro de actualización guarda la transacción, el ítem, el valor anterior (para undo) y el nuevo (para redo); también hay registros de inicio, commit, abort y checkpoint.
write-ahead logging (WAL)	La regla de que los registros del log que describen un cambio deben estar en almacenamiento estable antes de que la página modificada se escriba en disco, y todos los de una transacción antes de su commit. En PostgreSQL, WAL es también el nombre del log (`pg_wal`).
LSN	Log sequence number: identificador único y creciente de cada registro del log; en PostgreSQL, su posición en bytes dentro del WAL (`pg_current_wal_lsn()`).
pageLSN	El LSN del último registro del log cuyo cambio está aplicado en la página; se guarda en la cabecera de la página. Durante el redo se salta todo registro con LSN ≤ pageLSN.
redo / undo	Redo vuelve a aplicar, a partir del log, cambios confirmados que quizá no llegaron al disco. Undo deshace cambios de transacciones sin commit que quizá sí llegaron.
steal / no-steal	Con steal, el buffer manager puede escribir en disco una página modificada por una transacción que aún no hizo commit, así que la recuperación necesita undo. Con no-steal no puede.
force / no-force	Con force, todas las páginas modificadas por una transacción se escriben en disco al hacer commit, así que no hace falta redo. Con no-force pueden quedar en memoria, así que hace falta redo. Los DBMS reales usan steal / no-force.
checkpoint	Un punto que el DBMS anota en el log para acotar cuánto log hay que leer al recuperar. En ARIES es un fuzzy checkpoint (guarda la tabla de transacciones y la dirty page table sin detener el sistema); en PostgreSQL escribe todas las páginas sucias y marca desde dónde empieza el redo.
dirty page table	En ARIES, la lista de las páginas sucias del buffer pool, cada una con su recLSN: el LSN del primer registro que la ensució. El menor recLSN dice dónde empieza el redo.
ARIES	Algoritmo de recuperación para steal / no-force basado en WAL y LSNs. Tiene tres fases: análisis (reconstruye las transacciones activas y la dirty page table), redo (repite la historia, incluidas las transacciones perdedoras) y undo (deshace las perdedoras escribiendo CLRs).
CLR	Compensation log record: el registro que se escribe al deshacer un cambio durante un rollback o en la fase de undo. Es solo de redo, nunca se deshace, y su UndoNextLSN apunta al siguiente registro por deshacer, así que una caída durante la recuperación no repite trabajo.
Particionamiento (partitioning)	Dividir una tabla en partes según una clave, por rango, por lista o por hash. En un solo servidor permite descartar partes en las consultas; repartir las partes entre varios servidores es sharding.
Replicación (replication)	Mantener copias de los mismos datos en varios servidores, para tolerar fallos y repartir las lecturas. Es sincrónica si el commit espera la confirmación de las réplicas y asincrónica si no.
two-phase commit (2PC)	Protocolo de commit atómico entre varios servidores. En la fase 1 el coordinador pide a cada participante que se prepare y vote; en la fase 2, si todos votaron sí, ordena el commit, y si no, el abort. Si el coordinador falla, los participantes preparados quedan bloqueados.
consensus	El problema de que varios nodos acuerden un mismo valor (o una misma secuencia, como un log replicado) aunque una minoría falle. Paxos y Raft lo resuelven.
NoSQL	Nombre genérico de los sistemas que no usan el modelo relacional ni SQL como interfaz principal: key-value stores (solo `get` y `put` por clave), document stores (documentos JSON consultables por sus campos) y otros, muchas veces con garantías de consistencia más débiles.
MapReduce	Modelo de procesamiento paralelo en el que una función map produce pares clave-valor a partir de cada dato de entrada, el sistema los agrupa por clave (shuffle) y una función reduce combina los valores de cada clave.