Tôi có một bảng thực tế chụp nhanh tích lũy theo dõi sự ra vào của các container trong một thiết bị đầu cuối .

Các container có thể nhập và thoát theo 3 cách khác nhau , vì vậy tôi nghĩ sẽ tạo một bảng kích thước cụ thể liệt kê 3 cách có thể này ( tàu, tàu hoặc xe tải ).

Sau đó tôi đọc bài viết này về cơ bản nói rằng kỹ thuật này là sai, nhưng tôi không thể hiểu tại sao.

Bài viết đầu tiên:

Đôi khi, khi một bảng thực tế có một danh sách dài các sự kiện được đặt rải rác trong bất kỳ hàng riêng lẻ nào, thì việc tạo ra một thứ nguyên loại đo lường sẽ thu gọn hàng của bảng thực tế xuống một thứ nguyên chung chung được xác định bởi thứ nguyên loại đo. Chúng tôi thường không khuyến nghị phương pháp này. Mặc dù nó loại bỏ tất cả các cột thực tế trống, nhưng nó nhân kích thước của bảng thực tế với số cột trung bình bị chiếm trong mỗi hàng và nó làm cho việc tính toán trong cột trở nên khó khăn hơn nhiều. Kỹ thuật này được chấp nhận khi số lượng các sự kiện tiềm năng là cực kỳ (trong hàng trăm), nhưng ít hơn một số ít sẽ được áp dụng cho bất kỳ hàng bảng thực tế nào.

Tôi hiểu rằng nếu " Kích thước loại đo lường " được triển khai cho bảng thực tế giao dịch, nó có thể tạo ra các vấn đề như bài viết khác nói, nhưng tôi không thể thấy bất kỳ nhược điểm nào nếu được sử dụng cho thực tế ảnh chụp tích lũy .

Bài viết thứ hai: (một số nhược điểm của việc thực hiện "Kích thước loại đo lường")

1. [...] Nếu chúng tôi sử dụng "Kích thước loại đo", chúng tôi sẽ mất khả năng phân tích này. Nếu một biện pháp không tương thích với các biện pháp khác, chúng tôi không thể thêm chúng vào.
2. [...] Số lượng vượt qua SQL của chúng tôi cần chạy để tạo báo cáo, báo cáo càng chậm.
3. [...] Trên công cụ BI, nếu bạn không đặt bộ lọc loại đo lường, bạn sẽ gặp rủi ro khi người dùng nhận thông tin rác rưởi. Từ quan điểm khả năng sử dụng, thiết kế này là một rác.

Trả lời câu trả lời của Mark Storey-Smith

Cách tiếp cận rất hay, tôi sẽ không bao giờ nghĩ về điều đó.

Một điều nữa: mỗi lần ra vào của một chiếc xe đưa container vào bến đều có một ID duy nhất cung cấp cho tôi các thông tin khác như: xe đến, dự kiến ​​sẽ đến, nếu là tàu cập bến, nếu đó là xe tải của trạm thu phí và nhiều thông tin khác ...

Đây là 3 bảng thực tế khác nhau và chúng phải được liên kết bằng cách nào đó với bảng thực tế container.

Tôi nghĩ rằng ID của chuyến đi là một degenerate dimension, vì vậy nó sẽ trực tiếp đi vào bảng thực tế container. Vì vậy, nghi ngờ của tôi là: tôi có nên thêm 6 trường khác nhau trong bảng thực tế của container (ship_voyage_in_key, ship_voyage thừng_key, train_voyage_in_key, train_voyage thừng_key, Truck_voyage_in_key, Truck_voyage thừng_key) hay chỉ các chuyến đi khác

Tôi hy vọng nghi ngờ của tôi là rõ ràng, cảm ơn bạn.

Tôi tin rằng hướng dẫn đang đề cập đến một bảng thực tế rộng, trong đó phần lớn các giá trị đo là null:

CREATE TABLE dbo.SparseFact
(
    Dim1Key     INT NOT NULL
    , Dim2Key   INT NOT NULL
    , Dim3Key   INT NOT NULL
    , Dim4Key   INT NOT NULL
    , Dim5Key   INT NOT NULL
    , Value1    INT NULL
    , Value2    INT NULL
    , Value3    INT NULL
    , Value4    INT NULL
    , Value5    INT NULL
    , Value6    INT NULL
    , Value7    INT NULL
    , Value8    INT NULL
    ..
    , Value101  INT NULL
    , Value102  INT NULL
    , Value103  INT NULL
);

Gợi ý là một số người sẽ thấy tất cả các null và quyết định làm điều này thay vào đó:

CREATE TABLE dbo.DontDoThisFact
(
    Dim1Key             INT NOT NULL
    , Dim2Key           INT NOT NULL
    , Dim3Key           INT NOT NULL
    , Dim4Key           INT NOT NULL
    , Dim5Key           INT NOT NULL
    , MeasureTypeKey    INT NOT NULL
    , Value             INT NOT NULL
);

Không tốt.

Trong kịch bản của bạn, tôi nghĩ rằng tôi đang xem xét một cái gì đó như thế này, rất khác với kịch bản được mô tả trong các bài viết mà bạn tham chiếu.

CREATE TABLE dbo.InventoryFact
(
    ContainerKey        INT NOT NULL
    , TransportTypeKey  TINYINT NOT NULL
    , EntryDateTime     DATETIME NULL
    , ExitDateTime      DATETIME NULL
);

CREATE TABLE dbo.TransportType
(
    TransportTypeKey    TINYINT IDENTITY(1,1) NOT NULL
    , EntryTransport    CHAR(10) NOT NULL
    , ExitTransport     CHAR(10) NOT NULL
);

INSERT
    dbo.TransportType
SELECT
    EntryTransport
    , ExitTransport
FROM
    (
    SELECT EntryTransport = 'Train'
    UNION
    SELECT EntryTransport = 'Truck'
    UNION
    SELECT EntryTransport = 'Vessel'
    UNION
    SELECT EntryTransport = 'N/A'
    UNION
    SELECT EntryTransport = 'Unknown'
    ) en
CROSS JOIN
    (
    SELECT ExitTransport = 'Train'
    UNION
    SELECT ExitTransport = 'Truck'
    UNION
    SELECT ExitTransport = 'Vessel'
    UNION
    SELECT ExitTransport = 'N/A'
    UNION
    SELECT ExitTransport = 'Unknown'
    ) ex;

Đối với các câu hỏi bổ sung ...

Tôi sẽ thêm ExpectedEntryDate,ExpectedExitDate vào Container/InventoryFact. Ít chắc chắn hơn, không có khả năng hiển thị của tất cả các yếu tố dữ liệu, có lẽ tôi sẽ đặt EntryVoyageIdvà ExitVoyageIdtrong một chiều rác riêng biệt cùng nhau thành một hàng cùng với bất kỳ mục dữ liệu suy biến nào khác (định danh cho xe tải, xe lửa, v.v.).

Tôi sẽ thêm 3 chiều kích mới cho VesselVoyage, TruckVoyagevà TrainVoyagevà 6 phím Voyage (inbound / outbound) cho một thực tế này (đó là 6 phím mới, chứ không phải 6 thêm hàng). Sau đó, bạn có tùy chọn đặt Dockvà Tollboothtrong kích thước Voyage thích hợp. Nếu bạn giữ dữ liệu chung ở các kích thước này ( VesselFlag, TruckCapacity) và cụ thể ở kích thước rác ( VesselName, VesselMMSI) chúng sẽ không phát nổ về kích thước.