andere datenbankmodelle - cs.ubbcluj.rodianat/bd/curs/v11.pdf · erhöht werden, da die struktur...
TRANSCRIPT
![Page 1: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/1.jpg)
Andere DatenbankmodelleGraphendatenbanken
![Page 2: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/2.jpg)
Datenbankmodelle
• Relationale Datenbank (SQL)
• NoSQL (Not Only SQL): Implementierungen können folgendermaßen nach Datenmodell gegliedert werden:• Dokumentorientierte Datenbanken
• Objektdatenbanken
• Graphdatenbanken
• Key-Value-Datenbanken
• Multivalue-Datenbanken
• u.a.
![Page 3: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/3.jpg)
Relationale Datenbank
• Daten werden in Tabellen gespeichert
• Die Tabellen stehen zueinander in Beziehung (Fremdschlüssel)
• Nachteil:
• die Daten sind segmentiert →mit der Erhöhung der Anzahl der abgefragten Segmente verringert sich die Performanz der Abfrageverarbeitung
![Page 4: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/4.jpg)
NoSQL Objektorientierte Datenbank
• Objektdatenbankmanagementsystem wird als ODBMS gekennzeichnet
• Die zu einem Objekt gehörenden Daten werden im Objekt selbst abgelegt
• Die interne Organisation und Verwaltung der Daten wird komplett vom ODBMS übernommen
• Für die Abfrage und Manipulation der Daten stellt das ODBMS geeignete Objektsprachen bereit
• Nachteile:• Sind nur gering verbreitet und damit gibt es auch wenige Tools• Durch die hohe Komplexität eines einzelnen Objektes kann es bei
Manipulationsoperationen zu massiven Performanceproblemen kommen
![Page 5: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/5.jpg)
NoSQL Dokumentbasierte Datenbank
• Es gibt keine Relation zwischen den Daten
• Jeder Eintrag in der DB wird in einem eigenen Dokument gespeichert, das über eine eindeutige ID identifiziert wird
• Werden am häufigsten in Web-Applikationen eingesetzt
• Meistgenutzte Formate sind XML und Json
• In den unterschiedlichen Formate findet man meistens die Informationen als Key/Value -Paaren
• Jedes Dokument enthält seine eigene Struktur
• Nachteile:• Ungeeignet für komplexe Datenstrukturen• Der Aufwand bei der Programmierung, wenn man mit solchen DBs arbeitet kann
erhöht werden, da die Struktur der Dokumente nicht festgelegt ist• Viele in der relationalen oder objektorientierten DB zur Verfügung stehende
Funktionalitäten (z.B. Datenmanipulation) müssen individuell programmiert werden
![Page 6: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/6.jpg)
NoSQL Dokumentbasierte Datenbank -MongoDB• MongoDB – abgeleitet von “humongous”
• Ist eine dokumentorientierte NoSQL-Datenbank (geschrieben in C++)
• Eine der am weitesten verbreitete NoSQL-Datenbank
• Bietet eine weniger mächtige Abfragesprache an im Vergleich zu SQL• Nachteil: die Anwendugsschicht muss mehr Logik implementieren um die gleichen
Ergebnisse zu erzielen wie mit SQL-Datenbanken• Vorteil: die Arbeitslast kann einfacher auf mehrere Server verteilt werden (man
braucht nicht große Join Operationen)
• Es gibt kein Schema, das die Daten beschreibt• Vorteil: unterstützt agile Softwareentwicklung, da es einfacher ist, auf veränderte
Anforderungen zu reagieren• Nachteil: man muss selber wissen, wie die Daten strukturiert sind
![Page 7: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/7.jpg)
NoSQL Graphdatenbanken
• Motivation:• Fremdschlüssel führen zu Entwicklungoverhead: das Überprüfen der
Fremdschlüsseln ist aufwändig
• Das starre Schema der relationalen Datenbank fürht zu vielen NULL-Werten
• Viele JOINs nötig um Beziehungen wiederherzustellen
• Anwendung hat großen Einfluss auf Schemadesign
• Die Semantik von Beziehungen ist im Schema nicht ersichtlich
• Lösung: Graphendatenbank
![Page 8: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/8.jpg)
NoSQL Graphdatenbanken
• Graphendatenbank = eine Datenbank, die Graphen benutzt um stark vernetzte Informationen darzustellen und abzuspeichern
• Ein Graph besteht aus Knoten und Kanten, welche die Knoten verbinden
• Sowohl Knoten als auch Kanten können Eigenschaften (Properties) haben → dann redet man von einem Property-Graphen
• Da innerhalb eines solchen Graphen Kanten traversiert werdenkönnen, ist die Suche von Beziehungen unter den Knoten ungleichschneller als bei relationalen Datenbanken
![Page 9: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/9.jpg)
NoSQL Graphdatenbanken
• Graphendatenbanken können spezialisierte Graphenalgorithmenbenutzen, um komplizierte Datenbankabfragen zu vereinfachen (z.B. Dijkstra-Algorithmus oder A*-Algorithmus für kürzeste Weg)
• Es gibt keinen Standard für die Abfrage von Graphdatenbanken, daher gibt es unterschiedliche Abfragesprachen
![Page 10: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/10.jpg)
NoSQL Graphdatenbanken – Neo4j
• Neo4j ist eine Graphendatenbank welche Property-Graphen benutzt
• Neo4j ist schemafrei und gut skalierbar
• Die Community-Edition der Datenbank ist Open Source
• Abfragesprache: Cypher (besitzt aber auch eine REST-API für Abfragen)
• Beispiel von Abfrage:MATCH (actor:Person)-[:ACTED_IN]->(movie:Movie)
WHERE movie.title STARTS WITH "T"
RETURN movie.title AS title, collect(actor.name) AS cast
ORDER BY title ASC LIMIT 10;
• https://neo4j.com
![Page 11: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/11.jpg)
NoSQL Graphdatenbanken – Neo4j
• Interessante Anwendungen:• Soziale Beziehungen können sehr gut als Graph dargestellt werden• Geoinformationen eignen sich auch gut• Usw.
• Neo4j ist eine der populärsten Graphdatenbanken mit Kunden wie (https://neo4j.com/customers/ ):• eBay• Airbnb• Microsoft• IBM• NASA • Cisco
![Page 12: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/12.jpg)
Neo4j vs. relationale Datenbank
• Bemerkungen:• Die Fremdschlüsseln aus der relationalen Datenbank werden als Labels für die
Kanten benutzt (Beziehungen in dem Graphendatenbank)
• Aus einfachen Join Tabellen entstehen Beziehungen• Z.B. Enrolled(MatrNr, VorlNr) ⇒ ENROLLED
• Aus Join Tabellen mit Attributen entstehen Beziehungen mit Properties• Z.B. OrderDetails(OrderID, ProductID, Quantity, ..)⇒ ORDERS mit Property Quantity
![Page 13: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/13.jpg)
Neo4j vs. relationale Datenbank
• Beispiel von relationale Datenbank:Products(ProductID, ProductName, CategoryID, SupplierID, Price, ...)
Suppliers(SupplierID, CompanyName, ...)
Category(CategoryID, CategoryName, ...)
Customers(CustomerID, CompanyName, ...)
Employees(EmployeeID, LastName, FirstName, ...)
Orders(OrderID, CustomerID, EmployeeID, Date, ...)
OrderDetails(OrderID, ProductID, Quantity, ..)
![Page 14: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/14.jpg)
Neo4j vs. relationale Datenbank
• Beispiel von Graphendatenbank:
Employee
Cu
ProductCategory
Order
Supplier
Customer
![Page 15: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/15.jpg)
Neo4j vs. relationale Datenbank
![Page 16: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/16.jpg)
Cypher vs. SQL
• Finde alle Produkte:• SQL: SELECT p.* FROM Products p• Cypher: MATCH (p:Product) RETURN p
• Gebe die Namen und Preise aller Produkte sortiert aus:• SQL: SELECT p.ProductName, p.Price FROM Products p ORDER BY Price DESC• Cypher: MATCH (p:Product) RETURN p.productName, p.price ORDER BY price DESC
• Finde das Produkt “Schokolade”• SQL: SELECT * FROM Products WHERE ProductName = ‘Schokolade’• Cypher: MATCH (p:Product) WHERE p.productName = “Schokolade” RETURN p
oder MATCH (p:Product {productName:”Schokolade”}) RETURN p
![Page 17: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/17.jpg)
Cypher vs. SQL
• Finde die Kunde, die Schokolade gekauft haben• SQL: SELECT C.companyName FROM Customers
INNER JOIN Orders O ON C.customerID=O.customer.ID
INNER JOIN OrderDetails OD ON O.orderId = OD.orderId
INNER JOIN Products P ON OD.productId = P. productID
WHERE P.productName = ‘Schokolade’
• Cypher: MATCH (p:Product {productName:"Schokolade"})<-[: ORDERS]-(:Order)<-[:PURCHASED]-(c:Customer) RETURN c.companyName;
![Page 18: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/18.jpg)
Cypher vs. SQL
• Finde Produkte deren Name mit “C” anfängt und deren Preis > 100 ist• SQL: SELECT p.ProductName, p.UnitPrice FROM products P
WHERE p.ProductName LIKE ‘C%’ AND p.UnitPrice > 100
• Cypher: MATCH (p:Product) WHERE p.ProductName STARTS WITH “C” AND
p.unitPrice > 100 RETURN p.productName, p.unitPrice
oder mit regulären Ausdrücke: p.productName =~ “C.*”
![Page 19: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/19.jpg)
Cypher vs. SQL
• Outer Joins in Cypher -> OPTIONAL MATCH• SQL: SELECT p.ProductName FROM customers C
LEFT OUTER JOIN orders O ON C.CustomerId = O.CustomerId
LEFT OUTER JOIN order_details OD ON O.OrderId = OD.OrderId
LEFT OUTER JOIN products P ON OD.ProductId = P.ProductId
GROUP BY p.ProductName
• Cypher: MATCH (C:Customer)
OPTIONAL MATCH (P:Product) <- [PU:PRODUCT] – (:Order) <-[:PURCHASED] –(C) RETURN p.productName
![Page 20: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/20.jpg)
Cypher vs. SQL
• Indexe in Neo4J:• CREATE INDEX ON :Product(productName);
• Gruppierung in Neo4j ist implizit wenn man Aggregationsfunktionenbenutzt:• SQL: SELECT e.EmployeeId, count(*) as cnt
FROM Employee e INNER JOIN Order o ON o.EmployeeId=e.EmployeeId
GROUP BY e.EmployeeId
• Cypher: MATCH (:Order) <-[:SOLD] – (e:Employee)
RETURN e. EmployeeId, count(*) AS cnt
![Page 21: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/21.jpg)
Cypher vs. SQL
• Wenn man alle Angestellten aus einer Region sehen will:• In Cypher gibt es collect – eine Aggregationfunktion die eine Collection von
Werte erstellt (list,array)
• SQL: SELECT e.LastName, t.Description
FROM Employee e INNER JOIN EmployeeTerritory et ON ...
INNER JOIN Territory t ON ...
• Cypher: man kann das Ergebnis in derselben Form ausgeben oder:
MATCH (t:Territory) <- [:IN_TERRITORY] – (e:Employee)
RETURN t.description, collect(e.lastName)
![Page 22: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/22.jpg)
Cypher vs. SQL
• Füge einen neuen Produkt ein• SQL: INSERT INTO Product (ProductName) VALUES (‘Laptop’)
• Cypher: CREATE (p:Product {productName:“Laptop“})
• Dieselbe Methode kann benutzt werden auch um neue Properties zu einem Knoten einzufügen (ohne ALTER TABLE wie in SQL wenn man eine neue Spalte einfügen muss)
![Page 23: Andere Datenbankmodelle - cs.ubbcluj.rodianat/BD/curs/V11.pdf · erhöht werden, da die Struktur der Dokumente nicht festgelegt ist •Viele in der relationalen oder objektorientierten](https://reader036.vdocuments.pub/reader036/viewer/2022081323/5caa4ff288c993e3548b6836/html5/thumbnails/23.jpg)
Schlussfolgerungen
• Willst du das durchschnittliche Einkommen berechnen?
Frage eine relationale Datenbank ab.
• Brauchst du einen Onlineshop?
Benutze eine Key-Value-Datenbank.
• Willst du strukturierte Informationen über ein Produkt speichern?
Benutze eine Dokumentbasierte Datenbank.
• Willst du beschreiben wie ein Benutzer aus Punkt A zu Punkt B gekommen ist?
Benutze eine Graphdatenbanken.
Hauptidee: Wenn wir das Datenbankmodell auswählen, sollten wir sowohl das Ziel unserer Applikation, als auch die Struktur der Daten, die wir verwalten wollen, berücksichtigen!