Teil 2 Maßgeschneidertes Datenmanagement

Transkript

1 Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 2 Maßgeschneidertes Datenmanagement Gunter Saake (Universität Magdeburg) Christian Kästner (Universität Magdeburg)

2 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-2 Software heute I Moderne Anwendungssoftwaresysteme sind Eierlegende Wollmilchsäue Bsp: Windows Vista, Open Office, Oracle, SAP myerp, itunes Voll von Funktionalität, viele wird der normale Anwender nie benutzen Steigende Größe und Hardwareanforderungen Zielen auf breiten Massenmarkt ab rel. homogene Hardwarevorraussetzungen

3 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-3 Software heute II Software für eingebettete Systeme wird immer wichtiger 98% aller im Einsatz befindlichen Rechnersysteme sind eingebettete Systeme z.b. PDA, Handy, Sensoren, Toaster, Mikrowelle, Fernseher, Wetterstation, Taschenrechner, Chipkarten, Bordcomputer, Router, Ubiquitious Computing Ressourcenbeschränkung und heterogene Hardware erfordert maßgeschneiderte Lösungen Häufige Neuimplementierungen, lange Entwicklungszeiten, hohe Entwicklungskosten

4 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-4 Embedded Databases: Unterschiede Nicht immer alle Funktionalität benötigt Verschiedene Implementierungen der gleichen Funktionalität, z.b. Optimiert für geringen Stromverbrauch Optimiert für Performance Optimiert für minimalen Footprint Spezielle Implementierung für Systembesonderheiten, z.b. kein RAM Unterschiedliche Architekturen

5 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-5 Was ist maßgeschneiderte Software? Enthält genau die benötigte Funktionalität Verschiedene Varianten für verschiedene Anwendungsfälle Neue Varianten können leicht hinzugefügt werden, schnelle Entwicklung, Wiederverwendung bewährter Funktionalität Kunden-individuelle Fertigung, Spezialisierung Anpassung an verfügbare Ressourcen

6 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-6 Warum maßgeschneiderte Software? Ressourcenbeschrä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, unterschiedliche Audis möglich, unterschiedliche BMWs

7 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-7 Maßgeschneiderte Datenhaltung Kommerzielle DBMS Oracle, IBM DB2, SQL Server, 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!

8 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-8 Embedded Databases Eingebettete Systeme sind weit verbreitet und sollen sehr häufig Daten erfassen z.b. Sensoren im Auto, Biotopüberwachung, Gesundheitskarte, Wetterstation, RFID, Erdbebenvorhersage, Telefonanlage, Router, Handy Ständig wachsendes Datenaufkommen, immer mehr Daten sollen erfasst werden Eingebettete Systeme unterliegen starken Ressourcenbeschränkungn Senkung von Kosten, Energieverbrauch und Wärme Oracle im Auto?

9 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-9 Datenmanagement im Auto Persistenz Recovery Konsistenz Queries Granularität Navigationssystem x x SQL DB Fahrtenbuch x xx x cursor Tabelle Kilometerzähler x x xx fetch Tupel Umdrehungszähler (min/ max-wert) x int

10 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-10 Informatik im Auto 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

11 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-11 Smartcards Chipkarten mit geringer Rechenleistung und geringem Speicher, z. B. Bankkarte, Mensakarte, SIM-Karte, Gesundheitskarte Sehr wenig Speicher (24-48KB) Externe, unsichere Stromversorgung Schnelles Lesen aber sehr langsames Schreiben Beschränkte Rechenleistung Oft hohe Sicherheitsanforderungen IBM DB2 auf Bankkarte?

12 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-12 Datenmanagement auf Smartcards Transaktionen (ACID) Benutzerverwaltung, Datensicherheit und Datenschutz Recovery SQL Anfragen?

13 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-13 Sensornetzwerke Autarke Sensoren, ohne Zentralcomputer Kommunikation mittels (drahtlosen) Netzwerk Kleine Komponenten mit Sensor und eingebettetem System Ermöglicht die einfache Installation, Verteilung der Sensoren

14 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-14 Einsatzbeispiel Sensornetzwerke Biotopüberwachung auf Great Duck Island zur Beobachtung des Brutverhalten von Seevögeln, 2002, UC Berkeley & Intel 50 batteriebetriebene Sensoren

15 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-15 Einsatzbeispiel Sensornetzwerke II Sensornetzwerk in Erdbebentestzentrum Mobile, autarke, leicht anzubringende Sensoren statt zentraler Verkabelung Alte Zentralverkabelung

16 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-16 Ad-hoc Anfragen Datenmanagement bei Sensornetzwerken Aggregation, Anfragen über Raum und Zeit

17 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-17 Besonderheiten Sensornetzwerke Ressourcenbegrenzung durch Batteriebetrieb Schwache Rechenleistung Kein kontinuierliches Senden von Messwerten Unsichere Übertragung, veränderliches Netzwerk Wenig Speicher ( kB) Verteiltes System, verteilte Transaktionen Komplexe Anfragen Werteaggregation über mehrere Sensoren Anfragen über Raum und Zeit ( Wo war der Höchstwert der letzten Stunde )

18 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-18 Eingebettete Datenbanken in der Zukunft Ubiquitous Computing Bsp.: vernetzte Computer in Kleidung, Kühlschrank, Intelligent Home, Kaffeetasse Smart Dust

19 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-19 Invarianz-Gesetz: Monotones Wachstum der Datenhaltung 1 PB 1 TB 1 GB 1 MB 1 KB Business Applications Personal Data (PC) Mobile Data EmbeddedData Ubiquitous Smart Dust SQL-3 SQL-1 1-Relation 1-Tupel

20 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-20 Eingebettete Datenbanken Immer: Speicherung geringer Datenmengen bei eingeschränkten Ressourcen Business-Applikationen in 70ern Desktop-Anwendungen in 80ern Handys bis vor kurzem Sensornetzwerke, Ubiquitous Computing, Smart Dust in der Zukunft Immer: maßgeschneidertes Datenmanagement für Systeme mit vielen Daten unter Ressourcenbeschränkungen nötig

21 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-21 Von Macro über Mini und Micro zu Nano-DBMS Datenmodelle/ Speicherformen Anfragen Einsatzgebiet Typische Systeme Macro Mini Micro Nano Objektrelationales -. Multidimensionales -, und Relationales Datenmodell Relationales Datenmodell persistente Tabellen einfache persistente Speicherstrukturen (Array, Hash Map,..) SQL 3 SQL 1 (Ad-hoc Anfragen möglich) 1-Relationen Zugriff meist über eine API API Serversysteme Desktop, Laptop PDA, Smartphones (tief) eingebettete Systeme, Smartcards Oracle, IBM, MS SQL-Server MySQL, Oracle Lite Berkeley DB, RDM- Embedded, COMET DBMS Prevayler

22 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-22 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

23 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-23 Heute: SQL-Moloche statt angepasster kleiner Systeme Erklärungsversuch: Warum scheiterten alle diese bisherigen Versuche? Komplexität des Variantenraums, z.b. SQL3 als Moloch Schwer lokalisierbare Funktionalitäten, z.b. Transaktionseigenschaften

24 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-24 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, Produktlinien Analog zu Variantenfertigung im Ingenieurwesen

25 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-25 warum jetzt ein neuer Versuch? Erfahrung aus dem Betriebssystembereich Vor 25 Jahren: ähnliche Situation wie im DBMS- Bereich Neue Programmiertechniken (FOP, AOP) Zum Teil im Betriebssystem-Bereich entwickelt Dort erfolgreich eingesetzt Warum nicht auch für andere Infrastruktur- Software einsetzbar?

26 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-26 Gemeinsame Funktionalität von eingebetteten DBMS Was wird immer wieder gebraucht Speichermanagement (z.b. Einpassen auf Seiten) Katalog Anfrageverarbeitung (SQL parsen, Pläne erstellen und optimieren) Transaktionsverwaltung Zugriffsrechte Recovery Verschlüsselung DDL/DML/SQL Dialekte Nicht alle Systeme benötigen alle Features

27 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-27 Optimierung Unterschiedliche Varianten der gleichen Funktionalität, z. B. Optimiert für geringen Stromverbrauch Optimiert für Performance Optimiert für minimalen Footprint Spezielle Implementierung für Systembesonderheiten, z. B. kein RAM, keine/kaum Schreibzugriffe Unterschiedliche Architekturen, z. B. verteilt vs. stand-alone

28 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-28 Produktlinien Jeweils neu programmieren ist sowohl unwirtschaftlich als auch gefährlich Daher maßgeschneidertes Datenmanagement mit Produktlinien Aus wiederverwendbaren Teilen Die alternative Implementierungen haben können Anpassbar für spezielle Anwendungsfälle Nutzbar auch unter extremer Ressourcenbeschränkung

29 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-29 Zusammenfassung Maßgeschneiderte Datenhaltung nötig Große Datenmenge unter beschränkten Ressourcen Gemeinsame Funktionalität aber auch viele Unterschiede Produktlinien als Ausweg?

30 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-30 Ausblick Modellierung von Produktlinien mit Features Einfache Implementierungsstrategien Moderne Programmierparadigmen

31 Apel, Kästner, Saake Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Folie 2-31 Literatur Marko Rosenmüller, Thomas Leich, Sven Apel und Gunter Saake. Von Mini- über Micro- bis zu Nano-DBMS: Datenhaltung in eingebetteten Systemen. Datenbank Spektrum, 7(20), Feb.2007.