Datenbank

Entwurf

Für den Datenbankentwurf habe ich das Programm MySQL Workbench verwendet. Das Datenbankmodell kann hier als mwb-Datei, pdf-Datei oder als png-Datei runtergeladen werden. Ich habe die MySQL-Engine InnoDB verwendet, damit Fremdschlüsselbeziehungen verwendet werden können, die vom Datenbanksystem automatisch auf Konsistenz geprüft werden.

Tabellenstruktur

Haupttabelle

Die wichtigste Tabelle ist die Tabelle member_entries. Hier werden die Informationen für jedes Mitglied gespeichert. Die meisten Felder sprechen für sich. Es gibt jedoch auch ein paar Felder, deren Bedeutung vielleicht nicht sofort ersichtlich sind:

Feld	Erklärung
limit_access	Dieses Feld kann benutzt werden um bestimmte Mitglieder von anderen Mitgliedern abzuschirmen. So ist es zum Beispiel möglich, dass bestimmte Mitglieder ihre Daten nur dem Vorstand, jedoch nicht anderen Mitgliedern zur Verfügung stellen möchten.
partner	Wenn der Verein sowas wie ein Partnertarif anbietet oder die Mitglieder auch die Daten ihres Partners bearbeiten können, dann steht hier der Index des Partners.
company_information	Für einige Vereine ist es wichtig, dass die Mitglieder nachschauen können, wo ihre Mitglieder arbeiten und welche Position im Unternehmen sie haben. Dies kann hier gespeichert werden.
user_group	Alle Rechte im System werden in Benutzergruppen zusammengefasst. Jedes Mitglied ist Mitglied in genau EINER Benutzergruppe.
preferred_language	Wenn es verschiedene Nationalitäten unter den Mitgliedern gibt, kann hier gespeichert werden in welcher Sprache das Mitglied angesprochen werden möchte. Der Eintrag kann nur einer der in der Tabelle languages definierte Sprache sein.
membership_type	Dies ist für Vereine die verschiedene Mitgliedstypen anbieten, zum Beispiel mit verschiedenen Mitgliedsbeiträgen.
membership_end	Meist wird die Mitgliedschaft mit dem Ende des Vereinsjahrs beendet. Wenn dieses Feld auf wahr gesetzt wird, dann ist diese Person zwar immer noch Mitglied, kann aber zum Beispiel am Ende des Vereinsjahrs in die Gruppe ehemaliger Mitglieder verschoben werden.

Adressdaten

Die Adressdaten werden in einer eigenen Tabelle gespeichert. Dies hat den Vorteil, dass pro Mitglied mehr als eine Adresse gespeichert werden kann. Ein zweiter Vorteil ist, dass bei Partnern das gleiche Adressfeld verwendet werden kann, damit eine Änderung der Adresse automatisch für beide Mitglieder gilt. Für die Verbindung zwischen Adressen und Mitgliedern gibt es eine Verknüpfungstabelle. Bei jedem Mitglied muss in dieser Tabelle bei genau EINER Adresse das Feld main_address gesetzt sein. Dies ist die Postadresse die benutzt wird für die Korrespondenz (soweit dies nicht per Email geschied).

Das Feld address_type definiert, um welche Art von Adresse es sich handelt. Dies wird durch den Administrator festgelegt und wird zum Beispiel für Heimatadresse, Studienadresse, Firmenadresse, usw. verwendet.

Sprachen und Übersetzungen

In der Tabelle languages stehen alle Sprachen, die durch den Anwender ausgewählt werden können, wofür es also eine Übersetzung aller Texte im System gibt. Das System sucht in der Tabelle mit den Übersetzungen den Übersetzungstext unter Verwendung von module (Modul in dem der Text verwendet wird, zum Beispiel der Dateiname), language (Sprache des Textblocks) und key (ein Begriff, der innerhalb eines Moduls eindeutig sein muss).

Studentenvereine

Wenn das System für einen Studentenverein verwendet wird, dann ist es sinnvoll bei den Mitgliedern auch zu speichern, welches Studienfach sie studieren. In der Tabelle fields_of_study sind alle Studienfächer definiert. Durch die Verwendung der Tabelle studies_student_map können Mitglieder mehr als ein Fach studieren, wobei auch das Anfangs- und Endjahr eingegeben werden kann.

Arbeitsgruppen

In den meisten Vereinen gibt es Arbeitsgruppen, wie die Sport-AG, Party-AG, usw., aber auch den Vorstand. Für jede AG wird definiert, welche Funktionen hier möglich sind. Über die Tabelle committee_function_map wird festgelegt, welche Funktionen in welcher AG möglich sind. Über die zweite Tabelle, committee_member_map, wird festgelegt, welches Mitglied in welcher AG welche Funktion inne hat.

Emaillisten

In den meisten Vereinen gibt es verschiedene Emaillisten, zum Beispiel pro AG, für Mitglieder, für nicht-Mitglieder, usw. Hier werden die Listen in der Tabelle mailinslists definiert. Falls die Listen mit Majordomo arbeiten, kann hier auch direkt die Verwaltungsemailadresse und das Verwaltungskennwort gespeichert werden. Änderungen an Emailadressen oder an Listenmitgliedern werden so direkt bei Majordomo geändert.

Benutzerrechte

In der Tabelle user_rights sind alle Rechte definiert, die ein Mitglied haben kann. Es gibt drei Sorten von Rechten:

Systeminterne Rechte
Rechte für eine bestimmte A.G.
Rechte für einen bestimmten Status

Systeminterne Rechte sind durch die Programmierung von Vereniging 2.0 festgelegt und können daher nicht geändert werden. Desweiteren gibt es dynamische Rechte, die zum Beispiel benutzt werden um im Menü bestimmte Benutzergruppen sichtbar oder unsichtbar zu machen. Wenn es zum Beispiel den Status Mitglied und nicht-Mitglied gibt, dann gibt es ein Recht zum Betrachten von Mitgliedern und ein Recht zum Betrachten von Nicht-Mitgliedern. Das Gleiche gilt für A.G.s. Da aber Stati und A.G.s durch den Administrator angelegt werden, sind diese Rechte nicht statisch. Sie werden mit Hilfe zweier Datenbanktriggern automatisch angelegt wenn ein Wert zu einem dieser Tabellen hinzugefügt wird. Die Datenbank sorgt auch dafür dass sie automatisch gelöscht werden.

Unter value steht der Name des Rechts. Handelt es sich um ein dynamisches Recht, dann wird der Name automatisch durch die Trigger festgelegt, nach dem Schema view_status_.... oder view_committee_....

Eine Benutzergruppe fasst eine bestimmte Anzahl an Benutzerrechte unter einem Namen zusammen. Für die Verbindung zwischen diesen Beidern wird die Tabelle groups_rights_map verwendet. Ein Mitglied ist Mitglied in genau einer Benutzergruppe.

Änderungen protokollieren und per Email verschicken

Alle Änderungen an der Datenbank werden protokolliert, und zwar in der Tabelle logfile. Im Feld logentry steht der eigentliche Inhalt der Änderunge. Dies kann ein einfacher Text sein, aber auch ein XML-Text mit mehreren Änderungen. Wenn hier ein Text steht, der übersetzt werden soll, dann muss in dem String ein "translate(..)" geschrieben werden, mit dem zu übersetzendem Text in den Klammern, also zum Beispiel "translate(login)". In changed_by_member steht, wer die Änderung gemacht hat. Damit wird es möglich, zum Beispiel beim Einloggen anzuzeigen, welche Änderungen in der Vergangenheit gemacht wurden. Wenn sich Daten eines Mitglieds ändern, dann wird dessen Index in das Feld changes_on_member geschrieben. Da nicht alle Änderungen Mitgliedsdaten betreffen, kann dieses Feld auch NULL sein. Mit diesem Feld wird es möglich, direkt beim Bearbeiten der Mitgliedsdaten anzuzeigen, welche Änderungen in der Vergangenheit gemacht wurden.

Das letzte Feld, das zwingend vorhanden sein muss, ist change_type. Es gibt verschiedene Änderungstypen, wie zum Beispiel Änderungen an Mitgliederdaten, Änderungen von Kontaktdaten, Änderungen an Listenwerte, usw. Mittels dieses Typs wird nachgeschaut, wer über diese Änderungen per Email informiert werden soll. Welche Änderungen an wen geschickt werden sollen, steht in der Tabelle email_notifications.