Open Business Intelligence

La red del Business Intelligence

Hola a todos.
Recientemente se diseñó un datawarehouse en mi empresa (se dedica a la venta de semillas y agroquímicos) y pongo en duda el diseño con el cual se desarrolló (fue realizado por un proveedor externo).
Mi idea es plantear acá en forma muy resumida las relaciones de las tablas donde están los hechos en la base transaccional y ver cómo diseñarían ustedes el warehouse a partir de esto:

Básicamente, en el sistema entran los vendedores que están en el campo y cada año cargan la siguiente información:
1- Superficie de producción de los establecimientos a los que se vende
2- Superficie dedicada a cada cultivo específicamente de esos establecimientos
3- Venta de cada producto para utilizar en cada establecimiento (tanto para semillas, como para agroquímicos)

El DER (muy simplificado) es el siguiente:


Las tablas que contienen los hechos son:
Producciones: En el campo Hectareas se carga lo mencionado en el punto 1
Siembras: En el campo Hectareas se carga lo mencionado en el punto 2
Semillas: En el campo Venta se carga lo mencionado en el punto 3 (semillas)
Agroquímicos: En el campo venta se carga lo mencionado en el punto 3 (agroquimicos)

Puede haber un registro de Produccion sin registros de Siembras y de Agroquimicos asociados.
Puede haber un registro de Siembras sin registros de Semillas asociados.

Si bien el modelo es realmente simple, se me presentan algunas complicaciones al momento de identificar las Fact tables...

Cómo lo diseñarían ustedes?????

Muchas gracias por la ayuda!

Juan Manuel

Visitas: 1049

Responde a esto

Respuestas a esta discusión

Buenas tardes Juan Manuel, junto con mi colega Ariel Somale estuvimos viendo tu tema, y desde nuestro punto de vista, la tabla de hechos, debería poseer los siguientes campos:

id_assesor: es el correspondiente a la tabla "Assesores"
id_establecimiento: es el correspondiente a la tabla "Establecimientos".
id_campaña: es el correspondiente a la tabla "Campañas".
id_unidad_medida: referencia a la unidad de medida utilizada, es decir, Has (Siembras), Litros (Agroquímicos), ventas (Semillas).
id_concepto: referencia el nombre del producto, semilla, agroquímico, que se utilizó.
Para este caso, se debería construir una tabla de dimensiones que cruce las tablas "Siembras", "Semillas", "Agrquímicos" y "Productos".
Valor_Hecho: este es hecho en cuestión (venta en cantidad, moneda,etc.), y su valor dependerá de los valores que asuman los id anteriores.

Esperamos te sea de utilidad. Por cierto, hay muchas cosas que tuvimos que suponer, ya que no había suficiente información.

Saludos.

--
Ing. Bernabeu R. Dario
Juan Manuel,
Mira el siguiente modelo alternativo:


Por lo que veo tu modelo esta normalizado, con lo cual vas a minimizar el espacio en disco, pero tendrás un problema de performance a la hora de consultar los datos.
Lo que yo hice fue desnormalizar tu modelo y use dos tablas fact para no tener una sola tabla voluminosa y de paso separar por dos temas, por un lado agroquimicos y semillas por el otro.
La idea es que el costo de acceder a la informacion sea minimo.

Se te interesa puedo pasarte una metodología general de carga y procesamiento de DW, la cual usamos siempre.

Espero te sirva esta alternativa.

Saludos Atte.
Ing. Damián J. Putero
Darío, Ariel, Damián:
Antes que nada quiero agradecerles la rápida y dedicada respuesta de cada uno de ustedes. Por otro lado les pido disculpas por no haber podido contestar antes. Estuve de viaje y realmente no esperaba que contesten tan rápido! gracias!

Darío, Ariel:
Creo entender a qué apunta la solución que me plantean. Sin embargo hay algo que me parece que me complicaría un poco las cosas al momento de enfrentar al usuario con este modelo: Por lo que veo ustedes me sugieren usar un mismo campo para los valores de todos los hechos y agregar una FK a la fact que se relacione con un determinado concepto. Esto, según entiendo, haría necesaria la existencia de una dimensión "Concepto", y el usuario debería cruzar una métrica única con esta dimensión para poder ver los valores de los distintos hechos.
Por otro lado, como bien dicen ustedes, falta información en mi descripción del modelo, y una de las cosas que no aclaré es que además de los valores de hectáreas de producción, hectáreas de siembra, ventas y litros, hay algunos otros valores importantes en cada una de las tablas. Esto haría que tenga muchos otros conceptos, lo que multiplicaría la cantidad de registros de la fact y lo haría más complicado.
Es realmente necesario que exista la dimensión "concepto" en el modelo que plantean? O hay alguna forma de manejarlo internamente para que el usuario lo vea de forma más simple?

Damián:
Aclaro que el modelo que describo en mi consulta no es el warehouse sino el transaccional sobre el que cargan la información los usuarios. Por eso la normalización. El warehouse de hecho está desnormalizado, pero está hecho de una forma un tanto complicada y por eso quería otras opiniones para comparar con el diseño del proveedor.
Me parece interesante tu modelo y muy lógica la separación que planteás, pero hay algo que no se si quedaría resuelto en este modelo, que es la sumarización de la información de los distintos valores. La duda que se me plantea es la siguiente: Si existen muchos registros de la tabla semillas para cada registro de siembras y a la vez muchas siembras para cada producción, al sumar los valores de hectáreas de producción, hectáreas de siembra y ventas, cómo evitar sumar muchas veces el valor de hectáreas (por cada registro de nivel inferior)?
Lo mismo con el caso de agroquímicos.
Con respecto a la metodología que me ofrecés, creo que me puede llegar a ser útil. Te agradecería si me la podés pasar.

Disculpas si estoy preguntando cosas un poco tontas... No hace mucho que estoy en el tema de BI y por ahí paso por alto algunas cuestiones que para ustedes pueden ser obvias.

Muchas gracias nuevamente por sus comentarios!

Saludos

Juan Manuel
Juan Manuel,

Primero hago unas correcciones sobre las Facts del modelo que te pase:
Fact_Prod_Siembra= id_asesor + id_campaña + id_establecimiento + id_producto + id_cultivo + hec_produccion + hec_siembra + ventas
Fact_Prod_Agroquimic= id_asesor + id_campaña + id_establecimiento + id_producto + hec_produccion + litros

Con ese modelo verias el maximo nivel de detalle de la información, no se habla de sumarizar los datos. Para armar un DW se necesitan muchas especificaciones en base a las cuestiones que se quieren responder hoy y en un futuro. Debes especificar, granularidad (ejemplo: Trimestral, mensual, semanal, etc), las aperturas por las cuales quieres accedar a la información (Ejemplo: Tiempo, Producto, Region, etc), los indicadores a calcular, que valores cargar pordefecto en las dimensiones para cuando exista una clave nula en las fact, etc.

Otro modelo de ejemplo de la fact "Fact_Prod_Siembra", que si esta sumarizado y tiene algunas aperturas, podria ser:

Fact_Prod_Siembra= id_asesor + id_campaña + id_establecimiento + hec_produccion + hec_siembra + ventas

Las aperturas serian: Asesores, Campañas y Establecimientos

La query para cargar la fact podria ser:
select P.id_asesor, P.id_campaña, P.id_establecimieno,
sum(P.Hectareas) as Hect_Producciones, sum(S.Hectareas) as Hect_Siembras, sum(SM.ventas) as Ventas
from producciones P, Siembras S, Semillas SM
where P.id_produccion=S.id_produccion and S.id_siembra=SM.id_siembra
group by P.id_asesor, P.id_campaña, P.id_establecimieno
union all
select P.id_asesor, P.id_campaña, P.id_establecimieno,
sum(P.Hectareas) as Hect_Producciones, sum(S.Hectareas) as Hect_Siembras, sum(0) as Ventas
from producciones P, Siembras S, Semillas SM
where P.id_produccion=S.id_produccion and S.id_siembra<>SM.id_siembra
group by P.id_asesor, P.id_campaña, P.id_establecimieno
union all
select P.id_asesor, P.id_campaña, P.id_establecimieno,
sum(P.Hectareas) as Hect_Producciones, sum(0) as Hect_Siembras, sum(0) as Ventas
from producciones P, Siembras S, Semillas SM
where P.id_produccion<>S.id_produccion
group by P.id_asesor, P.id_campaña, P.id_establecimieno;

Podrias tener amobos modelos, uno para ver el resumen de la informacion y el otro para acceder al detalle.

Espero te sea de ayuda.

Para que te pase el documento, escribime a damutn@gmail.com


Saludos!
Buenos días Juan Manuel.

En realidad no me imagino cuál es la otra información adicional que le estaría faltando al diagrama que planteaste, es por ello que no puedo darte una respuesta adecuada al caso.

Por otro lado, considero que deberías mantener una dimensión de Conceptos, en la que estarían incluidos todos los diferentes conceptos. Esta dimensión no sería más que una muy buena desnormalización de conceptos.
Este punto traerá diferentes implicaciones:
* el ETL que se utilizará para crear/actualizar esta dimensión será complejo, y por consiguiente el tiempo total de carga será mayor.
* los cruces con la tabla de hechos al momento de consultar la información será más ágil, ya que estarán todos los conceptos en una sola tabla de dimensión.
* el usuario no tiene que preocuparse por la estructura de esta dimensión, ya que podrías confeccionar Jerarquías para que este pueda manejarse cómodamente.

Espero te sirva. Cualquier cosa, no dudes en consultar.
Saludos.

--
Ing. Bernabeu R. Dario

Responder a debate

RSS

Distintivo

Cargando…

© 2024   Creado por Emilio.   Tecnología de

Emblemas  |  Reportar un problema  |  Términos de servicio