Willkommen zur Sonderübung SQL.
Ich habe Ihnen versprochen, Herrn Goos die ein oder andere Minute aus
den Rippen zu leiern.
Ich hatte so viel Erfolg, dass es gleich 90 wurden.
Insofern habe ich die Ehre, Ihnen jetzt noch ein bisschen SQL
nahezubringen.
Wir betrachten SQL nicht für sich alleine, sondern immer nur in
Zusammenhang mit der theoretischen Grundlage dafür, mit der
relationalen Algebra.
Und Sie erinnern sich ja noch vom Freitag, dass wir da fünf
Grundoperationen, nämlich die Selektion haben zum Beispiel, die Dinge
wegschmeißt, die Projektion, die gewisse Datenfelder ausblendet, das
kathesische Produkt, das die Tuppel miteinander verknüpft, Vereinigung
und Differenz.
Und dann die Makrooperationen, Durchschnitt, Theta-Verbund,
natürlicher Verbund und die Division.
Die wichtigste, die zentrale Funktion in SQL, die Sie unbedingt
verstanden haben müssen, sind eben diese Joints.
Und aus diesem Grund werden wir uns diese Joints, die auf dieser
halben Folie, die am Freitag war, doch ein bisschen kurz dran waren,
uns nochmal genauer anschauen.
So, wie gesagt, sind die Grundlage der Verbindungsoperationen in der
relationalen Algebra immer das kathesische Produkt, auf dem wir
anschließend eine Selektion durchführen, und zwar mit dem Prädikat
Theta.
So, wie sieht das Ganze jetzt aus?
Zunächst einmal wollen wir gucken, wie sieht das kathesische Produkt
überhaupt aus in SQL?
Das können wir so hinschreiben, indem wir schreiben Select Stern from
Relation 1, Relation 2, Relation 3.
Und damit bilden wir praktisch das kathesische Produkt dieser drei
Relationen.
Zur Anmerkung an dieser Stelle, der Stern, wenn wir die Select
-Klausel, wenn wir da den Stern verwenden, dann entspricht es
praktisch genau der Identität als Projektion.
Und wir geben also alle Tuppelkomponenten zurück, und zwar genau in
der Reihenfolge, wenn man eben die Tuppel aus der Relation 1 vor die
Tuppel der Relation 2 und die vor die Tuppel der Relation 3 hängt.
Die Namen übernehmen die Spalten praktisch aus den drei Relationen,
wobei die meisten Datenbankprodukte das Ganze dann noch genauer
repräsentieren durch Relationsname, Punkt, Attributname, für den Fall,
dass ein Attribut mit gleichem Namen hier und hier vorkommen sollte.
So, die From-Klausel enthält die Liste der Relationen, aus denen wir
dieses kathesische Produkt bilden wollen, und die Where-Klausel lassen
wir in diesem Fall weg.
Die Where-Klausel ist implizit wahr, und deswegen bekommen wir dann in
dem Fall alle Tuppel zurück.
Und Sie sehen ein, dass wir in dem Fall tatsächlich dann das
kathesische Produkt Dreierrelationen in dem Fall so in SQL bilden
können.
So, die Selektion eines bestimmten Prädikates Theta in SQL sieht so
aus, dass wir natürlich wieder in dem Fall keine Projektion,
beziehungsweise als Projektionsfunktion die Identität wählen wollen
und von einer bestimmten Relation diejenigen Tuppel zurückgeben
wollen, für die ein bestimmtes Prädikat Theta zutrifft.
Gut, und wir gehen praktisch durch die Relationen, wenn wir ein
solches Select-Statement absetzen, und betrachten jedes einzelne
Tuppel dieser Relationen, und wenn Theta von diesem Tuppel gilt, dann
kommt dieses Tuppel in die Ergebnisrelation, die zurückgegeben wird,
und sonst wird es verworfen.
Es gibt zwei Fälle, einmal das Theta ein atomares und einmal das Theta
ein zusammengesetztes Prädikat ist.
Für atomare Prädikate, da haben wir in SQL zum Beispiel das ist
gleich, kleiner, größer, größer gleich, kleiner gleich und einige
weitere.
Einschränken muss man an dieser Stelle sagen, man kann jedoch nur über
Selektoren auf einzelne Werte zugreifen, das heißt auf die Attribute
des aktuellen Tuppels.
Und aus dem Grund gibt es tatsächlich auch nur Operatoren auf atomaren
Typen.
Das aktuelle Tuppel, das ist ziemlich wichtig, Sie können ja hier
nachher einen relativ komplexen Ausdruck stehen haben, und Sie setzen
an der Stelle für die Selektoren immer den Wert ein, der für das
aktuell betrachtete Tuppel da reinkommt.
Also nicht, dass Sie versuchen, irgendwie mit irgendwelchen Tuppeln
dort zu substituieren, sodass das hier zu true wird, sondern Sie
betrachten, wertet sich dieser Ausdruck hier zu wahr aus für das
aktuelle Tuppel oder nicht.
Und dementsprechend kommt es dann eben in die Ergebnisrelation oder
nicht.
Ein solches atomares Prädikat TETA würde dann eben aussehen wie Name
ist gleich Klaus, wenn jetzt Name der Selektor eines bestimmten
Attributes oder aller Tuppel wäre.
So, ich habe gesagt, TETA kann genauso gut ein zusammengesetztes
Prädikat sein.
In dem Fall kann man mit SQL diese zum Beispiel aufbauen durch die
Schlüsselwörter AND, OR und NOT und auch noch weitere.
Uns interessieren an dieser Stelle tatsächlich nur die, die da stehen,
die einfachsten.
Je nach Datenbankimplementierung kommen da halt unterschiedlich
mächtige oder eben auch gar keine zusätzlichen Operationen dazu.
Mit diesen Schlüsselwörtern kann ich dann atomare Prädikate oder
zusammengesetzte Prädikate verbinden.
Das Ganze wie in Prädikatenlogik mit Klammerungen und solchen Dingen.
Wichtig an dieser Stelle nochmal, dass praktisch alle wirklich immer
auf das aktuelle Tuppel verweisen.
Und hier haben wir das Beispiel, wo wir dann mit diesem AND zwei
atomare Prädikate miteinander verbinden.
Okay, jetzt stellt sich für uns die Frage, wir haben einmal gesehen,
das kathesische Produkt stellen wir so dar in SQL, die Selektion
stellen wir so dar in SQL, jetzt ist halt die Frage, wie kriegen wir
das zusammen?
Hier steht eine Relation und hier stehen drei.
Wie kann das passen?
Wenn wir uns jetzt angucken, nehmen wir mal an, unsere Relation 1 sei
AA und das Tuppel BB, Relation 2, 2X und 2Y und die Relation 3 bestehe
ebenfalls aus zwei Tuppeln und zwar 63AL und 15HP.
Und unsere Relation von hier drüben bestehe eben aus den angegebenen
Tuppeln AA, 2X, 3, 63AL und so weiter bis da unten, Sie können das
lesen.
Und wenn Sie sich das jetzt genau angucken, dann ist ja dieses
Relation Rel genau das, was das Kreuzprodukt dieser drei hier
entspricht.
Das heißt, eigentlich wäre es doch wünschenswert, dass wir dieses
Kreuzprodukt auch wieder wie eine ganz normale Relation auffassen und
entsprechend da oben auch reinstöpseln können.
Also wir nehmen praktisch diesen kompletten Ausdruck hier und basteln
ihn an diese Stelle hier rein.
Und genau das unterstützt SQL auch, indem wir dann nämlich unser
Select von eben, from where tether und dann den Ausdruck von eben,
also den inner join, Entschuldigung, das Kreuzprodukt hier einfach in
den Reihen schreiben.
Die gebräuchlichere Form an dieser Stelle und auch die ältere Form
ist, dass Sie es so hinschreiben.
Select Stern, from row 1, row 2, where tether.
Das geht dann zum Beispiel auch mit MySQL.
Im Endeffekt entspricht der relationalen Algebra aber eher dann diese
Darstellungsweise.
Was wir daraus auf jeden Fall für uns mitnehmen wollen, ist, dass das
Ergebnis einer Anfrage selbst wieder eine gültige Relation ist, die
wir dann natürlich wieder befragen können.
Zum Beispiel irgendwo in ein anderes Select Statement reinstecken
können.
Wenn man das so tut, dann spricht man von geschachtelten Anfragen.
Als wichtiger Hinweis an dieser Stelle noch, dass die Ergebnisrelation
nur temporär ist.
Das heißt, Sie setzen dieses Statement einmal ab, dann bekommen Sie
Ihre Ausgabe auf den Bildschirm.
Die ganzen Zeilen werden hingepinselt und danach ist es auch wieder
weg.
Das heißt, man kann auch sagen, das Ganze ist transient, während
letztendlich hier irgendwo in der From-Clause tatsächlich auch
persistente Tabellen stehen werden, weil Sie ja die Daten nicht jedes
Mal erfinden.
Okay, wir schauen uns jetzt mal so ein Beispiel an, wie so ein Join in
SQL aussehen könnte und haben dann mal so eine typische Frage, zu
welcher Kategorie gehört der Artikel mit der Artikelnummer 4711?
Also, wenn Sie in irgendeine Richtung Richtung Datenbank marschieren,
ist das eigentlich der übliche Index.
4711 oder 0815 aus unerfindlichen Gründen, die können Sie sich selber
überlegen.
Jedenfalls ist, Sie sehen hier, die Anfrage aufgeschrieben.
Wir wollen von dem Artikel den Namen zurückgeben, also Select K.Name
from Artikel A Kategorie K.
Dies hier ist, wie gesagt, ein Alias für diese Tabelle und erspart uns
hinterher Schreibarbeit.
Dieser Alias ist optional, also den können wir hinschreiben oder auch
nicht.
Wir könnten auch stattdessen das Ganze komplett qualifizieren und in
dem speziellen Fall hier sogar weglassen, weil die Namen
unterschiedlich sind in beiden Tabellen.
Also wir vergleichen dann hier, wir machen den Join über Kategorie und
Kategorienummer und zusätzlich noch die Selektionsbedingung, dass die
Artikelnummer 4711 ist.
Nun stellt sich schlicht und ergreifend die Frage, woher weiß man
denn, dass das Ding jetzt irgendwie Kategorie heißt oder Bestellnummer
oder weiß der Kuckuck was, was da zusammenpasst und wie man das dann
joinen kann.
Und dafür ist die Antwort, brauchen Sie das Schema.
Das brauchen Sie, damit Sie die Datenbank wirklich sinnvoll befragen
können, denn sonst könnten Sie Alter mit Schuhglöckengröße joinen, das
wäre sicherlich interessant, würde aber sicher keine große
Aussagekraft besitzen.
So, so ein Schema sieht zum Beispiel in Exzess, wo es einfach sehr
anschaulich dargestellt wird, sieht dann so aus.
Das heißt, Ihre einzelnen Relationen werden als Kasten dargestellt und
Attribute, die miteinander verbunden werden können, wie zum Beispiel
Kategorienummer und Kategorie, werden durch so eine Linie verbunden.
Da stellt sich natürlich die Frage, was soll denn dieser Eins hier
bedeuten und dieses Unendlich-Zeichen.
Also bei einem Datenbankmanagementsystem, was die Abkürzung für dieses
DBMS ist, an dieser Stelle auch der Hinweis, Sie müssen unterscheiden
zwischen dem Datenbankmanagementsystem und der Datenbank selbst.
Datenbankmanagementsystem ist das Produkt, was Ihnen zum Beispiel die
SQL -Schnittstelle zur Verfügung stellt, was die Ausgabe macht und
alles andere.
Die reinen Daten, wie sie auf der Platte liegen, das ist das, was man
Datenbank nennt.
In Ihrem Datenbankmanagementsystem können Sie Konsistenzbedingungen
vorgeben.
Konsistenz bedeutet, dass Sie natürlich wollen, dass Ihre Daten auch
sinnvoll sind.
Sie möchten nicht, dass in dem Feld Schuhgröße nachher irgendein Wert
von 2748 steht, sondern Sie möchten wahrscheinlich, dass da Werte
zwischen, sagen wir mal, ich glaube, 27 ist so das Kleinste und was
ist das Größte?
60?
Ich weiß es nicht.
Jedenfalls möchten Sie nicht, dass da was steht, was größer als 80
ist, weil das ist sicher verkehrt.
Und solche Konsistenzbedingungen können Sie Ihrem
Datenbankmanagementsystem vorgeben.
Und eine spezielle Konsistenzbedingung, die die Kopplung zweier
Relationen Rho1 und Rho2 ermöglicht, und zwar in der Form, dass die
Attributfolge, also dass in Rho1 die Attributfolge fk, die Werte, die
dort vorkommen, also in dem Attribut fk, die Werte, die dort
vorkommen, die müssen in der Relation Rho2 in einer anderen
Attributfolge, die wir hier pk nennen wollen, auftreten.
Wenn man das jetzt ein bisschen formalisieren will, würde man das so
hinschreiben, also Projektion auf fk von Rho1 ist Teilmenge Projektion
pk von Rho2.
Und dann spricht man von referenzieller Konsistenz von Rho1.fk nach
Rho2.pk.
Wenn pk ein Schlüssel ist, und zwar in aller Regel ein Primary Key,
deswegen pk von Rho2, dann würde man fk den Fremdschlüssel in Rho1
nennen, fk einfach für Foreign Key.
Also schauen wir uns das mal an dem oben genannten Beispiel an.
Wir haben, das habe ich ins letzte Mal schon gesagt, den
Primärschlüssel und das streichen wir immer.
Das ist so üblich.
Und wir lesen jetzt dieses Schema so, dass wir sagen, Kategorienummer
ist der Primärschlüssel in der Relation Kategorien und charakterisiert
eben alle Kategorien, die wir da rein eintragen, eindeutig.
Sie erinnern sich an die Abbildungsfunktion.
Und das bedeutet ja insbesondere, da ist die eindeutig
charakterisiert, dass es jede Kategorienummer nur ein einziges Mal
gibt.
Genauso hat Artikelnummer einen Primärschlüssel, nämlich dieses A
-Nummer, und den gibt es auch eben.
In der kompletten Tabelle gibt es jeden Wert für A-Nummer nur ein
einziges Mal.
Genauso verhält es sich für Lieferant.
Das ist jetzt der Primärschlüssel und diese Primärschlüssel werden
referenziert von Fremdschlüsseln.
Kategorie zum Beispiel, dieses Attribut, ist der Fremdschlüssel in der
Relation Artikel und das legt somit fest, dass diese Spalte Kategorie
nur solche Werte enthalten darf, die auch in diesem Attribut hier
vorkommen, nämlich in Kategorienummer in der Relation Kategorie.
Sprich, wenn sie nur drei Kategorien haben und damit die Nummern 1, 2
und 3 vergeben haben, darf hier in dem Feld alles stehen, was nicht 1,
2 und 3 ist.
Also es darf nur 1, 2 und 3 stehen.
Dabei ist es aber hier ja kein Schlüssel und deswegen darf es hier
natürlich in dieser Tabelle so oft stehen, wie Sie das möchten und das
wird einfach dann auch durch dieses Unendlich angedeutet.
Ich persönlich fand einfach diese Darstellung am schönsten, weil sie
am einfachsten nachzuvollziehen ist, weil sie auch im Gegensatz zur
UML, die einfach nur eine Linie dazwischen macht und Sie dann aus dem
Diagramm nicht ersehen können, was überhaupt zusammenpasst, habe ich
diese Darstellung von Access gewählt und dann auch das
Datenbasischema, was Sie zum Bearbeiten des Übungsblatts brauchen, das
habe ich Ihnen hier aufgeschrieben.
Das heißt, einfach als größeres Beispiel, Sie sehen, Sie haben nicht
mehr Strukturierungsmöglichkeiten als tatsächlich die Kästchen und die
Assoziationen und Sie sehen, dass jeweils zum Beispiel hier
Personalnummer der Primary Key ist und hier diese Personalnummer der
Foreign Key.
Unterschied zu dem bisher gezeigten, der Primary Key ist fett gedruckt
und nicht unterstrichen, aber das ist kein wesentlicher Unterschied.
Sie sehen zum Beispiel auch hier ein Beispiel für einen
zusammengesetzten Primärschlüssel.
An einer Stelle, wo Sie sagen, naja, bei den Bestelldetails würde es
mir da wirklich helfen, einen künstlichen Schlüssel zu haben, ich
könnte jetzt hier wirklich noch ein zusätzliches Integerfeld einfügen,
was ich einfach hochzähle und ich stelle dann natürlich aus meinem
Datenbasischema fest, na, ich referenziere das nie direkt, also
brauche ich diesen künstlichen Schlüssel wirklich nicht, wo kann ich
mir diese Daten getrost sparen.
Insbesondere legt Ihnen ja, nur so als Anmerkung, so ein Foreign Key
auch gleich noch einen Index mit an, eine Sortierreihenfolge, die
entsprechenden Strukturen zum Daten suchen und finden und dann ist es
natürlich besser, wenn Sie dann tatsächlich auch die Daten da stehen
haben, nach denen Sie wirklich suchen und nicht irgendeinen
künstlichen Primärschlüssel.
So, wir wollen auf diesem Beispielschema jetzt mal ein paar Anfragen
uns anschauen.
Select Stern vom Artikel A, Kategorien K, where A.Kategorie gleich K
.Kategorienummer.
Das heißt, wir haben die Tabelle Artikel und bezeichnen die als A in
unserer Anfrage und wir haben die Tabelle Kategorien und bezeichnen
die als K.
Und jetzt verlangen wir, dass A.Kategorie, also das hier,
mit K.Kategorienummer gleich sein muss.
Sie sehen ein, dass dieser Vergleich hier, weil wir hier eine
Fremdschlüsselbeziehung haben, auch wohl insbesondere Sinn ergibt.
Wir könnten nun auch die Artikelnummer mit der Kategoriennummer
vergleichen, aber das macht wahrscheinlich deutlich weniger Sinn.
So, und das ist jetzt einfach ein Theta-Join.
Und zwar, wenn wir Rho 1 annehmen als Artikel, Rho 2 als Kategorie und
das Theta als diesen kompletten Ausdruck hier.
Von diesem Ausdruck sehen wir, dass er nur eine Gleichheitsprüfung
enthält.
Und wenn Sie in Ihrer Bedingung hier nur Gleichheitsprüfungen haben,
dann würde man etwas spezieller auch von einem Äquijoin sprechen.
Aber das sagt eigentlich nur aus, dass tatsächlich nur Ist-Gleichs
drin vorkommen.
Also es ist nichts Besonderes an dieser Stelle.
Dargestellt in relationaler Algebra ganz einfach.
Wir haben das Kreuzprodukt aus den beiden Tabellen da oben gebildet
und haben danach einfach die rausselektiert, wo die Kategorie gleich
der Kategoriennummer ist.
Also Sie sehen, SQL, was für viele anschaulicher ist zunächst, ist
wirklich genau das Gleiche wie relationale Algebra soweit.
Also wir kennen da keinen Unterschied, wir brauchen auch keinen
Unterschied zu machen.
Hier ist es nur etwas formeller und im Endeffekt für uns besser zum
Rechnen.
So, schauen wir uns eine Alternative zu dem zuvor gezeigten an.
Und zwar machen wir hier praktisch genau das Gleiche.
Wir machen ein Kreuzprodukt aus den beiden und filtern diejenigen
raus, wo die Kategorie gleich der Kategorien- oder der Cat-Nummer ist.
Und zwar diesmal mit einer anderen Syntax, nämlich sagen wir an der
Stelle Artikel A, inner join, Kategorie K, on und dann unsere
Bedingung, die hier unten auch steht.
Das ist einfach nur eine andere Darstellungsmöglichkeit.
Ich glaube, seit SQL 92 ist die im Standard und die sagt wirklich
genau das Gleiche aus, wie was hier steht.
Und wenn Sie sich an letzten Freitag noch erinnern, dann war ja unser
Join tatsächlich auch so definiert, dass der als Selektion über einem
Kreuzprodukt dastand.
So, die Frage ist natürlich, jetzt macht das für uns hinterher einen
Unterschied und dazu wollen wir uns am Ende der Vorlesung noch
angucken.
Das ist nämlich genau eine Optimierungsfrage.
So, ein weiteres Beispiel, ein Natural Join wieder, das heißt ein
Kreuzprodukt und eine Selektion.
In diesem Fall, Sie sehen, der Natural Join würden wir natürlich
sagen, naja, das heißt ja gleich und der Natural Join war ja nur
gerade so definiert, dass man das dann nicht hinschreiben braucht.
In SQL muss man es aber eben trotzdem tun und deswegen bleibt es Ihnen
nicht erspart, das hinzuschreiben.
Und unsere anschließende Projektion sieht einfach so aus, dass Sie nur
zurückgeben die Bezeichnung und den Namen des Lieferanten.
So, was gibt das Ganze zurück?
Das Ganze gibt dann eben wegen der Projektion zurück eine Liste von
Tuppeln und diese Tuppeln haben zwei Komponenten.
Diese Komponenten sind jeweils Zeichenketten und die erste Komponente
ist eben die Bezeichnung des Artikels und die zweite Komponente ist
der Name des Lieferanten, der diesen Artikel uns geliefert hat, weil
wir eben dieser Konsistenzbedingungen gefolgt sind.
So, ein etwas größeres Beispiel, dass Sie auch sehen, dass das genauso
gut wie mit zwei auch mit drei geht, ist wenn wir jetzt unseren
Artikel A joinen mit einem Lieferanten L und das Ganze dann nochmal
joinen mit der Kategorie K.
Das hier wäre dann praktisch auch, damit Sie mal die Syntax sehen, wir
sehen ein, dass die WHERE-Clause auch sehr einfach gewesen wäre, das
heißt, Sie hätten einfach alles mit Kommas hier hinten
herangeschrieben und diese beiden Bedingungen einfach mit in die WHERE
-Clause reingenommen.
Das Ganze kann man ebenfalls wieder sehr leicht darstellen als
relationalen Ausdruck.
Von innen heraus fangen Sie an, Sie haben erstmal den Join von Artikel
und Lieferant, das steht hier in der Mitte, dann joinen Sie danach
dazu die Kategorie, das kommt dann hier dazu.
An dieser Stelle können Sie tatsächlich den Natural Join verwenden,
der relationalen Algebra, weil die ja gleich heißen.
An dieser Stelle hier heißen aber die Attribute unterschiedlich, also
Kategorie und Cat-Nummer, deswegen, ja okay, hier ist ein Fehler,
heißen die unterschiedlich, deswegen müssen Sie einen Theta-Join
machen, einen expliziten Equi-Join.
Und auf dieses große Kreuzprodukt, was Sie da haben, führen Sie
anschließend eine Selektion aus, und zwar da, wo die Artikelnummer
4711 ist, und projizieren hinterher auf Bezeichnung, Name und nochmal
Name.
Und hier stellen Sie auch fest, warum der Natural Join ein Problem
hat, K-Punkt-Name und L-Punkt-Name.
Wir haben einmal in der Kategorie ein Attribut Name und wir haben auch
beim Lieferant einen Name, und wenn wir jetzt hier blind auf die Equi
-Joins setzen, ohne das hier explizit angegeben zu haben, hätte der
uns nämlich nicht das hier miteinander verbunden und danach das hier
miteinander verbunden, sondern zuerst das hier miteinander verbunden
und danach stattdessen den Name mit dem Name.
Und eben das hier nicht gemacht, und das wäre natürlich falsch
gewesen.
Und deswegen verlangt eben SQL auch, dass Sie das immer explizit
hinschreiben.
Wir haben unsere Anfrage jetzt eben gesehen und wollen uns mal
anschauen, wie würde das Ganze denn aussehen, wenn man es ausführt.
Das sieht natürlich immer anders aus, je nachdem, was Sie gerade für
Daten in Ihrer Datenbank drin haben.
Sie sehen, wir haben hier die Relation Kategorien angegeben mit Cut
-Nummer, Name und Beschreibung.
Wir haben den Lieferanten mit L-Nummer, Name und Telefonnummer, den
Artikel mit Artikelnummer, Bezeichnung, der L-Nummer, der Cut-Nummer
und dem EK-Preis.
So, unsere Anfrage war diese.
Select A Bezeichnung, K.Name, S-Kategorie.
Sie sehen, wir verwenden an dieser Stelle wieder ein Alias und L.Name,
S -Firma.
Das wollen wir ausgeben und zwar von Artikel A in der Join-Lieferant
L.
Das wollen wir hier mit verbinden.
Und zwar da, wo A.L-Nummer gleich L.L-Nummer.
Schauen wir uns das an.
Also A.L-Nummer gleich L.L-Nummer.
Eins gleich eins.
Das heißt, wir hätten diese beiden Tuppel verbunden.
Nächste Zeile würden wir machen, da ist wieder eins, also wieder diese
beiden Tuppel verbunden.
Dann nochmal eine Eins und dann diese beiden Tuppel verbunden.
Dann hätten wir eine Zwei und würden diese Tuppel verbinden.
Und dann mit der Drei dann diese.
So, mit diesen verbundenen Tuppeln, die dann dabei rauskommen.
Das heißt, Sie können das praktisch lesen.
Eins, Chai, eins, eins, achtzehn, eins, Exotic Liquids, einundachtzig,
fünfhundertfünfundfünfzig, zweitausendzweihundertzweinundzwanzig.
Und das nächste Tuppel würde sich dann eben genauso lesen.
So, die Relation, die dabei rauskommt, die joinen wir jetzt nochmal
mit der Kategorie, also dem hier oben.
Und zwar in ganz genau der gleichen Weise, dass wir unsere Kategorie
Nummer Eins dann eben auf die Eins mit der Eins verbinden und so
weiter.
Was kommt da als Ergebnis bei Ihnen?
Bitte?
Wenn Sie ein Select nach dem Namen machen.
Nach welchem Namen?
Sie sehen, wir geben hier an K.Name für Kategorie und L.Name.
Und genauso hier bei den Bedingungen hinten auch und auch in der Work
Clause müssten Sie dann eben spezifizieren, welchen Namen Sie meinen.
Dafür gibt es diese Punktnotation.
Es muss Lieferanten heißen und nicht was?
Firma.
Achso, ja, okay, genau.
Okay, dann muss ich das nochmal erklären.
Also, nehmen Sie mal an, das hier wäre nicht da und das hier wäre
nicht da.
Sie sehen, eines würde uns dann zurückgeben, eine Relation und die
wäre halt irgendwie von dem Schema Bezeichnung,
offensichtlich wohl String, dann käme Name, was auch ein String wäre,
und dann käme nochmal Name, was in dem Fall auch ein String wäre.
Das wäre natürlich für den, dem wir die ganze Sache zurückgeben, nicht
wirklich offensichtlich, was wir damit jetzt wollen.
Das heißt, wir wenden an dieser Stelle eine Umbenennung an für die
Ergebnisrelation, für die entsprechende Spalte, beziehungsweise für
das entsprechende Attribut.
Also, in der Ausgabe wird das hier nicht mehr K.Name, sondern
Kategorie heißen.
Und das, was hier rauskommt, wird nicht mehr L.Name oder Name heißen,
sondern Firma, sodass sich dann nach der Umbenennung ein Schema
ergeben wird, was aussieht wie Bezeichnung,
dann Kategorie
und Firma.
Was kommt da als Ergebnis raus?
Sie sehen, da kommt dann diese Relation bei raus und hier oben steht
dann praktisch genau unsere Namen, die wir vergeben haben.
Also in dem Fall die Bezeichnung, die haben wir hier nicht abgeändert,
dann die Kategorie und dann die Firma.
Und damit sagen wir unserem Kunden, also derjenige, der die Datenbank
in dem Moment abfragt, also was du hier zurückbekommst, ist die Firma,
die uns diesen Artikel herstellt.
Wollte ich dazu noch was sagen?
Ich bin mir nicht sicher.
Okay, schauen wir uns den SQL-Mengen an.
Wir hatten ja bei den Grundoperationen noch die Mengenvereinigung zum
Beispiel mit drin und auch die gibt es in SQL.
Dort ist es der Union-Operator und damit kann man eben die Ergebnisse
von einzelnen Select-Anfragen miteinander verbinden.
Also wo Sie den Union-Operator nicht anwenden können, ist im From
-Teil.
Sie können dann nur hier im Select-Teil den Union-Operator anwenden,
aber das ist für Sie überhaupt kein Problem, da Sie wissen, dass hier
auch wieder eine Relation bei rauskommt und Sie diese Relation einfach
als geschaffte Relation in einer anderen Relation verwenden können.
Wichtig dabei ist natürlich, dass wir die gleiche Anzahl an Attributen
haben und dass das, was wir miteinander vereinigen wollen, in der
Reihenfolge seiner Komponenten auch vom Typ kompatibel ist.
Das heißt, ein String und eine Ganzzahl zusammenzuschmeißen könnte
schwierig werden.
Eine 32-Bit-Ganzzahl und eine 16-Bit-Ganzzahl, da wäre dann halt
einfach das Ergebnis der 32-Bit-Ganzzahl, wäre also kompatibel.
Als Beispielrelation ist hier angegeben, einmal die Relation 1 mit den
zwei Tuppeln 1,1 und 2,2 und die Relation 2 mit den Tuppeln 2,2 und 3
,3.
Und wenn wir jetzt hier alle Tuppel rausholen, alles davon zurückgeben
und das Ganze vereinen mit dem Gleichen für Relation 2, also einen
Union über diese beiden Relationen machen, ist das Ergebnis 1,1, 2,2
und 3,3.
Sie sehen ein, dieses Duplikat hier wurde entfernt und damit
entspricht das Verhalten genau dem, was wir von der relationalen
Algebra her erwarten.
Das ist sogar eher unüblich für SQL, wie wir gleich noch sehen würden.
Es gibt in SQL aber noch den Spezialfall des Union Alls und dann sagen
wir explizit, dass er alle aus der Relation 1 und alle aus der
Relation 2 nehmen soll und in die Ergebnisrelation schaufeln soll und
mit Union All werden die Duplikate dann eben nicht erfüllt.
Sie überlegen sich leicht, dass ein Union All natürlich deutlich
billiger ist im Vergleich zu einem Union, weil Sie wirklich nur Ihre
Daten nehmen müssen, sie irgendwo hin tun und dann nochmal die anderen
Daten nehmen, hinten dran ausgeben, das Ganze abschicken und fertig.
Bei einem Union All müssten Sie zum Beispiel zuerst mal sortieren, um
dann die Duplikate rauszufinden oder was auch sonst mittels Hash
-Funktionen oder sonst irgendwelche Strategien Sie sich überlegen.
Und unter Umständen würde es Ihnen ja gar nicht schaden, wenn Sie
Duplikate drin haben.
So, für das Union, die Vereinigung, da gibt es dann auch die
entsprechenden Pendants Intersect und Accept, die dann eben der
Durchschnitts - bzw.
der Differenzbildung dienen und sich wirklich genauso benutzen lassen
und eben auch an der gleichen Stelle mit der gleichen Semantik und
auch alles gleich wie das Union.
Gut, worauf ich an dieser Stelle nochmal jetzt hinweisen möchte, weil
es wichtig ist, ist, dass SQL im Gegensatz zur relationalen Algebra
tatsächlich mit Vielfachmengen arbeitet und eben nicht auf streng
mathematischen Mengen, so wie die relationale Algebra und damit also
Duplikate zugelassen sind und zwar sowohl in den Quellrelationen als
auch in den Ergebnisrelationen.
Das ist etwas, was Sie einfach bedenken müssen, wenn Sie damit
arbeiten.
Das kann gut sein für Sie, das kann schlecht sein für Sie, Sie müssen
es nur wissen.
Duplikate werden von den meisten SQL-Befehlen nicht automatisch
bereinigt, so wie von Union zum Beispiel.
In dem Fall können Sie aber immer mit dem Schlüsselwort distinct dafür
sorgen, dass Sie die Duplikate rausschmeißen.
Sie haben jetzt irgendeine Relation 1,1, 1,2, 1,3 mit irgendeinem
Schema A und B, das sind beides ganze Zahlen.
Und Sie wählen einmal von diesem Schema hier nur die erste Komponente
raus, also das 1,1,1, das entspricht ja jeweils dem A und geben das
Ganze zurück, dann bekommen Sie 1,1,1 bei Select.
Dann bekommen Sie tatsächlich die Duplikate zurück.
Wenn Sie Select distinct schreiben, dann schmeißt er die Duplikate
raus und wird Ihnen nur ein einzelnes Tuppel mit einer 1 drin
zurückgeben.
Sie sehen wieder, da Sie es schachteln können, können Sie ihr distinct
zum Schluss immer machen, dann haben Sie alle Duplikate zum Schluss
rausgeschmissen.
Okay.
Wichtig noch für etwas komplexere Anfragen, die so in Richtung, das
will der Betriebswirtschaftler wissen, gehen, ist die sogenannte
Gruppierungsfunktion von SQL.
Eine Frage, die sich da zum Beispiel auf uns zu bewegen könnte, wäre,
welche Firma hat wie viele Frachtkosten bei uns bedient?
Wir haben ja, wenn wir uns das Schema nochmal angucken,
wir haben Bestellungen und in diesen Bestellungen gibt es eben
irgendwo ein Feld, da stehen die Frachtkosten drin, die angefallen
sind, als wir diese Bestellung versendet haben.
Und wir haben diese Bestellung versendet über eine bestimmte
Versandfirma und weil wir jetzt mit dieser Versandfirma reden wollen
und einen Rabatt raushandeln wollen, wollen wir natürlich wissen, hey
Jungs, wir haben bei euch so und so viel, tausende Euro Umsatz
gemacht, wir wollen 10%, 15% oder was auch immer.
Um diese Anfrage zu stellen, können wir erstmal anfangen und sagen,
okay, dazu müssen wir wohl erstmal gucken, wer hat denn welche
Bestellung geliefert, wir müssen also wohl erstmal so ein Join machen
an dieser Stelle.
Und was uns dann interessiert, ist im Endeffekt nur der Firmennamen
und was hinten bei Frachtkosten rauskam.
Das Ergebnis, was dann eben bei rauskommt, sieht dann so aus, Federal
Shipping 32, Dollar 38, Speedy Express und so weiter.
Jetzt könnten wir natürlich die Sekretärin hinsetzen, die dann
anfängt, Federal Shipping das, das, das, das, das macht in Summe dann
irgendwie sowas, die sucht das alles hier raus, danach sucht sie dann
Speedy Express raus und macht die nächste Summe, aber irgendwie ist
das ja nicht so richtig effizient.
Na klar, sagen sie, der Herr Gehlhausen hat uns ja letzten Freitag
schon das Order-Bye-Bye gebracht, das heißt, wenn
sich die Hormone wieder beruhigt haben, dann...
Das heißt, unsere Sekretärin braucht sich wenigstens nicht die Arbeit
machen, um das Ganze hier jetzt auch noch zu sortieren, sondern
sortiert geben, was ihr automatisch.
Letztendlich ist das aber immer noch nicht schön, da muss man sich
jetzt, das ist ja ein Computer und rechnen kann der ja eigentlich
selber, jetzt muss man das noch alles in den Taschenrechner tippen
oder irgendwie ins Excel reinkopieren, nee, wollen wir auch alles
nicht.
Was wir im Endeffekt wollen, ist ja nur, dass wir hier dieses Federal
Shipping alles zusammen irgendwie als Gruppe auffassen und dann halt
eine Summe darüber bilden, über alles, was in dieser Gruppe an
Frachtkosten anfällt.
Und genauso, ich meine, mit der Sortierung waren jetzt natürlich blöd,
weil sie die anderen da unten nicht mehr sehen, aber sie glauben ja,
dass da unten ja dann so ganze Gruppen von anderen Frachtfirmen noch
kommen.
So, und dafür bietet SQL jetzt eine Hilfestellung an, und zwar das
Gruppieren.
Wir gruppieren einfach nach bestimmten Attributen mit Group-Bye und
verwenden dann eine Aggregationsfunktion.
Das ist also so mal die Marschrichtung.
Was ist Group-Bye?
Group-Bye teilt unsere Tuppel der Ergebnisrelation in Gruppen ein, und
zwar, wenn Sie jetzt eine gewisse Attributmenge in die Group-Bye
-Clause schreiben, dann bekommen Sie eine Äquivalenzrelation bezüglich
dieser Attribute.
Also alle Datensätze, die bezüglich dieser Attribute gleich sind,
fliegen in eine Gruppe rein.
So, dieses Group-Bye ist optional.
Wir haben es ja bisher nicht verwendet, also muss man es wohl offenbar
nicht.
Und es steht zwischen Where und Order-Bye.
Das sehen wir gleich im Beispiel nochmal.
Dann können wir Aggregationsfunktionen verwenden.
In dem Zusammenhang sei zuerst mal die pauschalste
Aggregationsfunktion, die wir ganz ohne Group-Bye auch verwenden
können.
Das wäre nämlich das Count-Stern, was einfach die Tuppel in Ihrer
Ergebnisrelation zählt.
Wenn Sie irgendeine riesen Kreuzproduktrelation aufbauen und sich
irgendwie nicht sicher sind, wie lange die Datenbank braucht, um das
zu berechnen, können Sie zuerst mal Ihre ganze Anfrage absetzen mit
Count -Stern.
Und dann sagt Ihnen die Datenbank erst mal, wie viel sie denn jetzt
überhaupt berechnen würde.
Die hat aber jetzt in dem Moment nichts mit der Gruppierung zu tun,
steht aber der Vollständigkeit halber mit auf der Folie bei den
Aggregationsfunktionen.
Die Aggregationsfunktionen, die uns an dieser Stelle interessieren,
sind die Min, die Max, die AVG, also Average, also Durchschnitt, die
Summe und die Count für die Anzahl der Tuppel in einer
Äquivalenzmenge.
So, und wenn Sie jetzt eben dieses Min verwenden und dann den Namen
irgendeines nicht probierten Attributes da reinschreiben, dann
bekommen Sie das Minimum der Elemente in der Spaltengruppe.
Wichtig an dieser Stelle nochmal die Erwähnung von Count.
Beim Zählen ist es ja irgendwie schon wichtig, dass wir wissen, ob wir
jetzt die Duplikate mitgezählt haben oder nicht.
Mit dem Distink können Sie sich sicher sein, dass Sie keine Duplikate
dann mehr drin hatten.
So, wie sieht das Ganze in der Anwendung aus?
Ich habe Ihnen gesagt, wir schreiben dieses Group-By einfach hier
dazwischen, zwischen das Square und das Order-By und wir gruppieren
jetzt nach Firma.
Klar, wir hatten vorher so eine Riesenliste, da war alles gleich mit
Firmen und wir wollen ja eigentlich alles zusammen haben und dann
wollen wir davon ja die Summe berechnen.
Okay, dann sagen wir einfach Summ B Punkt Frachtkosten.
Wichtig, es gibt hier so eine Art Klammer für
dieses Group-By, da habe ich ja die beste Farbe ausgesucht.
Die ist ja gerade so gut, also machen wir es ätzend.
Also, Sie haben hier so eine Art Klammer.
Das heißt, Sie können hier innen drin alle Attribute verwenden, wie
bisher auch.
Was Sie nicht können, ist hier außen verwenden alle Attribute, wie
bisher auch, sondern Sie können für sich alleine genommen nur
diejenigen Attribute verwenden, die auch tatsächlich in dieser Group
-By -Clause stehen.
Also, wenn Sie hier weitere Attribute aufführen wollten, die nicht in
der Group-By-Clause stehen, dann würde Ihnen der SQL-Interpreter einen
Fehler zurückliefern.
Sie können aber diese dann alle in diesen Aggregationsfunktionen
verwenden, wie Sie das wollen.
Genauso verhält sich es natürlich mit dem Order-By.
Sie können hier bei dem Order-By dann natürlich auch nicht nach, was
weiß ich, Telefonnummer sortieren, der Firma, weil Sie da keinen
Zugriff mehr drauf haben, weil Sie ja alles zusammengruppiert haben.
Und deswegen müssten Sie, wenn Sie jetzt zum Beispiel nach
Telefonnummer sortieren wollten, auch wenn Sie sie oben nicht
zurückgeben, hinten noch dran schreiben, Komma v.tel.
Und dann können Sie hier schreiben, v.tel.
Sie sehen ein, das verändert Ihnen die Ausgabe in keiner Weise, das
Ergebnis, weil eine Firma ja immer die gleiche Telefonnummer hat.
Das heißt, alles, was Sie bezüglich des Firmennamens in eine Gruppe
schmeißen, würden Sie natürlich auch bezüglich der Telefonnummer in
eine Gruppe schmeißen.
Sie sehen ein, das ist ein bisschen tricky und deswegen müssten Sie
das vielleicht dann auch zu gegebenen Zeitpunkten ein bisschen üben.
Warum reiten wir denn so auf relationaler Algebra rum, wenn wir doch
eigentlich mit Ihnen mal nur primär SQL angesprochen haben wollen?
Na, Sie sehen zum einen ein, zu einer SQL-Anfrage, sofern sie eben
nicht sich mit speziellen Dingen befasst, wie jetzt der Eigenschaft,
eine Vielfachmenge zu sein oder sonst was, können wir problemlos
überführen einen Ausdruck in relationaler Algebra, in dem Fall wäre
das Kreuzprodukte von Mitarbeiter und Projekte, also das hier.
Und dann haben wir irgendwelche Bedingungen noch dran geknüpft, also
zum Beispiel, dass wir hier ein Join machen.
Da ist natürlich an der Stelle auch ein Rechtschreibfehler und unser
Budget prüfen wir und machen noch eine Projektion auf den Nachnamen.
Was Ihnen bis jetzt spätestens aufgefallen sein sollte, ist das
wirklich, dass hier vorne immer gleich ist.
Das ist immer gleich, das können Sie hinschreiben wie irgendein Muster
pauschal und danach überlegen Sie sich, was Sie da hinten ausfüllen.
Ja, aber soweit Syntax von SQL, immer einfach, immer die Reihenfolge.
Gut, Sie machen halt mal was dazu, was Sie dann noch brauchen, das ist
dann an der Stelle oder hinten dran noch, aber immer dieses Muster.
So, wir haben hier einen Ausdruck in einer ordentlichen Algebra.
Und zu einer Algebra haben wir dann zum Beispiel gelernt, dass wir
solche Ausdrücke auch darstellen können als Kantorowitschbaum.
In der Datenbankwelt nennt man das Ganze dann Anfragebaum und man malt
das dann so ab, dass man die Quelltabellen unten hinschreibt, entweder
wie hier als Block oder, was eigentlich üblicher ist noch, dass Sie so
einen Zylinder malen.
Als Abstraktion für eine Festplatte.
Das heißt, wir haben wohl offenbar hier in unserem Schema zwei
Tabellen, eine heißt Mitarbeiter, eine heißt Projekte und von dieser
Tabelle bilden wir nun das Kreuzprodukt.
Nachdem wir das Kreuzprodukt gebildet haben, machen wir eine Selektion
und zwar auf diese Attribute hier und danach eine Projektion auf den
Nachnamen.
Und dieser Anfragebaum ist jetzt der Ausgangspunkt für die Optimierung
in SQL.
Was ist denn überhaupt, was wollen wir denn da optimieren?
Wir wollen natürlich, dass unsere Anfragen so schnell wie möglich
berechnet werden können.
Wir wollen dabei, dass natürlich das Ergebnis trotzdem das gleiche
bleibt.
Und wie können wir das erreichen?
Im Allgemeinen dadurch, dass die Zwischenergebnisse, die wir
berechnen, möglichst klein werden.
Sie erinnern sich, das Kreuzprodukt war eine extrem teure Operation.
Entsprechend der Anzahl von den Tabellen, also sagen wir mal drei
Tabellen, war dann O von N hoch drei, vier Tabellen war dann O von N
hoch vier, also O von quadratisch, quatsch, kubisch, exponentiell.
Und jetzt, da wir in einer Algebra sind, können wir natürlich anfangen
uns zu überlegen, was können wir uns denn für Gesetze ausrechnen oder
ausdenken?
Was können wir denn da haben, um das Ganze umzubauen?
Zum einen haben wir zum Beispiel die Kommutativität von der Selektion
und auch vom kathesischen Produkt.
Das heißt, die Selektion nach dem Prädikat P, angewendet auf die
Selektion nach dem Prädikat Q, auf eine bestimmte Relation Rho, ist
das Gleiche wie die Selektion P und Q von Rho.
Und das ist natürlich dann das Gleiche wie Selektion nach Q, nach
Selektion bezüglich P von Rho.
Also einfach nur die beiden vertauschen.
Dann gilt auch noch Assoziativität, sprich Rho1 Kreuzprodukt mit Rho2
und dann Kreuzprodukt mit Rho3 gebildet, ist das Gleiche, wenn Sie
Rho1 das Kreuzprodukt dann mit dem Kreuzprodukt aus Rho2 und Rho3
verbinden.
Das ist erstmal so, was uns als allererstes einfällt.
Wenn wir ein bisschen genauer hingucken, können wir auch noch was
bezüglich der Projektion sagen.
Wenn wir von einer, sagen wir mal, fünfstelligen Relation erst drei
Stellen ausblenden und dann nachher mal noch eine Stelle ausblenden,
dann ist das im Endeffekt das Gleiche, wie wenn wir gleich eine Stelle
nur genommen hätten.
Das gilt also, dass dieser Zusammenhang, wenn die Liste auf die
projiziert wird, eine Teilmenge dieser Liste ist.
Das Gleiche haben wir dann, dass wir zum Beispiel Sigma und das
Kreuzprodukt zusammenfassen können zu einer Joint-Operation.
Das war ja nun genau die Definition der Joint-Operation.
Dann können wir noch ein paar andere Dinge zeigen, dass man zum
Beispiel Pi über Sigma ziehen kann, Pi über den Joint ziehen kann und
die Selektion ebenfalls über den Joint ziehen kann.
Und zwar, dabei sind halt immer gewisse Randbedingungen dran geknüpft.
Aber Sie sehen ein, dass ich zum Beispiel, wenn ich jetzt die beiden
Tabellen miteinander verbinde und danach alle wegwerfe, wo ein
bestimmtes Prädikat erfüllt ist, also hier Budget kleiner 40.000, dass
ich gleich zuerst die, bei denen das Budget kleiner 40.000 ist, joinen
kann mit denen in M.
Das ist zunächst mal plausibel, braucht aber ein bisschen
Formalisierung und den Beweis dürfen Sie als Übung machen.
So, wie sieht das aus in unserem Beispiel hier?
Das war unser Ausgangsbaum, das heißt, wir hatten unsere Mitarbeiter
und unsere Projekte, davon das Kreuzprodukt, dann die Selektion
bezüglich irgendwelcher Prädikate und dann die Projektion auf den
Nachnamen.
Erstmal ziehen wir die Selektion auseinander, das war praktisch der
erste Punkt auf unserer vorhergehenden Folie bezüglich der
Optimierungen, die wir tun dürfen.
Der nächste Schritt wäre dann, dass wir diese aufgespaltenen
Selektionen, also das beides hier, zu einem Join zusammenfassen.
Ein Join, wenn ich weiß, dass der durchgeführt wird, ist natürlich
effizienter zu berechnen als zuerst das Kreuzprodukt und dann ganz
viele wieder wegzuschmeißen, indem ich nämlich gleich, also dafür gibt
es mehrere Strategien, um Joins effizient zu berechnen, zum Beispiel,
dass ich durchgehe, wenn die beiden sortiert sind, und dann abgleiche,
wann finde ich tatsächlich gleiche Paare und solche Dinge.
Das ist natürlich deutlich effizienter.
Der nächste Schritt wäre dann, dass wir unsere Selektionen über
unseren Join drüberziehen und uns gleich aus der Tabelle Projekte nur
diejenigen rausholen, für die das Budget überhaupt größer als 40.000
ist.
Für den Rest brauchen wir den Join gar nicht zu berechnen, der
interessiert uns ja eh nicht.
Dann im nächsten Schritt schauen wir uns an, wie wir die Projektion
nach unten ziehen können und zwar so, wir müssen sie in dem Fall nach
unten ziehen unter diesem Join und wir brauchen bei der Projektion
noch den Nachname und wir brauchen noch den PID der Tabelle M und wir
brauchen den PID der Tabelle P. Das heißt, wir brauchen aus der
Tabelle Mitarbeiter noch den Nachname hier oben zum Ausgeben und für
den Join brauchen wir noch das M.
Und wir brauchen hier nur das PID, nachdem wir hier diese Selektion
gemacht haben.
Und oben müssen wir halt, da ja hier jetzt eigentlich drei
zurückkommen noch nach dem Join, müssen wir halt trotzdem immer noch
eine Projektion lassen.
Sie sehen aber ein, dass wir uns trotzdem hier an beiden Enden etwas
sparen, weil wir hier einen Haufen Daten schon wegwerfen können und
auch hier.
So, der letzte Schritt wäre dann, dass wir diese Projektion nochmal
unter die Selektion ziehen, soweit uns das möglich ist.
Wir brauchen hier noch die PID, deswegen bleibt sie hier auch wieder
stehen, aber wir brauchen schon aus der ursprünglichen Tabelle nur die
PID, um das Budget rauszuholen.
Die ganzen anderen Felder interessieren uns nicht, deswegen lassen wir
sie auch gleich auf der Platte.
Jetzt stellen Sie natürlich die Frage, naja, wenn das alles so
hintereinander auf der Platte steht, wie will ich denn da überhaupt
die Dinger rauslesen einzeln?
Antwort, Ihr relationales System muss sie durchaus nicht alle zusammen
auf die Platte schreiben.
Die können in verschiedenen Indexstrukturen verstreut sein, die können
über verschiedene Rechner verstreut sein, also es ist bei großen
Clustern nicht unüblich, dass bestimmte Attributfolgen auf ganz
anderen Rechnern sind als andere Attributfolgen.
Das wäre dann vertikale Fragmentierung, entsprechend praktisch der
Tabellenlinie lang über die Rechner.
Sie können auch horizontale Fragmentierung treiben, dass Sie einfach
einen gewissen Ausschnitt aus Ihrer Tabelle auf den einen Rechner, den
nächsten Ausschnitt auf den anderen Rechner und dementsprechend ist es
natürlich günstig, wenn Sie wissen, dass das soweit geht.
Ob es letztendlich für den konkreten Einsatzfall sinnvoll ist, das
können wir hier pauschal sowieso nicht beantworten, das können Sie im
konkreten Anwendungsfall auch nicht beantworten.
Das weiß nur die Datenbank, die intern sich das Ganze mitschreibt, die
weiß, wie mächtig die Tabellen sind, wo die Tabellen rumliegen.
Die Datenbank weiß, was sie für Strategien zur Verfügung hat zum
Verbinden der Datensätze und alles andere auch, was sie für
Indexstrukturen hat.
Und deswegen ist es also hilfreich, dass wir unser SQL tatsächlich
dafür eine Relationenalgebra haben, dass wir da tatsächlich
Optimierungen machen können und von der hinterher auch noch wissen,
dass sie tatsächlich das Ergebnis zurückliefert, das wir gerne hätten.
Also ich würde Sie bitten, wenn Sie Schwätzchen halten wollen, dann
gehen Sie doch einfach einen Kaffee trinken, dann stören Sie
vielleicht Ihre Kollegen und auch mich nicht so arg.
Ich möchte nochmal zusammenfassen, SQL arbeitet auf der theoretischen
Grundlage der relationalen Algebra.
Warum?
Ich hoffe, ich habe Ihnen jetzt gerade hierfür einen ordentlichen
Grund gezeigt.
Dann ist bei SQL der große Unterschied zur relationalen Algebra, dass
wir Vielfachmengen verarbeiten und noch genauer gesagt sogar Listen.
Das heißt, aus der Vielfachmenge folgt, dass sowohl in Quell- als auch
in Ergebnisrelationen, dass da Duplikate drin sein können.
Als Hinweis nochmal an dieser Stelle, die werden Sie los mit dem
Schlüsselwort distinct und die Tuppel in der Relation, deswegen
genauer gesagt Listen, haben auch eine Reihenfolge, was Sie in der
relationalen Algebra nicht haben, die man beeinflussen kann, Stichwort
order by.
Nächster wichtiger festzuhaltender Punkt ist, dass SQL eine
deklarative Sprache ist und dass Sie Ihrem System sagen, was Sie haben
sollen und nicht, wie dieses Datenbanksystem Ihnen die Daten jetzt aus
einer Tabelle und filtern und was weiß ich was noch nicht alles soll.
Daraus ergeben sich eben, wie ich erklärt habe,
Optimierungsmöglichkeiten für das Datenbanksystem, die Sie so im
Einzelnen gar nicht so weit treiben könnten.
Wichtiger Hinweis an dieser Stelle noch, das zentrale Konzept bei SQL
in Bezug auf Select ist das Join.
Und daher würde ich Sie bitten, dieses Join sich nochmal sehr genau
anzuschauen, dieses Join versuchen zu verstehen und es dann üben,
üben, üben, üben.
Haben Sie noch Fragen?
So, dann können Sie jetzt einen Kaffee trinken gehen.