DB-Modell für eine Software

[AlexII]

Hallo,

ich möchte eine DB-Modell für eine Tagungssoftware erstellen, aber irgendwie habe ich keine Idee wie es weiter gehen soll. Die Anwendung soll Personen beinhalten und Tagungen bzw. Seminare die sie besuchen will. Folgendes habe ich schon gemacht, siehe Anhang...

Nun weiß ich nicht wo ich die Infos packen soll, ob eine Person zur einer Tagung eingeladen wurde, und ob sie diese Einladung angenommen oder abgelehnt hat. Danke für eure Hilfe.

[Der schöne Günther]

Die nächste Frage wäre doch die nach der Kardinalität zwischen "Person" und "Tagung", oder?

Verhält sich Person:Tagung wie 1:1, 1:n, m:n oder n:1? Soll heißen: Kann eine Person nur auf eine Tagung oder auf mehrere? Kann eine Tagung von mehreren Personen besucht werden? Kann eine Tagung auch existieren, ohne dass Personen sie besuchen?

So als absoluter Datenbank-Depp

[AlexII]

Zitat:

Zitat von Der schöne Günther (Beitrag 1284417)

Die nächste Frage wäre doch die nach der Kardinalität zwischen "Person" und "Tagung", oder?

Verhält sich Person:Tagung wie 1:1, 1:n, m:n oder n:1? Soll heißen: Kann eine Person nur auf eine Tagung oder auf mehrere? Kann eine Tagung von mehreren Personen besucht werden? Kann eine Tagung auch existieren, ohne dass Personen sie besuchen?

So als absoluter Datenbank-Depp

Ok... eine Person kann natürlich auf mehreren Tagungen sein, aber nicht parallel. Eine Tagung hat eine Start- und Endzeit(Datum). Eine Tagung können viele Personen besuchen und natürlich kann auf eine Tagung keiner kommen.

[mkinzler]

Und bei einer Tagung sind normalerweise mehrere Personen anwesend.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284421)

Und bei einer Tagung sind normalerweise mehrere Personen anwesend.

Genau. Wie bilde ich nur das ganze auf dem Modell ab?

[mkinzler]

Ist eine n:m Beziehung. Implementiert über eine Zuordungstabelle.

[Perlsau]

Zitat:

Zitat von AlexII (Beitrag 1284422)

Genau. Wie bilde ich nur das ganze auf dem Modell ab?

Du erstellst eine Tabelle Personen und eine Tabelle Tagungen. Als Verknüpfung erstellst du eine Verknüpfungstabelle (VT), in der du die ID einer Person und die ID einer Tagung mitführst, also eine Tabelle, die zwei Spalten hat. Als PK nimmst du entweder eine dritte Spalte oder, wenn dein DBMS das erlaubt, einen aus den beiden Spalten zusammengesetzten PK. Um dann später zu erfahren, wer alles auf der Tagung mit der ID 75 angemeldet ist, fragst du einfach deine VT nach der Tagungs-ID ab. Wenn du wissen möchtest, auf welchen Tagungen die Person mit der ID 321 bereits angemeldet war, fragst du deine VT nach der Personen-ID ab.

Eine weitere VT könnte abbilden, wer auf den Tagungen auch wirklich anwesend war. Noch Fragen?

Oh, sehe gerade:

Was mkinzler mit Zuordnungstabelle meint, heißt bei mir Verknüpfungstabelle. Ist aber dieselbe Idee.

[AlexII]

Ok... etwa so, siehe Screenshot.

[Der schöne Günther]

Etwas Kritik am Rande: Wirst du (oder jemand anderes) in zwei Wochen noch wissen was ein "tbl_vt" ist?

[mkinzler]

Nein von der Zwischentabelle zu den beiden Tabellen zwischen denen die n:m Beziehung besteht

A n: m B -> A n : 1 Zw 1 : m B

Im ER-Modell kannst Du auf die Zuordnungstabelle aber auch verzichten

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284431)

Nein von der Zwischentabelle zu den beiden Tabellen zwischen denen die n:m Beziehung besteht

A n: m B -> A n : 1 Zw 1 : m B

Im ER-Modell kannst Du auf die Zuordnungstabelle aber auch verzichten

Hm... jetzt aber :-D

[AlexII]

Zitat:

Zitat von Der schöne Günther (Beitrag 1284430)

Etwas Kritik am Rande: Wirst du (oder jemand anderes) in zwei Wochen noch wissen was ein "tbl_vt" ist?

Ich ändere es noch, will erst die Logik verstehen.

[mkinzler]

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

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284434)

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

Hat mir Perlsau so empfohlen - "Als Verknüpfung erstellst du eine Verknüpfungstabelle (VT), in der du die ID einer Person und die ID einer Tagung mitführst, also eine Tabelle, die zwei Spalten hat."

Oder meinst Du die FK in der Tabelle tbl_vt?

[mkinzler]

Imo sind die Felder in der Verknüpfungstablle doppelt vorhanden.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284438)

Imo sind die Felder in der Verknüpfungstablle doppelt vorhanden.

Muss jetzt die Verknüpfungstablle Beziehungen zu den zwei anderen Tabellen haben, oder ist das nicht nötig?

[mkinzler]

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

[AlexII]

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?

[mkinzler]

Er hat die Fremdschlüssel gemeint.
Ein paar Fragen zu der Notation Deines ER-Diagramms:
Sind die FK_... Felder oder nur die constraints? Im 2. Fall wären id i_... dann notwendig, dann würden diese aber bei Anrede fehlen.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284442)

Er hat die Fremdschlüssel gemeint.
Ein paar Fragen zu der Notation Deines ER-Diagramms:
Sind die FK_... Felder oder nur die constraints? Im 2. Fall wären id i_... dann notwendig, dann würden diese aber bei Anrede fehlen.

Ok... jetzt muss es aber stimme?

Das sind Felder, Constraints kenne ich nicht, zumindest nicht bewusst.

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

[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.