das Herzstück von dsfdb.org
der MulitRecordEditor
sorgt dafür, dass der Webbestand von dsfdb.org den Qualitätsanforderungen entspricht, die wir uns vorgenommen haben.
Franz_Leo hat ihm bereits Leben eingehaucht und wir lassen euch mal ein bisschen hinter die Kulissen sehen.
Hier ein paar ScreenShots:
1. Die Database Selection
Hier wird zB. der Import-Catalog der Website (also die Daten die über die Website eingegeben werden) und die Merge-Import (in der die Daten gemischt werden) zusammengeschaltet.
Wie man sehen kann, bestehen derzeit sechs Cataloge
Admin - der Bereich der Websiteadministration (Userverwaltung, Verwaltung globaler Identifyer, Sessionverwaltung, usw.)
Base - der Arbeitscatalog
History - damit können alle Transaktionen zurückverfolgt werden und so Fehler in der Vergangenheit aufgefunden werden oder Recherchen über das Zustandekommen eines Webergebnisses stattfinden
Import - zum Importieren von Daten sei es von Datenprovidern im Großen oder durch das Webend
Lookup - der füttert die Auswahlfelder mit den Positionen (zB. Mediumformat, Währung, Ländercodes, usw.)
Web - das sind die Daten, die im Webend schlußendlich als offizieller Datenbestand präsentiert werden.
Auf diese Weise ist sichergestellt, dass der Webbestand immer konsitent ist. Er kann durch äußere Einflüsse zwar theoretisch verändert oder beschädigt werden, ist aber immer durch ein aktuelles Backup aus der lokalen Verwaltung schnell und 100% wiederherstellbar.
Selbst die Webeingaben haben keinen direkten Einfluß auf den aktuellen Webbestand, da in keiner Phase der Eingabe ein Schreib-, Änderungs- oder Löschvorgang den Webbestand verändert. Nur über das Mergingprogramm wird der Webcatalog in einer eigenen Aktualisierungssession neu geschrieben. Die übrigen Cataloge sind außschließlich in lokaler Verwaltung von Lektoren und können von außerhalb nicht erreicht werden.
Der AdminCatalog enthält nur die Daten, die zur Verwaltung der Website erforderlich sind und aus den übrigen Catalogen kann jederzeit der Webbestand zu und für einen beliebigen Zeitpunkt der Vergangenheit rekonstruiert werden.
2. Die Table Selection
Die Table Selection bietet Einblick in die einzelnen Tables und deren Datensätze - im Bild ein Datensatz aus den Verlagsreihen die zum Import anstehen.
3. Der eigentliche MultiRecordEditor
Die Testprogramme und die Mergeprogramme erzeugen Einträge in der Consistency Control Datei, die die (global Identifyer) Werte für zu überprüfende Paare enthält.
Auf diese Weise werden Datensätze die zum Import anstehen und durch den automatischen Import zur Überprüfung vorgeschlagen werden weil sie nicht den Konistenzregeln der Datenbank entsprechen einem Lektor zur Prüfung vorgegeben. Der MultiRecordEditor liest diese Einträge und zeigt diese zur händischen Überprüfung und Mischung an.
Die ScreenShots zeigen solche Überprüfungen.
Das Bild zeigt einen zurückgewiesenen Datensatz (er wird nicht in das Webend aufgenommen)
dieses Bild zeigt zwei Datensätze aus Import und Web beim Mischen einer Webeingabe mit dem aktuellen Datensatz des Web-Cataloges.
Natürlich ist das Programm nur so gut, wie die Regeln die die automatische Prüfung vornehmen. Wir arbeiten mit Hochdruck daran diese immer wieder zu verfeinern und auf Fehlerquellen abzuklopfen. Und hier hilft uns die Zeit. Je länger und öfter wir Importe durchführen, desto feiner können wir die Prüfregeln knüpfen. Ich denke Franz_Leo leistet hier Pionierarbeit und er kann hier seine jahrelange Erfahrung exzellent einbringen.
Alles in Allem sollte es zeigen, dass wir technisch in der Lage sind einen entsprechenden Input (sei es aus dem Webend oder in jeder anderen Weise) auch tatsächlich entsprechend unseren Qualitätsrichtlinien umzusetzen.
Tja, das war's für's erste wiedereinmal aus der dsfdb.org - Küche
Haben wir euch Appetit gemacht?
Schönes Wochenende
Gruß
Thomas
Bearbeitet von t.sebesta, 09 März 2005 - 08:31.
