WEBVTT

02:48.080 --> 02:51.230
So, willkommen zur heutigen Vorlesung.

02:52.350 --> 02:56.310
Erstmal in eigener Sache, ich lasse ja immer andere Werbung machen,

02:56.430 --> 02:58.850
mache ich auch mal für mich selber Werbung, beziehungsweise nicht für

02:58.850 --> 03:03.990
mich selber, sondern für eine Institution, die an der Universität

03:03.990 --> 03:07.970
angesiedelt ist, sich aber etwas stärker der Transfer in die

03:07.970 --> 03:12.230
Wirtschaft geöffnet hat, dem FZI, und ein paar Prospekte habe ich oben

03:12.230 --> 03:17.040
ausgelegt, wer also Interesse hat, sich etwas näher mit dem FZI zu

03:17.040 --> 03:20.940
beschäftigen und vielleicht auch dort tatsächlich tätig zu werden, der

03:20.940 --> 03:24.380
möge sich einfach da oben einen der ausliegenden kurzen Flyer

03:24.380 --> 03:25.200
mitnehmen.

03:26.640 --> 03:30.120
So, heute haben wir zwar ein ordentliches Programm vor uns, aber es

03:30.120 --> 03:31.220
ist ein leichtes Programm.

03:31.700 --> 03:35.180
Wir können also relativ schnell durchgehen, weil die

03:35.180 --> 03:39.680
Informationsdichte nur dadurch erreicht wird, dass ich relativ schnell

03:39.680 --> 03:40.380
durchlaufe.

03:41.020 --> 03:47.240
Und zwar nehmen wir uns jetzt, wie wir sehen, mal der Datenbankdienste

03:47.240 --> 03:48.000
selbst an.

03:48.280 --> 03:51.280
Wir sehen uns also Datenbanksystemen, da haben wir ja die Architektur

03:51.280 --> 03:53.660
das letzte Mal angesehen, jetzt machen wir aber einen schwarzen Kasten

03:53.660 --> 03:58.720
draus und sagen, uns interessiert überhaupt nur, wie dieses System als

03:58.720 --> 04:02.460
Ressourcenverwalter nach außen wirkt, also welche Dienste es anbietet

04:02.460 --> 04:06.100
und wie es die Dienstqualitäten, die wir ja inzwischen alleingeführt

04:06.100 --> 04:08.920
haben, für die Datenbanksysteme, wie die sich nach außen bemerkbar

04:08.920 --> 04:09.160
machen.

04:14.040 --> 04:17.480
Das hatte ich ja schon mal vorgeführt, wenn wir so ansehen, wo wir

04:17.480 --> 04:21.220
denn momentan Konsistenz und wie wir die schrittweise erreichen, dann

04:21.220 --> 04:23.760
bewegen wir uns jetzt erstmal ganz auf der linken Seite beim

04:23.760 --> 04:24.480
Datenmodell.

04:24.560 --> 04:28.040
Wir betrachten also nur, wie strukturiert wird, wie die Zustandsräume

04:28.040 --> 04:33.120
zustande kommen, jetzt flackert es aber ordentlich, und wie die

04:33.120 --> 04:36.680
Dienste aussehen, das heißt, wie unsere Polymorphen-Operatoren

04:36.680 --> 04:37.280
aussehen.

04:37.280 --> 04:41.740
Und damit erreichen wir ja zunächst einmal eine generische

04:41.740 --> 04:45.600
Dienstfunktionalität, die besagt, dass ich für sehr viele

04:45.600 --> 04:51.020
unterschiedliche Anwendungswelten mit den gleichen Diensten auskomme.

04:51.360 --> 04:53.260
Und das führt sofort zu Problemen.

04:53.460 --> 04:58.240
Die Frage nämlich, wenn ich ein bestimmtes Datenmodell vorgebe, ist

04:58.240 --> 05:03.600
das nun wirklich für alle Anwendungswelten brauchbar oder muss ich

05:03.600 --> 05:07.200
gelegentlich mich etwas einschränken und ich suche mir ganz bestimmte

05:07.200 --> 05:10.180
Anwendungswelten heraus, für die es gut geeignet ist und muss dann die

05:10.180 --> 05:14.680
Frage stellen, wenn meine Anwendungswelt ganz anders aussieht, muss

05:14.680 --> 05:16.640
ich dann eventuell auf ein anderes Datenmodell übergehen.

05:18.040 --> 05:20.800
Das sagt auch ein bisschen was zur Historie aus.

05:20.940 --> 05:22.320
Das ist nochmal unser schwarzer Kasten.

05:22.380 --> 05:24.360
Wir bewegen uns nur oben an der obersten Schnittstelle.

05:26.080 --> 05:29.840
Und wir können jetzt mal die Frage stellen, wenn wir jetzt tatsächlich

05:29.840 --> 05:33.240
praktische Systeme einsetzen müssen, die möglichst weitgehend

05:33.240 --> 05:36.840
eingesetzt werden können, die also für das Web sich eignen und für die

05:36.840 --> 05:40.440
Unternehmenssoftware sich eignen und für Geschäftsprozesse sich eignen

05:40.440 --> 05:45.100
sollen und für technische Prozesse sich eignen sollen und sogar für

05:45.100 --> 05:49.140
Realzeitverhaltenssorge tragen, ist das alles mit einem und demselben

05:49.140 --> 05:52.800
Datenmodell machbar oder braucht man dazu unterschiedliche

05:52.800 --> 05:53.500
Datenmodelle?

05:53.980 --> 05:57.320
Und da sehen wir, dass wir durchaus in ein gewisses Dilemma geraten.

05:57.420 --> 06:01.100
Es ist nicht so einfach zu sagen, welchen Weg man einschlägt, wie

06:01.100 --> 06:04.060
speziell soll man werden oder wie breitbandig soll man werden.

06:04.060 --> 06:09.300
Die eine Frage, die wir uns stellen müssen, ist, wollen wir eher

06:09.300 --> 06:10.300
universelle Anwendbarkeit?

06:11.100 --> 06:16.720
Dann geht das nicht ohne Zugeständnisse, die die Anwendungen an die

06:16.720 --> 06:17.660
Technik machen müssen.

06:17.880 --> 06:21.240
Also da wird eine Anwendung die bestimmte Ziele verfolgt und nicht

06:21.240 --> 06:22.200
alle Ziele verfolgen können.

06:22.580 --> 06:26.860
Wenn sie sich auf eine möglichst allgemeine Einsetzbarkeit,

06:26.960 --> 06:32.080
universelle Anwendbarkeit ihrer Dienste abstützen will.

06:32.760 --> 06:35.520
Auf der anderen Seite, wenn sie sehr speziell sein will, dann hat sie

06:35.520 --> 06:39.340
eventuell überhaupt kein Datenmodell und keinen Anbieter, der ihr das

06:39.340 --> 06:42.100
Datenmodell anbietet und die entsprechenden Dienste anbietet.

06:42.300 --> 06:45.160
Sie müssen es selber implementieren und das ist extrem teuer.

06:45.400 --> 06:46.720
Dann werden die meisten überhaupt nicht überleben.

06:48.220 --> 06:53.100
Wenn sie gewillt sind, Zugeständnisse zu machen und sich auf Dienste

06:53.100 --> 06:56.620
allgemeiner Anwendbarkeit abzustützen, dann kriegen sie es mal

06:56.620 --> 06:57.820
allgemein kostengünstig.

06:57.820 --> 07:00.640
Also eine wirtschaftliche Frage an dieser Stelle.

07:01.740 --> 07:11.120
Hier bin ich wirtschaftlich im Allgemeinen und hier bin ich umgekehrt

07:11.120 --> 07:13.220
zugeschnitten auf meine Bedürfnisse.

07:21.100 --> 07:23.300
Es kommt noch ein zweites Dilemma hinzu.

07:23.440 --> 07:27.180
Wir haben ja gesagt, Performance ist ein ganz entscheidendes

07:27.180 --> 07:27.530
Kriterium.

07:28.440 --> 07:32.800
Die beste Funktionalität nützt nichts, wenn die Performance nicht

07:32.800 --> 07:34.020
hinreichend gut ist.

07:34.020 --> 07:39.040
Und das spielt sich ab auf der Frage der Ausdrucksmächtigkeit.

07:39.140 --> 07:42.400
Wie mächtig sollte die Ausdrucksfähigkeit meines Datenmodells sein

07:42.840 --> 07:45.820
versus der Effizienz der Implementierung.

07:46.540 --> 07:47.920
Das ist also eine Performance-Frage.

07:48.720 --> 07:54.240
Und auch da muss man natürlich sagen, je ausdrucksmächtiger ich werde,

07:54.940 --> 07:59.520
das kann man ziemlich grob abschätzen, umso mehr leidet die

07:59.520 --> 08:00.300
Performance darunter.

08:00.300 --> 08:04.140
Ich muss einfach zu viele spezielle Situationen abfangen.

08:04.260 --> 08:07.960
Ich muss ein zu breites Spektrum von Situationen abfangen können.

08:08.320 --> 08:11.200
Und das geht nicht ohne Einbußen an die Performance ab.

08:11.340 --> 08:13.320
Wir werden später auch sehen, warum das so ist.

08:14.120 --> 08:17.200
Wenn wir also auf die Performance großen Wert legen, dann werden wir

08:17.200 --> 08:23.040
bei der Ausdrucksmächtigkeit etwas zurück nachgeben müssen.

08:23.260 --> 08:26.860
Und das führt wieder dazu, dass wir dann auch wieder eher in die

08:26.860 --> 08:28.680
Richtung der universellen Anwendbarkeit kommen.

08:29.800 --> 08:31.580
Nun, die Frage ist natürlich uralt.

08:32.820 --> 08:36.300
Wenn wir uns die Historie der Datenmodelle ansehen, dann hat die heute

08:36.300 --> 08:38.600
auch ihre 30 Jahre und mehr auf dem Buckel.

08:39.620 --> 08:43.100
Und es hat mal Zeiten gegeben, da sind so an die 25 verschiedenen

08:43.100 --> 08:44.700
Datenmodelle in der Diskussion gewesen.

08:45.460 --> 08:47.040
Wenn Sie sich heute ansehen, was ist übrig geblieben?

08:47.360 --> 08:48.140
Nur ganz wenige.

08:49.680 --> 08:53.260
Die hier haben wir ein paar Mal aufgeführt, die übrig geblieben sind.

08:53.940 --> 08:57.400
Da gibt es das sogenannte hierarchische Modell und das

08:57.400 --> 08:58.260
Netzwerkdatenmodell.

08:59.400 --> 09:01.220
Von denen hören Sie heute überhaupt nichts mehr.

09:01.480 --> 09:03.900
Aber nur im universellen Bereich hören Sie natürlich nichts davon.

09:04.260 --> 09:06.860
Wenn Sie rausgehen in Unternehmen, dann stellen Sie sich fest, da gibt

09:06.860 --> 09:07.920
es diese Modelle, sehr wohl.

09:08.580 --> 09:10.800
Und in die ist auch enorm investiert worden.

09:11.240 --> 09:12.920
Viele Anwendungen laufen darauf.

09:13.460 --> 09:16.960
Und das sind die sogenannten Altanwendungen oder Altlasten oder

09:16.960 --> 09:19.940
inzwischen gibt es auch so einen Fachausdruck Legacy Systems.

09:19.940 --> 09:23.200
Das sind Systeme, die werden die Unternehmen nicht mehr los.

09:23.880 --> 09:26.540
Weil sie enorm investiert haben, weil ihre Geschäftsprozesse sehr

09:26.540 --> 09:28.260
stark auf diese Systeme zugeschnitten sind.

09:28.620 --> 09:31.460
Wenn Sie also rausgehen nach einer beruflichen Praxis, dann stoßen Sie

09:31.460 --> 09:35.220
auf Systeme, von denen ich Ihnen außer dem Schlagwort nie was erzählen

09:35.220 --> 09:35.540
werde.

09:35.880 --> 09:38.440
Die sind akademisch auch sehr uninteressant, weil sie natürlich sehr

09:38.440 --> 09:41.480
unsystematisch wirken, aus der heutigen Sicht und aus dem heutigen

09:41.480 --> 09:42.500
Kenntnisstand heraus.

09:42.860 --> 09:44.600
Aber Sie werden sich trotzdem darauf einstellen müssen, dass Sie auf

09:44.600 --> 09:47.680
diese alten Luder da noch stoßen und dass Sie mit denen auch irgendwie

09:47.680 --> 09:48.500
fertig werden müssen.

09:48.500 --> 09:50.780
Heute versucht man dann, das wird die Frau Zitterbaden ja so ein

09:50.780 --> 09:54.840
bisschen illustrieren, wird man versuchen, irgendwie drumherum

09:54.840 --> 09:58.600
sogenannte Rapper zu bauen, sodass man die etwas anpasst in die

09:58.600 --> 09:59.480
modernen Datenmodelle.

10:01.040 --> 10:04.020
Die hier spielen also eine große Rolle, aber sie spielen nur eine

10:04.020 --> 10:06.180
große Rolle, wenn man die Vergangenheit betrachtet.

10:07.380 --> 10:11.720
Dann gibt es ein Datenmodell, das dominiert die Welt heute.

10:12.380 --> 10:15.380
Und zwar auch schon seit 25, oder mindestens ja doch gut seit 25

10:15.380 --> 10:17.580
Jahren, das ist das Relationale Datenmodell.

10:17.580 --> 10:19.400
Auf das wollte ich natürlich sehr genau eingehen.

10:20.380 --> 10:23.180
Warum hat das seinen Siegeszug angetreten?

10:23.600 --> 10:26.620
Nun ursprünglich hat es auch gut auf die Anwendungsbedürfnisse

10:26.620 --> 10:27.040
gepasst.

10:27.160 --> 10:31.980
Denn die Anwendungen, mit deren Hilfe eigentlich zunächst mal die

10:31.980 --> 10:34.380
Datenbanktechnik groß geworden sind, waren immer klassische

10:34.380 --> 10:37.180
betriebswirtschaftliche und verwaltungstechnische Anwendungen.

10:37.580 --> 10:42.060
Und die folgen in der Tat dieser Tabellenvorstellung, die wir ja auch

10:42.060 --> 10:44.860
schon zu Beginn mal vorgestellt haben.

10:44.860 --> 10:48.080
Man stelle sich alles vor als so eine Art Karteikarten,

10:48.160 --> 10:48.900
Registerkarten.

10:49.320 --> 10:53.140
Und das wird recht gut mit dem Relationalen Datenmodell abgedeckt.

10:55.020 --> 10:59.080
dann hat sich natürlich die Performance gerade dieser Systeme so enorm

10:59.080 --> 11:03.240
gut entwickelt, dass sie heute einfach so als eine Art Kompromiss

11:03.240 --> 11:07.220
zwischen allen möglichen Bedürfnissen bewährt haben und auch heute

11:07.220 --> 11:09.560
unverändert das Feld dominieren.

11:09.720 --> 11:12.040
Natürlich auch mit einer ganzen Menge Weiterentwicklung, auf die wir

11:12.040 --> 11:12.920
auch etwas eingehen werden.

11:12.920 --> 11:15.240
Das werden wir also hier genauer ansehen.

11:16.560 --> 11:20.620
Dann hat man allerdings, als man doch zu neuen Anwendungen

11:20.620 --> 11:24.480
übergegangen ist, und das war zunächst einmal sehr stark technische

11:24.480 --> 11:28.680
Anwendungen, also im Entwurfsbereich, Entwicklungsbereich, im CAD-CAM

11:28.680 --> 11:32.780
-Bereich, ist man auf objektorientierte Systeme gestoßen.

11:32.940 --> 11:35.200
Da hat es zu jener Zeit immerhin schon die ersten objektorientierten

11:35.200 --> 11:36.360
Programmiersprachen gegeben.

11:36.480 --> 11:39.920
Man versucht jetzt auch die Vorstellungen, die hinter den

11:39.920 --> 11:43.420
objektorientierten Sprachen stecken, auf die Datenbank und auf die

11:43.420 --> 11:45.640
Dienstfunktionalität von Datenbanken zu übertragen.

11:45.980 --> 11:49.360
Das ist auch heute noch ein wesentliches Gebiet, insbesondere wenn man

11:49.360 --> 11:52.180
die ganzen multimedialen Anwendungen betrachtet, die sehr stark auf

11:52.180 --> 11:54.360
diesen objektorientierten Ansätzen basieren.

11:54.980 --> 11:59.400
Nur, leider hat man das Problem, die sind erheblich mächtiger in der

11:59.400 --> 12:02.920
Ausdrucksfähigkeit, prompt hat man erhebliche Probleme mit der

12:02.920 --> 12:06.620
Performance bekommen, im Vergleich zu den relationalen Systemen.

12:06.920 --> 12:11.120
Und so richtig durchsetzend haben sich die objektorientierten Systeme

12:11.120 --> 12:11.640
eigentlich nicht.

12:11.700 --> 12:13.680
Sie haben immer ein gewisses Nicht-Dasein geführt.

12:14.100 --> 12:17.400
Und das macht sie teuer, weil auf einmal natürlich der Umschlag

12:17.400 --> 12:20.620
solcher Produkte erheblich geringer ist als die relationalen Systeme.

12:22.320 --> 12:24.220
Heute hat man eine Art Kompromiss.

12:24.500 --> 12:28.020
Man versucht auch die großen Anbieter, und zwar all die Anbieter aus

12:28.020 --> 12:33.420
den relationalen Systemen, die versuchen heute irgendwie auch die

12:34.160 --> 12:35.700
objektorientierung mit einzubauen.

12:35.700 --> 12:39.960
Dann kommt man zu den sogenannten objektrelationalen Systemen, von

12:39.960 --> 12:44.160
denen man sagen kann, da hat man das Beste beider Welten vereinigt.

12:44.620 --> 12:47.620
Aber ich kann Ihnen garantieren, wenn Sie das Beste von zwei Welten

12:47.620 --> 12:49.840
zusammenwerfen, dann zahlen Sie irgendwo einen Preis.

12:50.660 --> 12:53.120
Und dieser Preis ist natürlich erstmal einer sehr viel schwierigeren

12:53.660 --> 12:54.080
Handhabbarkeit.

12:54.480 --> 12:57.560
Außerdem auch, man muss sich entscheiden, wo man die Performance

12:57.560 --> 12:58.120
hinlegt.

12:58.180 --> 13:00.400
Man legt sich halt unverändert die relationalen Systeme.

13:01.600 --> 13:06.680
Und heute, wer modern ist, hat natürlich als Datenmodell XML im

13:06.680 --> 13:11.360
Hinterkopf als dasjenige, das das Internet dominiert, zunächst mal für

13:11.360 --> 13:12.440
den Datenaustausch.

13:12.520 --> 13:17.480
Im Augenblick haben wir bei allen Anbietern einen enormen Aufwand in

13:17.480 --> 13:22.120
der Entwicklung von Dienstfunktionalität, die XML einschließt.

13:22.220 --> 13:26.260
Das wird übrigens heute auch häufig dadurch gemacht, dass man XML in

13:26.260 --> 13:30.240
die Objektwelt transferiert und dann objektrelationale Systeme

13:30.240 --> 13:30.840
anwendet.

13:31.700 --> 13:33.760
Also hier ist auch eine Menge Bewegung.

13:33.920 --> 13:37.280
Sie sehen sozusagen die Historie von ganz alt, treten Sie nur nach

13:37.280 --> 13:40.960
außen an, bis ganz modern, wo sogar die Entwicklung im Augenblick noch

13:40.960 --> 13:42.880
sehr in Bewegung ist, wie hier unten bei XML.

13:47.090 --> 13:50.110
So, und da habe ich ja schon gesagt, wo wir uns beschäftigen.

13:50.750 --> 13:54.090
Und hier ist ein kurzer Überblick, was wir jetzt in den nächsten zwei

13:54.090 --> 13:55.030
Wochen tun werden.

13:55.750 --> 13:59.730
Wir werden uns überwiegend mit dem relationalen Modell beschäftigen,

14:00.190 --> 14:02.670
indem wir erstmal unser Typ-System ansehen.

14:02.790 --> 14:03.930
Das ist ziemlich schnell erledigt.

14:04.390 --> 14:08.470
Dann ob wir die Polymorphen-Operationen betrachten.

14:08.990 --> 14:10.050
Dafür gibt es eine Algebra.

14:10.930 --> 14:15.690
Dann gehen wir auf die Anfragesprache, die eigentlich heute auch zur

14:15.690 --> 14:19.630
Standardisierung oder auch standardisiert ist, und zwar inzwischen in

14:19.630 --> 14:22.670
mehreren Etappen standardisiert ist.

14:22.990 --> 14:23.590
Das ist SQL.

14:24.270 --> 14:26.670
Dann werden wir noch etwas übersichtlich sprechen, also ein extrem

14:26.670 --> 14:30.910
interessantes Konzept, das erlaubt auch auf eine sehr komplizierte

14:31.810 --> 14:34.810
Anwendungswelt oder das Modell dieser Anwendungswelt vereinfachten

14:34.810 --> 14:38.610
Blickwinkel draufzulegen oder auf die eigenen Bedürfnisse

14:38.610 --> 14:41.210
zugeschnittenen Blickwinkel anzulegen.

14:41.470 --> 14:43.250
Und dann werden wir noch kurz etwas zur Sicherheit sagen.

14:45.090 --> 14:48.350
Dann werden wir, um doch mal die Abgrenzung zu machen und zu sagen,

14:48.410 --> 14:51.050
wie sieht es denn aus, wenn wir etwas mächtiger werden, schauen wir

14:51.050 --> 14:53.270
uns noch an, wie die objektorientierte Welt aussieht.

14:53.550 --> 14:57.150
Es ist ganz interessant, sich anzusehen, wie sich Objektorientierung

14:57.150 --> 15:02.650
in Datenbanken unterscheiden muss von Objektorientierung in

15:02.650 --> 15:03.450
Programmiersprachen.

15:03.530 --> 15:05.150
Wir werden trotzdem versuchen müssen, die beiden Welten auch

15:05.150 --> 15:05.850
zusammenzuführen.

15:06.270 --> 15:08.910
Wir werden also insbesondere darüber sprechen, wie passen die zwei

15:08.910 --> 15:10.410
Welten programmiertechnisch zusammen.

15:11.350 --> 15:13.130
Das werden wir im Typsystem tun.

15:13.250 --> 15:14.770
Dann werden wir eben über Operatoren sprechen.

15:14.970 --> 15:17.030
Insbesondere werden wir dann auch sehen, gibt es auch da sowas wie

15:17.030 --> 15:19.850
Polymorphie, das ist ja zunächst mal etwas Ungewöhnliches für die

15:19.850 --> 15:20.710
Objektorientierung.

15:21.070 --> 15:25.690
Und gibt auch da sowas wie eine interaktive Anfragesprache, sodass man

15:25.690 --> 15:31.370
wiederum sein Problem beschreibt in seinen Eigenschaften, aber dem

15:31.370 --> 15:34.310
System überlässt, wie es zur entsprechenden Lösung intern kommt.

15:35.590 --> 15:37.050
Also da haben wir ein ganz ordentliches Programm.

15:38.050 --> 15:41.210
Alles immer unter dem Gesichtspunkt, dass wir das Datenbanksystem

15:41.210 --> 15:42.630
selbst nur als schwarzen Kasten ansehen.

15:42.730 --> 15:44.230
Wir wollen überhaupt nicht wissen, was innen vorgeht.

15:44.590 --> 15:46.650
Wir betrachten nur, wie es sich nach außen darstellt.

15:48.270 --> 15:50.550
So, dann können wir also mit dem relationalen Datenmodell anfangen.

15:51.610 --> 15:57.430
Und das relationale Datenmodell das müssen wir jetzt in zwei Teile

15:57.430 --> 15:58.010
unterteilen.

15:58.110 --> 16:01.810
Wir betrachten einmal das Typsystem, also mehr die Struktur und die

16:01.810 --> 16:02.750
strukturellen Aspekte.

16:02.890 --> 16:04.970
Und anschließend betrachten wir die Operatoren.

16:05.830 --> 16:09.370
Also, wie gehe ich jetzt mit einer solchen Datenbasis um?

16:09.950 --> 16:12.170
Welche Dienstfunktion biete ich nach außen an?

16:12.270 --> 16:15.990
Oder zumindest, welche Vorstellung kann ein Benutzer entwickeln,

16:16.630 --> 16:19.430
welche Operatoren seinen Anfragesprachen zugrunde liegen?

16:24.170 --> 16:29.090
Ich hatte gesagt, das relationale Datenmodell ist von der Struktur her

16:29.090 --> 16:30.270
außerordentlich einfach.

16:30.570 --> 16:33.290
Also, die Ausdrucksmächtigkeit ist nicht sonderlich weit her.

16:34.890 --> 16:38.030
Und getrieben worden ist die Entwicklung sehr stark aus dem

16:38.030 --> 16:41.070
kommerziellen Bereich, bei dem man bisher mit Karteikarten und

16:41.070 --> 16:42.350
ähnlichen Dingen gearbeitet hat.

16:43.170 --> 16:46.850
Und wir sehen auch, dass infolgedessen, was hier steht, die Struktur

16:46.850 --> 16:50.130
ist, die ich auch schon mal so als Tabellenmodell ganz am Anfang

16:50.130 --> 16:51.450
eingeführt habe.

16:51.830 --> 16:54.730
Wir haben eine Reihe atomarer Typen.

16:56.470 --> 16:58.350
Die meisten kommen mir irgendwie bekannt vor.

16:58.630 --> 16:59.970
Zeichenketten haben wir.

17:00.410 --> 17:06.410
Integer, dann haben wir numerische Werte, die im allgemeinen

17:06.410 --> 17:09.630
Dezimalsystem beschrieben sind.

17:10.070 --> 17:11.470
Dann haben wir Gleitkommazahlen.

17:11.810 --> 17:13.790
Und dann haben wir noch hinten, das hatte ich auch schon mal erwähnt,

17:14.290 --> 17:18.350
dass im Datenbankbereich häufig auch Angaben zur Zeit und zu

17:18.350 --> 17:19.690
Gültigkeiten eine Rolle spielen.

17:20.670 --> 17:25.170
Datumsangaben, Tageszeitangaben und Timestamp ist einfach eine

17:25.170 --> 17:26.130
Kombination aus beiden.

17:28.230 --> 17:31.550
Und wenn es jetzt darum geht, Typen zu konstruieren, dann brauchen wir

17:31.550 --> 17:35.110
also polymorphe Operatoren, aus denen sich polymorphe Strukturen

17:35.110 --> 17:38.950
regeln, mit denen wir Typen konstruieren.

17:39.190 --> 17:41.430
Und wir konstruieren im Wesentlichen zwei Dinge.

17:42.390 --> 17:45.090
Datensätze und Mengen von Datensätzen.

17:45.250 --> 17:47.850
Und die heißen halt jetzt hier in dem speziellen Fall Tupel.

17:48.030 --> 17:50.250
Tupel ist also nichts anderes als ein Datensatz, wie Sie sehen.

17:51.270 --> 17:56.150
Er wird aufgebaut wie ein klassischer Datensatz aus Feldern.

17:56.630 --> 18:00.250
Diese Felder, die bestehen hier immer aus atomaren Typen.

18:00.430 --> 18:01.630
Also was anderes lassen wir schon gar nicht zu.

18:02.030 --> 18:03.450
Außer atomaren Typen.

18:03.930 --> 18:05.190
Also irgendetwas, was da oben steht.

18:06.490 --> 18:14.550
Und die Menge solcher Sätze des gleichen Typs, die bezeichnen wir als

18:14.550 --> 18:15.230
eine Relation.

18:17.390 --> 18:18.330
Warum Relation?

18:18.510 --> 18:20.350
Da müssen wir noch ein bisschen später drauf eingehen.

18:20.470 --> 18:25.330
Später, dass tatsächlich wir hier sehr bewusst sogar zumindest sehr

18:25.330 --> 18:27.590
nah an mathematische Relationen rankommen.

18:27.730 --> 18:28.550
Und das ist natürlich eine feine Sache.

18:28.910 --> 18:32.090
Wenn uns das tatsächlich gelingt, das auf so eine Art mathematisches

18:32.090 --> 18:34.910
Modell zu bringen, dann können wir hinterher eine Menge Formalismus

18:34.910 --> 18:36.650
und formale Betrachtungen anstellen.

18:36.950 --> 18:40.030
Wir können Beweise führen, wir können Algorithmen ableiten und können

18:40.030 --> 18:42.750
tatsächlich eine richtig formale Umsetzung durchführen.

18:43.090 --> 18:47.830
Und das ist auch einer der Gründe, warum das Relationale Modell auch

18:48.910 --> 18:51.830
im akademischen Bereich sehr schnell vorangetrieben worden ist und der

18:51.830 --> 18:53.730
akademische Bereich das aber auch die Entwicklung in der Industrie

18:53.730 --> 18:55.310
sehr stark beeinflusst hat.

18:55.570 --> 18:57.290
Man hatte von vornherein ein formales Modell.

18:57.450 --> 18:59.510
Man konnte alles auch formal absichern.

19:00.510 --> 19:03.290
Ich werde auch später nochmal, wenn es um die Robustheit des Systemes

19:03.290 --> 19:06.630
geht, auch nochmal versuchen, in eine formale Welt hineinzukommen,

19:07.010 --> 19:10.910
weil wir heute als Informatiker gefordert sind, Garantien abzugeben.

19:11.330 --> 19:12.390
Wir unterschreiben ja auch Verträge.

19:13.150 --> 19:15.750
Und da gibt es ein ganz ekelhaftes Gesetz, nämlich das

19:15.750 --> 19:16.810
Produkthaftungsgesetz.

19:17.630 --> 19:20.190
Da haften Sie einfach, wenn Ihr Produkt das Gewünschte nicht leistet.

19:21.110 --> 19:24.450
Sie müssen also sicher sein, dass Sie nur in einem Vertrag Zusagen

19:24.450 --> 19:28.770
machen, über Dinge, von denen Sie sicher sind, dass Sie garantieren

19:28.770 --> 19:28.990
können.

19:30.070 --> 19:32.310
Und da sind solche formalen Modelle für einen Informatiker natürlich

19:32.310 --> 19:32.870
sehr beruhigend.

19:32.970 --> 19:35.590
Da kann er, wenn er Beweise führt, da kann er schon fest, wenn er auch

19:35.590 --> 19:39.550
Fragen der Entscheidbarkeit angeht, dann kann er eben klären, ob er

19:39.550 --> 19:41.730
sich trauen kann, solche Garantien abzugeben oder nicht.

19:43.010 --> 19:46.690
Also in Folge dessen werden wir Satzmengen oder Tuppelmengen

19:46.690 --> 19:50.310
tatsächlich im Sinne von Relationen oder angenähert an mathematische

19:50.310 --> 19:51.250
Relationen betrachten.

19:52.490 --> 19:56.090
So, hier sieht man so ein bisschen mehr nochmal, welche Begriffe ich

19:56.090 --> 19:56.890
verwenden werde.

19:57.350 --> 20:00.350
Also das Tuppel ist eben jetzt unser Satz.

20:01.170 --> 20:04.350
Die einzelnen Komponenten, also das, was mit atomarer Typ hier

20:04.350 --> 20:06.490
umschrieben ist, das nennen wir die Tuppelkomponente.

20:07.050 --> 20:11.190
Den Selektor, den wir eingeführt haben, der wird in der Terminologie

20:11.190 --> 20:13.970
des relationalen Datenmodells als Attribut bezeichnet.

20:14.410 --> 20:17.850
Also wir können sagen, das hier ist jetzt das Attribut.

20:19.890 --> 20:22.250
Das hier ist unsere Tuppelkomponente.

20:22.990 --> 20:24.210
Das hier ist unser Tuppel.

20:25.270 --> 20:29.050
Und wir sagen übrigens auch nicht mehr atomarer Typ, sondern wir sagen

20:29.050 --> 20:33.470
der Wertebereich, aus dem die Komponenten eines solchen Attributs

20:33.470 --> 20:36.850
stammen, ist dann die Domäne.

20:37.310 --> 20:41.610
Also das, was wir hier hinschreiben, als atomaren Typ, das wird dann

20:41.610 --> 20:45.170
in der relationalen Terminologie als Domäne bezeichnet.

20:46.710 --> 20:48.050
Oder Domain werden.

20:49.570 --> 20:52.950
So, und die Relation ist, und jetzt kommt ein entscheidender Punkt,

20:53.710 --> 20:57.550
die Relation ist eine Menge im mathematischen Sinn.

20:59.330 --> 21:02.090
Das wird uns an einigen Stellen sogar Probleme bereiten, auf der

21:02.090 --> 21:04.370
anderen Seite auch einige reife Vorteile bieten.

21:04.770 --> 21:07.650
Wir halten zunächst mal fest, dass wir immerhin an dieser Stelle schon

21:07.650 --> 21:11.070
so formal sind, dass wir sagen, um uns abstützen zu können später auf

21:11.070 --> 21:15.250
Ergebnisse, die wir uns auch irgendwo aus der linearen Algebra holen

21:15.250 --> 21:20.270
können, definieren wir uns die Menge zunächst mal als eine Menge im

21:20.270 --> 21:20.950
mathematischen Sinn.

21:21.070 --> 21:25.170
So ein paar Eigenheiten, die stärker die Semantik noch ausdrücken, wie

21:25.170 --> 21:29.910
zum Beispiel das Wissen, dass jedes Tuppel gleich aufgebaut ist,

21:30.350 --> 21:33.770
jeweils über die gleichen Attribute verfügt und auch, dass die

21:33.770 --> 21:35.610
Tuppelkomponenten immer aus den gleichen Domänen stammen.

21:35.950 --> 21:37.850
Da haben wir ein bisschen mehr Information als die, die man

21:37.850 --> 21:40.570
üblicherweise hat, falls man die Stelligkeit kennt.

21:41.510 --> 21:44.330
Stelligkeit ist natürlich auch an diesen Stellen fest vorgegeben, das

21:44.330 --> 21:50.330
heißt, die Menge ist der Element, die Tuppel innerhalb der Relation

21:50.330 --> 21:53.070
haben alle gleiche Stelligkeit und, wie gesagt, stimmen auch in den

21:53.910 --> 21:54.810
Attributdomänenpaaren überein.

21:56.430 --> 21:59.890
So, das ist eigentlich schon alles, was wir wissen müssen.

22:01.610 --> 22:05.970
Die Konsequenzen, die stehen hier, die Konsequenzen sind also, dass

22:05.970 --> 22:10.390
wir duplikatfrei sind, das ist ja Eigenschaft einer Menge, wird später

22:10.390 --> 22:13.310
sehen, bei der Objektorientierung sind wir nicht so starr, da lassen

22:13.310 --> 22:14.250
wir auch Multimengen zu.

22:15.670 --> 22:20.610
Sie sind ungeordnet, ein sehr wichtiger Punkt, wir prägen also nicht

22:20.610 --> 22:23.410
einmal zusätzlich eine Ordnung auf, sondern so, wie die Definition

22:23.410 --> 22:24.430
ist, ist das einfach eine Menge.

22:24.530 --> 22:27.410
Und eine Menge ist zunächst mal per sich ungeordnet.

22:27.410 --> 22:29.670
Allerdings, eins wissen wir, sie ist endlich.

22:31.510 --> 22:34.010
Das ist schon mal beruhigend, was die Entscheidbarkeit angeht.

22:35.070 --> 22:37.770
Hilft zwar von der Rechnungskomplexität nicht weiter, aber wenigstens

22:37.770 --> 22:38.650
von der Entscheidbarkeit.

22:39.430 --> 22:44.630
Und wir sagen, im Übrigen, wenn unsere Attribute als atomare Domänen

22:44.630 --> 22:48.730
haben, oder atomare Typen als Domänen, dann sagen wir, diese Relation

22:48.730 --> 22:50.750
ist in der sogenannten ersten Normalform.

22:51.610 --> 22:53.110
Auf die werden wir später auch wieder stoßen.

22:54.170 --> 22:57.370
Und wenn man sagt, es gibt hier eine erste Normalform, dann gibt es

22:57.370 --> 22:59.990
offensichtlich auch mal Situationen, da kann man das Modell etwas

22:59.990 --> 23:03.890
abändern, sodass es nicht mehr eine erste Normalform ist, nämlich bei

23:03.890 --> 23:06.150
dem die Domänen beispielsweise dann nicht mehr atomar sind.

23:06.450 --> 23:09.910
Wir werden ausschließlich den Fall betrachten der ersten Normalform,

23:10.050 --> 23:11.090
also atomare Domänen.

23:12.170 --> 23:14.470
Und wenn man das hat, dann gibt es noch eine Veranschaulichung.

23:14.570 --> 23:18.030
Und man muss sagen, wenn man ganz genau hinschaut, es ist absolut

23:18.030 --> 23:22.050
frustrierend, nicht etwa die mathematische Eleganz des Modells war für

23:22.050 --> 23:24.650
den Siegeszug verantwortlich, sondern a, dass man gute

23:25.610 --> 23:28.630
Implementierungstechniken gefunden hat und b, dass es eine ganz

23:28.630 --> 23:32.490
einfache anschauliche Form gibt, mit der man die Ergebnisse auf dem

23:32.490 --> 23:35.750
Bildschirm, damals waren die alle nur alphanumerische Bildschirme, auf

23:35.750 --> 23:38.670
denen man die präsentieren kann, nämlich in Tabellenform.

23:40.810 --> 23:45.890
Unser Flugzeugtyp Relation oder bisher war es ja noch eine Menge,

23:46.110 --> 23:50.410
jetzt können wir ja sagen, es ist eine Relation, die nimmt also ganz

23:50.410 --> 23:51.730
einfach Tabellenform an.

23:51.950 --> 23:54.870
Wir schreiben die Attribute, die bei allen übereinstimmen, bei allen

23:54.870 --> 24:01.350
Tuppeln, die schreiben wir oben sozusagen als eine Art Kopfleiste an

24:02.330 --> 24:05.770
und dann stehen da unten alle die Komponenten, also das hier ist ein

24:05.770 --> 24:10.050
Tuppel und das ist eine Tuppelkomponente.

24:14.310 --> 24:17.570
Und wenn wir jetzt mal annehmen, dass wir zwar in der Datenbasis

24:17.570 --> 24:20.310
selbst gigantische Relationen haben mit Millionen von Tuppeln

24:20.310 --> 24:23.430
gelegentlich, aber das, was wir uns anzeigen lassen wollen, meistens

24:23.430 --> 24:27.770
nur eine ganz kleine Relation ist mit ganz wenig Tuppeln, dann kann

24:27.770 --> 24:30.910
man sich schon vorstellen, dass man heute auf dem hochauflösenden

24:30.910 --> 24:35.370
Bildschirm sehr bequem so eine Tabelle anzeigen lassen kann, sogar auf

24:35.370 --> 24:38.250
einem Wapp-Handy kann man das noch, wenn auch nicht mehr ganz elegant,

24:38.670 --> 24:40.030
noch bequem unterbringen.

24:40.950 --> 24:44.730
Also die Tatsache, dass wir eine ganz einfache Veranschaulichung

24:44.730 --> 24:47.970
haben, die hilft uns enorm weiter und ist auch dafür verantwortlich,

24:47.990 --> 24:50.750
warum das relationale Modell auch gar nicht vorzukriegen ist, selbst

24:50.750 --> 24:53.150
wenn es auf viele Anwendungen gar nicht mehr so sonderlich gut

24:54.010 --> 24:54.670
zutreffen würde.

24:56.950 --> 24:59.150
So, dann hat man gesagt, wir müssen noch etwas weiteres tun.

24:59.510 --> 25:03.270
Wir stopfen auch in das Datenmodell gleich die Konsistenzbedingungen

25:03.270 --> 25:06.710
rein, die wir Polymorph vorhalten, von denen wir also sagen, das

25:06.710 --> 25:10.050
Datenbanksystem muss, wenn es jetzt die Dienstschnittstelle umsetzt,

25:10.130 --> 25:12.890
dann muss es auch gleichzeitig dafür Sorge tragen, dass diese

25:12.890 --> 25:14.970
Konsistenzbedingungen eingehalten werden.

25:15.230 --> 25:17.510
Ich formuliere jetzt mal Polymorph und wenn ich dann zum Schema

25:17.510 --> 25:21.250
übergehe, dann wäre natürlich an die Stelle der Typvariablen

25:21.250 --> 25:22.670
spezifische Typen gesetzt.

25:23.310 --> 25:26.050
Und es gibt im Wesentlichen zwei Bedingungen, die wir auch schon

25:26.050 --> 25:27.270
früher kennengelernt haben.

25:28.970 --> 25:34.750
Nämlich einmal wollen wir die eindeutige Erkennung eines Tuples

25:34.750 --> 25:38.630
innerhalb einer Relation aufgrund seines Inhalts und zwar bestimmter

25:38.630 --> 25:40.630
inhaltlicher Komponenten festlegen.

25:40.730 --> 25:43.650
Wir haben ja gesagt, bei den riesigen Zahlen, die wir haben an Tuplen

25:43.650 --> 25:47.510
in der Datenbasis, können wir keine Identifikatoren, die nichtssagend

25:47.510 --> 25:51.510
sind, mitführen, sondern wir brauchen in der Anwendung aussagekräftige

25:52.310 --> 25:53.730
Werte und das durch Schlüssel.

25:54.030 --> 25:55.490
Das hat man schon mal als solchen bezeichnet.

25:56.010 --> 26:01.090
Wir führen also einmal eine Schlüsselbedingung ein, die ist jetzt hier

26:01.090 --> 26:04.290
ein klein bisschen komplizierter formuliert, weil es ja folgendes

26:04.290 --> 26:08.690
herausläuft, wir wollen im Grunde genommen sagen, wenn wir die

26:08.690 --> 26:14.270
Relation gegeben haben, welche Attribute unter welchen Attributen die

26:14.270 --> 26:17.730
identifizierenden Komponenten, also die Schlüsselkomponenten liegen.

26:18.050 --> 26:21.370
Und wir müssen zulassen, dass manchmal nicht ein einziges Attribut

26:21.370 --> 26:23.650
ausreicht, sondern dass wir eine Kombination von Attributen nehmen

26:23.650 --> 26:25.770
müssen, um diese Eindeutigkeit zu erhalten.

26:25.950 --> 26:29.570
Wir haben auch ein Beispiel, da sehen, dass das gelegentlich nicht zu

26:29.570 --> 26:30.310
vermeiden ist.

26:31.210 --> 26:34.610
Also wir sagen infolgedessen, den Schlüssel identifizieren wir, indem

26:34.610 --> 26:39.730
wir Selektoren nennen, aus diesen Selektoren gewinnen wir, die wir als

26:39.730 --> 26:43.610
Schlüssel der Relation anbezeichnen, oder Schlüsselattribute oder

26:43.610 --> 26:45.270
Schlüssel der Relation.

26:46.470 --> 26:50.930
Aus denen gewinnen wir, oder unter deren Angabe verwenden wir, um dann

26:50.930 --> 26:53.770
darunter nachzusehen und zu sehen, welche Werte stehen im einzelnen

26:53.770 --> 26:54.070
Tuppel.

26:54.110 --> 26:58.150
Und dann ist das dann der Wert, der jetzt als Schlüssel des Tuppels

26:58.150 --> 27:00.650
gilt, der nämlich das Schlüssel selbst identifiziert.

27:01.150 --> 27:04.050
Also wenn wir das dann nehmen, dann kommen wir hier zum Schlüssel

27:04.050 --> 27:05.230
dieses Attributs.

27:05.890 --> 27:10.250
Und damit ist, und mit diesem Schlüssel und den Werten identifizieren,

27:10.410 --> 27:12.970
können wir dann das Tuppel eindeutig identifizieren.

27:13.710 --> 27:16.090
Und wir verlangen sogar noch, wir sind noch viel härter, wir

27:16.090 --> 27:22.210
verlangen, dass es immer in einer Relation einen Schlüssel gibt.

27:22.790 --> 27:26.390
Also dass wir immer in der Lage sind, aufgrund von Inhalten einen

27:27.510 --> 27:29.210
Tuppel eindeutig zu identifizieren.

27:30.570 --> 27:32.710
Was passiert denn, wenn ich Ihnen keinen Schlüssel angebe?

27:33.850 --> 27:35.290
Haben wir dann einen Schlüssel, oder nicht?

27:37.530 --> 27:38.310
Also die Meinung.

27:40.330 --> 27:42.270
Wahrscheinlich würde man im Schema ja hinschreiben, Schlüssel ist das

27:42.270 --> 27:44.830
und das und ist angenommen, ich schreibe da nichts hin.

27:45.390 --> 27:46.570
Gibt es denn einen Schlüssel, oder nicht?

27:47.830 --> 27:48.450
Was meinen Sie?

27:48.810 --> 27:49.430
Gibt es einen, oder nicht?

27:51.550 --> 27:52.510
Ah, haben Sie keine Antwort?

27:54.010 --> 27:55.010
Ist doch leicht zu überlegen.

27:56.110 --> 27:59.530
Also zunächst mal haben Sie eine 50% Chance, ja oder nein.

27:59.670 --> 28:00.150
Ja oder nein?

28:01.990 --> 28:03.990
So ist es, wir wissen doch, dass der eindeutig ist.

28:03.990 --> 28:08.730
Also, nehmen wir einfach alle Komponenten, ist manchmal nichts zu

28:08.730 --> 28:09.050
vermeiden.

28:09.410 --> 28:13.890
Wir geben also tatsächlich Schlüssel an, dass alle das ganze Tuppel

28:13.890 --> 28:14.170
abdecken.

28:16.190 --> 28:16.370
Bitte?

28:16.530 --> 28:16.950
Ich habe nicht verstanden.

28:19.150 --> 28:22.310
Ah, weil ich die Eindeutigkeit im Modell drin habe.

28:23.830 --> 28:24.970
Das ist die Voraussetzung.

28:25.070 --> 28:28.250
Wir haben gesagt, es gibt keine Duplikate, es ist Duplikat frei und

28:28.250 --> 28:29.130
damit habe ich das.

28:29.970 --> 28:33.390
Also man sieht schon, das Datenmodell spielt eine Rolle an der Stelle.

28:33.730 --> 28:36.370
Ohne diese Bedingungen, hätte ich die Eindeutigkeit nicht gegeben.

28:37.230 --> 28:39.250
Das heißt, rücke ich davon ab, habe ich sofort ein Problem, was die

28:39.250 --> 28:39.910
Schlüssel angeht.

28:44.430 --> 28:48.690
So, und jetzt kann man sich nicht vorstellen, das hat gesagt, also

28:48.690 --> 28:52.190
unter diesen Komponenten dürfen keine zwei Tuppel mit identischen

28:52.190 --> 28:52.930
Werten vorkommen.

28:54.530 --> 28:56.550
Und dann müssen wir eben sagen, unsere Operatoren, wir haben ja

28:56.550 --> 28:58.690
gesagt, Polymer für Operatoren sorgen schon dafür, dass die

28:58.690 --> 29:01.350
Konsistenzbedingungen eingehalten werden und wir sagen mal halt, wenn

29:01.350 --> 29:04.310
geändert wird, lieber Operator, pass höllisch auf, dass dir da nicht

29:04.310 --> 29:07.330
plötzlich zwei identische Werte reingeraten, in die Relation.

29:11.180 --> 29:13.960
Die zweite Konsistenzbedingung, die wir auch schon mal verwendet

29:13.960 --> 29:18.560
haben, die hing damit zusammen, dass wir gesagt haben, eigentlich gibt

29:18.560 --> 29:22.620
es ja gewisse Zusammenhänge auch zwischen unterschiedlichen Mengen.

29:23.500 --> 29:24.800
Und die muss es sogar geben.

29:25.500 --> 29:29.140
Denn wenn wir jede Relation für sich allein hätten und wir könnten

29:29.140 --> 29:32.600
überhaupt nichts über Zusammenhänge zwischen diesen Relationen

29:33.220 --> 29:36.680
aussagen, dann hätten wir lauter isolierte Teile in der Datenbasis

29:36.680 --> 29:40.100
liegen und wir hätten nie eine Chance irgendwie gemeinsame Teile

29:40.100 --> 29:42.360
zusammen zu suchen und zu finden.

29:43.160 --> 29:45.820
Wir müssten darauf achten, dass wir möglichst weit alles in eine

29:45.820 --> 29:47.260
riesige Relation reinpacken.

29:48.400 --> 29:50.980
Was wir aber wollen, ist eigentlich, dass wir möglichst kleine

29:50.980 --> 29:53.760
Einheiten haben, die auch viel leichter zu verwalten sind, viel

29:53.760 --> 29:55.660
leichter aufrechtzuerhalten zu pflegen sind.

29:56.380 --> 29:59.700
Und dann müssen wir irgendwie in der Lage sein, Teile auch mal

29:59.700 --> 30:00.500
zusammen zu bringen.

30:00.500 --> 30:04.120
Und insbesondere gibt es gewisse Gesetzmäßigkeiten, da müssen wir

30:04.120 --> 30:07.560
sagen, dieser Zusammenhang existiert in dieser Datenbasis zwischen

30:07.560 --> 30:09.680
tuppel unterschiedlicher Relationen.

30:10.280 --> 30:14.340
Erinnern Sie sich, ich hatte mal, wir hatten Flughäfen aufgestellt und

30:14.340 --> 30:17.500
wir hatten Flüge und da gab es irgend so ein Attribut, dass ein Flug

30:17.500 --> 30:22.040
von einem Flughafen zum anderen geht und da gab es zwei Selektoren,

30:22.180 --> 30:22.820
von und nach.

30:23.660 --> 30:27.500
Und da hat man gesagt, davon darf ich nur etwas eintragen, was ein

30:27.500 --> 30:28.580
existierender Flughafen ist.

30:28.580 --> 30:29.640
Also ein Flughafen-Kürzel.

30:30.040 --> 30:33.320
Und da sehen wir schon, es gibt einen Zusammenhang zwischen Tuppeln in

30:33.320 --> 30:40.520
der Relation Flüge und Tuppeln in einer zweiten Relation Flughäfen.

30:41.400 --> 30:42.760
Und die können wir nicht ausnutzen.

30:42.880 --> 30:45.280
Aber zunächst mal müssen wir erst mal sicherstellen, dass dieser

30:45.280 --> 30:48.060
Zusammenhang tatsächlich gewährleistet bleibt.

30:48.560 --> 30:52.580
Und das ist die sogenannte referenzielle Konsistenz.

30:54.020 --> 30:56.620
Die ist zunächst mal sogar sehr allgemein.

30:56.620 --> 31:03.520
Die besagt nämlich, dass ich angebe, angeben kann, als eine

31:03.520 --> 31:09.100
Konsistenzbedingung, dass eine Wertemenge unter einer wiederum einer

31:09.100 --> 31:14.580
Kombination von Attributen in einer Relation eine Teilmenge ist, also

31:14.580 --> 31:21.600
existieren muss, in einer zweiten Relation unter einer zweiten Menge

31:21.600 --> 31:23.280
von Attributen in dieser Relation.

31:24.020 --> 31:28.680
Das heißt, also ich konstruiere, ich nehme mir sozusagen, hole mir die

31:28.680 --> 31:32.040
Spalten raus, die jeweils unter den Schlüsseln liegen oder diesen

31:32.040 --> 31:35.160
genannten Attributen liegen und sage einfach, ich bilde mal die Menge

31:35.160 --> 31:39.720
der Werte, die ich in der einen Relation finde, bilde die Menge der

31:39.720 --> 31:42.600
Werte, die ich in der zweiten Relation finde und die erste Menge muss

31:42.600 --> 31:43.700
Teilmenge der zweiten sein.

31:45.460 --> 31:49.900
Und das kann man jetzt noch etwas spezifischer machen, indem man sagt,

31:50.600 --> 31:55.460
dass ich setze hier voraus, dass es bei der zweiten Relation sich um

31:55.460 --> 32:00.580
Schlüssel handelt, dann nehme ich so, wie ich das jetzt bei von und

32:00.580 --> 32:06.240
nach bezüglich der Flughafenkürzel betrachte, dann spreche ich davon,

32:06.480 --> 32:09.920
dass in der zweiten Relation diese Teilmenge aus Schlüsseln dieser

32:09.920 --> 32:13.060
Relation gebildet wird und wenn das der Fall ist, dann spreche ich von

32:13.060 --> 32:13.740
Fremdschlüsseln.

32:14.180 --> 32:18.400
Und diese Fremdschlüssel spielen, wie wir später sehen werden, eine

32:18.400 --> 32:23.860
ausgesprochen große Rolle, nicht nur bei der Verwendung der Relation,

32:24.040 --> 32:27.080
sondern noch viel stärker, wenn es darum geht, zunächst einmal auch

32:27.080 --> 32:30.060
Entwurf zu treiben, das heißt überhaupt mal zu sagen, wie mache ich

32:30.060 --> 32:32.620
eigentlich mein Spagat, von dem ich auch mal früher gesprochen hatte,

32:32.880 --> 32:37.680
von der Anwendungswelt in die Modellwelt, wie sie durch Relation

32:37.680 --> 32:38.380
gegeben ist.

32:38.800 --> 32:41.440
Also wir behalten mal im Kopf, dass wir Fremdschlüssel haben, wir

32:41.440 --> 32:43.360
werden es nachher auch ansehen, wo diese existieren.

32:45.360 --> 32:47.920
Sie kommen ja viel stärker aus der Objektorientierung.

32:48.680 --> 32:52.560
Man kann also folgendes sagen, wenn ein Fremdschlüssel vorliegt, dann

32:52.560 --> 32:57.180
haben wir eigentlich nichts anderes als einen Verweis auf Tuppel einer

32:57.180 --> 32:58.060
zweiten Relation.

32:58.760 --> 33:01.860
Denn der Schlüssel identifiziert ja in dieser zweiten Relation das

33:01.860 --> 33:04.180
Tuppel eindeutig, also haben wir nichts anderes als einen Verweis.

33:04.560 --> 33:07.080
Nur, dass wir kein Objektidentifikator oder etwas Künstliches

33:07.080 --> 33:10.320
schaffen, was wir noch nicht mal zu sehen kriegen, sondern, dass wir

33:10.320 --> 33:13.440
unsere Verweise alle inhaltlicher Natur sind.

33:15.060 --> 33:18.300
Und inhaltlicher Natur heißt, dass wir am Schluss immer irgendwie

33:18.300 --> 33:19.720
associativ arbeiten müssen.

33:19.840 --> 33:22.680
Also immer Inhalte nutzen, um irgendetwas zu erfinden.

33:24.900 --> 33:28.080
Das ist auch wieder typisch für den Datenbankbereich, bei dem wir eben

33:28.080 --> 33:30.960
sagen, wir können praktisch nur aus den Inhalten, die durch die

33:30.960 --> 33:34.560
Anwendung gegeben sind, rückschließen auf das, was wir dann an

33:34.560 --> 33:37.640
Forderungen und an Funktionalität von dem Datenbanksystem haben

33:37.640 --> 33:37.880
wollen.

33:39.680 --> 33:41.980
So, jetzt können wir auch sagen, wie komme ich zu einem Schema?

33:42.120 --> 33:43.300
Wir brauchen ja immer ein Beispiel.

33:43.820 --> 33:46.380
Und wir nehmen unser Platzbuchungsbeispiel für den Zweck her.

33:47.120 --> 33:50.700
Und wir sehen also, was wir hier gemacht haben, ist wir sagen zunächst

33:50.700 --> 33:52.500
einmal, wir definieren unsere Tuppeltypen.

33:52.640 --> 33:54.020
Hier ist ein Tuppeltyp.

33:54.720 --> 33:56.080
Den nennen wir Flugzeugtyp.

33:56.480 --> 33:57.760
Und jetzt füllen wir ihn aus.

33:58.320 --> 34:03.800
Dieser Flugzeugtyp, der hat hier zunächst einmal sein Kürzel für den

34:03.800 --> 34:04.100
Typ.

34:04.380 --> 34:07.800
Dann geben wir aber auch noch einen vollen Namen diesem Typ.

34:09.080 --> 34:13.700
Dann gehen wir an, wie viele Plätze gibt es in der ersten Klasse, wie

34:13.700 --> 34:15.920
viele gibt es in der Business Class und wie viele gibt es in der

34:15.920 --> 34:16.280
Economy.

34:18.120 --> 34:21.520
Und dann müssen wir doch weiterhin sagen, wir definieren unsere

34:21.520 --> 34:22.260
Relation.

34:22.620 --> 34:26.200
Die Relation, die nennen wir jetzt auch Flugzeugtyp.

34:26.320 --> 34:28.360
Da ist noch ein Trick dahinter, wie Sie sehen.

34:28.680 --> 34:32.360
Die benenne ich nämlich im Augenblick gleich, wie der Tuppeltyp auch.

34:32.960 --> 34:35.140
Man kann ja wissen, dass es ein Relationstyp ist an der Stelle.

34:36.200 --> 34:40.360
Besteht aus Tuppeln des Typs Flugzeugtyp.

34:41.460 --> 34:43.000
Und jetzt sagen wir auch gleich, was der Schlüssel ist.

34:43.160 --> 34:50.720
Nämlich wir sagen, für uns ist der Schlüssel dieser Dreizeit, dieser

34:50.720 --> 34:53.340
Kurzcode für den Flugzeugtyp.

34:53.620 --> 34:54.520
Das ist der Schlüssel.

34:56.240 --> 34:58.860
Den Schlüssel kriegen wir am besten aus der Anwendung.

34:59.000 --> 35:01.780
Nicht etwa, indem wir jetzt als Informatiker rangehen, was hat er denn

35:01.780 --> 35:06.720
definiert und dann entscheiden wir von uns aus technisch, was der

35:06.720 --> 35:09.600
Schlüssel sein wird, sondern wir fragen den Anwender und sagen, wo

35:09.600 --> 35:13.560
durchzeichnet sich denn dein Tuppel oder deine Objekte in der realen

35:13.560 --> 35:14.460
Welt aus?

35:14.920 --> 35:16.480
Oder was ist das eindeutige Kriterium?

35:16.540 --> 35:18.480
Da sagt er, gut, der Kürzel für den Flugzeugtyp.

35:18.620 --> 35:19.480
Dann machen wir das zum Schlüssel.

35:22.280 --> 35:25.620
Wir werden jetzt folgendes tun, deshalb habe ich auch die Namensgebung

35:25.620 --> 35:26.960
schon gleich gewählt.

35:27.320 --> 35:31.280
Wir fassen den Relationstyp und den Tuppeltyp zu einer einzigen

35:31.280 --> 35:32.280
Vereinbarung zusammen.

35:32.280 --> 35:33.320
Das ist gängig.

35:34.280 --> 35:37.200
Macht es also bequemer, denn wir haben sowieso kaum was dazugewonnen,

35:37.480 --> 35:40.420
indem wir den Relationstyp hier getrennt aufgeführt haben.

35:41.420 --> 35:44.180
Und ich werde außerdem noch folgendes machen, statt dieser Key-Klausel

35:44.180 --> 35:47.540
werde ich mir das Leben etwas einfacher machen, indem ich die

35:47.540 --> 35:49.080
Schlüssel einfach unterstreiche.

35:53.610 --> 35:56.610
So, jetzt führen wir an unserer Anwendungswelt ein.

35:57.050 --> 36:00.930
Wir werden relativ viele Relationen einführen müssen, die sind aber

36:00.930 --> 36:03.770
alle mit sehr wenig Tuppeln ausgestattet, denn ich muss ja ständig

36:03.770 --> 36:07.170
hier auf dieser kleinen Leinwand Ihnen das Ganze vorführen können und

36:07.170 --> 36:10.710
da haben leider besonders viele Tuppel keinen Platz oder Sie können es

36:10.710 --> 36:11.450
nicht mehr lesen von hinten.

36:12.070 --> 36:15.690
Also nehmen wir sehr einfache Beispiele, sehr einfache Auszüge, aber

36:15.690 --> 36:18.970
wir brauchen doch relativ viele Relationen.

36:20.170 --> 36:23.490
Und zwar werden wir im Wesentlichen jetzt folgen, wir werden uns also

36:23.490 --> 36:26.850
auf die Platzbuchung konzentrieren, wir brauchen dazu, wie wir gesehen

36:26.850 --> 36:29.850
haben, die Flugzeugtypen und ihre Sitzkapazitäten, haben wir gerade

36:29.850 --> 36:30.730
schon ein Beispiel gehabt.

36:31.330 --> 36:33.910
Dann wollen wir die Flughäfen haben, weil wir über die auch ein paar

36:33.910 --> 36:35.010
Informationen führen müssen.

36:35.710 --> 36:38.530
Dann brauchen wir die Flüge, denn auf denen wird gebucht oder für die

36:38.530 --> 36:39.190
wird gebucht.

36:39.730 --> 36:42.510
Dann brauchen wir Kunden, denn das sind diejenigen, die immerhin

36:42.510 --> 36:44.610
buchen müssen und von denen wollen wir möglichst viele anziehen.

36:45.690 --> 36:48.370
Dann gibt es Passagiere, das sind nämlich die, die wir inzwischen

36:48.370 --> 36:49.130
gebucht haben.

36:49.550 --> 36:52.330
Wir wollen ja eine Kundendatei haben, eine Kundendatei, die viel mehr

36:52.330 --> 36:54.450
als die, die gerade fliegen, beinhaltet.

36:55.010 --> 36:57.570
Und wir wollen schließlich die Buchungen selbst vermerken.

36:58.170 --> 37:01.790
Jetzt dürfen Sie mich nicht fragen, warum ich gerade so aufgegliedert

37:01.790 --> 37:04.730
habe meine Anwendungswelt.

37:05.450 --> 37:08.690
Das klingt, sieht zwar plausibel aus, aber in gewisser Weise müssen

37:08.690 --> 37:11.210
wir einfach mal glauben, dass es eine ganz passable Aufteilung ist

37:11.210 --> 37:12.890
unserer Anwendungswelt.

37:13.790 --> 37:16.610
Und wir werden aber später natürlich doch die kritische Frage stellen,

37:16.730 --> 37:18.330
war das wirklich so gut, was ich da gemacht habe?

37:18.770 --> 37:21.190
Oder sollte man etwas kritischer rangehen und eine etwas andere

37:21.190 --> 37:23.250
Aufteilung unserer Anwendungswelt schaffen?

37:23.730 --> 37:27.310
Aber jetzt stellen wir mal, das wäre eine einigermaßen vernünftige und

37:27.310 --> 37:28.610
plausible Unterteilung.

37:29.170 --> 37:31.710
Dann müssen wir das alles nur jetzt in Relationen verwandeln.

37:33.690 --> 37:34.950
Hier ist die erste Relation.

37:35.130 --> 37:35.750
Die kennen wir jetzt schon.

37:36.870 --> 37:39.170
Flugzeugtyp, jetzt sehen Sie die Schreibweise ein bisschen anders und

37:39.170 --> 37:40.610
übersichtlicher gewählt.

37:42.230 --> 37:46.190
Flugzeugtyp enthält jetzt sowohl die Relation, den Relationstyp als

37:46.190 --> 37:47.370
auch den Tuple-Typ.

37:47.790 --> 37:51.370
Und wir sehen eben, dass wir jetzt F-Typ dastehen haben, mit F-Typ

37:51.370 --> 37:55.090
-Idee wie zuvor, haben nichts unterstrichen, also unter Schlüssel und

37:55.090 --> 37:57.410
haben dann ein weiteres Attribut, das ich auch vorhin schon aufgezählt

37:57.410 --> 38:03.030
habe, nämlich den Namen des Flugzeugs und dann eben die Aufteilung der

38:03.030 --> 38:04.230
Sitzplätze auf die drei Klassen.

38:05.470 --> 38:07.130
Und Sie sehen auch gerade hier mal ein Beispiel.

38:07.790 --> 38:11.830
Wir könnten also die Boeing 737 hatten vor die volle Bezeichnung eben

38:11.830 --> 38:15.110
Boeing 737, meistens hat es sogar noch mehr, nämlich noch irgendeine

38:15.110 --> 38:18.130
200, 300 dahinter stehen, die etwas aussagt.

38:18.630 --> 38:20.910
Ich weiß gar nicht, was das eigentlich im Einzelnen aussagt.

38:20.910 --> 38:24.470
Irgendwie mit der Sitzplatzkapazität, der Länge oder sowas hat das zu

38:24.470 --> 38:24.730
tun.

38:25.790 --> 38:29.590
Und wir haben weiterhin den Abkürzel, nämlich 737.

38:31.730 --> 38:36.810
Jede Ähnlichkeit mit einem externen Flugzeug, typisch übrigens, rein

38:36.810 --> 38:37.350
zufällig.

38:40.050 --> 38:44.830
So, und da ist noch mal unsere Relation und da sehen Sie eben, dass

38:44.830 --> 38:48.030
wir hier Abkürzungen, das sind übrigens Abkürzungen, die, glaube ich,

38:48.030 --> 38:49.030
die Lufthansa verwendet.

38:50.830 --> 38:56.710
Die also 747 fliegt und die entsprechend unterschiedlich bezeichnet.

38:56.910 --> 39:00.710
Dann haben wir hier Namen, manche sind zwar extrem lang, aber auch für

39:00.710 --> 39:03.370
die Identifikation wollen wir fest mit drei Zeichen arbeiten.

39:04.330 --> 39:05.230
So, die kennen wir ja schon.

39:06.810 --> 39:08.190
Jetzt kommen die Flughäfen dran.

39:09.450 --> 39:11.750
Bei den Flughäfen, das hat man auch schon mal gesehen, ich hatte mal

39:11.750 --> 39:14.830
am Anfang das Beispiel schon gebracht, da arbeiten wir auch mit

39:14.830 --> 39:15.270
Kürzeln.

39:16.390 --> 39:20.990
Und diese Kürzeln, diese Kürzeln bestehen auch aus drei Zeichen und

39:20.990 --> 39:23.030
sind also weltweit eindeutig.

39:25.610 --> 39:33.690
Manche sind sehr eigenartig und andere sind, kann man sofort

39:33.690 --> 39:36.090
entnehmen, den Ort.

39:37.990 --> 39:41.690
Bei Frankfurt ist es ziemlich einfach, FRA steht also als Kürzel für

39:41.690 --> 39:42.170
Frankfurt.

39:42.590 --> 39:44.550
Na, dann gehen wir an, in welcher Stadt er liegt.

39:45.210 --> 39:48.070
Nämlich dann insbesondere, wenn das Kürzel das nicht für Unheitbarkeit

39:48.070 --> 39:48.450
hergibt.

39:48.530 --> 39:49.810
Wir wollen auch das Land wissen.

39:50.690 --> 39:54.250
Vielleicht wegen Visa, Bestimmungen, insbesondere aber auch, weil wir

39:54.250 --> 39:55.950
daraus die Zeitzone entnehmen können.

39:56.930 --> 40:00.770
Wir geben die Zeitzone auch tatsächlich als letztes nochmal an und

40:00.770 --> 40:02.970
dann geben wir auch den Namen des Flughafens, die haben alle sehr

40:02.970 --> 40:03.790
malerische Namen.

40:04.150 --> 40:08.250
Meistens sind sie nach irgendeinem Politiker benannt, der bei der

40:08.250 --> 40:10.410
Einweihung dabei war oder der zumindest mal irgendwann das Geld

40:10.410 --> 40:11.110
beschafft hat.

40:11.710 --> 40:13.170
Zum Teil beschafft hat.

40:16.440 --> 40:18.300
Hier sehen Sie so eine Liste.

40:21.200 --> 40:29.500
Da sieht man zum Beispiel, dass das ist ein Geläufig, aber der von

40:29.500 --> 40:33.380
weit her kommt, der wundert sich immer, dass Berlin TXL hat und nicht

40:33.380 --> 40:36.020
etwa BER oder irgendwas als Kürzel.

40:37.200 --> 40:39.600
Und wenn wir einen langen Namen haben wollen, dann sehen wir zum

40:39.600 --> 40:43.560
Beispiel, der Münchner Flughafen, der von seiner Abkürzung her ja

40:43.560 --> 40:46.740
ziemlich naheliegend ist, der hat einen langen Namen, der ist nämlich

40:46.740 --> 40:52.600
nach jemand benannt, in dessen Amtszeit auf jeden Fall die Akquisition

40:52.600 --> 40:56.880
dieser ganzen Flächen, die da gebraucht wurden und die Planungen

40:57.720 --> 40:58.160
abliefen.

40:58.220 --> 41:00.300
Ich glaube, auch die Fertigstellung war noch in seiner Amtszeit.

41:02.380 --> 41:05.340
Aber wussten Sie zum Beispiel, dass Düsseldorf Rhein-Ruhr heißt?

41:07.240 --> 41:09.720
Und bei Frankfurt bin ich ja nicht ganz sicher, die hießen zumindest

41:09.720 --> 41:14.080
mal Frankfurt Main International, aber die hießen mal Rhein-Main.

41:15.920 --> 41:19.220
Also wir sehen hier einfach eine ganze Aufstellung, was uns vielleicht

41:19.220 --> 41:22.180
besonders interessiert, das Land hat aber auch noch eine Abkürzung

41:22.180 --> 41:24.260
genommen, ist die Zeitzone.

41:25.340 --> 41:29.880
Weil wir ja beachten müssen, zum Beispiel wenn wir von Frankfurt

41:29.880 --> 41:35.480
fliegen, nach New York, dann haben wir 1 und Minus 5.

41:35.480 --> 41:41.300
Und das müssen wir ordentlich addieren, 1 Minus 5 macht 6, 6 Stunden

41:41.300 --> 41:41.880
Flugzeit.

41:42.340 --> 41:46.440
Also 6 Stunden Zeitunterschied, die wir draufzusetzen haben auf den

41:46.440 --> 41:49.540
nominellen Zeitunterschied, den wir noch bei dem Flug selbst

41:49.540 --> 41:50.280
beobachten können.

41:52.480 --> 41:55.020
Ja, dann wollen wir den Flug selbst beschreiben.

41:55.860 --> 41:59.980
Vom Flug den werden wir auch eindeutig identifizieren.

42:00.740 --> 42:02.220
Nämlich durch seine Flugnummer.

42:03.140 --> 42:07.520
Ich hatte schon mal gesagt, als wir vor 10 Jahren die Vorlesung

42:07.520 --> 42:10.120
gehalten haben, war die Flugnummer nicht eindeutig.

42:11.160 --> 42:15.800
Das rührte davon her, dass zu jener Zeit die Fluglinien durchaus mit

42:15.800 --> 42:17.740
Zwischenstopps gearbeitet haben.

42:18.160 --> 42:21.480
Wenn Sie heute nachsehen, keine der größeren Fluglinien hat noch

42:21.480 --> 42:22.460
irgendwann Zwischenstopp.

42:22.660 --> 42:26.980
Die fliegt hin, an den Endort, und wenn sie weiterfliegen wollen, dann

42:26.980 --> 42:27.540
steigt sie halt um.

42:29.540 --> 42:31.920
Was manchmal sehr unangenehm ist, weil sie dann durch etliche

42:31.920 --> 42:36.300
Terminals hasten müssen, um in einem Bus oder Taxi um da rumgekurvt zu

42:36.300 --> 42:36.460
werden.

42:36.540 --> 42:38.540
Und manche haben ja auch etwas elegantere Bahnen, die einen da

42:38.540 --> 42:39.700
rumtransportieren.

42:40.780 --> 42:43.780
Vor 10 Jahren konnten sie noch irgendwo zwischendrin warten, in der

42:43.780 --> 42:45.940
Lounge, und dann wieder das Flugzeug besteigen.

42:46.040 --> 42:46.640
Heute schon nicht mehr.

42:47.640 --> 42:50.500
Also deshalb kommen wir jetzt mit der eindeutigen Flugnummer aus, als

42:50.500 --> 42:51.660
wirklich eindeutiges Kriterium.

42:52.120 --> 42:53.740
Und dann sehen Sie, was wir alles weiterhin haben.

42:53.820 --> 42:56.860
Wir haben den Code des Startflughafens, wir haben den Code des

42:56.860 --> 42:58.000
Zielflughafens.

42:58.520 --> 43:01.300
Dann wollen wir wissen, was da für Flugzeugtyp fliegt denn da.

43:02.760 --> 43:04.800
Das interessiert manche Leute brennend, und für die

43:04.800 --> 43:06.620
Sitzplatzreservierung spielt es ja auch eine Rolle.

43:07.120 --> 43:09.020
Dann wollen wir wissen, fliegt er noch täglich oder nicht.

43:10.060 --> 43:13.680
Dann interessiert uns natürlich, wann ist er denn angesetzt mit dem

43:13.680 --> 43:14.220
Abflug.

43:15.200 --> 43:18.640
Das hat mit der Realität nur in Grenzen was zu tun, aber man muss

43:18.640 --> 43:20.020
zumindest drinsitzen zu der Zeit.

43:21.760 --> 43:24.320
Dann interessiert die geplante Ankunftszeit.

43:24.980 --> 43:27.580
Da muss man sich dann überlegen, schaffst du den Anfluganschluss noch

43:27.580 --> 43:28.060
oder nicht.

43:30.160 --> 43:33.320
Man kennt ja auch seine Flughäfen, bei denen die geplante Ankunftszeit

43:33.320 --> 43:37.720
und die tatsächliche Ankunftszeit eine gewisse Ähnlichkeit haben, und

43:37.720 --> 43:39.580
andere Flughäfen, wo die weit auseinander klaffen.

43:41.960 --> 43:45.260
Und dann interessiert natürlich die Meilensammler auch noch die

43:45.260 --> 43:45.780
Entfernung.

43:46.740 --> 43:48.840
Allerdings nicht in Kilometern, wie hier, sondern in Meilen.

43:50.560 --> 43:53.300
Dann schauen wir uns wieder eine entsprechende an.

43:54.040 --> 43:55.560
Ah, hier ist noch was weiteres.

43:55.680 --> 43:58.260
Zum ersten Mal, wir haben hier referenzielle Konsistenzen

43:58.260 --> 43:59.080
hinzuschreiben.

44:00.060 --> 44:09.440
Wir sagen nämlich jetzt, dass hier von Bezug nimmt auf einen

44:09.440 --> 44:13.160
Flughafen, und zwar soll es auf einen existierenden Flughafen Bezug

44:13.160 --> 44:13.420
nehmen.

44:14.360 --> 44:17.860
Also können wir jedenfalls sagen, dass wir hier eine referenzielle

44:17.860 --> 44:20.580
Konsistenz, oder sogar genauer eine Fremdschlüsselbedingung haben,

44:20.900 --> 44:22.860
nämlich auf den Flughafengrund unseres Flughafens.

44:23.420 --> 44:25.180
Und das gleiche... Entschuldigung, das hätte ich da...

44:27.860 --> 44:30.940
Und nach das gleiche...

44:30.940 --> 44:32.820
Auch da wollen wir auf...

44:32.820 --> 44:35.380
Auch da verlangen wir, dass der Ankunftsflughafen existiert.

44:35.780 --> 44:38.700
Es ist so peinlich, wenn man in der Luft sich befindet und dann erst

44:38.700 --> 44:40.860
feststellt, dass der Flughafen gar nicht existiert, wenn man da

44:40.860 --> 44:41.460
anfliegen will.

44:42.980 --> 44:47.100
Und dann müssen wir natürlich auch wissen, existiert eigentlich der

44:47.100 --> 44:49.640
Flugzeugtyp, der ist ja tatsächlich geführt.

44:49.720 --> 44:52.540
Sonst können wir nicht buchen, weil wir über die Sitzplätze nicht

44:52.540 --> 44:53.100
Bescheid wissen.

44:54.080 --> 44:56.080
Also schreiben wir so ein paar Dinge hin und sagen, das sind die

44:56.080 --> 44:56.660
Voraussetzungen.

44:56.760 --> 45:00.100
Wir können überhaupt diese Flugrelation nur sinnvoll erfüllen, wenn

45:00.100 --> 45:01.960
diese Bedingungen hier erfüllt sind.

45:03.580 --> 45:06.880
Das ist schon ein bisschen dicker, diese Relation.

45:07.360 --> 45:09.460
Da haben wir hier unsere Flugnummer ganz links.

45:09.900 --> 45:15.340
Dann haben wir von nach den Startflughafen und den Zielflughafen.

45:15.340 --> 45:19.200
Also die Lufthansa 400 fliegt von Frankfurt nach New York.

45:19.520 --> 45:21.720
Wie wir sehen, mit der Boeing 47.

45:23.040 --> 45:25.520
Und sie fliegt übrigens, das ist so ein Kürzel, der gibt es heute auch

45:25.520 --> 45:27.580
nicht mehr, aber der war in alten Flugplänen immer noch drin.

45:27.900 --> 45:31.700
Da wurden einfach die Tage aufgezählt, an denen geflogen wurde und mit

45:31.700 --> 45:34.660
einem Strich eingetragen wurde, dann flog der an dem Tag nicht, an dem

45:34.660 --> 45:35.260
Wochentag nicht.

45:35.740 --> 45:39.960
Und da sehen wir also, die Lufthansa 400, die fliegt täglich.

45:40.640 --> 45:45.540
Und sie fliegt um 10.35 Uhr in Frankfurt ab und um 12.45 Uhr kommt sie

45:45.540 --> 45:45.960
dort an.

45:46.040 --> 45:48.400
Und wir haben ja schon ausgerechnet, dass die Zeitdifferenz 6 Stunden

45:48.400 --> 45:48.720
ist.

45:49.160 --> 45:51.420
Also fliegt die so rund 8 Stunden.

45:52.460 --> 45:56.700
Da weiß man dann schon, was man erwartet an dieser Stelle und ob man

45:56.700 --> 45:58.700
bis dahin seinen Kreislaufkollaps hatte oder nicht.

46:00.500 --> 46:03.600
Oder ob man sich ordentlich mit Lesestoff eindecken muss, schlafen

46:03.600 --> 46:05.480
kann man ja um die Tageszeit nicht so gut.

46:05.900 --> 46:08.020
Das ist alles Information, die sich als Kunde interessiert.

46:09.140 --> 46:11.280
Und dann ist die Entfernung da, die müssen wir jetzt noch in Meilen

46:11.280 --> 46:14.540
umrechnen und dann weiß also derjenige, der da drin fliegt, dass er

46:14.540 --> 46:18.140
wieder mal 4000 Meilen hinzufügen darf seinem Konto.

46:20.260 --> 46:22.800
Und so haben wir eine Menge dieser Dinge da.

46:22.900 --> 46:27.580
Zum Beispiel hier sehen wir immerhin, dass dieser Flug hier der von

46:27.580 --> 46:28.720
Frankfurt nach...

46:28.720 --> 46:32.780
Das war Alexander, ja wunderbar.

46:32.860 --> 46:33.220
Danke sehr.

46:34.020 --> 46:38.180
Der fliegt also, oder flog damals zumindest, nur dienstags, freitags,

46:38.240 --> 46:39.280
samstags und sonntags.

46:42.060 --> 46:43.440
Und so haben wir noch eine ganze Menge drin.

46:43.520 --> 46:47.660
Da haben wir jetzt also transkontinentale oder auch lokale Flüge.

46:49.220 --> 46:53.000
Zwei Airbus haben wir hier auch und auch ein paar 737 haben wir noch

46:53.000 --> 46:53.620
da drin.

46:54.280 --> 46:55.040
Es gibt noch mehr.

46:56.140 --> 46:57.740
Also Sie sehen, hier habe ich eine relativ große Relation.

46:59.560 --> 47:00.620
So, dann haben wir eine weitere.

47:01.660 --> 47:02.900
Jetzt kommen wir zu unseren Kunden dran.

47:03.480 --> 47:05.200
Jetzt kann man sich schon fragen, was müssen wir denn von den Kunden

47:05.200 --> 47:05.560
wissen?

47:05.980 --> 47:08.840
Und von den Kunden brauchen wir eigentlich nur den Namen und die

47:08.840 --> 47:09.620
Telefonnummer.

47:10.420 --> 47:14.640
Wenn wir annehmen, dass heute im Zeitalter elektronischer Buchungen

47:14.640 --> 47:17.800
sowieso kein Papier mehr hin und her transportiert wird, dann reicht

47:17.800 --> 47:18.240
das völlig.

47:18.680 --> 47:20.800
E-Mail-Adresse bräuchte man vielleicht noch stattdessen.

47:23.120 --> 47:29.740
Und hier habe ich auch eine ganze Reihe solcher Kunden dastehen mit

47:29.740 --> 47:32.200
ihren Telefonnummern, die zwar so ein bisschen geraten sind, also

47:32.200 --> 47:35.120
verlassen Sie nicht drauf, wenn Sie es versuchen, uns zu erreichen,

47:35.220 --> 47:35.740
dass die stimmt.

47:37.900 --> 47:41.800
Aber da ist so ziemlich mein Lehrstuhl vertreten, allerdings auch wie

47:41.800 --> 47:44.580
in der Vergangenheit existierte, nicht wie er augenblicklich aussieht.

47:44.960 --> 47:48.500
Bei mir wechseln ja so, das kann man ja ausrechnen, 20% pro Jahr.

47:50.740 --> 47:53.280
So, mit den Kunden werden wir dann hinterher auch arbeiten.

47:58.830 --> 47:59.090
Nee.

48:02.190 --> 48:03.570
Aber hier drin sind sie eindeutig.

48:05.230 --> 48:06.770
So, interessante Frage.

48:08.390 --> 48:11.150
Also ich gebe zu, ich mache mir das Leben hier einfach.

48:11.910 --> 48:14.550
In Wirklichkeit dürfen wir in der Tat nicht unterstellen, dass die

48:14.550 --> 48:15.490
Namen eindeutig sind.

48:16.210 --> 48:19.990
Denn natürlich Müller und Schmidt, die Chancen da eindeutig zu sein,

48:20.390 --> 48:20.990
sind nahe Null.

48:21.590 --> 48:23.930
Da müssten wir dann tatsächlich zum Beispiel die Telefonnummer noch

48:23.930 --> 48:24.270
hinzunehmen.

48:24.370 --> 48:25.990
Wenn wir sonst nichts machen wollen, müssen wir die Telefonnummer

48:25.990 --> 48:26.430
hinzunehmen.

48:26.530 --> 48:28.630
Also der Einwand war völlig gerechtfertigt.

48:29.170 --> 48:31.210
Ich gebe aber zu, ich mache mir hier gelegentlich das Leben etwas

48:31.210 --> 48:34.390
einfacher und Ihnen auch, indem ich an manchen Stellen Eindeutigkeit

48:34.390 --> 48:36.070
unterstelle, die in der Realität nicht gegeben ist.

48:36.270 --> 48:36.270
Ja.

48:40.870 --> 48:41.790
Ja, ja.

48:42.550 --> 48:43.630
Ja, ja, ja.

48:49.030 --> 48:51.610
Zwei Schmidts mit gleichem Namen in der gleichen Wohngemeinschaft.

48:51.850 --> 48:54.730
Also sehr wahrscheinlich, aber auszuschließen ist nicht.

48:55.270 --> 48:56.930
Wenn ich, aber jetzt drehen wir einen Spieß um.

48:57.850 --> 48:59.790
Angenommen, ich sage aber, das ist jetzt eindeutig.

49:00.870 --> 49:03.710
Dann kriegen Sie in dieser Datenbasis, zumindest wenn es so richtig

49:03.710 --> 49:07.470
funktioniert, kriegen Sie den zweiten Schmidt in Ihrer

49:07.470 --> 49:09.950
Wohngemeinschaft, der gleiche Vornamen hat, nicht mehr rein.

49:11.390 --> 49:12.670
Dann dreht sich der Spieß um.

49:12.770 --> 49:15.190
Dann komme ich mit meinem Modell und sage, die Realität hat Sie

49:15.190 --> 49:16.450
gefälligst, an meinem Modell zu halten.

49:17.850 --> 49:19.810
Das ist eine Haltung, die Informatiker würden sehr, sehr gerne

49:19.810 --> 49:20.270
einnehmen.

49:22.650 --> 49:24.110
Und man muss sich das genau überlegen.

49:24.850 --> 49:27.270
Also tatsächlich, normalerweise kriegen die alle Nummern.

49:27.670 --> 49:31.170
Das Problem in der Betriebswirtschaft, in der Anwendung, kriegen die

49:31.170 --> 49:33.750
alle künstlichen Nummern und dann haben sie sowas wie die

49:33.750 --> 49:37.830
Objektorientierung, wenn man will, auch eingeführt, aber hinterrücks,

49:37.890 --> 49:39.770
indem sie mit künstlichen Bezeichnungen arbeiten.

49:40.650 --> 49:42.670
Und auf diese Schlüssel wird auch sehr viel Wert gelegt.

49:43.070 --> 49:45.730
Wenn man die sich genauer ansieht, werden die zusammengesetzt und sind

49:45.730 --> 49:46.810
sogenannte sprechende Schlüssel.

49:48.350 --> 49:51.210
Also ich mache das Universum sehr einfach an dieser Stelle, indem ich

49:51.210 --> 49:52.250
sage, Namen sind eindeutig.

49:53.550 --> 49:56.490
Aber mit der Realität hat das wohl in Grenzen was zu tun.

49:58.130 --> 49:59.590
So, dann brauche ich noch das Ticket.

50:00.790 --> 50:07.290
Und das Ticket besagt halt jetzt, dass ich eine Ticketnummer vergebe.

50:07.950 --> 50:09.470
Das ist das Einzige, was ich wirklich sage.

50:10.190 --> 50:15.850
Und, dass ich außerdem sage, zu welchem Kunden gehört denn dieses

50:15.850 --> 50:16.190
Ticket.

50:16.650 --> 50:21.090
Und wir können auch sagen, kein Problem, denn wir wissen, dass der

50:21.090 --> 50:24.890
Kundenname Schlüssel dort ist und wir haben infolgedessen wieder eine

50:24.890 --> 50:29.390
Fremdschlüsselbedingung von Ticket zu dem Kunden.

50:31.230 --> 50:33.270
Und jetzt fragt man sich natürlich, na gut, da haben wir jetzt

50:33.270 --> 50:35.050
Ticketnummern, ist auch nichts Aufregendes.

50:36.950 --> 50:42.910
Und schließlich haben wir jetzt die Buchung vorzunehmen.

50:42.910 --> 50:46.030
Irgendwo müssen wir ja mal Kunden, Flugzeuge, Flüge, das müssen wir

50:46.030 --> 50:46.930
alles zusammenbringen.

50:47.210 --> 50:51.570
Und das bringen wir zusammen in einer sozusagen Artifiziellen, hat ja

50:51.570 --> 50:54.990
in der realen Welt als anfassbarer Gegenstand nichts zu tun, ist aber

50:54.990 --> 50:57.590
ein gedankliches Konstrukt mit der Buchung.

50:58.410 --> 51:01.170
Und bei der Buchung, sehen Sie, da führe ich tatsächlich jetzt einen

51:01.170 --> 51:02.630
kombinierten Schlüssel ein.

51:02.730 --> 51:07.730
Der hat also zwei Attribute, die gemeinsam den Schlüssel ausmachen.

51:08.030 --> 51:10.050
Nämlich die Flugnummer und die Ticketnummer.

51:11.390 --> 51:13.830
Und da könnte man sogar noch argumentieren, ob das ausreicht.

51:14.310 --> 51:18.070
Ich werde also hier, wenn ich das jetzt als Schlüssel nehme, dann

51:18.070 --> 51:19.370
unterstelle ich folgendes.

51:20.030 --> 51:23.450
Ein Ticket deckt mehr als ein Flug ab.

51:24.070 --> 51:27.310
Sie können ein Ticket lösen und wenn Sie schon mal mehrfach umsteigen

51:27.310 --> 51:31.450
müssen, dann unterstellen wir mal in unserer Welt, in der Welt, die

51:31.450 --> 51:34.690
ich jetzt hier aufbaue, dass Sie mit einem Ticket den ganzen Flug

51:34.690 --> 51:35.050
abdecken.

51:35.650 --> 51:38.810
Also auch möglicherweise, wenn aus mehreren Abschnitten mit Umsteigen

51:38.810 --> 51:39.190
besteht.

51:39.830 --> 51:42.610
Und dann ist euch klar, dann taucht die gleiche Ticketnummer in

51:42.610 --> 51:43.990
mehreren Buchungen auf.

51:44.890 --> 51:48.950
Aber sie taucht nur einmal auf pro Flug.

51:51.250 --> 51:55.650
Und eigentlich müsste man, wenn man genau ist, sagen, eigentlich

51:55.650 --> 51:58.850
müsste sogar doch das Datum mit herhalten.

51:58.950 --> 52:02.170
Es könnte ja sein, dass ich gleich so eine Massenbeschaffung mache.

52:02.290 --> 52:04.170
Das heißt, jede Woche fliege ich mit dem gleichen Flug.

52:05.270 --> 52:06.330
Nee, da ist auch das Ticket anders.

52:06.770 --> 52:08.290
Da wäre die Ticketnummer auch anders.

52:09.050 --> 52:12.610
Also wir unterstellen hier, dass es reicht, den Flug zu nehmen und die

52:12.610 --> 52:16.450
Ticketnummer, dass also, wenn ich den gleichen Flug ein anderes Mal

52:16.450 --> 52:19.210
wiedernehme, dass ich ein neues Ticket habe und dass ich umgekehrt

52:19.210 --> 52:21.970
aber ein Ticket über mehrere Stationen, über mehrere Flugabschnitte

52:21.970 --> 52:22.610
laufen kann.

52:22.890 --> 52:29.650
Und die Kombination aus Ticketnummer und Flugnummer, die sorgt dann

52:29.650 --> 52:30.650
für die Eindeutigkeit.

52:30.910 --> 52:35.490
Also hier haben wir einen zusammengesetzten Schlüssel.

52:36.650 --> 52:39.870
Und dann gehen wir noch den Platz an, wo die Buchung erfolgt ist und

52:39.870 --> 52:43.150
das Datum, an dem der Flug gebucht ist.

52:43.910 --> 52:47.110
Dann sehen wir also, wir haben hier eine Schlüsselbedingung, die eben

52:47.110 --> 52:48.830
zwei Attribute umfasst.

52:49.290 --> 52:53.210
Und wir haben außerdem wieder Fremdschlüssel, nämlich die Flugnummer,

52:54.670 --> 52:58.350
die muss sich übereinstimmen mit einem Flug, den wir kennen.

52:59.090 --> 53:03.290
Und die uns bekannten Flüge, die befinden sich in der Relation Flug.

53:04.270 --> 53:08.010
Und wir werden weiterhin sagen, die Ticketnummer, die müssen wir auch

53:08.010 --> 53:08.370
kennen.

53:09.750 --> 53:13.350
Und diese Ticketnummer finden wir in der Auflistung aller bis jetzt

53:13.350 --> 53:16.730
vergebenen Tickets, nämlich in der Relation Ticket.

53:17.510 --> 53:20.350
Und wir sehen insbesondere auch noch eine Eigenschaft, die wir später

53:20.350 --> 53:24.810
auch noch, sogar gewisse Hinweise gibt, über die Zusammenhänge,

53:25.190 --> 53:29.870
nämlich, dass ein Schlüssel selbst aus Fremdschlüsseln bestehen kann.

53:30.310 --> 53:33.570
Dieser Schlüssel hier besteht aus Fremdschlüsseln.

53:33.670 --> 53:36.790
Also wir können sagen, Schlüssel besteht

53:39.850 --> 53:41.290
aus Fremdschlüsseln.

53:47.440 --> 53:50.320
Also wenn man etwas Erfahrung hat, dann kann man das fort, eine ganze

53:50.320 --> 53:51.920
Menge Rückschlüsse daraus ziehen.

53:52.320 --> 53:56.260
Auch wieder, was sowohl die Anwendungswelt, also die Mini-Welt,

53:56.460 --> 53:57.800
angeht, als auch die Modellierung.

54:01.640 --> 54:06.280
So, hier müssen wir uns vorstellen, dass das hier fortgesetzt wird.

54:08.360 --> 54:11.920
Wir haben also hier einfach eine ganze Menge von Buchungen.

54:12.220 --> 54:17.100
Jetzt sehen wir zum Beispiel, hier haben wir zwei Buchungen für den

54:17.100 --> 54:17.640
selben Flug.

54:17.640 --> 54:22.120
Hier haben wir einen Flug und hier haben wir einen Flug, aber Gott sei

54:22.120 --> 54:24.120
Dank, wie wir sehen, sind die Ticketnummern unterschiedlich.

54:24.700 --> 54:27.080
Und hier haben wir zwei gleiche Ticketnummern.

54:28.660 --> 54:32.980
Also wir sehen, dass auch in dieser kleinen Datenbasis in der Tat

54:33.460 --> 54:37.980
keine der beiden Attribute für sich allein Schlüssel ist, sondern

54:37.980 --> 54:40.580
ersten Kombination zu einem Schlüssel führt.

54:41.680 --> 54:45.040
Ja, und dann sehen wir eben, wo die gebucht sind, auf welchen Plätzen

54:45.040 --> 54:47.240
und zu welchem Datum.

54:48.240 --> 54:51.040
Und Sie sehen auch, da ist nichts geordnet, das geht wie Kraut und

54:51.040 --> 54:51.940
Rüben durcheinander.

54:53.380 --> 54:54.840
In der Datenbasis sind das auch nicht.

54:55.860 --> 55:00.340
Wir sagen immer, das Datenmodell ist alles ungeordnet, wie das sich

55:00.340 --> 55:01.280
für eine Menge gehört.

55:01.580 --> 55:05.020
Und wenn Sie für die Anzeige das geordnet haben wollen, na ja, dann

55:05.020 --> 55:06.140
ordnen Sie es halt gefälligst selber.

55:06.800 --> 55:07.520
Und dann sortieren Sie es.

55:07.840 --> 55:10.260
Wir werden auch sehen, da kann auch das System ein bisschen Hilfe

55:10.260 --> 55:10.620
leisten.

55:15.100 --> 55:16.480
Jetzt müssen wir noch eins machen.

55:17.500 --> 55:20.020
Wir müssen nämlich sagen, wie kommen wir in die Datenbasis rein?

55:20.460 --> 55:22.940
Sie erinnern sich noch, da hatte ich eingeführt, die Wurzelobjekte.

55:23.180 --> 55:28.160
Im Schema müssen wir Wurzelobjekte als die Einstiegspunkte nehmen, von

55:28.160 --> 55:33.440
denen wir aus dann irgendwelche weiteren Schritte, Unternehmen

55:33.440 --> 55:35.640
beispielsweise, aber dann anschließend Polymer für Operatoren

55:35.640 --> 55:36.360
anwenden.

55:36.820 --> 55:38.900
Aber irgendwo müssen wir erstmal reinkommen in die Datenbasis.

55:39.500 --> 55:43.620
Jetzt wird folgende Regel in relationalen Datenbanken erlassen.

55:43.620 --> 55:50.060
Die sagt, es gibt nur pro Relationstyp zu jedem Zeitpunkt nur eine

55:50.060 --> 55:51.620
einzige Ausprägung.

55:52.600 --> 55:56.480
Wir können also auch mit anderen Worten dann sagen, der Relationstyp

55:56.480 --> 56:02.220
dient gleichzeitig als variablen Name in eine Menge, die eben variabel

56:02.220 --> 56:03.880
ist, das heißt, die zeitveränderlich ist.

56:05.780 --> 56:10.420
Also die erste Aussage ist, das ist aus Programmiersprachensicht ein

56:10.420 --> 56:13.400
bisschen ungewöhnlich, ist durchaus gewöhnungsbedürftig.

56:14.060 --> 56:17.220
Obwohl wir einen Typ haben, haben wir nur eine einzige Ausprägung

56:17.220 --> 56:19.440
dazu, die zeitlich variabel ist.

56:20.620 --> 56:24.980
Das zweite, was wir sagen, ist, das sind auch unsere Einstiegspunkte.

56:25.920 --> 56:28.560
Wenn ich also diesen Relationstyp, den wir jetzt als Relationsname,

56:28.640 --> 56:34.300
als variablen Namen, wenn ich den kenne, komme ich in die Datenbasis

56:34.300 --> 56:34.520
rein.

56:35.420 --> 56:40.320
Jede dieser Ausprägungen ist durch ihren Namen als Einstiegspunkt

56:40.320 --> 56:40.580
wahr.

56:42.120 --> 56:45.100
Ich kann aber natürlich einen Einstiegspunkt nehmen, eine Relation, da

56:45.100 --> 56:48.520
gucke ich mal nach, was es denn an referenziellen Konsistenzen gibt

56:48.520 --> 56:52.020
oder Fremdschlüsselbedingungen und anhand derer kann ich mich ja

56:52.020 --> 56:52.540
weiter einleiten.

56:53.400 --> 56:56.600
Ich brauche also nicht parallel in alle reinzugehen, sondern ich nehme

56:56.600 --> 56:59.560
ein, zum Beispiel einen dieser Einstiegspunkte, einen dieser

56:59.560 --> 57:03.540
Wurzelobjekte und an der marschiere ich dann einfach weiter und nutze

57:03.540 --> 57:05.720
jetzt alle die Gesetzmäßigkeiten, die wir eingeführt haben, in der

57:05.720 --> 57:06.360
Struktur aus.

57:06.360 --> 57:10.640
Oder besser gesagt, wir hoffen, dass die Polymorphenoperatoren, die

57:10.640 --> 57:12.520
wir jetzt dann entwickeln werden, dass die das können.

57:12.960 --> 57:16.400
Dass die in der Lage sind, diese inhaltlichen Querverweise zu

57:16.400 --> 57:18.240
verfolgen und auszunutzen.

57:19.500 --> 57:22.760
Jetzt haben wir also in unserem speziellen Beispiel, in dem wir sechs

57:22.760 --> 57:27.420
Relationstypen eingeführt haben, wir sehen auch sechs Ausprägungen.

57:28.660 --> 57:33.400
Jeweils für eine Ausprägung pro Relationstyp haben die gleichen Namen

57:33.400 --> 57:38.700
verwendet und erklären sie uns automatisch in einem relationalen

57:38.700 --> 57:42.220
Datenbanksystem, wird das auch zu einem Wurzelobjekt.

57:45.750 --> 57:47.210
So, und jetzt können wir zusammenfassen.

57:48.390 --> 57:52.170
Wenn wir also jetzt von unserem Modell zum Schema übergehen, ich

57:52.170 --> 57:54.730
glaube, man bekommt all diese Auswirkungen jetzt zum Tragen, dann

57:54.730 --> 57:58.210
geben wir in einem Schema die Relationstypen an, wir geben die

57:58.210 --> 58:01.550
Schlüssel - und Fremdschlüsselbedingungen an und dann werde ich etwas

58:01.550 --> 58:04.130
zunächst mal noch aufschieben, da kommen noch eine ganze Reihe

58:04.130 --> 58:05.450
weiterer Eigenschaften hinzu.

58:05.790 --> 58:08.110
Erstmal können wir noch erheblich mehr Konsistenzbedingungen

58:08.110 --> 58:10.210
unterbringen, als ich bisher erwähnt habe.

58:11.850 --> 58:14.510
Wir werden aber jetzt mal mit diesen zwei einfachen arbeiten.

58:14.930 --> 58:17.350
Wir werden, das hatte ich schon angedeutet, noch mit Sichten arbeiten,

58:17.450 --> 58:18.570
die müssen wir auch irgendwie definieren.

58:19.130 --> 58:20.790
Auch die kommen später noch in das Schema rein.

58:21.270 --> 58:24.230
Und wir werden auch ganz am Ende noch ansehen, man kann nämlich auch

58:24.230 --> 58:28.050
die Zugriffsrechte über das Schema regeln.

58:30.330 --> 58:32.750
Und da muss man allerdings natürlich wieder sagen, wer darf eigentlich

58:32.750 --> 58:33.970
auf die Zugriffsrechte zugreifen.

58:35.230 --> 58:39.030
Und die Relationale Datenbasis ist dann eine Menge von Wurzelobjekten.

58:42.580 --> 58:46.060
Und diese Wurzelobjekte, von denen existiert pro Typ genau eins, das

58:46.060 --> 58:49.440
wird dann immer aktualisiert, ist also die aktuelle Ausprägung.

58:53.450 --> 58:56.290
Und dann wollen wir noch folgendes erreichen, wenn wir jetzt

58:56.290 --> 58:58.450
Konsistenzbedingungen anschreiben, insbesondere wenn wir also die

58:58.450 --> 59:00.910
zwei, die Schlüsselbedingungen und die referenzielle Konsistenz

59:00.910 --> 59:03.690
anschreiben, dann müssen wir jetzt verlangen, das war auch unsere

59:03.690 --> 59:06.450
Forderung ursprünglich, als wir über Transaktionen gesprochen haben,

59:06.810 --> 59:13.430
wir müssen verlangen, dass jeder ändernde Operator dafür Sorge trägt,

59:13.570 --> 59:15.850
dass diese Konsistenzbedingungen beachtet werden.

59:16.130 --> 59:21.070
Das heißt, er weist eine Änderungsoperation zurück, wenn ein Verstoß

59:21.070 --> 59:24.250
gegen diese Konsistenzbedingungen erfolgt.

59:24.870 --> 59:30.170
Wenn er also ein Tuppel einfügt, dann muss er dafür Sorge tragen,

59:30.610 --> 59:35.510
dass, wenn die ursprüngliche Relation die Schlüsselbedingungen erfüllt

59:35.510 --> 59:41.230
hat, dass nach dem erfolgreichen Einfügen auch wieder die Relation

59:41.230 --> 59:43.590
diese Schlüsselbedingungen erfüllt.

59:44.410 --> 59:49.270
Wir verlangen also, dass zu jedem Zeitpunkt unsere Relation R, die vom

59:49.270 --> 59:53.650
Typ T ist, in der ja Konsistenzbedingungen definiert ist, dass dann

59:53.650 --> 59:58.030
immer dafür Sorge getragen wird, dass es nie zwei Tuppel in R gibt,

59:58.390 --> 01:00:01.130
die unter ihrem Schlüssel den gleichen Wert aufweisen.

01:00:01.430 --> 01:00:04.010
Das müssen unsere Polymorphen Operatoren garantieren.

01:00:04.850 --> 01:00:05.770
Das unterstellen wir.

01:00:06.650 --> 01:00:08.950
Und dafür muss natürlich der Datenbankanbieter, der das Ganze mal

01:00:08.950 --> 01:00:11.650
hergestellt hat, der muss halt uns garantieren, dass er auch

01:00:11.650 --> 01:00:14.510
tatsächlich sich an diese Bedingungen hält.

01:00:16.930 --> 01:00:21.690
Und wenn wir referenzielle Konsistenzen angeben, dann, das ist

01:00:21.690 --> 01:00:25.370
erheblich komplizierter zu erreichen, dann verlangen wir Folgendes,

01:00:25.790 --> 01:00:30.370
dann muss nachgesehen werden, wenn wir die referenzielle Konsistenz

01:00:30.370 --> 01:00:35.230
definiert haben von bestimmten Attributen aus in die Attribute einer

01:00:35.230 --> 01:00:40.550
anderen Relation, dann müssen wir prüfen, dann muss der Operator

01:00:40.550 --> 01:00:43.370
prüfen, ob tatsächlich am Schluss diese Teilmengen Bedingungen

01:00:43.370 --> 01:00:43.950
eingehalten sind.

01:00:44.070 --> 01:00:47.890
Ob er in einer anderen Relation der Wert, der hier neu eingefügt wird,

01:00:48.090 --> 01:00:48.910
schon existiert.

01:00:49.790 --> 01:00:51.850
Das kann man sich vorstellen, ist gar nicht ganz einfach, das kostet

01:00:51.850 --> 01:00:55.490
durchaus Aufwand und da muss man überlegen, wie kann man das geschickt

01:00:55.490 --> 01:00:58.730
implementieren, um diesen Aufwand bei der Prüfung möglichst gering zu

01:00:58.730 --> 01:00:58.990
halten.

01:01:00.730 --> 01:01:04.570
Also das ist das, was wir jetzt an Konsistenz garantieren.

01:01:06.190 --> 01:01:09.490
Ja und damit sind wir mit der Struktur fertig und jetzt sind Sie

01:01:09.490 --> 01:01:12.390
bestimmt auch schon etwas gespannt, was denn hinter dem Begriff

01:01:16.990 --> 01:01:20.290
der Polymorphen Operatoren und der relationalen Operatoren, der

01:01:20.290 --> 01:01:21.690
relationalen Algebraten steckt.

01:01:22.010 --> 01:01:24.870
Jetzt gehen wir also los und sagen, wir haben unsere Forderungen auf

01:01:24.870 --> 01:01:29.290
den Tisch gelegt und jetzt sollen diese Forderungen eingehalten

01:01:29.290 --> 01:01:29.550
werden.

01:01:29.670 --> 01:01:30.770
Jetzt werde ich aber etwas tun.

01:01:31.450 --> 01:01:33.850
Ich werde mich die Forderungen zunächst mal gar nicht groß kümmern.

01:01:34.850 --> 01:01:39.910
Sondern, was wir mal unterstellt haben, wenn wir eine Datenbank

01:01:39.910 --> 01:01:45.010
überwiegend lesen, dann interessiert uns erstmal die Operation zum

01:01:45.010 --> 01:01:45.410
Lesen.

01:01:46.530 --> 01:01:49.230
Und jetzt müssen wir ja bedenken, wir haben überall diese

01:01:49.230 --> 01:01:53.010
Querverweise, das einzige um überhaupt durch unsere Datenbank

01:01:53.010 --> 01:01:56.010
irgendwie durchzulaufen und die Informationen zusammen zu sammeln und

01:01:56.010 --> 01:02:00.510
zu komprimieren und dann rauszugeben, sind ja nur Inhalte.

01:02:00.650 --> 01:02:04.990
Wir können immer nur sagen, wenn ich an einer Stelle bin, guck mal, ob

01:02:04.990 --> 01:02:07.310
dieser Inhalt irgendwo anders auch existiert.

01:02:07.790 --> 01:02:10.090
Und wenn ja, dann gehört offenbar die Information zusammen.

01:02:11.230 --> 01:02:15.710
Wir versuchen also zunächst mal reinzugehen, im ersten Schritt von

01:02:15.710 --> 01:02:19.030
unserem Wurzelobjekt, in das wir reingegangen sind, möglichst alle

01:02:19.030 --> 01:02:21.350
Informationen, die gewissen Kriterien erfüllt, die wir da nicht

01:02:21.350 --> 01:02:23.910
anschreiben müssen, zusammen zu sammeln.

01:02:24.330 --> 01:02:27.170
Und in einem zweiten Schritt müssen wir die verdichten, sodass jemand,

01:02:27.310 --> 01:02:29.230
dem wir am Schluss die Information rausgeben, mit der er auch was

01:02:29.230 --> 01:02:29.770
anfangen kann.

01:02:29.830 --> 01:02:32.610
Und die meisten Benutzer sind nur an verdichteter Information

01:02:32.610 --> 01:02:33.150
interessiert.

01:02:33.270 --> 01:02:36.750
Also wir haben sozusagen eine Phase, in der wir rausgehen und uns

01:02:36.750 --> 01:02:38.850
verbreitern und möglichst die Information einsammeln.

01:02:38.910 --> 01:02:42.790
Und eine zweite, da komprimieren wir das Ganze, um am Ende einen

01:02:42.790 --> 01:02:46.170
lesbaren Ausdruck zu liefern, insbesondere der inhaltliche Aussagen

01:02:46.170 --> 01:02:46.650
gestattet.

01:02:48.130 --> 01:02:52.330
Also wollen wir erstmal, wenn wir lesen, irgendwie diese Operatoren,

01:02:52.730 --> 01:02:55.790
die erstmal rausgehen und nachher wieder zusammenfügen, die wollen wir

01:02:55.790 --> 01:02:56.470
erstmal einführen.

01:02:56.610 --> 01:02:58.010
Die brauchen wir für den Zweck.

01:02:59.110 --> 01:03:02.790
Und jetzt ist der Fall, weil wir jetzt nur mit Relationen umgehen

01:03:02.790 --> 01:03:06.010
können, also mit Mengen, führen wir Operatoren ein, die grundsätzlich

01:03:06.010 --> 01:03:07.310
über Mengen orientiert losgehen.

01:03:07.450 --> 01:03:10.690
Also das Verbreitern definieren wir jetzt irgendwie als Verbreitern

01:03:10.690 --> 01:03:14.610
von Mengen und das Komprimieren werden wir als das Komprimieren von

01:03:14.610 --> 01:03:15.630
Mengen betrachten.

01:03:16.390 --> 01:03:19.790
Und also entscheiden, und daher kommt auch die Bezeichnung des

01:03:19.790 --> 01:03:22.390
Relationalen Modells, es ist ein Mengen- orientiertes Modell.

01:03:23.030 --> 01:03:26.870
Und es ist nicht Mengen orientiert, weil die Struktur der Mengen

01:03:27.650 --> 01:03:32.190
enthält, sondern weil die polymorphen Operatoren auf Mengen definiert

01:03:32.190 --> 01:03:32.510
sind.

01:03:33.590 --> 01:03:36.430
Sehr im Gegensatz zur Objektorientierung, wie gesagt, da navigieren,

01:03:36.510 --> 01:03:39.050
das ist eine sogenannte navigierende Schnittstelle, da marschieren sie

01:03:39.050 --> 01:03:40.850
immer den Verweisen nach.

01:03:41.170 --> 01:03:43.990
Hier sind die Verweise irgendwie verdeckt.

01:03:44.470 --> 01:03:49.750
Wir nutzen nur den Operatoren aus, dass die Ausbreitung der Mengen

01:03:49.750 --> 01:03:51.950
irgendwie darauf basiert, dass wir Inhalte vergleichen.

01:03:54.150 --> 01:04:01.750
Also kommen wir mit unserer Algebra zu etwas, was wir als Relationale

01:04:01.750 --> 01:04:03.050
Algebra bezeichnen.

01:04:03.930 --> 01:04:08.170
Und Sie sehen, wenn Sie jetzt an die Lineare Algebra gehen, da gab es

01:04:08.170 --> 01:04:10.030
ja überhaupt nicht viele Operatoren, wenn überhaupt.

01:04:10.550 --> 01:04:12.790
Man konnte halt Vereinigen oder ähnliche Dinge tun.

01:04:13.730 --> 01:04:15.310
Das sind eigentlich uninteressante Operatoren.

01:04:15.390 --> 01:04:18.550
Die Tatsache, dass wir mit Inhalten umgehen, muss ja irgendwie in

01:04:18.550 --> 01:04:21.110
einem größeren Reichtum an Operatoren widerschlagen.

01:04:21.550 --> 01:04:23.630
Und Sie sehen, es gibt eine ganze Menge von Operatoren.

01:04:24.110 --> 01:04:25.670
Manche sind überhaupt nicht lesbar, sehe ich gerade.

01:04:26.610 --> 01:04:30.270
Das da soll so etwas sein.

01:04:30.370 --> 01:04:32.430
Überhaupt stelle ich gerade fest, da haben wir ein Problem.

01:04:34.410 --> 01:04:35.810
Das ist so eine Schleife, soll das sein.

01:04:37.970 --> 01:04:40.070
Also groß gezeichnet so.

01:04:43.980 --> 01:04:46.220
So, und hier sehen Sie eine ganze Menge von Operatoren.

01:04:48.200 --> 01:04:50.600
Selektion, kann man gleich sagen, ist so eine, die komprimiert.

01:04:52.120 --> 01:04:55.040
Und die Projektion ist auch eine, die komprimiert.

01:04:56.180 --> 01:04:59.440
Dann das kathetische Produkt ist eine, die ausdehnt.

01:04:59.580 --> 01:05:01.500
Da ist überhaupt eine Menge verloren gegangen, stelle ich fest.

01:05:01.600 --> 01:05:02.260
Oder nicht lesbar.

01:05:04.200 --> 01:05:05.980
Also das liegt an dem Projekt da oben.

01:05:06.920 --> 01:05:08.960
Da sollte natürlich, jetzt muss ich das alles nochmal nachtragen.

01:05:16.650 --> 01:05:18.150
Doch, den Rest ist lesbar.

01:05:21.470 --> 01:05:22.490
Das sind also Operatoren.

01:05:22.550 --> 01:05:23.670
Ich hatte gesagt, mengenorientiert.

01:05:24.070 --> 01:05:25.430
Also die sind auf Relation definiert.

01:05:25.550 --> 01:05:28.130
Nehmen Relation als Eingabe und liefern dann wieder eine Relation als

01:05:28.130 --> 01:05:28.710
Ausgabe aus.

01:05:30.330 --> 01:05:32.550
Die erste, wie gesagt, die komprimiert.

01:05:32.710 --> 01:05:33.710
Die zweite ist auch komprimierend.

01:05:33.830 --> 01:05:37.270
Die dritte ist eine, die furchtbar sich ausbreitet.

01:05:38.210 --> 01:05:44.950
Die vierte ist dann die Vereinigung und die Differenz und die

01:05:44.950 --> 01:05:45.730
Schnittbildung.

01:05:45.910 --> 01:05:47.270
Das ist eine klassische Mengenoperation.

01:05:47.950 --> 01:05:48.670
Ein paar Einschränkungen.

01:05:49.590 --> 01:05:53.430
Dann kommen zwei Operationen, die sogenannten Verbindungsoperationen,

01:05:53.450 --> 01:05:57.310
die auch ausdehnend sind, aber etwas selektiver sich ausdehnen.

01:05:57.690 --> 01:05:58.870
Und schließlich kommt noch die Division.

01:05:59.110 --> 01:06:00.730
Das ist wieder eine komprimierende Operation.

01:06:01.410 --> 01:06:04.810
Dass ich hier nicht in der Reihenfolge ausdehnend, komprimierend

01:06:04.810 --> 01:06:07.270
vorgehe, hat eigentlich mehr mit der Komplexität zu tun.

01:06:07.890 --> 01:06:10.050
Die Reihenfolge, die ich hier verwende, die werde ich auch dann in der

01:06:10.050 --> 01:06:11.530
Präsentation verwenden.

01:06:11.770 --> 01:06:14.410
Die sagt halt, erst kommt die ganz einfache und dann gehen wir auf die

01:06:14.410 --> 01:06:15.430
etwas komplizierteren über.

01:06:19.530 --> 01:06:22.670
Da wir aber hier formal arbeiten, wir können überall eine formale

01:06:22.670 --> 01:06:29.150
Definition angeben, können wir ja auch sagen, eigentlich brauchen wir

01:06:29.150 --> 01:06:30.310
gar nicht alle.

01:06:30.690 --> 01:06:32.110
Wir kommen auch mit weniger aus.

01:06:32.610 --> 01:06:35.430
Wir kommen beispielsweise, hier unten, das Theta ist übrigens in

01:06:35.430 --> 01:06:40.810
logischen Bedingungen, wir kommen aus mit als Grundoperation, mit der

01:06:40.810 --> 01:06:43.930
Selektion, mit der Projektion, also erst mit der zweiten Operation,

01:06:44.590 --> 01:06:48.190
dann mit dem kathesischen Produkt, das ist die dritte, dann mit der

01:06:48.190 --> 01:06:49.350
Vereinigung und der Differenz.

01:06:49.570 --> 01:06:51.190
Also mit den ersten fünf kommen wir aus.

01:06:51.750 --> 01:06:54.530
Und der Rest ist Zuckerguss, syntaktischer Zuckerguss, wenn man so

01:06:54.530 --> 01:06:54.690
will.

01:06:55.910 --> 01:07:00.330
Die kann man nämlich aus den anderen Operatoren herleiten.

01:07:01.090 --> 01:07:05.530
Aber, wir haben ja immer das Diktat der Performance.

01:07:06.150 --> 01:07:08.650
Was immer wir tun, wir haben immer darauf zu achten, dass wir

01:07:08.650 --> 01:07:09.410
performant bleiben.

01:07:10.110 --> 01:07:14.090
Und natürlich werden wir nicht etwa eine Prozedur aus mehreren dieser

01:07:14.090 --> 01:07:20.510
ersten fünf Operationen definieren, die möglicherweise fürchterlich

01:07:20.510 --> 01:07:23.650
unkomplizierte Zwischenergebnisse produziert, die dann

01:07:23.650 --> 01:07:26.890
weiterverarbeitet werden, sondern wir werden auch sehen, dass wir auch

01:07:26.890 --> 01:07:31.470
die abgeleiteten Definitionen kollabieren in einen einzigen intern

01:07:31.470 --> 01:07:32.490
implementierten Operator.

01:07:32.750 --> 01:07:33.850
Da kriegen wir eine Performance her.

01:07:33.930 --> 01:07:36.450
Und ich werde das auch an den einzelnen Operatoren später erläutern,

01:07:36.870 --> 01:07:40.270
was da tatsächlich enorme Performancegewinne erreicht werden können,

01:07:40.530 --> 01:07:43.370
wenn wir für auch die restlichen Operatoren uns vorgeben, als

01:07:43.370 --> 01:07:45.410
elementar und elementar implementieren.

01:07:51.830 --> 01:07:56.030
Und dann gibt es noch zwei Operatoren, die man aus formalen Gründen

01:07:56.030 --> 01:07:56.730
auch noch braucht.

01:07:56.930 --> 01:07:58.570
Einen werden wir auch gelegentlich einsetzen.

01:07:58.570 --> 01:08:03.390
Das ist der Operator Rho, der dazu dient, gelegentlich Spalten, also

01:08:03.390 --> 01:08:09.930
Attribute umzubenennen und der andere Xi zum Erzeugen von Tupeln oder

01:08:09.930 --> 01:08:11.590
von Relationen an diesem Fall.

01:08:12.010 --> 01:08:14.390
Den werden wir nicht weiterverwenden, der ist aber aus formalen

01:08:14.390 --> 01:08:15.550
Gründen auch noch erforderlich.

01:08:20.030 --> 01:08:21.610
So, jetzt sind wir bei dem ersten Operator.

01:08:21.850 --> 01:08:22.370
Selektion.

01:08:23.670 --> 01:08:27.290
Die Selektion, also mählich wird es immer schlechter, das Bild

01:08:27.290 --> 01:08:27.690
übrigens.

01:08:29.030 --> 01:08:30.730
Irgendwas müssen wir mit dem da oben tun.

01:08:33.770 --> 01:08:35.070
Wird immer schlechter lesbar.

01:08:35.410 --> 01:08:35.930
Tut mir so leid.

01:08:36.730 --> 01:08:39.690
Aber man kann so ganz schwach noch sehen, dass dann auch...

01:08:39.690 --> 01:08:45.990
Das soll hier Verknüpfung sein.

01:08:46.330 --> 01:08:48.210
Da ist...

01:08:50.910 --> 01:08:51.070
Ja.

01:08:52.130 --> 01:08:56.590
Die Selektion macht folgendes, die nimmt so eine große Relation und

01:08:56.590 --> 01:08:57.670
sagt, ich brauche ja gar nicht alle Tupeln.

01:08:58.610 --> 01:09:02.610
Das heißt, die geht einfach mit einem Vergleichskriterium los und

01:09:02.610 --> 01:09:06.850
sagt, ich wende auf jedes Tupel eine Vergleichsoperation an und wenn

01:09:06.850 --> 01:09:12.350
die Vergleichsoperation sich zu wahr ergibt, dann wird das Tupel

01:09:12.350 --> 01:09:16.350
übernommen in das Ergebnis und wenn es falsch ist, dann wird es

01:09:16.350 --> 01:09:16.790
weggeworfen.

01:09:16.850 --> 01:09:19.910
Dann wird es nicht in das Ergebnis übernommen.

01:09:21.310 --> 01:09:24.350
Jetzt wenn Sie sich mal vorstellen, was ist denn eigentlich, wenn Sie

01:09:24.350 --> 01:09:25.210
den Schlüssel nehmen.

01:09:25.270 --> 01:09:28.090
Wenn Sie also sagen, ich vergleiche auf den Schlüsselwert.

01:09:28.610 --> 01:09:30.770
Wie groß ist dann die Kardinalität des Ergebnisses?

01:09:34.230 --> 01:09:34.670
Was meinen Sie?

01:09:34.850 --> 01:09:39.710
Wie groß ist das Ergebnis, wenn ich den Wert vorgebe und sage, dass

01:09:39.710 --> 01:09:43.550
der Schlüsselwert maximal 1?

01:09:43.990 --> 01:09:46.030
Also das ist das Beste, was wir erreichen können.

01:09:46.090 --> 01:09:47.770
Nehmen Sie an, Sie haben eine Million Tupel.

01:09:48.110 --> 01:09:49.910
Sie wenden den Selektionsschlüssel an 1.

01:09:50.710 --> 01:09:52.330
Das ist doch wirklich eine Auswahl.

01:09:53.750 --> 01:09:55.850
Eine Schärfe haben Sie von 10 hoch 6.

01:09:56.310 --> 01:10:00.070
Und Sie brauchen gelegentlich wirklich so gewaltige Trennschärfen,

01:10:00.250 --> 01:10:03.770
damit Sie überhaupt die Datenbasen, um weiterzuarbeiten, auf ein

01:10:03.770 --> 01:10:04.770
vernünftiges Maß bringen.

01:10:06.390 --> 01:10:10.770
Allgemein, was man normalerweise tut, um abzuschätzen, wie gut eine

01:10:10.770 --> 01:10:13.490
Selektion wirkt, ist tatsächlich, dass man etwas Statistik treibt oder

01:10:13.490 --> 01:10:17.430
Wahrscheinlichkeiten aufstellt und dann abschätzt, wie groß ist denn

01:10:17.430 --> 01:10:20.750
die Trennschärfe, die Selektivität einer solchen Selektionsoperation.

01:10:21.730 --> 01:10:27.010
Also wir können mit der enorme Reduktion erreichen, wenn wir jetzt

01:10:27.010 --> 01:10:28.830
anfangen, Ergebnisse zu komprimieren.

01:10:29.350 --> 01:10:32.230
Dann ist das eine der ersten Kandidaten für das Komprimieren.

01:10:33.690 --> 01:10:36.590
Und wir werden sogar später sehen, dass man den, weil er so schön

01:10:36.590 --> 01:10:38.910
komprimiert, dass man den immer so schnell als möglich anzuwenden

01:10:38.910 --> 01:10:41.790
versucht, um die Größe seiner Zwischenergebnisse zu reduzieren.

01:10:43.230 --> 01:10:46.370
So, für die Selektionsbedingungen, das sind immer

01:10:46.910 --> 01:10:49.130
Vergleichsoperationen, habe ich ja hier angegeben, muss man nicht mehr

01:10:49.130 --> 01:10:52.870
sagen, die Domänen, die muss definiert sein auf die Domänen, die wir

01:10:52.870 --> 01:10:56.810
verwenden und dann kann ich die noch disjunktiv oder konjunktiv

01:10:56.810 --> 01:10:58.090
verknüpfen.

01:11:00.630 --> 01:11:02.010
Hier haben wir so ein Beispiel.

01:11:03.470 --> 01:11:05.230
Land gleich Deutschland.

01:11:05.390 --> 01:11:06.830
Nun Land ist nicht der Schlüssel.

01:11:07.470 --> 01:11:10.350
Also wir werden wahrscheinlich nicht damit rechnen können, dass

01:11:10.350 --> 01:11:14.310
tatsächlich nur ein einziges Tuppel übrig bleibt, aber man braucht ja

01:11:14.310 --> 01:11:18.970
nur hinzuschauen, zumindest eine ganze Reihe dürfte doch reduziert

01:11:18.970 --> 01:11:19.230
werden.

01:11:19.370 --> 01:11:21.810
Also die ursprüngliche Größe wird die Relation nicht mehr haben.

01:11:21.810 --> 01:11:24.670
Jetzt lassen wir mal hier ein bisschen Animation durchlaufen.

01:11:25.250 --> 01:11:28.230
Was jetzt übrig geblieben ist und hier viel besser verschwunden ist

01:11:28.230 --> 01:11:32.810
als bei mir, da sind die Tuppel, die noch Deutschland enthalten.

01:11:32.950 --> 01:11:33.770
Die haben wir jetzt ausgewählt.

01:11:34.810 --> 01:11:37.230
Naja, und wir könnten uns noch vorstellen, dass wir anschließend das

01:11:37.230 --> 01:11:40.010
Ganze zusammenschieben für die Ausgabe.

01:11:40.390 --> 01:11:44.390
Und jetzt haben wir immerhin aus ursprünglich so etwa 20 Tuppeln 5

01:11:44.390 --> 01:11:48.010
ausgewählt, aber wir haben nur eine Trennschärfe von 75%.

01:11:49.070 --> 01:11:50.670
Ein Viertel ist noch übrig geblieben.

01:11:51.090 --> 01:11:52.250
Das ist doch schon ganz anständig.

01:11:53.250 --> 01:11:54.470
Das ist eine Selektionsoperation.

01:11:55.050 --> 01:12:00.310
Hier sehen wir übrigens ein Spezifikum, die Selektion kennt zwei

01:12:00.310 --> 01:12:00.990
Arten.

01:12:01.410 --> 01:12:05.370
Eine daneben geben wir eine Konstante vor, wie hier D, und vergleichen

01:12:05.370 --> 01:12:06.070
auf die Konstante.

01:12:06.730 --> 01:12:09.810
Aber wir können auch eine andere wählen, die vergleicht einfach zwei

01:12:09.810 --> 01:12:15.090
Werte unter zwei verschiedenen Attributen der Relation, aber wieder

01:12:15.090 --> 01:12:15.790
Tuppel für Tuppel.

01:12:17.950 --> 01:12:18.850
Zum Beispiel hier.

01:12:19.350 --> 01:12:22.690
Hier könnten wir sagen, wir nehmen mal alle Flugzeugtypen, bei denen

01:12:22.690 --> 01:12:28.770
die erste Klasse mehr Sitze aufweist als in dem Fall die

01:12:28.770 --> 01:12:29.450
Businessklasse.

01:12:30.710 --> 01:12:32.470
Da brauchen wir nur einen Blick drauf zu werfen.

01:12:32.790 --> 01:12:36.110
Ganz deutlich bleibt da eigentlich nur die Concorde übrig, weil die

01:12:36.110 --> 01:12:37.830
überhaupt nichts anderes hat als erste Klasse Sitze.

01:12:38.850 --> 01:12:39.730
Zumindest vom Preis her.

01:12:42.430 --> 01:12:42.950
Und...

01:12:43.790 --> 01:12:47.610
also müsste auch hier verschwinden, nur das bleibt übrig, schiebe ich

01:12:47.610 --> 01:12:50.050
halt auch wieder nach oben, um das Endergebnis zu produzieren.

01:12:51.370 --> 01:12:55.610
Ja, und dann können wir jetzt konjunktiv verknüpfen, zum Beispiel hier

01:12:55.610 --> 01:12:59.130
ist eine, die besagt, ich kann... jetzt mal auf Rot übergehen.

01:13:02.980 --> 01:13:04.100
Hier kann ich...

01:13:04.100 --> 01:13:05.580
das war zu viel, des Guten.

01:13:06.920 --> 01:13:07.320
Zurück.

01:13:09.060 --> 01:13:14.860
Hier machen wir folgendes, wir suchen nach Flughäfen, wir suchen nach

01:13:14.860 --> 01:13:19.040
Flügen, die von Frankfurt aus gehen und mit einer Entfernung größer

01:13:19.040 --> 01:13:19.920
6000 sind.

01:13:20.320 --> 01:13:22.660
Jetzt müssen wir einfach mal glauben, dass wir an der Stelle, das ist

01:13:22.660 --> 01:13:25.320
ja auch deutlich zu sehen, dass wir auch alle erwischt haben, das

01:13:25.320 --> 01:13:26.820
können Sie nicht unbedingt hier ersehen.

01:13:27.640 --> 01:13:28.720
Wo haben wir denn die Entfernung?

01:13:29.100 --> 01:13:29.580
Die haben wir hier.

01:13:29.980 --> 01:13:31.440
Auch zumindest alles über 6.

01:13:32.640 --> 01:13:36.940
Und nebenbei gesagt, es gibt auch eine äquivalente Formulierung.

01:13:37.540 --> 01:13:41.280
Die hier und die hier unten sind äquivalent.

01:13:42.600 --> 01:13:44.540
Jetzt werden Sie sagen, warum ist das äquivalent?

01:13:45.100 --> 01:13:46.380
Kann man sich vorstellen.

01:13:46.560 --> 01:13:49.440
Das ist etwa die gleiche Bedeutung.

01:13:50.040 --> 01:13:51.360
Aber daraus sehen wir schon etwas.

01:13:51.860 --> 01:13:54.260
Wir können auch Gesetze erlassen.

01:13:54.940 --> 01:13:58.140
Wir können also sagen, wenn die beiden äquivalent sind, dann kannst du

01:13:58.140 --> 01:14:00.020
entweder den einen oder den anderen Ausdruck nehmen.

01:14:00.220 --> 01:14:02.800
Für den Benutzer wunderbar zunächst einmal, ist nämlich egal, wie er

01:14:02.800 --> 01:14:03.260
es hinschreibt.

01:14:04.460 --> 01:14:08.580
Für das System auch interessant, weil das System sich dann mal intern

01:14:08.580 --> 01:14:12.540
seine Implementierung, die Organisation der Datenbasis anschaut und

01:14:12.540 --> 01:14:15.740
sagt, na, ist jetzt die eine schneller durchzuführen oder ist die

01:14:15.740 --> 01:14:16.720
andere schneller durchzuführen?

01:14:17.100 --> 01:14:18.920
Das heißt, wir bauen uns einen Optimierer hintendran.

01:14:19.400 --> 01:14:21.880
Dieser Optimierer schaut sich die Ausdrücke an und weil er Regeln hat

01:14:21.880 --> 01:14:24.520
zum Umformen, der kann also den oberen und den unteren Ausdruck und

01:14:24.520 --> 01:14:26.720
den unteren und den oberen Ausdruck umformen, kann der also

01:14:26.720 --> 01:14:30.640
tatsächlich sich die beste Strategie auswählen, wie er möglichst

01:14:30.640 --> 01:14:31.680
schnell die Antwort gibt.

01:14:32.760 --> 01:14:33.600
Und das ist wunderbar.

01:14:33.740 --> 01:14:36.720
Das heißt nämlich, wir können tatsächlich, solange wir nur unseren

01:14:36.720 --> 01:14:40.780
Sachverhalt, den wir angeben wollen, richtig wiedergeben, brauchen wir

01:14:40.780 --> 01:14:41.660
uns um nichts zu kümmern.

01:14:41.760 --> 01:14:44.580
Intern das System wird schon dafür Sorge tragen, dass es unter Wahrung

01:14:44.580 --> 01:14:50.140
von Dienstmerkmalen oder Dienstqualitäten uns das korrekte Ergebnis

01:14:50.140 --> 01:14:51.120
liefert.

01:14:51.420 --> 01:14:54.720
Zum Beispiel besonders preisgünstig, weil besonders performant.

01:14:58.220 --> 01:15:00.880
Die Projektion ist das Gegenteil.

01:15:01.500 --> 01:15:03.860
Die Selektion hat ja Zeilen ausgewählt.

01:15:04.420 --> 01:15:06.540
Die Projektion, die wählt Spalten aus.

01:15:07.500 --> 01:15:10.320
So nach dem Motto, ach, mich interessiert doch nicht jedes Attribut,

01:15:10.440 --> 01:15:13.120
es sind nur ganz bestimmte Attribute, die mich interessieren, dann

01:15:13.120 --> 01:15:14.320
wirf mal den Rest weg.

01:15:15.320 --> 01:15:17.420
Ist also auch eine, die komprimiert.

01:15:17.740 --> 01:15:21.720
Allerdings da ist mit der Trennschärfe nicht sonderlich viel her.

01:15:21.800 --> 01:15:25.160
Nehmen wir an, wir haben zehn Attribute und davon wollen wir

01:15:25.160 --> 01:15:27.560
normalerweise mehr als eins haben, zwei, drei.

01:15:28.120 --> 01:15:33.160
Dann werfen wir also gerade ein Drittel der Informationen, ein Viertel

01:15:33.160 --> 01:15:37.800
irgendwas davon weg, während wir gesehen haben, bei der Eliminierung

01:15:37.800 --> 01:15:41.160
von Zeilen, erheblich höhere Trennschärfen erreichen können.

01:15:42.580 --> 01:15:45.800
Ja, wir machen also folgendes, wir geben eine Liste von Attributen vor

01:15:47.640 --> 01:15:52.980
und dann werfen wir, man kann sich vorstellen, wir umrahmen nur noch

01:15:52.980 --> 01:15:55.860
die Attribute, die in der Liste stehen, das sind die, die im Ergebnis

01:15:55.860 --> 01:15:59.180
bleiben und der Rest, der wird einfach nicht in das Ergebnis

01:15:59.180 --> 01:15:59.600
übernommen.

01:16:01.340 --> 01:16:05.080
So, also hier, beispielsweise, wenn Sie sich oben die Liste ansehen,

01:16:05.580 --> 01:16:08.780
dann stellen wir fest, die Zeitzone taucht da nicht auf.

01:16:10.420 --> 01:16:13.760
Also werden wir, das ist kein besonders sehr großes Ersparnis, wenn es

01:16:13.760 --> 01:16:18.460
auch noch so kurze Werte sind, aber wir eliminieren zumindest die

01:16:18.460 --> 01:16:20.020
Zeitzone, das sehen Sie da draußen.

01:16:20.460 --> 01:16:21.600
Jetzt verschwindet die einfach.

01:16:22.740 --> 01:16:24.580
Und das ist das Ergebnis, mit dem kann man weiterarbeiten.

01:16:28.290 --> 01:16:30.030
Jetzt machen wir es mal ein bisschen anders.

01:16:30.550 --> 01:16:32.530
Habe ich da irgendwas verpasst?

01:16:34.030 --> 01:16:34.750
Zurück, ne.

01:16:35.550 --> 01:16:35.770
Okay.

01:16:36.630 --> 01:16:38.750
Jetzt machen wir was anderes, jetzt gehen wir auf ein einziges

01:16:38.750 --> 01:16:39.790
Attribut zurück, Land.

01:16:40.970 --> 01:16:44.470
Also wir haben uns vorzustellen, dass wir hier, sozusagen, das lassen

01:16:44.470 --> 01:16:44.870
wir übrig.

01:16:47.270 --> 01:16:48.630
Das ist auch wieder einfach.

01:16:49.710 --> 01:16:51.910
Jetzt verschwindet der Rest und das da steht da.

01:16:54.270 --> 01:16:54.790
Tja.

01:16:57.870 --> 01:17:01.690
Aber das ist keine Relation nach unserer Lesart.

01:17:04.070 --> 01:17:05.650
Denn die enthält ja Duplikate.

01:17:07.770 --> 01:17:10.870
Und wir sind ja ziemlich stur an der Stelle.

01:17:11.090 --> 01:17:12.370
Oder unser Datenmodell ist stur.

01:17:12.470 --> 01:17:13.510
Es muss eine Menge sein.

01:17:14.530 --> 01:17:16.410
Also müssen Duplikate eliminiert werden.

01:17:18.030 --> 01:17:21.990
Und Duplikate zu eliminieren, das sieht so aus.

01:17:22.150 --> 01:17:23.110
Jetzt schauen wir mal an.

01:17:23.790 --> 01:17:26.770
Jetzt wird da markiert, jetzt fällt einiges raus.

01:17:27.270 --> 01:17:29.490
Den Rest schieben wir wieder zusammen und das ist das Endergebnis.

01:17:32.070 --> 01:17:35.790
Dummerweise ist die Duplikate-Eliminierung aber ach, wenn Sie es ganz

01:17:35.790 --> 01:17:37.090
günstig haben, N log N.

01:17:39.510 --> 01:17:40.550
Sonst quadratisch.

01:17:41.690 --> 01:17:43.650
Das ist natürlich absolut verblüffend.

01:17:43.850 --> 01:17:45.470
Sie sagen, ich will ja nicht alles haben.

01:17:46.950 --> 01:17:49.130
Und denken, das ist eine triviale Operation.

01:17:49.870 --> 01:17:51.970
Und stattdessen steht da plötzlich eine quadratische Operation

01:17:51.970 --> 01:17:52.370
dahinter.

01:17:53.290 --> 01:17:54.690
Das wird uns später auch noch beschäftigen.

01:17:55.190 --> 01:17:58.950
Weil als Benutzer neigen Sie ja normalerweise dazu, etwas, was Ihnen

01:17:58.950 --> 01:18:02.330
trivial erscheint, dass es auch wenig Aufwand kostet.

01:18:02.530 --> 01:18:04.570
Und jetzt fordern Sie, dass es auch wenig Geld kostet, wenn Sie dafür

01:18:04.570 --> 01:18:05.130
zahlen müssen.

01:18:06.170 --> 01:18:09.170
Und wenn da plötzlich eine Operation ist, die ganz harmlos aussieht,

01:18:09.370 --> 01:18:14.770
aber teuer ist, dann werden Sie erst verwirrt und anschließend drücken

01:18:14.770 --> 01:18:18.070
Sie überhaupt darum, das System zu benutzen oder diese Operation zu

01:18:18.070 --> 01:18:18.450
benutzen.

01:18:19.970 --> 01:18:23.850
Also das ist etwas Tückisches an der Projektion, die erstmal gar nicht

01:18:23.850 --> 01:18:27.070
mehr so sehr komprimiert und das dann auch noch zu hohen Kosten macht.

01:18:27.910 --> 01:18:30.210
Also werden wir uns überlegen, wie kriegen wir die Kosten runter.

01:18:30.630 --> 01:18:32.690
Aber im Augenblick müssen wir erstmal zur Kenntnis nehmen, dass das

01:18:32.690 --> 01:18:34.050
also bestenfalls endlockend ist.

01:18:42.820 --> 01:18:45.060
Ah ne, die hatte jetzt das Land, jetzt am Ende.

01:18:46.080 --> 01:18:46.900
Gehen wir nochmal zurück.

01:18:48.780 --> 01:18:51.420
Hier hatten wir die Projektion auf Land vorgenommen.

01:18:55.880 --> 01:18:57.340
Habe ich da was durcheinander geworfen?

01:18:59.000 --> 01:19:00.220
Ja, das ist die Relation.

01:19:01.200 --> 01:19:02.500
Jetzt müssen wir nochmal zurückgehen.

01:19:02.920 --> 01:19:05.260
Ja, das ist schon die Flughafen-Relation gewesen.

01:19:06.080 --> 01:19:06.800
Also hier haben wir ja noch die...

01:19:06.800 --> 01:19:08.620
Sie sind ganz schwach.

01:19:09.420 --> 01:19:10.780
Die gesamte Relation.

01:19:16.290 --> 01:19:17.170
So, jetzt...

01:19:17.170 --> 01:19:18.510
Das war eigentlich das Komprimieren.

01:19:18.610 --> 01:19:20.110
Obwohl wir gesagt haben, Komprimieren ist ja am Ende.

01:19:21.130 --> 01:19:22.010
Jetzt geht's...

01:19:22.010 --> 01:19:23.270
Jetzt wollen wir mal ausdehnen.

01:19:24.930 --> 01:19:27.750
Die primitivste Operation, die man sich überhaupt vorstellen kann fürs

01:19:27.750 --> 01:19:30.910
Ausdehnen, ist, die nimmt einfach zwei Relationen und bildet das

01:19:30.910 --> 01:19:31.650
charakteristische Produkt.

01:19:32.390 --> 01:19:35.510
Jedes Tuppel der einen Relation mit jedem Tuppel der anderen.

01:19:36.730 --> 01:19:37.770
Das führe ich auch mal vor.

01:19:38.870 --> 01:19:39.930
Das ist ein graues Licht.

01:19:40.050 --> 01:19:43.650
Zunächst einmal kann man sich schnell überlegen, weil Sie n-mal-n

01:19:43.650 --> 01:19:44.370
-Tuppel kriegen.

01:19:44.670 --> 01:19:47.290
Wir sehen mal gerade an, Sie haben 10 nach 6 Tuppel in jeder Relation,

01:19:47.410 --> 01:19:48.010
macht 10 nach 12.

01:19:50.030 --> 01:19:52.590
Ah, da laufen schon nicht Ihre Plattenspeicher über.

01:19:53.270 --> 01:19:54.750
Nur weil Sie da irgendwas...

01:19:54.750 --> 01:19:57.470
Und dann haben Sie noch blindlings alles zusammengepackt, ob es

01:19:57.470 --> 01:19:58.550
zusammengehört oder nicht.

01:19:59.290 --> 01:20:01.550
Da sieht man schon, das charakteristische Produkt ist meistens,

01:20:01.570 --> 01:20:04.430
allerdings auch nicht immer, aber meistens eher eine gedankliche

01:20:04.430 --> 01:20:05.130
Konstruktion.

01:20:05.590 --> 01:20:08.070
Aber sie ist so die primitive Ebene, auf der wir uns zunächst mal

01:20:08.070 --> 01:20:08.390
ausdehnen.

01:20:08.450 --> 01:20:10.910
Wir nehmen eine Relation und hängen eine zweite dran.

01:20:11.870 --> 01:20:14.230
Und anschließend, wenn wir die haben, dann können wir mit dem Ergebnis

01:20:14.230 --> 01:20:15.150
selbst wieder etwas tun.

01:20:16.930 --> 01:20:20.250
Für kleine Relationen, also insbesondere gegen Ende, da kommt

01:20:20.250 --> 01:20:22.910
gelegentlich tatsächlich diese Operation sogar auch in der Praxis vor.

01:20:23.610 --> 01:20:26.890
So, also jedes Tuppel, mit jedem Tuppel.

01:20:28.070 --> 01:20:30.090
Ich führe das mal nur vorher hier dran.

01:20:30.550 --> 01:20:33.490
Nehmen wir an, wir haben, im Augenblick betrachten wir nur die ersten

01:20:33.490 --> 01:20:37.070
vier Tuppel aus jeder der beiden Relationen Buchung und Kunde.

01:20:37.450 --> 01:20:39.910
Wir können sagen, die wollen wir irgendwie zusammenbringen, weil ja

01:20:39.910 --> 01:20:43.090
offensichtlich der Bucher, die Buchung und der Kunde, die hängen

01:20:43.090 --> 01:20:45.190
irgendwie zusammen über die Ticketnummer und dann kriegen wir auch den

01:20:45.190 --> 01:20:45.890
Namen noch dazu.

01:20:46.930 --> 01:20:50.530
Sieht also durchaus sinnvoll aus, sich von Buchung mal in die Richtung

01:20:50.530 --> 01:20:52.190
nach außen zu bewegen, zum Kunden.

01:20:52.790 --> 01:20:58.710
Aber wenn wir das umsetzen, dann produzieren wir ein Ergebnis, da

01:20:58.710 --> 01:21:02.470
sehen Sie zunächst mal, das ist überhaupt nur das erste Tuppel aus

01:21:02.470 --> 01:21:08.470
unserer Buchung-Relation und diesmal mit jedem dieser vier Kunden, die

01:21:08.470 --> 01:21:10.670
hier vorkommen, zusammengepackt.

01:21:12.650 --> 01:21:18.390
Dann haben wir, wobei hier, jetzt gehen wir weiter, jetzt kommt das

01:21:18.390 --> 01:21:23.370
nächste Tuppel aus Buchung, jetzt kommt das dritte Tuppel aus Buchung,

01:21:23.730 --> 01:21:27.550
wieder mit den vier Tuppeln aus der anderen, jetzt kommt das nächste

01:21:27.550 --> 01:21:31.370
und stellen Sie sich vor, das sind eine Million Tuppel bei jedem, dann

01:21:31.370 --> 01:21:32.750
können Sie sich also vorstellen, was da los ist.

01:21:34.330 --> 01:21:36.450
Und dann ist das Ganze blindlings, denn da hat überhaupt nichts

01:21:36.450 --> 01:21:38.110
miteinander zu tun, mit einer Ausnahme.

01:21:39.050 --> 01:21:46.770
Wenn wir uns mal ansehen, es gibt tatsächlich, und zwar sehen wir das

01:21:46.770 --> 01:21:53.180
hier, da stimmen die Tickets nun mal überein.

01:21:55.440 --> 01:21:57.600
Da könnte man sagen, das scheint doch sinnvoll zu sein.

01:21:57.980 --> 01:22:03.320
Das soll nämlich heißen, wer hat denn auf dem Flug 513 beispielsweise

01:22:03.320 --> 01:22:06.760
gebucht, der Passagiere, die darauf gebucht haben.

01:22:06.840 --> 01:22:09.440
Dann kriegt man zum Beispiel an der Stelle mich raus.

01:22:11.020 --> 01:22:12.880
Und vielleicht haben wir noch ein paar andere, aber es sind jedenfalls

01:22:12.880 --> 01:22:15.480
nur ganz wenig Tuppel, von denen man sagen kann, das ist eine

01:22:15.480 --> 01:22:18.580
sinnvolle Kombination, während der Rest ist einfach blindwütig alles

01:22:18.580 --> 01:22:19.800
zusammengepackt.

01:22:20.460 --> 01:22:23.100
Aber da sehen wir auch schon, wo wir eigentlich hinwollen.

01:22:23.660 --> 01:22:27.080
Wir wollen nämlich das kategorische Produkt eigentlich nur gedanklich

01:22:27.080 --> 01:22:27.460
verwenden.

01:22:27.660 --> 01:22:30.940
Wir wollen sagen, das ist der Basismechanismus, mit dem wir uns von

01:22:30.940 --> 01:22:33.680
einer Relation rausbewegen in unserer Datenbasis.

01:22:34.300 --> 01:22:40.080
Und weil wir entgegen dem objektorientierten Ansatz, wo wir sozusagen

01:22:40.080 --> 01:22:42.840
die Ticketnummer beispielsweise als Verweis verwenden,

01:22:43.060 --> 01:22:46.020
mengenorientiert sind, ist ja immer die Gefahr, dass man erstmal zu

01:22:46.020 --> 01:22:47.840
viel zusammenpackt.

01:22:47.880 --> 01:22:50.000
Nicht so schön, die Mengenorientierung ist auch formal.

01:22:50.780 --> 01:22:55.540
Der Nachteil ist, sie ist sehr bekannt zum Beispiel, muss relativ

01:22:55.540 --> 01:22:59.720
unterschiedslos vorgehen, was die einzelnen Werte in der Relation

01:22:59.720 --> 01:23:00.240
angeht.

01:23:00.840 --> 01:23:01.620
Das sehen wir also hier.

01:23:01.900 --> 01:23:05.640
Aber sie könnte doch etwas besser sein, indem sie nämlich auf

01:23:06.780 --> 01:23:07.760
Wertegleichheit prüft.

01:23:08.180 --> 01:23:10.940
Also wir bräuchten eigentlich eine Abwandlung des kathiesischen

01:23:10.940 --> 01:23:15.960
Produktes, in das wir irgendwie einen Wertevergleich reinpacken.

01:23:16.320 --> 01:23:18.480
Dann wären wir nämlich sofort selektiv, dann gehen wir nicht mehr

01:23:18.480 --> 01:23:22.420
blindwütig raus, sondern gehen wir gezielt aufgrund der Werte raus.

01:23:22.500 --> 01:23:24.660
Immer noch mengenorientiert, aber aufgrund der Werte.

01:23:26.100 --> 01:23:30.700
Also das ist nur als gedankliche Konstruktion brauchbar, oder im

01:23:30.700 --> 01:23:37.700
Extremfall mal, wenn wir schon eine sehr kleine Relation haben und die

01:23:37.700 --> 01:23:38.900
nicht mehr anders zusammenpacken können.

01:23:41.180 --> 01:23:45.320
Wir sehen also, was wir eigentlich hätten, wir wollen nicht

01:23:45.320 --> 01:23:50.040
blindlings, das gefällt uns gar nicht, sondern wir wollen sinnvoll

01:23:50.040 --> 01:23:50.380
sein.

01:23:50.820 --> 01:23:53.520
Und das könnten wir durch eine anschließende Selektion erreichen.

01:24:00.990 --> 01:24:04.710
Hier sehen Sie gerade noch, wie wir anschließend das uns vorzustellen

01:24:04.710 --> 01:24:07.070
haben, das kathiesische Produkt tatsächlich aufstellen.

01:24:07.470 --> 01:24:11.010
Dann sehen Sie, dass wir jetzt auf das Ergebnis, das ich gerade zuvor

01:24:11.650 --> 01:24:16.090
angewendet habe, erzeugt habe, da wenden wir jetzt genau das hier, den

01:24:16.090 --> 01:24:19.470
Vergleich, den ich einmal schon rot markiert hatte, bei mir, den

01:24:19.470 --> 01:24:22.530
wenden wir an, und dann erhalten wir tatsächlich das Ergebnis, unter

01:24:22.530 --> 01:24:25.110
anderem bin ich da tatsächlich, übrigens, das ist nur noch die Frau

01:24:25.110 --> 01:24:28.410
Schmidt, die zweite Passagierin jedenfalls von dem Beispiel, das wir

01:24:28.410 --> 01:24:29.510
hier haben.

01:24:31.030 --> 01:24:37.350
So, jetzt kommen wir also da müsste hier auch noch die Schleife

01:24:37.350 --> 01:24:39.070
zugemacht werden.

01:24:41.010 --> 01:24:44.010
Jetzt sagen wir uns einfach folgendes, wir nehmen das kathiesische

01:24:44.010 --> 01:24:47.950
Produkt, aber packen die gleich mit der Selektion zusammen und machen

01:24:47.950 --> 01:24:49.750
daraus eine einzige neue Operation.

01:24:50.630 --> 01:24:53.890
Statt die rechte Seite hinzuschreiben, schreibe ich die linke hin.

01:24:55.290 --> 01:24:59.390
Linke besagt also, dass wir wegbewegen,

01:25:02.690 --> 01:25:07.290
besagt also, dass wir eine Vergleichsoperation Theta wiedernehmen, so

01:25:07.290 --> 01:25:12.470
wie bei unserer Selektion, und bei der Selektion, das muss ich

01:25:12.470 --> 01:25:15.370
vielleicht noch nachtragen, wenn wir First und Business verglichen

01:25:15.370 --> 01:25:18.750
haben, dann müssen wir natürlich immer generell dafür Sorge tragen,

01:25:19.170 --> 01:25:22.110
dass die Vergleichsoperation auf den beteiligten Domänen definiert

01:25:22.110 --> 01:25:22.350
ist.

01:25:23.210 --> 01:25:26.110
Da war es tatsächlich definiert, weil beides Integerwerte waren.

01:25:26.570 --> 01:25:30.150
Aber wir müssen immer aufpassen, dass wir nicht Zigarettenraucher mit

01:25:30.150 --> 01:25:32.190
Kaffeetrinkern vergleichen.

01:25:33.770 --> 01:25:37.230
Also, das gilt auch hier, wenn wir hier ein Theta einführen, dann

01:25:37.230 --> 01:25:41.350
führen wir das Theta auch wieder auf Attributen ein, und die Domänen

01:25:41.350 --> 01:25:42.850
müssen wieder vergleichbar sein.

01:25:43.650 --> 01:25:44.890
Das ist also eine Randbedingung.

01:25:45.610 --> 01:25:51.090
So, aber dann sehen wir, wir kommen jetzt mit dieser einfacheren

01:25:51.090 --> 01:25:54.490
Formulierung aus, und dahinter steckt jetzt eine Implementierung, die

01:25:54.490 --> 01:25:58.530
baut nicht mehr das kathesische Produkt, sondern die wird immer nur

01:25:58.530 --> 01:26:03.670
ein Tupel nach dem anderen erzeugen, das für das Ergebnis als

01:26:03.670 --> 01:26:07.410
kathesisches Produkt Anwendung finden würde, schaut aber sofort nach,

01:26:07.610 --> 01:26:13.270
ob das wirklich dieses neue Tupel für das Endergebnis qualifiziert.

01:26:13.350 --> 01:26:15.510
Wenn das nicht der Fall ist, dann wird es gar nicht ins Endergebnis

01:26:15.510 --> 01:26:15.790
übernommen.

01:26:18.770 --> 01:26:20.530
So, jetzt können wir uns das auch wieder ansehen.

01:26:24.450 --> 01:26:24.890
Unsere...

01:26:26.030 --> 01:26:29.630
fast unser Beispiel von vorhin, das können wir jetzt also

01:26:29.630 --> 01:26:30.430
umformulieren.

01:26:31.250 --> 01:26:36.110
Da muss ich wieder hier nochmal die Schleife ausfüllen.

01:26:39.490 --> 01:26:43.690
Oben ist die Formulierung, die wir beispielsweise übrigens von außen

01:26:43.690 --> 01:26:44.490
reinschreiben könnten.

01:26:45.850 --> 01:26:50.390
Buchung, Ticket, und wir würden dann, und dann kommt die

01:26:50.390 --> 01:26:52.430
Selektionsbedingung noch dazu, hier haben wir noch eine weitere

01:26:52.430 --> 01:26:54.430
reingepackt, wir haben nicht gesagt, außerdem wollen wir auch nur die,

01:26:54.830 --> 01:26:56.430
für die gilt, dass das Datum der 6.

01:26:56.510 --> 01:26:56.990
August ist.

01:26:59.490 --> 01:27:02.950
Und jetzt können wir wieder sagen, wir bräuchten ja nur eine Regel

01:27:02.950 --> 01:27:07.690
anzugeben, also eine algebraische Regel, die besagt, wenn du auf ein

01:27:07.690 --> 01:27:13.290
kathetisches Produkt stößt, von zwei Relationen, und auf die wird eine

01:27:13.290 --> 01:27:16.210
Selektion angewendet, die ein Attribut aus der einen und ein Attribut

01:27:16.210 --> 01:27:19.350
aus der anderen Relation zum Inhalt hat, das ist in dem Fall die

01:27:19.350 --> 01:27:24.550
Ticketnummer in den beiden Fällen, dann verwandelt das sofort in eine

01:27:24.550 --> 01:27:25.410
Theta -Verbindung.

01:27:26.010 --> 01:27:27.250
Und das ist genau hier passiert.

01:27:27.590 --> 01:27:30.950
Sie sehen also unten die äquivalente Formulierung, die unser

01:27:30.950 --> 01:27:35.770
Optimierer dann liefern müsste, und die besagt, die Theta-Bedingung

01:27:35.770 --> 01:27:38.490
für die Verbindung ist eben der Vergleich der Ticketnummer.

01:27:39.910 --> 01:27:42.970
Und das andere, das Datum, das ist natürlich eine völlig getrennte

01:27:42.970 --> 01:27:43.970
Sache, die hat damit nichts zu tun.

01:27:44.310 --> 01:27:46.570
Die wird dann auf das Endergebnis angewendet, das heißt, wir nehmen

01:27:46.570 --> 01:27:50.510
das Endergebnis und selektieren daraus nochmal das Datum.

01:27:50.790 --> 01:27:54.170
Jetzt kommen noch ein paar clevere Leute, die sagen, ach, das geht

01:27:54.170 --> 01:27:58.690
noch viel besser, schieb doch die Selektion, denn die ist ja nur auf

01:27:58.690 --> 01:28:01.550
einem Attribut von Buchung definiert.

01:28:02.070 --> 01:28:03.770
Schieb doch die Selektion zu der Buchung gleich hin.

01:28:05.270 --> 01:28:08.010
Dann gehen wir nämlich gar nicht mehr mit der vollen Buchungsrelation

01:28:08.010 --> 01:28:09.950
rein, sondern dann gehen wir überhaupt nur noch mit dem selektierten

01:28:09.950 --> 01:28:10.650
Teil rein.

01:28:11.130 --> 01:28:13.490
Das heißt, jetzt fange ich an, das zu verzahnen.

01:28:13.850 --> 01:28:16.910
Ich warte nicht bis zum Ende, um zu komprimieren, sondern ich fange

01:28:16.910 --> 01:28:18.570
schon so früh als möglich an zu komprimieren.

01:28:19.350 --> 01:28:22.730
Unsere Optimierer, die gehen alle darauf los, möglichst früh zu

01:28:22.730 --> 01:28:23.190
komprimieren.

01:28:23.310 --> 01:28:26.630
Also tatsächlich doch mehr zu verzahnen, nicht erst Ausdehnung, dann

01:28:26.630 --> 01:28:29.790
Komprimierung, sondern Ausdehnung und gleich gucken, ob ich auch dabei

01:28:29.790 --> 01:28:30.550
komprimieren kann.

01:28:31.690 --> 01:28:36.570
Also könnte ich noch hier diese Selektion noch vor das Buchung

01:28:36.570 --> 01:28:36.890
schieben.

01:28:37.370 --> 01:28:39.170
Und das macht unsere Optimierer, da brauchen wir uns selber gar nicht

01:28:39.170 --> 01:28:39.690
drum zu kümmern.

01:28:42.310 --> 01:28:44.670
Das Endergebnis ist nicht überraschend.

01:28:44.930 --> 01:28:48.370
Natürlich dasselbe, weil zufällig bei dem... nee, halt, da hat es ein

01:28:48.370 --> 01:28:51.870
anderes Endergebnis beim zweiten Flug, dass der Weihnachten nicht mehr

01:28:51.870 --> 01:28:52.390
die Frau schminkt.

01:28:56.020 --> 01:29:00.760
So, aber eigentlich haftet unserem Beispiel sogar eine Besonderheit

01:29:00.760 --> 01:29:00.980
an.

01:29:01.560 --> 01:29:05.240
Das Theta, das wir in der Verbindungsoperation verwendet haben, war

01:29:05.240 --> 01:29:06.040
die Gleichheit.

01:29:06.980 --> 01:29:09.740
Es ist nicht zwingend, die Gleichheit zu verwenden, aber die

01:29:09.740 --> 01:29:11.740
Gleichheit kommt besonders häufig vor.

01:29:13.160 --> 01:29:17.240
Und man spricht infolgedessen erstmal schon von Gleich, von der

01:29:17.240 --> 01:29:22.400
sogenannten Gleich oder Equijoin, Gleichverbindung, weil sie eine

01:29:22.400 --> 01:29:23.080
Sonderrolle hat.

01:29:23.080 --> 01:29:25.460
Aber wenn wir uns das noch genauer ansehen, dann haben wir ja schon

01:29:25.460 --> 01:29:27.520
ein Ergebnis gesehen, wir können auch nochmal zurückgehen übrigens,

01:29:28.020 --> 01:29:33.400
dann sehen wir das da und das da sind ja gleiche Werte.

01:29:34.120 --> 01:29:35.320
Also da ist auch noch Redundanz drin.

01:29:36.040 --> 01:29:38.860
Und also, wir sollten, das haben wir ja schon gesehen, die

01:29:38.860 --> 01:29:41.660
Informationen so schnell als möglich komprimieren, also wir werden

01:29:41.660 --> 01:29:44.640
doch jetzt nicht hier an dieser Stelle, wo das so trivial ist, diese

01:29:44.640 --> 01:29:45.600
Redundanz mitschleppen.

01:29:46.240 --> 01:29:49.880
Also werden wir jetzt noch ein bisschen spezifischer werden und sagen,

01:29:50.020 --> 01:29:54.320
wir schaffen einen Spezialfall der Theta-Verbindung und dieser

01:29:54.320 --> 01:30:01.880
Spezialfall besteht darin, dieser Spezialfall besteht darin, dass ich

01:30:01.880 --> 01:30:07.060
redundante Spalten eliminiere aus dem Endergebnis.

01:30:07.940 --> 01:30:10.800
Und jetzt kann ich noch einen Schritt weiter gehen und sagen, in den

01:30:10.800 --> 01:30:15.040
meisten Fällen sind eigentlich solche redundanten Spalten sogar gleich

01:30:15.040 --> 01:30:16.220
benannt in der Relation.

01:30:16.740 --> 01:30:20.920
Nicht ganz zwingend, es gibt schon Ausnahmen, aber sehr häufig sind

01:30:20.920 --> 01:30:22.000
sie gleich benannt.

01:30:22.520 --> 01:30:24.840
Und dann komme ich zu der Definition der sogenannten natürlichen

01:30:24.840 --> 01:30:28.280
Verbindung, das ist so der, wenn man überhaupt über Relationale

01:30:28.920 --> 01:30:31.780
Systeme oder Relationale Operatoren spricht, dann lässt man immer so

01:30:31.780 --> 01:30:35.160
beiläufig das Wort natürliche Verbindung oder Natural Joint fallen und

01:30:35.160 --> 01:30:37.820
dann sind sie als absoluter Kenner der Materie ausgewiesen.

01:30:38.700 --> 01:30:43.100
Das ist also, wenn man will, die zentrale Operation des Relationalen

01:30:43.100 --> 01:30:47.140
Modells beim Ausdehnen in die Datenbasis hinaus.

01:30:48.600 --> 01:30:55.760
Und das sieht eben so aus, wir nehmen das kathetische Produkt, wir

01:30:55.760 --> 01:31:00.620
betrachten die Wertegleichheit von namensgleichen Attributen und dann

01:31:00.620 --> 01:31:03.140
werden die redundanten Spalten herausprojiziert.

01:31:06.120 --> 01:31:06.880
Und jetzt haben wir...

01:31:10.120 --> 01:31:14.020
Jetzt haben wir eben nochmal die Formulierung, jetzt sehen Sie, jetzt

01:31:14.020 --> 01:31:20.480
ist im Vergleich zu zuvor, ist jetzt hinter unserer Schleife das B

01:31:20.480 --> 01:31:22.500
-Ticketnummer gleich, T-Ticketnummer verschwunden.

01:31:23.600 --> 01:31:26.720
Jetzt sagen wir einfach an dieser Stelle, wenn du auf das Symbol

01:31:26.720 --> 01:31:29.520
dieser Spalte stößt, das ist natürlich Verbindung, wissen wir jetzt

01:31:29.520 --> 01:31:33.420
alle, und da gehst du mal rein in das Schema und schaust nach, in

01:31:33.420 --> 01:31:38.160
welchen Attributen stimmen denn diese beiden Relationen überein, das

01:31:38.160 --> 01:31:40.720
ist in dem Fall Ticketnummer, und dann sagt man sich sofort, ah, dann

01:31:40.720 --> 01:31:44.660
muss der also die Wertegleichheit unter den jeweiligen Attributen

01:31:44.660 --> 01:31:45.680
Ticketnummer betrachten.

01:31:46.940 --> 01:31:50.100
Das ist jetzt eine enorm einfache und elegante Formulierung.

01:31:51.300 --> 01:31:54.000
Wir werden zwar sehen, dass hinterher unsere Anfragesprache SQL

01:31:54.000 --> 01:31:56.240
eigentlich da gar nicht so schrecklich viel Rücksicht darauf nimmt,

01:31:56.800 --> 01:31:58.980
aber von der Algebra her ist das wunderbar.

01:31:59.080 --> 01:32:01.300
Jetzt können Sie ganz kurze Formeln anschreiben.

01:32:03.580 --> 01:32:06.600
Und da kommt, eben wie wir sehen, jetzt ist die eine Ticketnummer

01:32:06.600 --> 01:32:07.060
verschwunden.

01:32:07.420 --> 01:32:10.900
Vorher hatten wir hier noch, glaube ich, an der Stelle noch eine

01:32:10.900 --> 01:32:13.080
Ticketnummer, die ist jetzt verschwunden.

01:32:16.220 --> 01:32:18.500
Und jetzt können wir noch eine formale Definition angeben.

01:32:19.520 --> 01:32:21.800
Da will ich mich nicht lang auslassen, da steht eigentlich im Grunde

01:32:21.800 --> 01:32:26.240
genommen genau das drin, was ich Ihnen erklärt habe, nämlich, da sind

01:32:26.240 --> 01:32:30.500
B, die Bs sind die redundanten Attribute, A und C sind die nicht

01:32:30.500 --> 01:32:35.880
redundanten Attribute, also steht im Endergebnis die Attribute A und C

01:32:35.880 --> 01:32:41.400
drin und die von B tauchen nur einmal auf und ansonsten haben wir eben

01:32:41.400 --> 01:32:44.540
die Übereinstimmung, die Gleichheit an dieser Stelle.

01:32:46.040 --> 01:32:48.920
Und wenn Sie das etwas algebraisch formuliert haben wollen, dann sehen

01:32:48.920 --> 01:32:53.300
Sie unten noch R, S, da haben Sie sich auch zwischen R und S nochmal

01:32:53.300 --> 01:32:57.680
die Schleife vorzustellen, dann wird eben an dieser Stelle, ist das

01:32:57.680 --> 01:33:02.000
die größte Relation, für die gilt, dass das Ergebnis noch eine

01:33:02.000 --> 01:33:05.600
Teilmenge aus dieser projizierte auf die projizierte katholische

01:33:05.600 --> 01:33:06.160
Produkt ist.

01:33:06.620 --> 01:33:10.400
Ja, wir sind noch nicht ganz fertig mit der natürlichen Verbindung,

01:33:10.620 --> 01:33:14.000
denn so wie sie definiert ist, kann man auch ganz böse reinfallen.

01:33:14.440 --> 01:33:16.800
Und wie man reinfallen kann, das zeige ich Ihnen dann morgen.

01:33:56.460 --> 01:33:56.600
Vielen Dank.