Versionierung von Datensätzen

[Francois Zbinden]

Hallo

Ich habe eine grundsätzliche Frage, zu der ich noch keine generelle Antwort
gefunden habe.
Beispielsweise habe ich in einer Datenbank zwei Tabellen, Produkte (Name,
Preis)
und Bestellungen (ProduktNr, Menge). Soweit so gut. Jetzt ändert der
Benutzer
unter den Produkten den Preis. Jetzt wenn ich jetzt vergangene Bestellungen
betrachte und aus der Menge und ProduktNr den Totalbetrag ausrechnen
möchte stimmen die Angaben natürlich nicht mehr mit der originalen
Bestellung überein.

Ich sehe folgende Lösungsmöglichkeiten:
A. Speichern des Preis in der Bestllungstabelle
-> Redundanz der daten

B. Es dürfen generell keine Änderungen an einem bestehenden Produkt gemacht
werden.
Stattdessen muss das Produkt als neuer Datensatz erfasst werden.
-> Inkonsistenz

C. Einfügen einer Versionsnummer bei der Produktetabelle, Änderungen an
einem Produkt
können nicht mehr gemacht werden, statdessen wird der Datensatz kopiert,
behält dieselbe ProduktNr aber erhalt höhrere Versionnummer
-> Aufwendigere Realisation

D. Erstellen von (sehr vielen) Zwischentabellen bei denen alle mutierbaren
Daten
unabhängig vom Originaldatensatz (Produkt) in einer Zwischentabelle
gespeichert werden.
-> Aufwendigere Realisation

Gibt es vielleicht andere Ideen? Kann jemand aus Erfahrung eine generelle
Empfehlung
geben welches Konzept auf Dauer sich besser bewährt? Konkret handelt es sich
um
ein kleineres Projekt, welches aber doch senstive Daten verwalten muss. Als
Datenbank möchte ich Interbase / Firebird einsetzen.

Francois Zbinden

[Matthias Lippmann]

Hallo Francois,

Post by Francois Zbinden
Ich habe eine grundsätzliche Frage, zu der ich noch keine generelle Antwort
gefunden habe.
Beispielsweise habe ich in einer Datenbank zwei Tabellen, Produkte (Name,
Preis) und Bestellungen (ProduktNr, Menge). Soweit so gut. Jetzt ändert der
Benutzer unter den Produkten den Preis. Jetzt wenn ich jetzt vergangene Bestellungen
betrachte und aus der Menge und ProduktNr den Totalbetrag ausrechnen
möchte stimmen die Angaben natürlich nicht mehr mit der originalen
Bestellung überein.
A. Speichern des Preis in der Bestllungstabelle
-> Redundanz der daten

Ich sehe hier keine Redundanz. Die Preis-Attribute in den Tabellen
"Artikel" und "Bestellzeilen" beschreiben doch jeweils einen eigenen,
unabhängigen Sachverhalt (was Du ja auch selbst ausgeführt hast.).
Der Preis in der Artikel-Tabelle kann als Standardpreis für neue
Bestellungen oder als unverbindliche Preisempfehlung betrachtet
werden.
Der Preis in den Bestelldetails ist dagegen spezifisch für genau einen
Bestellvorgang (Es wäre ja auch denkbar, dass Preise zwischen Kunde
und Verkäufer frei vereinbart werden)

Post by Francois Zbinden
B. Es dürfen generell keine Änderungen an einem bestehenden Produkt gemacht
werden.
Stattdessen muss das Produkt als neuer Datensatz erfasst werden.
-> Inkonsistenz
C. Einfügen einer Versionsnummer bei der Produktetabelle, Änderungen an
einem Produkt
können nicht mehr gemacht werden, statdessen wird der Datensatz kopiert,
behält dieselbe ProduktNr aber erhalt höhrere Versionnummer
-> Aufwendigere Realisation

B und C unterscheiden sich ja kaum, es wird jeweils eine Kopie des Artikel-
Datensatzes angelegt. Da bei B die Produkt-Nr. nicht mehr eindeutig ist,
wird eine neue angelegt, bei C muss der Primärschlüssel aus ID und Version
zusammengesetzt werden.
Hier tritt auf jeden Fall eine vermeidbare Redundanz ein, wenn sich jetzt ein
anderes Attribut des Artikels ändert (z.B. der EK-Preis oder die Verpackuns-
einheit oder ...) dann müssen jetzt n Datensätze geändert werden statt nur
einem.

Post by Francois Zbinden
D. Erstellen von (sehr vielen) Zwischentabellen bei denen alle mutierbaren
Daten
unabhängig vom Originaldatensatz (Produkt) in einer Zwischentabelle
gespeichert werden.
-> Aufwendigere Realisation

Das wäre auch denkbar und kann - je nach Anforderungen an das System -
durchaus sinnvoll sein. Es wäre ja z.B. denkbar, dass bestimmte Kunden
oder Kundengruppen spezifische Preise oder Rabatte für einen Artikel oder
eine Warengruppe erhalten. Das müsste dann eben in mehreren Tabellen
abgebildet werden.

Falls Du MS Access oder SQL Server besitzt, kannst Du ja mal das Daten-
modell der Beispielanwendung "Nordwind/Northwind" betrachten, hier wurde
auch Lösung A gewählt.

[Hanspeter 'Happl' Oberlin]

Post by Francois Zbinden
Ich habe eine grundsätzliche Frage, zu der ich noch keine generelle Antwort
gefunden habe.
Beispielsweise habe ich in einer Datenbank zwei Tabellen, Produkte (Name,
Preis)
und Bestellungen (ProduktNr, Menge). Soweit so gut. Jetzt ändert der
Benutzer
unter den Produkten den Preis. Jetzt wenn ich jetzt vergangene Bestellungen
betrachte und aus der Menge und ProduktNr den Totalbetrag ausrechnen
möchte stimmen die Angaben natürlich nicht mehr mit der originalen
Bestellung überein.
A. Speichern des Preis in der Bestllungstabelle
B. Es dürfen generell keine Änderungen an einem bestehenden Produkt gemacht
werden. Stattdessen muss das Produkt als neuer Datensatz erfasst werden.
C. Einfügen einer Versionsnummer bei der Produktetabelle, Änderungen an
einem Produkt können nicht mehr gemacht werden, statdessen wird der Datensatz
kopiert, behält dieselbe ProduktNr aber erhalt höhrere Versionnummer
D. Erstellen von (sehr vielen) Zwischentabellen bei denen alle mutierbaren
Daten unabhängig vom Originaldatensatz (Produkt) in einer Zwischentabelle
gespeichert werden.

Ich schlage eine Kombination aus A und D vor.

A: der Preis wird in die Bestllungstabelle eingefügt und nicht
mehr geändert (damit Bestellungen auch wirklich nachvollzogen
werden können).

D: die Preisinformationen werden aus der Artikeltabelle in eine
eigene Preistabelle ausgelagert und mit der Information "gültig ab"
ergänzt (so ist 1) die Preishistory eines Artikels bekannt und es
können 2) Preise auch zukünftige Preise erfasst werden).


Lösung C ist natürlich auch möglich, doch würde ich statt einer
Versionsnummer die Information "gültig ab" als zusätzlichen Schlüssel
wählenl.

Grüsse aus der Schweiz
Happl

[Josef Snayberk]

Post by Hanspeter 'Happl' Oberlin
Ich schlage eine Kombination aus A und D vor.
A: der Preis wird in die Bestllungstabelle eingefügt und nicht
mehr geändert (damit Bestellungen auch wirklich nachvollzogen
werden können).> In article
D: die Preisinformationen werden aus der Artikeltabelle in eine
eigene Preistabelle ausgelagert und mit der Information "gültig ab"
ergänzt (so ist 1) die Preishistory eines Artikels bekannt und es
können 2) Preise auch zukünftige Preise erfasst werden).
Lösung C ist natürlich auch möglich, doch würde ich statt einer
Versionsnummer die Information "gültig ab" als zusätzlichen Schlüssel
wählenl.
Grüsse aus der Schweiz
Happl

Keine Kombination von A _und_ D sondern er soll sich entscheiden zwischen
A _oder_ D.

A ist eine einfache und schnell zu realisierende Lösung, entspricht aber
nicht der "reinen Lehre" sprich: Normalisierung. Aber Normalisierung ist
ja nicht alles.

D wäre weiter normalisiert und funktioniert auch ohne Preis in der
Bestelltabelle, wenn diese mit der Preishistorie über die Artikel-ID und
das Bestelldatum verknüpft ist.

Gruß