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.

08.09.1995

Client-Server-Datenmodellierung mit S-Designor Upsizing von Xbase auf SQL-Base mit Option auf Oracle-Umstieg

Als die Wohnungsbaugesellschaft Stuttgart (WGS) 1994 vor dem Problem stand, ihre gesamte Software von Xbase auf Client-Server umzustellen, musste sie auch ihre Datenstruktur neu definieren. Wie die WGS dabei vorging, beschreibt Ronald Knecht* im folgenden Beitrag.

Die Schwaben betreiben als Kerngeschaeft den Ankauf von Immobilien und deren Verkauf in bisher 35 geschlossenen Immobilienfonds im Grossraum Stuttgart. Im Hause war ein gigantisches Xbase-System (Clipper) herangewachsen, das alle dem Kerngeschaeft zugehoerigen Ablaeufe inklusive Datenaustausch mit den zirka 50 Vertriebsorganisationen regelte. Das System stellte einen wichtigen Wettbewerbsvorteil dar. Insbesondere bei den umfangreichen Listen und Reports kam die WGS jedoch zu Antwortzeiten, die den Umstieg auf eine andere Technologie zwingend erscheinen liessen. Ausserdem wollte die Gesellschaft den Unternehmensstandard Windows auch in die eigene Software einfuehren.

Fuer die in modernen Softwareprojekten so wichtige Datenmodellierung waehlte man das Werkzeug S-Designor (Professional Edition, Version 4.0), ein Windows- beziehungsweise Windows-NT- basiertes CASE-Tool zur Entity-Relationship-Modellierung. Ueber das Reverse-Engineering hinaus sprachen auch andere Kriterien fuer das Werkzeug. So wurde neben einer flexiblen Dokumentation Wert darauf gelegt, dass tatsaechlich alle Datenbankdefinitionen im Entity- Relationship-Modell abgelegt wurden und die Datenbank mit dem Modell synchron gefuehrt werden konnte.

Mit dem Tool liesse sich die referentielle Integritaet, also die logischen Beziehungen zwischen Tabellen, in einem allgemeingueltigen Modell definieren. Ferner hielt man sich die Moeglichkeit offen, spaeter von dem zunaechst gewaehlten Datenbanksystem SQL-Base von Gupta auf ein anderes System wie beispielsweise Oracle zu wechseln. Da sich das Design in ein konzeptionelles und ein physikalisches Modell trennen laesst, ist ein solcher Schritt einfach zu vollziehen, indem beim Uebergang vom logischen zum physikalischen Modell das neue Zielsystem gewaehlt und so alle Definitionen spezifisch fuer das neue System erzeugt werden.

Die WGS wollte bei ihrem Schritt in die Client-Server-Welt soweit wie moeglich herstellerunabhaengig bleiben. Eine solche Philosophie muss bereits beim Datenmodell anfangen. Natuerlich darf nicht verschwiegen werden, dass auch im physikalischen Modell Nacharbeiten notwendig sind. Jedes Datenbanksystem hat proprietaere Eigenschaften, die nicht in abstrakter Form in einem logischen Modell erfasst werden koennen. So waeren in jedem Fall die spezifischen Trigger nachzuarbeiten - auch wenn es in S-Designor vordefinierte Standard-Trigger fuer die referentielle Integritaet gibt.

Vor der Erstdefinition oder Erweiterung der Entitaeten stand die WGS vor der Aufgabe, die bestehende Datenstruktur der Dbase- Dateien in ein Modell zu bringen. Da es sich um zirka 90 Entitaeten handelte, wollte man diese nicht per Hand eingeben, zumal das nicht nur zeitraubend, sondern auch fehlertraechtig gewesen waere. Die Mitarbeiter bedienten sich der Reverse-Engineering-Faehigkeiten ihres Tools.

Ueber ein mitgeliefertes Werkzeug liess sich aus den DBF-Dateien ein Skript erzeugen, das direkt in ein physikalisches Modell eingelesen werden kann. Dieses "nackte" wurde dann in das logische Modell konvertiert und ueberarbeitet. Die Vorarbeiten bis zur eigentlichen Restrukturierung des Datenmodells dauerten lediglich einen Tag.

Die Restrukturierung des Datenmodells, die Normalisierung durch das Zusammenfuehren der Entitaeten, das Definieren der Domaenen, die Dokumentation und das Eintragen der Beziehungen sowie das Benennen der logischen Attributnamen statt der kryptischen Namen, die aus den DBF-Dateien uebernommen wurden, erstreckten sich etwa ueber zwei Wochen. Die Anzahl der Entitaeten war auf ungefaehr 70 geschrumpft. Die erstmalige Erstellung der physikalischen Datenbank war daraufhin nur noch einen Knopfdruck entfernt. Damit war der Grundstein fuer das Upsizing-Projekt der WGS gelegt.

Zwar stand vor Beginn der eigentlichen Codierung der einzelnen Softwareteile das Datenmodell weitgehend fest, doch es unterliegt - wie die Software selbst - einem staendigen Wandel. Deshalb legte die WGS Wert darauf, eine Aenderung des Modells sofort in der Datenbank nachvollziehen zu koennen. Den Entwicklern sollte die Moeglichkeit gegeben werden, permanent mit der aktuellen Version der Datenbank zu arbeiten - und zwar auch dann, wenn schon Daten darin enthalten sind.

Ueblicherweise ist das ein Problem, doch die WGS hatte die Moeglichkeit, sogenannte Alter-Skripte zu erzeugen. Diese enthalten die notwendigen SQL-Zeilen, so dass nur die Aenderungen an der Datenbankstruktur vorgenommen werden. Dies liess sich per ODBC durchfuehren, was einer enormen Zeitersparnis und Vereinfachung des Prozesses gleichkam.

Waehrend des gesamten Projektes wurden Versionen der Modelle in einem Versionskontrollsystem gehalten. Die verschiedenen Versionen, die in die Datenbank uebertragen wurden, konnten auch jeweils im Datenmodellierungs-Tool abgespeichert werden. Sie werden zwingend bei der Generierung der Alter-Skripte benoetigt. Eine weitergehende Versionskontrolle gibt es allerdings nicht - hier zeigt der S-Designor kleine Schwaechen.

Die Einarbeitungszeit fuer das Werkzeug war erstaunlich kurz. Dazu trug unter anderem der Grafik-Editor bei. Bei anderen Werkzeugen, die bei der Auswahl des Tools in Frage kamen, war die Arbeitsweise nicht so intuitiv zu erfassen. Die James Martin Notation, die verwendet wird, braucht - wie alle anderen Notationen auch - eine gewisse Eingewoehnung. Die Mitarbeiter hatten sie aber schon nach etwa ein bis zwei Tagen verinnerlicht.

Der Trigger-Editor soll genutzt werden

Zur Zeit wartet man bei WGS auf eines der staendig erscheinenden Maintenance-Releases. Da die neue Version des verwendeten Datenbanksystems SQL-Base von Gupta inzwischen auch Trigger und Stored Procedures unterstuetzt, moechte WGS diese sinnvollerweise auch in S-Designors Trigger-Editor definieren. Auf diese Weise will man gemaess des bisherigen Konzepts alle zur Datenbank gehoerenden Definitionen zentral in einem Werkzeug halten.

Der Hersteller SDP Technologies wurde kuerzlich von Sybase aufgekauft, will aber seine bisherige Produktphilosophie fortsetzen, so dass man sich fuer die naechsten Jahre im Hause WGS sicher fuehlt. Moeglicherweise laesst sich mit Hilfe des Softwarepartners nun auch die von den Stuttgartern gewuenschte Entwicklung eines Moduls zur Prozessmodellierung realisieren.

* Ronald Knecht ist Geschaeftsfuehrer von Knecht Consulting, einem System- und Beratungshaus im hessischen Egelsbach.