En líneas generales podemos observar en todas la tablas la misma estructura, un código genérico según concepto, su descripción genérica y un atributo denominado Level. Todo un invento por aquellos años.Creo que para muestra y coger la idea es bastante con la siguiente explicación. Supongamos que tenemos la necesidad de meter los datos desde el 1999 al 2002, con todos sus meses y días, u otros niveles intermedios. Pues el resultado de dicha tabla sería:
Codigo Descripción Level
01 1999 1
02 2000 1
03 2001 1
04 Enero 2
05 01/01/1999 3
06 2002 1
07 Febrero 2
09 Marzo 2
10 27/05/2003 3
En definitiva lo importante es ver como el campo level es el que nos proporciona información sobre el nivel jerárquico dentro de la dimensión, de tal forma que si queremos ver las ventas por meses deberíamos filtrar por el level del tiempo con valor igual a 2. Si deseamos ver las ventas por días, el filtro del tiempo debería ser 3, etc.
Tengamos en cuenta que en aquellos años no teníamos unas herramientas como las actuales y el “interrogatorio” lo hacíamos los informáticos y eran unos buenos intentos para satisfacer las demandas.
Lógicamente tenían ciertas ventajas y ciertos inconvenientes, pues imaginar lo complejo que es preguntas por las ventas de un determinado producto, en un momento en el tiempo y en un centro determinado. La sentencia SQL tiene level por todos los lados y además las condiciones restrictivas. Lo dicho tenían muchos problemas, algunos de los cuales los siguiente teniendo las estrellas de hoy en día… ya llegaremos. Pero el principal problema era que dichos modelos y su explotación eran imposibles dejarlos en manos de los usuarios finales.
Bueno simplemente eran otros tiempos, daremos un próximo paso en nuestra evolución…
Preguntas y comentarios recibidos:
Sergi pregunta: Indicadores contenidos en la Fact Table precio_unidad y coste_unidadSon propios del producto, ¿Por qué no se representan dentro de la dimensión Producto?, ¿Qué motivos de peso hay para romper la 3 forma normal?.
Respuesta: Tal y como adelante, el objetivo del modelo (ejemplo) solamente trata de haceros ver como hace años, finales de los ochenta, muchas personas ya se rompian la cabeza para intentar montar algo para poder analizar la información de forma más agil.
Estos temas los veremos en los siguientes modelos. En cualquier caso, efectivamente el precio unidad y el coste, logicamente deberian ir asociados al producto, pero no dentro de la dimensión producto (o no de forma normal), pues dichos valores varian con el paso del tiempo, basicamente podemos diseñar versionning (algo coñado y dificil de manejar para un simple usuario) o montar una fact especifica, ya veremos que es lo más conveniente.
Bueno en el modelo propuesto, es más que discutible si hemos roto o no la tercera forma. Pues a un simple vistazo tenemos unas tablas con codigo y descripción, siendo esa primary key la clave foranea de la tabla de hechos, el atributo level es un artilugio informatico, al igual que un flag u otra cosa.
Pero te adelanto que en este caso el fin justifica los medios, en DW lo normal es la desnormalización... poco a poco.
Sergi pregunta: Pongamos por caso que un determinado producto no se vende nunca, ¿Cómo podemos saber su precio unitario y el coste por unidad?
Respuesta: Buena observación y buen analisis del modelo. En la mini estructura propuesta, que repito que no tiene nada que ver con lo que haremos, solamente estariamos "procesando" las ventas, por lo tanto sin venta no habría otros datos. Estas en lo cierto.
Dimensiones genéricas (Aglutinación de niveles)
Aquí vengo a hacerte una propuesta, pero primero desarrollo el problema.
Sergi pregunta: Al tener una aglutinación de niveles, la Fac. table debe almacenar datos con diferente nivel de granularidad y NO siempre todos los indicadores son agregables, así mismo este hecho hace crecer el volumen de datos de la Fact Table.
Respuesta: Efectivamente este modelo, para bien y para mal, permite este tipo de cosas. Lo cual obliga que en función del nivel del dato guardado en la table fact, existan valores vacios en algunas métricas. Posiblemente este y otras cosas, que supungo que detectarán el resto de lectores, han propiciado que hace años no se usen este tipo de modelos. Además el tema de datos aditivos son conceptos que practicamente han aperecido con el uso de herramientas DSS/EIS actuales (desde principios de los 90).
Sergi pregunta o propone: Por eso yo te propongo lo siguiente, la clave de las dimensiones debe ser explicativa NO subrogada, es decir te estoy pidiendo que rompas la segunda forma normal en pedazos y en algunos casos la primera permitiendo así las Fully Functional Dependencies.
Generar una clave explicativa y única, y que aparte sea numérica es posible ya que para cualquier conjunto finito es posible generar una bijeccion con los naturales.
Pero tal vez quede más claro con el siguiente ejemplo, la dimension de tiempo almacenará como clave el número yyyymmdd es decir el primeo de enero de 2006 se expresará 20060101 y el 31 de diciembre 20061231. únicamente almacenaremos el mínimo nivel de detalle, pero este contendrá ya la información de los niveles superiores.
Por ejemplo para consultar las ventas del año 2006 el where podría ser…
WHERE id_tiempo between 20060000 and 20069999;
Para consultar las ventas de enero...
WHERE id_tiempo between 20060100 and 20060199;
Respuesta: A la primera parte de tu propuesta comentarte que llegaremos a otras formas de hacer las cosas, pues por eso hemos avanzado en estos años. El tema de las claves, que detecto que tanto os gusta a todos, no es un tema tan alegre el cual se pueda definir sin ver un ejemplo real, el tipo de clave, si estan o no codificadas, si las claves pueden ser reutilizadas, etc... Seguro que más adelante sale el tema y podemos debatir a nuestro gusto.
Sobre el ejemplo que propones para del desarrollo de una dimensión temporal, decirte que es completamente necesario disponer de todas las claves y ser muy escrupuloso con ellas, pues imagina unas consultas como las que propones sobre un DW de telco, los cuales tienen tablas fact de muchos millones de registro, el sistema lo dejarias colapsado y veriamos si responde. Las consultas deben salir por claves, excepto con DB2 lo ideal es que sean numericas, pues de lo contrario adios al tiempo de respuesta, tambien muy importante el uso de indices (otro mundo), pero consultas por cadenas o "between 20060100 and 20060199" se me antojan muy pesadas.
En cualquier caso, la curiosidad me puede. La proxima vez que este en uno de mis clientes gordos, intentare lanzar una query de ese tipo...
Saludos y muchas gracias por compartir tus ideas y comentarios... esperamos a los demas y sus aportaciones.
3 comentarios:
Me quedo impresionado de la cantidad de análisis que haceís sobre un modelo, ‘supuestamante’ sencillo. Se nota que le daís vueltas al tema, cosa muy importante cuando es están modelizando datos y de que las cosas casi nunca son tan fáciles como parecen.
Sólo añado un par de comentarios
1)No sé si me pasa a mi sólo, pero el jpg se ve regular, aunque miraré si es un problema mío.
2)Totalmente de acuerdo, en que una consulta del tipo “between 20060100 and 20060199” puede no terminar nunca en una tabla de hechos de un DW grandecito. Cambiaría la sintaxis y buscaría una estrategia de particionamiento (pienso en Oracle) adecuada, cuyas consultas se redireccionen inmediatamente a particiones no muy grandes. Otro tema por supuesto son los índices.
3)Siempre me ha parecido difícil de resolver el tema de las vigencias en las dimensiones, supongo que es a lo que os referís cuando hablaís de versioning.
He visto diferentes soluciones para este tipo de problemas: Me sorprendió mucho una solución que ví, de la que dudaba mucho en un principio. Ejemplo: Dimensión producto, suponiendo que sólo estamos interesados en conocer la vigencia a nivel de mes (aaaamm), ya que el mes es nuestra unidad de análisis temporal. He visto dimensiones como la de producto a las que se le añade el campo aaaamm y se replica el registro para el rango aaaamm_ini -> aaaamm_fin en el que esté vigente el producto. Las dimensiones se multiplicaban de volumen, pero el tiempo de análisis (informes) apenas se vió penalizado. Me llamo bastante la atención, la herramienta de explotación era Microstategy y se trataba de un modelo hechos-dimensiones en estrella.
Lógicamente el tema se complica mucho si tu unidad temporal es el día y las vigencias llegan a nivel aaaammdd.
Juan Vidal
Uhmm, este primer modelo, como dices Jose María, recuerda mucho a lo que a veces encontramos por ahí, al menos en mi caso, y es que un diseñador de bbdd operacionales, aplica un poco de sentido común, y crea casi sin querer un modelo dimensional.
Eso sí,sin jerarquias, SCD´s y ese tipo de cosas.
En cuanto a los comentarios de Sergi, al de los productos y precios unitarios de productos no vendidos, si hiciesemos una fact con los productos y sus precios, tendríamos todos los productos vendidos o no que debemos controlar.
Yo creo, así por encima que todos los datos de la tabla son aditivos...si estuviesen en dos tablas.
Lo unico que para unos la funcion de agregacion sería sum (unidades vendidas, subtotal, etc..) y otras avg (o max o min) (coste, precio). En cualquier caso al no tener jerarquias, yo creo que la agregacion (entendida a lo multidimensional) no tiene mucho sentido. Otra canción es si lo hacemos a base de sql, para reporting o para un Cuadro de Mando.
En cuanto a la clave, aqui los manuales dicen siempre que nada de claves inteligentes, que mejor integers secuenciales, que se mejoran rendimientos, se indexan, etc... La verdad es que en ocasiones el hacer la clave con el timestamp de la carga (en la dimension tiempo, se entiende) es superior a las fuerzas de gestionar
un sistema de claves surrogadas, jejejejje.
Muy bien, muy bien, entramos en calor.....
Hola,
Jose María, ¿no sigues adelante con esta iniciativa?.
La verdad es que era muy interesante.
Espero que siga.
Ánimo!
Un saludo.
Publicar un comentario