B3-T1: DISEÑO Y ADMINISTRACIÓN DE BASES DE DATOS RELACIONALES
Tema fundamental y de los más preguntados en el TAI. La normalización (identificar formas normales, dependencias funcionales) es casi fija. También preguntan mucho sobre el modelo E-R (cardinalidades, entidades débiles), álgebra relacional (selección, proyección, join), y los niveles de aislamiento de transacciones. Memoriza las definiciones formales de cada forma normal.
MODELO RELACIONAL: FUNDAMENTOS
Origen y conceptos básicos
El modelo relacional fue propuesto por Edgar F. Codd en 1970 en su artículo "A Relational Model of Data for Large Shared Data Banks" (IBM). Se basa en la teoría matemática de conjuntos y la lógica de predicados de primer orden.
| Concepto formal | Equivalente informal | Descripción |
|---|
| Relación | Tabla | Subconjunto del producto cartesiano de los dominios de sus atributos |
| Tupla | Fila / registro | Cada elemento de la relación (conjunto ordenado de valores) |
| Atributo | Columna / campo | Nombre que identifica cada componente de la tupla |
| Dominio | Tipo de dato | Conjunto de valores válidos para un atributo |
| Grado | Nº de columnas | Número de atributos de la relación |
| Cardinalidad | Nº de filas | Número de tuplas de la relación |
| Esquema | Definición de la tabla | Nombre de la relación + lista de atributos con sus dominios |
Propiedades de una relación
| Propiedad | Descripción |
|---|
| No hay tuplas duplicadas | Al ser un conjunto, cada tupla es única |
| El orden de las tuplas no importa | No hay primera ni última fila |
| El orden de los atributos no importa | Se accede por nombre, no por posición |
| Valores atómicos | Cada celda contiene un solo valor indivisible (1FN) |
Claves
| Tipo de clave | Definición |
|---|
| Superclave | Cualquier conjunto de atributos que identifica unívocamente cada tupla |
| Clave candidata | Superclave mínima (si se elimina cualquier atributo, deja de ser superclave) |
| Clave primaria (PK) | Clave candidata elegida como identificador principal. No admite NULL |
| Clave alternativa | Clave candidata no elegida como primaria |
| Clave ajena / foránea (FK) | Atributo(s) que referencia(n) la clave primaria de otra relación |
RESTRICCIONES DE INTEGRIDAD
| Restricción | Descripción |
|---|
| Integridad de entidad | La clave primaria no puede ser NULL (ni parcialmente NULL en claves compuestas) |
| Integridad referencial | Toda clave ajena debe referenciar una clave primaria existente (o ser NULL si se permite) |
| Integridad de dominio | Los valores de cada atributo deben pertenecer a su dominio (tipo, rango, formato) |
| Integridad semántica | Reglas de negocio definidas por el usuario (CHECK, triggers, assertions) |
Acciones referenciales (ON DELETE / ON UPDATE)
| Acción | Descripción |
|---|
| RESTRICT / NO ACTION | Rechaza la operación si hay filas que referencian la clave |
| CASCADE | Propaga la operación a las filas referenciantes (borra/actualiza en cascada) |
| SET NULL | Pone a NULL las claves ajenas de las filas referenciantes |
| SET DEFAULT | Pone el valor por defecto en las claves ajenas |
MODELO ENTIDAD-RELACIÓN (E-R)
Componentes del modelo E-R
Propuesto por Peter Chen en 1976. Es un modelo conceptual para representar la estructura de datos antes de implementarla en un SGBD.
| Componente | Símbolo | Descripción |
|---|
| Entidad | Rectángulo | Objeto del mundo real distinguible (Empleado, Departamento) |
| Entidad débil | Rectángulo doble | Depende de otra entidad para su identificación (no tiene clave propia completa) |
| Atributo | Elipse | Propiedad de una entidad o relación |
| Atributo clave | Elipse subrayada | Atributo que forma parte de la clave primaria |
| Atributo multivaluado | Elipse doble | Puede tener múltiples valores (teléfonos de un empleado) |
| Atributo derivado | Elipse punteada | Calculable a partir de otros atributos (edad a partir de fecha_nacimiento) |
| Atributo compuesto | Elipse con subelipses | Descomponible en subatributos (dirección → calle, ciudad, CP) |
| Relación (interrelación) | Rombo | Asociación entre entidades (Trabaja_en, Matriculado_en) |
| Relación identificadora | Rombo doble | Relación que conecta una entidad débil con su entidad fuerte |
Cardinalidades
| Cardinalidad | Notación | Ejemplo |
|---|
| 1:1 | Uno a uno | Empleado — tiene — DNI |
| 1:N | Uno a muchos | Departamento — emplea — Empleados |
| M:N | Muchos a muchos | Estudiante — matriculado — Asignatura |
Participación
| Tipo | Notación | Significado |
|---|
| Total (obligatoria) | Línea doble | Toda instancia de la entidad participa en la relación |
| Parcial (opcional) | Línea simple | Algunas instancias pueden no participar |
Transformación E-R a modelo relacional
| Elemento E-R | Transformación a tablas |
|---|
| Entidad fuerte | Una tabla con todos sus atributos. La clave del E-R es la PK |
| Entidad débil | Una tabla con sus atributos + la PK de la entidad fuerte como parte de la PK compuesta |
| Relación 1:1 | FK en cualquiera de las dos tablas (preferible en la de participación total) |
| Relación 1:N | FK en el lado N (la tabla del "muchos" recibe la PK del "uno") |
| Relación M:N | Tabla intermedia con las PKs de ambas entidades como PK compuesta + atributos de la relación |
| Atributo multivaluado | Tabla separada con FK a la entidad |
| Atributo compuesto | Se descompone en atributos simples en la tabla |
| Generalización/Especialización | Tres opciones: tabla padre + tablas hijas (con FK), solo tablas hijas, o tabla única con discriminador |
Examen: La relación M:N siempre genera una tabla intermedia. La relación 1:N se resuelve con FK en el lado N. La entidad débil siempre incluye la PK de su entidad fuerte en su propia PK.
ÁLGEBRA RELACIONAL
Operaciones fundamentales
| Operación | Símbolo | Descripción | Equivalente SQL |
|---|
| Selección | σ (sigma) | Filtra tuplas que cumplen una condición | WHERE |
| Proyección | π (pi) | Selecciona un subconjunto de atributos (columnas) | SELECT col1, col2 |
| Unión | ∪ | Tuplas que están en R1 o en R2 (mismos atributos) | UNION |
| Diferencia | − | Tuplas que están en R1 pero no en R2 | EXCEPT |
| Producto cartesiano | × | Todas las combinaciones de tuplas de R1 y R2 | CROSS JOIN |
| Renombramiento | ρ (rho) | Cambia el nombre de la relación o atributos | AS |
Operaciones derivadas
| Operación | Símbolo | Descripción | Equivalente SQL |
|---|
| Intersección | ∩ | Tuplas que están en R1 y en R2 | INTERSECT |
| Join natural | ⋈ | Producto cartesiano + selección sobre atributos comunes + proyección (sin duplicados) | NATURAL JOIN |
| Theta join | ⋈θ | Producto cartesiano + selección con condición θ | JOIN ON condición |
| Equi-join | ⋈= | Theta join donde θ es igualdad | JOIN ON a.x = b.x |
| Left outer join | ⟕ | Join natural + tuplas de R1 sin pareja (con NULLs) | LEFT JOIN |
| Right outer join | ⟖ | Join natural + tuplas de R2 sin pareja | RIGHT JOIN |
| Full outer join | ⟗ | Ambos outer joins | FULL OUTER JOIN |
| División | ÷ | Tuplas de R1 que se relacionan con TODAS las tuplas de R2 | Subconsulta con NOT EXISTS |
Examen: Las 6 operaciones fundamentales (Codd) son: σ, π, ∪, −, ×, ρ. El resto se pueden derivar de éstas. La selección filtra filas (horizontal), la proyección filtra columnas (vertical). La división es la más compleja — responde preguntas como "¿qué proveedores suministran TODOS los productos?".
NORMALIZACIÓN
Dependencia funcional
Un atributo B depende funcionalmente de A (se escribe A → B) si para cada valor de A hay exactamente un valor de B. Es decir: si dos tuplas coinciden en A, deben coincidir en B.
| Tipo de dependencia | Notación | Descripción |
|---|
| Funcional | A → B | A determina B (cada valor de A tiene un único B) |
| Funcional completa | AB → C (pero ni A→C ni B→C) | C depende de toda la clave AB, no de una parte |
| Transitiva | A → B → C (A no depende de B ni C) | C depende de A a través de B |
| Multivaluada | A ↠ B | Para cada A, hay un conjunto de B independiente de los demás atributos |
Formas normales
| Forma normal | Requisito | Elimina |
|---|
| 1FN | Todos los atributos son atómicos (no hay grupos repetitivos ni atributos multivaluados) | Grupos repetitivos |
| 2FN | 1FN + no hay dependencias parciales (todo atributo no clave depende de TODA la clave, no de una parte) | Dependencias parciales |
| 3FN | 2FN + no hay dependencias transitivas (ningún atributo no clave depende de otro atributo no clave) | Dependencias transitivas |
| BCNF (Boyce-Codd) | Para toda dependencia funcional X → Y, X es superclave | Anomalías residuales de 3FN (cuando hay claves candidatas solapadas) |
| 4FN | BCNF + no hay dependencias multivaluadas no triviales | Dependencias multivaluadas |
| 5FN (PJ/NF) | 4FN + no hay dependencias de join (no se puede descomponer sin pérdida) | Dependencias de proyección-join |
Examen: La 2FN solo aplica si la clave es compuesta (si la PK es un solo atributo, 1FN ⇒ 2FN automáticamente). La 3FN es el objetivo mínimo habitual en diseño. La BCNF es más estricta que 3FN — una tabla puede estar en 3FN y no en BCNF si hay múltiples claves candidatas solapadas. La frase mnemotécnica: "La clave, toda la clave, y nada más que la clave" (1FN→2FN→3FN).
Proceso de normalización — ejemplo
| Paso | Acción | Resultado |
|---|
| 0FN → 1FN | Eliminar grupos repetitivos y multivaluados. Cada celda = un solo valor | Tabla plana con atributos atómicos |
| 1FN → 2FN | Identificar dependencias parciales y extraer a tablas separadas | Cada atributo no clave depende de toda la PK |
| 2FN → 3FN | Identificar dependencias transitivas y extraer a tablas separadas | Ningún atributo no clave depende transitivamente de la PK |
| 3FN → BCNF | Verificar que todo determinante es superclave. Descomponer si no | Todo determinante funcional es superclave |
Desnormalización
Proceso inverso a la normalización: se introducen redundancias controladas para mejorar el rendimiento de lectura (evitar JOINs costosos). Se usa en Data Warehouses (esquema estrella/copo de nieve) y en aplicaciones con más lecturas que escrituras. El coste es mayor complejidad de mantenimiento y riesgo de inconsistencias.
TRANSACCIONES Y CONTROL DE CONCURRENCIA
Propiedades ACID
| Propiedad | Descripción |
|---|
| Atomicidad | La transacción se ejecuta completamente o no se ejecuta en absoluto (todo o nada) |
| Consistencia | La transacción lleva la BBDD de un estado válido a otro estado válido |
| Aislamiento (Isolation) | Las transacciones concurrentes no se interfieren entre sí |
| Durabilidad | Una vez confirmada (COMMIT), la transacción persiste aunque falle el sistema |
Problemas de concurrencia
| Problema | Descripción |
|---|
| Lectura sucia (dirty read) | T2 lee datos que T1 ha modificado pero no ha confirmado (si T1 hace rollback, T2 usó datos inválidos) |
| Lectura no repetible (non-repeatable read) | T1 lee un dato, T2 lo modifica y confirma, T1 relee y obtiene un valor distinto |
| Lectura fantasma (phantom read) | T1 ejecuta una consulta con WHERE, T2 inserta filas que cumplen el WHERE, T1 reejecutando ve filas nuevas |
| Actualización perdida (lost update) | T1 y T2 leen el mismo dato, ambas lo modifican, la segunda escritura sobrescribe la primera |
Niveles de aislamiento (SQL estándar — ISO/IEC 9075)
| Nivel | Dirty read | Non-repeatable read | Phantom read | Rendimiento |
|---|
| READ UNCOMMITTED | Posible | Posible | Posible | Máximo |
| READ COMMITTED | Evitado | Posible | Posible | Alto (default PostgreSQL, Oracle) |
| REPEATABLE READ | Evitado | Evitado | Posible | Medio (default MySQL InnoDB) |
| SERIALIZABLE | Evitado | Evitado | Evitado | Mínimo (máximo aislamiento) |
Examen: READ COMMITTED es el nivel por defecto en PostgreSQL y Oracle. REPEATABLE READ es el default en MySQL InnoDB. SERIALIZABLE evita todos los problemas pero con menor rendimiento. La mayoría de preguntas piden identificar qué problema se evita en cada nivel.
Mecanismos de control de concurrencia
| Mecanismo | Descripción |
|---|
| Bloqueo (locking) | Bloqueos compartidos (lectura) y exclusivos (escritura). Protocolo 2PL (Two-Phase Locking): fase de crecimiento + fase de liberación |
| Timestamp ordering | Cada transacción recibe un timestamp al iniciar; se ordenan según ese timestamp |
| MVCC (Multi-Version Concurrency Control) | Se mantienen múltiples versiones de cada fila. Los lectores ven una snapshot consistente sin bloquear escritores. Usado por PostgreSQL, Oracle, MySQL InnoDB |
| Optimistic concurrency | No bloquea durante la transacción; al hacer commit, verifica si hubo conflicto (si sí, rollback) |
ÍNDICES Y RENDIMIENTO
Tipos de índices
| Tipo | Estructura | Uso |
|---|
| B-tree / B+ | Árbol balanceado | Índice por defecto en la mayoría de SGBD. Búsquedas por igualdad y rango |
| Hash | Tabla hash | Solo búsquedas por igualdad exacta. No soporta rangos |
| Bitmap | Mapa de bits | Atributos con baja cardinalidad (pocas valores distintos: género, estado) |
| GiST / GIN | Generalizados | PostgreSQL: texto completo, geoespacial, arrays, JSON |
| Clustered | Ordena físicamente la tabla | Solo 1 por tabla. La tabla se almacena en el orden del índice |
| Non-clustered | Estructura separada con punteros | Múltiples por tabla. Punteros a las filas reales |
| Compuesto | Sobre múltiples columnas | Consultas que filtran/ordenan por varias columnas. Orden de columnas importa |
| Unique | B-tree con restricción de unicidad | Garantiza que no haya valores duplicados |
| Parcial / Filtered | Índice sobre un subconjunto de filas | Indexar solo filas que cumplen una condición (ej. WHERE active = true) |
Examen: Un índice clustered reordena físicamente las filas de la tabla → solo puede haber 1 por tabla. En MySQL InnoDB, la PK es siempre el índice clustered. Los índices aceleran las lecturas pero penalizan las escrituras (hay que mantener el índice actualizado).
VISTAS Y OBJETOS DE BBDD
| Objeto | Descripción |
|---|
| Vista (VIEW) | Consulta almacenada que se comporta como una tabla virtual. No almacena datos (se ejecuta al consultarla) |
| Vista materializada | Vista que sí almacena los resultados físicamente. Debe refrescarse periódicamente |
| Trigger | Procedimiento que se ejecuta automáticamente ante un evento (INSERT, UPDATE, DELETE) |
| Stored procedure | Conjunto de sentencias SQL almacenado y compilado en el servidor. Se invoca por nombre |
| Function | Similar a stored procedure pero retorna un valor y puede usarse en SELECT |
| Secuencia (SEQUENCE) | Generador de números únicos autoincrementales |
| Sinónimo (SYNONYM) | Alias para un objeto de la BBDD (otra tabla, vista, etc.) |
ADMINISTRACIÓN DE BBDD
Roles del DBA
| Función | Descripción |
|---|
| Diseño lógico/físico | Definir esquema, normalización, índices, particionado |
| Seguridad | Gestión de usuarios, roles, permisos (GRANT/REVOKE), auditoría |
| Backup y recuperación | Copias de seguridad (full, incremental, diferencial), planes de recuperación ante desastres |
| Monitorización | Rendimiento de consultas, uso de recursos, bloqueos, espacio en disco |
| Tuning | Optimización de consultas (EXPLAIN), índices, configuración del SGBD, estadísticas |
| Alta disponibilidad | Replicación, clustering, failover, balanceo de carga |
Tipos de backup
| Tipo | Qué copia | Tamaño | Restauración |
|---|
| Full (completo) | Toda la base de datos | Grande | Solo necesita este backup |
| Incremental | Solo lo cambiado desde el último backup (full o incremental) | Pequeño | Necesita full + todos los incrementales en orden |
| Diferencial | Lo cambiado desde el último backup full | Medio (crece con el tiempo) | Necesita full + último diferencial |
SGBD principales
| SGBD | Licencia | Características destacadas |
|---|
| Oracle Database | Comercial | Líder empresarial, PL/SQL, RAC (clustering), Data Guard (replicación) |
| PostgreSQL | Open Source (BSD) | Muy extensible, MVCC, JSON, PostGIS, tipos custom, CTE |
| MySQL | Open Source (GPL) + comercial | InnoDB (ACID), replicación, amplio ecosistema web (LAMP) |
| MariaDB | Open Source (GPL) | Fork de MySQL, compatible, Galera Cluster |
| SQL Server | Comercial (Microsoft) | T-SQL, SSRS, SSIS, SSAS, integración con Azure |
| SQLite | Dominio público | Embedded, sin servidor, fichero único. Ideal para apps móviles |
FUENTES PÚBLICAS
Este resumen ha sido elaborado íntegramente a partir de fuentes de dominio público. No se ha utilizado material con copyright de terceros ni material de preparadores.
| Fuente | Tipo | Referencia |
|---|
| Codd, E. F. (1970) — Modelo relacional | Publicación académica | IBM (dominio público) |
| Chen, P. (1976) — Modelo E-R | Publicación académica | Dominio público |
| ISO/IEC 9075 — SQL Standard | Estándar | ISO |
| Documentación PostgreSQL, MySQL, Oracle | Documentación oficial | Públicas |