Einf. Datenbanken
Werbung
Einführung in das Fach Datenbanken Holger Jakobs – [email protected], [email protected] 2008-03-25 Inhaltsverzeichnis 1 Warum werden Datenbanken eingesetzt? 1 2 Was wird in einer Datenbank gespeichert? 3 3 Datenunabhängigkeiten 4 4 Datenschemata eines DBMS 4 5 Architektur eines DBMS 5 6 Abarbeitung eines Zugriffswunsches 6 1 Warum werden Datenbanken eingesetzt? Daten fallen in Unternehmen in immer größeren Mengen an und müssen jederzeit an verschiedenen Orten zur Verfügung stehen, auch in unterschiedlicher Darstellung. Schließlich ist Information seit langem ein wesentlicher Produktionsfaktor geworden. Wenn mehrere Personen Zugriff auf dieselben Daten haben wollen, ohne diese mehrfach (redundant) vorrätig zu halten, bedienen sie sich eines Rechnersystems. Aber mit Hilfe einfacher Dateien sind die Probleme nicht leicht lösbar, sondern man benötigt Datenbanksysteme, um alle Bedingungen erfüllen zu können: Ist es sichergestellt, dass meine Daten immer aktuell allen anderen Anwendern zur Verfügung stehen? Denken Sie nur an die Preise bei Internet-Auktionen. Ist es sichergestellt, dass meine Daten immer konsistent, d. h. widerspruchsfrei sind? Hierzu ist es notwendig, dass es unmöglich gemacht wird, widersprüchliche Daten ins System einzutragen. Das wären beispielsweise zwei verschiedene Rechnungsadressen beim selben Kunden. Ebenso muss verhindert werden, dass ein Kunde gelöscht wird, der noch offene Rechnungen hat. Kann jede(r) auf die Daten zugreifen, die er/sie für die Arbeit benötigt, aber nicht auf Daten die ihn/sie nichts angehen? 1 1 WARUM WERDEN DATENBANKEN EINGESETZT? Ist es sichergestellt, dass nicht mehrere Personen gleichzeitig auf dieselben Daten schreibend zugreifen, ohne dass immer der gesamte Datenbestand gesperrt werden muss? Ist trotzdem gleichzeitiges Lesen möglich? Kann jede(r) die Daten so präsentiert bekommen, wie er/sie sie benötigt? Können verschiedene Personen verschiedene Sichten auf dieselben Daten bekommen? Können Anwendungen hardware- und betriebssystemunabhängig programmiert werden, so dass bei einem Plattformwechsel die Daten und Programme weiterverwendet werden können? Ist es möglich, die physische Speicherorganisation nachträglich zu ändern, ohne dass sich an der logischen Struktur der Datenbank etwas ändert? Laufen alle Programm danach noch problemlos? Steigt der Pflegeaufwand nicht überproportional an, so dass man auch nach Jahren noch Neu-Entwicklung betreiben kann und nicht in der Pflege des bestehenden Systems ertrinkt? Sind Ad-hoc-Abfragen möglich, d. h. kann man die Daten auf bislang nicht vorhergesehene Art verknüpfen, ohne daraus ein mehrwöchiges Projekt zu machen? James Martin definiert den Begriff Datenbank in seinem Buch Einführung in die Datenbanktechnik so: Eine Sammlung von Daten, die von verschiedenen Programmierern verwendet werden kann, wird Datenbank genannt. Wir definieren sie als eine Sammlung von inhaltlich zusammenhängenden Daten, die mit kontrollierter Redundanz abgespeichert werden, um für eine oder mehrere Anwendungen in optimaler Weise verwendbar zu sein. Die Daten werden so abgespeichert, dass sie unabhängig von den Programmen sind, von denen sie benutzt werden. Eine allen gemeinsame und kontrollierte Lösung wird für das Hinzufügen, das Modifizieren und Abfragen gespeicherter Daten der Datenbank benutzt. Ein System kann mehrere Datenbanken enthalten, wenn jede für sich eine eigenständige, von den anderen verschiedene Datenstruktur hat. Eine Datenbank wird von einem Datenbankverwalter (database administrator) eingerichtet und gepflegt. Diese spezielle Tätigkeit ist notwendig, weil ein Datenbanksystem schnell so umfangreich und komplex wird, dass man allein für die Pflege des Systems – also ohne die Programmierung der Anwendungen – einen oder mehrere Mitarbeiter benötigt. Bei kleinen Systemen kann das vom allgemeinen Systemverwalter mit erledigt werden. Der Datenbankverwalter ist eine Art Treuhänder der Daten. Er vergibt Rechte an den Daten an die Programmierer und Anwender. Er ist auch dafür verantwortlich, dass das System optimal genutzt werden kann, weil abhängig vom Entwurf der Datenstrukturen die Performance sehr stark schwanken kann. Die genormte Datenbanksprache SQL hat einen großen Anteil an der Erfüllung der oben aufgestellten Forderungen. Sie ist weit verbreitet, weshalb Wissen in SQL auf fast allen Systemen hilfreich ist, und sie verspricht auch noch in vielen Jahren vorhanden und nützlich zu sein. 2 2 WAS WIRD IN EINER DATENBANK GESPEICHERT? 2 Was wird in einer Datenbank gespeichert? In einer Datenbank werden Informationen über Objekte in Tabellen gespeichert. Ein Objekt kann ein Gegenstand sein, z. B. ein Artikel, oder etwas Nichtgegenständliches, z. B. ein Konto, ein Auftrag oder ähnliches. Ein Objekt hat verschiedene Merkmale oder Attribute, die gespeichert werden sollen. Für ein Objekt wird ein Datensatz (Tupel) angelegt, der aus Feldern (Attributen) besteht. In der Tabelle wird in jedem Feld die Ausprägung eines Merkmals gespeichert. Die Felder (Attribute) haben bestimmte Datentypen. Dazu gehören z. B. folgende: alphanumerische Zeichen (Zeichenkette) mit fester und variabler Länge ganze Zahlen (integer) gebrochene Zahlen, z. B. Gleitkommazahlen (double, real) und Festpunktzahlen (decimal) logische Werte (bool) (nur im SQL3-Standard, noch nicht überall verfügbar) Kalenderdatumswerte Uhrzeitwerte, z. T. mit Zeitzonenangabe Zeitstempelwerte (Datum & Uhrzeit), z. T. mit Zeitzonenangabe Natürlich kann es über diese grundlegenden Datentypen hinaus noch weitere geben, z. B. für IP-Adressen oder geografische Koordinaten. Die Verwendung von Datentypen ist schon die erste Konsistenzprüfung für die Daten. Falls also unmögliche Werte von einem Frontend geliefert werden, können diese vom Datenbanksystem entdeckt und abgewiesen werden, beispielsweise Buchstaben in einem reinen Zahlenfeld oder aber ein ungültiges Datum wie der 30. Februar. Der Verzicht auf Datentypen, so wie das in den meisten Scriptsprachen üblich ist, wäre also für ein Datenbanksystem ein schwerer Nachteil. Die Form, in der die Daten tatsächlich physikalisch gespeichert werden, ist nicht notwendigerweise dieselbe Form, in der sie dem Anwendungsprogramm übermittelt werden. Die Sicht des Anwendungsprogrammierers kann viel einfacher und auf ihn zugeschnitten sein. Dem Anwendungsprogrammierer sollten die technischen Details auch völlig egal sein. Das Datenelement, das von der Datenbank benutzt wird, um einen Datensatz (Tupel) eindeutig zu identifizieren, wird als (Primär-)Schlüssel bezeichnet. Meist handelt es sich um ein Attribut, manchmal aber auch um eine Attributkombination. Bietet sich beim Entwurf der Datenbank kein geeigneter (natürlicher) Schlüssel an – wie beispielsweise die ISBN bei einem Buchtitel –, so vergibt man einen künstlichen Schlüssel, meist in Form einer laufenden internen Nummer. Wie Schlüssel technisch verwaltet werden, kann dem Anwendungsprogrammierer wieder egal sein. Er muss sich nur darauf verlassen können, dass ein Primärschlüssel in jedem Fall eindeutig ist. 3 4 DATENSCHEMATA EINES DBMS 3 Datenunabhängigkeiten Es wird Software eingesetzt, um zwei Arten der Datenunabhängigkeit zu erreichen. Zum einen soll die physikalische Datenorganisation von der globalen logischen Datenbeschreibung getrennt werden. Das bedeutet, dass die physikalische Organisation optimiert oder auch vollständig geändert werden kann, ohne dass die logischen Beschreibungen neu geschrieben werden müssen. (Bei vielen Datenbanken ist heute der Einfluss des Datenbankverwalters auf die physikalische Datenorganisation gering. Bei Oracle sind die Gestaltungsmöglichkeiten der physikalischen Datenorganisation dagegen sehr groß, um diese auszunutzen, sind aber sehr umfangreiche, Oracle-spezifische Kenntnisse notwendig, die man nur in Schulungen bei Oracle selbst erwerben kann und nicht Unterrichtsgegenstand sein werden.) Zum anderen sollen die logischen Datenbeschreibungen für die einzelnen Anwender und Anwendungen unabhängig sein von der globalen logischen Datenbeschreibung, so dass Änderungen bei einem Anwendungsprogramm keine Auswirkung auf eine anderes haben. Veränderungen der globalen logischen Struktur sollen auch keine Auswirkung auf bestehende Programme haben – soweit es keine logischen Gründe gibt, hier Änderungen vorzunehmen. Ein Beispiel hierfür ist die Erweiterung der Kundentabelle um das Feld E-Mail-Adresse. Dies führt nicht zu einer Änderung am Programm, das Serienbriefe an die postalischen Adressen schreibt. 4 Datenschemata eines DBMS Bei einem Datenbank-Management-System (DBMS) gibt es verschiedene Schemata, die die Daten beschreiben. Zunächst wird immer das konzeptionelle Schema entworfen, d. h. die logische Gesamtsicht. Das ist die Sicht des Datenbankverwalters. Sie enthält alle Tabellen, Indexe, Schlüssel, Beziehungen usw. Für die anderen Benutzer gibt es – gruppenweise oder auch individuell – externe Schemata, sogenannte Anwendersichten. Einige Anwender werden nur eine Teilmenge der Kunden sehen, z. B. sehen die Handelsvertreter nur die Daten von Kunden aus ihrer eigenen Region, während die Mitarbeiter im Call Center nur die Telefonnummern der Kunden, nicht aber die postalischen Anschriften sehen. Die Geschäftsleitung möchte keine Detaildaten, sondern nur kumulierte Daten sehen, d. h. nur Umsatzsummen pro Region, aber keine Einzelaufträge von Kunden. Bei der Implementation eines Datenbankentwurfs werden neben den logischen Datenbeschreibungen auch Angaben über die physikalische Art der Speicherung gemacht, z. B. auf welcher Platte die Daten abgelegt werden, welche Indexe angelegt werden usw. Dies ändert an der logischen Struktur überhaupt nichts, kann aber für den Datendurchsatz und auch für die Datensicherheit sehr wichtig sein. Dies geschieht im internen Schema. Zwischen den einzelnen Sichten wird mit Hilfe von Software eine Umsetzung vorgenommen. Die einzelnen Sichten können durchaus geändert werden, ohne das zwangsläufig an den anderen Sichten sich etwas ändern muss. 4 5 ARCHITEKTUR EINES DBMS Abbildung 1: Datenbank-Schemata externes Schema 1 externes Schema 2 Schnittstelle externes Schema ... externes Schema N <−> konzeptionelles Schema konzeptionelles Schema (logische Gesamtsicht) Schnittstelle konzeptionelles Schema <−> internes Schema Datenbank− Management− System (DBMS) internes Schema Schnittstelle internes Schema <−> Datenspeicher physikalischer Speicher der Datenbank Auch bei einfachen Dateisystemen gibt es unterschiedliche Sichten der Daten. Technisch sind die Daten einer Datei bei Unix in Sektoren auf der Platte untergebracht, d. h. in Stücken fester Länge. Diese Stücke sind nicht zusammenhängend, sondern evtl. kreuz und quer über die Platte verteilt. Aus Sicht eines Programmierers ist eine Datei aber ein konstanter Strom von Bytes, dessen Länge auch kein Vielfaches der Sektorgröße sein muss. Auch hier ist eine Software für die Umsetzung zwischen den Sichten verantwortlich: das Unix-Dateisystem (vgl. Schichtenmodell des Unix-Betriebssystems). 5 Architektur eines DBMS Datenbanken sind heute üblicherweise nach dem Client-Server-Modell konstruiert, d. h. es ist nicht ein einziges, monolithisches Programm, in dem sowohl Anwendungsprogrammierung als auch Datenspeicherung vorgenommen wird. Vielmehr gibt es ein sogenanntes Frontend und ein Backend, wobei diese einzeln austauschbar sind, sofern eine genormte Schnittstelle zwischen beiden verwendet wird. Das Backend läuft auf dem Datenbankserver und greift direkt auf die Platte mit den Daten zu. Das kann über das Dateisystem geschehen oder aber auch direkt auf einen reservierten Bereich einer Platte, einer separaten Datenbank-Partition. Letzteres hat den Vorteil der höheren Performance, dafür muss eine ganze Partition der Platte hierfür zur Verfügung gestellt werden, was die Flexibilität stark einschränkt. Über ein Rechnernetz wird der Dienst des Backends dem Frontend zur Verfügung gestellt, heute üblicherweise über TCP/IP. Das Frontend läuft auf dem Anwendungsrechner und 5 6 ABARBEITUNG EINES ZUGRIFFSWUNSCHES stellt die Daten dem Anwender dar. Das Frontend kann ein Standardprogramm sein, das beim DBMS mitgeliefert wird, ein anderes Standardprogramm oder aber ein ganz spezielles Anwendungsprogramm mit Datenbank-Anbindung. Solche Programme werden häufig mit Embedded SQL geschrieben, d. h. die SQL-Anweisungen werden in eine klassische Programmiersprache, z. B. C oder C++, eingebettet. Für Java und für Scriptsprachen gibt es ähnliche Lösungen, so dass auch dort SQL-Anweisungen im Programm der gewöhnlichen Programmiersprache vorkommen können. Auch Office-Programme wie OpenOffice.org und Microsoft Office können über genormte Schnittstellen auf alle gängigen Datenbanksysteme zugreifen, um Serienbriefe und Reports zu erzeugen. Mit OpenOffice.org Base“ und Microsoft Access“ können sogar komplette ” ” Datenbank-Anwendungsprogramme geschrieben werden. Neben den auf dem Desktop laufenden Programmen sind viele Anwendungen auch als Web-Anwendungen realisiert, d. h. das Frontend läuft auf einem Webserver, die Darstellung für den Anwender geschieht aber wiederum über ein Rechnernetz innerhalb eines Browserfensters. Mit Hilfe neuerer Techniken wie Ajax“ können diese Anwendungen sogar recht ” anwenderfreundlich sein. Die ältere Technik der Einbettung einer kompletten Anwendung in ein Java-Applet, das im Browserfenster läuft, hat sich nicht in dem Maße wie erwartet durchgesetzt, wird aber immer noch verwendet und ist auch gar nicht schlecht. Abbildung 2: Client-Server-Architektur Frontend übers Netz Backend Natürlich können Backend und Frontend auch auf ein und demselben Rechner laufen, wie das bei Linux-Workstations oft der Fall ist. Bei größeren Datenbanken läuft das Backend auf einem dedizierten Server. Die Schnittstelle zwischen beiden ist manchmal eine proprietäre Schnittstelle, manchmal aber auch etwas Standardisiertes wie ODBC (Open DataBase Connectivity) oder JDBC (was offiziell keine Abkürzung ist). 6 Abarbeitung eines Zugriffswunsches Die Aktionen eines DBMS bei Abarbeitung eines Zugriffswunsches sind folgende 1. Entgegennahme des Zugriffswunsches 2. Interpretation des Wunsches: Holen der Definition aus dem zugehörigen externen 6 6 ABARBEITUNG EINES ZUGRIFFSWUNSCHES Schema und Ermitteln der entsprechenden Definition aus dem konzeptionellen Schema mit Hilfe der Transformationsregeln externes → konzeptionelles Schema“. ” 3. Ermitteln der zu lesenden physischen Objekte entsprechend der Transformationsregeln konzeptionelles → internes Schema“ und der Zugriffspfade dorthin. ” 4. Ermitteln der Seite, auf welcher die gesuchten Daten gespeichert sind. Prüfen, ob diese bereits im Systempuffer sind. Falls ja, weiter bei 8. 5. Auswahl einer Seite im Systempuffer, die überschrieben werden kann. Falls diese verändert wurde, vorher zurückschreiben. 6. Aufruf des Betriebssystems für (ggf.) Seite aus 5 zurückschreiben“ und Einlesen der ” ” neuen Seite“ 7. Laden der Seite in den Systempuffer durch das Betriebssystem 8. DBMS sucht die gewünschten Daten in der geladenen Seite, transformiert sie gemäß dem externen Schema in die passende Form und überträgt sie in den Arbeitsbereich des Anwendungsprogramms (sogenannte Communication Area). 9. Wiederholen der Schritte 3 bis 8, bis alle gewünschten Daten geholt wurden. 10. Hinterlegen der Statusinformation über den Ausgang der Operation im Arbeitsbereich des Anwendungsprogramms. 11. Dialog- bzw. Anwendungsprogramm kann die Daten weiter verarbeiten. $Id: einf_dab.tex,v 1.2 2008-03-25 09:02:16 hj Exp $ 7
