Quelltext der Seite Anomalie (Informatik)

In der [[Informatik]] bezeichnen '''Anomalien''' in [[Relationale Datenbank|relationalen Datenbanken]] Fehlverhalten der Datenbank durch ungünstige Umstände. Es handelt sich um unerwünschtes Verhalten, i.&nbsp;d.&nbsp;R. liegt aber kein [[Programmfehler]] in der Datenbank vor. Man unterscheidet zwischen Anomalien im Einbenutzerbetrieb und Mehrbenutzerbetrieb.

Im Einbenutzerbetrieb können Anomalien durch nicht [[Normalisierung (Datenbank)|normalisierte]] bzw. [[Denormalisierung|denormalisierte]] Datenstrukturen entstehen und führen zu [[Konsistenz (Datenspeicherung)#Konsistenz in klassischen relationalen Datenbanken|Inkonsistenzen]]. Man unterscheidet '''Einfüge-''', '''Änderungs-''' und '''Lösch-Anomalien'''.

Im Mehrbenutzerbetrieb einer Datenbank treten Anomalien durch unzulässigen parallelen Datenbankzugriff auf.
__TOC__

== Anomalien im Einbenutzerbetrieb ==

=== Einfüge-Anomalie ===

Beim Einfügen von Daten in eine Datenbank spricht man von einer '''Einfüge-Anomalie''' (Insertion-Anomalie), wenn ein neues [[Tupel (Informatik)|Tupel]] in die Relation nicht oder nur schwierig eingetragen werden kann, weil nicht zu allen Attributen (Spaltenüberschrift) des [[Schlüssel (Datenbank)|Primärschlüssels]] Werte vorliegen (was Voraussetzung ist, um einen Datensatz eintragen zu können). So können beispielsweise Informationen nicht aufgenommen werden, da andere, in diesem Zusammenhang uninteressante bzw. diesem Zeitpunkt unbekannte Angaben fehlen.

'''Beispiel:'''

In dieser Tabelle wird für Fahrzeuge der jeweilige Fahrer angegeben. Die Attribute (Kennzeichen, Nachname) seien [[Schlüssel (Informatik)|Identifikationsschlüssel]]. Hier treten Einfügeanomalien auf, wenn ein neues Fahrzeug eingefügt werden soll, aber noch kein Fahrer bestimmt wurde.<br />
Das Einfügen von Datensätzen ohne den Schlüssel (oder einen Teil des Schlüssels) ist unmöglich.

{| class="wikitable"
 !Kennzeichen
 !Hersteller
 !Vorname
 !Nachname
 |-
 |K-KJ 321
 |VW
 |Peter
 |Schmidt
 |-
 |CW-CD 29
 |Audi
 |Chayenne
 |Müller
 |-
 |FDS-MG 113
 |BMW
 |Marie
 |Maier
 |-
 |B-MD 321
 |BMW
 |Tom
 |Lehmann
 |-
 |A-BC 123
 |Škoda
 | ?
 | ?
 |-
 |A-BC 456
 |Škoda
 | ?
 | ?
|}

=== Änderungs-Anomalie ===

Beim Ändern von Daten in einer [[Datenbank]] spricht man von einer '''Änderungs-Anomalie''' (Update-Anomalie), wenn nicht alle ([[Redundanz (Informationstheorie)|redundanten]]) Vorkommen eines [[Attributwertes (Informatik)|Attributwertes]] zugleich geändert werden. Dieses führt zu [[Konsistenz (Datenspeicherung)#Konsistenz in klassischen relationalen Datenbanken|inkonsistenten]] Daten.

'''Beispiel:'''

{| class="wikitable"
 !Kennzeichen
 !Hersteller
 !Farbe
 !Vorname
 !Nachname
 |-
 |K-KJ 321
 |VW
 |Blau
 |Peter
 |Schmidt
 |-
 |H-CH 333
 |Opel
 |Rot
 |Fritz
 |Schneider
 |-
 |B-MD 321
 |BMW
 |Schwarz
 |Max
 |Maier
 |-
 |B-MM 473
 |Peugeot
 |Grün
 |Max
 |Maier
 |}

Es wird in dieser Tabelle davon ausgegangen, dass die Erwähnungen von „Max Maier“ für ein und dieselbe Person gelten. Wird der Name „Maier“ in „Meier“ geändert, muss dieses an zwei Stellen geschehen. Geschieht dieses nicht, spricht man von einer Update-Anomalie. Die Tabelle enthält nun [[Konsistenz (Datenspeicherung)#Konsistenz in klassischen relationalen Datenbanken|inkonsistente]] Daten.

Um dieses Problem zu verhindern, sollte die Tabelle in die 3. [[Normalisierung (Datenbank)|Normalform]] überführt werden, um die Fahrerdaten losgelöst von den Fahrzeugdaten betrachten zu können.

'''Beispiel in 3. Normalform:'''
{| border="0"
| valign="top" |
{| class="wikitable"
 |+'''Fahrzeug'''
 !Kennzeichen
 !Hersteller
 !Farbe
 !Fahrer_ID
 |-
 |K-KJ 321
 |VW
 |Blau
 |318
 |-
 |H-CH 333
 |Opel
 |Rot
 |37
 |-
 |B-MD 321
 |BMW
 |Schwarz
 |93
 |-
 |B-MM 473
 |Peugeot
 |Grün
 |93
 |}
| valign="top" |
{| class="wikitable"
 |+'''Fahrer'''
 !Fahrer_ID
 !Vorname
 !Nachname
 |-
 |318
 |Peter
 |Schmidt
 |-
 |37
 |Fritz
 |Schneider
 |-
 |93
 |Max
 |Maier
 |}
|}
Weil Fahrer_ID in der Tabelle "Fahrzeug" als Fremdschlüssel aus der Tabelle "Fahrer" eingesetzt wird, tritt die Update-Anomalie nicht mehr auf. Die Daten werden nun an zentraler Stelle und nicht mehr redundant abgelegt.

=== Lösch-Anomalie ===

Eine '''Lösch-Anomalie''' (''Delete-Anomalie'') entsteht, wenn durch das Löschen eines [[Datensatz]]es mehr Informationen als erwünscht verloren gehen. Sie entsteht, wenn ein Datensatz mehrere unabhängige Informationen enthält. Durch das Löschen der einen Information wird dann auch die andere gelöscht, obwohl diese noch benötigt wird.

'''Beispiel:'''

{| class="wikitable"
 !Kennzeichen
 !Hersteller
 !Farbe
 !Vorname
 !Nachname
 |-
 |K-KJ 321
 |VW
 |Blau
 |Peter
 |Schmidt
 |-
 |H-CH 333
 |Opel
 |Rot
 |Fritz
 |Schneider
 |-
 |B-MD 321
 |BMW
 |Schwarz
 |Max
 |Maier
 |}

Hier kann das Fahrzeug B-MD 321 nicht gelöscht werden, ohne den Fahrer ebenfalls zu löschen.

Um das Problem zu vermeiden, muss die Tabelle in die [[Normalisierung (Datenbank)#Dritte Normalform (3NF)|3. Normalform]] überführt werden.

'''Beispiel in 3. Normalform:'''
{| border="0"
| valign="top" |
{| class="wikitable"
|+'''Fahrzeug'''
!Kennzeichen
!Hersteller
!Farbe
!Fahrer_ID
|-
|K-KJ 321
|VW
|Blau
|318
|-
|H-CH 333
|Opel
|Rot
|37
|-
|B-MD 321
|BMW
|Schwarz
|93
|}
| valign="top" |
{| class="wikitable"
|+'''Fahrer'''
!Fahrer_ID
!Vorname
!Nachname
|-
|318
|Peter
|Schmidt
|-
|37
|Fritz
|Schneider
|-
|93
|Max
|Maier
|-
|}
|}

== Anomalien im Mehrbenutzerbetrieb ==
Im Mehrbenutzerbetrieb einer Datenbank treten Anomalien durch unzulässigen parallelen Datenbankzugriff auf. Man unterscheidet grob in vier Grundprobleme: Verlorenes Update, Schreib-Lese-Konflikt, Nichtwiederholbares Lesen und Phantomproblem. Es sind jedoch noch weitere feinere Unterscheidungen und Spezifikationen möglich.<ref>Theo Härder und Erhard Rahm: ''Datenbanksysteme, Konzepte und Techniken der Implementierung'', 2. Auflage (2001), Seite 408ff, Teil V (Transaktionsverwaltung), Kap 14 (Synchronisation), Abschnitt 14.1. (Anomalien im Mehrbenutzerbetrieb)</ref>

=== Verlorenes Update (Lost update) ===
Ein [[Verlorenes Update]] (engl. Lost Update) bezeichnet ein Problem, das auftritt, wenn mehrere parallele Schreibzugriffe auf eine gemeinsam genutzte Information auftreten können. Wenn zwei Transaktionen dieselbe Information verändern, dann können die Änderungen der ersten sofort durch die Änderungen der zweiten überschrieben werden.

=== Schreib-Lese-Konflikt (Dirty Read) ===
Ein [[Schreib-Lese-Konflikt]] (engl. Dirty Read) bezeichnet ein Problem, das auftritt, wenn von zwei gleichzeitig ablaufenden [[Transaktion (Informatik)|Transaktionen]] die eine Daten liest, die von der anderen geschrieben werden, jedoch noch nicht bestätigt (committed) sind.

=== Nichtwiederholbares Lesen (Non-Repeatable Read) ===
Ein [[Nichtwiederholbares Lesen]] (engl. Non-Repeatable Read) bezeichnet ein Problem, das auftritt, wenn innerhalb einer Transaktion dieselbe Leseoperation nacheinander unterschiedliche Ergebnisse liefert.

=== Phantomproblem (Inconsistent Read) ===
Ein [[Phantomproblem]] (inconsistent read) bezeichnet ein Problem, das bei mehreren parallelen Datenbankzugriffen auftreten kann. Werden während einer Transaktion, die sich auf mehrere Datensätze mit einer angegebenen Eigenschaft bezieht, in einer gleichzeitig ablaufenden Transaktion neue Datensätze mit dieser Eigenschaft eingefügt, kann dies inkonsistente Daten der ersten Transaktion zur Folge haben.

== Literatur ==
* {{Literatur | Autor=Theo Härder, Erhard Rahm | Titel=Datenbanksysteme, Konzepte und Techniken der Implementierung | Verlag=[[Springer Nature|Springer]] | Ort=Berlin | Jahr=2001 | ISBN=3-540-42133-5}}

== Weblinks ==
* [https://weichselbraun.net/dbs/p/exercise/normalformen/RelTheorie_Uebung_Loesung.pdf AIFB Institut für Angewandte Informatik und Formale Beschreibungsverfahren Datenbanksysteme Übungsblatt 1]

== Einzelnachweise ==
<references />

[[Kategorie:Datenbankmodellierung]]
[[Kategorie:Datenbanktheorie]]