Tema 10. Bases de datos no relacionales y especiales

Índice

1. Limitaciones del modelo relacional y origen de NoSQL
2. Teorema CAP y BASE vs ACID
3. Clasificación de bases de datos NoSQL
4. Bases de datos clave-valor
5. Bases de datos documentales
6. Bases de datos columnares (Wide Column)
7. Bases de datos orientadas a grafos
8. Otras tipologías especiales
9. Data Warehouse y sistemas OLAP
10. MDX: consultas a cubos OLAP
11. Minería de datos y Big Data
12. Comparativa general y elección de modelo
13. Resumen esquemático y preguntas tipo test

1. Limitaciones del modelo relacional y origen de NoSQL

1.1 El modelo relacional y sus limitaciones

El modelo relacional, propuesto por Edgar F. Codd en 1970, ha sido el paradigma dominante en la gestión de datos durante décadas. Se basa en tablas con filas y columnas, relaciones mediante claves ajenas y el lenguaje SQL para consultas.

Sin embargo, a partir de los años 2000, con la explosión de Internet y las aplicaciones web a gran escala, surgieron necesidades que el modelo relacional no podía satisfacer eficientemente:

1.2 El movimiento NoSQL

El término NoSQL (Not Only SQL) fue popularizado en 2009, aunque los sistemas que describe existían desde antes. No significa "sin SQL", sino que engloba sistemas que no siguen el modelo relacional estricto.

Principales impulsores del desarrollo NoSQL:

• Google desarrolló Bigtable (2004), base de los sistemas columnares.
• Amazon desarrolló Dynamo (2007), base de los sistemas clave-valor distribuidos.
• Facebook desarrolló Cassandra (liberada en 2008), fusión de ideas de Bigtable y Dynamo.
• LinkedIn creó Voldemort, otra base de datos clave-valor.

1.3 Características generales de los sistemas NoSQL

• Esquema flexible o sin esquema (schema-less o schema-on-read).
• Escalabilidad horizontal (scale-out): diseñados para distribuirse en múltiples nodos.
• Alta disponibilidad: tolerancia a fallos mediante replicación.
• Modelos de consistencia relajados: en general sacrifican consistencia fuerte por disponibilidad y rendimiento (BASE en lugar de ACID).
• Optimizados para casos de uso específicos: cada tipo de NoSQL destaca en un patrón de acceso concreto.

2. Teorema CAP y BASE vs ACID

2.1 Propiedades ACID (bases de datos relacionales)

Las transacciones en bases de datos relacionales cumplen las propiedades ACID:

2.2 Teorema CAP (Brewer, 2000)

El teorema CAP, enunciado por Eric Brewer en 2000 y demostrado formalmente por Gilbert y Lynch en 2002, establece que un sistema distribuido solo puede garantizar dos de las tres propiedades siguientes de forma simultánea:

         Consistencia (C)
              /\
             /  \
            /    \
           /  CA  \
          /        \
         /----+-----\
        /  CP | AP   \
       /      |       \
      +--------+--------+
  Disponibilidad (A)   Tolerancia a
                       particiones (P)

Clasificación de sistemas según CAP:

Nota: En la práctica, todo sistema distribuido debe tolerar particiones (P), por lo que la decisión real es entre CP (prioriza consistencia) y AP (prioriza disponibilidad).

2.3 Consistencia eventual

Muchos sistemas NoSQL ofrecen consistencia eventual (eventual consistency): el sistema garantiza que, si no se realizan nuevas escrituras, eventualmente todos los nodos convergerán al mismo valor. No garantiza cuándo ocurrirá esta convergencia.

2.4 Propiedades BASE (alternativa a ACID en NoSQL)

Frente a ACID, los sistemas NoSQL suelen seguir el modelo BASE:

3. Clasificación de bases de datos NoSQL

Las bases de datos NoSQL se clasifican principalmente según su modelo de datos:

                    BASES DE DATOS NoSQL
                           |
          +----------------+----------------+
          |                |                |
    CLAVE-VALOR      DOCUMENTALES      COLUMNARES
    (Key-Value)      (Document)       (Wide-Column)
    Redis, Dynamo    MongoDB,          Cassandra,
    Memcached,       CouchDB,          HBase,
    Riak             Elasticsearch     BigTable

          +----------------+----------------+
          |                |                |
      GRAFOS          SERIES          BÚSQUEDA
     (Graph)         TEMPORALES       (Search)
     Neo4j,          InfluxDB,        Elasticsearch,
     ArangoDB,       TimescaleDB,     Solr
     Amazon Neptune  Prometheus

4. Bases de datos clave-valor

4.1 Concepto

Las bases de datos clave-valor (key-value stores) son el tipo más simple de NoSQL. Almacenan datos como pares clave → valor, donde:

• La clave es un identificador único (string).
• El valor puede ser cualquier cosa: un string, un número, un JSON, un blob binario, una lista, un conjunto, etc.

El acceso se realiza siempre por clave. No existe lenguaje de consulta para buscar por el contenido del valor (salvo extensiones específicas de cada producto).

4.2 Redis

Redis (Remote Dictionary Server) es el sistema clave-valor más popular. Fue creado por Salvatore Sanfilippo en 2009.

Características principales

• Almacenamiento en memoria (in-memory): todos los datos residen en RAM, lo que lo hace extremadamente rápido (latencias de microsegundos).
• Persistencia opcional: puede persistir datos en disco mediante RDB (snapshots) o AOF (Append Only File).
• Estructuras de datos ricas: no solo almacena strings simples, sino también:

• Replicación maestro-réplica.
• Redis Cluster: particionamiento automático de datos entre nodos.
• Redis Sentinel: alta disponibilidad y monitorización.
• Pub/Sub: mensajería publicador-suscriptor.
• Lua scripting: ejecución de scripts atómicos.
• Transacciones mediante MULTI/EXEC.
• TTL (Time To Live): expiración automática de claves.

Casos de uso típicos de Redis

• Caché: almacenamiento temporal de resultados de consultas costosas.
• Gestión de sesiones: almacenamiento de sesiones de usuario en aplicaciones web.
• Colas de mensajes: implementación de colas FIFO o de prioridad.
• Rankings en tiempo real: tablas de clasificación con Sorted Sets.
• Contadores y estadísticas en tiempo real.
• Rate limiting: control de tasa de peticiones.
• Caché de páginas web.

Limitaciones de Redis

• El tamaño del dataset está limitado por la RAM disponible.
• No es adecuado para datos que requieran consultas complejas o relaciones.
• La persistencia en disco añade latencia si se activa con alta consistencia.

4.3 Amazon DynamoDB

DynamoDB es el servicio de base de datos clave-valor (y documental) gestionado de Amazon Web Services. Se basa en los principios del paper de Amazon Dynamo (2007).

• Totalmente gestionado: sin administración de servidores.
• Escalabilidad automática: ajusta capacidad según la demanda.
• Rendimiento predecible con baja latencia (milisegundos de un dígito).
• Modelo AP (disponibilidad + tolerancia a particiones).
• DynamoDB Streams: captura cambios en los datos en tiempo real.
• Usado extensamente en aplicaciones serverless con AWS Lambda.

4.4 Memcached

Memcached es un sistema de caché en memoria distribuida, más simple que Redis:

• Solo almacena strings simples (no estructuras de datos ricas).
• No tiene persistencia.
• Escalado horizontal sencillo.
• Orientado exclusivamente a caché de objetos.
• No tiene soporte nativo de clustering como Redis.

4.5 Riak

Riak es una base de datos clave-valor distribuida de tipo AP (disponibilidad + tolerancia a particiones):

• Basada en los principios del paper de Dynamo de Amazon.
• Alta disponibilidad como objetivo principal.
• Usa consistent hashing para distribuir datos.
• Soporte de CRDTs (Conflict-free Replicated Data Types) para resolver conflictos de forma automática.

5. Bases de datos documentales

5.1 Concepto

Las bases de datos documentales almacenan datos como documentos, generalmente en formato JSON (JavaScript Object Notation) o BSON (Binary JSON). Cada documento es una unidad autónoma que puede contener estructuras anidadas, arrays y campos de distintos tipos.

A diferencia de las tablas relacionales, los documentos de una misma colección no necesitan tener el mismo esquema.

5.2 Modelo de datos

{
  "_id": "5f3a2b1c4d5e6f7a8b9c0d1e",
  "nombre": "María García",
  "edad": 34,
  "direccion": {
    "calle": "Calle Mayor, 15",
    "ciudad": "Madrid",
    "cp": "28013"
  },
  "telefonos": ["612345678", "913456789"],
  "activo": true,
  "fechaAlta": "2023-01-15T10:30:00Z"
}

Características del modelo documental:
- Documentos anidados: evitan JOINs almacenando datos relacionados juntos.
- Arrays: permiten almacenar listas de valores o subdocumentos.
- Esquema dinámico: cada documento puede tener campos diferentes.
- Identificador único: cada documento tiene un _id que actúa como clave primaria.

5.3 MongoDB

MongoDB es la base de datos documental más utilizada del mundo. Fue creada por 10gen (ahora MongoDB Inc.) en 2009.

Conceptos equivalentes MongoDB vs SQL

Características de MongoDB

• BSON: almacena documentos en formato binario JSON (Binary JSON), que soporta más tipos de datos que JSON puro (fechas, datos binarios, ObjectId, etc.).
• Consultas ad hoc: permite consultar por cualquier campo, incluso anidados.
• Índices: secundarios, compuestos, geoespaciales, de texto, TTL.
• Aggregation Pipeline: framework potente para transformar y agregar datos mediante etapas encadenadas ($match, $group, $sort, $project, $lookup, etc.).
• Replicación: Replica Set (conjunto de réplicas con elección automática de primario).
• Sharding: particionamiento horizontal de datos entre múltiples servidores.
• Transacciones ACID multi-documento: desde la versión 4.0 (2018), MongoDB soporta transacciones multi-documento con garantías ACID, aunque con coste de rendimiento.
• GridFS: sistema para almacenar ficheros grandes (>16 MB) divididos en chunks.
• Change Streams: escuchar cambios en colecciones en tiempo real.

Consultas básicas en MongoDB

// Insertar un documento
db.usuarios.insertOne({ nombre: "Ana", edad: 28, ciudad: "Madrid" })

// Buscar documentos
db.usuarios.find({ ciudad: "Madrid", edad: { $gt: 25 } })

// Actualizar
db.usuarios.updateOne({ nombre: "Ana" }, { $set: { edad: 29 } })

// Eliminar
db.usuarios.deleteOne({ nombre: "Ana" })

// Aggregation Pipeline
db.pedidos.aggregate([
  { $match: { estado: "completado" } },
  { $group: { _id: "$clienteId", total: { $sum: "$importe" } } },
  { $sort: { total: -1 } }
])

Casos de uso de MongoDB

• Catálogos de productos con atributos variables (e-commerce).
• Gestión de contenidos (CMS).
• Aplicaciones móviles con datos flexibles.
• IoT: almacenamiento de datos de sensores.
• Perfiles de usuario con atributos heterogéneos.
• Logging y análisis de eventos.

Limitaciones de MongoDB

• Las transacciones multi-documento tienen mayor coste que en sistemas relacionales.
• No es adecuado para datos con relaciones muy complejas (grafos).
• El esquema flexible puede llevar a inconsistencias si no se gestiona correctamente.

5.4 CouchDB

Apache CouchDB es otra base de datos documental relevante:

• Almacena documentos JSON.
• Usa MapReduce para consultas y vistas.
• API RESTful nativa: toda interacción se hace mediante HTTP.
• Control de versiones de documentos (MVCC — Multi-Version Concurrency Control).
• Diseñada para sincronización offline-first: ideal para aplicaciones móviles que deben funcionar sin conexión.
• PouchDB es su equivalente para el navegador, compatible con sincronización bidireccional con CouchDB.

5.5 Elasticsearch

Elasticsearch es una base de datos documental especializada en búsqueda y análisis de texto (aunque también se usa para análisis de logs y métricas):

• Basado en Apache Lucene.
• Almacena documentos JSON.
• Motor de búsqueda de texto completo (full-text search) con relevancia.
• Análisis en tiempo real de grandes volúmenes de datos.
• Distributed by default: escala horizontalmente de forma nativa.
• Parte del stack ELK (Elasticsearch + Logstash + Kibana), ampliamente usado para análisis de logs.
• Aggregations: análisis estadísticos complejos sobre los datos indexados.

6. Bases de datos columnares (Wide Column)

6.1 Concepto

Las bases de datos columnares o de columna ancha (Wide Column Stores) almacenan datos por columnas en lugar de por filas. Existen dos variantes:

a) Almacenamiento por columnas (Column-oriented):
Los datos de cada columna se almacenan juntos en disco. Esto mejora el rendimiento en consultas analíticas que acceden solo a determinadas columnas de muchas filas.

b) Familia de columnas (Column-family / Wide Column):
Inspiradas en Google Bigtable, organizan los datos en familias de columnas. Cada fila puede tener un conjunto diferente de columnas dentro de cada familia.

6.2 Diferencia entre almacenamiento por filas y por columnas

Almacenamiento por filas (row-oriented) — típico en OLTP:

Fila 1: [1, "Ana", 28, "Madrid"]
Fila 2: [2, "Luis", 35, "Barcelona"]
Fila 3: [3, "Eva", 42, "Sevilla"]

Almacenamiento por columnas (column-oriented) — típico en OLAP:

ID:     [1, 2, 3]
Nombre: ["Ana", "Luis", "Eva"]
Edad:   [28, 35, 42]
Ciudad: ["Madrid", "Barcelona", "Sevilla"]

6.3 Apache Cassandra

Apache Cassandra fue desarrollada originalmente por Facebook para gestionar la bandeja de entrada de mensajes. Fue liberada como open source en 2008 y donada a la Apache Software Foundation.

Características de Cassandra

• Modelo AP: prioriza disponibilidad y tolerancia a particiones sobre consistencia.
• Arquitectura sin maestro (masterless / peer-to-peer): todos los nodos son iguales. No hay punto único de fallo.
• Consistent hashing + Virtual Nodes (vnodes): distribución de datos entre nodos.
• Replicación configurable: factor de replicación y estrategia de colocación (SimpleStrategy, NetworkTopologyStrategy).
• Consistencia ajustable por operación: ONE, QUORUM, ALL, LOCAL_QUORUM, etc.
• CQL (Cassandra Query Language): lenguaje de consulta similar a SQL.
• Diseño orientado a las consultas: el modelo de datos se diseña en función de los patrones de acceso, no de la normalización.
• Optimizada para escrituras masivas a alta velocidad.
• Escalabilidad lineal: añadir nodos aumenta proporcionalmente la capacidad y el rendimiento.

Modelo de datos de Cassandra

• Keyspace: equivalente a la base de datos.
• Table: similar a una tabla SQL, pero con clave compuesta.
• Partition Key: determina en qué nodo se almacena la fila.
• Clustering Key: ordena los datos dentro de una partición.
• Wide rows: una partición puede contener miles de filas ordenadas.

-- Ejemplo de tabla en CQL
CREATE TABLE mensajes (
  usuario_id UUID,
  fecha TIMESTAMP,
  mensaje TEXT,
  PRIMARY KEY (usuario_id, fecha)
) WITH CLUSTERING ORDER BY (fecha DESC);

Casos de uso de Cassandra

• Mensajería a gran escala (WhatsApp, Discord).
• Series temporales (métricas, logs de eventos).
• IoT: ingesta masiva de datos de sensores.
• Recomendaciones en tiempo real.
• Catálogos de productos a gran escala.

6.4 Apache HBase

Apache HBase es una base de datos columnar distribuida basada en el modelo de Google Bigtable, construida sobre Apache Hadoop HDFS.

• Modelo CP: prioriza consistencia sobre disponibilidad.
• Diseñada para almacenar grandes cantidades de datos dispersos (sparse data).
• Acceso aleatorio a datos en grandes conjuntos (petabytes).
• Integración nativa con el ecosistema Hadoop (MapReduce, Spark, Hive).
• Compactación periódica de datos para optimizar el almacenamiento.

6.5 Google Bigtable

Google Bigtable (2004, paper publicado en 2006) es el origen conceptual de los sistemas de familia de columnas. Es un sistema de almacenamiento distribuido para datos estructurados a escala masiva.

• Usado internamente por Google para Search, Maps, Gmail.
• Disponible como servicio gestionado en Google Cloud Bigtable.
• Influyó en el diseño de HBase y Cassandra.

6.6 Bases de datos columnar analíticas (OLAP)

Para análisis de datos (OLAP), existen sistemas columnar específicos:

7. Bases de datos orientadas a grafos

7.1 Concepto y teoría de grafos

Una base de datos orientada a grafos almacena datos como un grafo: una estructura matemática compuesta por:

• Nodos (vértices): entidades (personas, productos, páginas web, etc.).
• Aristas (relaciones): conexiones entre nodos, siempre con una dirección y un tipo.
• Propiedades: atributos asociados tanto a nodos como a aristas.

El modelo de grafo es especialmente eficiente para datos con relaciones complejas y profundas, donde las consultas de tipo "traversal" (recorrido del grafo) serían prohibitivamente lentas en una base de datos relacional.

7.2 Comparativa: consulta relacional vs grafo

Escenario: encontrar los amigos de los amigos de un usuario (2 saltos).

En SQL (modelo relacional):

SELECT DISTINCT f2.amigo_id
FROM amistades f1
JOIN amistades f2 ON f1.amigo_id = f2.usuario_id
WHERE f1.usuario_id = 1
AND f2.amigo_id != 1;

En Neo4j (Cypher):

MATCH (u:Usuario {id: 1})-[:AMIGO*2]->(amigo)
RETURN DISTINCT amigo

7.3 Neo4j

Neo4j es la base de datos orientada a grafos más utilizada del mundo. Fue desarrollada por Neo Technology (ahora Neo4j Inc.) y lanzada en 2007.

Modelo de datos de Neo4j: Property Graph Model

• Nodos: entidades con etiquetas (labels) y propiedades.
• Relaciones: conexiones dirigidas entre nodos, con tipo y propiedades.
• Etiquetas: clasifican los nodos (similar a una clase).
• Propiedades: pares clave-valor en nodos y relaciones.

(persona:Persona {nombre: "Ana", edad: 28})
    -[:TRABAJA_EN {desde: 2020}]->
(empresa:Empresa {nombre: "Ayuntamiento de Madrid"})

Lenguaje Cypher

Cypher es el lenguaje de consulta declarativo de Neo4j, diseñado para ser intuitivo mediante patrones ASCII:

-- Crear un nodo
CREATE (p:Persona {nombre: "Ana", edad: 28})

-- Crear una relación
MATCH (a:Persona {nombre: "Ana"}), (b:Persona {nombre: "Luis"})
CREATE (a)-[:CONOCE {desde: 2020}]->(b)

-- Consultar amigos de amigos
MATCH (yo:Persona {nombre: "Ana"})-[:CONOCE*2]->(posibleAmigo)
WHERE NOT (yo)-[:CONOCE]->(posibleAmigo)
RETURN posibleAmigo.nombre

-- Encontrar el camino más corto
MATCH path = shortestPath(
  (a:Persona {nombre: "Ana"})-[:CONOCE*]-(b:Persona {nombre: "Eva"})
)
RETURN path

Algoritmos de grafos en Neo4j

Neo4j Graph Data Science (GDS) incluye algoritmos de:

• Caminos más cortos: Dijkstra, A*, BFS, DFS.
• Centralidad: PageRank, Betweenness Centrality, Degree Centrality.
• Detección de comunidades: Louvain, Label Propagation.
• Similaridad: Node Similarity, KNN.
• Detección de ciclos.

Casos de uso de Neo4j y bases de datos de grafos

7.4 Otros sistemas de bases de datos de grafos

7.5 RDF y grafos semánticos

Además del Property Graph Model, existe el modelo RDF (Resource Description Framework):

• Estándar del W3C para representar datos en la web semántica.
• Los datos se representan como tripletas: Sujeto → Predicado → Objeto.
• Lenguaje de consulta: SPARQL.
• Bases de datos RDF: Amazon Neptune, Stardog, Apache Jena.
• Usado en ontologías, linked data y web semántica.

8. Otras tipologías especiales

8.1 Bases de datos de series temporales (Time Series)

Las bases de datos de series temporales están optimizadas para almacenar y consultar datos indexados por tiempo (timestamp).

Características:
- Ingesta masiva de datos con marca temporal.
- Consultas eficientes sobre rangos temporales.
- Funciones de agregación temporal (downsampling, rollup).
- Políticas de retención y expiración automática de datos.
- Compresión eficiente de datos temporales (los datos cambian poco entre muestras consecutivas).

Casos de uso:
- Métricas de infraestructura y aplicaciones (CPU, memoria, red).
- Datos de sensores IoT.
- Datos financieros (precios de acciones, transacciones).
- Monitorización de sistemas industriales (SCADA).

8.2 Bases de datos de búsqueda (Search Engines)

8.3 Bases de datos en memoria (In-Memory)

8.4 Bases de datos geoespaciales

Optimizadas para almacenar y consultar datos con componente geográfica.

• PostGIS: extensión geoespacial de PostgreSQL; el estándar de facto para datos geoespaciales en open source.
• MongoDB: soporte nativo de índices geoespaciales 2D y 2dsphere.
• Elasticsearch: soporte de consultas geoespaciales.
• SpatiaLite: extensión geoespacial de SQLite.
• Oracle Spatial: módulo geoespacial de Oracle.

Operaciones típicas: buscar puntos dentro de un radio, calcular distancias, intersección de polígonos, operaciones topológicas.

8.5 Bases de datos multi-modelo

Algunos sistemas modernos soportan múltiples modelos en un único motor:

8.6 Bases de datos orientadas a objetos

Almacenan objetos directamente, tal como se representan en un lenguaje orientado a objetos, sin necesidad de mapeo objeto-relacional (ORM).

• db4o: base de datos orientada a objetos Java/.NET.
• ObjectDB: base de datos orientada a objetos para Java con soporte JPA.
• Actualmente en desuso relativo frente a los ORMs sobre BBDD relacionales.

8.7 NewSQL: lo mejor de ambos mundos

Las bases de datos NewSQL son sistemas relacionales diseñados para escalar horizontalmente como NoSQL, manteniendo las garantías ACID.

9. Data Warehouse y sistemas OLAP

9.1 Concepto de Data Warehouse

Un Data Warehouse (almacén de datos) es un repositorio centralizado de datos integrados, históricos y organizados para el análisis y la toma de decisiones. Fue definido por Bill Inmon en 1992.

Definición de Bill Inmon: "Un Data Warehouse es una colección de datos orientada a temas, integrada, variable en el tiempo y no volátil, que se usa para el apoyo al proceso de toma de decisiones."

9.2 Las cuatro características de Inmon (OIVN)

9.3 OLTP vs OLAP

9.4 Arquitectura de un Data Warehouse

FUENTES DE DATOS          ETL / ELT              DW / DL           CONSUMO
+---------------+    +---------------+    +---------------+    +----------+
| Sistemas ERP  | →  |   Extract     | →  | Data Warehouse| →  | Informes |
| CRM           |    |   Transform   |    | (Star/Snowfl) |    | Dashboards|
| Ficheros CSV  |    |   Load        |    +-------+-------+    | OLAP     |
| APIs externas |    +---------------+            |            | ML / IA  |
| BBDD legadas  |                          +------+------+     +----------+
+---------------+                          | Data Marts  |
                                           +-------------+

9.5 Proceso ETL

El proceso ETL (Extract, Transform, Load) es el responsable de mover datos desde los sistemas fuente al Data Warehouse:

ELT (Extract, Load, Transform) es una variante moderna donde los datos se cargan primero en el DW (o Data Lake) y la transformación se realiza dentro del propio sistema, aprovechando su potencia de cómputo (Big Data, cloud DW).

9.6 Modelado dimensional: esquema estrella y copo de nieve

El modelado dimensional fue desarrollado por Ralph Kimball como alternativa al enfoque de Inmon.

Esquema estrella (Star Schema)

                    +---------------+
                    | DIM_TIEMPO    |
                    | id_tiempo     |
                    | año, mes, día |
                    +-------+-------+
                            |
+------------+    +---------+--------+    +---------------+
| DIM_CLIENTE|    |                  |    | DIM_PRODUCTO  |
| id_cliente | →  | TABLA DE HECHOS  | ←  | id_producto   |
| nombre     |    | VENTAS           |    | nombre        |
| ciudad     |    |                  |    | categoria     |
+------------+    | id_cliente (FK)  |    +---------------+
                  | id_producto (FK) |
                  | id_tiempo (FK)   |    +---------------+
                  | id_tienda (FK)   | ←  | DIM_TIENDA    |
                  | importe          |    | id_tienda     |
                  | unidades         |    | ciudad, pais  |
                  +------------------+    +---------------+

• Tabla de hechos (Fact Table): contiene las métricas cuantitativas (importes, unidades vendidas, conteos) y las claves foráneas a las dimensiones.
• Tablas de dimensión (Dimension Tables): contienen los atributos descriptivos (nombres, categorías, fechas completas).
• Ventajas: simple, fácil de entender, rendimiento óptimo en consultas OLAP.
• Desventaja: cierta redundancia en las tablas de dimensión (datos desnormalizados).

Esquema copo de nieve (Snowflake Schema)

Es una extensión del esquema estrella donde las tablas de dimensión están normalizadas, creando subdimensiones:

DIM_TIENDA → DIM_CIUDAD → DIM_PAIS
DIM_PRODUCTO → DIM_SUBCATEGORIA → DIM_CATEGORIA

• Ventaja: menor redundancia, menor espacio de almacenamiento.
• Desventaja: consultas más complejas, mayor número de JOINs, menor rendimiento.

9.7 Tabla de hechos: tipos de métricas

9.8 Data Mart

Un Data Mart es un subconjunto del Data Warehouse orientado a un departamento o área de negocio específica (ventas, finanzas, RRHH).

• Data Mart dependiente: se alimenta del Data Warehouse central.
• Data Mart independiente: se alimenta directamente de los sistemas fuente.
• Es más pequeño, más rápido de implementar y más fácil de gestionar que un DW completo.

9.9 Data Lake

Un Data Lake es un repositorio que almacena datos en su formato nativo (sin transformar), incluyendo datos estructurados, semiestructurados y no estructurados.

Data Lakehouse: arquitectura híbrida que combina la flexibilidad del Data Lake con las capacidades analíticas del Data Warehouse (Delta Lake, Apache Iceberg, Apache Hudi).

9.10 Slowly Changing Dimensions (SCD)

Las Dimensiones de Cambio Lento gestionan cómo se actualiza una tabla de dimensión cuando sus atributos cambian con el tiempo. Existen varios tipos:

10. MDX: consultas a cubos OLAP

10.1 Concepto de cubo OLAP

Un cubo OLAP (Online Analytical Processing) es una estructura de datos multidimensional que organiza la información en:

• Dimensiones: ejes del cubo (tiempo, producto, geografía, cliente).
• Medidas (measures): valores numéricos que se analizan (ventas, costes, unidades).
• Jerarquías: niveles dentro de una dimensión (Año → Trimestre → Mes → Día).
• Miembros: valores concretos dentro de una dimensión (2023, Q1, Enero).
• Celdas: intersección de dimensiones que contiene el valor de una medida.

Operaciones OLAP fundamentales

Tipos de sistemas OLAP

10.2 MDX: MultiDimensional eXpressions

MDX (MultiDimensional eXpressions) es el lenguaje estándar de consulta para bases de datos multidimensionales (cubos OLAP). Fue desarrollado originalmente por Microsoft para SQL Server Analysis Services (SSAS) y adoptado como estándar de facto.

Estructura básica de una consulta MDX

SELECT
  <eje_columnas> ON COLUMNS,
  <eje_filas> ON ROWS
FROM <cubo>
[WHERE <slicer>]

Elementos de MDX

Ejemplos de consultas MDX

-- Ejemplo 1: Ventas por año en columnas, por producto en filas
SELECT
  {[Tiempo].[2022], [Tiempo].[2023]} ON COLUMNS,
  {[Producto].[Laptop], [Producto].[Tablet], [Producto].[Móvil]} ON ROWS
FROM [Ventas]
WHERE ([Measures].[Importe_Ventas])

-- Ejemplo 2: Total de ventas del año actual vs año anterior
SELECT
  { [Measures].[Ventas], 
    [Measures].[Ventas] } ON COLUMNS,
  [Tiempo].[Año].Members ON ROWS
FROM [Ventas]

-- Ejemplo 3: Top 10 productos por ventas
SELECT
  [Measures].[Importe_Ventas] ON COLUMNS,
  TopCount(
    [Producto].[Producto].Members,
    10,
    [Measures].[Importe_Ventas]
  ) ON ROWS
FROM [Ventas]

Funciones MDX importantes

10.3 Herramientas OLAP que usan MDX

11. Minería de datos y Big Data

11.1 Minería de datos

La minería de datos (data mining) es el proceso de descubrir patrones, correlaciones y conocimiento útil en grandes conjuntos de datos mediante técnicas estadísticas y de machine learning.

Metodología CRISP-DM (6 fases)

CRISP-DM (Cross-Industry Standard Process for Data Mining) es la metodología estándar para proyectos de minería de datos:

1. Comprensión del negocio (Business Understanding)
        ↓
2. Comprensión de los datos (Data Understanding)
        ↓
3. Preparación de los datos (Data Preparation)  ←──┐
        ↓                                           |
4. Modelado (Modeling)  ───────────────────────────┘
        ↓
5. Evaluación (Evaluation)
        ↓
6. Despliegue (Deployment)

11.2 Técnicas de minería de datos

Aprendizaje supervisado (datos etiquetados)

Aprendizaje no supervisado (sin etiquetas)

Aprendizaje por refuerzo

El agente aprende por interacción con el entorno, maximizando una recompensa. Usado en robótica, juegos (AlphaGo), sistemas de recomendación.

11.3 PCA (Análisis de Componentes Principales)

El PCA (Principal Component Analysis) es una técnica de reducción de dimensionalidad:

• Transforma un conjunto de variables correlacionadas en un nuevo conjunto de variables ortogonales (no correlacionadas) llamadas componentes principales.
• Los componentes se ordenan por la varianza explicada (el primero explica la mayor varianza).
• Permite reducir el número de dimensiones manteniendo la mayor parte de la información.

Ejemplo del examen: dado un conjunto de 100.000 observaciones con 100 dimensiones, PCA se usa para obtener las mismas 100.000 observaciones pero con un número de dimensiones inferior a 100 (no reduce el número de observaciones, sino las dimensiones/características).

11.4 Big Data: las 5 Vs

El concepto Big Data se caracteriza por las 5 Vs:

11.5 Ecosistema Hadoop

Apache Hadoop es el framework open source de referencia para procesamiento de Big Data:

11.6 Apache Spark

Apache Spark es el sustituto moderno de MapReduce para procesamiento de datos distribuido:

• Procesamiento en memoria (hasta 100x más rápido que MapReduce para ciertos casos).
• Soporte de batch y streaming (Spark Structured Streaming).
• Módulos: Spark SQL, MLlib (machine learning), GraphX (grafos), Spark Streaming.
• APIs en Python (PySpark), Scala, Java, R.

12. Comparativa general y elección de modelo

12.1 Tabla comparativa de todos los modelos

12.2 Criterios para elegir el tipo de base de datos

¿Datos muy relacionados y consultas complejas en grafos?
  → Base de datos de GRAFOS (Neo4j)

¿Necesito máxima velocidad de lectura/escritura, datos simples?
  → CLAVE-VALOR (Redis, DynamoDB)

¿Documentos JSON con esquema flexible?
  → DOCUMENTAL (MongoDB)

¿Escrituras masivas distribuidas, IoT, series temporales?
  → COLUMNAR (Cassandra) o SERIES TEMPORALES (InfluxDB)

¿Análisis histórico, reporting, BI?
  → DATA WAREHOUSE (Redshift, BigQuery, Snowflake)

¿Búsqueda de texto completo, análisis de logs?
  → BÚSQUEDA (Elasticsearch)

¿Transacciones complejas, integridad referencial, SQL estándar?
  → RELACIONAL (PostgreSQL, MySQL, Oracle)

13. Resumen esquemático y preguntas tipo test

Resumen para repaso rápido

Preguntas tipo test de los exámenes

P: Neo4j, ¿qué tipo de base de datos es?
→ b) Base de datos orientada a grafos (no relacional, no columnar)

P: ¿Cuál de las siguientes opciones no es un sistema de gestión de bases de datos?
→ b) SQL (SQL es un lenguaje, no un SGBD; MySQL y Microsoft SQL Server sí son SGBD)

P: Indica qué base de datos es del tipo Clave-valor:
→ c) Redis (MongoDB es documental; Neo4j es de grafos)

P: ¿Qué lenguaje debo utilizar para realizar una consulta a una base de datos multidimensional (cubo OLAP)?
→ a) MDX (MultiDimensional eXpressions) (MQL y SMQL no existen como estándares)

P: ¿Cuál de las siguientes características se corresponde con una de las características de los datawarehouse?
→ c) La información se organiza por temas o áreas de negocio (sí distingue datos actuales de históricos; no es volátil)

P: Un almacén de datos se diferencia de una base de datos en:
→ c) Ambos son sistemas de almacenamiento, pero se utilizan para propósitos distintos (el DW para análisis histórico, la BBDD operacional para transacciones diarias)

P: En minería de datos se analizan hechos sobre la realidad basándose en los datos disponibles. Estos datos se organizan en dimensiones que son:
→ a) Las diferentes perspectivas a través de las que se pueden analizar los datos disponibles (no son datos numéricos ni tablas físicas)

P: Dado un conjunto de datos con 100.000 observaciones, donde cada observación es un vector real de 100 dimensiones, normalmente usaremos PCA para:
→ b) Obtener 100.000 observaciones, pero con un número de dimensiones inferior a 100 (PCA reduce dimensiones, no observaciones)

P: ¿Qué técnica de aprendizaje automático es más adecuada para descubrir grupos ocultos en un conjunto de datos?
→ c) K-Means clustering (regresión lineal es supervisada; árboles de decisión son para clasificación/regresión supervisada)

P: De acuerdo con la metodología CRISP-DM, ¿cuántas fases presenta el proceso de minería de datos?
→ c) 6 (no 7, no 8)

P: Respecto a JSON, ¿pueden las bases de datos almacenar y utilizar datos en este formato?
→ a) Sí, existen algunas bases que permiten trabajar con JSON de manera nativa (MongoDB, PostgreSQL con jsonb, MySQL, etc.)

P: ¿Cuál es la función principal de un Sistema de Información Geográfica (SIG)?
→ a) Capturar, almacenar, analizar y visualizar datos geográficos para comprender patrones y relaciones espaciales