3. Relationales Daten(bank)modell. Vorbemerkung - Historie - Einordnung

Transkript

1 3. Relationales Daten(bank)modell Vorbemerkung - Historie - Einordnung Begriffe und Eigenschaften - Relationen und Tabellen - Relationsschema - Schlüssel, Integrität Relationale Abbildung des E/R-Modells - Beziehungstypen - Nichtatomare Attribute Seite 97

2 3.1 Vorbemerkung/Historie nach dem hierarchischen Modell und Netzwerk-Modell "weit entfernt" vom gelegentlichen Endbenutzer ("casual user"): - Datenbank nur aus Anwendungsprogramm heraus ansprechbar, dazu sind Programmierkenntnisse erforderlich - Datenbanksprache (DL/1, CODASYL) schwer zu erlernen GET UNIQUE, GET NEXT, GET NEXT WITHIN PARENT FIND OWNER, FIND FIRST, FIND NEXT - Datenbanksystem nur für kleinen Kreis von Spezialisten zugänglich, dadurch "Entwicklungsstau" - Komplizierter Umgang mit Datenbanksystem führt zu Fehlern Datenbank wird inkonsistent, DBVS kann dies nicht feststellen "Zustand der modellierten Miniwelt <> Zustand der Datenbank" Fatal vor allem bei kritischen Anwendungen (z.b. Prozessteuerung in der Industrie, Finanzbereich) Seite 98

3 3.1 Vorbemerkung/Historie Entwicklungsziele für relationales Datenmodell / im IBM Forschungslabor in San Jose Ende 60er Jahre (E.F. Codd u.a.): - Einfaches Datenmodell mit mathematisch fundierter Grundlage - Einfache Datenbanksprache (auch für Ad-hoc-Anfragen) mit mathematisch fundierter Grundlage Verhalten von Datenbanksprachanweisungen (Semantik) ist wohldefiniert auf mathematischer Grundlage Benutzer beschreibt nur noch, was er haben möchte (lesen, einfügen, ändern, löschen), das wie überlässt er dem DBS Deskriptive Anfragen statt Navigation! - Überwachung von Konsistenz/Integrität möglichst weitgehend durch das DBVS und nicht durch den Benutzer Semantik der Daten muss dem DBVS offengelegt werden, so dass automatische Überprüfungen möglich sind DBVS berücksichtigt bei Operationen die Dateninhalte und verlässt sich nicht darauf, dass der Benutzer "die Zeiger richtig setzt" Seite 99

4 3.1 Vorbemerkung/Historie Ergebnis der Entwicklung/Forschung: - Datenmodell und Datenbanksprache leichter zu erlernen näher am (End-)Benutzer breiterer Benutzerkreis weniger Entwicklungsstau - Datenbankzugriffe auch ad-hoc möglich, nicht zwingend per Anwendung - Inkonsistente Datenbanken unwahrscheinlicher - Ineffizienter Datenbankzugriff unwahrscheinlicher DBVS ist für das wie des Datenzugriffs verantwortlich Optimale Ausführungsstrategie wählbar (Zugriffsplan, Optimizer) Entwicklungsweg relationaler DBMS -Erste Prototypen ab Mitte der 1970er System R (IBM, später DB2), Ingres (Univ. of California) -Erste Produkte ab Ende der 1970er SQL/DS, DB2, Ingres, Oracle - Stärkere Verbreitung in der Praxis ab Mitte der 1980er und 1990er Informix, Sybase, MS SQL Server, MySQL Seite 100

5 3.2 Begriffe und Eigenschaften Ziele bei der Definition des Modells: - Wenige, einfache, mathematisch fundierte Konzepte und Begriffe - Beschreibung ausschließlich logischer Aspekte (konzeptuelles Schema) - Physische Aspekte (internes Schema) nicht Gegenstand des Modells Modellierung in Form von Relationen, Grundlage zur - Darstellung der Daten - Datenabfrage und Manipulation Begriffsklärung nachfolgend: - Relation - Relationsschema -Schlüssel Seite 101

6 3.2.1 Relation Definition: - Gegeben seien Wertebereiche/Domänen D 1, D 2,..., D n - Eine Relation (Menge) R ist eine Teilmenge des kartesischen Produkts der Domänen D 1, D 2,..., D n R D 1 D 2... D n (n 1) n = Stelligkeit (Grad) der Relation Element r = (d 1, d 2,..., d n ) mit d i єd i wird als Tupel von R bezeichnet, d i als die i-te Komponente des Tupels Darstellungsform: - Relationen können als Tabellen dargestellt / aufgefasst werden - Tupel = Tabellenzeile ("rows") - Komponente des Tupels = Wert in Tabellenspalte ("columns") Relation R D 1 D 2... D n d 1 d 2... d n Tupel... Seite 102

7 3.2.1 Relation Beispiel: - Domänen: D 1 = {rot, blau, grün} D 2 = {0,1} - Kartesisches Produkt: D 1 D 2 = {(rot,0), (rot,1), (blau,0), (blau,1), (grün,0), (grün,1)} - Mögliche 2-stellige Relationen: R 1 = {(rot,0), (grün,1)} rot 0 grün 1 R 2 = { } R 3 = {(rot,0)} rot 0 Seite 103

8 3.2.2 Relationsschema Bisher wurden Relationen (Mengen von Tupeln) betrachtet -Aus Datenbanksicht ist aber auch das zugehörige Schema von Interesse, das einen Relationstyp beschreibt - Abstraktion von konkreter Relation zum Relationstyp Definition: Relationsschema besteht aus - Schemaname - Menge von Domänen(namen) D 1, D 2,..., D n - Menge von Attributnamen A 1, A 2,..., A n (Tabellenspalten mit a i єd i ) - Zusätzlichen Integritätsbedingungen Beispiel: - Schemaname: FarbTabelle, kurz: FarbTabelle(Farbe, Wert) - Domänen: D 1 = {rot, blau, grün}, D 2 = {0,1} - Attributnamen: Farbe (D 1 ), Wert (D 2 ) - Integritätsbedingung: Farbe rot darf nicht mit Wert 1 ein Tupel bilden Seite 104

9 3.2.2 Relationsschema Beispiel: - Relationsschema Angest (Name, Beruf, Wohnort, GebJahr) - Domänen/Integritätsbedingungen hier nicht aufgeführt - Darstellung von Schema + Daten Schemaname: Angest Attributnamen: Name, Beruf, Wohnort, GebJahr Schemaname Attributname Angest Name Beruf Wohnort GebJahr Schema Tupel (Darstellung als Tabellenzeilen) Müller Meier Schulze Schreiner Schmied Bergmann Jena Jena Seiffen Daten, konkrete Relation Attributwert Seite 105

10 3.2.2 Relationsschema Datenbankschema = Menge von Relationsschemata (mit verschiedenen Schemanamen) + Integritätsbedingungen (relationsschemaübergreifend) Keine strikte Unterscheidung zwischen Relationsschema und Relation; wenn von Relation die Rede ist, wird meist darunter auch das Schema subsumiert (d.h. Daten + Schema oder auch nur Schema) Definition: Eine Relation ist in 1. Normalform, wenn jedes Attribut aufgrund der Schemadefinition nur atomare Wertebereich hat. - Mengenwertige, strukturierte und geschachtelte Attribute im E/R- Verständnis sind verboten, Relation ist frei von Wiederholungsgruppen Entscheidung abhängig vom Anwendungskontext Bsp: Attribut "Adresse" (PLZ, Ort, Strasse, Nr) in 4 Attribute splitten - Das relationale Modell, wie von Codd definiert und in DBVS-Produkten realisiert, verlangt "im Prinzip" 1. Normalform!!! - Typische atomare Attribute: Integer, Real, Decimal, Char, String, Boolean Seite 106

11 3.2.3 Schlüssel Relationen sind Mengen, es dürfen also in einer Relation keine identischen Tupel auftauchen Müller Schreiner Jena 1960 Müller Schreiner Jena 1960 Relationenmodell ("reine Lehre") verlangt für jede Relation einen - Schlüssel als identifizierende Attributkombination mit - Minimalitätseigenschaft, d.h. bei Weglassen eines Attributs aus der Kombination geht die Schlüsseleigenschaft verloren - Existieren für eine Relation mehrere Schlüssel(kandidaten), muss einer ausgewählt werden als Primärschlüssel Beispiel: Relation Angest (Name, Beruf, Wohnort, GebJahr) - Was ist hier der Schlüssel? - Erweiterung der Relation erforderlich/sinnvoll: Angest (PNR, Name, Beruf, Wohnort, GebJahr) Schlüssel = PNR Seite 107

12 3.2.3 Schlüssel Definition: besitzt eine Attributkombination einer Relation R1 in einer Relation R2 (Primär-)Schlüsseleigenschaft, kann sie in R1 als Fremdschlüssel mit Bezug auf den (Primär-)Schlüssel in R2 bezeichnet werden - Fremdschlüssel ist üblicherweise kein Schlüssel in R1! - Fremdschlüssel als Definitionsmittel für referentielle Integrität, wobei Werte als Verweise dienen (keine "Pointer") - Namensidentität nicht zwingend, aber Kompatibilität der Wertebereiche - Relationen dürfen beliebig viele Fremdschlüssel haben Beispiel: - R1 = Angest (PNR, Name, Beruf, Wohnort, GebJahr, ANR) - R2 = Abteilung (ANR, AOrt, Mgr, Budget) - "ANR" kann als Fremdschlüssel in der Relation "Angest" bezüglich des Primärschlüssels "ANR" in "Abteilung" vereinbart werden (per DDL) - Bedeutung: Für "ANR" in "Angest" dürfen nur Werte auftreten, die auch als ANR-Wert in "Abteilung" vorkommen Reine Lehre: Waisenkinder sind verboten, Einfügereihenfolge! SQL / Produkte: Möglichkeiten der Aufweichung (on update/delete...) Seite 108

13 3.3 Relationale Abbildung des E/R-Modells Beziehungstypen - Nichtrekursive 1:n-Beziehung - Rekursive 1:n-Beziehung - Nichtrekursive n:m-beziehung - Rekursive n:m-beziehung Umgang mit nichtatomaren Attributen - Strukturierte Attribute - Mengenwertige Attribute Seite 109

14 3.3.1 Nichtrekursive 1:n-Beziehung E/R-Diagramm: ABTEILUNG (0,*) (1,1) HAT MITARBEITER Relational: - ABTEILUNG (ANR, AOrt,...) - MITARBEITER (PNR, Name,..., ANR) Beispieltabellen: - Reihenfolge der Spalten und Zeilen ist unerheblich (Menge!) Abteilung ANR AOrt Mitarbeiter PNR Name ANR Jena Weimar Erfurt Meier Meyer Maier Überführung eines Entity-Typ in Relation(sschema) - Unmittelbare Übernahme der (atomaren) Attribute - Vorsicht bei Schlüsselüberführung wegen Minimalitätsforderung Seite 110

15 3.3.1 Nichtrekursive 1:n-Beziehung ANR in MITARBEITER ist Fremdschlüssel bezüglich Primärschlüssel in ABTEILUNG - Darstellung des Beziehungstyp HAT aus dem E/R-Diagramm - Überführung von HAT in eigenständige Relation nicht erforderlich Beliebige Kardinalitäten (z.b. (3,7)) nicht direkt im rel. Modell darstellbar Falls Mitarbeiter erlaubt sein sollen, die keiner Abteilung angehören, ist für ANR in MITARBEITER definierbar, dass ein Nullwert (NULL) gestattet ist - Nullwert ("undefiniert") hat spezielle Semantik, nicht normaler Wert 0 - Bsp: Attribute ANR und Name in MITARBEITER dürfen Nullwerte haben Mitarbeiter PNR Name ANR Meier Meyer Maier NULL 3952 NULL Nullwerte sind für Primärschlüssel verboten, auch für Teil-Attribute!! Seite 111

16 3.3.2 Rekursive 1:n-Beziehung E/R-Diagramm: (0,1) ist... MITARBEITER (0,1) hat als... VORGESETZTER Relational: - MITARBEITER (PNR, Name,..., MgrPNR) MgrPNR ist Fremdschlüssel in MITARBEITER bezüglich Primärschlüssel der gleichen Relation (ist erlaubt!!) Problem: wie stellen wir als Tupel den "obersten Boss" dar? Alternativen: - MgrPNR und PNR besitzen gleichen Wert (Trick nicht empfehlenswert!) - MgrPNR bekommt in diesem Fall einen undefinierten Wert (Nullwert) Dies muss im relationalen Modell an MITARBEITER definiert werden Weitere Integritätsbedingung dann notwendig, die sicherstellt, dass am MgrPNR-Attribut nur einmal der Wert NULL vorkommt (Big Boss) Integritätsbedingung wegen Zyklenfreiheit Seite 112

17 3.3.2 Rekursive 1:n-Beziehung Beispieltabelle: Mitarbeiter PNR Name MgrPNR Schmidt Dagobert Graf Schneider NULL Ausprägungsbaum: - Tabelle (Relation) Mitarbeiter enthält für jeden Knoten (Mitarbeiter) im Ausprägungsbaum ein Tupel - Kanten im Ausprägungsbaum werden in der Tabelle durch die Primärschlüssel-Fremdschlüssel-Beziehungen dargestellt PNR 3814 PNR 4755 PNR PNR 6719 Seite 113

18 3.3.3 Nichtrekursive n:m-beziehung E/R-Diagramm: MENGE Relational: LIEFERANT - LIEFERANT (LieferNr, Name, Ort,...) - TEIL (TeileNr, Bezeichnung,...) - LIEFERT (TeileNr, LieferNr, Menge) (0,*) (0,*) LIEFERT TEIL Beziehungstyp wird in eigenständige Relation überführt (LIEFERT) - Primärschlüssel von LIEFERT ist die Attributkombination der Schlüssel der Relationen LIEFERANT und TEIL - Fremdschlüssel in LIEFERT: TeileNr (TEIL), LieferNr (LIEFERANT) - Warum Beziehungstyp als eigenständige Relation statt TeileNr aus TEIL als Fremdschlüssel in LIEFERANT aufnehmen? Redundanzvermeidung Abbildung von Lieferanten ohne Teile bzw. Teile ohne Lieferanten Seite 114

19 3.3.3 Nichtrekursive n:m-beziehung Konsequenz der 2 Primärschlüssel-Fremdschlüssel-Beziehungen: - In der Spalte TeileNr/LieferNr von LIEFERT dürfen nur Teilenummern bzw. Lieferantennummern vorkommen, die auch in TEIL/LIEFERANT vorhanden sind - Nullwerteproblematik hier durch Definition ausgeschlossen (warum?) LIEFERANT LieferNr Name Ort Jenoptik Zeiss Rodenstock Jena Jena Stuttgart TEIL TeileNr Bezeichnung LIEFERT TeileNr LieferNr Menge Glasauge Linse Okular Seite 115

20 3.3.4 Rekursive n:m-beziehung E/R-Diagramm: - Modell einer Stückliste (0,*) TEIL (0,*) - Entitytyp TEIL als Synonym für Einzelteil Baugruppe enthält / enthalten in MENGE Relational: - TEIL (TeileNr, Bezeichnung,...) - STRUKTUR (OberteilNr, UnterteilNr, Menge) Beziehungstyp wird in eigenständige Relation überführt (STRUKTUR) - Primärschlüssel von STRUKTUR setzt sich aus Attributen OberteilNr und UnterteilNr zusammen - OberteilNr und UnterteilNr sind jeweils einzeln Fremdschlüssel in STRUKTUR mit Bezug auf Primärschlüssel von TEIL Seite 116

21 3.3.4 Rekursive n:m-beziehung Konsequenz der 2 Primärschlüssel-Fremdschlüssel-Beziehungen: - In der Spalte OberteilNr/UnterteilNr von STRUKTUR dürfen nur Teilenummern vorkommen, die auch in TEIL vorhanden sind - Nullwerteproblematik hier ebenfalls durch Definition ausgeschlossen - Zusätzliche Integritätsbedingung wegen Zyklenfreiheit! TEIL TeileNr A B C D EF Bezeichnung Getriebe Gehäuse Welle Schraube Schraube Kugellager STRUKTUR OberteilNr A A A B B C C UnterteilNr B C E D E E F Menge Darstellung als Gozinto-Graph - "Zepartzat Gozinto" - DAG = directed acyclic graph B D A 1 4 E Mengen C F 2 Seite 117

22 3.3.5 Abbildung nichtatomarer Attribute Nichtatomare Attribute sind nicht direkt im relationalen Modell abbildbar - Grund: Einhaltung 1. Normalform - Vorstellung von Lösungsmöglichkeiten am Beispiel ANGEST Mengenwertige Attribute (Telefon#) Strukturierte Attribute (Adresse) E/R-Diagramm-Beispiel: ANGEST Telefon# PNR Name Adresse PLZ Ort Straße Hausnummer Seite 118

23 3.3.5 Abbildung nichtatomarer Attribute Mengenwertige Attribute Modellierungsvorschlag 1: Eine Tabelle ANGEST PNR TelNr Name Schmidt Schmidt Dagobert Dagobert Dagobert nein! - Mitarbeiter ohne Telefon können in ANGEST nicht aufgenommen werden! - Redundanz in Tabellenspalte Name, dadurch Änderungsaufwand und Integritätsgefährung! Lösung: 2. Normalform Modellierungsvorschlag 2: Zwei Tabellen ANGEST PNR Name TELEFON PNR TelNr Schmidt Dagobert Graf Seite 119

24 3.3.5 Abbildung nichtatomarer Attribute Mengenwertige Attribute - PNR in TELEFON ist Fremdschlüssel mit Bezug auf den Primärschlüssel von ANGEST - Nullwertproblematik hier per Definition ausgeschlossen - Zusätzliche Integritätsbedingung denkbar: Kein "Telefonnummern-Sharing", d.h. zwei Angestellte besitzen nie die gleiche Telefonnummer TelNr in TELEFON zum Schlüsselkandidaten machen garantiert Werteeindeutigkeit! Primärschlüssel wäre nach der reinen Lehre dann TelNr, aber Definition über (PNR, TelNr) mit UNIQUE-Bedingung auf TelNr lassen SQL/Produkte auch zu - Nachteil der Verwendung zweier Tabellen (ANGEST, TELEFON): Eine Datenbankanfrage, die z.b. Name und TelNr sehen möchte, muss auf beide Tabellen zugreifen Verknüpfungs-Operation (JOIN) ist bei falscher Verwendung sehr teuer (Optimizer-Aufgabe!) Seite 120

25 3.3.5 Abbildung nichtatomarer Attribute Strukturierte Attribute Modellierungsvorschlag 1: Eine Tabelle ANGEST PNR Name PLZ Ort Straße Hausnr Schmidt Dagobert Herausnehmen der Ebene "Adresse" und Hochziehen der zugehörigen atomaren Attribute - Nachteil: Verlust von Semantik Jena Berlin Freiheit Moabit Zusammengehörigkeit von PLZ-Ort-Straße-Hausnummer verloren Adresse in DB-Anfrage nicht mehr einfach als ganzes ansprechbar Modellierungsvorschlag 2: Zwei Tabellen ANGEST PNR Name ADRESSEN PNR PLZ Ort Schmidt Dagobert Jena Berlin - PNR in ADRESSEN ist Primär-/Fremdschlüssel auf PNR in ANGEST - Adresstabelle liefert gesamte Adresse für eine gegebene PNR Seite 121