Hulp gevraagd bij het opstellen van de tabellen

[AMBERTJE]

Hoi iedereen,

Graag zou ik jullie eerlijke mening willen vragen over mijn opzet van een kleine DB in Access.

De opzet is dat de volledige administratieve verwerking van een ledenadministratie van een vereniging of sportclub wordt verwerkt in Access.

Een beperkt overzicht van de entiteiten die in elke ledenadm.voorkomen:
Ledenbeheer:
-registreren nieuwe leden
-opzoeken/wijzigen ledengegevens
-lidkaarten maken
-vernieuwen lidmaatschap

Informatiebeheer:
-mailing versturen
-nieuwsbrief versturen

Financieel beheer:
-ontvangen bijdrage
-versturen aanmaningen
-resultaten opstellen


Voorlopig heb ik 2 tabellen opgesteld maar mijn gevoel zegt dat dit niet helemaal juist is.

Leden

Lid_ID Autonumber
Voornaam Text
Naam Text
Geboortedatum Date/Time
Geslacht Yes/No
Adreslijn1 Text
Adreslijn2 Text
Adreslijn3 Text
Telefoon number
E-Mail Text
Lid_Sinds Date/Time
TypeLid_ID number
Lidgeld_Betaald Yes/No
Rol Text
Nieuwsbrief Yes/No
Commentaar Text

TypeLid

TypeLid_ID Autonumber
Type Text
Commentaar Text

Groetjes,
Ambertje

 

[OctaFish]

Ik zo adresvelden nooit Adreslijn1, Adreslijn2 en Adreslijn3 noemen, want dat kun je niet echt beschrijvende veldnamen noemen. Straatnaam, Huisnummer, Huisnr_Toevoeging, Postcode, Woonplaats (kom ik nog tot 5 ook...) zijn toch veel duidelijker? Verder moet Telefoon een tekstveld zijn; je raakt anders voorloopnullen kwijt. En je zult denk ik niet zo snel het gemiddelde telefoonnummer willen uitrekenen. En Geslacht een Ja/Nee veld? Lijkt me eerder een veld dat een slager gebruikt Gewoon een keuzelijst met tekst, Man/Vrouw lijkt mij voldoende. Laatste opmerking: [Lidgeld betaald] hoort alleen in deze tabel thuis als je éénmalig geld wilt zien. Praat je over een (maandelijkse, jaarlijkse) terugkerende contributie, dan zou ik die in een aparte tabel opslaan, met een betaaldatum erbij. Je wilt immers ook kunnen uitrekenen wanneer iemand weer moet betalen. En of dat gebeurd is. Dat kun je ook op basis van Lid_Sinds, hoor ik je al zeggen.... Maar daarmee bouw je geen historie op; je overschrijft steeds de laatste betaalgegevens. Hoe kun je daarmee bijvoorbeeld een zwarte lijst opstellen van notoire wanbetalers? Dat kan alleen als je een historie opbouwt.

 

[AMBERTJE]

Ik zo adresvelden nooit Adreslijn1, Adreslijn2 en Adreslijn3 noemen, want dat kun je niet echt beschrijvende veldnamen noemen. Straatnaam, Huisnummer, Huisnr_Toevoeging, Postcode, Woonplaats (kom ik nog tot 5 ook...) zijn toch veel duidelijker? Verder moet Telefoon een tekstveld zijn; je raakt anders voorloopnullen kwijt. En je zult denk ik niet zo snel het gemiddelde telefoonnummer willen uitrekenen. En Geslacht een Ja/Nee veld? Lijkt me eerder een veld dat een slager gebruikt Gewoon een keuzelijst met tekst, Man/Vrouw lijkt mij voldoende. Laatste opmerking: [Lidgeld betaald] hoort alleen in deze tabel thuis als je éénmalig geld wilt zien. Praat je over een (maandelijkse, jaarlijkse) terugkerende contributie, dan zou ik die in een aparte tabel opslaan, met een betaaldatum erbij. Je wilt immers ook kunnen uitrekenen wanneer iemand weer moet betalen. En of dat gebeurd is. Dat kun je ook op basis van Lid_Sinds, hoor ik je al zeggen.... Maar daarmee bouw je geen historie op; je overschrijft steeds de laatste betaalgegevens. Hoe kun je daarmee bijvoorbeeld een zwarte lijst opstellen van notoire wanbetalers? Dat kan alleen als je een historie opbouwt.

Bedankt Michel,

Je hebt 100% gelijk, ik was al aan het twijfelen om die 3de tabel aan te maken maar voor de zekerheid vraag ik liever raad aan de experts.
Zal eens aan de slag gaan met deze nieuwe tips.
In die nieuwe tabel zet ik dan een BetaalID alsook LidID omdat ik deze tabel later kan koppelen aan de tabel leden om op te vragen of er wanbetalers zijn.

Klopt deze redenatie een beetje?

Groetjes,
Ambertje

 

[OctaFish]

Dat zie je prima! In tabellen met afhankelijke gegevens, zoals bestellingen en betalingen, neem je de velden op die verwijzen naar je hoofdtabellen. Eigenlijk is zo'n opzet dus vrij simpel te bedenken. Klanten zijn uniek, dus je KlantID is sleutelveld. Betalingen, activiteiten etc. zijn afhankelijke tabellen, waarin je (in mijn voorbeeld) betalingen en activiteiten voor de leden opslaat. Die koppeling maak je op basis van KlantID.

 

[AMBERTJE]

Dat zie je prima! In tabellen met afhankelijke gegevens, zoals bestellingen en betalingen, neem je de velden op die verwijzen naar je hoofdtabellen. Eigenlijk is zo'n opzet dus vrij simpel te bedenken. Klanten zijn uniek, dus je KlantID is sleutelveld. Betalingen, activiteiten etc. zijn afhankelijke tabellen, waarin je (in mijn voorbeeld) betalingen en activiteiten voor de leden opslaat. Die koppeling maak je op basis van KlantID.

Bedankt Michel :thumb:

 

[AMBERTJE]

Bedankt Michel :thumb:

Ik was iets te snel om het draadje af te sluiten, zo ziet mijn 3de tabel er nu uit.
Ik twijfel nog of de naamgeving van het veld [Prijs] wel goed gekozen is maar kan op niets anders komen.
Is dit de goede aanpak Michel?

Betaal_ID AutoNumber
LidID Number
Betaald Yes/No
Prijs Number
BetaalDatum Date/Time

Groetjes,
Ambertje

 

[OctaFish]

Wat ga je vastleggen in de db? Ledenadministratie, of ook wedstrijdadministratie? In het eerste geval zou ik de tabel [tContributie] noemen. Een Ja/Nee veld [Betaald] lijkt mij overbodig; je hebt ook al een betaaldatum. Wel zou ik ofwel in de tabel Leden, ofwel in Contributie vastleggen tot wannneer het lidmaatschap geldig is. Werk je met een lidmaatschap op maandbasis, jaarbasis, schooljaarbasis etc. In het geval van Jaarbasis, gebruik je dan de inschrijfdatum, of altijd de eerste van de maand? etc. In alle gevallen rolt er een einddatum uit, die moet worden getriggerd door de betaling(sdatum).

 

[AMBERTJE]

Ik was iets te snel om het draadje af te sluiten, zo ziet mijn 3de tabel er nu uit.
Ik twijfel nog of de naamgeving van het veld [Prijs] wel goed gekozen is maar kan op niets anders komen.
Is dit de goede aanpak Michel?

Tbl_Contributie

Betaal_ID AutoNumber pk
LidID Number fk
Prijs Number
BetaalDatum Date/Time

Groetjes,
Ambertje

Zo ziet de structuur er nu helemaal uit:

Tbl_Lid

Lid_ID Autonumber pk
Voornaam Text
Naam Text
Geboortedatum Date/Time
Sekse text
Adres Text
Gemeente Text
Postcode Text
Telefoon text
E-Mail Text
Lid_Sinds Date/Time
TypeLid_ID number fk
Betaal_ID number fk
Rol Text
Nieuwsbrief Yes/No
Commentaar Text

Tbl_TypeLid

TypeLid_ID Autonumber pk
Type Text
Commentaar Text

 

[AMBERTJE]

Wat ga je vastleggen in de db? Ledenadministratie, of ook wedstrijdadministratie? In het eerste geval zou ik de tabel [tContributie] noemen. Een Ja/Nee veld [Betaald] lijkt mij overbodig; je hebt ook al een betaaldatum. Wel zou ik ofwel in de tabel Leden, ofwel in Contributie vastleggen tot wannneer het lidmaatschap geldig is. Werk je met een lidmaatschap op maandbasis, jaarbasis, schooljaarbasis etc. In het geval van Jaarbasis, gebruik je dan de inschrijfdatum, of altijd de eerste van de maand? etc. In alle gevallen rolt er een einddatum uit, die moet worden getriggerd door de betaling(sdatum).

Een ledenadaministratie ga ik vastleggen in de db voor de rest niets anders.
Over de duur van het lidmaatschap zal ik nog even moeten nadenken.
De pk's en fk's heb ik ernaast gezet om aan te tonen welke id's van andere tabellen komen.

 

[OctaFish]

Over de duur van het lidmaatschap zal ik nog even moeten nadenken.

Die vraag is toch redelijk essentieel, tenzij je een lidmaatschap zonder einddatum hebt. In het welk geval je maar éénmalig hoeft te betalen, uiteraard.

 

[AMBERTJE]

Die vraag is toch redelijk essentieel, tenzij je een lidmaatschap zonder einddatum hebt. In het welk geval je maar éénmalig hoeft te betalen, uiteraard.

Het lidmaatschap zal jaarlijks betaald worden, moet ik dan nog iets veranderen?

 

[OctaFish]

Hangt van je tabel Contributie af.... Ik noem 'm contributie, maar weet natuurlijk niet welke naam jij gebruikt Ik zou zelf in ieder geval een einddatum opnemen, en een Betaaldatum. Op basis van de Einddatum, en de Betaaldatum kun je bijvoorbeeld op je Ledenlijst formulier een popup maken die tevoorschijn komt als de betaaldatum in het zicht komt. Bijvoorbeeld als je de mensen een mailtje wilt sturen dat hun lidmaatschap over een maand afloopt, en dat ze dus moeten betalen.

 

[AMBERTJE]

Hangt van je tabel Contributie af.... Ik noem 'm contributie, maar weet natuurlijk niet welke naam jij gebruikt Ik zou zelf in ieder geval een einddatum opnemen, en een Betaaldatum. Op basis van de Einddatum, en de Betaaldatum kun je bijvoorbeeld op je Ledenlijst formulier een popup maken die tevoorschijn komt als de betaaldatum in het zicht komt. Bijvoorbeeld als je de mensen een mailtje wilt sturen dat hun lidmaatschap over een maand afloopt, en dat ze dus moeten betalen.

Mmmmm goed idee, zal dat alvast implementeren.
Bedankt Michelleke.

 

[AMBERTJE]

Mmmmm goed idee, zal dat alvast implementeren.
Bedankt Michelleke.

Om de relaties te leggen wou ik nog een kleinigheidje vragen:
Ik wil een relatie leggen tussen tbl_Lid en TypeLid n... op n... omdat ik denk dat een lid meerdere types kan hebben (een lid kan bijv.een actief lid zijn en ook een erelid).
En een Typelid (bijv.actief lid) kan uit meerdere leden bestaan.

Tussen tbl_Contributie en Tbl_Lid wil ik ook een relatie leggen en hier denk ik 1 op 1.

Is dat een goede uitgangspositie?

 

[OctaFish]

Als je per lid meerdere types wilt kunnen vastleggen, dan kun je er voor kiezen om aparte Ja/Nee velden te gebruiken in tbl_Lid (niet zo'n mooie oplossing) of een aparte tabel. Hierin koppel je dan tbl_Lid aan Type_Lid. Uiteraard weer op basis van de sleutelvelden. Daarmee heb je je veel-op-veel relatie, en kun je per lid alle mogelijke combinaties maken. Ik zou dan wel de sleutel op basis van Lid_ID en Type_ID leggen, anders kun je (als je bijvoorbeeld een Autonummer als sleutelveld toevoegt) dubbele combinaties toevoegen, en dat zal niet de bedoeling zijn.... Zet je er ook nog een datumveldje bij, dan weet je straks ook nog wanneer iemand erelid is geworden.... Handig voor jubilea

 

[AMBERTJE]

Als je per lid meerdere types wilt kunnen vastleggen, dan kun je er voor kiezen om aparte Ja/Nee velden te gebruiken in tbl_Lid (niet zo'n mooie oplossing) of een aparte tabel. Hierin koppel je dan tbl_Lid aan Type_Lid. Uiteraard weer op basis van de sleutelvelden. Daarmee heb je je veel-op-veel relatie, en kun je per lid alle mogelijke combinaties maken. Ik zou dan wel de sleutel op basis van Lid_ID en Type_ID leggen, anders kun je (als je bijvoorbeeld een Autonummer als sleutelveld toevoegt) dubbele combinaties toevoegen, en dat zal niet de bedoeling zijn.... Zet je er ook nog een datumveldje bij, dan weet je straks ook nog wanneer iemand erelid is geworden.... Handig voor jubilea

Lid_Id , BetaalID en TypeLid zijn nu sleutels met een autonummer, moet ik dit dan veranderen of lees ik het helemaal verkeerd?

 

[OctaFish]

Hangt er vanaf over welke tabellen je het hebt. In de hoofdtabellen kun je prima autonummervelden gebruiken, al heb je dan geen invloed op het sleutelveld. Als je een bepaalde eigen code wilt voor een sleutelveld (Primary Key), zul je dat zelf moeten (kunnen) maken. In de gerelateerde tabellen komen deze sleutelvelden vaker terug, vandaar de term Foreign Key. De combinatie van de FK's zou ik in jouw geval als sleutel definiëren, om te voorkomen dat je dubbele combinaties toestaat, wat mij niet de bedoeling lijkt. En in dat geval heb je geen Autonummerveld meer nodig, want de sleutel bestaat dan uit meer velden. Bij een PK gaat het er (net als bij een autonmummerveld) om dat een record een unieke eigenschap heeft. De sleutel dus!