Lade Inhalt...

Entwicklung einer Datenbank zur Informationsverarbeitung und -verteilung im Projektmanagement

©2004 Masterarbeit 137 Seiten

Zusammenfassung

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 […]

Leseprobe

Inhaltsverzeichnis


ID 8666
Schropp, Edgar: Entwicklung einer Datenbank zur Informationsverarbeitung und
-
verteilung im Projektmanagement
Hamburg: Diplomica GmbH, 2005
Zugl.: Fachhochschule Nordostniedersachsen, MA-Thesis / Master, 2004
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2005
Printed in Germany

Inhaltsverzeichnis
Masterarbeit Edgar Schropp
1
EINLEITUNG ... 1
1.1
AUFGABENSTELLUNG... 1
1.2
BERUFLICHER WERDGANG ... 2
1.3
AUSGANGSSITUATION... 3
1.4
BISHER EINGESETZTE MITTEL... 3
1.5
MÖGLICHKEITEN DER PROJEKTDATENBANK ... 4
2
ENTWURF DER RELATIONEN DATENBANK ... 6
2.1
ENTWURFSPHASEN ... 6
2.1.1
ANFORDERUNGSANALYSE ... 6
2.1.2
KONZEPTIONELLER ENTWURF (ER-MODELL) ... 7
2.1.2.1
Konzeptionelles Schema... 7
2.1.2.2
Objektschicht... 7
2.1.2.3
Datenschicht... 7
2.1.3
VERTEILTER ENTWURF... 8
2.1.4
LOGISCHER ENTWURF (RELATIONENMODELL) ... 8
2.2
VOM ER - MODELL ZUM RELATIONENMODELL ... 8
2.2.1
ENTITY-TYPEN ... 9
2.2.2
BEZIEHUNGS-TYPEN... 9
2.3
ZUSAMMENFÜHREN DER INFORMATIONEN DER EINZELNEN TABELLEN ... 9
2.3.1
1:N BEZIEHUNG...10
2.3.2
M:N BEZIEHUNG ...10
2.3.3
1:1 BEZIEHUNG ...10
2.3.4
DEFINIEREN VON BEZIEHUNGEN IM MS ACCESS ...10
2.4
UMSETZUNG RELATIONENMODELL IN SQL-DDL (DATENBANK DEFINITION)...11
2.5
PHYSISCHER ENTWURF...12
2.6
IMPLEMENTIERUNG UND WARTUNG ...12
2.7
ÜBERBLICK ÜBER DIE BEZIEHUNGEN DER DATENBANK...12
3
KONZEPTION, UMSETZUNG UND IMPLEMENTIERUNG ... 13
3.1
INSTALLATION DER DATENBANKANWENDUNGEN ...13
3.1.1
TECHNISCHE VORAUSSETZUNGEN ...13
3.1.2
PROGRAMMADMINISTRATION ...13
3.1.3
INSTALLATION DER DATENBANK-ANWENDUNGEN AUF SERVER UND CLIENT...13
3.1.4
HERSTELLEN DER VERKNÜPFUNG FRONT UND BACK END DATENBANK ...14
3.1.5
PROGRAMMSTART ...17
3.1.6
VERWEISE IN ACCESS ...17
3.2
FUNKTIONEN DER DATENBANK ...18
3.2.1
BENUTZERSICHTEN UND ZUGRIFFSRECHTE ...18
3.2.2
STARTMASKE ...18
3.2.3
VOREINSTELLUNGEN ...19
3.2.3.1
Kategorie der Beteiligten...19
3.2.3.2
Art der Beteiligten ...19
3.2.3.3
Projektbeteiligte...19
3.2.3.4
Firmen ...20
3.2.3.5
Besprechungsarten...21
3.2.3.6
Berichtswesen...22
3.2.3.7
Gliederungspunkte Besprechung ...23
3.2.3.8
Eingabe Referenzen...24
3.2.3.9
Eingabe Status Erledigungspunkt ...24
3.2.3.10
Übergeordnete Filter für Erledigungsliste ...24
3.2.3.11
Kriterien definieren für Erledigungsliste...25
3.2.3.12
Gebäudegeometrie (Bauteile, Geschosse, Raumliste) ...25
3.2.3.12.1
Gebäudebauteile ...25
3.2.3.12.2
Ebenen ...26
3.2.3.12.3
Raumliste ...26
3.2.3.12.4
Raumbuch ...26
ERLEDIGUNGSLISTEN UND BESPRECHUNGSBERICHTE...27
3.2.4
STRUKTURIERUNG DER EINGABE ...27
3.2.5
IMPORT ERLEDIGUNGSTERMIN IN MS OUTLOOK ...27
3.2.6
AUFBAU EINER ARCHIV- UND WISSENSDATENBANK ...27
3.2.7
NUTZEN ALS PROJEKTSTEUERUNGS-TOOL ...28
3.2.8
AUSGABE DER BESPRECHUNGSERGEBNISSE ALS BERICHT ...28
3.2.9
AUSGABE DER BESPRECHUNGSERGEBNISSE ALS HTML SEITE...28
3.3
INVERZUGSETZUNGEN PLANER UND FIRMEN...28
3.4
PLANMANAGEMENT ...29
3.5
BEMUSTERUNGEN ...29
3.6
LEISTUNGEN IM RAHMEN DER BAUAUSFÜHRUNG...29
3.6.1
BEDENKENANMELDUNGEN ...30

Inhaltsverzeichnis
Masterarbeit Edgar Schropp
3.6.2
BEHINDERUNGSANZEIGEN...30
3.6.3
MEHRKOSTENMELDUNGEN ...30
3.6.4
NACHTRAGSANGEBOTE ...30
3.6.5
RECHNUNGSBUCH...31
3.7
MÄNGELMANAGEMENT ...31
3.8
TERMINVERFOLGUNG DER AUSFÜHRUNG...31
3.9
ERSTELLUNG EINES GEWÄHRLEISTUNGSTERMINPLANS ...32
3.10
ZUSÄTZLICHE LEISTUNGEN DES BÜROS...32
3.11
LISTE VERTEILTER UNTERLAGEN ...32
3.12
ALLGEMEINE NOTIZEN ERFASSEN ­ TAGEBUCH ...32
3.13
IMPORT VON TERMINEN IN MS OUTLOOK ...32
4
UMSETZUNG IN FRONT UND BACK END LÖSUNG ... 33
4.1
EINSCHRÄNKUNGEN BEI DER VERWENDUNG VON ACCESS...33
4.2
EINSATZ DES MICROSOFT SQL-SERVER 2000 ...33
4.2.1
DIE WICHTIGSTEN KOMPONENTEN DES SQL-SERVERS ...34
4.2.2
DIE WICHTIGSTEN TECHNIKEN DES SQL-SERVERS ...34
4.2.3
DIE VERSCHIEDENEN VERSIONEN DES SQL-SERVERS ...35
4.2.4
SYSTEM-DATENBANKEN DES SQL SERVER ...35
4.2.5
VERGLEICH MS SQL UND MS ACCESS...36
4.2.6
TRENNEN DER DATENBANK MIT DEM UPSIZING ASSISTENT...36
4.2.7
FRONT-END UND BACK-END DATENBANK - ANWENDUNG ...36
4.2.8
START DES SQL SERVER DIENST MANAGER VOR UPSIZING ...38
4.2.9
UPSIZING VON ACCESS 2002 AUF SQL SERVER...38
4.2.10
VORTEILE DES CLIENT/SERVER-DATENBANKSYSTEMS IM VERGLEICH ZU ACCESS ...39
4.2.10.1
Sicherung der Daten bei Hardware-Fehlern...39
4.2.10.2
Sicherung der Daten gegen Bedienungsfehler ...40
4.2.10.3
Speichern großer Datenbestände...40
4.2.10.4
Steigerung des Durchsatzes...40
4.2.11
VORTEILE EINER VERKNÜPFUNG MIT SQL SERVER ...41
5
MEHRBENUTZERBETRIEB, SYNCHRONISATION UND REPLIKATION ... 43
5.1
UNTERSCHEIDUNG DER BEGRIFFE...43
5.2
MEHRBENUTZERBETRIEB DER BACKEND - DATENBANK...43
5.2.1
MÖGLICHKEITEN DER DATENKONTROLLE ...43
5.2.2
DER BEGRIFF TRANSAKTION ...44
5.2.2.1
Das ACID Prinzip ...44
5.2.2.2
Erzwingen der Transaktion ...44
5.2.2.3
Anomalien bei unkontrollierten Mehrbenutzerbetrieb...45
5.2.3
TRANSAKTIONSVERWALTUNG ...46
5.2.4
PROTOKOLL- UND WIEDERANLAUF-EINHEIT - (LOGGING & RECOVERY) ...46
5.2.5
MEHRBENUTZER-SYNCHRONISATION (CONCURRENCY CONTROL) ...47
5.2.5.1
Sperrverfahren ...48
5.2.5.1.1
Setzen der Sperren durch den Scheduler...49
5.2.5.1.2
Das strenge 2-Phasen-Sperrprotokoll ...49
5.2.5.1.3
Manuelle und automatische Sperren ...50
5.2.5.1.4
Granularität ...50
5.2.5.2
Sperrenarchitektur bei SQL Server ...51
5.2.5.3
Sperrmodi in SQL Server...52
5.2.5.4
Isolationsstufen...52
5.2.5.5
Parallelitätsarchitektur ...53
5.2.5.6
Cursorparallelität...54
5.2.5.7
Zusammenfassung der Mechanismen des SQL Server ...55
5.2.6
ZUGRIFFSBESCHRÄNKUNG - BERECHTIGUNGEN FÜR DIE DATENBANK ...55
5.2.6.1
Erstellen von Sicherheitskonten ­ neuer Benutzer ...56
5.2.6.2
Die Sicherheit bei der Benutzung der Projektdatenbank ...57
5.2.6.3
Verwalten von Berechtigungen auf dem SQL Server ...58
5.2.6.3.1
Objektberechtigungen...58
5.2.6.3.2
Anweisungsberechtigungen...58
5.2.6.3.3
Implizite Berechtigungen ...59
5.2.6.4
Löschen von Datenbankobjekten durch Benutzer...59
5.2.6.5
Zugriffskontrolle in MS ACCESS ohne SQL Server...59
5.3
KONSISTENTER DATENBESTAND ...59
5.3.1
KONSISTENZ IN ZUSAMMENHANG MIT INTEGRITÄTSBEDINGUNGEN ...59
5.3.2
KONSISTENZ IN ZUSAMMENHANG MIT DER TOPOLOGIE ...61
5.3.2.1
Zentraler Datenbestand ...61
5.3.2.2
Verteilte Datenhaltung ...61
5.3.2.3
Replikation ...61
5.4
EINFÜHRUNG IN DIE REPLIKATION ...62
5.4.1
UNTERSCHEIDUNG REPLIKATION UND SYNCHRONISATION ...62
5.4.2
EINSATZGEBIETE UND VERWENDUNGSBEREICHE DER REPLIKATION...62

Inhaltsverzeichnis
Masterarbeit Edgar Schropp
5.4.3
VORTEILE DER REPLIKATION ...63
5.5
ARTEN VON REPLIKATIONEN...64
5.5.1
SYMMETRISCHE UND ASYMMETRISCHE KONFIGURATION...64
5.5.2
SYNCHRONE UND ASYNCHRONE KONFIGURATION ...64
5.6
DATENBANKREPLIKATION MIT DEM MS SQL-SERVER ...64
5.6.1
REPLIKATIONSMODELL ...64
5.6.1.1
Verleger...65
5.6.1.2
Verteiler...65
5.6.1.3
Abonnenten...65
5.6.1.4
Publikation ...65
5.6.1.5
Artikel ...66
5.6.1.6
Abonnement...66
5.6.1.7
Replikationsprozesse ...67
5.6.2
REPLIKATIONSTYPEN...67
5.6.3
FILTERN VON DATEN ...67
5.6.4
UNTERSCHEIDUNG DER REPLIKATIONSTYPEN...68
5.6.4.1
Snapshot-Replikation...68
5.6.4.1.1
Erläuterung ...68
5.6.4.1.2
Funktionsweise der Snapshotreplikation ...69
5.6.4.2
Transaktionale Replikation...70
5.6.4.2.1
Erläuterung Transaktionale Replikation...70
5.6.4.2.2
Funktionsweise der Transaktionsreplikation...72
5.6.4.3
Merge Replikation ...73
5.6.4.3.1
Erläuterung Merge Replikation ...73
5.6.4.3.2
Komponenten der Mergereplikation ...74
5.6.4.3.3
Funktionsweise der Mergereplikation beim SQL Server ...74
5.6.4.3.4
Planen der Mergereplikation...76
5.6.4.3.4.1
Timestamp-Spalten ...76
5.6.4.3.4.2
Datenintegrität...76
5.6.4.3.4.3
Fremdschlüssel ...76
5.6.4.3.4.4
Synchronisieren mit alternativen Synchronisierungspartnern...76
5.6.4.3.4.5
Konflikterkennung und -lösung...76
5.6.4.3.4.6
Trigger und Geschäftsregeln ...77
5.6.4.3.4.7
Text-, ntext und image-Datentypen in der Mergereplikation...77
5.6.4.3.4.8
Wartung von Online-/Offlineanwendungen...77
5.6.5
REPLIKATIONS-ASSISTENTEN...77
5.6.5.1
Publizierungs- und Verteilungskonfigurations-Assistent ...77
5.6.5.2
Publikationserstellungs-Assistent ...77
5.6.5.3
Pullabonnement-Assistent ...78
5.6.5.4
Pushabonnement-Assistent...78
5.6.5.5
Publizierungs- und Verteilungsdeaktivierungs-Assistent...79
5.6.5.6
Assistent zur Transformation von publizierten Daten definieren ...79
5.6.5.7
Assistent zum Erstellen dynamischer Snapshotaufträge...79
5.7
FUNKTIONSWEISE DER REPLIKATION...79
5.7.1
KONFIGURIEREN DER REPLIKATION ...79
5.7.2
GENERIEREN UND ANWENDEN DES ANFANGSSNAPSHOTS...80
5.7.3
ÄNDERN VON REPLIZIERTEN DATEN...81
5.7.4
SYNCHRONISIEREN UND WEITERGEBEN VON DATENÄNDERUNGEN...81
5.8
SYNCHRONISATION...81
5.8.1
SYNCHRONISATION VON DATEN ...81
5.8.2
ART DER SYNCHRONISATION IN BEZUG ZU REPLIKATIONSTYP...81
5.8.3
SYNCHRONISIERUNGSVERWALTUNG VON WINDOWS ...83
5.8.4
ÖFFNEN DER SYNCHRONISIERUNGSVERWALTUNG VON WINDOWS ...83
5.8.5
METHODEN ZUR SYNCHRONISATION...83
5.8.5.1
Direkte Synchronisierung ...83
5.8.5.2
indirekte Synchronisierung ...84
5.8.5.3
Internetsynchronisierung...84
5.8.6
SYNCHRONISIERUNGSKONFLIKTE ...84
5.8.6.1
Konflikterkennung und ­auflösung ...84
5.8.6.2
Arten von Konflikten bei der Mergereplikation...85
5.8.6.3
Konflikterkennung durch den Merge Agent ...85
5.8.6.4
Konfliktlösungsprozess ...86
5.8.6.4.1
Prioritätsbasierter Standardkonfliktlöser ...86
5.8.6.4.2
Benutzerdefinierte Konfliktlöser...87
5.8.6.4.3
Interaktiver und weitere Konfliktlöser ...87
5.8.6.5
Wahl des Konfliktlösers im Enterprise Manager ...88
5.8.6.6
Anzeigen von Konflikten mit dem Replikationskonflikt-Viewer ...88
5.9
IMPLEMENTIERUNG REPLIKATION UND MEHRBENUTZERBETRIEB ...89
5.9.1
FALLBEISPIEL 1: USER BEARBEITET DIE DATENBANK OFFLINE ...89
5.9.1.1
Schritte zur Konfiguration der Replikation...89
5.9.1.2
Wahl der Replikationsmethode ...90

Inhaltsverzeichnis
Masterarbeit Edgar Schropp
5.9.1.3
Publizierungs- und Verteilungskonfigurationsassistent ...90
5.9.1.4
Publikationserstellungs-Assistent ...91
5.9.1.5
Bearbeiten der Publikationszugriffslisten ...92
5.9.1.6
Aktivieren der Abonnenten ...92
5.9.1.7
Konfigurieren von Abonnements...93
5.9.1.7.1
Vorteile des Pullabonnement...93
5.9.1.7.2
Erstellen eines Pullabonnement ...95
5.9.1.8
Synchronisationen der Replikation ...95
5.9.1.8.1
Synchronisation im Netzwerk ...96
5.9.1.8.2
Synchronisation über das Internet ...96
5.9.1.9
Verwalten der Replikation...97
5.9.1.10
Offline Bearbeitung ...97
5.9.2
FALLBEISPIEL 2: PARALLELER ZUGRIFF DURCH ZWEI BEARBEITER...98
5.9.2.1
Verarbeitung der Fehlermeldungen...98
5.9.2.2
Nur lesender Zugriff auf Datensatz ­ Szenario 1...99
5.9.2.3
Datensatz speichern, in Zwischenablage oder verwerfen - Szenario 2 ...99
5.9.2.4
Meldung in SQL Server - Szenario 3 ... 100
5.9.2.5
Anpassen von Sperren und Isolationsstufen bei der Projektdatenbank ... 100
5.10
EINSATZ VON DATENBANKTRIGGERN... 101
5.10.1
ERLÄUTERUNG DES BEGRIFFS "TRIGGER"... 101
5.10.2
STRUKTUR EINES TRIGGER ... 103
5.10.3
VORTEILE UND NACHTEILE BEI DER VERWENDUNG VON TRIGGERN... 104
5.10.4
MÖGLICHE AUFGABEN FÜR TRIGGER... 105
5.10.5
AKTIVIERUNGSZEITPUNKT ­ BEFORE- UND AFTER-TRIGGER ... 106
5.10.6
ERSTELLEN EINES TRIGGERS IM ENTERPRISE MANAGER ... 107
5.10.7
REGELN FÜR DAS ANLEGEN VON TRIGGERN... 108
5.10.8
EINSATZ VON TRIGGERN ALS "BENUTZERDEFINIERTE INTEGRITÄT"... 108
5.10.8.1
Möglicher Einsatz für Trigger - diverse Beispiele ... 109
5.10.8.1.1
Nachträgliches Ändern des Erledigungsdatum ... 109
5.10.8.1.2
Automatisches Versenden einer Email ... 109
5.10.8.1.3
Protokollieren von Datenänderungen... 109
5.10.8.1.4
Einsatz bei der Replikation... 109
5.10.8.1.5
Integritätssicherung durch Trigger ... 109
5.10.8.2
Übergabe von Meldungen an eine Clientanwendung... 110
6
ANWENDUNGSBEISPIEL BERICHTSWESEN... 112
6.1
MODELLIERUNG DES DATENMODELLS ... 112
6.2
VERTEILTE SPEICHERUNG DES FORMULARS ERLEDIGUNG... 112
6.3
BEZIEHUNGEN ZWISCHEN DEN TABELLEN ... 113
6.3.1
1:N BEZIEHUNG MIT REFERENZIELLER INTEGRITÄT UND AKTUALISIERUNGSWEITERGABE... 113
6.4
EINGABE DER DATEN... 114
6.4.1
EINGABE DATEN IM RAHMEN DER VOREINSTELLUNG ... 114
6.4.1.1
Projektbeteiligte... 114
6.4.1.2
Besprechungsarten und deren Gliederungspunkte ... 114
6.4.1.3
Referenzen als Quelle der Information ... 115
6.4.1.4
Kennzeichnung des Erledigungsstandes... 115
6.4.1.5
Übergeordnete Filter und Kriterien zur erweiterten Filterung ... 115
6.4.1.6
Festlegungen der Gebäudegeometrie... 115
6.4.2
ERFASSUNG EINES OFFENEN PUNKTES... 116
7
ZUSAMMENFASSUNG ... 118
8
AUSBLICK ... 119
9
ANLAGEN ... 120
9.1
CD ZUR DOKUMENTATION... 120
9.2
EREIGNISPROZEDUR UND MODUL ZUR ÜBERNAHME VON TERMINEN IN OUTLOOK... 120
9.3
TRIGGER CODE... 121
9.3.1
TRIGGER ÄNDERUNGEN VERFOLGEN ... 121
9.3.2
TRIGGER FÜR KONTROLLKÄSTCHEN ERLEDIGT ... 122
9.4
BEZIEHUNGEN DER DATENBANK IM ÜBERBLICK ... 123
10
ABBILDUNGSVERZEICHNIS ... 124
11
GLOSSAR ... 126
12
AUTORENPORTRAIT... 128
13
ERKLÄRUNG ... 129
14
ENDNOTENVERZEICHNIS... 130

1 Einleitung
Masterarbeit Edgar Schropp
Seite 1
1
EINLEITUNG
1.1
AUFGABENSTELLUNG
Eine der wichtigsten Aufgaben im Projektmanagement von Bauvorhaben stellt die
Dokumentation und Weitergabe von Informationen dar. Damit eng verbunden sind
die Verfolgung von Terminen und die Verteilung von Aufgaben.
Aufgrund der Vielzahl von Projektbeteiligten, der teilweise immer diffizileren Prob-
lemstellungen und der immer kürzer werdenden Planungs- und Ausführungszeiten,
sind entsprechende Hilfsmittel erforderlich, um die eigentliche Projektmanagement-
leistung rationell, zuverlässig und termingerecht abzuwickeln. Für die Verarbeitung
von Informationen und Daten, stellt dabei eine Datenbank ein mächtiges Hilfsmittel
zur Bearbeitung dar.
Am Beispiel eines Projekts zur Erstellung eines Hotelneubau soll untersucht werden,
wie die bisher verwendeten, zum Teil sehr unterschiedlichen Informationsträger, sei
es Papier, ein Textverarbeitungsprogramm oder mehrere verschiedene Datenbanken,
als Insellösungen nun in einer Projektdatenbank sinnvoll zusammengefasst werden
könnten.
Im Rahmen der vorliegenden Masterarbeit soll ein netzwerkfähiges Datenbanksystem
für die Verwaltung und Bearbeitung der wichtigsten für ein Projektmanagement
relevanten Daten entwickelt werden.
Im Einzelnen sind folgende Teilaufgaben zu lösen:
Analyse des Datenmodells
Es wird untersucht, welche Anwendungsgebiete des Projektmanagements für eine
Integration in eine Projektdatenbank relevant sind und wie dies umgesetzt werden
kann. Das Datenbankmodell und der daraus abgeleitete Datenbankentwurf werden
analysiert.
Konzeption und Umsetzung
Um den Datenbestand von den Bearbeitungswerkzeugen und Auswertungsmodulen
zu trennen, wird eine Frontend-Backend-Architektur implementiert. Als Frontend wird
eine Microsoft-Access-Datenbank und als Backend eine Microsoft-SQL-Server-
Datenbank verwendet.
Anhand der darzustellenden Informationen und Daten sind im Frontend Oberflächen
zu strukturieren, welche die Informationen in angemessener und übersichtlicher
Weise für den Anwender darstellen. Dabei sind die Datenhierarchien mit entspre-
chenden Steuerelementen (Baumstruktur, Tabellen, Textfelder usw.) abzubilden. Es
wird eine menügesteuerte Benutzerführung für die Anwendung und seine Funktiona-
litäten der Daten entwickelt, sowie eine geeignete Zugriffskontrolle.
Die einzelnen Bestandteile der Datenbank und deren Funktionsweise werden be-
schrieben. Der Hauptbestandteil Berichtswesen wird im Rahmen der Masterarbeit als
durchgängiges Beispiel vom Entwurf im Datenbankmodell bis zur Darstellung des
Ergebnisses in einem Bericht erläutert.

1 Einleitung
Masterarbeit Edgar Schropp
Seite 2
Konzeption und Implementierung der Backend-Datenbank
Das Datenbankmanagementsystem soll einen Mehrbenutzerbetrieb ermöglichen. Es
soll geprüft werden, inwieweit die Backend-Datenbank entsprechende Werkzeuge
dafür zur Verfügung stellt. Insbesondere sollen
·
Datensatzsperrungen bei gleichzeitigem Benutzerzugriff zu analysieren,
·
Synchronisationsmechanismen untersucht werden
·
und so genannte Datenbanktrigger für die Konsistenzerhaltung des Datenbestan-
des auf ihre Einsatzfähigkeit hin überprüft werden.
·
Des Weiteren soll eine Verknüpfung des Datenbestandes mit anderen Softwareap-
plikationen wie z. B. MS Outlook betrachtet werden.
Durchgängiges Beispiel und Dokumentation
Alle Teilaufgaben sind dokumentiert. Die Ergebnisse werden im Rahmen eines Vor-
trages vorgestellt. Sämtliche für die Masterarbeit relevanten digitalen Dokumente,
insbesondere Dokumentationen und Programmcode, sind auf einem Datenträger (CD-
ROM) der Masterarbeit beigefügt.
1.2
BERUFLICHER WERDGANG
Seit 1996 bin ich in einem Büro für Projektmanagement im Bauwesen in München
tätig. Seitdem betreute ich mehrere Neubauvorhaben in den Geschäftsfeldern Pro-
jektsteuerung / -management.
Im März 2000 übernahm ich die Funktion der Projektleitung bei einem Hotelneubau
mit Herstellungskosten (Kostengruppe 2-6) in Höhe von 60 Mio. Euro netto. Der
Planungsbeginn erfolgte im Juni 2000, die Übergabe an den Bauherrn bzw. Nutzer
soll im Juli 04 durchgeführt werden. Im Rahmen unserer Beauftragung Projektmana-
gement und Projektleitung gemäß DVP Vertrag (Deutscher Verband der Projektsteu-
er) sind u.a. folgende Grundleistungen zu erbringen:
·
Projektstrukturplanung, sowie Aufbau und Abstimmung der Ablauforganisation mit
dem Auftraggeber
·
Organisation und Protokollierung des Besprechungswesens
·
Erstellen von Quartalsberichten und Mastervorlagen für den Bauherrn
·
Erstellen des Projekthandbuchs und Einrichtung des Projektservers für das Pla-
nungs- und Dokumentenmanagement
·
Qualitätssicherung der Planungs- und Ausschreibungsunterlagen
·
Sicherstellen des Nutzerbedarfsprogramms
·
Erstellen der Kostenberechnung nach DIN 276
·
Aufbau der Kostenverfolgung und Mittelabflussplanung
·
Rechnungsprüfung von Planungs- und Bauleistungen
·
Aufbau und Kontrolle des Änderungs- und Claimmanagements
·
Kontrollieren der Budgeteinhaltung während Planung und Ausführung
·
Erstellen, Überwachen und Steuern der Terminabläufe für die Vor-, Entwurfs- und
Ausführungsplanung, des Ausschreibungsverfahrens und der Bauausführung sämt-
licher Gewerke
·
Organisation der Abnahmen und Aufstellen der Gewährleistungstermine

1 Einleitung
Masterarbeit Edgar Schropp
Seite 3
Der o.g. Auszug unserer Leistungen zeigt bereits, dass es sich um ein sehr an-
spruchsvolles Projekt handelt, welches trotzdem effizient zu bearbeiten ist. Mit
diesem Hintergrund ist auch die Auswahl und Einsatz entsprechender Hilfsmittel zu
entscheiden.
1.3
AUSGANGSSITUATION
Im Projektverlauf hat sich herausgestellt, dass ein Schwerpunkt zur Realisierung des
Projekterfolgs in der Weitergabe von Informationen, Verfolgung von Terminen und
Verteilung von Aufgaben liegt.
Die besonderen Anforderungen an die Weitergabe von Informationen ergab sich
durch die außergewöhnlichen Projektumständen: Neben der hohen Anzahl an Pro-
jektbeteiligten führt auch der Qualitätsanspruch an einen 4 Sterne Hotelneubau zu
diesen besonderen Anforderungen. Der Schwerpunkt war jedoch die hohe Anzahl an
Projektbeteiligten, welche ohne ausführende Firmen über die Projektdauer gesehen
eine Anzahl von ca. 160 Personen umfasste, welche in eine Projektorganisation und
Informationsfluss eingebunden werden mussten. Diese große Anzahl kam auch
aufgrund des außergewöhnlichen Projektverlaufs zustande. So wurde nach der Vor-
planung das erste Büro für Küchenplanung gekündigt. Nach der Entwurfsplanung
erfolgte die Kündigung des zweiten Büros, diesmal eine Arbeitsgemeinschaft aus
einem deutschen und englischen Planer. Nunmehr erfolgt die Planung durch den
Dritten. Des Weiteren erfolgte die Einschaltung eines Architekten nur für die Aus-
schreibung und Objektüberwachung (Phase 6-8), sowie eines Architekturbüro für die
Planung (Phase 1-5). Auch hier gab es einen Wechsel da dem Büro nach der Ent-
wurfsplanung gekündigt wurde. Auch auf Seiten des Bauherrn fand ein Wechsel nach
der Entwurfsplanung statt, indem die Zuständigkeit des deutschen Bauamts in eine
andere Stadt wechselte. Die einzige Konstante im Rahmen des Projektes war somit
mein Büro und der Investor.
In Summe gibt es 3 Architekten, 2 deutsche und 1 US Bauamt, einen einflussreichen
Nutzer, einen anspruchsvollen Hotelmanager, eine große Anzahl an Planern, Sonder-
fachleuten, die Oberste Baubehörde, die Oberfinanzdirektion, einen Kaminkehrer,
mehrere Übersetzer, die verschiedenen Träger öffentlicher Belange, und und und).
Auch bei einem "normalen" Projekt sammeln sich die meisten Informationen, neben
dem Architekten, auf Seiten der Projektsteuerung. Bei diesem Projekt war es auf-
grund der vielen Wechsel und hohen Anzahl an Personen umso wichtiger, dass zum
einen die Informationen nicht verloren gingen und zum anderen entsprechend wei-
tergegeben werden konnten. Hierfür war die Entwicklung einer Datenbank die logi-
sche Schlussfolgerung.
1.4
BISHER EINGESETZTE MITTEL
Viele Kollegen verfolgen Aufgaben und Termine bis dato handschriftlich oder mit den
Programmen Word und Excel. Dies stellt jedoch aus meiner Sicht eine nicht mehr
zeitgemäße Form des "Dokumentenmanagement" dar, da die Informationen nur
"einmal" zur Verfügung stehen und nur bedingt weiterverarbeitet werden können.
Mittels einer Datenbank lassen sich die Informationen dokumentieren und sind durch
die Beteiligten jederzeit abruf- und filterbar. Über entsprechende Formulare und
Berichte können Erledigungslisten und Protokolle generiert werden. Weiterhin könn-
ten Faxe, Emails bzw. Briefe mit dieser Datenbank erstellt und verwaltet werden.
Obwohl es mittlerweile auch kommerzielle Projektsteuerungsprogramme auf dem
deutschen Markt gibt, welche zumindest teilweise über die von unserem Büro benö-
tigten Funktionen verfügen, muß eine eigene Applikation realisiert werden. Dadurch
ist gewährleistet, dass dieses zum einen über alle benötigte Bestandteile verfügt und

1 Einleitung
Masterarbeit Edgar Schropp
Seite 4
gleichzeitig nicht mit Funktionen überfrachtet ist, welche durch den Anwender nicht
benötigt werden, aber trotzdem vergütet werden müssen.
1.5
MÖGLICHKEITEN DER PROJEKTDATENBANK
Realisiert wurde die Datenbank zunächst mittels des Produkts MS Access 2002. Im
Rahmen der Masterarbeit wird eine "Trennung" zur Realisierung einer Front-End /
Back-End Lösung durchgeführt. Dabei wird MS Access als Front End gewählt und mit
einem SQL Server als Back End verknüpft.
MS Access wird verwendet, da dieses Produkt an den meisten Arbeitsplätzen bereits
installiert ist. Dadurch ist die Dateneingabe und Handhabung in unserem Büro ein-
fach durchzuführen. Bei der Eingabe der Daten in die Datenbank besteht dann, neben
der wie bisher üblichen Ausgabe eines Textdokuments, die Möglichkeit der umfas-
senden und vielseitigen Auswertung und Verfolgung von Eintragungen, wobei die
Eingabeparameter dabei der Schlüssel für umfangreiche Auswertungsmöglichkeiten
sind.
Über entsprechende Formulare und Berichte können Erledigungslisten und Protokolle
generiert werden. Um die Formulare zur Eingabe der Daten an die einzelnen Einga-
bemöglichkeiten und Benutzer anzupassen, ist dabei eine Programmierung von
Funktionen in Visual Basics (VBA) notwendig.
Auf dem SQL Server werden verschiedene Benutzer eingerichtet, sowie Zugriffsrechte
festgelegt, welche durch die Eingabe eines Passworts aktiviert werden.
Die Datenbank kann ferner zur Unterstützung der Abwicklung und Protokollierung
von Besprechungen herangezogen werden. Die Inhalte der Besprechungen werden
dabei im Gegensatz zu einer konventionellen Dokumentation mit einem Textverarbei-
tungsprogramm strukturiert erfasst und mit ergänzenden Informationen versehen.
Neben der Erstellung und Versand der Besprechungsprotokolle als Bericht, bietet die
Datenbank die Möglichkeit, alle einmal erfassten Informationen in beliebiger Weise
auszuwerten, abzurufen und darzustellen.
Als weitere Informationen können auch Daten aus Terminplänen, Planlisten und
Mängellisten in die Datenbank integriert werden.
Ein Schwerpunkt der Datenbank ist die Unterstützung der Kommunikation zwischen
den Projektpartnern. Dies erfolgt mit entsprechenden Berichten, welche an diese
versandt werden. Möglich ist auch der Austausch der strukturierten Inhalte mit den
anderen Projektbeteiligten als Datei, so dass jeder Partner die Möglichkeit des
Zugriffs auf gesammelte Informationen erhält.
Weitere Möglichkeiten der Datenbank sind die Erstellung professioneller Berichte.
Sämtliche Informationen können einfach wieder gefunden und einmal erfasste Inhal-
te weiterverwenden werden. Dabei werden die kompletten Informationspunkte
(Aussagen) samt Quellenangabe angegeben und nicht nur markierte Textstellen, wie
bei anderen Programmen.
Ein weiterer Vorteil ist die Verwaltung der Daten. Diese erfolgt nicht über Datei- und
Ordnernamen. Es gibt nur eine einzige Datenbank, in der die Dokumente und die
darin enthaltenen Informationen gespeichert sind. Dadurch wird Neueinsteigern und
Urlaubsvertretungen das Finden von Unterlagen und Informationen erleichtert. Die
Historie von Geschäftsfällen können einfach recherchiert werden, was vor allem bei
möglichen Rechtsstreitigkeiten hilfreich ist. Dadurch wird ermöglicht, nur durch
entsprechende Auswertungen, Dokumentationen zur Untermauerung eines Rechts-
standpunktes erstellen zu können.

1 Einleitung
Masterarbeit Edgar Schropp
Seite 5
Als mobile Lösung z.B. auf einem Laptop dient die Datenbank zur schnellen Recher-
che auch z.B. in Besprechungen. Behauptungen von Gesprächsteilnehmern können
umgehend geprüft und verifiziert werden.
Die erzeugten Auswertungen können generell in den Formaten PDF, HTML, RTF, XLS
u.a. ausgegeben oder als Datenbank exportiert werden.

2 Entwurf der relationen Datenbank
Masterarbeit Edgar Schropp
Seite 6
2
ENTWURF DER RELATIONEN DATENBANK
Die nachfolgend aufgeführten Erläuterungen der einzelnen Entwurfsphasen entspre-
chen den Studieneinheiten des Moduls "Datenbanken" des ACCE Studiums der FH
Nordostniedersachsen.
2.1
ENTWURFSPHASEN
Es werden folgende Software-Entwurfsphasen für Datenbanksysteme unterschieden:
1
·
Anforderungsanalyse (2.1.1)
·
Konzeptioneller Entwurf (2.1.2)
·
Verteilter Entwurf (2.1.3)
·
Logischer Entwurf (2.1.4)
·
Datenbank-Definition
·
Physischer Entwurf
·
Implementierung und Wartung
Abbildung 1: Phasen beim Entwurf einer Datenbank
2
2.1.1
Anforderungsanalyse
Hier wird der Informationsbedarf der unterschiedlichen Benutzer ermittelt und analy-
siert. Beschreibungen in Form von Texten, Tabellen, Formblättern usw. stellen das
Ergebnis dar und werden im zweiten Schritt in Daten (Datenanalyse) und Funktionen
(Funktionsanalyse) eingeteilt. Während die Datenanalyse für den Entwurf von Daten-
banken dabei von größerer Bedeutung ist, ist es die Funktionsanalyse für die Ent-
wicklung von Anwendungen, welche auf die Datenbank zugreifen.

2 Entwurf der relationen Datenbank
Masterarbeit Edgar Schropp
Seite 7
2.1.2
Konzeptioneller Entwurf (ER-Modell)
6
Mit den Ergebnissen der Anforderungsanalyse erfolgt durch den konzeptionellen
Entwurf eine formale Beschreibung des Problems (vergleiche: Definition des Universe
of Discourse). Die Informationen werden hier in einem semantischen Datenbankmo-
dell dem sog. ER-Modell abgebildet. Unterschieden werden folgende drei Teilschritte:
1. Modellierung spezieller Sichten
Es werden spezielle Sichten für die unterschiedlichen Benutzer modelliert. Aus der
Summe der Informationen der unterschiedlichen Sichten ergibt sich die Gesamtin-
formation, die in der Datenbank gespeichert werden soll.
2. Analyse der modellierten Sichten in Bezug auf die folgenden Aspekte
Namenskonflikte: Hier wird unterschieden, ob verschiedene Begriffe für dasselbe
Konzept der modellierten Anwendung vorkommen (Synonyme) bzw. der gleiche
Begriff für mehrere Konzepte benutzt wird (Homonyme). Diese Mehrdeutigkeit der
natürlichen Sprache wird an dem Begriff Bank deutlich, was ein Kreditinstitut oder
eine Sitzgelegenheit sein kann.
Typkonflikte: Diese treten auf, wenn verschiedene Strukturen für das gleiche
Element modelliert werden (= unterschiedliche Anwendungssichten bedeuten einen
unterschiedlichen Informationsbedarf). Die Lohnstelle eines Unternehmens benötigt
z.B. andere Informationen über einen Mitarbeiter als eine Fachabteilung.
Wertebereichskonflikte: Gleiche Attribute in verschiedenen Sichten können über
unterschiedliche Wertebereiche verfügen. So kann eine Telefonnummer z.B. als
mehrstellige Zahlen oder als Zeichenkette gespeichert werden.
Bedingungskonflikte: Diese entstehen, wenn in verschiedenen Sichten unter-
schiedliche Integritätsbedingungen angegeben werden, z.B. verschiedene Schlüssel
für ein Element. Es sollen vor allem Beziehungen zwischen den verschiedenen Sich-
ten gefunden und Konflikte zwischen den Sichten beseitigt werden.
3. Integration der Sichten in ein Gesamtschema
Um ein konsistentes Gesamtschema zu erhalten, werden die Konflikte in diesem
Schritt aufgelöst. Man erhält als Ergebnis ein Gesamtschema, z.B. in Form eines ER -
Diagramms.
2.1.2.1
Konzeptionelles Schema
Zur Modellierung der Informationen beim Entwurf von Datenbankanwendungen
müssen weitere Aspekte wie Anwendungsfunktionen oder zeitliche Bedingungen
berücksichtigt werden. Hierfür wird das konzeptionelle Schema S in die vier Kompo-
nenten (oder auch Schichten) Objektschicht (O), Datenschicht (D), Entwicklungs-
schicht (E) und Aktionsschicht (A) aufgeteilt.
2.1.2.2
Objektschicht
Diese Schicht beinhaltet die abstrakte Beschreibung der Informationsobjekte und
wird in der Regel als ER - Modell formuliert.
2.1.2.3
Datenschicht
In der Datenschicht werden die Datentypen (Wertebereiche) der Attribute festgelegt.

2 Entwurf der relationen Datenbank
Masterarbeit Edgar Schropp
Seite 8
2.1.3
Verteilter Entwurf
Werden Daten auf mehreren Rechnern gespeichert, ist die Art und Weise der verteil-
ten Speicherung zu definieren. Meist unterscheidet man in eine horizontale und
vertikale Verteilung.
·
Bei einer horizontalen Verteilung werden verschiedene Tupel einer Relation auf
unterschiedlichen Rechnern gespeichert. Horizontal bedeutet dabei einen "waage-
rechten Schnitt" durch eine Datentabelle. Ein Beispiel wäre die Relation Kunde ei-
ner Firma mit mehreren Filialen. Die Daten der lokalen Kunden der einzelnen Filia-
len würden auf einem lokalen Rechner gespeichert werden
·
Eine vertikale Verteilung hingegen ordnet einzelne Attribute von Tupeln auf ver-
schiedenen Rechnern an. Die Aufteilung der Relation Kunde auf zwei Rechner wäre
ein typisches Beispiel. Dabei speichert der eine die Adressen-Daten (wichtig für die
Poststelle) und der zweite die Konto-Daten (wichtig für die Finanzabteilung)
2.1.4
Logischer Entwurf (Relationenmodell)
Mit dem logischen Entwurf wird die abstrakte Beschreibung des ER - Modell in eine
idealisierte Form des Datenbankmodells transformiert, welches von dem ausgewähl-
ten Datenbanksystem unterstützt wird. Es entspricht z.B. dem Relationenmodell,
welches von den Datenbanksystemen MS SQL Server, MySQL und Oracle verarbeitet
wird. Dabei wird auf gewisse systemspezifische Feinheiten des konkreten Datenbank-
systems verzichtet (=idealisiert). Es werden folgende zwei Schritte ausgeführt:
1. Transformation des konzeptionellen Schemas
Das konzeptionelle Schema wird in das Datenbankmodell des gewählten Datenbank-
systems transformiert (z.B. vom ER-Modell ins relationale Modell)
2. Verbesserung des relationalen Schemas
Verbesserung anhand von Gütekriterien wie z.B. Minimierung redundanter Speiche-
rung. Das Ergebnis des logischen Entwurfs ist das logische Schema, bzw. eine struk-
turierte Menge von Relationen
2.2
VOM ER - MODELL ZUM RELATIONENMODELL
Im Rahmen des logischen Datenbankentwurfs erfolgt die Abbildung des konzeptionel-
len Schemas (ER - Modell) in ein Schema des gewählten Datenbanksystems (hier
Relationenmodell). Sämtliche Informationen des ER - Diagramms werden durch
Relationenschemata, Schlüssel und Fremdschlüssel ausgedrückt. Die Abwicklung
erfolgt in folgenden Schritten:
1.
Abbildung Entity- und Beziehungstypen
Die Entity- und Beziehungstypen werden jeweils auf Relationenschemata abgebildet.
Die Attribute des ER Modells werden zu Attributen des Relationenschematas, die
Schlüssel des ER - Modells werden im Relationenmodell übernommen.
Abbildung der Kardinalitäten
Funktionale Beziehungstypen werden, soweit sinnvoll, in die Entity-Typen übernom-
men. Dadurch können ggf. Relationen gestrichen und/oder zusammengefasst wer-
den. Eine weitere Abbildung von Kardinalitäten in das Relationenmodell ist nicht
möglich und ist durch Integritätsbedingungen zu realisieren.
2.
Fremdschlüsselbedingungen
Zwischen den verbleibenden Relationenschemata werden diverse Fremdschlüsselbe-
dingungen eingeführt.

2 Entwurf der relationen Datenbank
Masterarbeit Edgar Schropp
Seite 9
2.2.1
Entity-Typen
Es wird für jeden Entity-Typ ein Relationenschema mit sämtlichen Attributen des
Entity-Typs im Diagramm gebildet. Sollten mehrere Schlüssel vorhanden sein, wird
ein Primärschlüssel gewählt, der möglichst minimal sein sollte. Am besten wird dabei
ein ganzzahliges Attribut als Primärschlüssel gewählt.
2.2.2
Beziehungs-Typen
Jeder Beziehungstyp wird auf eine Beziehungsrelation abgebildet, dessen Relationen-
schema aus allen Attributen des Beziehungstyps im ER - Modell gebildet wird. Zudem
werden alle Primärschlüssel der beteiligten Entity-Typen in das Relationenschema
übernommen.
Man unterscheidet bei den Beziehungsrelationen folgende Schlüssel:
m:n-Beziehung:
Die Primärschlüssel der an der Beziehung beteiligten Entities bilden gemeinsam den
Primärschlüssel der Beziehungsrelation.
n:1-Beziehung:
Der Primärschlüssel der 1-Seite wird Primärschlüssel der Beziehungsrelation. Die
Aufnahme der Beziehungsrelation in die Relation der 1-Seite ist möglich.
1:1-Beziehung:
Beide Primärschlüssel werden je ein Schlüssel in der Beziehungsrelation. Der Primär-
schlüssel wird dann aus diesen Schlüsseln gewählt. Eine Zusammenfassung der drei
beteiligten Relationen zu einer Relation ist möglich.
IST-Beziehung:
Die IST-Beziehung wird nicht auf eine eigene Beziehungsrelation abgebildet. Das
Relationenschema des speziellen Entity-Typs enthält den Primärschlüssel des gene-
rellen Entity-Typs.
Abhängigkeits-Beziehung:
Die Abhängigkeits-Beziehung wird nicht auf eine eigene Beziehungsrelation abgebil-
det. In das Relationenschema des abhängigen Entity-Typs wird außer dem eigenen
Primärschlüssel zusätzlich der Primärschlüssel des übergeordneten Entity-Typs
aufgenommen.
2.3
ZUSAMMENFÜHREN DER INFORMATIONEN DER EINZEL-
NEN TABELLEN
Bei der Projektdatenbank werden Informationen, welche in den verschiedenen Tabel-
len verteilt gespeichert sind, mittels Beziehungsrelationen wieder zusammengeführt.
Die verteilte Speicherung hat den Vorteil, dass sämtliche Daten für ein Formular
nicht in einer u.U. zu großen Tabelle gespeichert werden müssen. In dieser Tabelle
würden stets Daten mitgeführt, welche nicht benötigt oder redundant gespeichert
werden, so dass zu viel Speicherplatz benötigt wird und die Verarbeitung verlang-
samt wird.
Die Erläuterung einer verteilten Speicherung von Daten wird anhand des Beispiels
Formular "Erledigungen" betrachtet (siehe hierzu Kapitel 6).
Nach der Festlegung der Felder der Tabellen, werden die Beziehungen zwischen
diesen Tabellen definiert. Dadurch wird ermöglicht dass Abfragen, Berichte oder

2 Entwurf der relationen Datenbank
Masterarbeit Edgar Schropp
Seite 10
Formulare auf die Informationen aus den verschiedenen Tabellen gleichzeitig zugrei-
fen und diese anzeigen können. Eine Beziehung funktioniert durch übereinstimmende
Daten in Schlüsselfeldern. Meist stellen diese Felder in der einen Tabelle den Primär-
schlüssel und in der anderen Tabelle einen Fremdschlüssel dar.
2.3.1
1:n Beziehung
In diesem häufigsten Beziehungstyp können einem Datensatz in Tabelle A mehrere
passende Datensätze in Tabelle B zugeordnet sein, aber einem Datensatz in Tabelle B
ist nie mehr als ein Datensatz in Tabelle A zugeordnet. In Bezug auf die Datenbank
bedeutet dies, dass z.B. einem Beteiligten mehrere offene Punkte zugeordnet werden
können, ein offener Punkte jedoch nur zu einem Beteiligten.
2.3.2
m:n Beziehung
Jedem Datensatz in der Tabelle 1 können bei einer m:n-Beziehung mehrere überein-
stimmende Datensätze in Tabelle 2 zugeordnet sein. Ebenso trifft dies für die Tabelle
2 zu, der mehrere Datensätze der Tabelle 1 zugeordnet werden können. Diese Bezie-
hung ist möglich, wenn eine dritte Tabelle als Zuordnungstabelle definiert wird. Der
Primärschlüssel dieser Tabelle muss aus zwei Feldern bestehen, welche die Fremd-
schlüssel der Tabellen 1 und 2 sind. Eine m:n-Beziehung besteht daher eigentlich aus
zwei 1:n-Beziehungen mit einer dritten Tabelle. Bei der vorliegenden Datenbank
besteht diese Beziehung z.B. zwischen der Tabelle tblEbene und der Tabelle tblBau-
teil. Die m:n Beziehung wird dabei durch zwei 1:n Beziehungen zur Tabelle tblRaum-
liste geschaffen. Der Primärschlüssel der Tabelle tblRaumliste besteht dabei aus den
Fremdschlüsseln KZEbene der tblEbene und BTKZ der tblBauteil. Eine Ebene kann
dabei viele Bauteile umfassen und jedes Bauteil kann aus mehreren Ebenen beste-
hen.
Abbildung 2: m:n Beziehung der Tabellen tblEbene, tblRaumliste und tblBauteil
2.3.3
1:1 Beziehung
Bei dieser Beziehung ist jedem Datensatz in Tabelle 1 nur ein übereinstimmender
Datensatz in Tabelle 2 zugeordnet und umgekehrt. Da der Großteil dieser so in
Beziehung stehenden Informationen sich in einer Tabelle befindet, kommt diese
Beziehung nicht oft vor. Sie wird eingesetzt um eine Tabelle mit vielen Feldern zu
teilen, einen Teil der Tabelle aus Sicherheitsgründen abzutrennen oder um Informati-
onen zu speichern, die nur für eine Untermenge der Haupttabelle gelten.
2.3.4
Definieren von Beziehungen im MS Access
Welche Art von Beziehung bei einer Datenbank wie MS Access erstellt wird, hängt
davon ab, wie die in Beziehung stehenden Felder definiert sind:

2 Entwurf der relationen Datenbank
Masterarbeit Edgar Schropp
Seite 11
1:n-Beziehung: liegt vor wenn nur eines der in Beziehung stehenden Felder ein
Primärschlüssel ist oder einen eindeutigen Index besitzt.
1:1-Beziehung: wenn beide in Beziehung stehenden Felder Primärschlüssel sind
oder über eindeutige Indizes verfügen.
m:n-Beziehung: besteht eigentlich aus zwei 1:n-Beziehungen mit einer dritten
Tabelle. Der Primärschlüssel dieser Tabelle besteht aus zwei Feldern, welche jeweils
die Fremdschlüssel aus den beiden anderen Tabellen sind.
Unbestimmte Beziehung: Wird ein Feld ohne Primärschlüssel oder eindeutigen
Index, mit einem Feld einer Tabelle in Beziehung gesetzt, welches ebenfalls keinen
Primärschlüssel und eindeutigen Index besitzt, stellt dies eine unbestimmte Bezie-
hung dar. Bei solch einer Verknüpfung wird zwar eine Verknüpfungslinie erzeugt,
eine referentielle Integrität ist aber nicht gegeben. Die Eindeutigkeit der Datensätze
ist nicht garantiert.
referenzielle Integrität (RI): Durch dieses Regelsystem wird sichergestellt, dass
Beziehungen zwischen Datensätzen in Detailtabellen gültig sind und verknüpfte
Daten nicht versehentlich gelöscht oder geändert werden. Dabei müssen folgende
Bedingungen gleichzeitig erfüllt sein:
1. Das übereinstimmende Feld aus der Mastertabelle ist ein Primärschlüssel bzw. hat
einen eindeutigen Index
2. Die verwandten Felder haben denselben Datentyp, wobei es zwei Ausnahmen gibt:
Der Typ Autowert kann mit dem Typ Zahl und Feldgröße-Eigenschaft Long Integer
verknüpft werden. Ferner ist es möglich, den Typ Autowert mit einem Feld vom Typ
Zahl zu verknüpfen, wenn beide die Feldgröße-Eigenschaft Replikations-ID besitzen.
3. Beide Tabellen gehören zu derselben MS Access-Datenbank. RI kann nicht für
verknüpfte Tabellen aus Datenbanken anderer Formate durchgesetzt werden.
Bei der referenziellen Integrität gelten folgende Regeln:
·
in das Fremdfeld der verwandten Tabelle kann kein Wert eingeben werden,
der nicht im Primärschlüssel der Mastertabelle enthalten ist.
·
in das Fremdschlüsselfeld kann ein NULL Wert eingeben werden, um an-
zugeben, dass die Datensätze nicht miteinander verknüpft sind.
·
Datensätze der Mastertabelle können nicht gelöscht werden, wenn überein-
stimmende Datensätze in einer Detailtabelle enthalten sind.
·
Der Primärschlüsselwert in der Mastertabelle kann nicht geändert werden,
wenn es zu diesem Datensatz Detaildatensätze gibt.
Bei der Aktivierung der Lösch- und Aktualisierungsoperationen ist es trotz den Regeln
der referenziellen Integrität möglich, dass der in der Mastertabelle gelöschte Daten-
satz oder geänderte Primärschlüsselwert in den verknüpften Tabellen nachgeführt
wird, um die referenzielle Integrität zu wahren.
2.4
UMSETZUNG RELATIONENMODELL IN SQL-DDL (DATEN-
BANK DEFINITION)
Bei diesem Schritt wird das logische Schema in ein konkretes Schema mittels der
Datendefinitions- und Datenmanipulationssprache des gewählten Datenbanksystems
umgesetzt.
Die Datendefinitionssprache SQL-DDL (Data Definiton Language) ist ein Teil der
Standardsprache SQL (Structured Query Language) für relationale Datenbanksyste-

2 Entwurf der relationen Datenbank
Masterarbeit Edgar Schropp
Seite 12
me. SQL-DDL wird der logische Entwurf eines Relationenmodells in ein konkretes
Datenbanksystem (z.B. Oracle) umgesetzt.
2.5
PHYSISCHER ENTWURF
Der physische Entwurf definiert mit einer Speicherstruktursprache (SSL) die interne
Speicherstruktur der Datenbank. Es wird z.B. angegeben, ob eine Relation in einer
Baumstruktur oder mittels einer Hash-Tabelle abgelegt wird. Das Ergebnis des physi-
schen Entwurfs ist das physische Schema.
2.6
IMPLEMENTIERUNG UND WARTUNG
Die resultierende Datenbank ist in den meisten Fällen kein unveränderliches System.
Im tatsächlichen Betrieb erfolgen Phasen der Wartung, der weiteren Optimierung, der
Anpassung an neue Anforderungen und Systemplattformen oder die Portierung auf
neue Datenbanksysteme. In der Regel übersteigen die anfallenden Kosten für War-
tung und Anpassung die ursprünglichen Entwurfskosten. Daher muss schon in der
Entwurfsphase die leichte Modifikation der Anwendung berücksichtigt werden, etwa
durch eine saubere Dokumentation aller Entwurfsentscheidungen, Modularisierungs-
techniken etc.. Auf die hierfür sinnvollen Techniken des Software Engineerings wird
an dieser Stelle ebenfalls nicht näher eingegangen.
2.7
ÜBERBLICK ÜBER DIE BEZIEHUNGEN DER DATENBANK
Die Beziehungen der SQL Server Datenbank können der Anlage in Kapitel 9.4 ent-
nommen bzw. im Ordner "Diagramme" des Enterprise Managers angezeigt werden.

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 13
3
KONZEPTION, UMSETZUNG UND IMPLEMENTIERUNG
3.1
INSTALLATION DER DATENBANKANWENDUNGEN
3.1.1
Technische Voraussetzungen
Für eine Installation der Datenbankanwendung muss eine Serverversion eines Be-
triebssystems implementiert sein, da dies für den Einsatz des SQL Server erforderlich
ist. Da in dem Office Paketen eine "kostenlose" Server Datenbank enthalten ist, muss
der SQL Server 2000 nicht installiert werden. Die sog. MSDE (Microsoft Data Engine)
ist Bestandteil des Office Paketes und dient als SQL Server. Als Betriebssystem
wurde Windows 2000 benutzt.
Um trotzdem die Administratorenoberfläche für den SQL Server zu erhalten, wurde
nach der Installation von MSDE noch der Enterprise Manager aus dem Paket Microsoft
SQL Server Enterprise Edition installiert. Als Front End Produkt fungiert die Daten-
bank MS Access 2002, als Email Client MS Outlook 2002. Die Verbindung zum Inter-
net wird mittels IES hergestellt.
Access 2002 muss als Bestandteil des MS-Office-Professional-Pakets komplett instal-
liert werden. Insbesondere der ODBC-Treiber (Open Database Connectivity) welcher
ebenfalls Bestandteil der CD ist, darf dabei nicht vergessen werden.
3.1.2
Programmadministration
Jeder Anwender muss zuvor vom Besitzer (dbo) der Datenbank auf dem SQL Server
als Benutzer angelegt und mit den entsprechenden Rechten versehen werden (siehe
hierzu Kapitel 5.2.6). Erst dann kann sich ein User unter seinem Benutzernamen
anmelden und die Projektdatenbank arbeiten.
3.1.3
Installation der Datenbank-Anwendungen auf Server und
Client
Nach dem Upsizing der Access Anwendung, erhält man eine MDF (Masterdatendatei)
und LDF (Transaktionsprotokoll) Datei, welche standardmäßig in das Verzeichnis
C:\Programme\Microsoft SQL Server\MSSQL\Data auf dem SQL Server gespeichert
wurden. Während des Upsizing Vorgangs wurde zuvor der gewünschte SQL Server
ausgewählt, mit dem die Front End DB verknüpft werden soll. Die Front End Anwen-
dung befindet sich zunächst nur auf dem Client der das Upsizing durchgeführt hat.
Die Front End Access MDB Datei kann nun in einem beliebigen Verzeichnis auf ande-
ren Clients gespeichert werden, die mit den SQL Server z.B. über das Firmennetz-
werk verknüpft werden können.
Soll nun die Back End Datenbank auf einen anderen SQL Server verschoben werden,
wird die MDF und LDF Datei in ein Verzeichnis auf dem neuen SQL Server zu kopie-
ren. Dabei wird bei der SQL-Server 2000 Version wie folgt vorgegangen:
Die Datenbank wird über das Kontextmenü der Datenbank mit dem Befehl Alle Tasks
/ Offline Schalten abgehängt. Auf dem neuen Server wird diese Datenbank über das
Kontextmenü von Datenbanken mit dem Befehl Alle Tasks / Datenbank anhängen,
angefügt.

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 14
Das Anfügen der MDF Dateien wird dabei wie folgt durchgeführt:
Abbildung 3: Anfügen einer Datenbank auf den SQL Server
Alternativ kann auch ein Backup der Datenbank auf dem ersten Server durchgeführt
werden. Die dadurch entstandene BAK.Datei wird kopiert und bei dem neuen Server
über "Datenbank wiederherstellen" eingefügt.
Sämtliche Festlegungen zu Benutzer, Rollen usw. werden durch die Kopie mit über-
tragen.
3.1.4
Herstellen der Verknüpfung Front und Back End Datenbank
Die Front End Access MDB Datei kann in einem beliebigen Verzeichnis auf den Clients
des neuen Servers gespeichert werden.
Die SQL Datenbank stellt eine ODBC-Datenquelle (Open Database Connectivity, eine
Standardmethode zum Freigeben von Daten zwischen Datenbanken und Program-
men) dar. Um die Tabellen der Front End Datenbank mit den Daten des SQL Server
zu verknüpfen, greift diese auf einen ODBC Treiber zu, der wiederum mit der SQL
Datenbank auf dem Server verknüpft ist. Der ODBC-Treiber verwendet zum Zugriff
auf die externen Daten die Standardsprache SQL (Structured Query Language).
Als letzter Schritt werden in der Front End Datenbank nun die Tabellen mit der
entsprechenden Quelle (den MDF Dateien auf dem SQL Server) verknüpft. Hierzu
wird nun der ODBC String, mit welchem die Tabellenverknüpfungen eingerichtet sind,
entsprechend aktualisiert, so dass die Front End Datenbank weiß, auf welchem
Server die Tabellen zu finden sind. Würde die Front End Datenbank allerdings mit
verknüpften Tabellen verteilt, würde es bei dem ersten Öffnen eine massive Behinde-
rung aufgrund von Timeouts geben, da die Verknüpfungen ins "Leere" gehen. Daher
werden sämtliche verknüpften Tabellen gelöscht und die Verknüpfung muss daher
mit folgenden Schritten neu erstellt werden.

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 15
Hierzu wird in der Front End Datenbank wie folgt vorgegangen:
1.
Anlegen des Benutzers auf dem SQL Server, der die Tabellen verknüpfen wird.
Öffnen der betreffenden Datenbank und anlegen des Benutzers (siehe hierzu Ka-
pitel 5.2.6.1)
2.
In der Front End Datenbank wird folgendes gewählt: Datei / Externe Daten /
Tabellen verknüpfen, es muss die Auswahl von ODBC Databases als Dateityp er-
folgen. Daraufhin erscheint das Fenster wie unter (A) zur Auswahl der Datenquel-
le
3.
Es erfolgt die Auswahl "Neue DSN" und Eingabe eines entsprechenden Dateina-
mens Ihrer Wahl
4.
Hier ist "SQL Server" auszuwählen. Daraufhin erscheint ein Fenster in dem die
Datenquelle gesucht oder neu angelegt werden kann. Es wird eine neue Quelle
z.B. mit dem Namen AHG-PDB12MTV.dsn angelegt.
5.
Als nächster Schritt wird der Server ausgewählt (hier IBBDBS2) mit dem die
Verbindung hergestellt werden soll (B).
6.
Schritt (C) beschreibt die Wahl der Authentifizierung, wie diese auf dem SQL
Server durchgeführt werden soll und ist abhängig von den Festlegungen, welche
zu diesen Benutzern auf dem SQL Server getroffen wurden (z.B. erster Benutzer:
SQL Authentifizierung, zweiter Benutzer: über Windows Kennwort).
7.
Nach erfolgreicher Verknüpfung erfolgt das Testen der Datenquelle (D)
8.
In dem neuen Pop Up Menü "SQL Server Anmeldung" erfolgt die Auswahl des
entsprechenden SQL Server, die Festlegung von Benutzername und Kennwort,
usw. Hierzu muss über den Button "Optionen" vorab das Menü erweitert werden.
Des Weiteren erfolgt die Auswahl der zu verknüpfenden Datenbank auf dem SQL
Server, welche die sog. Standarddatenbank darstellt. Diese muss identisch sein
mit der Datenbank, welche dem Benutzer auf dem SQL Server als Standarddaten-
bank zugeordnet wurde. Nach Klicken des OK Button, wird die neue ODBC Daten-
quelle mit den Tabellen der Front End Datenbank verknüpft (E).
9.
Als letzter Schritt erfolgt die Auswahl der zu verknüpfenden Tabellen, welche bei
der Projektdatenbank stets mit den Buchstaben "tbl" beginnen (F). Nach "OK"
werden diese mit der Back End Datenbank auf dem SQL Server verknüpft.
10.
Leider erhalten die verknüpften Tabellen einen Präfix der den Tabellennamen
verändert. Dadurch würden die Formulare, Abfragen und Berichte die zugrunde
liegenden Tabellen nicht mehr finden. Sämtliche Tabellen müssen daher einzeln
umbenannt werden, so dass diese jeweils mit "tbl" beginnen.

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 16
(A) DSN auswählen
(B) SQL Server auswählen
(C) SQL Authentifizierung
(D) Datenquelle testen

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 17
(E) Anmeldevorgang SQL Server
(F) Verknüpfen der Tabellen
Abbildung 4: Erstellung DSN Verbindung und ODBC Verknüpfung
3.1.5
Programmstart
Nach dem Verknüpfen der Tabellen, erscheint erneut das Eingabefeld für das Pass-
wort zur Anmeldung analog Schritt (E). Nach der erneuten Authentifizierung ist die
Datenbank zu benutzen und es können, je nach Berechtigung auf dem SQL Server,
Daten bearbeitet werden.
3.1.6
Verweise in Access
Um sämtliche Funktionen der Datenbank zu nutzen (wie z.B. den Import von Termi-
nen nach Outlook) ist es erforderlich in Access die entsprechenden Verweise auf
Objektbibliotheken einzurichten. Um diese einzurichten, öffnet man ein Modul und
aktiviert in dem Menü (Extras / Verweise) die erforderlichen Bibliotheken. Welche
dies sind, ist aus der folgenden Abbildung ersichtlich, wobei die Reihenfolge (z.B.
DAO vor ADO) einzuhalten ist.
Abbildung 5: erforderliche Verweise in Access

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 18
3.2
FUNKTIONEN DER DATENBANK
Vor der Realisierung der Datenbank wurde untersucht, welche Funktionen in diese
sinnvoll integriert werden könnten. Aufgrund der Komplexität der integrierten The-
men und da bereits eine entsprechende professionelle Eigenentwicklung meines
Büros existiert, erfolgte ein Verzicht auf die Integration des Themas Kostenplanung
und -verfolgung. Lediglich im Rahmen der Verfolgung von Nachtragsanmeldungen,
Mehrkosten und des Änderungsmanagements werden diese behandelt.
Die Datenbank verfügt jedoch über alle im Projektmanagement relevanten Bereiche:
Organisation, Termine, Kosten und Qualitäten. Nachfolgend die Kurzbeschreibung der
enthaltenen Funktionen:
3.2.1
Benutzersichten und Zugriffsrechte
Aufgrund der Verwendung in einer Mehrbenutzerumgebung werden verschiedene
Benutzersichten kreiert, sowie Zugriffsrechte festgelegt, welche durch die Windows
Anmeldung aktiviert werden (siehe hierzu Kapitel 5.2.6).
3.2.2
Startmaske
Nach einem Doppelklick auf die Datei startet die Datenbank und es erscheint das
Formular mit der Startmaske. Mit dieser Maske sind sämtliche Funktionen bzw.
Formulare über die Buttons auf der rechten Seite oder den Verzeichnisbaum der
linken Seite aufzurufen. Die Navigation zwischen den Formularen erfolgt generell
durch Buttons. Wird die Datenbank für die erste Benutzung eingerichtet, erfolgt
zunächst die Eingabe der Projektdaten in das Formular "Voreinstellungen bearbeiten".
Abbildung 6: Formular Startmaske

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 19
3.2.3
Voreinstellungen
Abbildung 7: Formular Voreinstellungen
3.2.3.1
Kategorie der Beteiligten
Hier werden die Kategorien der Beteiligten festgelegt, um eine übergeordnete Zuord-
nung wie z.B. Bauherr, Planer oder Firma vorzunehmen.
3.2.3.2
Art der Beteiligten
In diesem Formular werden die Daten einmalig eingegeben, um die Art des Beteilig-
ten (Projektsteurer, Prüfstatiker, Planer Haustechnik, ...) festzulegen.
3.2.3.3
Projektbeteiligte
Die Beteiligten Planer und sonstigen Beteiligten werden zunächst mit deren Kürzel
und weiteren allgemeinen Daten in dem Formular "Projektbeteiligte Kurzzeichen"
erfasst. Über dieses Kurzzeichen können dann in den Formular "Projektbeteiligte
Mitarbeiter" die jeweiligen Bearbeiter einem Kurzzeichen und somit einem Büro,
Kategorie, Art des Beteiligten und Anschrift zugeordnet werden. Dabei gibt es mit der
Zuordnung zu einer Kategorie und Art des Beteiligten zwei wichtige Kriterien, welche
über ein Drop Down Feld ausgewählt werden können. Es ist daher zweckmäßig vor
Eingabe der Projektbeteiligten die Daten in die Formulare "Art der Beteiligten" und
"Kategorie Beteiligte" einzugeben.

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 20
Abbildung 8: Formular Projektbeteiligte Kurzzeichen
In dem Formular "Projektbeteiligte Mitarbeiter" werden die Projektbeteiligten mit den
verschiedenen Informationen wie Name, Telefonnummer, Position, ... erfasst und
einem Kurzzeichen der Projektbeteiligten zugeordnet. Anzumerken ist noch, dass bei
einer entsprechenden Bearbeitung der Ansicht in dem Programm Outlook ein Import
der entsprechenden Daten aus diesem Programm in dieses Formular möglich ist.
Nach Erfassung der Daten können diese durch zwei verschiedene Berichte ausge-
druckt werden.
Abbildung 9: Formular Projektbeteiligte Mitarbeiter
3.2.3.4
Firmen
Nach Eingabe der Projektbeteiligten, können in diesem Formular speziell Firmen
erfasst und diese Vergabeeinheiten zugeordnet werden. Des Weiteren ist es möglich
etwaige Nachlässe der Auftragssumme einzugeben. Diese Angaben sind wichtig für
die weitere Bearbeitung der Verfolgung von Mehrkosten, Nachträgen und Ände-
rungsmeldungen.

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 21
Abbildung 10: Formular Firmen
3.2.3.5
Besprechungsarten
In dem Formular "Besprechungsarten" werden die verschiedenen Besprechungen
definiert, welche gemäß dem Organisationshandbuch in einem regelmäßigen Turnus
(= Jour Fixe) erfolgen. Hierzu gehören der Bauherrn Jour Fixe (BHJF) an dem neben
dem Bauherrn auch die Planer und der Projektsteurer teilnehmen und wichtige
Entscheidungen durch den Bauherrn gefällt werden, sowie wichtige Erledigungen für
die Planungsbeteiligten festgelegt werden. Neben dem Bauherrn Jour Fixe gibt es
auch noch den Lenkungskreisausschuss (LKJF) an dem z.B. der Vorstand des Bau-
herrn und der Projektsteuer teilnimmt und wichtige Meilensteine des weiteren Pro-
jektablauf besprochen werden. Weitere Besprechungen sind Planungs- und Baustel-
len Jour Fixe (PJF und BJF), oder unregelmäßige Besprechungen, welche unter den
Oberbegriff Sonstige fallen. In jeder der vorgenannten Besprechungen werden wich-
tige Entscheidungen gefällt, Aufgaben verteilt und Festlegungen getroffen, welche in
einem ansprechenden Berichtswesen dokumentiert werden müssen. Als weitere
Berichtsarten können definiert werden Aktenvermerke, Begehungsprotokolle, Aufga-
benlisten, Listen offener Punkte (LOP Liste).
Der Bauherrn JF und der Lenkungskreisausschuss werden durch den Projektsteuerer
geleitet und dokumentiert. Dadurch ist er sowohl für die Erfassung der Punkte, als
auch für die Erstellung des Berichtes zuständig. Aus den anderen Besprechungen gilt
es für ihn die Aufgaben, deren Erledigung verfolgt werden muss, herauszufiltern und
mittels der Datenbank weiter zu verfolgen. Die Erfassung erfolgt somit nicht im
Rahmen der Berichtserstellung, sondern als Erfassung der offenen Punkte zur Erledi-
gung.
Abbildung 11: Formular Besprechungsarten

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 22
3.2.3.6
Berichtswesen
Das Berichtswesen ist ein wichtiger Bestandteil des Projektmanagements. Die Aufga-
be des Berichtswesens ist es, die Ergebnisse der Projektarbeit zu dokumentieren und
den Beteiligten zugänglich zu machen. Dabei liefert die Dokumentation die Datenba-
sis für das Projekt-Controlling und die Projektsteuerung.
Obwohl das Berichtswesen essentiell für das Projektmanagement ist, wird es für
denjenigen, der die Berichte und Protokolle schreiben muss, als notwendiges Übel
angesehen, da es mit einem erheblichen Zeitaufwand verbunden ist und nicht abge-
schlossene Arbeiten und ungelöste Probleme dokumentiert werden.
Die Datenbank soll dazu dienen den Zeitaufwand insbesondere für die Erstellung von
Protokollen zu minimieren und eine leichte Auswertbarkeit zu gewährleisten. Dies
wird erreicht, indem stark restriktive Formulare eingesetzt werden (siehe hierzu
Kapitel 0). Die inhaltliche Qualität der Berichterstattung hängt dabei von jedem
einzelnen ab. Der Projektsteurer sollte jedoch die Probleme und ihre Lösungen in
einem ansprechenden Berichtswesen dokumentieren und über ein "Wissensmanage-
mentsystem" der Allgemeinheit zur Verfügung stellen. Formell ist dabei zwischen
Berichten und Protokollen zu unterscheiden.
·
Berichte sind verdichtete Informationen über einen bestimmten Zeitraum und
einen bestimmten Bereich des Projekts (z.B. vierteljährlicher Projektstatusbericht,
Projektabschlussbericht)
·
Protokolle sind die Dokumentation von Ergebnissen eines Ereignisses oder Vor-
gangs zu einem bestimmten Zeitpunkt (z.B. Protokoll des Bauherrn Jour Fixe)
Neben dem eigentlichen Inhalt sind bei einem Bericht auch folgende formalen
Eigenschaften zu erfüllen:
·
Verantwortlicher Berichterstatter (nicht gleichbedeutend mit den Autoren)
·
Adressat und Verteiler
·
Gegenstand der Berichterstattung
·
Berichtszeitraum
·
Häufigkeit der Berichtserstattung
·
Abgabetermin in Relation zur Häufigkeit (z.B. "jeweils 10 Arbeitstage nach Quar-
talsende")
·
Typ des Berichts (z.B. Dokumentation, Ergebnisbericht, Statusbericht)
·
Formelle Anforderungen (z.B. vorgeschriebene Vorlagen)
Ähnliches gilt für Protokolle, wobei die Zeitangaben hier auf das Ereignis abge-
stimmt sind:
·
Protokollführer
·
ggf. genehmigende Person
·
Adressat / Verteiler
·
Art des Ereignisses / Vorgangs
·
Typ des Protokolls (z.B. Besprechungsprotokoll, Testprotokoll)
·
Abgabetermin in Relation zum Ereignis (z.B. "ein Arbeitstag nach der Bespre-
chung")
·
Formelle Voraussetzungen

3 Konzeption, Umsetzung und Implementierung
Masterarbeit Edgar Schropp
Seite 23
Wie für alle Projektdokumente gelten auch für Protokolle und Berichte besonders
hohe Anforderungen für Ablage und Aufbewahrung. Zu jedem Zeitpunkt muss ge-
währleistet sein, dass sämtliche Berichte und Protokolle bei Bedarf den Berechtigten
sofort zur Verfügung stehen. Andererseits unterliegen diese oftmals besonderen
Geheimhaltungsvorschriften und müssen vor unberechtigten Zugriffen geschützt
werden. Mittels einer Datenbank kann sowohl der jederzeitige Zugriff, als auch
umfassende Suchmethoden garantiert werden. Durch die Vergabe von Benutzersich-
ten und Zugriffsrechten kann die Benutzung eingeschränkt werden (siehe hierzu
Kapitel 3.2.1). Da Berichte oft höheren Anforderungen an das Layout unterliegen und
z.T. Grafiken enthalten, liegt der Anwendungsschwerpunkt der Datenbank sicherlich
auf Protokollen.
3.2.3.7
Gliederungspunkte Besprechung
Für die Strukturierung der Endlosprotokolle ist es erforderlich Gliederungspunkte zu
definieren. Da die übergeordneten Gliederungspunkte z.B. bei dem BHJF (bis zur
zweiten Ebene) und LKJF sich im Projektverlauf nicht ändern, können diese einmalig
in diesem Formular definiert werden und dienen in dem Formular "Eingabe Erledi-
gungen" über ein Drop Down Menü zur schnellen Zuordnung eines Besprechungsin-
haltes zu einem Gliederungspunkt. Die Eingabe erfolgt für sämtliche Protokolle
fortlaufend in diesem Formular. Gliederungspunkte, welche sich ändern können bzw.
nur einmalig festgelegt werden, werden in dem Formular "Eingabe Erledigungen"
manuell als "Gliederungspunkt variabel" eingegeben. Da es sich bei dem Gliede-
rungspunkt um ein Textfeld handelt, ist es für die Sortierung wichtig, dass die Glie-
derungsnummer zweistellig eingegeben wird (z.B. 3.03).
Abbildung 12: Formular Eingabe Gliederungspunkte

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2004
ISBN (eBook)
9783832486662
ISBN (Paperback)
9783838686660
DOI
10.3239/9783832486662
Dateigröße
4.6 MB
Sprache
Deutsch
Institution / Hochschule
Leuphana Universität Lüneburg – Bauingenieurwesen
Erscheinungsdatum
2005 (März)
Note
2,0
Schlagworte
projektdatenbank microsoft server datenbanktrigger mehrbenutzerumgebung replikation rollen zugriffsbeschränkungen
Zurück

Titel: Entwicklung einer Datenbank zur Informationsverarbeitung und -verteilung im Projektmanagement
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
book preview page numper 19
book preview page numper 20
book preview page numper 21
book preview page numper 22
book preview page numper 23
book preview page numper 24
book preview page numper 25
book preview page numper 26
book preview page numper 27
book preview page numper 28
book preview page numper 29
137 Seiten
Cookie-Einstellungen