48897
May 30, 2007, updated at Jun 18, 2007 (UTC)
7231
3
0
Access Tabellenstruktur transitive Abhängigkeit? 3.Normalform
Hallo,
ich habe folgende Frage...
Ich habe 2 Tabellen - die eine heisst Stammdaten.Mitarbeiter und die andere Vertragsdaten. Zur Tabelle Vertragsdaten habe ich jedoch noch eine Frage: Mir ist aufgefallen, dass ich die Tabelle ja noch weiter trennen muss, oder?
Aktuell habe ich in der Tabelle Vertragsdaten:
VertragsID als Primärkey
Personalnr.
Vollzeit/Teilzeit (als Wertliste)
Arbeitszeitanteil
Tarifgruppe
Befristung (Ja/Nein)
Beginn Arbeitsvertrag
Ende Arbeitsvertrag
Bei weiterem Überlegen dachte ich mir jedoch folgendes - und ich bin mir nicht sicher ob es so korrekt ist ...
Ich müsste die Tabelle doch eigentlich in eine "Vollzeit/Teilzeit"-Tabelle (wo Beginn und Ende mittels Datum/Uhrzeit gespeichert wird) + eine "Tarifgruppen"-Tabelle (wo Beginn und Ende mittels Datum/Uhrzeit gespeichert wird) + in eine "Arbeitszeitanteil"-Tabelle (wo Beginn und Ende mittels Datum/Uhrzeit gespeichert wird) untergliedern. Wegen der 3.Normalform, oder? Ich weiss eben nicht ob das so korrekt ist, aber da ich dann später Auswertungen machen möchte die sich auf Zeiträume beziehen und sich die oben genannten Inhalte der Tabellen ändern können ohne dass sich der Rest ändert - dachte ich es mir halt so ?! Ein weiterer Punkt ist, dass mir die Angabe der Befristung ganz wichtig ist, da ich später auch einfach mal eine Abfrage machen will, wie viele befristete Verträge ich im Unternehmen habe. Nun dachte ich an ein Feld Befristung ja/ nein - bloss dann müsste ich auch wissen bzw. eintragen von wann bis wann die Befristung geht --> also wenn ich ja anklicke, dann muss man Beginn und Ende des Arbeitsvertrages eingeben, wenn ich keine Befristung habe, dann muss ich nur den Beginn des Arbeitsverhältnisses angeben. So hätte ich jetzt 5 Tabellen ?
Tabelle Vollzeit/Teilzeit
Tabelle Tarifgruppe
Tabelle Arbeitszeitanteil
Tabelle Befristung ja
Tabelle Befristung nein
Danke schon im Voraus für Tipps!
ich habe folgende Frage...
Ich habe 2 Tabellen - die eine heisst Stammdaten.Mitarbeiter und die andere Vertragsdaten. Zur Tabelle Vertragsdaten habe ich jedoch noch eine Frage: Mir ist aufgefallen, dass ich die Tabelle ja noch weiter trennen muss, oder?
Aktuell habe ich in der Tabelle Vertragsdaten:
VertragsID als Primärkey
Personalnr.
Vollzeit/Teilzeit (als Wertliste)
Arbeitszeitanteil
Tarifgruppe
Befristung (Ja/Nein)
Beginn Arbeitsvertrag
Ende Arbeitsvertrag
Bei weiterem Überlegen dachte ich mir jedoch folgendes - und ich bin mir nicht sicher ob es so korrekt ist ...
Ich müsste die Tabelle doch eigentlich in eine "Vollzeit/Teilzeit"-Tabelle (wo Beginn und Ende mittels Datum/Uhrzeit gespeichert wird) + eine "Tarifgruppen"-Tabelle (wo Beginn und Ende mittels Datum/Uhrzeit gespeichert wird) + in eine "Arbeitszeitanteil"-Tabelle (wo Beginn und Ende mittels Datum/Uhrzeit gespeichert wird) untergliedern. Wegen der 3.Normalform, oder? Ich weiss eben nicht ob das so korrekt ist, aber da ich dann später Auswertungen machen möchte die sich auf Zeiträume beziehen und sich die oben genannten Inhalte der Tabellen ändern können ohne dass sich der Rest ändert - dachte ich es mir halt so ?! Ein weiterer Punkt ist, dass mir die Angabe der Befristung ganz wichtig ist, da ich später auch einfach mal eine Abfrage machen will, wie viele befristete Verträge ich im Unternehmen habe. Nun dachte ich an ein Feld Befristung ja/ nein - bloss dann müsste ich auch wissen bzw. eintragen von wann bis wann die Befristung geht --> also wenn ich ja anklicke, dann muss man Beginn und Ende des Arbeitsvertrages eingeben, wenn ich keine Befristung habe, dann muss ich nur den Beginn des Arbeitsverhältnisses angeben. So hätte ich jetzt 5 Tabellen ?
Tabelle Vollzeit/Teilzeit
Tabelle Tarifgruppe
Tabelle Arbeitszeitanteil
Tabelle Befristung ja
Tabelle Befristung nein
Danke schon im Voraus für Tipps!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 60203
Url: https://administrator.de/contentid/60203
Printed on: April 19, 2024 at 03:04 o'clock
3 Comments
Latest comment
Moin polly15,
willkommen im Forum.
Der Grad der (wünschenswerten) Normalisierung hängt aber auch von Euren Realitäten bzw. Prozessen ab.
Konkret in diesem Fall solltest Du zwei Fragen noch ein wenig ausloten vor dem Tabellendesign:
Wenn es jeweils neue VertragsID gibt (und sei es nur als angehängte LaufendeNummer, also VID 4711-01, 4711-02, 4711-03....), dann kannst Du das Modell sauber bekommen.
Dann hat jede VertragsID ganz klar ein "Beginn" und ein "Ende"-Datum.
Dass die Zeiträume überschneidungsfrei sind, ist in der Realität so und kann zusätzlich noch programmtechnisch in der GUI sichergestellt werden.
Und welcher Vertrag heute, an den Iden des März oder zu einem beliebigen Zeitpunkt gültig ist, war oder sein wird, lässt sich jederzeit rekonstruieren (=auswerten).
Somit bleiben:
Das Attribut "befristet" kann entfallen - wenn kein Bis-Datum des Vertrags existiert, ist es unbefristet.
Das Attribut "Arbeitszeitanteil" kann ich inhaltlich nicht interpretieren (=kenn ich nich')
Gruß
Biber
willkommen im Forum.
Der Grad der (wünschenswerten) Normalisierung hängt aber auch von Euren Realitäten bzw. Prozessen ab.
Konkret in diesem Fall solltest Du zwei Fragen noch ein wenig ausloten vor dem Tabellendesign:
- Was willst Du später auswerten (können)? Welche Fragestellungen können an die DB gerichtet werden?
- Hat denn jede/r Mitarbeiter/in genau eine Vertragsnummer oder bekommt er/sie nicht nur einen geänderten Arbeitsvertrag, sondern eine neue VertragsID bei einem Wechsel z.B. von Teilzeit auf Vollzeit? Wie ist es bei einem Tarifwechsel? Bei Wechsel von befristet in unbefristet?
Wenn es jeweils neue VertragsID gibt (und sei es nur als angehängte LaufendeNummer, also VID 4711-01, 4711-02, 4711-03....), dann kannst Du das Modell sauber bekommen.
Dann hat jede VertragsID ganz klar ein "Beginn" und ein "Ende"-Datum.
Dass die Zeiträume überschneidungsfrei sind, ist in der Realität so und kann zusätzlich noch programmtechnisch in der GUI sichergestellt werden.
Und welcher Vertrag heute, an den Iden des März oder zu einem beliebigen Zeitpunkt gültig ist, war oder sein wird, lässt sich jederzeit rekonstruieren (=auswerten).
Somit bleiben:
- Tabelle MA-Stamm (mit PersNr, Name, Vorname, Geburtstag, Adresse....Eintritt, Aus/Abtritt..)
- Tabelle Vertragsdaten (PK sind VertragsID, falls VertragsID wie oben beschrieben eindeutig) mit den Attributen PersNr, GültigAb, GültigBis, Voll/TZ, Tarifgruppe,...
Das Attribut "befristet" kann entfallen - wenn kein Bis-Datum des Vertrags existiert, ist es unbefristet.
Das Attribut "Arbeitszeitanteil" kann ich inhaltlich nicht interpretieren (=kenn ich nich')
Gruß
Biber
Hallo polly15,
Wenn ich mir so die Daten anschaue, die du in der Datenbank speichern möchtest und später auch entsprechend auswerten willst, reicht es vollkommen aus wenn du 2-3 Tabellen dazu benutzt. Wenn du die Datenbank sauber nach der 3. Normalform konzipieren möchtest, wären wirklich diverse weitere Tabellen notwendig. Dann aber suaber die Daten zu speichern und später auch entsprechend auszuwerten ist/ wäre wesentlich komplexer....
Wenn ich eine Datenbank konzipiere schaue ich zwar auch auf die Normalformen und halte mich auch daran, aber nur bis zu einem gewissen Grad und selten 100%ig. Und der Grad ist bei mir meistens immer dan erreicht, wenn ich bei entsprechenden Reports später übermäßig Probleme habe/häte die ich programm(ier)technisch nicht mehr realisieren kann. Soll heißen, nicht immer ist es zweckmäßig eine Datenbank sauber bis in die 3. Normalform zu konzipieren.
Wenn ich mir deine Daten so anschaue würde ich deine beiden Tabellen nutzen. Je nachdem welche Daten zusätzlich in den Bereich "Tarifgruppe" fallen, würde ich das ggf. noch in eine weitere/ extra Tabelle auslagern.
Das Datenfeld "Befriestung" kannst du dir sparen, da das redundant zu "Beginn Arbeitsvertrag"/ "Ende Arbeitsvertrag" wäre. Wenn es sich um einen unbefristeten Arbeitsvertrag handelt, würde ich bei "Ende Arbeitsvertrag" entweder nichts oder einen utopisch hohen Wert (z.B. 31.12.9999) speichern. Bei einem befristeten Arbeitsvertrag dagegen ebend das entsprechende Datum. Über das Datum hast du nun jederzeit die Möglichkeit herrauszubekommen, ob es sich um einen befristeten oder unbefristeten handelt....
Gruss, Maik
Wenn ich mir so die Daten anschaue, die du in der Datenbank speichern möchtest und später auch entsprechend auswerten willst, reicht es vollkommen aus wenn du 2-3 Tabellen dazu benutzt. Wenn du die Datenbank sauber nach der 3. Normalform konzipieren möchtest, wären wirklich diverse weitere Tabellen notwendig. Dann aber suaber die Daten zu speichern und später auch entsprechend auszuwerten ist/ wäre wesentlich komplexer....
Wenn ich eine Datenbank konzipiere schaue ich zwar auch auf die Normalformen und halte mich auch daran, aber nur bis zu einem gewissen Grad und selten 100%ig. Und der Grad ist bei mir meistens immer dan erreicht, wenn ich bei entsprechenden Reports später übermäßig Probleme habe/häte die ich programm(ier)technisch nicht mehr realisieren kann. Soll heißen, nicht immer ist es zweckmäßig eine Datenbank sauber bis in die 3. Normalform zu konzipieren.
Wenn ich mir deine Daten so anschaue würde ich deine beiden Tabellen nutzen. Je nachdem welche Daten zusätzlich in den Bereich "Tarifgruppe" fallen, würde ich das ggf. noch in eine weitere/ extra Tabelle auslagern.
Das Datenfeld "Befriestung" kannst du dir sparen, da das redundant zu "Beginn Arbeitsvertrag"/ "Ende Arbeitsvertrag" wäre. Wenn es sich um einen unbefristeten Arbeitsvertrag handelt, würde ich bei "Ende Arbeitsvertrag" entweder nichts oder einen utopisch hohen Wert (z.B. 31.12.9999) speichern. Bei einem befristeten Arbeitsvertrag dagegen ebend das entsprechende Datum. Über das Datum hast du nun jederzeit die Möglichkeit herrauszubekommen, ob es sich um einen befristeten oder unbefristeten handelt....
Gruss, Maik
Hallo Biber, Hallo Maik,
vielen Dank für Eure Ideen/ Gedanken. Es hat mir wieder einige Anregungen gegeben noch einmal über meine DB-Struktur nachzudenken. Bin aber noch am geistigen Entwurf!
Also nochmals vielen Dank!!!!
vielen Dank für Eure Ideen/ Gedanken. Es hat mir wieder einige Anregungen gegeben noch einmal über meine DB-Struktur nachzudenken. Bin aber noch am geistigen Entwurf!
Also nochmals vielen Dank!!!!
