Relationale Entwurfstheorie und Normaliesierungen

In diesem Beitrag geht es um die relationale Entwurfstheorie und die Normalisierung von Datenbankschemen. Ziel ist es, aus einer ungeordneten Datenbank, eine geordnete und konsistentere Datenbank zu machen.

Funktionale Abhängigkeit

Eine funktionale Abhängigkeit ist z.B. wenn man Adresse & Wohneinheit kennt. Man weiß also somit auch, wer der Mieter von dem Objekt ist. X bestimmt Y also funktional. Das nennt sich funktionale Abhängigkeit.

Außerdem gibt es noch eine partielle Abhängigkeit. Dies ist gegeben, wenn mehr Attribute angegeben sind, als eigentlich zur Identifikation nötig gewesen wären. Um das am Beispiel oben zu belegen, könnte man noch das Attribut „Bundesland“ hinzufügen, welches wir aber auch problemlos weglassen könnten und trotzdem das selbe Ergebnis erzielen würden.

Es gibt auch voll funktionale Abhängigkeit. Das ist der Fall, wenn alle gegebenen Attribute benötigt werden und nichts für die Identifikation weg gelassen werden darf.

Superschlüssel

Der Superschlüssel definiert andere Wertepaare/Tupel. Es gibt nur einen Satz an Schlüsseln, welchen zu einem Superschlüssel passt. Zur Identifikation können Attribute weggelassen werden. Superschlüssel ist eine Ansammlung von Attribute und besteht somit aus mehreren Attributen.

Ein Kandidatenschlüssel hingegen ist ein Schlüssel, der minimal ist. Es dürfen keine Attribute des Schlüssels weg gelassen werden um den Datensatz eindeutig bestimmen zu können.

Der Primärschlüssel besteht aus einem Attribut und ist eindeutig auf einen Datensatz beziehbar.

Hüllen

Eine Hülle beinhaltet alles was man aus Attributen folgern kann. Auch die Verknüpfungen folgen danach. Die Attributhülle gibt also an, welche Dinge man aus seinen Attributen folgern kann.

Das Hauptziel ist es, feststellen zu können, mit welchen Attributen ich welche Attribute herausfinden kann und von welchen Attributen ich auch welche Attribute schließen kann. Also die Abhängigkeiten der Attribute voneinander.

Schlechtes Relationsschema

Ein schlechtes Relationsschema liegt vor, wenn z.B. ein und dieselbe Information doppelt in der Datenbank gespeichert wurde. Eine weiteres Anzeichen für ein schlechtes Relationsschema sind Anomalien. Anomalien entstehen z.B. beim Löschen von Datensätzen. Dazu im nächsten Absatz mehr.

Anomalien

Es können folgende Anomalien in einer Datenbank enstehen:

Änderungsanomalie -> Wenn Daten öfters gespeichert sind, müssen alle Attribute geändert werden. Es können Fehler entstehen. (z.B. Name muss geändert werden)

Einfügeanomalie -> Es können beim Einfügen in eine Tabelle „(null)“ Elemente entstehen, falls Attribute nicht vorhanden bzw leer bleiben, weil keine Daten vorhanden sind. Ursachen -> Wenn in einer Tabelle mehrere Entities modelliert sind.

Löschanomalie -> Es entsteht Datenverlust beim löschen. Wenn mehrere Entities zusammengefasst sind können Daten verloren gehen. (Wenn z.B. ein Arzt gelöscht wird der in der selben Tabelle auch Terminen zugeordnet ist => Wird der Arzt gelöscht ist auch der Termin weg.)

Idee: Schema so ändern, das die Informationen sicher gespeichert sind. Dies erreichen wir durch eine Verteilung auf mehrere Entities/Tabellen. Ziel ist es, die Anomalien zu vermeiden aber trotzdem die funktionalen Abhängigkeiten zu erhalten.

Lösungsansatz; Normalformen/Normalisierung von Relationen

Dazu gibt es drei Stufen der Dekomposition/Normalform:

  1. In einem Attribut darf maximal nur ein Wert stehen.
  2. Aufsplitten der „schlechten“ Tabelle in mehrere Tabellen und Beziehungen. (Alle Attribute werden zur Identifikation benötigt)
  3. Es werden quasi Daten ausgelagert. Z.B. wird eine BLZ angegeben und in einer zweiten Tabelle die Bankleitzahl einem Banknamen zugeordnet.

Die Normalformen werden alle nacheinander ausgeführt um die Datenbank zu sortieren. Dieser Vorgang nennt sich Dekomposition. Alle Normalisierung enthalten die Normalisierung da drüber. (Also: N3 enthält N1 & N2 und N2 enthält N1.)

Marvin Sengera

Marvin Sengera

Hey! Ich bin Marvin Sengera, Inhaber der Internetagentur "Binärfabrik" aus Paderborn. Ich habe mein Bachelorstudium Informatik mit Schwerpunkt Industriespionage an der Hochschule Hamm Lippstadt abgeschlossen und absolviere derzeit meinen Master in Fachrichtung "Technical Entrepreneurship and Innovation". Ich beschäftige mich rund um die Themen Informatik, Innovation & Unternehmensgründung.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.