Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

06.07.1990 - 

Programmieren und Abrufen von Objekten

Datenbanken orientieren sich zunehmend an Objekten

Relationalen Datenbank-Management-Systeme (RDBMS) werden von den Anbietern zunehmend mit objektorientierten Eigenschaften ausgestattet. Die Palette reicht von der Möglichkeit zur Definition von benutzerspezifischen Datenobjekten bis zu objektorientierten Anwendungs-Entwicklungs-Umgebungen. Im Idealfall ergänzen sich die Objekt-Fähigkeiten der einzelnen Komponenten.

Bei einem modernen Datenbanksystem ist grundsätzlich zu unterscheiden zwischen dem Datenbankserver (Back-end) und dem Datenbank-Client (Front-end). Um ein relationales Datenbank-Management-System mit objektorientierten Eigenschaften auszustatten, sollten beide Seiten über entsprechende Leistungsmerkmale verfügen.

Objektorientierung von der Serverzeite aus

Ein relationales DBMS mit Objekt-Management erlaubt dem Benutzer die Definition neuer Datenobjekte. Dazu gehören zum Beispiel Artikelkodierungen, geografische Koordinaten, Temperaturen und Zeitserien. Der Vorteil: Durch die Definition branchen- oder applikationsspezifischer Objekte läßt sich die Programmierung vereinfachen und damit der Anwendungscode reduzieren.

Der Anwender sollte in der Festlegung seiner Objekte völlig frei sein. Zudem ist wichtig, daß sie nicht nur gespeichert und abgerufen werden können, sondern sich auch mit entsprechenden Operatoren (+, -, *,>,< ,=) manipulieren lassen. Nur dadurch können die benutzerdefinierten Objekte uneingeschränkt in die Verarbeitung etwa durch Datenbankabfragen mit SQL einbezogen werden. Die Voraussetzung hierfür ist, daß der Benutzer nicht nur eigene Objekte, sondern auch eigene Funktionen und Operatoren definieren kann.

Der Code für die Unterstützung neuer Datenobjekte wird üblicherweise in einer Programmiersprache der dritten Generation - meist in C - abgefaßt und in den Datenbank-Manager eingebunden. Dadurch erreicht man, daß die Performance benutzerdefinierter Objekte mit der von Standard-Datentypen gleichwertig ist.

Objektorientierung auf der Client-Seite

Die Entwicklung in Richtung Objektorientierung auf der Client-Seite hängt unmittelbar mit der Verbreitung von Bildschirm-Arbeitsplätzen und dem Wunsch nach grafischen Benutzeroberflächen zusammen.

Über 300 Millionen Menschen weltweit arbeiten nach Schätzungen des Marktforschungs- und Beratungsunternehmens IDC heutzutage an Bildschirm-Arbeitsplätzen. Zum Vergleich: Vor zehn Jahren gab es nur etwa 50 Millionen "Bildschirm-Arbeiter", vor 20 Jahren gar nur knapp eine Million. Kamen früher bloß die EDV-Spezialisten mit Computern in direkte Berührung, so reicht heute die Palette von DV-Laien als Endbenutzer vom Teenager über den Sachbearbeiter bis zum Manager. Diese Entwicklung geht einher mit der Verbreitung von Minicomputern, Workstations und Personal Computern.

Kryptische Anweisungsfolgen

Begnügten sich die EDV-Experten früherer Jahre mit kryptischen Anweisungsfolgen für die Bedienung der Rechner, so erwartet der heutige Endbenutzer zu Recht bedienerfreundliche Software-Oberflächen. Überlappende Bildschirmfenster, Maussteuerung, Symbole zum Anklicken, Rollbalken, grafische Knöpfe und Regler - die Liste der objektorientierten Komfortmerkmale ist lang.

Im Xerox-Parc-Labor Ende der 70er Jahre entwickelt, hat Apple diese Oberflächen-Technologie mit dem Macintosh 1984 erstmals einem breiten Publikum vorgestellt. Mittlerweile hat die grafische Benutzeroberfläche durch Microsoft Windows und den Presentation Manager weite Kreise im PC-Bereich gezogen. Im Workstation-Markt hält die grafische, also am Objekt orientierte Bedienung durch Produkte wie OSF/Motif, Open Look und DEC-Windows Einzug.

So attraktiv grafische Oberflächen für den Endbenutzer sind, so problematisch stellen sie sich für den Anwendungsentwickler dar. Der Grund: Die Programmierung des Bedienungskomforts ist äußerst aufwendig. Untersuchungen haben gezeigt, daß bei der Entwicklung einer typischen Workstation-Applikation etwa 60 Prozent des Codes auf die Programmierung der grafischen Benutzerschnittstelle entfallen - und das bei Verwendung einer Standardoberfläche wie etwa Windows oder Motif Hierfür gibt es zwei wesentliche Gründe: die Produktivitätshemmnisse der immer noch häufig verwendeten Programmiersprachen der dritten Generation (3GL) und die Komplexität der Toolkits für die Programmierung grafischer Oberflächen.

Während sich das Preis-Leistungs-Verhältnis bei Hardware seit Jahren drastisch verbessert, wird Software nach wie vor "von Hand" codiert. Mit einer Programmiersprache der dritten Generation wie Cobol oder C liegt die durchschnittliche Arbeitsgeschwindigkeit eines verzierten Software-Entwicklers bei zehn ausgetesteten und fehlerfreien Codezeilen pro Tag.

Moderne Applikationen umfassen indes Hunderttausende von Zeilen. Diese Mengenproblematik wird noch verstärkt, wenn es um grafische Benutzeroberflächen geht. Sie stellen nichts anderes dar als Funktionsbibliotheken, auf die der Entwickler zugreifen kann. Die Benutzung der Bibliotheken ist jedoch nicht nur mühsam, sondern zudem für jede einzelne Oberfläche unterschiedlich.

Bedienungskomfort kann als Bremse wirken

Diese Entwicklung ist um so kritischer, als die Marktbeobachter der Aberdeen Group schätzen, daß 1992 etwa 70 Prozent aller neuen Software-Applikationen mit einer grafischen Oberfläche entwickelt werden. Damit entwickelt sich der moderne Bedienungskomfort, der für die Akzeptanz von Computern beim Endbenutzer von hoher Bedeutung ist, möglicherweise zum "Bremser".

Anwendungen können - da sie modern sein sollen - nur schleppend verfügbar gemacht werden. Der Aufwand hierfür lohnt sich zudem nur für die populären Standardapplikationen, die eine breite Abnehmerschaft finden. Firmenspezifische Anwendungen und Branchenlösungen, die keine Millionenbeträge erlösen, rechtfertigen beim Einsatz herkömmlicher Methoden den Aufwand einer modernen Oberfläche nicht. Andererseits entsprechen Applikationen ohne grafische Schnittstelle kaum noch dem Stand der Technik.

Einen Ausweg aus dem Dilemma bietet der Einsatz von objektorientieren Programmiersprachen der vierten Generation (4GL) sowie die Verwendung von grafischen Anwendungs-Entwicklungsumgebungen. Durch diese Kombination lassen sich moderne Applikationen mit zeitgemäßer Bedienerschnittstelle zu einem akzeptablen Preis erstellen.

Hierbei sollte die grafische Umgebung den interaktiven Aufbau von anwendungsspezifischen grafischen Software-Oberflächen unterstützen, während 4GL die Basis für die Entwicklung von Programmabläufen darstellt. Dadurch können moderne Workstation-Anwendungen in etwa einem Zehntel der Zeit erstellt werden, die bei Verwendung herkömmlicher Sprachen und Tools erforderlich wäre.

Eine Applikation, die in einer Programmiersprache der dritten Generation Tausende von Codezeilen benötigt, läßt sich durch eine objektorientierte 4GL-Sprache in einigen hundert Zeilen abfassen. Dabei wird nicht nur die Produktivität bei der Erstellung erhöht, sondern auch bei der Wartung der Softwareprodukte. Das ist um so bedeutsamer, als die Anwender nach Schätzungen heutzutage rund 60 Prozent ihrer Software. Aktivitäten auf die Wartung und Modifizierung bestehender Applikationen verwenden.

Wichtig dabei: Mit der 4GL erstellte Applikationen müssen sich nahtlos in die jeweilige Hardware- und Software-Umgebung einpassen. Die Unabhängigkeit von der jeweils verwendeten grafischen Benutzeroberfläche sollte auf jeden Fall gewährleistet sein. Hierbei präsentiert sich die Anwendung idealerweise automatisch im "look and feel" der jeweiligen Oberfläche, so daß der Benutzer intuitiv mit der Applikation umgehen kann.

Zu einer objektorientierten Anwendungs-Entwicklungsumgebung gehören noch weitere Leistungsmerkmale, etwa Kommandos für die Maussteuerung. Grafische Objekte sollten direkt mit Datenobjekten und/oder direkt mit 4GL-Code verknüpft werden können. Wichtig ist auch, daß die Objektorientierung von Datenbankserver und -Client aufeinander abgestimmt sind: Im Server abgelegte komplexe Datenobjekte müssen in der 4GL-Umgebung ohne weiteres verarbeitbar sein.

Durch die Anreicherung mit objektorientierten Eigenschaften offerieren relationale Datenbanksysteme neue Einsatzmöglichkeiten. Ein typisches Beispiel hierfür stellen Multimedia-Applikationen dar. Denken wir an eine Künstleragentur, bei der die Daten einer Reihe von Musikbands in der Datenbank gespeichert sind. Anhand von Kriterien (etwa Musikrichtung) können Bands herausgesucht werden. Dabei ist nicht nur die jeweilige Musikgruppe auf dem Bildschirm zu sehen, sondern auch der "Sound" hörbar. Sicherlich gibt es eine Vielzahl nützlicherer Applikationen - dennoch zeigt dieses Beispiel deutlich die Möglichkeiten objektorientierter Datenbanken auf.