{"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\/da\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","title":{"rendered":"Oversigt over fleksible DWH designmetoder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Udvikling af et datalager er en lang og seri\u00f8s opgave. <\/p>\n<p>Meget i projektets liv afh\u00e6nger af, hvor godt den objektmodel og database-struktur er planlagt fra starten.<\/p>\n<p>Den almindeligt accepterede tilgang har v\u00e6ret og forbliver forskellige kombinationsvarianter af stjerneskemaet med tredje normalform. Som regel f\u00f8lger den princippet: r\u00e5data - 3NF, datavarehuse - stjerne. Denne tilgang, som er blevet bevist gennem tiden og underst\u00f8ttet af mange unders\u00f8gelser, er det f\u00f8rste (og nogle gange det eneste), der kommer til at t\u00e6nke p\u00e5 for en erfaren DWH-udvikler, n\u00e5r man overvejer, hvordan et analytisk datalager burde se ud.<\/p>\n<p>P\u00e5 den anden side har b\u00e5de forretningen generelt og kundens krav i s\u00e6rdeleshed en tendens til hurtigt at \u00e6ndre sig, og data kan vokse b\u00e5de \"i dybden\" og \"i bredden\". Her viser stjernens hovednederlag sig \u2014 dens begr\u00e6nsede fleksibilitet. <b>fleksibilitet<\/b>.<\/p>\n<p>Hvis der pludselig i det stille og hyggelige liv for en DWH-udvikler opst\u00e5r et:<\/p>\n<ul>\n<li>behov for at \"f\u00e5 gjort noget hurtigt, s\u00e5 m\u00e5 vi se senere\";<\/li>\n<li>et hastigt voksende projekt, med tilslutning af nye kilder og en \u00e6ndring af forretningsmodellen mindst en gang om ugen;<\/li>\n<li>en kunde, der ikke har en id\u00e9 om, hvordan systemet skal se ud, og hvilke funktioner det til slut skal udf\u00f8re, men er \u00e5ben for eksperimenter og gradvis pr\u00e6cisering af \u00f8nsket resultat med en tilsvarende tilgang;<\/li>\n<li>en projektleder, der kommer med den gl\u00e6delige nyhed: \"Og nu har vi Agile!\".<\/li>\n<\/ul>\n<p>\nEller hvis du bare er interesseret i at h\u00f8re om, hvordan man ellers kan bygge datalagre \u2014 s\u00e5 er du velkommen til at l\u00e6se videre!<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" 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>Hvad betyder \"fleksibilitet\"?<\/h3>\n<p>\nFor at starte med, lad os definere, hvilke egenskaber et system skal have for at blive kaldt \"fleksibelt\". <\/p>\n<p>Det skal n\u00e6vnes, at de beskrevne egenskaber specifikt skal relateres til <b>netv\u00e6rksstyringssystemet og CI\/CD bliver et fuldst\u00e6ndigt versionsstyret konfiguration.<\/b>, og ikke til <b>udviklingsprocessen. <\/b>Derfor, hvis du \u00f8nskede at l\u00e6se om Agile som udviklingsmetodologi, er det bedre at kigge p\u00e5 andre artikler. For eksempel, her p\u00e5 Habr\u00e9, er der mange interessante materialer (b\u00e5de <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436178\/\">oversigts-<\/a><\/noindex> og <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/284012\/\">praktiske<\/a><\/noindex>, og <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataart\/blog\/245605\/\">problematikker.<\/a><\/noindex>).<\/p>\n<p>Det betyder ikke, at udviklingsprocessen og DWH-strukturen slet ikke har noget at g\u00f8re med hinanden. Generelt b\u00f8r det v\u00e6re betydeligt lettere at udvikle et fleksibelt datalager med en Agile-arkitektur. Dog m\u00f8der man i praksis oftere tilf\u00e6lde af udvikling af et klassisk DWH efter Kimballs metode og DataVault \u2014 efter vandfaldsmetoden, end glade sammenfald af fleksibilitet i de to former i \u00e9t projekt.<\/p>\n<p>Og hvilke muligheder b\u00f8r et fleksibelt datalager s\u00e5 have? Her kan man fremh\u00e6ve tre punkter:<\/p>\n<ol>\n<li><b>Tidlig levering og hurtig forbedring<\/b> \u2014 det betyder, at ideelt set b\u00f8r det f\u00f8rste forretningsresultat (for eksempel de f\u00f8rste fungerende rapporter) opn\u00e5s s\u00e5 tidligt som muligt, dvs. f\u00f8r systemet er fuldt designet og implementeret. Hver efterf\u00f8lgende forbedring b\u00f8r ogs\u00e5 tage s\u00e5 lidt tid som muligt.<\/li>\n<li><b>Iterativ forbedring<\/b> \u2014 det betyder, at hver efterf\u00f8lgende forbedring ideelt set ikke b\u00f8r p\u00e5virke den allerede fungerende funktionalitet. Dette punkt bliver ofte det st\u00f8rste mareridt i store projekter \u2014 f\u00f8r eller senere begynder enkelte objekter at f\u00e5 s\u00e5 mange forbindelser, at det bliver lettere at gentage logikken i en kopi ved siden af, end at tilf\u00f8je et felt i eksisterende tabel. Og hvis det forundrer dig, at analysen af forbedringens indflydelse p\u00e5 eksisterende objekter kan tage l\u00e6ngere tid end selve forbedringen \u2014 har du sandsynligvis endnu ikke arbejdet med store DWH i bank- eller telekomsektoren.<\/li>\n<li><b>Konstant tilpasning til \u00e6ndrede forretningskrav<\/b> \u2014 den generelle objektstruktur skal v\u00e6re designet ikke bare med mulighed for udvidelse in mente, men med det overordnede m\u00e5l, at retningen for denne n\u00e6ste udvidelse ikke engang burde kunne v\u00e6re forestillet p\u00e5 designstadiet.<\/li>\n<\/ol>\n<p>\nOg ja, overholdelse af alle disse krav i \u00e9t system er muligt (naturligvis under visse forhold og med nogle forbehold).<\/p>\n<p>Nedenfor vil jeg se n\u00e6rmere p\u00e5 to af de mest popul\u00e6re metoder til fleksibel design for DWH \u2014 <b>Anchor model<\/b> og <b>Data Vault<\/b>. For the sake of clarity, some excellent techniques such as EAV, 6NF (in its pure form), and everything related to NoSQL solutions are left out \u2014 not because they are worse or because the article might have ended up being the length of an average thesis. It\u2019s simply that all of this pertains to solutions of a somewhat different class \u2014 either to techniques that you can apply in specific cases, regardless of the overall architecture of your project (like EAV), or to completely different paradigms of data storage (such as graph databases and other NoSQL options).<\/p>\n<h3>Problems of the 'classical' approach and their solutions in agile methodologies<\/h3>\n<p>\n<i>By 'classical' approach, I mean the old reliable star (regardless of the specific implementation of the underlying layers, forgive me, followers of Kimball, Inmon, and CDM).<br \/>\n<\/i><\/p>\n<h4>1. Rigid cardinality of relationships<\/h4>\n<p>\nThe foundation of such a model rests on a clear separation of data into <b>dimensions (Dimension)<\/b> og <b>facts (Fact)<\/b>. And this is, damn it, logical \u2014 because data analysis in the vast majority of cases boils down to analyzing specific numeric indicators (facts) in specific contexts (dimensions).<\/p>\n<p>At the same time, the relationships between objects are established in the form of links between tables through a foreign key. This seems quite natural, but it immediately leads to the first limitation of flexibility \u2014 <b>a rigid definition of the cardinality of relationships.<\/b>.<\/p>\n<p>This means that at the design stage of tables you must accurately determine for each pair of related objects whether they can relate as many-to-many or only one-to-many, and 'in which direction'. This directly affects which table will have the primary key and which will have the foreign key. Changing this relationship when new requirements arise will very likely lead to a redesign of the database.<\/p>\n<p>For example, when designing the object 'cash receipt', relying on the solemn assurances of the sales department, you laid the possibility of one promotional action applying to several receipt items <b>(but not vice versa):<\/b> And after some time, the colleagues introduced a new marketing strategy where multiple promotional actions can apply to the same item simultaneously.<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/15226cb79c30364d94147383ba36a8fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAnd now you need to refine the tables, isolating the relationship into a separate object. <b>.<\/b>. <\/p>\n<p>(Alle afledte objekter, hvor der sker en join check p\u00e5 promo, skal nu ogs\u00e5 revideres).<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/3c4d84a31088660257d74c4c703071e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Forbindelser i Data Vault og Anchor Model<\/b><\/p>\n<p>Det viste sig at v\u00e6re ret simpelt at undg\u00e5 en s\u00e5dan situation: man skal ikke stole p\u00e5 salgsafdelingen for dette. <b>Alle forbindelser skal oprindeligt opbevares i separate tabeller<\/b> og behandles som mange-til-mange. <\/p>\n<p>Denne tilgang blev foresl\u00e5et <b>af Dan Linstedt<\/b> som en del af paradigmet <b>Data Vault<\/b> og blev fuldt ud st\u00f8ttet <b>af Lars R\u00f6nnb\u00e4ck<\/b> i <b>Anchor Model<\/b>.<\/p>\n<p>Resultatet er den f\u00f8rste karakteristiske egenskab ved fleksible metoder:<\/p>\n<blockquote><p>Forbindelserne mellem objekterne opbevares ikke i attributterne af de parent entity'er, men udg\u00f8r en separat type objekter.<\/p><\/blockquote>\n<p>I <b>Data Vault<\/b> S\u00e5danne forbindelsestabeller kaldes <b>Forbindelse<\/b>, og der sendes noget til den, vil flytning af denne task til sektionen <b>Anchor Model<\/b> \u2014 <b>Tie<\/b>. Ved f\u00f8rste \u00f8jekast ligner de hinanden meget, selvom deres navne ikke fuldt ud d\u00e6kker forskellene (som vil blive diskuteret nedenfor). I begge arkitekturer kan forbindelsestabeller forbinde <b>et hvilket som helst antal enheder<\/b> (ikke n\u00f8dvendigvis 2).<\/p>\n<p>Denne tilsyneladende overdrevenhed giver betydelig fleksibilitet ved revideringer. Denne struktur bliver tolerant ikke kun over for \u00e6ndringer i kardinaliteterne for eksisterende forbindelser, men ogs\u00e5 tilf\u00f8jelse af nye \u2014 hvis der nu vil v\u00e6re et link til den kasserer, der behandlede kvitteringen, bliver tilf\u00f8jelsen af en s\u00e5dan forbindelse blot en forst\u00e6rkning af de eksisterende tabeller uden indflydelse p\u00e5 nogen eksisterende objekter og processer.<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/6a3b942a6e5d04dcbe2ff0881ebdf1bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>2. Dateneduplication<\/h4>\n<p>\nDet andet problem, som fleksible arkitekturer l\u00f8ser, er mindre \u00e5benlyst og er prim\u00e6rt karakteristisk for <b>SCD2-type m\u00e5linger<\/b> (langsomt skiftende dimensioner af anden type), selvom dette ikke kun g\u00e6lder dem.<\/p>\n<p>I et klassisk datalager repr\u00e6senterer en dimension normalt en tabel, der indeholder en surrogatn\u00f8gle (som PK) samt en r\u00e6kke forretningsn\u00f8gler og attributter i separate kolonner. <\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/059dd47b2302b58c19a0144061b78cb4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvis dimensionen underst\u00f8tter versionsstyring, tilf\u00f8jes der tidsgr\u00e6nser for versionens gyldighed til standardferien, og til en r\u00e6kke i kilden optr\u00e6der der flere versioner i lageret (\u00e9n for hver \u00e6ndring af de versions-baserede attributter).<\/p>\n<p>Hvis dimensionen indeholder blot \u00e9n ofte \u00e6ndret versioneret attribut, vil antallet af versioner af denne dimension v\u00e6re betydeligt (selv hvis de \u00f8vrige attributter ikke er versionerede eller aldrig \u00e6ndres), og hvis der er flere s\u00e5danne attributter, kan antallet af versioner vokse eksponentielt i forhold til deres antal. En s\u00e5dan dimension kan optage en betydelig m\u00e6ngde diskplads, selvom st\u00f8rstedelen af de gemte data blot er duplikater af v\u00e6rdier fra u\u00e6ndrede attributter fra andre r\u00e6kker.<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/f3d5a4fd83a5ef36355961302173791d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSamtidig anvendes meget ofte ogs\u00e5 <b>denormalisering<\/b> \u2014 en del af attributterne gemmes bevidst som en v\u00e6rdi i stedet for en henvisning til et opslagsord eller en anden dimension. Denne tilgang fremskynder adgangen til dataene og reducerer antallet af joins, n\u00e5r der henvendes til dimensionen.<\/p>\n<p>Som regel f\u00f8rer det til, at <b>den samme information gemmes samtidigt flere steder<\/b>. For eksempel kan information om bop\u00e6lsregion og kategori tilh\u00f8rsforhold samtidig gemmes i dimensionerne \"Kunde\" og faktaene \"K\u00f8b\", \"Levering\" og \"Henvendelser til callcenteret\", samt i forbindelsestabellen \"Kunde \u2014 Kundeansvarlig.\"<\/p>\n<p>Generelt g\u00e6lder det ovenst\u00e5ende ogs\u00e5 for almindelige (ikke-versionerede) dimensioner, men i versionerede kan det have en anden skala: fremkomsten af en ny version af et objekt (is\u00e6r retrospektivt) f\u00f8rer ikke blot til opdatering af alle de relaterede tabeller, men til en kaskade af nye versioner af de relaterede objekter \u2014 n\u00e5r Tabel 1 bruges i opbygningen af Tabel 2, og Tabel 2 \u2014 i opbygningen af Tabel 3 osv. Selv hvis ingen attribut fra Tabel 1 deltager i opbygningen af Tabel 3 (men andre attributter fra Tabel 2, der er opn\u00e5et fra andre kilder, deltager), vil en versionering af denne konstruktion mindst f\u00f8re til yderligere overhead, og i v\u00e6rste fald til un\u00f8dvendige versioner i Tabel 3, som slet ikke er \"relevant\" her, og s\u00e5 videre ad k\u00e6den.<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/2935f93abc46f02bdc528accda2af758.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>3. Ikke-line\u00e6r kompleksitet af tilpasning<\/h4>\n<p>\nSamtidig \u00f8ger hver ny datavisning, der bygges p\u00e5 grundlag af en anden, antallet af steder, hvor dataene kan \"sl\u00e5 fejl\" ved indf\u00f8relsen af \u00e6ndringer i ETL. Dette f\u00f8rer i sin tur til en stigning i kompleksiteten (og varigheden) af hver f\u00f8lgende tilpasning.<\/p>\n<p>Hvis det ovenfor beskrevne g\u00e6lder systemer med sj\u00e6ldent modificerede ETL-processer, kan man leve i et s\u00e5dant paradigme \u2014 det er tilstr\u00e6kkeligt blot at sikre, at nye modifikationer bliver korrekt indf\u00f8rt i alle relaterede objekter. Hvis modifikationerne derimod sker ofte, stiger sandsynligheden for uheldigt at \"miste\" flere relationer betydeligt.<\/p>\n<p>Hvis man derudover overvejer, at \"versionsbaseret\" ETL er v\u00e6sentligt mere kompleks end \"ikke versionsbaseret\", bliver det ret vanskeligt at undg\u00e5 fejl ved hyppige \u00e6ndringer af hele dette system.<\/p>\n<h3>Opbevaring af objekter og attributter i Data Vault og Anchor Model<\/h3>\n<p>\nDen tilgang, der foresl\u00e5s af forfatterne til fleksible arkitekturer, kan formuleres s\u00e5ledes:<\/p>\n<blockquote><p>Det er n\u00f8dvendigt at adskille det, der \u00e6ndres, fra det, der forbliver u\u00e6ndret. Det vil sige, at n\u00f8gler skal opbevares separat fra attributter.<\/p><\/blockquote>\n<p> Man skal dog ikke forveksle <b>ikke versionsbaseret<\/b> attribut med <b>u\u00e6ndret<\/b>: den f\u00f8rste opbevarer ikke historien om \u00e6ndringer, men kan \u00e6ndres (for eksempel ved rettelse af indtastningsfejl eller modtagelse af nye data); den sidste \u2014 \u00e6ndres aldrig.<\/p>\n<p>Der er forskellige synspunkter p\u00e5, hvad der pr\u00e6cist kan betragtes som u\u00e6ndret i Data Vault og Anchor modellen.<\/p>\n<p>Set fra et arkitekturperspektiv <b>Data Vault<\/b>, kan man betragte <b>hele s\u00e6t af n\u00f8gler<\/b> \u2014 naturlige (CVR-nummer for virksomheder, produktkode i kildesystemet osv.) og surrogate. Herudover kan de \u00f8vrige attributter opdeles i grupper efter kilde og\/eller \u00e6ndringsfrekvens og <b>for hver gruppe f\u00f8re en separat tabel<\/b> med uafh\u00e6ngigt s\u00e6t af versioner.<\/p>\n<p>I paradigmet <b>Anchor Model<\/b> betegnes u\u00e6ndret <b>kun den surrogate n\u00f8gle<\/b> af entitet. Alt andet (inklusive naturlige n\u00f8gler) er blot en s\u00e6rlig form for dens attributter. Herudover <b>er alle attributter som standard uafh\u00e6ngige af hinanden<\/b>, derfor skal der oprettes en <b>separat tabel<\/b>.<\/p>\n<p>I <b>Data Vault<\/b> tabeller, der indeholder entitetsn\u00f8gler, kaldes <b>Hubs.<\/b>Hubs indeholder altid et fast s\u00e6t felter:<\/p>\n<ul>\n<li>Naturlige n\u00f8gler for entitet<\/li>\n<li>Surrogatn\u00f8gle<\/li>\n<li>Reference til kilde<\/li>\n<li>Tidspunkt for oprettelse af post<\/li>\n<\/ul>\n<p>\nPoster i Hubs <b>bliver aldrig \u00e6ndret og har ikke versioner.<\/b>. Eksternt ligner hubs meget p\u00e5 ID-map-tabeller, der anvendes i nogle systemer til generering af surrogater, men i Data Vault anbefales det at anvende hash fra et s\u00e6t af forretningsn\u00f8gler som surrogater i stedet for en heltalssekvens. Denne tilgang forenkler indl\u00e6sning af relationer og attributter fra kilder (man skal ikke join'e til hub'en for at f\u00e5 surrogatet, det er tilstr\u00e6kkeligt blot at beregne hashen af den naturlige n\u00f8gle), men kan medf\u00f8re andre problemer (for eksempel relateret til kollisioner, skrifttegn og usynlige tegn i strengn\u00f8gler osv.), og derfor er den ikke almindeligt accepteret.<\/p>\n<p>Alle andre attributter for entiteter opbevares i specielle tabeller, kaldet <b>satellitter (Satellit)<\/b>. \u00c9n hub kan have flere satellitter, der opbevarer forskellige s\u00e6t af attributter.<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/e145f211b8cfb51894e6e1789991e1cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFordelingen af attributter p\u00e5 satellitter sker efter princippet om <b>samlet \u00e6ndring<\/b> \u2014 i en satellit kan der opbevares ikke-versionerede attributter (for eksempel f\u00f8dselsdato og CPR-nummer for en privatperson), i en anden \u2014 sj\u00e6ldent \u00e6ndrede versionerede (for eksempel efternavn og pasnummer), i en tredje \u2014 ofte \u00e6ndrede (for eksempel leveringsadresse, kategori, dato for den seneste ordre osv.). Versioneringen f\u00f8res p\u00e5 niveauet af de enkelte satellitter og ikke entiteten som helhed, s\u00e5 fordelingen af attributter er hensigtsm\u00e6ssig at foretage, s\u00e5 overgangen mellem versioner inden for en satellit er minimal (hvilket reducerer det samlede antal gemte versioner). <\/p>\n<p>Desuden, for at optimere dataindl\u00e6sningsprocessen, udskilles ofte attributter, der modtages fra forskellige kilder, i separate satellitter.<\/p>\n<p>Satellitterne forbindes med hub'en via <b>fremmedn\u00f8gler<\/b> (hvilket svarer til kardinaliteten 1-til-mange). Det betyder, at flere v\u00e6rdier af attributter (for eksempel flere kontakttelefonnumre for \u00e9n kunde) underst\u00f8ttes som standard af denne arkitektur.<\/p>\n<p>I <b>Anker modellen (Anchor Model)<\/b> tabeller, der opbevarer n\u00f8glerne, kaldes <b>Ankre (Anchor)<\/b>. Og de opbevarer: <\/p>\n<ul>\n<li><b>Kun surrogatn\u00f8gler<\/b><\/li>\n<li>Reference til kilde<\/li>\n<li>Tidspunkt for oprettelse af post<\/li>\n<\/ul>\n<p>\nNaturlige n\u00f8gler betragtes i Anker Modellen som <b>almindelige attributter<\/b>. Denne variant kan synes mere kompleks at forst\u00e5, men den giver meget mere plads til identifikation af objektet.<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/0bf941581fd1177eda228d4429cf69db.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor eksempel, hvis data om den samme enhed kan komme fra forskellige systemer, hvor hver bruger sin egen naturlige n\u00f8gle. I Data Vault kan dette f\u00f8re til ret besv\u00e6rlige opbygninger af flere hubs (\u00e9n per kilde + en sammenbindende master-version), mens i Anker-modellen indg\u00e5r den naturlige n\u00f8gle fra hver kilde i sin egen attribut og kan bruges ved indl\u00e6sning uafh\u00e6ngigt af alle andre. <\/p>\n<p>Men her gemmer sig et snedigt punkt: hvis attributter fra forskellige systemer kombineres i en enhed, er der sandsynligvis nogle <b>regler for 'sammenkvalificering'<\/b>, hvor efter systemet skal forst\u00e5, at poster fra forskellige kilder svarer til en enkelt instans af enheden. <\/p>\n<p>I <b>Data Vault<\/b> Disse regler vil sandsynligvis definere dannelsen af <b>'surrogathub'en' af master-enheden<\/b> og vil p\u00e5 ingen m\u00e5de p\u00e5virke Hubs, der opbevarer de naturlige n\u00f8gler fra kilderne og deres oprindelige attributter. Hvis reglerne for sammenkvalificering \u00e6ndres p\u00e5 et tidspunkt (eller en opdatering af attributterne, der anvendes til den, kommer), vil det v\u00e6re tilstr\u00e6kkeligt at omstrukturere surrogat-hubbene.<\/p>\n<p>I <b>Anker-modellen<\/b> vil derimod sandsynligvis opbevare en s\u00e5dan enhed i <b>den eneste anker.<\/b>Det betyder, at alle attributter, uanset hvilken kilde de er hentet fra, vil blive knyttet til den samme surrogat. At adskille fejlagtigt sammenkoblede poster og generelt overv\u00e5ge aktualiteten af sammenkvalificeringen i et s\u00e5dant system kan vise sig at v\u00e6re betydeligt sv\u00e6rere, is\u00e6r hvis reglerne er relativt komplekse og ofte \u00e6ndres, og den samme attribut kan f\u00e5s fra forskellige kilder (selvom det bestemt er muligt, da hver version af attributten gemmer en reference til sin kilde).<\/p>\n<p>Under alle omst\u00e6ndigheder, hvis din system forudser implementeringen af funktionalitet <b>deduplicering, sammenl\u00e6gning af poster og andre MDM-elementer<\/b>, er det v\u00e6rd at se s\u00e6rligt n\u00f8je p\u00e5 aspekterne af opbevaring af naturlige n\u00f8gler i fleksible metodologier. Det er sandsynligt, at den mere besv\u00e6rlige Data Vault-struktur pludselig viser sig at v\u00e6re mere sikker i forhold til fejl ved sammenl\u00e6gning.<\/p>\n<p><b>Anker-modellen<\/b> forudser ogs\u00e5 en ekstra type objekt kaldet <b>Knude (Knot)<\/b> som i bund og grund er en speciel <b>degenereret form af ankeret<\/b>, som kun kan have \u00e9n attribut. Noderne er beregnet til at opbevare flade registre (f.eks. k\u00f8n, civilstand, kundepleje kategori osv.). I mods\u00e6tning til Anker, har Nodens <b>ikke tilknyttede attributtabeller<\/b>, og dens eneste attribut (navn) gemmes altid i \u00e9n tabel med n\u00f8glen. Noderne forbindes med Anker tilknyttede mellemtabeller (Tie) p\u00e5 samme m\u00e5de som ankerne imellem hinanden.<\/p>\n<p>Der er ikke en entydig holdning til brugen af Noder. For eksempel, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/azathot\/\">Nikolaj Golov<\/a><\/noindex>, som aktivt fremmer brugen af Anker-modellen i Rusland, mener (ikke uden grund), at der for ingen registre kan fastsl\u00e5s, at det <b>altid<\/b> vil v\u00e6re statisk og enkelt niveau, s\u00e5 for alle objekter er det bedre straks at bruge et fuldt Anker.<\/p>\n<p>En anden vigtig forskel mellem Data Vault og Anker-modellen er tilstedev\u00e6relsen af <b>attributter ved relationer<\/b>:<\/p>\n<p>I <b>Data Vault<\/b> Relationer er lige s\u00e5 fuldgyldige objekter som Hubs og kan have <b>egne attributter<\/b>. I <b>Anker-modellen<\/b> Relationer bruges kun til at forbinde Anker og <b>kan ikke have egne attributter<\/b>. Denne forskel giver v\u00e6sentligt forskellige tilgange til modellering <b>af fakta<\/b>, hvilket vil blive diskuteret senere.<\/p>\n<h3>Opbevaring af fakta<\/h3>\n<p>\nIndtil nu har vi hovedsageligt talt om modellering af dimensioner. Med fakta er situationen lidt mindre entydig.<\/p>\n<p>I <b>Data Vault<\/b> typisk objekt til opbevaring af fakta \u2014<b> Relation (Link)<\/b>, hvor Satellitterne opsamler de konkrete m\u00e5linger.<\/p>\n<p>Denne tilgang virker intuitivt forst\u00e5elig. Den giver nem adgang til de analyserede m\u00e5linger og ligner generelt en traditionel faktatabel (kun m\u00e5lingerne opbevares ikke i selve tabellen, men i den 'nabo'). Men der er ogs\u00e5 faldgruber: en typisk tilpasning af modellen \u2014 udvidelse af faktan\u00f8glen \u2014 kr\u00e6ver <b>tilf\u00f8jelse af en ny udenlandsk n\u00f8gle i Link<\/b>. Og dette 'bryder' modulariteten og kan potentielt kr\u00e6ve tilpasninger af andre objekter.<\/p>\n<p>I <b>Anker-modellen<\/b> Relationen kan ikke have egne attributter, s\u00e5 denne tilgang vil ikke v\u00e6re b\u00e6redygtig \u2014 absolut alle attributter og m\u00e5linger skal v\u00e6re bundet til et specifikt anker. Konklusionen er simpel \u2014 <b>for hvert faktum er der ogs\u00e5 behov for sit eget anker<\/b>. For some of what we consider facts, this might seem natural \u2014 for example, the fact of a purchase easily reduces to the \u201corder\u201d or \u201creceipt\u201d object, and visiting a website corresponds to a session, etc. However, there are also facts for which finding such a natural \u201cobject carrier\u201d is not so straightforward \u2014 for instance, the stock levels in warehouses at the start of each day. <\/p>\n<p>Consequently, there are no issues with modularity when expanding the fact key in the Anchor model (it\u2019s simply enough to add a new Relationship to the corresponding Anchor), but the design of the model to display facts is less straightforward; \u201cartificial\u201d Anchors may appear, representing a business object model in a non-obvious way.<\/p>\n<h3>How flexibility is achieved<\/h3>\n<p>\nThe resulting construct in both cases contains <b>significantly more tables<\/b>, than traditional measures. But it can occupy <b>significantly less disk space<\/b> with the same set of versioned attributes as traditional measures. There\u2019s no magic here, of course \u2014 it\u2019s all about normalization. By distributing attributes across Satellites (in Data Vault) or separate tables (Anchor Model), we reduce (or completely eliminate) <b>the duplication of values of certain attributes when others are changed.<\/b>.<\/p>\n<p>For <b>Data Vault<\/b> The gain will depend on the distribution of attributes across Satellites, and for <b>Anker-modellen<\/b> \u2014 it\u2019s practically directly proportional to the average number of versions per measurement object.<\/p>\n<p>However, the space-saving advantage is important, but not the main advantage of separate storage of attributes. Along with the separate storage of relationships, this approach makes the repository <b>a modular structure.<\/b>This means that adding both individual attributes and entire new subject areas to such a model looks like <b>an extension<\/b> over the existing set of objects without changing them. And this is precisely what makes the described methodologies flexible.<\/p>\n<p>This also resembles the transition from piece production to mass production \u2014 if in the traditional approach each table of the model is unique and requires individual attention, then in flexible methodologies, it is already a set of standard \u201cparts.\u201d On one hand, there are more tables, and the processes of data loading and querying must appear more complex. On the other \u2014 they become <b>standardized.<\/b>Which means they can be <b>automatiserede og styres af metadata<\/b>. Sp\u00f8rgsm\u00e5let \"hvordan skal vi klare det?\", hvis svar kunne tage en v\u00e6sentlig del af arbejdet med designet af \u00e6ndringerne, er nu simpelthen ikke relevant (ligesom sp\u00f8rgsm\u00e5let om, hvordan \u00e6ndringen af modellen p\u00e5virker de fungerende processer). <\/p>\n<p>Det betyder ikke, at analytikere i et s\u00e5dant system slet ikke er n\u00f8dvendige \u2014 nogen skal stadig arbejde med et s\u00e6t objekter og attributter og finde ud af, hvor og hvordan alle disse data skal indl\u00e6ses. Men omfanget af arbejdet samt sandsynligheden og prisen for fejl reduceres betydeligt. B\u00e5de i analysen og ved udvikling af ETL, som i v\u00e6sentlig grad kan reduceres til redigering af metadata. <\/p>\n<h3>Den m\u00f8rke side<\/h3>\n<p>\nAlt det ovenst\u00e5ende g\u00f8r begge tilgange virkelig fleksible, teknologiske og egnede til iterativ udvikling. Selvf\u00f8lgelig er der ogs\u00e5 en \"f\u00e6tter modbydelighed\", som jeg tror, du allerede har en fornemmelse af.<\/p>\n<p>De-kompositionen af data, som ligger til grund for modulariteten i fleksible arkitekturer, f\u00f8rer til en stigning i antallet af tabeller og derfor <b>overhead<\/b> for joins ved foresp\u00f8rgsel. For blot at f\u00e5 alle attributterne til en dimension er det i et klassisk datalager tilstr\u00e6kkeligt med en enkelt SELECT, mens en fleksibel arkitektur kr\u00e6ver en hel r\u00e6kke joins. Og hvis disse joins kan skrives p\u00e5 forh\u00e5nd til rapporterne, vil analytikere, der er vant til at skrive SQL selv, lide dobbelt.<\/p>\n<p>Der er flere fakta, der letter denne situation:<\/p>\n<p><b>N\u00e5r man arbejder med store dimensioner, bruges n\u00e6sten aldrig alle dets attributter p\u00e5 \u00e9n gang.<\/b> Det betyder, at antallet af joins kan v\u00e6re mindre, end det umiddelbart ser ud til, n\u00e5r man ser p\u00e5 modellen. I Data Vault kan man ogs\u00e5 tage h\u00f8jde for den forventede hyppighed af samtidig brug ved at fordele attributter p\u00e5 satellitter. Selve Hub eller Anker er prim\u00e6rt n\u00f8dvendige til generering og kortl\u00e6gning af surrogate p\u00e5 indl\u00e6sningsstadiet og bruges sj\u00e6ldent i foresp\u00f8rgsler (is\u00e6r g\u00e6lder dette for Anker).<\/p>\n<p><b>Alle joins \u2014 efter n\u00f8gle.<\/b> Desuden reducerer en \"komprimeret\" datastruktur omkostningerne ved at scanne tabeller, hvor det er n\u00f8dvendigt (f.eks. ved filtrering efter attribut-v\u00e6rdi). Dette kan medf\u00f8re, at foresp\u00f8rgsler fra en normaliseret database med mange joins endda kan v\u00e6re hurtigere end at scanne en enkelt tung dimension med mange versioner pr. r\u00e6kke.<\/p>\n<p>For eksempel er der i <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Anchor-Modeling.pdf\">denne <\/a><\/noindex> artiklen en detaljeret sammenligningstest af pr\u00e6stationen for Anchor-modellen med foresp\u00f8rgsler fra en enkelt tabel.<\/p>\n<p><b>Meget afh\u00e6nger af motoren.<\/b> Mange moderne platforme har interne mekanismer til optimering af joins. For eksempel kan MS SQL og Oracle \"springe\" joins over til tabeller, hvis deres data ikke bruges andre steder end i andre joins og ikke p\u00e5virker den endelige foresp\u00f8rgsel (table\/join elimination), mens MPP Vertica if\u00f8lge <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Big_Data_Normalization.pdf\">erfaringer fra kolleger i Avito<\/a><\/noindex>, har vist sig at v\u00e6re en fremragende motor til Anchor-modellen med lidt manuel optimering af foresp\u00f8rgselsplanen. P\u00e5 den anden side virker det ikke som en god id\u00e9 at lagre Anchor-modellen p\u00e5 Click House, som har begr\u00e6nset support for joins.<\/p>\n<p>Derudover findes der <b>specielle teknikker<\/b>, der letter adgangen til data (b\u00e5de hvad ang\u00e5r foresp\u00f8rgselspr\u00e6station og slutbrugere). For eksempel <b>Point-In-Time-tabeller<\/b> i Data Vault eller <b>specialiserede tabel-funktioner<\/b> i Anchor-modellen.<\/p>\n<h2>I alt<\/h2>\n<p>\nEssensen af de n\u00e6vnte fleksible arkitekturer ligger i modulariteten i deres \"konstruktion\". <\/p>\n<p>Netop denne egenskab g\u00f8r det muligt at:<\/p>\n<ul>\n<li>Efter en initial forberedelse, der involverer udrulning af metadata og skrivning af grundl\u00e6ggende ETL-algoritmer, <b>hurtigt levere den f\u00f8rste l\u00f8sning til kunden<\/b> i form af et par rapporter, der indeholder data fra blot nogle f\u00e5 datakilder. Det er ikke n\u00f8dvendigt at t\u00e6nke hele objektmodellen grundigt igennem (selv p\u00e5 et overordnet niveau) for dette.<\/li>\n<li>Datamodellen kan begynde at arbejde (og v\u00e6re nyttig) med bare 2-3 objekter, og derefter <b>gradvist vokse<\/b> (i forhold til Anchor-modellen anvendte Nikolaj <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">en smuk sammenligning med svampe-netv\u00e6rk). <\/a><\/noindex>De fleste tilpasninger, herunder udvidelse af emneomr\u00e5det og tilf\u00f8jelse af nye datakilder,<\/li>\n<li>p\u00e5virker ikke eksisterende funktionalitet og udg\u00f8r ikke en risiko for at \u00f8del\u00e6gge noget, der allerede fungerer. <b>p\u00e5virker ikke eksisterende funktionalitet og udg\u00f8r ikke en risiko for at bryde noget, der allerede fungerer<\/b>.<\/li>\n<li>Takket v\u00e6re dekompositionen i standardelementer fremst\u00e5r ETL-processerne i s\u00e5danne systemer ensartede, deres skrivning kan algoritmiseres og i sidste ende <b>automatiseres<\/b>.<\/li>\n<\/ul>\n<p>\nPrisen for denne fleksibilitet er <b>ydelse<\/b>. Det betyder ikke, at det er umuligt at opn\u00e5 acceptabel ydeevne med s\u00e5danne modeller. Ofte kr\u00e6ver det blot mere indsats og opm\u00e6rksomhed p\u00e5 detaljer for at n\u00e5 de \u00f8nskede m\u00e5linger.<\/p>\n<h2>Applikationer<\/h2>\n<p><\/p>\n<h4>Entity-typer <b>Data Vault<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/6bbaee505587152d7e5c11b2889bf25a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL\u00e6s mere om Data Vault:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/danlinstedt.com\/\">Dan Lestads hjemmeside<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.dwh-club.com\/ru\/dwh-bi-articles\/vse-o-data-vault.html\">Alt om Data Vault p\u00e5 russisk<\/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>Entity-typer <b>Anchor Model<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/d518f01e6a5c241e9e73d1ea0210c557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL\u00e6s mere om Anchor Model:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/\">Hjemmesiden for skaberne af Anchor Model<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">Artikel om erfaringerne med implementering af Anchor Model i Avito<\/a><\/noindex><\/p>\n<p>Oversigtstabel med f\u00e6lles tr\u00e6k og forskelle p\u00e5 de betragtede tilgange:<\/p>\n<p><img decoding=\"async\" alt=\"Oversigt over fleksible DWH designmetoder\" src=\"\/wp-content\/uploads\/2020\/08\/807717245fd874ab141031fc64e584fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Overblik over fleksible DWH-designmetoder | ProHoster","description":"Udvikling af et datalager er en lang og seri\u00f8s opgave.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/92015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=92015"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/92015\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/92016"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=92015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=92015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=92015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}