Office: Datenmodellierung, ERM Modell f. Personalmanagement DB

Hallo,

stehe ein wenig auf dem Schlauch beim Modellieren/Entwickeln einer DB mit dem Konzept Personalmanagement.

Habe die nötigen Felder Normalisiert und in Tabellen zusammengefasst.

tbl_Personendaten: PNR, Name, Vorname, Anschrift, PLZ, Ort, TelNr., GebDatum
tbl_Firmenzugehörigkeit: Eintrittsdatum, Austrittsdatum
tbl_Geschlecht: Geschlecht
tbl_Qualifikation: Qualifikation
tbl_Abteilung: Abt.Nr., Abteilung
tbl_Nationalität: Nationalität
tbl_Arbeitsverhältnis: Befristet_ja.nein, Wöchentliche Arbeitszeit, Teilzeit_ja.nein, Krankheitstage

Bin mir aber überhaupt nicht schlüssig ob ich da auf dem richtigen Weg bin und wie ich die Schlüssel setzen und die Beziehungen herstellen soll(te).

Hat jemand Rat, Hilfe, Ideen, vorschläge?, die Tabellen als auch die Felder sind nicht fix sondern können ergänzt und angepaßt werden.

Gerd

 

1. Jede Tabelle braucht einen "Primärschlüssel", und den setze ich eigentlich immer als Typ "AutoWert / Zufall". Das macht spätestens deutlich, daß dieser Schlüssel nirgends dafür gedacht ist, auf einem Formular angezeigt oder eingegeben zu werden. Es ist ein rein "internes" Feld, über das die Beziehungen der Tabellen untereinander hergestellt werden.

Im Zweifelsfall kann der Schlüssel in jeder Tabelle einfach nur "ID" heißen, was die Benutzung einiger Assistenten etwas vereinfacht. Ich persönlich mag es aber lieber, am Feldnamen auch zu erkennen, aus welcher Tabelle es stammt (PersonID, FirmaID, AuftragID, ...), auch wenn ich den Tabellennamen nicht mit . vor den Feldnamen setze.

2. Und in jeder "abhängigen" Tabelle brauchst Du dann noch ein "Referenz"-Feld, mit der die Tabelle weiß, zu welchem "Master"-Datensatz in der anderen Tabelle dieser Datensatz gehört. Das wäre dann Typ "Zahl / Long".

3. In den Beziehungen ziehst Du jetzt einfach das "Referenz"-Feld der abhängigen Tabelle auf das "ID"-Feld der Master-Tabelle und Dir wird i.a. auch schon die Verknüpfung 1:n angeboten, die Du ggf. mit "referentielle Integrität" und "Löschweitergabe" erweitern solltest.

Verfalle bitte nicht der Versuchung, die auf den ersten Blick eindeutigen Felder wie z.B. PersonalNummer oder AuftragsNummer als Primärschlüssel benutzen zu wollen. Richte lieber immer ein Extra-Feld ein.

Und richte den Primärschlüssel nicht als "Inkrement" ein, da es dazu verführt, diese schöne, fortlaufende Nummer doch auch noch anderweitig zu verwenden.

Gruß, Michael

 

Hallo Michael,

soweit war das klar, demnach sieht das ganze jetzt so aus.

Code:

tbl_Personendaten:		PersonalID, Name, Vorname, Anschrift, PLZ, Ort, TelNr., GebDatum
tbl_Firmenzugehörigkeit:	FirmenzugehörigkeitID, Eintrittsdatum, Austrittsdatum
tbl_Geschlecht:			GeschlechtID, Geschlecht
tbl_Qualifikation:		QualifikationID, Qualifikation
tbl_Abteilung:			AbteilungsID, Abteilung
tbl_Nationalität:			NationalitätID, Nationalität
tbl_Arbeitsverhältnis:		ArbeitsverhältnisID, Befristet_ja.nein, Wöchentliche Arbeitszeit, Teilzeit_ja.nein, Krankheitstage[quote][/quote]

Wobei die jeweilige ID dann der Primärschlüssel ist. soweit ich den Überblick habe sind die Tabellen ja alle 1:1 von der tbl_Personendaten abhängig? Bei dem zu erstellenden ERM Modell habe ich so meine Probleme.


Gerd

 

Jein... Im Prinzip sind sie 1:n verknüpft, aber Du kannst recht simpel dafür sorgen, daß es keine 2 Mitarbeiter geben kann, die auf der gleichen PersonalID laufen.

Wie gesagt, brauchst Du ja zu dem ID-Feld der Master-Tabelle auch noch das Referenz-Feld in der Detail-Tabelle. Also z.B.

"Master"
MasterID - Autowert/Zufall
MasterName - Text
MasterZahl - Zahl/Double
[...]

"Detail"
DetailID - Autowert/Zufall
MasterRef - Zahl/Long
DetailName - Text
DetailZahl - Zahl/Double
[...]

Und jetzt verknüpfst Du das "MasterRef" mit dem "MasterID" und hast Deine Relation aufgebaut.

Wenn MasterID der Primärschlüssel und MasterRef ein normales Zahlenfeld ist, dann kannst Du so eine 1:n Verknüpfung aufbauen. Sprich: In der Detail-Tabelle kann es mehrere Datensätze geben, die eine ID der Master-Tabelle referenzieren.

Wenn Du aber MasterRef mit einem Index/keineDuplikate versiehst, dann kann es in der Detail-Tabelle auch immer nur max. einen Datensatz geben, der eine bestimmte MasterID referenziert.

Das ist zwar im Prinzip immer noch 1:n, denn n kann auch 0 sein, aber es kann nicht mehr als 1 sein. Es kommt also der 1:1 Beziehung sehr nah, bietet aber z.B. die Möglichkeit, die (alle oder einige) Details eines Mitarbeiters zu löschen und den Master Datensatz noch zu behalten.

Z.B.: Ein Mitarbeiter verläßt die Firma. Die persönlichen Daten (Name, Geburtsdatum usw.) können gelöscht werden. Aber wenn die Stammnummer z.B. an eine Abteilung gebunden ist, kann diese Information erhalten bleiben. In der Personal-Liste könnte diese Personalnummer dann durch "n/a" als Platzhalter (nicht besetzte Planstelle) auftauchen.

Gruß, Michael

 

Hallo Michael,

habe so das Gefühl das du schon ein paar Schritte weiter bist.

Die Beziehungen habe ich wie folgt angedacht:

Bin ich da auf dem richtigen Weg?
Die Primärschlüssel hätte ich dann ja, jetzt müßten ja noch die Tabellen als Fremdschlüssel in die Tabelle Personendaten?

Gerd

 

So auf den ersten Blick würde ich sagen: Ja.

Aber: Du hast jetzt nur ausformuliert, welche Tabellen Du miteinander in Beziehung setzen willst. Ich war den Schritt weiter gegangen, auch auszuformulieren, welche Felder der Tabellen miteinander verknüpft werden müssen --> Ref : ID

Gruß, Michael

 

Hi,

nicht so schnell sonst wird mir schwindlig ;).

Ich war immer noch beim planen, so wie ich das sehe hast du schon die Beziehungen in Access erstellt in dem du die Felder verknüpft hast.

Gerd

 

Morgen,

so, habe meine Tabellenkonzept noch mal überarbeitet. Jetzt sollten auch alle Primär- und Fremdschlüssel stimmen.

Sollte jetzt stimmig sein, oder gibts noch Einwände?

Gerd

PS. Gibts ein Freewaretool mit dem man ein ERM Modell erstellen kann?

 

Das wirst Du selbst entscheiden müssen, wenn es darum geht, mit den Daten zu arbeiten. Probleme wirst Du schnell feststellen, wenn es darum geht, über die miteinander verknüpften Tabellen die Abfragen zu erstellen. Wenn Du da in Sackgassen gerätst, merkst Du recht schnell, woran es beim Tabellen-Design hapert.

Aber ich würde mit der Relation 1:1 sehr vorsichtig sein. Vielleicht ist es aber auch nur ein Verständnisproblem...

Die obige Zeile sagt: Ein Mitarbeiter kann und muß in genau einer Firma tätig sein, was ja ggf. noch nachvollziehbar ist. Unbeschäftigte stehen nicht in der Datenbank und Nebenjobs interessieren nicht. Aber es sagt umgekehrt auch, daß eine Firma nur genau einen Mitarbeiter haben kann und muß, und damit wird die Aussage dann vielleicht etwas gewagt... ;-)

Ich kenne nur "brain 1.0" in der Richtung, kostet nix und ist individuell anpaßbar. Die Multimedia-Version mit Papier und Buntstiften gibt es da ggf. auch noch. ;-)

Gruß, Michael