La dimensión de tiempo existe habitualmente en cada data warehouse y la granularidad más usada es el día. Generalmente tiene muchos atributos pero solo algunos de estos atributos como por ejemplo el nombre del mes y el año pueden ser obtenidos fácilmente usando una expresión SQL aplicada a la fecha. Si la dimensión tiene atributos para dar soporte a múltiples lenguajes resulta a veces complicado construirla con el lenguaje SQL. Otros atributos no se pueden obtener mediante SQL ya que no hay mecanismos predecibles y dependen de decisiones humanas.

Otra característica de la dimensión tiempo es que suele tener muchos atributos como por ejemplo marcas de días feriados o no laborables, atributos de períodos fiscales o de temporadas, atributos relacionados a la fecha como el número de semana, la marca de último día del mes, y otros atributos muy útiles usados especialmente para la navegación y que deben estar integrados en la dimensión fecha mediante atributos dimensionales.

La gran ventaja de esta dimensión es que está completamente definida y especificada desde el inicio del proyecto del data warehouse. Pero la desventaja es que no tiene una fuente de datos convencional sino que se suele generar mediante algún mecanismo como una planilla o tabla cargada manualmente o mediante algún proceso.

La clave de la dimensión fecha

Todas las dimensiones fecha necesitan un atributo que representa a la fecha y un atributo para relacionar con la tabla de hechos. Debe haber al menos un registro que permita representar situaciones especiales como una fecha no aplicable o no informada o que no ha ocurrido aún y además es posible que desee distinguir varias de estas condiciones inusuales.

En estos casos en que se deben representar hechos relacionados a estas “fechas especiales”, las referencias foreign key en la tabla de hechos deben permitir referenciar a estos registros con “fechas inusuales” en la tabla de la dimensión fecha. Recordemos que el valor de estos atributos en los campos de la tabla de hechos no puede ser nulo, ya que debe estar relacionado con la tabla de la dimensión tiempo.

La clave principal de la dimensión fecha ideal debería ser una clave subrogada sin representación semántica, como por ejemplo un numero entero (que no representa una fecha), pero muchos diseñadores no pueden resistir la tentación de hacer que la clave sea legible como por ejemplo 20101116 significando el 16 de noviembre de 2010. Sin embargo, como con todas las claves inteligentes, los pocos registros especiales en la dimensión fecha harán que el diseñador utilice trucos para representarlas. Por ejemplo, la clave inteligente para una fecha “no aplicable” tendría que ser un valor sin sentido como por ejemplo 99999999, y esto trae aparejado que las aplicaciones que tratan de interpretar la fecha directamente para obtener información (como por ejemplo el mes) sin usar los atributos de la dimensión tengan inconvenientes porque no es una fecha válida.

Conclusión

En definitiva utilizar un tipo de dato fecha para el atributo clave de la dimensión fecha no es una buena elección y conviene que el valor este subrogado utilizando una clave entera que está oculto al usuario dentro de la meta data. El atributo representativo de la fecha debe ser un atributo que acepte representaciones especiales y no solamente representación de fechas válidas.

Referencia:

[PDF] Kimball Design Tip #51: Latest Thinking On Time Dimension Tables

http://www.kimballgroup.com/2004/02/design-tip-51-latest-thinking-on-time-dimension-tables/

Categorías: Data Warehouse

Dejá un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *