DE69832593T2

DE69832593T2 - Netzwerk zur datencodierung

Info

Publication number: DE69832593T2
Application number: DE69832593T
Authority: DE
Inventors: William Sebastian
Original assignee: Intelligent Compression Technologies Inc
Current assignee: Via Sat Inc Carlsbad Calif Us
Priority date: 1997-03-07
Filing date: 1998-03-06
Publication date: 2006-08-17
Anticipated expiration: 2018-03-07
Also published as: WO1998039699A3; DE69832593D1; CA2283591C; EP0965171B1; ATE311692T1; JP4091990B2; CA2283591A1; US6253264B1; JP2001526853A; WO1998039699A2; EP0965171A2

Description

HINTERGRUND DER ERFINDUNG
Hochleistungsdatenkompressionssysteme nutzen Modelle der Daten, um deren Fähigkeit, Werte vorherzusagen, zu steigern, was wiederum zu einer größeren Kompression führt. Die besten Modelle können erzielt werden, indem man ein Kompressionssystem zum Unterstützen eines spezifischen Datenformates aufbaut. Statt zu versuchen, ein grobes Modell aus den Daten innerhalb einer spezifischen Datei abzuleiten, kann ein formatspezifisches Kompressionssystem ein genaues vorbestimmtes Modell erzeugen. Das Modell kann nicht nur den Vorteil der Dateiformatstruktur, sondern auch den aus Probendatenbanken gewonnener statistischer Daten nutzen.
Frühere Bemühungen bei der formatspezifischen Kompression waren auf Lösungen für einige wenige individuelle Formate statt auf die Entwicklung eines verallgemeinerten Verfahrens konzentriert, das auf viele Formate angewendet werden kann. Die Modelle, welche geschaffen wurden, beinhalten typischerweise eine kleine Anzahl von Komponenten. Dieses funktioniert ausreichend, wenn die meisten der Daten in wenigen Komponenten enthalten sind, wie z.B. in einer Bilddatei mit hauptsächlich roten, blauen und grünen Pixelwerten. Aber viele Formate werden am besten unter Verwendung einer großen Zahl von Komponenten modelliert, und die früheren Systeme sind nicht dafür ausgelegt, solche Modelle aufzubauen oder zu kodieren.
Die nachstehenden Dokumente stellen den Stand der Technik für die vorliegende Erfindung dar:
EP 0 729 237 A (IBM) 28. August 1996
US 5 467 087 A (CHU KE-CHIAMG) 14. November 1995
"Competetive Paralell Processing for Compression of Data" NTIS Tech Notes, 1. Mai 1990, page 379 XP 000137349
"VLSI Unviversal Noiseless Coder" NTIS Technotes, 1. März 1990, page 234 IX 000127250.
Die vorliegende Erfindung ist wie in den Ansprüchen beansprucht.
Ein bevorzugtes Codierungssystem gemäß der Erfindung löst diese b beiden Probleme in dem Stand der Technik: Es stellt eine verallgemeinerte Lösung bereit, welche zur Handhabung eines breiten Bereichs von Formaten angepasst werden kann, und sie handhabt effektiv Modelle, die eine große Zahl von Komponenten verwenden. Das Sys tem beinhaltet neue Ansätze auf vielen Ebenen: Von der höchsten (Schnittstellen) Ebene bis zu der niedrigsten (Kerncodierungsalgorithmen) Ebene. Das Codierungsnetzwerk enthält ein Kompressionsnetzwerk zum Codieren von Daten und ein Dekompressionsnetzwerk zum Decodieren von Daten.
Auf der höchsten Ebene verwendet ein bevorzugtes Kompressionssystem gemäß der Erfindung eine als Basis-Filter-Ressourcen-(BFR)-System bezeichnete Architektur. Dieser Lösungsansatz integriert die Vorteile einer formatspezifischen Kompression in ein Allzweck-Kompressionswerkzeug, das einen breiten Bereich von Datenformaten bedient. Das System enthält Filter, welche jeweils ein spezifisches Datenformat unterstützen, wie z.B. Excel XLS-Arbeitsblätter oder Word DOC-Dateien. Die Basis beinhaltet die Systemsteuermodule und eine von allen Filtern verwendete Bibliothek. Die Ressourcen beinhalten Routinen, welche von mehr als nur einem Filter verwendet werden, aber kein Teil der Basis sind. Wenn ein Filter installiert ist, welches mit dem Format der zu codierenden Daten übereinstimmt, können die Vorteile einer formatspezifischen Kompression für diese Daten realisiert werden. Andernfalls wird ein "allgemeines" Filter verwendet, welches eine Leistung ähnlich der anderer nicht spezifischer Datenkompressionssysteme (wie z.B. PKZip, Stacker, usw.) erzielt.
Auf der nächsten Ebene beinhaltet das System bevorzugt ein Verfahren zur Untergliederung von Quellendaten in individuelle Komponenten. Der als Strukturumgliederung bzw. "Struktur Flipping" bezeichnete Basisansatz stellt einen Schlüssel zur Umwandlung von Formatinformation in Kommunikationsmodelle bereit. Struktur Flipping reorganisiert die Information in einer Datei so, dass identische Komponenten die normalerweise getrennt sind, zusammen gruppiert werden.
Auf dieser Grundlage befindet sich eine Anzahl von Werkzeugen, wie z.B.:

– eine Sprache zur Vereinfachung der Erzeugung von Parsing- bzw. Untergliederungsroutinen;
– Werkzeuge zum Untergliedern der Quellendaten unter Anwendung dieses Verfahrens in getrennte Komponenten; und
– Werkzeuge zum Erzeugen von Modellen durch automatisierte Analyse von Probendatenbanken.

Diese Werkzeuge können für die Filter für einen breiten Bereich von Datei- und Datentypen zutreffen.
Das Kompressionssystem enthält bevorzugt als anwendungsspezifische Array-Transformationen bezeichnete Werkzeuge für spezifische Filter und für bestimmte Arten von Filtern. Diese Techniken handhaben einen spezifischen Dateityp oder bestimmte Datenkonstruktionen, die von mehreren Dateitypen verwendet werden, wie z.B. die Codierung von zweidimensionalen Daten-Arrays, wie man sie in vielen Datenbankformaten findet.
Auf der niedrigen Ebene des Systems befindet sich eine Anzahl von Mechanismen zum Codieren von Daten-Arrays, welche umfassen:

– neue Codierungsalgorithmen auf niedriger Ebene;
– Verfahren zum Integrieren einer großen Zahl von Transformations- und Codierungsalgorithmen;
– Verfahren zur Beseitigung des Zusatzaufwandes bzw. Overheads, so dass kleine Datenblöcke effizient codiert werden können; und
– ein neues Verfahren zum Integrieren sowohl statischer Modelle (ermittelt aus einer statischen Analyse von Probendatenbanken) als auch dynamischer Modelle (angepasst an die Daten innerhalb einer speziellen Anordnung) in die Codierung jeder Komponente.

Ein bevorzugtes Verfahren zum Codieren von Quellendaten umfasst das Parsing bzw. Untergliedern der Quellendaten in eine Vielzahl von Blöcken. Die untergliederten Blöcke haben typischerweise ein anderes Format als das Quellendatenformat. Insbesondere werden ähnliche Daten aus den Quellendaten gesammelt und in entsprechende Blöcke gruppiert.
Für jeden Block wird ein Kompressionsalgorithmus aus einer Vielzahl von Kandidatenkompressionsalgorithmen ausgewählt und auf den Block angewendet. Die Kompressionsalgorithmen können auf der Basis der Menge von Daten in dem entsprechenden Block bestimmt werden. Ferner können die Kompressionsalgorithmen an den entsprechenden Block angepasst werden, einschließlich der Verwendung einer anwendungs spezifischen Transformation. Die Auswahl eines Algorithmus kann auch auf einem Kompressionsmodell basieren, welches aus dem Format der Quellendaten abgeleitet wird. Die komprimierten Daten aus der Vielzahl von Blöcken werden dann in codierte Daten kombiniert.
Das Codierungsnetzwerk kann auch ein Dekomprimierungsnetzwerk enthalten, um die codierten Daten in die Quellendaten zurückzuwandeln. Zuerst werden die Daten decodiert und dann die Untergliederung rückgängig gemacht. In einem verlustlosen System sind die sich ergebenden Daten identisch mit den Quellendaten.
Ausführungsformen der Erfindung nehmen bevorzugt die Form maschinenausführbarer Instruktionen an, die in einem maschinenlesbaren Format auf einer CD-ROM, Floppy Disk, oder Festplatte oder einem anderen maschinenlesbaren Verteilungsmedium eingebettet sind. Diese Instruktionen werden durch eine oder mehrere Verarbeitungseinheiten zum Implementieren der Kompression und Dekompressionsnetzwerke ausgeführt.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorgenannten und weiteren Aufgaben, Merkmale und Vorteile der Erfindung werden aus der nachstehenden eingehenderen Beschreibung bevorzugter Ausführungsformen der Erfindung gemäß Darstellung in den beigefügten Zeichnungen, in welchen gleiche Bezugszeichen dieselben Teile durchgängig durch die unterschiedlichen Ansichten bezeichnen, ersichtlich. Die Zeichnungen sind nicht notwendigerweise maßstäblich, sondern da stattdessen die Betonung auf der Darstellung der Prinzipien der Erfindung liegt.
1 ist eine Blockdarstellung eines typischen Datenkompressionssystems auf hoher Ebene.
2 ist eine Blockdarstellung eines bevorzugten Codierers unter Verwendung des erfindungsgemäßen BFR-Systems.
3 ist ein Flussdiagramm eines Array-Codierers.
4 ist eine Blockdarstellung des String-Codierers 40 von 3.
5 ist eine Blockdarstellung eines Gleitkommawert-Codierers von 3.
6 ist ein Flussdiagramm eines bevorzugten automatisierten Analysesystems.
7 ist eine Flussdiagrammübersicht über den Integer-Codierer der hohen Ebene.
8 ist eine Flussdiagrammübersicht über den Integer-Codierer der mittleren Ebene.
DETAILLIERTE BESCHREIBUNGEN BEVORZUGTER AUSFÜHRUNGSFORMEN DER ERFINDUNG
1 ist eine Blockdarstellung eines typischen Datenkompressionssystems auf hoher Ebene. Die Hauptkomponenten des Systems sind eine sendende Anwendung 1, ein Codierer 3, ein Decodierer 5 und einen empfangende Anwendung 7.
Die sendende Anwendung 1 liefert Quellendaten 2 zur Codierung durch den Codierer 3. Die sendende Anwendung kann ein Dateiarchiv, ein Kommunikationssystem oder irgendeine andere Anwendung mit einem Bedarf zur Darstellung von Daten unter Verwendung von weniger Bytes als in dem ursprünglichen Format sein.
Der Codierer 3 empfängt die Quellendaten 2 und verwendet Datenkompressionsalgorithmen, um die Daten unter Verwendung von weniger Bytes darzustellen. Die typische Implementation des Codierers 3 ist eine auf einem Allzweckcomputer ablaufende Software, obwohl die zu beschreibenden Algorithmen auch in einer spezialisierten Hardware implementiert werden können.
Die Ausgabe des Codierers sind codierte Daten 4, welche in einem Speicher gespeichert werden (wobei in diesem Falle die Codierung die Speicherung von mehr Quellendaten innerhalb derselben Hardware erlaubt), oder an den Decoder 5 übertragen werden können (wobei in diesem Falle die Codierung eine schnellere Übertragung der Quellendaten erlaubt, wenn die Übertragungskanalbandbreite eingeschränkt ist).
Der Decoder 5 holt oder empfängt die codierten Daten 4 und kehrt die zum Codieren der Daten verwendeten Algorithmen um, um so die Quellendaten als decodierte Daten 6 zurück zu gewinnen. In einem verlustlosen System sind die decodierten Daten 6 mit den Quellendaten identisch. Abhängig von der Anwendung kann jedoch ein gewisser Datenverlust hinnehmbar sein. Wie der Codierer 3 ist der Decodierer 5 typischerweise als eine Software verkörpert, welche auf einem Allzweckcomputer läuft, kann aber auch in spezieller Hardware implementiert werden.
Die empfangende Anwendung 7 empfängt die decodierten Daten 6 zur Verarbeitung. Eine bevorzugte Kompressionsmaschine enthält Filter-basierende Codierer und Decodierer, welche von einer großen Zahl von sendenden Anwendungen 1 und empfangenden Anwendungen 7 verwendet werden können. Obwohl die Anwendungen 1, 7, die die codierten Daten speichern/holen oder senden/empfangen nicht Teil des Kompressionssystems sind, können sie Codierungs- und Decodierungsoperationen abhängig von Systembedingungen wie z.B. verfügbarer Übertragungskanalbandbreite anpassen.
Die nachstehenden Beschreibungen werden hauptsächlich den Codierer abdecken. Der Decodierer kehrt lediglich die Aktionen des Codierers um, so dass eine Beschreibung des Codierers ausreicht, um das gesamte Codierungs/Decodierungs-System zu beschreiben. Der Begriff "Datei" wird dazu verwendet, einen Block von Quellendaten zu beschreiben, welcher mit der üblichen Nutzung übereinstimmt, wobei sich jedoch verstehen dürfte, dass er auch auf viele andere Arten von Datenblöcken wie z.B. einen Datenaustausch in einem Client-Server-Anwendung anwendbar ist.
CODIERER
12 ist eine Blockdarstellung eines bevorzugten Codierers unter Verwendung eines Basis-Filter-Ressourcen-(BFR)-Netzwerkes gemäß der Erfindung. Der Codierer 3' basiert auf der Verwendung einer Vielzahl von Filtern 10a, ..., 10x, ..., 10z, welche spezifischen Dateiformaten dienen. Beispielsweise kann ein Filter 10a mehrere Versionen des DBF-Datenbankformates unterstützen, während ein anderes Filter 10z mehrere Versionen des DOC-Formats unterstützen kann, das von dem Microsoft Word Softwareprogramm verwendet wird. Die einzelnen Filter stellen entsprechende Auswahlkriterien 12 für ein Filterauswahlsystem 22 bereit.
Das Filterauswahlsystem 22 empfängt die Quellendaten 2 und prüft die Auswahlkriterien 12a, ..., 12x, ..., 12z aller Filter 10a, ..., 10x, ..., 10z, die in dem System eingebaut sind, um zu sehen, ob eines von diesen das Format der Quellendaten unterstützt. Falls nicht, wird ein "allgemeines" Filter verwendet, welches eine Kompressionsleistung ähnlich der anderer allgemeiner Kompressionssysteme, wie z.B. Lempel-ZIV(LZ)-Maschinen bereitstellt. In einer besonders bevorzugten Ausführungsform der Erfindung verwendet das allgemeine Kompressionssystem eine SZIP-Maschine, wie sie von Mr. Schindler in U.S. Application Serial No. 08/970,220, eingereicht am 14. November 1997, beschrieben wird. Die Beschreibungen des Netzwerkes werden hauptsächlich die Situationen abdecken, in welchen ein Filter zur Unterstützung des Datenformates erfolgreich gefunden wird.
Kurz gesagt, untergliedert ein sog. Parsing- bzw. Untergliederungssystem 24 die Quellendaten 2 in eine große Zahl von untergliederten ARRAYS 25, welche jeweils alle einzelnen Fälle oder bzw. sog. Instanzen einer speziellen Komponente in der Quellendatei enthält. Der nachstehend detaillierter beschriebene Begriff "ARRAY" ist mit Großbuchstaben geschrieben, um anzuzeigen, dass sich dieser auf einen für das Netzwerk spezifischen Strukturtyp im Gegensatz zu der normalen Verwendung des Begriffes "Array" bezieht. Der zur Untergliederung der Quellendaten 2 verwendete Algorithmus wird als "Struktur Flipping" bezeichnet, welcher ein wichtiger Aspekt des Netzwerkes ist, der nachstehend detaillierter beschrieben wird.
Das BFR-System verwendet ein (ebenfalls nachstehend im Detail beschriebenes) automatisiertes Analysesystem, um ein Modell für jedes ARRAY 25 aufzubauen, welches verwendet wird, wenn die ARRAYS 25 in einem Array-Codierer 28 codiert werden. In einigen Fällen kann eine bessere Kompression erzielt werden, wenn zuerst anwendungsspezifische Array-Transformationen 26 angewendet werden. Obwohl die durch das automatisierte Analysesystem erzeugten Modelle jedes Komponenten-ARRAY 25 unabhängig verarbeiten, können die anwendungsspezifischen Routinen einen Vorteil von Zwischen-Komponenten-Beziehungen nutzen.
Der Array-Codierer 28 codiert die ARRAYS 25 unter Verwendung eines Anzahlabhängigen Modellierungssystems, welches ein Gemisch statischer Modelle (konstant für alle Datenbanken) und einer dynamischen Einstellung für jedes spezielle ARRAY 25 enthält.
Das Filter 10x besitzt Komponenten zum Unterstützen jedes der vier Abschnitte des Codierers 3'. Die durch die Dateiformatspezifikation bestimmten Auswahlkriterien 12x enthalten Information, die zur Erkennung der durch das Filter 10x bearbeiteten Dateien erforderlich sind, wie z.B. Byte-Werte am Beginn der Datei, oder Dateititel-Anhänge. Ebenfalls durch die Dateiformatspezifikation bestimmte Untergliederungsbefehle 14 enthalten die Information, die erforderlich ist, um die Quellendatei in untergliederte ARRAYS 25 mit allen Instanzen einer speziellen Komponente in der Quellendatei zu untergliedern. Die anwendungsspezifischen Komponentenmodelle werden sowohl durch Bezugnahme auf die Dateiformatspezifikation als auch die Probendatenbanken aufgebaut. Sie können Zwischen-Komponenten-Beziehungen nutzen, um einen Teil der Komponenten-ARRAYS 25 zu transformieren, um sie besser komprimierbar zu machen. Codierungsparameter 18 werden durch ein automatisiertes Analysesystem erzeugt, welches Komponenten-ARRAYS 25 überprüft, die aus einer großen Zahl von Probendatenbanken untergliedert wurden. Die Codierungsparameter 18 liefern die erforderlichen Daten, um das anzahlabhängige Modellierungssystem in dem Array-Codierer 28 zu unterstützen.
FILTERAUSWAHLSYSTEM
Ein bevorzugtes Kompressionssystem verwendet eine erweiterbare Architektur, die es Benutzern ermöglicht, neue oder aktualisierte Formate durch Hinzufügen oder Ersetzen von Filtern 10 zu unterstützen. Gemäß vorstehender Anmerkung kann ein Filter 10 mehr als ein Format unterstützen. Beispielsweise kann ein als "LOTUS 123v4" bezeichnetes Filter alle Dateiformate in Verbindung mit dem LOTUS 123 Programm, wie z.B. das aktuelle WK4 Format oder die früheren WK3 und FM3 Formate unterstützen. Wenn ein Filter später für ein neues LOTUS WK5 Format entwickelt wird, ersetzt ein Benutzer das alte Filter durch eines, das das neue Format unterstützt, und welches auch mit dem früherem Filter in Bezug auf die älteren Formate rückwärtskompatibel wäre.
In der Microsoft Windows Umgebung ist jedes Filter eine getrennte dynamisch verknüpfte Bibliotheksdatei (DLL). Zusätzlich zu Datentabellen enthält ein Filter ausführbaren Code. Wenn ein Filter für eine Datei gefunden ist, wird es dynamisch verknüpft und dann aufgerufen, um die Datei zu codieren. Der codierte Datenstrom enthält einen Kennungs-(ID)-Code, der anzeigt, welches Filter zum Codieren der Daten verwendet wurde, und für welches der Decoder ein entsprechendes Decodierungsfilter haben muss.
Um ein Filterauswahlsystem 22 zu implementieren, führt das Basismodul eine Registrierungsdatenbank der derzeitig installierten Dateien, welche die Daten, die zum Identifizieren von Quellendateien dieses Typs erforderlich sind, sowie den Pfad zu der DLL enthält. Diese Registrierungsdatenbank wird jedes Mal aktualisiert, sobald ein Filter hinzugefügt oder ersetzt wird. Die Kennungsdaten können sowohl eine Liste von Dateititelanhängen als auch ein Verfahren zum Identifizieren von Dateien über Byte-Werte in der Nähe des Anfangs der Datei enthalten. Die Kennungsprozedur verwendet ein Suchbaumverfahren, um die Zeit zu verringern, die zum Prüfen der Liste benötigt wird, wenn viele Filter installiert sind. Aus dieser Registrierungsdatenbank wird das geeignete Filter 10 für den Dateityp aufgerufen.
Um Verbund-Dateiformate wie z.B. OLE 2 von Microsoft zu bearbeiten, kann ein Filter ein weiteres Filter zum Codieren einer Unterdatei oder eines Stroms innerhalb der Verbund-Datei aufrufen. Beispielsweise könnte ein Winword Filter ein Excel Filter aufrufen, um einige Excel-Daten zu codieren, welche innerhalb einer Verbund-Dokumentdatei eingebettet sind.
UNTERGLIEDERUNGSSYSTEM
Wie es vorstehend erwähnt wurde, erzeugt das Untergliederungssystem 24 eine große Zahl untergliederter ARRAYS 25. Jedes untergliederte ARRAY 25 enthält alle Instanzen einer speziellen Komponente in einer Datei. Eine getrennte Komponente wird für jedes Element eines definierten Strukturtyps erzeugt.
Beispiel 1
Beispielsweise werde die nachstehende Beschreibung eines Datensatzes bzw. Records beschrieben, der in einer Dateiformatbeschreibung definiert ist.
Zellenwert:
Das Format verwendet ein spezielles Verfahren zur Codierung von Zahlen in einem als eine RK-Zahl bezeichneten internen Zahlentyp, um so Speicher und Festplattenplatz einzusparen.
Record-Daten:
Das Untergliederungssystem 24 erzeugt untergliederte ARRAYS 25 für jede der vier Komponenten dieses Records. Jedesmal, wenn ein RK-Record gefunden wird, wird jedem Array ein Eintrag hinzugefügt. Die untergliederten ARRAYS 25 sind wesentlich besser komprimierbar als die Rohquellendaten, wie es durch Daten aus fünf Records dargestellt wird:
Die Quellendaten würden einem Byte-Vergleichsalgorithmus (in Hexadezimalform dargestellt) als zufällig erscheinen:
01 00 02 00 55 00 00 e1 f1 3f01 00 03 00 5f 00 00 a3 f1 3f 01 00 04 00 53 00 00 d0 f1 3f
01 00 06 00 5f 00 00 c4 e1 f1 3f 01 00 07 00 5f 00 00 d3 f1 3f
Wenn sie jedoch als vier getrennte ARRAYS 25 (Row, Col, Index und Num) unter Verwendung von für jede Komponente optimierten Algorithmen verarbeitet werden, können die Daten erheblich komprimiert werden. Dieser Lösungsansatz wird hierin als "Struktur Flipping" aufgrund der Art wie die Daten neu angeordnet werden, bezeichnet.
Das zusammengefasste Codieren der Instanzen derselben Komponente in einer Datenbank ist eine übliche Kompressionstechnik, und das Dateiformat wird oft dazu genutzt, um derartige Komponenten zu identifizieren. In der herkömmlichen Technik war jedoch dieser Lösungsweg auf die Isolation einiger weniger Hauptkomponenten einer spezifischen Dateiformats beschränkt, und es wurde nur die Dateiformatbeschreibung als eine Technik verwendet, um diese Hauptkomponenten zu finden. Gemäß bevorzugten Ausführungsformen der Erfindung wird ein Dateiformat tatsächlich in ein Kompressionsmodell umgewandelt, welches dann in ein automatisiertes System zum Analysieren der Daten und zum Optimieren der Codierungsleistung jeder Komponente über tragen wird. Obwohl dieses Kompressionsmodell üblicherweise durch anwendungsspezifische Array-Transformationen 26 verbessert wird, ist es immer noch ein Aspekt des Gesamtsystems.
Der Umfang, in welchem sich bevorzugte Lösungsansätze von herkömmlichen Systemen unterscheiden, wird in den für deren Implementation erstellten neuen Werkzeugen wiedergegeben. Dieser Lösungsansatz erzeugt eine große Zahl von ARRAYS 25. Jedes ARRAY 25 erfordert ein unterschiedliches Kompressionsmodell, und die Anzahl der Einträge in jedes kann sich deutlich von Datei zu Datei verändern. Um in einem derartigen Falle effektiv zu arbeiten, verwenden bevorzugte Ausführungsformen der Erfindung neue Lösungsansätze, wie die Codierung auf niedriger Ebene, wie z.B. die Beseitigung des Overheads, die Anzahl-abhängige Verarbeitung und die Verwendung eines Verarbeitungsnetzwerkes anstelle fester Codierungsalgorithmen, gehandhabt wird. Diese vorstehend beschriebenen Techniken werden bevorzugt, um die Ausgabe des Untergliederungssystems 24 zu handhaben.
Alle diese Implementationsmerkmale sind auf einer hohen Ebene integriert, so dass Aufrufe auf hoher Ebene die Operationen handhaben können, die zum Initialisieren des Systems, Untergliedern der Daten und Codieren der ARRAYS erforderlich sind.

Gemäß einer speziell bevorzugten Ausführungsform der Erfindung enthält das Untergliederungssystem 24 drei Untersysteme:

FILE_BUFFER	Eingabe/Ausgabe-Schnittstelle
ARRAYS	Zum Speichern der Daten für eine einzelne Komponente
PVSTRUCT	Zum Untergliedern der Eingabe in RAS oder zum Schreiben der decodierten RAS in einen Ausgabestrom.

Eine Vielzahl von FILE_BUFFER-Routinen stellt eine flexible Eingabe/Ausgabe-Schnittstelle unter Verwendung von FILE_BUFFER-Strukturen bereit, so dass derselbe Satz von Untergliederungsroutinen unabhängig von den Eingabe/Ausgabe-Formaten verwendet werden kann. Dieses ermöglicht die Unabhängigkeit des Kompressionssystems von dem I/O-Format. Das Dateiuntergliederungssystem unterstützt bevorzugt zwei Dateiformate: DOS und OLE 2, wobei dieses aber auch auf weitere Dateiformate sowie auf Schnittstellen zu Kommunikationsports als auch andere I/O-Optionen erweitert werden kann. Für DOS-Dateien sind die logischen Strompositionen üblicherweise dieselben wie die Rohdateipositionen. Das OLE 2 Format erfordert eine aufwändige Codeschicht, um einem OLE 2-Strom innerhalb der Containerdatei zu folgen.
Eine Vielzahl von ARRAY-Routinen stellt ein System zur Verwaltung des Prozesses von Initialisieren, Hinzufügen von Daten, Codieren und Freigeben von Daten-Arrays bereit. Jede ARRAY-Struktur enthält ein Daten-Array und die erforderliche Information zum Verwalten dieser Prozesse, wie z.B. die Zahl der Einträge in dem ARRAY 25, die Größe des momentan für das Array zugeordneten Puffers und Information, welche für die Codierung des Arrays nützlich ist.
Insbesondere speichert eine ARRAY_XX-Struktur alle Daten aus einer Komponente, und enthält Mechanismen zum Unterstützen eines schnellen sequentiellen Lese/Schreib-Zugriffs auf die Daten, einen erweiterbaren Puffer für die Daten und einen Speicher für Modelldaten. Diese Struktur ermöglicht auch einen einfachen Satz von Werkzeugen zum Handhaben aller Zuordnungs-, Unterteilungs- und Codierungsfunktionen. Die _XX-Nomenklatur zeigt an, dass etwas unterschiedliche ARRAY-Strukturen für unterschiedliche Datentypen definiert sind, wie z.B. unterschiedliche Integer-Wortgrößen, Strings und Gleitkommazahl-Typen, obwohl viele von den Verarbeitungsroutinen mit allen Varianten arbeiten.
Eine Vielzahl von PVSTRUCT Routinen bildet ein automatisiertes System zur Untergliederung der Dateidaten. Während der Codierung lesen sie Daten aus der FILE_BUFFER-Struktur und schreiben diese in ARRAYS 25. Während einer Decodierung entnehmen sie Daten aus den ARRAYS 25 und schreiben sie in die FILE_BUFFER-Strukturen. Diese Routinen können eine Beschreibung auf hoher Ebene eines Dateiformates annehmen und bearbeiten alle Aufgaben in Verbindung mit der Verwaltung der Untergliederung sowie der Codierung der untergliederten Daten. Viele von den Filtern 10 enthalten ebenfalls anwendungsspezifische Untergliederungsroutinen, welche die FILE_BUFFER- und ARRAY-Routinen direkt anstelle der Verwendung der PVSTRUCT Routinen aufrufen. Ein Aspekt des Untergliederungssystems 24 sind jedoch die PVSTRUCT Routinen und diese Diskussion wird primär mit deren Betrieb betrachtet.
Eine PVSTRUCT-Struktur enthält die gesamte benötigte Information zum Untergliedern und Codieren einer in einem Dateiformat definierten Datenstruktur. Diese beinhaltet üblicherweise mehrere Komponenten, so dass sie einzelne ARRAYS 25 für jede Komponente bereitstellt und behandelt. Der Begriff "PVSTRUCT" kommt von "Predic tor Variable Struktur", wobei sich "Predictor" auf die Verwendung statistisch erfasster Daten aus der Analyse einer großen Zahl von Probendateien zur Unterstützung bei der Codierung der Daten bezieht, und "Variable" anzeigt, dass sie Strukturen unterstützt, in welcher die Komponentenanzahlen zum Zeitpunkt des Ablaufs für jede Instanz (als "dynamische Strukturen" in einigen Fachbüchern bezeichnet) variieren können.
Eine Untergliederungssprache ist ein definierter Instruktionssatz, welcher einen knappen Weg zur Spezifikation der Untergliederung einer PVSTRUCT-Struktur bereitstellt. Der Instruktionssatz enthält eine Unterstützung für einen großen Bereich dynamischer Variation, einschließlich dem, in welchem die Anzahlen der Komponenten von Dateianzahlen oder anderen Komponenten sowie von externen Faktoren abhängen. Er enthält weitere Dateiformatdaten, wie z.B. definierte Werte oder Bereichseinschränkungen. Er stellt auch eine Einrichtung zum Austauschen von Daten zwischen der Untergliederungseinrichtung und dem Filter bereit.
Das Kompressionssystem basiert auf der Untergliederung einer Datei, um Elemente, die ähnlich sind, zusammengefasst zu platzieren. In der nachfolgenden Beschreibung des Kompressionssystems veranschaulichen Beispiele einige Strukturen, welche man in einem typischen Arbeitsblattdateiformat findet.
Beispiel 2
Arbeitsblatt-Dateien enthalten typischerweise eine Reihe von Records. Jeder Record beginnt mit einem 16-Bit Wort, das den Typ des Records anzeigt, gefolgt von einem 16-Bit Wort, das die Anzahl der Bytes in dem Körper des Records angibt. Die Dateispezifikation beschreibt dann den Inhalt jedes Records. Eine Spezifikation für einen TABLE-SIZE Record könnte sein:
Record-Daten:
Es kann sich mehr als ein derartiger Record in den Daten befinden. Wenn mehr als der eine Record vorhanden sind, sind die Werte derselben Komponente in jedem Record wahrscheinlich ähnlich zueinander. Dieses ermöglicht es dem Kompressionssystem, Nutzen aus den Ähnlichkeiten zum Erhöhen des Kompressionsverhältnisses zu ziehen.

Das Kommunikationssystem basiert bevorzugt auf den ARRAY_XX-Strukturen, die umfassen:

ARRAY_U8:	für 8-Bit Datenelemente, die von dem Codierungssystem als vorzeichenlos behandelt werden
ARRAY_U16:	für 16-Bit Datenelemente, die von dem Codierungssystem als vorzeichenbehaftet behandelt werden
ARRAY_U32:	für 32-Bit Datenelemente, die von dem Codierungssystem als vorzeichenbehaftet behandelt werden
ARRAY_FU32:	für 32-Bit Gleitkommazahlen
ARRAY_FU64:	für 64-Bit Gleitkommazahlen "Doubles")
ARRAY_FU80:	für 80-Bit Gleitkommazahlen "Long Doubles")
ARRAY_STR:	jeder Eintrag enthält mehrere Bytes, deren Anzahl durch eine Größe (String-Größe) gegeben ist

Für den TABLE-SIZE-Record würden fünf Arrays (gemäß der Record-Spezifikation) erzeugt werden. Jedes Mal, wenn ein Record untergliedert wird, wird ein Eintrag in jedes der fünf Arrays eingefügt.
Wenn alle Records untergliedert worden sind, wird eine Funktion aufgerufen, um die Elemente in jedem Array zu codieren. Diese Funktion enthält eine große Zahl von Algorithmen, welche eine große Vielfalt von Beziehungen ausnutzen können, um eine maximale Kompression zu erreichen. Die Implementation ist dahingehend extrem effizient, dass sie praktisch keinen Overhead benötigt: Selbst ein Array mit nur einem einzigen Eintrag kann effizient komprimiert werden. Dieses ist erforderlich, da das Unter gliederungssystem eine Datei in eine riesige Anzahl dieser kleinen Arrays transformieren kann. Die Codierungsfunktion kann auch die Daten freisetzen, nachdem sie deren Codierung beendet hat.
Der Decodierungsprozess kehrt den Ablauf um. Zuerst werden alle Komponenten-Arrays decodiert. Dann wird die Untergliederung umgekehrt.
Da diese Art von Untergliederung extensiv durchzuführen ist, wird eine Anzahl von Werkzeugen verwendet, um den Prozess zu vereinfachen. Sie basieren auf der Verwendung von als vstructa_defs bezeichneten Instruktionen. Um das TABLE SIZE Beispiel fortzuführen, wäre der Instruktionssatz zur Untergliederung eines derartigen Records:
Die vstruct_def Instruktionen sind 16-Bit Integers. Die ersten drei Worte enthalten immer dieselbe allgemeine Information über den Record. Der Rest der Worte enthält Instruktionen, welche dem automatisierten Untergliederungssystem mitteilen, wie vorzugehen ist, wenn ein derartiger Record angetroffen wird. In diesem Falle sind die Instruktionen die einfachst möglichen – lediglich eine Liste von Datentypen für jede Komponente des Records. Die Untergliederungseinrichtung würde ein Array für jede Komponente erzeugen und einen Eintrag dieses Typs in das Array jedes Mal laden, wenn sie einen Record dieses Typs untergliedert.
Funktionen werden dann bereitgestellt, um die Untergliederung und Codierung der Records auf der Basis dieser Instruktionen zu automatisieren. Wiederum kehrt der Decodierungsprozess die Aktionen des Codierers um.
Die vstruct_def Instruktionen können wesentlich komplexere Situationen als das vorherige Beispiel handhaben. Zur Vereinfachung wird eine Zusammenfassung des Aufbaus dieser Instruktionen anschließend dargestellt. Das obere Byte der 16-Bit Instruktion ist ein von dem unteren Byte benötigtes Argument. Das untere Byte ist in zwei 4-Byte Codes unterteilt. Die untersten vier Bytes beschreiben den Instruktionstyp und bestimmen die Bedeutung der nächsten vier Bits. Diese Bitfeldstruktur macht die Instruktionen in der hexadezimalen Schreibweise sehr lesbar, was in der nachstehenden Beschreibung der Codes genutzt wird. Das Zeichen "x" repräsentiert hexadezimale Werte, die das beschriebene Codewort nicht beeinflussen:
In dem Codierer wird kein Unterschied gemacht zwischen Integers mit und ohne Vorzeichen. 8-Bit Werte werden immer vorzeichenlos verarbeitet; 16- und 32-Bit Werte werden mit Vorzeichen verarbeitet. Diese Konvention wird verwendet, um die Routinen zu vereinfachen und zu beschleunigen, um so weniger Fälle bei der Prüfung eines Schalt-Statements zu haben. Es hat geringen Einfluss auf die Kompressionsleistung, jedoch sollte, wenn die Dateidaten auch in der Unterteilung verwendet werden (beispielsweise wenn Elementeanzahlen Teil der Dateidaten sind) Sorgfalt aufgewendet werden.
Der STRINGZ bezeichnet Strings mit Nullen am Ende. Sie werden in demselben ARRAY_STR wie normale Strings gespeichert, können aber während der Unterteilung unterschiedlich behandelt werden. Beispielsweise müssen die Stringlängen bereitgestellt werden, wenn ein regulärer String unterteilt wird, während ein STRINGZ seine eigene Länge finden kann. Der STRINGZ muss auch das Nullabschlusszeichen nicht speichern.
Die SYS_Sxx Typen bezeichnen Systemstrings. Normalerweise ist jede Komponente jedes PVSTRUCT in sich selbst dahingehend abgeschlossen, dass jede in einem getrennten Array untergebracht und unabhängig codiert wird. Über viele kleine aber stark korrelierte Arrays zu verfügen ist für numerische Daten sehr effizient, wenn die Codierungsroutinen verwendet werden. Aber für Strings kann die Kompression oft verbessert werden, indem viele Komponentenstrings in einem einzigen Array platziert werden, wie z.B. um Textdaten aus mehreren Records zu kombinieren. Das System lässt zwei "System"-Strings zu, die diese kombinierten Komponenten enthalten. Die in diese Systemdaten hinzugefügten Strings können reguläre oder STRINGZ-Typen sein.
Zur Veranschaulichung werden nachstehend zwei einfache Beispiele beschrieben.
Beispiel 3
In diesem Beispiel wird die Wassertiefe an einer speziellen Stelle zu acht unterschiedlichen Zeitpunkten gemessen und in einer Datenbank gespeichert:
Die Tiefenmessungen wären sehr ähnlich, so dass man sie in nur einem einzigen Array unterbringen würde. Der Instruktionssatz wäre:
Beispiel 4
In diesem Beispiel speichert ein Record das Alter für einige Freunde:
Ein Array mit variabler Größe wie dieses kann nicht innerhalb einer Struktur in der Programmiersprache 'C' deklariert werden, erscheint aber oft in Dateiformaten. Dieser Aufbautyp wird oft als eine dynamische Struktur bezeichnet. Sie kann über dem Instruktionssatz unterteilt werden:
Register werden als Teil der PVSTRUCT-Struktur zugeordnet und werden zur temporären Speicherung von Daten während der Verarbeitung eines Records verwendet. Ein Register 0 wird für spezielle Aufgaben (siehe nachstehendes Beispiel) verwendet. Der ein Filter erstellende Programmierer kann den Rest der Einträge beliebig verwenden. Die Registrierungsdatenbank können auch zum Austausch von Daten zwischen einem PVSTRUCT und dem Rest des Programms verwendet werden. Beispielsweise kann, wenn ein in einem großen Record vergrabenes Element für Steuerzwecke benötigt wird, dieser in einem Registrierungsdatenbank mit einer xx2f Instruktion anschließend an die Instruktion, die das Datenelement liest, abgelegt werden. Das Datenelement ist dann in dem Registrier nach dem Aufruf zum Lesen oder Schreiben der Datei verfügbar.
Beispiel 5
Eine Dateispezifikation für einen als COLUMMN TYPES bezeichneten Records könnte sein:
Record-Daten:
Offset-Werte sind 1-Byte werte. Die Anzahl der Offsets wird durch die Recordgröße bestimmt.
Der Instruktionssatz für diesen Record wäre:
Die letzte Komponente des Records ist eine Liste von 1-Byte Spalten-Offsets. Diese sind einander ähnlich und sollten alle in einem einzigen Array untergebracht werden. In diesem Falle kann die Zahl derartiger Einträge nicht intern bestimmt werden, sondern es ist die Recordgröße zu nutzen, welche zuvor unterteilt worden ist. Die 0x15f-Instruktion teilt der Unterteilungseinrichtung mit, die Anzahl von 1-Byte Worten zu ermitteln, die in dem Record verbleiben, und dieser Wert wird immer im Register 0 gespeichert. Die 0x020-Instruktion teilt der Unterteilungseinrichtung mit, dass mehrere 1-Byte Elemente einem einzigen Array hinzuzufügen sind, und dass die Anzahl derartiger Elemente im Register 0 zu finden ist.
Beispiel 6
Ein Beispiel eines als RANGE DEFINITION bezeichneten Records mit einem String könnte sein:
Der Instruktionssatz für diesen Record ist:
Record-Daten:
Der Instruktionssatz für diesen Record ist:
Hier wurde eine subjektive Entscheidung durch die das Filter erzeugende Person getroffen. Die Komponente, welche als ein String behandelt wurde, könnte genauso als mehrere Einträge gemäß vorstehender Darstellung behandelt werden. Deren Instruktion wäre dann gewesen:
Die Entscheidung, ein String-Array zu verwenden, basierte auf der Art des Eintrags. Der Record enthält einen Text-String. Das Array-Codierungssystem stellt eine Anzahl spezieller Merkmale zur Handhabung von Strings bereit. Beispielsweise prüft es auf vollständige String-Übereinstimmungen (alle 16 Zeichen eines einzigen Eintrags stimmen überein), welche sehr effizient codiert werden können. Demzufolge werden Text-Strings immer effizienter komprimiert, wenn sie als Strings gespeichert werden. Im Gegensatz dazu würden die Offsets in dem vorherigen Kapitel besser innerhalb eines numerischen Kompressors behandelt, welcher keine Stringgrößen nutzt.
Beispiel 7
Die Dateispezifikation für einen weiteren als EXTERNAL REFERENCES bezeichneten Record mit einem String könnte sein:
Record-Daten:
Der Instruktionssatz für diesen Record ist:
Die letzte Komponente des Records ist ein mit 0 abgeschlossener String. Die Länge des Strings kann durch Suchen des Begrenzungszeichens gefunden werden. Da das String-Array die Stringgröße speichert und codiert, muss das Abschlusszeichen nicht gespeichert werden. Der INTERN_SZ zeigt an, dass die Größe des Records, obwohl sie nicht im Voraus bekannt ist, intern ermittelt wird, so dass die Recordgröße nicht codiert werden muss, wie es für den Column-Typ-Record von Beispiel 5 erforderlich war.
Beispiel 8
Eine Struktur kann innerhalb einer weiteren Struktur verschachtelt sein. Eine Elternstruktur kann mehrere Instanzen der verschachtelten Struktur enthalten. Eine Beschreibung eines derartigen COLUMN STATUS Records könnte sein:
Record-Daten:
Die ColData-Einträge geben den Offset zu jeder Spalte an, deren Status nicht gleich dem Vorgabewert ist, und den Status dieser Spalte. Jeder Eintrag hat zwei Bytes:

Offset 1 Byte

Status 1 Byte
Die Instruktion für diesen Record ist:
Die letzte Komponente des Records ist eine Serie von Offset/Status-Paaren. Getrennte Arrays müssen für die Offset-Komponente und für die Breitenkomponente erzeugt werden. Die Untergliederungseinrichtung muss eine Folge von Paaren durchlaufen und die Elemente in deren korrekten Array platzieren. Diese allgemeine Prozedur wird durch Sub-Strukturen gehandhabt. In diesem Falle hat die Sub-Struktur zwei UCHAR-Komponenten. Zwei Instruktionen wären bei dem Aufbau der Sub-Struktur beteiligt.
Alle anschließenden Komponenten werden als Elemente der Sub-Struktur behandelt, bis eine End_Sub-Struktur-Instruktion a angetroffen (x000f) wird. Wenn keine vor dem Ende der Instruktionsliste angetroffen werden, sind alle restlichen Komponenten Teil der Sub-Struktur. Wenn ein End_Sub-Struktur-Instruktion angetroffen wird, beziehen sich anschließende Instruktionen auf Komponenten, die als Teil der Hauptstruktur einzufügen sind.
Obwohl das Untergliederungssystem auch eine Sub-Sub-Struktur (eine Sub-Struktur innerhalb einer Sub-Struktur) unterstützt, werden höhere Verschachtelungsebenen bevorzugt nicht zugelassen, da bisher keine derartig komplizierten Dateispezifikationen identifiziert wurden. So viele Sub-Strukturen oder Sub-Sub-Strukturen wie nötig können innerhalb eines PVSTRUCT definiert werden, bevorzugt so lange die Verschachtelung nicht tiefer als zwei Ebenen zu einem Zeitpunkt ist, d.h. ein Rücksprung zu dem Elternverschachtelungsebene über eine End_Sub-Struktur-Instruktion möglich ist.
Beispiel 9
In einigen Fällen ist der in ein Array zu schreibende Bereich von Daten durch das Dateiformat kleiner als der durch die Wortgröße definierte volle numerische Bereich. Beispielsweise kann eine Dateispezifikation ein 1-Byte Eintrag sein, der entweder 0 oder 1 ist. Diese Information kann sowohl von dem Untergliederungssystem als eine Unversehrtheitsprüfung als auch von dem Codierungssystem zur Erhöhung der Kompression verwendet werden. Die Beschreibung eines veranschaulichenden COLUMN OPEN Record ist:
Record-Daten:
Der Instruktionssatz für diesen Record ist:
Anstelle einer Eingabe von UCHAR wird D8_1 eingegeben, ein definierter Code, der eine 8-Bit Wortgröße anzeigt und einen 1-Bit Bereich von tatsächlich verwendeten Werten. Diese Bereichseinschränkungen beeinflussen die Untergliederung der Datei: Ein Bereichseinschränkungseintrag wird gemäß seiner Wortgröße untergliedert. Die Bereichseinschränkungen werden verwendet, um die automatisierte Erzeugung der PREDICTOR-Struktur zu unterstützen, welche das statische Modell für eine Komponente enthält und die Codierung der Arrays steuert. Die derzeit definierten Code-Worte verwenden das Format:
Das Parsing-System 24 (2) ist bevorzugt als eine in der Programmiersprache C geschriebene Funktionsbibliothek implementiert. Diese Beschreibung der Bibliothek ist in drei Abschnitte unterteilt: Die FILE I/O Routinen, die ARRAY Routinen und die PVSTRUCT Routinen.
Das Untergliederungssystem 24 enthält eine flexible Eingabe/Ausgabe-Schnittstelle, so dass derselbe Satz von Untergliederungsroutinen unabhängig von den Eingabe/Ausgabe-Formaten verwendet werden kann. Zwei Dateiformate werden unterstützt: DOS und OLE 2, wobei diese jedoch auf weitere Dateiformate sowie auf Schnittstellen zu Kommunikationsports und auf weitere I/O-Optionen erweitert werden können. Das DOS-Format ist dahingehend trivial, dass die logische Stromposition üblicherweise dieselbe wie die Rohdateiposition ist. Das OLE 2 Format erfordert eine extensive Co deschicht, um einen OLE 2 Strom unter Verwendung der internen Zuordnungstabelle zu rekonstruieren.
Anwendungsspezifische Array-Transformationen
Das Untergliederungssystem 24 erzeugt ARRAYS 25 für jede Komponente in der Quellendatei, und der durch die durch das automatisierte Analysesystem erzeugten Codierungsparameter 18 unterstützte Array-Codierer 28 findet die beste Möglichkeit zum Codieren jedes ARRAYS 25 unter Anwendung der ihm zur Verfügung stehendem Algorithmen. In einigen Fällen kann dieser automatisierte Vorgabemechanismus hinsichtlich der Verwendung anwendungsspezifischer Routinen verbessert werden. Die anwendungsspezifischen Routinen sind aufgerufene Transformationen, da sie mit den untergliederten ARRAYS 25 beginnen und das Ergebnis ein unterschiedlicher an den Array-Codierer 28 gesendeter Satz von ARRAYS 25 ist.
Die Hauptrolle der anwendungsspezifischen Array-Transformationen 26 ist die Implementierung von Zwischen-Komponenten-Modellen: wenn die Daten aus einer Komponente bei der Codierung einer weiteren Komponente unterstützen können. Die automatisierten Vorgabemechanismen verarbeiten jede Komponente einzeln, und die Kompressionsleistung kann manchmal durch Nutzung von Zwischen-Komponenten-Beziehungen verbessert werden. Ein solches System ist eines, das genau alle Werte in einem ARRAY 25 vorhersagen kann, so dass kein Code für das ARRAY 25 erforderlich ist. Die anwendungsspezifische Array- Transformation 26 wird zu einem Simulator: der die Funktionalität des Programms dupliziert, welches die Quellendatendatei erzeugte. Jede anwendungsspezifische Routine ist eine getrennte Erzeugung, welche ein spezifisches Problem mit Verbindung mit einem einzelnen Filter 10 löst. Viele von diesen Routinen könnten unabhängig als eine Lösung auf dieses spezielle Problem angewendet werden.
Da anwendungsspezifische Routinen mehr Arbeitsaufwand zur Erstellung erfordern und die Größe der ausführbaren Routine vergrößern, ist ihre Nutzung bevorzugt auf Fälle beschränkt, welche wahrscheinlich einen deutlichen Schub in der Gesamtleistung produzieren. In vielen Dateiformaten bilden einige wenige Komponenten den größten Teil der Daten. Eine anwendungsspezifische Array-Transformation 26 kann üblicherweise die Kompression dieser häufigen Komponenten verbessern, während der automatisierte Vorgabemechanismus eine ausreichende Kompression der restlichen Komponenten erzielt.
Die anderen Teile des Systems spielen eine wichtige Rolle selbst bei Komponenten, für welche anwendungsspezifische Array-Transformationen 26 geschrieben sind. Das Untergliederungssystem 24 vereinfacht die Isolation der Komponenten und die Identifikation und Analyse von Komponenten, die eine spezifische Bearbeitung benötigen. Der Array-Codierer 28 und die automatisierten Analyseroutinen verarbeiten die von den anwendungsspezifischen Array-Transformationen 26 erzeugten ARRAYS noch weiter. Die Fähigkeiten des Array-Codierers 28 ermöglichen innovative Lösungsansätze für die anwendungsspezifische Modellierung. Ein derartiger Lösungsansatz ist eine Kompression mittels Subdivision; Transformation einer ARRAY 25 in mehrere ARRAYS 25, wovon alle intern in einer Weise korreliert sind, die durch den Array-Codierer 28 ausgenutzt werden kann.
Als ein Beispiel dafür betrachte man die codierten Zahlen in dem vorstehenden Beispiel 1. Diese Werte würden in ein einziges ARRAY 25 mit 32 Bits Integers untergliedert werden. Diese Werte sind aber keine Integers, sondern stattdessen Codes, in welchen zwei von den Bits anzeigen, dass der Eintrag einer von vier unterschiedlichen Typen ist, und dass die restlichen Bits unterschiedliche Bedeutungen für jeden Typ besitzen. Ein neues ARRAY 25 kann für die 2-Bit Flags erzeugt werden und dann können getrennte Arrays für jeden der vier Typen erzeugt werden. Das automatisierte Analysesystem und der Array-Codierer 28 können unterschiedliche und optimale Modelle für jedes dieser fünf Arrays finden, und die Systemeffizienz bei der Handhabung von Arrays mit weniger Einträgen eliminiert den Overhead der Verwendung der mehreren Arrays. Demzufolge ist die Gesamtgröße des Codes, die sich aus der Codierung dieser fünf stark korrelierten Arrays ergibt, deutlich geringer als die Codierung der einzelnen ursprünglichen Arrays.
Wenn eine anwendungsspezifische Array-Transformation von mehr als nur einem Filter 10 verwendet werden kann, kann sie in eine Ressource umgewandelt werden. Ressourcen sind getrennte Module (DLLs in der Windows-Umgebung), welche von mehr als einem Filter verwendet werden. Der Hauptgrund zur Verwendung von Ressourcen ist die Reduzierung des redundanten Codes.
Array-Codierer
Die meisten Kompressionsalgorithmen beinhalten die Transformation eines Datenblockes und dann die Codierung der Ergebnisse unter Verwendung eines Verfahrens, das die häufigsten Werte unter Verwendung weniger Bits repräsentiert. Mehrere aufeinan der folgende Transformationen können verwendet werden, und jede Transformation kann mehrere Ausgabeblöcke erzeugen. In einem typischen LZ 77 Codierer werden beispielsweise die Quellendaten in vier unterschiedliche Arrays transformiert: einen Block von 1-Bit Flags, die anzeigen, ob eine übereinstimmende Sequenz, ein Array von Bytes, welche mit keiner vorhergehenden Sequenz übereinstimmen, und die Länge und Position einer übereinstimmenden Sequenz, wenn eine gefunden wurde, gefunden wurden. Die ersten drei Arrays werden oft in ein einziges Array kombiniert und dann Huffmann-codiert, während die Übereinstimmungspositionen Bereichs-transformiert und dann Huffmann-codiert werden.
Diese Art eines Kompressionssystems kann als ein Verarbeitungsnetzwerk betrachtet werden, bei der das Quellen-Array Transformationen unterzogen wird, welche es in ein oder mehrere unterschiedliche Arrays umwandelt wird, welche wiederum anderen Transformationen unterzogen werden können. Am Ende jedes Pfades befindet sich der Codierer auf niedriger Ebene, wie z.B. der Huffmann-Codierer oder arithmetische Codierer, welcher ein Wahrscheinlichkeitsmodell in die codierte Ausgabe umwandelt. Herkömmliche Lösungsansätze zur Datenkompression basieren auf "Kompressionsalgorithmen" mit einer kleinen Anzahl von Transformationen und der Definition eines festen Pfades durch diese. Diese festen Systeme handhaben die Codierungsanforderungen herkömmlicher Untergliederungssysteme, welche eine kleine Anzahl von Komponenten erzeugen.
Ein bevorzugtes Untergliederungssystem 24 gemäß der Erfindung erzeugt große Anzahlen von ARRAYS 25, die unterschiedliche Komponenten in den unterschiedlichen Filtern 10 repräsentieren.
Der Datentyp (Strings, Gleitkommawerte und Integers mit verschiedenen Wortgrößen) kann für jede Komponente unterschiedlich sein. Die Daten innerhalb jedes dieser Komponenten-Arrays können intern in vielfältiger Weise korreliert werden. Das Erzielen einer optimalen Kompression erfordert die Verwendung eines Kompressionsalgorithmus, welcher diese Muster ausnutzt. Der optimale Algorithmus wird auch durch die momentane Verfügbarkeit von Speicher und den gewünschten Kompromiss zwischen Geschwindigkeit und Kompressionsleistung beeinflusst. Die Anzahl von Einträgen in jedem Array variiert ebenfalls stark, und unterschiedliche Codierungslösungsansätze können besser bei unterschiedlichen ARRAY-Zählwerten arbeiten.
Das bevorzugte Codierersystem hat für jede Komponente ein statisches Modell zur Verfügung. Dieses Modell wird erzielt, indem Instanzen dieser Komponente in einer großen Anzahl von Quellendateien des durch ein Filter bedienten Typs analysiert werden. Das System ist weder "statisch" noch "adaptiv", sondern verwendet stattdessen Information aus dem statischen Modell, wann immer dieses hilfreich ist, während es vollständig in der Lage ist, auf die in jedem Array gefundenen einmaligen Datensatz zu reagieren. Das statische Modell kann sowohl die Auswahl von Transformationsalgorithmen führen als auch vorberechnete Codierungstabellen für die verschiedenen Algorithmen bereitstellen.
Demzufolge muss das bevorzugte Codiersystem Tausende unterschiedlicher Arten zur Codierung jedes Arrays unterstützen. Das Verarbeitungssystem ist kein festgelegter Algorithmus, sondern stattdessen ein dynamisches Netzwerk, und jeder Pfad durch dieses Netzwerk erzeugt einen unterschiedlichen Codierungsalgorithmus. Der Pfad der Daten durch das Netzwerk wird sowohl durch statische Modelle als auch dynamische Betrachtungen, wie z.B. die Anzahl der Einträge in dem Array, der Geschwindigkeit und Speichereinschränkungen geführt.
Ein Aspekt des bevorzugten Codiersystems ist die extensive Nutzung der Array-Zählwerte (der Anzahl von Einträgen in einem Array) zum Steuern des Netzwerkes. Bei niedrigeren Zählwerten verlässt sich das System stark auf ein statisches Modell, das aus der Analyse von Probendatenbanken erzeugt wird. Wenn der Zählwert ansteigt, verwendet das System Lösungsansätze, welche sich mehr an die Eigenschaften eines spezifischen Arrays anpassen, da der Gewinn aus der Anwendung adaptiver Modelle beginnt den Overhead der Codierung des adaptiven Modells zu überwiegen. Der Overhead ist bei niedrigen Zählwerten nahezu vollständig eliminiert, so dass selbst Arrays mit nur einem einzigen Eintrag effizient codiert werden können. Diese Beseitigung des Overheads erlaubt wiederum die Anwendung neuer Arten von Lösungsansätzen, welche als Kompression durch Sub-Division bezeichnet werden können, in welchen Quellen-Arrays in eine große Zahl hoch korrelierter kleinerer Arrays transformiert werden.
Das bevorzugte Codiersystem enthält auch eine Anzahl ursprünglicher Algorithmen, welche eine gesteigerte Kompressionsleistung für viele von den Komponenten, welche angetroffen wurden, bereitstellen. Routinen, wie die Gleit-, und String-Array-Transformationen stellen bedeutende Vorteile gegenüber vorherigen Verfahren zur Codierung dieser Komponenten dar.
3 ist ein Flussdiagramm eines Array-Codierers. Um die Schnittstelle zu anderen Routinen zu vereinfachen, enthält eine bevorzugte Implementation des Array-Codierers nur eine einzige Codierungsroutine, welche alle Array-Typen (Integers und Gleitkommawerte verschiedener Wortgrößen, Strings usw.) bearbeitet. Die Hauptroutine leitet dann wie dargestellt jedes Array zu einer spezialisierten Codierungsroutine.
Insbesondere wird im Schritt 32 der Typ des ARRAYS 25 als ein String-Array geprüft. Wenn das Array ein String-Array ist, wird dann ein String-Codierer 40 aufgerufen. Wenn das Array kein String-Array ist, wird der Array-Typ bei dem Schritt 34 als ein Gleitkommawert-Typ geprüft. Wenn das Array ein Gleitkommawert-Typ ist, wird dann ein Gleitkommawert-Codierer 50 aufgerufen. Wenn das Array weder ein String- noch ein Gleitkommawert-Typ ist, ist es ein Integer-Typ, und es wird ein Integer-Codierer 70 aufgerufen.
4 ist eine Blockdarstellung des String-Codierers 40 von 3. Der Begriff "String" wird hierin verwendet, um eine Multi-Byte Sequenz von Zeichen zu beschreiben. Ein String-Array kann einen oder mehrere derartige Strings enthalten, wovon jeder eine unterschiedliche Stringgröße (die Anzahl von Bytes in dieser Sequenz) enthalten kann. Der String-Codierer kann zuerst auf String-Übereinstimmungen in den empfangenen String-Daten unter Verwendung eines String-Vergleichers 41 prüfen – Fälle, in welchen ein gesamter String mit jedem anderen String in dem Array übereinstimmt. Der String-Vergleicher 41 kann an String-Daten aus dem Array-Codierer 28 oder einer Liste vorhergesagter Strings arbeiten, die von einem statischen Modell 43 geliefert werden. Anschließend kann das Array mittels verschiedener Mechanismen codiert werden. Kleinere Arrays, wie z.B. nicht übereinstimmende Strings, können bei einem Textcodierer 47 verarbeitet werden, welcher eine Variante der LC-Transformation verwendet, welche wiederum den Vorteil der String-Positionen nutzt, und welche auch statische Modelle verwenden kann, um das Wörterbuch vorzubereiten oder Codierungstabellen vorzuschlagen. Größere Arrays mit übereinstimmenden Codes können durch Standardtextkompressionsroutinen bearbeitet werden, welche von dem Array-Codierer 28 bereitgestellt werden, wie z.B. Blocksortieralgorithmen und andere allgemein bekannte Techniken. Wenn der Textcodierer 47 von dem statischen Modell 43 verwendet wird, wird der Codierer durch das statische Modell 43 vorbereitet.
5 ist eine Blockdarstellung des Gleitkommawert-Codierers 50 von 3. Gleitkommawert-Arrays können entweder in 32-, 64- oder 80-Bitformaten vorliegen. Der Gleitkommawert-Codierer empfängt die Gleitkommadaten aus dem Array-Codierer 28 und prüft erst auf Übereinstimmungen mit vorherigen Werten unter Verwendung eines LZ-Codierers 51, welcher nur Voll-Worte (wie z.B. alle 8 Bytes eines Doppelgenauigkeits-Gleitkommawertes) vergleicht, und ein Array mit den nicht übereinstimmenden Werten zurückgibt. Die nicht übereinstimmenden Werte werden dann zu einer Schreibweise auf der Basis 10 in einen Wandler 53 der Basis 10 umgewandelt, da viele Datenbanken Gleitkommawerte enthalten, welche ursprünglich als Werte auf der Basis 10 eingegeben wurden, und eine Codierung der Werte durch den Array-Codierer 28 in ihr Ausgangsformat ist effizienter. Die Mantissen zur Basis 10, Exponenten und Umwandlungsfehler werden getrennt durch den Array-Codierer 28 verarbeitet. Für eine verlustlose Codierung muss möglicherweise ein Offset gespeichert werden, um leichte Rundungsfehler in der Umwandlung zu korrigieren. Werte, welche nicht effektiv zur Basis 10 umgewandelt werden, werden dann unter Verwendung des String-Codierers 40 (4) codiert.
Automatisierte Analysesysteme
Das Untergliederungssystem untergliedert die Quellendateien in eine größere Anzahl von Komponenten. Durch Überprüfung derselben Komponente in einer Anzahl von Probendateien kann ein statisches Modell dieser Komponente aufgebaut werden, welches die Kompression von Arrays dieser Komponente in dem Array-Codierer vergrößern kann. Das automatisierte Analysesystem findet das beste derartige Modell.
6 ist ein Flussdiagramm eines bevorzugten automatisierten Analysesystems. Bei dem Schritt 62 wird die Operation vereinfacht, indem zuerst alle Quellendatendateien in Dateien mit allen Instanzen einer speziellen Komponente in allen Quellendateien untergliedert werden. Diese untergliederten Dateien werden dann bei dem Schritt 64 analysiert. Diese Analyse muss nicht schnell sein, da sie Offline ausgeführt wird. Die Ergebnisse für alle Komponenten für das Filter werden dann bei dem Schritt 66 in einer einzigen "PredictorData"-Datei konsolidiert, welche redundante Daten unter den mehreren Komponentenmodellen entfernt.
CODIERER FÜR INTEGER-DATEN
Der Codierer für Integer-Daten basiert bevorzugt auf einem Drei-Ebenen-System. Die Operationen der höchsten Ebene basieren auf Modellen, welche die Beziehungen zwischen einem Datenelement und spezifischen vorherigen Elementen in dem Datenblock nutzen, wie beispielsweise ein LZ-Algorithmus, welcher den Abstand zu einer Folge von übereinstimmenden Werten codiert, oder wie eine Differenztransformation, welche einen Wert in den Offset von dem vorherigen Wert transformiert. Die Operationen der mittleren Ebene basieren auf Modellen, welche von der Position der Datenwerte in dem Quellendatenblock unabhängig sind. Sie nutzen die Eigenschaften der Daten, wie z.B. die Häufigkeit, mit welcher spezifische Werte in dem Gesamtblock auftreten, oder die Häufigkeit, mit welcher die Datenwerte in verschiedenen numerischen Bereichen liegen. Sie transformieren die Datenwerte in einen Block von Codes. Der Codierer auf niedriger Ebene komprimiert diese Codes auf der Basis eines Wahrscheinlichkeitsmodells. Zwei allgemein bekannte Codierer auf niedriger Ebene sind der Huffmann- und arithmetische Codierer und jeder kann in dem vorliegenden System verwendet werden. Die nachstehende Diskussion beschreibt nur die Systeme der mittleren und hohen Ebene.
Der Codierer der hohen Ebene ist keine Einzellösung, sondern eine Sammlung von Verfahren und Modellen, wovon jedes bei einem speziellen Typ eines Datensatzes effektiv ist. Es gibt keine Einzellösung für diesen Teil des Problems, da viele andere Verfahren ebenfalls demselben allgemeinen Zweck dienen könnten, eine Lösung für Datensätze mit anderen als den hier betrachteten Eigenschaften bereitzustellen. Einige von den Verfahren, welche beschrieben werden, sind Standardtechniken, und andere sind besondere Adaptionen von Standardtechniken. Zusätzlich zur Beschreibung dieser Verfahren wird ein allgemeiner Rahmen zur Integration dieser Modelle auf hoher Ebene beschrieben, und um zu zeigen, wie die sich aus deren Transformationen ergebenden Daten effizient durch den Codierer der mittleren Ebene behandelt werden.
Der Codierer der mittleren Ebene hat die Größe des Alphabets auf eines zu reduzieren, welches effektiv durch die Codierer der niedrigen Ebene behandelt werden kann. Übliche numerische Wortgrößen erfordern oft mehr Symbole als von den herkömmlichen Implementationen entweder des Huffmann- oder arithmetischen Codierers gehandhabt werden können. Beispielsweise wären über 4.000.000.000 Symbole erforderlich, um das Alphabet der 32 Bits Integers zu repräsentieren, was bei weitem die Buchhaltungsfähigkeiten dieser Codierer überschreitet. Der Codierer der mittleren Ebene nutzt zwei Eigenschaften, welche in numerischen Datenblöcken üblich sind.

– Erstens treten spezifische Datenwerte oft mit einer hohen Häufigkeit in Datenblöcken auf. Jeder Datenblock kann einen eindeutigen Satz dieser magischen Werte enthalten, und diese Werte können an jedem Punkt in dem numerischen Bereich auftreten.
– Zweitens können Datenwerte ungleichmäßig in Bezug auf den numerischen Bereich verteilt sein. Beispielsweise tendieren in einigen Datenblöcken kleinere Werte dazu, häufiger als größere Werte aufzutreten.

7 ist eine Flussdiagrammübersicht über den Integer-Codierer der hohen Ebene. Der Integer-Codierer 70 beginnt bei dem Schritt 71, indem er das Modell der hohen Ebene aufbaut, welches die für die Transformationen verwendeten Transformationen und die zur Implementation dieser Transformationen benötigten anderen Parameter bestimmt. Diese Daten werden in einer codierten Modelldatenstruktur bei dem Schritt 73 gespeichert und als verschiedene Schritte während der Verarbeitung gemäß Darstellung verwendet.
Die erste Option ist ein Initialsplitter bei dem Schritt 75, welcher verwendet wird, wenn die unteren Bytes in einen Wert stark unabhängig von den oberen Bytes korreliert sind. Ein übliches Beispiel dafür ist das Auftreten von Nullen in den unteren Digits von Werten zur Basis 10 mit einer wesentlich höheren Häufigkeit als die bei einem zufälligen Datensatz erwarteten 10%. Wenn der Codierer der hohen Ebene eine derartige Bedingung detektiert, kann er bei dem Schritt 77 eine Teilung des Quellen-Arrays in getrennte Arrays bewirken, welche die oberen und unteren Digits in den Quellenwerten repräsentieren. Die Vielzahl der durch den Splitter zurückgegebenen ARRAYS wird getrennt verarbeitet.
Die ARRAY-Daten werden anschließend bei dem Schritt 79 geprüft, um zu ermitteln, ob ein Übereinstimmungsalgorithmus auf die Daten angewendet werden sollte. Der Übereinstimmungsalgorithmus bei dem Schritt 81 eliminiert redundante Datenelemente: diejenigen, welche vollständig mit einem vorherigen Eintrag in dem Array übereinstimmen. Die Übereinstimmungsalgorithmen speichern ARRAYS mit übereinstimmenden Daten bei dem Schritt 83. Nicht übereinstimmende Werte werden durch eine Handhabungseinrichtung für Übergrößen-Arrays bei dem Schritt 85 verarbeitet.
Das System beschränkt bevorzugt die Größe eines Integer-ARRAY auf ein festes Maximum, was den Wirkungsgrad verbessert und einige der Auslegungsprobleme vereinfacht. Wenn ein ARRAY-Zählwert dieses Maximum überschreitet, bringt die Handhabungseinrichtung für ein Übergrößen-Array (Schritt 85) das Array in eine Reihe kleine rer ARRAYS auf. Diese ARRAYS werden dann bei dem Schritt 37 in int32s umgewandelt, so dass die restlichen Routinen mit einem üblichen Datentyp arbeiten können. Diese Transformationen finden nach den Übereinstimmungsalgorithmen (Schritt 81) statt, da die Übereinstimmungsalgorithmen effizienter bei größeren Blöcken arbeiten.
Die int 32-Daten werden anschließend bei dem Schritt 89 geprüft, um zu ermitteln, ob anschließend eine numerische Transformation auszuführen ist. Bei dem Schritt 91 transformieren numerische Algorithmen das Array in Offsets von einem vorhergesagten Wert unter Verwendung vorheriger Werte. Diese Offsets von dem Modell werden dann an den Splitterentscheidungsblock bei dem Schritt 93 geliefert.
Wie vorstehend wird, wenn eine Splitterfunktion erforderlich ist, eine Splitteroperation bei dem Schritt 95 durchgeführt. Die Splitterfunktion gibt eine Vielzahl von ARRAYS zurück, welche getrennt verarbeitet werden.
Bei dem Schritt 97 wird eine Feststellung getroffen, ob eine Wiederholungstransformation (Schritt 99) zu verwenden ist. Die Wiederholungstransformation bei dem Schritt 99 ist ein Typ einer Übereinstimmungstransformation, kann jedoch nach allen anderen Transformationen angewendet werden. In jedem Falle geht die Verarbeitung auf den Codierer 100 der mittleren Ebene über.
Man beachte, dass der Splitter an zwei Stellen (Schritt 77 und 95) in dem Flussdiagramm dargestellt ist. Dieses ist so, da die Teilung typischerweise vor einer numerischen Transformation oder nach einer Übereinstimmungstransformation durchgeführt wird, wenn eine dieser Transformationen angewendet wird. Die Übereinstimmungs-, numerischen und Wiederholungs-Transformationen nutzen die Beziehung zwischen einem Datenelement und vorherigen Datenelementen in dem codierten Block.
Es sei angemerkt, dass der Begriff "hohe Ebene" den Aufbau dieses Codierers, aber nicht die Relation zwischen diesem Codierer und dem Gesamtkompressionssystem betrifft. Vor dem Senden eines Datenblocks an diesen Codierer kann das Gesamtsystem viele Dinge ausführen, um die Kompression zu verbessern, wie z.B. eine Untergliederung der Quellendaten, um so Arrays ähnlicher Komponenten zu erzeugen und den Vorteil von Zwischenbeziehungen zwischen unterschiedlichen Komponenten nutzen. Die hierin beschriebene Operation schließt diejenigen aus, welche auf der Systemebene bearbeitet werden sollten. Diese Beschreibung nimmt auch an, dass das Gesamtsystem auch Datentypen aussiebt, welche besser durch spezialisierte Codierer bearbeitet werden, wie z.B. Daten mit zwei Pegeln, Text, Bitmapping-Bilder, usw.
Der Zweck des Codierers auf hoher Ebene ist die Nutzung von Beziehungen zwischen unterschiedlichen Datenelementen in einem Datenblock. Zwei Arten von Beziehungen werden derzeit bearbeitet: numerische Transformation und Übereinstimmung.
Die numerischen Transformationen sagen einen Datenwert d[i] als Funktion einer arithmetischen Operation vorher, die an vorherigen Datenwerten in dem Block ausgeführt wird. Der D[i] wird dann als ein Offset von dem durch die Transformationsgleichung vorhergesagten Wert dargestellt. Die Transformation ist effizient, wenn die Anzahl der zum Codieren des transformierten Wertes benötigten Bits, kleiner als die ist, die zum Codieren des ursprünglichen Wertes erforderlich sind. Die Übereinstimmungsalgorithmen codieren Übereinstimmungen zwischen D[i] und einem vorherigen Wert in dem Datenblock. Der Algorithmus ist effizient, wenn die Anzahl der zum Codieren der Position des übereinstimmenden Wertes benötigten Bits kleiner als die ist, die zum Codieren von [i] erforderlich sind. Beide Arten von Operationen können an demselben Block durchgeführt werden. Beispielsweise kann einer Differenztransformation, welche D[i] als den Offset von D[i – 1] darstellt, ein Übereinstimmungsalgorithmus folgen, welcher Übereinstimmungen dieser Offsets findet.
Die Entscheidung, welche Operationen an einem Datenblock durchzuführen sind, wird von einer Modellauswahleinrichtung getroffen. Eine maximale Kompression kann erzielt werden, indem der vollständige Datenblock unter Verwendung jeder möglichen Kombination von Algorithmen codiert wird, wobei dieses aber mehr Verarbeitungszeit erfordert als die meisten realen Anwendungen erübrigen können. Die Bewertung kann beschleunigt werden, indem eine Alternative nur an einem Untersatz des zu codierenden Datenblockes geprüft wird, und indem Modelle aufgebaut werden, welche den Codierungsaufwand der transformierten Datenblöcke ohne vollständige Codierung dieser abschätzen. Der Codierer stellt die Fähigkeit bereit, Verarbeitungszyklen gegenüber Kompressionsleistung abzuwägen: Wenn die Anwendungsumgebung unter weniger Zeitdruck steht, kann sie mehr Zeit für die Bewertung von Alternativen verbrauchen, um die Kompressionsleistung zu verbessern. Die Diskussion jedes Algorithmus enthält eine Beschreibung des Modells, das zum Abschätzen des Codierungsaufwandes verwendet wird, wenn dieser Algorithmus verwendet wird.
Der erste Schritt in dem Codierer auf hoher Ebene besteht in der Abschätzung des Aufwandes der Codierung des Datenblocks, wenn keine Transformation angewendet wird, da die Umgehungscodierungstabellen später verwendet werden, um die Effektivität der anderen Alternativen zu bewerten. Der Umgehungsmodus kann getestet werden, indem ein Probendatenblock erzeugt wird und dieser an die Simulatoreinrichtung der mittleren Ebene gesendet wird. Die nachstehend zu beschreibende Simulatoreinrichtung der mittleren Ebene stellt einen schnellen Mechanismus für die Abschätzung des Aufwandes zum Codieren der an den Codierer der mittleren Ebene gesendeten Codierungsblöcke bereit. Die Größe des Probendatenblocks ist abhängig von Zeitbeschränkungen angepasst. Da die Codierung der mittleren Ebene von der Position von Datenwerten unabhängig ist, können die Proben zufällig in dem Datenblock verteilt sein, statt dass Probenblöcke nach Bedarf ausgewählt werden, um eine sequentiellen Algorithmus zu bewerten. Wenn andere Modi hoher Ebene bewertet werden, kann die Modellauswahleinrichtung Codierungstabellen verwenden, die von dem Codierer der mittleren Ebene erzeugt werden, um den Aufwand der Codierung jedes Elementes in dem Quellendatenblock abzuschätzen.
Die einfachste Beziehung besteht in der Codierung eines Wertes als ein Offset von einem vorherigen Wert. Dieses sagt im Wesentlichen voraus, dass D[i] = D[i – 1] ist, und transformiert D[i] in den Offset von dem vorhergesagten Wert: D'[i] = D[i – D[i – 1] (1)
Das System unterstützt auch eine Variante davon, welche dahingehend weniger störungsempfindlich ist, dass sie einen Wert vorhersagt, der gleich einem Durchschnittswert über die N-vorhergehenden Einträge ist:
Die Gleichung 1 kann als Fall der Gleichung 2 betrachtet werden, in welchem N = 1 ist. Sie werden jedoch unter Verwendung getrennter Routinen implementiert, um den Vorteil einer erhöhten Geschwindigkeit zu nutzen, wenn die einfachere Gleichung 1 bearbeitet wird.
Obwohl einige Datentypen (Ton, Bilder, usw.) Nutzen aus komplexeren Beziehungen ziehen könnten, werden derartige Datentypen bevorzugt unter Verwendung spezialisierter Routinen codiert, so dass keine andere Gleichung in den Allzweck-Integer-Codierer integriert ist.
Die Modellauswahleinrichtung liegt in zwei Stufen vor. Die erste Stufe wählt das beste numerische Modell aus, welches in unserem momentanen Aufbau lediglich die Auswahl des optimalen Wertes von N in der Gleichung 2 ist. Es reicht aus, lediglich einige wenige Werte wie z.B. N = 1, 2 und 4 zu prüfen, und dann den Wert von N auszuwählen, welcher die kleinsten Offsets produziert. Die genaueste Darstellung des Codierungsaufwandes bestünde in dem Vergleich von Logarithmen zur Basis 2 der Offsets, wobei es jedoch ausreicht, lediglich die Absolutwerte der Offsets zu vergleichen:
wobei ct = der Zählwert der Einträge in dem Datenblock ist.
Diese Routine kann schnell die optimale numerische Beziehung finden, so dass die zum Abschätzen des Codierungsaufwandes arbeitsaufwändigere Routine nur an einer numerischen Alternative auszuführen ist. Die momentane Routine zum Abschätzen des tatsächlichen Codierungsaufwandes basiert auf der Codierung eines Probendatensatzes unter Verwendung des Codierers der mittleren Ebene, wie sie für die Umgehungsbewertung ausgeführt wurde.
Drei Übereinstimmungsalgorithmen werden bevorzugt implementiert: eine Version des LZ-Algorithmus, welche eine Anzahl von Verbesserungen für die Arbeit mit Integers aufweist; eine Wiederholungstransformation, und einen Move-to-Front-(MTF)-Algorithmus.
Obwohl der LZ-Basisalgorithmus keine Wortgröße spezifiziert, basieren die meisten Implementationen auf der Verwendung von 1-Byte Worten. Das bevorzugte System ermöglicht eine flexible Wortgröße, welche derzeit 1, 2 und 4 Byte Integers umfasst. Die Routine erzeugt drei Ausgabe-Arrays:

– Nicht übereinstimmende Werte: Diese sind die Integers in dem Datenblock, welche nicht Teil einer Übereinstimmungssequenz sind. Der Datentyp ist unverändert – wenn das Quellen-Array int32s war, sind die nicht übereinstimmenden Werte ebenfalls int32s. Dieses verdichtete Array wird an den Integer-Codierer der niedrigeren Ebene zur Kompression gesendet.
– Länge: Für Übereinstimmungssequenzen gibt diese die Anzahl von Worten an, welche in dieser Sequenz übereinstimmten. Ansonsten gibt diese die Anzahl von nicht übereinstimmenden Werten vor der nächsten Übereinstimmung an.
– Position: Diese gibt den Offset (Anzahl der Worte, nicht Bytes) bis zu dem Beginn der Übereinstimmungssequenz an.

Eine weitere Innovation in der Implementation der Algorithmen ist ein dynamisches System zur Bewertung von Übereinstimmungen. Herkömmliche LZ-Implementationen nehmen einen festen Aufwand für die Codierung nicht übereinstimmender Datenelemente an, aber die Ergebnisse der Umgehungsbewertung stehen zur Verfügung, welche eine gute Abschätzung des Aufwandes der Codierung jedes unterschiedlichen nicht übereinstimmenden Datenwertes geben. Beispielsweise wären, wenn der Wert 1019 mit einer Häufigkeit von 25% auftritt, dessen Codierungsaufwand als ein nicht übereinstimmendes Element 2 Bits, was bedeutet, dass es nicht effizient wäre, eine Übereinstimmung von zwei derartigen Werten in einer Übereinstimmungssequenz zu codieren, da den Aufwand der Codierung der Übereinstimmung den Aufwand der Codierung des Wertes als einen nicht übereinstimmenden Eintrag überschreiten würden. Der Umfang, bis zu welchem dieses System einer dynamischen Bewertung implementiert ist, kann abhängig von dem Geschwindigkeits/Kompressions-Kompromiss in jeder Echtzeitsituation eingestellt werden.
Die Wiederholungstransformation ersetzt wiederholte Werte durch Wiederholungscodes. Das bevorzugte System stellt einige Verbesserungen gegenüber Standardimplementationen bereit. Erstens werden Wiederholungscodes dynamisch angepasst. D.h., die für jeden Datenblock verwendeten Wiederholungscodes werden gemäß zwei Eigenschaften des Datenblockes angepasst: der Größe des Datenblockes und der Anzahl der wiederholten Werte in dem Block. Zweitens gibt ein spezieller run-to-end-Code an, dass eine Wiederholungssequenz sich bis zu dem Ende des Blockes fortsetzt. Schließlich gibt es auch spezielle Codes, um große Werte darzustellen. Um Platz für die Wiederholungscodes zu schaffen, werden nicht übereinstimmende positive Werte durch die Anzahl der Wiederholungscodes nach oben verschoben. Um eine Vergrößerung unseres numerischen Bereichs zu vermeiden, werden die Werte an dem Ende des positiven Bereichs unter Verwendung spezieller Codes codiert.
Herkömmliche MTF-Codierer nehmen kleine Wortgrößen an, so dass sie alle möglichen Symbole als Übereinstimmungsabstände darstellen können. Große Wortgrößen sind zulässig, indem beispielsweise ein Puffer mit eingeschränkter Größe verwendet und indem ein Ausgabe-Array nicht übereinstimmender Werte erzeugt wird, welches an anschließende Ebenen des Integer-Codierers zur Codierung gesendet werden kann. Wenn ein Datenwert mit einem Wert in diesem Puffer übereinstimmt, wird er unter Verwendung des Index des Übereinstimmungswertes in dem Puffer dargestellt. Andernfalls wird die Anzahl nicht übereinstimmender Werte vor der nächsten Pufferübereinstimmung aufgezeichnet. Die Größe des Puffers wird abhängig von den Umgehungstestergebnissen angepasst. Wenn es die Zeit zulässt, wird der Aufwand der Codierung eines Elementes als ein nicht übereinstimmender Wert gegenüber dem Aufwand der Codierung dieses als eine Pufferübereinstimmung abgewogen, wobei dieses aber aufgrund des kleineren Overheads nicht kritisch für die MTF-Algorithmen ist, wie es für den LZ-Algorithmen war.
Dieser MTF-Algorithmus übertrifft den Integer-LZ-Algorithmus, wenn einzelne Elemente übereinstimmen, aber weinige Multi-Wort-Übereinstimmungsfolgen vorliegen. Um ein redundantes Suchen nach Übereinstimmungen zu vermeiden, sind beide Algorithmen bevorzugt in nur eine Transformationsroutine integriert, welche getrennte Ausgabe-Arrays erzeugt, und dann anschließend diejenige auswählt, welche besser arbeitet.
Statt der Bewertung der kleine Probensätze verwendenden Übereinstimmungsalgorithmen können die Transformation an dem vollständigen Datenblock ausgeführt werden, und dann die Ergebnisse zum Senden dieser an den Simulator der mittleren Ebene bewertet werden. Wenn die Zeitumgebung der Anwendung zeitlich stark beschränkt ist, erfolgt diese Bewertung nur nachdem ein Teil des Blockes transformiert worden ist.
In vielen realen Datensätzen haben die einzelnen Digits der Darstellungen der Werte auf der Basis 10 Eigenschaften, welche zur Erhöhung der Kompression genutzt werden können. Diese Eigenschaften werden unter Anwendung einer als "Splitting" bezeichneten Technik ausgenutzt. Das Array der Integers wird in zwei oder mehr getrennte Arrays von Integers aufgeteilt, wobei jedes Array aus einem Untersatz der Digits in dem Quellen-Array erzeugt wird. Das Splitten ist effizient, wenn der Gesamtcodierungsaufwand der Split-Arrays kleiner als der Aufwand der Codierung des Eingabequellen-Arrays ist. Ein Beispiel eines Arrays, welches effizient unter Verwendung von Splitting verarbeitet wird, wäre:
Vor der Splittung scheint das Quellen-Array zufällig innerhalb eines 21 Bitbereichs (10795484–13195399) zu variieren. Aber nach der Splittung kann die erste Spalte in 4-Bits/Eintrag codiert werden, die zweite verschwindet, und die dritte fällt in einen 7-Bit Bereich (399 bis 501). Der Gesamtaufwand für die Codierung ist etwa der halbe Aufwand der Codierung des Quellen-Arrays. Ferner kann jedes Array oft auf mehrere Arten gesplittet werden.
Das Splitten ist nützlich, da es Korrelationen findet, welche manchmal zwischen den Digit-Feldern auftreten, welche für andere Verfahren zur Bewertung der Zahlen nicht ersichtlich sind. Es ist insbesondere hier wichtig, da einige von den Transformationen, die für die Bereichs-Rückzuordnungseinrichtung zu beschreiben sind, niedrigere Bits als Zufallszahlen behandeln. Ohne die Anwendung des Splittings würden die Korrelationen in den niedrigeren Digits, wie z.B. das Vorhandensein vieler Nullen verloren gehen.
Die Modellauswahleinrichtung auf hoher Ebene hat mehrere Entscheidungen bezüglich des Splittings zu treffen. Ferner bestimmt die Modellauswahleinrichtung das zu verwendende beste Modell und ob Splitting effizienter ist als die anderen Codierungsalternativen. Zweitens ermittelt die Modellauswahleinrichtung, ob ein Übereinstimmungsalgorithmus vor der Ausführung des Splittings durchlaufen werden sollte. Schließlich ermittelt die Modellauswahleinrichtung, welche Algorithmen auf hoher Ebene bei jedem der gesplitteten Arrays nach dem Splitten durchlaufen werden sollte, wie z.B. eine numerische Transformation oder einer von den Übereinstimmungsalgorithmen.
Die Beziehungen, welche für Splitting geeignet sind, sind üblicherweise nur in der Darstellung zur Basis 10 sichtbar, so dass die erste Aktion des Splitters darin besteht, die Daten in die Darstellung zur Basis 10 umzuwandeln. In einigen Fällen können die Quellendaten ursprünglich in alphanumerischer Darstellung vorgelegen haben, und es wird in derartigen Fällen Umwandlungszeit eingespart, wenn die String-Darstellung des Datenblockes als ein optionales Argument an den Integer-Codierer übergeben wird.
Zur Bewertung des Splitteralgorithmus wird ein Histogramm für jedes Digit aufgebaut, was die Häufigkeit des Auftrittes für jeden der zehn möglichen Werte in diesem Digit-Feld angibt. Diese Histogramme werden dann zum Identifizieren und Gruppieren der Digit-Felder verwendet, welche in getrennte Arrays gesplittet werden sollten. Die Arrays werden dann geprüft, um zu sehen, ob die Wiederholungstransformation effizient ist, und dann kann der Codierungsaufwand unter Verwendung der Simulatoreinrichtung der mittleren Ebene abgeschätzt werden.
8 ist eine Flussdiagrammübersicht des Integer-Codierers der mittleren Ebene. Array-Daten werden bei dem Schritt 101 eingegeben, und zuerst durch eine Bereichszuordnungseinrichtung bei dem Schritt 103 verarbeitet. Zusätzlich zu packende Bits werden bei dem Schritt 105 gespeichert. Aus den sich ergebenden Bereichscodes erfolgt bei dem Schritt 107 eine Ermittlung, ob ein MTF-Codierer zu verwenden ist. Wenn diese Ermittlung bestätigend ist, wird dann der MTF-Codierer bei dem Schritt 109 ausgeführt. Die endgültigen Bereichscodes werden bei dem Schritt 110 dann an den Codierer auf niedriger Ebene geliefert.
Dieser Codierer auf mittlerer Ebene hat die Größe des Alphabetes auf eines zu reduzieren, welches effektiv durch die Codierer auf niedriger Ebene bearbeitet werden kann und diese Funktion in einer Weise auszuführen, welche die Kompression maximiert. Er enthält eine Bereichs-Rückzuordnungseinrichtung (Schritt 103) und eine optionale Nachtransformations-MTF-(Move-to-Front)-Transformation (Schritt 109). Die Bereichscodierung kann eine Positionskomponente in dem Datensatz dahingehend wieder einführen, dass Bereichscodes dazu tendieren können, mit den nahe gelegenen Bereichscodes übereinzustimmen, selbst wenn die ursprünglichen Werte nicht übereinstimmten. Wenn dieses auftritt, wird die MTF-Transformation vor dem Senden an den Codierer auf niedriger Ebene ausgeführt, welcher diese Symbole in den codierten Datenstrom umwandelt. Die Ausgabe des Codierers auf mittlerer Ebene wird an den Codierer auf niedriger Ebene gesendet. Die Simulatoreinrichtung auf mittlerer Ebene kann auch durch Routinen auf hoher Ebene verwendet werden, um Codierungsaufwand abzuschätzen.
Die Bereichs-Rückzuordnungseinrichtung wandelt die Integer-Eingabe in Codeworte um. Jeder Eingabewert wird durch ein einzelnes Codewort dargestellt. Da die Anzahl von Codeworten üblicherweise geringer als die Anzahl möglicher Datenwerte ist, können einige von den Codeworten mehr als einen möglichen Quellenwert repräsentieren. In diesen Fällen zeigt das Codewort einen Bereich von Werten an, und die Bereichs-Rückzuordnungseinrichtung führt eine Bitpackung an einen Offset innerhalb dieses Bereichs aus. Dieses ist eine Standardkompressionstechnik.
Die Standardlösungsansätze haben die Tendenz, vordefinierte Bereichstabellen zu verwenden und ermöglichen dem Codierer auf niedriger Ebene, weniger Bits für die Bereichscodes für die üblichsten Bereiche in dem Datenblock zu verwenden. Das bevorzugte System erzeugt Bereichstabellen, welche für jeden Datenblock optimiert sind, und reduziert signifikant die Anzahl von Bits, die zum Packen der Offsets innerhalb der Bereiche verwendet werden. Beispielsweise könnte eine feste Bereichstabelle einen Bereich definieren, der bei 0x10000 beginnt und bei 0x20000 endet, was 16 Bit erfordert, um den Offset für jeden Eintrag in diesen Bereich zu packen. Aber alle Einträge in diesem Bereich können den Wert 0x18000 haben. Das bevorzugte System würde dies entdecken, und einen speziellen Bereich für diesen Wert erzeugen, welcher keine Extrabits benötigt.
Das System verwendet den Begriff "magische Werte", um spezifische Werte zu beschreiben, welche mit hoher Häufigkeit in dem Datenblock auftreten. Diesen Werten wird eine Spezialbehandlung gegeben, da sie ohne Verwendung zusätzlicher Bits unabhängig davon, ob sie in dem Datenbereich auftreten oder nicht, gepackt werden sollten. Für die restlichen "nicht-magischen" werden optimierte Bereiche erzeugt, welche sich an die Verteilung der Werte innerhalb des Datenblockes anpassen.
Der erste Schritt besteht in der Ermittlung einer Zieltabellengröße. Jeder Tabelleneintrag erfordert einen festen Overhead sowohl in der Bereichs-Rückzuordnungseinrichtung als auch in dem Codierer auf niedriger Ebene. Kleinere Datenblöcke sollten eine kleinere Tabelle verwenden. Aber Datenblöcke mit einem großen numerischen Be reich können mehr Bits unter Verwendung besserer Tabellen sparen, so dass die Größe der Tabelle ebenfalls für den Datenbereich angepasst wird. Die Sollanzahl von Einträgen für jeden Tabelleneintrag, welche als die min_freq bezeichnet wird, wird dann berechnet als: min_freq = num_entries/target_tab_size; (4)
Die endgültigen Tabellengrößen werden sich erheblich von den Sollwerten unterscheiden, aber dieses ergibt einen in dem Tabellenaufbau zu verwendenden Wert. Ein sortiertes Histogramm, welcher die Häufigkeit jedes Wertes in dem Datenblock angibt, wird anschließend erzeugt. Die Tabelle wird in zwei Abschnitten aufgebaut: einen für positive Werte und einen für negative Werte. Die allgemeine Prozedur für die Erzeugung einer adaptiven Bereichstabelle wird für die positive Tabelle beschrieben:

– Start bei dem kleinsten Wert mit einer frq > 0 und Bezeichnen dieses als "Basis" unseres ersten Bereiches. Wenn dessen Häufigkeit kleiner als min_frq ist, Erweitern des Bereichs durch Hinzufügen eines weiteren Wertes dazu bis die Gesamthäufigkeit der in dem Bereich enthaltenen Werte > min_frq ist. An diesem Punkt hat der Bereich die Größe range_size = last_val – base (5)
– Ermitteln der Anzahl der Bits nbits, die zum Ausdrücken aller möglichen Werte in dem Bereich benötigt werden.
– Erweitern des Bereichs auf die Größe 1 << nbits. Der nächste Bereich beginnt bei base[i + 1] = base[i + 1] + (1 << nbits[i]) (6)
– Überspringen der Histogrammwerte zum Erhalten des nächsten Wertes >= base[i + 1], und dann Erzeugen des nächsten Bereiches. Die negative Tabelle wird auf dieselbe Weise beginnend bei –1 und Bewegung zu größeren negativen Werten erzeugt.

Beispiel 10
Obwohl dieses den allgemeinen Lösungsansatz einführt, wird dieses zur Behandlung der magischen Werte modifiziert. Jeder Wert, dessen frq > min_frq ist, ist ein magischer Wert, welcher einen getrennten Tabelleneintrag erhalten sollte, der keine zusätzlichen Bits erfordert. Wenn einer während des Vorgangs des Aufbaus der Tabelle angetroffen wird, wird er einer speziellen Liste hinzugefügt, welche für die magischen Werte geführt wird. Der Datenbereich wird so verdichtet, dass die magischen Werte aus dem Bereich entfernt werden:
Wenn min frq = 10 ist:
Wenn min_frq in diesem Beispiel 10 war, und ein neuer Bereich bei dem Wert 100 zu starten war, ist der Wert '102' ein magischer Wert, und wird aus dem Bereich, dessen Basis 100 ist, gelöscht. Alle vier Werte die in diesem Bereich bleiben (100, 101, 103, 104) werden dann unter Verwendung eines 2-Bit Offsets ausgedrückt.
Die Bereichstabellen können unter Verwendung der Liste magischer Werte und der eBits (der Anzahl zusätzlicher Bits zum Codieren der Offsets) für jeden Bereich rekonstruiert werden. Zum Codieren der eBits wird ein 2-Bit Code verwendet, dessen Werte die Offsets von dem vorhergehenden eBit darstellen, für jeden Eintrag erzeugt:
wobei der Offset als ein vorzeichenbehafteter Wert unter Verwendung einer Anzahl zusätzlicher Bits gepackt wird.
Vier von diesen Codes werden in einen 1-Byte Wert gepackt, und dann ein Codierer auf niedriger Ebene mit einer vordefinierten statischen Tabelle verwendet, um die 1-Byte Codeworte zu codieren. Ein Probenintervall wird definiert, und der Wert der Extrabits (die maximale Anzahl der für jeden Offset erforderlichen Bits) wird für jede Probengruppe angepasst. Mehrere Sätze von Codierungstabellen auf niedriger Ebene werden ebenfalls erzeugt, und die Codetabelle wird anhand des Aktivitätsanteils (veränderte Gesamtbits) in einer Probengruppe ausgewählt.
Zum Codieren der Liste magischer Werte wird die Liste sortiert und in Offsets zu dem vorhergehenden Wert umgewandelt. Diese Offsets werden dann unter Verwendung von 2-Bit Codes codiert:
Vier von diesen 2-Bit Codes werden in ein 1-Byte Wort gepackt und dann wird dieses Wort unter Verwendung einer vordefinierten statischen Tabelle codiert, die gemäß dem letzten 2-Bit Code in dem vorherigen Wort ausgewählt wird. Die Übergrößen-Offsets werden unter Verwendung einer statisch definierten base + offset Bereichstabelle definiert. Die Bereichscodes werden unter Verwendung des Codierers auf niedriger Ebene mit einer Tabelle codiert, die gemäß dem vorherigen Bereichscode ausgewählt wird. Die Offsets werden Bit-gepackt.
Die Bereichscodes können manchmal Positions-korreliert sein: ähnliche Codes können nahe aneinander gruppiert sein. In derartigen Fällen können Bearbeitungen der Codes durch eine MTF-Transformation die Codierung in dem Codierer auf niedriger Ebene verbessern. Dieses wird unter Verwendung eines Probenblockes von Codes vor dem Senden der Codes an den Codierer auf niedriger Ebene geprüft. Die Transformation wird dann angewendet, wenn sie effizient ist.
Die Modellauswahleinrichtung auf hoher Ebene benötigt oft einen Schätzwert des Codierungsaufwandes eines Blockes, um zwischen konkurrierenden Algorithmen auf hoher Ebene auszuwählen. Die Simulatoreinrichtung empfängt einen Block von Probenwerten sowie die Größe des vollen Datenblockes. Sie verwendet die Probenwerte, um einen Schätzwert des Aufwandes der Codierung des vollständigen Datenblockes zu erzeugen. Wenn diese Schätzung ausgeführt wird, werden mehrere Modifikationen in den Betrieb des Codierers der mittleren Ebene vorgenommen:

– Abschätzen des Aufwands der Codierung der Tabellen unter Verwendung eines auf der Anzahl von Einträgen und der Gesamtanzahl von für die gesamte Tabelle veränderten Bits basierenden Modells;
– Abschätzen des Aufwands der Codierung der Bereichscodes aus den Häufigkeiten jedes Codes unter Verwendung einer schnellen Approximation der Standardgleichung:
wobei: freq[i] = Häufigkeit des Codes (i) ist tot_freq = Gesamthäufigkeit aller Codes ist log₂ = der Logarithmus auf der Basis 2 ist cost = Anzahl der Bits ist, die zum Codieren des Blockes benötigt werden;
– Berechnen des Aufwandes der benötigten Extrabits zum Codieren der Offsets innerhalb der Bereiche; und
– Löschen des MTF der mittleren Ebene

ÄQUIVALENTE
Nachdem diese Erfindung unter Bezugnahme auf ihre bevorzugten Ausführungsformen im Detail dargestellt und beschrieben wurde, dürfte es sich für den Fachmann auf die sem Gebiet verstehen, dass verschiedene Änderungen in Form und Details darin ohne Abweichung von dem Schutzumfang gemäß Definition durch die beigefügten Ansprüche vorgenommen werden können. Der Fachmann auf diesem Gebiet wird erkennen oder in der Lage sein, unter Anwendung von nicht mehr als routinemäßigem Experimenten viele Äquivalente für die hierin im Detail beschriebenen spezifischen Ausführungsformen der Erfindung festzustellen. Derartige Äquivalente sollen in dem Schutzumfang der Ansprüche mit enthalten sein.

Claims

Computerisiertes Verfahren zum Codieren von Daten mit einer Vielzahl von Datenkomponenten, wobei jede Datenkomponente in ein Datenfeld eines zugeordneten Datentyps gemäß einem organisierten Format strukturiert ist, umfassend: aus einer Quellendatenstruktur mit einem organisierten Format Erzeugen einer Vielzahl von Blöcken auf der Basis der Quellendatenstruktur, wobei jeder Block einem spezifischen entsprechenden Datenfeld zugeordnet wird; Untergliedern jeder Datenkomponente aus der Quellendatenstruktur in einen von der Vielzahl der Blöcke auf der Basis des Datenfeldes der Datenkomponente; für jeden Block: Auswählen eines Kompressionsalgorithmus aus einer Vielzahl von Kandidatenkompressionsalgorithmen auf der Basis des Datentyps des dem Block zugeordneten Datenfeldes; Anwenden des ausgewählten Kompressionsalgorithmus, um jede Datenkomponente in dem Block zu komprimieren; und Kombinieren der komprimierten Datenkomponenten aus der Vielzahl der Blöcke in eine codierte Datenstruktur.
Verfahren nach Anspruch 1, wobei die Quellendatenstruktur in einem ersten Format organisiert ist, und das Untergliedern das Umwandeln der Quellendatenstruktur in ein zweites Format umfaßt.
Verfahren nach Anspruch 2, wobei das Umwandeln das Sammeln ähnlicher Daten aus der Quellendatenstruktur in entsprechende Blöcke umfaßt.
Verfahren nach Anspruch 2, wobei das Umwandeln das Erzeugen eines Kompressionsmodells auf der Basis des ersten Formats umfaßt.
Verfahren nach Anspruch 1, wobei die Kompressionsalgorithmen ferner auf der Basis der Menge von Daten in dem entsprechenden Block ermittelt werden.
Verfahren nach Anspruch 1, wobei ein Kompressionsalgorithmus an den entsprechenden Block angepaßt wird.
Verfahren nach Anspruch 1, wobei das Auswählen das Erzeugen einer speziell angepaßten Transformation umfaßt.
Verfahren nach Anspruch 1, welches ferner das Zurückgewinnen der Quellendatenstruktur aus der codierten Datenstruktur umfaßt.
Gegenstand, bestehend aus: einem maschinenlesbaren Medium; einem Satz von in dem maschinenlesbaren Medium aufgezeichneten Instruktionen zum Implementieren eines Datencodierungsnetzwerkes mit einer Vielzahl von Datenkomponenten, wobei jede Datenkomponente in ein Datenfeld eines zugeordneten Datentyps gemäß einem organisierten Format strukturiert ist, umfassend: aus einer Quellendatenstruktur mit einem organisierten Format Erzeugen einer Vielzahl von Blöcken auf der Basis der Quellendatenstruktur, jeden Block zugeordnet zu einem spezifischen entsprechenden Datenfeld; Untergliedern jeder Datenkomponente aus der Quellendatenstruktur in einen von der Vielzahl der Blöcke auf der Basis des Datenfeldes der Datenkomponente; für jeden Block: Auswählen eines Kompressionsalgorithmus aus einer Vielzahl von Kandidatenkompressionsalgorithmen auf der Basis des Datentyps des dem Block zugeordneten Datenfeldes; Anwenden des ausgewählten Kompressionsalgorithmus, um jede Datenkomponente in dem Block zu komprimieren; und Kombinieren der komprimierten Datenkomponenten aus der Vielzahl der Blöcke in eine codierte Datenstruktur.
Gegenstand nach Anspruch 9, wobei die Quellendatenstruktur in einem ersten Format organisiert ist, und das Untergliedern das Umwandeln der Quellendatenstruktur in ein zweites Format umfaßt.
Gegenstand nach Anspruch 10, wobei das Umwandeln das Sammeln ähnlicher Daten aus der Quellendatenstruktur in entsprechende Blöcke umfaßt.
Gegenstand nach Anspruch 10, wobei das Umwandeln das Erzeugen eines Kompressionsmodells auf der Basis des ersten Formats umfaßt.
Gegenstand nach Anspruch 9, wobei die Kompressionsalgorithmen ferner auf der Basis der Menge von Daten in dem entsprechenden Block ermittelt werden.
Gegenstand nach Anspruch 9, wobei ein Kompressionsalgorithmus an den entsprechenden Block angepaßt wird.
Gegenstand nach Anspruch 9, wobei das Auswählen das Erzeugen einer speziell angepaßten Transformation umfaßt.
Gegenstand nach Anspruch 9, welcher ferner das Zurückgewinnen der Quellendatenstruktur aus der codierten Datenstruktur umfaßt.
Vorrichtung zum Codieren von Daten mit einer Vielzahl von Datenkomponenten, wobei jede Datenkomponente in ein Datenfeld eines entsprechenden Datentyps gemäß einem organisierten Format strukturiert ist, aufweisend: eine Vielzahl von Blöcken basierend auf und abgeleitet von einer Quellendatenstruktur eines organisierten Formates, wobei jeder Block einem spezifischen entsprechenden Datenfeld zugeordnet ist; eine Untergliederungseinrichtung, zum Untergliedern jeder Datenkomponente aus der Quellendatenstruktur in einen von der Vielzahl von Blöcken auf der Basis des Datenfeldes der Datenkomponente; ein Auswahlsystem zum Auswählen eines Kompressionsalgorithmus für einen Block aus einer Vielzahl von Kandidatenkompressionsalgorithmen auf der Basis des Datentyps des dem Block zugeordneten Datenfeldes; eine Codierungseinrichtung zum Anwenden des ausgewählten Kompressionsalgorithmus, um jede Datenkomponente in dem Block zu komprimieren und um die kombinierten Datenkomponenten aus der Vielzahl von Blöcken in eine codierte Datenstruktur zu kombinieren.
Vorrichtung nach Anspruch 17, wobei die Untergliederungseinrichtung gleiche Daten aus der Quellendatenstruktur in entsprechende Blöcke untergliedert.
Vorrichtung nach Anspruch 17, wobei das Auswahlsystem auf die Daten in dem Block anpaßbar ist.
Vorrichtung nach Anspruch 17, welche ferner ein Rückgewinnungssystem für die Rückgewinnung der Quellendatenstruktur aus der codierten Datenstruktur enthält.