Sinnvoller aufbau einer DB

[Codehunter]

Zitat von haentschman:

Moin...

Zitat:

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.

Da hat mit Sicherheit die DSGVO was dagegen.

Genau. Am besten man speichert Personaldaten nur noch verschlüsselt und mit Zertifikat gesichert. Bei einer Volltextsuche rennt dann erstmal eine Brigade von Datenschutzbeauftragten durch die Firma und holt sich von jedem evtl. betroffenen MA die schriftliche Einwilligung zur fallbezogenen Einsichtnahme in seinen Datensatz. Natürlich in Papierform. Und die scannt man dann ein und speichert sie (nachdem man ein weiteres Mal die Einwilligung dazu geholt hat) im DMS. Am besten packt man den Passierschein A38 auch gleich dazu.

Die DSGVO macht IMHO keine Vorschriften bzgl. Datenmodell sondern der Möglichkeiten der Einsichtnahme und Übermittlung.

[stifflersmom]

Die Day-Spalte würde ich mir auch schenken und den Tag aus der Startzeit ermitteln. Das allerdings bedeutet, dass Du keine Zeiträume über den Tageswechsel hinaus eintragen kannst, sondern selbst dafür sorgen musst, um 23:59:59 zu stoppen und dann um 00:00:00 wieder zu starten. Auch würde ich die Arten nicht über einen String sondern auch wieder über eine ID aus einer anderen Tabelle referenzieren (WorkTypes).

WorkTypeID
1 / Work
2 / Travel
3 / Pause
...

employe_id / Worktype / Start / End
1 / 1 / 01.01.2019 22:00:00 / 01.01.2019 23:59:59
1 / 1 / 02.01.2019 00:00:00 / 02.01.2019 04:15:00

[pertzschc]

Schau Dir mal Kimai an. Das macht genau diese Erfassung für Dich und Dein Team und ist einfach aufzusetzen.
Wenn Du es in Delphi dennoch programmieren möchtest, kannst Du Dir ja deren Datenbankdesign einmal anschauen.
Grüße, Christoph

[Beach]

Kimai ist ein sehr interessantes Projekt. Wenn ich mir es auch momentan nicht vorstellen kann das es für unsere Tätigkeiten passt.
Um an das DB Design zu kommen müsste ich es leider zuerst installieren. Da habe ich im Moment keine Gelegenheit zu.

Aber mir geht es auch eigentlich auch darum ein eigenes Projekt zu haben, um zu lernen. Wenn es dann einen Nutzen für mich hat, umso besser.

Daher vielleicht mal als kleine Erklärung der Hintergründe (für diejenigen die es Interessiert. Andere einfach überlesen bitte) :

Was mir so als "Komplettanwendung" durch den Kopf geistert wäre das Erstellen von Serviceberichten / Hallenberichten (das was in der Firma gearbeitet wird) und das automatische Einfügen der Arbeitszeiten in die DB, so das am Monatsende der monatliche Stundenbericht für die Personalabteilung und für unsere Reisekostenabrechenung (in sehr vereinfachter Form) erstellt werden kann.
Diese Sachen werden bei uns momentan komplett über verschieden Excel Tabellen händisch gepflegt. Braucht man wohl nichts weiter dazu zu sagen.
Hat man die Daten aber erstmal in einer DB, kann man sich vieles erleichtern damit.

Nun bin ich aber was das Thema Programmieren angeht noch absoluter Anfänger. Habe zwar vor Jahren mal öfters mit PHP Scripten zu tun gehabt, daher kommen auch Grundkenntnisse im Bereich Datenbanken, wenn dieses auch stärker eingerostet sind als ich gedacht habe. Ansonsten ist das alles recht neu für mich.
Daher versuche ich Momentan erstmal Umsetzungen in kleinen Teilbereichen, auch um halt vieles erstmal zu lernen. Aber mit dem Augenmerk das ganze irgendwann mal zu einem großen zusammen zu bringen. Daher auch die Überlegung auf ein RDBMS zu wechseln. Denn sonst würde SQLite mir bis auf weiteres erstmal reichen.
Ich will nicht zu viel auf einmal angehen Für mich sonst wächst mir das schnell über den Kopf.
Meine erster Teil aus diesem "Projekt" war das Thema "Hallenberichte", der Überschaubarste Teil. Das ganze habe ich auch hinbekommen das es soweit das macht was ich mir darunter vorgestellt habe.
Allerdings alles nach dem Motto "Hauptsache es funktioniert". Als Anfänger braucht man schließlich Erfolgserlebnisse. Verbesserungspotenzial in allen Bereichen ist noch zur Genüge vorhanden.

Warum dann nicht diesen Bereich erstmal auf Vordermann bringen?
Naja, die Ursprüngliche Idee ist halt die Zeiterfassung (manuell) und das Erstellen des monatlichen Stundenbericht. Deshalb würde ich gerne mit diesem Teil weitermachen. Zeiten und Angaben eingeben, vergleichbar mit unserer Excel Tabelle (genaugenommen ist es eine OOo Calc Tabelle) und als Ergebnis den Ausdruck für die Personalabteilung und ein paar Statistiken für mich selber. Alle anderen Ideen ist erstmal Nebensächlich....
Dabei dann auch Prgrammtechnisch besser/sauberer werden.

[p80286]

Anmerkung zur Personalnummer:
Auch wenn sie meist nur aus Ziffern besteht, ist sie keine Zahl (führende Nullen)

Gruß
K-H

[jobo]

Zitat von stifflersmom:

Die Day-Spalte würde ich mir auch schenken und den Tag aus der Startzeit ermitteln. Das allerdings bedeutet, dass Du keine Zeiträume über den Tageswechsel hinaus eintragen kannst, sondern selbst dafür sorgen musst, um 23:59:59 zu stoppen und dann um 00:00:00 wieder zu starten. Auch würde ich die Arten nicht über einen String sondern auch wieder über eine ID aus einer anderen Tabelle referenzieren (WorkTypes).

WorkTypeID
1 / Work
2 / Travel
3 / Pause
...

employe_id / Worktype / Start / End
1 / 1 / 01.01.2019 22:00:00 / 01.01.2019 23:59:59
1 / 1 / 02.01.2019 00:00:00 / 02.01.2019 04:15:00

Ja, die Erfassung von Typisierung über eine Referenztabelle ist mehr oder weniger selbstverständlich. Aber wieso sollte man sich diese Art der Zeiterfassung antun und an der Tagesgrenze splitten?
Vielleicht gibt es Handlingargumente, aber ich hoffe, es bleibt nicht am Mitarbeiter hängen, diese Angaben zu tätigen.

[hoika]

Hallo,

Zitat:

Das allerdings bedeutet, dass Du keine Zeiträume über den Tageswechsel hinaus eintragen kanns

Einspruch:
wenn jemand über Mitternacht weg ist, macht das Aufdröseln bei 23:59:59 nicht viel Sinn (wo bleibt dann übrigens die 1 Sekunde?).
Ich hatte das damals mal so gemacht, dass es ein Startdatum, aber kein Enddatum gibt.
Die Zeit selbst wurde komplett auf das Startdatum gerechnet.

[stifflersmom]

Wie gesagt, es ging mir um die Day-Spalte, die anfangs aufgezählt war, und da macht es meiner Meinung nach schon Sinn, den Tageswechsel zu beachten, damit in Summe keine stundenzahl von über 24 für einen Tage ermittelt werden kann

[jobo]

Zitat von stifflersmom:

.. damit in Summe keine stundenzahl von über 24 für einen Tage ermittelt werden kann

Kommt in der Praxis wahrscheinlich selten vor oder?
Tatsächlich sollte m.E. grundsätzlich aber besser das abgespeichert werden, was stattgefunden hat, statt proaktive Korrektur eines hypothetischen Auswertungsfehlers. Man kann ja anhand der Daten bei Bedarf dann ermitteln, ob ein Tageswechsel dabei war.
Auswertungen bzw. allgemeine Verwendung dieser Daten würde wahrscheinlich sowieso im Rahmen eines existierenden Schichtmodells erfolgen, wenn tatsächlich zu solchen Zeiten gearbeitet wird.

[Beach]

Also zu dem Thema Tageswechsel...
Es kommt durchaus öfters vor das wir über den Tageswechsel unterwegs sind (Reisezeiten).
Dazu habe ich im Moment aber noch keine wirklichen Gedanken gemacht. Muss ich auch noch nachholen.

Auf jedenfall habe ich mir den Aufbau noch einmal gründlich durch den Kopf gehen lassen. Bin aber immer noch nicht ganz überzeugt....

Im Anhang ein Bild eines ER-Diagramms, um das Prinzip zu verdeutlichen.

In der wt_time_sub sollen alle Zeiten gesammelt werden. Als Typ geb ich an um welche Art es sich handelt z.B. Arbeitszeit oder Urlaub
Nun brauche ich aber eine Beziehung zur Tabelle wt_time_main um die Zeiten einem Tag und einem MA, usw zuzuordnen..
Das, habe ich gedacht über einen numerischen Schlüssel zu machen (Spalte key_time in Tabelle wt_time_main bezieht sich auf Spalte key in Tabelle wt_time_sub).
Dieser Schlüsselwert kommt aber in der wt_time_sub mehrfach vor (es können mehrere Einträge pro Tag und Person sein)
Könnte man das so lösen, oder gibt es eine andere Möglichkeit mehrere Werte in einer Tabelle eindeutig einer Spalte in einer anderen Tabelle zuzuordnen?

PS: Die Beziehungen zwischen wt_time_main zu wt_time_Sub und wt_expenses sind in der Grafik nicht korrekt dargestellt. OOo Base hat da gemeckert wegen FK....