Thiết kế dữ liệu: Kết hợp kích thước ngày Thời gian so với kích thước và thời gian ngày và giờ riêng biệt

Chúng tôi mới bắt đầu thiết kế cho một kho dữ liệu mới và chúng tôi đang cố gắng thiết kế cách thức kích thước ngày và giờ của chúng tôi sẽ hoạt động. Chúng tôi cần có khả năng hỗ trợ nhiều múi giờ (có thể ít nhất là GMT, IST, PST và EST). Ban đầu, chúng tôi nghĩ rằng chúng tôi sẽ có một chiều thời gian ngày kết hợp rộng xuống mức độ chi tiết có thể là 15 phút, theo cách đó chúng tôi có một khóa trong các bảng thực tế và tất cả dữ liệu thời gian ngày khác nhau cho tất cả các múi giờ được hỗ trợ đều nằm trong một bảng chiều. (tức là Khóa ngày, Ngày GMT, Giờ GMT, Ngày IST, Giờ IST, v.v ...)

Kimball gợi ý nên có kích thước ngày riêng biệt với thời gian của ngày để ngăn bảng phát triển quá lớn (Bộ công cụ kho dữ liệu trang 240) nghe có vẻ tốt tuy nhiên điều đó có nghĩa là chúng tôi có hai khóa trong bảng thực tế cho mỗi múi giờ chúng tôi cần hỗ trợ (một cho ngày và một cho thời gian trong ngày).

Vì tôi rất thiếu kinh nghiệm trong lĩnh vực này, tôi hy vọng ai đó ngoài kia biết được sự đánh đổi giữa hai cách tiếp cận, tức là hiệu suất so với việc quản lý tất cả các phím múi giờ khác nhau. Có thể có những cách tiếp cận khác nữa, tôi đã thấy một số người nói về việc có một hàng riêng trong bảng thực tế trên mỗi múi giờ, nhưng đó có vẻ là một vấn đề nếu các bảng thực tế của bạn là hàng triệu hàng thì bạn cần tăng gấp bốn lần để thêm múi giờ .

Nếu chúng tôi thực hiện hạt 15 phút, chúng tôi sẽ có 131.400 (24 * 15 * 365) hàng năm trong bảng thứ nguyên thời gian ngày của chúng tôi không có vẻ quá kinh khủng cho hiệu suất nhưng chúng tôi sẽ không biết chắc chắn cho đến khi chúng tôi kiểm tra một số truy vấn nguyên mẫu. Mối quan tâm khác với việc có các khóa múi giờ riêng biệt trong bảng thực tế là truy vấn phải nối bảng thứ nguyên sang một cột khác dựa trên múi giờ mong muốn, có lẽ đây là điều mà SSAS quan tâm đối với bạn, tôi không chắc chắn .

cảm ơn vì những suy nghĩ, -Matt

Có ngày và thời gian riêng biệt sẽ cho phép bạn thực hiện tổng hợp theo thời gian một cách dễ dàng. ví dụ: nếu bạn muốn chạy truy vấn để tìm khoảng thời gian nào trong ngày bận rộn nhất. Điều này rất dễ thực hiện bằng cách sử dụng thứ nguyên thời gian riêng biệt.

Ngoài ra, bạn chỉ nên có một phím thời gian. Quyết định thời gian GMT / EST - sau đó sử dụng điều này trong bảng thực tế. Nếu bạn cần chạy các báo cáo dựa trên múi giờ khác, chỉ cần chuyển đổi nó trong ứng dụng hoặc truy vấn của bạn.

Chỉ cần theo dõi về cách chúng tôi quyết định triển khai DataWarehouse để hỗ trợ nhiều múi giờ và hiệu quả nhất có thể: Chúng tôi đã chọn tạo một bảng múi giờ (id, name, v.v.) cũng như "Múi giờ cây cầu "bảng trông như thế này:

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

Bằng cách này, chúng ta có thể giữ các bảng thứ nguyên ngày và giờ bình thường của mình nhỏ, tất cả các sự kiện của chúng ta liên kết với các khóa ngày / giờ UTC, sau đó nếu chúng ta cần báo cáo / nhóm theo múi giờ khác, chúng ta chỉ cần tham gia qua bảng cầu múi giờ và liên kết các khóa ngày / giờ cục bộ trở lại bảng thứ nguyên ngày và giờ. Chúng tôi điền vào bảng cầu múi giờ bằng mã C # được gọi từ SSIS vì điều này ít phức tạp hơn nhiều so với thực hiện trực tiếp công cụ TZ từ SqlServer.

Tôi đã thấy ý tưởng về một nhà kho sử dụng DateTimekích thước kết hợp bị từ chối, nhưng tôi chưa thấy lý do thực sự rõ ràng tại sao. Đơn giản hóa một chút, đây là bảng thực tế tôi đang xây dựng ngay bây giờ:

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
)

Các DateTimetrường tham gia vào bảng 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)),
...
)

Đây là ở độ phân giải nửa giờ, vì vậy có 48 hồ sơ mỗi ngày, 350.400 trong 20 năm - khá dễ quản lý.

Ngày / giờ sự kiện được dịch sang UTC khi được lưu trữ, nhưng với LocalTimeZoneSKtrường và bảng cầu nối, chúng ta có thể dễ dàng tham gia để lấy giờ địa phương:

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

Để có được các giao dịch được tạo ngày hôm nay, thời gian UTC:

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

Để có được các giao dịch được tạo ngày hôm nay, theo giờ địa phương cho giao dịch:

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'

Bạn có thể muốn đơn giản hóa mọi thứ bằng cách thay thế TimeZoneSKbằng phần REALbù (ví dụ: -5.0 cho Giờ ban ngày trung tâm Hoa Kỳ), nhưng điều này sẽ bị hỏng nếu một số ngày / lần cho một bản ghi thực tế là trong Giờ tiết kiệm ánh sáng ban ngày và một số thì không.

Nếu các sự kiện cho một bản ghi thực tế có thể xảy ra ở các múi giờ khác nhau, như một chuyến hàng hoặc chuyến bay, thì bạn cần một trường múi giờ cho mỗi ngày và bạn có tối đa năm byte mỗi ngày.