Erstellen und Umstellen von relationalen Datenbanken

Erstellen und Umstellen
von relationalen Datenbanken
auf MS Access
- Möglichkeiten und Grundsätze -
Studienarbeit im Rahmen des
ersten Praktischen Studiensemesters
im Fachbereich Wirtschaftsinformatik
an der Fachhochschule Furtwangen
vorgelegt von
Markus Frommherz
Beim Widmen 22
D-79736 Rickenbach
Referent: Prof. Schreier
eingereicht am 31.08.95
1 Zusammenfassung
Ziel der Studienarbeit war die Untersuchung der Grundsätze beim Erstellen und Umstellen
relationaler Datenbanken und der Möglichkeiten, die MS Access hierfür bietet. Aufgrund seiner
Bedienungsfreundlichkeit eignet sich diese datenbankorientierte Entwicklungsumgebung vornehmlich
zur Erstellung und Umstellung von Datenbanken im Privatbereich oder für Einzelplatz- und kleine
Systemlösungen. Wegen der unzureichenden Unterstützung von Datenbankmanagementfunktionen
sowie der schlechten Performance eignet sie sich nicht für für den professionellen Einsatz in grösseren
Systemen. 1 Die Besonderheit bei der Entwicklung relationalen Datenbanken gegenüber der
Entwicklung anderer Software besteht darin, dass sich durch Normalisierung eine optimale
Datenstruktur erreichen lässt, die für weitere Design- und Implementierungphasen wertvoll ist.
Ansonsten gleicht das Vorgehen bei der allgemeinen Softwareentwicklung dem der
Datenbankentwicklung. Beim Umstellen relationaler Datenbanken unterscheidet man zwischen
revolutionärem und evolutionärem Verfahren, wobei bezüglich der Umstellung auf MS Access auch
andere Verfahren sinnvoll sind.
1
Dies entspricht einer Aussage von Bill Gates, Geschäftsführer von Microsoft: „If you can not make it good, make
it look good“.
2 Inhaltsverzeichnis
1 ZUSAMMENFASSUNG......................................................................................................2
2 INHALTSVERZEICHNIS ....................................................................................................3
3 EINFÜHRUNG......................................................................................................................4
4 IST-ANALYSE VON MS ACCESS....................................................................................5
4.1 Möglichkeiten und Grenzen ........................................................................................................................................ 5
4.2 Vergleich......................................................................................................................................................................... 7
4.3 Technische Beschreibung..........................................................................................................................................11
5 ERSTELLEN RELATIONALER DATENBANKEN .....................................................13
5.1 Grundsätze bei Softwareprojekten ...........................................................................................................................13
5.2 Entwicklungsvorgehensmodell..................................................................................................................................13
5.3 Erstellen von Datenbanken.........................................................................................................................................17
5.4 Vorgehen beim Erstellen mit MS Access................................................................................................................21
6 UMSTELLEN VON DATENBANKEN............................................................................25
6.1 Gefahren und Besonderheiten...................................................................................................................................25
6.2 Entwicklungsvorgehensmodell - Varianten............................................................................................................26
6.3 Vorgehen bei MS Access............................................................................................................................................26
7 FALLBEISPIEL ..................................................................................................................28
8 LITERATURVERZEICHNIS.............................................................................................33
3 Einführung
Diese Studienarbeit beschreibt das formal richtige Vorgehen beim Erstellen und Umstellen von
Software - insbesondere relationaler Datenbanken - im allgemeinen und Besonderheiten beim Erstellen
und Umstellen relationaler Datenbanken mit der datenbankorientierten Entwicklungsumgebung MS
Access im speziellen. Hierbei wird durch eine IST-Analyse von MS Access verstärkt auf dessen
Möglichkeiten und Grenzen eingegangen. Weiterhin werden Grundsätze bei Softwareprojekten und
beim Datenbankdesign genannt. Zuletzt wird durch ein Fallbeispiel das der eigenen Entwicklung einer
Datenbank zugrundeliegt die Umsetzung der zuvor beschriebenen Methoden dargestellt.
4 IST-Analyse von MS Access
4.1 Möglichkeiten und Grenzen
MS Access ist eine zum Frontend-Einsatz geeignete datenbankorientierte
Entwicklungsumgebung für Einzelplatz- und kleine Systemlösungen. Sie wurde für das auf IBMkompatible Mikrorechner ausgelegte Betriebssystem MS Windows entwickelt. MS Access von der
Microsoft Corp. liegt in der aktuellen Version 2.0 vor und ist in das Office-Packet MS Office
(Professional Version), das in der aktuellen Version 4.3 vorliegt, integriert.1 Eine umfangreich
überarbeitete Version MS-Access 7.0 wurde von Microsoft für das Office-Packet für Windows 95
angekündigt. Alle MS Office-Produkte sollen dann die einheitliche Versionsnummer 7.0 bekommen
(Excel, Powerpoint,...).2 Im folgenden wird die aktuelle Version MS Access 2.0 betrachtet. Vom
Produkt MS Office gibt es eine Reihe von Varianten und Updates. Die Hauptversionen sind die
Standardversion mit Winword, Excel, Powerpoint, Money und Visio Express und die die
Professionalversion mit MS Access als Zusatz. Vergleichbare Datenbanksysteme sind z.B. Approach
3.0 für Lotus SmartSuite und Paradox 5.0 für Perfect Office Professional.
MS Access als Frontend-Tool
Durch die Unterstützung vieler Datenbankformate und die guten grafischen
Auswertungsmöglichkeiten sowie die Integration in ein Office-Packet eignet sich Access gut als
Frontend-Tool in einer heterogenen Datenbankumgebung. Es unterstützt Import, Export und Einbindung
von dBase (III und IV), Paradox (3.x und 4.x), FoxPro (2.0 und 2.5), SQL (benötigt jeweiligen ODBCTreiber), Import und Export von Btrieve (benötigt DLL WBTRCALL.DLL von Novell) und eine Reihe
weiterer Formate. Durch das im Lieferumfang des MS Office enthaltene MS Graph und
Exportmöglichkeiten nach MS Excel lassen sich die Daten vielfältig darstellen und gut auswerten.
Das Mehrbenutzersystem
Aufgrund der schlechten Mehrbenutzerverwaltung und der bei zunehmender Benutzerzahl stark
steigenden Performanceprobleme eignet sich eine MS Access Datenbank für eine Umgebung mit
maximal ca. 20 Arbeitsplatzrechnern (10 MB RAM empfehlenswert) und eine minimale Anzahl von
Datensätzen (ca. <50.000).3 Zudem sind schon bei Systemen mit weniger Arbeitsplatzrechnern
umfangreichere Ergänzungen des integrierten Mehrbenutzersystems notwendig, um die notwendigen
Datenbankmanagementfunktionen zu erhalten. Einige Datenbankmanagementfunktionen wie ein
aktives Data Dictionary und Zugriffsrechte auf Felder statt nur auf Objekte lassen sich allerdings als
Zusatzentwicklung schwer oder gar nicht realisieren. Den modernen Anforderungen an die
Datensicherheit - Kennwörter sollten geheim gehalten, periodisch geändert und nicht schriftlich
festgehalten werden. Sie sollten bei der Eingabe nicht auf dem Bildschirm erscheinen und vom
Benutzer selbst ausgewählt werden, damit dieser sie nicht vergißt. (Gillenson, 457) - genügt MS
Access nur ungenügend. So unterstützt es im Gegensatz zu anderen Systemen keine zwangsweise
periodische Änderung des Kennworts und keine Recoverymöglichkeit für die Benutzerkonten beim
Verlust der SYSTEM.MDA. Dies und der Umstand, dass sogar die wenigen integrierten
Mehrbenutzer-verwaltungsfunktionen nicht einmal zuverlässig funktionieren, machen MS Access für
den professionellen Einsatz im grösseren Rahmen unbrauchbar. So lassen sich zum Beispiel die von
1
Die Standardversion ist 4.2 - es gibt auch Packete, wo Access der Standardversion hinzugefügt wurde.
Gemäss Babo, Michael von. „32-Bit-Verlockungen“. Windows Guide Schweiz Special 2b: 31.
3
Siehe auch Abschnitt 4.3.3 Hardware-Voraussetzungen (S. 12)
2
4. IST-Analyse von MS Access
6
Microsoft vorgegebenen Benutzerkonten auf einfachste Weise manipulieren und es gibt ebenfalls keine
Möglichkeit, die Benutzerkonten vor Löschung zu schützen, wenn man den Benutzern das erforderliche
Recht, selbst ihr Kennwort festzulegen und zu ändern, nicht nehmen will. Gemäss Martin (250)
beinhaltet die Datenbank-Sicherheit ‘Sieben wesentliche Elemente’. Im folgenden werden diese und
deren Unterstützung durch MS Access genannt:
Eine Datenbank sollte:
- geschützt sein - die MS Access Metadatenbankdatei SYTEM.MDA lässt sich durch jeden
Benutzer löschen bzw. überschreiben - ebenso jede andere bearbeitbare Datenbank, da das
MS Access zugrundeliegende Betriebssystem MS DOS nur Sperrungen auf Dateiebene
unterstützt und sich bearbeitbare Dateien auch komplett überschreiben, also prinzipiell
löschen lassen.
- rekonstruierbar sein - MS Access besitzt kein Backup- und Recoverysystem.
- überprüfbar sein - MS Access besitzt weder ein Logbuch noch ein Data Dictionary.
- einbruchsicher sein - die von MS Access vorgegebenen Benutzerkonten la ssen sich sehr
leicht manipulieren, allerdings lässt sich die Datenbank verschlüsseln.
Ihre Benutzer sollten:
- Identifizierbar sein - ohne Logbuch lässt sich nicht ermitteln, wer wann welche Daten
verändert hat. Durch das Hinzufügen eines eigenen Logbuchs ist allerdings die
Identifizierbarkeit relativ gut gewährleistet.
Ihre Benutzer sollten zu bestimmten Aktionen:
- Berechtigt sein - MS Access unterstützt Zugriffsrechte auf Objekt-, nicht jedoch auf
Feldebene. Der Schutz der Feldinhalte vor den Datenbankentwicklern ist nicht möglich.
- Überwacht werden - es gilt das selbe wie für die Identifizierbarkeit.
Upsizing Möglichkeiten
MS Access kann als Übergangslösung zum Upsizing von ‘PC-Datenbanken’ auf einen
gemeinsamen Server sehr gute Dienste leisten - es im- und exportiert eine Vielzahl unterschiedlicher
Datenbankformate und die Access-Datenbanken lassen sich mit Hilfe eines Upsizing-Kits relativ leicht
auf einen SQL-Server übertragen. Mittlerweile bietet sich dazu auch Windows NT auch als High-EndDatenbankserver an. Die Nutzung von SMP (Symmetrisches Multiprocessing Mehrprozessorenrechner) durch Windows NT bringt zwar schon mehr Performance, Server Cluster
haben aber einen nahezu linearen Leistungszuwachs und sind deshalb ausbaufähig. Wenn diese
Technologie auch im PC-Serverbereich Verbreitung findet, sind enorme Leistungs- und in Verbindung
mit preiswerter PC-Standardhardware auch Einsprungpotentiale zu erwarten (Schmitt, 160). Der
Access Upsizing Kit ist ein Assistent für den Umstieg auf einen Microsoft SQL-Server. Da ein
professionelles System wie ein SQL-Server bezüglich der Bedienungsfreundlichkeit und der
Komplexität viel anspruchsvoller ist als eine für Endanwender entwickelte Datenbank wie MS Access,
kann der Upsizing Kit nur eine Arbeitserleichterung sein. Gladis schreibt: Dabei wird zwar viel Arbeit
gespart, trotzdem sind anschliessend aufwendige Umstellungen der Access-Anwendung erforderlich,
um die nötige Geschwindigkeit zu erreichen (64).
Professionelle Produkte auf MS Access Basis mit dem Developers Toolkit erstellen
Mit dem Access Developers Toolkit können auf vergleichsweise einfache Art Datenbanken zu
unabhängig von Access lauffähigen Anwendungsprogrammen gemacht werden (Matthey, 25). Die
erzeugten Anwendungen können (ohne Assistent-Funktionen) ohne weitere Kopierrechts-
4. IST-Analyse von MS Access
7
beschränkungen beliebig vervielfältigt und benutzt werden, was ein im Verhältnis zu vergleichbaren
Datenbanken relativ preisgünstiges Angebot ist. Der Access Developers Toolkit besitzt eine integrierte
Unterstützung zur Erstellung von Installationsdisketten mit eigenen Seriennummern und einen
Hypertext-Hilfesystem-Compiler. Der Ressourcenbedarf der erzeugten Anwendungen ist i.d.R.
identisch mit dem Ressourcenbedarf der entsprechenden Datenbanken in MS Access. Auch die
Performance ist zum grössten Teil identisch.
Aus den Vor- und Nachteilen von MS Access ergeben sich dessen Einsatzmöglichkeiten. Für
den Einsatz im Pivatbereich und Kleinbetrieben ergeben sich eine Reihe von Vorteilen. So ist MS
Access leicht erlernbar, preiswert, in ein Office-Packet integriert und auf einer für Kleinbetriebe und
den Privatbereich extrem verbreiteten Plattform lauffähig (auch Nutzung von OLE 2.0 möglich).
In Zweigstellen kommt als Vorteil die Unterstützung vieler Fremdformate bei der Verbindung zu
anderen Niederlassungen hinzu. In Arbeitsgruppen lässt sich MS Access als Programmteil des
Arbeitsplatzrechners in Client-Server-Anwendungen und für Arbeitsgruppeninterne Datenbanken
einsetzen. Für Softwareentwickler, die bereits mit Microsoft Visual Basic arbeiten, ergibt sich eine
leichtere Einarbeitung. Als Komplettsystem lässt sich MS Access somit in kleineren Betriebe und als
Frontend-Anwendung in grösseren Unternehmen zum Beispiel mit einem Microsoft SQL Server
zusammen einsetzen. In Grossunternehmen kann MS Access wegen der grafischen
Auswertungsmöglichkeiten und Unterstützung zahlreicher Fremdformate als Frontend-Tool für die
Unterstützung von Managementinformationssystemen (MIS) Verwendung finden.
4.2 Vergleich
4.2.1 Funktionsumfang
Ein Vergleich des Funktionsumfangs von Access mit anderen DBMS ergibt folgendes: 1
Access besitzt eine Mehrbenutzerverwaltung in Bezug auf Autorisierungskontrolle und
eingeschränkt in Bezug auf Konfliktregelungen, eine Meta-Datenbank (SYSTEM.MDA), einen QBEAssistenten, eine DDL (Access SQL), Einbindung fremder DB-Objekte mittels ODBC, bedingte
Referenzielle Integrität, Import-/Exportmöglichkeiten für viele Formate, einen
Datenbankreparaturmechanismus, ein QMF, ein ADF, einen gemeinsamen Bereich für mehrere
Tabellen, eine dynamische Erweiterung der physischen Bereiche, eine sortierte Ablage von Zeilen
unterschiedlicher Tabellen (Strukturabbildung), serielles Durchsuchen, den wahlfreien und seriellen
Zugriff über einen Index, die Index-Schnittmengentechnik, NULL-Indikatoren, eine feste Feldanzahl
(pro Tabelle), eine feste Feldlänge (ausser OLE-Objekte), eine integrierte Programmiersprache
(Access BASIC), einen Parser, einen Precompiler, einen Update-Prozessor, einen Abfrage-Optimierer
(Rushmore) für High-Level-Optimierung und bedingt für Low-Level-Optimierung, einen RecoveryManager für Transaktions-Revisionen, einen Transaktions-Manager und einen DatenbankDokumentierer. Es unterstützt Netzwerk- und einfache Plexstrukturen und erlaubt Zyklen.
Access besitzt kein aktives und kein automatisch-passives Data Dictionary (DD), keine
Unterstützung verteilter Systeme, keine referenzielle Integrität zu eingebundenen Objekten, kein
Wartungs- und Recovery-System, kein Datenrestaurations- und -revisionssystem, keine separate
1
Verglichen mit dem Funktionsumfang in folgenden Quellen:
Gillenson, Mark L.. Datenbank-Konzepte - Datenbanken, Netzwerke, Expertensysteme.
Scherff, Dr. J.. DB-Design. Skript FH Furtwangen (Nr. 81; 3.3-7)
Vetter, Max. Aufbau betrieblicher Informationssysteme - mittels konzeptioneller Datenmodellierung.
Vossen, Gottfried. Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme.
4. IST-Analyse von MS Access
8
Ablage einzelner (Access-)Tabellen, keine Optimierungsinformationen, keine variable Feldanzahl (pro
Tabelle), keine variable Feldlänge (ausser OLE-Objekte), keinen Recovery-Manager für Hard- und
Softwarefehler, keinen Dictionary-Manager, keinen Data Manager für verteilte Systeme, keinen
integrierten Geräte- und Speichermanager, kein Logbuch, keine Trigger, keinen HypertextHilfecompiler, keine Möglichkeit, Zugriffsrechte so einzustellen, dass man zwar Tabellenentwürfe
bearbeiten, jedoch nicht die darin enthaltenen Daten lesen kann (z.B. wichtig für Personaldaten <->
EDV-Abteilung) und unterstützt keine komplexen Plexstrukturen. Access hat keine
Beschreibungssprache für physiche Daten und kein dokumentiertes bzw. veröffentlichtes
Datenbankformat.
Access kann folgende Bestandteile - z.B. durch eigene Funktionen - relativ leicht bekommen: ein
passives, halbautomatisches Data Dictionary, ein Wartungs- und Recovery-System, ein
Datenrestaurations- und -revisionssystem, ein Logbuch1 und einen DB-spezifischen HypertextHilfstextcompiler (ist beim Developers Toolkit dabei). Das Problem hinzugefügter DBMS-Bestandteile
besteht jedoch darin, dass sie naturgemäss nicht die gleiche Zuverlässigkeit wie integrierte Bestandteile
aufweisen - die Zuverlässigkeit jedoch gerade im administrativen DBMS-Bereich eine grosse Rolle
spielt (z.B. Backup/Recovery-System).
Standardbestandteile eines Datenbankmanagementsystems und deren Unterstützung in MS
Access:
DDL (Data Definition Language) :
Access benutzt als DDL Access SQL. Access unterstützt dabei Zugriffsrechte auf die DDL
auf Abfrage- bzw. View- und Modulbasis. Access SQL ist eine Erweiterung von StandardSQL. Abfragen lassen sich wahlweise mit Access SQL oder dem grafischen QBE erstellen.
Optimierer (für Anfragen):
Microsoft Access kann Ausdrücke in der Zeile "Kriterien" des QBE-Entwurfsbereichs oder in
der WHERE-Klausel einer SELECT-Anweisung (SQL) optimieren. Ist der Index absteigend
und liegt ein anderer Vergleichsoperator als Gleich (=) vor, kann die Abfrage nicht optimiert
werden. (Rushmore)-Abfragen funktionieren sowohl in Verbindung mit Microsoft AccessTabellen als auch in Verbindung mit Microsoft FoxPro und dBASE-Tabellen (.DBFDateien). Rushmore kann jedoch nicht in Verbindung mit ODBC-Datenquellen verwendet
werden, da Access diese Abfragen direkt an die ODBC-Datenquelle sendet, anstatt sie lokal
zu verarbeiten. Access unterstützt High-Level-Optimierung und bedingt Low-LevelOptimierung.
Beziehungsintegritätsspezifikationen (Referential Integrity Constraints):2
Ein Trend in der Datenbanktechnik der letzten Jahre war es, Trigger durch RI-Regeln zu
ersetzen. Access unterstützt die meisten davon:
ASSERT/Gewährleistung: zu jedem Fremdschlüssel existiert ein Primärschlüssel - dies wird
durch die Option ‘Referentielle Integrität’ von Access unterstützt.
Löschen eines Primärschlüsselwertes:
- CASCADES: Weitergabe an Löschung (wl) - alle Fremdschlüsselwerte ebenfalls löschen wird von Access durch Aktivierung der Option ‘Löschweitergabe an
1
Siehe Grothe, Roland. „Kleine Kniffe für den Notfall“. Tips&Tools Sonderheft von VTP Fürst 5: 18-22.
Vorgaben aus: Vetter, Max. Aufbau betrieblicher Informationssysteme - mittels konzeptioneller
Datenmodellierung: 167.
2
4. IST-Analyse von MS Access
9
Detaildatensatz’ unterstützt.
- RESTRICT.: Bedingte Löschung (bl) - Solange entsprechende Fremdschlüsselwerte
existieren, wird die Löschung nicht akzeptiert - unterstützt Access durch
Deaktivierung der Option ‘Löschweitergabe an Detaildatensatz’.
- NULLIFIES: Nullsetzung bei Löschung (nl) - Alle entsprechenden Fremdschlüsselwerte auf
Null setzen (Nullwerte müssen dort allerdings zugelassen sein) - wird von
Access nicht unterstützt
Modifizierung eines Primärschlüssels:
- CASCADES: Weitergabe der Modifikation (wm) - Entsprechende Fremdschlüsselwerte
werden ebenfalls modifiziert - wird in Access durch Aktivierung der Option
‘Aktualisierungsweitergabe an Detailfeld’ unterstützt.
- RESTRICT.: Bedingte Modifikation (bm) - Solange entsprechende Fremdschlüsselwerte
existieren, wird Aktualisierung nicht akzeptiert - unterstützt Access durch
Deaktivierung von ‘Aktualisierungsweitergabe an Detailfeld’.
- NULLIFIES: Nullsetzung bei Modifikation (nm) - alle entsprechenden Fremdschlüsselwerte auf Null setzen (Nullwerte müssen dort allerdings zugelassen
sein - wird von Access nicht unterstützt.
QBE- Query by Example:
Als erstes von IBM (für die relationale Abfragesprache SQL) angebotener Abfragegenerator. Im
Gegensatz zum ersten QBE-Bereich lässt sich der in Access weitestgehend grafisch (Drag&Drop)
bedienen und ist deshalb benutzerfreundlich. Auch das Umstellen auf die SQL-Ansicht und die
Bearbeitung der erzeugten SQL-Befehle ist möglich.
QMF - Query Management Facility:
Datenerfassungsprodukt für relationale Abfragen und zum generieren von Berichten. Access besitzt
eine Reihe von Formular- und Berichtsassistenten, mit denen man in kürzester Zeit alle gängigen
Formular- und Berichttypen erstellen lassen kann. Eine nachträgliche manuelle Anpassung, z.B. der
Feldgrössen ist jedoch in den meisten Fällen erforderlich.
ADF - Application Development Facility:
Anwendungsgenerator. Access bietet für die Befehlsschaltflächen in Formularen eine Reihe von
Assistenten, die alle gängigen Standardfunktionen wie z.B. Bericht drucken, Datensatz suchen,
Applikation beenden usw. als Access BASIC-Code generieren können.
DD - Data Dictionary:
Access besitzt lediglich einen Datenbank-Dokumentierer. Mit ein bisschen Mehraufwand (Makro) lässt
sich daraus ein passives Data Dictionary erstellen, dass durch eine Momentaufnahme der Datenbank
immer wieder aktualisiert werden muss (nur bedarfsgesteuert bzw. manuell möglich). Die meisten der
heutigen relationalen Datenbanken führen dagegen ihre Datenkataloge automatisch nach. Dies ist
neben der schlechten Mehrbenutzerverwaltung ein weiterer Umstand, der Access für den Einsatz in
grösseren Systemen disqualifiziert.
Als sinnvolle Erweiterungen der Access-Datenbankmanagementfunktionen haben sich gemäss
obengenannter Aufzählung im Laufe des Praxissemesters folgende Funktionen bewährt:
Logbuch:
Festhalten aller Eingaben und Änderungen der Datensätze, sodass jeder beliebige frühere
Zustand der Datenbank wieder hergestellt werden kann, damit Kontrollen und Auswertungen
4. IST-Analyse von MS Access
10
bezüglich der Benutzungshäufigkeit und -schwankungen gemacht werden können und
entsprechend Massnahmen (z.B. Zugriffsoptimierung) vorgenommen werden können.
Diese Funktion lässt sich leicht in MS Access realisieren.
Automatisches Wiedersetzen auf der zuletzt bearbeiteten Maske:
Ermöglicht schnellere Orientierung des Benutzers und eine kürzere Überbrückungsphase bis
zum Einsatz. Mögliche jedoch nicht realisierte Erweiterung: Aufsetzen auf dem zuletzt
bearbeiteten Datensatz. Diese Funktion lässt sich ausgehend von einem Logbuch mit wenig
Aufwand realisieren.
Passives halbautomatisches Data Dictionary:
Dient dem Aufspüren von Synonymen, Homonymen und Redundanzen.
Führt zu einer schnelleren Einarbeitungszeit bei Wartung/Änderung, und unterstützt eine
halbautomatische Dokumentation (z.B. aufgrund der Feldbeschreibungen in den Tabellen).
Abhängigkeitskontrolle - ob ein Objekt gelöscht werden kann oder ob es noch irgendwo benutzt
wird und bessere Testmöglichkeiten z.B. aufgrund von Objektlisten, anhand derer sich die
einzelnen Objekte sukzessive testen und anpassen lassen. Die Abhängigkeitskontrolle ist
notwendig, weil Access im Gegensatz zu einigen anderen DBMS erst zur Laufzeit meldet,
wenn
Objekte fehlen. Diese Funktion beruht bei der eigenen Lösung auf der durch den
Datenbankdokumentierer erzeugten Tabelle ‘Objektdefinitionen’.
Eine andere Möglichkeit - der direkte Zugriff auf die Systemtabellen - wurde ebenfalls erprobt,
jedoch für zu aufwendig und unzureichend empfunden. Die vom Datenbankdokumentierer
erstellten Ergebnisse stimmten jedoch nicht überall korrekt mit den Originaleinstellungen
überein. So wurde aus der Formulareinstellung ‘Nicht bearbeitbar’ in der Dokumentation
‘Bearbeitbar’ und umgekert - weshalb alle im Data Dictionary verwendeten Angaben auf ihre
Richtigkeit zu überprüfen sind. Solche Fehler sind - falls sie unerkannt bleiben - besonders
schwerwiegend, weil man nicht nur keine Information sondern eine glaubhafte Fehlinformation
daraus erhält, was die Fehlersuche z.B. bei der Wartung erschweren kann.
Wartungsdienst:
Statt dem direkten löschen von Datensätzen werden diese - wie bei anderen
Datenbanksystemen
zum Teil auch möglich - deaktiviert. Im Wartungsdienst lassen sich dann alle deaktivierten
Datensätze in eine Backupdatenbank exportieren und löschen. Weiterhin lassen sich
Datensätze
gruppenweise deaktivieren (z.B. Alle Aufträge <X DM, die schon länger als Y Monate erledigt
sind). Der Vorteil dieses Wartungsdienstes liegt in der grösseren Sicherheit gegenüber
Fehlbedienung, Hardwaredefekten u.ä... Die Realisierung gestaltet sich bei rechtzeitiger
Einplanung (z.B. wegen Aktiv/Inaktiv Feld in jeder Tabelle) einfach.
Verbesserungsvorschlägeformular:
Findet ein Benutzer einen Fehler oder hat ein Benutzer Anregungen zur fertiggestellten
Datenbank, so kann er diese in einem Verbesserungsformular niederlegen. Bei
Updates/Wartungen werden dann diese Verbesserungsvorschläge vom Entwickler bearbeitet
und - wo möglich bzw. oft genug genannt, dass sich der Aufwand rechtfertigen lässt realisiert.
Dabei hat jeder Benutzer seinen eigenen Verbesserungsvorschlagsdatensatz. Diese Funktion
lässt sich zusammen mit einem Logbuch leicht realisieren. Da sich noch keine meiner
dergestalt
ausgestatteten Datenbanken lange genug in der Anwendung befand, kann ich keine Aussage
über die Effizienz einer solchen Funktion machen - bei der Entwicklung nach dem Prototyping-
4. IST-Analyse von MS Access
11
Prinzip und bei der exakteren Spezifikation der Anforderungen erhoffe ich mir jedoch dadurch
einen spürbaren Rationalisierungseffekt.
4.2.2 Vor- und Nachteile
Aus dem Funktionsumfang und der Funktionsgüte von Access lassen sich die Vor- und
Nachteile im Verhältnis zu anderen relationalen Datenbanken begründen - hier die wichtigsten:
Vorteile sind das sehr gute Preis-Leistungs-Verhältnis - auch für eine Datenbank im PC-Low-CostBereich, die Bediendungsfreundlichkeit nicht nur der fertigen Datenbanken, sondern auch der
Entwicklerfunktionen, die Zugriffsmöglichkeiten auf viele Fremdformate mit Einbinden/Import/Export
und die komfortable Datenübernahme in andere gängige Büroanwendungen aufgrund der Integration in
ein Office-Softwarepacket. Die Nachteile sind die Langsamkeit und der Ressourcenbedarf im
Verältnis zu vergleichbaren Datenbanken, die schlechte unausgereifte Mehrbenutzerverwaltung, die
fehlende Unterstützung verteilter Systeme sowie das fehlende Recovery- und Backup-System. Leider
bietet Access nicht die Möglichkeit wie bei Großdatenbanken üblich, im voraus die Tabellengrößen
festzulegen und die jeweiligen Erweiterungsgrößen anzugeben. Dadurch würde sich die Notwendigkeit
zur regelmäßigen Komprimierung, bei der zudem kein Benutzer zeitgleich auf die entsprechende
Datenbank zugreifen darf, erübrigen.
4.3 Technische Beschreibung
4.3.1 Objekttypen
Objekttyp
Beschreibung1
(deutsch
/englisch)
Datenbank/ MS Access verwaltet alle Objekte einer (logischen)
Database
Datenbank in einer Datei (mit Suffix ‘.MDB’), der der
Objekttyp Database entspricht.
Tabelle
/Table
Abfrage
/Query
Formular/F
orm
Bericht
/Report
Steuerelement
/Control
Makro
/Macro
Modul
1
entspricht einer Datei zur Speicherung von Daten in
anderen Datenbanken.
entspricht einem View in anderen Datenbanken, mit
QBE-Funktion, auch: Abfragedefinition
entspricht Maske in anderen Datenbanken, beinhaltet
zusätzlich auch Befehlsschaltflächen und
Ereignisprozeduren und kann auch gedruckt werden.
zur grafischen Auswertung der Daten und zum drucken
(mit Seitenansicht) als Dokument.
Steuerelement eines Formulars oder Berichts (z.B.
Eingabefeld)
strukturierte Definition einer oder mehrerer Aktionen.
Kein Aufzeichnungsmodus möglich. Aktionsaufrufe in
deutsch. Kann Bedingungen enthalten. Wird auch zum
Erstellen von Pull-Down-Menüs verwendet.
Microsoft Access-Basic Funktion ähnlich Visual Basic,
Wichtigste Einschränkungen2
Maximal 255 Benutzer gleichzeitig.
Theoretischer Wert - aus
Performancegründen und aufgrund
schlechter Mehrbenutzerverwaltung
nur sinnvoll einsetzbar bis ca. 20
Benutzer.
Maximale Grösse eines OLEObjektfeldes: 128 MByte.
Maximale Anzahl von Tabellen in einer
Abfrage: 16.
Maximale Anzahl der Verschachtelungen: 3 (z.B. Formular-Unterformular-Unterformular).
Gesamthöhe: 508 cm. Gleicze Max. Anz.
Versch. wie Formular.
-
Maximale Anzahl Zeichen in einem
Aktionsargument: 255.
-
Entspricht Matthey U., Meiser U.. ACCESS 2.0 - Das DATA BECKER Handbuch, Einstieg, Praxis, Referenz: 26
mit Ergänzungen.
2
Ebenfalls Matthey U.: 515 - 518 mit Auswahl gemäss einem Vergleich mit den eigenen Datenbanken.
4. IST-Analyse von MS Access
/Module
Dynaset
Snapshot
12
entspricht z.B. NATURAL auf PREDICT/ADABAS.
Tabelle oder Abfrageergebnis (aktualisierbar)
Tabelle oder Abfrageergebnis (nicht aktualisierbar)
Maximale Grösse: 128 MB
-
4.3.2 Datenbanktechnik
Tabellen
(gespeicherte
Daten)
Aktion
Datenfluss
Abfragen
(Datenansicht)
Ausf.*
Auslöser
*Öffnen, Format,
Filter, Formulare,
Abfragen, Berichte
Auslöser
Makros
Auslöser
Auslöser
Formulare
Berichte
Ausf.
Module
Funktionen
Öffnen/Format Subprozeduren
Ausführen/
Aufrufen
Druck,Ans.,Format
Öffnen, Format, Filter,
Formulare, Abfr., Berichte
Definieren Formulare, Berichte,
Abfragen, Tabellen
Abbildung 1 - Datenbanktechnik von MS Access (Viescas, 47)
4.3.3 Hardware-Voraussetzungen
Die erforderliche Hardware hängt im wesentlichen von der Datenbankgrösse und von der
Anzahl der gleichzeitig an einer Datenbank bzw. an einer Tabelle arbeitenden Benutzer ab. 1
Einzelplatzsysteme erfordern mindestens einen PC 80386SX/DX mit 6 MB Festplattenspeicher für die
Mindest-, 23 MB für die Vollinstallation, eine Maus oder ähnliches, eine EGA- oder VGA-Grafikkarte
und einen Monitor sowie 6 MB Arbeitsspeicher (logisch), MS-DOS 3.1 und MS-Windows 3.1.
Empfohlen wird ein PC 80486 mit 8 MB Arbeitsspeicher (physisch). Bei kleinen
Mehrbenutzersystemen ist ein PC 80486 mit 10 MB Arbeitsspeicher (physisch), bei etwas grösseren
12 MB Arbeitsspeicher (physisch) empfehlenswert. Bei den heute gebräuchlichen IBM-kompatiblen
PC liegt bezüglich des Einsatzes von MS Access der Performanceengpass in den meisten Fällen bei
unzureichendem Hauptspeicher.
1
Da die an einer Tabelle gleichzeitig arbeitenden Benutzer von vielen Faktoren abhängen (Anwendungsgebiet,
DB-Struktur usw.), können nur sehr grobe Angaben zur Anzahl der Arbeitsplatzrechner gemacht werden.
5 Erstellen relationaler Datenbanken
5.1 Grundsätze bei Softwareprojekten
In einigen Installationen werden heute 80% und mehr des Entwicklungsetats für Wartung und
Veränderung bestehender Programme und Daten gebraucht; höchstens 20% werden für die
Entwicklung neuer Verfahren eingesetzt. Dieses Verhältnis ist der Evolution der Datenverarbeitung
innerhalb einer Organisation extrem hinderlich. Entsprechend dieser Aussagen von Martin (47) ist es
heute wichtig, wartungsfreundliche Software, die gut designed und dokumentiert ist, zu erstellen. Aus
dieser Sicht ist Software durchaus mit einem physischen Produkt vergleichbar - gutes Design wirkt sich
auf die Qualität aus und die Konstruktion eines Produktes steht im Vordergrund. Um aber die Effizienz
des Designs messen und Design-Werkzeuge (z.B. Computer Aided Software Engineering (CASE)Tools) bewerten zu können, müssen bei der Softwareentwicklung - vergleichbar mit dem auf dem
Rechnungswesen basierenden Controling - Daten gesammelt werden (z.B. Zeitgerüste). Dies
bestätigen Aussagen, die auf langjährigen Erfahrungen von Softwareprojekteleitern wie Pressman wie
„the sooner you begin ‘writing code,’ the longer it’ll take you to get done“ (22) und „Poor up-front
definition is the major cause of failed software efforts“ (21) beruhen. Die Qualitätsziele und die damit
verbundenen Messzahlen können sich (jedoch) für jedes Entwicklungsvorhaben ändern - sind also
projektspezifisch festzulegen. Diese Aussage von Prof. Illik 1 ergibt sich dadurch, dass bei einem
Softwareprojekt viele unterschiedliche Anforderungen und Bedingungen wie Terminplanung,
Ressourcenplanung, Versionsproblematik, wechselnde Auftraggeberwünsche, Budget, Gesetze und
Einflüsse von Gutachtern gleichzeitig auftreten. Eine grosse Rolle bei der Gewichtung dieser Faktoren
spielt dabei, ob eine Software als Produkt für einen anonymen Massenmarkt oder als
Projektabwicklung für einen spezifischen Kunden entwickelt wird. Während ersteres hohe
Anforderungen an das Dialogdesign, die Fehlertoleranz und das Marketing stellt erfordert letzteres die
genaue Analyse des organisatorischen Umfeldes und die Entwicklung eines Wartungssystems.
Bedeutende Qualitätsmerkmale für Software sind Korrektheit (zum Beispiel gemessen in Fehlern pro
Kilo Lines Of Code (KLOC)), Wartbarkeit (zum Beispiel gemessen in Mean Time To Change
(MTTC)), Integrität und Benutzerfreundlichkeit.
Für effizientes Softwareengineering werden zunehmend CASE-Tools eingesetzt. Sie
unterstützen die Geschäftsprozessplanung (Analysephase), das Projektmanagement, die
Kundenbetreuung, diverse Analyse und Designbereiche (z.B. Critical Path Method, CPM und
Programmablaufdesign), Programmierung, Integration und Test, Prototyping, Wartung und
Gruppenarbeit. Während andere Disziplinen (z.B. Maschinenbau mit Computer Aided Design (CAD)
und Elektrotechnik mit Electronic System Design Automation (ESDA)) schon länger rechnergestütztes
Design machen, ist entsprechende Nutzung bei der Softwareentwicklung relativ neu. Durch immer
leistungsfähigere Hardware wird diesem Bereich jedoch in Zukunft eine grosse Bedeutung zukommen.
5.2 Entwicklungsvorgehensmodell
Es gibt einige verschiedene Entwicklungsvorgehensmodelle bei der Softwareentwicklung von
denen jedes spezifische Vor- und Nachteile besitzt. Die bekanntesten sind das Vorgehensmodell (auch
V-Modell), das Wasserfallmodell (oder Life-Cycle Modell) das Prototyping, das Gestaltungsebenenmodell von Vetter und das Spiralenmodell. Durch das Wasserfallmodell, das den Abschluss
einer Projektphase vor Beginn einer neuen voraussetzt, lassen sich leicht Milestones setzen und
detailliertere Aussagen über Kosten- und Zeitrahmen des Projektes machen. Durch das Prototyping,
1
Entnommen aus Vorlesungsunterlagen zu „Methoden im Software-Projekt“ der FH Furtwangen von Anton Illik.
5. Erstellen relationaler Datenbanken
14
bei welchem die Benutzer einen aufgrund von einem ‘schnellen Design’ erstellten Prototypen
evaluieren (z.B. aufgrund Pflichtenheft erstellt), wird eher sichergestellt, dass das fertige
Softwareprodukt den gewünschten Anforderungen entspricht. Das von B. Böhm entwickelte
Spiralenmodell versucht, die Vorteile beider vorgenannten Modelle zu vereinen, indem es in den
zeitlichen Ablauf des Prototyping die Komponente ‘Risikoanalyse’ integriert. Das
Gestaltungsebenenmodell von Vetter mit vier Gestaltungsebenen für den Projektentwicklungsprozess
ähnelt dem Wasserfallmodell, unterscheidet jedoch zwischen statischen und dynamischen Aspekten
bzw. zwischen konzeptionellem Datenbank-Design und Prozess- und Dialogdesign. Das V-Modell
strukturiert das Projekt zeitlich und logisch durch die Definition und Beschreibung von Phasen,
Produkten und Tätigkeiten. Damit soll eine einheitliche und personenunabhängige Vorgehensweise aller
Beteiligten bewirkt werden (Illik). Unter Prototyping versteht man gemäss der Aussage von Vossen:
„Es sei bemerkt, dass ein Prototyping auch anders verstanden werden kann...“ (158) auch die
„Entwurfs-Verifikation“ als letzter Schritt des Entwurfsprozesses und entsprechende
Performancemessungen und -optimierungen. Die oben genannten Sichtweisen lassen - wie Pressman
in seinem Schaubild auf Seite 34 zeigt, auch kombinieren. Unabhängig vom gewählten Modell fallen
Systemanalyse, Projektplanung und Anforderungsanalyse, Softwaredesign, Implementierung und Test
sowie Korrektur, Adaption und Erweiterung immer an. Zu jeder Phase ist eine ensprechende
Dokumentation zu erstellen, sodass diese im folgenden nicht als separater Abschnitt erscheint.
Das klassische Phasenmodell als Beispiel für ein Vorgehensmodell (Finkenzeller, 4):
Abbildung 2 - Klassisches Phasenmodell
5.2.1 Analyse
Hauptbestandteile der Analyse für ein Softwareprojekt sind die Bedarfsanalyse,
Durchführbarkeitsstudien, die Wirtschaftlichkeits- und technische Analyse, die Aufwandsschätzung, die
Risikoanalyse und die Anforderungsspezifikation.
Als erster Analyseschritt setzen sich bei der Bedarfsanalyse Systementwickler und Anwender
und - soweit vom Anwender verschieden - Endanwender mit den Bedürfnissen und deren Prioritäten
auseinander. Bei der darauffolgenden Durchführbarkeitsstudie wird die wirtschaftliche
Durchführbarkeit (Kosten/Nutzen), die technische Durchführbarkeit (Funktionalität, Performance, ...),
5. Erstellen relationaler Datenbanken
15
die rechtliche Durchführbarkeit (Datenschutz u.ä.) und Alternativen ermittelt. Die
Wirtschaftlichkeitsanalyse oder Kosten-Nutzen-Analyse ist dabei die bedeutendste.
Um Aussagen über den geschätzen Aufwand bezüglich der benötigten Resourcen (Menschen,
Hardware, Software) machen zu können, bedarf es aussagekräftiger Daten von früheren Projekten.
Als Entscheidungshilfe können dabei zunehmend CASE-Tools dienen. Gemäss den unterschiedlichen
Anforderungen der einzelnen Entwicklungsphasen gibt es dabei unterschiedliche Tools, die auch
integriert als Datenbank angeboten werden.
Die Risikoanalyse teilt sich in die Risikoidentifikation (Technisches und wirtschaftliches Risiko
(z.B. Markt, Strategie, Marketing, Management, Budget)), die Risikoprojektion gemäss den
Wahrscheinlichkeiten aufgrund der Daten früherer Projekte und dem Risikomanagement auf.
Wesentlichen Einfluss auf das Risiko haben Zeitvorgaben. Offene oder grosszügig ausgelegte Termine
ermöglichen eine Optimierung der Ressourcennutzung, während Abweichungen von festgelegten
Terminen (z.B. Markteinführungszeitpunkt vorgegeben durch das Marketing) extrem hohe Kosten und
Risiken verursachen kann (z.B. kein Markt mehr für das Produkt, Konkurrenzprodukt etabliert o.ä.).
Ausgangspunkt für die weiteren Entwicklungsphasen ist eine mit einem Projektplan realisierte
Anforderungsspezifikation. Dieser beinhaltet im wesentlichen Schätzungen, Projektrisiken,
Aufgabenverteilung, Projektressourcen, Organisationsaufbau und Kontrollmechanismen und wird im
Laufe des Projektes ständig verfeinert und korrigiert. Bezogen auf die Analyse wird darin der ISTZustand, der SOLL-Zustand, Randbedingungen, der Aufgabenkatalog, Systemanforderungen, die
Schnittstellendefinition und der Systemtestentwurf festgehalten.
Die zur Analyse und Spezifikation benötigten Modelle müssen einige Anforderungen erfüllen. Sie
müssen unter anderem unabhängig von der Implementierung, tolerant gegenüber Unvollständigkeit und
Fehlern und lokalisiert und lose gekoppelt sein. Die verbreitetsten Modelle zur strukturierten Analyse
sind das Datenflussdiagramm, das Control Flow Modell (CFM), das Warnier Diagramm (auch Data
structured system development (DSSD)), die Jackson Methode (auch Jackson System Development
(JSD)) und die Structured Analysis and Design Technique (SADT).1
Martin unterscheidet auf Seite 23 zwischen ‘Zwangsgesteuert oder bedarfsgesteuert’ als
wesentliches Klassifizierungsmerkmal von Verarbeitungsabläufen und beschreibt auf Seite 66 die
‘Unterschiede zwischen Planungs- und ausführenden Systemen’. Dabei stellen bedarfsgesteuerte
Verarbeitungsabläufe und Informations- bzw. Planungssysteme ungleich höhere Anforderungen an die
Entwicklung als zwangsgesteuerte und ausführende. Obwohl es klassische Anwendungsbeispiele für
beide Varianten gibt (Wetterbericht zwangsgesteuert, Kontenauskunft operationell, Management
Informations System (MIS) bedarfsgesteuertes Informationssystem) ist doch aufgrund der
leistungsfähiger werdenden Hardware und steigenden Benutzeransprüche ein Trend zu
bedarfsgesteuerten Informationssystemen erkennbar. Entsprechend den Systemanforderungen dieser
Kategorie von Systemen ist eine aufwendigere Analyse und ein aufwendigeres Design der Datenflüsse
des Unternehmens notwendig.
Bevor ein Datenbankentwickler in die nächste Entwicklungsphase geht, benötigt er ausser der
sich aus der Analyse ergebenden Informationen das volle Verständnis und die Unterstützungszusage
der Geschäftsführung des Auftraggebers und eine grobe definitive Festlegung der Anforderungen (z.B.
Pflichtenheft). Wie die Auswertung eines Projektes an dem ich während des Praktikums beratend
beteiligt war ergab, verdoppelte sich der Umfang einer zu erstellenden Datenbank von der ‘Mitte’ bis
zum ‘Ende’ der Analysephase. Zwingt man den Auftraggeber nicht, sich grob festzulegen, dann kann
1
SADT ist ein Warenzeichen der Softech, Inc.
5. Erstellen relationaler Datenbanken
16
dies entweder dazu führen, dass die Anforderungen nicht erfüllt werden, oder der Datenbankentwickler
finanzielle Verluste aufgrund des unterschätzten Aufwandes bis hin zum Konkurs erleidet.
5.2.2 Design
Ziel des Designs ist die präzise und formale Spezifikation des Systems, welches mittels statischer
Zerlegungsstrukturen in kleinere Einheiten aufgeteilt wird. Hier werden erstmals auch Realisierungsentscheidungen (WIE) ausgehend von den Anforderungen (WAS) der Analyse getroffen. Dies führt zu
einer Verfeinerung und Präzisierung der Systemanforderungen. Anforderung, Spezifikation und
Konstruktion werden dabei oft mehrmals durchlaufen. Design ist die erste der drei technischen Phasen
‘Design’, ‘Implementierung’ und ‘Test’ und lässt sich unabhängig von der Designmethode in Daten-,
Struktur- und System- oder Architekturdesign unterteilen. Das grobe Systemdesign ist dabei dem
detaillierten Struktur- und Datendesign vorgelagert (Top-Down-Ansatz). Als Ausgangsbasis für das
Design dienen die System- und die Systemtestanforderungen aus der Analysephase. Das Systemdesign
spezifiziert dabei die Anforderungen an einzelne Module und ist somit Voraussetzung für das
Moduldesign. Die Spezifikation der Anforderungen an jedes Modul ist wiederum die Grundlage der
Programmierung (Modulimplementierung). Sie umfaßt in erster Linie eine präzise
Schnittstellenbeschreibung. Die Beschreibung der eigentlichen Leistung des Moduls sollte abstrakt sein,
da Realisierungsdetails erst bei der Modulimplementierung geklärt werden müssen und sich so aufgrund
des systemunabhängigen Designs bei späteren Änderungen leichter Re-Engineering durchführen lässt.
Für jedes Modul wird ebenfalls ein Modultest gemäss den Testanforderungen aus der
Aufgabendefinition entworfen.
Gemäss der Aussage von Pressman „Design, code and test absorb 75 percent or more of the
cost of software engineering (excluding maintenance). It is here that we make decisions that will
ultimately affect the success of software implementation and, as important, the ease whith which
software will be maintained.“ (316) ist die Güte des Designs entscheidend für die erfolgreiche
Softwareentwicklung. Design bedeutet Qualität insofern, dass sie hilft, gegebenen Anforderungen zu
entsprechen. Gutes Design sollte hierarchisch organisierte, modulare Modelle mit loser Kopplung der
einzelnen Module liefern.
Um ein gutes Design zu erhalten und gegenüber der direkten Implementierung einen Vorteil zu
erhalten, muss eine Designnotation eine Reihe von Vorteilen gegenüber der Implementierungsnotation
besitzen und Anforderungen erfüllen. Eine Designnotation sollte modulare Softwareentwicklung
unterstützen, einfache Notationselemente besitzen, leicht bearbeitbar, maschinenlesbar und wartbar
sein, nur strukturierte Konstrukte zulassen, logisch überprüfbar und implementierbar sein.
Bezüglich der Benutzer-Software-Schnittstelle liegen grafische Benutzeroberflächen im Trend.
Die ersten Schnittstellen waren zeilenorientierte Kommando- und Abfrageschnittstellen. Eine
Verbesserung der Bedienungsfreundlichkeit wurde durch einfache Auswahlmenüs erreicht. Da die
Hardware immer leistungsfähiger wurde und immer schlechter ausgebildete Benutzer mit Computern
umgehen mussten erwies sich der Desk-Top-Ansatz (Nachahmung einer Schreibtischoberfläche auf
dem Bildschirm) zusammen mit einer Window-orientierten mausgesteuerten Oberfläche als geeignetes
Umfeld für zukünftige Interfaces und ist heute in administrativen Unternehmensbereichen verbreitet.
Interfacedesign, Benutzerhilfen und Fehlerbehandlung sind frühzeitig zu planen - von ihnen hängt im
wesentlichen die Benutzerakzeptanz ab. Deshalb sollte das Interfacedesign vor der Implementierung
mit entsprechenden Interface-Prototypen durch die (potentiellen) Benutzer evaluiert werden. Dies ist
meistens ein iterativer Prozess, bei dem Interfaces erstellt werden, eine Benutzerumfrage gemacht und
ausgewertet und entsprechende Interfaceanpassungen vorgenommen werden.
5. Erstellen relationaler Datenbanken
17
5.2.3 Implementierung
Die Implementierung setzt die detaillierte Spezifikation der Anforderungen voraus. Bei ihr geht
es um Realisierungsentscheidungen der Modulkonstruktion. Um nachträgliche Anpassungen zu
ermöglichen und eine personenunabhängige Implementierung zu gewährleisten, sind das Einhalten und
Festhalten von Konventionen, Daten, verwendeten und nicht verwendeten Algorithmen sowie ein
kommentiertes Programmlisting notwendig. Da die Ausfallsicherheit des Gesamtsystems von der der
Module abhängt (Die Ausfallsicherheit eines Systems entspricht in etwa dem Produkt der
Ausfallsicherheit seiner Komponenten) ist zudem eine detaillierte Test-Konstruktion, die Protokollierung
der Testergebnisse und Fehlerbeseitigungen sowie Code Reading
(Durchsichtsprotokolle/Ergebnisse/Schlußfolgerungen) und Know-How-Archivierung der
Entwicklungsdaten notwendig.
Zur Implementierung von Interfaces gibt es Interface-Implementationstools (User Interface
Development Systems (UIDS)), die Funktionen wie Eingabegeräteverwaltung,
Benutzereingabenüberprüfung, Fehlerbehandlung und Fehlermeldungsanzeige und Benutzerhilfe
beinhalten. Diese Tools verringern bei gleichzeitiger Steigerung der Interface-Qualität den
Implementierungsaufwand beträchtlich. Da bei gutem Design die Implementierung zum grossen Teil
nur noch Übersetzungsarbeit von einer Darstellungsweise in eine andere bedeutet, erscheinen
zunehmend Werkzeuge auf dem Markt, mit denen sich anhand des Designs der Code bzw. die Struktur
des Codes automatisch erzeugen lässt. Das im Fach ‘Objektorientiertes Systemdesign’ Rahmen eines
Scheinnachweises von uns getestete ‘Together C++’ von ‘Objective International‘ erzeugt zum
Beispiel anhand des Objektorientierten Modells alles bis auf die Funktionen. Werden diese noch
integriert, so lässt sich der Code direkt übersetzen und das ausführbare Programm erstellen und
ausführen.
5.2.4 Integration
Bei grösseren Projekten werden viele Programmierer eingesetzt. Dabei sollte idealerweise ein
Programmierer je ein Modul bzw. eine Funktionseinheit implementieren. Das Zusammenfügen dieser
Module bezeichnet man als Integration. Dabei kann es mehrere Integrationsebenen geben. Die
Arbeitsschritte der Integration ähneln dabei denen der Implementierung: Erstellung von SubsystemTestentwürfen, Subsystem-Validation, Subsystem-Integration, Subsystem-Testdesign, Montage
("montiertes Subsystem"), Validation ("validiertes Subsystem") und Fehlerbeseitigung. Bei der
Integration werden lineare und baumartige Integration (BI) unterschieden, wobei auch Mischformen
praktiziert werden. Die BI spielt vor allem dann eine Rolle, wenn die Integrationseinheiten
selbstständige Komponenten sind.1
5.2.5 Test
Da die Kosten von einer Entwicklungsphase zur nächsten immens sind (z.B. ein Analysator, 10
Designer, 100 Implementierer, 1000 Tester) werden Tests in jeder technischen Phase der
Softwareentwicklung durchgeführt und bei schwerwiegenden Mängeln die getestete Phase und die
davorliegende wiederholt (Ansatz des V-Modells) oder es werden solange Prototypen erstellt und
getestet, bis das Produkt fertiggestellt ist (Prototyping). Bezüglich des fertiggestellten Produktes lassen
sich folgende Softwarequalitätsfaktoren unterscheiden: Funktionalität (Korrektheit, Sicherheit, Effizienz,
Integrität und Bedienungsfreundlichkeit), Anpassungsfähigkeit (Wartbarkeit, Flexibilität, Testbarkeit)
und Übertragbarkeit (Portabilität, Wiederverwertbarkeit und Interoperabilität).
1
Entnommen aus Vorlesungsunterlagen zu „Methoden im Software-Projekt“ der FH Furtwangen von Anton Illik.
5. Erstellen relationaler Datenbanken
18
5.3 Erstellen von Datenbanken
5.3.1 Einordnung
Eine Datenbank ist ein Element eines Systems, wie das Schaubild von Pressman (133)
veranschaulicht:
Procedures
Documents
Input
Hardware
System
Database
Output
Software
People
Abbildung 3 - System elements
Dabei wachsen die Bestandteile Datenbank und Software durch Embedded Functions
zunehmend zusammen. So besteht zum Beispiel in ORACLE eine Maske aus mehreren Oberflächen
nebst den dazugehörigen Funktionen (z.B. Eingabekontrollen). Auch in MS Access sind
Datenbankelemente und Software eng miteinander verbunden (z.B. durch Ereignisprozeduren, Module
und Gültigkeitsregeln). Gemäss eigener Erfahrungen sind Analyse und Design sowie Implementierung
und Test bei der Datenbankentwicklung iterativer Prozesse, die fliessend ineinander übergehen und
sich vermischen.
5.3.2 Analyse
Die Analyse bei der Datenbankentwicklung ist der der Softwareentwicklung sehr ähnlich. Auch
hier geht man vom groben ins Detail. Wichtiger Bestandteil der Analyse bei der Entwicklung von
Datenbanken ist die Einführung eines Data Dictionarys. Die Data Systems Working Party der British
Computer Society bezeichnet ein Data Dictionary als Werkzeug zur Verwaltung der Struktur und der
Verwendung von Daten (Vetter, 353). Ein Data Dictionary beinhaltet bezogen auf eine Datenbank die
Beziehungen zwischen den Datenobjekten und die Datenelemente. Es sollte idealerweise
unternehmensweit Gültigkeit besitzen um Datenaustausch und Anpassungen zu vereinfachen.
„Gemeinsame Datensätze an jedem Standort werden unsere Effektivität erhöhen, die Probleme einer
Fabrik interpretieren und ihr helfen zu können, das Personal vom einen Ort zum anderen zu versetzen,
Verantwortlichkeiten für Produkte zu übertragen, Produktinformationen auszutauschen, neue Fabriken
aufzubauen ... Dies wird von grosser Bedeutung für neues Personal sein ... Es wird für unser Personal
5. Erstellen relationaler Datenbanken
19
leichter, Informationen auszutauschen, wenn diese Informationen in der gleichen Weise interpretiert
werden ... Andere Bereiche der Kommunikation im Unternehmen werden sehr verbessert ...
Schnellere und genauere Kommunikation ... Schnellere Anpassung an sich ändernde
Umweltbedingungen ... Verbesserte Führung ... Verbesserte Leistung zu niedrigeren Kosten ...
werden das Ergebnis sein“ (Martin, 6). Gerade bei der Einführung der EDV in ein Unternehmen ist
diese Standardisierung enorm wichtig, weil sie dort - im Gegensatz zu einem Unternehmen mit bereits
bestehender EDV - noch ohne erheblichen Zeit- und Geldaufwand möglich ist.
Wichtige Unterschiede einer Datenbank zu einem anderen Softwareprodukt sind, dass der
Schwerpunkt der Entwicklung bei den Daten und deren Organisation und nicht bei den Funktionen liegt,
und dass andere Softwareprodukte bezüglich der Daten eine mehr oder weniger umfangreiche, jedoch
fest vorgegebene Ansammlung von Datenstrukturen besitzen. Mit dem von E.F. Codd entwickelten
relationalen Datenbankkonzept wird hingegen die Organisation und Speicherung der Daten unabhängig
von jeder bestimmten Anwendung realisiert. Entsprechend sind die Module aus der Analyse und die
Designbereiche Daten-, Architektur-, und Funktionsdesign unterschiedlich stark ausgeprägt. Bei der
datenorientierten Vorgehensweise stehen (demgegenüber) die Daten im Mittelpunkt der Betrachtung.
Idealerweise versucht man dabei, zunächst eine sehr grobe, unternehmensweite Datenstruktur zu
ermitteln (8). Entsprechend dieser Aussage von Vetter, der zwischen einer daten- und einer
funktionsorientierten Vorgehensweise unterscheidet, ist bei der Entwicklung auch ein detaillierteres
Phasenmodell sinnvoll, wie Finkenzellers Neues Phasenmodell (6) verdeutlicht:
Abbildung 4 - Neues Phasenmodell
Abbildung 4 - Neues Phasenmodell (Finkenzeller, 6)
Durch den Trend zu bedarfsgesteuerten Systemen, der sich bei Datenbanken in der Verbreitung
von Systemen mit Embedded Funktions wiederspiegelt, relativiert sich dieser Unterschied etwas.
Aufgrund der im folgenden genannten Vorteile ist es dennoch sinnvoll, bei Datenbanksystemen dieses
Modell zu verwenden.
Zur Ermittlung von Konstruktionselementen und von optimalen, voll normalisierten
Datenstrukturen eignen sich Realitätsbeobachtungen, die Analyse der im Rahmen einer Applikation zu
produzierenden Formulare und Bildschirmausgaben, die Analyse existierender Datenbestände und
Interviews. (Vetter, 237). Diese Verfahren lassen sich auch kombinieren. Ich glaube dass es z.B.
sinnvoll wäre, mit Interviews zur groben Ermittlung der gesamten Unternehmensstruktur zu beginnen,
und dann in diese die Ergebnisse aus den anderen Verfahren einzuordnen.
5. Erstellen relationaler Datenbanken
20
5.3.3 Design
Softwaredesign war früher hauptsächlich auf die Modularisierung und Hierarchisierung von
Programmen beschränkt. Prozedurale Aspekte führten dann zur Philosophie der Strukturierten
Programmierung. Später wurden Schwerpunkte auf den Datenfluss und die Datenstruktur gelegt. Die
neueste Sichtweise für das Design ist die objektorientierte. Da diese aber zum Erstellen relationaler
Datenbanken nicht geeignet ist (z.B. Verletzung des objektorientierten Prinzips, dass Daten und
zugehörige Funktionen gekapselt werden), beschränkt sich die Designbetrachtung bezüglich des
Datenbankdesign auf die Sicht auf Datenfluss und Datenstruktur. Die Normalisierung, bei der eine
optimale Datenstruktur erreicht wird, stellt hierbei ein adäquates Mittel dar, dass bei der Entwicklung
relationaler Datenbanksysteme fast immer benutzt werden sollte und auch benutzt wird.
Normalisierung führt zu Funktionaler Unabhängigkeit, welche die effektive Modularität des
Funktionsdesigns unterstützt. Deshalb ist es sinnvoll, das Datendesign mit Hilfe der Normalisierung
stets zeitlich vor dem Funktionsdesign zu machen. Dabei ist - unabhängig von der endgültigen Struktur zuerst ein semantisches ideales Datenmodell zu entwickeln und in das „Ziel“-Datenmodell zu
transformieren. So lässt sich ein möglichst redundanzfreies Modell entwerfen, dass - wo aus
Performancegründen notwendig - im nachhinein an das System, auf dem es realisiert werden soll,
angepasst werden kann. Der für uns wesentliche Aspekt dieser Vorgehensweise beim
Datenbankentwurf besteht darin, dass es dem Datenbank-Designer bei Verwendung des ER-Modells
möglich wird, sein „Wissen“ bzw. seine Erkenntnisse über die vorgegebene Anwendung zu
organisieren, ohne bereits auf spezielle Beschränkungen oder Charakteristika eines konkreten Modells
(wie z.B. die ausschliessliche Verwendbarkeit zweistelliger 1:n-Beziehungen im Netzwerk-Modell)
Rücksicht nehmen zu müssen (Vossen, 160). Die Aussage Vetters: Es empfiehlt sich,
Computerapplikationen vom Groben zum Detail (englisch: Top-down) zu entwickeln und zu realisieren
(16) - unterstützt diese Vorgehensweise.
Obwohl es je nach Anforderung Datenbanken mit unterschiedlichem Verhältnis vom Daten- zum
Funktionsumfang gibt, beeinflusst gemäss eigener Erfahrungen die Güte des Datendesigns zusätzlich
dieses Verhältnis: Je besser das Datendesign ist, desto höher wird der Daten- und desto geringer wird
der Funktionsumfang einer Datenbank bei gleichen Restbedingungen sein. Gutes Datendesign kann
also gutes Programmdesign, effektive Modularität und reduzierte Prozedurenkomplexität unterstützen.
Das Entity Relationship Modell (ERM) ist die wichtigste Designnotation für relationale
Datenbanken. 1 Da dies datenorientierte Softwareprodukte sind, spielen funktionsorientierte Notationen
wie der Programmablaufplan (PAP) und die Nassi-Shneiderman Notation eine eher geringe Rolle.
Ebenfalls ist das datenflussorientierte Design ist für Datenbanksysteme bestenfalls ein Teilbereich umfassendere Designarten dafür sind das datenorientierte Design, das Jackson Structured Design und
das Data Structured Systems Development (von Warnier). Die von Vossen verwendete in Abbildung 5
sichtbare Notationsvariante des ERM (49), bei der die Attribute in separaten Kreisen dargestellt wird,
nimmt zu viel Platz in Anspruch und führt schon bei etwas grösseren Modellen zum Verlust der
Übersichtlichkeit. Die von MS Access verwendete in Abbildung 6 sichtbare Notation, in der die zu
einer Tabelle gehörenden Felder in einem Block zusammengefasst sind und der Tabellenname auf dem
Kopf des Blocks steht ist deshalb meiner Meinung nach von Vorteil.
1
Es erfüllt die in Abschnitt 5.2.2 Design genannten Anforderungen durchweg gut.
5. Erstellen relationaler Datenbanken
21
Wenig zusätzliche Information führt zu grösserer Unübersichtlichkeit:
AUTOR
TITEL
VERLAG
INVNR
B
m
ELHN
RDAT
1
L
ADRESSE
LNR
NAME
Abbildung 5 - entnommen aus Vossen, 49
Verzicht auf zwei weniger bedeutende Informationen zugunsten von Übersichtlichkeit:
Abbildung 6 - 'ensprechende' Umsetzung im Access-Beziehungsfenster
5.4 Vorgehen beim Erstellen mit MS Access
MS Access unterstützt Fouth-Generation-Techniques relativ gut. Durch das grafisch darstellbare
ERM, den komfortablen QBE-Bereich sowie Funktionsgeneratoren für Standardfunktionen und direkte
grafische Darstellungsmöglichkeiten der Daten mittels MS Graph lässt sich Software auf einem
verhältnismässig hohen Niveau spezifizieren. Dieses Niveau sollte jedoch nicht dazu (ver-)führen, die
Analyse- und Designphase bei der Softwareentwicklung zu vernachlässigen. Da zu einer
kommerziellen Datenbank unter MS Access noch einige DBMS Funktionen hinzugefügt werden
müssen, empfiehlt es sich, auch auf Wiederverwertbarkeit der hinzugefügten Bestandteile zu achten,
zumal sich in Access BASIC-Code von sehr hohem Allgemeinheitsgrad schreiben lässt. Gemäss
eigener Erfahrungen hat sich der Einsatz einer Basisdatenbank, die alle allgemein nutzbaren Funktionen
und Objekte enthält, bei der Datenbankentwicklung bewährt. Sie hilft den Unterschied des
Funktionsumfangs von MS Access zu einer professionellen Datenbank zu verringern. Wichtige
5. Erstellen relationaler Datenbanken
22
Bestandteile einer Basisdatenbank für MS Access sollten ein Backup- und Recovery-System und ein
Logbuch sein.
MS Access eignet sich aufgrund der vielfältigen Auswertungs-, Darstellungs- und
Verarbeitungsmöglichkeiten sowie seiner Bedienungsfreundlichkeit gut zum Einsatz in
bedarfsgesteuersten Systemen. Seine schlechte Ausnutzung der Ressourcen und die damit
einhergehende schlechte Performance machen es für zwangsgesteuerte Aufgaben, bei denen oft
grosse Datenmengen verarbeitet werden müssen, ungeeignet. Da bedarfsgesteuerte Systeme grössere
Anforderungen an das Ablaufdesign stellen, sollte auch bei der Entwicklung mit MS Access ein
separates Ablaufdesign erstellt werden. Dabei hat es sich als effizient erwiesen, die Struktur des PullDown-Menüs und das Ablaufdesign einander anzugleichen: Ausgehend von einem Hauptmenü lassen
sich alle weiteren Menü- und Bearbeitungsformulare entsprechend ihrer Stellung und Hierarchieebene
im Pull-Down-Menü ansteuern. Dies erhöht die Benutzerfreundlichkeit, verringert den
Entwicklungsaufwand und erhöht die Qualität des Systems.
Das Vorgehensmodell in Abbildung 4 ist für das Erstellen von Datenbanken unter MS Access im
allgemeinen gut geeignet.1 Ergibt sich bei der Analyse keine klare Anforderungsspezifikation, so ist zu
prüfen, ob das Schalenmodell zur Entwicklung nicht besser geeignet ist.
Es gibt keine speziell auf MS Access zugeschnittenen CASE-Tools und auch keine integrierte
CASE-Lösung. Zur effizienten Datenbankentwicklung - auch auf einem Low-Level-System wie MS
Access - sind diese jedoch empfehlenswert. Durch die gute grafische Darstellung des ERM in MS
Access lässt sich dies auch gleichzeitig als Designtool für das Datendesign benutzen. Für das
Funktionsdesign, den Programmablaufplan, die Formularhierarchie und -inhalte müssen externe
Zusatzprogramme hinzugezogen werden. Für die Implementierungsphase stellt MS Access
leistungsfähige Mittel wie einen QBE-Bereich, Formular- und Ereignisprozedurassistenten und
Diagrammassistenten zur Verfügung. Für die anderen Phasen der Softwareentwicklung sind
ergänzende CASE-Tools sinnvoll. Dabei lassen sich auch oft allgemeine Programme für CASE
benutzen (z.B. MS Excel für Entscheidungstabellen und Auswertungen).
Entwickelt man eine MS Access Datenbank zum Einsatz in einer Arbeitsgruppe in einem
Unternehmen oder in einer Zweigstelle oder ähnlichem, dann werden in der Regel schon
Datenbanksysteme vorhanden sein. Ist ein unternehmensweites Data Dictionary definiert, so sollte man
sich auch bei der Entwicklung der MS Access Datenbank aufgrund der in Abschnitt 5.3.2 Analyse
genannten Vorteile daran halten. Sind die Felder nicht einheitlich definiert, so kann man sich am
grössten im Unternehmen eingesetzten Datenbanksystem oder an dem, dass die meisten Schnittstellen
zur zu erstellenden Datenbank hat orientieren. Bei Kleinbetrieben, in denen eine reine MS Access
Lösung zu erstellen ist, und bei obengenannten Einsatzmöglichkeiten, wo keine Vorgaben zu entnehmen
sind, sind vor Abschluss der Analysephase für alle Daten, die den geplanten Kern und die spontane
Hülle des Datenbanksystems betreffen, Definitionen zu erstellen.
5.4.1 Design
MS Access läuft auf der Window-orientierten Benutzeroberfläche MS Windows. Dies
ermöglicht eine sehr benutzerfreundliche Gestaltung, erfordert jedoch auch ein separates InterfaceDesign, welches Layouts und Interaktionen zwischen Benutzer und Software spezifiziert. Das
Interface ist die ‘Verpackung’ der Software - gute Nutzung des inneren wird erst durch gute
Interfaces möglich, was ein Vorteil von Access-Datenbanken gegenüber Datenbanken in Systemen mit
1
Die gleichen gegenüber den anderen Vorgehensmodellen in Unterkapitel 5.2 Entwicklungsvorgehensmodell
genannten Vor- und Nachteile gelten auch hier, haben aber eine Access-spezifische Gewichtung.
5. Erstellen relationaler Datenbanken
23
zeilenorientierten Masken ist. Der menschliche Faktor spielt beim Interfacedesign eine grosse Rolle:
Visuelle Wahrnehmung, Lesegewohnheiten, Verhalten des Benutzers und Wahrnehmungsattribute wie
Grösse, Schärfe, Farbe, Position und Bewegung müssen ebenso berücksichtigt werden wie die
Verweildauer von Informationen im Lang- und Kurzzeitgedächnis. Ausserdem müssen sich die
Interfaces den Benutzerkenntnissen und dem Benutzerverhalten anpassen, weshalb Kontext- und
Bereichsbezogene Interfaces allgemeingültigen vorzuziehen sind. Grafische Oberflächen liegen im
Trend. Dies bestätigt ein Projekt, bei dem ich in beratender Funktion beteiligt war und bei dem sich die
Beteiligten trotz der offensichtlichen Vorteile, die eine textorientierte Oberfläche aufgrund der
vorhandenen Systemumgebung und vorhandener Software bezüglich des Projekts gehabt hätte, für eine
Lösung mit einer grafischen Oberfläche entschieden haben. Grafische Benutzeroberflächen können
helfen, die Furcht mancher Benutzer vor der unbekannten Technik durch Humane Computer
Interfaces (HCI), die die Benutzerbedürfnisse berücksichtigen, zu verringern. Dies spricht auch für den
Einsatz von MS Access als Frontend-Tool in einer bestehenden Datenbankumgebung.
Probleme beim Interfacedesign mit MS Access entstehen hauptsächlich bezüglich der
Systemantwortzeiten. Kriterien für Systemantwortzeiten sind die durchschnittliche Antwortzeit und die
Varianz der Antwortzeiten. In einer Mehrbenutzerumgebung bekommen die Antwortzeiten bei MS
Access eine hohe Varianz und bei ‘grossen’ Datenbanken wird die durchschnittliche Antwortzeit stark
vergrössert, was nur bedingt durch leistungsfähigere Hardware auszugleichen ist.1 Die in MS Access
integrierten Interface-Implementationstools (auch Formularassistenten) sorgen dafür, dass sich
Interfaces nicht nur komfortabel bedienen, sondern auch komfortabel erstellen lassen.
Durch die Möglichkeit, in MS Access Kombinationsfelder und Unterformulare zu verwenden,
lässt sich das Formulardesign gut vom ERM ableiten. Als Beispiel sei hier eine Tabelle ‘Person’
angeführt, die mehrere ‘Adresse’(n) besitzen kann, wobei jede Adressse mehrere ‘Telefon’(e)
beinhalten kann:
Abbildung 7 - Beispiel ERM zum Formulardesign
Aus diesem ERM lassen sich folgende Formulare ableiten (auf die grafische Darstellung wurde
aus Platzmangel verzichtet):
- Personenliste sowie Adressenliste und Telefonliste mit Kombinationsfeldern zur Auswahl der
korrespondierenden Primärschlüssel aus der ensprechenden Haupttabelle,
- Person mit ihren Adressen, Person mit ihren Telefonen und Person mit ihren Adressen und
den
dazugehörigen Telefonnummern,
- Adresse mit ihren Telefonen und der Auswahl der ensprechenden Person über eine
Kombinationsschaltfläche.
1
Referenz: Jörg Sobottka, Netzwerkadministrator der SUD SOLEIL GmbH Freiburg, die MS Access in einem
System mit ca. 18 Benutzern einsetzt.
5. Erstellen relationaler Datenbanken
24
Wenngleich auch nicht alle abgeleiteten Formulare benötigt werden sollten, führt dies doch zu
einer bezogen auf die Möglichkeiten von MS Access nahezu vollständigen Liste von Formularvarianten,
anhand derer z.B. durch eine Auswahl durch die Benutzer eine exaktere Spezifikation der benötigten
Formulare möglich wird.
Die von Martin genannten Vorteile der Trennung von Eingabe (Verarbeitungssystem) und
Ausgabe (Informationssystem) (Abb. 6.2, 70): bessere Anwortzeiten und leichtere
Wartungsmöglichkeiten gelten auch für MS Access Datenbanksysteme. Da in Access in
regelmässigen Abständen Datenbanken ‘komprimiert’ werden müssen, und während dieses Vorgangs
kein Benutzer auf die Datenbank zugreifen darf, ist die Trennung von Verarbeitungs- und
Informationssystem eine Möglichkeit, die Wartung auch während der Benutzung vorzunehmen. Der
Geschwindigkeitsvorteil beim Nur-Lesen von Daten zum Bearbeiten von Daten ist bei MS Access
Datenbanken erheblich1, was ebenfalls für die Aufteilung in zwei Teilsysteme spricht.
5.4.2 Implementierung
Bezogen auf die Kopplungsgüte ist beste Kopplungsart für Funktionen die Parameterübergabe
(Stamp Coupling), gefolgt von der Flagübergabe (Control Coupling), dem gemeinsamen Zugriff auf
globale Daten (Common Coupling) und der Nutzung von Daten eines anderen Moduls durch ein Modul
(Content Coupling)§. Dies macht sich auch bei MS Access bemerkbar: bei der Umstellung einer mit
einer deutschen Version von MS Access erstellten Datenbank auf eine englische erwies sich, dass die
Parameterübergabe bei Funktionsaufrufen interner Funktionen funktionierte, die Flagübergabe jedoch
angepasst werden musste.
Eine wichtige Realisierungsentscheidung ist, ob eine Funktion als Access BASIC Modul oder als
Ereignisprozedur realisiert werden soll. Ist die Funktion formularspezifisch, so lässt sich eine bessere
Kapselung von Interface und Interface-Funktionalität erreichen. Lässt sich die Funktion allgemeingültig
definieren, so ist ein Access BASIC Modul wegen der Redundanzfreiheit gegenüber mehreren
Ereignisprozeduren vorzuziehen. Auf jeden Fall ist zu prüfen, welcher Kohäsion und welcher Kopplung
die jeweilige Funktion bezüglich des Formulars und der gesamten Datenbank unterliegt, bevor man
diese Realisierungsentscheidung trifft.
Zur Entwicklung grosser Datenbanksysteme werden Subschemas verwendet, die die Sicht eines
Anwendungsprogrammierers auf die von ihm benutzten Datenfeldtypen und Satztypen bezeichnen. In
MS Access sind diese nach meiner Einschätzung vermutlich nicht sinnvoll. Die mit MS Access
erstellbaren Datenbanksysteme sind klein genug, dass eine vertikale Arbeitsteilung bei der Entwicklung
(z.B. gemäss der Entwicklungsphasen) ausreichend ist, sodass eine Person ausreicht, um die
Implementierung vorzunehmen. Die Integrationsphase entfällt dadurch ebenfalls.
1
Referenz: Jörg Sobottka, Netzwerkadministrator der SUD SOLEIL GmbH Freiburg, die MS Access in einem
System mit ca. 18 Benutzern einsetzt.
6 Umstellen von Datenbanken
Das Umstellen von Datenbanken beinhaltet das zumindest teilweise Erstellen einer neuen
Datenbank und die Übernahme oder Anpassung der Daten und gleicht somit in grossen Teilen dem
Erstellen einer Datenbank. Deshalb wird in den folgenden Unterkapiteln lediglich auf die Unterschiede
zum Erstellen von Datenbanken eingegangen.
6.1 Gefahren und Besonderheiten
Datenbanken umstellen heisst Daten anders zu organisieren. Danach kann man auch das
Umstellen der nicht-rechnergestützten Datenorganisation eines Unternehmens auf eine Datenbank als
‘umstellen’ bezeichnen. Bei der Migration rechnergestützer Datenorganisationen spielt eine
wesentliche Rolle, in welcher Generation von Datenbanksystemen die Daten vorliegen. Laut Vossen
(14) lässt sich die bisherige „Entwicklungsgeschichte“ von Datenbanksystemen (lässt sich) - ähnlich
wie bei Rechnern - in fünf Generationen gliedern, ... . Die erste Generation lies lediglich sequentielle
Verarbeitungsformen zu. Die zweite ermöglichte Dialogbetrieb und Direct File Access. Die dritte
unterschied zwischen logischen und physischen Informationen und benutzte Datenmodelle zur logischen
Beschreibung physikalischer Strukturen. Die vierte Generation trennte klar zwischen logischem und
physischem Datenmodell - wie dies für das relationale Datenmodell zutrifft.
Beim Umstellen einer Datenbank lassen sich aufgrund vorhandener Daten (empirisches
Vorgehen) die Anforderungen genauer spezifizieren. Müssen Daten übernommen werden, so ist eine
Übergangslösung und zusätzlich Zugriffs- und Sicherheitsaspekte für das vorhandene System zu
berücksichtigen.
Gründe, die das Umstellen eines Datenbanksystems auf ein neues erforderlich machen, sind z.B.
gestiegene Benutzeranforderungen bezüglich Auswertungsmöglichkeiten, Reaktionszeit und
Bedienungsfreundlichkeit, unzureichende Sicherheit des alten Systems und zu hohe Wartungskosten.
Da eine solche Umstellung i.d.R. Auswirkungen auf das gesamte Unternehmen hat und entsprechend
kostenintensiv ist, sollte in der Analysephase genau geprüft werden, welche Alternativen sich ergeben
und ob das Kosten-Nutzen-Verhältnis für die Umstellung stimmt. Oft bietet sich bei kleinen
Änderungen die Anpassung des vorhandenen Systems und bei Performanceproblemen das Tuning des
Systems anstelle der eigentlichen Datenbank (z.B. die Erweiterung der Hardware, meistens des
Hauptspeichers) als günstigere Alternative an. Unter dem Paradigma, dass sich die
Gesamtperformance eines Systems verbessert, wenn oft benötigte Daten schneller zugänglich sind als
selten benötigte, lassen sich z.B. aufgrund der Auswertung von Logbucheinträgen
Zugriffsoptimierungen machen. Einige Datenbankmanagementsysteme machen dies automatisch.
Ob ein Unternehmen seine Felder standardisiert bzw. einheitlich definiert hat (z.B. mit einem
Data Dictionary) spielt beim Umstellen einer Datenbank eine entscheidende Rolle. Bei vorhandenen
Standards ergeben sich weniger Definitionsprobleme und Missverständnisse, weniger
Synchronisationsprobleme an den Schnittstellen zu anderen (vorhandenen) Systemen und geringere
Kosten für den EDV-Bereich des Unternehmens insgesamt. Falls eine Datenbank ohne standardisierte
Felder umgestellt werden soll, muss der Inhalt aller Felder zuvor eindeutig definiert werden. Falls eine
unterschiedliche Benutzung der Felder z. B. in einzelnen Abteilungen vorhanden ist, muss eine
Definition der Felder durch jede Abteilung separat vorgenommen und das Ergebnis unter den
Abteilungen abgeglichen werden. Unter solchen Voraussetzungen ist es aufwendig und schwierig, die
vorhandenen Daten in das neue System zu übernehmen. Als Bestätigung zur Wichtigkeit der
Feldstandardisierung sei ein Projekt genannt, bei dem ich während des Praktikums involviert war und
6. Umstellen von Datenbanken
26
dessen Inhalt es war, ein ‘Auftragslistenprogramm’, dass in mehreren Werken unabhängig voneinander
benutzt wurde, durch ein benutzerfreundlicheres, sichereres Datenbanksystem zu ersetzen. Obwohl
man sich früh darauf einigte, dass die vorhandenen Daten nicht übernommen werden müssten, war die
einheitliche Definition der Felder der neuen Datenbank aufgrund der gewohnten unterschiedlichen
Sichten auf diese durch die jeweiligen Benutzer in einem Werk aufwendig.
6.2 Entwicklungsvorgehensmodell - Varianten
Die Entwicklungsphasen beim Umstellen einer Datenbank unterscheiden sich nicht wesentlich
von denen beim Erstellen einer Datenbank. Dies stützt die Aussage von Vetter: Dazu ist zu sagen, dass
das in den vorangegangenen Kapiteln geschilderte Verfahren unbesehen auch für existierende
Datenbestände zur Anwendung gelangen kann. Das heisst, man wird in den bestehenden
Datenbeständen zunächst die - bislang vermutlich nur intuitiv berücksichtigten Konstruktionselemente ausfindig machen und für letztere ein voll normalisiertes Relationenmodell
definieren (271). Der kritische Bereich beim Umstellen liegt in der Übergangsphase: die vorhandene
Datenbank wird benutzt, das Unternehmen ist von ihr abhängig. In diesem Zusammenhang ist das
Umstellen eines vorhandenen Systems auf ein neues mit einem ‘Gewaltakt’, wie es immer noch in
manchen Unternehmen durchgeführt wird mit einer kriminellen Kurzschlusshandlung gleichzusetzen,
weil diese Art der Umstellung den Informationsfluss des gesamten Unternehmens lähmen kann. Durch
die zunehmende Abhängigkeit der Unternehmen vom Produktionsfaktor ‘Information’ kann dies leicht
zum Konkurs des Unternehmens führen. Deshalb nennt Vetter ‘Das evolutionäre Vorgehen’ (271)
und ‘Das revolutionäre Verfahren’ (272) als Möglichkeiten, Datenbanken umzustellen. Beim
evolutionären Vorgehen werden Analyse und Design durchgeführt und bei den laufenden Anpassungen
an neue Bedürfnisse das Design des neuen Systems als Leitbild für die entsprechenden
Strukturänderungen genommen. Mit diesem Verfahren kommen Verbesserungen erst nach längerer
Zeit zum Tragen und die Durchführung erfordert Disziplin, da sich die an Anpassungen Beteiligten
längere Zeit an eine Vorgabe halten müssen, deren Nutzen nicht direkt ersichtlich ist. Beim
revolutionären Verfahren werden bis zum Einsatz alle Entwicklungsphasen durchlaufen. Neue
Applikationen werden nach der Fertigstellung der neuen Datenbank gemäss dieser realisiert und beide
Systeme - neue und alte Datenbank - laufen solange parallel, bis alle erforderlichen Applikationen auch
auf dem neuen Datenbanksystem realisiert wurden. Dieses Verfahren bringt einen erhöhten
Arbeitsaufwand mit sich und kann zu Synchronisationsproblemen aufgrund der redundanten
Datenführung führen. Die Nachteile des einen Verfahrens sind dabei jeweils die Vorteile des anderen.
Ich halte auch eine Modifikation des evolutionären Vorgehens für sinnvoll, nach der man nicht nur
Anpassungen vornimmt wenn existierende Datenbestände an neue Bedürfnisse angepasst werden
müssen, sondern bereits wenn Ressourcen zur Anpassung frei sind.
6.3
Vorgehen bei MS Access
Aufgrund der geringen Grösse von MS Access Datenbanken hat sich gemäss eigenen
Erfahrungen das evolutionäre nicht und das revolutionäre Verfahren bedingt zum Umstellen als
geeignet erwiesen. Vielmehr hat sich gezeigt, dass oft die komplette Umstellung in einer kurzen Phase,
in der die Benutzer die Datenbank nicht benötigen, machbar und sinnvoll ist. Bei MS Access
Datenbanken müssen in regelmässigen Abständen ohnehin solche Unterbrüche stattfinden um die
Datenbank zu ‘komprimieren’, d.h. um freigewordene Pages in der Datenbankdatei auch wirklich
freizugeben. Bei der Umstellung entwickelt man nun unabhängig von der vorhandenen Datenbank eine
neue mit einer idealen Datenstruktur. Nachdem diese entwickelt und gut getestet wurde, wird die
automatische Übernahme der Daten der alten Datenbank in die neue z.B. mittels Access BASIC und
Abfragen vorbereitet. Ein Beispiel für eine solche Funktion ist ein Algorithmus, der aus einer
Mitarbeitertabelle, in der sich die Gebäude als redundante Datensätze befinden, die Gebäude
herausfiltert, Duplikate herausstreicht, einen Zählerschlüssel vor jedes Gebäude setzt anstelle der
6. Umstellen von Datenbanken
27
Gebäudeeinträge in der Mitarbeitertabelle den entsprechenden Fremdschlüssel einsetzt. Alle
Funktionen werden dabei genau dokumentiert. Wurden mittels automatischer Funktionen alle Daten der
alten Datenbank soweit möglich in die neue übernommen, so sucht man einen Zeitraum, in dem die
vorhandene Datenbank nicht benutzt wird und vereinbart einen Termin, ab dem die neue Datenbank in
Betrieb gehen soll. In diesem Zeitraum überträgt man nun den neuesten Stand der Datenbestände der
vorhandenen Datenbank mittels der zuvor erstellten Funktionen in die neue. Da die Funktionen bereits
erprobt und dokumentiert wurden, sollte dies ohne grössere Probleme und schnell machbar sein. Ab
diesem Zeitpunkt wird dann die neue MS Access Datenbank benutzt. Das revolutionäre Vorgehen
lässt sich mit einer Modifikation auch gut einsetzen: Der Nachteil dieses Vorgehens ist, dass es
aufgrund der doppelt geführten Datenbestände zu Synchronisationsproblemen kommen kann. Da MS
Access eine Reihe von Fremdformaten einbinden kann, bietet es sich an, die Tabellen der alten
Datenbank in MS Access lediglich einzubinden, sodass der Benutzer eine Zeitlang entweder die
vorhandene oder die neue Datenbank benutzen kann und auf die gleichen Daten zugreift. Vorteile
dieser Methode sind, dass sich der Benutzer allmählich an die neue Datenbank gewöhnen kann und
dass sich diese besser austesten lässt (z.B. durch Bug-Reporting der Benutzer). Allerdings eignet sich
dieses Vorgehen nur, wenn die neue Datenstruktur nicht wesentlich von der vorhandenen abweicht.
Ist das primäre Ziel einer Umstellung die Erhöhung der Benutzerfreundlichkeit bei gleicher
Funktionalität und genügt die vorhandene Datenstruktur den Anforderungen, dann ist in der Regel
letztgenanntes Vorgehen sinnvoll. Genügt die vorhandene Datenstruktur nicht den Anforderungen und
sind umfangreiche funktionale Änderungen oder Erweiterungen vorzunehmen, ist das erstgenannte
Verfahren vorteilhaft.
Vorsicht ist in Bezug auf die Machbarkeit der Umstellung gegeben. Vor der Umstellung ist
genau zu analysieren, ob die Anzahl der vorhandenen und neu zu erfassenden Datensätze und die
Anzahl der Benutzer für die Umstellung auf MS Access nicht zu gross ist. Ansonsten kann es in MS
Access relativ schnell passieren, dass man trotz guter Kenntnisse über die Datenbankoptimierung,
ODBC und die Jet-Engine keine ausreichende Performance erreicht.
7 Fallbeispiel
Zu entwickeln war eine Kursverwaltung für das Werk eines Unternehmens. Da die
Anforderungen am Anfang unklar waren, wurde ein kombiniertes Vorgehen gewählt, bei dem gemäss
dem Prototypingmodell Analyse und Design mehrmals durchlaufen wurden bis die Anforderungen
genau spezifiziert waren. Danach wurden die nächsten Phasen Implementierung und Test mit
Korrektur mehrmals hintereinander durchgeführt, wobei der Testanteil auf Kosten des
Implementierungsanteils stets stieg. Leider wurde zu spät bemerkt, dass sich die aufgewendete Zeit
durch ein Modell zur Wiederverwertung von Formularteilen bezüglich der Formularerstellung um ca.
52% reduzieren liesse bei gleichzeitiger Verbesserung der Qualität und geringerem Reengineering- und
Wartungsaufwand. Dennoch wurde für weitere Datenbanken zusätzlich dieses
Formulardesignablaufschema erstellt. Weiterhin wurde zu früh im Projektes ein funktionierender
Prototyp erstellt, was sich im nachhinein nicht als sinnvoll erwiesen hat und einen Mehraufwand von
zwei Stunden mit sich brachte.
Die Phasen beinhalteten dabei folgende Tätigkeiten (Zusammenfassung aus der Zeiterfassung):
Phase/Dauer
Analyse:
Gesamtzeit:
10 h 55 min.
Durchschnitt:
55 min.
Design:
Gesamtzeit:
25 h 39 min.
Durchschnitt:
77 min.
Implementierung:
Gesamtzeit:
16 h 42 min.
Durchschnitt:
67 min.
Test:
Gesamtzeit:
9 h 41 min.
Durchschnitt:
65 min.
Dokumentation:
Gesamtzeit:
3 h 30 min.
Durchschnitt:
70 min.
Tätigkeiten
Gespräch mit dem Auftraggeber über ERM, Formulare und deren Inhalte, mögliche
‘Listenausdrucke’, Formularlayouts. Auswertung der durch die Benutzer erstellten
Formularlayouts, Abklärung neuer Aspekte, Evaluierung von Tabellen- und
Felddefinitionen, ERM, PAP und Formularstruktur durch den Auftraggeber und den
Benutzer.
ERM mit MS Access erstellen, beschriften und zur Evaluierung ausdrucken, Prototypdatenbank erstellen mit Formular, -ausdrucken und -beschreibungen (nur ‘Tote Masken’).
PAP erstellen. Anpassungen an ERM, PAP und Formularlayouts (oft) und
Formulardesignablaufschema erstellen.
Erstellen und Anpassen von Tabellen gemäss ERM und von Abfragen gemäss Tabellen
und Druckformularen, Formulare an Abfragen anpassen, Menümakros gemäss PAP
erstellen. Überarbeitung der Formulare gemäss Formulardesignablaufschema, Korrektur
von Formularen nach Test (oft), Druckformulare erstellen, diverses.
Formulartests mit Testdatensätzen (oft), allgemeine funktionale Tests der Formulare, Test
der Druckformulare, Test der gesamten Datenbank (Zugriffsrechte u.ä.).
Hilfetext und Dokumentationstext erstellen. Dokumentation der Tabellen, -attribute,
Formulare, Abfragen und Menümakros nach der Designphase.
HINWEIS: Mittels dem Datenbankdokumentierer und eigener Add-Ons konnte etwa die
Hälfte der Dokumentation automatisch erstellt werden (z.B. Übernahme der
Feldbeschreibungen in den Tabellen). Zum Teil wurden lediglich die Ergebnisse der
Designphase archiviert (PAP, ERM, Formulardesignablaufschema u.ä.).
7. Fallbeispiel
29
Die Auswertung der Zeitaufwände für die einzelnen Phasen ergab folgendes Diagramm:
Abbildung 8 - Zeitaufwand pro Entwicklungsphase
Eine ‘Objektorientierte’ Zeiterfassung wäre sinnvoller gewesen, da sich dadurch der Aufwand
für weitere Projekte wesentlich exakter schätzen lässt (z.B. bei niedriger Streuung in einer Objektart
Durchschnittswerte, ansonsten mit Komplexitätsgraden o.ä.). Allerdings wäre dabei der
Zeiterfassungsaufwand ungleich höher gewesen. Für Zeitangaben über die Wartung und Anpassungen
ist die Datenbank zu kurze Zeit im Einsatz.
Ein Vergleich des Designs am Anfang und am Ende der Analyse/Designphase ergab bei den
Tabellen eine Steigerung von 5 auf 12, bei den Attributen von 35 auf 69 und bei den Formularen von 5
auf 98 (inklusive Druckformularen). Bei einer schlechten Analyse wären demnach ca. die Hälfte der
gewünschten Anforderungen nicht erfüllt worden.
Die genaue Definition der Attribute und Tabellen in der Analyse-/Designphase stellte sich als
wichtig heraus: Durch ein Missverständnis wäre eine wichtige Tabelle nicht berücksichtigt worden.
Weiterhin ergab sich die Möglichkeit, die so erstellten Definitionen und Beispiele für die Dokumentation
und die Benutzerhilfe zu verwerten.
Im folgenden erscheinen Ausschnitte aus den Ergebnissen der Designphase. Aus Platzmangel
wurde auf Beispiele der Implementierung und Dokumentation sowie die vollständige Darstellung der
Designergebnisse verzichtet. Die Reihenfolge der Darstellung entspricht der chronologischen
Reihenfolge der Erstellung. Als Hilfsmittel zur Erstellung wurden das ‘Beziehungen...’ Fenster von MS
Access, MS Paintbrush und Chartist von Novagraph verwendet.
7. Fallbeispiel
30
Das Entity Relationship Modell wurde direkt in MS Access erstellt, in Paintbrush übernommen,
beschriftet und als Bitmap abgespeichert. Die Definition der Attribute geschah durch die Auswertung
der Attributsbeschreibungen in den Tabellen über den Datenbankdokumentierer:
Abbildung 9 - ERM - Auszug
Der Programmablaufplan bzw. die Menüstruktur wurden mit dem Programm ‘Chartist’ von
‘Novagraph’ erstellt. Jeder Benutzer setzt die ersten X mal beim Start der Datenbank bei einem Intro
auf, und danach wahlweise beim Intro oder beim Hauptmenü. Wurden Daten bearbeitet, so setzt der
Benutzer auf dem Formular wieder auf, in dem er diese zuletzt bearbeitet hat. Die Pfeile bedeuten,
dass man mittels Befehlsschaltflächen zu diesen Formularen wechseln kann. Formulare sind rechteckig
dargestellt. Man kann jedes Formular entweder direkt über das Pull-Down-Menü, das den gleichen
Aufbau hat oder über indirekt über eine Befehlsschaltfläche erreichen.
Intro
START*
Hauptmenü
Spez
Mit
Geber
Ort
Gruppe
MitLis
Anb m.Leit
Ort m. Kur
Art
Mit m.
Teil+Bew
Typ
Abbildung 10 - PAP/Menüstruktur - Auszug
OrtLis
Anb
7. Fallbeispiel
31
Beim Formulardesign wurde die Formularbezeichnung unterstrichen und der Name in Klammern
dargestellt. Attributen, deren Wert durch eine Kombinationsschaltfläche gesetzt wird, geht ein
Doppelpunkt voran. Unterformulare sind durch einen Pfeil mit ihren Hauptformularen verknüpft, an
dem die beiden Verknüpfungsattribute stehen.
Art des Kurses
(KU-FO-SpezArt)
SpezArt#,:SpezGrup#,SpezArt,
SpezArtAkt
Kursgruppe
(KU-FO-SpezGrup)
SpezGrup#,
SpezGrup,
SpezGrupAkt
Art des Kurses
(KU-FO-SpezArt)
SpezArt#,:SpezGrup#,SpezArt,
SpezArtAkt
Kursgruppe mit Kursen
(KU-FO-SpezGrup0HKur)
KurGrup#,
KurGrup,
KurGrupAkt
SpezTyp#:SpezGrup#
Kursliste
(KU-FO-KurLis)
Kur#, :GebLeit#,
:Ort#,:SpezTyp#,
KurMinTeil,
KurMaxTeil,
KurVor, KurPreis,
KurBem, KurAkt
Kurse
(KU-FO-SpezGrup1UKur)
Kur#, :GebLeit#,
:Ort#,:SpezTyp#,
KurMinTeil,
KurMaxTeil,
KurVor, KurPreis,
KurBem, KurAkt
Abbildung 11 - Formulardesign - Auszug
Anbieter mit Leitern
(KU-FO-GebAnb0HLeit)
GebAnb#, GebAnb,
GebAnbOrt,
GebAnbTel,GebAnbAkt
GebAnb#:GebAnb#
Leiter
(KU-FO-GebAnb1ULeit)
GebLeit#,GebAnb#,
GebLeitNac,GebLeitVor,
GebLeitTel,GebLeitAkt
Kursart mit Kursen
(KU-FO-SpezArt0HKur)
SpezArt#,:SpezGrup#,SpezArt,
SpezArtAkt
Ort mit Kursen
(KU-FO-Ort0HKur)
Ort#,Ort,OrtAkt
Ort#:Ort#
Kurse
(KU-FO-Ort1UKur)
Kur#, :GebLeit#,
Ort#,:SpezTyp#,
KurMinTeil,
KurMaxTeil,
KurVor, KurPreis,
KurBem, KurAkt
Ort mit Terminen
(KU-FO-Ort0HTer)
Ort#,Ort,OrtAkt
7. Fallbeispiel
32
Das Formulardesignablaufschema beschreibt die Wiederverwertungsmöglichkeiten von
Formularen und unterteilt sich in vier Stufen, von denen in Abbildung 12 nur die obersten zwei sichtbar
sind. In der obersten Stufe beträgt der Erstellungsaufwand 100%. Dort werden Listenformulare
erstellt. In der zweiten Stufe werden die Listenformulare zu Haupt- und Unterformularen angepasst mit
einem geschätzen Aufwand von 50%. In der dritten Stufe werden Formulare, die nur als Unter- oder
Hauptformulare vorkommen erstellt mit einem Aufwand von 100%. In der vierten Stufe werden die
Haupt- und Unterformulare der zweiten und dritten Stufe in anderen Kombinationen zusammengefügt
und angepasst. Der geschätzte Aufwand hierfür beträgt 5% bis 20%.
MitLis
Art m. Typ
Typ
Art
Gruppe
Typ m. Teil
Abbildung 12 - Formulardesignablaufschema - Auszug
KurLis
Grp.m.Kur
Leit
8 Literaturverzeichnis
(bearbeitete Literatur)
Babo, Michael von. „32-Bit-Verlockungen“. Windows Guide Schweiz Special 2b (1995).
Bager, Jo. „Von Kunden und Dienstleistern - aktuell:CeBIT’95:Client/Server“. c’t 6 (1995): 76-78.
Brosius, Gerhard. Das Access 1.1 Sprachreferenz-Handbuch. Düsseldorf, Wien: Addison-Wesley, 1993.
Finkenzeller, Hermann und andere. Systematischer Einsatz von SQL-ORACLE - Entwurf und Realisierung
eines Informationssystems. Bonn: Addison-Wesley, 1989.
Gillenson, Mark L.. Datenbank-Konzepte - Datenbanken, Netzwerke, Expertensysteme. Sybex, 1991.
Gladis, Rolf. „Kletterhilfe - Die Access-Upsizing-Tools“. c’t 2 (1995): 64.
Grothe, Roland. „Kleine Kniffe für den Notfall“. Tips&Tools Sonderheft von VTP Fürst 5 (1994): 18-22.
Hock, Martin. „Clipper-Erbfolger für Windows - Computer Associates liefert Visual Objects 1.0 aus“.
c’t 2 (1995): 44.
Hüskes, Ralf. „Gebündelte Produktivität? - Office-Pakete im Vergleich“. c’t 12 (1994): 222.
Kolberg, Michael. Microsoft Access - auf einen Blick. Unterschleissheim: Microsoft Press, 1994.
Lambert, Colleen. ODBC: Architecture, Performance and Tuning. (MSDN CD Level 1).
Litwin, Paul. Jet Database Engine 2.0: A User's Overview. (MSDN CD Level 1)
Martin, James. Einführung in die Datenbanktechnik. 3. Auflage. München, Wien: Hanser Carl, 1981.
Matthey U., Meiser U.. ACCESS 2.0 - Das DATA BECKER Handbuch, Einstieg, Praxis, Referenz.
DATA BECKER, 1994.
Miller, Martin u.a.. „Banker-Leiden - Die Datenbankschnittstelle ODBC in der Praxis“. c’t 3 (1995): 306.
Philip, Picuri. „Eine Investition in die Zukunft - Interview mit ...“. Windows Guide Schweiz Special 2b
(1995).
Pressman, Roger S.. Software Engineering. 3. Auflage. Hamburg:McGraw-Hill, Inc., 1992.
Schmitt, Dr. Hans-Jochen. „Buchprüfung der Datenbankiers - Der Stand der Dinge bei PC-SQLServern“. c’t 6 (1995): 76-81.
Staud, Kurt. „Supervisor - Access 2.0-Anwendungen besser organisieren“. c’t 3 (1995): 260.
Steiner, René. Theorie und Praxis relationaler Datenbanken. Braunschweig/Wiesbaden:Vieweg, 1994.
Vetter, Max. Aufbau betrieblicher Informationssysteme - mittels konzeptioneller Datenmodellierung.
4. Auflage. Stuttgart: B.G. Teubner, 1987.
Viescas, John L.. Microsoft Access - Professionell nutzen. Unterschleissheim: Microsoft Press
Deutschland, 1994.
Vossen, Gottfried. Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme.
Bonn: Addison-Wesley, 1987.
7. Fallbeispiel
Weimer, Günter. „Solutions“. Microsoft Werbeheft 1 (1995)
34