Database

Ontwerp

Voor het ontwerk van de database heb ik het programma MySQL Workbench gebruikt. Het databasemodel kan hier als mwb-file, pdf-file of als png-file geladen worden. Ik heb de MySQL-engine InnoDB gebruikt, zodat foreign-key-constraints gebruikt kunnen worden, die door het databasesysteem automatisch op consistentie gecontrolleerd worden.

Tabellenstructuur

Hoofdtabel

De belangrijkste tabel is de tabel member_entries. Hier wordt de informatie voor elk lid opgeslagen. De meeste velden spreken voor zich. Toch zijn er een paar velden, die misschien niet meteen duidelijk zijn:

Veld	Uitleg
limit_access	Dit veld kan gebruikt worden om bepaalde leden van andere leden af te schermen. Zo is het bijvoorbeeld mogelijk, dat sommige leden hun gegevens alleen voor het bestuur, maar niet voor andere leden ter beschikking willen stellen.
partner	Als de vereniging zoiets als een partnertarief aanbiedt of wanneer leden ook de gegevens van hun partner kunnen bewerken, dan staat hier de index van de partner.
company_information	Voor sommige verenigingen is het belangrijk, dat leden kunnen nakijken, waar andere leden werken en wat voor een functie binnen een bedrijf bekleden. Dit kan hier ingegeven worden.
user_group	Alle rechten binnen het system worden in bepaalde gebruikersgroepen samengevat. Elk lid is lid van ÉÉN gebruikersgroep.
preferred_language	Als in een vereniging leden verschillende nationaliteiten hebben, dan kan in dit veld opgeslagen worden, in welke taal een lid het liefst aangesproken willen worden. Hier kan alleen uit die talen gekozen worden die in de tabel languages gedefinieerd zijn.
membership_type	Dit is voor verenigingen, die verschillende lidmaatschappen aanbieden, bijvoorbeeld met verschillende contributies.
membership_end	Meestal wordt een lidmaatschap aan het einde van het verenigingsjaar beëindigd. Als dit veld op true wordt gezet, dan wordt is deze persoon nog steeds lid, maar kan aan het eind van het vereingingsjaar bijvoorbeeld naar oudleden verschoven worden.

Adresgegevens

De adresgegevens worden in een eigen tabel opgeslagen. Dit heeft het voordeel, dat er meer dan één adres per lid opgeslagen kan worden. het tweede voordeel is, dat bij partners hetzelfde adresveld gebruikt kan worden, zodat adreswijzigingen automatisch voor beide leden gelden. Voor de verbinding tussen de adressen en leden is er een mapping-tabel. Voor elk lid moet er bij één van de adressen het veld main_address op true staan. Dit is het postadres dat wordt gebruikt voor de correspondentie (voor zover deze niet per email gaat).

Het veld address_type definieert, wat voor een adrestype dit adres is. Dit wordt door de administrator vastgelegd en wordt bijvoorbeeld gebruikt voor thuisadres, studieadres, werkadres, enz.

Talen en vertalingen

In de tabel languages staan alle talen, die door de gebruiker gekozen kunnen worden, waarvoor er dus een vertaling van alle teksten in het system ter beschikking staat. Het systeem zoekt in de tabel met de vertalingen een vertaaltekst naar module (module waarin de tekst gebruikt wordt, bijvoorbeeld de bestandsnaam), language (de taal van het tekstblok) en key (een begrip, dat per module uniek moet zijn).

Studentenverenigingen

Als het systeem voor een studentenvereniging gebruikt wordt, dan is het handig als bij de leden ook staat welke studierichting zij studeren. In de tabel fields_of_study zijn alle studierichtingen gedefinieerd, waaruit de leden kunnen kiezen. Door het gebruik van de tabel studies_student_map kunnen leden meer dan één studie volgen, waarbij dan ook het begin- en eindjaar kan worden ingevuld.

Commissies

De meeste verenigingen hebben ook commissies, zoals sportcommissie, feestcommissie, enz., maar ook het bestuur. Voor elke commissie wordt gedefinieerd, welke functies mogelijk zijn. Via de tabel committee_function_map wordt gedefinieerd, welke functies in welke commissie mogelijk zijn. Via een tweede tabel, committee_member_map, wordt vastgelegd, welke lid in welke commissie welke functies bekleed.

Emaillijsten

In de meeste verenigingen zijn er diverse emaillijsten, bijvoorbeeld per commissie, voor leden, voor niet-leden, enz. Hier worden de lijsten in de tabel mailinglists gedefinieerd. Als deze lijsten met Majordomo werken, dan kan hier ook direct het emailadres voor het beheer van de lijst en het beheerpasswoord opgeslagen worden. Veranderingen aan emailadressen of aan lijstdeelnemers worden dan direct bij Majodomo doorgevoerd.

Gebruikersrechten

In de tabel user_rights zijn alle rechten gedefinieerd, die een lid kan hebben. Er zijn drie soorten van rechten:

Systeeminterne rechten
Rechten voor een bepaalde commissie
Rechten voor een bepaalde status

Systeeminterne rechten zijn door de programmering van Vereniging 2.0 vastgelegd en kunnen niet worden veranderd. Verder zijn er dynamische rechten, die gebruikt worden om bijvoorbeeld in het menu bepaalde gebruikersgroepen zichtbaar of net niet zichtbaar te maken. Is er bijvoorbeeld de status lid en oudlid, dan is er een recht om leden te bekijken en een recht om niet-leden te bekijken. Hetzelfde geldt voor commissies. Aangezien statie en commissies door de administrator vastgelegt worden, zijn deze rechten dus niet statisch. Ze worden met behulp van twee databasetriggers automatisch aangelegd als er een waarde in één van deze twee tabellen wordt toegevoegd. Ze worden ook door de database automatisch gewist.

Onder value staat de naam van het recht. Is dit een dynamisch recht, dan wordt de naam automatisch door de triggers vastgelegd, volgens het schema view_status_.... of view_committee_....

Een gebruikersgroep vat een set van rechten onder één naam samen. Voor de verbinding tussen deze twee wordt de tabel groups_rights_map gebruikt. Een lid is lid van precies één gebruikersgroep.

Veranderingen protocolleren en per email versturen

Alle veranderingen aan de database worden geprotocolleerd, en wel in de tabel logfile. In het veld logentry staat de eigenlijke inhoud van de verandering. Dit kan een gewone tekst zijn, maar ook een XML met diverse veranderingen. Als de tekst vertaald moet worden, dan moet er een "translate(..)" geschreven worden, met de te vertalen tekst tussen de haakjes, dus bijvoorbeeld "translate(login)". In changed_by_member staat, wie deze verandering heeft doorgevoerd. Dit maakt het mogelijk om bijvoorbeeld bij het inloggen te laten zien, welke veranderingen tot nu toe gedaan werden. Als er iets aan de gegevens van een lid veranderd werd (dat kunnen ook de eigen gegevens zijn), dan staat de index van dat lid in changes_on_member. Aangezien niet alle veranderingen in de gegevens van een lid zijn, kan dit veld ook NULL zijn. Via dit veld is het mogelijk, om bij de gegevens van een lid direct te laten zien, welke veranderingen hier in het verleden zijn ingegeven.

Het laaste veld, dat wel verplicht is, is change_type. Er zijn verschillende types van veranderingen gedefinieerd, zoals bijvoorbeeld veranderingen aan leden, veranderingen aan contactgegevens, veranderingen aan lijstwaardes, enz. Via dit type wordt gekeken, aan wie deze verandering per email gestuurd moet worden. Welke veranderingen aan wie gestuurd moeten worden, staat in de tabel email_notifications.