Nguồn dữ liệu mục tiêu và mục hàng không khớp


7

Tôi đang làm việc với một lược đồ sao cho kho dữ liệu và tôi đang gặp vấn đề với các mục hàng và tiêu đề từ các nguồn dữ liệu khác nhau.

CREATE TABLE DataSourceAHeader
(
     OrderId INT NOT NULL
    ,TotalCost MONEY NOT NULL
    -- Date, etc...
);

CREATE TABLE DataSourceALine
(
     OrderId INT NOT NULL
    ,LineNumber INT NOT NULL
    -- Dates, etc...
);

CREATE TABLE DataSourceBLine
(
     OrderId INT NOT NULL
    ,Cost MONEY NOT NULL
    ,LineNumber INT NOT NULL
);

Tôi có nguồn dữ liệu A và B đại diện cho cùng một dữ liệu theo những cách khác nhau. Nguồn dữ liệu A chứa các tiêu đề và chi tiết đơn hàng, nhưng nó chỉ có kết quả ròng (Tổng chi phí) trong tiêu đề. Nguồn dữ liệu B chỉ chứa các chi tiết đơn hàng và mỗi mục có kết quả (Chi phí).

Tôi có thể giữ hai bảng thực tế (một cho tiêu đề và một cho mục hàng), nhưng tôi đã nghiên cứu và có vẻ như không thể xem được. Có một chiến lược để đối phó với loại định dạng không khớp này hay chúng nên được lưu trữ trong các kho dữ liệu riêng biệt (một kho cho mỗi nguồn dữ liệu)?

Chiến lược hiện tại của tôi:

CREATE TABLE Fact.Order
(
     Id BIGINT IDENTITY PRIMARY KEY
    ,OrderId INT NOT NULL
    ,Cost MONEY NOT NULL
    -- Date key, etc...
);

CREATE TABLE Fact.OrderLine
(
     Id BIGINT IDENTITY PRIMARY KEY
    ,OrderFactId BIGINT NOT NULL REFERENCES Fact.Order (Id)
    ,LineNumber INT NOT NULL
    -- related line stuff
);

DataSourceAHeaderDataSourceBLineđược chèn vào OrderOrderLine. DataSourceBLineđược chia một dòng trên mỗi hàng.

Đây là một ví dụ cho một DataSourceAHeaderDataSourceALine

SELECT * FROM Fact.Order;
|------------------------------------|
|   Id   |   OrderId   |   Cost      |
|   1    |     1100    |   12000.00  |
|   2    |     1101    |   10000.00  |
|------------------------------------|

SELECT * FROM Fact.OrderLine;
|-------------------------------------------|
|   Id   |   OrderFactId   |   LineNumber   |
|   1    |        1        |       1        |
|   2    |        1        |       2        |
|   3    |        1        |       3        |
|   4    |        2        |       1        |
|   5    |        2        |       2        |
|   6    |        2        |       3        |
|-------------------------------------------|

Đây là một ví dụ cho một DataSourceBLine

SELECT * FROM Fact.Order;
|---------------------------------|
|   Id   |   OrderId   |   Cost   |
|   1    |     1000    |   12.00  |
|   2    |     1000    |   10.00  |
|---------------------------------|

SELECT * FROM Fact.OrderLine;
|-------------------------------------------|
|   Id   |   OrderFactId   |   LineNumber   |
|   1    |        1        |       1        |
|   2    |        2        |       2        |
|-------------------------------------------|

Biên tập:

các TotalCosttrong tiêu đề không thể được đưa xuống mức dòng. Tôi đã nói chuyện với một người quen của kiến ​​trúc sư và lời khuyên của anh ta là triển khai hai bảng thực tế riêng biệt, một cho tiêu đề (tóm tắt) và một cho các dòng (chi tiết) và chỉ có NULLcác giá trị cho thông tin dòng bị thiếu DataSourceA.

Chỉnh sửa2:

Tôi đang cố gắng chung chung với OrderId vì tôi có thêm một số nguồn dữ liệu có thể chứa các lược đồ OrderId tương tự (va chạm). Tôi đã triển khai bảng Ánh xạ để dịch các định danh nguồn vào kho.

Chỉnh sửa 3:

Với ý định rằng câu hỏi này hữu ích cho nhiều người hơn là bản thân tôi, tôi muốn câu trả lời có các chi tiết sau (chủ yếu để biên dịch những gì mọi người đã suy luận về):

  • Nói chung, các cách tiếp cận để giải quyết các tập dữ liệu rời rạc liên quan ở dạng tóm tắt / chi tiết (bảng thực tế đơn hoặc bảng tóm tắt / chi tiết thực tế) là gì?
  • Những hạn chế của mỗi phương pháp là gì?
  • Loại cấu trúc nào mà bảng thực tế có thể thực hiện để đối phó với dữ liệu bị thiếu (hoặc không liên quan)?
  • (hai cách tiếp cận bảng thực tế) Trong trường hợp nào sẽ là khôn ngoan để cuộn xuống bản tóm tắt so với cuộn lên các chi tiết?

Dựa trên mô hình được đề xuất, làm thế nào để bạn có kế hoạch (tái) xây dựng mục hàng Giá trị chi phí cho dữ liệu Nguồn dữ liệu A? Có vẻ như không thể trừ khi có thêm thông tin có sẵn (sản phẩm, đơn vị, số lượng, v.v.).
Jon Seigel

Có, không thể xây dựng lại mục hàng Giá trị chi phí. Ngay bây giờ tôi đang xử lý các dòng như một bảng kích thước và tách các dòng từ DataSourceBLine. Mỗi mục hàng trở thành một hàng riêng biệt.
Dustin Kingen

@JonSeigel Kiểm tra chỉnh sửa của tôi cho câu hỏi.
Dustin Kingen

Ồ, tôi xin lỗi, tôi đã nhớ rằng bạn nói rằng cả hai nguồn dữ liệu đại diện cho cùng một dữ liệu.
Jon Seigel

Được rồi, để rõ ràng, bạn đang hỏi về cách triển khai tải các dòng "chỉ phẳng" - chỉ lược đồ được đề xuất bởi bài viết, đúng không?
Jon Seigel

Câu trả lời:


4

Nếu bạn muốn hủy chuẩn hóa điều này thành một bảng thực tế, thì bảng thực tế sẽ là về các chi tiết đơn hàng. Do đó, các sự kiện từ DataSourceAHeader cần được phân tách và phân phối cho các chi tiết đơn hàng có liên quan để chúng không bị trùng lặp. Vì hiện tại, điều đó có nghĩa là giảm tổng chi phí đơn hàng của bạn và tính toán điều này bằng cách tính tổng chi phí của chi tiết đơn hàng.

Các khóa kích thước DataSourceAHeader (ví dụ: ngày đặt hàng) có thể được lấy từ DataSourceAHeader và được áp dụng cho các hàng thực tế được tạo từ DataSourceBLine. Trong ví dụ này dường như không có bất kỳ thông tin nào có trên DataSourceALine chưa được bao gồm trên DataSourceAHeader hoặc DataSourceBLine, nhưng nếu có thì điều này có thể được ánh xạ theo cách tương tự.

Cách tiếp cận này dựa trên một số giả định, vấn đề chính là tất cả các sự kiện từ DataSourceAHeader có thể được phân phối chính xác giữa các chi tiết đơn hàng cấu thành của nó. Nếu điều này không đúng, tải hai bảng thực tế riêng biệt (một cho đơn hàng và một cho các chi tiết đơn hàng) có thể là một cách tiếp cận tốt hơn. Điều tương tự cũng có thể đúng nếu có rất nhiều câu hỏi được đặt ra về các đơn hàng, không xem xét thông tin cụ thể của chi tiết đơn hàng. Điều này được gắn nhãn là "Ý tưởng tồi # 2" trong bài viết mà bạn đã tham khảo, nhưng tôi đã thấy rằng trong một số trường hợp nhất định, đó thực sự là một ý tưởng tốt.

Cuối cùng, điều này giả định rằng hai nguồn dữ liệu được đồng bộ hóa. Nếu không, bạn sẽ tự giới hạn mình tải dữ liệu với tốc độ của nguồn dữ liệu chậm hơn. Điều này có thể tốt, nhưng cần được xem xét trong bối cảnh nhu cầu của bạn và sự khác biệt giữa hai nguồn dữ liệu.

Chỉnh sửa: Việc không chuẩn hóa thành một bảng thực tế có thể ảnh hưởng đáng kể đến hiệu suất khi đếm đơn hàng, vì về cơ bản nó là một số lượng riêng biệt, đó sẽ là lý do chính của tôi để xem xét hai bảng thực tế riêng biệt.

Chỉnh sửa 2 (để trả lời câu hỏi chỉnh sửa):

Ở đây, vấn đề là ở mức dữ liệu chi tiết nhất (dòng) không đầy đủ, càng nhiều thì không phải tất cả các hàng đều có giá trị chi phí. Tuy nhiên, tổng thông tin chi phí có sẵn ở cấp độ tiếp theo (tiêu đề). Điều này trình bày tình huống mà bạn không thể lấy được cấp cao hơn từ cấp thấp hơn; Hãy xem xét các tùy chọn kết quả:

  1. Có một bảng thực tế duy nhất ở mức độ chi tiết thấp nhất có sẵn (dòng). Đây không phải là khởi đầu, vì chúng tôi hiện đang dựa vào dữ liệu dòng không đầy đủ để trả lời các câu hỏi ở cấp cao hơn, mà chúng tôi biết rằng chúng tôi có thể đã trả lời.
  2. Có một bảng thực tế duy nhất ở mức độ chi tiết cao hơn (tiêu đề). Điều này có nghĩa là bây giờ chúng ta có thể trả lời các câu hỏi ở cấp độ cao hơn với dữ liệu hoàn chỉnh, nhưng không thể trả lời các câu hỏi ở cấp độ chi tiết hơn nữa. Điều này có thể được coi là chấp nhận được, nhưng trong hầu hết các trường hợp, chúng tôi đang vứt bỏ dữ liệu có giá trị.
  3. Có hai bảng thực tế liên quan, một cho dữ liệu không đầy đủ, chi tiết hơn (dòng) và một cho dữ liệu chi tiết, ít chi tiết hơn (tiêu đề). Đây là giải pháp lý tưởng, vì hiện tại chúng tôi có thể trả lời đầy đủ các câu hỏi ở cấp cao hơn và có thể đưa ra câu trả lời tốt nhất có thể cho các câu hỏi ở cấp thấp hơn, do tính không đầy đủ của dữ liệu nguồn.

Câu hỏi này được đặt ra vì nghi ngờ về việc có hai bảng thực tế liên quan. Những nghi ngờ xuất phát từ thực tế là việc duy trì và tham gia hai bảng thực tế lớn có thể tốn nhiều tài nguyên. Điều đó là đúng và nếu thông tin chi tiết nhất của bạn có thể được sử dụng để cung cấp mô tả đầy đủ về tình huống thì nên sử dụng một bảng thực tế duy nhất. Tuy nhiên, trong những tình huống như thế này khi không thể, cần có hai bảng thực tế nếu bạn muốn lưu giữ càng nhiều thông tin càng tốt.


Điểm đếm khác biệt của bạn là hợp lệ, tuy nhiên, có một số cách để tối ưu hóa điểm không yêu cầu sao chép dữ liệu. Nó sẽ là một trận chiến khó khăn thuyết phục tôi rằng phân bổ không phải là cách tiếp cận chính xác trong việc có hai bảng thực tế trong phần lớn các trường hợp.
StrayCatDBA

all the facts from DataSourceAHeader can accurately be distributed among its constituent line itemsCác DataSourceAHeaderkhông thể được phân phối giữa các dòng, vì vậy tôi bắt đầu suy nghĩ hai bảng riêng biệt sẽ là cần thiết. Xem chỉnh sửa của tôi cho câu hỏi ở phía dưới.
Dustin Kingen

Nếu đó là trường hợp @Romoku, thì tôi sẽ đồng ý với hai bảng. Chắc chắn không thể chấp nhận được một khi bạn đã khám phá các tùy chọn khác và thấy chúng không phù hợp.
Matt

2

Hãy giả sử với giả định rằng bạn chỉ cần một bảng thực tế cho "Đơn hàng". Cách tiếp cận này đúng trong 99% trường hợp và kịch bản của bạn khá chuẩn.

  1. Khai báo mức tăng của bảng thực tế: Một hàng trên mỗi dòng đơn hàng.

  2. Xác định các thuộc tính thứ nguyên (Ngày đặt hàng, Ngày giao hàng, khách hàng, sản phẩm, v.v.) Đây sẽ là một hỗn hợp từ cả tiêu đề đơn hàng và dòng đơn hàng. Số thứ tự (Order.OrderId?) Biến thành "thứ nguyên suy biến" (Bạn sẽ không có thứ nguyên "Đơn hàng" vì tất cả các thuộc tính thú vị đã bị loại bỏ chỉ còn lại số thứ tự.)

  3. Xác định sự thật. Đây là các phép đo liên quan đến thứ tự. Số lượng, chi phí, doanh thu, v.v ... Bạn muốn giữ sau đó là phụ gia, vì vậy hãy lưu trữ qty và giá mở rộng, không phải giá e. Các phép đo chỉ tồn tại ở cấp tiêu đề phải được phân bổ xuống cấp độ dòng.

Nếu doanh nghiệp do dự phân bổ chi phí cấp đơn hàng xuống chi tiết đơn hàng thì quá tệ. Họ sẽ nhận được một kho dữ liệu tốt hơn nếu họ làm.


các TotalCosttrong tiêu đề không thể được đưa xuống mức dòng. Tôi đã nói chuyện với một người quen của kiến ​​trúc sư và lời khuyên của anh ta là triển khai hai bảng thực tế riêng biệt, một cho tiêu đề (tóm tắt) và một cho các dòng (chi tiết) và chỉ có NULLcác giá trị cho thông tin dòng bị thiếu cho DataSourceA(dòng Cost).
Dustin Kingen

Tại sao tổng chi phí không thể được phân bổ? Sự biện minh được đưa ra là gì? Sự khác biệt giữa TotalCost và tổng chi phí của dòng là gì?
StrayCatDBA

Nó không thể được phân phối xuống vì DataSourceAkhông có bất kỳ chi phí dòng nào (chỉ là thông tin dòng) hoặc một phương pháp để lấy chi phí dòng. Tôi nhận được dữ liệu này như hiện tại và thật không may, tôi không thể buộc nhà cung cấp thay đổi hệ thống của họ.
Dustin Kingen

Liệu cùng một orderId từ cả hai nguồn dữ liệu, hoặc chúng tách rời các hệ thống? Hay cụ thể hơn, nếu đơn hàng 223344 đến từ DataSourceA, nó cũng hiển thị trong DataSourceB?
StrayCatDBA

Vâng, có thể có va chạm. Tôi đã triển khai bảng Ánh xạ để dịch các mã định danh nguồn vào kho
Dustin Kingen

0

Cố gắng tránh xa các khóa chính tùy ý. Trong trường hợp các đơn đặt hàng, có một khóa hữu ích trong id đơn hàng. Số dòng cũng là duy nhất khi kết hợp với id thứ tự. Tải dữ liệu nên bẫy bất kỳ trường hợp ngoại lệ nào, chẳng hạn như trùng lặp.

Tất cả các ràng buộc chính và ngoại của bạn, đối với dữ liệu bạn đã chia sẻ, phải được xây dựng dựa trên id đơn hàng và số dòng với trung tâm của ngôi sao chứa tiêu đề đơn hàng và tổng chi phí và các chi tiết đơn hàng trong một bảng riêng biệt với chi phí liên quan và dữ liệu khác của chúng từ cả hai nguồn trong các cột rời rạc


Tôi đang cố gắng chung chung OrderIdvì tôi có thêm một số nguồn dữ liệu có thể chứa các OrderIdlược đồ tương tự (va chạm). Tôi đã triển khai bảng Ánh xạ để dịch các định danh nguồn vào kho.
Dustin Kingen
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.