P8000/WEGA/contrib/ingres/dbs/tmp/ingres.mm

360 lines
15 KiB
XML
Executable File

.SA 1
.nr Hy 1
.HC ^
.nr Pt 2
.nr Oc 1
.DS C
.B "INGRES - KOMPATIBLE DATENBANKSYSTEME"
B.-M. Paschke
J. Wenzlaff
.DE
.H 1 Einleitung
Datenbanken sind Systeme zur Beschreibung, Speicherung und Wiedergewinnung
von umfangreichen Datenmengen, die von mehreren Anwendungsprogrammen
genutzt werden. Sie befreien den Nutzer vom Umgang mit der physischen
Struktur der Daten.
Bei mehrnutzerfaehigen Systemen regeln sie den parallelen Zugriff auf
den gleichen Datenbestand und gewaerleisten die Wiederherstellbarkeit
der Datenintegritaet bei Systemfehlern.
.br
Eine Aenderung der Datenbankstruktur erfordert nicht in jedem Fall eine
Aenderung der Anwenderprogramme.
.br
Ist die Datenbanksprache
in eine hoehere Programmiersprache eingebettet, wird dem Programmierer
die Moeglichkeit gegeben, die Dateiarbeit rechnerunabhaengig zu
gestalten. Dadurch wird die Portabilitaet von Programmen wesentlich
verbessert. Entwicklungs- und Zielrechner muessen nicht identisch sein.
.P 1
INGRES ist international eines der bedeutendsten
Datenbanksysteme (DBS).
Es wird von sieben der zehn groessten Industrieunternehmen der USA
benutzt und ist mit einem Markt^anteil von 36 Prozent /1/
.FD 10 1
.FS /1/
UNIX MAGAZIN 5/88 S. 57-58
.FE
Marktfuehrer bei
relationalen Datenbanksystemen fuer VAX-Rechner. In der BRD wurde 1987
eine INGRES-Benutzergruppe /2/
.FD 10 1
.FS /2/
unix/mail 4/87 S. 12
.FE
mit mehr als 50 Grossanwendern gegruendet.
.br
Es kann eingeschaetzt werden, dass es sich bei INGRES um das
fortschrittlichste relationale DBS handelt. 50 Prozent der Gewinne von
Relational Technology (RTI) werden in die weitere Forschung investiert.
.H 1 "Verfuegbarkeit von INGRES-kompatiblen DBS in der DDR"
In der DDR steht z. Z. fuer alle Rechner mit einer Verarbeitungsbreite
>= 16 Bit ein INGRES-kompatibles DBS zur Verfuegung.
.br
Es handelt sich dabei in allen Faellen um Systeme, die im wesentlichen von
J. Wenzlaff aus dem Zentralinstitut fuer Kybernetik
und Informationsprozesse (ZKI) erstellt wurden.
Ihm steht der Quelltext des Datenbanksystems INGRES
zur Verfuegung, der von ihm auch staendig gewartet und erweitert wird.
Sie repraesentieren,
im Vergleich zum INGRES, einen Stand von 1984. Alle Systeme sind
mehrplatzfaehig.
.DS 3
Rechner Betriebssystem Name des DBS
---------------------------------------------------------
BC 5120.16 MUTOS 8000 ING_DB
A 7150, EC 1834, DCP INDES
IBM XT / AT MS-DOS INDES
VENIX, XENIX ING_DB
P 8000 WEGA ING_DB
K 1630, SM 4, I 100 MUTOS ING_DB
SM 1420, SM 52/11 UNIX ING_DB
HP 9000 HP-UX ING_DB
AT 386 XENIX 386 ING_DB
K 1840, MUTOS 1800 DABA 32
VAX-Rechner ULTRIX ING_DB
UNIX (BSD 4.x) ING_DB
SVP bzw. VMS Entwicklung geplant
ESER-Rechner VMX ING_DB
PSU z.Z. in Entwicklung
.DE
Der Vertrieb erfolgt z. Z. durch verschiedene Einrichtungen. ING_DB wird vom
ZKI, INDES von der NVA und DABA 32 vom Kombinat ROBOTRON /3/
.FS /3/
Neue Technik im Buero 3/88 S. 84-86
.FE
angeboten.
Es ist vorgesehen, dass alle Systeme in Zukunft vom Kombinat
ROBOTRON vertrieben werden.
Entsprechende Verhandlungen stehen kurz vor dem Abschluss.
.H 1 "Moeglichkeiten zur Datenuebernahme aus anderen Systemen"
Zur Uebernahme von Daten aus anderen Systemen steht ein leistungsfaehiges
Kopierkommando zur Verfuegung. Es ermoeg^licht nicht nur die Uebernahme
von Daten aus ASCII-Dateien, sondern auch das Ueberspielen von
Integer- bzw. Gleitkommazahlen.
Zur Uebernahme von dBASE-Dateien wird in Kuerze ein spezielles Kopierprogramm
zur Verfuegung stehen.
.br
Da die Moeglichkeit besteht, Datenbankanweisungen in C-Programme zu
integrieren (siehe Abschnitt Programmierung), koennen Daten problemlos
in jedes beliebige Format konvertiert werden.
.H 1 "Programmierung und Arbeit mit der Datenbank"
Zur Nutzung der Datenbank stehen verschiedene Nutzerschnittstellen
zur Verfuegung.
.DS I
QUEL - QUEry Language
EQUEL - Embedded QUEL interface to C
AMX - Access Method - an eXtended interface
RC, RG - ReportCompiler, ReportGenerator
.DE
Die Sprache QUEL wird nicht nur fuer Anfragen an die Datenbank benutzt,
sie ermoeglicht auch jegliche Manipulationen in der Datenbank.
Die Query-Kommandos werden ueber einen interaktiven Terminal-Monitor
eingegeben, dann an einen Makro-Prozessor weitergeleitet und gelangen von
dort zum Datenbanksystem.
.br
Es besteht die Moeglichkeit, den Monitorpuffer durch einen beliebigen
im Betriebssystem verfuegbaren Texteditor zu bearbeiten. Weiterhin koennen Kommandofolgen in einer
Datei abgelegt und jederzeit in den Monitorpuffer geladen werden.
.br
Da mehrere Kommandos zu einer Query zusammengestellt werden koennen,
Eingaben und Verzweigungen moeglich sind, besteht mit QUEL bereits
die Moeglichkeit der Programmierung.
.P 1
Da aber viele Anwendungen den Einsatz komplexerer Programme erfordern,
wird mit EQUEL die Moeglichkeit bereitgestellt, QUEL-Kommandos
in C-Programme zu integrieren. Dabei stehen alle QUEL-Kommandos zur
Verfuegung. Variable Angaben in den EQUEL-Kommandos koennen aus
C-String-Variablen gelesen werden. Das Ergebnis eines retrieve-Kommandos
wird in C-Variablen abgelegt.
Damit besteht keine Einschraenkung bei der Nutzung der Datenbank
auf eine reine Datenbanksprache.
.P 1
Fuer sich staendig wiederholende Aufgaben mit der gleichen Datenbank
steht der AMX-Compiler zur Verfuegung. Mit ihm koennen sehr schnelle und
kurze Programme erstellt werden, da die Zugriffsmethoden des DBS
fest in die Programme integriert werden. Die Auswertung des Aufbaus
der einzelnen Relationen (Tabellen) erfolgt bereits waehrend der Uebersetzung, so
dass zur Laufzeit nicht mehr das DBS benoetigt wird. Dies hat
zur Folge, das AMX-Programme nach einer Veraenderung der Struktur benutzter
Relationen neu uebersetzt werden muessen.
.P 1
Der Reportgenerator stellt ein leistungsfaehiges Hilfsmittel
zur Aufbereitung von Listen zur Verfuegung. Er benutzt eine
eigene "Programmiersprache", die von einem Programmierer sicherlich
schnell zu erlernen, aber fuer den EDV-Laien nicht handhabbar ist.
Dafuer bietet er alles, was man sich von einem Reportgenerator
wuenscht.
.P 1
Viele relationale Datenbanksysteme stellen ein SQL-Interface zur
Verfuegung. Damit wird der Eindruck erweckt, dass SQL bereits eine
Standardsprache fuer relationale Datenbanken darstellt.
.br
Bei den hier genannten Systemen steht diese Sprache nicht zur
Verfuegung. Die Sprache QUEL ist in seinen wesentlichen Eigenschaften
mit SQL vergleichbar und bietet alle Moeg^lich^keiten einer modernen
Datenbanksprache.
.br
Bender und Bien weisen in ihrem Artikel "Kriterien fuer die Auswahl von
Datenbanksystemen in der Sozialwissenschaft" /4/
.FS /4/
ZA-Informationen 23 (November 1988) S. 113-118 Universitaet zu Koeln
.FE
darauf hin, dass die einzelnen SQL-Pakete nur bedingt kompatibel sind.
Da somit SQL-Programme nur bedingt portabel sind, besteht bis zur
Erarbeitung eines verbindlichen SQL-Standards keine Notwendigkeit
zur Bereitstellung dieser Sprache.
.H 1 "Speicherstrukturen fuer Relationen"
Die Effizienz eines DBS haengt im wesentlichen von den benutzten
Speicherstrukturen ab. Bei den hier genannten Systemen stehen folgende
Speicherstrukturen zur Auswahl:
.DS I
heap - unstrukturiert und ohne Schluessel
isam - index sequentielle Struktur
hash - hash Struktur
.DE
Es besteht fuer alle drei Speicherstrukturen die Moeg^lich^keit,
Zeichenketten in verdichteter Form abzulegen, d. h. nachlaufende
Leerzeichen werden nicht abgespeichert.
.P 1
Zu jeder Relation koennen eine beliebige Anzahl von Sekundaerindizes
bestehen. Diese koennen wieder in einer der drei Speicherstrukturen
organisiert sein.
.P 1
Vom Datenbanksystem wird fuer jede Anfrage der optimale Zugriffspfad
ausgewaehlt.
.H 1 "Grenzwerte und Formate der Domaenen"
Jede Datenbank kann aus einer beliebigen Anzahl von Relationen bestehen.
Die Zahl der gleichzeitig benutzten Relationen wird nur durch das jeweilige
Betriebssystem beschraenkt. Ebenso ist die Groesse einer Relation durch
die maximale Groesse eines Dateisystems auf dem benutzten Rechner
eingeschraenkt.
Die Anzahl der Domaenen (Spalten) fuer eine Relation ist
fuer 16-Bit-Rechner auf
49 bzw. fuer 32-Bit-Rechner auf 128 begrenzt.
Die maximale Laenge der Tupel (Zeilen) betraegt 1010 Bytes.
Fuer die Abspeicherung der Domaenen koennen folgenden Formate gewaehlt
werden:
.DS I
c1 - c255 Zeichenketten von 1-255 Bytes Laenge
i1 1-Byte Integer
i2 2-Byte Integer
i4 4-Byte Integer
f4 4-Byte floating
f8 8-Byte floating
.DE
Numerische Domaenen werden mit Null initialisiert.
Die Behandlung von nicht vorhandenen Werten bleibt dem Nutzer ueberlassen.
.P 1
Die genannten Grenzwerte werden oftmals als zu eng bewertet.
Da die maximale Laenge einer Zeichenkette
auf 255 Bytes beschraenkt ist, erscheint es empfehlenswert, Texte
zeilenweise abzuspeichern bzw. eine Relation mit Textbausteinen
(z. B. Saetzen) anzulegen und ueber einen Schluessel mit anderen
Relationen zu verbinden.
.br
Sollte jedoch jemand mehr als 49 bzw. 128 Domaenen in einer
Relation benoetigen,
ist er in den meisten Faellen gut beraten, wenn er sein Datenbankmodell
noch einmal ueberdenkt. Gegebenenfalls koennen mehrere Relationen
ueber einen Schluessel miteinander verbunden werden.
.H 1 "Zugriffsschutz und Datensicherheit"
Voraussetzung fuer die Benutzung des Datenbanksystems ist ein
Eintrag im Nutzerverzeichnis. Dieser legt auch
die Rechte des Nutzers innerhalb des Datenbanksystems fest.
.br
Fuer Relationen kann der Datenbankadministrator Zugriffsrechte
vergeben. Diese koennen sich auf bestimmte
Kommandos,
Zeitraeume und Terminals beziehen.
Weiterhin ist es moeg^lich, die Rechte der einzelnen Nutzer auf einzelne
Domaenen und datenabhaengig sogar auf einzelne Tupel einzuschraenken.
.P 1
Zur Sicherung der Integritaet der Datenbank bei Systemabstuerzen wird
garantiert, dass jede Veraenderung am Datenbestand zuerst in
eine Protokolldatei geschrieben wird, welches erst nach
erfolgreicher Aenderung
geloescht wird. Fuer den Fall eines Systemabsturzes waehrend einer
Aktu^ali^sie^rung steht ein "restore"-Programm zur Verfuegung, welches die
Integritaet der Datenbank gegebenenfalls wieder herstellt.
.P 1
Da die genannten Systeme mehrplatzfaehig sind, besteht die Notwendigkeit
einer "Gleichzeitigkeitskontrolle". Es wird gesichert, dass bei
Aenderungen in einer Relation die betreffende Seite bzw. die
gesamte Relation fuer diese Zeit gesperrt wird.
.H 1 "Speicherbedarf"
Die Abspeicherung der Daten auf externen Datentraegern erfolgt nach einem
Seitenkonzept. Jede Seite enthaelt Tupel einer Relation und zwar so,
dass jedes Tupel ganz auf einer Seite untergebracht ist.
Der Fuellfaktor einer Seite ist im wesentliche von der gewaehlten
Speicherstruktur abhaengig. Er
kann durch den Nutzer festgelegt werden.
Damit hat der Nutzer die Moeglichkeit, fuer Relationen, in denen keine bzw.
nur wenige Aenderungen zu erwarten sind, einen hoeheren Fuellfaktor anzugeben
und damit den
Speicherbedarf zu beeinflussen.
Als vorteilhaft erweist sich die Tatsache, dass die Daten entsprechend der
gewaehlten Speicherstruktur nach ihrem Hauptschluessel sortiert in den
Dateien abgelegt werden und somit fuer den jeweiligen Hautschluessel
keine sekundaere Indexdatei notwendig ist.
Weiterhin ist darauf hinzuweisen, dass numerische Daten
nicht als Zeichenketten in den Dateien gespeichert werden (wie
es z. B. in dem weit verbreiteten dBASE erfolgt).
.P 1
Ein weiterer Gesichtspunkt bei der Bewertung eines DBS ist der
Hauptspeicherbedarf bei Mehrplatzsystemen, sowie der benoetigte externe
Speicherplatz fuer die Programme des DBS. Bei den hier genannten Systemen
wird ein externer Spei^cher^platz von 1,2 MByte (MS-DOS) bis etwa 2 MByte
(ESER) benoetigt. Es besteht also auch auf kleinen Systemen noch die
Moeglichkeit, Daten abzuspeichern.
.P 1
Der Hauptspeicherbedarf des DBS ist als ausgesprochen gering einzuschaetzen.
Auf einem P 8000 mit einem Hauptspeicher von 1 MByte wurde von 3 Terminals
gleichzeitig ING_DB gestartet. Es konnte dabei keine zusaetzliche Behinderung
der einzelnen Prozesse durch ein notwendiges "swappen" festgestellt
werden. Natuerlich war aber eine Verlangsamung der einzelnen Prozesse
durch die notwendige Resourcenteilung zu bemerken. Ein sinnvolles Arbeiten
war jedoch noch moeglich.
.H 1 "Literatur"
Zum Datenbanksystem ING_DB steht eine umfangreiche, stellenweise
nicht gerade leicht verstaendliche Dokumentation zur Verfuegung. Sie zeichnet
sich dadurch aus, dass insbesondere die Speicherstrukturen
und Zugriffsmethoden des DBS sehr gut dargestellt werden. Die Entscheidung
des Nutzers fuer eine der moeglichen Benutzerschnittstellen wird durch
ein Kapitel ueber die Einbettung von Datenbanksprachen in hoehere
Programmiersprachen erleichtert. Hilfreich erscheint auch die Tatsache,
dass die Arbeitsweise des Makroprozessors ausfuerlich erlaeutert wird.
Dadurch ist diese Dokumentation sehr gut geeignet, die Arbeitsweise
des DBS verstehen zu lernen und beim Entwurf des Datenbankmodells
zu beruecksichtigen.
.P 1
In der Zeitschrift "Neue Technik im Buero", Heft 3/1988 ist ein
Ueberblicksartikel von Gruenhagen (DABA 32 - relationales Datenbanksystem
unter MUTOS 1800) erschienen, der in knapper Form auf die Moeglichkeiten
von DABA 32 eingeht.
.P 1
Zum aktuellen Entwicklungsstand von INGRES ist vom Vogel-Verlag fuer
voraussichtlich April 1989 ein Chip-Sonderheft geplant.
.P 1
Das Buch von Date "A Guide to INGRES" (Addison Wesly 1987) kann
als Standardwerk bezeichnet werden.
.H 1 "Zusammenfassung"
In der DDR steht fuer alle 16- und 32-Bit-Rechner ein INGRES-kompatibles
DBS zur Verfuegung. Alle diese Systeme sind in der Nutzerschnittstelle
und im Leistungsvermoegen vollstaendig identisch.
Der Uebergang zwischen verschiedenen Rechnern
wird dadurch betraechtlich vereinfacht.
Da im ZKI die Quellen fuer das DBS vorhanden sind, kann davon ausgegangen
werden, dass dieses DBS auch fuer jeden exotischen (ROBOTRON-) Rechner
bereitgestellt werden kann. Damit besteht nicht die Abhaengigkeit
vom Import westlicher Systeme.
.br
Die Systeme werden vom ZKI staendig aktualisiert und gewartet.
.br
Die genannten DBS sind sehr leistungsstarke, mehrplatzfaehige
Systeme, die sich vor
allem fuer den professionellen Einsatz eignen. Fuer die Benutzung durch
EDV-Laien koennte man sich eine komfortablere Benutzerschnittstelle
wuenschen. Mit EQUEL- bzw. AMX-Programmen koennen jedoch sehr
leistungsfaehige und benutzerfreundliche Bedienoberflaechen fuer den
jeweiligen Einsatzfall geschaffen werden.
.DS I
Anschrift der Autoren:
B.-M. Paschke
Institut fuer Krankenhaushygiene
des Bereiches Medizin (Charite)
der Humboldt-Universitaet zu Berlin
Otto-Grotewohl-Str.1
Postfach 140
Berlin
1 0 4 0 Tel. 2202411 App. 319
J. Wenzlaff
Zentralinstitut fuer Kybernetik
und Informationsprozesse der
Akademie der Wissenschaften
Kurstrasse 30 - 34
Berlin
1 0 8 0 Tel. 2072 322
.TC