Base de datos en SQL (con ejemplo real de modelo de datos)

04/12/2025
|In Google analytics
|By Ignacio

Esta guía responde a una de las preguntas que más nos hacen en empresas y formaciones:

“Quiero usar SQL para analítica (web, marketing, negocio…), pero ¿por dónde empiezo?
«¿Cómo debería estar estructurada mi base de datos para no hacer chapuzas?”

En el curso original de SQL que hicimos en su día, se utilizaba una base de datos de un hospital para explicar estos conceptos: tablas EMP, DEPT, HOSPITAL, DOCTOR, ENFERMO, SALA, etc.
Aquí vamos a conservar la misma lógica, pero aplicada a un proyecto real nuestro que es de bolsa, que trabaja con acciones de bolsa como dataset de ejemplo.

Muddle consejo: la clave: no te quedes con “acciones” o “hospitales”, quédate con los patrones. Esos mismos patrones se aplican luego a Google analytics o un CRM.

2. Conceptos que debes repasar antes de meterte en queries

Vamos a ir rápido pero antes debes saber qué es una

2.1. Tabla

Una tabla en SQL es una colección de filas (registros) con las mismas columnas.

  • Ejemplo en analítica digital:
    • USUARIOS, SESIONES, EVENTOS, CAMPAÑAS, PEDIDOS.
  • Ejemplo en nuestro proyecto de bolsa:
    • TICKER, HISTORICO_PRECIOS, EARNINGS, SENTIMIENTOS.

2.2. Columna

  • Cada columna representa un atributo.
  • Ejemplos:
    • En USUARIOS: id_usuario, pais, dispositivo.
    • En TICKER: SIMBOLO, NOMBRE_PUBLICO, SECTOR.

2.3. Clave primaria (PK)

Es una columna (o columnas) que identifican de forma única cada fila de una tabla. No puede repetirse, no puede ser NULL. Es la “matrícula”.

  • Ejemplos:
    • id_usuario en USUARIOS.
    • SIMBOLO en TICKER (AAPL, MSFT, etc.).

2.4. Clave foránea (FK)

Es una columna que apunta a la clave primaria (PK) de otra tabla. Sirve para relacionar tablas.

  • Ejemplos:
    • id_usuario en SESIONES apunta a USUARIOS.id_usuario.
    • SIMBOLO en HISTORICO_PRECIOS apunta a TICKER.SIMBOLO.

2.5. Relaciones 1:N (uno a muchos)

  • Un registro de una tabla se relaciona con muchos registros de otra.
  • Ejemplos:
    • 1 usuario → muchas sesiones
    • 1 campaña → muchos clics
    • 1 ticker → muchos precios diarios

Si te quedas con esto claro, el resto del post te va a encajar como un puzzle.

3. Modelo de datos: un ejemplo real de base de datos para analítica

Este será nuestro modelo de referencia para el resto de posts de SQL.
No es un blog de bolsa; es un blog de analítica digital, pero usamos este dataset porque:

  • Es rico en tiempo (fechas, históricos),
  • Tiene métricas numéricas (precios, volumen, EPS…),
  • Y se parece mucho a trabajar con sesiones, conversiones y campañas.

3.1. Tabla TICKER (equivalente a “clientes”, “propiedades”, “productos”)

Rol en el modelo: tabla maestra de entidades que analizas.

TICKER
-------
SIMBOLO -- PK, p.ej. 'AAPL'
NOMBRE_PUBLICO -- 'Apple Inc.'
SECTOR -- 'Technology'
INDUSTRIA -- 'Consumer Electronics'
PAIS -- 'US'
EXCHANGE -- 'NASDAQ'
FECHA_ALTA -- opcional
ACTIVO -- opcional (S/N)

Paralelismos con analítica digital:

  • TICKER podría ser:
    • CLIENTE
    • MARCA
    • WEB_PROPERTY
    • APP
  • Es una tabla de dimensiones: describe “qué es” esa entidad, no “qué hizo”.

3.2. Tabla HISTORICO_PRECIOS (equivalente a “sesiones”, “eventos”, “transacciones”)

Rol en el modelo: tabla de hechos diarios.

HISTORICO_PRECIOS
-----------------
ID -- PK
SIMBOLO -- FK → TICKER.SIMBOLO
FECHA
OPEN
HIGH
LOW
CLOSE
VOLUMEN

Cada fila es: un ticker en un día concreto, con sus métricas.

Paralelismos con analítica digital:

  • Tabla SESIONES:
    • id_sesion, id_usuario, fecha, canal, etc.
  • Tabla EVENTOS:
    • id_evento, id_usuario, timestamp, tipo_evento, etc.
  • Tabla PEDIDOS:
    • id_pedido, id_cliente, fecha, importe, etc.

La idea es la misma: una tabla de registros diarios o de eventos que siempre tiene una clave foránea que la conecta con una tabla maestra (TICKER, USUARIO, CAMPAÑA, PRODUCTO…).

3.3. Tabla EARNINGS (como “conversiones” o “compras”)

Rol en el modelo: eventos especiales y poco frecuentes, pero importantes.

EARNINGS
--------
ID -- PK
SIMBOLO -- FK → TICKER
FECHA_EARNINGS
EPS_REAL
EPS_ESTIMADO
SURPRISE_PCT
-- opcionales: REVENUE_REAL, REVENUE_ESTIMADO...

Interpretación:

  • Son “momentos clave” que afectan al comportamiento futuro:
    • En bolsa: earnings,
    • En marketing: lanzamientos, campañas especiales, promociones,
    • En producto: releases, migraciones, cambios de pricing.

Nuestro paralelismo para analítica digital sería: calendario_campanas o promociones.

3.4. Tabla Sentimientos (como señales sociales o encuestas)

Rol en el modelo: tabla de métrica externa / cualitativa asociada a una entidad + fecha.

SENTIMIENTOS
--------------------
ID
SIMBOLO -- FK → TICKER
FECHA
SENTIMENT_SCORE -- métrica agregada
MENSAJES_TOTAL
MENSAJES_BULL
MENSAJES_BEAR

Paralelismos con analítica digital:

  • Podría ser:
    • NPS_DIARIO por producto,
    • SENTIMENT_SOCIAL por marca,
    • ENCUESTAS_USUARIO agregadas por día.

4. Cómo se relacionan las tablas (este es el patrón que te interesa)

Piensa en esto como tu primer mapa mental:

  • 1 TICKER
    ↳ N registros en HISTORICO_PRECIOS
    ↳ N registros en EARNINGS
    ↳ N registros en SENTIMENTIENTOS
  • EARNINGS_GLOBAL agrupa por fecha y SIMBOLO lo que pasa a nivel calendario.

En analítica digital esto sería:

  • 1 USUARIO
    ↳ N SESIONES
    ↳ N EVENTOS
    ↳ N PEDIDOS
  • Y una tabla CAMPAÑAS o CALENDARIO_MARKETING que explica qué pasaba en esas fechas.

Lo importante no son los nombres, sino:

  • Tener tablas maestras (dimensiones),
  • Tener tablas de hechos (registros diarios o de eventos),
  • Y entender bien las relaciones 1:N.

5. Mini-ejercicios para fijar el modelo

Para que todo lo anterior no se quede solo en teoría, aquí tienes tres ejercicios muy cortos. Puedes hacerlos mentalmente o en una libreta.

5.1. Identifica la PK y la FK

Sin mirar el texto de arriba, intenta responder primero por tu cuenta y luego compara:

  • ¿Cuál es la PK (clave primaria) de cada tabla?
    • TICKER → SIMBOLO
    • HISTORICO_PRECIOS → ID (o la combinación SIMBOLO + FECHA, según cómo definas el modelo)
    • EARNINGS → ID
    • SENTIMIENTOS → ID
  • ¿Qué columnas son FK (claves foráneas) y hacia qué tabla apuntan?
    • HISTORICO_PRECIOS.SIMBOLO → TICKER.SIMBOLO
    • EARNINGS.SIMBOLO → TICKER.SIMBOLO
    • SENTIMIENTOS.SIMBOLO → TICKER.SIMBOLO

Pista rápida para recordar la diferencia:

  • PK = el “DNI” de la fila.
  • FK = el “cable” que conecta esa fila con otra tabla.

5.2. Traducir el modelo a analítica digital

Imagina ahora que, en lugar de acciones, trabajas con datos de analítica digital:

  • TICKER es tu tabla de USUARIOS o CLIENTES.
  • HISTORICO_PRECIOS es tu tabla de SESIONES o EVENTOS.
  • EARNINGS es tu tabla de CAMPAÑAS o PROMOCIONES_ESPECIALES.
  • SENTIMIENTOS es tu tabla de NPS o SENTIMENT_SOCIAL.

Intenta explicarlo con una frase sencilla, por ejemplo:

“Un usuario puede tener muchas sesiones, muchos pedidos y muchos registros de NPS o encuestas.”

Si eres capaz de contar esta historia con tus datos, ya tienes interiorizado el patrón de dimensiones + hechos.

5.3. Llevarlo a tu propia realidad

Piensa en el tipo de datos con los que trabajas en el día a día (GA4, CRM, ecommerce, campañas de pago…):

  • ¿Cuál sería tu tabla maestra? (usuarios, clientes, productos, marcas…)
  • ¿Cuál sería tu tabla de hechos diarios o de eventos? (sesiones, eventos, pedidos…)
  • ¿Qué tabla podría jugar el papel de “eventos especiales” como EARNINGS? (calendario de campañas, promos, releases, etc.)

Hacer este pequeño ejercicio mental te ayudará mucho cuando veas esquemas de bases de datos en tu empresa o en herramientas como BigQuery.

6. Cierre y siguiente paso en la serie

En este primer artículo hemos hecho algo muy concreto: poner orden en cómo se estructura una base de datos para analítica.

  • Has visto la diferencia entre tablas maestras (dimensiones) y tablas de hechos.
  • Has entendido qué son una PK y una FK.
  • Y has visto un patrón que puedes reutilizar tanto con datos de bolsa como con datos de usuarios, sesiones o pedidos.

A partir de aquí, en el siguiente post de la serie empezaremos ya a escribir consultas:

  • Cómo hacer tus primeros SELECT sobre este modelo.
  • Cómo filtrar con WHERE sin hacer un muddle
  • Cómo ordenar resultados con ORDER BY.

Todo ello siguiendo la misma idea: ejemplos con este dataset y su traducción directa al mundo de la analítica digital.

Privacy Preference Center

Privacy Preferences