Eine Einführung in die Datenbanknormalisierung (Database Normalization)

Daten sind die heutige Währung des Marketings. Und dank moderner Technologien stehen Marketer heute in Bezug auf Zielgruppen, Kaufverhalten und die Wirksamkeit ihrer Kampagnen mehr datengestützte Erkenntnisse zur Verfügung als je zuvor. Doch nur Datenbanken mit normalisierten Daten können diese Erkenntnisse liefern - deshalb ist das Thema Datenbanknormalisierung (Database Normalization) auch so wichtig.

Die Datenbanknormalisierung verleiht euren Daten Kontext und Struktur. Anstatt die Informationen überall verstreut aufzubewahren, werden die Daten in einem logischen, nutzbaren Format angeordnet. Die NutzerInnen können Informationen - ohne langes Versteckspiel - schneller in der Datenbank finden. Und wenn Daten einfacher gefunden werden können, können sie auch einfacher in der Datenanalyse genutzt werden.

Wie wird die Datenbanknormalisierung von einem Problem zu einer Top-Priorität? Lies diesen Leitfaden, um loszulegen.

Inhalt

• Was ist Datenbanknormalisierung (Database Normalization)

• Weshalb sind normalisierte Daten wichtig?

• Was sind Arten der Datennormalisierung?

• Wie werden Daten normalisiert?

Was ist Datenbanknormalisierung (Database Normalization)?

Verschaffen wir uns etwas Klarheit bezüglich der Datenbanknormalisierung (Englisch "Database Normalization"): Was genau ist das?

Im Gegensatz zum Marie-Kondo-Ansatz, ein Modell, bei dem du nur das behältst, was dir Freude macht, geht es bei dieser Art der Organisation darum, die Daten in einer logischen Weise anzuordnen. 

Die Normalisierung von Daten ist nach der Erstellung einer Datenbank der nächste logische Schritt. Bei diesem werden alle potenziellen Anomalien, Fehler oder Redundanzen entfernt, Regeln erstellt, um bestimmte Daten miteinander zu verknüpfen, und anschließend getestet, um sicherzustellen, dass sie auch sicher funktionieren.

Das Endergebnis ist Einfachheit und Leistungsfähigkeit. Wenn du Struktur und Logik zu deinen Daten hinzufügst, kannst du eine kleinere Datenbank unterhalten, die präzise und einfacher zu nutzen ist. Gleichzeitig bist du dadurch in der Lage, deine Daten erfolgreicher für dich arbeiten zu lassen.

Weshalb sind normalisierte Daten wichtig?

Normalisierte Daten werden mit der ständig wachsenden Menge von Marketingdaten immer wichtiger. Marketer erfassen Informationen aus mehr Quellen als je zuvor, beispielsweise aus E-Mails, den sozialen Medien, Suchmaschinen und der Marktforschung. Wenn du mehrere Software-as-a-Service-Tools verwendest, kann es sein, dass diese Anwendungen sich nicht immer gegenseitig unterstützen.

Was sind Vorteile der Normalisierung einer Datenbank?

Bei der Vereinheitlichung der Speicherung und des Zugriffs auf all eure Daten ergeben sich zahlreiche Vorteile:

• Beseitigung von Datenredundanz
• Ausschließlicher Fokus auf die erforderlichen Werte
• Gemeinsame Speicherung verwandter Daten
• Auflösung widersprüchlicher Daten
• Reduzierung der Komplexität von Datenbanken
• Schnellere und genauere Datenanalyse

Die Normalisierung von Datenbanken bietet außerdem die Möglichkeit, Anomalien zu beseitigen, die eure Datenanalysen beeinträchtigen könnten. Im Laufe der Zeit können Anomalien beispielsweise durch das Einfügen, Löschen oder Ändern von Daten entstehen. Wenn du diese Anomalien findest und herausfindest, wie du sie beheben kannst, lassen sich deine Daten schlussendlich erfolgreicher nutzen.

Der entscheidende Punkt ist, dass der ultimative Nutzen nicht in der Normalisierung der Daten selbst liegt. Vielmehr müssen Unternehmen ihr Augenmerk auf die Vorteile hinter dieser Maßnahme legen. Ohne diesen Prozess werden viele der wertvollen Daten, die ihr erfasst, nie genutzt - zumindest nicht in ihrem vollen Umfang. Die Datennormalisierung ist ein hervorragendes Mittel, um unnötige oder ungenaue Daten, die das Gesamtbild beeinträchtigen, zu beseitigen.

Was sind Arten der Datennormalisierung?

Normalisierung hat viele Gesichter, die von der jeweiligen Datenbank abhängen. Welche Arten der Datennormalisierung gibt es? Schauen wir uns einige Beispiele an:

1. Erste Normalform:
   Die erste Normalform (abgekürzt als 1NF) ist die einfachste und grundlegendste Form der Normalisierung. Bei diesem Prozess geht es darum, redundante Daten zu entfernen und zusammengehörige Daten in separate Tabellen aufzuteilen.
2. Zweite Normalform:
   Als Erweiterung der 1NF beseitigt die zweite Normalform (2NF) Untergruppen von Daten, die in mehreren Zeilen einer Tabelle angezeigt werden. Es werden neue Tabellen erstellt und Verbindungen zwischen ihnen hinzugefügt.
3. Dritte Normalform:
   Die dritte Normalform (3NF) erfüllt alle Regeln der 2NF plus noch einige weitere. Sie eliminiert Spalten, die keine tabelleninternen Abhängigkeiten vom Hauptschlüsselwert aufweisen.
4. Vierte Normalform und Fünfte Normalform:
   Die komplexeste Normalform ist die fünfte Normalform (5NF), dicht gefolgt von der vierten Normalform (4NF). Sie werden nur selten verwendet, da die ersten drei Normalformtypen am häufigsten vorkommen.
5. Boyce-Codd-Normalform:
   Die Boyce-Codd-Normalform (abgekürzt BCNF) ist ein guter Mittelweg zwischen der 3NF und der 4NF (wir nennen sie 3,5 NF). Nachdem die 3NF-Richtlinien erfüllt wurden, kann die BCNF einen Superkey-Wert bestimmen, wenn alle anderen Werte funktional von ihm abhängig sind.

Mit jeder Erhöhung des Normalisierungsgrades wird den Daten ein weiteres technisches Makeover verpasst.

In der 4NF werden zum Beispiel alle Abhängigkeiten zwischen verschiedenen Werten gelöscht. Technische und komplexe Prozesse sind jedoch nicht mit "besseren" Prozessen zu verwechseln.

Wie werden Daten normalisiert?

Und nun die große Frage: Wie lassen sich die Daten mit all den oben genannten Informationen normalisieren?

Die Datenbanknormalisierung ist ein Prozess, der am besten in Phasen unterteilt wird. Ein typisches Normalisierungsprojekt besteht aus den folgenden Schritten:

1. Erstellung einer Tabellen für die einzelnen Werte
2. Verbindung der Werte in den einzelnen Tabellen
3. Verknüpfung der Haupt-Schlüsselwerte mit Nicht-Schlüsselwerten

Führen wir am besten gemeinsam ein praxisnahes Normalisierungsbeispiel durch.

Beispiel für eine Datenbanknormalisierung

Gehen wir davon aus, dass du eine relationale Datenbank für deine Marketingagentur erstellen möchtest. Ihr bietet verschiedene Marketingdienstleistungen für unterschiedliche Branchen an. Eure bisherige relationale Datenbank besteht ausschließlich aus Tabellen für Kampagnen, den Kampagnen zugewiesene MitarbeiterInnen und Projekte innerhalb der Kampagne.

Nun möchtest du aber weitere Informationen daraus gewinnen. Deshalb musst du nach dem ursprünglichen Datenbankentwurf weitere Angaben zu deiner Datenbank hinzufügen. Das erfordert in der Regel eine Normalisierung, denn wenn du neue Werte hinzufügst, die nicht Teil des bestehenden Schemas sind, werden sie möglicherweise nicht korrekt mit den bestehenden Werten verknüpft.

Erste Phase: Erstellung deiner Tabellen

Beim ersten Schritt gilt es, sicherzustellen, dass dein Tabellenschema alle deine Werte unterstützt. Es ist hilfreich, zunächst eine Übersicht über alle Kundenbeziehungsdaten zu erstellen, die erfasst werden müssen.

Im obigen Anwendungsfall würdest du eine Tabelle für die Auflistung eurer Marketingdienstleistungen, eine für die MitarbeiterInnen und eine für die Projekte einrichten.

Nehmen wir an, du möchtest nun für einen zusätzlichen Überblick eine Kundentabelle hinzufügen. Diese neue Tabelle enthält wichtige Kundendaten wie Firmennamen, Kontaktperson, Branche, Telefonnummer, Adresse und Postleitzahl.

Dir fehlen diese Daten? Dann lies dir gerne unseren Beitrag zu Data Cleansing und Data Enrichment durch, um sie zu beschaffen!

Deine Tabelle sollte so einfach wie möglich aufgebaut sein. Die Kontaktperson und die Stellenbezeichnung dürfen zum Beispiel nicht in der gleichen Tabellenspalte stehen. Weise jeder Spalte und jeder Zeile nur einen Wert zu.

Hier ist ein einfaches Beispiel:

Kundentabelle 1

Außerdem muss in der Tabelle ein Primärschlüssel (auch Kandidatenschlüssel genannt) vorhanden sein. Anhand des Primärschlüssels können die NutzerInnen eindeutige Informationen identifizieren, die sich von allen anderen Daten unterscheiden. In diesem Anwendungsfall könnten wir die Projekt-ID als Primärschlüssel bestimmen - und benötigen dafür eine eigene Spalte.

Achte zudem darauf, dass sich die Informationen in der Tabelle nicht wiederholen. Wenn zum Beispiel mehrere Spalten für Projektbewertungen bestehen, damit verschiedene Projekte für ein und denselben Kunden erfasst werden können, solltest du diese in eine neue Tabelle verschieben. Das reduziert die Komplexität der Kundentabelle, ohne dass wichtiges Feedback verloren geht.

Anschließend kannst du die Projektbewertungstabelle mit der Kundentabelle und der Projekttabelle verknüpfen (was in der nächsten Phase geschieht).

Damit sollten alle 1NF-Anforderungen erfüllt sein.

Zweite Phase: Verknüpfung der Werte in den einzelnen Tabellen

An dieser Stelle könntest du die Aufgabe als erledigt und deine Datenbank als normalisiert ansehen. Doch die Extrameile für die Vervollständigung der 2NF zu gehen, erfordert kaum zusätzliche Arbeit. Außerdem erhältst du so eine bessere Kontrolle über deine Daten.

In dieser Phase musst du sicherstellen, dass sich alle Spalten der Tabelle auf den Primärschlüssel beziehen. Die Spalten, die sich nicht direkt auf den Primärschlüssel beziehen, sollten in eine andere Tabelle übertragen werden.

In unserem Anwendungsbeispiel haben wir eine Spalte für die Projekt-ID erstellt und sie zu unserem Primärschlüssel gemacht. Anhand dieser eindeutigen Kennzeichnung können wir sehen, welche Projekte zu den einzelnen Kunden gehören.

Allerdings können wir die Werte für die Kontaktperson, die Stellenbezeichnung oder die Telefonnummer nicht mit dem Primärschlüssel verknüpfen, da sich diese Informationen jederzeit ändern können. Das birgt ein gewisses Risiko für die Genauigkeit deiner Datenbank: Was ist, wenn ein neuer Mitarbeiter dieses Unternehmens zu deinem neuen Ansprechpartner wird? Das könnte bedeuten, dass sich auch die Werte für die Telefonnummer und die Stellenbezeichnung ändern. Wenn sich also eine Kontaktperson ändert, müssen eine Menge zusätzlicher Felder aktualisiert werden.

Weil sich diese Werte nicht auf den Primärschlüssel beziehen können, müssen wir sie in eine eigene Tabelle verschieben. Diese neue Tabelle enthält alle Angaben über die Kontaktperson. Dann können wir die Tabelle mit der Kundentabelle verbinden, indem wir die ID der Kontaktperson als Primärschlüssel verwenden.

Die neuen Tabellen könnten etwa so aussehen:

Kundentabelle 2

Kontaktperson Tabelle

Wenn nun eine neue Kontaktperson für einen Kunden hinzukommt, kannst du einfach die "Kontaktperson-ID" in der Kundentabelle aktualisieren. Anhand dieser ID kannst du alle Angaben zur aktuellen Kontaktperson abrufen.

Wenn sich die Kontaktperson ändert, erstellst du einfach einen neuen Datensatz in der Kontaktperson-Tabelle.

Wiederhole diesen Vorgang, um sicherzustellen, dass alle Spalten in einer Tabelle einem Primärschlüssel zugeordnet sind - danach ist die 2NF abgeschlossen.

Dritte Phase: Verknüpfung von Haupt-Schlüsselwerten mit Nicht-Schlüsselwerten

Um die 3NF in der Datenbanknormalisierung zu erfüllen, müssen wir sicherstellen, dass sich die Spalten nur auf den Primärschlüssel und nicht auf andere Spalten beziehen. Eine funktionale Abhängigkeit von mehr als einer Spalte in einer Tabelle kann die Datengenauigkeit beeinträchtigen, wenn sich die Werte im Laufe der Zeit ändern.

In unserer Beispieltabelle "Kunden" sehen wir die funktionale Abhängigkeit in den Spalten Ort, Bundesland und Postleitzahl. Diese beziehen sich nicht nur auf den Primärschlüssel des Kunden, sondern auch aufeinander. Wenn ein Unternehmen beispielsweise den Standort wechselt, wirkt sich eine Aktualisierung des Ortes mit Sicherheit auch auf die Postleitzahl aus.

Weshalb gilt das nicht für die Adresse oder das Bundesland? Das liegt daran, dass sich diese Werte nur manchmal gegenseitig beeinflussen. Wenn ein Unternehmen in eine andere Straße zieht, hat das wahrscheinlich keine Auswirkungen auf den Ort, das Bundesland oder die Postleitzahl. Wenn du eine Adresse änderst, kann sich das Bundesland ändern oder auch nicht. Aber eine Änderung des Ortes oder Bundeslandes wirkt sich immer auf die Postleitzahl aus.

Wir können die 3NF erfüllen, indem wir (du hast es erraten) eine separate Tabelle erstellen. Diese Tabelle muss den Ort, das Bundesland und die Postleitzahl(en) enthalten, die mit jedem Kunden verbunden sind. Du kannst sie mit der Kundentabelle verknüpfen, indem du einen Fremdschlüssel erstellst. In diesem Fall ist es die "PLZCodeID".

Unsere neuen Tabellen sehen dann ungefähr so aus:

Kundentabelle 3

PLZ Code Tabelle

Wenn dein Kunde die Adresse ändert, kannst du einen neuen Datensatz in der Tabelle "Postleitzahlen" erstellen, um den Ort, das Bundesland und die Postleitzahl zu aktualisieren, und dann die Adresse in der Tabelle "Kunden" anpassen.

Big Data in eine normalisierte Datenbank umzuwandeln, kann ein ziemliches Unterfangen sein. Es hilft dir jedoch dabei, das Optimum aus den Data Science Praktiken herauszuholen. Wenn du in Zukunft maschinelles Lernen, die Automatisierung von Datenmodellen oder Data Mining für Deep Learning in Betracht ziehst, muss eure Datenstruktur standardisiert werden. Dabei hilft dir ein gutes Datenbankmanagement.

Wenn du erfahren möchtest, wie Meltwater die Datenbanknormalisierung für euch anwendet, kontaktiere uns noch heute, indem du das folgende Formular ausfüllst: