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

Gunter 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

Gunter 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!

Gunter 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

Gunter 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!) …

Gunter 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

Gunter Saake7 Computer im Automobil

Gunter Saake8 AUTOMOTIVE OPEN SYSTEM ARCHITECTURE : Autosar

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

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

Gunter 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

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

Gunter 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 !

Gunter Saake14 Invarianz-Gesetz: Monotones Wachstum der Datenhaltung 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

Gunter 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

Gunter 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

Gunter 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

Gunter 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?

Gunter 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

Gunter 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

Gunter Saake21 Feature-Diagramme

Gunter 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

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

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

Gunter 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++

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

Gunter 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)

Gunter Saake28 Feature-Diagramm

Gunter Saake29 Domänenentwurf

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

Gunter 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

Gunter 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)