Modelowanie skarbca danych

Prosty model skarbca danych z dwoma hubami (niebieski), jednym łącznikiem (zielony) i czterema satelitami (żółty)

Data vault próbuje rozwiązać problem radzenia sobie ze zmianami w środowisku poprzez oddzielenie kluczy biznesowych (które nie mutują tak często, ponieważ jednoznacznie identyfikują podmiot biznesowy) i asocjacji między tymi kluczami biznesowymi, od atrybutów opisowych tych kluczy.

Klucze biznesowe i ich asocjacje są atrybutami strukturalnymi, tworzącymi szkielet modelu danych. Metoda skarbca danych ma jako jeden ze swoich głównych aksjomatów to, że rzeczywiste klucze biznesowe zmieniają się tylko wtedy, gdy zmienia się biznes i dlatego są najbardziej stabilnymi elementami, z których można wyprowadzić strukturę historycznej bazy danych. Jeśli użyjesz tych kluczy jako szkieletu hurtowni danych, możesz zorganizować wokół nich resztę danych. Oznacza to, że wybór właściwych kluczy dla hubów ma kluczowe znaczenie dla stabilności modelu. Klucze przechowywane są w tabelach z kilkoma ograniczeniami struktury. Te tabele z kluczami nazywane są hubami.

HubyEdit

Huby zawierają listę unikalnych kluczy biznesowych o niskiej skłonności do zmian. Huby zawierają również klucz zastępczy dla każdego elementu Hubu oraz metadane opisujące pochodzenie klucza biznesowego. Atrybuty opisowe informacji o hubie (takie jak opis klucza, ewentualnie w wielu językach) są przechowywane w strukturach zwanych tabelami satelitarnymi, które zostaną omówione poniżej.

Hub zawiera co najmniej następujące pola:

• klucz zastępczy, używany do łączenia innych struktur z tą tabelą.
• klucz biznesowy, sterownik dla tego huba. Klucz biznesowy może składać się z wielu pól.
• źródło rekordu, które może być użyte do sprawdzenia, który system załadował każdy klucz biznesowy jako pierwszy.
• opcjonalnie, można również posiadać pola metadanych z informacjami o ręcznych aktualizacjach (użytkownik/czas) oraz datę wyodrębnienia.

Koncentrator nie może zawierać wielu kluczy biznesowych, z wyjątkiem sytuacji, gdy dwa systemy dostarczają ten sam klucz biznesowy, ale z kolizjami, które mają różne znaczenia.

Koncentratory powinny zwykle mieć co najmniej jednego satelitę.

Przykład koncentratoraEdit

To jest przykład dla tabeli koncentratora zawierającej samochody, o nazwie „Samochód” (H_CAR). Kluczem napędowym jest numer identyfikacyjny pojazdu.

LinkiEdit

Asocjacje lub transakcje między kluczami biznesowymi (odnoszące na przykład węzły dla klienta i produktu ze sobą poprzez transakcję zakupu) są modelowane za pomocą tabel linków. Tabele te są w zasadzie tabelami złączonymi typu many-to-many, z pewnymi metadanymi.

Łącza mogą łączyć się z innymi łączami, aby poradzić sobie ze zmianami w ziarnistości (na przykład dodanie nowego klucza do tabeli bazy danych zmieniłoby ziarnistość tabeli bazy danych). Na przykład, jeśli masz skojarzenie między klientem a adresem, możesz dodać odniesienie do łącza między węzłami dla produktu i firmy transportowej. Może to być link o nazwie „Dostawa”. Odwoływanie się do łącza w innym łączu jest uważane za złą praktykę, ponieważ wprowadza zależności między łączami, które utrudniają ładowanie równoległe. Ponieważ link do innego linku jest tym samym, co nowy link z hubami z innego linku, w takich przypadkach tworzenie linków bez odwoływania się do innych linków jest preferowanym rozwiązaniem (zobacz sekcję dotyczącą praktyk ładowania, aby uzyskać więcej informacji).

Linki czasami łączą huby z informacjami, które same w sobie nie są wystarczające do skonstruowania huba. Dzieje się tak, gdy jeden z kluczy biznesowych powiązanych przez link nie jest prawdziwym kluczem biznesowym. Jako przykład weźmy formularz zamówienia z „numerem zamówienia” jako kluczem i liniami zamówienia, które są kluczowane pół-losowym numerem, aby uczynić je unikalnymi. Powiedzmy, że „unikalny numer”. Ten ostatni klucz nie jest prawdziwym kluczem biznesowym, więc nie jest hubem. Jednak musimy go użyć, aby zagwarantować właściwą granularność dla łącza. W tym przypadku nie używamy huba z kluczem zastępczym, lecz dodajemy sam klucz biznesowy „unikalny numer” do powiązania. Robi się to tylko wtedy, gdy nie ma możliwości wykorzystania klucza biznesowego dla innego powiązania lub jako klucza dla atrybutów w satelicie. Konstrukcja ta została nazwana przez Dana Linstedta na jego (nieistniejącym już) forum „łączem z kołkami”.

Łącza zawierają klucze zastępcze dla węzłów, które są połączone, ich własny klucz zastępczy dla łącza oraz metadane opisujące pochodzenie powiązania. Atrybuty opisowe dla informacji o powiązaniu (takie jak czas, cena lub kwota) są przechowywane w strukturach zwanych tabelami satelitarnymi, które są omówione poniżej.

Przykład powiązaniaEdit

To jest przykład tabeli powiązań między dwoma węzłami dla samochodów (H_CAR) i osób (H_PERSON). Link nazywa się „Kierowca” (L_DRIVER).

SatellitesEdit

Piasty i linki tworzą strukturę modelu, ale nie mają atrybutów czasowych i nie przechowują atrybutów opisowych. Są one przechowywane w osobnych tabelach zwanych satelitami. Zawierają one metadane łączące je z ich macierzystym węzłem lub łączem, metadane opisujące pochodzenie asocjacji i atrybutów, a także oś czasu z datą początkową i końcową dla atrybutu. Podczas gdy węzły i łącza zapewniają strukturę modelu, satelity dostarczają „mięso” modelu, kontekst dla procesów biznesowych, które są uchwycone w węzłach i łączach. Atrybuty te są przechowywane zarówno w odniesieniu do szczegółów sprawy, jak i osi czasu i mogą obejmować zakres od dość złożonych (wszystkie pola opisujące kompletny profil klienta) do dość prostych (satelita na łączu z tylko ważnym wskaźnikiem i osią czasu).

Zazwyczaj atrybuty są pogrupowane w satelitach według systemu źródłowego. Jednak atrybuty opisowe, takie jak rozmiar, koszt, prędkość, ilość lub kolor, mogą zmieniać się w różnym tempie, więc możesz również podzielić te atrybuty w różnych satelitach w oparciu o ich tempo zmian.

Wszystkie tabele zawierają metadane, minimalnie opisujące przynajmniej system źródłowy i datę, w której ten wpis stał się ważny, co daje pełny historyczny widok danych w momencie ich wejścia do hurtowni danych.

Przykład satelityEdit

To jest przykład satelity na łączu kierowcy między węzłami dla samochodów i osób, o nazwie „Ubezpieczenie kierowcy” (S_DRIVER_INSURANCE). Satelita ten zawiera atrybuty specyficzne dla ubezpieczenia relacji między samochodem a osobą nim kierującą, na przykład wskaźnik, czy jest to główny kierowca, nazwę firmy ubezpieczeniowej dla tego samochodu i osoby (może to być również osobny węzeł) oraz podsumowanie liczby wypadków z udziałem tej kombinacji pojazdu i kierowcy. Zawiera również odniesienie do tabeli o nazwie R_RISK_CATEGORY zawierającej kody kategorii ryzyka, do której zalicza się ten związek.

.

(*) co najmniej jeden atrybut jest obowiązkowy.(**) numer sekwencji staje się obowiązkowy, jeśli jest potrzebny do wymuszenia unikalności dla wielu ważnych satelitów na tym samym węźle lub łączu.

Tabele referencyjneEdit

Tablice referencyjne są normalną częścią zdrowego modelu skarbca danych. Ich zadaniem jest zapobieganie nadmiarowemu przechowywaniu prostych danych referencyjnych, do których często się odwołujemy. Bardziej formalnie Dan Linstedt definiuje dane referencyjne w następujący sposób:

Wszystkie informacje uważane za niezbędne do rozwiązania opisów z kodów lub do przetłumaczenia kluczy na (sic) spójny sposób. Wiele z tych pól ma charakter „opisowy” i opisuje określony stan innych, ważniejszych informacji. Jako takie, dane referencyjne żyją w oddzielnych tabelach niż surowe tabele Data Vault.

Tabele referencyjne są przywoływane z satelitów, ale nigdy nie są związane fizycznymi kluczami obcymi. Nie ma zalecanej struktury dla tabel referencyjnych: użyj tego, co najlepiej sprawdza się w Twoim konkretnym przypadku, od prostych tabel wyszukujących do małych skarbców danych lub nawet gwiazd. Mogą one być historyczne lub nie mieć historii, ale zaleca się, aby trzymać się kluczy naturalnych i nie tworzyć kluczy zastępczych w tym przypadku. Zwykle skarbce danych mają wiele tabel referencyjnych, tak jak każda inna hurtownia danych.

Przykład odniesieniaEdit

To jest przykład tabeli referencyjnej z kategoriami ryzyka dla kierowców pojazdów. Można się do niej odwołać z dowolnej satelity w hurtowni danych. Na razie odwołujemy się do niej z satelity S_DRIVER_INSURANCE. Tabela referencyjna to R_RISK_CATEGORY.

.

(*) co najmniej jeden atrybut jest obowiązkowy.