RDB Design DG

Universität Gesamthochschule Kassel
Fachbereich Wirtschaftswissenschaften
SEMINARARBEIT
„RELATIONALES DATENBANKDESIGN“
Zu dem Seminar
„Daten - und Informationsmanagement“

von Dr. Burkhard Hermes
Sommersemester 2001
Eingereicht von: Erstgutachter:

Daryush Ghassemi Dr. Burkhard Hermes
Oberer Schleifrain 23
34286 Spangenberg Zuordnung:
E-Mail: ghassemi@student.uni-kassel.de SP II/D – Prüfungsleistung
www.ghassemi.de
RELATIONALES DATENBANKDESIGN
Inhalt
EINLEITUNG / PROBLEMSTELLUNG........................................................................................................... 4
INFORMATIONSMANAGEMENT, DATENMANAGEMENT, DATENBANKDESIGN........................... 5
HISTORISCHE ENTWICKLUNG DER IV-ORGANISATION ........................................................................................ 5

Die technische Entwicklung ........................................................................................................................... 5
Die organisatorische Entwicklungsgeschichte: ............................................................................................. 6
Beurteilung der technischen und organisatorischen Entwicklung................................................................. 7
NOTWENDIGKEIT VON DATENBANKSYSTEMEN IM RAHMEN DES INFORMATIONSMANAGEMENTS ....................... 8
DEFINITION VON DATENBANKSYSTEMEN .......................................................................................................... 10
ARCHITEKTUR VON DATENBANKSYSTEMEN – DREI-SCHICHTEN-SCHEMAARCHITEKTUR:................................ 11
ZUM BEGRIFF DER RELATIONALEN DATENBANKEN ........................................................................ 13
ANFORDERUNGEN AN EIN RELATIONALES DATENBANKSYSTEM........................................................................ 14
DER ENTWURFSPROZESS – DESIGN EINER RELATIONALEN DATENBANK................................. 15
ANFORDERUNGEN AN EINEN SYSTEMATISCHEN ENTWURFSPROZESS................................................................. 15

PHASENMODELL („WASSERFALLMODELL“) DES SOFTWARE-ENGINEERINGS .................................................... 16
DIE PHASEN DES DATENBANKENTWURFS.......................................................................................................... 17
Phase 1: Die Anforderungsanalyse.............................................................................................................. 18
Phase 2: Konzeptioneller (fachlicher) Entwurf ........................................................................................... 18
Phase 3: Der Verteilungsentwurf................................................................................................................. 19
Phase 3b: DBMS-Auswahl........................................................................................................................... 19
Phase 4: Logischer Entwurf......................................................................................................................... 20
Phase 5: Datendefinition ............................................................................................................................. 20
Phase 6: Physischer Entwurf ....................................................................................................................... 21
Phase 7: Implementierung + Wartung......................................................................................................... 21
DAS PRAXISBEISPIEL – DIE HANDELSHOCHSCHULE KASSEL ........................................................ 22
PHASE 1 – DIE ANFORDERUNGSANALYSE ......................................................................................................... 22

Zu abstrahierende Objekte: ......................................................................................................................... 23
Eigenschaften (Attribute) der Objekte: ........................................................................................................ 23
Beziehungen der Objekte: ............................................................................................................................ 24
PHASE 2: DER KONZEPTIONELLE ENTWURF ...................................................................................................... 25
Grundlagen des Entity-Relationship-Modells: ............................................................................................ 25
Unser konzeptuelles Modell:........................................................................................................................ 27
PHASE 3: DER LOGISCHE / RELATIONALE ENTWURF .......................................................................................... 29
Überführung von Entitäten .......................................................................................................................... 29
Überführung von 1:n – Beziehungen ........................................................................................................... 30
Überführung von 1:c – Beziehungen ........................................................................................................... 30
Überführung von n:m – Beziehungen .......................................................................................................... 31
PHASE 3B: NORMALISIERUNG ........................................................................................................................... 32
PHASE 4: DATENDEFINITION ............................................................................................................................. 33
PHASE 5: IMPLEMENTIERUNG ............................................................................................................................ 36
Schemagenerierung über ODBC ................................................................................................................. 37
DEFINITION DER ZUGRIFFRECHTE ..................................................................................................................... 38
2
Datenbankrechte.......................................................................................................................................... 38
Tabellenrechte ............................................................................................................................................. 38
DEFINITION VON SICHTEN ................................................................................................................................. 39
Sichten & Datenschutz................................................................................................................................. 39
DER EINSATZ DES DATENBANKSYSTEMS .............................................................................................. 40
BEISPIEL: EINE ABFRAGE .................................................................................................................................. 40
SCHLUSSBEMERKUNG .................................................................................................................................. 41
ABKÜRZUNGSVERZEICHNIS ....................................................................................................................... 42
ANHANG: SOFTWAREWERKZEUGE FÜR DIE DATENBANKENTWICKLUNG ............................... 43
COMPUTER ASSOCIATES ERWIN 4.0 .................................................................................................................. 43

EMBARCADERO ER/STUDIO 4.2 ......................................................................................................................... 43
IDS SCHEER ARIS TOOLSET 4.0 ........................................................................................................................ 43
SYBASE POWERDESIGNER 7.0............................................................................................................................ 44
SILVERRUN RELATIONAL DATA MODELER .......................................................................................................... 44
KBSI SMARTER................................................................................................................................................. 44
MICROSOFT VISIO 2000 PROFESSIONAL / ENTERPRISE EDITION .......................................................................... 44
QUELLEN ........................................................................................................................................................... 45
3
Einleitung / Problemstellung
Relationale Datenbankmanagementsysteme sind schon seit über zwei Jahrzehnten die
führenden Datenbanksysteme1. Ursache für ihren Erfolg ist ihre Fähigkeit, eine hohe
Leistungsfähigkeit mit einer einfachen Handhabung zu kombinieren – selbst der Anfänger
kann mit ihnen intuitiv funktionsfähige Datenbanken erstellen2.
Relationale Datenbanken erlauben es, eine flexible und offene Informationsbasis zur
Verfügung zu stellen, und machen so komplexe Anwendungssysteme (wie z.B.
Bibliotheksverwaltungen oder PPS-Systeme) überhaupt erst möglich.
Der Umfang und die immer komplexer werdenden Abhängigkeiten der Daten voneinander
erzwangen eine computerunterstützte Verwaltung und Bereitstellung3. Wesentliche Aufgabe
der EDV war es dabei, Daten schnell, zu jeder Zeit, aktuell, bedarfsgerecht aufbereitet und
gleichzeitig für verschiedene Nutzer zur Verfügung zu stellen.
Jedoch ist eine Datenbasis immer nur so gut wie ihr struktureller und funktionaler Aufbau,
und die zunehmende Integration der verschiedenen Informationssysteme (nicht nur im
betriebliche Bereich) hat die Qualität der Datenorganisation stärker als bisher in den
Vordergrund treten lassen. Beispielsweise hat sich herausgestellt, dass die Kosten in der
Einsatzphase einer Datenbank die (an sich schon nicht geringen) Kosten für den Entwurf
und die Implementierung einer Datenbank bei weitem übertreffen.
Mit der Erkennen der Notwendigkeit, Information als strategischen Erfolgsfaktor

einzusetzen4, verlagerte sich der Hauptzweck der EDV von der Datenverarbeitung zur
Datenbereitstellung für die Informationsversorgung.5
Aus diesen Gründen ist ein systematischer Ansatz beim Umgang mit Daten zwingend
notwendig und auch in der Praxis längst allgemeingültiger Standard6.
Mit diesem systematischen Ansatz will sich diese Hausarbeit beschäftigen.
1
Allerdings kündigt sich ihre allmähliche Absetzung durch objektorientierte Datenbanksysteme an.
Diese dürfte allerdings noch einige Zeit dauern, und kann auch nicht Gegenstand meiner Hausarbeit
sein. Für weitere Informationen zu Objektorientierten Datenbanken siehe Vossen (1995) S. 336-389
und S. 577-601.
2
Es sei an die vielen mit MS Access oder ähnlichen Einbenutzersystemen realisierten Anwendungen
erinnert.
3
Vgl. Hald / Nevermann 1995, S. 1
4
Vgl. Heinrich 1992, S. 32
5
Heinrich 1992, S. 176
6
Hinzu kommen noch Performance-Anforderungen. Diese sollen bei meinen Ausführungen
ausgeklammert bleiben, da eine Behandlung zum einen den Rahmen sprengen würde; zum anderen
ist das Ziel nach Performance anderen Zielen entgegengesetzt, so daß eine Behandlung in einer
einführenden Schrift wie dieser eher verwirren würde.
4
Informationsmanagement, Datenmanagement, Datenbankdesign
Historische Entwicklung der IV-Organisation

Bei einer geschichtlichen Betrachtung des Informationsmanagements, des
Datenmanagements und des Datenbankdesigns muss man sowohl technische als auch
organisatorische Aspekte berücksichtigen; denn es fand einerseits sowohl eine
fortschreitende Entwicklung der Hard- und Software, andererseits aber auch eine ständige
Veränderung und Zunahme der Anforderungen an die Datenverarbeitung statt.
Die technische Entwicklung7

Die „technische Entwicklungsgeschichte“ lässt sich in fünf Generationen gliedern:
1. Generation 50er Jahre Dateisysteme auf Band
2. Generation 60er Jahre Dateisysteme auf Platte
3. Generation 70er Jahre Prärelationale DBS
4. Generation 80er Jahre Relationale DBS
5. Generation 90er Jahre Postrelationale DBS
Systeme der 1. Generation verfügten lediglich über eine Stapelverarbeitung. Jedes

Programm wurde mit „seinem“ speziellen Datensatz bzw. Datenbestand ausgestattet. Der
Zugriff auf die Daten erfolgte sequentiell.
Systeme der 2. Generation ermöglichten erstmals die Dialogverarbeitung8. Zudem erlaubte

die Entwicklung neuartiger Dateisysteme den wahlfreien Zugriff. Man konnte nun auf einen
bestimmten Datensatz über seine Adresse direkt zugreifen, ohne alle physisch „davor“
liegenden Datensätze durchlaufen oder lesen zu müssen. Zur Bestimmung einer solchen
Adresse diente dabei bspw. eine Indexdatei.
Systeme der 3. Generation hatten bereits eine erste Form von Datenunabhängigkeit.
Sie führten eine erste Unterscheidung zwischen logischen und physischen Informationen;
auch zeichneten sie sich durch eine zunehmende Verwaltung der Daten aus (im Gegensatz
zu deren reiner Verarbeitung). Erstmalig wurden Datenmodelle9 benutzt (wie das
hierarchische Datenmodell und das Netzwerkdatenmodell10).
Systeme der 4. Generation (die bis heute aktuell sind) basieren auf dem einfachen
relationalen Modell, und verfügen über einen hohen Grad an physischer
Datenunabhängigkeit. Das bedeutet, dass Änderungen der physischen Organisation der
Daten keine Auswirkungen auf angebundene Anwendungssysteme haben.
7
Vgl. hierzu und im folgenden: Vossen (1994), S. 4 f.
8
siehe Hansen (1996), S. 869
9
Ein Datenmodell beschreibt auf abstrakter Ebene einen gegebenen Ausschnitt aus der Realwelt, z.B.
einer Bibliothek . Da der Begriff "Datenmodell" eigentlich in mehreren Bereichen der Informatik
genutzt wird, müsste es eigentlich korrekterweise "Datenbankmodell" heißen, wenn von einem
Datenmodell für eine Datenbank die Rede ist (vgl. hierzu Vossen 1994, S. 22).
10
Für nähere Informationen zu den beiden Modellen siehe Hald/Nevermann (1995) S. 28-34
5
Systeme der 5. Generation (auch „Postrelationale Systeme“ genannt) umfassen sowohl

Erweitert-Rationale Systeme, anwendungsspezifische Systeme (z.B. CAD-Datenbanken), als
auch gänzlich andere Systeme (z.B. objektorientierte Systeme)11.
Die organisatorische Entwicklungsgeschichte:12
1. Phase Die Datenverarbeitung im Finanz- und Rechnungswesen

2. Phase Die aus dem Finanz- und Rechnungswesen herauswachsende Datenverarbeitung
3. Phase Die Emanzipation der Datenverarbeitung
4. Phase Die Entstehung des Informationsmanagements
1. Phase: Die Datenverarbeitung im Finanz- und Rechnungswesen

Die erste Phase war durch die Automatisierung stark formalisierter betrieblicher Aufgaben
mit einem hohen Datenanfall gekennzeichnet. Derartige Aufgaben fanden sich in der Lohn-
und Gehaltsabrechnung und in der Finanzbuchhaltung. Ziel des Technikeinsatzes war eine
beschleunigte Abwicklung und eine Erhöhung der Genauigkeit der Abrechnungsergebnisse
bei gleichzeitiger Kostenreduktion.
Die daraus resultierenden Aufgaben des Informationsmanagements beschränkten sich auf
die Anwendungsprogrammierung bei im wesentlichen unveränderter Struktur- und
Ablauforganisation sowie auf die Bedienung der Datenverarbeitungsanlagen und der
Datenerfassungsgeräte.
2. Phase: Die aus dem Finanz- und Rechnungswesen herauswachsende Datenverarbeitung

Die zweite Phase war dadurch gekennzeichnet, dass auch betriebliche Aufgaben außerhalb
des Finanz- und Rechnungswesens automatisiert wurden. Auch dabei handelte es sich um
Aufgaben mit starkem Formalisierungsgrad und hohem Datenanfall.
Die daraus resultierenden Aufgaben des IM wuchsen, wenn auch zunächst nur quantitativ.
Die wachsende Bedeutung der DV führte zur Bildung von DV-Abteilungen, welche entweder
der Unternehmensleitung als Stabsabteilung zugeordnet waren oder als Linienabteilung
geführt wurden.
3. Phase: Die Emanzipation der Datenverarbeitung

In der dritten Phase begann sich die Informationstechnologie über die stark formalisierten
betrieblichen Aufgaben hinaus auszubreiten; sie wurde nun auch für Planungs- und
Steuerungsaufgaben eingesetzt. Erprobte Methoden für diese nur schwach strukturierbaren
11
Für nähere Informationen zu den postrelationalen Systemen siehe Kemper (1996) S. 311 ff. sowie
S. 355 ff.
12
Vgl. hierzu und im Folgenden: Heinrich (1992), S. 40 ff.
6
Aufgaben waren nicht vorhanden, sodass die individuellen Bedürfnisse der Benutzer eine
große Rolle spielten.
Die Entstehung des Informationsmanagements13

Die vierte Phase begann, als man die Notwendigkeit aller im Zusammenhang mit der
Informationsverarbeitung stehenden Aufgaben erkannte. Auslösendes Moment für das
Erkennen dieser Notwendigkeit war die sichtbar gewordene Desintegration von
Anwendungsaufgaben durch den Einsatz von IuK-Technologien (beispielsweise von
Datenverarbeitung einerseits und Textverarbeitung andererseits), mit ihren negativen
Auswirkungen.
Mit der zunehmenden Verteilung der Informationsinfrastruktur und der zunehmenden
Verlagerung der Aufgaben auf die Fachabteilungen entstand ein Qualifikationsbedarf, der zu
einer erhöhten Selbständigkeit der Endbenutzer führte.
Damit stieg gleichzeitig der Koordinationsbedarf, insbesondere für die Abstimmung der
Aufgaben zwischen der individuellen IV einerseits und der unternehmensweiten IV
andererseits.
Beurteilung der technischen und organisatorischen Entwicklung

Ab dem Zeitpunkt der Entstehung von Systemen der 4. Generation kam zu einem Wachstum
der Kommunikationsnetze und zu einer Verbreitung von PCs. Aus dieser zunehmenden
Vielfalt folgte der Zwang zur Integration.
So leitete diese Phase den Wandel vom Informationssystemmanagement (verstanden als
Planung, Entwicklung und Betrieb von Informationssystemen14) zum
Informationsmanagement (verstanden als die betriebliche Informationsfunktion betreffendes
Leitungshandeln15) ein; der Schwerpunkt der Informationsverarbeitung verlagerte sich immer
mehr von der Datenverarbeitung zur Datenbereitstellung16.
Es stand nicht mehr der technische Aspekt, nicht mehr die bloße Unterstützung von
Informations- und Kommunikationsprozessen im Vordergrund; sondern vielmehr die
gewachsenen Möglichkeiten der IuK-Technologie zur Schaffung neuer Erfolgspotentiale.
Beispiele hierfür sind:
• Die Unterstützung der Produktentwicklung durch CAD-Technologien
• Die Veränderung von Produktionsweisen und Produktionsprozessen durch PPS-Systeme
• Die Unterstützung der Entscheidungsfindung durch „Executive Information Systems“
(Führungsinformationssysteme)17.
13
Vgl. Hierzu und im Folgenden: Heinrich (1992), S. 43 ff.
14
Vgl. Hansen (1997), S. 114
15
Vgl. Heinrich (1992), S. 11
16
17
Vgl. Link (1996), S. 151-152 sowie Link (1996) S. 182 f.
7
Notwendigkeit von Datenbanksystemen im Rahmen des Informationsmanagements

Information ist laut Heinrich „handlungsbestimmendes Wissen über historische,
gegenwärtige und zukünftige Zustände der Wirklichkeit und Vorgänge in der Wirklichkeit“18;
Informationsmanagement wird von Heinrich als das gesamte, die Informationsfunktion einer
Betriebswirtschaft betreffende Leitungshandeln verstanden.19
Die Ziele des Informationsmanagements lassen sich in Sach- und Formalziele
unterscheiden. Während die Sachziele den Zweck des IM definieren, beschreiben die
Formalziele, mit welcher Qualität die Sachziele erreicht werden sollen.20
Aus den Sachzielen leiten sich die Aufgaben des IM ab; diese lassen sich in strategische
Aufgaben (welche die Informationsinfrastruktur gliedern und strukturieren), administrative
Aufgaben (welche die Planung, Überwachung und Steuerung der Informationsinfrastruktur
umfassen), und operative Aufgaben (welche die Nutzung der Informationsinfrastruktur und
damit die „Produktion“ von Information umfassen) unterteilen.21
Da Informationen letztlich auf Daten basieren, führt eine unzureichende Datenhaltung

zwangsläufig zu einer unzureichenden Informationsversorgung. Demzufolge ist ein explizites
Management der Daten notwendig; dieses wird als „Datenmanagement“ bezeichnet, und
gehört zu den administrativen Aufgaben des IM.
„Aufgabe des Datenmanagements ist es, auf der Grundlage der Datenarchitektur22 alle im
Unternehmen verwendeten Daten (...) zu planen, zu überwachen und zu steuern, und zwar
so, dass die zur Informationsversorgung aller Aufgabenträger erforderlichen Daten verfügbar
sind.“23
Aus dieser Aufgabe werden folgende Teilaufgaben abgeleitet:24

• Entwickeln eines Datenmodells (Datenanalyse)
• Implementierung des Datenmodells (Datenbankentwurf)
• Organisation der Datenbeschaffung und Datennutzung
• Wartung und Pflege des Datensystems (Daten-Reengineering)
In meiner Hausarbeit soll es um die Entwicklung und Implementierung eines Datenmodells

gehen.
18
Heinrich (1992), S. 7
19
20
21
Vgl. Heinrich (1992), S. 20-21
22
Heinrich versteht unter einer Architektur eine Gliederung und Struktur, die sowohl durch ihren
Gegenstand (z.B. Daten, Anwendungssysteme oder Technologien), als auch durch ihre Sichtweise
(z.B. Benutzersicht, Entwicklersicht) gekennzeichnet ist.
23
Heinrich (1992), S. 176
24
8
Hier eine graphische Darstellung des Zusammenhangs:
Generelle Sachziele
Strategische Aufgaben
Strategische Situationsanalyse
Strategische Zielplanung
Strategie-Entwicklung
Strategische Maßnahmenplanung
Administrative Aufgaben
Projektmanagement
Datenmanagement
Datenanalyse + Datenbankentwurf
Anwendungssystem-Management
Technologiemanagement
Personalmanagement
Benutzerservice
Sicherheitsmanagement
Katastrophenmanagement
Operative Aufgaben
Produktionsmanagement
Problemmanagement
Doch auch ohne ein explizites Informationsmanagement lässt sich auf den Einsatz von
Datenbanksystemen nicht verzichten, da ansonsten Redundanzen25, Inkonsistenzen26,
Datenverlust, Integritätsverletzungen, Sicherheitsprobleme sowie ein unverhältnismäßig
hoher Wartungs- und Änderungsaufwand auftreten werden.
Insgesamt sind von Datenbanksystemen folgende Anforderungen zu erfüllen:
• Gewährleistung kurzer Zugriffszeiten
• Gewährleistung der leichten Aktualisierbarkeit der Daten
• Gewährleistung beliebiger Auswertbarkeit der Daten
• Gewährleistung von Unabhängigkeit und Flexibilität (z.B. gegenüber den AWS)
• Gewährleistung der Datenintegrität (Korrektheit und Vollständigkeit)
• Gewährleistung der Datensicherheit (Schutz vor Datenverlust)
• Gewährleistung des Datenschutzes (Schutz vertraulicher Daten vor unbefugtem Zugriff)
• Gewährleistung der Effizienz
• Gewährleistung der Transaktionssicherheit27
25
Redundanz ist die mehrfache Speicherung desselben Sachverhalts.
26
Widersprüche zwischen den verwalteten Daten
27
Transaktionen sind logisch zusammengehörende Aktionen, die Operationen auf die gemeinsam
gespeicherten Daten ausführen (Hansen 1996, S. 963). Ein Beispiel wäre eine Ab- und
Gegenbuchung auf einem Bankkonto.
9
Definition von Datenbanksystemen

Wenn wir in der Umgangssprache „Datenbank“ sagen, so meinen wir damit meist ein
Datenbankprogramm (beispielsweise ORACLE) und seinem Datenbestand.
Offiziell ist hierfür der Begriff „Datenbanksystem“ zu gebrauchen (der Begriff „Datenbank“
beschreibt hingegen eine Sammlung von inhaltlich zusammenhängenden Daten28).
Ein Datenbanksystem (DBS) besteht aus einer Komponente für die Einrichtung, Verwaltung
und Benutzung einer Datenbank (dem sogenannten „Datenbankmanagementsystem“) sowie
einem dauerhaften Datenbestand.
Die Datenbank umfasst sowohl die eigentlichen Nutzdaten für Anwender des
Anwendung 1 Anwendung 2 Anwendung 3
DBMS
Datenbank
Datenbanksystems, wie auch die Daten zur Verwaltung und Steuerung des Systems.
Das Datenbankmanagementsystem besteht in der Regel aus mehreren Programmen,

welche die Zugriffe (lesen, Ändern, Einfügen und Löschen von Daten) auf die Datenbank
verwalten und durchführen29. Anwendungen können nur über das DBMS auf die Datenbank
zugreifen.
28
Vg. Hald/Nevermann (1995), S. 2
29
Vg. Hald/Nevermann (1995), S. 2
10
Architektur von Datenbanksystemen – Drei-Schichten-Schemaarchitektur30:

1978 wurde von der Untergruppe SPARC31 des amerikanischen Normenausschusses ANSI32
ein Modell veröffentlicht, welches die Zusammenhänge zwischen Anwendungsdaten,
Gesamtdatenbank und der physikalischen Speicherung definiert, und diese drei Ebenen klar
trennt.
Internes
Schema
DATENVISUALISIERUNG
konzeptuelles
Schema
ANFRAGEBEARBEITUNG
Externe
Schemata
Das interne Schema beschreibt die Ebene der physischen Datenorganisation, also die
Anordnung der Daten auf peripheren Speichern und die Zugriffspfadgestaltung33.
Im Laufe Zeit hat sich herausgestellt, dass sich im Interesse wartungsärmerer und
konsistenterer Systeme möglichst wenig Anwendungsmodule mit den Details der
physikalischen Speicherung beschäftigen sollten.
Die externen Schemata beschreiben die für verschiedene Anwendungen und/oder

Benutzergruppen relevanten Ausschnitte des konzeptionellen Schemas34.
30
Vgl. hierzu und im folgenden: Vossen 1994, S. 24 – 26
31
Standards Planning and Requirements Comitee (SPARC)
32
American Standards Comitee on Computers and Information Processing, www.ansi.org
33
Vgl. Hansen (1996), S. 954
11
Aus deren Sicht ist eine möglichst abstrakte, problemorientierte (d.h. auf ihre Erfordernisse
möglichst gut angepasste) Sicht der Daten wünschenswert – also letztlich verschiedene
Sichten auf meist identische Daten.
Beispielsweise erwartet ein Student von dem Informationssystem seiner
Universitätsbibliothek eine bequeme, menübasierte Suche nach unterschiedlichen Kriterien
(wie z.B. Schlagwort, Titel, Autor), während ihn andere Informationen gar nicht interessieren,
und ihm sogar der Zugriff auf diese verweigert wird (z.B. die Information, wer sich gerade ein
bestimmtes Buch ausgeliehen hat).
Da nach außen hin beliebig viele externe Schemata (auch „Views“ genannt) zur Verfügung
gestellt werden können, lässt sich eine Datenbank beliebigen Erfordernissen anpassen.
Folglich benötigt man eine Zwischenschicht, in welcher die Beschaffenheit der gesamten
Daten beschrieben wird, sowie eine Beschreibung, wie sich die einzelnen Benutzersichten
aus dem Gesamtmodell ableiten.
Das sogenannte konzeptuelle Schema beschreibt die Gesamtstruktur und
Integritätsbedingungen; also die vollständige Datenbank, befreit von den
Speicherungsdetails der physischen Sicht auf einer abstrakten, system- und
modellunabhängigen Ebene35.
In Erweiterung der Drei-Schichten-Architektur hat sich die Einführung einer weiteren Ebene
bewährt – der logische Ebene. Sie umfasst die Implementierung des auf der konzeptionellen
Ebene definierten abstrakten Modells für ein bestimmtes Datenbanksystem; sie ist also
datenbankabhängig. Grundlage für die Implementierung bildet hierbei die DDL des jeweiligen
Datenbanksystems36.
Der Vorteile der Drei-Schichten-Schemaarchitektur liegt in der erreichten

Datenunabhängigkeit. Das bedeutet, auf einer Ebene Änderungen vornehmen zu können,
ohne das auf anderen Ebenen ebenfalls tun zu müssen.
Bspw. sind so Anwendungen vor Änderungen des internen Schemas (z.B. bei Tuning-
Maßnahmen) geschützt. Auch sind Anwendungen vor Änderungen des konzeptionellen
Schemas (z.B. bei Erweiterungen einer Datenbank) nicht betroffen.
34
Vgl. Hansen (1996), S. 953
35
Vgl. Hald/ Nevermann (1995), S. 5 ff.
36
Vgl. Hald/Nevermann (1995), S. 6.
Der Vollständigkeit halber muss allerdings gesagt werden, dass die logische Ebene und damit der
logischer Entwurf durchaus unterschiedlich definiert werden.
Während Hald/Nevermann unter der logischen Ebene die datenbankabhängige Implementierung
des abstrakten, konzeptionellen Modells für ein bestimmtes DBS verstehen, fassen andere Autoren
(wie z.B. Heuer/Saake) die logische Ebene als "idealisierte" Form des DB-Modells des Zielsystems
auf.) Das heißt, dass die logische Ebene Modellierungskonzepte des Zielsystems enthält, aber auf
systemspezifische Feinheiten verzichtet. Also wäre ein logisches Modell nach Heuer/Saake
beispielsweise ein relationales Modell, welches allerdings nicht auf ein spezielles RDBMS (wie z.B.
ORACLE) angepasst ist. Die Anpassung auf ein spezielles RDBMS muss gesondert erfolgen, und
bietet den Vorteil, dass ein so erstellter logischer Entwurf für verschiedene Systeme verwendet
werden kann.
12
Zum Begriff der relationalen Datenbanken

Relationale Datenbanken sind Datenbanken, deren Datenbankschema37 auf dem
mathematischen Modell der Relation aufbaut.
Eine „Relation“ bezeichnet in der Mathematik eine Beziehung zwischen Mengen. Relationale
Datenbanken sind demzufolge Datenbanken, die den gewünschten Teilausschnitt aus der
Realität als untereinander in Beziehungen stehende Mengen/Objekte abbilden.
E. F. Codd übertrug diese Relationen und ihre in der Mathematik verankerten Operationen
auf die Informatik, und schuf damit die Idee der relationalen Datenbanken38.
Mathematisch ist eine Relation eine Teilmenge eines kartesischen Produkts aus den
Domänen von n Attributen39.
R ⊆ D1 x … x Dn
Eine Domäne (oder Wertebereich) ist eine Menge der verschiedenen Ausprägungen, die ein
Attribut annehmen kann
kartesisches
Produkt
Domänen Dozent#, Name Relation
Dozent# Name 001, Hermes Dozent#, Name
002, Hermes
001
002 X
Hermes
Winand = 003, Hermes
⊇ 001, Hermes
002, Winand
003 Link 001, Winand 003, Link
002, Winand
usw. …
Praktisch kann man sich eine Relation als Tabelle vorstellen, welche folgende Bedingungen
erfüllt40:
1. Die Tabelle hat eine fest definierte Anzahl von Spalten. Die Reihenfolge der Spalten liegt fest.
2. Jede Spalte hat einen eindeutigen Namen und einen festliegenden Typ.
3. Die Tabelle besitzt beliebig viele Zeilen. Jede Zeile hält sich in Aufbau und Inhalt an die
Spaltendefinition. Insbesondere ist jeder Spaltenwert einer Zelle elementar, d.h. genau ein
Wert des Spaltentyps.
4. Keine Zeile tritt doppelt auf.
5. Die Reihenfolge der Zeilen ist unerheblich für die Operationen in der Tabelle.
37
Ein Datenbankschema ist eine Beschreibung des strukturellen Aufbaus einer Datenbank.
38
Codd, E.: „A relational Modell for large shared data banks“. In: Communications of the ACM, Band
13, Nr. 6, S. 377-387, Juni 1970
39
Vgl. hierzu Hald / Nevermann (1995) S. 25-27
40
Vgl. hierzu Roeing (1996) S. 63
13
Die erste Zeile gibt jeweils die Struktur einer Tabelle an, das sogenannte Relationenschema.
Attribute
Relationenschema
Dozenten_Nr Name_Dozent Fachgebiet Gehalt_Monat
(Tabellenstruktur)
11545211 Vahrenkamp 04 9.000,00 DM
12145123 Hünerberg, Reinhard 03 9.000,00 DM Relation
12345678 Link, Jörg 02 9.000,00 DM (Sämtliche
15595225 Winand, Udo 07 9.000,00 DM Tupel Tabelleneinträg
23115566 Hellstern, Michael 01 9.000,00 DM
23222212 Mack, Eduard 06 9.000,00 DM
Eine einzelne Zeile der Tabelle nennt man Tupel.

Die Eigenschaften einer Entität nennt man Attribut.
Anforderungen an ein relationales Datenbanksystem

Edgar F. Codd formulierte allgemeine Regeln, welche relationale DBMS erfüllen müssen41:
1. Ein RDBMS muss Datenbanken allein durch seine relationalen Fähigkeiten vollständig
verwalten können.
Das heißt, das alle Daten (auch die reinen Verwaltungsdaten) mit relationalen
Operationen veraltet werden können.
2. Alle Informationen ausschließlich auf der logischen Ebene dargestellt, und zwar als
Werte in Tabellen.
3. Jedes einzelne Datenelement muss garantiert durch eine Kombination aus
Tabellennamen, Primärschlüssel und Attributnamen logischzugänglich sein.
4. Ein RDBMS muss eine umfassende Datenbanksprache unterstützen. Für RDBMS hat
sich die Sprache SQL42 durchgesetzt.
5. Anwendungssysteme müssen bei Änderungen in der physikalischen Datendarstellung
der den Zugriffsmethoden logisch unbeeinträchtigt bleiben (physische
Datenunabhängigkeit).
6. Anwendungssysteme müssen logisch unbeeinträchtigt bleiben, wenn Änderungen der
Basistabellen den logischen Informationsgehalt theoretisch unangetastet lassen (logische
Datenunabhängigkeit).
7. Ein RDBMS ist unabhängig gegenüber der Verteilung der Datenbestände.
8. Zugriffe auf die Datenbestände dürfen ausschließlich über das RDBMS erfolgen, selbst
wenn das System andere, systemnähere Sprachen unterstützt.
41
Vgl. hierzu Hald/Nevermann (1995), S. 68-71.
Aus Gründen der Anschaulichkeit wurden einige Regeln weggelassen. Regeln wie Konsistenz etc.,
welche jedes (also auch jedes nicht-relationale) DBS erfüllen muss, wurden von Codd nicht
gesondert erwähnt.
42
"Structured Query Language"; die durch die ISO genormte wichtigste relationale Abfrage- und
Manipulationssprache
14
Der Entwurfsprozess – Design einer relationalen Datenbank

Der Datenbankentwurf modelliert eine gegebene Realwelt bzw. einen Ausschnitt daraus43,
mit dem Ziel der Erstellung eines konzeptionellen Schemas.
„Die Aufgabe des Datenbankentwurfs ist der Entwurf der logischen und physischen Struktur
einer Datenbank so, dass die Informationsbedürfnisse der Benutzer in einer Organisation für
bestimmte Anwendungen adäquat befriedigt werden können.“44
Also müssen die relevanten Daten der realen Welt in einer EDV-technischen Datenbasis
bereitgestellt und verwaltet werden.
Anforderungen an einen systematischen Entwurfsprozess

Aufgrund der Komplexität der Aufgabenstellung ist ein systematischer Entwurfsprozess
unumgänglich. An ihn ergeben sich folgende Anforderungen:45
• Die Tabellen sollten alle benötigten Informationen aufnehmen können (Vollständigkeit)
• Aufgabenadäquanz: Das DBS sollte den gestellten Aufgabenanforderungen entsprechen.
• Beispielsweise darf es nicht sein, dass es die zwei Objekte „Kunde“ und „Auftraggeber“
gibt, wenn doch ein und dasselbe Objekt gemeint ist.
• Der Datenbankentwurf ist gut zu dokumentieren, und die zur Dokumentation verwendete
Sprache ist präzise zu definieren, so dass sich ein Datenbanktechnisch bewanderter
Mensch in einer angemessenen Zeit einen Durchblick verschaffen kann.
• Der Entwurf sollte leicht erweiterbar, modularisiert und wiederverwertbar sein.
• Das Modell sollte homonymfrei sein, d.h. es sollte keine Mehrfachverwendungen
aufweisen. Dies wäre z.B. der Fall, wenn von „Personen“ gesprochen wird, obwohl es
sich in Wirklichkeit um „Kunden“ oder „Mitarbeiter“ handelt.
Zur bestmöglichen Erfüllung dieser Anforderungen hat sich die Ausrichtung an dem
Phasenmodell des Datenbankentwurfs als praktikabel erwiesen.
Da das Phasenmodell des Datenbankentwurfs stark an das Phasenmodell des Software-
Engineerings46 angelehnt ist (schließlich ist das „Datenbank-Engineering“ auch eine Form
des Software-Engineering), wird dieses kurz vorgestellt:
43
Vgl. hierzu und im folgenden: Vossen (1994) S. 48 – 52 sowie Heuer (1995) S. 133 ff.
44
Vossen (1994), S. 45
45
46
Software-Engineering ist die von Grund auf systematische Softwareentwicklung (vgl. Hasen 1996,
S. 859)
15
Phasenmodell („Wasserfallmodell“) des Software-Engineerings47
Planung
Definition
Entwurf
Implementierung
Am Anfang steht die Planung eines Projekts, bei dem es hauptsächlich um die Entscheidung
geht, ob das Projekt überhaupt durchgeführt werden sollte. Dementsprechend sind innerhalb
dieser Phase eine Durchführbarkeitsstudie und eine Kosten-/Nutzen-Analyse notwendig.
Als Ergebnis dieser Phase wird eine Projektentscheidung (ja oder nein) gefällt, und ein
grober Projektrahmen gesteckt.
Bei der Definition werden die fachlichen Anforderungen analysiert und möglichst genau
festgelegt. Das Ergebnis, das fachliche Pflichtenheft, ist die Grundlage für den technischen
Entwurf der Lösung.
Der Entwurf legt die technische Problemlösung grundlegend fest.
Die Implementierung überführt das technische Modell in eine lauffähige Lösung, beinhaltet
also das Programmieren.
Anmerkung: in unserem Beispiel gehen wir davon aus, dass noch gar nichts
Datenbanktechnisches vorhanden ist, und wir deshalb Schritt für Schritt nach dem
„Wasserfallmodell“ vorgehen mussten.
In der Praxis kommt es allerdings häufig vor, dass ein bereits vorhandenes
Datenbanksystem einem Redesign unterzogen werden soll. Häufig ist die Dokumentation
unzureichend oder gar überhaupt nicht vorhanden, so dass nichts anderes übrig bleibt, als
von dem vorhandenen System auf den logischen Aufbau und Zusammenhang der Daten zu
schließen.
Diese Vorgehensweise wird „Reverse Engineering“ genannt48.
Dabei lässt man sein CASE-Tool das jeweiliges Datenbanksystem untersuchen.
Aus dem daraus entstehenden technischen Modell lässt sich dann leicht (meist mit dem
selben Tool) ein konzeptionelles Modell erstellen.
47
Vgl. Roeing (1996), S. 9-10. Dies stellt allerdings eine stark vereinfachte Version des Wasserfall-
Modells dar. Für eine ausführliche Schilderung siehe Hansen (1996), S. 138-140.
48
16
Die Phasen des Datenbankentwurfs49

Analog zu dem Modell des Software-Engineerings lässt sich auch der Datenbankentwurf in
verschiedene Phasen aufteilen.
Fachproblem
Anforderungsanalyse
Informationsanalyse Funktionsanalyse
Konzeptioneller Entwurf
Sichtenentwurf
Obwohl dieses
„Wasserfallmodell“ in
Sichtenanalyse
mancher Hinsicht
50
kritisiert wird , ist es
doch für die
Sichtenintegration
Entwicklung
Konzeptionelles Gesamtschema relationaler
Datenbanken sehr gut
(wenn nicht am besten
geeignet), und ist
Verteilungsentwurf darüber hinaus leicht
nachzuvollziehen.
Logischer Entwurf
Datendefinition
Physischer Entwurf
Implementierung & Wartung
49
Vgl. hierzu und im Folgenden: Schürr, Andy: „Datenbanken I“, S. 75 – 83
50
Vgl. Roeing (1996) S. 11
17
Phase 1: Die Anforderungsanalyse51

In dieser Phase werden die Anforderungen an die zu realisierende Datenbank gesammelt
und analysiert; nämlich die Anforderungen aller potentiellen Benutzer, welche Aufschluss
darüber geben, welche Daten aus fachlicher Sicht notwendig sind (also über was Daten
gespeichert werden sollen), und wie diese Daten gespeichert werden sollen.
Beispielsweise gehört in der Realität zu einem Kunden eine fast unendlich große Anzahl von
Daten, welche aber größtenteils irrelevant sein dürfen (z.B. die Haarfarbe). Aber auch hier
muss Fallweise entschieden werden.
Die Durchführung dieser ersten Phase gestaltet sich in Interviews mit Vertretern der
einzelnen Benutzergruppen. Das Ergebnis sind textuelle oder tabellarische Beschreibungen
des Fachproblems.
Wir unterscheiden zwei Arten von Anforderungen:
1. Informationsanforderungen
Diese spezifizieren alle Informationen, welche das betreffende DBS im späteren Betrieb
verwalten soll; also z.B. Angaben über Realweltobjekte und deren Typen, Attribute und
deren Wertebereiche, Beziehungen, sowie allgemeine Integritätsbedingungen, über
welche die Konsistenz einer DB definiert wird.
2. Bearbeitungsanforderungen
Diese spezifizieren alle dynamischen Aktivitäten, welche später auf dem DBS ablaufen
sollen (also bspw. Anfragen, Updates, Auswertungen). Aus Informationen über
Datenvolumen und Häufigkeit der einzelnen Prozesse ergeben sich
Performanceanforderungen an das zukünftige System.
Phase 2: Konzeptioneller (fachlicher) Entwurf

Basierend auf den Ergebnissen der Anforderungsanalyse ist die Aufgabe des
konzeptionellen Entwurfs die erste formale Beschreibung des Fachproblems und der im
Anwendungsbereich benötigten Informationsstrukturen. Dies erfolgt mit einem sog.
konzeptionellen Datenmodell (in aller Regel mit einem Entity-Relationship-Diagramm52). Das
konzeptionelle Datenmodell soll ein fachlich korrektes, eingeschränktes Modell der
Wirklichkeit sein. Dieses Modell beschreibt Objekte und deren Beziehungen untereinander.
Das fachliche Modell sollte lediglich eine Beschreibung der abzubildenden „Miniwelt“
darstellen und unabhängig von Systemüberlegungen, also zielsystemunabhängig sein53.
Die Zielsystemunabhängigkeit ist deshalb wichtig, um nicht bereits in dieser frühen Phase
des Entwurf auf möglicherweise bestehende Einschränkungen oder spezielle Eigenschaften
des zu benutzenden Systems Rücksicht nehmen zu müssen (unbestritten sinnvoll ist es, erst
seine Ansprüche zu definieren, und dann nach dem geeigneten DBMS Ausschau zu halten).
51
Vgl. hierzu Heuer (1995) S. 136 und S. 137-138
52
Zur Entity-Relationship-Darstellungsmethode vergleiche Chen/Knöll (1991) S. 37 ff.
53
Vgl. Chen/Knöll (1991), S. 25
18
Ein weiterer Vorteil ist, dass dieses konzeptionelle Schema für Nicht-EDV-Fachleute leichter
zu verstehen ist als ein systemspezifisches Modell. Außerdem kann dieses auch bei einem
Wechsel des Systems beibehalten werden54.
Einzelsicht- oder Globalsichtorientiert ?

Bezüglich der weiteren Vorgehensweise gibt es zwei Möglichkeiten; die zentralisierte
(globalsichtorientierte), und die dezentralisierte (einzelsichtorientiert).
Bei der zentralisierten (globalsichtorientierten) Vorgehensweise modelliert man zunächst die
Gesamtsicht (das konzeptionelle Schema), und leitet daraus anschließend die externen
Schemata ab.
Bei der dezentralisierten (einzelsichtorientierten) Vorgehensweise hingegen modelliert man
erst die externen Schemata (ausgehend von den Informationsanforderungen der einzelnen
Benutzer bzw. Benutzergruppen), und setzt diese dann zu der konzeptionelle Gesamtsicht
zusammen. Diese Integration der vorher Entworfenen Einzelsichten wird auch „View
Integration“ oder „Schema Merging“ genannt.
Phase 3: Der Verteilungsentwurf

Soll die Datenbankanwendung verteilt realisiert werden, kann die Verteilung der Daten
entworfen werden, bevor konkrete Systeme ausgewählt werden. Da dies bei uns aus
Gründen der besseren Veranschaulichung nicht der Fall sein soll, wird diese Phase in der
praktischen Ausführung einfach ausgelassen.
Phase 3b: DBMS-Auswahl

Falls nicht schon von vornherein das zu verwendende DBMS feststeht55, sollte jetzt die
Entscheidung für ein bestimmtes System fallen, da alle weiteren Phasen hierauf Bezug
nehmen.
Auswahlkriterien können sein:
• Vorhandene Hard- und Software, insbesondere das vorhandene Betriebssystem
• Eventuell notwendige Unterstützung mehrerer Plattformen
• Benötigte Schnittstellen
• Benchmarkergebnisse56 vergleichbarer Systeme
• der Preis
• das schon vorhandene IT-Umfeld
54
Vgl. Chen/Knöll (1991) S. 25-26
55
Die von vornherein gegebene Festlegung auf ein bestimmtes System stellt natürlich eine große
Einschränkung der Flexibilität des Entwurfsprozesses dar. Sie ist allerdings nicht unwahrscheinlich;
bspw. könnte ein schon vorhandenes IT-Umfeld den Einsatz eines bestimmten Systems erzwingen.
56
Ein Benchmark ist eine Vergleichsmessung mithilfe standardisierter Hard- oder Software (vgl.
Hansen 1996, S. 44 f.
19
Phase 4: Logischer Entwurf57

In dieser Phase erfolgt eine Umsetzung oder Transformation des aus der dritten Phase
resultierenden konzeptionellen Schemas in das Datenmodell des zu verwendenden DBMS.
Das logische Datenmodell ist eine idealisierte Form des Datenbankmodells des
Realisierungs-Systems. Idealisiert deshalb, weil man auf gewisse systemspezifische
Feinheiten verzichtet, sich aber trotzdem auf die Modellierungskonzepte des Zielsystems
beschränkt. Der logische Entwurf ist also noch systemunabhängig
Meist liegt das konzeptionelle Schema als ER-Diagramm vor, und das betreffende DBMS
basiert auf dem relationalen Datenmodell. Dann ist das Ergebnis ein relationales
Datenbankschema58.
Anschließend wird das resultierende Schema (in unserem Fall also eine Sammlung von
Relationen) anhand unterschiedlicher Qualitätskriterien optimiert59. Dieser Schritt wird im
Relationenmodell als „Normalisierung“ bezeichnet60.
„Zusammengefasst bedeutet dies, dass sich der logische Datenbankentwurf mit der
Organisation der Daten beschäftigt, um sie in eine Form zu bringen, die für das vorgesehene
Datenbanksystem akzeptabel ist.“61
Phase 5: Datendefinition
Der logische Entwurf war noch systemunabhängig – in der Datendefinitionsphase hingegen
wird die Schemadefinition für ein konkretes DBMS vorgenommen.
Dies geschieht unter Verwendung der Datendefinitions- und Datenmanipulationssprache
eines konkreten DBMS62. Ebenfalls erfolgt die Definition der Benutzersichten (als Umsetzung
der in der Phase des konzeptionellen Entwurfs gewonnenen Anwendungssichten).
Das Ergebnis der Datendefinitionsphase ist ein konkretes Datenbankschema für ein
implementiertes DBMS63.
57
Vgl. zum logischen Entwurf Heuer (1995) S. 142
58
Diese Transformation erfolgt heutzutage meist automatisch, durch die Unterstützung
entsprechender Software.
59
Wobei durchaus verschiedene Optimierungsziele miteinander konkurrieren können, etwas
redundanzfreie Speicherung durch Aufteilung mehrerer Relationen versus schnellerer Zugriff
60
Der besseren Übersichtlichkeit wegen gehe auf die Normalisierung erst im Praxisabschnitt ein, da
zur Veranschaulichung der Normalisierungstechniken ein Praxisbeispiel sehr nützlich ist
61
Chen/Knöll (1991), S.20
62
Dies ist notwendig, da sich die einzelnen Systeme in den unterstützten Sprachmitteln
unterscheiden. Selbst der von allen Systemen unterstützte Standard SQL stellt gewissermaßen nur
eine gemeinsame Teilsprache dar.
63
Allerdings ist – wie bereits erwähnt – diese Phase bei einigen Autoren schon im logischen Entwurf
integriert.
20
Phase 6: Physischer Entwurf64

Der physische Entwurf ist die Auswahl einer physischen Datenstruktur für eine gegebene
logische Datenstruktur65 – also die Definition der internen Ebene. Hierfür wird eine
Speicherstruktursprache (SSL; storage structure language) eingesetzt, welche die Angabe
konkreter Speicherungsstrukturen ermöglicht. Beispielsweise wird angegeben, ob eine
Relation in einer Baumstruktur oder mittels einer Hash-Tabelle66 gespeichert wird; und
welche Attribute typische Selektionskriterien in Anfragen sind, für die darum ein zusätzlicher
Suchindex angelegt wird.
Das Ergebnis des physischen Entwurfs ist das sogenannte physische oder interne Schema.
Diese Phase ist nicht Gegenstand dieser Arbeit, weil dies für eine einführende Schrift zu weit
führen würde.
Phase 7: Implementierung + Wartung67

Neben der tatsächlichen Installation der Datenbankanwendung rechnet man dieser Phase
die Wartung und die fortlaufende Anpassung an neue Anforderungen zu. Dies kann ein
Wechsel der Systemplattformen sein, aber auch weitere Optimierungsarbeiten.
Ebenfalls in diese Phase fällt das optionale “Prototyping“. Darunter versteht man das Laden
einer Beispieldatenbank mit einem Test-Datenbestand zum Zwecke der
Entwurfsverifikation68. Die damit erfolgenden Performancemessungen ermöglichen es, vor
dem Laden der eigentlichen DB Aussagen darüber zu erhalten, ob die
Effizienzanforderungen an die DB gehalten werden können, um dann noch ggf. Änderungen
am Entwurf vornehmen zu können. Aufgrund hoher Wartungskosten muss schon in der
Entwurfsphase die leichte Modifizierbarkeit und damit Wartbarkeit des Systems angestrebt
werden.
Ich werde in meinen Ausführungen lediglich auf die Implementierung eingehen, da sich die
Wartung nur schwer in einer einführenden Schrift beschreiben läßt.
64
Vgl. hierzu und im Folgenden Heuer/Saake (1995), S. 143
65
Vgl. Chen/Knöll (1991), S. 18
66
Für nähere Informationen zum Hash-Verfahren siehe Hansen (1996), S. 937 ff.
67
Vgl. hierzu und im Folgenden Heuer/Saake (1995), S. 144
68
Im allgemeinen versteht man unter Prototyping Verfahren zur Entwicklung von Prototypen, vgl.
Hansen (1996), S. 138
21
Das Praxisbeispiel – die Handelshochschule Kassel

Zum Zwecke der besseren Verständlichkeit darf ein praktisches Beispiel natürlich nicht
fehlen69.
Und zwar gehen wir davon aus, dass in Kassel eine private Wirtschaftshochschule
gegründet werden soll: Die „Handelshochschule Kassel“ (im folgenden nur „HHK“ genannt).
Offensichtlich ist die Notwendigkeit, dass schon vor der „Inbetriebnahme“ eine
leistungsfähige EDV-Infrastruktur vorhanden sein muss. Ebenfalls ist allen Beteiligten klar,
welche wichtige Rolle eine integrierte70 Datenhaltung in größeren Softwaresystemen nimmt;
demzufolge kommt dem Entwurf der Datenbank eine besondere Bedeutung zu71.
Phase 1 – Die Anforderungsanalyse

Aufgabe der Anforderungsanalyse ist es, die durch Gespräche mit den zukünftigen
Anwendern gewonnenen Informationen in einem strukturierten Dokument festzuhalten72.
Mögliche Vorgehensweise:
1. Identifikation der Organisationseinheiten
2. Identifikation der zu unterstützenden Aufgaben
3. Anforderungs-Sammelplan: Ermittlung der zu befragenden Personen
4. Anforderungs-Sammlung
5. Satzklassifikationen: Gesammelte Informationen werden Objekten, Beziehungen
zwischen Objekten, Operationen und Ereignissen zugeordnet
6. Formalisierung / Systematisierung: Erstellen der Anforderungsspezifikation
(„Pflichtenheft“)
Die Schritte 1-2 dienen der Abgrenzung des Anwendungsbereichs; die Schritte 3-5 dienen
der systematischen Sammlung von Informationen über den abgegrenzte
Anwendungsbereich. Schritt 6 dient dazu, die erarbeiteten Ergebnisse so gut zu
dokumentieren, dass sie ggf. auch von Externen verstanden werden können. Dies empfiehlt
auch dann, wenn der Auftrag zur Realisierung nicht an Externe vergeben wird.
Bestandteile dieser Beschreibung sind:
• Objekte, welche zu Objekttypen (Entitäten) abstrahiert werden sollten
• Attribute, welche diese Objekte beschreiben bzw. identifizieren
• Beziehungen zwischen den Objekten
Die in der Anforderungsanalyse ermittelten Abschätzungen hinsichtlich Anzahl und Größe

der Objekte dienen dazu, schon frühzeitig das anfallende Datenvolumen abzuschätzen.
69
Mein Beispiel ist angelehnt an die Beispiele von Heuer (1995), S. 21-22, und Kemper 1996, S. 53 ff.
70
Integriert im Sinne von „frei von Integritätsverletzungen“
71
Vgl. hierzu Heuer (1995), S. 133
72
Vgl. hierzu und im Folgenden: Kemper (1996), S. 31-34
22
Zu abstrahierende Objekte:
Die Anforderungsanalyse arbeitet folgende Objekte heraus, die zu abstrahieren sind:
• Studenten, welche die Lehrveranstaltungen besuchen, und von den Dozenten geprüft
werden;
• Dozenten, welche die Lehrveranstaltungen halten, Forschung betreiben und die
Studenten prüfen;
• Assistenten, welche die Mitarbeiter der Dozenten sind und diese bei der Forschung
unterstützen;
• Mitarbeiter, welche die aufkommenden Verwaltungsarbeiten an der Hochschule
übernehmen;
• Bibliotheksnutzer, welche die vorhandene Literatur entleihen, und auch Hochschul-
Externe sein können.
An einer Hochschule wird man jedoch nicht nur Personen, sondern auch abstrakte, nicht-
fassbare Objekte (wie z.B. Vorlesungen) vorfinden.
Damit erweitert sich unsere Liste der zu verarbeitenden Objekte um:
• Lehrveranstaltungen, welche von Dozenten gehalten, und von Studenten besucht
werden;
• Fachgebiete, welche die an der Hochschule vertretenen verschiedenen Fachrichtungen
(wie z.B. Marketing oder Wirtschaftsinformatik) kennzeichnen;
• Lehrbücher als Sammelbegriff für die wissenschaftliche Literatur;
Eigenschaften (Attribute) der Objekte:

Ferner ist es notwendig, alle zu den einzelnen Objekten zu erfassenden Informationen
festzuhalten:
• Objekt Student: Matrikelnummer, Name, Studienbeginn, Adresse, Geburtsdatum,
Emailadresse
• Objekt Dozent: Dozentennummer, Name, Adresse, Geburtsdatum, Fachgebiet,
Monatsgehalt, Emailadresse
• Objekt Assistent: Assistentennummer, Name, Arbeitgeber, Geburtsdatum, Adresse,
Monatsgehalt, Emailadresse
• Objekt Mitarbeiter: Mitarbeiternummer, Name, Arbeitsgebiet, Emailadresse
• Objekt Lehrveranstaltungen: Lehrveranstaltungsnummer, Lehrveranstaltungstitel,
Lehrveranstaltungsart (Vorlesung oder Seminar), Semesterwochenstundenzahl,
• Objekt Fachgebiete: Fachgebietsnummer, Bezeichnung
• Objekt Lehrbücher: Titel, Autor, ISBN, Erscheinungsjahr, Verfügbarkeit
• Objekt Bibliotheksnutzer: Nutzer-Nummer, Name, Adresse, Status (interner oder
externer Nutzer)
23
Beziehungen der Objekte:

Die genannten Objekte stehen miteinander in Beziehungen, welche ebenfalls in der DB
verwaltet werden sollen:
• Die Studenten besuchen bestimmte Lehrveranstaltungen, und werden von Dozenten
geprüft
• Die Dozenten halten bestimmte Lehrveranstaltungen, prüfen bestimmte Studenten und
vergeben Noten; zudem empfehlen sie für bestimmte Lehrveranstaltungen gewisse
Lehrbücher. Dozenten sind außerdem Mitglieder von Fachgebieten.
• Die Assistenten sind bei den Dozenten beschäftigt.
• Jedes Fachgebiet beschäftigt immer genau einen Mitarbeiter. Allerdings ist nicht jeder
Mitarbeiter auch automatisch genau einem Fachgebiet zugeordnet (bspw. gibt es
Mitarbeiter, welche sich um allgemeine Verwaltungsaufgaben kümmern).
Ebenfalls sollten in dieser Phase die einzelnen Rechte und Beschränkungen der jeweiligen
Zielgruppen textuell oder tabellarisch festgehalten werden, um so später die Sichten
definieren zu können73.
Für unser Universitätsbeispiel könnten dies folgende Sichten sein:
• Dozentensicht
• Studentensicht
• Sicht der Verwaltungsmitarbeiter
Anmerkung: Obwohl in der Praxis in der Regel der durchgängige Einsatz eines CASE-
Tools74 erfolgt, erledige ich aus Gründen der besseren Veranschaulichung möglichst vieles
manuell.
73
Vgl. hierzu Kemper 1996, S. 48 – 49
74
CASE = Computer Aided Software Engineering (siehe Hansen 1996, S. 859-861)
24
Phase 2: Der konzeptionelle Entwurf
Grundlagen des Entity-Relationship-Modells75:

Grundlegendste Modellierungsstrukturen dieses Ansatzes sind die Entities (Gegenstände
oder Objekte) und die Relationships (Beziehungen) zwischen den Entities. Gegenstände und
deren Beziehungen werden durch Attribute beschrieben.
Gegenstände sind „wohlunterscheidbare physisch oder gedanklich existierende Konzepte
der zu modellierenden Welt“76. Man abstrahiert ähnliche Gegenstände zu Gegenstandstypen
(Entitytypen oder Entitymengen), die man graphisch als Rechtecke darstellt, wobei der Name
des Entitytyps innerhalb des Rechtecks angegeben wird.
Beziehungen werden auf analoge Weise zu Beziehungstypen zwischen den
Gegenstandstypen abstrahiert. Die Beziehungstypen werden als Rauten mit entsprechender
Beschriftung gezeichnet. Attribute charakterisieren Gegenstände bzw. Beziehungen. Sie
werden durch Kreise oder Ovale dargestellt, und den Gegenstandstypen bzw. den
Beziehungstypen zugeordnet.
Beispielhaft erfolgt hier die (vereinfacht dargestellte) Beziehung zwischen Dozenten und
Diplomanden:
Dozent_Nr Matrikel_Nr
Name_Dozent Name_Student
DOZENT betreuen DIPLO MAND
Vornam e_Dozent Vornam e_Student
Email_Dozent Email_Student
Beispielhaftes Entity-Relationship-Modell
Diese von Peter Chen 1976 vorgestellte ursprüngliche Entity-Relationship-Model – Notation77

verliert allerdings bei zunehmender Größe des Modells an Übersichtlichkeit, weswegen viele
75
Vgl. hierzu: Kemper (1996), S. 35 f.
76
Kemper (1996), S. 35
77
Vgl. hierzu: Chen, Peter: "The Entity-Relationship-Model--Toward a Unified View of Data"
(http://www.csc.lsu.edu/~chen/pdf/erd.pdf)
25
modifizierte und veränderte Notationen entwickelt wurden (die jedoch alle auf dem ER-
Diagramm beruhen)78.
Die Unübersichtlichkeit ist darauf zurückzuführen, dass für die Attribute und Beziehungen
eigene Objekte zu zeichnen sind. Nahezu alle modifizierten ER-Notationen begegnen dieser
Schwäche dadurch, dass sie die Attribute in das „Entity-Rechteck“ schreiben, und die
Entitäten direkt miteinander verbinden. Die Kardinalität79 wird anhand der Verbindungslinie
deutlich, und kann bei Bedarf zusätzlich notiert werden.
Modell in der IDEF1X – Notation80:

DO ZENT DIPLOMAND
Dozent_Nr (FK)
Name_Dozent
Vorname_Dozent Name_Student
Email_Dozent Vorname_Student
Email_Student
Modell in der Information Engineering – Notation81:

DO ZENT DIPLOMAND
Dozent_Nr (FK)
Name_Dozent
Vorname_Dozent Name_Student
Email_Dozent Vorname_Student
Email_Student
Da die Information Engineering – Notation (im folgenden kurz IE-Notation genannt) am

verständlichsten ist, entscheide ich mich für diese.
78
Einen ausführlicheren Vergleich der einzelnen Notationen bietet Hay, David: "A COMPARISON OF
DATA MODELING TECHNIQUES", Essential Strategies 1999, http://www.essentialstrategies.com
79
Kardinalität = Anzahl der zugeordneten Entitäten
80
Eine ausführliche Dokumentation der IDEF1X-Notation gibt es von dem National Institute of
Standards and Technology (www.nist.gov); Titel: "INTEGRATION DEFINITION FOR
INFORMATION MODELING (IDEF1X)"; Federal Information Processing Standards Publication 184,
1993; http://www.sdct.itl.nist.gov/~ftp/idef/idef1x.rtf
81
Die Information Engineering – Notation wurde 1970 von James Martin am "IBM Systems Design
Institute" in New York entwickelt. Für weitere Informationen zur IE-Notation bitte
http://www.essentialstrategies.com konsultieren.
Für weitere Einblicke in das Information Engineering selbst siehe Heinrich 1992, S. 259 ff. sowie
Martin, James: „Information Engineering: Introduction“, Prentice Hall 1989
26
Unser konzeptuelles Modell:

Um unser konzeptuelles Modell zu erstellen, modellieren wir einfach alle Objekte als
Rechtecke, und stellen die Beziehungen zwischen ihnen als Verbindungslinien dar.
Dabei bedeuten die Zeichen:
konditionell (0 oder 1)
einfach (genau 1)
multipel (1 oder mehrere)
multipel-konditionell (0 oder mehrere)
• Ein Student kann 0 bis n Lehrveranstaltungen besuchen; 0, wenn er beispielsweise ein

Praktikum absolviert, und n (also mehrere), wenn er normal studiert.
• Eine Lehrveranstaltung kann von mehreren Studenten besucht werden, sie muss aber
von mindestens einem Studenten besucht werden – ansonsten fällt sie aus.
• Ein Dozent kann 0 bis n Lehrveranstaltungen anbieten; 0, wenn er ein
Forschungssemester macht, und n (also mehrere), wenn er seiner Lehrtätigkeit
nachgeht.
• Eine Lehrveranstaltung kann nur von genau einem Dozenten gehalten werden
(Kooperationen lasse ich aus Gründen der Vereinfachung weg).
• Dozenten sind Fachgebieten zugeordnet; ein Dozent gehört zu genau einem Fachgebiet,
während ein Fachgebiet durchaus mehrere Dozenten haben kann.
• Dozenten werden von Assistenten (Hilfswissenschaftlern) unterstützt; ein Dozent kann 0
bis n Assistenten haben, während ein Assistent immer zwingend zu genau einem
Dozenten gehört.
• Auch zwischen Studenten und Dozenten gibt es direkte Beziehungen:
Ein Student kann von einem oder mehreren Dozenten geprüft werden; ein Dozent kann
keinen, einen oder mehrere Studenten prüfen.
• Daneben haben wir noch Universitätsmitarbeiter. Ein Mitarbeiter kann zu einem
Fachgebiet gehören, er kann aber auch für allgemeine Verwaltungsaufgaben eingestellt
worden sein – also zu gar keinem Fachgebiet gehören. Einem Fachgebiet hingegen ist
immer zwingend ein Mitarbeiter zugeordnet sein.
• Dozenten können Bücher empfehlen. Dabei kann ein Dozent mehrere Bücher empfehlen;
auch kann ein Buch von mehreren Dozenten empfohlen werden.
• Wir nehmen an, dass die Verwaltung der Bibliotheksnutzer unabhängig von der
Verwaltung der Studenten, Dozenten und Mitarbeiter ist, da unsere Unibibliothek auch
von anderen Personengruppen (z.B. von den Bürgern der Stadt) genutzt werden kann.
Dabei kann ein Bibliotheksnutzer mehrere Bücher entleihen, und ein bestimmtes Buch
(z.B. „Wirtschaftsinformatik I“) kann von mehreren Nutzern entliehen werden, sofern
mehrere Exemplare dieses Buch existieren.
27
Unser fertiges ER-Diagramm mit den oben beschriebenen Sachverhalten sieht so aus82:
MITARBEITER
STUDENTEN LEHRVERANSTALTUNGEN
Mitarbeiter_Nr
Matrikel_Nr LV_Nr Name_Mitarbeiter
Name LV_Titel Arbeitsgebiet
Studienbeginn LV_Art Gehalt_Monat
Adresse_Student Semesterw ochenstunden eMail
Geburtsdatum
eMail_Student
DOZENTEN
Dozenten_Nr FACHGEBIETE
LEHRBÜCHER
Name
FG_Nr
Titel Adresse
Bezeichnung
Autor Geburtsdatum
ISBN Fachgebiet
Erscheinungsjahr Gehalt_Monat
Verfügbarkeit eMail_Dozent
ASSISTENTEN
Assistent_Nr
BIBLIOTHEKSNUTZER Name_Assistent
Arbeitgeber
Nutzer_Nr
Geburtsdatum
Nutzer_Name
Adresse
Nutzer_Adresse
Gehalt_Monat
Nutzer_Status
eMail_Assistent
82
Das Modell wurde mit Hilfe der Software „Silverrun Relational Data Modeler“ erstellt
(http://www.silverrun.com/products/rdm.html). Prinzipiell kann dies natürlich auch von Hand erfolgen.
28
Phase 3: Der logische / relationale Entwurf

ER-Diagramme können nicht direkt in Datenbanken eingegeben werden83.
Der Grund hierfür ist, dass das konzeptionelle Schema nicht mit dem relationalen Schema
(und seiner typischen Tabellenstruktur) identisch ist. Beispielsweise kann es sein, dass
mehrere Entities (des konzeptionellen Modells) zu einer Tabelle (des relationalen Modells)
zusammengefasst werden (im Falle von 1:1-Beziehungen).
Auch müssen die Beziehungen des konzeptionellen Modells erst in Tabellen bzw. Feldwerte
überführt werden.
Da relationale Datenbanken aus Relationen bestehen, ist es notwendig, ER-Diagramme in

Relationen zu transformieren. Diese Relationen können dann sehr einfach in Tabellen
überführt werden. Anschließend können die Relationen mit Hilfe der
Normalisierungsmethode überprüft werden, um Fehler oder Designschwächen aufzudecken.
Wie im theoretischen Teil bereits erläutert, sollte zu Beginn dieser Phase oder kurz davor die
Auswahl eines bestimmten DBMS erfolgen.
In unserem Beispiel entscheiden wir uns für das System „MySQL84“, weil es auf diversen
Plattformen verfügbar ist, und kostenfrei angeboten wird (und dies ist angesichts der
knappen Mittel, die unserer Hochschule zur Verfügung stehen, nicht unwichtig).
Überführung von Entitäten

Entitäten sind einfach in Relationen zu überführen. Ein Entity-Typ entspricht genau einer
Relation.
Jeder Attributstyp eines Entity-Typs wird zu einer Attributsspalte der Relation85.
STUDENTEN STUDENTEN
Matrikel_Nr PK Matrikel_Nr
Name
Studienbeginn Name_Student
Adresse_Student Studienbeginn
Adresse
Geburtsdatum
G eburtsdatum
eMail_Student
eMail_Student
83
Vgl. hierzu und im folgenden: Roeing (1996), S. 63 ff.
84
Informationen zu MySQL gibt es unter http://www.mysql.com
85
Vgl. Hald/Nevermann (1995), S. 167
29
Überführung von 1:n – Beziehungen86

Welcher Dozent hält welche Lehrveranstaltung ?
Eine grundsätzliche Eigenschaft relationaler Systeme ist, dass Beziehungen über Feldwerte
gespeichert werden. Beziehungen werden also in den Relationen selbst gespeichert, nicht in
einem eigenen Objekt. Diese Relation „trägt“ dann die Beziehung.
Das Prinzip für die Überführung der Beziehungen basiert auf der Tatsache, dass jede
Relation einen Primärschlüssel besitzt. Bei einer 1:n – Beziehung „wandert“ der
Primärschlüssel einer Relation als sogenannter Fremdschlüssel in eine andere Relation. Der
Fremdschlüssel wird in diejenige Relation aufgenommen, deren Maximal-Kardinalität auf der
anderen Seite „1“ ist87.
In unserem Fall wird der Fremdschlüssel in der Relation „LEHRVERANSTALTUNGEN“
aufgenommen, weil eine Lehrveranstaltung von Maximal einem Dozenten gehalten werden
kann.
DOZENTEN DO ZENT LEHRVER ANSTALTUNG
Dozenten_Nr LEHRVERANSTALTUNGEN PK Dozent_Nr
PK LV_Nr
Name
LV_Nr
Adresse Name_Dozent
LV_Titel LV_Titel
Geburtsdatum Adresse LV_Art
LV_Art
Fachgebiet Geburtsdatum FK2 LV_Dozent
Semesterw ochenstunden Fachgebiet
Gehalt_Monat Semesterwochenstunden
Gehalt_Monat
eMail_Dozent
eMail_Dozent
Überführung von 1:c – Beziehungen88

Bei konditionellen Beziehungen wird immer der Schlüssel des Entity als Fremdschlüssel
übernommen, dessen Entity-Set nicht an allen Beziehungen teilnimmt.
In unserem Beispiel wird die Beziehung zwischen Mitarbeitern und Projekten durch die
Übernahme des Schlüssels „Mitarbeiter_Nr“ in die Relation „FACHGEBIETE“ umgesetzt.
MITARBEITER FACHGEBIETE MITARBEITER

FACHGEBIETE
Mitarbeiter_Nr FG_Nr
PK Mitarbeiter_Nr
Name_Mitarbeiter Bezeichnung PK FG _Nr
Arbeitsgebiet
Name_Mitarbeiter
Gehalt_Monat FG _Bezeichnung
Arbeitsgebiet
eMail FK1 Mitarbeiter_Nr
Gehalt_Monat
eMail
86
Vgl. hierzu und im folgenden: Roeing (1996), S. 65 f.
87
Vgl. Hald/Nevermann (1995), S. 171
88
Vgl. hierzu und im folgenden: Hald/Nevermann (1995), S. 169
30
Überführung von n:m – Beziehungen89

1:n – Beziehungen können deshalb in Relationen umgesetzt werden, weil genau ein
Feldinhalt im Fremdschlüssel ausreicht, um die maximale Anzahl von beteiligten Zeilen auf
der anderen Seite zu speichern.
Bei komplexen, also n:m – Beziehungen reicht ein Fremdschlüsselfeld nicht aus.
LEHRVERANSTALTUNGEN
STUDENTEN
LV_Nr
Matrikel_Nr
LV_Titel
Name
LV_Art
Studienbeginn
LV_Dozent
Adresse_Student
Geburtsdatum Semesterwochenstunden
eMail_Student
In unserem Beispiel besteht eine solche Beziehung zwischen STUDENTEN und

LEHRVERANSTALTUNGEN.
Wir benötigen eine Zwischentabelle, um die n:m – Beziehung wird in zwei 1:n – Beziehungen
aufzulösen. Diese Zwischentabelle enthält die Fremdschlüssel der beiden „Muttertabellen“.
STUDENTEN LV_Belegung LEHRVERANSTALTUNG EN
PK Matrikel_Nr PK,FK1 Matrikel_Nr PK LV_Nr

PK,FK2 LV_Nr
Name_Student LV_Titel
Studienbeginn LV_Art
Adresse FK2 LV_Dozent
G eburtsdatum Semesterwochenstunden
eMail_Student
89
Vgl. hierzu und im Folgenden Hald/Nevermann (1995), S. 171-172
31
Phase 3b: Normalisierung

Unter Normalisierung versteht man das Ausrichten von Relationen anhand bestimmter
Qualitätskriterien, den sogenannten Normalformen90.
Die erste Normalform:

„Eine Relation ist in der 1. Normalform, wenn sie nur Attribute mit einfacher
Datenausprägung besitzt, d.h. die Relation nur aus atomaren Attributen besteht.“91
Dies ist bei uns nicht der Fall, da die Tabellen STUDENTEN, MITARBEITER, DOZENTEN,
BIBLIOTHEKSNUTZER und ASSISTENTEN ein Attribut mit doppelter Datenausprägung
besitzen – nämlich das jeweilige Namensfeld.
Unter Berücksichtigung dieser Regel müsste man beispielsweise in der Relation
STUDENTEN das Feld „Name_Student“ durch die Felder „Nachname_Student“ und
„Vorname_Student“ ersetzen. Entsprechend ist mit allen anderen Relationen zu verfahren.
Die zweite Normalform

„Eine Relation ist in der 2. Normalform, wenn sie in der 1. Normalform ist, und alle Attribute
voll funktional von allen Schlüsselattributen abhängen.“92
Das heißt, dass ein Attribut den gesamten Schlüssel zur Identifikation benötigen muss, und
nicht bereits durch einen Teilschlüssel identifiziert werden darf.
Dies ist bei unseren Relationen bereits der Fall.
Die dritte Normalform

„Eine Relation ist in der 3. Normalform, wenn sie in der 2. Normalform ist, und keine transitiv
abhängigen Attribute existieren.“93
Das heißt, dass die Feldwerte nur vom Primärschlüssel abhängig sein dürfen, und
untereinander keine Abhängigkeiten haben dürfen.
Auch das ist bei unseren Relationen schon der Fall. Es wäre beispielsweise nicht der Fall,
wenn z.B. in der Relation LEHRVERANSTALTUNG außer der Dozenten-Nr („LV_Dozent“)
auch der Name und die Anschrift des Dozenten enthalten wären – denn dann wären diese
Attribute nicht vom Primär- sondern vom Fremdschlüssel abhängig. Man könnte in diesem
Fall von dem Fremdschlüssel (der Dozenten-Nr) auf weitere Attribute schließen – und in so
einem Fall sollte man Relation weiter unterteilen.
90
Vgl. hierzu und im Folgenden Kemper (1996), S. 143-149; sowie Hald/Neverman (1995), S. 35-42
91
Hald/Nevermann (1995), S. 37
92
Hald / Nevermann (1995) S. 38
93
Hald / Nevermann (1995) S. 39
32
Phase 4: Datendefinition
Diese Phase umfasst die Definition der Datentypen.
Da eine Behandlung aller von MySQL unterstützen Datentypen hier zu weit führen würde,
folgt hier lediglich eine Auflistung der von mir gewählten Typen94:
CHAR(NUM) Zeichenkette mit genau `NUM` Stellen (1<= NUM <=255).

CHAR(10) ist also eine Zeichenkette mit genau 10 Zeichen.
DATE Datum; Format: YYYY-MM-DD, wobei `-` jedes nicht numerische Zeichen sein
kann
VARCHAR(NUM) Zeichenkette mit maximal `NUM` Stellen (1<= NUM <=255).
VARCHAR(10) ist also eine variable Zeichenkette mit maximal 10 Zeichen.
Die Zuordnung der Attribute zu den ihnen zugewiesenen Datentypen ist der Abbildung der
folgenden Seite zu entnehmen.
Anmerkung:
Ich habe die Primärschlüsselfelder „Matrikel_Nr“, „Dozent_Nr“, „Mitarbeiter_Nr“,
„Assistent_Nr“, „Nuzer_Nr“, „LV_Nr“, „FG_Nr“ und „Inventar_Nr“ deswegen als CHAR-Felder
definiert, weil sich nur so eine zwingend vorgegebene Feldlänge realisieren ließ.
Und da mit diesen Feldern keine Rechenoperationen durchgeführt werden sollen, ist eine
Verwendung von Zeichenfeldern absolut unproblematisch.
94
Für eine Beschreibung aller von MySQL unterstützten Datentypen bitte das MySQL-Manual
konsultieren (http://www.mysql.com/Downloads/Manual/manual.pdf)
33
Das fertige relationale Schema (einschließlich der Datentypen) sieht folgendermaßen aus95:
STUDENTEN LV_Belegung
PK Matrikel_Nr CHAR(8) PK,FK1 Matrikel_Nr CHAR(8)

PK,FK2 LV_Nr CHAR(3) LEHRVERANSTALTUNG EN
Nachname_Student VARCHAR(50) PK LV_Nr CHAR(3)
Vorname_Student VARCHAR(50)
Studienbeginn DATETIME LV_Titel VARCHAR(50)
Adresse VARCHAR(50) LV_Art CHAR(1)
G eburtsdatum DATETIME FK2 LV_Dozent CHAR(8)
eMail_Student VARCHAR(50) SW S CHAR(2)
DO ZENTEN
Prüfungen PK Dozent_Nr CHAR(8)
PK,FK1 Matrikel_Nr CHAR(8) Nachname_Dozent VARCHAR(50) FACHG EBIETE

PK,FK2 LV_Nr CHAR(3) Vorname_Dozent VARCHAR(50)
PK,FK3 Dozent_Nr CHAR(8) Adresse VARCHAR(50) PK FG_Nr CHAR(2)
Geburtsdatum DATETIME
Note CHAR(1) Gehalt_Monat CHAR(6) FG_Bezeichnung VARCHAR(50)
eMail_Dozent VARCHAR(50)
FK2 Fachgebiet CHAR(2)
MITARBEITER
BIBLIO THEKSNUTZER PK Mitarbeiter_Nr CHAR(8)

BUCHEMPFEHLUNG EN
PK,FK1 Dozent_Nr CHAR(8) PK Nutzer_Nr CHAR(8) Nachname_Mitarbeiter VARCHAR(50)

PK,FK2 ISBN VARCHAR(50) Vorname_Mitarbeiter VARCHAR(50)
Nutzer_Nachname VARCHAR(50) Arbeitsgebiet VARCHAR(50)
Titel VARCHAR(70) Nutzer_Vorname VARCHAR(50) Gehalt_Monat CHAR(6)
LV CHAR(3) Nuzer_Adresse VARCHAR(50) eMail_Mitarbeiter VARCHAR(50)
Nutzer_Status CHAR(1)
ASSISTENTEN
LEHRBÜCHER PK Assistent_Nr CHAR(8)
PK ISBN VARCHAR(50) BUCHEXEMPLARE Nachname_Assistent VARCHAR(50)

Vorname_Assistent VARCHAR(50)
Titel VARCHAR(70) PK Inventar_Nr CHAR(4) FK1 Arbeitgeber CHAR(8)
Autor VARCHAR(50) G eburtsdatum DATETIME
Verlag VARCHAR(50) FK5 ISBN VARCHAR(20) Adresse VARCHAR(50)
Erscheinungsjahr CHAR(4) Rückgabe DATETIME Gehalt_Monat CHAR(6)
Verfügbarkeit CHAR(1) FK6 Ausleiher CHAR(8) eMail_Assistent VARCHAR(50)
95
Das Modell wurde erstellt mit einer Demoversion von Microsoft Visio 2000 Professional
(http://www.microsoft.com/office/visio)
34
Da nun die Datentypen festliegen, können jetzt die Tabellen in der DDL unseres Zielsystems
definiert werden96. Beispielhaft sei hier die CREATE TABLE Anweisung für die Tabelle
„STUDENTEN“ aufgezeigt:
CREATE TABLE STUDENTEN (

Matrikel_Nr CHAR(8) NOT NULL,
Nachname_Student VARCHAR(50) NOT NULL,
Vorname_Student VARCHAR(50) NOT NULL,
Studienbeginn DATE NOT NULL,
Adresse VARCHAR (50) NOT NULL,
Geburtsdatum DATE NOT NULL,
eMail_Student VARCHAR (50) NULL,
PRIMARY KEY (Matrikel_Nr)
);
Erläuterung:
Mit „CREATE TABLE“ wird die Tabellendefinition eingeleitet, dahinter folgen die Attribute und
ihre Datentypen. Anschließen wird mit „PRIMARY KEY()“ der Primärschlüssel festgelegt.
NULL bzw. NOT NULL geben an, ob das Feld leer bleiben darf, oder gefüllt werden muss.
Wenn alle Tabellen definiert sind, müssen noch die Beziehungen zwischen den einzelnen
Tabellen hergestellt werden.
Da der Fremdschlüssel in diejenige Relation aufgenommen wird, deren Maximal-Kardinalität
auf der anderen Seite „1“ ist, ergibt sich folgender SQL-Befehl:
ALTER TABLE LV_Belegung

ADD ( FOREIGN KEY (LV_Nr)
REFERENCES LEHRVERANSTALTUNG ),
ADD ( FOREIGN KEY (Matrikel_Nr)

REFERENCES STUDENTEN );
Der Befehl „ALTER TABLE“ verändert eine bereits definierte Tabelle.

„ADD ( FOREIGN KEY (LV_Nr) REFERENCES LEHRVERANSTALTUNG )“ fügt der
ausgewählten Tabelle (in unserem Fall die Tabelle „LV_Belegung“ einen Fremdschlüssel zu
(in unserem Fall der Fremdschlüssel „LV_Nr“), welcher in unserem Fall der Primärschlüssel
der Tabelle „LEHRVERANSTALTUNG“ ist.
96
Selbstverständlich kann die Skriptgenerierung auch automatisch über das jeweilige Tool erfolgen.
Das wurde aber aus Gründen der besseren Veranschaulichung unterlassen.
35
Phase 5: Implementierung
Die fertiggestellten Skripte lassen sich bequem per „copy & paste“ in „MySQL“ einlesen:
... Und wie man sieht, war das Einlesen erfolgreich:
36
Anmerkung: Die Screenshots zeigen lediglich einen Client mit graphischer

Benutzeroberfläche, der mit dem MySQL-Datenbanksystem verbunden ist, nicht aber den
MySQL-Server selbst. Die Auswahl des Clients ist beliebig; ich persönlich habe mich für
„MySQL-Front“ von Ansgar Becker entschieden (www.anse.de).
Prinzipiell könnte man sich auch ohne Client mit graphischer Benutzeroberfläche in den
MySQL-Server einloggen, und die SQL-Befehle beispielsweise über den DOS-Prompt
eingeben – was allerdings viel unkomfortabler wäre.
Schemagenerierung über ODBC

Es gibt noch eine einfachere Methode der Schemagenerierung, die allerdings aus Gründen
der Veranschaulichung weggelassen wurde: Die Schemagenerierung über ODBC.
ODBC (Open Database Connectivity) ist eine von Microsoft definierte Schnittstelle für den
Zugriff auf SQL-Datenbanken.
Da einfach entsprechende Treiber eingesetzt werden können, um eine Anwendung mit dem
jeweiligen DBMS zu verbinden, kann eine einzelne Anwendung (also in unserem Fall ein
CASE-Tool) auf verschiedene Datenbanksysteme zugreifen.
Ein Zugriff von Unbefugten ist nicht möglich, da man beim Anlegen einer ODBC-Datenquelle
das Datenbankkennwort nennen muss97.
Anwendung XXX
ODBC-Treiber
97
Für weitere Informationen zu ODBC siehe www.microsoft.de
37
Definition der Zugriffrechte

Dem Schutz der Daten vor unberechtigten Zugriffen kommt in Datenbanksystemen eine
besondere Bedeutung zu – schließlich werden sie nicht zuletzt aus diesem Grund eingesetzt.
Zugriffe werden durch die Vergabe bzw. das Entziehen von Rechten geregelt98.
Unterscheiden lassen sich dabei
• Datenbankrechte, welche den allgemeinen Zugang zur Datenbank regeln, und
• Tabellenrechte, welche den Zugriff auf die einzelnen Tabellen der Datenbank regeln.
Datenbankrechte
Bei der Definition von Datenbankrechten an Benutzer ist der Benutzername, die
Berechtigungsart, sowie das zu vergebende Passwort (in unserem Fall „XXX“) anzugeben.
GRANT ALL PRIVILEGES TO dari@localhost IDENTIFIED BY 'XXX';
Sollen Datenbankrechte wieder entzogen werden, so erfolgt das mit der REVOKE-
Anweisung:
REVOKE ALL PRIVILEGES FROM dari@localhost;
Tabellenrechte
Ein Datenbankrecht beinhaltet noch keinerlei Zugriffsrechte auf bestimmte Tabellen des
Systems. Die Entsprechende Anweisung dafür:
GRANT SELECT ON STUDENTEN TO dari@localhost;
Anstelle des SELECT-Rechts können auch andere Rechte, wie z.B. ALTER, INSERT oder
DELETE eingeräumt werden.
Das Entziehen von Tabellenrechten erfolgt ähnlich wie bei den Datenbankrechten:
REVOKE SELECT ON STUDENTEN FROM dari@localhost;
98
Vgl. hierzu und im Folgenden: Hald/Nevermann (1995), S. 199 ff.
38
Definition von Sichten

Wie bereits erläutert, kann man mit verschiedenen Sichten (Views) der externen Ebene
unterschiedliche Sichten und damit Zugriffsmöglichkeiten auf Tabellen realisieren99.
Die jeweils definierten Benutzersichten erscheinen dem Anwender bzw. dem AWS wie eine
"normale" Tabelle, auf die bspw. SELECT-Anweisungen angewendet werden können.
Beispielhaft sei hier die Definition einer Studenten Sicht auf die Dozentendaten beschrieben:
CREATE VIEW studentensicht_dozent

AS SELECT Vorname_Dozent, Nachname_Dozent, eMail_Dozent
FROM DOZENTEN;
Leider unterstützt die aktuelle Version von MySQL keine Views, allerdings ist die
Unterstützung für kommende Versionen geplant100, weswegen wir für unser Praxisbeispiel
davon ausgehen, dass der Hochschule bereits eine Version vorlag, die Views unterstützte.
Sichten & Datenschutz

Die Zugriffssteuerung durch Sichten funktioniert deshalb, weil sich Objektprivilegien nicht nur
für Tabellen, sondern auch für Sichten vergeben lassen101.
Darf ein bestimmter Benutzer nur bestimmte Felder einer Tabelle sehen, so erstellt man eine
Sicht über diese Spalten (wie oben mit der Studentensicht auf die Tabelle DOZENTEN
gezeigt), und erteilt diesem Benutzer die entsprechenden Rechte auf die Sicht – und nicht
auf die eigentliche Tabelle.
In unserem Beispiel sehe ein Abfragerecht auf die Studentensicht folgendermaßen aus:
GRANT SELECT ON studentensicht_dozent TO student@localhost;
99
Vgl. hierzu Hald/Nevermann (1995), S. 203 f.
100
Siehe hierzu das entsprechende Kapitel im MySQL-Manual
(http://www.mysql.com/doc/M/i/Missing_Views.html)
101
Vgl. hierzu und im Folgenden: Roeing (1996), S. 206 f.
39
Der Einsatz des Datenbanksystems

Das Design erfolgte bekanntlich mit dem Endziel der Informationensversorgung.
Informationen lassen einfach durch Abfragen an die Datenbank entnehmen.
Beispiel: Eine Abfrage

Wir möchten gerne wissen, welche Lehrveranstaltungen der Student Daryush Ghassemi
(Matrikelnummer 96219559) besucht hat, und welche Noten dabei erzielt wurden.
Die dabei für uns relevanten Attribute sind:
• Die Matrikelnummer („Matrikel_Nr“)
• Der Nachname des Studenten („Nachname_Student“)
• Der Titel der Lehrveranstaltung („LV_Titel“)
• Der Nachname des Dozenten („Nachname_Dozent“)
• Die Prüfungsnote („Note“)
Die sich daraus ergebende SQL-Abfrage lautet:
SELECT STUDENTEN.Matrikel_Nr, STUDENTEN.Nachname_Student,

LEHRVERANSTALTUNGEN.LV_Titel, DOZENTEN.Nachname_Dozent,
PRÜFUNG.Note
FROM STUDENTEN, LEHRVERANSTALTUNGEN, DOZENTEN, PRÜFUNG
WHERE STUDENTEN.Matrikel_Nr = PRÜFUNG.Matrikel_Nr
AND PRÜFUNG.Dozenten_Nr = DOZENTEN.Dozenten_Nr
AND PRÜFUNG.LV_Nr = LEHRVERANSTALTUNGEN.LV_Nr
AND DOZENTEN.Dozenten_Nr = LEHRVERANSTALTUNGEN.LV_Dozent
AND STUDENTEN.Matrikel_Nr = ‚96219559‘;
Das Ergebnis dieser Abfrage:

Matrikel_Nr Nachname_Student LV_Titel Nachname_Dozent Note
96219559 Ghassemi Informationsmanagement Hermes 6
96219559 Ghassemi Datenbankentwurf und -management Winand 6
96219559 Ghassemi Kostenrechnung Mack 6
40
Schlussbemerkung
Der Nutzen eines systematischen Designs relationaler Datenbanken steht bei allem
Aufwand, der mit ihm verbunden ist, außer Frage, weswegen dieser systematische Ansatz
auch und gerade in der Praxis längst vorherrschend ist.
Insgesamt ergeben sich folgende Vorteile des systematischen Datenbankdesigns:

1. Der Entwurf ist gut dokumentiert, so dass sich auch Dritte in einen vertretbaren
Zeitrahmen einarbeiten können – dies ist insbesondere dann wichtig, wenn die
Mitarbeiter, welche die DB entworfen haben, nicht mehr zur Verfügung stehen.
2. Die DB lässt sich dank der guten Entwurfsdokumentation in einem vertretbaren
Zeitrahmen anpassen oder verändern. Dies gilt insbesondere, wenn für den Entwurf ein
CASE-Tool eingesetzt wurde.
3. Die durch den systematischen Entwurf gewonnene Zeit kann für Tests und Probeläufe
(„Prototyping“) verwendet werden. Sollten innerhalb dieser Probeläufe Mängel offenbar
werden, so lassen sich dank der modularisierten Entwurfsweise Anpassungen und
Veränderungen leicht umsetzen.
41
Abkürzungsverzeichnis
1 NF Erste Normalform
2 NF Zweite Normalform
3 NF Dritte Normalform
ANSI American National Standards Institute
AWS Anwendungssystem
CASE Computer Aided Software Engineering
DBA Datenbankadministrator
DBMS Datenbankmanagementsystem
DBS Datenbanksystem
DDL Data Definition Language
DML Data Manipulation Language
DV Datenverarbeitung
ERD Entity-Relationship-Diagramm
ERM Entity-Relationship-Modell
HM Hierarchisches Modell
IM Informationsmanagement
IuK Information und Kommunikation
IV Informationsverarbeitung
RDBMS Relationales Datenbank-Management-System
42
Anhang: Softwarewerkzeuge für die Datenbankentwicklung

Wie für jeden Bereich der Softwareentwicklung, so gibt es auch für die Entwicklung von
Datenbanken eine Fülle von Softwarewerkzeugen. Dabei reicht das Spektrum von Tools,
welche hauptsächlich für den konzeptionellen Entwurf von Datenbanken eingesetzt werden
(z.B. ARIS), bis hin zu vollwertigen CASE-Tools, welche eine bequeme Implementierung der
entworfenen Datenbanken in ein beliebiges DBMS ermöglichen (z.B. ERwin).
Der Einsatz dieser Tools bedeutet nicht nur einen Gewinn an Komfort, sondern auch und vor
allem an Geschwindigkeit und Qualität.
Nachfolgend eine zwar nicht vollständige, aber durchaus repräsentative Auswahl von
Tools102.
Computer Associates ERwin 4.0

(http://www.cai.com/products/alm/erwin.htm)
Ein sehr übersichtliches Programm, welches aufgrund seiner sehr einfachen Handhabung
ein schnelles Design und eine unkomplizierte Datenbankgenerierung ermöglicht.
Der einzige Nachteil dürfte lediglich die äußerst umständliche Evaluierung sein103.
Unterstützte Notationen: IE, IDEF1X
Embarcadero ER/Studio 4.2

Ebenfalls ein übersichtliches Programm, welches eine große Zahl von Datenbanksystemen
unterstützt. Allerdings ist die Evaluierungsphase mit 15 Tagen recht kurz bemessen.
Unterstützte Notationen: IE, IDEF1X
IDS Scheer ARIS Toolset 4.0

(http://www.ids-scheer.com/de)
Da ARIS Toolset die Datenbankgenerierung nicht unterstützt wird, ist dieses Tool nicht für
die durchgängige Datenbankentwicklung geeignet.
Man muss jedoch sagen, dass ARIS ein „Upper-CASE“–Tool104 sein will; d.h. dass es
lediglich die konzeptionelle Modellierung unterstützen, und eine integrierte Betrachtung der
Unternehmensweiten Prozesse, Daten und Organisationen ermöglichen will – und dafür ist
dieses Tool sehr gut geeignet.
Unterstützte Notationen: (Chen-)ERM, SAP-SERM105, IE, UML
102
Anmerkung: Es wurden ausschließlich Demoversionen der entsprechenden Programme
eingesetzt.
Diese können von den jeweiligen Herstellern bezogen werden.
103
Im Gegensatz zu den Programmen anderer Hersteller braucht man für ERwin einen Schlüssel, um
überhaupt in den Genuß der recht kurzen Evaluierungsphase zu kommen (während für die
Produkte anderer Hersteller kein Schlüssel erforderlich ist).
104
Vgl. Hansen (1996), S. 860
105
Von der SAP AG verwendetes Strukturiertes Entity-Relationship-Modell
43
Sybase PowerDesigner 7.0

(http://www.sybase.com/products/enterprisemodeling/powerdesigner)
Ein sehr gutes, weil sehr übersichtliches und dabei sehr leistungsfähiges Tool mit einer
exzellenten Oberfläche, zahlreichen Darstellungsoptionen und der Möglichkeit, logische,
physische, und objektorientierte Datenmodelle zu Erzeugen.
Unterstützte Notationen: IE, OOM (objektorientiertes Modell)
Silverrun Relational Data Modeler

(http://www.silverrun.com/products/rdm.html)
Ein gutes und übersichtliches Programm, welches zudem sehr geringe Anforderungen an die
Computerhardware hat (was bei heutigen Rechnern zugegebenermaßen keine Rolle mehr
spielt). Leider unterstützt die Demoversion das Forward Engineering, also die Generierung
von Datenbanken aus dem Datenmodell heraus, nicht (das Reverse Engineering wird
hingegen unterstützt).
Unterstützte Notationen: Datarun, IE
KBSI SmartER
(http://www.kbsi.com/Software/Smarter.htm)
Ebenfalls ein gutes Tool, mit ebenfalls sehr bescheidenen Hardwareanforderungen.
Nachteilig ist das äußerst umständliches Handling, da zwingend erst Projekte und Views
definiert werden müssen.
Unterstützte Notationen: IDEF1X, IDEF0
Microsoft Visio 2000 Professional / Enterprise Edition

(http://www.microsoft.com/office/visio)
Visio 2000 gibt es in vier verschiedenen Versionen. Der Entwurf von Datenbanken wird
jedoch nur von den Versionen „Professional Edition“ und „Enterprise Edition“ unterstützt.
Visio ist (in diesen Editionen) ein äußerst umfangreiches Programm, mit nahezu uferlosen
Konfigurationsmöglichkeiten.
Unterstützte Notationen: Chen-ERM, IE, IDEF1X, Bachman, Express-G, Martin-ERD,
ORM-Quellenmodell, Booch-OOD, ROOM, Rumbaugh-OMT, UML-Modelldiagramm
44
Quellen
Bilke, Petra
„Start mit Datenbanken und SQL“
KnowWare Verlag 1997
Buchmann, Alejandro:
„Datenbanken I“
http://www.bib.informatik.th-darmstadt.de/ttt/ai.htm
Chen, Peter:
"The Entity-Relationship-Model--Toward a Unified View of Data"
http://www.csc.lsu.edu/~chen/pdf/erd.pdf
Chen, Peter / Knöll, Heinz-Dieter:

„Der Entity-Relationship-Ansatz zum logischen Systementwurf“
BI-Wissenschaftsverlag 1991
Hald, Anton / Nevermann, Wolf:

„Datenbank-Engineering für Wirtschaftsinformatiker“
Vieweg Verlag 1995
Hansen, H. R.:
„Wirtschaftsinformatik I“
Lucius & Lucius 1996
Hay, David:
„A COMPARISON OF DATA MODELING TECHNIQUES“
Essential Strategies 1999
http://www.essentialstrategies.com
Hay, David:
„BUILDING QUALITY DATA MODELS“
http://www.essentialstrategies.com/publications/modeling/dmquality.htm
Heinrich, Lutz:
„Informationsmanagement“
Oldenbourg Verlag 1992
45
Heuer, Andreas / Saake, Gunter:

„Datenbanken: Konzepte und Sprachen“
ITP-Verlag 1995
Heyer, Gerhard:
„Datenmodellierung und ER-Modelle“
http://www.informatik.uni-leipzig.de/ifi/lehre/Heyer9900/kap21/index.htm
Kemper, Alfons:
„Datenbanksysteme – Eine Einführung“
Oldenbourg Verlag 1996
Link, Jörg:
„Führungssysteme“
Vahlen 1996
Meier, Andreas:
„Relationale Datenbanken: Eine Einführung für die Praxis“
Springer 1995
National Institute of Standards and Technology (www.nist.gov)

„INTEGRATION DEFINITION FOR INFORMATION MODELING (IDEF1X)“
Federal Information Processing Standards Publication 184, 1993
http://www.sdct.itl.nist.gov/~ftp/idef/idef1x.rtf
Roeing, Frank
„ORACLE 7 – Datenbanken erfolgreich realisieren“
Verlag Vieweg, Wiesbaden 1996
Schürr, Andy:
„Datenbanken I“
Skript zur Vorlesung „Datenbanken I“
http://ist.unibw-muenchen.de/Lectures/DBI/DBI.pdf
Vossen, Gottfried:
„Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme“
Addison-Wesley 1994
46

RDB Design DG

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RDB Design DG

Загружено:

Авторское право:

Доступные форматы

Universität Gesamthochschule Kassel

„Daten - und Informationsmanagement“

Eingereicht von: Erstgutachter:

INFORMATIONSMANAGEMENT, DATENMANAGEMENT, DATENBANKDESIGN........................... 5

HISTORISCHE ENTWICKLUNG DER IV-ORGANISATION ........................................................................................ 5

ZUM BEGRIFF DER RELATIONALEN DATENBANKEN ........................................................................ 13

ANFORDERUNGEN AN EIN RELATIONALES DATENBANKSYSTEM........................................................................ 14

DER ENTWURFSPROZESS – DESIGN EINER RELATIONALEN DATENBANK................................. 15

ANFORDERUNGEN AN EINEN SYSTEMATISCHEN ENTWURFSPROZESS................................................................. 15

DAS PRAXISBEISPIEL – DIE HANDELSHOCHSCHULE KASSEL ........................................................ 22

PHASE 1 – DIE ANFORDERUNGSANALYSE ......................................................................................................... 22

DER EINSATZ DES DATENBANKSYSTEMS .............................................................................................. 40

BEISPIEL: EINE ABFRAGE .................................................................................................................................. 40

ANHANG: SOFTWAREWERKZEUGE FÜR DIE DATENBANKENTWICKLUNG ............................... 43

COMPUTER ASSOCIATES ERWIN 4.0 .................................................................................................................. 43

Mit der Erkennen der Notwendigkeit, Information als strategischen Erfolgsfaktor

Informationsmanagement, Datenmanagement, Datenbankdesign

Historische Entwicklung der IV-Organisation

Die technische Entwicklung7

Systeme der 1. Generation verfügten lediglich über eine Stapelverarbeitung. Jedes

Systeme der 2. Generation ermöglichten erstmals die Dialogverarbeitung8. Zudem erlaubte

Systeme der 5. Generation (auch „Postrelationale Systeme“ genannt) umfassen sowohl

Die organisatorische Entwicklungsgeschichte:12

1. Phase Die Datenverarbeitung im Finanz- und Rechnungswesen

1. Phase: Die Datenverarbeitung im Finanz- und Rechnungswesen

2. Phase: Die aus dem Finanz- und Rechnungswesen herauswachsende Datenverarbeitung

3. Phase: Die Emanzipation der Datenverarbeitung

Die Entstehung des Informationsmanagements13

Beurteilung der technischen und organisatorischen Entwicklung

Notwendigkeit von Datenbanksystemen im Rahmen des Informationsmanagements

Da Informationen letztlich auf Daten basieren, führt eine unzureichende Datenhaltung

Aus dieser Aufgabe werden folgende Teilaufgaben abgeleitet:24

In meiner Hausarbeit soll es um die Entwicklung und Implementierung eines Datenmodells

Hier eine graphische Darstellung des Zusammenhangs:

Definition von Datenbanksystemen

Anwendung 1 Anwendung 2 Anwendung 3

Das Datenbankmanagementsystem besteht in der Regel aus mehreren Programmen,

Architektur von Datenbanksystemen – Drei-Schichten-Schemaarchitektur30:

Die externen Schemata beschreiben die für verschiedene Anwendungen und/oder

Der Vorteile der Drei-Schichten-Schemaarchitektur liegt in der erreichten

Zum Begriff der relationalen Datenbanken

Eine einzelne Zeile der Tabelle nennt man Tupel.

Anforderungen an ein relationales Datenbanksystem

Der Entwurfsprozess – Design einer relationalen Datenbank

Anforderungen an einen systematischen Entwurfsprozess

Phasenmodell („Wasserfallmodell“) des Software-Engineerings47

Die Phasen des Datenbankentwurfs49

Implementierung & Wartung

Phase 1: Die Anforderungsanalyse51

Phase 2: Konzeptioneller (fachlicher) Entwurf

Einzelsicht- oder Globalsichtorientiert ?

Phase 3: Der Verteilungsentwurf

Phase 3b: DBMS-Auswahl

Phase 4: Logischer Entwurf57

Phase 6: Physischer Entwurf64

Phase 7: Implementierung + Wartung67

Das Praxisbeispiel – die Handelshochschule Kassel

Phase 1 – Die Anforderungsanalyse

Die in der Anforderungsanalyse ermittelten Abschätzungen hinsichtlich Anzahl und Größe

Eigenschaften (Attribute) der Objekte:

Beziehungen der Objekte:

Phase 2: Der konzeptionelle Entwurf

Grundlagen des Entity-Relationship-Modells75: