{"id":92015,"date":"2020-08-21T19:42:13","date_gmt":"2020-08-21T17:42:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh"},"modified":"2020-08-21T19:42:13","modified_gmt":"2020-08-21T17:42:13","slug":"obzor-gibkih-metodologij-proektirovaniya-dwh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","title":{"rendered":"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Utvecklingen av lagringsl\u00f6sningar \u00e4r en l\u00e5ng och seri\u00f6s process. <\/p>\n<p>Mycket av projektets framg\u00e5ng beror p\u00e5 hur v\u00e4l den objektorienterade modellen och databasstrukturen \u00e4r genomt\u00e4nkta fr\u00e5n b\u00f6rjan.<\/p>\n<p>Den allm\u00e4nt accepterade metoden har varit och f\u00f6rblir olika varianter av att kombinera stj\u00e4rnschemat med tredje normalformen. Som regel: k\u00e4lldata \u2014 3NF, datalager \u2014 stj\u00e4rna. Denna metod, som har bevisats \u00f6ver tid och st\u00f6ds av ett stort antal studier, \u00e4r det f\u00f6rsta (och ibland det enda) som kommer i \u00e5tanke f\u00f6r en erfaren DWH-specialist n\u00e4r de t\u00e4nker p\u00e5 hur ett analytiskt datalager b\u00f6r se ut.<\/p>\n<p>\u00c5 andra sidan, \u00e4r det vanligt att f\u00f6retagsbehov och kundkrav f\u00f6r\u00e4ndras snabbt, och data v\u00e4xer b\u00e5de \"djupg\u00e5ende\" och \"brett\". H\u00e4r uppdagar den st\u00f6rsta nackdelen med stj\u00e4rnan \u2014 begr\u00e4nsad... <b>flexibilitet<\/b>.<\/p>\n<p>Och om det pl\u00f6tsligt i ditt lugna och bekv\u00e4ma liv som DWH-utvecklare:<\/p>\n<ul>\n<li>uppkom en uppgift att \"g\u00f6ra n\u00e5got snabbt, och s\u00e5 ser vi senare\";<\/li>\n<li>det d\u00f6k upp ett snabbt v\u00e4xande projekt med nya datak\u00e4llor som \u00e4ndrar aff\u00e4rsmodellen minst en g\u00e5ng i veckan;<\/li>\n<li>det kom en kund som inte kan f\u00f6rest\u00e4lla sig hur systemet ska se ut och vilka funktioner det ska utf\u00f6ra, men som \u00e4r \u00f6ppen f\u00f6r experiment och successivt klarg\u00f6r \u00f6nskat resultat i en gradvis n\u00e4rmande process;<\/li>\n<li>en projektledare kom med den gl\u00e4djande nyheten: \"Och nu har vi Agile!\"<\/li>\n<\/ul>\n<p>\nEller om du bara \u00e4r nyfiken p\u00e5 hur man kan bygga lagringsl\u00f6sningar \u2014 v\u00e4lkommen under kat!<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/59cd70ca3af4841d0c5c9bfbbd7636a3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Vad betyder \"flexibilitet\"?<\/h3>\n<p>\nF\u00f6r att b\u00f6rja med, l\u00e5t oss definiera vilka egenskaper ett system m\u00e5ste ha f\u00f6r att kunna kallas \"flexibelt\". <\/p>\n<p>Det \u00e4r v\u00e4rt att notera att de egenskaper som beskrivs b\u00f6r relatera till <b>system f\u00f6r<\/b>, snarare \u00e4n till <b>utvecklingsprocessen. <\/b>D\u00e4rf\u00f6r, om du ville l\u00e4sa om Agile som en utvecklingsmetodik, \u00e4r det b\u00e4ttre att kolla in andra artiklar. Till exempel finns det p\u00e5 Habr\u00e9 massor av intressanta material (som <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436178\/\">\u00f6versikter<\/a><\/noindex> och <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/284012\/\">praktiska<\/a><\/noindex>, s\u00e5v\u00e4l som <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataart\/blog\/245605\/\">problem.<\/a><\/noindex>).<\/p>\n<p>Det betyder inte att utvecklingsprocessen och strukturen f\u00f6r ett Data Warehouse (DWH) \u00e4r helt orelaterade. Generellt sett borde det vara betydligt l\u00e4ttare att utveckla ett flexibelt datalager enligt Agile-metoden. Men i praktiken m\u00f6ter vi oftare situationer d\u00e4r utvecklingen f\u00f6ljer mer traditionella metoder enligt Kimball eller Data Vault \u2014 enligt vattenfallsmodellen, snarare \u00e4n lyckliga exempel p\u00e5 flexibilitet i b\u00e5da dess former p\u00e5 ett och samma projekt.<\/p>\n<p>S\u00e5, vilka m\u00f6jligheter b\u00f6r ett flexibelt datahanteringssystem inneha? H\u00e4r kan tre punkter sammanfattas:<\/p>\n<ol>\n<li><b>Tidigare leverans och snabb vidareutveckling<\/b> \u2014 det betyder att den f\u00f6rsta aff\u00e4rsresultatet (till exempel de f\u00f6rsta fungerande rapporterna) idealiskt ska uppn\u00e5s s\u00e5 tidigt som m\u00f6jligt, det vill s\u00e4ga innan systemet helt har designats och implementerats. Varje n\u00e4sta vidareutveckling ska ocks\u00e5 ta s\u00e5 lite tid som m\u00f6jligt.<\/li>\n<li><b>Iterativ vidareutveckling<\/b> \u2014 detta betyder att varje n\u00e4sta vidareutveckling i idealet inte ska p\u00e5verka redan fungerande funktionalitet. Just denna punkt blir ofta den st\u00f6rsta mardr\u00f6mmen i stora projekt \u2014 f\u00f6rr eller senare b\u00f6rjar enskilda objekt att f\u00e5 s\u00e5 m\u00e5nga samband att det blir enklare att helt \u00e5terskapa logiken i en kopia bredvid, \u00e4n att l\u00e4gga till ett f\u00e4lt i en befintlig tabell. Om du undrar varf\u00f6r analysen av p\u00e5verkan av vidareutvecklingen p\u00e5 befintliga objekt kan ta mer tid \u00e4n sj\u00e4lva vidareutvecklingen \u2014 har du sannolikt \u00e4nnu inte arbetat med stora datalager inom bank eller telekom.<\/li>\n<li><b>Kronisk anpassning till f\u00f6r\u00e4ndrade aff\u00e4rskrav<\/b> \u2014 den \u00f6vergripande objektstrukturen b\u00f6r designas inte bara med tanke p\u00e5 potentiell utvidgning utan ocks\u00e5 med ber\u00e4kning p\u00e5 att riktningen f\u00f6r denna n\u00e4sta utvidgning kan ha varit s\u00e5 ov\u00e4ntad att du aldrig ens kunde ha dr\u00f6mt om den under designfasen.<\/li>\n<\/ol>\n<p>\nOch ja, att uppfylla alla dessa krav i ett system \u00e4r m\u00f6jligt (naturligtvis under vissa omst\u00e4ndigheter och med vissa f\u00f6rbeh\u00e5ll).<\/p>\n<p>Nedan kommer jag att granska de tv\u00e5 mest popul\u00e4ra metoderna f\u00f6r flexibel design av datalager \u2014 <b>Anchor-modellen<\/b> och <b>Data Vault<\/b>. Det finns m\u00e5nga fantastiska metoder som EAV, 6NF (i sin rena form) och allt som h\u00f6r till NoSQL-l\u00f6sningar \u2014 inte f\u00f6r att de skulle vara s\u00e4mre, och inte ens f\u00f6r att artikeln i s\u00e5 fall skulle riskera att bli lika omfattande som en genomsnittlig avhandling. Det handlar ist\u00e4llet om l\u00f6sningar som tillh\u00f6r en annan klass \u2014 antingen metoder som kan till\u00e4mpas i specifika fall oavsett den \u00f6vergripande arkitekturen av ditt projekt (som EAV), eller helt andra paradigmer f\u00f6r datalagring (som till exempel grafdatabaser och andra NoSQL-alternativ).<\/p>\n<h3>Problemen med den \"klassiska\" metoden och deras l\u00f6sningar i flexibla metoder<\/h3>\n<p>\n<i>Med den \"klassiska\" metoden avser jag den gamla goda stj\u00e4rnan (oavsett den specifika implementeringen av de underliggande lagren, f\u00f6rl\u00e5t mig Kimball-, Inmon- och CDM-anh\u00e4ngare).<br \/>\n<\/i><\/p>\n<h4>1. Strikt kardinalitet av relationerna<\/h4>\n<p>\nDenna modell bygger p\u00e5 en tydlig uppdelning av data i <b>dimensioner (Dimension)<\/b> och <b>fakta (Fact)<\/b>. Och det \u00e4r, f\u00f6r sjutton, logiskt \u2014 eftersom dataanalys i de flesta fall handlar om att analysera specifika kvantitativa indikatorer (fakta) i specifika dimensioner (m\u00e4tv\u00e4rden).<\/p>\n<p>Relationerna mellan objekten definieras som relationer mellan tabeller via en fr\u00e4mmande nyckel. Detta verkar ganska naturligt, men leder omedelbart till den f\u00f6rsta begr\u00e4nsningen av flexibiliteten \u2014 <b>den strikta definitionen av kardinaliteten av relationerna<\/b>.<\/p>\n<p>Det betyder att under designfasen av tabeller m\u00e5ste du noggrant definiera f\u00f6r varje par relaterade objekt om de kan relateras som m\u00e5nga-till-m\u00e5nga eller bara en-till-m\u00e5nga, och \"i vilken riktning\". Detta p\u00e5verkar direkt vilken tabell som kommer att ha prim\u00e4rnyckeln och vilken som kommer att ha den fr\u00e4mmande. En f\u00f6r\u00e4ndring av detta f\u00f6rh\u00e5llande vid nya krav kommer med stor sannolikhet att leda till en omarbetning av databasen.<\/p>\n<p>Till exempel, n\u00e4r du designade objektet \"kassakvitto\" baserat p\u00e5 den fastst\u00e4llda informationen fr\u00e5n f\u00f6rs\u00e4ljningsavdelningen, inkluderade du m\u00f6jligheten f\u00f6r <b>en kampanj att g\u00e4lla f\u00f6r flera kvitto-poster<\/b> (men inte omv\u00e4nt):<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/15226cb79c30364d94147383ba36a8fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nOch efter en tid inf\u00f6rde kollegor en ny marknadsf\u00f6ringsstrategi d\u00e4r flera kampanjer kan g\u00e4lla f\u00f6r samma post <b>samtidigt.<\/b>. Och nu m\u00e5ste du revidera tabellerna och separera relationen i ett eget objekt. <\/p>\n<p>(Alla h\u00e4rledda objekt d\u00e4r det sker en joint check p\u00e5 promo beh\u00f6ver nu ocks\u00e5 bearbetas).<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/3c4d84a31088660257d74c4c703071e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Relationer i Data Vault och Anchor Model<\/b><\/p>\n<p>Att undvika en s\u00e5dan situation visade sig vara ganska enkelt: man beh\u00f6ver inte lita p\u00e5 f\u00f6rs\u00e4ljningsavdelningen f\u00f6r detta. <b>alla relationer b\u00f6r initialt lagras i separata tabeller<\/b> och behandlas som m\u00e5nga-till-m\u00e5nga. <\/p>\n<p>Denna metod f\u00f6reslogs <b>av Dan Linstedt<\/b> som en del av paradigmet <b>Data Vault<\/b> och st\u00f6ddes helt <b>av Lars R\u00f6nnb\u00e4ck<\/b> p\u00e5 <b>Anchor Model<\/b>.<\/p>\n<p>Som resultat f\u00e5r vi den f\u00f6rsta distinkta egenskapen hos flexibla metoder:<\/p>\n<blockquote><p>Relationer mellan objekt lagras inte i attributen f\u00f6r \u00f6verordnade entiteter utan representerar en skild typ av objekt.<\/p><\/blockquote>\n<p>I <b>Data Vault<\/b> Dessa relations-tabeller kallas <b>L\u00e4nk<\/b>, och i <b>Anchor Model<\/b> \u2014 <b>Tie<\/b>. Vid f\u00f6rsta anblicken ser de mycket lika ut, \u00e4ven om deras kvaliteter inte begr\u00e4nsas till namnen (som kommer att diskuteras nedan). I b\u00e5da arkitekturerna kan relations-tabeller koppla ihop <b>vilket antal entiteter som helst<\/b> (inte n\u00f6dv\u00e4ndigtvis 2).<\/p>\n<p>Denna till synes \u00f6verfl\u00f6diga struktur ger betydande flexibilitet vid anpassningar. Strukturen blir tolerant inte bara mot f\u00f6r\u00e4ndringar i kardinaliteter hos existerande relationer, utan ocks\u00e5 f\u00f6r att l\u00e4gga till nya \u2014 om det nu skulle tillkomma en referens till kass\u00f6ren som hanterade kvittot, skulle tillkomsten av en s\u00e5dan koppling bli en enkel \u00f6verbyggnad \u00f6ver de befintliga tabellerna utan p\u00e5verkan p\u00e5 n\u00e5gra befintliga objekt och processer.<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6a3b942a6e5d04dcbe2ff0881ebdf1bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>2. Duplicering av data<\/h4>\n<p>\nDet andra problemet som flexibla arkitekturer l\u00f6ser \u00e4r mindre uppenbart och \u00e4r fr\u00e4mst karakteristiskt f\u00f6r <b>m\u00e5tt av typ SCD2<\/b> (l\u00e5ngsamt f\u00f6r\u00e4nderliga m\u00e5tt av den andra typen), \u00e4ven om det inte bara g\u00e4ller dem.<\/p>\n<p>I ett klassiskt datalager representerar ett m\u00e5tt vanligtvis en tabell som inneh\u00e5ller en surrogatnyckel (som PK) samt en upps\u00e4ttning aff\u00e4rsnycklar och attribut i separata kolumner. <\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/059dd47b2302b58c19a0144061b78cb4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOm ett m\u00e5tt st\u00f6der versionshantering, l\u00e4ggs tidsgr\u00e4nser f\u00f6r versions giltighet till standardupps\u00e4ttningen av f\u00e4lt, och f\u00f6r en rad i k\u00e4llan visas flera versioner i datalagret (en f\u00f6r varje f\u00f6r\u00e4ndring av versionsattributen).<\/p>\n<p>Om en m\u00e4tning inneh\u00e5ller minst en ofta f\u00f6r\u00e4ndrad versionsattribut kommer antalet versioner av denna m\u00e4tning att bli betydande (\u00e4ven om \u00f6vriga attribut inte \u00e4r versionerade eller aldrig f\u00f6r\u00e4ndras), och om det finns flera s\u00e5dana attribut kan antalet versioner v\u00e4xa exponentiellt i f\u00f6rh\u00e5llande till deras antal. En s\u00e5dan m\u00e4tning kan ta upp ett betydande utrymme p\u00e5 h\u00e5rddisken, \u00e4ven om den st\u00f6rsta delen av de lagrade uppgifterna bara \u00e4r dubbletter av v\u00e4rden f\u00f6r of\u00f6r\u00e4ndrade attribut fr\u00e5n andra rader.<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/f3d5a4fd83a5ef36355961302173791d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDetta inneb\u00e4r att det ofta \u00e4ven till\u00e4mpas <b>denormalisering<\/b> \u2014 en del av attributen lagras medvetet som v\u00e4rden ist\u00e4llet f\u00f6r referenser till en referenstabell eller annan m\u00e4tning. Denna metod p\u00e5skyndar \u00e5tkomsten till data och minskar antalet join-operationer vid \u00e5tkomst till m\u00e4tningen.<\/p>\n<p>Som regel leder detta till att <b>samma information lagras samtidigt p\u00e5 flera st\u00e4llen<\/b>. Till exempel kan information om bostadsregion och kundkategori lagras samtidigt i m\u00e4tningarna \"Kund\" samt fakta \"K\u00f6p\", \"Leverans\" och \"Kontaktsamtal\", samt i kopplingstabellen \"Kund - Kundchef\".<\/p>\n<p>Generellt sett g\u00e4ller det ovanst\u00e5ende \u00e4ven f\u00f6r vanliga (icke-versionerade) m\u00e4tningar, men det kan ha en annan skala f\u00f6r versionerade: inf\u00f6randet av en ny version av ett objekt (s\u00e4rskilt retroaktivt) leder inte bara till en uppdatering av alla relaterade tabeller, utan till en kaskad av nya versioner av relaterade objekt \u2014 n\u00e4r Tabell 1 anv\u00e4nds f\u00f6r att bygga Tabell 2, och Tabell 2 anv\u00e4nds f\u00f6r att bygga Tabell 3 etc. \u00c4ven om inget attribut i Tabell 1 deltar i byggandet av Tabell 3 (utan andra attribut i Tabell 2 som kommer fr\u00e5n andra k\u00e4llor), kommer ett versionsuppdatering av denna struktur \u00e5tminstone att leda till ytterligare overheadkostnader, och som mest till on\u00f6diga versioner i Tabell 3, som h\u00e4r \u00f6verhuvudtaget inte har n\u00e5got med saken att g\u00f6ra, och s\u00e5 vidare i kedjan.<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/2935f93abc46f02bdc528accda2af758.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>3. Icke-linj\u00e4r komplexitet i modifieringar<\/h4>\n<p>\nSamtidigt \u00f6kar varje ny vy som byggs p\u00e5 grundval av en annan antalet st\u00e4llen d\u00e4r datan kan \"skiljas\" vid \u00e4ndringar i ETL. Detta leder i sin tur till en \u00f6kning av komplexiteten (och varaktigheten) av varje n\u00e4sta modifiering.<\/p>\n<p>Om det ovanst\u00e5ende g\u00e4ller system med s\u00e4llan \u00e4ndrade ETL-processer kan man leva i en s\u00e5dan paradigm \u2013 det r\u00e4cker med att se till att nya \u00e4ndringar korrekt inf\u00f6rlivas i alla relaterade objekt. Om \u00e4ndringar d\u00e4remot sker ofta \u00f6kar risken f\u00f6r att man av misstag \"missar\" flera kopplingar avsev\u00e4rt.<\/p>\n<p>Om man dessutom tar h\u00e4nsyn till att \"versions\" ETL \u00e4r betydligt mer komplicerat \u00e4n \"icke-versions\", blir det ganska sv\u00e5rt att undvika misstag vid frekvent modifiering av hela detta system.<\/p>\n<h3>Lagring av objekt och attribut i Data Vault och Anchor Model<\/h3>\n<p>\nDen f\u00f6reslagna metoden av f\u00f6rfattarna till flexibla arkitekturer kan formuleras s\u00e5 h\u00e4r:<\/p>\n<blockquote><p>Det \u00e4r n\u00f6dv\u00e4ndigt att separera det som f\u00f6r\u00e4ndras fr\u00e5n det som f\u00f6rblir of\u00f6r\u00e4ndrat. Det vill s\u00e4ga att lagra nycklar separat fr\u00e5n attribut.<\/p><\/blockquote>\n<p> Samtidigt ska man inte blanda ihop <b>icke-versionerad<\/b> attribut med <b>of\u00f6r\u00e4ndrad<\/b>: den f\u00f6rsta lagrar ingen historik \u00f6ver sina f\u00f6r\u00e4ndringar men kan f\u00f6r\u00e4ndras (till exempel vid korrigering av inmatningsfel eller vid mottagande av nya data), den andra f\u00f6r\u00e4ndras aldrig.<\/p>\n<p>\u00c5sikterna om vad som kan anses som of\u00f6r\u00e4ndrat i Data Vault och Anchor-modellen skiljer sig.<\/p>\n<p>Ur arkitekturens perspektiv <b>Data Vault<\/b>, kan man betrakta <b>hela upps\u00e4ttningen av nycklar<\/b> \u2013 naturliga (organisationsnummer, varukod i k\u00e4llsystemet etc.) och surrogatnycklar. Samtidigt kan \u00f6vriga attribut delas in i grupper efter k\u00e4lla och\/eller frekvens av f\u00f6r\u00e4ndringar och <b>f\u00f6r varje grupp uppr\u00e4tta en separat tabell<\/b> med en oberoende upps\u00e4ttning versioner.<\/p>\n<p>I Anchor Model-paradigmet anses d\u00e4remot <b>of\u00f6r\u00e4ndrad<\/b> endast surrogatnyckeln <b>f\u00f6r entiteten. Allt annat (inklusive naturliga nycklar) \u00e4r helt enkelt ett s\u00e4rskilt fall av dess attribut. Dessutom<\/b> \u00e4r alla attribut som standard oberoende av varandra <b>, d\u00e4rf\u00f6r b\u00f6r en<\/b>separat tabell skapas <b>Tabeller som inneh\u00e5ller entitetsnycklar kallas<\/b>.<\/p>\n<p>I <b>Data Vault<\/b> Hubbar (Hub) <b>. Hubbar inneh\u00e5ller alltid ett fast antal f\u00e4lt:<\/b>Naturliga nycklar f\u00f6r entiteten<\/p>\n<ul>\n<li>Surrogatnyckel<\/li>\n<li>L\u00e4nk till k\u00e4llan<\/li>\n<li>Tid f\u00f6r inl\u00e4ggning av posten<\/li>\n<li>Poster i Hubbar<\/li>\n<\/ul>\n<p>\n\u00e4ndras aldrig och har inga versioner. <b>\u00e4ndras aldrig och har inga versioner<\/b>. Externt liknar hubs tabeller av typen ID-map, anv\u00e4nd i vissa system f\u00f6r att generera surrogater, men i Data Vault rekommenderas att anv\u00e4nda en hash av en upps\u00e4ttning aff\u00e4rsnycklar ist\u00e4llet f\u00f6r heltalsssekvenser som surrogater. Denna metod f\u00f6renklar inl\u00e4sning av relationer och attribut fr\u00e5n k\u00e4llor (det beh\u00f6vs ingen join p\u00e5 hubben f\u00f6r att f\u00e5 surrogatet, man r\u00e4cker med att ber\u00e4kna hash av den naturliga nyckeln), men kan leda till andra problem (kopplade till till exempel kollisioner, stora och sm\u00e5 bokst\u00e4ver och icke-tryckbara tecken i str\u00e4ngnycklar etc.), och \u00e4r d\u00e4rf\u00f6r inte allm\u00e4nt accepterad.<\/p>\n<p>Alla andra attribut f\u00f6r entiteter lagras i speciella tabeller, kallade <b>Satelliter (Satellit)<\/b>. En hub kan ha flera satelliter som lagrar olika upps\u00e4ttningar attribut.<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/e145f211b8cfb51894e6e1789991e1cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00f6rdelning av attribut bland satelliter sker enligt principen <b>gemensam f\u00f6r\u00e4ndring<\/b> \u2014 i en satellit kan attribut som inte \u00e4r versionshanterade (till exempel f\u00f6delsedatum och personnummer f\u00f6r en fysisk person) lagras, i en annan s\u00e4llan f\u00f6r\u00e4ndrade versionshanterade (till exempel efternamn och passnummer), och i en tredje ofta f\u00f6r\u00e4ndrade (till exempel leveransadress, kategori, datum f\u00f6r senaste best\u00e4llning etc.). Versionshantering sker p\u00e5 niv\u00e5n av individuella satelliter, inte p\u00e5 entiteten som helhet, d\u00e4rf\u00f6r \u00e4r det rimligt att distribuera attribut s\u00e5 att \u00f6verlappning av versioner inom en satellit \u00e4r minimal (vilket minskar det totala antalet lagrade versioner). <\/p>\n<p>Dessutom, f\u00f6r att optimera datainl\u00e4sningsprocessen, flyttas ofta attribut som erh\u00e5lls fr\u00e5n olika k\u00e4llor till separata satelliter.<\/p>\n<p>Satelliter kopplas till hubben via <b>en utl\u00e4ndsk nyckel<\/b> (vilket motsvarar en kardinalitet 1-till-m\u00e5nga). Det inneb\u00e4r att multipla v\u00e4rden av attribut (till exempel flera kontakttelefonnummer f\u00f6r en kund) st\u00f6ds av denna arkitektur \u201cper standard\u201d.<\/p>\n<p>I <b>Ankarmodell (Anchor Model)<\/b> tabeller som lagrar nycklar kallas <b>Ankarpunkter (Anchor)<\/b>. Och de lagrar: <\/p>\n<ul>\n<li><b>Endast surrogatnycklar<\/b><\/li>\n<li>Tid f\u00f6r inl\u00e4ggning av posten<\/li>\n<li>Poster i Hubbar<\/li>\n<\/ul>\n<p>\nNaturliga nycklar betraktas enligt Ankarmodellen som <b>vanliga attribut<\/b>. Denna variant kan verka mer komplex att f\u00f6rst\u00e5, men den ger mycket st\u00f6rre utrymme f\u00f6r identifiering av objekt.<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/0bf941581fd1177eda228d4429cf69db.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTill exempel, om uppgifter om samma entitet kan komma fr\u00e5n olika system, d\u00e4r var och en anv\u00e4nder sin egen naturliga nyckel. I Data Vault kan detta leda till ganska komplicerade konstruktioner av flera hubbar (en per k\u00e4lla + en sammanfogande masterversion), medan i Ankarmodellen hamnar den naturliga nyckeln fr\u00e5n varje k\u00e4lla i sin egen attribut och kan anv\u00e4ndas vid inl\u00e4sning oberoende av alla andra. <\/p>\n<p>Men h\u00e4r finns ocks\u00e5 en listig detalj: om en entitet samlar attribut fr\u00e5n olika system, finns det troligen vissa <b>regler f\u00f6r \"sammanfogning\"<\/b>, enligt vilka systemet m\u00e5ste f\u00f6rst\u00e5 att poster fr\u00e5n olika k\u00e4llor motsvarar en och samma instans av entiteten. <\/p>\n<p>I <b>Data Vault<\/b> Dessa regler kommer troligen att best\u00e4mma utformningen <b>av en \"surrogathubb\" f\u00f6r masterentiteten<\/b> och p\u00e5verka Hubbarna som lagrar de naturliga nycklarna fr\u00e5n k\u00e4llorna och deras ursprungliga attribut. Om reglerna f\u00f6r sammanfogning \u00e4ndras vid n\u00e5got tillf\u00e4lle (eller om det kommer en uppdatering av attributen som de baseras p\u00e5), r\u00e4cker det att omforma surrogat-hubbarna.<\/p>\n<p>I <b>Ankarmodellen<\/b> kommer d\u00e4remot troligen att lagra en s\u00e5dan entitet i <b>en enda ankar.<\/b>. Det betyder att alla attribut, oavsett vilken k\u00e4lla de kommer fr\u00e5n, kommer att knytas till samma surrogat. Att separera felaktigt sammanfogade poster och \u00f6vergripande f\u00f6lja aktuell sammanfogning i ett s\u00e5dant system kan vara betydligt sv\u00e5rare, s\u00e4rskilt om reglerna \u00e4r ganska komplexa och ofta \u00e4ndras, och samma attribut kan komma fr\u00e5n olika k\u00e4llor (\u00e4ven om det \u00e4r absolut m\u00f6jligt, eftersom varje version av attributet beh\u00e5ller en l\u00e4nk till sin k\u00e4lla).<\/p>\n<p>I vilket fall som helst, om din system f\u00f6ruts\u00e4tter implementering av funktionalitet <b>f\u00f6r deduplicering, sammanfogning av poster och andra element i MDM<\/b>, b\u00f6r du s\u00e4rskilt noga bekanta dig med aspekterna av lagring av naturliga nycklar i flexibla metoder. Det \u00e4r m\u00f6jligt att den mer komplicerade konstruktionen Data Vault pl\u00f6tsligt visar sig vara s\u00e4krare ur perspektivet av sammanfogningens fel.<\/p>\n<p><b>Ankarmodellen<\/b> f\u00f6ruts\u00e4tter ocks\u00e5 en ytterligare typ av objekt som kallas <b>Knute (Knot)<\/b> det handlar i grunden om en speciell <b>degenererad typ av ankar.<\/b>, som kan inneh\u00e5lla endast en attribut. Noderna \u00e4r avsedda att anv\u00e4ndas f\u00f6r att lagra platta register (till exempel k\u00f6n, civilst\u00e5nd, kundkategori osv). Till skillnad fr\u00e5n Ankar, har Noden <b>inga relaterade attributtabeller<\/b>, och dess enda attribut (namn) lagras alltid i en tabell med nyckeln. Noder kopplas till Ankar genom sambands-tabeller (Tie) p\u00e5 samma s\u00e4tt som ankar kopplas till varandra.<\/p>\n<p>Det finns ingen entydig \u00e5sikt om anv\u00e4ndningen av Noder. Till exempel <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/azathot\/\">Nikolaj Golov<\/a><\/noindex>, som aktivt fr\u00e4mjar anv\u00e4ndningen av Ankar-modellen i Ryssland, anser (inte utan grund) att f\u00f6r n\u00e5got register kan man inte med s\u00e4kerhet p\u00e5st\u00e5 att det <b>alltid<\/b> kommer att vara statiskt och en niv\u00e5, s\u00e5 det \u00e4r b\u00e4ttre att anv\u00e4nda en fullst\u00e4ndig Anka fr\u00e5n b\u00f6rjan f\u00f6r alla objekt.<\/p>\n<p>En annan viktig skillnad mellan Data Vault och Ankar-modellen \u00e4r n\u00e4rvaron av <b>attribut hos relationer<\/b>:<\/p>\n<p>I <b>Data Vault<\/b> Relationer \u00e4r lika fullv\u00e4rdiga objekt som Huber, och kan ha <b>egna attribut<\/b>. I <b>Ankarmodellen<\/b> Relationer anv\u00e4nds endast f\u00f6r att koppla samman Ankar och <b>kan inte ha egna attribut<\/b>. Denna skillnad ger v\u00e4sentligt olika tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r modellering <b>fakta<\/b>, vilket kommer att diskuteras vidare.<\/p>\n<h3>Lagring av fakta<\/h3>\n<p>\nTidigare har vi fr\u00e4mst pratat om modellering av dimensioner. Faktabitar \u00e4r n\u00e5got mindre entydiga.<\/p>\n<p>I <b>Data Vault<\/b> \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0439 \u043e\u0431\u044a\u0435\u043a\u0442 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0444\u0430\u043a\u0442\u043e\u0432 &#8212;<b> Relation (Link)<\/b>, vars Satelliter inneh\u00e5ller faktiska m\u00e5tt.<\/p>\n<p>Denna metod verkar intuitivt f\u00f6rst\u00e5elig. Det ger enkel \u00e5tkomst till de analyserade m\u00e5tten och liknar helt klart en traditionell faktatabell (endast m\u00e5tten lagras inte i sj\u00e4lva tabellen, utan i en \"grann\" tabell). Men det finns ocks\u00e5 fallgropar: en av standardjusteringarna av modellen \u2014 att utvidga faktanyckeln \u2014 medf\u00f6r behovet av <b>att l\u00e4gga till en ny extern nyckel i Link<\/b>. Och detta \"krossar\" i sin tur modul\u00e4rheten och potentiellt leder till att andra objekt beh\u00f6ver justeras.<\/p>\n<p>I <b>Ankarmodellen<\/b> Relationen kan inte ha egna attribut, s\u00e5 detta tillv\u00e4gag\u00e5ngss\u00e4tt fungerar inte \u2014 absolut alla attribut och m\u00e5tt m\u00e5ste ha koppling till en specifik anka. Slutsatsen \u00e4r enkelt \u2014 <b>f\u00f6r varje faktum beh\u00f6vs ocks\u00e5 en specifik anka.<\/b>. F\u00f6r en del av det vi \u00e4r vana att tolka som fakta kan detta verka naturligt \u2014 till exempel, k\u00f6pet \u00f6vers\u00e4tts v\u00e4l till objektet \u201cbest\u00e4llning\u201d eller \u201ckvitto\u201d, bes\u00f6ket p\u00e5 en webbplats \u2014 till sessioner osv. Men det finns ocks\u00e5 fakta f\u00f6r vilka det inte \u00e4r s\u00e5 l\u00e4tt att hitta ett naturligt \u201cobjekt-b\u00e4rare\u201d \u2014 till exempel, lagersaldot vid dagens b\u00f6rjan. <\/p>\n<p>D\u00e4rf\u00f6r uppst\u00e5r det inga problem med modul\u00e4r design n\u00e4r man utvecklar faktanyckeln i Ankar-modellen (det r\u00e4cker att helt enkelt l\u00e4gga till en ny relation till den aktuella ankaren), men designa modellen f\u00f6r att visa fakta \u00e4r mindre entydig, det kan dyka upp \u201ckonstgjorda\u201d ankare som visar aff\u00e4rsmodellens objekt illa.<\/p>\n<h3>Hur flexibilitet uppn\u00e5s<\/h3>\n<p>\nDen resulterande konstruktionen i b\u00e5da fallen inneh\u00e5ller <b>betydligt fler tabeller<\/b>, \u00e4n traditionell m\u00e4tning. Men de kan ta upp <b>betydligt mindre diskutrymme<\/b> vid samma upps\u00e4ttning versionsattribut som traditionell m\u00e4tning. Ingen magi h\u00e4r, naturligtvis \u2014 allt handlar om normalisering. Genom att f\u00f6rdela attributen \u00f6ver Satelliter (i Data Vault) eller separata tabeller (Ankar-modell), minskar vi (eller helt utesluter) <b>duplicering av v\u00e4rden f\u00f6r vissa attribut vid f\u00f6r\u00e4ndring av andra<\/b>.<\/p>\n<p>F\u00f6r <b>Data Vault<\/b> vinsten kommer att bero p\u00e5 distributionen av attributen \u00f6ver Satelliter, och f\u00f6r <b>Ankarmodellen<\/b> \u2014 \u00e4r n\u00e4stan direkt proportionell mot det genomsnittliga antalet versioner per m\u00e4tobjekt.<\/p>\n<p>Men vinsten vad g\u00e4ller upptaget utrymme \u2014 \u00e4r en viktig men inte den fr\u00e4msta f\u00f6rdelen med separat lagring av attribut. Tillsammans med separat lagring av relationer, g\u00f6r denna metod lager <b>till en modul\u00e4r konstruktion<\/b>. Det betyder att till\u00e4gg av b\u00e5de separata attribut och helt nya \u00e4mnesomr\u00e5den i en s\u00e5dan modell framst\u00e5r som <b>ett till\u00e4gg<\/b> till den befintliga upps\u00e4ttningen objekt utan att f\u00f6r\u00e4ndra dem. Och det \u00e4r just det som g\u00f6r de beskrivna metoderna flexibla.<\/p>\n<p>Det p\u00e5minner ocks\u00e5 om \u00f6verg\u00e5ngen fr\u00e5n styckeproduktion till massproduktion \u2014 om det i det traditionella tillv\u00e4gag\u00e5ngss\u00e4ttet \u00e4r varje tabell i modellen unik och kr\u00e4ver s\u00e4rskild uppm\u00e4rksamhet, s\u00e5 i flexibla metoder \u00e4r det redan en upps\u00e4ttning standard \u201cdetaljer\u201d. \u00c5 ena sidan, \u00f6kar antalet tabeller, inl\u00e4snings- och urvalprocessen m\u00e5ste se mer komplex ut. \u00c5 andra sidan \u2014 de blir <b>standardiserade<\/b>. Det betyder att de kan vara <b>automatiserade och hanteras av metadata<\/b>. Fr\u00e5gan \"hur ska vi l\u00e4gga upp det?\" vars svar tidigare kunde ta en betydande del av arbetet med att designa \u00e4ndringar, st\u00e5r nu helt enkelt inte l\u00e4ngre (liksom fr\u00e5gan om hur f\u00f6r\u00e4ndringen av modellen p\u00e5verkar de p\u00e5g\u00e5ende processerna). <\/p>\n<p>Det betyder inte att analytiker i ett s\u00e5dant system \u00e4r helt on\u00f6diga \u2014 n\u00e5gon m\u00e5ste fortfarande arbeta igenom en upps\u00e4ttning objekt med attribut och ta reda p\u00e5 var och hur allt detta ska laddas. Men m\u00e4ngden arbete, liksom sannolikheten och kostnaden f\u00f6r fel, minskar avsev\u00e4rt. B\u00e5de i analysfasen och under utvecklingen av ETL, som i stor utstr\u00e4ckning kan reduceras till att redigera metadata. <\/p>\n<h3>Den m\u00f6rka sidan<\/h3>\n<p>\nDet som beskrivits ovan g\u00f6r b\u00e5da tillv\u00e4gag\u00e5ngss\u00e4tten verkligen flexibla, tekniska och l\u00e4mpliga f\u00f6r iterativa f\u00f6r\u00e4ndringar. Sj\u00e4lvklart finns det ocks\u00e5 en \"fat av tj\u00e4ra\" som ni s\u00e4kert redan misst\u00e4nker.<\/p>\n<p>Data dekomposition, som \u00e4r grunden f\u00f6r modul\u00e4ra flexibla arkitekturer, leder till en \u00f6kning av antalet tabeller och d\u00e4rmed <b>\u00f6verheadkostnader<\/b> f\u00f6r join-operationer vid urval. F\u00f6r att helt enkelt f\u00e5 alla attribut av en dimension r\u00e4cker det med en enkel select i en klassisk datalager, medan en flexibel arkitektur kr\u00e4ver flera joins. Om f\u00f6r rapporterna kan alla dessa joins skrivas i f\u00f6rv\u00e4g, kommer analytiker som \u00e4r vana vid att skriva SQL f\u00f6r hand att drabbas dubbelt.<\/p>\n<p>Det finns flera fakta som underl\u00e4ttar en s\u00e5dan situation:<\/p>\n<p><b>Vid arbete med stora dimensioner anv\u00e4nds n\u00e4stan aldrig alla dess attribut samtidigt.<\/b> Det betyder att antalet joins kan vara f\u00e4rre \u00e4n vad som verkar vid f\u00f6rsta \u00f6gonkastet p\u00e5 modellen. I Data Vault kan man ocks\u00e5 ta h\u00e4nsyn till den f\u00f6rv\u00e4ntade frekvensen av gemensam anv\u00e4ndning vid f\u00f6rdelning av attribut \u00f6ver satelliter. Sj\u00e4lva Hubbarna eller Ankrarna beh\u00f6vs fr\u00e4mst f\u00f6r att generera och mappa surrogat i inl\u00e4sningsfasen och anv\u00e4nds s\u00e4llan i fr\u00e5gor (s\u00e4rskilt g\u00e4ller detta Ankrarna).<\/p>\n<p><b>Alla joins \u2014 p\u00e5 nyckeln.<\/b> Dessutom minskar en mer \"komprimerad\" lagringsmetod overheadkostnaderna f\u00f6r tabellskanning d\u00e4r det \u00e4r n\u00f6dv\u00e4ndigt (till exempel vid filtrering efter attributv\u00e4rde). Detta kan leda till att en fr\u00e5ga fr\u00e5n en normaliserad databas med m\u00e5nga joins kan vara snabbare \u00e4n att skanna en tung dimension med m\u00e5nga versioner per rad.<\/p>\n<p>Till exempel, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Anchor-Modeling.pdf\">denna <\/a><\/noindex> denna artikel inneh\u00e5ller ett detaljerat j\u00e4mf\u00f6rande prestandatest av Anchor-modellen med en fr\u00e5ga fr\u00e5n en tabell.<\/p>\n<p><b>Mycket beror p\u00e5 motorn.<\/b> M\u00e5nga moderna plattformar har interna mekanismer f\u00f6r att optimera joins. Till exempel kan MS SQL och Oracle \"hoppa \u00f6ver\" joins p\u00e5 tabeller om deras data inte anv\u00e4nds n\u00e5gonstans, f\u00f6rutom av andra joins och inte p\u00e5verkar den slutliga fr\u00e5gan (table\/join elimination), medan MPP Vertica, enligt <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Big_Data_Normalization.pdf\">erfarenheterna fr\u00e5n kollegor p\u00e5 Avito,<\/a><\/noindex>visade sig vara en utm\u00e4rkt motor f\u00f6r Anchor-modellen med viss manuell planoptimering. \u00c5 andra sidan verkar det inte vara en s\u00e4rskilt bra id\u00e9 att lagra Anchor-modellen p\u00e5 Click House, som har begr\u00e4nsat st\u00f6d f\u00f6r joins.<\/p>\n<p>Dessutom finns det <b>s\u00e4rskilda tekniker<\/b>, som underl\u00e4ttar dat\u00e5tkomst (b\u00e5de ur perspektivet av f\u00f6rfr\u00e5gningsprestanda och f\u00f6r slutanv\u00e4ndare). Till exempel, <b>Point-In-Time tabeller<\/b> i Data Vault eller <b>speciella tabellfunktioner<\/b> i Anchor-modellen.<\/p>\n<h2>Sammanfattningsvis<\/h2>\n<p>\nHuvudpo\u00e4ngen med de flexibla arkitekturer som diskuterats \u00e4r deras modul\u00e4ra \"konstruktioner\". <\/p>\n<p>Just denna egenskap g\u00f6r det m\u00f6jligt att:<\/p>\n<ul>\n<li>Efter en viss initial f\u00f6rberedelse, relaterad till distributionsmetadata och skrivning av grundl\u00e4ggande ETL-algoritmer, <b>snabbt tillhandah\u00e5lla kunden det f\u00f6rsta resultatet<\/b> i form av n\u00e5gra rapporter som inneh\u00e5ller data fr\u00e5n bara n\u00e5gra k\u00e4llobjekt. Det \u00e4r inte n\u00f6dv\u00e4ndigt att fullst\u00e4ndigt t\u00e4nka igenom (\u00e4ven p\u00e5 \u00f6vergripande niv\u00e5) hela objektmodellen f\u00f6r detta.<\/li>\n<li>Datamodellen kan b\u00f6rja fungera (och ge f\u00f6rdelar) med bara 2-3 objekt, och sedan <b>gradvis v\u00e4xa<\/b> (relaterat till Anchor-modellen anv\u00e4nde Nikolaj <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">en vacker j\u00e4mf\u00f6relse med mycel). <\/a><\/noindex>De flesta f\u00f6rb\u00e4ttringar, inklusive utvidgning av \u00e4mnesomr\u00e5det och till\u00e4gg av nya k\u00e4llor<\/li>\n<li>ber\u00f6r inte den befintliga funktionaliteten och inneb\u00e4r ingen risk att n\u00e5got befintligt g\u00e5r s\u00f6nder. <b>p\u00e5verkar inte befintlig funktionalitet och inneb\u00e4r ingen risk f\u00f6r att bryta n\u00e5got som redan fungerar<\/b>.<\/li>\n<li>Genom att dekomponera i standardkomponenter ser ETL-processer i s\u00e5dana system likadana ut, deras skrivande kan algoritmiseras och i slut\u00e4ndan, <b>automatiseras<\/b>.<\/li>\n<\/ul>\n<p>\nPriset f\u00f6r denna flexibilitet \u00e4r <b>prestanda<\/b>. Det betyder inte att det \u00e4r om\u00f6jligt att uppn\u00e5 acceptabel prestanda med s\u00e5dana modeller. Oftast kan det bara kr\u00e4vas mer anstr\u00e4ngning och uppm\u00e4rksamhet p\u00e5 detaljer f\u00f6r att n\u00e5 de \u00f6nskade metrikerna.<\/p>\n<h2>Applikationer<\/h2>\n<p><\/p>\n<h4>Entitetstyper <b>Data Vault<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6bbaee505587152d7e5c11b2889bf25a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL\u00e4s mer om Data Vault:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/danlinstedt.com\/\">Dan Listedts webbplats<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.dwh-club.com\/ru\/dwh-bi-articles\/vse-o-data-vault.html\">Allt om Data Vault p\u00e5 ryska<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/348188\/\">Om Data Vault p\u00e5 Habr<\/a><\/noindex><\/p>\n<h4>Entitetstyper <b>of\u00f6r\u00e4ndrad<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/d518f01e6a5c241e9e73d1ea0210c557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL\u00e4s mer om Anchor Model:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/\">Webbplatsen f\u00f6r skaparna av Anchor Model<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">Artikel om erfarenheten av att implementera Anchor Model p\u00e5 Avito<\/a><\/noindex><\/p>\n<p>Sammanfattande tabell med gemensamma drag och skillnader mellan de granskade tillv\u00e4gag\u00e5ngss\u00e4tten:<\/p>\n<p><img decoding=\"async\" alt=\"\u00d6versikt \u00f6ver flexibla metodologier f\u00f6r design av DWH\" src=\"\/wp-content\/uploads\/2020\/08\/807717245fd874ab141031fc64e584fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>K\u00e4lla: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/glowbyte\/blog\/515940\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435. \u041c\u043d\u043e\u0433\u043e\u0435 \u0432 \u0436\u0438\u0437\u043d\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u0442\u043e\u0433\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u0440\u043e\u0434\u0443\u043c\u0430\u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0438 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u0437\u044b \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435. \u041e\u0431\u0449\u0435\u043f\u0440\u0438\u043d\u044f\u0442\u044b\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u043c \u0431\u044b\u043b\u0438 \u0438 \u043e\u0441\u0442\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f \u0441\u0445\u0435\u043c\u044b \u201c\u0437\u0432\u0435\u0437\u0434\u0430\u201d \u0441 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0444\u043e\u0440\u043c\u043e\u0439. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443: \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u2014 3NF, \u0432\u0438\u0442\u0440\u0438\u043d\u044b \u2014 \u0437\u0432\u0435\u0437\u0434\u0430. \u042d\u0442\u043e\u0442 \u043f\u043e\u0434\u0445\u043e\u0434, \u043f\u0440\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0439 \u0432\u0440\u0435\u043c\u0435\u043d\u0435\u043c \u0438 \u043f\u043e\u0434\u043a\u0440\u0435\u043f\u043b\u0435\u043d\u043d\u044b\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92016,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92015","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u0433\u0438\u0431\u043a\u0438\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0439 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f DWH | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-21T17:42:13+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-21T17:42:13+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00d6versikt \u00f6ver flexibla metoder f\u00f6r DWH-design | ProHoster","description":"Utvecklingen av lagringsl\u00f6sningar \u00e4r en l\u00e5ng och seri\u00f6s process.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u0433\u0438\u0431\u043a\u0438\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0439 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f DWH | ProHoster","og:description":"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-21T17:42:13+00:00","article:modified_time":"2020-08-21T17:42:13+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92015","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:16:44","updated":"2022-09-27 14:57:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/92015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=92015"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/92015\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/92016"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=92015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=92015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=92015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}