Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Diskussionen zu "Datenmodelle" von astern
Gehe zu Seite Zurück  1, 2, 3, 4  Weiter
zurück: Summieren und letzter Wert weiter: Aufbau einer Tabelle wie mit SVERWEIS Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Diskussion Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
0622trapper
Eher Einsteiger, Tabkalk-Grundkenntnisse


Verfasst am:
24. Nov 2009, 20:32
Rufname: Stefan
Wohnort: Heidelberg

fragen zu model hausvermietungv01 von astern - fragen zu model hausvermietungv01 von astern

Nach oben
       Version: Office 2007

hallo astern,

habe mich die letzten vier stunden mit deiner Version 1, also dem beziehungsfenster beschäftigt,
bei dieser Thematik reicht die tolle Anleitung, die du fürs Datenbankerstellen geschrieben hast nicht aus, weil man vorher eben nicht weis, welche Objekte extra tabellen werden sollen, oder eben nur attribute.

Ich habe in meinem Wirtschaftsinformatik Kurs die möglichen Normalformen durchgenommen, die eine Datenbank erfüllen kann, und versucht, dieses Konzept auch anzuwenden, z.B bin ich gedanklich so vorgegangen:

eine (mit einem vertrag verbundene) wohnung erfordert im laufe der Zeit mehrere nebenkostenvorauszahlungen. Also müssen diese (weil sie wie eben erkannt, nicht voll funktional von "wohnung" abhängig sind, in eine extra tabelle (gemäß den Erfordernissen der 2. Normalform).

Leider kann ich meine Gedankengänge an dieser Stelle nicht konsequent weiterführen, weshalb ich deine Gedanken bezüglich der Verknüpfungen deiner Tabellen

Miete<->>Nebenkosten<<--Nebenkostenart-->>Nebenkostenzahlung<<--Mietzahlung<<--Vertrag

sehr sehr gerne nachvollziehen könnte. es werden leider nur 1--n beziehungen angezeigt, gibt es für mögliche 1:1 beziehungen gar keine notation im beziehungsfenster?

warum sind die Tabellen Nebenkosten und Nebenkostenzahlung Zwischentabellen?
kann man bei dieser Frage auch so wie in deiner Anleitung argumentieren, eben mit den sich verändernden Werten, über die Zeit hinweg, oder

ist es einfach eine logische Konsequenz aus zum Beispiel dem folgenden Gedankengang:

Eine Nebenkostenart enthält viele Nebenkostenzahlungen und eine Mietzahlung enthält viele Nebenkostenzahlungen. Also ist Nebenkostenzahlungen eine Zwischentabelle...

Wie gehst du gedanklich vor, woran erkennst du, dass du eine extra Tabelle brauchst, verwendest du gedanklich das Normalisierungskonzept?

Rätst du mir einfach mal 2 häuser, 2 wohnungen, 2 mieter, 2 verschiedene nebenkostenhöhen usw. probehalber einzutagen um dann per abfragen die funktion zu prüfen?

Irgendwie muss ich ja weiterkommen! Ich will nicht nur deine Lösung kopieren, sondern auch die nötigen Gedankengänge richtig verstehen.

Vielen Dank
und viele Grüße

P.S ich bin mir nicht sicher, wie man eigentlich als nutzer jetzt sieht, dass ich diese, mittlerweile alte diskussion, wieder beleben will, wie funktioniert dass, oder muss einem der Diskussionsteilnehmer eine private Nachricht schreiben, damit sie darauf aufmerksam werden, hoffentlich keine gar zu dumme Frage... Smile

_________________
“…endure a hundred times, strengthen yourself a thousand times , and you will complete your tasks in short order…You have to be brave and persevere wheter there is opposition or not
KlausMz
Moderator Access


Verfasst am:
24. Nov 2009, 20:44
Rufname:
Wohnort: Irgendwo in der Pfalz


AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Hallo,
Zitat:
P.S ich bin mir nicht sicher, wie man eigentlich als nutzer jetzt sieht, dass ich diese, mittlerweile alte diskussion, wieder beleben will, wie funktioniert dass, oder muss einem der Diskussionsteilnehmer eine private Nachricht schreiben, damit sie darauf aufmerksam werden, hoffentlich keine gar zu dumme Frage.
die Meisten die hier auf Beiträge antworten, haben die Email Benachrichtigung aktiviert. Bzw. das ist Forenstandard. Da AStern in diesem Thema schon geantwortet hat, wird er hier informiert werden und bestimmt wieder antworten.
_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
astern
Datenmodell-Missionar


Verfasst am:
25. Nov 2009, 01:24
Rufname: Andreas
Wohnort: Rastede

Re: fragen zu model hausvermietungv01 von astern - Re: fragen zu model hausvermietungv01 von astern

Nach oben
       Version: Office 2007

astern am 24. Nov 2009 um 20:41 hat folgendes geschrieben:
Hallo!
Ich hab's gelesen - schaff's aber jetzt nicht sofort zu antworten.
Momentchen ...
A*

Zitat:
weil man vorher eben nicht weis, welche Objekte extra tabellen werden sollen, oder eben nur attribute.
Das ist ziemlich einfach: Ein Objekt (z.B. "Mieter") hat Eigenschaften (z.B. "Name") und es gibt mehrere, unterscheidbare Vertreter davon (z.B. "Meier", "Schulze", "Krause").
Eine Eigenschaft HAT keine Eigenschaften, sondern IST eine Eigenschaft. Fertig!

Zitat:
gibt es für mögliche 1:1 beziehungen gar keine notation im beziehungsfenster?
Die gibt es, aber 1:1-Beziehungen machen in den allerallerallermeisten Fällen keinen Sinn!!

Zitat:
warum sind die Tabellen Nebenkosten und Nebenkostenzahlung Zwischentabellen?
Dazu lies Dir nochmal den 4. Schritt meines Tutorials durch (Datenmodell entwickeln: Welche Tabellen und Beziehungen?)
Ich verwende bei meinen Überlegungen zur Datenmodellierung die Normalisierung ÜBERHAUPT nicht! Dazu eine kurze historische Abschweifung:
Ich habe nicht Informatik studiert, sondern mir das alles im Selbststudium beigebracht. Dabei bin ich zunächst auch auf den "Leim" der Normalisierung gekrochen. Dann hatte ich einen Lehrauftrag "Informatik" an einer Fachhochschule und habe versucht, den Studenten das beizubringen. Keine Chance! Das kapiert KEIN MENSCH! Weil es auch irgendwie unpraktisch und lebensfremd ist. Ich habe mir daher eine eigene Methodik zugelegt (siehe Tutorial), die bei konsequenter Anwendung AUTOMATISCH zur 3. Normalform führt!

Die Denkweise ist z.B. so:
Zu EINER Miete gehören MEHRERE Nebenkostenarten.
EINE Nebenkostenart gehört zu MEHREREN Mieten.
Also eine m:n-Beziehung zwischen miete und nebenkostenart.
Also eine Zwischentabelle miete_nebenkostenart (heißt hier "nebenkosten").
Dann gehören Mengen und Zeiten in die Zwischentabelle!
Woran merkt man das?
Einfach mal den Satz aussprechen: "Bei dieser Miete betragen die Heizkosten 120 Euro."
"120 Euro" ist WEDER Eine Eigenschaft von miete NOCH eine Eigenschaft von nebenkostenart.
Es ist eine GEMEINSAME Eigenschaft von miete und nebenkostenart.
Wieso? Versuch einfach mal, in dem Satz das Wort "Miete" oder das Wort "Heizkosten" wegzulassen! Behält der Satz dann seinen Sinn? Nein! (Achtung: "Die Heizkosten betragen 120 Euro." ist NICHT korrekt! Nur bei DIESER Miete! Bei einer anderen sind es vielleicht 150 Euro!!)

Zitat:
Wie gehst du gedanklich vor, woran erkennst du, dass du eine extra Tabelle brauchst, verwendest du gedanklich das Normalisierungskonzept?
s.o.!

Zitat:
Rätst du mir einfach mal 2 häuser, 2 wohnungen, 2 mieter, 2 verschiedene nebenkostenhöhen usw. probehalber einzutagen um dann per abfragen die funktion zu prüfen?
Auf jeden Fall! Wenn das Datenmodell halbwegs steht, sollte man in alle Tabellen Testdaten eintragen.

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!
tk6
SAP-Consultant


Verfasst am:
25. Nov 2009, 02:20
Rufname:

Re: fragen zu model hausvermietungv01 von astern - Re: fragen zu model hausvermietungv01 von astern

Nach oben
       Version: Office 2007

astern - 25. Nov 2009, 00:24 hat folgendes geschrieben:
Das kapiert KEIN MENSCH! Weil es auch irgendwie unpraktisch und lebensfremd ist.
Das ist natürlich Unsinn. Jedes mathematische oder logische System ist erstmal, so, wie es daher kommt, "unpraktisch und lebensfremd", aber damit ist die Aussage auch schon inhaltsleer.

An ein solches System kann überhaupt nicht der Anspruch gestellt werden, "lebensnah und praktisch" zu sein. Es ist dazu gemacht, bestimmte Erkenntnisse zu verallgemeinern. Damit besteht z.B. die Möglichkeit, den Entwicklern von Datenbanksystemen wie Oracle usw. ein verbindliches Instrumentarium an die Hand zu geben, mit dem sie Praktikern helfen können, ohne von deren praktischer Anwendung auch nur einen blassen schimmer zu haben. Insofern sind sie im Ergebnis "höchstpraktisch".

Entschuldigung, aber das mußte mal gesagt werden. Ich stimme Astern ja zu: Man kann erfolgreich Datenbanken aufbauen, ohne sich jemals mit Normalisierung beschäftigt zu haben. Aber es stört mich generell, wenn wichtige wissenschaftliche Erkenntnisse als unbrauchbar deklariert werden.

Wenn wir keine Wissenschaften hätten, die sich bisweilen "hochtheoretisch" und abstrakt mit den Dingen beschäftigen, säßen wir noch wie die Affen in den Bäumen...

_________________
Beste Grüße

tk
Martin1000
Im Profil kannst Du frei den Rang ändern


Verfasst am:
25. Nov 2009, 02:27
Rufname:
Wohnort: Hier isses schean!


AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Hallo 0622trapper,
hallo astern,

wie du gesehen hast, habe ich ja auch schon mich hier eingebracht (ob erfolgreich, hilfreich ... ist noch fraglich). (--> sorry @astern muss gestehen, dass ich das Thema, etwas vergessen hatte Shock -->EMail-Benachrichtigung sei dank)
Zitat:
Miete<->>Nebenkosten<<--Nebenkostenart-->>Nebenkostenzahlung<<--Mietzahlung<<--Vertrag
Bei genauer Betrachtung stolper auch ich hier über diese Verbindung, als Ansatz könnte man nun die Fragen/Aussagen ansetzen, wie sie astern hervorragen vorschlägt. Ich möchte aber hier mal einen anderen Weg als aster gegangen ist nehmen, da ich mit diesem eine erfolgreich laufende Mietverwaltung stehen habe.

Ein Mietobjekt wird vermietet durch einen Vertrag. Der Vertrag regelt die Nettomiete und Nebenkosten-vorauszahlung-. Üblich kann der Vertrag auch Staffelmieten bzw. Progressionen enthalten, d.h. es gibt zu einem Vertrag mehrer Zahlungsvereinbarungen (Höhe, von, bis). Da die Zahlungen immer differenziert zu vereinbaren sind (siehe Mietrecht), liegt der Gedanke nahe hieraus zwei Tabellen zu machen. Ich meine aber, es geht hier nur um eine Unterscheidung im Bestimmungszweck jedoch um den gleichen Gegenstand --Geld-- (für was, wann, von, bis). Beschreibt man nun den Bestimmungszweck hat man: Mietkosten und Nebenkosten aus sicht des Mieters. Mann kann natürlich die Nebenkosten weiter differenzieren, doch bleiben es Nebenkosten. Aus der Mietvereinbarung her ist es aber völlig unrelevant diese zu trennen, da es sich um einen Vorrauszahlungsvereinbarung handelt und keiner zum Zeitpunkt der Vereinbarung weiß, ob diese als Kosten so anfallen.
Daher meine ich, dass die Tabellen so aufgebaut sein müssten.

Wohnung<-->>Mietvertraege<-->>Zahlungsvereinbarung<<->Kostenarten

Diese Beziehung beschreibt so den SOLL-Zustand der in Zukunft eintretten müsste. Die Wohnung vererbt ihre Eigenschaften an den Mietvertrag (z.B. Wohnfläche = Mietervertagsfläche), der Mietvertrag sein an die Z-Vereinbarung (von, bis - kann nur im Rahmen des Mietvertrages sein) und die Zahlungsarten bestimmen den Zweck, aber keine neu zu differenzierte Objekte.

Umgedreht steht hier der eingetretene IST-Zustand -Zahlungseingang-. Mit einen Ausflug in das Mietrecht kann man auch hier wieder gleichen Ansatz, bestimmen. Ein Mieter kann eine Mietminderung nur auf die Nettomiete machen, jedoch muss er stets die Nebenkosten zahlen die vereinbart o. angefallen sind. Bei den NK handelt sich bis zum Zeitpunkt der Jahresendabrechng. um eine Vorrauszahlung, es ist so "Fremdgeld".
Deutlich wird nun, dass es sich hier nur um Geld auf Konten handelt, aber noch nicht um Kosten, diese Gelder jedoch strickt getrennt zu verwalten sind. Geht man davon aus, dass es sich um eine gewerbl. Wohnungsverwaltung handelt die im Auftrag arbeitet, dann ist sogar die Mietzahlung Fremdgeld. Beides also keine Kosten.

Wenn du nun am Ende sogar Endabrechnungen erstellen möchtes, kommst du meiner Meinung nach nicht um das System der Dopik (klassische Buchhaltung) mit Konten drum herum. Damit würde aus o.g. Tabelle "Kostenarten" eine Tabelle Konten werden. Somit entsteht eine Tabelle "Buchungen" die alles aufnimmt, was eine Bilanz, GuV beinhaltet. Damit auch Zahlungen und Kosten, sodass die Summe aller Buchungen immer auf 0 kommt und du auch Kontrolle über alles hast.
Nun könntes du meinen, dass dies übertrieben ist, doch gerade bei der Endabrechnung, gelangt man bei der Differenzierung der Zahlungen, Kosten usw. in verschieden Tabelle zu fast nicht überschaubare Berechnungsmodellen. Diese habe ich mit der Erstellung einer einfachen Buchhaltung wett gemacht und bekomme auch so bessere Kontrolle über Saldenlisten in die Buchungsvorgänge als wenn dies in unterschiedlichen Tabellen ist. --> es entsteht so ein Hauptbuch <--

Noch zu:
Zitat:
es werden leider nur 1--n beziehungen angezeigt, gibt es für mögliche 1:1 beziehungen gar keine notation im beziehungsfenster?
Eine 1:1 Beziehung würde beschreiben, das es in einer Tabelle einen Datensatz gibt zu dem auf jeden Fall ein Datensatz in einer andern Tabelle steht. Dies wäre Unsinnig, da so die Felder der zweiten Tabelle direkt in die Erste könnten. Meinst du jedoch eine 1:0-1 Beziehung, die aussagt, dass 1 DS in T1 und 0 bis 1 DS in T2 vorhanden sind, kann das Access grafisch nicht abbilden. Jedoch ist dies möglich zu erstellen, indem du das Fremdschlüsselfeld in T2 auf "ohne Dublikate" stellst.

Ich hoffe Dir einen nachvollziehbaren Ansatz beigesteuert zu haben. Wenn Dich das Modell mit Buchhaltung interessiert, kann ich es morgen mal bereitstellen.

Noch zur Normaliserung, am einfachsten ist es manchmal die Augen zu schließen und den Verlauf der Prozess wie sie im normalem Leben sind erstmal vor zu stellen und immer wieder an jedem Punkt die Fragen zu stellen, was bleibt gleich, was verändert sich. (Gleichbleibendes T1; Veränderliches T2) Wie man nun oben herausliest, sollte man auch immer wieder hinterfragen, an was für einem Objekt wird gerade gearbeitet, genauso wie ich oben zeigte werden keine Kosten vereinbart, sondern Geld o. Zahlungsbeträge. Kosten entstehen erst mit der Nutzung durch den Mieter im Zeitverlauf.

Nun erstmal Schluss
astern
Datenmodell-Missionar


Verfasst am:
25. Nov 2009, 10:53
Rufname: Andreas
Wohnort: Rastede

AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Hallo!
Ich kann Deiner verbalen Erläuterung ehrlich gesagt nicht sooo gaanz folgen. Anschaulicher wird das, wenn ich ein Datenmodell vor Augen habe. Wenn Du also bereit bist, das zu veröffentlichen, dann würde ich mir Dein Datenmodell gerne mal ansehen!

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!
Martin1000
Im Profil kannst Du frei den Rang ändern


Verfasst am:
26. Nov 2009, 22:35
Rufname:
Wohnort: Hier isses schean!

AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Kommt!

Bin bloß nicht dort wo die DB liegt!
tk6
SAP-Consultant


Verfasst am:
24. Jan 2010, 20:57
Rufname:

AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Leider ist es mir bisher nicht aufgefallen, aber der Datenbank-Entwurf bibliothek_v03a von Astern aus dem Beitrag vom 20. Dez 2009, 18:02 ist leider falsch. Die "Zwischentabelle" tblBuch_Leser_Mahn enthält zwischen den Feldern mahn_id_f und leser_id_f eine funktionale Beziehung. Eine Mahnung kann immer nur auf einen Leser lauten.

Dieser Fehler hat Auswirkungen:
1. Es entsteht eine Tabelle, bei der häufig (im veröffentlichten Beispiel sogar ausschließlich) das Feld mahn_id_f frei bleibt. Eine "eingebaute" Kontrolle über einen zusammengesetzen Index aus den drei Fremdschlüsselfeldern ist somit nicht möglich.
2. Bei der Erstellung von Abfragen sind Outer Joins erforderlich, was diese komplizierter und fehleranfälliger macht.

Richtig ist der erste Entwurf bibliothek_v03. Aus dem oben gesagten könnte man annehmen, daß dort auch eine Tabelle erforderlich ist, die die Beziehung zwischen dem Leser und der Mahnung abbildet. Dies ist nicht notwendig, weil diese 1:n-Beziehung bereits implizit durch die Beziehungen zwischen tblAusleihe und tblAus_Mahn sowie zwischen tblAusleihe und tblLeser abgebildet ist.

_________________
Beste Grüße

tk
astern
Datenmodell-Missionar


Verfasst am:
25. Jan 2010, 20:08
Rufname: Andreas
Wohnort: Rastede

AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

"Offener Brief" an die Leser dieses Threads
--------------------------------------------
Mein Spezialgebiet sind die Datenmodelle. Ich habe dazu schon viele Forumsbenutzer erfolgreich beraten und mir einen - wie ich glaube - recht guten Ruf hier im Forum erarbeitet. Nun ist es leider so, dass es einen Benutzer gibt ("tk6" - ansonsten völlig anonym), der immer mal wieder in Threads auftaucht, in denen ich poste und der meine Texte als "Unsinn" bzw. "falsch" bezeichnet (siehe z.B. hier in diesem Thread!). Ich habe überhaupt kein Problem damit, über unterschiedliche Lösungsansätze zu diskutieren und ich habe auch kein Problem damit, ggf. zuzugeben, dass ich mich geirrt bzw. etwas übersehen habe. Nobody is perfect! Meine Erfahrung mit tk6 ist jedoch, dass es ihm weniger um die Sache, als um die gezielte Schädigung meines Rufes geht. Ich möchte daher ein für alle mal bekanntgeben, dass ich auf keinerlei Postings von tk6 reagiere, weil unter diesen Voraussetzungen keine sachliche Diskussion möglich ist.
Ich möchte ausdrücklich betonen, dass ich keineswegs die Access-Kompetenz von tk6 infrage stelle. Im Gegenteil - ich habe schon viele hilfreiche Antworten vom ihm hier im Forum gesehen. Es ist nur leider so, dass er mich - aus welchen Gründen auch immer? - "auf dem Kieker" hat; und da mir meine Zeit für solchen Kinderkram zu kostbar ist, habe ich schon vor einiger Zeit jegliche Kommunikation mit ihm eingestellt.

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!
sk42
Im Profil kannst Du frei den Rang ändern


Verfasst am:
21. Feb 2011, 23:47
Rufname:

Re: AW: Diskussionen zu "Datenmodelle" von astern - Re: AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Martin1000 - 25. Nov 2009, 01:27 hat folgendes geschrieben:
Wenn du nun am Ende sogar Endabrechnungen erstellen möchtes, kommst du meiner Meinung nach nicht um das System der Dopik (klassische Buchhaltung) mit Konten drum herum. Damit würde aus o.g. Tabelle "Kostenarten" eine Tabelle Konten werden. Somit entsteht eine Tabelle "Buchungen" die alles aufnimmt, was eine Bilanz, GuV beinhaltet. Damit auch Zahlungen und Kosten, sodass die Summe aller Buchungen immer auf 0 kommt und du auch Kontrolle über alles hast.
Auch wenn der Thread schon älter ist, hoffe ich, daß du das trotzdem noch liest. Smile

Ich habe z.Zt. die Buchungen unterschiedlicher Themen auch in unterschiedlichen Tabellen (ist noch in Arbeit, also noch längst nicht fertig entwickelt), würde das aber auch lieber in einer Tabelle packen (da z.B. auch andere Ausgaben in die Rubrik "Reisekosten" fallen, ohne wirklich eine Reise zu sein, d.h. diese Kosten wären in meiner Tabelle bei den Sachausgaben und somit mit der Bestellungen-Tabelle verknüpft und nicht bei Reisen mit Verknüpfung zur Reisedatentabelle angesiedelt).
Das Problem dabei ist, daß diese Themengebiete (Reisen, Personal, Bestellungen, Zuweisungen) recht unterschiedliche Felder benötigen. Ferner wird bei der Summe aller Buchungen niemals 0 raus kommen, da es verschiedene einzeln abzurechnende Projekte sind und Restmittel aufs nächste Jahr übertragen werden.
Die Zuweisungen sind je nach Projekttyp auch recht unterschiedlich (unterschiedliche Kostenartennummern, unterschiedliche Aufteilung der Buchungen in Gruppen usw.
Macht es bei so vielen Unterschieden überhaupt Sinn, zu versuchen, da eine gemeinsame Buchungstabelle zu machen (da müßten dann ja viele Detailtabellen mit verknüpft werden, die die unterschiedlichen Daten enthalten, zusätzlich noch etliche dieser serh unhandlichen n:m-Verknüpfungen mit Reisen, Projekte, Vertrag usw.) oder sollte ich da lieber bei getrennten Tabellen bleiben?

Zitat:
Nun könntes du meinen, dass dies übertrieben ist, doch gerade bei der Endabrechnung, gelangt man bei der Differenzierung der Zahlungen, Kosten usw. in verschieden Tabelle zu fast nicht überschaubare Berechnungsmodellen. Diese habe ich mit der Erstellung einer einfachen Buchhaltung wett gemacht und bekomme auch so bessere Kontrolle über Saldenlisten in die Buchungsvorgänge als wenn dies in unterschiedlichen Tabellen ist. --> es entsteht so ein Hauptbuch <--
Du hast aber nur ein Konto? Hier hat jedes Projekt, Teilprojekt und Pauschalen ein eigenes Konto, einige Pauschalen unterschiedlicher Projekte sind aber auch auf einem Konto (Projektleiterabhängig) zusammengefaßt (müsten also sowohl getrennt als auch gemeinsam ausgewertet werden). Alle Projekte müssen getrennt abgerechnet werden, Gelder können aber auch zwischen den Projekten umgebucht werden. Ich müßte also die gemeinsame Tabelle zuerst durch Abfragen wieder aufschlüsseln und dann erst auswerten. Confused

Zitat:
Meinst du jedoch eine 1:0-1 Beziehung, die aussagt, dass 1 DS in T1 und 0 bis 1 DS in T2 vorhanden sind, kann das Access grafisch nicht abbilden.
Ab wieviel % der Datensätze, die 0 DS in T2 haben, würdest du das in eine extra Tabelle auslagern?
astern
Datenmodell-Missionar


Verfasst am:
25. Jul 2011, 09:47
Rufname: Andreas
Wohnort: Rastede

AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Hallo!
Die Frage geht zwar an Martin1000 und betrifft eher das Thema "Buchhaltung" als das Thema "Datenmodell" - ich will aber trotzdem kurz meine Meinung dazu sagen.
In einem Fall wie Deinem gibt es meiner Meinung nach keine "Superlösung", die alle Probleme aus dem Weg räumt. Wenn Du für die verschiedenen Buchungsarten verschiedene Tabellen anlegst, ist das auf den ersten Blick bequemer, denn jede Tabelle kann ihre eigenen Spalten haben, so dass die verschiedenen Buchungsarten beliebig verschieden sein können. Das erkaufst Du Dir mit der Unflexibilität der Lösung; denn kommt eine neue Buchungsart hinzu, musst Du eine neue Tabelle anlegen und auch neue Abfragen und Formulare gestalten.
In einer flexiblen Lösung (siehe unten mein Entwurf) hast Du nur eine einzige Tabelle tblBuchung mit einer daran hängenden Tabelle tblBuchungsart. Kommt jetzt eine neue Buchungsart hinzu, trägst Du einfach eine neue Zeile in tblBuchungsart ein, d.h. es ist KEINE Änderung am Datenmodell erforderlich. Jede dieser Buchungsarten hat in meinem Modell unterschiedliche Datenarten (tblBuchungsdatenart); also eine Reisebuchung hat z.B. Startort und Zielort, eine Beschaffungsbuchung hat z.B. einen Lieferanten usw. Das ist zunächst mal die DatenART - der eigentliche WERT steht in der Zwischentabelle tblBuchungsdaten in der Spalte dat_wert. Diese Lösung ist hochgradig flexibel, denn Du brauchst später am Datenmodell nie wieder etwas zu ändern. Du kannst beliebige Buchungsarten mit beliebigen Datenarten hinzufügen. Du erkaufst Dir das mit einem Zusatzaufwand bei der Abfrage- und Formularentwicklung.
Also - Zusammenfassung: Wenn Du von vorneherein absehen kannst, dass es nur eine bestimmte Menge von Buchungsarten geben wird, die Dir zum Zeitpunkt der DB-Entwicklung auch ALLE bekannt sind, dann kannst Du ruhig für jede Buchungsart eine eigene Tabelle anlegen. Wenn Du aber damit rechnen musst, dass im Laufe der Zeit immer mal wieder neue Buchungsarten hinzukommen, dann solltest Du die flexible Lösung wählen!

MfG
A*

PS: FRAGE AN DEN ADMIN: Ich wollte ein Bild mit dem Datenmodell uploaden, bekam aber die Fehlermeldung "Du hast die max. Grenze von 20 MB erreicht." Das klingt gar nicht gut ... kann ich jetzt gar nichts mehr uploaden??

_________________
1. Access-Gebot: Du sollst lange und gründlich über Dein Datenmodell nachdenken!
2. Access-Gebot: Du sollst keine Formulare erstellen ohne gutes Datenmodell!
sk42
Im Profil kannst Du frei den Rang ändern


Verfasst am:
30. Jul 2011, 19:25
Rufname:

Re: AW: Diskussionen zu "Datenmodelle" von astern - Re: AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Hallo astern:
astern - 25. Jul 2011, 09:47 hat folgendes geschrieben:
In einer flexiblen Lösung (siehe unten mein Entwurf) hast Du nur eine einzige Tabelle tblBuchung mit einer daran hängenden Tabelle tblBuchungsart.
Ich bin inzwischen auch zu der Überzeugung gelangt, daß alle Buchungen in einer Tabelle stehen sollten. Nur haben meine Versuche bisher nicht so richtig zum Ziel geführt (habe das in einem neuen Thread beschrieben: Datenmodell bei vielen Fallunterscheidungen). Daher hätte ich seeehr gerne deinen Entwurf gesehen. Schade daß du keine Dateien mehr hochladen kannst. Kannst du mir das ev. per pn schicken?
KlausMz
Moderator Access


Verfasst am:
30. Jul 2011, 19:44
Rufname:
Wohnort: Irgendwo in der Pfalz

AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

@Andreas
Habe Deine Frage zum Upload erst jetzt gelesen. Falls noch nicht geschehen:
Du kannst der Usergruppe "User_Upload_High" beitreten.

_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
astern
Datenmodell-Missionar


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

AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Danke - jetzt kann ich also wieder uploaden!
Hier kommt also das Bild zu dem Posting vom 25.7.

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!



buchungen-v01.jpg
 Beschreibung:
Flexibles Datenmodell
 Dateigröße:  50.67 KB
 Angeschaut:  1149 mal

buchungen-v01.jpg


sk42
Im Profil kannst Du frei den Rang ändern


Verfasst am:
01. Aug 2011, 20:01
Rufname:


AW: Diskussionen zu "Datenmodelle" von astern - AW: Diskussionen zu "Datenmodelle" von astern

Nach oben
       Version: (keine Angabe möglich)

Also das Datenmodell verstehe ich nur teilweise. Was genau ist der Unterschied zwischen Buchungsart und Buchungsdatenart? Was kommt da rein? Wozu das Feld dat_wert? Der Wert (also wieviel Euro) steht doch schon in buch_betrag? Confused

Eine Reise hat ja auch nicht nur Reiseort, sondern u.a. auch Beginn- und Ende-Datum. Das eine ist ein Textfeld, das andere ein Datumsfeld. Das läßt sich doch gar nicht mit nur einem Feld und der Auswahl eines Typs darstellen. Ein Feld kann doch nur entweder ein Textformat oder ein Datumsformat sein, aber nicht wahlweise abhängig von Typ?

Ferner (um beim Beispiel Reisen zu bleiben) gibt es da bestimmte Daten, die alle gefüllt werden müssen (z.B. Reisebeginn und Reiseende und Reiseort). Das mache ich immer mit der Kombination der Eigenschaften "Eingabe erforderlich = ja" und "Leere Zeichenfolge = Nein" des jeweiligen Feldes. Wenn ich zu einer Buchung nun mit einer 1:n-Beziehung nur das Datum und dann als Typ "Beginn" auswähle, könnte ich doch jetzt aber beliebige Kombinationen eintragen oder auch nur "Reisebeginn". Auf Tabellenebene kann ich das doch gar nicht mehr kontrollieren, ob da jetzt wirklich zu einer Reise die nötigen Daten Reisebeginn und Reiseende und Reiseort eingetragen werden vom Anwender? Ferner gehören Reisebeginn, Reiseende, Reiseort doch eigentlich gar nicht zu den Buchungen, sondern zu den Reisedaten, was ja aber eine ganz andre Tabelle wäre?
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Gehe zu Seite Zurück  1, 2, 3, 4  Weiter
Diese Seite Freunden empfehlen

Seite 2 von 4
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: Problem beim Datenmodell entwickeln nach astern 22 Der Bayer 864 11. Dez 2012, 18:08
Gast Problem beim Datenmodell entwickeln nach astern
Keine neuen Beiträge Access Tabellen & Abfragen: Klausurfrage: Datenmodelle 3 Klausurschreiber 246 13. Jun 2012, 15:45
JMalberg Klausurfrage: Datenmodelle
 

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