Diseño de almacén de datos: esquema en estrella para ERP y análisis de comercio electrónico

Su base de datos ERP está optimizada para transacciones: insertar pedidos, actualizar inventario, procesar pagos. Su plataforma de comercio electrónico está optimizada para ofrecer páginas de productos y procesar pagos. Ninguno de los dos está optimizado para responder las preguntas que impulsan las decisiones comerciales: ¿Qué categorías de productos son más rentables después de las devoluciones? ¿Qué segmentos de clientes tienen un valor de vida creciente? ¿Dónde están los cuellos de botella en nuestra cadena de suministro?

Ese vacío es lo que llena un almacén de datos. Y el esquema en estrella es el patrón de diseño que hace que las consultas analíticas sean rápidas, intuitivas y fáciles de mantener.

Conclusiones clave

• El esquema en estrella separa las métricas comerciales (hechos) del contexto descriptivo (dimensiones), lo que hace que las consultas sean intuitivas y rápidas.
• Los análisis de ERP y comercio electrónico normalmente necesitan de cuatro a seis tablas de hechos y de ocho a doce tablas de dimensiones para cubrir las preguntas comerciales centrales.
• Las canalizaciones de ETL deben utilizar una carga incremental con dimensiones que cambian lentamente para manejar el análisis histórico sin reprocesar todos los datos.
• Un esquema en estrella bien diseñado reduce la complejidad de las consultas entre un 60 y un 80 por ciento en comparación con la consulta directa de bases de datos operativas normalizadas.

---

¿Por qué no consultar el ERP directamente?

Antes de invertir en un almacén de datos independiente, muchas empresas intentan realizar consultas analíticas en su base de datos operativa. Esto falla por tres razones.

Rendimiento. Las consultas analíticas escanean millones de filas, calculan agregaciones y unen muchas tablas. Ejecutarlos en la base de datos de producción ralentiza el ERP para cada usuario. Un informe que analiza seis meses de datos de pedidos puede bloquear tablas y degradar el rendimiento del proceso de pago en tu tienda Shopify.

Complejidad. Las bases de datos operativas están normalizadas, diseñadas para minimizar la redundancia de datos. Una pregunta simple como "ingresos totales por categoría de producto por mes" podría requerir unir ocho tablas en la base de datos PostgreSQL de Odoo. En un esquema en estrella, la misma consulta une dos tablas.

Historial. Los sistemas operativos sobrescriben los datos. Cuando un cliente cambia su dirección, la dirección anterior desaparece. Cuando se recategoriza un producto, los informes históricos cambian retroactivamente. Un almacén de datos preserva la historia a través de dimensiones que cambian lentamente.

Múltiples fuentes. Las empresas medianas suelen ejecutar de tres a siete sistemas que contienen datos comerciales. El almacén de datos los consolida todos. Nuestra guía de canalizaciones ETL para datos ERP cubre la extracción y carga en detalle.

---

Fundamentos del esquema en estrella

Un esquema en estrella organiza los datos en dos tipos de tablas: tablas de hechos y tablas de dimensiones. Las tablas de hechos se encuentran en el centro (el cuerpo de la estrella) y las tablas de dimensiones las rodean (las puntas de la estrella).

Tablas de hechos

Las tablas de hechos almacenan eventos comerciales mensurables: cosas que sucedieron. Cada fila representa un evento en el grano significativo más bajo.

Características:

• Contiene medidas numéricas (cantidad, importe, duración, recuento)
• Contiene claves externas para tablas de dimensiones.
• Suelen ser las mesas más grandes del almacén.
• Crecer continuamente a medida que ocurren nuevos eventos.
• Debe tener el grano más fino que respalde las cuestiones comerciales.

Tablas de dimensiones

Las tablas de dimensiones almacenan contexto descriptivo: quién, qué, dónde, cuándo y cómo de los eventos comerciales.

Características:

• Contiene atributos textuales y jerarquías.
• Son relativamente pequeños (de miles a millones de filas, no miles de millones)
• Cambia lentamente con el tiempo
• Están desnormalizados para simplificar las consultas.
• Proporcionar las etiquetas, filtros y agrupaciones para los informes.

La forma de estrella

                    Dim: Customer
                         |
    Dim: Product ---  Fact: Sales  --- Dim: Time
                         |
                    Dim: Location

Una consulta como "ingresos totales por categoría de producto por trimestre por región" une la tabla de datos de ventas con tablas de tres dimensiones. Sin subconsultas, sin uniones anidadas complejas, solo uniones en estrella sencillas.

---

Diseño de tablas de hechos para ERP y comercio electrónico

Una empresa mediana típica que ejecuta Odoo ERP y Shopify eCommerce necesita de cuatro a seis tablas de hechos para cubrir los casos de uso analíticos principales.

Hecho: Ventas

La tabla de datos de ventas es la piedra angular. Cada fila representa un artículo de línea en un pedido de ventas.

Grano: Una fila por línea de pedido por día.

Hecho: Inventario

Realiza un seguimiento de los niveles de inventario como instantáneas periódicas en lugar de eventos.

Grano: Una fila por producto por almacén por día.

Hecho: Producción

Para las empresas manufactureras, el dato de producción rastrea las órdenes de trabajo.

Grano: Una hilera por orden de trabajo por producto por día.

Tablas de datos adicionales

• Dato: Compras --- gasto en adquisiciones por proveedor, producto y tiempo.
• Dato: Tickets de soporte --- volumen de tickets, tiempo de respuesta, tiempo de resolución por agente, cliente y categoría.
• Dato: Tráfico web --- visitas a páginas, sesiones, conversiones por página, fuente y campaña. Útil para análisis de atribución de marketing.

---

Diseño de tablas de dimensiones

Las tablas de dimensiones proporcionan el contexto que hace que los números de las tablas de hechos sean significativos. El principio clave es la desnormalización: almacenar datos redundantes para simplificar las consultas.

Oscuro: Hora

La dimensión temporal está presente en todo esquema estelar. Calcule previamente los atributos del calendario para evitar funciones de fecha complejas en las consultas.

Oscuro: Cliente

Desnormalice los atributos de los clientes de los sistemas CRM, contabilidad y comercio electrónico en una sola dimensión.

Las columnas rfm_segment y lifetime_value_tier son campos calculados derivados del análisis RFM, actualizados periódicamente por la canalización ETL.

Tenue: Producto

---

Dimensiones que cambian lentamente

Cuando un cliente se muda de Nueva York a Londres, ¿qué debe hacer el almacén de datos? La respuesta depende de la cuestión empresarial.

Tipo 1: Sobrescribir

Reemplace el valor anterior con el nuevo valor. La ciudad del cliente pasa a ser Londres y todos los pedidos históricos ahora muestran Londres. Utilícelo cuando la precisión histórica del atributo no importe.

Tipo 2: Agregar nueva fila

Cree una nueva fila para el cliente con la nueva ciudad, una fecha de vigencia y una fecha de vencimiento. Los pedidos históricos todavía apuntan a la fila anterior (Nueva York) y los nuevos pedidos apuntan a la fila nueva (Londres). Este es el enfoque más común para los atributos que afectan el análisis: segmento de clientes, departamento de empleados, categoría de producto.

Tipo 3: Agregar nueva columna

Almacene los valores nuevos y antiguos en columnas separadas. Útil cuando necesita comparar el antes y el después pero no necesita el historial completo. Menos común en la práctica.

Para empresas medianas, utilice el Tipo 2 para segmento de clientes, departamento de empleados, categoría de producto y atributos geográficos. Utilice el Tipo 1 para todo lo demás para mantener el almacén sencillo.

---

Patrones de diseño ETL

El proceso ETL (Extraer, Transformar, Cargar) mueve datos desde los sistemas de origen al almacén. Los patrones de diseño que funcionan bien para datos de ERP y comercio electrónico incluyen los siguientes.

Carga incremental

En lugar de recargar todos los datos en cada ejecución, realice un seguimiento de la última marca de tiempo cargada correctamente y procese solo los registros modificados desde entonces. El campo write_date de Odoo y el parámetro updated_at de Shopify hacen que esto sea sencillo.

1. Query source: SELECT * FROM sale_order_line WHERE write_date > last_load_timestamp
2. Transform: Map source fields to warehouse columns, look up dimension keys
3. Load: INSERT new rows, UPDATE changed rows (upsert)
4. Update: Set last_load_timestamp to current run start time

Gestión de claves sustitutas

Las tablas de dimensiones utilizan claves sustitutas (enteros que se incrementan automáticamente) en lugar de claves naturales (ID de Odoo, ID de Shopify). Esto desacopla el almacén de los formatos de claves del sistema de origen y maneja la consolidación de múltiples fuentes donde diferentes sistemas tienen esquemas de identificación en conflicto.

Dimensiones que llegan tarde

A veces, un registro de hechos llega antes que el registro de dimensión correspondiente: un pedido hace referencia a un nuevo cliente que aún no se ha sincronizado. Handle this with a placeholder dimension row that gets updated when the full dimension record arrives.

Actualizar programación

Para conocer los requisitos en tiempo real, consulte nuestra guía de análisis de transmisión.

---

Optimización del rendimiento de consultas

Un esquema en estrella bien diseñado ya funciona bien debido a sus patrones de unión simples. Las optimizaciones adicionales incluyen las siguientes.

Índices. Cree índices en todas las claves externas de dimensiones en tablas de hechos y en atributos de dimensiones comúnmente filtrados (intervalos de fechas, segmentos de clientes, categorías de productos).

Visitas materializadas. Consultas comunes agregadas previamente: ingresos diarios por categoría de producto, niveles de inventario semanales por almacén, adquisición mensual de clientes por canal. Actualice las vistas materializadas después de cada carga de ETL.

Particionamiento. Partición de tablas de hechos grandes por fecha (mensual o trimestral). Las consultas que filtran por rango de fechas escanean solo las particiones relevantes.

Estadísticas de columna. Mantenga las estadísticas de PostgreSQL actualizadas con ANALYZE después de cargas masivas para que el planificador de consultas tome decisiones óptimas.

Estas optimizaciones respaldan la experiencia de BI de autoservicio donde los usuarios empresariales ejecutan consultas ad hoc sin problemas de rendimiento.

---

Preguntas frecuentes

¿Qué tamaño debe tener la empresa para justificar un almacén de datos?

No hay un tamaño mínimo, pero la inversión vale la pena cuando tiene múltiples fuentes de datos que deben combinarse para el análisis, cuando las consultas operativas de bases de datos están ralentizando los sistemas de producción o cuando dedica más de 10 horas por semana a la recopilación manual de datos y la creación de informes. La mayoría de empresas con 30 o más empleados y al menos dos sistemas (ERP más comercio electrónico) se benefician de un almacén.

¿Deberíamos utilizar un almacén de datos en la nube como Snowflake o BigQuery?

Para las empresas medianas, PostgreSQL maneja bien la mayoría de las cargas de trabajo analíticas y cuesta significativamente menos. Los almacenes en la nube como Snowflake se vuelven atractivos cuando sus datos superan 1 TB, cuando necesita separar la computación del almacenamiento para optimizar los costos o cuando tiene requisitos complejos para compartir datos entre organizaciones. Comience con PostgreSQL y migre cuando lo supere.

¿Cuánto tiempo lleva construir un almacén de datos?

Un almacén mínimo viable con una tabla de hechos (ventas), cuatro tablas de dimensiones y un canal ETL que conecta Odoo y Shopify requiere de cuatro a ocho semanas para un equipo experimentado. Agregar tablas de hechos, cambiar dimensiones lentamente y monitorear la calidad de los datos lleva otras cuatro a ocho semanas por tabla de hechos. Planifique de tres a seis meses un almacén integral que cubra todas las áreas comerciales principales.

---

¿Qué sigue?

Un esquema en estrella bien diseñado es la base de toda capacidad de análisis, desde paneles de autoservicio hasta modelos predictivos y análisis integrados. Es parte de una estrategia de BI más amplia que transforma la forma en que su empresa toma decisiones.

ECOSIRE crea almacenes de datos y canales de análisis para empresas que ejecutan Odoo, Shopify y GoHighLevel. Nuestro equipo de consultoría de Odoo diseña esquemas de almacén adaptados a su modelo de negocio, y nuestros servicios de IA OpenClaw añaden análisis predictivos.

Contáctenos para analizar la arquitectura de su almacén de datos.

---

Publicado por ECOSIRE --- ayudando a las empresas a escalar con soluciones impulsadas por IA en Odoo ERP, Shopify eCommerce y OpenClaw AI.