Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

17.10.1980

DB-Relationenmodell einfach in der Konstruktion und hochtrabend im Fachchinesisch: DatacomDB im heterogenen Verbund MÜNCHEN - Maßstab für den Wert eines Datenbanksystems ist der Grad der Unabhängigkeit der Daten von den jeweiligen Anwendungen. Diese Auss

DB-Relationenmodell einfach in der Konstruktion und hochtrabend im Fachchinesisch:

Datacom/DB im heterogenen Verbund

MÜNCHEN - Maßstab für den Wert eines Datenbanksystems ist der Grad der Unabhängigkeit der Daten von den jeweiligen Anwendungen. Diese Aussage schreibt ADR-Vertriebsleiter Wolfgang Mudter dem DV-Papst James Martin zu und bekennt sich rückhaltlos zu ihr. ADR (Applied Data Research), Düsseldorf/Stuttgart, informierte in München ein gutes Dutzend Zuhörerfast durchweg schon ADR-Kunden - über die Datacom-Produktreihe.

Zunächst bot Mudter einen kurzen Abriß der Entwicklungsgeschichte der Datenbanken (s. Kasten). Anschließend daran kritisierte er, dem herkömmlichen Datenbank-Anwender müsse allzeit die Struktur seines DB-Systems vor Augen sein, um Programme entwickeln zu können (ausgenommen, er arbeite mit ADRs Datacom/DB). Mudter führte in diesem Zusammenhang die TBLR-(Top Bottom Left Right-)Navigationsregel in hierarchischen und die Gefahr "unendlich langer" Pointer-Ketten in Netzwerk-Datenbanken als Beleg an. Eine relationale Datenbank hingegen sei eine ausgesprochen einfache Konstruktion - im Gegensatz zur Aufgeblasenheit des üblicherweise verwendeten" Vokabulars, wo die Reihen einer zweidimensionalen Tabelle zu "Touples", die Spalten zu "Domains" würden. Sie stelle eine Sammlung von Benutzerdaten in "Flat Files" dar, die sich in logische Flat Files projizieren ließen, und wo durch "Joint Function" aus mehreren Dateien ein logischer Satz gebildet werden könne.

In Datacom/DB - so Mudter ist das Relationenmodell nicht vollständig realisiert (nur bedingte Joint Function), da die erforderliche Speicherform (Assoziativspeicher) noch nicht verfügbar ist und daher die Adressierung über den Speicherinhalt per invertierter Liste simuliert werden muß. Mudters weitere Produktskizze von Datacom/DB:

- Alle Sätze werden mit dem gleichen Lesebefehl gelesen.

- DB-Design und -Tuning beschränken sich auf rein sequentielles Arbeiten.

- Die Datenbank-Definition besteht aus dem Definieren

- der Datei (beispielsweise mit Datenkomprimierung und Logging),

- der Schlüssel (beispielsweise der Felder und ihrer Reihenfolge,

- der Datenelemente (beispielsweise der Feldnamen).

- Pro System sind 240 Datenbanken definierbar.

- Das Anwendungsprogramm sieht "seine" Datenbank in einem "File Table", das aus Dateien der diversen Datenbanken besteht. Es verlangt von Datacom/DB bestimmte Datenfelder in einer bestimmten Reihenfolge, die das DB-Managementsystem aus der "strukturlosen" Datenbank holt.

Eine solche Datenbank, meinte Mudter, sei kein Privileg für Hardware-Jumbos, sondern von einer 370-115 an aufwärts für DOS/OS/ MVS-Betriebssysteme verfügbar. Die Kontrolle der Sätze geschehe über Before- und After-lmages, die auf einer Platten-Online-Logdatei gespeichert seien; Datacom/DB, unterstrich Mudter, sei die einzige am Markt erhältliche Datenbank mit echtem Multi-Threading. In einem konkreten Fall habe die Reorganisation einer Datacom-Datenbank mit vier Millionen Sätzen etwa 40 Minuten gedauert.

Besonders bemerkenswert aber sei - und hier stehe ADR "an der vordersten -Front der Innovation" -, daß Datacom/DB in der "D-Net"-Version als verteilte Datenbank auf verschiedensten Rechnersystemen implementierbar sei, sofern auf allen Verbundrechnern ADRs Datadictionary verwendet werde. Ein Data Dictionary, forderte Mudter sollte alle

Informationen eines Gesamtunternehmens enthalten ihre Beschreibungen (Strukturen ) sowie Restriktionen und logische Querverweise (Many-to-many-Beziehungen).

Als Hauptaufgabe eines Data Dictionary bezeichnete es Mudter, den Umfang notwendig werdender Änderungen zuverlässig vorauszusagen.

Zum Einsatzbereich eines TP-Monitors - und hier speziell von Datacom/ DC - meinte Mudter, er müsse das Spektrum ausfüllen, das sich zwischen den benutzerorientierten Zugriffsmethoden wie BTAM und den datenorientierten a la VSAM zeige. Dies geschehe zum einen über die "Line Control", zum anderen über die "File Control", wobei beide von der "Task Control" gesteuert würden, die die Nachrichten den einzelnen Tasks zuordne.

Bevor eine Nachricht zur Task Control geht, hat bei Datacom/DC ein Preprocessor dafür gesorgt, daß sich nur solche Tasks im Speicher befinden, die auch wirklich benötigt werden. Mudters Ausführungen galten anschließend "Dataquery", der - wie er sagte - interpretativen Abfragesprache für den Laien. Mudter nannte auch Zahlen: 127 200 Mark kostet eine Datacom/DB-Datenbank (DOS-Version), ferner Datacom/DC 51000 Datadictionary 37 500 und Dataquery 22 500 Mark - letzteres setzt voraus, daß Datadictionary installiert ist.