Relationales Schema für Münzensammlung

Bob Hairgrove

Bob Hairgrove

Neuer Benutzer
Beiträge
3
Hallo,

ich versuche gerade ein Schema für meine Münzensammlung zu entwerfen und habe gemerkt, wie kompliziert das Modell wird. Vor allem, wenn man Varianten- bzw. Abarten sammelt...

Die am naheliegendsten Attribute sind schnell erfasst: Länder, Jahrgänge, metallurgische Komposition, Gewicht, Münzstätten bzw. Münzmeister, Erhaltung, usw. Allerdings gibt es einige Knackpunkte:

1. Länder existieren oft nur für mehr oder weniger klar definierte Zeiträume;
2. Varianten entstehen manchmal durch verschiedene Kombinationen von Vorderseite/Rückseite (so genannte "mules" auf englisch), also muss man beide Seiten separat erfassen. Allerdings findet man einige Varianten meistens nur innerhalb einer Zeitspanne von 2-3 Jahren;
3. Manchmal besteht Unklarheit ob eine Variante eine Fehlprägung oder z.B. von Stempelrissen entstehen, Prägung auf falsches Metall oder auf Rohlinge der falschen Grösse -- und es gibt ganze Klassifizierungen von diesen Abarten, die zu erfassen wären;

Hinzu kommen einige Attribute, die eher kaufmännischer Natur sind (An- und Verkaufspreise, Erstehungsdatum, usw.)

Ist das ein Rad, das evtl. schon einmal erfunden wurde? Zum Glück sammle ich nur Münzen und keine Medaillen, und auch keine antiken Münzen (römisch, griechisch usw.), da wird es wesentlich schwieriger.
 
Werbung:
Habe das Schema nun etwas genauer angeschaut ... es gibt leider einige Probleme mit 1NF (Tabelle "related_item", Spalten "item_id_1", "item_id_2", etc.) sowie offenbar redundante Daten (Tabelle "item", Spalten "item_date" und "item_year") und berechnete Daten, die in einer Tabellenspalte gespeichert anstatt durch eine VIEW sichtbar gemacht (Tabelle "collection::current_value").

Gerade das Datum einer Münze wirft Probleme auf, weil das Jahr auf der Münze entspricht nicht immer dem Jahr, wo die Münze tatsächlich geprägt wurde (geschweige denn dem Datum...). Es gibt z.B. bei russischen Kupfermünzen aus der Zeit von Katharina II ("die Grosse") und Paul viele Neu- und Überprägungen, die frühere Jahren anzeigen, als sie tatsächlich geprägt wurden (z.B. 1791 oder 1793 anstatt 1797). Dann gibt es eben auch die Münzen, die tatsächlich in den aufgeprägten Jahren gemünzt wurden.

Münzen wurden auch oft in anderen Ländern geprägt als im Heimatland der Münze (z.B. wurden fast alle Münzen der Philippinen und Hawaii in den USA geprägt; russische Kupfermünzen aus der 2. Hälfte des 19. Jh. wurden oft in Birmingham/England geprägt, obwohl die geprägte Münzstätte St. Peterburg "С.П.Б." zeigt).

Der Wert einer Münze (oder Briefmarke) ist nicht so direkt von der Erhaltung abhängig, sondern in Zusammenhang mit der Rarität. Ich denke, dass hier ein Bereich angegeben werden müsste. Es ist auch nicht so einfach, lineare Korrelationen anzuwenden, denn einige Münzen sind in zirkuliertem Zustand manchmal sogar höher bewertet, als in unzirkuliertem Zustand -- z.B. der Morgan-Dollar 1884-S aus USA.

Wie gesagt: Es ist eben kompliziert! :D
 
Ich habe mir über "ungenaue" Datumsangaben auch schon so meinen Kopf gemacht, z.B. wenn man nur Monat und Jahr, aber nicht den Tag kennt. Man kann sich da natürlich was basteln aber am Ende arbeitet man in jedem Fall nicht mit einem Datum und vielen Datumsfunktionen, sondern muss sich eventuell mit mehreren Spalten und einer eigenen Suchlogik behelfen.

In dem Fall könnte man solche Werte dann auch im EAV Prinzip speichern. Da ist man dann beim Datenmodell sehr flexibel, eine Suchlogik ist dann natürlich etwas arbeit.

Entity–attribute–value model - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Werbung:
Bob Hairgrove schrieb:
es gibt leider einige Probleme mit 1NF
Zum Vergrößern anklicken....
In einem komplexen Modell (".. es ist eben kompliziert ...") kann das vorkommen. Es ist nicht verboten, die Normalform zu verletzen. Es ist dann aber schärfstens geboten, manuell (Programmcode) für Überwachung und Konsistenz zu sorgen.
Beim Beispiel "item_date" und "item_year" stellt sich mir spontan die Frage, welche Informationen werden denn hier überhaupt gespeichert? Mglw. ein Create Date (des Datensatzes) sowie das Prägungsjahr? Dann wäre es ok. (Ich habe mir nicht die Mühe gemacht, meine spontane Idee zu überprüfen)
Deine Schilderung lässt am Ende offen, was Du erreichen möchtest. Erwartest Du, etwas besseres zu finden? Erwartest Du Verbesserungsvorschläge?
Erwartest Du noch etwas anderes?

Ich würde sagen, das ganze Modell (inkl. Defizite) bringt Dir auch verbessert nichts, wenn Du keine Software drumrum hast, die es nutzt. Also warum nicht anfangen und die Software schreiben?
Was die genannten Defizite angeht, ein Modell heißt u.a. so, weil es die Wirklichkeit in einem (statischen) und nicht 100% zutreffenden Modell abbildet. (Fast) jedes Datenbank-Modell dürfte ein Kompromiss sein...

ukulele schrieb:
In dem Fall könnte man solche Werte dann auch im EAV Prinzip speichern
Zum Vergrößern anklicken....
Wenn ich es richtig in Erinnerung habe, bietet das Modell bereits ein EAV Bereich an.
 
Zurück
Oben