Diseñar un modelo dimensional consiste en traducir las preguntas del negocio a tablas concretas: dimensiones que describen el contexto y una tabla de hechos que guarda las métricas. Aquí verás cómo armar ese diseño paso a paso, identificar relaciones y aplicar reglas de negocio para que tu data warehouse responda lo que el negocio realmente necesita.

¿Qué son las reglas de negocio en un modelo dimensional?

Las reglas de negocio son las transformaciones que el negocio te pide aplicar sobre los datos para que sirvan al momento de tomar decisiones [0:30]. No son opcionales: marcan cómo debe verse cada campo antes de llegar al modelo final.

Un ejemplo típico: tienes campos separados de nombre, segundo nombre, apellido y segundo apellido, pero el área de análisis necesita un solo campo de nombre completo. Esa unión es una regla que aplicas en el ETL y que luego se refleja en tu dimensión.

Otros casos comunes que vas a encontrar:

• Recortar campos de observación muy extensos porque el data warehouse no necesita tanto detalle.
• Marcar vendedores que cumplen un criterio con un atributo adicional.
• Agrupar datos transaccionales bajo categorías que el negocio define.

¿Dónde se aplican las reglas de negocio? En el proceso ETL, antes de cargar al modelo dimensional. El modelo solo refleja el resultado ya transformado.

¿Cómo se diseña una dimensión paso a paso?

Para diseñar una dimensión necesitas un nombre claro, una llave propia del data warehouse y los atributos que respondan a las preguntas de negocio. La herramienta usada en la clase es DB Diagram, que te permite escribir las tablas y verlas dibujadas al instante [2:30].

¿Cómo construir la dimensión de clientes?

La dimensión dim_clientes se crea bajo el esquema dw e incluye los campos que el negocio necesita para identificar y contactar a un cliente [3:00]:

• id_cliente como entero y llave primaria.
• codigo_cliente como varchar (el ID original del sistema transaccional).
• nombre y apellido como varchar.
• nombre_completo como varchar, cumpliendo la regla de negocio.
• numero_celular, numero_casa y numero_trabajo como varchar.
• ciudad_vivienda como varchar.

Fíjate en un detalle clave: el id_cliente del modelo no es el mismo del sistema transaccional. Creas un entero nuevo porque los IDs originales suelen ser varchar y no son óptimos para cruces ni indexaciones [6:30].

¿Cómo construir la dimensión de producto?

La dimensión dim_productos sigue la misma lógica. Llevas un id_producto entero como llave, un codigo_producto varchar que conserva el identificador transaccional, y los atributos que pidió el negocio:

• nombre_producto como varchar.
• color como varchar.
• tamano como varchar.
• categoria como varchar.

La categoría aparece porque el negocio pidió analizar ventas por categoría. Esa es la pista directa para saber qué atributos incluir: cada pregunta de negocio se traduce en un campo dentro de una dimensión.

¿Qué lleva la tabla de hechos y cómo se conecta con las dimensiones?

La tabla de hechos guarda los IDs de las dimensiones y las métricas que el negocio quiere medir. En este caso se llama fact_ventas porque las preguntas giran alrededor del proceso de ventas [7:30].

La estructura queda así:

• id_venta como entero y llave primaria incremental.
• id_cliente como entero, traído desde la dimensión de clientes.
• id_producto como entero, traído desde la dimensión de productos.
• cantidad como entero.
• valor como decimal.
• descuento como decimal.
• valor_neto como decimal, calculado como valor menos descuento.

¿Qué diferencia hay entre dimensión y tabla de hechos? La dimensión describe el contexto (quién, qué, dónde) con atributos descriptivos. La tabla de hechos guarda los IDs de esas dimensiones y los números que mides: cantidades, valores, descuentos.

¿Necesitas crear relaciones físicas entre tablas?

No. En un modelo dimensional las relaciones no se crean físicamente en la base de datos como en un modelo relacional tradicional [9:30]. Las relaciones existen de forma virtual: la tabla de hechos comparte los IDs con cada dimensión, y eso basta para hacer los cruces analíticos.

¿Por qué se hace así? Porque una misma dimensión puede reutilizarse en varios modelos. La dimensión de clientes puede aparecer en fact_ventas, en un modelo de despachos o en uno de rentas. La dimensión de productos puede vivir también en un modelo de inventarios. Forzar relaciones físicas limitaría esa reutilización.

En DB Diagram sí dibujas las relaciones para visualizar cómo se conectan los IDs, pero ese diagrama es documentación, no una restricción de base de datos.

¿Cómo traducir preguntas de negocio en atributos del modelo?

Cada atributo de tu modelo debe existir porque alguien lo va a preguntar. Si el negocio quiere ventas por categoría, categoria vive en dim_productos. Si quiere identificar un cliente puntual, los datos de contacto viven en dim_clientes. Y si quiere medir cantidades, valores y descuentos, esas métricas viven en fact_ventas.

Esta es la regla simple que ordena todo el diseño: los atributos descriptivos van a las dimensiones, los números medibles van a la tabla de hechos, y los IDs enteros creados en el data warehouse son los que conectan ambas.

Ahora te toca a ti: completa el modelo agregando la dimensión de vendedores y la de geografía, y cuéntanos en los comentarios cómo te quedó tu propuesta.