{"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\/de\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","title":{"rendered":"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Die Entwicklung eines Data Warehouses ist eine langwierige und ernsthafte Angelegenheit. <\/p>\n<p>Vieles im Leben eines Projekts h\u00e4ngt davon ab, wie gut das objektspezifische Modell und die Datenbankstruktur zu Beginn durchdacht sind.<\/p>\n<p>Allgemein wurden und werden verschiedene Varianten der Kombination des \"Sternschemas\" mit der dritten Normalform verwendet. In der Regel nach dem Prinzip: Ausgangsdaten \u2014 3NF, Data Marts \u2014 Stern. Dieser Ansatz, der sich \u00fcber die Zeit bew\u00e4hrt hat und durch zahlreiche Studien untermauert wird, ist das Erste (und manchmal das Einzige), was einem erfahrenen DWH-Entwickler in den Sinn kommt, wenn es darum geht, wie ein analytisches Data Warehouse aussehen sollte.<\/p>\n<p>Auf der anderen Seite neigt das Gesch\u00e4ft insgesamt und die Anforderungen der Kunden im Besonderen dazu, sich schnell zu \u00e4ndern, w\u00e4hrend die Daten sowohl \"in die Tiefe\" als auch \"in die Breite\" wachsen. Und hier zeigt sich der Hauptnachteil des Sternschemas: die begrenzte <b>Flexibilit\u00e4t<\/b>.<\/p>\n<p>Und wenn pl\u00f6tzlich in Ihrem ruhigen und gem\u00fctlichen Leben als DWH-Entwickler:<\/p>\n<ul>\n<li>die Aufgabe auftaucht, \"schnell irgendetwas zu machen, und dann schauen wir weiter\";<\/li>\n<li>ein rasant wachsendes Projekt mit der Anbindung neuer Quellen und der Umgestaltung des Gesch\u00e4ftsmodells mindestens einmal pro Woche erscheint;<\/li>\n<li>ein Kunde auftritt, der sich nicht vorstellen kann, wie das System aussehen und welche Funktionen es letztendlich ausf\u00fchren sollte, aber bereit ist, mit Experimenten zu arbeiten und schrittweise den gew\u00fcnschten Erfolg konkret zu pr\u00e4zisieren;<\/li>\n<li>ein Projektmanager mit der frohen Botschaft vorbeischaut: \"Und jetzt haben wir Agile!\".<\/li>\n<\/ul>\n<p>\nOder wenn Sie einfach nur neugierig sind, wie man Data Warehouses sonst noch bauen kann \u2014 willkommen unter dem Cut!<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" 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>Was bedeutet \"Flexibilit\u00e4t\"<\/h3>\n<p>\nZun\u00e4chst sollten wir kl\u00e4ren, \u00fcber welche Eigenschaften ein System verf\u00fcgen muss, damit man es als \"flexibel\" bezeichnen kann. <\/p>\n<p>Es ist wichtig zu betonen, dass die beschriebenen Eigenschaften sich gerade auf <b>das System<\/b>, und nicht auf <b>den Prozess <\/b>seiner Entwicklung beziehen. Daher, wenn Sie dar\u00fcber lesen wollten, wie Agile als Entwicklungsmethodik funktioniert, ist es besser, sich mit anderen Artikeln vertraut zu machen. Zum Beispiel gibt es auf Habr eine Vielzahl interessanter Materialien (sowohl <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436178\/\">\u00fcbersichtlicher<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/284012\/\">praktischer<\/a><\/noindex>, als auch <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataart\/blog\/245605\/\">problemorientierter Art).<\/a><\/noindex>).<\/p>\n<p>Das bedeutet jedoch nicht, dass der Entwicklungsprozess und die Struktur des DWH \u00fcberhaupt nicht miteinander verbunden sind. Im Allgemeinen sollte die Entwicklung eines flexiblen Architektur-Data Warehouses nach Agile erheblich einfacher sein. In der Praxis treten jedoch h\u00e4ufiger Varianten auf, bei denen ein klassisches DWH nach Kimball und Data Vault nach dem Wasserfallmodell entwickelt wird, als gl\u00fcckliche Zuf\u00e4lle der Flexibilit\u00e4t in ihren beiden Auspr\u00e4gungen in einem Projekt zu finden.<\/p>\n<p>Welche M\u00f6glichkeiten sollte ein flexibles Data Warehouse also bieten? Hier k\u00f6nnen drei Punkte hervorgehoben werden:<\/p>\n<ol>\n<li><b>Fr\u00fche Lieferung und schnelle Nachbearbeitung<\/b> \u2014 das bedeutet, dass im Idealfall das erste Gesch\u00e4ftsergebnis (zum Beispiel die ersten funktionierenden Berichte) so fr\u00fch wie m\u00f6glich erzielt werden sollte, also noch bevor das gesamte System vollst\u00e4ndig konzipiert und implementiert ist. Dabei sollte auch jede nachfolgende Nachbearbeitung m\u00f6glichst wenig Zeit in Anspruch nehmen.<\/li>\n<li><b>Iterative Nachbearbeitung<\/b> \u2014 das bedeutet, dass jede nachfolgende Nachbearbeitung idealerweise nicht den bereits funktionierenden Funktionsumfang beeintr\u00e4chtigen sollte. Genau dieser Punkt wird h\u00e4ufig zum gr\u00f6\u00dften Albtraum bei gro\u00dfen Projekten \u2014 fr\u00fch oder sp\u00e4t beginnen einzelne Objekte eine solche Vielzahl von Beziehungen zu entwickeln, dass es einfacher wird, die Logik in einer Kopie daneben vollst\u00e4ndig zu wiederholen, als ein Feld in eine bestehende Tabelle hinzuzuf\u00fcgen. Und wenn Sie \u00fcberrascht sind, dass die Analyse der Auswirkungen einer Nachbearbeitung auf bestehende Objekte mehr Zeit in Anspruch nehmen kann als die Nachbearbeitung selbst \u2014 dann haben Sie wahrscheinlich noch nicht mit gro\u00dfen DWHs in der Banken- oder Telekommunikationsbranche gearbeitet.<\/li>\n<li><b>St\u00e4ndige Anpassung an sich \u00e4ndernde Gesch\u00e4ftsanforderungen<\/b> \u2014 die gesamte objektorientierte Struktur sollte nicht nur mit Blick auf eine m\u00f6gliche Erweiterung entworfen werden, sondern so, dass die Richtung dieser n\u00e4chsten Erweiterung einem w\u00e4hrend der Planungsphase nicht einmal in den Sinn kommen konnte.<\/li>\n<\/ol>\n<p>\nUnd ja, die Einhaltung all dieser Anforderungen in einem System ist m\u00f6glich (nat\u00fcrlich in bestimmten F\u00e4llen und mit einigen Vorbehalten).<\/p>\n<p>Im Folgenden werde ich die zwei beliebtesten Methodiken f\u00fcr die flexible Gestaltung von DWH betrachten \u2014 <b>Anchor Model<\/b> und <b>Data Vault<\/b>. Hinter den Kulissen bleiben so sch\u00f6ne Ans\u00e4tze wie zum Beispiel EAV, 6NF (im reinen Sinne) und alles, was mit NoSQL-L\u00f6sungen zu tun hat \u2014 nicht weil sie in irgendeiner Weise schlechter w\u00e4ren, und auch nicht weil dieser Artikel sonst das Volumen einer durchschnittlichen Dissertation angenommen h\u00e4tte. Es handelt sich einfach um L\u00f6sungen einer etwas anderen Klasse \u2014 entweder um Ans\u00e4tze, die Sie in spezifischen F\u00e4llen anwenden k\u00f6nnen, unabh\u00e4ngig von der Gesamtarchitektur Ihres Projekts (wie EAV), oder um grundlegend andere Paradigmen zur Speicherung von Informationen (wie etwa Graphdatenbanken und andere NoSQL-Varianten).<\/p>\n<h3>Die Probleme des \u201eklassischen\u201c Ansatzes und ihre L\u00f6sungen in flexiblen Methoden<\/h3>\n<p>\n<i>Unter dem \u201eklassischen\u201c Ansatz verstehe ich den guten alten Stern (unabh\u00e4ngig von der konkreten Implementierung der darunterliegenden Schichten, m\u00f6gen mir die Anh\u00e4nger von Kimball, Inmon und CDM verzeihen).<br \/>\n<\/i><\/p>\n<h4>1. Strenge Kardinalit\u00e4t von Beziehungen<\/h4>\n<p>\nDer Grundlage eines solchen Modells liegt eine klare Trennung der Daten zugrunde in <b>Dimensionen (Dimension)<\/b> und <b>Fakten (Fact)<\/b>. Und das ist, verdammtes noch mal, logisch \u2014 denn die Datenanalyse beschr\u00e4nkt sich in \u00fcberwiegendem Ma\u00dfe \u0438\u043c\u0435\u043d\u043d\u043e auf die Analyse bestimmter quantitativer Indikatoren (Fakten) in bestimmten Dimensionen.<\/p>\n<p>Dabei werden die Beziehungen zwischen den Objekten in Form von Verbindungen zwischen Tabellen \u00fcber einen Fremdschl\u00fcssel angelegt. Das sieht ganz nat\u00fcrlich aus, f\u00fchrt aber sofort zur ersten Einschr\u00e4nkung der Flexibilit\u00e4t \u2014 <b>der strengen Definition der Kardinalit\u00e4t von Beziehungen.<\/b>.<\/p>\n<p>Das bedeutet, dass Sie in der Entwurfsphase der Tabellen genau festlegen m\u00fcssen, ob jede Paarung von verbundenen Objekten eine n:m- oder eine 1:n-Beziehung und in \u201ewelcher Richtung\u201c hat. Dies h\u00e4ngt direkt davon ab, in welcher der Tabellen der Prim\u00e4rschl\u00fcssel und in welcher der Fremdschl\u00fcssel sein wird. Eine \u00c4nderung dieser Beziehung bei neuen Anforderungen wird mit hoher Wahrscheinlichkeit eine \u00dcberarbeitung der Datenbank nach sich ziehen.<\/p>\n<p>Zum Beispiel haben Sie beim Entwurf des Objekts \u201eKassenzettel\u201c basierend auf den feierlichen Versprechungen der Verkaufsabteilung die M\u00f6glichkeit einer <b>einzelnen Werbeaktion auf mehrere Kassenzettelposten<\/b> (aber nicht umgekehrt) eingeplant:<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/15226cb79c30364d94147383ba36a8fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nNach einiger Zeit hat das Team eine neue Marketingstrategie eingef\u00fchrt, bei der mehrere Werbeaktionen gleichzeitig auf denselben Artikel wirken k\u00f6nnen. <b>. Und jetzt m\u00fcssen Sie die Tabellen nachbearbeiten, indem Sie die Beziehung in ein separates Objekt auslagern.<\/b>. <\/p>\n<p>(Alle abgeleiteten Objekte, in denen ein Join-Check f\u00fcr die Promotion stattfindet, m\u00fcssen jetzt ebenfalls \u00fcberarbeitet werden).<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/3c4d84a31088660257d74c4c703071e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Beziehungen im Data Vault und im Anchor Model<\/b><\/p>\n<p>Es stellte sich als recht einfach heraus, eine solche Situation zu vermeiden: Man muss der Verkaufsabteilung daf\u00fcr nicht vertrauen. <b>Alle Beziehungen sollten urspr\u00fcnglich in separaten Tabellen gespeichert werden<\/b> und als viele-zu-viele verarbeitet werden. <\/p>\n<p>Dieser Ansatz wurde vorgeschlagen <b>von Dan Linstedt<\/b> als Teil der Paradigmen <b>Data Vault<\/b> und wurde vollst\u00e4ndig unterst\u00fctzt <b>von Lars R\u00f6nnb\u00e4ck<\/b> in <b>des Anchor Models<\/b>.<\/p>\n<p>Am Ende erhalten wir das erste Unterscheidungsmerkmal flexibler Methoden:<\/p>\n<blockquote><p>Die Beziehungen zwischen den Objekten werden nicht in den Attributen der \u00fcbergeordneten Entit\u00e4ten gespeichert, sondern stellen einen eigenen Objekttyp dar.<\/p><\/blockquote>\n<p>Im <b>Data Vault<\/b> Solche Verkn\u00fcpfungstabellen werden genannt <b>Link<\/b>, sondern in <b>Anchor Model<\/b> \u2014 <b>Tie<\/b>. Auf den ersten Blick sehen sie sehr \u00e4hnlich aus, obwohl ihre Unterschiede nicht nur im Namen bestehen (wor\u00fcber sp\u00e4ter die Rede sein wird). In beiden Architekturen k\u00f6nnen Verkn\u00fcpfungstabellen <b>beliebige Anzahl von Entit\u00e4ten<\/b> (nicht zwingend 2) verbinden.<\/p>\n<p>Diese vermeintliche Redundanz bietet erhebliche Flexibilit\u00e4t bei der \u00dcberarbeitung. Diese Struktur wird nicht nur tolerant gegen\u00fcber \u00c4nderungen der Kardinalit\u00e4ten bestehender Beziehungen, sondern auch gegen\u00fcber der Hinzuf\u00fcgung neuer \u2014 wenn jetzt ein zu verkn\u00fcpfender Artikel auch einen Bezug zu dem Kassierer hat, der ihn erstellt hat, wird diese Verkn\u00fcpfung einfach eine Erweiterung der bestehenden Tabellen sein, ohne Einfluss auf bestehende Objekte und Prozesse zu nehmen.<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/6a3b942a6e5d04dcbe2ff0881ebdf1bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>2. Daten-Duplikation<\/h4>\n<p>\nDas zweite Problem, das durch flexible Architekturen gel\u00f6st wird, ist weniger offensichtlich und betrifft in erster Linie <b>Dimensionen des Typs SCD2<\/b> (langsam \u00e4ndernde Dimensionen zweiter Art), obwohl nicht nur diese.<\/p>\n<p>In einem klassischen Data Warehouse stellt eine Dimension normalerweise eine Tabelle dar, die einen Surrogatschl\u00fcssel (als PK) sowie eine Reihe von Gesch\u00e4ftsschl\u00fcsseln und Attributen in separaten Spalten enth\u00e4lt. <\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/059dd47b2302b58c19a0144061b78cb4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWenn die Dimension Versionierung unterst\u00fctzt, werden zu dem Standardfeldsatz Zeitgrenzen f\u00fcr die G\u00fcltigkeit der Version hinzugef\u00fcgt, und f\u00fcr jede Zeile in der Quelle gibt es mehrere Versionen im Data Warehouse (eine f\u00fcr jede \u00c4nderung der versionierten Attribute).<\/p>\n<p>Wenn eine Dimension mindestens ein h\u00e4ufig sich \u00e4nderndes versioniertes Attribut enth\u00e4lt, wird die Anzahl der Versionen dieser Dimension erheblich sein (selbst wenn die anderen Attribute nicht versioniert sind oder sich nie \u00e4ndern). Wenn es solch mehrere Attribute gibt, kann die Anzahl der Versionen geometrisch mit ihrer Anzahl wachsen. Eine solche Dimension kann erheblichen Speicherplatz in Anspruch nehmen, obwohl der Gro\u00dfteil der darin gespeicherten Daten einfach Duplikate von Werten unver\u00e4nderlicher Attribute aus anderen Zeilen sind.<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/f3d5a4fd83a5ef36355961302173791d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDabei wird sehr oft auch noch <b>Denormalisierung<\/b> \u2014 Teile der Attribute werden absichtlich als Werte gespeichert, anstatt als Verweis auf ein Verzeichnis oder eine andere Dimension. Dieser Ansatz beschleunigt den Datenzugriff, indem die Anzahl der Joins beim Zugriff auf die Dimension verringert wird.<\/p>\n<p>In der Regel f\u00fchrt dies dazu, dass <b>die gleichen Informationen gleichzeitig an mehreren Orten gespeichert werden<\/b>. Beispielsweise k\u00f6nnen Informationen \u00fcber den Wohnort und die Zugeh\u00f6rigkeit zur Kundenkategorie gleichzeitig in den Dimensionen \"Kunde\" sowie in den Fakten \"Kauf\", \"Lieferung\" und \"Anrufe beim Callcenter\" gespeichert werden, ebenso wie in der Verkn\u00fcpfungstabelle \"Kunde \u2014 Kundenbetreuer\".<\/p>\n<p>Insgesamt trifft das oben Beschriebene auch auf gew\u00f6hnliche (nicht versionierte) Dimensionen zu, jedoch kann dies bei versionierten Dimensionen einen anderen Umfang haben: Das Erscheinen einer neuen Version eines Objekts (insbesondere r\u00fcckblickend) f\u00fchrt nicht nur zur Aktualisierung aller verbundenen Tabellen, sondern zu einer kaskadenartigen Erstellung neuer Versionen verbundener Objekte \u2014 wenn Tabelle 1 beim Erstellen von Tabelle 2 verwendet wird und Tabelle 2 beim Erstellen von Tabelle 3, usw. Selbst wenn kein Attribut aus Tabelle 1 beim Erstellen von Tabelle 3 verwendet wird (sondern andere Attribute aus Tabelle 2, die aus anderen Quellen stammen), f\u00fchrt das versionierte Update dieser Struktur zumindest zu zus\u00e4tzlichen Overheadkosten und m\u00f6glicherweise zu unn\u00f6tigen Versionen in Tabelle 3, die in diesem Fall v\u00f6llig \"unbeteiligt\" ist, und weiter entlang der Kette.<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/2935f93abc46f02bdc528accda2af758.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>3. Nichtlineare Komplexit\u00e4t der \u00dcberarbeitung<\/h4>\n<p>\nDabei erh\u00f6ht jede neue Sicht, die auf der Grundlage einer anderen erstellt wird, die Anzahl der Stellen, an denen sich die Daten bei \u00c4nderungen im ETL \"auseinanderentwickeln\" k\u00f6nnen. Dies wiederum f\u00fchrt zu einer steigenden Komplexit\u00e4t (und Dauer) jeder nachfolgenden \u00dcberarbeitung.<\/p>\n<p>Wenn das oben Beschriebene Systeme mit selten \u00fcberarbeiteten ETL-Prozessen betrifft, ist es m\u00f6glich, in solch einem Paradigma zu leben \u2013 es reicht aus, einfach sicherzustellen, dass neue Anpassungen korrekt in alle damit verbundenen Objekte eingearbeitet werden. Wenn jedoch h\u00e4ufig Anpassungen stattfinden, steigt die Wahrscheinlichkeit, versehentlich mehrere Verbindungen zu \"\u00fcbersehen\", erheblich.<\/p>\n<p>Ber\u00fccksichtigt man au\u00dferdem, dass \"versionsbasierte\" ETL erheblich komplizierter ist als \"nicht versionsbasierte\", wird es ziemlich schwierig, Fehler bei der h\u00e4ufigen Anpassung all dieser Komponenten zu vermeiden.<\/p>\n<h3>Speicherung von Objekten und Attributen im Data Vault und im Anchor Model<\/h3>\n<p>\nDer von den Autoren flexibler Architekturen vorgeschlagene Ansatz kann wie folgt formuliert werden:<\/p>\n<blockquote><p>Es ist notwendig, das, was sich \u00e4ndert, von dem, was unver\u00e4ndert bleibt, zu trennen. Das hei\u00dft, Schl\u00fcssel getrennt von Attributen zu speichern.<\/p><\/blockquote>\n<p> Dabei sollte man nicht verwechseln <b>nicht versionsbasiert<\/b> Attribut mit <b>unver\u00e4ndert<\/b>: Erstes speichert nicht die Historie seiner Ver\u00e4nderungen, kann sich aber \u00e4ndern (zum Beispiel bei der Korrektur eines Eingabefehlers oder bei Erhalt neuer Daten), letzteres \u2013 \u00e4ndert sich niemals.<\/p>\n<p>Die Meinungen dar\u00fcber, was genau im Data Vault und im Anchor Model als unver\u00e4nderlich angesehen werden kann, gehen auseinander.<\/p>\n<p>Aus der Sicht der Architektur <b>Data Vault<\/b>, kann man als unver\u00e4nderlich betrachten <b>das gesamte Set von Schl\u00fcsseln<\/b> \u2013 nat\u00fcrliche (Steuernummer des Unternehmens, Produktcode im Quellsystem usw.) und surrogate. Dabei k\u00f6nnen die anderen Attribute in Gruppen entsprechend der Quelle und\/or H\u00e4ufigkeit der \u00c4nderungen unterteilt werden und <b>f\u00fcr jede Gruppe eine separate Tabelle f\u00fchren<\/b> mit einem unabh\u00e4ngigen Satz von Versionen.<\/p>\n<p>Im Paradigma <b>Anchor Model<\/b> gilt als unver\u00e4nderlich <b>nur der surrogate Schl\u00fcssel<\/b> der Entit\u00e4t. Alles andere (einschlie\u00dflich der nat\u00fcrlichen Schl\u00fcssel) ist einfach ein Sonderfall seiner Attribute. Dabei <b>sind alle Attribute standardm\u00e4\u00dfig unabh\u00e4ngig voneinander<\/b>, deshalb sollte f\u00fcr jedes Attribut eine <b>separate Tabelle erstellt werden<\/b>.<\/p>\n<p>Im <b>Data Vault<\/b> Tabellen, die die Schl\u00fcsseldaten enthalten, werden genannt <b>Hubs<\/b>. Hubs enthalten immer eine feste Anzahl von Feldern:<\/p>\n<ul>\n<li>Nat\u00fcrliche Schl\u00fcssel der Entit\u00e4t<\/li>\n<li>Surrogate Schl\u00fcssel<\/li>\n<li>Verweis auf die Quelle<\/li>\n<li>Zeitpunkt der Hinzuf\u00fcgung des Datensatzes<\/li>\n<\/ul>\n<p>\nDatens\u00e4tze in Hubs <b>werden niemals ge\u00e4ndert und haben keine Versionen.<\/b>. \u00c4u\u00dferlich \u00e4hneln Hubs sehr den ID-Map-Tabellen, die in einigen Systemen zur Generierung von Surrogaten verwendet werden. Im Data Vault wird jedoch empfohlen, anstelle einer Ganzzahl-Sequenz einen Hash des Satzes von Gesch\u00e4ftsschl\u00fcsseln als Surrogate zu verwenden. Dieser Ansatz vereinfacht das Laden von Beziehungen und Attributen aus Quellen (es ist nicht erforderlich, sich mit dem Hub zu verbinden, um ein Surrogat zu erhalten, es gen\u00fcgt, einfach den Hash des nat\u00fcrlichen Schl\u00fcssels zu berechnen), kann jedoch andere Probleme verursachen (z. B. Kollisionen, Gro\u00df- und Kleinschreibung und nicht druckbare Zeichen in stringbasierten Schl\u00fcsseln usw.), weshalb er nicht allgemein anerkannt ist.<\/p>\n<p>Alle anderen Attribute der Entit\u00e4ten werden in speziellen Tabellen gespeichert, die <b>Satelliten (Satellit)<\/b>. Ein Hub kann mehrere Satelliten haben, die unterschiedliche S\u00e4tze von Attributen speichern.<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/e145f211b8cfb51894e6e1789991e1cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Verteilung der Attribute auf Satelliten erfolgt nach dem Prinzip <b>gemeinsamer \u00c4nderung<\/b> \u2014 in einem Satelliten k\u00f6nnen nicht versionierte Attribute (z. B. Geburtsdatum und SNILS f\u00fcr nat\u00fcrliche Personen) gespeichert werden, in einem anderen \u2014 selten ge\u00e4nderte versionierte Attribute (z. B. Nachname und Reisepassnummer), in einem dritten \u2014 h\u00e4ufig ge\u00e4nderte (z. B. Lieferadresse, Kategorie, Datum der letzten Bestellung usw.). Die Versionierung erfolgt dabei auf Ebene einzelner Satelliten und nicht der Entit\u00e4t insgesamt, weshalb die Verteilung der Attribute so erfolgen sollte, dass die \u00dcberlappung von Versionen innerhalb eines Satelliten minimal ist (was die Gesamtanzahl der gespeicherten Versionen reduziert). <\/p>\n<p>Au\u00dferdem werden zur Optimierung des Datenladeprozesses h\u00e4ufig Attribute, die aus verschiedenen Quellen stammen, in separate Satelliten ausgelagert.<\/p>\n<p>Satelliten sind mit dem Hub \u00fcber <b>einen Fremdschl\u00fcssel<\/b> verbunden (was der Kardinalit\u00e4t 1 zu vielen entspricht). Das bedeutet, dass multiple Attributwerte (z. B. mehrere Telefonnummern eines Kunden) von dieser Architektur \u201estandardm\u00e4\u00dfig\u201c unterst\u00fctzt werden.<\/p>\n<p>Im <b>Anker-Modell (Anchor Model)<\/b> Tabellen, die Schl\u00fcssel speichern, werden <b>Ankern (Anchor)<\/b>. Und sie speichern: <\/p>\n<ul>\n<li><b>Nur surrogate Schl\u00fcssel<\/b><\/li>\n<li>Verweis auf die Quelle<\/li>\n<li>Zeitpunkt der Hinzuf\u00fcgung des Datensatzes<\/li>\n<\/ul>\n<p>\nNat\u00fcrliche Schl\u00fcssel gelten im Rahmen des Anker-Modells als <b>normale Attribute<\/b>. Diese Variante mag komplexer erscheinen, bietet jedoch viel mehr Spielraum f\u00fcr die Identifikation des Objekts.<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/0bf941581fd1177eda228d4429cf69db.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZum Beispiel, wenn Daten zu demselben Wesen aus verschiedenen Systemen stammen, wobei jedes System seinen eigenen nat\u00fcrlichen Schl\u00fcssel verwendet. In Data Vault kann dies zu ziemlich komplexen Konstruktionen aus mehreren Hubs f\u00fchren (einer pro Quelle + eine zusammenf\u00fchrende Master-Version), w\u00e4hrend im Anker-Modell der nat\u00fcrliche Schl\u00fcssel jeder Quelle in ein eigenes Attribut gelangt und unabh\u00e4ngig von allen anderen bei der Ladung verwendet werden kann. <\/p>\n<p>Aber hier steckt ein t\u00fcckischer Punkt: Wenn in einem Wesen Attribute aus verschiedenen Systemen zusammengef\u00fchrt werden, gibt es wahrscheinlich einige <b>Regeln zur \"Zusammenf\u00fchrung\"<\/b>, nach denen das System verstehen muss, dass Datens\u00e4tze aus verschiedenen Quellen einem einzigen Exemplar des Wesens entsprechen. <\/p>\n<p>Im <b>Data Vault<\/b> Diese Regeln werden wahrscheinlich die Bildung von <b>\"surrogaten Hubs\" der Master-Entit\u00e4t<\/b> bestimmen und keinen Einfluss auf die Hubs haben, die die nat\u00fcrlichen Schl\u00fcssel der Quellen und deren urspr\u00fcngliche Attribute speichern. Wenn sich die Regeln zur Zusammenf\u00fchrung zu irgendeinem Zeitpunkt \u00e4ndern (oder ein Update der Attribute, nach denen sie erfolgt, kommt), reicht es aus, die surrogate Hubs neu zu generieren.<\/p>\n<p>Im <b>Im Anker-Modell<\/b> wird ein solches Wesen wahrscheinlich in <b>einem einzigen Anker<\/b>gespeichert. Das bedeutet, dass alle Attribute, unabh\u00e4ngig von der Quelle, aus der sie stammen, an denselben Surrogat gebunden sind. Die f\u00e4lschlicherweise zusammengef\u00fchrten Datens\u00e4tze zu trennen und insgesamt die Aktualit\u00e4t der Zusammenf\u00fchrung in einem solchen System zu \u00fcberwachen, k\u00f6nnte sich als deutlich schwieriger erweisen, insbesondere wenn die Regeln ziemlich komplex sind und sich h\u00e4ufig \u00e4ndern, w\u00e4hrend dasselbe Attribut aus verschiedenen Quellen stammen kann (obwohl es m\u00f6glich ist, da jede Attribut-Version einen Verweis auf ihre Quelle speichert).<\/p>\n<p>In jedem Fall, wenn in Ihrem System die Implementierung von Funktionen <b>zur Dublettenbeseitigung, zur Zusammenf\u00fchrung von Datens\u00e4tzen und anderen MDM-Elementen<\/b>vorgesehen ist, sollten Sie besonders sorgf\u00e4ltig die Aspekte der Speicherung nat\u00fcrlicher Schl\u00fcssel in flexiblen Methodologien betrachten. Wahrscheinlich wird die komplexere Struktur von Data Vault pl\u00f6tzlich als sicherer hinsichtlich Zusammenf\u00fchrungsfehler erscheinen.<\/p>\n<p><b>Das Anker-Modell<\/b> sieht auch einen zus\u00e4tzlichen Objekttyp vor, der als <b>Knoten (Knot)<\/b> bezeichnet wird, <b>der im Wesentlichen eine spezielle Form des Ankers ist.<\/b>, der nur ein Attribut enthalten kann. Knoten sollen zum Speichern von flachen Verzeichnissen verwendet werden (zum Beispiel Geschlecht, Familienstand, Kundenkategorie usw.). Im Gegensatz zum Anker hat der Knoten <b>keine verkn\u00fcpften Attributtabellen<\/b>, und sein einziges Attribut (Name) wird immer in einer Tabelle mit dem Schl\u00fcssel gespeichert. Knoten werden mit Ankern durch Beziehungstabellen (Tie) verbunden, \u00e4hnlich wie Anker untereinander.<\/p>\n<p>Es gibt keine eindeutige Meinung zur Verwendung von Knoten. Zum Beispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/azathot\/\">Nikolai Golow<\/a><\/noindex>, der aktiv die Anwendung des Anker-Modells in Russland vorantreibt, ist der Meinung (nicht ohne Grundlage), dass f\u00fcr kein Verzeichnis genau behauptet werden kann, dass es <b>immer<\/b> statisch und einadrig sein wird, weshalb es f\u00fcr alle Objekte besser ist, sofort einen vollst\u00e4ndigen Anker zu verwenden.<\/p>\n<p>Ein weiterer wichtiger Unterschied zwischen Data Vault und dem Anker-Modell besteht darin, dass es <b>Attribute bei Beziehungen gibt.<\/b>:<\/p>\n<p>Im <b>Data Vault<\/b> Beziehungen sind ebenso vollst\u00e4ndige Objekte wie Hubs und k\u00f6nnen <b>eigene Attribute haben.<\/b>. In <b>Im Anker-Modell<\/b> Beziehungen werden nur zur Verbindung von Ankern verwendet und <b>k\u00f6nnen keine eigenen Attribute haben.<\/b>. Dieser Unterschied f\u00fchrt zu grunds\u00e4tzlich unterschiedlichen Ans\u00e4tzen bei der Modellierung <b>von Fakten<\/b>, wor\u00fcber weiter unten gesprochen wird.<\/p>\n<h3>Ablage von Fakten<\/h3>\n<p>\nBis jetzt haben wir haupts\u00e4chlich \u00fcber die Modellierung von Dimensionen gesprochen. Bei Fakten ist die Situation etwas weniger eindeutig.<\/p>\n<p>Im <b>Data Vault<\/b> typisches Objekt zur Speicherung von Fakten \u2013<b> die Beziehung (Link)<\/b>, in deren Satelliten sich reale Kennzahlen ansammeln.<\/p>\n<p>Dieser Ansatz erscheint intuitiv verst\u00e4ndlich. Er bietet einfachen Zugang zu den zu analysierenden Kennzahlen und \u00e4hnelt im Allgemeinen einer traditionellen Faktentabelle (nur dass die Kennzahlen nicht in der Tabelle selbst, sondern in der \"benachbarten\" gespeichert werden). Aber es gibt auch Haken: Eine der typischen Anpassungen des Modells \u2014 die Erweiterung des Faktenschl\u00fcssels \u2014 erfordert <b>die Hinzuf\u00fcgung eines neuen Fremdschl\u00fcssels in den Link.<\/b>Dies \"bricht\" wiederum die Modularit\u00e4t und k\u00f6nnte potenziell Anpassungen bei anderen Objekten erforderlich machen.<\/p>\n<p>Im <b>Im Anker-Modell<\/b> Die Beziehung kann keine eigenen Attribute haben, daher wird dieser Ansatz nicht funktionieren \u2014 alle Attribute und Kennzahlen m\u00fcssen an einen bestimmten Anker gebunden sein. Die Schlussfolgerung ist einfach \u2014 <b>jeder Fakt ben\u00f6tigt ebenfalls seinen eigenen Anker.<\/b>. F\u00fcr einen Teil dessen, was wir als Fakten betrachten, mag es nat\u00fcrlich erscheinen \u2013 zum Beispiel l\u00e4sst sich die Tatsache eines Kaufs gut auf das Objekt \u201cBestellung\u201d oder \u201cQuittung\u201d reduzieren, der Besuch einer Website auf eine Sitzung usw. Aber es gibt auch Fakten, f\u00fcr die es nicht so einfach ist, ein solches nat\u00fcrliches \u201cTr\u00e4ger-Objekt\u201d zu finden \u2013 zum Beispiel die Best\u00e4nde von Waren in Lagern zu Beginn eines jeden Tages. <\/p>\n<p>Entsprechend gibt es bei der Modularit\u00e4t beim Erweitern des Faktenschl\u00fcssels im Anker-Modell keine Probleme (es reicht aus, einfach eine neue Beziehung zu dem entsprechenden Anker hinzuzuf\u00fcgen), aber das Design des Modells zur Darstellung von Fakten ist weniger eindeutig, es k\u00f6nnten \u201ck\u00fcnstliche\u201d Anker entstehen, die das Gesch\u00e4ftsobjektmodell nicht offensichtlich darstellen.<\/p>\n<h3>Wie Flexibilit\u00e4t erreicht wird<\/h3>\n<p>\nDie resultierende Konstruktion enth\u00e4lt in beiden F\u00e4llen <b>deutlich mehr Tabellen<\/b>, als eine traditionelle Dimension. Sie kann aber <b>deutlich weniger Speicherplatz ben\u00f6tigen<\/b> bei demselben Satz von Versionsattributen wie bei einer traditionellen Dimension. Es gibt hier nat\u00fcrlich keine Magie \u2013 alles h\u00e4ngt von der Normalisierung ab. Wenn wir Attribute auf Satelliten (im Data Vault) oder separate Tabellen (im Anker-Modell) verteilen, reduzieren wir (oder schlie\u00dfen ganz aus) <b>die Duplizierung von Werten einiger Attribute bei der \u00c4nderung anderer<\/b>.<\/p>\n<p>F\u00fcr <b>Data Vault<\/b> der Gewinn h\u00e4ngt von der Verteilung der Attribute auf Satelliten ab, und f\u00fcr <b>Im Anker-Modell<\/b> ist er praktisch direkt proportional zur durchschnittlichen Anzahl von Versionen eines Messobjekts.<\/p>\n<p>Der Gewinn bei dem ben\u00f6tigten Platz ist jedoch ein wichtiges, aber nicht das Hauptargument f\u00fcr die separate Speicherung von Attributen. Zusammen mit der getrennten Speicherung von Beziehungen macht dieser Ansatz das Speicherformat <b>modular<\/b>. Das bedeutet, dass das Hinzuf\u00fcgen sowohl einzelner Attribute als auch ganzer neuer Fachbereiche in einem solchen Modell wie eine <b>Erweiterung<\/b> \u00fcber die bestehende Sammlung von Objekten ohne deren \u00c4nderung aussieht. Und genau das macht die beschriebenen Methodologien flexibel.<\/p>\n<p>Das erinnert auch an den \u00dcbergang von Einzelproduktion zu Massenproduktion \u2013 w\u00e4hrend im traditionellen Ansatz jede Tabelle des Modells einzigartig ist und besondere Aufmerksamkeit erfordert, handelt es sich in flexiblen Methodologien bereits um eine Reihe typischer \u201cTeile\u201d. Einerseits gibt es mehr Tabellen, die Prozesse zum Laden und Abfragen von Daten erscheinen komplizierter. Andererseits werden sie <b>typisch<\/b>. Das bedeutet, sie k\u00f6nnen sein <b>automatisiert und werden von Metadaten gesteuert<\/b>. Die Frage \"Wie werden wir es umsetzen?\", deren Antwort einen erheblichen Teil der Entwicklungsarbeiten f\u00fcr Verbesserungen ausmachen konnte, stellt sich jetzt einfach nicht mehr (wie auch die Frage nach den Auswirkungen einer Modell\u00e4nderung auf die laufenden Prozesse). <\/p>\n<p>Das bedeutet nicht, dass Analysten in einem solchen System v\u00f6llig \u00fcberfl\u00fcssig sind \u2013 jemand muss immer noch eine Reihe von Objekten mit Attributen bearbeiten und herausfinden, woher und wie all das geladen werden kann. Aber der Arbeitsaufwand sowie die Wahrscheinlichkeit und die Kosten eines Fehlers werden erheblich reduziert. Sowohl in der Analysephase als auch bei der Entwicklung von ETL, die zu einem erheblichen Teil auf die Bearbeitung von Metadaten hinauslaufen kann. <\/p>\n<h3>Die dunkle Seite<\/h3>\n<p>\nAlles, was oben beschrieben wurde, macht beide Ans\u00e4tze tats\u00e4chlich flexibel, technologisch fortschrittlich und geeignet f\u00fcr iterative Anpassungen. Nat\u00fcrlich gibt es auch \"ein Fass voll Teer\", von dem Sie, denke ich, bereits eine Ahnung haben.<\/p>\n<p>Die Dekomposition von Daten, die der Modularit\u00e4t flexibler Architekturen zugrunde liegt, f\u00fchrt zu einer erh\u00f6hten Anzahl von Tabellen und somit <b>\u00dcberheadkosten<\/b> bei Joins w\u00e4hrend der Abfrage. Um einfach alle Attribute einer Dimension zu erhalten, ist in einem klassischen Warehouse nur ein Select erforderlich, w\u00e4hrend eine flexible Architektur eine ganze Reihe von Joins erfordert. Dabei k\u00f6nnen f\u00fcr Berichte all diese Joins im Voraus geschrieben werden, doch Analysten, die es gewohnt sind, SQL von Hand zu schreiben, werden doppelt leiden.<\/p>\n<p>Es gibt einige Fakten, die diese Situation erleichtern:<\/p>\n<p><b>Bei der Arbeit mit gro\u00dfen Dimensionen werden fast nie alle ihre Attribute gleichzeitig verwendet.<\/b> Das bedeutet, dass die Anzahl der Joins geringer sein kann, als es auf den ersten Blick beim Betrachten des Modells erscheint. Im Data Vault kann zudem die voraussichtliche H\u00e4ufigkeit der gemeinsamen Nutzung bei der Verteilung von Attributen auf Satelliten ber\u00fccksichtigt werden. Dabei sind die Hubs oder Anker in erster Linie zur Generierung und Zuordnung von Surrogaten w\u00e4hrend des Ladevorgangs erforderlich und werden selten in Abfragen verwendet (insbesondere gilt dies f\u00fcr die Anker).<\/p>\n<p><b>Alle Joins erfolgen nach Schl\u00fcssel.<\/b> Dar\u00fcber hinaus reduziert eine \u201ekompaktere\u201c Methode zur Datenspeicherung die Kosten f\u00fcr das Scannen von Tabellen, wo dies erforderlich ist (zum Beispiel beim Filtern nach Attributwerten). Dies kann dazu f\u00fchren, dass die Abfrage aus einer normalisierten Datenbank mit vielen Joins sogar schneller ist als das Scannen einer einzigen schweren Dimension mit vielen Versionen pro Zeile.<\/p>\n<p>Zum Beispiel, hier in <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Anchor-Modeling.pdf\">dieser <\/a><\/noindex> dem Artikel gibt es einen detaillierten Vergleichstest der Leistung des Anchor-Modells mit einer Abfrage aus einer einzigen Tabelle.<\/p>\n<p><b>Vieles h\u00e4ngt vom Engine ab.<\/b> Viele moderne Plattformen haben interne Mechanismen zur Optimierung von Joins. Zum Beispiel k\u00f6nnen MS SQL und Oracle Joins zu Tabellen \"\u00fcberspringen\", wenn ihre Daten nirgendwo verwendet werden, au\u00dfer in anderen Joins, und keinen Einfluss auf die finale Abfrage haben (table\/join elimination), w\u00e4hrend MPP Vertica laut <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Big_Data_Normalization.pdf\">den Erfahrungen von Kollegen bei Avito<\/a><\/noindex>sich als hervorragende Engine f\u00fcr das Anchor-Modell bew\u00e4hrt hat, vorausgesetzt, es wird eine gewisse manuelle Optimierung des Abfrageplans vorgenommen. Andererseits scheint es nicht die beste Idee zu sein, das Anchor-Modell beispielsweise auf Click House zu speichern, das eine eingeschr\u00e4nkte Unterst\u00fctzung f\u00fcr Joins hat.<\/p>\n<p>Dar\u00fcber hinaus gibt es f\u00fcr beide Architekturen <b>spezielle Techniken<\/b>, die den Zugang zu Daten erleichtern (sowohl hinsichtlich der Abfrageleistung als auch f\u00fcr die Endbenutzer). Zum Beispiel, <b>Point-In-Time-Tabellen<\/b> im Data Vault oder <b>spezielle Tabellenfunktionen<\/b> im Anchor-Modell.<\/p>\n<h2>Insgesamt<\/h2>\n<p>\nDer Kern der besprochenen flexiblen Architekturen besteht in der Modularit\u00e4t ihrer \u201eKonstruktion\u201c. <\/p>\n<p>Genau diese Eigenschaft erm\u00f6glicht es:<\/p>\n<ul>\n<li>Nach einer gewissen anf\u00e4nglichen Vorbereitung, die mit der Bereitstellung von Metadaten und dem Schreiben grundlegender ETL-Algorithmen verbunden ist, <b>dem Kunden schnell ein erstes Ergebnis zur Verf\u00fcgung zu stellen<\/b> in Form von einigen Berichten, die die Daten nur weniger Quellobjekte enthalten. Es ist nicht notwendig, das gesamte Objektmodell (sogar auf hoher Ebene) vollst\u00e4ndig zu durchdenken.<\/li>\n<li>Das Datenmodell kann bereits mit 2-3 Objekten arbeiten (und Nutzen bringen), und dann <b>stufenweise wachsen<\/b> (in Bezug auf das Anchor-Modell hat Nikolai <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">eine <\/a><\/noindex>sch\u00f6ne Analogie zur Myzelstruktur gemacht).<\/li>\n<li>Die meisten Anpassungen, einschlie\u00dflich der Erweiterung des Themenbereichs und der Hinzuf\u00fcgung neuer Quellen, <b>ber\u00fchren die vorhandene Funktionalit\u00e4t nicht und stellen keine Gefahr dar, etwas, das bereits funktioniert, zu brechen.<\/b>.<\/li>\n<li>Durch die Dekonstruktion in standardisierte Elemente erscheinen ETL-Prozesse in solchen Systemen einheitlich, ihre Erstellung l\u00e4sst sich algorithmisieren und letztendlich <b>automatisieren<\/b>.<\/li>\n<\/ul>\n<p>\nDer Preis f\u00fcr diese Flexibilit\u00e4t ist <b>die Leistung<\/b>. Das bedeutet jedoch nicht, dass es unm\u00f6glich ist, in solchen Modellen akzeptable Leistungen zu erreichen. H\u00e4ufig kann es einfach mehr Aufwand und Aufmerksamkeit f\u00fcr Details erfordern, um die gew\u00fcnschten Metriken zu erreichen.<\/p>\n<h2>Anwendungen<\/h2>\n<p><\/p>\n<h4>Entit\u00e4tstypen <b>Data Vault<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/6bbaee505587152d7e5c11b2889bf25a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMehr \u00fcber Data Vault:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/danlinstedt.com\/\">Die Website von Dan Linstedt<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.dwh-club.com\/ru\/dwh-bi-articles\/vse-o-data-vault.html\">Alles \u00fcber Data Vault auf Russisch<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/348188\/\">\u00dcber Data Vault im Habr<\/a><\/noindex><\/p>\n<h4>Entit\u00e4tstypen <b>Anchor Model<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/d518f01e6a5c241e9e73d1ea0210c557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMehr \u00fcber das Anchor Model:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/\">Die Website der Erfinder des Anchor Model<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">Artikel \u00fcber Erfahrungen mit der Implementierung des Anchor Model bei Avito<\/a><\/noindex><\/p>\n<p>Eine \u00dcbersichtstabelle mit gemeinsamen Merkmalen und Unterschieden der behandelten Ans\u00e4tze:<\/p>\n<p><img decoding=\"async\" alt=\"Ein \u00dcberblick \u00fcber flexible Methoden zur DWH-Entwicklung\" src=\"\/wp-content\/uploads\/2020\/08\/807717245fd874ab141031fc64e584fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Quelle: <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.1.1 - 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\/de\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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\u00dcberblick \u00fcber agile DWH-Designmethodologien | ProHoster","description":"Die Entwicklung eines Data Warehouses ist eine langwierige und ernsthafte Angelegenheit.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/92015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=92015"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/92015\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/92016"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=92015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=92015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=92015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}