Laden...

Problem mit Datenbank-Struktur

Erstellt von MnX vor 7 Jahren Letzter Beitrag vor 7 Jahren 2.534 Views
M
MnX Themenstarter:in
15 Beiträge seit 2016
vor 7 Jahren
Problem mit Datenbank-Struktur

verwendetes Datenbanksystem: Microsoft ACCES

Guten Tag zusammen,
ich hab ein kleines Problem und zwar muss ich ein Lohnabrechnungs-System als IT-Projekt abgeben und hatte vor paar Monaten eine Datenbank entworfen die bisher gut lief aber beim Progammieren der Überstunden Abrechnung ist mir aufgefallen das die Beziehung nicht so klappen wie ich es mir gedacht habe und ich hab auch keine wirkliche Idee wie ich diese Umbauen sollte.

Zusammenfassung der Datenbank: Die Abrechnung Nr ist die Personal Nr wo durch in der Lohnabrechnung die Überstunden für den Abrechnungs Monat gefunden werden soll.

Bild von der Datenbank im Anhang

Ich hoffe es kann mir einer sagen was ich da für ein gedanken Fehler drinne habe haha 😄

2.207 Beiträge seit 2011
vor 7 Jahren

Hallo MnX,

das die Beziehung nicht so klappen wie ich es mir gedacht habe und ich hab auch keine wirkliche Idee wie ich diese Umbauen sollte.

Was genau willst du denn erreichen. Kannst du das mal auf den Punkt bringen? Ich frage deswegen in dieser Form, weil ich glaube, dass wenn du das Problem mal sauber aufschreiben kannst, du die halbe Lösung schon gemacht hast 😉

Gruss

Coffeebean

M
MnX Themenstarter:in
15 Beiträge seit 2016
vor 7 Jahren

Was genau willst du denn erreichen. Kannst du das mal auf den Punkt bringen?

Oh tut mir leid. Aktuell ist es so das ich keine Überstunden erstellen kann bevor eine Abrechnung erstellt wurde. Ich will aber das man erst die Überstunden einträgt und dann die Abrechnung durchführt. Hoffe meine erklärung kann helfen 😄

T
2.223 Beiträge seit 2008
vor 7 Jahren

Das erste problem was ich sehe ist folgendes:

verwendetes Datenbanksystem: Microsoft ACCES

Du solltest Access nicht als Datenbank verwenden.
Access ist im .Net Bereich keine Datenbank und sollte auch nicht verwendet werden.

Desweiteren machen die Spaltenprefixe für mich keinen Sinn.
Das verschlechter sogar die Lesbarkeit und Nachvollziehbarkein deiner Struktur.
Ebenfalls solltest du deine Spalten auch voll ausschreiben und nicht verkürzen.
Mit verkürzten Namen kann keiner verstehen was diese bedeuten.

Hier stellt sich auch die Frage ob die generelle Struktur nicht etwas entschlackt werden kann.
Ohne dein Abrechnungsprogramm im Detail zu kennen, würde ich die Strukturen mal prüfen und schauen wo es dort hängt.
Ggf. must du deine aktuelle Struktur verwerfen und neu umsetzen.

Auch wäre erwähnenswert wo das Problem bei deiner Programmierung liegt, dass du ein Problem siehst.

Nachtrag:
Hab jetzt erst deinen zweiten Post gesehen.
Das Problem ist ja, dass deine Überstunden an den Abbrechnungen hängen.
Ist zwar korrekt, führt dann aber zu deinem Problem.

Es wäre sinnvoller wenn deine Überstunden in der Person hängen mit einem Datum.
Über das Datum der Überstunde kannst du dann auch ermitteln zu welcher Abrechnung die Überstunden gehören.

Du musst also die Beziehung von der Abbrechnung hin zu deiner Personal Tabelle führen.
Die Beziehung der Abbrechnung zu deinen Überstunden müsstest du dann noch über eine Relationstabelle mappen.

Dort muss dann drin stehen welche Überstunden zu welcher Abbrechung gehören.
Also ein zusammen gesetzter PK aus Überstunden ID und Abbrechnung ID wären dies dann.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

M
MnX Themenstarter:in
15 Beiträge seit 2016
vor 7 Jahren

In der Aufgabe muss Acces benutzt werden das ist vorgegeben.

Sowie die Abkürzung die sollen vorgenommen werden.

zu deinem Tipp: aber entsteht da nicht das Problem das jeder Mitarbeiter beim erstellen dann ein Festes Datum hat? somit könnte ich Überstunden erstellen aber nur für dieses Datum? oder lieg ich da jetzt falsch

und die Prefix werden noch umgeändert dies ist mir letztens auch eingefallen aber es ist paar Monate her das die Datenbank entworfen wurde.

Nachtrag: Ok das macht schon sinn ich werde dies mal versuchen, ich danke dir viel mal für diesen Ansatz.

T
2.223 Beiträge seit 2008
vor 7 Jahren

@Mnx
Da die Überstunden pro Mitarbeiter und Tag eingetragen werden müssten, macht es schon Sinn die dort zu pflegen.
Da das ganze dann wohl in Access per entsprechenden Masken umgesetzt wird, lässt sich dies scheinbar nicht sinnvoller lösen.

In einer richtigen Anwendung würde man eine extra Maske zum pflegen von Überstunden umsetzen.
Dort müsste man dann z.B. den Mitarbeiter, ein Datum(alternativ auch den Zeitraum bei Tagesübergreifenden Schichten) und die Überstunden angeben.

Sowas in der Art hatte ich vor einigen Monaten für einen Kunden mal umgesetzt.
Dort werden aber die Anfangs- und Endzeiten der Schichten ermittelt.
Zeiten über 8 Std. sind dann Überstunden die rausgerechnet und mit extra Spesen berechnet wurden.
Ist im Kern aber der gleiche Denkansatz.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

M
MnX Themenstarter:in
15 Beiträge seit 2016
vor 7 Jahren

ich besitze getrennte masken für die Abrechnung und Überstunden, es wird ein Datum ausgewählt mit dem DataPicker dies wird dann im Programm gesplitet und das Datum Teil was für uns wichtig ist wird abgespeichert. Tage interessieren in dieser Aufgaben stellung nicht (was in einem richtigen system nicht so wäre.). Das Ansehen und Bearbeiten erfolgt auch in getrennten Masken.
nur als Info falls es hilft

NAchtrag: ich denke ich hab was Wichtiges vergessen zu erwähnen die AbrechnungsID ist die PersonalNr da ein Personal eine eindeutige Abrechnungs-Nr haben soll und ich dies mit der Personal Nr-Gelöst hatte

Ich hab was probiert so sieht aktuell die DB aus (siehe Anhang)

T
2.223 Beiträge seit 2008
vor 7 Jahren

@MnX
Deine Set_U_Ab Tabelle kann so nicht sinnvoll funktionieren!
Du hast dort nur das Datum der Abbrechnung und der Überstunden, dir fehlt aber noch die PersonalNr.
Sonst kannst du diese nicht verwenden, da du pro Mitarbeiter auch doppelte Abbrechnungsdatum und Überstundendatum haben kannst.

Deine aktueller Ansatz ist also keine Lösung, da du nur eine Tabelle zwischen die bestehenden Tabellen gepackt hast aber darüber keine Aussagen zur zusammengehörigkeit der beiden äußeren Tabellen machen kannst.

Sinnvoller wäre es, wenn deine Abbrechnungen eine ID hätten.
Also quasi einen Fremdschlüssel auf eine fortlaufenden ID(Auto Inkrement).
Das gleiche dann bei deinen Überstunden nochmal.
Dann brauchst du eigentlich nur noch eine Relationstabelle in der diese IDs wiederum einen PK bilden.

Dann gehören deine Abbrechnungen und Überstunden primär noch zu dem Mitarbeiter und Datum.
Und die Verknüpfung erfolgt dann über zusätzliche IDs.

Dann sollte sich das Problem erledigt haben, da die Verknüpfungen der Überstunden zu Abbrechnungen dann in deinem Programm gepflegt werden muss.
Dann kannst du deine Überstunden anlegen und nach anlegen der Abbrechnung diese Überstunden hinzufügen in dem du die entsprechenden Einträge in die Relationstabelle packst.

Dann sind deine Abbrechnungen und deine Überstunden erst einmal unabhängig von einerander, können aber durch die Relationstabelle wieder zusammengefügt werden.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

M
MnX Themenstarter:in
15 Beiträge seit 2016
vor 7 Jahren

Tut mir leid aber irgendwie krieg ich das nicht hin.

Kann mir das irgendwie jemand mit einer zeichnung veranschaulichen?
Kam schon bei den eigenen Normalisierungen echt durcheinander

T
2.223 Beiträge seit 2008
vor 7 Jahren

@MnX
Wie sieht den dein aktueller Ansatz aus?
hat sich da was getan oder hast du immer noch den gleichen Stand?

Ich hatte dir ja schon geschrieben, dass du hier eine Relationstabelle nutzen solltest.
Dazu sollte deine Abbrechnung eine extra ID, am besten sogar eine Fortlaufende Nummer als PK haben.


Tabellen Abrechnung_Datum
-ID (PK)
-PersonalNr
-Datum
-Stunden
-BonusNr

Tabelle UStunden_2
-ID (PK)
-Datum
-Stunden
-UStundenNr

Tabelle Abrechnung_UStunden_2
-AbrechnungID
-UStunden_2ID

So kannst du deine Abbrechnungen und deine Überstunden ohne direkte Abhängigkeiten pflegen.
Wenn du dann deine Überstunden einer Abrechnung zuordnen willst, musst du nur in der Abrechnung_UStunden_2 Tabelle einen Eintrag mit der Abrechnugn ID und der UStunden_2 ID machen.
Diese ergeben dann einen zusammengesetzten PK.
Dann weißt du bei deiner Abrechnung welche Überstunden dazu gehören.
Und du kannst beides unabhängig von einerander pflegen, was dein Ursprungsproblem lösen dürfte.
Oder habe ich was übersehen bzw. gibt es noch details die du noch nicht genannt hast?

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

M
MnX Themenstarter:in
15 Beiträge seit 2016
vor 7 Jahren

Diese ergeben dann einen zusammengesetzten PK.
Dann weißt du bei deiner Abrechnung welche Überstunden dazu gehören.
Und du kannst beides unabhängig von einerander pflegen, was dein Ursprungsproblem lösen dürfte.
Oder habe ich was übersehen bzw. gibt es noch details die du noch nicht genannt hast?

Ich danke dir also den Ansatz mit den ID's hatte ich mir auch gedacht nur wusste ich nicht wie die Relation Ansicht machen sollte

in der Relation wo die zusammengefügt werden müsste doch beide mit Duplikaten sein oder seh ich das falsch?

D
985 Beiträge seit 2014
vor 7 Jahren

Nur mal so als Tip:

Erstelle einfach mal eine Klassenstruktur, mit der du deine Daten abbilden kannst. Das Datenbank-Design kannst du anschließend daraus ablesen.

(So sollte man generell immer anfangen und nicht mit der Datenbank)

Beispiel Personal (wäre bei mir Mitarbeiter aber egal), Abteilung und Lohngruppe


class AbteilungDto
{
  public int? Id { get; set; }
  public string Bezeichnung { get; set; }
  public bool? Inaktiv { get; set; }
}

class LohngruppeDto
{
  public int? Id { get; set; }
  public string Bezeichnung { get; set; }
  public decimal? Lohn { get; set; }
  public bool? Inaktiv { get; set; }
}

class PersonalDto
{
  public int? Id { get; set; }
  public string PersonalNummer { get; set; }
  public string Vorname { get; set; }
  public string Nachname { get; set; }
  public int? Lohngruppe_Id { get; set; }
  public int? Abteilung_Id { get; set; }
  public bool? Inaktiv { get; set; }
}

Die Eigenschaften sind im Übrigen ganz bewusst alle nullable.

Eine Abrechnung könnte wie folgt aussehen


class Abrehnung
{
  public int? Id { get; set; }
  public DateTime? Datum { get; set; }
  public int? Personal_Id { get; set; }
  public AbrechnungPositionDto[] { get; set; }
}

class AbrechnungPositionDto
{
  public DateTime? Von { get; set; }
  public DateTime? Bis  { get; set; }
  public decimal? Pause { get; set; }
  public decimal? Stunden { get; set; }
  public decimal? Betrag { get; set; }
}

Warum ein Array für die Positionen? Weil die Positionen direkt zur Abrechnung gehören (sieh es wie ein komplettes Dokument an).

Der Mitarbeiter (dargestellt durch Personal_Id) ist einfach nur eine Referenz-Eigenschaft.

usw. usw.

Wenn du das fertig hast, dann ist das Datenbank-Design eigentlich nur noch abarbeiten nach Schema F.

M
MnX Themenstarter:in
15 Beiträge seit 2016
vor 7 Jahren

Wenn du das fertig hast, dann ist das Datenbank-Design eigentlich nur noch abarbeiten nach Schema F.

Ich hab mit dem Normalisierungs-Formen angefangen so wie es von uns verlangt wird. Dies war laut meinem Lehrer wohl Richtig und ich sollte dies dann in Acces anlegen nur nun wo ich bei den Überstunden angekommen bin hatte ich halt dieses Problem. Ich bin halt ein Schüler und mach da auch gerne noch paar tausend fehler haha 😄

Hinweis von Coffeebean vor 7 Jahren

Keine Full Quotes