Namenskonventionen im Data Warehousing
Eine der ersten und wichtigsten Entscheidungen bei der Data-Vault-Entwicklung betrifft die Definition von Namenskonventionen für Datenbankobjekte. Als wesentlicher Bestandteil der Standardisierung sind diese Konventionen zwingend erforderlich, um ein gut strukturiertes und konsistentes Data-Vault-Modell aufrechtzuerhalten. Angemessene Namenskonventionen erhöhen die Benutzerfreundlichkeit des Data Warehouses erheblich, nicht nur für Entwickler, sondern auch für Power-User bei der Datenexploration.
In diesem Artikel stellen wir Ihnen die wichtigsten Überlegungen aus unserem Standardprozess zur Definition von Namenskonventionen vor.
Dokumentation von Namenskonventionen
Es ist eine Sache, die Namenskonventionen für die Entwicklung Ihres Data Warehouses einfach nur zu definieren. Eine ganz andere Herausforderung ist es jedoch, die nötige Konsistenz zu etablieren, damit diese Konventionen auch tatsächlich zu gelebten Standards werden. Daher gehört es zu den Best Practices, eine klare Richtlinie für die Benennung von Data-Warehouse-Objekten zu dokumentieren. In den folgenden Abschnitten erörtern wir verschiedene Aspekte, die Sie bei der Definition von Namenskonventionen für eine Data-Warehouse-Lösung berücksichtigen sollten.
Namenskonventionen: Groß- und Kleinschreibung
Wenn es um die Groß- und Kleinschreibung von Namen geht, gibt es verschiedene Optionen: durchgehende Großschreibung, durchgehende Kleinschreibung, Camel Case und Pascal Case. Auch wenn die Unterschiede gering erscheinen mögen, hat jede Option ihre eigenen Vor- und Nachteile hinsichtlich der Lesbarkeit und der Schnelligkeit beim Tippen.
Letztendlich hängt die Entscheidung für eine bestimmte Schreibweise vom verwendeten Datenbankmanagementsystem ab. Einige Systeme wie PostgreSQL unterstützen case-sensitive Objektnamen, was bei Abweichungen die Verwendung von Anführungszeichen erforderlich macht. Daher bevorzugen PostgreSQL-Nutzer standardmäßig oft die Kleinschreibung, da kleingeschriebene Objektnamen den zu schreibenden Code reduzieren und gleichzeitig die Benutzerfreundlichkeit bei Ad-hoc-Abfragen durch Power-User verbessern. Dennoch ist es zwingend erforderlich, eine einheitliche Groß- und Kleinschreibung sowohl für Entitäts- als auch für Spaltennamen beizubehalten.
Figure 1: Naming Convention - Letter Case
Namenskonventionen: Verwendung von Unterstrichen „_“ und Bindestrichen „-“
Zur Verbesserung der Lesbarkeit sind Worttrenner wie Unterstriche „_“ oder, je nach Anwendungsfall, Bindestriche „-“ wünschenswert. Es ist jedoch wichtig zu bedenken, dass Bindestriche in vielen Systemen als Minuszeichen interpretiert werden. Dennoch werden Bindestriche häufig in XML- oder JSON-Datenformaten verwendet. Sie lassen sich jedoch leicht durch Unterstriche ersetzen, falls diese als Standard-Trennzeichen definiert sind.
Namenskonventionen: Abkürzungen und Akronyme
Einige Systeme erzwingen Zeichenbegrenzungen für Objektnamen. So erlauben beispielsweise Oracle 12.1 und ältere Versionen nur eine maximale Länge von 30 Bytes für Objektnamen. Daher bieten sich Abkürzungen und Akronyme bei der Objektbenennung an, auch wenn diese leicht zu Missverständnissen führen können. Um dem entgegenzuwirken, empfiehlt es sich, ein Dokument mit einer Liste aller verwendeten Abkürzungen und deren genauer Bedeutung zu erstellen. Um jedoch potenzielle Verwirrung zu vermeiden, sollten Sie den Einsatz von Abkürzungen und Akronymen auf ein Minimum beschränken.
In logischen Modellen sollten Objektnamen so selbsterklärend wie möglich sein. Das bedeutet, dass die meisten Wörter vollständig ausgeschrieben werden sollten – mit Ausnahme etablierter Abkürzungen wie „dept“ für „department“ oder „org“ für „organization“. In physischen Modellen hingegen werden typischerweise Abkürzungen und Akronyme genutzt, um die Objektnamen kurz zu halten.
Namenskonventionen: Singular- vs. Plural-Objektnamen
Es ist gängige Praxis, Substantive oder Nominalphrasen in ihrer Singularform als Objektnamen zu verwenden. So lässt sich vermeiden, dass man sich mit unregelmäßigen englischen Pluralformen (z. B. man/men, person/people) auseinandersetzen muss, was das Datenmodell unnötig verkomplizieren würde.
Namenskonventionen: Präfix vs. Suffix
Ob Objekte mit Präfixen oder Suffixen benannt werden, ist für die Entwicklung von untergeordneter Bedeutung. Dennoch bevorzugen wir intern bei Scalefree Tabellennamen mit Suffixen wie „customer_h“ und „transaction_l“ anstelle von Präfixen. Der Vorteil dieser Methode: Da die meisten Datenbank-Tools Tabellen alphabetisch sortieren, werden alle Tabellen, die sich auf dasselbe Geschäftsobjekt beziehen, automatisch gruppiert. Beispielsweise werden alle Hubs, Satelliten und Links für Kontakte, deren Namen mit „contact_…“ beginnen, im Datenbank-Browser direkt untereinander angezeigt. Dies erleichtert die Datenexploration für Power-User und Entwickler erheblich.
Figure 2: Naming Convention - Prefix
Dennoch können Präfixe in bestimmten Fällen sinnvoll sein. Beispielsweise hilft die Verwendung von Präfixen bei den Schema-Namen der verschiedenen Layer dabei, diese im Datenbank-Browser übersichtlich zu gruppieren.
Figure 3: Naming Convention - Schemas
Fazit
Namenskonventionen sind zu einem gewissen Grad eine Frage der persönlichen Vorliebe und der internen Richtlinien. Unabhängig davon gilt: Je systematischer und konsistenter die Namenskonventionen definiert sind, desto größer ist der Nutzen bei der Entwicklung und Implementierung Ihrer Data-Vault-Lösung. Um dies sicherzustellen, empfehlen wir Data-Vault-Entwicklungsteams, eine einfache SQL-Funktion zu implementieren, die die gesamte Datenbank automatisch auf Abweichungen von den Namenskonventionen überprüft. So wird die Einhaltung der Standards kontinuierlich gewährleistet.
Sind Sie daran interessiert, wie wir bei Scalefree Namenskonventionen standardisieren? In einem der nächsten Artikel werden wir konkrete Vorschläge für Namenskonventionen vorstellen, die sich sowohl bei unseren Kunden als auch in unserem eigenen Team in der Praxis bewährt haben.
Lassen Sie uns in den Kommentaren diskutieren: Wie setzen Sie Namenskonventionen in Ihrer Data-Vault-Entwicklung um? Welchen Standards folgen Sie?
