DB-Modell für eine Software

[jobo]

Ein Constraint definiert eine logische Regel, die hier in Deinem Fall die Fremdschlüsselbeziehung definiert (foreign key constraint)
Physikalisch reichen auch Deine "Felder", sie ermöglichen technisch die Verknüpfung, aber keine Prüfung durch den Server.

[AlexII]

Zitat:

Zitat von jobo (Beitrag 1284446)

Ein Constraint definiert eine logische Regel, die hier in Deinem Fall die Fremdschlüsselbeziehung definiert (foreign key constraint)
Physikalisch reichen auch Deine "Felder", sie ermöglichen technisch die Verknüpfung, aber keine Prüfung durch den Server.

Und was prüft der Server?

[Perlsau]

Zitat:

Zitat von AlexII (Beitrag 1284441)

Zitat:

Zitat von mkinzler (Beitrag 1284440)

Ja, durch die Fremdschlüssel (fk_person_id, fk_tagungs_id)

Und die befinden sich in der tbl_vt? Dann können die id_vtperson und id_vttagung weg? Und was hat dann Persau gemeint?

Um alle Klarheiten zu beseitigen, unten eine Grafik, schnell mal mit Access zusammengewurstelt. Die Tabelle besitzt einen PrimaryKey (PK) über zwei Felder. Das schützt einerseits davor, dieselbe Kombination mehr als einmal eingeben zu können und zweitens wird die Kombination Person/Tagung dadurch indiziert und so schneller gefunden. Die angehängte Zip-Datei enthält das Access-Beispiel.

[mkinzler]

Zitat:

Und was prüft der Server?

Im Minimalfall, ob der referenzierte Datensatz existiert.

[jobo]

Zitat:

Zitat von AlexII (Beitrag 1284447)

Und was prüft der Server?

Der Server prüft ob die Regel eingehalten wurde.
Also wenn Du einen Foreign Key Constraint definierst, prüft der Server die Eingabewerte und erzeugt einen Fehler, wenn Werte eingetragen werden, die die Regel verletzen.
Das ist das Wesen (ein Teil)von relationalen Datenbanken.
Der Server garantiert die Einhaltung bestimmter Regeln. Deshalb kann man am Ende auf solchen Teilen eine Kontoverwaltung oder so machen und nachts trotzdem ruhig schlafen.

[AlexII]

Zitat:

Zitat von Perlsau (Beitrag 1284448)

Zitat:

Zitat von AlexII (Beitrag 1284441)

Zitat:

Zitat von mkinzler (Beitrag 1284440)

Ja, durch die Fremdschlüssel (fk_person_id, fk_tagungs_id)

Und die befinden sich in der tbl_vt? Dann können die id_vtperson und id_vttagung weg? Und was hat dann Persau gemeint?

Um alle Klarheiten zu beseitigen, unten eine Grafik, schnell mal mit Access zusammengewurstelt.

Vielen, vielen Dank!!!

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284434)

Grundsätzlch ja, aber wozu benötigst du id_vtPerson und id_vtTagung?

Jah... habe eben in Ruhe bisschen nachgedacht, stimmt... drei IDs in einer Tabelle ist ja voller Quatsch. Ich meine IDs in dem Sinne wie ich es meinte, mit Autoincrement usw. :roteyes:

[mkinzler]

Auf dieses Feld kannst Du eigentlich auch verzichten und die beiden anderen Felder als zusammengesetzten Primärschlüssel definieren, dann kann sich niemand mehrmals für sie selbe Veranstaltung anmelden.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284456)

Auf dieses Feld kannst Du eigentlich auch verzichten und die beiden anderen Felder als zusammengesetzten Primärschlüssel definieren, dann kann sich niemand mehrmals für sie selbe Veranstaltung anmelden.

Ok... muss nur rausfinden wie. :gruebel:

[mkinzler]

SQL-Code:

CREATE TABLE TagungsTeilnehmer(
  Person Integer,
  Tagung Integer,
  PRIMARY KEY( Person, Tagung),
  FOREIGN KEY( Person) REFERENCES Person ( id_person),
  FOREIGN KEY( Tagung) REFERENCES Tagung (id_tagung));