{"id":283,"date":"2024-10-06T16:20:49","date_gmt":"2024-10-06T16:20:49","guid":{"rendered":"https:\/\/oberle-it-beratung.de\/?p=283"},"modified":"2024-10-06T16:20:49","modified_gmt":"2024-10-06T16:20:49","slug":"dry-and-coc","status":"publish","type":"post","link":"https:\/\/www.elrebo.de\/index.php\/2024\/10\/06\/dry-and-coc\/","title":{"rendered":"DRY and CoC"},"content":{"rendered":"\n

Don’t repeat yourself<\/h3>\n\n\n\n

Dieser Satz ist die Quintessenz des “DRY Principle of Software Development”. Eine Beschreibung dazu gibt es hier bei Wikipedia<\/a>. Es geht dabei darum, dass man in einem System den gleichen Code nicht mehrfach schreibt, sondern, dass es eine Stelle gibt, an der der Code steht und dieser Code im System immer wieder verwendet werden kann.<\/p>\n\n\n\n

Auch bei der Data Warehouse Automation geht es darum, den Aufwand f\u00fcr die wiederholte Definition immer gleicher Programmteile (z.B. f\u00fcr Hubs, Links, Satellites und Stages) zu reduzieren, indem man ein Tool wie z.B. dbt<\/a> verwendet und die DataVault-Objekte wie Hubs, Links und Satellites z.B. mit den dbt-Makros von AutomateDV<\/a> beschreibt. So eine L\u00f6sung habe ich in meinem Beitrag Ein DWH mit git, Linux, Docker, PostgreSQL, dbt und AutomateDV<\/a> beschrieben.<\/p>\n\n\n\n

Doch das ist nat\u00fcrlich noch nicht das Ende der Abstraktion, wie ich schon in meinem Beitrag Die Kraft der Abstraktion<\/a> beschrieben habe. Man kann sich einen Generator bauen, der den AutomateDV-Code f\u00fcr die Objekte des Raw Vault aus einer noch kleineren Steuerdatei erzeugt. Wie das geht, steht in meinem Beitrag GenRawVault: wie man aus einer Steuerdatei ein ganzes DWH generieren kann<\/a>.<\/p>\n\n\n\n

Bei der Steuerdatei RawVault.xml<\/a>, die dort beschrieben ist, handelt es sich quasi um eine DSL (domain specific language) f\u00fcr einen RawVault gem\u00e4\u00df Data Vault 2.0. Man erkauft sich die Kompaktheit der Darstellung damit, dass man keine individuellen Abweichungen und Erg\u00e4nzungen mehr in sein System einbringen kann, die in der DSL nicht vorgesehen sind. Aber das ist ja genau das, was Dan Linstedt fordert – dass man sich strikt an das Konzept von DataVault 2.0 halten soll, da nur so die Effizienz von DV2.0 erhalten bleibt.<\/p>\n\n\n\n

Convention over Configuration<\/h3>\n\n\n\n

Und damit sind wir beim zweiten Prinzip der Software-Entwicklung, auf das ich in diesem Beitrag eingehen m\u00f6chte: Convention over configuration (CoC). Auch hier gibt es eine Beschreibung auf Wikipedia<\/a>. Man verwendet Festlegungen (Konventionen), aus denen sich das “normale” Verhalten des Systems ergibt. Nur wenn man Abweichungen von diesem “normalen” Verhalten ben\u00f6tigt, dann konfiguriert man diese. <\/p>\n\n\n\n

Mit diesen beiden Prinzipien im Sinn habe ich die Struktur der RawVault.xml ver\u00e4ndert und eine neue Version (schema_version=”2″) erstellt. Der Rest dieses Beitrags beschreibt diese neue Version im Vergleich zur bisherigen. <\/p>\n\n\n\n

Die Struktur der DSL, die bisher in der Steuerdatei RawVault.xml verwendet wurde, orientiert sich am Ablauf der Daten\u00fcbernahme in das DWH:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n