I den forrige artikel talte jeg om det grundlæggende i DATA VAULT, beskrev hovedelementerne i DATA VAULT og deres formål. På dette tidspunkt kan emnet DATA VAULT ikke betragtes som udtømt, det er nødvendigt at tale om de næste trin i udviklingen af DATA VAULT.
Og i denne artikel vil jeg fokusere på udviklingen af DATA VAULT og overgangen til BUSINESS DATA VAULT eller blot BUSINESS VAULT.
Årsager til fremkomsten af BUSINESS DATA VULT
Det skal bemærkes, at DATA VAULT, der har visse styrker, ikke er uden sine mangler. En af disse ulemper er vanskeligheden ved at skrive analytiske forespørgsler. Forespørgsler har et betydeligt antal JOINs, koden er lang og besværlig. De data, der kommer ind i DATA VAULT, er heller ikke genstand for nogen transformationer, derfor har DATA VAULT fra et forretningsmæssigt synspunkt i sin rene form ingen ubetinget værdi.
Det er for at fjerne disse mangler, at DATA VAULT-metoden blev udvidet med elementer som:
- PIT (punkt i tid) tabeller;
- BRIDGE tabeller;
- FORUDDEFINEREDE AFLEDNINGER.
Lad os se nærmere på formålet med disse elementer.
PIT borde
Som regel kan ét forretningsobjekt (HUB) indeholde data med forskellige opdateringshastigheder, hvis vi f.eks. taler om data, der karakteriserer en person, kan vi sige, at oplysninger om et telefonnummer, adresse eller e-mail har en højere opdateringshastighed end f.eks. fulde navn, pasoplysninger, civilstand eller køn.
Derfor bør man, når man bestemmer satellitter, huske hyppigheden af deres fornyelse. Hvorfor er det vigtigt?
Hvis du gemmer attributter med forskellige opdateringshastigheder i den samme tabel, skal du tilføje en række til tabellen, hver gang den oftest ændrede attribut opdateres. Som et resultat er der en stigning i mængden af diskplads, en stigning i eksekveringstiden for anmodninger.
Nu hvor vi har adskilt satellitterne efter opdateringshastighed, og vi kan indlæse data i dem uafhængigt, skal vi sikre, at vi kan få opdaterede data. Bedre uden at bruge unødvendige JOINs.
Lad mig forklare, for eksempel, du skal have opdateret (inden for datoen for den sidste opdatering) information fra satellitter med forskellige opdateringshastigheder. For at gøre dette skal du ikke kun lave en JOIN, men også oprette flere indlejrede forespørgsler (for hver satellit, der indeholder information) med et valg af den maksimale opdateringsdato MAX (Opdateringsdato). Med hver ny JOIN vokser sådan kode, og den bliver meget hurtigt svær at forstå.
PIT-tabellen er designet til at forenkle sådanne forespørgsler, PIT-tabeller udfyldes samtidig med, at nye data skrives til DATA VAULT. PIT tabel:
Vi har således information om relevansen af data for alle satellitter på hvert tidspunkt. Ved at bruge JOINs på PIT-tabellen kan vi fuldstændigt eliminere indlejrede forespørgsler, naturligvis med den betingelse, at PIT'en udfyldes hver dag og uden huller. Selvom der er huller i PIT'en, kan du kun få opdaterede data ved at bruge én indlejret forespørgsel til selve PIT'en. En indlejret forespørgsel vil arbejde hurtigere end indlejrede forespørgsler for hver satellit.
BRIDGE
BRIDGE-tabeller bruges også til at forenkle analytiske forespørgsler. Forskellen fra PIT er dog et middel til at forenkle og fremskynde anmodninger mellem forskellige hubs, links og deres satellitter.
Tabellen indeholder alle de nødvendige nøgler til alle satellitter, der ofte bruges i forespørgsler. Derudover kan hash-nøgler om nødvendigt suppleres med nøgler i tekstform, hvis nøglernes navne er nødvendige til analyse.
Faktum er, at uden at bruge BRIDGE, i processen med at indhente data placeret i satellitter, der tilhører forskellige hubs, vil det være nødvendigt at JOIN ikke kun selve satellitterne, men også forbindelserne, der forbinder hubs.
Tilstedeværelsen eller fraværet af BRIDGE bestemmes af lagerkonfigurationen, behovet for at optimere hastigheden af forespørgselsudførelsen. Det er svært at komme med et universelt eksempel på BRIGE.
FORUDDEFINEREDE AFLEDNINGER
En anden type objekter, der bringer os tættere på BUSINESS DATA VAULT, er tabeller, der indeholder forudberegnede indikatorer. Sådanne tabeller er virkelig vigtige for erhvervslivet, de indeholder oplysninger aggregeret i henhold til givne regler og gør det relativt nemt at få adgang til.
Arkitektonisk er FORUDDEFINEREDE AFLEDNINGER intet andet end endnu en satellit af en bestemt hub. Den indeholder ligesom en almindelig satellit en forretningsnøgle og den dato, hvor posten blev oprettet i satellitten. Det er dog her lighederne slutter. Den yderligere sammensætning af attributterne for en sådan "specialiseret" satellit bestemmes af forretningsbrugere baseret på de mest populære, forudberegnede indikatorer.
For eksempel kan en hub indeholdende information om en medarbejder omfatte en satellit med indikatorer som:
- mindsteløn;
- Maksimal løn;
- Gennemsnitsløn;
- Samlet sum af optjente lønninger mv.
Det er logisk at inkludere PREDEFINED DERIVATIONS i PIT-tabellen i samme hub, så kan du nemt få medarbejderdataslices for en bestemt dato.
KONKLUSIONER
Som praksis viser, er brugen af DATA VAULT af forretningsbrugere noget vanskelig af flere årsager:
- Forespørgselskoden er kompleks og besværlig;
- Overfloden af JOINs påvirker forespørgselsydelsen;
- At skrive analytiske forespørgsler kræver et enestående kendskab til lagerstrukturen.
For at forenkle dataadgangen er DATA VAULT udvidet med yderligere objekter:
- PIT (punkt i tid) tabeller;
- BRIDGE tabeller;
- FORUDDEFINEREDE AFLEDNINGER.
Næste Jeg planlægger at fortælle, efter min mening, det mest interessante for dem, der arbejder med BI. Jeg vil præsentere måder at lave tabeller - fakta og tabeller - dimensioner på baseret på DATA VAULT.
Materialerne i artiklen er baseret på:
- On Kenta Graziano, som udover en detaljeret beskrivelse indeholder modeldiagrammer;
- Bog: "Opbygning af et skalerbart datavarehus med DATA VAULT 2.0";
- artiklen .
Kilde: www.habr.com