1 Relationale Datenbanken (DB): Das Relationenmodell
Transcription
1 Relationale Datenbanken (DB): Das Relationenmodell
1 Relationale Datenbanken (DB): Das Relationenmodell [eine Zusammenfassung von Christian Rausch nach Schicker: „Datenbanken und SQL“, 1999] Vereinfacht ausgedrückt bestehen relationale Datenbanken aus Tabellen, in denen Daten gespeichert sind. Üblicherweise stehen die Tabellen in Beziehungen zueinander, d. h. manche Einträge sind Verweise auf andere Einträge in anderen Tabellen. Wichtige Anforderungen an eine Datenbank: geringe Redundanz, gleiche Daten sind möglichst nicht an mehreren Stellen gleichzeitig abgelegt. Dadurch bleibt die DB übersichtlicher, Updates der Daten werden erleichtert, Speicherplatz wird gespart. Daten sind übersichtlich abgelegt, Abfragen sind einfach. gute Handhabbarkeit, einfache Zugriffe über möglichst wenige Tabellen Sicherstellung von Konsistenz und Integrität Datenbeziehungen bleiben in sich logisch und stimmig. Keine Gefahr von Datenverlust z. B. bei Updates oder Löschungen. 1.1 Beispiel zu relationalen Datenbanken Negativbeispiel: Datenbanktabelle VerkaeferProdukt (Tab. 1): Tab. 1 VerkaeferProdukt Verk_Nr Verk_Name V1 Meier V1 Meier V1 Meier V2 Schneider V2 Schneider V3 Müller PLZ 80075 80075 80075 70038 70038 10183 Verk_Adresse München München München Stuttgart Stuttgart Berlin Produktname Waschmaschine Herd Kühlschrank Herd Kühlschrank Staubsauger Umsatz 11000 5000 1000 4000 3000 1000 Zu jedem Verkäufer ist dessen Nummer und Name (Verk_Nr und Verk_Name), PLZ und Stadt seiner Adresse (PLZ und Verk_Adresse), der Name der von ihm verkauften Produkte (Produktname) und der Umsatz angegeben. Nachteile obiger Tabelle: Redundanzen: Name, PLZ und die Adresse der Verkäufer kommen mehrfach vor. Unbequeme Handhabbarkeit: ändert ein beliebiger Verkäufer seine Adresse, so ist eine variable Anzahl von Adresseinträgen zu ändern. Falls nicht alle Adresseinträge geändert werden, so besteht die Gefahr von Inkonsistenzen. Redundanz ist immer eine Gefahrenquelle für Fehler und Inkonsistenzen. Falls die Firma den Artikel Staubsauger aus dem Programm nimmt, so können nicht einfach die 1/13 Zeilen, die den Produktnamen Staubsauger enthalten, entfernt werden, da sonst auch alle Informationen zu Verkäufer Müller aus der Datenbank entfernt werden! E. F. Codd untersuchte ab 1970 den optimalen Aufbau von Tabellen und legte die Grundlage zu mathematisch-fundierten Theorien (relationale Algebra, Relationenkalül, Normalformenlehre). Es wurde theoretisch belegt, dass Tabellen so aufgebaut werden können, dass sowohl Redundanzen in den Daten vermieden als auch Einzeldaten isoliert gelöscht werden können. 1.2 Relationale Datenstrukturen Übersicht Entsprechung der formalen relationalen Ausdrücke mit mehr informellen alltäglichen Ausdrücken: Tab. 2 Formale relationale Ausdrücke Relation Tupel Kardinalität Attribut Grad Primärschlüssel Gebiet Informelle Ausdrucksweise Tabelle eine Zeile (Reihe) einer Tabelle Anzahl der Zeilen einer Tabelle eine Spalte (Feld) einer Tabelle Anzahl der Spalten einer Tabelle eindeutiger Bezeichner einer Zeile (eines Tupels) Menge aller möglichen Werte L# Lname Stadt PLZ L1 Müller München 81724 Schmidt Regensburg 93055 L3 Maier Hamburg 20543 L4 Schwarz Köln 50087 L5 Weiß Berlin 11168 Relation L2 Kopf(zeile) Rumpf Tupel Attribute Grad Abb. 1 Relationale Begriffe am Beispiel: L1-L5 Primärschlüssel; die Kardinalität ist die Zeilenzahl (=Tupelzahl) Der Kopf besteht aus einer festen Anzahl von Attributen: {(A1; D1), (A2; D2), ... , (An; Dn)}, wobei jedes Attribut Ai genau mit einem Gebiet korrespondiert (1 i n) Der Rumpf besteht aus einer variablen Anzahl von Tupeln. 2/13 Der Grad einer Relation R (d. h. die Spaltenzahl = Attributszahl) wird beim Erzeugen der Relation festgelegt (beim Hinzufügen einer Spalte (Attribut) handelt es sich genaugenommen um die Überführung der Relation in eine andere). Die Kardinalität ist beim Erzeugen der Relation gleich Null und erhöht sich mit jedem Einfügen eines neuen Tupels. Definition (Relation) Eine Relation ist eine Tabelle obiger Gestalt, bestehend aus einem Kopf und einem Rumpf, mit folgenden 4 Eigenschaften: Es gibt keine doppelten Tupel. Tupel sind nicht geordnet (etwa von oben nach unten). Attribute sind nicht geordnet (etwa von links nach rechts). Alle Attribute sind atomar, d. h. jedes Attribut („Tabellenelement“) enthält nur ein Element. (Handhabung wird vereinfacht, Speicherbedarf kann besser geplant werden.) Definition (Relationale Datenbank) = eine Ansammlung von normalisierten Relationen, die zeitlich variieren (können). die einen (geeigneten) Grad haben. die Relationen stehen zueinander in einer bestimmten Beziehung und werden von einem Verwaltungssystem gemeinsam verwaltet. Eine Datenbank, die ausschließlich mit SQL Befehlen verwaltet und auf die ausschließlich mit SQL Befehlen zugegriffen wird, ist bereits eine relationale Datenbank, da SQL nur Relationen kennt. Unterscheidung „eigentliche“ Relationen <---> von „eigentl.“ Relationen abgeleitete Relationen Basisrelationen (am wichtigsten, da „eigentliche“ Relation) existieren tatsächlich (real) in der DB, haben Namen und sind dauerhaft gespeichert. Sichten (Views) virtuell und nicht real erscheinen dem Benutzer wie „normale“ Relationen aus Basisrelationen abgeleitet geeignet, um Benutzer mit eingeschränkten Rechten z.B. nur „Teilsicht“ auf eine best. Relation zu gewähren. Abfrageergebnisse (Query-Results) sind auch Relationen existieren nur temporär als Abfrageergebnisse auf Bildschirm oder Drucker Temporäre Relationen existieren wie Abfrageergebnisse nur temporär werden aber erst durch best. Aktionen z.B. Beenden einer Transaktion zerstört dienen v.a. zum Abspeichern von Zwischenergebnissen. 3/13 In SQL: CREATE TABLE ...; CREATE VIEW ...; SELECT ...; CREATE TEMPORARY TABLE ...; Erzeugen einer Basisrelation Erzeugen einer Sicht Abfrage Erzeugen einer temporären Relation Definition (Primärschlüssel) der Primärschlüssel ist ein besonderes Attribut, durch das jeder Tupel eindeutig beschrieben wird. Primärschlüssel kann aus mehreren Einzelattributen zusammengesetzt sein. Wegen der Def. der Relation (einmaliges Auftauchen eines Tupels) besitzt jede Relation einen Primärschlüssel. Im ungünstigsten Fall erstreckt sich dieser über mehrere oder sogar alle Attribute! Bsp. Primärschlüssel Tab. 3 Tab. 3 Relation Lagerbestand mit zusammengesetztem Primärschlüssel Produktname Produkttyp Bestand Preis Staubsauger T06 25 498 Staubsauger T17 17 219 ... ... ... ... Herd T04 10 1598 7 1998 Herd T06 <--- Primärschlüssel -------------> 1.3 Relationale Integritätsregeln Physische Integrität Vollständigkeit der Zugriffspfade und der physischen Speicherstrukturen Vom Datenbankprogrammierer nicht beeinflussbar. Ablaufintegrität Korrektheit der ablaufenden Programme Keine Dateninkonsistenz im Mehrfachbenutzerbetrieb Verantwortung: Anwendungsprogrammierer und Datenbankdesigner Zugriffsberechtigung korrekte Vergabe der Zugriffsberechtigung Verantwortung: Datenbank-Administrator Semantische Integrität Übereinstimmung der Daten in der DB mit denen in der realen Welt Gefahr: z.B. aus Versehen könnten falsche Werte z.B. Mengenangaben eingegeben werden Abhilfe: Eingabe muss auf Korrektheit überprüft werden. Empfehlung: die Gebiete sind so klein wie möglich zu wählen. Verantwortung: Anwendungsprogrammierer, Datenbank-Administrator, DB-Hersteller 4/13 1.3.1 Entitäts-Integritätsregel = 1. Integritäsregel Jeder Primärschlüssel identifiziert jedes Tupel eindeutig <=> jedes Tupel hat einen Primärschlüssel. 1. Integritätsregel (Entitäts-Integritätsregel) Keine Komponente des Primärschlüssels einer Basisrelation darf nichts enthalten. Definition (Schlüsselkandidat) Ein eventuell aus mehreren einzelnen Attributen zusammengesetztes Attribut heißt Schlüsselkandidat, falls es eindeutig jedes Tupel identifiziert und minimal ist, d.h. bei Weglassen eines einzelnen Attributs die Eindeutigkeit verloren geht. Definition (Primärschlüssel, alternativer Schlüssel) Besitzt eine Relation mehrere Schlüsselkandidaten, so wird davon einer als Primärschlüssel ausgewählt; alle anderen heißen alternative Schlüssel. Der Primärschlüssel soll minimal sein. Teilattribute des alternativen Schlüssels dürfen leer sein. Bsp. für Auftreten von Primärschlüssel und alternativen Schlüsseln in Tab. 4: Tab. 4 Tabelle der chemischen Elemente Protonen Atomgewicht Name Symbol 1 1,0079 Wasserstoff H 2 4,0026 Helium He 3 6,9410 Lithium Li ... ... ... ... NB: Protonenzahl, Namen und Symbol des Elements sind Schlüsselkandidaten. 1.3.2 Referenz-Integritätsregel Diese regelt Verweise der Relationen untereinander. Allgemein gesprochen sind Relationen einzelne Objekte ohne zwingenden Bezug. Üblicherweise gibt es aber einen Bezug, da in Datenbanken „zusammengehörige“ Dinge verwaltet werden. Der Bezug zwischen zwei Relationen wird durch einen weiteren Schlüssel, den sog. Fremdschlüssel hergestellt. Fremdschlüssel sind der „Kitt“, der die einzelnen Relationen zu einem gemeinsamen Datenbestand zusammenfügt. Definition (Fremdschlüssel) Ein (möglicherweise zusammengesetztes) Attribut einer Basisrelation heißt Fremdschlüssel, falls das ganze Attribut entweder nichts oder einen definierten Inhalt enthält, eine Basisrelation mit einem Primärschlüssel existiert, so dass jeder definierte Wert des Fremdschlüssels zum Wert jenes Primärschlüssels identisch ist. Beispiel für die Relationen Personal, Kunde und Auftrag (Tab. 5) (nächste Seite) 5/13 Tab. 5 Beispiel für die Relationen Personal, Kunde und Auftrag 6/13 2. Integritätsregel (Referenz-Integritätsregel) Eine relationale Datenbank enthält keinen Fremdschlüssel (ungleich NULL), der auf einen nichtexistenten Primärschlüssel verweist. Problem: Falls ein Tupel mit Primärschlüssel gelöscht werden soll, auf den Fremdschlüssel verweisen, so kann dieses nicht einfach gelöscht werden, da sonst der Fremdschlüssel ins Leere verweist wodurch die 2. Integritätsregel verletzt wäre. Lösungsmöglichkeiten: Löschen bzw. Ändern nicht durchführen ON DELETE NO ACTION bzw. ON UPDATE NO ACTION Löschen bzw. Ändern rekursiv aller darauf verweisender Tupel ON DELETE CASCADE bzw. ON UPDTATE CASCADE Nullsetzen aller darauf verweisender Fremdschlüssel ON DELETE SET NULL bzw. ON UPDTATE SET NULL 1.4 Relationale Algebra E. F. Codd definierte eine vollständige Syntax auf 8 Operatoren und schuf eine relationale Algebra. Er zeigte, dass damit alle denkbaren Zugriffe auf beliebige Relationen der Datenbank möglich sind. 1.4.1 Relationale Operatoren Eine Relation R ist eine Menge (R ist Menge aller Relationen) Es gibt 8 Mengenoperatoren auf R x R (binäre Operatoren) und R (unäre Operatoren). Das Bildgebiet ist wieder eine Menge (Relation). Binäre Operatoren sind z.B. Addition und Multiplikation Unäre Operatoren sind z.B. das negative Vorzeichen. Vereinigung R1 UNION R2 Alle Tupel, die wenigstens in einer der beiden Relationen vorkommen Schnitt R1 INTERSECT R2 Enhält nur die in beiden Relationen vorkommenden Tupel. Differenz R1 MINUS R2 Bezüglich der Tupel: R1 ohne R2 i.e. R1 \ R2 Kartesisches Produkt R1 TIMES R2 alle möglichen Kombinationen der Tupel aus R1 und R2 Restriktion R WHERE Bedingung die sich ergebende Relation ist eine Teilmenge von R entsprechend der Bedingung Projektion R [Attributsauswahl] alle Tupel, aber nur mit einer Auswahl von Attributen werden angezeigt. 7/13 (Natürliche) Verbindung R1 JOIN R2 alle mögl. Kombinationen der Tupel aus R1 u. R2. „gemeinsame Attribute dienen als Verknüpfung“, Verknüpfung bei gemeinsamen Attributen ist über Fremdschlüssel -> Primärschlüssel gegeben. Division R1 DEVIDEBY R2 R1 muss mindestens alle Att. von R2 enthalten (R2 ist Teilmenge von R1). Die neue Relation enthält nur die Attribute, die R1 zusätzlich zu R2 hat enthält nur die Tupel von R2 deren Attribute Att mit denen von R1 übereinstimmen. nur die „neuen“ Attribute werden gewählt (d.h. nur in R1 enthalten) nur die Tupel werden gewählt, wo für die Attribute gilt, die in R1 und R2 vorhanden sind: „die Attribute stimmen in ihren Werten überein“ Graphische Verdeutlichung (Abb. 2): Abb 2.1: Natürliche Verbindung (JOIN) der Relationen Personal und Auftrag Abb 2.2: Graphische Verdeutlichung der 8 relationalen Operatoren 8/13 2 Datenbankdesign 2.1 Normalformenlehre Die Normalformenlehre betrachtet immer Relationen für sich. Das Entity-Relationship-Modell ist ein Gesamt-Design mit allen Beziehungen zwischen den Relationen. Die Normalformenlehre beschreibt, wie Relationen aufgebaut werden sollen, um Redundanzen zu vermeiden. Codd stellte 1970 3 Normalformen auf, heute gibt es insg. 5 Normalformen. Die 1. - 3. finden am meisten Anwendung. Die Normalformen bauen aufeinander auf, d.h. befindet sich eine Datenbank in der m.ten Normalform, so befindet sie sich auch in der n.ten (m n). Definition (erste Normalform) Eine Relation ist in der ersten Normalform, wenn alle zugrundeliegenden Gebiede nur atomatre Werte anthalten. Definition (funktionale Abhähngigkeit) Ein Attrbut Y einer Relation R heiß funktional abhängig vom Attirbut X derselben Relation, wenn zu jedem X-Wert höchsten ein Y-Wert möglich ist. Ist Y von X funktional abhängig so schreiben wir: X->Y Definition (volle funktionale Abhängigkeit) Ein Attribut Y einer Relation R heißt voll funktional abhängig vom Attribut X derselben Relation, wenn es funktional abhängig von X ist, nicht aber funktional abhängig von beliebigen Teilattributen von X. Ist Y von X voll funktional abhängig so schreiben wir: X=>Y Definition (zweite Normalform) Eine Relation ist in der zweiten Normalform, wenn sie in der ersten Normalform ist, und jedes Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel ist. (Ein Nichtschlüsselattribut ist jedes (auch zusammengesetzte) Attribut, das kein Schlüsselkandidat ist.) Bemerkung: Eine normalisierte Relation mit einem nicht zusammengesetzten Primärschlüssel befindet sich immer in der zweiten Normalform. Umgekehrt besitzt eine Relation, die sich nicht in der zweiten Normalform befindet, einen zusammengesetzten Primärschlüssel. Definition (Determinante) Eine Determinante ist ein (eventuell zusammengesetztes) Attribut, von dem ein anderes voll funktional abhängig ist. Diese Definition besagt nur, dass jedes Attribut, von dem ein Doppelpfeil ausgeht, als Determinante bezeichnet wird. In der zweiten Normalform sind also mindestens alle Schlüsselkandidaten Determinanten. Die dritte Normalform geht noch einen Schritt weiter: 9/13 Definition (dritte Normalform nach Boyce/Codd) Eine normalisieret Relation ist in der dritten Normalform, wenn jede Determinante dieser Relation ein Schlüsselkandidat ist. Bemerkung Jede beliebige Relation kann durch Umformung (meist Zerlegung in mehrere Relaitonen) in die zweite und auch in die dritte Normalform überführt werden. Vierte und fünfte Normalform (Ausblick) Primärschlüssel und alternative Schlüssel sind möglichst so zu wählen, dass sie nur aus ein oder höchstens zwei Attributen bestehen. Dies sind Aussage und Inhalt der vierten und fünften Normalform. Besitzt eine Relation einen nicht zusammengesetzten Primärschlüssel, so fallen die Definitionen der dritten, vierten und fünften Normalform zusammen! 2.2 Entity-Relationship-Modell Nachdem geklärt wurde, wie einzelne Relationen aufgebaut werden sollten, wird nun beschrieben, wie die Beziehungen zwischen den Relationen gestaltet werden sollen. 2.2.1 Entitäten Tab. 5 Begriffe zu relationalen Datenbanken Entiät ein unterscheidbares Objekt (im Sinne der betrachteten Objekte in der Datenbank), im mathematischen Sinne ein Element Eigenschaft ein Teil einer Entität, der die Entität beschreibt Beziehung eine Entität, die zwei oder mehr Entitäten miteinander verknüpft Subtyp eine Entität Y, die auch zu einer Entität X gehört Supertyp eine Entität, die Subtypen enthält Tab. 6 Beispiele zu den Begriffen zu relationalen Datenbanken Begriff Beispiele Entität Person, Werkzeugteil, Produkt, Rechnung Eigenschaft Name, Vorname, PLZ, Ort, Adresse einer Person; Einzelteile, aus denen ein Werkzeug besteht; Rechnungsdatum Beziehung die Relation Verknuepfung verbindet die Relationen Verkaeufer und Produkt (siehe Tab.7) Subtyp die Entität Programmierer ist ein Subtyp zu Entität Person. Supertyp die Entität Person ist ein Supertyp der Entität Programmierer. 10/13 Tab. 7 Relation Verkaeufer Verk_Nr Verk_Name PLZ Verk_Adresse V1 Meier 80075 München V2 Schneider 70038 Stuttgart V3 Müller 50083 Köln Tab. 8 Relation Produkt Prod_Nr Produktname P1 Waschmaschine P2 Herd P3 Kühlschrank P4 Staubsauger Tab. 9 Realtion Verknuepfung Verk_Nr Produkt_Nr Umsatz V1 P1 11000 V1 P2 5000 V1 P3 1000 V2 P2 4000 V2 P3 3000 V3 P4 1000 Abb. 3 Beispiel zu Entitäten und Eigenschaften 11/13 Ein Beispiel zu Beziehungen zwischen Relationen (Abb. 4): Eine Entität Person hat eine Beziehung zu der Entität (Relation) Abteilung, in der Daten zu den Abteilungen abgespeichert sind. Diese Beziehung stellt selbst eine Entität dar, eine sog. Beziehungs-Entität (dargestellt als Raute). Abb. 4 Beispiel einer Beziehungsrelation Es wird zwischen schwachen und starken Entitäten unterschieden. Eine schwache Entität hängt von einer starken Entität ab. Wird die starke Entität entfernt, so verliert jede von ihr abhängige schwache Entität ihre Daseinsberechtigung und kann auch entfernt werden. Ein Beispiel wären die Entitäten Produkt, Einzelteile und Fehler. Die Entitäten Einzelteile und Fehler hängen von Prokukt ab. Falls alle Fehler prokukt-spezifisch sind, so ist Fehler eine schwache Entiät, d. h. falls das Produkt aus der Prokuktion genommen wird, so sind die Fehlerdaten wertlos. Einzelteile können jedoch für verschiedene Produkte verwendet werden, diese Entität ist daher nicht schwach. 2.2.2 Beziehungen: Primärschlüssel und Fremdschlüssel Eine Beziehungsentiät zwischen zwei Entitäten enthält zwei Fremdschlüssel, die auf die Primärschlüssel der beiden Entitäten verweisen. Es liegen also Beziehungen wie zwischen Verkaefer und Produkt, oder wie zwischen Teilelieferant und Teile vor. Es sind auch Beziehungen zwischen mehreren Entitäten möglich, die Beziehungs-Entitäten enthalten dann dementsprechend mehr Fremdschlüssel. Abb. 5 Beziehungsrelation zwischen Verkaeufer und Prokukt Die Relation Verknuepfung wird in SQL wie folgt erzeugt, wobei alle Schlüsselinformationen bereits mit angegeben sind: 12/13 CREATE TABLE Verknuepfung ( Verk_Nummer CHARACTER(4) Produkt_Nr CHARACTER(4) Umsatz SMALLINT, PRIMARY KEY (Verk_Nummer, Produkt_Nr) ); REFERENCES Verkaeufer, REFERENCES Produkt, Einige Empfehlungen zum Erstellen einer Datenbank: Auswahl aller Eigenschaften, die in die Datenbank aufgenommen werden sollen (meist ein langwieriger und zeitraubender Prozess). Eine gute Auswahl schon in der Anfangsphase verhindert ein mehrmaliges und zeitraubendes Anpassen der Datenbank. Zusammenfassen der Eigenschaften zu Entitäten. Hier ist die Normalformenlehrre zu berücksichtigen. Bei guter Auswahl der Entitäten werden die Relationen meist automatisch in dritter oder höherer Normalform sein. Ermittlung der Beziehungen zwischen den einzelnen Entitäten Erzeugen der Relationen, Erzeugen der Beziehungsrelationen. Geeignete Wahl der Fremdschlüssel. Ermittlung der Eigenschaften der Fremdschlüssel. (Was soll mit ihnen geschehen falls der zugehörige Primärschlüssel eine „Lösch- oder Update-Anfrage“ bekommt.) Hier helfen auch Stichworte wie schwache Entität und Subtyp weiter. 13/13