andere datenbankmodelle - cs.ubbcluj.rodianat/bd/curs/v11.pdf · erhöht werden, da die struktur...

Andere DatenbankmodelleGraphendatenbanken

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.

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

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

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

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

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

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

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

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

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

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

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, ..)

Neo4j vs. relationale Datenbank

• Beispiel von Graphendatenbank:

Employee

Cu

ProductCategory

Order

Supplier

Customer

Neo4j vs. relationale Datenbank

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

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;

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.*”

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

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

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)

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)

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!