Integritätsregeln

Über Redundanz von Daten in Relationen
1. Normalform einer Relation

Weitere Redundanzen
2. Normalform einer Relation

« Integritätsregeln

Beim Bearbeiten der Daten geht der Benutzer von bestimmten Gesetzen aus, die für Daten gelten. Geburtsdaten von Mitarbeitern werden mit Sicherheit nicht aus dem 18. Jahrhundert stammen.

Integrität von Daten bedeutet eine Zusicherung über die Art der Datenspeicherung.


• Übersicht Integritätsregeln
  
  
  
  
• Anwendungsspezifische Integritätsregeln:
  Beispiele:
  • Kein Mitarbeiter verdient unter 400€ im Monat.
  • Das Eintrittsdatum eines Mitarbeiters in die Firma muss später als sein Geburtsdatum sein.
  • Telefonnummern enthalten grundsätzlich einen Schrägstrich (Slash).
  Diese Regeln müssen auf der Ebene der Benutzersichten überprüft werden, d.h. nach dem Bearbeiten eines Formulars und vor der Weitergabe der Daten in die logische Ebene.
• Strukturelle Integritätsregeln:
  • Schlüssel-Integrität: Eine Datenbank garantiert, dass jede Relation einen Primärschlüssel besitzt und dass jeder Primärschlüssel genau einen Datensatz identifiziert.
  • Referentielle-Integrität: Eine Datenbank garantiert, dass jeder Fremdschlüssel genua einen Datensatz identifiziert.
  Diese Regeln werden im allgemeinen von einem Datenbankmanagementsystem übernommen.

« Über Redundanz von Daten in Tabellen

Betrachten wir uns nochmals die Relation "Pizza" aus unserem Projekt:


Pizza	Name	Zutaten	Preis
	Margherita	Tomaten, Käse	4.10
	Salami	Tomaten, Käse, Salami	5.20
	Funghi	Tomaten, Käse, Champignon	5.20
	Hawai	Tomaten, Käse, Vorderschinken, Ananas	5.70
	Quattro Stagioni	Tomaten, Käse, Champignon, Vorderschinken, Salami, Peperoni	6.20

Das System, nach dem die Zutaten gespeichert sind hat einige Nachteile:
• Will man etwas an den Zutaten ändern, (z.B. aufgrund der Rechtschreibreform) so muss man mühsam Datensatz für Datensatz durchgehen.
• "Tomaten", "Käse", oder "Champignons" sind mehrfach gespeichert. (Verschwendung von Speicherplatz)
• Angenommen, jemand möchte den Preis pro Kilogramm mit den Zutaten abspeichern, wo soll das geschehen? (Schlechte Erweiterbarkeit)

Daher macht es mehr Sinn, dass eine Datenspalte nur ein Objekt enthalten darf. Dies bedeutet in unserem Fall aber eine neue Definition des ER-Diagramms:



Die Zutaten wurden als eigene Entität modelliert und damit sind alle oben angesprochenen Nachteile beseitigt. Die zugehörigen Relationen enthalten keine Mehrfachnennungen mehr:

• Bestellung{Datum, Uhrzeit}
• Angestellter{ID, Name, Adresse, Telefon, Gehalt}
• Kunde{ID, Name, Adresse, Telefon}
• Pizza{Name, Preis}
• Zutaten{Name}
• gibt ab{Bestellung.Uhrzeit,Bestellung.Datum,Kunde.ID}
• nimmt auf{Bestellung.Uhrzeit,Bestellung.Datum,Angestellter.ID}
• bäckt{Angestellter.ID,Pizza.Name}
• fährt aus{Angestellter.ID,Pizza.Name}
• erhält{Kunde.ID,Pizza.Name}
• enthält{Bestellung.Uhrzeit,Bestellung.Datum,Pizza.Name}
• enthält{Pizza.Name,Zutaten.Name}

« 1. Normalform

• Eine Relation befindet sich in 1. Normalform, wenn jede Spalte nur atomare (nicht weiter zerlegbare) Elemente enthält.


Aus oben genannten Gründen sind Datenbanken grundsätzlich in 1. Normalform zu erstellen.

« Weitere Redundanzen

Angenommen, der Pizzaservice will die Autos (Fahrzeugnr., Typ, Kilometerstand) mit in das Datenmodell aufnehmen. Da jeder Fahrer ein bestimmtes Auto (zwei in unterschiedlichen Schichten aber dasselbe) fährt, könnte man eine Tabelle folgender Art konstruieren:

Angestellter	ID	Name	Fahrzeugnr.	Fahrzeugtyp	Kilometerstand
	23	Maier	A34729384	Opel Corsa	67430
	3	Müller	V8347-1111	VW Polo	32165
	11	Valerius
	17	Walker	A34729384	Opel Corsa	67430

Die anderen Attribute des Angestellten wurden aus Übersichtlichkeitsgründen weggelassen.
"Valerius" ist kein Fahrer, deshalb hat er keine Autodaten in seinem Datensatz.

Aus dieser Tabelle, die die 1. Normalform erfüllt lassen sich weitere Nachteile ablesen:
• Update-Anomalie:
  Nach mehreren Fahrten hat sich der Kilometerstand des Corsa geändert. Wenn man nicht genau aufpasst, dann kann es sein, dass man nicht alle Datensätze geändert hat und man erhält inkonsistente Daten (Maier mit anderem Kilometerstand als Walker).
• Einfüge-Anomalie:
  Wo wird ein Auto eingetragen, dass noch keinen Fahrer hat?
• Lösch-Anomalie:
  Angenommen, Müller verlässt die Firma, dann müsste sein Datensatz gelöscht werden. Ist dann auch der VW Polo verloren?

« 2. Normalform

Die beschriebenen Probleme ergeben sich dadurch, dass bestimmte Attribute nicht mehr vom Primärschlüssel abhängen. Der "Corsa" wird z.B. nicht eindeutig durch "Walker" identifiziert.


• Eine Relation ist in 2. Normalform, wenn jedes Attribut eindeutig vom Primärschlüssel identifiziert wird.

Auch in diesem Fall bietet es sich an, die Autos als eigene Entität zu definieren.