Att utveckla en lagringsanläggning är ett långt och seriöst uppdrag.
Mycket i ett projekts liv beror på hur väl objektmodellen och basstrukturen är genomtänkta i början.
Det allmänt accepterade tillvägagångssättet har varit och förblir olika alternativ för att kombinera stjärnschemat med tredje normalform. Som regel, enligt principen: initiala data - 3NF, montrar - stjärna. Det här tillvägagångssättet, beprövat och underbyggt av en stor mängd forskning, är det första (och ibland det enda) som en erfaren DWH-specialist tänker på när han tänker på hur ett analytiskt förvar ska se ut.
Å andra sidan tenderar affärer i allmänhet och kundernas krav i synnerhet att förändras snabbt, och data tenderar att växa både "på djupet" och "i bredd". Och det är här den största nackdelen med en stjärna dyker upp - begränsad flexibilitet.
Och om du plötsligt i ditt lugna och mysiga liv som DWH-utvecklare:
- uppgiften uppstod "att göra åtminstone något snabbt, så får vi se";
- ett snabbt utvecklande projekt dök upp, med anslutning av nya källor och omarbetning av affärsmodellen minst en gång i veckan;
- det har dykt upp en kund som inte har en aning om hur systemet ska se ut och vilka funktioner det i slutändan ska utföra, men som är redo att experimentera och konsekvent förfina det önskade resultatet samtidigt som det konsekvent kommer närmare det;
- Projektledaren kom in med de goda nyheterna: "Och nu har vi agilt!"
Eller om du bara är intresserad av att ta reda på hur du annars kan bygga förråd – välkommen på hugget!
Vad betyder "flexibilitet"?
Låt oss först definiera vilka egenskaper ett system måste ha för att kallas "flexibelt".
Separat är det värt att nämna att de beskrivna egenskaperna bör relatera specifikt till systemet, inte att bearbeta dess utveckling. Därför, om du ville läsa om Agile som utvecklingsmetodik, är det bättre att läsa andra artiklar. Till exempel, precis där, på Habré, finns det mycket intressant material (som и , och ).
Det betyder inte att utvecklingsprocessen och strukturen i datalagret är helt orelaterade. Sammantaget borde det vara betydligt enklare att utveckla ett agilt repository för en agil arkitektur. Men i praktiken finns det oftare alternativ med Agile utveckling av den klassiska DWH enligt Kimbal och DataVault - enligt Waterfall, än lyckliga sammanträffanden av flexibilitet i dess två former på ett projekt.
Så, vilka möjligheter bör flexibel lagring ha? Det finns tre punkter här:
- Tidig leverans och snabb hantering - detta innebär att det första affärsresultatet (till exempel de första arbetsrapporterna) helst bör erhållas så tidigt som möjligt, det vill säga redan innan hela systemet är helt designat och implementerat. Dessutom bör varje efterföljande revidering också ta så kort tid som möjligt.
- Iterativ förfining - detta betyder att varje efterföljande förbättring helst inte bör påverka den funktionalitet som redan fungerar. Det är detta ögonblick som ofta blir den största mardrömmen på stora projekt – förr eller senare börjar enskilda objekt få så många kopplingar att det blir lättare att helt upprepa logiken i en kopia i närheten än att lägga till ett fält i en befintlig tabell. Och om du är förvånad över att det kan ta längre tid att analysera förbättringars inverkan på befintliga objekt än själva förbättringarna, så har du med största sannolikhet ännu inte arbetat med stora datalager inom bank eller telekom.
- Ständigt anpassa sig till förändrade affärskrav - den övergripande objektstrukturen bör utformas inte bara med hänsyn till eventuell expansion, utan med förväntningen att riktningen för denna nästa expansion inte ens kunde drömmas om på designstadiet.
Och ja, det är möjligt att uppfylla alla dessa krav i ett system (naturligtvis i vissa fall och med vissa reservationer).
Nedan kommer jag att överväga två av de mest populära metoderna för agila design för datalager - Ankarmodell и Datavalv. Utanför parentesen finns sådana utmärkta tekniker som till exempel EAV, 6NF (i sin rena form) och allt som rör NoSQL-lösningar - inte för att de på något sätt är sämre, och inte ens för att artikeln i det här fallet skulle hota att förvärva volymen av den genomsnittliga avhandlingen. Det är bara det att allt detta relaterar till lösningar av en lite annan klass - antingen till tekniker som du kan använda i specifika fall, oavsett den övergripande arkitekturen för ditt projekt (som EAV), eller till globalt andra paradigm för informationslagring (som grafdatabaser) och andra alternativ NoSQL).
Problem med det "klassiska" tillvägagångssättet och deras lösningar i flexibla metoder
Med "klassiskt" tillvägagångssätt menar jag den gamla goda stjärnan (oavsett den specifika implementeringen av de underliggande lagren, må anhängarna av Kimball, Inmon och CDM förlåta mig).
1. Styv kardinalitet av anslutningar
Denna modell bygger på en tydlig uppdelning av data i Dimensionera и fakta. Och detta, för fan, är logiskt - trots allt handlar dataanalys i den överväldigande majoriteten av fallen om analys av vissa numeriska indikatorer (fakta) i vissa avsnitt (dimensioner).
I det här fallet upprättas kopplingar mellan objekt i form av relationer mellan tabeller med hjälp av en främmande nyckel. Detta ser ganska naturligt ut, men leder omedelbart till den första begränsningen av flexibilitet - strikt definition av anslutningarnas kardinalitet.
Detta innebär att du i tabelldesignstadiet noggrant måste bestämma för varje par av relaterade objekt om de kan relatera lika många-till-många, eller bara 1-till-många, och "i vilken riktning". Detta avgör direkt vilken tabell som kommer att ha den primära nyckeln och vilken som kommer att ha den främmande nyckeln. Att ändra denna inställning när nya krav kommer in kommer med största sannolikhet att leda till en omarbetning av basen.
Till exempel, när du designade objektet "kontantkvitto" och förlitade dig på försäljningsavdelningens eder, fastställde du möjligheten till åtgärder en kampanj för flera checkpositioner (men inte vice versa):
Och efter en tid introducerade kollegor en ny marknadsföringsstrategi där de kan agera på samma position flera kampanjer samtidigt. Och nu måste du ändra tabellerna genom att separera relationen i ett separat objekt.
(Alla härledda objekt där kampanjchecken är sammanfogad behöver nu också förbättras).
Relationer i Data Vault och Anchor Model
Att undvika denna situation visade sig vara ganska enkelt: du behöver inte lita på säljavdelningen för att göra detta. alla anslutningar lagras initialt i separata tabeller och bearbeta det som många-till-många.
Detta tillvägagångssätt föreslogs Dan Linstedt som en del av paradigmet Datavalv och fullt stöd Lars Rönnbäck в Ankarmodell.
Som ett resultat får vi den första utmärkande egenskapen hos flexibla metoder:
Relationer mellan objekt lagras inte i attribut för överordnade enheter, utan är en separat typ av objekt.
В Datavalv sådana länkningstabeller kallas Länk, och i Ankarmodell - Binda fast. Vid första anblicken är de väldigt lika, även om deras skillnader inte slutar med namnet (som kommer att diskuteras nedan). I båda arkitekturerna kan länktabeller länka valfritt antal enheter (inte nödvändigtvis 2).
Denna redundans ger vid första anblicken betydande flexibilitet för modifieringar. En sådan struktur blir tolerant inte bara mot förändringar i kardinalitet hos befintliga länkar, utan också mot tillägg av nya - om nu en checkposition också har en länk till kassörskan som bröt igenom den, kommer utseendet på en sådan länk helt enkelt att bli ett tillägg över befintliga tabeller utan att påverka några befintliga objekt och processer.
2. Dataduplicering
Det andra problemet som löses av flexibla arkitekturer är mindre uppenbart och är i första hand inneboende. Mätningar av typ SCD2 (långsamt ändrande dimensioner av den andra typen), men inte bara dem.
I ett klassiskt lager är en dimension vanligtvis en tabell som innehåller en surrogatnyckel (som en PK) och en uppsättning affärsnycklar och attribut i separata kolumner.
Om en dimension stöder versionshantering läggs versionsgiltighetsgränser till i standarduppsättningen av fält, och flera versioner visas i arkivet för en rad i källan (en för varje ändring av versionsattribut).
Om en dimension innehåller minst ett versionsattribut som ofta ändras, kommer antalet versioner av en sådan dimension att vara imponerande (även om de återstående attributen inte är versionerade eller aldrig ändras), och om det finns flera sådana attribut kan antalet versioner växa exponentiellt från deras antal. Denna dimension kan ta upp en betydande mängd diskutrymme, även om mycket av den data den lagrar helt enkelt är dubbletter av oföränderliga attributvärden från andra rader.
Samtidigt används den också väldigt ofta denormalisering — Vissa attribut lagras avsiktligt som ett värde och inte som en länk till en referensbok eller en annan dimension. Detta tillvägagångssätt snabbar upp dataåtkomsten, vilket minskar antalet kopplingar vid åtkomst till en dimension.
Vanligtvis leder detta till samma information lagras samtidigt på flera ställen. Till exempel kan information om bostadsregionen och kundens kategori lagras samtidigt i "Kund"-dimensionerna och fakta om "Köp", "Leverans" och "Call Center-samtal" samt i "Kund - Kundansvarig" ” länktabell.
I allmänhet gäller det ovan beskrivna för vanliga (icke-versionerade) dimensioner, men i versioner kan de ha en annan skala: utseendet på en ny version av ett objekt (särskilt i efterhand) leder inte bara till uppdateringen av alla relaterade tabeller, men till det överlappande utseendet av nya versioner av relaterade objekt - när tabell 1 används för att bygga tabell 2 och tabell 2 används för att bygga tabell 3, etc. Även om inte ett enda attribut i tabell 1 är inblandat i konstruktionen av tabell 3 (och andra attribut i tabell 2 som erhållits från andra källor är inblandade), kommer versionering av denna konstruktion åtminstone att leda till ytterligare omkostnader, och högst till extra versioner i tabell 3. som inte har med det att göra alls, och längre ner i kedjan.
3. Icke-linjär komplexitet av omarbetning
Samtidigt ökar varje nytt skyltfönster som bygger på ett annat antalet platser där data kan "divergera" när ändringar görs i ETL. Detta leder i sin tur till en ökning av komplexiteten (och varaktigheten) för varje efterföljande revision.
Om ovanstående beskriver system med sällan modifierade ETL-processer kan du leva i ett sådant paradigm - du behöver bara se till att nya modifieringar görs korrekt på alla relaterade objekt. Om revisioner sker ofta ökar sannolikheten avsevärt att av misstag "missa" flera anslutningar.
Om vi dessutom tar hänsyn till att "versionerad" ETL är betydligt mer komplicerad än "icke-versionerad" blir det ganska svårt att undvika misstag när man ofta uppdaterar hela denna anläggning.
Lagring av objekt och attribut i Data Vault och Anchor Model
Det tillvägagångssätt som föreslås av författarna till flexibla arkitekturer kan formuleras enligt följande:
Det är nödvändigt att skilja det som förändras från det som förblir detsamma. Det vill säga lagra nycklar separat från attribut.
Man ska dock inte förväxla inte versionerad attribut med oförändrad: den första lagrar inte historiken för sina ändringar, men kan ändras (till exempel när man korrigerar ett inmatningsfel eller tar emot nya data), den andra ändras aldrig.
Synpunkter skiljer sig åt vad som exakt kan anses vara oföränderligt i Data Vault och Anchor Model.
Ur en arkitektonisk synvinkel Datavalv, kan anses oförändrad hela uppsättningen nycklar - naturlig (organisationens TIN, produktkod i källsystemet etc.) och surrogat. I det här fallet kan de återstående attributen delas in i grupper enligt källan och/eller frekvensen av ändringar och Håll en separat tabell för varje grupp med en oberoende uppsättning versioner.
I paradigmet Ankarmodell anses oförändrad endast surrogatnyckel väsen. Allt annat (inklusive naturliga nycklar) är bara ett specialfall av dess attribut. Vart i alla attribut är som standard oberoende av varandra, så för varje attribut a separat bord.
В Datavalv tabeller som innehåller entitetsnycklar anropas Hubami. Hub innehåller alltid en fast uppsättning fält:
- Naturliga enhetsnycklar
- Surrogatnyckel
- Länk till källa
- Registrera tilläggstid
Inlägg i Hubs ändras aldrig och har inga versioner. Externt är hubbar väldigt lika tabeller av ID-karttyp som används i vissa system för att generera surrogat, men det rekommenderas att använda en hash från en uppsättning affärsnycklar som surrogat i Data Vault. Detta tillvägagångssätt förenklar laddning av relationer och attribut från källor (du behöver inte gå med i navet för att få ett surrogat, du behöver bara beräkna hashen för en naturlig nyckel), men kan orsaka andra problem (relaterade till exempel till kollisioner , skiftläge och icke-utskrivbara tecken i strängnycklar, etc. .p.), därför är det inte allmänt accepterat.
Alla andra entitetsattribut lagras i speciella tabeller som kallas Satelliter. Ett nav kan ha flera satelliter som lagrar olika uppsättningar av attribut.
Fördelningen av attribut mellan satelliter sker enligt principen ledbyte — i en satellit kan icke-versionerade attribut lagras (till exempel födelsedatum och SNILS för en individ), i en annan - sällan ändrade versioner (till exempel efternamn och passnummer), i den tredje - ofta ändrade sådana (till exempel leveransadress, kategori, datum för senaste beställning, etc.). I det här fallet utförs versionshantering på nivån för enskilda satelliter, och inte enheten som helhet, så det är tillrådligt att distribuera attribut så att skärningspunkten mellan versioner inom en satellit är minimal (vilket minskar det totala antalet lagrade versioner ).
Dessutom, för att optimera dataladdningsprocessen, ingår ofta attribut som erhållits från olika källor i enskilda satelliter.
Satelliter kommunicerar med navet via främmande nyckel (vilket motsvarar 1-till-många kardinalitet). Detta innebär att flera attributvärden (till exempel flera kontakttelefonnummer för en klient) stöds av denna "standard" arkitektur.
В Ankarmodell tabeller som lagrar nycklar anropas Ankare. Och de håller:
- Endast surrogatnycklar
- Länk till källa
- Registrera tilläggstid
Naturliga nycklar ur ankarmodellens synvinkel beaktas vanliga attribut. Det här alternativet kan verka svårare att förstå, men det ger mycket större utrymme för att identifiera objektet.
Till exempel, om data om samma enhet kan komma från olika system, som vart och ett använder sin egen naturliga nyckel. I Data Vault kan detta leda till ganska krångliga strukturer av flera hubbar (en per källa + en samlande masterversion), medan i Anchor-modellen faller den naturliga nyckeln för varje källa in i sitt eget attribut och kan användas vid laddning oberoende av alla andra.
Men det finns också en lömsk poäng här: om attribut från olika system kombineras i en enhet, finns det troligen några regler för "limning", genom vilken systemet måste förstå att poster från olika källor motsvarar en instans av enheten.
В Datavalv dessa regler kommer med största sannolikhet att avgöra bildningen "surrogatnav" för huvudenheten och inte på något sätt påverka de nav som lagrar naturliga källnycklar och deras ursprungliga attribut. Om sammanslagningsreglerna vid något tillfälle ändras (eller attributen som det utförs med uppdateras), kommer det att räcka för att formatera om surrogathubben.
В Ankarmodell en sådan enhet kommer sannolikt att lagras i det enda ankaret. Detta innebär att alla attribut, oavsett vilken källa de kommer ifrån, kommer att vara bundna till samma surrogat. Att separera felaktigt sammanslagna poster och i allmänhet övervaka relevansen av sammanslagning i ett sådant system kan vara mycket svårare, särskilt om reglerna är ganska komplexa och ändras ofta, och samma attribut kan erhållas från olika källor (även om det verkligen är möjligt eftersom varje attributversion behåller en länk till sin källa).
I alla fall, om ditt system är tänkt att implementera funktionen deduplicering, sammanslagning av poster och andra MDM-element, är det värt att ägna särskild uppmärksamhet åt aspekterna av att lagra naturliga nycklar i agila metoder. Det är troligt att den skrymmande Data Vault-designen plötsligt kommer att bli säkrare när det gäller sammanslagningsfel.
Ankarmodell tillhandahåller också en extra objekttyp som kallas Knut det är i grunden speciellt degenererad typ av ankare, som bara kan innehålla ett attribut. Noderna är tänkta att användas för att lagra platta kataloger (till exempel kön, civilstånd, kundtjänstkategori, etc.). Till skillnad från ankaret, knuten har inga associerade attributtabeller, och dess enda attribut (namn) lagras alltid i samma tabell med nyckeln. Noder är anslutna till Anchors med tie-tabeller (Tie) på samma sätt som Anchors är anslutna till varandra.
Det finns ingen tydlig uppfattning om användningen av noder. Till exempel, , som aktivt främjar användningen av ankarmodellen i Ryssland, menar (inte orimligt) att det för inte en enda uppslagsbok kan konstateras med säkerhet att det alltid kommer att vara statisk och på en nivå, så det är bättre att omedelbart använda ett fullfjädrat ankare för alla objekt.
En annan viktig skillnad mellan Data Vault och Anchor-modellen är tillgängligheten attribut för anslutningar:
В Datavalv Länkar är samma fullfjädrade objekt som Hubs och kan ha egna attribut. I Ankarmodell Länkar används endast för att ansluta ankare och kan inte ha sina egna egenskaper. Denna skillnad resulterar i signifikant olika modelleringsmetoder fakta, som kommer att diskuteras vidare.
Faktalagring
Innan detta pratade vi främst om mätmodellering. Fakta är lite mindre tydlig.
В Datavalv ett typiskt objekt för att lagra fakta är Länk, i vars satelliter verkliga indikatorer läggs till.
Detta tillvägagångssätt verkar intuitivt. Den ger enkel åtkomst till de analyserade indikatorerna och liknar i allmänhet en traditionell faktatabell (endast indikatorerna lagras inte i själva tabellen, utan i den "intilliggande"). Men det finns också fallgropar: en av de typiska modifieringarna av modellen - utvidgning av faktanyckeln - nödvändiggör lägga till en ny främmande nyckel till Link. Och detta "bryter" i sin tur modulariteten och orsakar potentiellt behov av modifieringar av andra objekt.
В Ankarmodell En anslutning kan inte ha sina egna attribut, så detta tillvägagångssätt kommer inte att fungera - absolut alla attribut och indikatorer måste kopplas till ett specifikt ankare. Slutsatsen från detta är enkel - Varje faktum behöver också sitt eget ankare. För en del av det vi är vana vid att uppfatta som fakta kan detta se naturligt ut - till exempel kan faktumet om ett köp perfekt reduceras till objektet "order" eller "kvitto", besök på en webbplats för en session, etc. Men det finns också fakta för vilka det inte är så lätt att hitta ett sådant naturligt "bärarobjekt" - till exempel rester av varor i lager i början av varje dag.
Följaktligen uppstår inte problem med modularitet när man utökar en faktanyckel i Anchor-modellen (det räcker att helt enkelt lägga till en ny relation till motsvarande Anchor), men att designa en modell för att visa fakta är mindre entydigt; "konstgjorda" ankare kan förekomma som visar affärsobjektsmodellen på ett otydligt sätt.
Hur flexibilitet uppnås
Den resulterande konstruktionen i båda fallen innehåller betydligt fler bordän traditionell mätning. Men det kan ta betydligt mindre diskutrymme med samma uppsättning versionerade attribut som den traditionella dimensionen. Naturligtvis finns det ingen magi här - det handlar om normalisering. Genom att distribuera attribut över satelliter (i datavalvet) eller individuella tabeller (ankarmodell) minskar (eller helt eliminerar) vi duplicering av värden för vissa attribut när du ändrar andra.
för Datavalv vinsterna kommer att bero på fördelningen av attribut mellan satelliterna, och för Ankarmodell — är nästan direkt proportionell mot det genomsnittliga antalet versioner per mätobjekt.
Platsbesparingar är dock en viktig, men inte den största, fördelen med att lagra attribut separat. Tillsammans med separat lagring av relationer gör detta tillvägagångssätt butiken modulär design. Det betyder att det ser ut som att lägga till både enskilda attribut och hela nya ämnesområden i en sådan modell överbyggnad över en befintlig uppsättning objekt utan att ändra dem. Och det är just detta som gör de beskrivna metoderna flexibla.
Detta liknar också övergången från styckproduktion till massproduktion - om i det traditionella tillvägagångssättet är varje tabell i modellen unik och kräver särskild uppmärksamhet, så är det i flexibla metoder redan en uppsättning standard "delar". Å ena sidan finns det fler tabeller, och processerna för att ladda och hämta data borde se mer komplicerade ut. Å andra sidan blir de typisk. Vilket betyder att det kan finnas automatiserad och metadatadriven. Frågan "hur ska vi lägga det?", vars svar skulle kunna ta en betydande del av arbetet med att utforma förbättringar, är nu helt enkelt inte värt det (liksom frågan om hur en förändring av modellen påverkar arbetsprocesserna) ).
Det betyder inte att analytiker inte alls behövs i ett sådant system - någon måste fortfarande arbeta igenom uppsättningen objekt med attribut och ta reda på var och hur man laddar allt. Men mängden arbete, såväl som sannolikheten och kostnaden för ett fel, minskar avsevärt. Både på analysstadiet och under utvecklingen av ETL, som till en betydande del kan reduceras till redigering av metadata.
Mörk sida
Allt ovanstående gör båda tillvägagångssätten verkligt flexibla, tekniskt avancerade och lämpliga för iterativ förbättring. Naturligtvis finns det också en "fat i salvan", som jag tror att man redan kan gissa sig till.
Datanedbrytning, som ligger till grund för modulariteten hos flexibla arkitekturer, leder till en ökning av antalet tabeller och följaktligen, omkostnader att gå med vid provtagning. För att helt enkelt få alla attribut för en dimension räcker det i en klassisk butik med ett urval, men en flexibel arkitektur kommer att kräva en hel serie sammanfogningar. Dessutom, om alla dessa sammanfogningar för rapporter kan skrivas i förväg, kommer analytiker som är vana vid att skriva SQL för hand att drabbas dubbelt.
Det finns flera fakta som gör denna situation lättare:
När man arbetar med stora dimensioner används nästan aldrig alla dess attribut samtidigt. Det gör att det kan bli färre sammanfogningar än vad det verkar vid första anblicken på modellen. Data Vault kan också ta hänsyn till den förväntade frekvensen av delning vid tilldelning av attribut till satelliter. Samtidigt behövs själva Hubs eller Anchors främst för att generera och kartlägga surrogat vid laddningsstadiet och används sällan i frågor (detta gäller särskilt för Anchors).
Alla anslutningar sker med nyckel. Dessutom minskar ett mer "komprimerat" sätt att lagra data kostnaderna för att skanna tabeller där det behövs (till exempel vid filtrering efter attributvärde). Detta kan leda till att sampling från en normaliserad databas med ett gäng kopplingar blir ännu snabbare än att skanna en tung dimension med många versioner per rad.
Till exempel här i Artikeln innehåller ett detaljerat jämförande test av ankarmodellens prestanda med ett prov från en tabell.
Mycket beror på motorn. Många moderna plattformar har interna anslutningsoptimeringsmekanismer. Till exempel kan MS SQL och Oracle "hoppa över" joins till tabeller om deras data inte används någonstans förutom för andra joins och inte påverkar det slutliga valet (tabell/join eliminering) och MPP Vertica , har visat sig vara en utmärkt motor för ankarmodellen, givet viss manuell optimering av frågeplanen. Å andra sidan, att lagra Anchor Model, till exempel på Click House, som har begränsat anslutningsstöd, ser ännu inte ut som en särskilt bra idé.
Dessutom finns det för båda arkitekturerna speciella rörelser, vilket gör dataåtkomst enklare (både ur frågeprestandasynpunkt och för slutanvändare). Till exempel, Tidpunktstabeller i Data Vault eller speciella bordsfunktioner i Anchor-modellen.
Totalt
Huvudessensen av de övervägda flexibla arkitekturerna är modulariteten i deras "design".
Det är denna egenskap som tillåter:
- Efter några inledande förberedelser relaterade till metadata-distribution och skrivning av grundläggande ETL-algoritmer, snabbt ge kunden det första resultatet i form av ett par rapporter innehållande data från endast ett fåtal källobjekt. Det är inte nödvändigt att helt tänka igenom (även på toppnivå) hela objektmodellen.
- En datamodell kan börja fungera (och vara användbar) med bara 2-3 objekt, och sedan växa gradvis (angående Ankarmodellen Nikolai trevlig jämförelse med mycel).
- De flesta förbättringar, inklusive att utöka ämnesområdet och lägga till nya källor påverkar inte befintlig funktionalitet och innebär ingen risk att gå sönder något som redan fungerar.
- Tack vare nedbrytning i standardelement ser ETL-processer i sådana system likadana ut, deras skrivning lämpar sig för algoritmisering och, i slutändan, automatisering.
Priset för denna flexibilitet är produktivitet. Detta betyder inte att det är omöjligt att uppnå acceptabel prestanda på sådana modeller. Oftare än inte kan du helt enkelt behöva mer ansträngning och uppmärksamhet på detaljer för att uppnå de mått du vill ha.
Appar
Enhetstyper Datavalv
Mer information om Data Vault:
Enhetstyper Ankarmodell
Mer information om Anchor Model:
Sammanfattningstabell med gemensamma drag och skillnader för de övervägda tillvägagångssätten:
Källa: will.com