Wie intelligent . . . . . . können Datenbanken sein ? Wie intelligent

DB
-Stammtisch, Dresden,
DB-Stammtisch,
Dresden,10.12.2003
10.12.2003
Wie
Wie intelligent
intelligent .. .. ..
?
.. .. .. können
können Datenbanken
Datenbanken sein
sein ??
Prof. Dr. Rainer Manthey
Universität Bonn
Institut für Informatik III
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
1
Kurzbiographie
Kurzbiographiedes
desVortragenden
Vortragenden
1973
1973 Kiel
Kiel
Universität Kiel
Informatik/Mathematik
Student
(Diplom
1979)
Mitarbeiter (Promotion 1984)
1953
1953 Wilhelmshaven
Wilhelmshaven
1992
1992Bonn
Bonn
Universität Bonn
Professor
1984
1984 München
München
European Computer-Industry
Research Centre (ECRC)
Forscher/Teamleiter
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
2
AG
AGIntelligente
IntelligenteDatenbanken
Datenbankenan
ander
derUniversität
UniversitätBonn
Bonn
AG
AG "Intelligente
"IntelligenteDatenbanken"
Datenbanken"
Prof. Dr. Rainer Manthey
• Aktive und deduktive
Datenbanken
(→ Geo- und Bio-DB)
• zur Zeit:
2 wiss. Mitarbeiter
7 Doktoranden
13 Diplomanden
• seit 1994 abgeschlossen:
3 Dissertationen
106 Diplomarbeiten
ProgrammierProgrammiersprachen
sprachen
Datenbanken
Datenbanken
• Ereignisorientierte und
deskriptive Programmierung
• Deduktionssysteme und
Wissensbasen
© 2003 Prof. Dr. Rainer Manthey
Künstliche
Künstliche
Intelligenz
Intelligenz
Dresden, 10.12.2003
3
"Intelligent
": exotisch,
"IntelligentDatabases
Databases":
exotisch,aber
aberdurchaus
durchausnicht
nichtunüblich!
unüblich!
1998
1993
Begriff "intelligente Datenbank":
• in der Wissenschaft relativ selten verwendet und nicht präzisiert
• in D: nur an 2-3 Universitäten
• im Ausland: deutlich häufiger!
• im kommerziellen Kontext hin und
wieder intuitiv und vage
• "Literaturlage": sehr uneinheitlich!
Begriff
Begriffsehr
sehrbreit
breit"interpretierbar"
"interpretierbar"!!
• unser Ansatz: "bodenständig"
IDB
ADB ⊕⊕ DDB
DDB
IDB==defdef ADB
2001
© 2003 Prof. Dr. Rainer Manthey
intelligent
Dresden, 10.12.2003
aktiv
deduktiv
4
Deduktive
DeduktiveDB
DB
Deduktives
DeduktivesDatenbanksystem:
Datenbanksystem:
Inferenzsystem
-Funktionalität
Inferenzsystem mit
mit DB
DB-Funktionalität
generische
generische
Inferenz
Inferenzkomponente
komponente
DBMS
ableitbare
Information
DB
anwendungsspezifische
anwendungsspezifische
Inferenzregeln
Inferenzregeln
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
5
Deduktive
DeduktiveDB
DBund
undSQL
SQL
• Obwohl die Forschung zu „Deduktive Datenbanken“ fast ausschließlich die Sprache
Datalog verwendet („Logic and databases“), ist SQL als Basis für eine deduktive
Datenbank ebenso gut geeignet!
• „Sprachregelung“:
• SQL-Sicht ≡ abgeleitete Tabelle
• CREATE VIEW-Anweisung
≡ deduktive Regel
VIEW
•
In der DDB-Forschung werden zwei alternative Inferenzformen untersucht:
• ausgehend von Anfragen:
virtuelle Sichten
• ausgehend von Änderungen: materialisierte Sichten
•
SQL-Sichten (gemäß Standard) sind virtuell, manche Produkte kennen aber bereits
materialisierte Sichten (etwa Oracle).
•
Wichtiger Spezialfall virtueller Sichten fehlt aber in SQL: „Boolesche Sichten“
(Ja-/Nein-)Anfragen sind erstaunlicherweise in SQL nicht ausdrückbar!
•
Abgeleitete Tabellen sind in SQL (leider) nur „Bürger zweiter Klasse“.
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
6
Deduktive
DeduktiveDB
DBund
undSQL
SQL(2)
(2)
•
zentrales Problem der Forschung zu „Deduktive Datenbanken“:
effiziente Handhabung rekursiver Sichten
•
SQL kennt seit SQL:1999 ebenfalls eingeschränkte Formen von Rekursion:
• WITH RECURSIVE . . .
• CREATE RECURSIVE VIEW . . .
•
Rekursive Sichten sind von großer Bedeutung für alle Anwendungen, die . . .
• . . . Daten über Netzwerke verwalten (Geo-Anwendungen)
• . . . Hierarchien traversieren (Management, komplexe Produktstruktur)
•
Netzwerk-Daten: z.B. taktgesteuerte Fahrpläne, Routenplanung
pfad(X,Y,
L+1) if verbindung(X,Z) and pfad(Z,Y,
L).
pfad
pfad
•
Hierarchie-Daten: z.B. „Bill of Material“-Erstellung
cost(Part,
C) if C = sum(C‘: subpart(P‘, P) and cost(P‘,C‘)))
cost
cost
•
SQL-Produkte bieten bisher nur sehr stark spezialisierte Formen von Rekursion
mit explizitem Abbruchkriterium (tiefenbeschränkte Suche in Graphen).
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
7
Aktive
AktiveDB
DB
Aktives
AktivesDatenbanksystem:
Datenbanksystem:
reaktives
-Funktionalität
reaktivesSystem
Systemmit
mitDB
DB-Funktionalität
Sensoren
Sensoren
stimulierende
Ereignisse
ausgelöste
(Re-)Aktionen
DBMS
Effektoren
Effektoren
anwendungsspezifische
anwendungsspezifische
Reaktionsmuster
Reaktionsmuster
© 2003 Prof. Dr. Rainer Manthey
DB
Dresden, 10.12.2003
8
Aktive
AktiveDB
DB(2)
(2)
„State of the art" bei kommerziellen Datenbanksystemen (SQL)
• Sensorium und Aussenwirkung sind beschränkt auf die
"übliche" DB-Schnittstelle (Änderungen, Antworten)
• Menschliche/extern programmierte "Vermittlung" ist erforderlich.
DBMS
DB
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
9
Aktive
AktiveDB
DBund
undSQL:
SQL:Triggerkonzept
TriggerkonzeptininSQL:1999
SQL:1999
Auslösezeitpunkt
Triggername
auslösende
Änderung
CREATE
CREATETRIGGER
TRIGGER ersteVorlesung
ersteVorlesung
AFTER
AFTER INSERT
INSERTON
ON professoren
professoren
REFERENCING
Granularität
REFERENCING NEW
NEWROW
ROWAS
AS Newcomer
Newcomer
FOR
EACH
ROW
FOR EACH ROW
WHEN
WHEN NOT
NOTEXISTS
EXISTS
((SELECT
SELECT **
Bedingung
FROM
FROM vorlesungen
vorlesungen
WHERE
.Name ))
WHERE Name
Name==Newcomer
Newcomer.Name
BEGIN
BEGINATOMIC
ATOMIC
INSERT
INSERT INTO
INTO vorlesungen
vorlesungen
Aktion
VALUES
Newcomer.Name, NULL,
-std.);
VALUES ((Newcomer.Name,
NULL,44-std.);
INSERT
INSERT INTO
INTO übungen
übungen
VALUES
Newcomer.Name, NULL,
-std.)
VALUES ((Newcomer.Name,
NULL,22-std.)
END
END
© 2003 Prof. Dr. Rainer Manthey
"Transitionsvariable"
Dresden, 10.12.2003
10
Integritätsbedingungen:
Integritätsbedingungen:deduktiv
deduktivoder
oderaktiv
aktiv??
• Neben aktiven und deduktiven Regeln (Trigger und Sichten) gibt es noch eine dritte
Kategorie von Regeln, mit denen man in einer Datenbank „Wissen“ repräsentieren kann:
normative
normativeRegeln
Regeln
oder: Integritätsbedingungen
• Normative Regeln werden sowohl im Spezialgebiet ‚Aktive Datenbanken‘ als auch
unter dem Label ‚Deduktive Datenbanken‘ untersucht.
• Die Anwendung von normativen Regeln besteht aus zwei Phasen:
• Integritätsprüfung („integrity checking“): deduktiver Prozess
• Integritätserhaltung („integrity maintenance“): aktiver Prozess
• Integritätsprüfung (deduktiver Anteil) erfolgt in der Regel automatisch durch das DBMS,
integritätserhaltende Aktionen (aktiver Anteil) müssen anwendungsbezogen selbst programmiert werden (Ausnahme: Erhaltung referentieller Integrität).
• Gibt es “intelligente” Integritätsbedingungen?
Constraints in SQL werden oft als primitiv empfunden, weil die kommerziellen
Systeme sämtlich den Standard nicht einmal annährend implementieren
(mehr dazu später)!
Dresden, 10.12.2003
11
© 2003 Prof. Dr. Rainer Manthey
Können
KönnenDatenbanken
Datenbanken„intelligent“
„intelligent“sein
sein??
• These dieses Vortrags:
Setzt
Setztman
mandie
die„klassischen“
„klassischen“DB-Konzepte
DB-Konzepte
••
••
••
Sicht
Sicht
Integritätsbedingung
Integritätsbedingung
Trigger
Trigger
(deduktive
(deduktiveRegel)
Regel)
(normative
(normativeRegel)
Regel)
(aktive
(aktiveRegel)
Regel)
bewusst
bewusstund
undkonsequent
konsequentzur
zurAnwendungsmodellierung
Anwendungsmodellierungein,
ein,
dann
dannkann
kanndas
dasDBMS
DBMSdurchaus
durchaus„künstlich
„künstlichintelligentes“
intelligentes“Verhalten
Verhaltenzeigen.
zeigen.
• (Versuch einer) Begründung:
• Die drei Regelformate dienen zur expliziten, individuellen Darstellung
von Wissen über die jeweilige Anwendung („business rules“).
• Aktivieren von Regeln durch das DBMS simuliert logisches Schließen
bzw. folgerichtiges Handeln.
Handeln
• überraschend, aber zutreffend: Anfrageoptimierer sind automatische Beweiser !!
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
12
Fallstudie
-Datenbank
FallstudieBundesliga
Bundesliga-Datenbank
• Fallstudie zur Anwendungsmodellierung mit deduktiven Techniken:
MS Access-Datenbank mit Ergebnissen der Fußball-Bundesliga
• Die DB enthält nur 3 gespeicherte (Basis-)Tabellen:
Tabellen
• Vereine (Name, Stadt, Kurzform, Trainer)
• Resultate (Datum, Heim, ToreH, Auswärts, ToreA, Spieltag)
• Punktabzug (Verein, Punktabzug)
bundesliga.mdb
• Dazu kommen aber 36 Sichten (abgeleitete Tabellen) vorwiegend zur Berechnung
der jeweils aktuellen Bundesliga-Tabelle: eine weitgehend deduktive Datenbank !
• Jede Sicht definiert (mindestens) einen Fachbegriff aus der „Fußballterminologie“:
• Die Datenbank enthält offenbar Wissen über ihre Anwendungsdomäne.
• Das DBMS wendet dieses Wissen auf vernünftige Art und Weise zur
Problemlösung an.
Ist
Istdas
dasschon
schoneine
eineintelligente
intelligenteDatenbank?
Datenbank?
•
Die Beispiel-DB hat an sich höchstens Unterhaltungswert (und enthält trickreiches
SQL): Die Fallstudie dient aber vor allem als Anregung zur Analogiebildung !!
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
13
Bundesliga
-DB: Sichtenhierarchie
Bundesliga-DB:
Sichtenhierarchie==Taxonomie
Taxonomievon
vonFachbegriffen
Fachbegriffen
Tabelle
Positionen
AnzahlBesserAls
TabelleOhnePosition
abgeleitete
Tabellen
Punkte
Tore
Spiele
Siege
gespeicherte
Tabellen
© 2003 Prof. Dr. Rainer Manthey
BesserAls
AnzahlSiege
AnzahlUnentschieden
AnzahlNiederlagen
Unentschieden
Niederlagen
Resultate
Vereine
Dresden, 10.12.2003
Punktabzug
14
Bundesliga
-DB: „Intelligentere“
Bundesliga-DB:
„Intelligentere“Integritätsbedingungen
Integritätsbedingungen
• Diverse „business rules“ der Fußball-Bundesliga sind normativer Natur: Sie bestimmen,
was sinnvolle DB-Zustände sind, und werden durch Integritätsbedingungen ausgedrückt.
• Beispiele für solche Integritätsregeln:
Integritätsregeln
• Ein Verein kann nicht gegen sich selbst spielen.
• Pro Spieltag bestreitet jeder Verein genau ein Spiel.
• Jeder Verein spielt in Hin- und Rückrunde genau einmal gegen jeden
anderen Verein der Liga.
• Jeder Verein spielt gegen jeden anderen Verein einmal zuhause und einmal
auswärts.
• Pro Spieltag finden genau 9 Spiele statt.
• Jeder Verein hat in der Hin- und in der Rückrunde jeweils 9 Heim- und
9 Auswärtsspiele.
• Alle diese Bedingungen lassen sich gemäß Standard in SQL ausdrücken –
aber keine von ihnen wird von irgendeinem kommerziellen DBMS heutzutage
akzeptiert !
• Man kann sich natürlich auch einfach darauf verlassen, dass man bei der Eingabe keine
Fehler macht . . .
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
15
Integrität
IntegritätininSQL:
SQL:Die
DieSicht
Sichtdes
desStandards
Standards
Sichten
Sichten
(abgeleitete
(abgeleiteteTabellen)
Tabellen)
global
Integritätsbedingungen
Integritätsbedingungen
global
lokal
Basistabellen
Basistabellen
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
16
Integrität
-of-the-art im
IntegritätininSQL:
SQL:State
State-of-the-art
imkommerziellen
kommerziellenSektor
Sektor
Keine
KeineConstraints
Constraintsüber
über
abgeleiteten
abgeleitetenTabellen
Tabellen! !
Keine
KeineConstraints
Constraintsüber
über
mehreren
mehrerenTabellen
Tabellen! !
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
17
Integrit
ät ininSQL:
Integrität
SQL:Ausdrucksmöglichkeiten
Ausdrucksmöglichkeitenkommerzieller
kommerziellerSysteme
Systeme
CREATE
CREATETABLE
TABLE Conference_talk
Conference_talk
((
Speaker
Speaker
Title
Title
Session
Session
Type
Type
Duration
Duration
VAR
CHAR(20) NOT
NULL
VARCHAR(20)
NOTNULL,
NULL,
column
VAR
CHAR(80) UNIQUE,
UNIQUE
columnconstraints
constraints
VARCHAR(80)
UNIQUE,
INT,
INT
INT,
VARCHAR(7)
VARCHAR(7) CHECK
CHECK IN
IN ( ('short',
'short','long',
'long','invited'
'invited'),),
INT
CHECK
INT
CHECK IN
IN ( (15,
15,30,
30,60
60),),
PRIMARY
PRIMARY KEY
KEY
FOREIGN
FOREIGN KEY
KEY
(Session,
(Session,Speaker),
Speaker),
Speaker
Speaker REFERENCES
REFERENCES Participant
Participant, ,
CHECK
CHECK Duration
Duration== CASE
CASE
WHEN
WHEN Type
Type=='short'
'short' THEN
THEN 15
15
table
WHEN
tableconstraints
constraints
WHEN Type
Type=='long'
'long' THEN
THEN 30
30
WHEN
WHEN Type
Type=='invited'
'invited' THEN
THEN 60
60
END
END
Einschränkung
:
))
Einschränkung:
Keine
Keineeingebetteten
eingebettetenAnfragen
Anfragen!!
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
18
Integrität
IntegritätininSQL:
SQL:Assertions
Assertions
• „Urform“ und allgemeinstes Format von Integritätsbedingung: separat vereinbarte
Zusicherungen (engl.: „assertions“).
assertions Seit dem ersten SQL-Standard Teil von SQL !
CREATE
CREATEASSERTION
ASSERTION NeunSpieleProSpieltag
NeunSpieleProSpieltag AS
AS
CHECK
CHECK(NOT
(NOTEXISTS
EXISTS(SELECT
(SELECTSpieltag
Spieltag
FROM
FROMResultate
ResultateAS
ASXX
WHERE
WHERENOT
NOT((SELECT
((SELECTCOUNT(*)
COUNT(*)
FROM
FROMResultate
ResultateAS
ASYY
WHERE
)
WHEREX.Spieltag=Y.Spieltag
X.Spieltag=Y.Spieltag)
==99)
) ))))
Pro Spieltag finden genau 9 Spiele statt
• Diese Form von Integritätsbedingung wird für alle aufgeführten Beispielconstraints
des Bundesliga-Beispiels benötigt.
• aber: Assertions sind bisher noch von keinem DB-Hersteller implementiert worden!
(Argument: zu aufwändig, zu kompliziert, zu ineffizient)
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
19
Integrität
IntegritätininSQL:
SQL:Table
Tablecheck
checkconstraints
constraintsmit
miteingebetteten
eingebettetenAnfragen
Anfragen
• Zum Glück geht‘s auch einfacher – zumindest für diese Integritätsbedingung läßt sich
eine äquivalente Formulierung mittels einer CHECK-Constraint in die Tabellendefinition der Resultate-Tabelle einbauen:
CREATE
CREATETABLE
TABLE Resultate
Resultate
((. .. .. .
CHECK
CHECK ((SELECT
((SELECTCOUNT(*)
COUNT(*)
FROM
FROMResultate
ResultateAS
ASYY
WHERE
)
WHERE Spieltag=Y.Spieltag
Spieltag=Y.Spieltag)
==99)
) )))); ;
Pro Spieltag finden genau 9 Spiele statt
• Das funktioniert aber nur in speziellen Fällen, keineswegs immer!
immer Assertions sind
unverzichtbar, will man die Ausdrucksstärke von SQL nicht beeinträchtigen.
• und leider:
Auch diese Form von CHECK wird in keinem kommerziellen DBMS unterstützt !
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
20
Effiziente
EffizientePrüfung
Prüfungvon
vonAssertions
Assertionsdurch
durchSpezialisierung
Spezialisierung
INSERT
INSERTINTO
INTOResultate
Resultate
VALUES
VALUES(07.12.2003,
(07.12.2003,Schalke,
Schalke,2,2,Gladbach,
Gladbach,1,1,15)
15)
konkrete Änderungsoperation U
CREATE
CREATEASSERTION
ASSERTION NeunSpieleProSpieltag
NeunSpieleProSpieltag AS
AS
CHECK
CHECK(NOT
(NOTEXISTS
EXISTS(SELECT
(SELECTSpieltag
Spieltag
FROM
FROMResultate
ResultateAS
ASXX
WHERE
WHERENOT
NOT((SELECT
((SELECTCOUNT(*)
COUNT(*)
FROM
FROMResultate
ResultateAS
ASYY
WHERE
)
WHEREX.Spieltag=Y.Spieltag
X.Spieltag=Y.Spieltag)
==99)
) ))))
auf U spezialisierte Form
der Assertion
© 2003 Prof. Dr. Rainer Manthey
CHECK
CHECK ((SELECT
((SELECTCOUNT(*)
COUNT(*)
FROM
FROMResultate
Resultate AS
AS YY
WHERE
WHERE15
15=Y.Spieltag)
=Y.Spieltag)
==99)
) ))))
Dresden, 10.12.2003
21
Inkrementelle
InkrementelleÄnderungspropagierung
Änderungspropagierung
Seit vielen Jahren prinzipiell beherrscht
(aber im SQL-Kontext noch weitgehend unbekannt):
inkrementelle
inkrementelle
Änderungspropagierung
Änderungspropagierung
• analoge Fortführung der Spezialisierungstechniken auf Sichten
• Basis für effiziente Integritätsprüfung über Sichten
• gleichzeitig: Technik zur inkrementellen Anpassung von
materialisierten Sichten
• Propagierung durch rekursive
Sichten: erst seit wenigen Jahren
gemeistert
© 2003 Prof. Dr. Rainer Manthey
INSERT
INSERT
Dresden, 10.12.2003
22
Anwendungsszenario
AnwendungsszenarioMonitoringsysteme
Monitoringsysteme
Intelligent
IntelligentMonitoring
Monitoringofof
Events
EventsininTime
Timeand
andSpace
Space
interactive
vizualisation
discrete
discrete
event
event
simulation
simulation
stream of
sensor signals
event
detection
„reality“
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
event
event
log
log
knowledgebased
analysis
domain
domain
knowledge
knowledge
23
IMS:
IMS:Anwendungsgebiete
Anwendungsgebiete
Es gibt vielfältige Möglichkeiten, intelligente reaktive Überwachungssysteme zur
Entscheidungsunterstützung einzusetzen (reactive decision support):
aktuelles
Projekt
SIMON
•• Verkehr
:
Verkehr:
•• Verkehrsnetze
Verkehrsnetze(Bahn,
(Bahn,ÖPNV)
ÖPNV)
•• Strassen/Autobahnen
Strassen/Autobahnen(Staus,
(Staus,Maut)
Maut)
•• Luftraumüberwachung
Luftraumüberwachung
•• Transportunternehmen
fleet management
")
Transportunternehmen("("fleet
management")
•• Militär
battlefield surveillance
")
Militär(Truppenbewegungen,
(Truppenbewegungen,""battlefield
surveillance")
•• Verwaltung
:
Verwaltung:
•• Verfahrensbegleitung
)
Verfahrensbegleitung(Justiz,
(Justiz,Steuerbehörden,
Steuerbehörden,Prüfungsämter
Prüfungsämter)
•• Banken
:
Banken:
•• Kontenbewegungen,
Kontenbewegungen,Kreditwürdigkeit
Kreditwürdigkeit
•• Kursbewegungen,
Kursbewegungen,Portfoliomanagement
Portfoliomanagement
•• Gesundheit
:
Gesundheit:
•• Patientenüberwachung
Patientenüberwachung(Intensivmedizin,
(Intensivmedizin,Medikamentengabe)
Medikamentengabe)
•• Seuchenerkennung
Seuchenerkennung(z.B.
(z.B.Krebsregister
Krebsregister
•• u.v.a.
u.v.a.
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
24
Änderungspropagierung
-Anwendungen
Änderungspropagierungfür
fürMonitoring
Monitoring-Anwendungen
„Alarm“
Überwachungskriterien
?
+/−
+/−
+/−
+/−
+/−
Geschäftsregeln
+/−
Sensorsignal
+
Systemzustand
+/−
event log
© 2003 Prof. Dr. Rainer Manthey
Unternehmensdaten
Dresden, 10.12.2003
25
Data
Datastreams
streams&&continuous
continuousqueries
queries
?
+
+
!
!
!
!
Monitorbedingungen als
kontiuierliche Anfragen
+
!
!
!
.....
inkrementelle Propagierung
von „bewerteten“ Signalen
.....
+
+
+
+ +
+
+
Strom diskreter Sensordaten
t
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
26
Resümee
Resümee
Können Datenbanken intelligent sein?
Setzt
Setztman
mandie
die„klassischen“
„klassischen“DB-Konzepte
DB-KonzepteSicht,
Sicht,Integritätsbedingung
Integritätsbedingungund
undTrigger
Trigger
bewusst
bewusstund
undkonsequent
konsequentzur
zurAnwendungsmodellierung
Anwendungsmodellierungein,
ein,dann
dannkann
kanndas
dasDBMS
DBMS
durchaus
durchaus„künstlich
„künstlichintelligentes“
intelligentes“Verhalten
Verhaltenzeigen.
zeigen.
Wie intelligent können Datenbanken wirklich sein?
• SQL muss noch an entscheidenden Stellen erweitert,
erweitert ergänzt und konsequenter
gestaltet werden, um das Potential der Regelkonzepte voll auszuschöpfen.
• Kommerzielle SQL-Systeme müssen um fehlende Techniken zur Regelaktivierung
ergänzt werden, die in der Forschung bereits bekannt und konsolidiert sind, aber
von den Herstellern noch nicht (angemessen) wahrgenommen worden sind.
• Investitionen in überzeugende Demonstrator-Anwendungen für Nutzen und Eleganz
„intelligenter“ DB-Schemata sind noch erforderlich, um Überzeugungsarbeit bei
den Anwendern zu leisten.
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
27
VVLDB
LDB ⇒
SDB
⇒VVSDB
Very Large Data Bases
Very
VerySmart
SmartData
DataBases
Bases
© 2003 Prof. Dr. Rainer Manthey
Dresden, 10.12.2003
28