SQL Datenbank Normalisierung für Dumme

Manfred3

Neuer User
Mitglied seit
12 Dez 2019
Beiträge
49
Punkte für Reaktionen
5
Punkte
8
Vielleicht ist hier ja jemand, der sich auskennt, oder das mal lernen musste. :) Ich beschreibe mein Problem mal an einem fiktiven Beispiel.
Ich habe hier Mitarbeitende:rolleyes:, die haben zu einem bestimmten Datum unterschiedliche Stati. Die können krank, anwesend, auf Montage, im Urlaub usw. sein.
Wie bildet man das korrekt auf einer Datenbank ab? Der erste Teil ist klar, eine Tabelle Mitarbeiter mir einem fortlaufenden Primary Key. Da steht dann Name Telefon, Email usw.
Und dann eine Tabelle welche Jedem Mitarbeiter zu einem bestimmten Datum einen Status zuordnet? Wie mach man so etwas normalisiert? Für einen Datenbankprofi sicher eine lächerliche Frage, aber ich stehe auf dem Schlauch.
 
Du kannst viele Wege einschlagen, die irgendwie alle zum Ziel führen.
Zum einen hast Du als Hauptdatenbank (von SQL über Paradox bis dBase ist je nach Vorwissen und Forderungen alles denkbar) die schon genannte Mitarbeiter-Tabelle mit den persönlichen Daten. Diese verweist dann auf eine gesammelte Datenbank (egal, ob je Mitarbeiter separat oder in einer gesammelten Datenbank (per Filter selektierbar) alle MA zusammen.
Dort ist dann ein Feld Datum, Mitarbeiterschlüssel, Status.
Also bei Status gibt es z.B. "Mitarbeit-Ende" *) Urlaub, "Mitarbeit-Ende" Krank, Montage, Büro, Homeoffice usw. Diese verschiedenen Zustände legst du einfach als Text, Zahl oder was auch immer als Konstante fest und trägst diese Konstante in das jeweilige Feld ein.
So erhält jeder Mitarbeiter zu jedem Datum einen Arbeitsstatus, den du dann auswerten kannst.

*) Im Bereich Spaßzeug darf ich das falsch angewandte Partizip auch entsprechend deuten. :p
 
Zuletzt bearbeitet:
Diese verschiedenen Zustände legst du einfach als Text, Zahl oder was auch immer als Konstante fest und trägst diese Konstante in das jeweilige Feld ein.
Oder auch als weitere Relation (in einer zusätzlichen Tabelle) behandeln und deren PK (primary key) verwenden in der Tabelle mit Datum, MA-PK und dem Status-Feld.

Vorteile:
  • erzwungene Einheitlichkeit der Werte für den "Status" (im Gegensatz zu irgendwelchen "Freitexten" und mit "eingebauter Übersetzung" im Vergleich zu irgendwelchen Zahlen)
  • Wertebereich easy erweiterbar (einfach neue Stati bei Bedarf hinzufügen)
  • Daten leicht(er) nach diesem Kriterium selektierbar (und sortierbar) - z.B. wer ist alles am nächsten Donnerstag "im Urlaub"?
 
  • Like
Reaktionen: Deleted member 273463
Ich würde für diesen Fall drei Spalten vorsehen.
Status
Staus beginn (Datum)
Status ende (Datum)
beim Status "Krank" ist das Ende dann das voraussichtliche ende 8ende der Krankschreibung)
Beim Status "Ausgeschieden" ist das Ende irgend eine Datum weit in der Zukunft (31.12.2999 oder so)

(Bei einer solche Datenbank ist zu bedenken, dass nach dem Ausscheiden des Mitarbeiters dessen Daten nach einer bestimmten Zeit aus dieser Datenbank gelöscht werden müssen. einige Daten eventuell schon vorher, man sollte sich also Werte ausdenken, die in einem solchen Fall in die Felder wandern, damit die Datenbank weiterhin im "gültigen Daten" gefüllt ist (bei NOT NULL ist das dann kein wirklich passenden wert ;-) )
 
Danke für die Hinweise. Manchmal braut man eben einen Anstoß zum Denken.
Da wir in der Spaß-Abteilung sind, früher hätte man eine Exel Tabelle genommen.
Aber man will ja mit der Zeit gehen, heute ist MariaDB angesagt und die Hoffnung stirbt zuletzt,
es soll ja zukunftssicher sein und muss auch für die künftigen 100.000 Mitarbeiter funktionieren.:D
 
Falls Du für jeden Mitarbeiter alle Stati, die es für ihn jemals gab archivieren willst, dann brauchst Du eine Detail-tabelle. Am besten mit eigener fortlaufender ID-Spalte als Primärschlüssel, eine Spalte "MitarbeiterID" welche auf den Primärschlüssel der Mitarbeitertabelle verweist und eine Spalte für das Datum. Für die Spalte "MitarbeiterID" sollte man einen eigenen zusätzlichen Schlüssel erstellen (aber diese NICHT zum Primärschlüssel addieren!) und wegen referentieller Integrität ggf. auch über Foreign-Key nachdenken, falls die Datenbank das unterstützt.
Novize schrieb oben immer "Datenbank" aber ich denke er meint "Tabelle"
 
Kostenlos!

Statistik des Forums

Themen
249,021
Beiträge
2,308,938
Mitglieder
378,822
Neuestes Mitglied
schalex