Datenbanken

Warum Datenbank-Vorlesung?
■
Datenbanksysteme als Basis moderner
Softwaresysteme:
◆ Web-basierte Systeme (eBay, Amazon, . . . )
◆ ERP-Systeme (SAP R/3), CRM-Systeme,
Finanzsysteme
◆ administrative Anwendungen
◆ wiss. Anwendungen (Sloan Sky Survey, NASA Earth
Observation System, Human Genom Project, . . . )
■
Querbezüge zu anderen Bereichen der Informatik:
◆ Modellierung, Datenstrukturen, Theorie,
Betriebssysteme/Verteilte Systeme, Sicherheit,
Multimedia, . . .
Vorlesung
Datenbanken
Martin-Luther-Universität Halle, WS 02/03
Kai-Uwe Sattler
[email protected]
VL Datenbanken I – 0–1
Warum Datenbank-Vorlesung? /2
VL Datenbanken I – 0–1
Überblick
■
große Herausforderungen:
◆ Verwaltung von Daten im TB-Bereich, viele Nutzer
◆ weltweit verteilte Datenbestände
◆ Multimedia-Inhalte
◆ Hochverfügbarkeit, Sicherheit
■
DB-Kenntnisse unverzichtbar für *Informatik-Berufe:
◆ Administration, Planung/Entwurf, Entwicklung,
Nutzung
VL Datenbanken I – 0–2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Grundlegende Konzepte und Architekturen
Datenbankmodelle für den Entwurf
Datenbankmodelle für die Realisierung
Datenbankentwurf und Datendefinition
Anfrage- und Änderungsoperationen
Relationale Datenbanksprachen
Datenbank-Anwendungsprogrammierung
Integrität und Trigger
Sichten, Datenschutz
Dateiorganisation und Indexstrukturen
Weitere DB-Konzepte
VL Datenbanken I – 0–3
1. Grundlegende Konzepte
Literatur
■
Heuer, A., Saake, G.: Datenbanken — Konzepte und
Sprachen. 2. Aufl., mitp-Verlag, Bonn, Januar 2000
■
Vossen, G.; Datenbankmodelle, Datenbanksprachen
und Datenbankmanagement-Systeme. Oldenbourg,
München, 2000
■
Heuer, A., Saake, G., Sattler, K.; Datenbanken kompakt
mitp-Verlag, Bonn, 2001
■
Elmasri, R.; Navathe, S.B.; Fundamentals of Database
Systems. Addison-Wesley, 1999
■
Date, C.J.; An Introduction to Database Systems
Addison-Wesley, Reading, 1999
■
Motivation und Historie
■
Komponenten und Funktionen
■
Einsatzgebiete und Grenzen
■
Entwicklungslinien
■
Schema-Architektur
■
System-Architekturen
VL Datenbanken I – 0–4
Ohne Datenbanken: Datenredundanz
■
■
Basis- oder Anwendungssoftware verwaltet ihre eigenen
Daten in ihren eigenen (Datei-)Formaten
◆ Textverarbeitung: Texte, Artikel und Adressen
◆ Buchhaltung: Artikel, Adressen
◆ Lagerverwaltung: Artikel, Aufträge
◆ Auftragsverwaltung: Aufträge, Artikel, Adressen
◆ CAD-System: Artikel, Technische Bausteine
VL Datenbanken I – 1–1
Ohne Datenbanken: Datenredundanz II
■
Andere Software-Systeme können große Mengen von
Daten nicht effizient verarbeiten
■
Mehrere Benutzer oder Anwendungen können nicht
parallel auf den gleichen Daten arbeiten, ohne sich zu
stören
■
Anwendungsprogrammierer / Benutzer können
Anwendungen nicht programmieren / benutzen, ohne
◆ interne Darstellung der Daten
◆ Speichermedien oder Rechner
zu kennen (Datenunabhängigkeit nicht gewährleistet)
■
Datenschutz und Datensicherheit sind nicht
gewährleistet
Daten sind redundant: mehrfach gespeichert; Probleme:
Verschwendung von Speicherplatz, „Vergessen“ von
Änderungen; keine zentrale, „genormte“ Datenhaltung
VL Datenbanken I – 1–2
VL Datenbanken I – 1–3
Mit Datenbanken: Datenintegration
■
Historie
Die gesamte Basis- und Anwendungssoftware arbeitet
auf denselben Daten, z.B. Adressen und Artikel werden
nur einmal gespeichert
◆ Datenbanksysteme können große Datenmengen
effizient verwalten (Anfragesprachen, Optimierung,
Interne Ebene)
◆ Benutzer können parallel auf Datenbanken arbeiten
(Transaktionskonzept)
◆ Datenunabhängigkeit durch 3-Ebenen-Konzept
◆ Datenschutz (kein unbefugter Zugriff) und
Datensicherheit (kein ungewollter Datenverlust)
werden vom System gewährleistet
■
Anfang 60er Jahre: elementare Dateien,
anwendungsspezifische Datenorganisation
(geräteabhängig, redundant, inkonsistent)
■
Ende 60er Jahre: Dateiverwaltungssysteme (SAM,
ISAM) mit Dienstprogrammen (Sortieren)
(gerateunabhängig, aber redundant und inkonsistent)
■
70er Jahre: Datenbanksysteme (Geräte- und
Datenunabhängigkeit, redundanzfrei, konsistent)
VL Datenbanken I – 1–4
VL Datenbanken I – 1–5
Prinzipien
Historie von RDBMS
■
1970: Ted Codd (IBM) → Relationenmodell als
konzeptionelle Grundlage relationaler DBS
■
1974: System R (IBM) → erster Prototyp eines RDBMS
◆ zwei Module: RDS, RSS; ca. 80.000 LOC (PL/1,
PL/S, Assembler), ca. 1,2 MB Codegröße
◆ Anfragesprache SEQUEL
◆ erste Installation 1977
■
1975: University of California at Berkeley (UCB) →
Ingres
◆ Anfragesprache QUEL
◆ Vorgänger von Postgres, Sybase, . . .
■
1979: Oracle Version 2
■
DBMS: Datenbank-Management-System
■
DBS: Datenbanksystem (DBMS + Datenbank)
Anwendung 1
...
Anwendung n
DBMS
Datenbank
VL Datenbanken I – 1–6
VL Datenbanken I – 1–7
Prinzipien II
■
Prinzipien III
Grundmerkmale
◆ verwalten persistente (langfristig zu haltende) Daten
◆ verwalten große Datenmengen effizient
◆ Datenbankmodell, mit dessen Konzepten alle Daten
einheitlich beschrieben werden (Integration)
◆ Operationen und Sprachen (DDL, IQL, DML, . . . )
deskriptiv, getrennt von einer Programmiersprache
◆ Transaktionskonzept, Concurrency Control: logisch
zusammenhängende Operationen atomar (unteilbar),
Auswirkungen langlebig, können parallel
durchgeführt werden
◆ Datenschutz, Datenintegrität (Konsistenz),
Datensicherheit
■
Grundprinzip moderner Datenbanksysteme
◆ 3-Ebenen-Architektur (physische
Datenunabhängigkeit, logische Datenunabhängigkeit)
◆ Trennung zwischen Schema (etwa Tabellenstruktur)
und Instanz (etwa Tabelleninhalt)
angelehnt an 9 Codd’sche Regeln:
VL Datenbanken I – 1–8
Die neun Codd’schen Regeln
VL Datenbanken I – 1–9
Konzeptuelle Ebene: Relationenmodell I
1. Integration: einheitliche, nichtredundante
Datenverwaltung
2. Operationen: Speichern, Suchen, Ändern
3. Katalog: Zugriffe auf Datenbankbeschreibungen im Data
Dictionary
4. Benutzersichten
5. Integritätssicherung: Korrektheit des Datenbankinhalts
6. Datenschutz: Ausschluß unauthorisierter Zugriffe
7. Transaktionen: mehrere DB-Operationen als
Funktionseinheit
8. Synchronisation: parallele Transaktionen koordinieren
9. Datensicherung: Wiederherstellung von Daten nach
Systemfehlern
VL Datenbanken I – 1–10
Konzeptuell ist die Datenbank eine Menge von Tabellen
AUSLEIH
INV.NR
NAME
4711
Meyer
1201
Schulz
0007
Müller
4712
BUCH
Meyer
INV.NR
TITEL
ISBN
0007
Dr. No
3-125
AUTOR
James Bond
1201
Objektbanken
3-111
Heuer
4711
Datenbanken
3-765
Vossen
4712
Datenbanken
3-891
Ullman
4717
PASCAL
3-999
Wirth
Tabellen = „Relationen“
VL Datenbanken I – 1–11
Konzeptuelle Ebene: Relationenmodell II
■
Fett geschriebene Zeilen: Relationenschema
■
Weitere Einträge in der Tabelle: Relation
■
Eine Zeile der Tabelle: Tupel
■
Eine Spaltenüberschrift: Attribut
Relationenname
R
A1
...
...
Integritätsbedingungen
■
Relationenschema + lokale Integritätsbedingungen
◆ INVENTARNR ist Schlüssel für BUCH
◆ d.h. INVENTARNR darf nicht doppelt vergeben
werden
■
Datenbankschema ist Menge von Relationenschemata
+ globale Integritätsbedingungen
◆ INVENTARNR in AUSLEIH ist Fremdschlüssel
bezüglich BUCH
◆ d.h.: INVENTARNR taucht in einem anderen
Relationenschema als Schlüssel auf
Attribute
An
} Relationenschema
...
...
Relation
Tupel
VL Datenbanken I – 1–12
Anfrageoperationen I
■
■
Anfrageoperationen II
SELEKTION: Zeilen (Tupel) auswählen
σNAME=’Meyer’ (AUSLEIH)
VL Datenbanken I – 1–13
■
INVENTARNR
NAME
4711
Meyer
4712
Meyer
πINVENTARNR,TITEL (BUCH) 1 σNAME=’Meyer’ (AUSLEIH)
PROJEKTION: Spalten (Attribute) auswählen
INVENTARNR
πINVENTARNR, TITEL (BUCH)
VERBUND (JOIN): Tabellen verknüpfen über
gleichbenannte Spalten und gleiche Werte
ergibt:
TITEL
INVENTARNR
0007
Dr. No
1201
Objektbanken
4711
Datenbanken
4712
Datenbanken
4717
PASCAL
Achtung: doppelte Tupel werden entfernt!
VL Datenbanken I – 1–14
TITEL
NAME
4711
Datenbanken
Meyer
4712
Datenbanken
Meyer
■
Weitere Operationen: Vereinigung, Differenz,
Durchschnitt, Umbenennung
■
Alle Operationen beliebig kombinierbar („Algebra“)
VL Datenbanken I – 1–15
Sprachen und Sichten I
■
Sprachen und Sichten II
Anfragesprache
■
Änderungs-Komponente: interaktive Möglichkeit
◆ Tupel einzugeben
◆ Tupel zu löschen
◆ Tupel zu ändern
; Lokale und globale Integritätsbedingungen werden
geprüft!
■
Definition von Benutzersichten
◆ Häufig vorkommende Datenbankabfragen können
unter einem „Sichtnamen“ als „virtuelle“ Tabelle
gespeichert werden.
Interaktive Möglichkeit, Datenbankabfragen zu
formulieren und zu starten
◆ Relationenalgebra + Funktionen (SUM, MAX, MIN,
COUNT, . . . ) + arithmetische Operationen
◆ eventuell graphisch „verpackt“
◆
■
SQL als Standard
select BUCH.INVENTARNR, TITEL, NAME
from BUCH, AUSLEIH
where NAME = ’Meyer’ and
BUCH.INVENTARNR = AUSLEIH.INVENTARNR
VL Datenbanken I – 1–16
Optimierer I
VL Datenbanken I – 1–17
Optimierer: Algebraische Optimierung
Problem:
Finde einen Relationenalgebra-Ausdruck, der
äquivalent ist („das gleiche Ergebnis liefert“) wie
der gegebene, aber effizienter auszuwerten ist
VL Datenbanken I – 1–18
■
allgemeine Regel:
1. σA=Konst ( REL1 1 REL2 ) und A aus REL1
2. σA=Konst (REL1) 1 REL2
sind äquivalent
■
allgemeine Strategie: Selektionen möglichst früh, da sie
Tupelanzahlen in Relationen verkleinern
■
Beispiel: REL1 100 Tupel, REL2 50 Tupel
intern: Tupel sequentiell abgelegt
1. 5000 (1) + 5000 (σ ) = 10000 Operationen
2. 100 (σ ) + 10 · 50 (1) = 600 Operationen
falls 10 Tupel in REL1 die Bedingung A = Konst
erfüllen
VL Datenbanken I – 1–19
Notwendigkeit für Zugriffspfade
Interne Strukturen
■
Relation kann intern als Datei organisiert werden:
Heap, ungeordnet
Sequentiell, geordnet nach bestimmter Spalte
◆ Hash-organisiert, gestreut gespeichert,
Adreßberechnung durch Formel
◆ Baumartig, Tupel in einem Suchbaum angeordnet
■
Beispiel: Tabelle mit 10 GB Daten,
Festplattentransferrate ca. 10 MB/s
■
Operation: Suchen eines Tupels (Selektion)
■
Implementierung: sequentielles Durchsuchen
■
Aufwand: 10.240/10 = 1.024 sec. ≈ 17 min.
◆
◆
■
Zusätzliche Zugriffspfade
◆ statischer Index, einstufig oder mehrstufig
◆ dynamischer Index
beliebiger Wechsel zwischen Dateiorganisationen/
Zugriffspfaden möglich
je schneller die Abfrage, desto langsamer der Update
VL Datenbanken I – 1–20
Zugriffe auf Plattenseiten
■
■
VL Datenbanken I – 1–21
Einsatzgebiete und Grenzen
Jede Operation (σ , π , 1, . . . ) wird in optimale Folge von
Seitenzugriffen umgesetzt
◆ Ausnutzung von Zugriffspfaden und
Dateiorganisation, wenn es dem System sinnvoll
erscheint
◆ Bestimmung der Reihenfolge der Zugriffe nach
vorliegenden Zugriffspfaden
Beispiel: σNAME=’Meyer’ (σINVENTARNUMMER>4500 (AUSLEIH))
◆ Annahme: auf NAME ist ein Zugriffspfad definiert, auf
INVENTARNUMMER nicht
◆ System ändert die Reihenfolge der Selektionen!!
VL Datenbanken I – 1–22
■
Klassische Einsatzgebiete:
viele Objekte (15000 Bücher, 300 Benutzer, 100
Ausleihvorgänge pro Woche, . . . )
◆ wenige Objekttypen (BUCH, BENUTZER,
AUSLEIHUNG)
◆ etwa Buchhaltungssysteme,
Auftragserfassungssysteme, Bibliothekssysteme, . . .
◆
■
Aktuelle Anwendungen:
◆ E-Commerce, entscheidungsunterstützende Systeme
(Data Warehouses, OLAP), NASA’s Earth
Observation System (Petabyte-Datenbanken), Data
Mining
VL Datenbanken I – 1–23
Einsatzgebiete und Grenzen II
Datenbankgrößen
Normalerweise sind herkömmliche Datenbanksysteme
überfordert mit:
Sloan Digital Sky Survey
40 TB
Himmelsdaten (Bilder und Objektinformationen); bis 2004
WalMart Data Warehouse
24 TB
Produktinfos (Verkäufe etc.) von 2.900 Märkten;
50.000 Anfragen/Woche
US Library of Congress
10-20 TB
nicht digitalisiert
Indexierbares WWW (1999)
6 TB
ca. 800 Mill. Dokumente
Microsofts TerraServer
3,5 TB
unkomprimierte Bilder/Karten (komprimiert: ca. 1 TB);
174 Mill. Tupel
■
CAD- oder andere technische Anwendungen (viele
Objekte, viele Objekttypen, sehr strukturierte Objekte)
◆ ABER: Objektorientierte Datenbanksysteme
■
Expertensysteme (wenige Objekte, viele Objekttypen,
kompliziertere Operationen)
◆ ABER: Deduktive Datenbanksysteme
VL Datenbanken I – 1–24
Datenbankgrößen (II)
VL Datenbanken I – 1–25
Entwicklungslinien: 60er Jahre
SAP R/3-Installation der Deutschen Telekom AG (1998)
■
Financial Accounting: Rechnungen,
Zahlungsaufforderungen, Lastschriften, Mahnungen etc.
■
15 SAP R/3-Systeme; jedes
◆ verarbeitet 200.000 Rechnungen, 12.000
Mahnungen, 10.000 Änderungen von Kundendaten
pro Tag
◆ bis zu jeweils 1000 Nutzer gleichzeitig
■
über 13.000 Datenbanktabellen
■
Hardware: 51 Unix Enterprise Servern, 34
EMC-Speichersysteme (30 TB), 68 Magnetbandsysteme
für Backup (Backup in 2h)
VL Datenbanken I – 1–26
■
DBS basierend auf hierarchischem Modell,
Netzwerkmodell
◆ Zeigerstrukturen zwischen Daten
◆ Schwache Trennung interne / konzeptuelle Ebene
◆ Navigierende DML
◆ Trennung DML / Programmiersprache
VL Datenbanken I – 1–27
Entwicklungslinien: 70er und 80er Jahre
■
Relationale Datenbanksysteme
◆ Daten in Tabellenstrukturen
◆ 3-Ebenen-Konzept
◆ Deklarative DML
◆ Trennung DML / Programmiersprache
Entwicklungslinien: (80er und) 90er Jahre
■
Wissensbanksysteme
◆ Daten in Tabellenstrukturen
◆ Stark deklarative DML, integrierte
Datenbankprogrammiersprache
■
Objektorientierte Datenbanksysteme
◆ Daten in komplexeren Objektstrukturen (Trennung
Objekt und seine Daten)
◆ Deklarative oder navigierende DML
◆ Oft integrierte Datenbankprogrammiersprache
◆ Oft keine vollständige Ebenentrennung
VL Datenbanken I – 1–28
Entwicklungslinien: heute
■
VL Datenbanken I – 1–29
Schema-Architektur I
Unterstützung für spezielle Anwendungen
◆ Multimediadatenbanken: Verwaltung multimedialer
Objekte (Bilder, Audio, Video)
◆ XML-Datenbanken: Verwaltung semistrukturierter
Daten (XML-Dokumente)
◆ Verteilte Datenbanken: Verteilung von Daten auf
verschiedene Rechnerknoten
◆ Föderierte Datenbanken, Multidatenbanken,
Mediatoren: Integration von Daten aus heterogenen
Quellen (Datenbanken, Dateien, Web-Quellen)
◆ Mobile Datenbanken: Datenverwaltung auf
Kleinstgeräten (PDA, Handy, . . . )
VL Datenbanken I – 1–30
Zusammenhang zwischen
■
Konzeptuellen Schema (Ergebnis der Datendefinition)
■
Internen Schema (Festlegung der Dateiorganisationen
und Zugriffspfade)
■
Externen Schema (Ergebnis der Sichtdefinition)
■
Anwendungsprogrammen (Ergebnis der
Anwendungsprogrammierung)
VL Datenbanken I – 1–31
Schema-Architektur II
■
externes Schema 1
Datenbankschema besteht aus
◆ internem, konzeptuellen, externen Schema und den
Anwendungsprogrammen
◆ im konzeptuellen Schema etwa:
– Strukturbeschreibungen
– Integritätsbedingungen
– Autorisierungsregeln (pro Benutzer für erlaubte
DB-Zugriffe)
...
externes Schema N
konzeptuelles Schema
internes Schema
VL Datenbanken I – 1–32
Datenunabhängigkeit I
VL Datenbanken I – 1–33
Datenunabhängigkeit II
■
Stabilität der Benutzerschnittstelle gegen Änderungen
■
physisch: Änderungen der Dateiorganisationen und
Zugriffspfade haben keinen Einfluß auf das konzeptuelle
Schema
■
Datendarstellung
Trennung Schema — Instanz
◆ Schema (Metadaten, Datenbeschreibungen)
◆ Instanz (Anwenderdaten, Datenbankzustand oder
-ausprägung)
Anfragebearbeitung
■
Schema-Architektur III
■
eventuell externe Schemata betroffen (Ändern von
Attributen)
◆ eventuell Anwendungsprogramme betroffen
(Rekompilieren der Anwendungsprogramme,
eventuell Änderungen nötig)
◆
logisch: Änderungen am konzeptuellen und gewissen
externen Schemata haben keine Auswirkungen auf
andere externe Schemata und Anwendungsprogramme
■
VL Datenbanken I – 1–34
mögliche Auswirkungen von Änderungen am
konzeptuellen Schema:
nötige Änderungen werden jedoch vom DBMS erkannt
und überwacht
VL Datenbanken I – 1–35
Ebenen-Architektur am Beispiel I
■
Ebenen-Architektur am Beispiel II
Konzeptuelle Sicht: relationale Darstellung
AUTOR
BUCH
Name
Nr
BuchID
Meier
Schulze
Ibsen
...
1
2
1
...
4242
3745
3745
....
BuchID
Titel
Jahr
ISBN
4242
3745
...
Datenbasen I
UNIX X
...
1993
1998
...
3-452-12
1-424-11
...
■
Externe Sicht: Daten in einer flachen Relation
TITEL
BUCH.BuchID
Name
Nr
Titel
Jahr
ISBN
Meier
Schulze
Ibsen
...
1
2
1
...
Datenbasen I
UNIX X
UNIX X
...
1993
1998
1998
...
1-424-11
3-452-12
3-452-12
...
VL Datenbanken I – 1–36
Ebenen-Architektur am Beispiel III
■
Ebenen-Architektur am Beispiel IV
Externe Sicht: Daten in einer hierarchisch aufgebauten
Relation
TITEL
Autoren
{ Autor }
Titel
Jahr
VL Datenbanken I – 1–37
■
Interne Darstellung
Baumzugriff Autorname
Ibsen
ISBN
Meier
Datenbasen I
1993
1-424-11
Ibsen
Schulze
...
UNIX X
1998
3-452-12
...
...
...
Anderson
Heuer
Meier
Schulze
Hash-Tabelle Buchtitel
Ibsen
Ibsen
Jagellovsk
DeMonti
....
VL Datenbanken I – 1–38
1
1
4
..
*
*
*
*
...
101101
101110
101111
110000
110001
...
...
UNIX X
Datenbasen 1
MZ4 antwortet nicht
...
VL Datenbanken I – 1–39
System-Architekturen
ANSI-SPARC-Architektur I
■
Beschreibung der Komponenten eines
Datenbanksystems
■
Standardisierung der Schnittstellen zwischen
Komponenten
Architekturvorschläge
■
ANSI-SPARC-Architektur
; Drei-Ebenen-Architektur
■
Fünf-Schichten-Architektur
; beschreibt Transformationskomponenten
■
ANSI: American National Standards Institute
■
SPARC: Standards Planning and Requirement
Committee
■
Vorschlag von 1978
■
Im Wesentlichen Grobarchitektur verfeinert
◆ Interne Ebene / Betriebssystem verfeinert
◆ Mehr Interaktive und Programmier-Komponenten
◆ Schnittstellen bezeichnet und normiert
VL Datenbanken I – 1–40
Klassifizierung der Komponenten
ANSI-SPARC-Architektur II
Externe Ebene
Konzeptuelle Ebene
Interne Ebene
Anfragen
Optimierer
Auswertung
VL Datenbanken I – 1–41
Plattenzugriff
■
Definitionskomponenten: Datendefinition,
Dateiorganisation, Sichtdefinition
■
Programmierkomponenten: DB-Programmierung mit
eingebetteten DB-Operationen
■
Benutzerkomponenten: Anwendungsprogramme,
Anfrage und Update interaktiv
■
Transformationskomponenten: Optimierer, Auswertung,
Plattenzugriffssteuerung
■
Data Dictionary (Datenwörterbuch): Aufnahme der
Daten aus Definitionskomponenten, Versorgung der
anderen Komponenten
Updates
P1
DB-Operationen
...
Einbettung
Pn
Masken
Data Dictionary
Sichtdefinition
Dateiorganisation
Datendefinition
VL Datenbanken I – 1–42
VL Datenbanken I – 1–43
Fünf-Schichten-Architektur
5-Schichten-Architektur: Schnittstellen I
■
basierend auf Idee von Senko 1973
■
Weiterentwicklung von Härder 1987
■
Umsetzung im Rahmen des IBM-Prototyps System R
■
genauere Beschreibung der
Transformationskomponenten
◆ schrittweise Transformation von
Anfragen/Änderungen bis hin zu Zugriffen auf
Speichermedien
◆ Definition der Schnittstellen zwischen Komponenten
■
mengenorientierte Schnittstelle
◆ deklarative DML auf Tabellen, Sichten, Zeilen
■
satzorientierte Schnittstelle
◆ Sätze, logische Dateien, logische Zugriffspfade
◆ navigierender Zugriff
■
interne Satzschnittstelle
◆ Sätze, Zugriffspfade
◆ Manipulation von Sätzen und Zugriffspfaden
VL Datenbanken I – 1–44
5-Schichten-Architektur: Schnittstellen II
■
■
■
Pufferschnittstelle
◆ Seiten, Seitenadressen
◆ Freigeben und Bereitstellen
VL Datenbanken I – 1–45
5-Schichten-Architektur: Funktionen
Mengenorientierte
Schnittstelle (MOS)
Datensystem
Übersetzung, Zugriffspfadauswahl,
Zugriffskontrolle, Integritätskontrolle
Zugriffssystem
Data Dictionary, Currency Pointer,
Sortierung, Transaktionsverwaltung
Speichersystem
Record Manager, Zugriffspfadverwaltung,
Sperrverwaltung, Log/Recovery
Pufferverwaltung
Systempufferverwaltung mit
Seitenwechselstrategie
Satzorientierte
Schnittstelle (SOS)
Datei- oder Seitenschnittstelle
◆ Hole Seite, Schreibe Seite
Interne Satz−
schnittstelle (ISS)
Geräteschnittstelle
◆ Spuren, Zylinder
◆ Armbewegungen
Systempuffer−
schnittstelle (SPS)
Datei−
schnittstelle (DS)
Betriebssystem
Externspeicherverwaltung
Geräte−
schnittstelle (GS)
VL Datenbanken I – 1–46
VL Datenbanken I – 1–47
5-Schichten-Architektur: Objekte
Mengenorientierte
Schnittstelle (MOS)
Einige konkrete Systeme
Relationen
Sichten
SQL : select ... from ...
QBE, QUEL, ...
externe Sätze, Scans,
Index−Strukturen
FIND NEXT satz
STORE satz
interne Sätze, Bäume,
Hashtabellen
Speichere internen Satz s
INSERT in B−Baum
Segmente
Seiten
Bereitstellen Seite j
Freigeben Seite j
Dateien
Blöcke
Lies Block k
Schreibe Block k
Zylinder
Spuren
Treiber
■
(Objekt-)Relationale DBMS
◆ Oracle9i, IBM DB2 V.7, Microsoft SQL Server 2000,
Sybase
◆ MySQL, PostgreSQL, Firebird
■
Pseudo-DBMS
◆ MS Access, dBase
■
Objektorientierte DBMS
◆ Poet, Versant, ObjectStore
■
XML-DBMS
◆ Tamino (Software AG), eXcelon, Xindice
Datensystem
Satzorientierte
Schnittstelle (SOS)
Zugriffssystem
Interne Satz−
schnittstelle (ISS)
Speichersystem
Systempuffer−
schnittstelle (SPS)
Pufferverwaltung
Datei−
schnittstelle (DS)
Betriebssystem
Geräte−
schnittstelle (GS)
VL Datenbanken I – 1–48
VL Datenbanken I – 1–49
Open Source DBMS (I)
Oracle9i
■
Objektrelationales DBMS + Entwicklungswerkzeuge
■
verfügbar für Unix, Linux, Windows, Palm, PocketPC etc.
■
Enterprise, Personal, Mobile-Versionen
■
Unterstützung von XML und Multimedia-Dokumenten
■
Erweiterbarkeit über prozedurale SQL-Erweiterungen,
Java
■
Sicherheits- und Auto-Administration-Features
■
Internet-Content-Management (HTTP-, FTP-,
WebDAV-Zugriff), Application Server
■
Data Warehouse und Business Intelligence (OLAP, Data
Mining)
■
Unterstützung von verteilten und parallelen DBS
VL Datenbanken I – 1–50
■
MySQL (www.mysql.com)
◆ weit verbreitet (Linux, Windows), speziell für
Web-Datenbanken
◆ eingeschränkte SQL-Unterstützung, keine
Transaktionen etc.
■
PostgreSQL (www.postgresql.org)
◆ aus Forschungssystem Postgres (UCB) entwickelt
◆ für Unix und Linux
◆ objektrelationale Features (benutzerdefinierte
Datentypen)
◆ bessere SQL-Unterstützung
VL Datenbanken I – 1–51
Open Source DBMS (II)
■
FireBird (www.firebirdsql.org)
◆ aus InterBase (Borland) entstanden
◆ für Unix, Linux, Windows
◆ kompakt, geringer Speicherbedarf (2-3 MB)
◆ sehr gute SQL-Unterstützung
VL Datenbanken I – 1–52