15.2.2007Gunter Saake1 Maßgeschneiderte Datenbanksysteme – nach 20 Jahren immer noch ein Traum? Gunter Saake Festkolloquium für Prof. Dr. H.-D. Ehrich.

Präsentation zum Thema: "15.2.2007Gunter Saake1 Maßgeschneiderte Datenbanksysteme – nach 20 Jahren immer noch ein Traum? Gunter Saake Festkolloquium für Prof. Dr. H.-D. Ehrich."—  Präsentation transkript:

1 15.2.2007Gunter Saake1 Maßgeschneiderte Datenbanksysteme – nach 20 Jahren immer noch ein Traum? Gunter Saake Festkolloquium für Prof. Dr. H.-D. Ehrich Braunschweig, 15.2.2007

2 15.2.2007Gunter Saake2 Warum maßgeschneiderte Software? Ressourcen-Beschränkte Systeme Kosten, Energie, Platz, …. Individuelle Systeme versus individuelle Nutzung Ungenutzte Funktionalität als Risiko Wartungs- / Kontroll- / Testaufwand wächst mit Funktionsumfang Maßgeschneiderte Systeme sind im Ingenieurbereich State-of-the-Art! Automobil-Varianten pro Variante existieren 1.2 Audi

3 15.2.2007Gunter Saake3 Maßgeschneiderte Datenhaltung Kommerzielle DBMS Oracle, IBM DB2, SQL Server, … Eierlegende Wollmilchsäue Obermenge aller denkbaren, kommerziell einsetzbaren Funktionalität Individuelle Datenhaltungs-Software Selbst gestrickt: teuer, schwer wartbar,.. Maßgeschneiderte Software für Datenhaltung Variantenfertigung, DBMS-Produkt-Familie Gibt es noch nicht!

4 15.2.2007Gunter Saake4 Motivation für Embedded Databases 98 % aller im Einsatz befindlichen Rechnersysteme sind eingebettete Systeme Extreme Ressourcenbeschränkung Hohe Heterogenität von Hard- und Software Ubiquitous und Pervasive Computing Sensornetzwerke, Gerätesteuerung Datenaufkommen in diesem Bereich wächst ständig

5 15.2.2007Gunter Saake5 Motivation: Embedded Databases im Automobil Großer Teil der Kosten und der Wertschöpfung in Automobilen bereits heute durch Software-Systeme Viele Bereiche benötigen Persistenz Fahrtenbuch Navigationssystem Fahrer-Profile / Personalisierung Kilometerzähler (Recovery! Redundanz! Security!) …

6 15.2.2007Gunter Saake6 Informatik im Automobil Wertschöpfungsanteil der Elektronik im Fahrzeug: ca. 40% Entwicklungskosten eines Steuergeräts: 50% Software-Erstellungskosten Speicherbedarf im Oberklassewagen Um 1995: 1 MB (5 vernetzte Steuergeräte) Heute: 80 MB (über 70 vernetzte Steuergeräte) Zukünftig: 10 GB

7 15.2.2007Gunter Saake7 Computer im Automobil

8 15.2.2007Gunter Saake8 AUTOMOTIVE OPEN SYSTEM ARCHITECTURE : Autosar

9 15.2.2007Gunter Saake9 Datenhaltungsvarianten im Automobil: Beispiele TabellecursorxxxxFahrtenbuch fetch SQL Queries intxUmdrehungs- zähler (min/ max-Wert) TupelxxxxKilometerzähler DBxxNavigations- system GranularitätKonsistenzRecoveryPersistenz

10 15.2.2007Gunter Saake10 Beispiel: Führerstand eines Radladers (Ausschnitt)...

11 15.2.2007Gunter Saake11 Motivation: Sensor- Datenbanken Biotop-Überwachung [CACM,2005] 1000 drahtlose Sensoren : Temperatur, Luftdruck, Vibrationen, Lichtintensität, Feuchtigkeit, Chemische Zusammensetzungen Mikrosensoren: Stark ressourcenbeschränkte eingebettete Systeme Datenkollektoren Zusammenführung von Sensordaten Vorbereitung der Datenauswertung Problem: ressourcenknappe Umgebung Kein kontinuierliches Senden von Messwerten möglich Voraggregation verhindert Ad-hoc-Anfragen Lösung: Maßgeschneiderte Sensor-Datenverwaltung

12 15.2.2007Gunter Saake12 Von Macro über Mini und Micro zu Nano-DBMS

13 15.2.2007Gunter Saake13 Warum spezielle Datenhaltungsfamilie? Auch kleinste und kleine Systeme benötigen garantierte Eigenschaften für die Datenhaltung Persistenz Recovery Konsistenz Mehrbenutzerkontrolle Verschlüsselung etc. Jeweils neu programmieren ist sowohl unwirtschaftlich als auch gefährlich !

14 15.2.2007Gunter Saake14 Invarianz-Gesetz: Monotones Wachstum der Datenhaltung 19602020 1980 2000 19901970 2010 1 KB 1 MB 1 GB 1 TB 1 PB 1-Tupel 1-Relation SQL-3 SQL-1 Business Applications Personal Data (PC) Mobile Data Embedded Data Ubiquitous Smart Dust

15 15.2.2007Gunter Saake15 Datenbank-Archäologie Datenbankforschung vor gut 20 Jahren DFG SPP Objektbanken für Experten DBMS-Funktionalität für OO Themen auf Konferenzen Baukasten-Architektur Erweiterbarkeit Kernsysteme Effekt auf heutige reale Systeme? Erweiterbarkeit: ja Schlanke Systeme für Spezialaufgaben: nein

16 15.2.2007Gunter Saake16 Heute: SQL-Moloche statt angepasster kleiner Systeme Erklärungsversuch: Warum scheiterten alle diese bisherigen Versuche? Komplexität des Variantenraums SQL3 als Moloch Schwer lokalisierbare Funktionalitäten Transaktionseigenschaften

17 15.2.2007Gunter Saake17 Zerlegung des Molochs SQL3-DBMS bieten die Obermenge aller sinnvollen (d.h., verkaufbaren) Funktionalität Kleine Datenhaltungskomponenten können nur einen Teil dieser Funktionalität haben Zerlegung in Features notwendig Baukasten für Funktionalität Bekannt aus Betriebssystemforschung Maßschneiderung von Software DBMS-Familien Analog zu Variantenfertigung im Ingenieurwesen

18 15.2.2007Gunter Saake18 … warum jetzt ein neuer Versuch? Erfahrung aus dem Betriebssystembereich Vor 25 Jahren: ähnliche Situation wie im DBMS-Bereich Neue Programmiertechniken (AOP, FOP) Zum Teil im Betriebssystem-Bereich entwickelt Dort erfolgreich eingesetzt Warum nicht auch für andere Infrastruktur- Software einsetzbar?

19 15.2.2007Gunter Saake19 Methodisches Vorgehen Identifizierte Haupthindernisse 1.) Komplexität des Variantenraums Feature-oriented Design & Implementierung 2.) Crosscutting concerns Transaktionsverwaltung, Logging,… Aspektorientierte Programmierung 3.) Effiziente Implementierung C und C++ als Sprachen für Embedded Software

20 15.2.2007Gunter Saake20 Variantenraum Bestimmung der Merkmale die den Variantenraum aufspannen Feature-Diagramme Hierarchische Modellierung des Feature- Raumes Optionale und obligatorische Features Alternative Features Feature-Constraints für Abhängigkeiten zwischen Features

21 15.2.2007Gunter Saake21 Feature-Diagramme

22 15.2.2007Gunter Saake22 Merkmalsorientierte Programmierung Schichtenbasierte Realisierung Features entsprechen Schichten (Layers) Constraints legen die erlaubten Schichten- Stapel fest Programmierung in den Schichten OOP (in Java oder C++) Verfeinerung von Klassen Neue Klassen

23 15.2.2007Gunter Saake23 Feature-oriented Design Features Klassen Dekomposition des OOP Designs entsprechend Features

24 15.2.2007Gunter Saake24 Aspektorientierte Programmierung Aspekte Weben von Aspekten Dekomposition des OOP Designs in Klassen und Aspekte

25 15.2.2007Gunter Saake25 Synthese Für maßgeschneiderte Datenhaltung benötigen wir beides! Variantenreichtum durch FOP Crosscutting concerns durch AOP … und dies für eine Programmier- sprache, die für Embedded Software geeignet ist! C++

26 15.2.2007Gunter Saake26 Die Synthese: FeatureC++ Zerlegung von Aspekten und Klassen entsprechend relevanter Features Integration der Aspekte in FOP-Design

27 15.2.2007Gunter Saake27 Prototypische Umsetzung einer Speichermanagerfamilie Merkmalsorientierte Softwareentwicklung (FOSD) [Batory et al., 2002] Domänenanalyse (Feature Oriented Domain Analysis) Domänenentwurf (Collaboration based Design) Domänenimplementierung (FOP)

28 15.2.2007Gunter Saake28 Feature-Diagramm

29 15.2.2007Gunter Saake29 Domänenentwurf

30 15.2.2007Gunter Saake30 Prototyp einer Datenhaltungsfamilie Beispiel: Sensor-Netzwerk 93 Merkmale, 60 davon implementiert 8.164.800 mögliche Konfigurationen Variantenreichtum Ziel erreicht Konfigurationen für Sensor Zusammengesetzt aus 11 - 17 Merkmalen Ca. 60% - 70% der Funktionalität ist in allen Konfigurationen gleich Konfigurationen für Datenkollektoren Zusammengesetzt aus 30 - 45 Merkmalen Ca. 35% - 50% der Funktionalität jeweils gleich

31 15.2.2007Gunter Saake31 Ausblick Zerlegung von SQL (SQL3) Familie von DB-Sprachen und zugehörigen DBMS Entwicklung einer Datenhaltungsfamilie für Embedded Systems für Automotive-Anwendungen inklusive Design-Methoden Korrektheitseigenschaften Modellierung, Visualisierung, Strukturierung, Wiederverwendung großer Feature-Räume Kombination mit adaptiver Datenhaltung

32 15.2.2007Gunter Saake32 Danksagung Dank gilt der FAME Gruppe! Sven Apel (demnächst Filialleiter Passau) Thomas Leich (Industrie-Vertreter) Christian Kästner (Außenstelle Texas) Martin Kuhlemann (Schulung) Mario Pukall (Transaktionen) Marko Rosenmüller (F & E)