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

Vorlesung mit Übung
Datenbanksysteme 1
Wintersemester 2014/15
Institut für Informatik
Lehrstuhl für Datenbanken und Informationssysteme
http://www.minet.uni-jena.de/dbis/lehre/
Prof. Dr. Klaus Küspert (Vorlesung)
Dipl.-Inf. Bernhard Pietsch, wiss. Mitarbeiter (Übung)
28.10.2014
Datenbanksysteme 1
1
Organisatorisches – 1
• Veranstaltung V3+Ü1 im aktuellen Wintersemester
• Anschließend DBS2 im Sose 2015 („Paket“ DBS1/DBS2 sehr sinnvoll)
• Termine (Friedolin-Anmeldung):
- Vorlesung Di
UND
08.15 - 09.45 SR222 CZ3 Küspert
- Vorlesung Do 08.15 - 09.45 SR225 CZ3 Küspert (14-tägl.)
- Übung
ODER
Mo 14.15 - 15.45 SR104 AB4 Pietsch (14-tägl.)
- Übung
Do 08.15 - 09.45 SR225 CZ3 Pietsch (14-tägl.)
• Erster Übungstermin am 03.11./06.11.;
geplant sind 6 Übungsblätter im Wisem und 7 Übungstermine
Datenbanksysteme 1
2
Organisatorisches – 2
Scheinvergabe, Credit Points, Leistungspunkte:
• Teilnahme an Klausur am Do., 19.02.15, 16.00-17.30 Uhr, HS1, CZ3
• Modularisierte Studenten erwerben per Klausur 6 Leistungspunkte/ECTSPunkte
• Auch andere (Externe, …) können die Klausur für Schein oder als
Prüfungsleistung mitschreiben
In all diesen Fällen werden schöne Scheine (d.h. informativ, inhaltsreich..)
ausgegeben („Zertifikate“) 
• Folien „und mehr“: Jeweils im Web (sukzessive)!
• Regelmäßiger Besuch von Vorlesung und Übung wird dringend angeraten
(einige Vorlesungsinhalte wird es zusätzlich geben nur in Vorlesung / an
Tafel, also nicht auf den Folien). Übung wird ebenfalls die Vorlesung teils
stofflich ergänzen (bereits beim ersten Übungstermin der Fall)
Datenbanksysteme 1
3
Organisatorisches – 3
• Art der Übungsdurchführung:
- Ausgabe von 6 Übungsblättern
- Übung und „Gemeinsames Präsentieren“ von Übungslösungen im
Rahmen der Übungen (jeweils Woche nach Ausgabe)
• Die Übungsblätter werden beginnend ab KW46 jeweils ins Web gestellt.
http://www.minet.uni-jena.de/dbis/lehre/
• Neben Folien, Übungsblättern ... werden gelegentlich noch weitere
Materialien bereitgestellt, etwa Kopien von Veröffentlichungen
(„Milestone-Papieren“ im Datenbankbereich) etc.
• Regelmäßige, aktive Teilnahme an Vorlesung und Übung sehr
angeraten!!
Datenbanksysteme 1
4
Literatur – 1
• Vorlesung geht nicht strikt nur nach einem bestimmten Lehrbuch vor,
sondern wird inhaltlich aus verschiedenen Quellen gespeist. Beispiele für
gute, nette Lehrbücher im folgenden:
- Gunter Saake, Kai-Uwe Sattler, Andreas Heuer : Datenbanken:
Konzepte und Sprachen. mitp-Verlag, Redline GmbH, Heidelberg,
4. Auflage, 2010
- 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
und und und und und ...
Datenbanksysteme 1
5
Literatur – 2
• Die o.g. Lehrbücher bieten (mehr oder weniger breite) Einführung in die Datenbankthematik, vor allem von der Benutzer-/Administratorseite betrachtet.
• Für die Vorlesung zusätzlich gelegentlich relevant, insbesondere dann in DBS2
(Sommersemester 2015): Systemseite, also Interna, Datenbankmanagementsystem-Implementierung. Hierfür vor allem zwei „berühmte“ (deutschsprachige)
Lehrbücher:
- Theo Härder, Erhard Rahm: Datenbanksysteme. Konzepte und
Techniken der Implementierung. Springer-Verlag, Berlin Heidelberg, 2.
Auflage, 2001
- Gunter Saake, Andreas Heuer, Kai-Uwe Sattler: Datenbanken:
Implementierungstechniken. mitp-Verlag, Bonn, 2. Auflage, 2005
Datenbankmanagementsystem-Interna sind auch für Benutzer/Administratoren
sehr hilfreich, teils nötig!!
vor allem wegen der drei zentralen Probleme im Zusammenhang mit dem Einsatz
von Datenbankmanagementsystemen:
Performance
Performance
Performance
(Performance ist natürlich nicht alles, aber ohne P...)
Datenbanksysteme 1
6
Lehrangebot am Datenbanklehrstuhl
• Regelmäßig angeboten werden (für Bachelors u.a.):
- Datenbanksysteme 1
V3+Ü1 jedes Wisem
- Datenbanksysteme 2
V3+Ü1 jedes Sosem
- Datenbanksysteme Projekt P2
jedes Sosem
Sind also 8 SWS (12 Punkte)
• Angeraten wird komplette Teilnahme an diesen Lehrveranstaltungen
Datenbanksysteme 1
7
Derzeit noch Fragen?
Datenbanksysteme 1
8
Überblick zur Vorlesung DBS 1
1. Einleitung und Motivation
• 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 ist die entscheidende Funktionalität von Datenbanksystemen?
Begriffe, die im Zusammenhang mit Datenbanksystemen eine Rolle
spielen, im „Schnelldurchlauf“
2. Datenmodellierung mit dem Entity-Relationship-Modell (ERM)
• Was versteht man unter dem ERM?
Welche Konstrukte bietet es und wie setzt man diese Konstrukte ein?
• Varianten des ERM, Mächtigkeit und Nutzen dieser Varianten
Datenbanksysteme 1
9
3. Das hierarchische Daten(bank)modell
• Möglichkeiten der Datendarstellung/-modellierung mit dem hierarchiIMS schen Modell im „real existierenden Datenbanksystem“, Konstrukte
• Zugriff auf die Daten (Operationsvorrat),
Verarbeitung der Daten durch Anwendungsprogramme
• Einschätzung und Bewertung
4. Das Netzwerk-Daten(bank)modell
• Datendarstellung/-modellierung ..., Konstrukte
• Zugriff auf die Daten, Verarbeitung durch Anwendungsprogramme
• Einschätzung und Bewertung
5. Das relationale Daten(bank)modell ! ! !
• Datendarstellung/-modellierung ..., Konstrukte
• Vom Entity-Relationship-Modell zum relationalen Modell:
Vorgehen/Umsetzung
• Sprachen für das relationale Modell bzw. zum Umgang mit zugehörigen
Datenbanksystemen (relationalen Datenbanksystemen): Algebra, Kalkül
• Die Datenbanksprache SQL (Structured Query Language) und ihre
Funktionalität
• SQL-Verwendung aus Anwendungsprogrammen heraus (eingebettetes
SQL, „embedded SQL“)
Datenbanksysteme 1
10
6. Datenmodellierung unter Konsistenzgesichtspunkten (mit Bezug
auf das relationale Modell und zugehörige Datenbanksysteme)
• Sog. Normalformen
• Weitergehende Möglichkeiten zur Integritätssicherung beim
relationalen Modell/relationalen Datenbanksystemen
7. Interne DBS-Aspekte (teils erst in DBS 2)
• Anfragebearbeitung/-optimierung (bei relationalen Datenbanksystemen)
• Datenintegrität im Mehrbenutzerbetrieb
(„concurrency control“) + ihre Gewährleistung
• Datenintegrität im Fehlerfall (Datenbank-Recovery)
• Datenschutz/Datensicherung
Datenbanksysteme 1
11
1. Einleitung und Motivation
- Warum Datenbanksysteme? 1.1 Datenhaltungsfragestellungen
• In sehr vielen Informatik-Anwendungen (Anwendungssystemen) stehen
– teils sehr große – Datenbestände im Mittelpunkt der Betrachtungen.
Beispiele:
- Personaldatensysteme
- Buchungssysteme (Hotel, Flug, Reise, Bahn, Mietwagen ...) und
Abrechnungssysteme
- Lagerverwaltung/Bestandsverwaltung
- Kontenführung (Banken etc.)
- Vertragsbestandsverwaltung (Versicherungen, Bausparkassen etc.)
- Auftragsverwaltung (jedes Unternehmen!)
z.B. SAP R/3 (mySAP ERP)
- etc. etc.
Beispiele aus dem betriebswirtschaftlichen Bereich
Datenbanksysteme 1
12
Technik
• Solche Fragestellungen sind aber auch anderswo anzutreffen
(Beispiele):
- Konstruktionsdatenverwaltung für CAD-Systeme
(Computer Aided Design)
- Verwaltung von Millionen chemischer Verbindungen
- Messdatenerfassung/-verwaltung
- Textverwaltung/Dokumentverwaltung
- Mail-Ablage und –Verwaltung
- Telefonverzeichnisse
- Regel- und Faktenablage und –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-hocZugriff“ seitens des Benutzers
Büro
Wissenschaft
Datenbanksysteme 1
13
1.2 Datenhaltungsanforderungen/-vorstellungen (ca. 15 Punkte..)
• 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: Evtl. 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 1
14
verteilte
Datenbanken
• Hohe Flexibilität bzgl. der Datenverteilung:
Mitarbeiterstammdaten auf Rechner in Hamburg, Kursdaten in
Stuttgart, Projektdaten in Dresden und trotzdem integrierte
Auswertbarkeit („regionale Verteilung“)
Transparenz
Mehrrechner-DBS
Database Sharing
• Hohe Flexibilität bzgl. der Lastverteilung:
Bsp.: Von mehreren nahe beieinander befindlichen Rechnern
(Rechner-Cluster) 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 1
15
DatenbankRecovery
Autorisierung
Synchronisation
Concurrency
Control
• Sicherheit vor Datenverlust: Auch bei plötzlich auftretendem
Systemausfall („Absturz“) bzw. sogar bei Versagen eines
Externspeichermediums soll kein irreversibler Datenverlust
eintreten bzw. der Datenverlust sich in engen, wohldefinierten
Grenzen halten
• Sicherheit vor unberechtigtem Zugriff zu den Daten /
unberechtigtem Verändern: 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 Mehrbenutzerbetrieb
• Hoher Grad an semantischer Integrität im Datenbestand vom
Datenhaltungssystem automatisch garantiert
Datenbanksysteme 1
16
Bsp.:
• Datenhaltungssystem garantiert, dass Personalnummern nicht
mehrfach vergeben werden (Angest. Müller-Lüdenscheid und –
Meerschwein haben beide Personalnummer 4711  )
Aktive Datenbanken / DB Trigger
• . . ., 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 auto-
matisch wiederhergestellt wird (Bsp.: Abteilungsdaten werden aus
Bestand gelöscht, Datenhaltungssystem löscht autom. alle
zugehörigen Angestelltendaten (falls man das so will ...).)
Datenbanksysteme 1
17
• Hoher Grad an Datenunabhängigkeit (der Begriff sei hier nur
angedeutet, wird später sehr vertieft ):
(Strukturelle) Änderungen im Datenbestand sollen sich möglichst
nicht unmittelbar auf die Anwendungsprogramme auswirken.
Szenarium:
AP1
AP2
AP3
...
APn
n sehr groß
Betriebssystem + Datenhaltungssystem
Datenbestand
Angestelltenstammsatz wird um neues Feld „Haarfarbe“ erweitert, nur
ein Anwendungsprogramm APi nutzt zunächst dieses neue Feld 
alle anderen Anwendungsprogramme sollten von dieser strukturellen
Änderung am besten überhaupt nichts mitbekommen
Oder: 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
- etc. - etc. - etc.
Datenbanksysteme 1
18
Nochmals zu den Größenordnungen, von denen man spricht
• Datenbestände in GB-/TB-/PB-Größenordnungen
• Hunderte/Tausende/... gleichzeitig aktive Nutzer auf einem Datenbestand
• Dutzende/Hunderte von angeschlossenen Externspeichermedien
(Magnetplatten)
• (Beispielweise) Hunderte von „Verarbeitungsvorgängen“ pro Sekunde auf
einem Datenbestand, z.B. der Art: Umbuchung von einem Konto auf ein
anderes, Durchführung einer Platzreservierung, Anfrage an ein
Auskunftssystem
 DB-Transaktionen
später präzisiert
und vertieft
Datenbanksysteme 1
19
Datenbanksysteme sollen bzgl. aller vorgenannten Anforderungen und
Vorstellungen Lösungen bieten, wobei wesentlich ist, dass nicht nur
„irgendwie“ die gewünschte Funktionalität bereitgestellt wird, sondern dass
dies vor allem auch unter Performance-Gesichtspunkten geschieht 
sonst ist man bei großen Datenbeständen, vielen parallelen Benutzern,
komplexen Anfragen/Auswertungen verloren!!
• OLTP-Betrieb
 unser Thema vorwiegend
Online Transaction Processing (Bsp.: Flugbuchung)
viele (kurze) Verarbeitungsvorgänge (Transaktionen),
viele parallele Benutzer
schnelle Antwortzeiten
Praxis trennt sorgfältig
• DSS-Betrieb  auch´n Thema
Decision Support System
Data Warehouses
komplexe (lange) Verarbeitungsvorgänge
wenige parallele Benutzer
relativ unkritische Antwortzeiten OLAP Online Analytical Processing
Datenbanksysteme 1
20
1.3 Datenverwaltung mit Dateisystemen
• Dateiverwaltung (Dateisystem) in der einen oder anderen Weise
Bestandteil eines jeden Betriebssystems
• Datei = geordnete Sammlung von Datensätzen (auf Externspeicher),
wobei die Datensätze sich aus Feldern zusammensetzen ( Struktur
des Datensatzes) und alle Datensätze einer Datei i.d.R. die gleiche
Struktur aufweisen  „homogene Sammlung“ von Datensätzen
• Bemerkungen dazu:
- Geordnet heißt nicht unbedingt sortiert, heißt nur, dass
irgendeine Reihenfolge der Datensätze auf Externspeicher
vorliegt und diese Reihenfolge von Anwendungen „gesehen“ wird
und ausgenutzt werden kann beim Lesen der Daten (gib mir
ersten Datensatz, ... nächsten Datensatz usw.).
Unterscheidung begrifflich:
• „entry sequenced“: Einfügereihenfolge bestimmt Ordnung
• „key sequenced“: „Schlüsselwert“ bestimmt Ordnung,
sortiert nach bestimmtem (Schlüssel-)Feld, etwa nach
Personalnr. bei Personalstammdaten, Abteilungsnr. bei
Abteilungsdaten usw.
Datenbanksysteme 1
21
- Externspeicher heißt 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
- Felder / Struktur heißt, dass ein Datensatz sich aus Sicht der
Anwendung(!) nicht einfach als „byte string“ darstellt, sondern als
strukturiertes Gebilde. Bsp.: satz
Buchungs- Betrag Kto- Zahlungsnr.
nr. empfänger
3 Bytes
4 Bytes 2 Bytes
...
16 Bytes
Felder 1 ... 4
N.B.: So sieht das Anwendungsprogramm bzw. der Benutzer den Datensatz bzw. interpretiert ihn in dieser Form; das Betriebssystem (Dateisystem)
ist u.U. viel „dümmer“, hat doch nur die Sicht des langen „byte strings“
(Datensatz = 1 „byte string“), kennt keine Felder
Datenbanksysteme 1
22
- Homogene Sammlung von Datensätzen heißt (i.w.) gleichstrukturierte Datensätze innerhalb einer Datei (aus Sicht der Anwendungsprogramme!). Allenfalls sind aus Sicht der Anwendungsprogramme gewisse variante Strukturen bzgl. der Felder möglich
(z.B.: Buchungsnr. < 1 000 000 wird Ktonr. als 2-Byte-Integer interpretiert, sonst als 2-Byte-Character-Feld).
Falls aus Sicht des Betriebssystems/Dateisystems alles nur „byte
strings“, ist hier Homogenität ohnehin gegeben ...
Dateiorganisationsformen
1. Sequentielle Datei („sequential file“)
Datensätze sequentiell (fortlaufend) z.B. auf Platte oder Band abgelegt,
Ordnung entstanden durch Einfügereihenfolge. Bsp.: Angestelltendatei
Stammdaten Stammdaten Stammdaten
Mitarbeiter
Mitarbeiter
Mitarbeiter
Späth
Müller
Meier
1. Datensatz
Datenbanksysteme 1
2. Datensatz
...
3. Datensatz
23
• Felder fest oder variabel lang  Datensätze ebenfalls fest oder
variabel lang
• Zugriff auf die Daten (wir betrachten hier und im folgenden der
Einfachheit halber vorwiegend lesenden Zugriff):
sequentielle Suche
- Bei variabel langen Datensätzen nur
sequentieller Zugriff
möglich („ein Datensatz nach dem anderen“),
bei fest langen Datensätzen und Ablage auf Platte auch
wahlfreier Zugriff („lies Datensatz 37“)
- Bei fest langen Datensätzen und Ablage auf Platte und sortierter
Speicherung (etwa nach Personalnr. oder Name oder ...) ist auch
binäre Suche (beispielsweise) möglich
2. Indexsequentielle Datei („index sequential file“)
Datensätze in den Blättern eines (Zugriffs-)Baums abgelegt oder
Verweise von den Blättern aus zu den (außerhalb des Baums
abgelegten) Datensätzen
Datenbanksysteme 1
24
• Implementierungsform i.d.R. B*-Baum (als bekannt vorausgesetzt
bzw. siehe 1. Übungstermin)
 Datensätze nach bestimmtem (Schlüssel-)Feld sortiert abgelegt
Höhe
h
Verweise
Satz 1 ... 2 ... 3
eingebettete
Datensätze
Satz 1
... 2
... 3
nicht eingebettete
Datensätze
• Implementierungsbezeichnungen: z.B. ISAM (Index Sequential
Access Method), VSAM (Virtual Storage Access Method), wobei (IBM-)
ISAM nicht die Flexibilität des B*-Baums aufweist, sondern mehr
statische Struktur besitzt
(Platte-Zyl.-Spur
 Baumebenen; Überlaufspuren etc.)
• Zugriff auf die Daten: Sowohl sequentieller Zugriff möglich (liefert
die Datensätze in der Wertereihenfolge des Schlüsselfelds) als auch
wahlfreier Zugriff (unter Verwendung der Indexstruktur des Baums bei
gegebenem Schlüsselfeldwert): Vorteil der Baumorganisationsform!!
Datenbanksysteme 1
25
3. Hash-Datei
Ein Feld wird als Schlüsselfeld festgelegt (wie bei indexsequentieller
Datei), die Schlüsselfeldwerte werden über Hashfunktion in Speicheradressen umgerechnet (als bekannt vorausgesetzt bzw. 1. Übungstermin)
• Zugriff auf die Daten: Wahlfreier Zugriff auf die Daten (unter
Verwendung der Hashfunktion bei gegebenem Schlüsselfeldwert
(„Suchwert“)), ob auch sequentieller Zugriff möglich ist, hängt von
Implementierungsdetails ab (vor allem Überlaufbehandlung/
Konfliktauflösung)
• Grundsätzlich auch bei Hash-Datei Unterscheidung möglich zwischen
eingebetteten und nichteingebetteten Datensätzen
Hashtabelle
Datenbanksysteme 1
Hashtabelle
26
Dateien vs. Datenhaltungsanforderungen/-vorstellungen
aus Kap. 1.2
• 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 o.ä.); 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 indexseq. 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 (seq., indexseq., Hash) kennen und beim
Zugriff berücksichtigen
Datenabhängigkeit
Speicherungsstruktur abhängig
Probleme bei Änderung der Art der Abspeicherung
Datenbanksysteme 1

27
• Hohe Verfügbarkeit der Daten
nicht o.k., weil:
- Was passiert bei Datenverlust auf der Platte („Datei kaputt, Platte
kaputt“)?
- Was passiert im Fall der Datenreorganisation, wenn z.B.
Hashdatei vergrößert werden muss?
• Hohe Flexibilität bei Datenzugriff/-auswertung, integrierte
Auswertbarkeit
Bei Nutzung von Dateisystemen definitiv nicht gegeben: Jeweils
neue, 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 Programm „zu Fuß“ machen
• Hohe Flexibilität bzgl. der Datenverteilung
plus integrierte Auswertbarkeit: 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 1
28
• Hohe Flexibilität bzgl. der Lastverteilung
I.d.R. gehen Zugriffe zu einem Datenbestand über einen Rechner
 falls Datenbestand (Datei) „hot spot“, somit auch Rechner „hot spot“
• Hohe Benutzerfreundlichkeit/mächtige, leicht erlernbare
Abfragesprache
Bei Dateisystem in keiner Weise gegeben, von „Abfragesprache“
kann hier nicht die Rede sein
• Sicherheit vor Datenverlust
Zurück auf letzte Sicherungskopie der Datei („backup“), falls vorhanden  unbefriedigend
• Sicherheit vor unberechtigtem Zugriff/Verändern
Festlegung für Datei insgesamt möglich mit Rechtevergabe, nicht
aber werteabhängig (warum nicht?)  Kenntnis an Datensemantik
fehlt im Dateisystem
Datenbanksysteme 1
29
• Paralleler Zugriff mehrerer Benutzer
Lesend (natürlich) kein Problem, modifizierend (ändern, einfügen,
löschen) wird entweder durch Sperren der gesamten Datei
(zuständig: Dateisystem) unterbunden oder liefert potentiell Chaos 
unkontrolliertes Überschreiben von Datensätzen
Hinweis: Was fehlt – und was Datenbanksysteme haben! – ist das
sog. TRANSAKTIONSKONZEPT & Synchronisationsmechanismen
• Hoher Grad an semantischer Integrität
Dateisysteme kennen fast keine Datensemantik, können somit auch
nichts bieten hinsichtlich Fehlererkennung oder gar „aktive
Mechanismen“ hierfür bereitstellen
• Hoher Grad an Datenunabhängigkeit
siehe Problemszenarium aus Kap. 1.2 (strukturelle Änderung im
Datenbestand  Anwendungsprogramme müssen angepasst werden)
Oder auch: Abhängigkeit vom Vorhandensein oder
Nichtvorhandensein einer bestimmten Dateiorganisationsform
Oder: Abhängigkeit von / Vertrauen auf eine/r bestimmte/n Sortierfolge
in der Datei
 Dateisysteme bieten keine Datenunabhängigkeit!
Datenbanksysteme 1
30
Zusammenfassung / Abschlussbetrachtung zum Thema
„Nutzung von Dateisystemen“
Diskussion in Kap. 1.3 hat gezeigt:
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 durchaus: in Bezug auf Effizienz kann zugeschnittene, dateibasierte
Lösung einer (allgemeineren) datenbankbasierten Lösung überlegen sein:
manche CAD-Systeme, Geodatenverwaltungssysteme etc. verwenden
nach wie vor dateibasierte Datenverwaltung!
Datenbanksysteme 1
31