Módulo 02: Historia y tipos de bases de datos

Objetivos del módulo

Conocer la evolución histórica de los sistemas de almacenamiento de datos, desde las tarjetas perforadas hasta las bases de datos vectoriales
Comprender los modelos jerárquico y en red, sus estructuras y sus limitaciones, con ejemplos
Valorar la importancia del artículo de E. F. Codd (1970) y el nacimiento del modelo relacional y de SQL
Conocer el origen de los grandes SGBD relacionales: System R, Ingres, Oracle, DB2, Informix, Sybase y SQL Server
Situar los estándares de SQL en el tiempo
Entender qué aportaron las bases de datos orientadas a objetos y objeto-relacionales
Distinguir entre OLTP y OLAP, y conocer los almacenes de datos y los enfoques de Inmon y Kimball
Conocer las bases de datos libres que impulsaron la web: MySQL, PostgreSQL, SQLite y MariaDB
Comprender el teorema CAP, la diferencia entre ACID y BASE, y los cuatro grandes tipos de bases de datos NoSQL
Conocer las tendencias actuales: NewSQL, bases de datos distribuidas, en la nube (DBaaS), de series temporales, en memoria, data lakes y lakehouse, bases de datos vectoriales y multimodelo
Clasificar las bases de datos según distintos criterios

1. ¿Por qué estudiar la historia de las bases de datos?

Podría parecer que la historia es un adorno, pero en bases de datos es casi imprescindible: cada modelo nació para resolver los problemas del anterior. Si entiendes por qué se abandonó el modelo jerárquico, entenderás por qué el modelo relacional insiste tanto en la independencia de datos. Si entiendes por qué surgió NoSQL, sabrás cuándo conviene (y cuándo no) usar una base de datos que no sea relacional.

Además, la historia no ha terminado de “pasar”: todavía hay bancos que ejecutan cada día millones de transacciones sobre IMS, una base de datos jerárquica diseñada en los años sesenta, y conceptos que parecían olvidados (como navegar por punteros entre registros) han vuelto con las bases de datos de grafos.

📘 Concepto: La evolución de las bases de datos se puede resumir en una búsqueda constante de tres objetivos: independencia (que los programas no dependan de cómo se guardan los datos), escalabilidad (manejar cada vez más datos y usuarios) y flexibilidad (representar datos cada vez más variados).

2. Visión de conjunto: cronología

2.1. Tabla cronológica

Año	Hito	Protagonistas
1890	Las máquinas tabuladoras de tarjetas perforadas procesan el censo de EE. UU.	Herman Hollerith
1951	El UNIVAC I usa cinta magnética como almacenamiento de datos	Remington Rand
1956	Primer disco duro comercial (IBM 350, del sistema RAMAC): unos 5 MB	IBM
1959	Se crea CODASYL; nace el lenguaje COBOL (1959-1960)	Comité CODASYL
1963-1964	IDS (Integrated Data Store), primer SGBD, base del modelo en red	Charles Bachman (General Electric)
1966-1968	Desarrollo de ICS/DL/I para el programa Apolo; primer mensaje “READY” en 1968	IBM, North American Rockwell, Caterpillar
1969	ICS pasa a llamarse IMS/360: modelo jerárquico comercial. Primer informe CODASYL DBTG	IBM; CODASYL
1970	Artículo “A Relational Model of Data for Large Shared Data Banks”	Edgar F. Codd (IBM)
1971	Informe CODASYL DBTG que define el modelo en red	CODASYL
1973	Bachman recibe el premio Turing (“El programador como navegante”); comienza Ingres	Bachman; Stonebraker y Wong (Berkeley)
1973-1974	IDMS, SGBD en red derivado de IDS, comercializado por Cullinane	B. F. Goodrich, Cullinane
1974	Comienza System R; Chamberlin y Boyce presentan SEQUEL	IBM San José
1975	Informe provisional ANSI/SPARC: arquitectura de tres niveles	ANSI/X3/SPARC
1976	Modelo Entidad/Relación	Peter Chen
1977	Se funda Software Development Laboratories (futura Oracle)	Larry Ellison, Bob Miner, Ed Oates
1979	La empresa pasa a llamarse Relational Software, Inc. y lanza Oracle V2, primer SGBD relacional SQL comercial	RSI
1980	Se funda Relational Database Systems (futura Informix)	Roger Sippl
1981	Codd recibe el premio Turing; IBM lanza SQL/DS	Codd; IBM
1983	IBM lanza DB2; RSI pasa a llamarse Oracle Systems Corporation; Oracle V3, reescrito en C	IBM; Oracle
1984	Se funda Sybase	Mark Hoffman, Robert Epstein
1985	Codd publica sus reglas para sistemas relacionales	Codd
1986	Primer estándar de SQL (ANSI); ISO lo adopta en 1987. Comienza el proyecto POSTGRES	ANSI, ISO; Stonebraker
1989	Microsoft SQL Server 1.0 (con Sybase y Ashton-Tate, para OS/2)	Microsoft
1991-1993	Se crea el ODMG y publica su estándar de bases de datos de objetos	ODMG
1992	SQL-92. Inmon publica Building the Data Warehouse	ANSI/ISO; Bill Inmon
1993	Codd acuña el término OLAP	Codd
1995	Primera versión de MySQL	Michael Widenius, David Axmark, Allan Larsson
1996	POSTGRES pasa a llamarse PostgreSQL. Kimball publica The Data Warehouse Toolkit	Comunidad PostgreSQL; Ralph Kimball
1997	Oracle8 incorpora características objeto-relacionales	Oracle
1999	SQL:1999 (tipos definidos por el usuario, consultas recursivas)	ISO
2000	SQLite. Brewer enuncia la conjetura CAP	D. Richard Hipp; Eric Brewer
2002	Gilbert y Lynch demuestran formalmente el teorema CAP	MIT
2003-2004	Google publica GFS y MapReduce	Google
2006	Google publica Bigtable; nace Hadoop	Google; Doug Cutting
2007	Amazon publica Dynamo	Amazon
2008	Facebook libera Cassandra; Sun compra MySQL AB	Facebook; Sun
2009	MongoDB, Redis, MariaDB. Se populariza el término NoSQL. Amazon RDS	10gen; Salvatore Sanfilippo; Widenius; Amazon
2010	Oracle completa la compra de Sun (y con ella MySQL). Se acuña el término data lake	Oracle; James Dixon
2011	Se acuña el término NewSQL	Matthew Aslett (451 Group)
2012	Google publica Spanner	Google
2013	Oracle 12c con arquitectura multitenant. InfluxDB	Oracle; InfluxData
2014	Amazon Aurora	Amazon
2017	CockroachDB 1.0; Cloud Spanner disponible como servicio	Cockroach Labs; Google
2018	Oracle Autonomous Database	Oracle
2019	Oracle 19c, versión de soporte a largo plazo	Oracle
2020	Databricks propone el concepto lakehouse. Oracle 21c	Databricks; Oracle
2023	SQL:2023 (consultas de grafos SQL/PGQ, tipo JSON)	ISO
2024	Oracle Database 23ai (AI Vector Search). Estándar GQL para grafos (ISO/IEC 39075)	Oracle; ISO
2025	Oracle AI Database 26ai, nueva versión de soporte a largo plazo	Oracle

2.2. Línea temporal

timeline
    title Evolución de las bases de datos
    section Ficheros
        1890 : Tarjetas perforadas de Hollerith
        1951 : Cinta magnética en el UNIVAC I
        1956 : Primer disco duro, IBM RAMAC
    section Modelos navegacionales
        1964 : IDS de Bachman, modelo en red
        1968 : IMS para el programa Apolo, modelo jerárquico
        1971 : Informe CODASYL DBTG
    section Modelo relacional
        1970 : Artículo de Codd
        1974 : System R e Ingres, SEQUEL
        1979 : Oracle V2, primer SGBD SQL comercial
        1983 : IBM DB2
        1986 : Primer estándar SQL
    section Objetos y análisis
        1993 : ODMG y OLAP
        1996 : Almacenes de datos, Kimball
        1999 : SQL 1999 objeto-relacional
    section Web y código abierto
        1995 : MySQL
        1996 : PostgreSQL
        2000 : SQLite
    section Big Data y NoSQL
        2006 : Bigtable y Hadoop
        2007 : Dynamo
        2009 : MongoDB, Redis y el término NoSQL
    section Nube, NewSQL e IA
        2012 : Spanner
        2014 : Amazon Aurora
        2018 : Oracle Autonomous Database
        2024 : Oracle 23ai y búsqueda vectorial
        2025 : Oracle AI Database 26ai

2.3. Las grandes etapas

Etapa	Periodo aproximado	Modelo dominante	Problema que resolvía	Problema que dejaba
Ficheros	1950-1965	Ficheros secuenciales y luego directos	Automatizar el proceso de datos	Redundancia, dependencia física (módulo 01)
Navegacional	1965-1980	Jerárquico y en red	Integrar datos y compartirlos	Programas dependientes de la estructura; consultas difíciles
Relacional	1980 hasta hoy	Relacional (SQL)	Independencia de datos, consultas declarativas	Datos complejos, escalado horizontal masivo
Objetos y análisis	1985-2000	Objetos, objeto-relacional, almacenes de datos	Datos complejos, análisis histórico	Complejidad, poca adopción de las BD de objetos puras
Big Data y NoSQL	2005 hasta hoy	Clave-valor, documental, columnar, grafos	Escala web, datos semiestructurados	Consistencia más débil, menos estandarización
Nube e IA	2010 hasta hoy	NewSQL, DBaaS, lakehouse, vectorial, multimodelo	Escala global con transacciones, gestión automática, búsqueda semántica	En evolución

3. La prehistoria: tarjetas perforadas y ficheros en cinta (años 50 y 60)

3.1. Tarjetas perforadas

La primera “base de datos” mecanizada fue el censo de Estados Unidos de 1890. Herman Hollerith diseñó unas máquinas que leían tarjetas perforadas: cada tarjeta representaba a una persona, y la posición de los agujeros codificaba sus características (sexo, edad, estado civil…). La empresa de Hollerith acabaría formando parte de la que en 1924 pasó a llamarse IBM (International Business Machines).

Durante la primera mitad del siglo XX, las empresas procesaban sus nóminas y su contabilidad con equipos de registro unitario: clasificadoras, tabuladoras e intercaladoras de tarjetas. Cada tarjeta era un registro, cada grupo de columnas un campo, y un mazo de tarjetas un fichero. Los conceptos del módulo 01 nacieron aquí.

3.2. Cinta magnética y proceso por lotes

En los años cincuenta, los primeros ordenadores comerciales (como el UNIVAC I, de 1951) sustituyeron los mazos de tarjetas por cintas magnéticas, mucho más rápidas y compactas. Pero la cinta es un soporte secuencial, así que los datos se organizaban en ficheros secuenciales y se procesaban por lotes (batch processing):

Durante el día se acumulaban los movimientos (en tarjetas o en cinta).
Por la noche se ordenaban por la misma clave que el fichero maestro.
Un programa recorría a la vez el maestro y los movimientos, y generaba un nuevo maestro (el proceso que viste en el apartado 7.6 del módulo 01).

En 1959 se formó el comité CODASYL (Conference on Data Systems Languages), que creó el lenguaje COBOL, pensado precisamente para programar este tipo de aplicaciones de gestión con ficheros. CODASYL tendría después un papel decisivo en las bases de datos en red.

3.3. El disco cambia las reglas

En 1956, IBM presentó el IBM 350, el primer disco duro comercial, integrado en el sistema RAMAC (Random Access Method of Accounting and Control). Tenía 50 platos de 24 pulgadas y almacenaba unos 5 millones de caracteres. Por primera vez se podía acceder directamente a un registro sin leer todos los anteriores, lo que hizo posibles los ficheros de organización directa e indexada y, sobre todo, las aplicaciones en línea (online): consultar una cuenta en el momento, desde un terminal.

📘 Concepto: El paso de la cinta al disco permitió pasar del proceso por lotes al proceso en línea y al tiempo compartido, con muchos usuarios accediendo a la vez a los mismos datos. Eso planteó nuevos problemas (concurrencia, integridad, seguridad) que los ficheros no podían resolver y que dieron lugar a los primeros SGBD.

4. El modelo jerárquico

4.1. Historia: IMS y el programa Apolo

En 1961, el presidente Kennedy anunció el objetivo de llevar un hombre a la Luna. La empresa North American Aviation (luego North American Rockwell) obtuvo el contrato para construir la nave Apolo y se enfrentó a un problema monumental: gestionar la lista de materiales (bill of materials) de una nave con millones de piezas, organizadas en subconjuntos, que a su vez contenían otros subconjuntos…

En 1965 Rockwell se asoció con IBM y, a partir de 1966, un equipo de IBM, Rockwell y Caterpillar desarrolló un sistema llamado ICS/DL/I (Information Control System / Data Language/Interface). El primer mensaje “READY” apareció en un terminal de la división espacial de Rockwell, en Downey (California), el 14 de agosto de 1968. En 1969, IBM lo comercializó con el nombre de IMS/360 (Information Management System).

💡 Consejo: IMS no es una reliquia de museo: IBM sigue vendiéndolo y actualizándolo para sus mainframes (IBM Z), y muchos bancos, aseguradoras y administraciones públicas lo siguen usando para procesar enormes volúmenes de transacciones.

4.2. Estructura: el árbol

📘 Concepto: En el modelo jerárquico, los datos se organizan en árboles. Cada nodo del árbol es un segmento (equivalente a un registro), y los segmentos se relacionan mediante vínculos padre-hijo:

Cada árbol tiene un único segmento raíz.

Cada segmento padre puede tener varios hijos (relación 1:N).

Cada segmento hijo tiene un único padre.

Una base de datos jerárquica es un bosque de árboles.

Ejemplo: la base de datos de una empresa organizada jerárquicamente.

flowchart TB
    D["DEPARTAMENTO<br/>(raíz)"] --> E["EMPLEADO"]
    D --> P["PROYECTO"]
    E --> H["HIJO<br/>(familiar a cargo)"]
    E --> N["NÓMINA"]

Y una ocurrencia (los datos concretos) de ese árbol:

flowchart TB
    D30["30 INFORMÁTICA"] --> E120["120 Pablo Moreno"]
    D30 --> E121["121 Raquel Molina"]
    D30 --> P1["Proyecto: Nueva web"]
    E120 --> N1["Nómina 2026-09"]
    E120 --> N2["Nómina 2026-10"]
    E121 --> H1["Hijo: Marcos"]
    E121 --> N3["Nómina 2026-10"]

4.3. Cómo se almacena y se recorre

Los segmentos de cada árbol se almacenan habitualmente en preorden jerárquico (de arriba abajo y de izquierda a derecha):

30 INFORMÁTICA | 120 Pablo | Nómina 2026-09 | Nómina 2026-10 | 121 Raquel | Hijo Marcos | Nómina 2026-10 | Proyecto Nueva web

Los programas acceden a los datos navegando por el árbol con órdenes del lenguaje DL/I, como:

Orden DL/I	Significado
`GU` (Get Unique)	Obtener un segmento concreto (por ejemplo, el departamento 30)
`GN` (Get Next)	Obtener el siguiente segmento en preorden
`GNP` (Get Next within Parent)	Obtener el siguiente segmento hijo del padre actual
`ISRT`, `DLET`, `REPL`	Insertar, borrar, reemplazar un segmento

💻 Ejemplo: Pseudocódigo para listar los empleados del departamento 30 en una base de datos jerárquica:
GU  DEPARTAMENTO (dept_id = 30)          -- posicionarse en la raíz
GNP EMPLEADO                             -- primer empleado de ese departamento
MIENTRAS estado = OK
    mostrar nombre del empleado
    GNP EMPLEADO                         -- siguiente empleado del mismo padre
FIN MIENTRAS
El programador tiene que conocer la estructura del árbol y recorrerla paso a paso. Compáralo con SQL: SELECT nombre FROM empleados WHERE dept_id = 30;.

4.4. El problema de las relaciones N:M

Supongamos que un empleado puede trabajar en varios proyectos y un proyecto tiene varios empleados (una relación N:M, como ASIGNACIONES en el esquema EMPRESA). En un árbol, cada hijo solo puede tener un padre. Hay dos soluciones, ambas malas:

Duplicar segmentos: colocar PROYECTO como hijo de EMPLEADO, repitiendo el proyecto bajo cada empleado que trabaja en él. Resultado: redundancia e inconsistencia (si cambia el presupuesto del proyecto, hay que cambiarlo en todas las copias).
Punteros lógicos: IMS permite crear “relaciones lógicas” entre árboles distintos, mediante punteros. Funciona, pero complica enormemente la estructura y la programación.

flowchart TB
    subgraph A1["Árbol del empleado 120"]
        E1["EMPLEADO 120"] --> PA["PROYECTO Nueva web<br/>(copia 1)"]
        E1 --> PB["PROYECTO ERP<br/>(copia 1)"]
    end
    subgraph A2["Árbol del empleado 121"]
        E2["EMPLEADO 121"] --> PC["PROYECTO Nueva web<br/>(copia 2)"]
    end

4.5. Ventajas e inconvenientes

Ventajas	Inconvenientes
Muy eficiente para recorrer jerarquías naturales (listas de materiales, organigramas)	No representa bien las relaciones N:M ni las que no son jerárquicas
Rendimiento excelente en transacciones previstas	Los programas dependen de la estructura del árbol (falta de independencia)
Sencillo de entender cuando los datos son realmente jerárquicos	Consultas no previstas muy difíciles (“¿qué departamentos tienen proyectos de más de 100.000 €?” obliga a recorrer todos los árboles)
Integridad padre-hijo automática (si se borra un padre, se borran sus hijos)	Borrar un padre puede hacer perder información de los hijos que se quería conservar

📘 Concepto: Aunque las bases de datos jerárquicas puras sean hoy minoritarias, las estructuras jerárquicas están por todas partes: el sistema de ficheros de tu ordenador, el Registro de Windows, los documentos XML y JSON, los directorios LDAP o el DOM de una página web. Y en SQL de Oracle aprenderás a recorrer jerarquías almacenadas en tablas (como la de jefes de EMPLEADOS) con CONNECT BY (módulo 33).

5. El modelo en red

5.1. Historia: IDS, Bachman y CODASYL

Mientras IBM desarrollaba IMS, Charles Bachman, en General Electric, había creado el IDS (Integrated Data Store), operativo en 1963 y comercializado en 1964 para el ordenador GE 235. Se le considera el primer sistema gestor de bases de datos de la historia: por primera vez, un conjunto de ficheros compartidos en disco era gestionado por un software común al que los programas pedían los datos.

Bachman inventó también una forma de dibujar las estructuras de datos, los diagramas de Bachman (cajas unidas por flechas), antecedente de los diagramas E/R. En 1973 recibió el premio Turing; su conferencia se tituló “The Programmer as Navigator” (“El programador como navegante”), una descripción perfecta de cómo se trabajaba con estas bases de datos.

El comité CODASYL creó un grupo de trabajo, el DBTG (Data Base Task Group), que publicó en 1969 y, en su versión definitiva, en 1971 las especificaciones del modelo en red, basadas en las ideas de IDS. De ellas derivaron muchos productos; el más conocido fue IDMS (Integrated Database Management System), desarrollado a partir de IDS en la empresa B. F. Goodrich y comercializado desde 1973 por Cullinane (después Cullinet).

5.2. Estructura: registros y conjuntos (sets)

📘 Concepto: En el modelo en red (o modelo CODASYL), los datos se representan mediante:

Tipos de registro (record types): equivalentes a entidades (DEPARTAMENTO, EMPLEADO).

Tipos de conjunto (set types): relaciones 1:N con nombre entre un registro propietario (owner) y registros miembros (members).

A diferencia del modelo jerárquico, un registro puede ser miembro de varios conjuntos (tener varios “padres” de tipos distintos), lo que permite representar estructuras en forma de grafo y no solo de árbol.

flowchart LR
    DEP["DEPARTAMENTO"] -->|"set DEPT_EMP"| EMP["EMPLEADO"]
    DEP -->|"set DEPT_PROY"| PRO["PROYECTO"]
    EMP -->|"set EMP_ASIG"| ASI["ASIGNACION<br/>(registro de enlace)"]
    PRO -->|"set PROY_ASIG"| ASI

5.3. Relaciones N:M mediante registros de enlace

El modelo CODASYL solo admite conjuntos 1:N. Para una relación N:M (empleados y proyectos) se introduce un registro de enlace (link record), ASIGNACION, que es miembro de dos conjuntos a la vez: EMP_ASIG (cuyo propietario es el empleado) y PROY_ASIG (cuyo propietario es el proyecto). Fíjate en que es exactamente la misma idea que la tabla ASIGNACIONES del esquema EMPRESA.

Físicamente, cada conjunto se implementa con punteros: el propietario apunta a su primer miembro, cada miembro apunta al siguiente, y el último vuelve al propietario, formando un anillo.

 DEPARTAMENTO 30 ──► EMPLEADO 120 ──► EMPLEADO 121 ──► EMPLEADO 122 ──┐
        ▲                                                             │
        └─────────────────────────────────────────────────────────────┘
                         Ocurrencia del set DEPT_EMP

5.4. Navegación

Los programas (normalmente en COBOL) navegaban por la red con órdenes del DML de CODASYL:

💻 Ejemplo: Pseudocódigo CODASYL para obtener los nombres de los proyectos en los que trabaja el empleado 120:

MOVE 120 TO emp_id IN EMPLEADO
FIND ANY EMPLEADO USING emp_id            -- localizar al empleado
FIND FIRST ASIGNACION WITHIN EMP_ASIG     -- su primera asignación
PERFORM UNTIL fin-del-conjunto
    FIND OWNER WITHIN PROY_ASIG           -- subir al proyecto de esa asignación
    GET PROYECTO                          -- leer el registro del proyecto
    DISPLAY nombre IN PROYECTO
    FIND NEXT ASIGNACION WITHIN EMP_ASIG  -- siguiente asignación del empleado
END-PERFORM

El mismo resultado en SQL:

SELECT p.nombre
FROM   asignaciones a
       JOIN proyectos p ON p.proyecto_id = a.proyecto_id
WHERE  a.emp_id = 120;

5.5. Ventajas e inconvenientes

Ventajas	Inconvenientes
Representa relaciones más generales que el jerárquico (un registro con varios propietarios)	Los programas dependen de los conjuntos y punteros: falta de independencia
Acceso muy eficiente por los caminos previstos	Programación compleja y propensa a errores (“perderse” en la red)
Estandarizado por CODASYL	Cambiar la estructura obliga a reescribir programas
	Las consultas no previstas siguen requiriendo programar recorridos

⚠️ Importante: Los modelos jerárquico y en red se llaman navegacionales: el programador tiene que decir cómo llegar a los datos, siguiendo punteros paso a paso. El gran salto del modelo relacional fue permitir decir solo qué datos se quieren y dejar que el sistema decida cómo obtenerlos.

6. El modelo relacional

6.1. El artículo de Codd (1970)

Edgar Frank Codd (1923-2003), matemático británico que trabajaba en el laboratorio de investigación de IBM en San José (California), publicó en junio de 1970, en la revista Communications of the ACM, el artículo “A Relational Model of Data for Large Shared Data Banks” (“Un modelo relacional de datos para grandes bancos de datos compartidos”).

Sus ideas fundamentales fueron:

Los datos se representan como relaciones (en el sentido matemático de la teoría de conjuntos), que se pueden visualizar como tablas de filas y columnas.
No hay punteros visibles para el usuario: las relaciones entre datos se expresan mediante valores comunes (lo que hoy llamamos claves ajenas).
Independencia de datos: los programas no deben verse afectados por cambios en la representación interna de los datos (orden, índices, caminos de acceso).
Un lenguaje de manipulación basado en la lógica y el álgebra, que opera sobre conjuntos completos de filas y no registro a registro.
Normalización, para eliminar redundancias (que desarrollaría en artículos posteriores).

📘 Concepto: El modelo relacional separa limpiamente el nivel lógico (las tablas que ve el usuario) del nivel físico (cómo se guardan). Es la idea que hace posible la arquitectura ANSI/SPARC que estudiarás en el módulo 03, y la que justifica que hoy puedas crear un índice en Oracle sin tocar ni una línea de las aplicaciones.

Paradójicamente, IBM tardó en apostar por el modelo relacional: tenía una enorme inversión en IMS y dudaba de que un sistema relacional pudiera ser lo bastante eficiente. Codd recibió el premio Turing en 1981, y en 1985 publicó sus famosas reglas (las “12 reglas de Codd”, numeradas del 0 al 12) para determinar si un sistema era verdaderamente relacional. Las estudiarás en el módulo 16.

6.2. System R e Ingres: los prototipos

Para demostrar que el modelo relacional era viable, se desarrollaron dos prototipos de investigación a mediados de los setenta:

Prototipo	Dónde	Periodo	Aportaciones
System R	IBM San José	1974-1979	Lenguaje SEQUEL (luego SQL), optimizador de consultas basado en costes, gestión de transacciones y recuperación
Ingres	Universidad de California, Berkeley (Michael Stonebraker y Eugene Wong)	desde 1973	Lenguaje QUEL; su código y sus investigadores dieron origen a muchos productos comerciales (Ingres, Sybase y, a través de Sybase, Microsoft SQL Server) y al proyecto POSTGRES

6.3. De SEQUEL a SQL

En 1974, Donald Chamberlin y Raymond Boyce, del equipo de System R, presentaron SEQUEL (Structured English Query Language), un lenguaje de consulta con palabras en inglés, pensado para usuarios no programadores. Por problemas de marca registrada (el nombre SEQUEL ya pertenecía a otra empresa), el lenguaje pasó a llamarse SQL (Structured Query Language). Por eso aún hoy muchos profesionales lo pronuncian “sícuel” en lugar de deletrearlo.

💻 Ejemplo: Una consulta de SQL actual que se podría haber escrito, casi igual, en los años ochenta:
SELECT nombre, salario
FROM   empleados
WHERE  dept_id = 30
ORDER BY salario DESC;

6.4. Oracle: la primera empresa en comercializar SQL

Larry Ellison, Bob Miner y Ed Oates leyeron los artículos que IBM publicaba sobre System R y vieron una oportunidad: construir un SGBD relacional compatible con SQL antes que la propia IBM.

Año	Acontecimiento
1977	Fundan en California la empresa Software Development Laboratories (SDL). Según la historia más difundida, el nombre “Oracle” procede de un proyecto con ese nombre en clave en el que Ellison había trabajado para la CIA
1979	La empresa pasa a llamarse Relational Software, Inc. (RSI) y lanza Oracle Version 2, el primer SGBD relacional basado en SQL disponible comercialmente. No hubo “versión 1”: se llamó V2 para transmitir madurez
1983	La empresa adopta el nombre de su producto: Oracle Systems Corporation. Oracle V3 se reescribe en lenguaje C para poder portarse a distintas plataformas
1984	Oracle V4 introduce la consistencia de lectura multiversión (los lectores no bloquean a los escritores), una seña de identidad de Oracle hasta hoy
1985	Oracle V5, con soporte cliente/servidor y bases de datos distribuidas
1988	Oracle V6: bloqueo a nivel de fila y el lenguaje procedimental PL/SQL

La evolución posterior de Oracle Database resume, en buena medida, la historia de las bases de datos comerciales:

Versión	Año	Novedades destacadas
Oracle7	1992	Procedimientos almacenados y triggers en PL/SQL, commit en dos fases distribuido
Oracle8	1997	Características objeto-relacionales, particionamiento, RMAN (copias de seguridad)
Oracle8i	1998	La “i” de internet: Java dentro de la base de datos
Oracle9i	2001	Real Application Clusters (RAC), XML DB
Oracle10g	2003	La “g” de grid: ASM, flashback
Oracle11g	2007	Active Data Guard, compresión avanzada, Exadata
Oracle 12c	2013	La “c” de cloud: arquitectura multitenant (CDB y PDB), In-Memory, JSON
Oracle 18c, 19c	2018, 2019	Cambio a numeración por año; 19c es versión de soporte a largo plazo
Oracle 21c	2020	Versión de innovación: tablas blockchain, JSON binario
Oracle 23ai	2024	AI Vector Search (tipo `VECTOR`), JSON Relational Duality, tipo `BOOLEAN`
Oracle AI Database 26ai	2025	Nueva versión de soporte a largo plazo que sustituye a 23ai, con más funciones de IA integradas

💡 Consejo: En el módulo 03 verás la arquitectura de Oracle (instancia, base de datos, CDB y PDB) y en el módulo 22 aprenderás a instalar Oracle AI Database 26ai Free.

6.5. IBM DB2, Informix, Sybase y SQL Server

Producto	Origen	Hitos
SQL/DS y DB2 (IBM)	Herederos de System R	SQL/DS en 1981; DB2 para mainframe en 1983. Hoy la familia se comercializa como IBM Db2 en varias plataformas
Informix	Roger Sippl funda Relational Database Systems en 1980; su producto se llama INFORMIX y la empresa adopta después ese nombre	Muy popular en sistemas Unix; IBM la compró en 2001
Sybase	Fundada en 1984 por Mark Hoffman y Robert Epstein (este procedente del entorno de Ingres)	Sybase SQL Server para Unix (1987). Hoy, SAP ASE (SAP compró Sybase en 2010)
Microsoft SQL Server	Acuerdo de Microsoft con Sybase (y Ashton-Tate)	SQL Server 1.0 para OS/2 en 1989. En los noventa Microsoft se separó de Sybase y desarrolló su propio producto. Hoy es uno de los SGBD comerciales más usados

flowchart LR
    SR["System R<br/>(IBM, 1974)"] --> SQLDS["SQL/DS<br/>(1981)"] --> DB2["DB2<br/>(1983)"]
    SR -. "artículos publicados" .-> ORA["Oracle V2<br/>(1979)"]
    ING["Ingres<br/>(Berkeley, 1973)"] --> INGC["Ingres<br/>comercial"]
    ING --> SYB["Sybase<br/>(1984)"] --> MSSQL["Microsoft<br/>SQL Server (1989)"]
    ING --> PG["POSTGRES (1986)<br/>→ PostgreSQL (1996)"]

6.6. La estandarización de SQL

Con tantos fabricantes usando SQL, era necesario un estándar. ANSI publicó el primero en 1986 e ISO lo adoptó en 1987. Desde entonces el estándar se ha revisado periódicamente:

Versión	Año	Aportaciones principales
SQL-86 (SQL-87 en ISO)	1986/1987	Primer estándar: consultas básicas, definición de tablas
SQL-89	1989	Restricciones de integridad (claves primarias y ajenas)
SQL-92 (SQL2)	1992	Gran revisión: `JOIN` explícito, nuevos tipos, `CASE`, restricciones diferidas, niveles de conformidad
SQL:1999 (SQL3)	1999	Consultas recursivas, triggers, tipos definidos por el usuario y características objeto-relacionales, `BOOLEAN`
SQL:2003	2003	Funciones de ventana (analíticas), `MERGE`, columnas identidad, XML
SQL:2006	2006	Integración con XML y XQuery
SQL:2008	2008	`TRUNCATE`, triggers `INSTEAD OF`, `FETCH FIRST`
SQL:2011	2011	Datos temporales (tablas con periodos de validez)
SQL:2016	2016	JSON, reconocimiento de patrones en filas (`MATCH_RECOGNIZE`)
SQL:2023	2023	Consultas de grafos de propiedades (SQL/PGQ), tipo JSON, mejoras varias

⚠️ Importante: Ningún SGBD implementa el estándar completo, y todos añaden extensiones propias. Por eso hablamos de “SQL de Oracle”, “SQL de PostgreSQL”… En este curso usarás el SQL de Oracle, indicando cuándo algo es estándar y cuándo es propio de Oracle. Lo verás con más detalle en el módulo 22.

6.7. El modelo Entidad/Relación

En 1976, Peter Chen publicó “The Entity-Relationship Model: Toward a Unified View of Data”, que proponía un modelo conceptual, independiente del SGBD, para describir la realidad mediante entidades, relaciones y atributos. El modelo E/R, ampliado después con generalizaciones y otras construcciones (E/R extendido), se convirtió en la herramienta estándar de diseño conceptual y es el protagonista del bloque 2 de este curso.

6.8. ¿Por qué ganó el modelo relacional?

Factor	Explicación
Sencillez	Todo son tablas; cualquier persona entiende una tabla
Fundamento matemático	Teoría de conjuntos, lógica de predicados, álgebra relacional: permite razonar formalmente sobre los datos y optimizar consultas
Independencia de datos	Los programas no dependen de la estructura física
Lenguaje declarativo	SQL dice qué se quiere, no cómo obtenerlo
Consultas no previstas	Cualquier pregunta se puede formular sin programar nada nuevo
Optimizadores	Los optimizadores de consultas lograron un rendimiento comparable al de los sistemas navegacionales
Estandarización	SQL estándar facilita la formación y la portabilidad
Hardware	El abaratamiento de la memoria y la CPU compensó el coste de su mayor abstracción

7. Bases de datos orientadas a objetos y objeto-relacionales

7.1. El desajuste de impedancia

En los años ochenta y noventa se impusieron los lenguajes orientados a objetos (C++, Smalltalk y, después, Java). Los programadores trabajaban con objetos complejos (con atributos que son a su vez objetos, listas, herencia), pero tenían que guardarlos en tablas planas. A esta incomodidad se le llamó desajuste de impedancia (impedance mismatch).

💻 Ejemplo: En un programa, un objeto Pedido contiene una lista de objetos Linea, cada una con una referencia a un Producto. Para guardarlo en una base de datos relacional hay que “despiezarlo” en filas de tres tablas (PEDIDOS, LINEAS_PEDIDO, PRODUCTOS) y, para recuperarlo, volver a montarlo con joins. Hoy esta tarea la automatizan los ORM (Object-Relational Mapping) como Hibernate, Entity Framework o Doctrine.

7.2. Bases de datos orientadas a objetos (SGBDOO)

Las bases de datos orientadas a objetos guardan directamente los objetos del lenguaje de programación, con su identidad, sus referencias, herencia y métodos. Productos como GemStone, ObjectStore, Versant, O2 u Objectivity surgieron entre finales de los ochenta y los noventa.

En 1991 se creó el ODMG (Object Data Management Group), que publicó en 1993 un estándar con un modelo de objetos, un lenguaje de definición (ODL) y un lenguaje de consulta (OQL), con revisiones posteriores hasta la versión 3.0 (2000).

Las bases de datos de objetos puras no lograron desplazar a las relacionales: carecían de un fundamento teórico tan sólido, el estándar ODMG se implementó de forma desigual, el lenguaje de consulta estaba poco extendido y las empresas ya tenían enormes inversiones en SQL. Sobreviven en nichos (CAD, telecomunicaciones, sistemas embebidos).

7.3. Bases de datos objeto-relacionales

La respuesta de la industria fue ampliar el modelo relacional con características de objetos, sin renunciar a SQL. Son las bases de datos objeto-relacionales:

Tipos definidos por el usuario (tipos estructurados con atributos y métodos).
Herencia de tipos y de tablas.
Colecciones (arrays, tablas anidadas).
Referencias entre objetos (REF).
Tipos para datos complejos (multimedia, espaciales, texto).

Pioneros: el proyecto POSTGRES de Stonebraker (1986), los productos Illustra e Informix Universal Server, Oracle8 (1997) y DB2. El estándar SQL:1999 incorporó estas ideas.

💡 Consejo: Oracle sigue ofreciendo tipos de objeto (CREATE TYPE ... AS OBJECT), pero en la práctica profesional se usan poco para modelar datos de negocio: lo habitual es diseñar tablas relacionales normalizadas y dejar los objetos para la capa de aplicación. En este curso no los usaremos.

8. Almacenes de datos: OLTP frente a OLAP

8.1. Dos formas de usar los datos

Al generalizarse las bases de datos relacionales en las empresas, apareció un conflicto: las mismas bases de datos que registraban las ventas del día tenían que responder a preguntas del tipo “¿cómo han evolucionado las ventas por región y por categoría en los últimos cinco años?”. Esas consultas leían millones de filas y ralentizaban el sistema que atendía a los clientes.

Característica	OLTP (Online Transaction Processing)	OLAP (Online Analytical Processing)
Propósito	Registrar las operaciones del negocio	Analizar el negocio y apoyar decisiones
Usuarios	Muchos (empleados, clientes, aplicaciones)	Pocos (analistas, directivos)
Operaciones	Muchas transacciones cortas: insertar, modificar, consultar pocas filas	Pocas consultas largas y complejas que agregan millones de filas
Datos	Actuales y detallados	Históricos, integrados y agregados
Diseño	Normalizado (evitar redundancia)	Desnormalizado (esquemas en estrella), orientado a la consulta
Prioridad	Tiempo de respuesta, concurrencia, integridad	Velocidad de consultas masivas
Ejemplo	Registrar un pedido en el esquema EMPRESA	“Ventas por trimestre, provincia y categoría de 2020 a 2026”

El término OLAP lo acuñó el propio Codd en 1993.

8.2. El almacén de datos (data warehouse)

📘 Concepto: Un almacén de datos (data warehouse) es, según la definición clásica de Bill Inmon, una colección de datos orientada a temas, integrada, no volátil y variable en el tiempo, que sirve de apoyo a la toma de decisiones.

Propiedad	Significado
Orientado a temas	Organizado por áreas de negocio (ventas, clientes, productos), no por aplicaciones
Integrado	Reúne datos de muchas fuentes con formatos y códigos unificados
No volátil	Los datos se cargan y se consultan, pero no se modifican ni borran en el día a día
Variable en el tiempo	Guarda la historia: cada dato está asociado a un momento o periodo

Los datos llegan al almacén mediante procesos ETL (Extract, Transform, Load): se extraen de las bases de datos operacionales, se transforman (limpieza, unificación de códigos, cálculos) y se cargan en el almacén, normalmente por la noche.

flowchart LR
    O1[("BD ventas<br/>(OLTP)")] --> ETL["Proceso ETL<br/>extraer, transformar,<br/>cargar"]
    O2[("BD RR. HH.<br/>(OLTP)")] --> ETL
    O3["Ficheros<br/>externos"] --> ETL
    ETL --> DW[("Almacén de<br/>datos")]
    DW --> DM1[("Data mart<br/>ventas")]
    DW --> DM2[("Data mart<br/>finanzas")]
    DM1 --> BI["Informes, cuadros<br/>de mando, OLAP"]
    DM2 --> BI

8.3. Inmon frente a Kimball

Dos autores marcaron la forma de construir almacenes de datos:

Aspecto	Bill Inmon (Building the Data Warehouse, 1992)	Ralph Kimball (The Data Warehouse Toolkit, 1996)
Enfoque	De arriba abajo (top-down)	De abajo arriba (bottom-up)
Núcleo	Un almacén corporativo normalizado (3FN), del que se derivan data marts departamentales	Un conjunto de data marts dimensionales integrados mediante dimensiones compartidas (“conformadas”)
Modelo	Relacional normalizado en el almacén central	Esquemas en estrella: tablas de hechos rodeadas de tablas de dimensiones
Ventajas	Visión corporativa única, consistencia	Resultados rápidos, fácil de entender por el negocio
Inconvenientes	Proyecto largo y costoso	Riesgo de inconsistencias si no se planifica bien

💻 Ejemplo: Un esquema en estrella para analizar las ventas del esquema EMPRESA: una tabla de hechos HECHOS_VENTAS (importe, unidades, descuento) con claves hacia las dimensiones DIM_FECHA (día, mes, trimestre, año), DIM_CLIENTE (ciudad, provincia), DIM_PRODUCTO (nombre, categoría) y DIM_EMPLEADO (comercial, departamento).

erDiagram
    DIM_FECHA ||--o{ HECHOS_VENTAS : "cuándo"
    DIM_CLIENTE ||--o{ HECHOS_VENTAS : "quién compra"
    DIM_PRODUCTO ||--o{ HECHOS_VENTAS : "qué se vende"
    DIM_EMPLEADO ||--o{ HECHOS_VENTAS : "quién vende"
    HECHOS_VENTAS {
        NUMBER fecha_id FK
        NUMBER cliente_id FK
        NUMBER producto_id FK
        NUMBER empleado_id FK
        NUMBER unidades
        NUMBER importe
        NUMBER descuento
    }
    DIM_FECHA {
        NUMBER fecha_id PK
        NUMBER mes
        NUMBER trimestre
        NUMBER anio
    }

Cada fila de la tabla de hechos es una venta (o una línea de pedido); las dimensiones permiten “cortar” las cifras por fecha, cliente, producto o empleado.

Hoy los almacenes de datos se ofrecen a menudo como servicios en la nube (Oracle Autonomous Data Warehouse, Amazon Redshift, Google BigQuery, Snowflake, Azure Synapse…).

9. La web y las bases de datos libres

9.1. El auge de la web

A mediados de los noventa, internet llevó las bases de datos a todas partes: cada web dinámica (tiendas, foros, periódicos) necesitaba una. Los SGBD comerciales eran caros, y surgieron alternativas libres (de código abierto) que se convirtieron en la base de la web.

La combinación LAMP (Linux + Apache + MySQL + PHP/Perl/Python) fue durante años la plataforma estándar para construir aplicaciones web.

9.2. Las cuatro grandes bases de datos libres

SGBD	Origen	Características	Licencia
MySQL	Creado por Michael “Monty” Widenius, David Axmark y Allan Larsson; primera versión en 1995 (empresa MySQL AB, Suecia). Sun Microsystems compró MySQL AB en 2008 y Oracle compró Sun en 2010	Rápido, sencillo, muy popular en la web (WordPress, Drupal…)	Doble licencia: GPL (Community) y comercial (Enterprise)
PostgreSQL	Heredero del proyecto POSTGRES de Stonebraker en Berkeley (1986); Postgres95 incorporó SQL y en 1996 adoptó el nombre PostgreSQL	El SGBD libre más completo y fiel al estándar; objeto-relacional, muy extensible (tipos, índices, extensiones como PostGIS o pgvector)	Licencia PostgreSQL (permisiva, tipo BSD/MIT)
SQLite	Creado por D. Richard Hipp en 2000	Embebido: no es un servidor, sino una biblioteca que guarda toda la base de datos en un único fichero. Está en todos los móviles, navegadores y multitud de aplicaciones	Dominio público
MariaDB	Fork (bifurcación) de MySQL creado en 2009 por Monty Widenius ante la previsible compra de Sun por Oracle	Compatible con MySQL en gran medida, con motores y funciones propias	GPL

💡 Consejo: SQLite es probablemente el SGBD más desplegado del mundo: hay una copia en cada teléfono Android e iPhone, en cada navegador y en innumerables aplicaciones. Pero, por su naturaleza embebida, no está pensado para muchos usuarios escribiendo a la vez a través de la red.

10. Big Data y NoSQL

10.1. El problema de la escala web

A principios de los 2000, empresas como Google, Amazon, Facebook o Yahoo se enfrentaron a volúmenes de datos y de usuarios sin precedentes: miles de millones de páginas web, cientos de millones de usuarios, picos de tráfico imprevisibles. Las bases de datos relacionales de la época estaban diseñadas para crecer verticalmente (comprar un servidor más grande), y había un límite físico y económico.

Estrategia	Descripción	Ventajas	Inconvenientes
Escalado vertical (scale up)	Un servidor más potente (más CPU, RAM, disco)	Sencillo, sin cambios en la aplicación	Caro, con un límite físico, punto único de fallo
Escalado horizontal (scale out)	Más servidores baratos trabajando juntos	Prácticamente ilimitado, tolerante a fallos	Datos repartidos: consistencia y transacciones complicadas

Se habló de las “tres V” del Big Data: Volumen (enormes cantidades de datos), Velocidad (datos que llegan y deben procesarse continuamente) y Variedad (datos estructurados, semiestructurados y no estructurados). Después se añadieron otras, como Veracidad y Valor.

10.2. Los artículos que lo cambiaron todo

Año	Publicación	Idea
2003	The Google File System (Google)	Sistema de ficheros distribuido sobre miles de máquinas baratas
2004	MapReduce (Google)	Modelo de programación para procesar datos en paralelo en un clúster
2006	Bigtable: A Distributed Storage System for Structured Data (Google)	Almacén distribuido de familias de columnas, base de HBase y de Cassandra
2007	Dynamo: Amazon’s Highly Available Key-value Store (Amazon)	Almacén clave-valor distribuido que prioriza la disponibilidad, con consistencia eventual

Inspirados por estos artículos nacieron proyectos de código abierto: Hadoop (2006, implementación libre de GFS y MapReduce), HBase (inspirado en Bigtable), Cassandra (creado en Facebook, que combinaba ideas de Bigtable y Dynamo, liberado en 2008).

10.3. ¿Qué significa NoSQL?

El término NoSQL se usó en 1998 para una pequeña base de datos relacional sin SQL, pero se popularizó en 2009, cuando se eligió como etiqueta para un encuentro sobre bases de datos distribuidas no relacionales. Hoy se interpreta como “Not only SQL” (“no solo SQL”).

📘 Concepto: NoSQL designa una familia heterogénea de bases de datos que no siguen el modelo relacional y que, en general, comparten estas características:

Esquema flexible (o sin esquema fijo): cada elemento puede tener estructura distinta.

Escalado horizontal y distribución de los datos en muchos nodos.

Alta disponibilidad mediante replicación.

Modelos de datos adaptados a casos de uso concretos.

A menudo, consistencia relajada a cambio de rendimiento y disponibilidad.

10.4. El teorema CAP

En el año 2000, Eric Brewer enunció una conjetura que Seth Gilbert y Nancy Lynch (MIT) demostraron formalmente en 2002: un sistema de datos distribuido no puede garantizar simultáneamente estas tres propiedades:

Propiedad	Significado
Consistencia (Consistency)	Todos los nodos ven los mismos datos al mismo tiempo: cualquier lectura devuelve la última escritura
Disponibilidad (Availability)	Toda petición a un nodo que funciona recibe respuesta
Tolerancia a particiones (Partition tolerance)	El sistema sigue funcionando aunque se corte la comunicación entre nodos

flowchart TB
    C["C<br/>Consistencia"] --- A["A<br/>Disponibilidad"]
    A --- P["P<br/>Tolerancia a<br/>particiones"]
    P --- C
    CP["Sistemas CP<br/>ante un corte, rechazan<br/>peticiones para no dar<br/>datos desactualizados"] -.-> C
    CP -.-> P
    AP["Sistemas AP<br/>ante un corte, siguen<br/>respondiendo aunque<br/>los datos difieran"] -.-> A
    AP -.-> P

⚠️ Importante: En una red real, las particiones (cortes de comunicación) ocurren, así que la tolerancia a particiones no es opcional. La elección real es: cuando hay una partición, ¿priorizo la consistencia (sistema CP: rechazo peticiones hasta que se restablezca la comunicación) o la disponibilidad (sistema AP: sigo respondiendo, aunque algunos nodos devuelvan datos desactualizados)? Cuando no hay particiones, un sistema puede ofrecer consistencia y disponibilidad a la vez.

💻 Ejemplo: Un carrito de la compra suele diseñarse como AP: es preferible que el cliente pueda seguir añadiendo productos aunque un nodo no esté sincronizado (luego se fusionan los cambios) a mostrarle un error. El saldo de una cuenta bancaria debe ser CP: es preferible rechazar temporalmente un pago a permitir gastar dos veces el mismo dinero.

10.5. ACID frente a BASE

Las bases de datos relacionales garantizan las propiedades ACID en sus transacciones (las verás en detalle en el módulo 03). Muchas bases de datos NoSQL optaron por un modelo más relajado, llamado BASE:

ACID	BASE
Atomicidad: la transacción se hace entera o no se hace	Basically Available: el sistema está básicamente disponible, aunque falle parte
Consistencia: la transacción lleva la BD de un estado válido a otro válido	Soft state: el estado puede cambiar con el tiempo aunque no haya nuevas escrituras (por la sincronización entre réplicas)
aIslamiento: las transacciones concurrentes no interfieren entre sí	Eventual consistency: si dejan de llegar escrituras, todas las réplicas acabarán teniendo los mismos datos
Durabilidad: lo confirmado no se pierde
Enfoque pesimista: prioriza la corrección	Enfoque optimista: prioriza la disponibilidad y la escala

💡 Consejo: La frontera se ha difuminado: muchas bases de datos NoSQL modernas (MongoDB, por ejemplo) ofrecen transacciones ACID y consistencia configurable, y las relacionales han incorporado JSON, distribución y escalado horizontal. Elige por el caso de uso, no por la etiqueta.

10.6. Los cuatro grandes tipos de bases de datos NoSQL

Clave-valor

📘 Concepto: Una base de datos clave-valor es, conceptualmente, un diccionario (o tabla hash) gigante y distribuido: cada clave única está asociada a un valor opaco (texto, número, JSON, binario) que la base de datos no interpreta. Las operaciones básicas son get, put y delete por clave.

Ejemplos: Redis, Amazon DynamoDB (que también admite documentos), Memcached (caché), Valkey, etcd.
Casos de uso: cachés, sesiones de usuario, carritos de la compra, contadores, colas, clasificaciones (leaderboards) de videojuegos.
Puntos fuertes: rapidísima (Redis trabaja en memoria), muy escalable, sencilla.
Limitaciones: solo se busca por la clave; no hay consultas por el contenido del valor (salvo extensiones), ni relaciones.

Documental

📘 Concepto: Una base de datos documental almacena documentos semiestructurados (normalmente JSON o su versión binaria BSON), agrupados en colecciones. Cada documento tiene un identificador y puede contener campos anidados y listas; dos documentos de la misma colección pueden tener estructuras distintas. A diferencia del clave-valor, la base de datos entiende el contenido y permite consultar e indexar cualquier campo.

Ejemplos: MongoDB, Couchbase, Amazon DocumentDB, Azure Cosmos DB, CouchDB. Oracle también ofrece un modelo documental (colecciones JSON, API compatible con MongoDB, JSON Relational Duality).
Casos de uso: catálogos de productos con atributos variables, gestión de contenidos, perfiles de usuario, aplicaciones web y móviles, registro de eventos.
Puntos fuertes: el documento encaja con los objetos de los lenguajes de programación (menos desajuste de impedancia); esquema flexible; lectura de un “agregado” completo de una vez.
Limitaciones: los datos se duplican al incrustarlos; las relaciones entre documentos son menos naturales que en SQL.

Columnar (familias de columnas)

📘 Concepto: Una base de datos de familias de columnas (wide-column store) organiza los datos en filas identificadas por una clave, y cada fila puede tener un número variable y muy grande de columnas, agrupadas en familias. Los datos se reparten entre los nodos según una clave de partición, y dentro de cada partición se ordenan por una clave de agrupación. Se diseña a partir de las consultas que se van a hacer, no a partir de las entidades.

Ejemplos: Apache Cassandra, Apache HBase, Google Bigtable, ScyllaDB.
Casos de uso: escrituras masivas y continuas (sensores IoT, registros de actividad, mensajería), series temporales, históricos de grandísimo volumen.
Puntos fuertes: escalado lineal a cientos de nodos, escrituras rapidísimas, alta disponibilidad (Cassandra no tiene nodo maestro).
Limitaciones: sin joins; cada consulta necesita su tabla diseñada a medida; modelo de datos menos intuitivo.

⚠️ Importante: No confundas las bases de datos de familias de columnas (Cassandra, HBase) con las bases de datos relacionales de almacenamiento columnar (como Oracle In-Memory en su formato columnar, Amazon Redshift o ClickHouse), que guardan cada columna de una tabla de forma contigua para acelerar las consultas analíticas. Son conceptos distintos que comparten la palabra “columna”.

Grafos

📘 Concepto: Una base de datos de grafos representa los datos como nodos (entidades) y aristas o relaciones (conexiones entre nodos), ambos con propiedades. Está optimizada para recorrer relaciones: seguir una arista cuesta lo mismo tenga la base de datos mil o mil millones de nodos.

Ejemplos: Neo4j (lenguaje Cypher), Amazon Neptune, TigerGraph, JanusGraph. Oracle permite definir grafos de propiedades sobre tablas relacionales y consultarlos con SQL/PGQ.
Casos de uso: redes sociales (“amigos de mis amigos”), motores de recomendación, detección de fraude (cadenas de transferencias sospechosas), rutas y logística, grafos de conocimiento, gestión de redes y dependencias.
Puntos fuertes: consultas de relaciones profundas mucho más naturales y rápidas que con muchos joins.
Limitaciones: menos adecuadas para agregaciones masivas sobre todos los datos; escalado horizontal más difícil.

📘 Concepto: Curiosamente, las bases de datos de grafos recuperan la idea de navegar por relaciones del modelo en red de los años sesenta, pero con lenguajes declarativos (Cypher, GQL, SQL/PGQ). En 2024 se publicó GQL (ISO/IEC 39075), el primer lenguaje de consulta de bases de datos estandarizado por ISO desde SQL.

10.7. El mismo dato en cada tipo de base de datos

Veamos cómo se guardaría la misma información en cada modelo: la clienta 1003, María José Herrera, de Madrid, atendida por el comercial 111 (David Torres), y su pedido 5003 del 03/02/2025, con un Portátil Básico 15 (499,00 €) y unos Auriculares Bluetooth (59,90 €). Son datos reales del esquema EMPRESA.

En una base de datos relacional (Oracle)

Los datos se reparten en tablas normalizadas, relacionadas por claves:

CLIENTES
CLIENTE_ID NOMBRE              CIUDAD   COMERCIAL_ID
---------- ------------------- -------- ------------
      1003 María José Herrera  Madrid            111

PEDIDOS
 PEDIDO_ID CLIENTE_ID EMPLEADO_ID FECHA_PEDIDO ESTADO
---------- ---------- ----------- ------------ ---------
      5003       1003         111 03/02/2025   ENTREGADO

LINEAS_PEDIDO
 PEDIDO_ID  NUM_LINEA PRODUCTO_ID   CANTIDAD PRECIO_UNITARIO
---------- ---------- ----------- ---------- ---------------
      5003          1           3          1             499
      5003          2          13          1            59,9

PRODUCTOS
PRODUCTO_ID NOMBRE
----------- ----------------------
          3 Portátil Básico 15
         13 Auriculares Bluetooth

-- Ejemplo ilustrativo: reconstruir el pedido completo
SELECT c.nombre, p.pedido_id, p.fecha_pedido, pr.nombre AS producto, l.precio_unitario
FROM   clientes c
       JOIN pedidos p        ON p.cliente_id  = c.cliente_id
       JOIN lineas_pedido l  ON l.pedido_id   = p.pedido_id
       JOIN productos pr     ON pr.producto_id = l.producto_id
WHERE  p.pedido_id = 5003;

En una base de datos clave-valor (Redis)

Cada elemento se guarda bajo una clave construida por convenio; el valor es opaco para la base de datos:

SET cliente:1003 '{"nombre":"María José Herrera","ciudad":"Madrid","comercial":111}'
SET pedido:5003  '{"cliente":1003,"fecha":"2025-02-03","estado":"ENTREGADO","lineas":[{"producto":"Portátil Básico 15","precio":499.00},{"producto":"Auriculares Bluetooth","precio":59.90}]}'
RPUSH cliente:1003:pedidos 5003

GET pedido:5003                  -- se recupera el pedido completo por su clave
LRANGE cliente:1003:pedidos 0 -1 -- lista de pedidos de la clienta

Para responder “¿qué clientes de Madrid compraron auriculares?” no hay consulta posible: habría que leer todas las claves y examinar los valores en la aplicación (o mantener a mano estructuras auxiliares).

En una base de datos documental (MongoDB)

El pedido se guarda como un documento que incrusta sus líneas y una copia de los datos del cliente que interesan:

{
  "_id": 5003,
  "fecha": "2025-02-03",
  "estado": "ENTREGADO",
  "cliente": {
    "id": 1003,
    "nombre": "María José Herrera",
    "ciudad": "Madrid"
  },
  "comercial": { "id": 111, "nombre": "David Torres" },
  "lineas": [
    { "num": 1, "producto": "Portátil Básico 15", "cantidad": 1, "precio": 499.00 },
    { "num": 2, "producto": "Auriculares Bluetooth", "cantidad": 1, "precio": 59.90 }
  ]
}

// Pedidos de clientes de Madrid que incluyen auriculares
db.pedidos.find({ "cliente.ciudad": "Madrid", "lineas.producto": /Auriculares/ })

Un solo acceso devuelve el pedido completo. A cambio, el nombre de la clienta está duplicado en cada uno de sus pedidos: si cambia, hay que actualizarlo en todos.

En una base de datos de familias de columnas (Cassandra)

Se diseña una tabla para cada consulta. Si la consulta principal es “pedidos de un cliente, del más reciente al más antiguo”:

-- CQL (Cassandra Query Language): parece SQL, pero no lo es
CREATE TABLE pedidos_por_cliente (
    cliente_id    int,
    fecha_pedido  date,
    pedido_id     int,
    num_linea     int,
    cliente       text,
    producto      text,
    precio        decimal,
    PRIMARY KEY ((cliente_id), fecha_pedido, pedido_id, num_linea)
) WITH CLUSTERING ORDER BY (fecha_pedido DESC, pedido_id ASC, num_linea ASC);

INSERT INTO pedidos_por_cliente (cliente_id, fecha_pedido, pedido_id, num_linea, cliente, producto, precio)
VALUES (1003, '2025-02-03', 5003, 1, 'María José Herrera', 'Portátil Básico 15', 499.00);
INSERT INTO pedidos_por_cliente (cliente_id, fecha_pedido, pedido_id, num_linea, cliente, producto, precio)
VALUES (1003, '2025-02-03', 5003, 2, 'María José Herrera', 'Auriculares Bluetooth', 59.90);

SELECT * FROM pedidos_por_cliente WHERE cliente_id = 1003;

cliente_id es la clave de partición (decide en qué nodo se guardan los datos) y el resto de la clave ordena las filas dentro de la partición. Si mañana se necesita “pedidos por producto”, se crea otra tabla con los mismos datos organizados de otra forma.

En una base de datos de grafos (Neo4j)

Clientes, empleados, pedidos y productos son nodos, y sus conexiones, relaciones con propiedades:

// Cypher (Neo4j)
CREATE (c:Cliente  {id: 1003, nombre: 'María José Herrera', ciudad: 'Madrid'})
CREATE (e:Empleado {id: 111, nombre: 'David Torres'})
CREATE (p:Pedido   {id: 5003, fecha: date('2025-02-03'), estado: 'ENTREGADO'})
CREATE (a:Producto {id: 3,  nombre: 'Portátil Básico 15'})
CREATE (b:Producto {id: 13, nombre: 'Auriculares Bluetooth'})
CREATE (e)-[:ATIENDE]->(c)
CREATE (c)-[:REALIZA]->(p)
CREATE (p)-[:CONTIENE {cantidad: 1, precio: 499.00}]->(a)
CREATE (p)-[:CONTIENE {cantidad: 1, precio: 59.90}]->(b)

// "Qué otros productos compraron los clientes que compraron auriculares"
MATCH (:Producto {nombre: 'Auriculares Bluetooth'})<-[:CONTIENE]-(:Pedido)<-[:REALIZA]-(cli:Cliente)
      -[:REALIZA]->(:Pedido)-[:CONTIENE]->(otro:Producto)
RETURN otro.nombre, count(*) AS veces
ORDER BY veces DESC

flowchart LR
    E["Empleado 111<br/>David Torres"] -->|ATIENDE| C["Cliente 1003<br/>María José Herrera"]
    C -->|REALIZA| P["Pedido 5003<br/>03/02/2025"]
    P -->|"CONTIENE<br/>499,00"| A["Producto 3<br/>Portátil Básico 15"]
    P -->|"CONTIENE<br/>59,90"| B["Producto 13<br/>Auriculares Bluetooth"]

Comparación

Modelo	Unidad de almacenamiento	Recuperar el pedido 5003	“Clientes de Madrid que compraron auriculares”	Redundancia
Relacional	Filas en tablas normalizadas	Consulta con joins	Consulta SQL directa	Mínima
Clave-valor	Valor opaco bajo una clave	`GET pedido:5003` (1 acceso)	No soportada: hay que hacerlo en la aplicación	Alta, gestionada a mano
Documental	Documento JSON con datos incrustados	1 acceso	Consulta sobre campos del documento	Media (datos del cliente copiados)
Familias de columnas	Filas de una partición, diseñadas por consulta	1 partición	Requiere otra tabla diseñada para esa consulta	Alta (una tabla por consulta)
Grafos	Nodos y relaciones	Recorrer las relaciones del nodo	Patrón de recorrido muy natural	Mínima

10.8. Tabla resumen de los tipos NoSQL

Tipo	Modelo	Ejemplos	Casos de uso ideales	No recomendado para
Clave-valor	Diccionario clave → valor	Redis, DynamoDB, Memcached, Valkey	Caché, sesiones, contadores, colas	Consultas por contenido, relaciones
Documental	Colecciones de documentos JSON	MongoDB, Couchbase, Cosmos DB	Catálogos, contenidos, perfiles, apps móviles	Muchas relaciones N:M, transacciones complejas entre muchos documentos
Familias de columnas	Filas con columnas dinámicas, particionadas	Cassandra, HBase, Bigtable, ScyllaDB	Escrituras masivas, IoT, logs, series temporales	Consultas ad hoc, joins, datos pequeños
Grafos	Nodos y relaciones con propiedades	Neo4j, Neptune, TigerGraph	Redes sociales, recomendaciones, fraude, rutas	Agregaciones masivas sobre todos los datos

11. NewSQL y bases de datos distribuidas

11.1. Bases de datos distribuidas

📘 Concepto: Una base de datos distribuida es una base de datos cuyos datos están repartidos físicamente entre varios nodos (servidores) conectados por una red, pero que se presenta al usuario como una única base de datos lógica.

Dos técnicas fundamentales:

Técnica	Descripción	Objetivo
Fragmentación (sharding, particionamiento)	Cada nodo guarda una parte de los datos (por ejemplo, los clientes de cada país, o según un hash de la clave)	Escalabilidad: repartir la carga y el volumen
Replicación	Cada dato se guarda en varios nodos	Disponibilidad y rendimiento de lectura

Las bases de datos distribuidas no son nuevas (ya había prototipos en los años setenta y ochenta, y Oracle V5 de 1985 admitía consultas distribuidas), pero el reto de mantener transacciones ACID entre muchos nodos repartidos por el mundo no se resolvió a gran escala hasta mucho después.

11.2. NewSQL

El término NewSQL lo acuñó en 2011 Matthew Aslett, analista de 451 Group, para designar una nueva generación de SGBD que buscan lo mejor de los dos mundos:

Del mundo relacional: SQL, modelo relacional y transacciones ACID.
Del mundo NoSQL: escalado horizontal y alta disponibilidad en clústeres de muchos nodos.

Sistema	Origen	Características
Google Spanner	Artículo de 2012; servicio Cloud Spanner desde 2017	Base de datos distribuida a escala planetaria con transacciones consistentes, apoyada en relojes sincronizados con GPS y relojes atómicos (API TrueTime)
CockroachDB	Cockroach Labs; versión 1.0 en 2017	Inspirada en Spanner; compatible con el protocolo de PostgreSQL; diseñada para sobrevivir a la caída de nodos o centros de datos enteros
YugabyteDB, TiDB	Proyectos de código abierto	Compatibles con PostgreSQL y MySQL respectivamente, distribuidos
VoltDB, SingleStore		Enfoque en memoria y alto rendimiento transaccional

💡 Consejo: Los SGBD relacionales clásicos también han evolucionado en esta dirección. Oracle, por ejemplo, ofrece Oracle Globally Distributed Database (antes llamada Oracle Sharding) para repartir una base de datos entre muchos servidores, y RAC (Real Application Clusters) para que varios servidores compartan la misma base de datos.

12. Bases de datos en la nube (DBaaS)

12.1. Concepto

📘 Concepto: Una base de datos como servicio (Database as a Service, DBaaS) es una base de datos que un proveedor de nube instala, mantiene, actualiza, respalda y escala por ti. El cliente solo se conecta y la usa, pagando por los recursos consumidos.

Tarea	Base de datos propia (on-premises)	DBaaS
Comprar y mantener el hardware	Cliente	Proveedor
Instalar y actualizar el SGBD	Cliente	Proveedor
Copias de seguridad	Cliente	Proveedor (automáticas)
Alta disponibilidad	Cliente	Proveedor (opción configurable)
Diseño del esquema, consultas, datos	Cliente	Cliente
Seguridad de los datos y de los accesos	Cliente	Compartida

12.2. Principales servicios

Servicio	Proveedor	Descripción
Amazon RDS	Amazon Web Services (desde 2009)	Bases de datos gestionadas: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2
Amazon Aurora	AWS (anunciado en 2014)	SGBD relacional propio de AWS, compatible con MySQL y PostgreSQL, con un almacenamiento distribuido diseñado para la nube
Azure SQL Database	Microsoft (lanzado como SQL Azure en 2010)	SQL Server gestionado en la nube
Google Cloud SQL, AlloyDB	Google	MySQL, PostgreSQL y SQL Server gestionados; AlloyDB es un servicio compatible con PostgreSQL
Oracle Autonomous Database	Oracle (desde 2018)	Base de datos “autónoma”: se configura, se ajusta, se parchea y se protege automáticamente con técnicas de aprendizaje automático. Variantes para transacciones, almacén de datos y JSON
Oracle Database@Azure / @AWS / @Google Cloud	Oracle con los otros proveedores	Servicios de Oracle Database ejecutados dentro de los centros de datos de otras nubes
MongoDB Atlas, Amazon DynamoDB, Azure Cosmos DB	Varios	Servicios NoSQL gestionados

💡 Consejo: Para practicar con Oracle sin instalar nada existe el servicio gratuito FreeSQL (freesql.com), y Oracle ofrece una capa gratuita (Always Free) en su nube con Autonomous Database. Lo verás en el módulo 22.

12.3. Serverless

Un paso más es la base de datos serverless (sin servidor): no se elige ni siquiera el tamaño de la máquina; la base de datos crece y decrece automáticamente según la carga (e incluso se “duerme” cuando no se usa), y se paga por operación o por segundo de uso. Ejemplos: Aurora Serverless, DynamoDB, Azure SQL Database serverless, Oracle Autonomous Database con autoescalado.

13. Otros tipos de bases de datos actuales

13.1. Bases de datos de series temporales

📘 Concepto: Una serie temporal es una secuencia de mediciones asociadas a instantes de tiempo (temperatura cada minuto, cotización de una acción cada segundo, consumo eléctrico cada hora). Las bases de datos de series temporales (Time Series Database, TSDB) están optimizadas para insertar enormes cantidades de puntos ordenados por tiempo, comprimirlos y agregarlos por intervalos.

Ejemplos: InfluxDB (2013), TimescaleDB (extensión de PostgreSQL), Prometheus (monitorización), QuestDB.
Casos de uso: IoT y sensores, monitorización de servidores y aplicaciones, datos financieros, telemetría.
Funciones típicas: agregación por ventanas de tiempo, políticas de retención (borrar automáticamente los datos de hace más de un año), downsampling (guardar medias horarias en lugar de datos por segundo).

# Formato de línea de InfluxDB (line protocol): medida,etiquetas campos marca_de_tiempo
temperatura,sensor=almacen1,ciudad=Zaragoza valor=21.4 1759572000000000000
temperatura,sensor=almacen1,ciudad=Zaragoza valor=21.7 1759572060000000000

13.2. Bases de datos en memoria

📘 Concepto: Una base de datos en memoria (In-Memory Database, IMDB) mantiene todos los datos (o los más importantes) en la RAM, eliminando la latencia de disco. Para garantizar la durabilidad, registra los cambios en un log persistente y hace volcados periódicos al disco, o replica los datos en otros nodos.

Ejemplos: Redis, SAP HANA, Oracle TimesTen, VoltDB, Memcached (solo caché, sin persistencia).
Opción in-memory en SGBD clásicos: Oracle Database In-Memory mantiene en RAM una copia columnar de las tablas elegidas para acelerar consultas analíticas, mientras los datos siguen guardándose en disco en formato de filas.
Casos de uso: cachés, analítica en tiempo real, trading, videojuegos, sistemas que requieren respuesta en microsegundos.

13.3. Data lakes y lakehouse

📘 Concepto: Un data lake (lago de datos) es un repositorio que almacena grandes volúmenes de datos en bruto, en su formato original (estructurados, semiestructurados y no estructurados), normalmente sobre almacenamiento de objetos barato (módulo 01). A diferencia del almacén de datos, el esquema no se impone al cargar los datos, sino al leerlos (esquema en lectura, schema-on-read).

El término lo acuñó James Dixon en 2010. Los data lakes resolvían el coste y la rigidez de los almacenes de datos, pero muchos degeneraron en “pantanos de datos” (data swamps): datos sin documentar, de calidad desconocida y difíciles de explotar.

El lakehouse, concepto propuesto por Databricks en 2020, combina ambos mundos: datos almacenados en ficheros abiertos sobre almacenamiento de objetos (como en un data lake), pero con una capa de tablas que aporta transacciones ACID, esquemas, versiones y rendimiento propio de un almacén de datos. Se apoya en formatos de tabla abiertos como Delta Lake, Apache Iceberg o Apache Hudi.

Característica	Almacén de datos	Data lake	Lakehouse
Datos	Estructurados y depurados	De cualquier tipo, en bruto	De cualquier tipo
Esquema	Al escribir (schema-on-write)	Al leer (schema-on-read)	Ambos, con esquemas gestionados
Almacenamiento	SGBD analítico	Objetos (barato)	Objetos + formato de tabla abierto
Transacciones ACID	Sí	No	Sí
Usuarios típicos	Analistas de negocio (BI)	Científicos e ingenieros de datos	Todos

13.4. Bases de datos vectoriales y la inteligencia artificial

Los modelos de inteligencia artificial pueden convertir un texto, una imagen o un sonido en un vector: una lista de cientos o miles de números que representa su significado. A estos vectores se les llama embeddings. La propiedad clave es que contenidos con significado parecido producen vectores cercanos.

"portátil ligero para viajar"      → [0.12, -0.48, 0.33, ..., 0.07]   (por ejemplo, 768 números)
"ultrabook de poco peso"           → [0.11, -0.45, 0.35, ..., 0.09]   ← muy cercano
"silla de oficina ergonómica"      → [-0.62, 0.20, -0.14, ..., 0.51]  ← lejano

📘 Concepto: Una base de datos vectorial almacena vectores y permite hacer búsquedas por similitud: “dame los 10 vectores más parecidos a este”. Para que sea rápido con millones de vectores, usa índices vectoriales de búsqueda aproximada de vecinos más cercanos (Approximate Nearest Neighbor, ANN), como HNSW o IVF.

Esto permite la búsqueda semántica: buscar por significado y no por palabras exactas. Una búsqueda de “ultrabook de poco peso” puede encontrar el producto “Portátil UltraBook 14 - Portátil ligero de 14 pulgadas” aunque no comparta casi ninguna palabra.

Su aplicación más extendida es la generación aumentada por recuperación (Retrieval-Augmented Generation, RAG): antes de que un modelo de lenguaje responda a una pregunta, se buscan en la base de datos vectorial los documentos más relevantes de la empresa y se le entregan como contexto, para que responda con información propia, actualizada y verificable.

flowchart LR
    U["Pregunta del<br/>usuario"] --> EMB["Modelo de<br/>embeddings"]
    EMB --> VDB[("Base de datos<br/>vectorial")]
    VDB -->|"documentos más<br/>parecidos"| LLM["Modelo de<br/>lenguaje (LLM)"]
    U --> LLM
    LLM --> R["Respuesta basada<br/>en datos propios"]

Tipo de solución	Ejemplos
Bases de datos vectoriales específicas	Pinecone, Milvus, Weaviate, Qdrant, Chroma
Extensiones de SGBD existentes	pgvector (PostgreSQL), búsqueda vectorial en MongoDB Atlas, Redis, Elasticsearch
SGBD con búsqueda vectorial integrada	Oracle AI Database 26ai (AI Vector Search), SQL Server, otros

Oracle y la búsqueda vectorial. Oracle Database 23ai (2024) introdujo AI Vector Search: un tipo de dato VECTOR, índices vectoriales y funciones SQL de distancia (VECTOR_DISTANCE) para combinar en una misma consulta la búsqueda semántica con filtros relacionales clásicos. Oracle AI Database 26ai, anunciada en octubre de 2025 como versión de soporte a largo plazo que sustituye a 23ai, amplía la integración de la IA en la base de datos.

💻 Ejemplo: Una consulta ilustrativa (Oracle 23ai/26ai) que combina búsqueda semántica y filtros relacionales: “los 5 productos no descatalogados más parecidos a lo que busca el cliente”.
-- Ejemplo ilustrativo: supone una columna "embedding" de tipo VECTOR
-- y un vector de la búsqueda ya calculado en :vector_busqueda
SELECT nombre, precio
FROM   productos
WHERE  descatalogado = 'N'
ORDER BY VECTOR_DISTANCE(embedding, :vector_busqueda, COSINE)
FETCH FIRST 5 ROWS ONLY;

⚠️ Importante: Disponible desde Oracle 23ai. En versiones anteriores (19c, 21c) no existe el tipo VECTOR y habría que recurrir a soluciones externas. Este curso no profundiza en la búsqueda vectorial, pero conviene que sepas que existe y que se maneja con SQL.

13.5. Bases de datos multimodelo

📘 Concepto: Una base de datos multimodelo admite varios modelos de datos (relacional, documental, grafos, clave-valor, espacial, vectorial…) en un mismo motor, con una gestión, seguridad y transacciones comunes.

En lugar de usar una base de datos distinta para cada tipo de dato (lo que se ha llamado persistencia políglota, con el coste de integrar y sincronizar muchos sistemas), una base de datos multimodelo permite elegir el modelo más adecuado para cada parte de la aplicación sin multiplicar las tecnologías.

Producto	Modelos que integra
Oracle AI Database (Oracle lo denomina base de datos “convergente”)	Relacional, JSON/documental, grafos, espacial, XML, texto, vectorial, blockchain…
Azure Cosmos DB	Documental, clave-valor, grafos, familias de columnas (a través de distintas API)
ArangoDB	Documental, grafos, clave-valor
PostgreSQL (con extensiones)	Relacional, JSON, espacial (PostGIS), vectorial (pgvector)…
Couchbase	Documental, clave-valor

14. Clasificación de las bases de datos

Las bases de datos se pueden clasificar según muchos criterios. Estos son los más habituales en los temarios.

14.1. Según el modelo de datos

Modelo	Estructura básica	Ejemplos
Jerárquico	Árboles de segmentos padre-hijo	IBM IMS
En red	Registros y conjuntos (grafo de punteros)	IDMS, IDS
Relacional	Tablas (relaciones)	Oracle, SQL Server, PostgreSQL, MySQL, Db2
Orientado a objetos	Objetos con identidad, herencia y métodos	ObjectStore, Versant, db4o
Objeto-relacional	Tablas + tipos definidos por el usuario	Oracle, PostgreSQL
Clave-valor	Pares clave → valor	Redis, DynamoDB
Documental	Documentos JSON/BSON/XML	MongoDB, Couchbase
Familias de columnas	Filas con columnas dinámicas	Cassandra, HBase
Grafos	Nodos y aristas con propiedades	Neo4j, Neptune
Series temporales	Puntos (tiempo, valor)	InfluxDB, TimescaleDB
Vectorial	Vectores (embeddings)	Pinecone, Milvus, Oracle AI Vector Search
Multimodelo	Varios de los anteriores	Oracle, Cosmos DB, ArangoDB

14.2. Según el número de usuarios

Tipo	Descripción	Ejemplos
Monousuario	Un solo usuario a la vez, normalmente en el mismo equipo	Una base de datos SQLite de una aplicación móvil, Microsoft Access en local
Multiusuario	Muchos usuarios simultáneos con control de concurrencia	Oracle, SQL Server, PostgreSQL en un servidor

14.3. Según la ubicación de los datos

Tipo	Descripción
Centralizada	Todos los datos residen en un único sistema (un servidor o un clúster en un solo centro)
Distribuida	Los datos están repartidos entre varios nodos conectados por red, que aparentan ser una única BD. Puede ser homogénea (todos los nodos usan el mismo SGBD) o heterogénea (SGBD distintos)
*Local (on-premises)*	En los servidores de la propia organización
En la nube	En la infraestructura de un proveedor, a menudo como servicio (DBaaS)
Híbrida	Parte en la organización y parte en la nube
Embebida	Integrada dentro de la propia aplicación, sin servidor independiente (SQLite)

14.4. Según el propósito o el uso

Tipo	Descripción	Ejemplos
Operacional / transaccional (OLTP)	Registra las operaciones diarias; muchas transacciones cortas	La BD de pedidos del esquema EMPRESA, la de un banco
Analítica (OLAP)	Analiza datos históricos; consultas masivas	Almacenes de datos, data marts
Híbrida (HTAP)	Transacciones y análisis en tiempo real sobre los mismos datos	Oracle con In-Memory, SingleStore, TiDB
De propósito general	Sirve para casi cualquier tipo de aplicación	Oracle, PostgreSQL, SQL Server
Especializada	Diseñada para un tipo de dato o tarea concretos	Series temporales, búsqueda de texto (Elasticsearch), espaciales, vectoriales

Según la variabilidad de los datos, también se distingue entre bases de datos estáticas (de solo lectura, como un almacén histórico o un catálogo publicado en un DVD) y dinámicas (que se modifican continuamente).

14.5. Según la licencia

Tipo	Descripción	Ejemplos
Propietaria (comercial)	El código no es público y su uso requiere una licencia de pago, aunque muchos fabricantes ofrecen ediciones gratuitas con limitaciones	Oracle Database (con la edición gratuita Free), Microsoft SQL Server (con ediciones Express y Developer), IBM Db2
Libre / código abierto	El código es público y se puede usar, estudiar, modificar y redistribuir según su licencia	PostgreSQL (licencia PostgreSQL), MariaDB (GPL), SQLite (dominio público), Cassandra (Apache 2.0)
Doble licencia / open core	Una versión libre y otra comercial con funciones adicionales o soporte	MySQL (Community con GPL y Enterprise comercial), Neo4j (Community y Enterprise)
Licencias de código disponible (source-available)	El código se puede ver, pero con restricciones (por ejemplo, prohibido ofrecerlo como servicio en la nube)	MongoDB (SSPL desde 2018); otros fabricantes han hecho cambios similares

💡 Consejo: Las licencias de las bases de datos cambian con el tiempo, a veces de forma polémica (por ejemplo, el cambio de licencia de Redis en 2024 dio lugar a la bifurcación libre Valkey). Antes de elegir un SGBD para un proyecto profesional, consulta siempre la licencia vigente y sus condiciones.

14.6. ¿Qué bases de datos se usan más?

El sitio web DB-Engines publica mensualmente una clasificación de popularidad de los SGBD, elaborada a partir de indicadores como menciones en webs, búsquedas, ofertas de empleo, preguntas en foros técnicos y perfiles profesionales. No mide instalaciones ni cuota de mercado, sino interés.

De forma general y estable a lo largo de los años, en los primeros puestos de esa clasificación aparecen Oracle, MySQL, Microsoft SQL Server y PostgreSQL (todas relacionales), seguidas de MongoDB como primera no relacional, y de otras como Redis, Snowflake, Elasticsearch, IBM Db2 o SQLite. La conclusión que se repite año tras año es clara: los SGBD relacionales siguen dominando, y los NoSQL ocupan sus nichos.

⚠️ Importante: Si necesitas cifras concretas (puntuaciones o posiciones), consulta directamente la clasificación vigente en db-engines.com: cambia cada mes.

15. ¿Cómo elegir el tipo de base de datos?

No hay una base de datos mejor para todo. Algunas preguntas que guían la elección:

Pregunta	Si la respuesta es…	Considera…
¿Los datos son estructurados, con muchas relaciones y reglas de integridad?	Sí	Relacional
¿Necesito transacciones ACID estrictas (dinero, stock, reservas)?	Sí	Relacional o NewSQL
¿Los datos tienen estructura variable y se leen como un bloque?	Sí	Documental (o columnas JSON en una relacional)
¿Solo necesito guardar y recuperar por clave, muy rápido?	Sí	Clave-valor
¿Hay escrituras masivas continuas y consultas conocidas de antemano?	Sí	Familias de columnas o series temporales
¿Lo importante son las conexiones entre elementos?	Sí	Grafos
¿Necesito buscar por significado (texto, imágenes)?	Sí	Vectorial o un SGBD con búsqueda vectorial
¿Necesito analizar años de histórico?	Sí	Almacén de datos o lakehouse
¿Varios de los anteriores a la vez?	Sí	Multimodelo o persistencia políglota

💡 Consejo: En caso de duda, empieza por una base de datos relacional: es la opción más versátil, madura y con más profesionales formados. Muchas de ellas (Oracle, PostgreSQL) ya incluyen JSON, grafos, texto y vectores, así que podrás cubrir casos especiales sin cambiar de tecnología.

16. Ejercicios

Ejercicios resueltos

Ejercicio 1: Ordenar la historia

Ordena cronológicamente los siguientes acontecimientos e indica el año aproximado de cada uno: (a) publicación del artículo de Bigtable, (b) lanzamiento de Oracle V2, (c) primer estándar SQL, (d) artículo de Codd, (e) IDS de Bachman, (f) primera versión de MySQL, (g) modelo E/R de Chen, (h) IMS/360, (i) Oracle 23ai con AI Vector Search, (j) se acuña el término NewSQL.

Ver solución

Orden	Acontecimiento	Año
1	(e) IDS de Bachman	1963-1964
2	(h) IMS/360	1969
3	(d) Artículo de Codd	1970
4	(g) Modelo E/R de Chen	1976
5	(b) Oracle V2	1979
6	(c) Primer estándar SQL	1986 (ANSI) / 1987 (ISO)
7	(f) MySQL	1995
8	(a) Bigtable	2006
9	(j) NewSQL	2011
10	(i) Oracle 23ai	2024

Ejercicio 2: Modelo jerárquico

Una universidad quiere representar en una base de datos jerárquica: FACULTAD, que tiene varios DEPARTAMENTOS; cada departamento tiene varios PROFESORES y varias ASIGNATURAS. Además, cada asignatura tiene varios ALUMNOS matriculados, y un alumno se matricula en varias asignaturas.

a) Dibuja el esquema jerárquico. b) ¿Qué problema aparece con los alumnos? Explica las dos soluciones posibles. c) Escribe la consulta “nombres de los profesores del departamento de Informática” en SQL, suponiendo las tablas relacionales equivalentes.

Ver solución

a) Esquema:

flowchart TB
    F["FACULTAD"] --> D["DEPARTAMENTO"]
    D --> P["PROFESOR"]
    D --> A["ASIGNATURA"]
    A --> AL["ALUMNO"]

b) La relación entre ASIGNATURA y ALUMNO es N:M: un alumno está matriculado en varias asignaturas, pero en un árbol cada segmento hijo solo puede tener un padre. Soluciones:

Duplicar el segmento ALUMNO bajo cada asignatura en la que está matriculado. Provoca redundancia (los datos del alumno se repiten) e inconsistencia (si cambia su dirección hay que actualizar todas las copias).
Crear un árbol aparte para ALUMNO y enlazarlo con ASIGNATURA mediante punteros lógicos (relaciones lógicas de IMS). Evita la redundancia, pero complica la estructura y la programación.

c) En SQL:

SELECT p.nombre
FROM   profesores p
       JOIN departamentos d ON d.dept_id = p.dept_id
WHERE  d.nombre = 'Informática';

En el modelo jerárquico habría que posicionarse en el segmento del departamento (con GU) y recorrer sus hijos PROFESOR (con GNP) uno a uno.

Ejercicio 3: Modelo en red

Usando el modelo CODASYL, representa: CLIENTE realiza PEDIDO (1:N), y un PEDIDO incluye varios PRODUCTOS, mientras que un producto aparece en muchos pedidos. Indica los tipos de registro, los tipos de conjunto (con propietario y miembro) y cómo resuelves la relación N:M.

Ver solución

Tipos de registro: CLIENTE, PEDIDO, PRODUCTO y un registro de enlace LINEA (con atributos propios, como la cantidad y el precio).
Tipos de conjunto:

Conjunto	Propietario	Miembro
CLI_PED	CLIENTE	PEDIDO
PED_LIN	PEDIDO	LINEA
PRO_LIN	PRODUCTO	LINEA

flowchart LR
    CLI["CLIENTE"] -->|"CLI_PED"| PED["PEDIDO"]
    PED -->|"PED_LIN"| LIN["LINEA<br/>(enlace)"]
    PRO["PRODUCTO"] -->|"PRO_LIN"| LIN

La relación N:M entre PEDIDO y PRODUCTO se resuelve con el registro de enlace LINEA, que es miembro de dos conjuntos: tiene como propietario un pedido (PED_LIN) y un producto (PRO_LIN). Es la misma solución que la tabla LINEAS_PEDIDO del esquema EMPRESA.

Ejercicio 4: ¿Qué tipo de base de datos?

Propón el tipo de base de datos más adecuado para cada caso y justifica la respuesta:

a) Las sesiones de los usuarios de una web con 5 millones de visitas diarias, que caducan a los 30 minutos. b) La contabilidad y la facturación de una empresa. c) Las lecturas de 20.000 contadores eléctricos inteligentes que envían su consumo cada 15 minutos. d) Una red profesional que quiere sugerir “personas que quizá conozcas”. e) El catálogo de una tienda que vende ropa, electrónica y libros, con atributos muy distintos en cada tipo de producto. f) Un buscador interno que permita a los empleados encontrar documentos de la empresa preguntando en lenguaje natural. g) El análisis de las ventas de los últimos diez años por región, producto y mes.

Ver solución

Caso	Tipo recomendado	Justificación
a) Sesiones	Clave-valor en memoria (Redis)	Acceso por clave (identificador de sesión), rapidísimo, con caducidad automática (TTL)
b) Contabilidad	Relacional	Datos estructurados, muchas relaciones, transacciones ACID e integridad estricta
c) Contadores	Series temporales (o familias de columnas)	Escrituras masivas ordenadas por tiempo, agregación por intervalos, retención
d) Sugerencias de contactos	Grafos	Consultas de relaciones a varios niveles (“amigos de mis amigos”)
e) Catálogo heterogéneo	Documental (o relacional con columnas JSON)	Cada producto tiene atributos distintos; esquema flexible
f) Buscador en lenguaje natural	Vectorial (o SGBD con búsqueda vectorial, como Oracle 26ai)	Búsqueda semántica por similitud de embeddings, base de un sistema RAG
g) Análisis histórico	Almacén de datos (OLAP), o lakehouse	Consultas masivas de agregación sobre datos históricos e integrados

Ejercicio 5: Teorema CAP

Una aplicación de reservas de un hotel tiene dos centros de datos, en Madrid y en Barcelona, que replican los datos entre sí. Se corta la conexión entre ambos durante 10 minutos. Mientras tanto, dos clientes intentan reservar la última habitación libre del 15 de agosto, uno desde cada centro.

a) ¿Qué ocurre si el sistema es AP? ¿Y si es CP? b) ¿Cuál elegirías para las reservas? ¿Y para la sección de opiniones de los clientes?

Ver solución

a) AP: ambos centros siguen aceptando peticiones; los dos clientes reservan la misma habitación y, al restablecerse la conexión, se detecta un conflicto (overbooking) que habrá que resolver (anular una reserva, ofrecer otra habitación…). CP: al menos uno de los centros (normalmente el que no tiene la mayoría o la “propiedad” del dato) rechaza la reserva o la deja en espera hasta que se restablezca la comunicación, garantizando que la habitación no se vende dos veces.

b) Para las reservas, CP: es preferible rechazar temporalmente una reserva a vender dos veces la misma habitación. Para las opiniones, AP: no pasa nada si una opinión tarda unos minutos en aparecer en el otro centro; es más importante que la web siga funcionando.

Ejercicio 6: OLTP u OLAP

Clasifica cada operación como OLTP u OLAP:

a) Registrar la venta de un billete de tren. b) Calcular el número medio de pasajeros por línea, mes y franja horaria de los últimos 5 años. c) Consultar el saldo de una cuenta en el cajero. d) Detectar qué productos se compran juntos con más frecuencia analizando todos los tickets del año. e) Actualizar la dirección de un cliente.

Ver solución

a) OLTP: transacción corta que inserta pocas filas.
b) OLAP: agregación masiva de datos históricos.
c) OLTP: consulta puntual de una fila, con datos actuales.
d) OLAP: análisis de grandes volúmenes (minería de datos).
e) OLTP: modificación puntual.

Ejercicio 7: El mismo dato en varios modelos

Representa en los modelos relacional, documental y de grafos la siguiente información de una red social: el usuario ana (nombre Ana García) sigue a los usuarios luis y marta; luis sigue a marta. Ana ha publicado el mensaje “Hola mundo” el 01/10/2026, al que marta ha dado “me gusta”.

Ver solución

Relacional:

USUARIOS (login, nombre)

SIGUE (*seguidor*, *seguido*)

seguidor → USUARIOS(login)
seguido → USUARIOS(login)

PUBLICACIONES (pub_id, autor, texto, fecha)

autor → USUARIOS(login)

ME_GUSTA (*login*, *pub_id*)

login → USUARIOS(login)
pub_id → PUBLICACIONES(pub_id)

SIGUE: (ana, luis), (ana, marta), (luis, marta)
PUBLICACIONES: (1, ana, 'Hola mundo', 01/10/2026)
ME_GUSTA: (marta, 1)

Documental (una colección de usuarios y otra de publicaciones):

{ "_id": "ana", "nombre": "Ana García", "sigue": ["luis", "marta"] }
{ "_id": "luis", "nombre": "Luis", "sigue": ["marta"] }
{ "_id": "marta", "nombre": "Marta", "sigue": [] }
{ "_id": 1, "autor": "ana", "texto": "Hola mundo", "fecha": "2026-10-01", "me_gusta": ["marta"] }

Grafos:

flowchart LR
    ANA["Usuario<br/>ana"] -->|SIGUE| LUIS["Usuario<br/>luis"]
    ANA -->|SIGUE| MARTA["Usuario<br/>marta"]
    LUIS -->|SIGUE| MARTA
    ANA -->|PUBLICA| P1["Publicación 1<br/>Hola mundo"]
    MARTA -->|ME_GUSTA| P1

Observa que en el modelo de grafos las relaciones son ciudadanas de primera clase, mientras que en el relacional se convierten en tablas (SIGUE, ME_GUSTA) y en el documental en listas de identificadores dentro de los documentos.

Ejercicios propuestos

Ejercicio 8: Línea temporal de Oracle

Elabora una línea temporal de Oracle Database desde 1977 hasta hoy, indicando para cada versión importante una novedad que se relacione con algún concepto de este módulo (relacional, objeto-relacional, distribuido, nube, multitenant, vectorial…).

Ejercicio 9: Comparativa de SGBD libres

Compara MySQL, MariaDB, PostgreSQL y SQLite en una tabla con estos criterios: origen, licencia actual, arquitectura (cliente/servidor o embebida), puntos fuertes, casos de uso típicos y una aplicación conocida que use cada uno. Consulta la documentación oficial de cada proyecto.

Ejercicio 10: Clasificación de bases de datos

Clasifica según los cinco criterios del apartado 14 (modelo, usuarios, ubicación, propósito y licencia) las bases de datos de: (a) la app de notas de tu móvil, (b) el sistema de reservas de una aerolínea, (c) el almacén de datos de una cadena de supermercados en Oracle Autonomous Data Warehouse, (d) un clúster de Cassandra que guarda los mensajes de una aplicación de chat.

Ejercicio 11: Informe sobre una tecnología actual

Elige una de estas tecnologías: lakehouse, bases de datos vectoriales o NewSQL. Redacta un informe de una página que explique qué problema resuelve, cómo funciona, dos productos que la implementen y un caso de uso real.

Resumen

Concepto	Idea clave
Ficheros (1950-1965)	Tarjetas perforadas, cinta, proceso por lotes; el disco (RAMAC, 1956) permite el acceso directo
Modelo jerárquico	Árboles padre-hijo (1:N); IMS de IBM para el programa Apolo (1968-1969); problemas con N:M
Modelo en red	Registros y conjuntos propietario-miembro; IDS de Bachman (1964), CODASYL DBTG (1969-1971), IDMS
Navegacional	Jerárquico y en red: el programador dice cómo llegar a los datos
Modelo relacional	Codd (1970): tablas, independencia de datos, lenguaje declarativo
System R / Ingres	Prototipos de los setenta; SEQUEL → SQL; QUEL
Oracle	SDL (1977) → RSI (1979, Oracle V2, primer SGBD SQL comercial) → Oracle Systems Corporation (1983)
Otros pioneros	DB2 (1983), Informix (1980), Sybase (1984), SQL Server (1989)
Estándar SQL	SQL-86, SQL-92, SQL:1999, SQL:2003… SQL:2023
Objetos	SGBDOO (ODMG) y objeto-relacionales (SQL:1999, Oracle8)
OLTP / OLAP	Transacciones cortas / análisis masivo de histórico
Almacén de datos	Orientado a temas, integrado, no volátil, variable en el tiempo; Inmon (top-down) y Kimball (estrella)
BD libres	MySQL (1995), PostgreSQL (1996), SQLite (2000), MariaDB (2009)
Teorema CAP	Ante una partición de red, elegir consistencia (CP) o disponibilidad (AP)
ACID / BASE	Corrección estricta / disponibilidad y consistencia eventual
NoSQL	Clave-valor (Redis), documental (MongoDB), familias de columnas (Cassandra, HBase), grafos (Neo4j)
NewSQL	SQL + ACID + escalado horizontal (Spanner, CockroachDB)
DBaaS	BD gestionada por el proveedor (RDS, Aurora, Azure SQL, Oracle Autonomous Database)
Especializadas	Series temporales (InfluxDB), en memoria (Redis, HANA, Oracle In-Memory)
**Data lake / lakehouse**	Datos en bruto sobre objetos / lago con tablas ACID (Delta Lake, Iceberg)
Vectorial	Embeddings, búsqueda semántica, RAG; Oracle AI Vector Search (23ai, 26ai)
Multimodelo	Varios modelos en un solo motor (Oracle, Cosmos DB, ArangoDB)
Clasificación	Por modelo, número de usuarios, ubicación, propósito (OLTP/OLAP/HTAP) y licencia

Navegación
← Módulo anterior: Sistemas de almacenamiento	Siguiente módulo: Sistemas gestores de bases de datos →