297 lines
13 KiB
Groff
297 lines
13 KiB
Groff
dBase III im Vergleich mit ING_DB 6.3
|
|
_____________________________________
|
|
|
|
J. Wenzlaff
|
|
Zentralinstitut f}r Kybernetik und Informationsprozesse
|
|
der Akademie der Wissenschaften der DDR
|
|
|
|
|
|
|
|
Der Artikel ist nicht gedacht, dBase III mit ING_DB 6.3 zu vergleichen,
|
|
er soll nur die Fragen beantworten, die durch die Einbeziehung von
|
|
ING_DB 6.3 in den dBase III Vergleich durch Dr. W. Grafik und B. Osten
|
|
(siehe /1/) beim Entwickler und bei Anwendern entstanden sind.
|
|
|
|
|
|
EINLEITUNG
|
|
|
|
ING_DB 6.3 wurde am ZKI als portables relationales Datenbanksystem f}r
|
|
16-bit Computer unter UNIX-kompatiblen Betriebssystemen entwickelt.
|
|
Seit Oktober 1988 gibt es auf allen in der DDR g{ngigen Rechnern
|
|
(BC 5120.16, P8000, A 7150, EC 1834, IBM XT/AT, PDP11, K 1630, SM 1420,
|
|
I 100 . ..) lauff{hige Versionen. Alle Versionen sind in der Nutzer-
|
|
schnittstelle und im Leistungsverm|gen vollst{ndig identisch !
|
|
F}r M{rz 1989 ist eine Unterst}tzung f}r 32-bit Computer (K 1820 / 40,
|
|
I 80386, ESER / VMX) vorgesehen.
|
|
Zu dem Datenbanksystem werden ein Datenbankcompiler und ein Report-
|
|
system angeboten. Die Dokumentation kann kostenlos }ber das Institut
|
|
bezogen werden. Informationen zu Systemen unter anderen Betriebssyste-
|
|
men (z.B. MS-DOS) k|nnen beim Entwickler eingeholt werden.
|
|
|
|
|
|
TAFEL 1
|
|
|
|
Relation (in Bytes) dBase ING_DB ING_DB komprimiert
|
|
-------------------------------------------------------------------
|
|
journ 213504 256000 170000 .. 192000
|
|
jotitel 193024 113664 75000 .. 85000
|
|
joausdr 140288 86014 57000 .. 65000
|
|
-------------------------------------------------------------------
|
|
gesamt 546816 455680 302000 .. 342000
|
|
-------------------------------------------------------------------
|
|
ein Schl}ssel (a) 406528 277504 185000 .. 207000
|
|
zwei Schl}ssel (b) 546816 363520 242000 .. 272000
|
|
-------------------------------------------------------------------
|
|
|
|
|
|
DATENFILES
|
|
|
|
Sofort auff{llig wird, da~ erstens das Datenfile der Relation journ in
|
|
ING_DB 6.3 wesentlich l{nger ist (120%) und zweitens die Indexfiles da-
|
|
gegen um Gr|~enordnungen k}rzer (60%) sind.
|
|
|
|
zu1: dBase III speichert die Tupel (Datens{tze) kompakt ab, ING_DB 6.3
|
|
legt sie in sogenannte Seiten (pages). Ein ING_DB 6.3-Tupel darf eine
|
|
Seite nicht }berschreiten, so da~ bei ungl}cklicher Wahl der Tupell{nge
|
|
die Seiten nicht vollst{ndig gef}llt werden k|nnen, das hei~t, Platz
|
|
verschwendet wird. Konkret, eine Tupell{nge zwischen 201 und 253 Bytes
|
|
w}rde bei 1000 Tupel in ING_DB 6.3 immer zu einem file der L{nge von
|
|
256000 Bytes f}hren, in dBase III w}rde die L{nge zwischen 201000 und
|
|
253000 Bytes schwanken. Die Beachtung der Physik der Daten ist zwar
|
|
nicht Bestandteil der Relationentheorie, kann aber bei konkreten An-
|
|
wendungen sehr n}tzlich sein (wenn man Platz sparen will !).
|
|
|
|
zu 2: dBase III geht bei der Indexierung mit externen Speicherplatz
|
|
gro~z}gig um, kein Kommentar.
|
|
|
|
Disskussion: In der Gesamtbetrachtung schneidet ING_DB 6.3 aufgrund der
|
|
k}rzeren Indizes speicherplatzm{~ig besser ab.
|
|
ING_DB 6.3 gestattet die komprimierte Ablage von Tupel auf dem externen
|
|
Speichermedium. Bei den vorliegenden Daten und deren Struktur k|nnte
|
|
der Speicherplatzbedarf entsprechend der Spalte "ING_DB komprimiert"
|
|
reduziert werden.
|
|
Indizes definieren sogenannte Zugriffspfade, Wege auf denen Tupel sehr
|
|
schnell wiedergefunden werden k|nnen. In dBase III mu~ jeder Zugriffs-
|
|
pfad (Schl}ssel) als Index realisiert werden. In ING_DB 6.3 gibt es die
|
|
M|glichkeit, einen Zugriffspfad in die Daten direkt zu integrieren,
|
|
erst alle weitern m}ssen als Index angegeben werden. Aus dieser M|g-
|
|
lichkeit entsteht das Begriffspaar Prim{r- und Sekund{rschl}ssel. Der
|
|
Prim{rschl}ssel ist der direkte Zugriffspfad, der Sekund{rschl}ssel der
|
|
indirekte Zugriffspfad zu den bestehenden Daten. Es k|nnen zu einer
|
|
Relation nur ein Prim{rschl}ssel, dagegen mehrer Sekund{rschl}ssel de-
|
|
klariert werden. Die letzten beiden Zeilen der Tafel 1 geben die
|
|
Gesamtanzahl von Bytes f}r die Relation journ mit einem Zugriffspfad
|
|
}ber die Dom{ne (Spalte oder Feld) titel (a) und mit zwei Zugriffspfa-
|
|
den }ber erstens die Dom{ne titel und zweitens }ber die Dom{nen
|
|
ort_verlag+jahrg+standorte (b).
|
|
Schlu~folgerung: Mit der realen Unterstellung von mindestens einem er-
|
|
forderlichen Schl}ssel (oder mehr) ben|tigt ING_DB 6.3 etwa 2/3 des von
|
|
dBase III ben|tigten externen Speicherplatzes. Bei Textdaten kann durch
|
|
die komprimierte Ablage das Verh{ltnis auf 1/2 gesenkt werden.
|
|
|
|
|
|
LOCATE und PACK in dBase III
|
|
|
|
Ich m|chte mich nicht an der Diskussion beteiligen, ob dBase III ein
|
|
relationales Datenbanksystem ist oder nicht. Die Relationentheorie
|
|
trifft keine Aussage }ber die konkrete Lage von Tupel oder deren Rei-
|
|
henfolge. Ein Zugriff zu einem Tupel }ber eine "Satznummer" ist also
|
|
theoretisch irrelevant, Tupel werden durch die Vorgabe von konkreten
|
|
Werten f}r einzelne Dom{nen selektiert. F}r den Nutzer entsteht der
|
|
Vorteil, da~ er f}r sein Anwendungsmodell keine Lage- oder Reihenfolge-
|
|
probleme ber}cksichtigen mu~. Aus diesem Grund kann in ING_DB 6.3 keine
|
|
Entsprechung f}r die dBase III-Anweisung "LOCATE FOR RECNO() = .." ge-
|
|
funden werden.
|
|
Die dBase III-Anwendung "PACK" dient der Streichung von Tupel, die zur
|
|
L|schung markiert sind. dBase III kennt keine Freispeicherverwaltung,
|
|
neue Datens{tze werden hinten angeh{ngt. Bei Streichungen wird aus
|
|
Gr}nden der nicht vorhandenen Speicherverwaltung, der Satz im L|sch-
|
|
byte als gel|scht markiert. Bei einem Datenbanksystem unter paralleler
|
|
Verwendung mehrer Relationen kann das Zur}ckholen schon gel|schter Da-
|
|
tens{tze die Konsistenz der Datenbank zerst|ren, ist also eine nicht zu
|
|
unterst}tzende Funktion. Der temporale Aspekt dieses Problems, Zur}ck-
|
|
setzen des Datenbestandes auf eine bestimmte Zeit, ist in dBase III
|
|
nicht gemeint, da Ersetzungen und Einf}gungen nicht zur}ckgesetzt wer-
|
|
den k|nnen. ING_DB 6.3 {ndert die Daten direkt, so da~ die DELETE-Zeit
|
|
f}r ING_DB 6.3 mit der DELETE+PACK-Zeit von dBASE III verglichen werden
|
|
mu~.
|
|
|
|
|
|
TESTS
|
|
|
|
F}r die Tests wurden Strukturen und Daten benutzt, die in den folgenden
|
|
TAFELN 2, 3, 4 und 5 dokumentiert sind. Alle Tests wurden mit dem
|
|
Datenbankcompiler AMX implementiert, um Auslagern von Programmen durch
|
|
das Betriebssystem (swap) vorzubeugen. Grunds{tzlich andere Zeiten bei
|
|
Verwendung der Anfragesprache sind bei Unterstellung von gen}gend
|
|
Hauptspeicher nicht zu erwarten, da alle Aktionen den Datenbestand der
|
|
gesamten Relation verwenden. Die ]bersetzungszeit auf dem P8000 lag bei
|
|
75 Sekunden, der Linklauf ben|tigte 45 Sekunden, das entstandene
|
|
Programm ist 33000 Bytes gro~. F}r die Zeitmessung wurde der Systemruf
|
|
time(2) verwendet, die Reihenfolge der Kommandos wurde ge{ndert, um
|
|
bei allen Kommandos mit 1000 Tupel zu arbeiten.
|
|
|
|
|
|
TAFEL 2 (Struktur der Datenbank dbase)
|
|
|
|
Datenbank dbase / DBA ing_db
|
|
|
|
DB parallel verwendbar
|
|
QRYMOD-Unterstuetzung
|
|
Seitengroesse 1024 Bytes
|
|
|
|
Relation Besitzer Typ
|
|
----------------------------------------------------
|
|
journ ing_db Nutzerrelation
|
|
jotitel ing_db Index
|
|
joausdr ing_db Index
|
|
----------------------------------------------------
|
|
|
|
|
|
TAFEL 3 (Struktur der Relation journ)
|
|
|
|
Tupellaenge: 206
|
|
Tupelanzahl: 1000
|
|
Relationentyp: Nutzerrelation
|
|
Indexrelationen: jotitel
|
|
joausdr
|
|
|
|
Domaenname Typ Laenge Schluessel
|
|
--------------------------------------------
|
|
kurztitel c 40
|
|
titel c 90
|
|
ort_verlag c 30
|
|
jahrg c 8
|
|
standorte c 30
|
|
h1 i 2
|
|
h2 i 2
|
|
h3 i 2
|
|
h4 i 2
|
|
--------------------------------------------
|
|
|
|
|
|
TAFEL 4 (Struktur der Indexrelation jotitel)
|
|
|
|
Tupellaenge: 94
|
|
Tupelanzahl: 1000
|
|
Relationentyp: Index auf journ
|
|
|
|
Domaenname Typ Laenge Schluessel
|
|
--------------------------------------------
|
|
titel c 90 1
|
|
tidp i 4
|
|
--------------------------------------------
|
|
|
|
|
|
TAFEL 5 (Struktur der Indexrelation joausdr)
|
|
|
|
Tupellaenge: 72
|
|
Tupelanzahl: 1000
|
|
Relationentyp: Index auf journ
|
|
|
|
Domaenname Typ Laenge Schluessel
|
|
--------------------------------------------
|
|
ort_verlag c 30 1
|
|
jahrg c 8 2
|
|
standorte c 30 3
|
|
tidp i 4
|
|
--------------------------------------------
|
|
|
|
|
|
TAFEL 6 (1000 Tupel)
|
|
|
|
A7150 EC1834 P8000 dBase III-Entsprechung
|
|
-----------------------------------------------------------------------
|
|
COUNT 0:14 0:13 0:23 COUNT
|
|
DELETE 0:24 0:19 0:24 DELETE ALL FOR titel="xxx"
|
|
INDEX1 1:24 1:23 2:12 INDEX ON titel TO jotitel
|
|
INDEX3 1:39 1:36 2:17 INDEX ON ort_verlag + jahrg + standorte
|
|
TO joausdr
|
|
REPLACE 1:05 0:52 0:55 REPLACE ALL titel WITH titel
|
|
SORT1 1:33 1:36 2:43 SORT ON titel TO x
|
|
SORT3 1:35 1:36 2:37 SORT ON titel,ort_verlag,standorte TO x
|
|
SUM1 0:15 0:13 0:23 SUM h1
|
|
SUM5 0:17 0:15 0:28 SUM h1, h2, h3, h4, h1 + h2 + h3 + h4
|
|
-----------------------------------------------------------------------
|
|
|
|
|
|
DISKUSSION (Stichpunkte)
|
|
|
|
1) Der EC 1834 ist auf der Platte etwas schneller als der A 7150.
|
|
|
|
2) Die Zeiten f}r COUNT, SUM1, SUM5 sind rechnerbezogen konstant, SUM5
|
|
dauert etwas l{nger, da die Summation im Gleitkommaformat durchgef}hrt
|
|
wurde und keiner der Rechner einen Gleitkommaprozessor besa~. Die Zeit
|
|
f}r COUNT entspricht der Plattenzeit zum Lesen der 250 KBytes.
|
|
|
|
3) Die Sortierzeiten f}r SORT1 und SORT3 sind rechnerbezogen fast
|
|
identisch. ING_DB 6.3 sortiert immer das gesamte Tupel, so da~ die
|
|
Sortierzeiten unabh{ngig von den vorgegebenen Schl}sseln und nur von
|
|
der Tupelanzahl und Tupell{nge abh{ngig sind, was zu beweisen war.
|
|
|
|
4) Die P8000-Zeiten besitzen einige Besonderheiten, auf den ersten
|
|
Blick erscheint er langsamer. Auf dem A 7150 und dem EC 1834 wurde ein
|
|
neu eingerichtetes file-System verwendet, auf dem P8000 nicht. Bei
|
|
gleicher Ausgangslage w}rde der P8000 die Zeiten vom A 7150 erreichen,
|
|
bzw. umgekehrt. Das kann man sehr deutlich an den Zeiten f}r DELETE er-
|
|
kennen, durch den Lese/Schreibzyklus kann der Vorteil der frischen
|
|
Platte nicht mehr greifen.
|
|
Laut Aussage des P8000-Herstellers entsprechen die Plattenzugriffszei-
|
|
ten des P8000 denen des EC 1834, das konnte nicht best{tigt werden. Der
|
|
neue Plattencontroller des P8000 soll doppelt so schnell werden, so da~
|
|
die Zeiten auf dem P8000 nur besser werden k|nnen.
|
|
|
|
5) Der Sortieralgorithmus von ING_DB 6.3 ben|tigt 40% der Zeit, die
|
|
dBase III auf dem A 7150 ben|tigt bzw. 60% von der auf dem EC 1834.
|
|
Interessant ist die Fragestellung, wie die Sortierzeiten bei wachsenden
|
|
Datenbestand sich entwickeln (siehe dazu TAFEL 7).
|
|
|
|
6) Weiter Interpretationen sollen dem Leser }berlassen werden. F}r die
|
|
Zukunft wird ein echter Vergleich von dBase III mit ING_DB 6.3 unter
|
|
Datenbankaspekten geplant. Dieser Vergleich geht von einem genutzten
|
|
dBase III- Projekt eines Anwenders aus, der dieses Projekt aus inner-
|
|
betrieblichen Gr}nden auf Mehrnutzerbetrieb umstellt und dazu das
|
|
Datenbanksystem ING_DB 6.3 verwendet.
|
|
Gleichzeitig wird dann ein Koppelmodul angeboten, der es gestattet
|
|
dBase II/III-Datenbanken direkt in ING_DB 6.3-Relationen zu verwandeln
|
|
und umgekehrt. F}r die off-line Daten}bertragung geh|rt eine integrier-
|
|
te Software zum direkten Lesen und Schreiben von Disketten im CP/M-
|
|
bzw. MSDOS-Format unter WEGA, MUTOS usw. dazu.
|
|
|
|
7) Dieser Artikel entstand, da aus der Sicht des Autors in oben genann-
|
|
ter Ver|ffentlichung keine Quellenangabe f}r das System ING_DB 6.3 ge-
|
|
macht wurde und ich eine dadurch entstandene Informationsl}cke
|
|
schlie~en wollte.
|
|
ING_DB 6.3 ist eins der wenigen Systeme, die auf vielen Rechnern ver-
|
|
f}gbar sind, das in den Nutzerschnittstellen gegen}ber dBASE III etwas
|
|
spartanisch wirkt, in der Laufzeit (Performance) sich aber deutlich
|
|
qualifiziert. Es besitzt Parallelzugriff auf Datenbanken, Mechanismen
|
|
zur Wiederherstellung der Datenbankintegrit{t und -konsistenz und kann
|
|
f}r gro~e Datenmengen eingesetzt werden. Durch die uneingeschr{nkte
|
|
Lauff{higkeit auf unterschiedlichen Architekturen wird eine portable
|
|
Anwenderprojektierung unterst}tzt und m|glich. Das System wird vom Ent-
|
|
wickler gewartet und weiterentwickelt.
|
|
|
|
|
|
TAFEL 7 (2000 Tupel, ohne Kommentar)
|
|
|
|
A7150 EC1834 P8000 dBase III-Entsprechung
|
|
-----------------------------------------------------------------------
|
|
COUNT 0:29 0:27 0:50 COUNT
|
|
DELETE 0:46 0:41 0:54 DELETE ALL FOR titel="xxx"
|
|
INDEX1 2:30 2:30 3:54 INDEX ON titel TO jotitel
|
|
INDEX3 3:01 2:56 4:14 INDEX ON ort_verlag + jahrg + standorte
|
|
TO joausdr
|
|
REPLACE 2:13 1:44 1:53 REPLACE ALL titel WITH titel
|
|
SORT1 2:48 2:51 4:51 SORT ON titel TO x
|
|
SORT3 2:48 2:53 4:50 SORT ON titel,ort_verlag,standorte TO x
|
|
SUM1 0:30 0:27 0:47 SUM h1
|
|
SUM5 0:34 0:30 0:56 SUM h1, h2, h3, h4, h1 + h2 + h3 + h4
|
|
-----------------------------------------------------------------------
|
|
|
|
|
|
LITERATUR
|
|
|
|
/1/ Dr. W. Grafik, B. Osten: dBase III im Vergleich, MP 10/1988,
|
|
Verlag Technik, S. 294ff
|