Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Datenmodell bei vielen Fallunterscheidungen
zurück: Zahlenreihe - Anzahl der Einträge zählen weiter: union abfrage gruppieren Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Antwort Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
sk42
Im Profil kannst Du frei den Rang ändern


Verfasst am:
29. Jul 2011, 10:40
Rufname:

Datenmodell bei vielen Fallunterscheidungen - Datenmodell bei vielen Fallunterscheidungen

Nach oben
       Version: Office 2003

Hallo:

Ich will die Bearbeitung der Finanzen von Projekten und was verwaltungstechnisch dazu gehört komplett in eine Access-Datenbank übertragen (bisher teilweise Excel-Listen und teilweise Datenbank).

Ein Teil der Datenbank existiert bereits und es wird damit gearbeitet. Aber nun haben sich zum einen Änderungen bei den realen Objekten beim Zusammenhang Projekt - Konto ergeben, so daß dort mein Datenmodell nun nicht mehr stimmt.
Zum anderen habe ich bisher nur Reisen und Personal mit Access gemacht, es sollen nun aber noch alle anderen Finanzen (Bestellungen, Einnahmen usw.) hinzu kommen.

Leider lassen sich die realen Objekte nicht eindeutig und umfassend klassifizieren, d.h. die Art der Bearbeitung und somit die benötigten Datenbankfelder sind anhängig von verschiedenen Bedingungen unterschiedlich und es gibt auch Ausnahmen und Überschneidungen.

Und da grüble ich nun, wie ich das am besten in ein Datenmodell umsetze. Confused

Bisher wähle ich bei z.B. Reisen das Projekt aus, aus dem die Reise bezahlt werden soll. Die Struktur ist so:

Tabelle Projekt --> 1:n --> Tabelle Reisen --> 1:n --> Tabelle Reisekosten
Tabelle Projekt --> 1:n --> Tabelle Arbeitsvertrag --> 1:n --> Tabelle Personalkosten
Tabelle Projekt --> 1:1 --> Tabelle ABO (enthält virtuelle Kontodaten)
Tabelle Projekt --> 1:1 --> Tabelle KZ (enthält ID für Einzahlungen vom Mittelgeber)
Wenn nur die Resien betrachtet werden in der Finanzübersicht funktioniert das soweit auch gut.

Die Projekte sind aber leider nicht einheitlich, d.h. es gibt:
• Hauptprojekt --> 0 od. 1:n --> Konto (ABO)
• Sonderprojekte --> 0 od. 1:n --> Konto (über Teilprojektnummer)
• Teilprojekt --> 0 od. 1:1 od. 0 --> Konto (ABO)
• Projekte mit PP --> n:m --> Konto (ABO) (aber mit Umbuchung, also doch nur 1:n?)
• Sammelkonto (ABO) --> 1:n --> Kleinprojekte
• Allgem.Konto, (ABO, KS, KT) --> keinem Projekt zugehörig
• direkt vom Mittelgeber bezahlt (kein Konto!) --> 1:1 --> Projekt

Als Notlösung habe ich mir bisher damit beholfen, daß ich in der Projekttabelle auch alle "Nicht-Projekte" als virtuelles Projekt mit in der Projekttabelle aufgeführt habe (um die Finanzen zuordnen zu können). Ferner gibt es noch eine interne Beziehung in der Tabelle Projekte:
Tabelle Projekte --> 1:n --> Tabelle Projekte ("Teilprojekt von")

Nun würde ich gerne die Projekte von den Konten trennen (da es zunehmend schwieriger wird, in der Abfrage Projektliste die realen Projekte von diesen "Nicht-Projekten" zu trennen), allerdings soll bei der Zuordnung von z.B. Reisekosten dies weiterhin über "Projekt" erfolgen, da das Konto nur aus Kennziffern besteht (das kann sich ja keiner merken).

Also Tabelle Projekt --> 1:n oder n:m --> Tabelle Konto

Aaaaaber: was mache ich mit den Projekten, die kein Konto haben und den Konten, die keinem Projekt zugeordnet sind? Und was mache ich mit den Ausgaben, die keinem Konto zugeordnet sind, weil sie direkt vom Mittelgeber bezahlt weden, aber trotzdem bei der Finanzübersicht auftauchen müssen, weil von dieser Ausgabensumme eine zusätzliche Pauschale angefordert werden kann, welche dann wiederum auf einem bestimmten Konto landet und dem Projekt zugeordnet werden muß? Confused
Was ich nicht will, ist daß man Projekt und Kontro getrennt in den Formularen den Ausgaben zuordnen muß, denn das ist fehleranfällig (der Zusammenhang Projekt - Konto ist vorgegeben!)

Ferner würde ich die Ein- und Ausgaben gerne in einer Tabelle Buchungen zusammenfassen, weil es überschneidungen in der Ausgabenart gibt, d.h. es können auch Kosten in die Kategorie Reisen fallen, die aber nicht über das Reisen-Formular bearbeitet werden müssen, sondern über "Bestellungen". Aaaaaber auch hier gibt es so viele unterschiedliche Fallunterscheidungen, die jeweils anders bearbeitet werden müssen und somit auch andere Felder benötigt werden, so daß ich da auf keinen grünen Zweig komme. Confused

Es gibt:
Einnahmen
Ausgaben
Festlegungen
Sonstiges (zur Info, z.B. Konferenzgebühr und als Teilsumme einer Ausgaben, z.B. Betrag DB-Fahrkarte zur Abrechnung einer Bahncard)

Bei den Ausgaben sind das im wesentlichen die Kategorien:
Personal
Reisen
Bestellungen
Sonstiges
Diese Ausgaben werden wiederum in 2-4 Stufen klassifiziert.

Noch etwas komplexer ist es bei den Einnahmen. Da gibt es:
Einzeleinnahmen (Kleinprojekte)
Regelmäßige Zuweisungen in unterschiedlicher Anzahl und Höhe pro Jahr
Einmaleinzahlungen pro Projekt
Regelmäßige Mittelanforderungen, unterteilt in verschiedene Einnahmenkategorien und unterschiedliche Bearbeitung und Kategorisierung je nach Mittelgeber.

Ich hatte mir die Struktur grob so gedacht:
Tabelle Konto --> 1:n --> Tabelle Buchungen --> 1:1 --> Tabelle Reisekosten (mit den speziellen Feldern) --> 1:n --> Tabelle Reisne
Tabelle Konto --> 1:n --> Tabelle Buchungen --> 1:1 --> Tabelle Personalkosten (mit den speziellen Feldern) --> 1:n Tabelle Vertrag
Soweit würde das noch passen.
Aaaaber komplizierter wird bei den restlichen Ausgaben:
Tabelle Konto --> 1:n --> Tabelle Buchungen --> 1:n --> Tabelle Rechnungen --> 1:n Tabelle Bestellungen
Tabelle Rechnungen --> n:m Tabelle Inventarnummer

Aber was mache ich nun mit den Festlegungen?
Eigentlich besteht da ja dieser Zusammenhang:
Tabelle Konto --> 1:n --> Tabelle Buchungen --> 1:n --> Tabelle Bestellungen
Oder was mache ich mit dem Rechnungsbetrag? Dieser muß nicht mit den Buchungen übereinstimmen (Skonto, teilwiese Aufteilung des Rechnungsbetrages in verschiedene Buchungen bei Auslandsrechnungen mit MwSt. und bei Inventarisierten Geräten, Abzug von Gutschriften).

Was ich jetzt auch noch nicht mit drin haben sind die mehrstufigen Klassifizierungen und die Einnahmen.

Auch sind n:m-Beziehungen oder über mehrere Tabellen gehende Formulare (also HF mit UF, welches wiederum ein UF ehthält, denn bei UF1 mit UF2 läßt sich UF1 nicht mehr als Datasheet darstellen, was aber für die flüssige Bearbeitung des Vorganges unbeding nötig ist) immer ein Greul, weil man daraus keine dem realen Arbeitsfluß entsprechende Formularen basteln kann (also z.B. Hauptformular Bestellung mit Unterformular als Datasheet Ausgaben in einem rutsch einzugeben, also ohne das Formular zu wechseln). Ferner bin ich inzwischen so oft schon and die Grenzen von Access gestoßen, so daß man entgegen der Empfehlungen doch schon beim Datenmodell die spätere gewünshte Arbeitsweise berücksichtigen muß.

Vielleicht könnt ihr mir ja mal ein paar Denkanstöße bzgl des Datenmodells bei einem so komplexen Zusammenhang (das Problem sind die vielen Fallunterscheidungen und Sonderfälle) geben. Inzwischen sehe ich den Wald vor lauter Bäumen nicht mehr. Confused
RadiatoR
Im Profil kannst Du frei den Rang ändern


Verfasst am:
29. Jul 2011, 14:27
Rufname:


AW: Datenmodell bei vielen Fallunterscheidungen - AW: Datenmodell bei vielen Fallunterscheidungen

Nach oben
       Version: Office 2003

Ui ist das viel text. hast du nicht lust dein datenmodell mal als solches hier bereit zu stellen?

Über die grafische darschtellung ist es leichter ein überblick zu bekommen als hier deine verknüpfungen in Textform in meinen Kopf abzubilden.

Als tool kannst du mysql workbanch oder natürlich access benutzen.
Stefffano
Dazugelernt


Verfasst am:
29. Jul 2011, 15:00
Rufname:
Wohnort: Chemnitz

AW: Datenmodell bei vielen Fallunterscheidungen - AW: Datenmodell bei vielen Fallunterscheidungen

Nach oben
       Version: Office 2003

Hallo sk42,

da muß ich RadiatoR recht geben, es ist sehr viel Text und sehr schwierig das nachzuvollziehen.
Am besten sind immer noch Papier und Bleistift um sich über die Beziehungen klar zu werden.
Dann würde ich auch erstmal davon abgehen, alles sofort in den ganz großen Zusammenhang zu stellen und mir dafür einen Themenbereich nach dem anderen vorknöpfen.

_________________
Schöne Grüße,

Stefan
sk42
Im Profil kannst Du frei den Rang ändern


Verfasst am:
29. Jul 2011, 19:00
Rufname:

Re: AW: Datenmodell bei vielen Fallunterscheidungen - Re: AW: Datenmodell bei vielen Fallunterscheidungen

Nach oben
       Version: Office 2003

Hallo:
Stefffano - 29. Jul 2011, 15:00 hat folgendes geschrieben:
Am besten sind immer noch Papier und Bleistift um sich über die Beziehungen klar zu werden.
Ich habe da schon dutzende von Zetteln bekritzelt, so daß das inzwischen recht unübersichtlich geworden ist. Smile

Zitat:
Dann würde ich auch erstmal davon abgehen, alles sofort in den ganz großen Zusammenhang zu stellen und mir dafür einen Themenbereich nach dem anderen vorknöpfen.
Nun, das ist nur ein Themenbereich aus einer größeren Datenbank. Wink
Ich habe alles drumherum weggelassen (alles was mit *_FK bezeichnet ist, weist auf andere Tabellen, die teilweise zu anderen Modulen gehören) und nur die Finanzen selber betrachtet.

In Access habe ich den jetzigen Bereich noch nicht gemacht, da dieser in eine bestehende Datenbank integriert werden muß, mit der bereits gearbeitet wird. Das werde ich daher erst machen, wenn das Datenmodell steht, da ich dafür das Backend so lange sperren muß.

Daher kritzel ich das bisher alles auf Schmierpapier und versuche die Struktur mit Dia darzustellen. Aber das paßt alles noch nicht. Ich habe auch versucht, Sätze zu bilden wie hier Datenmodell entwickeln: Welche Tabellen und Beziehungen? beschrieben, aber das funktioniert aufgrund der vielen Fallunterscheidungen und Sonderfälle nicht so richtig.
Da wohl nicht jeder das Dateiformat von Dia lesen kann und bei einer Darstellung als jpg entweder die Datei zu groß oder die Schrift zu winzig würde, dabe ich die Dia-Datei mal als PDF exportiert. Da kann man dann schön hineinzoomen.

Edit:
Die Zeilen die mit + beginnen, sind die Felder. Da drunter steht dann teilweise Kommentar.
PK ist der Primärschlüssel, FK der Fremdschlüssel. Viele Tabellen und Hilfstabellen wurden der besseren Übersicht wegen weggelassen. Hilfstabellen dienen mir dazu, nur bestimmte Dinge auswählen zu können, was Fehleingaben (unterschiedliche Schreibweisen usw.) verhindert, aber es dient auch dazu, die Daten nach fest vorgegebenen Kriterien zu klassifizieren. Somit kann ich dann später diese Schlüsselfelder als eindeutige Abfragekriterien benutzen. Deshalb tauchen in meinen Tabellen so oft nur Fremdschlüssel auf statt realer Daten. Als Primärschlüssel verwende ich ausschließlich Autowert-ID-Felder.



Finanzen01.pdf
 Beschreibung:

Download
 Dateiname:  Finanzen01.pdf
 Dateigröße:  149.75 KB
 Heruntergeladen:  33 mal

astern
Datenmodell-Missionar


Verfasst am:
01. Aug 2011, 09:36
Rufname: Andreas
Wohnort: Rastede


AW: Datenmodell bei vielen Fallunterscheidungen - AW: Datenmodell bei vielen Fallunterscheidungen

Nach oben
       Version: Office 2003

Oweh,
da hast Du Dir was vorgenommen! Das sieht nach SEHR viel Arbeit aus.
Du must aber nicht bei Null beginnen. Googel doch einfach mal nach "Datenmodell Buchhaltung". Dann findest Du z.B. diese Diskussion mit einigen nützlichen Links:
Datenmodell für die Buchführung - Buchungsprogramm
Dort wird auch das Programm LX-Office erwähnt. Dessen Entwickler haben ihr Datenmodell veröffentlicht:
All Relationships
Vielleicht kannst Du daraus auch etwas entnehmen.

Ohne mich in Deine Problematik vertieft zu haben, würde ich sagen: Du hast Dich jetzt schon dermaßen in Einzelheiten und Spezialfälle verstrickt, dass Du wohl den Überblick über das große Ganze verloren hast. Am besten, Du schiebst alles bisher gemachte und gedachte beiseite und fängst nochmal ganz von vorne an nach dem von mir vorgeschlagenen Schema (Datenmodell entwickeln: Welche Tabellen und Beziehungen?):
- Welche Objekte habe ich? (Buchungen, Konten, Projekte, ...)
- Wie hängen diese zusammen? ("Zu EINEM ... gehören MEHRERE ...")

Dabei solltest Du UNBEDINGT auf eine korrekte Namensgebung der Tabellen achten!!
Damit meine ich folgendes: Eine Tabelle sollte so heißen, wie das Objekt, das durch eine ihrer Zeilen repräsentiert wird. Eine Tabelle sollte z.B. niemals "tblPersonal" heißen, denn eine Zeile ist nicht ein Personal, sondern ein Mitarbeiter. Also heißt die Tabelle "tblMitarbeiter". Erst dann kann man auch die "A*'schen Sätze" richtig bilden: "Zu EINEM Mitarbeiter gehören MEHRERE Aufträge" statt "Zu EINEM Personal gehören MEHRERE Aufträge". Korrekte und sinnvolle Namen sind GANZ WICHTIG, denn sie sorgen für gedankliche Klarheit!
Was soll z.B. bei Dir eine Zeile der Tabelle "Reisekosten" darstellen? Ein "Reisekost"? Was ist das? "Zu EINEM Reisekost gehört EINE Dienstreise"?

In diesem konkreten Fall muss die Herangehensweise so sein: Es gibt Dienstreisen und Reisekostenarten (Übernachtung, Reise, Tagungsgebühren, ...). Dann gilt:

Zu EINER Dienstreise gehören MEHRERE Reisekostenarten.
Zu EINER Reisekostenart gehören MEHRERE Dienstreisen.

Also gibt es eine m:n-Beziehung zwischen tblDienstreise und tblReisekostenart.
Also entsteht eine Zwischentabelle tblDie_Rart.
Darin steht dann der Betrag für eine bestimmte Reisekostenart bei einer bestimmten Dienstreise.

MfG
A*

_________________
1. Access-Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Access-Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: abfrage mit beliebig vielen kriterien 5 peter.stetter 102 06. Nov 2013, 15:19
Marmeladenglas abfrage mit beliebig vielen kriterien
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell Bestellung / Rechnung 10 Gast 439 13. Aug 2013, 13:24
Gast150313 Datenmodell Bestellung / Rechnung
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell prüfen 8 wagnvo 208 22. Jul 2013, 22:43
Gast150313 Datenmodell prüfen
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell 9 bimar 227 16. Apr 2013, 22:34
bimar Datenmodell
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell für Wörterbuch-, Notitz-, Wissensdatenbank 1 tina_klein 254 09. Apr 2013, 01:45
Gast150313 Datenmodell für Wörterbuch-, Notitz-, Wissensdatenbank
Keine neuen Beiträge Access Tabellen & Abfragen: Preisermittlung mit vielen Faktoren 7 Gastpseudonym 205 03. März 2013, 19:37
Nouba Preisermittlung mit vielen Faktoren
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell Supermarkt 2 ExZell 723 23. Apr 2012, 16:00
JMalberg Datenmodell Supermarkt
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell: Projekt und Konto 18 sk42 1050 23. März 2012, 23:00
Bitsqueezer Datenmodell: Projekt und Konto
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell, Tabellenstruktur - Verlängerung eines Vorganges 3 bobrock42 402 30. Jan 2012, 21:02
bobrock42 Datenmodell, Tabellenstruktur - Verlängerung eines Vorganges
Keine neuen Beiträge Access Programmierung / VBA: Eingabe mit vielen abhängigen Unterformularen aufbauen 5 gebio 188 28. Okt 2011, 14:17
gebio Eingabe mit vielen abhängigen Unterformularen aufbauen
Keine neuen Beiträge Access Tabellen & Abfragen: Datenmodell Auftragsabwicklung 6 quintxl 1863 08. Okt 2010, 02:08
Gast Datenmodell Auftragsabwicklung
Keine neuen Beiträge Access Berichte: Bericht von einzelnen Artikeln bei vielen Datensätzen?? 29 Gast 1018 31. März 2010, 09:04
Gast Bericht von einzelnen Artikeln bei vielen Datensätzen??
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Word VBA