Datenbank-Design

[Kalle_]

Hallöle,

ich glaube, ich habe einen falschen Ansatz, weil die Pflege der Daten so aufwendig ist. Es muss doch einfacher gehen, aber ich komme nicht drauf.

Der Fall:
---------
An einer Fachmesse nehmen 60 Aussteller und 400 Besucher teil, allesamt vorher angemeldet. PHP soll Gesprächstermine machen.

Jeder Aussteller kann ankreuzen, mit welchem Besucher er sprechen möchte und jeder Besucher, mit welchem Aussteller. Theoretisch wären das 400x60 = 24.000 Paarungen, in der Praxis tatsächlich 6.000.

Die Besucher können Priorität 1 und 2 vergeben, die Aussteller Priorität 3.

Pro Paarung richte ich einen Datensatz ein als Arbeitsvorrat für das Terminierungsprogramm.

Und um die Pflege geht es: Besucher B1 wünschte Aussteller A1 zu sprechen, ein Datensatz wurde angelegt:

B1-A1: pr1=1 pr2=0 pr3=0

Nun möchte auch Aussteller A1 Besucher B1 sprechen. KLar, der Satz muss ergänzt werden: pr3=1

Jetzt mache ich einen INSERT, um den Satz anzulegen. Ist schon da, also Fehler und nächster Zugriff: UPDATE.

Version 2: Ich frage, Satz vorhanden? und mache dann gezielt ein UPDATE oder INSERT. Das sind AUF JEDEN Fall 2 Zugriffe, Version 1 kommt oft mit EINEM Zugriff aus.

So weit, so gut. Nun können aber auch Wünsche zurückgenommen werden, indem der Haken (checkbox) aus der Liste entfernt wird. Wie hier bereits diskutiert, gibt es per <form> keine DIREKTE Möglichkeit, einen weggenommenen Haken zu erkennen.

Ich muss also sämtliche Sätze des ändernden Ausstellers mit den verbliebenen Haken vergleichen und fehlende Haken in die Änderung von prio_3=0 umsetzen. Wenn dann auch prio_1=0 UND prio_2=0 muss der Satz tatsächlich gelöscht werden.

Zugriffe über Zugriffe auf die Datenbank, und die Programmierung sehr aufwendig und damit fehlerträchtig.

Wie gesagt, der Lösungsansatz ist wohl nicht optimal. Wäre für eine Idee oder kluge Frage dankbar, bin sicher etwas betriebsblind.

LG Kalle

[Bio]

Sup!

Häh?

Gruesse,

Bio

[Kalle_]

Sup!

Häh?

Gruesse,

Bio

Jeder Kommentar freut mich, durch dich fühle mich gegrüßt und bin nicht mehr so alleine.

LG Kalle

[Tom]

Hello Kalle,

Sup!

Häh?

Gruesse,

Bio

Jeder Kommentar freut mich, durch dich fühle mich gegrüßt und bin nicht mehr so alleine.

Mir ging das im ersten Moment genauso.
Ich habe mich dann aber gefragt, was Du eigentlich ereichen wolltest und da ich da schon einige Erfahrungen habe (vielleicht hat BIO ja keine?), habe ich sofort erkannt, dass Dein Ansatz falsch ist. Deine Klartext-Beschreibung war ja aussagefähig genug, was mal wieder beweist, wie wichtig Klartext ist ;-))

BIO, Du solltest lieber mal wieder ein paar Kekse backen und die gegen Spende für Self oder sonstwas hier anbieten. *grins*

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Daniel]

Hi,

B1-A1: pr1=1 pr2=0 pr3=0

also sieht deine tabelle in etwa so aus:

-------------------------------------------------
| id_besucher | id_aussteller | pr1 | pr2 | pr3 |
-------------------------------------------------

geh ich da richtig in der annahme?

Ich muss also sämtliche Sätze des ändernden Ausstellers mit den
verbliebenen Haken vergleichen und fehlende Haken in die Änderung von
prio_3=0 umsetzen.

um wegen der löschung den datentransfer gering zu halten könntest du
auch einfach ein "DELET FROM 'tbl_name' WHERE pr1=0 AND pr2=0 AND pr3=0"
machen. Vorausgesetzt meine annahme des aufbaus der tabelle ist korekt

MfG

[Kalle_]

also sieht deine tabelle in etwa so aus:

---

| id_besucher | id_aussteller | pr1 | pr2 | pr3 |

Genau, und zusätzlich noch std_nr, das ist der evtl. vereinbarte Termin so wie in einem Stundenplan.

um wegen der löschung den datentransfer gering zu halten könntest du
auch einfach ein "DELET FROM 'tbl_name' WHERE pr1=0 AND pr2=0 AND pr3=0"
machen. Vorausgesetzt meine annahme des aufbaus der tabelle ist korekt

Ja, das ist der lezte Schritt, nachdem pr1, pr2 und pr3 korrekt (zurück)gesetzt wurden.

Das Setzen / zurücksetzen von pr1, pr2 und pr3 macht den Aufwand.

LG Kalle

[Tom]

Hello,

Und um die Pflege geht es: Besucher B1 wünschte Aussteller A1 zu sprechen, ein Datensatz wurde angelegt:

B1-A1: pr1=1 pr2=0 pr3=0

Nun möchte auch Aussteller A1 Besucher B1 sprechen. KLar, der Satz muss ergänzt werden: pr3=1

Ich fasse nochmal zusammen:

Es gibt Besucher   (B)
Es gibt Aussteller (A)
und es gibt Zeit   (Z)

Die Gruppierung heißt also:  B spricht A um Z

Du benötigst also drei Indexe:

B - A           Ein Gespräch zwischen Aussteller und Besucher reicht

A - Z           Wenn A um Z schon belegt ist, kann er
                  gleichzeitig keinen zweiten Termin wahrnehmen

B - Z           Wenn B um Z schon belegt ist, kann er
                  gleichzeitig keinen zweiten Termin wahrnehmen

Durch Terminwunsch und Ausweichterminwunsch kannst Du ggf. die Sache entkrampfen.
Denn es gelten die rahmenbedingungen: nicht jeder kann zu jeder Zeit.

Du müsstest also ein Raster im Maß der Gesprächsterminlänge bilden. Das ist dann Quantisierung. Es wäre auch möglich, einem Pärchen mehrere zusammenhängende Einheiten zu geben. usw.

Aber ich denke, die Vorgehensweise sollte Dir nun klar sein.

Zur Berechnung von 6000 Paarungen (oder Tripelungen) benötigt man keine Datenbank, sondern einen Arbeisspeicher mit z.B.

(6000 * 2 * 3 Byte) + (6000 * 32 Byte) pro Arrayelement

=> ca. 196kByte

Das sollte PHP locker zur Verfügung haben.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Kalle_]

Hello,

Ich fasse nochmal zusammen:

Es gibt Besucher   (B)
Es gibt Aussteller (A)
und es gibt Zeit   (Z)

Ja, und noch Prioritäten, denn nicht alle 6.000 Gesprächswünsche können erfüllt werden. Also werden zunächst die mit Priorität 1 ... und so weiter.

Die Gruppierung heißt also:  B spricht A um Z

Ja, genau.

Du benötigst also drei Indexe:

B - A           Ein Gespräch zwischen Aussteller und Besucher reicht

A - Z           Wenn A um Z schon belegt ist, kann er
                  gleichzeitig keinen zweiten Termin wahrnehmen

B - Z           Wenn B um Z schon belegt ist, kann er
                  gleichzeitig keinen zweiten Termin wahrnehmen

Durch Terminwunsch und Ausweichterminwunsch kannst Du ggf. die Sache entkrampfen.
Denn es gelten die rahmenbedingungen: nicht jeder kann zu jeder Zeit.

Du müsstest also ein Raster im Maß der Gesprächsterminlänge bilden.

Ja, das wird Slot genannt. Jeder Slot hat eine Nummer und eine zeit_von, zeit_bis.

Es wäre auch möglich, einem Pärchen mehrere zusammenhängende Einheiten zu geben. usw.

Ja, gibt es sogar, Workshops mit mehreren Teilnehmern. Aber das ist eine andere Baustelle, beeinflusst jedoch die Restzeit der Besucher.

Aber ich denke, die Vorgehensweise sollte Dir nun klar sein.

Lass mich drüber nachdenken, ob die Datenpflege einfacher wird. Das war ja das Hauptproblem.

Zur Berechnung von 6000 Paarungen (oder Tripelungen) benötigt man keine Datenbank, sondern einen Arbeisspeicher mit z.B.

(6000 * 2 * 3 Byte) + (6000 * 32 Byte) pro Arrayelement

=> ca. 196kByte

Das sollte PHP locker zur Verfügung haben.

Ja, gute Idee, geht sicher schneller, muss dann aber in der DB gespeichert werden, damit der "Stundenplan" zu beliebiger Zeit abrufbar und druckbar ist.

Danke dir.

LG Kalle

[Tom]

Hello,

Ja, gute Idee, geht sicher schneller, muss dann aber in der DB gespeichert werden, damit der "Stundenplan" zu beliebiger Zeit abrufbar und druckbar ist.

Ergebisse einer Berechnung in einer DB zu speichern sollte doch nicht das Problem bedeuten.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

Jeder Aussteller kann ankreuzen, mit welchem Besucher er sprechen möchte und jeder Besucher, mit welchem Aussteller. Theoretisch wären das 400x60 = 24.000 Paarungen, in der Praxis tatsächlich 6.000.

wenn ich dich richtig verstanden habe, dann geht es dir darum schon vorher entscheiden zu können, ob du einen insert oder update machen musst. dies könnte man über den klient lösen, in dem die aussteller/besucher ihre daten eingeben. ich greife einfach mal ins leere und hoffe, dass:

1. besucher/aussteller sich identifizieren
2. die Infos bekommen, wo sie sich schon eingetragen haben und wo nicht.

sollte beides der fall sein, dann kann man beim ausfüllen des formulars eine zusatzinformation mit übermitteln, ob der datensatz schon vorhanden ist oder nicht. schließlich wird auf die datenbank sowieso schon zugegriffen, wenn man die Infos bekommt, beim wenn man sich anmelden kann und wo man es schon getan hat.

Ilja

[dedlfix]

echo $begrüßung;

dann kann man beim ausfüllen des formulars eine zusatzinformation mit übermitteln, ob der datensatz schon vorhanden ist oder nicht.

Dies hat nur einen Haken: A hat grad die Daten abgefragt und überlegt noch... B hat die gleichen Daten grade bearbeitet und sendet sie während A noch überlegt an die DB. Wie löst man nun den Konflikt auf?
Das Problem existiert eigentlich überall bei solchen Mehruseranwendungen, nur dass hier noch erschwerend hinzukommt, dass, wenn [1] man sich auf die Daten von A verlässt, gelegentlich doch die falschen Befehle an die DB sendet. Und dann such mal so einen sporadischen Fehler, der in der Einzelplatzumgebung des Programmierers nicht auftritt...

echo "$verabschiedung $name";

[1] "dass wenn" klingt nicht gut. Wie löst man das sprachlich eleganter?

[Ilja]

yo,

Dies hat nur einen Haken: A hat grad die Daten abgefragt und überlegt noch... B hat die gleichen Daten grade bearbeitet und sendet sie während A noch überlegt an die DB. Wie löst man nun den Konflikt auf?

wenn das der einzige haken ist, dann sollte es lösbar sein. es macht ohnehin sinn, die eine beziehungstabelle in zwei aufzuteilen, eine für die aussteller und eine für die besucher.

Ilja

[Tom]

Hello,

Dies hat nur einen Haken: A hat grad die Daten abgefragt und überlegt noch... B hat die gleichen Daten grade bearbeitet und sendet sie während A noch überlegt an die DB. Wie löst man nun den Konflikt auf?

wenn das der einzige haken ist, dann sollte es lösbar sein. es macht ohnehin sinn, die eine beziehungstabelle in zwei aufzuteilen, eine für die aussteller und eine für die besucher.

Den Zugriffskonflikt kann man in einem verbindungslosen Protokoll nicht wirklich lösen, sondern nur mit einer optimistic-locking-Strategie, und da bleibt eignetlich nur "academic locking" (= Conflict-Counter) behandeln. Behandeln heißt, dass einer der Partner im Konfliktfalle nochmal arbeiten muss. Wenn man in einem verbindungsorientierten Protokoll arbeitet, kann man auch mit pessimistic locking arbeiten, was das Bearbeiten der Datensätze füe einen zweiten User unmöglich machen würde, solange der erste daran arbeitet.

Der eindeutige Schlüssel, der gefunden werden soll, besteht aus den drei Teilen A-B-Z

A = Aussteller
B = Besucher
Z = Zeitpunkt (Slotkennung)

wobei zusätzlich die Teilschlüssel

A-B  (B-A)
A-Z
B-Z

eigene Sperrfunktion erhalten.

Es ist also nur ein Datensatz mit A(n)-B(m)-Z(x) möglich
Es ist aber auch nur ein Datensatz mit dem Teilschlüssel

A(n)-B(m)
  A(n)-Z(x)
  B(m)-Z(x)

möglich

Dass ein Aufteilen in zwei oder mehr Tabellen notwendig wäre, kann ich nicht erkennen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

Den Zugriffskonflikt kann man in einem verbindungslosen Protokoll nicht wirklich lösen, sondern nur mit einer optimistic-locking-Strategie, und da bleibt eignetlich nur "academic locking" (= Conflict-Counter) behandeln.

nicht immer, wenn man davon ausgehen kann, dass jeder besucher einmalig ist. schließlich sollte er ja nicht gleichzeitig an zwei computer seine eingaben machen. und andere werden auf den datensatz sowieso keinen zugriff haben. problematisch wird es nur bei den ausstellern, wo eventuell mehrere mitarbeiter zugang haben könnten. aber das müsste erst noch einmal geklärt werden, bevor anfängt datensätze zu sperren. und selbst wenn, wäre das nicht so schlimm.

Der eindeutige Schlüssel, der gefunden werden soll, besteht aus den drei Teilen A-B-Z

nein, die zeit muss hier schon mal kein schlüssel sein, es sein den sie können mehrere termine ausmachen. davon gehe ich aber mal nicht aus.

Dass ein Aufteilen in zwei oder mehr Tabellen notwendig wäre, kann ich nicht erkennen.

es geht nicht um notwendig, sondern was eine gute lösung für ihn ist. so gibt es verschiedene möglichkeiten. abwägen muss er am ende, was seiner meinung nach die beste ist. ein voreil zweier tabellen wäre zum beispiel das bessere locking-verhalten. Austeller und benutzer könnten sich nicht ins gehege kommen.

Ilja

[Tom]

Hello,

Den Zugriffskonflikt kann man in einem verbindungslosen Protokoll nicht wirklich lösen, sondern nur mit einer optimistic-locking-Strategie, und da bleibt eignetlich nur "academic locking" (= Conflict-Counter) behandeln.

nicht immer, wenn man davon ausgehen kann, dass jeder besucher einmalig ist. schließlich sollte er ja nicht gleichzeitig an zwei computer seine eingaben machen. und andere werden auf den datensatz sowieso keinen zugriff haben. problematisch wird es nur bei den ausstellern, wo eventuell mehrere mitarbeiter zugang haben könnten. aber das müsste erst noch einmal geklärt werden, bevor anfängt datensätze zu sperren. und selbst wenn, wäre das nicht so schlimm.

Der eindeutige Schlüssel, der gefunden werden soll, besteht aus den drei Teilen A-B-Z

nein, die zeit muss hier schon mal kein schlüssel sein, es sein den sie können mehrere termine ausmachen. davon gehe ich aber mal nicht aus.

Selbstverständlich ist die Zeit (bzw die Slot-Kennung) ein Schlüsselbestandteil.
Und zwar, wie schon erwähnt, in den Unique-Kombinationsschlüsseln (A-Z) und (B-Z).
Weder ein Besucher noch ein Aussteller kann zur selben Zeit an zwei Orten sein.

Den Zugriffskonflikt hat man auch aus diesem Grunde der mehrfachen Schlüssel.
Es können sowohl Aussteller als auch Besucher die Ressourcen vergeben. Aus dem eben oben erwähnten Zeit-Konflikt kann auch ein Zugriffskonflikt entstehen, der abgefangen werden muss. Wie soetwas in einem verbindungslosen Protokoll funktioniert habe ich ja schon erläutert.

Der Einfachheit halber kann man das hier aber auch über die Schlüssel regeln, da Datensätze nur hinzugefügt und nicht verändert werden sollen. Den Zugriffskonflikt gibt's ja nur bei der Veränderung vorhandener Daten.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

Selbstverständlich ist die Zeit (bzw die Slot-Kennung) ein Schlüsselbestandteil.
Und zwar, wie schon erwähnt, in den Unique-Kombinationsschlüsseln (A-Z) und (B-Z).

ein Unique-feld muss nicht zwangsweise auch bestandteil eines schlüssels sein, zumal der auch noch das kriterium not null erfüllt. ein schlüssel dient nur dazu, einen datensatz eindeutig zu identifizieren und dazu braucht man die zeit in diesem falle nicht. es müsste nur teil des keys sein, falls die gleichen austeller/besucher mehrere termine ausmachen. ansonsten würde die aussteller/besucher id ausreichen oder aber ein künstlicher schlüssel. auch wenn die zeit unique ist, so ist sie doch nur ein attribut.

Weder ein Besucher noch ein Aussteller kann zur selben Zeit an zwei Orten sein.

das mag so sein, ist aber trotzdem kein argument für einen schlüssel. desweiteren würde dazu eine zeitangabe nicht reichen, sondern man bräuchte einen start und endzeiptunkt. schließlich macht es wenig sinn, wenn man jede sekunde einen neuen termin haben kann.

Ilja

[Tom]

Hello,

Selbstverständlich ist die Zeit (bzw die Slot-Kennung) ein Schlüsselbestandteil.
Und zwar, wie schon erwähnt, in den Unique-Kombinationsschlüsseln (A-Z) und (B-Z).

ein Unique-feld muss nicht zwangsweise auch bestandteil eines schlüssels sein,

Jedes Feld, das in einen Index aufgenommen wird, ist auch Bestandteil eines Schlüssels, nämlich des des Index. Über den Index (auch Schlüssel genannt) kann man die Datensätze auffinden. Wenn dieser Index primär ist, identifiziert er auch den Datensatz.

Dies hier ist übrigens ein gutes Beispiel dafür, dass ein Unique Key nicht auch gleichzeitig ein (gültiger) Primärschlüssel sein muss, und dass ein Datensatz sogar drei Unique Keys haben kann. Er sollte aber (nach gültiger Regel) neu _einen_ Primärschlüssel haben.

Der Unterschied zwischen den beiden (Unique Key und Primary Key) ist die Bindung an die Daten. Ein Primary Key hat eine unbedingte _Bindung_ an den Datensatz, ist aber niemals selber Bestandteil der Daten des Datensatzes. Unsere drei Schlüssel hier sind aber Bestandteil der Daten.

zumal der auch noch das kriterium not null erfüllt. ein schlüssel dient nur dazu, einen datensatz eindeutig zu identifizieren

Nein. Ein Schlüssel muss nicht primär sein.

und dazu braucht man die zeit in diesem falle nicht. es müsste nur teil des keys sein, falls die gleichen austeller/besucher mehrere termine ausmachen. ansonsten würde die aussteller/besucher id ausreichen oder aber ein künstlicher schlüssel. auch wenn die zeit unique ist, so ist sie doch nur ein attribut.

Diesen Absatz versteh ich jetzt nicht. Bahnhof?

[...]

das mag so sein, ist aber trotzdem kein argument für einen schlüssel. desweiteren würde dazu eine zeitangabe nicht reichen, sondern man bräuchte einen start und endzeiptunkt. schließlich macht es wenig sinn, wenn man jede sekunde einen neuen termin haben kann.

Wenn Du doch wenigstens gelesen hättest, was ich geschrieben habe...

Die Spalte Z ist die Slotkennung in der vorgesehenen Quantisierung. Darum kommst Du nicht drum herum, wenn das System nicht zu kompliziert werden soll. Alternative wären zwei Spalten (von und  bis), um den gebuchten Terminbereich zu kennzeichnen.

Der lässt sich aber mMn nicht durch einen einfachen Nachschlage-Index (einer der auf statische Datenbestandteile geht) abfangen, sondern würde einen berechneten benöten. Den unterstützt aber MySQL nicht, oder?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

ich muss nochmal auf deinen ersten beitrag hier eingehen.

<zitat> Der eindeutige Schlüssel, der gefunden werden soll, besteht aus den drei Teilen A-B-Z </zittat>

ich denke, wir reden über diesen primär-schlüssel. und solange besucher und veranstallter sich nicht mehrmals treffen wollen, solange braucht man nur A/B als zusammengestzten schlüssel, sprich Z ist hier überflüssig. auch macht es meiner meinung nach sinn, die buchungen von den aussteller von den buchungen der besucher in zwei tabellen zu trennen. aber das ist sicherlich geschmackssache.

ein Unique-feld muss nicht zwangsweise auch bestandteil eines schlüssels sein,

Jedes Feld, das in einen Index aufgenommen wird, ist auch Bestandteil eines Schlüssels, nämlich des des Index. Über den Index (auch Schlüssel genannt) kann man die Datensätze auffinden. Wenn dieser Index primär ist, identifiziert er auch den Datensatz.

ein index ist sicherlich ein schlüssel, aber ich sagte ein Unique-feld, vielmehr ein Unique constraint ist nicht zwangsweise auch bestandteil eines schlüssel. ich habe mich bei mysql schon mal darauf aufgehangen, weil mysql --> immer <-- einen index zu einem Unique contraint anlegen will. dass ist aber mysql spezifisch und ziemlich dumm. ein Unique constraint ist nämlich kein index, sondern benutzt diesen nur, um den contraint zum beispiel bei 1 millionen datensätze schneller ausführen zu können. aber es würde auch ohne einen index gehen, oder wie oracle es macht, erst einmal nachschauen, ob ich nicht schon einen index auf die entsprechende spalte habe. sollte dies nämlich der fall sein, so brauche ich nicht noch zusätzlich einen anlegen. ist ja auch irgendwie albern, zwei indexe auf eine und dieselbe spalte zu haben. und genau das versucht mysql und wenn ich mich nicht ganz täusche und der name des vorhandenen indexes der gleiche ist, den mysql durch den unique contraint anlegen will, dann gibt es eine fehlermeldung (nicht ganz sicher).

Dies hier ist übrigens ein gutes Beispiel dafür, dass ein Unique Key nicht auch gleichzeitig ein (gültiger) Primärschlüssel sein muss

hat auch keiner behauptet. allerdings ist es meiner meinung nach etwas verwässert von einen unique key zu reden. sicherlich löst mysql das so, ich würde aber von einem unique constraint reden.

Der Unterschied zwischen den beiden (Unique Key und Primary Key) ist die Bindung an die Daten. Ein Primary Key hat eine unbedingte _Bindung_ an den Datensatz, ist aber niemals selber Bestandteil der Daten des Datensatzes. Unsere drei Schlüssel hier sind aber Bestandteil der Daten.

natürliche schlüssel sind sicherlich auch bestandteil der daten, obwohl ich selbst solche schlüssel nicht verwenden würde. aber es gibt trotzdem noch einen weiteren unterscheid, zwischen Unique und primary key. die unique spalte wird auch NULL werte mit aufnehmen, der PK würde das nicht tun.

grundsätzlich gilt für einen PK, er muss den datensatz eindeutig identifizieren, sprich er besitzt zwei contraints, NOT NULL und UNIQUE. so und nicht anders ist meiner meinung nach ein PK definiert. und dabei ist von index erst einmal keine rede, auch wenn es sinn macht, immer automatisch durch das dbms einen anzulegen.

Ilja

[fanelf.de]

Und um die Pflege geht es: Besucher B1 wünschte Aussteller A1 zu sprechen, ein Datensatz wurde angelegt:

Nun möchte auch Aussteller A1 Besucher B1 sprechen. KLar, der Satz muss ergänzt werden: pr3=1

hier liegt schon der gedankliche fehler: wer will wen sprechen?
A=B oder B=A ? die richtung ist wesentlich. hierfür benötigst du 2 tabellen.

1. tab Austellerstamm
2. tab Besucherstamm
3. tab Aussteller-Besucher Bewegung (Zeit Ausstellerprio)
4. tab Besucher-Aussteller Bewegung (Zeit Besucherprio)

die resultierenden termine können dann durch join der 3. und 4. tab ermittelt werden.