Skip to main content
search
0
CartClose Cart
Category

Data Warehouse

In Anfänger, Data Warehouse, Künstliche Intelligenz

KI im Data Warehousing: Prinzipien und Anwendungen

KI im Data Warehousing

KI im Data Warehousing

Die Fähigkeit, Daten effizient zu speichern, zu verwalten und zu analysieren, ist für jedes Unternehmen zu einem kritischen Erfolgsfaktor geworden. Der Bereich des Data Warehousing ist ein integraler Bestandteil dieses Prozesses, da er eine strukturierte, zentralisierte Speicherung großer Datenmengen bietet und ein wichtiges Element der Business Intelligence darstellt. Die zunehmende Menge und Komplexität der Daten stellt das Management jedoch vor immer größere Herausforderungen. Dennoch prägt KI bereits viele Prozesse in den unterschiedlichsten Bereichen, einschließlich des Data Warehousing.

Dieser Artikel untersucht die grundlegenden Prinzipien und Anwendungen der Künstlichen Intelligenz und wie KI in ein Enterprise Data Warehouse integriert werden kann. Dabei wird beleuchtet, wie sie zur Verbesserung des Designs und des Betriebs von Data Warehouses eingesetzt werden kann und gleichzeitig die Entwicklung anspruchsvollerer Data-Science-Anwendungen wie Machine Learning oder Predictive Analytics ermöglicht.

KI im Data Warehousing: Prinzipien und Anwendungen

Dieses Webinar befasst sich mit den wesentlichen Prinzipien der Künstlichen Intelligenz (KI) und ihrer transformativen Rolle im Data Warehousing. Wir untersuchen, wie KI und Machine Learning (ML) nicht nur den Aufbau und den Betrieb von Data Warehouses verbessern, sondern auch die darin gespeicherten riesigen Datenmengen nutzen, um leistungsstarke Anwendungen zu entwickeln, z. B. für Predictive Analytics.

Sie lernen die grundlegenden KI-Technologien kennen, die diese Fortschritte vorantreiben, und erfahren, wie sie sich mit Data Science und Machine Learning überschneiden, um die Datenspeicherung zu optimieren, die Entscheidungsfindung zu verbessern und neue geschäftliche Erkenntnisse zu gewinnen. Dieses Webinar bietet wertvolle Perspektiven für die Integration dieser Technologien in Ihre Data-Warehousing-Methoden.

Watch webinar recording

In this article:

Grundlegende Prinzipien der KI

Lassen Sie uns zunächst den Begriff der Künstlichen Intelligenz sowie andere Begriffe wie Machine Learning, Deep Learning oder Generative KI einordnen, um den Kontext zu verdeutlichen und zu klären, was sich genau hinter diesen Begriffen verbirgt.

Künstliche Intelligenz ist heute eher ein Oberbegriff und repräsentiert ein breites Feld. Im Allgemeinen umfasst der Begriff KI Techniken, die es Computern ermöglichen, menschliches Verhalten nachzuahmen, sodass sie lernen, Sprache zu verstehen, Entscheidungen zu treffen, Muster zu erkennen und komplexe Probleme auf eine Weise zu lösen, die der menschlichen Intelligenz ähnelt.

AI Graphic

Machine Learning (ML) als Teilbereich der KI

Machine Learning ist ein Teilbereich der Künstlichen Intelligenz und, auch wenn der Begriff weniger präsent sein mag, einer der wichtigsten. Machine Learning nutzt fortschrittliche Techniken und Algorithmen, um Muster in großen Datenmengen zu erkennen. Dies ermöglicht es Maschinen, autonom zu lernen und sich anzupassen, um auf Basis der Daten Rückschlüsse oder Vorhersagen zu treffen. Im Gegensatz zur traditionellen Programmierung, bei der Aufgaben auf der Grundlage klarer und definierter Anweisungen ausgeführt werden, stützt sich Machine Learning auf statistische Analysen von Eingabedaten, um Ergebnisse innerhalb eines erwarteten Bereichs auszugeben. Im Wesentlichen ermöglicht es Machine Learning Computern, aus Daten zu lernen und diese zu interpretieren, ohne für jeden einzelnen Fall explizit programmiert zu werden.

Deep Learning (DL) – Ein tieferer Einblick in ML

Deep Learning ist ein spezialisierter Teilbereich des Machine Learning und der KI und nutzt tiefe neuronale Netze, um tiefgehende Datenverarbeitungsaufgaben zur Erkennung komplexer Muster durchzuführen.

Deep Learning nutzt viele Schichten, um komplexe Merkmale aus Rohdaten als Eingabe zu extrahieren, was in gewisser Weise die Funktionsweise des menschlichen Gehirns simuliert.

In dieser Hinsicht ist Deep Learning besonders leistungsfähig bei der Verarbeitung sehr großer Datenmengen, um komplexe Muster zu erlernen und so die unterschiedlichsten Aufgaben zu lösen. Bekannte Beispiele hierfür sind Aufgaben wie die Bild- oder Spracherkennung, die heute jedes moderne Smartphone beherrscht.

Generative KI – Der kreative Aspekt des Deep Learning

Generative KI ist ein Begriff, der in letzter Zeit vor allem durch ChatGPT sehr bekannt geworden ist. Generative KI ist ein Teilbereich des Deep Learning und umfasst Deep-Learning-Modelle, die neue Inhalte wie Texte, Bilder, Code oder sogar Videos auf Basis der Daten generieren, mit denen sie trainiert wurden. Sie sind in der Lage, ohne explizite Anweisungen neuartige Ergebnisse zu erzeugen, die die Trainingsdaten nicht direkt replizieren. Dies eröffnet völlig neue Möglichkeiten, wie beispielsweise die Erstellung langer Texte, komplexer Bilder oder sogar Musik.

Die Rolle der KI beim Aufbau von Data Warehouses

KI verändert alles, auch das Data Warehousing. Dabei kann sie dazu beitragen, die Effizienz und Effektivität Ihres Data Warehouses von Grund auf zu steigern. Vom Design und der Struktur bis hin zu den laufenden Datenmanagementprozessen gibt es viele Möglichkeiten, bei denen KI helfen kann.

KI hat das Potenzial, die größten Herausforderungen eines Data Warehouses zu bewältigen: Performance, Governance und Benutzerfreundlichkeit. Dies ist gelebte Data Intelligence, die die Art und Weise, wie Sie Ihre Daten abfragen, verwalten, steuern und visualisieren, revolutionieren wird.

Verbesserung von Design und Struktur

Die Architektur eines Data Warehouses ist von entscheidender Bedeutung, da sie eine effiziente Datenabfrage und Skalierbarkeit bei gleichbleibender Performance unterstützen muss. Durch die Analyse von Nutzungs- und Abfragemustern können KI-Algorithmen optimale Datenmodelle und Indizierungsstrategien vorschlagen. Dies beschleunigt nicht nur den Abruf von Informationen, sondern sorgt auch für eine agilere Datenhandhabung bei der Skalierung oder der Integration neuer Datenquellen.

Automatisierung von Datenintegration, -bereinigung und -transformation

Indem KI Routineaufgaben übernimmt, können sich Data Engineers auf anspruchsvollere Aufgaben wie den Entwurf von Datenmodellen, das Trainieren von Machine-Learning-Algorithmen und die Erstellung von Datenvisualisierungen konzentrieren. Beispielsweise nutzt The Coca-Cola Company KI-gestützte ETL-Tools, um Datenintegrationsaufgaben in ihrer gesamten globalen Lieferkette zu automatisieren und so die Beschaffungs- und Einkaufsprozesse zu optimieren.

Darüber hinaus kann KI auch die Entwickler selbst bei ihrer Arbeit unterstützen, sodass sie schneller und effizienter arbeiten können. Entwickler können KI nutzen, um Probleme in ihrem Code schneller zu beheben, indem sie auf KI-basierte Codegenerierung und -analyse wie GitHub Copilot zurückgreifen. Dieser vervollständigt, refaktoriert und debuggt Code in Echtzeit direkt in der IDE.

Auch das Performance-Tuning von Data-Warehouse-Workloads lässt sich durch prädiktive Optimierungen automatisieren, was erhebliche Kosten einsparen kann.

KI kann auch die Governance skalieren und automatisieren, indem sie automatisiertes Tagging, eine lückenlose Dokumentation und die Suche in natürlicher Sprache über alle Daten und Assets eines Unternehmens hinweg ermöglicht.

Dies reicht bis hin zu der Möglichkeit für Business-Anwender, natürliche Sprache zu nutzen, um mit Daten zu interagieren, Fragen zu stellen und Dashboards zu erstellen. Die Möglichkeiten sind nahezu unbegrenzt, und wir stehen erst am Anfang dieser Entwicklung.

Nutzung eines Data Warehouse für KI-Anwendungen

Die Struktur eines Data Warehouses – ein strukturiertes und zentralisiertes Repository, das Daten aus mehreren Quellen innerhalb eines Unternehmens aggregiert – macht es zur perfekten Grundlage für den Aufbau und das Trainieren von KI-Anwendungen. KI-Modelle benötigen große Mengen gut strukturierter und variabler Daten von hoher Qualität. Ein Data Warehouse bietet hierfür die perfekte Basis, um unternehmenseigene KI-Modelle zu trainieren.

Beispielsweise könnte ein Data Warehouse im Einzelhandel die jahrelange Historie von Käufen, demografischen Daten und Produktinformationen speichern. Diese Daten können genutzt werden, um KI-Modelle zu trainieren, die zukünftige Einkaufstrends vorhersagen oder personalisierte Produktempfehlungen aussprechen.

Verbesserung der KI-Fähigkeiten mit Data Vault

Insbesondere Data Vault 2.0 schafft die optimalen Voraussetzungen für das Trainieren eigener KI-Modelle durch sein strukturiertes und zuverlässiges Daten-Framework.

Hier sind einige Beispiele, wie diese Integration KI-gestützten Analysen zugutekommen kann:

  • Verbesserte Datenqualität: Die organisierte und auditierbare Struktur von Data Vault 2.0 sorgt für eine höhere Datenqualität und -konsistenz, was für das Trainieren präziser KI-Modelle unerlässlich ist. Saubere, gut strukturierte Datenmodelle verkürzen den Zeitaufwand für die Datenaufbereitung und erhöhen die Zuverlässigkeit von KI-Vorhersagen.
  • Verbesserte historische Analyse: Die umfassenden historischen Daten, die von Data Vault 2.0 erfasst werden, ermöglichen es KI-Modellen, präzisere Trendanalysen und Prognosen durchzuführen. Diese Fähigkeit ist besonders in Branchen wie dem Finanzwesen und dem Einzelhandel wertvoll, da die Analyse langfristiger Trends strategische Entscheidungen erheblich beeinflussen kann.
  • Datenzuverlässigkeit und Lineage: Das robuste Framework von Data Vault 2.0 gewährleistet die Datenzuverlässigkeit durch seine einzigartige Architektur, die Daten aus verschiedenen Quellen erfasst und gleichzeitig deren Lineage beibehält. Dies bedeutet, dass jeder Datenpunkt im System bis zu seinem Ursprung zurückverfolgt werden kann, was Transparenz schafft und das Vertrauen in die für KI-Modelle genutzten Daten stärkt.

Fazit

Die Integration von Künstlicher Intelligenz (KI) in das Data Warehousing steigert die Effizienz und Effektivität der Datenspeicherung, -verwaltung und -analyse erheblich. Durch den Einsatz von KI-Technologien können Unternehmen Prozesse zur Datenintegration, -bereinigung und -transformation automatisieren, was zu präziseren und schnelleren Erkenntnissen führt. Darüber hinaus sorgt die KI-gestützte Optimierung von Design und Struktur des Data Warehouses für eine verbesserte Performance und Skalierbarkeit. Der Einsatz von KI im Data Warehousing rationalisiert nicht nur die Abläufe, sondern ermöglicht es Unternehmen auch, fortschrittliche Analysen wie Machine Learning und Predictive Analytics zu nutzen, um tiefere Erkenntnisse zu gewinnen und fundierte Entscheidungen zu treffen.

In Data Warehouse, Fortgeschrittene

Data Vault im Data-Mesh-Ansatz

Solutions

Data Vault & Data Mesh

Tauchen Sie ein in die Integration von Data Vault im Kontext von Data Mesh. Beginnen Sie die Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen mit unserem Data Vault 2.Go-Newsletter – Ihrer zentralen Anlaufstelle für (fast) alles rund um die zukunftsweisende Welt der Daten.

In dieser Ausgabe befassen wir uns eingehend mit der Integration von Data Vault 2.0 im Kontext eines Data-Mesh-Ansatzes. Begleiten Sie uns auf dieser Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen.

Data Vault im Data-Mesh-Ansatz

Dieses Webinar untersucht die Integration von Data Vault in einen Data-Mesh-Ansatz und beleuchtet die Synergie zwischen den Data-Mesh-Prinzipien und der Skalierbarkeit, Flexibilität, Resilienz sowie Interoperabilität von Data Vault. Wir betrachten die Integration von Data Vault im Kontext eines Data-Mesh-Ansatzes im Detail – eine Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen.

Watch webinar recording

In this article:

Data Mesh verstehen: Eine kurze Zusammenfassung

Bevor wir uns mit der Rolle von Data Vault befassen, lassen Sie uns kurz rekapitulieren, was ein Data Mesh ist. Der von Zhamak Dehghani geprägte Begriff Data Mesh beschreibt ein Architekturparadigma, das darauf abzielt, die Herausforderungen bei der Skalierung von Daten in großen Unternehmen zu bewältigen. Es fördert einen dezentralen Ansatz für das Dateneigentum (Data Ownership) und den Datenzugriff, indem es Daten als Produkt behandelt und eine domänenorientierte Self-Service-Dateninfrastruktur etabliert.

Data Vault im Mesh: Eine synergetische Allianz

Lassen Sie uns nun über Data Vault sprechen. Data Vault ist seit Langem als robuste Methodik für den Aufbau von Enterprise Data Warehouses anerkannt und hat seinen Wert bei der Erstellung skalierbarer, flexibler und resilienter Datenarchitekturen unter Beweis gestellt. Seine Integration in einen Data-Mesh-Ansatz fügt jedoch eine neue Ebene der Agilität und Effizienz hinzu.

Skalierbarkeit

Data Mesh betont die Notwendigkeit eines dezentralen Dateneigentums, was eine horizontale Skalierung der Dateninfrastruktur entscheidend macht. Data Vault fügt sich mit seiner modularen und skalierbaren Architektur nahtlos in diese Anforderung ein. Durch die Aufteilung des Data Warehouses in kleinere, überschaubare Komponenten stellt Data Vault sicher, dass das System mühelos mit steigendem Datenvolumen und zunehmender Komplexität skalieren kann.

Flexibilität

In einem Data Mesh ist jede Domäne oder Geschäftseinheit für ihre eigenen Datenprodukte verantwortlich. Hier glänzt die Anpassungsfähigkeit von Data Vault, da verschiedene Teams ihre Daten unabhängig voneinander modellieren und verwalten können. Diese Flexibilität ermöglicht schnellere Entwicklungszyklen, reduziert die Abhängigkeiten von einem zentralen Datenteam und befähigt die Domänenteams, in ihrem eigenen Tempo Innovationen voranzutreiben und zu iterieren.

Resilienz

Data Mesh führt das Konzept von Datenprodukten und -services ein und betont die Notwendigkeit von Resilienz in Datenarchitekturen. Data Vault spielt mit seinem Fokus auf die Erfassung und Verwaltung historischer Datenänderungen eine entscheidende Rolle bei der Gewährleistung der Zuverlässigkeit und Integrität von Datenprodukten. Diese historische Datenhaltung erweist sich als unschätzbar wertvoll für Audits, Compliance und das Verständnis der Datenentwicklung im Laufe der Zeit.

Interoperabilität

Ein Data Mesh befürwortet eine föderierte Datenarchitektur, in der Datenprodukte nahtlos miteinander interagieren können. Die standardisierten Modellierungstechniken und klar definierten Schnittstellen von Data Vault erleichtern es verschiedenen Domänen, zusammenzuarbeiten und Daten auszutauschen, während gleichzeitig Konsistenz und Kohärenz im gesamten Ökosystem gewahrt bleiben.

Data Mesh & Data Vault

Fazit

Die Verbindung von Data Vault und Data Mesh stellt einen großen Fortschritt in der Evolution von Datenarchitekturen dar. Sie kombiniert die bewährte Zuverlässigkeit von Data Vault mit der Agilität und Skalierbarkeit eines dezentralen Data Mesh und bietet Unternehmen eine leistungsstarke Lösung für die Verwaltung ihrer stetig wachsenden und vielfältigen Datenlandschaft.

Obwohl die Integration von Data Vault in einen Data-Mesh-Ansatz zahlreiche Vorteile mit sich bringt, ist es wichtig, auch potenzielle Herausforderungen zu berücksichtigen. Die Steuerung des dezentralen Dateneigentums, die Gewährleistung einheitlicher Standards über Domänen hinweg und die Bereitstellung einer angemessenen Governance sind entscheidende Aspekte, die sorgfältig bedacht werden müssen.

Sehen Sie sich unbedingt die Webinar-Aufzeichnung zu „Data Mesh in einem Data-Vault-2.0-Ansatz“ an, um noch tiefer in das Thema einzusteigen.

In Anfänger, Data Warehouse

Sicherstellung der Datenqualität in Ihrem Data Warehouse

Data quality in a data warehouse

Sicherstellung der Datenqualität

Mangelhafte Datenqualität kann zu ungenauen Erkenntnissen, fehlerhaften Entscheidungen und letztendlich zu Beeinträchtigungen des Geschäftserfolgs führen. Im Zeitalter von Big Data verlassen sich Unternehmen stark auf Data Warehouses, um riesige Informationsmengen zu speichern, zu verwalten und zu analysieren. Die Effektivität eines Data Warehouse hängt jedoch von der Qualität der darin enthaltenen Daten ab. Wie lässt sich eine hohe Datenqualität sicherstellen?

In diesem Blogartikel gehen wir auf die Bedeutung der Datenqualität in einem Enterprise Data Warehouse ein und liefern Ihnen praktische Strategien, um präzise, zuverlässige und qualitativ hochwertige Daten mit Data Vault 2.0 zu gewährleisten.

Vielleicht möchten Sie sich auch die Webinar-Aufzeichnung genau zu diesem Thema ansehen. Sehen Sie sie sich hier kostenlos an!

Sicherstellung der Datenqualität in Ihrem Data Warehouse

In der heutigen datengetriebenen Kultur verlassen sich Unternehmen stark auf ihre Data Warehouses, um fundierte Entscheidungen zu treffen. Die Effektivität eines Data Warehouse hängt jedoch von der Qualität der darin enthaltenen Daten ab. In diesem Artikel gehen wir auf die Bedeutung der Datenqualität ein und stellen praktische Strategien vor, um mit Data Vault 2.0 genaue, zuverlässige und hochwertige Daten zu gewährleisten.

Watch webinar recording

In this article:

Was sind die Ursachen für schlechte Daten?

Datenqualität bezieht sich auf die Genauigkeit, Vollständigkeit, Konsistenz und Zuverlässigkeit von Daten. Im Kontext eines Data Warehouse ist die Aufrechterhaltung einer hohen Datenqualität entscheidend, um aussagekräftige Erkenntnisse zu gewinnen und fundierte Entscheidungen zu treffen. Verschiedene Faktoren tragen zum Vorhandensein von schlechten oder fehlerhaften Daten bei. Das Erkennen und Verstehen dieser Ursachen ist essenziell für die Implementierung effektiver Strategien zum Datenqualitätsmanagement. Hier sind einige häufige Gründe für schlechte Daten in einem Data Warehouse:

  • Unvollständige oder fehlende Quelldaten
  • Fehlende Standardisierung
  • Probleme bei der Datentransformation
  • Mangelhafte Data Governance
  • Unzureichende Validierung und Qualitätsprüfungen
  • Fehlende Anwenderschulung und mangelndes Bewusstsein

Techniken zur Sicherstellung der Datenqualität

Es gibt eine Vielzahl von Datenqualitätstechniken, und es gibt keine universelle Ideallösung für alle Probleme. Die Schwierigkeit besteht darin, die aktuelle Situation sowie die Stärken und Schwächen der verfügbaren Techniken zu verstehen. Tatsächlich variiert die Effektivität der Techniken je nach Kontext. Eine bestimmte Technik passt in manchen Situationen gut, in anderen weniger. Scott Ambler hat fünf Vergleichsfaktoren entwickelt, mit denen sich die Effektivität einer Datenqualitätstechnik beurteilen lässt. Diese nachfolgend gezeigten Faktoren sollen Ihnen helfen, die passende DQ-Technik für Ihre jeweilige Situation auszuwählen:

Data Quality graphic technique comparison for a data warehouse

Quelle: https://agiledata.org/essays/dataqualitytechniquecomparison.html

  • Rechtzeitigkeit (Timeliness): Reagieren Sie auf ein entdecktes DQ-Problem oder wenden Sie die Technik an, um DQ-Probleme proaktiv zu vermeiden oder zu reduzieren?
  • Automatisierungsgrad (Level of automation): Inwieweit ist eine Automatisierung möglich? Eine kontinuierliche Technik würde je nach Bedarf automatisch aufgerufen werden.
  • Auswirkung auf die Quelle (Effect on source): Hat die Technik Auswirkungen auf die eigentliche Datenquelle?
  • Nutzenrealisierung (Benefit realization): Tritt der Nutzen der Qualitätsverbesserung sofort ein oder ist ein langfristiger Nutzen zu erwarten?
  • Erforderliche Fähigkeiten (Required skills): Erfordert die Technik anspruchsvolle Fähigkeiten, die erst durch Schulung/Erfahrung erworben werden müssen, oder ist die Technik leicht zu erlernen?

Der Nutzen des Data-Vault-2.0-Ansatzes

Wenn schlechte Daten erkannt werden, besteht der erste Schritt in einer Ursachenanalyse. Was aber, wenn die schlechten Daten aus dem Quellsystem stammen? Der beste Ansatz wäre, die Fehler direkt im Quellsystem zu beheben. Diese Methode wird jedoch häufig abgelehnt, da sie als zu kostspielig gilt. Da die Quellsysteme nicht im Verantwortungsbereich des Data-Warehouse-Teams liegen, müssen wir einen Weg finden, die fehlerhaften Daten an einer anderen Stelle in unserer Architektur zu bereinigen. In Data Vault 2.0 betrachten wir eine Datenbereinigungsroutine als Business Rule (Soft Rule), wobei diese Regeln im Business Vault implementiert werden.

In der gezeigten Architektur (Abbildung 1) ist ein Quality Layer in den Business Vault integriert, in dem die Datenbereinigungsroutinen ausgeführt werden. Ziel ist es, die bereinigten Daten für nachgelagerte Business-Vault- und Information-Mart-Objekte in hohem Maße wiederverwendbar zu machen. Wenn sich die Datenqualitätsregeln ändern oder neue Erkenntnisse über die Daten gewonnen werden, können die Regeln angepasst werden, ohne dass bisherige Rohdaten neu geladen werden müssen.

Nun stehen die Daten für die Verwendung in jedem Dashboarding- oder Reporting-Tool bereit. Es ist auch möglich, die bereinigten Daten in die Quelle zurückzuschreiben. Zu diesem Zweck werden die Daten einem Interface Mart bereitgestellt, der wiederum die Daten an das Quellsystem selbst zurücksendet. Auf diese Weise können Fachanwender die qualitativ hochwertigen Daten auch in ihren Quellanwendungen nutzen. Beim nächsten Laden der Rohdaten in den Raw Data Vault sind die Daten somit bereits bereinigt.

Data quality in a data warehouse

Der zweite in Abbildung 1 beschriebene Anwendungsfall ist das Monitoring von schlechten Daten durch einen sogenannten Quality Mart. Der Quality Mart ist Teil des Information Delivery Layer und wählt alle fehlerhaften Daten anstelle der bereinigten Daten aus. Darauf aufbauend können Berichte oder grafische Benutzeroberflächen für den Data Steward erstellt werden. Darüber hinaus kann der Data Steward Kommentare zu bestimmten Datensätzen hinterlassen, die nicht als schlechte Daten eingestuft werden sollten oder Ausnahmen von den Regeln darstellen. Diese Benutzeroberfläche speichert alle hinzugefügten Daten (Kommentare, Flags etc.) in einer Datenbank, die wiederum als Quelle für den Data Vault dient. Diese Daten können genutzt werden, um die Business Rules zu erweitern – insbesondere, um Ausnahmen von den Datenbereinigungsregeln herauszufiltern.

Ein weiterer Vorteil von Data Vault 2.0 sind die stark musterbasierten und standardisierten Entitäten. Dies ermöglicht eine einfache und automatisierte Entwicklung technischer Tests. Einmal für jede Data-Vault-Entität erstellt, können diese Tests sowohl auf die Raw-Data-Vault-Entitäten als auch auf die Business-Vault-Entitäten angewendet werden. Dies stellt ein konsistentes und auditierbares Data Warehouse sicher. Lesen Sie diesen Blogartikel, wenn Sie detailliertere Informationen zu technischen Tests in Data Vault benötigen.

Gängige Datenqualitätstechniken

Im letzten Abschnitt haben wir bereits einige Techniken zur Sicherstellung einer hohen Datenqualität in einer Data-Vault-2.0-Architektur beschrieben. Selbstverständlich gibt es eine Reihe weiterer Techniken, die unabhängig davon sind, welcher Modellierungsansatz verwendet wird. Darüber hinaus konzentrieren sich einige Techniken nicht in erster Linie auf die Datenqualität, haben aber dennoch einen positiven Einfluss darauf. Schauen wir uns einige davon im Folgenden genauer an:

  • Validierung von Business Rules: An dieser Stelle müssen wir zwischen Datenqualität und Informationsqualität unterscheiden. Datenqualität konzentriert sich auf die intrinsischen Eigenschaften der Daten und adressiert Probleme wie Fehler, Inkonsistenzen und Unvollständigkeit auf granularer Ebene. Informationsqualität ist ein breiteres Konzept, das nicht nur die Qualität einzelner Datenelemente umfasst, sondern auch den Gesamtwert und den Nutzen der aus diesen Daten abgeleiteten Informationen. Darüber hinaus kann das, was für den einen Anwendungsfall nützliche Informationen sind, für einen anderen unzureichend sein. Aus diesem Grund müssen die Fachanwender stark in diesen Prozess eingebunden werden, beispielsweise durch User Acceptance Tests.

  • Data Governance umfasst die Definition von Rollen, Verantwortlichkeiten und Rechenschaftspflichten für die Datenqualität, um sicherzustellen, dass Daten als wertvolles Unternehmensgut behandelt werden. Entwickeln Sie Data-Governance-Frameworks einschließlich Datenqualitätsstandards, Data-Stewardship-Verantwortlichkeiten sowie Dokumentationen und setzen Sie diese konsequent um.

  • Data Guidance und Standardisierung stellen die Einheitlichkeit von Formaten, Einheiten und Werten über das gesamte Data Warehouse hinweg sicher und reduzieren so das Risiko von Fehlern, die durch unterschiedliche Darstellungen verursacht werden. Etablieren Sie standardisierte Benennungskonventionen, Maßeinheiten, Formatierungsregeln sowie Konventionen für Datensicherheit und Datenschutz und setzen Sie diese konsequent um. Data Vault 2.0 ist in dieser Hinsicht sehr hilfreich, da alle Entitäten stark standardisiert und automatisierbar sind.

  • Data Steward: Als Teil der Data-Governance-Praxis ist ein Data Steward eine Überwachungs- und Governance-Rolle innerhalb einer Organisation, die für die Sicherstellung der Qualität und der Zweckmäßigkeit der Unternehmensdaten verantwortlich ist.

  • Continuous Integration (CI) ist eine Entwicklungspraxis, bei der Entwickler ihre Arbeit häufig integrieren. Erfolgreiche Tests sollten eine zwingende Voraussetzung für die Einführung neuer Änderungen in Ihre EDW-Codebasis sein. Dies lässt sich durch den Einsatz von DevOps-Tools und die Aktivierung von Continuous Integration in Ihrem Entwicklungslebenszyklus erreichen.
    Die Ausführung automatisierter Tests bei jedem Code-Check-in oder -Merge stellt sicher, dass Konsistenzprobleme oder Bugs frühzeitig erkannt und vor dem Go-Live behoben werden.

  • Ein Review ist eine Peer-Review der Implementierung (Quellcode, Datenmodelle etc.). Die Entwicklung eines starken Review-Prozesses schafft die Grundlage für eine kontinuierliche Verbesserung und sollte Teil des Workflows eines Entwicklungsteams werden, um die Qualität zu steigern und sicherzustellen, dass jeder Codeabschnitt von einem anderen Teammitglied geprüft wurde.

  • Anwenderschulung und Bewusstseinsbildung: Schulen Sie Anwender in der Bedeutung der Datenqualität und bieten Sie Trainings zu den notwendigen Themen und Fähigkeiten an. Fördern Sie eine Kultur des Datenqualitätsbewusstseins innerhalb der Organisation, um die proaktive Identifikation und Behebung von Datenqualitätsproblemen zu unterstützen.

Fazit

Es steht außer Frage, dass eine hohe Datenqualität für ein erfolgreiches Data-Warehousing-Projekt unerlässlich ist. Der Weg zu hoher Datenqualität ist keine einmalige Anstrengung, sondern eine kontinuierliche Verpflichtung. Es handelt sich um einen vielschichtigen Prozess, der eine Kombination von Techniken, teamübergreifende Zusammenarbeit und die Förderung einer Kultur der Data Stewardship umfasst.

In diesem Artikel sind wir auf die Ursachen für schlechte Daten eingegangen und haben verschiedene Techniken für den Umgang mit diesen Problemen diskutiert. Genauer gesagt haben wir beschrieben, wie Datenqualitätstechniken innerhalb einer Data-Vault-2.0-Architektur implementiert werden können.

Wenn Sie tiefer in das Thema Datenqualität eintauchen möchten, denken Sie daran, sich die kostenlose Webinar-Aufzeichnung anzusehen.

In Data Warehouse, Fortgeschrittene

Technische Tests eines Data Vault-gestützten EDW

Data Vault-gestütztes EDW

In diesem Newsletter stellen wir Ihnen verschiedene Methoden und Ansätze zur Durchführung technischer Tests eines Data Vault-gestützten EDW vor und geben Ihnen einen Überblick darüber.

Die unten beschriebenen Testansätze zielen darauf ab, die Integrität, Zuverlässigkeit, Genauigkeit, Konsistenz und Revisionssicherheit (Auditability) der in Ihre Data-Vault-Entitäten geladenen Daten sowie der darauf aufbauenden Information-Marts sicherzustellen. Dies stellt sicher, dass Ihr Unternehmen auf der Grundlage dieser Daten fundierte Entscheidungen treffen kann.

Technische Tests und Monitoring eines Data Vault-gestützten EDW

In diesem Webinar geben Ihnen unsere Experten einen Überblick über verschiedene Methoden und Ansätze für technische Tests und das Monitoring eines Data Vault-gestützten EDW. Die vorgestellten Testansätze eignen sich für verschiedene Schichten (Layers) Ihrer EDW-Lösung – von der Extraktion der Daten aus den Quellen in die Landing Zone/Staging Area (Extract and Load) bis hin zu den Information-Marts, die von den Endanwendern in ihren BI-Berichten genutzt werden. Der Hauptfokus unseres Webinars liegt jedoch auf dem Testen der Data-Vault-2.0-Entitäten in den Raw-Vault- und Business-Vault-Schichten. Das Monitoring konzentriert sich darauf, Einblicke in die Performance Ihres EDW zu geben. Ausgehend vom Modellierungsansatz des Metrics-Vault und der Metrics-Marts werden die Quelldatenbereiche dieser Entitäten abgedeckt. Diese erfassten Daten liefern Informationen über die Prozessausführung Ihrer ELT-Prozesse sowie Fehlerinformationen. Durch die Analyse der Error-Marts können Sie Fehler nachverfolgen, deren Ursachen ermitteln und die Performance durch die Berücksichtigung von Performance-Metriken steigern.

Watch Webinar Part 1Watch Webinar Part 2

In this article:

Was Sie erwartet

Sie erhalten einen Überblick über Testansätze, die für verschiedene Schichten Ihrer EDW-Lösung geeignet sind – angefangen bei der Extraktion von Daten aus Quellen in die Landing Zone/Staging Area (Extract and Load) bis hin zu Information-Marts, die von Endanwendern in ihren BI-Berichten verwendet werden. Darüber hinaus thematisieren wir die Testautomatisierung und ihre Bedeutung für die Continuous Integration Ihres Data-Vault-basierten EDW. Der Hauptfokus dieses Newsletters liegt jedoch auf dem Testen der Data-Vault-Entitäten in den Raw-Vault- und Business-Vault-Schichten.

Testen des Datenextraktionsprozesses

Unabhängig davon, wo die Datenextraktion stattfindet – Datenquelle, Persistent Staging oder Transient Staging – besteht das Hauptziel der Tests in dieser Phase darin, nachzuweisen, dass beim Transport oder Staging der Daten kein Datenverlust (Data Leakage) auftritt. Der Vergleich der Eingangsdaten mit den Zieldaten stellt sicher, dass die Daten nicht versehentlich oder unbefugt aufgrund von Problemen im Extraktionsprozess gelöscht, hinzugefügt oder geändert wurden. Prüfsummen (Checksums), Hash-Summen (Hash Totals) und die Anzahl der Datensätze (Record Counts) sollten verwendet werden, um sicherzustellen, dass die Daten unverändert geblieben sind:

  • Stellen Sie sicher, dass die Prüfsummen (Checksums) zwischen dem Quelldatensatz und der Ziel-Staging-Tabelle übereinstimmen.
  • Stellen Sie sicher, dass die numerische Summe eines oder mehrerer Felder in einem Quelldatensatz (auch bekannt als Hash Total) mit der Summe der entsprechenden Spalten in der Zieltabelle übereinstimmt. Eine solche Summe kann Daten enthalten, die normalerweise nicht für Berechnungen verwendet werden (z. B. numerische ID-Werte, Kontonummern usw.).
  • Stellen Sie sicher, dass die Zeilenanzahl (Row Count) zwischen der Quelle und der Ziel-Staging-Tabelle übereinstimmt.

Testen von Data Vault

Das Herzstück Ihrer Data-Vault-gestützten EDW-Lösung ist der Raw Data Vault. Dieser enthält rohe und ungefilterte Daten aus Ihren Quellsystemen, die aufgeteilt und basierend auf Business-Keys in Hubs, Links, Satelliten und andere Data-Vault-spezifische Entitäten geladen werden. Dies ist der erste Punkt in der Datenpipeline, an dem die Daten in den gemäß Data Vault modellierten Entitäten landen. Daher sind spezifische Tests erforderlich, um die Konsistenz und Revisionssicherheit der Daten nach dem Befüllen des Raw Data Vault sicherzustellen. Die folgenden Testansätze gelten gleichermaßen für Business-Vault-Entitäten.

Testen von Hubs

Hubs speichern Business-Keys, indem sie diese vom Rest des Modells trennen. Für jedes Geschäftsobjekt (Business Object) wird ein Hub erstellt. Er enthält eine eindeutige Liste von Schlüsseln, die ein Geschäftsobjekt repräsentieren und dieselbe semantische Bedeutung sowie Granularität aufweisen. Auf die in einem Hub befindlichen Geschäftsobjekte wird anschließend von anderen Data-Vault-Entitäten über Hash-Keys verwiesen, die während der Staging-Phase berechnet werden.

Daher müssen an Hubs folgende Tests durchgeführt werden, um deren Konsistenz zu gewährleisten. Für einen Hub mit einem einzelnen Business-Key sollten Tests sicherstellen, dass:

  • der Hub eine eindeutige Liste von Business-Keys enthält (Primary-Key- (PK-) Test).
  • eine Business-Key-Spalte keine NULL- oder leeren Werte enthält (außer wenn der Business-Key zusammengesetzt ist).

Wenn ein Hub einen zusammengesetzten Business-Key hat, stellen Sie sicher, dass:

  • die Kombination der Werte in den Business-Key-Spalten eindeutig ist (PK-Test).
  • die Business-Key-Spalten nicht alle gleichzeitig NULL- oder leere Werte enthalten.

Die Gültigkeit des letztgenannten Punktes hängt von der Natur des Geschäftsobjekts selbst ab. Es kann auch sein, dass in keiner der Business-Key-Spalten NULL- oder leere Werte zulässig sind.

Stellen Sie für beide Arten von Hubs sicher, dass:

  • die Hash-Key-Spalte eine eindeutige Liste
    • eine eindeutige Liste von Werten enthält (PK-Test)
    • keine NULL- oder leeren Werte vorhanden sind.

Testen von Links

Ein typischer Link definiert Beziehungen zwischen Geschäftsobjekten, indem er eindeutige Kombinationen von Hash-Keys der verbundenen Hubs speichert. Der Primary-Key des Links oder der Link-Hash-Key identifiziert eine solche Kombination eindeutig. Daher sollten Link-Tests Folgendes prüfen:

  • dass die Kombination der verbundenen Hub-Referenzen (Hub-Hash-Keys) eindeutig ist (PK-Test).
  • dass jeder Hub-Hash-Key-Wert im referenzierten Hub existiert.
  • dass Hub-Referenzen keine NULL- oder leeren Werte enthalten.

Beachten Sie bezüglich des letzten Aufzählungspunkts, dass NULL- und leere Werte in Hub-Referenzen sowie in Hash-Key-Spalten anderer Data-Vault-Entitäten durch Zero-Keys ersetzt werden. Für transaktionale (nicht historisierte) Daten sollten transaktionale Schlüsselspalten zusätzlich zu den Spalten mit Hub-Hash-Keys in die Eindeutigkeitstests einbezogen werden. Stellen Sie sicher, dass auch transaktionale Schlüssel befüllt sind. Solche transaktionalen Schlüssel werden in der Regel nicht gehasht, da im Regelfall keine Hubs für Transaktionen erstellt werden.
Zudem sollten Sie, wie bei den Hubs, sicherstellen, dass die Link-Hash-Key-Spalte eindeutige Werte enthält und keine NULL- oder leeren Werte vorhanden sind.

Testen von Satellites

Satelliten speichern beschreibende Informationen (Attribute) für Geschäftsobjekte (die sich in Hubs befinden) oder Beziehungen zwischen Geschäftsobjekten (die sich in Links befinden). Ein Satellit referenziert entweder einen Hub oder einen Link. Da sich beschreibende Informationen für Geschäftsobjekte und deren Beziehungen im Laufe der Zeit ändern können, wird der Primary-Key eines Satelliten um den Load-Date-Timestamp des Satellitendatensatzes ergänzt.

Vor diesem Hintergrund sollten Tests für einen Satelliten sicherstellen, dass:

  • die Kombination aus einer Hub-/Link-Referenz (dem Hash-Key) und dem Load-Date-Timestamp eines Datensatzes eindeutig ist (PK-Test).
  • jeder Hub- oder Link-Hash-Key-Wert im referenzierten Hub oder Link existiert.
  • Hub- oder Link-Referenzen keine NULL- oder leeren Werte enthalten.

Multi-Active-Satelliten enthalten mehrere aktive Datensätze zur gleichen Zeit. Daher sind zusätzliche Schlüsselspalten (z. B. Type Code, Sequence usw.) erforderlich, um einen Datensatz eindeutig zu identifizieren. Diese zusätzlichen Schlüsselspalten müssen Teil des Eindeutigkeitstests eines Multi-Active-Satelliten sein. Darüber hinaus sollten sie auf das Fehlen von NULL- und leeren Werten getestet werden. Der Ansatz zum Testen eines Non-Historized-Satelliten unterscheidet sich ebenfalls geringfügig vom Testen seines Standard-Pendants. Ein Non-Historized-Satellit ist ein spezieller Entitätstyp, der beschreibende Attribute für jeden entsprechenden Datensatz in einem Non-Historized-Link enthält. Der Primary-Key eines Non-Historized-Satelliten ist ein Link-Hash-Key. Daher ist es nicht erforderlich, einen Load-Date-Timestamp in die Prüfung des Primary-Keys einzubeziehen. Stellen Sie bei einem Non-Historized-Satelliten zusätzlich sicher, dass er eine 1:1-Beziehung mit dem entsprechenden Non-Historized-Link aufweist. Die Anzahl der Datensätze (Record Counts) in beiden Entitäten sollte exakt übereinstimmen.

Testen anderer Data Vault-Entitäten

Es gibt weitere spezielle Entitätstypen in Data Vault, die im Hinblick auf das Testen erwähnenswert sind:

  • Reference-Hubs und Reference-Satelliten: Die Testansätze ähneln denen von Standard-Hubs und -Satelliten. Der einzige Unterschied besteht darin, dass keine Hash-Keys vorhanden sind und Business-Keys direkt verwendet werden.
  • Record-Source-Tracking-Satelliten: Dem Primary-Key-Test wird eine Spalte hinzugefügt, die einen statischen Quellnamen repräsentiert.
  • PIT-Table (Business Vault)
    • PK-Test – die Kombination aus dem Hub-/Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten ist eindeutig.
    • Überprüfen Sie für jede Satelliten-Referenz, ob das Paar aus Hub-/Link-Hash-Keys und dem Load-Date-Timestamp im referenzierten Satelliten existiert.
    • Die Hub-/Link-Referenz enthält keine NULL- oder leeren Werte.
  • Bridge-Table (Business Vault):
    • PK-Test – die Kombination aus einem Basis-Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten ist eindeutig.
    • Überprüfen Sie für jede Hub- und Link-Referenz, ob das Hub-/Link-Hash-Key-Paar im referenzierten Hub oder Link existiert.

Allgemeine Tests für alle Data Vault-Entitäten

Es gibt einige Tests, die für alle Data-Vault-Entitäten anwendbar sind.
Stellen Sie sicher, dass alle Data-Vault-Entitäten:

  • Zero-Keys anstelle von NULL-Schlüsseln enthalten.
  • Record-Source-Spalten haben, die befüllt sind und dem definierten Muster (z. B. Regex) entsprechen. Prüfen Sie beispielsweise, ob sie den Dateipfad enthalten, bei dem der Name des Ordners auf oberster Ebene den Namen des Quellsystems darstellt und der Dateiname den Zeitstempel der Datenextraktion enthält.
  • Keine NULL-Werte in ihren Load- (bzw. Snapshot-) Date-Timestamp-Spalten aufweisen

Testen von Source Marts

Der Source-Mart ist eine der Facetten des Information-Mart-Konzepts in Data Vault. Es handelt sich um ein virtualisiertes Modell auf dem Raw Data Vault mit dem Ziel, die ursprünglichen Quellstrukturen zu replizieren. Er eignet sich hervorragend für Ad-hoc-Berichte, bietet vielen Data Scientists und Power-Usern einen hohen Mehrwert und kann auch verwendet werden, um die Konsistenz und Revisionssicherheit des Ladeprozesses in ein Data-Vault-gestütztes EDW zu testen.

Source-Mart-Objekte sollen genauso aussehen wie die jeweiligen Quelltabellen (einschließlich der Spaltennamen). Wenn Sie Source-Marts in Ihrem EDW implementiert haben, stellen Sie sicher, dass Sie diese nach dem Datenladeprozess mit den jeweiligen Quelltabellen in der Staging Area vergleichen. Werte und Zeilenanzahlen (Row Counts) der Quellstrukturen sollten exakt mit den jeweiligen Source-Mart-Objekten übereinstimmen. In der Data-Vault-Community ist diese Art von Test auch als „Jedi-Test“ bekannt.

Es ist relativ einfach, einen solchen Vergleich zu automatisieren und ihn in den Ladeprozess zu integrieren.

Testen von Hash Key- und Hash Diff-Berechnungen

Hash-Keys in Data Vault ermöglichen es, Business-Keys auf deterministische Weise aus mehreren Quellen parallel zu integrieren. Sie sind das Bindeglied, das verschiedene Data-Vault-Entitäten miteinander verbindet.

Hash-Diffs hingegen werden auf die Satelliten angewendet und helfen dabei, Unterschiede in beschreibenden Attributen während des Datenladeprozesses zu identifizieren.

Es ist wichtig, Unit-Tests für die in Ihrem EDW verwendeten Hash-Key- und Hash-Diff-Berechnungen einzuführen, um sicherzustellen, dass die gehashten Werte gemäß den definierten Hashing-Standards berechnet werden. Lesen Sie hier mehr über Anforderungen und Vorlagen für das Hashing. Testfälle für solche Unit-Tests sollten so viele Kombinationen verschiedener Datentypen und Werte (z. B. NULL- und leere Werte) wie möglich abdecken, um eine konsistente Berechnung zu gewährleisten.

Falls Ihr EDW auf verschiedenen DBMS-Plattformen existiert (z. B. während eines Migrationsprozesses oder aufgrund von Datensicherheitsvorschriften), können die oben genannten Testfälle verwendet werden, um sicherzustellen, dass Ihre Hash-Berechnungen plattformunabhängig (platform-agnostic) sind – was bedeutet, dass sie auf verschiedenen Plattformen das gleiche Ergebnis liefern. Ein typischer Anwendungsfall ist, wenn ein Link auf einer On-Premises-DBMS-Plattform auf einen Hub verweist, der bereits auf eine Cloud-Plattform migriert wurde. Solche Unit-Tests können auf beiden Plattformen ausgeführt werden, um die Konsistenz des Hashings während einer Migration sicherzustellen.

Testen von Business Rules

Im Gegensatz zu Hard-Rules, welche die Inhalte der Daten nicht verändern oder unterbrechen und so die Revisionssicherheit wahren, setzen Soft-Rules oder Business-Rules die von den Geschäftsanwendern (Business Users) definierten geschäftlichen Anforderungen um. Beispiele für Business-Rules sind:

  • Verkettung (Nachname und Vorname)
  • Standardisierung von Telefonnummern
  • Berechnung des Gesamtumsatzes (Aggregation)
  • Coalescing (Zusammenführung) usw.

Neben den oben aufgeführten, relativ einfachen Beispielen kann es auch komplexere Business-Rules geben, die anspruchsvolle Berechnungen, Datentransformationen und komplexe Joins beinhalten. Je nach Anwendungsfall landen die Ergebnisse dieser Regeln im Business Vault (z. B. in einem Business-Satelliten) und später in der Information-Mart-Schicht, wo sie von den Geschäftsanwendern konsumiert werden. Daher ist das Testen von Business-Rules ein wichtiger Teil des Informationsbereitstellungsprozesses (Information Delivery Process).

Business-Rules sind in der Regel auch Gegenstand von Unit-Tests, die kontinuierlich während des Entwicklungs- und CI-Prozesses durchgeführt werden müssen. Um einen solchen Unit-Test durchzuführen, werden bestimmte Erwartungswerte benötigt, die im besten Fall vom Fachbereich (Business) bereitgestellt werden – beispielsweise ein erwarteter Nettoumsatzwert für ein bestimmtes Produkt oder eine Reihe von Produkten in einer bestimmten Filiale an einem bestimmten Tag auf der Grundlage realer Daten. Die Nettoumsatzberechnung aus dem Business Vault wird dann gegen das vorgegebene erwartete Ergebnis getestet.

Testautomatisierung und Continuous Integration

Alle oben beschriebenen Tests sollten so weit wie möglich automatisiert und von den EDW-Entwicklern während des Entwicklungsprozesses ausgeführt werden. Erfolgreiche Tests sollten eine zwingende Voraussetzung für die Integration neuer Änderungen in Ihre EDW-Codebasis sein. Dies lässt sich durch den Einsatz von DevOps-Tools und die Aktivierung von Continuous Integration (CI) in Ihrem EDW-Entwicklungslebenszyklus erreichen. Die Ausführung automatisierter Tests bei jedem Einchecken oder Zusammenführen (Mergen) von Code stellt sicher, dass Probleme mit der Datenkonsistenz oder Fehler frühzeitig erkannt und behoben werden, bevor sie in die Produktion übergeben werden. In der Regel wird für die Durchführung automatisierter Tests eine separate Test- (oder CI-) Umgebung erstellt.

Hier sind einige allgemeine Empfehlungen für das Erstellen und Betreiben einer Testumgebung:

  • Gestalten Sie die CI-Umgebung so ähnlich wie möglich zur Produktionsumgebung.
  • Erstellen Sie Test-Quelldatenbanken und Quelldateien, die von realen Daten abgeleitet sind.
  • Die Test-Quelldateien und -Quelldatenbanken sollten klein sein, damit die Tests schnell ausgeführt werden können.
  • Die Test-Quelldateien und -Quelldatenbanken sollten zudem statisch sein, damit die erwarteten Ergebnisse im Voraus bekannt sind.
  • Testen Sie Full-Load- und Incremental-Load-Muster, da sich die Logik beider Muster in den meisten Fällen unterscheidet.
  • Führen Sie Tests nicht nur für die zusammenzuführenden Änderungen aus, sondern auch für alle nachgelagerten Abhängigkeiten (Downstream Dependencies) oder sogar für den gesamten Ladeprozess im Allgemeinen, um Regressionen zu vermeiden.

Fazit

In diesem Newsletter haben wir Ihnen einen Überblick über verschiedene Methoden und Ansätze für das technische Testen eines Data-Vault-gestützten EDW gegeben.

Wir haben das Testen verschiedener Phasen des EDW-Ladeprozesses behandelt, einschließlich der Extraktion von Daten aus Datenquellen, dem Laden von Data-Vault-Entitäten und dem Informationsbereitstellungsprozess (Information Delivery Process), wobei der Hauptfokus auf dem Laden von Data-Vault-Entitäten lag.

Wir haben auch das Unit-Testing von Hash-Key- und Hash-Diff-Berechnungen behandelt.

Es ist wichtig, sicherzustellen, dass Ihre Hashing-Lösung plattform- und werkzeugunabhängig (platform-/tool-agnostisch) ist, insbesondere während des Migrationsprozesses.

Wir haben auch gelernt, dass das Testen von Business-Rules ein wesentlicher Bestandteil des Informationsbereitstellungsprozesses ist, da diese die Daten interpretieren und definieren, was Geschäftsanwender in ihren Berichten sehen. Wir haben die Bedeutung von Unit-Tests für die Business-Rules und die Zusammenarbeit mit dem Fachbereich (Business) bei der Definition von Testfällen und erwarteten Ergebnissen hervorgehoben.

Darüber hinaus haben wir die Bedeutung der Testautomatisierung während der Entwicklungsphase sowie für die Ermöglichung von Continuous Integration betont und Empfehlungen für die Erstellung und den Betrieb einer Testumgebung gegeben.

In unserem Webinar gehen wir noch tiefer auf dieses Thema ein. Nutzen Sie die Gelegenheit und sehen Sie sich die Aufzeichnung kostenlos an!

In Data Warehouse

Was Sie bei Namenskonventionen im Data Warehousing beachten sollten – Teil 1

Naming conventions - Letter cases

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.

In this article:

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.

Naming conventions - Letter cases
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.

Naming conventions - prefix
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.

Naming conventions - Schema
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?

Close Menu