Szenarien für den ndreader / ndwriter 

Im Folgenden einige Fallbeispiele für den praktischen Einsatz von nadas.

 

1     dezentrale Datenanalyse

In den Datenbanken  eines zentralen Systems werden umfangreiche Daten gespeichert (Messergebnisse von Versuchsreihen, Wahlergebnisse, Teilekatalog, historische Kursdaten, Geodaten, Kundenstatistik, etc.)

 

Teile dieser Daten werden von verschieden Abteilungen für detaillierte Auswertungen benötigt.

Lösung:

Mit Hilfe des ndwriters werden periodisch, bzw. auf Anforderung Datenauszüge als NDF erstellt und je nach Größe per E-Mail verschickt oder per FTP-Server zum download bereitgestellt.

Vorteile:

1.     Aus der Signatur und dem Erstellungsdatum des NDF geht die Herkunft der Daten sicher und nachvollziehbar hervor.

2.     Auch bei unterschiedlichen dezentralen/zentralen System (z.B MS Windows PC, Linux Intel, SUN Sparc, AIX RS6000) muss nur ein Format erstellt werden.

3.     Laufzeitkritische SQL-Auswertungen können ausgeführt werden, ohne das zentrale System zu belasten.

2     Meldewesen / Reporting

Die Zentrale Z der xyz-Holding benötigt täglich/wöchentlich/monatlich statistische Daten ihrer europaweit/tweltweit operierenden Töchter/ branch offices/Filialen/ etc.

Lösung:

Jeder "Berichtspflichtige", im folgenden kurz B_,  erhält von der Zentrale ein NDF-File mit den leeren Tables und die zugehörigen SQL-LOAD  Befehle für die Verarbeitung.

 

B_ startet den ndwriter mit seiner Signatur und mit einer Kopie des NDF. Dann lädt er seine Daten in die vorgegebene Struktur.

 

Das so erstellte NDF hat die Signatur von B_ und den Zeitstempel der Erstellung.

 

B_ schickt das NDF dann an die Zentrale (z.B per E-Mail, per Kurier auf Datenträger, etc). 

 

In der Zentrale wird das NDF geprüft (Signatur, Datum, Datenkatalog) und anschließend die Daten ausgewertet.

 

Vorteile:

1.     Über das Datenmodell kann auf plausible Art die Einhaltung formaler Bedingungen (constrains) und damit eine Mindestdatenqualität erzwungen werden. (Datentypen, not null, primary key).

2.     Aus der Signatur geht der Autor hervor.

3.     Die NDF  internen Absicherungen sichern Vollständigkeit und Unverfälschtheit der Daten.

 

3     Archivierung

Der Inhalt einer Auftrags-, Kunden oder Bestandsdatenbank soll jeweils zum Monatsende gesichert werden.

Einzelne Datensätze hieraus werden von Zeit zu Zeit benötigt.

Lösung:

Die Sicherung erfolgt mit dem ndwriter, die NDF werden auf ein offline Medium geschrieben (Band, CD, DVD, SIM-Card etc )

Vorteile:

1.     Jede Sicherung hat eine Signatur, ein Datum und ist per Prüfsumme gesichert. Datensätze im NDF können nicht nachträglich verändert werden.

2.     Das NDF kann auf jedem System, das mit einem ndreader ausgestattet ist, ausgewertet werden. Es muss hierfür nicht wieder in die zentrale Datenbank geladen werden.

 

4         ndreader als high Performance Datenserver

Bei Stammdaten ist der Datenbestand oft über ein größeres Zeitintervall, Stunden, Tage u.U. mehrere Wochen oder gar Monate konstant. Geo-Daten sind ein gutes Beispiel hierzu.

 

Manchmal ist es sogar so, dass Datenänderungen nur in einem bestimmten Rhythmus und durch eine speziell autorisierte Instanz zulässig sind!

 

In diesem Fall sind NDF ideal, um diese Anforderung zu erfüllen.

 

Ein NDF ist nicht änderbar. Das ermöglicht dem ndwriter eine optimierte Speicherung (Kompression redundanter Daten und Optimierung der Indizes).

Dem ndreader ermöglich das eine optimierte interne Darstellung von Ergebnismengen (Pointer statt Wertekopien).

 

Je größer die Anzahl paralleler Abfragen ist, umso mehr kommt dieser Ressourcenvorteil in der CORBA-Servervariante des ndreaders gegenüber einem herkömmlichen Datenbanksystem zum tragen.

 

Da der ndreader mit einer beliebigen Anzahl NDF gleichzeitig gestartet werden kann, lassen sich je nach Änderungshäufigkeit der Daten, optimierte Strategien entwickeln

 

Beispiel: Daten die monatlich geändert werden liegen in NDF1, Daten mit täglicher (24 STD) Änderung in NDF2, Daten die 3x täglich geändert werden in NDF3. Sobald ein neues NDF2 aufbereitet ist, wird der ndreader "restartet".

 

Wird ein Teil der Daten neartime geändert, können diese Daten in einem Datenbanksystem liegen und die Stammdaten (schreibgeschützt) im NDF. ndreader und Datenbanksystem werden dann per ODBC-Bridge transparent miteinander verbunden.