Datenbanken

Vorlesung
Datenbanken
TU Dresden, SS 2002
Kai-Uwe Sattler
[email protected]
VL Datenbanken I – 0–1
Überblick
1. Grundlegende Konzepte und Architekturen
2. Datenbankmodelle für den Entwurf
3. Datenbankmodelle für die Realisierung
4. Datenbankentwurf und Datendefinition
5. Anfrage- und Änderungsoperationen
6. Relationale Datenbanksprachen
7. Datenbank-Anwendungsprogrammierung
8. Integrität und Trigger
9. Sichten, Datenschutz
VL Datenbanken I – 0–1
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
VL Datenbanken I – 0–2
1. Grundlegende Konzepte
■
Motivation und Historie
■
Komponenten und Funktionen
■
Einsatzgebiete und Grenzen
■
Entwicklungslinien
■
Schema-Architektur
■
System-Architekturen
VL Datenbanken I – 1–1
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
■
Daten sind redundant: mehrfach gespeichert; Probleme:
Verschwendung von Speicherplatz, „Vergessen“ von
Änderungen; keine zentrale, „genormte“ Datenhaltung
VL Datenbanken I – 1–2
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
VL Datenbanken I – 1–3
Mit Datenbanken: Datenintegration
■
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
VL Datenbanken I – 1–4
Historie
■
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–5
Prinzipien
■
DBMS: Datenbank-Management-System
■
DBS: Datenbanksystem (DBMS + Datenbank)
Anwendung 1
...
Anwendung n
DBMS
Datenbank
VL Datenbanken I – 1–6
Prinzipien II
■
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
VL Datenbanken I – 1–7
Prinzipien III
■
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
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–9
Konzeptuelle Ebene: Relationenmodell I
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–10
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
...
...
Attribute
An
} Relationenschema
...
...
Relation
Tupel
VL Datenbanken I – 1–11
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
VL Datenbanken I – 1–12
Anfrageoperationen I
■
SELEKTION: Zeilen (Tupel) auswählen
σNAME=’Meyer’ (AUSLEIH)
■
INVENTARNR
NAME
4711
Meyer
4712
Meyer
PROJEKTION: Spalten (Attribute) auswählen
INVENTARNR
πINVENTARNR, TITEL (BUCH)
TITEL
0007
Dr. No
1201
Objektbanken
4711
Datenbanken
4712
Datenbanken
4717
PASCAL
Achtung: doppelte Tupel werden entfernt!
VL Datenbanken I – 1–13
Anfrageoperationen II
■
VERBUND (JOIN): Tabellen verknüpfen über
gleichbenannte Spalten und gleiche Werte
πINVENTARNR,TITEL (BUCH) 1 σNAME=’Meyer’ (AUSLEIH)
ergibt:
INVENTARNR
TITEL
NAME
4711
Datenbanken
Meyer
4712
Datenbanken
Meyer
■
Weitere Operationen: Vereinigung, Differenz,
Durchschnitt, Umbenennung
■
Alle Operationen beliebig kombinierbar („Algebra“)
VL Datenbanken I – 1–14
Sprachen und Sichten I
■
Anfragesprache
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–15
Sprachen und Sichten II
■
Ä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.
VL Datenbanken I – 1–16
Optimierer I
Problem:
Finde einen Relationenalgebra-Ausdruck, der
äquivalent ist („das gleiche Ergebnis liefert“) wie
der gegebene, aber effizienter auszuwerten ist
VL Datenbanken I – 1–17
Optimierer: Algebraische Optimierung
■
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–18
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
◆
◆
■
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–19
Zugriffe auf Plattenseiten
■
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–20
Einsatzgebiete und Grenzen
■
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–21
Einsatzgebiete und Grenzen II
Normalerweise sind herkömmliche Datenbanksysteme
überfordert mit:
■
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–22
Entwicklungslinien: 60er Jahre
■
DBS basierend auf hierarchischem Modell,
Netzwerkmodell
◆ Zeigerstrukturen zwischen Daten
◆ Schwache Trennung interne / konzeptuelle Ebene
◆ Navigierende DML
◆ Trennung DML / Programmiersprache
VL Datenbanken I – 1–23
Entwicklungslinien: 70er und 80er Jahre
■
Relationale Datenbanksysteme
◆ Daten in Tabellenstrukturen
◆ 3-Ebenen-Konzept
◆ Deklarative DML
◆ Trennung DML / Programmiersprache
VL Datenbanken I – 1–24
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–25
Entwicklungslinien: heute
■
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–26
Schema-Architektur I
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–27
Schema-Architektur II
■
Trennung Schema — Instanz
◆ Schema (Metadaten, Datenbeschreibungen)
◆ Instanz (Anwenderdaten, Datenbankzustand oder
-ausprägung)
■
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)
VL Datenbanken I – 1–28
Schema-Architektur III
externes Schema 1
...
externes Schema N
Datendarstellung
Anfragebearbeitung
konzeptuelles Schema
internes Schema
VL Datenbanken I – 1–29
Datenunabhängigkeit I
■
Stabilität der Benutzerschnittstelle gegen Änderungen
■
physisch: Änderungen der Dateiorganisationen und
Zugriffspfade haben keinen Einfluß auf das konzeptuelle
Schema
■
logisch: Änderungen am konzeptuellen und gewissen
externen Schemata haben keine Auswirkungen auf
andere externe Schemata und Anwendungsprogramme
VL Datenbanken I – 1–30
Datenunabhängigkeit II
■
mögliche Auswirkungen von Änderungen am
konzeptuellen Schema:
eventuell externe Schemata betroffen (Ändern von
Attributen)
◆ eventuell Anwendungsprogramme betroffen
(Rekompilieren der Anwendungsprogramme,
eventuell Änderungen nötig)
◆
■
nötige Änderungen werden jedoch vom DBMS erkannt
und überwacht
VL Datenbanken I – 1–31
Ebenen-Architektur am Beispiel I
■
Konzeptuelle Sicht: relationale Darstellung
AUTOR
BUCH
Name
Nr
BuchID
BUCH.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
...
VL Datenbanken I – 1–32
Ebenen-Architektur am Beispiel II
■
Externe Sicht: Daten in einer flachen Relation
TITEL
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–33
Ebenen-Architektur am Beispiel III
■
Externe Sicht: Daten in einer hierarchisch aufgebauten
Relation
TITEL
Autoren
{ Autor }
Titel
Jahr
ISBN
Meier
Datenbasen I
1993
1-424-11
Ibsen
Schulze
...
UNIX X
1998
3-452-12
...
...
...
VL Datenbanken I – 1–34
Ebenen-Architektur am Beispiel IV
■
Interne Darstellung
Baumzugriff Autorname
Ibsen
Anderson
Heuer
Meier
Schulze
Hash-Tabelle Buchtitel
Ibsen
Ibsen
Jagellovsk
DeMonti
....
1
1
4
..
*
*
*
*
...
101101
101110
101111
110000
110001
...
...
UNIX X
Datenbasen 1
MZ4 antwortet nicht
...
VL Datenbanken I – 1–35
Einige konkrete Systeme
■
(Objekt-)Relationale DBMS
◆ Oracle9i, IBM DB2 V.7, Microsoft SQL Server 2000
◆ MySQL, PostgreSQL
■
Objektorientierte DBMS
◆ Poet, Versant, ObjectStore
■
XML-DBMS
◆ Tamino (Software AG), eXcelon
VL Datenbanken I – 1–45