Lagerudvikling er en lang og seriøs forretning.
Meget i et projekts levetid afhænger af, hvor godt objektmodellen og basisstrukturen er gennemtænkt i starten.
Den generelt accepterede tilgang har været og forbliver forskellige kombinationer af stjerneskemaet med den tredje normalform. Som regel ifølge princippet: indledende data - 3NF, montrer - en stjerne. Denne tilgang, tidstestet og understøttet af en masse forskning, er den første (og nogle gange den eneste) ting, der kommer til at tænke på for en erfaren DWH-specialist, når de tænker på, hvordan et analytisk depot skal se ud.
På den anden side har forretning generelt og kundernes krav i særdeleshed en tendens til at ændre sig hurtigt, mens data vokser både "i dybden" og "i bredden". Og her vises stjernens største ulempe - begrænset fleksibilitet.
Og hvis du pludselig er i dit stille og behagelige liv som DWH-udvikler:
- opgaven opstod "at gøre i det mindste noget hurtigt, og så får vi se";
- et hurtigt udviklende projekt dukkede op med tilslutning af nye kilder og ændring af forretningsmodellen mindst en gang om ugen;
- en kunde dukkede op, som ikke aner, hvordan systemet skal se ud, og hvilke funktioner det skal udføre i sidste ende, men er klar til eksperimenter og konsekvent forfining af det ønskede resultat med en konsekvent tilgang til det;
- projektlederen kiggede ind med den gode nyhed: “Og nu har vi agile!”.
Eller hvis du bare er interesseret i at lære, hvordan du ellers kan bygge opbevaring - velkommen til katten!
Hvad betyder "fleksibilitet"?
Til at begynde med, lad os definere hvilke egenskaber et system skal have for at blive kaldt "fleksibelt".
Separat er det værd at nævne, at de beskrevne egenskaber skal referere specifikt til system, ikke til behandle dens udvikling. Derfor, hvis du ville læse om Agile som udviklingsmetodologi, er det bedre at læse andre artikler. For eksempel lige der, på Habré, er der en masse interessante materialer (som и Og ).
Det betyder ikke, at udviklingsprocessen og strukturen af datavarehuset er fuldstændig uafhængige. Generelt burde agil udvikling af en agil opbevaring være meget nemmere. Men i praksis er der flere muligheder med Agile udvikling af klassisk DWH ifølge Kimbal og DataVault - ifølge vandfald end lykkelige sammenfald af fleksibilitet i dens to former på ét projekt.
Så hvilke funktioner skal fleksibel opbevaring have? Der er tre punkter her:
- Tidlig levering og hurtig afslutning - det betyder, at ideelt set bør det første forretningsresultat (f.eks. de første arbejdsrapporter) indhentes så tidligt som muligt, det vil sige selv før hele systemet er designet og implementeret. Samtidig bør hver efterfølgende revision også tage så lidt tid som muligt.
- Iterativ forfining - dette betyder, at hver efterfølgende revision ideelt set ikke bør påvirke den allerede fungerende funktionalitet. Det er dette øjeblik, der ofte bliver det største mareridt på store projekter – før eller siden begynder individuelle objekter at få så mange relationer, at det bliver nemmere helt at gentage logikken i en kopi side om side end at tilføje et felt til en eksisterende tabel. Og hvis du er overrasket over, at analysen af effekten af forbedringer på eksisterende objekter kan tage længere tid end selve revisionen, har du højst sandsynligt ikke arbejdet med store datavarehuse inden for bank- eller telekommunikation.
- Konstant tilpasning til skiftende forretningskrav - den generelle objektstruktur bør designes ikke blot under hensyntagen til den mulige udvidelse, men med forventning om, at retningen for denne næste udvidelse ikke engang kunne drømmes om på designstadiet.
Og ja, det er muligt at overholde alle disse krav i ét system (selvfølgelig i visse tilfælde og med nogle forbehold).
Nedenfor vil jeg gennemgå to af de mest populære agile designmetoder til HD - anker model и Data Vault. Uden for parenteserne er så vidunderlige tricks som for eksempel EAV, 6NF (i sin rene form) og alt relateret til NoSQL-løsninger - ikke fordi de på en eller anden måde er værre, og heller ikke fordi artiklen i dette tilfælde ville true med at tilegne sig volumen af en gennemsnitlig afhandling. Det er bare, at alt dette refererer til løsninger af en lidt anden klasse - enten til teknikker, som du kan anvende i specifikke tilfælde, uanset den generelle arkitektur af dit projekt (som EAV), eller til globalt forskellige informationslagringsparadigmer (såsom grafdatabaser) og andre muligheder). NoSQL).
Problemer med den "klassiske" tilgang og deres løsninger i fleksible metoder
Med den "klassiske" tilgang mener jeg den gode gamle stjerne (uanset den specifikke implementering af de underliggende lag, tilgiv mig tilhængerne af Kimball, Inmon og CDM).
1. Rigid kardinalitet af forbindelser
Denne model er baseret på en klar opdeling af data i mål (Dimension) и fakta (fakta). Og det her, for fanden, er logisk – dataanalyse kommer jo i langt de fleste tilfælde til at analysere visse numeriske indikatorer (fakta) i bestemte afsnit (dimensioner).
Samtidig lægges links mellem objekter i form af links mellem tabeller med en fremmednøgle. Dette ser ret naturligt ud, men fører straks til den første begrænsning af fleksibiliteten − streng definition af relationers kardinalitet.
Det betyder, at du på designstadiet af tabeller skal angive for hvert par af relaterede objekter, om de kan relateres som mange-til-mange, eller kun 1-til-mange, og "i hvilken retning". Det afhænger direkte af, hvilken af tabellerne der vil have en primær nøgle, og hvilken der vil have en fremmednøgle. Ændring af dette forhold, når der modtages nye krav, vil højst sandsynligt føre til en omarbejdning af basen.
For eksempel, når du designer "kontantkvittering"-objektet, har du, afhængigt af salgsafdelingens edsvorne forsikringer, fastsat muligheden for handling én forfremmelse til flere kontrolstillinger (men ikke omvendt):
Og efter et stykke tid introducerede kollegerne en ny marketingstrategi, hvori flere kampagner på samme tid. Og nu skal du færdiggøre tabellerne ved at fremhæve forholdet i et separat objekt.
(Alle afledte objekter, hvori promochecken indgår, skal nu også forbedres).
Links i Data Vault og Anchor Model
Det viste sig at være ret simpelt at undgå en sådan situation: du behøver ikke at stole på salgsafdelingen, det er nok alle relationer er oprindeligt gemt i separate tabeller og behandle så mange-til-mange.
Denne fremgangsmåde er blevet foreslået Dan Linstedt som en del af paradigmet Data Vault og fuldt understøttet Lars Rönnbäck в Anker model.
Som et resultat får vi det første karakteristiske træk ved fleksible metoder:
Relationer mellem objekter gemmes ikke i attributterne for overordnede enheder, men er en separat type objekter.
В Data Vault sådanne tabeller kaldes Link, og i Anker model — Binde. Ved første øjekast er de meget ens, selvom deres forskelle ikke udtømmes af navnet (som vil blive diskuteret nedenfor). I begge arkitekturer kan linktabeller linke et vilkårligt antal enheder (ikke nødvendigvis 2).
Denne redundans ved første øjekast giver væsentlig fleksibilitet ved færdiggørelser. En sådan struktur bliver tolerant ikke kun over for at ændre kardinaliteterne af eksisterende links, men også over for at tilføje nye - hvis nu en checkposition også har et link til den kasserer, der har brudt det, vil udseendet af et sådant link blot være en overbygning over eksisterende tabeller uden at påvirke eksisterende objekter og processer.
2. Dataduplikering
Det andet problem, der løses af fleksible arkitekturer, er mindre indlysende og iboende i første omgang. målinger type SCD2 (langsomt skiftende mål af den anden type), men ikke kun dem.
I klassisk lagring er en dimension normalt en tabel, der indeholder en surrogatnøgle (som PK) og et sæt forretningsnøgler og attributter i separate kolonner.
Hvis dimensionen understøtter versionering, tilføjes versionstidsgrænser til standardsættet af felter, og der vises flere versioner i lageret pr. række i kilden (en for hver ændring af versionerede attributter).
Hvis en dimension indeholder mindst én versionsbestemt attribut, der ofte ændres, vil antallet af versioner af en sådan dimension være imponerende (selvom de andre attributter ikke er versionerede eller aldrig ændres), og hvis der er flere sådanne attributter, antallet af versioner kan vokse eksponentielt fra deres antal. En sådan dimension kan optage en betydelig mængde diskplads, selvom de fleste af de data, der er gemt i den, simpelthen er duplikater af uforanderlige attributværdier fra andre rækker.
Samtidig bliver det også ofte brugt denormalisering - nogle af attributterne er bevidst gemt som en værdi og ikke som en reference til en opslagsbog eller en anden dimension. Denne tilgang fremskynder dataadgangen ved at reducere antallet af joinforbindelser, når du får adgang til en dimension.
Typisk resulterer dette i den samme information gemmes samtidigt flere steder. For eksempel kan oplysninger om bopælsregion og medlemskab af kundekategorien samtidig gemmes i "Kunde"-dimensionerne og fakta om "Køb", "Levering" og "Call Center-kontakter" samt i "Kunde - Customer Manager” linktabel.
Generelt gælder ovenstående for almindelige (ikke-versionerede) målinger, men i versionerede kan de have en anden skala: udseendet af en ny version af et objekt (især set i bakspejlet) fører ikke kun til opdatering af alle relaterede tabeller, men til en kaskadefremkomst af nye versioner af relaterede objekter - når tabel 1 bruges til at bygge tabel 2, og tabel 2 bruges til at bygge tabel 3, og så videre. Selv hvis ikke en eneste egenskab i tabel 1 er involveret i konstruktionen af tabel 3 (og andre egenskaber i tabel 2 opnået fra andre kilder er involveret), vil versioneringen af denne konstruktion i det mindste føre til yderligere overhead og højst til ekstra versioner i tabel 3, som generelt "ikke har noget at gøre med det" og længere nede i kæden.
3. Ikke-lineær kompleksitet af raffinement
Samtidig øger hver ny butiksfacade, der bygges oven på en anden, antallet af steder, hvor data kan "afvige", når der foretages ændringer i ETL. Dette fører igen til en stigning i kompleksiteten (og varigheden) af hver efterfølgende revision.
Hvis ovenstående gælder for systemer med sjældent modificerede ETL-processer, kan du leve i et sådant paradigme - bare sørg for, at der er lavet nye forbedringer korrekt til alle relaterede objekter. Hvis revisioner forekommer hyppigt, øges sandsynligheden for ved et uheld at "mangle" flere links betydeligt.
Hvis vi derudover tager i betragtning, at den "versionerede" ETL er meget mere kompliceret end den "ikke-versionerede", bliver det ret svært at undgå fejl under den hyppige forfining af hele denne økonomi.
Lagring af objekter og attributter i Data Vault og Anchor Model
Den tilgang, der er foreslået af forfatterne af fleksible arkitekturer, kan formuleres som følger:
Det er nødvendigt at adskille det, der ændrer sig, fra det, der forbliver uændret. Det vil sige at gemme nøgler adskilt fra attributter.
Dog ikke forvirre ikke versioneret attribut med uændret: den første gemmer ikke historikken for sin ændring, men kan ændres (f.eks. når man retter en inputfejl eller modtager nye data), den anden ændres aldrig.
Synspunkterne på, hvad der præcist kan betragtes som uændret i Data Vault og Anchor modellen er forskellige.
Med hensyn til arkitektur Data Vault, kan betragtes som uændret hele nøglesættet — naturlig (organisationens TIN, produktkode i kildesystemet osv.) og surrogat. Samtidig kan de resterende attributter opdeles i grupper i henhold til kilden og/eller hyppigheden af ændringer og holde en separat tabel for hver gruppe med et uafhængigt sæt versioner.
I samme paradigme Anker model betragtes som uændret kun surrogatnøgle enheder. Alt andet (inklusive naturlige nøgler) er kun et særligt tilfælde af dets egenskaber. Hvori alle attributter er som standard uafhængige af hinanden, så der skal oprettes for hver attribut separat bord.
В Data Vault tabeller, der indeholder entitetsnøgler, kaldes Hubami (Hub). Hubs indeholder altid et fast sæt felter:
- Naturlige enhedsnøgler
- Surrogatnøgle
- Link til kilde
- Optagelsestid
Indgange i Hubs ændres aldrig og har ingen versioner. Udadtil minder hubs meget om ID-map-tabeller, der bruges i nogle systemer til at generere surrogater, dog anbefales det ikke at bruge en heltalssekvens, men en hash fra et sæt forretningsnøgler som surrogater i Data Vault. Denne tilgang forenkler indlæsningen af links og attributter fra kilder (ingen grund til at tilslutte sig hub'en for at få et surrogat, bare beregne hashen fra den naturlige nøgle), men det kan forårsage andre problemer (for eksempel med kollisioner, store og små bogstaver og ikke-udskrivbare tegn i strengnøgler osv.), så det er ikke generelt accepteret.
Alle andre entitetsattributter er gemt i specielle tabeller kaldet Satellitter (satellit). En hub kan have flere satellitter, der gemmer forskellige sæt attributter.
Fordelingen af attributter blandt satellitter sker efter princippet fælles ændring - i den ene satellit kan ikke-versionerede attributter gemmes (for eksempel fødselsdato og SNILS for en person), i den anden - sjældent ændring af version (f.eks. efternavn og pasnummer), i den tredje - hyppigt ændring (f.eks. leveringsadresse, kategori, dato for sidste ordre osv.). Versionering i dette tilfælde udføres på niveau med individuelle satellitter, og ikke enheden som helhed, derfor er det tilrådeligt at distribuere attributterne på en sådan måde, at skæringspunktet mellem versioner inden for en satellit er minimal (hvilket reducerer det samlede antal af lagrede versioner).
Også for at optimere processen med at indlæse data placeres attributter opnået fra forskellige kilder ofte i separate satellitter.
Satellitter kommunikerer med Hub ved fremmed nøgle (hvilket svarer til 1-til-mange kardinalitet). Dette betyder, at flere attributværdier (for eksempel flere kontakttelefonnumre for den samme kunde) understøttes af denne "standard" arkitektur.
В Anker model tabeller, der gemmer nøgler, kaldes Ankre. Og de holder:
- Kun surrogatnøgler
- Link til kilde
- Optagelsestid
Naturlige nøgler fra ankermodellens synspunkt tages i betragtning almindelige egenskaber. Denne mulighed kan virke sværere at forstå, men den giver meget mere mulighed for at identificere et objekt.
For eksempel hvis data om den samme enhed kan komme fra forskellige systemer, som hver især bruger sin egen naturlige nøgle. I Data Vault kan dette føre til ret besværlige konstruktioner af flere hubs (én pr. kilde + flette masterversion), mens i Anchor-modellen falder den naturlige nøgle for hver kilde ind i sin egen attribut og kan bruges ved indlæsning uafhængigt af alle de andre.
Men her ligger et snigende øjeblik: hvis attributter fra forskellige systemer kombineres i én enhed, er der højst sandsynligt nogle lim regler, hvorved systemet skal forstå, at registreringer fra forskellige kilder svarer til én forekomst af enheden.
В Data Vault disse regler vil sandsynligvis bestemme dannelsen "surrogathub" for masterenheden og påvirker på ingen måde de Hubs, der gemmer kildernes naturlige nøgler og deres originale attributter. Hvis reglerne for sammenlægning på et tidspunkt ændres (eller de attributter, der bruges til sammenlægning, kommer til at blive opdateret), vil det være nok at omforme surrogathubsene.
В anker model en sådan enhed vil sandsynligvis blive opbevaret i enkelt anker. Det betyder, at alle attributter, uanset hvilken kilde de kommer fra, vil være bundet til det samme surrogat. At adskille fejlagtigt flettede poster og generelt spore relevansen af fletning i et sådant system kan være meget vanskeligere, især hvis reglerne er ret komplekse og ændres hyppigt, og den samme egenskab kan fås fra forskellige kilder (selvom det bestemt er muligt, fordi hver attributversion bevarer en reference til dens oprindelse).
Under alle omstændigheder, hvis dit system skal implementere funktionaliteten deduplikering, fletning af poster og andre MDM-elementer, bør du især omhyggeligt læse aspekterne af lagring af naturlige nøgler i fleksible metoder. Måske er det mere uhåndterlige design af Data Vault pludselig mere sikkert med hensyn til flettefejl.
anker model giver også en ekstra objekttype kaldet Knude faktisk er det en speciel degenereret ankertype, som kun kan indeholde én attribut. Det er meningen, at noderne skal bruges til at gemme flade mapper (f.eks. køn, civilstand, kundeservicekategori osv.). I modsætning til Anchor, Knot har ingen tilknyttede attributtabeller, og dens eneste attribut (navn) er altid gemt i den samme tabel med nøglen. Noder er knyttet til Anchors af tie-tabeller (Tie) på samme måde, som ankre er forbundet med hinanden.
Der er ingen entydig mening om brugen af noder. For eksempel, , der aktivt fremmer brugen af ankermodellen i Rusland, mener (ikke urimeligt), at det er umuligt for en enkelt opslagsbog at sige, at han altid vil være statisk og enkelt-niveau, så det er bedre at bruge et fuldgyldigt anker til alle objekter på én gang.
En anden vigtig forskel mellem Data Vault og Anchor Model er tilstedeværelsen attributter for links:
В Data Vault Links er de samme fuldgyldige objekter som Hubs og kan have egne attributter. I anker model Links bruges kun til at forbinde ankre og kan ikke have deres egne attributter. Denne forskel fører til væsentligt forskellige modelleringstilgange. fakta, som vil blive diskuteret næste gang.
Opbevaring af fakta
Hidtil har vi primært talt om modellering af målinger. Kendsgerningerne er lidt mindre klare.
В Data Vault et typisk objekt til lagring af fakta − Link, i hvis satellitter er tilføjet rigtige indikatorer.
Denne tilgang synes at være intuitiv. Det giver nem adgang til de analyserede indikatorer og ligner generelt en traditionel faktatabel (kun indikatorerne er ikke gemt i selve tabellen, men i "tilstødende tabel"). Men der er også faldgruber: en af de typiske forfinelser af modellen - udvidelsen af faktanøglen - gør det nødvendigt tilføjelse af en ny fremmednøgle til linket. Og dette "bryder" igen modulariteten og forårsager potentielt behov for forbedringer af andre objekter.
В anker model Et link kan ikke have sine egne attributter, så denne tilgang vil ikke fungere - absolut alle attributter og indikatorer skal være knyttet til ét specifikt anker. Konklusionen fra dette er enkel - hver kendsgerning har også brug for sit eget anker. For noget af det, vi er vant til at opfatte som fakta, kan dette virke naturligt - for eksempel er kendsgerningen om et køb perfekt reduceret til objektet "ordre" eller "kvittering", besøg på et websted reduceres til en session osv. Men der er også fakta, som det ikke er så nemt at finde sådan et naturligt "bærerobjekt" for - for eksempel varebalancen i varehuse i begyndelsen af hver dag.
Følgelig er der ingen problemer med modularitet, når man udvider faktanøglen i ankermodellen (det er nok bare at tilføje et nyt forhold til det tilsvarende anker), men at designe modellen til at vise fakta er mindre ligetil, "kunstige" ankre kan forekomme som afspejler virksomhedens objektmodel er ikke indlysende.
Hvordan fleksibilitet opnås
Den resulterende konstruktion i begge tilfælde indeholder markant flere bordeend traditionel måling. Men det kan tage betydeligt mindre diskplads med det samme sæt af versionerede attributter som den traditionelle dimension. Naturligvis er der ingen magi her - det handler om normalisering. Ved at distribuere attributter på tværs af satellitter (i Data Vault) eller individuelle tabeller (ankermodel), reducerer vi (eller helt eliminerer) duplikere værdierne af nogle attributter, når du ændrer andre.
for Data Vault gevinsten vil afhænge af fordelingen af attributter blandt satellitterne, og for anker model — er næsten direkte proportional med det gennemsnitlige antal versioner pr. måleobjekt.
At optage plads er dog en vigtig, men ikke den største fordel ved at gemme egenskaber separat. Sammen med separat lagring af links gør denne tilgang lagringen modulært design. Det betyder, at tilføjelse af både individuelle attributter og helt nye fagområder i en sådan model ser ud overbygning over et eksisterende sæt af objekter uden at ændre dem. Og det er netop det, der gør de beskrevne metoder fleksible.
Det ligner også overgangen fra stykproduktion til masseproduktion - hvis i den traditionelle tilgang hvert modelbord er unikt og kræver særskilt opmærksomhed, så er det i fleksible metoder allerede et sæt typiske "detaljer". På den ene side er der flere tabeller, processerne med at indlæse og hente data skulle se mere komplicerede ud. På den anden side bliver de typisk. Det betyder, at der evt automatiseret og administreret af metadata. Spørgsmålet "hvordan skal vi lægge det?", hvor svaret kunne optage en væsentlig del af arbejdet med udformningen af forbedringer, er nu simpelthen ikke det værd (ligesom spørgsmålet om virkningen af at ændre modellen på arbejdsprocesser).
Det betyder ikke, at der slet ikke er brug for analytikere i et sådant system - nogen skal stadig udarbejde et sæt objekter med attributter og finde ud af, hvor og hvordan det hele skal indlæses. Men mængden af arbejde, såvel som sandsynligheden for og omkostningerne ved en fejl, er betydeligt reduceret. Både på analysestadiet og under udviklingen af ETL, som i en væsentlig del kan reduceres til redigering af metadata.
Mørk side
Alt ovenstående gør begge tilgange virkelig fleksible, fremstillelige og velegnede til iterativ forfining. Der er selvfølgelig også en “tjæretønde”, som jeg tror du allerede kender til.
Datanedbrydning, der ligger til grund for modulariteten af fleksible arkitekturer, fører til en stigning i antallet af tabeller og følgelig, over hovedet for joins ved afhentning. For blot at få alle attributterne for en dimension, er et enkelt udvalg tilstrækkeligt i den klassiske opbevaring, og en fleksibel arkitektur vil kræve et antal sammenføjninger. Desuden, hvis alle disse joinforbindelser kan skrives på forhånd for rapporter, vil analytikere, der er vant til at skrive SQL i hånden, lide dobbelt.
Der er flere fakta, der gør denne situation lettere:
Når du arbejder med store dimensioner, bruges næsten alle dens egenskaber næsten aldrig samtidigt. Det betyder, at der kan være færre sammenføjninger, end det ser ud ved første øjekast på modellen. I Data Vault kan du også tage højde for den forventede frekvens for deling, når du tildeler attributter til satellitter. Samtidig er Hubs eller Anchors i sig selv primært nødvendige til at generere og kortlægge surrogater på indlæsningsstadiet og bruges sjældent i forespørgsler (dette gælder især for Anchors).
Alle sammenføjninger er med nøgle. Derudover reducerer en mere "komprimeret" måde at gemme data på overhead af tabelscanning, hvor det er nødvendigt (for eksempel ved filtrering efter en attributværdi). Dette kan føre til, at hentning fra en normaliseret database med en masse joins vil være endnu hurtigere end at scanne en tung dimension med mange versioner pr. række.
For eksempel her i artikel er der en detaljeret sammenlignende præstationstest af Anchor-modellen med et udvalg fra én tabel.
Meget afhænger af motoren. Mange moderne platforme har interne mekanismer til optimering af sammenføjninger. For eksempel kan MS SQL og Oracle "springe" joins til tabeller, hvis deres data ikke bruges andre steder end andre joins og ikke påvirker det endelige valg (tabel/join eliminering), mens MPP Vertica , viste sig at være en fremragende motor til ankermodellen med en vis manuel optimering af forespørgselsplanen. Til gengæld virker det ikke som en god idé at gemme eksempelvis Ankermodellen på Click House, som har begrænset support til join.
Derudover er der for begge arkitekturer specielle tricks, som gør det nemmere at få adgang til data (både med hensyn til forespørgselsydelse og for slutbrugere). For eksempel, Tidspunkter i Data Vault eller specielle bordfunktioner i ankermodellen.
I alt
Hovedessensen af de betragtede fleksible arkitekturer er modulariteten af deres "design".
Denne ejendom tillader:
- Efter nogle indledende forberedelser relateret til implementering af metadata og skrivning af grundlæggende ETL-algoritmer, hurtigt give kunden det første resultat i form af et par rapporter indeholdende data fra blot nogle få kildeobjekter. Det er ikke nødvendigt at gennemtænke (selv på øverste niveau) hele objektmodellen til dette.
- En datamodel kan begynde at arbejde (og nyttig) med kun 2-3 objekter, og derefter vokse gradvist (vedrørende Ankermodellen Nikolai smuk sammenligning med mycelium).
- De fleste forbedringer, herunder udvidelse af emneområdet og tilføjelse af nye kilder påvirker ikke eksisterende funktionalitet og forårsager ikke faren for at bryde noget, der allerede fungerer.
- Takket være dekomponering i standardelementer ser ETL-processer i sådanne systemer ens ud, deres skrivning egner sig til algoritmisering og i sidste ende, automatisering.
Prisen for denne fleksibilitet er ydeevne. Dette betyder ikke, at det er umuligt at opnå acceptabel ydeevne på sådanne modeller. Oftere end ikke, kan du bare have brug for mere indsats og opmærksomhed på detaljer for at opnå de ønskede målinger.
Apps
Enhedstyper Data Vault
Mere om Data Vault:
Enhedstyper Anker model
Mere om Anchor Model:
Oversigtstabel med fælles træk og forskelle mellem de overvejede tilgange:
Kilde: www.habr.com