Diseñar un modelo dimensional es crucial para traducir los registros transaccionales en información útil para la toma de decisiones empresariales. En esta clase, veremos cómo crear tablas, identificar relaciones, y asignar atributos a las distintas dimensiones, siempre respetando las reglas de negocio.
¿Qué es una regla de negocio?
Una regla de negocio establece las transformaciones que los datos deben cumplir para satisfacer las necesidades de la empresa. Un ejemplo clásico es la necesidad de consolidar campos de nombres separados en un solo campo de nombre completo. Otra regla podría ser condensar un campo de observación extenso o adicionarle atributos a un vendedor según ciertos criterios. Estas reglas son integradas en el ETL para reflejarse en el modelo dimensional.
¿Cómo se hace la diagramación del modelo?
Utilizamos herramientas como DbDiagram para diagramar el modelo de datos basado en las dimensiones y hechos identificados previamente. Comenzamos creando tablas para las dimensiones como la de clientes y productos, definiendo atributos y estableciendo sus tipos de datos.
Definimos cada campo según las reglas de negocio, y revisamos las bases de datos para asegurarnos del acceso a toda la información necesaria.
¿Cómo se estructura la tabla de hechos?
La tabla de hechos, en este caso FacVentas, contiene las métricas y los IDs de las dimensiones. La estructura incluye un ID de venta, IDs de cliente y producto como claves, y las métricas identificadas como cantidad vendida, valor, descuento y valor neto.
Table dwh.FacVentas {
IdVenta int [pk, increment]
IdCliente int [ref: > dwh.DimClientes.IdCliente]
IdProducto int [ref: > dwh.DimProductos.IdProducto]
CantidadVendida int
Valor decimal
Descuento decimal
ValorNeto decimal
}
Es importante destacar que no es necesario crear relaciones físicas en bases de datos en modelos dimensionales, ya que las dimensiones pueden emplearse en múltiples modelos.
¿Cómo establecer relaciones virtuales?
Aunque no se requieren relaciones físicas, al diseñar en herramientas de modelado, es útil definir relaciones virtuales para visualizar mejor cómo las tablas se relacionan.
Por ejemplo, conectar IdCliente de una dimensión con el mismo campo en la tabla de hechos para entender la interconexión de datos:
Una vez que el diseño básico del modelo está completado, se pueden añadir más dimensiones como vendedores y geografía para enriquecer el modelo. Esto permite abarcar más escenarios de negocio y realizar análisis más completos.
Te animamos a que experimentes incorporando estas dimensiones faltantes y compartas tu propuesta y resultados. Continuar extendiendo el modelo afina tu habilidad de diseño y mejora las capacidades analíticas del data warehouse.
Dejo URL de mis notas relativas a hechos y dimensiones, que he publicado en mi repositorio de GitHub y en LinkedIn, por si a algún/a compañero/a le pueda interesar:
Gracias
Here my proposal about task teacher left us, what you think guys !
Cuál es el sentido de que la Fact tenga una columna con PK ? me gustaría entender la necesidad, pq no la veo en realidad.
Cada venta debe tener un identificador unico, porque mas alla de que sea una tabla dependiente de las demas, tiene sus propios valores que hace que deba identificarse de manera unica.
quisiera saber algo, tengo entendido que un registro es una fila, un atributo es una columna y la dimensión es el producto del total de registro por los atributos, estoy en lo correcto ?
si yo tengo un campo que es un booleano, el cual me indica que el valor de la administración de un contrato es cobrada o no es cobrada a un cliente, este campo seria otra dimensión y el valor de la administración estaría en la tabla de hechos o el campo booleano puede ir en la tabla de hechos?
Esto dependerá de si este campo booleano se comporta igual para todos los clientes (iría en la dimensión) o si depende de cada cliente+contrato (iría en la de hechos al momento de celebrar el contrato). Ten en cuenta que también podría ir en la dimensión de clientes si es que depende del cliente el cobro de esta administración, por ejemplo, que todos los contratos para este cliente deben ser cobrados. Todo dependerá de las necesidades del negocio.
Table dwh.dim_producto {
id_producto int pk
codigo_cliente varchar
nombre varchar
color varchar
tamano varchar
categoria varchar
}
Ref:dwh.dim_producto.id_producto < dwh.fact_ventas.id_producto
Table dwh.dim_geografia {
id_ubicacion int pk
cod_ubicion varchar
pais varchar
estado varchar
ciudad varchar
}
Ref:dwh.dim_geografia.id_ubicacion < dwh.fact_ventas.id_ubicacion
Table dwh.dim_vendedores {
id_vendedor int pk
cod_vendedor varchar
nombre varchar
apellido varchar
}
Ref:dwh.dim_vendedores.id_vendedor < dwh.fact_ventas.id_vendedor
Table dwh.fact_ventas {
id_venta int pk
id_cliente int pk
id_producto int pk
id_ubicacion int pk
id_vendedor int pk
cantidad int
valor decimal
descuento decimal
valor_neto decimal
}
El diseño de un modelo dimensional se centra en estructurar los datos para facilitar la consulta y el análisis, utilizando un enfoque orientado al usuario final. A continuación, se describen los pasos principales para diseñar un modelo dimensional:
1. Definir el propósito del modelo
Objetivo: Comprender las preguntas de negocio que el modelo debe responder. Por ejemplo:
¿Qué métricas se analizarán (ventas, ingresos, costos)?
