Probleme beim Erstellen einer Access Datenbank

[Areks]

Hallo zusammen,



ich erstelle gerade einer kleine Accessdatenbank zur Verwaltung einer Sportabteilung, da dies bisher noch per Hand geschieht und deutlich einfacher sein sollte, wenn es elektronisch passiert.

Mein Problem liegt jetzt darin, dass ich nicht genau weiß wie ich eine rekursive Beziehung aufbaue und ob ich dies überhaupt muss. Ich habe im Anhang dafür mal 2 Entwürfe angehängt. Im ersten ist nur die "Basis" zu sehen und im zweiten mein Versuch das Problem zu lösen. Zur konkreten Anforderung:

• es gibt Kinder und Gruppenleiter
• die Kinder zahlen monatlich einen Betrag X (zB. 9€) als Gebühr (natürlich durch die Eltern)
• die Gruppenleiter zahlen natürlich nichts
• wenn ein Kind ein Geschwisterkind hat, dann wird der gesamt Betrag günstiger (zB zusammen 14€ statt 18€)
• falls diese beiden Kinder noch ein Geschwisterkind haben wird es wieder günstiger (zB 20€ für alle 3 statt 27€)
• das Spiel geht dann theoretisch beliebig weiter
• jeden Monat muss für jedes Kind eingetragen werden, ob es gezahlt hat und wenn ja wieviel und ob es eine Rückbuchung gab (evtl noch ein Kommentar)

Meine fragen sind daher folgende:

1. wie mache ich den Datenbank klar, dass eine "Person" ein Geschwisterkind hat?
2. wo genau in der Datenbank hinterlege ich die Beitragshöhe?
3. wie genau kann ich sinnvoll eine Sportgruppe darstellen? (1 Gruppenleiter und X Kinder)
4. geht das in meinem zweiten Entwurf überhaupt? Also die Beziehung der DB mit sich selbst. Laut Internet wäre das ein möglicher Weg, aber ich kenne das nicht und Access scheint es aber möglich zu machen (tbl_Person_1 existiert als Tabelle nicht)
5. und zum Schluss: ist die DB ausreichend normalisiert? Sind dort grobe Fehler enthalten?

Sobald die DB dann "in Ordnung" ist würde ich mich dann in die Formulare bei Access einarbeiten.

Danke und Gruß
Areks

 

[h00bi]

so wie ich das sehe sollten die daten aus tbl_Person_1 eigentlich in tbl_Person stehen.
tbl_geschwister sollte nur die Verwandtschaft matchen.

Grundsätzlich ist das Konzept aber unnötig kompliziert.
Weil eigentlich zahlt ja nicht Kind1 9 Euro und Kind2 9 Euro und die Eltern xx Euro sondern die Eltern zahlen einen Familienbeitrag und die Kinder sind beitragsfrei.

 

[Areks]

Das Problem ist allerdings, dass bisher nur die Kinder erfasst wurden und nicht die Eltern.

Als Datensatz habe ich also nur die Informationen über die Kinder mit den Bankdaten (Bank und IBAN) der Eltern. Auf den Informationsbögen der Kinder stehen dann noch die Geschwister, dh. bisher haben die Geschwister keinen eigenen Datensatz. Das macht aber aus meiner Sicht Sinn dies zu ändern, wenn man es schon digitalisiert.

Von daher hast du natürlich recht. Bei Geschwistern zahlt nur ein Kind, aber bei den Geschwistern müssten natürlich auch ein "bezahlt" drinstehen.

 

[m.c.ignaz]

Meine erste Idee waere, fuer jedes Kind die Anzahl seiner Geschwister mit abzuspeichern und dann den Beitrag ueber einen Multiplikator in Abhaengigkeit der Geschwisteranzahl zu errechnen.

 

[Areks]

Die Idee hatte ich auch schon. Sie hat aber einen entschiedenen Haken:
Woher weiß das Formular nachher welche Kinder verwandt sind?

 

[The Ripper]

Du könntest eine Tabelle aufbauen:

Verwandschaftsrabatt: VerwandschaftsID, PersonID

​Alle Kinder, die Geschwister zueinander sind, haben die gleiche VerwandschaftsID. Falls zu zusätzliche Informationen zur Verwandschaft speichern möchtest, erstellst du noch eine zweite Tabelle, auf die die VerwandschaftsID dann verweißt.

​VerwandschaftsID, Info1, Info2

​Als Info könntest du zum Beispiel die ID hinzufügen von der Person, welche den Beitrag dann zahlt.

wo genau in der Datenbank hinterlege ich die Beitragshöhe?​

​Die Beitragshöhe kannst du dann über die Anzahl der PersonIDs mit der speziellen VerwandschaftsID ausrechnen.

wie genau kann ich sinnvoll eine Sportgruppe darstellen? (1 Gruppenleiter und X Kinder)​

​Drei Tabellen, wobei PersonID den Gruppenleiter darstellt:

​Personen: PersonID, Info1, Info2, ...

​Gruppenzuordnungen: PersonID, GruppeID

​Gruppen: GruppeId, PersonID Info1, Info2, ...

und zum Schluss: ist die DB ausreichend normalisiert? Sind dort grobe Fehler enthalten?

​Es gibt Algorithmen um bestimmte Normalisierungsstufen zu erreichen. Einfach einmal durchmachen. Welche Stufe für dich in Ordnung ist, musst du bezogen auf die Anwendung entscheiden.
​Logdaten brauchen i.d.R. keine Normalisierung. Umso wichtiger ist es, wenn du häufig mit den Werten arbeitest, insbesondere schreibend.