Cuando estamos diseñando las estrellas o copos de nieve que formarán nuestro data warehouse, hay que tener mucho cuidado con la dimensión de tiempo. Hay varias formas de hacerlo y para mi gusto unas mejores que otras. La forma más común de encontrar es una en la que el campo llave es la fecha.
Aquí a la izquierda está el típico diseño. El problema aquí es que a las bases de datos les cuesta trabajo hacer búsquedas por campos datetime o date, al menos más que un campo entero. Otro punto es que el campo fecha ocupa más espacio que un campo entero. Hay que tomar muy en cuenta que el campo fecha, que es la llave, formará parte de la tabla de hechos; y con millones y millones de registros un byte o dos es mundo de espacio, tal vez un disco duro 
.
Podemos mejorar el diseño cambiando el campo llave por un campo entero como en la figura de la derecha. Esto hará que:
- las búsquedas sean más rápidas sobre todo en la tabla de hechos. Esto por que a las bases de datos les cuesta menos trabajo manejar números que fechas, o sea ocuparemos menos el procesador y ocuparemos menos memoria.
- Que el tiempo de respuesta sea más rápido. No es redundancia, este punto es una consecuencia de lo anterior.
- Que físicamente los datos ocupen menos espacio. De nuevo, el servidor trabaja menos con menor volumen de información y se requieren menos procesador y menos memoria o sea que la ganancia es doble.
En este diseño hay 2 corrientes, los que usan un numero consecutivo como llave y los que usamos un numero en el formato yyyyMMdd. Para mi gusto es muy frustrante encontrarse una estrella donde la llave de la tabla tiempo es un 1,2,3,4…34560,34561,….@#$%#$$% ¡para saber a que fecha corresponden el 34561!…pues hay que hacerle un query a la tabla de tiempo.
Yo prefiero de llave un numero con el formato yyyyMMdd, así para el 31 de diciembre del 2007 guardo 20071231 en el campo TiempoID, sigue siendo un numero entero y es mucho más legible que un simple 1-2-3. Con solo ver que valor tiene el campo TiempoID puedo saber a que fecha corresponde el registro. Además funciona perfectamente en el where con un between:
SELECT *
FROM HECHOS
WHERE TIEMPOID BETWEEN 20070101 AND 20070131
Hay un punto no tan visible con el campo llave: la tabla de hechos tiene índices para acelerar el tiempo de respuesta. Los índices ocupan espacios y si usamos un campo entero en vez de un datetime estaremos ahorrando espacio y haciéndole la vida más fácil al servidor.
En bases de datos pequeñas 1 a 10 gigas da lo mismo usar uno u otro. En bases de datos gigantes como las de grandes tiendas departamentales o tiendas de conveniencia donde la base de datos del data warehouse mide teras usar un campo entero es de vital importancia.
En otro post analizaremos los demás campos de la tabla de tiempo.
Para obtener un script para crear y llenar la tabla de tiempo dé clic aquí.
Technorati tags: Cubos, Rolap, Data Warehouse
[...] dimensión Tiempo. Los otros campos 3 07 2007 Continuando con la dimensión de tiempo, también están los otros campos que son muy importantes. Debemos considerar el campo Fecha que [...]
[...] tabla de tiempo 18 07 2007 Recuro muy seguido a este script de SQL para llenar mi tabla de tiempo. Casi siempre lo hago y lo vuelvo a hacer una vez al mes. Todavía no comprendo como no [...]
[...] El concepto de Estrella es bastante sencillo. Hay que diseñar las tablas usando una tabla central para los hechos, tablas para los los catálogos y una tabla de tiempo. [...]
Hola Adrian antes que nada felicitaciones por tu blog, he tomado muchas ideas interesantes que he aplicado, ya que estoy iniciando con este mundo de los cubos, ahora tomandote la palabra de pedirte una ayuda, con respecto a este mundo, tengo un problemita con un cubo que estoy diseñando en analisys services 2005, te resumo: tengo 5 tablas de hechos las cuales 3 tienen minimo 4 campos fechas, y pues elusuario quiere filtrar informacion a traves de esas fechas, por lo que se me ocurrio hacer dimensiones por cada fecha que me solicito como filtro el usuario, es decir no tengo una tabla fecha como la que aconsejas en tu articulo, sino que descompongo las fechas en 3 partes dia, mes y año, y suponiendo en una tabla tengo 2 fechas, serian 6 atributos mas, posteriormente , creo una dimension de tiempo, con cada una de esas fechas que dividi, y claro esta que tengo n dimensiones por cada fecha de filtro, ¿esto es factible o me podrias dar otra idea, o mas bien tu opion?, que la verdad la consideraria mejor, Gracias de antemano.
Hola Israel,
Pues me suena factible, pero me preocuparía que el usuario tendría todas esas combinaciones por filtrar, son demasiadas
Me imagino que tienes algo asi como fEcha pedido, fecha factura, fecha de embarque, fecha promesa de pago de donde el usuario podrá seleccionar información de esas fechas lo cual es completamente normal.
Se pueden crear n dimensiones fecha en un cubo de AS aunque tal vez no sea necesario partirlas en 3, tal vez con un solo campo fecha y sus respectivos padres semana, mes, año serías suficiente.
Es solo una opinión.
saludos
Que libros podrias recomendarme para leer sobre cubos de datos
Estoy haciendo un trabajo sobre cubos y me gustari saber si puedes recomendarme algunos libros sobre el tema.
Saludos y gracias
Cuantas Dimensiones de tiempo se puede tener en un solo cubo ??