Unternehmen sammeln und speichern große Mengen an Daten, die Informationen über das Geschäftsprofil enthalten, z. B. Verkäufe, Zusammenarbeit mit Partnern, Lagerbestände, Lieferungen und Produktpreise. Es ist offensichtlich, dass Daten nicht beliebig in Datenbanksystemen abgelegt werden können. In dieser Situation ist es notwendig, die relationale Datenbank richtig zu entwerfen. Eine gut gestaltete relationale Datenbank zeichnet sich dadurch aus, dass alle notwendigen Informationen in den Geschäftsbereichen des Unternehmens klar und übersichtlich dokumentiert und im Alltag einfach zu nutzen sind.
Eine Möglichkeit, eine relationale Datenbank intuitiv zu konstruieren, ist die Normalisierung. Dies ist ein Prozess der Organisation von Daten in einer Datenbank, bei dem Tabellen erstellt werden, die einen einzigartigen Bereich der Unternehmensaktivitäten repräsentieren (wie vendors oder customers), und Beziehungen zwischen diesen Tabellen durch Eliminierung von Redundanz und inkonsistenter Abhängigkeit festgelegt werden. Gleichzeitig kann die Normalisierung als Ziel in der Entwurfsphase der relationalen Datenbank betrachtet werden.
Manchmal gibt es jedoch Situationen, in denen es notwendig ist, von dieser Regel abzuweichen, und es kann erforderlich sein, eine sogenannte Database Denormalization durchzuführen.
Was ist database denormalization?
Kurz gesagt, database denormalization ist das Zusammenführen von normalisierten Tabellen zu einer einzigen. Dies ist die Einführung kontrollierter Redundanz in die Datenbank, um die Arbeit mit ihr zu beschleunigen. Wenn große Datenmengen in relationalen Tabellen vorliegen, kann das Joinen dieser Tabellen zur Gewinnung der benötigten Informationen zu teuer werden. Eine Lösung ist daher das Cross-Checking von Schlüsseln oder Spalten zwischen häufig verbundenen Tabellen.
Folglich enthält die Zieltabelle nicht nur die für sie relevanten Daten, sondern auch Informationen aus anderen Tabellen. Natürlich bringt diese Lösung die Möglichkeit von Datenredundanz in den Tabellen mit sich, was wiederum zu einer schnellen Vergrößerung ihrer Größe führt. Ein häufiges Symptom ist die Möglichkeit von Daten-Duplikaten.
Aus dieser Sicht erscheint database denormalization als eine Art Kompromiss. Während bei der Normalisierung das Ziel darin besteht, die Tabellen auf die maximal unabhängige Form für jeden Datenbereich zu vereinfachen, ist die Denormalisierung auf die spezifische Art des Datenzugriffs zugeschnitten und kann nicht universell für jeden Fall definiert werden. Ihre effiziente Funktionsweise muss auf Basis der Geschäftsanforderungen festgelegt werden. Wenn Sie wissen möchten, wie Sie dies richtig umsetzen, besuchen Sie unsere Data Engineering Consultancy Seite.
Database denormalization – Vorteile und Nachteile
Bei einem schnellen Anstieg der Datenmenge in einer Datenbank bringt die Denormalisierung spürbare Vorteile, hat aber auch einige Nachteile. Hier einige davon:
Vorteile der database denormalization:
- Erhöhte Geschwindigkeit der Abfrageausführung.
Da keine Joins zwischen Tabellen erforderlich sind, können die benötigten Informationen aus einer einzigen Tabelle extrahiert werden, was die Geschwindigkeit der Abfrageausführung automatisch erhöht. Zusätzlich spart diese Lösung Speicher. - Einfacheres Schreiben von Abfragen.
Wenn die Tabelle für die häufigsten Anforderungen richtig umorganisiert ist, können Daten aus nur einer Tabelle abgerufen werden, ohne Zeit mit der Suche nach Join-Keys zu verlieren. Man sollte jedoch an die Datenredundanz denken und die Abfrage entsprechend anpassen. - Kein Bedarf, Daten aus Dictionary-Tabellen zu holen, deren Werte sich über die Zeit nicht ändern.
Tabellen mit Länder-Dictionaries sind ein gutes Beispiel. Wenn ein Unternehmen auf einer festen Anzahl von Märkten tätig ist, ist es unnötig, ständig Joins mit der Ländertabelle durchzuführen. In diesem Fall lohnt es sich, z. B. der Verkaufstabelle eine Spalte mit dem Ländernamen hinzuzufügen. - Möglichkeit, aggregierte Daten hinzuzufügen, die für effizienteres Reporting genutzt werden können.
Bestimmte Statistiken wie die Anzahl der Verkaufsaktionen, durchschnittlicher Umsatz usw. sind sehr wichtig für die Analyse verschiedener Unternehmensbereiche. Es kann einfacher sein, Schlüsselstatistiken zu definieren und in einer Tabelle zu speichern, als sie durch Joins mehrerer Tabellen zu berechnen. - Reduktion der Anzahl der Tabellen in einer relationalen Datenbank.
Bei einer komplexen relationalen Architektur kann das Abrufen von Daten aus mehreren Tabellen schwierig sein. Wenn die Datenbank richtig denormalisiert ist, kann die Anzahl dieser Tabellen effektiv reduziert und die Architektur vereinfacht werden.
Nachteile der database denormalization:
- Erhöhte Verarbeitungsgröße.
Aufgrund von Redundanz und möglichen Duplikaten steigt die Größe der Abfrageverarbeitung. - Größere Tabellengrößen.
Durch die Denormalisierung kann die Tabelle erheblich an Größe zunehmen, was die Speicherkapazität belasten kann. - Höhere Kosten für Updates und Inserts.
In einer Tabelle mit redundanten Daten kann das Aktualisieren problematisch sein. Wenn z. B. eine zusätzliche Spalte mit der Kundenadresse hinzugefügt wurde, kann das Aktualisieren dieser Daten aufwendig und teuer sein, wenn der Kunde die Adresse ändert. In einer normalisierten Datenbank reicht es, die Daten in der Dictionary-Tabelle zu ändern. Ähnlich verhält es sich mit Inserts – durch die Redundanz kann das Einfügen vieler Daten in eine Tabelle aufwendig sein. - Daten können inkonsistent sein.
Vor der Ausführung einer Abfrage muss die Tabelle gründlich verstanden und Daten-Duplikate berücksichtigt werden. Die Abfrage, die die benötigten Daten ohne Inkonsistenzrisiko extrahiert, sollte umfassend vorbereitet werden.
Database denormalization – Beispiele
- Spalten mit aggregierten Daten.
Angenommen, die Datenbank hat Tabellen für advertisers, sales und campaigns. Für das Reporting der Werbetreibenden ist es notwendig, die Anzahl der Kampagnen und den Umsatz für jeden zu zählen. Es ist möglich, der advertisers-Tabelle zusätzliche Spalten hinzuzufügen, die die Anzahl der Kampagnen und das Verkaufsvolumen zählen. Dadurch muss man diese Daten nicht jedes Mal aus sales und campaigns per count-Funktion holen. - Dictionary-Tabellen.
Beispiel: Es gibt Tabellen für countries und customers. Das Unternehmen möchte Kunden und Länder hinsichtlich der Verkaufseffektivität analysieren, daher werden regelmäßig Joins zwischen customers und countries durchgeführt. Um diese häufigen Joins zu vermeiden, kann der customers-Tabelle eine Spalte mit dem Ländernamen hinzugefügt werden. - Erstellen einer neuen Tabelle, die den Geschäftsanforderungen entspricht.
Wenn häufig Daten aus mehreren Tabellen abgerufen werden müssen, kann – nach entsprechender Definition der Geschäftsanforderungen – eine Tabelle erstellt werden, die die Verarbeitungsgröße und Zeit für regelmäßige Joins reduziert.
Zurück zum ersten Beispiel: Wenn ein Unternehmen regelmäßig Verkaufsdetails wie Kampagnen oder Advertisers mit vollständigen Namen extrahieren möchte, kann eine Tabelle erstellt werden, die alle notwendigen Daten in der sales-Tabelle enthält. So können die benötigten Daten abgerufen werden, ohne regelmäßig mehrere Tabellen joinen zu müssen.
- Wörterbuchtabellen.
In diesem Beispiel gibt es zwei Tabellen in der Datenbank: Länder und Kunden. Eine der Anforderungen des Unternehmens besteht darin, Kunden und Länder unter dem Gesichtspunkt der Vertriebseffektivität zu untersuchen. Daher werden Verknüpfungen regelmäßig zwischen den Tabellen „Kunden“ und „Länder“ vorgenommen. Um das häufige Zusammenfügen dieser beiden Tabellen zu begrenzen, könnte der Kundentabelle eine zusätzliche Spalte hinzugefügt werden — der Ländername.
- Erstellen Sie eine neue Tabelle, die den Geschäftsanforderungen entspricht.
Nehmen wir an, dass häufig Daten aus mehreren Tabellen extrahiert werden müssen. Wenn die Geschäftsanforderungen richtig definiert sind, ist es möglich, eine Tabelle zu erstellen, die die Verarbeitungsgröße und den Zeitaufwand für regelmäßige Verknüpfungen reduziert. Kehren wir zum ersten Beispiel zurück. Angenommen, ein Unternehmen möchte regelmäßig Verkaufsdaten wie Kampagnen oder Werbetreibende mit vollständigen Namen extrahieren. Zu diesem Zweck ist es möglich, eine Tabelle zu erstellen, die alle erforderlichen Daten in der Verkaufstabelle enthält. In einer solchen Tabelle kann das Unternehmen die erforderlichen Daten abrufen, ohne regelmäßig mehrere Tabellen zusammenfügen zu müssen.
Wenn Sie wissen möchten, wie diese Lösungen Ihrem Unternehmen helfen können, kontaktiere uns.
Cloud backup dienste wie wahlt man die beste option aus
Der beste cloud speicher fur unternehmen im jahr 2021
Stream processing vs batch processing ein leitfaden
