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

6 Zusammenfassung Grundlagen

6.1 Erste Schritte

Die bisherigen Ausführungen zum Entwurf eines relationalen Datenmodells lassen sich wie folgt zusammenfassen:

1. Schritt

Konzeptionelle Modellierung 1

• Im ersten Schritt wird die Komplexität des betrachteten Weltausschnitts dadurch reduziert, dass bedeutsame Objekte und Beziehungen identifiziert/festgelegt werden. Von Bedeutung für die Anwendung, für die Geschäftsprozesse, die dort eine Rolle spielen.

2. Schritt

Konzeptionelle Modellierung 2

• Dann werden bedeutsame Attribute von Objekten und Beziehungen erfasst. Auch bei den Attributen gilt, dass nur solche genommen werden, die "Bedeutung" im Sinn der obigen Anmerkung haben. Die Reihenfolge der ersten beiden Schritte ist unterschiedlich. Manchmal werden zuerst die Informationsträger (Objekte und Beziehungen) und dann die beschreibende Information (Attribute) entdeckt, manchmal ist es umgekehrt.

3. Schritt

Konzeptionelle Modellierung 3

• Im dritten Schritt werden die Objekte bzw. Beziehungen zusammengefasst, die durch dieselben Attribute beschrieben werden. Die sich dabei ergebenden Mengen werden Klassen genannt, Objektklassen bzw. Beziehungsklassen.

4. Schritt

Relationale Modellierung

• Im nächsten Schritt wird für Objekt- bzw. Beziehungsklassen je eine Relation angelegt. Dabei müssen die Anforderungen an Relationen beachtet werden. In dieser Phase sollte auch für jede Relation ein Schlüssel angelegt werden.

Die so entstehenden Relationen sind relational verknüpft. Ergab sich die Verknüpfung nicht direkt aus dem Designprozess, muss sie jetzt ergänzt werden. Nach dieser Phase liegen kleine Datenmodelle vor, Fragmente des geplanten Gesamtmodells.

6.2 Warum eigentlich flache Tabellen?

Warum stehen solche flachen Tabellen im Mittelpunkt eines datenbanktheoretischen Ansatzes? Wieso lässt man nicht Mehrfacheinträge zu⁷, die sich ja ständig ergeben (vgl. unten). Die Gründe sind i.w. folgende:

• Mit den beschriebenen flachen Tabellen ist eine umfassende Modellierung möglich, d.h. die im konventionellen Bereich vorkommenden Datenstrukturen können dadurch repräsentiert werden. Mit "konventionell" ist hier v.a. der kaufmännische Bereich gemeint. Zusätzlich aber auch alle anderen, deren Informationen sich durch Attribute erfassen lassen. Nichtkonventionell in diesem Sinn sind z.B. die Datenbanken der Chemie, Physik, der Technik (teilweise), usw. Hier liegen neben den Attributen ganz andere Informationsarten vor (Strukturformeln, Spektren, technische Zeichnungen, usw.). Ebenso nichtkonventionell sind die sog. unstrukturierten Daten, die unter dem Stichwort BigData und NoSQL behandelt werden (vgl. Kapitel 24).

• Flache Tabellen können weitgehend redundanzfrei organisiert werden.

• Eine Modellierung mit flachen Tabellen ist insgesamt übersichtlich.

• Flache Tabellen können ohne Schwierigkeit verknüpft werden, um entsprechende Datenstrukturen abzubilden (z.B. solche, die sich als 1: n- oder n: m- Beziehungen äußern).

• Flache Tabellen können problemlos als Dateien geführt und dann leicht abgefragt und verwaltet werden.

Die Anhängsel "_UN" (unormalisiert) und "_1NF" (erste Normalform) werden im nächsten Kapitel erläutert.

Das folgende Beispiel der Relationen Pers_UN (UN=in unnormalisierter Form, eine Tabelle zu Personen mit Mehrfacheinträgen) und Pers_1NF (Relation zu Personen als flache Tabelle⁸) möge dies veranschaulichen. In beiden wird für irgendwelche Personen festgehalten, welche Programmiersprachen sie beherrschen (ProgSpr) und wieviel Jahre Erfahrung sie damit haben (Erfahrung). Die Attribute ProgSpr und Erfahrung haben Mehrfacheinträge, was ja nicht erlaubt ist. Außerdem hängen die beiden Attribute dergestalt zusammen, dass die Angabe zur Programmiererfahrung an einer bestimmten Position zur Programmiersprache an derselben Position gehört.

Pers_UN

#PersNr	ProgSpr	Erfahrung
123	C, COBOL, PHP, C++	10, 14, 2, 5
456	C++, Java, C	5, 2, 7

Pers-UN enthält als Ausprägungen des Attributs ProgSpr eine Liste der Programmiersprachen, die von der jeweiligen Person beherrscht werden. Das Attribut Erfahrung gibt die Zahl der Jahre an, die mit der Sprache gearbeitet wurden. Die Beziehung zwischen den Attributsausprägungen von ProgSpr und Erfahrung wird nur durch die Position in der Liste festgehalten.

Flach durch Tupelvermehrung

Die nachfolgende Tabelle zeigt dieselben Daten als flache Tabelle. Dabei wurde einfach für jeden der Mehrfacheinträge ein eigenes Tupel angelegt. Diese Methode wird Tupelvermehrung genannt.

Pers_1NF

PersNr	ProgSpr	Erfahrung
123	C	10
123	COBOL	14
123	PHP	2
123	C++	5
456	C++	5
456	Java	2
456	C	7

#(PersNr, ProgSpr)

Auch wenn diese Relation auf den ersten Blick redundant anmutet, ist sie es im relationalen Sinn nicht und stellt eine effiziente und "wartungsfreundliche" Informationsstruktur

dar. Wenn die Mehrfacheinträge so wie hier beseitigt sind,

• … kann jedes Feld leichter abgefragt werden. In Pers-UN kann die Suche nach allen, die C++ beherrschen, nicht einfach durch Abgleich erfolgen, sondern durch das Absuchen der Zeichenkette nach dem Auftreten der Zeichenfolge "C++".

• … kann jedes Feld für die Verknüpfung mit anderen Relationen genutzt werden. Hier z.B. zu einer Relation, die zu den jeweiligen Programmiersprachen nähere Angaben enthält.

• … ist die Beschreibung der Objekte eindeutig, denn sonst kann bereits bei zwei Feldern mit Mehrfacheinträgen die Eindeutigkeit verloren gehen. Beispiel: In der Tabelle Pers_UN ist die Zuordnung zwischen Programmiersprache und Programmiererfahrung sicherlich schwerer korrekt zu halten, als in der Relation Pers_1NF .

• … ist ohne Schwierigkeit in die heute gängigen Dateitypen abzubilden (z.B. als indexsequentielle Datei).

• … ist leichter zu korrigieren, wenn z.B. die Schreibweise einer Ausprägung an allen Stellen geändert werden soll. In Pers-UN erfordert dies lange Suchprozesse und nicht ganz einfache Änderungen, in Pers_1NF könnte durch einen Befehl in allen Datensätzen z.B. "Fortran" durch "Fortran 2000" ersetzt werden.

Die Bedeutung der flachen Tabelle ist also sehr groß und kann so zusammengefasst werden:

Relationale Datenbanken bauen in all ihren Aspekten (Datenstruktur, Datenabfrage, Datenverwaltung, usw.) voll auf flachen Tabellen mit den beschriebenen Eigenschaften auf (Relationen). Diese sind daher beim Entwurf des Datenmodells zu realisieren.

Ausnahmen stellen Felder dar, die ausdrücklich nur zur Ausgabe dienen, die also weder Schlüsselattribut sind, noch Determinanten (vgl. unten), noch in Abfragen für die Festlegung der auszugebenen Menge dienen, noch die Verknüpfung mit anderen Relationen leisten.

7 Es gibt in der Tat Datenbanksysteme, die ausdrücklich solche nicht-flachen Strukturen zulassen, dominierend sind aber in Unternehmen (bzw. Organisationen aller Art) derzeit Relationale Datenbanksysteme.

8 Eine solche Relation wird als Relation in erster Normalform (1NF) bezeichnet (vgl. unten), was einfach bedeutet, dass sie keine Mehrfacheinträge hat, d.h. flach ist.