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

  RELATIONALES DATENBANKDESIGN  

  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 Datenbanksysteme ¹ . 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 erstellen ² .

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 Bereitstellung ³ . 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 einzusetzen ⁴ , 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 Standard ⁶ .

Mit diesem systematischen Ansatz will sich diese Hausarbeit beschäftigen.

¹ 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.

² Es sei an die vielen mit MS Access oder ähnlichen Einbenutzersystemen realisierten Anwendungen erinnert.

³ Vgl. Hald / Nevermann 1995, S. 1 ⁴ Vgl. Heinrich 1992, S. 32 ⁵ Heinrich 1992, S. 176 ⁶ 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 Entwicklung 7

Die „technische Entwicklungsgeschichte“ lässt sich in fünf Generationen gliedern:

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 Dialogverarbeitung ⁸ . 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 Datenmodelle ⁹ benutzt (wie das hierarchische Datenmodell und das Netzwerkdatenmodell ¹⁰ ).

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. ⁷ Vgl. hierzu und im folgenden: Vossen (1994), S. 4 f.

⁸ siehe Hansen (1996), S. 869 ⁹ 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).

¹⁰ 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) ¹¹ .

Die organisatorische Entwicklungsgeschichte: 12

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

¹¹ Für nähere Informationen zu den postrelationalen Systemen siehe Kemper (1996) S. 311 ff. sowie S. 355 ff.

¹² 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 Informationsmanagements 13

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 Informationssystemen ¹⁴ ) zum Informationsmanagement (verstanden als die betriebliche Informationsfunktion betreffendes Leitungshandeln ¹⁵ ) ein; der Schwerpunkt der Informationsverarbeitung verlagerte sich immer mehr von der Datenverarbeitung zur Datenbereitstellung ¹⁶ .

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) ¹⁷ .

¹³ Vgl. Hierzu und im Folgenden: Heinrich (1992), S. 43 ff.

¹⁴ Vgl. Hansen (1997), S. 114

¹⁵ Vgl. Heinrich (1992), S. 11

¹⁶ Vgl. Heinrich (1992), S. 176

¹⁷ 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“ ¹⁸ ; Informationsmanagement wird von Heinrich als das gesamte, die Informationsfunktion einer Betriebswirtschaft betreffende Leitungshandeln verstanden. ¹⁹ 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. ²⁰ 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 Datenarchitektur 22 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.

¹⁸ Heinrich (1992), S. 7

¹⁹ Vgl. Heinrich (1992), S. 11 ²⁰ Vgl. Heinrich (1992), S. 19 ²¹ Vgl. Heinrich (1992), S. 20-21 ²² 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.

²³ Heinrich (1992), S. 176 ²⁴ Vgl. Heinrich (1992), S. 177

8

Hier eine graphische Darstellung des Zusammenhangs:

Generelle Sachziele

Doch auch ohne ein explizites Informationsmanagement lässt sich auf den Einsatz von Datenbanksystemen nicht verzichten, da ansonsten Redundanzen ²⁵ , Inkonsistenzen ²⁶ , 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 Transaktionssicherheit 27

²⁵ Redundanz ist die mehrfache Speicherung desselben Sachverhalts. ²⁶ Widersprüche zwischen den verwalteten Daten ²⁷ 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 Daten ²⁸ ). 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

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ühren ²⁹ . Anwendungen können nur über das DBMS auf die Datenbank zugreifen.

²⁸ Vg. Hald/Nevermann (1995), S. 2

²⁹ Vg. Hald/Nevermann (1995), S. 2

10

Architektur von Datenbanksystemen – Drei-Schichten-Schemaarchitektur ³⁰ : 1978 wurde von der Untergruppe SPARC ³¹ des amerikanischen Normenausschusses ANSI ³² ein Modell veröffentlicht, welches die Zusammenhänge zwischen Anwendungsdaten, Gesamtdatenbank und der physikalischen Speicherung definiert, und diese drei Ebenen klar trennt.

Das interne Schema beschreibt die Ebene der physischen Datenorganisation, also die Anordnung der Daten auf peripheren Speichern und die Zugriffspfadgestaltung ³³ . 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 Schemas ³⁴ .

³⁰ Vgl. hierzu und im folgenden: Vossen 1994, S. 24 – 26

³¹ Standards Planning and Requirements Comitee (SPARC)

³² American Standards Comitee on Computers and Information Processing, www.ansi.org ³³ 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 Ebene ³⁵ .

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 Datenbanksystems ³⁶ .

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.

³⁴ Vgl. Hansen (1996), S. 953

³⁵ Vgl. Hald/ Nevermann (1995), S. 5 ff.

³⁶ 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 Datenbankschema ³⁷ 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 Datenbanken ³⁸ .

Mathematisch ist eine Relation eine Teilmenge eines kartesischen Produkts aus den Domänen von n Attributen ³⁹ .

R ⊆ D 1 x … x D n

Eine Domäne (oder Wertebereich) ist eine Menge der verschiedenen Ausprägungen, die ein Attribut annehmen kann

Praktisch kann man sich eine Relation als Tabelle vorstellen, welche folgende Bedingungen erfüllt ⁴⁰ :

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.

³⁷ Ein Datenbankschema ist eine Beschreibung des strukturellen Aufbaus einer Datenbank. ³⁸ Codd, E.: „A relational Modell for large shared data banks“. In: Communications of the ACM, Band 13, Nr. 6, S. 377-387, Juni 1970 ³⁹ Vgl. hierzu Hald / Nevermann (1995) S. 25-27 ⁴⁰ Vgl. hierzu Roeing (1996) S. 63

13

Die erste Zeile gibt jeweils die Struktur einer Tabelle an, das sogenannte Relationenschema.

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üssen ⁴¹ :

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 SQL ⁴² 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.

⁴¹ 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.

⁴² "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 daraus ⁴³ , 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.“ ⁴⁴ 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-Engineerings ⁴⁶ angelehnt ist (schließlich ist das „Datenbank-Engineering“ auch eine Form des Software-Engineering), wird dieses kurz vorgestellt:

⁴³ Vgl. hierzu und im folgenden: Vossen (1994) S. 48 – 52 sowie Heuer (1995) S. 133 ff. ⁴⁴ Vossen (1994), S. 45 ⁴⁵ Vgl. Heinrich (1992), S. 176 ⁴⁶ Software-Engineering ist die von Grund auf systematische Softwareentwicklung (vgl. Hasen 1996, S. 859)

15

Phasenmodell („Wasserfallmodell“) des Software-Engineerings 47

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“ genannt ⁴⁸ .

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.

⁴⁷ 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. ⁴⁸ Vgl. Heinrich (1992), S. 180

16

Die Phasen des Datenbankentwurfs 49

Analog zu dem Modell des Software-Engineerings lässt sich auch der Datenbankentwurf in verschiedene Phasen aufteilen.

⁴⁹ Vgl. hierzu und im Folgenden: Schürr, Andy: „Datenbanken I“, S. 75 – 83 ⁵⁰ Vgl. Roeing (1996) S. 11

17

Phase 1: Die Anforderungsanalyse 51

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-Diagramm ⁵² ). 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 sein ⁵³ . 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).

⁵¹ Vgl. hierzu Heuer (1995) S. 136 und S. 137-138

⁵² Zur Entity-Relationship-Darstellungsmethode vergleiche Chen/Knöll (1991) S. 37 ff. ⁵³ 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 werden ⁵⁴ .

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 feststeht ⁵⁵ , 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

• Benchmarkergebnisse ⁵⁶ vergleichbarer Systeme

• der Preis

• das schon vorhandene IT-Umfeld

⁵⁴ Vgl. Chen/Knöll (1991) S. 25-26

⁵⁵ 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. ⁵⁶ Ein Benchmark ist eine Vergleichsmessung mithilfe standardisierter Hard- oder Software (vgl. Hansen 1996, S. 44 f.

19

Phase 4: Logischer Entwurf 57

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 Datenbankschema ⁵⁸ .

Anschließend wird das resultierende Schema (in unserem Fall also eine Sammlung von Relationen) anhand unterschiedlicher Qualitätskriterien optimiert ⁵⁹ . Dieser Schritt wird im Relationenmodell als „Normalisierung“ bezeichnet ⁶⁰ .

„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 DBMS ⁶² . 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 DBMS ⁶³ .

⁵⁷ Vgl. zum logischen Entwurf Heuer (1995) S. 142

⁵⁸ Diese Transformation erfolgt heutzutage meist automatisch, durch die Unterstützung entsprechender Software.

⁵⁹ Wobei durchaus verschiedene Optimierungsziele miteinander konkurrieren können, etwas redundanzfreie Speicherung durch Aufteilung mehrerer Relationen versus schnellerer Zugriff ⁶⁰ Der besseren Übersichtlichkeit wegen gehe auf die Normalisierung erst im Praxisabschnitt ein, da zur Veranschaulichung der Normalisierungstechniken ein Praxisbeispiel sehr nützlich ist ⁶¹ Chen/Knöll (1991), S.20 ⁶² 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.

⁶³ Allerdings ist – wie bereits erwähnt – diese Phase bei einigen Autoren schon im logischen Entwurf integriert.

20

Phase 6: Physischer Entwurf 64

Der physische Entwurf ist die Auswahl einer physischen Datenstruktur für eine gegebene logische Datenstruktur ⁶⁵ – 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-Tabelle ⁶⁶ 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 + Wartung 67

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 Entwurfsverifikation ⁶⁸ . 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.

⁶⁴ Vgl. hierzu und im Folgenden Heuer/Saake (1995), S. 143

⁶⁵ Vgl. Chen/Knöll (1991), S. 18 ⁶⁶ Für nähere Informationen zum Hash-Verfahren siehe Hansen (1996), S. 937 ff. ⁶⁷ Vgl. hierzu und im Folgenden Heuer/Saake (1995), S. 144 ⁶⁸ 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 fehlen ⁶⁹ .

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 integrierte ⁷⁰ Datenhaltung in größeren Softwaresystemen nimmt; demzufolge kommt dem Entwurf der Datenbank eine besondere Bedeutung zu ⁷¹ .

Phase 1 – Die Anforderungsanalyse

Aufgabe der Anforderungsanalyse ist es, die durch Gespräche mit den zukünftigen Anwendern gewonnenen Informationen in einem strukturierten Dokument festzuhalten ⁷² . 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.

⁶⁹ Mein Beispiel ist angelehnt an die Beispiele von Heuer (1995), S. 21-22, und Kemper 1996, S. 53 ff. ⁷⁰ Integriert im Sinne von „frei von Integritätsverletzungen“ ⁷¹ Vgl. hierzu Heuer (1995), S. 133 ⁷² 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, nichtfassbare 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önnen ⁷³ .

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-Tools ⁷⁴ erfolgt, erledige ich aus Gründen der besseren Veranschaulichung möglichst vieles manuell.

⁷³ Vgl. hierzu Kemper 1996, S. 48 – 49

⁷⁴ CASE = Computer Aided Software Engineering (siehe Hansen 1996, S. 859-861)

24

Phase 2: Der konzeptionelle Entwurf

Grundlagen des Entity-Relationship-Modells ⁷⁵ :

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:

Beispielhaftes Entity-Relationship-Modell

Diese von Peter Chen 1976 vorgestellte ursprüngliche Entity-Relationship-Model – Notation ⁷⁷ verliert allerdings bei zunehmender Größe des Modells an Übersichtlichkeit, weswegen viele

⁷⁵ Vgl. hierzu: Kemper (1996), S. 35 f.

⁷⁶ Kemper (1996), S. 35 ⁷⁷ 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) ⁷⁸ .

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ät ⁷⁹ wird anhand der Verbindungslinie deutlich, und kann bei Bedarf zusätzlich notiert werden.

Modell in der IDEF1X – Notation ⁸⁰ :

Modell in der Information Engineering – Notation ⁸¹ :

Da die Information Engineering – Notation (im folgenden kurz IE-Notation genannt) am verständlichsten ist, entscheide ich mich für diese.

⁷⁸ Einen ausführlicheren Vergleich der einzelnen Notationen bietet Hay, David: "A COMPARISON OF DATA MODELING TECHNIQUES", Essential Strategies 1999, http://www.essentialstrategies.com ⁷⁹ Kardinalität = Anzahl der zugeordneten Entitäten ⁸⁰ 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 ⁸¹ 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:

• 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 aus ⁸² :

⁸² 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 werden ⁸³ . 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 „MySQL ⁸⁴ “, 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 Relation ⁸⁵ .

⁸³ Vgl. hierzu und im folgenden: Roeing (1996), S. 63 ff.

⁸⁴ Informationen zu MySQL gibt es unter http://www.mysql.com ⁸⁵ Vgl. Hald/Nevermann (1995), S. 167

29

Überführung von 1:n – Beziehungen 86

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“ ist ⁸⁷ .

In unserem Fall wird der Fremdschlüssel in der Relation „LEHRVERANSTALTUNGEN“ aufgenommen, weil eine Lehrveranstaltung von Maximal einem Dozenten gehalten werden kann.

Überführung von 1:c – Beziehungen 88

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.

⁸⁶ Vgl. hierzu und im folgenden: Roeing (1996), S. 65 f.

⁸⁷ Vgl. Hald/Nevermann (1995), S. 171

⁸⁸ Vgl. hierzu und im folgenden: Hald/Nevermann (1995), S. 169

30

Überführung von n:m – Beziehungen 89

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.

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“.

⁸⁹ 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 Normalformen ⁹⁰ .

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.“ ⁹¹ 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.“ ⁹² 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.“ ⁹³ 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.

⁹⁰ Vgl. hierzu und im Folgenden Kemper (1996), S. 143-149; sowie Hald/Neverman (1995), S. 35-42 ⁹¹ Hald/Nevermann (1995), S. 37 ⁹² Hald / Nevermann (1995) S. 38 ⁹³ 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 Typen ⁹⁴ :

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.

⁹⁴ 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 aus ⁹⁵ :

⁹⁵ 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 werden ⁹⁶ . Beispielhaft sei hier die CREATE TABLE Anweisung für die Tabelle „STUDENTEN“ aufgezeigt:

CREATE TABLE STUDENTEN (

Matrikel_Nr

Nachname_Student Vorname_Student VARCHAR(50) NOT NULL, Studienbeginn

DATE NOT NULL, Adresse Geburtsdatum eMail_Student

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.

⁹⁶ 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:

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 muss ⁹⁷ .

⁹⁷ 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 geregelt ⁹⁸ . 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;

⁹⁸ 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 realisieren ⁹⁹ . 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 geplant ¹⁰⁰ , 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 lassen ¹⁰¹ .

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;

⁹⁹ Vgl. hierzu Hald/Nevermann (1995), S. 203 f.

¹⁰⁰ Siehe hierzu das entsprechende Kapitel im MySQL-Manual (http://www.mysql.com/doc/M/i/Missing_Views.html) ¹⁰¹ 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:

STUDENTEN.Matrikel_Nr, STUDENTEN.Nachname_Student, SELECT LEHRVERANSTALTUNGEN.LV_Titel, DOZENTEN.Nachname_Dozent, PRÜFUNG.Note STUDENTEN, LEHRVERANSTALTUNGEN, DOZENTEN, PRÜFUNG FROM STUDENTEN.Matrikel_Nr = PRÜFUNG.Matrikel_Nr WHERE 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‘;

AND Das Ergebnis dieser Abfrage:

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

RELATIONALES DATENBANKDESIGN  

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 Tools ¹⁰² .

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 sein ¹⁰³ . 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“–Tool ¹⁰⁴ 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-SERM ¹⁰⁵ , IE, UML

¹⁰² Anmerkung: Es wurden ausschließlich Demoversionen der entsprechenden Programme eingesetzt.

Diese können von den jeweiligen Herstellern bezogen werden.

¹⁰³ 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).

¹⁰⁴ Vgl. Hansen (1996), S. 860 ¹⁰⁵ 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