Eine erste Entscheidung von entscheidender Bedeutung bei der Entwicklung von Data Vault betrifft die Definition von Namenskonventionen für Datenbankobjekte. Als Teil der Entwicklungsstandardisierung sind diese Konventionen zwingend erforderlich, um ein gut strukturiertes und konsistentes Data Vault-Modell zu erhalten. Es ist wichtig zu erwähnen, dass angemessene Namenskonventionen die Nutzbarkeit des data warehouse nicht nur für Lösungsentwickler, sondern auch für Power-User im Rahmen der Datenexploration verbessern.
In diesem Artikel werden wir die wichtigsten Überlegungen im Rahmen unseres Standardwerks, dem Prozess der Festlegung von Namenskonventionen, vorstellen.
Dokumentation der Benennungskonvention
Es ist eine Sache, einfach nur Namenskonventionen zu definieren, die bei der Entwicklung Ihres data warehouse verwendet werden, aber es ist eine ganz andere Sache, Konsistenz herzustellen, um definierte Namenskonventionen zu schaffen, die zu Standards werden sollen. Dennoch ist es eine gute Praxis, eine Richtlinie für die Benennung von Data Warehouse-Objekten zu dokumentieren. Zu diesem Zweck werden in den nächsten Abschnitten mehrere Überlegungen erörtert, die bei der Festlegung der Namenskonventionen für eine data warehouse-Lösung zu berücksichtigen sind.
Briefkasten
Für die Großschreibung von Namen gibt es mehrere Möglichkeiten: Großbuchstaben, Kleinbuchstaben, Camel Case, Pascal Case. Auch wenn die Unterschiede gering sind, hat jede Option ihre eigenen Vor- und Nachteile in Bezug auf die Lesbarkeit und die Schreibbarkeit, um die Unterschiede kurz zu erläutern.
Letztendlich hängt die Entscheidung über die Groß- und Kleinschreibung davon ab, welches Datenbankmanagementsystem verwendet wird, da einige, wie z. B. PostgreSQL, die Groß- und Kleinschreibung von Objektnamen unterstützen, was die Verwendung von Namen in Anführungszeichen erfordert. Daher bevorzugen Benutzer oft die Kleinschreibung als Standard in PostgreSQL, da die Kleinschreibung von Objektnamen die Menge des zu generierenden Codes reduzieren kann und gleichzeitig die Benutzerfreundlichkeit für Ad-hoc-Abfragen durch Power-User verbessert. Nichtsdestotrotz ist es zwingend erforderlich, eine konsistente Groß- und Kleinschreibung sowohl für Entitäts- als auch für Spaltennamen beizubehalten.
Verwendung von Unterstrichen "_"Bindestriche "-"
Um die Lesbarkeit zu verbessern, sind Worttrenner wie Unterstriche "_" oder, je nach Anwendungsfall, Bindestriche "-" wünschenswert. Dabei ist jedoch zu beachten, dass Bindestriche in vielen Systemen als Minuszeichen interpretiert werden. Abgesehen davon werden Bindestriche häufig in XML- oder JSON-Datenformaten verwendet, obwohl sie leicht durch Unterstriche ersetzt werden können, wenn letztere als Trennzeichen verwendet werden.
Abkürzungen, Akronyme
Einige Systeme schreiben eine Zeichenbegrenzung für Objektnamen vor, z.B. erlaubt Oracle 12.1 und darunter nur eine maximale Länge des Objektnamens von 30 Bytes. Daher können Abkürzungen und Akronyme bei der Benennung von Objekten berücksichtigt werden, obwohl sie oft zu Fehlinterpretationen führen können. Um dem entgegenzuwirken, wird empfohlen, ein Dokument zu erstellen, das eine Liste der verwendeten Abkürzungen mit einer detaillierten Beschreibung ihrer Bedeutung enthält. Um eine mögliche Verwirrung zu vermeiden, sollte jedoch eine übermäßige Verwendung von Abkürzungen und Akronymen vermieden werden.
In logischen Modellen ist es ratsam, dass die Objektnamen so selbsterklärend wie möglich sind, d.h. die meisten Wörter sollten vollständig ausgeschrieben werden, mit Ausnahme gängiger Abkürzungen für längere Wörter wie "dept" für "Abteilung" oder "org" für "Organisation". In physikalischen Modellen werden jedoch in der Regel Abkürzungen und Akronyme verwendet, um die Objektnamen kurz zu halten.
Singular vs. Plural von Objektnamen
Es ist eine gängige Praxis, Substantive oder Substantivphrasen in ihrer Einzahl als Objektnamen zu verwenden. Auf diese Weise wird vermieden, dass man sich mit der unregelmäßigen Pluralisierung im Englischen befassen muss, z. B. man/men, person/people, was unnötigerweise eine ganz neue Ebene der Komplexität im Datenmodell schaffen würde.
Präfix vs. Suffix
Ob Objekte mit Präfixen oder Suffixen benannt werden, ist für die Entwicklung nicht von großer Bedeutung. Allerdings bevorzugen wir bei Scalefree intern Tabellennamen mit Suffixen wie "customer_h", "Transaktion_l", anstatt Präfixe zu verwenden. Der Vorteil dieser Methode besteht darin, dass die meisten Datenbanktools Tabellen alphabetisch sortieren, so dass alle Tabellen, die mit einem Geschäftsobjekt zusammenhängen, in einer Gruppe zusammengefasst werden. Zum Beispiel werden alle Kontaktknoten, Satelliten und Links, deren Namen mit "Kontakt_..." beginnen, im Browser zusammen gefunden. Dies unterstützt die Datenexploration durch Power-User und Entwickler.
Nichtsdestotrotz können Präfixe in einigen Anwendungsfällen sinnvoll sein, z. B. hilft die Verwendung von Präfixen in den Namen von Ebenenschemata dabei, diese im Datenbankbrowser übersichtlich zusammenzufassen.
Schlussfolgerung
Namenskonventionen sind zum Teil eine Frage der persönlichen Vorliebe und der organisatorischen Richtlinien. Je systematischer die Namenskonventionen bei ihrer Festlegung sind, desto mehr Vorteile ergeben sich letztendlich bei der Entwicklung und Implementierung Ihrer Data Vault-Lösung. Um diesen Punkt zu veranschaulichen, empfehlen wir Data Vault-Entwicklungsteams, eine einfache SQL-Funktion zu schreiben und zu implementieren, die die gesamte Datenbank auf Inkonsistenzen bei den Namenskonventionen überprüft. Dadurch wird sichergestellt, dass die Standards eingehalten werden.
Möchten Sie wissen, wie wir hier bei Scalefree die Namenskonventionen standardisieren? In einem kommenden Artikel werden wir mehrere konkrete Vorschläge für Namenskonventionen vorstellen, von denen die meisten sowohl von unseren Kunden als auch von unserem Team regelmäßig intern verwendet werden.
Lassen Sie uns nun im Kommentarfeld unten darüber diskutieren: Wie setzen Sie bei Ihrer Data Vault-Entwicklung Namenskonventionen um? Welche Konventionen befolgen Sie?
Updates und Support erhalten
Bitte senden Sie Anfragen und Funktionswünsche an [email protected].
Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.
Um die Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio zu unterstützen, wurde eine Schablone implementiert, die zum Zeichnen von Data Vault-Modellen verwendet werden kann. Die Schablone ist erhältlich bei www.visualdatavault.com.
Vielen Dank für Ihren Kommentar, Arne!
Mit freundlichen Grüßen,
Ihr Scalefree-Team
Bei ChipSoft verwenden wir ein ORM, um die Tabellen für unser data warehouse-Produkt zu generieren. Die Definition erfolgt in C#, so dass die Gehäuse den C#-Konventionen (=PascalCase) folgen.
Wir verwenden Datenbankschemata als Datenspeicher (als Sicherheitsgrenzen). Wir haben noch nicht genug davon, um einen Benennungsstandard vorzuschreiben.
Für die Tabellennamen in Data Vault bevorzugen wir ebenfalls die Postfixierung, und zwar mit demselben Gruppierungsargument, das Sie auch verwenden.
Das Format eines Hub-Tabellennamens wäre {module}{entity}Hub, z.B. ConfigUserHub, z.B. ConfigUserHub.
Die entsprechenden Satellitentabellen hätten Namen wie {Modul}{Einheit}{optionaler Unterbereich}Sat, z. B. ConfigUserSat oder ConfigUserPersonalDataSat.
Die Link-Tabellen würden Namen wie ConfigUserLink und ConfigUserOrganisationalLink tragen.
Auf diese Weise werden die Tabellen zunächst nach Modulen und dann nach Entitäten gruppiert, was wir für sehr praktisch halten.
Für Information Marts (dimensional modelliert) verwenden wir Präfixe, da Dimensionstabellen nicht unbedingt an eine einzelne Faktentabelle gebunden sind.
Das Format der Namen von Dimensionstabellen ist: Dim{optionaler Themenbereich}[Entität}.
Das Format der Namen von Faktentabellen ist: Fakt{Themenbereich}{Maßnahmengruppe}.
Für Faktentabellen (sowie Data Vault Brückentabellen) verwenden wir häufig Pluralformen. Alle anderen Tabellennamen werden im Singular geschrieben.
Vielen Dank für Ihren Kommentar, Arne!
Angenommen, Sie haben ein Quellsystem in englischer Sprache, aber Ihre Benutzer sprechen Deutsch. Außerdem sind die Spaltennamen aus dem Quellsystem stark abgekürzt, während Ihre Benutzer in ihren Berichten sprechende Spaltennamen benötigen. Was ist die bessere Strategie, um die Spalten im Raw Vault zu benennen? Einerseits könnten Sie den datengetriebenen Ansatz verfolgen und daher die Tabellen- und Spaltennamen aus dem Quellsystem verwenden. Dies hat den Vorteil, dass Sie schnell Ergebnisse liefern können. Auf der anderen Seite könnten Sie den geschäftsorientierten Ansatz verfolgen und deutsche und sprechende Spaltennamen in der Rohdatenbank verwenden. Der Vorteil wäre, dass Sie die gewünschten Daten schneller finden und die Spalten auf dem Weg zum Bericht nicht umbenennen müssen. Was ist Ihrer Erfahrung nach der bessere Ansatz?
Hallo Daniel,
Vielen Dank, dass Sie sich mit Ihrer Frage an uns wenden! Im Allgemeinen ist es eine gute Idee, die Übersetzungsarbeit weiter nachgelagert zu positionieren (d.h. Business Vault, vorzugsweise sogar Information Delivery), um den von Ihnen erwähnten Vorteil zu erreichen - die Ergebnisse schnell zu liefern. Wenn ein Attribut in der Quelle umbenannt wird, müssen Sie außerdem die Spaltenumbenennung nicht über Raw/Business Vault weitergeben.
Wenn Sie jedoch beispielsweise ein Quellsystem verarbeiten müssen, das in einer für Ihr Unternehmen völlig fremden Sprache verfasst ist, sollten Sie die Übersetzungsarbeit in einem früheren Stadium der Pipeline durchführen lassen, entweder im Raw Vault oder im Staging-Bereich. Auf diese Weise wird sichergestellt, dass die benötigten Daten in einem für alle Benutzer - sowohl für Entwickler als auch für Datenkonsumenten - verständlichen Zustand in Ihr data warehouse gelangen.
Herzlichen Dank,
Trung Ta