{"id":55001499,"date":"2024-06-01T00:00:00","date_gmt":"2024-12-06T10:59:43","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1499"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Datenmodell_Mitarbeiterverwaltung","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Datenmodell_Mitarbeiterverwaltung\/","title":{"rendered":"Datenmodell Mitarbeiterverwaltung"},"content":{"rendered":"

\"\"Eigentlich wollten wir nur ein kleines Datenmodell erstellen, das einige Tabellen enthält, die alle Beziehungstypen und Felddatentypen abbildet. Dieses wollten wir als Beispiel für eine SQL Server-Migration verwenden. Allerdings ist das Datenmodell so umfangreich geworden, dass wir uns entschieden haben, dieses einmal in einem Beitrag vorzustellen. Es enthält alle wichtigen Datentypen, alle Beziehungstypen und auch verschiedene Eigenschaften wie eindeutige und nicht eindeutige Indizes, Fremdschlüsselfelder, Felder, die den Wert Null enthalten dürfen und solche, die es nicht dürfen und vieles mehr. Dies ist ein Entwurf für ein solches Datenmodell, das keinen Anspruch auf Vollständigkeit hat – und es werden auch nicht alle Aspekte behandelt, die man vielleicht noch in einer solchen Verwaltung erwartet. Die Verwaltung von Gehältern, Urlauben et cetera würden wir gegebenenfalls in weiteren Beiträgen vorstellen.<\/b><\/p>\n

Verwalten von Mitarbeitern<\/h2>\n

Die Verwaltung von Mitarbeitern ist in Unternehmen, die eine relevante Anzahl Mitarbeiter haben, existenziell. In diesem Beitrag schauen wir uns an, welche Informationen eine Mitarbeiterverwaltung erfassen kann und wie diese auf die verschiedenen Tabellen aufgeteilt werden. Der Entwurf des Datenmodells erhebt keinesfalls den Anspruch auf Vollständigkeit. Wie schon im Einleitungstext erwähnt, gibt es nicht nur noch weitere Bereiche, die hier nicht erfasst werden, wie Lohnbuchhaltung oder Urlaubsverwaltung. Auch die hier vorgestellten Tabellen sind sicher nicht vollständig und decken nicht alle denkbaren Anwendungsfälle ab. Jedoch können Sie als Grundlage dienen, wenn Sie selbst einmal vor der Herausforderung stehen, eine Mitarbeiterverwaltung zu programmieren. Das Datenmodell enthält außerdem alle wichtigen Felddatentypen, Beziehungstypen, Beziehungseigenschaften, Indizes und Feldeigenschaften. Dies war die ursprüngliche Motivation: Wir wollten ein Datenmodell erschaffen, mit dem wir die Migration von Access zum SQL Server dokumentieren können. Es ist jedoch sinnvoll, dieses Datenmodell auch einmal zu erläutern, damit deutlich wird, wo die Besonderheiten stecken.<\/p>\n

Die Tabelle zum Verwalten der Mitarbeiter<\/h2>\n

Die wichtigste Tabelle ist die Tabelle tblMitarbeiter<\/b>. Ihr Entwurf sieht wie in Bild 1 aus. Neben dem obligatorischen Primärschüsselfeld namens MitarbeiterID <\/b>finden wir einige Felder für Name und Adresse vor, womit wir schon einmal den Datentyp Kurzer Text <\/b>abgedeckt haben.<\/p>\n

\"Entwurf<\/p>\n

Bild 1: Entwurf der Mitarbeitertabelle<\/span><\/b><\/p>\n

Diese Felder haben wir im Gegensatz zu einigen anderen Feldern mit dem Wert Ja <\/b>für die Eigenschaft Eingabe erforderlich <\/b>ausgestattet, damit diese immer gefüllt werden müssen.<\/p>\n

Die Anrede wählen wir über ein Nachschlagefeld aus, das wir für das Feld AnredeID <\/b>hinterlegen. Die damit verknüpfte Tabelle heißt tblAnreden <\/b>und enthält die beiden Felder AnredeID <\/b>und Anrede<\/b>. In dieser Tabelle haben wir für das Feld Anrede <\/b>einen eindeutigen Index definiert (siehe Bild 2).<\/p>\n

\"Entwurf<\/p>\n

Bild 2: Entwurf der Tabelle tblAnreden<\/span><\/b><\/p>\n

Damit stellen wir sicher, dass jede Anrede nur einmal eingegeben werden kann. Die Beziehungen zwischen der Haupttabelle und den Nachschlagetabellen wie tblAnreden<\/b> werden über das Fremdschlüsselfeld der Tabelle tblMitarbeiter <\/b>und dem Primärschlüsselfeld der jeweiligen Nachschlagetabelle wie in Bild 3 definiert.<\/p>\n

\"Verknüpfung<\/p>\n

Bild 3: Verknüpfung zwischen der Haupttabelle tblMitarbeiter und einer Lookuptabelle, hier tblAnreden<\/span><\/b><\/p>\n

Das Land geben wir ebenfalls nicht als Text ein, sondern wählen es über ein Nachschlagefeld aus, wobei die Daten in der Tabelle tblLaender <\/b>stecken. Diese enthält, wie für die meisten Lookuptabellen typisch, lediglich zwei Felder – das Primärschlüsselfeld LandID <\/b>und das Feld Land <\/b>mit der Länderbezeichnung. Auch hier haben wir für einen eindeutigen Index definiert, diesmal für das Feld Land<\/b>.<\/p>\n

Mit dem Feld Geburtsdatum <\/b>decken wir das Datumsfeld ab.<\/p>\n

Das Feld GehaltssteigerungProJahr <\/b>definieren wir mit dem Felddatentyp Währung <\/b>und stellen für die Eigenschaft Format <\/b>den Wert Prozentzahl <\/b>ein. So erhalten wir für die Werte dieses Feldes die Genauigkeit eines Dezimalfeldes und die Darstellung als Prozentzahl.<\/p>\n

Mit dem Feld Foto<\/b> decken wir den Datentyp Anlage <\/b>ab, der unter SQL Server so nicht verfügbar ist – so viel vorneweg.<\/p>\n

Memofeld mit verschiedenen Eigenschaften<\/h2>\n

Wir wollen auch Memofelder, die heute unter dem Felddatentyp Langer Text <\/b>zu finden sind, abbilden, und zwar mit den verschiedenen speziellen Eigenschaften.<\/p>\n

In der Tabelle tblMitarbeiter <\/b>finden wir so die beiden Felder Lebenslauf <\/b>und Notizen<\/b>. Lebenslauf <\/b>ist ein Feld mit dem Datentyp Langer Text <\/b>und den Standardeinstellungen. Für das Feld Notizen <\/b>haben wir den Wert der Eigenschaft Nur anfügen <\/b>auf Ja <\/b>eingestellt. Das bedeutet, dass wenn wir Änderungen an dem Inhalt vornehmen, intern die neueste Version gespeichert wird, die vorherigen Versionen aber auch noch vorhanden sind. Diese können wir beispielsweise per VBA mit folgendem Befehl abrufen, hier im Format für das Direktfenster:<\/p>\n

  ColumnHistory(\"tblMitarbeiter\", \"Notizen\", \"MitarbeiterID = 1\")<\/pre>\n
Oder wir klicken mit der rechten Maustaste auf das Tabellenfeld oder ein daran gebundenes Formularfeld und wählen aus dem Kontextmenü den Eintrag Spaltenverlauf anzeigen <\/b>aus, der den Inhalt wie in Bild 4 anzeigt. Beides ist nicht besonders komfortabel, sodass man sich ohnehin eine eigene Funktion zur Anzeige ausdenken muss.<\/p>\n
\"Inhalt<\/p>\n
Bild 4: Inhalt eines Memofeldes mit aktivierter Eigenschaft Nur anfügen.<\/span><\/b><\/p>\n
Und wenn man schon dabei ist, könnte man diese auch direkt so ersetzen, dass sie gar nicht verwendet werden muss. Wie das gelingen kann, zeigen wir im Beitrag Textfeldhistorie in eigener Tabelle speichern <\/b>(www.access-im-unternehmen.de\/1500<\/b>).<\/p>\n
Auf ein Memofeld mit dem Textformat Rich-Text <\/b>kommen wir später in einer anderen Tabelle zurück.<\/p>\n
Webseite <\/b>und EMail <\/b>sind beides Felder mit dem Datentyp Link<\/b>.<\/p>\n
Mit Eintrittsdatum <\/b>und Austrittsdatum <\/b>stellt die Tabelle weitere Felder des Datentyps Datum\/Uhrzeit <\/b>bereit.<\/p>\n
Das Feld Behindert<\/b>, mit dem wir den Datentyp Ja\/Nein <\/b>abbilden, gibt an, ob der Mitarbeiter eine Behinderung aufweist.<\/p>\n
Behinderungsgrad ist ein Zahlenfeld, dem wir über das Format Prozentzahl<\/b> die Ansicht als Prozentzahl hinzugefügt haben – diesmal allerdings mit der Feldgröße Single<\/b>, was mit einer geringeren Genauigkeit bei den Nachkommastellen einhergeht als bei Datentyp Währung<\/b>.<\/p>\n
ReligionID<\/b>, GeschlechtID <\/b>und SteuerklasseID <\/b>sind jeweils Fremdschlüsselfelder, die wir als Nachschlagefelder ausgelegt haben und die mit den Tabellen tblReligionen<\/b>, tblGeschlechter <\/b>und tblSteuerklassen <\/b>verknüpft sind.<\/p>\n
Weitere Tabellen zum Verwalten von Lookupdaten<\/h2>\n
Bevor wir uns den übrigen Tabellen zuwenden, schauen wir uns noch alle Lookup- oder Nachschlagetabellen an, die wir neben tblAnreden <\/b>und tblLaender <\/b>noch benötigen. Diese heißen wie folgt und enthalten die angegebenen Felder:<\/p>\n