Datenbanken Unit 12: NoSQL-Datenbanken und XML

Transkript

1 Datenbanken Unit 12: NoSQL-Datenbanken und XML 18. VI. 2018

2 Outline 1 Organisatorisches 2 NoSQL: Diverse Ansätze 3 NoSQL: Objekt-relationale Datenbanken Object-Relational Impedance Mismatch Objekt-relationale Erweiterungen 4 XML 5 Normalisierung

4 Organisatorisches Nächste Woche Fragestunde in der VO UE entfällt nächste Woche

6 NoSQL NoSQL: Sammelbegriff für alternative Datenbanklösungen, die das traditionelle relationale Schema nicht implementieren. NoSQL fasst völlig unterschiedliche Ansätze für Lösung unterschiedlicher Probleme zusammen: Verteilte Datenbanken Graph Datenbanken Key-Value und Document Stores (Wide) Column Stores Objekt- und objektrelationale Datenbanken

7 Verteilte Datenbanken Große Datenmengen können oft nicht mehr auf einem Rechner gespeichert werden. verteilte Datenbanken Umsetzung wirft mehrere technische Probleme auf: Wie soll aufgeteilt werden? (Fragmentierung und Allokation) Wie werden Anfragen bearbeitet? Wie können Transaktionen konsistent durchgeführt werden?

8 Key-Value und Document Stores Key-Value Store: funktioniert wie Map in Java, wobei Value sehr große Datei sein kann Die Values haben i.a. keinen einheitlichen Daten- bzw. Dateityp. Zugriff erfolgt immer über Key. Document Stores: verallgemeinern Key-Value Store Suchmöglichkeit auch über Values

9 Graph Datenbanken Graph Datenbanken erlauben die Speicherung vernetzter Daten (Graphen). Speicherung von Datenobjekten als Graph Sowohl Knoten als auch Kanten besitzen Attribute. Graphenspezifische Abfragen schneller als in relationem System. Beispiele: Welche Schauspieler haben mit Christopher Walken in einem Film gespielt? Wie komme ich am schnellsten mit öffentlichen Verkehrsmitteln von Mariazell nach Kirchberg in Tirol? Welche Artikel haben Kunden gekauft, die diesen Artikel gekauft haben?

10 Row Store vs. Column Store Typischerweise werden Tabellen zeilenweise gespeichert. (s. Bsp. auf Folien von A. Kemper)

11 Row Store vs. Column Store Typischerweise werden Tabellen zeilenweise gespeichert. Bei vielen Spalten, kann es aus Performancegründen u.u. auch besser sein, spaltenweise zu speichern: (s. Bsp. auf Folien von A. Kemper)

12 Row Store vs. Column Store Typischerweise werden Tabellen zeilenweise gespeichert. Bei vielen Spalten, kann es aus Performancegründen u.u. auch besser sein, spaltenweise zu speichern: Die meisten Abfragen betreffen nur wenige Spalten. (s. Bsp. auf Folien von A. Kemper)

13 Row Store vs. Column Store Typischerweise werden Tabellen zeilenweise gespeichert. Bei vielen Spalten, kann es aus Performancegründen u.u. auch besser sein, spaltenweise zu speichern: Die meisten Abfragen betreffen nur wenige Spalten. Spaltenwerte sind ähnlicher und können leichter komprimiert werden. (s. Bsp. auf Folien von A. Kemper)

14 Row Store vs. Column Store Typischerweise werden Tabellen zeilenweise gespeichert. Bei vielen Spalten, kann es aus Performancegründen u.u. auch besser sein, spaltenweise zu speichern: Die meisten Abfragen betreffen nur wenige Spalten. Spaltenwerte sind ähnlicher und können leichter komprimiert werden. Verwendung von Wörterbuch-Tabelle (s. Bsp. auf Folien von A. Kemper)

16 Object-Relational Impedance Mismatch Beispiel: Bücherdatenbank

17 Object-Relational Impedance Mismatch Beispiel: Bücherdatenbank Wir führen IDs für Autoren, Bücher und Keywords ein. Dann: eine Tabelle für jeden Entitätstyp (mit den IDs als Primärschlüssel): Autoren: {[a_id, Name]} Bücher: {[b_id, Titel, Verlag]} Keywords: {[k_id, Keyword]} eine Tabelle für jede Relation: schreibt: {[a_id, b_id]} hat_keyword: {[b_id, k_id, Gewicht]}

18 Object-Relational Impedance Mismatch Beispiel: Bücherdatenbank Wir führen IDs für Autoren, Bücher und Keywords ein. Dann: eine Tabelle für jeden Entitätstyp (mit den IDs als Primärschlüssel): Autoren: {[a_id, Name]} Bücher: {[b_id, Titel, Verlag]} Keywords: {[k_id, Keyword]} eine Tabelle für jede Relation: schreibt: {[a_id, b_id]} hat_keyword: {[b_id, k_id, Gewicht]} brauchen fünf (!) Tabellen für einen Entitätstyp

19 Object-Relational Impedance Mismatch Beispiel: Bücherdatenbank Wir führen IDs für Autoren, Bücher und Keywords ein. Dann: eine Tabelle für jeden Entitätstyp (mit den IDs als Primärschlüssel): Autoren: {[a_id, Name]} Bücher: {[b_id, Titel, Verlag]} Keywords: {[k_id, Keyword]} eine Tabelle für jede Relation: schreibt: {[a_id, b_id]} hat_keyword: {[b_id, k_id, Gewicht]} brauchen fünf (!) Tabellen für einen Entitätstyp

20 Object-Relational Impedance Mismatch Object-Relational Impedance Mismatch brauchen fünf (!) Tabellen für einen Entitätstyp Object-Relational Impedance Mismatch : Objekte lassen sich im allgemeinen nicht gut in relationen Datenbanken abbilden.

21 Object-Relational Impedance Mismatch Object-Relational Impedance Mismatch brauchen fünf (!) Tabellen für einen Entitätstyp Object-Relational Impedance Mismatch : Objekte lassen sich im allgemeinen nicht gut in relationen Datenbanken abbilden. Verschiedene Lösungsansätze: Objektdatenbanken Java Persistence Library: speichert Objekte automatisch in passender relationaler Datenbank

22 Objekt-relationale Erweiterungen Objekt-relationale Datenbanken erweitern relationale Datenbanktheorie mit objektorientierten Ideen: Erweiterungen: Large Objects (z.b. Datentyp blob in MySQL)

23 Objekt-relationale Erweiterungen Objekt-relationale Datenbanken erweitern relationale Datenbanktheorie mit objektorientierten Ideen: Erweiterungen: Large Objects (z.b. Datentyp blob in MySQL) Mengenwertige Attribute

24 Objekt-relationale Erweiterungen Objekt-relationale Datenbanken erweitern relationale Datenbanktheorie mit objektorientierten Ideen: Erweiterungen: Large Objects (z.b. Datentyp blob in MySQL) Mengenwertige Attribute Geschachtelte Relationen: Relationen als Attribute

25 Objekt-relationale Erweiterungen Objekt-relationale Datenbanken erweitern relationale Datenbanktheorie mit objektorientierten Ideen: Erweiterungen: Large Objects (z.b. Datentyp blob in MySQL) Mengenwertige Attribute Geschachtelte Relationen: Relationen als Attribute Typendeklaration: Definition eigener Datentypen (ähnlich wie Klassendefinition in objektorientierter Sprache)

26 Objekt-relationale Erweiterungen Objekt-relationale Datenbanken erweitern relationale Datenbanktheorie mit objektorientierten Ideen: Erweiterungen: Large Objects (z.b. Datentyp blob in MySQL) Mengenwertige Attribute Geschachtelte Relationen: Relationen als Attribute Typendeklaration: Definition eigener Datentypen (ähnlich wie Klassendefinition in objektorientierter Sprache) Referenzen auf andere Tupel oder Objekte

27 Objekt-relationale Erweiterungen Objekt-relationale Datenbanken erweitern relationale Datenbanktheorie mit objektorientierten Ideen: Erweiterungen: Large Objects (z.b. Datentyp blob in MySQL) Mengenwertige Attribute Geschachtelte Relationen: Relationen als Attribute Typendeklaration: Definition eigener Datentypen (ähnlich wie Klassendefinition in objektorientierter Sprache) Referenzen auf andere Tupel oder Objekte Vererbung

28 Objekt-relationale Erweiterungen Objekt-relationale Datenbanken erweitern relationale Datenbanktheorie mit objektorientierten Ideen: Erweiterungen: Large Objects (z.b. Datentyp blob in MySQL) Mengenwertige Attribute Geschachtelte Relationen: Relationen als Attribute Typendeklaration: Definition eigener Datentypen (ähnlich wie Klassendefinition in objektorientierter Sprache) Referenzen auf andere Tupel oder Objekte Vererbung SQL:1999 Standardisierung des objekt-relationalen Datenmodells (bisher in kommerziellen Systemen nur teilweise und mit uneinheitlicher Syntax umgesetzt)

30 Relationales Datenmodell Das relationale Datenmodell ist rigide: Tabellenstruktur ist vorgegeben. fixe Anzahl von Spalten Spalten haben vorgegebenen Typ. ein Datensatz pro Zeile

31 XML: Flexible Datenstruktur XML (extensible Markup Language) ist im Unterschied dazu so flexibel wie möglich: XML-File legt nicht nur die Daten sondern auch die Struktur fest. Beispiel: <info>der <tier typ="vogel">darwinfink</tier> ist ein sehr zutraulicher Vogel, der auf den <ort typ="insel">galapagos-inseln</ort> lebt. </info>

32 XML: Flexible Datenstruktur XML (extensible Markup Language) ist im Unterschied dazu so flexibel wie möglich: XML-File legt nicht nur die Daten sondern auch die Struktur fest. Trennung von Struktur und Präsentation erweiterbar und anpassbar Es gibt auch Abfragesprachen für XML. Ein XML-File ist ein Text-Dokument.

33 XML: Anwendungen Verwendung: Hochstrukturierte Daten (Tabellen) Semistrukturierte Daten Datenaustausch Web-Dokumente (html) Grafiken (svg) Formeln

34 XML: Flexible Datenstruktur Weiteres Beispiel: <?xml version="1.0" encoding="iso "?> <planetensystem> <stern typ="g2"> <name>sonne</name> <durchmesser> </durchmesser> </stern> <planet> <name>venus</name> <durchmesser>12102</durchmesser> <entfernung> <min>107.1</min> <max>109.0</max> </entfernung>

35 XML: Flexible Datenstruktur Weiteres Beispiel: <?xml version= 1.0 encoding= UTF-8?> <PEOPLE> <PERSON personid=p1retired="yes"> <NAME>Mark Wilson</NAME> <ADDRESS> <STREET>Somewhere Circle</STREET> <NR>911</NR> <CITY>Canberra</CITY> <COUNTRY>Australia</COUNTRY> </ADDRESS> </PERSON> <PERSON personid=p2»

36 XML: Flexible Datenstruktur Weiteres Beispiel (svg-grafikfile): <?xml version= 1.0 encoding= UTF-8?> <svg xmlns=" <rect x="10"y="10"width="200"height="225" stroke="blackfill=transparentßtroke-width="1px"/> <circle cx="110cy="110r="75" stroke="blackfill="yellow"/> <circle cx="75cy="80r="10" stroke="blackfill="black"/> <circle cx="145cy="80r="10" stroke="blackfill="black"/> <path d=m74,130 A35,35 0 0,0 149,130" stroke="blackßtroke-width="6pxfill=transparent"/> <text x="60"y="210font-family="sans-serif"> Hello SVG!</text> </svg>

37 XML: Flexible Datenstruktur Weiteres Beispiel (svg-grafikfile): <?xml version= 1.0 encoding= UTF-8?> <svg xmlns=" <rect x="10"y="10"width="200"height="225" stroke="blackfill=transparentßtroke-width="1px"/> <circle cx="110cy="110r="75" stroke="blackfill="yellow"/> <circle cx="75cy="80r="10" stroke="blackfill="black"/> <circle cx="145cy="80r="10" stroke="blackfill="black"/> <path d=m74,130 A35,35 0 0,0 149,130" stroke="blackßtroke-width="6pxfill=transparent"/> <text x="60"y="210font-family="sans-serif"> Hello SVG!</text> </svg>

38 VO + UE: Datenbeschreibungssprachen Einführung in XML u.a.: Lehrveranstaltung Datenbeschreibungssprachen (Antenreiter) Wenn Sie nicht hingehen: XML ist ein Standard. XML-Schnittstelle vs. proprietäre Schnittstelle

40 Normalisierung: Weiteres Beispiel Entwerfen Sie eine Datenbank einer Ticketagentur für Pop-/Rock-Konzerte. Für jedes Konzert sollen die spielenden Bands, das Datum und die Beginnzeit, das Land, die Stadt sowie der Veranstaltungsort gespeichert werden. Weiters soll der Ticketpreis hinterlegt werden, wobei Sie davon ausgehen können, dass dieser für jedes Konzert einheitlich ist. Für jeden Kunden sollen Name und Adresse gespeichert werden sowie wieviele Tickets für welches Konzert bestellt wurden.

41 Normalisierung: Tickets für Konzerte Manchmal bekommt man kein gutes Schema, wenn man die Normalformen der Reihe nach durchgeht. Beispiel: Ticket_no Concert_no Band Es gibt folgende FDs und MVDs: Ticket_no Concert_no Ticket_no Band Concert_no Band...

42 Normalisierung: Tickets für Konzerte Manchmal bekommt man kein gutes Schema, wenn man die Normalformen der Reihe nach durchgeht. Beispiel: Ticket_no Concert_no Band Es gibt folgende FDs und MVDs: Ticket_no Concert_no Ticket_no Band Concert_no Band... Der Dekompositionsalgorithmus für 4NF auf die letzte MVD angewandt gibt ein gutes Datenbankschema.

43 Verallgemeinerter Dekompositionsalgorithmus für 4NF Gegeben: Relation R, Menge F von MVDs Wir wollen: Zerlegung R 1,..., R n in 4NF Verallgemeinerter Dekompositionsalgorithmus: Initialisiere Z := {R}; while (es gibt R i in Z, das nicht in 4NF) do 1 Finde MVD α β in R i mit α β = und α R i. 2 Zerlege R i in R i1 := α β und R i2 := R i β. 3 Ersetze R i in Z durch R i1 und R i2, d.h. Z := (Z {R i }) {R i1, R i2 }. (Nachdem jede Relation in 4NF auch in BCNF ist, gibt es Fälle, wo eine 4NF Zerlegung nicht abhängigkeitserhaltend ist.)

44 Normalisierung: Tickets für Konzerte Beispiel: Ticket_no Concert_no Band Es gibt folgende FDs und MVDs: Ticket_no Concert_no Ticket_no Band Concert_no Band... Achtung: Wählt man eine andere FD/MVD für Zerlegung erhält man ein schlechteres Datenbankschema. (Zur Erinnerung: 4NF ist nicht immer abhängigkeitserhaltend, sodass es einen Unterschied machen kann, welche FD für Zerlegung gewählt wird!)

45 Normalisierung: Wartungszeiten für Anlagen Im Beispiel 8.4 ist dasselbe passiert: Item_id Time_stamp Wartungszeit. Es gelten folgende FDs: Anlage Wartungszeit Item_id, Time_stamp Anlage Item_id, Time_stamp Wartungszeit..

46 Normalisierung: Wartungszeiten für Anlagen Im Beispiel 8.4 ist dasselbe passiert: Item_id Time_stamp Wartungszeit. Es gelten folgende FDs: Anlage Wartungszeit Item_id, Time_stamp Anlage Item_id, Time_stamp Wartungszeit.. Besser ist es offensichtlich, die Wartungszeiten mit den Anlagen zu speichern: Anlage. Wartungszeit.

47 Normalisierung: Fazit Manchmal ist es eine gute Idee, aus FDs α β gleich eine Tabelle mit Spalten α und β zu extrahieren und β aus der ursprünglichen Tabelle zu entfernen (vgl. Dekompositionsalgorithmus), auch wenn dies nicht der nächste Schritt in der Normalisierungsreihenfolge ist.