Diplomarbeit Datenbank-Entwurf durch „Reverse Engineering“ von

Diplomarbeit
Datenbank-Entwurf durch
„Reverse Engineering“ von
relationalen Datenbanken
Stefan Rollert
Matrikelnummer 1443941
Betreuer: Prof. Dr. Udo Lipeck
Institut für Informatik
Universität Hannover
Februar 1996
- ii -
Zusammenfassung
In den letzten Jahren haben sich in allen Bereichen, in denen größere Datenmengen gespeichert werden
müssen, „relationale Datenbanksysteme“ durchgesetzt. Grundlage des Entwurfes einer relationalen
Datenbank ist meist ein „(erweitertes) Entity-Relationship-Schema“ (EER-Schema). Mit Hilfe von
Werkzeugen zum Datenbank-Entwurf läßt sich ein EER-Schema in ein Relationenschema umsetzen.
Da sich im Laufe ihrer Existenz die Anforderungen an eine Datenbank ändern, erfährt die relationale
Struktur typischerweise zahlreiche Korrekturen, die das Relationenschema unverständlich werden
lassen. An dieser Stelle wäre es hilfreich, aus einem relationalen Datenbank-Schema das zugehörige
EER-Schema zurückzugewinnen.
Für diese Art von „Reverse Engineering“ lassen sich bereits einige Verfahren in der Literatur finden.
Dabei erweist sich das Verfahren von Chiang / Barron / Storey als das leistungsfähigste, weil bei diesem
Algorithmus mehr strukturelle Eigenschaften aus dem Relationenschema wiedergewonnen werden als
bei anderen Verfahren. Jedoch werden Kardinalitäten von Beziehungen, bestimmte Beziehungsarten
und einige weitere Strukturen nicht erkannt. Ziel dieser Arbeit ist daher, auf Basis des Verfahrens von
Chiang einen Algorithmus zu entwickeln, der über Anfragen versucht, weitere Informationen über die
relationale Struktur einer Datenbank zu gewinnen. Alle Tabellen und ihre Attribute werden bei diesem
Verfahren bestimmten Entity- bzw. Beziehungs- Klassen zugeordnet und in Objekte eines EER-Schemas
umgesetzt.
- iii -
Das zu diesem Algorithmus in der Programmiersprache „C“ entwickelte Programm liest ein Schema aus
einer Oracle-Datenbank. Zu den Informationen über Tabellen, die aus dem Oracle-Data-Dictionary
gewonnen werden, kann der Anwender zusätzliche Schlüsselkandidaten und Fremdschlüssel bestimmen.
Durch Datenbank-Anfragen werden die Vermutungen des Benutzers überprüft und gegebenenfalls
zurückgewiesen.
Das auf diese Weise gewonnene Relationenschema kann mit Hilfe des entwickelten Verfahrens in ein
EER-Schema umgesetzt, aber auch mit anderen Tools weiterverarbeitet werden.
Zur Überprüfung des Verfahrens wird eine Fallstudie angefertigt, die einen Ausschnitt der relationalen
Studenten-Datenbank der Hochschul-Informations-Systeme GmbH (HIS) in ein EER-Schema umsetzt.
- iv -
Inhaltsverzeichnis
ZUSAMMENFASSUNG ..................................................................................... ii
1 EINLEITUNG.................................................. Fehler! Textmarke nicht definiert.
2 GRUNDLAGEN ................................................................................................4
2.1 WOZU DIENT „REVERSE ENGINEERING“ ? ...........................................................4
2.2 WAS MUß EIN RE-ALGORITHMUS TUN ? ..............................................................5
2.3 WELCHE OBJEKTE ENTHÄLT DAS ZIELMODELL ?..................................................5
2.4 WIE IST DAS QUELLMODELL AUFGEBAUT ?........................................................10
2.5 WIE KANN DIE QUALITÄT EINES SCHEMAS BEWERTET WERDEN ? .......................12
2.6 WIE WIRD EIN EER-SCHEMA IN EIN RELATIONENSCHEMA UMGESETZT ?............13
2.7 WELCHE VERFAHREN ZUM „REVERSE ENGINEERING“ WURDEN BEREITS
VERÖFFENTLICHT ?......................................................................................19
2.8 WIE SIND DIE VERFAHREN ZU BEWERTEN ? .......................................................20
2.9 AUF WELCHE WEISE SETZEN DIE ALGORITHMEN EIN RELATIONENSCHEMA IN
„IHR“ ZIELMODELL UM ?..............................................................................20
2.10 WIE ARBEITET DER ALGORITHMUS VON CHIANG ?...........................................21
2.11 WAS MACHT CHIANGS VERFAHREN AUS DER HIS-DB ? ..................................26
2.12 WELCHE PROBLEME TRETEN BEI CHIANG AUF ?...............................................32
2.13 WIE ARBEITEN DIE ANDEREN ALGORITHMEN ? ................................................35
3 LÖSUNGSANSATZ ........................................................................................41
3.1 ERMITTELN VON PRIMÄR- UND FREMDSCHLÜSSELN..........................................42
3.2 KLASSIFIKATION DER RELATIONEN UND ATTRIBUTE..........................................45
-v-
3.3 ERZEUGUNG EINES (E)ER-SCHEMAS ................................................................49
3.3.1 Starke Entity-Relationen ..........................................................................50
3.3.2 Besondere Entity-Relationen ....................................................................51
3.3.3 Schwache Entity-Relationen .....................................................................51
3.3.4 Spezielle Beziehungs-Relationen ..............................................................52
3.3.5 Reguläre Beziehungsrelationen ................................................................54
3.3.6 Sonderfall bei Beziehungsrelationen ........................................................55
3.3.7 Fremdschlüssel-Beziehungen....................................................................56
3.3.8 Aggregationen..........................................................................................57
3.3.9 Fremdschlüssel besonderer Entity-Relationen ..........................................58
3.3.10 Kardinalitäten........................................................................................61
3.4 BEWERTUNG DES EIGENEN VERFAHRENS ..........................................................66
4 ALGORITHMUS UND CODIERUNG ..........................................................73
4.1 MARKOWITZ-TOOLS ........................................................................................74
4.2 PROGRAMMENTWICKLUNG ...............................................................................75
4.2.1 ora2rel.....................................................................................................78
4.2.2 rel2pre .....................................................................................................88
4.2.3 Übrige Programme ..................................................................................97
4.3 FALLSTUDIE: UMSETZUNG EINER STUDENTEN-DATENBANK ..............................98
4.3.1 Vorbereitung ............................................................................................98
4.3.2 Programmstart.......................................................................................100
4.3.3 Relationenschema erstellen ....................................................................101
4.3.4 Umsetzung des Relationenschemas in ein PRE-Schema..........................112
4.3.5 Umwandlung in ein SDT-Schema ...........................................................116
4.3.6 Vergleich der erzeugten SDT-Schemata..................................................118
4.3.7 Grafische Ausgabe des Schemas.............................................................120
4.4 BEWERTUNG DER RESULTATE .........................................................................127
4.5 FOLGERUNGEN FÜR DAS RELATIONENSCHEMA ................................................129
4.6 VERGLEICH MIT CHIANGS VERFAHREN ...........................................................130
4.7 S-DESIGNOR PROFESSIONAL...........................................................................131
- vi -
5 AUSBLICK....................................................................................................134
GLOSSAR.........................................................................................................137
LITERATURHINWEISE.................................................................................139
ANHANG..........................................................................................................141
ANHANG A: FORMATE.........................................................................................141
a Relationen-Format.......................................................................................141
b PRE-Format ................................................................................................142
c SDT-Format.................................................................................................143
ANHANG B: BENUTZERHANDBUCH ......................................................................144
a Programmquellen ........................................................................................144
b Systemvoraussetzungen ................................................................................144
c Installation...................................................................................................145
d Benutzung ....................................................................................................146
e Fehlermeldungen / Warnungen.....................................................................149
ANHANG C: UMSETZUNG EINER LITERATUR-DATENBANK ....................................151
ANHANG D: BEISPIEL-INSTANZEN DER TEST-DATENBANK ...................................156
ANHANG E: PROGRAMMQUELLEN .......................................................................158
a eingabe.h .....................................................................................................158
b eingabe.c .....................................................................................................159
c menu.h .........................................................................................................162
d menu.c .........................................................................................................163
e ora2rel.pc ....................................................................................................166
f rel2pre.c .......................................................................................................185
g haupt.c.........................................................................................................198
h pre2sdt.sed...................................................................................................201
i crschema.sql .................................................................................................201
-7-
-1-
1 Einleitung
In den vergangenen Jahren haben sich in allen Bereichen, wo größere Datenmengen
gespeichert werden müssen, die sogenannten „relationalen Datenbanken“ durchgesetzt
und alte Modelle wie z.B. das Netzwerkmodell abgelöst. Heute trifft man auf allen
Betriebssystemen fast ausschließlich auf Datenbanksysteme, die ihre Daten in Form von
Tabellen speichern. Dies gilt nicht nur für den professionellen Bereich - auch im
Heimbereich haben die relationalen Datenbanksysteme ihren Einzug gehalten.
Grundlage für den Entwurf einer relationalen Datenbankstruktur bildet heute das
sogenannte „Entity-Relationship-Modell“, in dem die zu speichernden Daten und ihre
Beziehungen zueinander grafisch dargestellt werden. Algorithmen wurden entwickelt, die
ein so entstandenes ER-Schema in die Tabellenstruktur einer relationalen Datenbank
übertragen. Der Vorteil eines solchen systematischen Vorgehens ist die einfache und
leicht änderbare Struktur und die anwendungsnahe Semantik, die eine auf diese Weise
erzeugte Datenbank erhält.
Ist hingegen bereits eine Datenbank oder ein Dateisystem vorhanden, die in das
Relationenmodell umgesetzt werden soll, so sparen sich die meisten Entwickler den
„Umweg“ über ein (E)ER-Modell und übertragen die Daten einfach in eine
Tabellenstruktur. Vielfach wissen die Entwickler überhaupt nicht, welche Daten sich
hinter den einzelnen Attributen einer Datenbank verbergen, wenn z.B. die Entwickler der
„Ur-“Datenbank nicht mehr „verfügbar“ sind. Die Folge ist, daß das relationale System
unübersichtlich wird und nicht mehr klar erkennbar ist, in welcher Form die Daten in der
Datenbank abgelegt werden. Eine Änderung der Struktur oder ein Übertragen der Daten
in ein neues Modell (beispielsweise ein objektorientiertes Modell) wird auf diese Weise
immer schwieriger.
Die gleichen Probleme treten auf, wenn sich die Anforderungen an ein
Datenbanksystem im Laufe der Zeit ändern. Die Entwickler stehen häufig unter
Zeitdruck, so daß ein Modellieren der neuen Anforderungen ausbleibt und z.B. Attribute
einfach in die bestehende Datenbank eingefügt werden.
-2-
„Reverse Engineering“ (RE) von einer relationalen Datenbank bezeichnet den
Vorgang, aus einer Tabellenstruktur ein (E)ER-Schema zu entwickeln. Das Ergebnis
eines solchen Vorgangs ist ein aussagekräftiges Modell der Datenbankstruktur, die es
auch einem Außenstehenden ermöglicht, die Inhalte der Daten zu verstehen und das
Schema gegebenenfalls zu rekonstruieren. Häufig ist ein so gewonnenes (E)ER-Schema
sogar besser als das originale Entwurfsschema, weil sich die Anforderungen nach dem
ersten Datenbankentwurf geändert und verschiedene Entwickler die Tabellenstruktur
bearbeitet haben können.
Der Begriff „Reverse Engineering“ stammt ursprünglich aus der HardwareEntwicklung, wo versucht wird herauszufinden, wie Systeme anderer Unternehmen
funktionieren. Bei Software-Systemen wird hingegen meist untersucht, wie das eigene
System läuft. Hier ist Ziel des Reverse Engineering-Prozesses, Software-Komponenten
zu identifizieren und ihre Beziehungen untereinander zu ermitteln. Auch die Analyse der
Anforderungen an ein solches Software-System ist Aufgabe des Reverse Engineering.
Alte Systeme (in der englischsprachigen Literatur tritt häufig der Begriff „legacy
systems“ auf) werden in der Realität immer wieder geändert und erweitert, obwohl der
Entwickler nicht alle Funktionen des Systems verstanden hat. Hier wird Reverse
Engineering dazu benutzt, Algorithmen zu verstehen und Programmteile eventuell
wiederzuverwenden. Im Programm implementierte Unternehmens-Regeln, die nur im
System präzise definiert und sonst schlecht dokumentiert wurden, können so aufgespürt
und Mängel erkannt werden.
Aus denselben Gründen wird Reverse Engineering auch bei Datenbanken
angewendet. Besonders bei Portierung einer Datenbank auf eine andere Plattform ist die
Anwendung eines Reverse Engineering-Verfahrens sinnvoll.
Ziel dieser Arbeit ist, einen Algorithmus zu entwerfen, mit dem man aus einer
Menge von Relationen ein bezüglich der Entwurfskriterien „gutes“ (E)ER-Schema
erstellen kann. Dazu werden die in der Literatur beschriebenen Verfahren verglichen und
bewertet (siehe Kapitel 2). Im Anschluß daran soll ein eigener Algorithmus entwickelt
werden, der mit möglichst wenigen Eingaben des Anwenders auskommt (Kapitel 3,4).
-3-
An dieser Stelle möchte ich mich bei Herrn Prof. Dr. Udo W. Lipeck für die gute
Betreuung während der letzten sechs Monate bedanken. Seine Anregungen und Hinweise
haben mir bei Bearbeitung dieser Arbeit sehr geholfen.
Viele hilfreiche Diskussionen konnte ich auch mit Herrn Michael Gertz führen.
Vielen Dank dafür.
Kommentare zu Vorversionen dieser Arbeit habe ich außerdem von Claudia
Wehrhahn und Patricia Giesemann erhalten. Auch für ihre Hilfe bin ich dankbar.
-4-
2 Grundlagen
2.1 Wozu dient „Reverse Engineering“ ?
Es gibt verschiedene Gründe, eine vorhandene relationale Datenbank in ein ER-Schema
zu übersetzen. Die grafische Darstellung einer Datenbank-Struktur ist leicht zu verstehen
und hat eine anwendungsnahe Semantik. Ein ER-Diagramm ist dadurch aussagekräftiger
und einfacher zu ändern als eine relationale Datenbankstruktur. So können zum Beispiel
unnötige Tabellen-Attribute oder Redundanzen (mehrfache Speicherung derselben
Daten) entfernt und Inkonsistenzen in der Struktur leichter aufgefunden werden. Zum
anderen kann eine Umsetzung in ein grafisches Modell Dokumentationszwecke erfüllen.
Die genannten Änderungen werden erforderlich, wenn sich Anforderungen an eine
Datenbank im Laufe der Zeit ändern. Der Wunsch, Programme beim ersten Mal perfekt
zu erstellen, ist deshalb nicht zu erfüllen. RE versucht, aus den vorhandenen Relationen
die Aufgaben des Systems abzuleiten. Manchmal ist es allerdings sehr schwierig, ein
grafisches Modell zu produzieren, weil auch Datenbank-Experten die Regeln eines guten
Datenbankentwurfs verletzen.
Andererseits ermöglicht erst das grafische Schema eine Übersetzung der Datenbank
in andere Modelle. Aber auch der Wechsel von einem relationalen Datenbanksystem zu
einem anderen kann eine Umstrukturierung der Datenbank erfordern, wenn zum Beispiel
das Schema speziell für ein System optimiert wurde. Das ER-Modell ist unabhängig von
der physikalisch implementierten Datenbank.
-5-
altes Rel.Schema
ER-Schema
restrukturiertes
ER-Schema
neues Rel.Schema
Erweiterung
Dokumentation
objektorient.
Datenmodell
hierarchisches
Datenmodell
2.2 Was muß ein RE-Algorithmus tun ?
Im Grunde muß ein Reverse-Engineering-Algorithmus „nur“ den Prozeß des „Forward
Engineering“ (s.u.) aufheben und umkehren. Dazu sollten alle verfügbaren Informationen
ausgewertet werden: das Schema sowie die Daten. Zusätzliche Informationen, die ein
Anwender eingibt, können sehr hilfreich sein.
Weil die vorhandenen Informationen über die Datenbank meist nicht ausreichen, um
eine eindeutige Modellierungs-Entscheidung zu treffen, ist bei RE viel Kommunikation
mit dem Anwender erforderlich. Zum Beispiel ist oft nicht zu ermitteln, ob eine Relation
ein Entity oder eine Beziehung repräsentieren soll. Ebenso muß der Nutzer
Integritätsbedingungen eingeben, wenn diese in dem benutzten Datenbanksystem nicht
gespeichert werden.
2.3 Welche Objekte enthält das Zielmodell ?
Als Zielmodell des „Reverse Engineering“-Prozesses dient in der Literatur ein
„erweitertes Entity-Relationship (EER) Modell“. In diesem „semantischen“ Modell wird
die Realität auf hoher Abstraktionsebene repräsentiert, so daß es leicht zu verstehen und
interpretieren ist. Im Gegensatz dazu ist das Relationenmodell ein „logisches“ Modell,
das Daten in einer physikalisch leicht zu speichernden Form ablegt.
Es gibt zum Teil recht unterschiedliche Erweiterungen des Entity-Relationship
Modells. Auch in den Artikeln, die sich mit Reverse Engineering von relationalen
Datenbanken beschäftigen, sind Unterschiede im Zielmodell zu verzeichnen.
-6-
In der Vergangenheit hat sich aber das Modell von Batini/Ceri/Navathe [3] als ein
Quasi-Standard etabliert. Dieses EER-Modell wird auch am häufigsten von den Autoren
der betrachteten Artikel benutzt. Es soll deshalb an dieser Stelle näher erläutert werden.
Die Basis eines ER-Modells bilden die Klassen Entities, Beziehungen und Attribute:
Entities repräsentieren Objekte der realen Welt. Gleichartige Objekte werden in
Entity-Typen wie z.B. „Student“ oder „Professor“ zusammengefaßt. In grafischer
Notation werden Entity-Typen durch Rechtecke dargestellt.
Wie in der Literatur üblich soll im folgenden statt Entity-Typ einfach Entity
geschrieben werden. Muß zwischen Entity und Entity-Typ unterschieden werden, so
wird explizit darauf hingewiesen.
Beziehungen stellen Zusammenhänge zwischen zwei oder mehr Entities her. Der
Grad einer Beziehung ist gleich der Anzahl der teilnehmenden Entities. Am häufigsten
treten binäre Beziehungen, also Beziehungen vom Grad 2, auf. Zwischen „Student“ und
„Professor“ besteht zum Beispiel die Beziehung „wird betreut“, die im Modell als
Raute dargestellt wird.
Ein Ring ist eine binäre Beziehung, die ein Entity mit sich selbst verbindet. Ringe
werden oft auch als rekursive Beziehungen bezeichnet.
Die Kardinalität legt fest, an wievielen Beziehungs-Instanzen ein Entity teilnehmen
kann. Sie wird durch ein Paar ganzer Zahlen (Minimum, Maximum) angegeben. Ein N
bzw. M als Minimum bzw. Maximum bedeutet „beliebig viele“. Es gibt drei
grundlegende Kardinalitätsverhältnisse für binäre Beziehungen: 1:1, N:1 und N:M. Das
passende Verhältnis für eine Beziehung hängt von der Situation in der realen Welt ab, die
durch
die
Beziehung
modelliert
wird.
Auf
folgende
Art
kann
aus
dem
Kardinalitätsverhältnis einer Beziehung die Kardinalität ermittelt werden:
Kardinalitätsverhältnis
(Min,Max) von Entity 1
(Min,Max) von Entity 2
N:M
N:1
1:1
(0,N)
(0,1)
(0,1)
(0,M)
(0,N)
(0,1)
-7-
Die Beziehung „wird betreut“ ist zum Beispiel eine typische N:1-Beziehung, denn ein
Student kann nur von einem Professor betreut werden, ein Professor hingegen betreut in
der Regel mehrere Diplomarbeiten.
Student
(0,1)
wird betreut
(0,N)
Professor
Attribute enthalten die gespeicherten Daten von Entities und Beziehungen. Alle
externen Informationen werden in Attributen abgelegt. Attribute vom Entity „Student“
sind beispielsweise der Name und die Matrikelnummer des Studenten, die
folgendermaßen notiert werden:
Name
Student
Matrikelnr
oder
Matrikelnr, Name
Student
Batini/Ceri/Navathe erweitern dieses Modell um folgende Elemente:
Ein Entity-Typ E ist eine Generalisierung einer Gruppe von Entity-Typen E1,...,En,
wenn jedes Objekt der „speziellen“ Typen E1,...,En auch Objekt des „generellen“ EntityTyps E ist. So ist zum Beispiel der Entity-Typ „Person“ Vereinigung der Entity-Typen
„Mann“ und „Frau“. Da kein Objekt sowohl in „Mann“ als auch in „Frau“ stehen kann,
handelt es sich hierbei um eine exklusive Generalisierung. Im Gegensatz dazu ist es bei
einer überlappenden Generalisierung erlaubt, daß Objekte in mehr als einem Entity-Typ
Ei gespeichert werden. Außerdem wird zwischen totaler und partieller Generalisierung
unterschieden: Nur bei partieller Generalisierung ist es möglich, daß E Objekte enthält,
die in keinem Ei enthalten sind. Bei folgendem Beispiel handelt es sich also um eine totale
exklusive Generalisierung:
Person
Mann
Frau
-8-
Der Vorteil einer derartigen Generalisierung ist, daß Attribute, die in allen EntityTypen E1,...,En gespeichert werden, nur im generellen Entity-Typ E abgelegt werden
müssen und aus den speziellen Entity-Typen entfernt werden können. Zum Beispiel hat
jede „Person“ einen Namen, so daß das Attribut „Name“ nur in „Person“ stehen muß,
nicht jedoch in den Entity-Typen „Mann“ bzw. „Frau“.
Ein besonderer Fall einer Generalisierungs-Hierarchie ist die Spezialisierung. Hier
sind die Objekte in einem Entity-Typ einfache Untermenge der Objekte eines anderen
Entity-Typs. Nach obiger Bezeichnungsweise ist die Spezialisierung eine partielle
exklusive Generalisierung mit nur einem speziellen Entity-Typ.
Mitarbeiter
Manager
Einige Attribute fungieren als Schlüssel. Der Primärschlüssel dient dabei der
eindeutigen Identifikation eines Datentupels. Sei E ein Entity, A1,...,An Attribute von E.
Seien E1,...,Em weitere Entities mit Primärschlüssel P1,...,Pm, die mit E über binäre 1:1oder N:1-Beziehungen R1,...,Rm verbunden sind. Ein möglicher Primärschlüssel ist dann
die Menge P={A1,...,An,P1,...,Pm}, n≥0, m≥0, n+m≥1. Zu beachten ist dabei die Gefahr,
rekursive Primärschlüssel-Definitionen zu erhalten. Da eine solche Schlüssel-Definition
keinen Sinn macht, seien rekursive Primärschlüssel verboten. Als Primärschlüsselwert P
für ein bestimmtes Tupel e bezeichnet man die Zusammensetzung aller Werte der
Attribute Ai und alle Tupel der Entities Ej, die mit e in Beziehung stehen.
Ein Primärschlüssel P von E hat folgende Eigenschaften:
- Es kann nicht zwei Tupel von E mit demselben Primärschlüsselwert geben.
- Der Primärschlüssel ist in dieser Eigenschaft minimal, d.h. wenn wir ein beliebiges
Attribut Ai oder einen beliebigen Primärschlüssel Pj von Entity Ej aus dem
Primärschlüssel P entfernen, so gilt die erste Eigenschaft nicht mehr.
Es ist zu beachten, daß der Primärschlüssel keineswegs eindeutig sein muß. Es kann
zum Beispiel in einem Entity mehrere Schlüsselkandidaten geben, aus denen einer als
Primärschlüssel ausgewählt wird.
Eine Klassifikation der Schlüssel wird durch folgende Definitionen vorgenommen:
Ein Schlüssel heißt einfach, wenn n+m=1 gilt, bzw. zusammengesetzt, wenn n+m>1
ist. Er heißt intern für m=0, extern für n=0 oder gemischt für n>0 und m>0.
-9-
Mit diesen Definitionen können Entities in zwei Klassen unterteilt werden: Starke
Entities haben einen internen Primärschlüssel, der nur aus Attributen des Entities besteht.
Schwache Entities E hingegen können nicht eindeutig über ihre internen Attribute
identifiziert werden. Ihr Primärschlüssel besteht zum Teil aus Attributen anderer Entities
Ej, die Eigentümer genannt werden und mit E über binäre 1:1- oder N:1-Beziehungen
verbunden sind. Wenn m>1 ist, so hat E mehrere Eigentümer verschiedenen Typs.
Jedes Entity benötigt im Datenbankentwurf mindestens einen Primärschlüssel. Im
Datenbank-Schema werden Attribute, die zum Primärschlüssel gehören, unterstrichen.
Bei einem schwachen Entity E ist zu beachten, daß nicht nur die unterstrichenen internen
Attribute von E zu seinem Primärschlüssel gehören, sondern zusätzlich die
Primärschlüsselattribute der Eigentümer für eine eindeutige Identifikation der Tupel
notwendig sind. Die Eigentümer werden im Schema dadurch kenntlich gemacht, daß an
der (binären) Beziehung zu E ein senkrechter Strich steht.
Zum Beispiel seien die Entities „Abteilung“, „Projekt“ und „Mitarbeiter“ gegeben.
Einer Abteilung können dabei mehrere Projekte zugeordnet werden, die von jeder
Abteilung durchnumeriert werden. Ein Mitarbeiter wiederum kann immer nur an einem
Projekt arbeiten. Folgendes Schema bietet sich an:
Abteilung
(0,N)
betreut
(1,1)
Projekt
(1,N)
arbeitet
Projektnr, Projname
Abteilnr
(0,1)
Mitarbeiter
Name
Arbeiternr
Das starke Entity „Abteilung“ hat als Primärschlüssel das Attribut „Abteilnr“. Es
handelt sich hierbei also um einen einfachen internen Schlüssel. Analog dazu ist der
Primärschlüssel von „Mitarbeiter“ einfach und intern, das Entity ist deshalb stark.
„Projekt“ hingegen ist ein schwaches Entity, da sein Primärschlüssel aus dem Attribut
„Projektnr“ und dem Primärschlüssel des Entities „Abteilung“, also dem Attribut
„Abteilnr“, zusammengesetzt ist. Der Schlüssel von „Projekt“ ist damit gemischt und
zusammengesetzt, der einzige Eigentümer von „Projekt“ ist das Entity „Abteilung“, das
mit Entity „Projekt“ über die binäre 1:N-Beziehung „betreut“ verbunden ist.
Eine
Aggregation
ist
eine
Art
der
Abstraktion,
indem
eine
Anzahl
zusammenhängender Objekte zu einem abstrakten Entity zusammengefaßt werden.
Dadurch ist es möglich, daß eine Beziehung an einer anderen Beziehung teilnimmt, denn
- 10 -
ein abstraktes Entity kann genauso Bestandteil einer Beziehung sein wie ein anderes
Entity. Mit Hilfe der Ersetzung derartiger Teilschemata durch abstrakte Entity-Typen
können ER-Schemata übersichtlicher gestaltet werden, indem die einzelnen Bestandteile
einer solchen Aggregation separat modelliert werden.
Zum Beispiel kann in obigem Schema ein abstrakter Entity-Typ „Arbeitsplatz“ die
Entity-Typen „Abteilung“ und „Projekt“ sowie die Beziehung „betreut“ ersetzen. Es ist
leicht einzusehen, daß bei Ersetzung eines viel größeren Teilschemas das Diagramm an
Übersichtlichkeit gewinnt.
Abteilung
(0,N)
betreut
(1,1)
Projekt
(1,N)
arbeitet
(0,1)
Mitarbeiter
Arbeitsplatz
⇔
Arbeitsplatz
(1,N)
arbeitet
(0,1)
Mitarbeiter
2.4 Wie ist das Quellmodell aufgebaut ?
Als Quellmodell wird das relationale Datenmodell benutzt. Die Basis dieses Modells
bilden Tabellen, in denen verschiedene Attribute zusammengefaßt werden. Ein Tupel
einer solchen Relation ist eine Zeile der Tabelle, also die Sammlung von Werten jedes
Attributs. Schlüssel sind im Relationenmodell ähnlich definiert wie im EER-Modell: Ein
Schlüssel einer Relation ist eine Menge von Attributen dieser Relation, die ein Tupel
eindeutig identifizieren. Im Gegensatz zum EER-Modell sind hier ausschließlich interne
Schlüssel erlaubt.
Auch eine Relation kann mehrere Schlüsselkandidaten haben, von denen einer als
Primärschlüssel gewählt wird.
Beziehungen wie im ER-Modell gibt es im Relationenmodell nicht. Stattdessen
werden zur Repräsentation von Beziehungen Joins zwischen Attributen verschiedener
- 11 -
Tabellen benutzt. Dies bedeutet: Wenn die Tupel zweier Tabellen zueinander in
Beziehung stehen, dann müssen die Werte der Attribute, über denen der Join definiert ist,
übereinstimmen.
Auf einem Relationenschema werden weiterhin Integritätsbedingungen definiert, die
für alle Instanzen des Schemas gelten. Besonders drei Arten von Integritätsbedingungen
sollten beachtet werden:
Schlüssel-Bedingungen spezifizieren die Schlüsselkandidaten einer Relation. Die
Werte der Schlüsselkandidaten müssen für alle Tupel eindeutig sein.
Entity-Integritätsbedingungen legen fest, daß kein Wert eines Primärschlüssels leer
sein kann. Dies ist notwendig, weil der Wert des Primärschlüssels die Tupel der Relation
identifiziert.
Referentielle Integritätsbedingungen werden im Gegensatz zu den anderen beiden
genannten Bedingungsarten zwischen zwei Relationen definiert. Sie sind für die
Aufrechterhaltung der Konsistenz zwischen Tupeln zweier Tabellen verantwortlich und
besagen, daß die Tupel einer Relation, die mit einer anderen Relation in Beziehung steht,
auf bestehende Tupel in dieser Relation verweisen müssen.
Um diese referentiellen Integritätsbedingungen
Relationenschema
Fremdschlüssel
definiert.
Die
zu
speichern,
Bedingungen,
die
werden
zu
im
einem
Fremdschlüssel gehören, spezifizieren eine Integritätsbedingung zwischen den Relationen
R1 und R2. Eine Menge von Attributen FS aus Relation R1 definiert einen
Fremdschlüssel, wenn FS dieselben Daten wie der Primärschlüssel von R2 speichert.
Man sagt auch, daß FS auf Relation R2 verweist. Außerdem muß jeder Wert von FS
eines Tupels von R1 auch Wert des Primärschlüssels (PS) eines Tupels von R2 oder leer
sein. Es gilt also: ∀t:R1 ∃t′:R2 mit t.FS=t′.PS.
Oft müssen weitere (referentielle) Abhängigkeiten angegeben werden, um andere
Integritätsbedingungen zu repräsentieren, die durch die Definition von Fremdschlüsseln
nicht übernommen werden können. Sie werden durch sogenannte Inklusionen definiert:
Definition:
Seien R1,R2 Relationen, M und N eine Menge von Attributen
derselben Anzahl aus R1 bzw. R2. Dann sei: R1.M→R2.N :⇔ ∀t:R1 ∃t′:R2 mit t.M=t′.N
(Werte in R1.M sind Untermenge der Werte von R2.N)
- 12 -
Mit Hilfe dieser Definition können die Fremdschlüssel-Bedingungen auch wie folgt
geschrieben werden:
Definition:
Seien R1,R2 Relationen, FS und N eine Menge von Attributen
derselben Anzahl aus R1 bzw. R2. FS ist Fremdschlüssel von R1, wenn N Primärschlüssel
von R2 ist und R1.FS→R2.N gilt.
In den heute erhältlichen kommerziellen Datenbank-Management-Systemen sind
meist nicht alle diese Integritätsbedingungen definierbar. In diesem Fall muß sie der
Datenbank-Administrator gesondert notieren.
2.5 Wie kann die Qualität eines Schemas bewertet
werden ?
Um festzustellen, „wie gut“ ein Schema ist, müssen zunächst Kriterien festgelegt werden,
nach denen die Güte eines Schemas bewertet werden kann. Sieben Qualitätsmerkmale
werden von Batini/Ceri/Navathe [3] vorgeschlagen:
Vollständigkeit: Ein Schema wird vollständig genannt, wenn es alle relevanten
Merkmale des Anwendungsgebietes repräsentiert.
Korrektheit: Ein Schema heißt korrekt, wenn es geeignete Objekte des (E)ERModells benutzt. Dabei muß zwischen syntaktisch und semantisch korrekt unterschieden
werden. Ein Schema heißt syntaktisch korrekt, wenn die im Modell benutzten Objekte
richtig definiert werden. So ist zum Beispiel ein Schema, in dem Generalisierungen
zwischen
Beziehungen
verwendet
werden,
nicht
syntaktisch
korrekt,
denn
Generalisierungs-Hierarchien werden nur für Entities definiert. Semantisch korrekt nennt
man ein Schema, wenn seine Objekte (Entities, Beziehungen, usw.) gemäß ihrer
Definition benutzt werden. So ist zum Beispiel die Benutzung eines Attributes für die
Speicherung von Produkten semantisch falsch, wenn mehrere Produkt-Eigenschaften
(wie Bezeichnung, Preis, Lagerbestand, ...) in der Datenbank abgelegt werden sollen.
Stattdessen wäre das Anlegen eines Entities „Produkt“ semantisch korrekt.
Minimalität: Ein Schema ist minimal, wenn alle Aspekte der Anforderungen nur
einmal im Schema erscheinen, wenn also kein (E)ER-Objekt ohne Informationsverlust
aus dem Schema gelöscht werden kann.
- 13 -
Ausdrucksstärke: Ein Schema heißt ausdrucksvoll, wenn es alle Anforderungen in
natürlicher leicht verständlicher Weise repräsentiert, ohne weitergehende Erklärungen zu
benötigen.
Selbsterklärung: Ein Schema wird als selbsterklärend bezeichnet, wenn es
weitestgehend durch die Strukturen des Datenmodells modelliert wird und keine
Zusatzerklärungen benötigt.
Lesbarkeit: Dieses Qualitätsmerkmal, das ausschließlich das grafische Modell
betrifft, wird von unterschiedlichen Menschen auch sehr unterschiedlich bewertet. Wie
gut ein Modell lesbar ist, ist eine „persönliche Geschmacksfrage“. Allen Lesern
gemeinsam sind jedoch die Forderungen, daß sich im Modell möglichst wenige Objekte
und Verbindungen überschneiden und daß gleiche (E)ER-Objekte auch die gleiche
Darstellungs-Größe haben sollen.
Änderbarkeit: Ein Schema kann leicht geändert und an neue Anforderungen
angepaßt werden, wenn es sich in Teile (Module) zerlegen läßt.
Normalität: Dieses Qualitätsmerkmal stammt aus der Normalisierungs-Theorie des
relationalen Modells und steht etwas abseits der anderen Qualitätskriterien. Je höher die
im Schema geltende Normalform (erste bis fünfte bzw. Boyce-Codd) ist, desto besser ist
seine Qualität bezüglich dieses Merkmals. Das Ziel ist, daß die Transformation des
(E)ER-Schemas
automatisch
normalisierte
Relationen
liefert.
Die
anderen
Qualitätsmerkmale (Selbsterklärung, Ausdrucksstärke, ...) implizieren dieses Kriterium
weitestgehend, wegen der besonderen Beziehung zum Relationenmodell wird es aber in
der Regel gesondert betrachtet.
2.6 Wie wird ein EER-Schema in ein Relationenschema
umgesetzt ?
Es gibt mehrere Verfahren, ein EER-Schema in ein Relationenschema zu übersetzen.
Eines soll hier genauer betrachtet werden:
Beim Prozeß des „Forward Engineering“ ist zu beachten, daß im Relationenmodell
Beziehungen und Integritätsbedingungen zwischen Attributen verschiedener EERObjekte nicht dargestellt werden können und gesondert genannt werden.
- 14 -
Auf folgende Weise wird ein Relationenschema aus dem EER-Modell erzeugt:
Starke Entities werden in Relationen umgesetzt, deren Attribute und Schlüssel mit
denen des entsprechenden Entities übereinstimmen.
Ein schwaches Entity wird in eine Relation umgesetzt, deren Primärschlüssel sowohl
aus den „internen“ Schlüssel-Attributen (auch „hängende Schlüsselattribute“ genannt) als
auch aus dem Primärschlüssel des Eigentümers zusammengesetzt ist. Die Beziehungen
zu dem bzw. den Eigentümer(n) werden dann nicht weiter behandelt und „vergessen“, da
sie durch die „importierten“ Primärschlüsselattribute repräsentiert werden.
Im Beispiel werden die beiden Relationen „Abteilung“ und „Projekt“ erzeugt. Der
Primärschlüssel „Abteilnr“ des starken Entities wird dabei in die Tabelle „Projekt“
importiert und dient als Fremdschlüssel, wodurch die Beziehung „betreut“ repräsentiert
wird.
Abteilung
(0,N)
betreut
(1,1)
Projekt
Projektnr, Projname
Abteilnr
Es werden also die folgenden Relationen gebildet (Primärschlüssel sind einfach
unterstrichen, Fremdschlüssel punktiert unterstrichen):
Abteilung
(Abteilnr)
Projekt
(Abteilnr, Projektnr, Projname)
Weil „Abteilnr“ in Relation „Projekt“ Fremdschlüssel ist, gilt die Integritätsbedingung
Projekt.Abteilnr→Abteilung.Abteilnr.
- 15 -
Bei binären Beziehungen zwischen Entities A und B muß unterschieden werden:
A
(v,w)
R
(x,y)
A1,A2,A3
B
B1,B2
A und B haben Kardinalität (1,1):
(v=w=x=y=1)
Wenn A und B denselben Schlüssel P haben (P=A1=B1), dann definiere die
Relationen A (P,A2,A3) und B (P,B2) und folgende Abhängigkeiten für die
referentielle Integrität: A.P→B.P und B.P→A.P
Eine weitere Möglichkeit ist die „Fusion“ der Relationen, die mit A bzw. B
korrespondieren. Alle Attribute beider Relationen müssen dann in die neue
Tabelle aufgenommen werden. Der Primärschlüssel wird aber nur einmal
definiert: A_B (P,A2,A3,B2)
Wenn A und B verschiedene Schlüssel haben, dann importiere den Schlüssel von
A als Fremdschlüssel in B, den Schlüssel von B als Fremdschlüssel in A, oder
beides. Also z.B. A (A1,A2,A3,B1), B (B1,B2)
Wieder gilt die Fremdschlüsselbedingung A.B1→B.B1
Auch die „Fusion“ beider Relationen ist möglich, jedoch müssen beide Schlüssel
in der neuen Relation erscheinen, von denen einer als Primärschlüssel ausgewählt
wird: A_B (A1,A2,B1,B2,B3)
Nur ein Entity aus A und B hat die Kardinalität (1,1) (z.B. B), das andere hat
Kardinalität (0,1) (z.B. A):
(v=0, w=x=y=1)
In diesem Fall ist es sinnvoll, den Primärschlüssel des einen Entities jeweils in die
Tabelle, die das andere Entity repräsentiert, als Fremdschlüssel zu importieren,
also z.B. A (A1,A2,A3,B1), B (B1,B2,A1). Dabei ist zu beachten, daß für Tupel
aus A in B1 NULL-Werte erlaubt sind, weil in der dargestellten Beziehung nicht
umbedingt zu jedem Tupel aus A ein Tupel aus B existieren muß. Hingegen
existiert zu jedem Tupel aus B genau ein Tupel aus A, so daß Tupel aus B in
Attribut A1 keine NULL-Werte enthalten darf.
Weiterhin gelten die Integritätsbedingungen A.B1→B.B1 und B.A1→A.A1
Alternativ dazu kann zusätzlich zu den Relationen A (A1,A2,A3) und B (B1,B2)
eine neue Relation R erzeugt werden, die die Schlüssel beider Entities enthält.
- 16 -
Nur der Schlüssel des Entities mit Kardinalität (1,1) ist Primärschlüssel von R,
weil der Schlüssel des anderen Entities NULL-Werte erlauben muß, um die
dargestellte Beziehung zu repräsentieren: R (A1,B1)
Zusätzlich gelten die Fremdschlüsselbedingungen R.A1→A.A1, R.B1→B.B1
A und B haben Kardinalität (0,1):
(v=x=0,w=y=1)
Genauso wie eben werden wechselseitig die Primärschlüssel des jeweils anderen
Entities als Fremdschlüssel importiert und dieselben Fremdschlüsselbedingungen
definiert. Jedoch erlauben hier beide Fremdschlüssel NULL-Werte, also auch in
Tupeln aus B kann das Attribut A1 leer sein.
Ein Entity aus A, B hat Kardinalität (1,1) (z.B. A), das andere hat Kardinalität (1,N)
oder (0,N) (z.B. B): (v=w=x=1,y=N)
Wenn A und B denselben Schlüssel P haben (P=A1=B1), dann definiere eine der
beiden folgenden Abhängigkeiten: A.P→B.P (wenn A Kardinalität (1,1) hat) oder
B.P→A.P (wenn B Minimum/Maximum-Werte (1,1) hat).
Wenn A und B verschiedene Schlüssel haben, dann importiere den Schlüssel des
Entities, das die Kardinalität (1,N) aufweist, als Fremdschlüssel in die Relation,
die dem Entity mit Kardinalität (1,1) entspricht. Natürlich gilt wieder die
Fremdschlüsselbed.: A (A1,A2,A3,B1), B (B1,B2), A.B1→B.B1
Ein Entity aus A, B hat Kardinalität (0,1) (z.B. A), das andere hat Kardinalität (1,N)
oder (0,N) (z.B. B): (v=0,w=x=1,y=N)
Es wird eine neue Relation R erstellt, die die Schlüssel von A und B enthält. Der
Schlüssel des Entities mit Kardinalität (0,1) wird als Primärschlüssel der neuen
Relation auserwählt. R (A1,B1)
Es gelten die Integritätsbedingungen R.A1→A.A1, R.B1→B.B1
Alle anderen binären Beziehungen und allgemein Beziehungen vom Grad > 2:
Erzeuge eine neue Relation R mit einem Primärschlüssel, der aus allen Schlüsseln
der an der Beziehung beteiligten Entities zusammengesetzt wird. Für alle diese
Schlüssel gelten außerdem die Fremdschlüsselbedingungen. Zum Beispiel gilt für
(v=x=1,w=y=N): R (A1,B1) und R.A1→A.A1, R.B1→B.B1
- 17 -
Generalisierungs-Hierarchien werden umgesetzt, indem die Abhängigkeiten für die
referentielle Integrität definiert werden (analog zu oben: Wenn etwa A generelles Entity
ist und B ein spezielles Entity mit gleichem Primärschlüssel P, dann definiere B.P→A.P).
Haben die speziellen Entities andere Primärschlüssel als das generelle Entity, dann muß
vor Festlegung der Abhängigkeiten der Primärschlüssel des generellen Entities als
Fremdschlüssel in die Relationen importiert werden, die mit den speziellen Entities
korrespondieren. Die Abhängigkeiten werden dann entsprechend über die neuen
Fremdschlüssel der speziellen Entities definiert.
Name, Straße, Ort
Mitarbeiternr, Gehalt
Person
Mitarbeiter
Kunde
Kundennr
Hier entstehen folgende Relationen und Integritätsbedingungen:
Person
(Name, Straße, Ort)
Mitarbeiter
(Mitarbeiternr, Gehalt, Name)
Kunde
(Kundennr, Name)
Mitarbeiter.Name→Person.Name, Kunde.Name→Person.Name
Bei Aggregationen muß das Relationenschema für alle Bestandteile der Aggregation wie
eben beschrieben erweitert werden. Ein Spezialfall wird dabei gesondert betrachtet: Für
Beziehungen, die zwischen einem Entity und einer anderen Beziehung bestehen, müssen
folgende Fälle unterschieden werden:
Entity hat Kardinalität (1,1):
Primärschlüssel des Entities wird zum Fremdschlüssel in der Relation, die der
Beziehung entspricht.
Entity hat Kardinalität (0,1):
Erzeuge entweder eine neue Relation oder verfahre wie eben im vorherigen Fall.
Sonst:
Erzeuge eine neue Relation.
- 18 -
Der Primärschlüssel der neuen Relation wird aus dem Schlüssel des Entities und den
Primärschlüsseln der an der Beziehung beteiligten Entities zusammengesetzt.
A
R_A
R_B
(0,1)
(1,N)
B
(1,1)
A1,A2,A3
B1,B2
Bei Umsetzung dieses Schemas wird zuerst die Aggregation wie ein Entity behandelt.
Nach obigem Verfahren muß also Entity B den Primärschlüssel der Aggregation als
Fremdschlüssel importieren. Anschließend wird Entity A in eine Tabelle umgesetzt und
dann eine Relation R_A erzeugt:
B
(B1,B2,A1)
A
(A1,A2,A3)
R_A
(A1,B1)
B.A1→A.A1, R_A.A1→A.A1, R_A.B1→B.B1
Zu bemerken ist, daß bei Umsetzung eines EER-Schemas in ein Relationenschema
Informationen verloren gehen, sofern nicht zusätzlich zum Schema weitere
Integritätsbedingungen notiert werden. Zum Beispiel sind aus einem „reinen“
Relationenschema keinerlei Informationen über Kardinalitäten zu erhalten.
Werden hingegen derartige zusätzliche Bedingungen erfaßt, so läßt sich ein
Relationenschema finden, das bezüglich der gespeicherten Daten zu dem ursprünglichen
EER-Schema äquivalent ist. Beide Schemata enthalten dieselben Zustandsmengen. Wie
eben gezeigt sind aber grafische Entwurfs-Elemente wie Aggregationen im
Relationenschema nicht mehr zu erkennen, da es im Relationenmodell keine Struktur
gibt, die zu einer Aggregation äquivalent ist. Dasselbe Problem gibt es auch in
umgekehrter
Richtung:
Nicht
alle
Integritätsbedingungen,
die
auf
einem
Relationenschema definiert werden können, sind im EER-Schema wiederzuerkennen.
- 19 -
2.7 Welche Verfahren zum „Reverse Engineering“
wurden bereits veröffentlicht ?
Seit nahezu zehn Jahren findet man in den Fachzeitschriften immer wieder Artikel, die
sich mit dem Thema „Reverse Engineering von Datenbanken“ auseinandersetzen. Es ist
wegen der Verbreitung der relationalen Datenbanksysteme kaum verwunderlich, daß sich
die Verfasser dieser Texte fast ausschließlich mit relationalen Datenbanken befassen. Als
Zielmodell
wählten
die
Autoren
meist
ein
EER-Modell
wie
oben
mit
Spezialisierungen/Generalisierungen und Aggregationen [2,3,4,5,10,13,16,17]. Der
Algorithmus aus [7] bildet ein „einfaches“ ER-Diagramm. Nur Shoval/Shreiber [19]
entwickeln anhand ihres Verfahrens ein „Binary Relationship Model“. Interessant ist auch
die Variante des ER-Entwurfs, die in [23] beschrieben wird: Wenguang/Carlson/Dreyer
benutzen als Zielmodell ein „Nested ER-Model“. Dieses Diagramm zeichnet sich dadurch
aus, daß es aus mehreren Stufen bzw. Ebenen besteht. Jede dieser Ebenen enthält ein
eigenes ER-Schema. Auf diese Weise kann man z.B. ganze Gruppen von Entities und
zugehörige Beziehungen in einer höheren Ebene als ein einziges Entity schreiben. Die
Darstellung wird dadurch übersichtlicher und einfacher verständlich.
Fast alle Algorithmen bauen auf dem Schema einer vorhandenen relationalen
Datenbank auf und klassifizieren die Relationen in bestimmte Kategorien. Dabei wird
immer vorausgesetzt, daß das Schema in der „dritten Normalform“ vorliegt und auch
Angaben über die Primärschlüssel enthält. Nur die Algorithmen aus [2] und [17] bilden
hier eine Ausnahme: Sie bewerten die Tabellen anhand von Anfragen bzw. anhand von
denjenigen Programmen, die Attribute aus der Datenbank benutzen. Der Nachteil dieser
beiden Verfahren ist, daß das entstehende ER-Modell stark vom jeweiligen DatenbankZustand abhängig ist. So können zum Beispiel Beziehungen zwischen Tabellen nicht
erkannt werden, wenn die Datensätze in den Tabellen gerade zufällig voneinander
unabhängig sind. Andererseits können aber durch Anfragen Gemeinsamkeiten zwischen
Relationen erkannt werden, die ein Datenbank-Schema nicht liefert.
- 20 -
2.8 Wie sind die Verfahren zu bewerten ?
Kriterien/Fragen zur Bewertung der Algorithmen sind:
• Was für eine Art von Schema entsteht ?
• Was für Voraussetzungen werden an das Relationenschema gestellt ?
• An welchen Stellen sind Eingaben vom Nutzer erforderlich ?
• Wie groß ist der Automatisierungsgrad ?
• Kann der Nutzer den Algorithmus beeinflussen ?
• Werden sinnvolle Annahmen gemacht ?
• Ist die Übersetzung semantisch korrekt ?
• Wie ist die Qualität der Ergebnisschemata ?
• Wird Pseudo-Code für spätere Programmierung geliefert ?
Zu einigen Verfahren stehen allerdings nicht ausreichend Informationen zur
Verfügung, um sie nach all diesen Kriterien bewerten zu können.
2.9 Auf welche Weise setzen die Algorithmen ein
Relationenschema in „ihr“ Zielmodell um ?
Die Verfahren werden jetzt kurz erläutert und bewertet. Für nähere Informationen sei
hiermit auf die jeweiligen Artikel (siehe Literaturhinweise) verwiesen.
Eine große Anzahl an veröffentlichten Algorithmen lassen sich zu einer Gruppe
zusammenfassen, denn die Verfahren aus [3,4,5,10,13,16] arbeiten alle mit Hilfe einer
Klassifikation der Tabellen und anschließender Umsetzung in ein EER-Schema (wie oben
beschrieben) unter Zuhilfenahme dieser Einordnung der Relationen in unterschiedliche
Klassen. Das Verfahren von Chiang/Barron/Storey [4,5] erweist sich bei der Bewertung
mit Hilfe oben genannter Kriterien als das beste bisher veröffentlichte, weil hier dem
Anwender die Arbeit weitestgehend erleichtert wird, der Algorithmus auf der anderen
Seite aber sehr viele Informationen des Relationenschemas bzw. des Anwenders
ausnutzen und auswerten kann. Aus diesem Grund soll Chiangs Verfahren ausführlicher
betrachtet werden.
- 21 -
2.10 Wie arbeitet der Algorithmus von Chiang ?
Input:
Voraussetzung:
Relationenschema in dritter Normalform
Primärschlüssel (Fremdschlüssel empfehlenswert, s.u.)
Datensätze aus der Datenbank
In der Datenbank müssen Tupel gespeichert sein.
Attribute gleichen Namens speichern gleiche Inhalte.
Diese Datensätze dienen der Kontrolle einiger Annahmen, die der Algorithmus macht.
1. Relationenschema und Informationen über Primärschlüssel (PS) (und
Fremdschlüssel) aus Datenbank lesen oder vom Anwender eingeben lassen. Das
Relationenschema muß in der dritten Normalform vorliegen.
Um zu ermitteln, welche Tabellen welche Art von EER-Objekten (Entity oder
Beziehung) repräsentieren, werden die Relationen zunächst in vier verschiedene
Klassen eingeteilt. Durch Umkehr des oben erläuterten „Forward Engineering“Prozesses kann dann ein EER-Schema erzeugt werden.
2. Klassifikation der Tabellen: Sei A betrachtete Relation mit PS P, X und Y
beliebige weitere Relationen mit PS Q bzw. R. Mit Kleinbuchstaben werden
Attribute bezeichnet, mit ∆ die Menge aller Relationen der Datenbank.
Annahme: Attribute haben gleiche Namen, wenn in ihnen dieselben Inhalte
gespeichert werden. Es wird unterschieden zwischen:
Wenn ∀X∈(∆\{A}) gilt Q⊄P, dann ist A „starke Entity-Relation“ (SER).
(PS von A enthält keinen PS einer anderen Relation)
Wenn gilt: ∃Q⊂P ∧ ∃a∈P: ∀Y∈(∆\{A}) a∉R, dann wird A als „schwache EntityRelation“ bzw. „weak Entity-Relation“ (WER) klassifiziert.
(PS enthält sowohl Attribute, die Schlüssel einer anderen Relation sind, als auch
Attribute, die zu keiner anderen Tabelle gehören)
Gilt P=Q1∪...∪Qn, n>1, Qi PS, so wird A als „reguläre Beziehungs-Relation“ (RBR)
bezeichnet.
(PS ist Zusammensetzung von mindestens zwei PS anderer Tabellen)
Übrige Tabellen nennt man „spezielle Beziehungs-Relationen“ (SBR).
Analog zur Klassifikation der Relationen werden auch die Attribute in Klassen
unterteilt. Dies ist deshalb sinnvoll, weil viele Attribute in den Tabellen einzig der
Speicherung von Beziehungen zwischen Relationen dienen (z.B. Fremdschlüssel). Diese
Attribute werden bei der Erstellung der Beziehungen im EER-Schema beachtet.
ACHTUNG: Die Definition von „Primärschlüsselattributen“ ist hier anders als im
allgemeinen üblich.
- 22 -
3. Klassifikation der Attribute: Sei A betrachtete Relation mit PS P, ER:=SER∪WER,
BR:=RBR∪SBR.
a∈P heißt „Primärschlüsselattribut“, wenn:
A∈SER
∨
A∈WER ∧ a∈Q mit Q ist PS von (A≠)X∈ER
∨
A∈BR ∧ a∈Q mit Q ist PS von (A≠)X∈∆
(Die Menge aller Primärschlüsselattribute aus A werde mit ϕ bezeichnet, die
Menge der Primärschlüsselattribute einer Relation (A≠)X∈∆ sei ζ)
a∈P heißt „hängendes Schlüsselattribut“, wenn A∈WER ∧ a∉ϕ
a∈P heißt „allgemeines Schlüsselattribut“, wenn A∈SBR ∧ a∉ϕ
a∉P heißt „Fremdschlüsselattribut“, wenn a∈ζ für beliebiges X∈(∆\{A})
sonst heißt a∉P „Nichtschlüsselattribut“.
Die Klassifikation, die der Algorithmus vornimmt, ist abhängig von den Daten, die der
Anwender dem Verfahren vorgibt. Oftmals kann der Algorithmus aber nicht den
eigentlichen Zweck einer Relation ermitteln, so daß hier eine Nachbearbeitung durch
den Nutzer erforderlich wird. Besonders zu erwähnen ist hier die Klassifikation
zwischen schwacher Entity-Relation und spezieller Beziehungs-Relation: Manchmal
dient nämlich eine Tabelle, die als WER klassifiziert wurde, eigentlich der
Repräsentation einer Beziehung zwischen starken Entities, die bei Erzeugung des
Relationenschemas aber nicht in eigenständige Tabellen umgesetzt wurden. Durch die
Eingriffs-Möglichkeiten, die an dieser Stelle der Anwender hat, können derartige
Modellierungs-Fehler verhindert werden.
4. Klassifikation wird vom Nutzer überprüft und gegebenenfalls korrigiert.
Insbesondere unterscheidet er zwischen WER und SBR, denn alle Tabellen, die
als WER klassifiziert worden sind, können stattdessen auch als SBR behandelt
werden. Alle Klassifikations-Änderungen des Nutzers werden durch DatenbankAnfragen kontrolliert und der Anwender auf vermutete Fehler hingewiesen.
Wichtig für die spätere Erstellung von Beziehungen, Generalisierungs-Hierarchien und
Aggregationen ist die Ermittlung von Abhängigkeiten. Das Verfahren versucht,
möglichst viele Abhängigkeiten automatisch zu finden. Eine Nachbearbeitung durch den
Nutzer ist hier sehr wichtig, da die Heuristiken nicht dazu geeignet sind, alle
Abhängigkeiten zu finden. Besonders von Interesse ist hier die Kenntnis von
Fremdschlüsseln: Ohne deren Spezifikation werden über die Heuristiken kaum
Abhängigkeiten gefunden.
5. Ermitteln von Abhängigkeiten:
Seien A,B Tabellen aus ∆, N eine Menge von Attributen. Folgende Heuristiken
werden angewendet:
N ist PS von A∈SER und von B∈SER,
dann vermute A.N→B.N ∨ B.N→A.N
- 23 -
N ist PS von A∈ER und Fremdschlüssel von B (sofern FS bekannt),
dann
B.N→A.N
N ist PS von A∈ER und Teil des Primärschlüssels von B∉SER,
dann vermute B.N→A.N
Durch Anfragen werden diese Vermutungen überprüft und redundante
Abhängigkeiten gelöscht:
Ist πN(B)⊄πN(A), dann widerspricht dies der Vermutung B.N→A.N.
Gilt A.N→B.N ∧ B.M→C.M ∧ M⊂N, so ist A.M→C.M redundant und
wird verworfen.
Die Abhängigkeiten können vom Anwender editiert oder gelöscht werden. Auch
ein Hinzufügen von Abhängigkeiten ist möglich.
Die Umsetzung beginnt natürlich mit der Erzeugung der starken und schwachen
Entities, weil Beziehungen, an denen sie beteiligt sind, erst hinterher erstellt werden
können.
6. Erzeugung von starken Entities: Sei R betrachtete Relation.
∀R∈SER erzeuge starkes Entity mit PS:=Primärschlüsselattribute(R).
Name des neuen Entities:=Name von R
7. Erzeugung von schwachen Entities:
∀R∈WER erzeuge schwaches Entity mit PS:=hängende Schlüsselattr.(R) und
N:1-Beziehung zwischen neuem Entity und Eigentümer, der durch
Primärschlüsselattribute(R) bestimmt wird:
X:=Primärschlüsselattribute(R) bilden PS von A∈ER ∧ R.X→A.X,
dann ist A Eigentümer von R
Ist der Eigentümer von R nicht eindeutig festzustellen, weil mehrere Relationen A
obiger Bedingung genügen, so muß er durch den Nutzer bestimmt werden.
Name des neuen Entities:=Name von R
Name der Beziehung:=‘ABHÄNGIG’
Durch „Umkehr“ des „Forward Engineering“-Prozesses werden nun die Beziehungen,
Hierarchien und Aggregationen erstellt.
8. Erzeugung von „is a“-Beziehungen:
Wenn P ist PS von A∈SER und B∈SER ∧ A.P→B.P gilt,
dann bilde „is a“-Beziehung zwischen A und B
mit Kardinalitätsverhältnis 1:1
9. Erzeugung von Spezialisierungs-/Generalisierungs-Hierarchien:
Hat „generelles“ Entity V mehrere „is a“-Beziehungen zu „speziellen“ Entities, so
wird mit Hilfe von Anfragen geprüft, ob alle Daten von V in genau einem
speziellen Entity vorkommen. Trifft dies zu, so erzeuge Hierarchie zwischen V und
speziellen Entities.
(Dieses Verfahren erkennt also nur totale exklusive Generalisierungen)
- 24 -
10. Erzeugung von binären Beziehungen aufgrund von Fremdschlüsseln:
Für alle Fremdschlüssel Fi von B∈ER wiederhole:
Sei F:=Fremdschlüssel Fi, P:=PS von A∈∆.
Wenn F=P ∧ B.F→A.F gilt, dann bilde Beziehung zwischen A und B.
Genügt mehr als eine Relation A dieser Bedingung, so muß der Anwender eine
Tabelle auswählen
Hat B.F eindeutige (unique) Werte (wird über Anfragen vermutet und durch
Anwender überprüft), so folgt Kardinalitätsverhältnis 1:1, sonst folgt
Kardinalitätsverhältnis 1:N zwischen A und B.
Name der Beziehung:=‘HAT’
11. Erzeugung von binären Beziehungen aufgrund von Nichtschlüsseln:
Seien M:=Nichtschlüssel von B∈∆ und N:=Nichtschlüssel von A∈∆
Wenn B.M→A.N gilt, dann bilde Beziehung zwischen A und B.
Hat B.M eindeutige (unique) Werte, so folgt Kardinalitätsverhältnis 1:1, sonst 1:N
Name der Beziehung:=‘HAT’
12. Behandlung der regulären Beziehungs-Relationen: Sei R betrachtete Relation mit
R∈RBR, P der Primärschlüssel von R. W sei Menge von Entity-Relationen.
W:=∅. Für alle A∈ER wiederhole
Q sei PS von A. Wenn Q⊂P ∧ R.Q→A.Q, so sei W:=W∪A
Genügen mehrere Entities obiger Bedingung, muß der Nutzer
ein Entity aus diesen bestimmen.
Bilde n-fache Beziehung zwischen allen Entities A∈W.
Kardinalitätsverhältnis jeder binären Beziehung:=N:M
Name der Beziehung:=Name von R
13. Behandlung der speziellen Beziehungs-Relationen: Sei R betrachtete Relation mit
R∈SBR, P die Menge der Primärschlüsselattribute von R, G Menge der
allgemeinen Schlüsselattribute von R, W eine Menge von Entity-Relationen.
W:= ∅. Erzeuge starkes Entity A mit PS:=G. Wenn G>1, so
entscheidet der Anwender, wieviele neue starke Entities A
erzeugt werden sollen. W:=W∪A.
Name des neuen Entities:=(Nutzereingabe)
Für alle A∈ER wiederhole
Q sei PS von A. Wenn Q⊂P ∧ R.Q→A.Q, so sei W:=W∪A
Genügen mehrere Entities obiger Bedingung, muß der Nutzer
ein Entity aus diesen bestimmen.
Bilde n-fache Beziehung zwischen allen Entities A∈W.
Kardinalitätsverhältnis jeder binären Beziehung:=N:M
Name der Beziehung:=Name von R.
- 25 -
14. Identifikation von Aggregationen: Sei F Fremdschlüssel von R∈BR, P PS von
A∈ER.
Gilt P=F ∧ R.F→A.P, so bilde abstraktes Entity W, in dem R und alle an
dieser Beziehung beteiligten Entities zusammengefaßt werden.
Genügen mehrere A∈ER der Bedingung, muß der Nutzer entscheiden
Bilde Beziehung zwischen A und W mit Kardinalitätsverhältnis 1:N.
Name von W:=Name von R
Name der Beziehung:=(Nutzereingabe)
Den Abschluß des Verfahrens bildet die Zuweisung der Attribute zu den EER-Objekten.
15. Zuweisung der Nichtschlüsselattribute:
(Sämtliche Schlüsselattribute wurden bereits in den vorhergehenden Schritten
behandelt, denn entweder sie fungieren im EER-Schema als Primärschlüssel,
oder sie dienten der Identifikation von Beziehungen)
Sei A∈∆ Relation, V Menge der Nichtschlüsselattribute von A.
A∈ER hat keine Fremdschlüsselattribute
⇒
V wird dem Entity A′ zugeordnet, das mit A korrespondiert
A∈ER hat Fremdschlüsselattribute
⇒
V wird wahlweise A′ oder einer der durch die Fremdschlüssel
identifizierten binären Beziehungen zugeordnet
A∈BR hat keine Fremdschlüsselattribute
⇒
V wird der Beziehung A′ zugeordnet, die mit A korrespondiert
A∈BR hat Fremdschlüsselattribute
⇒
V wird wahlweise A′ oder einer der durch die Fremdschlüssel
identifizierten binären Beziehungen zugeordnet
Das fertig erzeugte EER-Schema wird in der Regel noch nicht den Wünschen des
Anwenders entsprechen. Zum Beispiel fehlt noch die Zuweisung der Kardinalitäten zu
den Objekten, da kein Algorithmus in der Lage ist, diese automatisch anhand des
Relationenschemas zu ermitteln. Die Informationen über Kardinalitäten gehen beim
„Forward Engineering“-Prozeß verloren bzw. können nur durch zusätzliche
Integritätsbedingungen ins Relationenmodell übertragen werden. Einzig die
Kardinalitätsverhältnisse werden durch das Verfahren festgestellt.
16. Korrektur: Abschließend hat der Anwender die Möglichkeit, das entstandene
Schema zu modifizieren. Dies ist besonders dann notwendig, wenn vor Beginn
des Umsetzungsprozesses nicht alle Abhängigkeiten gefunden bzw. eingegeben
worden sind.
- 26 -
2.11 Was macht Chiangs Verfahren aus der HIS-DB ?
Dieser Algorithmus soll nun auf Teile der relationalen Datenbank angewendet werden,
die bei Hochschul-Informations-Systeme GmbH Hannover (HIS) der Verwaltung von
Studentendaten dient.
Wir betrachten folgende Tabellen (Primärschlüssel sind einfach unterstrichen,
Fremdschlüssel sind punktiert unterstrichen):
• SOS
Feste Studentendaten
(MtkNr, Semester, Status, Name, Strasse, Ort, Staat,
HmKfzKz, HmKfz, ImmDat, RueDat, ExmDat, ExmGrund)
• STG
Veränderliche-Studentendaten (für jedes Semester Einträge)
(MtkNr, Semester, StgNr, Status, Stg, Abschl, BeuGrund,
EndeGrd)
• K_STG
Schlüsseltabelle für Studiengang
(Stg, Ktxt, Dtxt, AStat)
• K_ABINT
Schlüsseltabelle für Abschluß (intern)
(Abschl, Ktxt, Dtxt, AStat)
• K_ABSTG
Verknüpfung Studiengang-Abschluß
(AbStg)
• K_AKFZ
Schlüsseltabelle Auslandskennzeichen
(AKfz, Ktxt, Dtxt, AStat, EGMitgl)
• K_IKFZ
Schlüsseltabelle Inlandskennzeichen
(IKfz, Ktxt, Dtxt, AStat)
• K_GDEX
Schlüsseltabelle Exmatrikulationsgrund
(GdEx, Ktxt, Dtxt, AStat)
• K_GDBU
Schlüsseltabelle Beurlaubungsgrund
(GdBu, Ktxt, Dtxt, AStat)
Folgende für die Umsetzung wichtige Informationen sind nicht aus dem Schema
abzulesen:
I) Die Tabelle STG enthält für jeden Studenten für jedes Semester, in dem der
Student eingeschrieben ist, und für jedes Fach, das er belegt, einen eigenen
- 27 -
Datensatz. In der SOS-Relation wird hingegen in den Attributen Semester und
Status nur der Stand des aktuellen bzw. letzten Semesters gespeichert. Die
Inhalte in beiden Attributen stimmen mit den Inhalten des Satzes mit maximalem
Semester der STG-Tabelle überein. Nur für exmatrikulierte Studenten ist dies
nicht der Fall: Bei ihnen wird der SOS.Status auf ‘exmatrikuliert’ gesetzt, der
STG.Status bleibt unverändert.
II) Das einzige Attribut der Relation K_ABSTG ist zusammengesetzt aus den
Primärschlüsseln der Tabellen K_STG und K_ABINT - Stg bzw. Abschl.
Damit
das
Verfahren
diese
Tabelle
richtig
behandelt,
sei
also
AbStg:=Stg+Abschl.
III) Der Fremdschlüssel HmKfz aus Tabelle SOS verweist auf die Relationen
K_IKFZ oder K_AKFZ, je nachdem, welchen Inhalt das Attribut HmKfzKz hat.
HmKfzKz bestimmt, ob die Anschrift im In- oder Ausland liegt, und nimmt
entsprechend die Werte ‘I’ oder ‘A’ an. Zum Beispiel kann in HmKfz der
Eintrag ‘B’ stehen. Ist HmKfzKz auf ‘I’ gesetzt, so bedeutet dies, daß der
Student aus Berlin kommt. Im anderen Fall steht in HmKfzKz ein ‘A’ und der
Student kommt aus Belgien („aufgespaltene referentielle Integritätsbedingung“).
Die nachstehenden Abhängigkeiten sind bekannt:
A) SOS.HmKfz→K_AKFZ.AKfz,
B) SOS.HmKfz→K_IKFZ.IKfz,
C) SOS.ExmGrund→K_GDEX.GdEx,
D) STG.Stg→K_STG.Stg,
E) STG.Abschl→K_ABINT.Abschl,
F) STG.BeuGrund→K_GDBU.GdBu,
G) STG.EndeGrd→K_GDEX.GdEx,
H) STG.MtkNr→SOS.MtkNr,
I) K_ABSTG.Stg→K_STG.Stg,
J) K_ABSTG.Abschl→K_ABINT.Abschl.
- 28 -
Dieses Relationenschema wird durch das beschriebene Verfahren von Chiang umgesetzt.
Es wird erst einmal davon ausgegangen, daß Fremdschlüssel der Tabellen und
Abhängigkeiten dem Anwender bekannt sind. Die Schrittnummern entsprechen denen im
Algorithmus:
1. Schema an Algorithmus übergeben.
2. SOS, K_AKFZ, K_IKFZ, K_GDEX, K_GDBU, K_STG und K_ABINT sind SER,
STG ist WER, K_ABSTG ist RBR. Letzteres geht aber erst aus der
Zusatzinformation II) hervor - sonst würde K_ABSTG als SER klassifiziert werden.
3. Primärschlüsselattribute (im Sinne des Verfahrens) sind in den SER und RBR die im
Schema unterstrichenen Attribute des Primärschlüssels, in STG ist es einzig das
Attribut MtkNr. Die anderen Attribute des PS von STG (Semester und StgNr)
sind hängende Schlüsselattribute. Fremdschlüsselattribute sind in den Tabellen SOS
und STG zu finden, und zwar in SOS die Attribute HmKfz und ExmGrund, in
STG Stg, Abschl, BeuGrund und EndeGrd. Alle übrigen Attribute sind
Nichtschlüsselattribute.
4. Änderungen sind nicht erforderlich.
5. Die erste Heuristik findet keine Abhängigkeit, denn es gibt keine zwei Tabellen mit
demselben Primärschlüssel. Wären die Namen der Primärschlüsselattribute von
K_AKFZ und K_IKFZ gleich, so würde eine Abhängigkeit zwischen beiden
Relationen gefunden werden. Diese würde aber aufgrund der Überprüfung am Ende
von Schritt 5 wieder wegfallen. Die Fremdschlüssel geben die Abhängigkeiten A) bis
G) vor, die dritte Heuristik liefert H) bis J).
Alle Abhängigkeiten werden nun auf die beiden im Verfahren aufgeführten
Bedingungen hin überprüft:
Weil es Werte in K_AKFZ gibt, die nicht in K_IKFZ auftauchen, und umgekehrt,
das Attribut SOS.HmKfz aber sowohl Werte der einen als auch der anderen Tabelle
annimmt (je nach Eintrag in SOS.HmKfzKz, siehe Zusatzinformation III), werden
die Abhängigkeiten A) und B) verworfen. Der Anwender wird sie aber wieder
hinzufügen.
- 29 -
6. Starke Entity-Typen werden erzeugt:
MtkNr
SOS
K_IKFZ
K_AKFZ
K_GDEX
K_GDBU
K_ABINT
K_STG
IKfz
AKfz
GdEx
GdBu
Abschl
Stg
7. Erzeugung des schwachen Entities: Durch H) erweist sich Entity SOS als
Eigentümer.
MtkNr
SOS
Semester,StgNr
1
ABHÄNGIG
N
STG
K_IKFZ
K_AKFZ
K_GDEX
K_GDBU
K_ABINT
K_STG
IKfz
AKfz
GdEx
GdBu
Abschl
Stg
8. Da keine zwei Relationen denselben PS aufweisen, wird keine „is a“-Beziehung
erstellt. Wie bereits in 5. angesprochen wäre eine solche Beziehung zwischen
K_AKFZ und K_IKFZ erzeugt worden, wenn nicht die Inhalte beider Tabellen dem
widersprechen würden.
9. Hierarchien werden nicht erzeugt.
- 30 -
10. Fremdschlüssel-Beziehungen auswerten: Die Abhängigkeiten A) und B) beziehen
sich auf denselben Fremdschlüssel SOS.HmKfz. Der Nutzer muß also hier eine
Abhängigkeit auswählen, die ins Schema übernommen werden soll. Die Wahl fällt
dabei auf Abhängigkeit B). In Schritt 16. muß aber daran gedacht werden, daß auch
Abhängigkeit A) beachtet werden muß (siehe III).
MtkNr
Semester,StgNr
1
SOS
N
B
N
ABHÄNGIG
N
STG
N
C
HAT
G
HAT
1
HAT
F
N
E
HAT
1
N
N
D
HAT
1
HAT
1
1
K_IKFZ
K_AKFZ
K_GDEX
K_GDBU
K_ABINT
K_STG
IKfz
AKfz
GdEx
GdBu
Abschl
Stg
11. Beziehungen aufgrund von Nichtschlüssel-Abhängigkeiten werden nicht gebildet.
12. Übernahme von K_ABSTG mit den Abhängigkeiten I) und J) in das Schema:
MtkNr
Semester,StgNr
1
SOS
N
ABHÄNGIG
N
HAT
STG
N
HAT
1
N
1
HAT
1
N
N
N
HAT
HAT
HAT
1
1
1
K_IKFZ
K_AKFZ
K_GDEX
K_GDBU
IKfz
AKfz
GdEx
GdBu
K_ABINT
K_STG
Abschl
Stg
M
K_ABSTG
13. Spezielle Beziehungs-Relationen wurden nicht im Schema entdeckt.
N
- 31 -
14. Die einzige Beziehungs-Relation (K_ABSTG) des betrachteten Relationenschemas
enthält keine Fremdschlüssel.
15. Zunächst werden die Nichtschlüsselattribute der Relationen K_STG, K_ABINT,
K_AKFZ, K_IKFZ, K_GDEX und K_GDBU jeweils dem korrespondierenden
Entity zugeordnet, denn diese Tabellen enthalten keine Fremdschlüssel. Bei den
Tabellen SOS und STG hat man die Wahl, ob die Nichtschlüsselattribute den
Entities SOS bzw. STG oder einer ihrer binären ‘HAT’-Beziehungen zugeordnet
werden sollen. Hier wird der einfache Fall gewählt, so daß SOS die Attribute
Semester, Status, Name, Strasse, Ort, Staat, HmKfzKz, ImmDat, RueDat und
ExmDat zugeordnet werden, während STG das Attribut Status erhält. Die übrigen
Attribute beider Tabellen, die nicht zum PS gehören, sind Fremdschlüssel und dienen
ausschließlich der Identifikation von Beziehungen. Als letztes wird K_ABSTG
behandelt. Diese Tabelle hat aber keine Nichtschlüsselattribute.
16. Einige Verbesserungen sind noch an dem entstandenen EER-Schema durchzuführen:
So werden vor allem die Namen der Entities und Beziehungen in sprechendere
Bezeichnungen umgewandelt. Nicht zu vergessen ist auch die Modellierung der
Abhängigkeit A) (siehe 10.). Die Beziehung K_ABSTG mit den Entities K_ABINT
und K_STG können zu einem abstrakten Entity zusammengefaßt werden. Die
beiden ‘HAT’-Beziehungen fallen dann weg und werden durch eine neue Beziehung
ersetzt. Zusätzlich werden die Kardinalitäten aller Beziehungen definiert. Die
Nichtschlüssel aus 15. werden der Übersichtlichkeit halber nicht ins Schema
übernommen.
- 32 -
MtkNr
Semester,StgNr
(1,N)
(0,1)
Student
(0,1)
(0,N)
Fach
(1,N)
(0,1)
wohnt in
studiert
(0,1)
wohnt in
(0,N)
(0,1)
exmatrikuliert
exmatrikuliert
(0,N)
(0,N)
(0,1)
im
beurlaubt
(0,N)
(1,N)
Studiengang
ermöglicht
(1,N)
(1,N)
Stadt
(Inland)
Land
(Ausland)
Exmatr.grund
Beurlaub.grund
Abschluß
Stud.gang
IKfz
AKfz
GdEx
GdBu
Abschl
Stg
2.12 Welche Probleme treten bei Chiang auf ?
Bei Bearbeitung obigen Beispiels fallen schon einige Probleme auf, die der Algorithmus
mit sich bringt:
Eine Schwierigkeit, die bei jedem Verfahren auftritt, ist die Namensgebung der
EER-Objekte. Meist sind die Namen der Relationen nicht als Namen der erzeugten
Objekte zu gebrauchen, da oft im Relationenschema Abkürzungen angewendet werden.
Dieses Problem ist aber nicht durch einen Automatismus zu lösen, da kein Algorithmus
ermitteln kann, welche Art von Daten in welcher Relation gespeichert werden. Die
Namen, die Chiang verwendet, sind deshalb zwar nicht sehr aussagekräftig, stellen aber
doch eine dem Problem entsprechende Lösung dar. Hier ist der Anwender gefordert,
bessere Namen zu vergeben.
Unverständlich ist hingegen die Reihenfolge der Erstellung von Beziehungen.
Sicherlich wäre es besser, Beziehungen, die aus Fremdschlüsseln oder Nichtschlüsseln
resultieren (Schritte 10. und 11.), erst nach der Umsetzung von Beziehungs-Relationen
(Schritte 12. und 13.) zu erzeugen. Sonst kann es passieren, daß Fremdschlüssel, die in
Beziehungs-Relationen stehen, nicht beachtet werden.
- 33 -
In dieser Hinsicht ist auch die Voraussetzung für die zweite Heuristik in Schritt 5.
nicht zu begreifen, denn auch Beziehungs-Relationen können Fremdschlüssel enthalten.
Durch die Voraussetzung A∈ER werden sie aber nicht als solche erkannt. Gerade diese
Fremdschlüssel liefern aber für Schritt 14. die notwendigen Hinweise auf Aggregationen.
Um ein EER-Schema zu erhalten, das aussagekräftig ist und die Beziehungen
zwischen den anderen Objekten geeignet darstellt, ist die Kenntnis von Primär- und
Fremdschlüsseln unerläßlich. Hier liefert das Verfahren von Chiang leider keine
Unterstützung. Hingegen wird vom Anwender verlangt, daß er die Schlüssel
kennzeichnet. Dabei ist es nicht weiter schwierig, Heuristiken analog zu 5. zu finden, die
mögliche Schlüsselattribute suchen. Zum Beispiel geben „unique“-Indexe Aufschluß auf
mögliche Schlüsselkandidaten, während die Namensgebung von Attributen auf
Fremdschlüssel deuten können. Wenn ein Attribut einer Tabelle den gleichen Namen wie
der Primärschlüssel einer anderen Relation besitzt, so kann vermutet werden, daß es sich
hierbei um ein Fremdschlüsselattribut handelt. Diese Annahmen können anhand der
Datenbank-Inhalte überprüft und vom Nutzer korrigiert werden. Primärschlüssel sollten
wegen ihrer Wichtigkeit bei der Klassifikation der Relationen deklariert sein.
Weitere Verbesserungen im Bereich der Automatisierung des Algorithmus sind
denkbar, indem der Anwender nicht sofort zu einer Entscheidung im Zweifelsfalle
gezwungen wird, sondern der Algorithmus eine „vorläufige“ Entscheidung trifft und den
Nutzer erst in Schritt 16. auf derartige Fälle hinweist.
Eine weitere Möglichkeit, den Grad der Automatisierung zu erhöhen, liegt im 15.
Schritt bei der Zuweisung der Nichtschlüsselattribute zu den EER-Objekten. Es ist
rätselhaft, warum Chiang hier dem Anwender die Wahl läßt, die Attribute einer über
Fremdschlüssel spezifizierten binären Beziehung zuzuordnen, denn diese Möglichkeit ist
semantisch gleichwertig zu dem gebräuchlichen Vorgehen, die Attribute dem Entity bzw.
der Beziehung zuzuweisen. Im oben betrachteten Beispiel ist es unerheblich, ob das
Attribut Status dem (schwachen) Entity FACH oder der Beziehung STUDIERT
zugeordnet wird. Nimmt man dem Anwender diese Entscheidungsmöglichkeit bzw.
Entscheidungspflicht, so kann auf einfachste Art und Weise der Nutzer entlastet werden.
Die Annahmen, die das Verfahren macht, sind in der Regel sinnvoll und können so
übernommen werden. Problematisch ist die Überprüfung der vermuteten Abhängigkeiten
(Schritt 5) und die Ermittlung der Kardinalitätsverhältnisse (Schritte 10 und 11), denn
- 34 -
hierzu werden Daten-Instanzen verwendet. Dadurch wird die Erstellung des EERSchemas abhängig vom Datenbank-Zustand. Wenn nur wenige Daten gespeichert sind,
können falsche Kardinalitätsverhältnisse vermutet werden. Allerdings hat dieses
Vorgehen den Vorteil, daß der Anwender entlastet wird, denn viele Abhängigkeiten
werden auf diese Weise automatisch gefunden, die der Nutzer sonst selbständig eingeben
müßte.
Ebenso werden in Schritt 9 Daten-Instanzen verwendet. Unglücklicherweise findet
Chiangs Verfahren nicht alle Arten von Generalisierungs-Hierarchien. Nur totale
exklusive Generalisierungen werden erkannt, und die auch nur dann, wenn entsprechende
Daten gespeichert sind.
Die Voraussetzung, daß Attribute gleichen Namens gleiche Inhalte speichern, ist
leider unrealistisch. Schon das angegebene Beispiel zeigt, daß Attribute, die dieselben
Daten speichern, nicht den gleichen Namen haben müssen (z.B. STG.BeuGrund und
K_GDBU.GdBu). Noch schwerwiegender ist aber der Fehler in der anderen Richtung,
denn wenn zwei Entities STUDENT und PROFESSOR beide ein Attribut „Name“
enthalten, so werden in diesen beiden Attributen nicht unbedingt dieselben Daten
gespeichert.
Eine weitere Idee zur Verbesserung des Verfahrens ist, daß Integritätsbedingungen
bei der Transformation ebenfalls beachtet werden sollten. Der Nutzer sollte die
Möglichkeit bekommen, Integritätsbedingungen - wie in I) bis III) definiert - zusammen
mit dem Relationenschema anzugeben. Der Algorithmus muß diese dann bei der
Umsetzung beachten und ausnutzen. Außerdem kann auch die Auswertung der
Schlüsselkandidaten in vielen Fällen hilfreich sein, denn die Tabellen können bei
Verwendung eines anderen Primärschlüssels völlig anders klassifiziert werden. Als
Beispiel soll die oben genannte Tabelle STG betrachtet werden: Nimmt man hier die
Attribute MtkNr, Semester und Stg als Primärschlüssel, so wird das Attribut Stg als
Primärschlüsselattribut behandelt. Relation STG hat dann zwei Primärschlüsselattribute
(MtkNr und Stg) und kann somit nicht als schwache Entity-Relation, sondern nur als
spezielle Beziehungs-Relation klassifiziert werden. Das EER-Schema hätte dann
folgendes „ideale“ Aussehen:
- 35 -
MtkNr
SOS
Stg
STG
K_STG
Semester
Semester
2.13 Wie arbeiten die anderen Algorithmen ?
Im Unterschied zu Chiang verlangt der Algorithmus von Batini/Ceri/Navathe [3] neben
der Angabe von Primärschlüsseln auch die Nennung aller Fremdschlüssel und
Schlüsselkandidaten. Anhand der Primärschlüssel und deren Vergleich werden die
Relationen des eingegebenen Schemas in die Klassen „primary“, „weak primary“ und
„secondary relation“ unterteilt. Dabei ist die Klasse der „secondary“-Tabellen analog zu
den beiden Beziehungs-Relationen in Chiangs Algorithmus (s.o.). Alle Schlüssel werden
nach der Klassifikation miteinander verglichen, um über Namensgleichheit Beziehungen
zu finden. Auch dieses Vorgehen ist dem von Chiang sehr ähnlich, jedoch hat der Nutzer
keine vom Verfahren vorgesehene Eingriffsmöglichkeit. „Primary relations“ werden
anschließend in Entities, „secondary relations“ in Beziehungen umgesetzt. Wie bei
Chiang werden Tabellen der Kategorie „weak primary“ im EER-Modell als schwache
Entities mit zugehöriger „is a“-Beziehung dargestellt. Weitere Beziehungen werden aus
den Bedingungen zur referentiellen Integrität bei Fremdschlüsseln gefolgert.
Der Vorteil dieses Verfahrens gegenüber dem Algorithmus von Chiang ist, daß der
Anwender zu keinem Zeitpunkt vor einem Entscheidungszwang steht. Erkauft wird dies
aber damit, daß zu Beginn sämtliche Schlüssel und Schlüsselkandidaten angegeben
werden müssen. Gerade das Finden von Schlüsselkandidaten stellt einen Anwender vor
größere Probleme. Leider hat er später keine Möglichkeit, den ablaufenden Algorithmus
zu beeinflussen. Dafür versucht der Algorithmus anhand der Schlüsselkandidaten einen
Primärschlüssel zur bearbeiteten Relation zu finden, der mit dem Primärschlüssel einer
anderen Relation übereinstimmt, um so eventuell vorhandene Beziehungen zu finden.
- 36 -
Jedoch geht dieses Verfahren wieder von der oben kritisierten Annahme aus, daß
Namensgleichheit auf Inhaltsgleichheit schließen läßt.
Die Verfahren von Johannesson/Kalman [10] und Markowitz/Makowsky [13] sind
völlig analog zu dem von Batini/Ceri/Navathe [3]. Einziger Unterschied zwischen diesen
Algorithmen ist, daß in [10,13] zusätzlich zu den Schlüsseln und Schlüsselkandidaten
auch alle Abhängigkeiten eingegeben werden müssen, ohne daß das Verfahren wie bei
Chiang Heuristiken liefert, die derartige Abhängigkeiten vermuten können. Anhand
dieser Inklusionen werden (wie bei Chiang) weitere Beziehungen gebildet, Klassifikation
und Umsetzung der Tabellen verlaufen aber genauso wie in [3]. Vor- und Nachteile
entsprechen ebenfalls denen des Verfahrens aus [3].
Input des Verfahrens von Navathe/Awong [16] sind neben dem Relationenschema
auch die Angabe von Primär- und Fremdschlüsseln sowie die Definition der
Abhängigkeiten zwischen den Tabellen. Die Klassifikation der Tabellen und Attribute ist
mit der bei Chiang [4,5] identisch. Bei Erzeugung des EER-Diagramms werden zuerst
die Relationen umgesetzt, bevor anhand der eingegebenen Fremdschlüssel und
Abhängigkeiten weitere Beziehungen in das Schema eingefügt werden. Gibt es bei der
Umsetzung der Fremdschlüssel mehrere Relationen, deren Primärschlüssel zu dem
Fremdschlüssel der betrachteten Tabelle paßt, so muß der Anwender eine auswählen.
Außerdem hat er Einfluß auf die Bildung von Spezialisierungen/Generalisierungen, indem
er die entstandenen Entities gruppieren und einordnen kann.
Der Algorithmus aus [16] entspricht nahezu vollständig dem aus [4,5]. Auch hier
werden vom Anwender sehr viele Eingaben verlangt. Jedoch können Navathe/Awong
nicht ganz soviele Informationen ermitteln und verarbeiten wie der Algorithmus von
Chiang. Es fehlen zum Beispiel Heuristiken, die dem Anwender die Eingabe von
Abhängigkeiten erleichtert. Während Aggregationen überhaupt nicht erkannt werden,
müssen Spezialisierungen/Generalisierungen vom Nutzer angegeben werden.
Auch im Verfahren von Davis/Arora [7] werden Relationen und Attribute in
dieselben Klassen eingeteilt wie bei Chiang [4,5]. Jedoch verwenden Davis/Arora als
Zielmodell ein „einfaches“ ER-Modell mit Entities und Beziehungen. Aggregationen oder
Spezialisierungen/Generalisierungen entstehen in diesem Algorithmus nicht.
- 37 -
Ein Problem, das allen hier besprochenen Verfahren angelastet werden kann, ist, daß
die entstehenden ER-Schemata sehr eng an das ursprüngliche Relationenschema
gebunden sind und somit meist nur die physikalisch vorhandene Datenbank
repräsentieren. Gewünscht wird hingegen ein leicht verständliches Schema, das
unabhängig von der Implementation ist. Vor allem auf den Algorithmus aus [7] trifft
dieses Kriterium zu. Hier werden Entities und Beziehungen rein aufgrund des
eingegebenen relationalen Schemas erzeugt, so daß ein ER-Diagramm entsteht, das nur
die physikalische Implementation der Datenbank grafisch darstellt und somit nicht den
Erwartungen des Anwenders entspricht. Für ein Relationenschema wie
Person
(Name, Straße, Ort)
Mitarbeiter
(Mitarbeiternr, Gehalt, Name)
Kunde
(Kundennr, Name),
bei dem ein Schema der Form
Name, Straße, Ort
Mitarbeiternr, Gehalt
Person
Mitarbeiter
Kunde
Kundennr
gewünscht wird, entsteht im Gegensatz dazu das Schema
Name, Straße, Ort
Mitarbeiternr, Gehalt
Person
ist
ist
Mitarbeiter
Kunde
Kundennr
Die Information, daß es sich hierbei um eine partielle überlappende Generalisierung
(Mitarbeiter können auch Kunden sein!) handelt, geht verloren.
Der Algorithmus von Shoval/Shreiber [19], der ein „Binary Relationship Model“
erstellt, verlangt als Eingabedaten das Relationenschema und die Primärschlüssel.
Wahlweise können auch Fremdschlüssel, Schlüsselkandidaten und Abhängigkeiten
angegeben werden. Das spätere Schema wird dann umso besser und gehaltvoller, je mehr
Informationen
der
Anwender
eingeben
kann.
Damit
alle
wichtigen
- 38 -
Integritätsbedingungen der Datenbank im Schema veranschaulicht werden, ist besonders
die Eingabe von Abhängigkeiten und Fremdschlüsseln zwingend. Alle Nutzereingaben
werden durch Datenbank-Anfragen überprüft und eventuell wieder verworfen. Die
Relationen werden nach Anzahl und Art der Attribute im Primärschlüssel klassifiziert und
umgesetzt. Diese Klassifikation ist allerdings sehr schwer verständlich und kaum
nachvollziehbar. Die Bildung zusätzlicher Beziehungen ergibt sich aus den angegebenen
Abhängigkeiten. Sämtliche Nutzerkommunikation wickelt das Verfahren aus [19] vor
Beginn der Umsetzung ab. Der Vorteil daran ist, daß der Algorithmus automatisch
abläuft, obwohl der Anwender großen Einfluß nehmen kann.
Wenguang/Carlson/Dreyer [23] verlangen in ihrem Verfahren neben dem
Relationenschema auch die Eingabe sämtlicher Inklusionen. Der Algorithmus soll dann
rekursiv die verschiedenen Ebenen eines sogenannten „Nested ER-Models“ erzeugen.
Jedoch ist das Verfahren zu kurz beschrieben. Das ungewöhnliche Zielmodell läßt sich
zwar gut in grafischer Form ausgeben, ist aber nicht so leicht zu lesen wie ein EERSchema, weil nicht alle Informationen in einer Stufe sichtbar sind.
Einen ganz anderen Weg als die bisher beschriebenen Verfahren geht der
Algorithmus aus [17] von Petit/Kouloumdjian/Boulicaut/Toumani: Hier werden
Anfragen dazu benutzt, die Eigenschaften einer relationalen Datenbank zu ermitteln.
Erwartet wird als Input das Relationenschema und alle „unique“- und „not null“Eigenschaften
der
Attribute.
Diese
werden
als
Kennzeichen
für
mögliche
Schlüsselattribute verwendet. Über Anfragen werden dann die Tabellen untersucht und in
die verschiedenen Elemente eines EER-Modells umgesetzt. Dazu wird eine SQL-Anfrage
vom System erzeugt, in der zwei Relationen über einen „Join“ miteinander verbunden
werden. Der Anwender muß entscheiden, ob diese Anfrage sinnvoll ist oder nicht, indem
er das Ergebnis der Anfrage angezeigt bekommt. Der Join einer „sinnvollen“ Anfrage
wird dann vom Verfahren genauer untersucht: Besteht der Join aus allen Attributen der
Primärschlüssel der ersten wie auch der zweiten Tabelle, so wird eine Beziehung
angenommen. Die genaue Art der Beziehung wird über weitere Anfragen ermittelt, die
der Algorithmus bildet. Sie zählen die Anzahl der Datensätze in den einzelnen Tabellen
bzw. die Datensätze, die in beiden Tabellen vorhanden sind. Wenn z.B. kein einziger
Datensatz in beiden Relationen zu finden ist, so sind die Tabellen voneinander
unabhängig. Sind hingegen nicht alle Attribute des Primärschlüssels einer Relation an
- 39 -
dem Join beteiligt, so wird angenommen, daß es sich hierbei um ein schwaches Entity
handelt.
Der Algorithmus, der in [17] verwendet wird, enthält einige interessante Ideen.
Jedoch hat er den schwerwiegenden Nachteil, daß er vom jeweiligen Datenbank-Zustand
abhängig ist. Außerdem wird aus dem veröffentlichten Artikel nicht klar, wie die
Anfragen vom System erstellt werden und auf welche Weise das Verfahren „sinnvolle“
Joins findet.
Dieselben Probleme bereitet auch das Verfahren von Andersson [2]. Andersson
benutzt Programme, die Daten der Relationen manipulieren oder Daten selektieren. Als
Eingabe wird der Quellcode von Programmen erwartet, die mit der Datenbank arbeiten.
Aus diesen schneidet der Algorithmus die SQL-Anweisungen heraus und ermittelt die
Eigenschaften der Tabellen mit diesen Anweisungen. Das Verfahren ist an dieser Stelle
mit dem in [17] veröffentlichten vergleichbar, weshalb auch die gleichen Probleme
auftauchen.
Die besonderen Eigenschaften der Verfahren sollen in folgender Tabelle noch einmal
der Übersicht halber dargestellt werden:
(Soweit nichts anderes angegeben wird, ist die Ausgabe ein Schema in oben
erläutertem EER-Modell)
- 40 -
Verfahren
Chiang [4,5]
Input
Schema in 3.NF
Primärschlüssel
Datensätze in DB
empfohlen: Fremdschl.
Batini [3]
Schema in 3. NF
Primärschlüssel
Fremdschlüssel
Schlüsselkandidaten
Johannesson [10], Schema in 3. NF
Markowitz [13]
Primärschlüssel
Fremdschlüssel
Schlüsselkandidaten
Abhängigkeiten
Navathe [16]
Schema in 3. NF
Primärschlüssel
Fremdschlüssel
Abhängigkeiten
Davis [7]
Shoval [19]
Wenguang [23]
Petit [17]
Andersson [2]
Umsetzung
Besonderheiten
Klassifikation der
Relationen in vier
Klassen
Viel Kommunikation
mit dem Anwender
Heuristiken zum Finden
von Abhängigkeiten
Keine Einflußnahme
durch den Anwender
möglich
Klassifikation in
drei Klassen
wie in [3]
Klassifikation in
vier Klassen, wie
in [4,5]
wie in [3], aber
Abhängigkeiten geben
weitere Beziehungen
vor
Keine automatische
Bildung von
Spezialisierungen oder
Aggregationen, müssen
von Anwender
eingegeben werden
Schema in 3. NF
Klassifikation in
Ziel ist ER-Schema
Primärschlüssel
vier Klassen, wie ohne Erweiterungen
Abhängigkeiten
in [4,5]
(wie z.B.
Aggregationen)
Schema in 3. NF
Klassifikation der Ziel ist „Binary
Primärschlüssel
Relationen anhand Relationship Model“
empfohlen: Fremdschl. ihrer Primärschl.
Überprüfung aller
Abhängigkeiten
Nutzereingaben durch
optional:
DB-Anfragen
Schlüsselkandidaten
Nutzerkommunikation
vor Beginn des
Algorithmus
Schema in 3. NF
Rekursive
Ziel ist „Nested ERPrimärschlüssel
Erzeugung der
Model“
Abhängigkeiten
Ebenen des
Zielmodells
Schema in 3. NF
Joins „sinnvoller“ Völlig andere
„unique“Anfragen werden Vorgehensweise bei der
Eigenschaften
untersucht
Umsetzung
„not null“-Eigensch.
Abhängigkeit vom DBZustand
Quellcode von
Untersuchung der wie in [17]
Programmen, die mit Anfragen wie bei
DB arbeiten
Petit [17]
- 41 -
3 Lösungsansatz
Im vorherigen Kapitel wurde gezeigt, auf welche Weise in bereits veröffentlichten
Verfahren das Problem des „Reverse Engineering“ gelöst wird. Der Vergleich basierte
dabei hauptsächlich auf dem Verfahren von Chiang [4,5], welches sich als das bisher
beste herauskristallisierte. Aus diesem Grund soll auch in diesem Kapitel dieser
Algorithmus, der in Kapitel 2 ausführlich dargestellt wurde, die Grundlage bilden. Wie
bereits gezeigt wurde, läßt sich Chiangs Verfahren an einigen Stellen verbessern. Bei der
Erstellung eines eigenen Verfahrens sollen möglichst viele Probleme behoben und vor
allem die Arbeit des Anwenders weiter erleichtert werden.
Eine Möglichkeit, den Nutzer zu entlasten, ist dabei, Heuristiken anzugeben, die
mögliche Schlüsselattribute suchen. Viele Datenbanksysteme (wie z.B. Informix) haben
keine Möglichkeit, in der relationalen Datenbank Schlüssel zu vergeben. Hingegen
verwenden sie Indexe, die „unique“- und „not null“-Bedingungen enthalten können. Mit
Hilfe dieser Informationen, die wie das Schema ohne weiteres aus dem Datenbanksystem
auszulesen sind, lassen sich Vermutungen über mögliche Schlüssel formulieren. Der
Anwender kann dann diese Vermutungen bestätigen oder verwerfen. Über DatenbankAnfragen können derartige Vermutungen genauso wie auch Vermutungen über
Abhängigkeiten überprüft werden. Es ist jedoch zu beachten, daß diese Prüfung immer
abhängig vom jeweiligen Datenbank-Zustand ist.
Weiterhin würde die Beachtung von Integritätsbedingungen das EER-Schema
erheblich aussagekräftiger gestalten. Allerdings müßten diese, sofern sie nicht (wie in
Oracle) in der relationalen Datenbank definiert werden, vom Anwender eingegeben
werden, denn über Heuristiken sind viele Integritätsbedingungen nicht zu finden.
Schwierig ist auch die Beachtung von Schlüsselkandidaten. Das angestrebte
Verfahren muß hier Kriterien finden, nach denen es einen geeigneten Primärschlüssel aus
den Schlüsselkandidaten auswählt.
- 42 -
3.1 Ermitteln von Primär- und Fremdschlüsseln
Auch in der eigenentwickelten Strategie zum „Reverse Engineering“ soll vorausgesetzt
werden, daß die relationale Datenbank in der dritten Normalform vorliegt. Mit dieser
Voraussetzung wird man davor bewahrt, daß innerhalb einer Relation noch funktionale
Abhängigkeiten beachtet werden müssen, die durch die Definition eines Primärschlüssels
oder Schlüsselkandidaten nicht abgedeckt werden.
Werden Schlüssel-Definitionen im Datenbank-System gespeichert, so ist es möglich,
diese Definitionen einfach aus der Datenbank auszulesen. Sonst muß der Anwender die
Schlüssel jeder Tabelle bestimmen. Der Algorithmus soll aber den Anwender durch
Heuristiken unterstützen:
Primärschlüssel zu finden ist kein einfaches Unterfangen. Werden in der Datenbank
Indexe angelegt, so kann die Definition eines „unique“-Indexes darauf hinweisen, daß die
Attribute dieses Indexes ein Schlüsselkandidat für die Relation ist. Um weitere
Schlüsselkandidaten zu vermuten, können Anfragen gestellt werden. Ist jeder Wert der
Ergebnismenge dabei nur genau einmal vorhanden („unique“), so hat man eventuell einen
Schlüsselkandidaten gefunden. Die Suche nach diesem Prinzip läuft also auf den
Vergleich der Ergebnismengen folgender Anfragen hinaus:
A:={SELECT <Attribut> FROM <Tabelle>}
B:={SELECT DISTINCT <Attribut> FROM <Tabelle>}
WENN (A=B), DANN vermute <Attribut> als Schlüsselkandidaten
Mit einer Anfrage kann man formulieren:
SELECT COUNT(*) INTO z FROM <Tabelle> GROUP BY <Attribut>
HAVING COUNT(*)>1
WENN (z<2), DANN vermute <Attribut> als Schlüsselkandidaten
Problematisch ist dabei, daß <Attribut> auch die Kombination mehrerer Attribute der
Tabelle sein kann. Bei Tabellen mit vielen Attributen bekommt man derart viele
Kombinations-Möglichkeiten, daß der Sinn einer Überprüfung nach obigem Verfahren
eher zweifelhaft erscheinen muß. Jedoch liefert die Definition von Indexen nicht
hinreichend Hinweise auf mögliche Primärschlüssel. Wenn der Anwender die
Primärschlüssel
nicht
kennt,
so
ist
also
dieser
Weg
zur
Ermittlung
der
Schlüsselkandidaten der einzig mögliche. Abhilfe bietet hier nur der Weg, den Anwender
- 43 -
bestimmen zu lassen, welche Attribut-Kombinationen getestet werden sollen. Man muß
allerdings - wie bereits oben bemerkt - beachten, daß das Verfahren auf Anfragen
zurückgreift, deren Ergebnismenge vom Zustand der Datenbank abhängig ist.
Etwas einfacher ist das Finden von Fremdschlüsseln. Hier liefert die Namensgebung
Hinweise auf mögliche Zusammenhänge. Hat ein Attribut bzw. eine Menge von
Attributen gleiche Namen wie der bzw. die Attribute des Primärschlüssels oder eines
Schlüsselkandidaten einer anderen Tabelle, so kann zwischen den Attributen eine
Beziehung vermutet werden. Über Anfragen können die Inhalte auf Unterschiede geprüft
werden. Werden Unterschiede gefunden, so kann es sich um keine FremdschlüsselBeziehung handeln.
A:={SELECT DISTINCT <Primärschlüssel P> FROM <Tabelle1>}
B:={SELECT DISTINCT <Fremdschlüssel F> FROM <Tabelle2>}
WENN (B⊄A), DANN verwerfe Fremdschlüssel-Vermutung
SONST merke Abhängigkeit <Tabelle1.F>→<Tabelle2.P>
Wiederum läßt sich dies auch in einer Anfrage formulieren:
SELECT COUNT(*) INTO z FROM <Tabelle1>
WHERE NOT EXISTS (
SELECT <Primärschlüssel P> FROM <Tabelle2>
WHERE <Tab2>.<Primärschl. P>=<Tab1>.<Fremdschl. F>
)
WENN (z>0), DANN verwerfe Fremdschlüssel-Vermutung
SONST merke Abhängigkeit <Tabelle1.F→Tabelle2.P>
Diese Überprüfung eines Fremdschlüsselverdachtes ist allerdings vom DatenbankZustand abhängig. Deshalb sind Fremdschlüssel-Vermutungen, die diesem Test
standhalten, keineswegs zwangsläufig zutreffend. Vielmehr muß der Anwender den
Verdacht prüfen.
Zu beachten ist, daß auch Attribute, die zu einem Schlüsselkandidaten oder dem
Primärschlüssel einer Tabelle gehören, gleichzeitig zu einem Fremdschlüssel gehören
können.
Eine weitere Idee, mögliche Primärschlüssel oder Fremdschlüssel zu finden, kann
man aus dem Verfahren von Petit [17] adaptieren: Wenn dem Nutzer einige Anfragen
aus Programmen, die mit der relationalen Datenbank arbeiten, bekannt sind, so können
anhand der Selektionsbedingungen Primärschlüssel und Fremdschlüssel vermutet werden.
- 44 -
Sei also beispielsweise die folgende Anfrage vorgegeben:
SELECT <beliebige Attribute> FROM A,B
WHERE A.a1=B.b1 AND A.a2=B.b2
A und B sind dabei selbstverständlich Tabellen, a1,a2,b1,b2 beliebige Attribute in
Relation A bzw. B. Aus dieser Anfrage kann nun gefolgert werden, daß zwischen den
Tabellen A und B eine Beziehung besteht. Wenn durch weitere Anfragen (wie oben)
herausgefunden wird, daß die Ergebnisse von (a1∪a2) bzw. von (b1∪b2) eindeutig sind,
so wird angenommen, daß a1 und a2 bzw. b1 und b2 den Primärschlüssel der Relation A
bzw. B bilden und die jeweils anderen beiden Attribute Fremdschlüssel sind.
Alle derartigen Vermutungen müssen durch den Anwender überprüft und
gegebenenfalls korrigiert werden. Nur der Anwender hat die Möglichkeit, einen
Schlüssel-Verdacht zu prüfen, weil kein Verfahren anhand von Anfragen mit Sicherheit
herausfinden kann, daß bestimmte Attribute einer Relation einen Schlüsselkandidaten
bilden. Durch Ausgabe der Ergebnismengen kann das Verfahren dem Nutzer aber die
Entscheidung
erleichtern.
Außerdem
obliegt
es
dem
Benutzer,
aus
allen
Schlüsselkandidaten einen Primärschlüssel auszuwählen. Dies ist für die Klassifikation
der Relationen wichtig. Die weiteren Schlüsselkandidaten sollten jedoch dabei keinesfalls
in Vergessenheit geraten, um dem Anwender bei der Klassifikation anzuzeigen, welche
Konsequenzen die Wahl eines anderen Primärschlüssels auf das Ergebnis des Verfahrens
hätte.
Wenn hingegen auch die Wahl des Primärschlüssels aus einer Reihe von
Schlüsselkandidaten durch das Verfahren vorgenommen werden soll, so sind folgende
Kriterien (in der Reihenfolge ihrer Wichtigkeit) zu beachten:
1. Schlüsselkandidat erscheint auf der rechten Seite einer Abhängigkeit.
2. Schlüsselkandidat besteht zum Teil aus Fremdschlüsselattributen.
3. Schlüsselkandidat besteht aus wenigen Attributen.
Je besser bzw. häufiger diese Kriterien auf einen Schlüsselkandidaten zutreffen, desto
eher handelt es sich dabei um den Primärschlüssel der Relation.
Unabhängig davon, ob Fremdschlüssel vom Verfahren oder vom Anwender
angegeben werden, müssen die entsprechenden Abhängigkeiten definiert werden. Dies
bedeutet, daß der Nutzer, wenn er die Fremdschlüssel der Tabellen selbst definiert, auch
die Relation angeben muß, auf die der Fremdschlüssel verweist.
- 45 -
Alle weiteren Integritätsbedingungen, die in der relationalen Datenbank gelten,
können nicht aus dem Relationenschema abgeleitet werden. Sie werden im DatenbankBetrieb entweder durch Programme, oder bestenfalls durch die Definition sogenannter
„Trigger“ sichergestellt. Leider ist aber nicht bei allen Datenbank-Management-Systemen
die
Möglichkeit
gegeben,
Trigger
zur
Einhaltung
von
zusätzlichen
Integritätsbedingungen zu verwenden.
Wenn Trigger in einer relationalen Datenbank definiert wurden, so lassen sich diese
einfach aus den Systemtabellen der Datenbank auslesen und so weiterverwenden. Ihre
Auswertung soll allerdings nicht Gegenstand dieser Arbeit werden. Anderenfalls gibt es
leider
keine
andere
Möglichkeit,
als
den
Anwender
aufzufordern,
die
Integritätsbedingungen einzugeben.
3.2 Klassifikation der Relationen und Attribute
Nach den vorhergehenden Überlegungen soll nun in den folgenden Abschnitten davon
ausgegangen werden, daß sowohl Primär- als auch Fremdschlüssel der Relationen
bekannt sind.
Die Definition der Primärschlüssel jeder Relation im vorhergehenden Schritt bildet
die Grundlage für die Klassifikation. Dabei ist zu beachten, daß die Auswahl des
Primärschlüssels aus einer Reihe von Schlüsselkandidaten die Klassifikation und damit
auch das folgende Verfahren erheblich beeinflussen kann, denn je nach Wahl wird aus der
Relation beispielsweise entweder ein Entity oder eine Beziehung erzeugt. Das
Programm,
deren
Entwicklung
in
Kapitel
3.2
ansteht,
sollte
anhand
der
Schlüsselkandidaten auf die unterschiedlichen Klassifikations-Möglichkeiten hinweisen.
Teile des Primärschlüssels einer Relation können gleichzeitig als Fremdschlüssel
fungieren. Dieses ist ein wichtiges Kriterium bei der Klassifikation:
Besteht der Primärschlüssel P der Relation A ausschließlich aus Attributen, die nicht
Bestandteil eines beliebigen Fremdschlüssels von A sind, so repräsentiert A ein starkes
Entity. In Anlehnung an Chiangs Algorithmus wird A dann „starke Entity-Relation“
(SER) genannt.
- 46 -
Zum Beispiel sind „Student“ und „Professor“ starke Entity-Relationen:
Student
(Matrikelnr, Name, Straße, Ort)
Professor
(Name, Gehalt, Fachbereich)
Student
Professor
Ebenso einfach ist die Klassifikation, wenn der Primärschlüssel von A ausschließlich aus
Fremdschlüsseln zusammengesetzt ist. In diesem Fall ist es naheliegend, daß A eine
Beziehung repräsentiert. Relation A wird dann als „reguläre Beziehungs-Relation“
(RBR) bezeichnet.
Die Relation „Betreuung“ ist zum Beispiel eine solche RBR, denn der
Primärschlüssel besteht ausschließlich aus Fremdschlüsseln, die auf die oben genannten
Tabellen „Student“ und „Professor“ verweisen.
Betreuung
(Matrikelnr→Student, ProfName→Professor, Beginn, Ende)
Betreuung
Ein Sonderfall muß an dieser Stelle berücksichtigt werden: Es gibt Relationen, deren
Primärschlüssel aus nur einem Fremdschlüssel zusammengesetzt ist. Dies ist in
Generalisierungen der Fall sowie in binären Beziehungen, bei denen nur Kardinalitäten
(1,1) auftreten. Die gespeicherten Abhängigkeiten können dann weitere Hinweise auf die
geeignete Umsetzung geben. Hier sollen derartige Relationen lediglich als „besondere
Entity-Relationen“ (BER) klassifiziert werden.
Tabelle „Manager“ ist eine BER. Der Primärschlüssel „Mitarbeiternr“ von
„Manager“ ist gleichzeitig sein einziger Fremdschlüssel. Er verweist auf Relation
„Mitarbeiter“ mit dem gleichen Primärschlüssel „Mitarbeiternr“. Würde auch
„Mitarbeiternr“ in „Manager“ als Fremdschlüssel klassifiziert werden, so würde eine
binäre Beziehung zwischen „Mitarbeiter“ und „Manager“ vorliegen. In diesem Fall
handelt es sich hingegen um eine Spezialisierung:
- 47 -
Mitarbeiter
(Mitarbeiternr, Name, Gehalt)
Manager
(Mitarbeiternr→Mitarbeiter, Arbeitsbereich)
Mitarbeiter
Manager
Schwieriger wird es, eine geeignete Klassifikation für Tabellen zu finden, deren
Primärschlüssel nur zum Teil aus Fremdschlüsseln besteht. Ohne Nutzerkommunikation
ist es dann nicht möglich zu unterscheiden, ob eine Relation A eine Beziehung oder ein
schwaches Entity repräsentiert. Da in EER-Schemata schwache Entities mit mehreren
Eigentümern aber eher selten anzutreffen sind, gehen wir in der Regel davon aus, daß A
als eine Beziehung dargestellt werden soll, wenn sein Primärschlüssel mehrere
Fremdschlüssel enthält. Das Verfahren unterscheidet also analog zu Chiangs Algorithmus
wie folgt:
Wenn der Primärschlüssel von A genau einen Fremdschlüssel enthält, so klassifiziere
A als „schwache (weak) Entity-Relation“ (WER).
Zum Beispiel ist „Projekt“ (siehe Kapitel 2) eine WER, denn „Abteilnr“ ist ein
Fremdschlüssel und verweist auf Tabelle „Abteilung“. „Abteilung“ ist also der
Eigentümer von „Projekt“.
Projekt
(Abteilnr→Abteilung, Projektnr, Projname)
Projekt
Wenn der Primärschlüssel von A mehrere Fremdschlüssel enthält, so klassifiziere A als
„spezielle Beziehungs-Relation“ (SBR). Die Attribute des Primärschlüssels von A, die
nicht zu einem Fremdschlüssel gehören, bilden dann den Primärschlüssel eines neuen
Entities, das Teilnehmer an der repräsentierten Beziehung ist.
Enthält zum Beispiel der Primärschlüssel von Tabelle „Projekt“ zusätzlich ein
Attribut „Standort“, das auf eine weitere Relation „Ort“ verweist, so wird „Projekt“ als
SBR klassifiziert.
Projekt
(Abteilnr→Abteilung, Standort→Ort, Projektnr, Projname)
betreut
Projekt
- 48 -
Bei dieser Art der Klassifikation sollte aber keinesfalls vergessen werden, daß auch
Tabellen als schwache Entity-Relationen klassifiziert werden, die sinnvoller als spezielle
Beziehungs-Relationen behandelt werden sollten, und umgekehrt. Die Entscheidung,
welche Klassifikation die bessere ist, muß aber letztlich beim Anwender bleiben.
Weiterhin ist gerade hier die Wahl des Primärschlüssels aus einer Reihe von
Schlüsselkandidaten von entscheidender Bedeutung, denn oft ist es möglich, ein Attribut
des Primärschlüssels durch ein anderes auszutauschen, das dann unter Umständen ein
Fremdschlüssel der Tabelle ist. Bestes Beispiel hierfür ist die Umsetzung der Tabelle
„STG“ aus Kapitel 2.
Die Klassifikation der Attribute ist im Gegensatz zur Tabellen-Klassifikation
eindeutig. Hier sollen aber die Klassen, in die die Attribute eingeordnet werden, etwas
anders definiert werden als bei Chiang. So soll zum Beispiel die Definition von
„Primärschlüsselattributen“ analog zur allgemein gebräuchlichen Art erfolgen:
Sei also a ein Attribut aus Relation A mit Primärschlüssel P. Alle Attribute a∈P
werden „Primärschlüsselattribute“ genannt. Alle Attribute, die zu einem Fremdschlüssel
gehören, bezeichnet man als „Fremdschlüsselattribute“. Diese Klassen sind nicht
exklusiv, das heißt es gibt Attribute, die sowohl Primär- als auch Fremdschlüsselattribute
sind. Zum Beispiel sind bei regulären Beziehungs-Relationen alle Primärschlüsselattribute
gleichzeitig Fremdschlüsselattribute.
Die Primärschlüsselattribute einer schwachen Entity-Relation, die nicht zu einem
Primärschlüssel eines Eigentümers gehören, werden als „hängende Schlüsselattribute“
bezeichnet. Ein „allgemeines Schlüsselattribut“ ist Bestandteil des Primärschlüssels einer
speziellen Beziehungs-Relation, gehört aber zu keinem Primärschlüssel einer weiteren
Tabelle. Alle anderen Attribute werden als „Nichtschlüsselattribute“ bezeichnet.
Bei Betrachtung obiger Tabellen werden folgende Klassifikationen vorgenommen:
Student
(Matrikelnr, Name, Straße, Ort)
„Matrikelnr“ ist Primärschlüsselattribut, „Name“, „Straße“ und „Ort“ sind
Nichtschlüsselattribute.
- 49 -
Professor
„Name“
ist
(Name, Gehalt, Fachbereich)
Primärschlüsselattribut,
„Gehalt“
und
„Fachbereich“
sind
Nichtschlüsselattribute.
Betreuung
„Matrikelnr“
(Matrikelnr→Student, ProfName→Professor, Beginn, Ende)
und
„ProfName“
sind
gleichzeitig
Primärschlüssel-
und
Fremdschlüsselattribute, „Beginn“ und „Ende“ sind Nichtschlüsselattribute.
Projekt1
(Abteilnr→Abteilung, Projektnr, Projname)
„Abteilnr“ ist Primär- und Fremdschlüsselattribut, „Projektnr“ ist ein hängendes
Schlüsselattribut. „Projname“ ist ein Nichtschlüsselattribut.
Projekt2
(Abteilnr→Abteilung, Standort→Ort, Projektnr, Projname)
Wie eben ist „Abteilnr“ gleichzeitig Primär- und Fremdschlüsselattribut. Ebenso
wird „Standort“ klassifiziert. „Projektnr“ ist ein allgemeines Schlüsselattribut,
„Projname“ ein Nichtschlüsselattribut.
Auch auf diese Klassifikation hat die Auswahl des Primärschlüssels aus einer Menge
von Schlüsselkandidaten erheblichen Einfluß, der nicht vernachlässigt werden darf.
3.3 Erzeugung eines (E)ER-Schemas
Im Folgenden soll I die Menge aller Inklusionen sein, die in Kapitel 3.1.1 gefunden bzw.
durch den Anwender eingegeben wurden. Es ist einfacher, für die Erstellung von
Beziehungen nicht die Namensgleichheit von Attributen im Relationenschema als
Kriterium heranzuziehen, denn namensgleiche Attribute verschiedener Tabellen wurden
schon in 3.1.1 auf Abhängigkeiten hin geprüft. Stattdessen sollte die Menge der
Abhängigkeiten untersucht werden.
Weiterhin sei ER:=SER∪WER∪BER die Menge aller Entity-Relationen, die Menge
aller Beziehungs-Relationen sei BR:=RBR∪SBR.
- 50 -
3.3.1 Starke Entity-Relationen
Die Objekte, die am leichtesten zu identifizieren sind, sind die starken Entities. Diese
werden einfach aus den starken Entity-Relationen erzeugt, wobei die Primärschlüssel der
Tabellen auch Primärschlüssel in den Entities werden. Alle Nichtschlüsselattribute der
Relationen werden den jeweiligen Entities zugeordnet. Fremdschlüsselattribute dienen
der Identifikation von Beziehungen und werden nicht in das EER-Schema aufgenommen.
Sei
Alg1)
A∈SER
mit
Primärschlüssel
P,
N
sei
die
Menge
der
Nichtschlüsselattribute von A. Dann erzeuge ein starkes Entity namens A mit
Primärschlüssel P und weise alle Attribute von N dem neuen Entity zu.
Beispiel:
Für die Tabelle
Student
(Matrikelnr, Name, Straße, PLZ→Ort)
wird das folgende Entity erzeugt:
Name
Matrikelnr
Student
Straße
Das Attribut „PLZ“ ist ein Fremdschlüssel, der auf eine andere Tabelle „Ort“ verweist.
Aus diesem Grund wird „PLZ“ bereits bei der Verarbeitung der Relation „Ort“ gemerkt
und muß hier nicht beachtet werden.
Ein weiteres Beispiel ist die Relation
Abteilung
(Abteilnr)
Sie wird in folgendes Schema umgesetzt:
Abteilnr
Abteilung
- 51 -
3.3.2 Besondere Entity-Relationen
Bei den besonderen Entity-Relationen (BER) wird zunächst die Tatsache
vernachlässigt, daß ihr Primärschlüssel gleichzeitig als Fremdschlüssel klassifiziert wurde.
Alle Relationen dieser Klasse werden wie starke Entity-Relationen behandelt: Aus ihnen
werden starke Entities erzeugt.
3.3.3 Schwache Entity-Relationen
Nachdem alle starken und besonderen Entity-Relationen umgesetzt worden sind,
werden die schwachen Entity-Relationen ausgewertet. Für jede Tabelle, die dieser Klasse
angehört, wird ein schwaches Entity erzeugt, dessen Primärschlüssel aus den hängenden
Schlüsselattributen der Relation besteht. Der bzw. die Eigentümer werden aufgrund der
Abhängigkeiten in der Menge I wie folgt bestimmt:
Alg2)
Sei A∈WER mit Primärschlüssel P, H⊂P sei die Menge aller
hängenden
Schlüsselattribute
von
A,
M
die
Menge
der
sonstigen
Primärschlüsselattribute M=P\H, N die Menge der Nichtschlüsselattribute von A. Dann
erzeuge ein schwaches Entity namens A mit Primärschlüssel H und weise alle
Attribute von N dem neuen Entity zu.
Durchsuche dann die Menge der Inklusionen I nach Vorkommen von M auf der
linken Seite von Abhängigkeiten: Wenn (A.M→X.P)∈I mit beliebiger Tabelle X∈ER mit
Primärschlüssel P, dann ist X ein Eigentümer von A. Erstelle dann binäre Beziehung
‘ABHÄNGIG’
1
zwischen Entity A und dem Entity, das mit der Relation X
korrespondiert, also den Namen X hat.
Beispiel:
„Projekt“ ist eine WER (siehe oben). Es wird also ein schwaches Entity „Projekt“
erstellt, dessen Primärschlüssel das hängende Schlüsselattribut „Projektnr“ bildet. Das
weitere Primärschlüsselattribut „Abteilnr“ findet man in der Menge der Abhängigkeiten I
nur unter Projekt.Abteilnr→Abteilung.Abteilnr. Daher verweist „Abteilnr“ auf Tabelle
1
Da in einem EER-Schema die Namen von Entities und Beziehungen eindeutig sein müssen, werden
den „ABHÄNGIG“-Beziehungen ebenso wie den „SPEZIELL“-Entities die Relationennamen
angehängt, aus denen sie erzeugt wurden. Die „HAT“-Beziehungen werden durchnumeriert. Der
laufende Text wird durch Weglassen der Nummern bzw. Relationennamen vereinfacht.
- 52 -
„Abteilung“, die bereits in ein gleichnamiges starkes Entity umgewandelt worden ist.
„Abteilung“ ist also der einzige Eigentümer von „Projekt“.
Abteilung
(Abteilnr)
Projekt
(Abteilnr→Abteilung, Projektnr, Projname)
Abteilnr
Abteilung
ABHÄNGIG
Projektnr
Projekt
Projname
3.3.4 Spezielle Beziehungs-Relationen
Wenn alle Entity-Relationen verarbeitet worden sind, sollen die BeziehungsRelationen umgesetzt werden. Für die allgemeinen Schlüsselattribute einer Tabelle, die
als spezielle Beziehungs-Relation klassifiziert wurde, wird ein neues Entity erzeugt. Die
anderen Primärschlüsselattribute legen jene Entities fest, die neben dem neuen Entity an
der zu erzeugenden Beziehung teilnehmen.
Alg3)
allgemeinen
Sei A∈SBR mit Primärschlüssel P, H⊂P sei die Menge aller
Schlüsselattribute
von
A,
M
die
Menge
der
sonstigen
Primärschlüsselattribute M=P\H, N sei die Menge der Nichtschlüsselattribute von A.
Dann erzeuge ein starkes Entity namens ‘SPEZIELL’ mit Primärschlüssel H und
weise alle Attribute von N dem neuen Entity zu.
Erzeuge anschließend eine n-fache Beziehung namens A, an der alle Entities
einer Menge W teilnehmen. W wird wie folgt initialisiert: W:=‘SPEZIELL’. Überprüfe
für alle Relationen R∈ER, ob der Primärschlüssel Q von R Teil des Primärschlüssels
von A ist, ob also Q⊂M gilt. Ist dies der Fall, so prüfe, ob (A.Q→R.Q)∈I gilt. Wenn
beide Bedingungen zutreffen, so nimmt das Entity, das mit Tabelle R korrespondiert,
an der Beziehung teil und es sei W:=W∪R.
Beispiel:
Die folgende Tabelle „Projekt“ ist eine derartige spezielle Beziehungs-Relation.
Zunächst wird ein Entity „SPEZIELL“ erzeugt, dessen Primärschlüssel das einzige
allgemeine Schlüsselattribut „Projektnr“ bildet. Die Primärschlüsselattribute „Abteilnr“
bzw. „Standort“ verweisen auf die Entities „Abteilung“ bzw. „Ort“, die bereits bei der
Umsetzung der starken Entity-Relationen erzeugt worden sind. An der neuen Beziehung
- 53 -
„Projekt“ nehmen also die Entities „Abteilung“, „Ort“ und „SPEZIELL“ teil. In der
Menge I müssen die Abhängigkeiten Projekt.Abteilnr→Abteilung.Abteilnr sowie
Projekt.Standort→Ort.Standort definiert sein. Das Nichtschlüsselattribut „Projname“
wird dem neuen Entity „SPEZIELL“ zugeordnet.
Abteilung
(Abteilnr)
Ort
(Standort, Mitarbeiterzahl)
Projekt
(Abteilnr→Abteilung, Standort→Ort, Projektnr, Projname)
(Die Namen, die im EER-Schema automatisch verwendet werden, sind an dieser Stelle
nicht sehr passend. Der Anwender sollte später die Namen ändern.)
Projektnr
Abteilnr
Abteilung
Projekt
SPEZIELL
Projname
Standort
Ort
Mitarbeiterzahl
Der Grund dafür, daß im Gegensatz zu Chiangs Verfahren hier als erstes die
Beziehungen erzeugt werden, die aus den speziellen Beziehungs-Relationen folgen, ist
bei Betrachtung obigen Beispiels leicht einzusehen:
Wenn eine weitere Tabelle
Mitarbeiter
(Name, Projektnr→Projekt)
existiert, so muß der Fremdschlüssel „Projektnr“ auf das Entity „SPEZIELL“
verweisen, denn „Projektnr“ ist ein allgemeines Schlüsselattribut in „Projekt“. Dieser
Verweis kann nur dann erzeugt werden, wenn die spezielle Beziehungs-Relation
„Projekt“ vorher verarbeitet worden ist. Derartige Abhängigkeiten, bei denen ein
Fremdschlüssel einer Entity-Relation auf allgemeine Schlüsselattribute einer speziellen
Beziehungs-Relation zeigen, können mit Chiangs Algorithmus nicht ausgewertet werden.
- 54 -
3.3.5 Reguläre Beziehungsrelationen
Analog zu den speziellen Beziehungs-Relationen werden auch die regulären BeziehungsRelationen umgesetzt. Bei diesen ist es aber nicht erforderlich, neue Entities zu erzeugen:
Sei
Alg4)
A∈RBR
mit
Primärschlüssel
P,
N
sei
die
Menge
der
Nichtschlüsselattribute von A. Erzeuge eine n-fache Beziehung namens A und weise
alle Attribute von N dieser neuen Beziehung zu. Um festzustellen, welche Entities an
der Beziehung teilnehmen, überprüfe (analog zu oben) für alle Relationen R∈ER, ob
der Primärschlüssel Q von R Teil des Primärschlüssels von A ist, ob also Q⊂P gilt. Ist
dies der Fall, so prüfe, ob (A.Q→R.Q)∈I gilt. Wenn beide Bedingungen zutreffen, so
nimmt das Entity, das mit Tabelle R korrespondiert, an der Beziehung teil und es sei
W:=W∪R. In der Menge W werden so alle Entity-Namen abgelegt, die an der
Beziehung A teilnehmen. Bei Erzeugung dieser Beziehung müssen also alle Entities
aus W durch A miteinander verbunden werden.
Beispiel:
Die Tabelle „Betreuung“ ist eine reguläre Beziehungs-Rel., deren Primärschlüssel die
beiden Teilnehmer der Beziehung, „Student“ und „Professor“, bestimmt. Dazu müssen
die Abhängigkeiten Betreuung.Matrikelnummer→Student.Matrikelnummer und
Betreuung.ProfName→Professor.Name in der Menge I vorhanden sein. Die
Nichtschlüsselattribute „Beginn“ und „Ende“ werden
der
neuen
Beziehung
„Betreuung“ zugeordnet.
Student
(Matrikelnr, Name, Straße, Ort)
Professor
(Name, Gehalt, Fachbereich)
Betreuung
(Matrikelnr→Student, ProfName→Professor, Beginn, Ende)
Matrikelnr
Name
Straße
Ort
Student
Betreuung
Beginn
Professor
Ende
Name
Gehalt
Fachbereich
- 55 -
3.3.6 Sonderfall bei Beziehungsrelationen
Einen Fall haben wir bei der Behandlung der Beziehungs-Relationen bisher außer
acht gelassen: Es ist denkbar (wenn auch ungewöhnlich), daß ein Primärschlüsselattribut
einer Beziehungs-Relation A∈BR gleichzeitig als Fremdschlüsselattribut klassifiziert
wurde, die Abhängigkeit in I aber auf eine spezielle Beziehungs-Relation verweist. Mit
den oben angegebenen Verfahren werden nur Entities als Teilnehmer an Beziehungen
erkannt, die aufgrund von Entity-Relationen entstanden sind. Der Fall, daß ein Entity,
das aus einer speziellen Beziehungs-Relation gebildet wurde, an einer Beziehung
teilnimmt, wurde bisher (wie bei Chiang) vernachlässigt.
Alg5)
Sei
also
M
eine
Menge
von
Primärschlüsselattributen
einer
Beziehungs-Relation A, die alle auch als Fremdschlüsselattribute klassifiziert wurden,
jedoch nicht auf eine Entity-Relation verweisen. Prüfe für jede Tabelle R∈SER, ob die
allgemeinen Schlüsselattribute Q von R Teil der Menge M sind, ob also Q⊂M gilt. Ist
dies der Fall, so prüfe, ob (A.Q→R.Q)∈I gilt. Trifft beides zu, dann ist das Entity
‘SPEZIELL’, das aufgrund der speziellen Beziehungs-Relation R entstanden ist und
an der Beziehung, die mit R korrespondiert, teilnimmt, Bestandteil der Beziehung, die
aus der Beziehungs-Relation A erzeugt wurde.
Beispiel:
Gegeben seien beispielsweise die schon oben behandelten Tabellen „Abteilung“, „Ort“
und „Projekt“. Zusätzlich wird nun gespeichert, welche Firmen ein Projekt finanziell
unterstützen. Dazu existiert einmal die Tabelle „Firma“, die als starke Entity-Relation
klassifiziert wird, in der die Firmendaten gesichert werden. Zum anderen gibt es eine
reguläre Beziehungs-Relation „Sponsor“, in der den Firmen verschiedene Projekte
zugeordnet werden. Die Schwierigkeit ist, daß das Primärschlüsselattribut „Projektnr“
von „Sponsor“ auf eine spezielle Beziehungs-Relation, nämlich auf „Projekt“, verweist.
Erst durch das zuletzt angegebene Verfahren kann die Beziehung „Sponsor“ erzeugt
werden. In der Menge I werden die Abhängigkeiten Sponsor.Name→Firma.Name
sowie Sponsor.Projektnr→Projekt.Projektnr benötigt.
- 56 -
Abteilung
(Abteilnr)
Ort
(Standort, Mitarbeiterzahl)
Projekt
(Abteilnr→Abteilung, Standort→Ort, Projektnr, Projname)
Firma
(Name, Gesellsch)
Sponsor
(Name→Firma, Projektnr→Projekt)
Projektnr
Abteilnr
Abteilung
Projekt
SPEZIELL
Projname
Standort
Ort
Sponsor
Mitarbeiterzahl
Name
Firma
Gesellsch
3.3.7 Fremdschlüssel-Beziehungen
Weitere (binäre) Beziehungen werden aufgrund von Fremdschlüsseln erzeugt. Dazu
werden alle Entity-Relationen daraufhin untersucht, ob sie Attribute besitzen, die als
Fremdschlüssel klassifiziert wurden, aber nicht gleichzeitig als Primärschlüssel fungieren.
Attribute, die gleichzeitig als Primär- und Fremdschlüsselattribute klassifiziert wurden,
sind bereits in den vorhergehenden Abschnitten behandelt worden.
Die Menge der Abhängigkeiten I wird dann nach Vorkommen des Fremdschlüssels
auf der linken Seite einer Inklusion untersucht, um so die an der Beziehung beteiligte
Relation zu ermitteln.
Mögliche Kardinalitäten für diese funktionalen Beziehungen werden erst im
Abschnitt „Kardinalitäten“ ermittelt.
Alg6)
Sei F Fremdschlüssel einer Tabelle A∈ER. Durchsuche dann die
Menge der Inklusionen I nach Vorkommen von F auf der linken Seite von
Abhängigkeiten: Wenn (A.F→X.M)∈I mit beliebiger Tabelle X∈ER gilt, wobei M
Schlüsselkandidat für Relation X ist, dann erstelle eine binäre Beziehung namens
‘HAT’ zwischen den Entities, die mit den Tabellen A bzw. X korrespondieren.
- 57 -
Beispiel:
Gegeben seien zum Beispiel die beiden Tabellen „Student“ und „Wohnort“. Das
Attribut „Plz“ in „Student“ wird als Fremdschlüsselattribut klassifiziert und die
zugehörige Abhängigkeit Student.Plz→Wohnort.Plz verweist auf die Tabelle
„Wohnort“. Entsprechend wird eine binäre Beziehung „HAT“ zwischen den Entities, die
aus den beiden starken Entity-Relationen entstanden sind, erzeugt.
Student
(Matrikelnummer, Name, Straße, Plz→Wohnort)
Wohnort
(Plz, Ort)
Matrikelnummer
Name
Straße
Plz
Student
HAT
Wohnort
Ort
3.3.8 Aggregationen
Besitzt hingegen eine Beziehungs-Relation einen Fremdschlüssel, so deutet dies auf
eine binäre Beziehung zwischen einer Beziehung und einem Entity hin. Dies ist jedoch
nur im Zusammenhang mit Aggregationen sinnvoll.
Alg7)
Sei F Fremdschlüssel einer Tabelle A∈BR. Durchsuche die Menge der
Inklusionen I nach Vorkommen von F auf der linken Seite von Abhängigkeiten: Wenn
(A.F→X.M)∈I mit beliebiger Tabelle X∈ER gilt, wobei M Schlüsselkandidat für Relation
X ist, dann bilde eine Aggregation und eine neue Beziehung: Die Aggregation
namens A beinhaltet die Beziehung, die mit A korrespondiert, sowie alle an A
beteiligten Entities. Die neue binäre Beziehung ‘HAT’ setzt die Aggregation und das
Entity, das mit X korrespondiert, zueinander in Beziehung.
Beispiel:
Soll beispielsweise in einer Datenbank einer Kombination von „Student“ und
„Professor“ ein „Fachbereich“ zugeordnet werden, so bietet sich eine derartige
Aggregation an. Über die Beziehung „Betreuung“ wird jedem Studenten aus dem
starken Entity „Student“ ein Professor aus dem starken Entity „Professor“ zugeordnet.
Dazu sind in I die Inklusionen Betreuung.Matrikelnr→Student.Matrikelnr und
Betreuung.ProfName→Professor.Name gespeichert. Das Attribut „FB“ aus der
Tabelle „Betreuung“ wird als Fremdschlüssel klassifiziert. Als zugehörige Abhängigkeit
- 58 -
wird Betreuung.FB→Fachbereich.FB ermittelt. „FB“ ist der Primärschlüssel des
starken Entities „Fachbereich“. Wegen der zuletzt genannten Inklusion werden nun die
Beziehung namens „Betreuung“ und alle an ihr teilnehmenden Entities, also „Student“
und „Professor“, einer Aggregation „Betreuung“ zugeordnet. Anschließend wird eine
binäre Beziehung „HAT“ erzeugt, die das Entity „Fachbereich“ mit der Aggregation
verknüpft.
Student
(Matrikelnr, Name)
Professor
(Name)
Betreuung
(Matrikelnr→Student, Name→Professor, FB→Fachbereich)
Fachbereich (FB)
Matrikelnr
Name
Student
Betreuung
Professor
Name
Betreuung
HAT
Fachbereich
FB
3.3.9 Fremdschlüssel besonderer Entity-Relationen
Die einzigen Fremdschlüssel, die bisher noch nicht beachtet wurden, sind die
Primärschlüssel der besonderen Entity-Relationen. Der Primärschlüssel von Tabellen, die
als besondere Entity-Relationen klassifiziert wurden, besteht aus genau einem
Fremdschlüssel. Dies deutet auf eine Generalisierung (bzw. Spezialisierung) hin oder auf
eine binäre Beziehung, bei der nur Kardinalitäten (1,1) auftreten.
Um zu unterscheiden, ob eine binäre Beziehung mit dieser besonderen Eigenschaft,
oder eine Generalisierung vorliegt, müssen die Abhängigkeiten untersucht werden, die im
Zusammenhang mit der jeweiligen besonderen Entity-Relation auftreten. Verweist die
Fremdschlüssel-Bedingung einer solchen Tabelle auf eine andere besondere EntityRelation, so kann von einer binären Beziehung mit Kardinalitäten (1,1) ausgegangen
werden.
Anderenfalls verweist die Abhängigkeit, die zum Primärschlüssel einer besonderen
Entity-Relation gehört, auf eine andersartige Entity-Relation. Gibt es nur eine besondere
- 59 -
Entity-Relation, deren Primärschlüssel auf dieselbe Tabelle zeigt, so handelt es sich hier
um eine Spezialisierung. Sonst liegt eine Generalisierung vor, deren Art über zusätzliche
Anfragen ermittelt werden muß.
Sei also A∈BER mit Primärschlüssel P. P ist gleichzeitig als
Alg8)
Fremdschlüssel klassifiziert worden. Durchsuche I nach Abhängigkeiten, auf deren
linken Seite A.P auftritt. Ist (A.P→X.Q)∈I eine solche Abhängigkeit, bei der X∈ER und
Q Primärschlüssel von X ist, so unterscheide folgende Fälle:
Wenn X∈BER ist und auch (X.Q→A.P)∈I gilt, so bilde eine binäre Beziehung namens
‘GLEICH’ mit Kardinalitäten (1,1) zwischen den Entities, die mit A bzw. X
korrespondieren. Die Attribute des gemeinsamen Primärschlüssels P werden der
neuen Beziehung zugeordnet und aus den Entities entfernt.
Sonst untersuche die Menge I nach weiteren Inklusionen, auf deren rechten Seite
Tabelle X erscheint: Ist (R.M→X.Q)∈I mit R∈BER und M Primärschlüssel von R, so
merke Tabelle R in einer Menge von Relationen GENREL. Unterscheide dann:
Ist GENREL leer, also GENREL=∅, so sei A eine Spezialisierung von X, denn in
diesem Fall ist A die einzige Relation, die zu X.Q in Beziehung steht. Sonst besteht
eine Generalisierungs-Hierarchie zwischen A sowie allen Tabellen R∈GENREL und X.
Die Art der Generalisierung kann nur über zusätzliche Datenbank-Anfragen ermittelt
werden:
Sei GENREL:=GENREL∪{A}. Ist jeder Wert des Primärschlüssels von Tabelle X in
einer der Relationen R∈GENREL gespeichert, so handelt es sich um eine totale
Generalisierung. Sonst liegt eine partielle Generalisierung vor.
Für alle Tabellen R∈GENREL seien folgende Mengen definiert: (n=1,...,|GENREL|)
Rn:={SELECT DISTINCT <Primärschlüssel M> FROM <Tabelle Rn>}
Weiterhin sei für Relation X definiert:
Z:={SELECT DISTINCT <Primärschlüssel Q> FROM <Tabelle X>}
Wenn Z⊂(R1∪...∪R|W|) gilt, so wird aufgrund des aktuellen Datenbank-Zustandes eine
totale Generalisierung vermutet. Ebenso kann zwischen exklusiver und überlappender
Generalisierung unterschieden werden: Wenn für alle i,j=1,...,|W|, i≠j, Ri∩Rj=∅ gilt, so
handelt es sich vermutlich um eine exklusive, sonst um eine überlappende
Generalisierung.
- 60 -
Unabhängig davon, ob eine Spezialisierung oder eine Generalisierung vorliegt, wird
der Primärschlüssel der
Entities,
die mit den
besonderen
Entity-Relationen
korrespondieren, gelöscht.
Beispiel:
Für alle drei Fälle werden nun Beispiele aufgeführt. Gegeben seien zum Beispiel die
beiden besonderen Entity-Relationen „Student“ und „Wohnung“. Der Primärschlüssel
„Matrikelnr“ beider Tabellen wird gleichzeitig auch als Fremdschlüssel klassifiziert. Weil
die
beiden
Inklusionen
Student.Matrikelnr→Wohnung.Matrikelnr
und
Wohnung.Matrikelnr→Student.Matrikelnr ermittelt werden, wird eine binäre
Beziehung „GLEICH“ zwischen den beiden Entities „Student“ und „Wohnung“
erstellt. Die Kardinalitäten an beiden Seiten der Beziehung betragen (1,1).
Student
(Matrikelnr→Wohnung, Name)
Wohnung
(Matrikelnr→Student, Straße, Ort)
Student
(1,1)
GLEICH
Matrikelnr, Name
(1,1)
Wohnung
Matrikelnr, Straße, Ort
Eine Spezialisierung entsteht bei den beiden Tabellen „Mitarbeiter“ und „Manager“.
„Mitarbeiter“ ist eine starke Entity-Relation, während „Manager“ als eine besondere
Entity-Relation klassifiziert wird, weil sein Primärschlüssel „Personalnr“ gleichzeitig
Fremdschlüssel ist und auf den Primärschlüssel von „Mitarbeiter“ verweist und die
Abhängigkeit Manager.Personalnr→Mitarbeiter.Personalnr Element der Menge I
ist. Eine weitere Abhängigkeit, die auf Mitarbeiter.Personalnr zeigt, wird nicht
gefunden. Deshalb ist die Menge W leer und zwischen „Manager“ und „Mitarbeiter“
wird eine Spezialisierung erzeugt. Der Primärschlüssel von „Manager“ kann dann aus
dem EER-Schema entfernt werden.
Mitarbeiter
(Personalnr, Name, Gehalt)
Manager
(Personalnr→Mitarbeiter, Abteilung)
Personalnr, Name, Gehalt
Mitarbeiter
Manager
Abteilung
- 61 -
Im Gegensatz dazu bleibt die Menge W bei den folgenden gegebenen Tabellen nicht leer:
Person
(Name, Alter)
Mann
(Name→Person)
Frau
(Name→Person, Geburtsname)
Zunächst wird die besondere Entity-Relation „Mann“ gefunden. Ihr Primärschlüssel
„Name“ verweist auf den Primärschlüssel der starken Entity-Relation „Person“, denn
die Inklusion Mann.Name→Person.Name ist Element der Menge der Abhängigkeiten
I. Bei der Suche nach weiteren Abhängigkeiten, die auf Person.Name zeigen, wird
Frau.Name→Person.Name gefunden. „Frau“ ist ebenfalls als besondere EntityRelation klassifiziert worden und wird deswegen in die Menge W aufgenommen. Da
keine weiteren Abhängigkeiten in I gefunden werden, die zu dieser GeneralisierungsHierarchie gehören, wird nun die Art der Generalisierung durch oben genannte Anfragen
ermittelt. Dabei kommt heraus, daß Z⊂(R1∪R2) ist und R1∩R2=∅ ist. Es liegt also eine
totale exklusive Generalisierung vor.
Person
Mann
Name, Alter
Frau
Geburtsname
3.3.10 Kardinalitäten
Bei der Behandlung der besonderen Entity-Relationen wurden erstmals in diesem
Verfahren für eine Beziehung Kardinalitäten angegeben. In besagtem Fall ist die Angabe
der Kardinalitäten sehr einfach und leicht einzusehen. Schwieriger wird die Angabe auch
für andere Beziehungen. Hier müssen vor allem Indexe bzw. Anfragen und die im
Relationenschema in der Regel aufgeführten „null“- bzw. „not null“-Eigenschaften der
Attribute helfen, die ungefähren Kardinalitäten zu ermitteln. Letztgenannte Eigenschaften
geben Aufschluß über die Minimum-Angaben bei den Kardinalitäten (0 oder 1), Indexe
und Anfragen helfen, die Maximum-Angaben zu finden. Dabei ist jedoch nur die
Unterscheidung zwischen 1 und N möglich, denn bestimmte Werte größer als 1 sind aus
- 62 -
einem Relationenschema nicht mehr ableitbar. Lediglich durch die Auswertung von
Triggern ist eine genauere Bestimmung von Kardinalitäten möglich.
Zwei Arten von Beziehungen sollen getrennt untersucht werden: Auf der einen Seite
sind die Beziehungen zu betrachten, die aufgrund von Beziehungs-Relationen entstanden
sind, auf der anderen Seite werden die (funktionalen) Beziehungen behandelt, die durch
Fremdschlüssel und Inklusionen erzeugt wurden.
3.3.10.1 Kardinalitäten bei Beziehungsrelationen
Wenn eine Beziehung erstellt wurde, weil eine Tabelle in die Klasse der BeziehungsRelationen (reguläre oder spezielle) eingeordnet war, so gehört zu jedem Entity, das an
dieser Beziehung teilnimmt, in der Regel eine Kardinalität (0,N). Andere Kardinalitäten
sind nur über Anfragen zu ermitteln: Wenn ein Fremdschlüssel, der Teil des
Primärschlüssels der Tabelle ist, die mit der Beziehung korrespondiert, nur eindeutige,
also „unique“ Werte enthält, so ist als Maximum-Angabe in der Kardinalität, die zu dem
Entity gehört, auf dessen Primärschlüssel der betrachtete Fremdschlüssel verweist, eine 1
zu vermuten. Die Eigenschaft „unique“ kann entweder aus einem definierten Index oder
aus Anfragen der Art, wie bereits in 3.1.1 besprochen wurden, gefolgert werden.
Andererseits ist die Minimum-Angabe auf 1 zu korrigieren, wenn durch Anfragen
festgestellt wird, daß jeder Wert des Primärschlüssels der Entity-Relation im zugehörigen
Fremdschlüssel der Beziehungs-Relation erscheint.
Alg9)
Sei A∈BR mit Primärschlüssel P. F1,...,Fn⊂P seien die Fremdschlüssel,
die zur Beziehungs-Relation A gehören. Dann untersuche zunächst für alle
F=F1,...,Fn, ob auf die Werte in F die „unique“-Eigenschaft zutrifft. Wenn auf F kein
„unique“-Index definiert ist, so starte die Anfrage
SELECT COUNT(*) INTO z FROM A GROUP BY F
HAVING COUNT(*)>1
Wenn z<2 gilt oder ein „unique“-Index definiert ist, so lege in der Kardinalität zwischen
der Beziehung A und dem Entity, auf das Fremdschlüssel F verweist, die MaximumAngabe auf 1 fest. Sonst beträgt sie N.
Sei weiterhin die Abhängigkeit A.F→X.Q Element der Menge I, also Q der
Primärschlüssel der Entity-Relation X, auf den der Fremdschlüssel F verweist. Das
Minimum der zu bestimmenden Kardinalität wird zunächst auf 0 gesetzt. Es muß auf 1
korrigiert werden, wenn die folgende Anfrage z=0 liefert:
- 63 -
SELECT COUNT(*) INTO z FROM X WHERE NOT EXISTS
(SELECT F FROM A WHERE A.F=X.Q)
Wenn nämlich die Anfrage das Ergebnis z=0 liefert, so gibt es keine Werte in X.Q, die
nicht auch in A.F auftauchen.
Eine Besonderheit tritt auf, wenn eine spezielle Beziehungs-Relation vorliegt:
Wenn A∈SBR, so wurde bei der Umsetzung ein Entity erzeugt, dessen Primärschlüssel
aus den allgemeinen Schlüsselattributen von A zusammengesetzt ist. Die Untergrenze der
Kardinalität zwischen diesem Entity und der Beziehung, die mit A korrespondiert, kann
in jedem Fall auf 1 gesetzt werden, da aufgrund der Art der Speicherung keine Werte im
Entity existieren können, die nicht auch an der Beziehung teilnehmen. Die Obergrenze ist
genauso festzustellen wie oben: Liefert die Anfrage
SELECT COUNT(*) INTO z FROM A GROUP BY M
HAVING COUNT(*)>1
(M ist die Menge der allgemeinen Schlüsselattribute von A) das Ergebnis z<2 oder ist
sogar ein „unique“-Index auf M definiert, so beträgt die Kardinalität (1,1), sonst (1,N).
3.3.10.2 Kardinalitäten bei funktionalen Beziehungen
Das Feststellen der Kardinalitäten bei binären Beziehungen, die aufgrund von
Fremdschlüssel-Klassifikationen erstellt wurden, verläuft ähnlich:
Alg10)
Sei A die betrachtete Relation, die den Fremdschlüssel F enthält.
Wenn A keine schwache Entity-Relation ist, so darf F nicht gleichzeitig Teil des
Primärschlüssels von A sein. Ist hingegen A eine schwache Entity-Relation, so verweist F
auf einen Eigentümer von A und die daraus entstandene Beziehung wird ebenfalls hier
behandelt.
In der Menge der Inklusionen I kann dann eine Abhängigkeit A.F→X.Q gefunden
werden, wobei X∈ER gilt. Die betrachtete Beziehung besteht dann zwischen dem
Objekt, das mit A korrespondiert, und dem Entity, das aus Tabelle X erzeugt wurde.
Beide Objekte sollen hier ebenfalls mit A bzw. X bezeichnet werden.
Die Kardinalität auf der Seite von A kann entweder (0,1) oder (1,1) sein
(funktionale Beziehung). Unterscheiden kann man dies, indem man die „null“- bzw. „not
null“-Eigenschaft von F auswertet:
- 64 -
Wenn mindestens ein Attribut von F keine leeren Werte zuläßt („not null“), so muß
Kardinalität (1,1) gewählt werden. Sonst wird (0,1) bevorzugt.
Schwieriger ist die Festlegung der Kardinalität auf der anderen Seite: Auch diese ist
nur durch Anfragen bzw. die Auswertung von Indexen zu ermitteln:
Sind die Werte von F in A „unique“, d.h. ist ein „unique“-Index auf F definiert oder
liefert die Anfrage
SELECT COUNT(*) INTO z FROM A GROUP BY F
HAVING COUNT(*)>1
als Ergebnis z<2, so ist die Obergrenze der Kardinalität auf der Seite von X auf 1
festzulegen. Sonst beträgt sie N.
Die Untergrenze dieser Kardinalität ist in der Regel 0. Sie muß aber auf 1
korrigiert werden, wenn in Q kein einziger Wert auftritt, der nicht auch in F gespeichert
ist, wenn also die folgende Anfrage das Ergebnis z=0 liefert:
SELECT COUNT(*) INTO z FROM X WHERE NOT EXISTS
(SELECT F FROM A WHERE A.F=X.Q)
An dieser Stelle ist zum wiederholten Mal zu beachten, daß die Ergebnisse von Anfragen
vom jeweiligen Datenbank-Zustand abhängig sind. Die Kardinalitäten, die aufgrund von
Anfrage-Ergebnissen gebildet wurden, bedürfen deshalb einer genauen Überprüfung.
Beispiel:
Als Beispiel soll folgendes Relationenschema betrachtet werden, das nahezu mit einem
Schema übereinstimmt, welches in einem vorhergehenden Kapitel umgesetzt worden ist.
Attribute, die „null“-Werte erlauben, weisen diese Eigenschaft explizit aus, indem bei
ihnen als „Exponent“ eine 0 notiert wird:
Abteilung
(Abteilnr)
Standort
(Standort, Plz→Ort, Mitarbeiterzahl)
Ort
(Plz, Name)
Projekt
(Abteilnr→Abteilung, Standort→Ort, Projektnr, Projname)
Firma
(Name, Straße0, Postfach0,
Plz→Ort, Aktiennr0→Aktien)
Aktien
(Aktiennr, Wert, Anzahl)
Sponsor
(Name→Firma, Projektnr→Projekt)
- 65 -
Im Gegensatz zu oben sind die starken Entities „Ort“ und „Aktien“ hinzugekommen, auf
die die Fremdschlüssel „Plz“ in „Standort“ bzw. „Firma“ und „Aktiennr“ in „Firma“
verweisen. Die Umsetzung in ein EER-Schema ist leicht zu vollziehen.
Um die Kardinalitäten festzulegen, wird als erstes die spezielle Beziehungs-Relation
„Projekt“ betrachtet. Das Attribut „Abteilnr“ enthält weder eindeutige Werte, noch sind
alle Werte von „Abteilnr“ in Tabelle „Abteilung“ auch in Tabelle „Projekt“ gespeichert.
Als Kardinalität auf der Seite von „Abteilung“ folgt deshalb (0,N). Bei „Standort“
hingegen folgt (1,N), denn die Anfrage
SELECT COUNT(*) INTO z FROM Standort
WHERE NOT EXISTS (SELECT Standort FROM Projekt
WHERE Projekt.Standort=Standort.Standort)
liefert als Ergebnis z=0. Auf der Seite vom Entity „SPEZIELL“ steht Kardinalität (1,1),
weil die Anfrage
SELECT COUNT(*) INTO z FROM Projekt GROUP BY Projektnr
HAVING COUNT(*)>1
z<2 zurückliefert und somit das Attribut „Projektnr“ nur eindeutige („unique“) Werte
enthält.
„Sponsor“ ist eine reguläre Beziehungs-Relation. Aus ihr wird eine Beziehung
zwischen den Entities „SPEZIELL“ und „Firma“ erzeugt. Die Anfragen, die zur
Ermittlung der Kardinalitäten gestellt werden, liefern alle Werte z>0. Deshalb folgt hier
auf beiden Seiten der Beziehung Kardinalität (0,N).
In den Tabellen „Standort“ und „Firma“ tritt der Fremdschlüssel „Plz“ auf, der auf
Tabelle „Ort“ verweist. Bei beiden Relationen erlaubt „Plz“ keine „null“-Werte, so daß
auf ihrer Seite Kardinalität (1,1) steht. Auf der anderen Seite folgt jeweils (0,N), denn in
Tabelle „Ort“ werden auch Orte gespeichert, die weder in „Standort“ noch „Firma“
auftauchen. Außerdem könnten mehrere Firmen oder Standorte unter der gleichen
Postleitzahl erreichbar sein.
- 66 -
Anders sieht es für die binäre „HAT“-Beziehung zwischen „Firma“ und „Aktien“
aus. Der Fremdschlüssel „Aktiennr“ in Relation „Firma“ erlaubt auch „null“-Werte, so
daß auf Seite des Entities „Firma“ die Kardinalität (0,1) stehen muß. Auf der anderen
Seite steht (1,1), weil beide erstellten Anfragen als Ergebnis z=0 liefern, also das Attribut
„Aktiennr“ in „Firma“ nur eindeutige Werte enthält und jede „Aktiennr“ aus „Aktien“
auch in „Firma“ gespeichert ist.
Abteilnr
Abteilung
(0,N)
(1,1)
Projekt
SPEZIELL
(1,N)
Standort
Mitarbeiterzahl
Sponsor
(1,1)
(0,N)
(1,1)
Plz
Name
Ort
Firma
HAT
(0,N)
Projname
(0,N)
Standort
HAT
Projektnr
(0,1)
(0,N)
Name
Straße
Postfach
HAT
(1,1)
Aktien
Aktiennr
Wert
Anzahl
3.4 Bewertung des eigenen Verfahrens
Bei der Bewertung eines Algorithmus ist es von entscheidender Bedeutung, ob das
Verfahren korrekt ist bzw. ob die Algorithmus-Schritte äquivalenzerhaltend sind. Dabei
wird zwischen semantischer und syntaktischer Korrektheit unterschieden, wobei letzter
Punkt die reine Modellierung betrifft und somit durch das Verfahren aus Kapitel 3.3
gesichert wird, weil das Zielschema dem EER-Modell entspricht.
Schwieriger ist die Bewertung der semantischen Korrektheit: Hier muß jeder Schritt
des Umsetzungs-Prozesses (aus Kapitel 3.3) daraufhin untersucht werden, ob
Informationen verloren gehen oder durch Vermutungen hinzugefügt werden. Bei dieser
Analyse wird auf den Algorithmus in 3.3 verwiesen. Vorausgesetzt wird an dieser Stelle,
daß die zur Umsetzung nötigen Informationen durch den Anwender ergänzt und
vervollständigt bzw. korrigiert werden - die Auswertung des Relationenschemas allein
- 67 -
reicht nicht aus, da beispielsweise einige referentielle Abhängigkeiten nicht aus dem
relationalen Schema abgelesen werden können. Auch die Klassifikation zwischen
schwacher Entity-Relation und spezieller Beziehungs-Relation muß durch den Anwender
entschieden werden (s.o.).
Es kann hier nur untersucht werden, ob das Ergebnis-Schema äquivalent zum
Quellschema (inklusive aller Zusatzangaben) ist. Ein anderes Problem ist die
Unvollständigkeit der Modellierung: Solange das Quellschema nicht vollständig ist, kann
das Verfahren kein vollständiges Zielschema erzeugen.
In Schritt „Alg1“ werden starke und besondere Entity-Relationen in Entities
umgewandelt und diesen Entities alle Nichtschlüsselattribute und der Primärschlüssel der
zugehörigen ursprünglichen Tabellen zugeordnet. Hier gehen also alle Attribute verloren,
die als Fremdschlüsselattribute und nicht gleichzeitig als Primärschlüsselattribute
klassifiziert wurden. Diese Fremdschlüssel werden zu einem späteren Zeitpunkt („Alg6“)
ausgewertet. Bei besonderen Entity-Relationen wird zunächst vernachlässigt, daß ihr
Primärschlüssel aus exakt einem Fremdschlüssel besteht.
Schwache Entity-Relationen werden in ein Entity und eine Beziehung umgesetzt
(„Alg2“). Ebenso wie in „Alg1“ werden hier vorläufig Fremdschlüsselattribute, die nicht
zum Primärschlüssel gehören, außer acht gelassen. Alle anderen Attribute werden dem
neuen schwachen Entity zugeordnet, aus den hängenden Schlüsselattributen und den
zugehörigen referentiellen Abhängigkeiten werden Beziehungen zwischen schwachem
Entity und seinen Eigentümern erstellt. Zu beachten ist hier, daß in der Regel zu einer
schwachen Entity-Relation nur eine Eigentümer-Beziehung gehört, denn Tabellen mit
mehreren Fremdschlüsseln im Primärschlüssel werden als spezielle Beziehungs-Relation
klassifiziert, sofern der Anwender an dieser Stelle nicht eingreift.
Diese ersten Schritte sind also, abgesehen von den Fremdschlüsseln, semantisch
korrekt. Die Semantik des Schemas vor diesen Verfahrens-Schritten ist äquivalent zur
Semantik des Schemas danach. Informationen gehen weder verloren, noch werden
welche hinzugefügt.
In den Algorithmus-Schritten „Alg3“ bis „Alg5“ werden Beziehungs-Relationen
ausgewertet. Dabei werden zunächst die Entities zu speziellen Beziehungs-Relationen
erzeugt, bevor dann die Beziehungen erstellt werden. Auch hier gehen - abgesehen von
den Fremdschlüsseln, die nicht zu einem Primärschlüssel gehören - keine Informationen
- 68 -
verloren. Allerdings ist, wie schon bei Behandlung der schwachen Entity-Relationen, die
Benennung der EER-Objekte bei dieser Betrachtung auszuklammern, da eine semantisch
korrekte Namensgebung aus dem Relationenschema nicht abgeleitet werden kann. Der
Anwender hat hier durch Umbenennung dafür zu sorgen, daß sprechendere Namen als
„ABHAENGIG“
bzw.
„SPEZIELL“
vergeben
werden.
Um
den
Grad
der
Automatisierung des Verfahrens nicht zu verringern, werden derartige NutzerÄnderungen erst nach Ablauf des Umsetzungs-Prozesses vorgesehen.
Die Fremdschlüssel-Beziehungen werden in „Alg6“ und „Alg7“ behandelt.
Semantisch korrekt ist dabei mit Sicherheit „Alg6“: In diesem Teil des Verfahrens
werden die in „Alg1“ und „Alg2“ ausgeklammerten Fremdschlüssel von EntityRelationen ausgewertet und daraus binäre Beziehungen erzeugt. Problematisch hingegen
ist die Erstellung von Aggregationen im siebten Schritt: Nicht immer ist es korrekt, daß
aus Fremdschlüsseln in Beziehungs-Relationen Aggregationen auf diese Art wie in
„Alg7“ erzeugt werden. Es ist ebenso möglich, daß mehr EER-Objekte in einer
Aggregation zusammengefaßt werden, als das Verfahren dies im Zielschema angibt. Der
Anwender muß dafür sorgen, daß die Semantik erhalten bleibt, indem er die
Aggregationen entsprechend ändert.
Beispiel:
In folgendem Schema wird dieses Problem deutlich:
Student
(Matrikelnr, Name, Wohnort→Ort)
Ort
(Name)
Professor
(Name)
Assistent
(Name, Prof→Professor)
Betreuung
(Matrikelnr→Student, Name→Professor, FB→Fachbereich)
Fachbereich (FB)
- 69 -
Name
wohnt in
Student
Matrikelnr
Betreuung
Name
Professor
bei
Betreuung
Ort
Name
HAT
Fachbereich
Assistent
FB
Name
Wie in 3.3.8 erläutert, wird hier wegen des Fremdschlüssels „FB“ in „Betreuung“ eine
Aggregation gebildet, die neben der Beziehung „Betreuung“ alle beteiligten Entities,
also „Student“ und „Professor“, umfaßt. Obwohl es einem Anwender schon wegen der
Objektnamen einleuchtet, daß auch „Assistent“ zur Aggregation gehört, erkennt das
Verfahren dies nicht. Es ist dann Aufgabe des Nutzers, Aggregation „Betreuung“ zu
erweitern. Das Entity „Ort“ hingegen sollte nicht in die Aggregation eingebunden
werden.
Auch der nächste Schritt im Verfahren weist einige Probleme auf: Es ist semantisch
korrekt, eine „GLEICH“-Beziehung zu erzeugen, wenn die Primärschlüssel zweier
besonderer Entity-Relationen auf sich gegenseitig verweisen. Auch die Zuordnung der
gemeinsamen Primärschlüssel zur neu erzeugten Beziehung verletzt die Äquivalenz der
Schemata vor bzw. nach diesem Schritt noch nicht. In der Datenbank kann kein Zustand
erzeugt werden, zu dem das Zielschema nicht mehr äquivalent zum Quellschema ist.
Jedoch ist die Differenzierung zwischen den verschiedenen Generalisierungs-Typen vom
jeweiligen Datenbank-Zustand abhängig, da hier Anfragen zur Unterscheidung dienen.
Hält das Zielmodell die verschiedenen Generalisierungs-Typen auseinander, so kann
durch Einfügen weiterer Instanzen in die Datenbank ein Zustand erzeugt werden, zu dem
das Zielschema nicht mehr äquivalent zum Quellschema ist. Nur durch Nachbearbeitung
des Anwenders ist hier die semantische Korrektheit zu gewährleisten und zu verhindern,
daß in der Datenbank Zustände entstehen können, die im Zielschema nicht möglich sind.
- 70 -
Beispiel:
Es seien folgende Relationen und Tupel gegeben:
Person
Name
Rollert
Wehrhahn
Kunde
Name→Person
Wehrhahn
Rollert
Warenwert
3498,-540,--
Mitarbeiter Name→Person
Rollert
Gehalt
6000,--
(*)
Analog zum Beispiel in Kapitel 3.3.9 werden die Tabellen „Kunde“ und „Mitarbeiter“
als besondere Entity-Relationen klassifiziert. Der Algorithmus erzeugt daraus eine
Generalisierung:
Person
Gehalt
Mitarbeiter
Name
Kunde
Warenwert
Bei der Ermittlung des Generalisierungs-Typen soll zunächst davon ausgegangen
werden, daß das Tupel „(*)“ in Relation „Kunde“ nicht gespeichert ist. Die Anfragen
R1:={SELECT DISTINCT Name FROM Kunde}
R2:={SELECT DISTINCT Name FROM Mitarbeiter}
Z:={SELECT DISTINCT Name FROM Person}
liefern dann die Eigenschaften R1∩R2=∅ und Z=R1∪R2. Damit wird eine totale
exklusive Generalisierung erkannt und im Zielschema vermerkt. Wird jetzt aber das
(zulässige) Tupel „(*)“ in „Kunde“ eingefügt, so entsteht im Quellschema ein Zustand,
der im Zielschema nicht abgebildet werden kann. Der Anwender muß also den
Generalisierungs-Typ in „total und überlappend“ ändern. Um den Automatisierungsgrad
des Verfahrens nicht herabzusetzen, ist diese Änderung erst nach Umsetzung des
Schemas vorgesehen.
- 71 -
Ebenso müssen die Kardinalitäten, die in den Schritten „Alg9“ bzw. „Alg10“
ermittelt werden, durch den Anwender im Zielschema überprüft und gegebenenfalls
korrigiert werden. Denn auch hier werden Anfragen ausgeführt, um Informationen aus
der relationalen Datenbank zu gewinnen, die hinterher im EER-Schema zur Festlegung
von Kardinalitäten ausgewertet werden. Diese Anfragen liefern jedoch nur Vermutungen,
denn ihre Ergebnisse sind von den gespeicherten Instanzen, also dem DatenbankZustand, abhängig. Es handelt sich hier nicht um gesicherte Informationen, weshalb
dieser Teil des Verfahrens die semantische Korrektheit nicht gewährleistet. Die Menge
der möglichen Zustände in Quell- und Zielschema können differieren.
Beispiel:
Als Beispiel sollen folgende Relationen und Tupel betrachtet werden:
Kunde
(*)
Name
Wehrhahn
Rollert
Giesemann
Warenwert
1298,-762,-1155,--
Mitarbeiter Name
Gertz
Gehalt
7800,--
betreut
MName→Mitarbeiter
Gertz
Gertz
(*)
KName→Kunde
Rollert
Wehrhahn
„betreut“ ist eine reguläre Beziehungs-Relation. Aus ihr wird eine Beziehung zwischen
den Entities „Kunde“ und „Mitarbeiter“ erzeugt. Zur Ermittlung der Kardinalitäten an
dieser Beziehung werden folgende Anfragen ausgeführt:
Anf1)
SELECT COUNT(*) INTO z1 FROM Kunde
WHERE NOT EXISTS (SELECT KName FROM betreut
WHERE betreut.KName=Kunde.Name)
Anf2)
SELECT COUNT(*) INTO z2 FROM betreut GROUP BY KName
HAVING COUNT(*)>1
Anf3)
SELECT COUNT(*) INTO z3 FROM Mitarbeiter
WHERE NOT EXISTS (SELECT MName FROM betreut
WHERE betreut.MName=Mitarbeiter.Name)
- 72 -
Anf4)
SELECT COUNT(*) INTO z4 FROM betreut GROUP BY MName
HAVING COUNT(*)>1
Die ersten beiden Anfragen „Anf1“ und „Anf2“ dienen dabei der Festlegung der
Kardinalitäten auf der Seite von Entity „Kunde“, die anderen beiden helfen, die
Kardinalitäten auf der Seite von Entity „Mitarbeiter“ zu definieren. Wieder soll zunächst
ein Datenbank-Zustand zugrunde liegen, bei dem die Tupel „(*)“ in den Tabellen
„Kunde“ bzw. „betreut“ nicht gespeichert sind. Anfrage „Anf4“ liefert in diesem Fall als
Obergrenze für die Kardinalität zwischen „Mitarbeiter“ und „betreut“ das Ergebnis 1,
denn Feld „MName“ enthält dann nur eindeutige Werte. Untergrenze ist ebenfalls 1,
weil alle Einträge aus „Mitarbeiter.Name“ auch in „betreut.MName“ gespeichert sind.
Wird aber Tupel „(*)“ in „betreut“ eingefügt, so sind Quellschema und Zielschema
nicht mehr äquivalent zueinander, weil das Zielschema das Einfügen von Tupel „(*)“
nicht zuläßt. Deshalb muß die Obergrenze der Kardinalität bei „Mitarbeiter“ auf N
gesetzt werden. „Anf4“ liefert jetzt z4>1.
Auf der anderen Seite wird als Kardinalität (1,1) festgelegt, denn die
Anfrageergebnisse von „Anf1“ bzw. „Anf2“ sind z1=0 und z2<2. Wird auch in Relation
„Kunde“ das Tupel „(*)“ eingefügt, so liefert „Anf1“ z1>0 und das Verfahren ermittelt
Kardinalität (0,1).
Name
Mitarbeiter
Gehalt
(1,N)
betreut
(0,1)
Name
Kunde
Warenwert
Als Ergebnis erhält man aus dieser Betrachtung, daß Quellschema und Zielschema
nur unter bestimmten Bedingungen äquivalent zueinander sind. Die Entscheidungen, die
durch Anfragen im Verfahren gefällt werden, müssen durch den Anwender überprüft und
gegebenenfalls geändert werden, um die Semantik des Quellschemas zu erhalten. Erst
nach diesen (korrekten) Änderungen sind das ursprüngliche Relationenschema (mit
Ergänzungen des Nutzers) und das erzeugte EER-Schema äquivalent. Das Zielschema ist
dann bis auf die Benennung der Objekte korrekt - sowohl semantisch als auch
syntaktisch.
- 73 -
4 Algorithmus und Codierung
Aus dem im vorherigen Kapitel vorgestellten Algorithmus wurde im Rahmen dieser
Diplomarbeit ein Werkzeug entwickelt, das aus einem Oracle-Datenbank-Schema ein
EER-Schema erzeugt. Dieses Tool besteht aus mehreren Teil-Anwendungen, die
unterschiedliche Schemata in Form einer ASCII-Datei erzeugen. Durch die Anwendung
von Tools, die V.M. Markowitz und seine Mitarbeiter entwickelt haben, bestehen
weitere Möglichkeiten der Umsetzung. Einen Überblick über die Programme und
Schemata bietet folgendes Diagramm (neu-entwickelte Programme sind fett gedruckt):
OracleDB-Schema
ora2rel
RelationenSchema
rel2pre
PRE-Schema
rel2sdt
pre2sdt
SDT-Schema
sdt2erd
MarkowitzTools
(eergraph)
ERD-Schema
erdraw
ERDRAW
EER-Grafiktool
- 74 -
4.1 Markowitz-Tools
V.M. Markowitz hat mit einigen seiner Mitarbeiter Ende 1993 einige Tools veröffentlicht
[14,15,21], mit denen man ein Relationenschema in grafisch aufbereiteter Form darstellen
kann. Die Art der grafischen Darstellung ist der eines ER-Schemas (ohne Erweiterungen)
sehr ähnlich, jedoch werden Fremdschlüsselbeziehungen nicht über ein typisches
Beziehungs-Objekt, sondern durch eine direkte Verbindung zwischen den betreffenden
Entities dargestellt.
Das Verfahren, mit dem Markowitz ein Oracle- oder Sybase-Schema in ein ERSchema umsetzt, hat er in verschiedene Schritte unterteilt: Im ersten Schritt wird aus
dem jeweiligen Datenbank-System ein Schema ausgelesen und in eine ASCII-Datei
geschrieben. Das Programm „ora2rel“ läuft jedoch nicht einwandfrei, weil neuere OracleVersionen (ab Version 7) nicht unterstützt werden - eine Nachfrage bei V.M. Markowitz
hat ergeben, daß die Tools nicht weiter gepflegt werden. Man muß also die ASCII-Datei
mit dem Relationenschema selbst erstellen.
Der nächste Schritt wird durch das Programm „rel2sdt“ gelöst: Es bildet aus dem
Relationenschema ein sogenanntes SDT-Schema (Schema Design and Translation). In
diesem Programm steckt der eigentliche Algorithmus zum „Reverse Engineering“. Dabei
werden die Tabellen in zwei Klassen „Entity“ bzw. „Relationship“ unterteilt. Diese
Klassifizierung ist, wie bei den meisten in Kapitel 2 vorgestellten Verfahren, einzig von
dem Primärschlüssel der jeweiligen Relation abhängig: Enthält er ausschließlich
Attribute, die als Fremdschlüssel dienen, so bildet Markowitz aus der Tabelle eine
Beziehung, sonst wird ein Entity erstellt. Neben der verlangten Definition eines
Primärschlüssels
und
der
optionalen
Definition
von
Fremdschlüsseln
im
Relationenschema können auch Schlüsselkandidaten („alternate keys“) angegeben
werden. Ihre Definition hat allerdings keinerlei Auswirkungen auf das erstellte SDTSchema.
Das Programm „sdt2erd“ bereitet das so erzeugte SDT-Schema für die grafische
Darstellung mittels „erdraw“ vor.
Um
mit
Hilfe
der
Markowitz-Tools
aus
einem
Relationenschema
(abgewandeltes) ER-Schema zu erzeugen, sind also folgende Schritte notwendig:
ein
- 75 -
1. Relationenschema in bestimmter Form (siehe [15]) in eine Datei „<Dateiname>.rel“
schreiben.
2. „rel2sdt <Dateiname>.rel <Dateiname>.sdt“ aufrufen. Das entstandene SDTSchema kann gemäß Anhang A/c editiert werden.
3. „sdt2erd <Dateiname>.sdt <Dateiname>.erd“ aufrufen.
4. „erdraw“ starten und das Schema <Dateiname>.erd laden.
Ein ausführliches Beispiel ist in Kapitel 4.3 zu finden.
4.2 Programmentwicklung
Bei der eigenen Programmentwicklung ist es sinnvoll, sich an den Tools von Markowitz
zu orientieren. Aus Zeitgründen ist es nicht möglich, daß im Rahmen dieser Diplomarbeit
bereits ein Werkzeug programmiert wird, das ein EER-Schema grafisch darstellen kann.
Deshalb wird der in Kapitel 3 entwickelte Algorithmus ebenfalls in verschiedene Schritte
eingeteilt: „ora2rel“ ist ein Programm, das den Benutzer auffordert, sich bei einer OracleDatenbank anzumelden und ein Schema auszuwählen. Über Anfragen an das DataDictionary werden dann die gewählten Tabellen mit ihren Spalten und Indexen
ausgelesen. Der Benutzer hat anschließend die Möglichkeit, weitere Schlüsselkandidaten
und Fremdschlüssel einzugeben. Seine Eingaben werden von „ora2rel“ über DatenbankAnfragen überprüft und gegebenenfalls zurückgewiesen. Auch hat der Anwender die
Möglichkeit, aus der Menge der Schlüsselkandidaten selbst den Primärschlüssel
auszuwählen, der seiner Meinung nach am besten geeignet ist. Das System schlägt aber
dem Benutzer einen passenden Schlüsselkandidaten vor.
Das ermittelte Relationenschema wird abschließend in eine ASCII-Datei
geschrieben. Die Form der Speicherung ist der von Markowitz sehr ähnlich, es sind nur
die Angaben zur späteren Kardinalitäten-Ermittlung hinzugekommen. Die Backus-NaurForm des Relationenschemas ist in Anhang A/a zu finden.
Das Programm „rel2pre“ führt den eigentlichen (eigenen) „Reverse Engineering“Vorgang aus. Unter Ausnutzung der Informationen im Relationenschema wird ein
sogenanntes PRE-Schema (siehe Anhang A/b) erzeugt, das wiederum dem SDT-Schema
von Markowitz (siehe Anhang A/c) ähnlich ist. Hinter „rel2pre“ verbirgt sich der in
Kapitel 3 entwickelte Algorithmus. Jedoch werden auch von „rel2pre“ noch keine
- 76 -
Aggregationen erkannt und zwischen den verschiedenen Arten von Generalisierungen
wird noch nicht unterschieden, weil die Programmentwicklung dieser Funktionen den
zeitlichen Rahmen dieser Arbeit gesprengt hätte. Dennoch liefert das Programm
„rel2pre“ bessere Ergebnisse mit mehr Struktur-Informationen als „rel2sdt“ von
Markowitz: So werden beispielsweise bei „rel2sdt“ keine Fremdschlüssel-Beziehungen
gebildet. Stattdessen werden die in Beziehung stehenden Entities direkt durch eine Linie
miteinander verbunden. Außerdem werden keine Angaben über Kardinalitäten gemacht.
Dies wird noch in Kapitel 4.3 an einem Beispiel verdeutlicht.
Das PRE-Schema sollte zu einem späteren Zeitpunkt direkt als EER-Schema
ausgegeben werden. Wie bereits oben erwähnt, kann bis dahin „erdraw“ von Markowitz
zur grafischen Darstellung des Schemas herangezogen werden. Aus diesem Grund setzt
„pre2sdt“ das PRE-Schema in ein SDT-Schema um, das dann wie in Kapitel 4.1
weiterverarbeitet werden kann.
Bei Einsatz der neu entwickelten Programme „ora2rel“, „rel2pre“ und „pre2sdt“ ist
also folgende Vorgehensweise vorgesehen:
1. Mit „ora2rel <Dateiname>.rel“ aus einer Oracle-Datenbank ein Relationenschema
erzeugen.
2. „rel2pre <Dateiname>.rel <Dateiname>.pre“ aufrufen und so das
Relationenschema in ein EER-Schema umsetzen.
3. „pre2sdt <Dateiname>“ ausführen, um das Schema mit den Tools von Markowitz
weiterzuverarbeiten. Achtung: Informationsverlust! Kardinalitätsangaben gehen
verloren, aus Generalisierungen und schwachen Entities werden starke Entities.
4. „sdt2erd <Dateiname>.sdt <Dateiname>.erd“ aufrufen.
5. „erdraw“ starten und das Schema <Dateiname>.erd laden.
Ein ausführliches Beispiel ist in Kapitel 4.3 zu finden. Das Benutzerhandbuch steht in
Anhang B.
- 77 -
OracleDatenbank
RelationenSchema
PRESchema
SDTSchema
ERDSchema
erdraw
rel2pre
ora2rel
(Editor)
menu
eingabe
ora2eer
pre2sdt
rel2sdt
sdt2erd
MarkowitzTools
Einen Überblick über die Programme und Module bietet folgende Übersicht:
Aus dieser Abbildung ist ersichtlich, welche Programme von „ora2eer“ aufgerufen
werden und welche Schemata von welchen Programmen verarbeitet bzw. geschrieben
werden. Die beiden Module „eingabe“ (Anhang E/a, E/b) und „menu“ (Anhang E/c, E/d)
enthalten Routinen zur Ein-/Ausgabe und Menüsteuerung.
- 78 -
4.2.1 ora2rel
Das Programm „ora2rel“ beinhaltet den Teil des Verfahrens, der Anfragen an die
Datenbank und das Data-Dictionary stellt und viel Nutzerkommunikation verlangt. Der
Quellcode zu „ora2rel“ ist in Anhang E/e zu finden. Einen Überblick darüber, welche
Tabellen des Data-Dictionarys welche Struktur-Informationen liefern, verschafft das
folgende Diagramm:
ora2rel.pc:
(ORACLE-Data-Dictionary)
table_name
user_tables
num_rows
column_name
user_tab_columns
Tabelle
data_type
nullable
num_distinct
index_name
user_indexes
uniqueness
table_name
SchlüsselKandidat
constraint_type
user_constraints
constraint_name
r_constraint_name
user_ind_columns
column_name
user_cons_columns
column_name
FremdSchlüssel
- 79 -
Datenstrukturen:
rel:
ARRAY [1..MAX_REL] OF STRING;
In „rel“ werden die Relationnamen gespeichert.
(Zeile 40)
relation:
ARRAY [1..MAX_REL] OF RECORD
(Zeile 43-66)
In der Struktur „relation“ werden alle Informationen zu Tabellen gespeichert:
num_rows: INTEGER;
Anzahl der Datensätze
anz_col:
INTEGER;
Anzahl der Attribute
anz_idx:
INTEGER;
Anzahl der Indexe
anz_alt:
INTEGER;
Anzahl der Schlüsselkandidaten
anz_for:
INTEGER;
Anzahl der Fremdschlüssel
col_names: ARRAY [1..MAX_COL] OF STRING;
Namen der Attribute
col_num:
ARRAY [1..MAX_COL] OF INTEGER;
Anzahl der verschiedenen Attribut-Werte einer Spalte
col_null:
ARRAY [1..MAX_COL] OF BOOLEAN;
Erlaubt Attribut leere Einträge ?
col_type:
ARRAY [1..MAX_COL] OF STRING;
Datentypen der Attribute
idx_names: ARRAY [1..MAX_IDX] OF STRING;
Namen der Indexe
idx_unique: ARRAY [1..MAX_IDX] OF BOOLEAN;
Index vom Typ „unique“ ?
idx_typ:
ARRAY [1..MAX_IDX] OF CHAR;
Index-Typen (primary/foreign key oder zusätzlicher Index)
idx_col:
ARRAY [1..MAX_IDX] OF
ARRAY [1..MAX_IDX_COL] OF INTEGER;
Attributnummern, auf denen Index definiert ist
pri_key:
ARRAY [1.. MAX_IDX_COL] OF INTEGER;
Attributnummern der Felder, die Bestandteil des Primärschlüssels sind
alt_key:
ARRAY [1..MAX_IDX] OF
ARRAY [1..MAX_IDX_COL] OF INTEGER;
Attributnummern der Felder, die zu einem Schlüsselkandidaten gehören
- 80 -
for_key:
ARRAY [1..MAX_IDX] OF
ARRAY [1..MAX_IDX_COL] OF INTEGER;
Attributnummern der Felder, auf denen ein Fremdschlüssel definiert ist
for_ref:
ARRAY [1..MAX_IDX] OF STRING;
Namen der Tabellen, auf die die Fremdschlüssel zeigen
for_col:
ARRAY [1..MAX_IDX] OF
ARRAY [1..MAX_IDX_COL] OF STRING;
Attribute der Referenztabelle, auf die ein Fremdschlüssel verweist
for_null:
ARRAY [1..MAX_IDX] OF BOOLEAN;
Erlaubt Fremdschlüssel leere Einträge ?
for_uni:
ARRAY [1..MAX_IDX] OF BOOLEAN;
Sind die Einträge in den Fremdschlüsseln eindeutig („unique“) ?
for_alle:
ARRAY [1..MAX_IDX] OF BOOLEAN;
Sind alle Einträge in der Referenztabelle auch im Fremdschlüssel gespeichert ?
END;
Zentrale Algorithmen:
Nach dem Lesen der Indexe einer Tabelle werden diese daraufhin untersucht, ob sie
Primärschlüssel oder Schlüsselkandidaten beinhalten. Diese Aufgabe übernimmt die
Funktion „idx_exam“ (Zeile 249-274):
PROCEDURE idx_exam();
BEGIN
FOR i:=1 TO anz_idx DO
IF idx_typ[i]=‘P’ THEN
(* Primärschlüssel *)
<Kopiere Attribute aus idx_col[i] in pri_key>;
ELSE
IF idx_unique[i] THEN BEGIN
(* Schlüsselkandidat *)
anz_alt := anz_alt + 1;
<Kopiere Attribute aus idx_col[i] in alt_key[anz_alt]>;
(* Wenn alle Attr. NULL zulassen, verwerfe Kand. *)
IF col_null[<Alle Attribute aus idx_col[i]>] THEN
anz_alt := anz_alt - 1;
(* verwerfe Schl.kand. *)
END;
END;
- 81 -
Die Funktion „search_pk“ (Zeile 411-486) ermöglicht dem Anwender die Eingabe eines
Schlüsselkandidaten. Das System prüft über die in Kapitel 3.1 erläuterten Anfragen, ob
der Schlüsselkandidat die UNIQUE-Bedingung erfüllt. Wenn nicht, so wird der
Schlüsselkandidat als ungültig zurückgewiesen:
PROCEDURE search_pk();
VAR kand: <Menge von Attributen>;
BEGIN
<Eingabe Attribute des Schlüsselkandidaten (kand)>;
IF kand∈alt_key THEN BEGIN
Ausgabe(„Eingegebener Schlüsselkandidat ist bereits vorhanden.“);
RETURN;
END;
IF kand=pri_key THEN
Ausgabe(„Eingegebener Schlüsselkandidat ist Primärschlüssel.“);
RETURN;
END;
(* Prüfe auf UNIQUE, siehe Kapitel 3.1 *)
SELECT COUNT(*) INTO v_int FROM rel GROUP BY kand
HAVING COUNT(*)>1;
IF v_int>1 THEN
Ausgabe(„Schlüsselkandidat hat keine UNIQUE-Eigenschaft.“);
ELSE BEGIN
anz_alt := anz_alt + 1;
<Kopiere Attribute aus kand in alt_key[anz_alt]>;
END;
END;
Die Funktion „test_fk“ (Zeile 490-526) prüft über eine Datenbank-Anfrage, ob eine vom
Nutzer eingegebene Fremdschlüssel-Beziehung gültig ist. Dieser Funktion werden der
Fremdschlüsselkandidat, die Referenztabelle und die Namen der Attribute übergeben, auf
die der Fremdschlüssel verweist:
FUNCTION test_fk(fskand,reftab,refattr);
VAR fskand,refattr: <Menge von Attributen>;
VAR reftab: Tabelle;
BEGIN
IF Felderzahl(fskand) <> Felderzahl(refattr) THEN BEGIN
Ausgabe(„Unterschiedliche Anzahl an Feldern“);
RETURN;
END;
- 82 -
(* Prüfe auf Fremdschlüssel, siehe Kapitel 3.1 *)
SELECT COUNT(*) INTO v_int FROM rel WHERE NOT EXISTS
(SELECT refattr FROM reftab WHERE reftab.refattr=rel.fskand);
IF SQL-Fehler THEN
Ausgabe(„Ungültige Attribut-Namen eingegeben“);
ELSE IF v_int>0 THEN
(* In fskand sind Daten, die nicht in reftab.refattr vorkommen *)
Ausgabe(„Keine gültige Fremdschlüssel-Beziehung“);
ELSE
RETURN <gültiger Fremdschlüssel>;
END;
„test_fk“ wird von Funktion „search_fk“ (Zeile 529-723) aufgerufen, die den Anwender
einen Fremdschlüssel eingeben läßt und prüft, ob der neu eingegebene Fremdschlüssel
bereits vorher definiert wurde. Außerdem hat der Benutzer die Möglichkeit, das System
nach gleichnamigen Attributen suchen zu lassen:
PROCEDURE search_fk();
VAR fskand,refattr: <Menge von Attributen>;
VAR reftab: Tabelle;
VAR merktabs: <Menge von Tabellen>;
BEGIN
<Eingabe Attribute des Fremdschlüsselkandidaten (fskand)>;
IF fskand∈for_key THEN
Ausgabe(„Warnung: Feldkombination ist bereits Fremdschlüssel.“);
reftab := <Menü-Auswahl der Referenztabelle>;
IF reftab∉rel THEN BEGIN
(* Automatische Suche nach gleichnamigen Attributen *)
refattr := fskand;
<Schreibe fskand in temporäre Tabelle>;
SELECT table_name INTO merktabs FROM user_tables
WHERE NOT EXISTS (
(SELECT fskand FROM temporäre_Tabelle)
MINUS
(SELECT column_name FROM user_tab_columns
WHERE table_name=user_tables.table_name)
)
<Lösche temporäre Tabelle>;
FOR <jede Tabelle tab∈merktabs> DO
IF (test_fk(fskand,tab,fskand)) <> <gültiger Fremdschlüssel>
THEN <lösche tab aus merktabs>;
- 83 -
IF merktabs=0 THEN BEGIN
Ausgabe(„Keine Relation gefunden.“);
RETURN;
END ELSE IF merktabs=1 THEN
reftab := merktabs[1];
ELSE
reftab := <Menü-Auswahl der Referenztabelle aus merktabs>;
END ELSE BEGIN
(* Eingabe der Referenzattribute *)
<Eingabe Attribute der Referenztabelle (refattr)>;
IF (test_fk(fskand,reftab,refattr)) <> <gültiger Fremdschlüssel>
THEN BEGIN
Ausgabe(„DB-Zustand widerspricht FS-Vermutung.“);
RETURN;
END;
END;
IF (<Fremdschlüssel schon vorhanden>) THEN
Ausgabe(„Fremdschlüssel ist bereits vorhanden.“);
ELSE BEGIN
anz_for := anz_for + 1;
for_ref[anz_for] := reftab;
<Kopiere Attribute aus fskand in for_key[anz_for]>;
IF col_null[<Alle Attribute aus for_key[anz_for]>] THEN
for_null[anz_for] := TRUE;
ELSE
for_null[anz_for] := FALSE;
<Kopiere Attribute aus refattr in for_col[anz_for]>;
END;
END;
Die Funktion „pk_choose“ (Zeile 727-808) wird an zwei verschiedenen Stellen des
Programmes „ora2rel“ aufgerufen: Beim ersten Aufruf legt das System eigenständig
einen Primärschlüssel fest, bei weiteren Aufrufen kann der Anwender aus der Menge der
Schlüsselkandidaten den Primärschlüssel selbst bestimmen. Um diese unterschiedlichen
Modi zu gewährleisten, wird „pk_choose“ der gewünschte Modus übergeben:
PROCEDURE pk_choose(mode);
VAR merk: Schlüsselkandidat;
BEGIN
IF <Primärschlüssel definiert> THEN BEGIN
(* Primärschlüssel als Schlüsselkand. merken *)
anz_alt := anz_alt + 1;
- 84 -
<Kopiere Attribute aus pri_key in alt_key[anz_alt]>;
END;
IF anz_alt<1 THEN BEGIN
Ausgabe(„Kein Schl.kand. vorhanden. Verwende ganze Tab. als PS!“);
pri_key := <Alle Tabellenfelder>;
END ELSE BEGIN
(* Suche des besten Schlüsselkandidaten (Kriterien siehe 3.1) *)
merk := alt_key[1];
FOR <jeden Schlüsselkandidaten kand∈alt_key> DO BEGIN
IF (<kand hat weniger Nicht-Fremdschlüsselattr. als merk>)
OR ((<kand, merk haben gleichviele Nicht-Fremdschl.attr.>)
AND (<kand hat insgesamt weniger Attr. als merk>))
THEN merk := kand;
END;
(* Auswahl eines Schlüsselkandidaten *)
IF (anz_alt>1) AND (mode<>automatisch) THEN BEGIN
Ausgabe(„Empfehle die Wahl des Schl.kand. “, merk);
merk := <Menü-Auswahl des Primärschlüssels>;
END;
(* Verschiebe Schl.kand. merk in Primärschlüssel *)
<Kopiere Attribute aus merk in pri_key>;
<Lösche merk aus alt_key>;
anz_alt := anz_alt - 1;
END;
END;
Funktion „test_all“ (Zeile 812-821) ermittelt mit Hilfe einer Anfrage, ob die AttributWerte in einer Referenztabelle alle als Attribut-Werte in einem Fremdschlüssel auftreten.
Dies ermöglicht später die Festlegung von Kardinalitäten. „test_all“ werden dazu der
Name der Tabelle mit dem Fremdschlüssel, die Fremdschlüsselattribute, der Name der
Referenztabelle sowie die Referenzattribute übergeben:
FUNCTION test_all(orgtab,orgcol,reftab,refcol);
VAR orgtab,reftab: Tabelle;
VAR orgcol,refcol: <Menge von Attributen>;
BEGIN
SELECT COUNT(*) INTO v_int FROM reftab WHERE NOT EXISTS
(SELECT orgcol FROM orgtab WHERE orgtab.orgcol=reftab.refcol);
IF v_int=0 THEN
RETURN <Alle Werte aus reftab in orgtab>;
END;
- 85 -
„test_all“ wird innerhalb der Funktion „analyze“ (Zeile 825-876) aufgerufen. Mit dieser
Funktion werden alle Informationen gesammelt, die später der Festlegung der
Kardinalitäten dienen:
PROCEDURE analyze();
BEGIN
FOR i:=1 TO anz_for DO BEGIN
(* UNIQUE-Eigenschaft der FS über Vergleich mit Schl.kand. *)
IF (for_key[i]=pri_key) OR (for_key[i]∈alt_key) THEN
for_uni[i] := TRUE;
ELSE
for_uni[i] := FALSE;
(* Aufruf der Funktion test_all *)
IF test_all(rel,for_key[i],for_ref[i],for_col[i])=
<Alle Werte von reftab in orgtab> THEN
for_alle[i] := TRUE;
ELSE
for_alle[i] := FALSE;
END;
END;
Eine Übersicht über den Ablauf des Programmes „ora2rel“ liefern die folgenden
Abbildungen:
- 86 -
conn
ora2rel.pc:
(Anmeldung bei Oracle,
Eingabe des
auszuwertenden Schemas)
eingabe
tab_read
(Tabellennamen aus dem
angegebenen Schema
auslesen)
Oracle-Analyse
durchführen ?
ora2eer_schema
user_tables
tab_analyze
Ja
(Tabellen mit dem OracleKommando "analyze"
analysieren)
user_tables
Nein
Für jede Tabelle des
Schemas tue
user_tab_columns
tab_exam
(Tabellen-Eigenschaften
bestimmen, Spalten und
Indexe lesen)
user_indexes
user_constraints
idx_exam
(Indexe analysieren)
user_ind_columns
fk_read
(Fremdschlüssel lesen:
Referenztabelle und
-spalten ermitteln)
Primärschlüssel
vorhanden ?
user_cons_columns
pk_choose
Nein
(System legt aus Menge
von Schl.kand. den
Primärschlüssel fest)
Ja
analyze
(Anfragen für spätere
KardinalitätenBestimmung ausführen)
Datenbank
(Schleifenende)
new_exam
eingabe
(Benutzer wählt
Tabelle aus, für die er
weitere Schlüssel
eingeben möchte)
schema_write
(Relationen-Schema in
Datei schreiben)
menu
Aus Datenbank
abmelden
- 87 -
ora2rel.pc:
(Unterprogramm new_exam)
Beginn new_exam
Wähle Tabelle aus
Programmende
gewählt ?
Nein
search_pk
(Benutzer gibt mögliche
Schl.kand. ein, Programm
prüft Vermutung)
menu
search_fk
Ja
(Benutzer gibt mögliche
Fremdschl. ein, Programm
prüft Vermutung)
eingabe
pk_choose
(Benutzer wählt aus
Menge von Schl.kand. den
Primärschlüssel aus)
analyze
(Anfragen für spätere
KardinalitätenBestimmung ausführen)
(Schleifenende)
Ende new_exam
Datenbank
- 88 -
4.2.2 rel2pre
Das Programm „rel2pre“ setzt ein aus „ora2rel“ gewonnenes Relationenschema in ein
EER-Schema (PRE-Schema) um. Der Quellcode ist in Anhang E/f nachzuschlagen. Die
Algorithmus-Schritte aus Kapitel 3.3 sind hier wiederzufinden.
Datenstrukturen:
TYPE RELKL = (ser,wer,ber,rbr,sbr);
(Zeile 30)
Relationenklassen bei der Klassifizierung: Starke Entity-Relation, schwache (Weak) EntityRelation, Besondere Entity-Relation, Reguläre Beziehungs-Relation, Spezielle BeziehungsRelation.
TYPE COLKL = (psa,fsa,pfsa,nsa);
(Zeile 33)
Attributklassen bei der Klassifizierung: PrimärSchlüsselAttribut, FremdSchlüsselAttribut,
Primär- und FremdSchlüsselAttribut, NichtSchlüsselAttribut.
TYPE OBJKL = (ent,went,bez,wbez,gen,gbez,fsbez);
(Zeile 36)
Objektklassen eines EER-Schemas: ENTity, Weak ENTity, BEZiehung, Weak BEZiehung
(Beziehung zwischen Weak Entity und Eigentümer), GENeralisierung, GeneralisierungsBEZiehung (1:1-Bez. zwischen Ent., die aus BERs entstanden sind), FremdSchlüsselBEZiehung.
TYPE FKY = RECORD
(Zeile 39-46)
Struktur zur Speicherung von referentiellen Abhängigkeiten / Fremdschlüsseln
anz_col:
INTEGER;
Anzahl der Fremdschlüsselfelder
orgcolnr:
ARRAY [1..MAX_FKY_COL] OF INTEGER;
Attributnummern der Fremdschlüsselfelder
orguni:
BOOLEAN;
Einträge im Fremdschlüssel eindeutig (UNIQUE) ?
refrelnr:
INTEGER;
Nummer der Referenzrelation
refcolnr:
ARRAY [1..MAX_FKY_COL] OF INTEGER;
Attributnummern der Referenzfelder in der Referenztabelle
refuni:
BOOLEAN;
Alle Attribut-Werte der Referenzfelder auch in den Fremdschlüsselattributen ?
END;
- 89 -
TYPE COL = RECORD
Struktur zur Speicherung von Tabellen-Spalten
(Zeile 49-55)
name:
STRING;
Attributname
type:
STRING;
Datentyp der Spalte
null:
BOOLEAN;
Sind leere Einträge erlaubt ?
schl:
INTEGER;
Schlüsselinformation über das Feld: Ungerader Wert => Primärschlüsselattribut,
Wenn Spalte zum Schl.kand. Nr. i gehört, so gilt: schl:=schl+2i
klasse:
COLKL;
Attributklasse, der das Feld bei der Klassifizierung zugeordnet wird
END;
TYPE REL = RECORD
Struktur zur Speicherung von Relationen
(Zeile 58-66)
name:
STRING;
Name der Tabelle
anz_col:
INTEGER;
Anzahl der Tabellen-Spalten
spalte:
ARRAY [1..MAX_COL] OF COL;
Informationen über die Attribute
anz_ref:
INTEGER;
Anzahl der Fremdschlüssel
fs:
ARRAY [1..MAX_FKY] OF FKY;
Informationen über die Fremdschlüssel
klasse:
RELKL;
Relationenklasse, der die Tabelle bei der Klassifizierung zugeordnet wird
objnr:
INTEGER;
Nummer des zugehörigen EER-Objektes
END;
- 90 -
TYPE OBJ = RECORD
(Zeile 69-77)
Struktur zur Speicherung der EER-Objekte, die aus den Relationen erzeugt werden
name:
STRING;
Name des Objektes
klasse:
OBJKL;
EER-Klasse des Objektes
relnr:
INTEGER;
Nummer der Relation, aus der Objekt entstanden ist
anz_ref:
INTEGER;
Anzahl der Verbindungen / Abhängigkeiten zu anderen Objekten
refobjnr:
ARRAY [1..MAX_OBJ] OF INTEGER;
Nummern derjenigen Objekte, mit denen Objekt verbunden ist
kard:
ARRAY [1..MAX_OBJ] OF INTEGER;
Kardinalitäten an den Verbindungen von Beziehungen bzw. Generalisierungen:
1=(0,1);2=(0,n);11=(1,1);12=(1,n);99=Gen
komm:
STRING;
Kommentarzeile
END;
rel_anz:
INTEGER;
Anzahl der gespeicherten Relationen
(Zeile 80)
rel:
ARRAY [1..MAX_REL] OF REL;
Gespeicherte Relationen
(Zeile 81)
obj_anz: INTEGER;
Anzahl der erzeugten EER-Objekte
(Zeile 84)
obj:
ARRAY [1..MAX_OBJ] OF OBJ;
Erzeugte EER-Objekte
(Zeile 85)
Zentrale Algorithmen:
Mit Hilfe der Funktion „schema_lesen“ (Zeile 113-353) wird aus einer Datei ein
Relationenschema eingelesen. Während des Einlesens werden alle Attribute einer Tabelle
implizit klassifiziert. Hier soll nur das Vorgehen bei dieser Klassifizierung angegeben
werden:
PROCEDURE schema_lesen();
BEGIN
<Lies Zeile aus Datei>;
IF <Zeile enthält Attributdefinition> THEN BEGIN
rel[rel_anz].anz_col := rel[rel_anz].anz_col + 1;
- 91 -
rel[rel_anz].spalte[anz_col] := <Informationen aus Zeile>;
END;
IF <Zeile enthält Primärschlüsseldefinition> THEN
FOR feld∈PRIMARY_KEY DO
rel[rel_anz].spalte[feld].klasse := psa;
IF <Zeile enthält Schlüsselkandidatendefinition> THEN
FOR feld∈ALTERNATE_KEY DO
<Merke Schl.kand.nr. in rel[rel_anz].spalte[feld].schl>;
IF <Zeile enthält Fremdschlüsseldefinition> THEN BEGIN
FOR feld∈FOREIGN_KEY DO
<Merke „Fremdschl.attr.“ in rel[rel_anz].spalte[feld].klasse>;
rel[rel_anz].anz_ref := rel[rel_anz].anz_ref + 1;
<Kopiere Fremdschl.-Informationen in rel[rel_anz].fs[anz_ref]>
END;
END;
Nach dem Einlesen des Schemas werden die Relationen mit der Funktion „schema_klass“
(Zeile 356-401) klassifiziert:
PROCEDURE schema_klass();
BEGIN
FOR i:=1 TO rel_anz DO BEGIN
CASE
<PS von rel[i] enthält keinen FS>:
rel[i].klasse := ser;
<PS von rel[i] besteht aus genau einem FS>:
rel[i].klasse := ber;
<PS von rel[i] besteht ausschließlich aus (mehreren) FS>:
rel[i].klasse := rbr;
<PS von rel[i] enthält nur einen FS (und weitere Attr.)>:
rel[i].klasse := wer;
<PS von rel[i] enthält mehrere FS (und weitere Attr.)>:
rel[i].klasse := sbr;
END;
END;
END;
- 92 -
Die Funktion „fs_erz“ (Zeile 424-456) erzeugt eine Fremdschlüsselbeziehung zwischen
zwei Entities. Dazu werden zwei Parameter übergeben, in denen die Nummern der
Relationen stehen, aus denen diese beiden Entities entstanden sind. Außerdem dient die
Nummer des behandelten Fremdschlüssels der Ursprungstabelle als dritter Parameter:
PROCEDURE fs_erz(urtab,reftab,fsnr);
VAR urtab,reftab: Tabellennr;
VAR fsnr: <Fremdschlüsselnr aus urtab>;
BEGIN
IF rel[urtab].fs[fsnr]∈<PS von rel[urtab]> THEN
RETURN;
(* FS ist Teil des PS *)
ELSE BEGIN
(* Erzeuge neues Objekt *)
obj_anz := obj_anz + 1;
obj[obj_anz].name := „HAT“;
obj[obj_anz].klasse := fsbez;
(* Festlegen der Verbindungen *)
obj[obj_anz].anz_ref := 2;
obj[obj_anz].refobjnr[1] := rel[urtab].objnr; (* Objekt aus urtab *)
obj[obj_anz].refobjnr[2] := rel[reftab].objnr; (* Objekt aus reftab *)
(* Festlegen der Kardinalitäten *)
IF <rel[urtab].fs[fsnr] erlaubt leere Einträge> THEN
obj[obj_anz].kard[1] := <(0,1)>;
ELSE
obj[obj_anz].kard[1] := <(1,1)>;
CASE
rel[urtab].fs[fsnr].orguni AND rel[urtab].fs[fsnr].refuni:
obj[obj_anz].kard[2] := <(1,1)>;
NOT (rel[urtab].fs[fsnr].orguni OR rel[urtab].fs[fsnr].refuni):
obj[obj_anz].kard[2] := <(0,n)>;
NOT (rel[urtab].fs[fsnr].orguni) AND rel[urtab].fs[fsnr].refuni:
obj[obj_anz].kard[2] := <(1,n)>;
rel[urtab].fs[fsnr].orguni AND NOT (rel[urtab].fs[fsnr].refuni):
obj[obj_anz].kard[2] := <(0,1)>;
END;
END;
END;
- 93 -
Die Umsetzung des Relationenschemas in ein EER-Schema geschieht in der Funktion
„schema_umsetz“ (Zeile 459-599):
PROCEDURE schema_umsetz();
VAR m,n: INTEGER; (* Relationennummer *)
BEGIN
(* ### 1. PASS: Erstellen der EER-Objekte *)
FOR i:=1 TO rel_anz DO BEGIN
obj_anz := obj_anz + 1;
(* Relation wird zugehöriges Objekt zugeordnet *)
IF rel[i].klasse=sbr THEN
rel[i].objnr := obj_anz + 1;
ELSE
rel[i].objnr := obj_anz;
(* Objekt bekommt gleichen Namen wie Relation *)
obj[obj_anz].name := rel[i].name;
obj[obj_anz].relnr := i;
obj[obj_anz].anz_ref := 0;
IF (rel[i].klasse=ser) OR (rel[i].klasse=ber) THEN
obj[obj_anz].klasse := ent;
ELSE IF (rel[i].klasse=wer) THEN
obj[obj_anz].klasse := went;
ELSE
obj[obj_anz].klasse := bez;
IF rel[i].klasse=wer THEN BEGIN
(* Eigentümer-Beziehung erzeugen *)
obj_anz := obj_anz + 1;
obj[obj_anz].name := „ABHAENGIG“;
obj[obj_anz].relnr := i;
obj[obj_anz].klasse := wbez;
obj[obj_anz].anz_ref := 1;
obj[obj_anz].refobjnr[1] := obj_anz - 1;
(* Objektnr. des weak Entities *)
obj[obj_anz].kard[1] := <(1,1)>;
END;
IF rel[i].klasse=sbr THEN BEGIN
obj[obj_anz].klasse := bez;
obj[obj_anz].anz_ref := 1;
obj[obj_anz].refobjnr[1] := obj_anz + 1;
(* Objektnr. des neuen Entities *)
obj[obj_anz].kard[1] := <1,n>;
(* spezielles Entity erzeugen *)
obj_anz := obj_anz + 1;
obj[obj_anz].name := „SPEZIELL“;
- 94 -
obj[obj_anz].relnr := i;
obj[obj_anz].klasse := ent;
obj[obj_anz].anz_ref := 0;
END;
END;
(* ### 2. PASS: Erstellen der Verknüpfungen *)
FOR i:=1 TO obj_anz DO BEGIN
m := obj[i].relnr;
FOR j:=1 TO rel[m].anz_ref DO BEGIN
n := rel[m].fs[j].refrelnr;
CASE
(* SER können nur über FS Verknüpfungen haben *)
rel[m].klasse=ser:
fs_erz(m,n,j);
(* WER haben zusätzlich im PS Verweis auf Eigentümer *)
rel[m].klasse=wer:
IF (obj[i].klasse=wbez) AND (<FS Nr. j∈PS>) THEN
BEGIN
obj[i].anz_ref := obj[i].anz_ref + 1;
obj[i].refobjnr[obj[i].anz_ref] := rel[n].objnr;
obj[i].kard[obj[i].anz_ref] := <(0,1)>;
END ELSE
IF obj[i].klasse=wbez THEN
(* wbez enthält keine Attribute *)
;
ELSE (* FS für weak Entity *)
fs_erz(m,n,j);
(* Beziehungen bilden *)
(rel[m].klasse=rbr) OR (rel[m].klasse=sbr):
IF (obj[i].klasse=bez) AND (<FS Nr. j∈PS>) THEN
BEGIN
obj[i].anz_ref := obj[i].anz_ref + 1;
obj[i].refobjnr[obj[i].anz_ref] := rel[n].objnr;
(* Kardinalität ermitteln *)
CASE
rel[m].fs[j].orguni AND rel[m].fs[j].refuni:
obj[i].kard[obj[i].anz_ref] := <(1,1)>;
NOT (rel[m].fs[j].orguni OR rel[m].fs[j].refuni):
obj[i].kard[obj[i].anz_ref] := <(0,n)>;
NOT (rel[m].fs[j].orguni) AND rel[m].fs[j].refuni:
obj[i].kard[obj[i].anz_ref] := <(1,n)>;
rel[m].fs[j].orguni AND NOT (rel[m].fs[j].refuni):
obj[i].kard[obj[i].anz_ref] := <(0,1)>;
END;
- 95 -
END ELSE
IF (obj[i].klasse=bez) AND (rel[m].klasse=sbr) THEN
(* Die aus sbr erzeugte Bez. enthält keine Attribute *)
;
ELSE
fs_erz(m,n,j);
(* Generalisierungen ? *)
rel[m].klasse=ber:
IF (<FS Nr. j∈PS>) THEN BEGIN
(* Ist referenzierte Tabelle auch ber ? *)
IF (rel[n].klasse=ber) AND
(<PS von rel[n] verweist auf rel[m]>) THEN
(* 1:1-Beziehung schon erstellt ? *)
IF m<n THEN BEGIN
(* Erstelle Beziehung mit Kard. (1,1) *)
obj_anz := obj_anz + 1;
obj[obj_anz].name := „GLEICH“;
obj[obj_anz].klasse := gbez;
obj[obj_anz].relnr := n;
obj[obj_anz].anz_ref := 2;
obj[obj_anz].refobjnr[1] := i;
obj[obj_anz].refobjnr[2] := rel[n].objnr;
obj[obj_anz].kard[1] := <(1,1)>;
obj[obj_anz].kard[2] := <(1,1)>;
END ELSE ;
ELSE
(* Klasse der Reftab. ungleich ber *)
IF rel[n].klasse<>rbr THEN BEGIN
(* Generalisierung *)
obj[i].klasse := gen;
obj[i].anz_ref := obj[i].anz_ref + 1;
obj[i].refobjnr[obj[i].anz_ref] := rel[n].objnr;
obj[i].kard[obj[i].anz_ref] := <General.>;
END ELSE ;
END ELSE
(* FS Nr. j∉PS *)
fs_erz(m,n,j);
END; (* CASE *)
END;
END;
END;
- 96 -
Beim Schreiben des so erzeugten PRE-Schemas in eine Datei mit Hilfe der Funktion
„schema_schreiben“ (Zeile 602-697) muß jetzt nur noch beachtet werden, daß die
Attribute der Relationen den richtigen Objekten zugeordnet werden:
PROCEDURE schema_schreiben();
BEGIN
FOR i:=1 TO obj_anz DO BEGIN
<Schreibe Datei(obj[i].name)>;
CASE obj[i].klasse OF
ent:
<Schreibe Datei(„Typ Entity“)>;
bez: <Schreibe Datei(„Typ Beziehung“)>;
went: <Schreibe Datei(„Typ schwaches Entity“)>;
wbez: <Schreibe Datei(„Typ schwache Beziehung“)>;
gen: <Schreibe Datei(„Typ Generalisierung“)>;
gbez: <Schreibe Datei(„Typ Beziehung“)>;
fsbez: <Schreibe Datei(„Typ Beziehung“)>;
END;
(* Bestimmte Beziehungstypen dürfen keine Attribute enthalten *)
(* (Sonderfall: Eine aus rbr erzeugte Bez. kann Attr. enthalten) *)
IF (obj[i].klasse<>wbez) AND (obj[i].klasse<>fsbez) AND
((obj[i].klasse<>bez) OR (rel[obj[i].relnr].klasse<>sbr)) THEN
BEGIN
FOR j:=1 TO rel[obj[i].relnr].anz_col DO
(* Beachte Sonderfall, daß eine „GLEICH“-Bez. erstellt *)
(* wurde: Gemeinsame Attr. werden Bez. zugeordnet! *)
(* Sonst können alle (p)fsa vergessen werden *)
IF ((obj[i].klasse<>gbez) AND
((rel[obj[i].relnr].spalte[j].klasse=psa) OR
(rel[obj[i].relnr].spalte[j].klasse=nsa))) OR
((obj[i].klasse=gbez) AND
(rel[obj[i].relnr].spalte[j].klasse=pfsa)) THEN
<Schreibe Datei(rel[obj[i].relnr].spalte[j])>;
END;
<Schreibe alle obj[i].anz_ref Verknüpfungen von obj[i] in Datei>;
END;
END;
- 97 -
Die folgende Darstellung faßt den Funktionsablauf in „rel2pre“ zusammen:
rel2pre.c:
schema_lesen
(Relationen-Schema mit
Spalten und Schlüsseln
aus Datei lesen, Attribute
klassifizieren)
Relationen-Schema
schema_klass
(Relationen in
Abhängigkeit ihres
Primärschl. klassifizieren)
schema_umsetz
fs_erz
(Relationen in EERObjekte umsetzen,
Verknüpfungen und
Kardinalitäten bilden)
(FremdschlüsselBeziehungen erzeugen)
schema_schreiben
(EER-Objekte als PRESchema in Datei ablegen)
Dateien schließen
4.2.3 Übrige Programme
„pre2sdt“ setzt ein erzeugtes PRE-Schema in ein SDT-Schema um. Für diese Aufgabe
wurde ein SED-Script erstellt, dessen Quelle in Anhang E/h zu finden ist.
„ora2eer“ (Anhang E/g) stellt dem Anwender ein Hauptmenü zur Verfügung, aus
dem heraus er alle anderen Programm-Teile aufrufen kann.
Das
SQL-Script
„crschema.sql“
(Anhang
E/i)
erzeugt
eine
Tabelle
„ora2eer_schema“, in der ein Anwender das zu bearbeitende Schema eintragen kann.
Dazu muß jeweils in das Feld „Schema“ ein vom Anwender zu bestimmender SchemaName und in „Tabelle“ ein zugehöriger Tabellennamen eingetragen werden.
Die übrigen erwähnten Programme von Markowitz sind in [14,15,21] dokumentiert.
- 98 -
4.3 Fallstudie: Umsetzung einer Studenten-Datenbank
In diesem Kapitel wird ein Ausschnitt aus der relationalen Studenten-Datenbank der HIS
GmbH in ein EER-Schema umgesetzt. Wir betrachten dabei dieselben Relationen, die
schon in Kapitel 2 als Beispiel dienten:
• SOS
(MtkNr, Semester, Status, Name, Strasse, Ort, Staat,
HmKfzKz, HmKfz, ImmDat, RueDat, ExmDat, ExmGrund)
• STG
(MtkNr, Semester, StgNr, Status, Stg, Abschl, BeuGrund,
EndeGrd)
• K_STG
(Stg, Ktxt, Dtxt, AStat)
• K_ABINT
(Abschl, Ktxt, Dtxt, AStat)
• K_ABSTG
(Stg, Abschl)
• K_AKFZ
(AKfz, Ktxt, Dtxt, AStat, EGMitgl)
• K_IKFZ
(IKfz, Ktxt, Dtxt, AStat)
• K_GDEX
(GdEx, Ktxt, Dtxt, AStat)
• K_GDBU
(GdBu, Ktxt, Dtxt, AStat)
4.3.1 Vorbereitung
Mit dem folgenden SQL-Script werden die genannten Tabellen und die entsprechenden
Indexe in der Datenbank angelegt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE
abschl
ktxt
dtxt
astat
);
CREATE TABLE
stg
abschl
);
CREATE TABLE
akfz
ktxt
dtxt
astat
egmitgl
);
k_abint(
VARCHAR2(2) not null,
VARCHAR2(10),
VARCHAR2(25),
VARCHAR2(2) not null
k_abstg(
VARCHAR2(3) not null,
VARCHAR2(2) not null
k_akfz(
VARCHAR2(3) not null,
VARCHAR2(10),
VARCHAR2(25),
VARCHAR2(3),
VARCHAR2(1)
- 99 -
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
CREATE TABLE k_gdbu(
gdbu
VARCHAR2(1) not null,
ktxt
VARCHAR2(10),
dtxt
VARCHAR2(25),
astat
VARCHAR2(1)
);
CREATE TABLE k_gdex(
gdex
VARCHAR2(2) not null,
ktxt
VARCHAR2(10),
dtxt
VARCHAR2(25),
astat
VARCHAR2(1)
);
CREATE TABLE k_ikfz(
ikfz
VARCHAR2(4) not null,
ktxt
VARCHAR2(10),
dtxt
VARCHAR2(25),
astat
VARCHAR2(5)
);
CREATE TABLE k_stg(
stg
VARCHAR2(3) not null,
ktxt
VARCHAR2(10),
dtxt
VARCHAR2(25),
astat
VARCHAR2(4)
);
CREATE TABLE sos(
MtkNr
INTEGER not null,
Semester
SMALLINT,
Status
VARCHAR2(01),
Name
VARCHAR2(35),
Strasse
VARCHAR2(30),
Ort
VARCHAR2(25),
Staat
VARCHAR2(03),
HmKfzKz
VARCHAR2(01),
HmKfz
VARCHAR2(04),
ImmDat
VARCHAR2(10),
RueBeuDat VARCHAR2(10),
ExmDat
VARCHAR2(10),
ExmGrund
VARCHAR2(02)
);
CREATE TABLE stg(
MtkNr
INTEGER not null,
Semester
SMALLINT not null,
StGNr
VARCHAR2(02) not null,
Status
VARCHAR2(01),
StG
VARCHAR2(03) not null,
Abschl
VARCHAR2(02),
BeuGrund
VARCHAR2(01),
EndeGrd
VARCHAR2(02)
);
CREATE UNIQUE INDEX i_k_abint ON k_abint
CREATE UNIQUE INDEX i_k_abstg ON k_abstg
CREATE UNIQUE INDEX i_k_akfz ON k_akfz
CREATE UNIQUE INDEX i_k_gdbu ON k_gdbu
CREATE UNIQUE INDEX i_k_gdex ON k_gdex
CREATE UNIQUE INDEX i_k_ikfz ON k_ikfz
CREATE UNIQUE INDEX i_k_stg
ON k_stg
CREATE UNIQUE INDEX i_sos
ON sos
CREATE UNIQUE INDEX i_ustg
ON stg
(abschl);
(abschl,stg);
(akfz);
(gdbu);
(gdex);
(ikfz);
(stg);
(MtkNr) ;
(MtkNr,Semester,StGNr);
- 100 -
Anschließend werden einige Datensätze in die Tabellen geladen. Die Daten stammen
dabei aus einer Test-Datenbank der HIS. Einige Instanzen wichtiger Attribute sind in
Anhang D aufgeführt.
4.3.2 Programmstart
Zur Umsetzung der auf diese Weise erzeugten Relationen wird nun das Programm
„ora2eer“ gestartet, das folgendes Hauptmenü auf dem Bildschirm anzeigt:
Hier wird zuerst Menüpunkt „1“ („Dateiname ändern“) gewählt, um den Namen der
Ausgabedatei zu ändern.
Durch Wahl von Punkt „2“ („Oracle-Schema in Relationenschema umsetzen (ora2rel)“)
gelangt man in das Programm „ora2rel“.
- 101 -
4.3.3 Relationenschema erstellen
Nach der Anmeldung an das Oracle-System und der Eingabe des auszuwertenden
Schemas wird hier die Frage, ob Oracle auf jeder Tabelle das „analyze“-Kommando
ausführen soll, mit „j“ bestätigt.
„ora2rel“ liest nun aus dem Data-Dictionary die oben genannten Relationen mit ihren
Attributen und Indexen ein. Weil keine Primärschlüssel definiert wurden, diese aber im
Relationenschema verlangt werden, verwendet das System bei jeder Tabelle ihren Index
als Primärschlüssel. Wäre auf einer Relation kein Index definiert, so würde „ora2rel“ die
Gesamtheit aller Attribute der Tabelle als Primärschlüssel nehmen.
Beispiel:
In Tabelle K_ABINT existiert ein UNIQUE INDEX i_K_ABINT auf dem Feld Abschl.
Aus diesem Grund wird Abschl als Primärschlüssel der Relation verwendet:
PRIMARY KEY (ABSCHL)
- 102 -
Wäre i_K_ABINT nicht definiert, so würden alle Attribute der Relation als
Primärschlüssel verwendet werden:
PRIMARY KEY (ABSCHL,KTXT,DTXT,ASTAT)
Nach Auswertung des Data-Dictionarys kann der Anwender Relationen auswählen, für
die er weitere Schlüsselkandidaten bzw. Fremdschlüssel definieren will.
Da bei Erzeugung obiger Tabellen keine einzige Fremdschlüssel-Bedingung angegeben
wurde und (wie schon in Kapitel 2 gezeigt) für die Relation „STG“ ein zweiter
Schlüsselkandidat festgelegt werden kann, werden hier nacheinander die Relationen
„STG“, „K_ABSTG“ und „SOS“ ausgewählt.
- 103 -
Zunächst wird durch Eingabe von „9“ Tabelle „STG“ betrachtet: Das Zeichen „!“
liefert alle Schlüsselkandidaten und den derzeit gewählten Primärschlüssel der Relation
„STG“ und gibt diese Daten auf dem Bildschirm aus. Wie in Kapitel 2 angegeben, bilden
die drei Attribute „MtkNr“, „Stg“ und „Semester“ einen weiteren Schlüsselkandidaten.
Nach Eingabe dieser drei Attributnamen startet das System eine Anfrage an die
Datenbank, mit der ermittelt werden kann, ob die Kombination dieser Attribute
tatsächlich einen Schlüsselkandidaten erzeugt (siehe Kapitel 3.1):
SELECT COUNT(*) FROM stg GROUP BY mtknr,stg,semester
HAVING COUNT(*)>1
Hier liefert diese Anfrage zunächst, daß die Attribute nicht die für Schlüsselkandidaten
zwingend notwendige Eindeutigkeit ihrer Daten aufweisen, denn als Anfrage-Ergebnis
wird ein Wert größer 1 geliefert.
- 104 -
Eine Überprüfung der Einträge in der Tabelle „STG“ in einem separaten Oracle-Fenster
ergibt, daß hier noch einige inkonsistente Daten vorliegen, die aus der Relation entfernt
werden. In den in Anhang D angegebenen Instanzen muß z.B. die mit „(*)“ markierte
Zeile aus „STG“ gelöscht werden, da diese Zeile doppelt gespeichert wurde. Nach
erneuter Eingabe der drei Attributnamen werden sie als Schlüsselkandidat akzeptiert - die
Kombination der genannten drei Attribute erfüllt nun die UNIQUE-Bedingung.
Nach Eingabe von „0“ gelangt man auf die nächste Bildschirm-Maske, bei der
Fremdschlüssel definiert werden können. Analog zu oben müssen auch hier zunächst die
Attribute der Tabelle „STG“ ausgewählt werden, die einen Fremdschlüssel formen.
Zunächst wird dabei das Feld „Abschl“ eingegeben. Nun wird eine Liste mit allen zum
Schema gehörenden neun Relationen angezeigt, aus der die Tabelle ausgewählt werden
soll, auf die das Feld zeigt. Mit „1“ wird „K_ABINT“ als Referenztabelle festgelegt.
Dann muß das Attribut in der Referenztabelle bestimmt werden, auf die „Abschl“
verweist. Die Eingabe eines falschen Feldnamens führt zur Ausgabe einer Fehlermeldung.
Erst, wenn das Feld „Abschl“ aus „K_ABINT“ richtig eingegeben wird, legt das System
die richtige Fremdschlüssel-Beziehung fest. Die oben angegebenen Instanzen erfüllen die
Bedingung, die mit Hilfe einer Anfrage (siehe 3.1) überprüft wird: Alle Attribut-Werte
von „Abschl“ in „STG“ sind auch in „Abschl“ von „K_ABINT“ gespeichert, weshalb
die Anfrage
SELECT COUNT(*) FROM stg WHERE NOT EXISTS (
SELECT abschl FROM k_abint WHERE k_abint.abschl=stg.abschl)
als Ergebnis 0 liefert.
- 105 -
Auf die gleiche Weise werden auch die weiteren Fremdschlüssel „Beugrund“ und
„Endegrd“ (verweisen auf „K_GDBU.Gdbu“ bzw. „K_GDEX.Gdex“) festgelegt.
Für
die
Felder
„MtkNr“
und
„Stg“
ist
nicht
bekannt,
ob
sie
als
Fremdschlüsselattribute fungieren. Hier hat man aber die Möglichkeit, „ora2rel“
automatisch nach Fremdschlüssel-Beziehungen suchen zu lassen. Dazu wählt man z.B.
das Feld „Stg“ aus Relation „STG“ aus und gibt dann „10“ („Suche Tabellen mit
gleichnamigen Attributen“) ein. Durch Anfragen an das Data-Dictionary werden nun
Tabellen gesucht, die ebenfalls ein Attribut „Stg“ enthalten. Das System liefert dabei die
Tabellen „K_ABSTG“ und „K_STG“ zurück. Über weitere Anfragen an die Datenbank
wird dann ermittelt, welche Relation als Referenztabelle in Frage kommt (siehe oben).
- 106 -
Hier ergibt sich, daß ausschließlich „K_STG“ mögliche Referenztabelle ist, weil in
„STG.Stg“ Werte gespeichert sind, die „K_ABSTG.Stg“ nicht enthält (in den BeispielDaten ist es der Studiengang „SPT“). Die Anfrage
SELECT COUNT(*) FROM stg WHERE NOT EXISTS (
SELECT stg FROM k_abstg WHERE k_abstg.stg=stg.stg)
liefert als Ergebnis einen Wert größer 0. Deshalb wird die Abhängigkeit zwischen „STG“
und „K_STG“ automatisch festgelegt. Sonst muß der Anwender die Referenztabelle aus
allen ermittelten Möglichkeiten auswählen.
Für Attribut „MtkNr“ liefert die automatische Suche Relation „SOS“ als
Referenztabelle. Durch „!“ kann man sich die Fremdschlüssel am Bildschirm anzeigen
lassen, mit „0“ beendet man die Definition weiterer Fremdschlüssel.
- 107 -
Weil nun für Tabelle „STG“ mehrere Schlüsselkandidaten definiert sind, kann der
Anwender aus diesen einen Primärschlüssel auswählen. Nach den in 3.1 angegebenen
Kriterien gibt das Programm aber an, welcher Schlüsselkandidat der am besten passende
Primärschlüssel ist. Hier wird der Schlüsselkandidat „MtkNr, Stg, Semester“
vorgeschlagen, weil er mehr Fremdschlüssel enthält als der andere Kandidat „MtkNr,
StgNr, Semester“.
Die Auswahl eines Primärschlüssels für Tabelle „STG“ hat erheblichen Einfluß auf
die spätere
Umsetzung
des
Relationenschemas
in
ein
EER-Schema:
Wenn
Schlüsselkandidat „2“ gewählt wird, so setzt „rel2pre“ die Tabelle „STG“ in ein
schwaches Entity um, weil dann nur ein Feld des Primärschlüssels gleichzeitig
Fremdschlüssel ist („MtkNr“). Befolgt der Anwender hingegen den Vorschlag des
Systems und wählt „1“ (, was an dieser Stelle auch geschehen soll), so ist zusätzlich auch
das Attribut „Stg“ ein Fremdschlüssel und „STG“ wird in „rel2pre“ als spezielle
Beziehungsrelation klassifiziert.
- 108 -
Für jeden Fremdschlüssel der Tabelle „STG“ wird dann durch Anfragen ermittelt, ob alle
Daten der jeweiligen Referenztabelle auch in „STG“ auftreten und ob die Fremdschlüssel
nur eindeutige Einträge aufweisen. Wie in 3.1 erläutert liefern diese Anfragen Hinweise
auf die Kardinalitäten, die zu den Fremdschlüssel-Beziehungen gehören.
Beispiel:
In der Abhängigkeit „STG.MtkNr→SOS.MtkNr“ erfüllt der Fremdschlüssel „MtkNr“
aus „STG“ nicht die UNIQUE-Eigenschaft, weil jeder Student mehrere Semester bzw.
mehrere Studiengänge studieren kann. Die Anfrage
SELECT COUNT(*) FROM stg GROUP BY mtknr
HAVING COUNT(*)>1
liefert hier ein Ergebnis größer 1. Hingegen hat jeder Student mindestens ein Semester
ein Fach studiert, so daß alle Matrikelnummern aus „SOS“ auch in „STG“ gespeichert
sind:
SELECT COUNT(*) FROM sos WHERE NOT EXISTS
(SELECT mtknr FROM stg WHERE stg.mtknr=sos.mtknr)
ergibt hier den Wert 0. Andererseits wird nicht unbedingt jeder Studiengang von einem
Studenten studiert, so daß bei der Abhängigkeit „STG.Stg→K_STG.Stg“ ermittelt
wird, daß nicht alle Einträge aus „K_STG.Stg“ in „STG.Stg“ auftreten:
SELECT COUNT(*) FROM k_stg WHERE NOT EXISTS
(SELECT stg FROM stg WHERE stg.stg=k_stg.stg)
liefert einen Wert größer 0. (Vergleiche dazu im Anhang D angegebene Beispiel-Daten.)
Durch das gleiche Vorgehen werden nun auch die Fremdschlüssel-Beziehungen
„K_ABSTG.Stg→K_STG.Stg“,
„K_ABSTG.Abschl→K_ABINT.Abschl“
„SOS.Exmgrund→K_GDEX.Gdex“
festgelegt,
wobei
die
ersten
und
beiden
Abhängigkeiten auch durch die automatische Suche gefunden werden können. Bei der
dritten Beziehung scheitert die automatische Suche an den unterschiedlichen
Attributnamen.
- 109 -
Wie in Kapitel 2 erwähnt, dient auch das Feld „HmKfz“ in Tabelle „SOS“ als
Fremdschlüssel. Jedoch bestimmt der Inhalt des Attributes „HmKfzKz“, welche Relation
als
Referenztabelle
fungiert
(„K_AKFZ“
oder
„K_IKFZ“).
Dadurch
enthält
„SOS.HmKfz“ sowohl Daten, die nicht in „K_AKFZ.AKfz“ auftreten, wie auch Daten,
die nicht in „K_IKFZ.IKfz“ zu finden sind (vergleiche Instanzen aus Anhang D). Aus
diesem Grund werden Versuche, die eine oder die andere Abhängigkeit zu definieren,
vom System zurückgewiesen, weil die Anfrage-Ergebnisse (nach Kapitel 3.1 und oben)
den eingegebenen Vermutungen widersprechen. Die Bedingung zur referentiellen
Integrität ist bei diesem Feld nicht erfüllt - „HmKfz“ genügt einer „aufgespaltenen
referentiellen Integritätsbedingung“.
Nach Beendigung des Programmes „ora2rel“ wird das folgende Relationenschema in
der Datei „testdb.rel“ abgelegt (Format siehe Anhang A/a):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
9
RELATION K_ABINT (
ABSCHL VARCHAR2 NO NULLS
ASTAT VARCHAR2 NO NULLS
DTXT VARCHAR2 NULLS ALLOWED
KTXT VARCHAR2 NULLS ALLOWED
PRIMARY KEY (ABSCHL)
)
RELATION K_ABSTG (
ABSCHL VARCHAR2 NO NULLS
STG VARCHAR2 NO NULLS
PRIMARY KEY (ABSCHL,STG)
FOREIGN KEY (ABSCHL) (n)
REFERENCES K_ABINT(ABSCHL) (n)
INSERT RESTRICTED
DELETE RESTRICTED
FOREIGN KEY (STG) (n)
REFERENCES K_STG(STG) (n)
INSERT RESTRICTED
DELETE RESTRICTED
)
RELATION K_AKFZ (
AKFZ VARCHAR2 NO NULLS
ASTAT VARCHAR2 NULLS ALLOWED
DTXT VARCHAR2 NULLS ALLOWED
EGMITGL VARCHAR2 NULLS ALLOWED
KTXT VARCHAR2 NULLS ALLOWED
PRIMARY KEY (AKFZ)
)
RELATION K_GDBU (
ASTAT VARCHAR2 NULLS ALLOWED
DTXT VARCHAR2 NULLS ALLOWED
GDBU VARCHAR2 NO NULLS
KTXT VARCHAR2 NULLS ALLOWED
PRIMARY KEY (GDBU)
)
- 110 -
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
RELATION K_GDEX (
ASTAT VARCHAR2 NULLS ALLOWED
DTXT VARCHAR2 NULLS ALLOWED
GDEX VARCHAR2 NO NULLS
KTXT VARCHAR2 NULLS ALLOWED
PRIMARY KEY (GDEX)
)
RELATION K_IKFZ (
ASTAT VARCHAR2 NULLS ALLOWED
DTXT VARCHAR2 NULLS ALLOWED
IKFZ VARCHAR2 NO NULLS
KTXT VARCHAR2 NULLS ALLOWED
PRIMARY KEY (IKFZ)
)
RELATION K_STG (
ASTAT VARCHAR2 NULLS ALLOWED
DTXT VARCHAR2 NULLS ALLOWED
KTXT VARCHAR2 NULLS ALLOWED
STG VARCHAR2 NO NULLS
PRIMARY KEY (STG)
)
RELATION SOS (
EXMDAT VARCHAR2 NULLS ALLOWED
EXMGRUND VARCHAR2 NULLS ALLOWED
HMKFZ VARCHAR2 NULLS ALLOWED
HMKFZKZ VARCHAR2 NULLS ALLOWED
IMMDAT VARCHAR2 NULLS ALLOWED
MTKNR NUMBER NO NULLS
NAME VARCHAR2 NULLS ALLOWED
ORT VARCHAR2 NULLS ALLOWED
RUEBEUDAT VARCHAR2 NULLS ALLOWED
SEMESTER NUMBER NULLS ALLOWED
STAAT VARCHAR2 NULLS ALLOWED
STATUS VARCHAR2 NULLS ALLOWED
STRASSE VARCHAR2 NULLS ALLOWED
PRIMARY KEY (MTKNR)
FOREIGN KEY (EXMGRUND) (n)
REFERENCES K_GDEX(GDEX) (n)
INSERT RESTRICTED
DELETE RESTRICTED
)
RELATION STG (
ABSCHL VARCHAR2 NULLS ALLOWED
BEUGRUND VARCHAR2 NULLS ALLOWED
ENDEGRD VARCHAR2 NULLS ALLOWED
MTKNR NUMBER NO NULLS
SEMESTER NUMBER NO NULLS
STATUS VARCHAR2 NULLS ALLOWED
STG VARCHAR2 NO NULLS
STGNR VARCHAR2 NO NULLS
PRIMARY KEY (MTKNR,SEMESTER,STG)
ALTERNATE KEY (MTKNR,SEMESTER,STGNR)
FOREIGN KEY (MTKNR) (n)
REFERENCES SOS(MTKNR) (A)
INSERT RESTRICTED
DELETE RESTRICTED
FOREIGN KEY (STG) (n)
REFERENCES K_STG(STG) (n)
INSERT RESTRICTED
DELETE RESTRICTED
- 111 -
97
FOREIGN KEY (BEUGRUND) (n)
98
REFERENCES K_GDBU(GDBU) (n)
99
INSERT RESTRICTED
100
DELETE RESTRICTED
101
FOREIGN KEY (ENDEGRD) (n)
102
REFERENCES K_GDEX(GDEX) (n)
103
INSERT RESTRICTED
104
DELETE RESTRICTED
105
FOREIGN KEY (ABSCHL) (n)
106
REFERENCES K_ABINT(ABSCHL) (n)
107
INSERT RESTRICTED
108
DELETE RESTRICTED
109 )
Im Hinblick auf obiges Beispiel soll in dieser Datei die Tabelle „STG“ (Zeile 78-109)
genauer betrachtet werden:
Nach der Definition der Attribute (Zeile 79-86) erscheint in Zeile 87 der oben vom
Anwender gewählte Primärschlüssel. Der vom Index „i_USTG“ vorgegebene
Schlüsselkandidat steht in Zeile 88. Die folgenden Zeilen bestimmen die FremdschlüsselBeziehungen, die von der Relation „STG“ ausgehen. So ist zum Beispiel vermerkt, daß
das Feld „MtkNr“ (Zeile 89) auf „MtkNr“ in Tabelle „SOS“ (Zeile 90) verweist. Die
beiden darauf folgenden Zeilen (91/92) dienen der Kompatibilität des PRE-Schemas zum
SDT-Schema - sie werden nicht ausgewertet. Am Ende der Zeilen 89/90 stehen in
Klammern die Ergebnisse der Anfragen, die zur Ermittlung der Kardinalitäten dienen.
Wie oben angegeben hat „MtkNr“ keine UNIQUE-Eigenschaft, weshalb (in Zeile 89) ein
„n“ vermerkt wurde. Im anderen Fall würde hier ein „U“ stehen. In Zeile 90 hingegen ist
ein „A“ notiert, weil obige Anfrage an die Datenbank ergeben hat, daß alle
Matrikelnummern aus „SOS“ auch in „STG“ gespeichert sind. Indessen sind nicht alle
Studiengänge aus „K_STG“ auch in „STG.Stg“ abgelegt, so daß bei dieser
Abhängigkeit ein „n“ notiert wird (Zeile 94).
Durch Wahl des Punktes „3“ („Relationenschema editieren“) im Hauptmenü kann
diese Datei noch editiert werden, bevor mit „4“ („Relationenschema in EER-Schema
umsetzen (rel2pre)“) die Umsetzung gestartet wird.
- 112 -
4.3.4 Umsetzung des Relationenschemas in ein PRE-Schema
Der Start des Programms „rel2pre“ erzeugt folgende Bildschirm-Ausgabe:
Hier hat der Anwender keinen Einfluß mehr auf die Art der Umsetzung. Erst die
entstehende Datei „testdb.pre“ kann durch Wahl des Punktes „5“ („EER-Schema
editieren“) aus dem Hauptmenü heraus editiert werden:
1
2
3
4
5
6
7
8
9
10
11
14
K_ABINT(E)
ATTRS: ABSCHL (ID, "", , VARCHAR2 NO NULLS),
ASTAT (, "", , VARCHAR2 NO NULLS),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_ABINT ist SER/BER";
K_ABSTG(R)
ARCS: K_ABINT (k(2), , ),
K_STG (k(2), , )
DESCR: "Rel. K_ABSTG ist RBR";
- 113 -
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
K_AKFZ(E)
ATTRS: AKFZ (ID, "", , VARCHAR2 NO NULLS),
ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
EGMITGL (, "", , VARCHAR2 NULLS ALLOWED),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_AKFZ ist SER/BER";
K_GDBU(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
GDBU (ID, "", , VARCHAR2 NO NULLS),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_GDBU ist SER/BER";
K_GDEX(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
GDEX (ID, "", , VARCHAR2 NO NULLS),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_GDEX ist SER/BER";
K_IKFZ(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
IKFZ (ID, "", , VARCHAR2 NO NULLS),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_IKFZ ist SER/BER";
K_STG(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
KTXT (, "", , VARCHAR2 NULLS ALLOWED),
STG (ID, "", , VARCHAR2 NO NULLS)
DESCR: "Rel. K_STG ist SER/BER";
SOS(E)
ATTRS: EXMDAT (, "", , VARCHAR2 NULLS ALLOWED),
HMKFZ (, "", , VARCHAR2 NULLS ALLOWED),
HMKFZKZ (, "", , VARCHAR2 NULLS ALLOWED),
IMMDAT (, "", , VARCHAR2 NULLS ALLOWED),
MTKNR (ID, "", , NUMBER NO NULLS),
NAME (, "", , VARCHAR2 NULLS ALLOWED),
ORT (, "", , VARCHAR2 NULLS ALLOWED),
RUEBEUDAT (, "", , VARCHAR2 NULLS ALLOWED),
SEMESTER (, "", , NUMBER NULLS ALLOWED),
STAAT (, "", , VARCHAR2 NULLS ALLOWED),
STATUS (, "", , VARCHAR2 NULLS ALLOWED),
STRASSE (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. SOS ist SER/BER";
STG(R)
ARCS: SPEZIELL_STG (k(12), , ),
SOS (k(12), , ),
K_STG (k(2), , )
DESCR: "Rel. STG ist SBR";
SPEZIELL_STG(E)
ATTRS: SEMESTER (ID, "", , NUMBER NO NULLS),
STATUS (, "", , VARCHAR2 NULLS ALLOWED),
STGNR (, "", , VARCHAR2 NO NULLS)
DESCR: "Spez. Entity zu SBR STG";
HAT_1(R)
ARCS: SOS (k(1), , ),
K_GDEX (k(2), , )
DESCR: "FS-Bez. (REFERENCE) SOS --> K_GDEX";
- 114 -
71
72
73
74
75
76
77
78
79
80
81
82
HAT_2(R)
ARCS:
SPEZIELL_STG (k(1), , ),
K_GDBU (k(2), , )
DESCR: "FS-Bez. (REFERENCE) STG --> K_GDBU";
HAT_3(R)
ARCS: SPEZIELL_STG (k(1), , ),
K_GDEX (k(2), , )
DESCR: "FS-Bez. (REFERENCE) STG --> K_GDEX";
HAT_4(R)
ARCS: SPEZIELL_STG (k(1), , ),
K_ABINT (k(2), , )
DESCR: "FS-Bez. (REFERENCE) STG --> K_ABINT";
Daraus kann folgendes EER-Schema abgelesen werden:
K_GDEX
(0,N)
K_GDBU
(0,N)
HAT_1
(0,N)
HAT_3
(0,1)
(0,1)
SOS
HAT_2
(1,N)
STG
(1,N)
(0,N)
HAT_4
(0,N)
K_ABSTG
SPEZIELL_STG
(0,1)
K_STG
K_AKFZ
(0,1)
(0,N)
(0,N)
K_ABINT
K_IKFZ
Die Relationen „K_ABINT“, „K_AKFZ“, „K_IKFZ“, „K_GDBU“, „K_GDEX“,
„K_STG“ und „SOS“ werden in gleichnamige Entities („E“) umgesetzt, deren
Primärschlüsselattribute durch die Angabe von „ID“ in der jeweiligen Attribut-Zeile
markiert werden. Für jedes Feld wird weiterhin vermerkt, welchen Datentyp es hat und
ob leere Einträge erlaubt sind oder nicht.
Tabelle „K_ABSTG“ (Zeile 8-11) wird als Beziehung („R“) klassifiziert, weil alle
Felder seines Primärschlüssels auch als Fremdschlüsselattribute fungieren. Die Beziehung
enthält keine eigenen Attribute, sondern stellt die Verbindung zwischen den Entities
- 115 -
„K_ABINT“ und „K_STG“ her. Als Kardinalitäten werden auf beiden Seiten (0,n)
(„k(2)“) notiert (Zeile 9/10).
„STG“ wird als spezielle Beziehungs-Relation klassifiziert und somit in eine
Beziehung und ein Entity umgesetzt. Das Entity „SPEZIELL_STG“ (Zeile 62-66)
enthält dabei alle Attribute aus Relation „STG“, die nicht als Fremdschlüsselattribut
dienen. Das Feld „Semester“ ist in Tabelle „STG“ Bestandteil des Primärschlüssels,
wurde aber nicht gleichzeitig als Fremdschlüsselattribut klassifiziert. Deshalb dient es in
dem neuen Entity als Primärschlüssel (Zeile 63). „STG“ (Zeile 57-61) ist eine dreifache
Beziehung, die aus dem Primärschlüssel der gleichnamigen Relation entsteht. Sie
verbindet die drei Entities „SPEZIELL_STG“, „SOS“ und „K_STG“ (Zeile 58-60). An
den beiden ersten Verbindungen werden dabei die Kardinalitäten (1,n) („k(12)“) notiert.
Die Untergrenze kommt dadurch zustande, daß alle Einträge aus „SOS.MtkNr“ bzw.
„SPEZIELL_STG.Semester“ in „STG“ zu finden sind. Bei speziellen BeziehungsRelationen („STG“) kann zwischen den beiden aus dieser Tabelle erzeugten Objekten
(Beziehung „STG“ und Entity „SPEZIELL_STG“) grundsätzlich als Kardinalität (1,n)
festgelegt werden, bei der Verbindung zwischen „SOS“ und „STG“ wird die
Information aus dem Relationenschema ausgenutzt, daß alle Matrikelnummern aus
„STG“ auch in „SOS“ gespeichert sind.
In den Zeilen 67-82 werden die Fremdschlüssel-Beziehungen („HAT“) notiert. Jede
dieser funktionalen Beziehungen hat dabei als Kardinalität auf der Seite der
Referenztabelle (0,n) („k(2)“) stehen, weil die Fremdschlüssel keine UNIQUEEigenschaft erfüllen. Auf der anderen Seite steht jeweils (0,1) („k(1)“), da alle
Fremdschlüsselattribute auch leere Einträge erlauben.
Um auch ein Beispiel für eine Generalisierung / Spezialisierung anzugeben, wird das
oben notierte Relationenschema um die Tabelle „TEST“ erweitert:
1
2
3
4
5
6
7
8
9
10
RELATION TEST (
COL1 NUMBER NO NULLS
COL2 CHAR NO NULLS
STG CHAR NO NULLS
PRIMARY KEY (STG)
FOREIGN KEY (STG) (U)
REFERENCES K_STG(STG) (n)
INSERT RESTRICTED
DELETE RESTRICTED
)
- 116 -
Diese Tabelle wird als besondere Entity-Relation klassifiziert, weil der Primärschlüssel
von „TEST“ aus nur einem Fremdschlüssel besteht:
1
2
3
4
5
TEST(Gen)
ATTRS: COL1 (, "", , NUMBER NO NULLS),
COL2 (, "", , CHAR NO NULLS)
ARCS: K_STG (k(99), , )
DESCR: "Bez. (REFERENCE) zw. BER TEST und Rel. K_STG --> Gen.";
Umgesetzt wird Tabelle „TEST“ deshalb in ein gleichnamiges Entity, das eine
Spezialisierung von „K_STG“ darstellt, weshalb als Objekttyp „Gen“ (Zeile 1) notiert
wird. An der Verbindung zu „K_STG“ steht keine Kardinalität - der Wert „k(99)“ gibt
an, daß es sich hier um die Verbindung zwischen einem Entity und einer Generalisierung
bzw. Spezialisierung handelt.
4.3.5 Umwandlung in ein SDT-Schema
Durch Wahl des Punktes „6“ („EER-Schema in SDT-Schema umsetzen (pre2sdt)“) im
Hauptmenü wird nun das in „test.pre“ abgelegte EER-Schema in ein SDT-Schema
umgewandelt, um es später mit dem Tool „erdraw“ von Markowitz grafisch ausgeben zu
können. Bei dieser Umwandlung werden durch das SED-Script „pre2sdt“ die
Kardinalitäten in SDT-konforme Begriffe umgesetzt. Aus den Kardinalitäten „(0,n)“
wird so ein „HAS_M“ (Zeile 9,10,60,69,73,77,81), aus „(0,1)“ ein „HAS“ (Zeile
68,72,76,80) und aus „(1,n)“ ein „A_HAS_M“ (Zeile 58,59):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
14
K_ABINT(E)
ATTRS: ABSCHL (ID, "", , VARCHAR2 NO NULLS),
ASTAT (, "", , VARCHAR2 NO NULLS),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_ABINT ist SER/BER";
K_ABSTG(R)
ARCS: K_ABINT (HAS_M, , ),
K_STG (HAS_M, , )
DESCR: "Rel. K_ABSTG ist RBR";
K_AKFZ(E)
ATTRS: AKFZ (ID, "", , VARCHAR2 NO NULLS),
ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
EGMITGL (, "", , VARCHAR2 NULLS ALLOWED),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_AKFZ ist SER/BER";
- 117 -
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
K_GDBU(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
GDBU (ID, "", , VARCHAR2 NO NULLS),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_GDBU ist SER/BER";
K_GDEX(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
GDEX (ID, "", , VARCHAR2 NO NULLS),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_GDEX ist SER/BER";
K_IKFZ(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
IKFZ (ID, "", , VARCHAR2 NO NULLS),
KTXT (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. K_IKFZ ist SER/BER";
K_STG(E)
ATTRS: ASTAT (, "", , VARCHAR2 NULLS ALLOWED),
DTXT (, "", , VARCHAR2 NULLS ALLOWED),
KTXT (, "", , VARCHAR2 NULLS ALLOWED),
STG (ID, "", , VARCHAR2 NO NULLS)
DESCR: "Rel. K_STG ist SER/BER";
SOS(E)
ATTRS: EXMDAT (, "", , VARCHAR2 NULLS ALLOWED),
HMKFZ (, "", , VARCHAR2 NULLS ALLOWED),
HMKFZKZ (, "", , VARCHAR2 NULLS ALLOWED),
IMMDAT (, "", , VARCHAR2 NULLS ALLOWED),
MTKNR (ID, "", , NUMBER NO NULLS),
NAME (, "", , VARCHAR2 NULLS ALLOWED),
ORT (, "", , VARCHAR2 NULLS ALLOWED),
RUEBEUDAT (, "", , VARCHAR2 NULLS ALLOWED),
SEMESTER (, "", , NUMBER NULLS ALLOWED),
STAAT (, "", , VARCHAR2 NULLS ALLOWED),
STATUS (, "", , VARCHAR2 NULLS ALLOWED),
STRASSE (, "", , VARCHAR2 NULLS ALLOWED)
DESCR: "Rel. SOS ist SER/BER";
STG(R)
ARCS: SPEZIELL_STG (A_HAS_M, , ),
SOS (A_HAS_M, , ),
K_STG (HAS_M, , )
DESCR: "Rel. STG ist SBR";
SPEZIELL_STG(E)
ATTRS: SEMESTER (ID, "", , NUMBER NO NULLS),
STATUS (, "", , VARCHAR2 NULLS ALLOWED),
STGNR (, "", , VARCHAR2 NO NULLS)
DESCR: "Spez. Entity zu SBR STG";
HAT_1(R)
ARCS: SOS (HAS, , ),
K_GDEX (HAS_M, , )
DESCR: "FS-Bez. (REFERENCE) SOS --> K_GDEX";
HAT_2(R)
ARCS: SPEZIELL_STG (HAS, , ),
K_GDBU (HAS_M, , )
DESCR: "FS-Bez. (REFERENCE) STG --> K_GDBU";
HAT_3(R)
ARCS: SPEZIELL_STG (HAS, , ),
K_GDEX (HAS_M, , )
DESCR: "FS-Bez. (REFERENCE) STG --> K_GDEX";
- 118 -
79
80
81
82
HAT_4(R)
ARCS:
SPEZIELL_STG (HAS, , ),
K_ABINT (HAS_M, , )
DESCR: "FS-Bez. (REFERENCE) STG --> K_ABINT";
Betrachtet man wieder die Erweiterung des Schemas um Tabelle „TEST“, so würden
zusätzlich die folgenden Zeilen am Ende der Datei „test.sdt“ stehen:
1
2
3
4
5
TEST(E)
ATTRS: COL1 (, "", , NUMBER NO NULLS),
COL2 (, "", , CHAR NO NULLS)
ARCS: K_STG (ISA, , )
DESCR: "Bez. (REFERENCE) zw. BER TEST und Rel. K_STG --> Gen.";
Im Unterschied zu obigem PRE-Schema gibt es bei SDT-Schemata nicht die
Möglichkeit, Generalisierungen / Spezialisierungen zu definieren. Das Objekt „TEST“
wird hier deshalb als Entity behandelt (Zeile 1), das mit Objekt „K_STG“ verbunden ist.
Die Art dieser Verbindung wird auf „ISA“ festgelegt (Zeile 4).
Auch das SDT-Schema kann über das Hauptmenü editiert werden. Dazu ist die
Wahl des siebenten Hauptmenü-Punktes („SDT-Schema editieren“) erforderlich.
4.3.6 Vergleich der erzeugten SDT-Schemata
Das in der Datei „testdb.rel“ abgelegte Relationenschema (siehe oben) kann auch mit
dem Programm „rel2sdt“ von Markowitz direkt in ein SDT-Schema umgesetzt werden.
Aufgerufen wird dieses Programm durch Wahl des Punktes „11“ („Relationenschema in
SDT-Schema umsetzen (rel2sdt - MARKOWITZ)“) im Hauptmenü:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Generated by rel2sdt
9
K_ABINT(E)
ATTRS: ABSCHL (ID, "", , varchar NO NULLS),
ASTAT (, "", , varchar NO NULLS),
DTXT (, "", , varchar NULLS ALLOWED),
KTXT (, "", , varchar NULLS ALLOWED)
DESCR: "";
K_ABSTG(R)
ARCS: K_ABINT (M, RESTRICTED, ),
K_STG (M, RESTRICTED, )
DESCR: "";
K_AKFZ(E)
ATTRS: AKFZ (ID, "", , varchar NO NULLS),
ASTAT (, "", , varchar NULLS ALLOWED),
DTXT (, "", , varchar NULLS ALLOWED),
EGMITGL (, "", , varchar NULLS ALLOWED),
KTXT (, "", , varchar NULLS ALLOWED)
DESCR: "";
- 119 -
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
K_GDBU(E)
ATTRS: ASTAT (, "", , varchar NULLS ALLOWED),
DTXT (, "", , varchar NULLS ALLOWED),
GDBU (ID, "", , varchar NO NULLS),
KTXT (, "", , varchar NULLS ALLOWED)
DESCR: "";
K_GDEX(E)
ATTRS: ASTAT (, "", , varchar NULLS ALLOWED),
DTXT (, "", , varchar NULLS ALLOWED),
GDEX (ID, "", , varchar NO NULLS),
KTXT (, "", , varchar NULLS ALLOWED)
DESCR: "";
K_IKFZ(E)
ATTRS: ASTAT (, "", , varchar NULLS ALLOWED),
DTXT (, "", , varchar NULLS ALLOWED),
IKFZ (ID, "", , varchar NO NULLS),
KTXT (, "", , varchar NULLS ALLOWED)
DESCR: "";
K_STG(E)
ATTRS: ASTAT (, "", , varchar NULLS ALLOWED),
DTXT (, "", , varchar NULLS ALLOWED),
KTXT (, "", , varchar NULLS ALLOWED),
STG (ID, "", , varchar NO NULLS)
DESCR: "";
SOS(E)
ATTRS: EXMDAT (, "", , varchar NULLS ALLOWED),
HMKFZ (, "", , varchar NULLS ALLOWED),
HMKFZKZ (, "", , varchar NULLS ALLOWED),
IMMDAT (, "", , varchar NULLS ALLOWED),
MTKNR (ID, "", , number NO NULLS),
NAME (, "", , varchar NULLS ALLOWED),
ORT (, "", , varchar NULLS ALLOWED),
RUEBEUDAT (, "", , varchar NULLS ALLOWED),
SEMESTER (, "", , number NULLS ALLOWED),
STAAT (, "", , varchar NULLS ALLOWED),
STATUS (, "", , varchar NULLS ALLOWED),
STRASSE (, "", , varchar NULLS ALLOWED)
ARCS: K_GDEX (HAS, RESTRICTED, )
DESCR: "";
STG(E)
ATTRS: SEMESTER (ID, "", , number NO NULLS),
STATUS (, "", , varchar NULLS ALLOWED),
STGNR (, "", , varchar NO NULLS)
ARCS: SOS (ID, RESTRICTED, ),
K_STG (ID, RESTRICTED, ),
K_GDBU (HAS, RESTRICTED, ),
K_GDEX (HAS, RESTRICTED, ),
K_ABINT (HAS, RESTRICTED, )
DESCR: "";
- 120 -
Daraus kann folgendes Schema abgelesen werden:
K_GDEX
K_GDBU
HAS
HAS
HAS
SOS
STG
ID
ID
K_STG
K_AKFZ
M
K_ABSTG
HAS
M
K_ABINT
K_IKFZ
Auffällig sind dabei die folgenden Unterschiede zu dem oben erstellten SDT-Schema:
• Relation „STG“ wird von Markowitz anders klassifiziert und umgesetzt als im
selbstentwickelten Algorithmus: Weil der Primärschlüssel von „STG“ nicht
ausschließlich aus Fremdschlüsselfeldern besteht, wird diese Tabelle als EntityObjekt behandelt. Alle Attribute und Beziehungen werden dem Objekt „STG“
zugeordnet. Die aus den beiden Attributen „MtkNr“ und „Stg“ des
Primärschlüssels von Relation „STG“ folgenden Abhängigkeiten werden als
„ID“-Verbindungen von Objekt „STG“ zu den Objekten „SOS“ bzw. „K_STG“
dargestellt (Zeile 63/64). Oben wurde Tabelle „STG“ als spezielle EntityRelation klassifiziert und deshalb in ein Entity „SPEZIELL_STG“ und eine
Beziehung „STG“ umgewandelt.
• Die Fremdschlüsselbeziehungen „HAT“ fehlen im Schema von Markowitz ganz.
„rel2sdt“ ordnet stattdessen die Verbindungen zwischen Fremdschlüssel und
Referenztabelle direkt den Entities zu (Zeile 57, 65-67).
An diesen Punkten kann man erkennen, daß „rel2sdt“ weniger Struktur-Informationen
aus dem Relationenschema abliest als „rel2pre“ und „pre2sdt“.
4.3.7 Grafische Ausgabe des Schemas
Mittels des Menüpunktes „8“ („SDT-Schema in ERD-Schema umsetzen (sdt2erd MARKOWITZ)“) wird dann das SDT-Schema aus der Datei „testdb.sdt“ in ein ERD-
- 121 -
Schema umgewandelt, das einzig der grafischen Ausgabe des Schemas dient. Die
entstehende Datei kann mit „9“ („ERD-Schema editieren“) editiert und nach Wahl des
Punktes „10“ („ERDRAW aufrufen (erdraw - MARKOWITZ)“) mit dem MarkowitzTool „erdraw“ eingelesen werden. „erdraw“ stellt dann das Schema grafisch in folgender
Form dar:
- 122 -
Auf der ersten Seite des Schemas sind alle Entities aufgeführt. Durch Weiterblättern
gelangt man dann zur zweiten Seite, auf der alle Beziehungen abgebildet sind:
- 123 -
Die nun folgenden Seiten enthalten einzeln alle Entities mit den dazugehörigen
Beziehungen. So wird zum Beispiel auf Seite 3 des ERD-Schemas das Entity
„K_ABINT“ dargestellt. Weil die Beziehungen „K_ABSTG“ und „HAT_4“ auf
„K_ABINT“ verweisen, sind auch diese Objekte mit allen damit verbundenen Objekten
auf dieser Seite aufgeführt:
- 124 -
Weil auf Entity „K_AKFZ“ keine Abhängigkeit verweist, enthält die vierte Seite des
ERD-Schemas nur dieses Objekt. Interessanter ist wieder „K_GDBU“, da die
Fremdschlüsselbeziehung „HAT_2“ von „SPEZIELL_STG“ auf „K_GDBU“ verweist:
Analog dazu werden auf Seite 6 die beiden Fremdschlüsselbeziehungen „HAT_1“ und
„HAT_3“ von „SOS“ bzw. „SPEZIELL_STG“ auf Entity „K_GDEX“ dargestellt.
Seite 7 enthält wieder nur ein Entity: Das Objekt „K_IKFZ“ ist hier abgebildet.
- 125 -
Auf Entity „K_STG“ verweisen die Beziehungen „K_ABSTG“ und „STG“.
Deshalb werden beide Beziehungen und alle an diesen Beziehungen teilnehmenden
Objekte auf der achten Seite des Schemas dargestellt:
- 126 -
Das Objekt „SOS“ ist Bestandteil der Beziehung „STG“. Außerdem verweist die
Fremdschlüsselbeziehung „HAT_1“ von „SOS“ auf „K_GDEX“. Aus diesem Grund
werden diese Objekte auf der neunten Bildschirm-Seite von „erdraw“ abgebildet:
- 127 -
Die komplexeste Grafik enthält die letzte Seite des ERD-Schemas. Die vier Beziehungen
„STG“, „HAT_2“, „HAT_3“ und „HAT_4“ enthalten alle Verweise auf das Entity
„SPEZIELL_STG“. Deshalb sind hier nahezu alle Objekte des ERD-Schemas
aufgeführt:
4.4 Bewertung der Resultate
Sieht man von der „aufgespaltenen referentiellen Integritätsbedingung“ bei Feld
„HmKfz“ ab („HmKfz“ bildet keinen Fremdschlüssel im eigentlichen Sinne: Das Attribut
„HmKfzKz“ bestimmt, ob Tabelle „K_AKFZ“ oder „K_IKFZ“ Referenztabelle ist), so
deckt sich das hier erhaltene Ergebnis mit dem, was am Ende des Kapitels 3.3 zu
erwarten war. Insofern ist das Ergebnis besser als die Resultate, die mit einem der
anderen Verfahren zu erzielen sind. Allerdings ist es auch hier noch notwendig, daß der
Anwender alle relevanten Fremdschlüssel und Schlüsselkandidaten bestimmt, sofern sie
nicht aus dem Oracle-Datenbank-Schema abzulesen sind. Eine Möglichkeit wäre, die
- 128 -
Anfragen aus Kapitel 3.1 auf allen möglichen Feldkombinationen auszuprobieren, um
damit den Anwender zu entlasten. Dieses scheitert jedoch daran, daß die Anzahl der
Anfragen exponentiell mit der Anzahl der Attribute in den Tabellen ansteigt und mit ihr
auch die Laufzeit. Ein automatisches Durchsuchen der Datenbank nach Schlüsseln ist nur
bei winzigen Schemata möglich, hier aber gleichzeitig auch unnötig, denn bei
entsprechend kleinen Datenbanken ist ein Tools zum Reverse Engineering nicht mehr
erforderlich.
Weiterhin ist zu beachten, daß eventuell fehlerhafte Eingaben des Anwenders nur
dann erkannt werden, wenn die gespeicherten Instanzen, also der jeweilige DatenbankZustand, dies zuläßt. Für dieses Verfahren gibt es aber keine Alternative, so daß diese
Abhängigkeit vom Zustand der Datenbank in Kauf genommen werden muß.
Wenn wir als Beispiel die letzte Seite des ERD-Schemas betrachten (s.o.), so fällt
auf, daß die Umsetzung dieses Schemas in ein Relationenschema wieder auf die
ursprüngliche Tabellen-Struktur zurückführt. Hieran sieht man recht deutlich, daß alle
wichtigen Struktur-Informationen des Relationenschemas im EER-Schema umgesetzt
werden.
Wie bereits in Kapitel 3.4 erwähnt sind auch am Ende dieses Verfahrens noch
Änderungen am entstandenen Schema notwendig, um die Lesbarkeit zu erhöhen.
Besonders „erdraw“ bietet hier noch nicht ausreichend Möglichkeiten der grafischen
Darstellung. So werden Kardinalitäten noch nicht abgebildet und die Objekte
Generalisierungen / Spezialisierungen gibt es bei den Werkzeugen von Markowitz
überhaupt nicht. Hier kann die Entwicklung eines neuen grafischen Tools, das ein PRESchema direkt auswerten und als EER-Schema auf dem Bildschirm ausgeben kann,
schon für Abhilfe sorgen. Jedoch muß der Anwender auch dann noch z.B. die Namen der
Fremdschlüssel-Beziehungen ändern.
Zu bemerken ist außerdem, daß die Information über Schlüsselkandidaten bei dem
Schritt vom Relationenschema zum PRE-Schema verloren geht. Dies liegt daran, daß im
EER-Modell, wie es am Anfang des zweiten Kapitels definiert worden ist, keine
Schlüsselkandidaten-Angabe möglich ist. Auch das SDT-Schema von Markowitz sieht
eine solche Option nicht vor.
- 129 -
4.5 Folgerungen für das Relationenschema
Aus den Umsetzungs-Ergebnissen können Korrekturen abgelesen werden, die die
relationale Struktur der Test-Datenbank verbessern:
• In Tabelle „STG“ sollte der Primärschlüssel aus den Attributen „MtkNr“,
„Semester“ und „Stg“ zusammengesetzt werden. Damit wird also im
bisherigen Primärschlüssel das Attribut „StgNr“ durch „Stg“ ersetzt.
• Die Attribute „HmKfzKz“ und „HmKfz“ in Relation „SOS“ sollten zu einem
Fremdschlüsselattribut „HmKfz“ verschmolzen werden. In den Tabellen
„K_AKFZ“
bzw.
„K_IKFZ“
Primärschlüsselattributen
die
werden
dann
Kennzeichen
den
„A“
Daten
bzw.
in
„I“
den
(aus
„SOS.HmKfzKz“) vorangestellt. Weiterhin sollte eine neue Tabelle „K_KFZ“
mit
nur
einem
Attribut
„Kfz“
erzeugt
werden,
die
in
diesem
Primärschlüsselattribut alle Daten aus „K_AKFZ.AKfz“ sowie „K_IKFZ.IKfz“
speichert. Dadurch kann erreicht werden, daß „K_AKFZ“ und „K_IKFZ“ von
„rel2pre“ als besondere Entity-Relationen klassifiziert werden und so eine
(totale exklusive) Generalisierung erzeugt wird, die den Zweck der Relationen
am besten wiedergeben.
Nach diesen Änderungen wird durch die Programme „ora2rel“ und „rel2pre“ für die
Tabellen „SOS“, „K_KFZ“, „K_AKFZ“ und „K_IKFZ“ das folgende EER-Schema
erzeugt:
SOS
HAT_1
K_KFZ
K_AKFZ
K_IKFZ
- 130 -
4.6 Vergleich mit Chiangs Verfahren
Bei Vergleich des Verfahrens von Chiang (siehe Kapitel 2) mit dem in Kapitel 3
vorgestellten neuen Algorithmus fällt als erstes das gemeinsame Problem der
Namensgebung auf: Kein Algorithmus kann helfen, sinnvolle Namen für die
unterschiedlichen Objekte im Zielschema zu vergeben. In beiden Zielschemata existieren
Objekte mit Namen wie „HAT“. Hier ist der Anwender gefordert, Bezeichnungen zu
wählen, die die Lesbarkeit des EER-Schemas erhöhen.
Hingegen wird der Anwender bei der Ermittlung von Schlüsselkandidaten und
Fremdschlüsseln durch das neue Verfahren besser unterstützt: Während Chiang
Namensgleichheit von Attributen ausnutzt, um Fremdschlüsselvermutungen zu äußern,
werden im eigenen Algorithmus diese Vermutungen zusätzlich durch DatenbankAnfragen überprüft. Außerdem ermittelt das System mögliche Schlüsselkandidaten über
Anfragen. Aber auch diese Vermutungen müssen durch den Anwender überprüft und
gegebenenfalls korrigiert werden, da die Ergebnisse der Anfragen vom jeweiligen
Datenbank-Zustand abhängig sind. Dennoch erhält der Nutzer eine sinnvolle
Unterstützung bei der Definition weiterer Schlüssel, weil unsinnige Angaben durch das
Verfahren erkannt und zurückgewiesen werden, sofern ausreichend viele Instanzen in der
Datenbank gespeichert sind.
Außerdem enthält das Zielschema von Chiang keine Kardinalitäten. Das neue
Verfahren hingegen bestimmt mögliche Kardinalitäten über Anfragen an die Datenbank.
Ein weiterer Unterschied liegt in der Reihenfolge, in der die Beziehungs-Relationen
umgesetzt werden. Durch das Vorziehen der Erstellung der Entities zu speziellen EntityRelationen vor die Bildung von Beziehungen (siehe Kapitel 3.3, Schritt 5) werden beim
eigenen Verfahren auch Beziehungen zwischen diesen „SPEZIELL“-Entities und
anderen Entities oder Beziehungen erkannt und gebildet. Bei Chiang ist dies nicht
möglich.
Weiterhin ist der Grad der Automatisierung erhöht worden, indem der Anwender
nicht mehr auswählen muß, ob Attribute an ein Entity oder eine Beziehung gehängt
werden, wenn beide Fälle äquivalent sind (siehe Schritt 15 von Chiang). Im eigenen
Verfahren werden die Attribute in diesem Fall immer dem Entity zugeordnet.
- 131 -
4.7 S-Designor Professional
Ein weiteres Tool, das eine Option zum Reverse Engineering von Datenbanken anbietet,
ist das Programm „S-Designor Professional“, dessen Beta-Version im Rahmen dieser
Arbeit kurz getestet wurde. Das Programm wurde von Xiao-Yun Wang, Powersoft
GmbH, entwickelt und stand in der Version 4.1.2 zum Test zur Verfügung (frei erhältlich
unter „http://www.powersoft.com/mktg/prodinfo/designor/sdpro.html“).
Der S-Designor ist ein Werkzeug, das unter Microsoft-Windows (ab Version 3.10)
lauffähig ist und mit Datenbanken zusammenarbeitet, die dem ODBC (Open DataBase
Connectivity) - Standard von Microsoft entsprechen. Neben einer Option zum Reverse
Engineering bietet es dem Anwender vor allem die Möglichkeit, im S-Designor definierte
„Entities“ (dieser Begriff hat hier eine andere Bedeutung als i.A. üblich, siehe unten) als
Relationen in unterschiedlichen Datenbank-Systemen zu erzeugen (Ein kurzer Bericht
über diese Funktionen ist in der Zeitschrift „PC Professionell“, Ausgabe 01/96, Seite 92,
zu finden). Diese Möglichkeiten werden hier jedoch nicht weiter behandelt - stattdessen
wurde die Funktion „Reverse Engineering“ genauer betrachtet:
Nach Wahl dieser Funktion muß eine Datenbank spezifiziert werden, auf die das
Tool angewendet werden soll. Zum Test wurde unter Microsoft-Access 2.0 eine
Datenbank angelegt, die dieselben Tabellen aufweist wie die bereits in Kapitel 4.3
betrachtete Test-Datenbank. Nach Auswahl dieser Datenbank im S-Designor startet die
Reverse Engineering-Funktion, die sehr schnell arbeitet und folgende BildschirmAusgaben erzeugt:
- 132 -
Der Anwender hat dabei an keiner Stelle die Möglichkeit, in den Algorithmus
einzugreifen. Das Ergebnis, das diese Funktion liefert, wird wie folgt dargestellt:
Hieran sieht man recht deutlich, daß der S-Designor kein Schema erzeugt, das dem
(E)ER-Modell entspricht, sondern die Tabellen der Access-Datenbank auf dem
- 133 -
Bildschirm ausgibt und über Namensgleichheiten referentielle Abhängigkeiten vermutet.
So wird beispielsweise der Verweis von „STG.MtkNr“ auf „SOS.MtkNr“ richtig
vermutet, die Beziehung zwischen „STG“ und „GDEX“ wird hingegen nicht erkannt,
weil die Attribute „Beugrund“ bzw. „Gdex“ unterschiedliche Namen haben. Selbst
wenn die entsprechenden Fremdschlüssel-Beziehungen direkt in Access definiert werden,
kann der S-Designor diese nicht auswerten und darstellen.
Verwunderlich ist auch das Ergebnis in Bezug auf die Attribute „Stg“ und „Abschl“
in Relation „STG“: Hier wird eine Beziehung zwischen „STG“ und „K_ABSTG“
vermutet, was, wie in Kapitel 4.3 zu sehen ist, sogar dem Datenbank-Zustand
widerspricht. Offensichtlich werden bei der Reverse Engineering-Funktion des SDesignor Instanzen nicht ausgewertet, denn sonst würde eine solche Beziehung nicht
vermutet werden.
Durch Nachbereitung des Schemas im S-Designor kann eine ähnliche Darstellung
gewonnen werden, wie bereits Microsoft-Access in seiner Funktion „Beziehungen“
bietet. Dabei werden die Tabellen der Datenbank auf dem Bildschirm ausgegeben und
Attribute, die durch Fremdschlüssel-Definitionen miteinander in Beziehung stehen,
werden durch einfache Pfeile verbunden. Einzig die Funktion, Verbindungen zwischen
gleichnamigen Attributen unterschiedlicher Relationen zu erzeugen, bietet Access nicht.
Aus diesem Grund fällt die Bewertung der Reverse Engineering-Funktion des SDesignor sehr negativ aus: Das Zielschema, das erzeugt wird, stellt nur die in der
Datenbank definierten Tabellen auf dem Bildschirm dar. Gleichnamige Attribute
verschiedener Tabellen werden miteinander verbunden, ohne daß Instanzen, die in der
Datenbank abgelegt sind, dabei beachtet werden. Fremdschlüssel-Informationen werden,
zumindest was Microsoft-Access angeht, aus dem ursprünglichen Datenbank-System
überhaupt nicht übernommen. Befremdlich wirkt außerdem, daß die Tabellen im SDesignor als „Entities“ bezeichnet werden - die Begriffe „Relationship“ oder
„Beziehung“ sind dem System hingegen unbekannt.
Die Existenz eines solchen Tools deutet aber darauf hin, daß in nächster Zeit im
Bereich „Reverse Engineering von Datenbanken“ einige Neuerungen zu erwarten sind.
Vielleicht bietet schon die nächste Version des S-Designor in dieser Hinsicht mehr
Möglichkeiten.
- 134 -
5 Ausblick
Wie bereits angemerkt, sind die im Rahmen dieser Arbeit entstandenen Programme noch
an einigen Stellen zu verbessern und zu erweitern:
• Das in Kapitel 3 vorgestellte Verfahren ist noch nicht vollständig im Programm
implementiert: Es fehlt noch die Behandlung von Aggregationen sowie die
Unterscheidung zwischen den verschiedenen Generalisierungs-Typen. Hier liegt
ein erster Ansatz, das Umsetzungs-Programm „rel2pre“ zu erweitern.
• Die Interaktivität der Werkzeuge „ora2rel“ sowie „rel2pre“ sollte erhöht werden
und der Anwender an mehr Stellen die Möglichkeit erhalten, in die UmsetzRoutinen einzugreifen. So kann es zum Beispiel sinnvoll sein, bei der Festlegung
der Kardinalitäten den Anwender mehr in den Umsetz-Prozeß einzubinden.
Außerdem hat der Nutzer bisher keinen Einfluß auf die Klassifizierung der
Tabellen - auch an dieser Stelle ist es vielleicht hilfreich, wenn das System beim
Anwender nachfragt, welche Klassifizierung sinnvoll ist. Jedoch ist dabei immer
abzuwägen, ob es sinnvoller ist, den Nutzer durch viele Fragen mehr in den
Umsetz-Prozeß einzubinden, oder ob es nicht besser ist, wenn die Programme
nahezu automatisch arbeiten und der Anwender erst nach der Umsetzung die
Möglichkeit erhält, das entstandene Zielschema zu ändern. Unter Beachtung
derselben Frage ist auch zu diskutieren, ob der Anwender schon während des
Umsetz-Prozesses Namen von EER-Objekten festlegen sollte.
• Einige Möglichkeiten, die zum Beispiel das Oracle-Datenbanksystem dem
Anwender bietet, werden von „ora2rel“ noch nicht ausgewertet. So ist zum
Beispiel aus Trigger-Definitionen ablesbar, wie die Kardinalitäten an Beziehungen
festzulegen sind. Die Analyse von Views kann helfen, Zusammenhänge zwischen
Relationen zu ermitteln, um beispielsweise Hinweise auf Fremdschlüssel zu
erhalten.
Durch
die
Untersuchung
von
Datenbank-Operationen
in
Anwenderprogrammen können weitere Informationen über den Aufbau einer
Datenbank gewonnen werden (vgl. [2,17], siehe Ende Kapitel 2).
- 135 -
• Durch die Teilung der Umsetzungs-Routine in die zwei Tools „ora2rel“ und
„rel2pre“ ist es verhältnismäßig einfach, neben Oracle auch andere DatenbankSysteme zu unterstützen. Um beispielsweise auch relationale Datenbanken eines
Informix-Systems in ein EER-Schema umzusetzen, ist es nur noch notwendig, ein
Programm „inf2rel“ zu entwickeln, das ein Relationenschema im vorgegebenen
Format (siehe Anhang A/a) erzeugt. Durch „rel2pre“ kann auch dieses aus einer
Informix-Datenbank entstandene Schema ausgewertet werden.
Diese Punkte betreffen aber nur die schon vorhandenen Werkzeuge. Der erste Schritt
sollte sicherlich die Entwicklung eines Programmes sein, das die Ausgabe-Schemata von
„rel2pre“ auswerten und als EER-Schema darstellen kann.
Eine andere Frage ist die Einbindung der entwickelten Tools in ein interaktives
Entwurfsunterstützungssystem. Ein mit den Programmen erzeugtes EER-Schema bildet
die Grundlage für einen neuen Datenbank-Entwurf. Durch die Analyse des EERSchemas können Fehler erkannt werden, die bei dem ursprünglichen Datenbank-Entwurf
gemacht wurden. Nach Behebung der Fehler muß aus dem EER-Schema wieder ein
Relationenschema gewonnen werden. Für diesen Vorgang gibt es bereits einige
Programme, die automatisch die zugehörigen Tabellen aufbauen. Die Kombination
solcher Tools mit den Programmen dieser Arbeit bildet so ein umfassendes Werkzeug,
um vorhandene relationale Datenbanken zu optimieren.
Das Ziel muß aber nicht immer ein Relationenschema sein. Ebenso ist es auch
denkbar, aus dem (verbesserten) EER-Schema eine objektorientierte Datenbank zu
entwickeln.
Ein weiterer Punkt ist die Art der Anwendung der Programme: In dieser Arbeit
wurde ausschließlich darauf eingegangen, wie man „überlieferte“ Relationenschemata
verbessert, indem man sie auf Basis des erzeugten EER-Schemas komplett neu entwirft.
Unter dem Stichwort „Vermächtnis-Systeme“ bzw. (englisch) „legacy systems“ sind zu
diesem Thema weitere Artikel in der Literatur zu finden. Demgegenüber ist ein System
wünschenswert, bei dem einer Änderung in der Relationen-Struktur nicht unbedingt eine
komplette neue Umsetzung mit Hilfe der Programme folgen muß, sondern bei dem eine
derartige Änderung auch „nur“ eine Änderung im EER-Schema hervorruft. Dadurch
kann die Pflege von relationalen Datenbanken erheblich vereinfacht werden. Jedoch ist
die Umsetzung eines kleinen Teils eines Relationenschemas problematisch, weil z.B.
- 136 -
Fremdschlüssel zwischen Tabellen nicht erkannt werden können, wenn die jeweilige
Referenztabelle nicht ebenfalls umgesetzt wird. Dennoch ist ein solches System
realisierbar, wenn der Anwender dafür sorgt, daß das alte EER-Schema und das neue
Teil-Schema in geeigneter Form kombiniert werden. Aber auch ein Algorithmus ist
vorstellbar, der diese Aufgabe übernimmt. Es muß dann aber darauf geachtet werden,
daß Relationenschema und EER-Schema quasi gleichzeitig verändert werden müssen.
Auch wenn nur eine Änderung des Relationenschemas im EER-Schema nicht
nachvollzogen wird, kann dies das Zielschema schon so stark verfälschen, daß die
Struktur der Datenbank nicht mehr erkannt wird. Sinnvoll wäre hier also eine
Datenbank-Umgebung, bei der Änderungen an der relationalen Struktur die sofortige
Änderung des zugehörigen EER-Schemas bewirkt.
Wenn man die Ankündigungen vieler Datenbank-Hersteller beachtet, so wird deutlich,
daß das Thema „Reverse Engineering“ zunehmende Bedeutung erhält. Nicht nur der in
Kapitel 4.7 kurz vorgestellte „S-Designor“ bietet eine Option zum „Reverse
Engineering“ an, auch die Firma Oracle hat für die nächste Version ihres
Datenbanksystems eine solche Möglichkeit angekündigt. Es ist aber auch verständlich,
daß immer mehr Hersteller von Datenbank-Managementsystemen sich mit diesem Thema
beschäftigen, denn viele bereits existierende Datenbanken bedürfen einer Überarbeitung
und Optimierung. Ein Werkzeug mit „Reverse Engineering“-Option kann den
Datenbank-Entwickler bei dieser Arbeit unterstützen.
- 137 -
Glossar
Abhängigkeit
In dieser Arbeit ist der Begriff „Abhängigkeit“ stets mit „referentieller
Abhängigkeit“ gleichzusetzen. Zwei Attribute, die in verschiedenen Relationen
gespeichert sind, bezeichnet man als referentiell abhängig voneinander, wenn die
Speicherung eines Wertes in der einen Tabelle die Speicherung desselben Wertes in
der anderen Relation voraussetzt (siehe auch Kapitel 2.4).
Data-Dictionary
Relationale →DBMS verwalten die Tabellen, Indexe, Attribute usw. der
verschiedenen Anwender intern auch mit Hilfe von Relationen. Die Gesamtheit
aller dieser System-Tabellen wird als Data-Dictionary bezeichnet.
Datenbank-Managementsystem (DBMS)
Ein DBMS verwaltet Daten und kümmert sich um den Zugriff auf eine Datenbank.
Die am weitesten verbreitete Sprache zum Zugriff auf →relationale Datenbanken
ist →SQL. Nahezu jedes moderne DBMS enthält diese Anfrage-Sprache.
Häufig anzutreffen sind die DBMS der Hersteller Oracle, Informix oder Sybase
(E)ER-Schema
Ein Schema, das dem →(E)ER-Modell genügt.
Entity-Relationship-Modell (ER-Modell)
Konzepte dieses Modells sind Entities (Objekte der realen Welt) und Relationships
(Beziehungen). Diese werden grafisch dargestellt (siehe auch Kapitel 2.3).
Erweitertes Entity-Relationship-Modell (EER-Modell)
Erweiterungen des →ER-Modells um Elemente wie „Generalisierungen“ oder
„Aggregationen“. Es gibt viele verschiedene Varianten des EER-Modells (siehe
auch Kapitel 2.3).
- 138 -
Feld
Einige Datenbank-Hersteller benutzen den Begriff „Feld“ statt „Attribut“. In dieser
Arbeit werden deshalb beide Bezeichnungen synonym verwendet.
„is a“-Beziehung
Beziehung zwischen zwei Entity-Typen, von denen eines als „Master“, eines als
„Slave“ bezeichnet wird. Zwischen Master und Slave besteht dabei eine InklusionsBeziehung bzw. →Abhängigkeit, bei der Slave vollständig in Master enthalten ist.
Bezogen auf das Relationenmodell bedeutet dies, daß die Slave-Tabelle zusätzliche
Daten zu einzelnen Datensätzen der Master-Relation enthält. Der Primärschlüssel
der Slave-Tabelle muß dazu den der Master-Tabelle enthalten.
relationale Datenbank
Daten werden in Form von Tabellen in einer Datenbank gespeichert. Eine Tabelle
wird dabei als Relation bezeichnet. Diese Art der Speicherung basiert auf dem
→Relationenmodell.
Relationenmodell
Das relationale Datenmodell beruht auf der Struktur Tabelle oder Relation. Jede
Zeile einer solchen Tabelle nennt man Tupel. Alle Informationen einer Datenbank,
also sowohl Objekte als auch ihre Beziehungen untereinander, werden durch
Relationen dargestellt. Beziehungen sind vorhanden, wenn ein Wert in mehreren
Tabellen vorkommt. Zwischen diesen Tabellen besteht dann eine →Abhängigkeit
(siehe auch Kapitel 2.4).
Relationenschema
Ein Schema, das dem →Relationenmodell genügt.
SQL
Structured Query Language = Strukturierte Anfrage-Sprache
SQL ist eine standardisierte Sprache für den Zugriff auf →relationale
Datenbanken. Sie enthält sowohl Befehle zur Datenselektion als auch zur
Datenmanipulation.
Trigger
Trigger (oder Triggered Procedures) enthalten Befehlsfolge(n), die nach Änderung
von Tabelleneinträgen aufgerufen werden und die Gültigkeit der Einträge prüfen.
Auf diese Weise kann die Integrität einer Datenbank sichergestellt werden.
- 139 -
Literaturhinweise
[1]
Albrecht, M.: Semantikakquisition im Reverse-Engineering. Reihe Informatik I
(4/94), Technische Universität Cottbus
[2]
Andersson, M.: Extracting an Entity Relationship Schema from a Relational
Database through Reverse Engineering. in: Proc. Thirteenth Internat. Conf. on
Entity Relationship Approach, 1994, S. 403-419
[3]
Batini, C. / Ceri, S. / Navathe, S.: Conceptual Database Design - An Entity
Relationship Approach. The Benjamin/Cummings Publishing Company,
Redwood City (California), 1992
[4]
Chiang, R.H.L. / Barron, T.M. / Storey, V.C.: Performance Evaluation of
Reverse Engineering Relational Databases into Extended Entity-Relationship
Models. in: Proc. Twelfth Internat. Conf. on Entity Relationship Approach, 1993,
S. 352-363
[5]
Chiang, R.H.L. / Barron, T.M. / Storey, V.C.: Reverse Engineering of Relational
Databases - Extraction of an EER Model from a Relational Database. in: Data
& Knowledge Engineering, Vol. 12, 1994, S. 107-142
[6]
Date, C.J.: An Introduction to Database Systems Vol. I (5th ed.). AddisonWesley Publ. Co., Reading (Mass.), 1990
[7]
Davis, K.H. / Arora, A.K.: Converting a Relational Database Model into an
Entity-Relationship Model. in: Proc. Seventh Internat. Conf. on Entity
Relationship Approach, 1988, S. 271-285
[8]
Hainaut, J.-L.: Database Reverse Engineering - Models, Techniques,
Strategies. in: Proc. Tenth Internat. Conf. on Entity Relationship Approach, 1991,
S. 729-741
[9]
Hainaut / Tonneau / Joris / Chandelon: Transformation-based Database Reverse
Engineering. in: Proceedings of the ER Conference, 1993
[10] Johannesson, P. / Kalman, K.: A Method for Translating Relational Schemas
into Conceptual Schemas. in: Proc. Eighth Internat. Conf. on Entity Relationship
Approach, 1989, S. 271-285
[11] Lipeck, U.W.: Skriptum zur Vorlesung „Datenbanksysteme“. Vorlesung an der
Universität Hannover, 1993
- 140 -
[12] Lipeck, U.W.: Skriptum zur Vorlesung „Datenbank-Entwurf“. Vorlesung an
der Universität Hannover, 1994
[13] Markowitz, V.M. / Makowsky, J.A.: Identifying Extended Entity-Relationship
Object Structures in Relational Schemas. in: IEEE Transactions on Software
Engineering, Vol. 16, No. 8, August 1990, S. 777-790
[14] Markowitz, V.M. / Shoshani, A.: An Overview of the Lawrence Berkeley
Laboratory Extended Entity-Relationship Database Tools. Technical Report
LBL-34932, Lawrence Berkeley Laboratory, Dezember 1993
[15] Markowitz, V.M. / Wang, J. / Fang, W.: SDT 6.3 - A Schema Definition and
Translation Tool for Extended Entity-Relationship Schemas (Reference
Manual). Technical Report LBL-27843, Lawrence Berkeley Laboratory,
Dezember 1993
[16] Navathe, S.B. / Awong, A.M.: Abstracting Relational and Hierarchical Data
with a Semantic Data Model. in: Proc. Sixth Internat. Conf. on Entity
Relationship Approach, 1987, S. 305-333
[17] Petit, J.-M. / Kouloumdjian, J. / Boulicaut, J.-F. / Toumani, F.: Using Queries to
Improve Database Reverse Engineering. in: Proc. Thirteenth Internat. Conf. on
Entity Relationship Approach, 1994, S. 369-385
[18] Premerlani, W.J. / Blaha, R.B.: An Approach for Reverse Engineering of
Relational Databases. in: Communications of the ACM 1994, Vol. 37, No. 5,
S. 42-49
[19] Shoval, P. / Shreiber, N.: Database Reverse Engineering - From the Relational
to the Binary Relationship Model. in: Data & Knowledge Engineering, Vol. 10,
1993, S. 293-315
[20] Signore, O. / Loffredo, M. / Cima, M.: Reconstruction of ER Schema from
Database Applications - a Cognitive Approach. in: Proc. Thirteenth Internat.
Conf. on Entity Relationship Approach, 1994, S. 387-401
[21] Szeto, E. / Markowitz, V.M.: ERDRAW 5.3 - A Graphical Editor for Extended
Entity-Relationship Schemas (Reference Manual). Technical Report LBLPUB-3084, Lawrence Berkeley Laboratory, Dezember 1993
[22] Ullmann, J.D.: Principles of Database and Knowledge-Base Systems (Vol. I).
Computer Science Press, Rockville (Md.), 1988
[23] Wenguang, J. / Carlson, C.R. / Dreyer, D.: An Algorithm Converting Relational
Schemas to Nested Entity Relationship Schemas. in: Proc. Tenth Internat. Conf.
on Entity Relationship Approach, 1991, S. 231-246
[24] Zehnder, C.: Informationssysteme und Datenbanken. Teubner, Stuttgart, 1989