Datenbank mit Historienverwaltung

[Sncrwein]

Hallo,

ich bräuchte etwas Hilfe bei einer Programmierung in Access. Ich weiß momentan einfach nciht einmal, was der richtige Weg hierfür wäre. Und zwar geht es um folgendes:

Ich habe eine Eigentümer-Datenbank, welche auf Grundstücke bezogen ist.  Sprich in einer Zeile stehen Anschrift(Eigentümer) und die Flurstücksnummer.

Nun möchte ich bei einem Eigentümerwechsel auch auf die alten Eigentümer zurückgreifen können, sprich alle Daten die geändert werden in eine "Historientabelle" abspeichern (inklusive Zeitstempel -> Gültig bis).

Einen funktionierenden Audittrail via Makro habe ich schon hinbekommen, nur ist das leider nciht das was ich will. Für die Weiterverweudng in einem spezifischen Programm bräuchte ich die "Historientabelle" im gleichen Format wie aktuelle. Somit hilft mir eine Protokollierung der Änderungen nicht weiter. Im Prinzip müsste das Before.Update-Makro "nur" die zu ändernde Zeile kopieren, in der "Historientabelle" abspeichern und ein Datumsfeld mit dem aktuellen Datum versehen.

Aber leider komme ich ab hier nicht weiter, da ich nicht genau weiß, wie ich das in dem Before.Update-Makro schreibe.

Kann mir hier jemand weiterhelfen?

[MaggieMay]

Hallo,

so wie ich das verstanden habe, willst du den kompletten Datensatz im Zustand vor der Änderung sichern. Das kannst du mit Hilfe der OldValue-Eigenschaft der Textfelder im Formular tun, allerdings brauchst du dazu ein Recordset, das feldweise gefüllt wird bzw. eine entsprechende Anfügeabfrage.

[DF6GL]

Hallo,

bevor da mit Audittrail-Funktion gearbeitet wird, schlage ich vor, die Tabelle(n) an die Anfordernisse anzupassen:

tblFlurstücke
FS_ID
FS_Gemarkung
FS_Bezeichnung
.
.


tblBesitzer
B_ID
B_FS_ID
B_Nachname
B_Vorname
B_erworbenAm
B_veraeusertAm
.
.
.


Beziehungen:

FS_ID    1:n   B_FS_ID

Somit wird jedem Flurstück ein oder mehrere Besitzer (zeitlich gleichzeitig oder nacheinander) zugeordnet.


Die "Historie" ergibt sich automatisch aus der Sortierung des ErworbenAm-Feldes.

[Sncrwein]

Hallo,

danke schonmal für die Antwort.

@MaggieMay: Ja genau! Das mit dem Recordset hab ich auch schon gelesen, war mir aber nicht sicher, ob das der richtige Weg gewesen wäre. Das probier ich dann gleich mal aus.
Sollte da jmd schon ein ähnliches Skript haben, kann er gerne ein paar Hilfsstützen posten ;-)

@DF6GL:
Vom Prinzip her würde ich dir da zustimmen, nur leider kann ich im nachfolgenden Programm nur 1:1 Beziehungen darstellen... D.h. jeglicher Aufbau von 1:n Beziehungen wäre leider komplett sinnlos.
Außerdem können sich nicht nur die Daten der Eigentümer zum Flurstück ändern, sondern auch Daten des Flurstücks selbst. (Hab ich leider vergessen zu erwähnen, da es selten vorkommt).

[MzKlMu]

Hallo,

nur leider kann ich im nachfolgenden Programm nur 1:1 Beziehungen darstellen... D.h. jeglicher Aufbau von 1:n Beziehungen wäre leider komplett sinnlos.

kannst Du das mal näher erläutern, was ist das für ein nachfolgendes Programm ?
Die Beziehungen werden ja auch für Access benötigt und nicht für ein nachfolgendes Programm.
Nach meiner Auffassung ist eine solche Datenbank ohne 1:n Beziehungen überhaupt nicht sinnvoll (datenbankgerecht) aufzubauen.

Und bei einer korrekt aufgebauten DB hast Du diese ganze Historie eines Flurstücks automatisch, alleine über eine entsprechende Tabellenstruktur, wie es von Franz auch schon erwähnt wurde.

Und wenn Du keine korrekte Struktur aufbaust, brauchst Du auch kein Access, da kannst Du auch Excel nehmen.

[Sncrwein]

Ja, ich weiß, dass das wirklich viel sinnvoller wäre. Das Programm danach ist GeoMedia, ein GIS. In dem Programm selbst kann ich Joins etc ausführen, nur keine 1:n Beziehungen. Access, Oracle oder SQL sind die "Standard"-DBs für das Programm.
Für meine Kunden muss ich später leider alles in Excel exportieren und eben so aufbauen, dass sie pro Flurstück je eine Zeile mit allen Werten sehen wollen, auch wenn nur einer geändert wurde.

Ich kann natürlich die DB trotzdem 1:n aufbauen, nur muss ich später sowieso alles in Excel ausgeben und somit würde mir ein einfacher "Select *" und dann "Copy" in eine andere Tabelle inklusive Timestamp ausreichen.
Das ist sicherlich nicht die eleganteste Lösung, aber ich dachte mir halt die einfachst, für das, dass danach eh alles in Excel kommt (zum Schluss)

[Sncrwein]

Wenn ich nun das ganze in 2 Tabellen trenne (was kein Problem wäre), wie würde dann das ganze gespeichert werden, wenn ich sowohl Daten zum Grundstück (hier geht es spezielle Berechnungen, also ein paar Zahlenwerte, welche wieder in einer Tablle mit der FLSt_ID verlinkt werden könnten) als auch zum Eigentümer in einem Formular ändere?

Kann man das dann trotzdem per Timestamp machen? Dieser würde die Bearbeitungszeit widerspiegeln.

[MzKlMu]

Hallo,

In dem Programm selbst kann ich Joins etc ausführen, nur keine 1:n Beziehungen.

wenn Du JOINS ausführen kannst, kannst Du auch 1:n Beziehungen darstellen. Ein Join ist eine Verknüpfung zwischen 2 Tabellen. Ob das 1:1 oder 1:n ist ergibt sich alleine aus der Tatsache dass der Fremdschlüssel Duplikate zulässt. Wenn es in der 2 Tabelle Duplikate gibt, hast Du automatisch 1:n, das hat mit den Beziehungen nichts zu tun. Beziehungen werden zentral angelegt, diese verwalten dann auch referentielle Integrität und andere Dinge. Von daher, bin ich sicher, dass auch GeoMedia 1:n Beziehungen problemlos darstellen bzw. damit umgehen kann.

Ich bin auch der Auffassung, dass 2 Tabellen nicht reichen. Hier sind 3 Tabellen erforderlich.
- Flurstücke
- Eigentümer
- EigentümerFlurstück

In die 3 Tabelle kommt die FlurstückID und die EigentümerID jeweils als Fremdschlüssel. Sowie die beiden Datumsfelder.
Das würde auch den Fall abdecken, das ein Flurstück mehrere Eigentümer haben kann, was ja nicht unwahrscheinlich ist. In der 3. Tabelle könnte dann auch noch ein Anteil (in %) eingetragen werden.
Eigentümer und deren Wechsel werden in der 3.Tabelle einfach fortlaufend eingetragen, der Datensatz (bzw. die DS) ohne Veräußerungsdatum ist der aktuelle Besitzer (bzw. die Besitzer). Und damit hast Du eine lückenlose Historie des Flurstücks.

Der Export nach Excel ist dann ein anderes Thema, das solltest Du erst mal außer acht lassen, erst sollte das Datenmodell stimmen.