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

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


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“


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!


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


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


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


Computer im Automobil


AUTOMOTIVE OPEN SYSTEM ARCHITECTURE: Autosar


Datenhaltungsvarianten im Automobil: Beispiele

TabellecursorxxxxFahrtenbuch

fetch

SQL

Queries

intxUmdrehungs-zähler (min/ max-Wert)

TupelxxxxKilometerzähler

DBxxNavigations-system

Granularität

Konsistenz

Recovery

Persistenz


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


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


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


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 !


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


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


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


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


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


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


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


Feature-Diagramme


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


Feature-oriented Design

Features

Klassen

Dekomposition des OOP Designs entsprechend Features


Aspektorientierte Programmierung

Aspekte

Weben von Aspekten

Dekomposition des OOP Designs in Klassen und Aspekte


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


Die Synthese: FeatureC++ Zerlegung von Aspekten und Klassen

entsprechend relevanter Features Integration der Aspekte in FOP-Design


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)


Feature-Diagramm


Domänenentwurf


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


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


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)

Documents

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