Ubungstool zu Normalformen - Institut für Informatik

Leopold-Franzens-Universität Innsbruck
Institut für Informatik
Datenbanken und Informationssysteme
Übungstool zu Normalformen
Bachelor-Arbeit
Katja Sonderegger
betreut von
Michael Tschuggnall, MSc
Prof. Dr. Günther Specht
Innsbruck, 2. Juni 2014
Zusammenfassung
Normalformen waren und sind ein wichtiges Thema im Bereich von
Datenbanksystemen und werden deshalb auch in Lehrveranstaltungen
entsprechend behandelt. Um den Studenten das Verstehen und Erlernen dieses Themengebiets zu erleichtern, ist das Ziel dieser Arbeit, ein
Übungstool zur Lernunterstützung zu entwickeln. Dabei sollen sowohl
grundlegende Beispiele und Erklärungen zu den einzelnen Normalformen
gegeben werden, als auch die Möglichkeit bestehen, sich selbst anhand
von Übungsbeispielen zu testen und auf Fehler aufmerksam gemacht
zu werden. Das Übungstool wurde webbasiert umgesetzt und kann in
gängigen Browsern verwendet werden.
Abstract
Normal forms have been a very important topic in the area of databases
and still are. This is why it still is a topic in many computer science
lectures. To simplify the learning and understanding of this subject, the
aim of this thesis is to develop a learning tool, which should contain
examples and explanations of the different normal forms as well as the
possibility to test oneself. The normal form tool is web-based and can
be used with common browsers.
Inhaltsverzeichnis
1 Einleitung
1
2 Anforderungsspezifikation
2.1 Struktur . . . . . . . . . . . . .
2.1.1 Inhaltliche Ziele . . . .
2.1.2 Funktionale Ziele . . . .
2.2 Technologien . . . . . . . . . .
2.2.1 PHP und PHPUnit . . .
2.2.2 JavaScript bzw JQuery
2.2.3 CSS . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
6
6
7
8
3 Systemüberblick
3.1 Warum braucht es Normalformen? . . .
3.2 Atomare Attribute . . . . . . . . . . . .
3.3 Funktionale Abhängigkeiten . . . . . . .
3.4 Schlüssel . . . . . . . . . . . . . . . . . .
3.4.1 Superschlüssel . . . . . . . . . .
3.4.2 Schlüsselkandidaten . . . . . . .
3.4.3 Schlüsselattribut . . . . . . . . .
3.4.4 Voll funktionale Abhängigkeiten
3.5 Transitive Abhängigkeiten . . . . . . . .
3.6 Determinator . . . . . . . . . . . . . . .
3.7 Zerlegung . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
10
10
11
11
11
11
12
12
12
13
.
.
.
.
.
.
.
.
15
15
17
19
19
22
24
26
27
.
.
.
.
.
.
.
4 Systemimplementierung
4.1 Normalformenberechnung . . . .
4.1.1 Schlüsselkandidaten . . .
4.1.2 1. Normalform . . . . . .
4.1.3 2. Normalform (Kemper)
4.1.4 2. Normalform (Specht) .
4.1.5 3. Normalform . . . . . .
4.1.6 Boyce Codd Normalform
4.2 Minimale Überdeckung . . . . . .
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
4.3
4.4
4.5
4.6
4.7
Relationensynthese . . . . . . . . . . .
BCNF Dekomposition . . . . . . . . .
Übungen . . . . . . . . . . . . . . . . .
Automatische Fragebogengenerierung .
4.6.1 Fragebogen generieren . . . . .
4.6.2 Aufgaben generieren . . . . . .
Systemtest . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
33
36
38
38
39
41
5 Zusammenfassung
43
Literaturverzeichnis
46
IV
Katja Sonderegger
Kapitel 1
Einleitung
In der Informatik sind Datenbanken seit vielen Jahren ein wichtiges
und sehr häufig eingesetztes Konzept. Es gibt große Mengen an Daten,
die von Programmen verarbeitet, gespeichert und wieder abgerufen werden sollen. Um dies zu ermöglichen, existieren die unterschiedlichsten
Datenbanksysteme. Der größte Teil der heute existenten Systeme sind
relationale Datenbanksysteme und solche, die darauf aufbauen. Daher
ist es sehr wichtig, das relationale Konzept zu verstehen. In einem relationalen Datenbanksystem werden Daten in Tabellen - auch Relationen
genannt - abgespeichert, wobei jede Relation aus Attributen besteht und
eindeutig identifizierbar ist. Bei der Erstellung von Relationen werden
häufig Informationen redundant - also mehrfach - abgespeichert, was
eine ineffiziente Speichernutzung zur Folge hat. Auch Anomalien wie die
Insert-Anomalie, die Update-Anomalie und die Delete-Anomalie treten
häufig auf.
Beispiel 1.1. Beispiel einer Tabelle mit redundanten Informationen.
Uni
IBK
IBK
SZG
SZG
IBK
IBK
MatrNr
123456
123457
123458
123459
123450
124578
StdKennzahl
C 033 521
C 033 521
C 033 221
C 033 221
C 033 201
C 033 521
Studium
Informatik
Informatik
Mathematik
Mathematik
Mathematik
Informatik
LVnr
703020
703020
733021
733021
703025
703021
LV
DBS
DBS
LA
LA
M
WIS
Redundanz: Bei der Tabelle in Beispiel 1.1 werden sehr viele redundante Daten gespeichert. Für jeden Studenten werden erneut die Universität, die Lehrveranstaltungsinformationen und die Studieninformationen gespeichert.
1
KAPITEL 1. EINLEITUNG
Delete Anomalie: Sollte die Lehrveranstaltung gelöscht werden, werden damit auch die Studenten gelöscht. Wenn in der Tabelle in Beispiel
1.1 die Lehrveranstaltung DBS (Datenbanksysteme) gelöscht wird, da
die Lehrveranstaltung z.B. nicht mehr gehalten wird, dann verschwinden
damit auch die Informationen zu den Studenten und der Studienrichtung.
Insert Anomalie: Ein neuer Student kann erst dann gespeichert werden, wenn er sich für eine Lehrveranstaltung entschieden hat, da die
LVnr Teil des Schlüssels ist.
Update Anomalie: Sollte eine Information der Lehrveranstaltung sich
ändern, wie zum Beispiel der Lehrveranstaltungsname (LV), dann muss
dies für alle Tupel passieren. Das heißt konkret, dass wenn die Vorlesung
LA umbenannt wird zu LA2, dann müssen in Beispiel 1.1 bereits zwei
Tupel angepasst werden. Nachdem jeder Eintrag separat angepasst werden muss, kann es schnell passieren, dass ein Eintrag übersehen wird.
Hier spricht man von einer Update-Anomalie.
Um in den Relationen Redundanzen und Anomalien zu vermeiden, wurden von Edgar F. Codd die ersten drei Normalformen vorgeschlagen.
Diese wurden weiter ergänzt und kommen heute beim relationalen Datenbankentwurf zum Einsatz [Cod70]. Insgesamt gibt es fünf aufeinander
aufbauende Normalformen und eine Erweiterung der dritten Normalform, die sogenannte Boyce-Codd-Normalform (BCNF), welche von Codd
nachgereicht wurde [Cod71].
Die vierte Normalform geht auf Fagin [Fag77] zurück und wurde von
ihm 1977 als Erweiterung der BCNF eingeführt. Die fünfte Normalform
führte Fagin 1979 [Fag79] ein. In dieser Arbeit werden die Normalformen
bis inklusive der BCNF behandelt. Auf die vierte und fünfte Normalform wird hier nicht genauer eingegangen. Der interessierte Leser wird
auf [KE06] und [Spe13] verwiesen. Die heutige Auslegung der ersten bis
fünften Normalform inklusive der BCNF basiert auf der Überarbeitung
von Kent [Ken83].
Jede Normalform ist eine Einschränkung der vorhergehenden Normalform. So ist zum Beispiel die zweite Normalform eine Einschränkung der
ersten Normalform und somit ist eine Relation, die in zweiter Normalform ist, automatisch auch in der ersten Normalform. Die sich daraus
ergebende Hierarchie ist in Abbildung 1.1 grafisch dargestellt.
2
Katja Sonderegger
KAPITEL 1. EINLEITUNG
Abbildung 1.1: Normalformen-Hierarchie.
Um Relationen so darzustellen, dass keine Redundanzen oder Anomalien auftreten, sollte man mindestens die Normalformen von der ersten bis zur dritten Normalform inklusive der BCNF erfüllen. Daher
ist es wichtig, dass die Studierenden diese Normalformen beherrschen.
Aus diesem Grund wurde im Rahmen dieser Bachelorarbeit ein webbasiertes Übungstool zur Erarbeitung und Erlernung dieser Kernthemen
entwickelt. Die genauen Anforderungen an diese Bachelorarbeit und die
abgedeckten Themen werden in den folgenden Kapiteln erläutert.
Katja Sonderegger
3
Kapitel 2
Anforderungsspezifikation
Im Folgenden werden die inhaltlichen und funktionalen Ziele, sowie die
grobe Struktur dieser Arbeit beschrieben und die verwendeten Technologien vorgestellt.
2.1
2.1.1
Struktur
Inhaltliche Ziele
Das Tool behandelt inhaltlich folgende Themengebiete:
• Schlüsselkandidaten
• funktionale Abhängigkeiten
• voll funktionale Abhängigkeiten
• 1. Normalform
• 2. Normalform
• 3. Normalform (inkl. transitive Abhängigkeiten)
• BCNF (inkl. Determinatoren)
• minimale Überdeckung
• Relationensynthese
• BCNF-Dekomposition
2.1.2
Funktionale Ziele
Das Tool ist webbasiert umgesetzt und läuft ohne Probleme auf den
gängigen Browsern1 . Zusätzlich bietet das Tool weitere Funktionen, die
im Weiteren genauer erläutert werden.
1
Firefox, Chrome und Internet Explorer
5
KAPITEL 2. ANFORDERUNGSSPEZIFIKATION
Normalformerkennung
Unter der Normalformerkennung wird verstanden, dass man als Eingabeparameter eine Relation und deren funktionale Abhängigkeiten bereitstellt, und das Tool dann ausgibt in welcher Normalform sich diese Relation befindet. Es werden zwei verschiedene Arten der 2. Normalform
(einmal nach Specht und einmal nach Kemper) berücksichtigt.
Fragebogen
Um den Studenten der Lehrveranstaltung eine Möglichkeit zu geben, sich
selbst zu testen und das Erlernte einzuüben, gibt es die Möglichkeit,
Fragebögen zu verschiedenen Teilbereichen zu erstellen, beantworten
und auswerten zu lassen.
Zusatzfunktionen
Zusätzlich zu den bereits erwähnten Funktionen bietet das Tool die Möglichkeit, aus einer gegebenen Relation und deren funktionalen Abhängigkeiten eine BCNF-Dekomposition, eine Relationensynthese und die
minimale Überdeckung zu berechnen.
2.2
Technologien
In diesem Abschnitt werden die verwendeten Technologien vorgestellt.
2.2.1
PHP und PHPUnit
Da das Übungstool webbasiert umgesetzt werden sollte, wurde vor allem
auf XHTML mit PHP 5.5.9 gesetzt.
Zum Testen der in PHP implementierten Algorithmen wurde PHPUnit
verwendet. PHPUnit ist ein Tool zum automatisierten Testen von PHP
Code.
<?php
// require all files containing the code to test
require_once ’../functions/helperFunctions.php’;
class FunctionsTest extends PHPUnit_Framework_TestCase
{
public function testGetMinimalKeys()
{
// Arrange
$relation = array(
6
Katja Sonderegger
KAPITEL 2. ANFORDERUNGSSPEZIFIKATION
’A’,’B’,’C’,’D’,’E’
);
// A,B,C->D;B->E;E->A
$fd = array(
array(
array(’A’, ’B’, ’C’),
array(’D’),
),
array(
array(’B’),
array(’E’),
),
array(
array(’E’),
array(’A’),
),
);
// Act
$possibleKeys = getMinimalKeys($relation, $fd);
// Assert
$expectedKeys = array(array(’B’, ’C’));
$this->assertEquals($expectedKeys, $possibleKeys);
}
}
?>
Codebeispiel 2.1: PHPUnit Codebeispiel.
In Codebeispiel 2.1 wird die Funktion “getMinimalKeys” getestet, die
die minimalen Schlüsselkandidaten zu einer gegebenen Relation und
deren funktionalen Abhängigkeiten berechnet. Mit Hilfe von Assertions
können die Ergebnisse verglichen werden.
Wie im Codebeispiel ersichtlich, muss in PHPUnit jede Funktion, die
getestet werden soll, ihren Namen mit “test” beginnen. Im Beispielcode
oben heißt daher die Funktion testGetMinimalKeys().
2.2.2
JavaScript bzw JQuery
JavaScript ist eine Skriptsprache, die oft verwendet wird, um auf die
Eingabe des Benutzers zu reagieren. JQuery ist eine freie JavaScriptBibliothek, die die Verwendung von JavaScript erleichtert.
Katja Sonderegger
7
KAPITEL 2. ANFORDERUNGSSPEZIFIKATION
2.2.3
CSS
CSS (Cascading Style Sheets) ist eine deklarative Sprache und wird in
dieser Arbeit verwendet, um die vorhandenen XHTML Elemente visuell
darzustellen. Der Großteil der Arbeit wurde mit Hilfe von Bootstrap2
gestaltet.
2
8
[http://getbootstrap.com/] - 10. Mai 2014
Katja Sonderegger
Kapitel 3
Systemüberblick
Abbildung 3.1: Menü des Übungstools.
Wie man in Abbildung 3.1 sieht, besteht das Tool aus verschiedenen
Bereichen:
Startseite
Auf der Startseite gibt es einige einleitende Worte.
Fakten und Regeln
In den Fakten und Regeln werden alle Begriffe anhand von Beispielen erklärt.
Normalformberechnung
Hier ist der Kern des Normalformen-Tools: die Normalformberechnung, als auch die zusätzlichen Algorithmen (minimale Überdeckung, Relationensynthese, BCNF-Dekomposition).
Übungen
Hier können die von den Übungsleitern hochgestellten Übungsaufgaben bearbeitet werden.
Tools
Bei Tools kann ein Fragebogen generiert werden oder explizit eine
Aufgabe generiert werden, die in einer bestimmten Normalform
ist.
9
KAPITEL 3. SYSTEMÜBERBLICK
Hilfe
Diese Arbeit, sowie weitere Hilfestellungen, werden unter diesem
Punkt verlinkt.
Referenzen
Alle Referenzen befinden sich hier.
Um die Funktion des webbasierten Normalformen-Übungstools genauer
erklären zu können, benötigt es zuerst die Definition und Erläuterung
einiger Begriffe. Falls nicht anders angemerkt, sind die folgenden Definitionen und Erklärungen aus [Spe13] entnommen.
3.1
Warum braucht es Normalformen?
In relationalen Datenbanksystemen werden Daten mit Hilfe von Tabellen
(Relationen) gespeichert. Bei der Erstellung dieser Relationen ist es
wichtig, bestimmte Punkte zu beachten, damit man später nicht redundante Informationen abspeichert und nicht mehr Datenbankzugriffe
als unbedingt nötig machen muss, um einen Datensatz zu speichern, zu
bearbeiten oder zu löschen.
Um die Erstellung von “guten” Tabellen zu erleichtern und die oben
genannten Probleme zu verhindern, wurden bereits in den frühen 50er
Jahren erste Versuche gestartet, Regeln zu definieren, nach denen man
sich richten konnte. Diese Regeln wurden im Laufe der Zeit immer wieder
abgeändert und erweitert, bis schlussendlich die heute bekannten Normalformen entstanden sind. Von den derzeit fünf Normalformen (+ BCNF) sind vor allem die ersten drei und die BCNF entscheidend. Die
vierte und fünfte Normalform werden eher selten gebraucht.
3.2
Atomare Attribute
Die einzelnen Spaltenelemente der Tabelle werden auch Attribute genannt. Wenn diese atomar sind, bedeutet das, dass das Element weder ein
Array, eine Liste, eine Struktur noch eine Menge ist. Anders gesagt: die
Attribute sind nicht weiter zerlegbar.
3.3
Funktionale Abhängigkeiten
In Relationen kann es funktionale Abhängigkeiten geben. Funktionale
Abhängigkeiten sind wie folgt definiert:
Gegeben sei die Relation R(A1 , ..., An ) und X,Y ⊆ A1 , ..., An
10
Katja Sonderegger
KAPITEL 3. SYSTEMÜBERBLICK
Eine Attributkombination Y heißt funktional abhängig
von X, wenn in jedem möglichen Tupel von R die
Werte von Y durch die von X eindeutig bestimmt sind.
In Zeichen: X → Y ( X bestimmt Y“)
”
3.4
Schlüssel
Grundsätzlich sind hier verschiedene Begriffe zu unterscheiden, welche
im Folgenden näher erläutert werden.
3.4.1
Superschlüssel
Ein Superschlüssel ist eine Kombination von Attributen, über deren
funktionale Abhängigkeiten (FA) alle restlichen Attribute der Relation
erreicht werden können. Der einfachste Weg einen Superschlüssel zu finden, ist die Berechnung der Attributhülle. Sind alle Elemente der Relation
auch in der Attributhülle enthalten, so ist diese Attributkombination
ein Superschlüssel. Hier ist anzumerken, dass ein Superschlüssel beliebig
viele Elemente enthalten kann und es in einer Relation viele verschiedene
Superschlüssel geben kann.
Beispiel 3.1. Superschlüssel.
Relation
FA
{A,B,C,D,E}
{A → BC, D → E}
Hier gibt es folgende Superschlüssel: AD, ADE, ADB, ADC, ..., ABCDE
3.4.2
Schlüsselkandidaten
Ein Schlüsselkandidat ist ein Superschlüssel mit der zusätzlichen Anforderung, dass der Superschlüssel minimal sein soll.
Die minimalen Superschlüssel aus Beispiel 3.1 sind: AD.
Somit ist AD in diesem Beispiel der einzige Schlüsselkandidat.
3.4.3
Schlüsselattribut
Schlüsselattribute sind alle Elemente, die im Schlüsselkandidat enthalten
sind. In Beispiel 3.1 sind die Schlüsselattribute: A,D und folglich alle
Nicht-Schlüsselattribute: B,C,E.
Katja Sonderegger
11
KAPITEL 3. SYSTEMÜBERBLICK
3.4.4
Voll funktionale Abhängigkeiten
Funktionale Abhängigkeiten wurden bereits erklärt. Allerdings gibt es
noch eine Verfeinerung der funktionalen Abhängigkeit - die voll funktionale Abhängigkeit:
Gegeben sei die Relation R(A1 , ..., An ) und X,Y ⊆ A1 , ..., An
Eine Attributkombination Y heißt voll funktional abhängig
von X, wenn Y funktional abhängig von X ist, aber
nicht funktional abhängig von einer echten Teilmenge
von X ist. In Zeichen X →
˙ Y
Gibt es nur einelementige Schlüssel, dann sind alle funktionalen Abhängigkeiten auch voll funktional abhängig von jedem Schlüssel.
3.5
Transitive Abhängigkeiten
Transitive Abhängigkeiten werden wie folgt definiert:
In einer Relation R ist eine Attributkombination Z
transitiv abhängig von X, wenn Z funktional abhängig
von Y und Y funktional abhängig von X ist. Dabei
muss zusätzlich gelten, dass X nicht auch funktional
?
abhängig von Y ist. In Zeichen: X →
− Z.
?
Formal ist X →
− Z gleichbedeutend zu:
1. X → Y und Y → Z
2. X, Y, Z verschieden
3. Es darf nicht gelten: Y → X
3.6
Determinator
Ein Determinator ist wie folgt definiert:
Gegeben sei die Relation R(A1 , ..., An ) und X,Y ⊆ A1 , ..., An
X heißt Determinator von Y, wenn Y von X voll funktional abhängig ist. D.h. Det(Y) = X ist gleichbedeu?
tend zu X →
− Y
12
Katja Sonderegger
KAPITEL 3. SYSTEMÜBERBLICK
3.7
Zerlegung
Eine Zerlegung ist die Aufteilung einer Relation in mehrere kleine Relationen. Hierbei kann man verlustfreie, abhängigkeitsbewahrende Zerlegungen erhalten.
Gegeben sei eine Relation R, die in die Relationen R1 ,..., Rn zerlegt wird.
Verlustfreiheit
Diese Zerlegung ist verlustfrei, wenn alle zerlegten Relationen R1 ,..., Rn
wieder zusammengefügt werden können und das Ergebnis wieder die
Anfangsrelation R ist. Kurz: R:= R1 ∪...∪ Rn
Abhängigkeitsbewahrung
Die Zerlegung ist abhängigkeitsbewahrend, wenn alle in R geltenden
funktionalen Abhängigkeiten (F) erhalten bleiben, das heißt, dass gefordert wird, dass FR := FR1 ∪...∪ FRn
Katja Sonderegger
13
Kapitel 4
Systemimplementierung
Nachdem die wichtigsten Begriffe im vorhergehenden Kapitel erklärt
wurden, befasst sich der folgende Teil mit der Funktionalität des Normalformentools und den verwendeten Algorithmen.
4.1
Normalformenberechnung
Die Normalformenberechnung ist der Kern des Normalformen-Tools. Hier wird aus einer gegebenen Relation und deren funktionalen Abhängigkeiten berechnet, in welcher Normalform sich die Relation befindet.
Abbildung 4.1: Normalformen-Tool Eingabe.
Abbildung 4.1 zeigt die Eingabe der Normalformberechnung. Hier können
die Elemente, die in der Relation enthalten sind, im Feld “Relationsschema” angegeben werden. Die zugehörigen funktionalen Abhängigkeiten
15
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
werden im Feld “funktionale Abhängigkeiten” angegeben, wobei einzelne
funktionale Abhängigkeiten mit einem Strichpunkt getrennt werden,
während die Elemente innerhalb der Abhängigkeiten mit einem Beistrich
getrennt werden.
Beispielsweise ist eine mögliche Eingabe:
A, B → C; C → A; C → D; C → E; D → B
Abbildung 4.2: Normalformen-Tool Ausgabe.
Die Ausgabe der Normalformberechnung ist in Abbildung 4.2 zu sehen. In diesem Fall wurde ausgewählt, dass die Berechnung nicht in der
zweiten Normalform laut Specht erfolgen soll, sondern in der zweiten
Normalform laut Kemper.
In Abbildung 4.3 ist die Ausgabe der Normalformberechnung laut Specht
zu sehen.
In den Abbildungen 4.2 und 4.3 ist die Normalformberechnung des Tools
ersichtlich und wird hier nun genauer erklärt.
Bevor die Berechnung der einzelnen Normalformen durchgeführt wird,
werden die Eingabedaten auf ihre Korrektheit überprüft. Anschließend
werden die Schlüsselkandidaten berechnet - also jene Attribute, mit denen man alle anderen Attribute der Relation erreichen kann.
16
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Abbildung 4.3: Normalformen-Tool Ausgabe inkl. Specht.
4.1.1
Schlüsselkandidaten
Für die Berechnung der Schlüsselkandidaten wird ein rekursiver Algorithmus verwendet, der schlussendlich alle minimalen Schlüsselkandidaten zurückgibt.
Input:
R
FA
K
Relation R mit ihren Attributen
alle funktionalen Abhängigkeiten (FA) der Relation R
Attribute (K), die später der minimale Schlüsselkandidat werden
sollen (zu Beginn ist K = {x |x ∈ R})
Output:
Array von minimalen Schlüsselkandidaten
Algorithmus:
1. überprüfe, ob die Attribute K bereits einen Superschlüssel darstellen
2. ist K bereits ein Superschlüssel, wird ein kleinerer Superschlüssel
gesucht, indem jeweils ein Attribut (a) von K entfernt wird und
überprüft wird, ob (K − a) immer noch ein Superschlüssel ist
3. wenn (K − a) ein Superschlüssel ist, wurde ein kleinerer Schlüsselkandidat gefunden und die Funktion wird erneut mit dem neuen
minimalen Schlüssel (K − a) aufgerufen
Katja Sonderegger
17
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
4. wenn kein neuer minimaler Schlüssel gefunden wurde, wird K zu
den minimalen Schlüsselkandidaten hinzugefügt
Die Überprüfung, ob eine Kombination von Attributen ein Schlüsselkandidat ist, wird mit Hilfe der Attributhülle berechnet. Die Attributhülle
ist die Menge aller Elemente, die über die funktionalen Abhängigkeiten
von einer Attributkombination erreicht werden kann. Diese Menge wird
mit den Relationselementen verglichen. Wenn die Hülle alle Elemente
der Relation enthält, ist die Attributkombination ein Superschlüssel.
Erläuterung der verwendeten Funktionen:
• isKey(relation, fd, attributes)
Die Funktion isKey berechnet mit Hilfe der Attributhülle, ob eine
Menge von Attributen (attributes) ein Superschlüssel zur gegebenen Relation und ihren funktionalen Abhängigkeiten ist. Die Funktion gibt einen Wahrheitswert zurück.
• arrayContains(minimalKeys, newMinimalKey)
Die Funktion arrayContains vergleicht zwei Arrays miteinander,
und überprüft, ob der neue minimale Superschlüssel im derzeitigen
minimalen Superschlüssel enthalten ist und gibt dementsprechend
einen Wahrheitswert zurück.
attributes = relation;
getMinimalKeysRecursive(relation, fd, attributes) {
if isKey(relation, fd, attributes) then
foundSmallerKey = false;
foreach attribute in attributes do
reducedAttributes = attributes - attribute;
if isKey(relation, fd, reducedAttributes) then
foundSmallerKey = true;
newMinimalKeys = getMinimalKeysRecursive(relation, fd,
reducedAttributes);
foreach newMinimalKey in newMinimalKeys do
if !arrayContains(minimalKeys, newMinimalKey) then
minimalKeys[] = newMinimalKey;
if !foundSmallerKey then
if !arrayContains(minimalKeys, attributes)
minimalKeys[] = attributes;
return minimalKeys;
}
then
Codebeispiel 4.1: Berechnung der Schlüsselkandidaten.
Nachdem die Schlüsselkandidaten berechnet wurden, werden die einzelnen Normalformen berechnet. Das Normalformen-Tool deckt die erste
18
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Normalform, zweite Normalform, dritte Normalform, sowie die BCNF
ab, welche im Folgenden erläutert werden:1
4.1.2
1. Normalform
Eine Relation R ist in der ersten Normalform, wenn
all ihre Domänen nur elementare Werte enthalten.
Die erste Normalform wird in diesem Tool schon von den gegebenen Relationen vorausgesetzt und wird daher nicht überprüft.
Beispiel 4.1. Negativbeispiel für die erste Normalform und Lösung.
MatrNr.
123456
234567
Nachname
Sonderegger
Stricker
Vorname
Katja
Benedikt
LV
DBS, Funktionale Prog.
WebInfoSys, LinAlg
Die oben dargestellte Relation enthält Matrikelnummer und Namen von
Studenten und die Lehrveranstaltungen die sie besuchen. Hier ist die
erste Normalform verletzt, weil das Attribut LV eine Liste von Lehrveranstaltungen enthält, was in der ersten Normalform nicht erlaubt ist. In
der ersten Normalform sieht die Relation wie folgt aus:
MatrNr.
123456
123456
234567
234567
Nachname
Sonderegger
Sonderegger
Stricker
Stricker
Vorname
Katja
Katja
Benedikt
Benedikt
LV
Datenbanksysteme
Funktionale Prog.
Webinformationssysteme
Lineare Algebra
Hier werden die Lehrveranstaltungen nicht gemeinsam als Struct, Liste
oder Menge gespeichert, und somit erfüllt diese Relation die erste Normalform.
Im Folgenden wird die zweite Normalform erläutert. Hierbei sei erwähnt,
dass im Normalformen-Tool zwei verschiedene Definitionen der zweiten Normalform implementiert wurden. Für genauere Informationen zu
den einzelnen Normalformen wird auf [KE06] für die zweite Normalform
laut Kemper und auf [Spe13] für die zweite Normalform laut Specht
verwiesen.
4.1.3
2. Normalform (Kemper)
Die zweite Normalform laut Kemper ist wie folgt definiert:
1
Auch hier gilt wieder, dass alle Definitionen, wenn nicht anders angegeben aus
den Unterlagen der Vorlesung entnommen sind [Spe13].
Katja Sonderegger
19
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Eine Relation R mit zugehörigen FA F ist in zweiter Normalform, falls jedes Nichtschlüssel-Attribut A ∈
R voll funktional abhängig ist von jedem Kandidatenschlüssel der Relation. [KE06]
Die Berechnung der zweiten Normalform laut Kemper ist in folgendem
Algorithmus angegeben und wird wie folgt durchgeführt:
Input:
R
FA
K
Relation R mit ihren Attributen
alle funktionalen Abhängigkeiten (FA) der Relation R
Array mit allen minimalen Schlüsselkandidaten
Output:
Wahrheitswert, der mitteilt, ob die Relation in zweiter
Normalform laut Kemper ist oder nicht
Algorithmus:
1. zuerst wird überprüft, ob es nur einelementige Schlüsselkandidaten
gibt, wenn ja, dann ist die Relation bereits in zweiter Normalform
und der Algorithmus ist beendet.
2. ist dies nicht der Fall, werden alle Nichtschlüsselattribute ermittelt und für jeden Schlüsselkandidaten wird überprüft, ob alle
Nichtschlüsselattribute voll funktional abhängig vom gesamten
Schlüsselkandidaten sind. Ist dies nicht der Fall, ist die Relation
nicht in zweiter Normalform laut Kemper.
Erläuterung der verwendeten Funktionen:
• getFullFunctionalDependency(nonKeyAttribute, key, fd)
Die Funktion getFullFunctionalDependency gibt einen Wahrheitswert zurück, der mitteilt, ob eine funktionale Abhängigkeit zu
einem Schlüsselkandidaten (key) besteht.
checkSecondLikeKemper(relation, fd, keys){
inKemper = false;
if all keys have only one attribute then
inKemper = true
else
nonKeyAttributes = relation;
foreach key in keys do
nonKeyAttributes = nonKeyAttributes - key;
if nonKeyAttribute is empty then
inKemper = true;
else
20
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
inKemper = true;
foreach key in keys do
foreach nonKeyAttribute in nonKeyAttributes do
if !getFullFunctionalDependency(nonKeyAttribute, key
, fd) do
inKemper = false;
return inKemper;
}
Codebeispiel 4.2: Berechnung der zweiten Normalform nach Kemper.
Beispiel 4.2. Negativbeispiel für die zweite Normalform nach Kemper
und Lösung.
MatrNr
123456
234567
StudentNachname
Sonderegger
Stricker
Dozent
Specht
Gassler
LV
Datenbanksysteme
WebInfoSys
Die oben dargestellte Relation enthält Matrikelnummer und Nachname
von Studenten und den Namen des Dozenten, bei dem sie eine Lehrveranstaltung besuchen.
Die funktionalen Abhängigkeiten sind folgende:
MatrNr → StudentNachname
Dozent → LV
Daraus ergibt sich der zusammengesetzte Schlüsselkandidat: (MatrNr,
Dozent).
Hier ist die zweite Normalform verletzt, da LV von einem Teil des
Schlüsselkandidaten (Dozent) abhängig ist. Selbiges gilt für den StudentNachname, der von MatrNr abhängig ist. Um die zweite Normalform nach Kemper zu erfüllen, kann die Relation in folgende Relationen
aufgeteilt werden:
MatrNr
123456
234567
Dozent
Specht
Gassler
StudentNachname
Sonderegger
Stricker
LV
Datenbanksysteme
Webinformationssysteme
Katja Sonderegger
21
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
MatrNr
123456
234567
4.1.4
Dozent
Specht
Gassler
2. Normalform (Specht)
Eine Relation R ist in 2NF, wenn gilt:
1. R ist in 1NF, und
2. Für jeden Schlüsselkandidaten SK gilt: alle Attribute
im Komplement von SK sind voll funktional abhängig
vom SK.
Die Berechnung der zweiten Normalform laut Specht2 ist in folgendem
Algorithmus angegeben und wird wie folgt durchgeführt:
Input:
R
FA
K
Relation R mit ihren Attributen
alle funktionalen Abhängigkeiten (FA) der Relation R
Array mit allen minimalen Schlüsselkandidaten
Output:
Wahrheitswert, der mitteilt, ob die Relation in zweiter
Normalform laut Specht ist oder nicht
Algorithmus:
1. zuerst wird überprüft, ob es nur einelementige Schlüsselkandidaten
gibt, wenn ja, dann ist es bereits in zweiter Normalform und der
Algorithmus ist beendet.
2. ist dies nicht der Fall, werden für jeden Schlüssel alle Nichtschlüsselattribute ermittelt und überprüft, ob alle Nichtschlüsselattribute voll funktional abhängig vom gesamten Schlüsselkandidaten
sind. Ist dies nicht der Fall, ist die Relation nicht in zweiter Normalform laut Specht.
checkSecondLikeSpecht(relation, fd, keys){
inSpecht = false;
if all keys have only one attribute then
inSpecht = true;
2
Diese strengere Definition geht laut Specht bis auf eine Vorlesungsmitschrift aus
dem Jahr 1986 der Vorlesung von Professor R. Bayer, Datenbanksysteme I, gehalten
an der TU München, zurück.
22
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
else
foreach key in keys do
nonKeyAttributes = relation;
nonKeyAttributes = nonKeyAttributes - key;
if nonKeyAttributes is empty then
inSpecht = true;
else
inSpecht = true;
foreach nonKeyAttribute in nonKeyAttributes do
if !getFullFunctionalDependency(nonKeyAttribute, key,
fd) do
inSpecht = false;
return inSpecht;
}
Codebeispiel 4.3: Berechnung der zweiten Normalform nach Specht.
Beispiel 4.3. Negativbeispiel für die zweite Normalform nach Specht.
Gegeben sei eine Relation, in der die Matrikelnummer und das Studium
eines Studenten abgespeichert wird. Zusätzlich wird auch noch die Universität, an der er dieses Studium absolviert, abgespeichert.
Dann ergeben sich folgende funktionale Abhängigkeiten:
MatrNr, Studium → Universität
Universität → Studium
Schlüsselkandidaten: (MatrNr, Studium) und (MatrNr, Universität)
MatrNr
123456
789012
456789
Studium
Informatik
Informatik
Biologie
Universität
Universität Innsbruck
Universität Wien
Universität Innsbruck
In der Definition nach Kemper wird hier kein Attribut überprüft,
da alle Attribute Teil eines Schlüsselkandidaten sind. Daher ist diese
Relation in der zweiten Normalform nach Kemper.
In der Definition nach Specht hingegen werden mehrere Attribute
überprüft, da die Überprüfung bezüglich jedes Schlüssels separat durchgeführt wird:
• Universität wird für Schlüsselkandidat (MatrNr, Studium) geprüft
und
• Studium wird für Schlüsselkandidat (MatrNr, Universität) geprüft.
– Bei der Überprüfung von Studium bezüglich des Schlüsselkandidaten (MatrNr, Universität) ist die zweite Normalform
Katja Sonderegger
23
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
nach Specht durch die funktionale Abhängigkeit Universität
→ Studium verletzt, da hier das Studium von einem Teil des
Schlüsselkandidaten abhängig ist.
4.1.5
3. Normalform
Die dritte Normalform ist wie folgt definiert:
Ein Relationsschema R ist in dritter Normalform, wenn
für jede für R geltende funktionale Abhängigkeit der
Form α → B mit α ⊆ R und B ∈ R mindestens eine
von drei Bedingungen gilt:
• B ∈ α, d.h. die FA ist trivial.
• Das Attribut B ist in einem Kandidatenschlüssel
von R enthalten - also B ist prim.
• α ist Superschlüssel von R.
[KE06, Seite 188]
Eine alternative Definition der dritten Normalform ist wie folgt definiert:
Eine Relation R ist in 3NF, wenn gilt
1. R ist in 2NF, und
2. R enthält keine transitiven Abhängigkeiten[Spe13]
Die Berechnung der dritten Normalform basiert auf der Definition nach
[KE06, Seite 188] und wird wie folgt durchgeführt:
Input:
R
FA
K
Relation R mit ihren Attributen
alle funktionalen Abhängigkeiten (FA) der Relation R
Array mit allen minimalen Schlüsselkandidaten
Output:
Wahrheitswert, der mitteilt, ob die Relation in dritter
Normalform ist oder nicht
Algorithmus:
1. für jede funktionale Abhängigkeit wird überprüft, ob sie:
• trivial ist
24
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
• die rechte Seite der funktionalen Abhängigkeit aus Schlüsselattributen besteht
• ob die linke Seite ein Superschlüssel ist
2. trifft für jede der funktionalen Abhängigkeiten eine der oben genannten Eigenschaften zu, ist die Relation in der dritten Normalform.
Erläuterung der verwendeten Funktionen:
• checkConditionsForThird(nonKeyAttributes, keyAttributes,
fd, relation)
Die Funktion checkConditionsForThird gibt einen Wahrheitswert
zurück, der true zurück gibt, wenn alle funktionalen Abhängigkeiten mindestens eine der drei Bedingungen der Definition erfüllen.
Ansonsten wird false zurückgegeben.
checkThird(relation, fd, keys) {
inThird = false;
nonKeyAttributes = relation;
foreach key in keys do
nonKeyAttributes = nonKeyAttributes - key;
foreach attribute in relation do
if attribute is in keys then
keyAttributes[] = attribute;
if nonKeyAttributes is empty then
inThird = true;
else
if checkConditionsForThird(nonKeyAttributes, keyAttributes,
fd, relation) then
inThird = true;
return inThird;
}
Codebeispiel 4.4: Berechnung der dritten Normalform.
Beispiel 4.4. Negativbeispiel für die dritte Normalform und Lösung.
Gegeben sei folgende Situation: Ein Student nimmt an einer Prüfung
teil. Für diese Prüfung existiert nachfolgende Relation in der man nachsehen kann, in welchem Hörsaal die Prüfung abgehalten wird. Es stehen
zwei Hörsäle zur Verfügung. Alle Studenten deren Anfangsbuchstabe des
Nachnamen zwischen A und L liegt, schreiben in HS A - alle anderen in
HS B.
Daraus ergeben sich folgende funktionale Abhängigkeiten:
MatrNr. → Vorname, Nachname
Nachname → Prüfungshörsaal
Katja Sonderegger
25
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
MatrNr
123456
234567
789020
Nachname
Sonderegger
Stricker
Amann
Vorname
Katja
Benedikt
Franz
Prüfungshörsaal
HS B
HS B
HS A
Diese Relation ist nicht in dritter Normalform, weil die funktionale Abhängigkeit Nachname → Prüfungshörsaal die dritte Normalform verletzt.
In der dritten Normalform würde die Relation in folgende Relationen
aufgeteilt werden:
MatrNr
123456
234567
789020
Nachname
Sonderegger
Stricker
Amann
Nachname
Sonderegger
Stricker
Amann
4.1.6
Vorname
Katja
Benedikt
Franz
Prüfungshörsaal
HS B
HS B
HS A
Boyce Codd Normalform
Die Boyce Codd Normalform (BCNF) ist wie folgt definiert:
Ein Relationsschema R mit FAs F ist in BCNF, falls
für jede funktionale Abhängigkeit α → β mindestens
eine der folgenden zwei Bedingungen gilt:
• β ⊆ α, d.h. die Abhängigkeit ist trivial oder
• α ist Superschlüssel von R[KE06, Seiten 190,191]
Die Berechnung der BCNF ist in folgendem Algorithmus angegeben und
wird wie folgt durchgeführt:
Input:
R
FA
K
Relation R mit ihren Attributen
alle funktionalen Abhängigkeiten (FA) der Relation R
Array mit allen minimalen Schlüsselkandidaten
Output:
Wahrheitswert, der mitteilt, ob die Relation in BCNF
ist oder nicht
Algorithmus:
26
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
1. für jede funktionale Abhängigkeit wird überprüft, ob die linke Seite
ein Superschlüssel ist. Ist dies nicht der Fall, so ist die Relation
nicht in BCNF.
checkBCNF(relation, fd, keys) {
foreach dependency in fd do
check = false;
left = left side of dependency;
if isKey(relation, fd, left) then
check = true;
if !check then
return false;
return true;
}
Codebeispiel 4.5: Berechnung der BCNF.
Beispiel 4.5. Negativbeispiel für die BCNF.
Gegeben sei eine Relation, in der die Matrikelnummer und das Studium
eines Studenten abgespeichert wird. Zusätzlich wird auch noch die Universität, an der er dieses Studium absolviert, abgespeichert.
Dann ergeben sich folgende funktionale Abhängigkeiten:
MatrNr, Studium → Universität
Universität → Studium
Schlüsselkandidaten: (MatrNr, Studium) und (MatrNr, Universität)
MatrNr
123456
789012
456789
Studium
Informatik
Informatik
Biologie
Universität
Universität Innsbruck
Universität Wien
Universität Innsbruck
Diese Relation ist nicht in BCNF, da das Studium von der Universität
abhängig ist und die Universität kein Superschlüssel ist.
4.2
Minimale Überdeckung
Die minimale Überdeckung3 ist die Reduktion der funktionalen Abhängigkeiten, sodass die überflüssigen funktionalen Abhängigkeiten entfernt werden und eine minimale Version der funktionalen Abhängigkeiten
entsteht. Es gibt immer eine minimale Überdeckung, allerdings ist sie
3
in der Literatur wird die minimale Überdeckung auch kanonische Überdeckung
genannt
Katja Sonderegger
27
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
nicht immer eindeutig, das heißt, es kann mehrere unterschiedliche minimale Überdeckungen geben.
Definition:[KE06, Seite 177]
Zu einer gegebenen Menge F von FA nennt man Fc eine minimale
Überdeckung, falls folgende drei Eigenschaften erfüllt sind:
1. Fc ≡ F, d.h. Fc + = F+
2. In Fc existieren keine FA α → β, bei denen α oder β überflüssige
Attribute enthalten. D.h. es muss folgendes gelten:
(a) ∀ A ∈ α: (Fc - (α → β) ∪ ((α - A) → β)) 6≡ Fc
(b) ∀ B ∈ β: (Fc - (α → β) ∪ ((α → (β - B))) 6≡ Fc
3. Jede linke Seite einer funktionalen Abhängigkeit in Fc ist einzigartig. Dies kann durch sukzessive Anwendung der Vereinigungsregel
auf FA der Art α → β und α → γ erzielt werden, so dass die
beiden FA durch α → βγ ersetzt werden.
Der folgende Algorithmus wurde aus [KE06, Seite 177-178] übernommen:
Algorithmus:
Zu einer gegebenen Menge F von FA kann man eine minimale Überdeckung wie folgt bestimmen:
1. Führe für jede FA α → β ∈ F die Linksreduktion durch, also:
• Überprüfe für alle A ∈ α, ob A überflüssig ist, d.h. ob
β ⊆ AttrHülle(F, α − A)
gilt. Falls dies der Fall ist, ersetze α → β durch α − A → β.
2. Führe für jede (verbliebene) FA α → β die Rechtsreduktion durch,
also:
• Überprüfe für alle B ∈ β, ob
B ∈ AttrHülle(F − (α → β) ∪ (α → (β − B)), α)
gilt. In diesem Fall ist B auf der rechten Seite überflüssig und
kann eliminiert werden, d.h. α → β wird durch α → (β − B)
ersetzt.
3. Entferne die FA der Form α → ∅, die im 2. Schritt entstanden
sind.
28
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
4. Fasse mittels der Vereinigungsregel4 FA der Form α → β 1 , ..., α →
β n zusammen, so dass α → (β 1 ∪ ... ∪ β n ) verbleibt.
Erläuterung der verwendeten Funktionen:
• reduceLeftSide(relation, fd)
Die Funktion reduceLeftSide reduziert die linke Seite aller gegebenen funktionalen Abhängigkeiten (fd), sodass nur die notwendigen
Attribute auf der linken Seite stehen.
• reduceRightSide(relation, fd)
Die Funktion reduceRightSide reduziert die rechte Seite aller gegebenen funktionalen Abhängigkeiten (fd), sodass nur die notwendigen
Attribute auf der rechten Seite stehen.
getMinimalCover(relation, fd) {
fd = reduceLeftSide(relation, fd);
fd = reduceRightSide(relation, fd);
foreach dependency in fd do
if dependency -> right is empty then
remove dependency from fd;
if there are fds with same left side in fd then
summarize into one dependency;
return fd;
}
Codebeispiel 4.6: Berechnung der minimalen Überdeckung.
In Abbildung 4.4 sieht man die Ausgabe der Berechnung der minimalen
Überdeckung anhand eines Beispiels.
Beispiel 4.6. Berechnung der minimalen Überdeckung.
Relation R = A, B, C, D, E, F
A → BC
C → AD
E → ABC
F → CD
Schlüsselkandidaten (EF)
1. zuerst wird die Linksreduktion durchgeführt:
• A → BC - kann nicht reduziert werden
• C → AD - kann nicht reduziert werden
• E → ABC - kann nicht reduziert werden
4
Wenn α → β und α → γ gelten, dann gilt auch α → βγ.[KE06, Seite 176]
Katja Sonderegger
29
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Abbildung 4.4: Ausgabe der Berechnung der minimalen Überdeckung.
• F → CD - kann nicht reduziert werden
Da alle linken Seiten bereits minimal sind, bleibt nach der
Linksreduktion das Ergebnis das selbe.
2. Rechtsreduktion:
• A → BC - kann nicht reduziert werden
• C → AD - kann nicht reduziert werden
• E → ABC - da wir mit C über C → AD bereits A erreichen,
kann A entfernt werden. Auch B erreichen wir anschließend
durch A mit A → BC. ⇒ Reduktion der FA auf: E → C
• F → CD - da wir mit C über C → AD bereits D erreichen,
kann D entfernt werden. ⇒ Reduktion der FA auf: F → C
Ergebnis nach der Rechtsreduktion: A → BC, C → AD, E
→ C, F → C
3. da keine der neuen FA in der Form X → ∅ ist, kann keine FA
entfernt werden.
4. da keine der neuen FA die selbe linke Seite hat, und somit nichts
zusammengefügt werden kann, ist hiermit die Berechnung fertig.
30
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Ergebnis: A → BC, C → AD, E → C, F → C
4.3
Relationensynthese
Die Relationensynthese ist ein Algorithmus, um aus einer Relation und
deren funktionalen Abhängigkeiten eine verlustlose, abhängigkeitsbewahrende Zerlegung zu finden, mit der sich alle neuen Relationen in
der dritten Normalform befinden. Der Algorithmus wurde von Biskup,
Dayal und Bernstein [BDB79] eingeführt.
Algorithmus:
1. Bestimme die minimale Überdeckung G zur Menge der funktionalen
Abhängigkeiten F.
2. Erzeuge eine eigene Relation für Attribute, die in keiner FA vorkommen.
3. Für jedes X in funktionalen Abhängigkeiten X → A1 ,..., X → An
∈ G:
• Erzeuge eine Relation RX := X ∪ A1 ∪ ... ∪ An
• Ordne der Relation alle FA zu, von denen alle Attribute in
RX enthalten sind.
4. Falls keine der erzeugten Relationen einen Schlüsselkandidaten
enthält, wähle einen Schlüsselkandidaten SK und erzeuge eine zusätzliche Relation RSK := SK.
Erläuterung der verwendeten Funktionen:
• getMinimalCover(relation, fd)
Die Funktion getMinimalCover berechnet die minimale Überdeckung der funktionalen Abhängigkeiten (fd).
• getMinimalKeys(relation, fd)
Die Funktion getMinimalKeys berechnet die minimalen Schlüsselkandidaten zur gegebenen Relation und ihren funktionalen Abhängigkeiten.
getRelationSynthese(relation, fd){
fd = getMinimalCover(relation, fd);
keys = getMinimalKeys(relation, fd);
/*if one attribute is not in any functional dependency*/
foreach attribute in relation do
inRelation = false;
Katja Sonderegger
31
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
foreach dependency in fd do
if attribute is in dependency then
inRelation = true;
if !inRelation then
newRelation[] = attribute;
allRelations[] = newRelation;
foreach dependency in fd do
elements = attributes of dependency;
foreach dependency2 in fd do
if (leftSide is in dependency) && (rightSide is not in
dependency) then
if rightSide is not in elements then
elements[] = rightSide;
allRelations[] = elements;
newRelationFDs[][] = get all functional dependencies for
elements;
/*one more relation if no key is part of a relation*/
boolean = false;
foreach relation in allRelations do
if key is in relation then
boolean = true;
if !boolean then
allRelations[] = key;
return allRelations;
}
Codebeispiel 4.7: Berechnung der Relationensynthese.
In Abbildung 4.5 sieht man die Ausgabe der Berechnung der Relationensynthese anhand eines Beispiels.
Beispiel 4.7. Berechnung der Relationensynthese.
Relation R = A, B, C, D, E, F
A → BC
C → AD
E → ABC
F → CD
Schlüsselkandidaten (EF)
1. minimale Überdeckung: A → BC, C → AD, E → C, F → C
2. alle Attribute sind in den funktionalen Abhängigkeiten enthalten
3. für alle funktionalen Abhängigkeiten
• Relation R1 = A, B, C
• Relation R2 = A, C, D
32
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Abbildung 4.5: Ausgabe der Berechnung der Relationensynthese.
• Relation R3 = C, E
• Relation R4 = C, F
4. da kein Schlüsselkandidat vorhanden ist, wird eine zusätzliche Relation erstellt. Relation R5 = E, F
Ergebnis:
• Relation R1 = A, B, C mit A → BC
• Relation R2 = A, C, D mit C → AD
• Relation R3 = C, E mit E → C
• Relation R4 = C, F mit F → C
• Relation R5 = E, F
4.4
BCNF Dekomposition
Die BCNF Dekomposition ist ein Algorithmus, der eine Relation R zerlegt, sodass die Zerlegung verlustlos und in der BCNF ist. Dies ist für
jede Relation verlustlos möglich, allerdings ist hier die Bewahrung der
Abhängigkeiten nicht immer gegeben.
Katja Sonderegger
33
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Die BCNF Dekomposition wird wie im folgenden Algorithmus angegeben
berechnet [KE06, Seiten 191,192]:
Input:
R
FA
Relation R mit ihren Attributen
alle funktionalen Abhängigkeiten (FA) der Relation R
Output:
Z
die verlustlose, Zerlegung Z = R1 ,...,Rn in BCNF
Algorithmus:
1. starte mit Z = R
2. Solange es noch ein Relationsschema Ri ∈ Z gibt, das nicht in
BCNF ist, mache folgendes:
• Finde eine für Ri geltende nicht-triviale FA (a → b) mit a ∩
b = ∅ UND a 6→ Ri
• Zerlege Ri in Rn := a ∪ b und Ri2 := Ri - b
• Entferne Ri aus Z und füge Ri1 und Ri2 ein, also
Z := (Z - Ri ) ∪ Ri1 ∪ Ri2
Erläuterung der verwendeten Funktionen:
• checkNormalforms(relation, fd, keys)
Die Funktion checkNormalforms berechnet für die Relation und
ihren funktionalen Abhängigkeiten, in welcher Normalform sie sich
befindet, und gibt das Ergebnis zurück.
• getAllViolatingFDs(relation, fd, keys)
Die Funktion getAllViolatingFDs sucht alle funktionalen Abhängigkeiten, die die BCNF verletzen, und gibt diese in einem Array
zurück.
BCNFDecomposition(relation, fd) {
keys = getMinimalKeys(relation, fd);
/*nf Array contains numbers (21-Specht, 22-Kemper, 3-third NF
, 31-BCNF)*/
nf = checkNormalforms(relation, fd, keys);
if 31 is in nf then
"Already in BCNF";
return relation;
else
boolean = false;
dependencies = getAllViolatingFDs(relation, fd, keys);
34
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
foreach dependency in dependencies do
elements = dependency -> right;
FDs[] = dependency;
R[] = elements;
relation = relation - elements;
R[] = relation;
FDs[] = get dependencies for relation;
return R;
}
Codebeispiel 4.8: Berechnung der BCNF-Dekomposition.
In Abbildung 4.6 sieht man die Ausgabe der Berechnung der BCNF
Dekomposition anhand eines Beispiels.
Abbildung 4.6: Ausgabe der Berechnung der BCNF Dekomposition.
Beispiel 4.8. Berechnung der BCNF Dekomposition.
Relation R = A, B, C, D, E
A→B
C→D
Schlüsselkandidaten (A, C, E)
1. Z:= R
2. für jede funktionale Abhängigkeit, die die BCNF verletzt, wird
eine neue Relation erstellt. Die ursprüngliche Relation verliert alle
Katja Sonderegger
35
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Elemente, die in der rechten Seite der funktionalen Abhängigkeit
vorkommen:
• für funktionale Abhängigkeit: A → B Relation R2 = A, B
Z ist nun: {R1 = A, C, D, E;
R2 = A, B}
• für funktionale Abhängigkeit: C → D Relation R3 = C, D
Z ist nun: {R1 = A, C, E;
R2 = A, B;
R3 = C, D}
Ergebnis:
• Relation R1 = A, C, E
• Relation R2 = A, B mit A → B
• Relation R3 = C, D mit C → D
Das Normalformen-Tool bietet dem Benutzer zusätzlich zu den oben
genannten Algorithmen die Möglichkeit, sich selbst zu testen. Dies kann
auf zwei verschiedene Arten gemacht werden.
4.5
Übungen
Die Übungen im Normalformen-Tool können von den LV-Leitern auf
den Server gestellt werden, und stehen anschließend den Studenten zur
Verfügung.
Hier besteht für den LV-Leiter die Möglichkeit, beliebige Fragen und
deren Antwortmöglichkeiten einzutragen. So können alle möglichen
Übungsaufgaben zur Verfügung gestellt werden.
Abbildung 4.7: Übungsfiles, die auf dem Server liegen und von den LVLeitern zur Verfügung gestellt wurden.
36
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
In Abbildung 4.7 ist die Liste der zur Verfügung gestellten Übungen zu
sehen.
Abbildung 4.8: Übungsfiles werden vom Server geladen und können
beantwortet werden.
Sobald man eine Übung ausgewählt hat, ist es möglich, die Aufgaben
zu beantworten und abzuschicken, was in Abbildung 4.8 ersichtlich ist.
Anschließend erhält man eine Auswertung, wo dem Benutzer bei falscher
Beantwortung mitgeteilt wird, was die richtige Antwort gewesen wäre.
Die Auswertung ist in Abbildung 4.9 ersichtlich.
Abbildung 4.9: Validierung des ausgefüllten Fragebogen.
Katja Sonderegger
37
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
4.6
Automatische Fragebogengenerierung
Mit dem Normalformen-Tool können auch Übungsbeispiele und ganze
Fragebögen generiert werden.
4.6.1
Fragebogen generieren
Bei der Generierung eines Fragebogens werden vom Benutzer die Anzahl
der Relationselemente eingegeben und die Anzahl der Übungsaufgaben,
die er im Fragebogen haben möchte. Zusätzlich kann ausgewählt werden,
ob man die zweite Normalform nach der Definition von Specht oder nach
der Definition von Kemper enthalten haben möchte. Die Generierung
eines Fragebogen und der generierte Fragebogen ist in den Abbildungen
4.10 und 4.11 zu sehen.
Generierung eines Fragebogens:
Input:
R
F
Anzahl der Elemente der Relation
Anzahl der Fragen, die generiert werden sollen
Output:
Fragebogen, der ausgefüllt werden kann
Algorithmus:
1. es werden zufällig funktionale Abhängigkeiten generiert
2. mit diesen Abhängigkeiten wird überprüft, in welcher Normalform die Relation mit den funktionalen Abhängigkeiten ist, woraus
schlussendlich der Fragebogen zusammengesetzt wird
3. zuletzt werden alle Fragen und Antworten dargestellt
Abbildung 4.10: Generierung eines Fragebogens.
38
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Abbildung 4.11: Ausgabe des generierten Fragebogens.
4.6.2
Aufgaben generieren
Bei der Generierung von Aufgaben werden vom Benutzer die Anzahl
der Relationselemente eingegeben und die Anzahl der Aufgaben, die er
haben möchte. Zusätzlich kann ausgewählt werden, ob man die zweite
Normalform nach der Definition von Specht oder nach der Definition
von Kemper enthalten haben möchte, und in welcher Normalform sich
die Aufgaben befinden sollen.5
Abbildung 4.12: Generieren von Aufgaben.
Generierung von Aufgaben:
5
Die angegebene Normalform ist die “höchste” Normalform, die noch gültig ist.
Katja Sonderegger
39
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
Input:
R
F
N
Anzahl der Elemente der Relation
Anzahl der Aufgaben, die generiert werden sollen
die Normalform in der die Aufgaben sein sollen
Output:
funktionale Abhängigkeiten, die sich in der gegebenen
Normalform befinden
Algorithmus:
1. es werden zufällig funktionale Abhängigkeiten generiert
2. mit diesen Abhängigkeiten wird überprüft in welcher Normalform
die Relation mit den funktionalen Abhängigkeiten ist. Ist die Relation in der gewünschten Normalform, wird sie für die spätere
Ausgabe gespeichert, wenn nicht wird wieder ab Schritt 1 wiederholt.
3. zuletzt werden alle Aufgaben wie in Abbildung 4.12 dargestellt.
Sowohl bei der Generierung der Fragebögen, als auch bei der Generierung von Aufgaben, besteht die Möglichkeit, sich die Aufgaben als
Latexcode ausgeben zu lassen. Diese Ausgabe ist in Abbildung 4.13 zu
sehen.
Abbildung 4.13: Ausgabe des Latexcode.
40
Katja Sonderegger
KAPITEL 4. SYSTEMIMPLEMENTIERUNG
4.7
Systemtest
Insgesamt wurde mit Hilfe von PHPUnit ein Großteil der Funktionen, die
nicht auf Eingaben basieren mit Testdaten aus verschiedenen Übungsblättern getestet. Die daraus resultierende Code Coverage ist in den
Screenshots in 4.14 und 4.15 ersichtlich:
Abbildung 4.14: Code Coverage der Algorithmen ohne Generierung.
In Abbildung 4.14 ist die Code Coverage der Funktionen zu sehen, die
das Projekt ausmachen.
Abbildung 4.15: Codecoverage der Normalformenalgorithmen.
Die Abbildung 4.15 zeigt die Code Coverage der Normalformenberechnung. Die linke Seite der Abbildung zeigt an, welche Funktionen direkt
aufgerufen werden. Die mit 0.00% angeführten Funktionen werden von
anderen Funktionen aufgerufen. Dies ist auch auf der rechten Seite der
Abbildung ersichtlich, da hier die Testabdeckung anhand der Codezeilen
angegeben wird.
Katja Sonderegger
41
Kapitel 5
Zusammenfassung
Das Normalformen-Übungstool ist ein webbasiertes Übungstool, das den
Studenten das Erlernen und Einüben der Normalformen erleichtern soll.
Das Tool bietet Beispiele und Erklärungen zu allen Begriffen, die die Studenten im Zusammenhang mit den Normalformen kennen sollten. Außerdem erklärt es auch wichtige Algorithmen wie die minimale Überdeckung,
Relationensynthese und BCNF Dekomposition.
Einer der Kernbereiche des Übungstools ist die Normalformerkennung.
Diese ermöglicht ein schnelles Feststellen, in welcher Normalform sich
eine Relation befindet und bietet mit Hilfe der oben genannten Algorithmen auch die Möglichkeit, die Relationen in die dritte Normalform
beziehungsweise BCNF zu bringen.
Die Lehrveranstaltungsleiter können Fragebögen zur Verfügung stellen,
die die Studenten dann beantworten und validieren lassen können. Außerdem ist es möglich, Fragebögen automatisch generieren zu lassen.
Das Tool kann funktionale Abhängigkeiten generieren, die in einer bestimmten Normalform sind, und diese dann als Latexcode ausgeben. Dies
ermöglicht unter anderem den LV-Leitern eine schnellere Erstellung von
Übungsblättern.
43
Literaturverzeichnis
[BDB79] J. Biskup, U. Dayal and P. A. Bernstein: Synthesizing Independent Database Schemas, Proceedings of the 1979 ACM SIGMOD International Conference on Management of Data, SIGMOD ’79, ACM, New York, NY, USA, pages 143–151, URL
http://doi.acm.org/10.1145/582095.582118.
[Cod70] E. F. Codd: A Relational Model of Data for Large Shared Data
Banks, Commun. ACM, volume 13(6), (1970), pages 377–387,
URL http://doi.acm.org/10.1145/362384.362685.
[Cod71] E. F. Codd: Further Normalization of the Data Base Relational
Model, IBM Research Report, San Jose, California, volume
RJ909.
[Fag77]
R. Fagin: Multivalued Dependencies and a New Normal Form
for Relational Databases, ACM Trans. Database Syst., volume 2(3), (1977), pages 262–278, URL http://doi.acm.
org/10.1145/320557.320571.
[Fag79]
R. Fagin: Normal Forms and Relational Database Operators,
Proceedings of the 1979 ACM SIGMOD International Conference on Management of Data, SIGMOD ’79, ACM, New York,
NY, USA, pages 153–160, URL http://doi.acm.org/10.
1145/582095.582120.
[KE06]
A. Kemper and A. Eickler: Datenbanksysteme: eine
Einführung, Oldenbourg, 2006, URL http://books.
google.at/books?id=YezXpIacjkgC.
[Ken83] W. Kent: A Simple Guide to Five Normal Forms in Relational
Database Theory, Commun. ACM, volume 26(2), (1983), pages
120–125, URL http://doi.acm.org/10.1145/358024.
358054.
[Spe10]
G. Specht: Vorlesung Datenbanksysteme, 2010, URL
http://dbis-informatik.uibk.ac.at/files/ext/
45
LITERATURVERZEICHNIS
lehre/ws10-11/vo-datenbanksysteme/skript/
dbs-kap06.pdf, [Online; accessed 14-April-2014].
[Spe13]
46
G. Specht: Vorlesung Datenbanksysteme, 2013, URL http://
dbis-informatik.uibk.ac.at/files/ext/lehre/
ws13-14/VO-DBS/DBS-Kap06-NF-MUC-NEU.pdf, [Online; accessed 19-February-2014].
Katja Sonderegger