Moderne Post-Organisationen haben ein zentrales elektroni- sches Adressverzeichnis (ZAV), in dem alle zu beliefernden Adressen (Zustellpunkte) aufgezeichnet sind. Das Adressver- zeichnis (ZAV) stellt die Informationsgrundlage für mehrere postalische Anwendungen dar, und wird regelmäßig aktuali- siert, z. B. monatlich. Änderungen werden typischerweise an- hand von Anträgen der Benutzer der vom ZAV abhängigen posta- lischen Anwendungen, z. B. Post-Zusteller, durchgeführt. Die ZAV-Daten sind häufig hierarchisch gegliedert : Zustellbezir- ke, Zustellabschnitte (Gruppen von Zustellpunkten) und Zu- stellpunkte.

Die Einführung von neuen Dienstleistungen und insbesondere von neuen Stufen der Automatisierung, z. B. Verteilreihenfol- gesortierung, führt zu neuen Anforderungen an ein ZAV-System.

Zusätzliche anwendungsspezifischen Daten müssen gespeichert werden. Um Änderungen am ZAV-System zu vermeiden, werden neue Anwendungssysteme installiert, auf denen die anwendungsspezi- fischen Daten gespeichert und verarbeitet werden können. In der Regel speichert ein solches Anwendungssystem intern eine Kopie des ZAV, das über eine bestehende dateiorientierte Schnittstelle übertragen wird. Änderungen an dem zentralen ZAV-Datenbestand erfordern die Replikation des neuen Datenbe- stands in den Anwendungssystemen.

Ein solches Anwendungssystem, der Verteilreihenfolgemanager (VFM), ist notwendig, um eine Verteilreihenfolgesortierung durchzuführen. Bei dieser Automatisierungsstufe werden die Sendungen maschinell in die Reihenfolge sortiert, in der die Sendungen vom Zusteller zugestellt werden. Damit wird die zeitaufwendige Handsortierung der Sendungen vor der Zustel- lung erspart. Mit dem VFM werden Sortierpläne aufbereitet, in denen die Reihenfolge der Briefsendungen vorgegeben wird, und die von den Verteilreihenfolgesortieranlagen geladen werden.

Der VFM muss auch Quality of Service (QoS) Merkmale wie, zum Beispiel,"nur Dienstags austragen"mit den Adressdaten spei- chern. Diese QoS Merkmale werden vom VFM ausgewertet, um die Sortierpläne tagtäglich aktuell zu halten.

Ein Problem bei der Verarbeitung der ZAV-Daten im VFM sind fehlerhafte oder nicht vollständige Datensätze. Entweder be- inhaltet das ZAV gar keine oder nur ungenaue Sequenzangaben, um die Verteilreihenfolge vorzugeben. Die von den Zustellern benötigte Zustellreihenfolge kann sich auch aus anderen Grün- den, z. B. Krankheitsvertretung, täglich ändern. Diese Ände- rungen müssen unmittelbar durchführbar sein, um die Effizienz der Verteilreihenfolgesortierung nicht zu beeinträchtigen.

Aus diesem Grund und um die QoS Informationen vor Ort pfleg- bar zu machen, werden die VFM-Systeme bevorzugt auf gesonder- ten Rechnern vor Ort bei den Sortieranlagen installiert.

Jeder VFM ist daher in der Regel für ein getrenntes postali- sches Gebiet zuständig und sein Datenbestand muss nicht mit dem der anderen VFMs abgeglichen werden. Neue Versionen des ZAV müssen jedoch nach dieser Architektur auf mehreren VFMs repliziert und dort mit lokalen Änderungen in der vorherigen Version integriert werden. Diese Replikation wäre einfach zu realisieren, falls das ZAV-System ein Log-File der Änderungen zur Verfügung stellen würde (wie üblich bei Merge-Replikation zwischen Datenbanksystemen (Microsoft SQL Server 2000 Refe- rence Library (ISBN 0-7356-1280-3))) oder falls das VFM- System keine Änderungen an den Daten zu lassen würde (read- only snapshots (Buretta, Marie"Data Replication : Tools and Techniques for Managing Distributed Information", (ISBN 0- 471-15754-6))). Wäre der VFM mit einem Industrie-Standard DBMS (Database Management System) und Replikaktionsdienst implementiert, könnte man die fehlende Änderungshistorie (Log-File) kompensieren. Der VFM sollte aber von mehreren Endgeräten aus bedienbar sein, was zusammen mit der Anzahl von verteilten VFM-Rechnern beträchtliche Lizenzkosten für ein DBMS bedeuten kann. Die ZAV-Daten sollen auch als Master- Version dienen, die Verteilreihenfolgedaten als Replika (asymmetrische Replikation [Buretta, Marie"Data Replicati- on : Tools and Techniques for Managing Distributed Informati- on", (ISBN 0-471-15754-6)]). Eine Realisierung ohne DBMS oder Log-Files der ZAV-Änderungen würde daher die automatische Konfliktlösung schwierig machen.

Der Erfindung liegt die Aufgabe zugrunde, ein einfaches Ver- fahren zum automatischen Erzeugen von aktuellen Verteilrei- henfolgedaten mit der Replikation von ZAV-Datenbeständen und mit lokalen Änderungen ohne ein Database Management System zu schaffen.

Die Erfindung soll auch die Integration von zentral gepfleg- ten Quality of Service-Merkmalen, z. B. Nachsendeanträge, die einfache Integration von parallel durchgeführten Änderungen sowie die Ergänzung und Korrektur von einem vorhandenen Ad- ressverzeichnis durch inkrementelle Änderungen ermöglichen.

Erfindungsgemäß wird die Aufgabe durch die Merkmale des An- spruches 1 gelöst.

Durch die Schritte : - Lokales Kopieren des aktuellen zentralen Adressver- zeichnisses oder der Teile, die das relevante Gebiet betreffen, - Übertragen von lokal gespeicherten Änderungsbefehlen hinsichtlich relativer Positionswechsel von Zustell- punkten in der Verteilreihenfolge für die vorherige Version des zentralen Adressverzeichnisses oder der re- levanten Teile, wobei die Zustellpunkte anhand von Identifikationsdaten, die mindestens den Sortierkode enthalten, identifiziert werden, auf die lokale Kopie des aktuellen zentralen Adressverzeichnisses oder der relevanten Teile, - Überprüfen, ob die Änderungsbefehle im kopierten aktu- ellen Adressverzeichnis schon realisiert sind oder ob sie noch auszuführen sind, - Abspeichern der noch auszuführenden, gültigen Ände- rungsbefehle in einem Audit-File und Ausführen der Än- derungsbefehle, ist es nicht mehr notwendig, die Änderungen mit Hilfe eines Database Management Systems durchzuführen und zu verwalten.

Wird zu einem späteren Zeitpunkt eine neue Version des zent- ralen Adress-Verzeichnisses freigegeben, wird der neue Daten- bestand einfach als neue Version der Verteilreihenfolgedaten vom VFM importiert. Danach können die im Audit-File der vor- herigen Version gespeicherten Änderungsbefehle automatisch von einem Editor-Programm auf der neuen Version angewandt werden. Hierbei werden die Änderungen auch in das zunächst leere Audit-File der neuen Version geschrieben und so von Version zu Version weitergeleitet.

Verfahrensgemäß ist Kontextinformation aus den Identifikati- onsdaten im Audit-File vorgesehen, um eine semantische Über- prüfung der Gültigkeit der Audit-File Einträge während deren Anwendung zu ermöglichen. Hierdurch werden nur die noch gül- tigen Änderungen von einer Version zur nächsten übertragen.

Eine wichtige Grundlage dieses Verfahrens ist es auch, dass die Audit-Einträge so ausgelegt sind, dass sie nicht nur die einfache Übertragung der Datenänderungen ermöglichen, sondern auch die gleichzeitige Überprüfung der Gültigkeit der Ände- rungsanweisungen erlauben.

Jedes Mal nach der Replikation einer neuen Version der ZAV- Daten entsteht eine neue Version der Verteilreihenfolgedaten auf jedem VFM. Jeder VFM bearbeitet nur die ZAV-Daten für seinen Zuständigkeitsbereich, was eine Verteilung und Paral- lelisierung der Arbeit bedeutet. Ein kompliziertes Zusammen- führen der ZAV-und Verteilreihenfolge-Datenbestände entfällt bei diesem Master/Slave Verfahren. Durch das Anlegen einer neuen Version der Verteilreihenfolgedaten wird automatisch zur Sicherung der alte Datenbestand noch vorhanden sein. Bei der Generierung der Sortierpläne für die Sortieranlagen wird nur eine, die aktuelle, Version der Verteilreihenfolgedaten verwendet.

Durch die Verwendung von mehreren Audit-Files können mehrere Operatoren gleichzeitig Änderungen an der gleichen Version der Verteilreihenfolgedaten vornehmen. Nachdem ein Operator mit der Arbeit fertig ist, wird der Inhalt seines Audit-Files automatisch auf den aktuellen Datenbestand wie oben beschrie- ben, angewandt. Hierdurch werden seine Änderungen erst gül- tig. Sollte es Änderungen geben, die durch inzwischen vollzo- gene Änderungen eines anderen Operators nicht durchführbar sind, kann der Operator darüber informiert werden und darauf- hin die geänderten Verteilreihenfolgedaten erneut bearbeiten.

Die Struktur des Audit-Files erlaubt es, ein Audit-File an- hand von Änderungen an einer Version der Verteilreihenfolge- daten zu erzeugen, und dieses dann auf einer inzwischen geän- derten Version der Verteilreihenfolgedaten anzuwenden.

Vorteilhafte Ausgestaltungen der Erfindung sind in den Unter- ansprüchen dargestellt.

So ist es vorteilhaft, wenn die Identifikationsdaten zusätz- lich Hausnummernerweiterungen enthalten.

Vorteilhaft ist es auch, wenn die Identifikationsdaten zu- sätzlich kennzeichnende Bemerkungen enthalten, z. B."keine Zustellung am Dienstag"oder"ab einem bestimmten Datum Zu- stellen an neue Adresse".

Zur Aufnahme dieser Weiterleitungs-oder Verteilhinweise in das kopierte Adressverzeichnis ist es vorteilhaft, zuerst zu überprüfen, ob der Zustellpunkt für den jeweiligen Weiterlei- tungs-und/oder Verteilhinweis im kopierten aktuellen Adress- verzeichnis für die Verteilreihenfolgedaten existiert. Wenn ja, erfolgt das Einfügen der neuen Weiterleitungs-und/oder Verteilhinweise in das kopierte Adressverzeichnis, neue Hin- weise ersetzen hierbei gleichartige alte Hinweise, und die vollständigen Änderungsdaten der Weiterleitungs-und/oder Verteilhinweise werden in den Audit-File übernommen.

Zentral eingepflegte QoS Merkmale werden also in eine Kopie der aktuellen Verteilreihenfolgedaten des Adressverzeichnis- ses integriert, indem die existierenden Merkmale um die neuen Merkmale ergänzt oder entsprechend korrigiert werden. Anders als bei den ZAV-Daten wird auch ein völlig neuer Eintrag in den zu der neuen Version gehörigen Audit-File für jede Merk- malsänderung geschrieben. Hierdurch werden lokal und zentral eingepflegte Merkmale in Zukunft auf neue Datenbestände über- tragen. Dieses Verfahren funktioniert nur, weil die Audit- Einträge für Merkmale als einzige nicht als Änderungsanwei- sung, sondern als geänderter Datensatz in dem Audit-File ge- speichert werden. Dadurch.. können die Merkmalsdaten vollstän- dig und ohne großen Aufwand von einer Version der Verteilrei- henfolgedaten zur nächsten übertragen werden. Dieses kombi- nierte Loggen von Änderungsanweisungen und Datensätzen zeich- net die Methode dieser Erfindung aus.

In einer weiteren vorteilhaften Ausgestaltung werden zur Ak- tualisierung des zentralen Adressverzeichnisses oder von Tei- len des zentralen Adressverzeichnisses nur inkrementelle Än- derungen per Datenübertragung übermittelt. Diese inkrementel- len Änderungen werden mit dem kopierten, bisher aktuellen Ad- ressverzeichnis oder Adressverzeichnisteil zusammengeführt, indem anhand der Identifikationsdaten zu jedem Zustellzeit- punkt in dem bisher aktuellen Adressverzeichnis oder Adress- verzeichnisteil überprüft wird, ob der jeweilige Zustellpunkt der inkrementellen Änderung schon vorhanden ist. Ist dies nicht der Fall, wird er in der mit übermittelten Position der Verteilreihenfolge in das kopierte Adressverzeichnis oder Ad- ressverzeichnisteil aufgenommen. Ist der Zustellpunkt in der inkrementellen Änderung im Adressverzeichnis oder Adressver- zeichnisteil schon vorhanden, so wird er an die geänderte Po- sition im Adressverzeichnis verschoben. Der Verschiebeprozess erfolgt vorteilhafterweise, indem der Zustellpunkt an der bisherigen Position des Adressverzeichnisses gelöscht und an der geänderten Position neu eingetragen wird.

Hierdurch wird die Vielzahl an Änderungen, die mit den neuen ZAV-Daten mitkamen, nicht mit den lokalen Änderungen ver- mischt. D. h. lokale Änderungen ändern den Datenbestand, wer- den aber auch getrennt im neuen Audit-File geloggt. Inzwi- schen überflüssig gewordene lokale Korrekturen können einfach weg gelassen werden. Dieses Verfahren funktioniert nur wegen der in der Praxis beschränkten Art und des Umfanges der Ände- rungen in den ZAV-Daten und macht es somit nur für die Anwen- dung im postalischem Bereich sinnvoll, d. h. Adressen werden eher hinzugefügt oder verschoben und relativ selten gelöscht.

Anschließend wird die Erfindung in einem Ausführungsbeispiel anhand der Zeichnungen näher erläutert.

Dabei zeigen FIG 1 ein Strukturdiagramm von Verteilreihenfolge- sortiersystemen ; FIG 2 ein Flussdiagramm zur Korrektur/Ergänzung der Verteilreihenfolgedaten durch einen Operator ; FIG 3 ein Flussdiagramm der Importierung von neuen Verteilreihenfolgedaten ; FIG 4 ein Flussdiagramm der Importierung von inkre- mentell geänderten Verteilreihenfolgedaten.

FIG 5 ein Flussdiagramm der Importierung einer Merkmals-Datei ; FIG 6 ein Flussdiagramm der Importierung einer Au- dit-Datei.

Einem Verteilreihenfolgemanager (VFM) werden mindestens die für sein postalisches Gebiet relevanten zentralen Adressver- zeichnis (ZAV) -Daten in Dateien per Datenübertragung zuge- stellt. FIG 1 zeigt die zur Bearbeitung der Adressdaten und für die Verteilreihenfolgesortierung von einer Post- Organisation benötigten Systeme. Der VFM 100 bekommt die ZAV- Daten vom System 101, auf dem die ZAV-Daten gepflegt werden, und bereitet daraus die Sortierpläne mittels eines Generator- Programms 106 für die Verteilreihenfolgesortieranlagen 104 vor. Gegebenenfalls gibt es ein zweites Anwendungssystem 102, das auch auf die ZAV-Daten zugreift, auf dem Nachsendeanträge verwaltet werden. Andere Anwendungssysteme, die weitere für die Verteilreihenfolgesortierung nützliche Informationen ver- walten, sind auch möglich. Die Nachsendedaten werden auch dem VFM per Datenübertragung, z. B. ftp, zugestellt.

Die vollständigen ZAV-Daten werden vom VFM komplett übernom- men und lokal als Verteilreihenfolgedaten auf einer Festplat- te 103 gespeichert. Jedes Mal, wenn es eine neue Version der ZAV-Daten gibt, wird eine neue Version der kopierten lokalen Verteilreihenfolgedaten erzeugt. Auf diese Art und Weise wer- den die ZAV-Daten im Master/Slave Modus repliziert.

Quality of Service (QoS) Merkmale sind nicht in den ZAV-Daten enthalten, diese werden lokal auf dem VFM vom Operator ge- pflegt und mit der passenden Version der Verteilreihenfolge- daten abgespeichert. Der Operator kann auch die Verteilrei- henfolgedaten mit einem Editorprogramm 105 korrigieren oder ergänzen, um Änderungen im Straßenbild, z. B. neue Häuser, die noch nicht im ZAV-System bekannt sind, in der Verteilreihen- folgesortierung zu berücksichtigen.

FIG 2 zeigt als Flussdiagramm die Pflege der Verteilreihen- folgedaten durch einen Operator mit einem Editor 105. Zuerst wird die zu bearbeitende Version der Verteilreihenfolgedaten von der Festplatte gelesen 201. Danach reagiert der Editor auf Benutzereingaben, die Änderungen an den Daten vornehmen 202. Änderungen an den Adressdaten können auf verschiedenen Ebenen der Hierarchie durchgeführt werden, um einen/mehrere Zustellbezirke, einen/mehrere Zustellabschnitte oder einzel- ne/mehrere Zustellpunkte zu verschieben 203, bzw. zu löschen 204 oder hinzuzufügen 205. Diese Operationen ändern die Daten und werden gleichzeitig jeweils als Audit-Einträge der Sorten MOVE 207, DELETE 208 und ADD 209 geloggt. Sollte der Operator QoS Merkmale für einen Zustellpunkt/Abschnitt/Bezirk hinzufü- gen, löschen oder verschieben 206, werden alle Änderungen mit einem SET Merkmale Eintrag im Audit-File geloggt 210. Sollte der Operator nach dem Editieren die geänderten Daten spei- chern wollen 211, werden die Verteilreihenfolgedaten abge- speichert und die neuen Audit Einträge am Ende des Audit- Files hinzugefügt 212.

Die Auslegung der Audit Einträge ist eine wesentliche Grund- lage dieses Verfahrens und wird in der Tabelle 1 dokumen- tiert. Operation Parameter 1 Parameter 2 Parameter 3 MOVE Erster Letzter Vor/Nach Zustellpunkt Zustellpunkt Zustellpunkt Zustellpunkt ADD Neuer Vor/Nach Zustellpunkt Zustellpunkt Zustellpunkt DELETE Zustellpunkt Zustellpunkt MOVE Abschnitt Erster Letzter Vor/Nach Abschnitt Abschnitt Abschnitt ADD Abschnitt Neuer Vor/Nach Abschnitt Abschnitt DELETE Abschnitt Abschnitt MOVE Bezirk Erster Bezirk Letzter Bezirk Vor/Nach Bezirk ADD Bezirk Neuer Bezirk Vor/Nach Bezirk DELETE Bezirk Bezirk SET Merkmale Zustellpunkt Alle Merkmale Tabelle 1 Bei ADD und DELETE Einträgen wird der betroffene Zustell- punkt, Abschnitt oder Bezirk als ein Parameter im Eintrag an- gegeben.

Alle Details zu Zustellpunkten, Abschnitten oder Bezirken werden immer mitgespeichert, d. h. für Zustellpunkte : Bezirk-ID, Abschnitt-ID, Sortcode, Postleitzahl, Stra- ßenname, Hausnummer, Hausnummererweiterung, Bemerkung ; für Zustellabschnitte : Bezirk-ID, Abschnitt-ID, Abschnittsname ; für Zustellbezirke : Bezirk-ID, Bezirksname.

Bei ADD Einträgen wird auch die Stelle in der Verteilreihen- folge, an der der Zustellpunkt/Abschnitt/Bezirk eingefügt werden soll, gekennzeichnet. Anstatt einer Positionsnummer wird die entsprechende Stelle anhand der vorher/nachher kom- menden Zustellpunkte/Abschnitte/Bezirke notiert. Ein MOVE Eintrag bekommt auch als Parameter vorher/nachher kommende Zustellpunkte/Abschnitte/Bezirke. Weil ein MOVE Eintrag mehr als einen Zustellpunkt/Abschnitt/Bezirk gleichzeitig als ei- nen zusammenhängenden Bereich verschieben kann, wird der Be- reich mit dem ersten und letzen Zustellpunkt/Abschnitt/Bezirk angegeben.

Die Verwendung von einem Vorher-oder Nachher-Eintrag an Stelle einer Positionsnummer macht die Zielposition einer Verschiebung nicht von der absoluten, sondern von der relati- ven Reihenfolge der Zustellpunkte abhängig.

Abschnittsänderungen werden relativ zu einem Abschnitt und Bezirksänderungen relativ zu einem Bezirk geloggt. Diese re- lativen Angaben zusammen mit der Tatsache, dass die reale Geographie der Zustellpunkte statisch bleibt, bedeutet eine sehr effektive Übertragung der Audit-Einträge.

QoS Merkmale werden mit. dem Editor eingegeben und als SET Au- dit-Einträge gespeichert. Ein wesentlicher Anteil eines Au- dit-Files besteht aus SET Merkmale Anweisungen. Weil jeder Zustellpunkt/Abschnitt/Bezirk in der Regel nur wenige QoS Merkmale bekommt, wird die Auswertung des Audit-Files dadurch einfach gehalten, dass immer alle für einen Zustell- punkt/Abschnitt/Bezirk vorhandenen Merkmale in jedem SET Ein- trag angegeben werden. Dadurch muss nur der letzte SET Ein- trag zu jedem Zustellpunkt/Abschnitt/Bezirk ausgewertet wer- den. Beim Laden der Verteilreihenfolgedaten 201 können über- flüssige SET Einträge einfach ignoriert werden, was nach dem Wiederabspeichern das Audit-File verdichtet.

Das Einlesen einer neuen vollständigen Version der ZAV-Daten und das Anlegen einer neuen Version der Verteilreihenfolgeda- ten fängt, wie in FIG 3 gezeigt, mit der Übertragung der neu- en ZAV-Daten an 400. Eine syntaktische Überprüfung der ZAV- Daten, um die Korrektheit und Vollständigkeit der Datensätze zu sichern, wird zuerst gemacht 401. Für die Übertragung von inzwischen durchgeführten lokalen Änderungen auf die neue Version der Daten ist es erforderlich, dass die Datensätze von einer Version zur nächsten identifiziert werden können.

Bezirke und Abschnitte sind in den ZAV-Daten nur als eine Menge von Zustellpunkt-Datensätze definiert, und werden nach Bedarf in den Verteilreihenfolgedaten erzeugt. Um Zustell- punkt-Datensätze zu identifizieren, werden Identifikationsda- ten aus dem Sortierkode + Hausnummererweiterung + Bemerkung eines Zustellpunktes gebildet. Der Sortierkode stellt das Ziel der Sortierung dar und wird häufig als Barcode auf Briefsendungen bei der automatisierten Briefverteilung ge- druckt. Der Sortierkode muss nicht aus Postleitzahl, Straßen- bezeichnung und Hausnummer bestehen. Das Verfahren wird aber effektiver, wenn eindeutige abstrakte Sortierkodes verwendet werden. Da in der Regel nicht alle Zustellpunkte einen ein- deutigen Sortierkode bekommen, müssen die Hausnummernerweite- rung (oft alphabetisch) und die Bemerkung (z. B."Metzgerei"), falls vorhanden, berücksichtigt werden. Bezirke und Abschnit- te haben in der Regel eine Kennung, die für die Identifikati- on passend ist. Es muss auch sichergestellt werden 402, ob die erwähnten Kennungen und Identifikationsdaten eindeutig sind. Alle eindeutigen Datensätze werden in der neuen Ver- teilreihenfolgedaten-Version gespeichert, zusammen mit einem leeren Audit-File 402.

Danach können die Einträge eines existierenden Audit-File, z. B. von der vorher aktuellen Version der Daten, auf die neu- en Daten angewandt werden 403, um alle lokalen Änderungen zu übertragen. Dabei muss zuerst jeder Eintrag auf seine Gültig- keit überprüft werden 404. Der Eintrag ist nicht mehr gültig, zum Beispiel, falls der zu verschiebende Zustellpunkt schon an der richtigen Stelle ist. Alle gültigen Einträge werden vom Editorprogramm angewandt 405. Bei der Bearbeitung der Au- dit-Einträge der bisher aktuellen Version werden Audit- Einträge für die neue Version der Verteilreihenfolgedaten er- zeugt. Diese Audit-Einträge der neuen Version werden zwischen gespeichert 406. Alle nicht mehr gültigen Audit-Einträge wer- den in ein Log-File gespeichert 407 und können vom Operator nach Bedarf eingesehen werden. Nachdem alle Audit-Einträge verarbeitet wurden 408, kann die neue Version der Verteilrei- henfolgedaten mit einem in der Regel kleineren Audit-File ab- gespeichert werden 409.

Werden die aktualisierten Versionen der ZAV-Daten nur als in- krementelle Datenbestände zur Verfügung gestellt, wird jeder Datenbestand mit der bisher aktuellen Version der Verteilrei- henfolgedaten zu einer neuen Vollversion der Verteilreihen- folgedaten kombiniert. Wie in FIG 4 abgebildet, wird zunächst die aktuelle Version der Verteilreihenfolgedaten von der Festplatte gelesen 500. Dabei wird typischerweise eine Hash- Tabelle nach der üblichen Programmiertechnik im Speicher auf- gebaut 501, um das schnelle Finden der Zustellpunkte nachher ermöglicht. Als Schlüssel in der Hash-Tabelle dienen die be- reits erwähnten Identifikationsdaten, die aus dem Sortierkode + Hausnummererweiterung + Bemerkung eines Zustellpunktes ge- bildet werden. Manche ZAV-Datenbestände kennen aber keine Sortierkodes, in diesem Fall, wird während der Importierens der korrekte Sortierkode generiert.

Alle neuen Zustellpunkte werden nacheinander bearbeitet 502, als erstes wird überprüft ob der Zustellpunkt schon existiert 503. Falls der neue Zustellpunkt schon existiert, wird dessen relative Position mit der bisherigen relativen Position ver- glichen 504. Sollten die Positionen gleich sein, ist keine weitere Aktion nötig. Sind die Positionen unterschiedlich, wird der Zustellpunkt in eine Liste von Zustellpunkten, die zu löschen sind, eingetragen 505. Diese zu verschiebenden Zu- stellpunkte werden auch wie neue Zustellpunkte in eine Liste der neuen Zustellpunkte eingetragen 506. Nach dem alle Zu- stellpunkte bearbeitet wurden 507, werden alle zu löschenden Zustellpunkte aus dem Datenbestand entfernt 508. Danach wer- den alle neuen oder verschobenen Zustellpunkte hinzugefügt 509. Zuletzt kann die neue Version der Verteilreihenfolgeda- ten abgespeichert werden 510. Dabei werden leere Abschnitte sowie leere Bezirke weg gelassen.

Die QoS Merkmale von einem anderen zentralen Anwendungssystem werden als Datei bereitgestellt. Eine Merkmalsdatei kann mit der aktuellen Version der Verteilreihenfolgedaten zu einer neuen Version kombiniert werden. Wie in FIG 5 abgebildet, wird hierfür zunächst die aktuelle Version der Verteilreihen- folgedaten von der Festplatte gelesen 600. Dabei wird eine Hash-Tabelle nach der üblichen Programmiertechnik wie oben schon beschrieben im Speicher aufgebaut 601. Alle Merkmale in der Datei werden nacheinander bearbeitet 602, wobei zuerst überprüft wird, ob der betroffene Zustellpunkt überhaupt existiert 603. Falls der Zustellpunkt existiert, werden die bisherigen Merkmale mit den neuen Merkmalen kombiniert, wobei die neuen Merkmale Vorrang haben 605. Der ergänzte Datensatz wird in den Verteilreihenfolgedaten und als ein vollständiger SET-Eintrag in das Audit-File gespeichert 606. Sollte der be- troffene Zustellpunkt nicht vorhanden sein, wird ein Eintrag in einer Fehler-Datei geloggt 604. Nachdem alle Zustellpunkte bearbeitet wurden 607, wird die neue Version der Verteilrei- henfolgedaten abgespeichert.

Einzelne Audit-Files können mit der aktuellen Version der Verteilreihenfolgedaten zu einer neuen Vollversion kombiniert werden. Diese Funktionalität ermöglicht die parallele Bear- beitung der Verteilreihenfolgedaten durch mehrere Operatoren.

Wie in FIG 6 abgebildet, wird hierfür zunächst die aktuelle Version der Verteilreihenfolgedaten von der Festplatte gele- sen 700. Dabei wird eine Hash-Tabelle nach der üblichen Pro- grammiertechnik im Speicher wie oben schon beschrieben aufge- baut 701. Alle Audit-Einträge aus dem Audit-File werden bear- beitet 702, und zuerst wird überprüft, ob jeder Eintrag noch gültig ist 703. Kann ein Eintrag nicht angewandt werden, weil zum Beispiel der Zustellpunkt fehlt, wird der Eintrag im Au- dit-Log-File gespeichert 706. Kann der Eintrag doch angewen- det werden, wird die Änderung durchgeführt 704, und ein neuer Eintrag in das neue Audit-File gespeichert 705. Nachdem alle Audit-Einträge bearbeitet wurden, wird die neue Version der Verteilreihenfolgedaten abgespeichert 708.