Hi,
jetzt benötige ich nochmal Hilfe.
In der tblMitglieder werden die Beiträge hinterlegt. So kann ich später berechnen welche Einnahmen durch Beiträge erzielt wurden.
Problem:
Es gibt einen Familienbeitrag. D.h. mehrere Mitglieder bezahlen zusammen nur einen Betrag X.
Wenn ich in der Tabelle tblMitglieder jetzt für jeden Familienbeitrag 70 Euro hinterlege bekomme ich bei 3 Mitgliedern 210 Euro. Dabei sind es eigentlich nur 70 Euro, da alle 3 Mitglieder auf den gleichen Familienbeitrag laufen.
Wie kann ich das Ganze so abbilden, dass der Beitrag in tblMitglieder ein Pflichtdfeld bleibt und ich keine Probleme mit der Abrechnung bekomme?
Danke!
Hallo,
da gibt es mehrere Möglichkeiten.
Eine wäre:
Führe in tblMitglieder ein weiteres Long-Feld "HauptmgldID" mit zur Unterscheidung, ob es sich beim aktuellen Mitglied um ein Hauptmitglied (der Beiträge zahlt) oder um ein "Nebenmitglied" (der keine Beiträge zahlt) handelt.
In dieses Feld wird, wenn es sich um "Nebenmitglied" handelt, die ID des dazugehörenden Hauptmitgliedes eingetragen.
Wenn das Feld leer ist/bleibt, handelt es sich um das Hauptmitglied. Mittels Tabellen-Gültigkeitsregel oder auch im Formular wird der Eintrag des Beitrages nur zugelassen, wenn das Feld leer ist, es sich also um ein Hauptmitglied handelt.
Bei der Berechnung der Einnahmen werden nur die DS berücksichtigt, bei denen "HauptmgldID" leer ist.
Hallo,
und noch weitere Möglichkeiten.
Ich denke, hier muss mehr Aufwand betrieben werden. Der Beitrag sollte in der Tabelle Mitglieder nicht erfasst werden. Der Beitrag unterliegt ja Änderungen über der Zeit, wie willst Du das berücksichtigen ? Die alten Beiträge müssen ja erhalten bleiben, sonst sind ja die Daten der Vergangenheit falsch. Es fehlten daher noch einige Tabellen. Eine Tabelle zur Bildung von Gruppen (Familien etc.).In diese Tabelle ist jede Person die zu einer Gruppe gehört (auch Einzelpersonen sind dann eine Gruppe) als Fremdschlüssel aufzunehmen.
Dann wird eine Tabelle benötigt die die Beiträge in je einem Datensatz erfasst. Immer fortlaufend, ein neuer Beitrag (wegen Erhöhung) gibt ein neuer Datensatz. Mit einem Feld für das Gültigkeitsjahr.
Der Fremdschlüssel dieses Beitrags wird dann als Fremdschlüssel in einer weiteren Tabelle erfasst. In diese Tabelle kommt dann auch der Fremdschlüssel zur Gruppe. Du kannst Dann beliebig große Gruppen bilden.
In dem Zusammenhang, ich würde alle Personen in einer Tabelle führen und auf die 1:1 Beziehung verzichten. Über Datumsfelder (Eintrittsdatum z.B.) kannst Du problemlos die Art der Personen unterscheiden.
Wenn man jetzt noch bedenkt, dass manche Personen aus dem Verein austreten und 2 Jahre später wieder eintreten, wird das alles noch viel komplizierter.
Hi,
okay ja, die Möglichkeit klingt auch gut.
Ich hatte mir vorher gedacht eine tblFamilienbeitrag zu machen um die m:n Beziehung zu umgehen.
Wenn ich es mit Haupt- und Nebenmitglied mache kann ich mir dann ein einem Bericht z.B. Rechnung anzeigen lassen wer Hauptmitglied ist, wer die Nebenmitglieder sind die dazu gehören und den Betrag, von dann 70 Euro?!
Ich denke schon!
@MzKlMu
Personen habe ich mittlerweile in einer Tabelle. Ich würde also jetzt eine tblGruppe machen und jedes Mitglied einer Gruppe zuordnen.
Familienmitglieder also in eine Gruppe und zu jeder Gruppe dann einen Beitrag!
Am Ende also tblPersonen, tblGruppe und tblBeiträge.
In tblGruppe muss ich dann für die Fremdschlüssel aus tblPersonen mehrere Werte zulassen?!
Noch eine Frage:
In tblPersonen ist mein Primärschlüssel aus 3 Feldern zusammengesetzt um doppelte Einträge zu vermeiden und, da die Mitgliedsnummer nicht eindeutig ist!
Wie verweise ich auf den Primärschlüssel, der sich aus Name, Vorname und Geburtsdatum zusammensetzt?!
Danke Euch und VG
@ Klaus
siehe auch
http://www.access-o-mania.de/forum/index.php?topic=22512.0
;)
Hallo,
der Primärschlüssel über 3 Felder ist nicht zu empfehlen und machen zusätzlichen Aufwand. Erstelle ein Autowertfeld und verwende dieses einzelne Feld als Primärschlüssel. Über die jetzigen Felder das PS legst einen eindeutigen zusammengesetzten Index. Alle Felder dieses Indexes müssen dann auf Eingabe erforderlich stehen und dürfen keinen Nullstring ("") zulassen. Kann man alles auf Tabellenebene einstellen.
Eine nicht eindeutige Mitgliedsnammer solltest Du bereinigen und dann auch zukünftig verhindern.
Okay, also AutoWert als PK und die drei Felder als Index, quasi Indiziert ohne Duplikate!
Ich möchte aber, dass die Kombination aus den dreien einmalig ist! Wie geht das?
Danke Euch!
Hallo,
siehe Access Hilfe >Index >Mehrfeldindex
Beachte auch die anderen Hinweise dazu in #5.
Danke, habs gefunden! ::)
Wie wird das denn generell gehandhabt. Sollte ich in jeder Tabelle das einen AutoWert als PK verwendet einen Mehrfachindex anlegen um die Eindeutigkeit der Datensätze sicherzustellen?
Hallo,
ich persönlich bevorzuge immer einen Autowert als Primärschlüssel. Zumal eine Zahl als PS als Primärschlüssel besser geeignet ist als ein Text.
Wenn die Tabelle ein Bestandteil einer Beziehung als 1-Tabelle ist, würde ich immer einen Autowert als PS verwenden und diesen PS dann als FS in den entsprechenden n-Tabellen.
Für die Beziehungen ist klar ein AutoWert besser geeignet!
Mir geht es darum.
Wenn ich einen AutoWert als Schlüssel habe und über ein Formular einen neuen Datensatz hinzufüge kann ich ja exakt den gleichen Datensatz eingeben. Einmal dann mit AutoWert 1 und einmal mit 2!
Es gibt Vor- und Nachteile, die man im Einzelfall abwägen sollte:
SQL Server: Natural Key Verses Surrogate Key (http://www.databasejournal.com/features/mssql/article.php/3922066/SQL-Server-Natural-Key-Verses-Surrogate-Key.htm)
10 tips for choosing between a surrogate and natural primary key (http://www.techrepublic.com/blog/10-things/10-tips-for-choosing-between-a-surrogate-and-natural-primary-key/)
Surrogate vs. natural/business keys (https://stackoverflow.com/questions/63090/surrogate-vs-natural-business-keys)
Hallo,
Zitatüber ein Formular einen neuen Datensatz hinzufüge kann ich ja exakt den gleichen Datensatz eingeben. Einmal dann mit AutoWert 1 und einmal mit 2!
nein, eben nicht. Ein zusammengesetzter eindeutiger Index (mit den oben beschriebenen Einstellungen) lässt das genau wie ein zusammengesetzter PS nicht zu.
Den gleichen Datensatz mit Autowert 1 und 2 kann es nicht geben.
Der Autowert darf natürlich nicht mit in den Index genommen werden.
Ja genau!
Das verstehe ich! Meine Frage war dann eben ob man al PK immer einen AutoWert nehmen sollte und dann zusätzlich einen Mehrfachindex für die Eindeutigkeit!?
Hallo,
das lässt sich pauschal nicht beantworten.
Siehe #9 und #11.
Zitat von: AndyMcNab am Juli 06, 2017, 14:06:59
Ja genau!
Das verstehe ich! Meine Frage war dann eben ob man al PK immer einen AutoWert nehmen sollte und dann zusätzlich einen Mehrfachindex für die Eindeutigkeit!?
Ein Mitglied ist eine Entität, also braucht es auch eine eindeutige Nummer in der DB. Sonst mußt Du bei jeder Relation, wo Mitglieder vorkommen, und bei jedem Join unnützen Aufwand treiben.
Anders ist es bei Relationen vom Typ m:n, hier ist ein mehrspaltiger Schlüssel ausreichend.
Hi Leute,
ich habe es jetzt wie Franz, DF6GL gesagt hat geregelt. Mit einem Feld Hauptmitglied, falls das Mitglied Betrag bezahlt, und einem Feld Nebenmitglied falls nicht. Im Feld Nebenmitglied befindet sich dann die ID des jeweiligen Hauptmitlgieds.
Wie kann ich nun die Hauptmitglieder abfragen und darunter gruppiert alle Nebenmitglieder die dazu gehören?
@DF6GL
Habe es jetzt mit Hauptmitglied und Nebenmitglied gemacht.
Wie kann ich jetzt alle Hauptmitglieder abfragen und darunter gruppiert alle dazugehörigen Nebenmitglieder?
Hallo,
ZitatMit einem Feld Hauptmitglied, falls das Mitglied Betrag bezahlt...
So habe ich das nicht gemeint.. Es ist nur
ein Feld ("HMdglID") erforderlich, das die ID ("MitgldID") des Hauptmitglieds speichert.
Gruppierung (Darstellung mit HFO/UFO-Konstruktion):
Erstelle ein Einzel-Form (als HFO) mit Basis zur einer Abfrage, die nur Hauptmitglieder filtert ( "Select * from tblMitglieder Where HMdglID is null" ) Tabelle und darin ein Endlosform (angezeigt mit einem UFO-Steuerelement) mit Basis zu einer Abfrage, die nur die Nebenmitglieder filtert (" Select * from tblMitglieder Where HMdglID is not null" ) .
Die Verknüpfungs-Eigenschaften des UFO-Steuerelementes werden so eingestellt:
Verknüpfen von: HMdglID
Verknüpfen nach: MitgldID
Für eine "echte" Gruppierung wäre ein Bericht einzusetzen.
Hi,
bei mir sieht es so aus.
Ich habe ein Mitglied mit mitgliedID = 1 und das Mitglied ist Hauptmitglied. Nun habe ich ein Mitglied mit mitgliedID = 2 das Nebenmitglied ist und in der Spalte Nebenmitglied die mitlgiedID des Hauptmitglieds speichert, also 1.
Kann ich jetzt keine Abfrage erstellen die mir das Hauptmitglied abfrägt und dann alle Nebenmitglieder wo Nebenmitglied = mitgliedID (vom Hauptmitglied)?
Sonst habe ich ja bei einem Familienbeitrag keine Zuordnung wer denn alles zu dem Beitrag gehört!
Hallo,
habe Dir doch gezeigt, wie das gemacht werden kann. Passe lediglich die Namen der Felder an:
Verknüpfen von: Nebenmitglied
Verknüpfen nach: MitgliedID
Daten sollen mit Formularen angezeigt/bearbeitet werden und nicht direkt in Tabellen, bzw. Abfragen. Die Abfragen für die Formulare habe ich auch gezeigt ("select....")