Office: (Office 2016) Datenmodell/Beziehungen

Hallo Zusammen,

ich glaube ich habe mich in meinem Datenmodell verlaufen.
Es geht um eine Vortragsplanung von Liedern mit verschiedenen Gruppen.
Ich lege einen Termin mit Datum und einer Gruppe fest, i.d.R. gibt es auch nur eine Gruppe pro Termin. Bei einem Konzert können aber mehrere Gruppen an einem Termin auftreten. Dazu habe ich die Gruppe "Verschiedene" angelegt.

In der Tabelle Vortrag steht nun:
ID_Vortrag
Datum
ID_Gruppe (Gruppe1, Gruppe2, ... Verschiedene) ohne direkte Beziehung zur Tabelle "Gruppe. Ich weiß, das sollte man nicht tun aber ich lasse ein löschen von Gruppen nicht zu, sondern nur ein "deaktivieren". Grundsätzlich liegt ja auch hier mein Problem.

In der Tabelle Vortrag_Lieder lege die Lieder zum Vortrag fest:
ID_Vortrag_Lieder
ID_Vortrag
ID_Gruppe_Lied (Hier sind die Lieder mit der Gruppe verknüpft)
ID ...
...

Das funktioniert soweit ganz gut. Nun möchte ich aber eine Auswertung fahren um die Historie anzuzeigen (Wie oft und von wem vorgetragen?) Dazu benötige ich das Datum aus der Tabelle Vortrag. Da aber durch die Beziehungen in der Tabelle Vortrag, die Gruppe "Verschiedene" definiert ist, ich aber keine echte Gruppe "Verschiedene" habe, fallen alle Lieder aus der Historie raus die in Beziehung zu dem Termin mit der Gruppe Verschiedene stehen.

Im Prinzip ist das Logisch, aber ich möchte irgendwie in der Liste der Vorträge sehen, welche Gruppe aktiv ist, trotzdem die Möglichkeit haben an einem Termin mehrere Gruppen einzuplanen und eine saubere Historie zu sehen.

Im Anhang meine Beziehungen aufs wesentliche reduziert.

Vielen Dank im Voraus!

:)

 

Moin,

da gibt es nicht viel zu grübeln: Was an Daten nicht drinsteckt, kann niemand herausholen. Ob es hülfe, eine Dummy-Gruppe "Verschiedene" anzulegen, möchte ich bezweifeln, meistens wird der Verhau dadurch nur schlimmer.

Ganz nebenbei: Id_Lied hat in Vortrag_Lieder nichts verloren. Id_Gruppe hat nichts in Vortrag verloren, es sei denn, ein Vortrag bezeichne den Auftritt einer Gruppe. Dann fehlte aber eine Beziehung, und Vortrag_Lieder wäre massiv überbestimmt, sprich beliebig konfilktfähig mit Gruppe_Lieder.

Beim Modellieren ist es oft hilfreich, den Inhalt der Entität zu beschreiben: Ein Vortrag ist ein Liederabend, an dem von einer oder mehreren Gruppen Lieder vorgetragen werden (nur als Beispiel).

Gruß
Ralf

 

Hallo Ralf,

ID_Lied: stimmt das ist noch ein Überbleibsel, fliegt raus.

ID_Gruppe in Vortrag, darum geht es ja. Ich möchte in der Terminliste, die sich aus Vortrag ergibt, sehen welche Gruppe davon betroffen ist, ohne in die Beitragsübersicht Vortrag_Lieder einsteigen zu müssen.

Dein Bespiel trifft es ganz gut, nur das eben an dem einen "Liederabend" eine Gruppe und manchmal mehrere Gruppen vertreten sind.

Ich habe mir schon überlegt, ob es nicht sinnvoller ist, den Weg andersherum zu gehen: Kein ID_Gruppe in Vortrag, dafür frage ich ab, ob nur eine oder mehrere Gruppen in Vortrag_Lieder stecken und lasse das Ergebnis bei Requery von Vortrag anzeigen.

 

Hallo,
ich halte das Datenmodell so und so für überarbeitungsbedürftig.
Kannst Du mal die Aufgabe der DB zusammenhängend schildern, ohne mal die DB/Tabellen als solches im Blick zu haben.

 

Es gibt mehrere Musikgruppen (Chöre/Orchester). Das Liedgut ist teilweise identisch, teils spezifisch für die Gruppen, in Summe ca. 1500 Lieder. Natürlich sind nicht alle von diesen Liedern gleichermaßen bekannt. In diesen Musikgruppen gibt es unterschiedliche und durch Vertretungen auch mehrere Dirigenten. Es gibt Probentermine und Vortragstermine. Bei den Probenterminen übt zu 99% nur eine Gruppe unter sich. Bei den Vortragsterminen kann es Kunterbunt sein, auch was die Dirigenten betrifft. Allerdings ist dies auch eher selten.

Mit dieser Datenbank möchte ich die Liedplanung (Proben/Vorträge)vornehmen Dirigenten zuordnen, organisieren, für eine gute Übersicht sollen Gruppenspezifische Informationen z.B. Liedstatus in der Datenbank gepflegt werden. Deswegen hat jede Gruppe eine eigene Liedzuordnung. Das ganze soll später auch noch Mehrbenutzerfähig sein, also auf SQL -Server gehoben werden.

 

Richtig erkannt. Wenn es mehrere Gruppen bei einem Vortrag geben kann, hat die ID_Gruppe in dieser Tabelle nichts verloren.

Jetzt gibt es zwei Möglichkeiten. Wenn es dir ausreicht, dass die Zuordnung von einer Gruppe zu einem Vortrag nur über die vorgetragenen Lieder möglich ist, dann brauchst du nichts weiter tun als deine Abfragen entsprechend umzustellen.

Wenn du aber in der deiner DB abbilden möchtest, dass eine bestimmte Gruppe für einen Vortrag fest eingeplant ist, es aber noch nicht bekannt ist, welche Lieder sie vortragen wird, dann brauchst du noch eine M:N-Zwischentabelle, die Vortrag und Gruppe verbindet.
Dies in der Benutzeroberfläche sauber abzubilden und verwaltbar zu machen, ist allerdings voraussichtlich etwas aufwendig.

 

Wenn man die beiden überflüssigen Felder mal ausser Acht lässt (die entfernst du ja), dann scheint es mir eigentlich stimmig.

WO hast du noch Probleme, denn dann wäre deine Beschreibung gleich oben unvollständig ...

Die Tabellen solltest du mit einem Präfix versehen, damit gerade auch bei Beschreibungen klar ist, von was man spricht.

Die Tabelle Vortrag solltest du anders nennen, z.b. tbl_Ereignis und dann mit einem Attribut sagen, um welche Art es sich handelt: Probe, Generalprobe, Konzert (ev. weitere)

Was sind die beiden Fremdschlüssel "ID_Anlass" und "ID_Anlass2" ??

 

Hallo und frohe Ostern,

zum vollen Verständnis sollte ich noch sagen, dass es für die Proben eigene Tabellen gibt, Proben und Proben_Lieder. Hier ist die Sache mit der Gruppenzuordnung einfacher, weil wie schon beschrieben jede Gruppe für sich übt. Was in diesem Thread mit Sicherheit zu der Frage führt warum diese Trennung von Vortrag und Proben vorhanden ist. So ganz sicher bin ich mir nicht mehr *rolleyes.gif* , aber ich werde überlegen die vier Tabellen auf zwei zu reduzieren, erspart ein paar Formulare etc.

Der Grund warum ID_Gruppe enthalten sein soll, ist letztendlich eine Übersicht der Termine. Was passiert da und welche Gruppe betroffen ist. Die ID_Anlass und ID_Anlass2 enthalten Informationen zu Anlass: "Konzert" und "Ostern". Ich möchte später auswerten können, was die letzten Jahre zu Ostern gespielt/gesungen wurde. Was haltet ihr von dem Gedanken, eine zweite Tabelle Gruppe anzulegen die nur für Vortrag und Proben vorhanden ist?

 

Gar nichts, siehe meine Bemerkung oben zu tbl_Ereignis mit Attribut
Alles andere führt eher früher wie später zu irgenwelchen Murks-Aktionen.
Auch wenn du heute das vieleicht nicht siehst: es könnte z.b. mal die Frage kommen, wieviele Proben gab es zum Konzert XY. Dann müsstest du aus 2 Strukturen zusammenführen.

Bei ID_Anlass und ID_Anlass2 ist es dasselbe: überflüssig. Ob das Ostern, Pfingsten oder wann auch immer war, sieht man doch anhand des Datums. Und wenn schon, dann kannst du ja ein Attribut mit einer weiteren Tabelle erstellen, in der du die Bezeichnung regelmässiger Konzerte hast, eben z.b. "Osterkonzert", "Weihnachstkonzert", "Abonnements-Konzer" etc.

 

Es handelt sich um zwei unterschiedliche Tabellen Anlass und Anlass2 mit unterschiedlichen Inhalten/Kategorien. Anhand des Datums sieht man allenfalls Weihnachten oder Neujahr also die Tage zu festen Terminen, aber ein Weihnachtskonzert beschreibt einen Zeitraum und keinen festen Termin. Osterkonzerte kann ich nur über den Begriff "Ostern" filtern.

OK also ich denke ich bin einen deutlichen Schritt weiter. Ich werde die zweite Tabelle für Gruppen einführen, auch wenn das gewisse "Murks"- Risiken bedeutet. In der Praxis üben zwei oder mehr unterschiedliche Gruppen an einem Tag und zur selben Uhrzeit. Die Proben werden von unterschiedlichen Dirigenten geleitet und da wird die Planung ohne deutliche Unterscheidung der Gruppen nicht wirklich funktionieren.

Vielen Dank für Eure Denkhilfen!

 

Hallo

meine Überlegung ist:
an einem bestimmten Ort wird eine Veranstaltung (Konzert, Liederabend oder wie auch immer)
für einen bestimmten Anlass gegeben mit einem Dienstleiter (Verantwortlichen).
Zu diesem Anlass werden verschiedene Lieder mit ev. verschiedenen
Dirigenten und auch wieder ev. verschiedenen Gruppen dargebracht.
Gruppen lernen verschiedene Lieder, aber was ist, wenn eine Gruppe ausfällt,
muss eine andere Gruppe dieses Lied singen... oder nicht?
Das würde dann in deinem Fall nicht so richtig passen.
Musiker die zu einer Gruppe gehören, sind bei dir nicht vorgesehen, wäre das nicht gut?
Mehr fällt mir im Moment nicht dazu ein.
Eine Überlegung in Form eines DB-Modells im Anhang.
Bin auch nicht sicher ob meine Idee so ideal ist... müsste ich erst mit Daten testen.
Nur wenige Daten sind eingefügt... und die nur zum besseren Verständnis.

Ich habe alle Personen in einer Tabelle und diese werden durch ihre Art gekennzeichnet.
Es könnte natürlich jetzt sein, dass eine Person einer Gruppe zusätzlich noch
Dirigent oder Dienstleiter ist, das habe ich noch nicht, in die BDB, mit eingefügt,
da ich nicht weiß ob das überhaupt vorkommen kann.

PS: ich habe die Gruppen für LiedGruppen (Musical/Operette/Oper/Volksmusik usw.) gedacht...
und nicht für Personen! Falls das nicht gebraucht wird, kann man diese Tabelle ja löschen!

Alles Gute für deine DB *Smilie

PS2: eine Planung der Proben wird mM das Problem nicht sein, dass man 2 Tabellen benötigt.
Oder, habe ich mich jetzt verlesen? Mach das ja nicht, du wirst es bereuen!
Überlegung am Anfang erspart später viel Ärger!!!

Habe schon Musiker und Proben in die BDB eingefügt... dürfte auch so passen...???!!! Denke ich.
Noch nicht in dieser...BDB nur zu Hause *Smilie
So, habe sie jetzt eingefügt... war zwar eine Hau-Ruck-Aktion, deshalb nicht sicher ob ich gut gedacht habe *Smilie

 

wer nicht hören will, muss fühlen ...

ist doch überhaupt kein Problem, du kannst in der "Vortrag" Tabelle (dass der Name schlecht ist, habe ich schon gesagt) doch mehrere Einträge für denselben Tag machen und dann in "Vortrag_Lieder" die entsprechende Kombination von Gruppe (= Orchester/Chor) mit dem betreffenden Lied eintragen.
Vermutlich fehlt einfach noch ein Ort, wo das stattfindet.

 

Hi,

das ist, wie man so schön sagt, ein unsittliches Ansinnen. Das Datum steht nun mal beim Vortrag, die Gruppe erst in Vortrag_Lieder.

Es mag Gründe geben, von der reinen Lehre abzuweichen - wenn Du aber schon auf diesem Level die Regeln brechen möchtest, sehe ich den Verhau in Reinstform auf Dich zukommen.

Gruß
Ralf

 

Hallo Zusammen,

ich habe die Beziehungen (diesmal komplett) meiner geänderten Datenbank angehängt. Vortrag heißt jetzt Termine und Vortrag_Lieder heißt jetzt Termine_Lieder.Die Tabelle Proben und Proben_Lieder ist in Termine... aufgegangen.

Was ich aber überhaupt nicht verstehe - und das meine ich im Wortsinn - was an meinem speziellen Wunsch so schlimm ist. Das ich doppelt Daten führe ist nicht toll, verstanden aber sonst?

Wenn ich einen Schrank mit Musikordnern habe, möchte ich nicht alle Ordner durchsuchen um zu sehen was drin enthalten ist, sondern beschrifte die Ordner entsprechend. Oder würdet ihr auf die Idee kommen alle Ordner zu öffnen?

Ich habe hier wohl mehr die Benutzerbrille auf als die Entwicklerbrille *holy :

 

Hallo,
die 2 Anlasstabellen sind auf jeden Fall falsch. Du solltest Dir hier eine TAbelle anlegen die alle möglichen Anlässe ausgeschrieben und als Kürzel in jeweils einem Datensatz enthält. Dann speichert Du den entsprechenden Anlass nur als Fremdschlüssel. Im Grunde kannst Du Anlass_2 einfach löschen, mitsamt dem Fremdschlüssel.

Der Vergleich mit Schrank und Ordner hinkt. Der Schrank ist die eine Tabelle und der Ordnern sind die Daten und bei den Daten steht in welchem Ordner die sind. Du suchst also in einer Tabelle nach Inhalten und da diese Inhalte einen Vermerk haben in welchem Ordner sie sind, kannst Du über eine Filterung jederzeit aus dem kompletten Inhalt (dem Schrank) die richtigen Daten ausfiltern.

Das restliche Datenmodell habe ich immer noch nicht so recht verstanden, scheint mir aber eher über normalisiert zu sein.