Mam kilka podmiotów w mojej hurtowni danych:Jak utworzyć tabelę faktów historycznych?
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
Dokument - documentId, liczbę, rodzaj
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:
- 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!
@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
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
@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 !!) –