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.
Verwalten von Mitarbeitern
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.
Die Tabelle zum Verwalten der Mitarbeiter
Die wichtigste Tabelle ist die Tabelle tblMitarbeiter. Ihr Entwurf sieht wie in Bild 1 aus. Neben dem obligatorischen Primärschüsselfeld namens MitarbeiterID finden wir einige Felder für Name und Adresse vor, womit wir schon einmal den Datentyp Kurzer Text abgedeckt haben.
Bild 1: Entwurf der Mitarbeitertabelle
Diese Felder haben wir im Gegensatz zu einigen anderen Feldern mit dem Wert Ja für die Eigenschaft Eingabe erforderlich ausgestattet, damit diese immer gefüllt werden müssen.
Die Anrede wählen wir über ein Nachschlagefeld aus, das wir für das Feld AnredeID hinterlegen. Die damit verknüpfte Tabelle heißt tblAnreden und enthält die beiden Felder AnredeID und Anrede. In dieser Tabelle haben wir für das Feld Anrede einen eindeutigen Index definiert (siehe Bild 2).
Bild 2: Entwurf der Tabelle tblAnreden
Damit stellen wir sicher, dass jede Anrede nur einmal eingegeben werden kann. Die Beziehungen zwischen der Haupttabelle und den Nachschlagetabellen wie tblAnreden werden über das Fremdschlüsselfeld der Tabelle tblMitarbeiter und dem Primärschlüsselfeld der jeweiligen Nachschlagetabelle wie in Bild 3 definiert.
Bild 3: Verknüpfung zwischen der Haupttabelle tblMitarbeiter und einer Lookuptabelle, hier tblAnreden
Das Land geben wir ebenfalls nicht als Text ein, sondern wählen es über ein Nachschlagefeld aus, wobei die Daten in der Tabelle tblLaender stecken. Diese enthält, wie für die meisten Lookuptabellen typisch, lediglich zwei Felder – das Primärschlüsselfeld LandID und das Feld Land mit der Länderbezeichnung. Auch hier haben wir für einen eindeutigen Index definiert, diesmal für das Feld Land.
Mit dem Feld Geburtsdatum decken wir das Datumsfeld ab.
Das Feld GehaltssteigerungProJahr definieren wir mit dem Felddatentyp Währung und stellen für die Eigenschaft Format den Wert Prozentzahl ein. So erhalten wir für die Werte dieses Feldes die Genauigkeit eines Dezimalfeldes und die Darstellung als Prozentzahl.
Mit dem Feld Foto decken wir den Datentyp Anlage ab, der unter SQL Server so nicht verfügbar ist – so viel vorneweg.
Memofeld mit verschiedenen Eigenschaften
Wir wollen auch Memofelder, die heute unter dem Felddatentyp Langer Text zu finden sind, abbilden, und zwar mit den verschiedenen speziellen Eigenschaften.
In der Tabelle tblMitarbeiter finden wir so die beiden Felder Lebenslauf und Notizen. Lebenslauf ist ein Feld mit dem Datentyp Langer Text und den Standardeinstellungen. Für das Feld Notizen haben wir den Wert der Eigenschaft Nur anfügen auf Ja 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:
ColumnHistory("tblMitarbeiter", "Notizen", "MitarbeiterID = 1")
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 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.
Bild 4: Inhalt eines Memofeldes mit aktivierter Eigenschaft Nur anfügen.
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 (www.access-im-unternehmen.de/1500).
Auf ein Memofeld mit dem Textformat Rich-Text kommen wir später in einer anderen Tabelle zurück.
Webseite und EMail sind beides Felder mit dem Datentyp Link.
Mit Eintrittsdatum und Austrittsdatum stellt die Tabelle weitere Felder des Datentyps Datum/Uhrzeit bereit.
Das Feld Behindert, mit dem wir den Datentyp Ja/Nein abbilden, gibt an, ob der Mitarbeiter eine Behinderung aufweist.
Behinderungsgrad ist ein Zahlenfeld, dem wir über das Format Prozentzahl die Ansicht als Prozentzahl hinzugefügt haben – diesmal allerdings mit der Feldgröße Single, was mit einer geringeren Genauigkeit bei den Nachkommastellen einhergeht als bei Datentyp Währung.
ReligionID, GeschlechtID und SteuerklasseID sind jeweils Fremdschlüsselfelder, die wir als Nachschlagefelder ausgelegt haben und die mit den Tabellen tblReligionen, tblGeschlechter und tblSteuerklassen verknüpft sind.
Weitere Tabellen zum Verwalten von Lookupdaten
Bevor wir uns den übrigen Tabellen zuwenden, schauen wir uns noch alle Lookup- oder Nachschlagetabellen an, die wir neben tblAnreden und tblLaender noch benötigen. Diese heißen wie folgt und enthalten die angegebenen Felder:
- tblGeschlechter (Primärschlüsselfeld GeschlechtID, Textfeld Geschlecht mit eindeutigem Index)
- tblReligionen (Primärschlüsselfeld ReligionID, Textfeld Religion mit eindeutigem Index)
Später benötigen wir noch zwei weitere Lookup-Tabellen, die wir allerdings nicht direkt mit der Tabelle tblMitarbeiter verknüpfen, sondern über weitere Tabellen:
- tblPositionen (Primärschlüsselfeld PositionID, Textfeld Position mit eindeutigem Index)
- tblAbteilungen (Primärschlüsselfeld AbteilungID, Textfeld Abteilung mit eindeutigem Index)
Eine Gemeinsamkeit aller Nachschlagetabellen ist, dass wir das Feld, das den nachzuschlagenden Wert enthält, mit einem eindeutigen Index ausgestattet haben. Dazu haben wir die Eigenschaft Indiziert auf den Wert Ja (Ohne Duplikate) eingestellt.
Außerdem haben wir für diese Felder die Eigenschaft Eingabe erforderlich auf den Wert Ja eingestellt. Damit wird die Eingabe eines Wertes erzwungen, was sinnvoll ist, denn ein Datensatz in einer Nachschlagetabelle ohne Wert ist nicht brauchbar.
Tabelle für die Steuerklassen
Die Tabelle tblSteuerklassen ist eigentlich auch eine reines Lookuptabelle, allerdings enthält diese neben dem Primärschüsselfeld SteuerklasseID und dem Feld Steuerklasse noch ein weiteres Feld namens Beschreibung. Der Entwurf dieser Tabelle ist in Bild 5 dargestellt.
Bild 5: Tabelle zum Speichern von Steuerklassen
Gehälter der Mitarbeiter verwalten
Auch wenn wir keine Lohnbuchhaltung mit diesem Datenmodell ermöglichen wollen, so wollen wir doch zumindest die Gehälter der Mitarbeiter speichern können. Dazu legen wir nicht etwa weitere Felder in der Tabelle tblMitarbeiter an, sondern erstellen eine neue Tabelle namens tblGehaelter. Diese enthält die Felder aus Bild 6.
Bild 6: Tabelle zum Speichern von Gehältern
Die Beziehung zwischen den beiden Tabellen tblMitarbeiter und tblGehaelter ist diesmal andersherum aufgebaut wie bei den bisher vorgestellten Nachschlagetabellen. Diesmal enthält die Tabelle tblGehaelter das Fremdschlüsselfeld, hier namens MitarbeiterID, das mit dem Primärschlüsselfeld der Tabelle tblMitarbeiter verknüpft ist (siehe Bild 7).
Bild 7: Beziehung zwischen den Tabellen tblMitarbeiter und tblGehaelter
Dadurch erreichen wir, dass wir zu jedem Mitarbeiter einen oder mehrere Datensätze in der Tabelle tblGehaelter speichern können. Warum benötigen wir das? Weil sich das Gehalt ändern kann und wir eine Historie darüber benötigen, wann ein Mitarbeiter welches Gehalt bezogen hat. Damit wir wissen, wann welches Gehalt bezahlt wurde, enthält die Tabelle tblGehaelter die beiden Felder VonDatum und BisDatum, die angeben, in welchem Zeitraum dieser Datensatz gültig war.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo