การจัดการโซนเวลาใน data mart / คลังสินค้า

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

อย่างไรก็ตามคำถามที่ฉันมีเวลาตอบยากคือขนาดและวันที่และเวลาที่ดีสำหรับฉันจริง ๆ แล้วพิจารณาความต้องการโซนเวลาแบบไดนามิกของฉันได้อย่างไร มิติเวลาทำให้รู้สึกมากกว่าเล็กน้อย แต่ฉันมีเวลายากกับมิติวันที่ แนวทางการออกแบบทั่วไปสำหรับส่วนข้อมูลวันที่มักจะมีคุณสมบัติเช่นชื่อวันวันในสัปดาห์ชื่อเดือน ฯลฯ ปัญหาที่ฉันมีอยู่ทั้งหมดคือ 23.00 น. ในวันอังคารที่ 31 ธันวาคม 2013 ใน UTC คือวันพุธ , 1 มกราคม 2014 ในโซนเวลาทั้งหมดที่อยู่หลัง UTC + 2

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

คนอื่น ๆ แนะนำให้มีตารางบริดจ์โซนเวลาซึ่งแม้ว่าจะมีเหตุผลบางอย่าง แต่ก็ดูเหมือนว่าจะมีความซับซ้อนและการรวมพิเศษเพื่อให้บรรลุสิ่งที่ลูกค้าและแอพของฉันควรจะสามารถหาได้จากวันที่ (การรายงานจะใช้เว็บเป็นหลัก ที่ซึ่งมีไลบรารีจำนวนมากมายเพื่อช่วยในการแปลงแสดงและจัดรูปแบบวันที่)

สิ่งเดียวที่ฉันคิดได้คือความง่ายและประสิทธิภาพของการจัดกลุ่มตามวันที่และเวลา แต่วิธีที่แย่คือการจัดกลุ่มตามวันที่ (เราใช้ MS SQL แต่เราจะสอบถามแถวนับล้าน) หรือเราควรพิจารณา เพียงส่วนข้อมูลวันที่และเวลาที่เรียบง่ายมากที่มีตัวเลขชั่วโมงวันเดือนและปีไม่มากไปกว่านี้เพราะตัวอักษรส่วนใหญ่เช่นวันจันทร์ไม่ได้มีความหมายมากนักเมื่อเขตเวลาเข้ามาเล่น?

ประการแรก ...

การแยกDatime/Timeออกเป็นDateมิติหนึ่งและTimeมิติเป็นวิธีที่แน่นอน

ในการจัดการหลายเขตเวลาคุณจำเป็นต้องทำซ้ำDateKeyและTimeKeyเพื่อให้คุณมีสิ่งต่อไปนี้:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

คุณพูด...

ปัญหาที่ฉันมีกับสิ่งทั้งหมดคือ 23.00 น. ในวันอังคารที่ 31 ธันวาคม 2013 ใน UTC คือวันพุธที่ 1 มกราคม 2014 ในโซนเวลาทั้งหมดที่อยู่หลัง UTC + 2

โดยการมี 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 ไป มุมมองของผู้อ่านรายงาน):

• มีการคำนวณที่อยู่ในแบบสอบถามใด ๆ วางภาระประสิทธิภาพพิเศษในพวกเขาคูณด้วยจำนวนครั้งที่คุณต้องเรียกใช้แบบสอบถามดังกล่าวสำหรับรายงานใด ๆ ที่คุณมี (เรื่องนี้เมื่ออ่านล้านแถว)
• ภาระพิเศษที่ทำให้มั่นใจได้ว่าการคำนวณจะได้รับการดูแลอย่างถูกต้องในแต่ละแบบสอบถาม (โดยเฉพาะเมื่อคุณคำนึงถึงการประหยัดเวลากลางวัน)
• ป้องกันการสแกนช่วงของดัชนีใด ๆ ที่เป็นส่วนหนึ่งของคอลัมน์เนื่องจากคุณจะทำการคำนวณในคอลัมน์ที่บังคับให้คิวรีทำการสแกนดัชนีแทนการค้นหา (ซึ่งโดยทั่วไปจะมีราคาแพงกว่าเนื่องจากต้องอ่านหน้าข้อมูลแต่ละหน้า); สิ่งนี้เป็นที่รู้จักกันว่าไม่สามารถขายได้
  • แก้ไขเนื่องจากความคิดเห็น:นี้ใช้ถ้าคุณผลักดันการแปลงลงไปในแบบสอบถามที่เกิดขึ้นจริง
• โดยใช้แนวคิดของการมีวัน UTC เพิ่มเติมและเวลาที่มีอยู่ให้มีอะไรที่หยุดคุณจากการใช้แนวคิดนี้และขยายโดยเรียกนี้StandardisedDateKeyหรือCorporateHQDateKeyที่แทนของตารางวันเวลา UTC คุณขึ้นอยู่กับมาตรฐานอื่น ๆ บางธุรกิจที่ตกลงกันมาตรฐาน
• การมีคอลัมน์แยกกันสองประเภท (Local และ UTC) ช่วยให้สามารถเปรียบเทียบแบบระยะยาวข้ามระยะทางภูมิศาสตร์ได้ คิด -> คนในออสเตรเลียเข้ามาบันทึกที่ timestamped กับทั้งท้องถิ่นและ UTC บางคนในนิวยอร์กอ่านรายงานที่มี (ออสเตรเลีย) วันที่และเวลาท้องถิ่นและการแสดงที่นิวยอร์กวัน UTC และเวลาจึงเห็นอะไรบางอย่างที่ คู่ของพวกเขาชาวออสเตรเลียทำในช่วงกลางของวัน (เวลาออสเตรเลีย) เกิดขึ้นในตอนกลางคืนเวลาของพวกเขา (เวลานิวยอร์ก) การเปรียบเทียบเวลานี้เป็นสิ่งที่ขาดไม่ได้ในธุรกิจข้ามชาติ

ฉันต้องขออภัยล่วงหน้าสำหรับช่วงเวลาสั้น ๆ ของคำตอบนี้และวางแผนที่จะอธิบายอย่างละเอียดเมื่อฉันไม่ได้ทำงาน

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

หากคำถามหรือความคิดเห็นอื่น ๆ อย่าลังเลที่จะถาม