Sinnfrage zu Datenmodell

[Beaker s.a.]

Moin,
Ich habe da ein kleines Projekt mit ca. 2 Dutzend Tabellen. Nun soll ich
das erweitern, wozu ein weiteres halbes Dutzend Tabellen benötigt werden.

So weit so gut alles kein Problem 

Beim Erstellen dieser Tabellen ist mir jetzt (erst  ) aufgefallen, dass
es in fast allen Tabellen die identischen Felder zur Protokollierung von
"wer-was-wann-gemacht-hat" gibt.

Anmerkung: Es geht nur darum die Anlage eines DS und dessen letzte
(also nicht historisch) Änderung, nicht auf Feldebene, zu erfassen.

Jetzt also meine Fragen,
1. macht das Sinn?
2. passt das Modell (siehe Grafik) dazu?

Vielen Dank im Voraus für Eure Mitarbeit.
gruss ekkehard

[DF6GL]

Hallo,

verstehe die Frage nicht...

Willst Du die "wer-was-wann"-Felder in eine extra Tabelle auslagern? Bei einer "nicht historischen" Vorgabe würde das eher keinen Sinn machen.. Trotzdem ist es natürlich möglich...

[Beaker s.a.]

Hallo Franz,

verstehe die Frage nicht...

Nee, is klar, sorry, da war ich mal wieder zu schnell 

Willst Du die "wer-was-wann"-Felder in eine extra Tabelle auslagern?

Ja, genau das war die Absicht.

Bei einer "nicht historischen" Vorgabe würde das eher keinen Sinn machen..

Kannst du das noch näher erläuten?
Und, - passt dann das Modell zu einer historischen Erfassung?

gruss ekkehard

[DF6GL]

Hallo,


also doch historisch...?

Wenn die "DS-Bearbeitungsdaten" historisch erfasst werden sollen, dann ist schon eine separate History-Tabelle erforderlich. Es muss eben neben der jeweiligen ID auch die Herkunftstabelle dieses ID_Feldes in der History-Tabelle geführt werden...


Die "DS-Bearbeitungsdaten" entfallen dann aus den anderen Tabellen.

[crystal]

Hallo,
es macht schon Sinn, Änderungen in der MA-Tabelle zu führen und separat auch bei den Kontakten.
Allerdings fällt mir auf, dass es in beiden Tabellen keinen Status (aktiv, gelöscht) gibt, weshalb der Sinn der Felder "DatumGeloescht" etwas schwer zu verstehen ist, es sei denn, in Abfragen steht jeweils ein "...And DatumGeloescht = Null" oder sowas.

Nur Felder "letzte Änderung am... von..." zu führen ist m. E. kritisch, da man nicht nachvollziehen kann, was denn die letzte Änderung war. Eine einfache Lösung könnte darin bestehen, schlicht alle Felder z. B. kommasepariert vor und nach einer Änderung als langen Text in eine Audit-Tabelle zu schreiben, z. B. mit einem Loop über me.controls(i).

Wenn es wirklich nur darum geht, Anlage- und Änderungs-Datum zu speichern, macht das DM schon Sinn, da diese Werte in jedem DS gespeichert werden. Fraglich ist eben nur, welchen Sinn es macht zu erfahren, dass ein DS z. B. vorgestern geändert worden ist ohne zu wissen, welche Daten denn nun geändert wurden. Datenschutz-Aspekte (wer) einmal hintenan gestellt...

[Beaker s.a.]

Hallo,

@ Franz

also doch historisch...?

Ist halt meine Überlegung. Wenn ich es sowieso auslagere, und es ohne
Historie wenig Sinn macht, kann ich es ja auch gleich historisch anlegen.
Dazu war meine Frage nach dem Aufbau des Modells.
Rest ist klar, und sollte eigentlich aus der Grafik ersichtlich sein. Die TableID
hole ich mir aus MSysObjects.

@crystal
Es geht nicht nur um die beiden gezeigten Tabellen; - wie gesagt, das
sind ganzen jetzt so um die 30.

in Abfragen steht jeweils ein "...And DatumGeloescht = Null"

So ist es, denn es wird ja nicht physisch gelöscht.

Fraglich ist eben nur, welchen Sinn es macht zu erfahren, dass ein DS z. B. vorgestern geändert worden ist ohne zu wissen, welche Daten denn nun geändert wurden.

So genau will der Auftraggeber es nicht wissen, ihm reicht es zu wissen,
wer da zuletzt dran war.

Danke für eure Anteilnahme, und wenn da jetzt nicht noch was zum DM
kommt, würde ich das Thema schliessen.

gruss ekkehard

[crystal]

Hallo nochmal,

Falls deine Frage dahin deutet, die durchgestrichenen Felder im DM in eine separate Tabelle auszulagen (Normalisierung), würde ich davon abraten. Es ist sicher einfacher, diese Felder an der Oberfläche zu besetzen und sie in der betreffenden Tabelle zu speichern, als sie in eine extra Tabelle zu schreiben, was dann wieder zu komplizierteren Abfragen führen würde. Hierzu müsste man auch eine Referenz auf das geänderte Objekt mitführen, wie ja bereits in einer anderen Antwort gesagt wurde.

Liegen die Änderungs-Daten in den Tabellen selbst, kann doch viel einfacher darauf zugegriffen werden und das Prinzip der Redundanz-Vermeidung wäre anderenfalls nur durch erhöhten Verwaltungs-Aufwand zu erreichen. Auch würden Änderungs-Datensätze in einer Extra-Tabelle keinen Speicherplatz einsparen, da es nicht möglich ist, zu einem bestimmten Zeitpunkt gleichzeitig mehrere DS zu ändern (es sei denn. man beschränkt sich auf ungefähre Zeit-Angaben). Einziger Vorteil einer separaten Audit-Tabelle wäre es, einfach abfragen zu können, welcher Mitarbeiter in einem bestimmten Zeitfenster an welchen Tabellen Änderungen vorgenommen hat. Aber das ist mit einer mehrfachen UNION-Abfrage auch machbar und im SQL-Modus schnell codiert.

[Beaker s.a.]

Hallo crystal,

Hierzu müsste man auch eine Referenz auf das geänderte Objekt mitführen,

Welches Objekt?
Ich habe die TableID aus MSysObjects und den PK des DS aus der Tabelle.
Das sollte doch reichen.

Liegen die Änderungs-Daten in den Tabellen selbst, kann doch viel einfacher darauf zugegriffen werden

Das scheut mich nicht.

das Prinzip der Redundanz-Vermeidung wäre anderenfalls nur durch erhöhten Verwaltungs-Aufwand zu erreichen.

Welche Redundanz? Da wird doch nur jeweils ein DS in die Protokolltabelle
geschrieben.

Ich mach mal 'nen Test mit ein paar wenigen Tabellen und schau mir den
Aufwand an.

gruss ekkehard

[crystal]

Hallo Ekkehard,
wir meine ja beide das gleiche.
Die TableID und der PK sind zusammen eine Referenz auf das geänderte Objekt, das in der Audit-Tabelle geführt wird.

Aber warum einen solchen Aufwand treiben?

Im engeren Sinne handelt es sich um Redundanz, wenn in zwei oder mehr Tabellen Felder gleichen Namens/Inhalts existieren, oder? Genau genommen sind diese Felder aber nicht redundant, da sie nie denselben Inhalt haben/haben können (außer MA-Name). Naja - und kaum jemand käme auf die Idee, z. B. in einer MA-Tabelle den Vornamen auszulagern, um Redundanz zu vermeiden. Das wäre schlicht praxis-fern und dshalb macht es auch keiner. Vermutlich nicht einmal in der Telefonnummern-Datenbank der Telekom, trotz einiger Millionen Einträge. Und genau das meine ich, wenn man Datum/Uhrzeit/MA des Anlegens und der letzten Änderung eines Datensatzes schlicht im Datensatz selbst speichert, statt diese Informationen in eine separate Tabelle (mit Referenz aufs geänderte Objekt, s. o.) auszulagern.

Ein Test ist sicher gut, vor allem, wenn es sich um die Erweiterung eines bestehenden Systems handelt. Wenn du aber nur ein halbes Dutzend Tabellen zum Bestand hinzufügen musst, lohnt es m. E. nicht, hier neue Funktionalität oder Logik zu implementieren. Auch im Sinne der Pflegbarkeit eines solchen Systems wäre es vermutlich besser, bestehende Überlegungen/Techniken des Vorgängers zu übernehmen.

Aber egal - du wirst sicher eine praktikable Lösung für dein "kleines Projekt" finden, denn du bist ja kein Access-Neuling, sondern ein erfahrener Profi! Und das meine ich ehrlich.

Respektvolle Grüße

crystal

[Beaker s.a.]

Hallo crystal,

Aber warum einen solchen Aufwand treiben?

Weil's Spass macht was zu lernen.

sondern ein erfahrener Profi

Nicht wirklich, aber trotzdem danke für die Blumen.

gruss ekkehard