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.
