La primera vez que estaba haciendo algo parecido a BI, la dimensión tiempo se generaba a partir de un campo de tipo datetime en la tabla de hechos. Para ese entonces estaba empleando Cognos y era lo único que necesitaba para generar la jerarquía, con todos los niveles e inclusive los típicos acumulados por año, mes, trimestre, etc.

No obstante, es mucho más útil tener una verdadera dimensión tiempo definida y cargada en el datawarehouse, lo cual, genera algunas dudas como ¿de dónde la cargo?, ¿cada cuánto la actualizo?, ¿qué atributos incluyo?, ¿cuál nivel de granularidad? Entre otras.

Y si a eso se le suma complejidad que podría presentar el tener una implementación en varios husos horarios o el hecho de que sea multilenguaje. Todos estos factores deben ser tomados en cuenta desde el inicio del diseño del datawarehouse.

Un parámetro básico del cual se puede partir para obtener los primeros atributos de la dimensión es considerar todos aquellos datos que podemos derivar desde el motor de base de datos. Para el caso particular de Microsoft SQL Server, todo lo que se puede obtener de la función datepart (mes, año, día, nombre de mes, etc.).

Independientemente al tipo de arquitectura o diseño empleado, hay un aspecto fundamental: el campo llave inteligente. Cruzar datos desde la tabla de hechos y la dimensión tiempo vía un valor date o datetime sería sumamente costoso. Por ende, debe realizarse un trabajo en el procesamiento de la dimensión (tiempo de ejecución ETL), en el cual se crea una llave especial para cada registro de esta dimensión. Por ejemplo, un registro con fecha 27-ene-2010, deberá tener como llave para el cruce con la tabla de hechos a un número entero, a saber: 20100127. También puede usarse la notación tipo offset, como la que emplea Microsoft Excel, en la cual la fecha se representa como la cantidad de días pasados desde el 01 de enero del año 1900. En cualquiera de los dos casos, un join con números enteros será mucho más eficiente que una operación comparativa con datetimes o dates.

Tipos de Calendarios

Hasta el momento no se ha profundizado sobre el tipo de calendario que se empleará. Para un diseñador sería mucho más fácil que toda organización que implementa una solución BI/DW cuente con un calendario de actividades uniformes, no obstante, eso está muy lejos de la realidad.

Las variantes generalmente son de dos tipos:

  • En granularidad
  • En distribución del tiempo

En el primer caso se tienen que tomar decisiones sobre cuál es la unidad de tiempo más pequeña en el DW. Día suele ser una buena decisión, pero algunas compañías, como telecoms, probablemente necesitarán realizar consultas con ventanas de tiempo más pequeñas, como minutos e inclusive segundos. Acá es donde el arquitecto debe encontrar el equilibrio entre rendimiento y funcionalidad. Mientras más pequeña sea la unidad de tiempo, mayor volumen de datos. Un día tiene 86400 segundos, así que un año con granularidad al segundo, contará con más de 31 millones de registros.

En el segundo caso, el problema radica en que la organización no emplea el calendario natural o Gregoriano para registrar sus transacciones. Se presenta comúnmente en empresas de manufactura, en las cuales los ciclos de producción están representados por 4 semanas (28 días) y el año cuenta con 13 periodos. Por ende, hay que personalizar la dimensión tiempo o bien crear las equivalencias en cada registro.

Ejemplo: diseño básico de dimensión tiempo

Supóngase que se tiene una empresa de producción. Por razones corporativas, todas las operación de la planta se basan en ciclos de 4 semanas y se agrupan en periodos. El año cuenta con 13 periodos y no siempre comienza el mismo día. El primer día del año 2010 comenzó el 28 de diciembre de 2009. Todos los reportes de producción, manufactura y logística deben ser realizados tomando en cuenta este calendario.

Por otro lado, los departamentos financieros y administrativos, realizan los cortes mensuales con base en el calendario Gregoriano o natural. Es de suma importancia determinar cuáles son los últimos días de mes, natural o corporativo, ya que se dan picos de actividades propias del negocio.

¿Cómo quedaría el diseño de esta dimensión?

En la imagen adjunta se aprecia un diseño, no exhaustivo, pero representativo de los campos básicos para crear una dimensión tiempo que cumpla con los requisitos de análisis, tanto para la perspectiva del usuario que emplea el calendario natural, como aquel que emplea el calendario corporativo.

Nótese que se incluyeron campos que indican si se encuentra en el último día de mes o si es feriado. Así como también la dualidad entre el calendario natural y el calendario corporativo.

La forma más práctica de llenar esta tabla es a través de un script de SQL o bien, sentarse algunas horas frente a una hoja electrónica y llenar manualmente cada campo, cosa poco remomendada y propensa a muchos errores.

En caso de que se usaran otros lenguajes, es probable que existiesen campos adicionales con los captions respectivos para cada uno de ellos.

Por último, si se cuenta con transacciones en más de un huso horario, es común incorporar una hora corporativa y una hora local en los registros de la tabla de hechos para ubicar correctamente en el tiempo el evento.

Anuncios