Manejo de zonas horarias en data mart / warehouse

Estamos comenzando a diseñar los bloques de construcción de un data mart / warehouse y necesitamos poder admitir todas las zonas horarias (nuestros clientes son de todo el mundo). Al leer las discusiones en línea (y en los libros), una solución común parece ser tener una dimensión de fecha y hora separada, así como una marca de tiempo en las tablas de hechos.

Sin embargo, la pregunta que me cuesta responder es ¿de qué me sirven las dimensiones de fecha y hora teniendo en cuenta mis requisitos de zona horaria dinámica? Una dimensión de tiempo tiene un poco más de sentido, pero estoy teniendo dificultades con la dimensión de fecha. Un enfoque de diseño general para una dimensión de fecha generalmente incluye propiedades como el nombre del día, el día de la semana, el nombre del mes, etc. El problema que tengo con todo eso es que las 11:00 PM del martes 31 de diciembre de 2013 en UTC es el miércoles , 1 de enero de 2014 en todas las zonas horarias posteriores a UTC + 2.

Entonces, si tendré que hacer todas estas conversiones de zona horaria en todas y cada una de las consultas (e informes), ¿cuál es el punto de tener y almacenar estas propiedades que probablemente nunca usaré (parece)? Algunas personas sugieren tener filas de hechos para cada zona horaria, pero eso me parece ridículo. Necesitamos poder almacenar millones de registros cada mes.

Otros sugieren tener una tabla de puente de zona horaria que, aunque tiene algo de sentido, también parece una complejidad adicional y uniones adicionales para lograr algo que mis aplicaciones e informes de clientes deberían poder resolver fácilmente a partir de una fecha (los informes se basarán principalmente en la web donde hay una gran cantidad de bibliotecas para ayudar a convertir, mostrar y formatear fechas).

Lo único en lo que puedo pensar es en la facilidad y posiblemente el rendimiento de la agrupación por fecha y hora, pero cuán mala es agrupar por fecha (estamos usando MS SQL pero consultaremos millones de filas) o deberíamos considerar solo dimensiones de fecha y hora extremadamente simples con no mucho más que números de hora, día, mes y año en su mayor parte, ya que la mayoría de los literales como el lunes no significarían mucho cuando las zonas horarias entren en juego.

Primeramente...

Separarse Datime/Timeen una Datedimensión y una Timedimensión es definitivamente el camino a seguir.

Para administrar varias zonas horarias, debe duplicar DateKeyy TimeKeypara que tenga lo siguiente:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

Tu dices...

El problema que tengo con todo eso es que las 11:00 PM del martes 31 de diciembre de 2013 en UTC es el miércoles 1 de enero de 2014 en todas las zonas horarias posteriores a UTC + 2.

Al tener las 4 columnas que he enumerado anteriormente, podrá unir la tabla de hechos a la dimensión de Fecha y / o Hora Usando Alias ​​de Tabla (en la terminología de Kimball estas tablas de dimensión con alias se conocen como "Dimensiones de Juego de Rol"), por lo que tendrías algo como lo siguiente:

/*
    Assumes the following:
        - [DateLongName] has the format of this example "Tuesday, December 31, 2013"
        - [TimeShortName] has the format of this example "11:00 PM"
        - Both [DateLongName] & [TimeShortName] are strings
*/
select
    -- Returns a string matching this example  "11:00 PM Tuesday, December 31, 2013"
    localTime.TimeShortName + ' ' + localDate.DateLongName
    ,utcTime.TimeShortName + ' ' + utcDate.DateLongName
    ,f.*
from
    FactTableName  AS f

    -- Local Date and Local Time joins          
    inner join dbo.Date  AS localDate
        on localDate.DateKey = f.LocalDateKey

    inner join dbo.Time  AS localTime
        on localTime.TimeKey = f.LocalTimeKey 

    -- Utc Date and Utc Time joins    
    inner join dbo.Date  AS utcDate
        on utcDate.DateKey = f.UtcDateKey

    inner join dbo.Time  AS utcTime
        on utcTime.TimeKey = f.UtcTimeKey 

Para concluir...

A medida que crea un data mart, y no una base de datos OLTP, la generación de los tiempos Local y Utc debe realizarse en su ETL , NO en ninguna aplicación del lado del cliente por las siguientes razones (aparte de la localización del tiempo UTC al informe de la perspectiva del lector):

• Hacer que el cálculo resida en cualquier consulta supone una carga de rendimiento adicional para ellos, multiplicado por la cantidad de veces que tiene que ejecutar dicha consulta para cualquier informe que tenga (esto es importante al leer millones de filas)
• Carga adicional de garantizar que el cálculo se mantenga correctamente en cada consulta (especialmente cuando tiene en cuenta el horario de verano)
• Evite el escaneo de rango de cualquier índice del que forme parte la columna, ya que realizará un cálculo en la columna que obliga a las consultas a realizar escaneos de índice en lugar de búsquedas (que generalmente son más caras ya que cada página de datos se necesita para leer); Esto se conoce como no sargable .
  • Editar debido a comentarios: esto se aplica si empuja la conversión hacia abajo en la consulta real .
• Utilizando el concepto de tener las fechas y horas UTC adicionales disponibles, no hay nada que le impida tomar este concepto y extenderlo llamando a esto StandardisedDateKey, o CorporateHQDateKey, en lugar de una tabla de fechas UTC que estandarice en base a algún otro estándar acordado por la empresa
• Tener los dos tipos de columnas separadas (Local y UTC), permite la comparación lado a lado a través de la distancia geográfica. Piense:> alguien en Australia ingresa un registro que tiene una marca de tiempo con Local y UTC, alguien en Nueva York lee el informe con la fecha y hora Local (Australia) y la representación de Nueva York de la fecha y hora UTC, viendo así que algo su contraparte australiana sucedió durante la mitad del día (hora de Australia) sucedió en la mitad de la noche su hora (hora de Nueva York). Esta comparación del tiempo es indispensable en las empresas multinacionales.

Pido disculpas de antemano por la brevedad de esta respuesta y planeo elaborar cuando no estoy en el trabajo.

Sin duda, existen ventajas de tener tablas de fecha y hora, ya que permiten una fácil agregación de sus datos. En muchos casos, es la forma más sencilla de ordenar por mes o días hábiles cosas de esa naturaleza. Sin embargo, esto no necesariamente reemplaza la utilidad de una marca de tiempo. En su caso particular, una marca de tiempo UTC. Una vez que tenga esa marca de tiempo, todo lo que tiene que hacer es cambiarla a la hora local en la capa de informe o presentación. Para evitar escaneos de rango, asegúrese de convertir su rango de solicitud a la hora UTC también.

Si tiene alguna otra pregunta o comentario, no dude en preguntar.