Datenbanken aufteilen

17 Datenbank aufteilen
Warum teilt man eine Datenbank auf und was bedeutet dies? Eine Access-Datenbankdatei ist
ein Monolith. Sie enthält alle notwendigen Objekte wie Tabellen, Abfragen, Formulare, Berichte,
Makros und VBA-Module. Mit den Tabellen enthält sie sogar noch die Daten, die der Benutzer
eingibt. Und das ist der entscheidende Nachteil: Da diese eine Datei die Daten enthält, ist sie auch
ständigen Änderungen durch den Benutzer unterworfen. Das ist kein Problem, wenn die Datenbank
fertig programmiert ist. Das ist selten der Fall: Die meisten Datenbanken offenbaren früher oder
später kleinere Fehler, die es zu beheben gilt, oder die Benutzer wünschen Erweiterungen oder
Änderungen der Anwendung. Und hier wird es schwierig: Sie können zwar die Änderungen vornehmen, aber während Sie programmieren, gibt der Benutzer natürlich weiter Daten ein. Also
teilen Sie die Datenbank in zwei Datenbanken auf: eine, die die Daten enthält, also die Tabellen
(das Backend), und eine mit den übrigen Elementen, also der Benutzeroberfläche und der
Anwendungslogik in Form von VBA-Code (das Frontend). Es gibt natürlich auch Anwendungslogik
in den Tabellen – zum Beispiel Restriktionen wie eindeutige Felder.
Das Aufteilen der Datenbank ist kein Problem, denn Sie können ja in einer Access-Datenbank
ohne eigene Tabellen Verknüpfungen zu den Tabellen einer anderen Access-Datenbank herstellen und diese Tabellen genauso nutzen, als ob sich diese in der gleichen Access-Datenbank befinden würden. Welche Vorteile bringt dies nun? Sie erhalten damit die Möglichkeit, das Frontend,
das ja nun nur noch Elemente enthält, die der Benutzer nicht verändert, weiterzuentwickeln. Zu
gegebener Zeit tauschen Sie dann einfach das alte Frontend gegen das neue Frontend aus und
der Benutzer kann von den neuen Funktionen und/oder behobenen Fehlern profitieren.
Natürlich kann es auch einmal Aktualisierungen am Datenmodell geben. Dafür müssen Sie den
Benutzer aber auch nicht von der Arbeit abhalten und beispielsweise das Backend mit dem aktuellen Stand der Daten anfordern, die Änderungen durchführen und das Backend wieder zum
Benutzer zurücksenden. Sie können nämlich im Frontend Code unterbringen, der beim Start des
Frontends die Version des Backends prüft und notwendige Änderungen am Datenmodell auf das
Backend anwendet.
Es gibt neben der Wartung der Datenbank natürlich noch einen weiteren, sehr wichtigen
Grund für die Aufteilung einer Datenbank: Sie können dann nämlich Frontend-Datenbanken
auf verschiedenen Rechnern installieren, damit mehrere Benutzer gleichzeitig auf die im
Backend gespeicherten Daten zugreifen können. Dies ist ein Szenario, das üblicherweise mit der
Verwaltung eben jener Benutzer einhergeht und zusätzlich nach der Vergabe unterschiedlicher
Berechtigungen für Benutzer und/oder Benutzergruppen verlangt.
In diesem Buch werden wir uns allerdings ausschließlich dem Aufteilen einer Datenbank zum
Zwecke der einfacheren Wartung widmen. Mit Access 2007 hat Microsoft nämlich entschieden, auf ein integriertes Sicherheitssystem inklusive Benutzerverwaltung zu verzichten. Das ist
nicht allzu schlimm, denn das Sicherheitssystem war ohnehin nie wirklich sicher. Ich werde aber
Kapitel 17 Datenbank aufteilen
in nicht allzu ferner Zukunft in einer weiteren Publikation auf die Anwendung einer AccessDatenbank in Zusammenarbeit mit einem Datenbank-Management-System wie dem Microsoft
SQL Server oder MySQL eingehen. Diese Systeme bringen eine professionelle Benutzer- und
Benutzergruppenverwaltung mit, die auch die entsprechende Sicherheit garantiert.
Die eigentliche Aufteilung einer Datenbank in Frontend und Backend ist ein harmloser Vorgang,
der sich allein mit den Mitteln der Benutzeroberfläche von Access durchführen lässt. Interessant
wird es hingegen, wenn das Frontend ausgetauscht wird. Warum? Weil beim Verknüpfen einer
Frontend-Datenbank mit dem Backend der Speicherort des Backends in einer Systemtabelle des
Frontends gespeichert wird – zum Beispiel c:\Datenbank\Backend\AEMA_BE.accda.
Wenn Sie nun eine neue Version des Frontends programmieren und diese über die alte Version
kopieren, weiß die neue Version natürlich noch nicht, an welchem Ort sich die zu verknüpfenden
Tabellen im Backend befinden. Sie versucht dann, die Tabellen von dem Ort einzubinden, an dem
diese sich zuletzt befunden haben, also irgendwo im Dateisystem Ihres Entwicklungsrechners.
Wenn das nicht gelingt, löst dies beim ersten Zugriff auf die enthaltenen Daten einen Fehler aus.
Dies sollten Sie natürlich umgehen, und zwar indem das Frontend beim Öffnen prüft, ob die
Datenbank mit den Tabellen sich an Ort und Stelle befindet. Ist dies nicht der Fall, soll die
Anwendung einen Dialog zur Auswahl des neuen Speicherortes der Backend-Datenbank anbieten. Nach der Auswahl der Datei erneuert das Frontend dann VBA-gesteuert die Verknüpfung
mit den Tabellen im Backend.
Das sollte nun aber nicht mit jeder neuen Version nötig sein, denn erstens kann es ja sein, dass
es regelmäßig Updates gibt, und zweitens arbeiten vielleicht viele Benutzer mit der Datenbank.
Wenn dann alle paar Tage oder Wochen einige Mitarbeiter einen Dateidialog bemühen müssen,
um das Backend neu auszuwählen, kostet das unnötig Zeit und Geld.
Also sorgen wir dafür, dass die neue Frontend-Datenbank den aktuellen Speicherort der
Backend-Datenbank anderweitig erfährt. Dazu gibt es verschiedene Möglichkeiten: zum Beispiel
einen Eintrag in die Registry oder eine kleine Textdatei, die sich im gleichen Verzeichnis wie
die Frontend-Datenbank befindet. Wenn Sie nun eine neue Version des Frontends auf den
Rechner des Benutzers kopieren, prüft das Frontend beim Öffnen zunächst, ob der angegebene
Speicherort für die verknüpften Tabellen noch stimmt. Falls nicht, liest es den zuletzt verwendeten Speicherort aus der bereits erwähnten Textdatei ein und verknüpft die Tabellen neu. Hier
können nun eigentlich nur noch zwei Dinge dazwischenkommen: entweder ist die BackendDatei nicht mehr am erwarteten Ort oder das Netzwerk ist unterbrochen.
17.1 Datenbank in Frontend und Backend aufteilen
Kommen wir nun zunächst zum einfachen Teil: dem Aufteilen einer Datenbank in Front- und
Backend. Dazu erstellen Sie eine neue Datenbank-Datei, die beispielsweise AEMA_BE.mdb
heißt (_BE kennzeichnet das Backend). Aus Gründen der Performance bei verknüpften Access-
518
Datenbank in Frontend und Backend aufteilen
Datenbanken sollte der Dateiname nicht länger als acht Zeichen sein und keine Erweiterung von
mehr als drei Zeichen besitzen, daher benennen wir die Endung einer neu erstellten .accdb-Datenbank in .mdb um (dies gilt nur für das Backend!). Öffnen Sie die Datenbank und wählen Sie den
Ribbon-Eintrag Externe Daten|Importieren und Verknüpfen|Access aus (siehe Abbildung 17.1).
Abbildung 17.1: Importieren von Tabellen einer anderen Access-Datenbank
Wählen Sie im folgenden Dialog die aufzuteilende Datenbank aus, also <Pfad>\AEMA.accdb.
Behalten Sie die Importieren...-Option bei und klicken Sie auf OK. Es erscheint der Dialog Objekte
importieren aus Abbildung 17.2. Klicken Sie hier auf die Schaltfläche Alle Auswählen.
Abbildung 17.2: Importieren aller Tabellen des Frontends in das Backend
Sie sollten sicherheitshalber prüfen, ob die Beziehungen mit importiert werden. Dazu klicken
Sie auf die Schaltfläche Optionen und aktivieren, sofern noch nicht geschehen, die Option
Importieren|Beziehungen (siehe Abbildung 17.3). Mit einem Klick auf OK importieren Sie nun
alle Tabellen der Datenbankdatei AEMA.accdb in die Backend-Datenbank AEMA_BE.mdb. Aber
wollen wir wirklich alle Tabellen der Datenbank in das Backend verschieben? Sollten nicht
Tabellen wie tblOptionen oder tblStammdaten im Frontend verbleiben? Immerhin enthalten
diese doch Felder, die auf dem Rechner des jeweiligen Benutzers eingestellt und dort auch wieder abgefragt werden? Die Antwort lautet Nein.
519
Kapitel 17 Datenbank aufteilen
Abbildung 17.3: Stellen Sie sicher, dass auch die Beziehungen mit importiert werden.
Wie oben angemerkt, soll die Aufteilung in diesem Fall zunächst die Möglichkeit eröffnen, das
Frontend und somit die Benutzeroberfläche auszutauschen, ohne dass die Daten jeweils in die
neue Version übertragen werden sollen – wir gehen also im Rahmen dieses Buchs von einer
Einzelplatzanwendung aus. Und selbst wenn wir eine Mehrbenutzer-Anwendung planen, so
würden doch die benutzerabhängigen Daten unter Angabe des jeweiligen Benutzers im Backend
gespeichert werden. Anders könnte der Benutzer ja gar nicht von verschiedenen Arbeitsplätzen
aus auf seine Daten zugreifen, sondern müsste immer vom gleichen Rechner aus arbeiten. Also
verschieben wir alle Tabellen in das Backend.
Nun haben wir von jeder Tabelle zwei Exemplare: eine im Frontend und eine im Backend. Die
Tabellen im Frontend können Sie löschen: Das Frontend soll schließlich auf die Tabellen im
Backend zugreifen, und das realisieren wir durch die Herstellung entsprechender Verknüpfungen.
Um die Tabellen zu löschen, markieren Sie diese einzeln im Navigationsbereich und betätigen
die Entf-Taste. Es erscheinen Meldungen wie die aus Abbildung 17.4, die Sie einfach bestätigen.
Abbildung 17.4: Löschen einer Tabelle per Navigationsbereich
Die Anwendung funktioniert zu diesem Zeitpunkt natürlich gar nicht mehr, denn es fehlen sämtliche Tabellen. Um dies wieder in Ordnung zu bringen, fügen Sie nun Verknüpfungen auf alle
Tabellen in der Backend-Datenbank AEMA_BE.mdb hinzu. Dazu betätigen Sie – diesmal vom
Frontend aus – den Ribbon-Eintrag Externe Daten|Importieren und Verknüpfen|Access. Wählen
520
Datenbank in Frontend und Backend aufteilen
Sie im Dialog Externe Daten diesmal die Backend-Datenbank als Datenquelle aus. Außerdem
aktivieren Sie die zweite Option Erstellen Sie eine Verknüpfung zur Datenquelle, indem Sie eine
verknüpfte Tabelle erstellen und klicken Sie dann auf OK (siehe Abbildung 17.5).
Abbildung 17.5: Vorbereiten der Tabellenverknüpfungen
Wählen Sie im Dialog Tabellen verknüpfen aus Abbildung 17.6 mit einem Klick auf Alle auswählen alle Tabellen aus und klicken Sie auf OK.
Abbildung 17.6: Auswahl der zu verknüpfenden Tabellen
521
Kapitel 17 Datenbank aufteilen
Dies stellt Verknüpfungen zu allen Tabellen der Backend-Datenbank her, die wie in Abbildung
17.7 dargestellt werden. Sie können nun doppelt auf die verknüpften Tabellen klicken und erhalten genauso Zugriff auf die Daten, als wenn sich die Tabellen in der gleichen Datenbank befinden würden. Das Gleiche gilt für Abfragen, Formulare, Steuerelemente, Berichte und VBA-Code,
der auf die in den Tabellen enthaltenen Daten zugreift.
Abbildung 17.7: Verknüpfte Tabellen im Frontend
17.2 Prüfen und Wiederherstellen der Verknüpfung beim
Start
Wenn Sie mit einer Frontend/Backend-Lösung arbeiten, speichert die Tabelle MSysObjects der
Frontend-Datenbank zu jeder Tabelle Name und Pfad der Backend-Datenbank. Diese Tabelle
blenden Sie im Navigationsbereich ein, indem Sie mit der rechten Maustaste auf den Titel dieses Bereichs klicken, den Eintrag Navigationsoptionen... auswählen und im nun erscheinenden
Dialog die Option Systemobjekte anzeigen aktivieren. Öffnen Sie die Tabelle MSysObjects nun
per Doppelklick auf den Eintrag im Navigationsbereich, zeigt diese ihre Informationen wie in
Abbildung 17.8 an.
Sollte der Benutzer nun den Speicherort der Backend-Datenbank ändern oder diese gar löschen,
findet Access die verknüpften Tabellen nicht mehr unter dem im Feld Database der Tabelle
MSysObjects angegebenen Namen.
Sie können dies testen, indem Sie einfach den Dateinamen der Backend-Datenbank ändern. Wenn Sie nun versuchen, auf eine der Tabellen zuzugreifen, erscheint die Meldung aus
Abbildung 17.9.
Um solche Probleme zu verhindern, soll die Anwendung beim Starten prüfen, ob die Tabellen
ordnungsgemäß verknüpft sind. Dies untersuchen wir der Einfachheit halber nur anhand einer
einzigen Tabelle, und zwar mit der Tabelle tblOptionen.
522