Para hacer un diseño, buen diseño, mediante el sistema OLAP, hay algún truco, algún esquema, algún sistema general para diseñar y corregir? o se hace a ojímetro y lo vas ganando con la experiencia(que en mi caso es nula).
Si a la estrella le vamos añadiendo más y más puntas......habrá demasiadas dimensiones y si no le añadimos, no podremos desgranar la información que queremos. Sera esta la regla básica?.
Con independencia de la existencia de metodologías que te pueden servir para abordar un proyecto de Data Warehouse, voy a contestarte desde el punto de vista práctico y sin meternos que charcos demasiado grandes para ti u otras personas.
¿Trucos? Pues si existen. Fruto de años de participar en este tipo de proyectos, uno poco a poco va aprendiendo cositas y las aplica en el beneficio de los clientes. Sobre tu pregunta sobre un sistema para diseñar un OLAP, solamente existe un truco: escuchar bien las necesidades de los usuarios finales (ojo, no cualquier charlatán que piense tener bien claras las ideas), intentar obtener que tipo de requerimientos desean, informes tipo y cualquier concepto de negocio necesario. Tras obtener todo esto, es cuando nuestro trabajo tiene más fuerza. Si hemos entendido bien los conceptos y las necesidades podremos diseñar un buen modelo, de lo contrario no haremos nada bueno.
Un modelo debe poder controlar correctamente el negocio y éste lógicamente tiene variaciones con los años. Magia no podemos hacer y lógicamente si estamos montando un sistema de BI para un taller, no vamos a controlar que mañana decidan vender también coches o por lo menos no a priori. Pero si es lógico pensar en las piezas son suministradas por proveedores y que estos pueden cambiar con cualquier tipo de frecuencia, que los precios de coste y los de venta también, que existirá un stock de las piezas, etc… Este tipo de cosas, y muchas más, son aquellas que obtienes con la experiencia y que en ningún sitio podrás aprenderlas, siendo por lo que muchos de nosotros tenemos un determinado “caché” o salario.
Sobre tu segunda pregunta… las puntas de la estrella. Bueno de forma muy básica, por el momento y hasta nuevas preguntas, existen dos tipos básicos de estructuras (y combinaciones) las estrellas y el copo de nieve. Si nos ponemos a dar un charlón de cátedra demostraríamos que son la misma cosa, pero tratadas o almacenadas diferente.
Uno puede añadir tantas dimensiones como quiera o como pueda, el secreto es más bien saber que es una dimensión. Pues haciendo bien las dimensiones y para un grupo de métricas a analizar no saldrán muchas, en caso contrario estoy convencido de que tienes un error de concepto en algún sitio.
Según teorías de libro, si tienes más de 10 dimensiones el usuario final del sistema empieza a tener problemas para saber intepretar la información y en función del tipo de BBDD que utilices puedes empezar a encontrar limitaciones. No es lo mismo ir contra un gestor relacional, que contra una multidimensional propietaria, que contra alguna BBDD orienta a objetos.
La grandeza de un modelo, por hacerlo entendible, está en la capacidad de cruce de sus distintas estrellas.
Un último ejemplo que creo ilustrativo, siempre lo uso en mis Master. Una estructura o estrella es como la cabeza de un ciervo.
Si a la estrella le vamos añadiendo más y más puntas......habrá demasiadas dimensiones y si no le añadimos, no podremos desgranar la información que queremos. Sera esta la regla básica?.
Con independencia de la existencia de metodologías que te pueden servir para abordar un proyecto de Data Warehouse, voy a contestarte desde el punto de vista práctico y sin meternos que charcos demasiado grandes para ti u otras personas.
¿Trucos? Pues si existen. Fruto de años de participar en este tipo de proyectos, uno poco a poco va aprendiendo cositas y las aplica en el beneficio de los clientes. Sobre tu pregunta sobre un sistema para diseñar un OLAP, solamente existe un truco: escuchar bien las necesidades de los usuarios finales (ojo, no cualquier charlatán que piense tener bien claras las ideas), intentar obtener que tipo de requerimientos desean, informes tipo y cualquier concepto de negocio necesario. Tras obtener todo esto, es cuando nuestro trabajo tiene más fuerza. Si hemos entendido bien los conceptos y las necesidades podremos diseñar un buen modelo, de lo contrario no haremos nada bueno.
Un modelo debe poder controlar correctamente el negocio y éste lógicamente tiene variaciones con los años. Magia no podemos hacer y lógicamente si estamos montando un sistema de BI para un taller, no vamos a controlar que mañana decidan vender también coches o por lo menos no a priori. Pero si es lógico pensar en las piezas son suministradas por proveedores y que estos pueden cambiar con cualquier tipo de frecuencia, que los precios de coste y los de venta también, que existirá un stock de las piezas, etc… Este tipo de cosas, y muchas más, son aquellas que obtienes con la experiencia y que en ningún sitio podrás aprenderlas, siendo por lo que muchos de nosotros tenemos un determinado “caché” o salario.
Sobre tu segunda pregunta… las puntas de la estrella. Bueno de forma muy básica, por el momento y hasta nuevas preguntas, existen dos tipos básicos de estructuras (y combinaciones) las estrellas y el copo de nieve. Si nos ponemos a dar un charlón de cátedra demostraríamos que son la misma cosa, pero tratadas o almacenadas diferente.
Uno puede añadir tantas dimensiones como quiera o como pueda, el secreto es más bien saber que es una dimensión. Pues haciendo bien las dimensiones y para un grupo de métricas a analizar no saldrán muchas, en caso contrario estoy convencido de que tienes un error de concepto en algún sitio.
Según teorías de libro, si tienes más de 10 dimensiones el usuario final del sistema empieza a tener problemas para saber intepretar la información y en función del tipo de BBDD que utilices puedes empezar a encontrar limitaciones. No es lo mismo ir contra un gestor relacional, que contra una multidimensional propietaria, que contra alguna BBDD orienta a objetos.
La grandeza de un modelo, por hacerlo entendible, está en la capacidad de cruce de sus distintas estrellas.
Un último ejemplo que creo ilustrativo, siempre lo uso en mis Master. Una estructura o estrella es como la cabeza de un ciervo.
La cabeza es la tabla de hechos a analizar, la cual contiene todas las métricas necesarias. Cada cuerno es una dimensión, en el ejemplo del ciervo 2 dimensiones. Lo cual implica que dentro de cada cuerno existen muchas ramificaciones pero no por ello son otras dimensiones. Siguiendo con el ejemplo, las dimensiones nunca se tocan entre sí. El único punto en común entre ellas son las tablas fact.
Hasta pronto.
Chema Arce.
No hay comentarios:
Publicar un comentario