Tema 34. El modelo relacional. Definiciones y conceptos básicos. Arquitectura. Diseño. Normalización. Manipulación: álgebra y cálculo relacional. Modelo entidad– relación. El lenguaje SQL. Normas y estándares para la interoperabilidad entre gestores de bases de datos relacionales. Principales SGBD comerciales. SGBD de código abierto.

Tema específico de Técnico/a Especialista en Informática

1. El modelo relacional

🎯 Idea clave

  • El modelo relacional fue propuesto por Edgar F. Codd en 1970 en Communications of the ACM como un paradigma basado en la teoría matemática de conjuntos.
  • Se fundamenta en el concepto de relación, entendida como un subconjunto del producto cartesiano de dominios, representada operativamente mediante tablas bidimensionales.
  • Codd estableció doce reglas teóricas en 1985 que definen los requisitos que debe cumplir un sistema de gestión de bases de datos para ser considerado verdaderamente relacional.
  • La normalización fue desarrollada originalmente por Codd junto con el modelo relacional como proceso formal para eliminar redundancias y anomalías en el diseño lógico.
  • El modelo garantiza el cierre relacional, permitiendo que las operaciones sobre relaciones devuelvan siempre relaciones como resultado.
  • SQL, desarrollado inicialmente por IBM como SEQUEL para el proyecto System R, se fundamenta en los conceptos teóricos de este modelo.

📚 Desarrollo

Origen académico. El modelo relacional fue propuesto por Edgar F. Codd en 1970 mediante su artículo publicado en Communications of the ACM. Este trabajo fundacional estableció un nuevo paradigma para la gestión de datos, sustituyendo los modelos jerárquicos y en red por una estructura basada en la teoría matemática de conjuntos.

Fundamento teórico. El modelo define una relación como un subconjunto del producto cartesiano de dominios, aplicando rigurosamente conceptos de la teoría de conjuntos. Esta base matemática garantiza la solidez formal del modelo, representando operativamente la información mediante estructuras bidimensionales compuestas por filas y columnas bajo reglas que preservan la validez y coherencia del dato.

Doce reglas de Codd. En 1985, Codd estableció una guía teórica compuesta por doce reglas que definen los requisitos fundamentales que debe cumplir un sistema de gestión de bases de datos para ser considerado verdaderamente relacional, estableciendo criterios sobre la representación lógica de la información y los mecanismos de acceso.

Desarrollo conjunto de la normalización. El proceso de normalización fue desarrollado originalmente por Codd junto con el modelo relacional como técnica formal de análisis y descomposición de relaciones. Su objetivo es eliminar redundancias y las anomalías de actualización que estas generan, preservando la semántica de los datos como elemento central del diseño lógico.

Cierre relacional y operaciones. El modelo define operaciones formales que toman relaciones como entrada y devuelven relaciones como resultado, propiedad conocida como cierre relacional. Esta característica permite componer consultas complejas mediante la anidación de operaciones simples sin salir del marco del modelo, sentando las bases para el álgebra relacional formalizada posteriormente.

Mecanismos de integridad. El modelo establece reglas de integridad mediante claves primarias, que identifican unívocamente cada fila garantizando su unicidad y ausencia de valores nulos, y claves foráneas que mantienen la coherencia referencial entre relaciones, exigiendo que los valores existan en la tabla referenciada o sean nulos.

Relación con SQL. SQL fue desarrollado inicialmente por IBM en los años setenta como SEQUEL, formando parte del proyecto System R, y se fundamenta en los conceptos teóricos del modelo relacional, combinando elementos del álgebra y el cálculo relacional para proporcionar un lenguaje declarativo estándar de manipulación de datos.

🧩 Elementos esenciales

  • Propuesta de 1970: Artículo fundacional de Codd en Communications of the ACM que estableció el paradigma relacional y sus fundamentos matemáticos.
  • Base teórica: Fundamentación en teoría de conjuntos donde una relación es un subconjunto del producto cartesiano de dominios.
  • Doce reglas: Criterios teóricos establecidos por Codd en 1985 para definir un sistema de gestión de bases de datos verdaderamente relacional.
  • Representación operativa: Estructuración de la información en tablas bidimensionales compuestas por filas y columnas que preservan la validez y coherencia.
  • Cierre relacional: Propiedad que garantiza que las operaciones sobre relaciones devuelvan siempre relaciones, permitiendo la composición de operaciones.
  • Integridad referencial: Reglas que aseguran que las claves foráneas correspondan a claves primarias existentes o sean nulas, manteniendo la coherencia entre tablas.
  • Normalización: Técnica desarrollada conjuntamente por Codd para el diseño lógico, destinada a eliminar redundancias y anomalías de actualización.
  • Valores nulos: El modelo asume inicialmente que todos los valores son conocidos, aunque posteriormente se desarrolló la lógica trivaluada para tratar información ausente.

🧠 Recuerda

  • Codd propuso el modelo relacional en 1970 en Communications of the ACM.
  • El modelo se basa en la teoría matemática de conjuntos y relaciones.
  • Una relación es formalmente un subconjunto del producto cartesiano de dominios.
  • Codd estableció doce reglas teóricas en 1985 para definir un SGBD relacional.
  • La normalización fue desarrollada por Codd junto con el modelo relacional.
  • El cierre relacional permite operar siempre con relaciones como entrada y salida.
  • Las claves primarias garantizan la identificación única de registros sin valores nulos.
  • Las claves foráneas mantienen la integridad referencial entre tablas.
  • SQL se fundamenta en los conceptos del modelo relacional y fue desarrollado inicialmente como SEQUEL por IBM.

2. Definiciones y conceptos básicos

🎯 Idea clave

  • Una base de datos relacional es aquella que se ajusta al modelo relacional, mientras que el RDBMS es el software que implementa dicho modelo y permite gestionar los datos.
  • La relación constituye el concepto teórico central y se representa operativamente mediante una tabla compuesta por filas y columnas.
  • Los dominios definen el conjunto de valores atómicos admisibles para cada atributo, garantizando la integridad de los datos.
  • Las claves primarias identifican unívocamente cada tupla, y las claves foráneas establecen las relaciones entre diferentes tablas.
  • El esquema describe la estructura lógica permanente, mientras que la instancia refleja el contenido variable en cada momento.
  • Las restricciones convierten en exigibles las reglas del modelo y refuerzan la calidad y consistencia de la información almacenada.

📚 Desarrollo

Definición fundamental. Una base de datos relacional es aquella que se ajusta al modelo relacional, y un RDBMS es el sistema de software que implementa este modelo permitiendo definir, almacenar y manipular los datos conforme a sus reglas. Esta distinción resulta esencial para comprender la arquitectura de los sistemas de información.

Estructura básica. La relación es el concepto teórico central del modelo, que en la práctica se representa operativamente mediante una tabla. Cada tabla contiene filas, equivalentes operativamente a tuplas, y columnas, equivalentes a atributos. Esta terminología dual —teórica y operativa— es omnipresente en el ámbito de las bases de datos.

Dominios y tipos. Cada atributo se asocia a un dominio que define el conjunto de valores atómicos admisibles del mismo tipo. Los dominios pueden ser predefinidos, como enteros o cadenas de texto, definidos por el usuario o tipos avanzados en sistemas modernos. El uso disciplinado de dominios refuerza la integridad y calidad de los datos.

Esquema e instancia. El esquema de una relación describe su estructura lógica mediante el nombre de la relación y la lista de atributos con sus dominios asociados, permaneciendo estable en el tiempo. La instancia o extensión representa el conjunto concreto de tuplas que contiene la relación en un momento dado, variando conforme se realizan operaciones de inserción, modificación o eliminación.

Sistema de claves. Una clave candidata es un conjunto mínimo de atributos cuyo valor identifica unívocamente cada tupla. De entre las candidatas se elige una como clave primaria, siendo las restantes claves alternativas. La clave foránea o ajena es un atributo o conjunto de atributos cuyos valores coinciden con la clave primaria de otra relación, estableciendo referencias entre entidades.

Propiedades y restricciones. Las relaciones presentan propiedades fundamentales derivadas de su naturaleza de conjunto: no existen tuplas duplicadas, el orden de las filas no es significativo, y cada celda contiene un valor atómico no descomponible. Las restricciones de integridad convierten en exigibles estas reglas, garantizando la calidad del dato y la consistencia del sistema.

🧩 Elementos esenciales

  • Relación: Concepto teórico central del modelo relacional, representado operativamente como una tabla bidimensional.
  • Tupla: Cada fila de una relación, correspondiente a un registro lógico concreto que representa una instancia de la entidad.
  • Atributo: Cada columna de una relación, también denominada campo, caracterizada por un nombre y un dominio asociado.
  • Dominio: Conjunto de valores atómicos del mismo tipo que define los valores admisibles para un atributo específico.
  • Esquema: Descripción de la estructura lógica de la relación que incluye su nombre y la lista de atributos con sus dominios.
  • Instancia: Conjunto concreto de tuplas que componen la relación en un momento determinado, susceptible de variación temporal.
  • Clave candidata: Conjunto mínimo de atributos que identifica de manera unívoca cada tupla dentro de la relación.
  • Clave primaria: Clave candidata seleccionada como identificador principal, que no admite valores nulos y debe permanecer estable.
  • Clave foránea: Atributo o conjunto de atributos que referencia la clave primaria de otra relación, materializando las relaciones entre entidades.
  • Integridad referencial: Regla que garantiza que no puede existir un registro con una clave foránea sin correspondencia en la tabla referenciada.
  • NULL: Valor especial que representa la ausencia de valor conocido o aplicable, distinto de cero o cadena vacía.

🧠 Recuerda

  • Una base de datos relacional se ajusta al modelo relacional, mientras que el RDBMS es el software que lo implementa.
  • Relación es el término teórico preciso; tabla es su representación operativa habitual en el uso práctico.
  • Cada celda de una relación debe contener un valor atómico, cumpliendo la condición de Primera Forma Normal.
  • El esquema describe la estructura permanente, mientras que la instancia refleja el contenido actual y variable.
  • La clave primaria identifica unívocamente cada tupla y no puede contener valores nulos ni modificarse constantemente.
  • Las claves foráneas establecen conexiones entre tablas y sostienen la integridad referencial del sistema.
  • Los dominios definen el tipo y rango de valores admisibles, previniendo incoherencias en los datos.
  • Una relación no puede contener tuplas duplicadas porque constituye un conjunto matemático.
  • El orden de las tuplas y de los atributos carece de significado conceptual en el modelo relacional.

3. Arquitectura

🎯 Idea clave

  • La arquitectura ANSI/SPARC de 1975 establece tres niveles de abstracción que separan la visión de usuario de la implementación física.
  • El nivel externo define vistas personalizadas de datos adaptadas a las necesidades de cada usuario o aplicación.
  • El nivel conceptual describe la estructura lógica global e integrada de toda la base de datos.
  • El nivel interno especifica las estructuras físicas de almacenamiento y los métodos de acceso en disco.
  • La arquitectura garantiza independencia física y lógica de los datos mediante mapeos entre niveles.
  • Los SGBD modernos incorporan componentes funcionales como procesador de consultas, gestores de almacenamiento y transacciones, y catálogo del sistema.

📚 Desarrollo

Marco conceptual fundamental. La arquitectura ANSI/X3/SPARC, propuesta en 1975 por el American National Standards Institute, constituye el modelo de referencia para los sistemas gestores de bases de datos relacionales. Este marco establece una organización en tres niveles de abstracción que separa la perspectiva de los usuarios de los detalles de implementación física, permitiendo evolucionar el sistema sin afectar a las aplicaciones existentes.

Nivel externo o de vistas. Corresponde a la visión particular que cada usuario o aplicación tiene de la base de datos. En este nivel se definen subconjuntos lógicos de datos adaptados a necesidades específicas, permitiendo múltiples vistas simultáneas sobre los mismos datos. Los usuarios operan con estas vistas sin necesidad de conocer la estructura completa ni la implementación física subyacente.

Nivel conceptual o lógico global. Representa el esquema integrado de toda la base de datos, describiendo entidades, relaciones, restricciones de integridad y semántica. Es el nivel del administrador de bases de datos y constituye la visión unificada y única de todos los datos almacenados en el sistema, independientemente de quién los utilice.

Nivel interno o físico. Especifica la representación física de los datos en el disco, incluyendo estructuras de almacenamiento, índices, páginas, bloques y tablespaces. Este nivel responde a cómo se materializan realmente los datos en el sistema de almacenamiento y cómo se accede a ellos físicamente.

Independencia de datos. La separación entre niveles garantiza dos tipos de independencia. La física permite modificar el almacenamiento o la indexación sin alterar el esquema conceptual. La lógica permite cambiar el esquema conceptual sin rehacer las vistas externas existentes, reduciendo el acoplamiento entre aplicaciones y datos.

Componentes funcionales modernos. Los SGBDR actuales incorporan elementos operativos como el procesador de consultas, el gestor de almacenamiento, el gestor de transacciones y el catálogo del sistema. Estos componentes materializan la arquitectura teórica en sistemas funcionales que gestionan memoria, procesos, concurrencia y recuperación.

Plano lógico y plano físico-operativo. El plano lógico abarca relaciones, atributos, dominios y restricciones, respondiendo qué datos existen y qué reglas deben cumplir. El plano físico-operativo comprende ficheros, páginas, índices, memoria, bloqueos y servicios de red, determinando cómo el sistema ejecuta realmente las operaciones manteniendo rendimiento y disponibilidad.

🧩 Elementos esenciales

  • ANSI/X3/SPARC: Comité que en 1975 propuso la arquitectura de tres niveles como modelo de referencia conceptual para SGBD.
  • Nivel externo: Conjunto de vistas personalizadas que cada aplicación o usuario tiene sobre la base de datos.
  • Nivel conceptual: Esquema global único que describe la estructura lógica completa, entidades y relaciones del sistema.
  • Nivel interno: Descripción única de la implementación física, almacenamiento y métodos de acceso a los datos.
  • Esquema externo: Puede existir pluralidad de esquemas externos simultáneos adaptados a distintos usuarios.
  • Esquema conceptual: Es único en cada base de datos y representa la visión integrada del administrador.
  • Esquema interno: Es único y define cómo se materializan los datos en el dispositivo de almacenamiento.
  • Independencia física: Capacidad de modificar el nivel interno sin alterar el esquema conceptual ni las vistas externas.
  • Independencia lógica: Posibilidad de cambiar el esquema conceptual sin modificar las vistas externas existentes.
  • Procesador de consultas: Componente funcional que analiza, optimiza y ejecuta las solicitudes de información.
  • Gestor de almacenamiento: Módulo que controla la ubicación física de datos e índices en disco.
  • Catálogo del sistema: Repositorio de metadatos que describe la estructura completa de la base de datos.

🧠 Recuerda

  • La arquitectura ANSI/SPARC data de 1975 y sigue siendo el modelo de referencia conceptual para SGBD.
  • Existen tres niveles: externo (vistas de usuario), conceptual (lógico global) e interno (físico).
  • Hay múltiples esquemas externos posibles, pero solo un esquema conceptual y uno interno en cada base de datos.
  • La independencia física protege el esquema conceptual de cambios en almacenamiento o indexación.
  • La independencia lógica protege las aplicaciones de cambios en la estructura global de datos.
  • Los mapeos entre niveles permiten traducir solicitudes de usuarios en operaciones físicas concretas.
  • El término "esquema" en el modelo ANSI difiere del uso de "schema" en productos comerciales como contenedor de objetos.
  • Los componentes funcionales modernos incluyen gestores de transacciones y procesadores de consultas.
  • El plano lógico responde al "qué" datos existen, mientras el físico responde al "cómo" se accede a ellos.
  • Los SGBD actuales implementan esta arquitectura aunque con distinto grado de explicitación.

4. Diseño

🎯 Idea clave

  • El diseño de bases de datos relacionales se estructura en tres fases secuenciales: conceptual, lógico y físico.
  • Cada fase utiliza modelos con distintos niveles de abstracción y grados de independencia tecnológica.
  • El diseño conceptual se basa en el modelo entidad-relación y requiere la participación de usuarios del dominio.
  • El diseño lógico traduce el esquema conceptual al modelo relacional aplicando reglas formales de transformación.
  • La normalización constituye un elemento central del diseño lógico encargado de eliminar redundancias y anomalías.
  • El diseño físico materializa el esquema en un SGBDR específico mediante tipos de datos, índices y estrategias de almacenamiento.

📚 Desarrollo

Proceso estructurado. El diseño de bases de datos relacionales sigue un método sistemático dividido en tres etapas diferenciadas que progresan desde la abstracción hacia la concreción tecnológica. Estas fases —conceptual, lógica y física— establecen un marco metodológico que garantiza la coherencia entre los requisitos del negocio y la implementación técnica final.

Diseño conceptual. Esta fase inicial emplea el modelo entidad-relación para representar el dominio del problema con total independencia de la tecnología. Participan activamente los usuarios del dominio junto con los técnicos para identificar entidades, atributos y relaciones estableciendo las cardinalidades correspondientes. El resultado es un esquema abstracto que captura la semántica de la información sin ataduras a ningún sistema gestor específico.

Transformación lógica. El diseño lógico convierte el esquema conceptual en un modelo relacional aplicando reglas precisas de traducción. Las entidades se convierten en tablas, las relaciones uno-a-muchos generan claves foráneas en la tabla correspondiente, y las relaciones muchos-a-muchos requieren la creación de tablas puente que albergan las claves foráneas de las entidades asociadas. Las entidades débiles incorporan la clave foránea de su entidad propietaria como parte de su clave primaria.

Normalización integrada. Dentro del diseño lógico se desarrolla el proceso de normalización, encargado de descomponer las relaciones para eliminar redundancias y las anomalías de actualización, inserción y borrado. Este análisis formal preserva la semántica de los datos y asegura que el esquema resultante cumpla con las propiedades de integridad antes de proceder a la implementación física.

Implementación física. El diseño físico materializa el esquema lógico en un SGBDR concreto, definiendo tipos de datos específicos, estructuras de almacenamiento, índices optimizados y mecanismos de particionamiento. En esta etapa se configuran aspectos como índices B-tree, hash o bitmap según los requerimientos de rendimiento y se establece la organización física de los datos en el sistema de almacenamiento.

Optimización selectiva. Durante el diseño físico puede aplicarse desnormalización controlada para mejorar el rendimiento de consultas específicas, introduciendo redundancia deliberada cuando los beneficios en velocidad superan el coste de mayor complejidad en mantenimiento. Esta decisión representa un equilibrio entre la pureza del modelo relacional y las necesidades operativas del sistema.

Modelado previo. El diseño requiere la creación de representaciones abstractas que faciliten la comprensión del sistema, permitan la validación con los usuarios y sirvan como referencia para las sucesivas fases de desarrollo. Estos modelos actúan como lenguaje común entre técnicos y expertos del dominio antes de la construcción efectiva de la base de datos.

🧩 Elementos esenciales

  • Tres fases del diseño: Secuencia metodológica compuesta por diseño conceptual, diseño lógico y diseño físico, cada uno con objetivos y niveles de abstracción diferenciados.
  • Diseño conceptual: Fase inicial que utiliza el modelo entidad-relación, mantiene independencia del SGBDR y requiere participación de usuarios del dominio para definir entidades y relaciones.
  • Diseño lógico: Etapa de traducción del esquema E-R al modelo relacional mediante reglas formales que determinan tablas, claves primarias y foráneas.
  • Reglas de transformación: Conversión de entidades a tablas, relaciones uno-a-muchos en claves foráneas, relaciones muchos-a-muchos en tablas puente, y entidades débiles con clave foránea del propietario incluida en su clave primaria.
  • Cardinalidades: Determinan la implementación física de las relaciones en el modelo relacional, distinguiendo entre uno-a-uno, uno-a-muchos y muchos-a-muchos.
  • Normalización: Proceso formal que forma parte del diseño lógico y elimina redundancias mediante la aplicación de formas normales, preservando la integridad semántica.
  • Diseño físico: Implementación concreta en un SGBDR específico que incluye definición de tipos de datos, índices estructurados y configuración del almacenamiento.
  • Desnormalización: Técnica aplicable exclusivamente en el diseño físico para optimizar el rendimiento mediante redundancia controlada, sacrificando normalización por velocidad de acceso.

🧠 Recuerda

  • El diseño sigue siempre el orden: conceptual, lógico y físico.
  • El conceptual usa E-R y no depende de ningún sistema gestor.
  • El lógico transforma E-R en tablas, claves primarias y foráneas según reglas fijas.
  • La normalización ocurre durante el diseño lógico, no en el físico.
  • Las cardinalidades 1:N, M:N y 1:1 determinan cómo se implementan las relaciones.
  • El físico define índices, tipos de datos concretos y estrategias de particionamiento.
  • La desnormalización es propia del diseño físico para ganar rendimiento.
  • Las entidades débiles incorporan la clave foránea del propietario en su clave primaria.

5. Normalización

🎯 Idea clave

  • La normalización se fundamenta en el análisis de las dependencias funcionales existentes entre los atributos de una relación.
  • Una dependencia funcional A → B indica que cada valor de A determina unívocamente un único valor de B.
  • El estándar SQL no define explícitamente las formas normales como restricciones sintácticas, sino que proporciona mecanismos para implementarlas.
  • Las restricciones PRIMARY KEY, UNIQUE, FOREIGN KEY y CHECK permiten garantizar las condiciones necesarias para mantener la normalización del esquema.
  • El análisis de dependencias funcionales permite identificar dependencias parciales, completas y transitivas para determinar la forma normal de una relación.

📚 Desarrollo

Concepto de dependencia funcional. Se dice que un atributo B depende funcionalmente de A, notado como A → B, si para cada valor de A existe exactamente un valor de B en la relación. Es decir, conocer el valor de A permite determinar unívocamente el valor de B, estableciendo la base teórica para la normalización.

Dependencia funcional completa. B depende funcionalmente de A de forma completa cuando depende de A pero no de ningún subconjunto propio de A. Eliminar cualquier atributo de A haría que dejara de existir la dependencia funcional, lo que resulta crucial para alcanzar la segunda forma normal.

Dependencia funcional parcial. Ocurre cuando B depende de un subconjunto propio de la clave candidata y no de la clave completa. Esta situación se presenta cuando la clave primaria es compuesta y algún atributo no clave depende únicamente de parte de dicha clave, generando redundancias.

Dependencia transitiva. B depende transitivamente de A a través de C cuando se cumple que A → C y C → B, pero C no es una superclave de la relación. Esto implica que B depende de A de forma indirecta, constituyendo un problema para la tercera forma normal.

Axiomas de Armstrong. Este conjunto de reglas de inferencia permite derivar todas las dependencias funcionales implicadas por un conjunto inicial. Los tres axiomas básicos son reflexividad, aumentatividad y transitividad, de los cuales se derivan también la unión, descomposición y pseudotransitividad.

Implementación en SQL. El estándar SQL no define explícitamente las formas normales como restricciones sintácticas, siendo responsabilidad del diseñador aplicar la normalización. Sin embargo, proporciona mecanismos como PRIMARY KEY para garantizar unicidad e irreducibilidad, UNIQUE para claves alternativas, FOREIGN KEY para integridad referencial y CHECK para restricciones de dominio.

Descomposición sin pérdida. La restricción FOREIGN KEY implementa la integridad referencial que hace posible la descomposición sin pérdida de datos entre tablas relacionadas. Las vistas pueden utilizarse para presentar datos de múltiples tablas normalizadas como si fueran una única tabla, ocultando la descomposición al usuario final.

Tipos de dependencias triviales. Las dependencias funcionales pueden ser simples o triviales cuando B depende de A y B es subconjunto de A. Por ejemplo, el caso {Nombre, Apellido} → {Nombre} representa una dependencia trivial que no aporta información semántica relevante para el proceso de normalización.

🧩 Elementos esenciales

  • Dependencia funcional (DF): Relación entre atributos donde A → B significa que cada valor de A determina un único valor de B.
  • DF completa: B depende de todo el conjunto de atributos A y no de ningún subconjunto propio de A.
  • DF parcial: B depende únicamente de una parte de la clave candidata, no de la clave completa.
  • DF transitiva: Dependencia indirecta A → C a través de B, donde B no es superclave.
  • Axiomas de Armstrong: Reglas de inferencia (reflexividad, aumentatividad, transitividad) para derivar dependencias funcionales.
  • PRIMARY KEY: Restricción SQL que garantiza unicidad e irreducibilidad de la clave primaria, necesaria para 2FN y 3FN.
  • FOREIGN KEY: Implementa integridad referencial permitiendo descomposición sin pérdida entre tablas.
  • UNIQUE: Declara claves alternativas cuando existen múltiples claves candidatas.
  • CHECK: Expresa restricciones de dominio que complementan las dependencias funcionales.
  • Vistas SQL: Permiten presentar datos de tablas normalizadas como una única tabla, ocultando la descomposición.

🧠 Recuerda

  • La normalización parte del análisis riguroso de las dependencias funcionales entre atributos.
  • Una DF completa requiere que el atributo dependa de toda la clave, no de una parte.
  • La dependencia parcial indica que un atributo depende solo de parte de la clave compuesta.
  • La dependencia transitiva implica un intermediario que no es superclave en la cadena de dependencias.
  • Los axiomas de Armstrong permiten inferir todas las dependencias funcionales implicadas.
  • SQL no define sintácticamente las formas normales, pero proporciona mecanismos para implementarlas.
  • PRIMARY KEY es fundamental para garantizar las condiciones de la segunda y tercera forma normal.
  • FOREIGN KEY permite mantener la integridad referencial en esquemas descompuestos.
  • Las dependencias triviales no son relevantes para el proceso de normalización práctico.

6. Manipulación: álgebra y cálculo relacional

🎯 Idea clave

  • El álgebra relacional constituye un lenguaje procedimental que especifica la secuencia de operaciones necesarias para obtener un resultado.
  • El cálculo relacional opera como lenguaje declarativo que indica qué datos se desean sin definir el procedimiento de obtención.
  • Ambos formalismos mantienen equivalencia expresiva y constituyen la base teórica del lenguaje SQL.
  • El modelo relacional garantiza el cierre relacional, permitiendo que operaciones sobre relaciones generen nuevas relaciones.
  • Las operaciones se clasifican en fundamentales (primitivas) y derivadas, siendo seis las operaciones básicas necesarias para expresar cualquier consulta.

📚 Desarrollo

Naturaleza procedimental. El álgebra relacional define operaciones que toman relaciones como entrada y producen relaciones como resultado, especificando explícitamente el procedimiento o secuencia de pasos necesarios para alcanzar el resultado deseado. Esta característica procedimental implica que el usuario debe indicar cómo obtener los datos mediante la composición de operadores aplicados sobre conjuntos de tuplas.

Cierre relacional. Una propiedad fundamental del modelo es el cierre relacional, que garantiza que el resultado de cualquier operación sobre relaciones es siempre otra relación. Esta propiedad permite componer consultas complejas de forma anidada, utilizando el resultado de una operación como entrada de la siguiente sin salir del modelo formal, facilitando la construcción modular de expresiones.

Operaciones fundamentales. Existen seis operaciones primitivas suficientes para expresar cualquier consulta relacional: la selección (σ), que filtra tuplas según condiciones booleanas; la proyección (π), que extrae subconjuntos de atributos; la unión (∪), que combina tuplas de relaciones compatibles; la diferencia (−), que obtiene tuplas presentes en una relación y ausentes en otra; el producto cartesiano (×), que combina sistemáticamente tuplas de dos relaciones; y el renombramiento (ρ), que modifica los nombres de atributos.

Operaciones derivadas. A partir de las fundamentales se definen operaciones derivadas de uso frecuente como la intersección (∩), que devuelve tuplas comunes a dos relaciones; el join natural (⋈), que combina filas de distintas tablas según igualdad entre atributos relacionados; el theta-join (⋈_θ), que establece condiciones arbitrarias de combinación; y la división (÷), especializada en consultas de tipo "para todos" que seleccionan tuplas relacionadas con el conjunto completo de otra relación.

Selección y filtrado. La operación de selección opera sobre las filas de la relación conservando el esquema original pero reduciendo el número de tuplas. La condición de selección puede combinar comparaciones simples entre atributos y valores mediante operadores lógicos como conjunción, disyunción y negación, estableciendo predicados que deben cumplir las tuplas resultantes.

Cálculo relacional. El cálculo relacional presenta un enfoque declarativo donde se especifica qué resultado se quiere mediante fórmulas lógicas sin indicar el procedimiento. Existen dos variantes: el cálculo de tuplas, que utiliza variables que representan tuplas completas junto con cuantificadores existenciales y universales; y el cálculo de dominios, que emplea variables sobre valores individuales de los dominios de atributos y constituye la base formal del lenguaje QBE.

Equivalencia con SQL. SQL constituye un lenguaje relacionalmente completo capaz de expresar cualquier consulta formulable en álgebra relacional, incorporando además extensiones como agregación, ordenación y valores nulos. Existen equivalencias directas entre constructos SQL y operaciones algebraicas: la cláusula WHERE corresponde a la selección, la especificación de columnas en SELECT equivale a la proyección, UNION se mapea directamente, EXCEPT corresponde a la diferencia, e INTERSECT a la intersección.

🧩 Elementos esenciales

  • Álgebra relacional: lenguaje procedimental que especifica cómo obtener los resultados mediante operaciones sobre relaciones.
  • Cálculo relacional: lenguaje declarativo que especifica qué datos se desean sin definir el procedimiento de obtención.
  • Cierre relacional: propiedad que garantiza que toda operación sobre relaciones devuelve una relación, permitiendo composición anidada.
  • Selección (σ): operación que filtra tuplas según condiciones booleanas sobre atributos, operando sobre filas.
  • Proyección (π): operación que reduce el número de atributos seleccionando columnas específicas de la relación.
  • Unión (∪): operación que combina tuplas de dos relaciones compatibles eliminando duplicados.
  • Diferencia (−): operación que obtiene tuplas presentes en una relación y ausentes en otra.
  • Producto cartesiano (×): operación que combina todas las tuplas de dos relaciones, base formal del join.
  • Join (⋈): operación derivada más utilizada que combina información de varias relaciones según condiciones de igualdad.
  • Cálculo de tuplas: variante declarativa que emplea variables de tupla y cuantificadores existenciales (∃) y universales (∀).
  • Cálculo de dominios: variante que utiliza variables sobre valores de dominio y sirve de base al lenguaje QBE.
  • Equivalencias SQL: WHERE equivale a σ, SELECT de columnas a π, UNION a ∪, EXCEPT a −, JOIN a ⋈ e INTERSECT a ∩.

🧠 Recuerda

  • Álgebra procedimental especifica el cómo; cálculo declarativo especifica el qué.
  • Las seis operaciones fundamentales (σ, π, ∪, −, ×, ρ) son suficientes para expresar cualquier consulta relacional.
  • SQL es relacionalmente completo y puede expresar toda consulta del álgebra relacional.
  • El join natural es la operación más frecuentemente utilizada en la práctica de bases de datos.
  • La división responde a consultas del tipo "para todos" o "que se relacionan con todos".
  • El cierre relacional permite tratar el resultado de una operación como entrada de otra.
  • El cálculo de tuplas utiliza cuantificadores existenciales y universales sobre variables de tupla.
  • La selección opera sobre filas; la proyección opera sobre columnas.

7. Modelo entidad– relación

🎯 Idea clave

  • El modelo entidad-relación es una técnica de modelado conceptual propuesta por Peter Chen en 1976 para representar semánticamente un dominio de información antes de su implementación relacional.
  • Permite identificar entidades (objetos relevantes), atributos (propiedades) y relaciones (asociaciones estructuradas) entre los elementos del sistema.
  • Se sitúa en la fase conceptual del diseño de bases de datos, sirviendo como puente hacia el modelo relacional sin confundirse con él.
  • Distingue entre entidades fuertes, con existencia e identificador propios, y entidades débiles, dependientes de una entidad propietaria.
  • La cardinalidad determina cuántas ocurrencias de una entidad se vinculan con otra, clasificándose en uno a uno, uno a muchos o muchos a muchos.
  • La notación de Chen es la estándar académica y la más requerida en oposiciones, aunque existen alternativas como crow's foot o UML.

📚 Desarrollo

Fase conceptual del diseño. El modelo entidad-relación constituye una técnica de modelado de datos que permite representar de manera comprensible y estructurada los elementos relevantes de un dominio y las asociaciones entre ellos. Su valor principal reside en comprender la realidad a almacenar antes de traducirla a tablas, claves y restricciones del sistema gestor. No sustituye al modelo relacional ni se confunde con la normalización, sino que ofrece una representación semántica clara que facilita el diseño lógico posterior.

Tipología de entidades. Una entidad representa cualquier objeto, persona, concepto, evento o hecho del mundo real sobre el que se desea almacenar información y que puede distinguirse de otros objetos. Se distinguen entidades fuertes, que poseen existencia independiente y un identificador propio suficiente, y entidades débiles, que dependen de la existencia de otra entidad denominada propietaria. La identificación de una entidad débil requiere combinar su discriminante con la clave de la entidad propietaria.

Atributos y sus categorías. Los atributos son propiedades que describen características de las entidades. En la transformación al modelo relacional, los atributos simples se convierten en columnas, los compuestos se descomponen en subatributos con significado operativo propio, y los multivaluados generan tablas separadas vinculadas mediante clave foránea. Los atributos derivados, calculables a partir de otros, normalmente no se almacenan salvo que existan razones específicas de rendimiento o trazabilidad.

Relaciones y cardinalidad. Una relación expresa una asociación significativa entre entidades, representando vínculos estructurados como la adscripción de un paciente a un centro o la inclusión de productos en un pedido. La cardinalidad indica cuántas ocurrencias de una entidad pueden asociarse con ocurrencias de otra, determinando restricciones estructurales que deben reflejar reglas reales del dominio. Las cardinalidades básicas son uno a uno, uno a muchos y muchos a muchos.

Representación gráfica. La notación de Chen, propuesta originalmente en 1976, utiliza rectángulos para entidades, rombos para relaciones y elipses para atributos, siendo la más habitual en manuales académicos y oposiciones. La notación crow's foot emplea símbolos gráficos sobre las líneas de conexión, donde una línea simple indica "uno" y tres líneas en abanico indican "muchos". La notación UML utiliza diagramas de clases donde las asociaciones representan relaciones con multiplicidades numéricas del estilo 0..1 o 1..*.

Transformación al modelo relacional. El pasaje del modelo E-R al relacional sigue reglas sistemáticas: cada entidad fuerte genera una tabla con su identificador como clave primaria; cada entidad débil genera una tabla cuya clave primaria es compuesta por el discriminante y la clave de la entidad propietaria. Las relaciones uno a muchos implementan la clave primaria del lado "uno" como clave foránea en el lado "muchos". Las relaciones muchos a muchos requieren una tabla de asociación con las claves foráneas de ambas entidades formando la clave primaria compuesta.

🧩 Elementos esenciales

  • Entidad fuerte: Objeto con existencia independiente que posee un identificador propio distintivo y se representa mediante rectángulo simple en los diagramas.
  • Entidad débil: Objeto cuya existencia depende de otra entidad propietaria y que carece de identificador suficiente por sí sola, representada con doble rectángulo.
  • Atributo multivaluado: Propiedad que puede tener múltiples valores para una misma instancia de entidad y que genera una tabla separada en el diseño lógico.
  • Atributo derivado: Característica calculable a partir de otros atributos que normalmente no se almacena en la base de datos salvo requisitos de rendimiento específicos.
  • Cardinalidad 1:N: Vinculación donde una ocurrencia de la primera entidad se asocia con varias de la segunda, implementándose mediante clave foránea en el lado "muchos".
  • Cardinalidad M:N: Asociación donde múltiples ocurrencias de ambas entidades se relacionan mutuamente, requiriendo tabla intermedia con claves foráneas de ambas entidades.
  • Notación de Chen: Sistema gráfico canónico que emplea rectángulos, rombos y elipses para representar entidades, relaciones y atributos respectivamente.
  • Tabla de asociación: Estructura resultante de transformar relaciones muchos a muchos, conteniendo las claves primarias de las entidades participantes como clave foránea.

🧠 Recuerda

  • El modelo E-R fue propuesto por Peter Chen en 1976 como técnica estándar de modelado conceptual de datos.
  • Una entidad débil siempre requiere de una entidad fuerte propietaria para su identificación completa.
  • Las relaciones muchos a muchos siempre generan una tabla intermedia durante la transformación al modelo relacional.
  • La notación de Chen es la más relevante y habitual en las oposiciones del Servicio Andaluz de Salud.
  • La cardinalidad debe reflejar restricciones reales del dominio y no intuiciones personales del diseñador.
  • Los atributos multivaluados se transforman en tablas separadas con clave foránea hacia la entidad origen.
  • Las relaciones uno a muchos se resuelven añadiendo la clave del lado "uno" como foránea en la tabla del lado "muchos".
  • Los atributos derivados se calculan sobre la marcha y no suelen almacenarse en el esquema físico.

8. El lenguaje SQL

🎯 Idea clave

  • SQL es el lenguaje estándar más extendido para trabajar con bases de datos relacionales.
  • SQL no solo consulta datos, sino que también define estructuras, modifica información y participa en el control de privilegios y transacciones.
  • El carácter declarativo de SQL se aprecia especialmente en las consultas que utilizan la sentencia SELECT.
  • El lenguaje se organiza en sublenguajes específicos: DDL, DML, DQL, DCL y TCL.
  • El estándar internacional vigente es ISO/IEC 9075:2023, que proporciona una base formal para la interoperabilidad.
  • SQL soporta el modelo relacional pero cada sistema gestor introduce dialectos y extensiones propietarias que limitan la portabilidad absoluta.

📚 Desarrollo

Definición y alcance. SQL es el lenguaje estándar más extendido para trabajar con bases de datos relacionales. Su función trasciende la mera consulta de datos, ya que permite definir estructuras, modificar información, gestionar privilegios de acceso y controlar transacciones, convirtiéndose en un lenguaje completo de gestión de datos.

Naturaleza declarativa. El carácter declarativo de SQL se manifiesta claramente en las consultas mediante SELECT, donde el usuario especifica qué datos desea obtener sin detallar el procedimiento o secuencia de operaciones necesaria para recuperarlos. Esta aproximación contrasta fundamentalmente con los lenguajes procedimentales de manipulación de datos.

Sublenguajes componentes. SQL se estructura en cinco categorías funcionales diferenciadas: el DDL se utiliza para definir y modificar objetos del esquema; el DML permite insertar, actualizar y borrar filas; el DQL se centra específicamente en la recuperación de información; el DCL expresa operaciones de concesión o retirada de privilegios; y el TCL permite confirmar o revertir cambios dentro de una transacción.

Fundamento teórico. SQL constituye la materialización tecnológica práctica de los formalismos teóricos del álgebra y el cálculo relacional. Aunque se apoya conceptualmente en el modelo relacional, no se identifica por completo con su formulación teórica pura, adaptándose a las necesidades operativas de los sistemas reales.

Estándar internacional. La norma principal que define SQL es ISO/IEC 9075, conocida como SQL:2023 en su edición vigente. Esta especificación establece la gramática, el modelo de datos, el conjunto de tipos de datos, operadores, restricciones de integridad y comportamientos que todos los sistemas gestores conformes deben implementar.

Niveles de conformidad. El estándar define un núcleo mínimo obligatorio denominado Core SQL, que representa el subconjunto mínimo que un sistema debe implementar para ser considerado conforme. Además, contempla funcionalidades opcionales adicionales que los fabricantes pueden incorporar para extender las capacidades del lenguaje.

Estructura por partes. La norma se organiza en múltiples partes especializadas: Framework establece el marco conceptual; Foundation contiene el núcleo esencial; Call-Level Interface sirve de base conceptual para ODBC; Persistent Stored Modules regulan procedimientos almacenados y triggers; Management of External Data facilita el acceso a fuentes externas; Information and Definition Schemas estandarizan los metadatos mediante INFORMATION_SCHEMA; y la Parte 16 incorpora Property Graph Queries para consultas sobre grafos.

Limitaciones prácticas. A pesar de estandarizar una base común para tablas, vistas, restricciones, joins, agregaciones y transacciones, cada sistema gestor implementa extensiones propietarias no portables. La gestión de valores NULL, los tipos de datos específicos y ciertas operaciones presentan comportamientos ligeramente diferentes entre implementaciones, por lo que la conformidad con el estándar no elimina completamente los problemas de portabilidad.

🧩 Elementos esenciales

  • DDL (Data Definition Language): Define y modifica objetos del esquema como tablas, índices, dominios y restricciones estructurales.
  • DML (Data Manipulation Language): Permite insertar, actualizar y eliminar filas en las relaciones existentes.
  • DQL (Data Query Language): Se centra exclusivamente en la recuperación de información mediante operaciones de selección y proyección.
  • DCL (Data Control Language): Gestiona la concesión y revocación de privilegios de acceso sobre los objetos de la base de datos.
  • TCL (Transaction Control Language): Controla la confirmación o reversión de cambios dentro de una transacción mediante sentencias como COMMIT y ROLLBACK.
  • ISO/IEC 9075: Denominación formal del estándar SQL, mantenido conjuntamente por la Organización Internacional de Normalización y el Comité Electrotécnico Internacional.
  • SQL:2023: Edición vigente del estándar, publicada como ISO/IEC 9075:2023, que incorpora el tipo de dato JSON nativo y nuevas funciones escalares.
  • Core SQL: Subconjunto mínimo obligatorio que un sistema gestor debe implementar para declararse conforme con el estándar internacional.
  • Parte 2 (Foundation): Especifica el núcleo del lenguaje incluyendo tipos de datos, SELECT, INSERT, UPDATE, DELETE, restricciones, vistas y transacciones.
  • Parte 11 (Information Schema): Define INFORMATION_SCHEMA como catálogo estándar de metadatos accesible mediante consultas SQL.
  • SQL/XML: Especificación de la Parte 14 para la integración y manipulación de datos XML dentro del entorno relacional.
  • Property Graph Queries: Funcionalidad introducida en SQL:2023 mediante la Parte 16 para realizar consultas sobre grafos de propiedades.

🧠 Recuerda

  • SQL es declarativo: se especifica el resultado deseado, no el procedimiento algorítmico para obtenerlo.
  • El estándar actual es ISO/IEC 9075:2023, conocido formalmente como Database Language SQL.
  • Core SQL representa el mínimo obligatorio; las demás funcionalidades son extensiones opcionales.
  • Cada fabricante añade dialectos propios que limitan la portabilidad total entre sistemas distintos.
  • SQL:2023 incluye JSON nativo y funciones escalares como GREATEST, LEAST, LPAD, RPAD y ANY_VALUE.
  • La Parte 2 (Foundation) contiene el núcleo esencial del lenguaje que todo gestor debe implementar.
  • INFORMATION_SCHEMA proporciona metadatos de forma estandarizada según la Parte 11 de la norma.
  • SQL soporta el modelo relacional pero no se identifica completamente con su formulación teórica pura.
  • La interoperabilidad real mejora cuando se usa el subconjunto más portable del lenguaje estándar.
  • El estándar crea un terreno común suficiente para que la portabilidad parcial sea posible entre gestores.

9. Normas y estándares para la interoperabilidad entre gestores de bases de datos relacionales

🎯 Idea clave

  • El estándar SQL ISO/IEC 9075 constituye el mecanismo fundamental que define la gramática, el modelo de datos y los comportamientos mínimos para la interoperabilidad entre sistemas gestores de bases de datos relacionales.
  • ODBC proporciona una API multi-lenguaje que permite a aplicaciones escritas en distintos lenguajes acceder uniformemente a cualquier SGBDR mediante drivers específicos.
  • JDBC representa el equivalente de ODBC exclusivamente para el ecosistema Java, facilitando la portabilidad de aplicaciones entre diferentes gestores de bases de datos.
  • El driver JDBC de Tipo 4 o Pure Java Driver es el más utilizado actualmente porque implementa directamente el protocolo nativo del SGBD sin requerir software adicional en el cliente.
  • Los procesos ETL, las tecnologías ORM y los sistemas de replicación heterogénea complementan los estándares básicos de interoperabilidad entre gestores dispares.

📚 Desarrollo

Estándar SQL fundamental. El estándar definido por ISO/IEC 9075 establece la gramática, el modelo de datos, los tipos de datos, operadores y restricciones de integridad que deben implementar los SGBD conformes. Especifica niveles de conformidad donde el núcleo (Core SQL) representa el subconjunto mínimo obligatorio para considerar un gestor como conforme con la norma.

Limitaciones del estándar. A pesar de su importancia, SQL no elimina completamente los problemas de portabilidad debido a las extensiones propietarias que cada fabricante incorpora, comportamientos diferenciados en ciertas características aunque la sintaxis sea estándar, y variaciones en la gestión de valores NULL y tipos de datos entre implementaciones.

Arquitectura ODBC. Open Database Connectivity constituye una API desarrollada originalmente por Microsoft que permite a aplicaciones escritas en lenguajes como C, C++ o Python acceder a cualquier SGBDR mediante drivers específicos. Su estructura comprende cuatro capas diferenciadas: la aplicación que invoca funciones, el gestor de drivers que dirige las llamadas, el driver propiamente dicho que traduce a llamadas nativas, y finalmente el sistema gestor de base de datos.

Configuración mediante DSN. Las conexiones ODBC se establecen utilizando un Data Source Name que agrupa los parámetros de conexión necesarios como el gestor, servidor, base de datos y credenciales. Este mecanismo permite a las aplicaciones conectarse por nombre sin especificar detalles técnicos directamente en el código fuente.

Interfaz JDBC. Java Database Connectivity representa el equivalente de ODBC para el lenguaje Java, formando parte de la plataforma Java SE dentro del paquete java.sql. Proporciona acceso universal a datos mediante un marco donde pueden instalarse dinámicamente diferentes drivers según el gestor objetivo, trabajando contra abstracciones estables como conexión, sentencia y transacción.

Clasificación de drivers. JDBC define cuatro tipos de drivers: el Tipo 1 o JDBC-ODBC Bridge resulta obsoleto y eliminado en Java 8; el Tipo 2 utiliza APIs nativas del SGBD en C/C++; el Tipo 3 emplea middleware de red independiente; y el Tipo 4 o Pure Java Driver, que implementa directamente el protocolo nativo del gestor, constituye la opción predominante por su portabilidad, eficiencia y ausencia de dependencias nativas.

Herramientas complementarias. El ecosistema de interoperabilidad se completa con tecnologías como los ORM para mapeo objeto-relacional, procesos ETL para extracción, transformación y carga de datos, y sistemas de replicación heterogénea que facilitan la sincronización entre gestores dispares como Oracle GoldenGate.

🧩 Elementos esenciales

  • SQL ISO/IEC 9075: Norma internacional que define la sintaxis y semántica del lenguaje SQL para garantizar la portabilidad básica entre gestores.
  • Core SQL: Nivel mínimo de conformidad que un SGBD debe implementar para considerarse conforme con el estándar SQL internacional.
  • ODBC: API multi-lenguaje que proporciona acceso uniforme a bases de datos mediante drivers específicos por cada sistema gestor.
  • Driver Manager: Componente del sistema operativo que gestiona la carga de drivers ODBC y dirige las llamadas al driver correspondiente.
  • DSN: Nombre de origen de datos que agrupa parámetros de conexión para facilitar la configuración de accesos ODBC sin codificar detalles técnicos.
  • JDBC: API específica del ecosistema Java para acceso a bases de datos, ubicada en el paquete java.sql y equivalente funcional a ODBC.
  • Driver JDBC Tipo 4: Implementación completamente en Java que se conecta directamente al protocolo nativo del SGBD, siendo la opción más utilizada actualmente.
  • Driver JDBC Tipo 1: Puente JDBC-ODBC considerado obsoleto y eliminado en versiones modernas de Java a partir de Java 8.
  • Connection: Interfaz JDBC que representa la conexión establecida con el SGBD y permite gestionar transacciones mediante commit y rollback.
  • PreparedStatement: Sentencia SQL precompilada con parámetros que ofrece mayor eficiencia y seguridad frente a inyección SQL que Statement simple.
  • ORM: Tecnologías de mapeo objeto-relacional que facilitan la interoperabilidad entre el paradigma de programación orientada a objetos y las bases relacionales.
  • Replicación heterogénea: Mecanismos que permiten sincronizar datos entre diferentes sistemas gestores de bases de datos manteniendo la consistencia.

🧠 Recuerda

  • SQL ISO/IEC 9075 es el estándar base, pero las extensiones propietarias de cada fabricante limitan la portabilidad total entre gestores.
  • ODBC permite acceso multi-lenguaje mientras que JDBC está específicamente orientado al entorno Java y forma parte de Java SE.
  • El driver JDBC Tipo 4 es el más eficiente porque no requiere software nativo adicional en el cliente y es completamente portable.
  • El JDBC-ODBC Bridge (Tipo 1) está obsoleto y fue eliminado en Java 8 y versiones posteriores.
  • Las conexiones ODBC se configuran mediante DSN para abstraer los detalles técnicos de la aplicación cliente.
  • DriverManager.getConnection es el método estándar para establecer conexiones JDBC con el SGBD.
  • Los ORM y procesos ETL complementan los estándares de interoperabilidad básicos proporcionando capas de abstracción adicionales.
  • La gestión de transacciones en JDBC se controla mediante los métodos setAutoCommit, commit y rollback de la interfaz Connection.

10. Principales SGBD comerciales

🎯 Idea clave

  • Los SGBD comerciales son productos empresariales con soporte profesional, licencia y garantías contractuales que ofrecen funcionalidades avanzadas para entornos de alta exigencia.
  • Oracle Database es el SGBD líder mundial y el principal en el SAS, donde gestiona el sistema DIRAYA con la historia clínica de aproximadamente 8,5 millones de ciudadanos andaluces.
  • Microsoft SQL Server destaca por su integración con el ecosistema Microsoft y Azure, mientras que IBM Db2 mantiene su fortaleza en entornos mainframe y sistemas distribuidos.
  • SAP HANA representa la tendencia in-memory para la integración de procesamiento transaccional y analítico en tiempo real dentro del entorno SAP.
  • Todos estos productos combinan alta disponibilidad, seguridad avanzada y herramientas de administración corporativa, aunque conllevan mayor coste y dependencia del proveedor.
  • La elección entre distintos gestores depende de requisitos funcionales, arquitectura existente, presupuesto y ciclo de vida previsto, más que de rankings absolutos de calidad.

📚 Desarrollo

Definición de SGBD comercial. Un sistema gestor de bases de datos comercial es un producto distribuido bajo licencia empresarial que incluye soporte profesional, contratos de mantenimiento, versiones certificadas y herramientas avanzadas de administración, seguridad y alta disponibilidad. Esta categoría abarca tanto productos estrictamente propietarios como ediciones empresariales de tecnologías de código abierto, diferenciándose por la existencia de una oferta empresarial sostenida con responsabilidades contractuales claras y ciclo de vida definido.

Oracle Database como referencia. Oracle Database, desarrollado por Oracle Corporation, se posiciona como el SGBDR líder mundial para cargas corporativas críticas y entornos multimodelo. Su arquitectura distingue entre la instancia, compuesta por la memoria SGA y procesos en segundo plano, y la base de datos propiamente dicha formada por ficheros físicos. Emplea PL/SQL como lenguaje procedimental y ofrece mecanismos de alta disponibilidad mediante Real Application Clusters, que permiten el acceso concurrente de múltiples nodos a una misma base de datos compartida, complementado con Data Guard para la recuperación ante desastres mediante bases standby.

Posición dominante en el SAS. En el ámbito del Servicio Andaluz de Salud, Oracle Database constituye el sistema gestor principal, albergando el sistema DIRAYA que gestiona la historia clínica digital de aproximadamente 8,5 millones de ciudadanos andaluces. Esta implantación masiva determina que el conocimiento de su arquitectura, herramientas como SQL Developer, Enterprise Manager y RMAN, así como la gestión de la memoria SGA y PGA, resulte especialmente relevante para la categoría profesional.

Microsoft SQL Server y su ecosistema. Microsoft SQL Server destaca por su profunda integración con el ecosistema Microsoft, incluyendo Windows, .NET y Azure. Su núcleo, el Database Engine, utiliza T-SQL como lenguaje procedimental. Ofrece capacidades de alta disponibilidad mediante Always On Availability Groups y Failover Cluster Instance, además de componentes específicos para business intelligence como SSIS, SSAS y SSRS. En el contexto sanitario andaluz presenta un uso puntual en sistemas departamentales, aprovechando su arquitectura híbrida local-nube.

IBM Db2 y SAP HANA. IBM Db2 mantiene su posición de referencia para entornos de misión crítica, particularmente en mainframes bajo z/OS, destacando por su resiliencia y capacidad para gestionar workloads mixtos transaccionales y analíticos mediante SQL PL y tecnologías pureScale y HADR. Por su parte, SAP HANA representa una plataforma relacional in-memory orientada a la integración de procesamiento transaccional y analítico en tiempo real, vinculada estrechamente al ecosistema SAP S/4HANA y aplicable en la gestión ERP.

Consideraciones generales. Los principales SGBD comerciales, completados por Teradata Vantage para data warehousing masivo y MySQL Enterprise Edition para aplicaciones web empresariales, comparten características de seguridad avanzada, continuidad de negocio y administración profesional. Sin embargo, esta potencia conlleva inherentemente mayor complejidad, coste elevado y dependencia tecnológica del proveedor, aspectos que deben ponderarse frente a las alternativas de código abierto según los requisitos específicos del proyecto.

🧩 Elementos esenciales

  • SGBD comercial: Producto empresarial con licencia, soporte profesional, ciclo de vida certificado y responsabilidades contractuales, distinto del software de código abierto sin soporte vendor.
  • Oracle Database: SGBD líder mundial desarrollado por Oracle Corporation, orientado a cargas críticas con arquitectura dual instancia-base de datos y lenguaje PL/SQL.
  • Real Application Clusters (RAC): Tecnología de Oracle que permite que múltiples instancias en nodos diferentes accedan concurrentemente a una misma base de datos física compartida.
  • Data Guard: Solución de Oracle para recuperación ante desastres mediante bases de datos standby que mantienen copia sincronizada de la principal.
  • System Global Area (SGA): Memoria compartida de Oracle que incluye Buffer Cache, Shared Pool y Redo Log Buffer, gestionada por la instancia junto con la PGA.
  • SQL Server: SGBD de Microsoft centrado en el Database Engine con T-SQL, integrado con Azure y herramientas de BI como SSIS, SSAS y SSRS.
  • Always On Availability Groups: Mecanismo de alta disponibilidad de SQL Server que permite failover automático y réplicas secundarias legibles.
  • IBM Db2: SGBD de IBM especializado en mainframes z/OS y sistemas distribuidos, utilizando SQL PL y tecnologías pureScale y HADR para alta disponibilidad.
  • SAP HANA: Plataforma in-memory columnar para procesamiento híbrido transaccional-analítico integrada con el ecosistema SAP S/4HANA.
  • DIRAYA: Sistema de historia clínica digital del SAS que utiliza Oracle Database como gestor principal, gestionando datos de aproximadamente 8,5 millones de ciudadanos.

🧠 Recuerda

  • Oracle, SQL Server y Db2 conforman el trío histórico de SGBD comerciales de referencia, ampliado recientemente con SAP HANA.
  • En el SAS, Oracle es el gestor principal mediante DIRAYA, mientras que SQL Server tiene uso departamental y Db2 es marginal.
  • RAC permite escalabilidad horizontal activa; Data Guard proporciona protección ante desastres mediante standby físicas o lógicas.
  • La SGA es el núcleo de memoria compartida en Oracle, compuesta por Buffer Cache, Shared Pool y Redo Log Buffer.
  • SQL Server se identifica por T-SQL y su ecosistema Microsoft/Azure, mientras Db2 destaca en mainframes z/OS.
  • SAP HANA opera en memoria para unificar OLTP y OLAP en tiempo real mediante arquitectura columnar.
  • Los SGBD comerciales ofrecen soporte contractual y herramientas profesionales, pero con mayor coste y vendor lock-in.
  • La elección debe basarse en requisitos técnicos y arquitectónicos concretos, no en rankings genéricos de productos.
  • Distingue siempre el motor técnico, el modelo de licencia y el ecosistema de soporte al estudiar estos productos.

11. SGBD de código abierto

🎯 Idea clave

  • Los SGBD de código abierto permiten uso, modificación y distribución bajo licencias libres sin costes de licenciamiento propietario.
  • Los principales referentes son PostgreSQL, MySQL Community, MariaDB y SQLite, cada uno con arquitecturas y casos de uso diferenciados.
  • PostgreSQL destaca por su extensibilidad, conformidad estricta con estándares SQL y naturaleza objeto-relacional.
  • MariaDB ofrece compatibilidad con MySQL junto con características avanzadas como Galera Cluster para alta disponibilidad multi-maestro.
  • SQLite funciona como biblioteca embebida sin servidor separado, almacenando la base de datos en un único fichero de dominio público.
  • La ausencia de costes de licencia no elimina la necesidad de gobierno de datos, soporte técnico y administración especializada.

📚 Desarrollo

Definición y ventajas administrativas. Los Sistemas Gestores de Bases de Datos Relacionales de código abierto disponen de código fuente público distribuido bajo licencias libres que permiten su uso, modificación y distribución sin pagar licencias propietarias. Esta condición resulta especialmente atractiva para administraciones públicas y organismos sanitarios, ya que facilita la auditoría tecnológica, reduce la dependencia de proveedores y optimiza la eficiencia en el uso de recursos públicos, manteniendo funcionalidades comparables a los sistemas comerciales de gama media.

PostgreSQL y su arquitectura objeto-relacional. PostgreSQL se define oficialmente como un sistema objeto-relacional de código abierto que ofrece soporte amplio del estándar SQL, integridad transaccional completa, claves foráneas, disparadores y vistas actualizables. Destaca por su muy alta conformidad con estándares, control de concurrencia multiversión nativo y extensibilidad mediante tecnologías como PostGIS o Foreign Data Wrappers. Para alta disponibilidad emplea soluciones como Patroni combinado con replicación streaming, dirigiéndose principalmente a entornos empresariales y administraciones públicas con datos complejos.

MySQL y su modelo de licenciamiento dual. MySQL mantiene un modelo de doble licencia que permite su uso como producto de código abierto bajo GNU GPL o bajo licencia comercial de Oracle. Funciona con arquitectura cliente-servidor y ofrece transacciones ACID cuando utiliza el motor InnoDB, junto con MVCC y conformidad SQL alta aunque moderada en comparación con PostgreSQL. Su ecosistema se orienta especialmente a aplicaciones web y entornos LAMP, contando con replicación asíncrona y Group Replication para configuraciones distribuidas.

MariaDB como alternativa libre. MariaDB Server constituye una derivación de MySQL publicada bajo licencia GPLv2, surgida para mantener una alternativa completamente libre y abierta. Ofrece compatibilidad con MySQL añadiendo características adicionales como el motor ColumnStore o Spider, y destaca especialmente en alta disponibilidad mediante Galera Cluster, que proporciona replicación síncrona multi-maestro. Se presenta como sustituto libre de MySQL con fuerte orientación al rendimiento, escalabilidad y despliegue profesional en servidores.

SQLite y su naturaleza embebida. SQLite no constituye un servidor de bases de datos en red sino una biblioteca en proceso que implementa un motor SQL transaccional autocontenido y sin configuración. Su código reside en dominio público y almacena la base de datos en un único fichero, empleando control de concurrencia por bloqueo de archivo en lugar de MVCC. Resulta insuficiente para cargas multiusuario de servidor pero extremadamente útil en aplicaciones embebidas, dispositivos móviles, cachés locales y entornos de prueba que requieren ligereza y portabilidad.

Gobernanza y decisión técnica. La disponibilidad de código abierto no elimina la necesidad de establecer gobierno y administración rigurosa de los datos. La elección entre estos gestores debe fundamentarse en requisitos específicos de licenciamiento, necesidades de soporte técnico, rendimiento esperado, grado de conformidad SQL, mecanismos de replicación y alta disponibilidad, así como en el campo de uso previsto, ya que cada sistema presenta arquitecturas distintas y comunidades de desarrollo con diferentes dinámicas.

🧩 Elementos esenciales

  • Licencias de código abierto: PostgreSQL utiliza licencia BSD permisiva, MariaDB GPL v2, SQLite dominio público y MySQL mantiene modelo dual GPL/comercial.
  • Arquitectura cliente-servidor: PostgreSQL, MySQL y MariaDB funcionan con modelo cliente-servidor, mientras que SQLite opera como biblioteca embebida sin servidor separado.
  • Conformidad SQL: PostgreSQL alcanza muy alta conformidad con estándares; MySQL y MariaDB presentan conformidad media-alta; SQLite ofrece conformidad parcial suficiente para uso embebido.
  • Control de concurrencia: Los tres motores servidor implementan MVCC nativo, mientras que SQLite utiliza control por bloqueo de fichero dada su naturaleza monofichero.
  • Replicación y alta disponibilidad: PostgreSQL emplea replicación streaming y Patroni; MySQL utiliza Group Replication e InnoDB Cluster; MariaDB implementa Galera Cluster síncrono multi-maestro.
  • PostgreSQL: Sistema objeto-relacional extensible mediante PostGIS y Foreign Data Wrappers, dirigido a producción empresarial y administraciones con datos complejos.
  • MariaDB: Derivación de MySQL bajo GPL v2 que añade motores ColumnStore y Spider, con fuerte orientación a rendimiento y escalabilidad profesional.
  • SQLite: Motor autocontenido de dominio público que almacena datos en único fichero, ideal para aplicaciones móviles, embebidas y pruebas locales.
  • Gestión y soporte: Los SGBD abiertos requieren gobierno de datos, administración especializada y decisión técnica rigurosa independientemente de la ausencia de costes de licencia.

🧠 Recuerda

  • PostgreSQL representa el estándar de facto en extensibilidad y cumplimiento estricto de normas SQL.
  • MariaDB nació como fork de MySQL para garantizar continuidad bajo licencia puramente GPLv2.
  • MySQL permite uso comercial bajo licencia propietaria o abierto bajo GPL según necesidades del proyecto.
  • SQLite no sustituye a servidores multiusuario pero es insustituible para sistemas embebidos y móviles.
  • La apertura del código fuente exige igualmente planificar soporte técnico y gobernanza de datos adecuados.
  • Cada gestor presenta arquitecturas, modelos de concurrencia y campos de uso claramente diferenciados.
  • Las administraciones públicas valoran estos sistemas por reducir vendor lock-in y facilitar auditorías de seguridad.

Prueba la demo si quieres ver el resto

Has visto un tema abierto completo. En la demo puedes comprobar cómo encajan el temario, las preguntas justificadas y los simulacros dentro de OposAs.

Qué vas a probar

Una demo pensada para decidir con criterio

Temario, test y simulacro conectados

La idea no es solo leer un tema: es estudiar con continuidad y comprobar cómo se relaciona con el resto de herramientas.

Preguntas justificadas

Verás explicaciones de la correcta y de las incorrectas para estudiar con más criterio, no solo para memorizar.

Acceso rápido

Con tu nombre y tu email, eliges categoría y te enviamos el acceso por correo sin compromiso.

Gratis Sin compromiso Acceso por email

Solicita ya tu acceso Demo

Sólo tu email, tu nombre y apellidos (si quieres), elige categoría y prueba antes de decidir. Es gratis.

Acceso solicitado

Revisa tu correo y también spam.

En tienes el enlace para terminar el autoregistro.

Ábrelo antes de 1 hora.

OposAs