Namenskonventionen im Data Warehousing
In diesem Artikel werden wir weiterhin unsere Vorschläge für Namenskonventionen in einer Data-Warehouse-Lösung vorstellen und Beispiele für Namensstandards präsentieren, die sowohl unser Team als auch unsere Kunden intern anwenden. Sie finden hier auch unseren vorherigen Blogbeitrag, in dem wir die verschiedenen Aspekte einer Dokumentation zu Namensstandards erörtert haben – von der Groß- und Kleinschreibung bis hin zur Abwägung zwischen der Verwendung von Präfixen oder Suffixen in Datenbankobjektnamen.
Layer-Schemata
Für die Namen von Layer-Schemata bevorzugen wir die Verwendung von Präfixen.
Wie im vorherigen Blogbeitrag besprochen, erhöht diese Konvention für Entwickler und Business-Anwender die Übersichtlichkeit bei der Datenexploration im Enterprise Data Warehouse, indem Schemata desselben Data-Warehouse-Layers gruppiert werden.
Im Folgenden finden Sie eine Liste gängiger Enterprise-Data-Warehouse-Layer und unsere entsprechenden Empfehlungen für die Namenskonventionen:
Abbildung 1: Empfohlene Namenskonventionen für gängige Enterprise-Data-Warehouse-Layer
EDW/Data-Vault-Entitäten
Wie im vorherigen Abschnitt besprochen, teilen wir Raw Data Vault und Business Vault nicht auf verschiedene Datenbankschemata auf. Stattdessen können Benutzer eine Raw-Vault-Entität und eine berechnete Entität anhand des Entitätsnamens voneinander unterscheiden.
Im Folgenden finden Sie eine Liste von Namenskonventionen für Standard-Data-Vault-2.0-Entitäten sowie für fortgeschrittenere Entitätstypen.
**Hinweis: PIT– und Bridge-Tabellen sind nur im Business Vault verfügbar
Abbildung 2: Namenskonventionen für Standard-Data-Vault-Entitäten
Details zu den Namenskonventionen für Satellite-Entitäten
Kriterien für das Satellite-Splitting spielen eine entscheidende Rolle bei den Namenskonventionen für Satellite-Strukturen. Es wird nämlich nicht empfohlen, alle beschreibenden Daten eines Business-Objekts in einer einzigen Satellite-Struktur zu speichern – stattdessen sollten Rohdaten vorzugsweise nach bestimmten Kriterien aufgeteilt werden. (Linstedt, D., & Olschimke, M. (2016). Building a scalable Data Warehouse with Data Vault 2.0. S. 114–115)
Bei Scalefree haben wir drei Arten von Satellite-Splits definiert:
- Split nach Quellsystem
- Technischer Split nach Änderungsrate, Sicherheitsstufe und Datenschutzstufe
- Business-driven Split
Ein Satellite-Split nach Quellsystem und der technische Split nach der Änderungsrate der Daten sind gängige und empfohlene Praktiken bei der Aufteilung beschreibender Attribute. Wir haben uns jedoch entschieden, Rohdaten noch weiter aufzuteilen, sowohl technisch als auch nach geschäftlicher Bedeutung.
Daher lautet unsere vollständige Namenskonvention für Satellite-Entitäten wie folgt:
[parent-obj]_[biz-split]_[src]_[tech-split]_[satellite-type-suffix]
Dabei gilt:
[parent-obj] = der Name des Business-Objekts des übergeordneten Satelliten (Satellite Parent)
[biz-split] = die geschäftliche Klassifizierung
[src] = eine Abkürzung für das Quellsystem
[tech-split] = eine Kombination aus technischen Kriterien für das Satellite-Splitting
Bitte beachten Sie, dass der auf verschiedenen Sicherheitsstufen basierende Split die Daten in Sicherheitsgruppen klassifiziert. Auf diese Weise erhalten Endbenutzer nur Zugriff auf bestimmte Tabellengruppen, die ihrer Freigabestufe entsprechen.
In unserem Prozess reichen die Sicherheitsstufen von:
- der niedrigsten Vertraulichkeitsstufe (Stufe 0, 1): keine Sicherheitsmaßnahmen erforderlich, für öffentliche Daten
- über eingeschränkten Zugriff für bestimmte interne Parteien (Stufe A, R, C, F)
- bis zur höchsten Vertraulichkeitsstufe (Stufe S): streng geheim (Top Secret)
Wichtig ist auch, dass das letzte technische Kriterium für das Satellite-Splitting innerhalb der SOP von Scalefree durch den Split nach Datenschutzstufe (Privacy Level) bestimmt wird. Dieser Split ist ein notwendiger Bestandteil des Prozesses, da er personenbezogene und nicht-personenbezogene Informationen voneinander trennt.
Darüber hinaus verteilt der Business-driven Satellite-Split Rohdaten auf verschiedene Satellite-Tabellen, basierend auf der geschäftlichen Bedeutung des Dateninhalts.
Wir haben für diesen Zweck mehrere Klassifizierungen definiert, wie beispielsweise „contact“ für Kontaktdaten oder „activity“ für Daten zur Nachverfolgung von Benutzerinteraktionen mit dem Quelldatensatz.
Zudem können Datenmodellierer individuelle geschäftliche Klassifizierungen für spezifische Business-Objekte definieren.
Beispielsweise werden oft alle Datenattribute einer auf der CRM-Plattform Salesforce installierten Anwendung in einer einzigen Satellite-Struktur gespeichert. Der Business-driven Satellite-Split zielt somit darauf ab, die Benutzerfreundlichkeit und Zugänglichkeit des EDW für Endanwender zu verbessern. Dies erleichtert es den Anwendern, die benötigten Daten im DWH schneller zu finden, da die Daten in Gruppen mit klarer geschäftlicher Relevanz strukturiert sind.
Zusammenfassend zeigt das folgende Beispiel einen Satellite-Namen in unserer internen EDW-Lösung:
customer_contact_sfdc_lcp_s
Dies ist ein Satellite des Business-Objekts „Customer“ und enthält Kundenkontaktdaten aus dem Quellsystem Salesforce. Die Daten weisen eine niedrige Änderungsrate auf, unterliegen der Sicherheitsstufe C und enthalten personenbezogene Informationen.
Fazit
In diesem Artikel haben wir unsere Empfehlungen für Namenskonventionen für verschiedene Arten von Data-Warehouse-Objekten vorgestellt und einen tiefen Einblick in unsere Überlegungen zur Benennung von Satelliten gegeben.
Sind Sie an anderen Aspekten von Namensstandards interessiert? Lassen Sie es uns im Kommentarbereich wissen!
