Modelowanie przechowalni danych

Prosty model magazynu danych z dwoma koncentratorami (niebieski), jednym łączem (zielony) i czterema satelitami (żółty)

Modelowanie magazynu danych to metoda modelowania bazy danych , która została zaprojektowana w celu zapewnienia długoterminowego przechowywania danych historycznych pochodzących z wielu systemów operacyjnych. Jest to również metoda patrzenia na dane historyczne, która zajmuje się takimi zagadnieniami jak audyt, śledzenie danych, szybkość ładowania i odporność na zmiany, a także podkreśla potrzebę śledzenia, skąd pochodzą wszystkie dane w bazie danych. Oznacza to, że każdemu wierszowi w magazynie danych muszą towarzyszyć atrybuty źródła rekordu i daty ładowania, co umożliwia audytorowi prześledzenie wartości z powrotem do źródła. Został opracowany przez Daniela (Dana) Linstedta w 2000 roku.

Modelowanie przechowalni danych nie rozróżnia dobrych i złych danych („złe” oznacza niezgodność z regułami biznesowymi). Podsumowano to w stwierdzeniu, że przechowalnia danych przechowuje „pojedynczą wersję faktów” (wyrażoną również przez Dana Linstedta jako „wszystkie dane przez cały czas”), w przeciwieństwie do praktyki stosowanej w innych metodach przechowywania danych hurtowni danych „ jedna wersja prawdy ”, gdzie dane niezgodne z definicjami są usuwane lub „czyszczone”.

Metoda modelowania została zaprojektowana tak, aby była odporna na zmiany w środowisku biznesowym, z którego pochodzą przechowywane dane, poprzez wyraźne oddzielenie informacji strukturalnych od atrybutów opisowych. Przechowalnia danych została zaprojektowana tak, aby umożliwić jak największe ładowanie równoległe, dzięki czemu bardzo duże implementacje mogą być skalowane bez konieczności gruntownego przeprojektowania.

Historia i filozofia

W modelowaniu hurtowni danych istnieją dwie dobrze znane konkurujące ze sobą opcje modelowania warstwy, w której przechowywane są dane. Albo modelujesz według Ralpha Kimballa z dopasowanymi wymiarami i korporacyjną magistralą danych , albo modelujesz według Billa Inmona ze znormalizowaną bazą danych ^{[ potrzebne źródło ]} . Obie techniki mają problemy podczas radzenia sobie ze zmianami w systemach zasilających hurtownię danych ^{[ potrzebne źródło ]} . W przypadku zgodnych wymiarów należy również wyczyścić dane (aby je dostosować), co jest niepożądane w wielu przypadkach, ponieważ nieuchronnie spowoduje to utratę informacji ^{[ potrzebne źródło ]} . Magazyn danych ma na celu uniknięcie lub zminimalizowanie wpływu tych problemów poprzez przeniesienie ich do obszarów hurtowni danych, które znajdują się poza historycznym obszarem przechowywania (czyszczenie odbywa się w hurtowniach danych) oraz poprzez oddzielenie elementów strukturalnych (klucze biznesowe i powiązania między kluczami biznesowymi) z atrybutów opisowych.

Dan Linstedt, twórca metody, opisuje powstałą bazę danych w następujący sposób:

„Model Data Vault to zorientowane na szczegóły, historyczne śledzenie i unikalnie połączone zestawy znormalizowanych tabel, które obsługują jeden lub więcej obszarów funkcjonalnych firmy. Jest to podejście hybrydowe obejmujące najlepsze w swojej klasie między trzecią postacią normalną (3NF) a schematem gwiaździstym . Projekt jest elastyczny, skalowalny, spójny i dopasowuje się do potrzeb przedsiębiorstwa"

Filozofia magazynu danych polega na tym, że wszystkie dane są danymi istotnymi, nawet jeśli nie są zgodne z ustalonymi definicjami i regułami biznesowymi. Jeśli dane nie są zgodne z tymi definicjami i regułami, jest to problem dla firmy, a nie dla hurtowni danych. Określenie, że dane są „błędne”, jest interpretacją danych wynikającą z określonego punktu widzenia, który może nie być ważny dla wszystkich lub w każdym momencie. Dlatego magazyn danych musi przechwytywać wszystkie dane i tylko podczas raportowania lub wyodrębniania danych z magazynu danych dane są interpretowane.

Kolejną kwestią, na którą magazyn danych jest odpowiedzią, jest rosnąca potrzeba pełnej audytowalności i identyfikowalności wszystkich danych w hurtowni danych. Ze względu na Sarbanes-Oxley w USA i podobne środki w Europie jest to istotny temat dla wielu wdrożeń Business Intelligence, dlatego każde wdrożenie przechowalni danych koncentruje się na pełnej identyfikowalności i możliwości audytu wszystkich informacji.

Data Vault 2.0 to nowa specyfikacja. Jest to otwarty standard . Nowa specyfikacja składa się z trzech filarów: metodologii (SEI/ CMMI , Six Sigma , SDLC itp.), architektury (m.in. warstwa wejściowa (data stage) i warstwa prezentacji (data mart) oraz obsługi jakości danych usługi i usługi danych podstawowych) oraz model. W ramach metodologii zdefiniowano wdrażanie najlepszych praktyk. Data Vault 2.0 koncentruje się na włączeniu nowych komponentów, takich jak duże zbiory danych , NoSQL - a także koncentruje się na wydajności istniejącego modelu. Stara specyfikacja (w większości udokumentowana tutaj) jest bardzo skoncentrowana na modelowaniu przechowalni danych. Jest to udokumentowane w książce: Tworzenie skalowalnej hurtowni danych za pomocą Data Vault 2.0.

Konieczna jest ewolucja specyfikacji w celu uwzględnienia nowych komponentów wraz z najlepszymi praktykami, aby systemy EDW i BI były na bieżąco z potrzebami i pragnieniami dzisiejszego biznesu.

Historia

Modelowanie przechowalni danych zostało pierwotnie wymyślone przez Dana Linstedta w latach 90. XX wieku i zostało wprowadzone w 2000 r. jako metoda modelowania w domenie publicznej. W serii pięciu artykułów w The Data Administration Newsletter rozszerzono i wyjaśniono podstawowe zasady metody Data Vault. Zawierają one ogólny przegląd, przegląd komponentów, omówienie dat końcowych i połączeń, tabele połączeń oraz artykuł na temat praktyk ładowania.

Alternatywną (i rzadko używaną) nazwą metody jest „Common Foundational Integration Modeling Architecture”.

Data Vault 2.0 pojawił się na scenie w 2013 roku i zapewnia Big Data, NoSQL, nieustrukturyzowaną, częściowo ustrukturyzowaną bezproblemową integrację, wraz z metodologią, architekturą i najlepszymi praktykami wdrożeniowymi.

Alternatywne interpretacje

Według Dana Linstedta model danych jest inspirowany (lub wzorowany) na uproszczonym widoku neuronów, dendrytów i synaps – gdzie neurony są powiązane z koncentratorami i satelitami koncentratorów, łącza to dendryty (wektory informacji), a inne łącza to synapsy (wektory w przeciwnym kierunku). Korzystając z zestawu algorytmów eksploracji danych, linki można oceniać z pewności i siły . Można je tworzyć i upuszczać w locie, zgodnie z poznawaniem relacji, które obecnie nie istnieją. Model może być automatycznie przekształcany, dostosowywany i dostosowywany w miarę używania i wprowadzania nowych struktur.

Według innego poglądu model magazynu danych zapewnia ontologię przedsiębiorstwa w tym sensie, że opisuje terminy w domenie przedsiębiorstwa (centra) i relacje między nimi (łącza), dodając atrybuty opisowe (satelity) tam, gdzie to konieczne.

Innym sposobem myślenia o modelu magazynu danych jest model graficzny . Model magazynu danych faktycznie zapewnia model „oparty na grafie” z koncentratorami i relacjami w świecie relacyjnej bazy danych. W ten sposób programista może używać języka SQL do uzyskiwania relacji opartych na wykresach z odpowiedziami poniżej sekundy.

Podstawowe pojęcia

Magazyn danych 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 powiązań między tymi kluczami biznesowymi, od opisowych atrybutów tych kluczy .

Klucze biznesowe i ich powiązania to atrybuty strukturalne, tworzące szkielet modelu danych. Jednym z głównych aksjomatów metody przechowywania danych jest 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 wokół nich zorganizować resztę danych. Oznacza to, że wybór odpowiednich kluczy do piast ma pierwszorzędne znaczenie dla stabilności Twojego modelu. Klucze są przechowywane w tabelach z kilkoma ograniczeniami dotyczącymi struktury. Te tabele kluczy nazywane są koncentratorami.

Piasty

Huby zawierają listę unikalnych kluczy biznesowych o niskiej skłonności do zmian. Huby zawierają również klucz zastępczy dla każdego elementu Huba oraz metadane opisujące pochodzenie klucza biznesowego . Atrybuty opisowe informacji w Hubie (takie jak opis klucza, być może 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 koncentratora. Klucz biznesowy może składać się z wielu pól.
źródło rekordów, którego można użyć do sprawdzenia, który system najpierw załadował każdy klucz biznesowy.
opcjonalnie możesz mieć również pola metadanych z informacją 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 centrum

To jest przykład tabeli centralnej zawierającej samochody, zwanej „Samochód” (H_CAR). Kluczem do jazdy jest numer identyfikacyjny pojazdu .

Nazwa pola	Opis	Obowiązkowy?	Komentarz
H_CAR_ID	Identyfikator sekwencji i klucz zastępczy dla koncentratora	NIE	Zalecane, ale opcjonalne
VEHICLE_ID_NR	Klucz biznesowy, który napędza to centrum. Może być więcej niż jednym polem dla złożonego klucza biznesowego	Tak
H_RSRC	Źródło rekordu tego klucza przy pierwszym załadowaniu	Tak
LOAD_AUDIT_ID	Identyfikator do tabeli z informacjami kontrolnymi, takimi jak czas ładowania, czas trwania ładowania, liczba wierszy itp.	NIE

Spinki do mankietów

Powiązania lub transakcje między kluczami biznesowymi (powiązania między centrami dla klienta i produktu poprzez transakcję zakupu) są modelowane za pomocą tabel powiązań. Te tabele to w zasadzie tabele łączenia wiele-do-wielu z pewnymi metadanymi.

Łącza mogą łączyć się z innymi łączami, aby radzić sobie ze zmianami szczegółowości (na przykład dodanie nowego klucza do tabeli bazy danych zmieniłoby ziarnistość tabeli bazy danych). Na przykład, jeśli masz powiązanie między klientem a adresem, możesz dodać odniesienie do łącza między hubami 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ż łącze do innego łącza jest takie samo jak nowe łącze z koncentratorami z innego łącza, w takich przypadkach preferowanym rozwiązaniem jest tworzenie łączy bez odwoływania się do innych łączy (więcej informacji znajduje się w sekcji dotyczącej praktyk ładowania).

Łącza czasami łączą koncentratory z informacjami, które same w sobie nie wystarczają do zbudowania koncentratora. Dzieje się tak, gdy jeden z kluczy biznesowych powiązanych z łączem nie jest prawdziwym kluczem biznesowym. Weźmy na przykład formularz zamówienia z „numerem zamówienia” jako kluczem i zamów wiersze z półlosową liczbą, aby uczynić je unikalnymi. Powiedzmy, „unikatowy numer”. Ten ostatni klucz nie jest prawdziwym kluczem biznesowym, więc nie jest hubem. Jednak musimy go użyć, aby zagwarantować odpowiednią szczegółowość łącza. W tym przypadku nie używamy koncentratora z kluczem zastępczym, ale dodajemy sam klucz biznesowy „unikatowy numer” do łącza. Odbywa się to tylko wtedy, gdy nie ma możliwości wykorzystania klucza biznesowego do innego łącza lub jako klucza do atrybutów w satelicie. Ten konstrukt został nazwany przez Dana Linstedta na jego (nieistniejącym już) forum „łączem z peg-legged”.

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

Przykład linku

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ę „Sterownik” (L_DRIVER).

Nazwa pola	Opis	Obowiązkowy?	Komentarz
L_ID_KIEROWCY	Identyfikator sekwencji i klucz zastępczy dla łącza	NIE	Zalecane, ale opcjonalne
H_CAR_ID	klucz zastępczy do piasty samochodu, pierwsza kotwica ogniwa	Tak
H_PERSON_ID	klucz zastępczy dla centrum osoby, druga kotwica łącza	Tak
L_RSRC	Źródło rekordów tego powiązania przy pierwszym załadowaniu	Tak
LOAD_AUDIT_ID	Identyfikator do tabeli z informacjami kontrolnymi, takimi jak czas ładowania, czas trwania ładowania, liczba wierszy itp.	NIE

Satelity

Piasty i łącza tworzą strukturę modelu, ale nie mają atrybutów czasowych ani atrybutów opisowych. Są one przechowywane w osobnych tabelach zwanych satelitami . Obejmują one metadane łączące je z nadrzędnym centrum lub łączem, metadane opisujące pochodzenie powiązania i atrybutów, a także oś czasu z datami rozpoczęcia i zakończenia atrybutu. Tam, gdzie koncentratory i łącza zapewniają strukturę modelu, satelity zapewniają „mięso” modelu, kontekst dla procesów biznesowych, które są uchwycone w koncentratorach i łączach. Atrybuty te są przechowywane zarówno w odniesieniu do szczegółów sprawy, jak i osi czasu i mogą wahać się od dość złożonych (wszystkie pola opisujące pełny profil klienta) do całkiem prostych (satelita na łączu z tylko ważnym wskaźnikiem i oś czasu).

Zwykle atrybuty są pogrupowane w satelity 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 na różne satelity w oparciu o ich tempo zmian.

Wszystkie tabele zawierają metadane, które w minimalnym stopniu opisują przynajmniej system źródłowy i datę, w której ten wpis stał się ważny, dając pełny widok historyczny danych w momencie ich wprowadzania do hurtowni danych.

Przykład satelity

To jest przykład satelity na łączu kierowców między węzłami dla samochodów i osób, o nazwie „Ubezpieczenie kierowcy” (S_DRIVER_INSURANCE). Ten satelita zawiera atrybuty, które są specyficzne dla ubezpieczenia relacji między samochodem a osobą, która go prowadzi, na przykład wskazanie, czy jest to główny kierowca, nazwa firmy ubezpieczeniowej dla tego samochodu i osoby (może to być również osobny hub) oraz zestawienie liczby wypadków z udziałem tego zespołu pojazdu i kierowcy. Dołączone jest również odniesienie do tabeli przeglądowej lub tabeli referencyjnej o nazwie R_RISK_CATEGORY zawierającej kody kategorii ryzyka, w której uważa się, że ta zależność należy do kategorii.

Nazwa pola	Opis	Obowiązkowy?	Komentarz
S_DRIVER_INSURANCE_ID	Identyfikator sekwencji i klucz zastępczy dla satelity na łączu	NIE	Zalecane, ale opcjonalne
L_ID_KIEROWCY	(Zastępczy) klucz podstawowy dla łącza kierowcy, rodzic satelity	Tak
S_SEQ_NR	Numer porządkowy lub sekwencyjny, aby wymusić unikalność, jeśli istnieje kilka ważnych satelitów dla jednego klucza nadrzędnego	NIE(**)	Może się tak zdarzyć, jeśli na przykład masz KURS w centrum, a nazwa kursu jest atrybutem, ale w kilku różnych językach.
S_LDTS	Załaduj datę (datę początkową) ważności tej kombinacji wartości atrybutów dla klucza nadrzędnego L_DRIVER_ID	Tak
S_LEDTS	Załaduj datę końcową (datę końcową) ważności tej kombinacji wartości atrybutów dla klucza nadrzędnego L_DRIVER_ID	NIE
IND_PRIMARY_DRIVER	Wskazuje, czy kierowca jest głównym kierowcą tego samochodu	NIE (*)
FIRMA UBEZPIECZENIOWA	Nazwa firmy ubezpieczeniowej dla tego pojazdu i tego kierowcy	NIE (*)
NR_OF_ACCIDENTS	Liczba wypadków tego kierowcy w tym pojeździe	NIE (*)
R_RISK_CATEGORY_CD	Kategoria ryzyka dla kierowcy. To jest odniesienie do R_RISK_CATEGORY	NIE (*)
S_RSRC	Źródło rekordów informacji w tym satelicie przy pierwszym załadowaniu	Tak
LOAD_AUDIT_ID	Identyfikator do tabeli z informacjami kontrolnymi, takimi jak czas ładowania, czas trwania ładowania, liczba wierszy itp.	NIE

(*) co najmniej jeden atrybut jest obowiązkowy. (**) numer kolejny staje się obowiązkowy, jeśli jest potrzebny do wyegzekwowania niepowtarzalności wielu ważnych satelitów w tym samym hubie lub łączu.

Tabele referencyjne

Tabele referencyjne są normalną częścią zdrowego modelu przechowalni danych. Są tam, aby zapobiec nadmiarowemu przechowywaniu prostych danych referencyjnych, do których często się odwołuje. Bardziej formalnie Dan Linstedt definiuje dane referencyjne w następujący sposób:

Wszelkie informacje uznane za niezbędne do rozwiązania opisów z kodów lub 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. W związku z tym dane referencyjne znajdują się w oddzielnych tabelach od nieprzetworzonych tabel Data Vault .

Tabele referencyjne są przywoływane z satelitów, ale nigdy nie są powiązane z fizycznymi kluczami obcymi. Nie ma zalecanej struktury tabel referencyjnych: użyj tego, co najlepiej sprawdza się w twoim konkretnym przypadku, od prostych tabel przeglądowych po małe przechowalnie danych, a nawet gwiazdki. Mogą być historyczne lub nie mieć historii, ale zaleca się trzymanie się kluczy naturalnych i nie tworzenie kluczy zastępczych w takim przypadku. Zwykle magazyny danych mają wiele tabel referencyjnych, tak jak każda inna hurtownia danych.

Przykład referencyjny

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

Nazwa pola	Opis	Obowiązkowy?
R_RISK_CATEGORY_CD	Kod kategorii ryzyka	Tak
RISK_CATEGORY_DESC	Opis kategorii ryzyka	NIE (*)

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

Praktyki ładowania

Proces ETL służący do aktualizowania modelu magazynu danych jest dość prosty (zobacz Data Vault Series 5 — Praktyki ładowania ). Najpierw musisz załadować wszystkie koncentratory, tworząc identyfikatory zastępcze dla nowych kluczy biznesowych. Po wykonaniu tej czynności możesz teraz rozwiązać wszystkie klucze biznesowe, aby zastąpić identyfikatory, jeśli wyślesz zapytanie do centrum. Drugim krokiem jest rozwiązanie powiązań między koncentratorami i utworzenie identyfikatorów zastępczych dla wszelkich nowych powiązań. W tym samym czasie możesz także utworzyć wszystkie satelity, które są podłączone do koncentratorów, ponieważ możesz rozwiązać klucz na identyfikator zastępczy. Po utworzeniu wszystkich nowych łączy z kluczami zastępczymi możesz dodać satelity do wszystkich łączy.

Ponieważ koncentratory nie są ze sobą połączone inaczej niż za pomocą łączy, można ładować wszystkie koncentratory równolegle. Ponieważ linki nie są połączone bezpośrednio ze sobą, możesz również ładować wszystkie linki równolegle. Ponieważ satelity można podłączać tylko do koncentratorów i łączy, można je również ładować równolegle.

ETL jest dość prosty i nadaje się do łatwej automatyzacji lub tworzenia szablonów. Problemy występują tylko w przypadku łączy odnoszących się do innych łączy, ponieważ rozwiązanie kluczy biznesowych w łączu prowadzi tylko do innego łącza, które również należy rozwiązać. Ze względu na równoważność tej sytuacji z połączeniem z wieloma węzłami, trudności tej można uniknąć, przemodelowując takie przypadki i jest to w rzeczywistości zalecana praktyka.

Dane nigdy nie są usuwane z magazynu danych, chyba że wystąpi błąd techniczny podczas ładowania danych.

Magazyn danych i modelowanie wymiarowe

Warstwa modelowana magazynu danych jest zwykle używana do przechowywania danych. Nie jest zoptymalizowany pod kątem wydajności zapytań ani nie jest łatwy do wykonywania zapytań za pomocą dobrze znanych narzędzi do zapytań, takich jak Cognos , Oracle Business Intelligence Suite Enterprise Edition , SAP Business Objects , Pentaho i in. ^{[ Potrzebne źródło ]} Ponieważ te narzędzia komputerowe dla użytkowników końcowych oczekują lub wolą, aby ich dane były zawarte w modelu wielowymiarowym , zwykle konieczna jest konwersja.

W tym celu koncentratory i powiązane satelity na tych koncentratorach można uznać za wymiary, a łącza i powiązane satelity na tych łączach można postrzegać jako tabele faktów w modelu wymiarowym. Umożliwia to szybkie prototypowanie modelu wymiarowego z modelu przechowalni danych przy użyciu widoków.

Należy zauważyć, że chociaż stosunkowo łatwo jest przenieść dane z modelu przechowalni danych do (oczyszczonego) modelu wymiarowego, odwrotna sytuacja nie jest tak łatwa, biorąc pod uwagę zdenormalizowaną naturę tabel faktów modelu wymiarowego, zasadniczo różniących się od trzeciej postaci normalnej przechowalnia danych.

Metodologia przechowywania danych

Metodologia przechowalni danych oparta jest na najlepszych praktykach SEI / CMMI Level 5. Zawiera wiele komponentów CMMI Level 5 i łączy je z najlepszymi praktykami z Six Sigma , TQM i SDLC. W szczególności koncentruje się na zwinnej metodologii Scotta Amblera w zakresie budowania i wdrażania. Projekty przechowalni danych mają krótki, kontrolowany zakresem cykl wydawniczy i powinny składać się z wersji produkcyjnej co 2–3 tygodnie.

Zespoły korzystające z metodologii przechowywania danych powinny łatwo dostosowywać się do powtarzalnych, spójnych i mierzalnych projektów, których oczekuje się na poziomie 5 CMMI. Dane przepływające przez system przechowywania danych EDW zaczną podlegać cyklowi życia TQM (total quality management), który którego od dawna brakowało w projektach BI (business intelligence).

Narzędzia

Niektóre przykłady narzędzi to: ^{[ wymagane wyjaśnienie ]}

Zobacz też

Cytaty

Źródła

Linstedt, Dan (grudzień 2010). Doładuj swoją hurtownię danych . Dana Linstedta. ISBN 978-0-9866757-1-3 .
Thomasa C. Hammergrena; Alan R. Simon (luty 2009). Hurtownia danych dla bystrzaków, wydanie drugie . John Wiley & Synowie. ISBN 978-0-470-40747-9 .
Ronalda Damhofa; Lidwine van As (25 sierpnia 2008). „EDW nowej generacji - Porzucenie idei jednej wersji prawdy” (PDF) . Magazyn bazy danych (DB/M) . Array Publications BV
Linstedt, Dan. „Data Vault Series 1 – Przegląd przechowalni danych” . Seria przechowalni danych . Biuletyn administracji danych . Źródło 12 września 2011 r .
Linstedt, Dan. „Data Vault Series 2 — komponenty Data Vault” . Seria przechowalni danych . Biuletyn administracji danych . Źródło 12 września 2011 r .
Linstedt, Dan. „Data Vault Series 3 — daty końcowe i podstawowe połączenia” . Seria przechowalni danych . Biuletyn administracji danych . Źródło 12 września 2011 r .
Linstedt, Dan. „Data Vault Series 4 — Tabele połączeń” . Seria przechowalni danych . Biuletyn administracji danych . Źródło 12 września 2011 r .
Linstedt, Dan. „Data Vault Series 5 — praktyki ładowania” . Seria przechowalni danych . Biuletyn administracji danych . Źródło 12 września 2011 r .
Kunenborg, Ronald. „Ściągawka reguł przechowalni danych w wersji 1.0.8” (PDF) . Reguły magazynu danych . Grundsätzlich IT . Źródło 26 września 2012 r . Ściągawka odzwierciedlająca zasady w wersji 1.0.8 i dodatkowe wyjaśnienia z forów dotyczące zasad w wersji 1.0.8.
Linstedt, Dan. „Specyfikacja modelowania magazynu danych, wersja 1.0.9” . Forum magazynu danych . Dana Linstedta . Źródło 26 września 2012 r .
Linstedt, Dan. „Specyfikacja ładowania magazynu danych w wersji 1.2” . DanLinstedt.com . Dana Linstedta . Źródło 2014-01-03 .
Linstedt, Dan. „Krótkie wprowadzenie do #datavault 2.0” . DanLinstedt.com . Dana Linstedta . Źródło 2014-01-03 .
Linstedt, Dan. „Ogłoszenie Data Vault 2.0” . DanLinstedt.com . Dana Linstedta . Źródło 2014-01-03 .

źródła w języku niderlandzkim

Ketelaars, MWAM (2005-11-25). „Modele hurtowni danych z magazynem danych”. Magazyn bazy danych (DB/M) . Tablica Publications BV (7): 36–40.
Verhagen, K.; Vrijkorte, B. (10 czerwca 2008). „Relacja kontra przechowalnia danych”. Magazyn bazy danych (DB/M) . Tablica Publications BV (4): 6–9.

Literatura

Patrick Cuba: guru przechowalni danych. Pragmatyczny przewodnik po budowaniu przechowalni danych. Selbstverlag, ohne Ort 2020, ISBN 979-86-9130808-6.
John Giles: Słoń w lodówce. Przewodnik po krokach prowadzących do sukcesu magazynu danych poprzez budowanie modeli zorientowanych na biznes. Technika, Basking Ridge 2019, ISBN 978-1-63462-489-3 .
Kent Graziano: Lepsze modelowanie danych. Wprowadzenie do zwinnej inżynierii danych przy użyciu Data Vault 2.0. Wojownik danych, Houston 2015.
Hans Hultgren: Modelowanie zwinnej hurtowni danych za pomocą Data Vault. Brighton Hamilton, Denver ua 2012, ISBN 978-0-615-72308-2 .
Dirk Lerner: Magazyn danych dla zwinnej architektury hurtowni danych. W: Stephan Trahasch, Michael Zimmer (Hrsg.): Agile Business Intelligence. Teoria i praktyka. dpunkt.verlag, Heidelberg 2016, ISBN 978-3-86490-312-0, S. 83–98.
Daniel Linstedt: Doładuj swoją hurtownię danych. Nieocenione zasady modelowania danych do wdrożenia magazynu danych. Linstedt, Saint Albans, Vermont 2011, ISBN 978-1-4637-7868-2 .
Daniel Linstedt, Michael Olschimke: Budowanie skalowalnej hurtowni danych z Data Vault 2.0. Morgan Kaufmann, Waltham, Massachusetts 2016, ISBN 978-0-12-802510-9 .
Dani Schnider, Claus Jordan UA: Plany hurtowni danych. Business Intelligence w praktyce. Hanser, Monachium 2016, ISBN 978-3-446-45075-2 , S. 35–37, 161–173.

Linki zewnętrzne