먼저 ...
차원과 차원 Datime/Time으로 분리 하는 것이 확실합니다.DateTime
당신이를 복제 할 필요가있는 복수 시간대를 관리하려면 DateKey하고, TimeKey그래서 당신은 다음을 가지고 :
LocalDateKeyLocalTimeKeyUtcDateKeyUtcTimeKey
당신은 말합니다 ...
내가 가진 모든 문제는 UTC + 2 이후의 모든 시간대에서 2013 년 12 월 31 일 화요일 오후 11시 (UTC)입니다 .2014 년 1 월 1 일 수요일입니다.
위에 나열된 4 개의 열이 있으면 테이블 별칭을 사용하여 팩트 테이블을 날짜 및 / 또는 시간 차원에 조인 할 수 있습니다 (Kimball 용어에서는 이러한 별칭이 지정된 차원 테이블을 "역할 재생 차원"이라고 함). 다음과 같은 것이 있습니다.
/*
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
닫는 중 ...
당신은 OLTP 데이터베이스를 데이터 마트를 구축하고,하지 않을 때, 로컬 및 UTC 시대의 생성은 당신의 ETL 수행해야한다 , 하지 떨어져에 UTC 시간의 현지화에서 (다음과 같은 이유로 모든 클라이언트 측 애플리케이션에 보고서 독자의 관점) :
- 계산이 모든 쿼리에 상주하면 보고서에 대해 해당 쿼리를 실행해야하는 횟수를 곱한 결과에 추가 성능 부담이 발생합니다 (수백만 행을 읽을 때 중요 함).
- 각 쿼리에서 계산을 올바르게 유지해야하는 추가 부담 (특히 일광 절약 시간을 고려할 때)
- 열에 대한 계산을 수행 할 때 쿼리가 탐색 대신 인덱스 스캔을 수행하도록하는 열에 대한 계산을 수행하므로 열에 대한 범위 스캔을 방지하십시오 (일반적으로 각 데이터 페이지를 읽어야 할 때 더 비쌉니다). 이는 것으로 알려진 비 스 SARGable .
- 주석으로 인해 편집 : 변환을 실제 쿼리 로 푸시 할 경우 적용됩니다 .
- 추가 UTC 날짜 및 시간을 사용할 수 있다는 개념을 사용하면이 개념을 취하고이를 확장하여 확장 할 수 있습니다
StandardisedDateKey. 또는 CorporateHQDateKeyUTC 날짜 테이블 대신 다른 비즈니스 계약 표준에 따라 표준화합니다.
- 두 개의 개별 열 유형 (로컬 및 UTC)을 사용하면 지리적 거리에서 나란히 비교할 수 있습니다. 생각 - 호주에서 누군가가 로컬 및 UTC 모두 소인이되는 기록을 입력>, 뉴욕에서 누군가가 지역 (호주) 날짜와 시간에 보고서를 읽어 와 UTC 날짜와 시간의 뉴욕 표현을하여 뭔가를보고 그들의 호주인은 하루 중 (오스트레일리아)에 한밤중에 (뉴욕 시간) 일을했습니다. 다국적 기업에서는 이러한 시간 비교가 필수적입니다.