1 Einführung in Datenbanken
1.1 Zweck von Datenbanken
Kernaufgaben von Datenbanksystemen ist die Speicherung und Verwaltung von großen Datenbeständen. Nehmen Sie das Beispiel in Tabelle 1.1 dargestellte Szenario der Verwaltung von Hochschuldaten. Daten von Studenten, Vorlesungen und die zugehörige Einschreibung sind in verschiedenen Tabellen organisiert. Auf diesen Daten müssen verschiedene Operationen durchgeführt werden, welche durch das Akronym CRUD charakterisiert werden.
C reate (Erzeugen neuer Datensätze)
R ead (Lesen vorhandener Datensätze)
U pdate (Ändern/Aktualisieren von Bestandsdaten)
D elete (Löschen nicht mehr benötigter Datensätze)
Beispielsweise könnte es erforderlich sein alle Vorlesungen auszugeben (READ), einen Studierenden in eine Veranstaltung einzuschreiben (UPDATE), einen Studierenden bei der Immatrikulation neu anzulegen (CREATE) oder Vorlesungen zu löschen (DELETE), weil sie vielleicht nicht mehr angeboten werden.
Tabelle 1.1: Beispiel Hochschuldatenbank
| Mtr | Vor- name | Nach- name |
|---|---|---|
| 26123 | Peter | Müller |
| 21098 | Klara | Maier |
| 22347 | Katrin | Jensen |
| Nr | Vorlesung |
|---|---|
| 1 | Datenbanken |
| 2 | OOP |
| 3 | Algorithmen |
| Mtr | Vorlesung |
|---|---|
| 26123 | 1 |
| 21098 | 2 |
| 22347 | 2 |
1.2 Dateiorganisation vs. Datenbanksystem
1.2.1 Dateiorganisation
Historisch betrachtet entstand der Bedarf an der Speicherung von Daten im Versuch betriebliche Abläufe zu automatisieren, indem meist hochspezialisierte Anwendungen (Computerprogramme) für bestimmte Geschäftsbereiche entwickelt wurden. Jede dieser Anwendungen legte die Daten in einem zumeist eigenen (proprietären) Format zur dauerhaften Speicherung in einer Datei im Dateisystem ab. Um Daten von einer Anwendung in eine andere übertragen zu können, ist ein Konverterprogramm notwendig.
Im Falle des betrachteten Beispiels einer Hochschulverwaltung könnte es also drei Anwendungen geben (z.B. Studierendenservice, Prüfungsamt, Hochschulbibliothek), welche ihre jeweiligen Daten (z.B. Adressdaten der Studierenden) in jeweils einer Datei ablegen (siehe Abbildung 1.1). Jede dieser Dateien enthält dieselben Informationen in unterschiedlichen Formaten und ggf. unterschiedlicher Aktualität. Wenn beispielsweise ein Studierender umzieht und seine neue Adresse dem Studierendenservice meldet, bleiben die Adressdaten der beiden anderen Anwendungen unverändert. Wir erhalten inkonsistente Daten. Ähnliches kann passieren, wenn der Mitarbeiter der Bibliothek Daten mit anderen Schreibweisen erfasst.
Diese Architektur ermöglicht eine hohe Effizienz bezüglich des Datenzugriffs in den eigenen Dateien, unterliegt aber erheblichen Nachteilen:
Redundanz: Jedes System (Anwendung) speichert eine eigene Kopie von Daten, die von unterschiedlichen Anwendungen verarbeitet werden. Aufgrund unterschiedlicher Formate der gespeicherten Daten werden Konverterprogramme gebraucht, die jeweils Daten eines Quellformates in ein Zielformat überführen. Will man also alle Anwendungen vollständig vernetzen, braucht man \(n*(n-1)\) Konverter. Für unser Minibeispiel mit nur drei Anwendungen würden wir demnach schon sechs Konverter benötigen.
Abhängigkeit von der physischen Datenstruktur: Jede Änderung der Datenstruktur zieht, aufgrund des unmittelbaren Zugriffs auf die zugehörige Datei, eine Änderung des Anwendungsprogrammes nach sich.
Fehlende Parallelisierbarkeit: Parallele Zugriffe mehrerer Nutzer derselben Anwendung oder unterschiedlicher Anwendungen mit demselben Datenformat sind ausgeschlossen, da es keinen koordinierten Zugriff auf die jeweilige Datei gibt.
Fehlende Mechanismen für Datenkonsistenz, Zugriffsschutz und Recovery: Jede Anwendung ist selbst verantwortlich für die konsistente Speicherung der Daten, den Schutz der Daten vor unbefugtem Zugriff und die Wiederherstellung nach Soft- oder Hardwareausfällen.
1.2.2 Datenbanksystem (DBS)
Um die Probleme der Dateiorganisation zu lösen, gibt es in Datenbanksystemen ein Datenbank-Managementsystem (DBMS), welches als Schnittstelle und Koordinator zwischen unterschiedlichen Anwendungen und der eigentlichen Datenbank (DB), welche die physische Datenablage realisiert, fungiert.
Eine Datenbank (engl. Data Base - DB) ist eine Sammlung von strukturierten Daten, zwischen denen sachlogische Zusammenhänge bestehen. (Jarosch 2010, 19)
Ein Datenbank-Managementsystem (engl. Data Base Management System – DBMS) ist ein Programmsystem, das die notwendige Software für alle Aspekte der Datenverwaltung bereitstellt. (Jarosch 2010, 20)
Abbildung 1.2 zeigt die Datenorganisation unseres Beispiels der Hochschulverwaltung mit einem DBS. Alle Anwendungen greifen jetzt auf denselben Datenbestand zu, sind aber physisch entkoppelt, denn jede Anfrage (CRUD) muss über das DBMS gestellt werden, dem die Aufgabe eines Vermittlers und Koordinators zukommt. Nur das DBMS kennt die Struktur der Daten in der DB. Die Kommunikation der Anwendungssysteme mit dem DBMS erfolgt mittels einer normierten Sprachschnittstelle, der SQL (Structured Query Language) standardisiert als ISO/IEC 9075-1:2016.
Redundanzfreiheit: Daten werden nur einmal gespeichert und alle Anwendungssysteme greifen auf denselben Datenbestand zu.
logische Datenunabhängigkeit: Spezielle Anforderungen an Daten einzelner Anwendungssysteme sind entkoppelt von der physischen Struktur der Daten in der Datenbank.
Flexibilität: Logische Datenunabhängigkeit erlaubt es prinzipiell jeder Anwendung auf den gesamten Datenbestand zuzugreifen. (Rechte können aber eingeschränkt werden)
physische Datenunabhängigkeit: Änderungen an der physischen Datenstruktur (z.B. zur Effizienzsteigerung) haben keinen Einfluss auf die Anwendungssysteme, da diese nur auf die logische Datenstruktur zugreifen.
Mehrbenutzerbetrieb: Konkurrierende Zugriffe durch unterschiedliche Anwendungen oder Nutzer werden durch das übergeordnete DBMS koordiniert, so dass es nicht zu Konflikten kommen kann.
Datenintegrität: DBMS sichert die Vollständigkeit, Korrektheit und Widerspruchsfreiheit der Daten.
Zugriffsschutz: DBMS schützt die Daten vor unbefugtem Zugriff.
Recovery: DBMS stellt einen korrekten Datenzustand nach Ausfällen und Störungen infolge von Soft- oder Hardwarefehlern wieder her.
1.3 Architektur eines DBS
Schauen wir uns als nächstes die Abstraktionsebenen eines DBS an. Auf niedrigster Ebene, der physischen Ebene, wird definiert wie konkret die Daten auf dem Sekundärspeichermedium (z.B. Festplatte) abgelegt und strukturiert werden. Darüber, auf der logischen oder auch konzeptionellen Ebene, wird mittels Datenbankschema festgelegt, welche Daten gespeichert werden, wie diese charakterisiert sind (z.B. Text, Zahlen …) und wie diese miteinander in Beziehung stehen. An oberster Stelle befindet sich die Ebene der Sichten. Hier kann bestimmt werden, welche Nutzer für welche Anwedung welche Teilmengen der Daten sehen können. Abbildung 1.3 skizziert die soeben besprochenen Abstraktionsebenen.
Schauen wir uns die gerade diskutierten Abstraktionsebenen für unser Beispiel der Hochschulverwaltung an (siehe Abbildung 1.4). Auf physischer Ebene ist festgelegt, wie ein Student des DBS im Speicher als Bytes oder Words abgelegt wird. Auf logischer Ebene können wir festlegen, welche Attribute eines Studierenden in welcher Form erfasst werden (wir definieren den Inahlt der Tabelle). Auf Ebene der Sichten können wir beispielsweise festlegen, dass Bibliotheksmitarbeiter nur bestimmte Spalten der Tabelle sehen können.
Natürlich umfasst jede Ebene eine Vielzahl von Aufgaben, welche in der bisherigen vereinfachten Sicht zusammengefasst waren. Einen detaillierteren Überblick liefert Abbildung 1.5. Wir stellen fest, dass es auf physischer Ebene weit mehr zu tun gibt. Beispielsweise müssen Zugriffe protokolliert werden oder Indizes für schnellere Zugriffe geführt werden. Auch die logische Ebene hat einiges mehr an Komplexität zu bieten. Auf dieser Ebene arbeiten wir später, wenn wir mit SQL z.B. das Datenbankschema definieren oder Informationen abfragen.
SQL-Teil zur Beschreibung Änderung oder Entfernung von Datenstrukturen und verwandten Elementen.
SQL-Teil zum Schreiben, Lesen, Ändern oder Löschen von Datensätzen.
