Universalrelation

1 Anfragen an UniversalrelationSysteme
Zusammenhang zwischen
dem Stellen von relationalen Anfragen und
der Navigation im relationalen Datenbankschema her.
Erleichterung des Anfragen-Stellens:
Query-by-Example: graphische Hilfsmittel (Tableaus)
Jetzt: kein Aufwand, mehrere Relationen explizit zu verbinden.
Universalrelation-System zielt primär auf gelegentliche Benutzer ab
Datenbank-Experten profitieren vom geringeren Schreibaufwand.
Wir stellen die Arbeitsweise eines Universalrelation-Frontends vor, sowie
ihre effiziente Berechnung insbesondere für die Klasse der γ-azyklischen
Datenbankschemas.
Wir zeigen insbesondere, wie man aus einer SQL-ähnlichen UniversalrelationAnfrage eine gewöhnliche SQL-Anfrage erzeugt.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
1
1.1
Das Stellen von Anfragen als Navigation
durch das Datenbankschema
relationales Datenbankschema als Hypergraph
verallgemeinerter Graph, dessen (Hyper-)kanten eine Menge von Knoten enthalten
[nicht nur Zweiermengen (oder Paare) von Knoten wie bei (gerichteten) Graphen].
Die Attribute des Datenbankschemas sind die Knoten.
Jedes Relationenschema ist eine Hyperkante des Hypergraphen; sie enthält alle
Attribute des Relationenschemas
zeichnerisch: Kringel, der genau diese Attribute umschließt.
Manchmal zusätzlich nötig:
rechteckige Rollen-Hyperkanten: maximale Mengen von Attributen, die sich auf
die gleichen Entities (wenn auch in verschiedenen Rollen) beziehen.
Beispiel: Arztpraxis (vereinfacht).
Geschlecht
ELT
BEH
ArtPro
Name
Eltern
Patient
PERSON
Arzt
Mensch
Wir stellen zunächst einige Überlegungen zusammen, wie man die im letzten
Semester vorgestellten relationalen Anfragesprachen (SQL, QbE, Relationenalgebra,
Relationenkalkül) benutzt.
Ein Benutzer findet in der Regel bereits ein (vom Datenbankadministrator
vereinbartes) relationales Datenbankschema vor, das man durch einen Hypergraphen
veranschaulichen kann.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
2
Ein zunächst umgangssprachlich ausgedrückter Anfragewunsch muss dann zu
einem Ausdruck der Relationenalgebra oder des Relationenkalküls formalisiert
werden.
Diese Formalisierung kann oft nach folgendem Muster erfolgen:
1. Für die umgangssprachlich vorliegenden Begriffe müssen formale
Entsprechungen als Attribute, Relationensymbole, Entitybezeichnungen oder
Konstantenzeichen bestimmt werden.
2. Für die umgangssprachlich vorliegenden Zusammenhänge zwischen den
Begriffen müssen formal entsprechende Pfade im Hypergraphen des Schemas
bzw. ein für die Anfrage relevanter Teilhypergraph gefunden und dann relational
ausgedrückt werden.
3. Für die umgangssprachlich vorliegenden Zwecke des Anfragewunsches müssen
formale Entsprechungen als Selektionen und Projektionen ausgedrückt werden.
4. Abschließend können noch mit Hilfe der algebraischen Eigenschaften vom
Benutzer oder automatisch vom Datenbankverwaltungssystem Optimierungen
vorgenommen werden (die wir im folgenden Beispiel nur für die
Relationenalgebra beschreiben).
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
3
a. Anfragewunsch: "Bestimme Geschlecht und Eltern des Kindes theresia!"
Schritt 1: Den nominalen Begriffen Kind, Geschlecht und Eltern entsprechen
die Attribute ELT.Name, PERSON.Geschlecht und ELT.Eltern;
beteiligt sind die Relationensymbole PERSON und ELT.
Schritt 2: Für ein Kind sollen Geschlecht und Eltern bestimmt werden. Diesem
Zusammenhang entspricht der Pfad Geschlecht, PERSON, Name,
ELT, Eltern im Hypergraphen. Der relevante Teil des Hypergraphen ist
daher:
Geschlecht
ELT
Eltern
PERSON
Name
In diesem Fall ist die benötigte Verbindung über das Attribut Name bereits im
Datenbankschema angelegt und kann direkt mit Hilfe des natürlichen
Verbundes ausgedrückt werden:
PERSON ELT bzw.
PERSON(Name, Geschlecht) ∧ ELT(Name, Eltern) bzw.
º
SELECT *
FROM PERSON, ELT
WHERE PERSON.Name=ELT.Name
Schritt 3: Dem vorliegenden Zweck, Daten zum Konstantenzeichen theresia
zu erfragen, entspricht die abschließende Selektion:
σName=theresia(PERSON ELT) bzw.
PERSON(Name, Geschlecht) ∧ ELT(Name, Eltern) ∧ (Name=theresia) bzw.
º
SELECT *
FROM PERSON, ELT
WHERE PERSON.Name=ELT.Name AND PERSON.Name='theresia'
Schritt 4: Die Selektion nach dem Wert theresia des Attributs
PERSON.Name bzw. ELT.Name kann vorgezogen werden:
σName=theresia(PERSON) σName=theresia(ELT)
º
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
4
b. Anfragewunsch: "Bestimme alle Ärzte, die weibliche Patienten behandeln!"
Schritt 1: Den nominalen Begriffen Arzt und Patient entsprechen die Attribute
BEH.Arzt und BEH.Patient; dem adjektiven Begriff weiblich entspricht
das Konstantenzeichen Πals ein Wert des Attributs PERSON.Geschlecht;
dem verbalen Begriff behandeln entspricht das Relationensymbol BEH.
Schritt 2: Dem vorliegenden Zusammenhang zwischen Patienten und ihrem
Geschlecht entspricht der Pfad Arzt, BEH, Patient, Mensch,
Name, PERSON, Geschlecht im Hypergraphen. Der relevante Teil des
Hypergraphen ist dann:
Geschlecht
PERSON
Name
Patient
BEH
Arzt
Mensch
In diesem Fall muss die benötigte Verbindung zwischen den
Relationensymbolen BEH und PERSON erst durch eine Umbenennung des
Attributs Patient in Name oder mit Hilfe eines Equijoins oder eines
Vergleichs hergestellt werden:
δPatient←Name(BEH) PERSON oder
BEH Patient=Name PERSON oder
σPatient=Name(BEH PERSON) bzw.
º
º
º
BEH(Patient, Arzt, ArtPro) ∧ PERSON(Name, Geschlecht) ∧ (Patient=Name)
bzw.
SELECT *
FROM BEH, PERSON
WHERE Patient=Name
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
5
Schritt 3: Dem vorliegenden Zweck, nur die Ärzte der weiblichen Patienten zu
bestimmen, entspricht eine Selektion nach dem Konstantenzeichen Œ für das
Attribut PERSON.Geschlecht und eine abschließende Projektion nach
dem Attribut BEH.Arzt:
πArzt(σGeschlecht=Œ(δPatient←Name(BEH) PERSON)) oder
πArzt(σGeschlecht=Œ(BEH Patient=Name PERSON)) oder
πArzt(σGeschlecht=Œ(σPatient=Name(BEH PERSON))) bzw.
º
º
º
(∃ Patient)(∃ ArtPro)(∃ Name)(∃ Geschlecht) [BEH(Patient, Arzt, ArtPro) ∧
PERSON(Name, Geschlecht) ∧ (Patient=Name) ∧ (Geschlecht=Œ)]
SELECT Arzt
FROM BEH, PERSON
WHERE Patient=Name AND Geschlecht='Œ'
Schritt 4: Die Selektion nach dem Konstantenzeichen Πdes Attributs
PERSON.Geschlecht sowie das Entfernen des Attributs BEH.ArtPro
können vorgezogen werden:
πArzt(δPatient←Name(BEH) σGeschlecht=Œ(PERSON)) oder
πArzt(πPatient,Arzt(BEH) Patient=Name σGeschlecht=Œ(PERSON)) oder
πArzt(σPatient=Name(πPatient,Arzt(BEH) σGeschlecht=Œ(PERSON))
º
º
º
In Universalrelation-Systemen konstruiert man die Schemas gerne so, dass
keine Rollenhyperkanten nötig sind.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
6
1.2
Ziele und Arbeitsweise von
Universalrelation-Systemen
In relationalen Datenbanksystemen stellt man eine Anfrage, indem man angibt:
• die gewünschten Ausgabeattribute,
• die beteiligten Relationen,
• sowie die Bedingungen zur Auswahl der Ausgabetupel.
Dazu gehören auch Bedingungen, die festlegen, wie die beteiligten
Relationen verknüpft werden sollen.
schwierigste Operation für Benutzer: der Verbund von Relationen
Ziel: Benutzer entlasten von der expliziten Verknüpfung der Relationen.
fiktive "Universalrelation" enthält die Information aus allen Relationen der
Datenbank (und ist daher eine Relation über allen Attributen der Datenbank).
Bei Anfragen sind dann nur noch die Tupel geeignet auszuwählen:
die Anfragen werden einfacher.
Bei Universalrelation-Systemen braucht der Benutzer daher bei Anfragen nur noch
• die gewünschten Ausgabeattribute anzugeben, sowie
• die Bedingungen, die für diese Anfrage gelten sollen.
Das Universalrelation-System ermittelt dann
• die für die Anfrage nötigen Relationen sowie
• die dazu passenden Verbundbedingungen.
Das Universalrelation-System ermittelt dazu einen relevanten (aber möglichst
kleinen) Ausschnitt des Datenbankschemas, den sog. Anfragehypergraphen.
Wichtig ist, dass es zu einer Anfrage nur einen einzigen Anfragehypergraphen gibt,
da das Universalrelation-System aufgrund der ihm zur Verfügung stehenden Daten
nicht erkennen kann, welchen Teil der Datenbank (oder gar den Durchschnitt oder
die Vereinigung der zu den Anfragehypergraphen gehörenden Relationen) der
Benutzer im Sinn hatte.
Die Verknüpfung der Relationen des Anfragehypergraphen findet mit dem
natürlichen Verbund statt.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
7
Welcher Teil der Datenbank für eine Anfrage benutzt werden soll, muss aus den in
der Anfrage genannten Attributen ermittelt werden.
Rollen, die die Attribute bei einer Datenbankanfrage (als relationalen Ausdruck)
spielen:
• das Attribut ist Ausgabeattribut,
• das Attribut kommt im Bedingungsteil vor, ist aber kein Ausgabeattribut,
• das Attribut wird als Verbundattribut benötigt, kommt aber weder als
Ausgabeattribut noch im Bedingungsteil vor, und
• das Attribut wird für diese Anfrage nicht benötigt.
Die ersten beiden Attributmengen kommen explizit in der Anfrage an ein
Universalrelation-System vor, die dritte Attributmenge wird vom UniversalrelationSystem berechnet.
Ein Universalrelation-System ist also in der Lage, aus der Attributmenge einer
Anfrage die erforderlichen Verbundbedingungen zu erzeugen, so dass ein Benutzer
des Universalrelation-Systems nicht mehr die Relationen und die Art der
Verbundenheit des Schemas zu kennen braucht, sondern nur noch die Attribute.
Wir stellen hier ein Universalrelation-Frontend vor, das mit einer SQL-ähnlichen
Sprache arbeitet. Soweit wir uns auf den semantisch eindeutigen Fall der γazyklischen Datenbankschemas beschränken, können wir eine optimierte Semantik
verwenden, die i.a. mit weniger Verbundoperationen auskommt.
Die Vorteile eines Universalrelation-Systems werden durch das nachfolgende
Beispiel anschaulich:
Beispiel 1: Unsere Beispieldatenbank enthält Informationen über Bücher, ihre
Autoren und Verlage sowie über die in der Bibliothek vorhandenen Exemplare:
Ein Buch wird identifiziert durch seine ISBN.
Jedes Buch kann mehrfach in einer Bibliothek vorhanden sein, verschiedene
Exemplare eines Buches haben stets die gleiche ISBN, unterscheiden sich jedoch in
Signatur und Inventarnummer.
Verlage werden identifiziert durch die ersten Stellen der ISBN ihrer Bücher, den
ISBN-Code.
Weitere Attribute eines Verlags sind der Verlagsname sowie das mengenwertige
Attribut Verlagsort.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
8
Verlagsname
Verlag
Verlagsort
ISBN-Code
Entity-Relationship-Diagramm
für Beispiel 1
wird
verlegt
Inventarnr
Signatur
ISBN
Exemplar
ist
Exemplar
von
Titel
Buch
Erscheinungsjahr
Auflage
Hrsg
hat
Autor
Autor
Position
Autorenname
Das zugehörige relationale Datenbankschema wird gut durch einen Hypergraphen
veranschaulicht, wobei die Knoten die Attribute und die Hyperkanten die
Relationenschemas sind:
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
9
Verl_Orte
Verlagsort
Verlagsname
Exemplar
Inventarnr
Verlag
ISBN_Code
Signatur
wird_verlegt
ISBN
Autorenname
Hrsg
Autor
Position
Titel
Erscheinungsjahr
Auflage
Buch
Ein Benutzer dieser Bibliotheksdatenbank sucht ein Buch, von dem er nur den
Namen des Verlags sowie des Autors kennt.
Um alle in Frage kommenden Bücher aufzulisten, muss der Benutzer bei einer
gewöhnlichen relationalen Datenbank Kenntnisse bzgl. der Schema-Informationen
über die Relationen und Attribute der Datenbank besitzen, insbesondere die
beteiligten Relationen und die entsprechenden Verbundbedingungen ermitteln und
daraus die gewünschte Anfrage stellen.
Bzgl. unserer Beispiel-Datenbank kommt folgende Anfrage heraus:
SELECT Titel, Buch.ISBN
FROM Buch, Autor, wird_verlegt, Verlag
WHERE Autorenname='gesuchter_Autor' AND
Verlagsname='gesuchter_Verlag'
AND Buch.ISBN=Autor.ISBN AND Buch.ISBN=wird_verlegt.ISBN
AND wird_verlegt.ISBN_Code=Verlag.ISBN_Code;
Bei einem Universalrelationen-System braucht der Benutzer nur die vorhandenen
Attribute kennen. Die gleiche Anfrage lautet dort:
SELECT Titel, ISBN
WHERE Autorenname='gesuchter_Autor' AND
Verlagsname='gesuchter_Verlag';
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
10
Da wir uns eine Universalrelation vorstellen, können wir weglassen:
• die FROM-Klausel,
• die Relationensymbole (es gibt ja nur eine Relation und wir benötigen hier
nur eine Kopie davon) und außerdem
• die Verbundbedingungen (es gibt nichts zu verbinden).
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
11
1.3
Für Universalrelation-Systeme geeignete
Datenbankschemas
Der Einfachheit halber betrachten wir hier nur (als Hypergraph) zusammenhängende
sowie reduzierte Datenbankschemas, d.h. es gibt keine zwei Relationenschemas, so
dass die eine Attributmenge eine Teilmenge der anderen Attributmenge ist.
Die Kreisfreiheit von Hypergraphen ist ein wichtiges Kriterium für eine eindeutige
Semantik.
Unglücklicherweise überträgt sich der Begriff eines Kreises nicht ganz einfach von
Graphen auf Hypergraphen.
Bei Hypergraphen unterscheidet man daher mehrere Grade von Azyklizität.
1.3.1 Anforderungen an das Datenbankschema
Ein Datenbankschema, das für ein Universalrelation-System geeignet sein soll, muss
folgende Bedingungen erfüllen:
1. Die Attributnamen müssen nicht nur relationenweit, sondern datenbankweit
gültig (und eindeutig) sein, weil bei einer Universalrelation-Anfrage die
Information, aus welcher Relation die Attribute stammen, nicht vorhanden ist.
D.h. es muss gelten, dass zwei Attribute mit dem gleichen Namen stets den
gleichen Aspekt der realen Welt bezeichnen (also keine Homonyme
vorkommen) und umgekehrt. Diese Eigenschaft kann durch geeignete
Umbenennung von Attributen stets erreicht werden.
2. Die zweite Anforderung an das Datenbankschema ist die γ-Azyklizität (vgl.
Kapitel 1.3.2). In einem γ-zyklischen Schema sind die semantischen
Beziehungen zwischen manchen Attributen mehrdeutig, Anfrageergebnisse
können dann falsch interpretiert werden;
technischer ausgedrückt:
zu einigen Attributmengen gibt es mehr als einen Anfragehypergraphen.
Das Datenbankschema muss so beschaffen sein, dass es zwischen zwei Relationen
nicht mehr als eine (Standard-)Beziehung gibt. (Standardbeziehungen sind in etwa
die Beziehungen im Entity-Relationship-Diagramm.) Genau diese Beziehung soll
berechnet werden.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
12
Beispiel 2: Gegeben sei jetzt ein anderer Ausschnitt eines Bibliotheksschemas:
Inventarnr
Signatur
ISBN
ist
Exemplar
von
Exemplar
leiht
aus
EntityRelationshipDiagramm
für Beispiel 2
Buch
Titel
bestellt
vor
BName
Benutzer
Benutzernr
Diese Anwendung kann durch das folgende γ-zyklische Datenbankschema realisiert
werden:
Exemplar
Inventarnr
Signatur
ISBN
Titel
Buch
leiht aus
bestellt vor
Benutzernr
Hypergraph
zu Beispiel 2
BName
Benutzer
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
13
In diesem Schema gibt es zwischen den Attributen Benutzernr und
Signatur zwei Beziehungen:
1. Der durch Benutzernr gekennzeichnete Benutzer hat das Exemplar
Signatur ausgeliehen.
2. Der durch Benutzernr gekennzeichnete Benutzer hat ein Buch vorbestellt,
von dem Signatur ein Exemplar ist.
Ohne weitere Angaben des Benutzers kann das Universalrelationsystem bei einem
γ-zyklischen Schema nicht erkennen, welche Interpretation gewünscht ist.
Technisch kommt dies dadurch zum Ausdruck, dass die Universalrelation-Anfrage
SELECT Benutzernr, Signatur;
zwei verschiedene Anfragehypergraphen hat, die diese unterschiedlichen
Interpretationen widerspiegeln:
Signatur
Signatur
ISBN
{Exemplar}
{leiht aus} Benutzernr
Benutzernr
{bestellt vor}
In einem γ-azyklischen Schema ist der Anfragehypergraph dagegen stets eindeutig.
Hat man ein γ-zyklisches Datenbankschema, so lassen sich für jedes γ-azyklische
Teilschema wieder die Vorteile des Universalrelation-Systems nutzen.
In unserem Beispiel 2 musste ein Benutzer dann zu Beginn nicht das
Datenbankschema 'Bibliothek', sondern eines der Datenbank-Teilschemas 'Ausleihe'
oder 'Vorbestellen' auswählen.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
14
1.3.2 Überprüfung der Anforderungen
Das Universalrelation-System benötigt für seine Arbeit Informationen über das
Datenbankschema. Diese sind in der Regel bereits im Data Dictionary des
Datenbankverwaltungssystems vorhanden oder in der SQL-Kommandodatei, mit der
das Datenbankschema erzeugt wurde, die also insbesondere alle CREATE-TABLEKommandos der Datenbank enthält.
Das Universalrelation-System ermittelt bei seiner Initialisierung alle relevanten
Daten des Datenbankschemas, nämlich für jede Relation ihren Namen und die
Menge ihrer Attribute sowie für jedes Attribut seinen Namen, seinen Typ und die
Menge der das Attribut enthaltenden Relationen.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
15
Beispiel 1: Für unser Beispielschema liegt folgende SQL-Kommandodatei vor:
CREATE TABLE Buch
(
ISBN
Titel
Erscheinungsjahr
Auflage
CHAR(13)
CHAR(150) ,
NUMBER(4),
NUMBER(4)
PRIMARY KEY,
);
CREATE TABLE wird_verlegt
(
ISBN
CHAR(13)
ISBN_Code
CHAR(9)
PRIMARY KEY,
NOT NULL);
CREATE TABLE Verlag
(
ISBN_Code
CHAR(9)
Verlagsname
CHAR(30)
PRIMARY KEY,
NOT NULL);
CREATE TABLE Verl_Orte
(
ISBN_Code
CHAR(9)
Verlagsort
CHAR(30)
NOT NULL,
);
CREATE TABLE Autor
(
ISBN
Autorenname
Hrsg
Position
NOT NULL,
NOT NULL,
NOT NULL,
NOT NULL);
CHAR(13)
CHAR(30)
CHAR(4)
NUMBER(2)
CREATE TABLE Exemplar
(
ISBN
CHAR(13)
Inventarnr
CHAR(8)
Signatur
CHAR(16)
NOT NULL,
PRIMARY KEY,
NOT NULL);
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
16
Die so gewonnenen Schemainformationen werden in zwei Tabellen für Relationen
und Attribute gespeichert, aus denen wir insbesondere Verbundinformationen leicht
ablesen können.
Nach Einlesen unseres Beispielschemas liegen die beiden folgenden Tabellen vor:
RelationTabelle:
Nr.
1
2
3
4
5
6
Name
Buch
wird_verlegt
Verlag
Verl_Orte
Autor
Exemplar
enthält Attribut Nr.
{1, 2, 3, 4}
{1, 5}
{5, 6}
{5, 7}
{1, 8, 9, 10}
{1, 11, 12}
AttributTabelle: Nr.
Name
Typ
enthalten_in Relation Nr.
1
ISBN
CHAR(13)
{1, 2, 5, 6}
2
Titel
CHAR(150)
{1}
3 Erscheinungsjahr NUMBER(4)
{1}
4
Auflage
NUMBER(4)
{1}
5
ISBN_Code
CHAR(9)
{2, 3, 4}
6
Verlagsname
CHAR(30)
{3}
7
Verlagsort
CHAR(30)
{4}
8
Autorenname
CHAR(30)
{5}
9
Hrsg
CHAR(4)
{5}
10
Position
NUMBER(2)
{5}
11
Inventarnr
CHAR(8)
{6}
12
Signatur
CHAR(16)
{6}
Beim Einlesen der Schemainformation wird gleichzeitig eine notwendige Bedingung
für die globale Gültigkeit von Attributnamen geprüft, nämlich ob alle Attribute mit
gleichem Namen auch in allen Relationen den gleichen Typ haben. Ist das nicht der
Fall, so spricht dies dafür, dass unterschiedliche semantische Konzepte mit dem
gleichen Attributnamen belegt sind.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
17
Außerdem erfolgt, nachdem die Schemainformationen der SQL-Kommandodatei
entnommen wurden, ein Test auf γ–Azyklizität.
Für diesen Test benutzen wir die folgende DMF-Reduktion:
DMF-Reduktion:
Führe folgende Operationen (in beliebiger Reihenfolge) aus, bis keine mehr
angewendet werden kann:
(1) Kommt ein Attribut in nur einem Relationenschema vor, so entferne dieses
Attribut.
(2) Enthält ein Relationenschema weniger als zwei Attribute, so entferne dieses
Relationenschema.
(3) Haben zwei Relationenschemas die gleichen Attributmengen, so entferne eins
dieser Relationenschemas.
(4) Sind zwei Attribute in genau der gleichen Menge von Relationenschemas
enthalten, so entferne eins dieser Attribute aus allen Relationenschemas.
Ein Hypergraph ist γ-azyklisch genau dann, wenn die DMF-Reduktion zum leeren
Ergebnis führt.
Beide Tests werden nur einmal während der Initialisierungsphase des
Universalrelation-Systems durchgeführt.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
18
1.4
Berechnung des Anfragehypergraphen, der
Verbundbedingungen und des Fensters
Die vom Benutzer eingegebene Universalrelation-Anfrage
SELECT Select-Liste WHERE Anfragebedingung;
wird gemäß einer Syntax analysiert, die einer SQL-Anfrage mit Ausnahme der
FROM-Klausel entspricht.
Dabei werden alle vorkommenden Attributnamen auf ihr Vorhandensein im
Datenbankschema überprüft und in der Anfrageattributmenge X gespeichert.
Die gesamte Universalrelation-Anfrage wird außerdem textuell unverändert für die
Erzeugung der SQL-Anfrage gespeichert.
Beispiel 1: Wir veranschaulichen den Ablauf anhand von zwei Beispielanfragen an
das Universalrelation-System, die wir jeweils mit A und B unterscheiden:
A: Man möchte die Titel aller Bücher und die Namen ihrer Autoren wissen, die im
Springer-Verlag erschienen sind.
SELECT Autorenname, Titel
WHERE Verlagsname='Springer';
B: Man möchte die Kennungen aller in der Datenbank geführten Verlage wissen.
SELECT DISTINCT ISBN_Code;
Die Attribute, die in der Select-Liste vorkommen, bezeichnen wir mit AusgabeAttribut-Liste; denn die Select-Liste kann außer Attributen auch z.B. Konstanten
oder Aggregatoperationen enthalten.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
19
1.4.1 Ermittlung des Anfragehypergraphen
Zu der beim Einlesen der Anfrage ermittelten Menge von Anfrageattributen X wird
jetzt der Anfragehypergraph H berechnet, der den für die Anfrage relevanten Teil
des Datenbankschemas darstellt, nämlich genau die Anfrageattribute sowie die für
die Verbundbedingungen erforderlichen Attribute enthält.
Dazu verwenden wir den GYO-Algorithmus, der ursprünglich als Test auf αAzyklizität und später in modifizierter Form auch für die Anfragebearbeitung
benutzt wurde.
globale Eingabe:
γ-azyklisches Datenbankschema als Attributmenge und Menge
der Relationschemas.
lokale Eingabe:
Menge der Anfrageattribute X.
Ausgabe:
Anfragehypergraph.
Verfahren:
Solange sich noch etwas ändert, führe einen der beiden
folgenden Schritte aus :
1. Kommt ein Attribut, das nicht in X ist, in höchstens einem
Relationschema vor, so lösche das Attribut.
2. Sind alle (nicht bereits gelöschten) Attribute eines
Relationsschemas auch in einem anderen Relationschema
enthalten, so lösche das kleinere Relationschema.
Ergebnis sind die Mengen der nicht gelöschten Attribute und
Relationschemas.
Satz: Für γ-azyklische Datenbankschemas berechnet der obige, modifizierte GYOAlgorithmus den Anfragehypergraphen.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
20
Beispiel 1: In unserem Beispiel erhält man folgende Anfrageattributmengen und
Anfragehypergraphen:
A: X = {Autorenname, Titel, Verlagsname}
Anfragehypergraph { {ISBN, Titel}Buch, {ISBN, ISBN_Code}wird_verlegt,
{ISBN_Code, Verlagsname}Verlag, {ISBN, Autorenname}Autor }
Verlagsname
Verlag
ISBN_Code
wird_verlegt
ISBN
Autorenname
Titel
Autor
Buch
B: X = {ISBN_Code}
Anfragehypergraph { {ISBN_Code}Verl_Orte, Verlag, wird_verlegt }
ISBN_Code
{Verl_Orte,
Verlag,
wird_verlegt}
Die Anfrageattribute sind im Anfragehypergraphen fett hervorgehoben.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
21
Aus den Kanten des Anfragehypergraphen kann leider nicht eindeutig auf ein
Relationenschema geschlossen werden, aus dem es entstanden ist, z.B. kann die
Kante mit dem einzigen Knoten ISBN_Code aus den Relationsschemas Verlag,
Verl_Orte oder wird_verlegt entstanden sein.
Entsprechend haben wir im letzten Bild die Kanten des Anfragehypergraphen mit
der Menge der Kanten des ursprünglichen Hypergraphen bezeichnet, aus denen sie
entstanden sein können.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
22
1.4.2 Erzeugen der SQL-Anfrage mit der minimalen
Verbindungsemantik
Statt genau festzulegen, wie die Universalrelation aussieht, reicht es, für jede Menge
X von Attributen, die in einer Anfrage vorkommt, festzulegen, wie das zu X gehörige
sog. Fenster der Universalrelation aussieht; dies ist eine Relation über X und wird
mit [X] bezeichnet.
Wir geben nachfolgend an, wie man ausgehend vom Anfragehypergraphen dieses
Fenster berechnet, das wir in den SQL-Kommandos AHG nennen.
Bei der minimalen Verbindungssemantik betrachten wir für jede Kante Rk
(k=0…m) des Anfragehypergraphen alle Relationen der Datenbank, deren Schema
eine Obermenge von Rk ist, berechnen ihre Projektionen auf die Attributmenge Ak
von Rk und vereinigen sie.
Anschließend fassen wir alle diese Vereinigungen mit dem natürlichen Verbund
zusammen.
Dieser Verbund erstreckt sich hier über Projektionen von Datenbankrelationen.
Formal ist ein Fenster der minimalen Verbindungssemantik definiert als:
[X]MC := πX V∈AHG ∪R∈RS,R⊇V πV R
º
Aus praktischen Erwägungen wird die Bearbeitung der Anfrage an das
Universalrelation-System in mehrere Schritte aufgeteilt:
1. Sichten für die Vereinigungen der ∪R∈RS,R⊇V πV R werden erzeugt.
2. Die Verbundbedingungen werden erzeugt und eine Sicht für den Verbund
gebildet.
3. Die ursprüngliche, um die FROM-Klausel ergänzte Anfrage, wird gestellt.
4. Die erzeugten Sichten werden wieder gelöscht.
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
23
1. Für jede Kante des Anfragehypergraphen Rk wird eine Sicht Kantek erzeugt, die
von allen Relationen ORk,0, …, ORk,nk der Datenbank, deren Schema eine
Obermenge von Ak ist, die Projektionen auf Ak berechnet und vereinigt.
CREATE VIEW Kantek AS
SELECT Ak FROM ORk,0
UNION … UNION
SELECT Ak FROM ORk,nk;
Beispiel 1: Im unserem Beispiel ist
A: A0={Titel, ISBN}, A1={ISBN, ISBN_Code},
A2={ISBN_Code, Verlagsname}, A3={ISBN, Autorenname};
B: A0={ISBN_Code}
Unserem erweiterten Anfragehypergraphen kann man ebenfalls die Oberrelationen
entnehmen:
A: OR0,0=Buch, OR1,0=wird_verlegt, OR2,0=Verlag, OR3,0=Autor;
B: OR0,0=Verl_Orte, OR0,1=Verlag, OR0,2=wird_verlegt.
Wir erhalten also folgende Definitionen für Sichtrelationen:
A: CREATE VIEW Kante0 AS SELECT Titel, ISBN FROM Buch;
CREATE VIEW Kante1 AS SELECT ISBN, ISBN_Code FROM wird_verlegt;
CREATE VIEW Kante2 AS SELECT ISBN_Code, Verlagsname FROM Verlag;
CREATE VIEW Kante3 AS SELECT ISBN, Autorenname FROM Autor;
B: CREATE VIEW Kante0 AS SELECT ISBN_Code FROM Verl_Orte
UNION SELECT ISBN_Code FROM Verlag
UNION SELECT ISBN_Code FROM wird_verlegt
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
24
2. Bezüglich der Sichten Kantek (k=0…m) und deren Attributmengen Ak werden
nun die Verbundbedingungen zum Anfragehypergraphen berechnet.
Die Verbundbedingungen VB werden stets folgendermaßen erzeugt:
Für jedes Attribut A, das in den Relationenschemas (hier: der Sichtrelationen
Kante0,…, Kantem) mehrmals vorkommt, also A∈S1, …, A∈Sn mit n≥2, wird
folgende Bedingung hinzugefügt:
S1.A=S2.A AND S1.A=S3.A AND … AND S1.A=Sn.A.
Mit diesen Sichten und Bedingungen wird eine Sicht AHG (als das zum
Anfragehypergraphen gehörende Fenster) erzeugt:
CREATE VIEW AHG AS
SELECT Anfrageattribut-Liste FROM Kante0, …, Kantem
WHERE erzeugte_Verbundbedingungen;
Beispiel 1: Im unserem Beispiel ist
A: CREATE VIEW AHG AS
SELECT Verlagsname, Titel, Autorenname
FROM Kante0, Kante1, Kante2, Kante3
WHERE Kante0.ISBN=Kante1.ISBN AND Kante0.ISBN=Kante3.ISBN
AND Kante1.ISBN_Code=Kante2.ISBN_Code;
B: CREATE VIEW AHG AS
SELECT ISBN_Code FROM Kante0;
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
25
3. Danach erfolgt die ursprüngliche, um eine FROM-Klausel ergänzte Anfrage an
SQL:
SELECT Select-Liste FROM AHG WHERE Anfragebedingung;
Diese Anfrage wird vom Datenbanksystem bearbeitet und liefert das
gewünschte Ergebnis.
Beispiel 1: Im unserem Beispiel also
A: SELECT Autorenname, Titel
FROM AHG
WHERE Verlagsname='Springer';
B: SELECT DISTINCT ISBN_Code
FROM AHG;
4. Schließich werden alle erzeugten Sichten wieder gelöscht:
DROP VIEW Kante0; …; DROP VIEW Kantem;
DROP VIEW AHG;
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
26
Die Verwendung von Inline-Views in der FROM-Klausel verringert den
Kommunikations- und Organsiationsaufwand mit dem Datenbanksystem.
Eine Universalrelation-Anfrage führt dann zu nur einer Datenbank-Anweisung; das
Erzeugen und Löschen der Sichten entfällt.
Allerdings ist die erzeugte Datenbank-Anweisung schwieriger lesbar.
Mit inline-views sehen die Anfragen so aus:
A. SELECT Autorenname, Titel
FROM (SELECT Verlagsname, Autorenname, Titel
FROM (SELECT ISBN, Titel FROM Buch) Kante_0,
(SELECT ISBN, ISBN_Code FROM wird_verlegt) Kante_1,
(SELECT ISBN_Code, Verlagsname FROM Verlag) Kante_2,
(SELECT ISBN, Autorenname FROM Autor) Kante_3
WHERE Kante_0.ISBN=Kante_1.ISBN AND
Kante_0.ISBN=Kante_3.ISBN AND
Kante_1.ISBN_Code=Kante_2.ISBN_Code
) AHG
WHERE Verlagsname='Springer'
B. SELECT DISTINCT ISBN_Code
FROM (SELECT ISBN_Code
FROM (SELECT ISBN_Code FROM wird_verlegt
UNION
SELECT ISBN_Code FROM Verlag
UNION
SELECT ISBN_Code FROM Verl_Orte
) Kante_0
) AHG
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
27
Die innere Projektion auf Attribute der Kanten ist nur notwendig, falls eine Kante
aus der Vereingung von mehreren (projizierten) Relationen entsteht (Fall B).
Sonst kann man diese Projektion auch dem Oracle-Optimierer überlassen (die
Verbundbedingung muss aber unverändert bleiben!):
A. SELECT Autorenname, Titel
FROM (SELECT Verlagsname, Autorenname, Titel
FROM (SELECT ISBN, Titel FROM Buch) Kante_0,
(SELECT ISBN, ISBN_Code FROM wird_verlegt) Kante_1,
(SELECT ISBN_Code, Verlagsname FROM Verlag) Kante_2,
(SELECT ISBN, Autorenname FROM Autor) Kante_3
WHERE Kante_0.ISBN=Kante_1.ISBN AND
Kante_0.ISBN=Kante_3.ISBN AND
Kante_1.ISBN_Code=Kante_2.ISBN_Code
) AHG
WHERE Verlagsname='Springer'
A. SELECT Autorenname, Titel
FROM (SELECT Verlagsname, Autorenname, Titel
FROM Buch Kante_0, wird_verlegt Kante_1,
Verlag Kante_2, Autor Kante_3
WHERE Kante_0.ISBN=Kante_1.ISBN AND
Kante_0.ISBN=Kante_3.ISBN AND
Kante_1.ISBN_Code=Kante_2.ISBN_Code
) AHG
WHERE Verlagsname='Springer'
A. SELECT Autorenname, Titel
FROM (SELECT Verlagsname, Autorenname, Titel
FROM Buch, wird_verlegt, Verlag, Autor
WHERE Buch.ISBN=wird_verlegt.ISBN AND
Buch.ISBN=Autor.ISBN AND
wird_verlegt.ISBN_Code=Verlag.ISBN_Code
) AHG
WHERE Verlagsname='Springer'
Brüggemann, Vorlesungsnotizen zu Datenbanksysteme IIb, Uni Hannover, Sommersemester 2003
28