diff --git a/WEGA/contrib/ingres/dbs/tmp/mp/art.1 b/WEGA/contrib/ingres/dbs/tmp/mp/art.1 new file mode 100644 index 0000000..0d00548 --- /dev/null +++ b/WEGA/contrib/ingres/dbs/tmp/mp/art.1 @@ -0,0 +1,296 @@ +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