Esquema de estrella y diseño de almacenes de datos
Tablas de hechos y dimensiones, ventajas y desventajas de la desnormalización y modelado OLAP.
Esquema de estrella y diseño de almacenes de datos es una lección gratuita de SQL Interview Prep en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Interview Prep, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Interview Prep incluye 4 lecciones en total.
OLTP frente a OLAP
Las preguntas sobre almacenes de datos comienzan con una distinción que los entrevistadores esperan que domine: OLTP frente a OLAP.
- OLTP (transaccional): muchas lecturas y escrituras pequeñas, con un alto grado de normalización para garantizar la integridad. Da soporte a la aplicación.
- OLAP (analítico): pocas lecturas grandes que agregan datos históricos, con una desnormalización deliberada para obtener velocidad. Da soporte a los informes y paneles.
Los esquemas en estrella son un diseño OLAP. Su objetivo es realizar consultas analíticas rápidas, aceptando redundancia a cambio de velocidad.
Hechos y dimensiones
Un esquema en estrella divide los datos en dos tipos de tablas:
- Tabla de hechos: los eventos o transacciones medibles (una venta, un clic). Contiene medidas numéricas y claves foráneas hacia las dimensiones.
- Tablas de dimensiones: el contexto descriptivo por el que se segmentan los datos (fecha, producto, cliente, tienda).
La tabla de hechos se encuentra en el centro; las dimensiones la rodean como las puntas de una estrella, de ahí su nombre.
Anatomía de una tabla de hechos
Una tabla de hechos consta principalmente de claves foráneas y medidas numéricas. Es larga y estrecha, y crece continuamente.
Las medidas son valores numéricos aditivos que se agregan: cantidad, ingresos, coste. La granularidad (una fila = un ?) debe indicarse claramente; aquí, una fila representa una línea de producto de una venta.
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
date_key INT NOT NULL, -- FK to dim_date
product_key INT NOT NULL, -- FK to dim_product
customer_key INT NOT NULL, -- FK to dim_customer
store_key INT NOT NULL, -- FK to dim_store
quantity INT, -- measure
revenue DECIMAL(12,2), -- measure
cost DECIMAL(12,2) -- measure
);Anatomía de una tabla de dimensiones
Las dimensiones son cortas y anchas: contienen muchas columnas descriptivas por las que se filtran y agrupan los datos. Se desnormalizan intencionadamente para que una consulta solo necesite una unión por dimensión.
Observe que dim_product mantiene la categoría y la marca en la misma fila, en lugar de hacerlo en tablas separadas. Esa redundancia es precisamente el objetivo: evita uniones adicionales en el momento de consultar.
CREATE TABLE dim_product (
product_key INT PRIMARY KEY, -- surrogate key
product_id INT, -- natural/business key
product_name VARCHAR(100),
category VARCHAR(50), -- denormalized
brand VARCHAR(50), -- denormalized
unit_price DECIMAL(10,2)
);Una consulta de esquema en estrella
Esto es lo que se consigue con este diseño. Una consulta analítica típica une la tabla de hechos con algunas dimensiones, filtra y agrega los datos. Hay una unión por dimensión, sin cadenas profundas.
Los entrevistadores le pedirán que escriba exactamente este tipo de consulta sobre un esquema en estrella.
SELECT d.category,
t.year,
SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product d ON d.product_key = f.product_key
JOIN dim_date t ON t.date_key = f.date_key
WHERE t.year = 2025
GROUP BY d.category, t.year
ORDER BY total_revenue DESC;Claves subrogadas
Las dimensiones utilizan una clave subrogada: una clave primaria entera sin significado empresarial (como product_key) generada por el almacén de datos, independiente de la clave natural del sistema de origen.
Por qué les importa a los entrevistadores:
- Desacopla el almacén de datos de las claves empresariales cambiantes.
- Mantiene reducida la anchura de las tablas de hechos (las uniones entre enteros son rápidas).
- Es necesaria para mantener el historial mediante dimensiones de cambio lento (la siguiente escena).
Dimensiones de cambio lento
Un tema favorito en las entrevistas sobre almacenes de datos: cuando cambia un atributo de una dimensión (un cliente se muda de ciudad), ¿cómo se gestiona? Se trata de dimensiones de cambio lento (SCD):
- Tipo 1: sobrescribir el valor anterior. Sin historial.
- Tipo 2: añadir una fila nueva con fechas de vigencia y un indicador de actualidad. Historial completo; requiere claves subrogadas.
- Tipo 3: conservar una columna de «valor anterior». Historial limitado.
La respuesta que más habitualmente se espera para realizar un seguimiento de los cambios a lo largo del tiempo es el tipo 2.
-- SCD Type 2 dimension
CREATE TABLE dim_customer (
customer_key INT PRIMARY KEY, -- surrogate
customer_id INT, -- natural key
city VARCHAR(50),
valid_from DATE,
valid_to DATE,
is_current BOOLEAN
);Estrella frente a copo de nieve
Espere una pregunta comparativa. Un esquema de copo de nieve normaliza las dimensiones en subt tablas (producto -> categoría -> departamento), mientras que un esquema en estrella las mantiene planas.
- Estrella: menos uniones, lecturas más rápidas y cierta redundancia. Es la opción preferida por su rendimiento en las consultas.
- Copo de nieve: menos almacenamiento y mantenimiento más sencillo de las dimensiones, pero más uniones por consulta.
Diga: «Use por defecto el esquema en estrella para obtener velocidad en las consultas; use el copo de nieve únicamente cuando las dimensiones sean grandes y se reutilicen».
La dimensión de fecha
Casi todos los esquemas en estrella tienen una dimensión de fecha específica en lugar de una columna de fecha sin procesar. Esta dimensión precalcula el año, el trimestre, el mes, el día de la semana, los indicadores de festivo y los periodos fiscales.
Esto permite a los analistas agrupar por «trimestre fiscal» o por «is_weekend» mediante una unión sencilla, en lugar de usar funciones de fecha dispersas. Mencionar una dimensión de fecha sin que se lo pidan es una señal clara de que ha creado almacenes de datos.
CREATE TABLE dim_date (
date_key INT PRIMARY KEY, -- e.g. 20250131
full_date DATE,
year INT,
quarter INT,
month INT,
day_of_week VARCHAR(10),
is_weekend BOOLEAN,
fiscal_qtr VARCHAR(6)
);Elegir la granularidad
La decisión más importante sobre una tabla de hechos es la granularidad: qué representa una fila. Declárela antes que cualquier otra cosa.
- Si es demasiado general (una fila por día y tienda), perderá detalle.
- Si es demasiado específica (una fila por artículo escaneado), la tabla crecerá desmesuradamente.
Una declaración clara de la granularidad, como «una fila por producto y línea de pedido», determina qué dimensiones y medidas corresponden. Los entrevistadores prestan atención a esta disciplina.
Cuándo desnormalizar
Relaciónelo con la normalización. Los sistemas OLTP se normalizan hasta 3NF para garantizar la integridad; los almacenes de datos desnormalizan deliberadamente las dimensiones para obtener velocidad de lectura.
Debe explicar la siguiente compensación:
- Los datos redundantes de las dimensiones son aceptables porque el almacén se carga mediante ETL controlado, no mediante escrituras improvisadas de la aplicación.
- Menos uniones significan agregaciones más rápidas sobre miles de millones de filas de hechos.
Aquí, lo que diferencia las respuestas sénior es el criterio, no la regla.
Comprobación rápida
Está diseñando un almacén de datos de ventas y necesita conservar el historial completo de la ciudad de un cliente cuando se muda.
Repaso: esquema en estrella y diseño de almacenes de datos
Ahora puede responder preguntas sobre el modelado de almacenes de datos:
- OLTP normaliza para garantizar la integridad; OLAP desnormaliza para obtener velocidad de lectura.
- Un esquema en estrella tiene una tabla de hechos central (claves foráneas y medidas numéricas) rodeada de dimensiones planas.
- Use claves subrogadas y una dimensión de fecha específica.
- Realice el seguimiento de los cambios con SCD de tipo 2; declare primero la granularidad de los hechos.
- Prefiera el esquema en estrella frente al copo de nieve para obtener un mejor rendimiento en las consultas.
Preguntas frecuentes
¿La lección «Esquema de estrella y diseño de almacenes de datos» es gratis?
Sí — el texto completo de «Esquema de estrella y diseño de almacenes de datos» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Interview Prep, actualiza a CoddyKit PRO. El curso de SQL Interview Prep incluye 4 lecciones en total.
¿Qué aprenderé en «Esquema de estrella y diseño de almacenes de datos»?
Tablas de hechos y dimensiones, ventajas y desventajas de la desnormalización y modelado OLAP. Practicas SQL Interview Prep con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar SQL Interview Prep?
No se requiere experiencia previa. SQL Interview Prep en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.
¿Cuánto tiempo toma la lección «Esquema de estrella y diseño de almacenes de datos»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de SQL Interview Prep?
Sí. Cada lección de SQL Interview Prep incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Normalización hasta la 3NF
- Modelado ER y cardinalidad de relaciones
- Esquema de estrella y diseño de almacenes de datos
- Colección completa de problemas de simulación de entrevista