Datenbanksysteme 1 - Fakultät für Mathematik und Informatik
Werbung
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
