10 Alternative Datenmodelle und neuere Entwicklungen

Transkript

1 10 Alternative Datenmodelle und neuere Entwicklungen Informationssysteme füringenieure (ISI) Herbstsemester 2016 R. Marti

2 Limitationen des Relationenmodells 1. Normalform: Tupel sind "simple Objekte" "komplexe Objekte", d.h. Objekte mit "komplexen" Attributwerten (z.b. Listen, Arrays, Mengen) sind für verschiedene DB-Anwendungen wünschbar Die Abbildung von Datenstrukturen in modernen (oft objektorientierten) Programmiersprachen auf relationale DB Strukturen ist aufwendig (sog. impedance mismatch) Subtypen und Vererbung (sowie allenfalls Überschreibung von Methoden) werden nicht direkt unterstützt 2

3 Reminder: Wann ist eine Programmiersprache (PL) OO? OO = Objekt-Orientiert Eigenschaften wie prozedurale / funktionale Programmiersprachen à la C, Pascal und Lisp, insbes. "komplexe" Datenstrukturen wie struct (record), array, evt. Listen Datenkapselung [data encapsulation, auch information hiding] Zugriff auf einzelne Datenfelder eines Objekts erfolgt ausschliesslich oder tendentiell (je nach "Sichtbarkeit") über Prozeduren, die für dieses Objekt definiert sind Vererbung [inheritance], Erweiterung [extension] und Überschreibung [override] Möglichkeit zur Definition von Subtypen (vgl. ER-Modell), welche - Datenfelder und Prozeduren des Supertyps erben - zusätzliche Datenfelder und Prozeduren haben können - bestehende Prozeduren des Supertyps überschreiben (d.h. umdefinieren) können dynamische Bindung von Prozeduren Prozeduren, die für den Supertyp definiert sind, werden zur Laufzeit (d.h. dynamisch) gemäss dem jeweiligen Subtyp eines Objekts ausgewählt (d.h. an das Objekt gebunden) 3

4 Beispiel: Ein ER Modell für eine Datenbank Person Department mit Prozedur (*) Subtyping Customer Employee Project mit mehrwertigen Attributen (*) direkte m:m Beziehung 4

5 Java Modell auf Business Logic Layer class Person { // Disclaimer: this may not be absolutely correct Java int persno; String name; String address; Date birthdate; int age() { // a procedure which computes the age of a person return Calendar.getTime().getYear() birthdate.getyear(); } } class Employee extends Person { // a subtype int salary; Department dept; // a reference to a Department object Set<Project> projs; // a set of references to Project objects Set<String> childnames; // a set of strings Person Department } Person Department class Department { int deptno; String name; Set<Employee> emps; } Customer Employee Customer Employee Project Project 5

6 Relationales Modell ("gängige" Alternative) create table Person ( create table Department ( persno integer primary key, persno integer primary key, name varchar(40) not null, name varchar(40) not null address varchar(100) not null, ); birthdate date not null ); create table Employee ( persno integer primary key, -- primary key of supertype salary integer not null, deptno integer, foreign key persno references Person, foreign key deptno references Department -- a "reference" to a Department ); create table EmpChild ( persno integer not null, childname varchar not null, primary key (persno, childname), foreign key persno references Employee ); Person Person Department Department create table ProjAssig ( Customer Employee Project persno integer not null, Customer Employee Project projno integer not null, primary key (persno, projno), foreign key persno references Employee, foreign key projno references Project EmpChild ProjAssig ); 6

7 Object Relational Mapping (ORM) Mögliche Übersetzung des Beispiels in Relationen und notwendige Anfragen zur Darstellung eines Objekts (z.b. eines Employee) Person(persNo, name, address, birthdate) - age erfordert Berechnung in SELECT-Liste Employee(persNo, salary, deptno) - name, address etc. erfordern Join mit Person - projs erfordert Join mit ProjAssigmnt und evt. mit Project - children erfordert Join mit EmpChild - dept erfordert evt. Join mit Department EmpChildren(persNo, childname) Project(projNo, ) ProjAssig(persNo, projno) Department(deptNo, name) - emps erfordert Join mit Employee 7

8 Möglichkeiten zur Realisierung von ORM Programmierung mit JDBC (evt. SQLJ) "von Hand" erfordert relativ viel repetitiven Programm-Code Verwendung eines ORM-Toolkits, welcher Programm-Code für Mappings aufgrund einer deklarativen Beschreibung erzeugt z.b. mybatis, Hibernate zusätzlicher Lernaufwand, evt. etwas weniger performant Verwendung eines Objekt-orientierten Datenbanksystems Objekt-relationales Datenbanksystem (OO-Erweiterungen von SQL) Objekt-orientiertes Datenbanksystem gemäss ODMG Standard (ODL = Object Definition Language, OQL = Object Query Language) Persistent Java (C++, Smalltalk) Data Store 8

9 Reminder: Dienstleistungen von DB-Systemen (DBMSs) persistente Verwaltung sehr grosser Datenmengen (Terabytes) auf Sekundärspeicher, inkl. Fehlertoleranz (backup, recovery) deklarativer, mengenorientierter Datenzugriff Mehrbenutzerbetrieb (concurrency control) Datenintegritätskontrolle (semantic integrity) Zugriffskontrolle, Datenschutz (authorization) Optimierung der Datenzugriffe und Anfragen (access path selection, query optimization) Datenunabhängigkeit von Programmen (data independence) bei Änderungen physischer Datenstrukturen und Zugriffsoptimierung bei Erweiterungen und Modifikationen logischer Datenstrukturen 9

10 Wann ist ein Datenbanksystem (DBMS) OO Unterstützung der Eigenschaften von Datenbanksystemen (DBMSs) Unterstützung der Eigenschaften von OOPL (anfängl insbes auf Basis von Smalltalk, C++ oder CLOS; heute Java) komplexe Datenstrukturen Datenkapselung Vererbung dynamische Bindung Objektidentität vom DBMS erzeugte OIDs (Object IDentifiers) als Primärschlüssel Berechnungsvollständige DB Programmiersprache 10

11 ODMG Object Definition Language (ODL) class Person ( extent PersonExtent, key persno ) { attribute int persno; attribute string name; attribute string address; attribute date birthdate; int age(); // an interface of a procedure } class Employee extends Person { // a subtype attribute int salary; relationship Department dept // a reference to a Department object inverse Department::emps; relationship set(project) projs // a set of references to Project objects inverse Projects::emps; attribute set(string) childnames; // a set of strings } class Department ( extent DeptExtent, key deptno ) Person Person { attribute int deptno; attribute string name; relationship set(employee) emps inverse Employee::dept; } Customer Employee Department Department Customer Employee Project Project 11

12 ODMG Object Query Language (OQL): Beispiele (1) Einfache Anfragen Die Anfragesprache OQL finde die Namen der C4-Professoren select p.name from p in AlleProfessoren where p.rang = C4 ; Generiere Namen- und Rang-Tupel der C4-Professoren select struct(n: p.name, r: p.rang) from p in AlleProfessoren where p.rang = C4 ; Geschachtelte Anfragen und Partitionierung select struct(n: p.name, a: sum(select v.sws from v in p.liest)) from p in Alle Professoren where avg(select v.sws from v in p.liest) > 2; R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen 12

13 ODMG Object Query Language (OQL): Beispiele (2) Pfadausdrücke in OQL-Anfragen select s.name from s in AlleStudenten, v in s.hört where v.gelesenvon.name = Sokrates ; Visualisierung des Pfadausdruckes hört gelesenvon Studenten Vorlesungen Professoren Name ein längerer Pfadausdruck einevorlesung.gelesenvon.residiertin.größe Vorlesungen Professoren Räume float R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen 13

14 ODMG Object Query Language (OQL): Beispiele (3) Erzeugung von Objekten Vorlesungen(VorlNr: 5555, Titel: Ethik II, SWS: 4, gelesenvon: ( select p from p in AlleProfessoren where p.name = Sokrates )); Operationsaufruf in OQL-Anfragen select a.name from a in AlleAngestellte where a.gehalt() > ; R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen 14

15 Objekt-orientierte und objekt-relationale DBMS OODB: unterstützen meist ODL und OQL (konzeptionell eine Erweiterung von SQL) ORDB: unterstützen "plain old" SQL mit relationalen Erweiterungen 15

16 Die NoSQL Bewegung Treiber Limitationen des relationalen Datenmodells (vgl. OO Datenmodelle) Bewältigung sehr grosser Datenmengen ("Big Data") mit sehr vielen Benutzern (vgl. Google, amazon, facebook, Twitter) NoSQL steht nicht notwendigerweise für "no SQL" (= "kein SQL") sondern allenfalls für not only SQL Datenmodelle: uneinheitlich, aber nicht relational (bzw."mehr als relational") key-value databases: an ein Objekt werden "beliebige" Listen von Attribut-Werte Paaren (key-value lists, auch property lists) angehängt graph databases: Knoten ( Entitäten) und Kanten ( binäre Beziehungen) document databases: Datenbank von (evt. verketteten) Dokumenten columnar databases: +/ relational, Daten werden nicht reihen- sondern kolonnenweise gespeichert je nach Anwendung substantielle Vorteile bezügl. Performanz und Platzbedarf Daten sind typischerweise verteilt und werden parallel verarbeitet 16

17 Grundidee von Key-Value Datenbanken Übliche Darstellung (auch horizontale Darst.) Person PersNo PersName FirstName Address BirthDate 3 'McNealy' 'Scott' 'Atherton' Reifizierte Darstellung (auch vertikale Darst., Objekt-Attribut-Wert Tripel) Person PersAttrValues PersAttr PersNo AttrValue AttrNo AttrName 3 'McNealy' 1 'PersName' 'BirthDate' Objekt mit Key-Value Liste (JSON Format) Person( id:3, [PersName:'McNealy', FirstName:'Scott',, BirthDate: ] ) 17

18 Semantic Web: Resource Description Framework (RDF) Triple-Datenmodell (Subjekt, Prädikat, Objekt) Meist graphische Visualisierung Subjekte und Objekte sind Knoten Prädikate sind gerichtete Kanten Von Subjekt-Knoten nach Objekt Knoten R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen

19 Beispiel-RDF-Graph R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen

20 CAP Consistency, Availability, Partition Tolerance CAP Theorem bei verteilten und replizierten Daten können nur 2 der 3 folgenden Eigenschaften - Konsistenz (C = Consistency) - Verfügbarkeit (A = Availability) A - Toleranz bei Netzwerkpartition (P = Partitioning) gleichzeitig garantiert werden C P in vielen (verteilten) NoSQL Systemen wird darum das Kriterium Konsistenz durch "eventual consistency" ersetzt: ein Update muss nur "eventually (d.h. nach einer gewissen Zeit) auf allen Datenkopien nachgeführt werden 20

21 Momentaner Hype: Big Data (1) 21

22 Momentaner Hype: Big Data (2) "Definition" (eher: Charakterisierung) von Big Data: The 3 Vs Volume: 100 Terabyte ( Byte) oder gar 1 Petabyte (10 15 Byte). Volumen ist relativ, ändert über die Zeit. Berücksichtigung "aller" Daten, nicht nur Stichproben (samples). Speicherung + Verarbeitung benötigen viele Disks + CPUs Variety: nicht nur strukturierte, auch unstrukturierte Daten (insbes. Text). > 80% der Daten sind unstrukturiert. Entdecken von Strukturen in unstrukturierten Daten Velocity: nicht nur statische (teilweise "abgestandene") Daten, sondern "real-time" Daten sowie dynamische Datenströme (data streams). "sofortige" Sichtbarkeit aller Änderungen in gesamter Unternehmung. Ticker von Aktienkursen, Sensor Daten, Bewegungen mobiler Devices 22

23 Datenbank versus Datenstrom R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen

24 Technische Sicht auf Big Data neues "Infrastruktur-Ökosystem" für Big Data entwickelt oft Open Source HDFS (Hadoop Distributed File System) Hadoop Implementation von Google's MapReduce Paradigma Abfragesprachen wie HiveQL (angelehnt an SQL) 24

25 Map-Reduce Framework um die Parallelität (mehrere Datenkopien, sehr viele Prozessoren) ausnützen zu können, sollten Anfragen in ein sog. Map-Reduce Framework "gegossen" werden Figure 1.6 The map and reduce functions are ways of partitioning large datasets into smaller chucks that can be transformed on isolated and independent transformation systems. 25

26 Map-Reduce R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen

27 Join mit Map-Reduce R. Marti A. Kemper & A. Eickler ISI Alterntative Datenmodelle und neuere Entwicklungen