Entwicklung einer Datenbank zur Informationsverarbeitung und -verteilung im Projektmanagement

Masterarbeit aus dem Jahr 2004 im Fachbereich Informatik - Wirtschaftsinformatik, Note: 2,0, Leuphana Universität Lüneburg (Bauingenieurwesen), Sprache: Deutsch, Abstract: Inhaltsangabe:Problemstellung:§Meist ist der Einsatz eines kommerziellen Programms für ein Unternehmen die wirtschaftlichere Variante, als eine Softwareanwendung selbst zu entwickeln. Obwohl es auch im Bereich Projektmanagement mehrere Produkte gibt, welche viele Komponenten der Projektdatenbank erfüllen könnte, sind diese für die tägliche Arbeit des Projektmanagers (noch) nicht die erste Wahl. Der Hauptgrund ist sicherlich, dass die Projektdatenbank in der Anwendung und bei der Konfiguration der einzelnen Komponenten flexibler ist. Außerdem bieten die kommerziellen Produkte zu einem oft hohen Preis entweder gerade die eine erforderliche Komponente nicht, oder sind mit nicht benötigen Tools überfrachtet.§Trotzdem hat auch der bisherige Einsatz der eigenentwickelten Datenbank gezeigt, dass eine solche Anwendung nur so gut ist, wie deren Benutzer. Diese müssen bei der Eingabe der Daten die Vollständigkeit wahren und die vorhandenen Regeln einhalten. Gerade die korrekte und vollständige Erfassung der Eingabeparameter ist der Schlüssel für eine umfangreiche Dokumentation und verschiedene Auswertungsmöglichkeiten. Dies stellt aber eine Gratwanderung dar, zwischen der für viele Kollegen erforderlichen Flexibilität und der strukturierten Eingabe von Daten um diese weiter verarbeiten zu können. Gleichzeitig hängt die Akzeptanz bei den Bearbeitern aber entscheidend von einer flexiblen und leichten Bedienung ab. Das Ergebnis dieser Gratwanderung stellt eine wichtige Voraussetzung für den weiteren Einsatz der Datenbank dar.§Die Projektdatenbank selbst wurde im Laufe einer Projektbearbeitung aus der Praxis für die Praxis zunächst in MS Access 2000 entwickelt. Je nach Projektstadium wurden nach und nach weitere Module aufgenommen, so dass die Datenbank bis zuletzt lebte . Der Mehrbenutzerbetrieb und die Weiterentwicklung der Datenbank machte eine Migration in eine Front und Back End Lösung erforderlich. Dies erfolgte mit ODBC da die meisten Funktionen nach dem Upsizen unverändert funktionierten. Bei einem ADP wäre ein erheblicher Umstellungsaufwand erforderlich gewesen, dafür ist die Anwendung mit per ODBC eingebundenen Tabellen etwas langsamer. Ein weiterer Grund für ODBC ist die Akzeptanz bei den Benutzern, da ODBC bekannter ist, als ADO, DAO oder Access Projekt.§Benutzer die bisher lediglich mit den Office Produkten von Microsoft (speziell Access) arbeiteten, stellt die Arbeit mit dem SQL Server eine neue Herausforderung dar. So ist nicht nur die Herstellung der Beziehungen zwischen Tabellen strengeren Konventionen unterworfen, sondern auch die Auswahl der Datentypen und Feldgrößen. §Das Migrieren der Datenbank erfolgte mit wenigen Fehlern nahezu reibungslos und die anfängliche Skepsis gegenüber diesem Weg hat sich nicht bestätigt. Lediglich die Mergereplikation und das Einrichten der Benutzer erforderte intensive Überlegungen und mehrere Erprobungen. Festzuhalten ist auch, dass die Thematik des Mehrbenutzerbetriebs und hiermit verbunden der Isolationsstufen und Sperren, durch den SQL Server in der Standardeinstellung für die Projektdatenbank ausreichend gelöst wird.§Als sehr interessante Recherche zeigte sich das Thema Trigger. Der Sinn und Zweck deren Einsatzes, wird zwischen den Fachleuten intensiv bis leidenschaftlich diskutiert. Zusammenfassend sehe ich deren Einsatzgebiet hauptsächlich zur Erfüllung von transitionalen Integritätsbedingungen und, wenn die von Einschränkungen wie z.B. der referenziellen Integrität unterstützten Funktionen nicht die Funktionalitätsanforderungen der Anwendung erfüllen. Gerade da Zeitereignisse, DBMS Ereignisse und select Ereignisse nicht unterstützt werden und Trigger sich eigtl. auf Modifikationsoperationen beschränke...