Josef Ludwig Staud: Auszüge aus dem Buch: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. 2. Auflage 2021

Auszüge aus dem Buch: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. 2. Auflage 2021
©2021 Josef L. Staud
Autor: Josef L. Staud
Stand: August 2021
Umfang des Textes: 452 Seiten
Dieser Text enthält Auszüge aus meinem Buch: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. 2. Auflage 2021 Verlag: tredition GmbH, Hamburg
ISBN: 978-3-347-35883-6 (Paperback): 978-3-347-35884-3 (Hadcover) 978-3-347-35885-0 (E-Book) 452 Seiten
Aufbereitung für’s Web
Diese HTML-Seiten wurden mithilfe eines von mir erstellten Programms erzeugt: WebGenerator (Version 2015-1). Es setzt Texte in HTML-Seiten um und ist noch in der Entwicklung. Die „maschinelle“ Erstellung erlaubt es, nach jeder Änderung des Textes diesen unmittelbar neu in HTML-Seiten umzusetzen. Da es nicht möglich ist, nach jeder Neuerstellung alle Seiten zu prüfen, ist es durchaus möglich, dass irgendwo auf einer „abgelegenen“ Seite Fehler auftreten. Ich bitte dafür um Verzeihung und um Hinweise (staud@gmx.info).
Urheberrecht
Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.
Warenzeichen und Markenschutz
Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Produktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei zu betrachten wären und daher von jedermann benutzt werden dürften.



Prof. Dr. Josef L. Staud

Vorwort, Inhalt, Abkürzungen

Vorwort

Datenbanken waren noch nie so wichtig. Diese Aussage mag überraschen, angesichts der Bedeutung, die Datenbanken in den letzten 50 Jahren schon gewonnen haben. Sie ist aber, angesichts der Herausbildung einer digitalen Parallelwelt, richtig.

Datenbanken werden überall dort benötigt, wo - im Rahmen der Informatisierung - Informationen "erhalten bleiben sollen". Da dies für so gut wie alle Anwendungs- und Lebensbereiche gilt, ergibt sich eine entsprechende Verbreitung von Datenbanken und ein entsprechender Bedarf an Wissen über Datenbanktechniken.

Informatisierung

In einer Zeit aber, in der sich die Weltgesellschaft mit dem Internet eine digitale Parallelwelt geschaffen hat, in der sie privat, geschäftlich, kriminell, in staatlichem Auftrag, usw. aktiv ist, ist dieser Bedarf noch größer geworden. Denn alle diese Netzaktivitäten beruhen auf bzw. führen zu Datenbanken. Natürlich Datenbanken der verschiedensten Art. Netzwerkdaten im Social Web, wo Terabyte von Daten bereits emsig ausgewertet werden; Datenbanken der Suchmaschinen, die letztendlich auf die Technologie der "inverted files" zurückgehehen; "Unstruktierte Daten" der unterschiedlichsten Art, usw. Und die schon altbewährten Relationalen Datenbanken, die einen sehr großen Anteil am Gesamtbestand von Datenbanken halten, v.a. in den Unternehmen.

Immer mehr Datenbanken

Um die Relationalen Datenbanken geht es in diesem Buch in erster Linie. Sie sollen umfassend dargestellt werden und auch der Weg zu ihnen: Vom Anwendungsbereich zur konzeptionellen und logischen Datenmodellierung, dann zum Datenbankdesign und zur Einrichtung der Datenbank. Zum Schluss werden noch die physischen Datenstrukturen beschrieben, auf denen die heutigen Speichertechniken beruhen.

Der ganze Weg

Daneben werden aber auch die wichtigsten Alternativen kurz beschrieben. Alternative Datenmodelle (semantische und logische) und alternative Datenbanktechnologien, von dimensionalen Datenbanken über NoSQL-Datenbanken bis zur InMemory-Technologie.

Bezüglich der relationalen Datenbanktheorie sind folgende Themen neu und so anderweitig nicht abgedeckt:

Die intensive Betrachtung von Mustern in Anwendungsbereichen und in relationalen Datenmodellen(„Semantik sucht Syntax“). Dies sollte die konkrete Datenmodellierung erleichtern.

Die Erweiterung der Kardinalitäten zur durchgängigen Betrachtung von Min-/Max-Angaben bei relationalen Verknüpfungen („wieviele Teilnehmer mindestens, wieviele höchstens“). Auch dies sollte bei einer modernen Modellierung so sein.

Die Betrachtung des gesamten Wegs von der Wahrnehmung des Anwendungsbereichs bis zur Erstellung der Datenbank und der physischen Datenorganisation.

Zahlreiche Beispiele für relationale Datenmodellierung, einige mit Lösungsweg, einige ohne. Dies ist motiviert durch die Erfahrung aus jahrzehntelanger Lehr- und Beratungstätigkeit, dass Datenmodellierung beim Umgang mit Datenbanken die größten Probleme macht und vielerorts nur eingeschränkt beherrscht wird.

Prof. Dr. Josef Ludwig Staud

Inhaltsverzeichnis der Buch- und PDF-Version

Vorwort, Inhalt, Abkürzungen III

1 Einleitung 13

1.1 Aufbau des Buches, Gesamtüberblick 13

1.2 Hinweise zur Textgestaltung 17

1.3 Datenbanken 17

1.4 Logische Datenmodelle, Datenorganisation 19

1.5 Relationale Datenbanksysteme 21

1.6 Die drei Ebenen der ANSI-SPARC - Architektur 23

1.7 Syntax, Semantik, Pragmatik 23

2 Informationen, Daten, Attribute 27

2.1 Informationen, Daten 27

2.2 Klassifizierung von Daten 29

2.3 Zeichen, Zeichenvorrat 31

2.4 Attribute 32

3 Konzeptionelle Modellierung 37

3.1 Anwendungsbereiche 37

3.2 Objekte und Beziehungen erkennen 38

3.3 Klassen bilden 40

3.4 Beispiele 41

3.5 Zusammenfassung 42

4 Relationen bilden 45

4.1 Von Klassen zu Relationen 45

4.2 Eigenschaften und Darstellung von Relationen 47

5 Beziehungen erkennen und einrichten 53

5.1 Beziehungen erkennen 53

5.2 Schlüssel und Fremdschlüssel 56

5.3 Umsetzung von 1:1 57

5.4 Min-/Max-Angaben und "1:1 vertieft" 59

5.5 Umsetzung von 1:n 64

5.6 Umsetzung von n:m 67

5.7 Verknüpfung konkret 70

5.8 Mehrstellige Beziehungen 73

5.9 Integritäten 74

5.10 Schlüssel vertieft 74

6 Zusammenfassung Grundlagen 77

6.1 Erste Schritte 77

6.2 Warum eigentlich flache Tabellen? 78

7 Die erste Normalform (1NF) 81

7.1 Optimierung durch Normalisierung 81

7.2 Definition und Herbeiführung 82

7.3 Tupelvermehrung 83

7.4 Zerlegung nach 1:n 84

7.5 Zerlegung nach n:m 87

7.6 Schlechte Lösungen 92

7.7 Relationale Datenmodelle 94

7.8 Redundanzen in 1NF-Relationen 99

7.9 Anomalien 101

8 Funktionale Abhängigkeiten 105

8.1 Einführung 105

8.2 Funktionale Abhängigkeit 106

8.3 Schneller Weg zum Erfolg 110

8.4 Einfache und volle FA 112

8.5 Schlüssel (formal) 114

9 Die zweite Normalform (2NF) 117

9.1 Redundanz trotz 1NF 117

9.2 Definition 118

9.3 Beispiel Aufträge 119

9.4 Beispiel PROJEKTMITARBEIT 121

9.5 Zerlegung und Zusammengehörigkeit 124

10 Die dritte Normalform (3NF) 125

10.1 Redundanz trotz 2NF 125

10.2 Beispiel Auftragsköpfe 126

10.3 Beispiel Angestellte 128

10.4 Beispiel Aufträge / Artikel / Kunden 130

10.5 Definition 3NF 133

11 Die Boyce-Codd - Normalform (BCNF) 135

11.1 Redundanz trotz 3NF 135

11.2 Beispiel Projektmitarbeit 137

11.3 Definition BCNF 140

11.4 Noch ein Beispiel 140

12 Die vierte Normalform (4NF) 143

12.1 Das Defizit 143

12.2 Beispiel Vorlesungsbetrieb 143

12.3 Mehrwertige Abhängigkeit 146

12.4 Definition 4NF 147

13 Die fünfte Normalform (5NF) 149

13.1 Verbund (Join) und Projektion 150

13.1.1 Verbund (Join) 150

13.1.2 Projektion 152

13.2 N-Zerlegbarkeit 154

13.3 Regeln für die Erstellung relationaler Datenmodelle 163

14 Muster in Anwendungsbereichen und Modellen 165

14.1 Ähnlichkeit - Generalisierung / Spezialisierung 165

14.2 Einzel- und Typinformation 174

14.3 Enthaltensein - Aggregation 179

14.4 Enthaltensein und Existenzabhängigkeit - Komposition 183

14.5 Beziehungsattribute 188

15 Die Zeit in Datenmodellen und Datenbanken 193

15.1 Zeitlich fixiert oder zeitabhängig 193

15.2 Duplizieren zum Zeitpunkt der Rechnungsstellung 194

15.3 Andere Lösungen 195

16 Modellierungsbeispiele mit Lösungsweg 197

16.1 Rechnungsstellung 197

16.2 Sportverein 208

16.3 PC-Beschaffung 214

16.4 Fachliteratur 219

16.5 Hochschule – Vorlesungsbetrieb 228

16.6 Sprachenverlag 237

17 Weitere Modellierungsbeispiele 249

17.1 Obst 249

17.2 Haushaltsgeräte 251

17.3 Angestellte 253

17.4 Kfz-Werkstatt 258

17.5 WebShop 259

17.6 Zoo 262

18 Von Attributen zu Datentypen 265

18.1 Vielfalt 265

18.2 Die Datentypen von MySQL 269

18.3 Die Datentypen von ORACLE SQL 276

18.4 Die Datentypen von ACCESS 277

18.5 Welcher Datentyp für welches Attribut? 282

19 Einführung in SQL 283

19.1 Einleitung 283

19.2 Datenbanken anlegen und löschen 286

19.3 Relationen anlegen und löschen 287

19.4 Eingeben von Daten 294

19.5 Abfragen der Daten mit Select 298

19.6 Gezieltes Löschen und Korrigieren 309

19.6.1 Löschen mit DELETE FROM 311

19.6.2 Daten korrigieren - Update ... set ... 312

19.6.3 Maskierung mit LIKE 313

19.7 Funktionen 315

19.7.1 Funktionen für Tupelmengen und Gruppenbildung 315

19.7.2 Mathematische Funktionen 317

19.7.3 Funktionen für Zeichenketten 321

19.8 Verknüpfen von Relationen 324

19.8.1 Equjoin - Verbund über die Gleichheit von Attributsausprägungen 324

19.8.2 Outer Join 329

19.8.3 SelfJoin - Eine Relation mit sich selbst verknüpfen 333

19.9 Transaktionen 338

20 Vom Zeichen zur Datenbank 346

20.1 Die Ebenen 346

20.2 Übersicht 348

21 Dateitechniken 351

21.1 Datenmodell - Datenbank - Datei 351

21.2 Stapeldateien 352

21.3 Sequenzielle Dateien 353

21.4 Indexsequenzielle Dateien 355

21.5 Direktzugriffsdateien/Hashing 357

22 Speichermedien 361

22.1 Periphere Speicher 361

22.2 Konkrete Speicherung 362

22.3 Magnetische Speicher 362

22.4 Optische Speicher 365

22.5 Elektronische Speicher 370

23 Andere Datenmodelle 373

23.1 Semantische Datenmodelle 373

23.2 Logische Datenmodelle 374

24 NoSQL etc. Nicht-konventionelle DBn 377

24.1 OLTP und OLAP 377

24.2 Dimensionale Datenbanken 379

24.3 Spaltenorientierte Datenbanken 390

24.4 NoSQL-Datenbanken - Überblick 393

24.4.1 Definition 394

24.5 BigData 396

24.5.1 Parallelwelten 396

24.5.2 Ursache 1: Immer mehr Daten in den Rechnernetzen 397

24.5.3 Ursache 2: Internet der Dinge und Industrie 4.0 398

24.5.4 Immenser Speicherbedarf und Vielfalt 400

24.5.5 Volume, Velocity, Variety 401

24.5.6 Skalierbarkeit 401

24.5.7 Parallelisierung mit Hilfe des MapReduce-Frameworks 402

24.6 Konsistenz, CAP-Theorem 403

24.7 Schemafreiheit 404

24.8 Key/Value - Datenbanken 407

24.9 Graphendatenbanken 409

24.10 Dokumentendatenbanken 410

24.11 InMemory - Datenbanksysteme 414

Literatur 417

Abkürzungsverzeichnis

Abkürzung

ANSI

American National Standards Institution

DBMS

Datenbankmanagementsystem

DBS

Datenbanksystem

DML

Data Manipulation Language

DV

Datenverarbeitung

ERM

Entity Relationship - Modell

ERP

Enterprise Ressource Planning. Eingeführte Bezeichnung für integrierte prozessorientierte Standardsoftware.

fA

funktionale Abhängigkeit

FA-Diagramm

Diagramm der funktionalen Abhängigkeiten

IRS

Information Retrieval System

IT

Informationstechnologie. Heute benutzt als Bezeichnung für die Abteilung, in der die Computer der Organisation betrieben werden.

OODBS

Objektorientiertes Datenbanksystem

OODM

Objektorientierte Datenmodellierung

PC

Personal Computer

RDBS

Relationales Datenbanksystem

SPARC

Standards Planning and Requirements Committee

SQL

Structured Query Language

vs.

versus (im Vergleich zu, im Gegensatz zu)

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.

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.

Anwendungsbereich und Konzeptionelle Modelllierung

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.

Semantische Datenmodelle

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

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.

Logisches Datenmodell

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.

Datenbankdesign vollzogen

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.

Datenbanken einrichten mit SQL

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.

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.

Dateien auf peripheren Speichern
Physische Datenorganisation

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.

Träger der jeweiligen Aktivität

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).

Datenbanksystem - Betriebssystem

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

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:

Überblick durch Typographie

Bezeichnungen von Anwendungsbereichen werden etwas vergrößert, in Kapitälchent 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.

Für die Relationen (Tabellen für relationale Datenbanken) 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".

Relationenbezeichnung

1.3 Datenbanken

Digitale Abbilder

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.

Immer mehr Daten, immer mehr Datenbanken

Ü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.

Digitale Parallelwelt

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.

Relationale 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.

Dateisysteme vs. Datenbanksysteme.

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

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.

Realität und Modell

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:

Beispiele

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

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.

Abstrahiertes Abbild der Realität

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

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.

Zusammenfassung

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

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:

Festlegungen

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.

Datenbanksystem,
relationales Datenbanksystem

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.

Nicht ohne Theorie

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

Theorie + zugehörige Software ==> Datenbanken

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 [Anmerkung] 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.

Attribute und ihre Ausprägungen in Datensätzen

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.

Relationale Datenbanken für Geschäftsprozesse

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 [Anmerkung] (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:

Zusammenfassung

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.

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: relationale Datenbank

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.

Definition: Datenbanksysteme

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:

Drei Ebenen

Die externe Ebenebeschreibt 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[2]. 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].

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.

Sichten - views

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.

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.

Datumsangaben: Tag, Monat, Jahr

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.

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

Beispiel
Zahl 19

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".

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

Beispiel
Lehrbetrieb

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.

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).

Mehr Semantik in das Datenmodell

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.

Pragmatik

2 Informationen, Daten, Attribute

Hier beginnt Teil I: Grundlagen

mit den Kapiteln

2 Informationen, Daten, Attribute

3 Konzeptionelle Modellierung

2.1 Informationen, Daten

Information bedeutet in erster Linie Wahrnehmung. Wahrnehmung wiederum ist für uns Menschen mit irgendeinem Phänomen der Realwelt verbunden, einem Informationsträger. Die englische Fachliteratur hat dafür den Begriff entity. Information ist deshalb jegliche Kenntnis über Dinge, Ereignisse, Beziehungen, Abläufe, Tatsachen, usw. Sie kommt in irgendeiner Form, die wir wahrnehmen können, entweder direkt (Bild, Ton, Text, Ziffern, usw.) oder mithilfe von Hifsmitteln (Fernsehen, Computer, Smartphone, Radio, usw.).

Alles was wir wahrnehmen

Informationen sind also eigentlich schon strukturiert, werden aber als unstrukturiert bezeichnet. Strukturiert für uns Menschen, unstrukturiert weil sie nicht direkt in unsere digitalen Systeme und Speicher aufgenommen und nicht digital verarbeitet werden können.

Strukturiert - unstrukturiert

Maschinelle Informationsverarbeitung

Diese Diskrepanz wird Schritt um Schritt aufgelöst. Menschliche Sprache kann heute nicht nur aufgezeichnet, sondern auch gleich digital-textlich verfügbar gemacht werden. Genauso Handschrift. Der Tablet-Computer, auf dem dieser Text gerade bearbeitet wird, hat eine Texterkennung, die keine Probleme mit der nicht "unkrakeligen" Handschrift des Autors hat. Ein großes Internetunternehmen kann digital erfasste Gesichter identifizieren und sie Personen zuordnen, die ihrem Datenbestand zugeliefert wurden. Eine Sache von der die Künstliche Intelligenz - Forschung (KI), die Strafverfolgungsbehörden und die Geheimdienste vor einigen Jahren noch geträumt haben. Aus den zwar digitalen aber komplexen Daten des SocialWeb werden durch Programme Profile von Nutzern, Situationen ("hat geheiratet und will Haus bauen", ...) gewonnen, die nicht nur Geheimdiensten ("neigt zum Terrorismus"), sondern auch Versicherungsunternehmen dienen. Im Sommer 2014 wurde eine Software zum Formulieren von einfachen Texten vorgestellt. Diese Liste liese sich lange fortsetzen.

Ein Gegenbeispiel soll nicht verschwiegen werden: Das Verstehen von textlich formulierter Information. Dies ist - trotz der intensiven Anstrengungen kapitalstarker Internetunternehmen mit riesigen Entwicklerabteilungen - noch nicht gelöst (das Programm, das menschliche Gegner im Quiz schlägt, versteht die Fragen nicht, sondern löst sie aufgrund massenhafter Datenabgleiche). Dafür wäre "Verstehen" notwendig, Verstehen von Semantik, Zusammenhängen, usw., also der Besitz von Weltwissen, wie das in der KI genannt wird. Das geht noch nicht, aber wer weiß ...

Information an und für sich ist etwas abstraktes, immaterielles. Sie kann nur mitgeteilt (transportiert) und verarbeitet werden, wenn sie z.B. in Worten formuliert, mit Buchstaben aufgeschrieben, mithilfe von Symbolen gezeichnet, wenn sie also in irgendeiner Form dargestellt wird. Die so repräsentierten Informationen nennen wir Daten. Sie stellen Informationen aufgrund bestimmter Regeln oder Abmachungen in einer zur maschinellen Verarbeitung, Speicherung oder Übertragung geeigneten Form dar. Informationen haben Semantik, Daten nicht - deren Semantik muss durch das datenverwaltende System unterstützt bzw. sicher gestellt sein.

Daten

Analog, digital

Bilder, Töne und andere physikalische Größen wie Temperatur, Geschwindigkeit oder elektrische Spannung bestehen meist nicht aus einzelnen (diskreten) Werten, sondern sind durch einen kontinuierlichen Verlauf gekennzeichnet. Sie sind stetig veränderlich und können somit unendlich viele Werte annehmen. Man spricht deshalb von analogen Größen. Im Gegensatz dazu heißt eine Darstellung, die sich aus einzelnen, endlich vielen Zeichen zusammensetzt, digital.

Ein Beispiel stellen die verschiedenen Uhrentechnologien dar. Grundsätzlich ist der Zeitverlauf kontinuierlich. Zwischen 0 und 24 Uhr durchläuft die Zeit unendlich viele Punkte. Bei einer analogen Uhr, die auf der Basis ihres Uhrwerks mit Ziffernblatt und Zeiger arbeitet, kann jeder auch noch so winzige Zeitpunkt angezeigt werden. Der Zeiger überstreicht unendlich viele Positionen. Ganz anders bei einer digitalen Uhr: Diese stellt nur einzelne (ausgewählte) Zeitpunkte durch Zeigerpositionen oder Ziffern dar. Sie beginnt bei 0 Uhr und zählt die einzelnen Sekunden hoch. Alle Zwischenwerte werden auf- oder abgerundet. Somit gilt:

Beispiel: Uhren

Digitale Daten bestehen aus aufeinanderfolgenden (diskreten) Zeichen.

Analoge Daten entsprechen kontinuierlichen Funktionen und werden durch physikalische Größen dargestellt, die stufenlos veränderbar sind und den zu beschreibenden Sachverhalt repräsentieren.

Weitere Beispiele für analoge Daten sind die Darstellung der Temperatur durch die Höhe einer Quecksilbersäule in einem Thermometer oder die Musik auf einer Schallplatte. Auf einer CD gespeicherte Worte, Zahlen oder Musik sind Beispiele digitaler Daten. Selbstverständlich sind alle im Internet gespeicherten Daten ebenfalls digital.

Computer können nur mit digitalen Daten umgehen. Liegen analoge Werte vor, müssen sie zur Verarbeitung im Rechner digital dargestellt werden. Will man etwa den analog erhobenen Temperaturverlauf eines Tages zur Wettervorhersage für den nächsten Tag heranziehen und durch einen Computer verarbeiten lassen, so muss die Temperaturkurve vor der Verarbeitung in digitale Werte umgewandelt werden. Werden analoge Übertragungseinrichtungen benutzt (z.B. Datenübertragung über das analoge Telefonnetz) ist eine Analog-Digital-Wandlung erforderlich. Man nennt dies Digitalisierung. Dabei verliert man Informationen, das Ergebnis ist gegenüber den analogen Daten ungenau. Stellt man die Abtastrate (Zeitabstufung) und die Empfindlichkeit des Messvorgangs jedoch fein genug ein, bemerkt man den Fehler normalerweise nicht.

Digitalisierung

Ohne Digitalisierung geht es also nicht, soll die Information in Rechnern erfasst und verarbeitet werden. Sie hat darüberhinaus große Vorteile. Im Gegensatz zu analogen Daten können digitale Daten komprimiert (verdichtet) werden. Das bedeutet, dass sie weniger Speicherplatz auf den Datenträgern benötigen und dass größere Datenmengen transportiert werden können. So steigt durch Komprimierung die Kapazität von Datenübertragungswegen beträchtlich an. Auch sind digitale Daten bei einer Übertragung weniger störanfällig als analoge. Strom- oder Spannungsverläufe in elektrischen Kabeln lassen sich durch elektromagnetische Einflüsse sehr leicht verändern. Sind die Spannungswerte dagegen digitalisiert, führt ihre "Ungenauigkeit" dazu, dass kleinere Störungen unerheblich bleiben, die evtl. gestörten Zwischenwerte interessieren nicht.

Eine weitere Eigenschaft von Daten ist, dass sie einen Träger brauchen, denn sie existieren auch außerhalb der menschlichen Vorstellungswelt. Früher war das "in Stein meißeln" üblich, heute ist sehr oft Papier der Träger der Wahl (z.B. als Buch oder Aufsatz), im Rahmen der Informatik sind aber andere Träger notwendig. Vor allem solche, die schnell, leicht und immer wieder beschrieben werden können. Ein solches Mittel, auf dem Daten aufbewahrt und auch transportiert werden können, heißt Datenträger. Die Entwicklung ist hier, genauso wie in der sonstigen IT, sehr dynamisch. Heute werden Festplatten mit bis zu 20 Terabyte Daten und sehr kurzen Zugriffszeiten zu erschwinglichen Preisen angeboten.

Träger von Daten

Kapitel 22 gibt einen Überblick zu den aktuell genutzten Datenträgern

Datenträger können Daten dauerhaft speichern, z.B. auf Magnetplatten, in einem Solid State Drive (SSD), auf optischen Speichern (DVD, Blue Ray, CD-ROM). Oder sie nur vorübergehend festhalten (die "flüchtigen", aber schnellen Speicher bei der Informationsverarbeitung rund um die CPU) bzw. sehr kurz abbilden, d.h. nur während eines Transports bewahren (z.B. elektromagnetische Schwingung, Gleichstromimpuls).

Dauerhaft, flüchtig, nur zum Transport

2.2 Klassifizierung von Daten

Es gibt Daten in unendlicher Vielfalt, wie es eben auch Informationen aller Art gibt. Alle diese Daten werden in Datenbanken gespeichert. Hier nun einige Definitionen grundsätzlicher Natur und aus dem Umfeld betrieblicher Anwendungsbereiche.

Daten, die zur maschinellen Verarbeitung in einem fest vereinbarten Aufbau geordnet sind, bezeichnet man als formatierte Daten. Dabei erhalten sie eine Struktur (in Feldern und Sätzen) und werden zusammenfassend in Dateien und Datenbanken abgelegt. Vgl. dazu Kapitel 20 und 21.

Formatierte Daten

Daten, die über keine solche formale Struktur verfügen, nennt man unformatierte Daten. Das wichtigste Beispiel dafür ist Text, eine Aneinanderreihung von Buchstaben, Ziffern und Sonderzeichen zu Wörtern und Sätzen, die nur durch unsere Sprachkompetenz erzeug- und verstehbar sind. Es wird allerdings schon lange an textverstehenden Programmen gearbeitet, erste Erfolge sind erzielt. Zum Beispiel bei der Sprachsteuerung in Kraftfahrzeugen oder bei Diktiersystemen, die gesprochenen Text in Dateien niederschreiben.

Unformatierte Daten

Die folgenden Definitionen sind im Umfeld von Informationssystemen von Organisationen (insbesondere Unternehmen) üblich (vgl. [Mertens 2013] für eine vertiefte Betrachtung):

Nach dem Inhalt: Nutzdaten, Steuerdaten

Bezüglich statischer und dynamischer Aspekte: Zustandsorientierte und abwicklungsorientierte Daten

Nach dem Verwendungszweck: Stammdaten, Bestandsdaten, Änderungsdaten, Bewegungsdaten

Nach der Stellung im Verarbeitungsprozess: Eingabedaten, Ausgabedaten

Nutzdaten. Daten, die Phänomene der betrieblichen (unternehmerischen, organisationellen) Anwendungsbereiche beschreiben, heißen Nutzdaten. Mit ihnen arbeiten die betrieblichen Anwendungssysteme. Sie werden unterschieden von den Steuerdaten, die für die Steuerung der rechnerinternen Verarbeitungsprozesse benötigt werden.

Nach dem Inhalt

.Damit sind Daten gemeint, die den Zustand einer Organisation zu einem Zeitpunkt beschreiben. Angaben über einen Auftrag, also etwa die Auftragsnummer, der Name und die Anschrift des Auftraggebers, bestellte Mengen, geforderter Liefertermin usw. und Informationen über die Kapazitäten, etwa Auslastung der vorhandenen Maschinen, einsetzbares Personal usw. beschreiben den Zustand des Betriebs. Es sind zustandsorientierte Daten, die eine gewisse zeitliche Gültigkeit haben. Die Anschrift des Auftraggebers wird sich normalerweise nicht so schnell ändern und auch der Liefertermin oder die bestellte Menge bleiben zumindest während der Gültigkeit des Auftrags stabil. Erst wenn der Auftrag geändert oder ein neuer Auftrag gestellt wird, verlieren diese Angaben ihre Gültigkeit und müssen angepasst werden. Der Zustand des Auftrags und damit der des Betriebs verändern sich.

Zustandsorientierte Daten

Daten, die Aktionen oder Ereignisse beschreiben, die zustandsorientierte Daten verändern, heißen abwicklungsorientierte Daten. Die Entscheidung, Sonderschichten einzuführen, würde über solche Daten dargestellt werden, also die Einteilung von Mitarbeitern zu den einzelnen Schichten. Damit steigt (verändert sich) die verfügbare Kapazität des Betriebs.

Abwicklungsorientierte Daten

Nach dem Verwendungszweck

Stammdaten sind zustandsorientierte Daten, die der Identifizierung, Klassifizierung und Charakterisierung von Sachverhalten dienen und die unverändert über einen längeren Zeitraum hinweg zur Verfügung stehen. Sie ändern sich nicht oder nur sehr selten.

Stammdaten.

Anders sieht es aber mit dem Lagerbestand der Artikel, dem Kassenbestand, dem Umsatz oder dem Resturlaub von Mitarbeitern aus. Sie werden oftmals, von Monat zu Monat, variieren. Diese werden Bestandsdaten genannt. Sie sind zustandsorientierte Daten, welche die betriebliche Mengen- und Wertestruktur kennzeichnen und durch das Betriebsgeschehen systematischen Änderungen unterworfen sind.

Bestandsdaten.

Änderungsdaten sind abwicklungsorientierte Daten, die fallweise eine Änderung von Stammdaten auslösen. So sind beispielsweise eine neue Telefonnummer, Angaben über neue oder auslaufende Artikel oder Änderungsmitteilungen von Lieferantenadressen Änderungsdaten. Ihre Verarbeitung führt zu einer Aktualisierung der jeweiligen Stammdatensätze.

Änderungsdaten

Bewegungsdaten sind abwicklungsorientierte Daten, die Bestandsdaten verändern. Sie stellen den größten Teil der anfallenden Daten und entstehen immer wieder neu durch die betrieblichen Leistungsprozesse. Für die laufende Bearbeitung von Geschäftsvorfällen werden sie gespeichert, nach einer gewissen Zeitspanne können sie jedoch wieder aus den Datenbanken entfernt werden, da sie nur für kurze Zeit aktuell sind. Bewegungsdaten sind beispielsweise Warenlieferungen, Warenentnahmen, Ein- oder Auslagerungen, Rechnungsbegleichungen oder Kontobewegungen.

Bewegungsdaten

Obiges kann die Vielfalt und den Aufbau dieser Daten nur andeuten. Einen vertieften Einblick geben die einschlägigen Bücher aus der Wirtschaftsinformatik, z.B. die Bücher von Mertens zur Integrierten Informationsverarbeitung (vgl. [Mertens 2013]).

Alle oben beschriebenen Daten haben eines gemeinsam, sie bestehen aus Zeichenfolgen, die aus einem Zeichenvorrat nach bestimmten Regeln erzeugt werden.

2.3 Zeichen, Zeichenvorrat

Zeichen (Symbole) sind Elemente zur Darstellung von Informationen. Ein Zeichenvorrat (Alphabet) ist die Menge aller vereinbarten oder verfügbaren Zeichen für eine Darstellung von Informationen. Im einfachsten Fall definiert man die Menge der Zeichen durch das Aufzählen ihrer Elemente, z.B. so:

Ziffern von 0 bis 9

Buchstaben von a bis z und A bis Z

Sonderzeichen: .,?! _ -+* usw., aber auch

Farben, z.B. schwarz, weiß, rot, grün, blau usw., oder

Schuhgrößen, z.B. 36 bis 46

Man unterscheidet

numerische Daten, die aus Ziffern und gegebenenfalls einem Vorzeichen gebildet werden.

alphabetische Daten, die nur aus Buchstaben gebildet werden.

alphanumerische Daten, die aus beliebigen Zeichen (Ziffern, Buchstaben und Sonderzeichen) gebildet werden.

Es gibt aber auch Daten, die nicht aus einzelnen Zeichen zusammengesetzt sind, z.B. Videos, Bilder und Töne. Sie können unter den Stichworten

Grafische Daten, Akustische Daten

grafische Daten, die Grafiken bzw. Bilder entweder über einzelne Bildpunkte mit den dazugehörenden Koordinaten oder über Vektoren beschreiben, und

akustische Datenwie Töne, gesprochene Worte usw.

zusammengefasst werden.

Es gibt auch andere. Zum Beispiel im Internet, wo unsere Daten inzwischen intensiv ausgewertet werden. Da sind natürlich auch Bilder, Videos und Attribute dabei (Name, Alter, usw.), aber auch Beziehungsdaten, die man im SocialWeb erzeugt ("mag ich, mag ich nicht").

Daten im Internet

Ein Bereich, der von Informatik und Wirtschaftsinformatik beharrlich übersehen wird, die Fachinformationsdatenbanken, verwaltet schon seit Jahrzehnten weitere Arten von Daten. Die Vielfalt ist sehr groß. Die wichtigsten Datenarten und Datenbanktypen:

Fachinformationsdatenbanken

Dokumente in Dokumentendatenbanken (auch Faktendatenbanken) zur Verwaltung beliebiger Dokumente.

Bibliographische Information in Bibliographischen Datenbanken

Volltexte in Volltextdatenbanken zur Verwaltung von Texten

Zeitreihen in Statistischen Datenbanken

Statistische Datenbanken mit Merkmalsräumen

Naturwissenschaftliche Daten aller Art in entsprechenden Datenbanken zu Messwerten, Kernresonanzspektren, usw.

Chemische Strukturformeln in Chemiedatenbanken

Mehr dazu in [Staud 2022b, Kapitel 17]. Ein Beispiel für einen Anbieter solcher Datenbanken ist das FIZ Karlsruhe. Vgl. für einen Überblick:

https://www.fiz-karlsruhe.de/de/ produkte-und-diensleistungen/produkte-dienstleistungen

2.4 Attribute

Die meisten der oben beschriebenen Daten stellen Eigenschaften von Ojekten und Beziehungen dar. Diese Eigenschaften sind es auch, die in Datenbanken erfasst werden. Für Datenbankzwecke werden sie etwas formaler gefasst und Attribute genannt.

Ein großer Teil des klassischen Datenbankgeschehens beruht tatsächlich auf Attributen. Es gibt auch andere Informationen in anderen Datenbanken, aber in wichtigen Bereichen liegen attributbasierte Datenbanken vor, die meist als Relationale Datenbanken realisiert sind. Vor allem in den Unternehmen und sonstigen Organisationen. Mit Hilfe von Attributen wird also die Information erfasst, die in der Datenbank gespeichert wird. Etwas konkreter und auf die heutige Datenbanktechnologie bezogen: Durch sie werden die zu erfassenden Objekte und Beziehungen (vgl. die Abschnitte 3.2 und 3.3) identifiziert und beschrieben. Außerdem erfolgt mit ihrer Hilfe dann auch die Abfrage der Datenbestände. SQL, die Abfrage-, Auswertungs- und Verwaltungssprache für relationale Datenbanken baut vollkommen auf Attributen auf (vgl. zu SQL Kapitel 19).

Attributbasierte Datenbanken

Wie sind nun diese Attribute strukturiert? Sie besitzen eine Bezeichnung, verschiedene Attributsausprägungen und Objekte oder Beziehungen, die sie beschreiben. Betrachten wir einige Beispiele:

Struktur von Attributen

Widmer, Maier, usw. als Namen von Angestellten in einem Unternehmen

Schwarz, weiß, grau, rot, ... als Farben von Autos

Männlich, weiblich als Geschlecht von Katzen

126 als Messwert des Blutzuckers bei Diabetikern

5, 10, 20, 50, ... als Dauer von Ehen in Jahren

450,00 Euro als Preis eines Datenbanksystems bei einem bestimmten Händler

5000,00 Euro oder ein anderer positiver Betrag als Gehalt von Menschen

10050, 10051, ... als Personalnummer von Angestellten

1,7 oder eine andere Zahl zwischen 1 und 5 als Note von Hochschulklausuren

Alle unterstrichenen Wörter: Name, Farbe, Geschlecht, Blutzucker, Ehedauer, Gehalt, Personalnummer und Note sind Beispiele für Attributsbezeichnungen.

Alle kursiv gesetzten Wörter und Zahlen sind Beispiele für Attributsausprägungen, d.h. von Werten, die ein Attribut annehmen kann. Die Zahl vonAusprägungen muss mindestens 2 sein (zum Beispiel bei Geschlecht), sie kann einige umfassen (Farbe von Autos) oder viele (Namen, Messwerte).

Attribute können bestimmte Werte annehmen, diese werden Attributsausprägungen genannt.

Alle fett gesetzten Wörter: Angestellte, Autos, Katzen, Diabetiker, Ehen, Datenbanksysteme, Menschen, Hochschulklausuren bezeichnen Objekte und Beziehungen (im allgemeinsten Sinn). Diese werden durch die Attribute und ihre Ausprägungen beschrieben. Sie müssen angegeben werden, da sonst nicht klar ist, worauf sich die Attribute beziehen. Dieser Zusammenhang zwischen Attributsbezeichnungen, -ausprägungen und Objekten / Beziehungen ist grundlegend und wie folgt:

Objekte

Attribute haben eine bestimmte Menge von Attributsausprägungen.

Objekten / Beziehungen werden Attribute zugeordnet

Ein Objekt hat für jedes Attribut eine gültige Attributausprägung, manchmal auch mehrere (vgl. zu letzterem das Attribut Hobby in der Tabelle unten).

Vgl. hierzu das mit derselben Aufgabe bedachte (Zuweisung von Eigenschaften) semantisch ärmere Konzept der Key/Value-Tupel. Hier beschrieben in den Abschnitten 24.8 und 24.10.

Wenn man also, ganz am Anfang der Datenmodellierung und bei der Analyse eines Anwendungsbereichs etwas wahrnimmt und erfassen möchte, muss man zuerst entscheiden, ob es ein Attribut, eine Attributsausprägung oder ein Objekt / ein Beziehung bezeichnet. Oder etwas ganz anderes: Video-, Audiosequenz, chemische Strukturformel, Beziehungsdaten aus dem Social Web, usw.

Vgl. hierzu Kapitel 3 zur sog. Konzeptionellen Modellierung

Dieses "etwas" wird auch als Realweltphänomen bezeichnet, d.h. alles, was wir mit unserer körperlichen und geistigen Ausstattung als Menschen wahrnehmen können; z.B. einen AUDI A6, die Katze Miezi, die telefonische Bestellung des Kunden Kaiser, die mündliche Prüfung der Studierenden Müller. Hier stoßen wir an biologische und erkenntnistheoretische Fragen, die, was letztere angeht, z.B. in der sog. Konzeptionellen Datenmodellierung (Kapitel 3) oder "davor" in der Erkenntnistheorie, Psychologie, usw. behandelt werden.

Erkennen wir etwas als Attribut, dann müssen wir die Ausprägungen suchen oder auch festlegen. Außerdem muss geklärt werden, auf welche Objekte es sich bezieht. Dies ist wichtig, weil Attributsbezeichnungen das Attribut alleine nicht definieren. Z.B. kann ein Attribut Größe sich auf Menschen, Tiere oder ein materielles Gut beziehen. Auch die grundsätzliche Entscheidung, ob etwas Attribut ist, ist nicht immer so einfach wie bei Gehalt oder Personalnummer von Angestellten. Liegt z.B. Programmiersprache (PS) vor, als Attribut, das die Programmiersprachenkompetenz von Entwicklern in einem Softwarehaus festhält, wird es schwieriger. Dann muss wirklich entschieden werden, ob diese Information als Attribut von Angestellten behandelt wird oder ob es selbst zum Objekt wird. Diese Frage ist Gegenstand von Kapitel 3.

"Etwas" ist Attribut

Wird es als Attributsausprägung erkannt, muss man die Bezeichnung des Attributs und die übrigen Ausprägungen suchen oder festlegen und kann dann auch das zugehörige Objekt ableiten. So kann man von einfließenden Geldbeträgen, z.B. in einem WebShop, auf Rechnungssumme und die dazugehörigen Rechnungen und Kunden schließen. Oder von der Zahl 1,7 auf Noten und die zugehörigen Klausuren. Oder von einer Ortsangabe auf ein Attribut Ort in Adressangaben.

"Etwas" ist Attributsausprägung

Wird es als Objekt oder Beziehung erkannt, müssen die einschlägigen Attribute und ihre Ausprägungen gesucht bzw. festgelegt werden. Z.B. wenn im Rahmen eines Projekts zur Datenbankerstellung dem Modellierer Rechnungen, Lieferscheine und Produkte vorgelegt werden.

"Etwas" ist Objekt oder Beziehung

Damit stellt sich zu Beginn jeder Datenmodellierung, bei der Betrachtung des Weltausschnitts oder Anwendungsbereichs, immer die Frage: Was beschreibt, was wird beschrieben?

Anfangsfragen

In einer mehr technischen Sprache: Welches sind im Anwendungsbereich die Objekte, welche Attribute haben diese und welche Ausprägungen haben die Attribute.

In der angelsächsischen Literatur wird die Menge der Attributsausprägungen eines Attributs mit domain bezeichnet, weshalb sich in der deutschsprachigen Literatur auch die Bezeichnung Domäne findet.

Domain und entity

Eigenschaften von Attributen

Attribute können nach verschiedenen Kriterien unterschieden werden. Eines davon hat auch im Zusammenhang mit Datenbanken Bedeutung und soll deshalb hier betrachtet werden. Es betrifft die Art und Weise, wie das jeweilige Attribut beschreibt. Unterschieden werden dabei:

identifizierende Attribute

qualitative Attribute

rangskalierte Attribute

quantitative Attribute

Identifizierende Attribute sind eindeutige Bezeichnungen der Objekte bzw. Beziehungen. Oft z.B. Namen (z.B. von Datenbanksystemen, von Unternehmen) oder eindeutige Nummern (z.B. Personalnummern oder Artikelnummern). Ihr Kennzeichen ist die Eindeutigkeit, d.h. jedes Objekt bzw. jede Beziehung wird durch eine andere Attributsausprägung benannt. Personennamen gehören hier im übrigen meist nicht dazu, auch nicht Postleitzahlen, wenn es um Orte geht (da viele Orte mehrere Postleitzahlen haben).

Identifizierend

Attribute dieses Typs dienen im Datenmodell - in Bezug auf ihre Objekte / Beziehungen - als Schlüssel, d.h. als identifizierende Information.

Dasselbe Attribut kann für die einen Objekte identifizierend sein und für die anderen nicht. Nehmen wir als Beispiel die Bezeichnungen von Programmiersprachen (C, COBOL, FORTRAN, usw.). Für die Objekte Programmiersprachen wäre dies ein identifizierendes Attribut, für Angestellte, wo jedem Angestellten die Programmiersprachen zugeordnet werden, die er oder sie beherrscht, ein beschreibendes (qualitatives) Attribut.

In den folgenden Kapiteln wird es noch mehrmals um Schlüssel gehen, hier ein Erstkontakt. Ist also ein Attribut so konstruiert, dass es für jedes Objekt / jede Beziehung eine andere Ausprägung hat, dann wird es Schlüssel (oder: Schlüsselattribut) genannt. Der Schlüssel dient somit zur eindeutigen Identifizierung eines Objekts / einer Beziehung. So ist z.B. die Personalnummer ein Schlüsselattribut für Angestellte. Der Name kann es nicht sein, er ist nicht eindeutig (meist gibt es mehrere Angestellte mit den Namen Maier, Müller oder Schulze). Bei der Datenbankabfrage dienen Schlüssel zur Identifizierung einzelner Objekte und Beziehungen.

Schlüssel: Definition 1

Während obiger Attributstyp identifizierenden Charakter hat, dienen die folgenden drei der weitergehenden Beschreibung der Objekte bzw. Beziehungen. Sie beruhen auf dem Gegensatz qualitativ/quantitativ, wie er aus der Statistik (genauer: der statistischen Messtheorie) bekannt ist.

Qualitative Attribute beschreiben die Objekte nicht-numerisch ("qualitativ"). Sie dienen der Differenzierung zwischen Objekten und nicht dem "in Beziehung setzen", weshalb auch in der Regel mehrere Objekte dieselbe Attributsausprägung aufweisen. Einige Beispiele hierzu:

Qualitative Attribute

Geschlecht, Name, Vorname für Menschen

TypDBS (Datenbanksystemtyp), Produzent eines Datenbanksystems für Datenbanksysteme

Abteilung(szugehörigkeit), PS (beherrschte Programmiersprachen), Gehalt für die Angestellten eines Unternehmens

Bezeichnung für technische Geräte aller Art

Bei der Datenbankabfrage dienen qualitative Attribute der inhaltlichen Festlegung der Suchmenge. Z.B. indem in einer entsprechenden Datenbank nach allen Angestellten gesucht wird, die in der Abteilung "IT" arbeiten und die fähig sind in Java zu programmieren. In Beziehung gesetzt werden können diese Attribute nur durch den Gleich/ungleich-Operator. Also zum Beispiel:

Geschlecht='w' (Auswahl aller weiblichen Angestellten)

TypDBS='RDBS' (Auswahl aller Relationalen Datenbanksysteme)

PS='Java' (Wer kann Java?)

Abteilung='IT' (Auswahl aller Angestellten in der IT-Abteilung)

In der Regel haben bei qualitativen Attributen mehrere Objekte dieselbe Attributsausprägung.

Rangskalierte Attribute drücken eine Rangfolge unter den Objekten / Beziehungen aus. Z.B. durch Noten oder Einschätzungen (schlecht, gut, hervorragend). Oft sind die Ausprägungen numerisch, allerdings kann mit ihnen nicht rechnerisch gearbeitet werden. Bei ihnen ist der Abstand zwischen den Werten nicht interpretierbar, nur die Rangfolge: 1. Preis, 2. Preis, usw. Nicht mal ein Mittelwert ist da eigentlich zulässig, wird aber oft berechnet.

Rangskalierte Attribute

Quantitative Attribute beschreiben die Objekte und Beziehungen numerisch und zwar so, dass die Ausprägungen verglichen werden können und dass man mit ihnen rechnen kann. Einige Beispiele:

Quantitative Attribute

Preise, MaxDS (maximale Anzahl Datensätze) für Datenbanksysteme

Alter, Gehalt für die Angestellten eines Unternehmens

Preis für Lagerartikel (eines WebShops)

Diese Attributsart dient bei der Abfrage ebenfalls der inhaltlichen Festlegung der Suchmenge, z.B., wenn Datenbanksysteme mit einem Preis kleiner 3000,-- Euro gesucht werden. Die Ausprägungen quantitativer Attribute können - zusätzlich zum Gleich/Ungleich-Operator" auch mit dem Kleiner-/Größer-Operator in Beziehung gesetzt werden. Wichtiger ist, dass man mit den Ausprägungen quantitativer Attribute rechnen kann. In der Grundausstattung von SQL sind dann auch gleich Funktionen für die Aufsummierung, die Mittelung, das Finden des kleinsten/größten Werts, usw. enthalten.

In der Regel haben bei quantitativen Attributen mehrere Objekte dieselbe Attributsausprägung.

Nicht alles, was quantitativ erscheint, ist auch so. Zum Beispiel Personalnummern. Das Kriterium der Unterscheidung qualitativer und quantitativer Attribute ist einfach: Dient die Information - alphanumerisch oder numerisch - nur zur Unterscheidung der Objekte, ist sie qualitativ. Dient sie auch zu Berechnungen, ist sie quantitativ.

Quantitativ?

Attribute als solche haben mit den konkreten Datenbanksystemen noch nichts zu tun. Dort stehen dann für die Attribute die Datentypen zur Verfügung (wie Integer, Real, Date, usw.). Vgl. hierzu Kapitel 18. Gleiches gilt für moderne Informationstypen wie Audio, Video, usw., die in Datenbanksystemen meist durch Binary Large Objects (BLOBs) realisiert werden. Der Begriff Attribut ist auf der Modellebene angesiedelt (auf der wir uns hier befinden), der Begriff Datentyp auf der Ebene der physischen Datenorganisation.

Attribute vs. Datentypen

Die folgende Abbildung fasst die Ausführungen zu Attributen zusammen.

Abbildung 2.4-1: Das Attributkonzept - zusammengefasst

3 Konzeptionelle Modellierung

Hinweis: Nicht verwirren lassen. Seit einigen Jahren taucht in der Fachliteratur der Ausdruck "konzeptuelle Modellierung" statt "konzeptionelle Modellierung" auf. Dies ist wahrscheinlich vom englischen Fachbegriff "conceptual" her motiviert. Beide Begriffe bedeuten dasselbe.

Exkurs: Informationsträger

Für Objekte im hier gebrauchten Sinn wird in der angelsächsischen Literatur nicht der Begriff object, sondern der Begriff entity verwendet. Dieser bedeutet, betrachtet man den Sprachgebrauch, soviel wie Informationsträger im Sinne von: Alles was durch Informationen (hier im wesentlichen Attribute) beschrieben werden kann. Einige deutschsprachige Autoren verwenden für entity das Wort Entität.

3.1 Anwendungsbereiche

Am Anfang des Datenbankdesigns steht die Analyse des Anwendungsbereichs für den die Datenbank zu erstellen ist. Dieser wird meist Anwendungsbereich genannt. Z.B. die Abteilung Vertrieb eines Unternehmens. Oder ganze Unternehmen, wenn zum Beispiel für eine integrierte prozessorientierte Software (wie sie z.B. SAP herstellt) die Datenbank eingerichtet werden soll. Aber auch kleine Anwendungsbereiche sind denkbar. Z.B. wenn ein Unternehmen für seine Produkte versucht, den Absatz vorherzusagen und wenn dafür eine Datenbank eingerichtet wird. Und auch wenn man sich entschließt, die Filmesammlung in einer Datenbank zu verwalten und dafür Daten zu erfassen, stellt diese einen Anwendungsbereich dar.

Ganz besonders spannende und auch große Anwendungsbereiche finden sich im Internet. Nicht nur Geheimdienste sammeln dort Informationen und legen damit Datenbanken an, sondern zum Beispiel auch Versicherungsunternehmen. Diese werten die Daten des SocialWeb aus und versuchen, daraus wirksame Angebote für die Internetnutzer zu generieren ("Sie sind Mutter geworden. Dürfen wir Ihnen eine Ausbildungsversicherung anbieten...").

Internet

Doch nun zurück zu den "normalen" Anwendungsbereichen, vor allem zu denen in Unternehmen. In allen diesen Fällen interessiert beim Datenbankdesign nicht nur der Anwendungsbereich als solcher, sondern die in ihm realisierten Tätigkeiten, die Geschäftsprozesse, für die die Daten benötigt werden und in denen abzuspeichernde Daten entstehen. Anders ausgedrückt: Hier stellt sich beim Datenbankdesign zunächst die Frage, welche Daten die Geschäftsprozesse des Anwendungsbereiches benötigen und welche sie erzeugen.

Nun ist so ein Anwendungsbereich sehr vielfältig. In ihm finden sich Aufgaben, Handelnde, Geschäftsobjekte (wie Rechnungen, Bestellungen Überweisungsbelege, usw.), Organisationsstrukturen und vieles mehr. Für das Datenbankdesign vereinfacht sich die Sache glücklicherweise, da können wir uns auf Objekte und - später - die Beziehungen zwischen ihnen konzentrieren. Das Finden dieser Objekte und Beziehungen wird im Rahmen der konzeptionellen Datenmodellierung geleistet.

Abstraktion

Geht es beim Datenbankentwurf um Organisationen (wie immer: Unternehmen, Verwaltungen, usw.), dann gehört zur Analyse des Anwendungsbereichs auch die Analyse der in ihm realisierten Tätigkeiten (der Geschäftsprozesse), für die die Daten benötigt werden und in denen abzuspeichernde Daten entstehen. Anders ausgedrückt: Im Datenbankentwurf stellt sich in diesen Fällen zunächst die Frage, welche Daten die Geschäftsprozesse des Anwendungsbereiches benötigen und welche sie erzeugen.

Anwendungsbereiche mit Geschäftsprozessen

Hier einige Beispiele für Anwendungsbereiche mit hoher Relevanz von Geschäftsprozessen:

Beispiele

Anwendungsbereich Gesamtunternehmen mit allen Geschäftsprozessen und Funktionen, die realisiert werden. Zum Beispiel, wenn für das Unternehmen eine umfassende Datenbank für eine ERP-Software erstellt werden soll.

Anwendungsbereich Abteilung eines Unternehmens (z.B. Vertrieb, Beschaffung, Personalwesen) mit den dort vorliegenden Geschäftsprozessen und Funktionen.

Logistikkette einer Spedition

Hotelkette mit weltweiten Buchungen

Internetunternehmen mit vollautomatisierten Geschäftsprozessen und umfassender Datenbank.

Studienbetrieb einer Hochschule

Markt für Datenbanksysteme

Angestellte eines Unternehmens

Die letzten drei sind hier didaktisch motiviert und tauchen - mit einfachen Beispielen - in den Kapiteln zur relationalen Modellierung immer wieder auf. Der Anwendungsbereich Markt für Datenbanksysteme dient auch als Beispiel im SQL-Kapitel.

Obige Schriftgestaltung basiert auf den typographischen Festlegungen von Abschnitt 1.2.

3.2 Objekte und Beziehungen erkennen

Bei der Analyse des Anwendungsbereichs geht es im ersten Schritt darum, die (datenbanktechnisch wichtigen) Objekte und Beziehungen zu finden oder festzulegen. Denn genau diese werden in Datenbanken erfasst.

Der einfache Fall

Im einfachsten Fall nehmen wir Objekte und Beziehungen einfach wahr. Meist ist es jedoch nicht so einfach, sondern muss genauer geklärt werden. Dabei ist der Attributbegriff hilfreich. Denn Objekte und Beziehungen werden in Datenbanken durch ihre Attribute (in Feldern) beschrieben, diese macht sie für die Datenbank existent. Zu leisten ist dabei folgendes:

Zuerst muss das Attribut gefunden werden, welches die Objekte und Beziehungen identifiziert. Dies ergibt sich oft von selbst, wie Fall einer Personalnummer oder einer eindeutigen Bezeichnung ("Bezeichnung Kraftfahrzeug"), muss aber oft auch gesucht oder festgelegt werden. Manchmal sind auch nur mehrere Attribute zusammen identifizierend, vor allem bei Beziehungen. Dazu später mehr. Möglich ist auch, dass es mehrere identifizierende Attribute zu denselben Objekten oder Beziehungen gibt. Dies führt dann in der Datenbank zu Primär- und Sekundärschlüsseln. Auch dazu unten mehr.

Schritt 1: Attribute identifizieren

Der zweite Schritt besteht darin, die beschreibenden Attribute zu finden oder festzulegen. Dies ist ein wichtiger Schritt und einer der wohlbedacht sein muss:

Schritt 2: Attribute festlegen

Es werden genau die Attribute den Objekten bzw. Beziehungen zugeordnet, die für die Abwicklung der Geschäftsprozesse im zugehörigen Anwendungsbereich benötigt werden.

Früher sprach man statt von den Geschäftsprozessen, die durch die Datenbank unterstützt werden, vom Zweck der Datenbank. In einfachen Fällen ist auch heute noch diese Formulierung sinnvoll. Nehmen wir als Beispiel eine Datenbank, die eine einzelne Aufgabe unterstützen soll, z.B. die Absatzprognoserechnung für die Produkte eines Unternehmens. Hier werden die Attribute von dieser einzelnen Aufgabe abgeleitet.

Durch Analyse der Attribute

Eine im Bereich der relationalen Modellierung immer tragfähige Vorgehensweise ist die Identifizierung von Objekten (und danach auch von Beziehungen) durch Attributanalyse. Es gilt folgende Regel: Werden irgendwelche Realweltphänomene durch ein Attribut identifiziert, dann ist dieses erst mal ein einfaches beschreibendes Attribut.

Zum Beispiel Abteilungsbezeichnungen (AbtBez). Diese können den Angestellten zugewiesen werden, um festzuhalten, in welcher Abteilung sie arbeiten:

Bsp. 1

Attribut: AbtBez

Objekte: Angestellte

Oder die Personalnummern (PersNr) von Angestellten, durch die festgehalten wird, in welchen Projekten sie mitarbeiten:

Bsp. 2

Attribut: PersNr

Objekte: Projekte

Hier werden die Ausprägungen von PersNr den Projekten zugewiesen und halten fest, wer in welchem Projekt mitarbeitet.

Oder eine Angabe zu den von Angestellten eines Softwarehauses beherrschten Programmiersprachen, für jeden Angestellten seine wichtigste (ProgSpr):

Bsp. 3

Attribut: ProgSpr

Objekte: Angestellte

Identifizierung + Beschreibung => Objekt

Kommt nun aber bei der Beschreibung des Realweltphänomens zu der Benennung nur ein einziges beschreibendes Attribut dazu, erfolgt ein qualitativer Sprung: Die Beschreibung etabliert nun für die Datenmodellierung Objekte bzw. Beziehungen. In den obigen Beispielen:

Das Attribut AbtBez wird ergänzt durch das Attribut Abteilungsleiter (AbtLeiter) (und später noch viele mehr):

zu Bsp. 1

Attribut 1: AbtBez

Attribut 2: AbtLeiter

Jetzt geht es um Abteilungen (sie werden identifiziert und zusätzlich beschreiben). Abteilungen sind datenbanktechnisch zu Objekten geworden. Die Abteilungszugehörigkeit muss jetzt auf andere Weise erfasst werden.

Das Attribut PersNr wird ergänzt durch das Attribut Name (und später noch viele mehr):

zu Bsp. 2

Attribut 1: PersNr

Attribut 2: Name

Jetzt geht es um Angestellte (sie werden identifiziert und zusätzlich beschrieben), sie sind datenbanktechnisch zu Objekten geworden. Die Projektmitarbeit muss jetzt auf andere Weise erfasst werden.

Das obige Attribut ProgSpr wird ergänzt um das Attribut (verwendeter) Compiler:

zu Bsp. 3

Attribut 1: ProgSpr

Attribut 2: Compiler

Jetzt geht es um Programmiersprachen (sie werden identifiziert und zusätzlich beschrieben), auch sie sind datenbanktechnisch zu Objekten geworden. Die Programmierkompetenz muss jetzt auf andere Weise erfasst werden.

Jeweils ein weiteres Attribut genügt also für die Etablierung der Objekte und Beziehungen. Für Beziehungen gilt dies genauso, wenn ein einzelnes Attribut die Beziehung identifiziert ("Transaktionsnummer"). Meist werden in der relationalen Modellierung aber (mindestens) zwei Attribute zur Identifizierung von Beziehungen benötigt (vgl. Kapitel 5).

Mit obigem Regelwerk ist es einfach, Objekte und Beziehungen im datenbanktechnischen Sinn zu erkennen:

Wird ein Realweltphänomen durch ein Attribut (oder mehrere) identifiziert und durch mindestens ein weiteres beschrieben, handelt es sich datenbanktechnisch um ein Objekt oder eine Beziehung.

Vgl. zur Schriftgestaltung die typographischen Festlegungen von Abschnitt 1.2.

Im nächsten Schritt werden alle gleich strukturierter Objekte und Beziehungen zusammengefasst. "Gleich strukturiert" bedeutet hier "dieselben Attribute besitzen". Daraus entstehen dann Gruppen gleichartiger Objekte und Beziehungen, die Klassen genannt werden:

Schritt 3: Klassen bilden

Die Objekte und Beziehungen, die dieselben Attribute besitzen, werden zu Objektklassen bzw. Beziehungsklassen zusammengefasst.

Dies erfolgt oft schon automatisch beim ersten Schritt, beim Erkennen der Objekte und Beziehungen, wo wir unbewusst schon gleich an alle Studierende, an alle Angestellten, usw. denken, wenn wir die entsprechenden Objekte wahrnehmen. Diese Klassenbildung ist aber nicht immer so einfach und muss auf jeden Fall über die Attribute überprüft werden. Dies soll an einigen der oben eingeführten Beispiele verdeutlicht werden.

Exkurs für alle, die mit der objektorientierten Theorie vertraut sind:

So wie der Begriff Klasse hier verwendet wird, ist er durchaus verträglich mit dem entsprechenden Begriff der objektorientierten Theorie. Er soll aber nicht gleich gesetzt werden, denn dort gehört noch mehr dazu: Klassenattribute, Methoden, usw. Vgl. für eine Einführung [Staud 2019].

3.3 Beispiele

Im Studienbetrieb einer Hochschule sind unschwer die Objekte Studierende, Dozenten, Vorlesungen und Veranstaltungsräume zu erkennen. Sie werden identifiziert und beschrieben:

Studienbetrieb einer Hochschule

Studierende z.B. durch eine Matrikelnummer (MatrNr), den Namen, Vornamen, usw.

Dozenten durch eine Dozentennummer (DozNr), das gehaltene Fach, usw.

Vorlesungen durch ihre Kurzbezeichnung (BezVorl), das Semester, in dem sie gehalten werden, usw.

Veranstaltungsräume durch ihre Bezeichnung (BezRaum), die Anzahl der Sitzplätze, die Ausstattung, usw.

Auch eine Beziehung ist gleich erkennbar: Vorlesungsbesuch. Sie könnte Vorlesungen, Studierende und Dozenten verknüpfen. Vorlesungen und Veranstaltungsräume könnten auch einfach nur beschreibende Attribute bei anderen Objekten oder Beziehungen sein, z.B. bei Vorlesungsbesuch. Alle diese Objekte und Beziehungen werden dann auch zu Klassen.

Im (Markt für) Datenbanksysteme sind auf Anhieb folgende Objekte erkennbar, die dann auch zu Objektklassen aggregiert werden:

Markt für Datenbanksysteme

die Datenbanksysteme selbst, z.B. Oracle, DB2, ACCESS, MySQL, CouchDB

die Firmen, die diese Software programmieren lassen und auf den Markt bringen: Oracle, IBM, Microsoft usw.

die Händler, die diese Software dem Endkunden zum Verkauf anbieten

Ebenfalls sofort erkennbar sind die Beziehungen "stellt her" und "bietet an". Erstere stellt die Datenbanksysteme mit den Produzenten in Beziehung, letztere die Datenbanksysteme mit den Händlern. Objekte und Beziehungen werden diese aber nur, weil wir auch sofort Attribute erkennen, auch identifizierende, die dann zu Schlüsseln werden (Bsp. Produktname, Firmenname, Händlername usw.).

Auch die beschreibenden Attribute sind leicht zu finden. Für die Datenbanksysteme liegen die Attribute Bez (Bezeichnung), Typ (relationales Datenbanksystem, objektorientiertes Datenbanksystem, NoSQL-System, ...), Plattform und deren jeweiliger Listenpreis (LPreis) nahe. Für die Produzenten (also die Unternehmen Oracle, IBM, Microsoft usw.) könnte man die Attribute Bez, Land und die Adresse im World Wide Web (WWW) erfassen. Für die Händler liegen die Attribute Bez, Ort, Straße, Telefonnummer (Tel) und Mailadresse (EMail) nahe.

Beschreibende Attribute

Bezüglich der Beziehung "Händler bietet ein Datenbanksystem auf dem Markt an" (bietet an) könnte der Preis festhalten werden, zu dem dies geschieht. Die Beziehung "Produzent stellt ein Datenbanksystem her" (stellt her) könnte Attribute wie Beginn und Ende erhalten.

Die folgende Tabelle fasst die jetzt festgelegten Objektklassen und Beziehungsklassen mit ihren Attributen zusammen.

(Markt für) Datenbanksysteme

Objekt-, Beziehungsklasse

Attribute

Datenbanksysteme

Bez, Typ, Plattform, LPreis

Produzenten

Bez, Land, WWW

Händler

Bez, Ort, Straße, Tel, EMail

bietet an

Preis

stellt her

Beginn, Ende

Die Klassenbildung ist nicht immer so einfach wie in diesen Beispielen. Würden wir uns z.B. dazu entschließen, für die einzelnen Arten von Datenbanksystemen spezifische Attribute zu erfassen, z.B. Dokumentart für NoSQL-Datenbanksysteme oder die Art der Vererbungstechnik bei objektorientierten Systemen, könnten wir diese nicht in einer einzigen Objektklasse zusammenpacken. Sie müsste aufgespaltet werden (vgl. dazu Abschnitt 14.1).

3.4 Zusammenfassung

Die konzeptionelle Modellierung für relationale Datenbanken klärt die für die Anwendung wichtigen Objekte und Beziehungen und - in einem ersten Schritt, der später verfeinert wird - deren Aggregation zu Objekt- und Beziehungsklassen. Dies geschieht wesentlich durch die Analyse der Attribute. Kurz gefasst gilt:

Ein Realweltphänomen, das durch ein Attribut (oder mehrere) identifiziert und durch mindestens ein weiteres beschrieben wird, ist datenbanktechnisch existent und wird zu einem Objekt oder einer Beziehung. Objekte und Beziehungen, die dieselben Attribute habe, werden zu Objekt- bzw. Beziehungsklassen zusammengeführt.

Soweit der erste Schritt, das Erkennen von Objekten und Beziehungen. Er führt in der Regel zu einer Vielzahl von Informationen, die weiter strukturiert werden. Bei dieser Strukturierung kann es auch ohne weiteres geschehen, dass Objekte als solche wieder verschwinden oder dass neue entstehen.

Obwohl dieses Zusammenstellen von Objekten und Beziehungen nur den Einstieg darstellt, ist es der erste und wichtige Schritt bei der Erstellung eines Datenmodells. Am besten führt man ihn so durch, dass alle Beteiligten ihre Ideen und Vorschläge zusammentragen. Zu den Beteiligten gehören neben den Datenbankspezialisten auch die zukünftigen Nutzer der Datenbank, z.B. Mitarbeiter des Lagers, wenn es um eine Datenbank für das Lagerwesen geht oder Mitarbeiter der Beschaffung, wenn das Beschaffungswesen in einer Datenbankanwendung erfasst werden soll. Oftmals fallen die beiden Gruppen allerdings zusammen oder die Nutzergruppe steht erst mal nicht zur Verfügung.

Schrittweises Verfeinern

Mehr Semantik

Obiges Erfassen von Objekten und Beziehungen ist der erste Schritt. Anschließend erfolgt die Erfassung weiterer semantischer Aspekte, die für den Anwendungsbereich wichtig sind. Nur um dies anzudeuten, hier ein Beispiel:

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

Beispiel Lehrbetrieb

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.

Die Semesterpläne müssen die aktuelle Studienordnung umfassend widerspiegeln.

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 und später in Datenbanken erfasst werden, was zu den oben schon erwähnten semantischen Integritätsbedingungen führt.

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

Datenbank oder Anwendungs-
programme?

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 umfassend umgesetzt werden.

Allerdings hat uns die jüngste Vergangenheit gelehrt, dass in bestimmten Anwendungsbereichen (Internet, BigData) die durch die Erfassung von Semantik erforderliche größere Komplexität der Datenstrukturen hinderlich ist. Das beginnt schon bei einfacher referentieller Integrität (vgl. Kapitel 5) und verschärft sich bei komplexeren semantischen Integritätsbedingungen. Vgl. Kapitel 24.

Internet, BigData

Vertiefung

Die Ausführungen in diesem Kapitel stellen nur die Grundlagen der konzeptionellen Modellierung dar. Für eine vertiefte Betrachtung empfiehlt sich die einschlägige Literatur, z.B. [Olivé 2007]. Vieles spielt sich hier allerdings in Tagungen und deren Tagungsbändenab. Vgl. beispielhaft [Ng, Storey, Trujillo et al. 2013].

4 Relationen bilden

Hier beginnt Teil II: Relationale Datenmodelle

mit den Kapiteln

4 Relationen bilden

5 Beziehungen erkennen und einrichten

6 Zusammenfassung Grundlagen

Die oben gefundenen Objekte und Beziehungen werden nun zu einem relationalen Datenmodell zusammengeführt, mit dessen Hilfe dann später mit Hilfe eines relationalen Datenbanksystems die Datenbank erstellt wird. Ein Datenmodell ist ein Abbild des jeweiligen Anwendungsbereichs, das mit den Mitteln und gemäß den Regeln des jeweiligen datenbanktheoretischen Ansatzes realisiert wurde. In den nächsten Kapiteln wird nun betrachtet, welche "Mittel und Regeln" die relationale Theorie [Anmerkung] für die Erstellung von Datenmodellen zur Verfügung stellt.

Andere Modellierungstheorien haben natürlich andere Werkzeuge. Um nur die beiden "benachbarten" zu nennen: Die ER-Modellierung benutzt neben wichtigen Metaregeln u.a. Entitäts- und Beziehungstypen, um zu Modellen zu kommen, die objektorientierte (Daten)Modellierung Klassen, Methoden, Assoziationen, usw.

4.1 Von Klassen zu Relationen

Im nächsten Schritt wird nun jede der oben eingeführten Objekt- und Beziehungsklassen - falls letztere in der konzeptionellen Datenmodellierung bereits gefunden wurden - in einer Tabelle erfasst. Dies geschieht wie folgt:

die Attributsbezeichnungen stehen im Kopf der Spalten

darunter folgen Zeile für Zeile die Attributsausprägungen, die ein Objekt bzw. eine Beziehung beschreiben, geordnet nach der Attributsanordnung in der Kopfzeile. Diese Zeilen werden in der relationalen Theorie Tupel genannt.

Betrachten wir das Beispiel der Objektklasse Angestellte. Die Tabelle kann (in einfacher und abstrahierter Form) so aussehen, wie unten angegeben. Die Angestellten werden durch folgende Attribute beschrieben:

Beispiel: Objektklasse Angestellte

Personalnummer (PersNr)

Name

Vorname (VNname)

Datum der Einstellung (DatEinst)

Geburtstag (GebTag)

Eines der Attribute muss identifizierenden Charakter haben, hier ist es die Personalnummer. Es wird Schlüssel (der Relation) genannt und durch eine Raute gekennzeichnet (mehr dazu weiter unten). Für die Objektklasse Angestellte entsteht also eine Tabelle wie die folgende:

Schlüssel: Definition 2

Tabelle Angestellte

PersNr

Name

VName

DatEinst

GebTag

1001

Müller

Karolin

1.3.2010

14.5.1985

1010

Jäger

Rolf

1.10.1990

21.9.1959

1020

Wilkens

Jenny

1.1.2007

23.3.1970

1030

May

Karl

1.10.2010

31.7.1985

1005

Sommer

Lisa

1.7.2009

21.9.1970

1040

Winter

Angelika

1.2.2007

17.9.1965

1007

Müller

Igor

1.5.2008

22.11.1962

1090

Stepper

Rolf

1.7.2013

15.4.1974

Betrachten wir noch ein zweites Beispiel, die Objektklasse Abteilungen mit den Attributen:

Bezeichnung der Abteilung (AbtBez)

Leiter der Abteilung (AbtLeiter)

Standort der Abteilung

Hier ergibt sich folgende Tabelle

Tabelle Abteilungen

AbtBez

AbtLeiter

Standort

PW

Sommer

München

IT

Winter

Ulm

RE

Müller

München

VB

Stepper

München

PW=Personalwesen, IT=Datenverarbeitun, RE=Rechnungswesen, VB=Vertrieb

Nun noch die Objektklasse der Projekte. Für diese wird eine Bezeichnung (Bez), der Tag der Einrichtung (TagEinr), die Dauer und das Budget erfasst.

Tabelle Projekte

Bez

TagEinr

Dauer

Budget

LiefPortal

1.10.2013

60

200

Ind4p0

1.1.2014

48

600

BPM

1.4.2013

48

150

Abschließend noch die Objektklasse PC. Sie beschreibt die imUnternehmen benutzten PCs.

Tabelle PC

InvNr

Bez

Typ

pc2012

...

Desktop Büro

pc3015

...

Desktop Entwickler

Pc1414

...

Laptop

Genau solche Tabellen werden, wenn sie bestimmte Eigenschaften haben, Relationen genannt. Relationen sind also - auf dieser Ebene der Modellierung - nichts anderes als nach bestimmten Regeln gestaltete Tabellen, mit denen jeweils eine Objekt- oder Beziehungsklasse beschrieben wird.

Von Tabellen zu Relationen

Die Beziehungen und Beziehungsklassen betrachten wir in Kapitel 5. Somit besteht der nächste Schritt im Modellierungsprozess darin, für jede Objektklasse eine Relation anzulegen. Damit verlassen wir auch den Bereich der konzeptionellen Modellierung und beginnen mit der relationalen Modellierung.

4.2 Eigenschaften und Darstellung von Relationen

Folgendes sind die Eigenschaften, die eine Tabelle erfüllen muss, um zur Relation zu zu werden:

(1) Jede Zeile (auch "Reihe" oder "Tupel") beschreibt ein Objekt (bzw. eine Beziehung), die Tabelle als Ganzes beschreibt die Objekt- oder Beziehungsklasse.

Eigenschaften von Relationen

(2) In jeder Spalte steht als Kopf der Name eines Attributs, darunter stehen die Attributsausprägungen, die das jeweilige Objekt (die Beziehung) beschreiben.

(3) Eine Relation hat immer einen Schlüssel, der auch aus mehr als einem Attribut bestehen kann, und mindestens ein beschreibendes Attribut.

(4) Es gibt keine zwei identischen Tupel, d.h. jedes Tupel beschreibt ein anderes Objekt.

(5) Im Schnittpunkt jeder Zeile und Spalte wird genau eine Attributsausprägung festgehalten, nicht mehr. Dies macht die Tabelle zur flachen Tabelle.

Zu 1: Dies ist am Anfang der Erstellung eines Datenmodells richtig. Später, wenn eventuelle Redundanzen in den Modellentwürfen beseitigt werden - Stichwort Normalisierung (vgl. die Kapitel 7 - 13) - werden die Attribute zu einem Objekt u.U. auf mehrere Relationen und damit auf mehrere Tupel verteilt.

Zu 2: So wurden die Tabellen ja oben bereits eingeführt.

Zu 3: Denn ein Schlüssel alleine hat nicht allzuviel Aussagekraft.

Zu 4: Dies kann man auch mit der mathematischen Herleitung der relationalen Theorie begründen, vgl. [Staud 2006, Abschnitt 3.22]. Es genügt aber auch, sich klar zu machen, dass zwei Tupel einer Relation mit demselben Schlüssel und denselben Attributen keinen Sinn machen, denn sie beschreiben ja dasselbe Objekt bzw. die dieselbe Beziehung.

Zu 5: Die letztgenannte Eigenschaft ist besonders wichtig in der relationalen Theorie und bereitet beim Aufbau einer Datenbank (bei der Erstellung des Datenmodells) auch einige Schwierigkeiten. Sie bedeutet konkret, dass eine Tabelle umorganisiert werden muss (mehr dazu in Kapitel 7), wenn einem Objekt mehr als eine Ausprägung eines Attributs zugeordnet werden kann. Man spricht dann von Mehrfacheinträgen oder auch Wiederholungsgruppen (repeating groups).). Wäre z.B. in der folgenden Abbildung auch das Attribut BezProj (Projektbezeichnung) mitaufgeführt (Projekte, in denen die Angestellten mitarbeiten), könnten Mehrfacheinträge entstehen, wenn ein Angestellter in mehreren Projekten mitarbeitet.

Flachheit – Mehrfacheinträge - Wiederholungsgruppen

Die oben eingeführten Tabellen erfüllen alle diese Anforderungen und können deshalb als Relationen weiter geführt werden.

Auf diesen Relationen und nur auf ihnen beruht die relationale Theorie und auf diesem wiederum die Relationalen Datenbanksysteme (RDBS). Alle Objekt- und Beziehungsklassen werden durch Relationen erfasst und nur durch diese.

Im Mittelpunkt: Flache Tabellen

Auch die relationalen Datenbanksysteme sind voll auf diesen Informationstyp zugeschnitten. Sie besitzen Befehle zum Einrichten dieser Relationen, zum Festlegen der Attribute usw. Sie erlauben dann, Relationen miteinander zu verknüpfen und auszuwerten, usw.

Die folgende Abbildung zeigt, wie Relationen als Tabellen dargestellt werden können und wie sie aufgebaut sind. Zu jeder Relation gehört eine Bezeichnung, hier Angestellte. In der obersten Zeile stehen die Bezeichnungen der Attribute. Hier sind schon mal Schlüssel (identifizierendes Attribut) und Fremdschlüssel markiert, sie werden unten erläutert. In den Zeilen darunter stehen die Ausprägungen der in der Kopfzeile angegebenen Attribute. Diese Zeilen werden in der relationalen Theorie Tupel genannt. Somit beschreibt ein Tupel ein Objekt oder eine Beziehung (vgl. dazu den nächsten Abschnitt). Die Attribute, die Fremdschlüssel sind, dienen zur Verknüpfung, vgl. die Definition oben und die genauere Darstellung im nächsten Abschnitt.

Darstellung 1: didaktisch motivierte grafische Darstellung

Abbildung 4.2-1: Aufbau von Relationen.
Vgl. zu den verwendeten Abkürzungen die Erläuterungen oben.

Neben dieser grafischen Darstellung wird für Relationen auch die folgende textliche Schreibweise benutzt:

Darstellung 2: textliche Darstellung

Relationenname (#A1, A2, A3, ...)

Dabei stehen A1_,A2 usw. für die Attribute der Relation. Die Raute kennzeichnet das Schlüsselattribut. Für das Beispiel oben also:

Angestellte (#PersNr, Name, VName, ...)

Es kommt vor, dass der Schlüssel einer Relation aus mehreren Attributen besteht, z.B. bei bestimmten Beziehungen (vgl. dazu den nächsten Abschnitt). Dann werden die Schlüsselattribute (hier A1 und A2) in Klammern gefasst:

Mehrere Attribute im Schlüssel

Relationenname (#(A1, A2), A3, A4, ...)

Soll ein Attributsnamen um die Angabe seiner Relation ergänzt werden (z.B. in SQL, wo es teilweise unabdingbar ist), wird der Relationenname voran gestellt:

SQL

Relationenname.Attributname

Also z.B. Angestellte.Name oder Abteilungen.AbtLeit.

Hier nun alle obige Relationen zum Anwendungsbereich Angestellte in dieser textlichen Darstellungsweise:

Angestellte (#PersNr, Name, VName, DatEinst, GebTag)

Abteilungen (#AbtBez, AbtLeiter, Standort)

Projekte (#Bez, TagEinr, Dauer, Budget)

PC (#InvPC, Bez, Typ)

Die Schlüssel bedeuten:

PersNr: Pesonalnummer

AbtBez: Kurzbezeichnung der Abteilung

InvPC: Inventarnummer des PC

ProjId: Identifizierende Information für PCs

Die eigentliche grafische Darstellungsweise für Relationen ist wie in der folgenden Abbildung angegeben. In einem Rechteck wird in der oberen Hälfte der Relationenname angegeben, darunter die Schlüssel und Fremdschlüssel (und nur diese). Diese Darstellung wird benötigt, wenn ganze Datenmodelle (also viele Relationen mit ihren Verknüpfungen) dargestellt werden sollen (vgl. hierzu Kapitel 7 bis 13 und insbesondere die zahlreichen Beispiele in den Kapiteln 16 und 17).

Darstellung 3: Eigentliche grafische Darstellung von Relationen

Fremdschlüssel dienen der Verknüpfung verschiedener Relationen miteinander und sind deshalb von großer Bedeutung in der relationalen Modellierung. Sie werden im nächsten Kapitel erläutert.

Abbildung 4.2-2: Grafische Darstellung von Relationen

Beispiele aus dem Anwendungsbereich Angestellte

In dem in diesem Abschnitt eingeführten Beispiel soll es um den Anwendungsbereich Angestellte eines Unternehmens (in vereinfachter Form) gehen. Hier die grafische Darstellung der vier Relationen.

Abbildung 4.2-3: Relationen aus dem Anwendungsbereich Angestellte

Beispiele aus dem Anwendungsbereich Rechnungsstellung

Vgl. hierzu die zusammenhängende Darstellung in Abschnitt 16.1. Dort ist auch eine abstrahierte Rechnung angegeben.

In diesem zweiten Beispiel soll es um den Anwendungsbereich Rechnungsstellung gehen. Erfasst werden die Informationen rund um die Rechnungen (Typ Möbelhaus). Im ersten Schritt legen wir die Relationen Kunden, Artikel, ReKöpfe (Rechnungsköpfe) und Lagerort an. Hier die textliche Fassung der Relationen mit den Schlüsseln. Weitere Attribute werden folgen.

Kunden (#KuNr, ...)

Artikel (#ArtNr, ...)

ReKöpfe (#ReNr, ...)

Lagerort (#LoId, ...)

Die Schlüssel bedeuten:

ArtNr: Artikelnummer

LoId: Lagerortidentifikation

ReNr: Rechnungsnummer

KuNr: Kundennummer

Hier die grafische Darstellung der Relationen.

Abbildung 4.2-4: Relationen aus dem Anwendungsbereich Rechnungsstellung

Soweit die Relationen der einführenden Beispiele und ihre Darstellung. Die folgende Tabelle fasst die Grundbegriffe zu Relationen zusammen. Dabei sind die Begriffe der datenbanktheoretischen Diskussion um die informellen Begriffe ergänzt, soweit solche existieren.

Grundbegriffe

Relationale Begrifflichkeit

Informell

Formell

Englisch

Tabelle

Relation

Table

Zeile

Tupel

row, tuple

Eigenschaft - Bezeichnung

Attribut(sname)

attribute

Eigenschaft - Ausprägung

Attributsausprägungen, Wertebereich

domain

5 Beziehungen erkennen und einrichten

5.1 Beziehungen erkennen

In Kapitel 3 zur konzeptionellen Modellierung wurden bereits die Beziehungen zwischen Objekten bzw. Objektklassen eingeführt, die im Anwendungsbereich erkannt werden und die für die Anwendung von Bedeutung sind. Also zum Beispiel die Beziehung zwischen Angestellten und Abteilungen: Ein Angestellter ist in genau einer Abteilung, eine Abteilung hat mehrere Angestellte.

Beziehungen zwischen Objekten und zwischen Objektklassen

Diese Beziehungen müssen beim Datenbankentwurf beachtet werden. Einige werden schon in der konzeptionellen Modellierung entdeckt und festgehalten. Andere erst, wenn die Relationen angelegt werden und das Datenmodell vervollständigt wird. Wiederum andere ergeben sich aus der Notwendigkeit, Beziehungen zwischen Relationen im Datenmodell und in der Datenbank zu verankern.

Dabei geht es nur um semantisch sinnvolle Beziehungen, nur um solche, die für den Anwendungsbereich von Bedeutung sind. Spielen z.B. Geschäftsprozesse im Anwendungsbereich eine Rolle, dann müssen alle die Beziehungen erfasst werden, die zu deren Abwicklung benötigt werden.

Die meisten Beziehungen sind zweistellig (zwei Objektklassen / Relationen stehen in Beziehung), mehrstellige kommen aber auch vor und werden deshalb unten auch erläutert. Zu Beginn wollen wir aber hier von zweistelligen Beziehungen ausgehen.

Zwei- und mehrstellig

Wichtig ist, wieviele Objekte von jeder Relation an der Beziehung teilhaben. Im obigen Beispiel zu Abteilungen und Angestellten ist dies z.B.

Kardinalitäten

1:n

Gesprochen wird dies "eins zu n", die Buchstaben n oder m stehen für "1 Objekt oder mehrere". Diese Angabe wird Kardinalität genannt. Sie bestimmt, auf welche Weise die Beziehung im Datenmodell und dann in den Daten erfasst wird. Dazu unten mehr. Datenbanktechnisch notwendig ist die Unterscheidung von genau drei Kardinalitäten:

1:1-Beziehungen, d.h. eine Beziehung der Kardinalität 1:1

1:n-Beziehungen, ...

n:m-Beziehungen, ...

1:1

Die folgende Abbildung zeigt ein erstes Beispiel. Der Text zwischen den Relationen beschreibt die gewünschte Beziehung. Im ersten Fall geht es um die Beziehung zwischen Angestellten und PCs in einer Organisation. Hier soll es so sein, dass jedem Angestellten genau ein PC zugewiesen ist und er oder sie diesen auch alleine nutzt.

Kardinalität 1:1, 1:1 - Beziehung

Abbildung 5.1-1: Relationen aus dem Anwendungsbereich Angestellte

Das zweite Beispiel betrifft die Beziehung zwischenden Artikeln und dem Ort im Lager, wo sie aufbewahrt werden. Hier soll es so sein, dass jeder Artikel an einem Lagerplatz ist und umgekehrt an einem Lagerplatz nur ein einziger Artikel.

Abbildung 5.1-2: Relationen aus dem Anwendungsbereich Rechnungsstellung

Diese beiden Beispiele stellen 1:1 - Beziehungen dar, da sie jeweils ein Tupel der einen Relation mit einem der anderen in Beziehung setzen.

1:n

Ganz anders in den folgenden Beispielen. Zwischen Abteilungen und den Angestellten gibt es die Beziehung Abteilungszugehörigkeit. Für diese gelten die in der Abbildung angegebenen Wertigkeiten. Sie drücken aus, dass eine Abteilung mehrere Angehörige hat und dass ein Angestellter nicht in mehr als einer Abteilung sein kann. Hier liegt also eine 1:n - Beziehung vor.

Kardinalität 1: n, 1:n - Beziehung

Abbildung 5.1-3: Relationen aus dem Anwendungsbereich Angestellte

Die Beziehung zwischen Rechnungen und Kunden erfasst das nachfolgende Beispiel. Eine Rechnung ist für genau einen Kunden bestimmt, ein Kunde kann natürlich viele Rechnungen beim jeweiligen Unternehmen haben. Also auch wieder eine 1:n - Beziehung.

Rechnungen – Kunden

Abbildung 5.1-4: Relationen aus dem Anwendungsbereich Rechnungsstellung

n:m

Projekte – Angestellte. Der dritte Beziehungstyp bringt mehrere Tupel der einen Relation mit mehreren der anderen in Beziehung. Das erste Beispiel betrifft Projekte (in Unternehmen) und Angestellte. Dabei gilt, dass in einem Projekt typischerweise mehrere Angestellte mitarbeiten und ein Angestellter in mehreren Projekten mitarbeiten kann. Damit liegt die Kardinalität n:m vor.

Kardinalität n:m,
n:m – Beziehung

Kunden – Adresssen. Genauso kann man es bei der Erfassung von Adressangaben machen. Ein Kunde kann mehrere Adressen haben, unter einer Adresse können mehrere Kunden wohnen. Dies wird oft einfacher erfasst, z.B. ohne den zweiten Aspekt. Dann wäre die Kardinalität 1:n. Oder man lässt je Kunde nur eine Adresse zu, die "Hauptadresse", dann wird die Beziehung zu einer 1:1-Beziehung.

Zusammenfassung

Die folgende Abbildung drückt die verschieden Kardinalitäten grafisch aus. Die Punkte auf den beiden Seiten repräsentieren die Objekte bzw. Tupel. Die Linien zwischen ihnen die Beziehungen. Entsprechend ist bei einer Kardinalität von 1:1 jeder Punkt einer Seite mit genau einem auf der anderen Seite verbunden. Bei einer Kardinalität von 1:n ist ein Punkt der einen Seite mit einem oder mehreren verbunden. Bei der Kardinalität von n:m ist von beiden Seiten aus ein Punkt mit mehreren auf der anderen Seite verknüpft.

Abbildung 5.1-5: Mögliche Kardinalitäten in Relationalen Datenmodellen

5.2 Schlüssel und Fremdschlüssel

Bevor nun die konkrete Art und Weise, wie diese Verknüpfungen realisiert werden, besprochen wird, müssen zwei Begriffe geklärt werden. Zuerst der des Schlüssels.

Als Schlüssel wird ein Attribut bezeichnet, das für jedes Tupel eine andere Ausprägung hat. Ein Schlüssel weist somit jedem Objekt oder jeder Beziehung eine andere Ausprägung zu. Ein Schlüssel kann auch aus einer Kombination von Attributen bestehen. Dann gilt obiges entsprechend.

Schlüssel:
Definition 3

Zum Objektbegriff: Hier wird der Einfachheit halber weiterhin davon ausgegangen, dass jedes Tupel (jede Zeile) einer Relation ein Objekt (eine Beziehung) beschreibt und die Relation als Ganzes die Objektklasse (Beziehungsklasse).

Beziehungen in relationalen Datenmodellen und Datenbanken führen zu entsprechenden Verknüpfungen zwischen Attributen verschiedener Relationen, meist zwischen Schlüsseln und Fremdschlüsseln, weshalb letztere jetzt genauer betrachtet werden. Es wird in den folgenden Abschnitten vielfach und in allen Varianten gezeigt: Eine Beziehung zwischen zwei zu verknüpfenden Relationen A und B wird im Kern auf folgende Weise realisiert: Der Schlüssel von Relation A (IdA) wird zu der Relation B hinzugefügt. Dort wird er unterstrichen und stellt dann einen sog. Fremdschlüssel dar.

Fremdschlüssel

Relation-A (#IdA, ...)

Relation-B (#IdB, ..., IdA)

Dies ist nur eine von zahlreichen Varianten, die wir im folgenden kennenlernen. Ist eine Datenbank in guter Verfassung [Anmerkung] gibt es dann für jede Ausprägung des Fremdschlüssels auch eine Attributsausprägung beim zugehörigen Schlüssel (hier IdA). Diese referentielle Integrität wird in der relationalen Theorie gefordert. Damit kann man wie folgt definieren:

Ein Attribut, das zusammen mit dem Schlüssel einer anderen Relation eine relationale Verknüpfung realisiert, wird Fremdschlüssel genannt. Es entspricht dem Schlüssel der anderen Relation, d.h., es hat auch seine Attributsausprägungen. Normalerweise besteht ein Fremdschlüssel aus einem einzelnen Attribut, selten aus mehreren. Die Verknüpfung erfolgt über die Ausprägungen von Schlüssel und Fremdschlüssel, z.B. mit Hilfe entsprechender SQL-Befehle.

Definition: Fremdschlüssel

Die folgenden Abschnitte bringen zahlreiche Beispiel mit allen möglichen Varianten.

5.3 Umsetzung von 1:1

Betrachten wir nun die in Abschnitt 5.1 vorgestellten Beispiele. Das erste betraf die Beziehung zwischen Angestellten und PCs. Es wurde hier als 1:1-Beziehung festgestellt. Es wird also angenommen, dass die PC-Nutzung so geregelt ist, dass einem Mitarbeiter genau ein PC zugeordnet ist und dieser ihm alleine zur Verfügung steht. Eine solche semantische Beziehung verknüpft also je ein Tupel aus den beiden Relationen (je ein Objekt aus den beiden Objektklassen) und wird 1:1 - Beziehung genannt.

1:1
Einer hier, einer dort

In einem relationalen Datenmodell wird eine solche Beziehung verankert, indem entweder der Schlüssel von Angestellte zu den Attributen von PC oder der von PC zu den Attributen von Angestellte hinzugefügt wird:

Entweder also

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag, InvNrPC)

PC (#InvNr, Bez, Typ)

oder

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag)

PC (#InvNr, Bez, Typ, PersNr)

In der Tabellendarstellung mit Beispielsdaten wird die Verknüpfung noch klarer. Zuerst die beiden Ausgangsrelationen:

Angestellte

#PersNr

Name

VName

...

100

Sulger

Paul

...

200

Müller

Ulrike

...

150

Radetzky

Siegfried

...

PC

#InvNr

Typbez

...

Inv001

Server

...

Inv005

Laptop

...

Inv004

Laptop

...

Inv002

Desktop

...

Inv003

Desktop

...

Nach der Übernahme des Schlüssels von PC in die Relation Angestellte könnten sich dann zum Beispiel folgende Fremdschlüsseleinträge ergeben:

Angestellte

#PersNr

Name

VName

...

InvNrPC

100

Sulger

Paul

...

Inv005

200

Müller

Ulrike

...

Inv001

150

Radetzky

Siegfried

...

Inv003

Hier noch die beiden Varianten in der grafischen Darstellungsweise. Dabei wird auch der Fremdschlüssel in das Rechteck aufgenommen und die relationale Verknüpfung durch eine Pfeillinie zwischen Schlüssel und Fremdschlüssel dargestellt. Diese beiden Attributsarten, Schlüssel und Fremdschlüssel, sind auch die einzigen, die in dieser grafischen Darstellungsart angegeben werden. Mit ihnen und den Pfeillinien der Verknüpfungen werden dann die relationalen Datenmodelle dargestellt. Vgl. dazu die zahlreichen Beispiele in den Kapiteln 16 und 17.

1:1 - Beziehungen

Abbildung 5.3-1: Zwei Varianten einer Verknüpfung entlang einer 1:1-Beziehung - im Beispiel Angestellte / PC

Genauso bei dem Beispiel Artikel/Lagerort. Auch hier kann der Schlüssel der einen Relation als Fremdschlüssel in die andere kommen - in beide Richtungen.

Abbildung 5.3-2: Zwei Varianten einer Verknüpfung entlang einer 1:1-Beziehung - im Beispiel Artikel / Lagerort

5.4 Min-/Max-Angaben und "1:1 vertieft"

Die oben gezeigte Verknüpfungsart ist zwar richtig, aber für die konkrete Arbeit nicht genau genug. Denn sie berücksichtigt nicht, ob es sich um Pflichtbeziehungen oder um optionale Beziehungen handelt. Im obigen Beispiel zu Angestellten und PCs:

Min- / Max-Angaben
- Wertigkeiten

Nehmen alle Angestellten an der Beziehung teil, haben also alle einen zugeordneten PC?

Sind alle PCs einem Angestellten zugeordnet oder gibt es welche, die zwar beschafft, aber nicht zugewiesen sind, z.B., weil sie erst noch hergerichtet werden?

Min-/Max-Angaben

Dies ist datenbanktechnisch und für die Gestaltung der Verknüpfungen von großer Bedeutung, wie gleich unten gezeigt wird, und muss deshalb auch erfasst werden. Dazu gibt man statt der Kardinalität bei jeder an der Beziehung beteiligten Relation an, wieviele Tupel mindestens und wieviele höchstens daran teilhaben. Damit entstehen sog. Min-/Max-Angaben (auch Wertigkeiten), mit denen dann für jede Relation die Beziehung wesentlich genauer angegeben werden kann. Im obigen Fall zum Beispiel:

Optionale Beziehung vs. Pflichtbeziehung

Jeder Angestellte muss genau einen zugeordneten PC haben. Min-/Max-Angabe: 1,1 (mindestens ein Tupel, höchstens ein Tupel => genau ein Tupel). Pflichtteilnahme.

Ein Angestellter kann, muss aber nicht einen PC haben. Min-/Max-Angabe: 0,1 (evtl. kein Tupel, höchstens ein Tupel). Optionale Teilnahme.

Jeder PC muss genau einem Angestellten zugeordnet sein. Min-/Max-Angabe: 1,1. Pflichtteilnahme.

Ein PC kann, muss aber nicht einem Angestellten zugeordnet sein. Min-/Max-Angabe: 0,1. Optionale Teilnahme.

Für die 1:1-Beziehung zwischen Angestellten und PCs sind also folgende Varianten möglich:

1,1 : 1,1

0,1 : 1,1

1,1 : 0,1

0,1 : 0,1

Lesehinweis

Meistens beziehen sich Min-/Max-Angaben auf zwei Relationen und deren Attribute (i.d.R. Schlüssel und Fremdschlüssel). Z.B. Relation 1 / Relation 2. Bei der Interpretation der Min-/Max-Angaben ist die Reihenfolge zu beachten, in der die Relationen angeführt sind. Der erste Min-/Max-Ausdruck vor dem Doppelpunkt bezieht sich auf die erstgenannte Relation (gibt also an, wie sie an der Beziehung teilnimmt), der zweite Min-/Max-Ausdruck auf die zweite. Liegen z.B. die Min-/Max-Angaben 1,1 : 1,n vor, bedeutet dies hier:

Jedes Tupel von Relation 1 nimmt mindestens und maximal ein Mal an der Beziehung teil (“genau ein mal“)

Jedes Tupel von Relation 2 nimmt mindestens ein Mal an der Beziehung teil. Also auch u.U. mehrfach

Entsprechend in den Grafiken mit Datenmodellen. Von einer Relation ausgehend ist der erste Teil der Min-/Max-Angabe der für diese Relation zuständige.

Verknüpfungsvarianten1,n

Die damit möglichen Präzisierungen der Verknüpfungen werden im folgenden dargestellt. Zuerst aber eine grafische Darstellung der Varianten in der folgenden Abbildung. Dabei repräsentieren die Punkte die Objekte (Tupel) der Relationen und die Linien die relationale Verknüpfung. Bleiben Punkte ohne Linie, handelt es sich um eine für die jeweilige Relation optionale Beziehung (mit Minimalwert 0), ansonsten ist es eine Pflichtbeziehung. Der Kardinalität 1:1 entsprechend ist hier jeweils ein Objekt (Tupel) der einen Seite mit genau einem der anderen Seite verknüpft. Durch die nicht verknüpften Punkte wird die Optionalität bzw. der Pflichtcharakter der Beziehung für die jeweilige Relation verdeutlicht.

Abbildung 5.4-1: Min-/Max-Varianten für Kardinalität 1:1

Verknüpfung für die Min-/Max-Angaben 1,1 : 1,1

Der oben bei der Diskussion der Kardinalität vorgestellte Fall betrifft die Situation, wenn auf beiden Seiten 1,1 als Min-/Max-Angabe vorliegt. Dann besteht freie Wahl, welcher Schlüssel in die andere Relation als Fremdschlüssel übernommen wird, genauso wie es oben in Abbildung 5.3-2 gezeigt wurde.

1,1 : 1,1

Verknüpfung für die Min-/Max-Angaben 1,1 : 0,1

Ist die Teilnahme der PCs an der Beziehung optional, muss der Schlüssel von PC in die Relation Angestellte aufgenommen werden:

1,1:0,1

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag, InvNr)

PC (#InvNr, Bez, Typ)

Die andere Richtung ist nicht möglich, weil es da wiederum für den Fremdschlüssel teilweise keine Ausprägungen geben kann. Zur Veranschaulichung eine Tabelle mit der falschen Lösung. Es soll so sein, dass Müller, Stanis und Stoll keinen PC haben, die anderen aber schon. Dann wäre bei den drei genannten kein sinnvoller Eintrag möglich.

Angestellte

#PersNr

Name

VName

...

InvPC

100

Sulger

Paul

...

Inv005

200

Müller

Ulrike

...

?????

150

Radetzky

Siegfried

...

Inv001

199

Stanis

Rolf

...

?????

244

Stoll

Eva

...

?????

Die folgende Abbildung zeigt die richtige Lösung, d.h. die richtige Platzierung des Fremdschlüssels.

Abbildung 5.4-2: Relationale Verknüpfung für Angestellte / PC und die Min-/Max-Angaben 1,1 - 0,1

Kardinalität: 1:1

Min-/Max-Angaben: 1,1 : 0,1

Semantik:

- Allen Angestellten ist ein PC zugewiesen. Dies fordert auch die referentielle Integrität.

- Es gibt PCs, die noch keinem Angestellten zugewiesen sind.

Verknüpfung für die Min-/Max-Angaben 0,1 : 1,1

Was ist, wenn auf der Seite der Angestellten die Min-/Max-Angabe 0,1 vorliegt? Dann kann in diese Relation nicht der Schlüssel von PC aufgenommen werden, denn es gäbe dann Tupel, für die es einen Attributseintrag nicht geben kann. Somit muss in diesem Fall die PersNr als Fremdschlüssel in PC eingefügt werden.

0,1:1,1

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag)

PC (#InvNr, Bez, Typ, PersNr)

Abbildung 5.4-3: Relationale Verknüpfung für Angestellte / PC und die Min-/Max-Angaben 0,1 : 1,1

Kardinalität: 1:1

Min-/Max-Angaben: 0,1 : 1,1

Semantik:

- Es gibt Angestellte, denen kein PC zugewiesen ist. Ansonsten haben sie maximal einen.

- Jeder PC wird datenbanktechnisch immer einem Angestellten zugeordnet.

Verknüpfung für die Min-/Max-Angaben 0,1 : 0,1

Dritte Relation. Eine Sondersituation liegt vor, wenn die Beziehung Angestellte / PC die Min-/Max-Angaben 0,1 : 0,1 hat. Dann kann weder der Schlüssel von Angestellte nach PC noch der von PC nach Angestellte genommen werden. In diesem Fall ist eine neue dritte Relation ("PC-NUTZUNG") nötig, in der die Schlüssel der beiden Relationen vereinigt sind:

0,1:0,1

PC-NUTZUNG (#AngNr, #InvNrPC)

Dies drückt dann die Beziehung korrekt aus. In tabellarischer Darstellung könnte es sich so ergeben:

PC-NUTZUNG

#PersNr

#InvPC

100

Inv005

150

Inv001

Durch diese neue Relation werden nur die wirklich existierenden Beziehungen erfasst. Eine Besonderheit dieser Relation ist, dass beide Attribute alleine Schlüssel sein können, da aufgrund der Zahl eins an der zweiten Stelle der Min-/Max-Angaben die Attribute PersNr und InvPC jede Ausprägung nur einmal besitzen.

Hier noch die grafische Darstellung.

Abbildung 5.4-4: Relationale Verknüpfung für Angestellte / PC und die Min-/Max-Angaben 0,1 : 0,1

Kardinalität: 1:1

Min-/Max-Angaben: 0,1 : 0,1

Semantik:

- Es gibt Angestellte, denen kein PC zugewiesen ist. Ansonsten haben sie maximal einen.

- Es gibt PC, die keiner Angestellten zugewiesen sind. Ansonsten ist maximal einer zugewiesen..

5.5 Umsetzung von 1:n

Grundsätzlich gilt: Allein die Möglichkeit, dass mehr als ein Objekt (mehr als ein Tupel) an einer Beziehung teilhaben kann, erhöht bereits ihre Stelligkeit auf der jeweiligen Seite über 1 hinaus, da dieser Fall dann ja in der Datenbank erfasst werden muss und die höhere Stelligkeit die niedrigere umfasst, aber nicht umgekehrt.

Die oben eingeführten 1:n-Beziehungen können mit den Min-/Max-Angaben ebenfalls ausdifferenziert werden. Insgesamt gibt es folgende Varianten, von denen aber nicht alle datenbanktechnisch bedeutsam sind:

Ausdifferenzierung

1,1 : 1,n (für beide Relationen Pflicht)

1,1 : 0,n (Pflicht für die eine Relation, Option für die andere)

0,1 : 1,n (optional für die eine Relation, Pflicht für die andere)

0,1 : 0,n (optionale Beziehung für beide Relationen)

Die folgende Abbildung drückt für die Kardinalität 1:n die verschiedenen Min-/Max-Angaben grafisch aus. Der Kardinalität entsprechend ist hier jeweils ein Objekt (Tupel) der einen Seite mit mehreren der anderen Seite verknüpft. Dabei repräsentieren wiederum die Punkte die Objekte (Tupel) der Relationen und die Linien die relationale Verknüpfung. Bleiben Punkte ohne Linie, handelt es sich um eine für die jeweilige Relation optionale Beziehung (mit Minimalwert 0), ansonsten ist es eine Pflichtbeziehung.

Abbildung 5.5-1: Varianten der Kardinalität 1:n entlang der Min-/Max-Angaben

Konkrete Realisierung der Verknüpfung

1,1 : 1,n

Die erste Variante ist der Fall, an den man denkt, wenn man die Kardinalität 1:n wahrnimmt. In der Realität ist sie aber eher die Ausnahme. Bei ihr nimmt jedes Tupel der beiden Relationen an der Beziehung teil.

Nur eine Lösung

Im Beispiel Abteilungen / Angestellte bedeutet dies - durchaus nachvollziehbar - dass jede Abteilung Angestellte hat (mindestens eine/n) und jede/r Angestellte in einer Abteilung ist. Dementsprechend kann der Schlüssel von Abteilungen in der Angestelltenrelation hinterlegt werden:

Abteilungen (#AbtBez, AbtLeiter, Standort)

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag, AbtBez)

Umgekehrt geht dies nicht. Der Schlüssel von Angestellte in Abteilungen würde zu Mehrfacheinträgen führen, was für relationale Datenmodelle verboten ist. Die folgende Abbildung zeigt die Umsetzung in ein Datenmodell.

Abbildung 5.5-2: Relationale Verknüpfung für Abteilungen / Angestellte und die Min-/Max-Angaben 1,n : 1,1

Kardinalität: 1:n

Min-/Max-Angaben: 1,n : 1,1

Semantik:

- Eine Abteilung hat mindestens einen Angestellten.

- Ein Angestellter ist genau einer Abteilung zugeordnet.

Diese Variante bedeutet, dass der Fremdschlüssel in der Relation mit Pflichtteilnahme hinterlegt werden muss. Dies ist dann die, von der jedes Tupel genau eine Beziehung eingeht. Sie bedeutet in diesem Beispiel, dass es Abteilungen gibt, denen (noch) keine Angestellten zugeordnet sind, z.B. weil sie zwar eingerichtet aber noch nicht mit Personal ausgestattet wurden. Andererseits nehmen alle Angestellten an der Beziehung teil. Deshalb kann die Umsetzung hier genauso wie im vorigen Fall sein.

1,1 :0,n

Diese Variante bedeutet, dass der Fremdschlüssel in der Relation hinterlegt werden müsste, bei der jedes Tupel eine mehrfache Beziehung eingehen könnte. Dies ist aber nicht möglich, weil dabei Mehrfacheinträge entstehen würden. Damit ergibt sich hier die Notwendigkeit für die relationale Beziehung eine neue Relation (Abteilungszughörigkeit; AbtZug) einzurichten.

0,n : 1,1 - Neue Relation

Genau dasselbe gilt für die Variante 0,1 : 0,n. Sie bedeutet ja, dass der Fremdschlüssel in keiner der beiden Relationen untergebracht werden kann, da es dann in beiden Fällen Tupel gäbe, bei denen der Fremdschlüssel keinen Eintrag haben könnte und ein Fall sowieso wegen drohender Mehrfacheinträge nicht in Frage kommt. Also auch hier die neue Relation. Für beide obigen Fälle ergibt sich damit die folgende Lösung.

0,1 : 0,n

Abteilungen (#AbtBez, AbtLeiter, Standort)

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag)

AbtZug (#(AbtBez, PersNr))

Die neue Relation hat einen zusammengesetzten Schlüssel, bestehend aus den zwei Fremdschlüsseln. Die folgende Abbildung zeigt das dabei entstehende kleine Datenmodell.

Abbildung 5.5-3: Relationale Verknüpfung für Abteilungen / Angestellte und die Min-/Max-Angaben 0,1 : 1,n sowie 0,1 : 0,n

Kardinalität: 1:n

Min-/Max-Angaben: 0,1 : 1,n oder 0,1 : 0,n.

Semantik 0,1 : 1,n:

- Einer Abteilung ist kein Angestellter, einer oder es sind mehrere zugewiesen.

- Ein Angestellter ist keiner oder genau einer Abteilung zugewiesen.

Semantik 0,1 : 0,n:

- Einer Abteilung ist ein Angestellter zugewiesen oder mehrere („mindestens einer)“.

- Ein Angestellter ist keiner oder genau einer Abteilung zugewiesen

5.6 Umsetzung von n:m

Eine Kardinalität von n:m bedeutet, dass mehrere Tupel der einen Relation mit mehreren der anderen in Beziehung stehen und dies in beide Richtungen. Folgende Varianten sind möglich:

Verbindungsrelation

1,n : 1,m

0,n : 1,m

1,n : 0,m

0,1 : 0,m

Die folgende Abbildung drückt für die Kardinalität n:m die verschiedenen Min-/Max-Angaben grafisch aus. Der Kardinalität entsprechend ist hier jeweils ein Objekt (Tupel) der einen Seite mit mehreren der anderen Seite verknüpft - in beide Richtungen. Dabei repräsentieren wiederum die Punkte die Objekte (Tupel) der Relationen und die Linien die relationale Verknüpfung. Bleiben Punkte ohne Linie, handelt es sich um eine für die jeweilige Relation optionale Beziehung (mit Minimalwert 0), ansonsten ist es eine Pflichtbeziehung.

Verknüpfungsvarianten für n:m

Abbildung 5.6-1: Varianten der Kardinalität n:m entlang der Min-/Max-Angaben

Realisierung der Verknüpfung - Verbindungsrelation

Die Lösung besteht hier immer aus der Einrichtung einer neuen Relation, da jede Übernahme eines Schlüssels in die andere Relation zu Mehrfacheinträgen führen würde. In der neuen Relation, die Verbindungsrelation genannt wird, sind die beiden Schlüssel der zu verknüpfenden Relationen zusammen Schlüssel und dabei einzeln jeweils Fremdschlüssel. Hier ergibt die Betrachtung der verschiedenen Min-/Max-Angaben keine Notwendigkeit für spezielle Lösungen. In allen Varianten leistet die Verbindungsrelation die problemfreie Verknüpfung.

So bei einer Beziehung "Projektmitarbeit" zwischen Angestellten und Projekten einer Organisation. Ein Angestellter kann in mehreren Projekten mitarbeiten, ein Projekt kann mehrere Angestellte zugewiesen haben:

Beispiel Projektmitarbeit

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag)

Projekte (#Bez, TagEinr, Dauer, Budget)

Die Verbindungsrelation ergibt sich wie folgt:

ProjMitarb (#(PersNr, BezProj))

Zusammen mit den Ausgangsrelationen ergibt sich ein kleines Datenmodell, das die n:m-Beziehung in allen Min-/Max-Varianten erfasst.

Abbildung 5.6-2: Relationale Verknüpfung für Angestellte / Projekte und die Kardinalität n:m

Kardinalität: n:m

Min-/Max-Angaben:

1,n : 1,m / 1,n : 0,n / 0,n : 1,m / 0,n : 0,m

Semantik:

- 1,n : 1,m: Eine Angestellte ist mindestens einem Projekt zugeordnet. Ein Projekt hat mindestens einen zugewiesenen Angestellten.

- 1,n : 0,n: Eine Angestellte ist keinem, einem oder mehreren Projekten zugewiesen. Ein Projekt hat mindestens einen zugewiesenen Angestellten.

- 0,n : 1,m: Eine Angestellte ist mindestens einem Projekt zugeordnet. Ein Projekt hat keinen, einen oder mehrere zugewiesene Angestellte.

- 0,n : 0,m: Eine Angestellte ist keinem, einen oder mehreren Projekten zugewiesen. Ein Projekt hat keinen, einen oder mehrere zugewiesene Angestellte.

Schlüssel: Zusammengesetzt aus zwei Attributen. Für jedes Tupel müssen beide Attribute Einträge haben.

Die konkrete Verknüpfung zeigt die folgende tabellarische Darstellung mit Beispielsdaten.

Angestellte

#PersNr

Name

VName

...

100

Sulger

Paul

...

200

Müller

Ulrike

...

150

Radetzky

Siegfried

...

102

Meindl

Karl

...

300

Friedrich

Eugenie

...

350

Paulsen

Heinrich

...

390

Lürsen

Lars

...

400

Schlichter

Ute

...

Projekte

#Bez

Leiter

Budget

...

BPR

Müller

10000

...

Change Management

Paulsen

50000

...

IT2014

Lürsen

1500000

...

BPR: Business Process Reengineering (Geschäftsprozessoptimierung)

Die Verbindungsrelation hält in jedem Tupel eine Projektmitarbeit fest. Arbeitet ein Angestellter in mehreren Projekten mit, gibt es entsprechend mehrere Tupel.

ProjMitarb

ProjBez

PersNr

...

BPR

Müller

...

BPR

Radetzky

...

Change Management

Radetzky

...

IT2014

Lürsen

...

IT2014

Schlichter

...

...

...

...

Schlüssel: #(ProjBez, PersNr)

Diese angegebenen Tupel genügen, um die n:m - Beziehung deutlich zu machen: Ein Projekt hat mehrere Mitarbeiter, ein Mitarbeiter ist in mehreren Projekten.

Die Bezeichnung Verbindungsrelation rührt daher, weil sie die anderen beiden semantisch (und dann später auch für Abfragen und Auswertungen) verknüpft. Auch sie benötigt natürlich einen Schlüssel. Dieser besteht aus den beiden von den Ausgangsrelationen übernommenen Attributen und ist unten an der Tabelle angegeben. Er ist das erste Beispiel für einen zusammengesetzten Schlüssel. Dazu später mehr.

Verbindungsrelation

Beziehungen in relationalen Datenmodellen und damit in relationalen Datenbanken können meist nur auf die oben beschriebene Weise erfasst werden, also nur durch Attribute, die von der einen Relation kommen (meist als Schlüssel) und bei der anderen eingefügt werden (meist als Fremdschlüssel). Nach der Übernahme eines Attributs als Fremdschlüssel gibt jedes Tupel eine der Beziehungen an.

5.7 Verknüpfung konkret

Es wurde oben schon deutlich: Relationen stehen nicht isoliert im Datenmodell, sondern sind miteinander verknüpft. Dies ist sogar ein grundsätzliches Wesensmerkmal relationaler Datenmodelle. Alle Relationen eines relationalen Datenmodells müssen untereinander in Beziehung stehen, wobei mit Beziehung die oben eingeführte Verknüpfung durch Attribute gemeint ist.

Anmerkung:
Eine Ausnahme von dieser Regel ergibt sich, wenn man Tabellen zum "Nachschlagen" mit in das Datenmodell integriert. Z.B. mit Kalenderdaten, wenn es um ein Datenmodell geht, bei dem Kalenderdaten eine große Rolle spielen. Eine solche "Nachschlagetabelle" ist nicht auf die übliche "relationale" Weise mit den übrigen Relationen des Datenmodells verknüpft (wie es in diesem Abschnitt erläutert wird), hat aber trotzdem Bedeutung für das Datenmodell.
Bei Datenbanken, deren Ersteller wenig Kompetenz in Datenmodellierung haben, sieht man Lösungen ohne attributbasierte Schlüssel-/Fremdschlüsselbeziehungen. Da werden dann diese Beziehungen im Anwendungsprogramm hinterlegt und durch dieses realisiert. Die jeweilige Semantik ist damit im Programm hinterlegt.

Was bedeuten nun solche Verknüpfungen konkret? Die folgenden Abbildungen sollen darauf eine Antwort geben. Als Beispiel dient die Beziehung zwischen Datenbanksystemen (DBS) und ihren Produzenten. Da ein Produzent u.U. mehrere Datenbanksysteme herstellt und ein Datenbanksystem von einem einzigen Produzenten kommt, handelt es sich hier um eine 1:n - Beziehung mit den Min-/Max-Angaben 1,1 : 1,n. D.h., wir nehmen nur die Produzenten auf, von denen wir auch eine Datenbank erfasst haben. DBS erhält also einen Fremdschlüssel. Die textliche Fassung sei wie folgt:

DBS / PROD mit Min-/Max-Angaben 1:n

DBS (#(Bez, Typ, Plattform, IdProd)

PROD (#IdProd, Ort, Straße, Land)

Hier das Datenmodell in grafischer Fassung.

Abbildung 5.7-1: Datenmodellfragment DBS / Prod in grafischer Darstellung

Nun zur Verdeutlichung die Relationen in Tabellenform mit abstrahierten Daten. Die Verbindungslinie soll wiederum zeigen, dass bei gleichen Ausprägungen eine Verknüpfung erfolgen kann. Dabei wird dann, z.B. mit SQL, das Tupel zu DBS4 über den Fremdschlüsseleintrag "P2" mit dem Tupel von "P2" in Prod verknüpft.

Abbildung 5.7-2: Datenmodellfragment DBS / PROD in Tabellendarstellung

Dies wird noch deutlicher, wenn man wie in der nächsten Abbildung diese Tupelverknüpfung verdeutlicht. Die Pfeile deuten jetzt an, dass ein Tupel der Relation PROD(uzenten) mit mehreren Tupeln der Relation DBS verbunden sein kann, entsprechend der 1:n-Verknüpfung.

Hier kann man sich auch die Probleme vorstellen, die entstehen, wenn es Fremdschlüsseleinträge gibt, die beim zugehörigen Schlüssel nicht vorhanden sind. Dies ist auch explizit untersagt. Liegt es nicht vor, ist die sog. referentielle Integrität des Datenmodells und später der Datenbank gesichtert (vgl. Abschnitt 5.9). Dagegen macht es datenbanktechnisch keine Probleme, wenn beim Schlüsselattribut einer solchen Verknüpfung Ausprägungen vorhanden sind, die "auf der anderen Seite" fehlen. Dann ist die Beziehung eben optional im oben diskutierten Sinn.

Abbildung 5.7-3: Darstellung der Verknüpfung auf Tupelebene

Über eine solche relationale Verknüpfung können die beiden Relationen auch insgesamt zusammengeführt werden.

5.8 Mehrstellige Beziehungen

Es gibt natürlich auch mehrstellige Beziehungen in Datenbanken und Datenmodellen. In diesen Fällen muss immer eine Verbindungsrelation gebildet werden. Diese hat einen zusammengesetzten Schlüssel, der aus den Schlüsseln der beteiligten Relationen besteht, wie es auch dieses abstrakte Beispiel zeigt:

Zusammengesetzte Schlüssel

R1 (#Attr1, Attr2, Attr3, ...)

R2 (#Attr4, Attr5, ...)

R3 (#Attr6, Attr7, Attr8)

Verbindungsrelation

R1-R2-R3 (#(Attr1, Attr4, Attr6))

Soweit - sozusagen - die Standardlösung in einfacher abstrahierter Darstellung. In jedem Tupel der Verbindungsrelation ist dann genau eine Beziehung festgehalten. Der konkrete Aufbau hängt dann noch von den Min-/Max-Angaben und einer eventuellen zeitlichen Dimension ab. Außerdem werden natürlich nur die Schlüsselbestandteile Fremdschlüssel, für die es eine beschreibende Relation "am anderen Ende der Verknüpfung" gibt.

Zwei Beispiele sollen dies noch mehr verdeutlichen. Im ersten geht es um das Training von Mannschaften, z.B. im Fussball. Der Trainer ist ein Angestellter des Vereins und hat deshalb eine Personalnummer (PersNr). Das Training kann an verschiedenen Orten stattfinden (Bezeichnung Ort: BezOrt). Die (vereinfachten) Relationen seien wie folgt:

Beispiel: Training

Mannschaften (#MannschNr, Bez, ...)

Trainer (#PersNr, Name, VName, ...)

Orte (#BezOrt, Typ, Strasse, PLZ, Ort)

In einer konkreten Trainingsdurchführung kommen dann drei Objekte (im Sinne der konzeptionellen Modellierung) bzw. Relationen zusammen. Hinzugenommen werden muss noch der Zeitpunkt des Trainings (vgl. zur zeitlichen Dimension in der Datenmodellierung Kapitel 15), hier mit der Angabe des Tages. Der Einfachheit halber soll angenommen werden, dass nur einmal am Tag trainiert wird, dann reicht die Angabe des Tages aus:

Training (#(MannschNr, PersNr, BezOrt, Tag), Beginn, Ende)

Damit identifiziert jeder Schlüssel eine Trainingseinheit und das Tupel als Ganzes beschreibt sie. Hier einige Beispiele:

Training

MannschNr

PersNr

BezOrt

Tag

Beginn

Ende

1001

700

Stadion

20.9.2021

8.00

12.00

2000

440

Stadion

17.7.2021

9.00

10.30

1001

700

Halle

22.9.2021

14.00

17.30

...

Das zweite Beispiel betrifft die Durchführung von Vorlesungen über die Semester hinweg. Welche Vorlesung hat stattgefunden? Welcher Dozent hat sie realisiert, usw.? Also nicht die konkreten Vorlesungstermine, sondern die Durchführung der einzelnen Vorlesungen in den Semestern, z.B. der Vorlesung Datenbanksysteme mit der Vorlesungsnummer (VorlNr) 9012 im SS2021 durch den Dozenten mit der DozId Sta. Das könnte die folgende Relation leisten:

Vorlesungsbetrieb (VLB)

VLB (#(VorlNr, Semester, DozId))

Zusätzlich existieren Relationen zu den Vorlesungen und den Dozenten:

Vorlesungen (#VorlNr, Bez, SWS, cps, ...)

Dozenten (#DozId, Name, Vorname, ...)

Vgl. Abschnitt 16.5 für ein umfassendes Beispiel zum Vorlesungsbetrieb.

5.9 Integritäten

Dies ist nun die Stelle, um zwei grundsätzliche Forderungen an Relationen bzw. Datenmodelle anzuführen: Objektintegrität und referentielle Integrität.

Objektintegrität wird die Forderung genannt, dass kein Tupel mit unvollständigem Schlüssel in eine Relation eingetragen werden darf. D.h., es kommt natürlich vor, dass unvollständige Tupel in eine Relation eingetragen werden, z.B. weil eine Information noch fehlt, aber der Schlüssel muss vollständig vorhanden sein. Dies wird normalerweise gar nicht als Problem erkannt, da bei einem Schlüssel, der aus einem Attribut besteht, niemand auf die Idee kommt, ihn wegzulassen. Besteht der Schlüssel aber aus mehreren Attributen (vgl. den nächsten Abschnitt), kann man beim Eintragen schon auf diese Idee kommen.

Objektintegrität
Nie ohne vollständigen Schlüssel

Es wurde oben schon öfters thematisiert. Bei einer relationalen Verknüpfung sollten beim Fremdschlüssel keine Ausprägungen vorhanden sein, die es beim zugehörigen Schlüssel nicht gibt. Denn ist dies der Fall, gibt es zu der Ausprägung keine "Fortsetzung" in der anderen Relation.

Referentielle Integrität

Man kann es auch so formulieren: In den jeweiligen Fremdschlüssel einer relationalen Verknüpfung darf eine Ausprägung nur eingetragen werden, wenn sie als Ausprägung des Schlüssels in der anderen Relation (wo dieses Attribut ja Schlüssel ist) vorkommt. Damit soll verhindert werden, dass Fremdschlüsseleinträge erfolgen, die nicht verknüpft werden können.

Betrachten wir als Beispiel nochmals die beiden Relationen DBS (mit dem Fremdschlüssel IdProd) und PROD (mit dem Schlüssel IdProd). Die Forderung der referentiellen Integrität verbietet es, einen Produzenten in DBS.IdProd einzutragen, der nicht in PROD.IdProd vorhanden ist.

Erinnerung: Die Schreibweise DBS.IdProd bedeutet "Attribut IdProd von der Relation DBS". Entsprechend bedeutet PROD.IdProd "Attribut IdProd von der Relation PROD".

5.10 Schlüssel vertieft

Oben kam es nun schon mehrmals vor. Zuletzt bei den mehrstelligen Verknüpfungen und davor in Abschnitt 5.6: Schlüssel, die aus mehr als einem Attribut bestehen. Das Beispiel aus Abschnitt 5.6 betraf die Projektmitarbeit. Die Relation

Zusammengesetzte Schlüssel

ProjMitarb (#(PersNr, BezProj))

benötigt zwei Attribute um den Sachverhalt ausdrücken, welche Angestellten in welchen Projekten mitarbeiten. Dann sieht man, dass Radetzky in den Projekten BPR und Change Management mitarbeitet, Müller aber nur im Projekt BPR.

Relation ProjMitarb

BezProj

PersNr

BPR

Müller

BPR

Radetzky

Change Management

Radetzky

...

...

Hier noch die grafische Darstellung solcher Relationen:

In der textlichen Notation werden zusammengesetzte Schlüssel wie oben gesehen angegeben. Hier noch ein weiteres Beispiel aus den obigen Abschnitten, Abteilungszugehörigkeit (AbtZug), mit den Min-/Max-Angaben 01, : 0,n.

Textliche Notation

AbtZug (#(AbtBez, PersNr)) // vgl. Abschnitt 5.5

Grundsätzlich müssen die einzelnen Attribute des Schlüssels ("Schlüsselattribute") nicht Fremdschlüssel sein, sie sind es aber oft, da meist eine von den Fremdschlüsseln ausgehende relationale Verknüpfung vorliegt.

Von dieser Situation, dass ein Schlüssel aus mehreren Attributen besteht, ist zu unterscheiden, wenn eine Relation mehrere, voneinander unabhängige Schlüssel hat (konkurrierende Schlüssel). Nehmen wir als Beispiel eine Relation zu Abteilungen:

Konkurrierende Schlüssel

Abteilungen (#AbtID, #AbtBez, AbtLeiter, Standort)

Hier sind AbtId und AbtBez jeweils identifizierend.

Die grafische Darstellung:

Es soll zu jeder Abteilung eine identifizierende Kurzbezeichnung geben wie PW, ORG, IT, usw. und zusätzlich die ganz normale Bezeichnung. Beide erhalten die Raute für die Kennzeichnung als Schlüssel. In einem solchen Fall macht es auch Sinn, von Sekundärschlüsseln und Primärschlüsseln zu reden. Einer der Schlüssel, meist der für die interne Verknüpfung verwendete, wird zum Primärschlüssel, der andere ist dann der Sekundärschlüssel.

Primärschlüssel und Sekundärschlüssel

Der von einigen Autoren verwendete Begriff Schlüsselkandidat ist eine direkte Übersetzung des amerikanischen Begriffs "candidate key" für Sekundärschlüssel.

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 [Anmerkung] , 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 [Anmerkung] ) 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.

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.

Flach durch Tupelvermehrung

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 Die erste Normalform (1NF)

Hier beginnt Teil III: Optimierung des Datenbankentwurfs

mit den Kapiteln

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)

Wenn es um die relationale Theorie geht, insbesondere um die Normalformenlehre, ist der Klassiker von Date immer noch die erste Wahl. Er ist 2006 in 8. Auflage erschienen:

Date, C.J; Kannan, A. und Swamynathan, S.: An Introduction to Database Systems. (8. Auflage), New Delhi 2006

Vgl. dort insbesondere die vertiefenden Ausführungen zum Datenbankentwurf in Part III Database Design.

Mit dem in den ersten sechs Kapiteln gelernten kommt man schon sehr weit im Datenbankdesign. Man könnte sogar schon einen ersten Datenmodellentwurf aufstellen. Dies wird aber noch etwas verschoben, auf das Ende dieses Kapitels. Denn dieser erste mögliche Entwurf weist in der Regel noch viele Unzulänglichkeiten auf, v.a. Mehrfacheinträge und Redundanzen. Deren Beseitigung wird in den nächsten acht Kapiteln beschrieben.

7.1 Optimierung durch Normalisierung

"Optimierung" bedeutet hier unterschiedliches, z.B. auch die Beseitigung eventueller Mehrfacheinträge, v.a. aber die Beseitigung von Redundanz in den Daten einer Relation. Diese bedeutet hier, dass dass ein und dieselbe Information in einer Relation mehrfach erfasst wird. Z.B. die Tatsache, dass Person X die Programmiersprache C++ beherrscht. In den folgenden Abschnitten sind viele Beispiele für Redundanzen in Relationen angeführt.

Redundanz

Letztendlich ist eine Regel für die im folgenden dargestellten Bemühungen verantwortlich, die wegen ihrer Bedeutung getrost zu einer der zentralen Regeln des Datenbankentwurfs ernannt werden kann:

Zentrale Regel des Datenbankentwurfs

Jede Information darf in einer Datenbank nur einmal vorkommen.

Dabei geht es um attributbasierte Infomation. Also z.B. die Information, dass Lisa Steiner in der Abteilung Controlling arbeitet, dass Heiner Müller Abteilungsleiter der Abteilung Personalwesen ist, dass Angelika Widmer die Programmiersprache C++ beherrscht, usw.

Als Werkzeug für diese Optimierung stellt die relationale Datenbanktheorie die Normalformen zur Verfügung. Insgesamt gibt es sechs, die

Normalformen

Erste Normalform (1NF)

Zweite Normalform (2NF)

Dritte Normalform (3NF)

Boyce-Codd - Normalform (BCNF)

Vierte Normalform (4NF) und die

Fünfte Normalform (5NF).

Die einzelnen Normalformen bauen aufeinander auf. Ist die n-te erfüllt, sind auch alle "darunterliegenden" erfüllt. Jede Normalform hat das Ziel, das Datenmodell - aufbauend auf der vorangehenden - weiter zu "optimieren". Was dies jeweils bedeutet, wird bei den Normalisierungsschritten betrachtet.

Aufbauend

Die Normalformen kommen zum Zug, wenn die Objekt- und Beziehungsklassen des ersten Entwurfs in Relationen "gegossen" und die Verknüpfungen geklärt wurden - wie in Teil I dargestellt. Oftmals endet dieser erste Entwurf auch in einer einzigen großen Universalrelation, in die alle gewünschten Attribute geschrieben wurden. Auf die Relationen dieses ersten Datenmodells werden dann die Normalformen angewandt.

Universalrelation

7.2 Definition und Herbeiführung

Oben - bei der Definition von Relationen - wurde bereits beschrieben, dass Relationen flache Tabellen (d.h. ohne Mehrfacheinträge) mit den angeführten Eigenschaften sind. Dann sind sie auch gleich in erster Normalform (1NF). Solange sie diese Eigenschaften nicht voll erfüllen werden sie, sprachlich nicht ganz korrekt, als unnormalisierte Relationen bezeichnet.

Definition: 1NF

Definition 1NF

Eine Relation ist in 1NF, falls sie keine Mehrfacheinträge aufweist.

Auch einem gesamten Datenmodell kann man eine Normalform zuweisen. Dabei ist die niedrigste gemeinsame Normalform aller Relationen die des Datenmodells. Haben z.B. alle Relationen eines Datenmodells die 3NF erreicht, ist auch das Datenmodell in dieser, aber nur dann.

Datenmodelle mit NF

"Unnormalisierte Relationen" kommen sehr oft vor, teilweise schon beim ersten Anlegen einer Relation, vor allem aber bei der Weiterentwicklung im Rahmen der Normalisierung. Z.B. weil ein neu hinzukommendes Attribut Mehrfacheinträge aufweist. Ein Beispiel wurde oben schon angegeben, die Relationen Pers_UN, die dann in die 1NF gebracht wurde (Pers_1NF). In den folgenden Kapiteln werden oft die Normalformen an die Relationenbezeichnung angehängt, z.B. auch, um die Entwicklung einer Relation über mehrere Normalformen deutlich zu machen.

Wie wird nun die 1NF herbeigeführt? Insgesamt gibt es folgende Verfahren, eine unnormalisierte Relation in die 1NF zu bringen, wobei aber nur die ersten drei korrekt sind:

Herbeiführung der 1NF

Tupelvermehrung

Zerlegung entlang einer 1:n - Beziehung

Zerlegung entlang einer n:m - Beziehung

Attributvermehrung

Ausprägungen zu Attributsnamen

Neue Ausprägungen

7.3 Tupelvermehrung

Die Ausgangsrelationen haben hier den Zusatz "_UN" für "unnormalisiert". Die optimierten Relationen erhalten in diesem Abschnitt das Anhängsel 1NF, auch wenn in Wirklichkeit die erreichte Normalform SCHON HÖHER IST. Diese höheren Normalformen sind aber an dieser Stelle des Textes noch nicht bekannt.

Die Tupelvermehrung wurde oben bereits gezeigt, beim Weg von der Pers_UN zur Pers_1NF. Dabei werden die Mehrfacheinträge so aufgelöst, dass für jeden Eintrag ein eigenes Tupel angelegt wird. So entstanden in Pers_1NF für die Person mit der Personalnummer 123 insgesamt vier Tupel, für jede Programmiersprache eines. Diese Lösung ist naheliegend, man stelle sich aber vor, es würden zahlreiche weitere Attribute in der Relation noch folgen. Dann würde diese Lösung eine gewaltige Vervielfachung von Informationen bedeuten. Auf der anderen Seite erlaubt diese Lösung problemlos die spätere Abfrage der Daten. Sie passt insofern hervorragend in den relationalen Ansatz.

Die Relation Prod_UN erfasst abstrahiert und vereinfacht Hersteller von Datenbanksystemen, mit den Datenbanksystemen und Adressangaben.

Zweites Beispiel Prod_UN

Prod_UN

#NameProd

BezDBS

Ort

Straße

Land

Microsoft

FoxPro, ACCESS

AAA

...

...

Borland

Visual dBase, Paradox

BBB

...

...

CA

INGRES

CCC

...

...

Oracle

Oracle

DDD

...

...

...

NameProd = Name des Herstellers eines Datenbanksystems.
BezDBS = Name des Datenbanksystems. Ort, Straße,
Land = Adressangaben zum Produzenten.

Die Tupelvermehrung führt zu folgender Lösung:

Prod_1NF

NameProd

#BezDBS

Ort

Straße

Land

Microsoft

FoxPro

AAA

...

...

Microsoft

ACCESS

AAA

...

...

Borland

Visual dBase

BBB

...

...

Borland

Paradox

BBB

...

...

CA

INGRES

CCC

...

...

Oracle

Oracle

DDD

...

...

...

Schlüssel: #BezDBS

Hier wird die Erhöhung der Redundanz offensichtlich. Die Adressangaben werden für jedes Datenbanksystem wiederholt. Das Ausmaß der Redundanz wird noch deutlicher, wenn man sich vorstellt, die Adressangaben würden aus den üblichen 10 bis 20 Attributen bestehen. Trotzdem ist obiger Lösungsweg für die Herbeiführung der 1NF sinnvoll, da die dabei evtl. entstehende Redundanz schon beim nächsten Optimierungsschritt, der Realisierung der 2NF, beseitigt wird.

Abkürzungen. Führt man das obige Verfahren durch, entstehen somit erstmals Redundanzen, die dann aber im nächsten Schritt beseitigt werden. Will man dieses vorübergehende Auftreten von Redundanzen nicht, muss man eines der Verfahren wählen, die in den nächsten zwei Abschnitten vorgestellt werden. Diese erfordern allerdings ein vertieftes Verständnis relationaler Beziehungen.

7.4 Zerlegung nach 1:n

Oftmals rühren Mehrfacheinträge daher, dass eine 1:n - Verknüpfung nicht erkannt wurde. Erkennt man dies, kann man sich den Umweg über die Tupelvermehrung sparen und gleich die Zerlegung durchführen. Dann wird also die Ausgangsrelation in zwei miteinander verknüpfte Relationen zerlegt.

Nicht erkannte 1:n-Verknüpfung

Zu erkennen ist dieses Strukturdefizit daran, dass es mindestens ein Attribut gibt, das gegenüber dem Schlüssel Mehrfacheinträge aufweist. Die Lösung ist dann wie folgt:

Ist es nur ein Attribut, muss dieses identifizierenden Charakter haben. Es wird in eine eigene Relation ausgelagert, zusammen mit dem Schlüssel der Ausgangsrelation. Dieser bildet den Fremdschlüssel für die relationale Verknüpfung. Hier drückt die neue Relation also die Beziehung aus. Vgl. das folgende Beispiel Prod_UN.

Sind es mehrere, bilden diese eine eigene Relation. Eines ist der Schlüssel, der Schlüssel der Ausgangsrelation bildet den Fremdschlüssel.

Beispiele

Betrachten wir nochmals die Relation Prod_UN von oben:

Beispiel Prod_UN

Prod_UN (#NameProd, BezDBS, Ort, Straße, Land)

Die Semantik soll so sein [Anmerkung] , dass ein Datenbanksystem auch nur von einem Produzenten hergestellt wird. Dann handelt es sich um eine eindeutige 1:n - Beziehung zwischen Produzenten und Datenbanksystemen [Anmerkung] . Die Zerlegung führt zu folgenden Relationen:

Prod_1NF

#NameProd

Ort

Straße

Land

Microsoft

...

...

...

Borland

...

...

...

CA

...

...

...

...

DBS_1NF

#BezDBS

NameProd

FoxPro

Microsoft

ACCESS

Microsoft

Visual dBase

Borland

Paradox

Borland

INGRES

CA

...

Fremdschlüssel: NameProd

Eigentlich sind diese beiden Relationen schon in der 5NF, da die weiteren Normalformen aber noch nicht besprochen sind, wird hier die nächste erreichte Normalform in der Relationenbezeichnung angeführt.

Wiederverknüpfbarkeit. Wie oben beschrieben, führt diese Zerlegung zu einer neuen Relation in der das Attribut mit den Mehrfacheinträgen zum Schlüssel wird und der Schlüssel der Ausgangsrelation in die neue Relation als Fremdschlüssel kommt. Mit ihm können die beiden Relationen bei Bedarf wieder verknüpft werden. Diese Möglichkeit, auch nach einem durch die Normalisierung erzwungenen Zerlegungsschritt die "alten" Attribute wieder zusammenzufügen, ist von großer Bedeutung. Sie ist Ausdruck einer der Grundregeln der Normalisierung:

Die Zerlegungen im Rahmen der Normalisierung dürfen zu keinem Informationsverlust führen.

Der Grund ist einfach: In der unnormalisierten Relation wurden die Attribute ja nicht willkürlich zusammengestellt, sondern weil sie "irgendwie" zusammengehören (vgl. unten). Dieser Zusammenhang kann bei Auswertungen oder Abfragen wieder Bedeutung gewinnen.

Doch zurück zu den beiden Relationen. Sie machen deutlich, dass die Ursprungsrelation zwei verschiedene Aspekte der Realwelt erfasst hat: zum einen die Beschreibung der Produzenten (von Datenbanksystemen), zum anderen die Beziehung "wer produziert welches System?". Eine solche Vermengung zweier Aspekte in einer Relation führt immer zu Schwierigkeiten. Die Zerlegung in die zwei Relationen führt zu einer sauberen Trennung.

"Vermengung" schafft Redundanz

Im folgenden Beispiel geht es um eine Relation zu Angestellten (Ang), in die auch die Information einefügt wurde, die festhält, in welchen Projekten er oder sie mitarbeitet (BezProj). Damit weist BezProj Mehrfacheinträge auf. Die Lösung sieht so aus, dass eine neue Relation ProjMitarb in der oben beschriebenen Form entsteht (vgl. die Abbildung). Jedes Tupel dieser Relation erfasst eine Beziehung, der Schlüssel der Ausgangsrelation PersNr ist hier Fremdschlüssel und Schlüsselbestandteil.

Beispiel Projektmitarbeit
ProjMitarb

Abbildung 7.4-1: Der Weg zur 1NF - am Beispiel Projektmitarbeit

Das letzte Beispiel zu diesem Themenbereich beschäftigt sich mit Rechnungsartikeln. Hier wurden in einer Relation zu Rechnungsköpfen auch die Artikel (mit der Artikelnummer, ArtNr) erfasst. Damit liegen natürlich Mehrfacheinträge vor. Beseitigt werden sie durch eine Relation Rechnungsartikel (ReArtikel), in der sich die Artikelnummer und der Schlüssel der Ausgangsrelation befinden. Zusammen sind sie Schlüssel der neuen Relation. Jedes Tupel der neuen Relation erfasst jetzt genau einen in der Rechnung enthaltenen Artikel.

Beispiel Kundenrechnungen

Abbildung 7.4-2: Der Weg zur 1NF - am Beispiel Rechnungsköpfe / Artikel

7.5 Zerlegung nach n:m

Oftmals gehen Mehrfacheinträge auch darauf zurück, dass in den Daten eine n:m - Beziehung vorliegt und nicht erkannt wird. Dann muss eine Zerlegung in drei Relationen erfolgen. Eine für die erste Objektklasse, eine für die zweite und eine für die Verknüpfung. Letztere wird zur Verbindungsrelation.

Mehrfacheinträge durch nicht erkannte n:m-Beziehung

Beispiele

Das erste Beispiel ist eine leicht veränderte Version der Relation Pers_UN. Nehmen wir an, dass wir beim Attribut ProgSpr nicht einen spezifischen Compiler, sondern nur die Bezeichnung der Programmiersprache erfassen. Dann handelt es sich um eine n:m - Beziehung zwischen Angestellten und Programmiersprachen: eine Person kann mehrere Programmiersprachen beherrschen und eine Programmiersprache wird u.U. von mehreren Personen beherrscht.

Pers_UN

#PersNr

Name

ProgSpr

Stellenwert

123

Maier

C, COBOL, PHP, C++

1, 4, 2, 3

456

Müller

C++, Java, C

3, 5, 10

...

Das Attribut Stellenwert beschreibt die Bedeutung, den die Programmiersprache für das Unternehmen hat. Mit diesem Attribut werden also die Programmiersprachen beschrieben. Insgesamt sind die Angestellten, die Programmiersprachen und ihre Programmierkompetenz in dieser Relation erfasst. Zu erkennen ist das Vorliegen einer n:m - Beziehung in den Mehrfacheinträgen entweder aus der Semantik des Weltausschnitts heraus, wenn es sich in Wirklichkeit um zwei Objektklassen A und B handelt, die zusammen in einer Relation beschrieben werden, oder durch die einfache Analyse der Daten. Hier machen z.B. die drei folgenden Beziehungen bereits den n:m-Charakter deutlich:

n:m in Mehrfacheinträgen

Maier mit C

Müller mit C

Müller mit C++

D.h., ein Angestellter beherrscht mehrere Sprachen und eine Sprache wird von mehreren Angestellten genutzt. In einem solchen Fall wird die unnormalisierte Relation in drei Relationen zerlegt: eine für die eine Objektklasse, eine für die andere und eine für die Beziehung zwischen ihnen. Die Relationen, die die Objektklassen repräsentieren, erhalten als Schlüssel jeweils eines der Attribute mit Mehrfacheinträgen und alle Attribute, die dieselbe Objektklasse beschreiben. Die Relation für die Beziehungsklasse, die Verbindungsrelation, enthält die beiden Schlüssel, die in ihr zusammen Schlüssel und allein Fremdschlüssel sind.

n:m, gezeigt an 3 Tupeln

Im obigen Beispiel entstehen dann folgende Relationen: Pers beschreibt die Objektklasse der Personen, ProgSpr die der Programmiersprachen und Kompetenz ist die Verbindungsrelation die festhält, welche Person welche Programmiersprache beherrscht.

Pers

#PersNr

Name

123

Maier

456

Müller

...

PS

#ProgSpr

Stellenwert

C

1

COBOL

4

Fortran

2

Prolog

3

C++

10

...

Kompetenz

PersNr

PS

123

C

123

COBOL

123

Fortran

123

Prolog

456

C

456

C++

...

#(PersNr, PS)

Im realen Datenbankentwurf ist es meist so, dass sich die m:n - Beziehung bereits bei der ersten Beschreibung des Weltausschnittes herausstellt und dann gleich entsprechend berücksichtigt werden kann.

Der Vorteil der Zerlegung einer solchen in einer Relation angelegten n:m - Beziehung in mehrere Relationen ist fundamental. Erst dadurch werden die Informationen zugängig und können für Abfragen und Verknüpfungen sinnvoll genutzt werden. Der einzige Nachteil ist unumgänglich und liegt in der Zerlegung selbst, da bei Abfragen mit mehreren Relationen gearbeitet werden muss.

Das zweite Beispiel betrifft die Situation zwischen Kunden und Adressen. Ein Kunde soll mehrere Adressen haben und unter einer Adresse sollen mehrere Kunden wohnen können. Ausgangspunkt ist die unnormalisierte Kundenrelation:

Kundenadressen:
KuAdr

Kunden_UN (#KuNr, Name, Vname, PLZ, Ort, Straße)

In ihr werden zum einen Kunden beschrieben (über #KuNr, Name, VName), zum anderen Adressen (PLZ, Ort, Straße). Die Lösung besteht nun darin, für die Kunden eine eigene Relation anzulegen (Kunden_1NF) mit dem Schlüssel KuNr. Genauso für die Adressen (Adressen_1NF) mit einer Adressennummer (AdrNr). dieser Schlüssel muss hinzugefügt werden. Die Verbindung zwischen Adressen und Kunden wird über eine Verbindungsrelatioin KuAdr_1NF hergestellt. In solchen Verbindungsrelationen sind dann die beiden Schlüssel der Ausgangsrelationen Fremdschlüssel und zusammen der Schlüssel.

Abbildung 7.5-1: Der Weg zur 1NF - am Beispiel Kundenadressen - Variante 1

Oftmals wird darauf verzichtet die Tatsache, dass mehrere Kunden dieselbe Adressen haben, in die Modellierung einzubeziehen. Man verhindert damit zwar Redundanz in den Daten (allerdings nicht sehr viel), muss aber eine weitere Relation akzeptieren, was die Abfragen und Auswertungen komplizierter macht. Die einfachere Lösung zeigt die folgende Abbildung. Die Beziehung zwischen Kunden und Adressen wird als 1:n - Beziehung festgelegt, so dass bei jeder Adresse die Kundennummer (KuNr) als Fremdschlüssel hinterlegt werden kann. Eine solche pragmatische Entscheidung muss im Datenbankdesign öfters gefällt werden. Sie sollte jeweils in ihren Konsequenzen sorgfältig bedacht werden.

Pragmatik

Abbildung 7.5-2: Der Weg zur 1NF - am Beispiel Kundenadressen - Pragmatische Variante 2

Es kommt auch vor, dass beim Entwurf einer Relation mehrere einzelne Attribute Mehrfacheinträge aufweisen. In einem solchen Fall muss man die Mehrfacheinträge in getrennten Relationen auflösen. Für jedes Attribut entsteht also eine neue Relation mit dem Attribut, das Mehrfacheinträge aufweist und mit dem Schlüssel der ursprünglichen Relation. Dies ist auch Gegenstand der 4NF, die in Kapitel 12 beschrieben wird. Bei ihr geht es um die Schwierigkeiten, die man sich einhandelt, wenn man beide (oder noch mehr) Mehrfacheinträge innerhalb einer Relation auflöst.

Mehrere Mehrfacheinträge,
Siehe auch Kapitel 12 mit der 4NF

Die folgende Abbildung zeigt ein Beispiel. In eine Relation, die Mannschaften beschreibt (Fußball, Handball, ...) wurde auch ein Attribut für die Spieler (identifiziert durch die Spielernummer, SpNr) und eines für die Trainer (identifiziert durch die Trainernummer, TrNr) eingefügt. Beide haben aber Mehrfacheinträge, gehören also nicht in diese Relation. In die erste Normalform kommen die Relationen, indem man für beide eine neue Relation anlegt. Die Verknüpfung zur Ausgangsrelation erfolgt über die Mannschaftsbezeichnung (MaBez) als Fremdschlüssel in den beiden neuen Relationen.

Mehrere Spieler, mehrere Trainer

Abbildung 7.5-3: Der Weg zur 1NF - am Beispiel Mannschaften

Wie sehr eine kleine Änderung in der Attributzusammensetzung der unnormalisierten Relation das Ergebnis verändert zeigt das folgende Beispiel. In Abbildung 7.4-1 wurde Projektmitarbeit nur mit einem Attribut erfasst (der Projektbezeichnung). Das Ergebnis war dann eine einzige ausgelagerte Relation. Werden die Projekte aber durch zwei oder mehr Attribute beschrieben, wird aus der "1:n-Zerlegung" eine "n:m-Zerlegung", wie es die folgende Abbildung zeigt.

Projektmitarbeit n:m

Hier wird für die Projekte noch zusätzlich die Länge und der Standort (StOrt) erfasst. Dadurch entsteht die weitere Relation Projekte_1NF. Der Grund ist klar: Die Projektbezeichnung ist nicht mehr nur beschreibendes (mehrwertiges) Attribut von Angestellte, sondern Schlüssel einer eigenständigen Relation.

Abbildung 7.5-4: Der Weg zur 1NF - am Beispiel Projektmitarbeit

7.6 Schlechte Lösungen

Attributvermehrung

Ein oft genutzter Lösungsweg für die Beseitigung von Mehrfacheinträgen besteht darin, aus dem Attribut mit Mehrfacheinträgen mehrere Attribute zu machen und zwar so, dass jedes der neu entstandenen Attribute "flach" ist. Dabei hängt die Zahl der entstehenden Attribute von der maximalen Zahl von Ausprägungen ab, die sich bei den Mehrfacheinträgen finden. Betrachten wir folgende Variante der Relation Pers_UN, bei der zu jedem Angestellten noch der Name angegeben ist.

Pers_UN

#PersNr

ProgSpr

Name

123

C, COBOL, PHP, C++

Müller

456

C++, Java, C

Maier

234

PHP, C

Schweizer

345

Smalltalk, Prolog

Fricksen

567

C++, Java

Rau

Die maximale Zahl von Mehrfacheinträgen ist vier. Mit obigem Verfahren sieht die auf diese Weise in die 1NF gebrachte Relation dann so aus:

Pers_1NF

PersNr

PS-1

PS-2

PS-3

PS-4

Name

123

C

COBOL

PHP

C++

Müller

456

C++

Java

C

-

Maier

234

PHP

C

-

-

Schweizer

345

Smalltalk

Prolo

-

-

Fricksen

567

C++

Java

-

-

Rau

Es ist wohl sofort ersichtlich, dass diese Lösung zwar zu einer flachen Tabelle führt, in der Praxis aber kaum bestehen kann und den Prinzipien der relationalen Theorie in vollem Umfang widerspricht. Einige der Nachteile:

Die Abfrage der Programmiersprachen wird komplizierter (man stelle sich eine Abfrage des Typs "Wer beherrscht Java?" vor, von komplizierteren Abfragen ganz zu schweigen).

Relationale Verknüpfungen über ein solches Feld sind praktisch unmöglich.

Sollte jemand eingestellt werden, der mehr als vier Programmiersprachen beherrscht, muss die Struktur der Relation geändert werden.

Da die Zahl der Mehrfacheinträge in der Regel stark schwankt, entstehen viele Felder mit Leereinträgen.

Diese Lösung ist somit nicht mit der relationalen Theorie vereinbar.

Ausprägungen zu Attributsnamen

Dasselbe gilt für die Lösung, die in der folgenden Tabelle angedeutet ist. Hier wurden die Attributsausprägungen eines Attributs (beherrschte) Programmiersprachen zu Attributsnamen gemacht. Leider ist so etwas in real existierenden Datenbanken sehr oft zu sehen.

Pers_1NF

PersNr

C

PHP

Prolog

C++

Cobol

Java

Smalltalk

Name

123

ja

ja

ja

ja

Müller

234

ja

ja

Schweizer

345

ja

ja

Fricksen

456

ja

ja

ja

Maier

567

ja

ja

Rau

Eine solche Lösung hat alle oben beschriebenen Schwächen. Zusätzlich ist es ohne Kontaktierung des Data Dictionary [Anmerkung] nicht mehr möglich abzufragen, welche Programmiersprachen im Unternehmen vorhanden sind.

Neue Ausprägungen

Auch die letzte hier angeführte Lösung ist nicht tauglich. Dabei wird das Attribut einfach umdefiniert, z.B. von "Beherrschte Programmiersprachen" zu "Liste der beherrschten Programmiersprachen" bzw. von "Telefonnummer" zu "Liste der Telefonnummern". Natürlich bedeutet auch dies den gänzlichen Verzicht auf alle Operationen, die über die reine Informierung durch die Ausprägungen hinausgehen.

7.7 Relationale Datenmodelle

Oben wurden ja schon zahlreiche Modellfragmente erstellt. Spätestens nach der Herbeiführung der 1NF lohnt es sich aber, ganze Datenmodelle mit mehreren Relationen, Verknüpfungen, usw. darzustellen. Dabei wird dann auch deutlich, welche Bedeutung die beiden Darstellungstechniken (textliche und grafische) haben.

Textliche und grafische Darstellung (auch Notation genannt)

Die grafische Darstellung zeigt den Gesamtzusammenhang auf, die Verknüpfung der einzelnen Relationen durch Schlüssel und Fremdschlüssel. Deshalb werden in dieser Notation auch nur Fremdschlüssel und Schlüssel angegeben (vgl. die folgende Abbildung). Die Beziehungen zwischen den Relationen, die relationalen Verknüpfungen, werden durch die oben schon gezeigten Linien zwischen den beteiligten Attributen ausgedrückt (meist Schlüssel in der einen und Fremdschlüssel in der anderen Relation).

Die textliche Notation gibt dagegen die Gesamtheit aller Attribute an. Schlüssel und Fremdschlüssel werden dabei auch gekennzeichnet.

Datenmodell Angestellte

Für ein Beispiel fassen wir die Modellfragmente der oberen Kapitel zum Anwendungsbereich Angestellte zu einem kleinen Datenmodell Angestellte zusammen. Folgende Semantik gilt bzw. wurde festgelegt:

Angestellte / Abteilungen: Ein Angestellter arbeitet in genau einer Abteilung, einer Abteilung können mehrere Angestellte zugeordnet sein: Kardinalität n:1. Mit den Min-/Max-Angaben 1,1 : 1,n kann noch festgelegt werden, dass es keine Angestellten ohne Abteilungszugehörigkeit gibt und dass jede Abteilung mindestens einen zugeordneten Angestellten hat.

Angestellte / PC: Einem Angestellten ist genau ein PC zugeordnet: Kardinalität 1:1. Mit den Min-/Max-Angaben 1,1 : 0,1 wird noch präzisiert, dass es keinen Angestellten ohne zugehörigen PC gibt, sehr wohl aber PCs, die noch nicht zugeordnet sind.

Angestellte / Projekte: Ein Angestellter kann in mehreren Projekten mitarbeiten, ein Projekt kann mehrere zugeordnete Angestellte haben: n:m. Mit den Min-/Max-Angaben wird noch präzisiert, dass es Angestellte ohne Projektzugehörigkeit gibt und dass man Projekte anlegen kann, ohne bereits Projektmitarbeiter zu kennen.

Damit ergeben sich folgende Relationen:

Textliche Darstellung

Projekte (#Bez, TagEinr, Dauer, Budget)

ProjMitarb (#(PersNr, BezProj))

Abteilungen (#AbtBez, AbtLeiter, Standort)

Angestellte (#PersNr, Name, VNname, DatEinst, GebTag, AbtBez, InvNrPC)

PC (#InvPC, Bez, Typ)

Die folgende Abbildung zeigt die grafische Darstellung.

Abbildung 7.7-1: Datenmodell Angestellte - grafische Darstellung

Semantik

Allein durch die Gestaltung der Relationen, Schlüssel und Fremdschlüssel ist ein großer Teil der oben gewünschten Semantik bereits festgelegt:

ProjMitarb ist eine Verbindungsrelation. Dies bedeutet aufgrund der Schlüsselkonstruktion, dass in einem Projekt mehrere Mitarbeiter erfasst werden können und dass ein Mitarbeiter auch in mehreren Projekten mitwirken kann. Datenbanktechnisch: Jeder Eintrag in ProjMitarb muss eine Personalnummer und eine Projektbezeichnung enthalten, d.h. der Schlüssel muss vollständig sein (Objektintegrität). Zu jedem Eintrag in Angestellte.PersNr gibt es keinen, einen oder mehrere Einträge in ProjMitarb.PersNr. Zu jedem Eintrag in Projekte.Bez gibt es keinen, einen oder mehrere Einträge in ProjMitarb.BezProj. Umgekehrt gilt: zu jedem Eintrag in der Relation ProjMitarb gibt es entsprechende Einträge in Projekte und Angestellte. Dies verlangt die Forderung nach referentieller Integrität.

Angestellte / PC: Hier ist aus der Anlage des Fremdschlüssels erkennbar, dass jede/r Angestellte genau einen zugewiesenen PC hat. Außerdem kann es PCs geben, die keinem Angestellten zugwiesen sind.

Angestellte / Abteilungen: Hier ist, wiederum aus der Anlage des Fremdschlüssels, erkennbar, dass jeder Angestellte zu genau einer Abteilung gehört. Umgekehrt kann es Abteilungen geben, denen noch kein Angestellter zugewiesen ist. Dies widerspricht den obigen Anforderungen. Dazu gleich unten mehr.

Datenmodell Angestellte - mit Kardinalitäten

Keinen Zuwachs an semantischer Aussagekraft bringt das Hinzufügen der Kardinalitäten. Es erlaubt aber dem flüchtigen oder nicht so theoriefesten Betrachter das schnellere Verständnis.

Abbildung 7.7-2: Datenmodell Angestellte – mit Kardinalitäten

Lesehilfe zu den Kardinalitäten (einschließlich Schlüssel-/Fremdschlüsselverknüpfungen)

Angestellte / PC:

- Ein PC hat genau einen zugeordneten Angestellten

- Ein Angestellter hat genau einen zugeordneten PC

Angestellte / Abteilungen:

- Eine Abteilung hat zugeordnete Angestellte

- Ein Angestellter ist einer Abteilung zugeordnet

ProjMitarb:

- Ein Angestellter kann in mehreren Projekten mitwirken

- Ein Projekt kann mehrere zugeordnete Angestellte haben

Datenmodell Angestellte – mit Min-/Max-Angaben

Eine genauere Beschreibung der Semantik bringt das Einfügen der Min-/Max-Angaben, wie es die folgende Abbildung zeigt. Hier kann nun auch der semantische Aspekt umgesetzt werden, dass wir Abteilungen nur anlegen wollen, wenn wir mindestens einen zugehörigen Anestellten haben, z.B. die Abteilungsleiterin. Dies leisten die Min-/Max-Angaben (1,1 : 1,n) für Angestellte / Abteilungen.

Abbildung 7.7-3: Datenmodell Angestellte - mit Min-/Max-Angaben

Lesehilfe zu den Min-/Max-Angaben

Angestellte / PC:

- Ein PC hat keinen oder maximal einen zugeordneten Angestellten

- Ein Angestellter hat genau einen zugeordneten PC

Angestellte / Abteilungen:

- Eine Abteilung hat mindestens einen zugeordneten Angestellten

- Ein Angestellter ist genau einer Abteilung zugeordnet

ProjMitarb:

- Für jeden Eintrag in ProjMitarb.BezProjekt gibt es genau einen Eintrag in Projekte.Bez.

- Für jeden Eintrag in ProjMitarb.PersNr gibt es genau einen Eintrag in Angestellte.PersNr.

- Ein Projekt kann auch angelegt werden, wenn noch kein Projektmitarbeiter bekannt ist. D.h., für jeden Eintrag in Projekte.Bez kann es keinen, einen oder mehrere Einträge in ProjMitarb.BezProj geben.

- Ein Angestellter kann, muss aber nicht in durchaus mehreren Projekten mitarbeiten. D.h., für jeden Eintrag in Angestellte.PersNr kann es keinen, einen odere mehrere Einträge in ProjMitarb.PersNr geben.

Konsequenzen für die Datenbank:

Ein Angestellter kann nur eingegeben werden, wenn ein zugewiesener PC bekannt ist und wenn seine Abteilung klar ist.

Eine Abteilung kann in der Relation Abteilungen erst eingegeben werden, wenn zumindest ein Abteilungsmitglied bekannt ist, z.B. der Abteilungsleiter.

Eine Projektmitarbeit kann auch angelegt werden, wenn das Projekt in Projekte noch nicht existiert bzw. wenn der Angestellte nicht in Angestellte eingetragen ist.

Ganz schön viel Semantik, die natürlich auch ganz anders sein kann. Auf jeden Fall hat sie Einfluss auf die Struktur der Datenbank, die Eingabe- und Auswertungsmöglichkeiten.

Beispiel: (Markt für) Datenbanksysteme.

Auch das zweite einfache Beispiel ist oben in den Fragmenten teilweise schon aufgetaucht. Es geht um Datenbanksysteme, ihre Produzenten und Datentypen sowie um die Händler, von denen das Datenbanksystem gekauft werden kann. Die Beziehungen seien wie folgt:

Produzenten / DBS (Datenbanksysteme) mit Kardinalität 1:n. Ein Produzent produziert ein Datenbanksystem oder mehrere, jedes Datenbanksystem hat genau einen Produzenten. Genauer mit Min-/Max-Angaben, z.B. 1,n : 1,1. Einen Produzenten erfassen wir erst, wenn mindestens ein von ihm hergestelltes Datenbanksystem bekannt ist. Ein Datenbanksystem wird nur erfasst, wenn der Produzent bekannt ist (dies fordert allerdings bereits die referentielle Integrität).

Dafür wird in der Relation DBS ein Fremdschlüssel PrName angelegt.

DBS / Datentypen mit Kardinalität 1:n. Zu einem Eintrag in DBS können mehrere in Datentypen gehören (zusammengesetzter Schlüssel). Zu einem Eintrag in (BezDBS, BezDT) gehört genau ein Eintrag in DBS.Bez. M.a.W.: Ein Datenbanksystem hat mehrere Datentypen, ein Datentyp kann in mehreren Datenbanksystemen vorkommen. Die Min-/Max-Angaben 1,n : 1,1 legen zusätzlich fest, dass für Einträge in die Datenbank jeweils mindestens ein Datentyp bzw. ein Datenbanksystem vorliegen muss.

Dafür wurde die Verbindungsrelation Datentypen (#BezDBS, BezDT) angelegt. BezDT ist nur deshalb nicht Fremdschlüssel, weil keine Beschreibung der Datentypen in einer weiteren Relation vorhanden ist.

DBS / Händler mit Kardinalität n:m. Ein Datenbanksystem wird von mehreren Händlern angeboten, ein Händler bietet u.U. mehrere Datenbanksysteme an. Die Min-/Max-Angaben 0,n : 0,m für Angebot legen fest, dass auch Datenbanksysteme erfasst werden, für die noch kein Händler vorliegt und Händler, von denen wir noch kein Datenbanksystem kennen.

Dafür wird eine Verbindungsrelation Angebot (#(FiName, BezDBS), Preis) angelegt.

Bei Verbindungsrelationen ist es auch möglich, die einzelnen Verknüpfungen bzgl. ihrer Min-/Max-Angaben zu betrachten. Für DBS – Angebot ist dies hier 0,n : 1,1, für Händler – Angebot 0,n : 1,1.

Die textliche Notation ergibt sich damit wie folgt:

Produzenten (#Name, Ort, Straße, Land, WWW)

DBS (#Bez, Typ, Plattform, LPreis, PrName)

Angebot (#(FiName, BezDBS), Preis)

Händler (#Name, Ort, Straße, Tel, Fax, Rabatte, AnsprP)

DBS-DT (#(BezDBS, BezDT)

Die grafische Notation mit Kardinalitäten und Min-/Max-Angaben:

Abbildung 7.7-4: Relationales Datenmodell (Markt für) Datenbanksysteme

Bezeichnungen der Attribute, soweit nicht selbsterklärend:

DBS.LPreis: Listenpreis des jeweiligen Datenbanksystems

DBS.Typ: Datenbanksystemtyp (relational, objektorientiert, NoSQL, …)

DBS.PrName: Name (Bezeichnung) des Datenbankproduzenten

Angebot.FiName: Firmenname

Angebot.BezDBS: Bezeichnung des Datenbanksystems

Händler.AnsprP: Ansprechpartner

DBS-DT.NameDT: Bezeichnung des Datentyps

7.8 Redundanzen in 1NF-Relationen

Die Ausgangsrelationen haben hier den Zusatz "_1NF". Die optimierten Relationen erhalten das Anhängsel 2NF, auch wenn in Wirklichkeit die erreichte Normalform schon höher ist. Diese höheren Normalformen sind aber an dieser Stelle des Textes noch nicht bekannt.

Mit obigem Normalisierungsschritt sind schon recht vorzeigbare Relationen realisierbar und die Ergebnisse im vorigen Abschnitt waren auch schon in der höchsten denkbaren Normalform (5NF), auch wenn bei den Abbildungen jeweils aus didaktischen Gründen 1NF angehängt wurde. In der Modellpraxis ist es aber so, dass Relationen in 1NF durchaus noch Mängel aufwiesen. Dies sind immer solche, die zu Redundanzen in den Daten führen, wenn die Relation bei der Einrichtung der Datenbank angelegt und die dann entstehende Datei mit Daten gefüllt wird. Diese Redundanzen entstehen im wesentlichen aus zwei Quellen:

Wenn die Relation einen zusammgesetzten Schlüssel hat und sich von den übrigen Attributen eines (oder mehrere) auf Teile des Schlüssels beziehen.

Wenn sich von den übrigen Attributen eines (oder mehrere) gar nicht auf den Schlüssel bezieht, sondern auf ein anderes Attribut.

Dazu einige Beispiele. Die folgende Relation hält Informationen zur Projektmitarbeit fest. Sie ist ohne Mehrfacheinträge, also in 1NF. Neben der Zordnung von Angestellten zu Projekten wird auch der jeweilige Name des Angestellten und die Dauer des Projekts eingefügt:

Beispiel Projektmitarbeit

ProjMitarb (#(PersNr, BezProj), Name, Dauer)

Diese Relation ist in 1NF, da sie keine Mehrfacheinträge aufweist. Trotzdem hat sie "Schwachstellen". Dies macht die folgende tabellarische Darstellung mit Beispielsdaten deutlich.

ProjMitarb_1NF

PersNr

BezProj

Name

Dauer

1001

BPM

Maier

18 Monate

1001

SocWeb

Maier

12 Monate

2001

BPM

Rau

18 Monate

...

Schlüssel: #(PersNr, BezProj)

Schon die wenigen Tupel zeigen die Redundanz. Für jede einzelne Projektmitarbeit wird der Name erfasst sowie die Dauer des Projekts. Wenn also eine Person in fünf Projekten mitarbeitet, taucht der Zusammenhang von Angestellten und Namen sowie von Projekten und Projektdauer fünffach in den Daten auf.

Redundanzen dieses Typs werden durch die 2NF beseitigt

Die folgende Relation beschreibt Auftragsköpfe. Sie enthält zusätzlich zum Schlüssel noch das Auftragsdatum, die Kundennummer (KuNr) und den Namen des Kunden (KuName).

Beispiel Auftragsköpfe

AuftrKöpfe (#AuftrNr, AuftrDatum, KuNr, KuName)

Wo ist die Redundanz? Die nachfolgende tabellarische Darstellung macht es deutlich. Der Kundenname wird bei jedem Auftrag angegeben. Hat ein Kunde also 200 Aufträge realisiert, wird 200 mal der Zusammenhang von Kundennummer und Kundenname festgehalten.

AuftrKöpfe_1NF

AuftrNr

AuftrDatum

KuNr

KuName

1001

10.1.2014

1007

Müller GmbH

1010

5.10 2015

2008

Steiner

2011

1.9.2015

1007

Müller GmbH

2012

20.12.2015

2008

Steiner

...

Schlüssel: #AuftrNr

Redundanzen dieses Typs werden durch die 3NF beseitigt

Die folgende Relation soll erfassen, welcher Dozent (Dozentennummer, DozNr; Dozentenname, DozName) in welchem Semester welche Lehrveranstaltung (LV) hält (in jedem Semester nur einmal). Die Namen der Dozenten seien eindeutig.

Beispiel Lehre an Hochschulen

Lehre (#(DozNr, LV), DozName, Semester)

oder

Lehre (#(DozName, LV), DozNr, Semester)

Wiederum zeigen einige Beispielsdaten in der tabellarischen Darstellung die Redundanz.

Lehre_1NF

DozNr

LV

Semester

DozName

1001

DBS

WS15

Müller

1007

BWL

WS15

Steiner

1001

EinführungWI

SS15

Müller

1007

BI

SS15

Steiner

...

Schlüssel: #(DozNr, LV) oder #(DozName, LV)

Die Relation ist in 1NF (sogar in einer höheren, wie später zu sehen sein wird, vgl. Kapitel 11), trotzdem hat sie Redundanzen. Der Zusammenhang zwischen DozNr und DozName wird in jedem Tupel erfasst. Wenn also ein Dozent fünf verschiedene Lehrverantaltungen gibt, insgesamt fünf mal.

Redundanzen dieses Typs werden durch die BCNF beseitigt

Soweit ein erster Blick auf die in 1NF-Relationen vorkommenden fehlerhaften Strukturen. In den nächsten Kapiteln wird gezeigt, wie sie beseitigt werden können. Zuerst aber erst noch ein Blick auf die negativen Konsequenzen dieser Strukturdefizite.

7.9 Anomalien

Dazu betrachten wir eine Relation, in die alle diese Defizite eingebaut wurden. Die Konsequenzen der Defizite werden in der Literatur auch als Anomalien bezeichnet.

Relation Aufträge – in 1NF und doch fehlerbehaftet.

Diese Relation hält Informationen zu Aufträgen fest. Die AuftrNr identifiziert den Auftrag, die PosNr die einzelnen Positionen eines Auftrags. Jede Position bezieht sich auf ein Produkt, das durch ProdBez(eichnung) benannt und zusätzlich durch die ProdNr identifiziert wird. Menge gibt an, wieviele Produkte in der Position aufgeführt sind. Das Attribut KuNr identifiziert den Kunden, auf den sich der Auftrag bezieht. Die Kundennamen (KuName) sind nicht eindeutig.

Aufträge_1NF

AuftrNr

PosNr

ProdNr

ProdBez

Menge

Auftr-
Datum

KuNr

KuName

0001

1

9901

Laser Dru x

1

30.06.15

1700

Müller

0001

2

9910

Toner xyz

3

30.06.15

1700

Müller

0001

3

9905

Papier abc

5.000

30.06.15

1700

Müller

0010

1

9905

Papier abc

30.000

01.07.14

1201

Sammer

0010

2

9910

Toner xyz

1

01.07.14

1201

Sammer

0011

1

9901

Laser Dru x

1

02.07.15

1600

Stanzl KG

0011

2

9911

Tintenpatr x

20

02.07.15

1600

Stanzl KG

0011

3

9905

Papier abc

5.000

02.07.15

1600

Stanzl KG

0011

4

9906

InkJet-Dru y

2

02.07.15

1600

Stanzl KG

0012

1

9998

z-Bildschirm

1

04.07.16

1900

Max OHG

...

Schlüssel: #(AuftrNr, PosNr)

Es ist unschwer zu erkennen, dass die beiden Attribute AuftrNr und PosNr den Schlüssel der Relation darstellen, weil mit den Ausprägungen dieser Attribute jedes Tupel (jede Zeile) eindeutig identifiziert werden kann. Diese Relation ist in 1NF, da sie keine Mehrfacheinträge aufweist. Trotzdem hat sie Schwachstellen. Betrachten wir als erstes Schwierigkeiten, die sich beim Aktualisieren von Datensätzen ergeben können.

Schlüssel der Relation

Aktualisierungs-Anomalie

Eine sogenannte Aktualisierungs-Anomalie liegt vor, wenn die Änderung einer Information dazu führt, dass in mehreren Tupeln die Ausprägung des entsprechenden Attributs verändert werden muss. Dies ist grundsätzlich unerwünscht. Es hat bei der Aktualisierung des Werts die Konsequenz, dass die Zahl der zu ändernden Tupel im Vornehinein unbekannt ist. Unter Umständen muss die gesamte Relation durchsucht werden.

Eine Aktualisierung, mehrere zu ändernde Tupel

Ursache für eine solche Struktur ist, dass eine bestimmte Information mehrfach in der Datenbank abgespeichert ist. Im obigen Beispiel: Werden die Produktbezeichnungen geändert, indem z.B. der Produktnummer 9901 statt "Laser Dru(cker) x" jetzt "HP Laser Dru Serie 5" zugeordnet wird, dann muss die Prdouktbezeichnung nicht nur in einem Tupel, sondern in mehreren geändert werden. Dies führt leicht dazu, dass die eine oder andere Stelle vergessen wird.

Gleiches gilt für das AuftrDatum. Müssen wir dieses aus irgendwelchen Gründen ändern, muss dies mehrfach geschehen. Auch die Kundennamen weisen diese Eigenschaft auf. Ändert sich der Kundenname des Kunden 1700 von "Müller" nach "Müller amp; Paul", sind bei der Aktualisierung wieder mehrfache Änderungen nötig.

Es ist klar, wodurch diese Anomalie verursacht ist. Durch einen Verstoß gegen die oben angeführte zentrale Regel des Datenbankentwurfs, wonach die Datenbank so zu gestalten ist, dass jede Information nur an einer Stelle gespeichert wird.

Zentrale Regel

Einfüge-Anomalie

Redundanzen bereiten auch Schwierigkeiten beim einfachen Einfügen von Daten, dies führt zur Einfüge-Anamolie. Eine solche liegt vor, wenn ein neues (noch) unvollständiges Tupel nicht in die Relation eingetragen werden kann, z.B. weil unter den fehlenden Attributen ein Schlüsselattribut ist. Diese Anomalie beruht also auch auf der oben dargelegten Festlegung, dass ein Tupel in die Relation nur eingetragen werden darf, wenn die Ausprägungen für die Schlüsselattribute (die Attribute, die den Schlüssel ausmachen) vorhanden sind (vgl. Abschnitt 5.9 zur Forderung nach Objektintegrität).

Einfügbarkeit gefährdet

Im obigen Beispiel: Nehmen wir neue Produkte mit ProdNr und ProdBez auf, so können wir sie in der Relation erst erfassen, wenn wir zumindest einen Auftrag mit Positionsnummer haben, in dem sie erscheinen. Sonst wäre eine Erfassung nicht möglich, da ja kein Schlüsselattribut vorliegen würde. Ähnlich gilt für das AuftragsDatum. Es kann erst erfasst werden, wenn die erste Position des Auftrags bekannt ist. Gleiches gilt für KuNr und KuName.

Die Ursache für diese Anomalie liegt darin, dass in obiger Relation mehrere verschiedene "Dinge" zusammen beschrieben werden: die Objektklassen Aufträge, Produkte und Kunden, sowie die Beziehungsklasse Aufträge-Kunden. Diese Strukturschwäche wird mit Hilfe des Konzepts der funktionalen Abhängigkeit gelöst (vgl. das nächste Kapitel).

Verschmelzung von Objekten, Objektklassen

Lösche-Anomalie

Die letzte Anomalie beschreibt Schwierigkeiten, die aus den Redundenzen beim Löschen von Datensätzen auftreten. Von einer Lösche-Anomalie wird gesprochen, wenn beim Löschen einer Information, die nur einen Teil des Tupels betrifft, auch die übrigen Attributswerte verloren gehen. Im obigen Beispiel: Löscht man den Auftrag 0012, der nur eine Position hat, geht auch die Information verloren, dass z-Bildschirme die Produktnummer 9998 haben.

Probleme beim Löschen

Wiederum liegt die Ursache in der Vermischung mehrerer Objekt- und Beziehungsklassen in einer Relation.

Ziel

Was ist das Ziel bei der Erkennung und Beseitigung der Anomalien? Selbst dieses sehr einfachen Beispiele machen deutlich, wohin die drei Anomalien zielen: sie dienen zur Klärung, welche Attribute am besten zusammen erfasst werden und welche besser getrennt werden. Sie bringen also Ordnung in den zu Beginn jeder Modellierung entstehenden "Attributs- und Merkmalshaufen", der sog. Universalrelation.

Ordnung in den "Attributshaufen"

Während die 1NF dazu führte, dass die Attribute zusammen bleiben, deren Ausprägungen so den Objekten zugeordnet werden können, dass je genau eine Ausprägung mit den anderen kombiniert wird, liegt hier eine andere Situation vor. Hier geht es darum, die Attribute zusammenfassen, die zusammen mit einem Schlüssel einen "homogenen" Block bilden, indem sie genau die vom Schlüssel identifizierten Objekte beschreiben und keine anderen.

Dies wird erreicht durch Beseitigung der Redundanz, die in solchen Relationen angelegt ist. Deren Beseitigung klärt auch die Anordnung der Attribute in der Relation. Ein sehr hilfreiches Mittel für die Klärung der inneren Struktur von Relationen sind die sog. funktionalen Abhängigkeiten, die im nächsten Kapitel betrachtet werden.

8 Funktionale Abhängigkeiten

In diesem Abschnitt geht es um die Beziehungen zwischen den Attributen einer einzelnen Relation, nicht um die Beziehungen zwischen verschiedenen Relationen.

8.1 Einführung

Vereint modellieren

Die wichtigste Beziehung zwischen den Attributen einer einzelnen Relation ist die, dass sie zusammen die Objekte / Beziehungen der jeweiligen Objekt- oder Beziehungsklasse modellieren. So wie in der oben schon eingeführten Relation Aufträge modelliert werden. Daher rührt die Bezeichnung Relation für eine Tabelle, die diese Zusammengehörigkeit ausdrückt. Neben dieser fundamentalen Beziehung gibt es aber noch weitere, die bei der Optimierung der Relationen helfen.

Wichtigste Beziehung zwischen den Attributen einer Relation

Schließen, vom Einen auf das Andere

Betrachten wir obige Relation Aufträge_1NF nochmals und etwas genauer.

Aufträge_1NF

AuftrNr

PosNr

ProdNr

ProdBez

Menge

AuftrDatum

KuNr

KuName

0001

1

9901

Laser Dru x

1

30.06.15

1700

Müller

0001

2

9910

Toner xyz

3

30.06.15

1700

Müller

0001

3

9905

Papier abc

5.000

30.06.15

1700

Müller

0010

1

9905

Papier abc

30.000

01.07.14

1201

Sammer

0010

2

9910

Toner xyz

1

01.07.14

1201

Sammer

0011

1

9901

Laser Dru x

1

02.07.15

1600

Stanzl KG

0011

2

9911

Tintenpatr x

20

02.07.15

1600

Stanzl KG

0011

3

9905

Papier abc

5.000

02.07.15

1600

Stanzl KG

0011

4

9906

InkJet-Dru y

2

02.07.15

1600

Stanzl KG

0012

1

9998

z-Bildschirm

1

04.07.16

1900

Max OHG

...

Schlüssel: #(AuftrNr, PosNr)

Dann können wir feststellen, dass von bestimmten Attributen auf andere geschlossen werden kann (wobei die Grundlage dafür die Kenntnis der Semantik des jeweiligen Weltausschnitts ist). D.h., ist die Ausprägung des einen Attributs bekannt, kann die Ausprägung des anderen angegeben werden. Im obigen Beispiel ist dies in folgenden Fällen möglich:

Zusammenhang zwischen Attributen

Von der ProdNr kann auf die ProdBez geschlossen werden, und umgekehrt, wenn wir von der naheliegenden Tatsache ausgehen, dass beide - Produktnummern und Produktbezeichnungen - eindeutig sind.

Von der AuftrNr kann auf das AuftragsDatum geschlossen werden, weil ein Auftrag ein bestimmtes Datum hat.

Von der KuNr kann auf den KuName(n) geschlossen werden.

Von AuftrNr und PosNr zusammen(!) auf die ProdNr, die ProdBez(eichnung) und die Menge, da an einer Position eines Auftrags nur ein Produkt mit einer Mengenangabe aufgeführt wird.

Solche Beziehungen müssen nicht existieren. So kann z.B. weder von der AuftrNr auf die PosNr, noch von der ProdBez(eichnung) auf den KuName(n), usw. geschlossen werden. Wenn sie aber da sind, sind sie für die Modellierung von großer Bedeutung.

8.2 Funktionale Abhängigkeit

Sind nun aber zwischen Attributen oder Attributkombinationen solche "Schlüsse" möglich, wird von voller funktionaler Abhängigkeit (f.A.) gesprochen. Die Wortwahl ist folgende: Kann vom Attribut A auf das Attribut B "geschlossen" werden, ist B funktional abhängig von A.

In der textlichen Notation wird die volle funktionale Abhängigkeit mit dem grafischen Symbol "Pfeil mit Doppellinie" => dargestellt, also z.B. so:

=>

A => B (Attribut B ist funktional abhängig von Attribut A) oder

AuftrNr => KuNr

Alle bisher betrachteten funktionalen Abhängigkeiten sind sogenannte "volle". Auf die Unterscheidung von "voller" und "einfacher" f.A. wird weiter unten eingegangen.

Eine andere - gleichwertige - Interpretation der funktionalen Abhängigkeit ist es, die Attributsausprägungen zu betrachten: Gibt es für eine Ausprägung eines Attributs A für alle Tupel immer genau dieselbe für ein Attribut B, dann ist B funktional abhängig von A. Im obigen Beispiel:

Zweite Interpretation

Jedesmal, wenn in einem Tupel eine bestimmte Produktnummer auftritt, kommt dieselbe Produktbezeichnung vor. Dies gilt auch umgekehrt.

Jedesmal, wenn in einem Tupel eine bestimmte Auftragsnummer vorkommt, kommt dasselbe Auftragsdatum vor.

Jedesmal, wenn in einem Tupel eine bestimmte Kundennummer vorkommt, kommt derselbe Kundenname vor.

Für eine bestimmte Kombination aus Auftragsnummer + Positionsnummer gibt es genau eine Angabe zu Produktnummer, Produktbezeichnung und zur Menge.

Jedesmal wenn in einem Tupel eine bestimmte Auftragsnummer vorkommt, kommt dieselbe Kundennummer vor.

So kann funktionale Abhängigkeit also auch gesehen werden und manchen leuchtet diese Interpretation leichter ein als die obige. Beide Interpretationen ("schließen auf" bzw. "genau eines") sind aber gleichwertig. Einmal hilft bei der praktischen Modellierungsarbeit die eine, manchmal die andere.

Zwei Interpretationen

Basis der funktionalen Abhängigkeit

Das obige Beispiel macht auch deutlich, was die Voraussetzung für das Erkennen funktionaler Abhängigkeiten ist: das Wissen, das der Nutzer über den Anwendungsbereich und seine konkreten Objekte hat. Ohne dieses Wissen können die Relationen und dann das gesamte Datenmodell nicht konstruiert werden und dieses Wissen legt auch die funktionalen Abhängigkeiten fest.

Funktionale Abhängigkeit drückt Zusammengehörigkeit aus. Sie geht davon aus, dass es eine identifizierende Information gibt (bestehend aus einem Attribut oder mehreren), die jedes Tupel (d.h. Objekt oder Beziehung) identifiziert und weitere Attribute, die genau dieses Objekt oder diese Beziehung näher beschreiben.

Grundkonzept

In der relationalen Theorie wird dann noch zusätzlich verlangt, dass von den beschreibenden Attributen jeweils genau eine Ausprägung Gültigkeit hat.

Funktionale Abhängigkeiten einer Relation können auch grafisch dargestellt werden, durch ein sog. Diagramm der funktionalen Abhängigkeiten (FA-Diagramm). In ihm werden die Attribute durch Rechtecke repräsentiert und die funktionalen Abhängigkeiten durch Pfeile. Das folgende FA-Diagramm (in der US-amerikanischen Literatur FD-Diagram, wegen: functional dependency) zeigt die funktionalen Abhängigkeiten der obigen Relation Aufträge_1NF.

Abbildung 8.2-1: FA-Diagramm der Relation Aufträge

Anmerkung: Jeder Pfeil repräsentiert eine volle funktionale Abhängigkeit.

Erläuterung

Für jedes Attribut wird ein Rechteck angelegt. Handelt es sich um einen Schlüssel, wird die Raute vorangesetzt:

Aufbau von FA-Diagrammen

Besteht ein Schlüssel aus zwei oder mehr Attributen, wird um diese ein weiteres Rechteck gezeichnet:

Die Pfeillinien zwischen den Attributen bedeuten jeweils eine funktionale Abhängigkeit. D.h. von dem Attribut am Pfeilanfang kann auf das Attribut an der Pfeilspitze geschlossen werden. So wie hier von der Kundennummer auf den Namen des Kunden:

Ob es sich um eine volle oder einfache funktionale Abhängigkeit handelt, geht aus dem FA-Diagramm hervor. Das für das Erkennen notwendige Instrumentarium wird in den nächsten Abschnitten vorgestellt. Ganz grundsätzlich gilt im übrigen, dass alle Attribute einer Relation in irgendeiner Form mit anderen verbunden sein müssen.

Idealstrukturen

Die Bedeutung der funktionalen Abhängigkeiten liegt auch darin, dass man die Anforderung an korrekte und redundanzfreie Relationen grafisch darstellen kann. Dadurch wird jede Abweichung sofort in der Abbildung sichtbar.

Strukturierungshinweis durch funktionale Abhängigkeiten

Korrekt und redundanzfrei sind Relationen, wenn sie einen Schlüssel haben (oder auch mehrere konkurrierende) und wenn alle anderen Attribute vom Schlüssel voll funktional abhängig sind. Die folgenden Abbildungen zeigen solche - abstrahierten - Idealstrukturen am Beispiel von vier Attributen [Anmerkung] und einem Schlüssel (mit einem Attribut bzw. mit zweien).

Abbildung 8.2-2: Idealstruktur 1 - Relation ohne Redundanz und Anomalien

Abbildung 8.2-3: Idealstruktur 2 - Relation ohne Redundanz und Anomalien mit zusammengesetztem Schlüssel

Anmerkung: Das Rechteck um die beiden Schlüsselattribute kennzeichnet diese als Schlüssel.

Ziel der Normalisierung

Liegen nun von dieser Idealstruktur abweichende funktionale Abhängigkeiten vor, sind sie in der Abbildung sofort erkennbar und können beseitigt werden. Im Rahmen der weiteren Normalisierungsschritte geht es nun darum, für jede Relation - ohne Informationsverlust - eine solche Idealstruktur zu erreichen.

Determinanten

Bevor wir dies vertiefen, soll noch ein weiterer Begriff eingeführt werden: Determinante. Jedes Attribut, von dem andere funktional abhängig sind, wird Determinante genannt. Determinanten können auch aus mehreren Attributen bestehen, wie im obigen Beispiel: Hier sind AuftrNr und PosNr zusammen Determinante für ProdNr und weitere Attribute. Natürlich sind alle Schlüssel auch Determinanten. Damit liegen insgesamt folgende "Rollen" von Attributen in Relationen vor:

Schlüssel

Teil eines zusammengestzten Schlüssels, diese werden Schlüsselattribute(SA) genannt

Attribute, die nicht Teil eines Schlüssels sind, diese werden Nichtschlüsselattribute(NSA) genannt

Determinanten

Der Weg zur oben angedeuteten "Idealstruktur" kann dann auch so beschrieben werden, dass durch sie jeweils eine Determinante und die von ihr funktional abhängigen Attribute zu einer Relation werden, wobei die Determinante dann Schlüssel wird.

Zur Veranschaulichung hier eine Abbildung, die im FA-Diagramm der Relation Aufträge_1NF die Determinanten (D), die Schlüsselattribute (SA) und die Nichtschlüsselattribute (NSA) markiert.

Abbildung 8.2-4: Schlüsselattribute (SA), Nichtschlüsselattribute (NSA) und Determinanten (D) in Aufträge_1NF

Jetzt wird deutlich, dass die oben angesprochenen Strukturdefizite zwei Ursachen haben:

1) Die Tatsache, dass einzelne Schlüsselattribute Determinanten sind.

Dies führt immer zu Redundanz, die Beseitigung dieses Defizits wird zur 2NF führen. Der Grund ist folgender: Die Ausprägungen eines einzelnen Schlüsselattributs kommen in der Regel jeweils mehrfach vor. Damit kommen auch die Ausprägungen des funktional abhängigen Attributs mehrfach vor. Im obigen Beispiel: AuftrNr hat Ausprägungen, die gleich sind (die eines Auftrags). Für alle diese gleichen Ausprägungen wird die KuNr erfasst. Damit sind die erfassten Daten redundant.

2) Die Tatsache, dass es Determinanten gibt, die Nichtschlüsselattribute sind.

Auch dies erzeugt immer Redundanz, die Beseitigung dieses Defizits führt zur 3NF. Der Grund: Die Ausprägungen von Nichtschlüsselattributen kommen natürlich mehrfach vor und damit auch die Ausprägungen der funktional abhängigen Attribute. Im obigen Beispiel: KuNr hat gleiche Ausprägungen (für die Aufträge von einem Kunden). Damit wird auch der KuName mehrfach erfasst.

8.3 Schneller Weg zum Erfolg

Ein schneller Weg zum Erreichen der Idealstruktur (der höchsten Normalform), der allerdings erst nach einiger Übung leicht fällt, besteht darin, aus jeder Determinante und den von ihr abhängigen Attributen eine eigene Relation zu machen und die dabei entstehenden Relationen dann noch durch Fremdschlüssel zu verknüpfen. Nimmt man die in diesem Beispiel vorliegenden vier Determinanten

Beispiel "Aufträge"
Zerlegung in 4 Relationen

AuftrNr

KuNr

ProdNr bzw. ProdBez

und

(AuftrNr, PosNr)

kann man, sozusagen auf direktem Weg, durch Bildung von vier Relationen zur "Idealstruktur" kommen. Beachtet werden muss lediglich, dass bei der notwendigen Zerlegung die Verknüpfbarkeit erhalten bleibt. Im folgenden sind die dabei entstehenden Relationen in Tabellenform angegeben. Um die Beseitigung der Redundanz deutlich zu machen, wurden die in den neuen Relationen wegfallenden Tupel durchgestrichen stehen gelassen.

Die neuen Relationen sind bereits in der höchsten Normalform, der 5NF.

AuftrKöpfe_5NF

AuftrNr

AuftrDatum

KuNr

0001

30.06.15

1700

~~0001~~

~~30.06.15~~

~~1700~~

~~0001~~

~~30.06.15~~

~~1700~~

0010

01.07.14

1201

~~0010~~

~~01.07.14~~

~~1201~~

0011

02.07.15

1600

~~0011~~

~~02.07.15~~

~~1600~~

~~0011~~

~~02.07.15~~

~~1600~~

~~0011~~

~~02.07.15~~

~~1600~~

0012

04.07.16

1900

...

Schlüssel: #AuftrNr

In obiger Relation wird die KuNr zum Fremdschlüssel. Jetzt wurde nur noch ein einziges Mal erfasst, dass die Auftragsnummer 0001 das Auftragsdatum 30.06.15 hat, usw.

Kunden_5NF

#KuNr

KuName

1700

Müller

1700

Müller

1700

Müller

1201

Sammer

1201

Sammer

...

Dass zur Kundennummer 1700 der Kunde Müller gehört, ist jetzt nur noch einmal in der Datenbank vermerkt.

Produkte_5NF

#ProdNr

#ProdBez

...

9901

Laser Dru x

~~9901~~

~~Laser Dru x~~

9905

Papier abc

9905

Papier abc

~~9905~~

~~Papier abc~~

9906

InkJet-Dru y

9910

Toner xyz

~~9910~~

~~Toner xyz~~

9911

Tintenpatr x

9998

z-Bildschirm

...

Schlüssel: #ProdNr, #ProdBez

Die Tatsache, dass "Papier abc" die Produktnummer 9905 hat, wird jetzt nur noch einmal erfasst.

AuftrPos_5NF

AuftrNr

PosNr

ProdNr

Menge

0001

1

9901

1

0001

2

9910

3

0001

3

9905

5.000

0010

1

9905

30.000

0010

2

9910

1

0011

1

9901

1

0011

2

9911

20

0011

3

9905

5.000

0011

4

9906

2

0012

1

9998

1

...

Schlüssel: #(AuftrNr, PosNr)

Hier müssen keine Zeilen durchgestrichen werden. Dieser Teil der Relation war bereits frei von Redundanz, da hier alle Nichtschlüsselattribute (NSA) voll funktional abhängig sind vom Gesamtschlüssel. ProdNr wird zum Fremdschlüssel, der diese Relation mit der Relation Produkte verknüpft. AuftrNr verknüpft mit AuftrKöpfe.

Somit zeigt sich, dass in der Ausgangsrelation Aufträge_1NF vier verschiedene Aspekte der Realwelt modelliert waren: die Beziehung zwischen Aufträgen und Kunden, die Kunden, Produkte und Auftragspositionen.

Vermischung verschiedener Objekte / Relationen

Bei jeder solchen Neuordnung muss dann noch geprüft werden, ob die Zerlegung nicht zu einem Informationsverlust geführt hat. Dazu muss lediglich überprüft werden, ob die neuen Relationen durch Attribute wieder verknüpft werden können oder ob vielleicht das eine oder andere Attribut als Fremdschlüssel ergänzt werden muss, bzw. ob eine Verbindungsrelation nötig ist. Hier ergaben sich die Fremdschlüssel von selbst, dies ist aber nicht immer so.

Die grafische Darstellung des Datenmodells Aufträge_5NF gibt den Zusammenhang zwischen den Relationen an:

Abbildung 8.3-1: Datenmodell Aufträge

Abschließend noch die textliche Notation dieses Datenmodells:

AuftrKöpfe_5NF (#AuftrNr, AuftrDatum, KuNr)

AuftrPos_5NF (#(AuftrNr, PosNr), ProdNr, Menge)

Kunden_5NF (#KuNr, KuName)

Produkte_5NF (#ProdNr, #ProdBez)

Im Rahmen der Datenbanktheorie wird diese "Idealform" durch zwei Normalisierungsschritte (2NF und 3NF) erreicht, die im Folgenden vorgestellt werden. Bevor wir uns dem zuwenden, muss noch die Unterscheidung von einfacher und voller funktionaler Abhängigkeit eingeführt werden.

8.4 Einfache und volle FA

Alle bisherigen funktionalen Abhängigkeiten waren sogenannte "volle". Zur Einführung der "einfachen" betrachten wir nochmals die ursprüngliche Relation Aufträge_1NF, die den Schlüssel #(AuftrNr, PosNr) hat. Von diesem Schlüssel kann - sonst wäre es kein Schlüssel - auf alle übrigen Attribute geschlossen werden, wenn auch auf unterschiedliche Weise. Die folgende Liste gibt all diese Abhängigkeiten an, die vollen f.A. sind mit => gekennzeichnet:

f.A. = funktionale Abhängigkeit

AuftrNr, PosNr => ProdNr (volle f.A.)

AuftrNr, PosNr => ProdBez (volle f.A.)

AuftrNr, PosNr => Menge (volle f.A.)

AuftrNr, PosNr --> AuftragsDatum (einfache f.A.)

AuftrNr, PosNr --> KuNr (einfache f.A.)

AuftrNr, PosNr --> KuName (einfache f.A.)

Wie zu sehen ist, liegen nun Abhängigkeiten vor, die nicht volle f.A. sind. Dies sind einfache funktionale Abhängigkeiten. Sie werden in den Abbildungen mit einem einfachen Pfeil --> gekennzeichnet.

Bei diesen ist die Determinante "überausgestattet", d.h., sie weist mehr Attribute auf, als für die volle funktionale Abhängigkeit nötig wäre. In den obigen drei Fällen einfacher funktionaler Abhängigkeit würde z.B. das Attribut AuftrNr alleine für eine volle funktionale Abhängigkeit ausreichen. Somit gilt:

Determinante überausgestattet

Eine funktionale Abhängigkeit heißt voll, wenn von der Determinante kein Attribut weggenommen werden kann, ohne dass die funktionale Abhängigkeit verloren geht.

Definition:
Volle und einfache funktionale Abhängigkeit (f.A.)

Sie heißt einfach, wenn die Determinante mehr Attribute enthält, als für die funktionale Abhängigkeit nötig ist.

Im obigen Beispiel gelten darüberhinaus auch noch die sozusagen trivialen einfachen funktionalen Abhängigkeiten von der Determinante auf ihre Teile:

AuftrNr, PosNr --> AuftrNr

AuftrNr, PosNr --> PosNr

Diese sollen allerdings im weiteren nicht betrachtet werden.

Formale Definition: einfach und voll

Nun zu einer formalen Definition der funktionalen Abhängigkeiten. Diese bezieht sich darauf, dass das Vorkommen eines Werts eines Attributs (bzw. einer Attributkombination) AK₁ über alle Tupel hinweg mit dem Vorkommen eines bestimmten Werts eines Attributs (oder einer Attributkombination) AK₂ verbunden sein kann. Die erste Definition beschreibt funktionale Abhängigkeit als solche, noch ohne die Unterscheidung in "volle" oder "einfache".

Seien T die Menge der Attribute einer Relation und AK1, AK2 Teilmengen von T, d.h.

Definition (formal):
funktionale Abhängigkeit (f.A.)

AK1 = {A11, A21, A31, ..., Am1}, AK2 = {A12, A22, A32, ..., An2}.

AK2 ist funktional abhängig von AK1 (in der jeweiligen Relation), in Zeichen: AK1 --> AK2, falls gilt: alle Tupel, die in den AK1-Ausprägungen übereinstimmen, tun dies auch in den AK2-Ausprägungen.

Eine Attributkombination (AK) besteht aus einem oder mehreren Attributen von T, der Menge der Attribute einer Relation. Nachfolgende Definition der vollen funktionalen Abhängigkeit erfasst nun den Tatbestand, dass die Determinante nur die Minimalausstattung an Attributen haben sollte.

Seien AK₁, AK₂ Teilmengen von T. AK₂ heißt voll funktional abhängig von AK₁, in Zeichen: AK₁ => AK_2,falls gilt:

Definition (formal):
volle f.A.

1) AK₁ -->AK₂

und

2) Es gibt keine echte Untermenge AK₁^* von AK₁, so dass gilt:

AK₁^{* -->} AK₁

Ist AK₁ ein einziges Attribut, dann ist AK₁ --> AK₂ gleichbedeutend mit

AK₁ => AK₂

Als einfache funktionale Abhängigkeit soll hier weiterhin eine funktionale Abhängigkeit bezeichnet werden, die keine volle ist.

Hier noch ein weiteres Beispiel, eine Relation, die recht einfach die Mitarbeit von Angestellten in Projekten erfasst. Wie immer soll die Semantik gelten, dass ein Angestellter in mehreren Projekten mitarbeiten kann und ein Projekt mehrere ihm zugewiesene Angestellte hat. In einer Relation

Beispiel Projektmitarbeit

Angestellte (#(PersNr, BezProj), ProgSpr, AntProj)

(mit Personalnummer; Projekt, in dem der/die Angestellte mitarbeitet; Programmiersprachen, die ein Angestellter beherrscht; Anteil der Arbeitszeit, die ein Angestellter für ein Projekt tätig ist) gelten dann folgende funktionalen Abhängigkeiten:

PersNr, BezProj --> ProSpr

PersNr, BezProj => AntProj

PersNr => ProgSpr

Das FA-Diagramm ergibt sich dann wie folgt:

Abbildung 8.4-1: FA-Diagramm der Relation Angestellte

Die funktionale Abhängigkeit des Attributs ProgSpr vom Schlüssel ist nur eine einfache, da als Determinante die PersNr alleine genügen würde.

8.5 Schlüssel (formal)

Weiter oben wurde ein Schlüssel kurz als ein Attribut definiert, das für jedes Objekt (für jedes Tupel) eine andere Ausprägung hat, dessen Ausprägungen, m.a.W., paarweise verschieden sind. Damit gleichbedeutend ist, dass ein Schlüssel die eindeutige Identifikation aller Objekte (Datensätze) erlaubt. Dies kann nun präziser gefasst werden:

Sei AK Teilmenge von T, d.h. AK = {A₁, A₂, ..., A_n}. AK heißt Schlüssel, falls für alle A_m (A_m NICHT enthalten in T) aus der Relation R gilt:

Schlüssel: Definition 4

A₁, A₂, ..., A_n => A_m
und keine echte Untermenge von AK hat diese Eigenschaft.

Damit gilt (mit AK₁ und AK₂ als Attributskombinationen einer Relation):

AK₁ Schlüssel ==> AK₁ => AK₂

D.h., falls AK₁ ein Schlüssel ist, sind alle anderen Attributskombinationen davon voll funktional abhängig.

AK₁, AK₂ Schlüssel ==> AK₁ => AK₂ und AK₂ => AK₁.

Erinnerung:

1. Das Zeichen '==>' meint hier die logische Implikation. Damit bedeutet A ==> B: aus A folgt B.

2. T: Menge der Attribute einer Relation

3. Attributskombination AK: Attribute einer Relation, z.B. die eines zusammengesetzten Schlüssels

Liegen zwei Schlüssel vor, sind diese natürlich gegenseitig voneinander funktional abhängig. Wie oben schon angeführt, werden Attribute, die Teil eines Schlüssels sind, Schlüsselattribute (SA) genannt. Die anderen Nichtschlüsselattribute (NSA).

9 Die zweite Normalform (2NF)

Die zweite Normalform besteht darin, die funktionalen Abhängigkeiten, die von einem Teil des Schlüssels herrühren, zu beseitigen. Nach dessen Beseitigung ist die jeweilige Relation in 2NF und damit redundanzfreier. Ganz abstrakt und auf das Wesentliche reduziert, drückt die folgende Abbildung das Problem bei Relationen aus, die nicht in 3NF sind: Es gibt eine Determinante, die Teil des Schlüssels ist (Schlüsselattribut; SA). Da eine solche Determinante typischerweise mehrere gleiche Ausprägungen hat, wird die davon abhängige Attributsausprägung in C auch mehrfach erfasst. Das Strukturdefizit ist hervorgehoben.

Strukturdefizit: funktionale Abhängigkeit von einem Schlüsselteil

Abbildung 8.5-1: 1NF und nicht 2NF - abstrakt

9.1 Redundanz trotz 1NF

Wo steckt die Redundanz bei einer Relation, die in 1NF und nicht in 2NF ist? Betrachten wir dazu eine Relation zum Vorlesungsbetrieb einer Hochschule:

Redundanzquelle

VorlBetrieb (#(MatrNr, LVNr, DozNr, Tag, Beginn), Name, LVBez)

MatrNr: Matrikelnummer (für Studierende eindeutig)

LVNr: Nummer der Lehrveranstaltung (für Lehrveranstaltungen eindeutig)

DozNr: Personalnummer des Dozenten (für Dozenten eindetuig)

Name: Name des Dozenten

LVBez: Bezeichnung der Lehrveranstaltung

Tag und Beginn identifizieren jeden einzelnen Vorlesungstermin. Es geht also nicht um die Lehrveranstaltungen also solche, sondern um die einzelnen Termine. Der Schlüssel besteht aus zahlreichen Attributen. Jedes Tupel hält fest, dass ...

ein Studierender eine bestimmte Lehrveranstaltung bei einem bestimmten Dozenten an einem Tag mit einem bestimmten Startzeitpunkt ...

besucht. Damit ist ein bestimmter Lehrveranstaltungstermin und sein Besuch durch einen Studierenden eindeutig festgehalten. Es gelten die im FA-Diagramm angegebenen funktionalen Abhängigkeiten. Dies sind beides einfache funktionale Abängigkeiten.

Abbildung 9.1-1: FA-Diagramm zur Relation VorlBetrieb_1NF

Die Redundanz entsteht dadurch, dass für jeden Lehrveranstaltungstermin der Name des Studierenden und die Bezeichnung der Lehrveranstaltung festgehalten wird. Ursache ist, dass Nichtschlüsselattribute (NSA; Name und VBez) funktional abhängig sind von einem Teil des Schlüssels.

Wird dieses Strukturdefizit beseitigt, entstehen die in den folgenden Abbildungen als FA-Diagramme angegebenen redundanzfreien Relationen. Für die Studierenden und Lehrveranstaltungen je eine neue, die alte bleibt erhalten, erhält aber Fremdschlüssel. Alle angegebenen funktionalen Abängigkeiten sind volle. Die Relationen sind alle bereits in der 5NF.

Optimaler Aufbau

Abbildung 9.1-2: FA-Diagramme zu den Relationen Vorlesungsbetrieb (VorlBetrieb_5NF), Studierende (Stud_5NF) und Lehrveranstaltungen (LV_5NF).

9.2 Definition

Damit kann die 2NF wie folgt definiert werden:

Eine Relation ist in zweiter Normalform (2NF), falls jedes Nichtschlüsselattribut voll funktional abhängig ist vom (gesamten) Schlüssel.

Definition: Zweite Normalform (2NF)

Alternativ: ... falls kein (echtes) Schlüsselattribut Determinante für Nichtschlüsselattribute ist.

Somit müssen in einer Relation mit 1NF und ohne 2NF einfache funktionale Abhängigkeiten bestehen. Werden diese beseitigt, beschreibt jedes Attribut dann das Objekt, das durch den Primärschlüssel identifiziert wird und nicht ein anderes, das durch einen Teil des Schlüssels identifiziert wird. Ist diese Bedingung erfüllt, können die oben angeführten Anomalien nicht auftreten.

Was oben gezeigt wurde, gilt grundsätzlich. Relationen in 1NF, die nicht in 2NF sind, können in diese überführt werden. Dies erreicht man dadurch, dass die Attribute der Relation so in verschiedenen Relationen neu angeordnet werden, dass a) obige 2NF-Bedingung erfüllt ist und b) keine Information verloren geht. Etwas konkreter Jedes Schlüsselattribut, das Determinante ist, wird Schlüssel einer neuen Relation. Ihr werden die von diesem Schlüssel funktional abhängigen Attribute zugeordnet. Die Determinante selbst bleibt in der 1NF-Relation, wird aber zum Fremdschlüssel. Im folgenden noch einige Beispiele für diesen Normalisierungsschritt.

Überführung von 1NF nach 2NF.

9.3 Beispiel Aufträge

Betrachten wir nochmals obige Relation Aufträge_1NF. Ein FA-Diagramm zu dieser Relation liegt in Abschnitt 8.2 vor.

Aufträge_1NF

AuftrNr

PosNr

ProdNr

ProdBez

Menge

AuftrDatum

KuNr

KuName

0001

1

9901

Laser Dru x

1

30.06.15

1700

Müller

0001

2

9910

Toner xyz

3

30.06.15

1700

Müller

0001

3

9905

Papier abc

5.000

30.06.15

1700

Müller

0010

1

9905

Papier abc

30.000

01.07.14

1201

Sammer

0010

2

9910

Toner xyz

1

01.07.14

1201

Sammer

0011

1

9901

Laser Dru x

1

02.07.15

1600

Stanzl KG

0011

2

9911

Tintenpatr x

20

02.07.15

1600

Stanzl KG

0011

3

9905

Papier abc

5.000

02.07.15

1600

Stanzl KG

0011

4

9906

InkJet-Dru y

2

02.07.15

1600

Stanzl KG

0012

1

9998

z-Bildschirm

1

04.07.16

1900

Max OHG

...

Schlüssel: #(AuftrNr, PosNr)

Sie soll nun schrittweise und nicht wie oben "auf einen Schlag" in die höheren Normalformen gebracht werden. Sie ist tatsächlich in 1NF und nicht in 2NF, da von dem Schlüsselattribut AuftrNr funktionale Abhängigkeiten ausgehen, dieses also Determinante ist:

Schrittweise normalisieren

AuftrNr => AuftrDatum

AuftrNr => KuNr

AuftrNr => KuName

Damit bestehen auch einfache funktionale Abhängigkeiten, deren Existenz immer ein Hinweis auf einen Verstoß gegen die 2NF ist:

AuftrNr, PosNr --> AuftrDatum

AuftrNr, PosNr --> KuNr

AuftrNr, PosNr --> KuName

Ein solches Defizit ist in den FA-Diagrammen besonders leicht erkennbar. Hier nochmals die Ausgangsrelation in textlicher Notation:

Aufträge_1NF (#(AuftrNr, PosNr), ProdNr, ProdBez, Menge, AuftragsDatum, KuNr, KuName)

Um die 2NF zu erreichen wird das Schlüsselattribut (Determinante) AuftrNr mit allen von ihm funktional abhängigen Attributen in eine neue Relation AuftrKöpfe getan. Diese ist dann in 2NF (weiter noch nicht, vgl. den nächsten Abschnitt).

AuftrKöpfe_2NF

#AuftrNr

AuftrDatum

KuNr

KuName

0001

30.06.15

1700

Müller

~~0001~~

~~30.06.15~~

~~1700~~

~~Müller~~

~~0001~~

~~30.06.15~~

~~1700~~

~~Müller~~

0010

01.07.14

1201

Sammer

~~0010~~

~~01.07.14~~

~~1201~~

~~Sammer~~

0011

02.07.15

1600

Stanzl KG

~~0011~~

~~02.07.15~~

~~1600~~

~~Stanzl KG~~

~~0011~~

~~02.07.15~~

~~1600~~

~~Stanzl KG~~

~~0011~~

~~02.07.15~~

~~1600~~

~~Stanzl KG~~

0012

04.07.16

1900

Max OHG

...

Die durchgestrichenen Tupel sind die jetzt überflüssigen. Für diese Relation gilt: Schlüssel ist AuftrNr, Nichtschlüsselattribute (NSA) sind AuftrDatum, KuNr, KuName

Folgende funktionale Abhängigkeiten bestehen:

AuftrNr => AuftragsDatum

AuftrNr => KuNr

AuftrNr => KuName

KuNr => KuName

Es liegt also eine volle funktionale Abhängigkeit aller Nichtschlüsselattribute vom Schlüssel vor. Die restlichen Attribute von Aufträge_1NF bilden dann eine Relation zu den Auftragspositionen (AuftrPos), in der die einzelnen Auftragspositionen festgelegt sind. Die AuftrNr verbleibt hier ebenfalls und ist nun einfaches Schlüsselattribut und ein Fremdschlüssel.

AuftrPos_2NF

AuftrNr

PosNr

ProdNr

ProdBez

Menge

0001

1

9901

Laser Drucker xyz

1

0001

2

9910

Toner xyz

3

0001

3

9905

Papier abc

5.000

0010

1

9905

Papier abc

30.000

0010

2

9910

Toner xyz

1

0011

1

9901

Laser Drucker xyz

1

0011

2

9911

Tintenpatronen x

20

0011

3

9905

Papier abc

5.000

0011

4

9906

InkJet-Drucker yz

2

0012

1

9998

xyz-Bildschirm

1

...

Für diese Relation gilt: Schlüssel ist #(AuftrNr, PosNr), Schlüsselattribute (SA) sind AuftrNr und PosNr. Außerdem bestehen folgende vollen funktionalen Abhängigkeiten:

AuftrNr, PosNr => ProdNr

AuftrNr, PosNr => Menge

AuftrNr, PosNr => ProdBez

ProdNr => ProdBez

Die Verknüpfung der beiden nun entstandenen Relationen und damit die eventuelle Wiederherstellung der alten "Zusammenhänge" erfolgt über das Attribut AuftrNr, das ja in beiden Relationen vorkommt:

AuftrKöpfe.AuftrNr bzw. AuftrPos.AuftrNr

Erinnerung: dies stellt die in SQL übliche Kennzeichnung für Attribute und ihre Relationen dar.

Damit ergibt sich auch der in AuftrPos angegebene Fremdschlüssel. Die folgende Abbildung zeigt das sich daraus ergebende kleine Datenmodell.

Abbildung 9.3-1: Relationales Datenmodell Aufträge_2NF

Die 2NF ist immer dann von vorneherein erfüllt, falls jeder Schlüssel aus einem einzigen Attribut besteht, denn in diesem Fall ist die funktionale Abhängigkeit immer die volle funktionale Abhängigkeit und da das Attribut Schlüssel ist, sind alle NSA voll von ihm abhängig (nicht aber die anderen Schlüsselattribute).

Faustregel.

Eine Zerlegung einer Relation wie oben gezeigt wird Projektion genannt. Grundsätzlich gilt, dass jede Relation, die in 1NF ist und nicht in 2NF, durch Projektionen immer in 2NF-Relationen zerlegt werden kann. Die Originalrelation kann durch einen sog. Verbund wiederhergestellt werden (ein Verbund zweier Relationen entspricht der oben eingeführten relationalen Verknüpfung zweier Relationen).

Zu Projektion und Verbund vgl. Abschnitt 19.8.

9.4 Beispiel PROJEKTMITARBEIT

Ein weiteres Beispiel: Die Relation Projektmitarbeit (ProjMitarb_1NF) erfasst Informationen zu Angestellten und ihrer Mitwirkung in Projekten:

Projektmitarbeit Variante 1

ProjMitarb_1NF

Name

PersNr

Funktion

FuBeschr

BezProj

Dauer

Zugeh

Budget

Stein

12345

Leiter

...

LCD

24

24

10

Maier

12346

DV

...

LCD

24

18

10

Müller

23456

Leiter

...

786zz

18

18

30

Bach

54321

InfMan

...

786zz

18

10

30

Bach

54321

DV

...

LCD

24

24

10

...

...

Schlüssel: #(PersNr, BezProj)

Die textliche Darstellung:

ProjMitarb_1NF (PersNr, BezProj), Name, Funktion, FuBeschr, Dauer, Zugeh, Budget)

Das folgende FA-Diagramm gibt die vollen funktionalen Abhängigkeiten an.

Abbildung 9.4-1: FA-Diagramm der Relation ProjMitarb_1NF

Es bedeuten:

Funktion: Funktion der Person im Projekt

FuBeschr: Genauere Klärung der Funktion

BezProj: Eindeutiger Name des Projekts

Dauer: Dauer des Projekts in Monaten

Zugeh: Anzahl Monate, die die jeweilige Person dem Projekt angehört

Budget: Budget des Projekts in Millionen Euro

Daneben existieren die folgenden einfachen funktionalen Abhängigkeiten:

PersNr, BezProj --> Name

PersNr, BezProj --> Budget

PersNr, BezProj --> Dauer

Das FA-Diagramm zeigt: Die im Attribut FuBeschr festgehaltene Beschreibung der Funktion ist nicht von den Personen abhängig, die die jeweilige Funktion inne haben, sondern nur von der Funktion selbst.

In welcher Normalform ist diese Relation? Die 1NF ist erfüllt. Ein Verstoß gegen sie wäre im FA-Diagramm nicht erkennbar, weshalb FA-Diagramme nur bei Relationen eingesetzt werden, die in 1NF sind. Die 2NF ist nicht erfüllt, weil die Nichtschlüsselattribute (NSA) Name, Budget und Dauer nicht voll funktional vom Schlüssel abhängig sind.

Exkurs: Anomalien in diesem Beispiel

Einfüge-Anomalie

Wird ein neues Projekt gestartet, so kann es erst eingetragen werden, wenn die erste Person, die im Projekt mitarbeitet, ebenfalls bekannt ist.

Lösche-Anomalie

Angenommen, ein Projekt ist vorübergehend ohne Personal, z.B. weil die Mitarbeiter aus dem Projekt gekündigt haben, neue aber noch nicht bestimmt sind. Dann verschwindet, wenn die Projektzugehörigkeit der letzten Person gelöscht wird, auch die Information über das Projekt.

Aktualisierungsanomalien

Falls die Dauer eines Projekts verändert wird, muss diese Information nicht nur an einer Stelle geändert werden, sondern an mehreren. Gleiches gilt für das Budget. Falls ein Mitarbeiter seinen Namen verändert, z.B. durch Heirat, gilt dasselbe.

Diese Relation wird normalisiert in die drei Relationen [Anmerkung]

ProjMitarb_2NF (PersNr, BezProj), Funktion, FuBeschr, Zugeh)

Projekte_5NF (#BezProj, Budget, Dauer)

und

Ang_5NF (#PersNr, Name).

Die tabellarische Darstellung:

ProjMitarb_1NF

PersNr

Funktion

FuBeschr

BezProj

Zugeh

12345

Leiter

...

LCD

24

12346

DV

...

LCD

18

23456

Leiter

...

786zz

18

54321

InfMan

...

786zz

10

54321

DV

...

LCD

24

...

...

Schlüssel: #(PersNr, BezProj)

Projekte_5NF

#BezProj

Dauer

Budget

LCD

24

10

~~LCD~~

24

10

786zz

18

30

~~786zz~~

18

30

~~LCD~~

24

10

Ang_5NF

Name

#PersNr

Stein

12345

Maier

12346

Müller

23456

Bach

54321

~~Bach~~

~~54321~~

...

Schlüssel: #(PersNr, BezProj)

Die durchgestrichenen Zeilen sind jetzt, gegenüber der Ausgangsrelation, überflüssig. Hier noch die FA-Diagramme der neuen Relationen:

Abbildung 9.4-2: FA-Diagramme der Relationen ProjMitarb, Projekte und Ang(estellte)

Abschließend das Datenmodell:

Abbildung 9.4-3: Relationales Datenmodell ProjMitarb

9.5 Zerlegung und Zusammengehörigkeit

Der Normalisierungsschritt von der 1NF zur 2NF ist immer mit einer Zerlegung der Relation verbunden. Immer wird die "störende" Determinante, die Teil des Schlüssels ist, mit den von ihr abhängigen Attributen herausgenommen und zu einer neuen Relation gemacht.

Keine Informationsverluste durch Zerlegungen

Auch die weiteren Normalisierungsschritte führen meist zu Zerlegungen. Für alle diese Zerlegungen sind zwei Regeln zu beachten:

Die Zerlegung darf zu keinem Informationsverlust führen. Dies wird i.d.R. durch entsprechende Schlüssel/Fremdschlüssel realisiert.

Kommt es vor, dass eine neu entstehende Relation eine Objekt- oder Beziehungsklasse beschreibt, die bereits in einer anderen Relation angelegt ist, dann werden die beiden Relationen zusammengeführt. Denn es gilt: Für eine bestimmte Objekt- oder Beziehungsklasse darf nur eine Relation existieren. Dafür gibt es nur wenige Ausnahmen, z.B. bei der Generalisierung / Spezialisierung (vgl. Abschnitt 14.1).

Identisch sind zwei Relationen in diesem Sinne, wenn sie denselben Schlüssel haben.

10 Die dritte Normalform (3NF)

10.1 Redundanz trotz 2NF

Ganz abstrakt und auf das Wesentliche reduziert, drückt die folgende Abbildung das Problem bei Relationen aus, die nicht in 3NF sind: Es gibt eine Determinante, die nicht Schlüssel und nicht Schlüsselattribut ist (im ersten Beispiel D, im zweiten B). Da eine solche Determinante typischerweise mehrere gleiche Ausprägungen hat, wird die davon abhängige Attributsausprägung in C mehrfach erfasst.

Redundanz durch "NSA-Determinanten"

Abbildung 10.1-1: 2NF und nicht 3NF - abstrakt

Solche "fortgesetzten" funktionalen Abhängigkeiten werden transitive genannt (vgl. unten). Relationen mit einem solchen Strukturmerkmal werden wie folgt normalisiert:

Transitive Abhängigkeit

Die Determinante, die nicht Schlüsselattribut ist, bildet zusammen mit dem von ihr abhängigen Attribut eine neue Relation. In der Ursprungsrelation muss diese Determinante (die nach der Normalisierung keine mehr ist) ebenfalls stehen bleiben. Dort wird sie zum Fremdschlüssel und sichert so den Zusammenhalt zwischen den Daten bzw. verhindert Datenverluste.

Regel -Von der 2NF zue 3NF

Hierzu die obigen Relationen in 3NF:

Abbildung 10.1-2: Relationen in 3NF - abstrakt

10.2 Beispiel Auftragsköpfe

Im vorigen Abschnitt ergab sich bei der Herbeiführung der 2NF u.a. die folgende Relation, die hier um ein Attribut und einige Tupel ergänzt wurde:

AuftrKöpfe (#AuftrNr, AuftrDatum, KuNr, KuName, Ort)

AuftrKöpfe_2NF

#AuftrNr

AuftrDatum

KuNr

KuName

Ort

0001

30.06.15

1700

Müller

München

0010

01.07.14

1201

Sammer

Ravensburg

0011

02.07.15

1600

Stanzl KG

Berlin

0012

04.07.16

1900

Max OHG

Passau

1001

19.05.14

1700

Müller

München

1010

20.03.15

1201

Sammer

Ravensburg

1011

05.09.15

1600

Stanzl KG

Berlin

10112

20.12.14

1900

Max OHG

Passau

...

AuftrNr: Auftragsnummer

AuftrDatum: Datum des Auftrags

KuNr: Kundennummer

KuName: Kundenname

Sie hält Informationen zu Aufträgen fest, genauer zu den Auftragsköpfen, und zu den Kunden. Es gelten die folgenden funktionalen Abhängigkeiten:

AuftrNr => AuftrDatum

AuftrNr => KuNr

AuftrNr => KuName

KuNr => KuName

AuftrNr => Ort

KuNr => Ort

Die Relation ist ohne Zweifel in 2NF. Die trotzdem noch vorliegende Redundanz kommt daher, dass dieselbe Kundennummer natürlich sehr oft vorkommen kann und für jedes Vorkommen der Kundennamen und der Wohnort des Kunden erfasst wird. Die Ursache liegt darin, dass ein Nichtschlüsselattribut (NSA), KuNr, Determinante ist und dass es "fortgesetzte" funktionale Abhängigkeiten gibt:

Redundanz

AuftrNr => KuNr => KuName und

AuftrNr => KuNr => Ort

Die Bezeichnung transitive Abhängigkeit, erfolgt in Anlehnung an den entsprechenden Begriff der Mathematik.

transitive Abhängigkeit

Zur Erinnerung (an die Schulalgebra): transitiv bedeutet eine Beziehung über ein anderes Element hinweg. A und B sind in (irgendeiner) transitiven Beziehung (bez), wenn für diese gilt. A bez C bez B.

Sie wird so dargestellt:

AuftrNr --> :: --> KuName

AuftrNr --> :: --> Ort

Um dieses Defizit beseitigen zu können, muss die Relation in zwei Relationen zerlegt werden. Die "NSA-Determinante" zusammen mit dem funktional abhängigen Attribut Ort ergibt die neue Relation Kunden_5NF.

Kunden_5NF (#KuNr, KuName, Ort)

Die "alte" Relation verliert das Attribut KuName und behält die ursprüngliche Determinante KuNr als Fremdschlüssel.

Aufträge_5NF (#AuftrNr, AuftragsDatum, KuNr)

Die folgende Abbildung zeigt den ganzen Normalisierungsschritt einschließlich des dabei entstehenden kleinen Modellfragments.

Abbildung 10.2-1: Von 2NF zu 3NF - am Beispiel Aufträge / Kunden

KuNr: Kundennummer
KuName: Name des Kunden

10.3 Beispiel Angestellte

Das nächste Beispiel betrifft eine Relation mit Informationen zu Angestellten. Im Rahmen eines Modellierungsvorhabens habe sich folgende Relation ergeben:

Angestellte (#PersNr, Abteilung, AbtLeiter, Name, VName, Alter, Wohnort, Straße)

Mit der Festlegung, dass hier nur der Hauptwohnsitz erfasst wird, dass also jede/r nur eine Adresse hat, gelten folgende funktionalen Abhängigkeiten:

PersNr => Name

PersNr => VName

PersNr => Abteilung

PersNr => AbtLeiter

PersNr => Alter

PersNr => Wohnort

PersNr => Straße

Somit gilt:

PersNr => Abteilung => AbtLeiter

und damit die folgende transitive Abhängigkeit:

PersNr --->::---> AbtLeiter

Die Redundanz liegt hier in der Mehrfacherfassung des Zusammenhangs

Abteilung => AbtLeiter

Bei jedem Eintrag einer Abteilung wird auch der Abteilungsleiter eingetragen. Das folgende FA-Diagramm mit den vollen funktionalen Abhängigkeiten macht dieses Strukturmerkmal deutlich. Die störende funktionale Abhängigkeit ist hervorgehoben.

Störend: NSA als Determinante.

Abbildung 10.3-1: FA-Diagramm der Relation Angestellte_2NF

Die Beseitung erfolgt auf die oben vorgestellte Weise: Die Determinante (hier Abteilung) wird zum Schlüssel einer neuen Relation (Abteilungen), in die auch die von ihr abhängigen Attribute kommen.

Abbildung 10.3-2: FA-Diagramm der Relation Abteilungen_3NF

Sie bleibt aber auch in der "alten" Relation zurück - als Fremdschlüssel.

Abbildung 10.3-3: FA-Diagramm der Relation Angestellte_3NF

10.4 Beispiel Aufträge / Artikel / Kunden

Zum Abschluss dieses Abschnitts nun noch ein größeres Beispiel für den Weg von der 1NF zur 3NF. Im Rahmen eines Modellierungsvorhabens habe sich folgende Relation ergeben:

Von 1NF zu 3NF

Aufträge_1NF (#(AuftrNr, PosNr), Menge, AuftrDatum, KuNr, KuName, ArtNr, ArtBez, Preis)

Wenn man sie betrachtet und dies vielleicht auch mit einem FA-Diagramm (vgl. die nächste Abbildung) erkennt man, dass gleich mehrere Strukturdefizite vorliegen:

Die funktionalen Abhängigkeiten von AuftrNr signalisieren den Verstoß gegen die 2NF und die daraus folgenden Redundanzen. Die transitiven Abhängigkeiten von KuNr und ArtNr zeigen zwei Verstöße gegen die 3NF, was ebenfalls zu Redundanzen führt.

Man erkennt diese Defizite entweder gleich im FA-Diagramm oder bei der Betrachtung der einfachen und vollen funktionalen sowie der transitiven Abängigkeiten:

AuftrNr, PosNr => ArtNr //in Ordnung

AuftrNr, PosNr => Menge //in Ordnung

AuftrNr, PosNr --> AuftrDatum //einfache funktionale Abhängigkeit: 2NF?

AuftrNr, PosNr --> KuNr //einfache funktionale Abhängigkeit: 2NF?

AuftrNr, PosNr --> KuName //einfache funktionale Abhängigkeit: 2NF?

AuftrNr, PosNr -->::--> ArtBez //transitive Abhängigkeit: 3NF?

AuftrNr, PosNr -->::--> Preis //transitive Abhängigkeit: 3NF?

AuftrNr => AuftrDatum

AuftrNr => KuNr

AuftrNr => KuName

KuNr => KuName //NSA als Determinante: 3NF?

ArtNr => ArtBez //NSA als Determinante: 3NF?

ArtNr => Preis //NSA als Determinante: 3NF?

Die Herbeiführung der 3NF erfolgt wie oben beschrieben. Für den Schlüssel der Ausgangsrelation und für jede Determinante, die nicht Schlüssel ist, wird eine eigene Relation angelegt und die Determinanten werden zu Schlüsseln:

Normalisierung zur 3NF

#(AuftrNr, PosNr) //Schlüssel der Relation Auftragsköpfe

#AuftrNr //Schlüssel der Relation Aufträge

#KuNr //Schlüssel der Relation Kunden

#ArtNr //Schlüssel der Relation Artikel

An diese Schlüssel werden die voll funktional abhängigen Attribute angehängt:

#(AuftrNr, PosNr), ArtNr, Menge

#AuftrNr, AuftrDatum, KuNr

#KuNr, KuName

#ArtNr, ArtBez, Preis

Danach werden die früheren Determinanten zu Fremdschlüsseln:

#(AuftrNr, PosNr), ArtNr, Menge

#AuftrNr, AuftrDatum, KuNr

#KuNr, KuName

#ArtNr, ArtBez, Preis

Mit den Relationenbezeichnungen liegt dann die Lösung vor. Vgl. die Abbildung. Alle Relationen sind auch bereits in 5NF, wie in der Abbildung angegeben.

Abbildung 10.4-1: Von 1NF zu 3NF - am Beispiel Aufträge / Artikel / Kunden

Die nächste Abbildung zeigt die grafische Darstellung des Datenmodells. Hier wird insbesondere die durch die Zerlegung entstandene Notwendigkeit deutlich, für Auswertungen die Relationen zu verknüpfen.

Das ist sozusagen der Preis, den man für die redundanzfreien Datenbestände zahlen muss. Die Abbildung zeigt im unteren Teil auch die FA-Diagramme aller entstandenen Relationen. Alle sind in der 5NF und weisen auch darüberhinaus keine Defizite auf.

Abbildung 10.4-2: Relationales Datenmodell und FA-Diagramme zum Beispiel Aufträge / Artikel / Kunden

10.5 Definition 3NF

Hier nun die formale Fassung der oben eingeführten Definitionen. Zuerst die der transitiven Abhängigkeit:

A, B und C seien Attribute einer Relation R. C heißt transitiv abhängig von A, in Zeichen:

Definition: transitive Abhängigkeit

A --->::---> C,

falls es ein Attribut B aus R gibt mit dem gilt:

A => B => C (für A <> B <> C)

Entsprechendes gilt für Attributkombinationen, wenn also für A, B oder C mehrere Attribute stehen. Liegen solche Strukturen nicht vor oder wurden sie beseitigt, ist eine Relation in dritter Normalform:

Eine Relation ist in dritter Normalform (3NF), falls sie in 2NF ist und falls keine transitiven Abhängigkeiten zwischen dem Schlüssel und Nichtschlüsselattributen (NSA) bestehen (alternativ: ... falls kein NSA Determinante ist).

Definition: 3NF

Somit gilt:

in einer 3NF-Relation ist kein Nichtschlüsselattribut (NSA) transitiv von einem Schlüssel abhängig, d.h. jedes NSA beinhaltet eine Eigenschaft, die dem zugrundeliegenden Objekt als Ganzes zukommt.

Eine Relation ist genau dann in 3NF, wenn alle NSA gegenseitig unabhängig und voll abhängig vom Schlüssel sind.

"A relation R is in third normal form (3NF) if and only if, for all time, each tuple of R consists of a primary key value that identifies some entity, together with a set of zero or more mutually independent attribute values that describe the entity in some way" [Date 1990, S. 367].

Damit ist dann der Bezug auf ein Objekt im relationalen Sinn voll hergestellt. Im FA-Diagramm äußert sich dies so, dass Pfeile nur vom Schlüssel ausgehen, so wie oben als Idealstrukturen gezeigt.

Relationale Objekt- und Beziehungsklasse

Ganz zu Beginn des Kapitels, bei der Einführung des Relationenbegriffs, wurde als ein Modellierungsschritt genannt, dass jede Objektklasse und jede Beziehungsklasse in genau eine Relation "eingefüllt" wird. Ist dies geschehen, entsprechen sich (Objekt-/Beziehungs-)Klasse und Relation noch sehr genau.

Objektklasse vs. Relation I

Wird dann die 1NF herbeigeführt sind u.U. Attribute mit Mehrfacheinträgen weggenommen und in eigene Relationen getan worden. Die Übereinstimmung von (Objekt-/Beziehungs-)Klasse und Relation ist nicht mehr voll gegeben. Die Klasse wird durch zwei oder drei Relationen beschrieben.

Objektklasse vs. Relation II

Genauso bei der Herbeiführung der 2NF und 3NF. Die Attribute der (Objekt-/Beziehungs-)Klasse werden, falls nötig, auf verschiedene Relationen verteilt, diesmal aber, weil in der Ausgangsrelation verschiedene Objekt-/Beziehungsklassen zusammen beschrieben wurden.

Objektklasse vs. Relation III

Insgesamt gilt, dass die ursprüngliche Beschreibung der (Objekt-/Beziehungs-)Klasse sich nach den Normalisierungsschritten nicht mehr in einer Relation, sondern in mehreren (unter Umständen zahlreichen) befindet.

Normalisierung durch Zerlegung

Soweit die Betrachtung der ersten drei Normalformen. Dies sind gleichzeitig auch die wichtigsten, zumindest für die Praxis der Datenhaltung. Wie zu erkennen ist bedeutet Normalisierung, dass Relationen in eine höhere Normalform gebracht werden und dass dies meist durch Zerlegung geschieht. Diese Zerlegung sollte aber gewissen Regeln genügen. Die wichtigsten seien hier nochmals zusammengefasst:

Es darf keine Information verloren gehen. D.h., es muss durch entsprechende Schlüssel/Fremdschlüssel-Anordnung erreicht werden, dass die zerlegten Relationen gegebenenfalls wieder verknüpft werden können.

Es darf durch die Zerlegung in keinem Bereich des Datenmodells ein Rückschritt bezüglich der Normalformen erfolgen.

Nach jeder Zerlegung ist zu prüfen, ob die neu entstandenen Relationen nicht mit anderen, schon bestehenden, verschmolzen werden können. Grundsätzlich gilt, dass für eine relationale Objekt- oder Beziehungsklasse immer nur eine Relation vorhanden sein darf.

11 Die Boyce-Codd - Normalform (BCNF)

11.1 Redundanz trotz 3NF

Schlüssel, die aus zwei oder mehr Attributen bestehen, kamen oben schon vor. Sie bedeuten immer, dass jedes der Attribute (z.B. PersNr und BezProj) einen Aspekt des erfassten Realweltphänomens (z.B. Projektmitarbei) identifizierend beschreibt und dass sie zusammen das Realweltphänomen selbst beschreiben ("wer in welchem Projekt").

Es kommt nun vor, wenn auch nicht oft, dass eine Relation überlappende Schlüssel hat. Dann besteht jeder Schlüssel aus mindestens zwei Attributen (z.B. #(A,B) und #(B,C)), die mindestens ein Attribut gemeinsam haben (hier B). Die folgende Abbildung zeigt, wie diese Situation in einem FA-Diagramm ausgedrückt wird.

Abbildung 11.1-1: Redundanzen in der 3. Normalform - 3NF und nicht BCNF

So weit so gut. Wenn dies von den Notwendigkeiten des Anwendungsbereichs gefordert ist, muss man so modellieren. Redundanzen entstehen, wenn es funktionale Abängigkeiten zwischen den Schlüsseln gibt, wenn also z.B. ein Attribut des einen Schlüssels von einem des anderen funktional abhängig ist. Dies ist dann auch umgekehrt der Fall, da beide ja als Schlüsselbestandteil für einen Teilaspekt des beschriebenen Phänomens identifizierenden Charakter haben. Die folgende Abbildung zeigt eine solche Situation.

Vgl. zum besseren Verständnis die praktischen Beispiele unten.

Redundanz, weil identifizierende Schlüsselattribute doppelt vorhanden sind.

Abbildung 11.1-2: Redundanzen in der 3. Normalform – F.A. zwischen Schlüsselattributen

Für jede Ausprägung von A gibt es eine entsprechende von C. Da in A eine bestimmte Ausprägung mehrfach vorkommt (Schlüsselbestandteil), kommt die zugehörige in B auch mehrfach vor. Diese Beziehung muss auch umgekehrt gelten, weil A und B in einer solchen Anordnung Schlüsselcharakter für Teilaspekte haben müssen. Diese Redundanz wird noch vergrößert, wenn Nichtschlüsselattribute (NSA) hinzukommen. Die folgende Abbildung zeigt dies am Beispiel eines einzelnen NSAs.

Abbildung 11.1-3: 3NF und nicht BCNF - abstrakt

Bei einer solchen Schlüsselkonstellation ist jedes NSA von zwei Schlüsseln abhängig. Für jedes mehrfache Auftreten einer Attributsausprägung in A bzw. C liegen auch mehrfache Einträge in D vor. Auch dies ist redundant, wenn auch von den bisherigen Schritten der Normalisierungstheorie nicht bedacht.

Erinnerung: NSA = Nichtschlüsselattribut

Trotz dieser Defizite ist eine solche Relation in 2NF, denn es gibt keine funktionalen Abhängigkeiten von einem Schlüsselattribut zu einem NSA und auch in 3NF, da kein NSA Determinante ist.

2NF und 3NF erfüllt

Die Lösung besteht darin, den Zusammenhang zwischen den beiden Attributen, der durch die gegenseitigen funktionalen Abängigkeiten ausgedrückt wird, in eine eigene Relation auszulagern. In unserem abstrakten Beispiel entsteht dadurch die Relation A-C. Da kommt jede Ausprägung des einen und des anderen Attributs nur einmal vor, der Zusammenhang wird nur einmal festgehalten.

Die Semantik, die sich durch die funktionale Abhängigkeit zum NSA ausdrückte, wird durch eine neue Relation mit einem der "alten" zusammengesetzten Schlüssel (egal mit welchem) und dem NSA festgehalten. Im Beispiel entsteht dabei die Relation A-B. Das Attribut, das aus dem zusammengesetzten Schlüssel auch in der anderen Relation vorkommt, wird dort zum Fremdschlüssel und erlaubt damit die Verknüpfung mit der anderen entstehenden Relation.

Endlich die BCNF

Abbildung 11.1-4: Relationen A-C und A-B in BCNF – als FA-Diagramme

Diese neuen Relationen sind dann in der Boyce-Codd - Normalform (BCNF), benannt nach ihren Entdeckern. Auch sie dient dem Zweck der Optimierung der relationalen Struktur, d.h. der optimierten Anordnung der Attribute in flachen Tabellen.

Mit ihr werden Defizite beseitigt, die in Bezug auf die Coddsche dritte Normalform im Laufe der Jahre entdeckt wurden. Konkret waren dies Schwierigkeiten die auftreten, falls eine Relation mehrere zusammengesetzte (aus mehreren Attributen bestehende) und sich überlappende Schlüssel hat und zwischen einzelnen Schlüsselattributen funktionale Abhängigkeiten bestehen. Denn die 3NF verlangt nicht die volle funktionale Abhängigkeit eines Attributs vom Primärschlüssel, falls es selbst Attribut eines Schlüssels ist.

11.2 Beispiel Projektmitarbeit

Betrachten wir als Beispiel die folgende Relation zu Projektmitarbeit (ProjMitarb).

ProjMitarb

AngName

PersNr

Funktion

BezProj

Zugeh

Stein

12345

Leiter

BPR

24

Maier

12346

DV

BPR

18

Müller

23456

Leiter

ITIL

18

Bach

54321

InfMan

ERP-Einf

10

Bach

54321

DV

Portal

24

Bach

54321

InfMan

SDK

6

...

SA

SA

NSA

SA

NSA

Schlüssel: #(AngName, BezProj) oder #(PersNr, BezProj)

Primärschlüssel sei #(AngName, ProjName)

SA: Schlüsselattribut, NSA: Nichtschlüsselattribut

Es gelte folgende Semantik:

Das Attribut AngName sei eindeutig(!). Es kann sich also nur um ein kleines Unternehmen handeln.

Die Funktion beschreibt die Stellung der Angestellten (Leiter: Projektleiter, InfMan: Informationsmanager, DV: DV-Spezialist). Angestellte können in verschiedenen Projekten unterschiedliche Funktionen haben.

BezProj ist die (eindeutige) Bezeichnung des Projekts (z.B. BPR: Business Process Reengineering)

Zugeh erfasst die Dauer der Projektzugehörigkeit in Monaten.

Die textliche Notation:

ProjMitarb (#(AngName, (BezProj), PersNr), Funktion Zugeh) //überlappender Schlüssel

Zwischen den Attributen bestehen folgende vollen funktionalen Abhängigkeiten:

(AngName, BezProj) => Funktion

(AngName, BezProj) => Zugeh

(PersonalNr, BezProj) => Funktion

(PersonalNr, BezProj) => Zugeh

AngName => PersNr

PersNr => AngName

Die folgende Abbildung zeigt im oberen Teil das FA-Diagramm. PersNr und AngName sind gegenseitig funktional abhängig. Die Relation ist in der 3NF, weil die Nichtschlüsselattribute voll funktional abhängig sind vom Schlüssel und weil es zwischen den NSAs keine weiteren vollen funktionalen Abhängigkeiten gibt.

Vermischung

Trotzdem weist diese Relation Redundanzen auf und vermischt Konzepte zweier Realweltphänomene, was zu den schon diskutierten Anomalien führt: Zum einen erfasst sie die Funktion und Projektzugehörigkeit der Personen, zum anderen erfasst sie, welche Personalnummer die Personen haben. Das Problem liegt hier also darin, dass die 1:1 - Beziehung zwischen den beiden Schlüsselattributen AngName und PersNr mehrfach erfasst wird. Z.B. dass Bach die Personalnummer 54321 hat.

Diese Redundanz wird von der 3NF nicht beseitigt, da dort funktionale Abhängigkeiten zwischen Schlüsselattributen nicht betrachtet werden. Die Anomalien hier im einzelnen:

Einfüge-Anomalie: Dörrer wird neu eingestellt und erhält eine Personalnummer. Sie ist allerdings noch keinem Projekt zugeordnet. Ihre Daten können nicht erfasst werden (wegen der Forderung der Objektintegrität), da zum Schlüssel ja auch ein Projekt gehört.

Lösche-Anomalie: Stein verlässt das Projekt "LCD", sein Datensatz wird gelöscht. Damit verschwindet auch die Information, welche Personalnummer er hat.

Aktualisierungs-Anomalie: Bach erhält eine neue Personalnummer. Um diese Information in die Datenbank einzutragen, muss für jeden Eintrag "Bach/54321" die Änderung vorgenommen werden. Es wird also gegen die Regel verstoßen, dass jede in der Datenbank gespeicherte Information nur an einer Stelle stehen sollte.

Wieder besteht die Lösung in der Zerlegung der Relation. Zum einen in eine Relation ProjMitarb, zum anderen in eine Relation Angestellte (vgl. die Abbildung), die natürlich mit einer entsprechenden evtl. schon existierenden verschmelzen würde.

Lösung durch Zerlegung

Abbildung 11.2-1: Von 3NF zu BCNF - am Beispiel Projektmitarbeit

Die Abbildung enthält im unteren Teil auch die FA-Diagramme der neuen Relation. Diese machen nochmals deutlich, dass die erreichte Normalform optimal (redundanzfrei) ist. Endgültig klärt dies wohl die tabellarische Darstellung. Die in den neuen Relationen überflüssigen Tupel wurden zur Verdeutlichung durchgestrichen stehen gelassen.

Angestellte_5NF

#AngName

#PersNr

Stein

12345

Maier

12346

Müller

23456

Bach

54321

~~Bach~~

~~54321~~

~~Bach~~

~~54321~~

...

SA

SA

Schlüssel: #AngName oder #(PersNr, BezProj)

Primärschlüssel sei #(AngName, ProjName)

ProjMitarb

PersNr

Funktion

BezProj

Zugeh

12345

Leiter

BPR

24

12346

DV

BPR

18

23456

Leiter

ITIL

18

54321

InfMan

ERP-Einf

10

54321

DV

Portal

24

54321

InfMan

SDK

6

…

SA

NSA

SA

NSA

Schlüssel: #(AngName, BezProj) und #(PersNr, BezProj)

11.3 Definition BCNF

Relationen, die in der 3NF sind und kein oben beschriebenes Strukturdefizit aufweisen, befinden sich in der Boyce-Codd-Normalform (BCNF). Diese kann wie folgt definiert werden:

Eine Relation ist in Boyce/Codd-Normalform (BCNF), falls jede Determinante Schlüssel ist (Primär- oder Sekundärschlüssel).

Definition: BCNF

Diese Definition umfasst auch die 2NF und die 3NF. Sie geht weiter, als die der 3NF, wo ja nur verhindert wird, dass ein NSA zur Determinante wird. Hier wird auch verhindert, dass ein SA, das nicht selbst Schlüssel ist, Determinante wird. Mit anderen Worten: Nimmt man diese Definition als Grundlage der Modellierungsbemühungen sind alle Normalformen einschließlich der BCNF realisiert.

11.4 Noch ein Beispiel

Im folgenden Beispiel (nach [Date 1990, S. 546]) gilt folgende zugegeben etwas konstruierte Semantik:

Relation Vorlesungen

Ein bestimmtes Fach hört jeder Student / jede Studentin (Stud) nur bei einem Dozenten (Doz)

Jeder Dozent an dieser Hochschule lehrt nur ein Fach, aber jedes Fach wird von mehreren Dozenten gegeben.

VORLESUNGEN

Stud

Fach

Doz

Schmidt

DBS

Steiner

Schmidt

IT-Management

Grauer

Müller

DBS

Steiner

Müller

IT-Management

Grauer

Johnson

No-SQL-DB

Wagner

SA

SA

SA

[SA: Schlüsselattribut]

Schlüssel: #(Stud, Fach)

Aus der ersten obigen Semantikfestlegung ergibt sich:

(Stud, Fach) => Doz

Aus der zweiten Semantikfestlegung folgt

Doz => Fach

Damit gibt es einen zweiten Schlüssel: #(Doz, Stud). All dies führt zu folgendem FA-Diagramm:

Abbildung 11.4-1: FA-Diagramm der Relation VORLESUNGEN

Beide (zusammengesetzten) Schlüssel sind durch entsprechende Rechtecke gekennzeichnet. Die beiden Schlüssel überlappen sich.

In welcher Normalform befindet sich diese Relation? Die 2NF ist erfüllt, da es keine Nichtschlüsselattribute gibt, ebenso die 3NF. Überprüfen wir die BCNF. Diese verlangt, dass jede Determinante Schlüssel ist, was hier offensichtlich nicht der Fall ist. Bevor wir diese Relation normalisieren, suchen wir die Anomalien. Diese sind darin begründet, dass der Zusammenhang Dozent - Fach ("jeder Dozent lehrt nur ein Fach") mehrfach erfasst wird, was bereits bei den wenigen Tupeln der obigen Tabelle sichtbar wird. Im einzelnen:

2NF erfüllt
3NF erfüllt
BCNF nicht erfüllt

Ändert der Dozent Steiner den Namen seines Fachgebietes zu Computergestützte Informationssysteme ist diese Änderung mehrfach zu vollziehen, so oft, wie die Anzahl der Studierenden ist, die das Fach belegt haben.

Aktualisierungs-Anomalie

Ein neuer Dozent gibt das Fach Geschäftsprozessoptimierung. Er kann erst eingetragen werden, wenn sich der erste Studierende für sein Fach entschieden hat, da erst dann ein Eintrag möglich ist, bei dem der Schlüssel vollständig ist (Forderung nach Objektintegrität)

Einfüge-Anomalie

Verlässt der Studierende Müller den Kurs Netzwerkdatenbanken des Dozenten Wagner, geht auch die Information verloren, dass Wagner dieses Fach lehrt. Wie immer deutet die Löscheanomalie damit an, dass "verschiedene Dinge" in eine Relation gepackt wurden. Hier ist es zum einen der Vorlesungsbesuch der Studierenden, zum andern die Dozententätigkeit.

Lösche-Anomalie

Die Normalisierung - gemäß den Forderungen der BCNF - führt zu folgendem Ergebnis:

Abbildung 11.4-2: FA-Diagramme der Relationen zu Vorlesungen in BCNF (und 5NF)

Die Relation StudDoz hält fest, welcher Studierende bei welchem Dozent einen Kurs besucht. Die untere, welches Fach ein Dozent lehrt. Wäre in der ersten Relation statt "Dozent" das Attribut Fach genommen worden, wäre die Relation zwar korrekt, was den Zusammenhang Studierende - Fach angeht, es wäre aber keine Verknüpfung mit der anderen Relation möglich gewesen. Insofern wäre gegen die Regel, dass eine Zerlegung ohne Informationsverlust zu erfolgen hat, verstoßen worden und die Lösung wäre falsch. Die folgende Abbildung zeigt das Datenmodell, es soll StudDoz genannt werden.

Relationales Datenmodell StudDoz

Abbildung 11.4-3: Relationales Datenmodell StudDoz

12 Die vierte Normalform (4NF)

12.1 Das Defizit

Obwohl die BCNF zu weitgehend redundanzfreien Relationen führt, fanden sich im Laufe der Zeit doch Attributkonstellationen, die von ihr nicht erfasst werden. Eine solche wird in der 4NF bearbeitet.

Oft ist zu hören, dass diese Normalform keine Bedeutung in der Praxis hätte. Dies ist nicht ganz richtig. Sie gibt uns zumindest einen Hinweis auf eine mögliche Fehlerquelle gleich zu Beginn der Normalisierung, bei der Behandlung der unnormalisierten Relation. Deshalb soll sie hier auch betrachtet werden.

Der Hintergrund der vierten Normalform kann wie folgt beschrieben werden: Angenommen, es liegt eine unnormalisierte Relation vor, in der drei oder mehr Attribute Mehrfacheinträge aufweisen (d.h., sie sind nicht flach; Einige Autoren verwenden auch den Begriff Wiederholungsgruppen, vom angelsächsischen repeating groups). In einem solchen Fall könnte man auf die Idee kommen, diese Mehrfacheinträge einfach durch Tupelvermehrung gegeneinander aufzulösen. Dabei entsteht aber eine Relation mit Strukturdefiziten, die von den bisherigen Normalformen nicht erfasst werden. Dazu ein Beispiel.

Problemursache: mehrfache Mehrfacheinträge

12.2 Beispiel Vorlesungsbetrieb

Gegeben sei die folgende unnormalisierte Relation, mit der die Beziehungen zwischen Vorlesungen (als solchen, also nicht Vorlesungstermine), den Dozenten und Räumen in einer Tabelle erfasst werden. Es gilt folgende Semantik: Eine Vorlesung kann von mehreren Dozenten gehalten werden und sie kann in mehreren Räumen stattfinden (nur in bestimmten, wegen ihrere Anforderungen: Größe, DV-Ausstattung, ...).

V-D-R_UN

Vorlesung

Dozent

Raum

V1

D1, D2

R1, R2

V2

D1

R2

V3

D1, D3

R3

[V-D-R: Vorlesungen - Dozenten - Räume]

Was bedeuten in einer solchen Relation die Tupel (Zeilen)? Die Bedeutung der ersten Zeile ist wie folgt: Vorlesung V1 wird von den Dozenten D1 und D2 angeboten und kann in den Räumen R1 und R2 durchgeführt werden. Entsprechend bedeutet die zweite Zeile: Vorlesung V2 wird von D1 angeboten und kann in R2 stattfinden. Und die dritte: Vorlesung V3 wird von D1 und D3 angeboten und kann in R3 stattfinden.

Wird diese unnormalisierte Tabelle nun direkt mittels Tupelvermehrung in die 1NF gebracht, müssen die Mehrfacheinträge miteinander kombiniert werden (mittels des kartesischen Produkts), nur dann bleibt die Information der unnormalisierten Relation erhalten. Dann entsteht folgende Relation:

Normalisierung durch kartesisches Produkt

V-D-R_1NF

Vorlesung

Dozent

Raum

V1

D1

R1

V1

D1

R2

V1

D2

R1

V1

D2

R2

V2

D1

R2

V3

D1

P3

V3

D3

P3

[V-D-R: Vorlesungen - Dozenten - Räume]

In dieser haben die Tupel folgende Bedeutung:

Tupel 1: V1 wird von D1 angeboten und kann in R1 stattfinden

Tupel 2: V1 wird von D1 angeboten und kann in R2 stattfinden

Tupel 3: V1 wird von D2 angeboten und kann in R1 stattfinden

Tupel 4: V1 wird von D2 angeboten und kann in R2 stattfinden

usw. Die ersten vier Tupel werden benötigt, um den Informationsgehalt des ersten Tupels der Relation V-D-R_UN zu erfassen (1 * 2 * 2 = 4). Es ist leicht zu sehen, dass eine solche Relation nur Schwierigkeiten bereitet. Trotzdem ist sie in BCNF, da alle Attribute Schlüsselattribute sind ("all key") und die Regeln der BCNF gegenüber einer solchen Situation nicht greifen.

Die Redundanz ist offensichtlich: Dass V1 von D1 angeboten wird, ist nicht nur einmal erfasst, sondern mehrmals (für jeden Raum). Ebenso wird die Tatsache, dass V1 in R1 stattfinden kann, mehrfach erfasst (Zahl der Dozenten). Dieses Strukturdefizit entsteht, weil im Rahmen der Normalisierung die Information auf "flache" Tupel verteilt werden muss. Die Komplexität entsteht durch die Bildung der Relation aus dem kartesischen Produkt der Ausprägungen mit Mehrfacheinträgen. Dadurch "lastet" auf ihr eine komplexe Regel:

Redundanz

Falls (V1, D1, R1) und (V1, D2, R2) beide da sind, müssen auch (V1, D1, R2) und (V1, D2, R1) vorkommen.

Dies resultiert aus der Entstehung der Relation durch Tupelvermehrung. Aus dem ersten Teil der Regel folgt, dass in der unnormalisierten Ursprungsrelation die nachfolgend aufgeführte Zeile vorhanden war:

V1 mit seinen Dozenten und Räumen

Vorlesung

Dozent

Raum

V1

D1, D2

R1, R2

Denn diese führt zu folgenden Kombinationen:

War diese aber vorhanden, müssen (wegen der Bildung des kartesischen Produkts aus (D1, D2) x (R1, R2) auch die Tupel (V1, D2, R1) und (V1, D2, R2) vorhanden sein. Eine solch komplexe Regel (eine semantische Integritätsbedingung) kann im Zeitverlauf kaum aufrechterhalten werden. Bei jedem neuen Eintrag, der entweder mehrere Hosts oder mehrere Produzenten aufweist muss ja nicht nur ein Tupel, sondern es müssen mehrere eingetragen werden.

Wird zum Beispiel V1 zusätzlich von einem Dozenten D4 angeboten, muss nicht nur das Tupel (V1, D4, R1), sondern auch das Tupel (V1, D4, R3) zusätzlich eingetragen werden.

Auch hier besteht die Lösung wiederum in einer Zerlegung der Relation. Mit den obigen Abkürzungen wird V-D-RS in die zwei Relationen

Normalisierung durch Zerlegung

V-D_4NF (#(Vorlesung, Dozent))

V-D ist auch gleich in 5NF

und

V-R_4NF (#(Vorlesung, Raum))

V-R ebenfalls

zerlegt. V-D_4NF erfasst nun die Beziehung zwischen Vorlesungen und ihren Dozenten ("welcher Dozent gibt welche Vorlesung). V-R_4NF erfasst die Beziehung zwischen Vorlesungen und Räumen ("in welchen Räumen können die Vorlesungen stattfinden). Es entstehen die folgenden Tabellen:

V-D_4NF

Vorlesung

Dozent

V1

D1

V1

D1

V1

D2

V1

D2

V2

D1

V3

D1

V3

D3

Schlüssel: #(Vorlesung, Dozent)

V-R_4NF

Vorlesung

Raum

V1

R1

V1

R2

V1

R1

V1

R2

V2

R2

V3

R3

V3

R3

Schlüssel: #(Vorlesung, Raum)

Die durchgestrichenen Zeilen zeigen wiederum die Redundanz der ursprünglichen Relation. Die Kennzeichnung von Vorlesung als Fremdschlüssel (durch Unterstreichung) hat nicht genau dieselbe Bedeutung wie sonst, da (hier) ja die Relation fehlt, die Vorlesungen beschreibt und in der das Attribut Vorlesung Schlüssel wäre. Sie wurde trotzdem gewählt, weil die beiden Attribute Fremdschlüsselcharakter haben. Allerdings wäre eine direkte Verknüpfung problematisch (wegen der jeweils mehrfachen Ausprägungen), weshalb im folgenden Datenmodell eine Relation VORLESUNGEN ergänzt wurde.

Bewältigte Redundanz

Abbildung 12.2-1: Relationales Datenmodell V-D-R

Wegen der hier diskutierten Probleme mit mehrfachen Wiederholungsgruppen weist Date darauf hin, dass bei der Normalisierung einer unnormalisierten Relation auf jeden Fall zuerst die voneinander unabhängigen Wiederholungsgruppen getrennt werden sollten [Date 1990, S. 383].

Regel

12.3 Mehrwertige Abhängigkeit

Für die Definition der vierten Normalform (4NF), in der also die oben beschrieben Strukturdefizite nicht (mehr) auftreten, kann eine weitere Form der Abhängigkeit zwischen den Attributen einer Relation eingeführt werden, die sog. mehrwertige Abhängigkeit (MWA; engl. multi-valued-dependency (MVD)). Bei dieser stehen zwei Attribute A und B einer Relation in folgender Beziehung zueinander: Kennt man eine Ausprägung von A, kann man zwar nicht genau eine (einzige) von B "vorhersagen" (dies wäre eine funktionale Abhängigkeit), aber eine genau definierte Menge von Ausprägungen von B. Beispiele hierfür sind leicht zu finden.

In obiger Relation zu Vorlesungen - Dozenten - Räumen:

Kennt man die Bezeichnung einer Vorlesung, kann man zwar nicht genau einen Dozenten nennen, der sie halten kann, aber eine genau definierte Gruppe von Dozenten.

Kennt man die Bezeichnung einer Vorlesung, kann man zwar nicht genau einen Raum nennen, der geeignet ist, aber eine genau definierte Menge von Räumen, in denen die Vorlesung stattfinden kann.

In einer Relation zu den Angestellten eines Unternehmens:

Vom Namen eines Angestellten kann nicht eine einzelne von ihm beherrschte Programmiersprache genannt werden, aber eine Liste, nämlich genau die der von ihm beherrschten.

In einer Relation zu Datenbanksystemen:

Da ein DBS mehrere Datentypen hat, gilt auch hier eine solche Beziehung, da vom Namen eines Datenbanksystems zwar nicht auf einen Datentyp, aber auf eine wohldefinierte Menge von Datentypen geschlossen werden kann.

Aus der Sicht der Abhängigkeiten zwischen Attributen bedeutet dies, dass nicht eine Ausprägung genannt werden kann, aber eine genau definierte Menge. Das ist die oben angeführte mehrwertige Abhängigkeit (MWA).

Exkurs: Abhängigkeiten zwischen den Attributen einer Relation

Attribute einer Relation stehen miteinander in Beziehung. Mit der obigen mehrwertigen Abhängigkeit sind insgesamt folgende Beziehungen möglich:

Unabhängigkeit (die Ausprägungen der beiden Attribute sind unabhängig voneinander. Jede Ausprägung beschreibt eine eigenständige Eigenschaft).

volle und einfache funktionale Abhängigkeit

transitive Abhängigkeit

mehrwertige Abhängigkeit

Mit Ausnahme der ersten gibt jede Beziehung einen Hinweis auf Optimierungsbedarf.

In einer Relation schlägt sich die mehrwertige Abhängigkeit in der Form von Mehrfacheinträgen bei einem der Attribute nieder. Diese Form der Abhängigkeit zwischen zwei Attributen einer Relation ist somit etwas weiter als die der funktionalen Abhängigkeit, aber deutlich enger als die der Unabhängigkeit zweier Attribute (dann ist überhaupt keine "Vorhersage" möglich ist).

"Wieviel Vorhersage" ist möglich

Schwierigkeiten bereitet diese Art der Abhängigkeit nur, falls sie doppelt in einer unnormalisierten Relation vorkommt. Dann müssen mindestens drei Attribute A, B und C im Spiel sein und zwei davon stehen in der beschriebenen Abhängigkeit vom dritten (wie im obigen Beispiel).

Seien A, B, C Attribute einer Relation R. B heißt mehrwertig abhängig von A, in Zeichen: A_C =>=> B falls für jede Kombination von Attributsausprägungen von A, C eine wohldefinierte Menge von Ausprägungen von B existiert, die von A, aber nicht von C abhängt.

Definition: Mehrwertige Abhängigkeit (MWA)

Es gilt dann auch: A_B =>=> C

Am leichtesten veranschaulicht man sich die Definition anhand des obigen Beispiels. Hier gilt

VorlesungDozent =>=> Raum

VorlesungRaum =>=> Dozent

Das tiefgestellte Attribut wird mit angegeben, um deutlich zu machen, dass die MWA nur dann gegeben ist, wenn drei Attribute im Spiel sind, denn nur dann treten die beschriebenen Schwierigkeiten auf. Liegen nur zwei (die zwei mit den Mehrfacheinträgen) vor, werden sie gegeneinander aufgelöst und es entsteht eine Situation wie bei einer Verbindungsrelation.

Jede funktionale Abhängigkeit ist auch eine (einfache) mehrwertige Abhängigkeit (eine, bei der nur ein "Treffer" vorliegt). Im Folgenden sollen mehrwertige Abhängigkeiten, die keine funktionalen Abhängigkeiten sind, als echte mehrwertige Abhängigkeiten bezeichnet werden.

Echte MWA

12.4 Definition 4NF

Eine Relation mit einer echten mehrwertigen Abhängigkeit hat die beschriebenen Strukturdefizite, die durch einen weiteren Normalisierungsschritt beseitigt werden, der zur vierten Normalform (4NF) führt. Dies geschieht so, dass aus jedem Attribut mit Mehrfacheinträgen zusammen mit dem Schlüssel eine neue Relation gebildet wird: Waren A, B und C die Attribute mit A_C =>=> B und A_B =>=> C, dann kann die Relation in die zwei Relationen R1(A,B) und R2(A,C) zerlegt werden. Die so entstehenden Relationen befinden sich dann in vierter Normalform.

Eine Relation R ist in 4NF, falls sie in BCNF ist und falls sie keine echten mehrwertigen Abhängigkeiten aufweist.

Definition 1: 4NF

Gleichwertig ist die folgende Definition nach [Date 1990, S. 558]:

Eine Relation R ist in 4NF, falls alle mehrwertigen Abhängigkeiten in R auf den Schlüsseln von R basieren.

Definition 2: 4NF

Denn wenn sie auf den Schlüsseln beruhen, liegt bei einem Schlüssel aus einem Attribut in einer Richtung immer Eindeutigkeit vor, vom Schlüssel zu den Nichtschlüsselattributen. Sollten - Alternative 2 - zwei Attribute mit Mehrfacheinträgen als Schlüssel vorliegen, sind sie von allen anderen unabhängig, werden gegeneinander aufgelöst und stellen einen zusammengesetzten Schlüssel dar.

Wie oben ausgeführt, treten die Probleme nur auf, wenn zwei Attribute mit Mehrfacheinträgen auftreten. Liegt nur ein solches vor, wird die Tabelle einfach flach gemacht, z.B. durch Tupelvermehrung (vgl. oben).

Faustregel

Probleme mit der 4NF können also nur auftreten, wenn eine echte mehrwertige Abhängigkeit durch Tupelvermehrung aufgelöst wurde. Umgekehrt: Liegt keine echte MWA vor, können die Strukturdefizite, die zu Problemen mit der 4NF führen, nicht vorliegen.

13 Die fünfte Normalform (5NF)

Motivation

Stellen wir uns vor, in einer Relation zum Anwendungsbereich Projektmitarbeit (in einem Softwarehaus) geht es darum festzuhalten, mit welcher Programmiersprache jeder Mitarbeiter in einem bestimmten Projekt mitwirkt. In der zugehörigen Relation – nennen wir sie AngProjPS (Angestellte – Projekte – Programmiersprachen) könnten z.B. folgende Attribute und Tupel vorliegen:

Relation AngProjPS

PersNr

BezProj

BezPS

1007

SocWeb

XHTML

1007

WebPl

PHP

1007

WebPl

MySQL

1008

WebPl

PHP

1008

WebPl

MySQL

1009

PPS

Cpp

1009

PPS

Cpp

1009

PPS

C

1010

PPS

C

1010

PPS

Cpp

1010

WebPl

PHP

1010

WebPl

MySQL

Schlüssel: (PersNr, BezProj, BezPS)

WebPl soll ein Projekt zur Erstellung einer neuen Webplattform für das Unternehmen sein. SocWeb eines zur Analyse von Daten im Social Web. PPS soll das (selbst programmierte) Produktionsplanungssystem des Unternehmens verbessern.

Es soll nun aber nicht die übliche Semantik einer solchen Relation gelten, die einfach die Attribute in die üblichen Beziehungen (funktionale Abhängigkeiten) stellt, z.B.:

„1008“ arbeitet im Projekt WebPl mit und nutzt dort die Abfragesprache MySQL

Sondern es gilt eine vertiefte semantische Struktur, die an diesem Beispiel so beschrieben werden kann:

Vertiefte Semantik

Falls die Angestellte 1007 im Projekt SocWeb mitarbeitet und falls im Projekt SocWeb XHTML benötigt wird, dann arbeitet 1007 mit XHTML in dem Projekt mit.

Für die Tupel bedeutet dies an obigem Beispiel: Falls

eine Person in einem Projekt mitwirkt,

falls in diesem Projekt eine bestimmte Programmiersprache benötigt wird

und falls die Person diese Programmiersprache beherrscht,

dann wirkt diese Person mit dieser Programmiersprache in diesem Projekt mit.

Es werden hier also Projektmitarbeit, Programmiersprachenkompetenz und Programmierspracheneinsatz in Projekten miteinander verknüpft.

Ansonsten verstößt diese Relation gegen keine der uns bisher bekannten Normalformen:

Funktionale Abhängigkeiten liegen nicht vor, auch nicht bei Schlüsselattributen (BCNF). Die einzelnen Attribute sind unabhängig voneinander.

Alle drei Attribute zusammen sind Schlüssel.

Es liegen keine mehrwertigen Abhänfigkeiten vor (4NF).

Es liegt kein Verstoß gegen die ersten vier Normalformen vor.

Trotzdem wäre eine solche Relation nur schwer zu pflegen, weil die beschriebene komplexe Semantik beim Löschen, Einfügen und Aktualisieren ja erhalten bleiben müsste.

Wie meist beim Optimieren von Relationen könnte die Lösung darin liegen, eine solche Relation ohne Semantikverluste zu zerlegen. Wie dies in diesem Fall geht, zeigen die Ausführungen in diesem Kapitel.

Vorbemerkung

Bevor die abschließende fünfte Normalform (5NF) besprochen werden kann, werden die beiden Techniken Verbund und Projektion benötigt. Diese beschreiben zwei sog. Relationale Operatoren (oder Operationen).

Hier wird, zur Darstellung von Verbund (Join) und Projektion, mit SQL gearbeitet. Es wäre daher sinnvoll, zuerst Kapitel 19 mit einer Einführung in SQL zu lesen, insbesondere die Abschnitte 19.5 und 19.8.

13.1 Verbund (Join) und Projektion

13.1.1 Verbund (Join)

Vgl. auch Abschnitt 19.8

Ein Verbund (Join) zweier Relationen ist die relationale Verknüpfung auf der Basis der Ausprägungen zweier Attribute (meist Schlüssel / Fremdschlüssel). Dabei werden die Tupel einer Relation A (mit Verknüpfungsattribt a1) mit denen einer Relation B (Verknüpfungsattribut b1) zu neuen Tupeln zusammengefügt, falls sich in a1 und b1 identische Attributsausprägungen finden. Meist ist a1 ein Schlüssel und b1 ein Fremdschlüssel, dann muss sich also zu einer Schlüsselausprägung eine übereinstimmende Fremdschlüsselausprägung finden, damit die Tupel verknüpft werden. Falls sich zu einer Schlüsselausprägung mehrere Fremdschlüsselausprägungen finden, entstehen mehrere verknüpfte Tupel.

Beispiel

Im folgenden Beispiel gehe es in Ang um die Angestellten und in Abt um die Abteilungen eines Unternehmens.

Relation Ang

PersNr

Name

Vname

AbtBez

1030

May

Karl

IT

1005

Sommer

Lisa

PW

1040

Winter

Angelika

IT

1090

Stepper

Rolf

PW

1008

Rülp

Fred

VB

1009

Baum

Ottilie

FE

1017

Czerny

Rudi

CO

Relation Abt

AbtBez

AbtLeiter

Standort

PW

Sommer

Hamburg

RE

Müller

Passau

VB

Rülp

Ulm

CO

Czerny

Ulm

LA

Dorr

Hamburg

PW=Personalwesen, IT=Datenverarbeitung, RE=Rechnungswesen, VB=Vertrieb
CO Controlling, LA Lager

Ein Verbund dieser zwei Relationen kann über über die Abteilungsbezeichnung (AbtBez) durchgeführt werden. Dieses Attribut ist Schlüssel in Abt und Fremdschlüssel in Ang. Mit dem folgenden VERBUND-Befehl (mit MySQL, vgl. Kapitel 19) werden nun alle Tupel aus Ang nacheinander abgeglichen mit den Tupeln der Relation Abt. Tritt in Abt dieselbe Ausprägung in AbtBez auf, wird ein neues zusammengesetztes Tupel aus allen oder ausgewählten Attributen beider Relationen gebildet. Die neuen Tupel werden zu einer Ergebnisrelation zusammengefasst.

Verbund (Join)

Vgl. Abschnitt 5.7 für eine vertiefte Darstellung.

Der SQL-Befehl ist wie folgt:

Select a.PersNr, a.Name, a.VName, a.AbtBez,

b.AbtBez, b.AbtLeiter, b.Standort

from ang a, abt b

where a.AbtBez=b.AbtBez

Das Ergebnis des Verbunds:

PersNr

Name

VName

AbtBez

AbtBez

AbtLeiter

Standort

1005

Sommer

Lisa

PW

PW

Sommer

Hamburg

1090

Stepper

Rolf

PW

PW

Sommer

Hamburg

1008

Rülp

Fred

VB

VB

Rülp

Ulm

1017

Czerny

Rudi

CO

CO

Czerny

Ulm

Das erste Attribut AbtBez stammt aus der Relation Ang, das zweite aus Abt.

Das Ergebnis der Abfrage ist nur für die Ausgabe und für eine eventuelle Weiterverarbeitung (z.B. in einem Reportgenerator oder einer Maske der Bedienoberfläche) vorhanden, es wird nicht dauerhaft (persistent) gespeichrt. Es enthält die verknüpften Daten mit den Redundanzen im Bereich der Abteilungsinformation und ist nur in 2NF.

Temporäre Ausgaberelation

Wie in Abschnitt 5.9 dargelegt, fordert die referentielle Integrität, dass es keinen Fremdschlüsseleintrag geben darf, den es im zugehörigen Schlüssel nicht gibt. Dies ist hier nicht gegeben:

Referentielle Integrität

Für die Abteilungsbezeichnung IT in Ang (Fremdschlüssel!) gibt es keine Entsprechung in Abt.AbtBez. Ebenso für FE. Umgekehrt: Der Schlüsselwert RE in Abt hat keine Entsprechung in den Fremdschlüsseln Ang.AbtBez. Ebenso LA. Es bleiben also nur die Ausprägungen PW, VB und CO, die in beiden Relationen vorkommen, so dass es auch nur für diese verknüpfte Tupel gib.

Diese Operation Verbund (Join) wird in SQL ständig benötigt, da sie temporär Relationen wieder zusammenfügt, die vielleicht vorher im Rahmen der Normalisierung getrennt wurden.

Vgl. für eine Einführung in SQL Kapitel 19, zum Join Abschnitt 19.8.

13.1.2 Projektion

Die relationale Operation Projektion besteht darin, bestimmte Attribute (Spalten) einer Relation zu streichen, so dass als Ergebnis eine "schlankere" Relation entsteht. Sollten dabei gleiche Tupel entstehen, werden diese gestrichen.

Betrachten wir als erstes Beispiel wiederum eine Relation zu den Angestellten eines Unternehmens (Ang). Neben dem Namen enthält sie auch noch die Bezeichnung der Abteilung, in der der Angestellte arbeitet (AbtBez).

Beispiel Angestellte

Ang

PersNr

Name

VName

AbtBez

1030

May

Karl

IT

1005

Sommer

Lisa

PW

1040

Winter

Angelika

IT

1090

Stepper

Rolf

PW

1008

Rülp

Fred

VB

1009

Baum

Ottilie

FE

1017

Czerny

Rudi

CO

Eine Projektion könnte darin bestehen, nur die Attribute Name und VName auszuwählen:

select Name, VName from Ang;

Projektion 1 auf Ang

Name

VName

May

Karl

Sommer

Lisa

Winter

Angelika

Stepper

Rolf

Rülp

Fred

Baum

Ottilie

Czerny

Rudi

Eine andere könnte für irgendeinen Zweck nur die Abteilungszugehörigkeit auswählen:

select PersNr, AbtBez from Ang;

Projektion 2 auf Ang

PersNr

AbtBez

1030

IT

1005

PW

1040

IT

1090

PW

1008

VB

1009

FE

1017

CO

Oftmals ergeben sich bei Projektionen identische Tupel. Diese sind in Relationen sinnlos und nicht vorgesehen. Das folgende Beispiel einer Relation zur Thematik …

Angestellte - Projekte - Funktionen

… möge dies verdeutlichen. Die Relation hält fest, wer in welchem Projekt mit welcher Funktion mitarbeitet. Es liegt eine n:m-Beziehung vor: Ein Angestellter kann in mehreren Projekten mitarbeiten, zu einem Projekt gehören typischerweise mehrere Angestellte.

AngProjFu

Name

Projekt

Funktion

Bauer

A

Leitung

Bauer

B

Controller

Dürr

D

Leitung

Hasslo

A

Entwickler

Hasslo

D

Entwickler

May

C

Leitung

Müller

A

IT

Müller

B

Leitung

Müller

C

IT

Müller

D

Finanzen

Schlüssel: #(Name, Projekt))

Eine Projektion könnte darin bestehen, die Attribute Name und Funktion auszuwählen, um festzustellen, welche Funktionen die einzelnen Personen in Projekten übernehmen. Dann ergibt sich, sortiert nach Name und Funktion sowie vor der Löschung der identischen Tupel, folgende Relation:

Projektion 1 auf AngFu

AngFu_redundant

Name

Funktion

Bauer

Controller

Bauer

Leitung

Dürr

Leitung

Hasslo

Entwickler

~~Hasslo~~

~~Entwickler~~

May

Leitung

Müller

Finanzen

Müller

IT

~~Müller~~

IT

Müller

Leitung

Schlüssel: #(Name, Funktion))

Die redundanten Tupel sind durchgestrichen.

Werden die identischen Tupel gelöscht (identische Tupel gibt es in Relationen nicht!) entsteht AngFu_ohne Redundanz.

AngFu_ohne Redundanz

Name

Funktion

Bauer

Controller

Bauer

Leitung

Dürr

Leitung

Hasslo

Entwickler

May

Leitung

Müller

Finanzen

Müller

IT

Müller

Leitung

Schlüssel: #(Name, Funktion))

Soweit die benötigten Grundlagen für die 5NF.

13.2 N-Zerlegbarkeit

Kommen wir zurück zu der Relation AngProjPS aus dem Motivationsabschnitt:

Relation AngProjPS

PersNr

BezProj

BezPS

1007

SocWeb

XHTML

1007

WebPl

PHP

1007

WebPl

MySQL

1008

WebPl

PHP

1008

WebPl

MySQL

1009

PPS

Cpp

1009

PPS

Cpp

1009

PPS

C

1010

PPS

C

1010

PPS

Cpp

1010

WebPl

PHP

1010

WebPl

MySQL

Schlüssel: (PersNr, BezProj, BezPS)

WebPl soll ein Projekt zur Erstellung einer neuen Webplattform für das Unternehmen sein. SocWeb eines zur Analyse von Daten im Social Web. PPS soll das (selbst programmierte) Produktionsplanungssystem des Unternehmens verbessern.

Sie hat, wie oben ausgeführt, nicht die „übliche“ Semantik eines solchen Tupels, sondern eine vertiefte, die alle drei Attribute in Beziehung setzt:

Falls eine Person in einem Projekt mitarbeitet, falls dort eine bestimmte Programmiersprache benötigt wird und die Person diese Programmiersprache beherrscht, dann arbeitet sie mit dieser Programmiersprache in diesem Projekt mit.

In obigem Beispiel:

Falls die Angestellte 1007 im Projekt SocWeb mitarbeitet und falls im Projekt SocWeb XHTML benötigt wird, dann arbeitet 1007 mit XHTML in dem Projekt mit.

Für die Tupel bedeutet dies zum Beispiel:

Mit den zwei Einträgen „1007 / WebPl“ (interpretiert als „1007 arbeitet im Projekt WebPl mit“) und „WebPl / MySQL“ (interpretiert als „in WebPl wird MySQL benötigt“) muss also auch „1007 / MySQL“ (interpretiert als „1007 beherrscht MySQL“) im Tupel vorhanden sein.

Eine solche Relation wäre nur schwer zu pflegen, weil die beschriebene komplexe Semantik beim Löschen, Einfügen und Aktualisieren ja erhalten bleiben müsste. Entdeckt wurde dieses Strukturmerkmal von Relationen durch [Aho, Beeri und Ullman 1979], zitiert nach [Date, Kannan und Swamynathan 2006, S. 320].

Sie erfüllt die ersten vier Normalformen. Die dort jeweils angeführten Defizite liegen nicht vor. Trotzdem weist sie das beschriebene Defizit aus. Bleibt nur die Zerlegung, um eine Relationenstruktur zu schaffen, die gepflegt werden kann.

Die übliche Vorgehensweise wäre eine Zerlegung in zwei Relationen. Dies klappt hier aber nicht. Dabei geht der semantische Bezug über die drei Attribute hinweg verloren. Bleibt nur die Zerlegung in mehr als zwei Relationen mit dem Join als Werkzeug, um die zerlegten Relationen wieder zusammenzuführen.

Dies wurde in den einschlägigen Tagungen erarbeitet und führte zur Definition der n-Zerlegbarkeit:

Eine Relation heißt n-zerlegbar, falls sie ohne Informationsverlust in n Relationen zerlegt werden kann, nicht aber in m (m < n).

Definition:
n-Zerlegbarkeit

Das Phänomen der n-Zerlegbarkeit bezieht sich also auf Beziehungen, die über mehr als zwei Attribute greifen.

Wann kommt es zu einer solchen - zugegeben etwas konstruierten - Situation? Sie liegt genau dann vor, wenn die Relation dem Verbund von einigen ihrer Projektionen entspricht bzw. wenn ihre Entstehung so gedacht werden kann.

Dies führte zur Definition der Verbundabhängigkeit, für die die beiden oben eingeführten Techniken (Verbund (Join) und Projektion) benötigt werden:

Seien T die Menge der Attribute einer Relation R und AK1, AK2, AKn Teilmengen von T. R ist verbund-abhängig, in Zeichen

Definition: Verbundabhängigkeit

* (AK₁, AK₂, ..., AK_n)

falls R gleich dem Verbund seiner Projektionen auf AK₁, AK₂, ..., AK_n ist.

Damit kann dann die fünfte Normalform (5NF) definiert werden:

Definition: 5NF

Sei R eine Relation. R ist in der 5NF, falls jede Verbund-Abhängigkeit in R durch Schlüssel von R verursacht wird.

Zur Abklärung der 5NF muss also erst mal geklärt werden, ob eine Verbundabhängigkeit, wie oben beschrieben, vorliegt. Dann muss geklärt werden, ob diese durch die Schlüssel verursacht ist.

Verbund über Schlüssel, 5NF erfüllt:

Beispiel

Wir nutzen wieder die Relationen AngProj und AngPS sowie eine weitere, AngAbt, die auch den Schlüssel PersNr hat (damit der Verbund über den Schlüssel gehen kann). AngAbt (Angestellte / Abteilungen) erfasst die Abteilungszugehörigkeit:

select* from angabt;

PersNr

BezAbt

1007

IT

1008

Personalwesen

1009

Entwicklung

1010

Entwicklung

1011

Produktion

1012

Personalwesen

1013

Prozessmanagement

1014

Prozessmanagement

Führen wir nun einen Join durch, mit dem Ziel den Zusammenhang zwischen Personen, ihren Abteilungen und beherrschten Programmmiersprachen zu erfassen:

select a.PersNr, a.BezAbt, b.BezProj, c.BezPS

from AngAbt a, AngProj b, AngPS C

where a.PersNr=b.PersNr

and b.PersNr=c.PersNr;

PersNr

BezAbt

BezProj

BezPS

1007

IT

WebPl

PHP

1007

IT

SocWeb

PHP

1007

IT

WebPl

MySQL

1007

IT

SocWeb

MySQL

1008

Personalwesen

WebPl

XHTML

1008

Personalwesen

WebPl

PHP

1009

Entwicklung

PPS

C

1009

Entwicklung

PPS

JavaScr

1010

Entwicklung

PPS

Cpp

1010

Entwicklung

WebPl

Cpp

1010

Entwicklung

PPS

HTML 5

1010

Entwicklung

WebPl

HTML 5

1010

Entwicklung

PPS

Fortran

1010

Entwicklung

WebPl

Fortran

Dieser Verbund wurde mit einem Schlüssel durchgeführt und führt zu einem fehlerfreien Ergebnis, da jedem Schlüsselwert der einen ein Schlüsselwert der anderen entspricht. In die Ergebnisrelation kommen auf diese Weise auch nur die Tupel der verschiedenen Relationen, die einen gemeinsamen Schlüssel haben.

Verbund mit Schlüsseln

Das Beispiel macht auch deutlich, dass die Verbundabhängigkeit die ganz normale funktionale Abhängigkeit mitumfasst. Denn wenn der jeweilige Schlüssel ein solcher ist, liegen funktionale Abhängigkeiten zwischen ihm und den NSA vor. Erfolgt der Verbund über Schlüssel, werden demzufolge Attribute zusammengeführt, die von demselben Schlüssel funktional abhängig sind.

Wie leicht gezeigt werden kann gilt damit: Jede Relation in 5NF ist auch in 4NF. Denn wenn die Relation aus einem Verbund mit Hilfe von Schlüsseln entstanden ist, können keine mehrwertigen Abhängigkeiten vorliegen.

5NF umfasst 4NF

Nun ein Verbund, der nicht mit Schlüsseln realisert wird, sondern mit Teilen von Schlüsseln (Schlüsselattributen).

„Nicht-Schlüssel-Verbund“

Nun ein Verbund, der nicht mit Schlüsseln realisiert wird, sondern mit Teilen von Schlüsseln (Schlüsselattributen).

Zur Veranschaulichung betrachten wir nochmals das Beispiel AngProjPS, jetzt ausgehend von einzelnen Relationen, deren Join zu AngProjPS geführt haben könnte.

Beispiel AngProjPS

Die Relationen AngProj (Angestellte, Projekte), ProjPS (Projekte, Programmiersprachen) und AngPS erfassen jeweils Aspekte der Tätigkeiten von Angestellten in Unternehmen:

AngProj: Wer arbeitet in welchem Projekt mit?

ProjPS: Welche Programmiersprachen werden in welchen Projekten genutzt?

AngPS: Wer beherrscht welche Programmiersprachen

Sie verbinden jeweils zwei voneinander unabhängige Aspekte dieses Anwendungsbereichs, weshalb sie alle einen zusammengesetzten Schlüssel haben. Hier zur Veranschaulichung einige Beispieldaten.

Wer arbeitet in welchem Projekt mit:

Relation AngProj

PersNr

BezProj

1007

WebPl

1007

SocWeb

1008

WebPl

1009

PPS

1010

PPS

1010

WebPl

Schlüssel #(PersNr, BezProj)

Wieder gilt:

WebPl soll ein Projekt zur Erstellung einer neuen Webplattform für das Unternehmen sein. SocWeb eines zur Analyse von Daten im Social Web. PPS soll das (selbst programmierte) Produktionsplanungssystem des Unternehmens verbessern.

Zum Nachvollziehen, zum Beispiel mit MySQL (vgl. Kapitel 19):

Create table AngProj (PersNr int(4), BezProj char(6));

Insert into AngProj values

(1007, 'WebPl'),

(1007, 'SocWeb'),

(1008, 'WebPl'),

(1009, 'PPS'),

(1010, 'PPS'),

(1010, 'WebPl');

In Projekten benötigte Programmiersprachen:

Relation ProjPS

BezProj

BezPS

WebPl

PHP

WebPl

C#

WebPl

CSS

SocWeb

HTML5

SocWeb

Python

SocWeb

XHTML

WebPl

MySQL

PPS

C

PPS

Cpp

Schlüssel #(BezProj, BezPS)

Zum Nachvollziehen:

Create table ProjPS (BezProj char(6), BezPS char(6));

Insert into ProjPS values

('WebPl' ,'PHP'),

('WebPl', 'C#'),

('WebPl', 'CSS'),

('SocWeb', 'HTML5'),

('SocWeb', 'Python'),

('SocWeb', 'XHTML'),

('WebPl', 'MySQL'),

('PPS', 'C'),

('PPS', 'Cpp');

Programmiersprachen, die Angestellte beherrschen:

Relation AngPS

PersNr

BezPS

1007

PHP

1007

MySQL

1008

XHTML

1009

C

1009

JavaScr

1010

Cpp

1010

HTML 5

1010

Fortran

1011

Cpp

Schlüssel #(PersNr, BezPS)

Zum Nachvollziehen:

Create table AngPS (PersNr int(4), BezPS char(7));

Insert into AngPS values

(1007 ,'PHP'),

(1007, 'MySQL'),

(1008, 'XHTML'),

(1009, 'C'),

(1009, 'JavaScript'),

(1010, 'Cpp'),

(1010, 'HTML 5'),

(1010, 'Fortran'),

(1011, 'Cpp');

Nun der Verbund

Ein Verbund ist hier nur über Nichtschlüsselattribute (NSAs) möglich. Zuerst für zwei Attribute, mit denen die Projektmitarbeit und die Programmiersprachenkompetenz einer jeden Person zusammengeführt werden:

select *

from AngProj a, AngPS c

where a.PersNr = c.PersNr

order by a.PersNr, a.BezProj, c.BezPS

PersNr

BezProj

PersNr

BezPS

1007

SocWeb

1007

MySQL

1007

SocWeb

1007

PHP

1007

WebPl

1007

MySQL

1007

WebPl

1007

PHP

1008

WebPl

1008

PHP

1008

WebPl

1008

XHTML

1009

PPS

1009

C

1009

PPS

1009

JavaScr

1010

PPS

1010

Cpp

1010

PPS

1010

Fortran

1010

PPS

1010

HTML 5

1010

WebPl

1010

Cpp

1010

WebPl

1010

Fortran

1010

WebPl

1010

HTML 5

Es werden in diesem Beispiel bewusst alle Attribute ausgegeben, um die Verknüpfung und Einschränkungen zu verdeutlichen. Dabei wird auch deutlich, dass – wenn wir uns die doppelte Personalnummer wegdenken – eine optimale Struktur vorliegt. Beide, BezProj und BezPS sind funktional abhängig von PersNr.

Nun der erste Ausbau des Verbunds durch Hinzunahme der Einschränkung auf die Tupel, bei denen die Programmiersprache der Person identisch ist mit der benötigten Programmiersprache im Projekt.

select *

from AngProj a, ProjPS b, AngPS c

where a.PersNr = c.PersNr

AND b.BezPS = c.BezPS

order by a.PersNr, a.BezProj, c.BezPS

PersNr

BezProj

BezProj

BezPS

PersNr

BezPS

1007

SocWeb

WebPl

MySQL

1007

MySQL

1007

SocWeb

WebPl

PHP

1007

PHP

1007

WebPl

WebPl

MySQL

1007

MySQL

1007

WebPl

WebPl

PHP

1007

PHP

1008

WebPl

WebPl

PHP

1008

PHP

1008

WebPl

SocWeb

XHTML

1008

XHTML

1009

PPS

PPS

C

1009

C

1010

PPS

PPS

Cpp

1010

Cpp

1010

WebPl

PPS

Cpp

1010

Cpp

Der zweite Ausbau des Verbunds bringt eine weitere semantische Einschränkung auf die Tupel, bei denen das bei AngProj (Projektmitarbeit) genannte Projekt gleich dem ist, welches in ProjPS genannt wird:

select *

from AngProj a, ProjPS b, AngPS c

where a.PersNr = c.PersNr

AND b.BezPS = c.BezPS

AND a.BezProj = b.BezProj

order by a.PersNr, a.BezProj, c.BezPS

PersNr

BezProj

BezProj

BezPS

PersNr

BezPS

1007

WebPl

WebPl

MySQL

1007

MySQL

1007

WebPl

WebPl

PHP

1007

PHP

1008

WebPl

WebPl

PHP

1008

PHP

1009

PPS

PPS

C

1009

C

1010

PPS

PPS

Cpp

1010

Cpp

Hier mit Unterdrückung identischer Attribute:

select a.PersNr, a.BezProj, c.BezPS

from AngProj a, ProjPS b, AngPS c

where a.PersNr = c.PersNr

AND b.BezPS = c.BezPS

AND a.BezProj = b.BezProj

order by a.PersNr, a.BezProj, c.BezPS

PersNr

BezProj

BezPS

1007

WebPl

MySQL

1007

WebPl

PHP

1008

WebPl

PHP

1009

PPS

C

1010

PPS

Cpp

Insgesamt tragen die Tupel nun folgende Semantik:

Falls eine Person in einem Projekt mitwirkt, falls dort eine bestimmte Progammiersprache benötigt wird und falls die Person diese Programmiersprache beherrscht, dann wirkt sie auch mit dieser Programmiersprache in diesem Projekt mit.

Betrachten wir den Befehl nochmal detailliert:

select a.PersNr, b.BezProj, c.BezPS

from AngProj a, ProjPS b, AngPS c

where a.PersNr = c.PersNr

Damit wird jede Personalnummer von a mit der identischen von c zusammengefügt. Da beide Mehrfacheinträge haben, gibt es viele gleiche Tupel.

AND b.BezPS = c.BezPS

Dies führt zu einer Einschränkung bzgl. der Tupelmenge. Gestrichen werden die, bei denen b.BezPS ungleich c.BezPS ist:

b.BezPS: Im jeweiligen Projekt genutzte Programmiersprache.

c.BezPS: von der jeweiligen Person beherrschte Programmiersprache.

Es bleiben also nur die Tupel übrig, bei denen (persönliche) Programmiersprachenkompetenz und notwendige (Projekt-)Programmiersprachen übereinstimmern.

AND a.BezProj = b.BezProj

Wieder eine Einschränkung auf der Tupelmenge. Gestrichen werden nun die, bei denen a.BezProj ungleich b.BezProj ist:

a.BezProj: Projekt in dem die Person mitarbeitet.

b.BezProj: Projekt in dem die jeweilige Programmiersprache genutzt wird.

Es bleiben also nur die Tupel übrig, bei denen bzgl. persönlicher Programmiersprachenkompetenz und benötigter (Projekt-)Programmiersprache derselbe Eintrag vorliegt.

Diese Relation ist nicht in 5NF. Eine Zerlegung in weniger als drei Relationen ist ohne Semantikverlust nicht möglich.

Eine einfache Zerlegung durch Projektionen in drei Relationen führt zu den oben angeführten Relationen, allerdings nur mit den Daten, die den semantischen Anforderungen genügen.

Zum besseren Verständnis

Mit den Befehlen

create table angprojPS AS

select a.PersNr, a.BezProj, c.BezPS

from AngProj a, ProjPS b, AngPS c

where a.PersNr = c.PersNr

AND b.BezPS = c.BezPS

AND a.BezProj = b.BezProj

order by a.PersNr, b.BezProj, c.BezPS

erzeugen wir die Relation AngProjPS. Nun die Projektionen, die hier gleich als persistente Relationen angelegt wurden:

Projektion 1

PersNr

BezProj

1007

WebPl

1008

WebPl

1009

PPS

1010

PPS

Projektion 2

PersNr

BezPS

1007

MySQL

1007

PHP

1008

PHP

1009

C

1010

Cpp

Projektion 3

BezProj

BezPS

WebPl

MySQL

WebPl

PHP

PPS

C

PPS

Cpp

Nun der Join über diese drei Relationen:

select* from proj1 a, proj2 b, proj3 c

where a.PersNr=b.PersNr

and a.BezProj=c.BezProj

and b.BezPS=c.BezPS

PersNr

BezProj

PersNr

BezPS

BezProj

BezPS

1007

WebPl

1007

MySQL

WebPl

MySQL

1007

WebPl

1007

PHP

WebPl

PHP

1008

WebPl

1008

PHP

WebPl

PHP

1009

PPS

1009

C

PPS

C

1010

PPS

1010

Cpp

PPS

Cpp

Die identischen Attribute zeigen, dass die gewünschte Semantik voll erfüllt ist. Allerdings enthält diese Relation nicht alle Daten, die in unseren Ausgangsrelationen AngProj, AngPS und ProjPS vorhanden waren, sondern nur diejenigen mit der gewünschten Semantik. Die ursprüngliche Ausgangsrelation AngProjPS erfüllt also nicht die 5NF.

Letzte denkbare Normalform

Normalformen sind bezüglich einer Operation (bzw. bezüglich zweier in Beziehung stehender Operationen) definiert. Die hier betrachteten bezogen sich auf die oben vorgestellten Verbund/Projektion - Operationen. Date weist darauf hin, dass die 5NF die letzte denkbare Normalform bezüglich der Verbund/Projektion-Operationen ist [Date 1990, S. 390].

In der Praxis spielt die 5NF so gut wie keine Rolle. Eine Verbund-Abhängigkeit ist auch nicht ohne weiteres zu erkennen, denn selbst wenn alle Einträge einer Relation angegeben sind, und die vorliegenden Daten die oben angegebene Regel einhalten, muss sie ja nicht gelten.

Wenngleich es nicht immer sinnvoll ist, alle Normalisierungsschritte tatsächlich durchzuführen, verhilft die Kenntniss der Normalisierungstheorie doch zu einem besseren Datenmodell und zu einem tieferen Verständnis der attributbasierten Modellierung, die hier mit den Normalisierungsstufen einen ihrer Höhepunkte erlebt. Ein erheblicher Teil dessen, was Stammdatenkrisegenannt wird, ist auf inkompetente Normalisierung zurückzuführen.

Normalisierung - wie weit?

Auf jeden Fall ist die Realisierung der BCNF und die Verhinderung einer mehrfachen mehrwertigen Abhängigkeit zu empfehlen, so dass die 4NF immer sichergestellt ist.

Ganz aktuell und ganz anders: Im Bereich von BigData und NoSQL wird teilweise sogar auf elementare Normalisierungsschritte verzichtet. Grund ist die gewünschte hohe Verarbeitungsgeschwindigkeit. Voraussetzung ist eine entsprechende einfache Datenstruktur. Vgl. hierzu Kapitel 24.

NoSQL: Keine Normalisierung

Zum Nachdenken

Hier noch etwas zum Nachdenken und zum Überprüfen des Erkenntnigewinns: In [Date 1990, S. 558] finden sich folgende elegante Definitionen der drei höheren Normalformen:

A relation R is in BCNF if and only if every FD in R is a consequence of the candidate keys of R

A relation R is in 4NF if and only if every MVD in R is a consequence of the candidate keys in R

A relation R is in 5NF if and only if every JD in R is a consequence of the candidate keys of R.

Zur Erinnerung:

FD = functional dependency =funktionale Abhängigkeit = FA

MVD = multi-valued dependency =mehrwertige Abhängigkeit =MWA

JD= join dependency = Verbund-Abhängigkeit = VA

candidate key = (Sekundär)Schlüssel, Schlüsselkandidat

13.3 Regeln für die Erstellung relationaler Datenmodelle

Hier nun - kurz zusammengefasst - die aus dem obigen Text ableitbaren Regeln für die Erstellung relationaler Datenmodelle:

Jede Relation muss in 5NF sein. Dafür genügt meist ein Herbeiführen der 3NF und ein Prüfen, ob die BCNF erfüllt ist und ob keine mehrfachen mehrwertigen Attribute oder fehlerhafte Verbundabhängigkeiten vorliegen.

Die Zerlegungen im Rahmen der Normalisierung dürfen zu keinem Informationsverlust führen. D.h., es ist immer darauf zu achten, dass durch relationale Verknüpfungen entlang von Schlüsseln und Fremdschlüsseln die in der Ausgangsrelation vorhandene Information erhalten bleibt.

In jede Relation kommen nur die Attribute, die für alle Objekte Gültigkeit haben. Dies ergibt sich auch aus den Normalformen, soll aber nochmals deutlich gemacht werden (vgl. hierzu auch Kapitel 14 zum Muster Generalisierung / Spezialisierung). Es darf also keine semantisch bedingten Leereinträge geben. Ausnahmen sind Attribute zu Anfang und Ende bei zeitlichen Dimensionsangaben.

Normalerweise gibt es keine unterschiedlichen Relationen mit identischem Schlüssel. Ausnahmen sind Relationen im Rahmen einer Generalisierung / Spezialisierung (vgl. Abschnitt 14) und große Relationen mit sehr lückenhaften Daten. Hier greift man u.U. ganz pragmatisch zu einer Aufteilung, damit die Leereinträge nicht vervielfacht werden. Ein Beispiel könnte eine Relation zu Datenbanksystemen sein, bei der man alle "kaufmännischen" Attribute hat, aber nur sehr wenige technische. Dann könnte in DBS-Kfm und DSBS-Tech aufgeteiltt werden.

Wird dies alles realisiert, ist auch eine zentrale Regel des Datenbankentwurfs umgesetzt:

Jede (hier ja immer attributbasierte) Information darf in einer Datenbank nur einmal vorkommen.

14 Muster in Anwendungsbereichen und Modellen

Hier beginnt Teil IV: "Feintuning" und Vertiefung

mit den Kapiteln

14 Muster in Anwendungsbereichen und Modellen

15 Die Zeit in Datenmodellen und Datenbanken

In den obigen Kapiteln wurde der grundsätzliche Aufbau relationaler Datenmodelle vorgestellt. Bei der Erstellung von Datenmodellen für bestimmte Anwendungsbereiche muss dieses Instrumentarium eingesetzt werden. Dabei stößt man aber nicht nur auf einfache Strukturmerkmale, die sich problemslos in obiges abbilden lassen, sondern auch auf kompliziertere Strukturen , wie sie in realen Anwendungsbereichen eben vorliegen.

Diese erscheinen als Muster der Realwelt, die soweit wie möglich in Muster des relationalen Datenmodells abgebildet werden müssen. Semantik (der Realwelt/des Anwendungsbereichs) sucht Syntax (des relationalen Modells). Zum Beispiel folgende:

Semantik sucht Syntax

Enthaltensein von Objekten ineinander (eine Festplatte ist in einem PC enthalten)

Ähnlichkeit von Objekten (Objekte mit gemeinsamen Attributen: alle Angestellte, Entwickler, Haustechnikpersonal)

Existenzabhängigkeit (die einen Objekte können ohne die anderen nicht existieren, z.B. (wenn eingebaut) Chip und Motherboard in einem PC, usw.

Da diese Muster für die Objekte und deren datenbanktechnische Verwaltung große Bedeutung besitzen, werden sie auch in den Datenmodellen ausgedrückt. Sie sind in der semantischen und objektorientierten Modellierung größtenteils schon länger bekannt, werden aber in der relationalen Theorie meist nur unzureichend thematisiert.

14.1 Ähnlichkeit - Generalisierung / Spezialisierung

Es gibt Objekte in Anwendungsbereichen, die sich in vielen Attributen gleichen, in einigen aber nicht. Betrachten wir die Angestellten eines Unternehmens. Gemeinsam könnten sie die Attribute

Personalnummer (PersNr), Name, Vorname (VName), Abteilungsbezeichnung (AbtBez), Einstellungsdatum (EinstDat)

haben. Für die Entwickler wären noch die Attribute

Entwicklungsumgebung (EntwU), Programmiersprache (ProgSpr) (jeweils nur eine, die meist genutzte)

denkbar. Für das leitende Management könnte noch das

Entgeltmodell (Entgelt)

festgehalten werden.

Generalisierung / Spezialisierung (Gen/Spez)

Vgl. zur Herkunft der Begrifflichkeit [Staud 2019] bzw. die Literatur zur objektorientierten Theorie.

Wie bewältigt man ein solches Muster? Nimmt man alle Attribute zusammen in eine Relation, gibt es für Nicht-Entwickler und Nicht-Manager Attribute, die nicht belegt werden können ("semantisch bedingte Leereinträge", vgl. dazu das Dozentenbeispiel am Schluss des Abschnitts). Das ist eine höchst unzulängliche Struktur in (attributbasierten) Dateien und Datenbanken. In der semantischen Modellierung und in der objektorientierten Theorie wurde deshalb für dieses Muster die sog. Generalisierung / Spezialisierung (Gen/Spez) entwickelt. Diese kann in die relationale Theorie übernommen werden. Sie besteht hier darin, für alle gemeinsamen Attribute eine eigene Relation anzulegen, das wäre die sog. Generalisierung, und für die Attribute der jeweiligen spezialisierten Gruppen eine eigene, die Spezialisierungen. In unserem Beispiel entstehen damit folgende Relationen:

Angestellte (#PersNr, Name, VName, AbtBez, EinstDat)

Entwickler (#PersNr, EntwU, ProgSpr)

TopManagement (#PersNr, Entgelt)

Als Schlüssel wird jeweils PersNr genommen. Auf diese Weise erhält man Relationen, bei denen für jedes Objekt und jedes Attribut eine Attributsausprägung vorliegen kann, es braucht also keine semantisch bedingten Leereinträge geben.

Ein abstraktes Beispiel

Im folgenden Beispiel gehen wir von einer Standardsituation in Modellierungsprojekten aus: Mehrere Relationen liegen vor und plötzlich "entdeckt" man, dass sie gemeinsame Attribute haben. Betrachten wir die drei Relationen R1, R2 und R3 mit den angeführten Attributen:

Gemeinsame Attribute entdecken

R1 (#A1, A2, A3, A4, A5)

R2 (#A1, A2, A3, A6, A7, A8)

R3 (#A1, A2, A3, A6, A9, A10)

Offensichtlich haben die drei Relationen die Attribute A1, A2 und A3 gemeinsam, während ihre übrigen Attribute verschieden sind. In einem solchen Fall wird man die gemeinsamen Attribute in eine eigene Relation tun, die "oberste" Generalisierung. Sie soll R4 genannt werden.

R4 (#A1, A2, A3)

Das macht ein weiteres Motiv für die Gen/Spez deutlich: Ein bestimmtes Attribut soll nur einmal im Datenmodell und dann in der Datenbank auftauchen und nicht mehrfach. R4 stellt die Generalisierung der anderen drei Relationen dar. Diese behalten den Schlüssel, verlieren aber die übrigen gemeinsamen Attribute:

"Sparsame" Modellierung

R1 (#A1, A4, A5)

R2 (#A1, A6, A7, A8)

R3 (#A1, A6, A9, A10)

Diese drei Relationen stellen damit Spezialisierungen dar. Grafisch lässt sich dieses Datenmodell wie in der folgenden Abbildung ausdrücken. Die grafische Notation für dieses Muster hat kein eigenes grafisches Element, wie dies bei Entity Relationship - Modellen (ERM) und in Klassendiagrammen der objektorientierten Theorie der Fall ist. Man erkennt sie nur daran, dass die Relationen denselben Schlüssel haben und an den Min-/Max-Angaben zwischen diesen.

Abbildung 14.1-1: Generalisierung / Spezialisierung - Abstrakt

Betrachtet man die textliche Fassung dieses Datenmodells genauer, bemerkt man, dass R2 und R3 ein weiteres Attribut gemeinsam haben, R6. Dies erfordert eine weitere Zerlegung. Das gemeinsame Attribut wird nach R5 ausgelagert. R5 ist dann Spezialisierung von R4 und Generalisierung von R2 und R3. Insgesamt gilt damit:

Gleichzeitig Generalisierung und Spezialisierung

Generalisierung aller Relationen, "oberste" Generalisierung:

R4 (#A1, A2, A3)

Spezialisierung von R4:

R1 (#A1, A4, A5)

Spezialisierung von R4, Generalisierung von R2 und R3:

R5 (#A1, A6)

Spezialisierungen von R5:

R2 (#A1, A7, A8)

R3 (#A1, A9, A10)

Vererbung “relational”

Obige textliche Darstellung zeigt die Aufteilung der Attribute auf die Relationen. Die folgende Abbildung klärt den Zusammenhang zwischen den Relationen. Die evtl. nötige Verknüpfung erfolgt über die Primärschlüssel. Benötigt nun eine Anwendung oder Auswertung, die auf R2 fokussiert auch die Attribute von R5 und R4 bzw. deren Ausprägungen, kann sie sich diese durch die relationele Verknüpfung von den dortigen Relationen holen. Vgl. dazu das Beispiel am Abschnittsende. Diese Technik nennt man in der objektorientierten Theorie Vererbung (die obere Relation "gibt" den "unteren" ihre Attribute im Bedarfsfall). Vgl. [Staud 2019, Abschnitt 6.6].

Attribute weiterreichen, per SQL

Die Primärschlüssel der Generalisierungen und Spezialisierungen stehen in folgendem Verhältnis zueinander: Die oberste Generalisierung enthält alle Schlüsselausprägungen. Jede ihrer Spezialisierungen enthält eine Teilmenge davon. Dies ist in der nächsten Abbildung auch durch die Wertigkeiten ausgedrückt. Die Kardinalität ist 1:1, die Min-/Max-Angaben sind 0,1 und 1,1 da nicht jedes Objekt der Generalisierung an einer bestimmten Spezialisierung teilnehmen muss, umgekehrt aber jedes Objekt der Spezialisierung verknüpft sein muss. Auch R5 als Generalisierung enthält alle Schlüsselausprägungen von R5, R3 und R2, die beiden letztgenannten aber nur Teilmengen von R5.

Mengen und Teilmengen

Abbildung 14.1-2: Generalisierung / Spezialisierung – Zweistufig und abstrakt

Bleiben noch zwei Fragen:

Überlappen sich die Spezialisierungen (ist ihre Teilmenge nicht leer) oder tun sie es nicht (Überlappung).

Decken die Spezialisierungen alle Ausprägungen der Generalisierung ab, ist also die Vereinigungsmenge der Spezialisierungen gleich der Generalisierung, oder ist sie es nicht (Überdeckung).

Beides muss bedacht und (bei Abfragen, Auswertungen) berücksichtigt werden, schlägt sich aber im Datenmodell nicht nieder. Eine Detailbetrachtung hierzu findet sich für die objektorientierte Modellierung in [Staud 2019, Abschnitt 6.4].

Beispiel Dozenten

Das folgende Beispiel soll den Sachverhalt noch deutlicher machen und auf das Problem der semantisch bedingten Leereinträge hinweisen. Im Rahmen der Modellierung einer Hochschule habe sich für die Dozenten folgende Relation ergeben:

Dozenten (#DozNr, Name, VName, Raum, IntDozTel, IntDozSpr
ExtDozOrt, ExtDozStr, E-Mail, ExtDozTelOrg, ExtDozTelPriv, ExtDozOrg)

DozNr: Dozentennummer

VName: Vorname

IntDozTel: Telefonnummer des internen Dozenten

IntDozSpr: Sprechstunde des internen Dozenten

ExtDozOrt:: Wohnort des externen Dozenten)

ExtDozStr: Straße der Adresse des externen Dozenten

E-Mail: Mailadresse des internen oder externen Dozenten

ExtDozTelOrg: Telefonnummer des externen Dozenten an seinem Arbeitsplatz ("Organsiation")

ExtDozTelPriv: Private Telefonnummer des externen Dozenten.

ExtDozOrg: Organisation, in der der externe Dozent arbeitet.

Die Attribute mit "Int..." beziehen sich also auf die internen Dozenten, die mit "Ext..." auf die externen. In einer so gestalteten Relation wird es immer semantisch bedingte Leereinträge geben. Beschreibt ein Tupel einen internen Dozenten, können nur die Attribute Ausprägungen erhalten, die interne Dozenten beschreiben. Umgekehrt gilt dasselbe. Attribute für externe Dozenten erhalten nur Ausprägungen, wenn das betreffende Tupel auch externe Dozenten beschreibt. Lediglich die Attribute, die beide Dozententypen beschreiben, erhalten immer (für alle Tupel) Ausprägungen.

Semantisch bedingte Leereinträge

Die folgende Abbildung möchte dies veranschaulichen. Die Dozenten 1001 bis 1003 sind externe Dozenten, die übrigen interne. Ein "x" bedeutet, dass semantisch ordnungsgemäße Einträge an der jeweiligen Stelle möglich sind. Fragezeichen bedeuten, dass dies nicht möglich ist. Sind da Einträge, sind sie falsch, weil Attribute beschrieben werden, die es für die jeweilige Gruppe nicht gibt.

Abbildung 14.1-3: Generalisierung / Spezialisierungung – Semantisch bedingte Leereinträge

Eine solche Struktur wird in der Datenmodellierung durch die oben eingeführte Generalisierung / Spezialisierung aufgelöst. Dazu wird die Relation zerlegt. Die Attribute für beide Dozententypen kommen in eine Relation (die Generalisierung), die für die externen und internen Dozenten jeweils in eine andere (Spezialisierungen):

Dozenten (#DozNr, Name, VName, Raum, E-Mail)

DozIntern (#DozNr, IntDozTel, IntDozSpr)

DozExtern (#DozNr, ExtDozOrt, ExtDozStr, E-Mail, ExtDozTelOrg, ExtDozTelPriv, ExtDozOrg)

Vgl. zu diesem Thema auch die Beispiele in den Kapiteln 16 und 17, insbesondere Sprachenverlag.

Damit entstehen drei Relationen, die keine der oben beschriebenen Lücken aufweisen. Im Bedarfsfall müssen aber, z.B. für Auswertungen, die Attribute der Generalisierung mit denen einer Spezialisierung zusammengebracht werden. Dies geschieht über den Schlüssel, der ja in der Generalisierung und in allen Spezialisierungen gleich ist.

Anwendungsbereich Fahrzeuge aller Art

Das folgende Beispiel zeigt eine Generalisierung / Spezialisierung mit zahlreichen Ebenen. Es soll um ein Unternehmen gehen, das Fahrzeuge aller Art vermietet. Folgende Attribute werden für die Fahrzeugtypen erfasst:

Für alle Fahrzeuge: Tag der Anschaffung (TagAnsch), Preis, nötiger Führerschein zum Fahren des Fahrzeugs (Führerschein)

Zusätzlich für die einzelnen Untertypen:

Für PKW: Motorart (Diesel, Benziner, Elektro, Hybrid, Wasserstoff, …), Motorstärke (PS). Hierunter fallen Limousinen, Cabriolets (Dach fest oder flexibel: Dachart), Sportwagen (Beschleunigung von 0 auf 100: Beschl) und Familienautos (Zahl der Sitzplätze)

für LKW: Getriebeart (Getriebe)

Für Busse: Zahl der Sitzplätze (Plätze)

Für Kettenfahrzeuge: bewältigbare Steigung (Steigung)

Für militärische Kettenfahrzeuge: mit oder ohne Bewaffnung (Waffejn). Hier wird außerdem festgehalten, ob es sich um Kampfpanzer (für diese wird Feuerkraft erfasst) oder um Brückenlegepanzer (für diese wird Brückenlänge erfasst) handelt.

Für zivile Kettenfahrzeuge: Schiebekraft (wieviel Erde sie maximal wegschieben können)

Folgendes gehört nicht zum Muster Gen/Spez, dient nur zur Abrundung.

Die Ausleihe eines jeden Fahrzeugs wird mit Beginn (Tag der Ausleihe) und Ende (Tag der Rückgabe) festgehalten. Es versteht sich, dass ein Kunde öfters ein Fahrzeug ausleihen kann und dass ein Fahrzeug im Zeitverlauf möglichst oft ausgeliehen werden soll. Nach jeder Rückgabe des Fahrzeugs durch einen Kunden wird der Fahrzeugzustand festgehalten (ZustandF). Die Ausprägungen sind tadellos, normal, beschädigt, schwer beschädigt, funktionsunfähig. Ziel ist hier, die Historie der Zustandsentwicklung festzuhalten. Von den Ausleihern werden die Adressangaben (nur eine Adresse) erhoben (Name, Vorname, PLZ, Ort, Straße, Telefon). Sie erhalten außerdem einen Status, der folgende Ausprägungen haben kann: Neukunde (0), langjähriger solider Kunde (1), nicht solider Kunde (2).

Die folgende Tabelle ordnet die Attribute den Fahrzeugtypen zu.

Attribute zu Fahrzeugtypen

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

Fahrzeuge

x

x

x

x

x

PKW

x

x

x

x

x

x

x

LKW

x

x

x

x

x

x

Busse

x

x

x

x

x

x

Kettenfahrzeuge

x

x

x

x

x

x

Familienautos

x

x

x

x

x

x

x

x

Sportwagen

x

x

x

x

x

x

x

x

Cabriolets

x

x

x

x

x

x

x

x

Kettenfahrzeuge Zivil

x

x

x

x

x

x

x

Kettenfahrzeuge Militärisch

x

x

x

x

x

x

x

Kampfpanzer

x

x

x

x

x

x

x

x

Brückenlegepanzer

x

x

x

x

x

x

x

x

Anmerkung: Ein x bedeutet, dass das Attribut für den jeweiligen Fahrzeugtyp Bedeutung hat.

Attribute der Spaltenüberschriften:

1 Nr

2 FZTyp (Typ des Fahrzeugs)

3 TagAnsch (Tag der Anschaffung)

4 Preis (Preis des Fahrzeugs)

5 Führerschein (Benötiger Führerschein)

6 PS (Motorleistung, heute in kW gemessen)

7 Motarart (Art des Motors)

8 Getriebe (Art des Getriebes)

9 Plätze (Anzahl der Sitzplätze)

10 Steigung (Höchste bewältigbare Steigung)

12 Beschl (Beschleunigungsvermögen des Fahrzeugs, von 0 auf 100)

13 Dachart (Art des Daches)

14 Schiebekraft (Größte durch das Fahrzeug verschiebbare Menge an Erde)

15 WaffeJN (Waffenausstattung ja/nein)

16 Feuerkraft (Feuerkraft des Geschützes)

17 Brückenlänge (Länge der ausklappbaren Brücke)

Lösung 1 (textlich)

Als oberste Generalisierung ergibt sich die Relation Fahrzeuge mit den für alle Fahrzeugen gültigen Attributen:

Fahrzeuge (#Nr, FZTyp, TagAnsch, Preis, Führerschein)

FZTyp (Fahrzeugtyp): Ein solches Attribut, das die Zugehörigkeit zu einer Spezialisierung zeigt, ist zwar optional, aber sinnvoll. Es erleichtert die SQL-Abfragen entlang der Gen/Spez-Hierarchie.

Die folgenden vier Relationen sind Spezialisierungen von Fahrzeuge mit jeweils zusätzlichen Attributen.

PKW (#Nr, PS, Motarart)

LKW (#Nr, Getriebe)

Busse (#Nr, Plätze)

Kettenfahrzeuge (#Nr, Steigung)

PKW und Kettenfahrzeuge sind gleichzeitig auch Generalisierungen für weitere Relationen. PKW für die folgenden:

Familienautos (#Nr, Sitzplätze)

Sportwagen (#Nr, Beschl)

Cabriolets (#Nr, Dachart)

Kettenfahrzeuge für:

KettenfahrzeugeZivil (#Nr, Schiebekraft)

KettenfahrzeugeMilitärisch (#Nr, WaffeJN)

Die Relation KettenfahrzeugeMilitärisch hat die Spezialisierungen:

Kampfpanzer (#Nr, Feuerkraft)

Brückenlegepanzer (#Nr, Brückenlänge)

Nicht zur Generalisierung / Spezialisierung gehören die Relationen Ausleiher und Ausleihe:

Ausleiher (#Nr, Name, Vorname, PLZ, Ort, Straße, Telefon, Status)

Ausleihe (#(KNr, FahrzNr, Beginn), Ende, ZustandF)

Erinnerung: Ein Schlüssel einer Spezialisierung enthält eine Teilmenge der Schlüsselausprägungen des Schlüssels der Generalisierung.

Die folgende Abbildung zeigt die grafische Lösung. Hier wird die gestufte Gen/Spez-Hierarchie besonders deutlich. Für eventuelle Auswertungen werden die Tupel der Relationen über den Schlüssel zusammengebracht. Mittels SQL können natürlich beliebige Relationen verknüpft werden (vgl. Kapitel 19), allerdings wird die Menge der gemeinsamen Tupel nur dann nicht leer sein, wenn die Abfrage entlang einer bestimmten Generalisierung / Spezialisierung liegt.

Abbildung 14.1-4: Muster Gen/Spez – mehrstufig am Beispiel Fahrzeuge

Zusammengefasst

Die Generalisierung / Spezialisierung klärt die sinnvolle Speicherung von Relationen, die zwar viele Attribute gemeinsam haben, einige aber nicht. Zusammen mit dem Schlüssel werden alle gemeinsamen Attribute in einer Relation erfasst (Generalisierung). Die Spezialisierungen kommen mit ihren spezifischen Attributen und dem Schlüssel ebenfalls in jeweils eine Relation.

14.2 Einzel- und Typinformation

In Kapitel 3 und insbesondere in Abschnitt 3.4 wurde gezeigt, wie einzelne Objekte zu Objektklassen zusammengefasst werden. In einer Klasse sind dann Objekte, die genau dieselben Attribute besitzen. Diese werden dann in der Datenbank verwaltet. Jedes Attribut beschreibt somit alle einzelnen Objekte der Klasse, jedem Objekt kann eine Attributsausprägung zugewiesen werden. Nun gibt es aber Situationen in Anwendungsbereichen, wo der Klasse als Ganzes ebenfalls Attribute und Attributsauswertungen zugewiesen werden müssen. Insgesamt liegen dann Attribute für die Einzelobjekte und für die Objektklasse vor.

Attribute für die Einzelobjekte und die Klasse

In der objektorientierten Theorie wird dieses Muster durch die sog. Klassenattribute erfasst. Vgl. [Staud 2019, Abschnitt 2.3].

Dieses Muster – es wird hier Einzel/Typ-Muster genannt – ist in den Anwendungsbereichen ständig präsent und muss dementsprechend auch in den Datenmodellen der Anwendungsbereiche umgesetzt werden. Leider wird es oft übersehen, was zu Redundanz in den Datenbeständen führt. Seine Grundlage ist also, dass es Objekte (aller Art) gibt, die sich sehr ähneln und die demzufolge gleiche Attribute haben (Tiere einer Gattung, technische Geräte eines Typs, Menschen einer Gruppe,...), bei denen aber auch gleichzeitig die Gattungen / Gerätetypen / Menschengruppen Attribute aufweisen.

Je nach Anwendungsbereich und Objekttyp wird die Gesamtheit aller Objekte auf abstrakte Weise unterschiedlich benannt: Ganz allgemein und zurückgreifend auf die objektorientierte Theorie Klassen (Objektklassen). Falls es sich um Tiere handelt Gattungen, bei Geräten Typen (Gerätetypen), bei Menschen Gruppen, usw.

Will man bei solchen Objekten die Informationen der einzelnen Objekte mit denen der Klasse ergänzen und fügt man diese einfach der Relation mit den Einzelinformationen hinzu, ist dies redundant. Einige Beispiele:

In einem Zoo werden evtl. die einzelnen Tiere (Schimpanse Eddi, Orang Utan Franz, Elefant Paul, ...) durch Attribute erfasst, zum anderen auch die Gattungen (Schimpansen, Orang Utans, Elefant der Gattung, ...). Natürlich nur für Großtiere, die als Individuen in Erscheinung treten.

In der Technik wird in bestimmten Situationen das einzelne Stück erfasst (einzelne Kraftfahrzeuge, Festplatten, Flugzeugersatzteile, ...), zum anderen auch die gleichartigen Gruppen (Kraftfahrzeuge, Festplatten, Flugzeugersatzteile eines Typs, ...).

Bei Menschen wird oftmals der einzelne Mensch erfasst (mit Personalnummern, Namen, usw.) und auch die Gruppe, zu der er gehört (Mitarbeiter IT, Leiharbeiter, Leitendes Management, ...).

Liegt eine solche Situation vor, gibt es drei Möglichkeiten:

In der Datenbank und damit im Datenmodell werden nur Attribute zu den einzelnen Objekten erfasst. Dann gibt es eine Relation zu diesen und alles ist in Ordnung. Das entspricht der Standardsituation.

Es werden nur Attribute zur Klasse (Typ, Gattung, Gruppe) erfasst. Dann gibt es eine Relation zu diesen und die Sache ist ebenfalls geklärt. Lediglich bei einer eventuellen relationalen Verknüpfung mit einer anderen Relation muss aufgepasst werden. Vgl. dazu die Beispiele unten.

Zu beidem, zu den einzelnen Objekten und zur Klasse sind Attribute zu erfassen. Dann müssen zwei Relationen angelegt werden (eine für die einzelnen Objekte, eine für die Klasse) und die Attribute müssen auf diese aufgeteilt werden. Attribute, die einzelne Objekte beschreiben, kommen in die Relation mit den Einzelinformationen. Beschreiben sie die Klasse als Ganzes, kommen sie in eine Relation mit den Typinformationen. Vgl. dazu die folgenden Beispiele.

Es gibt also in der Datenbank u.U. einzelne Objekte, zum anderen aber auch die Zusammenfassung gleichartiger Objekte. Die Zusammenfassung wird hier einheitlich für alle im jeweiligen Bereich üblichen Bezeichnungen (Typ, Gattung, Gruppe, usw.) Typ genannt. Das Muster soll dann Einzel/Typ-Muster genannt werden.

Muster Einzel/Typ

Beispiel: Zootiere - einzeln und als Gattung

Die folgende Abbildung zeigt das Muster in einem Anwendungsbereich, in dem es um Tiere geht, z.B. in einem Zoo. Die Tiergattungen des Zoos könnten aus Schimpansen, Orang Utans, Elefanten usw. bestehen. Für sie wird die Relation TiereGattung mit den Attributen Bezeichnung (Bez), Anzahl der Mitglieder (Anzahl), einer Angabe zur Klassifikation (Klassif) und Hinweisen zur Art der Unterbringung (ArtUnt) erfasst. Für die einzelnen Tiere in der Relation TiereEinzeln gibt es eine Tiernummer (TNr), einen Namen (Name), den Geburtstag (GebTag), das Geschlecht und die Nummer des Gebäudes, in dem sie untergebracht sind (GebNr). Zur Verbindung der beiden Relationen wird die Gattungsbezeichnung in TiereEinzeln aufgenommen. Diese beiden Relationen beschreiben den Sachverhalt absolut redundanzfrei.

Abbildung 14.2-1: Muster Einzel/Typ zu Zootieren

Muster Einzel/Typ bei technischen Teilen

Im folgenden Beispiel soll es um hochwertige technische Teile gehen, z.B. Ersatzteile für Flugzeuge, für Kraftwerke, usw. Auf jeden Fall um Teile, die auch einzeln identifiziert werden und nicht nur als Typen, wie es in diesen Anwendungsbereichen ja meist der Fall ist.

Für die einzelnen Teile (Relation Teile-Einzeln) wird eine Teilenummer (TeilNr), das Datum der Beschaffung (DatBesch), der Lieferantenname (LiefName; es gibt also unterschiedliche Lieferanten für die einzelnen Teile eines Typs) erfasst. Für die Teiletypen die Typbezeichnung (TeilBez), die Anzahl der für den Typ vorhandenen einzelnen Teile (Anzahl) und der minimale Lagerbestand, der für den Typ vorgehalten wird (MinLag).

Abbildung 14.2-2: Muster Einzel/Typ am Beispiel Teile

Muster Einzel/Typ bei Festplatten (mit Einbindung ins Datenmodell)

Das folgende Beispiel ist auch aus dem technischen Bereich (Festplatten). Es zeigt zusätzlich, wie diese "Muster-Information" mit dem übrigen Datenmodell verknüpft wird.

Die einzelnen Festplatten (Relation FP-Einzeln) werden durch eine Seriennummer (SerNr), das Datum des Einbaus der Festplatte (DatEinbFP) und das Ergebnis der letzten Fehlerprüfung (FehlPrüf) beschrieben. Die Festplattentypen (FP-Typen) durch die Bezeichnung (PlBez), die Speicherkapazität (Größe) und die Zugriffsgeschwindigkeit (Zugriff). Die Verknüpfung der beiden Relationen geschieht wieder durch die Übernahme des Schlüssels der Typ-Relation als Fremdschlüssel in die Einzeln-Relation. Hier als PlBez nach FP-Einzeln.

Die Verknüpfung mit dem Rest des Datenmodells – hier zur Relation PC – erfolgt in der Regel über die Relation mit den einzelnen Objekten, hier FP-Einzeln. Hier soll die Semantik so sein, dass ein PC mehrere Festplatten haben kann und eine bestimmte Platte in genau einen PC eingebaut ist. Dann ergibt sich die relationale Verknüpfung so, wie es die folgende Abbildung im unteren Teil zeigt: InvPC wird Fremdschlüssel in FP-Einzeln.

Verknüpfung

Der untere Teil der Abbildung zeigt die Min-/Max-Angaben 0,n auf der Seite von FP-Typen. Dies bedeutet, dass wir einen neuen Festplattentyp gefunden haben (sehr viel Speicherplatz, besonders schneller Zugriff,…), den wir erfassen, aber noch nicht einbauen.

Abbildung 14.2-3: Muster Einzel/Typ mit Verknüpfung ins Datenmodell

Verknüpfung mit Typinformation

Das folgende Beispiel zeigt eine Verknüpfung mit Typinformationen. Die PCs seien über die Relation

Ungenaue relationale Verknüpfung

PC (#InvPC, Proz, ArbSp, LWjn)

erfasst.

Optische Laufwerke sind - erkennbar am Schlüssel - per Typbezeichnung erfasst. Dies bedeutet, hinter einer Bezeichnung können viele Einzelgeräte stehen. Ist dann die Semantik so, dass ein PC mehrere optische Laufwerke haben kann (ein bestimmter Laufwerkstyp kann ja sowieso in vielen PC sein) ergibt sich folgende Lösung:

OptLwPC (#(LWBez, InvPC))

Dies hält fest, wieviele Laufwerkstypen in einem PC enthalten sind. Will man auch die Anzahl der einzelnen Geräte erfassen, muss eine Ergänzung vorgenommen werden:

OptLwPC (#(LWBez, InvPC), Anzahl)

Abbildung 14.2-4: Verknüpfung mit Typinformation am Beispiel Optische Laufwerke

InvPC: Inventarnumme des PC (eindeutig)

Proz: Prozessorbezeichnung

ArbSp: Größe des Arbeitsspeichers

LWjn: Laufwerk vorhanden? (Ja/Nein)

LWBez: Laufwerkbezeichnung

Geschw: Geschwindigkeit des Laufwerks.

Anzahl: Anzahl der Laufwerke im PC

14.3 Enthaltensein - Aggregation

Hier geht es um das Muster, das in der semantischen Datenmodellierung und in der objektorientierten Theorie Aggregation genannt wird. Es drückt aus, dass ein Objekt in einem anderen enthalten ist. Es drückt nicht Existenzabhängigkeit aus, das ist Aufgabe der Komposition, die im nächsten Abschnitt beschrieben wird.

Typisch für dieses Muster ist, dass die enthaltenen Teile eine eigene Existenz besitzen. Das kann auf zweierlei Weise modelliert werden. Entweder betrachtet man die Komponenten auf Typ-Ebene oder als individualisierte Komponenten. Die folgenden Beispiele rund um die Welt der PCs mögen dies verdeutlichen.

Anwendungsbereich PC – Aggregation mit individualisierten Komponenten

Hier soll es um Komponenten gehen, mit denen ein PC ausgestattet werden kann und die mit ihm fest, aber nicht untrennbar (vgl. dazu das Muster Komposition im nächsten Abschnitt) verbunden sind. Also z.B. Grafikkarten, interne Festplatten. Die Komponenten sind individualisiert, d.h. sie haben jeweils einen Schlüssel.

Komponenten auf Typebene

Die folgende Abbildung zeigt das (kleine) Datenmodell. Es gibt eine Relation PC und eine PCKomp für die Komponenten. InvNr bedeutet jeweils Inventarnummer. Sind PC und Komponenten die Ausgangsrelationen, muss die Aggregation durch eine eigene Relation PCKomp ausgedrückt werden:

PCKomp (#InvNrKomp, InvNrPC)

Damit kann die Komponente in Komponenten auch „existieren“, falls sie nicht mehr in einen PC eingebaut ist.

Abbildung 14.3-1: Muster Komposition mit individualisierten Komponenten

Anwendungsbereich PC - Komponenten auf Typebene

Auch hier soll es wieder um die Ausstattung jedes einzelnen PCs mit Komponenten gehen, die Komponenten sollen aber nur über ihre Bezeichung ("Grafikkarte xyz"), also auf Typebene, erfasst werden. Damit verändert sich die Relation zu den Komponenten:

Komponenten-Typen (#BezKomp, Funktion) //BezKomp : Bezeichnung Komponente

Dann ergibt sich die unten angegebene Lösung. Die Agregation wird durch die Relation PCKomp wie folgt ausgedrückt:

PCKomp (#(InvNrPC, BezKomp))

Ein PC kann also mehrere Komponenten zugeordnet bekommen, eine Komponente („Festplatte IBM 123“) kann mehreren PCs zugeordnet werden. Diese Modellierung auf Typebene ist allerdings ungenau, da die konkrete Anzahl von Komponenten des gleichen Typs so nicht erkannbar ist. Sollte auch dies ausgedrückt werden, müßte die Anzahl (z.B. der „Typ-gleichen“ Festplatten ) noch angegeben werden:

PCKomp (#(InvNrPC, BezKomp), Anzahl)

Abbildung 14.3-2: Muster Aggregation mit Komponenten auf Typebene

Anwendungsbereich Teile / rekursiv

Eine oftmals vorkommende Aggregation ist die rekursive Beziehung von (technischen) Teilen, die andere Teile enthalten, und dies auf mehreren Ebenen. Zur Veranschaulichung stelle man sich ein Gerät vor, z.B. ein Fahrrad oder ein Flugzeug. Das ganze Gerät besteht aus Grobkomponenten, jede dieser aus Subkomponenten, usw., bis man bei elementaren Komponenten angekommen ist. Eine solche Zusammenstellung von Komponenten mit den in ihnen enthaltenen Subkomponenten ist Grundlage von Stücklisten.

Enthaltensein

Die folgende Abbildung zeigt ein Beispiel. Die Relation für das Enthaltensein wird TeileEnth genannt. Sie stellt Teile in Beziehung: Teile mit „A“ (TeilNrA) enthalten Teile mit „B“ (TeilNrB), Anzahl gibt an, wieviele. Das Ganze ist mehrstufig, auch in den Beispielsdaten.

Relation Teile-Enth

TeilNrA

TeilNrB

Anzahl

K1001

K1005

1

K1001

K1006

1

K1002

K1006

1

K1002

K1007

2

K1003

K1008

2

K1005

K1009

1

K1005

K1010

1

...

Die Semantik („TeilNrB ist in TeilNrA enthalten“) muss im Anwendungsprogramm hinterlegt sein. Die folgende Abbildung zeigt diese Relation und ihre Anbindung an eine i.d.R. notwendige Relation, mit der die Teile beschrieben werden (Teile).

Abbildung 14.3-3: Muster Aggregation am Beispiel einer rekursiven Beziehung

Wie man sehen kann, drückt das Datenmodell nicht sehr viel von der Semantik der mehrstufigen rekursiven Beziehung aus, so dass tatsächlich der Hauptanteil der Semantik durch das Anwendungsprogramm umgesetzt werden muss.

14.4 Enthaltensein und Existenzabhängigkeit - Komposition

Bei diesem Muster geht es auch um Enthaltensein, wie bei der Aggregation, allerdings sind die enthaltenen Teile untrennbar mit dem übergeordneten Teil verbunden. Zumindest datenbanktechnisch aber manchmal auch ganz real im Anwendungsbereich sind die enthaltenen Teile existenzabhängig vom "Ganzen": Wird ein"Ganzes" gelöscht, verschwinden auch die Komponenten. Am leichtesten kann man sich dies an den Anwendungsbereichen Rechnungsstellung und Gebäude vorstellen:

Wird der Rechnungskopf gelöscht, verschwinden auch die Rechnungspositionen

Wird das Gebäude aus der Datenbank genommen, z.B. weil es verkauft wurde, müssen auch die zugehörigen Büros herausgenommen werden (falls sie datenbanktechnisch erfasst waren).

Typisch für alle Varianten ist, dass der Schlüssel der übergeordneten Relation als Schlüsselattribut und Fremdschlüssel in die untergeordnete eingefügt wird.

Anwendungsbereich Rechnungsstellung

Das klassische Beispiel für dieses Muster ist die Beziehung zwischen Rechnungsköpfen (ReKöpfe) und Rechnungspositionen (RePos) der jeweiligen Rechnung. Sie gehören untrennbar zusammen und die Rechnungspositionen verschwinden auch, wenn die Rechnung aus der Datenbank gelöscht wird.

Modelliert werden kann dies wie im folgenden Beispiel gezeigt. RePos erhält einen zusammengesetzten Schlüssel, bestehend aus Rechnungsnummer (ReNr) und Positionsnummer (PosNr). ReNr ist gleichzeitig auch Fremdschlüssel.

Abbildung 14.4-1: Muster Komposition im Anwendungsbereich Rechnungsstellung

Anwendungsbereich PC

Hier soll es um Komponenten gehen, die mit dem PC fest verbunden sind und mit ihm (normalerweise) zu existieren aufhören. Z.B. die WLAN-Komponente, das Kartenlesegerät, usw. Diese sind datenbanktechnisch existent, haben also eine eigene Beschreibung, ausgedrückt durch Attribute. Die Modellierung erfolgt so, dass der Schlüssel der übergeordneten Relation PC zum Fremdschlüssel in der untergeordneten Relation Komponenten wird. Da ein Tupel ohne Fremdschlüsseleintrag nicht existieren kann, verschwinden die Einträge in Komponenten, wenn der entsprechende PC ausgemustert wird.

Vgl. das Modellbeispiel in Abschnitt 16.3

Abbildung 14.4-2: Muster Komposition im Anwendungsbereich PC

Ich weiß, dass die "Bastler" diese Komposition leicht zu einer Aggregation machen, indem sie z.B. eine solche Komponente eben doch ausbauen und woanders verwenden, hier soll aber mal - z.B. im Rahmen einer PC-Massenfertigung - von der Komposition ausgegangen werden.

Anwendungsbereich Zoo

Im folgenden Beispiel wird angenommen, dass es zu jedem (größeren) Tier des Zoos eine Tierakte gibt, die bei seiner Geburt entsteht und beim Tod vernichtet wird. Sie besteht aus einzelnen Einträgen, die durch eine Aktennotiznummer (AktNotizNr) identifiziert werden.

Das zugehörige Gesamtmodell Zoo wird in Abschnitt 17.6 vorgestell.

Dies kann durch das folgende Beispiel ausgedrückt werden. Neben der Relation zu den einzelnen Tieren gibt es auch eine zu den Tierakten mit dem angegebenen Schlüssel. Die Struktur des Schlüssels sichert die Existenzabhängigkeit. Gibt es eine bestimmte Tiernummer nicht mehr, müssen auch die entsprechenden Akteneinträge verschwinden.

Semantik sucht Syntax

Abbildung 14.4-3: Muster Komposition im Anwendungsbereich Zoo

Anwendungsbereich Sportverein

Das folgende Modellfragment stammt aus dem Beispiel Sportverein, vgl. Abschnitt 16.2. Es geht um Begegnungen von Mannschaften des Vereins mit anderen (fremden) Mannschaften. Dies könnte, wie unten gezeigt, modelliert werden. Da die zeitlichen Aspekte schon recht identifizierend wirken (eine Mannschaft kann zu einem Zeitpunkt nur gegen einen Gegner spielen) genügt es, die Mannschaftsnummer um den Tag und den Beginn der Begegnung zu ergänzen. Gegner und Ergebnis können außerhalb des Schlüssels platziert werden.

Zusätzliche Zeitaspekte

Auch bei dieser Konstruktion ist gesichert, dass die Begegnungen existenzabhängig sind von den Mannschaften. Würde zum Beispiel eine Mannschaft aufgelöst, müssten auch deren Begegnungen gelöscht werden.

Abbildung 14.4-4: Muster Komposition im Anwendungsbereich Sportverein

Anwendungsbereich Fachliteratur

In Abschnitt 16.4 wird eine Datenbank zu Fachliteratur vorgestellt. Erfasst werden alle Typen von Fachliteratur, auch Sammelbände und die einzelnen Beiträge in den Sammelbänden. Dabei gilt: Ein Sammelbandbeitrag (SBB) gehört zu genau einem Sammelband (SB). Existenzabhängigkeit ist auch gegeben. Wenn ein Sammelband aus der Datenbank genommen wird, muss auch jeder SBB gelöscht werden. Die folgende Abbildung zeigt dies und zusätzlich die Einbettung in das Modell:

Vgl. Abschnitt 16.1

Sammelbände (SB) sind eine Spezialisierung von Mono+SB (vgl. die Verknüpfung an Position 2), der Relation mit den gemeinsamen Attributen von Monographien (Mono) und Sammelbänden, vgl. Abschnitt 16.4.

Sammelbandbeiträge (SBB) eine von ZSA-SBB, der Relation mit den gemeinsamen Attributen von Zeitschriftenaufsätzen (ZSA) und Sammelbandbeiträgen, vgl. Abschnitt 16.4.

Der grau schraffierte Teil der Abbildung zeigt die Komposition (Position 1).

Abkürzungen:

Mono: Monographie

ZSA: Zeitschrifenaufsatz

WerkNr: Schlüssel von Werke (Überbegriff zu jeglicher Fachliteratur)

Vgl. auch Abschnitt 16.4

Die Semantik wird durch den Fremdschlüssel SBNr in der Relation SBB ausgedrückt und die Verknüpfung mit der WerkNr (vgl. Position 1). Damit ist modelltechnisch gesichert, dass die Tupel in SBB nur existieren, wenn die von SB vorhanden sind.

Semantik sucht Syntax

Abbildung 14.4-5: Muster Komposition im Anwendungsbereich Fachliteratur

14.5 Beziehungsattribute

Beziehungen zwischen Relationen (bzw. den dort erfassten Objekten) sind erst mal genau dies: Beziehungen (wie oben gesehen) . Sie verknüpfen (typischerweise) einen Schlüssel und einen Fremdschlüssel und drücken damit die Beziehung aus. Manchmal weisen sie aber zusätzlich auch Eigenschaften auf, die als Attribute modelliert werden müssen. Diese sollen Beziehungsattribute genannt werden.

Beziehungen mit Eigenschaften

Betrachten wir zuerst den Fall von zwei Relationen. Hier müssen der Beziehung diejenigen Attribute zugewiesen werden, die weder in die eine noch in die andere der verknüpften Relationen passen.

Zwei Relationen

1:1-Beziehungen

Beginnen wir mit 1:1-Beziehungen. Diese werden im Normalfall ja einfach durch Einrichtung eines Fremdschlüssels in einer der beiden Relationen realisiert. Liegen Beziehungsattribute vor, muss je nach Wertigkeiten vorgegangen werden.

1,1 : 1,1 0,1 : 1,1 0,1 : 0,1

Bei 1,1 : 0,1 (zum Beispiel Angestellte / PC: Jeder Angestellte hat einen zugwiesenen PC, ein PC ist höchstens einem Angestellten zugeordnet) werden die Beziehungsattribute (z.B. der Tag der Einrichtung) der Relation mit dem Fremdschlüssel zugeordnet:

Angestellte – PC

Angestellte (#PersNr, ..., InvNrPC, TagEinrichtung)

PC (#InvNrPC, ...)

Entsprechend wird das Beziehungsattribut für die Wertigkeiten 0,1 : 1,1 gelöst.

Für den Fall einer Beziehung mit den Wertigkeiten 0,1 : 0,1 entsteht ja sowieso eine neue Relation für die Verknüpfung. An diese kann das Beziehungsattribut angehängt werden:

AngPC (#PersNr, #InvNrPC, TagEinrichtung)

Die Schlüssel sind wirklich so, vgl. Abschnitt 5.3

In dieser Relation gibt es nur für jeden wirklich zugewiesenen PC einen Eintrag - und dieser wird um das zusätzliche Attribut TagEinrichtung ergänzt.

1:n-Beziehungen

Bei 1,1 : 1,n - Wertigkeiten können Beziehungsattribute ebenfalls an den Fremdschlüssel angehängt werden, d.h. sie kommen in die Relation, bei der der Schlüssel der anderen Relation nur eine Ausprägung je Objekt hat. Betrachten wir das Beispiel Angestellte - Abteilungen und nehmen wir als Beziehungsattribut den Beginn der Mitarbeit (Beginn) an. Dann ergibt sich die Lösung wie folgt:

Angestellte – Abteilungen

Angestellte (#PersNr, Name, VName, GebDatum, AbtNr, Beginn)

Abteilungen (#AbtNr, Bez, Standort)

Dieselbe Lösung wird bei 1,1 : 0,n gewählt.

Im Falle von 0,1 : 1,n und 0,1 : 0,n entsteht ja eine neue Relation für die Beziehung (vgl. Abschnitt 5.5). Dieser können die Beziehungsattribute zugewiesen werden. Im hier gewählten Beispiel wäre dies die Relation Abteilungszugehörigkeit (AbtZug):

0,1 : 1,n und 0,1 : 0,n

Angestellte (#PersNr, Name, VName, GebDatum)

Abteilungen (#AbtNr, Bez, Standort)

AbtZug (#(AbtNr, PersNr), Beginn)

N:m-Beziehungen

Im Fall von n:m-Beziehungen entsteht ja bei allen Wertigkeiten eine neue Relation, die Verbindungsrelation. In diese können die Beziehungsattribute eingefügt werden. Das folgende Beispiel mit den Wertigkeiten 0,n : 0,m möge dies erläutern. Studierende können keine, eine oder mehrere Prüfungen besuchen, Prüfungen können von keinem, einem oder mehreren Studierenden absolviert werden. Die Verbindungsrelation kann dann einfach um Beziehungsattribute wie Prüfungstag (PruefTag), Note und Prüfungsnummer (PruefNr) ergänzt werden.

0,n : 0,m
1,n : 0,m
0,n : 0,m
0,n : 0.m

Abbildung 14.5-1: Muster Beziehungsattribute im Anwendungsbereich Hochschule

Auch bei der schon oft eingebrachten Beziehung zwischen Datenbanksystemen und Händlern, können Beziehungsattribute vorliegen. Im folgenden Beispiel sind dies der Marktpreis (MPreis) und der zur Verfügung gestellte Service. Er soll von beidem, dem Datenbanksystem und dem Händler abhängen. Dies bedeutet, dass ein Händler für unterschiedliche Datenbanksysteme unterschiedliche Serviceangebote anbietet.

Datenbanksysteme - Händler

Abbildung 14.5-2: Muster Beziehungsattribute im Anwendungsbereich Datenbanksysteme

Drei- und mehrstellige Beziehungen

Im Falle von mehr als zweistelligen Beziehungen werden die Beziehungsattribute der Verbindungsrelation zugewiesen. Betrachten wir als Beispiel den Anwendungsbereich Sportverein und die Beziehung Training, die Mannschaften, Trainer und Trainingsort in Beziehung setzt:

Mannschaften - Trainer – Trainingsort

Mannschaften (#MaNr, Bez, ...)

Trainer (#TrNr, Name, Vorname, ...)

Trainingsort (#OrtNr, Bez, Typ)

Für jedes Training sollen die Wertigkeiten 1,n : 1,3 : 1,1 gelten. D.h., an einem Training nimmt mindestens eine Mannschaft teil, es wird von maximal drei Trainern gestaltet und es findet immer an genau einem Ort statt (Stadion, Halle, Park, ...). Mit Hinzunahme des Tages und der Annahme, dass pro Tag nur ein Training stattfindet, ergibt sich:

Training (#(MaNr, TrNr, OrtNr, Tag))

Kommen nun Beziehungsattribute hinzu, hier Art (ArtTr) und Intensität (IntensTr) des Trainings, können diese in die Verbindungsrelation eingefügt werden:

Training (#(MaNr, TrNr, OrtNr, Tag), ArtTr, IntensTr))

15 Die Zeit in Datenmodellen und Datenbanken

15.1 Zeitlich fixiert oder zeitabhängig

In jeder Datenbank gibt es Daten, die von vorneherein zeitlich fixiert sind. Dies bedeutet, zum zugehörigen Datensatz (zum Tupel) gehört ein Attribut, das einen Zeitpunkt festhält. Zum Beispiel ...

Zeitlich fixiert

Bei einer Rechnung der Rechnungskopf mit seinem Datum

Bei einer Gewichtsmessung die Angabe des Messzeitpunktes

Beim Auftragseingang das Datum

Solche Einträge in die Datenbank behalten diese zeitliche Fixierung bis zum Ende der Datenbank und brauchen im weiteren nicht betrachtet werden. Wird diese Information vielleicht später wieder benötigt, ist sie da.

Die meisten Informationen haben aber diese zeitliche Fixierung nicht, sondern erfassen nur den aktuellen Informationsstand zum Zeitpunkt der Datenerfassung. Bei jedem erneuten Eintrag werden die früheren Daten überschrieben. Zum Beispiel bei einer Relation zu Artikeln in einem WebShop.

Nur der aktuelle Stand

Artikel (#ArtNr, Beschr, Preis)

Ändert sich dort z.B. der Preis eines Artikels, wird der alte überschrieben und steht (in der Datenbank) nicht mehr zur Verfügung. Genauso die Beschreibung, usw. Oder nehmen wir eine Kundenrelation:

Kunden (#KuNr, Name, VName, PLZ, ORT, Straße, Tel)

Hier können sich im Zeitablauf die Adressangaben ändern, auch die Telefonnummer und evtl. sogar der Name. Wenn einfach überschrieben wird, sind die alten Daten weg. Dies sind also zeitabhängige Daten. Bei ihnen muss geprüft werden, ob das "Verschwinden durch Überschreiben" akzeptiert werden kann. Oft kann man es deshalb nicht, weil der alte Zustand zum Zeitpunkt der Entstehung der Daten erhalten bleiben muss, z.B. aus steuerlichen Gründen. Dies kann Rechnungen, aber auch andere Geschäftsobjekte betreffen.

Zeitabhängige Daten

Früher wurden dafür Belege abgelegt und füllten ganze Archive, später und auch heute noch Faksimiles in DVD-Stapeln archiviert oder Datenbestände dupliziert. Andere Lösungen wurden für NoSQL-Datenbanken gefunden. Hier nun eine Lösung, die mit Hilfe der relationalen Datenbanktechnologie eine Sicherung über die Zeit ermöglicht.

15.2 Duplizieren zum Zeitpunkt der Rechnungsstellung

Sie besteht darin, die zeitabhängigen Daten zum Entstehungszeitpunkt zu duplizieren und ebenfalls in der Datenbank zu speichern. Dazu werden die duplizierten Daten der Relation zugeordnet, von deren Schlüssel sie funktional abhängig sind.

Beispiel Rechnungsstellung

Diese Vorgehensweise wird an einer einfachen Fassung eines Datenmodells zur Rechnungsstellung demonstriert. Gegeben seien die folgenden Relationen:

Adressen (#AdrNr, PLZ, Ort, Straße, Telefon)

Artikel (#ArtNr, Beschr, Preis)

KuAdr (#(KNr, AdressNr)) //Kundenadressen

Kunden (#KNr, Name, Vorname)

ReKöpfe (#ReNr, Datum, Verkäufer, KVDAT) //Rechnungsköpfe

RePos (#(ReNr, PosNr), ArtikelNr, Anzahl) //Rechnungspositionen

KVDAT bedeutet Kaufvertragsdatum, ein Kunde kann beliebig viele Adressen haben, unter einer Adresse können mehrere Kunden wohnen. Eine größere Fassung dieses Datenmodells findet sich in Abschnitt 16.1.

Nun zum Duplizieren der Daten. Als erstes müssen die Daten bestimmt werden, die zeitabhängig sind und die evtl. später wieder benötigt werden. Hier sind es zum einen die Daten der Rechnung, zum anderen die des Kunden. Bei den Rechnungsköpfen sind alle dafür notwendigen Informationen bereits zeitlich fixiert. Bei den Rechnungspositionen werden wir aber fündig: Die Artikelnummer kann sich ändern (sie kann z.B. wegfallen), die Artikelbeschreibung auch und der Preis sowieso. Also legen wir folgende Attribute an:

Duplizieren zum Rechnungsstellungs-
zeitpunkt (RZ)

ArtNr-RZ (Artikelnummer zum RechnungsstellungsZeitpunkt)

Beschr-RZ (Beschreibung zum RZ)

Preis-RZ (Preis zum RZ)

Sie müssen nun in der Relation eingefügt werden, von deren Schlüssel sie funktional abhängig sind. Das ist RePos. Somit entsteht:

RePos-Historisch (#(ReNr, PosNr), ArtikelNr, Anzahl, ArtNr-RZ, Beschr-RZ, Preis-RZ)

Die Relation Artikel bleibt unverändert. Nun die Kundendaten. Hier kann sich auch sehr vieles verändern. Sämtliche Adressangaben, sogar der Nachname (wenn Herr Rumpelstiz den Namen seiner Frau annimmt). Somit entstehen folgende Attribute:

Name-RZ (Nachname zum RZ)

PLZ-RZ

Ort-RZ

Straße-RZ

Wohin mit diesen zeitlich fixierten Attributen? Da sie pro Rechnung genau einmal auftreten, sind sie von der Rechnungsnummer (ReNr) funktional anhängig und gehören in ReKöpfe:

ReKöpfe-Historisch (#ReNr, Datum, Verkäufer, KVDAT, Name-RZ, PLZ-RZ, Ort-RZ, Straße-RZ)

Damit sind die historischen Daten eingepflegt und der aktuelle Datenbestand der zeitlich abhängigen Attribute kann ohne Probleme weitergeführt werden. Insgesamt ergibt sich damit folgendes Datenmodell:

Adressen (#AdrNr, PLZ, Ort, Straße, Telefon)

Artikel (#ArtNr, Beschr, Preis)

KuAdr (#(KNr, AdressNr))

Kunden (#KNr, Name, Vorname)

ReKöpfe-Historisch (#ReNr, Datum, Verkäufer, KVDAT, Name-RZ, PLZ-RZ, Ort-RZ, Straße-RZ)

RePos-Historisch (#(ReNr, PosNr), ArtikelNr, Anzahl, ArtNr-RZ, Beschr-RZ, Preis-RZ)

Das gewünschte Ziel ist erreicht: Zum Rechnungstellungszeitpunkt werden die Artikelnummer, die Beschreibung und der Preis in die entsprechenden „RZ-Attribute“ geschrieben und bleiben dort erhalten.

15.3 Andere Lösungen

Stammdaten fortschreiben

Manchmal sieht man auch die folgende Lösung. Da bekommen die zeitabhängigen Attribute eine Versionsnummer. Bei Änderungen werden die vorhandenen Daten nicht überschrieben, sondern der neue Wert wird mit einer neuen Versionsnummer eischließlich der Zeitangabe dazugegeben.

In obigem Beispiel Artikel gilt dann: Wenn sich die Beschreibung ändert, erhält der Artikel eine neue Versionsnummer, ebenso wenn sich der Preis ändert, usw. Ein konkreter Artikel wird dann über die kombinierte Artikel- und Versionsnummer identifiziert:

Artikel (#(ArtikelNr, VersionsNr), Beschreibung, Preis)

Für die Rechnungspositionen ergibt sich dann:

RePos (#(ReNr, PosNr), (ArtikelNr, VersionsNr), Beschreibung, Preis, Anzahl)

Diese Lösung ist machbar, führt aber zu Redundanzen, nicht auf der Ebene der einzelnen Relationen, aber über die Relationen hinweg. So wird die Beschreibung wiederholt, wenn sich der Preis ändert. Hat sich nur der Preis geändert, z.B. zehn mal, wird in 10 Tupeln dieselbe Beschreibung und derselbe Standort festgehalten.

Binäre Relationen

Dies ist die Stelle, an der oft radikale Umstrukturierungen der Relationen vorgeschlagen werden im Sinne binärer Relationen. Das bedeutet, dass alle Attribute einer Relation, die sich im Zeitablauf verändern können, zusammen mit dem Schlüssel in jeweils eine eigene Relation getan werden. Im obigen Beispiel:

Artikel-Beschreibung (#(ArtikelNr, VersionsNr), Beschreibung)

Artikel-Preis (#(ArtikelNr, VersionsNr), Preis)

Die Relation zu den Rechnungspositionen würde sich bei dieser Lösung wie folgt verändern:

RePos (#(ReNr, PosNr), ((ArtikelNr, VersionsNr), Beschreibung), ((ArtikelNr, VersionsNr), Preis), ((ArtikelNr, VersionsNr), Anzahl))

Bei dieser Lösung sind die oben angesprochenen Redundanzen beseitigt, allerdings werden die Abfragen komplizierter. Nicht nur müssen mehr Relationen verknüpft werden, was die Abfragen und Auswertungen verlängert, es muss auch immer noch bei jeder Relation die höchste Versionsnummer (bzw. bei Rekonstruktionen die "richtige") bestimmt werden.

NoSQL-Welt

In der NoSQL und BigData-Welt werden andere Techniken angewandt. Z.B. bei Dokumentendatenbanken (vgl. Abschnitt 24.10). Hier wird nach jeder Änderung eines Feldes das gesamte Dokument als neue Version abgespeichert. Vgl. zu diesem Teil der Datenbankwelt Kapitel 24.

16 Modellierungsbeispiele mit Lösungsweg

Hier beginnt Teil V: Beispiele relationaler Datenmodelle

mit den Kapiteln

16 Modellierungsbeispiele mit Lösungsweg

17 Weitere Modellierungsbeispiele

Mit den folgenden Beispielen soll auch der Entstehungsprozess eines Datenmodells gezeigt werden - seine Entwicklung "Schritt um Schritt". Dabei werden unterschiedliche Vorgehensweisen vorgestellt. Wie immer in diesem Text bezeichnet folgende Formatierungen ein Attribut, eine Relation und einen Anwendungsbereich.

16.1 Rechnungsstellung

Mit diesem Beispiel wird die Erstellung eines relationalen Datenmodells für den Zweck der Rechnungsstellung gezeigt. Ausgangspunkt ist dabei die in der folgenden Abbildung angegebene Rechnung , also ein Geschäftsobjekt (business object), was in der Datenmodellierung durchaus oft der Fall ist. Es gelten - neben der üblichen kaufmännischen Semantik von Rechnungen - die folgenden Bedingungen und semantischen Festlegungen:

Rechnungen

Die Kunden werden mit Namen (Name), Vornamen (VName) und Anrede erfasst. Außerdem wird ein identifizierendes Attribut (KuNr) angelegt.

Ein Kunde wird zuerst mit nur einer Adresse erfasst. Später dann mit beliebig vielen.

Ein Kunde kann mehrere Telefonanschlüsse haben.

In der Datenbank wird auch festgehalten, wer die Kundschaft bedient hat (Verkäufer). Dies wird auf der Rechnung ausgegeben.

TOUR bezeichnet das Auslieferungsteam (Tour).

KVDAT gibt den Tag an, an dem die Kundschaft im Möbelhaus war und die Ware bestellt hat (Kvdat).

Eine Rechnung bezieht sich auf genau einen Auftrag

Die angegebene Telefonnummer ist die der Rechnungsanschrift

Die Abkürzungen bei Position 1 bedeuten:

889999: Artikelnummer (ArtNr)

B/00/EG: Standort der Ware im Lager (Standort)

COUCHTISCH 1906 EICHE NATUR - MIT LIFT 125x71 cm: Artikelbezeichnung (ArtBez)

Abbildung 16.1-1: Geschäftsobjekt Rechnung (Typ Möbelhaus)

Diese Aufgabe wird mit unterschiedlichen Komplexitätsgraden in drei Stufen gelöst:

Aufgabe Stufe 1 - Grundstruktur: Für jeden Kunden wird nur eine Anschrift, die Rechnungsanschrift, erfasst. Es wird keine zeitliche Dimension berücksichtigt, d.h. alte Rechnungen müssen nicht aus der Datenbank heraus reproduzierbar sein.

Aufgabe Stufe 2 - Beliebige Rechnungs- und Lieferadresse: Für jeden Kunden werden beliebig viele Adressen erfasst. Bei jedem Kauf kann ein Kunde eine beliebige seiner Adressen als Lieferadresse bzw. als Rechnungsadresse angeben.

Aufgabe Stufe 3 - Zeitachse: Einfügen einer zeitlichen Dimension. Die Rechnungen sollen über die Zeit gerettet werden, d.h. es soll möglich sein, beliebige Rechnungen der Vergangenheit aus der Datenbank heraus zu reproduzieren. Also z.B. eine Rechnung vom 20. November 2012 mit den damaligen Preisen, der damaligen Mehrwertsteuer, usw.

Rechnungsstellung Stufe 1

Für die Stufe 1 sammeln wir zuerst die Attribute ein und bestimmen die Determinanten und funktionalen Abhängigkeiten (ein bei Geschäftsobjekten sinnvolles Vorgehen):

Von den Attributen ausgehend modellieren

Name: des Kunden

VNname

PLZ: der Rechnungsanschrift

Ort

Straße

Tel: Telefonnummer

KuNr: Kundennummer. Diese ergänzen wir gleich, da die Erfassung der Kunden ohne eine Kundennummer nicht sinnvoll ist.

ReNr: Rechnungsnummer

ReDatum: Rechnungsdatum

Verkäufer: die Angabe des Verkäufers erfolgt auf der Rechnung

KVDAT: Hierbei handelt es sich um das Kaufvertragsdatum.

TOUR: Bezeichnung des Teams, das mit seinem Fahrzeug die Möbel ausliefert. Eine tiefere Semantik liegt nicht vor.

PosNr: Rechnungspositionsnummer

ArtNr: wird bei den Rechnungspositionen angegeben.

Anzahl der Artikel pro Position

Standort: Standort der Ware im Lager. Wird bei den Rechnungspositionen angegeben.

ArtBez: Artikelbezeichnung

ZV: Zahlungsvereinbarung

LiPreis: Listenpreis. Der Preis für die gesamte Position wird berechnet aus Anzahl und Preis.

Für die meisten Artikel liegt noch eine Beschreibung vor (Beschr), die aber nicht auf der Rechnung ausgegeben wird. Der Mehrwertsteuersatz wird im Programm hinterlegt, der Mehrwertsteuerbetrag (MWStB) wird dann daraus und aus der Rechnungssumme berechnet.

Was kann man nun, auch unter Berücksichtigung der ja immer vorliegenden Objekt-/Beziehungsstruktur von den Attributen ableiten? Problemlos zu erkennen sind die Kunden: als Objekte, Objektklasse und als Relation. Identifiziert werden sie durch die KuNr. Diese ist hier also erstmals Determinante. Voll funktional abhängig von dieser sind die folgenden Attribute:

Objekte und Beziehungen finden

KuNr => Name

KuNr => VName

KuNr => PLZ

KuNr => Ort

KuNr => Straße

Für die Adressangaben gilt dies nur, weil wir uns in Stufe 1 mit der Rechnungsanschrift begnügen. Damit ergibt sich die erste Relation:

Kunden (#KuNr, Name, VName, PLZ, Ort, Straße)

Jeder Kunde kann mehrere Telefonanschlüsse haben. Dies wird durch die folgende Relation erfasst:

KuTel (#(KuNr, Tel))

Beide Relationen sind bereits in 5NF. Ähnlich einfach ist das Erkennen der Rechnung als Modellelement. Bei genauerem Hinsehen erkennt man aber, dass es eine Unterscheidung geben muss zwischen Rechnungskopf (identifiziert durch die Rechnungsnummer (ReNr)) und den Rechnungspositionen, denn es gibt pro Rechnung mehrere Positionen. Folgende funktionalen Abhängigkeiten bestehen von der Determinante ReNr:

Rechnungskopf vs. Rechnungspositionen

ReNr => ReDatum: Es gibt genau ein Rechnungsdatum pro Rechnung bzw. von der Rechnungsnummer kann auf das Rechnungsdatum geschlossen werden.

ReNr => Verkäufer: Da immer nur einer für einen Kaufvertrag zuständig ist und nur einer auf der Rechnung erscheint.

ReNr => Tour: Es gibt ein Auslieferungsteam je Rechnung.

ReNr => KVDAT: Es gibt hier genau ein Kaufvertragsdatum je Rechnung.

ReNr => ZV: Die Zahlungsvereinbarung ist je Rechnung eindeutig. Trotz Nachfragen konnte auch keine weitere Semantik (z.B. Abhängigkeit vom gekauften Produkt) festgestellt werden.

Ergänzt man noch das Datum der Lieferung (DatumLief) und den Mehrwertsteuerbetrag (MWStB) ergibt sich folgende Relation zu den Rechnungsköpfen:

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB)

Auch diese ist in 5NF. Die letzten leicht erkennbaren Objekte sind die Artikel. Auch sie werden identifiziert (ArtNr), haben eine Bezeichnung (ArtBez) und werden beschrieben. Allerdings liegt nicht zu jedem Artikel eine Beschreibung vor. ArtNr ist also Determinante mit folgenden funktional abhängigen Attributen:

Artikel in zwei Relationen

ArtNr => ArtBez

ArtNr => LiPreis: Da es sich um den Einzelpreis der Artikel handelt.

ArtNr => Standort: Standort der Ware im Lager. Für einen Artikel immer derselbe.

Dies führt zu folgenden Relationen:

Artikel (#ArtNr, ArtBez, LiPreis, Standort)

Für die Artikel mit Beschreibung wird eine eigene Relation angelegt, da es sich um eine Teilmenge aller Artikel handelt und damit insgesamt um eine Generalisierung/Spezialisierung (Gen/Spez):

Muster Gen/Spez

ArtBeschr (#ArtNr, ArtBeschr) //Artikelbeschreibung

Auch hier gibt es keinen Verstoß gegen die 5NF. Bleiben noch die übrigen Attribute. Sie bewegen sich alle um die Rechnungspositionen herum. Ihre Verarbeitung macht bei ungeübten Modellierern regelmäßig Schwierigkeiten. Hier muss erkannt werden, dass das zu modellierende Realweltphänomen das kaufmännische Konstrukt der Rechnungspositionen ist. Wird dies erkannt, ist der Rest einfach. Rechnungspositionen werden durch eine Attributskombination identifiziert: (ReNr, PosNr). Folgende funktionalen Abhängigkeiten bestehen:

Rechnungspositionen - kaufmännische Semantik

(ReNr, PosNr) => ArtNr: Da es pro Rechnungsposition nur einen Artikel gibt.

(ReNr, PosNr) => Anzahl: Anzahl der Artikel je Position.

Damit ergibt sich folgende Relation zu Rechnungspositionen, ebenfalls in 5NF:

RePos (#(ReNr, PosNr), ArtNr, Anzahl).

Oftmals wird in Übungen obige Relation über den Zusammenhang von Rechnung und Artikeln erkannt. Da es typischerweise pro Rechnung mehrere Artikel gibt und die Artikel auch auf mehreren Rechnungen auftauchen (ein bestimmtes Sofa, das hundert mal verkauft wurde) wird dabei dann zuerst eine Verbindungsrelation mit dem Schlüssel (ReNr, ArtNr) eingerichtet. Dann wird die PosNr zu einem beschreibenden Attribut der Relation. Insgesamt also:

Alternativer Weg

RePos (#(ReNr, ArtNr), PosNr, Anzahl)

In dem Lösungsweg hier sind nun sechs Relationen entstanden, die wesentliche Merkmale der Rechnung beschreiben. Zu prüfen sind aber noch die Schlüssel und Fremdschlüssel, d.h. die relationalen Verknüpfungen:

Relationale Verknüpfungen

Zwischen Kunden und ReKöpfe: Hier liegt sicherlich eine Beziehung vor. Ein Kunde hat u.U. viele Rechnungen mit dem Unternehmen, aber eine Rechnung bezieht sich immer nur auf einen Kunden. Diese 1:n - Beziehung kann verankert werden, indem in ReKöpfe die Kundennummer festgehalten wird:

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, KuNr)

Zwischen Kunden und Artikel: Hier gibt es auf der Ebene der Relationen keine direkte Beziehung. Die Beziehung manifestiert sich durch die Rechnung und ihre Positionen. Wenn man sie trotzdem einrichtet, um z.B. im Rahmen des Kundenbeziehungsmanagements (Customer Relationship Management; CRM) schnellen Zugriff auf die vom Kunden schon getätigten Käufe zu haben, ist das möglich. Dafür müsste eine Verbindungsrelation eingerichtet werden.

Zwischen Kunden und RePos (Rechnungspositionen): Auch hier gibt es auf der Ebene der Relationen keine Beziehung. Die Verknüpfung erfolgt über die Rechnung.

Zwischen ReKöpfe und Artikel: Dieser Zusammenhang wird über die RePos hergestellt.

Zwischen ReKöpfe und RePos: Diese Beziehung ist natürlich fundamental. Es ist eine 1:n - Beziehung, denn eine Rechnung kann mehrere Positionen haben, eine Rechnungsposition gehört aber immer zu einer bestimmten Rechnung. Damit handelt es sich bei diesem Muster um eine Komposition. Diese Beziehung wurde aber schon bei der Festlegung des Schlüssels von RePos festgelegt. Es muss lediglich noch die ReNr als Fremdschlüssel gekennzeichnet werden:

RePos (#(ReNr, PosNr), ArtNr, Anzahl)

Zwischen Artikel und Rechnungspositionen (RePos): Hier liegt wiederum eine 1:n - Beziehung vor. Ein Artikel kommt hoffentlich auf vielen Rechnungspositionen vor und eine Rechnungsposition erfasst genau einen Artikel. Die Min-/Max-Angabe von 1,1 auf der Seite der Rechnungspositionen ist hier besonders sinnvoll, denn es hat keinen Sinn, Rechnungspositionen ohne Artikel zu erfassen. Damit kann die Verknüpfung durch Übernahme der ArtNr in die Relation RePos eingerichtet werden. Da dies oben schon geschehen ist (falls nicht, würde das Defizit spätestens hier erkannt), muss lediglich noch die Kennzeichnung von ArtNr als Fremdschlüssel erfolgen:

RePos (#(ReNr, PosNr), ArtNr, Anzahl)

Die funktionalen Abhängigkeiten sind in allen Relationen bereits geklärt, da ja die Attribute so zu Relationen gruppiert wurden, dass jeweils ein Schlüssel und die von ihm voll funktional abhängigen Attribute zusammen kamen. Da keine überlappenden Schlüssel auftreten, ist die BCNF auch gesichert. Da darüber hinaus die in der vierten und fünften Normalform angesprochenen Probleme nicht auftreten, befinden sich alle Relationen in 5NF.

Idealstruktur – redundanzfrei

Die folgende Abbildung zeigt die grafische Darstellung des Datenmodells.

Abbildung 16.1-2: Relationales Datenmodell Rechnungsstellung Stufe 1

Hier noch die textlichen Notationen - im Zusammenhang:

ArtBeschr (#ArtNr, Beschr)

Lösung Stufe 1

Artikel (#ArtNr, ArtBez, Standort, LiPreis)

Kunden (#KuNr, Anrede, Name, VName, PLZ, Ort, Straße)

KuTel (#(KuNr, Tel))

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, KuNr)

RePos (#(ReNr, PosNr), ArtNr, Anzahl)

Rechnungsstellung Stufe 2

In Stufe 2 wird nun zwischen Liefer- und Rechnungsadresse unterschieden und es soll gelten: Ein Kunde kann beliebig viele Adressen haben, jede kann bei einer Rechnung Liefer- oder Rechnungsadresse sein. Eine Folge dieser Festlegung ist, dass die alte Relation Kunden verkürzt wird, da die Adressattribute in die Relation Adressen gehen. Übrig bleiben KuNr, Name, VName, so dass daraus die neue Kundenrelation entsteht:

Adressen

Kunden (#KuNr, Name, Vorname)

Adressen werden zu einer eigenen Relation. Ergänzt wird ein Schlüssel Adressnummer (AdrNr), denn einen Schlüssel braucht jede Relation:

Adressen (#AdrNr, PLZ, Ort, Straße, Telefon)

Es fehlt aber noch die Verknüpfung zwischen den Kunden und Adressen. Deren Wertigkeit ist n:m, denn ein Kunde hat ja mehrere Adressen und unter einer Adresse wohnen u.U. mehrere Kunden (Mehrfamilienhäuser). Es wird also eine Verbindungsrelation Kunden-Adressen benötigt:

KuAdr (#(KuNr, AdrNr))

Beide Attribute wurden gleich als Fremdschlüssel gekennzeichnet. Damit ist im Datenmodell die Beziehung zwischen Kunden und Adressen festgehalten. Bleibt noch zu klären, wie festgehalten wird, welche bei einer bestimmten Lieferung die Liefer- und welche die Rechnungsadresse ist. Bisher war diesbezüglich ja einfach die KNr als Fremdschlüssel in ReKöpfe hinterlegt.

Eine sinnvolle Lösung ist, für jede Lieferung die drei Relationen Kunden, Adressen und Rechnungsköpfe zu verknüpfen und bei jeder Verknüpfung festzuhalten, ob es sich um die Liefer- oder die Rechnungsadresse handelt (hier mit dem Attribut Typ). Dann kann es pro Lieferung eine oder zwei solche Verknüpfungen geben, je nachdem, wieviele Adressen der Kunde angegeben hat. Die Relation hat damit drei Fremdschlüssel:

KuAdrRe (#(KuNr, AdrNr, ReNr), Typ)

Das Attribut Typ hat die Ausprägungen L(ieferadresse) und R(echnungsadresse). R gibt es immer, L nur, falls es eine extra Lieferanschrift gibt. Ansonsten ist die Rechnungsanschrift gleich der Lieferanschrift. Die folgende Tabelle zeigt zur Verdeutlichung einige Beispielsdaten:

KuAdrRe

ReNr

KuNr

AdrNr

Typ

1001

007

2

L

1001

007

5

R

2002

007

1

R

2020

010

1

R

...

...

...

...

Zur Veranschaulichung wurde in den Daten auch der Fall mit eingefügt, dass unter einer Adresse mehrere Kunden wohnen (Rechnungsnummern 2002 und 2020).

Die Relation KuAdr wird jetzt eigentlich nicht mehr benötigt. Da es aber oftmals sinnvoll ist, die Adressen von Kunden auch ohne die Rechnungen ansprechen zu können, z.B. bei Marketingmaßnahmen oder ganz allgemein im Customer Relationship Management (CRM), soll sie drin bleiben. Damit ergibt sich das grafische Datenmodell der folgenden Abbildung.

Abbildung 16.1-3: Datenmodell Rechnungsstellung Stufe 2

Die Wertigkeiten bei der dreistelligen Beziehung KuAdrRe ergeben sich wie folgt, wie immer bei mehrstelligen Beziehungen von der Verbindungsrelation aus gesehen: 1,1 : 1:1 : 1,1 (An einer Beziehung nimmt genau eine Kundennummer, eine Adressnummer und eine Rechnungsnummer teil).

Wertigkeiten

Hier das Gesamtmodell nach Stufe 2 in textlicher Notation:

Adressen (#AdrNr, PLZ, Ort, Straße, Telefon)

Lösung Stufe 2

ArtBeschr (#ArtNr, ArtBeschr)

Artikel (#ArtNr, ArtBez, Standort, LiPreis)

KuAdr (#(KuNr, AdrNr))

KuAdrRe (#(KuNr, AdrNr, ReNr), Typ)

Kunden (#KuNr, Anrede, Name, Vorname)

KuTel (#(KuNr, Tel))

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB)

RePos (#(ReNr, PosNr), ArtNr, Anzahl)

Rechnungsstellung Stufe 3

In der folgenden dritten Stufe soll nun die zeitliche Dimension hinzugefügt werden und zwar mit dem Ziel, die Rechnungen der vergangenen Jahre aus der Datenbank heraus reproduzierbar zu halten, auch wenn sich die Stammdaten verändern. Bei einer Rechnungsstellung entstehen ja Daten zum kaufmännischen Vorgang, die auch nicht mehr verändert werden. Z.B. Rechnungsnummer, Rechnungsdatum, Artikelbeschreibung, Positionssummen, Gesamtsumme. Andere Daten werden mit Hilfe der durch das Datenmodell vorgegebenen Struktur im Moment der Rechnungsstellung aus den Datenbeständen geholt: zum Kunden, zu den Artikeln. Genau diese Daten können sich aber nach dem Zeitpunkt der Rechnungsstellung sehr schnell ändern:

Vgl. zur zeitlichen Dimension auch
Kapitel 15

Der Kunde zieht um, seine Telefonnummer ändert sich, er ändert seinen Namen.

Die Artikelpreise ändern sich, Artikel verschwinden aus dem Sortiment, ihre Bezeichnung oder auch Beschreibung ändert sich.

Und so weiter. Um sich dagegen abzusichern können die "vergänglichen" Attribute bzw. deren Ausprägungen zum Zeitpunkt der Rechnungsstellung (RZ; Rechnungsstellungszeitpunkt) festgehalten werden. Dazu werden diese Attribute an geeigneter Stelle im Datenmodell angelegt und dann in der Datenbank gespeichert.

Folgende Attribute müssen bezüglich der Kunden über die Zeit "gerettet" werden: Name, Vorname, PLZ, Ort, Straße. Dies geschieht, indem sie mit dem Zusatz "RZ" zusätzlich aufgenommen werden. Doch in welcher Relation soll man sie unterbringen? Hier hilft die Überlegung, von welcher Determinante diese Attribute funktional abhängig sind. Natürlich von der Rechnungsnummer, also gehören sie in die Relation Rechnungsköpfe. Da sich der Mehrwertsteuersatz ja auch regelmäßig ändert und auf der Rechnung ausgewiesen ist, muss auch er "konserviert" werden. Auch er ist von der Rechnungsnummer funktional abhängig. Somit ergibt sich:

Zu "rettende" Kundendaten

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, Name-RZ, VName-RZ, PLZ-RZ, Ort-RZ, Straße-RZ, Tel-RZ, MWStS-RZ)

Folgende "vergänglichen" Attribute bezüglich der Artikel sollten, da sie auf der Rechnung erscheinen, verdoppelt werden: Artikelnummer, Artikelbezeichnung, Listenpreis. Wieder hängen wir das Kürzel RZ an. Der Platz für diese Attributdoppelung ist, auch hier hilft wieder die Überlegung zu den funktionalen Abhängigkeiten und zur Determinante, die Relation Rechnungspositionen:

Zu "rettende" Artikeldaten

RePos (#(ReNr, PosNr), ArtNr, Anzahl, ArtNr-RZ, ArtBez-RZ, LiPreis-RZ)

Fassen wir das Vorgehen zusammen. Folgende Schritte sind zu leisten:

Klären, welche Attribute wegen der notwendigen Reproduzierbarkeit dupliziert werden müssen.

Feststellen, wo diese Attribute platziert werden können durch Klärung der Frage, wovon sie funktional abhängig sind.

Hier nun das gesamte Datenmodell der Stufe 3 in textlicher Notation:

Adressen (#AdrNr, PLZ, Ort, Straße)

ArtBeschr (#ArtNr, ArtBeschr)

Artikel (#ArtikelNr, ArtBez, Standort, LiPreis)

KuAdr (#(KuNr, AdrNr))

KuAdrRe (#(KuNr, AdrNr, ReNr), Typ)

Kunden (#KuNr, Anrede, Name, Vorname)

KuTel (#(KuNr, Tel))

ReKöpfe (#ReNr, ReDatum, KVDAT, Tour, Verkäufer, DatumLief, ZV, MWStB, Name-RZ, VName-RZ, PLZ-RZ, Ort-RZ, Straße-RZ, Tel-RZ)

RePos (#(ReNr, PosNr), ArtNr, Anzahl, ArtNr-RZ, ArtBez-RZ, LiPreis-RZ)

RZ : Zeitpunkt der Rechnungsstellung

Das grafische relationale Datenmodell bleibt gleich, da die duplizierten Attribute weder Schlüssel noch Fremdschlüssel sind. Mit dieser Methode des Einbindens der zeitlichen Dimension sind die "geretteten" Daten in die operative Datenbank integriert.

16.2 Sportverein

Ein Sportverein beschließt, seine Aktivitäten (Mitgliederverwaltung, Sportveranstaltungen, usw.) in Zukunft computergestützt abzuwickeln. Dazu soll eine Datenbank aufgebaut werden, für die folgende Festlegungen getroffen werden:

Anwendungsbereich: Sportverein

Die Mitglieder des Vereins werden durch Name, Vorname (VName), Telefon (Tel), Geburtstag (GebTag), eine Mitgliedsnummer (MiNr) und die Hauptadresse (PLZ, Ort, Straße) festgehalten. Erfasst wird außerdem der Tag des Eintritts (Eintritt) in den Verein. Bei ausgetretenen Mitgliedern ebenfalls der des Austritts (Austritt). Es kommt auch vor, dass ein Mitglied austritt und später wieder eintritt. Auch dies soll in vollem Umfang dokumentiert werden, d.h. vorherige Mitgliedschaften werden nicht gelöscht. Es entsteht so eine Dokumentation aller Ein- und Austritte eines Vereinsmitglieds. Bei verstorbenen Mitgliedern wird der Todestag (Todestag) vermerkt.

Für die Mitglieder wird erfasst, ob sie passiv oder aktiv sind. Für jedes aktive Mitglied wird dann noch festgehalten, welche Sportart es in welcher Leistungsstufe (LStufe) betreibt. Dies können mehrere sein. Für die passiven Mitglieder wird erfasst, für welche ehrenamtliche Tätigkeit sie zur Verfügung stehen (BezTät). Auch dies können mehrere sein.

Der Sportverein ist in Abteilungen (AbtNr, AbtBez) gegliedert (Handball, Fußball, Volleyball, usw.).

Jede Abteilung hat einen Leiter (AbtLeiter). Dieser zählt als aktives Mitglied.

Eine Abteilung kann mehrere Mannschaften haben. Natürlich gehört eine Mannschaft zu genau einer Abteilung.

Von jeder Mannschaft (MaNr, MaBez) werden mit Hilfe der Mitgliedsnummer die Spieler und der Kapitän (KapNr) festgehalten sowie die Liga, in der sie spielt (Bundesliga, usw.).

Jede Mannschaft hat einen (einzigen) Trainer (TrNr). Auch dieser wird festgehalten. Er zählt als aktives Mitglied.

Die Begegnungen von Mannschaften des Vereins sollen mit Datum (Tag), Spielbeginn (Beginn), gegnerischer Mannschaft (Gegner) und Ergebnis festgehalten werden. Falls im Rahmen eines Turniers zwei Mannschaften des Vereins gegeneinander spielen, wird nur ein Eintrag vorgenommen und eine der beiden Mannschaften als "gegnerische" Mannschaft eingetragen. Für diese Datenbank wird angenommen, dass eine Mannschaft mehrere Spiele an einem Tag haben kann (Turnier!).

Wie sehen nun die konkreten Modellierungsschritte aus? Sinnvoll ist es, zuerst die Objekte und Objektklassen und die zugehörigen Relationen zu suchen.

Erste Schritte

Beginnen wir mit den Mitgliedern des Vereins. Diese erkennt man modellierungstechnisch daran, dass es sich erstens um Objekte im allgemeinen Sinn handelt und dass zweitens diese Objekte durch Attribute beschrieben werden. Zweiteres ist von zentraler Bedeutung, denn sonst kann es sich auch um ein Attribut handeln, das andere Objekte beschreibt. Es entsteht also eine Relation Mitglieder. Nehmen wir die o.g. deskriptiven Attribute und den Schlüssel erhalten wir folgende Relation:

Mitglieder (#MiNr, Name, VName, Tel, GebTag, PLZ, Ort, Straße)

Alle Mitglieder sind irgendwann in den Verein eingetreten. Insofern könnte man das Attribut Eintritt zur Relation mithinzunehmen. Da es aber Mitglieder gibt, die ausgetreten sind und solche, die vielleicht später wieder eintreten, stellen diese Mitglieder eine Spezialisierung dar. Die ganz korrekte Lösung wäre es, zwei Relationen anzulegen:

Eintritt, Austritt, verstorbene Mitglieder

MitglEintritt (#(MiNr, Datum))

MitglAustritt (#(MiNr, Datum))

Der Schlüssel ist zusammengesetzt, da dasselbe Mitglied ja jeweils mehrere Einträge haben kann.

Vertretbar ist aber auch die hier gewählte pragmatische Lösung, die Ein- und Austritte zusammen zu verwalten, auch wenn dabei inhaltlich begründete Leereinträge entstehen, denn das Austrittsdatum wird erst beschrieben, wenn das Mitglied tatsächlich austritt:

Pragmatische Lösung wegen zeitlicher Dimension.
Muster GenSpez

MitglEinAus (#(MiNr, Eintritt), Austritt)

Auch hier ist der Schlüssel wieder zusammengesetzt aus Mitgliedsnummer und Eintrittsdatum, da nur diese Attributkombination differenziert. In beiden Fällen ist es daher möglich, dass ein Mitglied mehrfach ein- und wieder austritt.

Auch die verstorbenen Mitglieder müssen als Spezialisierung erfasst werden, da diese Eigenschaft und den Todestag die anderen Mitgleider nicht teilen:

Verstorbene Mitglieder

MitglVerstorben (#MiNr, Todestag)

Dies macht nochmals deutlich, dass ein Attribut genügt, zu um einer spezialisierten Relation zu kommen.

Bleibt noch die Modellierung der Eigenschaft, aktives oder passives Vereinsmitglied zu sein. Ginge es nur um diese Eigenschaft, würde einfach ein Attribut "aktiv/passiv" mit diesen zwei Eigenschaften an die Relation Mitglieder angefügt. Nun ist es hier aber so, dass für die aktiven und passiven Mitglieder jeweils unterschiedliche Attribute festgehalten werden sollen. Deshalb müssen diese Teilgruppen der Mitglieder getrennt als Spezialisierungen erfasst werden:

aktiv / passiv - Muster Gen/Spez

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

Die passiven Mitglieder erhalten einen zusammengesetzten Schlüssel. Damit kann datenbanktechnisch ein Mitglied auch mehrere ehrenamtliche Tätigkeiten übernehmen.

Oftmals wird in die "oberste" Relation ganz pragmatisch noch ein Attribut eingefügt, das angibt, zu welcher Spezialisierung das Objekt gehört. Hier könnte z.B. ein Attribut Status in Mitglieder angeben, ob es sich um ein aktives, passives oder verstorbenes Mitglied handelt. Dies erleichtert die Abfragen und Auswertungen sehr stark, denn dadurch kann ohne Abfragen der Spezialisierungen gleich die entsprechende Auswahl getroffen werden.

Pragmatik
Klärung der Spezialisierung

Insgesamt erhalten wir damit für die Mitglieder folgende Relationen:

Mitglieder (#MiNr, Name, VName, Tel, GebTag, PLZ, Ort, Straße, Status)

MitglEinAus (#(MiNr, Eintritt), Austritt)

MitglVerstorben (#MiNr, Todestag)

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

Hier die grafische Darstellung dieses Modellfragments:

Abbildung 16.2-1: Mitglieder im Datenmodell Sportverein

Hilfestellung zum Lesen der Wertigkeiten:

In der relationalen Verknüpfung zwischen Mitglieder und MitglAktiv kommt eine bestimmte MiNr aus Mitglieder maximal einmal vor, eine bestimmte MiNr aus MitglAktiv genau ein Mal.

In semantischen und objektorientierten Modellen ist es möglich auszudrücken, dass alle Objekte der übergeordneten Einheit (Entitätstyp, Superklasse) an den Spezialisierungen teilhaben. Dies kann in relationalen Modellen nicht ausgedrückt werden. Falls es gewünscht wird, muss es auf andere Weise festgehalten und durch das Anwendungsprogramm sichergestellt werden.

Totale Beteiligung

Die Mannschaften

Betrachten wir nun die Mannschaften. Sie tauchen mit folgenden Beschreibungen auf:

Jede Abteilung hat mehrere Mannschaften, insofern könnte "Mannschaft" ein Attribut von Abteilung sein.

Von jeder Mannschaft werden die Bezeichnung (MaBez), die Spieler, der Kapitän, die Liga, der Trainer und ihre Begegnungen festgehalten.

Letzteres macht die Mannschaften zu Klassen und dann zu Relationen, da sie durch weitere Attribute beschrieben werden. Trainer und Kapitän sind aktive Mitglieder und werden somit durch einen Fremdschlüssel erfasst. Die Abteilungszugehörigkeit wird im nächsten Schritt geklärt. Damit ergibt sich folgender erster Entwurf:

Mannschaften (#MaNr, MaBez, Liga, TrNr, KapNr)

Schlüssel, Sekundärschlüssel und Fremdschlüssel

MaNr: Mannschaftsnummer

MaBez: Mannschaftsbezeichnung

TrNr: Trainernummer

KapNr : Kapitänsnummer

Die Zuordnung der Spieler schieben wir auf, da eine Mannschaft mehrere Spieler hat. Die Begegnungen werden ebenfalls später geklärt, da sie durch weitere Attribute zu einer eigenständigen Existenz kommen.

Abteilungen

Jetzt müssen noch die Abteilungen betrachtet werden. Für sie wurde oben festgehalten, dass der Verein in Abteilungen gegliedert ist (Handball und Fußball), dass jede Abteilung eine/n Leiter/in und mehrere Mannschaften hat.

In Konfrontation mit den schon erstellten Modellfragmenten lässt sich damit festhalten, dass Abteilungen zu einer Relation mit den Attributen AbtBez und AbtLeiter wird. Die Tatsache, welche Mannschaft zu welcher Abteilung gehört, ist eine 1:n-Beziehung (z.B. als 1,1 : 1,n) und wird daher durch den Fremdschlüssel AbtNr in Mannschaften festgehalten.

Abteilungen (#AbtNr, AbtBez, AbtLeiter)

Mannschaften (#MaNr, MaBez, Liga, TrNr, KapNr, AbtNr)

Spieler

Eine Mannschaft hat mehrere Spieler, ein Spieler kann in mehreren Mannschaften sein. Damit liegt eine n:m-Beziehung zwischen Aktiven Mitgliedern (AM) und Spielern (SP) vor:

AMSp (#(MaNr, MiNr))

Begegnungen

Im beschreibenden Text wurde festgelegt, dass alle Begegnungen von Mannschaften des Vereins mit Tagesdatum, Gegner und Ergebnis festgehalten werden sollen. Da die Mannschaften in einer anderen Relation beschrieben sind, werden sie hier durch den Fremdschlüssel MaNr repräsentiert:

MaNr, Tag, Gegner, Ergebnis

Fehlt noch ein Schlüssel. Dieser könnte realisiert werden, indem bei jeder Begegnung der Beginn des Spiels miterfasst wird. Denn eine Mannschaft kann zwar u.U. an einem Tag mehrere Begegnungen haben, aber nicht mit demselben Startpunkt. Damit werden (MaNr, Tag, Beginn) zu einem Schlüssel und die Relation ergibt sich wie folgt:

Begegnungen (#(MaNr, Tag, Beginn), Gegner, Ergebnis)

Die Beziehung Begegnungen zu Mannschaften stellt eine Komposition dar. Wenn eine Mannschaft aus der Datenbank gelöscht wird, müssen (datenbanktechnisch) auch ihre Begegnungen verschwinden, da unvollständige Schlüssel nicht zulässig sind.

Muster Komposition

Zu beachten ist, dass es nur um die Spiele des betrachteten Vereins geht, nicht um alle Spiele einer Liga, was die Situation verändern würde. Oben wurde schon angemerkt, was geschieht, falls ausnahmsweise im Rahmen eines Turniers zwei Mannschaften des Vereins gegeneinander spielen.

Insgesamt ergibt sich damit das folgende Datenmodell.

Mitglieder (#MiNr, Name, VName, Tel, GebTag, PLZ, Ort, Straße, Status)

Textliche Notation

MitglEinAus (#(MiNr, Eintritt), Austritt)

MitglVerstorben (#MiNr, Todestag)

MitglAktiv (#MiNr, Sportart, LStufe)

MitglPassiv (#(MiNr, BezTät))

Begegnungen (#(MaNr, Tag, Beginn), Gegner, Ergebnis)

AMSp (#(MaNr, MiNr))

Abteilungen (#AbtNr, AbtBez, AbtLeiter)

Mannschaften (#MaNr, MaBez, Liga, TrNr, KapNr, AbtNr)

Grafische Notation des Datenmodells:

Abbildung 16.2-2: Gesamtmodell Sportverein

AbtNr: Abteilungsnummer

AbtLeiter: Abteilungsleiter

MaNr: Mannschaftsnummer

MiNr: Mitgliedsnummer

TrNr: Trainernummer

KapNr: Kapitänsnummer

LStufe: Leistungsstufe

BezTät: Bezeichnung der ehrenamtlichen Tätigkeit

Zur konkreten Bedeutung von Kardinalitäten und Wertigkeiten siehe Kapitel 5.

16.3 PC-Beschaffung

Anforderungen an die Datenbank

In einem Unternehmen soll der Vorgang der PC-Beschaffung durch eine Datenbank festgehalten werden. Folgende Festlegungen ergaben sich in den Interviews, die im Vorfeld mit den Betroffenen geführt wurden:

Jeder PC erhält eine Inventarnummer (InvPC), ebenso die Bildschirme (InvBS). Jedem PC ist genau ein Bildschirm zugeordnet.

Für jeden PC wird folgendes festgehalten: der Prozessortyp (Proz), die Größe des Arbeitsspeichers (ArbSp), ob ein optisches Laufwerk (DVD, CD-ROM, usw.) vorhanden ist und welche Bezeichnung und Geschwindigkeit (BezLW bzw. Geschw) es hat. Es können durchaus mehrere optische Laufwerk eines Typs in einen PC eingebaut sein (z.B. zu Archivierungszwecken), so dass auch die Anzahl festgehalten wird. Natürlich gibt es einen Laufwerkstyp durchaus in verschiedenen Rechnern.

Für alle PCs wird festgehalten, ob Programmiersprachen (PS) installiert sind und falls ja, welche. Für die PCs der Entwickler wird die hauptsächlich verwendete Entwicklungsumgebung (EntwUmg) festgehalten.

In diesem Unternehmen wird vor der Übergabe des PC an den Nutzer durch die IT geprüft, ob das Gehäuse, die jeweilige Hauptplatine und die Grafikkarte für die Anforderungen des Nutzers geeignet sind. Falls nicht, werden sie ausgetauscht. Deshalb werden diese drei Komponenten in der Datenbank ausgewiesen. Alle mit ihrer Bezeichnung (BezGH, BezHP, BezGK), die Gehäuse noch mit Größenangaben (Größe), die Hauptplatinen mit der Anzahl der Prozessoren (AnzProz) und die Grafikkarten mit ihrer maximalen Auflösung (Auflösung). Natürlich kommt es vor, dass diese Komponenten in mehreren PC eingebaut werden.

Für jede Festplatte wird die Bezeichnung (BezPl), die Speicherkapazität (Größe) sowie die Zugriffsgeschwindigkeit (Zugriff) erfasst. Jede Festplatte erhält von der IT-Abteilung eine eindeutige Seriennummer (SerNrF), angelehnt an die des Festplattenherstellers und wird ausführlich getestet. Das Ergebnis, ein Qualitätskoeffizient (Qual), wird auch festgehalten. Es kommt durchaus vor, dass ein PC mehrere Festplatten hat, aber nicht umgekehrt.

Außerdem werden jeweils mit Hilfe einer Kurzbezeichnung (KBezSK) die im PC enthaltenen sonstigen Komponenten (W-LAN-Komponente, Kamera, usw.) festgehalten. Natürlich kommt eine bestimmte Komponente in mehreren PCs vor. Außerdem hat ein PC typischerweise mehrere solcher "sonstigen Komponenten".

Für jeden ins Unternehmen gegebenen PC wird weiterhin festgehalten, wer ihn nutzt, erfasst über die Personalnummer (PersNr), Name, Vorname (VName) sowie Telefonnummer (Tel) und wann er dort eingerichtet wurde (DatEinr). Ein bestimmter PC wird immer von genau einem Angestellten genutzt, ein Angestellter kann bis zu zwei PC zugeordnet bekommen.

Für Bildschirme wird neben der Bezeichnung (BezBS) noch festgehalten, von welcher Art (Art) sie sind, welchen Durchmesser sie haben (Zoll) und wann sie übergeben wurden (DatÜb).

Mit diesem Beispiel soll auch nochmals auf das Muster Einzel/Typ hingewiesen werden. Vgl. dazu Abschnitt 14.2.

Einzelgerät vs. Typ

Lösungsweg

Zur Erstellung des Datenmodells werden - Schritt um Schritt - nochmals die Anforderungen betrachtet, jeweils etwas eingerückt.

Jeder PC erhält eine Inventarnummer (InvPC), ebenso die Bildschirme (InvBS). Jedem PC ist genau ein Bildschirm zugeordnet.

Anforderung Teil 1

Für jeden PC wird folgendes festgehalten: der Prozessortyp (Proz), die Größe des Arbeitsspeichers (ArbSp), ob ein optisches Laufwerk (DVD, CD-ROM, usw.) vorhanden ist und welche Bezeichnung und Geschwindigkeit (BezLW bzw. Geschw) es hat. Es können durchaus mehrere optische Laufwerk eines Typs in einen PC eingebaut sein (z.B. zu Archivierungszwecken), so dass auch die Anzahl festgehalten wird. Natürlich gibt es einen Laufwerkstyp durchaus in verschiedenen Rechnern.

Für alle PCs wird festgehalten, ob Programmiersprachen (PS) installiert sind und falls ja, welche. Für die PCs der Entwickler wird die hauptsächlich verwendete Entwicklungsumgebung (EntwUmg) vermerkt.

Da PCs nicht nur identifiziert, sondern auch beschrieben werden, stellen sie eine Relation dar. Mit den Attributen, die im Text genannt werden und die "keine Probleme" machen ergibt sich der nachfolgende Erstentwurf.

Relation PC

Die Bildschirme tauchen hier nur mit einem identifizierenden Attribut auf. Ein Blick weiter nach unten in der Beschreibung zeigt, dass sie weiter beschrieben werden. Also können wir auch dafür eine Relation anlegen. Außerdem ist angegeben, dass jedem PC ein Bildschirm zugeordnet ist, so dass wir auch gleich in PC einen Fremdschlüssel einfügen können.

PC (#InvPC, InvBS, Proz, ArbSp, ...)

BS-Einzeln (#InvBS, ...)

Die optischen Laufwerke werden selbst existent, weil sie identifiziert und beschrieben werden. Zu beachten ist, dass sie auf Typebene erfasst sind, was auch im Schlüssel ("Bezeichnung") zu erkennen ist. Mit der Festlegung, dass ein PC auch mehrere optische Laufwerke enthalten kann, ergibt sich damit [Anmerkung] :

Optische Laufwerke,
auf Typebene

OptLw (#BezLW, Geschw)

OptLwPC (#(BezLW, InvPC), Anzahl)

Man beachte die eingeschränkte Aussagekraft einer solchen Modellierung. Festgehalten wird nicht, welche konkreten Laufwerke in den PC eingebaut sind, sondern nur, wieviele verschiedene Laufwerkstypen. Schon bei der Angabe eines einzigen Typs können dies beliebig viele konkrete Laufwerke sein.

Die Installation der Programmiersprachen wird durch eine eigene Relation festgehalten. Der Schlüssel ergibt sich daraus, dass auf einem PC mehrere Programmiersprachen und eine Programmiersprache auf mehreren PCs installiert ist.

PS-Install (#(InvPC, ProgSpr))

Die Hinweise auf die PCs der Entwickler führen zu einer Spezialisierung. Es entsteht eine eigene Relation mit dem zusätzlichen Attribut.

Muster Gen/Spez

EntwPC (#InvPC, EntwUmg)

Bei den Bildschirmen klärt sich die Modellierungssituation im letzten Teil der Anforderungsliste:

Bildschirme

Für Bildschirme wird neben der Bezeichnung (BezBS) noch festgehalten, von welcher Art (Art) sie sind, welchen Durchmesser sie haben (Zoll) und wann sie übergeben wurden (DatÜb).

Anforderung Teil 2

Damit ergibt sich, dass zu Beginn zu Recht die Einzelinformation zu Bildschirmen angelegt wurde (lag ja auch nahe, angesichts des Schlüssels InvBS). Insgesamt ergeben die Attribute aber auch noch eine Relation mit Typinformation zu den Bildschirmen:

Muster Einzel/Typ

BS-Einzeln (#InvBS, BezBS, DatÜb)

BS-Typen (#BezBS, Art, Zoll)

Der Fremdschlüssel ist nötig, damit die Einzelinformationen mit den Typinformationen verknüpft werden können. Der nächste Abschnitt der Spezifikation legt fest, welche Komponenten auf welche Weise erfasst werden.

Komponentenpräzisierung

In diesem Unternehmen wird vor der Übergabe des PC an den Nutzer durch die IT geprüft, ob das Gehäuse, die jeweilige Hauptplatine und die Grafikkarte für die Anforderungen des Nutzers geeignet sind. Falls nicht, werden sie ausgetauscht. Deshalb werden diese drei Komponenten in der Datenbank ausgewiesen. Alle mit ihrer Bezeichnung (BezGH, BezHP, BezGK), die Gehäuse noch mit Größenangaben (Größe), die Hauptplatinen mit der Anzahl der Prozessoren (AnzProz) und die Grafikkarten mit ihrer maximalen Auflösung (Auflösung). Natürlich kommt es vor, dass diese Komponenten in mehreren PC eingebaut werden.

Anforderung Teil 3 -.

Da alle drei Komponenten mit ihren Bezeichnungen erfasst werden, liegt Typinformation vor. Es handelt sich um eine 1:n-Beziehung zwischen den Komponenten und den PCs, woraus sich die Schlüssel ergeben.

1:n-Beziehung und Muster Einzel/Typ

Gehäuse (#(BezGH, InvPC), Größe)

Grafikkarten (#(BezGK, InvPC), Auflösung)

Hauptplatinen (#(BezHP, InvPC), AnzProz)

Auch die Festplatten werden so beschrieben, dass sie eigene Relationen bilden und dass Einzel- und Typinformation vorhanden ist.

Festplatten

Für jede Festplatte wird die Bezeichnung (BezPl), die Speicherkapazität (Größe) sowie die Zugriffsgeschwindigkeit (Zugriff) erfasst. Jede Festplatte erhält von der IT-Abteilung eine eindeutige Seriennummer (SerNrF), angelehnt an die des Festplattenherstellers und wird ausführlich getestet. Das Ergebnis, ein Qualitätskoeffizient (Qual), wird auch festgehalten. Es kommt durchaus vor, dass ein PC mehrere Festplatten hat, aber nicht umgekehrt.

Anforderung Teil 4

Es ergeben sich die entsprechenden Relationen. Hier soll zusätzlich der Frage nachgegangen werden, wie in einem solchen Fall - wenn also Einzel- und Typinformation vorliegt - die Verknüpfung mit dem restlichen Modell (hier PC) vorgenommen wird. Grundsätzlich ist beides möglich, allerdings ist die Verknüpfung mit Typinformation ungenau. Dabei würde nur erfasst, welcher Plattentyp in einem PC installiert ist. Wird dagegen mit Hilfe der Einzelinformation verknüpft, kann genau festgehalten werden, welche und wieviele Festplatten im PC sind. Deshalb wird hier dieseVorgehensweise gewählt. Da eine einzelne Festplatte nur in einem einzigen PC sein kann, handelt es sich um eine 1:n-Beziehung, die durch den Fremdschlüssel InvPC in FP-Einzeln ausgedrückt wird.

Relationale Verknüpfung mit Typ- oder Einzelinformation

FP-Einzeln (#SerNrF, Qual, BezPL, InvPC)

FP-Typen (#BezPl, Größe, Zugriff)

Der folgende Ausschnitt aus der Spezifikation klärt das Umfeld der im Unternehmen eingesetzten PCs.

Außerdem werden jeweils mit Hilfe einer Kurzbezeichnung (KBezSK) die im PC enthaltenen sonstigen Komponenten (W-LAN-Komponente, Kamera, usw.) festgehalten. Natürlich kommt eine bestimmte Komponente in mehreren PCs vor. Außerdem hat ein PC typischerweise mehrere solcher "sonstigen Komponenten".

Anforderung Teil 5

Auch hier wird wieder auf Typebene modelliert, so dass sich die folgende Relation ergibt.

Sonstige Komponenten

SK (#(KBezSK, InvPC)) //SK : Sonstige Komponenten

Abschließend wird in der Spezifikation beschrieben, wie die Nutzung und Einrichtung datenbankmäßig modelliert wird.

Für jeden ins Unternehmen gegebenen PC wird weiterhin festgehalten, wer ihn nutzt, erfasst über die Personalnummer (PersNr), Name, Vorname (VName) sowie Telefonnummer (Tel) und wann er dort eingerichtet wurde (DatEinr). Ein bestimmter PC wird immer von genau einem Angestellten genutzt, ein Angestellter kann bis zu zwei PC zugeordnet bekommen.

Anforderung Teil 6 - Nutzung

Die Nutzer werden über die Personalnummer erfasst und durch einige weitere Attribute beschrieben.

Nutzer (#PersNr, Name, VName, Tel)

Bleibt die Einrichtung des PCs. Angesichts der Festlegung der Min-/Max-Angaben wird das Attribut PersNr zu einem Bestandteil von PC. Auch das Datum der Einrichtung kann in diese Relation eingefügt werden, die sich damit wie folgt ergibt:

PC (#InvPC, InvBS, Proz, ArbSp, PersNr, DatEinr)

Damit sind die Relationen des Datenmodells zusammengestellt. Auch die relationalen Verknüpfungen sind schon angelegt.

Das gesamte relationale Datenmodell

Zuerst die textliche Notation:

BS-Einzeln (#InvBS, BezBS, DatÜb)

BS-Typen (#BezBS, Art, Zoll)

EntwPC (#InvPC, EntwUmg)

FP-Einzeln (#SerNrF, Qual, BezPL, InvPC)

FP-Typen (#BezPl, Größe, Zugriff)

Gehäuse (#(BezGH, InvPC), Größe)

Grafikkarten (#(BezGK, InvPC), Auflösung)

Hauptplatinen (#(BezHP, InvPC), AnzProz)

Nutzer (#PersNr, Name, VName, Tel)

OptLw (#BezLW, Geschw) //Typebene

OptLwPC (#(BezLW, InvPC), Anzahl) //Typebene

PC (#InvPC, InvBS, Proz, ArbSp, PersNr, DatEinr)

PSInstall (#(InvPC, ProgSpr))

SK (#(KBezSK, InvPC)) //Sonstige Komponenten

Die folgende Abbildung zeigt die grafische Fassung des Datenmodells.

Abbildung 16.3-1: Datenmodell PC-Beschaffung

HP: Hauptplatine, Motherboard

EntwPC: Entwickler-PC

16.4 Fachliteratur

Im Anwendungsbereich Fachliteratur sollen alle wichtigen Typen von Fachliteratur erfasst werden. Zweck der Datenbank ist es, die Literatur zu erfassen, die Suche nach Fachliteratur zu ermöglichen und von Zeit zu Zeit eine Literaturliste wie die nachfolgende zu erstellen (z.B. für eine Bachelor- oder Masterarbeit).

Die wichtigsten Arten von Fachliteratur sind:

Monographien (Mono). Dies sind Bücher, die ein zusammenhängendes Werk darstellen und die von einem Autor oder mehreren verfasst sind.

Sammelbände (SB). Auch diese sind Bücher. Allerdings hat hier jedes Kapitel einen eigenen Autor oder mehrere. Die Autoren des Sammelbandes insgesamt werden Herausgeber genannt.

Die Beitrag in einem Sammelband (SBB). Dies sind die einzelnen Kapitel in Sammelbänden. Da diese ja spezielle Themen betreffen und eigene Autoren haben, werden sie als eigenständige Werke in der Datenbank erfasst. Zum Beispiel, um sie bei einer inhaltlichen Suche zu finden.

Artikel in Fachzeitschriften (Zeitschriftenartikel, ZSA). Dies sind Werke, die in einer Zeitschrift erschienen sind.

Internetquellen (IQU). Dies sind Werke von Internetseiten, z.B. Forschungsberichte, Firmenmitteilungen, usw.

Ergänzend werden Zeitschriften (ZS) erfasst, als Trägermedium der Zeitschriftenartikel (ZSA).

Diese Unterscheidung von Literaturarten ist wichtig, weil sie teilweise unterschiedlich beschrieben werden. Zum Beispiel in einer Literaturliste, wie sie bei einer akademischen Abschlussarbeit meist anfällt:

Scheer, August-Wilhelm: Wirtschaftsinformatik. Referenzmodell für industrielle Geschäftsprozesse (5. Auflage), Berlin et al. 1994 (Springer-Verlag)

Beispiele für eine Monographie (Mono)

Österle, H.; Brenner, W.; Hilbers, K. et al.: Unternehmensführung und Informationssystem, Stuttgart 1992 (XYZ-Verlag)

Also: Name; Vorname; Titel; Ort (des Verlags); Erscheinungsjahr; Verlag, bei dem das Buch erschienen ist. Die Gestaltung mit Punkten, Strichpunkten, Kommata und die Einordnung der Verlagsangabe ist nur eine Empfehlung.

Reussner, Ralf; Hasselbring, Wilhelm (Hrsg.), Handbuch der Software-Architektur (2. Auflage). Heidelberg 2009 (dpunkt)

Beispiel für einen Sammelband (SB)

Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Hrsg.): Prozessmanagement. Ein Leitfaden zur Prozessorientierten Organisationsgestaltung (5. Auflage). Berlin u.a. 2005 (Springer)

Also: Namen und Vornamen; Hinweis auf die Herausgeberschaft; Titel; Untertitel, falls vorhanden; Hinweis auf Auflage, falls nicht die erste; Verlagsort(e); Erscheinungsjahr; Angabe Verlag, falls möglich.

Hansmann, Holger; Laske, Michael; Luxem, Redmer: Einführung der Prozesse - Prozess-Roll-out. In: [Becker, Kugeler, Rosemann (Hrsg.) 2005], S. 269 - 298.

Beispiele für einen Beitrag in einem Sammelband (SBB)

Baier, Achim; Becker, Steffen; Jung, Martin u.a.: Modellgetriebene Software-Entwicklung . In: [Reussner, Hasselbring (Hrsg.) 2009], S. 93 - 122

Also: Namen und Vornamen, bei mehr als drei Autoren der Zusatz "u.a." (und andere) oder "et al"; Titel; das Wort "In", das verdeutlicht, dass jetzt das übergeordnete Werk (der SB) folgt; bibliographische Angaben des Sammelbandes, in dem der SBB enthalten ist; Seitenangaben: erste und letzte Seite des SBB.

Wirth, N.: Gedanken zur Software-Explosion. In: Informatik Spektrum, Februar 1994, S. 5 - 10.

Beispiele für einen Artikel in einer Zeitschrift (ZSA)

Czarski, Carsten: Richtig gefragt. Konstrukte für komplexe Datenbank-Queries. In: iX, Januar 2013, S. 154 - 157.

Schulz, Hajo: Objektorientiert programmieren mit Smalltalk. In: c’t kompakt Programmieren, Heft 03/2012, S. 146 - 152

Also: Namen und Vornamen; Titel, evtl. Untertitel; Bezeichnung der Zeitschrift, Angaben zum konkreten Heft der Zeitschrift; erste und letzte Seite des Artikels.

Grundstruktur

Bevor wir in die eigentliche Modellierung einsteigen, hier einige Ausführungen zur Erfassung von Fachliteratur und zu den einzelnen Arten, die es hier gibt. Zu jeder Fachliteratur, egal ob sie als Buch, Zeitschriftenaufsatz oder sonstwie erscheint, gehört ein Text, dieser wird Werk genannt. Er soll hier durch eine WerkNr identifiziert werden. Jedes Werk hat eine Person bzw. Organisation (Forschungseinrichtungen, Behörden, ... oder mehrere (schon bald Programme!), die es verfasst haben. Diese Autoren werden ebenfalls erfasst und durch eine Autorennummer identifiziert (AutorNr). Da es zwei Gruppen von Autoren mit teilweise abweichenden Attributen gibt, müssen dafür zwei verschiedene Relationen angelegt werden, Organisationen als Autoren (Aut-Org) und Personen als Autoren (AutPers). Es entsteht also eine Gen/Spez-Hierachie.

Werke – Autoren - Autorenschaft

In die Generalisierung kommt der Name (bei Personen) bzw. die Unternehmensbezeichnung. Dieses Attribut wird hier Id1 genannt. In den beiden Spezialisierungen folgen dann die übrigen beschreibenden Attribute. BezInst (Bezeichnung Institution) sollen die Attribute zur weiteren Bezeichnung der Organisation genannt werden.

Generalisierung / Spezialisierung (GenSpez)

Werke und Autoren sind durch die Autorenschaft verbunden: Hier wird festgehalten, wer welches Werk verfasst hat. Da es sich um eine n:m-Verknüpfung handelt, ergibt sich eine Verbindungsrelation. Das folgende Modellfragment gibt diesen "Kern" des Datenmodells an.

Ein Autor kann mehrere Werke veröffentlichen, ein Werk kann mehrere Autoren haben.

Abbildung 16.4-1: Autorenschaft im Anwendungsbereich Fachliteratur

Nehmen wir noch dazu, dass bei Werken mit mehreren Autoren die Reihenfolge der Autorennennungen wichtig ist, ergibt sich für die Relation Autorenschaft ein beschreibendes Attribut Rang (an welcher Stelle der Autorenliste kommt er oder sie). Insgesamt liegen dann in textlicher Form folgende Relationenfragmente vor:

Autoren (#AutorNr, Id1)

AutPers (#AutorNr, VName, Anrede)

AutOrg(#AutorNr, BezOrg2, BezOrg3)

Werke (#WerkNr, ...)

Autorenschaft (#(AutorNr, WerkNr), Rang)

Modellierung der Literaturtypen

Die obige Liste von Werken machte den weitergehenden Aufbau der verschiedenen Literaturarten deutlich. In der folgenden Tabelle sind diese Informationen zusammengefasst. Es handelt sich hier um eine Generalisierung/Spezialisierung (vgl. Abschnitt 14.1).

Typen bewältigen durch Gen/Spez

Werke und ihre Attribute aus der Gen/Spez-Hierarchie

Mono

SB

SBB

ZSA

IQU

A

Autoren: Personen oder Organisationen, u.U. mehrere

Ja

Ja

Ja

Ja

Ja

B

Titel

ggf. Untertitel: UTitel

Ja

Ja

Ja

Ja

Ja

C

ISBN-Nummer: ISBN

Ja

Ja

-

-

-

D

Auflage

Ja

Ja

-

-

-

E

Erscheinungsjahr: Jahr

Ja

Ja

-

-

-

F

Verlagsort/e, u.U. mehrere: Ort

Ja

Ja

-

-

-

G

Verlagsbezeichnung: BezVerlag

U.U. mehrere

Ja

Ja

-

-

-

H

Von (erste Seite des SBBs bzw. ZSAs)

-

-

Ja

Ja

-

I

Bis (letzte Seite des SBBs bzw. ZSAs)

-

-

Ja

Ja

-

J

Quelle (SB + Kapitel, in dem der SBB enthalten ist):

WerkNr, KapitelNr

-

-

Ja

-

-

K

Quelle (Name und Heft der Zeitschrift, in dem der ZSA enthalten ist):

ZSBez, HeftNr

-

-

-

Ja

-

L

URL

-

-

-

-

Ja

M

Tag des Abrufs:

AbrTag

-

-

-

-

Ja

N

Anzahl der Kapitel in Sammelbänden:

AnzKap

-

Ja

-

-

-

Zeile A ...

sagt, dass alle Werke Autoren haben, die entweder Personen oder Organisationen sind. Dies wurde schon angelegt.

Zeile B ...

gibt den Hinweis auf ein Attribut, das alle verschiedenen Werke haben, den Titel. Außerdem auf eine Spezialisierung von Werke, nämlich Werke mit Untertiteln:

Werke (#WerkNr, Titel, …)

WerkeUT (#WerkNr, UT)

Zeilen C bis G ...

zeigen, dass MONographien (Mono) und SammelBände (SB) die 5 Attribute ISBN, Auflage, Jahr, Ort und BezVerlag gemeinsam haben, womit eine weitere Spezialisierung von Werke entsteht. In die Spezialisierung kommen aber nur drei Attribute, da die Verlagsangaben mehrfach vorkommen können, wenn ein einzelnes Werk von mehreren Verlagen herausgegeben wird. Dazu unten mehr.

Mono+SB (#WerkNr, ISBN, Auflage, Jahr)

Zeilen F und G: vgl. unten

Zeilen H und I ...

geben Attribute an, die nur SBB und ZSA besitzen. Für sie entsteht also eine Spezialisierung:

SBB+ZSA (#WerkNr, Von, Bis)

Zeile J ...

zeigt, dass Sammelbandbeiträge (SBB) eine weitere spezifische Information haben, die Angabe, von welchem Sammelband sie stammen (Quelle). Sie besteht aus zwei Attributen: Werknummer des Sammelbandes (WerkNrSB) und die KapitelNr im Sammelband. Somit entsteht die folgende Relation:

SBB (#WerkNr, WerkNrSB, KapitelNr)

Muster Komposition. Damit liegt eine Komposition zwischen Sammelbandbeiträgen und Sammelbänden vor. Falls ein Sammelband aus dem Buchbestand und damit aus der Datenbank entfernt wird, müssen auch die Sammelbandbeiträge dieses Sammelbands entfernt werden. Die Gestaltung des Schlüssels ergibt sich daraus, dass jeder SBB eine eindeutige Werknummer erhält und auch nur in genau einem SB enthalten ist [Anmerkung] .

Komposition zwischen SBB und SB, als 1:n-Beziehung

Zeile K ...

zeigt, dass die Zeitschriftenaufsätze ebenfalls eine spezifisches Information haben, die Quellenangabe. Sie besteht (im einfachsten Fall) aus zwei Attributen, Zeitschriftenbezeichnung (ZSBez) und Heftnummer (HeftNr):

ZSA (#WerkNr, ZSBez, HeftNr)

Zeilen L, M und N ...

führen zu weiteren Spezialisierungen von Werke, zu Internetquellen (IQU) und zu Sammelbänden (SB). Für die Internetquellen wird die URL und der Tag des Abrufs (AbrTag) angegeben, für die Sammelbände die Anzahl der Kapitel, die sie enthalten (AnzKap):

IQU (#WerkNr, URL, AbrTag)

SB (#WerkNr, AnzKap)

Insgesamt ergibt sich damit folgendes Datenmodell:

IQU (#WerkNr, URL, AbrTag)

ZSA (#WerkNr, ZSBez, HeftNr)

AutOrg(#AutorNr, BezOrg2, BezOrg3)

Autoren (#AutorNr, Id1)

Autorenschaft (#(AutorNr, WerkNr), Rang)

AutPers (#AutorNr, VName, Anrede)

Mono+SB (#WerkNr, ISBN, Auflage, Jahr)

SB (#WerkNr, AnzKap)

SBB (#WerkNr, WerkNrSB, KapitelNr)

SBB+ZSA (#WerkNr, Von, Bis)

Werke (#WerkNr, Titel)

WerkeUT (#WerkNr, UT)

Die folgende Abbildung mit dem Ausschnitt zur Gen/Spez der Werke und zur Komposition zwischen SBB und SB verdeutlicht dieses Strukturmerkmal. Die Beziehungswertigkeiten zeigen zum einen die zwischen jeder Spezialisierung und ihrer Generalisierung (Kardinalität 1:1, Min-/Max-Angaben 0,1 : 1,1), zum anderen die bei einer Komposition, hier zwischen SB und SBB. Die Null bei der Wertigkeit bedeutet, dass es auch Sammelbände gibt, von denen keine Sammelbandbeiträge erfasst sind. Der Fremdschlüssel Fach in Werke wird unten erläutert.

Wertigkeiten

Abbildung 16.4-2: Gen/Spez zu Literaturarten und Muster Komposition im Anwendungsbereich Fachliteratur

Noch mehr Anforderungen

Erfasst werden soll außerdem, welches Werk von welchem Verlag verfasst wurde. Es kommt auch vor, dass mehrere Verlage zusammen ein Buch publizieren. Bei den Verlagen wird der Ansprechpartner (AnsprV), die allgemeine Telefonnummer (Tel) und die des Ansprechpartners (TelAP) erfasst, für die Adressen der Verlage und die Adressen der Autoren PLZ, Ort und Straße. Von einem Verlag wird nur die Hauptadresse erfasst, von einem Autor mehrere. Es gibt auch Adressen, unter denen mehrere Autoren wohnen. Daraus ergeben sich die folgenden Relationen. Die Veröffentlichungstätigkeit wird als n:m-Verbindung zwischen Verlagen und Werken angesetzt. Die Adressen der Verlage werden durch einen Fremdschlüssel in Verlage integriert. Für die Adressen der Autoren gibt es eine Verbindungsrelation.

Verlage und Publikationen

Neue und veränderte Relationen

Verlage (#VerlNr, #BezVerlag,Tel, AnsprV, TelAP, AdrNr)

Publikationen (#(VerlNr, WerkNr))

Adressen (#AdrNr, PLZ, Ort, Straße)

AutOrg(#AutorNr, BezInst2, BezInst3, AdrNr)

AutPersAdr (#(AutorNr, AdrNr))

Für die Literatursuche sollen die Werke auch inhaltlich erschlossen werden. Dazu werden für jedes Werk ein Schlagwort (BezSchl) oder mehrere erhoben, z.B. Softwareentwicklung, Datenbankdesign, HTML 5, NoSQL. Jedes Schlagwort wird kurz beschrieben (Beschr), um die exakte Bedeutung zu klären. Dies führt zu folgenden neuen Relationen.

Inhaltliche Erschließung

WSchl (#(WerkNr, BezSchl))

Schlagw (#BezSchl, Beschr)

Ebenfalls erfasst werden soll ein Fachgebiet pro Werk. D.h. jedes Werk erhält eine Fachgebietszuordnung (Medizin, Technik, Informatik, ...). Diese werden regelmäßig ausgezählt, die Ergebnisse werden auch in der Datenbank verwaltet.

"Wieviele Werke liegen zu jedem Fachgebiet vor"

AnzFG (#Fachgebiet, Anzahl)

Das gesamte Datenmodell

Insgesamt ergeben sich damit folgende Relationen:

Adressen (#AdrNr, PLZ, Ort, Straße)

AnzFG (#Fachgebiet, Anzahl) //Anzahl Werke in den Fachgebieten

Autoren (#AutorNr, Id1, Typ) //Name bzw. Organisationsbezeichnung

Autorenschaft (#(AutorNr, WerkNr), Rang)

AutOrg(#AutorNr, BezInst2, BezInst3, AdrNr) //Organisationen als Autoren

AutPers (#AutorNr, VName, Anrede) //Personen als Autoren

AutPersAdr (#(AutorNr, AdrNr)) //n:m, Autorenadressen

IQU (#WerkNr, URL, AbrTag) //Internetquellen

Mono+SB (#WerkNr, ISBN, Auflage, Jahr) //Monographien und Sammelbände

Publikationen (#(VerlNr, WerkNr)) //Verlage und Veröffentlichungen

SB (#WerkNr, AnzKap) //Sammelbände

SBB (#WerkNr, WerkNrSB, KapitelNr) //Beiträge in Sammelbänden

SBB+ZSA (#WerkNr, Von, Bis) //Seitenzahlen

Schlagw (#BezSchl, Beschr) //Schlagworte

Verlage (#VerlNr, #BezVerlag,Tel, AnsprV, TelAP, AdrNr) //Verlage

Werke (#WerkNr, Titel, Fach) //Textliche Werke (Fachliteratur)

WerkeUT (#WerkNr, UT) //Werke mit Untertiteln

WSchl (#(WerkNr, BezSchl)) //Verschlagwortung

ZSA (#WerkNr, ZSBez, HeftNr) //Zeitschriftenaufsätze

Die folgende Abbildung zeigt die grafische Darstellung des Datenmodells. Einige beispielhafte Wertigkeiten wurden auch eingefügt. Ein Beispiel für die Wertigkeiten einer n:m-Verknüpfung ist bei Autorenschaft angegeben. Die Min-/Max-Angaben signalisieren, dass nur Autoren aufgenommen werden, die auch mindestens 1 Werk in der Datenbank aufweisen und dass Werke nicht ohne zugehörigen Autor erfasst werden.

Grafische Notation

Abbildung 16.4-3: Relationales Datenmodell zum Anwendungsbereich Fachliteratur

Abkürzungen in den Datenmodellen zur Fachliteratur

ZS: Zeitschriften

ZSA: Zeitschriftenartikel

SB: Sammelbände

SBB: Beiträg in einem Kapitel eines Sammelbandes

Mono: Monographien

IQU: Internetquellen

16.5 Hochschule – Vorlesungsbetrieb

Hier wird der Anwendungsbereich Vorlesungsbetrieb einer Hochschule betrachtet. Folgendes soll erfasst werden:

Für die Lehrveranstaltungen eine Veranstaltungsnummer (LVNr), ihre Bezeichnung (BezV), der Typ des zugehörigen Studienganges (Master, Bachelor, Diplom) (TypSG), die Bezeichnung des Studienganges (WI, AI, ...), der die Lehrveranstaltung durchführt (BezSG), die Credit Points (cp) und die Anzahl Semesterwochenstunden (SWS). Außerdem, in welchem Studiensemester die Lehrveranstaltung abzuhalten ist (SemPlan). Für jeden konkreten Termin der Lehrveranstaltungen wird festgehalten an welchem Tag er statt fand (Tag), wann er begann (Beginn) und wann er endete (Ende). Also z.B. Mittwochs, 8.00 - 9.30 Uhr. Die Räume werden ebenfalls erfasst, mit einer Typisierung (ArtRaum; DV-Raum, Vorlesungsraum, Labor, ...), der Größe (Groesse), der Ausstattung mit Beamern und Intranet (BeamerJN, IntranetJN) und dem Gebäude, in dem sie sich befinden (GebBez). Dabei geht man davon aus, dass in einem Semester eine Lehrveranstaltung immer in demselben Raum stattfindet. In verschiedenen Semestern kann die Lehrveranstaltung aber natürlich in jeweils anderen Räumen sein.

Die Studierenden werden durch ihre Matrikelnummer (MatrNr), den Namen, Vornamen (VName) und ein E-Mail-Postfach (E-Mail) erfasst. Für sie wird außerdem festgehalten, in welchem Semester sie welche Lehrveranstaltung besucht haben. Es kommt durchaus vor, dass ein Studierender eine bestimmte Lehrveranstaltung mehrfach besuchen muss. Sozusagen in den "Stammdaten" der Studierenden ist außerdem vermerkt, wann das Studium begann (BegStudium), wann es endet(e) (EndeStudium), in welchem Studiengang (SG) sie eingeschrieben sind und in welchem Fachsemester sie sich befinden (FachSem).

Für die Studierenden werden beliebig viele Adressen (PLZ, Ort, Strasse) zugelassen. Eine davon muss als die gekennzeichnet sein, zu der die Mitteilungen der Hochschule gesandt werden.

Die Dozenten werden durch eine Dozentennummer (DozNr), den Namen, Vornamen (VName), die Anrede sowie ein E-Mail-Postfach erfasst. Für die Dozenten der Hochschule sollen zusätzlich auch die Nummer ihres Büros (BüroNr), ihre interne Telefonnummer (IntTel), ihre Sprechstunde (SprSt), ihre Fakultät und die Angabe des Gebäudes, in dem sich das Büro befindet (GebBez), angegeben werden. Für diese Gebäude wird noch festgehalten, in welchem Ort sie sich befinden (Ort), welche Straßenadresse sie haben (Straße, z.B. Hauptstr. 8) und welcher DV-Betreuer für das Gebäude zuständig ist (Straße, DVBetr). Es gibt an dieser Hochschule auch externe Dozenten. Für diese wird die Adresse erfasst (nur eine), welchen akademischen Abschluss sie haben (AkAb) und in welcher Organisation (Unternehmen, andere Hochschule, ...) sie arbeiten. Deren Adresse wird, für die Zusendung von Lehraufträgen usw., ebenfalls erfasst.

Zum Lehrbetrieb soll in der Datenbank festgehalten werden, welcher Dozent welche Lehrveranstaltung gehalten hat. Üblicherweise hält ein Dozent mehrere Lehrveranstaltungen in einem Semester und dieselbe Lehrveranstaltung kann in verschiedenen Semestern von unterschiedlichen Dozenten gehalten werden. Kein Dozent hält in einem Semester eine Lehrveranstaltung mehrfach.

Auch der Besuch von Lehrveranstaltungen durch Studierende wird mit Angabe des Semesters erfasst. Es soll möglich sein, dass ein Studierender mehrfach für eine Lehrveranstaltung eingeschrieben ist (Wiederholungen).

Alle Prüfungen beziehen sich immer auf genau eine Lehrveranstaltung. Jeder wird eine Prüfungsnummer (PrüfNr) und eine Bezeichnung (Bez) zugewiesen. Bei allen Prüfungen wird der Prüfungstag festgehalten (Datum). Bei Klausuren (KL) und mündlichen Prüfungen (MP) auch die Länge. Bei mündlichen Prüfungen zusätzlich der Prüfer (dies ist immer nur genau einer; PrüfPersNr). Dieser kann interner oder auch externer Dozent sein. Praktische Arbeiten (PA) sind Leistungen wie Erstellung eines Datenmodells, Modellierung eines Prozesses, usw. Laborarbeiten (LA) sind solche, für die ein Labor und die Unterstützung des zuständigen Laborbetreuers benötigt wird. Beide finden in einem bestimmten Zeitraum statt, der ebenfalls in der Datenbank erfasst werden soll (Start, Ende). Bei Laborarbeiten sind zusätzlich die Laborbezeichnung (LabBez; EBUS-Labor, Mikrocomputerlabor, ERP-Labor, ...) und der Laborbetreuer mit Namen und Vornamen zu erfassen (LabBetrN, LabBetrVN).

Der Besuch einer Prüfung bezieht sich immer auf eine Lehrveranstaltung. Festgehalten wird zu jeder Prüfung das Semester, in dem sie stattfindet (Sem), das genaue Datum, um welchen Versuch es sich handelt (1. Versuch, 2. Versuch, ...) und welche Note erzielt wurde.

Der Lösungsweg

Für die Lösung werden obige Anforderungen abschnittsweise angeführt, durch Einrückung hervorgehoben und ausgewertet.

Für die Lehrveranstaltungen eine Veranstaltungsnummer (LVNr), ihre Bezeichnung (BezV), der Typ des zugehörigen Studienganges (Master, Bachelor, Diplom) (TypSG), die Bezeichnung des Studienganges (WI, AI, ...), der die Lehrveranstaltung durchführt (BezSG), die Credit Points (cp) und die Anzahl Semesterwochenstunden (SWS). Außerdem, in welchem Studiensemester die Lehrveranstaltung abzuhalten ist (SemPlan). Für jeden konkreten Termin der Lehrveranstaltungen wird festgehalten an welchem Tag er war (Tag), wann er begann (Beginn) und wann er endete (Ende). Also z.B. Mittwochs, 8.00 - 9.30 Uhr. Die Räume werden ebenfalls erfasst, mit einer Typisierung (ArtRaum; DV-Raum, Vorlesungsraum, Labor, ...), der Größe (Groesse), der Ausstattung mit Beamern und Intranet (BeamerJN, IntranetJN) und dem Gebäude, in dem sie sich befinden (GebBez). Dabei geht man davon aus, dass in einem Semester eine Lehrveranstaltung immer in demselben Raum stattfindet. In verschiedenen Semestern kann die Lehrveranstaltung aber natürlich in jeweils anderen Räumen sein.

Anforderung Teil 1

Auf Grund der Beschreibung kann angenommen werden, dass es nicht um fixe Wochenpläne geht, sondern um flexible, also um Einzeltermine. Dass trotzdem die meisten dann in jeder Woche zum selben Zeitpunkt stattfinden soll nicht stören.

Die Lehrveranstaltungen selbst sind sofort erkennbar, da sie identifiziert und durch zahlreiche Attribute beschrieben werden (LV). Für die Termine der Lehrveranstaltungen ergibt sich ein Schlüssel, wie er oft bei zeitlich fixierten Vorgängen auftritt. Der eigentliche Gegenstand, hier die Veranstaltungstermine, muss mit einem "Zeitstempel" versehen werden. Dabei genügen hier Tag und Beginn, da damit der Schlüssel eindeutig wird (LVTermine).

Lehrveranstaltungen und ihre Termine

Auch die Räume sind oben angesprochen. Ihre Modellierung bereitet keine Probleme. Bei den Gebäude muss geprüft werden, ob sie später noch beschrieben werden. Da dies der Fall ist, wird die Gebäudebezeichnung hier als Fremdschlüssel aufgenommen.

Räume

Die Ausführungen in der Anforderung zu den Räumen für die Lehrveranstaltungen sind etwas unklar und müssen präzisiert werden. Nimmt man die Räume zu den Terminen hinzu entsteht Redundanz, denn es ist ja in einem Semester immer derselbe Raum, in dem die Lehrveranstaltung stattfindet. Deshalb muss eine eigene Relation eingerichtet werden, die an einer einzigen Stelle für eine Lehrveranstaltung und ein ganzes Semester den Raum festhält.

Damit ergeben sich folgende Relationen:

LV (#LVNr, BezLV, TypSG, BezSG, SemPlan, cp, SWS)

LVRaum (#(LVNr, Sem), Raum)

LVTermine (#(LVNr, Tag, Beginn), Ende)

Räume (#RaumNr, ArtRaum, Groesse, BeamerJN, IntranetJN, GebBez)

Die Studierenden werden durch ihre Matrikelnummer (MatrNr), den Namen, Vornamen (VName) und ein E-Mail-Postfach (E-Mail) erfasst. Für sie wird außerdem festgehalten, in welchem Semester sie welche Lehrveranstaltung besucht haben. Es kommt durchaus vor, dass ein Studierender eine bestimmte Lehrveranstaltung mehrfach besuchen muss. Sozusagen in den "Stammdaten" der Studierenden ist außerdem vermerkt, wann das Studium begann (BegStudium), wann es endet(e) (EndeStudium), in welchem Studiengang (SG) sie eingeschrieben sind und in welchem Fachsemester sie sich befinden (FachSem).

Anforderung Teil 2

Für die Studierenden werden beliebig viele Adressen (PLZ, Ort, Strasse) zugelassen. Eine davon muss als die gekennzeichnet sein, zu der die Mitteilungen der Hochschule gesandt werden.

Hieraus ergeben sich mehrere Relationen. Die erste zu den Studierenden. Sie werden durch die Matrikelnummer identifiziert und durch die angegebenen weiteren Attribute beschrieben. Die Aufnahme von EndeStudium verstößt ja eigentlich gegen eine der Grundregeln relationaler Datenmodellierung (weil diese Angabe ja erst mal nicht zur Verfügung steht), wird aber aus pragmatischen Gründen akzeptiert.

Die zweite erfasst den Besuch von Lehrveranstaltungen. Es ist eine n:m-Verknüpfung, so dass eine Verbindungsrelation entsteht, allerdings mit einem zusätzlichen Zeitstempel, der Semesterangabe (Sem).

Damit ergibt sich zwischen Studierenden und Adressen eine 1:n-Beziehung. Da unter einer Adresse auch mehrere Studierende wohnen können, gilt auch umgekehrt eine 1:n-Beziehung, insgesamt ensteht also also eine n:m-Beziehung. Diese führt zur Relation Stud-Adr. Mit dem Attribut Art kann festgehalten werden, ob es sich um die Adresse für die Mitteilungen an die Studierenden handelt.

Damit ergeben sich folgende neuen Relationen:

Studierende (#MatrNr, Name, VName, E-Mail, BegStudium, EndeStudium, SG, FachSem)

LVBesuch (#(MatrNr, LVNr, Sem))

Adressen (#AdrNr, Ort, PLZ, Strasse)

StudAdr (#(MatrNr, AdrNr), Art)

Die Dozenten werden durch eine Dozentennummer (DozNr), den Namen, Vornamen (VName), die Anrede sowie ein E-Mail-Postfach erfasst. Für die Dozenten der Hochschule sollen zusätzlich auch die Nummer ihres Büros (BüroNr), ihre interne Telefonnummer (IntTel), ihre Sprechstunde (SprSt), ihre Fakultät und die Angabe des Gebäudes, in dem sich das Büro befindet (GebBez), angegeben werden. Für diese Gebäude wird noch festgehalten, in welchem Ort sie sich befinden (Ort), welche Straßenadresse sie haben (Straße, z.B. Hauptstr. 8) und welcher DV-Betreuer für das Gebäude zuständig ist (Straße, DVBetr). Es gibt an dieser Hochschule auch externe Dozenten. Für diese wird die Adresse erfasst (nur eine), welchen akademischen Abschluss sie haben (AkAb) und in welcher Organisation (Unternehmen, andere Hochschule, ...) sie arbeiten. Deren Adresse wird, für die Zusendung von Lehraufträgen usw., ebenfalls erfasst.

Anforderung Teil 3

Die Lehrkräfte der Hochschule erscheinen hier als externe und interne Dozenten. Da es Attribute für alle Dozenten gibt und spezifische für die beiden Untergruppen liegt eine Gen/Spez-Hierarchie vor. Die gemeinsamen Attribute sind Name, VName, Anrede und E-Mail, sie kommen in die Generalisierung (DOZ-ALLgemein). Von den externen Dozenten [Anmerkung] (DozExtern) wird nur eine einzige Adresse erfasst, somit genügt für das Festhalten der Adresse ein Fremdschlüssel in der Relation. Bei den Dozenten der Hochschule wird angenommen, dass sie nur ein einziges Büro haben. Dessen Gebäude kann als Fremdschlüssel in DozHS erfasst werden. Bleiben noch die Organisationen. Sie haben eine Bezeichnung und eine Adresse, außerdem vergeben wir für sie noch einen Schlüssel. Damit kann die untenstehende Relation Organisationen angelegt werden. Mit dem Fremdschlüssel AdrNr wird diese Relation mit der zu den Adressen verknüpft.

Gen/Spez mit DozAllg, DozExt und DozHS

Damit ergeben sich folgende zusätzlichen Relationen:

DozAllg (#DozNr, Name, VName, Anrede, E-Mail)

DozExt (#DozNr, AkAb, OrgNr, AdrNr)

DozHS (#DozNr, Fakultät, BüroNr, BezGeb, IntTel, SprSt, E-Mail)

Gebäude (#BezGeb, Ort, Straße, DVBetr)

Organisationen (#OrgNr, Bez, AdrNr)

Zum Lehrbetrieb soll in der Datenbank festgehalten werden, welcher Dozent welche Lehrveranstaltung gehalten hat. Üblicherweise hält ein Dozent mehrere Lehrveranstaltungen in einem Semester und dieselbe Lehrveranstaltung kann in verschiedenen Semestern von unterschiedlichen Dozenten gehalten werden. Kein Dozent hält in einem Semester eine Lehrveranstaltung mehrfach.

Anforderung Teil 4

Auch der Besuch von Lehrveranstaltungen durch Studierende wird mit Angabe des Semesters erfasst. Es soll möglich sein, dass ein Studierender mehrfach für eine Lehrveranstaltung eingeschrieben ist (Wiederholungen).

Der Lehrbetrieb wird einfach durch eine Verbindungsrelation mit Angabe des Semesters erfasst. Mit dieser Lösung kann ein Dozent mehrere Lehrveranstaltungen pro Semester halten (was ja meist der Fall ist) und dieselbe Lehrveranstaltung kann in einem Semester von mehreren Dozenten gehalten werden, was allerdings normalerweise nicht der Fall ist. Genau gleich ist die Lösung für den Besuch von Lehrveranstaltungen. Durch das Schlüsselattribut Semester sind auch Wiederholungen erfassbar.

Damit ergeben sich folgende neuen Relationen mit "Zeitstempel":

Lehrbetrieb (#(DozNr, VeranstNr, Sem))

LVBesuch (#(MatrNr, LVNr, Sem))

Alle Prüfungen beziehen sich immer auf genau eine Lehrveranstaltung. Jeder wird eine Prüfungsnummer (PrüfNr) und eine Bezeichnung (Bez) zugewiesen. Bei allen Prüfungen wird der Prüfungstag festgehalten (Datum). Bei Klausuren (KL) und mündlichen Prüfungen (MP) auch die Länge. Bei mündlichen Prüfungen zusätzlich der Prüfer (dies ist immer nur genau einer; PrüfPersNr). Dieser kann interner oder auch externer Dozent sein. Praktische Arbeiten (PA) sind Leistungen wie Erstellung eines Datenmodells, Modellierung eines Prozesses, usw. Laborarbeiten (LA) sind solche, für die ein Labor und die Unterstützung des zuständigen Laborbetreuers benötigt wird. Beide finden in einem bestimmten Zeitraum statt, der ebenfalls in der Datenbank erfasst werden soll (Start, Ende). Bei Laborarbeiten sind zusätzlich die Laborbezeichnung (LabBez; EBUS-Labor, Mikrocomputerlabor, ERP-Labor, ...) und der Laborbetreuer mit Namen und Vornamen zu erfassen (LabBetrN, LabBetrVN).

Anforderung Teil 5

Auch bei den Prüfungen zeichnet sich eine Generalisierung / Spezialisierung ab. Alle erhalten eine Prüfungsnummer (PrüfNr), eine Bezeichnung (Bez), ein Prüfungsdatum (Datum) und den Verweis auf die Lehrveranstaltung , auf die sie sich beziehen. Da sich jede Prüfung auf genau eine Lehrveranstaltung bezieht, ist diese Lösung mit einem Fremdschlüssel korrekt. Für die Klärung der Gen/Spez-Hierarchie wird eine Tabelle erstellt, genau nach den oben formulierten Anforderungen.

Noch eine Gen/Spez

Prüfungsunterschiede

Klausuren (KL)

Mündliche Prüfungen (MP)

Praktische Arbeit

(PA)

Laborarbeit (LA)

PrüfNr

PrüfNr

PrüfNr

PrüfNr

Bez

Bez

BEz

Bez

Datum

Datum

Datum

Datum

Versuch

Versuch

Versuch

Versuch

Länge

Länge

Start

Start

Ende

Ende

PrüfPersNr

LabBez

LabBetrN

LabBetrVN

Damit sind die Spezialisierungen klar. PrüfAllg ist die "oberste" Generalisierung und enthält die Attribute, die alle Relationen aufweisen. Die ersten Spezialisierungen sind PrüfPALA für die gemeinsamen Attribute von PA und LA (Start und Ende) sowie PrüfKLMP für das gemeinsame Attribut von KL und MP (Länge). Es folgen die Spezialisierungen PrüfLA von PrüfPALA und PrüfMP von PrüfKLMP. PrüfLA erhält die Attribute zur Laborbetreuung, PrüfMP die zur prüfenden Person.

Die Relationen PrüfPALA und PrüfKLMP sind "nach oben" Spezialisierungen und "nach unten" Generalisierungen. Die Abbildung mit dem Datenmodell unten verdeutlicht dieses Strukturmerkmal. In dieser Abbildung sind die relationalen Verknüpfungen entlang dieser Spezialisierungshierachie eingezeichnet. Natürlich können aber in relationalen Datenbanken mit SQL alle Relationen einer Gen/Spez über ihre (gleichen) Schlüssel verknüpft werden.

Die neuen Relationen

PrüfAllg (#PrüfNr, Bez, ArtPrüf, LVNr)

PrüfKLMP (#PrüfNr, Länge)

PrüfLA (#PrüfNr, LabBez, LabBetrN, LabBetrVN)

PrüfMP (#PrüfNr, PrüfPersNr)

PrüfPALA (#PrüfNr, Start, Ende)

Der Besuch einer Prüfung bezieht sich immer auf eine Lehrveranstaltung. Festgehalten wird zu jeder Prüfung das Semester, in dem sie stattfindet (Sem), das genaue Datum, um welchen Versuch es sich handelt (1. Versuch, 2. Versuch, ...) und welche Note erzielt wurde.

Anforderung Teil 6

Der letzte Teil der Anforderungen klärt die Erfassung des Prüfungsbesuchs. Dies ist wieder eine n:m-Beziehung. Als Schlüssel dient neben der Matrikel- und Prüfungsnummer auch die Semesterangabe. Die anderen drei beschreibenden Attribute werden als Nichtschlüsselattribute eingefügt. Damit ergibt sich folgende Relation:

PrüfBesuch (#(MatrNr, PrüfNr, Sem), Datum, Versuch, Note)

Das gesamte Datenmodell – textliche Fassung

Adressen (#AdrNr, Ort, PLZ, Strasse)

DozAllg (#DozNr, Name, VName, Anrede, E-Mail)

DozExt (#DozNr, AkAb, OrgNr, AdrNr)

DozHS (#DozNr, Fakultät, BüroNr, BezGeb, IntTel, SprSt, E-Mail)

Gebäude (#BezGeb, Ort, Straße, DVBetr)

Lehrbetrieb (#(DozNr, VeranstNr, Sem))

LV (#LVNr, BezLV, TypSG, BezSG, SemPlan, cp, SWS)

LVBesuch (#(MatrNr, LVNr, Sem))

LVRaum (#(LVNr, Sem), Raum)

LVTermine (#(LVNr, Tag, Beginn), Ende) //für jeden Termin

Organisationen (#OrgNr, Bez, AdrNr)

PrüfAllg (#PrüfNr, Bez, ArtPrüf, LVNr)

PrüfBesuch (#(MatrNr, PrüfNr, Sem), Datum, Versuch, Note)

PrüfKLMP (#PrüfNr, Länge)

PrüfLA (#PrüfNr, LabBez, LabBetrN, LabBetrVN)

PrüfMP (#PrüfNr, PrüfPersNr)

PrüfPALA (#PrüfNr, Start, Ende)

Räume (#RaumNr, ArtRaum, Groesse, BeamerJN, IntranetJN, GebBez)

StudAdr (#(MatrNr, AdrNr), Art)

Studierende (#MatrNr, Name, VName, E-Mail, BegStudium, EndeStudium, SG, FachSem)

Das gesamte Datenmodell – graphische Fassung

Abbildung 16.5-1: Relationales Datenmodell Hochschule

16.6 Sprachenverlag

Auch in diesem Beispiel sind wieder viele "Muster" vertreten, besonders ausgeprägt aber das Muster Generalisierung / Spezialisierung (Gen/Spez).

Anwendungsbereich

Es geht um die Produkte eines Verlages, der Wörterbücher (z.B. von Deutsch nach Englisch), digital oder auch gedruckt, herstellt und verkauft und der seit einiger Zeit auch Übersetzungsprogramme anbietet. Seine Produkte sollen in einer Datenbank verwaltet werden. Zu erfassen sind die nachfolgend angeführten Sachverhalte.

Wörterbücher und Übersetzungsprogramme

Alle Produkte, d.h. alle Wörterbücher und Volltextübersetzer (Programm zur automatischen Übersetzung von Text) mit ihrer Produktnummer (ProdNr) und Bezeichnung (Bez), mit ihrem Listenpreis (LPreis) und den Sprachen, die abgedeckt sind (z.B. deutsch nach englisch und englisch nach deutsch, deutsch nach französisch und französisch nach deutsch). Es ist grundsätzlich möglich, dass ein Wörterbuch auch nur eine Richtung abdeckt. Deshalb wird jede "Richtung" separat erfasst.

Anforderungungsbeschreibung

Für jedes gedruckte Wörterbuch wird auch festgehalten, wieviele Einträge es hat (Einträge), für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe), wann es auf den Markt gebracht wurde (ErschDat), wieviele Seiten es hat (AnzSeit).

Für jedes digitale Wörterbuch wird auch festgehalten, wann es auf den Markt gebracht wurde (ErschDat), welche Speichertechnik (SpeichTech) bei ihm verwendet wurde, wieviele Einträge es umfasst (Einträge) und für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe).

Die digitalen Produkte des Verlags beruhen jeweils auf einem Übersetzungsprogramm (BezProg). Es kann sein, dass eines mit verschiedenen Programmen angeboten wird (z.B. zielgruppenspezifisch). Natürlich dient ein Programm u.U. mehreren digitalen Produkten. Für diese Programme wird festgehalten, welche Dokumentarten (DokArt) sie auswerten können (Word, PDF, Bildformate, usw.; mehrere) und ob es möglich ist, die Programmleistung in Textprogramme zu integrieren (IBK: Integrierbarkeit).

Für jeden Volltextübersetzer wird auch festgehalten, welche Sprachen abgedeckt sind, wieviele Einträge das Systemlexikon hat (Einträge), für welche Zielgruppe das Produkt gedacht ist und wann es auf den Markt gebracht wurde (ErschDatum). Festgehalten wird außerdem, ob man den Käufern anbietet, es durch Internetzugriffe regelmäßig aktualisieren zu lassen. Falls ja, wie lange dies möglich ist (AktJahre), z.B. 5 Jahre ab Kauf.

Für alle Programme werden außerdem die Softwarehäuser, die an der Erstellung mitgearbeitet haben, mit ihrer Anschrift (nur die Zentrale) festgehalten. Es wird auch die zentrale E-Mail-Adresse erfasst. Es kommt durchaus vor, dass ein Programm in Kooperation von mehreren Softwarehäusern erstellt wird. Natürlich bietet ein bestimmtes Softwarehaus u.U. mehrere Programme an, z.B. für verschiedene Sprachen. Es wird bzgl. eines jeden Programms der Beginn und das Ende der Zusammenarbeit vermerkt.

Für alle digitalen Produkte werden außerdem die Systemvoraussetzungen festgehalten, abhängig vom eingesetzten Programm. Welche minimale Hardwareanforderung gegeben ist (anhand des Prozessors, Proz), wieviel Arbeitsspeicher sie benötigen (ArbSp), wieviel freier Plattenspeicher (PlattSp) nötig ist (in MB) und welche Betriebssystemversion (BS) genutzt werden kann (Windows Vista, 7, 8; LINUX). Dies sind in der Regel mehrere.

Erfasst werden auch die konkreten Geräte, auf denen die digitalen Produkte lauffähig sind mit ihrer Bezeichnung (Bez) und dem Gerätetyp (Typ; Smartphone, Pad, Tablett, Laptop, usw.). Auf einem Gerät sind natürlich mehrere digitale Produkte lauffähig, dagegen werden die digitalen Produkte am Ende ihrer Entwicklung auf genau ein Gerät zugeschnitten. Besteht das jeweilige Gerät nicht mehr, wird auch das zugehörige digitale Produkt überflüssig.

Die Entwicklung der Programme findet (natürlich) so statt, dass jedes Programm mit unterschiedlichen grafischen Bedienoberflächen (GUI) kombiniert werden kann. Für die GUIs wird ein Schlüssel (GUIId), der Typ (Fenster, Kacheln, ...) und die Programmiersprache (PS), mit der sie entwickelt wurde, festgehalten. Ein konkretes vom jeweiligen Softwarehaus angebotenes Programm enthält dann genau eine GUI, d.h. die Programme sind nach ihren GUIs differenziert.

Lösungsschritte

Hier wird nun wieder die schrittweise Umsetzung des Textes in ein relationales Datenmodell dargestellt.

Alle Produkte, d.h. alle Wörterbücher und Volltextübersetzer (Programm zur automatischen Übersetzung von Text) mit ihrer Produktnummer (ProdNr) und Bezeichnung (Bez), mit ihrem Listenpreis (LPreis) und den Sprachen, die abgedeckt sind (z.B. deutsch nach englisch und englisch nach deutsch, deutsch nach französisch und französisch nach deutsch). Es ist grundsätzlich möglich, dass ein Wörterbuch auch nur eine Richtung abdeckt. Deshalb wird jede "Richtung" separat erfasst.

Anforderung 1

Dem Text kann entnommen werden, dass es Produkte gibt und dass diese (erstmal) aus Wörterbüchern und Volltextübersetzern bestehen. Nennen wir sie auch Produkte und geben ihnen den Schlüssel ProdNr. Außerdem wird auf die abgedeckten Sprachen hingewiesen und zwar als mehrwertige Attribute an dieser Relation. Damit entstehen die folgenden ersten zwei Relationen:

ProdSpr (#(ProdNr, Sprache))

Produkte (#ProdNr, Bez, LPreis, ...)

Wenn also z.B. ein Produkt "Englisch - Deutsch" und "Deutsch - Englisch" abdeckt hat es mit seiner Produktnummer (z.B. 1000) zwei Einträge:

Relation ProdSpr

ProdNr

Sprache

1000

Deutsch

1000

Englisch

...

...

#(ProdNr, Sprache)

Für jedes gedruckte Wörterbuch wird auch festgehalten, wieviele Einträge es hat (Einträge), für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe), wann es auf den Markt gebracht wurde (ErschDat), wieviele Seiten es hat (AnzSeit).

Anforderung 2

Das Wort "auch" macht deutlich, dass es sich um eine Variante handelt, die evtl. zusätzliche Attribute hat. Dies ist hier auch der Fall, so dass eine Spezialisierung für gedruckte Wörterbücher eingerichtet werden muss. Sie wird WBGedr genannt und hat (erstmal!) die folgenden Attribute.

WBGedr (#ProdNr, Einträge, Zielgruppe, ErschDat, AnzSeiten)

Für jedes digitale Wörterbuch wird auch festgehalten, wann es auf den Markt gebracht wurde (ErschDat), welche Speichertechnik (SpeichTech) bei ihm verwendet wurde, wieviele Einträge es umfasst (Einträge) und für welche Zielgruppe es gedacht ist (Schüler, Studierende, "Anwender", "Profi-Anwender", Übersetzer) (Zielgruppe).

Anforderung 3

Wieder taucht in der Anforderungsformulierung das Wort "auch" auf. Die neue Produktvariante hat dann auch eine Spezialisierung: Digitale Wörterbücher. Diese Relation wird WBDig genannt:

WBDig (#ProdNr, Einträge, Zielgruppe, ErschDat, SpeichTech)

Da in WBDig zum Teil dieselben Attribute wie in WBGedr vorliegen, kann eine Generalisierung dieser beiden Relationen mit Einträge, ErschDatum und Zielgruppe gebildet werden. Dieses Muster Gen/Spez muss man nun erkennen, z.B. anhand der Semantik ("Ähnlichkeit") oder der identischen Attribute. Die Bereinigung ergibt eine Relation für Wörterbücher und je eine "abgeschlankte" für die digitalen und gedruckten Wörterbücher.

Muster Gen/Spez

Damit entstehen folgende neue bzw. veränderte Relationen:

WB (#ProdNr, Einträge, Zielgruppe, ErschDat)

WBDig (#ProdNr, SpeichTech)

WBGedr (#ProdNr, AnzSeiten)

WB ist Spezialisierung von Produkte, WBDig und WBGedr sind Spezialisierungen von WB.

Will man eine nicht simple Gen/Spez-Struktur durchdringen, lohnt sich die Anlage einer Tabelle mit den Attributen der beteiligten Relationen, wie es die folgenden Abbildungen zeigen. In der Kopfzeile sind die einzelnen Produkte angesiedelt, darunter zeilenweise die Attribute. Die obersten Zeilen geben die Attribute an, die alle Produkte haben, darunter dann die für die einzelnen Spezialisierungen.

Gen/Spez-Tabelle 1: Produkte und ihre Spezialisierungen - Version 1-A

Produkte

WB

WBGedr

WBDig

ProdNr

ProdNr

ProdNr

ProdNr

Bez

Bez

Bez

Bez

Lpreis

LPreis

LPreis

LPreis

Einträge

Einträge

Einträge

Zielgruppe

Zielgruppe

Zielgruppe

ErschDat

ErschDat

ErschDat

AnzSeiten

SpeichTech

Schon diese Tabelle zeigt die Gen/Spez-Struktur auf. Noch übersichtlicher wird es, wenn man in jeder Spalte die Attribute weg lässt, die in der übergeordneten Generalisierung enthalten sind:

Gen/Spez-Tabelle 1: Produkte und ihre Spezialisierungen - Version 1-B

Produkte

WB

WBGedr

WBDig

ProdNr

Bez

Lpreis

Einträge

Zielgruppe

ErschDat

AnzSeiten

SpeichTech

Hier ist jetzt der Spezialisierungszusammenhang klar erkennbar.

Die digitalen Produkte des Verlags beruhen jeweils auf einem Übersetzungsprogramm (BezProg). Es kann sein, dass eines mit verschiedenen Programmen angeboten wird (z.B. zielgruppenspezifisch). Natürlich dient ein Programm u.U. mehreren digitalen Produkten. Für diese Programme wird festgehalten, welche Dokumentarten (DokArt) sie auswerten können (Word, PDF, Bildformate, usw.; mehrere) und ob es möglich ist, die Programmleistung in Textprogramme zu integrieren (IBK: Integrierbarkeit).

Anforderung 4

Anforderung 4 beschreibt die digitalen Produkte näher. Der erste Teil legt außerdem auch eine n:m-Beziehung zwischen wischen Produkten und Programmen fest, so dass sich die Relation ProdDig ergibt. Die Programme werden durch die beiden Attribute DokArt und IBK datenbanktechnisch existent, wegen der n:m-Beziehung zwischen Programmen und Dokumentart sogar in zwei Relationen.

Damit kommen folgende Relationen dazu:

Programme (#BezProg, IBK)

ProgDokArt (#(BezProg, DokArt))

ProdDig (#(ProdNr, BezProg))

Für jeden Volltextübersetzer wird auch festgehalten, welche Sprachen abgedeckt sind, wieviele Einträge das Systemlexikon hat (Einträge), für welche Zielgruppe das Produkt gedacht ist und wann es auf den Markt gebracht wurde (ErschDatum). Festgehalten wird außerdem, ob man den Käufern anbietet, es durch Internetzugriffe regelmäßig aktualisieren zu lassen. Falls ja, wie lange dies möglich ist (AktJahre), z.B. 5 Jahre ab Kauf.

Anforderung 5

Die Beschreibung der Produkte geht weiter. Die hier genannten Attribute der Volltextübersetzer sind bis auf eines in WB enthalten. Deshalb ändern wir den Namen von WB in WB+VTÜ (Wörterbücher und Volltextübersetzer). Dies ist eine angemessene Lösung, denn normalerweise gibt es keine zwei Relationen mit identischem Schlüssel. Für die Volltextübersetzer mit Aktualisierungsmöglichkeit wird eine neue Relation VTÜAkt angelegt:

Lösung durch Umbenennung

WB+VTÜ (#ProdNr, Einträge, Zielgruppe, ErschDat)

VTÜAkt (#ProdNr, AktJahre)

Auch die Gen/Spez-Tabelle ändert sich damit (die bei den anderen Produkten vorkommenden Attribute wurden gleich weggelassen):

Gen/Spez-Tabelle 2: Produkte und ihre Spezialisierungen

Produkte

WB+VTÜ

WBGedr

WBDig

VTÜAkt

ProdNr

Bez

LPreis

Einträge

Zielgruppe

ErschDat

AnzSeiten

SpeichTech

AktJahre

Um nicht den Überblick zu verlieren und um die Gen/Spez-Struktur ganz deutlich zu machen, lohnt sich hier das Erstellen einer Abbildung.

Abbildung 16.6-1: Generalisierung / Spezialisierung rund um Produkte

Für alle Programme werden außerdem die Softwarehäuser, die an der Erstellung mitgearbeitet haben, mit ihrer Anschrift (nur die Zentrale) festgehalten. Es wird auch die zentrale E-Mail-Adresse erfasst. Es kommt durchaus vor, dass ein Programm in Kooperation von mehreren Softwarehäusern erstellt wird. Natürlich bietet ein bestimmtes Softwarehaus u.U. mehrere Programme an, z.B. für verschiedene Sprachen. Es wird bzgl. eines jeden Programms der Beginn und das Ende der Zusammenarbeit vermerkt.

Anforderung 6

Hier werden nun die Softwarehäuser zu Datenbankobjekten. Da für sie gleich auch noch Attribute angegeben werden, kann eine Relation angelegt werden. Außerdem auch für die Beziehung zwischen den Softwarehäusern und den Programmen. Diese ist vom Typ n:m und hat eine Zeitkomponente. Es genügt die Aufnahme des Beginns der Zusammenarbeit in den Schlüssel, damit können mehrere solche Phasen unterschieden werden.

Zeitaspekt in Beziehung

Daraus folgen weitere Relationen:

SWHäuser (#SWHNr, PLZ, Ort, Straße, eMail

SWHProg (#(SWHNr, BezProg, Beginn), Ende)

Für alle digitalen Produkte werden außerdem die Systemvoraussetzungen festgehalten, abhängig vom eingesetzten Programm. Welche minimale Hardwareanforderung gegeben ist (anhand des Prozessors, Proz), wieviel Arbeitsspeicher sie benötigen (ArbSp), wieviel freier Plattenspeicher (PlattSp) nötig ist (in MB) und welche Betriebssystemversion (BS) genutzt werden kann (Windows 7, 8, 10; LINUX). Dies sind in der Regel mehrere.

Anforderung 7

Zuerst scheint der Text eine Erweiterung der Beschreibung der digitalen Produkte zu enthalten. Die Formulierung "abhängig vom eingesetzten Programm" zeigt aber, dass Objekte gemeint sind, die durch die Kombination aus Produkt und Programm identifiziert sind. Deshalb wird die Relation ProdDig hier um die drei Attribute ergänzt. Bleiben noch die Betriebssysteme. Da u.U. mehrere Betriebssysteme für ein digitales Produkt tauglich sind, muss eine Relation erstellt werden, die das Attribut BS mit im Schlüssel hat: ProdDig-BS. Dadurch kommt es zu einer eher seltenen Konstellation: einem Fremdschlüssel, der aus zwei Attributen besteht: (#(ProdNr, BezProg)). Der entsprechende Schlüssel ist der von ProdDig.

Zwischen den digitalen Produkten und Betriebssystemen liegt eine n-m-Beziehung vor, weshalb eine eigene Relation dafür notwendig ist.

Daraus ergeben sich folgende geänderte und neue Relationen:

ProdDig (#(ProdNr, BezProg), Proz, ArbSp, PlattSp)

ProdDig-BS (#((ProdNr, BezProg), BS)

Erfasst werden auch die konkreten Geräte, auf denen die digitalen Produkte lauffähig sind mit ihrer Bezeichnung (Bez) und dem Gerätetyp (Typ; Smartphone, Pad, Tablett, Laptop, usw.). Auf einem Gerät sind natürlich mehrere digitale Produkte lauffähig, dagegen werden die digitalen Produkte am Ende ihrer Entwicklung auf genau ein Gerät zugeschnitten. Besteht das jeweilige Gerät nicht mehr, wird auch das zugehörige digitale Produkt überflüssig.

Anforderung Teil 8

Damit ergibt sich eine Relation zu Geräten. Außerdem kann die Gerätebezeichnung als Teilschlüssel in den Schlüssel von ProdDig aufgenommen werden, denn ein Gerät ist auf mehreren digitalen Produkten lauffähig.

Dies führt zu neuen bzw. veränderten Relationen:

Geräte (#Bez, Typ)

ProdDig (#(ProdNr, BezProg, BezGerät), Proz, ArbSp, PlattSp)

Unbehagen

Ist das wirklich korrekt? Bei näherem Hinsehen beschleicht den Betrachter ein leichtes Unbehagen. Wird nicht Proz, ArbSp und PlattSp alleine durch ProdNr und BezProg bestimmt? Was tut dann, diesbezüglich, BezGerät im Schlüssel. Würden die drei beschreibenden Geräte auch durch das jeweilige Gerät mit bestimmt, wäre das in Ordnung. Nach der Beschreibung ist dies aber nicht anzunehmen. Der Bedarf an Hardwarekapazitäten wird wohl geräteunabhängig bestimmt. Um ein solches Unbehagen zu beseitigen, ist ein FA-Diagramm gut geeignet:

Abbildung 16.6-2: FA-Diagramm der Relation ProdDig_1NF

Das macht die Problematik klar. Die Relation ist nicht mal in 2NF. Deshalb muss normalisiert werden.

Abbildung 16.6-3: FA-Diagramm der Relationen ProdProgGer und ProdDig

Damit ergibt sich eine veränderte Relation ProdDig (die der "vorletzten" Fassung entspricht) und eine neue Relation zu der Beziehung von Produkten, Programmen und Geräten. Sie hält fest, in welcher konkreten Konstellation die drei Komponenten zusammengefügt werden können.

ProdDig neu und ProdProgGer

ProdDig (#(ProdNr, BezProg), Proz, ArbSp, PlattSp)

ProdProgGer (#(ProdNr, BezProg, BezGerät))

Es soll an dieser Stelle nicht verschwiegen werden, dass ProdProgGer in der Praxis ein Kandidat für die Einführung eines Schlüssels wäre, der die jeweils konkrete Konstellation ausdrückt (ProduktProgrammGerätId). Dann würden die drei Attribute a) zu einem Sekundärschlüssel und b) zu beschreibenden Attributen:

Konstruierter Schlüssel.

ProdProgGer-Alternative (#PPGId, (ProdNr, BezProg, BezGerät))

Die folgende Abbildung zeigt das zugehörige FA-Diagramm.

ALTERNATIVE

Abbildung 16.6-4: FA-Diagramm der Relation ProdProgGer-Alternative

Die Entwicklung der Programme findet (natürlich) so statt, dass jedes Programm mit unterschiedlichen grafischen Bedienoberflächen (GUI) kombiniert werden kann. Für die GUIs wird ein Schlüssel (GUIId), der Typ (Fenster, Kacheln, ...) und die Programmiersprache (PS), mit der sie entwickelt wurde, festgehalten. Ein konkretes vom jeweiligen Softwarehaus angebotenes Programm enthält dann genau eine GUI, d.h. die Programme sind nach ihren grafischen Bedienoberflächen differenziert.

Anforderung Teil 9

Nun wird die Einbindung der grafischen Bedienoberflächen (graphical user interface, GUI) in das Datenmodell geklärt. Sie werden durch Identifikation und Beschreibung datenbanktechnisch existent in der Relation GUI. Dem Text kann außerdem entnommen werden, dass ein bestimmtes Programm genau eine ganz bestimmte GUI hat, so dass hier eine 1:n-Beziehung vorliegt. Entsprechend wird der Schlüssel von GUI in Programme als Fremdschlüssel eingefügt:

GUI

GUI (#GUIId, Typ, PS)

Programme (#BezProg, IBK, GUIId)

Das gesamte relationale Modell

Damit ergibt sich das folgende Gesamtdatenmodell, zuerst in textlicher Notation:

Geräte (#Bez, Typ)

GUI (#GUIId, Typ, PS)

ProdDig (#(ProdNr, BezProg), Proz, ArbSp, PlattSp)

ProdDig-BS (#((ProdNr, BezProg), BS)

ProdProgGer (#(ProdNr, BezProg, BezGerät))

ProdSpr (#(ProdNr, Sprache))

Produkte (#ProdNr, Bez, LPreis, Einträge, Zielgruppe, ErschDat, Typ)

Prog-DokArt (#(BezProg, DokArt))

Programme (#BezProg, IBK, GUIId)

SWHäuser (#SWHNr, PLZ, Ort, Straße, eMail

SWHProg (#(SWHNr, BezProg, Beginn), Ende)

VTÜAkt (#ProdNr, AktJahre)

WB+VTÜ (#ProdNr, Einträge, Zielgruppe, ErschDat)

WBDig (#ProdNr, SpeichTech)

WBGedr (#ProdNr, AnzSeiten)

Die grafische Notation:

Abbildung 16.6-5: Relationales Datenmodell Sprachenverlag

Abkürzungen für Attribute:

AktJahr: Zahl der Jahre, in denen das Programm aktualisiert wird

ArbSp: Arbeitsspeicher

BS: Bezeichnung Betriebssystemversion

ErschDatum: Erscheinungsdatum

Geräte.Bez: Bezeichnung des Geräts

Geräte.Typ: Gerätetyp

GUI.Typ: Typ der grafischen Bedienoberfläche

GUIId: Schlüssel für die grafische Bedienoberfläche

LPreis: Listenpreis

PlattSp: Speichergröße der Festplatte

ProdDig.BezProg: Bezeichnung des Übersetzungsprogramms

ProdNr : Produktnummer

Produkte.Bez: Bezeichnung Produkt

Proz: Bezeichnung des Prozessors bei digitalen Produkten

PS: Programmiersprache, mit der die GUI entwickelt wurde

Sprachen: abgedeckte Sprachen

SWHProg.Beginn: Beginn der Zusammenarbeit

SWHProg.Ende: Ende der Zusammenarbeit

WB+VTÜ. Einträge: Zahl der Einträge in gedruckten Wörterbüchern und Volltextübersetzern

Zielgruppe: anvisierte Kundengruppe

Abkürzungen für Relationen:

Geräte: Geräte, auf denen das digitale Produkt einsetzbar ist

GUI: grafische Bedienoberfläche

ProdDig: digitale Produkte

ProdDig-BS: digitale Produkte in Kombination mit Betriebssystemen

ProdProgGer: Kombination Produkte – Programme – Geräte

ProdSpr: Kombinatione Produkte und Sprachen

Produkte: die vom Sprachenverlag hergestellten Produkte

ProgDokArt: Dokumentarten, die von den Programmen ausgewertet werden können

Programme: die eingesetzten Programme

SWHäuser: Softwarehäuser, die mit dem Sprachenverlag zusammenarbeiten

SWHProg: Kombination Softwarehäuser und Programme

VTÜAkt: Angabe zur Aktualisierung bei Volltextübersetzern

WB+VTÜ: Attribute zu Volltextübersetzern und Wörterbüchern

WBDig: digitale Wörterbücher

WBGedr: Gedruckte Wörterbücher

17 Weitere Modellierungsbeispiele

In diesem Kapitel werden einige weitere Datenmodelle mit Anforderungsbeschreibung, Lösung und Lösungshinweisen vorgestellt. Es handelt sich um einfache didaktisch motivierte und einführende Beispiele, die aber alle wesentlichen Hürden der relationalen Datenmodellierung beinhalten.

17.1 Obst

Der Anwendungsbereich

Ein Einzelhändler möchte seine Obstlieferanten und Obstlieferungen in einer Datenbank verwalten. Für alle Lieferanten erfasst er die Zuverlässigkeit (ZV; Skala von 1 bis 6) und die Art der Abrechnung (AbrArt; sofort, Monatsende, Saisonende, ...). Bezüglich der Landwirte, die ihm Obst liefern, erfasst er Name, Vorname (VName), Typ (biologisch, ...), Postleitzahl (PLZ), Ort, Straße, Telefon (nur eines; Tel), Mailadresse (E-Mail) und welche Obstsorten (z.B. Golden Delicious) (SortBez) sie ihm in den einzelnen Monaten typischerweise liefern können ("Lieferbarkeit" ). Dies können durchaus mehrere sein, z.B. eine Sorte Äpfel, mehrere Sorten Birnen, usw., alles was in der Region wächst.

Beispiele für Lieferbarkeit

LNr

SortBez

Monat

100

Äpfel xyz

August

100

Äpfel xyz

September

100

Birnen xyz

Oktober

101

Birnen xyz

Oktober

...

...

...

Bezüglich der Obstgroßhändler erfasst er Firmenname (FName), Land (Deutschland, Österreich, Schweiz, Niederlande, ...) Postleitzahl (PLZ), Ort (Ort), Straße, Telefon (nur eines) (Tel), Fax (Fax), Mailadresse (E-Mail) und - genau wie bei den Landwirten - welche Obstsorten (SortBez) in welchem Zeitraum typischerweise lieferbar sind (z.B. Erdbeeren von Januar bis März, da aus Übersee). Alle Lieferanten (Landwirte oder Großhändler) erhalten eine Lieferantennummer (LiefNr). Aus pragmatischen Gründen erhält jede Obstsorte auch eine identifizierende Nummer (Sortennummer, SortNr). Für jede Obstsorte wird auch festgehalten, wie lagerfähig sie ist (LagFäh), d.h. wieviele Wochen man sie gekühlt aufheben kann.

Weiter sollen konkrete Lieferungen (von Landwirten oder Großhändlern) erfasst werden mit Obstsorte, Menge (Menge), Liefertag (LTag), Lieferant (Landwirt oder Großhändler) und Kilopreis (KPreis). Ein Lieferant liefert höchstens einmal pro Tag, da aber u.U. mehrere Obstsorten. Aus statistischen Gründen wird auch festgehalten, wieviel (in kg) von jeder Obstsorte umgesetzt wurde (Umsatz). Diese Berechnung erfolgt in jedem Jahr neu ab Jahresanfang.

Textliche Lösung

Anmerkung: "Verfügbarkeit" bezieht sich nicht auf den Lagerbestand, sondern auf die Wachstumsperioden.

Insgesamt ergeben sich damit folgende Relationen:

Landwirte (#LiefNr, Name, Vorname, Typ)

Lieferanten (#LiefNr, ZV, AbrArt, AdrNr)

Adressen (#AdrNr, PLZ, Ort, Straße, Telefon, E-Mail)

Großhändler (#LiefNr, FName, Land, Fax)

KonkreteLief (#(LiefNr, SortNr, LTag), KPreis, Menge) //Konkrete Lieferungen

Lieferbarkeit (#(LiefNr, ObstNr, Monat))

Obstsorten (#SortNr, SortBez, LagFäh, Umsatz)

Grafische Notation des Datenmodells

Abbildung 17.1-1: Relationales Datenmodell Obst

17.2 Haushaltsgeräte

Der Anwendungsbereich

Ein großer Einzelhändler möchte seinen Lagerbestand und die Verkäufe in einer Datenbank verwalten. Für jedes Haushaltsgerät wird die exakte Bezeichnung (Bez) erfasst, z.B. Staubsauger XYZ. Außerdem der Hersteller (Hersteller), der Listenpreis (LPreis), die Anzahl der Geräte im Lager (AnzLager), das Datum der Herstellung (DatumHerst) und das Datum, wann es ins Lager aufgenommen wurde (LagAufn). Für Staubsauger wird zusätzlich festgehalten, welche Saugkraft sie haben und von welchem Typ sie sind (mit Beutel, ohne, ...). Für Kaffemaschinen, welche Wassermenge sie maximal verarbeiten können (MaxWass) und in welcher Zeit sie einen halben Liter Kaffee kochen (Geschw).

Einzel- oder Typinformation?

Von den Kunden werden Name, Vorname (VName) und Telefonnummer erfasst Tel; durchaus auch mehrere) und natürlich erhält jeder eine Kundennummer (KuNr). Beim Verkauf hochwertiger Geräte mit Garantievereinbarung (teurer als 300 Euro) wird der Käufer (mit aktueller Adresse), das konkrete Gerät (Seriennummer, ...GNr) das Datum, die Versicherungsnummer (VNr) und der tatsächlich erzielte Preis (ErzPreis) festgehalten. Dieser weicht oft vom Listenpreis ab, meist weil Nachlässe gegeben werden.

Ein Kunde kann mehrere Adressen haben (PLZ, Ort, Straße), unter einer Adresse können mehrere Kunden wohnen.

Textliche Notation

Bez(eichnung) als Schlüssel deutet immer auf die Typbezeichnung und damit auf die Typebene

HG-Typen (#Bez, Hersteller, LPreis, AnzLager) //Typ-Ebene Hausgeräte

HG-Einzeln (#GNr, Bez, DatumHerst, LagAufn //Einzel-Ebene Hausgeräte

Staubsauger (#Bez, Saugkraft, Typ) //Typ-Ebene

Kaffeemaschine (#Bez, MaxWass, Geschw) //Typ-Ebene

Kunden (#KuNr, Name, VName)

VerkHG (#(GNr, KuNr, AdrNr), Datum, ErzPreis, VNr) //Verkäufe von Hausgeräten

KuAdr (#(KuNr, AdrNr))

Adressen (#AdrNr, PLZ, Ort, Straße)

Telefon (#(KuNr, Tel))

Anmerkungen

Für die Kunden werden beliebig viele Adressen erfasst und es wird auch datenbanktechnisch berücksichtigt, dass unter einer Adresse mehrere Kunden wohnen können. Es werden auch Kunden erfasst, deren Adresse durch eine Werbeaktion gewonnen wurde, die aber noch nichts gekauft haben.

Das Muster Einzel/Typ ist nicht auf Anhieb erkennbar. Hier hilft das Nachdenken mit Hilfe der Attributzuordnung, z.B. über ein FA-Diagramm.

Grafische Darstellung des Datenmodells

Abbildung 17.2-1: Relationales Datenmodell zum Anwendungsbereich Haushaltsgeräte

17.3 Angestellte

Der Anwendungsbereich

In diesem Anwendungsbereich geht es um Angestellte eines Unternehmens, ihre Ausstattung mit PCs, ihre Mitarbeit in Abteilungen und Projekten, usw. Ausschnitte aus diesem didaktisch motivierten Datenmodell dienen in den Theoriekapiteln als Beispiele. Folgendes soll festgehalten werden:

Für die Angestellten die Personalnummer (PersNr), der Name (Name), Vorname (VName) und Geburtstag (GebTag). Außerdem werden die Adressen erfasst mit Strasse, PLZ, Ort und einer zweiten Adresszeile (AdrZ2). Jeder Angestellte kann mehrere Adressen haben und unter einer Adresse können mehrere Angestellte wohnen.

Das Vorgesetztenverhältnis. Wer ist wem unter- bzw. überstellt?

Für die Projekte die Bezeichnung (Bez), der Einrichtungstag (TagEinr), die Dauer (Dauer) und das Budget (Budget). Ein Projekt kann auf mehrere Standorte verteilt sein. Dies wird auch erfasst.

Die Standorte werden mit einer identifizierenden Information (OrtId), ihrer Bezeichnung (Bez), ihrer Adresse und der Anzahl Mitarbeiter am Standort (AnzMitarb) erfasst.

Ein Angestellter kann in mehreren Projekten mitarbeiten und ein Projekt hat typischerweise mehrere Mitarbeiter.

Für die Abteilungen wird die Abteilungsbezeichnung (AbtBez), der Abteilungsleiter (AbtLeiter) und der Standort festgehalten. Eine Abteilung ist immer genau an einem Standort, an einem Standort können mehrere Abteilungen sein.

In einer Abteilung sind mehrere Angestellte, ein Angestellter gehört aber zu einem Zeitpunkt genau zu einer Abteilung. Im Zeitverlauf können Angestellte auch die Abteilung wechseln, was mit BeginnZ(ugehörigkeit) und EndeZ ebenfalls erfasst wird.

Festgehalten wird auch, welche Funktion ein Angestellter in einer Abteilung hat. Dies geschieht mit Hilfe der Funktionsbezeichnung (BezFu), dem Beginn (Beginn) und Ende (Ende) der Funktionsübernahme. Es ist durchaus möglich, dass ein Angestellter im Zeitablauf auch unterschiedliche Funktionen in einer Abteilung übernimmt. Zu einem Zeitpunkt aber immer nur eine.

Für die von den Angestellten benutzten PCs wird die Inventarnummer, (InvNr), die Bezeichnung (Bez) und der Typ (Typ) erfasst. Ein PC kann mehreren Angestellten zugeordnet sein, ein Angestellter nutzt zu einem Zeitpunkt maximal einen PC. Die Übernahme eines PC durch einen Angestellten wird mit der Art der Übernahme (Art; "Entwickler, Office-Nutzer, Superuser"), dem Beginn (Beginn) und dem Ende (Ende) festgehalten. Natürlich nutzt ein Angestellter im Zeitverlauf mehrere PC, diesbezüglich soll die gesamte Historie festgehalten werden.

Für die Programmiersprachen, die von den Angestellten beherrscht werden, wird die Bezeichnung der Sprache (BezPS), die Bezeichnung des Compilers (BezComp) und der Preis (PreisLiz) für eine Lizenz festgehalten. Wegen der Bedeutung der Programmiererfahrung wird außerdem festgehalten, wieviel Jahre Programmierpraxis (ErfPS) jeder Angestellte in seinen Programmiersprachen hat. Es gibt auch Angestellte, die nicht programmieren und keine Programmiersprache beherrschen.

Für die Entwickler unter den Angestellten wird die von ihnen genutzte Entwicklungsumgebung (EntwU) und ihre hauptsächlich genutzte Programmiersprache festgehalten (HauptPS). Für die Mitarbeiter des Gebäudeservices die Funktion (Funktion) und die Schicht (Schicht), in der sie arbeiten. Für das Top-Management der Bereich in dem sie tätig sind (Bereich) und das Entgeltmodell, nach dem sie ihr Gehalt bekommen (Entgelt).

Textliche Lösung

Abteilungen (#AbtBez, AbtLeiter, OrtId)

Adressen (#AdrId, PLZ, Ort, AdrZ2, Strasse)

Die Beziehung Angestellte-Abteilungen-Funktionen beschreibt die Übernahme von Funktionen in Abteilungen durch Angestellte, mit Angabe des Zeitraums:

BeginnF: Beginn der Funktionsübernahme

EndeF: Ende der Funktionsübernahme

BezFu: Bezeichnung der Funktion

AngAbtFu (#(PersNr, AbtBez, BeginnF), EndeF, BezFu))

Die Beziehung Angestellte - Abteilungen - Zugehörigkeit beschreibt die Zugehörigkeit zu Abteilungen, mit Angabe des Zeitraums:

AngAbtZug (#(PersNr, AbtBez, BeginnZ), EndeZ)

AngAdr (#(PersNr, AdrId))

Angestellte (#PersNr, Name, VName, DatumEinst, GebTag)

AngPC (#(PersNr, Beginn), InvNrPC, Art, Ende))

Methodisch wäre ein Schlüssel mit InvNrPC eingängiger. Da nach den Anforderungen jedem/jeder nur genau ein PC zugeordnet ist, wäre dies auch möglich.

ProjMitarb (#(PersNr, BezProj))

AngPS (#(PersNr, BezPS), ErfPS)

Entwickler (#PersNr, EntwU, HauptPS)

GebService (#PersNr, Funktion, Schicht)

PCEinzeln (#InvNr, BezPC)

PCTyp (#BezPC, Typ)

Projekte (#Bez, TagEinr, Dauer, Budget)

ProjOrte (#(BezProj, OrtId))

PS (#BezPS, BezComp, PreisLiz)

Standorte (#OrtId, Bez, AnzMitarb, AdrId)

TopMan (#PersNr, Bereich, Entgelt)

Vorgesetzte (#(PersNrV, PersNrU))

Die grafische Lösung

Abbildung 17.3-1: Relationales Datenmodell zum Anwendungsbereich Angestellte

17.4 Kfz-Werkstatt

Der Anwendungsbereich

In der Datenbank soll das Geschehen rund um die Reparaturaufträge erfasst werden. Für die Reparaturaufträge selbst wird erfasst, um welches Kraftfahrzeug es geht, an welchem Tag es in die Werkstatt kam (TagAnnahme), um was für einen Schaden es sich handelte (ArtSchaden), also z.B. Totalschaden, Blechschaden, Motorprobleme, usw. Außerdem, bei welchem Serviceberater (ServBerater) das Auto abgegeben wurde und von welchem Kunden das Auto kommt. Zur einfacheren Handhabung erhält jeder Reparaturauftrag eine fortlaufende Nummer (RepANr). Aus demselben Grund wird jedem angelieferten Kfz ebenfalls eine eindeutige Nummer (KfzNr) gegeben.

Rund um Reparaturaufträge

Für die Kunden wird neben einer Kundennummer (KuNr) der Name (Name), Vorname (VName), eine Telefonnummer (Tel; die unter der der Kunde für Rückfragen zur Reparatur erreichbar ist) und die Adresse (PLZ, Ort, Straße) erfasst. Grundsätzlich soll es möglich sein, dass ein Kunde mehrere Adressen hat und unter einer Adresse mehrere Kunden wohnhaft sein können. Die Erfassung der Kundenadressen ist unabhängig von konkreten Reparaturaufträgen.

Für die Kfz werden der Hersteller (Hersteller; z.B. VW, BMW, AUDI), die Bezeichnung (Bez; z.B. PASSAT, A6, GOLF), die Art des Autos (Autoart; z.B. Cabrio, Limousine, usw.), das Kennzeichen (Kennz) und der Tag der Erstzulassung (TagErstzula) erfasst. Bei Fahrzeugen, die bei unserem Autohaus gekauft wurden, wird zusätzlich der Tag des Verkaufs (TagVerkauf) und die Art der Garantie (ArtGarantie) festgehalten.

Muster Einzel/Typ

Nach durchgeführter Reparatur wird die Rechnung in der üblichen Struktur erstellt, mit Rechnungsnummer (RNr), Datum (Datum), Angabe des Kunden und des reparierten Autos, Angabe derjenigen Adresse des Kunden, an den die aktuelle Rechnung geschickt werden soll, Rechnungspositionen mit Beschreibung der einzelnen Reparatur (BeschrRep; z.B. "Lackschaden am Kotflügel ausgebessert", "Druckluftschlauch wegen Marderschaden ausgewechselt") und Kosten der Reparatur (Preis; bei jeder Position). Auch die Gesamtsumme (SummeGes) der Rechnung wird erfasst.

Textliche Lösung

KFZAutohaus (#KfzNr, TagVerkauf, ArtGarantie)

KFZ-Einzeln (#KfzNr, Kennz, TagErstzula, (Hersteller, Bez))

KFZ-Typ (#(Hersteller, Bez), Autoart)

Oder auch : KFZ-Typ (#TypBez, #(Hersteller, Bez), Autoart) ; d.h. mit dem Attribut TypBez als konstruiertem identifizierenden Attribut und mit den Konsequenzen bzgl. des Fremdschlüssels.

ReKöpfe (#RNr, Datum, KNr, AdrNr, KfzNr, SummeGes)

RePos (#(RNr, PosNr), BeschrRep, Preis)

Kunden (#KuNr, Name, VName, Tel)

RepAufträge (#RepANr, KfzNr, ArtSchaden, TagAnnahme, ServBerater, KuNr)

Adressen (#AdrNr, PLZ, Ort, Straße)

KundeAdr (#(KuNr, AdrNr))

Grafische Lösung

Abbildung 17.4-1: Relationales Datenmodell Kfz-Werkstatt

17.5 WebShop

In diesem Beispiel erfolgt ansatzweise auch prozessorientierte Datenmodellierung, d.h. eine Datenmodellierung, wie sie entlang eines Geschäftsprozesses nötig ist.

Der Anwendungsbereich

Es geht um Teile des Finanzwesens eines WebShops. Wenn die Warensendung im WebShop fertig ist wird die Rechnung erstellt und der Sendung beigelegt. Damit ist das kaufmännische Konstrukt Rechnung existent. Wie üblich, wird es über Rechnungsköpfe und Rechnungspositionen erfasst. Die Rechnungsköpfe erhalten als identifizierendes Attribut eine Rechnungsnummer (ReNr) und als beschreibende Attribute das Rechnungsdatum (RDatum), die Zahlungsart (ZahlArt; L (per Lastschrift), U (per Überweisung)), die Versandart (VersArt) und der Kunde vermerkt. Da die Rechnung als PDF-Dokument erzeugt wird, ist dessen identifizierende Information (PDFId) hier ebenfalls festgehalten.

Die Kunden werden durch ihre Kundennummer (KuNr) und durch ihre Adressangaben (Name, Vorname (VName), PLZ, Ort, Straße) erfasst. Damit bei einem evtl. Umzug die frühere korrekte Adresse für die Rechnung vorhanden ist, werden bei der Rechnung die "änderungsanfälligen" Adressangaben zum Zeitpunkt der Rechnungsstellung (RechnungsstellungsZeitpunkt) erfasst (durch Name-RZ, PLZ-RZ, Ort-RZ, Straße-RZ). Es versteht sich, dass ein Kunde u.U. mehrere Rechnungen beim WebShop hat, jede Rechnung aber genau einem Kunden zugeordnet ist.

Die Artikel werden durch eine Artikelnummer ArtNr, eine Artikelbezeichnung ArtBez, den Preis und eine Artikelbeschreibung (ArtBeschr) erfasst.

Die einzelnen Rechnungspositionen einer Rechnung erhalten eine Positionsnummer (PosNr), die Artikelnummer (ArtNr) und die Anzahl. Wiederum um die Rechnung auch nach längerer Zeit, wenn sich vielleicht Bezeichnung und Preis verändert haben, abrufen zu können, wird bei der Rechnung der zum RechnungsstellungsZeitpunkt gültige Preis (Preis-RZ) und die da gültige Bezeichnung ArtBez-RZ erfasst.

Für alle Artikel wird auch der gültige Mehrwertsteuersatz (MWStS) Mehrwertsteuer (MWStB) erfasst. Zu beachten ist, dass verschiedene Produkte des WebShops unterschiedliche Mehrwertsteuersätze haben). Da sich auch Mehrwertsteuersätze regelmäßig verändern, wird dieser für den Rechnungsstellungszeitpunkt (RZ) festgehalten.

Für Produkte von Fremdanbietern (Firmen, die über den WebShop auch verkaufen) wird noch die Firmennummer (FiNr) des Fremdanbieters erfasst und seine durchschnittliche Lieferzeit (LiefZeit).

Auch die ausgesandten Mahnungen und Zahlungserinnerungen werden erfasst. Jede wird identifiziert (MahnId) und bezieht sich auf genau eine Rechnung. Es versteht sich, dass es zu einer Rechnung mehrere Mahnungen geben kann. Festgehalten wird, an welchem Tag die Mahnung (Datum) verschickt wurde und von welchem Typ sie war. Verschiedene Mahnungen zur selben Rechnung erhalten jeweils eine neue Id.

Eine Rechnung kann sich in verschiedenen Zuständen befinden. Folgende sind möglich:

Zustände einer Rechnung

ZustandsNr

Bezeichnung

100

neu (nach Erstellung)

200

offen (nach Versand zum Kunden)

300

nicht bezahlt

310

nicht bezahlt (1. Zahlungserinnerung)

320

nicht bezahlt (2. Zahlungserinnerung)

330

nicht bezahlt (1. Mahnung)

340

nicht bezahlt (2. Mahnung)

350

nicht bezahlt (rechtsanwaltliche Mahnung)

400

Widerspruch

500

Gutschrift

600

storniert

700

bezahlt (Rückbuchbar)

710

bezahlt

Diese Zustände sollen für jede Rechnung erfasst werden. Nach der Erstellung hat sie den Zustand (ZustNr) "neu", nach Zusendung zum Kunden den Zustand "offen", nach Bezahlung den Zustand "bezahlt". Zu beachten ist, dass ALLE sich im Zeitverlauf ergebenden Zustände erfasst werden sollen, so dass die gesamte Historie einer Rechnung erfasst wird. Deshalb wird auch bei jedem neuen Zustand das Datum (DatumZ) erfasst, zu dem er eintrat.

Textliche Fassung des Datenmodells:

Mahnungen (#MahnId, ReNr, Datum, Typ)

Zustände (#(ReNr, ZustNr), DatumZ)

Fremdanbieter (#FiNr, LiefZeit)

Artikel (#ArtNr, ArtBez, Preis, ArtBeschr, MWStS, Typ)

ArtikelFA (#ArtNr, FiNr)

Kunden (#KuNr, Name, VName, PLZ, Ort, Straße)

ReKöpfe (#ReNr, RDatum, ZahlArt, VersArt, PDFId, KuNr, Name-RZ, PLZ-RZ, Ort-RZ, Straße-RZ)

RePos (#(ReNr, PosNr), ArtNr, Anzahl, ArtBez-RZ, Preis-RZ, MWStS-RZ)

RZ: RechnungsstellungsZeitpunkt

Grafische Fassung des Datenmodells :

Abbildung 17.5-1: Relationales Datenmodell WebShop

ReKöpfe: Rechnungsköpfe

RePos: Rechnungspositionen

ArtikelFA: Artikel von Fremdanbietern

17.6 Zoo

Der Anwendungsbereich

Für einen Zoo soll eine Datenbank rund um die vorhandenen Tiere erstellt werden. Dabei erfolgt eine Konzentration auf größere Tiere (Säugetiere, Reptilien, ...). Allen diesen Tieren wird eine identifizierende Tiernummer (TierNr), ihr Name (Name) und die Gattung, zu der sie gehören (Gattung) zugewiesen. Außerdem wird ihr Geburtstag (GebTag), das Geschlecht und das Gebäude erfasst, in dem sie gehalten werden. Für jede Gattung wird auch festgehalten, wieviele Tiere davon im Zoo vorhanden sind (z.B. 5 Afrikanische Elefanten oder 20 Schimpansen) (Anzahl). Wegen der Bedeutung der Information für die Gebäude und das Außengelände wird bei Elefanten noch zusätzlich das Gewicht und bei Giraffen die Größe erfasst, jeweils mit dem Datum, zu dem der Wert erhoben wurde.

Tiere - als Gattung (Typ) und einzeln:
Gen/Spez

Auch das benötigte Futter für die Tiere wird verwaltet mit der Futterbezeichnung (Bez), dem noch vorhandenen Vorrat (Vorrat) und der Mindestmenge, die immer vorrätig gehalten wird (MiMenge). Ebenso die Entnahmen von Futter mit der Futterbezeichnung (FuttBez), der Menge, dem Tag der Entnahme (Datum) und dem Tier, das gefüttert wird. Es wird nur ein Mal pro Tag Futter für ein Tier entnommen.

Den Tieren sind Pfleger zugeordnet. Von diesen wird in der Datenbank die Personalnummer (PersNr), der Name und Vorname (VName) festgehalten. Es wird auch festgehalten, von wann bis wann ein Pfleger einem Tier zugeordnet ist (Beginn, Ende). Öfters kommt es vor, dass ein Pfleger für einen bestimmten Zeitraum einem Tier zugeordnet ist, dann nicht mehr und später wieder, so dass es mehrere Pflegezeiträume eines Pflegers bei einem Tier geben kann.

Für die einzelnen Gebäude des Zoos wird eine Gebäudenummer (GebNr), die Größe, der Typ (für Säugetiere, für Reptilien, usw.) und die Anzahl der Plätze (AnzPlätze) erfasst. Selbstverständlich wird auch festgehalten, welches Tier aktuell in welchem Gebäude ist.

Für die einzelnen Gebäude des Zoos wird eine Gebäudenummer (GebNr), die Größe, der Typ (für Säugetiere, für Reptilien, usw.) und die Anzahl der Plätze (AnzPlätze) erfasst. Selbstverständlich wird auch festgehalten, welches Tier aktuell in welchem Gebäude ist.

Für jedes Tier gibt es eine Tierakte, die digital geführt wird. Ein Eintrag entsteht bei der Geburt, einer beim Weggang bzw. Sterben des Tieres. Dazwischen entstehen Einträge bei besonderen Anlässen, z.B. wenn das Tier den Zoo wechselt, eine schwere Verletzung / Erkrankung erleben muss oder Nachwuchs bekommt. Jeder Eintrag erhält eine fortlaufende Aktennummer (1, 2, 3, ...) (AktNr). Außerdem wird das Datum der Anlage der Akte (DatAnlage) sowie der Grund für die Anlage (Geburt, Krankheit, Tod, ...) (Ereignis) und eine Beschreibung des Ereignisses (BeschrEr) in die Datenbank eingetragen. Nach dem Tod des Tieres wird die Akte archiviert und aus der Datenbank entfernt.

Komposition

Textliche Fassung des Datenmodells:

Tierakten (#(TierNr, AktNr), DatAnlage, Ereignis, BeschrEr)

Gebäude (#GebNr, Größe, Typ, AnzPlätze)

Pflege (#(PersNr, TierNr, Beginn), Ende)

Pfleger (#PersNr, Name, VName)

Futter (#Bez, Vorrat, MiMenge)

Fütterung (#(TierNr, FuttBez, Datum), Menge)

Tiere-Einzeln (#TierNr, Name, BezGatt, GebTag, Geschlecht, GebNr)

Tiere-Gattung (#BezGatt, Anzahl)

Elefanten (#(TierNr, Datum), Gewicht)

Giraffen (#(TierNr, Datum), Größe)

Grafische Darstellung des Datenmodells

Die folgende Abbildung zeigt die grafische Fassung des Datenmodells.

Abbildung 17.6-1: Relationales Datenmodell Zoo

Muster Komposition bei Tierakten

Muster Einzel/Typ bei Tiere

Muster Gen/Spez bei Elefanten, Giraffen

18 Von Attributen zu Datentypen

Hier beginnt Teil VI: Datenbankpraxis

mit den Kapiteln

18 Von Attributen zu Datentypen

19 Einführung in SQL

18.1 Vielfalt

Attribute sind, wie in Abschnitt 2.4 gezeigt, sehr unterschiedlich. Betrachten wir nur die Attribute

Name (einer Person)

Geburtstag (eines Angestellten)

Gehalt (einer Programmiererin)

Bewertung (einer studentischen Klausur)

Videodokument zur Jahreshauptversammlung eines DAX-Unternehmens

Es handelt sich um Informationen, die Informationsträger beschreiben. Daneben können sie Eigenschaften besitzen, die hier an Beispielen erläutert werden sollen.

Quantitativ, qualitativ: Es gibt Attribute, mit deren Ausprägungen man rechnen kann, z.B. Gehalt, Gewicht. Solche Attribute werden als quantitativ bezeichnet. Das Gegenstück sind qualitative Attribute, wie z.B. Geschlecht (m/w/d) oder Abteilungszugehörigkeit.

Außerdem kommen bei Gehalt nur positive Werte in Betracht, eine Einschränkung des Wertebereichs durch die Semantik der Information.

Informationen des Typs Geburtstag haben eine Semantik (von Datum, vgl. Abschnitt 1.7).

Namen sind einfache Buchstabenfolgen

Bewertungen sind positive Zahlen zwischen 1 und z.B. 100. Sie sind rangskaliert (im Sinne der Statistik), aber nicht "quantitativ". D.h. der Abstand von 6 zu 5 ist nicht gleich zu interpretieren wie der von 5 zu 4 usw., was aber bei quantitativen Attributen, wie z.B. Gehalt, der Fall ist.

Videodokumente sind große Datenmengen, die einer speziellen Methode zur Darstellung am Bildschirm bedürfen.

Rangskaliert: D.h., 90 Punkte sind besser als 50 Punkte, usw. Ab 50 Punkte hat man bestanden (zum Beispiel). Es gibt also eine Rangfolge unter den Attributsausprägungen.

Bei der Einrichtung der Datenbank (vgl. das nächste Kapitel) muss für jedes Attribut ein Datentyp festgelegt werden. D.h., die Attribute werden, wie in Kapitel 4 gezeigt, beim Datenbankentwurf benutzt, um die gefundenen Objekte und Beziehungen zu beschreiben. Dann folgt, wie in den Kapiteln 5 - 15 gezeigt, der Entwurf des Datenmodells. Auch dies geschieht auf der Basis der erfassten Attribute. Die relationale Theorie ist ganz und gar attributgestützt. Wenn dann anschließend das Datenmodell mit Hilfe eines Datenbanksystems in eine konkrete Datenbank überführt wird, müssen als allererstes die Attribute der Relationen, egal ob es Schlüssel, Fremdschlüssel oder Nichtschlüsselattribute sind, angelegt werden. Dazu muss ihnen ein Datentyp zugewiesen werden.

Das attributbasierte Datenmodell wird mit Hilfe eines Datenbanksystems zur Datenbank.

Welcher Datentyp für welches Attribut?

Der Datentyp eines Attributs erfasst dessen Syntax, Semantik und die möglichen Verarbeitungsschritte für die Attributsausprägungen. Entsprechend werden die Datentypen gewählt. Einige Beispiele:

Semantische Übereinstimmung + minimaler Speicherverbrauch

Für ein Attribut Name genügt ein Datentyp, der alphabetische Zeichen zulässt (und eventuell einen Bindestrich) und dessen Ausprägungen sortiert und textlich verabeitet werden können.

Ein Attribut Gehalt erhält einen numerischen Datentyp, der positive Dezimalzahlen in einem bestimmten Wertebereich zulässt und dessen Ausprägungen man rechnerisch verarbeiten kann.

Ein Attribut Datum erhält einen Datentyp, der die Syntax kontrolliert, die Semantik berücksichtigt (vgl. Abschnitt 1.4) und Methoden zur Datumsverarbeitung bereitstellt (Abstand zweier Datumsangaben in Tagen, Hinzurechnen / Abziehen von Tagen zu/von einem Datum, usw.).

Für Bewertungen (z.B. Schulnoten) ist ein Datentyp geeignet, der positive Dezimalzahlen verwaltet. Auch er benötigt nur einen eingeschränkten Wertebereich.

Für Videodokumente wird ein Datentyp genommen, der große Datenmengen zu verwalten erlaubt und mit dem eine Methode verbunden ist, um die Daten auf den Schirm zu bringen. Ein solcher Datentyp heißt bei vielen Datenbanksystemen Binary Large Object (BLOB) (vgl. unten).

Damit ist es dann möglich, die Daten korrekt zu erfassen. Außerdem ist ein Stück der Semantik ebenfalls schon berücksichtigt.

Felder, Datensätze, Dateien

Hier geht es zum ersten Mal um das konkrete Anlegen der Datenbank - am Beispiel der Datentypen (mehr dazu in Kapitel 19). Es geht also um den Übergang von der logischen Ebene der Datenmodellierung zur physischen. Denn genau da kommen die Datentypen ins Spiel. Wenn eine Datenbank angelegt ist, müssen zuerst die Relationen eingerichtet werden. Bei vielen Datenbanksystemen wird aus einer Relation genau eine Datei. Dabei werden die Attribute in die Datei eingefügt. Dies geht nur, indem jedem Attribut ein Datentyp zugeordnet wird. Diese Attribute mit ihrem Datentyp stellen dann die Felder der Datei dar. Die Attributsausprägung, die dann eingetragen wird, ist ein Eintrag in das Feld. Oftmals liest man für die Attributsausprägung / den Feldeintrag in der deutschsprachigen Fachliteratur auch den Begriff Wert bzw. value. Das Oracle SQL-Handbuch drückt den hier besprochenen Sachverhalt so aus:

Datentypen:
Verknüpfer der logischen und der physischen Ebene

"Each value manipulated by Oracle Database has a data type" [Oracle SQL 2013, S. 3-1]

In der folgenden Tabelle sind die Begriffe der beiden Ebenen zusammengestellt. Aus dem Datenmodell wird die Datenbank, aus Relationen werden Dateien, ein Tupel einer Relation entspricht einem Datensatz, ein Attribut einem Feld und die Attributsausprägungen stellen die Grundlage dar für die Einträge in ein Feld. Felder gibt es nur mit einem Datentyp.

Von der logischen zur physischen Ebene

Logische Ebene

Physische Ebene

Datenmodell

Datenbank

Relation

Datei

Tupel

Datensatz (record)

Attribut

Feld (field)

Attributsausprägung

Feldeintrag, Wert (value)

Näheres zum Gesamtzusammenhang zwischen Weltausschnitt und konkreten Dateien und der verwendeten Begrifflichkeit findet sich in Kapitel 20.

Varianten von Datentypen

Heutige Datenbanksysteme stellen eine große Vielfalt von Datentypen zur Verfügung, aus der ausgewählt werden muss. Es geht dann nur um die Frage, welcher für das jeweilige Attribut am geeignetsten ist: Welcher Datentyp ...

Grobeinteilung

erlaubt am besten die Kontrolle der Syntax (der Korrektheit der Eingaben),

die Erfassung der Semantik,

die Bereitstellung der benötigten Verarbeitungsschritte.

und tut dies mit dem geringsten Speicheraufwand.

Die wichtigste Unterscheidung bei Datentypen ist, ob sie textliche oder numerische Daten verwalten können. Dies kommt daher, weil ein Computer Text (genauer: alphanumerische Zeichenketten, "strings") auf andere Art verwalten muss als numerische Werte, z.B. weil wir mit numerischen Werten rechnen wollen, mit alphanumerischen aber nicht.

Textlich / numerisch

Diese sehr grundsätzliche Unterscheidung wird um weitere ergänzt, bei denen Semantik eine Rolle spielt. Zum Beispiel gibt es spezielle Datentypen für Datumsangaben. Rechnerintern ist ein Datum auch nur eine Folge von Ziffern und Zeichen, allerdings eine, bei der die Syntax kontrolliert und die Semantik dieses Attributstyps (vgl. Abschnitt 1.7) gleich hinzuprogrammiert wurde. Was zum Beispiel das Abweisen unzulässiger Datumsangaben und das Durchführen von Berechnungen im Rahmen der Datumsarithmetik erlaubt. Insgesamt kann festgehalten werden:

Datentyp + Semantik + mögliche Verarbeitungsschritte

Zu einem Datentyp gehören eine Datenstruktur (festgelegt durch die Syntax und Semantik des Attributs) und Methoden, die darauf angewandt werden können. In den Methoden spiegelt sich die Semantik des Datentyps wider.

Die Ähnlichkeit zu den Klassen der objektorientierten Theorie ist nicht zufällig. Datentypen waren die Vorläufer des Klassenkonzepts.

Ebenfalls semantisch motiviert sind Datentypen wie Aufzählung (enumeration) oder Menge (set). Auch hier liefern die Datentypen ein Stück weit die Semantik der zugehörigen Attribute gleich mit. Z.B. liegt bei einer Aufzählung eine strikte Ordnung auf den Ausprägungen und bei einer Menge können nicht zwei gleich Elemente vorkommen. Dies muss dann durch die dem Datentyp beigefügten Programme sichergestellt werden.

Auch Eigenschaften im syntaktischen Bereich bzw. beim Übergang von Syntax und Semantik führen zu eigenen Datentypen. So kann man einen Datentyp GELD (in einigen Datenbanksystemen MONEY genannt) so sehen, dass die Syntax ("zwei Stellen rechts vom Komma, beliebig viele davor") umgesetzt und ein Währungszeichen bei den Ausprägungen vorangestellt wird.

Syntax

Ein anderer Motivgeber für die Wahl bestimmter Datentypen ist der Wunsch, eine möglichst sparsame Speicherung zu ermöglichen. Deshalb gibt es für Integerwerte (ganze Zahlen) Datentypen mit sehr unterschiedlichen Wertebereichen (vgl. unten die Beispiele bei MySQL) und für textliche Attributsausprägungen sowie Texte (alphanumerische Zeichenfolgen) eine riesige Auswahl von Datentypen, die von der Speicherung von kurzen "strings" bis zur Verwaltunge ganzer Buchtexte optimierte Möglichkeiten anbieten.

Sparsame Speicherung

Speicherplatz sparen?

Warum ist es überhaupt nötig, über platzsparende Datentypen nachzudenken, warum kann man nicht einfach alle Daten in eine Datei reinschreiben und die Optimierung dem Datenbanksystem überlassen?

Nun, das hat u.a. mit den heutigen Speichertechniken für relationale Datenbanken zu tun. Dateien bestehen hier oft aus Datensätzen mit einem einheitlichen Aufbau und fixer Länge. Ein einfaches Beispiel: Wenn man einen Datentyp (z.B. char, vgl. unten) mit der fixen Länge von 1000 Zeichen anlegt, dann werden bei jedem Eintrag einer Attributsausprägung 1000 Zeichen verbraucht, egal wie lange der tatsächliche Eintrag ist. Dies kann durch Datentypen, die variable Längen erlauben (wie z.B. vchar, vgl. unten), ein Stück weit abgefangen werden. Da gibt es aber noch die Grenze von 255 Bytes, die für unterschiedliche Datenmengen unterschiedliche datentechnische Vorgehensweisen fordern.

Genauso bei numerischen Datentypen, z.B. Integer: Wenn man durch den Datentyp große Integerzahlen verlangt (z.B. BIGINT, vgl. unten), darin aber nur ganze Zahlen im Wertebeich von 0 bis 10000 verwaltet, wird trotzdem bei jedem Eintrag der Speicherplatz verbraucht, den der Datentyp vorgibt.

Der Grund liegt also darin, dass systemtechnisch Daten unterschiedlicher Größe (egal ob numerisch oder textlich bzw. alphanumerisch) unterschiedlich behandelt werden müssen.

Es soll an dieser Stelle nicht verschwiegen werden, dass es seit einiger Zeit Datenbanksysteme gibt, die nicht nur sehr große Datenbestände verwalten können ("Big Data"), sondern bei denen auch Speicherplatz sparen nicht im Fokus der Betreiber steht. Vgl. dazu Kapitel 24.

Weitere Datentypen ergeben sich aus "unkonventionellen" Anwendungsbereichen, die von der klassischen Datenbanktechnologie erst spät unterstützt wurden. Z.B. die geografischen und geometrischen Datentypen. Aber auch die Datentypen für große Textmengen bzw. beliebige Binärinformation. Diese BLOB-Datentypen waren in den ersten Generationen der relationalen Datenbanksysteme nicht vorhanden, kamen dann aber hinzu, als Antwort auf den Bedarf der Nutzer, die große Textemengen oder ganze Filme in Datenbanken verwalten wollten. Die Schwierigkeit bei der Verwaltung von Text war, dass lange Texte intern anders verarbeitet werden müssen, als alphanumerische Zeichenketten bis zur Länge von 255 Bytes. Deshalb kamen "die BLOBs" spät und müssen speichertechnisch anders verwaltet werden, als die übrigen Attribute (vgl. unten). Im nächsten Abschnitt sind die in MySQL dafür vorliegenden Datentypen kurz beschrieben.

Unkonventionelle Anwendungsbereiche

Abbildung 18.1-1: Datentypen in heutigen Datenbanksystemen – Auswahl

Die aktuelle Diskussion thematisiert diese Anwendungsbereiche und ihre Informationen auch unter dem Begriff NoSQL-Datenbanken. Vgl. Abschnitt 24.4.

18.2 Die Datentypen von MySQL

Die Parameter

Quelle für diesen Abschnitt: [MySQL 5.7]

Die Datentypen von MySQL sind sehr vielfältig und decken so gut wie jede heute genutzte Attributart ab. Sie sind wie oben gezeigt gruppiert in numerische, alphanumerische, geometrische und Datentypen für Datums- und Zeitangaben. Im folgenden werden diese kurz beschrieben. Zuerst wird die Bezeichnung des Datentyps mit seinen Parametern angegeben. Folgende Parameter kommen vor:

NOT NULL. Dies bedeutet, dass im zugehörigen Feld keine Leereinträge erlaubt sind.

AUTO_INCREMENT. Bei jedem Eintrag wird der Wert hochgezählt.

UNIQUE. Alle Einträge müssen unterschiedlich sein.

ZEROFILL

SIGNED / UNSIGNED. Die (numerischen) Einträge haben ein Vorzeichen oder keines. SIGNED ist Voreinstellung und wird daher meist weggelassen. Falls UNSIGNED gesetzt ist, sind keine negativen Werte möglich.

Numerische Datentypen haben grundsätzlich als Voreinstellung SIGNED ("mit Vorzeichen"). Einige könnnen auch auf UNSIGNED gesetzt werden (vgl. unten).

Numerische Datentypen

Bei den Integerdatentypen bedeutet M die maximale Anzeigegröße und für Gleitkomma- sowie Dezimalzahlen (fixed-point types) die Gesamtzahl von Stellen, die gespeichert werden können. Falls bei einem numerischen Datentyp ZEROFILL gesetzt ist, wird automatisch auch UNSIGNED gesetzt. Hier nun die Datentypen:

TINYINT[(M)] [UNSIGNED] [ZEROFILL] (tiny integer). Für ganze Zahlen im Wertebereich von -128 bis +127. Falls man die Option unsigned wählt ist der Wertebereich 0 bis 255.

SMALLINT[(M)] [UNSIGNED] [ZEROFILL] (small integer). Für ganze Zahlen im Wertebereich von -32.768 bis +32.767. Falls man die Option unsigned wählt ist der Wertebereich 0 bis 65.535.

MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL] (medium-sized integer). Für ganze Zahlen im Wertebereich von -8.388.608 bis 8.388.607. Falls man die Option unsigned wählt ist der Wertebereich 0 bis 16.777.215.

INT oder INTEGER [(M)] [UNSIGNED] [ZEROFILL]. Für ganze Zahlen im Wertebereich von -2.147.483.648 bis 2.147.483.647. Falls man die Option unsigned wählt ist der Wertebereich 0 bis 4.294.967.295.

BIGINT [(M)] [UNSIGNED] [ZEROFILL](large integer). Für ganze Zahlen im Wertebereich von -9.223.372.036.854.775.808 bis 9.223.372.036.854.775.807. Falls man die Option unsigned wählt ist der Wertebereich 0 bis 18.446.744.073.709.551.615.

Obiges zeigt, dass sehr unterschiedliche INTEGER-Datentypen angeboten werden. Je nach benötigter maximaler Zahlengröße wählt man den, in den die Zahlen gerade noch reinpassen.

SERIAL. Dieser Datentyp entspricht BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE. Damit ist er einer der Datentypen die mehr Komfort als die einfachen Datentypen anbieten. Mit der Bezeichnung alleine ist der große Wertebereich festgelegt, die Tatsache, dass es keine negativen und keine Leereinträge gibt und dass bei der Eingabe automatisch hochgezählt wird.

Die Parameter zeigen, dass bei SERIAL ein großer Wertebereich positiver ganzer unterschiedlicher Zahlen, die bei der Eingabe automatisch hochgezählt werden, vorgesehen ist.

DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL). Für Kommazahlen mit fixierter Kommastelle. M gibt die Gesamtzahl aller Stellen an (max. 65) und D die Anzahl der Stellen rechts vom Komma (max. 30). Voreinstellung für M ist 10 und für D null. Das Komma und das eventuelle Minuszeichen werden für M nicht gezählt.