Problem mit Normalisierung zweier Tabellen

Ich hoffe das Thema ist hier richtig platziert…

Also folgender Sachverhalt:

Ich habe zwei Tabellen

Profile, Zeiten

Profile beinhaltet:
(PNr [AutoWert], Bez [Text 15])

Zeiten beihnaltet:
(Beginn [Datetime 24 Std] , Ende [Datetime 24 Std], Pause [Datetime 24 Std])

Allgemein: Folgendes muss/soll erfüllt werden:

Jedes Profil hat mind. 1 max n Zeiten
Jede Zeit wird von mind. 0 , max. n Profilen benutzt

ABER das reicht so nicht… jetzt kommt der sprichwörtl. „Haken an der Sache“. Jedes Profil soll/kann auch für unterschiedl. Wochen (gerade/ungerade) unterschiedl. Zeiten haben

Die Woche hat 7 Tage also
Jedes Profil hat genau 7 Zeiten für die ungerade Woche und 7 Zeiten für die gerade Woche.

Primärschlüssel Profile = PNr
Primärschlüssel Zeiten = Beginn, Ende, Pause ( Autowert wäre doch Quatsch, da dann ja dieselben Zeiten mehrmals hinzugefügt werden könnten)

So ich hoffe, dass es halbwegs nachvollziehbar ist…

Hallo,

also wenn ich das richtig interpretiere dann geht es um eine Studienaufgabe mit dem altbekannten Problem der „Schichtzuweisung“

Also:

Profile beinhaltet:
(PNr [AutoWert], Bez [Text 15])

soweit so gut…

(Beginn [Datetime 24 Std] , Ende [Datetime 24 Std], Pause

auch ok

Primärschlüssel Zeiten = Beginn, Ende, Pause ( Autowert wäre
doch Quatsch, da dann ja dieselben Zeiten mehrmals hinzugefügt
werden könnten)

na ja… doch Primaerschluessel…aber dann kann man sich doch einen anderen Ansatz vorstellen

Profile hat PS(numerisch)
Zeiten haben PS(numerisch)

Diese beiden Tabellen werden dann in einer 3. Tabelle (sagen wir mal Schichttabelle) zusammengefuehrt.
Schichttabelle:

ID ( P-Schluessel autowert )
ProfilID ( Zeiger auf Profilsatz)
ZeitID ( Zeiger auf Zeitensatz)
WochenTagGueltig ( Der Tag an dem dieser Zeitplan fuer dieses Profil gilt)

Dann ist alles schon normalisiert und es gibt keine Redundanzen.

Uch vermue mal, das die Aufgabenstellung nicht dahin formuluert war das Problem in 2 Tabellen zu loesen.

Tschau
Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hallo,

also wenn ich das richtig interpretiere dann geht es um eine
Studienaufgabe mit dem altbekannten Problem der
„Schichtzuweisung“

stimmt

Profile hat PS(numerisch)
Zeiten haben PS(numerisch)

Diese beiden Tabellen werden dann in einer 3. Tabelle (sagen
wir mal Schichttabelle) zusammengefuehrt.
Schichttabelle:

ID ( P-Schluessel autowert )
ProfilID ( Zeiger auf Profilsatz)
ZeitID ( Zeiger auf Zeitensatz)
WochenTagGueltig ( Der Tag an dem dieser Zeitplan fuer dieses
Profil gilt)

Dann ist alles schon normalisiert und es gibt keine
Redundanzen.

zu dem Vorschlag Schichttabelle
Ja aber ich kann dann ja für jedes Profil x Wochtentage hinzufügen, unter anderem ja auch für z.B. den Wochentag 1, x verschiedene Zeiten, wenn ich dann eine Abfrage starte zeige mir die Zeiten von Montag (1) an, habe ich mehrere Werte zur Verfügung… und da genau ist das Problem… …leider, oder habe ich was missverstanden ?

zu Primärschlüssel in Zeiten numerisch
wenn ich dort auch einen autowert als Primärschlüssel definiere, ist zwar auch hier als redundanzfrei, aber bei genauer Betrachtung kann ich ja dadurch in jeder Zeile immer wieder diesselbe Zeit eintragen…

Uch vermue mal, das die Aufgabenstellung nicht dahin
formuluert war das Problem in 2 Tabellen zu loesen.

Nein … bei m zu n muss ne dritte Tabelle her… bloß ich weiß halt nicht wie die aussehen soll , damit alle Kriterien erfüllt werden…

Hallo,

also da habe ich dann ein Detail falsch verstanden.

Wenn es darum geht, das nur ein einziger Eintrag fuer ProfilZeittabelle bstehten darf ( was etwas realitaetsfremd ist) dann ist die Sache noch etwas einfacher:

Profiltabelle wie gehabt
Zeitentabelle wie gehabt
Zuweisungstabelle nur 2 Felder
ProfilID und ZeitID und genau diese beiden Felder werden gemeinsam als Primarykey definiert!
Damit ist Sichergestellt, das ein Zeiteintrag einem Profil nur einmal zugewiesen werden kann.

Um fuer die Zeitentabelle sicherzustellen das es fuer ein bestimmtes Intervall nur ein Eintrag existiert muesste man die Tabelle ewt. noch erweitern mit z.B. ein Feld das festlegt gerade/ungerade Woche und ein weiteres fuer den Wochentag, und diese beiden Felder muessten dann als UniqueKey definiert sein.

Tschau
Peter

Hallo,

also da habe ich dann ein Detail falsch verstanden.

Wenn es darum geht, das nur ein einziger Eintrag fuer
ProfilZeittabelle bstehten darf ( was etwas
realitaetsfremd ist) dann ist die Sache noch etwas einfacher:

Nein dem Profil sollen mehr als eine Zeit zugeordnet werden…ich glaube ich erkläre das ganze auch viel zu kompliziert

Also

Am Beispiel

Tabelle Profile ( PNr,Bez)
1, Angestellte
2, Verwaltung
usw.

Tabelle Zeiten (ZNr, Beginn, Ende, Pause)
1, 08:00, 16:00, 00:30
2, 07:00, 17:00, 00:45
3, 22:00, 06:00, 00:45
4, 00:00, 00:00, 00:00
usw.

Mein Problem in einer eventuellen Beziehungstabelle

Das Profil Angestellte z.B. soll

in einer geraden Woche
Mo, Zeiten -> 1
Di, Zeiten -> 1
Mi, Zeiten -> 1
Do, Zeiten -> 1
Fr, Zeiten -> 1
Sa, Zeiten -> 4
So, Zeiten -> 4

in einer ungeraden Woche
Mo, Zeiten -> 2
Di, Zeiten -> 2
Mi, Zeiten -> 2
Do, Zeiten -> 2
Fr, Zeiten -> 2
Sa, Zeiten -> 4
So, Zeiten -> 4

enthalten… , somit sind das dann genau 14 Verknüpfungen / Profil… und was nehme ich nun in der Beziehungstabelle als Primärschlüssel ?

Tag, Woche, PNr, würden dafür sorgen,dass genau 14 Einträge möglich sind, aber laut Regel xy muss doch bei der m zu n beziehung auch der Schlüssel der Zeiten Tabelle ( ZNr) im Primärschlüssel enthalten sein oder ??

Doch wenn ich ZNr noch dazu nehme ist es wieder möglich x Verknüpfungen zwischen Profile und Zeiten zu erzeugen… jeder Tag könnte dann mehrere Zeiten erhalten

Mo, Zeiten -> 2
Mo, Zeiten -> 3
Mo, Zeiten -> 4

usw., da ja ZNr mit im Primärschlüssel enthalten ist…

Denke ich zu kompliziert oder schlichtweg falsch, oder ist es kompliziert… ??

Gruß, und danke für die bisherigen Antworten

Hallo,

ok, langsam versteh ich die Aufgabenstellung…

also um sicherzustellen, das fuer ein Profil nur max. 14 Eintraege vorhanden sein duerfen bedarf es einem Schluessel der aus der ProfilID, dem Wochentag und einem Schalter fuer gerade/ungerade Woche besteht.
Der Verweis in die „Zeitentabelle“ ist hier vorhanden aber nicht als Schluessel zu definieren.

Das sollte eigentlich alles sein.

Die Beziehungstabelle wuerde dann folgendermassen aussehen

ZNr, ( num)
PNr, ( num)
iTag, ( num)
bWoche (boolean) … True = gerade; FALSE = ungerade

PNr, Tag, Wochenflag bilden zusammen den Primaerschluessel

Fuer das Feld Tag muesste man darueber hinaus noch ein Constain definieren, das der Wert sich nur zwischen 1 und 7 bewegen darf.

aber laut Regel xy muss doch bei der m zu n
beziehung auch der Schlüssel der Zeiten Tabelle ( ZNr) im
Primärschlüssel enthalten sein oder ??

Gerade eben nicht, denn in diesem Falle besagt mn ja gerade die !!nicht!! Eindeutigkeit der Beziehung.

Hope this helped
Tschau
Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]