 |
|
|
|
| Während relationale Datenbanken mit Tabellen nur eine Form
der Datenspeicherung kennen, verwenden die Applikationen der Dialog Data zahlreiche
verschiedene Verfahren zur Speicherung von Daten auf externen Massenspeichern. |
|
 |
Mehrplatzfähige Indexdateien |
| |
Parametergesteuerte Zugriffsroutinen |
| |
Automatische Reorganisation |
| |
Änderung von Stammnummern |
|
|
| Diese Methoden sind für die jeweilige Datenform optimiert
und dafür ausschlaggebend, dass die Verarbeitungen eine extrem hohe Durchsatzrate haben.
Bei Bedarf ist es möglich, statt der speziellen Zugriffsverfahren ein relationales
Datenbanksystem einzusetzen, allerdings gehen damit die Vorteile der optimierten
Dateizugriffe verloren, was die Verarbeitungszeiten um einige tausend Prozent erhöht. |
|
| Grundlegende Zugriffsverfahren |
| Neben den unter UNIX verfügbaren Standardzugriffstechniken zur
Verarbeitung von Dateien in sequentieller Form oder im Direktzugriff stützt sich das
Dateimanagement auf ein von der Dialog Data entwickeltes Zugriffsverfahren für
Indexdateien, das eine Reihe von Vorteilen in sich vereinigt. |
|
| Indexdateien |
| Die Routinen sind äußerst effizient (wir kennen keine
schnelleren), flexibel und mehrplatzfähig. Einer der Gründe für die hohe
Leistungsfähigkeit dieser Funktionen besteht darin, dass für diese Art von Dateien weder
ein Mehrfachindex noch doppelte Schlüssel vorgesehen sind, was den Overhead bei allen
Zugriffsformen drastisch reduziert. Im folgenden wird sich zeigen, dass infolge der
speziellen Eigenschaften dieses Systems durch diese Einschränkungen keinerlei Nachteile
entstehen. |
|
| Parametergesteuerte Zugriffe |
| Die Zugriffsroutinen arbeiten völlig parametergesteuert ,
weshalb für alle Arten von Indexdateien unabhängig von der Länge der Datensätze oder
der Schlüssellänge dieselben Routinen verwendet werden können. |
|
| Trennung der Daten vom Index |
| Die Funktionen verwenden eigene Dateien für Index und Daten,
wobei das Datenfile keinerlei Steuerinformation außer einer Verkettung der
gelöschten Datensätze enthält. Es können daher alle Datensätze auch im Direktzugriff
oder sequentiell verarbeitet werden. |
|
| Interne Reorganisation |
| Für die Indexdatei wird ein ausgeglichener B*-Baum verwendet,
der sich selbst permanent reorganisiert und damit jederzeit den Zugriffsaufwand
minimal hält. Gelöschte Datensätze werden für spätere Neueinfügungen wiederverwendet.
Dateien mit häufigem Löschen und Einfügen belegen daher nicht unnötig Speicherplatz
und müssen auch nicht reorganisiert werden. |
|
| Flexible Funktionen |
| Schlüssel und Datensatz sind für das Indexdateisystem zwei physisch
voneinander unabhängige Objekte, was eine Reihe von Vorteilen bringt: Zum Beispiel
muss sich der Schlüssel nicht im Datensatz befinden, was bei speziellen Anwendungen auch
verwendet wird. |
|
| Index ohne Daten |
| Ein weiterer Vorteil dieses Konzepts besteht darin, dass
Indexdateien
ohne Datenfile erstellt werden können. Damit können Verzeichnisse angelegt werden,
die nur aus einem Schlüssel bestehen, ohne dass ein Platz für die Daten (mit denselben
Informationen wie im Schlüssel) auf der Platte verschwendet wird. |
|
|
| Interne
Indizierung |
| Besondere Anforderungen an die Optimierung stellen jene
Fälle, bei denen die vom Anwender gewünschten Identifikationsbegriffe einen wesentlich
größeren Wertebereich umfassen als tatsächlich benötigt wird: Sechsstelligen
Kontonummern erlauben im Sachbuch eine Million Konten, obwohl in der Praxis kaum mehr als
300 oder 500 benötigt werden. Wenn sich jeder Einwohner von Österreich 300.000 Autos
kauft, reicht das derzeit verwendete KFZ-Nummernsystem leicht aus, um jedem Kraftfahrzeug
ein eindeutiges Kennzeichen zuzuweisen. |
|
| Optimierung der
Schlüsselbegriffe |
| Solche "überdimensionierte"
Identifikationsbegriffe lassen den Platzbedarf und den Zugriffsaufwand in vielen
Anwendungen deutlich ansteigen, ohne dass damit irgendwelche Effekte erzielt werden
könnten. Die Kontonummer ist beispielsweise in jedem einzelnen Buchungssatz vorhanden,
mit Gegenkonto meist sogar zweifach. Ebenso wird jeder Schlüssel in Indexdateien auf
diese Weise unnötig vergrößert. |
|
| Interne Verknüpfungen |
| Die meisten Stammdaten werden daher intern indiziert, also
mit kürzeren Identifikationsnummern versehen, die der extern verwendeten Nummer über
eine eigene Verzeichnisdatei zugeordnet wird. Alle Daten werden unter der internen Nummer
gespeichert, was nicht nur zu einer Reduzierung des Speicheraufwands und der
Schlüsselgröße in Indexdateien führt, sondern auch den Zugriffsaufwand drastisch
vermindert. |
|
| Änderung der Stammnummer |
| Daneben erlaubt die interne Indizierung auf einfache Weise
eine Änderung der Stammnummern: Es wird im Verzeichnis der externen Nummern nur die alte
Nummer gelöscht und die neue externe Nummer eingetragen. Die intern verwendete Nummer
bleibt davon in allen Datensätzen unberührt. Eine Reorganisation des Nummernsystems in
der Kostenrechnung ist damit in einer Stunde erledigt. Zudem hat man die Wahl, ob eine
Änderung der Nummern rückwirkend gelten soll oder nur ab dem Zeitpunkt der Änderung. |
|
| Mehrfachindex |
| Es können zu einem Datenfile beliebig viele
Indexdateien angelegt werden, womit sich die oben erwähnte Einschränkung bezüglich
eines Mehrfachindex in einen Vorteil verwandelt: Einerseits ist die Anzahl der
Indexdateien nicht begrenzt, während Systeme mit Mehrfachindex meist eine Obergrenze für
die Anzahl der zusätzlichen Indizes festlegen. Dazu wird in einer bestimmten Anwendung
meist nur eines der verfügbaren Schlüsselverzeichnisse verwendet. Hier ist der Zugriff
über eine eigene Indexdatei wesentlich effizienter möglich als innerhalb eines
Mehrfachindexsystems. |
|
|
 |
Softwarestandards |
|
 |
Datenmanagement |
|
| Spezielle
Zugriffsformen |
 |
|
|
|
Software
