Nicht Relationale Datenbanken. Nachteile des Relationenmodells

Transkript

1 Nicht Relationale Datenbanken Nachteile des Relationenmodells

2 Gliederung Probleme des Relationenmodells Datenmodellierung Datenbankentwurf Anfragesprachen Update Operationen Zugriffspfade Optimierung

3 Datenmodellierung

4 Datenmodellierung Beispiel Objekttyp Bücher Bücher = {ISBN, Titel, Autoren, Versionen, Stichworte, Verlag} verwendet ausschließlich Standarddatentypen (string, integer) Überführung in 1. Normalform jeder Wert eines Attributs muss atomar sein => bsw. können nicht mehrere Autoren für ein Buch in einer Zeile verzeichnet sein Beispielausprägung:

5 Datenmodellierung Redundanzen Übergang zur 3. Normalform => alle Felder einer Tabelle sind vollkommen unabhängig voneinander d.h. kein Feld determiniert den Wert eines anderen Feldes Beispielausprägung in 3. Normalform:

6 Datenmodellierung stellt ein Attribut eine Menge von Werten dar, muss dieses Attribut aus der eigentlich für diesen Objekttyp zuständigen Relation ausgelagert werden (bsw. Buchautor) besteht ein Attribut aus mehreren Komponenten (bsw. Version), so nimmt man nur diese Komponenten in das Relationenschema auf Attribute, die aus Wertemengen oder aus mehreren Komponenten bestehen, können simuliert, aber nicht direkt im RDM dargestellt werden. Wertemengen müssen im RDM immer durch einen anderen Attributwert identifiziert werden (im Beispiel: Autoren / Stichworte durch ISBN)

7 Datenmodellierung Beispiel Personen / Studenten Identifikation über Primärschlüssel PersonalAuswNr.

8 Datenmodellierung Beispiel Personen / Studenten Fremdschlüsselbeziehungen mit unterschiedlicher Semantik: PersonalAuswNr (Pers_Hobbies) -> PersonalAuswNr (Personen) dient der Herstellung eines Zusammenhangs zwischen komplexen Attributen eines Objekttyps => eine Person hat mehrere Hobbies PersonalAuswNr (Studenten) -> PersonalAuswNr (Personen) IS A Relation => für alle Studenten Objekte gelten die gleichen Attribute wie für Personen Vater_PANr (Studenten) -> PersonalAuswNr (Personen) Komponentenobjekte des Objekttyps Studenten Attribute sind Objekttypen => Personen

9 Datenmodellierung Beziehungen zwischen verschiedenen Relationen eines Objekttyps, IS A Beziehungen zwischen verschiedenen Objekttypen und Objekt Komponentenobjekt Beziehungen können im Relationen Datenbankmodell nicht unterschieden werden. Sie werden jeweils über Fremdschlüssel Beziehungen dargestellt.

10 Datenbankentwurf

11 Datenbankentwurf Datenbankentwurfstechniken Informale Methoden Entwurf aufgrund eines Datenmodells wie dem ER Modell Probleme: verwendete Datenmodelle oft zu schwach für adäquate Modellierung aufgrund der Informalität ist Qualität der Datenbankschemata nicht messbar Formale Algorithmen Entwurf basiert auf einer formalen Spezifikation der Anwendung in einem semantischen Datenbankmodell dieser Entwurf wird mittels Algorithmen in ein relationales Datenbankschema überführt

12 Datenbankentwurf Formale Algorithmen funktionale Abhängigkeiten (FD) in einer Relation gilt eine funktionale Abhängigkeit zwischen Attributmengen X und Y, wenn in jedem Tupel der Attributwert unter der X Komponente den Attributwert unter der Y Komponente festlegt X -> Y Einschränkung der erlaubten Menge von Relationen Integritätsbedingung Schlüssel sind somit Spezialfälle funktionaler Abhängigkeiten Ziel eines Datenbankentwurfs ist hier die Umformung aller gegebenen funktionalen Abhängigkeiten in Schlüsselabhängigkeiten bsw. PersonalAuswNr -> Vorname, Nachname, PLZ usw. jedes Tupel der Relation wird durch PersonalAuswNr eindeutig bestimmt

13 Datenbankentwurf Formale Algorithmen mehrwertige funktionale Abhängigkeiten (MVD) einem Attributwert der Menge X wird eine Menge von Y Werten zugeordnet X->->Y bsw. ISBN ->-> Autor zu einer ISBN können mehrere Autoren gehören Problem: FDs und MVDs sind meist nur schwer zu bestimmen Vollständigkeit der Beschreibung meist nicht gegeben

14 Datenbankentwurf Formale Algorithmen Eingangsgrößen für den Datenbankentwurf sollten nicht nur Attribute und Abhängigkeiten zwischen Attributen sein, da mit diesen weder eine Anwendung vollständig beschrieben, noch eine verständliche und widerspruchsfreie Modellierung der Anwendung erreicht werden kann.

15 Datenbankentwurf Formale Algorithmen weitere Integritätsbedingungskonzepte Verbund - / Verbundabhängigkeiten Auftrennung eines Relationenschemas R in mehrere Schemata R1 Ri => Dekomposition die Rekonstruktion zum Schema R bezeichnet man als Verbund die Verbundbildung muss ohne Informationsverlust realisierbar sein Darstellung solcher Dekompositionen als Abhängigkeiten => Verbundabhängigkeit graphisch >< Beispiel Bücher - ><[ {ISBN, Titel, Verlag}, {ISBN, Autor}, {ISBN, Stichwort}, {ISBN, Version} ]

16 Datenbankentwurf Formale Algorithmen Def. Universum alle Attribute eines Datenbankschemas häufig wird eine Verbundabhängigkeit über alle Attribute des Schemas benötigt Möglichkeit der Darstellung aller Attribute über Universalrelation die darin enthaltenen Information sind allerdings geschickter durch Verteilung auf die angegebenen Komponenten darstellbar

17 Def. Inklusionsabhängigkeit Datenbankentwurf Formale Algorithmen Verallgemeinerung der Fremdschlüssel auf der rechten Seite einer Fremdschlüsselabhängigkeit muss nicht zwangsläufig der Primärschlüssel stehen X Werte einer Relation r1(r1) dürfen auch als Y Werte einer Relation r2(r2) vorkommen => Inklusionsabhängigkeit R1[X] R2[Y] alle Ausprägungen von X müssen in Y vorhanden sein

18 Datenbankentwurf Formale Algorithmen Inklusionsabhängigkeit Beispiel: AUTOR(Autoren-Nr, Name) VERFASST(Autoren-Nr, Buch-Nr) Autoren-Nr(verfasst) inkludiert in Autoren-Nr(Autor) alle Werte von Autoren-Nr(verfasst) sind Teilmenge aller Werte von Autoren-Nr(Autor) wird ein Tupel aus AUTOR entfernt, müssen die zugehörigen Elemente in VERFASST ebenfalls gelöscht werden, um die Abhängigkeit nicht zu verletzen Integritätsbedingung

19 Datenbankentwurf Schema - Eigenschaften Relationenschemata, Schlüssel und Fremdschlüssel sollten so gewählt sein, dass: alle Anwendungsdaten aus den Basisrelationen hergeleitet werden können nur semantisch sinnvolle und konsistente Anwendungsdaten dargestellt werden können die Anwendungsdaten möglichst nicht redundant dargestellt werden Def. Abhängigkeitstreue FDs und MVDs werden in Schlüssel / Fremdschlüssel umgewandelt Abhängigkeitstreue liegt vor, wenn die Menge der Abhängigkeiten äquivalent zu der Menge der Schlüsselbedingungen ist

20 Datenbankentwurf Schema - Eigenschaften transitive Abhängigkeit K -> X -> Y => bsw. PLZ bestimmt den Ort funktional eleminiert man diese Abhängigkeiten nicht, entstehen wieder Redundanzen darum Auslagerung von Ort und PLZ in eigene Relation gelten in einem Relationenschema keine transitiven Abhängigkeiten, befindet es sich in 3. Normalform Def. nichttriviale mehrwertige Abhängigkeit MVD X->->Y ist nichttrivial, wenn außer X und Y noch weitere Attribute im zugehörigen Relationenschema vorkommen (bsw. Buch_Version => ISBN, Auflage, Jahr) enthält ein Relationenschema nur noch triviale MVDs, befindet es sich in 4. Normalform

21 Datenbankentwurf Schema - Eigenschaften Problem: Verbundtreue ist nicht gewährleistet Originalrelation ist nicht wiederherstellbar, da alle Zusammenhänge zwischen den Relationen verlorengegangen sind

22 Datenbankentwurf Schema - Eigenschaften Forderung der Minimalität zwar sollen Normalformen und Abhängigkeitstreue erreicht werden allerdings soll die Anzahl der dafür erzeugten aufgespalteten Relationenschemata möglichst minimal sein

23 Datenbankentwurf Dekompositionsalgorithmus Startet bei initialem Relationenschema R, das aus allen Attributen und den Schlüsseln besteht, die von den erfassten Abhängigkeiten impliziert werden Suche transitiver Abhängigkeiten K->X->Y Y wird zusammen mit X aus dem Relationenschema eliminiert und in einem neuen Schema zusammengefasst => X ist Schlüssel dieses neuen Schemas nach Terminierung des Algorithmus gilt: - Ergebnis ist in 3. Normalform - der Algorithmus selbst sichert die Verbundtreue zu

24 Datenbankentwurf Dekompositionsalgorithmus nicht gewährleistet sind allerdings: Minimalität Abhängigkeitstreue dies hängt damit zusammen, dass die Reihenfolge der Schritte starken Einfluss auf das Endergebnis nimmt dies gilt z.b. für die Wahl der aufzuspaltenden Relationen usw. Das Ergebnis der Dekomposition ist nicht abhängigkeitstreu, nicht minimal und sehr reihenfolgeabhängig. Teilweise werden Attribute vollkommen getrennter Objekttypen in ein Relationenschema aufgenommen, Informationen eines Objekttyps dagegen auf mehrere Relationenschemata verteilt oder gar nicht berücksichtigt.

25 Datenbankentwurf Synthesealgorithmus Unterschiede zum Dekompositionsalgorithmus U: gegebene Attribute K: Schlüsselmenge F: funktionale Abhängigkeiten Synthese manipuliert zunächst nur die gegebenen FDs Dekomposition erzeugt finale Schemata aus während des Verfahrens erzeugten Schemata Synthese erzeugt die Schemata erst im letzten Schritt

26 Datenbankentwurf Synthesealgorithmus Vorteile: durch die Manipulation der FD Menge wird weitgehend eine Reihenfolgeunabhängigkeit erreicht außerdem ist die Abhängigkeitstreue leichter erfüllbar allerdings können nur FDs sinnvoll verwendet werden MVDs sind kontextabhängig und deshalb nicht so leicht umzuformen Vorgehen Eliminiere Redundanzen durch das Entfernen überflüssiger FDs und Attribute => FDs bsw. überflüssig, wenn sie sich aus anderen FDs herleiten lassen Fasse FDs mit gleicher linker Seite zu Äquivalenzklassen zusammen => aus diesen werden Relationenschemata angelegt

27 Datenbankentwurf Synthesealgorithmus Beispiel FDs: PersonalAuswNr und die Attribute Vorname, Nachname, PLZ und Geburtsdatum bestimmen sich gegenseitig funktional aufgrund dieser Äquivalenz werden nun bis auf die FD mit der linken Seite Bezeichnung die restlichen FDs in einer Äquivalenzklasse zusammengefasst

28 Datenbankentwurf Synthesealgorithmus Zwar werden alle Datenbankschem Eigenschaften erreicht, trotzdem können Attribute unterschiedlicher Objekttypen nicht getrennt werden. Außerdem werden MVDs nicht berücksichtigt.

29 Anfragesprachen

30 Anfragesprachen praktische Verwendbarkeit Strukturmangel im Ergebnis Ergebnis einer Anfrage im relationalen Datenmodell ist immer eine Relation aus den einzelnen Relationenschemata müssen somit wieder die Gesamtinformationen rekonstruiert werden diese Rekonstruktion bietet zwar die Gesamtinformationen, aber in unstrukturierter Darstellung bsw. Bücher >< Buch_Autor >< Buch_Stichworte >< Buch_Version

31 Anfragesprachen praktische Verwendbarkeit Keine Unterstützung komplexer Strukturen in der Anfrageformulierung Beispiel: Welche Bücher wurden von den Autoren Vossen und Witt zusammen geschrieben? SELECT ISBN FROM Buch_Autor WHERE Autor = Witt AND Autor = Vossen leere Ergebnismenge, da kein Tupel die Autoren Witt und Vossen gleichzeitig erfüllt Anfragen dieser Art sind zwar teilweise formulierbar, diese sind aber unkomfortabel und unübersichtlich

32 Anfragesprachen praktische Verwendbarkeit Notwendigkeit expliziter Verbundoperationen möchte man auf verschiedene Relationen verteilte Informationen gemeinsam nutzen, so muss man einen expliziten Verbund formulieren dies gilt auch dann, wenn die Zusammenhänge der Informationen in der Anwendungsmodellierung eigentlich klar ist

33 Relationenalgebra Fehlende Operationen auf Domänen Elemente einer Domäne werden als uninterpretierte, abstrakte Symbole aufgefasst zwar sind Abfragen wie A = 3 möglich, Rechenoperationen mit diesen Werten allerdings nicht Erweiterung der Relationenalgebra um Domänen Operationen

34 Relationenalgebra Verbunde mit Informationsverlust die Bildung eines Verbunds ist nicht immer informationserhaltend im Beispiel fällt der Student mit Matrikelnummer aus dem Ergebnis heraus, da er keine Hobbies hat ein solches Tupel wird als Dangling Type bezeichnet

35 Relationenalgebra das vorhergehende Problem kann durch die Einführung von Nullwerten gelöst werden ein OUTER JOIN nimmt dann jedes Tupel aus den Argumentenrelationen in die Ergebnisrelationen auf generelles Problem der Nullwerte - keine Unterscheidung von Wert nicht bekannt und Attribut für dieses Tupel nicht anwendbar diese Semantiken werden derzeit in keinem Datenbanksystem berücksichtigt

36 Erweiterung der Anfragesprachen Relationenalgebra und SQL sind für komplexere Anfragen nicht mächtig genug insbesondere die Forderung nach Sicherheit der Sprache ist hierfür verantwortlich Sicher ist eine Sprache dann, wenn jeder syntaktisch korrekte Ausdruck in endlicher Zeit ein endliches Ergebnis liefert somit implementieren diese Sprachen bsw. keine Schleifenkonstrukte, da diese der Sicherheit widersprechen würden um komplexere Operationen auf einem Datenbanksystem auszuführen, bleibt häufig nur die Einbettung in Programme einer höheren Programmiersprache

37 Einbettung Anwendungsprogramme greifen auf die Inhalte der Datenbank zu und führen Operationen aus, die durch die Anfragesprache nicht umsetzbar sind => bsw. fehlende Operationen auf Domänen außerdem kann die Leistungsfähigkeit der Anfragesprachen durch diese Einbettung erhöht werden, wenn bsw. Konzepte wie Rekursion außerhalb der Anfrageoperationen implementiert werden Problem: Datenbank und Programmiersprachenkonzepte passen häufig nicht zusammen => impedance mismatch Typsystem / Datenbankmodell Paradigmen der Programmiersprache (bsw. imperativ) vs. Datenbankoperationen (bsw. kalkülartig) Mismatch nur durch ähnlichen Satz von Konzepten vermeidbar

38 Update - Operationen

39 Update - Operationen Def. Update Operationen Operationen, die den in einer Datenbank gespeicherten Datenbestand verändern dürfen allgemeine Probleme von Update Operationen Tupelorientiertheit Anwendungsobjekte liegen meist auf mehrere Tupel verteilt vor Update Operationen sind allerdings meist nur in der Lage, festgelegte Tupelmengen einer Relation homogen zu ändern daraus resultieren Nachteile für Updates auf komplexen Objekten

40 Update - Operationen Deskriptive Spezifikation da man bei Updates meist auf die Konstrukte der Datenbanksprache angewiesen ist, entstehen ähnliche Probleme beim Update komplexer Objekte wie bei der Anfrage Eine Relation mit einem Update Kommando kann man nur Tupel einer Relation ändern, auch wenn die zum Objekt gehörenden Daten auf mehrere Relationen verteilt sind Nur homogene Änderungen auf alle ausgewählten Spezifikationen wird die gleiche Ersetzungsvorschrift angewendet

41 Update - Operationen dies führt dazu, dass Update Operationen sehr aufwendig sind und eine Vielzahl von Update Kommandos benötigen Updates sind auf explizite Integritätsbedingungen angewiesen - Legt man bsw. einen neuen Datensatz in einer Datenbank an, muss explizit überprüft werden, ob die durch Schlüssel definierten Integritätsbedingungen erfüllt sind Identifikation der Objekte über sichtbare Schlüssel - im relationalen Modell werden Objekte deskriptiv über ihre Schlüsselattribute bestimmt problematisch, wenn Schlüsselattribute benutzersichtbar und veränderbar sind Identifikation der Objekte kann bei Änderung nicht mehr vorgenommen werden

42 Update - Operationen Beispiel Autodatenbank: Lutz verkauft sein altes Auto und kauft ein neues Neues Auto in Autos einfügen Kennzeichen in der Besitzt Relation ändern neuer Besitzer des alten Autos in Besitzer als auch in Besitzt Relation

43 Update - Operationen diese Update Operationen sind vom Benutzer / Entwickler in dieser Reihenfolge anzugeben das System selber kann bsw. nicht zwischen Verkauf bzw. Ummeldung unterscheiden das Problem liegt in der Identifikation über benutzersichtbare Schlüssel verwendet man stattdessen abstrakte Werte (Objektidentitäten) für die Identifikation, können Werteänderungen und Änderungen von Beziehungen unterschieden werden diese Objektidentitäten sind nicht änderbar

44 Update - Operationen Objekte werden durch dargestellt wird nun bsw. ein Auto an einen neuen Besitzer verkauft, so ändern sich nur die Kanten zwischen Autos und Besitzer die Objektattribute bleiben unverändert

45 Update - Operationen Keine Möglichkeit zur Definition objektspezifischer Updates meist unterscheiden sich die Update Operationen für unterschiedliche Objekttypen dies gilt auch für Grundvoraussetzungen die durch den Objekttyp gegeben sind und für Auswirkungen auf andere Relationen sind nur für alle Objekttypen gleich definierte Update Operationen vorhanden, müssen explizite Integritätsbedingungen die verschiedenen Objekttypsemantiken retten auch hier wirken sich wieder die genannten Nachteile relationaler Systeme aus (bsw. fehlende Integritätsbedingungen, Fixierung auf einen speziellen Datenbankzustand usw.)

46 Zugriffspfade

47 Zugriffspfade klassische Dateiorganisationsformen für jede Relation in der konzeptuellen Darstellung wird eine Datei auf der internen Ebene angelegt nichtklassische Dateiorganisationsformen bilden die Relationen der konzeptuellen Darstellung nicht trivial ab es wird nicht für jede Relation eine getrennte Datei angelegt bsw. Cluster Strukturen => bilden mehrere Relationen in einer kompakten Datei ab Beispiel: Clustering für einen Buchrecord

48 Zugriffspfade Beispiel für klassische Organisationsformen

49 Zugriffspfade klassische Organisationsformen Vorteile schneller Zugriff auf Teilinformationen Nachteile große Anzahl benötigter Seiten dadurch zeitaufwendige Rekonstruktion durch Verbundoperationen nicht klassische Organisationsformen Vorteile geringe Anzahl von Seiten zur Speicherung komplexer Objekte geringer Aufwand bei Datenrekonstruktion (ohne Verbundoperationen) Nachteile langsamer Zugriff auf Teilinformationen (bsw. alle Cluster müssen durchlaufen werden)

50 Optimierung

51 Optimierung Algebraische Optimierung Umformung eines relationenalgebraischen Ausdrucks aufgrund eines Regelsystems der verwendeten Algebra Reihenfolge der anzuwendenden Regeln wird heuristisch bestimmt => aufgrund der Heuristik ungenau Kostenminimalität (bsw. Minimierung von Verbundoperationen / Selektionen / Seitenzugriffen) wird nicht erreicht keine Berücksichtigung interner Strukturen (bsw. Zugriffspfade) keine Ausnutzung von Intergritätsbedingungen => dadurch gehen wesentliche Informationen für die Optimierung verloren

52 Optimierung Tableauoptimierung Umformung eines relationenalgebraischen Ausdrucks in ein Tableau Matrix, mit je einer Zeile für jede im Ausdruck vorkommende Relation Minimierung des Tableaus aufgrund von Tableuabbildungen aus diesem Minimaltableau wird durch eine Rückübersetzungsstrategie ein algebraischer Ausdruck geformt, der eine minimale Anzahl an Verbundoperationen benötigt nur wenige Arten von Integritätsbedingungen werden berücksichtigt keine Optimierung der Anzahl / Reihenfolge von Selektionen eingeschränkte Anwendbarkeit (s. bsw. Intergritätsbedingungen) hohe Zeitkomplexität

53 Optimierung Interne Optimierung aufgrund von Informationen über Dateiorganisation / Zugriffspfade / Tupelanzahlen wird eine Reihenfolge der benötigten Operationen bestimmt Bestimmung / Implementierung der Abarbeitungsstrategie der einzelnen Operationen / Operatoren bei der konzeptuellen Optimierung werden Informationen der konzeptuellen Ebene ausgenutzt eine Kombination aus interner und konzeptueller Optimierung wäre demnach wünschenswert

54 Optimierung kostenbasierte Optimierung Integration von algebraischer und interner Optimierung zunächst Umformung analog zur algebraischen Optimierung => Umformung in äquivalenten Ausdruck hierbei werden mehrere alternative Anfragepläne erstellt Konkretisierung dieser Pläne durch verschiedene Implementierungsstrategien (auf interner Ebene) Abschätzung der Kosten (bsw. geschätzte Antwortzeit) für jede einzelne Strategie Auswahl der Strategie mit minimalen Kosten

55 Ende Fragen?