Datenbanken I 1. Einf¨uhrung - Technologie der Informationssysteme

Prof. Dr. rer.nat.habil. Bernhard Thalheim
Information Systems Engineering
Department of Computer Science
Christian-Albrechts-University Kiel
Olshausenstr. 40
D - 24098 Kiel
Vorlesung
Datenbanken I
1. Einführung
SS 2008
1 Grundlagen und Ziele
Für die Erörterung im schriftlichen Teil der Vorlesung: Systematik
Hier: Informationssysteme aus der Sicht des Informatikers
Informatik: Wissenschaft (oder Kunst) der formalen Sprachen zur Beschreibung von abstrakten Dingen und Handlungsabläufen
• erfinden
Syntax
Form der formalen Sprache, Standardisierung, Rückgriff auf existierende Verständigungsmittel, verschiedene
Detailisierung (bis hin zu abstrakten Maschinen)
• verwirklichen (d.h. beherrschbar)
implementieren erst nach Festlegung der Semantik, verschiedene Semantiken (operationale, ...)
• nutzen
Beschreibung der Aufgaben mit den Mitteln der Sprache, Methodologie
schwierigste Teile: von informal zu formal
Semantik
Pragmatik
Wolkenbild mit Maschine
Semiotisches Dreieck: Syntax, Semantik, Pragmatik
formale Sprache
erfinden
verwirklichen
benutzen
Paradigmen
\
Theorie
Abstraktion
Entwurf
Unsere Vorlesungsanwendung : Universitätsdatenbank (Verwaltung von Studenten, Mitarbeitern, Ressourcen (Gebäude, HW, SW, Bücher, ...), Fonds, Stundenplanung, ... ) mit unterschiedlichen Sichten
1.1 Information, Kommunikation
Zeitalter
1. Zeitalter der manuellen Produktion
Jäger, Sammler, Landwirte, Handwerker
2. Industriezeitalter
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
2
3. Informationszeitalter
Der Mensch ändert sich nicht so sehr wie die Technik suggeriert.
Psychologische Barrieren
• Verarbeitungskapazität des Menschen
• Formulierungsfähigkeit des Menschen
• Gewohnheiten des Menschen
US-Diskussion der ‘Y’-Gesellschaft und der Trennung
Wir sind bereits in Informationen ertränkt.
• Anstelle von mehr Information brauchen wir Information
• zur rechten Zeit,
• der richtigen Sorte,
• in der richtigen Dosis,
• in der richtigen Form,
• im vollen Umfang,
• zu akzeptablen Kosten
für alle Benutzer (bzw. Anwendungen) unserer Informationssystemes.
• Der Mensch ist das einzige Ziel der Information.
• Gespeicherte Information muß verarbeitet werden, ehe sie Nutzen bringt.
Information
Daten +
empfangen +
ausgewählt durch Interesse +
integriert
1.1.1 Einleitung
Verschiedene Arten von Informationssystemen (Sammlung von Daten):
Computerized Information System
CIS
Management-Informationssysteme POI-Systeme, meist Spreadsheet-unterstützt, graphische Oberfläche, einfache Bedienung, Vernetzung mit Partnern mit unterschiedlichen Aufgaben im System, hierarchisch
Entscheidungsunterstützungssysteme meist stand-alone-Lösungen, Expertensystem-shell-basiert, verschiedene
Unterstützung für Äbwägen, Diskussion, Rücknahme
(Hyper)textsysteme Volltextsysteme mit umfangreichen Verweismöglichkeiten und evt. logischen Ableitungen
(zwischen den Zeilen) (Supertextsysteme)
Information-Retrieval-Systeme meist über Deskriptoren organisiert, einfache Funktionen, einfache Datenstrukturen, effiziente Suche, schwierig zu erweitern, unscharfe Suche, unscharfe Daten
Dokumentationssysteme hierarchisch, Deskriptoren, komplexe Struktur, eingeschränkte, schnelle Suche
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
3
Büroinformationssysteme kleine Anwendungssysteme, kooperative Lösung
Datenbanksysteme Datenbeschreibungssprache (basierend auf Datenmodell), viele Funktionen, optimierend, verteilte Systeme, Konsistenz, Sicherheit, konkurrierender Zugriff und Fehlerbehandlung (Zurückfahren), Sichten für verschiedene Nutzer
Wissensbanken
Datenbanken sind übergreifend
Entwicklung der DBMS führte zur Integration verschiedener Funktionen anderer Arten von CIS
• graphische Oberfläche
• deduktive Datenbanken
• aktive Datenbanken
• parallele Datenbanken
• Deskriptoren
• Wissensverarbeitung
• objektorientierte Entwicklung
• Reasoning-Funktionen zum Abwägen und Ableiten
• groupware-middleware-Datenbanken
• telekommunikative, mobile Datenbanken
Trotzdem: Datenbanksysteme haben nicht die gesamte Funktionalität von allen CIS (und werden diese auch nicht
anstreben).
Volltextsysteme, Entscheidungsunterstützungssysteme, inexakte, inkonsistente Daten, ...
Entscheidungsunterstützungssysteme sind spezielle Datenbanken.
Vielfältige Anwendungen: Materialwirtschaft, Reservierungssysteme, Bibliotheksverwaltungssysteme, Versicherungswirtschaft, Banken, Meldewesen, Auskunftswesen, Produktionsplanung und -steuerung, Personalverwaltung,
Auftragsverwaltung, ...
Neuartige Anwendungen: CAx, Büroinformationssystem, Geoinformationssysteme, Prozeßdatenverarbeitung, Versuchsdaten, intelligente Systeme, statische Systeme, Multimediasysteme, ... Musikverarbeitung
Riesiger Marktsprung (siehe Übersicht)
Kennzeichen einer DB
• große Mengen von Daten
large amount
• dauerhaft
persistent
• verläßlich
dependable
• verschiedene Benutzer
• Sicherheit der Daten
• effizient
shared
security
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
4
• verwalten
• Anfragen
storage management
queries
ad-hoc-Anfragesprachen
• Änderungen
updates
‘Unternehmen’ kann Informationssystem auf verschiedene Arten benutzen; evt. auch gemischt
1. System ist “Modell” der Welt (Daten als Gegebenheiten)
2. System verwaltet ‘Original’dokumente (Bsp. Programmentwicklungssystem, Referatesystem)
3. System wird als ‘schwarzes Brett’ benutzt (gemeinsame Hinterlegung von Daten; Austausch (Bsp. Patienteninformationssystem))
⇒
Anforderungen
• “Daten” strukturieren (für alle Benutzer verstehbar + verwaltbar)
• verschiedenartige Benutzer wirken zusammen, unabhängig - wie ? wie sicher ?
• Gestaltung von Oberflächen bei gleichzeitiger einheitlicher Verwaltung
• Kommunikation
⇒
Besonderheiten von Informationssystemen
• Modellierung formalisierbarer statischer und dynamischer Gesichtpunkte von ‘Unternehmen’
• anschauliche Beschreibungen
• formale Beschreibungen
semantische Begriffe
Modelle
• Datenmodelle (logische, relationale, objektorientierte)
• Algorithmenmodelle (Transaktionen)
• Implementierungen
• Structured Query language, QBE, Quel, Datalog, ...
• Algorithmen, Datenstrukuren für (relationale) Operationen
• unterliegende System (C++, Ontos, ...)
• Dauerhaftigkeit und Teilhabe
• Transaktionen
• Schemaentwurf
• Sicherheit
• Schichtenarchitektur
Außerdem: ‘Unternehmen’ bestehen aus Menschen; DB als technisches Hilfsmittel
⇒
Definition von Information , Kommunikation, Wirklichkeit und Modell erforderlich
Hinzu: Informationssystem beeinflußt auch den Geschäftsablauf
Historie
Generationen verschiedene Einteilungen; evt. analog zu Rechnergenerationen
1. Filesysteme auf Band bzw. später auf Platte
50-er + 60-er
Redundanz, Gefahr der Inkonsistenz, Inflexibilität, eingeschränkte Produktivität (aufwendige Programmierung), Datenschutzprobleme, Einhaltung und Durchsetzung von Standards
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
5
2. Prärelationale Systeme
70-er
Unterscheidung der physischen und logischen Sicht
Katalog, verschiedene Benutzer
hierarchisches und Netzwerk-Datenmodell
Redundanzvermeidung, zentrale Integritätskontrolle, Strukturierung, DML und DDL
relativ implementationsnah, navigierender Zugriff
Effizienzprobleme, Konsistenzprobleme, Sicherheitsprobleme, Compatibilität
1961 C. Bachman’s Vorschlag, 1965-70 IMS DB/DS (Netzwerk), Dodd’s APL für PL/1, Sabre (IBM + Am.
Airlines), IBM’s hierarch. System
1971 CODASYL DBTG Vorschlag; IDMS, IDS II, DMS verschied. Hersteller
1985 Vorschlag für NDL (Network defintion language)
3. Relationale Systeme
Dreiebenenarchitektur, Unabhängigkeit der konzeptionellen Darstellung
mächtige Sprachen
mengenorientiert, Programm-Daten-Unabhängigkeit, Datenabstraktion, insert, delete, update
1970 E.F. Codd (Childs); 1975 VLDB, 1972 ACM SIGMOD; 1976 P.P. Chen
SQUARE, SEQUEL (SQL), QBE, QUEL
1985 Preliminary SQL, 1986 ANSI SQL, SQL 89, SQL 2; 199x SQL 3 (x > 5)
Etappen der Entwicklung des relationalen Systeme
80-er
• Codd’s Arbeit in den Comm. of the ACM, 1970
• MacAIMS (1970-71) (R. Godstein, J. Strnad)
• IS/1, PRTV (71-75)
• Große Debatte von Codd/Date und Charlie Bachmann
• System R (Mitte 70er)
• System Ingres (Mitte 70er)
• frühe relationale Produkte (79-83)
• Tandem NonStop SQL (87) mit ersten besseren Leistungsparametern
Hauptbeträge zur Entwicklung der Technologie
• Arbeiten von Hall, Todd, Hitchcock, Immon, Stonebraker, Strnad (parallel zu Codd 1971 im IFIP Congress) zu IS/1- und PRTV-Prototypen
• Arbeiten von Chamberlin, Traiger u.a. zum R Prototypen
• Arbeiten von Zloof zu QBE
• Arbeiten von Stonebraker zum Ingres Prototypen
• Arbeiten von Armstrong, Fagin u.a. zur Abhängigkeitstheorie
4. Postrelationale Systeme
90-er
aufgrund obiger neuartiger Anwendungen Erweiterung der Funktionalität
umfangreichere Typenkonstruktoren, verbesserte Semantik, umfangreichere Operationalität, Verhalten, Mehrnutzerbetrieb, offene Systeme, objektorientierte Systeme, Versionen, räumliche Daten, aktive Anwendungen
Vermutung: keine universellen Systeme, eher anwendungsspezifische
goodies: benutzerdefinierte Datentypen, Vererbung
Falsche Ansichten zu OODB
• blobs + gespeicherte Prozeduren = Objekte
Typ hat Zustands- und Verhaltenscharakteristika (blobs nur Zustand), Typen sind in Hierarchie (?),
klare Trennung von Typ-Spezifikation und -Implementation
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
6
• richtige DBMS unterstützen SQL
besser Vielzahl von Sprachkonzepten
• Client-Server = Client-Server
relationales Client-Server-Modell ist Auswuchs der mainframe-Architektur (Steuerung, auch für Terminals und Benutzeroberflächen durch Server); besser Verteilung nach Rechenleistung etc. auf Server
Objektrelationale
Modelle
XMLbasierte
Modelle
i
}
6
XMLAlgebraWirrwarr
16
Universelle
Modelle
Objektorientierte
Modelle
Deduktive
Modelle
]
6
Relationale
Modelle
6
Navigationsmodelle
6
File
Strukturen
Datenabstraktionshierarchie
HERMAlgebraAusdrücke
]
6
Logikbasierte
Ausdrücke
Erweiterte
EntityRelationshipModelle
6
EntityRelationshipModelle
6
Relationale
Algebra
6
Normalisierungstheorie
6
Anfrageberechnungsstrategien
6
Rekursionsmodelle
Baumstrukturen
6
6
Implementations- Strukturierte
programme
Programmierung
Algorithmische
Hierarchie
Modellieringshierarchie
Abbildung 1: Generationen 1, 2, 3, 4 von Datenbankverwaltungssystemen
Relationale Systeme
1. SQL - Linie
SQL ist De-Facto-Standard der relationalen Datenbankwelt
• 1970 : Codd’s Arbeit
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
7
• 1974 : Chamberlain’s SEQUEL
verschiedene Versionen 1975 (SEQUEL-XRM), 1977 (SEQUEL/2 - R), Standardisierung, 1981 (ORACLE,
SQL/DS), 1983 (DB2), DG/SQL (1984), SYBASE (1986), ...
• SQL-Standardisierung
ISO 9075 (1987) - größerer gemeinsamer Nenner
ISO 9075 (1989) - echter Standard, Integritätsregeln, Schlüssel, ...
ISO 9075 (1992) - SQL2 SQL89 + Säuberung + voll relational
ISO 9075 (1999) - SQL:1999
ISO 9075 (2003) - SQL:2003
• SQL-Schnittstellen anderer Systeme (IDM (1984), INGRES (1985), SESAM (1989), UDS (1989))
VisualSQL als Zusammenführung von SQL, Quel und visuellen Sprachen
2. QUEL - Linie
logisch-orientierte Sprache
3. QBE -Linie
Query-by-example
nicht durchgesetzt
...
intelligente Oberflächen
4. Datenbankprogrammiersprachen
DBPL, ADABPL, Galileo, Persistente Programmiersprachen
Einbettung in PASCAL, Modula-2, QUEST, ...
5. VisualSQL - unsere Eigenentwicklung - steht auch jedem zur Verfügung
Verschiedene Benutzer
verschiedene Rollen
• Administrator (Datenbankadministrator)
Ressourcenverwaltung, Zutrittsrechte, internes Schema, tuning und monitoring, Sicherheit und Zuverlässigkeit
• Entwerfer (Unternehmensadminstrator)
konzeptionelles Schema, externe Schemata, Software-Entwicklung
• Systemanalytiker, Anwendungsprogrammierer
Anforderungserhebung, Software-Entwicklung
• Endbenutzer
• Zufälliger Benutzer
unterschiedliche Info, komplexe Auswertungen, schnell mal reinschauen, manager, Anfragen nicht vorhersehbar
• Naiver (oder parametrischer) Benutzer
Anwendungsprogramme, ‘canned transactions’, Sachbearbeiter, ...
• Voll ausgebildeter Benutzer
komplexe Anforderungen, gute Kenntnis von DBS und Schnittstellen, Techniker, wissenschaftler, Analytiker, ...
• DBMS und Tools Designer und Implementierer
• Operatoren und Wartungspersonal
Nutzen von DBMS
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
8
1. Kontrollierte Redundanz
2. Daten-sharing
3. Eingeschränkter Benutzerzugriff
concurrency, user view
security, authorization
4. Verschiedene Interfaces
5. Darstellung komplizierter Beziehungen der Daten
6. Integritätserzwingung
7. Robustheit, Wiederanlauf
Vorteile von DB
1. Standarderzwingung
2. Flexibilität
3. Verringerte Anwendungsentwicklung
4. Up-to-date-Information für alle Benutzer
5. Aufgabenverteilung
⇒
Einsatz von DBMS
• heterogene Benutzergruppen, gemeinsame Datenhaltung
• keine oder kontrollierte Redundanz gewünscht
• Benutzerverwaltung, Authorisierung
• Unterschiedliche Schnittstellen für unterschiedlich geschulte Benutzer
• komplexe Daten, komplexe Beziehungen zwischen den Daten
• Integritätsmechanismen sollen genutzt werden
• Backup, Fehlerbehandlung
• geringe Entwicklungszeit für sich ändernde Anwendungen
Ein DBMS sollte man nicht benutzen, wenn
• hoher overhead wegen
• hoher initialer Aufwand (HW + SW) bei geringem Nutzen
• Allgemeinheit der vorhandenen Funktionen
• security, safety, concurrency control, recovery, integrity
• Anwendung und DB sind eher einfach
• real-time-Forderungen, die dem overhead gegenüberstehen
• kein Mehrfachparallelzugriff auf Daten
backup, recovery
β
CAU Kiel, IfI, ISE
SS 2008
Datenbanken I 1. Einführung
1.1.2 Information
‘Information’ - vielseitig belegt
Ereignisse untereinander in Beziehung gesetzt unter Gesichtspunkt inwieweit Unsicherheit verringert wird
Absteckung des Möglichen
Wahrscheinlichkeitstheoretische Sicht von Informationen
Gegeben ist eine Zufallsvariable a = (a1 , ..., an ) p(ai ) Wahrscheinlichkeiten des Eintreffens von ai
a - Ausschnitt aus Menge der möglichen Ereignisse
Informationsgehalt des Wertes ai der Zufallsvariablen a :
Unsicherheit, die durch das tatsächliche Eintreffen von ai beseitigt wird
Nichtereignis versus Ereignis
Formalisierung durch Maß
• I(ai )
=
I(ai )
mit folgenden Anford.
f (p(ai ))
• f ist stetig in [0,1]
• f ist antiton (wahrscheinlichere Ereignisse enthalten weniger Information)
• Informationsgehalt ist additiv: f (p1 ∗ p2 ) = f (p1 ) + f (p2 )
⇒ dadurch ist I bis auf Konstante eindeutig festgelegt
I(ai )
=
−ld(p(ai ))
= ld(
1
)
p(ai )
falls p(ai ) ̸= 0
Informationsgehalt von einem einzelnen Wert ai
falls p(ai ) = 1 , dann keine Unsicherheit beseitigt
wird nun der gesamte Informationsgehalt der Zeichen von a betrachtet, d.h.
H(a) =
n
∑
p(ai )I(ai )
i=1
=
−
n
∑
p(ai ) ld(p(ai ))
i=1
ist der mittlere Informationsgehalt von a (Entropie)
durch weitere Ausnutzung der WMS-Grundlagen
angewandt auf Übertragung von Signalen
Kanal
Sender −→ Empfänger
bedingte Wahrscheinlichkeiten, unabhängige Zufallsgrößen, ...
z.B. Hvor (x|y) und Hnach (x|y) Unsicherheiten von x unter y vor und nach Ausführung
D(x, y) := Hvor (x|y) − Hnach (x|y) übertragene Information
Modelltheoretische Sicht von Informationen
Klasse K von Strukturen gegeben (M = (D, r1 , ..., rn ), ri τi -stellige Relationen)
“Ereignisse” werden durch FOPL-Formeln dargestellt
Aussage entweder wahr oder falsch in M (falls wahr, dann M Modell von α)
9
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
d.h. M odK (α) = {M ∈ K | M |= α} ⊆ K
bzw. M odK (Φ) = ∩M odK (α)
falls Φ bekannt, dann unsicher, welches Modell vorliegt
sicher, fall ||M odK (Φ)|| = 1 ;
höchst unsicher, falls M odK (Φ) = K
Beispiel: S := if x ≥ 8 then y := 1 else y := 0
nach Ausführung der Anweisung und bei Beobachtung von y verringert sich Unsicherheit über x
w(eakest) p(recondition) {S} Φ
x - Sender; y - Empfänger
damit verändert der Informationsfluß von x nach y unsere Kenntnis über die Modellklasse
mitunter ist auch Information redundant
1.1.3 Kommunikation
ebenso überladen
kommunikatives Handeln: Verständigung über ihre Handlungssituation
Sprache zur Mittlung
Kommunikation als Synthese dreier Selektionen:
• Information, ausgewählt aus einem Vorrat an Möglichen
• Mitteilung, von Sender gewählt für sein Verhalten
• Verstehen zur Veränderung der Möglichkeiten des Empfängers
daran anschließend: Ablehnung oder Annahme des Verstandenen
1.1.4 Wirklichkeit und Modell
Abstraktion als Mittel der Modellierung
verschiedene Arten
1. Datenabstraktion
• Klassifizierung / Instantiierung
• Aggregation / Dekomposition (Tupel-, Mengen-, Listen-, Clusteroperatoren)
• Hierarchien (Generalisierung / Spezialisierung)
2. Lokalisierungsabstraktion
• Unterscheidung zwischen Definition und Verwendung (Wiederverwendung, Wiederholung)
• naming
• binding
• scoping
3. Implementationsabstraktion
• Verkapselung (Modularisierung)
10
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
11
• Sichtbarkeit , hiding
• mapping
1.2 Architektur
Architektur mit einer Vielzahl von Sichten
Modellierungsarchitektur z.B. Dreiebenenarchitektur
dient dem Verständnis
Modularchitektur (auch als technische Architektur)
Typische Ausprägungen
Schichtenarchitektur je nach Anwendungsaktivität
oft auch eigenständige Architekturvariante Anwendungsarchitektur
entspricht Diagramm der Aktivitäten (wie z.B. Gehirnaktivität)
Architektur der Komponenten mit entsprechenden Schnittstellen
Architektur als glass box mit einer Abstraktion von Interna der Komponenten
Infrastruktur-Architektur mit den entsprechenden Begleitsystemen, Schnittstellen, Kollaboration
Integrationsarchitektur im Sinne der Gestalltung der Landschaft
Landschaftsarchitekt
DBS = DBn + DBMS
Dreiebenenarchitektur einer DB-Anwendung
Abstraktionsebene
Externe Ebene
Externes
Externes
Schema ... Schema
n
1
6
?
Konzeptionelle Ebene
6
?
Interne Ebene
zugeordnete Sprache
I
-
DatenDefinition
R
DatenManipulation
-
DatenAdministration
-
Abbildung 2: Dreiebenen-Modellierungsarchitektur bzw. -schichtung
darauf aufbauend:
5-Schichten-Modell eines DBMS
1. Ebene derBenutzersprache
Benutzerschnittstelle
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
12
DBMS
Kommunikations-Subsystem
InputOutputProzessor
Authorisierungkontrolle
Parser
Precompiler
Compiler
UpdateProzessor
QueryProzessor
Optimierer
Zugriffsplanerstellung
Code-Erzeugung
Integritätsprüfung
und
-erzwingung
Verteilungsmanager
Recovery
Manager
Synchronisation
paralleler
Zugriffe
Transaktionsverwaltung
Scheduler
Speicherverwaltung
Data-Manager
6
6
?
Support
Systeme
Graphische
etc.
Buffer-Manager
6
?
Logbuch
6
?
-
Data
Dictionary
Datenbank
Datenbank
Datenbank
Datenbank
...
Datenbank
?
Betriebssystem
Abbildung 3: Einfache Sicht (Schichtenarchitektur der Module) auf moderne DBMS
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
13
DBMS
InputOutputProzessor
Authorisierungkontrolle
UpdateProzessor
QueryProzessor
Code-Erzeugung
Speicherverwaltung
Data-Manager
6
6
?
Support
Systeme
Graphische
etc.
6
?
Logbuch
6
?
-
Data
Dictionary
Datenbank
?
Betriebssystem
Abbildung 4: DBMS einfachster Prägung (meist als Einstiegsdroge benutzt)
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
14
2. Ebene der Anfrageverarbeitung
3. Ebene der Zugriffstrukturen und Code-Erzeugung
4. Ebene der Synchronisation paralleler Zugriffe
5. Ebene der Speicherverwaltung
Geräteschnittstelle
Darauf aufbauend hat das System verschiedene Schnittstelle
• Mengen-Schnittstelle
select, insert, delete, modify
1
↔
2
views, Relationen
• Tupel-Schnittstelle
fetch, store, erase, update
2
↔
3
Cursor, Tupel
• Record-Schnittstelle
retrieve, add, change, dispose, change
3
↔
4
(Index-)Records
• Seiten-Schnittstelle
read, write
4
↔
5
Seiten, Segmente
Service des DBMS am Beispiel der Anfrageverarbeitung
1. Überprüfung der Syntax
2. Authorisierungs- und Existenztest
3. Generieren der notwendigen internen Operationen und Speichermechanismen
4. Generieren eines effizienten Programmes
5. Berechnen der Anfrage in der DB
6. Aufbereiten der Anfrageergebnisse (Operand)
7. Sicherstellen, daß Ergebnis während der Ausführung der Anfrage nicht geändert wird
darauf aufbauend verschiedene Sprachen für den Benutzer
Data Definition Language (DDL): Definition des konzeptionellen Schemas einer Datenbank
falls keine zusätzliche Storage Definition Language (SDL) vorhanden auch implizit (d.h. abgeleitet aus
DDL-Definitionen) oder explizit Defintion des internen Schemata
View Definition Language: Sichtendefinitionssprache zur Definition der externen Schemata
Data Manipulation Language (DML): Datenmanipulationssprache zur Modifikation der vorhandenen Datenbank
und zur Wiedergewinnung von Informationen
Retrieval für die Abfrage
Insert für das Einfügen von Daten
Delete für das Löschen von Daten
Update für die Modifikation der Daten
Konzepte der DML können auf unterschiedlicher programmiersprachlicher Basis existieren
nicht prozedural / prozedural
mengenorientiert / satzorientiert
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
15
data sublanguage / host language
Host Language des unterlegten Programmiersystemes
Moderne DBMS bieten eine deklarative DDL, eine deklarative DML und auch eine embedded host language
an. Alles andere kann aus diesen Sprachen generiert werden. Die DDL umfaßt auch direkte Möglichkeiten zur
Darstellung von Sichten.
Die Sprachen basieren auf entsprechenden Datenbankmodellen und auf Typensystemen, die den Programmiersprachen entlehnt sind.
Wir unterscheiden heute je nach Datenbankmodell
Relationale DBMS (auf der Grundlage des relationalen DB-Modelles),
Hierarchische DBMS (auf der Grundlage des hierarchischen DB-Modelles),
Netzwerk-DBMS (auf der Grundlage des Netzwerk-DB-Modelles) und neuerdings
Objektorientierte DBMS (auf der Grundlage von DB-Modellen mit umfangreicheren Typensystemen und einer
direkten Darstellung von Objekten mit ihren Identifikationsmechanismen und ihren Methoden),
XML-DBMS als Erweiterung von Ausspiel- und Austauschformaten hin zur objektentfalteten Speicherung von
Dingen der Realität mit Eigenbeschreibung,
Objektrelationale DBMS als Erweiterung relationaler und universeller Systeme,
sowie eine Reihe weiterer Arten von DBMS.
Klassifikation von DBMS
Datenmodell relational, Netzwerk, hierarchisch, oo
# Benutzer Single oder Mehrfachbenutzer
# Knoten Zentralisiert oder verteilt
• homogen
• heterogen
• förderiert
• interoperabel
Kosten
Zugriff Typen von Zugriffspfaden
General purpose Allgemeine Anwendungen oder Spezialanwendungen
Architektur Wie gut kann der Server seine Ressourcen im Mehrnutzerbetrieb ausschöpfen ?
Einprozeßarchitektur Module der Anwendung und für Zugriff in einem Prozeß zusammengefaßt.
+ : keine zusätzliche Kommunikation
- : selten im Unix-Umfeld
Mehrprozeßarchitektur Volle Parallelität der einzelnen Module.
+ : für viele Anwender und viele parallele Prozesse
Zugriffsprogramm nur einmal geladen; Ressourcenminimierung
+ : einfache Kontrolle der beteiligten DB-Prozesse
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
16
Single-Threaded-Single-Server-Arch. Jedem Anwendungsprogramm wird sein Prozeß zugeordnet,
der über die volle Funktionalität des Servers verfügt.
evt. auch Weiteruntergliederung des Servers in verschiedene spezialisierte Prozesse;
+ : Verarbeitung läßt sich parallelisieren; effizienter
Parallel-Server-Arch. Einzelne Funktionen sind in einem Cluster-System (Rechnerzusammenschluß
ohne Hauptspeicher und mit gemeinsamer Peripherie) zusammengefaßt
Multi-Threaded-Single-Server-Arch. Ein zentraler DB-Prozeß bedient alle Front-End-Prozesse.
+ : Ein Prozeß wird nur einmal geladen und verteilt die Arbeit auf parallel arbeitende spezialisierte Prozesse. (weniger Speicherbelastung, jedoch wird dann zentraler Prozeß evt. Engpaß)
Multi-Threaded-Multi-Server-Arch. Mehrere Backendprozesse versorgen die Frontendprozesse mit Daten. (evt. mit Priorisierung der einzelnen Klassen zur Effzienzverbesserung)
(+ : für viele hundert Benutzer noch gute Antwortzeiten)
Warum Optimierung ?
Weg vom mainframe zur Unix-Umgebung
Massives paralleles Processing als Ausweg
Bislang offen: wahre Bedeutung von Multiprozessoren und Multiprozessing
Ziel war: Anwendungsunabhängigkeit (nicht mehr Programmieren von Seiten, cache Größe, sharing
memory, Code-Längen)
wichtige Leistungsparameter
• Throughput: heute Tausende von Datenbank Requests / Sekunde (TDRPS)
frühere Meinung: nur für high-end Firmen; aber heute Ausweitung der DB Technologie auf BS
Routinen (Speichertabellen und hartkodierte Werte mit abgelegt) - damit neue Herausforderung
• Relationale Technologie und Implementation: bislang effizienter Zugriff für ein Attribut (einschließlich tuning)
• Skalierbarkeit und modulares Wachstum: große Zugriffsrate insbesondere in im Netz (mit logischen zentralen ‘Warenhaus’) erfordert spezielle Zugänge zur Leistungserhöhung, Zugriffszeitreduktion, Erhöhung der Flexibilität und für Erweiterbarkeit
Das Throughput-Problem
Verarbeitung nach Warteschlangen-Theorie
Service-Zeit: Beginn mit dispatch vom Programm, Ende mit Prozessorfreigabe
Damit einige Parameter:
• Ankunftsrate der Prozesse (wartende und ankommende)
• Service-Rate (Zeit pro Service und Prozeß)
• Serviceintensität (# simultane (concurrent) Operationen)
• Länge der Warteschlange (insbesondere der Prozesse gleicher Priorität)
• Scheduling delay
• Servicekapazität
2 Basisstrategien: Multiprogramming (mehrere Prozesse auf einem Prozessor) und
Multiprocessing (ein Programm auf mehreren Prozessoren)
nunmehr Multiprocessing statt Multiprogramming (eigentlich nur Pseudoparalleleität)
multitasking (oder synonym multithreading)
=⇒ Granularität muß reduziert werden
Pipelining,
shared Speicherressourcen,
nachrichtenbasierte Interprozeßkommunikation
Wissenschaftliche Anforderungen
• Referentielle Integrität, Integritätsbedingungen
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
17
• Komplexe Strukturen
• Sicherheit
• Komplexe Transaktionen
• Intelligentes Suchen (Index aufwärts, abwärts, ...)
Wichtigste Auswahlkriterien für Systeme
1. Multiuserfähigkeit
2. Datenbankinterne Datenbeschreibungs- und manipulationsprache
3. Sicherheit
4. Leistungsfähigkeit
Einige Leistungen der Datenbanktechnologie:
I. Technologie auf sicherer theoretischer Basis Mit der Entwicklung des relationalen Datenbankmodelles
Strukturierung von Datenbanken
Semantik von Datenbanken
Generische Operationen
Optimierungstheorie
Interoperabilität, Verteilung, middleware
Dynamik von Datenbankanwendungen
Benutzerunterstützung
Ausgereifte Datenbankmodelle
Darauf aufsetzend:
Theorie semantischer und objekt-orientierter Datenbanken
Ausgereifte Technologie Ausgereifte, standardisierte Programmiersprachen SQL92 (SQL2), Einbettungsprinzipien in Wirtssprachen
Ausgereifte Architektur von Systemen
Einbettung in Betriebssysteme, graphische Systeme, ...
Komponentenarchitektur, 3-Ebenen-Architektur
Verteilung (two tier, three tier, trader)
Benutzbarkeit für jedermann: Benutzungsoberflächen
Vielfältige Einsatzgebiete durch Erweiterungen der Technologie
Informationssysteme, Wissensbanken,
Information-Retrieval-Systeme, Suchmaschinen,
Dokumenten-Management-Systeme,
Entscheidungsunterstützungsysteme, MIS, EIS,
Data Warehouse, Internet-DB, Multimedia-DB, Dienste
Sichere Technologie Sicher für den Anwender
Verhalten der Datenbank gesichert
Daten gegen Schäden der HW/SW gesichert
Sicher gegen Fremdbenutzer
Einhaltung der Sicherheitsforderungen
Veränderungssicherheit
Nachvollziehbarkeit
Sicherheitsnormen auf B-, sogar A-Niveau
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
18
Sicher gegen den Anwender
und seine Fehler (Konsistenzerzwingung),
seine Nachlässigkeiten (Transaktionskonzept),
seine Neugier (Sichten)
Ausgereifte Pragmatik vorhanden: Methodiken und Vorgehensmodelle zum Entwurf und zur Implementation
von Datenbankanwendungen insbesondere für relationale Anwendungen
Beherrschung des Anwendungs-Engineering über die volle Lebenszeit der Anwendung mit Redesign, ReEngineerung
Beherrschung der Abstraktion
Somit: Regelmäßiges semiotisches Dreieck (Syntax, Semantik, Pragmatik)
1.3 Der grundlegende Zugang zur Modellierung
formale Sprache
erfinden
verwirklichen
benutzen
Paradigmen
\
Theorie
•
•
Abstraktion
•
Entwurf
•
Begriffsgerüste
Sinn von Informationssystemen
• (handelnde) Personen
• (strukturelle) Verpflichtungen innerhalb der Unternehmen
• die von einer jeweils ausgeführten (sozialen) Rolle abhängen
• ihr dazu notwendiges Wissen über das Unternehmen
• ihre (formalen) Handlungen
• die zugrundeliegenden Mitteilungen
Wissen der Anwendung
Drei Abstraktionsarten
statische Gesichtspunkte einer Anwendung
Struktur in Abhängigkeit des Typensystems
meist nur Datenabstraktion
• Seiendes (entity) : Ding, das wirklich exisitert
• Beziehung (relationship) : Zusammenhang
• Eigenschaft, Attribut : extensional (Dinge sind durch ihre Eigenschaften vollständig beschrieben
und identifizierbar)
Dinge stehen in Beziehung bzw. besitzen Eigenschaften
• Rolle evt. auch mehrmals
• Klassenbildung als Abstraktionsprinzip
Gesamtheit der Dinge modellieren
• Aussonderung : Separation / Spezialisierung
• Verallgemeinerung : Generalisierung von Gemeinsamkeiten
• Aggregation :
Semantik einschränkende Bedingungen für wirklichkeitsgetreue Nachbildung der Anwendung
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
19
• eindeutige Bestimmung aller Objekte : Schlüsselbedingung
• Hierarchie der Objekte
Aussonderungsbedingungen (specialization, IsA): Objekte sind auch Objekte in anderen Klassen
Verallgemeinerungsbedingungen (partition constraints, uniqueness constraints): Beziehungen
zwischen Objekten in einer Verallgemeinerungsklasse
• Bedingungen für Beziehungsklassen
• funktionaler Zusammenhang (viele-eins-Bedingung)
• jedes Komponentenobjekt einbezogen ? Seinsbedingung (existence constraint)
• Verweisbedingung auf Objekte der Komponentenklassen
• allgemeine Bedingungen - inhärente Bedingungen des Modells
• Gesamtheitsregel (universe of discourse) : Gesamtheit der möglichen Seienden ist durch
folgende Angaben ... vollständig beschrieben
• Verneinungsregel : Ist eine Beziehung weder direkt noch indirekt dargestellt, dann gilt sie
nicht.
Sichten und abgeleitete Begriffe : aus den Objekten der DB erschließbar
Lokalisierungs- und Implementationsabstraktion, mitunter auch Datenabstraktion
• Regeln zur Generierung des nicht direkt dargestellten Wissens
abgeleitete Begriffe und Typen (Vorfahren aus Eltern-Kind-Beziehung)
• Regeln zur Generierung des Ausschnittes, der für handelnde Personen sichtbar sein soll
oft als Implementationsabstraktion verstanden für externe Sichten (Sichtbarkeit, hiding)
Modularisierung (Verkapselung) oft nur nebenrangig
daneben aber auch als Lokalisierungsabstraktion (Unterscheidung zwischen Definition und Verwendung, naming, binding, scoping)
dynamische Gesichtpunkte der Anwendung
Operationen - Handlungen zur Darstellung des dynamischen Verhaltens
•
•
•
•
Änderungsoperationen - zur Veränderung im Wissen
Retrievaloperationen - zur Erschließung des Wissens ohne Veränderung der DB
Sprache zur Generierung von Programmen (siehe Theorie der Programmiersprachen)
Rollenveränderungen von dargestellten Objekten
Semantik zur Darstellung von zugelassenen und verbotenen Handlungsfolgen
Verpflichtungen innerhalb einer Rolle beschrieben durch
• welches Wissen zugänglich (Sichten (konsistent zu deren Definition)) und welche Handlungsfolgen ausgeführt werden müssen, evt. unter Berücksichtung von Ursachen (aktive Elemente)
• welches Wissen zugänglich (Sichten (konsistent zu deren Definition)) und welche Handlungsfolgen ausgeführt werden dürfen, evt. unter Berücksichtung von Voraussetzungen
Mitteilungen an einen oder den anderen Empfänger, die sie ihrerseits verstehen und verarbeiten sollten
zeit(un)abhängige Beschreibungen
• zeitunabhängig wird meist die Semantik vorausgesetzt, evt. auch Operationen, fast immer die Struktur
• zeitabhängig ist z.B. aufzählendes Wissen, insbesondere Inhalt der Datenbank
Daraus folgt: 3
1
2
Schichten bei der Darstellung einer Datenbank
1. Datenstrukturen (des zugrundegelegten DBMS oder allgemeine) (Datenschema)
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
20
2. Struktur, Operationen, Semantik, Sichten, ... (Datenbank-Schema)
3. Datenbankinstanz, die dem DB-Schema entspricht
4. Beispieldaten
Zur Erinnerung: Grundbegriffe der Logik, der Mengenlehre, der Theorie der Programmiersprachen
Einige wichtige Begriffe
• Syntax
• Alphabet
• Variable (Individuen-, Funktions-, Prädikaten-)
• induktive Definition von Formeln
• Interpretation
• Gültigkeit
• Modell
• Allgemeingültigkeit, Erfüllbarkeit
• Folgerung
• Ableitungsregeln
• die durch Ψ ausgesonderte Menge
Allgemeines Vorgehen
• Typen sind über ihre Typausdrücke definiert. Den (freien) Variablen werden wiederum Typen zugeordnet.
• Die Zuordnungsvorschrift für Typausdrücke kann sowohl hierarchisch als auch zyklisch sein. Wählt man eine zyklische Struktur, dann sind meist nur Topoi-Semantiken geeignet. Wählt man
hierarchische Strukturen, dann kann meist eine Mengensemantik noch garantiert werden.
• Typen haben eine assoziierte Semantik (statische).
• Typen haben Operationen zu ihrer Manipulation und Veränderung. Man kann diese Operationen generisch definieren, wenn die Typenstruktur hierarchisch aufgebaut ist. (siehe Vorlesung Theorie
der Programmiersprachen: Semantik von goto)
CAU Kiel, IfI, ISE
β
semantische Begriffe
Seiendes einfach
zusammenges.
Beziehung
Eigenschaft /
Attribut
SS 2008
Datenbanken I 1. Einführung
Grundbegiffe aus Logik/Mengenlehre
Syntax
Semantik
Konst.-zeichen
Elem. ∈ Wertemenge
Grundterm (mit Fkt.-z.)
atomare Grundaussage
Tupel einer Relation
Rolle (bei Bezieh.)
(2-stell.) atomare
Grundaussage /
Grundterm
Stelle eines Präd.-z.
Komp. einer Relation
Klassenbildung
Gesamtheit
Aussonderung
Menge v. Konst.-zeich.
Formel ϕ
Universum
dM,ϕ , 2M
Verallgemein.
∨
Vereinigung
Aggregation
∧, =
∩,×
(implikative) Aussage
mit =-Konklusion
Modellklasse
Bedingung
Schlüsselbeding.
Aussonderungsbed.
Verallgemein.-bed.
1-n-Beding.
Seinsbeding.
Verweisbeding.
Regel
Gesamtheitsregel
Verneinungsregel
Sichtregel
Handlung
Information
Tupel einer (2-stell.) Rel.
Funktionswert
21
Konzepte
imperativer Prog.-Spr.
Konstante
Strukturbaum eines Terms
Verbund (reecord),
Aufruf Boolesch-wert. Proz.
Verbund (record)
Aufruf einer attribut.wertigen Fkt.-proz.
Komp.-bezeichner (Verbund)
formaler Parameter (F.-proz.)
Deklaration
Typendeklarat.
Menge, Deklar.
(Bool.-w.) Funkt.-proz.
Deklarat. eines
varianten Verbundtyps
Deklarat. von Feldund Verbundtypen
Deklarat. einer Prozedur
mit =-Konklusion
Deklaration einer Prozedur
Ableit.-regel, Formeln
Ableit.-regel, Formeln
Formeln
logische Implikation
logische Implikation
Relation
Verkleinerung
der Modellklasse
Mitteilung
konjunktiv hinzugefügte Aussage
Aussage
Verstehen
Widerspruchsfreiheit
Erfüllbarkeit
Zustandänderung
(Wertzuweisung)
akt. Parameter beim
Prozeduraufruf
Ausführung einer Proz.
1.4 Database Systems at the First Level as Abstract State Machines
In this section we describe the semantics of a first level database using abstract state machines. The specification
is executable using AsmL 1.5, however, we used syntax from AsmL 2.0 at several places in order to make the
specification more readable. Currently we are converting the specification to AsmL 2.0 format.
1.4.1 The Database System as an Input-Output Engine
At the first level we describe databases from the outside point of view. The structure of the database is fixed, i.e.
we do not consider any create/delete table operations. The semantics of those is simple enough. The common data
types between inner and outer representation are view names, relation names and procedure names (for stored
procedures) and attribute names (including primary and secondary keys).
Therefore the interface specification is as follows:
type
type
type
type
type
ViewName
RelationName
ProcedureName
AttributeName
TypeName
=
=
=
=
=
String
String
String
String
String
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
22
For the representation of stored procedures it is essential to have complete freedom as to how the body of the
procedure is defined. This is achieved by allowing the complete power of ASM for the definition of the body. To
this end, only an interface is given, how the computations of a procedure should function, and the rest can be given
as an ASM procedure. See also ?? below for some concrete examples of stored procedures.
interface ProcedureStep
stepAction(params as Seq of Data) as Set of Request
stepResult(params as Seq of Data) as Data
structure StoredProcedure
transactional as Boolean
params as Seq of String // means sequence of types
contents as Seq of ProcedureStep
1.4.2 Structuring of the Database
First, we define the global types necessary for databases. These types are
• Database,
• Request, with the kinds
• Insert
• Delete
• Update
• Call (of a stored procedure)
• simple Select (provide a relation as result)
• general Select (just provide any result data)
and
• Answer, which can be a status message or a relation in case of a simple select request.
Moreover, we want to use variables at several places. Therefore we define the global database structure as follows:
structure Database
content as Map of RelationName to Relation
procs as Map of ProcedureName to StoredProcedure
constraints as Set of Constraint
structure Request
case Insert
relName as RelationName
ins as Tuple
case Delete
relName as RelationName
del as Tuple
case Update
relName as RelationName
upd as Tuple
case Call
pname as ProcedureName
pparams as Seq of Data
presult as Variable
case SimpleSelect
what as Seq of AttributeName
From as RelationName
Where as Constraint
result as Relation
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
23
case OutputSelect
result as Set of Tuple
structure Answer
case StatusAnswer
status as String
case RelationAnswer
rel as Relation
class Variable
name as String
value as Data
1.4.3 The Global States of the Database System
Now we define the global state variables: an input, an output, a set of variables and the database.
var
var
var
var
input as Set of Request = {}
output as Seq of Answer = []
variables as Set of Variable = {}
database as Database = Database({|->},{|->},{})
The action on the database depends on the input as follows (compare again with ??):
DBAction() =
choose inp in input do
input:= input difference { inp }
ProcessAction(inp)
ProcessAction(inp as Request) =
match inp with
Insert(n,t): DBChange(n,inp)
Delete(n,t): DBChange(n,inp)
Update(n,t): DBChange(n,inp)
Call(p,par,v):
let proc = database.procs(p)
if proc = undef then
output:= output + [StatusAnswer("no such procedure: " + p.name) as Answer]
else
DBCall(proc,par,v)
SimpleSelect(what,n,constr,result): //very simple version first
let res = database.content(n)
if res = undef then
output:= output + [StatusAnswer("relation " + n.name + " not defined") as Answer]
else
output:= output + [RelationAnswer(res) as Answer]
This behaviour is refined with the definition of DBChange for a simple change to the database and DBCall for
the call of a stored procedure. A single change to the database is described using the function DBStep
DBChange(n as RelationName, r as Request) =
let rel = database.content(n)
if rel=undef then
output:= output + [StatusAnswer("no such relation") as Answer]
else
let newDB = DBStep(database.content, n, r)
if check(newDB,database.constraints) then
database.content:= newDB
output:= output + [StatusAnswer("ok") as Answer]
else
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
24
output:= output + [StatusAnswer("constraint violation") as Answer]
DBStep(cont as Map of RelationName to Relation, n as RelationName, r as Request)
as Map of RelationName to Relation =
let rel = cont(n)
let newrel =
match r with
Insert(_,t): Relation(rel.attributes, rel.members union {t})
Delete(_,t): Relation(rel.attributes, rel.members difference {t})
Update(_,t):
Relation(rel.attributes,
(rel.members difference sameKeys(n, rel.members, t)) union {t})
cont override { n |-> newrel }
An update to a relation consists of two steps: first, all tuples which have the same key values are deleted, and
second, the new tuple is inserted. The tuples with the same key values are computed using the function sameKeys
below.
sameKeys(n as RelationName, r as Set of Tuple, t as Tuple) as Set of Tuple =
let attr = database.content(n).attributes
let keys = { (d as KeyConstraint).key | d in database.constraints
where d is KeyConstraint and
(d as KeyConstraint).rel = n }
bigUnion({ { tup | tup in r where getKey(attr,tup,k)=getKey(attr,t,k) } | k in keys })
getKey(n as Seq of AttributeName, t as Tuple, k as Set of AttributeName) as Seq of Data =
let len = if length(t.contents) < length(n) then length(t.contents) else length(n)
[t.contents(idx) | idx in [ 0 .. len ] where n(idx) in k]
DBCall(p as StoredProcedure, par as Seq of Data, res as Variable) =
let chk = ParamCheck(p,par)
if chk and p.transactional then
machine
var localDB as Map of RelationName to Relation = database.content
foreach pstep in p.contents do
foreach act in pstep.stepAction(par) do
match act with
Insert(n,t):
if localDB(n)=undef then
output:= output + [StatusAnswer("no such relation") as Answer]
else
localDB:= DBStep(localDB, n, act)
Delete(n,t):
if localDB(n)=undef then
output:= output + [StatusAnswer("no such relation") as Answer]
else
localDB:= DBStep(localDB, n, act)
Update(n,t):
if localDB(n)=undef then
output:= output + [StatusAnswer("no such relation") as Answer]
else
localDB:= DBStep(localDB, n, act)
_: output:= output + [StatusAnswer("invalid action in stored procedure")
as Answer]
step
if check(localDB,database.constraints) then
database.content:= localDB
output:= output + [StatusAnswer("stored procedure ok") as Answer]
else
output:= output + [StatusAnswer("constraint violation in stored procedure")
as Answer]
else
if chk then
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
25
foreach pstep in p.contents do
foreach act in pstep.stepAction(par) do
ProcessAction(act)
else
output:= output + [StatusAnswer("illegal parameters for stored procedure")
as Answer]
ParamCheck(p as StoredProcedure, par as Seq of Data) as Boolean =
let len = length(p.params)
let ldiff = length(par) - len
ldiff >= 0 and
(forall idx in [0 .. len-2] holds p.params(idx)=par(idx).typ)
and (p.params(len-1)="*" or
(p.params(len-1)=par(len-1).typ and length(par)=len))
This concludes the top level view of databases. We proceed with defining relations and tuples. Moreover, we
define a basic set of data types allowed within the database.
structure Relation
attributes as Seq of AttributeName
members as Set of Tuple
structure Tuple contents as Seq of Data
// no nested Tuples allowed
structure Data
typ as String
case PUndef
case PInteger val as Integer
case PString val as String
case PShort val as Short
case PByte val as Byte
case PChar val as Char
case PBoolean val as Boolean
case PDate val as Date
case PTimeStamp val as Float
// could add more here
converter
converter
converter
converter
converter
converter
converter
converter
(x
(x
(x
(x
(x
(x
(x
(x
as
as
as
as
as
as
as
as
Integer) as Data = PInteger("Integer",x)
String) as Data = PString("String",x)
Short) as Data = PShort("Short",x)
Byte) as Data = PByte("Byte",x)
Char) as Data = PChar("Char",x)
Boolean) as Data = PBoolean("Boolean",x)
Date) as Data = PDate("Date",x)
Float) as Data = PTimeStamp("TimeStamp",x)
We also have to define what constraints are and how they are checked. We distinguish between only two
kinds of constraints, namely key constraints and domain constraints. A key constraint says, that the values on the
corresponding attributes are unique within the relation. A domain constraint is used for type-checking the attribute
values.
structure Constraint
case KeyConstraint
rel as RelationName
key as Set of AttributeName
case DomainConstraint
rel as RelationName
attr as AttributeName
domain as TypeName
check(cont as Map of RelationName to Relation, constr as Set of Constraint)
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
26
as Boolean =
forall c in constr holds
forall r in dom(cont) holds
checkOne(c,r,cont(r))
checkOne(c as Constraint, n as RelationName, rel as Relation) as Boolean =
match c with
KeyConstraint(RelationName(r),k):
if r <> n.name then true
else
let relSize=size(rel.members)
let keyCount=size({ getKey(rel.attributes,t,k) | t in rel.members })
machine
if relSize <> keyCount then
write("Key constraint violation: "); prettyPrint(c)
step
relSize = keyCount
DomainConstraint(RelationName(r),attr,TypeName(d)):
if r <> n.name then true
else
forall t in rel.members holds
if length(rel.attributes) <> length(t.contents)
then
machine
write("Domain constraint violation: ")
write("wrong number of elements in "); prettyPrint(t)
step
false
else
machine
let elem=getKey(rel.attributes,t,{attr})
if head(elem).typ <> d then
write("Domain constraint violation: ")
write(" Attribute "); write(r); write("."); write(attr.name)
write("="); prettyPrint(head(elem));
write(" must be "); write(d)
write(" and not "); writeln(head(elem).typ)
step
head(elem).typ = d
1.4.4 An Application Example
The next part is devoted to an example taken in the context of internet information services. We (partially) define a
database of restaurants. We define first some simplifications for defining the database structure:
structure DataDesc
name as AttributeName
typ as TypeName // would be good to have MetaType here
mkDataDesc(attr as String, atype as String) as DataDesc =
DataDesc(AttributeName(attr), TypeName(atype))
mkRelation(name as String, key as Seq of DataDesc,
members as Seq of DataDesc) =
let relName = RelationName(name)
database.content:=
database.content override
{ relName |-> Relation([k.name | k in key] + [k.name | k in members],{}) }
database.constraints:=
database.constraints union
{ KeyConstraint(relName,{k.name | k in key}) as Constraint } union
{ DomainConstraint(relName, k.name, k.typ) as Constraint | k in key } union
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
27
{ DomainConstraint(relName, m.name, m.typ) as Constraint | m in members }
Now the macro mkRelation is used to create the database structure. Please note that we left this out of our
description of database semantics as it is a static structure. As you can see below, it might still cause some work for
a real database.
InitSampleDB() =
machine
variables:= { resVar }
step
mkRelation("Restaurant",
[ mkDataDesc("no","Integer") ],
[ mkDataDesc("name","String"),
mkDataDesc("street","String"),
mkDataDesc("place","String"),
mkDataDesc("po_code","String"),
mkDataDesc("telephone","String"),
mkDataDesc("fax","String"),
mkDataDesc("email","String"),
mkDataDesc("url","String")
])
step mkRelation("Person", < omitted > )
step
mkRelation("Contact",
[ mkDataDesc("restaurant_id","Integer") ],
[ mkDataDesc("person_id","Integer")
])
step mkRelation("Owner", < omitted > )
step mkRelation("Operation_mode", < omitted > )
step mkRelation("Mode", < omitted > )
step
mkRelation("Cuisine_kind",
[ mkDataDesc("cuisine_id","Integer") ],
[ mkDataDesc("description","String")
])
step
mkRelation("Cuisine",
[ mkDataDesc("restaurant_id","Integer"),
mkDataDesc("cuisine_id","Integer") ],
[])
step mkRelation("Offers", < omitted > )
step mkRelation("Multimedia", < omitted > )
step mkRelation("Offer_description", < omitted > )
step mkRelation("Special_offers", < omitted > )
step mkRelation("Business_hours", < omitted > )
step mkRelation("Description", < omitted > )
step mkRelation("Location", < omitted > )
step mkRelation("Service_offers", < omitted > )
step mkRelation("Service", < omitted > )
step
mkRelation("Cards",
[ mkDataDesc("card_id","Integer") ],
[ mkDataDesc("description","String")
])
step
mkRelation("Credit_cards",
[ mkDataDesc("restaurant_id","Integer"),
mkDataDesc("card_id","Integer") ],
[ ])
step
mkRelation("Ambiente_kind",
[ mkDataDesc("ambiente_id","Integer") ],
[ mkDataDesc("description","String")
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
28
])
step
mkRelation("Ambiente",
[ mkDataDesc("restaurant_id","Integer"),
mkDataDesc("ambiente_id","Integer") ],
[ ])
step mkRelation("Intern", < omitted > )
step
mkRelation("Acquisition_url",
[ ],
[ mkDataDesc("url_menu","String"),
mkDataDesc("url_map","String"),
mkDataDesc("url_pics","String"),
mkDataDesc("url_video","String")
])
The next step is to define two sample stored procedures for the database. These are fairly general procedures
for deleting the tuples in a relation and for inserting tuples into a relation thereby creating a unique index for each
of the entries. Both kinds of procedures are used later on to modify the database.
class SP_DeleteStep implements ProcedureStep
stepAction(params as Seq of Data) as Set of Request =
let n as RelationName = RelationName((params(0) as PString).val)
{ Delete(n,t) as Request | t in database.content(n).members
where t.contents(1) = params(1) }
stepResult(params as Seq of Data) as Data = 0 as Data
class SP_FillStep implements ProcedureStep
stepAction(params as Seq of Data) as Set of Request =
let n as RelationName = RelationName((params(0) as PString).val)
{ Insert(n,Tuple([idx as Data, params(idx)])) as Request |
idx in [1..length(params)-1] }
stepResult(params as Seq of Data) as Data = length(params) as Data
InitProcedures() =
database.procs(ProcedureName("sp_delete")):=
StoredProcedure(true,
["String", "String"], // these are the parameter types
[ new SP_DeleteStep() as ProcedureStep ])
database.procs(ProcedureName("sp_fill")):=
StoredProcedure(true,
["String", "*"], // these are the parameter types, ’*’ means any type
[ new SP_FillStep() as ProcedureStep ])
Now we define some sample requests. We obtain the following AsmL specification:
InitInsertRequests() =
input:= {
Call(ProcedureName("sp_fill"),
["Service_offers" as Data, < omitted > ], resVar) as Request,
Call(ProcedureName("sp_fill"),
["Operation_mode" as Data, < omitted > ], resVar) as Request,
Call(ProcedureName("sp_fill"),
["Cuisine_kind" as Data,
"american", "arabian", "argentinean", "australian", "balkan", "bavarian",
< many more omitted >
], resVar) as Request,
Call(ProcedureName("sp_fill"),
["Ambiente_kind" as Data,
"asian", "historic building", "dignified", "bucolic", "luxurious",
"modern", "nostalgic", "oriental", "rustic"
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
29
], resVar) as Request,
Call(ProcedureName("sp_fill"),
["Cards" as Data,
"American Express", "DinersCub", "Euro Card", "Euro-cheque", "EC-card",
"Visage", "Mastercard", "Tele-Cash", "Restaurant-cheque"
], resVar) as Request,
Insert(RelationName("Acquisition_url"), Tuple([ "1" as Data, "2", "3", "4" ])) as Request
}
InitUpdateRequests() =
input:= {
Update(RelationName("Cards"), Tuple([ 2 as Data, "Diners Club" ])) as Request,
Update(RelationName("Cards"), Tuple([ 6 as Data, "Visa" ])) as Request,
// it is not clear whether the following line should produce a key constraint violation
Insert(RelationName("Cards"), Tuple([ 7 as Data, "Mastercard" ])) as Request,
Insert(RelationName("Acquisition_url"), Tuple([ "a" as Data, "b", "c", "d" ])) as Request,
Update(RelationName("Acquisition_url"), Tuple(
[ "http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/speisekarten/" as Data,
"http://delaware.informatik.tu-cottbus.de/Stadtkarte/image.pl?place=",
"http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/bilder/",
"http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/video/" ])) as Request
}
InitCallRequests() =
input:= {
Call(ProcedureName("sp_delete"), ["Ambiente" as Data,"dummy"], resVar) as Request,
Call(ProcedureName("sp_delete"), ["Ambiente_kind" as Data,"modern"], resVar) as Request
}
InitRetrieveRequests() =
input:=
{ SimpleSelect([],RelationName("Cards"),undef,undef) as Request,
SimpleSelect([],RelationName("xxx"),undef,undef) as Request
}
Now we put everything together to get an executable AsmL specification. The idea is always to initialize a
sequence of requests and execute them afterwards using until fixpoint do DBAction(). Please note,
that the requests are executed non deterministically and not in the order they are given.
run() =
machine
InitSampleDB()
InitProcedures()
InitInsertRequests()
step
until fixpoint do DBAction()
step
writeln("The result is: ")
prettyPrint(output)
prettyPrint([StatusAnswer("ready") as Answer])
output:= []
InitUpdateRequests()
step
until fixpoint do DBAction()
step
prettyPrint(output)
prettyPrint([StatusAnswer("ready") as Answer])
output:= []
InitCallRequests()
step
until fixpoint do DBAction()
step
prettyPrint(output)
prettyPrint([StatusAnswer("ready") as Answer])
output:= []
InitRetrieveRequests()
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
step
until fixpoint do DBAction()
step
prettyPrint(output)
prettyPrint([StatusAnswer("ready") as Answer])
output:= []
writeln(); writeln("The database is: ")
prettyPrint(database)
1.4.5 Executing the Abstract Database Machine
We can now test the database engine by running the specification. The result is as follows:
The result is:
Status: ok
Status: stored procedure ok
Status: stored procedure ok
Status: stored procedure ok
Status: stored procedure ok
Status: stored procedure ok
Status: ready
Key constraint violation: Key(Acquisition_url)= {}
Status: ok
Status: ok
Status: ok
Status: constraint violation
Status: ok
Status: ready
Status: stored procedure ok
Status: stored procedure ok
Status: ready
Relation:
card_id
description
#3
"Euro Card"
#4
"Euro-Cheque"
#5
"EC-Card"
#6
"Visa"
#7
"Mastercard"
#8
"Tele-Cash"
#9
"Restaurant-Cheque"
#1
"American Express"
#2
"Diners Club"
Status: relation xxx not defined
Status: ready
After executing all the requests, the database has the values given below:
The database is:
Relation Description: <empty>
Relation Mode: <empty>
Relation Operation_mode:
< omitted >
Relation Acquisition_url:
url_menu url_map url_pics
url_video
"http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/speisekarten/"
"http://delaware.informatik.tu-cottbus.de/Stadtkarte/image.pl?place="
"http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/bilder/"
"http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/video/"
Relation Restaurant: <empty>
Relation Owner: <empty>
Relation Intern: <empty>
Relation Cards:
card_id
description
#3
"Euro Card"
30
CAU Kiel, IfI, ISE
β
SS 2008
Datenbanken I 1. Einführung
#4
"Euro-Cheque"
#5
"EC-Card"
#6
"Visa"
#7
"Mastercard"
#8
"Tele-Cash"
#9
"Restaurant-Cheque"
#1
"American Express"
#2
"Diners Club"
Relation Credit_cards: <empty>
Relation Cuisine: <empty>
Relation Cuisine_kind:
cuisine_id
description
#1
"american"
#2
"arabian"
#3
"argentinean"
#4
"australian"
#5
"balkan"
#6
"bavarian"
< some more omitted >
Relation Location: <empty>
Relation Multimedia: <empty>
Relation Business_hours: <empty>
Relation Person: <empty>
Relation Service_offers:
< omitted >
Relation Service: <empty>
Relation Offers: <empty>
Relation Offer_description: <empty>
Relation Ambiente: <empty>
Relation Ambiente_kind:
ambiente_id
description
#8
"oriental"
#9
"rustic"
#1
"asian"
#2
"historic building"
#3
"dignified"
#4
"bucolic"
#5
"luxurious"
#7
"nostalgic"
Relation Special_offers: <empty>
Relation Contact: <empty>
< now showing the constraints that are in the database >
Domain(Acquisition_url.url_map)= String
Domain(Acquisition_url.url_pics)= String
Domain(Acquisition_url.url_speisekarte)= String
Domain(Acquisition_url.url_video)= String
< many more domain constraints omitted >
Key(Acquisition_url)= {}
Key(Cards)= {card_id}
< more key constraints omitted >
Press any key to continue
31