데이터웨어 하우스 디자인 : 결합 된 날짜 시간 차원 대 별도의 요일 및 시간 차원 및 시간대

새로운 데이터웨어 하우스를위한 디자인을 시작하고 있으며 날짜 및 시간 차원의 작동 방식을 디자인하려고합니다. 여러 시간대 (아마도 GMT, IST, PST 및 EST)를 지원할 수 있어야합니다. 우리는 처음에 15 분의 세분화까지 하나의 넓은 결합 날짜 시간 차원을 가질 것이라고 생각했습니다. 이렇게하면 팩트 테이블에 하나의 키가 있고 지원되는 모든 시간대에 대한 모든 다른 날짜 시간 데이터가 하나의 차원 테이블에 있습니다. (예 : 날짜 키, GMT 날짜, GMT 시간, IST 날짜, IST 시간 등)

Kimball은 테이블이 너무 커지는 것을 방지하기 위해 시간 차원과 별도의 일 차원을 가질 것을 제안합니다 (데이터웨어 하우스 툴킷 p. 240). 우리는 지원해야합니다 (하나는 날짜와 하나는 시간).

내가이 분야에서 매우 경험이 없기 때문에 누군가가 두 가지 접근 방식, 즉 다른 표준 시간대 키의 성능과 관리 간의 상충 관계를 알고 있기를 바랍니다. 어쩌면 다른 접근법도있을 수 있습니다. 시간대마다 팩트 테이블에 별도의 행을 갖는 것에 대해 이야기하는 사람들이 있지만 실제로 팩트 테이블이 수백만 행이면 시간대를 추가하기 위해 4 배로 늘려야하는 것처럼 보입니다. .

우리가 15 분 곡물을 수행하면 날짜 시간 차원 테이블에 연간 131,400 (24 * 15 * 365) 행이있어 성능이 너무 무섭지 않지만 테스트 할 때까지 확실하지 않습니다. 프로토 타입 쿼리. 팩트 테이블에 별도의 표준 시간대 키가있는 다른 문제는 쿼리가 원하는 표준 시간대를 기준으로 차원 테이블을 다른 열에 조인해야한다는 것입니다. 아마도 SSAS가이를 처리하는 것일 수도 있습니다. 확실하지 않습니다. .

어떤 생각에 감사합니다, -Matt

날짜와 시간을 분리하면 시간별로 집계를 훨씬 쉽게 수행 할 수 있습니다. 예를 들어, 하루 중 가장 바쁜 시간대를 찾기 위해 쿼리를 실행하려는 경우. 이것은 별도의 시간 차원을 사용하여 훨씬 쉽게 수행됩니다.

또한 하나의 타임 키가 있어야합니다. GMT / EST 시간을 결정한 다음 팩트 테이블에서이를 사용하십시오. 다른 시간대를 기준으로 보고서를 실행해야하는 경우 응용 프로그램이나 쿼리에서 변환하십시오.

여러 표준 시간대를 지원하고 가능한 효율적으로 DataWarehouse를 구현하기로 결정한 방법에 대한 후속 조치 : "표준 시간대뿐만 아니라 표준 시간대 테이블 (ID, 이름 등)을 작성하기로 선택했습니다. 브리지 "테이블은 다음과 같습니다.

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

이렇게하면 일반적인 날짜 및 시간 차원 테이블을 작게 유지할 수 있으며 모든 사실은 UTC 날짜 / 시간 키에 연결됩니다. 다른 시간대로보고 / 그룹화 해야하는 경우 시간대 브리지 테이블을 통해 조인해야합니다. 로컬 날짜 / 시간 키를 날짜 및 시간 차원 테이블에 다시 연결하십시오. SSIS에서 호출 된 C # 코드를 사용하여 표준 시간대 브리지 테이블을 채 웁니다. 이는 SqlServer에서 직접 TZ 작업을 수행하는 것보다 훨씬 덜 복잡하기 때문입니다.

결합 된 DateTime차원이 거부 된 창고에 대한 아이디어는 거부되었지만 그 이유를 알 수 없었습니다. 약간 단순화하면 다음은 현재 구축중인 팩트 테이블입니다.

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
)

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)),
...
)

이것은 30 분의 1 초의 해상도로 하루에 48 개의 레코드, 20 년 동안 350,400 개의 레코드가 있습니다.

이벤트 날짜 / 시간은 저장 될 때 UTC로 변환되지만 LocalTimeZoneSK필드와 브리지 테이블을 사용하면 현지 시간을 얻기 위해 쉽게 조인 할 수 있습니다.

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

오늘 UTC로 생성 된 트랜잭션을 가져 오려면 다음을 수행하십시오.

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

거래를 위해 현지 시간으로 오늘 거래를 만들려면 :

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'

당신은 대체하여 단순화 것들에 유혹 할 수있다 TimeZoneSK와 REAL오프셋 (예를 들어, -5.0 미국 중부 일광 절약 시간에 대한)하지만, 사실 레코드의 일부 날짜 / 시간이 일광 절약 시간에 일부가 아닌 경우이 분해됩니다.

팩트 레코드에 대한 이벤트가 선적 또는 항공편과 같은 다른 시간대에서 발생할 수있는 경우 각 날짜에 대한 시간대 필드가 필요하며 날짜 당 최대 5 바이트입니다.