Vorlesung Datenbanksysteme - Fakultät für Mathematik und Informatik

Vorlesung
Datenbanksysteme
- Weiterqualifizierung für Lehrer Sommersemester 2008
Institut für Informatik
Lehrstuhl für Datenbanken und Informationssysteme
[http://www.minet.uni-jena.de/dbis]
Prof. Dr. Klaus Küspert
Dipl.-Inf. Matthias Liebisch
10.04.2008
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 1
Organisatorisches
Vorlesung Datenbanksystems im Sommersemester
- 10.04. - 17.07. jeweils Donnerstag 10.30 - 12.00
- Regulärer Umfang ist V4+Ü2 (DBS1), eingedampft auf V2 (DBS½)
- Klausur-/Prüfungsmodalitäten noch unklar
Theoretischer Umfang von 15 Terminen, allerdings:
- 01.05. (Doppel)-Feiertag mit Seltenheitswert: zuletzt 1913, wieder 2160
- 12.06. Rechtstutorium durch Hr. Ivo Geis
- 2 Praktikumstermine am Ende
Folien werden schrittweise im Netz bereitgestellt
- Spätestens 1 Tag vor dem Vorlesungstermin
- http://www.minet.uni-jena.de/dbis/
Lehrveranstaltungen
[Weiterqualifizierung für Lehrer]
Materialien
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 2
Literatur
Vorlesung wird aus verschiedenen Quellen gespeist
Beispiele für gute, nette Lehrbücher sind:
- Andreas Heuer, Gunter Saake: Datenbanken:
Konzepte und Sprachen. mitp-Verlag, Bonn, 3. Auflage, 2007
- Andreas Heuer, Gunter Saake, Kai-Uwe Sattler:
Datenbanken kompakt. mitp-Verlag, Bonn
- Stefan Lang, Peter Lockemann:
Datenbank-Einsatz. Springer-Verlag, Berlin Heidelberg
- Werner Kießling, Gerhard Köstler:
Multimedia-Kurs Datenbanksysteme. Springer-Verlag, Berlin Heidelberg
- Karl Neumann:
Datenbanktechnik für Anwender. Hanser Verlag, München
- Alfred Moos, Gerhard Daues:
Datenbank-Engineering. Vieweg Verlag, Braunschweig Wiesbaden
- Günter Matthiesen, Michael Unterstein:
Relationale Datenbanken und SQL. Addison-Wesley Verlag Deutschland,
Bonn
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 3
Inhalt
1. Einleitung und Motivation [2 Termine]
-
Warum braucht man Datenbanksysteme; welchen Nutzen verspricht
man sich von Datenbanksystemen; welche Probleme sollen sie lösen?
-
Datenverwaltung mit Dateisystemen: Möglichkeiten, Varianten,
Limitationen
-
Datenbanksysteme und ihre Eigenschaften im Überblick:
Was sind die entscheidenden Funktionalitäten von
Datenbanksystemen?
-
Begriffe, die im Zusammenhang mit Datenbanksystemen eine Rolle
spielen, im „Schnelldurchlauf“
2. Datenmodellierung mit Entity-Relationship-Modell [2 Termine]
-
Was versteht man unter dem ERM?
-
Welche Konstrukte bietet ERM und wie setzt man diese ein?
-
Varianten des ERM, Mächtigkeit und Nutzen dieser Varianten
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 4
Inhalt
3. Relationales Daten(bank)modell [1 Termin]
- Exkurs in die Historie: Hierarchisches/Netzwerk-Datenmodell
- Datendarstellung/-modellierung, Konstrukte
- Vom Entity-Relationship-Modell zum relationalen Modell:
Vorgehen/Umsetzung
4. Algebra [1 Termin]
- Sprachen für das relationale Modell
- Umgang mit zugehörigen relationalen Datenbanksystemen
5. SQL [5 Termine]
- SQL (Structured Query Language) als die Datenbanksprache
- Historie und Normierung
- Funktionalität
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 5
1. Einleitung und Motivation
Datenhaltungsfragestellungen
Datenhaltungsanforderungen
Größenordnungen
Datenverwaltung mit Dateisystemen
Dateien vs. Datenhaltungsanforderungen
Datenbanksysteme – Terminologie & Eigenschaften
Architekturen im DB-Umfeld
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 6
1.1 Datenhaltungsfragestellungen
In sehr vielen Informatik-Anwendungen (Anwendungssystemen) stehen –
teils sehr große – Datenbestände im Mittelpunkt der Betrachtungen.
Beispiele aus dem betriebswirtschaftlichen Bereich:
- Personaldatensysteme, Lagerverwaltung/Bestandsverwaltung
- Buchungssysteme (Hotel, Flug, Reise, Bahn, Mietwagen ...) und
Abrechnungssysteme
- Kontenführung (Banken etc.)
- Vertragsbestandsverwaltung (Versicherungen, Bausparkassen etc.)
- Auftragsverwaltung (jedes Unternehmen!)
z.B. SAP R/3 (mySAP ERP)
Beispiele aus dem technischen Bereich:
- Konstruktionsdatenverwaltung für CAD-Systeme (Computer Aided
Design)
- Verwaltung von Millionen chemischer Verbindungen
- Meßdatenerfassung/-verwaltung
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 7
1.1 Datenhaltungsfragestellungen
Beispiele aus dem bürokratischen Bereich:
- Textverwaltung/Dokumentverwaltung
- Mail-Ablage und -Verwaltung
- Telefonverzeichnisse
Beispiele aus dem wissenschaftlichen Bereich:
- Regel- und Faktenablage sowie -verwaltung bei Expertensystemen
- Ablage/Verwaltung von Formelsammlungen in der Mathematik
In allen diesen Fällen sollen Datenbestände zum Zugriff (Lesen) und zur
Veränderung bereitgestellt werden
- meist über eine Anwendung
- teils aber auch zum direkten „Ad-hoc-Zugriff“ seitens des Benutzers
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 8
1.2 Datenhaltungsanforderungen
Persistente Datenhaltung, d.h. auf nichtflüchtigem Speicher (Magnetplatte, band, optischem Speicher)
Ggf. sehr große („beliebig große“) Datenmengen: (Giga-/Terabytes/mehr)
Sehr schneller Zugriff auf die Daten beim Lesen/Einfügen/Ändern/Löschen
→ i.d.R. keine sequentielle Suche akzeptierbar, „hohe Performance“!!!
Hohe Verfügbarkeit der Daten: eventuell 24*7, d.h. 24-Stunden-Betrieb 365
Tage im Jahr (Bsp.: Flugbuchungssysteme, Bankensysteme)
Hohe Flexibilität beim Datenzugriff / der Datenauswertung, integrierte
Auswertbarkeit verschiedener Datenbestände
- Bsp: Welche Mitarbeiter der Firma sind seit über 10 Jahren im
Unternehmen, haben Kurse zu Unix und Windows besucht und haben
schon in mindestens drei Projekten Leitungserfahrung gesammelt?
- hierfür kann man eigens eine Anwendung schreiben (Anfrage
„ausprogrammieren“, will man aber vielleicht nicht)
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 9
1.2 Datenhaltungsanforderungen
Hohe Flexibilität bzgl. der Datenverteilung:
- Bsp: Mitarbeiterstammdaten auf Rechner in Hamburg, Kursdaten in
Stuttgart, Projektdaten in Dresden; trotzdem integrierte Auswertbarkeit
(„regionale Verteilung“) gewollt (Transparenz)
Hohe Flexibilität bzgl. der Lastverteilung:
- Bsp.: Von mehreren nahe beieinander befindlichen Rechnern (RechnerCluster) soll auf einen Datenbestand zugegriffen werden können in für
den Benutzer / die Anwendung transparenter Weise
Hohe Benutzerfreundlichkeit des Datenhaltungssystems
- einfacher Zugriff auf die Daten, leichte Erlernbarkeit der Abfragesprache
bei gleichzeitig großer Mächtigkeit der Sprache
- „Quadratur des Kreises“? Jein
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 10
1.2 Datenhaltungsanforderungen
Sicherheit vor Datenverlust:
- Auch bei plötzlich auftretendem Systemausfall („Absturz“) bzw. sogar bei
Versagen eines Externspeichermediums soll kein irreversibler
Datenverlust eintreten bzw. dieser sich in wohldefinierten Grenzen halten
Sicherheit vor unberechtigtem (änderndem) Zugriff zu den Daten:
- Dies soll möglichst fein und präzise spezifizierbar sein
- Bsp: Personalsachbearbeiter Müller soll nur auf jene Personalstammsätze
zugreifen können, wo Gehalt < 7000. Oder: Änderungen des Gehalts im
Personalstammsatz soll nur der Personalleiter Müller-Meerschwein
vornehmen können.
Paralleler Zugriff mehrerer („beliebig vieler“) Benutzer auf einen
Datenbestand und zwar ohne dass „Konflikte“ auftreten logischer
Einbenutzerbetrieb bei physischem Mehrbenutzer-betrieb
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 11
1.2 Datenhaltungsanforderungen
Hoher Grad an semantischer Integrität im Datenbestand vom
Datenhaltungssystem automatisch garantiert
- Bsp: Datenhaltungssystem garantiert,
• dass Personalnummern nicht mehrfach vergeben werden (Angest. MüllerLüdenscheid und –Meerschwein haben beide Personalnummer 4711 )
• dass Gehalt stets < 10000, falls dies in der Firma so sein soll
semantische Integritätsbedingung
• dass Durchschnittsgehalt einer Abteilung stets < 7000, falls . . .
• dass jeder Mitarbeiter auch wirklich einer Abteilung zugeordnet ist (keine
„Waisenkinder“)
- Datenhaltungssystem überwacht selbständig Integritätsregeln bzw. sorgt
sogar durch „aktive Mechanismen“ dafür, dass Integrität automatisch
wiederhergestellt wird
• Bsp: Abteilungsdaten werden aus Bestand gelöscht, Datenhaltungssystem
löscht autom. alle zugehörigen Angestelltendaten (falls man das so will ...)
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 12
1.2 Datenhaltungsanforderungen
Hoher Grad an Datenunabhängigkeit (Vertiefung später)
- (Strukturelle) Änderungen im Datenbestand sollen sich möglichst nicht
unmittelbar auf die Anwendungsprogramme auswirken
- Bsp: Angestelltenstammsatz wird um neues Feld „Haarfarbe“ erweitert,
nur ein Anwendungsprogramm (APx) nutzt zunächst dieses neue Feld →
alle anderen Anwendungsprogramme sollten von dieser strukturellen
Änderung am besten überhaupt nichts mitbekommen
- Bsp: Gehaltsfeld (INTEGER) wird von 3 auf 4 Bytes erweitert, um auch
Monatsgehälter > 16... Mio darstellen zu können → Alle AP's sollten
davon unberührt bleiben
AP1
AP2
AP3
...
APn
n sehr groß
Betriebssystem + Datenhaltungssystem
Datenbestand
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 13
1.2 Datenhaltungsanforderungen
Datenbanksysteme sollen bzgl. aller vorgenannten Anforderungen und
Vorstellungen Lösungen bieten
- Funktionalität soll nicht nur „irgendwie“ bereitgestellt werden, sondern
vorallem unter Performance-Gesichtspunkten
- Sonst ist man bei großen Datenbeständen, vielen parallelen
Benutzern, komplexen Anfragen/Auswertungen verloren!!
Praxis trennt sorgfältig zwischen
- OLTP-Betrieb → unser Thema vorwiegend
• Online Transaction Processing (Bsp: Flugbuchung)
• viele (kurze) Verarbeitungsvorgänge (Transaktionen)
• viele parallele Benutzer, schnelle Antwortzeiten
- OLAP-Betrieb → Thema Data Warehouses
• Online Analytical Processing, auch DSS (Decision Support System)
• komplexe (lange) Verarbeitungsvorgänge
• wenige parallele Benutzer, relativ unkritische Antwortzeiten
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 14
1.3 Größenordnungen
Datenbestände in GB-/TB-/PB-Größenordnungen
Hunderte/Tausende gleichzeitig aktive Nutzer auf einem Datenbestand
Dutzende/Hunderte von angeschlossenen Externspeichermedien
(Magnetplatten)
Hunderte von „Verarbeitungsvorgängen“ (Transaktionen) pro Sekunde auf
einem Datenbestand, z.B. der Art:
- Umbuchung von einem Konto auf ein anderes
- Durchführung einer Platzreservierung
- Anfrage an ein Auskunftssystem
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 15
1.4 Datenverwaltung mit Dateisystemen
Dateiverwaltung (Dateisystem) in der einen oder anderen Weise Bestandteil
eines jeden Betriebssystems
Datei = geordnete Sammlung von Datensätzen (auf Externspeicher), wobei
- Datensätze sich aus Feldern zusammensetzen (→ Struktur des
Datensatzes)
- Alle Datensätze einer Datei i.d.R. die gleiche Struktur aufweisen →
„homogene Sammlung“ von Datensätzen
Geordnet heißt nicht unbedingt sortiert, sondern dass irgendeine
Reihenfolge der Datensätze auf Externspeicher vorliegt und diese
Reihenfolge von Anwendungen „gesehen“ und ausgenutzt werden kann
beim Lesen der Daten (gib mir ersten/nächsten Datensatz); Unterscheidung:
- „entry sequenced“: Einfügereihenfolge bestimmt Ordnung
- „key sequenced“: „Schlüsselwert“ bestimmt Ordnung, sortiert nach
bestimmtem (Schlüssel-)Feld, etwa nach Personalnummer
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 16
1.4 Datenverwaltung mit Dateisystemen
Externspeicher gliedert sich in
- Magnetplatte (Sekundärspeicher)
- Magnetband, opt. Speicher o.ä. (Tertiärspeicher)
- Dateien, für die ein schneller (u. ggf. wahlfreier) Zugriff („random
access“) benötigt wird, müssen auf Magnetplatte stehen, andernfalls
können auch (kostengünstigere) Tertiärspeicher Verwendung finden
Homogene Sammlung von Datensätzen heißt
- Aus Sicht der Anwendungsprogramme
• Im wesentlichen gleichstrukturierte Datensätze innerhalb einer
Datei
• Gewisse variante Strukturen bzgl. der Felder möglich (z.B.:
Buchungsnr. < 1000000 wird Ktonr. als 2-Byte-Integer interpretiert,
sonst als 2-Byte-Character-Feld).
- Aus Sicht des Betriebssystems/Dateisystems alles nur „byte strings“,
hier Homogenität ohnehin gegeben
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 17
1.4 Datenverwaltung mit Dateisystemen
Felder / Struktur heißt, dass ein Datensatz sich aus Sicht der
Anwendung(!) nicht einfach als „byte string“ darstellt, sondern als
strukturiertes Gebilde
- Bsp.:
Buchungs- Betrag Kto- Zahlungsnr.
nr. empfänger
3 Bytes
4 Bytes 2 Bytes
...
16 Bytes
Felder 1 ... 4
- So sieht das Anwendungsprogramm bzw. interpretiert Benutzer den
Datensatz; das Betriebssystem (Dateisystem) ist u.U. viel „dümmer“, hat
doch nur die Sicht des langen „byte strings“ und kennt keine Felder
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 18
1.4.1 Sequentielle Datei
Datensätze sequentiell (fortlaufend) z.B. auf Platte oder Band abgelegt,
Ordnung entstanden durch Einfügereihenfolge; z.B. Angestelltendatei
Stammdaten Stammdaten Stammdaten
Mitarbeiter
Mitarbeiter
Mitarbeiter
Späth
Müller
Meier
...
Felder fest oder variabel lang → Datensätze ebenfalls fest oder variabel lang
Zugriff auf die Datensätze (vereinfachend lesender Zugriff):
- Bei variabler Länge nur sequentieller Zugriff möglich („lies einen
Datensatz nach dem anderen“)
- Bei fester Länge und Ablage auf Platte auch wahlfreier Zugriff möglich
(„lies Datensatz 37“)
- Bei fester Länge und Ablage auf Platte und sortierter Speicherung (z.B.
nach Personalnr. oder Name) auch binäre Suche möglich
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 19
1.4.2 Indexsequentielle Datei
Blätter eines (Zugriffs-)Baums enthalten Datensätze oder Verweise zu den
außerhalb des Baums abgelegten Datensätzen
Implementierungsform i.d.R. B*-Baum (balancierter Baum mit mindestens
2/3-gefüllten Knoten), Datensätze nach bestimmtem (Schlüssel-)Feld sortiert
abgelegt
Implementierungsbezeichnungen z.B. ISAM (Index Sequential Access
Method) oder VSAM (Virtual Storage Access Method)
Zugriff auf die Daten
- Sequentieller Zugriff liefert Datensätze in der Wertereihenfolge des
Schlüsselfelds
- Wahlfreier Zugriff unter Verwendung der Indexstruktur des Baums bei
gegebenem Schlüsselfeldwert
eingebettete
Datensätze
Satz 1 ... 2 ... 3
Datenbanksysteme
Verweis auf
Datensätze
Höhe h
Satz 1
Friedrich-Schiller-Universität Jena
... 2
... 3
Seite 20
1.4.3 Hash-Datei
Festlegung eines Feldes als Schlüsselfeld (wie bei indexsequentieller Datei),
die Schlüsselfeldwerte werden über Hashfunktion (z.B. Quersumme) in
Speicheradressen umgerechnet
Zugriff auf die Daten:
- Wahlfreier Zugriff auf die Daten (unter Verwendung der Hashfunktion bei
gegebenem Schlüsselfeldwert („Suchwert“))
- Sequentieller Zugriff abhängig von Implementierungsdetails (vor allem
Überlaufbehandlung / Konfliktauflösung)
Grundsätzlich auch bei Hash-Datei Unterscheidung möglich zwischen
eingebetteten und nichteingebetteten Datensätzen
Hashtabelle
Datenbanksysteme
Hashtabelle
Friedrich-Schiller-Universität Jena
Seite 21
1.5 Dateien vs. Datenhaltungsanforderungen
Persistente Datenhaltung
o.k.; Magnetplatte/-band und weitere (Tertiär-)Speichermedien unterstützt je
nach vorgenannter Dateiorganisationsform (z.B. Band verträgt sich nur mit
sequentieller Datei)
Sehr große Datenmengen (GB, TB)
im Prinzip o.k., aber Obergrenzen für Dateigrößen beachten (z.B. 2 GB);
größere Datenbestände müssen „künstlich zerhackt“ und auf mehrere, ggf.
viele Dateien aufgeteilt werden → erschwert Handhabung
Sehr schneller Zugriff auf die Daten
Nur bei indexsequentiellen und Hash-Dateien gegeben und auch dort nur
bei Zugriff über das Schlüsselfeld (gegebener Schlüsselfeldwert), ansonsten
Zugriff sehr langsam
- Zudem: Anwendung muss Form der Datenabspeicherung kennen
(sequentiell, indexsequentiell, Hash) beim Zugriff berücksichtigen
- Probleme bei Änderung der Art der Abspeicherung!
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 22
1.5 Dateien vs. Datenhaltungsanforderungen
Hohe Verfügbarkeit der Daten
nicht o.k., weil:
- Was passiert bei Datenverlust auf der Platte („Datei/Platt kaputt“)?
- Was passiert im Fall der Datenreorganisation, wenn z.B. Hashdatei
vergrößert werden muss?
Hohe Flexibilität bei Datenzugriff / Integrierte Auswertbarkeit
- Bei Nutzung von Dateisystemen definitiv nicht gegeben, jeweils neue
und eigens zugeschnittene Anwendung erforderlich
- Auswertung „Alle Personalstammsätze, wo Name = Müller“ mag schnell
gehen (falls Index/Hash-Zugriff), „Alle Personalstammsätze, wo Gehalt >
500“ dagegen u.U. gar nicht oder nur sehr langsam
- Integrierte Auswertungen über mehrere Dateien muss ein Programm
„zu Fuß“ machen
Hohe Flexibilität bzgl. der Datenverteilung
Betriebssystem kann ggf. physische Lokation der Dateien im Netz verbergen
(→
→ Transparenz), aber Problem der integrierten Auswertbarkeit ohnehin hier
ungelöst, somit erst recht bei Verteilung
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 23
1.5 Dateien vs. Datenhaltungsanforderungen
Hohe Flexibilität bzgl. der Lastverteilung
Zugriff zu einem Datenbestand i.d.R. über einen Rechner ("hot spot"-Gefahr)
Hohe Benutzerfreundlichkeit
Bei Dateisystem in keiner Weise gegeben, keine leicht erlernbare
"Abfragesprache“ vorhanden
Sicherheit vor Datenverlust
Verwendung der letzten Sicherungskopie der Datei („backup“) soweit
vorhanden → unbefriedigend
Sicherheit vor unberechtigtem Zugriff/Verändern
Rechtevergabe nur für Datei insgesamt möglich, nicht aber werteabhängig
→ Kenntnis an Datensemantik fehlt im Dateisystem
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 24
1.5 Dateien vs. Datenhaltungsanforderungen
Paralleler Zugriff mehrerer Benutzer
- Lesend (natürlich) kein Problem
- modifizierend wird entweder durch Sperren der gesamten Datei
(zuständig: Dateisystem) unterbunden oder liefert potentiell Chaos →
unkontrolliertes Überschreiben von Datensätzen
- Es fehlen Transaktionskonzepte & Synchronisationsmechanismen
Hoher Grad an semantischer Integrität
Dateisysteme kennen fast keine Datensemantik, können somit auch nichts
bieten hinsichtlich Fehlererkennung / „aktive Mechanismen“
Hoher Grad an Datenunabhängigkeit
Problemszenarien bereits angesprochen:
- Strukturelle Änderung im Datenbestand → Anpassung der Anwendungen
- Abhängigkeit vom (Nicht-)Vorhandensein einer bestimmten
Dateiorganisationsform
- Abhängigkeit/Vertrauen bzgl. einer bestimmten Sortierfolge in der Datei
Dateisysteme bieten keine Datenunabhängigkeit!
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 25
1.5 Dateien vs. Datenhaltungsanforderungen
Fazit: Datenhaltung in Dateisystemen eignet sich nur sehr beschränkt zur
Verwaltung großer Datenbestände unter Gesichtspunkten wie
Flexibilität, (Effizienz), Benutzerfreundlichkeit, Fehlertoleranz, Datensicherheit,
Datenunabhängigkeit, parallele Verarbeitung usw.
Datenbanktechnologie soll die Antwort auf diese
Fragestellungen / Anforderungen liefern
Aber: bezüglich Effizienz kann eine zugeschnittene, dateibasierte Lösung
einer (allgemeineren) datenbankbasierten Lösung überlegen sein: manche
CAD-Systeme, Geodatenverwaltungssysteme etc. verwenden nach wie vor
dateibasierte Datenverwaltung!
Datenbanksysteme
Friedrich-Schiller-Universität Jena
Seite 26