Читать книгу Relationale Datenbanken - Josef Ludwig Staud - Страница 8

1 Einleitung

1.1 Aufbau des Buches, Gesamtüberblick

Im Mittelpunkt dieses Buches stehen Relationale Datenbanken - ihr Entwurf, ihre Modellierung, ihre Optimierung und ihre Einrichtung. Dies ist eingebettet in eine Darstellung des gesamten Weges, den die Informationen eines Anwendungsbereichs zurücklegen müssen, bis sie sich als Datenbank auf einem Speichermedium wiederfinden.

Anwendungsbereich und Konzeptionelle Modelllierung

In der Abbildung unten ist dieser Weg skizziert. Am Anfang (Position 1) ist der Anwendungsbereich. Er wird meist durch eine Wolke dargestellt. Die Auseinandersetzung mit dem Anwendungsbereich, das Gewinnen der für die Datenbank wichtigen Informationen, wird konzeptionelle Modellierung (conceptual modeling) genannt. Mit ihrer Hilfe werden Objekte und Objektklassen erkannt, Attribute gefunden und zugeordnet sowie Beziehungen geklärt. Vgl. dazu Kapitel 3.

Semantische Datenmodelle

Die konzeptionelle Modellierung führt zu einem semantischen Datenmodell (Position2). Mit einem solchen ist es möglich, Objekte, Beziehungen und Attribute unabhängig von einem konkreten Datenbanksystem zu beschreiben. Von den vielen, die in den letzten Jahrzehnten hierfür vorgeschlagen wurden, blieb nur das sog. Entity Relationship - Modell übrig. Seine Aufgabe ist eine erste mit viel Aussagekraft erstellte Modellierung. Oder auch eine für Überblicksnotationen.

Vgl. hierzu " http://www.staud.info/er/er_f_1.htm

Logisches Datenmodell

Im nächsten Schritt (Position 3) entsteht ein logisches Datenmodell. Damit werden Modelle bezeichnet, die einer bestimmten Datenbanktheorie und damit einem bestimmten Datenbanksystemtyp entsprechen. Dies sind heutzutage relationale und objektorientierte Datenbanksysteme und weitere, die neueren Ansätzen zur Datenverwaltung entsprechen (vgl. Kapitel 23). In diesem Buch stehen relationale Datenmodelle und Datenbanken im Vordergrund.

Mit der Erstellung des logischen Datenmodells ist die Struktur der künftigen Datenbank festgelegt. Also ein relationales Datenmodell oder auch ein objektorientiertes. Für diese Datenmodelle gibt es Datenbanksysteme, die mehr oder weniger gut das jeweilige Datenmodell (die jeweilige Theorie) unterstützen und seine Umsetzung erlauben. In diesem Buch konzentrieren wir uns auf Relationale Datenbanksysteme.

Datenbanken einrichten mit SQL

Nun gilt es, aufbauend auf dem logischen Datenmodell, die konkrete Datenbank mit einem geeigneten Datenbanksystem einzurichten (Position 4). Dies geschieht mittels der Masken und Menüs der grafischen Bedienoberflächen und - vor allem - mit einer formalen Sprache für das Einrichten, Befüllen, Verwalten und Auswerten der Daten. Bei Relationalen Datenbanksystemen ist dies SQL (vgl. Kapitel 19). Das Ergebnis dieser Bemühungen ist eine Datenbank.

In Kapitel 19 wird SQL beschrieben. Wegen der leichten Verfügbarkeit und gleichzeitig großen Leistungsstärke wurde dafür mySQL mit XAMPP gewählt.

Dateien auf peripheren Speichern - Physische Datenorganisation

Richtet man die relationale Datenbank ein, entstehen viele Dateien auf dem peripheren Speicher (heute meist Festplatten), in denen die Daten und die Verwaltungsinformation abgelegt sind (Position 5). Der grundsätzliche Aufbau dieser Dateien ist in den Kapiteln 20 und 21 beschrieben. Verwaltet werden diese Dateien von einem Teil des Betriebssystems, das Dateisystem (file system) genannt wird. Es nimmt die SQL-Befehle entgegen und setzt sie in Befehle für die sog. physische Datenorganisation um. Dabei nutzt es das sog. Festplattenverwaltungssystem.

Träger der jeweiligen Aktivität

Auf der rechten Seite der folgenden Abbildung ist angegeben, wer die jeweilige Aktivität umsetzt. Von 1 nach 2 ist Kompetenz in den Bereichen konzeptionelle und semantische Modellierung nötig. Geht es weiter nach 3, ist Kompetenz in logischer Datenmodellierung gefragt, heute also v.a. in relationaler oder in objektorientierter Modellierung (vgl. dazu [Staud 2019] und www.staud.info ==> Objektorientierung). Den Schritt nach 4, also die Einrichtung der Datenbank, übernehmen dann die die ganz normalen Datenbankspezialisten.

Datenbanksystem - Betriebssystem

Die nächsten Schritte bis zum physischen Speichermedium werden dann durch Anwendungssysteme realisiert. Durch das Datenbanksystem (database management system; DBMS; hier DBS) und das Betriebsssystem. Letzteres v.a. durch die in der Abbildung angeführten Komponenten Dateisystem (file system) und Festplattenverwaltungssystem (disk manager).

Abbildung 1.1-1: Der Weg vom Anwendungsbereich zur Datenbank und ihren Dateien

Obige Thematik wird, ergänzt um Kapitel zu „Modellierung, Speicherung, Alternativen“, in diesem Text betrachtet:

***Teil I - Grundlagen

2 Informationen, Daten, Attribute

3 Konzeptionelle Modellierung

***Teil II - Relationale Datenmodelle

4 Relationen bilden

5 Beziehungen erkennen und einrichten

6 Zusammenfassung Grundlagen

***Teil III - Optimierung des Datenbankentwurfs

7 Die erste Normalform (1NF)

8 Funktionale Abhängigkeiten

9 Die zweite Normalform (2NF)

10 Die dritte Normalform (3NF)

11 Die Boyce-Codd - Normalform (BCNF)

12 Die vierte Normalform (4NF)

13 Die fünfte Normalform (5NF)

***Teil IV - "Feintuning" und Vertiefung

14 Muster in Anwendungsbereichen und Modellen

15 Die Zeit in Datenmodellen und Datenbanken

***Teil V - Beispiele relationaler Datenmodelle

16 Modellierungsbeispiele mit Lösungsweg

17 Weitere Modellierungsbeispiele

***Teil VI - Datenbankpraxis

18 Von Attributen zu Datentypen

19 SQL - Eine Kurzeinführung

***Teil VII - Physische Datenorganisation

20 Vom Zeichen zur Datenbank

21 Dateitechniken

22 Speichermedien

***Teil VIII - Alternativen

23 Andere Datenmodelle

24 Nicht-konventionelle Datenbanken – NoSQL etc.

1.2 Hinweise zur Textgestaltung

Überblick durch Typographie

Was die zu beschreibenden Elemente in der Datenmodellierung angeht, kann man einen Ausgangspunkt und drei Modellebenen unterscheiden. Der Ausgangspunkt ist der zu modellierende Anwendungsbereich, manchmal auch Weltausschnitt genannt. Die erste Modellebene ist die der Attribute, durch die Objekte und Beziehungen beschrieben werden. Die zweite die Ebene der "kleinsten" Elemente im jeweiligen Ansatz, dies sind hier die Relationen. Die dritte Ebene ist die des gesamten Datenmodells. Um diesbezüglich im Text die Übersichtlichkeit zu erhöhen wird folgende typographische Festlegung getroffen:

• Bezeichnungen von Anwendungsbereichen werden etwas vergrößert, in Kapitälchen und in Arial gesetzt: HOCHSCHULE, PERSONALWESEN, WEBSHOP. In der Web-Version sind sie zusätzlich in roter Farbe gehalten.

• Bezeichnungen von Datenmodellen und Datenbanken sind in normaler Größe und in Arial gesetzt: Vertrieb , Zoo , WebShop , Datenbanksysteme (Markt für Datenbanksysteme). In der Web-Version zusätzlich in rot.

• Bezeichnungen von Relationen sind etwas verkleinert und in Arial gesetzt: Angestellte , Abteilungen , Projekte. In der Web-Version zusätzlich in rot.

• Bezeichnungen von Attributen sind etwas verkleinert, fett und in Arial gesetzt: Gehalt , Name , Datum . Bei zusammengesetzten Benennungen wird der nachfolgende Begriff wieder groß begonnen: PersNr (Personalnummer), BezProj (Bezeichnung Projekt).

• Ausprägungen von Attributen werden in normaler Größe und in Courier gesetzt, z.B. Müller für das Attribut Name .

Relationenbezeichnung. Für die Relationen wird bei der Bezeichnung immer die Mehrzahl gewählt, da ja in der Regel mehrere Objekte bzw. Beziehungen erfasst sind. Für die in den Beispielen oft benutzten Personal Computer gilt: als Relationenbezeichnung wird PC verwendet, ansonsten (im Text) für die Mehrzahl "PCs".

1.3 Datenbanken

Digitale Abbilder, Immer mehr Daten, immer mehr Datenbanken

Unsere digitale Welt erzeugt Daten in einem Umfang, den man sich in früheren Zeiten nicht vorstellen konnte. In den Unternehmen werden die Geschäftsprozesse immer intensiver durch Anwendungssysteme begleitet, was automatisch zu großen Datenbeständen führt. Die Internetunternehmen bedienen uns mit vollautomatisierten Geschäftsprozessen und mit einem ausgefeilten Kundenbeziehungsmanagement (CRM; Customer Relationship Management), beides ist ohne umfassende Datenbasis nicht möglich. Im Internet sorgen wir durch Nutzung des SocialWeb für Datenbestände, die (nicht nur durch Geheimdienste) abgespeichert und intensiv untersucht werden. Und auch im privaten Bereich entstehen immer mehr Daten (Bilder, Viedeosequenzen, Texte, …), worauf die Industrie mit Festplatten antwortet, die inzwischen mehrere Terabyte fassen können.

Digitale Parallelwelt. Überall also Daten und damit überall Datenbanken. Um den größeren Bogen zu spannen: Die Vermessung der Welt ist inzwischen einen Schritt weiter. Sie erfasst jetzt auch Interaktionen und Aktivitäten und geht in Richtung Widerspiegelung der Welt in digitalen Datenbeständen. Es gibt eine digitale Parallelwelt, die im Internet, aber nicht nur dort erzeugt wird.

Relationale Datenbanksysteme

Ein Teil dieser Daten ist so strukturiert (vgl. die folgenden Kapitel), dass er in Relationalen Datenbanken abgespeichert werden kann. Um diese und um ihr "Umfeld" geht es in diesem Buch. Kurz gesagt, bedeutet dies, dass die Daten durch Attribute strukturiert und in verknüpfte Tabellen gefasst sind, die sich (meist) jeweils in einer Datei widerfinden. Zumindest für die Datenbestände von Unternehmen und sonstigen Organisationen ist dies der wichtigste Datenbanktyp. Es gibt aber inzwischen viele andere, sie werden im Kapitel 24 kurz vorgestellt.

Dateisysteme vs. Datenbanksysteme. Jede Programmiersprache erlaubt das Anlegen von Dateien. Große, kleine, für unterschiedlichste Daten, mit unterschiedlichem Aufbau. Deshalb stellt sich die Frage: Benötigt man überhaupt Datenbanken, reichen nicht Dateien völlig aus? Es gibt ja auch Softwaresysteme, die es erlauben, einzelne Dateien einzurichten und zu verwalten, die sog. Dateisysteme Nun, einzelne Dateien reichen heute nicht mehr aus, denn sie können jeweils nur einen bestimmten eher kleinen Anwendungsbereich erfassen. Die meisten Anwendungsbereiche sind aber sehr viel umfangreicher. Eine integrierte prozessorientierte Software (ERP-Software, vgl. [Staud 2006] oder www.staud.info ==> ERP-Software) wie die von SAP enthält z.B. in ihrer Datenbank Informationen zu allen Aspekten des Unternehmens, man spricht da auch von einer unternehmensweiten Datenbank. Aber auch kleinere Anwendungsbereiche, z.B. die Beschaffung oder der Vertrieb eines Unternehmens, die Studierenden einer Hochschule oder die Daten eines Sportvereins können nicht alleine in einer Datei verwaltet werden.

Diese Komplexität der Daten rührt u.a. daher, weil die Daten die Geschäftsprozesse der Organisationen unterstützen sollen und in diesen sehr viele Aspekte der Geschäftstätigkeit eine Rolle spielen, z.B. Kunden, Lieferanten, Produktion, Artikel, usw.

Anwendungsbereiche - Realität und Modell

Jetzt wird es Zeit, den schon mehrfach benutzen Begriff Anwendungsbereich näher zu klären. Datenbanken speichern, wie oben beschrieben, die Datenbestände, die in der Weltgesellschaft und -wirtschaft entstehen und die zu irgendeinem Zweck aufbewahrt werden sollen. Sie stellen damit immer ein abstrahiertes Abbild der Realität dar. Irgendeiner Realität. Da es sich immer nur um Teilbereiche handelt, sind dafür Begriffe wie Anwendungsbereich, Weltausschnitt (slice of reality) und Miniwelt (bei Autoren mit Kontakt zur Künstlichen - Intelligenz - Forschung) in Gebrauch. In diesem Buch wird der Begriff Anwendungsbereich verwendet.

Anwendungsbereiche können Abteilungen von Unternehmen ("Datenbank für den Vertrieb”) oder auch (fast) ganze Unternehmen sein (z.B. bei ERP-Software). Sie können aber auch durch eine einzelne Aufgabe definiert sein, z.B. "Daten für die Absatzprognose" oder "Daten für die neue Web-Präsentation des Unternehmens".

Es soll hier nicht verschwiegen werden, dass es auch außerhalb des attributbasierten Bereichs, in dem wir uns hier bewegen, Weltausschnitte mit faszinierenden anderen Informationsarten gibt, z.B. in der Chemie mit chemischen Strukturformeln, in der Physik oder auch Ökonometrie (vgl. die Zeitreihendatenbanken der entsprechenden Anbieter).

Hier einige Beispiele für Anwendungsbereiche:

• Alle Aspekte eines Unternehmens mit dem Ziel, dem Leitungspersonal ständig zentrale Kennziffern des Unternehmens zur Verfügung zu stellen.

• Buchungen in einer internationalen Hotelkette mit dem Ziel, möglichst in Realzeit einen Überblick über die Belegungen zu haben.

• Chemische Strukturformeln mit dem Ziel, die Suche nach Stoffen und Teilstoffen zu ermöglichen.

• Das Social Web mit seinen Aktivitäten. Ziel ist hier vor allem, diese Aktivitäten durch entsprechende Datenbanken möglich zu machen. Andere Ziele sind hier das Gewinnen von Nutzerprofilen, sei es für Versicherungsunternehmen oder für Geheimdienste.

• Ein ganzes Unternehmen, bzw. eine ganze Organisation. Die dabei entstehende umfassende Datenbank dient als Grundlage einer ebenso umfassenden prozessorientierten integrierten Standardsoftware (ERP-Software), d.h. als Grundlage einer umfassenden Modellierung der Geschäftsprozesse einer Organisation.

• Finanzwesen eines Unternehmens mit dem Ziel, die finanzielle Seite der Leistungserbringung deutlich zu machen.

• Lehrbetrieb einer Hochschule mit dem Ziel, die Lehre zu organisieren und zu dokumentieren.

• Personalwesen eines Unternehmens mit dem Ziel, den Personaleinsatz zu erfassen und notwendige Aktivitäten (z.B. die monatliche Gehaltszahlung) zu ermöglichen.

• Private Sammlung von Filmen mit dem Ziel, immer einen vollständigen Überblick zu haben.

• Produktionsbereich eines Unternehmens mit dem Ziel, Daten für ein Produktionsplanungssystem zur Verfügung zu stellen.

Die Liste könnte beliebig fortgesetzt werden.

1.4 Logische Datenmodelle, Datenorganisation

Abstrahiertes Abbild der Realität

Oben wurde es schon angedeutet: Grundlage einer jeden Datenbank ist ein sog. Datenmodell. Dieses stellt ein abstrahiertes Abbild eines Anwendungsbereichs oder Weltausschnittes dar. "Abstrahiert" deshalb, weil von der vielschichtigen Realität nur die Strukturen aufgenommen werden, die für die Anwendung benötigt werden. Etwa so, wie es bei den konzeptionellen Überlegungen festgelegt wurde.

Datenmodelle sind theoriespezifisch. D.h., sie werden mit Hilfe eines Instrumentariums erstellt, das eine Datenbanktheorie zur Verfügung stellt. Z.B. die relationale Datenbanktheorie, die objektorientierte oder die für die semantische Modellierung. Die relationale Theorie wird im weiteren hier vorgestellt.

Nach Fertigstellung werden Datenmodelle mit Hilfe des entsprechenden Datenbanksystems in eine Datenbank umgesetzt. Diesen Zusammenhang veranschaulicht die folgende Abbildung.

Abbildung 1.4-1: Vom Weltausschnitt zur Datenbank

Zusammenfassung

Ein Datenmodell ist ein Abbild des jeweiligen Weltausschnitts, das mit den Mitteln und gemäß den Regeln des jeweiligen datenbanktheoretischen Ansatzes realisiert wurde und das mit Hilfe eines Datenbanksystems in eine Datenbank umgesetzt wird.

Datenmodelle sind also ein Werkzeug, um mit Hilfe eines Datenbanksystems Datenbanken einzurichten.

Festlegungen. Die Nutzung eines Instruments gibt einerseits viele Möglichkeiten, bringt andererseits immer auch Einschränkungen mit sich. Der jeweilige datenbanktheoretische Ansatz legt fest, was wir erfassen können, mit welchen Mitteln wir dies tun und wie das Ergebnis aussieht. Hier nur einige sehr allgemeine Festlegungen, die spezifischen werden in den einzelnen Kapiteln diskutiert:

• Die meisten heutigen Datenmodelle sind attributbasiert, d.h. sie erfassen den Anwendungsbereich durch die Zuweisung von Attributsausprägungen zu Objekten und zu Beziehungen zwischen Objekten. Dies ist im Kern auch so, wenn von Name/Wert-Paaren oder Key/Value-Paaren die Rede ist, wie in der Diskussion rund um NoSQL und BigData (vgl. Kapitel 24).

• Die meisten heutigen Datenmodelle gehen im Kern von Objekten und Beziehungen aus, die im Anwendungsbereich gesucht und beschrieben werden.

Weiter legt das Datenmodell als Methode fest, was wir von den sonstigen Strukturen und Regeln des Anwendungsbereichs - der Semantik - erfassen können. Diese semantischen Integritätsbedingungen (constraints) schränken die Operationen ein, die auf den Daten erlaubt sind.

Bis zum Aufkommen der objektorientierten Modellierung galt außerdem, dass ein Datenmodell nur Strukturen (statische Aspekte) erfasst, nicht "Verhalten" (dynamische Aspekte).

1.5 Relationale Datenbanksysteme

Die Software für das Einrichten, Befüllen, Betreiben und Auswerten von Datenbanken wird Datenbanksystem genannt. Im Falle von Relationalen Datenbanken dann entsprechend Relationales Datenbanksystem (RDBS). Der Begriff "relational" kommt von der zugrundeliegenden Theorie, die zu einem relationalen Datenmodell führt, das im folgenden intensiv betrachtet wird. Es besteht aus verknüpften Tabellen einer bestimmten Struktur. Damit entsteht ein integrierter Datenbestand, die Datenbank. Ein korrektes relationales Datenmodell beschreibt a) alle benötigten Daten redundanzfrei und erfasst b) die Beziehungen zwischen den Daten, wobei in relationalen Datenmodellen die "Beziehungen" v.a. Verknüpfungen zwischen den Relationen sind.

Ohne Theorie geht es also bei der Verwaltung von Daten ganz grundsätzlich nicht. Die effiziente Speicherung von Informationen benötigt sie. Andere zu Datenbanken führende Theorien führen zu objektorientierten Datenbanken, zu spaltenorientierten (vgl. Abschnitt 24.3), zu multidimensionalen (vgl. Abschnitt 24.2), usw., früher auch zu Hierarchischen- und Netzwerk-Datenbanken.

Theorie + zugehörige Software ==> Datenbanken

Somit entstehen Relationale Datenbanken mit Hilfe der in den Kapiteln 4 bis 15 vorgestellten relationalen Theorie, relationale Datenmodellierung genannt. Es gibt …

• eine Modellierungstheorie,

• die zugehörige Software (ein Datenbanksystem (DBS))

• und die daraus entstehenden Datenbanken.

Relationale Datenbanksysteme setzen also relationale Datenmodelle in Relationale Datenbanken um, d.h. in die adäquate physische Datenstruktur und erlauben deren Verwaltung. Es sind nichts anderes als Softwaresysteme, die auf diese Aufgabe zugeschnitten sind.

Ähnliches gibt es noch für die objektorientierte Theorie¹ und die objektorientierten Datenbanken bzw. Datenbanksysteme sowie für neuere Modellierungsansätze (vgl. Kapitel 24). Allerdings sind im Umfeld von Unternehmen, Verwaltungen und sonstigen Organisationen die Relationalen Datenbanken absolut führend und am meisten verbreitet.

Aufgaben von Datenbanksystemen

Die Hauptaufgabe von Datenbanksystemen ist die effiziente Verwaltung der Informationsarten, für die sie geschaffen wurden. Bei Relationalen Datenbanken also die von attributbasierten (vgl. unten sowie Abschnitt 2.4), in Datensätzen (vgl. Kapitel 21) organisierten Daten. Wesentlich ist, dass diese Datenverwaltung über lange Zeiträume stattfinden soll, womit eine langfristige Speicherung der Daten einhergeht. Man spricht hier auch von persistenter Datenhaltung.

Relationale Datenbanken für Geschäftsprozesse

Da die unternehmerische Wirklichkeit und auch die anderer Organisationen durch Geschäftsprozesse geprägt ist, ist es dort die Aufgabe der Datenbanken, die Geschäftsprozesse zu unterstützen. Sie stellen für diese Informationen bereit und nehmen die im Geschäftsprozess neu entstehenden auf.

Mit obigem und mit dem Hinweis, dass letztendlich durch Datenbanken die Geschäftsprozesse der Organisationen unterstützt werden müssen, kann man die Hauptaufgaben von Relationalen Datenbanksystemen wie folgt formulieren. Sie …

• ermöglichen die Umsetzung eines relationalen Datenmodells in eine relationale Datenbank.

• leisten die redundanzfreie und integrierte Datenspeicherung.

• ermöglichen Auswertungen auf den abgespeicherten Daten.

• unterstützen die Geschäftsprozesse des jeweiligen Anwendungsbereichs, d.h. sie stellen Informationen zu allen Aspekten der Geschäftstätigkeit zur Verfügung und verwalten diese. Dies rührt daher, weil eine Datenbank so etwas wie ein informationelles Abbild des Anwendungsbereichs darstellt.

Datenbanksysteme sichern aber auch den laufenden Betrieb über den gesamten Lebenszyklus einer Datenbank hinweg, insbesondere die Integrität der Daten. Dazu gehört die Redundanzfreiheit, Korrektheit der Schlüssel (identifizierende Attribute) und der relationalen Verknüpfungen. Also auch stimmige Schlüssel und Fremdschlüssel (Attribut, das der Verknüpfung von Relationen bzw. ihren Tupeln dient, vgl. Kapitel 5.).

Eigenschaften von Datenbanksystemen

Zusammengefasst und noch etwas ergänzt gehören somit zu den Eigenschaften, die von Datenbanksystemen gefordert werden, die folgenden:

• Unterstützung eines Datenmodells, dazu gehört auch die redundanzfreie Speicherung

• persistente Datenhaltung

• Unterstützung einer formalen Sprache, mit der die Nutzer die Datenstruktur definieren, auf die Daten zugreifen und sie verarbeiten können. Z.B. SQL, vgl. Kapitel 19.

• Ermöglichung von Mehrfachzugriffen, die Fähigkeit vielen Nutzern auf einmal den Zugriff auf die Daten zu erlauben.

• Zugangskontrolle, die Fähigkeit, den Zugriff auf die Daten zu kontrollieren.

• Prüfungen der semantischen Integrität (der inhaltlichen Richtigkeit, wie im Datenmodell hinterlegt)

• Ausfallsicherheit, d.h. Absicherung der Daten für allen erdenklichen Fälle, angefangen vom Rechnerausfall bis zur Zerstörung durch Feuer.

• Transaktionsmanagement, d.h. die Fähigkeit, vielen Nutzern auf einmal den Zugriff auf die Daten zu erlauben. Vgl. Abschnitt 19.9.

• Für Relationale Datenbanksysteme gilt zusätzlich, dass sie auf effiziente Weise die Verknüpfung von Daten aus verschiedenen Dateien (Schlüssel / Fremdschlüssel (vgl. Kapitel 5) ermöglichen.

Damit kann nun definiert werden.

Definition: relationale Datenbank

Eine relationale Datenbank beruht auf einem Datenmodell. Sie besteht aus einer Sammlung von Dateien, die untereinander in inhaltlich begründeten Beziehungen stehen. Sie wird mit Hilfe eines Datenbanksystems angelegt, ausgewertet und verwaltet sowie an die sich ständig verändernden Strukturen im Anwendungsbereich angepasst.

Definition: Datenbanksysteme

Datenbanksysteme sorgen für eine effiziente Verwaltung der in der Datenbank persistent gespeicherten komplexen Daten über einen Anwendungsbereich. Sie sichern die Redundanzfreiheit und Integrität der in der Datenbank gespeicherten Daten im Zeitverlauf. Darüber hinaus ermöglichen sie den Mehrfachzugriff sowie eine Kontrolle des Zugriffs auf die gespeicherten Daten. Und natürlich ermöglichen sie eine flexible Auswertung der Daten.

1.6 Die drei Ebenen der ANSI-SPARC - Architektur

Der SPARC-Ausschuss (Standards Planning and Requirements Committee) des amerikanischen Normungsinstituts ANSI (American National Standards Institution) hat bezüglich der Architektur von Datenbanken schon in den 1970er-Jahren drei gegeneinander abgegrenzte Ebenen eingeführt, die ANSI-SPARC - Architektur, deren Betrachtung auch heute noch lohnt:

• Die externe Ebene beschreibt die Sichten der Anwender auf die Daten einer Datenbank. Hier ist festgelegt, wie bestimmte Anwendergruppen die Daten sehen, z.B. als Tabelle oder als Liste. Hier werden auch Einschränkungen vorgenommen, z.B. weil für eine bestimmte Aufgabe nur ein Teil der Daten wichtig ist oder weil bestimmte Nutzer nicht alle Daten sehen sollen. Es kann mehrere externe Sichten geben, jede für eine bestimmte Anwendung.

• Die konzeptionelle Ebene betrachtet die konzeptionelle Gesamtstruktur der Daten². Das Ergebnis wird konzeptionelles Schema genannt. Sämtliche Daten und ihre Beziehungen müssen hier dargestellt werden - unabhängig von Spezialanforderungen der Benutzer und der physischen Speicherung der Daten. Das konzeptionelle Schema ist die Sichtweise des Datenbankadministrators. Er muss hierfür ein Datenmodell finden, das am besten den Anforderungen genügt.

• Die interne Ebene beschreibt die physische Organisation und Speicherungsform der Daten. Das Ergebnis wird auch internes Schema genannt. Hier werden auch die Zugriffsarten festgelegt.

Eine ausführliche Darstellung findet sich in [Connolly, Begg und Stachan 2002, S. 80ff].

Sichten – views. Die sog. Sichten (views) auf eine Datenbank sind in der externen Ebene angesiedelt. Da eine Datenbank in der Regel einen großen Datenbestand enthält ist es sinnvoll, einzelnen Nutzern einen Ausschnitt davon zur Verfügung zu stellen. Da kann dann der Produktionsleiter alle Daten rund um die Produktion ausgewählt bekommen und die Personalchefin alle Daten des Personalwesens.

1.7 Syntax, Semantik, Pragmatik

Die im Datenbankkontext verwalteten Informationen werden i.d.R. durch Daten ausgedrückt (vgl. auch Kapitel 20), weshalb wir von diesem Begriff ausgehen.

Solche Daten haben einen bestimmten Aufbau (Syntax), eine Bedeutung (Semantik) und dienen einem Zweck (Pragmatik):

• Semantik meint hier im Datenbankkontext die Bedeutung, den Bedeutungsgehalt der Informationen, die über den Anwendungsbereich gewonnen wurden.

• Den korrekten Aufbau legt die sog. Syntax fest, die dafür die Regeln vorgibt.

• Mit Pragmatik ist der zielgerichtete Zweck gemeint, durch den Daten zu einer (eindeutig interpretierbaren) Information werden.

Datumsangaben: Tag, Monat, Jahr

Betrachten wir einige Beispiele, zuerst Datumsangaben. Diese haben eine schlichte Struktur. Sie bestehen aus einer Tages-, einer Monats- und einer Jahresangabe. Z.B. könnte die Syntax folgenden Aufbau vorschreiben: 4. Mai 2021 oder auch 2021/05/04. Also z.B. dass die Tagesangabe aus einer maximal zweistelligen positiven Zahl besteht, die Monatsangabe ebenfalls (oder aus einer Zeichenfolge) und die Jahresangabe entweder ebenfalls als zweistellige oder als vierstellige positive Zahl erfasst wird. Damit legt die Syntax den korrekten Aufbau dieser Information schon etwas fest, würde aber auch den 31. April 2024 oder den 35. 12. 2022 zulassen.

Dies unterbindet die Semantik, die zur weiteren Festlegung der Datumsangaben führt:

• Tagesangaben liegen nur zwischen 1 und 31

• Monatsangaben nur zwischen 1 und 12

• Die Monate April, Juni, September, November haben maximal 30 Tage

• Der Monat Februar hat maximal 28 Tage mit Ausnahme der Schaltjahre

• Das Jahr 2004 ist ein Schaltjahr, der Februar hat also 29 Tage

• Das Jahr 2000 war ebenfalls ein Schaltjahr (die Schaltjahrregelungen sind recht kompliziert, so gibt es Schaltjahre, die nur in großem Abstand auftreten).

usw.

Solche Festlegungen stellen also die Semantik der Datumsangaben dar. Genauer formuliert ist es so, dass die Realwelt (Datumsangaben) eine Semantik hat, die durch die Datumsangaben im Datenbestand möglichst genau erfasst werden soll. Dem Datenbanksystem liefert damit die Semantik weitere Regeln für die Korrektheit der Information. Dabei spricht man auch von Semantischen Integritätsbedingungen (englisch: constraints).

Noch präziser wird die Information durch die Pragmatik beschrieben. Eine Datumsangabe kann zum Beispiel einen Auftragseingang, ein Zahlungsziel oder den Abgabetermin für die Bachelorarbeit bedeuten. Das weiß die jeweilige Nutzerin und richtet ihr Verhalten daran aus.

Zahl 19

Betrachten wir ein weiteres Beispiel. Die Ausprägung einer Information sei die Zahl "19". Dieses Datenelement kann verschiedene Bedeutung haben:

• eine Hausnummer

• eine Uhrzeit

• ein Kalendertag

• die Nummer einer Buslinie

Diese Semantik wird erst durch den Zusammenhang klar:

• Steht 19 neben der Eingangstür an einer Hauswand, weiß man: Es ist die "Hausnummer 19".

• Steht 19: 00 auf einer digitalen Armbanduhr, so weiß man: Es ist "7 Uhr abends".

• Steht 19 auf Anzeige vorne in der S-Bahn, so weiß man: Es ist "die Linie 19".

Beispiel Lehrbetrieb. In einer Hochschule könnten folgende Grundsätze unserer Daseins zur Semantik gehören und bei der Gestaltung einer Datenbank zum Lehrbetrieb wichtig sein:

• In einem Raum kann in einer Zeitspanne nur eine Veranstaltung stattfinden.

• Ein Dozent kann in einer Zeitspanne nur einen Kurs abhalten.

• Ein Dozent sollte pro Tag nicht mehr als 6 Stunden Vorlesungen und Übungen geben.

• Veranstaltungen, die das lokale PC-Netz zum Absturz bringen könnten (z.B. Programmierkurse) sollten nicht am Freitag Nachmittag stattfinden, da ab 13.00 Uhr die Rechenzentrumsmitarbeiter nicht mehr da sind, um einen evtl. Netzzusammenbruch "zu reparieren".

usw. Wenigstens ein kleiner Teil solcher Semantikaspekte kann in Datenmodellen erfasst werden. Allerdings wirklich nur ein kleiner, wie im folgenden zu sehen sein wird, weshalb die diesbezüglichen Anstrengungen weitergehen.

Mehr Semantik in das Datenmodell. Woher kommt der Wunsch, möglichst viel Semantik des jeweiligen Weltausschnitts in einem Datenmodell und dann in der Datenbank zu erfassen? Nun, die Semantik gehört zur Anwendung. Sie muss auf jeden Fall berücksichtigt werden, soll die Anwendung leistungsstark sein. Entweder wird sie in der Datenbank hinterlegt oder in den Programmen softwaretechnisch realisiert (dann ist sie Gegenstand der Systemanalyse).

Es geht natürlich nur um den Teil der Semantik, der für die jeweilige Anwendung bzw. für die Geschäftsprozesse, denen die Datenbank "dient", Bedeutung hat.

Die Hinterlegung in der Datenbank, aufbauend auf der vorangehenden Berücksichtigung beim Datenbankentwurf, hat aber Vorteile: Sie ist sehr übersichtlich (z.B. als Semantische Integritätsbedingungen (constraints) auf den Relationen) und leicht änderbar. Man kann es auch so formulieren: Alle (zu berücksichtigende) Semantik, die nicht in der Datenbank hinterlegt wird, muss bei der Systemanalyse für die Anwendungsprogramme berücksichtigt werden.

Fehlt noch die Pragmatik von Daten bzw. Informationen. Daten, die eine Bedeutung haben, sind immer noch keine (eindeutige) Information. Dazu fehlt der praktische Wert, den eine Angabe für den Empfänger der Information bekommt. Eine Datumsangabe zum Beispiel kann einen Auftragseingang, ein Zahlungsziel oder den Abgabetermin für die Bachelorarbeit bedeuten. Das weiß der jeweilige Nutzer. Daten und ihre Bedeutung müssen also über einen zielgerichteten, pragmatischen Zweck verfügen, um zu einer (eindeutig interpretierbaren) Information zu werden. Diesen Aspekt von Daten nennt man auch Pragmatik.

1 Und für ältere Datenmodelle bzw. Datenbanksystemtypen (Netzwerkdatenbanken, Hierarchische Datenbanken), die aber heute keine Rolle mehr spielen.

2 Einige Autoren übersetzen "conceptual modeling" mit "konzeptuelle Modellierung". Das englische "conceptual" meint aber genau das deutsche "konzeptionell".