15.2.2007 Gunter Saake 1
Maßgeschneiderte Datenbanksysteme – nach 20 Jahren immer noch ein Traum?
Gunter SaakeFestkolloquium für Prof. Dr. H.-D.
EhrichBraunschweig, 15.2.2007
15.2.2007 Gunter Saake 2
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“
15.2.2007 Gunter Saake 3
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!
15.2.2007 Gunter Saake 4
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
15.2.2007 Gunter Saake 5
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!) …
15.2.2007 Gunter Saake 6
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
15.2.2007 Gunter Saake 7
Computer im Automobil
15.2.2007 Gunter Saake 8
AUTOMOTIVE OPEN SYSTEM ARCHITECTURE: Autosar
15.2.2007 Gunter Saake 9
Datenhaltungsvarianten im Automobil: Beispiele
TabellecursorxxxxFahrtenbuch
fetch
SQL
Queries
intxUmdrehungs-zähler (min/ max-Wert)
TupelxxxxKilometerzähler
DBxxNavigations-system
Granularität
Konsistenz
Recovery
Persistenz
15.2.2007 Gunter Saake 10
Beispiel: Führerstand eines Radladers (Ausschnitt)...
15.2.2007 Gunter Saake 11
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
15.2.2007 Gunter Saake 12
Von Macro über Mini und Micro zu Nano-DBMS
PrevaylerAPIeinfache persistente Speicherstrukturen
(Array, Hash Map,..)Nano
Berkeley DB, RDM- Embedded,
COMET DBMS
1-Relationen Zugriff meist über
eine APIpersistente Tabellen Micro
MySQL, Oracle Lite
SQL 1 (Ad-hocAnfragen möglich)
Relationales Datenmodell
Mini
Oracle, IBM, MS SQL-Server
SQL 3
Objektrelationales -. Multidimensionales -,
und Relationales Datenmodell
Macro
Typische Systeme
EinsatzgebietAnfragenDatenmodelle/
Speicherformen
PrevaylerAPIeinfache persistente Speicherstrukturen
(Array, Hash Map,..)Nano
Berkeley DB, RDM- Embedded,
COMET DBMS
1-Relationen Zugriff meist über
eine APIpersistente Tabellen Micro
MySQL, Oracle Lite
SQL 1 (Ad-hocAnfragen möglich)
Relationales Datenmodell
Mini
Oracle, IBM, MS SQL-Server
SQL 3
Objektrelationales -. Multidimensionales -,
und Relationales Datenmodell
Macro
Typische Systeme
EinsatzgebietAnfragenDatenmodelle/
Speicherformen
(tie
f) e
ing
eb
ett
ete
Sys
tem
e,
Sm
art
card
s
PD
A, S
ma
rtp
hon
es
Desk
top
, L
apto
p
Serv
ers
yste
me
15.2.2007 Gunter Saake 13
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 !
15.2.2007 Gunter Saake 14
Invarianz-Gesetz: Monotones Wachstum der Datenhaltung
1960 20201980 200019901970 2010
1 KB
1 MB
1 GB
1 TB
1 PB
1-Tupel
1-Relation
SQL-3
SQL-1
Business A
pplications
Personal D
ata (PC)
Mobile Data
Embedded Data
Ubiquitous
Smart Dust
15.2.2007 Gunter Saake 15
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
15.2.2007 Gunter Saake 16
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
15.2.2007 Gunter Saake 17
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
15.2.2007 Gunter Saake 18
… 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?
15.2.2007 Gunter Saake 19
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
15.2.2007 Gunter Saake 20
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
15.2.2007 Gunter Saake 21
Feature-Diagramme
15.2.2007 Gunter Saake 22
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
15.2.2007 Gunter Saake 23
Feature-oriented Design
Features
Klassen
Dekomposition des OOP Designs entsprechend Features
15.2.2007 Gunter Saake 24
Aspektorientierte Programmierung
Aspekte
Weben von Aspekten
Dekomposition des OOP Designs in Klassen und Aspekte
15.2.2007 Gunter Saake 25
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++
15.2.2007 Gunter Saake 26
Die Synthese: FeatureC++ Zerlegung von Aspekten und Klassen
entsprechend relevanter Features Integration der Aspekte in FOP-Design
15.2.2007 Gunter Saake 27
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)
15.2.2007 Gunter Saake 28
Feature-Diagramm
15.2.2007 Gunter Saake 29
Domänenentwurf
15.2.2007 Gunter Saake 30
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
15.2.2007 Gunter Saake 31
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
15.2.2007 Gunter Saake 32
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)