Oracle zur Studienarbeit

Sehr geehrter Herr Klinger,

im Zuge meines Weiterbildungsstudienganges an der FH in Suderburg hatte ich mich entschieden eine Studienarbeit mit Datenbankanwendungen zu verfassen. Ich hatte Sie bereits letztes Jahr darauf angesprochen. Leider ließ die berufliche Situation den Beginn dieser Arbeit nicht zu und ich war gezwungen die Arbeit zu verschieben.

Derzeit bin ich noch dabei die Arbeitsgrundlagen zusammenzutragen. Das Ziel ist eine Datenbankanwendung mit Aufgaben im im Bereich von Baukosten, Angebotskalkulationen, Kostenverfolgung u.dgl.. Hierbei sind spezielle Lösungsansätze zur Dokumentation der Daten von nöten, die unter Einsatz handelsüblich verfügbarer Softwarelösungen einen sehr hohen Bearbeitungsaufwand bedeuten würden, aber aufgrund der geforderten, kurzen Antwortzeiten bei diesen Projekten zeitlich kaum realisierbar und von der Kostenseite nicht vertretbar sind.

Ausgangssitation ist eine bereits existierende Anwendung, basierend auf MS-Access, in die diese Zielsetung bereits teilweise eingearbeitet war. Diese DB ist eine von mir selbst realisierte Lösung mit deutlichen Strukturschwächen. Der Grund hierfür ist in der Entstehungsgeschichte dieser Anwendung zu suchen, die aus einer recht einfachen Aufgabenstellung zu einer Lösung mit recht komplexer Funktionalität gewachsen ist. Konzepte für diese Anwendung wurden nur in Fragmenten erstellt und meist nur aus der Not heraus, weiterentwickelt.

Alleine der Einsatz von Access verursacht schon eine ganze Reihe von Problemen: Die vorhandenen Datenmengen lassen sinnvoll kaum mehr als 2 User gleichzeitig zu. Die Netzlast ist ungeheur groß. Durch die Eigenheiten eines nativen Compilers kommt es immer wieder zu Konflikten mit DLL's. Der Funktionsumfang von Access ist begrenzt, so fehlen umfangreiche Bibliotheken zur Erstellung von Grafiken, die Belegung Datengebundener Listenfelder führt sehr schnell zum Überschreiten der möglich geöffneten Tabellen (das sind immerhin 1024). Die Sicherheit eines Backend im Bezug auf nicht autorisierte Zugriffe ist nicht ausreichend gelöst. Es stehen keine ausreichende Möglichkeiten zur automatischen Datensicherung und Datenkomprimierung zur Verfügung. Das System ist mit MS verheiratet.

Die Liste läßt sich sehr viel weiterführen.

Die Aufgabe muß ich auch ungeachtet der Studienarbeit lösen. Die Datenbank ist nun völlig neu zu konzipieren. Lediglich Teile der bestehenden Datenstämme sind zu erhalten, nicht deren Strukturen. Angedacht ist eine Client/Serverlösung deren Frontend in einer möglichst objektorientierten Sprache verfaßt ist, vorzugsweise Java. Das Backend soll mittels einer relationalen Datenbank realisiert werden. Hier ist Vorgabe eine möglichst geringe Netzlast zu erzeugen, um auch mit langsamen Zugriffstechniken, z.B. via Internet, ausreichend kurze Antwortzeiten zu erhalten. Die Arbeit im mobilen Einsatz soll möglich werden. Bei den Daten handelt es sich größtenteils um Angebotskalkulationen funktional ausgeschriebener Großobjekte im schlüsselfertigen Hochbau, die aufgrund ihrer Brisanz eine hohe Sicherheit bezüglich unautorisierter Zugriffe sowie der Datenerhalt fordern. Entsprechende Lösungen müssen erarbeitet werden.

Die Liste ist nicht vollständig, es soll nur das Vorhaben in groben Zügen wiedergeben. Um endgültig festzulegen welche Entwicklerwerkzeuge und Datenbanken zum Einsatz kommen ist eine Gegenüberstellung von MS-SQL 7.0 und Oracle von nöten. Hierzu wird zumindest eine Desktopversion benötigt, sowie die Kosten der Lizenzierung. Oracle scheint mittlerweile von den Softwarelieferanten nicht mehr vertrieben zu werden und wäre für die Information dankbar wo man die Software beziehen kann und welche Möglichkeiten es gibt eine voll funktionsfähige Lösung wenigstens für den Zeitraum der Grundlagendiskussion zu bekommen.

Die endgültige Formulierung wollte ich erst nach diesen grundsätzlichen Entscheidungen vornehmen und etwa bis Ende August anfertigen. Nach Vorlage der Aufgabenstellung sollte man dann einen Termin in Hannover, nach Ihren zeitlichen Möglichkeiten vereinbaren.

freundliche Grüße
Adrian Herrmann Received on Wed Jul 03 2002 - 07:21:40 CDT