<\/p>\n
Die Tage war es soweit: Schwiegervater, seines Zeichens zweiter Vorsitzender eines Sportvereins, druckste herum: „Die Mitgliederdatei, also … die Excel-Datei – kannst Du uns da nicht mal was Richtiges draus zaubern Also ein Programm, mit dem ich Mitglieder eingeben und auch mal ein paar Auswertungen machen kann“ Na klar kann ich. Also hatte ich ein neues Projekt: Eine Excel-Tabelle mit allen relevanten Daten sollte in einer relationalen Datenbank landen, die nicht nur die Dateneingabe vereinfachte, sondern auch noch verschiedene andere Aufgaben übernehmen sollte. Ein perfektes Beispiel für eine Lösung in Access im Unternehmen! Dieser Teil beschreibt, wie wir die Daten aus der Excel-Tabelle in ein frisch erstelltes Datenmodell überführen.<\/b><\/p>\n
Die Herausforderung bringt so Einiges mit sich, was man beim überführen einer Excel-Tabelle in ein relationales Datenmodell an Herausforderungen erwarten kann. Alle Daten sind in einer einzigen Tabelle gespeichert, Lookup-Daten etwa zum Auswählen von Anreden, Altersklassen et cetera gibt es nicht, verschiedene Felder wie etwa der Nachname werden zum Hinzufügen zusätzlicher Informationen verwendet. Außerdem gibt es noch verschiedene farbige Markierungen, die einen bestimmten Status des Mitglieds belegen.<\/p>\n
Als Erstes wollen wir uns die Daten der Excel-Datei in Form einer verknüpften Access-Tabelle für unsere gewohnten Werkzeuge verfügbar machen. Das ist schon mal nicht allzu einfach, da der bisherige Verwalter dieser Daten ja nicht nur Werte in die Spalten eingetragen hat, sondern auch noch Informationen in Form unterschiedlicher Formatierungen, in diesem Fall etwa farbiger Hintergründe oder fetter Schrift hinterlegt hat. Außerdem beginnen die Zeilen mit den Daten auch nicht gleich in der ersten oder zweiten Zeile, sondern im Kopf befindet sich zunächst noch eine überschrift, die normalweise natürlich im Kopfbereich der Seite landen sollte – genauso wie die Legende im unteren Bereich, die im Fußbereich erscheinen sollte.<\/p>\n
Die Lösung für die überflüssigen Zeilen über und unter den relevanten Daten ist relativ einfach: Wir legen dazu einfach einen Bereich in der Excel-Tabelle fest, den wir dann beim Verknüpfen oder Importieren auswählen können. Wie geht das Dazu markieren Sie den gewünschten Bereich und klicken dann in das Namenfeld links oben über der Tabelle und geben dort den Namen für den gewählten Bereich ein – in diesem Fall wollen wir den Bereich Mitglieder <\/b>nennen (s. Bild 1).<\/p>\n
![\"Benennen](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_001.png\")
<\/p>\n
Bild 1: Benennen eines Bereiches<\/span><\/b><\/p>\n Wenn Sie dann im Ribbon von Excel den Befehl Formeln|Definierte Namen|Namensmanager <\/b>wählen, erscheint der Dialog aus Bild 2, mit dem Sie die bereits festgelegten Bereiche bearbeiten können. Hier können Sie auch eventuell falsch markierte Bereiche löschen oder bearbeiten.<\/p>\n Bild 2: Verwalten der benannten Bereiche<\/span><\/b><\/p>\n Damit haben wir die Voraussetzung geschaffen, dass wir die Daten gleich mit Access verknüpfen können. Nun ist allerdings noch ein weiteres Problem vorhanden: Wie können wir die farbigen Markierungen so darstellen, dass diese auch nach dem Verknüpfen von Access aus gelesen werden können<\/p>\n Im Detail sieht es es aus, dass wir in der ersten Spalte verschiedene farbige Markierungen vorfinden, die nicht etwa aus einer bedingten Formatierung stammen, sondern die vom Benutzer manuell erstellt wurden. In Access können wir diese Markierungen aber nach dem Importieren oder Verknüpfen der Excel-Tabelle nicht mehr erkennen, diese werden ignoriert. Also müssen wir die Markierungen irgendwie in einen Zahlencode oder eine andere Information übertragen.<\/p>\n Wer zu faul ist, kann natürlich einfach dem Auftraggeber sagen, dass er eine neue Spalte anlegen und die Informationen aus den farbigen Markierungen dort eintragen soll. Aber wir sind ja immer an kreativen Lösungen interessiert und nehmen dies daher selbst in die Hand. In diesem Fall wollen wir eine neue Spalte namens Farbcode anlegen und für die Zellen dieser Spalte eine Formel hinterlegen, welche die Hintergrundfarbe der ersten Spalte ausliest und einen entsprechenden Zahlenwert in die Felder der neuen Spalte einträgt.<\/p>\n Um die Hintergrundfarbe in Form eines Zahlencodes in einer neuen Spalte rechts von den eigentlichen Inhalten anzuzeigen, gehen Sie wie folgt vor:<\/p>\n Bild 3: Name für eine Formel auf Basis einer Zelle<\/span><\/b><\/p>\n Nun liefert die hintere Spalte die den Hintergrundfarben entsprechenden Farbwerte (s. Bild 4). Damit können wir beim Import von Access aus doch schon etwas anfangen!<\/p>\n Bild 4: Hinzufügen des Namens mit der Referenz<\/span><\/b><\/p>\n Was aber haben wir hier gemacht – und wie funktioniert die angegebene Formel genau Die Zuordnen<\/b>-Funktion erwartet zwei Parameter: der erste erhält einen Zahlencode, der die Eigenschaft repräsentiert, die wir für die im zweiten Parameter angegebenen Bereich ermitteln wollen. In diesem Fall liefert der Zahlencode 63 <\/b>einen Wert für die Eigenschaft Hintergrundfarbe<\/b>. Mit dem zweiten Ausdruck geben wir die zu untersuchende Zelle an. In diesem Fall nutzen wir die indirekte Schreibweise: INDIREKT(„ZS(-15)“)<\/b>. Hinter Z <\/b>befindet sich keine Zahl, also wollen wir in der gleichen Zeile arbeiten, hinter S <\/b>befindet sich der Wert -15<\/b>, was bedeutet, dass wir uns auf die Zeile beziehen, die 15 Spalten weiter links liegt.<\/p>\n Dadurch dass wir die Formel =Hintergrundfarbe <\/b>in die Zeile R <\/b>schreiben, erhalten wir die Hintergrundfarbe für die Zelle der gleichen Zeile in der Spalte B<\/b>. Nun wollen wir auch noch zwei weitere Formatierungen in den folgenden beiden Spalten unterbringen, nämlich die Schriftart in der Spalte B <\/b>und ob der Text in Spalte B <\/b>fett formatiert ist.<\/p>\n Dazu legen wir zwei neue Einträge im Dialog Namens-Manager <\/b>hinzu, sodass diese anschließend wie in Bild 5 aussieht. Die Formel für den Namen Schriftfarbe <\/b>sieht so aus – hier verwenden wir also den Code 24<\/b>:<\/p>\n Bild 5: Anlegen zweier weiterer Benennungen<\/span><\/b><\/p>\n Die Formel für den Namen Fett <\/b>gestalten wir mit dem Code 20 <\/b>wie folgt:<\/p>\n Damit haben wir die drei möglichen Informationen, die durch die verschiedenen Formatierungen entstehen, und können diese auch beim Import in die Access-Datenbank berücksichtigen.<\/p>\n Den benannten Bereich für den Import müssen Sie übrigens nicht mehr um die drei neu angelegten Spalten erweitern, da wir dort die kompletten Zeilen als Bereich angegeben haben.<\/p>\n Nun wollen wir die Daten aus der Excel-Tabelle in Access verfügbar machen. Dazu haben wir zwei Möglichkeiten: Entweder wir importieren die Daten oder wir erstellen eine Verknüpfung. In diesem Fall, wo nur eine einmalige Migration der Daten geplant ist, können wir die Daten direkt importieren. Das erledigen wir wie folgt:<\/p>\n Bild 6: Starten des Import-Vorgangs<\/span><\/b><\/p>\n Bild 7: Auswahl von Quelldatei und Import <\/span><\/b><\/p>\n Bild 8: Festlegen des zu importierenden Bereichs<\/span><\/b><\/p>\n Bild 9: Es fehlen einige Spaltenüberschriften<\/span><\/b><\/p>\n Bild 10: Einstellen der Feldeigenschaften<\/span><\/b><\/p>\n Bild 11: Festlegen eines Primärschlüssels<\/span><\/b><\/p>\n <\/p>\n Im vorliegenden Beispiel traten beim Import ein paar Fehler auf, die der Import-Assistent in der Tabelle Mitglieder_Importfehler <\/b>gespeichert hat. Die Fehler traten wohl in der Spalte mit der Postleitzahl auf, die entsprechenden Zeilennummern sind ebenfalls in der Tabelle angegeben (s. Bild 12). Ein Blick in die Zieltabelle Mitglieder <\/b>zeigt, dass das Feld Postlz <\/b>für die angegebenen Zeilen leer ist. Also werfen wir auch noch einen Blick auf die Daten in der Ausgangsdatei.<\/p>\n Bild 12: Tabelle der Importfehler<\/span><\/b><\/p>\n Hier zeigt sich dann ein gern gemacht er Fehler: Statt das Land in einer eigenen Spalte zu speichern, wird dieses als Kürzel vor die Postleitzahl geschrieben. In diesem Fall handelt es sich um die Schweiz und Einträge wie etwa CH-8005<\/b>. Beim Import werden die Datentypen der Zielfelder auf Basis der oberen paar Werte ermittelt. Hier traten noch keine Postleitzahlen mit anderen Zeichen als mit Zahlen auf, daher wurde ein Zahlendatentyp für das Feld festgelegt. In ein solches Feld können wir natürlich keine Werte mit Buchstaben importieren. Auch hier haben Sie die Wahl: ändern Sie die paar Einträge in der Zieltabelle von Hand oder wollen Sie dies in der Quelldatei erledigen und die Daten erneut importieren Wir starten den Import erneut und stellen diesmal den Datentyp für die Spalte PLZ <\/b>auf Kurzer Text <\/b>ein – nun gelingt auch der Import der PLZ-Werte mit Länderkennzeichen.<\/p>\n Damit wäre der Import abgeschlossen und wir können uns dem Datenmodell und dem übertragen der Daten aus der Tabelle Mitglieder<\/b> in die noch zu erstellenden Tabellen der Anwendung konzentrieren. Wir können noch die meisten der in der Zieltabelle Mitglieder<\/b> angelegten Felder mit den Bezeichnungen F21<\/b>, F22 <\/b>und so weiter löschen sowie den drei von uns angelegten Feldern entsprechende Feldnamen zuweisen. Der Entwurf des Datenmodells sieht anschließend wie in Bild 13 aus.<\/p>\n Bild 13: Datenmodell der Tabelle nach dem Umbenennen und Entfernen unnötiger Felder<\/span><\/b><\/p>\n Nun erstellen wir die Zieltabellen für die Daten aus der temporären Tabelle Mitglieder<\/b>. Als Erstes legen wir die Tabelle tblMitglieder <\/b>an, welche die Basisdaten eines jeden Mitglieds enthält – also Vorname<\/b>, Nachname<\/b>, Mitgliedsnummer <\/b>und so weiter. Des Weiteren werden wir einige Lookup-Tabellen brauchen – zum Beispiel für die Anrede. Wobei an dieser Stelle auffällt, dass die Excel-Tabelle gar keine Spalte für die Anrede enthält. Eine Spalte für das Geschlecht ist auch nicht vorhanden. Wie wurden denn dann die Serienbriefe mit der korrekten Anrede gefüllt Vielleicht hat man diese einfach weggelassen. Wir werden auf jeden Fall eine Anrede unterbringen. Dazu benötigen wir die Lookup-Tabelle tblAnreden<\/b>, deren Entwurf wie hier nicht extra vorstellen wollen – sie enthält lediglich die Felder AnredeID<\/b>, Anrede<\/b>, Briefanrede <\/b>und Adressanrede<\/b> (also für Werte wie Herr<\/b>, Sehr geehrter Herr <\/b>und Herrn<\/b>).<\/p>\n Der Haken an der Tabelle mit den Anreden ist, dass das entsprechende Fremdschlüsselfeld in der Tabelle tblMitglieder <\/b>manuell gefüllt werden muss, da die Excel-Tabelle ja noch gar keine Informationen bezüglich Anrede oder Geschlecht enthält. Das einzige Feld, dem man eine Information über das Geschlecht entnehmen kann, ist Vorname<\/b>. Allerdings gibt es auch keinen Algorithmus, der zuverlässig das Geschlecht vom Vornamen ableitet. Wenn wir aber in der Excel-Tabelle etwas weiter nach rechts schauen, findet sich dort eine Spalte mit der überschrift AK\/Pa<\/b>. Was Pa <\/b>ist, ist aktuell nicht bekannt, aber AK <\/b>heißt offensichtlich Altersklasse. Dort finden sich dann Werte wie EPM<\/b>, EPW<\/b>, WJ <\/b>oder EAM<\/b>. Die Gemeinsamkeit ist: Alle Einträge enthalten entweder ein M <\/b>für Männlich <\/b>oder ein W <\/b>für Weiblich<\/b>. Bingo!<\/p>\n Für das Geschlecht legen wir wie für die Anrede eine eigene Lookup-Tabelle namens tblGeschlechter <\/b>an. Diese enthält die beiden Felder GeschlechtID <\/b>und Geschlecht<\/b> (s. Bild 14).<\/p>\n Bild 14: Die Tabelle tblGeschlechter<\/span><\/b><\/p>\n Apropos Altersklassen. Normalerweise ist sehr eindeutig festgelegt, mit welchem Alter man in welcher Altersklasse unterwegs ist. Allerdings gibt es immer Vereine, die in einer Altersklasse zu wenige Spieler haben. Bevor man dann in dieser Altersklasse gar keine Mannschaft meldet, stockt man diese gegebenenfalls mit jüngeren Spielern auf, was in den meisten Sportarten bis zu einem gewissen Alter möglich ist, oder man spielt außer Konkurrenz und nimmt ein paar ältere Spieler hinzu. Was hat das mit dem Datenmodell zu tun Nun: Normalerweise wird jedes Mitglied einer Altersklasse zugeordnet. Das kann man auch automatisiert machen, indem man das Geburtsdatum des Mitglieds ermittelt, den Stichtag hinzunimmt, an dem das Alter für die aktuelle Saison ermittelt wird und dann aus einer entsprechenden Tabelle die Altersklasse ausliest. Aber was, wenn wir oben Mitglieder in mehr als einer Altersklasse geführt werden sollen, weil eben in einer Mannschaft zu wenige Mitglieder sind und diese aufgestockt werden muss An dieser Stelle kommen wir an einer Verfeinerung der Begriffe nicht vorbei: Ein Spieler kann natürlich immer nur einer Altersklasse angehören. Allerdings können durchaus Spieler verschiedener Altersklassen einer Mannschaft zugeordnet werden.<\/p>\n Wir behalten also die Idee bei, die Altersklasse über das Geschlecht und die Tabelle mit den Altersklassen zu ermitteln. Zusätzlich legen wir eine Tabelle an, die alle für die aktuelle Saison gemeldeten Mannschaften enthält. Eine Tabelle zum Herstellen einer m:n-Beziehung erlaubt dann das Zuordnen eines Spielers zu einer oder mehreren Mannschaften.<\/p>\n Wir benötigen also mindestens noch eine Tabelle namens tblAltersklassen<\/b>. Diese enthält ein Primärschlüsselfeld namens AltersklasseID<\/b>, ein Textfeld mit der Bezeichnung der Altersklasse namens Altersklasse<\/b>, ein Fremdschlüsselfeld namens GeschlechtID<\/b>, mit dem wir das Geschlecht auswählen können und zwei Felder für das Mindestalter und das Höchstalter für diese Altersklasse. Schließlich haben wir noch ein Feld namens Kuerzel<\/b>, welches die Kurzform der Bezeichnung <\/b>enthält. Den Entwurf der Tabelle finden Sie Bild 15. <\/p>\n Bild 15: Entwurf der Tabelle tblAltersklassen<\/span><\/b><\/p>\n Bei der Beispielanwendung handelt es sich um Daten aus dem Hockeysport, wo die Altersklassen wie in Bild 16 aussehen.<\/p>\n Bild 16: Datenblattansicht der Tabelle tblAltersklassen<\/span><\/b><\/p>\n Wenn wir über Altersklassen sprechen, müssen auch den Begriff Stichtag ins Spiel bringen. Verbände legen damit fest, an welchem Tag des Jahres das Alter ermittelt wird, damit die Zuordnung zu den Altersklassen erfolgen kann. Im vorliegenden Fall handelt es sich dabei um den 31.12.2017. Dieses Datum muss natürlich jedes Jahr angepasst werden, damit die Mitglieder jeweils in die entsprechende Altersklasse rutschen. Für Daten wie diese legen wir eine Optionen-Tabelle namens tblOptionen <\/b>an. Der Entwurf sieht wie in Bild 17 aus. Diese Tabelle darf natürlich immer nur einen Datensatz enthalten.<\/p>\n Bild 17: Entwurf der Tabelle tblOptionen<\/span><\/b><\/p>\n Alternative: Der Stichtag liegt natürlich immer im aktuellen Kalenderjahr. Man könnte hier auch nur den Tag und den Monat speichern und das Jahr aus dem aktuellen Datum hinzufügen. Auf diese Weise braucht man den Stichtag nie zu aktualisieren, außer er ändert sich einmal auf einen anderen Tag des Jahres – beispielsweise auf den 1. Januar oder auf den 1. Juli eines Jahres.<\/p>\n Darüber hinaus benötigen wir noch eine Tabelle, mit der wie die Mannschaften speichern. Diese soll tblMannschaften <\/b>heißen und die Felder MannschaftID<\/b>, Mannschaft <\/b>und AltersklasseID <\/b>enthalten (s. Bild 18).<\/p>\n Bild 18: Entwurf der Tabelle tblMannschaften<\/span><\/b><\/p>\n Hier könnten wir das Spiel noch weitertreiben – zum Beispiel mit einem Ja\/Nein<\/b>-Feld AusserKonkurrenz <\/b>oder mit einem Fremdschlüsselfeld namens LigaID<\/b>, mit dem wir einstellen, in welcher Liga in einer dann noch zu erstellenden Tabelle tblLigen <\/b>die Mannschaft spielt. Wobei sich dann die Frage stellt, ob man dies nicht über eine m:n-Beziehung realisiert, die auch noch die Saison speichert. So hätte man dann direkt eine Historie, welche Mannschaft wann in welcher Liga gespielt hat. Aber warum überhaupt wollen wir neben der Tabelle tblAltersklassen <\/b>noch die Tabelle tblMannschaften <\/b>nutzen Weil es ja auch einmal zwei Mannschaften einer Altersklasse geben kann, zum Beispiel Herren I <\/b>und Herren II <\/b>oder Mädchen A I <\/b>und Mädchen B II<\/b>.<\/p>\n Um die Mannschaften zu bilden – sprich: einer Mannschaft Mitglieder zuzuweisen -, benötigen wir eine passende Verknüpfungstabelle. Diese soll tblMitgliederMannschaften <\/b>heißen und neben dem Primärschlüsselfeld MitgliedMannschaftID <\/b>noch zwei Fremdschlüsselfelder auf die Tabellen tblMitglieder <\/b>und tblMannschaften <\/b>aufweisen. Für die beiden Fremdschlüsselfelder stellen wir einen eindeutigen Index ein, da ja jedes Mitglied nur einmal einer Mannschaft zugeteilt werden soll (s. Bild 19).<\/p>\n Bild 19: Entwurf der Tabelle tblMitgliederMannschaften<\/span><\/b><\/p>\n Andererseits soll ein Mitglied auch einmal zu mehreren Mannschaften gehören können – daher die m:n-Beziehung.<\/p>\n Auch hier könnte man noch einen Schritt weiter gehen, wenn man eine Historie mit einpflegen möchte: Durch Hinzufügen eines Feldes SaisonID<\/b>, das auf eine Tabelle namens tblSaisons <\/b>verweist, könnte man aufzeichnen, wann welcher Spieler in welcher Mannschaft gespielt hat. Dieses Feature wollen wir allerdings in der aktuellen Version noch nicht einbauen.<\/p>\n Einer der Haupteinsatzzwecke einer Mitgliederverwaltung ist das die Verwaltung der Beiträge. Allermindestens sollte die Mitgliederverwaltung dabei zu jedem Mitglied speichern, welcher Beitrag zu zahlen ist. Dazu finden wir in unserer Exceltabelle eine entsprechende Spalte mit dem Beitrag als Zahlenwert.<\/p>\n Bei näherer Betrachtung sind diese Zahlen allerdings nicht gerade konsistent – mindestens nicht in dem Sinne, als dass man erwarten würde, dass die Mitglieder einer gemeinsamen Altersklasse auch einen einheitlichen Beitrag zahlen würden. Ohne weitere Informationen sind die Zahlen auch nicht reproduzierbar. Abhilfe schafft dann eine weitere Spalte namens Bemerkung, in welcher oft der reguläre Beitrag angegeben wird und eine Prozentzahl, um welche dieser reduziert wurde.<\/p>\n Dies wollen wir nun etwas konsistenter abbilden. Dabei benötigen wir zunächst eine Möglichkeit, den regulären Beitrag zu speichern. Der reguläre Beitrag sollte sich von der Altersklasse ableiten. Bei unseren Altersklassen, die wir oben in der Tabelle tblAltersklassen <\/b>eingetragen haben, würden dann allerdings noch ein paar Einträge fehlen – beispielsweise für passive Mitglieder. Diese können wir jedoch recht schnell hinzufügen.<\/p>\n Allerdings fehlt dieser Tabelle noch ein Währungsfeld namens Beitrag<\/b>, das wir an dieser Stelle hinzufügen könnten. Aber wie sinnvoll ist es wirklich, auch die passiven Mitglieder zur Tabelle der Altersklassen hinzuzufügen – und somit auch die Beiträge Immerhin haben wir ja gerade eine saubere Trennung der verschiedenen Altersklassen über die Altersbereiche. Wenn wir nun noch zwei Klassen etwa namens Passiv männlich <\/b>und Passiv weiblich <\/b>hinzufügen, die ja theoretisch jeden Alters sein können, bringt dies unser Konzept durcheinander. Wie sollen wir also die passiven Mitglieder handhaben <\/p>\n Bringen wir also noch ein Ja<\/b>\/Nein<\/b>-Feld etwa namens Aktiv <\/b>in die Tabelle tblMitglieder <\/b>ein, um diese Eigenschaft direkt für das Mitglied festzulegen Dann würde es Sinn machen, auch noch eine eigene Tabelle anzulegen, welche die Beitragssätze für die verschiedenen Gruppen enthält. Diese könnten dann etwa nach dem Alter und der aktiven oder passiven Vereinszugehörigkeit aufgeteilt werden.<\/p>\n Nun kommen aber noch die verschiedenen Rabatte hinzu. Davon gibt es verschiedene: Bei manchen Einträgen scheinen diese willkürlich vergeben worden zu sein – außer im entsprechenden Hinweisfeld finden sich keine weiteren Informationen zum Rabatt. In einigen Fällen greift ein Familienrabatt, der folgende Regel vorsieht: Das erste Mitglied zahlt den regulären Beitrag, das zweite bekommt 20% Rabatt, das dritte 30% Rabatt und so weiter. Der gesamte Beitrag für die Mitglieder einer Familie ist allerdings auf einen bestimmten Beitrag gedeckelt – hier 300 EUR.<\/p>\n Auch dies wollen wir entsprechend abbilden. Dazu soll man einem Mitglied die übrigen Familienmitglieder zuordnen können. Das erledigen wir über eine weitere m:n-Beziehung, die wir mit der Tabelle tblFamilienmitglieder <\/b>abdecken. Diese Tabelle enthält neben dem Feld FamilienzugehoerigkeitID <\/b>die beiden Fremdschlüsselfelder FamilienoberhauptID <\/b>und FamilienmitgliedID<\/b>, die beide mit der Tabelle tblMitglieder <\/b>verknüpft sind. Auch hier legen wir wieder einen zusammengesetzten, eindeutigen Schlüssel über die beiden Fremdschlüsselfelder fest.<\/p>\n Wo aber speichern wir die Rabatte für das zweite, dritte, vierte und die weiteren Familienmitglieder Dazu bietet sich die Optionentabelle an, der wir für jeden Rabatt ein weiteres Feld zuweisen – für das erste weitere Familienmitglied beispielsweise in Familienrabatt1<\/b> (s. Bild 20).<\/p>\n Bild 20: Entwurf der Tabelle tblOptionen, erweitert<\/span><\/b><\/p>\n Das Feld legen wir als Währungsfeld mit Format Prozentzahl <\/b>aus. Außerdem legen wir hier ein Feld namens MaximalerFamilienbeitrag <\/b>an, welches den Familienbeitrag deckeln kann – wenn also etwa vier Mitglieder einer Familie angemeldet sind, die mit den entsprechenden Rabatten 350 EUR bezahlen sollen, kann man den Betrag beispielsweise auf 300 EUR beschränken. <\/p>\n Für die übrigen Rabatte legen wir eine Tabelle an, welche die Felder RabattklasseID <\/b>als Primärschlüsselfeld, Rabattklasse <\/b>für die Bezeichnung und Rabatt <\/b>für den prozentualen Rabatt enthält.<\/p>\n Wie Bild 21 zeigt, haben wir für den Rabatt den Datentyp Währung <\/b>festgelegt, aber für die Eigenschaft Format <\/b>den Wert Prozentzahl<\/b>. Auf diese Weise erhalten wir eine Festkommazahl und eine ausreichend große Genauigkeit.<\/p>\n Bild 21: Entwurf der Tabelle tblRabattklassen<\/span><\/b><\/p>\n Die Rabattklasse wollen wir dem Mitglied über ein Fremdschlüsselfeld namens RabattklasseID <\/b>in der Tabelle tblMitglieder <\/b>zuweisen. Damit ist klar, dass wir in dieser Tabelle auch einen Datensatz anlegen müssen, der einen Rabatt von 0% auszeichnet – so können wir diesen Datensatz standardmäßig über das Fremdschlüsselfeld auswählen.<\/p>\n Sie können den Familienrabatt natürlich auch in Form von Rabattklassen festlegen und diesen dann den Familienmitgliedern direkt zuweisen. Wir wollen uns aber der Herausforderung stellen und dies per Datenmodell abbilden, um etwa beim Ausscheiden eines Familienmitgliedes und der damit gegebenenfalls verbundenen änderung von Rabattklassen nicht immer manuell eingreifen zu müssen.<\/p>\n Für das Fremdschlüsselfeld RabattklasseID <\/b>in der Tabelle tblMitglieder <\/b>können wir, wenn Sie in der Tabelle tblRabatte <\/b>als ersten Datensatz einen Eintrag mit der Bezeichnung Ohne Rabatt <\/b>mit einem Rabattwert von 0% <\/b>eingetragen haben, den Standardwert 1 <\/b>für den entsprechenden Primärschlüsselwert festlegen.<\/p>\n Bei der Gelegenheit fügen wir der Tabelle tblMitglieder<\/b> auch gleich noch ein Ja\/Nein<\/b>-Feld namens Aktiv <\/b>hinzu, welches das Mitglied als aktives oder passives Mitglied markiert.<\/p>\n Was soll geschehen, wenn ein Mitglied in den Verein eintritt, wieder austritt und dann wieder eintritt Hier gibt es mindestens drei Möglichkeiten:<\/p>\n Die Entscheidung hängt davon ab, ob man eine Historie wünscht und auch im Nachhinein etwa die Entwicklung der Mitgliederzahlen nachvollziehen möchte. In diesem Fall wären die zweite und die dritte Variante angezeigt. Wenn es keine Rolle spielt, ob ein Mitglied irgendwann früher bereits einmal Mitglied war, kommt auch Variante eins in Frage. Wenn allerdings, wie es in manchen Vereinen üblich ist, beispielsweise Ehrungen vorgenommen werden, wenn ein Mitglied zehn, 25 oder 50 Jahre Vereinszugehörigkeit aufweist, wäre eine konsequente Aufzeichnung der Zugehörigkeiten sinnvoll.<\/p>\n Wie wollen redundante Daten vermeiden und wählen für unsere Anwendung die dritte Variante mit der Tabelle tblVereinszugehoerigkeiten<\/b>. In der Tabelle speichern wir neben dem Verweis auf das Mitglied das Eintritts- und das Austrittsdatum in Datumsfeldern (s. Bild 22).<\/p>\n![\"Verwalten](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_002.png\")
<\/p>\nFarbige Markierungen in Daten umwandeln<\/h2>\n
\n
![\"Name](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_003.png\")
<\/p>\n![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_004.png\")
<\/p>\n![\"Anlegen](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_005.png\")
<\/p>\n=ZELLE.ZUORDNEN(24;INDIREKT(\"ZS(-17)\";))<\/pre>\n
=ZELLE.ZUORDNEN(20;INDIREKT(\"ZS(-18)\";))<\/pre>\n
Import\/Verknüpfung der Daten<\/h2>\n
\n
![\"Starten](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_006.png\")
<\/p>\n![\"Auswahl](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_007.png\")
<\/p>\n![\"Festlegen](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_008.png\")
<\/p>\n![\"Es](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_009.png\")
<\/p>\n![\"Einstellen](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_010.png\")
<\/p>\n![\"Festlegen](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_011.png\")
<\/p>\n![\"Tabelle](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_012.png\")
<\/p>\n![\"Datenmodell](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_013.png\")
<\/p>\nErstellen der Zieltabellen<\/h2>\n
![\"Die](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_014.png\")
<\/p>\nAltersklassen<\/h2>\n
Tabelle für die Altersklassen<\/h2>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_015.png\")
<\/p>\n![\"Datenblattansicht](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_017.png\")
<\/p>\nTabelle für Optionen<\/h2>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_016.png\")
<\/p>\nTabelle zum Speichern der Mannschaften<\/h2>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_018.png\")
<\/p>\nMitglieder zu Mannschaften zuweisen<\/h2>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_019.png\")
<\/p>\nBeiträge<\/h2>\n
Beitragsrabatte<\/h2>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_023.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_020.png\")
<\/p>\nVereinszugehörigkeiten<\/h2>\n
\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_021.png\")
<\/p>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_022.png\")
<\/p>\n![\"Datenmodell\"](\"..\/fileadmin\/_temp_\/2017_06\/pic_1106_024.png\")
<\/p>\n