Letzte Änderung am 20. August 2021 by Christoph Jüngling
Im ersten Teil ging es zunächst um das Grundsätzliche, um die Motivation, lieber doch nicht alle Anwender auf einer einzelnen Access-Datenbankdatei herumturnen zu lassen. Nun möchte ich mich der Frage widmen, was denn die Alternative ist.
Gehe zu Teil 1 – Teil 2 – Teil 3
In diesem Artikel
Prinzip
Auch hier erst einmal zum Prinzip, später dann zur konkreten Umsetzung. Dieses Prinzip ist schnell erklärt und keineswegs neu: Trenne “einfach” Applikation und Daten voneinander und sorge anschließend dafür, dass die Applikation auf die Daten zugreifen kann.
Diese Skizze zeigt das hoffentlich sehr übersichtlich auf. Es ist dabei grundsätzlich egal, wieviele Arbeitsplätze betroffen sind, solange die maximale Anzahl an Zugriffen auf das Backend nicht überschritten wird. Diese Zahl lag bei MDBs bei 255 (für ACCDBs habe ich auf die Schnelle nichts gefunden), was sicher in der Praxis keine wesentliche Einschränkung ist.
Frontend-Backend-Trennung
Daten im Netz
Dabei kommen die Daten in’s Netzwerk, denn schließlich soll ja jeder Benutzer dasselbe sehen und bearbeiten können. Auf diese Weise sind sie (hoffentlich) auch in der täglichen Datensicherung eingeschlossen. Das ist keineswegs unwichtig, wenn man bedenkt, welchen Stellenwert diese Daten oft für das Unternehmen haben.
Diese Daten-Datenbank wird oft auch “Backend” (sprich: “bäck-änd”) genannt, das “hintere Ende”. Es handelt sich dabei um eine ganz normale Access-Datenbank, also eine .accdb-Datei. Das Backend enthält nur Tabellen und deren Beziehungen, und vielleicht noch ein Autoexec-Makro, das die Datei, sobald sie jemand öffnen möchte, sofort wieder schließt.
Applikation lokal
Die Appplikation – wir nennen sie analog dazu “Frontend” (das “vordere Ende”) – würde in diesem Szenario auf dem PC eines jeden Users liegen. Alle bekommen zwar eine Kopie des Frontends, aber theoretisch (je nachdem welche Kenntnisse der Anwender hat) könnten sich im Laufe der Zeit hier Änderungen ergeben.
Auch dieses ist eine .accdb-Datei, aber eine mit anderem Inhalt als zuvor beschrieben. Denn hier steckt alles andere drin: Abfragen, Formulare, Berichte und diverser VBA-Code. Tabellen sind hier nur scheinbar enthalten, denn wir wollen die Daten ja nicht duplizieren. Daher spricht man im Access-Jargon von verknüpften Tabellen. Salopp gesprochen “weiß” das Frontend, wo die Tabellen stehen.
Wenn jetzt die lokale Access-Datenbank geöffnet wird und ein Datenzugriff erfolgen soll, dann sorgt Access selbst dafür, dass über die verknüpften Tabellen auf das Backend zugegriffen wird. Dabei werden üblicherweise Sperrmechanismen wirksam, die verhindern, dass die Benutzer sich beim Ändern der Daten gegenseitig in die Quere kommen.
Aus Benutzersicht
Für den Benutzer existiert scheinbar nur seine lokale Installation, und das ist auch gut so. Sollte mit dieser lokalen Datenbank etwas schiefgehen, lässt sich dies durch eine Neuinstallation schnell beheben. Denn es werden ja hier keine wichtigen Daten gespeichert, die landen alle im Backend und somit auf dem Netzwerk.
Jetzt haben wir die Probleme und mögliche Lösungen besprochen. Im nächsten Teil geht es dann endlich an die Umsetzung.
Neueste Kommentare