2011-05-21 30 views
9

Mam kilka podmiotów w mojej hurtowni danych:Jak utworzyć tabelę faktów historycznych?

  1. Osoba - z atrybutami PersonID, dateFrom, dateTo i innych tych może być zmieniony, na przykład nazwisko, data urodzenia i tak dalej - powoli zmienia wymiar

  2. Dokument - documentId, liczbę, rodzaj

  3. Adres - addressId, miasto, ulica, nr domu, mieszkania

Relacje między (osobą i dokumentem) to jeden do wielu, a (osoba i adres) to wiele-wiele.

Moim celem jest stworzenie historii tabelę faktów, które mogą nam odpowiedzieć na następujące pytania:

  1. które osoby z co dokumenty żył na zdefiniowany adres w określonym terminie?

2, Jaka historia mieszkańców ma zdefiniowany adres w określonym przedziale czasu?

To nie tylko dla tego, co DW jest zaprojektowane, ale myślę, że jest to najtrudniejsze w projekcie DW.

Na przykład, Miss Brown z personId = 1, dokumenty z identyfikatorem documentId = 1 i documentId = 2 były przechowywane pod adresem o adresie address = 1 od 01.01.2005 do 02.02.2010, a następnie przeniesione do addressId = 2 gdzie był żył od 02.03.2010 do bieżącej daty (NULL?). Ale zmieniła nazwisko na Mrs Green od 04/05/2006 i jej pierwszy dokument z documentId = 1 do documentId = 3 od 06/07/2007. Mr Black z personId = 2, documentId = 4 mieszkał na adres addressId = 1 od 02.03.2010 do bieżącej daty.

Oczekiwany wynik naszego zapytania dla pytania 2 gdzie addressId = 1, a czas jest przedział od 01/01/2000 do teraz, musi być jak:

rzędów:

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 

miałem pomysł na tworzenie tabeli faktów z kluczem złożonym (personId, documentId, addressId, dateFrom), ale nie mam pojęcia, jak załadować tę tabelę, a następnie uzyskać oczekiwany wynik z tą strukturą.

Będę zadowolony z każdej pomocy!

Odpowiedz

3

Interesujące pytanie @Arnistom!

więc stworzyć jakiś wspólny język na moim przykładzie, chcesz

  • DimPerson (PK = kcPerson, klucz suggorate unikalnych Osoby = kPerson, typ 2 dim)
  • DimDocument (PK = kcDocument, kluczem suggorate unikalnych dokumentów = kDocument, typ 2 dim)
  • DimAddress (PK = kcAddress, klucz suggorate unikalnych adresów = kAddress, typ 2 dim)

kolega napisał krótki blog na t użył dwóch zastępczych kluczy, aby wyjaśnić powyższe wartości "Using Two Surrogate Keys on Dimensions".

Zawsze dodaję DimDate z PK w postaci yyyymmdd do dowolnej hurtowni danych z dodatkowymi kolumnami atrybutów.

Wtedy masz tabelę faktów jak

  • FactHistory (FKS = kcPerson, kPerson, kcDocument, kDocument, kcPerson, kPerson, kDate) plus wszelkie aditional środków.

Następnie dołączając do "kc" można wyświetlić aktualne informacje o wymiarach Osoba/Dokument/Adres. Jeśli dołączyłeś do "k", możesz wyświetlić historyczne informacje o wymiarach Osoba/Dokument/Adres.

Wadą tego jest fakt, że ta tabela faktów wymaga jednego wiersza dla każdej kombinacji osoba/dokument/adres/data. Ale to naprawdę bardzo wąska tabela, ponieważ tabela ma po prostu kilka kluczy obcych.

Zaletą tego jest to, że bardzo łatwo jest zapytać o pytania, które zadawałeś.

Alternatywnie, można mieć tabeli faktów, jak

  • FactHistory (FKS = kcPerson, kPerson, kcDocument, kDocument, kcPerson, kPerson, kDateFrom, kDateTo) plus wszelkie aditional środków.

Jest to oczywiście znacznie bardziej kompaktowe, ale zapytania stają się bardziej złożone. Można również wyświetlić widok tabeli Fakt, aby ułatwić wyszukiwanie!

Wybór rozwiązania zależy od częstotliwości zmiany danych. Podejrzewam, że to się nie zmieni tak szybko, więc alternatywny projekt tabeli faktów może być lepszy.

Nadzieję, że pomaga.

+0

@Marcus D Dziękuję. Myślałem podobnie, ale bez klawiszy "k" w tabeli faktów (Czy rozumiem twoje imiona właściwie? KcPerson - klucz zastępczy do indentyfikacji wiersza, a kPerson - klucz naturalny do identyfikacji jednej osoby?). – Argnist

+0

Ale FactHistory (FKs = kcPerson, kPerson, kcDocument, kDocument, kcAddress, kAddress, kDateFrom, kDateTo) daje, że musimy zaktualizować stare fakty "kDateTo - to nie jest dobre, pomyślałem. Może lepiej mieć jeden kDateFrom ... I jedno pytanie więcej. Typ 2 scd w DimDocument lub DimAddress - dla zestawu dokumentów/adresów jednej osoby lub czego? – Argnist

+0

@Argnist. użylibyśmy dwóch całkowitych kluczy zastępczych kcPerson i kPerson.Kperson byłby zastępczym kluczem wskazującym unikalną osobę (bez względu na zmiany nazwiska/zmiany płci itp.), kcperson byłby zastępczym kluczem, który wskazuje na konkretną instancję tej osoby (jej konkretne imię/płeć itp.). Sprawdź link, który zawarłem. Nie przechowujemy naturalnych kluczy na stołach faktów. zawsze klucze zastępcze - znacznie szybciej, omija problem, gdy użytkownicy biznesowi chcą zmienić nazwę klucza naturalnego, ale zachowują link do historii (tak, tak się stało !!) –

Powiązane problemy