Zunächst müssen wir die Frage klären, was SQL überhaupt ist. SQL steht für Sturctured Query Language und ist eine standardisierte Datenbankabfragesprache zur Abfrage und Manipulation von Daten in relationalen Datenbanken. Auf diese Definition möchte ich zu einem späteren Zeitpunkt noch einmal zurückkommen, um sie etwas ausführlicher zu erläutern. Wir stellen zunächst einmal fest, die Sprache dient dazu, Informationen aus relationalen Datenbanken zu gewinnen bzw. Daten in relationalen Datenbanken - im weitesten Sinne - zu verändern. Damit stellt sich die Frage „Was sind relationale Datenbanken?“.
Als Datenbank bezeichnen wir allgemein eine Sammlung von Daten, die in irgendeiner Form logisch zusammen gehören. Von einer relationalen Datenbank spricht man dann, wenn diese Daten durch ein relationales Datenbankverwaltungssystem (RDBMS) verwaltet werden. Microsoft Access ist ein solches relationales Datenbankmanagementsystem (RDBMS). Ein RDBMS speichert und verwaltet die Daten wiederum auf der Grundlage des relationalen Datenmodells. Um den Begriff „relationale Datenbank“ weiter zu konkretisieren, müssen wir erst einmal über das relationale Datenmodell sprechen.
Relationales Datenmodell
- Mathematiker Edgar F. Codd
- Forscher in den Entwicklungslabors der IBM in San Jose
- Veröffentlichung erster Ansätze 1969-1970
- alle Daten werden ausschließlich als Feldinhalte in Tabellen (Relationen) dargestellt
- es existieren keine dem Benutzer sichtbaren Verbindungen zwischen den Tabellen
- es muss eine Sprachschnittstelle mit einem relationalen Verarbeitungsspektrum zur Verfügung gestellt werden
Grundlage des Konzeptes relationaler Datenbanken ist die Relation. Dabei handelt es sich im Wesentlichen um eine mathematische Beschreibung für eine Tabelle. Operationen auf diesen Relationen werden durch die relationale Algebra bestimmt. Diese Operationen finden im Sprachumfang von SQL Berücksichtigung.
Ziel des relationalen Datenmodells
- Vermeidung redundanter Daten
- Vermeidung von Anomalien bei Speicheroperationen
- Nutzung der Daten durch verschiedene Applikationen
Datenredundanz
- das mehrmalige Festhalten desselben Faktums, d.h. ein und derselben Aussage
Werden solche Aussagen mehrfach in einer Datenbank festgehalten, so wird zunächst einmal mehr Speicherplatz benötigt. Darüber hinaus kann es vorkommen, dass die Beobachtung der Realität eine Änderung solcher Aussagen erzwingt. Wurden solche Aussagen mehrfach festgehalten, muss jede aufgefunden und geändert werden. Dies bedingt einen Mehraufwand und eine erhöhte Fehleranfälligkeit gegenüber der redundanzfreien Speicherung. Letztlich führen Datenredundanzen zu negativen Auswirkungen auf das Antwortzeitverhalten der Datenbank (Perfomance-Verlust). Dies soll später noch anhand eines Fallbeispiels erläutert werden.
Speicheranomalien
- Schwierigkeiten, die beim Einfügen, Ändern oder Löschen von Daten in der Datenbank auftreten
- Verletzung der Integrität (Richtigkeit)
- Relation entspricht nicht mehr den Realitätsbeobachtungen
An dieser Stelle möchte ich zunächst lediglich die Begriffsdefinition vorstellen. Auch dieses Problem soll anhand des Beispiels erörtert werden.
Tabellen
- Grundlage des relationalen Datenmodells
- Kollektionen von Werten, die in Reihen und Spalten angeordnet sind
- logische Datenstrukturen
- werden vom Datenbankmanagementsystem verwaltet
- besitzen Schlüssel
- stellen Objekte der realen Welt dar
Logische Datenstrukturen bedeutet, dass die tabellarische Darstellung der Daten unabhängig ist von der physischen Speicherungsform. Was Objekte der realen Welt sein können, soll im Folgenden dargestellt werden. Dasselbe gilt für die Notwendigkeit von „Schlüsseln“.
Entität
- Individuelles und identifizierbares Exemplar von Dingen, Personen oder Begriffen der realen oder Vorstellungswelt
- Individuum, reales Objekt, abstraktes Konzept oder Ereignis
- Eindeutig identifizierbare Einheit, für die Informationen gesammelt und auf Speichermedium festgehalten werden sollen
Objekte der realen Welt werden als Entitäten bezeichnet. Der Begriff der Entität ist jedoch so allumfassend und vielfältig, dass eine Definition wohl nicht möglich ist. Auf dieser Folie sind drei Umschreibungen dargestellt, die den Begriff verständlich machen sollen. In einer Tabelle sollen als mehrere Entitäten, also Entitätsmengen, festgehalten werden.
Entitätsmenge
- eindeutig benannte Kollektion von Entitäten gleichen Typs
- Entitäten, die aufgrund der gleichen Eigenschaften (nicht Eigenschaftswerte) charakterisiert werden können
Eine Tabelle im relationalen Datenmodell repräsentiert eine Entitätsmenge. In der Literatur wird gelegentlich darauf hingewiesen, dass Tabellen auch Beziehungsmengen beinhalten. Auf diesen Begriff werde ich im Zusammenhang mit der Normalisierungstheorie noch einmal zurückkommen. Eigenschaften sind beispielsweise der Name eines Kunden, sein Wohnort etc.. Eigenschaftswerte hingegen sind die konkreten Ausprägungen zu diesen Attributen, Beispiel: der Kunde mit der Kundennummer 1 hat den Namen „Meier“ und wohnt in „Düsseldorf“.1, Meier und Düsseldorf sind also Eigenschaftswerte.
Reihe, Zeile, Tupel
- logisch zusammgehörige Informationen
- enthält eine Entität mit ihren Eigenschaften
- unterteilt die Tabelle waagerecht
- entspricht einem Datensatz
- Reihenfolge ist unbestimmt
Spalte
- unterteilt die Tabelle senkrecht
- teilt die Reihe in Felder auf
- Aufteilung ist für jede Reihe gleich
- Werte in der Spalte sind vom selben Datentyp
- Reihenfolge wird beim Anlegen der Tabelle festgelegt
- besitzt Namen
Spaltenname
- Zugriff auf die Daten einer Spalte erfolgt über symbolischen Namen
- wird beim Anlegen der Tabelle zugewiesen
- muss innerhalb der Tabelle eindeutig sein
- soll Bedeutung der Information widerspiegeln
Wert
- Schnittpunkt von Reihe und Spalte
- Feld enthält genau einen skalaren Wert
- wird durch Daten repräsentiert
- keine Verweise
- keine Werteliste
- NULL
NULL-Wert
- <> 0, Leerzeichen oder leere Zeichenkette
- Ergebnis arithmetischer Operationen ist NULL
- nie gleich, kleiner oder größer als ein Vergleichswert
- Darstellung ist systemabhängig
Identifizierbare Einheiten
- Die Zeilen einer Tabelle müssen paarweise verschieden sein
- Es darf keine Zeilen geben, die miteinander identisch sind
Die Beschreibung des Begriffs Entität sagt aus, dass es sich um identifizierbare Einheiten handeln muss. Eine Zeile in einer Tabelle stellt eine Entität mit ihren Attributen dar. Daraus folgt, dass in einer Tabelle keine identischen Zeilen existieren dürfen. In einer Tabelle muss es also Spalten geben, die nur eindeutige Werte bzw. Wertekombinationen beinhalten. Solche Attribute bezeichnet man als Schlüssel.
Die meisten RDBMS‘e lassen das Einfügen identischer Zeilen in einer Tabelle zunächst zu. Die Eindeutigkeit der Werte in einer Spalte wird bei den meisten Systemen durch das Anlegen eines unique Index erzwungen. Exkurs: Ein Index ist eine geordnete Liste von Werten und Pointern, die den Zugriff auf die Daten beschleunigen. Unter Access kann beim Anlegen eines Index über die Feldeigenschaften festgelegt werden, ob Duplikate zugelassen oder ausgeschlossen werden sollen.
Schlüssel
- eindeutige Identifikation und Adressierbarkeit der Daten
- eine oder mehrere Spalten bilden den Primärschlüssel
- nur eindeutige Werte bzw. Wertekombinationen in den Primärschlüsselspalten
- Schlüsselkandidaten
- Fremdschlüssel
Die Festlegung von Spalten als Primärschlüssel unter Access impliziert auch das Anlegen eine unique Index.
Als Schlüsselkandidaten bezeichnet man weitere Attribute neben dem Primärschlüssel, die eine eindeutige Identifizierung einer Zeile in einer Tabelle ermöglichen.
Fremdschlüssel sind Attribute in einer Tabelle, die in einer anderen Tabelle die Funktion als Primärschlüssel besitzen. Die Beziehungen zwischen den Tabellen werden über die Dateninhalte der Primär- und Fremdschlüsselspalten zum Ausdruck gebracht. Diese ermöglichen auch, die Daten später wieder sinnvoll miteinander zu kombinieren. Dies soll im Zusammenhang mit den referentiellen Beziehungen noch einmal näher betrachtet werden.
Relationale Datenbank
- Sammlung logisch zusammengehöriger Tabellen
- Normalisierung
- referentielle Beziehungen
- referentielle Integrität
Aufgrund der bisherigen Aussagen können wir nun den Begriff der relationalen Datenbank weiter konkretisieren. Wir verstehen sie nun im Kontext des relationalen Datenmodells als eine Anordnung logisch zusammen gehörender Tabellen. Nun stellt sich die Frage, wie die Daten in einem möglicherweise unternehmensweiten Datenmodell auf die einzelnen Tabellen verteilt werden sollen. Mit dieser Frage setzt sich die Normalisierungstheorie auseinander. In diesem Zusammenhang müssen auch die Begriffe referentielle Beziehungen und referentielle Integrität etwas näher beleuchtet werden. Ich möchte nun einige Aspekte des Datenbankentwurfs an einem kleinen Beispiel verdeutlichen. Im Anschluss daran sollen die Begriffe noch einmal mit Hilfe dieser Präsentation dargestellt werden.
Gegeben sei ein Unternehmen bei dem Kunden verschiedene Artikel bestellen. Dieser Bestellvorgang soll nun in einer Datenbank erfasst werden.
Um in diesem Beispiel die Übersicht zu behalten, möchte ich mich auf wenige Daten wie den Kundennamen, seine Adresse, die Artikel, den Artikelpreis und die Anzahl der bestellten Artikel beschränken. Da es sich um eine überschaubare Anzahl von Attributen handelt, könnte man in Versuchung kommen, alle Merkmale in einer Tabelle abzulegen. Die Relation könnte wie folgt aussehen:
BESTELLUNG(B#, Name, Anschrift, Bestelldatum, Anzahl, Artikel, Preis)
Der Inhalt der Tabelle könnte nun wie folgt aussehen:
B# Name Anschrift Bestelldatum Anzahl Artikel Preis
Anne Ecke 40476 Düsseldorf, Mauerstr. 51 10.07.2007 3 CD 5,- €
B.Trug 42551 Velbert, Bahnhofstr. 1 15.07.2007 1, 1 CD, DVD 5,- €, 6,- €
Anne Theke 42549 Velbert, Thekbusch 50 20.07.2007 2, 2 DVD, MC 6,- €, 10,-€
Anne Ecke 40476 Düsseldorf, Mauerstr. 51 30.07.2007 1 CD 5,- €
Es fällt sofort auf, das verschiedene Informationen mit jeder Bestellung erneut gespeichert werden müssen. Es werden also dieselben Fakten mehrfach in der Datenbank festgehalten. Es handelt sich also um einen Fall von Datenredundanz mit den negativen Begleiterscheinungen, die ich bereits angesprochen hatte. Die Spalten Anzahl, Artikel und Preis enthalten Wiederholungsgruppen (Wertekollektive). Die Aussage beispielsweise, dass der Kunde B.Trug eine CD bestellt hat bzw. das ein Gebinde CD‘s 5 Euro kostet, ist aus diesem Datenmodell nicht zweifelsfrei ableitbar. Schwierigkeiten bereiten auch die Spalten Name und Anschrift. So ist beispielsweise nicht möglich, durch eine einfache Suchabfrage alle Kunden zu ermitteln, die in Velbert wohnen.
Einige Probleme können dadurch behoben werden, dass die Informationen soweit zerlegt werden, das in jeder Spalte nur noch elemetare Datenelemente abgelegt werden. Für die Spalten Name und Anschrift ist dies sicherlich unproblematisch. Für die Spalten Anzahl, Artikel und Preis hätte dies zur Folge, das sie in einzelnen Zeilen dargestellt werden müssen. Die Relation beschreibt in diesem Fall nicht mehr die Bestellung sondern die Bestellposition. Das hat auch zur Folge, dass die B# nicht mehr ausreicht, um eine Zeile eindeutig zur identifizieren. Diese Maßnahme bedingen außerdem, dass die Zahl der redundant gespeicherten Daten weiter zunimmt.
Nun existiert auch noch ein weiteres Problem. Nehmen wir an, die Bestellung mit der B# 3 ist abgearbeitet und wir möchten unsere Daten nach einer gewissen Frist bereinigen. Wir löschen also die entsprechenden Zeilen aus unserer Tabelle. Mit dieser Operation geht die Information, der Artikel MC kostet je Gebinde 10 Euro verloren. Damit wird unsere Relation in einen Zustand überführt, die den Realitätsbeobachtungen nicht mehr entspricht. In diesem Fall spricht man von den bereits genannten Speicheranomalien.
Es bietet sich an, die Daten auf mehrere Tabellen zu verteilen. Betrachten wir die Objekt der realen Welt für die wir Daten sammeln und auf Speichermedium festhalten wollen.
So kann man gewiss die Kundeninformationen in einer separaten Relation festhalten.
KUNDE(Name, Vorname, PLZ, Ort, Straße, Nr)
Nun besteht hier das Problem, das Müller, Meier und Schmitz in der Realität sicherlich häufiger vorkommen. Auch die weiteren Attribute dieser Relation sind nicht geeignet, einen Kunden eindeutig zu identifizieren. Deshalb muss auch hier ein künstlicher Schlüssel gebildet werden, z.B. K#.
KUNDE(K#, Name, Vorname, PLZ, Ort, Straße, Nr)
Ein weiteres Objekt der realen Welt, über das wir informationen Speichern wollen ist sicherlich der Artikel. Wird halten Informationen über Artikel ebenfalls in einer weiteren Relation fest. Auch in diesem Fall soll ein künstlicher Schlüssel gebildet werden, denn ein Artikel könnte in der Tabelle mehrfach auftreten, beispielsweise weil er von verschiedenen Lieferanten bezogen wird.
ARTIKEL(A#, Artikelbezeichnung, Preis)
Die Bestellpositionen werden wegen der o.a. Probleme ebenfalls in einer eigenen Tabelle abgebildet.
BESTPOS(B#, P#, A#, Anzahl)
Die Relation BESTELLUNG enthält nun nur noch folgende Attribute:
BESTELLUNG(B#, K#, Bestelldatum)
Normalisierungstheorie
- eine auf der Mengentheorie beruhende Sammlung von Schemata und Regeln zur Aufteilung und Verknüpfung von Tabellen
- sie beschreibt die Normalform einer Tabelle und den Weg zur idealen Tabellenstruktur
Wir haben gesehen, dass bereits ein paar logische Überlegungen zu einem akzeptablen Datenbankentwurf führen können. Bei komplexen Lebenssachverhalten, die beispielsweise in einem unternehmensweiten Datenmodell abgebildet werden müssen, ist jedoch ein systematisches Vorgehen erforderlich. Die Vorgehensweisen zu beschreiben würde den Rahmen dieses Lehrgangs sprengen. Es sei nur darauf hingewiesen, dass beim Datenbankentwurf i.d.R. die Normalisierungstheorie Berücksichtigung findet.
Ziel der Normalisierung
- Ermitteln von optimalen Datenstrukturen, die keine Möglichkeit bieten, einmal getroffene Annahmen der Realität zu verletzen
Rufen wir uns die Zielsetzung beim Datenbankentwurf noch einmal in Erinnerung. Die Normalisierungstheorie beschreibt fünf Normalformen einer Tabelle. In der Praxis können wir normalerweise von einer optimalen Datenstruktur ausgehen, wenn die Tabelle der 3. Normalform genügt. Aus diesem Grunde sollen die Normalformen kurz vorgestellt werden.
1. Normalform
- Eine Tabelle befindet sich in der ersten Normalform, wenn jede Eigenschaft elementar ist und sich weder aus nichtelementaren Attributen zusammensetzt noch Wiederholungsgruppen enthält
- Jedes Feld enthält nur skalare (atomare) oder elementare Eigenschaften
Wie sinnvoll es ist, dass eine Tabelle der ersten Normalform genügt, dürfte das Beispiel bewiesen haben.
2. Normalform
- Tabelle genügt der ersten Normalform und
- jede Nicht-Schlüsselspalte ist vollständig vom (gesamten) Primärschlüssel abhängig
- Tabellen sollen nur Daten zu einer Entitätsmenge beinhalten
- Entität soll vollständig durch den Primärschlüssel beschrieben sein
Es soll noch einmal das genannte Beispiel herangezogen werden. Hätten wir die Aufteilung in BESTELLUNGEN und BESTELLDETAILS unterlassen und nur den Primärschlüssel erweitert, wäre folgende Tabellenstruktur verblieben:
BESTELLUNG(B#, P#, K#, A#, Bestelldatum, Anzahl)
Die Attribute K#, A#, und Anzahl sind funktional vom gesamten Primärschlüssel (also der Kombination aus B# und P#) abhängig. Das Attribut Bestelldatum hängt jedoch funktional nur vom Schlüsselteil B# ab. Insofern läge ein Verstoß gegen die 2. Normalform vor.
3. Normalform
- Tabelle genügt der 2. Normalform und
- alle Nicht-Schlüsselattribute sind voneinander funktional unabhängig
- -keine transitiven Abhängigkeiten
Im folgenden Beispiel genügt die Relation zwar der 2. Normalform, die Speicherungsform ist dennoch nicht optimal. Beispiel: Es existiert ein Messsystem, mit dem Schadstoffdaten in der Umwelt gemessen und erfasst werden. Die Messergebnisse sollen in einer Datenbank festgehalten werden. Unter anderem sollen Informationen über die Messstelle in einer Tabelle festgehalten werden. Dabei handelt es sich um die Messstellennummer, Angaben zur Lage der Messstelle wie die Gemeindekennziffer, die Ortsbezeichnung der Gemeinde, die Gauß-Krüger-Koordinaten (Rechtswert und Hochwert) sowie das Datum der Inbetriebnahme und das Datum der Außerbetriebnahme.
MESSSTELLE(MS#, GKZ, ORT, RW ,HW, VON, BIS,)
In diesem Beispiel besteht eine solche transitive, d.h. indirekte Abhängigkeit zwischen den Attributen GKZ und Ort. Das Attribut Ort ist genau genommen nicht funktional abhängig von der MS#, sondern von der Gemeindekennziffer. Die Tabelle genügt nicht der 3. Normalform. Diese Relation beschreibt also nicht nur eine Entitätsmenge. Außerdem werden hier die Daten redundant gespeichert. Für jede Messtelle in Düsseldorf wird in diesem Fall die Aussage „der Ort mit der Gemeindekennziffer 05111000 trägt die Ortsbezeichnung Düsseldorf“ festgehalten.
Die Lösung für die Probleme besteht in einer Aufteilung der Daten auf zwei Tabellen:
MESSSTELLE(MS#, GKZ, RW ,HW, VON, BIS,)
GEMEINDE(GKZ, ORT)
4. Normalform
- Tabelle genügt der 3. Normalform und
- weist keine paarweise auftretenden mehrwertigen Abhängigkeiten auf
Nun ist es möglich Relationen zu kreieren, welche die 3. Normalform respektieren, aber trotzdem zu Problemen Anlass geben. Die Definition der 4. und 5. Normalform wird lediglich der Vollständigkeit halber angegeben, da sie in der Praxis kaum von Bedeutung ist und eine eingehende Erläuterung aus Zeitgründen nicht möglich ist.
5. Normalform
Eine Tabelle ist in der 5. Normalform, wenn sie unter keinen Umständen aufgrund einer Verschmelzung einfacherer Relationen mit unterschiedlichen Schlüsseln konstruiert werden kann.
Referentielle Beziehungen
Beziehungen zwischen Tabellen werden über Datenwerte hergestellt
Master- / Detailtabelle
Kardinalitäten
- 1:1
- 1:n
- n:m
Aus den bisherigen Beispielen lässt sich also ableiten
- Die Tabellen in einer relationalen Datenbank stehen miteinander in Beziehung.
- Die Beziehungen zwischen den Tabellen werden über die Datenwerte in den Primär-/Fremdschlüsselspalten abgebildet.
- Die Tabellen mit den Fremdschlüsseln enthalten Details zu den Entitäten, die über die Fremdschlüssel referenziert werden. Die Tabellen mit den Fremdschlüsseln werden demzufolge als Detailtabelle (Childtable) bezeichnet. Die Tabelle mit den zugeordneten Primärschlüsseln bezeichnet man analog als Mastertabelle (Parenttable).
Betrachten wir die Beziehungen zwischen den Tabellen näher:
Die Kardinalität beschreibt in der Datenbanktechnik die Komplexität oder den Grad einer Beziehung (engl: Relationship) zwischen zwei Entitätstypen in einem Entity-Relationship-Diagramm (ER-Diagramm). D.h. die Kardinalität eines Beziehungstyps (Relationship-Typs) gibt an, mit wie vielen anderen Entitäten eine Entität eines bestimmten Entitätstyps in einer konkreten Beziehung stehen muss bzw. kann.
1:1-Beziehung
- zu jedem Datensatz in einer Tabelle gibt es genau einen Datensatz in einer anderen Tabelle
- eine Entität des einen Entitätstyps steht mit höchstens einer Entität des anderen Entitätstyps in Beziehung und umgekehrt
In der Literatur findet man beide Definitionen, wobei ich der ersten den Vorzug gebe. Legt man diese zugrunde, gibt es kaum Gründe, die Daten auf mehrere Tabellen aufzuteilen. Wenn jede Zeile der einen Tabelle mit genau einem Satz der anderen Tabelle korrespondiert, kann man sie genau so gut in einer Tabelle zusammenfassen. Ein Grund sie dennoch aufzuteilen, sind Restriktionen aufgrund des ausgewählten RDBMS. So kann beispielsweise das DBMS nur eine bestimmte Zahl von Spalten in einer Tabelle verwalten. Handelt es sich um eine Entität mit einer größeren Anzahl von Attributen, ist man gezwungen, diese auf mehrere Tabellen zu verteilen (Beispiel Kläranlagenkataster).
Legt man die zweite Definition zugrunde ist denkbar, dass Attribute nur für bestimmte Kategorien der betrachteten Entität vorliegen. Würde man sie in einer Tabelle zusammenfassen, blieben viele Datenfelder bei allen anderen Kategorien leer. In diesem Fall bietet sich die Aufteilung an. Die gemeinsamen Attribute könnten in einer Tabelle abgebildet werden, während die speziellen Attribute der betroffenen Kategorien in einer weiteren Tabelle gespeichert würden.
1:n-Beziehung
- ein Datensatz in einer Tabelle ist mit einem, keinem oder mehreren Datensätzen in einer anderen Tabelle verknüpft
n:m-Beziehung
- ein Datensatz in einer Tabelle-1 ist mit einem, keinem oder mehreren Datensätzen in einer Tabelle-2 verknüpft
- ein Datensatz in der Tabelle-2 ist mit einem, keinem oder mehreren Datensätzen in der Tabelle-1 verknüpft
Erweitern wir das Beispiel noch einmal. Nehmen wir an, dass ein Artikel tatsächlich von mehreren Lieferanten geliefert werden könnte, wobei ein Lieferant i.d.R. mehrere Artikel liefert. Nehmen wir weiter an, dass die Informationen über Lieferanten ebenfalls in unserer Datenbank festgehalten werden sollen. Es existieren also folgende Tabellen
ARTIKEL(A#, Bezeichnung, Preis, Bestellnr)
LIEFERANT(L#, Firma, PLZ, Ort, Straße, ...)
Die RDBMS unterstützen diese n:m Beziehung nicht. Um diesen Sachverhalt in der Datenbank abzubilden, muss noch eine zusätzliche Tabelle eingefügt werden. Um darzustellen, dass ein Artikel von einem bestimmten Lieferanten bezogen wird, enthält diese Tabelle nun die Zuordnung von A# zu L#. Die Beziehung zwischen den Tabellen ARTIKEL und LIEFERANT wird nun über diese zusätzliche Tabelle dargestellt, welche die n:m Beziehung in 1:n Beziehungen zwischen ARTIKEL und ARTLIEF und LIEFERANT und ARTLIEF auflöst.
ARTLIEF(A#, L#)
In diesem Fall wird in der Literatur auch von Beziehungsmengen gesprochen. Der Primärschlüssel dieser Tabelle setzt sich nun aus den Primärschlüsseln der Artikel und Lieferantentabelle zusammen. In der Praxis werden i.d.R. noch weitere Attribute in dieser Relation festgehalten (z.B. Rabattsatz etc.). Diese werden auch als Beziehungsattribute bezeichnet.
Referentielle Integrität
Werte für Fremdschlüssel in einer Detailtabelle können nur gespeichert und verwendet werden, wenn ein entsprechender Eintrag in den Primärschlüsselspalten der Mastertabelle existiert
Regeln für das Löschen von Primärschlüsseln in der Mastertabelle, solange noch entsprechende Fremdschlüssel in der Detailtabelle existieren
- restricted
- cascade
- set null
Damit die Datenbank die Realität korrekt abbildet, muss auch die Richtigkeit der Beziehungen zwischen den Tabellen sichergestellt werden. Dabei geht es darum, dass keine verwaisten Zeilen in den abhängigen Tabellen auftreten können. Das bedeutet, dass zu jeder Zeile in einer Detailtabelle auch eine korrespondierende Zeile in der Mastertabelle existieren muss.
Die RDBMS‘e stellen zur Sicherstellung der referentiellen Integrität enstprechende Funktionen zur Verfügung, d. h. man kann in der Datenbank entsprechende Integritätsregeln hinterlegen.
Keine Kommentare:
Kommentar veröffentlichen