MÜNCHEN - "Benutzerkomfort und Intelligenz müssen entweder mit erhöhter Rechnerkapazität oder einem Performance-Abfall erkauft werden." Auf diese prägnante Aussage führen DB-Spezialisten die Probleme zurück, die heute noch den Einsatz relationaler Datenbanken erschweren. Auswege aus diesem Dilemma allerdings sind vorhanden und müssen nicht immer teuer sein.
Schon von ihrer Konzeption her beinhalten relationale Datenbanksysteme eine Diskrepanz: Angenähert an die assoziativen Strukturen menschlicher Gedankengänge, leidet der Einsatz dieser Datenbanken unter dem sequentiellen Aufbau herkömmlicher "Von-Neumann "-Rechner.
Dietmar Bothe, Vertriebsleiter für Datenbankmaschinen der GEI in Aachen, erklärt: "Das Problem des Einsatzes relationaler Software-Datenbanken liegt darin, daß umfangreiche Tabellen durch den Hauptspeicher durchgeschleust werden müssen."
Dies entspräche in etwa einem Bild, bei dem Haare (=Files) durch einen Kamm gezogen würden. Durch diese hohe Belastung leide die Durchsatzgeschwindigkeit insbesondere dann, wenn der Computer noch andere Aufgaben zu erledigen habe.
Herbert Neumaier, Geschäftsführer der Interface Concilium GmbH aus München, findet andere Worte, um dieses Phänomen zu erklären: Bei komplizierten logischen Verknüpfungen müssen alle beteiligten Listen abgefragt werden.
Hier heiße es, entweder mit der Hardware-Leistung "zu klotzen" oder unter gegebenen Voraussetzungen Disziplin und Logik bei der Organisation der Datenbank einzusetzen.
Das A und O dabei liege in einer "ordentlichen" Datenmodellierung, denn allein anwendungsorientierte Struktur des Datenaufbaus könne zu einer Optimierung beitragen. Bei diesem Modellierungsvorhaben soll vor allem auf die Verbindung der Datenobjekte untereinander Wert gelegt werden - nach ihrer Benennung und einer grafischen Darstellung liege der nächste Schritt darin, eine geschickte Struktur zu erarbeiten.
Für große Datenmengen erscheint dieses Problem nicht trivial.
Im zweiten Optimierungsschritt ist zu überlegen, ob nicht Anfrage und Update zeitlich zu trennen sind. So ergaben Untersuchungen, daß bis zu 90 Prozent der Nutzung einer relationalen Datenbank Abfragen betreffen; der Rest sind dann Updates.
Es sei deshalb zu überlegen, ob nicht die Auskünfte über eine gekoppelte" DB ausgeführt werden können, oder aber Updates - freilich unter einem vertretbaren Verlust der Informationsgeschwindigkeit - nur zu bestimmten Zeiten durchgeführt werden sollten.
Der parallele, permanente Update, so die Erfahrung Neumaiers, biete oft mehr Luxus als notwendig.
Auch Dietmar Bothe plädiert für eine Trennung zwischen Update und Abfrage. Eine weitere Möglichkeit, Performance-Probleme bei Einsatz relationaler Datenbanken zu umgehen, beinhaltet die Chance, durch Multimomentaufnahmen ein repräsentatives Bild der getätigten Anfragen zu erarbeiten. Bei dieser Vorgehensweise wird jede x-te Anfrage an die DB analysiert; aus diesen Ergebnissen können dann Daten und Zugriffsstrukturen angepaßt werden. Häufige Suchvorgänge stehen dann in der Priorität an erster Stelle. Der Vorteil dieser Methode liegt darin, daß sowohl Abfragegewohnheiten als auch ihre. Veränderungen mit statistischen Mitteln erkannt werden können.
Die Optimierung der Datenverteilung auf den Speichermedien eignet sich als weiterer Schritt, relationale Datenbanken den Erfordernissen der Anwender anzupassen. So können Nutz- und Verwaltungsinformationen auf verschiedenen Medien abgespeichert werden; die Response-Time verkürzt sich entsprechend.
Die GEI geht bei ihren Tuning-Überlegungen noch einen kleinen Schritt weiter: Dietmar Bothe plädiert für eine Vorauswertung der Daten in solche, die sich wenig oder häufig ändern.
Der Geschäftsführer der Interface Concilium, Herbert Neumaier, regt darüber hinaus an, Datenbanken etwa nach geografischen Gesichtspunkten oder anderen Kriterien aufzusplitten, um dadurch Response-Zeiten zu verkürzen.
Eine Möglichkeit, relationale DBs schneller zu machen, liegt darin, aus Daten mathematische Prozesse zu konstruieren. So erscheint es sinnvoll, nicht eine neue Umsatzdatei anzulegen, sondern aus den Werten für "Preis mal Menge" die gewünschte Tabelle des Umsatzes im Moment der Abfrage zu generieren. Die Rechenzeit für diese Art des Tunens erscheint aus der Erfahrung heraus unerheblich.
Krankten die relationalen Datenbanken bislang noch häufig daran, daß das Antwortverhalten den Benutzeransprüchen nicht immer gerecht wurde, so zeichnet sich mittlerweile eine Wende durch den Einsatz von "reinen" DB-Rechnern ab.
Auch der Benutzer, der aus psychologischen Aspekten heraus nur längere Antwortzeiten bei Updates akzeptiert, bei Anfragen aber schnell bedient werden möchte, findet heute in den DB-Maschinen Preis-Leistungsbezogene Möglichkeiten, seine Informationsbedürfnisse zu befriedigen.
Diese junge Technologie, die nach Meinung der Experten am Anfang eines Booms steht, verlangt allerdings auch intensive organisatorische Vorüberlegungen.
So bietet sich als Alternative zu dem unbeliebten "Hardware-Klotzen" beim Einsatz einer Software-Datenbank die Möglichkeit, zentrale Datenbanken auf einen spezialisierten Rechner zu ziehen, der dann sternförmig oder über andere Netzkonfigurationen dezentral eingesetzte Systeme als Vorrechner nutzt. Er beschränkt sich dabei auf seine reine DB-Aufgabe des Suchens, Verknüpfen und Updatens.
Diese Vorgehensweise entspricht weitgehend auch den User-Wünschen, so meinen Datenbankexperten. Denn die reinen Software-Datenbanken sind nach Meinung von Dietmar Bothe bereits zu 90 bis 95 Prozent ausgereizt, so daß Verbesserungen nur noch mit überhöhtem Aufwand bei der Entwicklung erkauft werden könnten.
Der Ballast, der diese Systeme durch ihre interne Konkurrenz zu Applikations- und Systemsoftware behindert, könne in naher Zukunft nur durch eine Spezialisierung der Hardware-Aufgaben abgefangen werden - zumindest so lange, wie die sequentielle Rechnerarchitektur die DV-Szene bestimmt.