THEMA: Modellbahndatenbank mit Artikelimport

Hallo Andreas,
schau dir doch mal die Müller Modelldatenbank an, ich glaube die kann auch importieren, die Frage ist ja welches Datenformat du vorliegen hast und weniger ob die Datenbank das kann.

http://www.muellerbahn.de//pages/modell-datenbank.php

Ein Bekannter hat eine Warenwirtschaft aus dem Internet als ModellDB benutzt und kann somit alle Preislisten der Hersteller direkt importieren, Bilder verwalten und vieles mehr ..

Die Müller DB hab ich gerade angefangen zu füttern und mir scheint sie ist sehr umfangreich und bietet sehr viele nützliche Funktionen.

Grüße
Patrik

Hallo Patrik

Ich mich hier unklar ausgedrückt, ich meine eine automatisierte Importfunktion mittels Schnittstelle zu einer Online-Artikeldatenbank und keinen Einmal-Import von Datensätzen. In diesem Fall ist mir als User das Datenformat bzw. Datenmodell dann auch egal. (Wunsch: Ich suche ein Modell online über Beschreibung oder Artikelnummer, wähle es aus, die Datenbank importiert zu diesem Modell die bereits online gepflegten Daten und ich füge meine Invidualdaten hinzu.)

Das Müller-Programm hatte ich mir schon angesehen. In der Beschreibung sind zwar einige hundert Felder zum Erfassen von Artikeldaten, Ersatzteildaten, Wartungsdaten, Katalogdaten etc. enthalten, aber kein Hinweis auf eine Importfunktion einer Onlinedatenbank (vergleichbar der freedb.org für Musikeinspielungen, der Ebay-Artikeleinstellungsautomatik oder der Content-Datenblätter wie sie beispielsweise von CNet zur Verfügung gestellt werden).

Die Spur-N-Datenbank wäre zum Beispiel eine nützliche Quelle für eine solche Schnittstelle. Sie weist zwar nur um die 16,17 Felder auf, aber diese muss man zumindest nicht selbst befüllen.

VG
Andreas

Die Idee finde ich gut! Wie oft schreibe ich Wagennummern von den Modellen runter und stelle später fest, daß ich 'ne 1 mit 'ner 7 verwechselt habe usw. Wenn wir da irgendwo die Daten der Modelle zentral hätten, dann könnte jeder seine Daten lokal ergänzen. Umgekehrt wird ja nun der Schuh draus: Wenn einfach alle ihre Daten mal rausgeben ( ohne Anzahl und von mir aus auch ohne Namen, um nicht die bösen Buben zu locken) dann wäre der Rest ja nur noch eine Kleinigkeit. Schön wäre, wenn auch gleich Bremsgewichte für die einzelnen Bremsarten usw. dabie wären. Dann hätte man auch gleich noch die Daten für Wagenliste & Bremszettel fertig.

Ich fänd es toll! Ein bißchen SQL kann ich noch

Gruß
Klaus

Hallo Klaus,

Genau so hätte ich mir das auch vorgestellt

Eine Symbiose aus einer Online-Datenbank (z. B. Spur-N-Datenbank - einige wirken mit, es sammeln sich einige Daten) und einer lokalen Datenbank (z. B. Müller-DB - Felder ohne Ende, aber jeder beginnt für sich von vorne, Waschzetteldatenbank, Ersatzteildatenbanken...).

Ich könnte mir vorstellen, dass durch die Möglichkeit der lokalen Replikation eine ungleich höhere Motivation zur Mitwirkung an einer Online-Datensammlung besteht als bei einer reinen Netz-Datenbank.

Die Folge: eine hohe Dichte von Modell- und Vorbildbildern- und Daten je Modell inkl. Verknüpfung mit Ersatzteillisten, Beschreibungen, Hilfetexten bzw. Praxistips (Reparatur, Tuning etc.).

Letztendlich kann über so ein Modell auch eine Modell- und Ersatzteilbörse entstehen, indem die Möglichkeit besteht, einzelne Bestände einer Individualdatenbank online freizuschalten (zum Verkauf, Tausch oder auch als Gesuch).

VG
Andreas

Hallo,

eine Import-Schnittstelle ist nicht das Problem. Ich muss aber Zugriff auf die Felder einer Online-Datenbank haben, um die gewünschten Daten zu erhalten, und diese Möglichkeit besteht meines Wissens bisher nicht. Um Daten "von irgendwo" importieren zu können, müssen sie so vorliegen, dass sie den Feldern der Empfänger-DB entsprechen. Es gibt z. B. immer Importdaten, denen in der Empfänger-DB kein Feld entspricht. Wohin damit? Auch kann die Importfunktion nicht automatisch ihr unbekannte Felder zuordnen; denn woher soll das Programm wissen, dass "Nummer" aus der Sender-DB dem Feld "Art-Nr" in der Empfänger-DB entspricht. Automatisch geht das nur, wenn es ein einheitliches Format gibt, d. h. wenn die Daten in einer zuvor festgelegten Form und Reihenfolge vorliegen.  So etwas muss deshalb einmalig zwischen Sender- und Empfänger-DB abgestimmt werden.

Ich könnte in meine ModellDB jederzeit Daten automatisch importieren, sofern eine Importdatei vorliegen würde (.xls oder .txt), die einer von mir noch zu erstellenden Schnittstellenbeschreibung entspräche.


Gruß
K.U.Müller

Guten Morgen Karl Ulrich,

gratuliere Vorab zu Deiner Modellbahn-Datenbank. Hier hast Du schon ein mächtiges Werk geschaffen. Aber gerade weil die Möglichkeiten Deiner Datenbank zur Erfassung von so zahlreichen und auch verknüpften Daten so umfangfreich sind, ist es für einen Einzelnen (im Normalfall) wohl schon aus zeitlichen Gründen kaum möglich, mehr als einen Bruchteil der Möglichkeiten der Datenbank zu nutzen. Noch gar nicht davon gesprochen, dass nicht jeder Zugang zu allen Datenoptionen hat, die Du vorgesehen hast.

Bezüglich eines Imports von Online-Quellen.

1. FELD-IDs

Du schreibst, Online-Daten müssten "so vorliegen, dass sie den Feldern der Empfänger-DB entsprechen" bzw. "Auch kann die Importfunktion nicht automatisch ihr unbekannte Felder zuordnen; denn woher soll das Programm wissen, dass "Nummer" aus der Sender-DB dem Feld "Art-Nr" in der Empfänger-DB entspricht."

Obwohl ich kein Programmierer bin, möchte ich hier  anmerken, das dies kein immenser Aufwand sein sollte:
Für einen Import müßte lediglich eine Zwischentabelle geschaffen werden, in der passende Felder aus DB 1 den passenden Feldern aus DB 2 zugeordnet werden, dies sollte für einen Programmierer eine sehr leichte Übung sein.

2. "FEHLENDE" FELDER

Du schreibst: "Es gibt z. B. immer Importdaten, denen in der Empfänger-DB kein Feld entspricht. Wohin damit?"

Das ist schnell besprochen: Die Empfänger-DB bekommt ein weiteres Feld oder diese Daten werden nicht synchronisiert.

3. DATENSATZ-IDs

Du schreibst: "Automatisch geht das nur, wenn es ein einheitliches Format gibt, d. h. wenn die Daten in einer zuvor festgelegten Form und Reihenfolge vorliegen."

ich denke, Form ist sekundär und die Reihenfolge nach meinem laienhaften Verständnis egal.

Die Herausforderung liegt eher darin, dass beide Datenbanken mit übereinstimmenden Datensatz-IDs arbeiten müssen. Aus diesem Grund (und wohl auch aus rechtlichen Überlegungen) müssen die Verfüger über beide DBs eng zusammenarbeiten.

Dazu wird eine Zwischentabelle benötigt, in welcher Deinen Datensatz IDs die korrekten Datensatz IDs einer anderern Datenbank zugeordnet sind. Dies ist ein relativ großer Aufwand, da  bei neu hinzukommenden Modellen jeweils darauf Rücksicht genommen werden muss.

Idealerweise gibt es dann eine Masterdatenbank, und nur in dieser werden neue Modelle erfasst (sonst ist es eine Sisyphos-Arbeit mit dem ständigen Abgleich).

3.a SUCHE

Im Übrigen müsste dann die "Suchfunktion" Deiner Datenbank so angepasst werden, dass die Nutzer über die Suche sowohl Ihre Individualdaten abfragen können wie auch die online bereits konsolidierten Datensätze.

3.b UPDATE

Auch sollten die bestehenden Nutzer Deiner Datenbank die Möglichkeit haben, Ihre bisher erfassten Datensätzen einmalig manuell oder halbautomatisiert in die neue Version Deiner DB zu übernehmen, und dabei Ihren individuellen Datensätzen dann die richtigen IDs der neuen DB zuzuordnen. Hier ist auch zu klären, wie mit unterschiedlichen Feldinhalten umgegangen werden soll (z. B. könnten die alten Individual-Daten in einer "Schattenkopie" eines jeden Feldes hinterlegt werden, sodass es keine Kollissionen gibt.

4. DATENABGLEICH

Last not least wäre zu klären, welche Daten in welcher Datenbank aktuell gehalten würden. Wenn es keine Masterdatenbank gibt, in welcher ausschließlich neue Datensätze und neue Felder angelegt werden, dürfte der Programmieraufwand (endgültig ) immens werden.

5. DATENREDAKTION

ist leider auch noch ein Thema. Wer darf was, wer kontrolliert Neueinträge und Änderungen......

VG
Andreas

Ich denke, das ganze ist nicht so kompliziert, wie es sich erst einmal anhört.

Von einer Quelldatenbank müssen die passenden Felder gefunden werden und dann die Daten mit entsprechenden Formatkonvertern in die jeweils neue Datenbank gezogen werden. Da hier ggf. jeder eine andere Feldbezeichnung hat, jeder andere Formate für Wagennummern bevorzugt usw. ist das erst einmal für jeden selbst eine Festlegung.

Technisch ist das aber Kindergarten.

Wichtig wäre mir dabei noch, daß am Ende wahrscheinlich viel mehr "Felder" zur Verfügung stehen, als bisher in einer einzelnen. Durch zusammenfassen der DBs wird es dann aber unvollständige Sätze geben, was aber auch nicht schlimm wäre.

Man kann das Ganze nun noch deutlich vereinfachen, indem man ein "globales Zielformat" festlegt. Dann hat jeder Anwender nur noch eine Hin- und Her- Definition. Ich fürchte nur, daß das EINE Format schwer zu finden ist und sich vermutlich in kurzer Zeit mehrfach endet.

Lange Rede, kurzer Sinn:
Ich würde meine Daten natürlich in irgendeiner Form bereitsstellen. Derzeit ist es nur eine Tabelle, aber die nach SQL zu importieren ist ja schnell erledigt. Export über XML usw. ist ja sowieso immer dabei.

Wenn sich ein paar Leute hier melden, dann können wir ja die Datenbestände mal sichten und mal schauen, was man daraus zusammenmischen kann. Toll wäre es natürlich, wenn wir auch die Daten aus den Online-Banken mit einbeziehen könnten. Hat da jemand Kontakte?

Gruß
Klaus

Eine Excel-Tabelle könnte einen Anfang darstellen.

Diese sollte diverse Felderlisten enthalten (z. B. für Vorbilder, Hersteller, Wagen, Loks, Ersatzteile, Herstellerkataloge).

Die DB-Struktur der DB von Karl-Ulrich wäre hier sicher eine schöne Basis.

Wenn jeder dazu beiträgt und aus der von ihm benutzen Datenbank Felder zuordnet oder fehlende Felder angibt, ergibt sich recht bald ein Gesamtbedarf. Ob eine Datenbank 300 oder 600 Felder je Datensatz hat, ist der Datenbank von der Performance relativ egal. Es ist eher eine Herausforderung an die Usabilty (Bedienbarkeit und Übersichtlichkeit).

Als nächster Schritt könnten dann die 1:N und N:N Verknüpfungen definiert werden.
Z. B: LOK A aus der Vorbilddatenbank wird hergestellt von Hersteller A, C, und E aus der Herstellerdatenbank mit diesen und jenen Artikelnummern/Varianten......

VG
Andreas

Hallo Andreas,



Was meinst du damit konkret? Es wäre eigentlich widersinnig, wenn es Optionen gäbe, die nicht benutzt werden dürften. Bewusst habe ich zumindest den Zugang zu irgendeiner Option nicht gesperrt.



Eben. Anfangs meines Berufslebens wurden in meiner Abteilung die Worte "lediglich" und "mal eben" aus dem Wortschatz verbannt. Es gab den Leitsatz: Lediglich und mal eben wird teuer.

Wenn es eine allgemeingültige "Zwischentabelle" gäbe, wäre die Schaffung einer ebenso allgemeingültigen Importfunktion kein großer Akt. Aber hieran scheitert es ja zunächst einmal. Ich habe schon das eine oder andere Mal Daten zur Verfügung gestellt bekommen, um sie für Kollegen zu importieren. Das war ein Aufwand zwischen einigen Stunden und in einem Extremfall von mehreren Tagen. Es kommt nämlich darauf an, ob die Daten in einem mehr oder weniger chaotischen Zustand bereitgestellt werden. Und was für einen Programmierer eine leichte Übung zu sein scheint, ist für nicht Geübte schon deshalb schwerer, weil sie nicht wissen können, was in welcher Form erforderlich ist. Die sogenannte "Zwischentabelle" ist im Prinzip die Schnittstelle.



Das ist leider nicht so. Wenn ich Daten angeboten bekomme, muss ich wissen, in welchem Feld der Quelle steht was? Der eine liefert z. B. im ersten Feld einer Excel-Datei die Artikel-Nummer, ein anderer die Hersteller-Bezeichnung. Ich kann also nicht automatisch zuordnen. Jede professionelle Schnittstellenbeschreibung beinhaltet Datensatzbeschreibungen und die darin enthaltenen Felder in der festgelegten Reihenfolge. Wenn ich Daten für eine fremde DB anliefere, muss ich diese Beschreibung minutiös einhalten, sonst lehnt die empfangende DB, wenn sie professionell gemacht ist, den Import ab oder erzeugt im besten Fall ein Fehlerprotokoll.

Die besagte Excel-Datei ist nur dann hilfreich, wenn genau festgelegt ist, wie viele Spalten pro Tabelle existieren müssen und welchen Inhalt jede einzelne Spalte zwingend haben muss (wobei auch eine leere Spalte möglich ist). Mit anderen Worten: Was steht in jeder Spalte (also z. B. Baureihe in Spalte 5, Betriebsnummer in Spalte 6 usw.) und zwar bei jedem Export immer in derselben Spalte. Das Quell-Programm sollte beim Export also in der Lage sein, diese Reihenfolge festzulegen. Anderenfalls müsste die Excel-Datei von Hand entsprechend strukturiert werden.



Das ist theoretisch denkbar, kommt aber in der Praxis allenfalls vor, wenn es sich um dieselbe DB handelt (z. B. in meiner DB beim Update-Import). Zwei völlig unterschiedliche DB können keine identischen Datensatz-IDs aufweisen (außer durch Zufall, was aber nicht hilft).



Mit einer Datensatz ID ist es nicht getan; denn die gilt für den gesamten Datensatz. Es wird aber eine Zuordnung jedes einzelnen Feldes des Datensatzes benötigt. Ein Lok-Datensatz nützt nichts, wenn die Artikel-Nr. der Lok mal in Feld01 und mal in Feld05 des Datensatzes stehen würde. Die Zuordnung muss insoweit manuell gemacht werden, wobei man wissen muss, was in welchem Feld steht (was beileibe nicht immer klar erkennbar ist, wenn eine Dokumentation fehlt).



Die Übernahme der Daten in eine neue Version geschieht doch schon von Beginn an automatisch. Eine Zuordnung von IDs ist weder erforderlich noch wünschenswert. Das ist ja genau der oben beschriebene Fall: Wenn ich Daten aus meiner eigenen DB importiere, stimmen die Feldnamen 1:1 überein, so dass die DB die Zuordnung vollautomatisch übernimmt.



Das verstehe ich noch nicht. Mit scheint aber, dass Du soeben an einem Grundprinzip jeder relationalen DB rüttelst: Redundanzfreiheit.

Hallo Klaus,



Das sieht zunächst vielleicht so aus. Ich habe in meinem früheren Leben eine Vielzahl unterschiedlichster Schnittstellen entwickelt und kann sagen, dass es offensichtlich ein weiteres Murphy-Gesetz gibt: Nichts geht so leicht, wie es anfangs aussieht.  

Gruß
K.U.Müller

Jeder der Daten im- oder exportieren will, muss seine Daten beschreiben. Z.B. so:
http://en.wikipedia.org/wiki/W3C_XML_Schema
Wenn dann einer "Artikelnummer"  und der andere "Artnr" als Feldbezeichnug hat, dann muss man das bei der Konvertierung von Schema A zu Schema B berücksichtigen. Gibts bestimmt Tools dafür. Disclaimer: Bin aber kein Database-Informatiker. Wenn man sich an Schemas hällt, dann muss man zumindest nicht einzelne Daten von Hand konvertieren.

Gruß,
Harald.

Hallo,

ich habe mal als Beispiel eine Import-Schnittstelle nur für Tfz beschrieben und auf meiner website hinterlegt. In dieser Art würde für jede DB-Tabelle eine Schnittstelle beschrieben werden müssen und der "Lieferant" von Quelldaten müsste sich daran halten und entsprechende Excel-Tabellen erzeugen. Dann kann man einen automatischen Import machen.
http://www.muellerbahn.de//pages/downloads.php

Gruß
K.U.Müller

Hallo Karl Ulrich

Mit "Zugang zu Datenoptionen" meinte ich die ganzen inhaltlichen Quellen, aus denen man seine Datenbank befüllen könnte (wenn man alle Felder voll kriegen möchte), und auf all diese Inhalte können sicher nur wenige User zugreifen.

"Zwischentabelle": allgemeingültig kann die nie sein, es ist immer eine manuell angefertigte, die Felder zwischen DB 1 und DB 2 referenziert, sie kann nur für 2 Datenbanken passen, nicht für mehrere.

"Reihenfolge des Imports".: wenn wir jetzt nicht von einer einfachen Tabelle wie *.csv oder *.xls sprechen sondern einer  Datenbank, dann sollte die Reihenfolge von Feldern nicht wichtig sein, da sich Felder über eine ID identifizieren.

"Herausforderung übereinstimmender Datensatz-IDs zwischen 2 Datenbanken". Natürlich meine ich nicht, dass die zufällig schon passen (dann wäre es ja keine "Herausforderung"), sondern dass beide Datenbanken IN ZUKUNFT pro "gleichem Modell bzw. Artikel bzw. Ersatzteil" eine gemeinsame ID-verwenden müssen.

"Mit einer Datensatz ID ist es nicht getan.... es wird eine Zuordnung jedes einzelnen Feldes des Datensatzes benötigt"..... das habe ich ja ganz oben mit der referenzierenden Zwischentabelle gemeint, in der die Felder der Datenbanken einander zugeordnet werden. Die Datensatz-ID ist schon pro Datensatz gemeint, hier geht es um die "Herausforderung" siehe obiger Absatz.

"Automatische Übernahme von Daten bei Import, Zuordnung von IDs":
Wenn wir von einer zukünftigen Online-Datenbank sprechen, bei der mehrere User auf die selben Datensatz-Inhalte zurückgreifen können, dann kann ein solcher automatischer Import in die neue Version nicht funktionieren. Woher soll die Datenbank mit Sicherheit erkennen können, welches vom User bisher eingetragene Modell zweifelsfrei welchem Online-Datensatz entspricht. Dies kann nur über eine Vorschlagsfunktion aufgrund von Feldübereinstimmungen geschehen, der User selbst muss entscheiden, ob der Vorschlag korrekt ist

"Grundprinzip der Redundanzfreiheit". Kenne ich, und die neue Datenbank ad se muss dieses natürlich beherzigen. Es wird aber Redundanzen in der Form geben, dass 50 User in 50 alten Datenbanken für das ein und das selbe Lokmodell 50 verschiedene Bezeichnungen, Beschreibungen und Zusatzinfos eingegeben haben. Entweder verliert man diese Info beim Import, oder man muss diese Information irgendwo User-individuell in dessen lokalen Datenbankversion abspeichern, genau genommen sind diese Infos nicht wirklich redundant

Solche Datenbankstrukturen lassen sich erfahrungsgemäß per Mail und Posts kaum besprechen. Meist ist die Materie so komplex, dass man sogar im direkten Gespräch mit Notizblock und Bleistift immer wieder aneinander vorbeiredet.

Ich bin zwar kein Programmierer, erteile aber für unsere eigene Firma und für unsere Kunden seit vielen Jahren Aufträge an professionelle Programmierfirmen, wobei auch die Pflichtenhefte gemeinsam erarbeitet werden. Also ganz "Grün" bin ich bei diesem Thema nicht.

VG
Andreas