2011-05-21 35 views
9

Tôi có một số đối tượng trong Data Warehouse của tôi:Làm cách nào để tạo bảng lịch sử?

  1. Person - với các thuộc tính PersonId, dateFrom, dateTo, và những người khác những thể thay đổi, ví dụ Tên cuối cùng, ngày tháng năm sinh và vân vân - chậm thay đổi chiều hướng

  2. Document - documentId, số lượng, loại

  3. Địa chỉ - AddressID, thành phố, đường phố, nhà, căn hộ

Mối quan hệ giữa (Người và Tài liệu) là Một-Nhiều và (Người và Địa chỉ) là Nhiều người-Nhiều.

mục tiêu của tôi là để tạo ra bảng thực tế lịch sử mà có thể trả lời chúng tôi câu hỏi sau:

  1. người gì với những gì tài liệu sống tại địa chỉ được xác định vào ngày xác định?

2, Lịch sử của người dân địa chỉ được xác định có trong khoảng thời gian xác định?

Điều này không chỉ cho những gì DW được thiết kế, nhưng tôi nghĩ rằng đó là điều khó khăn nhất trong thiết kế của DW.

Ví dụ: Hoa hậu Brown với personId = 1, tài liệu có documentId = 1 và documentId = 2 đã được sống tại địa chỉ có addressId = 1 từ 01/01/2005 đến 02/02/2010 và sau đó được chuyển đến addressId = 2 nơi đã sống từ ngày 02/03/2010 đến ngày hiện tại (NULL?). Nhưng cô đã đổi tên thành Mrs Green từ ngày 04/05/2006 và tài liệu đầu tiên của cô với documentId = 1 thành documentId = 3 kể từ 06/07/2007. Mr Black với personId = 2, documentId = 4 đã được sống tại addressId = 1 kể từ ngày 02/03/2010 đến ngày hiện tại.

Kết quả dự kiến ​​trên truy vấn của chúng tôi cho câu hỏi 2 nơi AddressID = 1, và khoảng thời gian là từ 01/01/2000 đến nay, phải như:

Hàng:

last_name="Brown", documentId=1, dateFrom=01/01/2005, dateTo=04/04/2006 

last_name="Brown", documentId=2, dateFrom=01/01/2005, dateTo=04/04/2006 

last_name="Green", documentId=1, dateFrom=04/05/2006, dateTo=06/06/2007 

last_name="Green", documentId=2, dateFrom=04/05/2006, dateTo=06/06/2007 

last_name="Green", documentId=2, dateFrom=06/07/2007, dateTo=02/01/2010 

last_name="Green", documentId=3, dateFrom=06/07/2007, dateTo=02/01/2010 

last_name="Black", documentId=4, dateFrom=02/03/2010, dateTo=NULL 

tôi đã một ý tưởng để tạo bảng thực tế với khóa tổng hợp (personId, documentId, addressId, dateFrom) nhưng tôi không có ý tưởng làm thế nào để tải bảng này và sau đó nhận được kết quả mong đợi với cấu trúc này.

Tôi sẽ rất vui lòng được trợ giúp!

Trả lời

3

Câu hỏi thú vị @Argnist!

Vì vậy, để tạo ra một số ngôn ngữ chung cho ví dụ của tôi, bạn muốn có một

  • DimPerson (PK = kcPerson, phím suggorate cho Người độc đáo = kPerson, loại 2 mờ)
  • DimDocument (PK = kcDocument, chìa khóa suggorate cho Tài liệu độc đáo = kDocument, loại 2 mờ)
  • DimAddress (PK = kcAddress, phím suggorate cho địa chỉ độc đáo = kAddress, loại 2 mờ)

một đồng nghiệp đã viết một blog ngắn về t anh ta sử dụng hai khóa thay thế để giải thích các số mờ trên 'Using Two Surrogate Keys on Dimensions'.

Tôi sẽ luôn thêm DimDate với PK dưới dạng yyyymmdd vào bất kỳ kho dữ liệu nào có cột thuộc tính bổ sung.

Sau đó, bạn sẽ có bảng thực tế của bạn như

  • FactHistory (FKS = kcPerson, kPerson, kcDocument, kDocument, kcPerson, kPerson, kDate) cộng thêm bất kỳ biện pháp aditional.

Sau đó, tham gia vào "kc", bạn có thể hiển thị thông tin kích thước Người/Tài liệu/Địa chỉ hiện tại. Nếu bạn đã tham gia vào "k", bạn có thể hiển thị thông tin kích thước Người/Tài liệu/Địa chỉ lịch sử.

Nhược điểm của điều này là bảng thực tế này cần một hàng cho mỗi người/tài liệu/địa chỉ/ngày kết hợp. Nhưng nó thực sự là một cái bàn rất hẹp, vì bàn chỉ có một số khoá ngoại.

Lợi thế của việc này là rất dễ dàng để truy vấn các loại câu hỏi bạn đang hỏi.

Ngoài ra, bạn có thể có bảng thực tế của bạn như

  • FactHistory (FKS = kcPerson, kPerson, kcDocument, kDocument, kcPerson, kPerson, kDateFrom, kDateTo) cộng thêm bất kỳ biện pháp aditional.

Điều này rõ ràng là nhỏ gọn hơn nhiều, nhưng việc truy vấn trở nên phức tạp hơn. Bạn cũng có thể đặt chế độ xem trên bảng Sự kiện để giúp truy vấn dễ dàng hơn!

Lựa chọn giải pháp phụ thuộc vào tần suất thay đổi dữ liệu. Tôi nghi ngờ rằng nó sẽ không thay đổi nhanh chóng, do đó, thiết kế thay thế của bảng thực tế có thể tốt hơn.

Hy vọng điều đó sẽ hữu ích.

+0

@Marcus D Cảm ơn bạn. Tôi nghĩ tương tự nhưng không có bàn phím "k" trong bảng thực tế (Tôi có hiểu tên của bạn đúng không? KcPerson - chìa khóa thay thế cho việc xác định một hàng và kPerson - khóa tự nhiên để nhận dạng một người?). – Argnist

+0

Nhưng FactHistory (FKs = kcPerson, kPerson, kcDocument, kDocument, kcAddress, kAddress, kDateFrom, kDateTo) cho rằng chúng ta phải cập nhật thông tin cũ 'kDateTo - đây không phải là điều tốt. Có thể tốt hơn để có một kDateFrom ... Và một câu hỏi nữa. Loại 2 scd trong DimDocument hoặc DimAddress - cho bộ tài liệu/địa chỉ của một Person hoặc cái gì? – Argnist

+0

@Argnist. chúng tôi sẽ sử dụng hai khóa thay thế nguyên kcPerson và kPerson.kperson sẽ là một chìa khóa thay thế trỏ đến cá nhân duy nhất (bất kể thay đổi tên/thay đổi giới tính, vv), kcperson sẽ là một chìa khóa thay thế trỏ đến trường hợp cụ thể của người đó (tên/giới tính cụ thể của họ). Có một kiểm tra của liên kết tôi bao gồm. Chúng tôi không giữ các khóa tự nhiên trên bảng thực tế. luôn luôn thay thế các phím - nhanh hơn nhiều, cũng xoay quanh vấn đề khi người dùng doanh nghiệp của bạn muốn thay đổi tên khóa tự nhiên, nhưng giữ lại một liên kết đến lịch sử (có chúng tôi đã có nó xảy ra !!) –

Các vấn đề liên quan