การออกแบบคลังข้อมูล: มิติเวลาวันที่แบบรวมเทียบกับมิติและวันและเวลาที่แยกจากกัน

เราเพิ่งเริ่มออกแบบคลังข้อมูลใหม่และเราพยายามออกแบบวิธีการทำงานของวันที่และเวลา เราต้องสามารถรองรับหลายเขตเวลา (อาจอย่างน้อย GMT, IST, PST และ EST) ตอนแรกเราคิดว่าเราจะมีมิติเวลาวันที่ที่รวมกันกว้างลงไปจนถึง 15 นาทีอย่างละเอียดด้วยวิธีนี้เรามีหนึ่งคีย์ในตารางข้อเท็จจริงของเราและข้อมูลวันที่ที่แตกต่างกันทั้งหมดสำหรับเขตเวลาที่สนับสนุนทั้งหมดอยู่ในตารางมิติหนึ่ง (เช่นรหัสวันที่, วันที่ GMT, เวลา GMT, วันที่ IST, เวลา IST, ฯลฯ ... )

Kimball แนะนำให้มีการแยกมิติวันจากช่วงเวลาของวันเพื่อป้องกันไม่ให้ตารางขยายตัวใหญ่เกินไป (ชุดเครื่องมือคลังข้อมูลหน้า 240) ซึ่งฟังดูดี แต่นั่นหมายความว่าเรามีสองปุ่มในตารางความเป็นจริงสำหรับแต่ละเขตเวลา เราต้องการการสนับสนุน (หนึ่งสำหรับวันที่และหนึ่งสำหรับช่วงเวลาของวัน)

เนื่องจากฉันไม่มีประสบการณ์มากในพื้นที่นี้ฉันหวังว่าจะมีใครบางคนรู้ว่าการแลกเปลี่ยนระหว่างสองวิธีคือประสิทธิภาพและการจัดการของคีย์โซนเวลาที่แตกต่างกันทั้งหมด อาจมีวิธีอื่นด้วยเช่นกันฉันเคยเห็นบางคนกำลังพูดถึงการแยกแถวในตารางความเป็นจริงต่อเขตเวลา แต่ดูเหมือนว่าจะมีปัญหาหากคุณข้อเท็จจริงว่าตารางมีจำนวนหลายล้านแถวคุณต้องเพิ่มสี่เท่าเพื่อเพิ่มเขตเวลา .

ถ้าเราทำธัญพืช 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 จากนั้นถ้าเราต้องการรายงาน / กลุ่มตามโซนเวลาที่แตกต่างกัน และเชื่อมโยงปุ่มวันที่ / เวลาท้องถิ่นกลับไปที่ตารางวันที่และเวลา เราเติมข้อมูลตารางบริดจ์โซนเวลาโดยใช้รหัส C # ที่เรียกใช้จาก SSIS เนื่องจากมีความซับซ้อนน้อยกว่าการทำข้อมูล TZ จาก SqlServer โดยตรง

ฉันเห็นความคิดของคลังสินค้าโดยใช้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เขตร่วมกับตาราง 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)),
...
)

นี่คือความละเอียดครึ่งชั่วโมงดังนั้นจึงมี 48 บันทึกต่อวัน 350,400 ใน 20 ปี - จัดการค่อนข้าง

วันที่ / เวลาของกิจกรรมถูกแปลเป็น 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 สำหรับเวลาออมแสงตอนกลางของสหรัฐอเมริกา) แต่สิ่งนี้จะพังถ้าวันที่ / เวลาสำหรับบันทึกความจริงบางอย่างอยู่ในการปรับเวลาตามฤดูกาล

หากเหตุการณ์สำหรับบันทึกข้อเท็จจริงสามารถเกิดขึ้นได้ในเขตเวลาที่แตกต่างกันเช่นการจัดส่งหรือเที่ยวบินคุณต้องมีเขตเวลาในแต่ละวันและคุณมีความยาวไม่เกินห้าไบต์ต่อวัน