1. Definiciones y Conceptos Básicos del Modelo Relacional

1.1. Origen y Fundamentación Teórica

El modelo relacional fue introducido por Edgar Frank Codd en su artículo seminal «A Relational Model of Data for Large Shared Data Banks» publicado en 1970. Codd, trabajando en IBM Research, buscaba superar las limitaciones de los modelos jerárquicos y de red que dominaban la época, caracterizados por su complejidad y dependencia de la estructura física de almacenamiento. El modelo relacional establece una clara separación entre el nivel lógico y físico de los datos, permitiendo que los usuarios y aplicaciones trabajen con una visión abstracta de la información sin preocuparse por los detalles de implementación.

La fundamentación matemática del modelo se basa en la teoría de conjuntos y el álgebra relacional. Una base de datos relacional se compone de relaciones (tablas), donde cada relación es un conjunto de tuplas (filas) que comparten la misma estructura definida por atributos (columnas). Esta base formal garantiza propiedades importantes como la clausura algebraica: el resultado de cualquier operación sobre relaciones es también una relación, lo que permite componer operaciones complejas a partir de operaciones básicas.

1.2. Conceptos Fundamentales

Dominio

Un dominio es un conjunto de valores atómicos permitidos para un atributo. Por ejemplo, el dominio de un atributo «edad» podría ser el conjunto de números enteros entre cero y ciento cincuenta. Los dominios definen el tipo de datos y las restricciones de valores que puede tomar cada atributo, asegurando la integridad semántica de la información.

Relación

Una relación R sobre los dominios D1, D2, …, Dn es un subconjunto del producto cartesiano D1 × D2 × … × Dn. En términos prácticos, una relación es una tabla con n columnas donde cada fila representa una combinación válida de valores de los dominios correspondientes. El grado o aridad de una relación es el número de atributos que posee, mientras que la cardinalidad es el número de tuplas que contiene.

Tupla

Una tupla es un elemento de una relación, representando una fila en la tabla. Cada tupla es una combinación ordenada de valores, uno para cada atributo de la relación. Las tuplas deben ser únicas dentro de una relación, lo que se garantiza mediante la existencia de claves.

Atributo

Un atributo representa una propiedad o característica de las entidades modeladas por la relación. Cada atributo tiene un nombre único dentro de su relación y está asociado a un dominio específico. Los atributos pueden clasificarse en simples o compuestos, monovaluados o multivaluados, y almacenados o derivados.

1.3. Tipos de Claves

Superclave

Una superclave es cualquier conjunto de atributos que puede identificar únicamente cada tupla de una relación. Formalmente, si K es una superclave de R, entonces no pueden existir dos tuplas distintas t1 y t2 en R que tengan el mismo valor para todos los atributos de K.

Clave Candidata

Una clave candidata es una superclave minimal, es decir, una superclave de la cual no se puede eliminar ningún atributo sin perder la propiedad de unicidad. Una relación puede tener múltiples claves candidatas, todas ellas funcionalmente equivalentes para propósitos de identificación.

Clave Primaria (Primary Key)

La clave primaria es la clave candidata seleccionada por el diseñador de la base de datos para ser el identificador principal de las tuplas. Por convención, se elige la clave más natural o la que tiene menos atributos. La clave primaria no puede contener valores nulos (restricción de integridad de entidad).

Clave Foránea (Foreign Key)

Una clave foránea es un conjunto de atributos en una relación R1 que hace referencia a la clave primaria de otra relación R2. Las claves foráneas implementan las relaciones entre tablas y están sujetas a la restricción de integridad referencial: el valor de una clave foránea debe aparecer como valor de clave primaria en la tabla referenciada, o ser nulo.

1.4. Las 12 Reglas de Codd

Edgar F. Codd propuso doce reglas (más una regla cero) que debe cumplir un sistema para considerarse verdaderamente relacional. Estas reglas establecen criterios estrictos que muchos SGBD comerciales no cumplen completamente:

1. Regla 0 – Regla Fundamental: Un sistema que se anuncia como relacional debe gestionar bases de datos exclusivamente mediante capacidades relacionales.
2. Regla 1 – Regla de la Información: Toda la información debe representarse de una sola manera: mediante valores en posiciones de columnas dentro de filas de tablas.
3. Regla 2 – Regla del Acceso Garantizado: Cada valor debe ser accesible mediante la combinación de nombre de tabla, valor de clave primaria y nombre de columna.
4. Regla 3 – Tratamiento Sistemático de Valores Nulos: Los valores nulos deben ser soportados de forma uniforme y distinta de cualquier valor del dominio.
5. Regla 4 – Catálogo Dinámico en Línea Basado en el Modelo Relacional: Los metadatos deben almacenarse como tablas ordinarias consultables mediante el mismo lenguaje de datos.
6. Regla 5 – Regla del Sublenguaje de Datos Completo: Debe existir al menos un lenguaje que soporte definición de datos, manipulación, restricciones de integridad, autorización y transacciones.
7. Regla 6 – Regla de Actualización de Vistas: Todas las vistas teóricamente actualizables deben ser actualizables por el sistema.
8. Regla 7 – Insert, Update y Delete de Alto Nivel: Las operaciones deben poder aplicarse a conjuntos completos, no solo a filas individuales.
9. Regla 8 – Independencia Física de Datos: Los cambios en el almacenamiento físico no deben afectar a las aplicaciones.
10. Regla 9 – Independencia Lógica de Datos: Los cambios en las tablas base no deben afectar a las aplicaciones si son compatibles.
11. Regla 10 – Independencia de Integridad: Las restricciones de integridad deben especificarse separadamente de los programas de aplicación.
12. Regla 11 – Independencia de Distribución: La distribución física no debe afectar al funcionamiento lógico.
13. Regla 12 – Regla de No Subversión: No debe ser posible usar un lenguaje de bajo nivel para saltarse las restricciones de integridad.

2. Arquitectura del Modelo Relacional

2.1. Arquitectura de Tres Esquemas ANSI-SPARC

El modelo relacional se implementa típicamente siguiendo la arquitectura de tres esquemas propuesta por ANSI-SPARC, que establece tres niveles de abstracción claramente diferenciados para proporcionar independencia de datos. Esta arquitectura, aunque fue diseñada para sistemas de bases de datos en general, se aplica perfectamente al modelo relacional.

Nivel Externo (Vistas de Usuario)

El nivel externo define múltiples vistas personalizadas de la base de datos para diferentes usuarios o grupos de usuarios. Cada vista externa presenta una perspectiva específica de los datos, ocultando información irrelevante o sensible para ese usuario particular. En el modelo relacional, las vistas se implementan como consultas almacenadas que derivan tablas virtuales a partir de las tablas base. Por ejemplo, un departamento de recursos humanos podría tener una vista que muestre información de empleados sin incluir datos salariales sensibles.

Nivel Conceptual (Esquema Lógico)

El nivel conceptual representa la estructura lógica completa de la base de datos independientemente de consideraciones físicas. En el modelo relacional, este nivel se define mediante el esquema de la base de datos: el conjunto de todas las relaciones con sus atributos, dominios, claves y restricciones de integridad. Este es el nivel donde los diseñadores de bases de datos trabajan para modelar la realidad del dominio de aplicación. El esquema conceptual describe qué datos se almacenan y qué relaciones existen entre ellos, pero no cómo se almacenan físicamente.

Nivel Interno (Esquema Físico)

El nivel interno describe la implementación física de la base de datos: cómo se almacenan realmente los datos en el hardware. Esto incluye estructuras de almacenamiento, índices, organización de archivos, compresión, particionamiento y distribución física de los datos. El SGBD oculta estos detalles al usuario, proporcionando independencia física de datos. Cambios en el nivel interno, como añadir un índice para mejorar el rendimiento, no deberían afectar al nivel conceptual o externo.

2.2. Componentes Arquitectónicos de un SGBD Relacional

Procesador de Consultas

El procesador de consultas es responsable de transformar las consultas SQL de alto nivel en operaciones de bajo nivel eficientes sobre la base de datos física. Sus componentes principales incluyen el analizador sintáctico que verifica la corrección de la sintaxis SQL, el traductor que convierte SQL a álgebra relacional, el optimizador que genera planes de ejecución eficientes explorando alternativas, y el evaluador que ejecuta el plan seleccionado.

Gestor de Almacenamiento

El gestor de almacenamiento proporciona la interfaz entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicación y consultas. Sus responsabilidades incluyen la interacción con el gestor de archivos del sistema operativo, la gestión de buffers en memoria, la implementación de estructuras de indexación y el mantenimiento del diccionario de datos que contiene los metadatos del sistema.

Gestor de Transacciones

El gestor de transacciones garantiza que las transacciones se ejecuten correctamente preservando las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad). Coordina el control de concurrencia para gestionar accesos simultáneos, implementa mecanismos de recuperación ante fallos, y asegura que las transacciones se completen totalmente o no tengan ningún efecto sobre la base de datos.

3. Diseño de Bases de Datos Relacionales

3.1. Proceso de Diseño

El diseño de una base de datos relacional es un proceso sistemático que transforma los requisitos de información de una organización en una estructura de base de datos eficiente y bien organizada. Este proceso se desarrolla en varias fases interrelacionadas, cada una con objetivos específicos y productos de salida bien definidos.

Fase 1: Análisis de Requisitos

Durante esta fase inicial se recopilan y documentan los requisitos de información del sistema. Se identifican los datos que deben almacenarse, las relaciones entre ellos, las restricciones de negocio, los volúmenes esperados de datos, los patrones de acceso y los requisitos de rendimiento. Esta fase produce un documento de especificación de requisitos que sirve como base para las siguientes etapas. Las técnicas utilizadas incluyen entrevistas con usuarios, análisis de documentos existentes, observación de procesos de negocio y talleres de trabajo con stakeholders.

Fase 2: Diseño Conceptual

El diseño conceptual crea un modelo de alto nivel de la estructura de la base de datos independiente de cualquier SGBD específico. El modelo Entidad-Relación es la herramienta más común para esta fase. Se identifican las entidades (objetos o conceptos del mundo real), los atributos que describen cada entidad, y las relaciones entre entidades con sus cardinalidades. El resultado es un diagrama ER que representa visualmente la estructura conceptual de la información, libre de consideraciones de implementación.

Fase 3: Diseño Lógico

En el diseño lógico, el modelo conceptual se transforma en un esquema relacional específico. Se aplican reglas de transformación para convertir entidades y relaciones en tablas, se definen claves primarias y foráneas, se especifican dominios de atributos, y se documentan restricciones de integridad. Un aspecto crucial es el proceso de normalización, que se aplica para eliminar redundancias y anomalías de actualización. El producto final es un conjunto de esquemas de relaciones con sus restricciones.

Fase 4: Diseño Físico

El diseño físico traduce el esquema lógico en estructuras de almacenamiento específicas del SGBD objetivo. Se toman decisiones sobre indexación (qué columnas indexar, tipos de índices), particionamiento de tablas, organización de archivos, espacios de almacenamiento y parámetros de configuración. También se pueden aplicar técnicas de desnormalización controlada para optimizar patrones de consulta específicos cuando el rendimiento es crítico. Esta fase requiere conocimiento profundo del SGBD específico y sus características de rendimiento.

3.2. Restricciones de Integridad

Las restricciones de integridad son reglas que deben cumplirse en todo momento para mantener la exactitud y consistencia de los datos. El modelo relacional define varios tipos de restricciones formales que los SGBD modernos implementan y verifican automáticamente.

Integridad de Entidad

Esta restricción establece que la clave primaria de una relación no puede contener valores nulos. La razón fundamental es que la clave primaria identifica únicamente cada tupla, y un valor nulo representaría una tupla no identificable. Adicionalmente, implica que no pueden existir dos tuplas con el mismo valor de clave primaria (unicidad). Los SGBD imponen esta restricción automáticamente cuando se declara una clave primaria.

Integridad Referencial

La integridad referencial garantiza que las referencias entre tablas sean válidas. Cuando un atributo de una tabla (clave foránea) hace referencia a la clave primaria de otra tabla, el valor de la clave foránea debe existir en la tabla referenciada o ser nulo. Esta restricción previene «referencias colgantes» que apuntarían a tuplas inexistentes. Los SGBD modernos permiten definir acciones en cascada: cuando se elimina o actualiza una tupla referenciada, se puede propagar automáticamente el cambio, rechazar la operación, o establecer valores nulos en las referencias.

Integridad de Dominio

La integridad de dominio especifica que los valores de cada atributo deben pertenecer a su dominio definido. Esto incluye el tipo de datos (entero, cadena, fecha), restricciones de rango (edad entre cero y ciento cincuenta), restricciones de formato (código postal con formato específico), y valores por defecto. Los SGBD implementan estas restricciones mediante tipos de datos, constraints CHECK, y triggers cuando se necesita lógica más compleja.

Restricciones de Usuario (Semánticas)

Además de las restricciones inherentes al modelo relacional, se pueden definir restricciones específicas del dominio de aplicación. Por ejemplo, que el salario de un empleado no puede exceder el salario de su supervisor, que la fecha de finalización de un proyecto debe ser posterior a su fecha de inicio, o que un estudiante no puede matricularse en más de cinco asignaturas simultáneamente. Estas restricciones se implementan mediante constraints CHECK complejos, assertions, o triggers que ejecutan lógica procedural para verificar las condiciones.

4. Normalización

4.1. Fundamentos y Objetivos de la Normalización

La normalización es un proceso sistemático de organización de datos que elimina redundancias y previene anomalías de actualización, mediante la descomposición de relaciones en relaciones más pequeñas que cumplen ciertas propiedades deseables. Este proceso, formalizado por Edgar F. Codd y posteriormente refinado por otros investigadores, se basa en la teoría de dependencias funcionales y multivaluadas.

Los objetivos principales de la normalización son prevenir anomalías de inserción (imposibilidad de añadir ciertos datos sin añadir otros datos no relacionados), anomalías de eliminación (pérdida involuntaria de información al eliminar datos), y anomalías de actualización (necesidad de modificar múltiples tuplas para actualizar un único hecho). La normalización también minimiza el espacio de almacenamiento necesario al reducir redundancias y simplifica las reglas de integridad al aislar datos relacionados en sus propias relaciones.

4.2. Dependencias Funcionales

Una dependencia funcional es una restricción entre dos conjuntos de atributos de una relación. Se dice que un conjunto de atributos Y depende funcionalmente de un conjunto de atributos X (notado X → Y) si para cada valor de X existe exactamente un valor de Y asociado. Formalmente, si dos tuplas tienen el mismo valor para X, deben tener el mismo valor para Y.

Por ejemplo, en una relación de empleados, DNI → Nombre significa que cada DNI determina únicamente un nombre. Las dependencias funcionales pueden ser triviales (Y es subconjunto de X), no triviales parciales (Y depende de una parte de X), o completas (Y depende de todo X). La identificación correcta de dependencias funcionales es fundamental para aplicar adecuadamente el proceso de normalización.

4.3. Formas Normales

Primera Forma Normal (1FN)

Una relación está en primera forma normal si todos sus atributos contienen únicamente valores atómicos, es decir, indivisibles. No se permiten atributos multivaluados, compuestos o relaciones anidadas. Por ejemplo, una tabla donde el atributo «teléfonos» contiene múltiples números separados por comas violaría 1FN. La solución es crear una tabla separada para teléfonos con una clave foránea que referencie la entidad principal, permitiendo múltiples filas de teléfonos por entidad.

Segunda Forma Normal (2FN)

Una relación está en segunda forma normal si está en 1FN y además todos los atributos no clave dependen completamente de la clave primaria completa, no solo de parte de ella. Esta forma normal es relevante solo para relaciones con claves compuestas. Una dependencia funcional parcial ocurre cuando un atributo depende solo de algunos componentes de una clave compuesta. La solución es descomponer la relación, separando los atributos que dependen solo de parte de la clave.

Tercera Forma Normal (3FN)

Una relación está en tercera forma normal si está en 2FN y además no existen dependencias transitivas entre atributos no clave. Una dependencia transitiva ocurre cuando un atributo no clave depende de otro atributo no clave, que a su vez depende de la clave primaria. Es decir, si X → Y y Y → Z, entonces Z depende transitivamente de X. La eliminación de dependencias transitivas previene anomalías al aislar hechos independientes en sus propias relaciones.

Forma Normal de Boyce-Codd (BCNF)

La forma normal de Boyce-Codd es una versión más estricta de 3FN. Una relación está en BCNF si para cada dependencia funcional no trivial X → Y, X es una superclave. En otras palabras, solo las superclaves pueden determinar otros atributos. Hay casos raros donde una relación está en 3FN pero no en BCNF, típicamente cuando la relación tiene múltiples claves candidatas compuestas que se solapan. BCNF elimina todas las anomalías derivadas de dependencias funcionales, aunque puede requerir descomposiciones que no preserven todas las dependencias.

Cuarta Forma Normal (4FN)

La cuarta forma normal trata dependencias multivaluadas, que ocurren cuando la presencia de un valor de un atributo determina un conjunto de valores de otro atributo, independientemente de otros atributos. Una relación está en 4FN si está en BCNF y no contiene dependencias multivaluadas no triviales. Por ejemplo, si un profesor puede enseñar múltiples asignaturas y tener múltiples títulos, y estas son independientes entre sí, se crea una dependencia multivaluada que genera redundancia. La solución es separar las dependencias multivaluadas en relaciones distintas.

Quinta Forma Normal (5FN)

La quinta forma normal, también llamada Forma Normal de Proyección-Join (PJNF), trata dependencias de join. Una relación está en 5FN si no se puede descomponer sin pérdida en relaciones más pequeñas. Es la forma normal más restrictiva y raramente se alcanza en bases de datos prácticas. Está relacionada con situaciones donde la información solo puede representarse completamente mediante la join de tres o más relaciones, y cualquier combinación de solo dos de ellas pierde información o introduce redundancia.

4.4. Desnormalización

Aunque la normalización es generalmente deseable, en ocasiones se aplica desnormalización deliberada para optimizar el rendimiento. La desnormalización introduce redundancia controlada para reducir el número de joins necesarios en consultas frecuentes o críticas. Por ejemplo, en un sistema de comercio electrónico, podría almacenarse el nombre del producto tanto en la tabla de productos como en la tabla de detalles de pedido, para evitar joins al listar pedidos históricos. La desnormalización debe documentarse cuidadosamente y acompañarse de mecanismos (como triggers) para mantener la consistencia de los datos duplicados.

5. Álgebra y Cálculo Relacional

5.1. Álgebra Relacional

El álgebra relacional es un lenguaje procedimental que consiste en un conjunto de operaciones que toman una o dos relaciones como entrada y producen una nueva relación como resultado. Esta propiedad de clausura (el resultado de una operación es del mismo tipo que los operandos) permite componer operaciones complejas a partir de operaciones básicas. El álgebra relacional proporciona la fundamentación formal para los lenguajes de consulta y es utilizada internamente por los optimizadores de consultas para representar y transformar consultas.

Operaciones Básicas

Selección (σ): La operación de selección extrae tuplas de una relación que satisfacen un predicado dado. Se denota σ_predicado(R). Por ejemplo, σ_edad>30(EMPLEADO) devuelve todos los empleados mayores de treinta años. La selección es conmutativa: σ_p1(σ_p2(R)) = σ_p2(σ_p1(R)) = σ_p1∧p2(R).

Proyección (π): La proyección extrae ciertas columnas de una relación, eliminando las demás y eliminando tuplas duplicadas. Se denota π_atributos(R). Por ejemplo, π_{nombre,departamento}(EMPLEADO) devuelve solo los nombres y departamentos de los empleados. La proyección puede reducir la cardinalidad de la relación al eliminar duplicados.

Unión (∪): La unión combina tuplas de dos relaciones eliminando duplicados. Las relaciones deben ser unión-compatibles (mismo número de atributos con dominios correspondientes compatibles). R ∪ S contiene todas las tuplas que están en R, en S, o en ambas. Es conmutativa y asociativa.

Diferencia (−): La diferencia R − S devuelve tuplas que están en R pero no en S. Las relaciones deben ser unión-compatibles. La diferencia no es conmutativa: R − S ≠ S − R.

Producto Cartesiano (×): El producto cartesiano R × S combina cada tupla de R con cada tupla de S. Si R tiene n tuplas y m atributos, y S tiene p tuplas y q atributos, el resultado tiene n×p tuplas y m+q atributos. El producto cartesiano es conmutativo.

Renombrado (ρ): La operación de renombrado cambia el nombre de una relación o sus atributos. Se denota ρ_X(R) para renombrar la relación, o ρ_{(A1,A2,…,An)}(R) para renombrar atributos. Es útil para resolver ambigüedades y permitir auto-joins.

Operaciones Derivadas

Intersección (∩): R ∩ S = R − (R − S). Devuelve tuplas presentes en ambas relaciones. Es conmutativa y asociativa.

Join Natural (⋈): R ⋈ S combina tuplas de R y S que tienen valores iguales en todos los atributos comunes, eliminando columnas duplicadas. Equivale a π_atributos(σ_{R.A=S.A∧…}(R × S)).

Theta Join (⋈_θ): R ⋈_θ S = σ_θ(R × S), donde θ es una condición arbitraria. Es un producto cartesiano seguido de una selección.

Equijoin: Un theta join donde la condición solo contiene igualdades. Es la base del join natural.

Join Externo (Outer Join): Preserva tuplas que no tienen correspondencia en la otra relación, rellenando con valores nulos. Puede ser left outer join (⟕), right outer join (⟖), o full outer join (⟗).

División (÷): R(X,Y) ÷ S(Y) devuelve todas las X de R que están asociadas con todas las Y de S. Es útil para consultas del tipo «encontrar todos los X que están relacionados con todos los Y». Por ejemplo, «estudiantes matriculados en todas las asignaturas».

5.2. Cálculo Relacional

El cálculo relacional es un lenguaje declarativo basado en la lógica de predicados de primer orden. A diferencia del álgebra relacional que especifica cómo obtener el resultado, el cálculo relacional especifica qué tuplas deben estar en el resultado sin indicar cómo obtenerlas. Existen dos variantes: el cálculo relacional de tuplas y el cálculo relacional de dominios.

Cálculo Relacional de Tuplas

En el cálculo relacional de tuplas, las variables representan tuplas completas. Una consulta tiene la forma {t | P(t)} donde t es una variable de tupla y P(t) es una fórmula lógica que especifica las condiciones que debe cumplir t. Por ejemplo, para encontrar empleados con salario mayor a cincuenta mil: {e | EMPLEADO(e) ∧ e.salario > 50000}. Las fórmulas pueden incluir cuantificadores existenciales (∃) y universales (∀), conectivos lógicos (∧, ∨, ¬), y operadores de comparación.

Cálculo Relacional de Dominios

En el cálculo relacional de dominios, las variables representan valores de dominios individuales en lugar de tuplas completas. Una consulta especifica qué valores deben tener ciertos atributos. Por ejemplo: {n, s | ∃d(EMPLEADO(n, d, s) ∧ s > 50000)} devuelve nombres y salarios de empleados con salario mayor a cincuenta mil, donde n representa nombre, s representa salario, y d representa departamento.

Equivalencia y Poder Expresivo

El álgebra relacional y el cálculo relacional son equivalentes en poder expresivo: cualquier consulta expresable en álgebra relacional puede expresarse en cálculo relacional y viceversa. Esta equivalencia fue demostrada por Codd y es fundamental porque establece que SQL, basado en el cálculo relacional de tuplas, tiene el mismo poder expresivo que el álgebra relacional. El teorema de Codd establece que un lenguaje de consulta es «relacionalmente completo» si puede expresar todas las consultas expresables en álgebra relacional básica.

6. Modelo Entidad-Relación (ER)

6.1. Fundamentos del Modelo ER

El modelo Entidad-Relación, propuesto por Peter Chen en 1976, es una técnica de modelado conceptual de alto nivel para el diseño de bases de datos. Proporciona una representación gráfica intuitiva de la estructura de información de un dominio de aplicación, independiente de consideraciones de implementación. El modelo ER se centra en identificar los objetos importantes del mundo real (entidades), sus propiedades (atributos), y cómo se relacionan entre sí (relaciones).

6.2. Componentes del Modelo ER

Entidades

Una entidad es un objeto distinguible del mundo real con existencia independiente, ya sea física (una persona, un producto) o conceptual (un curso, una transacción). El conjunto de todas las entidades del mismo tipo forma un tipo de entidad o conjunto de entidades. En los diagramas ER, las entidades se representan mediante rectángulos. Por ejemplo, EMPLEADO, DEPARTAMENTO, PROYECTO son tipos de entidad típicos en una base de datos organizacional.

Atributos

Los atributos describen las propiedades de las entidades. Cada atributo tiene un dominio de valores permitidos. Los atributos se clasifican en varias categorías. Los atributos simples son atómicos e indivisibles (como el DNI). Los atributos compuestos pueden dividirse en partes más pequeñas (como una dirección en calle, ciudad, código postal). Los atributos monovaluados toman un solo valor por entidad, mientras que los multivaluados pueden tomar múltiples valores (como números de teléfono). Los atributos derivados se calculan a partir de otros atributos (como la edad a partir de la fecha de nacimiento). En los diagramas ER, los atributos se representan con óvalos conectados a su entidad.

Relaciones

Una relación es una asociación entre dos o más entidades. Por ejemplo, un empleado «trabaja en» un departamento. El grado de una relación es el número de entidades participantes: binarias (grado dos), ternarias (grado tres), etc. Las relaciones pueden tener sus propios atributos descriptivos, llamados atributos de relación. Por ejemplo, la relación «trabaja en» podría tener un atributo «fecha_inicio» indicando cuándo el empleado comenzó en ese departamento.

Cardinalidades

La cardinalidad especifica el número de instancias de una entidad que pueden asociarse con instancias de otra entidad a través de una relación. Las cardinalidades principales son uno a uno (1:1) donde cada instancia de A se relaciona con a lo sumo una instancia de B y viceversa; uno a muchos (1:N) donde cada instancia de A puede relacionarse con múltiples instancias de B, pero cada B con a lo sumo una A; y muchos a muchos (N:M) donde cada instancia de ambas entidades puede relacionarse con múltiples instancias de la otra. La cardinalidad se representa mediante números o símbolos en las líneas que conectan entidades con relaciones.

Participación

La participación indica si todas las instancias de una entidad deben participar en una relación. La participación total (o existencial) requiere que todas las instancias participen, representada con línea doble en el diagrama. La participación parcial permite que algunas instancias no participen, representada con línea simple. Por ejemplo, si todo empleado debe estar asignado a un departamento, EMPLEADO tiene participación total en la relación «trabaja en».

Entidades Débiles

Una entidad débil es aquella que no puede identificarse únicamente por sus propios atributos y depende de otra entidad (llamada entidad propietaria o fuerte) para su identificación. Por ejemplo, un DEPENDIENTE de un empleado podría ser una entidad débil, identificada por su nombre junto con el identificador del empleado del cual depende. Las entidades débiles se representan con rectángulos de doble línea, y su relación de identificación con la entidad fuerte se representa con un rombo de doble línea.

6.3. Modelo ER Extendido (EER)

El modelo ER Extendido añade conceptos de modelado más avanzados para capturar semántica más compleja. La especialización permite definir subclases de un tipo de entidad basándose en características distintivas. Por ejemplo, EMPLEADO puede especializarse en INGENIERO y GERENTE. La generalización es el proceso inverso: combinar tipos de entidad similares en una superclase. La herencia permite que las subclases hereden atributos de la superclase. La especialización puede ser total (todo miembro de la superclase debe pertenecer a alguna subclase) o parcial, y disjunta (las subclases son mutuamente exclusivas) o superpuesta (pueden solaparse).

6.4. Transformación de ER a Modelo Relacional

La transformación de un diagrama ER a un esquema relacional sigue reglas sistemáticas. Cada tipo de entidad fuerte se convierte en una tabla, con los atributos simples convirtiéndose en columnas. La clave candidata de la entidad se convierte en clave primaria de la tabla. Los atributos compuestos se aplanan incluyendo solo sus componentes atómicos. Los atributos multivaluados se representan mediante una tabla separada con una clave foránea referenciando la entidad original. Los atributos derivados típicamente se omiten del esquema relacional.

Las relaciones binarias uno a uno pueden implementarse añadiendo la clave primaria de una entidad como clave foránea en la otra (preferiblemente en la entidad con participación total). Las relaciones uno a muchos se implementan añadiendo la clave primaria del lado «uno» como clave foránea en el lado «muchos». Las relaciones muchos a muchos requieren una tabla de relación separada que contenga las claves primarias de ambas entidades participantes como clave foránea compuesta.

Las entidades débiles se convierten en tablas incluyendo una clave foránea que referencia la entidad propietaria. La clave primaria de la entidad débil es compuesta, combinando la clave foránea con su discriminador parcial. Para jerarquías de especialización, existen tres estrategias: crear una tabla única con todos los atributos de superclase y subclases (incluyendo un atributo tipo), crear tablas solo para las subclases incluyendo atributos heredados, o crear tablas para todos los niveles con claves foráneas conectándolas.

7. El Lenguaje SQL

7.1. Historia y Evolución de SQL

SQL (Structured Query Language) fue desarrollado originalmente en IBM en los años setenta por Donald Chamberlin y Raymond Boyce, inicialmente llamado SEQUEL (Structured English Query Language). Se diseñó como lenguaje de consulta para el sistema System R, uno de los primeros prototipos de sistemas de bases de datos relacionales. El lenguaje fue estandarizado por primera vez por ANSI en 1986 (SQL-86), seguido por SQL-89, que añadió integridad referencial.

SQL-92 (también conocido como SQL2) fue una revisión mayor que añadió joins explícitos, operaciones de conjuntos, y capacidades mejoradas. SQL:1999 (SQL3) introdujo características objeto-relacionales, triggers, tipos definidos por usuario, y expresiones regulares. SQL:2003 añadió funciones ventana, secuencias, y características XML. SQL:2008 introdujo el operador MERGE y mejoras en TRUNCATE. SQL:2011 añadió soporte temporal para datos históricos. SQL:2016 introdujo búsqueda de patrones en filas y mejoras en JSON. SQL:2023, el estándar más reciente, añade capacidades para grafos de propiedades y JSON mejorado.

7.2. Componentes de SQL

DDL – Data Definition Language

El lenguaje de definición de datos permite crear, modificar y eliminar estructuras de base de datos. Los comandos principales incluyen CREATE para crear objetos (tablas, índices, vistas, esquemas), ALTER para modificar estructuras existentes, DROP para eliminar objetos, y TRUNCATE para vaciar tablas rápidamente. DDL también permite definir restricciones de integridad como claves primarias, claves foráneas, restricciones CHECK, y valores por defecto.

CREATE TABLE EMPLEADO (
    empleado_id INT PRIMARY KEY,
    nombre VARCHAR(100) NOT NULL,
    fecha_nacimiento DATE,
    salario DECIMAL(10,2) CHECK (salario >= 0),
    departamento_id INT,
    FOREIGN KEY (departamento_id) 
        REFERENCES DEPARTAMENTO(departamento_id)
        ON DELETE SET NULL
        ON UPDATE CASCADE
);

DML – Data Manipulation Language

El lenguaje de manipulación de datos permite consultar y modificar los datos. SELECT recupera datos de una o más tablas, soportando filtrado (WHERE), agrupación (GROUP BY), ordenación (ORDER BY), joins, subconsultas, y operaciones de conjuntos. INSERT añade nuevas filas a una tabla. UPDATE modifica filas existentes. DELETE elimina filas. Estos comandos pueden afectar múltiples filas simultáneamente mediante condiciones WHERE apropiadas.

SELECT d.nombre_departamento, 
       AVG(e.salario) as salario_promedio,
       COUNT(*) as num_empleados
FROM EMPLEADO e
INNER JOIN DEPARTAMENTO d ON e.departamento_id = d.departamento_id
WHERE e.fecha_contratacion >= '2020-01-01'
GROUP BY d.nombre_departamento
HAVING AVG(e.salario) > 40000
ORDER BY salario_promedio DESC;

DCL – Data Control Language

El lenguaje de control de datos gestiona permisos y autorización. GRANT otorga privilegios a usuarios o roles sobre objetos de base de datos. REVOKE retira privilegios previamente otorgados. Los privilegios pueden ser granulares (SELECT, INSERT, UPDATE, DELETE sobre tablas específicas) o más amplios (ALL PRIVILEGES). Los roles permiten agrupar privilegios y asignarlos colectivamente a usuarios.

TCL – Transaction Control Language

El lenguaje de control de transacciones gestiona transacciones. COMMIT confirma permanentemente los cambios realizados en la transacción actual. ROLLBACK deshace todos los cambios desde el inicio de la transacción o desde el último COMMIT. SAVEPOINT crea puntos de control intermedios dentro de una transacción, permitiendo rollback parcial. SET TRANSACTION configura características de la transacción como nivel de aislamiento.

7.3. Características Avanzadas de SQL

Subconsultas

Las subconsultas son consultas anidadas dentro de otra consulta. Pueden ser escalares (devuelven un solo valor), de fila (devuelven una fila), de columna (devuelven múltiples filas de una columna), o de tabla (devuelven múltiples filas y columnas). Pueden aparecer en cláusulas SELECT, FROM, WHERE, o HAVING. Las subconsultas correlacionadas hacen referencia a tablas de la consulta externa y se ejecutan una vez por cada fila de la consulta externa.

Funciones de Ventana

Las funciones de ventana (introducidas en SQL:2003) realizan cálculos sobre un conjunto de filas relacionadas con la fila actual, sin colapsar el conjunto de resultados como haría GROUP BY. Permiten operaciones como numeración de filas (ROW_NUMBER), clasificación (RANK, DENSE_RANK), agregaciones móviles, y acceso a filas adyacentes (LAG, LEAD). Se definen mediante la cláusula OVER con especificaciones de partición y orden.

CTE – Common Table Expressions

Las expresiones de tabla común permiten definir conjuntos de resultados temporales con nombre que pueden referenciarse dentro de una consulta. Se definen con la cláusula WITH y mejoran la legibilidad de consultas complejas. Los CTE recursivos permiten consultas que referencian a sí mismas, útiles para procesar jerarquías o grafos, como estructuras organizacionales o árboles de categorías.

Vistas

Una vista es una tabla virtual definida por una consulta. Las vistas proporcionan abstracción de datos, simplifican consultas complejas, y mejoran la seguridad al restringir el acceso a ciertas filas o columnas. Las vistas simples (sobre una tabla, sin agregaciones) son generalmente actualizables. Las vistas materializadas almacenan físicamente los resultados y se actualizan periódicamente, mejorando el rendimiento de consultas complejas a cambio de posible desactualización de datos.

Procedimientos Almacenados y Triggers

Los procedimientos almacenados son programas guardados en la base de datos que encapsulan lógica de negocio compleja. Aceptan parámetros, pueden contener lógica condicional y bucles, y mejoran el rendimiento al reducir el tráfico de red. Los triggers son procedimientos que se ejecutan automáticamente en respuesta a eventos específicos (INSERT, UPDATE, DELETE) en una tabla. Pueden ejecutarse BEFORE o AFTER el evento, y tienen acceso a los valores OLD y NEW de las filas afectadas.

8. Normas y Estándares para la Interoperabilidad

8.1. El Estándar SQL ISO/IEC

El estándar SQL está definido conjuntamente por ISO (International Organization for Standardization) e IEC (International Electrotechnical Commission). El estándar completo se denomina ISO/IEC 9075 y consta de múltiples partes que cubren diferentes aspectos del lenguaje. La parte uno define el marco general y conceptos, la parte dos especifica la fundación del lenguaje SQL (Core SQL), la parte tres define la invocación a SQL desde otros lenguajes (SQL/CLI y embedded SQL), y partes adicionales cubren aspectos como tipos definidos por usuario, XML, JSON, y funciones de programación.

8.2. ODBC – Open Database Connectivity

ODBC es un estándar de facto desarrollado originalmente por Microsoft para acceso a bases de datos desde aplicaciones Windows, posteriormente adoptado como estándar por el grupo X/Open. Define una API de nivel de llamada (Call Level Interface) que permite a aplicaciones escritas en C o C++ conectarse y operar sobre diferentes SGBD mediante drivers específicos. ODBC proporciona una capa de abstracción que aísla la aplicación de las particularidades de cada SGBD. La arquitectura ODBC consta de cuatro componentes: la aplicación, el gestor de drivers (Driver Manager), el driver específico del SGBD, y la fuente de datos (el SGBD mismo).

Los drivers ODBC pueden ser de un nivel (la aplicación accede directamente a archivos de datos) o multinivel (el driver traduce llamadas ODBC a llamadas del SGBD). ODBC soporta múltiples niveles de conformidad API (Core, Level uno, Level dos) que especifican qué funciones están disponibles. Las aplicaciones configuran Data Source Names (DSN) que encapsulan información de conexión, permitiendo cambiar de SGBD sin modificar código de aplicación.

8.3. JDBC – Java Database Connectivity

JDBC es el estándar de Java para conectividad con bases de datos, parte de la Java Platform Standard Edition. Define una API orientada a objetos que permite ejecutar operaciones SQL desde código Java de manera independiente del SGBD. La arquitectura JDBC es similar a ODBC: las aplicaciones Java usan la API JDBC, que se comunica con drivers específicos del SGBD.

Existen cuatro tipos de drivers JDBC. El tipo uno (puente JDBC-ODBC, deprecado) traduce llamadas JDBC a ODBC. El tipo dos (driver parcialmente Java) usa código nativo para comunicarse con el SGBD. El tipo tres (driver de middleware) se comunica con un servidor intermedio que traduce a protocolo específico del SGBD. El tipo cuatro (driver Java puro) implementa directamente el protocolo de red del SGBD en Java puro, siendo el más eficiente y portable.

JDBC incluye características avanzadas como soporte para procedimientos almacenados, prepared statements (consultas precompiladas para mejor rendimiento y seguridad), gestión de transacciones con diferentes niveles de aislamiento, manejo de tipos de datos específicos de SGBD mediante ResultSet, y batch updates para operaciones masivas eficientes.

8.4. ADO.NET

ADO.NET es la tecnología de acceso a datos de Microsoft para aplicaciones .NET Framework y .NET Core. Proporciona un conjunto de componentes para acceso eficiente a bases de datos relacionales y otras fuentes de datos. ADO.NET soporta dos modos de operación: conectado (usando objetos Connection, Command, DataReader) y desconectado (usando DataSet y DataAdapter).

El modo desconectado es particularmente innovador: permite cargar datos en memoria, trabajar con ellos offline, y posteriormente sincronizar cambios con la base de datos. Los data providers específicos de SGBD (SqlClient para SQL Server, OracleClient para Oracle, etc.) implementan la funcionalidad core. Entity Framework, construido sobre ADO.NET, proporciona un marco ORM (Object-Relational Mapping) que permite trabajar con datos como objetos .NET en lugar de tablas y filas.

8.5. Conectividad Moderna

Las tecnologías más recientes de acceso a datos incluyen ORMs (Object-Relational Mappers) como Hibernate para Java, Entity Framework para .NET, Django ORM para Python, y Active Record para Ruby. Estos marcos proporcionan una capa de abstracción completa que mapea objetos del lenguaje de programación a tablas de base de datos, generando automáticamente SQL y gestionando relaciones.

Las arquitecturas de microservicios han popularizado APIs REST y GraphQL como interfaces de acceso a datos, con el SGBD accesible solo desde servicios backend. Los conectores nativos específicos de SGBD (como psycopg2 para PostgreSQL en Python, mysql-connector para MySQL) ofrecen mejor rendimiento que interfaces genéricas. Los pools de conexiones optimizan el uso de recursos reutilizando conexiones establecidas. Las bibliotecas async/await modernas permiten acceso asíncrono no bloqueante para alto rendimiento en aplicaciones concurrentes.

9. Principales SGBD Comerciales

9.1. Oracle Database

Oracle Database es el SGBD comercial más establecido y ampliamente utilizado en entornos empresariales de misión crítica. Desarrollado por Oracle Corporation desde 1977, actualmente en su versión 23c (2024), ofrece características empresariales avanzadas incluyendo Real Application Clusters (RAC) para alta disponibilidad mediante servidores agrupados, Active Data Guard para réplicas síncronas y asíncronas, particionamiento avanzado para gestión de grandes volúmenes, compresión y encriptación transparentes, y Autonomous Database que utiliza machine learning para autotuning y autopatch.

Oracle se destaca por su rendimiento en cargas OLTP de alta concurrencia, su extenso ecosistema de herramientas (Oracle Enterprise Manager, SQL Developer, APEX), y características avanzadas como flashback para recuperación a punto en el tiempo, materalized views con refresh incremental, y soporte para JSON, XML y datos espaciales. El modelo de licenciamiento se basa en procesadores o usuarios nombrados, con costos significativos que lo posicionan en el segmento enterprise. Oracle Exadata son appliances integrados hardware-software optimizados para máximo rendimiento.

9.2. Microsoft SQL Server

Microsoft SQL Server es el SGBD de Microsoft, fuertemente integrado con el ecosistema Windows y Azure. La versión actual es SQL Server 2022, aunque muchas organizaciones utilizan SQL Server 2019 o versiones anteriores. Características destacables incluyen Integration Services (SSIS) para ETL, Analysis Services (SSAS) para cubos OLAP y modelos tabulares, Reporting Services (SSRS) para generación de informes, Always On Availability Groups para alta disponibilidad, columnstore indexes para cargas analíticas, e in-memory OLTP para máximo rendimiento transaccional.

SQL Server Management Studio (SSMS) es un entorno integral de administración muy apreciado por su usabilidad. Azure SQL Database es la versión cloud completamente gestionada, con variantes como SQL Managed Instance que ofrece mayor compatibilidad con SQL Server on-premise. SQL Server Express es una edición gratuita con limitaciones de tamaño y recursos, adecuada para aplicaciones pequeñas. El licenciamiento se basa en cores de procesador o usuarios simultáneos (CAL – Client Access License).

9.3. IBM Db2

IBM Db2 (Database 2) tiene una larga historia desde los años ochenta y sigue siendo relevante en entornos mainframe y empresariales, especialmente en sectores financieros y gubernamentales. Db2 11.5 y Db2 Warehouse son versiones actuales. Características clave incluyen soporte nativo para mainframe z/OS con integración CICS y IMS, particionamiento multi-dimensional para data warehousing, BLU Acceleration con compresión columnar y procesamiento in-memory, soporte para JSON, XML y datos temporales, y Db2 pureScale para escalabilidad horizontal con arquitectura shared-disk.

Db2 se distingue por su robustez en entornos de alto volumen transaccional, integración profunda con herramientas IBM (WebSphere, InfoSphere), y optimización para cargas mixtas OLTP/OLAP. IBM Cloud Pak for Data integra Db2 en una plataforma unificada de datos e IA. El licenciamiento puede ser perpetuo o por suscripción, basado en procesadores virtuales o PVUs (Processor Value Units).

9.4. SAP HANA

SAP HANA es una plataforma in-memory más reciente (lanzada en 2010) que combina funcionalidades de base de datos relacional, procesamiento analítico, y capa de aplicación. A diferencia de los SGBD tradicionales basados en disco, HANA mantiene todos los datos en memoria RAM, logrando velocidades de consulta órdenes de magnitud superiores. Utiliza compresión columnar agresiva que permite mantener datasets masivos en memoria a costo razonable.

HANA soporta cargas OLTP y OLAP simultáneamente sin réplicas (HTAP – Hybrid Transactional/Analytical Processing), procesamiento de texto completo avanzado, predicción y machine learning integrados, y replicación asíncrona para disaster recovery. Es la plataforma preferida para aplicaciones SAP S/4HANA ERP. Los requisitos de hardware son exigentes (grandes cantidades de RAM) y el costo es elevado, posicionándolo en el segmento enterprise premium. SAP HANA Cloud ofrece la solución como servicio completamente gestionado.

10. SGBD de Código Abierto

10.1. PostgreSQL

PostgreSQL, frecuentemente llamado Postgres, es ampliamente considerado el SGBD relacional de código abierto más avanzado. Originado en el proyecto POSTGRES de la Universidad de California Berkeley en 1986, ha evolucionado hasta convertirse en un sistema de nivel enterprise completo. La versión actual es PostgreSQL 16 (2024), con PostgreSQL 17 en desarrollo.

Características distintivas incluyen cumplimiento extremadamente riguroso con estándares SQL, soporte para tipos de datos avanzados (arrays, hstore, JSON/JSONB, XML, tipos geométricos), extensibilidad mediante funciones definidas por usuario en múltiples lenguajes (PL/pgSQL, Python, Perl, C), índices avanzados (B-tree, Hash, GiST, SP-GiST, GIN, BRIN), replicación streaming nativa con replicas síncronas y asíncronas, y control de concurrencia MVCC (Multi-Version Concurrency Control) que permite alto rendimiento en lecturas concurrentes.

PostgreSQL se destaca por su extensibilidad: extensiones populares incluyen PostGIS para datos geoespaciales (estándar de facto en GIS), TimescaleDB para series temporales, Citus para distribución horizontal, pgvector para vectores de embeddings de IA, y pg_stat_statements para análisis de rendimiento. La comunidad PostgreSQL es muy activa con conferencias globales, documentación excelente y soporte comercial disponible de múltiples vendors (EnterpriseDB, Crunchy Data, 2ndQuadrant).

10.2. MySQL y MariaDB

MySQL es probablemente el SGBD de código abierto más popular históricamente, especialmente en aplicaciones web (stack LAMP: Linux, Apache, MySQL, PHP). Creado en 1995 por MySQL AB, fue adquirido por Sun Microsystems en 2008 y posteriormente por Oracle Corporation en 2010. La versión actual es MySQL 8.4 (2024), que introdujo mejoras significativas en rendimiento, características JSON, y ventanas analíticas.

MySQL Community Edition es completamente gratuito bajo licencia GPL, mientras que MySQL Enterprise Edition ofrece funcionalidades adicionales, herramientas de monitorización, y soporte comercial. Características incluyen múltiples motores de almacenamiento (InnoDB es el predeterminado, soporta transacciones ACID; MyISAM para tablas de solo lectura rápidas), replicación maestro-esclavo y maestro-maestro, Group Replication para alta disponibilidad, MySQL Cluster para escalabilidad horizontal con arquitectura shared-nothing, y MySQL Router para proxy transparente.

MariaDB surgió como un fork de MySQL en 2009 cuando la comunidad estaba preocupada por la adquisición de Oracle. Liderada por el creador original de MySQL Michael Widenius, MariaDB mantiene alta compatibilidad con MySQL pero ha divergido añadiendo características propias como motores de almacenamiento alternativos (Aria, ColumnStore para analytics), Galera Cluster integrado para multi-master replication, y características de SQL avanzadas antes que MySQL. MariaDB Server es completamente código abierto; MariaDB Enterprise ofrece soporte y herramientas adicionales.

10.3. SQLite

SQLite es único entre los SGBD: es una biblioteca C embebida en la aplicación en lugar de un proceso servidor separado. La base de datos completa se almacena en un solo archivo portable entre plataformas. SQLite es probablemente la base de datos más desplegada en el mundo, utilizada en prácticamente todos los smartphones (Android e iOS), navegadores web (almacenamiento local), aplicaciones de escritorio, y dispositivos IoT.

SQLite es ideal para aplicaciones embebidas, prototipos rápidos, almacenamiento local en aplicaciones móviles y desktop, y datasets de tamaño pequeño a mediano que no requieren acceso concurrente de escritura. Sus limitaciones incluyen falta de soporte para concurrencia de escritura (solo un escritor a la vez), sin usuarios ni permisos, sin procedimientos almacenados nativos, y tipos de datos dinámicos flexibles pero menos estrictos que otros SGBD. Es completamente de dominio público (no requiere atribución ni licencia), extremadamente estable, bien documentado, y sorprendentemente capaz para su simplicidad.

10.4. Otros SGBD de Código Abierto

Firebird es un SGBD completo descendiente de Borland InterBase, con soporte ACID completo, procedimientos almacenados, triggers, y deployment embebido o cliente-servidor. Es popular en aplicaciones legacy y en algunos países de Europa del Este. Apache Derby (también conocido como Java DB) es un SGBD escrito completamente en Java, embebible en aplicaciones Java, con footprint pequeño. H2 Database es un SGBD Java más moderno y rápido que Derby, con modos embebido y servidor, compatible con PostgreSQL y MySQL, popular en testing y desarrollo.

CockroachDB, aunque más reciente (2015) y con modelo de negocio diferente (core open source, enterprise propietario), merece mención como base de datos distribuida SQL que implementa el modelo relacional sobre arquitectura distribuida inspirada en Google Spanner, con consistencia fuerte y resiliencia ante fallos de nodos o datacenters completos.

11. Mapa Conceptual del Modelo Relacional

12. Preguntas de Test – Evaluación de Conocimientos

13. Respuestas Correctas y Justificaciones

14. Referencias Bibliográficas

14.1. Libros Fundamentales

• Elmasri, R. & Navathe, S. B. (2023). Fundamentals of Database Systems (8th ed.). Pearson. – Texto universitario completo sobre bases de datos, considerado el estándar en educación.
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. – Cobertura exhaustiva de teoría y práctica de sistemas de bases de datos.
• Date, C. J. (2019). Database Design and Relational Theory: Normal Forms and All That Jazz (2nd ed.). Apress. – Tratamiento riguroso de la teoría relacional y normalización.
• Ramakrishnan, R. & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill. – Enfoque equilibrado entre teoría e implementación práctica.
• Codd, E. F. (1990). The Relational Model for Database Management: Version 2. Addison-Wesley. – Obra definitiva del creador del modelo relacional.

14.2. Estándares y Especificaciones

• ISO/IEC 9075:2023. Information technology — Database languages — SQL. International Organization for Standardization.
• ANSI X3.135-1992. Database Language SQL. American National Standards Institute.
• Microsoft Corporation. (2024). SQL Server 2022 Documentation. https://docs.microsoft.com/sql/
• Oracle Corporation. (2024). Oracle Database 23c Documentation. https://docs.oracle.com/database/
• PostgreSQL Global Development Group. (2024). PostgreSQL 16 Documentation. https://www.postgresql.org/docs/

14.3. Documentación Técnica de SGBD

• PostgreSQL Documentation. (2024). The PostgreSQL Global Development Group. https://www.postgresql.org/docs/ – Documentación oficial extremadamente completa y bien organizada.
• MySQL Reference Manual. (2024). Oracle Corporation. https://dev.mysql.com/doc/ – Documentación oficial de MySQL 8.x.
• MariaDB Knowledge Base. (2024). MariaDB Foundation. https://mariadb.com/kb/ – Documentación oficial de MariaDB Server.
• SQLite Documentation. (2024). SQLite Development Team. https://www.sqlite.org/docs.html – Documentación completa del motor embebido.
• IBM Db2 Documentation. (2024). IBM Corporation. https://www.ibm.com/docs/db2 – Recursos oficiales de Db2.

14.4. Artículos Académicos Seminales

• Codd, E. F. (1970). «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM, 13(6), 377-387. – El artículo fundacional del modelo relacional.
• Codd, E. F. (1985). «Is Your Database Really Relational?» y «Does Your DBMS Run By the Rules?». ComputerWorld. – Artículos donde Codd presenta sus 12 reglas.
• Chen, P. P. (1976). «The Entity-Relationship Model: Toward a Unified View of Data». ACM Transactions on Database Systems, 1(1), 9-36. – Introducción del modelo ER.
• Fagin, R. (1977). «Multivalued Dependencies and a New Normal Form for Relational Databases». ACM Transactions on Database Systems, 2(3), 262-278. – Introducción de 4FN.
• Armstrong, W. W. (1974). «Dependency Structures of Data Base Relationships». IFIP Congress, 580-583. – Axiomas de Armstrong para dependencias funcionales.

14.5. Recursos Online y Tutoriales

• W3Schools SQL Tutorial. https://www.w3schools.com/sql/ – Tutorial interactivo excelente para principiantes en SQL.
• SQLZoo. https://sqlzoo.net/ – Plataforma interactiva para aprender y practicar SQL.
• DB-Engines Ranking. https://db-engines.com/ – Rankings actualizados de popularidad y características de SGBD.
• Stanford Database Course Materials. https://cs145-fa19.github.io/ – Materiales del curso CS145 de Stanford.
• Use The Index, Luke! https://use-the-index-luke.com/ – Guía excelente sobre indexación y optimización SQL.

14.6. Especificaciones de Conectividad

• Microsoft Corporation. (2024). ODBC API Reference. https://docs.microsoft.com/sql/odbc/ – Documentación oficial de la API ODBC.
• Oracle Corporation. (2024). JDBC API Specification. https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/ – Especificación JDBC oficial.
• X/Open Group. (1995). X/Open SQL and RDA Standards. The Open Group. – Estándares históricos de interoperabilidad SQL.
• IETF RFC 1006. (1987). ISO Transport Service on top of the TCP. – Estándares de protocolos de red para bases de datos.