Datenbanktechnologie im Umbruch: - Alumni Informatik Universität

Datenbanktechnologie im Umbruch:
neue Anforderungen — neue Funktionalität
— neue Architekturen
Klaus R. Dittrich
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
IFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIIFIFIIFIIFI
Institut für Informatik
der Universität Zürich
Forschungsbereich
Datenbanktechnologie
Winterthurerstrasse 190, CH-8057 Zürich
e-mail: [email protected], http://www.ifi.unizh.ch
Tel.: ++41-1-257 4312, Fax: ++41-1-363 0035
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
1
Datenbanktechnologie im Umbruch
neue
Anforderungen
neue
Funktionalität
neue
Architekturen
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
2
Inhalt
■
Datenbanken und Objekte
— objektorientierte und objektrelationale Datenbanksysteme
■
aktive Datenbanken
■
Informationsgewinnung aus Datenbanken
— OLAP, data mining, data warehouse
■
verteilte, föderierte, interoperable Datenbanksysteme
■
Datenbanken und das Internet/Intranet/Extranet
■
DBMS-Architektur der Zukunft: Monolith oder was sonst ?
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
3
Datenbank
eine Menge
zusammengehörender Daten mit folgenden Eigenschaften:
■
dauerhaft verfügbar (d.h. explizit steuerbare Lebensdauer)
■
potentiell gross
■
integriert
(über mehrere Anwendungen mit überlappendem Informationsbedarf; redundanzarm)
■
verwendbar unabhängig vom Erzeugungsprogramm
(Datenunabhängigkeit: wechselseitige Änderungsimmunität AWP – DB)
■
mehrfachbenutzbar (“parallel zugreifbar”)
■
konsistent, integer, sicher (“Datenqualität”)
■
bequem, flexibel und effizient handhabbar (“assoziativer Zugriff”)
■
(evtl.) verteilt im Rechnernetz (––> “Transparenz”)
Datenbanktechnologie
Gesamtheit der Konzepte, Methoden, Systeme und Werkzeuge
für die Organisation und den Betrieb von Datenbanken
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
4
Datenbankverwaltungssystem
(database management system; DBMS)
Software zur Verwaltung von Datenbanken mit den genannten Eigenschaften
realisiert u.a.:
■ ein Datenmodell: konzeptueller Rahmen zur logischen Datenorganisation
Mittel zur Strukturierung/Beschreibung der Daten
(“Datendefinition”/DDL ––> Schema, Sichten)
■ Mittel für Datenzugriff und Datenmanipulation: DB-Operatoren (DML)
Anfragesprache
■ Steuerung und Überwachung: Transaktionsmodell (inkl. Wiederanlauf, Synchronisation)
Konsistenzsicherung
Trigger
Zugriffsschutz
Datensicherung und Archivierung
Hintergrundspeicherverwaltung (Zugriffspfade etc.)
Verteilung im Rechnernetz (z. B. Client/Server-Architektur)
...
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
5
die heutige Situation
■
relationale DBMS “Stand der Kunst”:
reife Technologie mit 25 Jahren Erfahrung, bestens eingeführt,
zahlreiche Produkte und zahllose DB im erfolgreichen Einsatz
(... und trotzdem werden auch noch ältere Systemarten verwendet)
aber:
■
Grenzen relationaler DBMS bei “nonstandard”-Anforderungen
■
Verlangen nach umfassenderer Nutzung umfangreicher (vorhandener) Datenbestände
■
neue DB-Anforderungen durch neue Systemumgebungen
(Verteilung, Zusammenführung vormaliger Einzelsysteme, Internet, ...)
■
neue technologische Möglichkeiten (Multimedia, ...)
■
neue Konzepte verfügbar (Objektorientierung, ...)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
6
■
Datenbanken und Objekte
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
7
Konzepte objektorientierter Systeme
betrachte und modelliere die reale Welt als eine Kollektion von (kooperierenden, untereinander in Beziehung stehenden) wohlunterscheidbaren Einheiten: OBJEKTE
■ Abstraktion und Autonomie:
––>
Objekt:
<Wert, {Operatoren}>
Wert:
Datenstruktur
Einkapselung (Geheimnisprinzip)
Anforderung von Leistungen anderer Objekte
■ Klassifikation:
––>
gemeinsame Beschreibung (Intension)/
Zusammenfassung gleichartiger
Objekte (Extension; "Klasse")
■ Taxonomie:
––>
Ober-/Unterklassen
Vererbung von Eigenschaften
Polymorphismus
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
8
objektorientierte Modellierung
akzeptierbare Botschaft
(Operatorschnittstelle)
Zustand (Wert)
Methode
(Operatorrumpf)
"Objekt"
■ anwendungsgerechte Einheiten
■ anwendungsgerechte
("höherwertige") Operatoren
■ Aufgabenteilung (Kooperation)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
9
Klassen (“Typen”)
Klasse
(a)
Muster für gleichartige Objekte
(Beschreibung der gemeinsamen
Eigenschaften)
(b)
Menge der (jeweils) vorhandenen
gleichartigen Objekte
Objekte
der Klasse
Extension der Klasse
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
10
Taxonomie / Klassenhierarchie / Vererbung
Fahrzeuge
Velos
Tourenräder
Automobile
Personenwagen
Rennräder
Lastwagen
Mountain Bikes
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
11
Vorteile objektorientierter Modellierung
■ "Natürlichkeit" (zumindest vergleichsweise)
— sinnvolle Abstraktion/hohe Modularität
— Beherrschung von Komplexität
— Trennung Schnittstelle/Implementation
■ evolutionäre Systemkonstruktion
("inkrementelles Programmieren"; "Wiederverwendbarkeit")
dies sind zunächst potentielle Vorteile:
— sie fallen nicht "automatisch" an
— sie setzen das Verstehen und die sachgerechte Anwendung der Technik voraus
— sie erfordern teilweise unterstützende Techniken (z.B. für Auffinden von Klassen)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
12
objektorientiertes Datenbanksystem
::= Datenbanksystem mit objektorientiertem Datenmodell, d. h.
■
Datenbank
■
Objektidentität
■
Einkapselung
■
komplexe Werte, Objektstrukturen, komplexe Objekte
■
Klassenhierarchien (Vererbung)
mit Überladen/Überschreiben/später Bindung
::=
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
Menge von Objekten, die von Klassen
(im Schema definiert) abstammen
13
Objektstruktur
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
14
zusammengesetzte Objekte
(komplexe, strukturierte, molekulare, ... Objekte)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
15
zusätzliche Eigenschaften OODM/OODBMS
■
explizite Beziehungen
■
BLOBs (binary large objects)
■
Objektversionen
■
Schemaevolution
■
Trigger-Mechanismen
■
erweiterte Transaktionskonzepte
■
enge Integration mit (OO-) Progammiersprachen im Rahmen
gemeinsamer Benennungs- und Persistenzmodelle
■
...
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
16
allgemeine funktionale Architektur von OODBMS
ODL
OQL
PL
(C++)
PL
(Smalltalk)
PL
(Java)
•••
Datenbank”maschine”
Datenbank
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
17
Arbeitsweisen mit OODBMS
■
voll integriertes Arbeiten mit einer ooPL (C++, Smalltalk, Java ...) als
“Datenbankprogrammiersprache”: Datenmanipulation und Datendefinition (!!!);
navigierende Verwendung der DB
■
(ad hoc) Anfragebearbeitung mit OQL
(deskriptiv, optimierbar, z. Zt. ausschliesslich für Anfragen vorgesehen)
■
Einbettung von OQL in die integrierte ooPL
(ermöglicht dort die Ausnutzung der Vorteile einer Anfragesprache)
■
Einbettung von OQL in konventionelle PL (analog “embedded SQL”)
■
separate Datendefinition mit ODL
(nur damit ist Datenintegration, Datenadministration etc. vernünftig möglich !!)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
18
einfaches Anwendungsbeispiel
Angestellter
A#
Name
Tel
Gehalt
Bild
Abteilung
AName
U_Ziel
ltd_Angestellter
Titel
Bonus
Tel:
Menge von Paaren wie
(Büro, 257 4312),
(Mobil, 696 7354),
(Fax, 363 0035)
Bild: gerastertes Foto
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
19
Beispiel ODMG ‘93: ODL
interface ANGESTELLTER
(
extent ANGESTELLTE;
key A# ): persistent
{
typedef Struct Telnum {String A_Art, Unsigned Long Nummer};
attribute Unsigned Short A#;
attribute String Name;
attribute Set <Telnum> Tel;
attribute Unsigned Long Gehalt;
relationship ABTEILUNG arbeitet_in inverse ABTEILUNG :: hat_Mitarbeiter;
void Bild ();
...
}
interface LTD_ ANGESTELLTER: ANGESTELLTER
(
extent LTD_ ANGESTELLTE)
{
attribute String Titel;
attribute Unsigned Long Bonus;
relationship ABTEILUNG leitet inverse ABTEILUNG :: geleitet_von;
...
}
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
20
Beispiel ODMG ‘93: ODL
interface ABTEILUNG
(
extent ABTEILUNGEN;
key AName ): persistent
{
attribute String AName;
attribute Unsigned Long U_Ziel;
relationship set <ANGESTELLTER> hat_Mitarbeiter
inverse ANGESTELLTER :: arbeitet_in;
relationship LTD_ANGESTELLTER geleitet_von
inverse LTD_ANGESTELLTER :: leitet;
...
}
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
21
Beispiel ODMG ‘93: OQL
select ANG.Name
from ANGESTELLTE ANG
where ANG.Gehalt >= 30000
select struct (N: ANG.Name, T: ANG.Tel)
from ANGESTELLTE ANG
where ANG.Gehalt < 150 000
select struct (N: L_ANG.Name, G: L_ANG.Gehalt)
from LTD_ANGESTELLTE L_ANG
select struct (N: L_ANG.Name, A: ABT.AName)
from ABTEILUNGEN ABT, ABT.geleitet_von L_ANG
where ABT.U_Ziel ≥ 3 000 000
select ANG.Bild
from ANGESTELLTE ANG
where ANG.Gehalt >= 30000
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
22
objektrelationale DBMS
Erweiterung des relationalen Datenmodells um OO-Konzepte
bzw. Kombination beider Ansätze
also:
Beibehalt der bisherigen (bewährten!) Konzepte von RDBMS
——> Datenbank ist weiterhin eine Menge von Relationen !
heutiger Stand:
■
viele Schlagworte ( “ORDBMS”, “postrelationale DBMS”, “Universal Server”,
“Data Blades”, “Data Cartridges”, “Extenders”, ...)
■
viel Werberummel (mit entsprechendem Nebelwerfen ...)
■
allgemein anerkannte Definition ???
(konsolidiertes Konzept ? — Standard (SQL 3) ? — spezielles Produkt ?)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
23
objektrelationale DBMS: spezielle Konzepte
■
Anfrage-Code als DB-Inhalt (“stored procedures”)
■
lange Felder
■
Tupelidentifikatoren
■
Tupeltypen separat von Relationsdefinitionen
■
komplexe Strukturen (geschachtelte Relationen und mehr)
■
benutzerdefinierbare (“abstrakte”) Datentypen
(mit Kapselung, teilweise mit definierbaren Zugriffspfaden etc.)
■
Vererbung (mehrere Formen)
“Neubau” solcher Systeme vs. Erweiterung existierender DBMS ???
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
24
ORDBMS: ADTs
■
benutzerdefinierbare Datentypen
■
können wie Standarddatentypen für die Definition von Attributen verwendet werden
■
Einkapselung, Vererbung, ...
create type Foto
( <Festlegung der internen Repräsentation>
<Definition der erforderlichen Vergleichsoperationen>
<Definition der Konstruktorfunktion>
<Definition der eigentlichen Typoperationen>
z.B. actor procedure zeige_Foto (<Parameter>);
begin
<Operatorrumpf>
end
)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
25
ORDBMS: komplexe Objekte, Objektidentifikatoren, Vererbung, ...
■
Trennung von Tupeltypdefinition und Relationsdefinition
■
Kollektionstypen (Mengen, Listen, ...)
———> dadurch Substrukturen in Relationen möglich (z.B. Schachtelung)
■
OID-Vergabe kann verlangt werden (je Tupel)
■
Referenztyp (Verweise auf Tupel als Attributwerte)
———> dadurch komplexe Objekte/Objektstrukturen
zusammen: gewisse Arten von Objekten “in zwei Dimensionen”
(ADTs in Spalten, erweiterte Tupel – evtl. zusammen
mit “stored prodecures” – in Zeilen)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
26
Beispiel ORDBMS
create row type TELNUM_TYP (
A_Art
Character (15),
Nummer
Integer);
create row type ANG_TYP (
ANG_ID
ref (ANG_TYP),
A#
Integer,
Name
Character Varying (30),
Tel
set (TELNUM_TYP),
Gehalt
Integer,
Bild
Foto,
arbeitet_in
ref (ABT_TYP) );
create row type LTD_ANG_TYP under ANG_TYP (
Titel
Character (15),
Bonus
Integer
leitet
ref (ABT_TYP) );
create row type ABT_TYP (
ABT_ID
ref (ABT_TYP),
AName
Character Varying (30),
U_Ziel
Integer,
hat_Mitarbeiter set(ref (ANG_TYP)
geleitet_von
ref (LTD_ANG_TYP));
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
27
Beispiel ORDMBS
create table ANGESTELLTER of ANG_TYP (
primary key A#,
values for ANG_ID are system generated,
scope for arbeitet_in is ABTEILUNG);
create table LTD_ANGESTELLTER under ANGESTELLTER of LTD_ANG_TYP (
scope for leitet is ABTEILUNG);
create table ABTEILUNG of ABT_TYP (
primary key AName,
values for ABT_ID are system generated,
scope for hat_Mitarbeiter is ANGESTELLTER
scope for geleitet_von is LTD_ANGESTELLTER);
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
28
Beispiel ORDBMS
select Name
from ANGESTELLTER
where Gehalt >= 30000
select Name, Tel
from ANGESTELLTER
where Gehalt < 150 000
select Name, Gehalt
from LTD_ANGESTELLTER
select geleitet_von —> Name, AName
from ABTEILUNG
where U_Ziel ≥ 3 000 000
select zeige_Foto (Bild)
from ANGESTELLTER
where Gehalt >= 30000
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
29
DBMS
relationale
Datenbank
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
30
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
31
OO
DBMS
objektorientierte
Datenbank
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
32
DBMS
RDB + “stored
procedures”
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
33
OR
DBMS
ORDB
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
34
OR
DBMS
ORDB
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
35
wofür ist was gut ? – einige Vergleiche
alle besprochenen DBMS-Ansätze resultieren (neben neuen technischen Möglichkeiten
und wissenschaftlicher Neugier) aus
—
—
—
erkannten Schwachstellen klassischer RDBMS
neuen Anforderungen aus DBMS-Anwendungen (“nonstandard”-Anforderungen)
neuen Anforderungen durch neue Umgebungen (OO!)
und bieten daher (in erster Linie)
(a)
erweiterte Möglichkeiten zur Modellierung von Strukturen
(——> Graphen, Taxonomien)
(b)
Möglichkeiten zur Modellierung von Verhalten als Bestandteil der DB
(——> definierbare Funktionalität)
(c)
bessere (“nahtlose”) Integration von DBMS-Funktionalität in das Gesamtsystem:
objektorientierte Informationssysteme (mit “hochwertiger Persistenz”)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
36
Beurteilung
(im Vergleich zu “puren” RDBMS)
objektorientierte/objektrelationale DBMS:
•
für weitergehende DBMS-Anforderungen, vorwiegend aus speziellen Anwendungsgebieten: spezielle Datentypen, komplex strukturierte Daten, spezielle Operationen,
auch "navigierender" Zugriff
•
oft geringere Bedeutung von ad hoc-Zugriffen (aber eben doch auch ... !)
•
es kann sehr viel Semantik in der DB selbst modelliert werden (––> zentrale Stelle!)
•
effiziente Unterstützung für geeignete Anwendungen (nicht generell!)
objektorientierte DBMS auch:
•
(vorzugsweise) enge Bindung an objektorientierte Programmiersprachen
•
Streben nach ganzheitlicher Modellierungsweise,
unabhängig von Lebensdauer der Daten
Reifegrad von OODBMS/ORDBMS ?
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
37
wofür ist was gut ? – einige Vergleiche
■
Relationen sind in einem OODM als Spezialfall darstellbar
■
OQL und SQL sind in diesem Fall für Anfragen (fast) gleichwertig
■
Objekte tauchen in ORDBMS nur als “Elemente zweiter Klasse” auf,
sind gegenüber OODM mit Einschränkungen behaftet
■
Aufwärtskompatibilität von SQL: Segen und Fluch zugleich
■
SQL ist internationaler Standard, SQL 3/4 aber immer noch in Arbeit;
OQL ist zur Zeit der Standard eines Firmenkonsortiums
■
Normenkonformität von ORDBMS voraussichtlich nur eingeschränkt zu erwarten
■
die Anfragesprache OQL wird ihrem Namen (zur Zeit) voll gerecht und umfasst
damit weniger Teilaspekte als SQL
■
OQL ist in OODBMS-Produkten noch nicht flächendeckend vorhanden,
ebenso gibt es noch Defizite bei einigen anderen DBMS-Mechanismen
(diese sind jedoch produkt- und nicht konzeptbedingt !)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
38
wofür ist was gut ? – einige Vergleiche
■
sowohl OODBMS als auch ORDBMS bieten Mittel für weitergehende
Datenmodellierung (Struktur und Verhalten); sie sind in dieser Hinsicht
nahezu gleichwertig
■
die “nahtlose” Integration mit (objektorientierten) Programmiersprachen
ist für OODBMS besser gelöst
■
die Frage der “Altlasten” (d.h. von allem, was bis heute schon existiert):
—
man kann nicht einfach das bisherige RDBMS “XXX” durch das künftige
ORDBMS “XXX” ersetzen und ohne zusätzlichen Aufwand alle Vorteile
der Objektorientierung quasi umsonst erhalten
—
blosse “Objektifizierung” relationaler Daten reicht nicht
— es ist in jedem Fall (egal, ob OODBMS oder ORDBMS eingesetzt
werden soll) ein “Reengineering” erforderlich
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
39
Produkte (unvollständige Übersicht; subjektive Einordnung)
OODBMS
ORDBMS
• Ontos (früher VBase; Ontologic)
• Informix Universal Server
(mit ehemaligem Illustra-ORDBMS)
• Objectivity/DB (Objectivity)
• Versant (Versant Object Technology)
• ObjectStore (Object Design)
• GemStone (GemStone Inc.)
• OpenODB (<––IRIS; Hewlett-Packard)
• Oracle Version 8 (Universal Server)
• DB2 Version 2 for Common Servers,
Universal Database System (IBM)
• UniSQL
• Omniscience ORDBMS
• ORION (MCC ––> ITASCA Systems; Ibex)
• O2 (O2 –Technology; Altair)
• POET (POET Software)
• ODBMS (VC Software Construction)
• Jasmine (CA)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
• manche “OO”DBMS ??
40
Dateisysteme
OODBMS
einfache
Daten
komplexe
Daten
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
Anfragen
ORDBMS
RDBMS
ORDBMS
keine
Anfragen
Anfragen
RDBMS
keine
Anfragen
was wofür: eine Frage des Standpunktes
Dateisysteme
OODBMS
einfache
Daten
komplexe
Daten
41
wohin führt der Weg ?
■
Objektorientierung als Ansatz hat sich durchgesetzt (ist längst kein akademisches
Spielzeug mehr); muss DB-seitig unterstützt werden und bringt Vorteile auch für DB
■
es existieren zahlreiche Anwendungen, für die heutige DBMS wenig geeignet sind,
die aber durchaus nach DBMS-Unterstützung verlangen
——>
——>
■
viele davon sind Zielbereich für OODBMS!
gute Marktprognosen für oo-unterstützende Systeme generell
bereits zahlreiche kommerzielle OODBMS-Produkte, die auch bereits im Einsatz stehen
typische Anwendungscharakteristika:
• komplexe Netzstrukturen
• grosse Anzahl von Informations”varianten”
• operationaler Aspekt ???
■
für viele Anwendungen sind (heutige) relationale DBMS völlig ausreichend
und auf weite Sicht "unschlagbar"; ——> in oo-Systeme integrieren !
■
künftige ORDBMS ab sofort “im Kommen”; haben Startvorteil durch ihre Herkunft;
stellen pragmatische Lösung dar
■
Koexistenz mehrerer Systemarten absehbar (Gateways und mehr; interoperierende
heterogene DBMS)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
42
OODBMS vs. ORDBMS
■
mit ORDBMS ziehen die RDBMS-Hersteller nach und bringen entscheidende
Konzepte und Möglichkeiten der Objektorientierung in ihre Systeme ein
■
für “nahtlose” objektorientierte Informationssysteme sind OODBMS (wohl auf
längere Sicht) die bessere Lösung
■
Systemreife ? Effizienz ? Handhabbarkeit ? Preis ? ...
(dieselben Bedenken, die vor allem RDBMS-Hersteller lange Zeit gegenüber
OODBMS geltend gemacht haben)
■
auch bei ORDBMS fällt die Umstellung von RDBMS nicht gratis ab
■
im Hinblick auf Altlasten: die Notwendigkeit zur Integration heterogener Systeme
entfällt nicht
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
43
■
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
aktive Datenbanken
44
konventionelle Datenbanksysteme: “passiv”
Repräsentation von Umweltsemantik im Rahmen von
Schema
• Datenmodell
Manipulationsoperatoren
Resultat
DBMS
– Strukturen für "Fakten"
– Standardoperatoren zum
Umgang damit
– (einige) Konsistenzregeln
• Transaktionsmodell
– Ausführung anwendungsdefinierter Arbeitseinheiten
(unmittelbar auf Anforderung)
mit Zusicherung bestimmter
Qualitäten ("ACID-Prinzip")
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
45
andere Arten oft benötigter
Semantik der Informationsverarbeitung
•
Überwachung/Durchsetzung von Beschränkungen (“constraints”)
(verschiedene Arten, Überprüfungszeitpunkte, Durchsetzungsverfahren)
•
Überwachung/Meldung bestimmer Situationen, reaktives Verhalten
(bestimmter Zustand der DB oder DB-Bearbeitung soll bestimmte Operation auslösen,
erfordert Benachrichtigung der Anwender, ...)
•
Folgeaktionen
(explizit verlangte DB-Operation soll implizit andere Operation auslösen)
•
...
——> wenig Hilfe von konventionellen DBMS (bestenfalls für ein paar Spezialfälle,
“fest verdrahtet”)
——> andere/zusätzliche Lösungen erforderlich
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
46
"passives" Datenbanksystem
2 Exemplare
DB-Handbuch
verkauft
•
•
wieviele
Exemplare
DB-Handbuch
noch am Lager?
DBS
3
Lagerbestand
DB-Handbuch 5 3
bestelle 100
Exemplare
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
47
konventionelle Lösungen
(1) reguläre Anwendungsprogramme berücksichtigen zusätzliche Semantik
– bestimmte allgemein vorkommende Arten von Semantik sind in Programmcode
verborgen/über zahlreiche Programme verteilt (schwer zugänglich, änderbar etc.)
– Wirksamkeit/Korrektheit von allen betroffenen Anwendungen abhängig
– nicht einmal in allen Fällen möglich
(2) periodische Abfragen der Datenbank (mittels spezieller Anwendungssoftware)
– Semantik an einem Platz konzentriert
(jedoch i.d.R. immer noch "fest verdrahtet")
– gelegentliche Abfragen: mögliches "Verpassen" des geeigneten Reaktionszeitpunktes
– häufige Abfragen: teuer für DBMS-Betrieb
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
48
"aktives" Datenbanksystem
2 Exemplare
DB-Handbuch
verkauft
•
Lagerbestand
•
(
)
bestelle 100
Exemplare
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
DBS
DB-Handbuch 5 3
Regeln
"wenn Lagerbestand < 5
wird, bestelle
100 Exemplare"
49
Grundidee
•
Erkennen von (vorab beschriebenen, beobachtbaren)
Situationen
( . . . in der Datenbank, Anwendung, Umgebung)
•
bei Eintreten auslösen (definierter)
Reaktionen
( . . . DB-Operationen, beliebige Programme)
➮
aktives Datenbanksystem (aDBMS):
. . . kann – zusätzlich zu den bekannten Fähigkeiten –
anwendungsdefinierte Situationen in der Datenbank (und
darüber hinaus) erkennen und bei deren Eintreten selbsttätig anwendungsdefinierte Reaktionen auslösen
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
50
Paradigma für Spezifikation in aDBMS: ECA-Regeln
( E, C) ——> A
ON
Ereignis tritt ein
"Situation"
IF
Bedingung ist erfüllt
DO
führe aus Aktion
"Reaktion"
unterstelltes Systemverhalten: “wenn E eintritt, prüfe C und falls C erfüllt ist, führe A aus”
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
51
wirft etliche Fragen auf:
•
welche Arten von Ereignissen/Bedingungen/Aktionen kann man spezifizieren?
•
was genau heisst “Eintreten eines Ereignisses” ?
•
wie und wann “merkt” das DBMS, dass ein Ereignis eingetreten ist ?
•
wann genau wird eine Bedingung geprüft, eine assoziierte Regel ausgeführt (“gefeuert”) ?
•
wie werden Regeln als Elemente der Datenbank behandelt ?
•
wie stehen typische DBMS-Mechanismen zu Regeln und ihrer Ausführung
(z.B. Synchronisation, Wiederanlauf, Autorisierung, ...) ?
•
...
aktive DBMS-Funktionalität ist prinzipiell orthogonal zur DBMS-Art (Datenmodell)
——>
——>
——>
aktive relationale DBMS
aktive objektorientierte DBMS
...
heute Gegenstand intensiver Forschung und Prototypentwicklung
(grösste Probleme: effiziente Realisierung, sichere Verwendung)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
52
reduzierte Funktionalität: DB-Trigger
(z.B. in SQL 3-Vorschlag)
CREATE TRIGGER <trigger_name>
{BEFORE | AFTER | INSTEAD OF}
{INSERT | DELETE | UPDATE [OF <column_list>]}
ON <table>
[REFERENCING OLD AS <old_values_correlation_name>
NEW AS <new_values_correlation_name> ]
[WHEN <predicate>]
<statement_list> [FOR EACH {ROW | STATEMENT} ]
– Ereignisse (Bedingungen, Aktionen): nur DB-Operationen
– Bezug auf alte und neue Werte möglich
– FOR EACH ROW-Option: Wirkung auf gesamte Tabelle, nicht nur einzelnes Tupel
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
53
■
Informationsgewinnung
aus Datenbanken
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
54
Ausgangslage und Möglichkeiten
•
heute übliche Sichtweise:
– Datenbank ist Menge von Fakten
– Benutzung: Auffinden bestimmter Fakten(mengen), allenfalls einfache Korrelationen,
Bearbeitung der Ergebnisse (verändern, löschen, ...)
•
neuere Erkenntnisse:
– Datenbanken enthalten (meist implizit) wesentlich mehr “Informationen”,
als durch obige Arbeitsweise ausgenutzt wird
(beachte: Daten ≠ Informationen!)
– dies gilt insbesondere bei zunehmend umfangreicheren Datenbanken
(mehr Fakten über Unternehmen etc. in DB vorhanden)
– diese Informationen können insbesondere der Entscheidungsfindung im Unternehmen
dienen (“decision support”) und stellen eine höchst wertvolle Resource dar
•
wesentliche Möglichkeiten:
– Datenanalyse (Gruppierung/Aggregation/... “dimensionaler” Daten): “OLAP”
– Erkennung/Ermittlung typischer Muster in den Daten: “data
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
mining”
55
OLAP
Online Analytical Data Processing
•
•
interaktive, multidimensionale Datenanalyse
im Gegensatz zu OLTP (online transaction processing): herkömmliche DB-Verwendung
•
Hintergrund:
in vielen Datenbanken liegen Werte für bestimmte Messgrössen vor
(z.B. Umsätze, Kosten), die funktional von bestimmten (meist mehreren)
Dimensionen abhängen (z.B. Produktarten, Zeiträumen, Regionen)
•
Ziel:
konsolidierte Betrachtung der Messwerte auf verschiedenen Stufen
Beispiel: Relation Umsatzdaten (Artikel, Filiale, Zahlungsmittel, Umsatz)
•
konzeptuelle Betrachtung dieser Daten in einem multidimensionalen Datenmodell
(Datenwürfel, Hyperwürfel, data cube)
•
Operationen:
–
–
–
–
“drill down” (Detaildaten finden), “roll up” (Details zusammenfassen)
Projektion (——> Würfel niedrigerer Dimension), Selektion
“slice & dice” (Selektion + Projektion)
Drehen (rotate/pivot: Ändern der dimensionalen Orientierung)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
56
multidimensionale Datenbank: Modell “Datenwürfel”
Filiale
Artikel und
Zahlungsmittel
1
Summe
Aggregation
Radio
VideogerŠt
Fernseher
Zahlungsmittel
2
3
4
Bar
EC
Postcard
Artikel
Summe
GROUP BY
Fil. 1
Fil. 2
Bar
EC Post
Filiale
Fil. 3
Fil. 1
Fil. 4
Fil. 2
Zahlungsmittel
und Filiale
Fil. 3
Fil. 4
Filiale
Artikel und
Filiale
Summe
Zahlungsmittel
Summe
Kreuztabelle
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
DatenwŸrfel
(data cube)
57
data mining
•
Erkennung/Ermittlung typischer Muster in den Daten:
– treffen bestimmte (vermutete) Muster zu ?
– welche Muster sind überhaupt vorhanden ?
•
auf Basis bestimmter Gesetzmässigkeiten (Regeln), nach welchen gesucht werden kann
Verfahren:
–
–
–
–
–
–
Regression
Klassifikation
Segmentierung (Cluster-Bildung)
Generalisierung & Aggregation
Sequenzanalyse
Assoziation
Forschungsgebiet, das verschiedene Gebiete wie Statistik, Datenbanksysteme,
Künstliche Intelligenz (Mustererkennung, neuronale Netze, ...), Information Retrieval,
Datenvisualisierung etc. benötigt
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
58
data mining: Beispiel
Assoziationsregeln
gegeben:
– Menge von Entitäten E = {e1, e2, ..., en}
– Menge von Vorgängen V = {v1, v2, ..., vk} mit vi ⊆ E
(Transaktionen, welche Entitäten aus E betreffen)
Assoziationsregel:
X ——> Y
mit Vertrauen (“confidence”) k, Unterstützung (“support”) s
• X ⊆ E, Y ⊆ E, X ∩ Y = Ø
• s: Anteil der Vorgänge in V, welche X ∪ Y enthalten
• k: Anteil der Vorgänge in V, welche Y enthalten,
an denjenigen Vorgängen, welche X enthalten
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
59
data mining: Beispiel
Beispiel Lebensmittelgeschäft: “wer Butter und Brot kauft, nimmt auch Milch mit”
•
•
E = {Butter, Brot, Milch, ...}, V = {<Verkaufstransaktionen>}
Assoziationsregel: {Butter, Brot} ——> {Milch}, k= 80%, s = 5%
d. h.
“5% aller Verkaufstransaktionen beinhalten Butter, Brot und Milch”
“80% aller Verkaufstransaktionen, die Butter und Brot beinhalten, enthalten auch Milch”
Problem des data mining:
finde für eine DB alle (in unserem Fall) Assoziationregeln,
welche vorgegebene Minimalwerte für k und s aufweisen
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
60
Systemunterstützung
OLAP und data mining erfordern erhebliche Unterstützung
durch DB-Technologie:
•
•
•
spezielle (teils sehr aufwendige!) Spezialoperationen (vgl. Datenwürfel)
passende Datenmodelle
Systemarchitektur (OLAP und data mining auf “operationaler” Datenbank ???)
——> Data Warehouse: •
•
•
•
spezielle Datenbank (Datenmodell)
Metadaten
spezielle Funktionalität
evtl. noch spezifische “data marts”
Einzelaspekte:
•
•
•
Data Warehouse als spezielles DB(M)S, in welches operationale Daten eingespielt werden
(auch aus verschiedenen, heterogenen Quellen!): Datenrepliation
(physisches) Datenmodell: ROLAP (relational) vs. MOLAP (multidimensional)
Spezialsystem vs. “normales” DBMS (mit Ergänzungen)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
61
■
verteilte, föderierte, interoperable
Datenbanksysteme
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
62
Ausgangslage und Möglichkeiten
•
dezentrale Aufgaben im Unternehmen
(——> die mit Hilfe der Datenbank zu modellierende Realwelt ist verteilt)
•
Trend zur Dezentralisierung der Hardware, dazu jedoch intensive Vernetzung
•
resultierende Notwendigkeit zur Anpassung vieler Softwaresysteme
(dabei Berücksichtigung moderner Systemstrukturen)
•
Existenz diverser (heterogener!) Datensammlungen/DBMS
im Unternehmen/Unternehmensverbund:
Notwendigkeit der Integration, gemeinsamen Nutzung
Möglichkeiten (je nach Randbedingungen; nicht disjunkt):
–
–
–
–
–
Client/Server-Architektur
(transparent) verteilte DBMS: von vornherein entsprechend gebaut
DBMS-Föderationen (bei weitgehendem Erhalt der Autonomie der Komponenten),
Multi-DBMS, interoperierende DBMS, DBMS-Brückenprogramme (gateways)
Nutzung allgemeiner Interoperabilitäts-Infrastrukturen (CORBA, ...): “Middleware”
dringend benötigt: Standards !
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
63
Client/Server-Konzept als Organisationsprinzip
ein Organisationsprinzip für Software mit folgenden Merkmalen:
—
Aufteilung in funktionale Einheiten, welche Dienste erbringen und/oder anfordern
—
Client: ein Prozess, der von Server-Prozessen spezifische Leistungen anfordert
—
Server: ein Prozess, der für Klienten angeforderte Dienste erbringt
also: die Verkörperung des Prinzips “Arbeitsteilung” in der Software
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
64
Client/Server-Modell
Client
Dienstnehmer
Dienstnachfrager
Kunde
Auftraggeber
❶
Auftrag
❷
Bearbeitung
❸
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
Server
Dienstgeber
Diensterbringer
Lieferant
Auftragnehmer
Antwort
65
Eigenschaften des Client/Server-Konzepts
■
unabhängig von zugrunde liegender HW-Architektur,
ABER: prädestiniert für Rechnernetze
■
synchrone oder asynchrone Kommunikation
■
Mehrstufigkeit möglich
■
mehrere Clients je Server möglich
■
Granularität/Art der Aufteilung: viele Möglichkeiten
■
Art der Diensterbringung für Klienten unerheblich (Schnittstelle entscheidend)
■
weitgehene Unabhängigkeit von Client und Server (Entkoppelung)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
66
mehrstufige Client/Server-Architektur
Auftrag
Auftrag
Antwort
Antwort
Client
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
Client
&
Server
Server
67
Client/Server-Aufteilung (Beispiel)
Client
Präsentation
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
Server
Anwendung
Daten
68
Middleware
Client
Middleware
Server
Benennungsdienste
Verzeichnisdienste
Sicherheitsdienste
Transaktions-Monitore
DB-Gateways
Interprozesskommunikation
Botschaftendienste
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
69
Integration heterogener DBMS
AWP
allgemeine Lösung
“Integrationsschicht”
DBMS 1
DBMS 2
DM 1
DM 2
DM int
Aufgaben und Probleme:
—
—
—
—
Vorteile:
— Nutzung von “Altlasten” zusammen mit modernen Systemen
— graduelle Migration
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
Datenmodellabbildungen
“globale” Transaktionen, Konsistenz etc.
Autonomie der Komponentensysteme
...
auch hierfür:
Nutzung von
oo-Konzepten!
70
CORBA-Architektur der OMG
Application Objects
Common Facilities
Common Object Request Broker Architecture
Name
Events
Life Cycle
Persistence
Relationships
Transactions
Concurrency
Security
Time
Licensing
Properties
Query
Trading
Change Mgmt.
Data Interchange
Common Object Services Specification
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
71
Beispiel für “gemischte” Lösung in Client/Server-Umgebung
zur Nutzung neuartiger DBMS
konventionelle Anwendungen
(z. B. OLTP)
RDBMS
RDB
oo-Anwendungen
(z. B. Entscheidungsunterstützung)
ooDBMS
Datenpropagierung
Notifikation
Replikation
(auszugsweise, evtl. aggregiert)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
ooDB
72
■
Datenbanken und das
Internet/Intranet/Extranet
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
73
Internet, Intranet, Extranet, WWW, ...
■
Internet:
weltweiter Zusammenschluss von Rechnern, die selbst wieder in Teilnetzen organisiert sind (“Netz der Netze”, “Datenautobahn”)
● technische Infrastruktur (samt Übertragungsprotokollen: TCP/IP, ...)
● Datenaustauschprotokolle (HTTP, FTP, ...)
● eindeutige Identifikatoren für alle beteiligten Rechner (“Knoten”)
völlig dezentralisiert, keine eigentliche Verwaltung,
jeder Knoten kann Informationen anbieten,
“kreatives Chaos”
■
WWW:
World Wide Web — die Veredelung des Internet
● Organisation der in den Knoten (WWW-Server) angebotenen
Dokumente in “Seiten” mit beliebigen Querverweisen: Hypertext
● HTML als Standard für die Dokumentbeschreibung
● URLs als weltweit eindeutige Identifikatoren für Dokumente
● Klienten-Software für das Arbeiten mit empfangenen Dokumenten
(WWW-Browser; “Surfbretter”)
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
74
Internet, Intranet, Extranet, WWW, ...
■
stillschweigende Annahme: ● multimediale Information (Text, Bild, Grafik)
■
mehr und mehr auch:
■
Intranet:
genau das gleiche (Infrastruktur, Protokolle, Software, Arbeitsweisen, ...)
aber: beschränkt auf eigenes Unternehmen oder Teile davon
■
Extranet:
Intranet unter Einbezug von Komponenten befreundeter Organisationen
(z. B. ——> virtuelle Unternehmen)
●
●
●
●
weitere Medien (Video, Ton, ...)
von Dokumenten zu “aktiven Elementen” (Applets)
von HTML zu Java
von reinem Lesen von Dokumenten
zu interaktivem Arbeiten
kreatives Chaos ——> angemessene Organisation
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
75
Internet
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
76
Informationsanbieter im Internet
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
77
Hypertext-Dokumente
Kantone der Schweiz
Die Schweiz
Swissair
Swissair ist die nationale Fluglinie
der Schweiz. Sie bietet Ihnen in
ihrem aktuellen Flugplan beste Verbindungen nach 4 Kontinenten an.
Besonders machen wir Sie auf
unsere attraktiven Sondertarife
aufmerksam.
...
...
...
...
...
Dokument 1
Die Schweiz, im Herzen
von Europa gelegen, ist
in 26 Kantone gegliedert.
...
...
...
Dokument 2
SWISSAIR
Flugplan Sommer 96
...
...
...
...
...
...
...
...
Dokument 3
Europa
...
...
...
...
Dokument 5
Dokument 4
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
78
WWW
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
79
Datenbanksysteme im Internet/Intranet/Extranet
■
Aufgabe 1:
existierende Datenbanken in der neuen Umgebung verfügbar machen
●
●
●
●
■
Aufgabe 2:
WWW ermöglicht breite Verfügbarkeit, einheitliche Oberfläche für
unterschiedliche Datenbestände bei beliebigen Klienten
für alle Arten von DBMS (und andere Systeme) möglich
keine automatische Datenintegration (——> verteilte Datenbanken)
keine automatische Client/Server-Lösung
DBMS für die Verwaltung grosser Mengen von HTML-Dokumenten etc.
auf WWW-Servern
●
●
●
Suche, Konsistenthaltung, Versionierung, Kompression, ...
Unterstützung für die WWW-Verantwortlichen
erfordert funktional reichhaltiges DBMS
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
80
WWW-Anbindung von DBMS
WWW-Server
HTTP
CGIProgramme
HTMLDokumente
DBMS
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
81
DB-Technologie für Internet/Intranet/Extranet: Ausgangslage
■
Annahmen: ●
●
●
●
■
daher dringend erforderlich:
weiteres Anwachsen der Informationsflut
neue Arbeitsumgebung macht mehr Informationen zugänglich
grosse Artenvielfalt der Informationen
weitere Einsatzfelder der Web-Technologie, vor allem für Intranets
(z.B. gezielte Informationsverteilung, Bearbeitung von Geschäftsvorfällen)
● sinnvolle Nutzung der technischen Möglichkeiten bringt grosse Vorteile
● mehr Struktur/Strukturierungsmöglichkeiten
● einfacher, leistungsfähiger, gezielter Umgang
mit Netzinformation (für Nachfrager und Anbieter)
● Steuerungs- und Überwachungsmöglichkeiten für
Aktivitäten im Netz
■ Datenbanktechnologie kann hierfür Lösungen/Unterstützung bieten
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
82
■
DBMS-Architektur der Zukunft:
Monolith oder was sonst ?
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
83
Resümee
•
es wird (aus guten Gründen!) eine zunehmend grössere Funktionalität von DBMS
gefordert (die besprochenen Beispiele geben bei weitem kein vollständiges Bild!)
•
generelle Tendenzen:
•
aber auch:
——>
– "mehr Semantik in DB/DBMS"
– grössere Diversifikation (Anforderungen, Lösungen)
– grosse Datenmengen liegen nicht in DBMS vor
(z.B. Spreadsheets, viele “Multimedia”-Daten, ...)
– zunehmend auch hierfür DBMS-Funktionalität gewünscht
kann dies wirklich alles noch von (mehr oder weniger)
monolithisch aufgebauten Allround-DBMS vernünftig
geleistet werden ???
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
84
einige jüngere Forschungs- und Entwicklungsrichtungen
■ relationale DBMS
■ verteilte DBMS
■ TA-Monitore
■ objektorientierte DBMS
■ Client/Server-DBMS
■ geschachtelte TAs
■ objektrelationale DBMS
■ heterogene DBMS
■ lange TAs
■ temporale DBMS
■ DBMS-Föderationen
■ kooperierende TAs
■ aktive DBMS
■ Data Repositories
■ DB/IR-Integration
■ Multimedia-DBMS
■ Metadatenbanken
■ DB-Programmiersprachen
■ Geo-DBMS
■ Datenreplikation
■ persistente Objekte
■ deduktive DBMS
■ Zugriffsschutz
■ DBMS-Middleware
■ erweiterbare DBMS
■ Versionsverwaltung
■ Zugriffspfade
■ Data Blades
■ Schemaevolution
■ Tuning/Optimierung
■ Realzeit-DBMS
■ Anfragesprachen
■ Hauptspeicher-DBMS
■ universelle DB-Server
■ Sichtenkonzepte
■ DBMS-Parallelisierung
■ mobile Datenbanken
■ Data Warehouse (OLAP)
■ DBMS-Benchmarks
■ digitale Bibliotheken
■ Data Mining
■ Standards
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
85
generelle Tendenz: "mehr Semantik in DB/DBMS"
•
•
•
•
wo sinnvoll möglich; Kenntnisse in DB ohnehin vorhanden
explizite Repräsentation möglichst vielerlei Informationen (Zugänglichkeit, Änderbarkeit)
Standardmechanismen vs. Individuallösungen
Ersparnis häufiger DBS-Aufrufe
Anwendung
Anwendung
DBMS
DBMS
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
86
die Zukunft: DBMS als Komponentenarchitekturen ?
•
•
•
•
DBMS-Kernsystem (was muss es bieten, wie klein darf es sein, ...?)
DBMS-Erweiterungen
DBMS-Middleware (vgl. die heutigen Transaktionsmonitore)
OODBMS/ORDBMS/CORBA etc. weisen die Richtung (zumindest in Teilaspekten)
Anwendung
Anwendung
Middleware
DBMS
Erweiterungen
DBMS-Kern
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
87
Literaturhinweise
Die Literatur zu den hier besprochenen Themen ist naturgemäss umfangreich und vielfältig (und von sehr
unterschiedlicher Qualität). Eine recht umfassende und verständliche Behandlung der Thematik bieten die
beiden folgenden Bücher:
•
Alan R. Simon: Strategic Database Technology – Management for the Year 2000
Morgan Kaufmann Publishers, San Francisco, 1995
•
Bart O’Brien: Database Decisions – Briefings on the Management of Technology
Pitman Publishing, London, 1994
Dort sind auch zahlreiche Hinweise auf Literatur zu Details angegeben.
Auch über die auf dem Titelblatt genannte WWW-Heimatseite des Autors kann man zahlreiche Verweise zu
interessanten aktuellen Arbeiten auf diesem Gebiet finden.
©1997 Prof. Dr. Klaus R. Dittrich, IFI, Universität Zürich
88