Access-Datenbank - Dokumentation erstellen

[Don_2020]

Ich habe hier ein "wild" gewachsene Access-Datenbak ohne Dokumentation. Immer wenn eine weitere Information benötigt wurde, ist eine Spalte hinzugefügt worden. Dabei entstanden ist ein unentwirbares Konvolut. Es gibt Redundanzen, identische Spalten mit unterschiedlichen Namen in verschiendenen Tabellen. Wie diese alle zusammenhängen habe ich noch nicht durchschaut.
Es gibt Spalten mit Leistungsangaben z.B. "1000","350" und eine Spalte mit Einheiten "W", "kW", "MW". Für Berechnungen und Eingaben unpraktisch. Telefonnummer mal mit führender Null (für Vorewahl) mal ohne führende Null. Spalten mal in der einen Tabelle als Text und in der anderen Tabelle als Zahl definiert.
Der Entwickler ist mittlerweile in Rente und nicht verfügbar.

Was ich machen soll ist die Datenbank neu strukturieren, redundanzen auflösen und in die Daten in die erste Normalform bringen.
Das ganze soll später auf SQL umgesetzt werden.

Gibt es Tools mit dem man die Datenank gut Dokumentieren kann?

 

[ella_one]

Mir sind keine Tools bekannt, die Dir helfen könnten. Es bleibt die Möglichkeit eine Normalisierung der Daten mit Access Mitteln (Abfragen, VBA-Code) vorzunehmen. Zuvor müssen alle Tabellen und Attribute händisch beschrieben werden, d.h. der Zweck einer Tabelle/eines Attributs muss aus der Beschreibung hervorgehen.

Na, dann viel Spaß

 

[benneq]

Im Access Umfeld kenne ich mich da auch nicht aus. Aber kannst du die Datenbank (oder zumindest die Tabellen Struktur ohne Daten) nicht einfach exportieren und in eine MySQL, PostgreSQL oder ähnliche "normale" SQL Datenbank exportieren? Da gibt's dann auf jeden Fall massig Tools, um den Salat zu analysieren.

 

[Don_2020]

Neben den Tabellen gibt es noch massig Scipts bzw. Abfragen und Reports. Das kann man nicht einfach so umsetzen, wenn die Tabellen kunterbunt zusammengefricklet wurden.

 

[ella_one]

Mit einer sog. "normalen", was ist schon "normal"?, Datenbank, wie z.B. IBM DB2 oder MS SQL ist das kaum lösbar.
Skripte, wohl in VBA geschrieben, Makros und Reports lassen sich mit nicht unerheblichem Aufwand optimieren - hierbei sollten alle Abfragen in VBA überführt und in einem Modul, z.B. modSQL, als öffentliche Funktionen (Public Function...) deklariert und gespeichert werden.
Die Überarbeitung der Skripte und Berichte wird zu einer erheblichen Verringerung der Anzahl selbiger führen.
Die Access Oberfläche bietet enorme Vorteile und Du solltest diese zu deinem Vorteil nutzen!!!

Ich habe bei derartigen Optimierungen die Anzahl Abfragen durch die Verwendung parametrisierter Funktionen oft von über hundert auf weniger als fünfzig reduzieren können.

 

[N00bn00b]

Ein erster Schritt wäre, eine Übersicht über das Datenmodell erstellen zu lassen, "Reverse Engineering" ist das Stichwort. Dazu gibt es diverse Tools, siehe zum Beispiel hier: https://dbmstools.com/categories/database-diagram-tools/access . Ev. hilft schon das Access-interne Relationship Window.

Angesichts der erwähnten zusätzlichen Scripts und Reports lohnt sich der Aufwand meiner Meinung nach nicht, ich würde das ganze "frisch aufsetzen": Anforderungen beschreiben, Datenmodell erstellen und das ganze sauber dokumentiert umsetzen.

 

[benneq]

Skripte in der Datenbank machen das ganze natürlich zu einer sehr unschönen Fleißaufgabe. Sowas ist auch eher ein Relikt aus der Steinzeit. Heutzutage kauft man sich lieber 10% mehr Hardwareleistung und macht das alles unabhängig von der Datenbank (oder den Datenbanken - polyglot trifft man ja immer häufiger an) im Applikationscode.
Die verlinkten Tools von @N00bn00b sollten aber schon mal helfen, um einen guten Überblick über das Schema zu erhalten. Danach werden sicherlich auch die Skripte viel einfacher zu verstehen.

Wenn eh alles von Access weg soll, würde ich ein neues Projekt aufsetzen und dort nach und nach alles hin umziehen. Wenn der eigentliche Programmcode im Groben beibehalten werden soll, tut's natürlich auch eine Kopie, wo erst mal alles auskommentiert wird, was ersetzt werden soll und dann nach und nach wieder mit Leben gefüllt wird.
Jedes Stück, das du in Access verstanden hast, wird dann zum neuen Projekt hinzugefügt. Parallel dazu kann man dann auch gleich den Code schreiben, der für diesen Abschnitt alles aus Access zusammensammelt, (evtl. normalisiert) und in die neue Datenbank einfügt. Und die Dokumentation nicht vergessen, sonst kommt in 10 Jahren dein Nachfolger und stellt hier wieder dieselben Fragen

Einfacher und schneller wird das Unterfangen dadurch nicht. Aber irgendwo muss man schließlich anfangen. Das schöne an Code ist ja, dass man ihn immer wieder überarbeiten und testen kann - bis alles passt.
Vor 10 Jahren haben wir was ähnliches gemacht, aber glücklicherweise hatten wir noch einen von 5 ehemaligen Entwicklern dabei, sodass zumindest die Hälfte der Datenbank einfach(er) zu verstehen war. Der Rest war viel Ratespiel, rumprobieren, und schauen was sich wo ändert, wenn eine bestimmte Funktion ausgeführt wurde. Spaß macht das nicht wirklich, aber mit den richtigen Kollegen zumindest erträglich.