Relationales Datenbankdesign

Inhalt

EINLEITUNG / PROBLEMSTELLUNG

INFORMATIONSMANAGEMENT, DATENMANAGEMENT, DATENBANKDESIGN
HISTORISCHE ENTWICKLUNG DER IV-ORGANISATION
Die technische Entwicklung
Die organisatorische Entwicklungsgeschichte
Beurteilung der technischen und organisatorischen Entwicklung
NOTWENDIGKEIT VON DATENBANKSYSTEMEN IM RAHMEN DES INFORMATIONSMANAGEMENTS
DEFINITION VON DATENBANKSYSTEMEN
ARCHITEKTUR VON DATENBANKSYSTEMEN – DREI-SCHICHTEN-SCHEMAARCHITEKTUR

ZUM BEGRIFF DER RELATIONALEN DATENBANKEN
ANFORDERUNGEN AN EIN RELATIONALES DATENBANKSYSTEM

DER ENTWURFSPROZESS – DESIGN EINER RELATIONALEN DATENBANK
ANFORDERUNGEN AN EINEN SYSTEMATISCHEN ENTWURFSPROZESS
PHASENMODELL („WASSERFALLMODELL“) DES SOFTWARE-ENGINEERINGS
DIE PHASEN DES DATENBANKENTWURFS
Phase 1: Die Anforderungsanalyse
Phase 2: Konzeptioneller (fachlicher) Entwurf
Phase 3: Der Verteilungsentwurf
Phase 3b: DBMS-Auswahl
Phase 4: Logischer Entwurf
Phase 5: Datendefinition
Phase 6: Physischer Entwurf
Phase 7: Implementierung + Wartung

DAS PRAXISBEISPIEL – DIE HANDELSHOCHSCHULE KASSEL
PHASE 1 – DIE ANFORDERUNGSANALYSE
Zu abstrahierende Objekte:
Eigenschaften (Attribute) der Objekte:
Beziehungen der Objekte:
PHASE 2: DER KONZEPTIONELLE ENTWURF
Grundlagen des Entity-Relationship-Modells
Unser konzeptuelles Modell:
PHASE 3: DER LOGISCHE / RELATIONALE ENTWURF
Überführung von Entitäten
Überführung von 1:n – Beziehungen
Überführung von 1:c – Beziehungen
Überführung von n:m – Beziehungen
PHASE 3B: NORMALISIERUNG
PHASE 4: DATENDEFINITION
PHASE 5: IMPLEMENTIERUNG
Schemagenerierung über ODBC
DEFINITION DER ZUGRIFFRECHTE
Datenbankrechte
Tabellenrechte
DEFINITION VON SICHTEN
Sichten & Datenschutz

DER EINSATZ DES DATENBANKSYSTEMS
BEISPIEL: EINE ABFRAGE

SCHLUSSBEMERKUNG

ABKÜRZUNGSVERZEICHNIS

ANHANG: SOFTWAREWERKZEUGE FÜR DIE DATENBANKENTWICKLUNG
COMPUTER ASSOCIATES ERWIN 4.0
EMBARCADERO ER/STUDIO 4.2
IDS SCHEER ARIS TOOLSET 4.0
SYBASE POWERDESIGNER 7.0
SILVERRUN RELATIONAL DATA MODELER
KBSI SMARTER
MICROSOFT VISIO 2000 PROFESSIONAL / ENTERPRISE EDITION

QUELLEN

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

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.

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⁷

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

Abbildung in dieser Leseprobe nicht enthalten

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.

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:¹²

Abbildung in dieser Leseprobe nicht enthalten

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 Aufgaben waren nicht vorhanden, sodass die individuellen Bedürfnisse der Benutzer eine große Rolle spielten.

Die Entstehung des Informationsmanagements¹³

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

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

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

Aus dieser Aufgabe werden folgende Teilaufgaben abgeleitet:²⁴

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

Abbildung in dieser Leseprobe nicht enthalten

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²⁷

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

Abbildung in dieser Leseprobe nicht enthalten

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.

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.

Abbildung in dieser Leseprobe nicht enthalten

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

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.

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.

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³⁹.

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

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.

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

Abbildung in dieser Leseprobe nicht enthalten

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.

[...]

---

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

⁷ 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

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

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

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

²⁵ 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.

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

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

³⁰ 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

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

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

³⁶ Vgl. Hald/Nevermann (1995), S. 6.

³⁷ 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

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