(Überarbeitung eines Beitrags zur Festschrift für Hermann Havekost, "Zwischen Schreiben und Lesen", S. 203-223, BIS Oldenburg 1995)

Architekten haben vor Vertretern anderer intellektueller Berufe den Vorteil, mit dem Vitruv, den "Zehn Büchern über Architektur" (De Architectura) des Marcus Vitruvius Pollio, über ein Lehrwerk zu verfügen, das zeitlose Gültigkeit besitzt. Wer "seinen" Vitruv gründlich verstanden hat, kann schon nicht mehr gar so viel falsch machen - einmal etwas überspitzt formuliert. Zumindest dann nicht, wenn er römische Bäder, Atriumhäuser, Tempel oder Befestigungsanlagen - oder auch Maschinen zu deren Überwindung - zu bauen hat.

Informatiker hingegen gehören einer weitaus jüngeren Profession an, in der noch immer um Grundlagen zu ringen ist, wo Theorie und Praxis selten zur Deckung kommen, zumal die technischen Möglichkeiten bisweilen der praktischen Umsetzung von Theorien weit vorauseilen. Man ist zwischen kontroversen Ansätzen hin- und hergerissen, und etablierte Standards ("Industriestandards") werden oft eher als Hemmnis denn als Hilfe empfunden. Welches andere Fach sieht sich konfrontiert mit so riesigen und heterogenen Scharen von Anwendern, die auf zuverlässige Lösungen hoffen und gerne wüßten, wie man denn im Zweifel das Bewährte erkennt, aber welches Fach hat eine kürzere Ahnengalerie als dieses, und wie groß kann bei der notorisch kurzatmigen Dynamik schon der Bestand an Bewährtem und Gesichertem sein?

Doch schauen wir genauer hin! Auf dem Felde der Informatik und ihrer Anwendungen wird auffällig oft von "Architektur" gesprochen: von Rechnerarchitektur, Systemarchitektur, Client/Server-Architektur, Datenbankarchitektur, Netzarchitektur. Will man hier keine willkürliche Vereinnahmung eines fachfremden Begriffes unterstellen, so liegt doch der Versuch nahe, einmal nachzulesen bei Vitruv, ob er nicht auch diesen neuen Zweigen seiner Kunst noch Maßgebliches mit auf den Weg zu geben hat. Dieser Versuch muß in überschaubarem Rahmen bleiben und sich daher exemplarisch auf ein engeres Anwendungsgebiet beschränken: das der bibliothekarischen Datenbank-Baukunst.

Es mag bekannt sein, doch der Hinweis soll nicht fehlen, daß in der Antike der "Architekt" mehr Aufgabenfelder hatte als heute: Buch 9 handelt von der korrekten Konstruktion von Uhren, Buch 10 von Maschinen und Instrumenten, und zwar kriegerischen (Katapulte, Belagerungsmaschinen) sowohl wie zivilen (Pumpen, Kräne, Mühlen, Wasserorgeln). Dies erweist, daß die antiken Baumeister sich durchaus als legitime Altvordern der Ingenieurszunft fühlen dürfen, die doch wohl auch die praktische Informatik mit einschließt. Es ist demnach keineswegs abwegig, sondern ausgesprochen geradlinig, sich in den "Zehn Büchern" der Grundlagen des Faches vergewissern zu wollen.

Im ersten Kapitel des ersten Buches [1][2] (Literaturhinweise in eckigen, Zitate aus Vitruv in runden Klammern) verlangt Vitruv vom Architekten nichts weniger als universale Bildung, denn wie anders könne er die Prinzipien des Bauens so umsetzen, daß die Anforderungen der Praxis optimal erfüllt werden. Wer von Musik und Schauspiel nichts verstehe, wie könne der zum Beispiel ein gutes Theater bauen? Wollen wir das auf die Datenbankarchitektur übertragen, und speziell auf den Bau von bibliothekarischen Datenbanken, also Katalogisiersystemen, OPACs, Erwerbungs- und Ausleihdatenbanken, so kann das, einmal ganz praktisch besehen, nur heißen: wer sich an so einen Bau heranmacht (oder damit beauftragt wird), muß selber schon einmal eine Anzahl Bücher katalogisiert und Kataloge ausgiebig benutzt haben. Praktische Erfahrung an einer Ausleihtheke und anderswo im bibliothekarischen Geschäftsgang wäre ebenfalls förderlich. Weniger günstig dürfte es sein, wenn erst einmal am Reißbrett angefangen wird, zu programmieren, nur mit einem von Bibliothekaren (ihrerseits ohne praktische DV-Erfahrung) verfaßten Pflichtenheft ausgestattet, und ein für weitgehend fertig gehaltenes Produkt dann am Einsatzort erprobt wird, um anschließend das System "abzurunden". Wo wäre schon einmal aus dem Elfenbeinturm einer Informatik-Abteilung ein überzeugendes Bibliothekssystem hervorgegangen? Die Informatik erarbeitet allgemeine Grundlagen und konstruiert unentbehrliche Werkzeuge, das ist schwierig genug, aber der Bau von anwendungstauglichen Datenbanken erfordert etwas anderes: aus dem Arsenal des Verfügbaren sind mit Fachverstand die passenden Konzepte und die geeigneten Werkzeuge auszuwählen, dann erst kann die Arbeit beginnen.

Im Kapitel 3 des ersten Buches wird uns der grundlegende Konflikt aller Bautätigkeit vor Augen geführt: unser Bau soll zugleich dauerhaft solide sein (firmitas), zweckmäßig (utilitas), aber auch noch elegant (venustas)! Das gelingt noch heute nicht immer. Wer kennt nicht Beispiele, wo ein Architekt die Dauerhaftigkeit oder die Zweckmäßigkeit oder beides einer fragwürdigen Ästhetik opferte? Wer hat nicht Datenbanken erlebt, deren Aufbau einen grundsoliden Eindruck machte, die aber erstaunliche praktische Mängel aufwiesen, oder deren Oberflächenästhetik bestechend war, die aber für manche Vorgänge überraschend viel Zeit brauchten, und leider gerade für solche Vorgänge, die man besonders oft brauchte.

Jeder baut gerne mal ein Luftschloß. Problematisch wird es aber, wenn man versucht, darin zu wohnen. Für reale Gebäude hat zu gelten: bereits der erste Ansatz zum Entwurf muß die Anforderungen der Nutzung mit gleichem Gewicht wie die der Solidität und der Ästhetik einbeziehen. Wenn erst die Fundamente gelegt sind, kann ein Bau nicht mehr grundlegend umkonzipiert werden. Fehler im Ansatz lassen sich nicht durch noch so viel Kosmetik übertünchen. Gewiß, Grundmauern lassen sich nachträglich verstärken, Stützpfeiler einbauen, man kann aufstocken und anbauen, aber die Eleganz ist dahin und die Kosten steigen.

Der Konflikt zwischen den drei genannten "Kardinaltugenden" besteht offensichtlich heute wie damals. Was ist zu tun? Vitruvius will uns ein gutes Stück weiterhelfen, indem er sechs Grundprinzipien für die Entwurfsarbeit vorgibt. Das Problem damit ist nur, daß die Begriffe nicht mehr leicht zu übersetzen sind. Sie entstammen einer Erfahrungswelt, die uns doch sehr fern ist. Das Alltagsleben, aber auch Politik und Wissenschaft waren durchsetzt von spekulativen (wir sind oft versucht zu sagen, abergläubischen) Elementen, die niemand hinterfragte. Die sozialen und wirtschaftlichen Strukturen waren grundlegend andere, man denke nur an das Sklavenwesen. Die Achtung vor den Leistungen der "Alten", das Bestreben zur Fortführung langer Traditionen (Tenor: früher war alles besser, besonders im Osten, bei den Griechen) - solche Haltungen scheinen heute verschwunden, wenn nicht gar ins Gegenteil verkehrt (Tenor: das Neuere ist das Bessere, besonders wenn es aus dem Westen kommt). Diese wenigen und ganz unvollständigen Andeutungen müssen hier genügen, die enorme Kluft zwischen der antiken Lebenswelt und der heutigen wenigstens in Konturen erahnbar zu machen. Skeptiker mögen nun einwenden, daß diese Kluft unser Vorhaben von vornherein fragwürdig erscheinen ließe. Doch legt etwa der Mathematiker aus denselben Gründen Thales und Pythagoras ad acta?

Nehmen wir die Grundprinzipien in der Reihenfolge vor, wie sie uns der Altmeister im Kapitel 2 des ersten Buches aufzählt, wenngleich manche davon teilweise aufeinander aufbauen; besonders die Punkte 1. und 4. haben viel miteinander zu tun. Wo er den griechischen Urbegriff zur Erklärung mit heranzieht, geben wir diesen in Klammern ebenfalls an.

1. Ordinatio (taxis)

Das breite Bedeutungsfeld dieser Wörter erschwert es, eine griffige Entsprechung zu finden. "Augenmaß" könnte am ehesten passen. Es geht um die richtige Gesamtgröße eines Gebäudes und um die dazu passende elementare Maßeinheit. Allen Abmessungen soll eine gemeinsame Größeneinheit, der modulus M, zugrunde liegen, und diesen gilt es zunächst einmal zu bestimmen. Beim Tempelbau beispielsweise ist M der zweiundvierzigste Teil seiner Breite. Die Kapitelle haben dann genau die Höhe M, der Säulenfuß hat 2M Durchmesser etc. Weil die Bauvorschriften dann im einzelnen zahlreiche Verhältniszahlen der Teile untereinander festlegen (siehe 4.), ist die Bestimmung dieser Maßeinheit das zentrale Problem am Anfang der Entwurfsarbeit.

Der alles diktierende modulus im Softwarebereich ist das Byte, die Maßeinheit für die Speicherung eines Zeichens. Daß es aus 8 Bit besteht, ist durchaus willkürlich. Es war nur einfach für die Mikro-Architektur der elektronischen Bauelementetechnik sehr praktisch, diese Größe zu wählen. Als Datenbankarchitekt hat man allerdings schlichtweg nicht die Möglichkeit, einen anderen modulus zum Maßstab zu machen. 10 Bit wären besser, dann hätten wir nicht die ärgerlichen Zeichensatzprobleme, weil wir statt nur 256 dann ohne Kunstgriffe 1024 Codes definieren könnten. Da es keine 10-bit-Hardware und/oder -Systemsoftware gibt, können wir das nicht tun. Ein Umstieg auf den 16-Bit-Standard UNICODE ist zum einen softwaretechnisch noch nicht durchführbar, andererseits würde sich dadurch sofort die Gesamtgröße unserer Gebäude (gemessen in Megabyte) verdoppeln. Die breite Masse unserer Bestände kommt mit einem 8-Bit-Code aus. Zumindest wäre es grotesk, die Bibliothek mit überwiegend deutschsprachigem Bestand zu zwingen, mit 16 Bit zu arbeiten, wenn womöglich kein einziger Titel den erweiterten Zeichenvorrat erfordert. Das Byte ist aber vielleicht eher so etwas wie ein Ziegel, und deren Größe bestimmte auch in Rom nicht der Architekt, die waren von der Industrie auf 1,5 x 1 Fuß genormt (Kap.2,3) und man verwendete sie für ganz kleine wie ganz große Bauten gleichermaßen. Ziegel jedoch sinken nicht fortwährend im Preis, wie es Bytes tun. Daher werden letztere schon gar nicht mehr als knappes Gut empfunden. Sie sind es und sie bleiben es aber, solange Bibliotheksbestände rastlos wachsen. Darauf wird noch zurückzukommen sein.

Ein weiterer modulus mit großer Bedeutung für den Datenbankbau ist aber die Breite der Satznummern. Wenn der Entwurf von einer 16-Bit (also 2 Byte) Satznummer ausgeht, kann eine Datenbank nur 2¹⁶ = 65536 Sätze umfassen - entschieden zuwenig. Wollte man völlig auf Nummer Sicher gehen und etwa 10-Byte-Satznummern wählen, wäre das auf absehbare Zeit ein viel zu großer Normbaustein für alle realen Datenbanken, und für die Masse der kleinen (unter 2¹⁶) wäre das etwa so, als wollte man Reihenhäuschen so auslegen, daß sich die größten Sippschaften darin noch verlören. Ideal wäre natürlich, wenn das Datenbanksystem eine der Gesamtgröße angemessene Satznummernbreite erlauben würde, was aber kein System tut. Das Gängige ist der modulus 4 Byte (= 2³² = 4.294.967.296), und bei diesem ergeben sich derzeit immerhin keine allzu offensichtlichen Mißverhältnisse oder Beschränkungen. Die größten Bibliotheksdatenbanken (bei der LC und beim OCLC) liegen in der Größenordnung von 2²⁶ (ca. 67 Mio.), das ist ein Vierundsechzigstel des Möglichen.

Hier ist eine Nebenbemerkung über Zahlen angebracht. Die Zahl 16 hält Vitruv für die "vollkommenste Zahl" und begründet dies (in 3,1) auf entwaffnende Art: "die Alten" hätten als Zahl der Finger die 10 für die vollkommene Zahl gehalten, die Mathematiker sähen dafür aber die 6 an, somit müsse die Summe 16 wohl der Inbegriff der Vollkommenheit sein. Informatiker mögen dieser Argumentation nicht mehr ganz bereitwillig folgen, dennoch schätzen sie die 16 sehr als Basis des Hexadezimalsystems. Es ist unübersehbar, daß Vitruv dual, nicht dezimal denkt; seine Proportionen beruhen, wo immer möglich, auf fortgesetzten Halbierungen oder Verdopplungen, also auf Potenzen von 2. Von Plato hat er gelernt, das Quadrat zu verdoppeln, also das Verhältnis 1:Ö 2 darzustellen (6,3,3). Noch viel später, in der Gotik, als das geometrische Konstruieren seine Höhepunkte erreichte [3], hatte diese Proportion eine fundamentale Bedeutung und galt als das sogenannte "rechte Maß".

Der bibliothekarische Datenbankarchitekt, zurück zum eigentlichen Thema, kann in der Regel höchstens über einen dritten modulus wirklich entscheiden: die Breite der Feldbezeichnung oder Kategorienummer. Meistens ist auch dieser Wert schon vorgegeben, doch theoretisch geht die Entscheidung voraus, daß man überhaupt mit diesem Konzept arbeitet. Praktisch tut das aber jedes ernstzunehmende System. Darauf gehen wir im nächsten Abschnitt ein.

2. Dispositio (diathesis, ideai)

Unter dieser Überschrift geht es Vitruvius vordergründig um die Entwurfsskizzen: Grundriß, Aufriß, Ansicht. Es ist aber klar, daß diese nur entstehen können, wenn das Erscheinungsbild des Gebäudes bereits im Kopf des Architekten vorhanden ist. Die Skizze repräsentiert ja nur das Eigentliche, und das ist die Idee, der Ansatz, das Modell. Für die Säulenordnungen von Tempeln etwa läßt Vitruv, gestützt auf die Überlieferung, nur drei Modelle zu: das dorische, das ionische und das korinthische (Kap. 3 und 4). Ist der Modul festgelegt, steht damit praktisch auch schon das Modell, denn die Entwurfsvorschriften legen alle Einzelteile und ihre Größenbeziehungen fest. Diese Haltung mutet doch als schwer erklärbarer Konservativismus an, denn sie begrenzt rigoros jede Kreativität. (Es mag sein, daß zeitgenössische Kritiker dies bereits verurteilt haben, doch haben die Werke dieser Rivalen die Millenien leider nicht überdauert, weder die Schriften noch die Bauten.) Der Grund wird sein, daß Vitruv auf klare und eindeutige Entwurfsregeln aus war und nichts dem Zufall überlassen wollte. Er beklagt an anderer Stelle (10,2) ein um sich greifendes Stümpertum, und da könnte er einen Vorteil darin gesehen haben, penible Vorschriften aufzustellen, mit denen auch der weniger Begabte zwangsläufig zu akzeptablen Resultaten kommt. Für das Entwickeln von Ideen kann es solche Regeln jedoch nicht geben. Vermutlich ahnte er genau, was passieren würde, wenn die zufällige Eingebung des Entwerfenden, extremer Gegenpol zu seiner Haltung, in Entwurfsfragen zum bestimmenden Moment würde.

Der Umgang mit Bibliotheksdaten erfordert ein Modell zu ihrer Speicherung. Dieses Problem hat drei Aspekte: 1. Welche Gegebenheiten der realen Welt müssen als identifizierbare Einheiten oder Objekte in der Datenbank abgebildet werden, und sind diese Objekte alle gleichberechtigt und unabhängig voneinander oder kann es logische Zusammenhänge zwischen Objekten geben? 2. In welche Elemente muß man die Beschreibung eines jeden solchen Objekts zerlegen? und 3. Wie kann man diese Elemente in einem gegebenen Speichersystem anordnen? Der Gesamtentwurf muß schnelles Wiederfinden genauso garantieren wie zweckmäßige Darstellung des Gefundenen, sowie effiziente Möglichkeiten zur Modifikation (Korrektur) wie für das Einspeisen neuer Objektbeschreibungen. Diese Fragen werden kaum noch gestellt, sie sind fast gar nicht mehr bewußt. Aufgrund eines schwer erklärbaren Konservativismus (das hatten wir doch schon mal?) nimmt es jeder für gegeben, daß die darzustellenden Objekte Bücher sind, daneben werden Normsätze für Personen, Körperschaften und Begriffe (Schlagwort-Stammsätze) gefordert. Kaum hinterfragt wird auch, daß die Elemente und die Struktur der Beschreibung durch eine Sprache namens RAK und eine Art Grammatik namens MAB letztgültig festgelegt sind. Wie das Ganze intern wirklich gespeichert ist, das interessiert den bibliothekarischen Datenbankentwerfer eigentlich nicht, wenn das Material nur auf der (Bildschirm-)Oberfläche so erscheint, daß er es als "natürlich" empfindet. Dieses Empfinden ist im deutschsprachigen Raum nicht so einheitlich wie in der angelsächsischen Welt, oder schon beinahe in der gesamten nicht-deutschsprachigen Welt. Dort ist AACR2 mit der Grammatik MARC die einzige Sprache, die gesprochen und verstanden wird, wenngleich in diversen Dialekten.

Zu Punkt 1: Objekte

Um eingeschliffene Vorstellungsbilder aufzulockern, sehen wir uns ganz kurz das Hauptproblem der Musikalienkatalogisierung an. Wenn man in Analogie zur Bücherwelt die Schallplatte oder die CD als Einheit betrachtet und katalogisiert, ignoriert man die Erwartungen der Praxis (utilitas!). Das einzelne Musikstück ist es, nach dem gesucht wird! Die physische Platte ist zwar eine mit der Hand greifbare Einheit, wie das Buch, aber ihr Inhalt ist oftmals eine willkürliche Zusammenstellung - ganz anders als beim Buch. (Gewiß, bei Festschriften zum Beispiel kann es auch so sein, aber der Normalfall ist es nicht.) Ferner steht bei der Buchkatalogisierung der vorliegende Sachtitel, der Hauptsachtitel, im Zentrum des Interesses. Die Übertragung dieses Prinzips führt in der Musikalienkatalogisierung zum Chaos, denn die aufgedruckten Titel der Stücke variieren so sehr, daß in einer alphabetischen Auflistung die verschiedenen Ausgaben (Interpretationen) eines gegebenen Stückes weit verstreut sein können. Also kommt dem bei Büchern eher vernachlässigten Einheitstitel bei Musikalien eine tragende Bedeutung zu.

Wenn man das zu Ende denkt und auf Publikationen aller Art anwendet, kommt heraus, daß die Vorlagenorientierung der RAK eben doch ein artifizielles, nicht am Ziel orientiertes Konzept ist. Benutzer suchen nicht das konkrete Buch oder die CD als physisches Objekt, sie suchen Inhalte. Die Werkorientierung der Preußischen Instruktionen kam den Erwartungen da schon näher, wenngleich auch sie mit enthaltenen, beigefügten und unselbständigen Werken stiefmütterlich umgingen, doch das war eher ein Zugeständnis an die Ökonomie. Eine Folge der Vorlagenorientierung waren in der MAB-Grammatik die unsäglichen "Nachsätze". Im Zuge der MAB2-Reform wurden sie abgeschafft. Die Nachfolgeregelung ist indessen auch keine Offenbarung, aber es wird immerhin auf die Möglichkeit hingewiesen, enthaltene Werke als eigene (unselbständige) Datensätze zu erfassen. Konsequente Werkorientierung als Grundprinzip (d.h. jedem Werk und jeder Ausgabe davon - ob selbständig oder nicht - ein eigener Datensatz, evtl. verknüpft mit einem Stammsatz) wird in den USA mehr diskutiert als hier [4], an eine Umsetzung ist momentan aber nirgends zu denken.

Zu Punkt 2: Elemente

Es hat sich eingebürgert, als Bezeichner für Datenelemente Nummern zu verwenden, genannt "Kategorienummern". Auch darüber wird nicht mehr nachgedacht, wenngleich ganz andere Ansätze denkbar sind, zum Beispiel wenn man sich von der relationalen Datenbankwelt her dem Thema nähert oder aber aus der Gegend der Textsysteme. Die Kategorienummern, mit denen man letztlich arbeitet, spielen im Prinzip eine eher untergeordnete Rolle. Das heißt, es ist egal, ob der Hauptsachtitel das Etikett "245" bekommt (MARC) oder "331" (MAB). Wichtig sind die Inhalte. Wichtig ist, wie er angesetzt, also eingegeben wird, denn daraus ergeben sich direkt die Suchmöglichkeiten. Die Katalogregeln bestimmen die Inhalte, nicht das Format - das ist nur die Grammatik. Strenggenommen müßte der Datenbankentwurf die Katalogregeln mit einbeziehen, aber in der Praxis bleiben sie als quasi sakrosankt außen vor. Damit hat der Datenbankarchitekt nichts zu tun. Er soll gefälligst die Datenbank so entwerfen, daß man alle RAK-Finessen abbilden kann. (Die Frage nach dem Sinn solcher Finessen wurde ja lange Zeit selbst von den Auftraggebern nicht mehr gestellt, bis dann die RAK-online-Diskussion in Gang kam.) Aber Vitruv hatte als Baumeister auch nicht zu fragen, ob denn der dorische Tempel den Metopenfries wirklich braucht, wo er doch den berüchtigten "Eckkonflikt" hervorbringt. Es handelte sich dabei in der Tat um ein Relikt aus der Holzbauzeit: die Triglyphen waren aus den Stirnflächen der Balken hervorgegangen, die der Steinbau gar nicht mehr hatte. (Vitruv entschied sich übrigens dafür, den Konflikt zu ignorieren, also Abstriche bei der venustas zu machen, weil die bekannten Lösungen seine Verhältniszahlen aus dem Gleichgewicht brachten (2,4).)

Die Kategorienummern sind aber nur theoretisch unwichtig. In der Praxis sind sie in zweifacher Hinsicht sehr wichtig:

1. Sie strukturieren eine Sprache, die von Menschen und Maschinen erlernt und gesprochen werden muß. Babylonische Sprachverwirrung kann man hier sowenig vertreten wie auch sonst im Leben, denn sie behindert die Kommunikation der Katalogisierer so sehr wie den Datenaustausch zwischen den Systemen.

2. Die Kategorienummern brauchen ihrerseits Speicherplatz. Wenn man rein bibliothekarisch denkt, kann man zu einem Entwurf wie MAB gelangen und diesen vertreten, doch der Programmierung zwingt man damit unästhetische Kunstgriffe auf (besonders mit den Mehrfach-Feldgruppen und dem unbegründbaren Verzicht auf die ökonomische Teilfeldtechnik) und man schafft künstlich einen erhöhten Speicherbedarf. MARC ist da schon ein wenig besser, aber auch noch nicht optimal. Beide arbeiten mit dreistelligen Feldbezeichnungen. Das ist eine Stelle zuviel. Der Grund ist, daß beide mit einem Dogma operieren, daß nämlich Kategorienummern Nummern sein müssen. Verwendet man Ziffern und Buchstaben, kommt man ohne Probleme mit zwei Stellen aus. Immerhin erzielt man damit ca. 5% Platzersparnis. Heute wird jedoch Verschwendung in weitaus größerem Ausmaß nicht nur hin- sondern gar nicht mehr als solche wahrgenommen. (Mehr dazu noch unter 6.)

Zu Punkt 3: Speicherung (interne Darstellung)

Bei manchen Systemen würde sich ein Katalogisierer wundern, wenn er einmal sehen könnte, wie die eingegebenen Daten intern wirklich aussehen. Da kann eine Titelaufnahme zur Unkenntlichkeit umcodiert oder auch aufgespalten und auf mehrere Dateien oder Tabellen verteilt sein. Im Prinzip ist auch dieses nicht wichtig, solange das System zum richtigen Zeitpunkt immer alles richtig zusammenbringt und auf die Oberfläche projiziert. Praktisch jedoch kann eine Datenbank dadurch zur "black box" werden, aus der man bei einem Totalversagen des Systems rein gar nichts Brauchbares mehr herausbringen kann. Allerdings sind alle eingesetzten Systeme solchermaßen solide, daß kein Totalversagen auftreten kann. Dafür legt jeder Hersteller die Hand ins Feuer, was man im "Kleingedruckten" nachlesen kann.

3. Eurythmia

Hierfür gibt es nun wirklich keinen passenden deutschen Begriff, und leider zeigt Vitruv uns in den einzelnen Kapiteln (im Gegensatz zur symmetria, siehe 4.) nicht mit Beispielen, wie dies und jenes der eurythmia wegen sein müsse. Summiert man einmal, was die Übersetzer daraus gemacht haben, dann ist wohl so etwas gemeint wie "der ästhetische Zusammenklang von Form, Proportion und Größe". Selbst wenn man einen modulus und damit auch die Gesamtgröße des Baues bestimmt hat, selbst wenn die grundsätzliche Idee der Bauform zu Papier gebracht ist, kann der Entwurf z.B. zu kleinteilig und detailbeladen sein oder aber zu grobschlächtig und langweilig. Aus diesem Grunde braucht der dorische Tempel dann eben doch seinen Metopenfries, denn er hätte sonst zu wenig optische Struktur. (Diesen Grund gibt Vitruv freilich nicht an. Er gibt gar keinen an, sondern akzeptiert dieses Bauelement als Bestandteil der Tradition.)

Hat dieses schwer faßbare Prinzip überhaupt irgendeinen Bezug zur Datenbankarchitektur? Aber ja. Knapp ausgedrückt: in größeren Datenbanken muß es abgestufte Strukturen geben. Es reicht nicht, wenn es Registereinträge als kleinste sinntragende Elemente und eine Suchsprache mit logischen Verknüpfungen gibt. Die Ergebnismengen beim Suchen werden dann allzu oft allzu groß und damit unübersichtlich. Zumindest muß es dann eine geordnete Kurzanzeige der Ergebnismenge geben. Aber auch Möglichkeiten zur Verfeinerung einer Suche sind gefragt: Einschränkung nach Erscheinungszeitraum z.B., nach Materialart, nach Sachgebiet. Serienstücke sollten sortiert nach Bandnummern aufzublättern sein, mehrbändige und unselbständige Werke müssen so präsentiert werden, daß auch und gerade in umfangreichen Fällen Übersicht geschaffen wird. Bisher nur sehr wenige Systeme bieten strukturierbare Register, d.h. mehrteilige Schlüssel (z.B. "Verlag,Erscheinungsjahr", "Komponist: Einheitstitel"), sowie die Möglichkeit, die Register in trunkierter Form zu betrachten. Auch Zwischenüberschriften (analog zu Leitkarten im Zettelkatalog) sind machbar, um große Register zu gliedern. Auch auf der Ebene des einzelnen Datensatzes ist Strukturierung notwendig: ein großer Zentralkatalog kann etwa Bestandsangaben nach Regionen gliedern und diese in sich nach Sigeln sortieren. In einem OPAC, der mit einem Ausleihsystem gekoppelt ist, muß man eine Liste der Bände einer Zeitschrift abfragen können. Da es aber hunderte von Bänden geben kann, muß man den Einstiegspunkt bestimmen können, denn schlichtes Weiterblättern bis zum bitteren Ende wird schnell als Zumutung empfunden. Das sind alles Beispiele für Strukturierungen, die eine Katalogdatenbank anbieten kann oder sollte, sobald ihre Größe einige zehntausend Sätze überschreitet. Kleine Datenbanken wirken dagegen überladen, wenn man sie mit all diesen "features" ausstattet. Im Gegensatz zum Zettelkatalog, den man mit dem Auge als Ganzheit von Ende zu Ende überblicken und daher in seiner Größe einschätzen kann, ist die Datenbank eigentlich so gut wie unsichtbar, denn die Ausschnitte im Bildschirmfenster vermitteln keinen visuellen Eindruck von der Datenbank als Gesamtheit.

4. Symmetria

Was wir heute unter "Symmetrie" verstehen, genau das ist nicht gemeint. Daß ein Bau achsensymmetrisch (ein Rundbau zentralsymmetrisch) zu sein hat, das war vielmehr völlig selbstverständlich und mußte überhaupt nicht erwähnt werden - vielleicht gab es gar kein Wort dafür. Der menschliche Körper wurde stets als Maß aller Dinge herangezogen (3,1), und der ist achsensymmetrisch. Damit steht dieses Merkmal a priori und unverrückbar fest. "Harmonische Proportionierung" wäre vielmehr die angemessene Übersetzung. Nach Festlegung von Gesamtgröße und Modul, Aufstellung des Entwurfs und Abwägen der Bestandteile geht es nun an die Feinarbeit. Wie schon erwähnt, müssen alle Bauteile als Vielfache oder Bruchteile des modulus bemessen werden. Die konkreten Zahlen jedoch zu ermitteln, die ein harmonisches Gesamtbild entstehen lassen, das eben ist die Kunst. Vitruv geht hier insbesondere bei den Tempelmodellen bis in alle Einzelheiten. Die Architekten der Gotik, wie schon angedeutet, führen das antike Konstruktionsprinzip zur Vollendung, indem sie alle Abmessungen einer Kathedrale durch geometrische Verfahren, Verdopplungen und Halbierungen, aus einem einzigen Quadrat oder Dreieck entwickeln, und zwar auch und vor allem den Innenraum, den Vitruv als Gestaltungsaufgabe noch kaum wahrgenommen hatte.

Den Datenbankarchitekten wird womöglich das äußere Erscheinungsbild der Datenbank gar nicht interessieren. Das ist Sache eines Anwendungsprogramms, heute meist Client genannt. Für den Benutzer jedoch ist die Oberfläche die Datenbank. Ob man das Oberflächendesign zur Datenbank- oder zur Schnittstellen- oder Systemarchitektur rechnet, darauf kommt es nicht an: es ist eine anspruchsvolle Teilaufgabe im Gesamtprojekt einer bibliothekarischen Datenbankanwendung. Denn an dieser Schnittstelle stehen sich künstliche und natürliche Intelligenz gegenüber, zwei grundverschiedene Welten. Ganz einfach kann es da nicht zugehen. Selbst wenn wir einheitliche Katalogisierungsregeln hätten und die Daten überall in einheitlichem Format vorlägen (ein bloßer Konjunktiv, aber nehmen wir mal an), die Erscheinungsbilder der real existierenden OPACs nach außen wären noch immer äußerst unterschiedlich. Damit dieser Abschnitt nicht den Rahmen völlig sprengt, nehmen wir uns nur zwei Aspekte vor:

1. Verhältnis zwischen Menüführung und Datendarstellung. Wenn die Bildschirme überwiegend mit Hilfs- und Menütexten gefüllt sind, das Register- oder Anzeigefenster folglich relativ klein ist, kann man nicht von einem harmonisch proportionierten Entwurf sprechen. Vor allem muß wenigstens jederzeit klar erkennbar sein, wo inmitten des Beiwerks eigentlich die momentan wichtigen Daten stehen, und welches die möglichen nächsten Schritte sind. Hier kann nicht nur die Flächenaufteilung, sondern auch die Farbgestaltung sehr helfen.

2. Die RAK und auch die RAK-online-Entwürfe sind unvollständig. Sie sagen z.B. nichts darüber aus, wie und aus welchen Teilen eine einzeilige Kurzanzeige im OPAC aufzubauen ist. Ergo toben sich hier die Designer aus und die Ergebnisse sind überall verschieden. Auch die Fragen werden nicht behandelt, welche Register es geben und wie man sie eigentlich nennen (!) sollte (Fragen: Personen und Körperschaften zusammen oder getrennt? Stichwörter und Schlagwörter zusammen oder getrennt? Personenschlagwörter zusammen mit den beteiligten Personen? Serientitel aufgelöst in Stichwörter oder als String, mit oder ohne Bandnummer? usw. usf.) Nichts gesagt wird über eine minimale oder wünschenswerte Breite der Registereinträge. Auch zu solchen Kleinigkeiten wie der Behandlung der Sonderzeichen, der Umlaute, der Akzente etc. in den Registern schweigen die RAK sich aus. Jeder kann leicht vergleichende Katalogforschung über Internet betreiben und die Konsequenzen besichtigen.

Es ist klar, daß diese, sagen wir, optisch-statischen Eigenschaften des Oberflächendesigns nicht die ganze Antwort zum Kriterium venustas sind. Man hat es mit einer Maschine zu tun! Ihre Teile müssen harmonische Bewegungen vollführen. Weder darf der Wechsel von einem Bildschirm zum nächsten zeitlich undurchschaubar schwanken, noch darf der Bewegungsspielraum zu gering sein (z.B. nur seitenweise und nur nach unten blättern statt zeilenweise auf- und abwärts "scrollen"). Zwanghaft starre Abläufe ermüden, Abkürzungen, Quer- und Rücksprünge zwischen Fenstern oder Funktionen ermöglichen organisch-flüssiges Arbeiten.

5. Decor

Erneut führt eine wörtliche Übertragung in die Irre. Hier geht es nicht um Dekoration, sondern um "Angemessenheit" im weitesten Sinne; ältere deutsche Übersetzungen reden gar von "Schicklichkeit", englische von "propriety". Dabei gibt es drei Aspekte: 1. Man vermeide jedes Stilgemisch (keine Triglyphen an ionischen Tempeln); 2. Der Stil muß zum Zweck passen (für Mars einen dorischen, für Venus einen korinthischen Tempel); 3. Schließlich muß sich das Gebäude in seine Umgebung einfügen, man muß seinen Standort und seine Ausrichtung mit Bedacht wählen (Schlafzimmer und Bibliothek nach Osten, Bad nach Westen). Ein wichtiges und oft genanntes Kriterium ist auch die Gesundheit der Bewohner und Benutzer der Gebäude!

Auch im Datenbank-Bauwesen ist ein Nachdenken über die Angemessenheit von Konzepten, Strukturen, Komponenten und Elementen sehr anzuraten, doch wird der Einsatz von unangemessenen Mitteln nicht immer von außen wahrnehmbar sein. Ein verbreitetes Übel ist das Schießen mit Kanonen auf Spatzen. Gern werden Standard-Werkzeuge eingesetzt, weil sie wenig Programmieraufwand erfordern. Das kann sich als Fehlspekulation erweisen, und zwar weil man erstens immer wieder Kompromisse machen muß, und weil zweitens viel mehr Speicherplatz und/oder Rechenleistung verbraucht wird als angemessen. Als Summe aller Kompromisse und Zugeständnisse kann herauskommen, daß man eine mehrfach größere Hardwarebasis braucht als tatsächlich notwendig wäre, und es können Lizenzkosten für Produkte hinzukommen, deren eigentliches Potential kaum genutzt wird. Soviel zum allgemeinen Thema "Angemessenheit". Nehmen wir uns aber die oben genannten drei Punkte noch genauer vor:

Zu 1. Stilgemisch

Wer lange Zeit nur die Schreibmaschine kannte und dann auf Bildschirmarbeit umsteigt, der muß zunächst eine Flut von neuen Eindrücken verdauen. Vielleicht die größte Überraschung ist die, daß eine und dieselbe Taste, ganz anders als auf der Schreibmaschine, in verschiedenen Situationen und unterschiedlichen Programmen ganz verschiedene Wirkungen hervorrufen kann, u.U. auch einmal gar keine, manchmal eine überhaupt nicht plausible, gelegentlich eine durchaus katastrophale. Da dies verunsichernd wirkt und selbst für langjährige Dauer-Hacker ein Ärgernis und also ungesund ist, gab es in der Softwarebranche seit längerem Bemühungen um Standardisierung. IBM startete schon 1983 ein ehrgeiziges Projekt namens Standard Application Architecture (SAA) [5], und ein Bestandteil davon war das Konzept Common User Access, CUA, das bis ins kleinste Detail das Aussehen von Bildschirmfenstern und die Wirkungsweise von Tasten vorschrieb, neben vielen anderen Einzelheiten wie auch der Mausbetätigung. Ein wahrhaft vitruvianisch-akribisches Regelwerk - für notwendig gehalten, weil sonst unvermeidlich jeder Entwickler eine Oberfläche nach eigenem Gusto zusammenstoppelt. Der "SAA-Standard" findet nur gelegentlich noch Erwähnung, aber die auf Tastatur, Bildschirm und Maus bezogenen Anteile sind in der Tat weitgehend in Microsoft's Windows übernommen worden. Deshalb ist Windows so beliebt: man weiß immer, wo man dran ist, wenn man bestimmte Dinge sieht, und was z.B. TAB, ENTER, ESC und besonders F1 in einer gegebenen Situation machen werden. Der Lernaufwand für neue Software, so die Vorstellung, wird drastisch verringert, Verunsicherung vermieden, Wohlbefinden gefördert, Produktivität gesteigert. Rasant vermehren sich derzeit und deswegen diejenigen Anwender, die noch nie ein "DOS-Prompt" gesehen haben und außer Windows-Software nichts kennen (wollen). Die Regenbogenpresse der Computerei scheint wie hypnotisiert und orakelt kaum noch, ob Windows'2000 alles andere wegfegen wird, sondern nur noch wann. Allerdings: wenn wir die Betriebssysteme DOS und UNIX mit ihrer äußerst schlichten und schmucklosen Formensprache einmal als Romanik einstufen (DOS als volkstümliche Version, UNIX als Glasperlenspiel der Scholastiker), dann katapultiert uns Windows-Software sofort in den schwülstigsten, sorglos-verschwenderischen Barock hinein, in eine neue Oberflächlichkeit, die Leichtigkeit nur vortäuscht, Wesentliches unter optischer Fülle begräbt. Ein Jammer, daß die Gotik übersprungen wurde: ihre Transparenz, ihre Einheit von Form und Funktion, ihre unaufdringliche Überzeugungskraft, ihr perfektes Augenmaß bei mathematisch exakter Proportionierung - ist die Chance vertan? Bill Gates ist nicht die Art Visionär, den es hier gebraucht hätte.

Zu 2. Zweckmäßigkeit

"Form follows function" - diese gern strapazierte Devise heutiger Baumeister (zuerst formuliert von Louis Henry Sullivan (1856-1924)) wird anscheinend manchmal so verstanden, daß die Form etwas über die Funktion aussagen müsse, wo doch wohl gemeint ist, daß sie ihr entsprechen und sie unterstützen soll. Wie kann man sich sonst erklären, daß ein Entwurf für ein extrem großes Gebäude einer europäischen Nationalbibliothek genau deshalb vom Staatsoberhaupt ausgewählt wurde, weil es aussieht "wie vier aufgeklappte Bücher, die sich gegenüberstehen". Daß es zweckmäßig wäre, davon hat man noch nichts gehört ...
Aber schweifen wir nicht ab. Gebäude der realen Welt haben aus rein physikalischen Gründen eine recht geringe Flexibilität, sie müssen daher von vornherein, mit Weitblick, zweckentsprechend konzipiert sein. Datenbanken können dagegen immer nur indirekt, quasi wie Luftspiegelungen, betrachtet werden. Per Software wird einem am Bildschirm eine bestimmte Ansicht vorgespiegelt, im nächsten Moment oder am Schirm eines anderen Benutzers kann eine ganz andere Ansicht aufscheinen. Das gleiche Datenbanksystem kann mehrere konkrete Datenbanken mit ganz unterschiedlichen Gesichtern (z.B. ganz verschiedenen Kategoriesystemen) präsentieren. Also muß die Staatsbibliothek im Prinzip kein anderes Datenbanksystem anschaffen als die Hochschulbibliothek, die kirchliche kein anderes als die Museumsbibliothek. In allen Häusern könnte das gleiche System arbeiten, aber unterschiedlich konfiguriert. Und die vielfältigen Ansichten entstehen immer aus denselben Daten, aber jeweils mit anderen Einstellungen oder Parametern der Software. Das also sind die Forderungen, die man an das Datenbanksystem stellen muß: Konfigurationsfähigkeit (z.B. bezüglich Kategoriesystem) und Parametrierbarkeit (z.B. bezüglich Indexgestaltung, Bildschirmanzeige, Druckausgabe). Einmal anders ausgedrückt: Datenbanken sind zwar Gebäude, aber das Datenbanksystem ist eine Maschine. Sie kann unterschiedlichste Datenbanken erstens bauen (dafür muß sie konfigurierbar sein) und zweitens betreiben (dafür muß sie parametrierbar sein).

Zu 3. Einklang mit der Umgebung

Für OPACs wünscht man sich, daß alle Welt darauf zugreifen kann. Man geht davon aus, daß sie das auch will. Eine "Bibliothek ohne Wände" soll entstehen. Der Rechner selbst mag zwar im Gemäuer der Bibliothek stehen und nur Befugten physisch zugänglich sein, aber eine Glasfaser geht durch die Wand und macht diese transparent, d.h. ermöglicht den Einblick von außen. Eine Glasfaser allein macht aber noch keine "Schnittstelle" (manche können das Wort längst nicht mehr hören).

In Zettelkataloge konnte man nicht von außen hineinschauen. Infolgedessen entstanden in isolierten Biotopen die schönsten Sumpfblüten. Man rettet davon, was zu retten ist, in die Online-Umgebung - das Datenbanksystem ist ja geduldig (sprich konfigurier- und parametrierbar). Wie aber bringt man es der Außenwelt bei, daß man den besten aller Kataloge hat, wenn dort jeder dasselbe von seinem eigenen denkt? Antwort: man schafft eine Software, die jedem Außenstehenden die Datenbank so zeigt, wie er sie sehen will. Sagen wir z.B., um keine Namen zu nennen, unsere Datenbank ist eine korinthische, dann können wir Besitzern von dorischen oder ionischen Datenbanken vorspiegeln, unsere sei auch eine solche, und jene können das Umgekehrte tun. Diese Software ist noch nicht vollkommen fertig und noch nicht überall einsetzbar, aber einen Namen hat sie: SR-Schnittstelle (Search and Retrieve) oder noch schöner: Z39.50. Auf den ersten Blick eine geniale Idee: die Sumpfblüten können virtuell weiterblühen, aber alle können sich verständigen. Ein Datenbank-Esperanto, aber nicht die Menschen, nur die Maschinen müssen es lernen! Vielleicht ist es etwas einfacher zu realisieren als das automatisch übersetzende Telefon, das den Gesprächspartnern stets vorgaukelt, der andere spreche dieselbe Sprache. Sehr viel einfacher allerdings nicht, denn es gibt ganz ähnliche Probleme. Hier sind ein paar davon:

1. Vokabular-Probleme: wenn ich selbst etwa ein Künstler-Register habe, der andere aber nicht, kann ich an dessen Datenbank nicht die entsprechenden Fragen stellen;

2. Syntaktische Probleme: Wenn das andere System keine logische NICHT-Verknüpfung hat, kann ich auf solche Suchanfragen keine Antwort bekommen;

3. Idiomatische Probleme: Wenn ich eigene Ansetzungs- und Erfassungsregeln habe (z.B. an mehrbändige Werke mag man schon gar nicht denken), können Abfragen aus anderen Umgebungen leicht danebengehen.

Der dritte Punkt kann gar nicht ernst genug genommen werden. Illustrieren kann man das durch einen etwas respektlosen Vergleich:
Die Kommunikation über Z39.50 (oder auch der Austausch über ein internationales Format wie UNIMARC) wird technokratisch etwa so betrachtet, als ob sich weltweit die Käsereien auf ein gemeinsames, einheitliches Verpackungsformat geeinigt hätten. Das erleichtert sehr alle Transport-, Lager- und Packvorgänge. Der Konsument jedoch findet in der Packung jeweils den alten Käse - was er durchaus erwartet! Genau das erwartet ein Empfänger solchermaßen verpackter Daten aber nicht, er ist vielmehr verstimmt, wenn statt des deutschen Schlagwortes "Käse" aus Italien "Formaggio" kommt, aus Polen "Ser" und aus den USA "Cheese". Das muß er beim Suchen wissen und beim Übernehmen bearbeiten.

Die Idee SR kann in einer MARC-Landschaft vielleicht einigermaßen funktionieren, weil dort das Material relativ homogen ist, formal wie sprachlich. Auf unserem Flickenteppich aber müssen wir zwangsläufig stolpern oder ausrutschen.

Die Hoffnung trügt also, mittels Software könne man die unangenehme Forderung abwenden, sich anpassen zu müssen. Des alten Meisters Mahnung, Bauwerk und Umgebung in Einklang zu bringen, ist aktueller denn je.

6. Distributio (oikonomia)

Entwürfe sind die eine Seite des Bauschaffens, die Ausführung ist die andere. Dazu braucht man einen Bauplatz, Material, Werkzeug und Arbeitskräfte, also zuerst einmal Geld. Nicht jeder Bauherr ist ein Crassus oder Krösus, mithin muß der Architekt von Anbeginn der Planung die Kosten im Auge haben. Vitruv lobt in der Einleitung zum zehnten Buch die Weisheit der Stadtväter von Ephesus: sie hatten in früher Zeit schon ein Gesetz, das den Architekten persönlich haftbar machte für eine mehr als 25prozentige Überschreitung seines Kostenvoranschlags. "In der Beschränkung zeigt sich erst der Meister" konstatiert sehr viel später Goethe, aber bereits Vitruv sieht als integralen Bestandteil der Baukunst die Fähigkeit, mit gegebenen Mitteln nicht nur irgendwie auszukommen, sondern das Bestmögliche daraus zu machen. Breiten Raum nehmen deshalb in seinen Büchern auch die Ausführungen über Baumaterialien einschließlich ihrer Gewinnung oder Herstellung ein, bis hin zu den Farbstoffen.
Von Verschwendung war unter Punkt 2 ("Dispositio") schon die Rede. Man muß sich nur einmal ansehen, um einen Begriff vom heutigen Ausmaß zu gewinnen, wie Metadatan nach "Dublin Core" codiert werden: Verpackung und Inhalt stehen ohne echte, sachliche Notwendigkeit in einem nie dagewesenen Mißverhältnis.
Ein anderes, besonders krasses Beispiel ist der Trend, für Datenbanken überall gleich Windows-NT hinzustellen. Das ist, als würde man ständig mit einem Möbelwagen durch die Gegend fahren, nur weil man gelegentlich mal eine Gartenbank zu transportieren hat.
Datenbankarchitekten machen sich nicht gern die Hände schmutzig. Besser gesagt, sie wissen meistens nicht viel über Hardware (sind aber natürlich selber immer gut ausgestattet). Anlaß zu gewisser Vorsicht besteht dann, wenn einem der Datenbankbaumeister ein paar schlichte Fragen nicht bündig beantworten kann, und zwar natürlich am besten mit Beispielen, also Erfahrungswerten, von realen Anwendungen:

1. Was ist die Hardware-Mindestvoraussetzung für einen Mitarbeiterplatz, für ein Netzwerk, für einen OPAC-Arbeitsplatz?
2. Wieviel Bytes muß man im Durschschnitt brutto für einen Datensatz veranschlagen? (D.h. einschließlich Indexdateien und anderem Zubehör)
3. Wie ist das Zeitverhalten beim Indexieren, d.h. beim Neuaufbau einer Datenbank? Insbesondere: wenn sich die Datenmenge verdoppelt, wie verhält sich die Zeit für das Indexieren?
4. Kann man neue Daten im laufenden Betrieb einmischen? Wie ist dabei das Zeitverhalten?
5. Wie lange braucht eine Reorganisation im Schadensfall (abhängig von der Größe), wenn man eine Sicherungskopie aktivieren und aktualisieren muß?
6. Muß man Wartungszeiten einkalkulieren, in denen die Datenbank nicht benutzt werden kann?
7. Ist eine Volltextsuche möglich? Wenn ja, wie lange dauert sie in einer Datenbank von 100.000 Sätzen?
8. Wenn von einem Datensatz ein Suchbegriff genau bekannt ist, wieviele Schritte (Bildschirme, Tasten) sind nötig, um ihn auf den Schirm zu bekommen?
9. Wie lange dauert in solchen Fällen der Zugriff auf einen Datensatz in einer Datenbank mit 1.000.000 Sätzen? Wie lange die Speicherung eines neuen Satzes, die Ausführung einer Korrektur?

Im Zweifel das Bewährte?

Vitruvius wurde wohl schon in seiner Zeit für einen Konservativen gehalten. Er preist seine Bücher zwar als vollständige Abhandlung über die Baukunst, aber einige Aufgaben, wie das Amphitheater oder den Wege- und Brückenbau läßt er aus, obwohl er letzteren unter Caesar früher selbst betrieben hatte. Auch fanden Kritiker z.B. heraus, daß er wohl nie in Athen war, aber so tut als ob. Aber ist das alles wichtig? Nicht seine konkreten Rezepte für das Betonmischen sind es, die sich über zwei Jahrtausende erhalten haben, nicht seine Proportionstabellen für Säulenordnungen geben uns heute noch Hilfestellung. Das Bewährte - das sind eben gerade seine Grundprinzipien, die nirgendwo ausdrücklich auf die Bewahrung des Überkommenen abzielen, sondern auf das Herausfinden des Tauglichen. Damit reicht er uns über die Jahrtausende eine Richtschnur herüber, die wir auch noch an unsere "virtuellen" Bauwerke anlegen können - bis vielleicht mal ein neuer kommt, "Virtuvius" könnte er als Pseudonym wählen, der uns eine bessere gibt.

Zum Abschluß eine nachdenkliche Frage: wie ist nun eigentlich ein relationales Datenbanksystem einzuordnen? Hat es dorische, ionische oder korinthische Züge? Nun, zunächst einmal ist es kein Tempel, sondern ein privater oder öffentlicher Zweckbau. Sein senkrecht-waagrechtes Erscheinungsbild mit lauter festgelegten Kästchen und Fächern legt eigentlich sofort die Zuordnung zur Sparte "Fachwerk" nahe. Über diese Bauweise hält Vitruv seine unverblümte Meinung nicht zurück (2,8,20): "Vom Fachwerk aber wollte ich, es wäre gar nicht erfunden worden."
 
 

Literaturangaben

[1] Es wurden drei Übersetzungen des erstmals um 30 v.Chr. erschienen Werkes verwendet:

Vitruv [Marcus Vitruvius Pollio]:
-- Des Vitruvius zehn Bücher über Architektur / Übers. und durch Anmerkungen und Risse erläutert von Franz Reber. - Stuttgart: Krais & Hoffmann, 1865. - X, 353 S.

-- Baukunst / Übers.: August Rode, Hrsg.: Beat Wyss, Einf.: Georg Germann, Anm.: Andri Gieré. - Zürich; München: Artemis, 1987. - Bd. 1.2. - ISBN 3-7608-8064-9  [Die Originalüberetzung. von Rode erschien 1795]

-- The ten books on architecture / transl. by Morris Hicky Morgan. - New York: Dover Publ., c1960. XII, 331 S. - ISBN 0-486-20645-9  [Die Originalübers. erschien 1914]
 

[2] Knell, Heiner: Vitruvs Architekturtheorie : Versuch einer Interpretation. - Darmstadt: Wissenschaftliche Buchgesellschaft, 1985. - XI, 191 S. - ISBN 3-534-09399-2

[3] Simon, Otto von: Die gotische Kathedrale : Beitr. zu ihrer Entstehung und Bedeutung. - Darmstadt: Wiss. Buchges., 1979. - VIII, 376 S. ; 48 Taf. - ISBN 3-534-04306-5

[4] Navigating the networks : Proc. of the ASIS Mid-Year Meeting, Porland, Oreg. May 21-25,1994. Ed. by Deborah Lines Anderson usw. - Medford, N.J.: ASIS, 1994. - 257 S. - ISBN 0-938734-85-7
Darin die Beiträge:
Leazer, Gregory H.: A conceptual schema for the control of bibliographic works. S. 115-135
Smiraglia, Richard P.: Derivative bibliographic relationships: Linkages in the bibliographic universe. S. 167-183.

[5] Killen, Michael: IBM - the making of the common view. - Boston: Harcourt Brace Jovanovich, 1988. - XX, 284 S. - ISBN 0-15-143480-8