DB-Modell für eine Software

[Perlsau]

Zitat:

Zitat von AlexII (Beitrag 1284457)

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:

In der angehängten Access-Datenbank hab ich das hinbekommen, indem ich die beiden Felder im Entwurfsmodus markiert (nicht in der Spalte mit dem Bezeichner, sondern davor mit gedrückter Shift- oder Strg-Taste) und dann mittels Mausrechtsklick beide Felder als Primärschlüssel definiert habe. Versuchst du nun, einen Eintrag hinzuzufügen, der bereits existiert (diese Person nimmt bereits an dieser Tagung teil), löst das eine Fehlermeldung aus. In Firebird, PostGre, MySQL und MsSQL kann ich das mit dem jeweiligen Datenbankmanager lösen (Access ist ja im Grunde auch nichts anderes als ein Datenbank-Manager für Access-"Datenbanken"). Das alles kann man in der Grafik oben und in der Access-DB sehr gut sehen.

Ach, ich sehe eben, mkinzler hat das bereits als SQL hingeschrieben, so geht's natürlich auch. :thumb:

[Dejan Vu]

Da es keine Tabelle 'Teilnehmer' gibt, tendiere ich bei existierender Tabelle 'Personen' zur Nomenklatur 'TagungsPersonen' bzw. in diesem Fall eher zur Umbenennung der Tabelle 'Personen' in 'Teilnehmer'.

Es erhöht imho die Übersichtlichkeit, wenn keine neuen Bezeichner eingeführt werden. Die Regel wird genau dann gebrochen, wenn die entstehenden Bezeichnungen allzu albern werden. Dann gilt: Hauptsache, man versteht es.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284459)

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));

Sag ma und wie sieht eine Selection mit so einem PK aus? Mit einem "normalen" PK mache ich es so:

Delphi-Quellcode:

x := 7;
SELECT ... FROM ... WHERE id=x;

Wenn aber der PK aus zwei Integer besteht? :gruebel:

[mkinzler]

Es sind ja auch 2 Felder

SQL-Code:

select ... from ... where person = 7 and tagung = 8;

[Dejan Vu]

Das wird man aber selten brauchen. Man will eher wissen, wer alles auf einer Tagung war ('select personID from TagungsTeilnehmer where TagungsID=123') oder welche Tagungen eine Person besucht hat. Die Abfrage mit PersonID und TagungsID ist eher ein 'Hat diese Person die Tagung besucht?'

Du kannst in einer WHERE-Klausel unterbringen, was Du willst:

Code:

select * from MeineTabelle WHERE CURRENT_DATE()> '12.01.2015'

Zeigt die Tabelle nur nach dem 12.1.2015 an
und

Code:

select * from MeineTabelle WHERE 1=0

zeigt nur die Überschriften.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284493)

Es sind ja auch 2 Felder

SQL-Code:

select ... from ... where person = 7 and tagung = 8;

Ich glaube ich muss anfangen ein bisschen einfacher zu denken... :roteyes: Ein bisschen entspannen und schon ist programmieren halb so wild. :mrgreen:

[mkinzler]

Zitat:

Das wird man aber selten brauchen. Man will eher wissen, wer alles auf einer Tagung war ('select personID from TagungsTeilnehmer where TagungsID=123') oder welche Tagungen eine Person besucht hat. Die Abfrage mit PersonID und TagungsID ist eher ein 'Hat diese Person die Tagung besucht?'

Bzw. auf Zusatzinformationen, welche man in dieser Tabelle bezüglich der Teilnahme/Buchung ablegen könnte. Z.B. Buchungsdatum, Details zur Teilnahme usw.

[Dejan Vu]

In einer Relation? Kann man machen. Geht aber sehr schnell in Richtung => Verletzung 3NF.

[mkinzler]

Warum nicht?

SQL-Code:

CREATE TABLE TagungsTeilnehmer(
  Person Integer,
  Tagung Integer,
  BuchungsDatum DATE,
  bezahlt Integer,
  teilnehmerNr Integer,
  teilgenommen Integer,
  ...
  PRIMARY KEY( Person, Tagung),
  FOREIGN KEY( Person) REFERENCES Person ( id_person),
  FOREIGN KEY( Tagung) REFERENCES Tagung (id_tagung));

[Dejan Vu]

Kann man zusammenfassen, sollte man aber nicht (wegen der Flexibilität). Ich persönlich würde es nicht machen, da die 3NF verletzt ist. Eine Person nimmt an einer Tagung teil, die sie zuvor gebucht hat (3 Tabellen: Personen, Buchungen, Tagungen und entsprechende Relationen).

Ich kann so einer Person ermöglichen an einer Tagung teilzunehmen, ohne das sie gebucht hat. Das soll es geben. Bei deinem Ansatz müsste dann z.B. 'Buchungsdatum = NULL' sein und für die anderen Flags müsste man auch tristate logic einführen => Anti-Pattern.