Udviklingen af DATA VAULT og overgangen til BUSINESS DATA VAULT

I den tidligere artikel har jeg beskrevet grundlaget for DATA VAULT, forklaret de vigtigste elementer i DATA VAULT og deres formål. Emnet DATA VAULT kan dog ikke betragtes som udtømt, da vi skal tale om de næste skridt i evolutionen af DATA VAULT.

I denne artikel vil jeg fokusere på udviklingen af DATA VAULT og overgangen til BUSINESS DATA VAULT eller blot BUSINESS VAULT.

Årsagerne til opkomsten af BUSINESS DATA VAULT

Det bør bemærkes, at DATA VAULT, selvom det har visse styrker, ikke er uden svagheder. En af disse svagheder er kompleksiteten ved at skrive analytiske forespørgsler. Forespørgslerne har et betydeligt antal JOINs, og koden bliver lang og klodset. Derudover gennemgår dataene, der kommer ind i DATA VAULT, ingen transformationer, hvilket betyder, at DATA VAULT i sin rene form ikke nødvendigvis har værdi for forretningen.

Netop for at afhjælpe disse svagheder er metodologien DATA VAULT blevet udvidet med elementer som:

• PIT (point in time) tabeller;
• BRIDGE tabeller;
• PREDEFINED DERIVATIONS.

Lad os se nærmere på formålet med disse elementer.

PIT tabeller

Generelt kan én forretningsenhed (HUB) have data med forskellige opdateringsfrekvenser. For eksempel, når vi taler om data, der karakteriserer en person, kan vi sige, at oplysninger om telefonnummer, adresse eller e-mail har en højere opdateringsfrekvens end for eksempel navn, pasoplysninger, civilstand eller køn.

Derfor bør man tage højde for opdateringsfrekvensen, når man definerer satellitter. Hvorfor er det vigtigt?

Hvis man opbevarer attributter med forskellige opdateringsfrekvenser i én tabel, skal man tilføje en række i tabellen ved hver opdatering af den mest hyppigt ændrede attribut. Som følge heraf øges diskpladsen, og udførelsestiden for forespørgslerne stiger.

Nu, når vi har opdelt satellitterne efter opdateringsfrekvens, og vi kan indlæse data i dem uafhængigt, skal vi sikre os mulighed for at få adgang til aktuelle data. Helst uden at bruge unødvendige JOINs.

For example, it is necessary to obtain up-to-date information from satellites with different update frequencies. This not only requires making a JOIN but also creating several nested queries (to each satellite containing information) with the selection of the maximum update date MAX(Update Date). With each new JOIN, such code grows and quickly becomes complex to understand.

The PIT table is designed to simplify such queries, and the PIT tables are filled simultaneously with the recording of new data into the DATA VAULT. PIT table:

Thus, we have information about the relevance of data across all satellites at any given moment. By using JOINs to the PIT table, we can completely eliminate nested queries, provided that the PIT is filled daily and without omissions. Even if there are gaps in the PIT, the latest data can only be obtained using a single nested query to the PIT itself. One nested query will run faster than nested queries to each satellite.

BRIDGE

BRIDGE-type tables are also used to simplify analytical queries. However, unlike the PIT, they serve to simplify and accelerate queries between different hubs, links, and their satellites.

The table contains all necessary keys for all satellites that are frequently used in queries. Additionally, if needed, hashed business keys can be supplemented with textual keys when the names of keys are required for analysis.

The fact is that without the use of BRIDGE, obtaining data from satellites belonging to different hubs will require not only joining the satellites themselves but also the links that connect the hubs.

The presence or absence of a BRIDGE is determined by the storage configuration and the need to optimize the speed of query execution. It is difficult to come up with a universal example of a BRIDGE.

PREDEFINED DERIVATIONS

Another type of object that brings us closer to the BUSINESS DATA VAULT is tables containing pre-calculated metrics. Such tables are indeed important for business, as they contain information aggregated according to specified rules and allow relatively easy access to this information.

Arkitektoniske PREDEFINED DERIVATIONS repræsenterer intet mindre end endnu en satellit af et bestemt hub. Den, ligesom en almindelig satellit, indeholder forretningsnøgle og dato for oprettelse af indtastningen i satellitten. Her ophører dog lighederne. Den videre sammensætning af attributter for en sådan "specialiseret" satellit bestemmes af forretningsbrugere baseret på de mest efterspurgte, forudberegnede indikatorer.

For eksempel kan en hub, der indeholder information om en medarbejder, inkludere en satellit med sådanne indikatorer som:

• Minimumsløn;
• Maksimalløn;
• Gennemsnitsløn;
• Akkumuleret resultat af udbetalt løn osv.

Det er logisk at inkludere PREDEFINED DERIVATIONS i PIT-tabellen for denne samme hub, så man nemt kan få dataskæringer for medarbejderen på en specifikt valgt dato.

KONKLUSIONER

Som praksis viser, er brugen af DATA VAULT for forretningsbrugere en smule besværlig af flere grunde:

• Koden til forespørgsler er kompleks og voluminøs;
• Overfloden af JOINs påvirker forespørgslernes hastighed;
• For at skrive analytiske forespørgsler kræves en fremragende viden om struktur af lageret.

For at forenkle adgangen til data udvides DATA VAULT med yderligere objekter:

• PIT (point in time) tabeller;
• BRIDGE tabeller;
• PREDEFINED DERIVATIONS.

I næste artikel jeg planlægger at dele, hvad jeg synes er det mest interessante, for dem der arbejder med BI. Jeg vil præsentere måder at oprette faktatabeller og dimensionstabeller på baggrund af DATA VAULT.

Materialerne i artiklen er baseret på:

• På publikation af Kenta Graziano, som udover en detaljeret beskrivelse indeholder modelleringsskemaer;
• Bogen: "Building a Scalable Data Warehouse with DATA VAULT 2.0";
• Artikel Grundlæggende i Data Vault.

Kilde: habr.com