Diseño de Datawarehouse: dimensión combinada de fecha y hora versus dimensiones separadas de día y hora y zonas horarias

Recién estamos comenzando a diseñar un nuevo almacén de datos y estamos tratando de diseñar cómo funcionarán nuestras dimensiones de fecha y hora. Necesitamos ser capaces de soportar múltiples zonas horarias (probablemente al menos GMT, IST, PST y EST). Inicialmente pensamos que tendríamos una dimensión de fecha y hora combinada amplia de hasta una granularidad de 15 minutos, de esa manera tenemos una clave en nuestras tablas de hechos y todos los datos de fecha y hora diferentes para todas las zonas horarias admitidas están en una tabla de dimensión. (es decir, clave de fecha, fecha GMT, hora GMT, fecha IST, hora IST, etc.)

Kimball sugiere tener una dimensión de día separada de la dimensión de hora del día para evitar que la tabla crezca demasiado (The data warehouse toolkit p. 240), lo que suena bien, sin embargo, eso significaría que tenemos dos claves en nuestras tablas de hechos para cada zona horaria necesitamos soporte (uno para la fecha y otro para la hora del día).

Como soy muy inexperto en esta área, espero que alguien conozca las compensaciones entre los dos enfoques, es decir, el rendimiento frente a la gestión de todas las diferentes claves de zona horaria. Tal vez también hay otros enfoques, he visto a algunas personas hablar de tener una fila separada en la tabla de hechos por zona horaria, pero eso parece un problema si las tablas de hechos son millones de filas, entonces debe cuadruplicarlo para agregar zonas horarias .

Si hacemos el grano de 15 minutos, tendremos 131,400 (24 * 15 * 365) filas por año en nuestra tabla de dimensiones de fecha y hora que no suena demasiado horrible para el rendimiento, pero no lo sabremos con seguridad hasta que probemos algunos consultas prototipo. La otra preocupación por tener claves de zona horaria separadas en la tabla de hechos es que la consulta debe unir la tabla de dimensiones a una columna diferente en función de la zona horaria deseada, quizás esto es algo que SSAS se encarga de usted, no estoy seguro .

gracias por cualquier pensamiento, -Matt

Tener la fecha y la hora separadas le permitirá hacer agregados por tiempo con mucha facilidad. por ejemplo: si desea ejecutar una consulta para encontrar qué período del día está más ocupado. Esto se realiza con mucha facilidad utilizando una dimensión de tiempo separada.

Además, solo debe tener una tecla de tiempo. Decida el horario GMT / EST, luego use esto en la tabla de hechos. Si necesita ejecutar informes basados ​​en la otra zona horaria, simplemente conviértalo en su aplicación o consulta.

Solo un seguimiento de cómo decidimos implementar nuestro DataWarehouse para admitir múltiples zonas horarias y ser lo más eficientes posible: elegimos crear una tabla de zonas horarias (id, nombre, etc.), así como una "zona horaria" puente "que se ve así:

time_zone_bridge
---------------
date_key_utc
time_key_utc
timezone_id
date_key_local
time_key_local

De esta manera, podemos mantener pequeñas nuestras tablas normales de dimensiones de fecha y hora, todos nuestros hechos se vinculan con las teclas de fecha / hora UTC, luego, si necesitamos informar / agrupar por una zona horaria diferente, solo tenemos que unirnos a través de la tabla puente de zona horaria y vincule las teclas locales de fecha / hora a las tablas de dimensiones de fecha y hora. Rellenamos nuestra tabla de puentes de zona horaria utilizando el código C # invocado desde SSIS, ya que esto era mucho menos complicado que hacer cosas TZ desde SqlServer directamente.

He visto DateTimerechazada la idea de un almacén utilizando una dimensión combinada , pero no he visto una razón muy clara por qué. Simplificando ligeramente, aquí está la tabla de hechos que estoy construyendo en este momento:

Transactions
(
...
CreatedDateTimeSK         INT NOT NULL,  -- Four bytes per date...
AuthorizedDateTimeSK      INT NOT NULL,
BatchSubmittedDateTimeSK  INT NOT NULL,
BatchApprovedDateTimeSK   INT NOT NULL,
SettlementDateTimeSK      INT NOT NULL,
LocalTimeZoneSK           TINYINT NOT NULL  -- ...plus one byte for the time zone
)

Los DateTimecampos se unen a una tabla DateTime:

DateTimes
(
DateTimeSK   INT NOT NULL PRIMARY KEY,
SQLDate      DATE NOT NULL,
SQLDateTime  DATETIME2(0) NOT NULL,
Year         SMALLINT NOT NULL,
Month        TINYINT NOT NULL,
Day          TINYINT NOT NULL,
Hour         TINYINT NOT NULL,
Minute       TINYINT NOT NULL CHECK (Minute IN (0, 30)),
...
)

Esto tiene una resolución de media hora, por lo que hay 48 registros por día, 350,400 en 20 años, bastante manejables.

La fecha / hora del evento se traduce a UTC cuando se almacena, pero con el LocalTimeZoneSKcampo y una tabla puente podemos unirnos fácilmente para obtener la hora local:

TimeZoneBridge
(
DateTimeSK       INT NOT NULL,
TimeZoneSK       TINYINT NOT NULL,
PRIMARY KEY (DateTimeSK, TimeZoneSK),
LocalDateTimeSK  INT NOT NULL
)

Para obtener transacciones creadas hoy, hora UTC:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN DateTimes AS CD ON T.CreatedDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

Para obtener transacciones creadas hoy, en hora local para la transacción:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN TimeZoneBridge AS TZB ON T.CreatedDateTimeSK = TZB.DateTimeSK AND T.TimeZoneSK = TZB.TimeZoneSK
  INNER JOIN DateTimes AS CD ON TZB.LocalDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

Puede tener la tentación de simplificar las cosas reemplazando el TimeZoneSKcon un REALdesplazamiento (por ejemplo, -5.0 para el horario de verano central de EE. UU.), Pero esto se desglosará si algunas fechas / horas para un registro de hechos están en el horario de verano y otras no.

Si los eventos para un registro de hechos pueden ocurrir en diferentes zonas horarias, como un envío o un vuelo, entonces necesita un campo de zona horaria para cada fecha, y tiene hasta cinco bytes por fecha.