Grundlagen Relationale Datenbanken

MultiAugustinum
E2A/E3A
SQL
Relationale Datenbanksysteme
Mag. Christian Gürtler
2011
Inhaltsverzeichnis
I.
Allgemeines
5
1. Vergleich Datenbankysteme – Dateisystem
7
2. Architektur eines DBMS
11
2.1. Konkrete Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Arten von Datenbanksystemen
3.1. Hierarchische Datenbanksysteme . .
3.2. Netzwerkmodell . . . . . . . . . . . .
3.3. Objektorientierte Datenbanksysteme
3.4. Relationale Datenbanksysteme . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
II. Datenbankdesign
4. Entity-Relationship-Modell
4.1. Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Grundlagen des Entity-Relationship-Modells (ER-Modell)
4.3. Eigenschaften von Beziehungen . . . . . . . . . . . . . . .
4.3.1. Eigenschaften von Eigenschaften . . . . . . . . . .
4.3.2. Stelligkeit . . . . . . . . . . . . . . . . . . . . . . .
4.3.3. Kardinalität – Konnektivität . . . . . . . . . . . .
4.3.4. Stärke der Beziehung . . . . . . . . . . . . . . . . .
4.3.5. Optionalität . . . . . . . . . . . . . . . . . . . . . .
4.3.6. Abhängige Entity-Typen, IST-Beziehung . . . . . .
4.3.7. Redundante Beziehungen . . . . . . . . . . . . . .
4.4. Beispiel eines ER-Modells . . . . . . . . . . . . . . . . . .
15
15
15
16
16
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
20
23
24
25
25
27
27
28
28
30
3
Teil I.
Allgemeines
5
1
Vergleich Datenbankysteme –
Dateisystem
Bis in die 1960er-Jahre wurden die Daten in einem Dateisystem gespeichert, im
schlimmsten Fall verwaltet jedes Anwendungsprogramm seine eigenen Daten und mitunter auch noch in eigenen Dateiformaten (Excel als xls, Access als mdb usw.)
• Die Buchhaltung speichert Daten über Artikel und Adressen.
• Die Auftragsverwaltung bearbeitet Daten über Aufträge, Adressen und Kunden
• Die Kundenbetreuung bearbeitet Daten der Kunden (Adressen,...)
Anwendung 1
Datei 1
Anwendung 2
Datei 2
Datei 3
Abbildung 1.1.: Zugriff auf Dateien
Problem der Datenredundanz
In diesem Szenario sind die Daten mehrfach (redundant) gespeichert, in der Folge
kommt es einerseits zu unnötig belegtem Speicherplatz und andererseits (was noch
gravierender ist) zu Dateninkonsistenzen: ändert die Kundenbetreuung die Daten eines Kunden – zum Beispiel von Herrn Müller, dann müssen auch die Buchhaltung und
die Auftragsverwaltung ihre Daten ändern. Geschieht dies nicht, so haben alle Abteilungen unterschiedliche Datensätze, also inkonsistente Daten. Der Müller aus der
Kundenbetreuung ist nicht mehr der Kunde Müller aus der Auftragsverwaltung.
7
1. Vergleich Datenbankysteme – Dateisystem
Weitere Problemfelder
Um diese Daten zu verwalten, werden in den Betrieben oft zusätzlich spezielle Anwendungsprogramme entwickelt. Die Entwickler solcher Programme müssen jedoch
wissen, wie die Daten intern gespeichert werden (um die Daten in einem speziellen
Format zu speichern). Dieser Punkt wird als fehlende Datenunabhängigkeit bezeichnet.
Ein weiterer Punkt der Speicherung von Daten in einem Dateisystem betrifft fehlende Zugriffskontrolle und Datensicherheit. Meist können in einem Dateisystem die
Rechte nur bis auf Dateiebene vergeben werden, nicht jedoch auf einzelne Inhalte einer Datei. Zusätzlich existieren kaum Möglichkeiten, Dateien so zu sperren, dass sich
mehrere Benutzer beim Bearbeiten nicht gegenseitig behindern bzw. Daten gegenseitig
überschreiben (was zu Datenverlust führen kann).
Ende der 1960er-Jahre wurden Dateiverwaltungssysteme eingeführt. Zwischen Datei
und Anwendung liegt eine Dateiverwaltungsschicht (z. B ISAM – Indexed Sequential
Access Method ).
Anwendung 1
Anwendung 2
Dateiverwaltungssystem I
Datei 1
Dateiverwaltungssystem II
Datei 2
Datei 3
Abbildung 1.2.: Zugriff auf Dateien
Mit der Verwendung von (I)SAM wurde Geräteunabhängigkeit erreicht, die Daten
waren aber immer noch redundant gespeichert.
Die Lösung dieser Probleme wurden in den 1970er-Jahren durch den Einsatz von
Datenbanksystemen erreicht, hier ist insbesonders das von Codd entwickelte Relationenmodell zu nennen. Die Daten sind in einer Datenbank gespeichert, wo die Daten
physisch liegen wird vom Datenbankmanagementsystem (DBMS) verwaltet, die Anwender und Programmiererer brauchen sich in der Regel nicht darum zu kümmern.
Der Zugriff erfolgt sozusagen gefiltert“ (abstrahiert) durch das DBMS.
”
8
Anwendung 1
Anwendung 2
DBMS
Datenbank
Abbildung 1.3.: Zugriff auf Datenbank
Zusammengefasst: Datenbanksysteme zeichnen sich durch folgende Prinzipien aus:
• Die Daten werden zentral und nicht-redundant gespeichert.
• Mehrere Benutzer können gleichzeitig (parallel) auf die Daten zugreifen. Transaktionen verhindern unerwünschte Nebeneffekte. Konkurrierende Transaktionen
müssen synchronisiert werden (greifen mehrere Transaktionen auf einen Datensatz zu, so müssen sie aufeinander abgestimmt werden). 1
• Datenunabhängigkeit gewährleistet die Unabhängigkeit der Programme von den
Daten und umgekehrt. Wie die Daten organisiert bzw. gespeichert werden spielt
für ein Programm keine Rolle; ein bestimmtes Programm oder eine Applikation
darf wiederum die Organisation der Daten nicht beeinflussen.
• Datenbanksysteme gewährleisten feiner abgestimmte Zugriffskontrollen und Rechte. Sichten (eingeschränkte Sicht auf die Daten) und Rechte auf einzelne Datensätze (Zeilen) sind möglich (views).
• Ein Datenbanksystem bietet Operationen zum Suchen, ändern und Anlegen von
Datensätzen. Dazu sind deskriptive Sprachen vorhanden.
• Ein Katalog, auch Data Dictionary genannt, ermöglicht Zugriffe auf die Beschreibungen (Metadaten) der Daten und Datenbanken (um zum Beispiel zu erfahren,
wer einen bestimmten Datensatz angelegt oder geändert hat, oder welche Tabellen eine bestimmte Datenbank besitzt).
• Das Datenbanksystem gewährleistet die Datenintegrität (Konsistenz).
• Datensicherung muss die Wiederherstellung von Daten nach Fehlern gewährleisten.
1 Unter
einer Transaktion versteht man eine Zusammenfassung von Datenbankprozessen, die als
gesamtes (atomar) ausgeführt werden. Nach einer Transaktion befindet sich die Datenbank in
einem konsistenten (consistent) Zustand. Mehrere Transaktionen laufen isoliert voneinander ab.
Bei Erfolg sind die Daten dauerhaft speichert – ACID.
9
1. Vergleich Datenbankysteme – Dateisystem
Im Zusammenhang mit Datenbanken sind verschiedene Begriffe üblich.
Folgende Tabelle erläutert die Unterschiede:
Kürzel
Begriff
Erläuterung
DB
Datenbank
Datenbestand
DBMS
Datenbankmanagementsystem
verwaltet Datenbestand
DBS
Datenbanksystem
DB + DBMS
Tabelle 1.1.: Begriffe
10
2
Architektur eines DBMS
Es werden drei Ebenen unterschieden, die den Zugriff auf die Daten gewährleisten:
• die externe Ebene beschreibt, wie Anwendungen (Masken, Einbettung in Programmiersprachen wie PHP), die Daten sehen. Da dies je nach Anwendung unterschiedlich ist, existiert eine
• konzeptuelle Ebene, die eine logische Sicht auf die Daten bietet. Eine Stufe tiefer
existiert eine
• interne Ebene, die sich um die physische Speicherung auf Platten- bzw. Betriebssystemebene kümmert.
Dieses Schema gewährleistet einen wichtigen Punkt, nämlich den der Datenunabhängigkeit mit ihren zwei Teilaspekten (Implementierungsunabhängigkeit, physische Datenunabhängigkeit – wie die Daten gespeichert werden, ist für die Sicht auf die Daten egal –
und Anwendungsunabhängigkeit, logische Unabhängigkeit – Änderungen auf eine Anwendung dürfen sich nicht auf die Daten auswirken).
Modell für die konzeptuelle Ebene: Relationenmodell
Die Grundlage des Relationenmodells liefert die Relation. Eine Tabelle wird durch ein
sog. Relationenschema beschrieben. Dieses Schema gibt an, aus wievielen Spalten die
Tabelle besteht und wie die Spalten benannt sind. Die Einträge in der Tabelle werden
als Relation zu diesem Schema bezeichnet. Ein Tupel bezeichnet eine Zeile in einer
Tabelle. Die Spaltenüberschriften werden als Attribute bezeichnet.
Relationenname
Weine
Tupel
Attribute
Name
La Rose Grand Cru
Zinfandel
Chardonnay
Farbe
Rot
Rot
Weiß
Jahrgang
1998
2003
1999
Weingut
Creek
Helena
Müller
Relationenname
Relation
Tabelle 2.1: Begriffsbildung
11
2. Architektur eines DBMS
2.1. Konkrete Architekturen
Die relationalen DBMS sind die Systeme, die den Markt dominieren. Vertreter sind
IBM (DB2, Informix), Oracle (Oracle 11g), Microsoft (SQL Server), PostgreSQL, SUN
(MySQL). Die beiden letztgenannten sind Open-Source-Systeme.
Gemeinsame Merkmale sind
• die Drei-Ebenen-Architektur
• einheitliche Sprache (SQL)
• Einbettung in Programmiersprachen wie C/C ++, PHP, Java
• kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle
Mit Ausnahme von SQL Server (läuft nur auf Microsoft-Servern) gibt es für die oben
genannten Datenbanksysteme Versionen für die gängigsten Betriebssysteme (Windows,
UNIX, Linux). Aus der Sicht einer Anwendung ist ein DBMS ein Client-Server-System.
Der Client läuft meist auf einem PC (Mysql-Query-Browser, PHPMyAdmin, . . . ), der
eine Anfrage an den Server stellt. Dieser nimmt die Anfrage auf, führt eine Bearbeitung
durch und gibt die Ergebnisse dem Client zurück.
Client
Server
3
Anfrage
Antwort
Bearbeitung
1
2
Abbildung 2.1.: Client-Server-System
Oft sind diese Systeme reine sog. Zwei-Schichtensysteme (reine Client-Server-Systeme),
wo sowohl Benutzerschnittstelle als auch die Anwendungslogik im Client integriert
sind. Bei manchen Systemen gibt es allerdings drei Schichten, wie beispielsweise Apache/PHP-MySQL-PostgreSQL. Streng genommen kann der Apache mit PHP und der
entsprechenden Schnittstelle zur Datenbank als eigener Applikationsserver betrachtet werden. Solche Drei-Schichtensysteme gibt es auch bei Oracle, IBM (WebSphere),
RedHat (JBoss), Java Beans. . . .
Bei diesen Beispielen ist es oft problematisch, wenn ein Datenbanksystem durch ein
anderes ersetzt werden soll (beispielsweise MySQL durch Oracle). Dann müssen in
12
2.1. Konkrete Architekturen
sämtlichen Anwendungsprogrammen die Schnittstellen geändert werden (Risiko, Zeitaufwand). Um diese Probleme zu umgehen, wurden sog. Middleware-Lösungen wie
CORBA oder ODBC entwickelt. Diese zusätzliche Schicht enthält nur die Information
(Treiber) über die darunterliegende Datenbank, das Anwendungsprogramm braucht
sich darum nicht zu kümmern. änderungen sind daher nur einmal notwendig und nicht
in allen Programmen.
(a) Zwei-Schichten-System
(b) Drei-Schichten-System
Benutzerschnittstelle
Benutzerschnittstelle
Anwendungslogik
DB-Schnittstelle
Anwendungslogik
DB-Schnittstelle
Datenbank
Datenbank
Abbildung 2.2.: Anwendungsarchitekturen
13
3
Arten von Datenbanksystemen
3.1. Hierarchische Datenbanksysteme
In den 1960er-Jahren wurde das sogenannte hierarchische Datenbankmodell entwickelt.
Die Daten werden in einer Baumstruktur mit einem Root-Knoten, ästen (vertikal) und
Blättern (horizontal) gespeichert.
Firma
Vorstand
Müller
Produktion
Huber
Dorfer
Meier
Vertrieb
Hauser
Berger
Abbildung 3.1.: Hierarchisches Modell
In diesem Modell sind nur 1 : 1 und 1 : N -Beziehungen darstellbar, M : N Beziehungen sind nur mit zusätzlichem Aufwand (virtuelle Zeiger) darstellbar. Ein
ähnliches System existiert in LDAP, einem modernen plattformübergreifenden Userverwaltungssystem.
3.2. Netzwerkmodell
In diesem System, das auch als CODASYL-System, bekannt ist, sind auch M : N Beziehungen darstellbar, allerdings fehlt hier der wesentliche Punkt der Datenunabhängigkeit; als Programmiersprache ist weitgehend COBOL und keine eigene Abfragesprache wie SQL im Einsatz. Diese Datenbanken werden hauptsächlich noch auf
15
3. Arten von Datenbanksystemen
Großsrechnern eingesetzt. Der Datenbestand besteht hier aus netzwerkartig verketteten Datensätzen (Records).
3.3. Objektorientierte Datenbanksysteme
Diese Systeme entstanden bereits in den 1980er-Jahren und wollen prinzipiell die objektorientierte Ausrichtung von Programmiersprachen wie C ++, Smalltalk oder Java
auf Datenbanken abbilden. Erst 1993 bildete sich so etwas wie ein gemeinsamer Standard (Kompromiss).
3.4. Relationale Datenbanksysteme
Im folgenden wird hauptsächlich dieses Modell mit Tabellen, Entities, Relationen etc.
besprochen.
16
Teil II.
Datenbankdesign
17
4
Entity-Relationship-Modell
4.1. Modelle
Modelle dienen zum Erfassen der Daten und nicht der daraus gewonnen Informationen. Daten sind zum Beispiel Schüler mit ihrem Namen, Geburtsdatum und Noten,
Informationen werden daraus gewonnen (Notendurchschnitt, Alter). Um ein Modell
zu entwickeln, sind Informationen über
1. statische Eigenschaften von Objekten und Beziehungen,
2. dynamische Eigenschaften wie Operationen und Beziehungen zwischen Operationen,
3. Integritätsbedingungen von Objekten und Operationen
zu sammeln. Objekte sind zum Beispiel Artikel mit statischen Eigenschaften Bezeichnung, Preis etc. Beziehungen wären beispielsweise: 1 Erzeugern produziert einen Artikel, oder Schüler x geht in die Klasse y.
Dynamische Eigenschaften (Operationen) wären die Berechnung des Endpreises mit
Skonto. Eine Beziehung zwischen Operationen könnte sein, dass ein Artikel erst dann
bestellt werden darf, wenn er produziert wurde, oder ein Schüler erst dann in den
Aufbaulehrgang kommen darf, wenn er eine Fachschule absolviert hat.
Integritätsbedingungen legen zum Beispiel fest, dass ein Artikel eine eindeutige Nummer aufweisen muss (Schlüsselbedingung) und dass es zu jedem Artikel einen Erzeuger
geben muss (referentielle Integrität).
Im Relationenmodell sind sie Daten in ungeschachtelten Tabellen gespeichert (SQLDatenbanken), die Beziehungen werden durch Wertevergleich ausgedrückt. Eine Erweiterung dieses Modells ist das Modell der geschachtelteten oder Non-First-Normal-Form
(N F 2 ), in der Attribute Relationen als Werte haben dürfen, sonst dürfen nur einfache
Strings (keine Arrays, . . . ) gespeichert werden.
Als Vorstufe des Relationenmodells wird das Entity-Relationship-Modell angesehen,
das eine abstrakte Sicht auf die Daten liefert und für einen Entwurf einer Datenbank
unerläßlich ist. Hier werden die Daten mit ihren Attributen und Beziehungen grafisch
dargestellt.
19
4. Entity-Relationship-Modell
4.2. Grundlagen des Entity-Relationship-Modells
(ER-Modell)
Das ER-Modell geht zurück auf eine Arbeit von P. P. Chen im Jahre 1976 und ist
heute faktisch Standard bei der Datenbankentwicklung. Zum ER-Modell gehört eine
grafische Notation (ER-Diagramm oder ERD , die die Datenbank mit ihren Daten und
Beziehungen abstrakt darstellt. Das ER-Modell spiegelt nicht die konkreten Werte wider, sondern zeigt nur die typmäßige Struktur.
Zum ER-Modell gehören drei Begriffe:
1. Entity: ein Objekt aus der reellen Welt (Artikel, Kunden, Lieferanten,. . . ).
Wichtig ist dabei festzustellen, welche Objekttypen (Entitytypen) vorhanden
sind. Ein Objekttyp ist vergleichbar mit einem Karteikasten (Kundenkartei), in
dem für jedes einzelne Objekt( Kunde) eine Karteikarte angelegt wird. Der Objekttyp ist sozusagen die Abstraktion.
2. Relationship: gibt die Beziehung zwischen den Entities wider (Lieferant produziert Artikel, Kunde kauft Artikel,. . . )
3. Attribut: entspricht einer Eigenschaft von Entities oder auch Beziehungen (Farbe eines Weines, Bezeichnung eines Artikels, Name von Kunden,. . . ). Um diese Attribute speichern zu können, sind entsprechende Datentypen notwendig
(integer für ganze Zahlen, date für Datumswerte, char für Strings, . . . )
Entity-Typen
Entities sind Einheiten, in denen Objekte mit der gleichen Art von Eigenschaften gespeichert werden. Die einzelnen Zeilen (Tupel) werden nicht als eigene Einheit gespeichert, sondern werden beispielsweise alle Artikel, die eine Nummer, eine Bezeichnung
und einen Preis aufweisen in einem Entity-Typ Artikel gespeichert. In der grafischen
Notation werden diese Entity-Typen als Rechteck (bei Oracle mit gerundeten Ecken)
dargestellt und der Name des Typs im Rechteck eingetragen.
(a) klassische Darstellung
(b) Darstellung Oracle
Artikel
Artikel
Abbildung 4.1.: Grafische Darstellung eines Entity-Typs
Beziehungstypen
Beziehungen zwischen Entities werden nicht für jede Ausprägung modelliert, sondern
zu Beziehungstypen zusammengefasst, also nicht, dass Artikel Feinkristallzucker von
20
4.2. Grundlagen des Entity-Relationship-Modells (ER-Modell)
der Firma Agrana stammt, sondern dass ein Artikel von einem Produzenten erzeugt
wird. Beziehungstypen werden als Raute dargestellt. Die Beziehungen können Zweistellig (binär) oder n-stellig sein:
(a) binärer Beziehungstyp
Artikel
produziert
Produzent
Kritiker
empfiehlt
Wein
Speise
(b) n-stelliger Beziehungstyp
Abbildung 4.2.: Grafische Darstellung von Beziehungstypen
Attribute
modellieren Eigenschaften von Entities oder Beziehungen, alle Entities eines Typs haben die selben Arten von Eigenschaften. Attribute werden als Oval dargestellt und
einem Entity-Typ zugeordnet. Wie genau die Attribute zergliedert werden, hängt von
den Anforderungen ab. Zum Beispiel kann eine Adresse wie 5581 St. Margarethen
Schulgasse 60 als kompletter Satz gespeichert werden – soll später aber nach Postleitzahlen oder Orten gesucht werden, empfiehlt sich eine Auftrennung in ein Attribut
Postleitzahl, ein Attribut Straße und ein Attribut Ort.
Eigenschaften (Attribute) können identifizierend sein (zum Beispiel eine Buchnummer
oder Personalnummer) oder beschreibend. Hat ein Objekttyp kein identifizierendes
Attribut, so spricht man von einem schwachen Objettyp
Preis
Nummer
Artikel
Bezeichnung
Abbildung 4.3.: Attributnotation eines Entity-Typs
Neben Entities können auch Beziehungen Attribute aufweisen.
21
4. Entity-Relationship-Modell
Anteil
Wein
hergestellt aus
Rebsorte
Abbildung 4.4.: Attributnotation für Beziehungen
In dieser Abbildung ist die Beziehung zweier Tabellen (Entities) dargestellt, das
Attribut Anteil ist weder der Entity Wein noch der Entity Rebsorte zugeordnet.
Beziehungen können auch rekursiv sein, zum Beispiel kann in einem Objekttyp Person
ein Objekt mit einem anderen in Beziehung stehen, wenn Herr Meier der Vorgesetzte
von Frau Müller ist.
Person
PersonalNummer
Name
Abbildung 4.5.: rekursive Beziehung
Identifizierung durch Schlüssel
Für jede Entity gibt es den Effekt, dass einige Attribute mit ihren Werten für eine
eindeutige Identifizierung der Entity sorgen. Ein Wein kann zum Beispiel durch die
Kombination aus Namen, Jahrgang und Weingut identifiziert werden, ein Mitarbeiter
in einer Firma durch seine Sozialversicherungsnummer oder ein Buch durch seine ISBNNummer. Diese Attribute werden Schlüsselattribute genannt. Oft tritt der Fall ein,
dass es mehrere Kandidaten gibt – ein Wein kann durch die Kombination aus Namen,
Jahrgang und Weingut, aber auch durch ein künstliches Merkmal (interne Nummer)
eindeutig gekennzeichnet werden. Aus diesen Kandidaten wird einer gewählt, dieser
wird dann der sog. Primärschlüssel .
Für eine eindeutige Identifizierung gibt es drei Möglichkeiten
• eine einzige Eigenschaft: unikales Attribut; Beispiele wären Sozialversicherungsnummer, ISBN-Nummer. Diese Attribute werden auch natürliche Schlüssel genannt.
22
4.3. Eigenschaften von Beziehungen
• Kombination von Eigenschaften: hier müssen so wenige Merkmale wie möglich
herangezogen werden. Zum Beispiel kann ein Wein durch die Kombination aus
Namen, Jahrgang, Weingut identifiziert. Name, Jahrgang wäre wahrscheinlich
zu wenig, Name, Jahrgang, Weingut, Restzucker wäre zu viel.
• künstliche Schlüssel: wenn ein natürlicher Schlüssel nicht vorhanden ist oder
eine Kombination zu umständlich ist, werden künstliche Attribute eingeführt.
Ein Beispiel wäre in einer Firma die Personalnummer oder in einem Laden die
Artikelnummer.
Künstliche Schlüssel werden sehr oft eingesetzt, da sie meistens kürzer sind (Vergleich Personalnummer mit Sozialversicherungsnummer) und daher weniger fehleranfällig (gegen vertippen etc.) sind.
4.3. Eigenschaften von Beziehungen
Beziehungen gehen immer in zwei Richtungen – zum Beispiel:
Lehrer unterrichtet Schüler; Schüler wird von Lehrer unterrichtet ;
wobei die Fragestellung immer von 1 ausgehen muss:
1 Lehrer unterrichtet wie viele Schüler, 1 Schüler wird von wie vielen Lehrern unterrichtet.
Falsch wäre:
Mehrere Lehrer unterrichten mehrere Schüler, mehrere Schüler werden von mehreren
Lehrern unterrichtet.
Dies würde nichts über die tatsächliche Beziehung zwischen den einzelnen Objekten
(hier Personen) aussagen. Beziehungen lassen sich durch drei Eigenschaften charakterisieren:
• die Stelligkeit gibt an, wie viele Entities an einer Beziehung beteiligt sind
• die Kardinalität gibt an, wie viele Instanzen eines Entity-Typs an einer Beziehung
beteiligt sind.
• die Optionalität . Beispiel: 1 Autor kann (muss aber nicht) Bücher schreiben, 1
Buch muss aber unbedingt von einem Autor geschrieben werden.
Häufig besteht die Notwendigkeit, eine Beziehung zwischen Objekttypen genauer zu
spezifizieren. Zum Beispiel werden in einem Standesamt Informationen gespeichert,
welcher Mann mit welcher Frau verheiratet ist und wann das Hochzeitsdatum war.
Dieses Hochzeitsdatum gehört als Eigenschaft weder zu Mann noch zu Frau, sie ist
eine Eigenschaft der Beziehung.
Ein ähnliches Beispiel wäre die Beziehung zwischen Arbeitgeber und Arbeitnehmer.
Das Einstellungsdatum ist eine Eigenschaft der Beziehung und nicht des Arbeitgebers
oder Arbeitnehmers.
23
4. Entity-Relationship-Modell
Ehe
Mann
Frau
FamName
FamName
Datum
Vorname
Vorname
Abbildung 4.6.: Eigenschaft einer Beziehung
4.3.1. Eigenschaften von Eigenschaften
Angenommen, es werden Informationen über den Fuhrpark einer Firma gespeichert.
Ein Auto weist ein eindeutiges Kennzeichen, eine Farbe, eine Marke auf. Nun soll zu
dieser Marke ein Mindestpreisreis gespeichert werden.
Auto
Kennzeichen
Marke
Farbe
Abbildung 4.7.: Objekttyp Auto
Was würde passieren, wenn zu dieser Marke der Mindestpreis gespeichert wird? Wenn
mehrere Autos zur gleichen Marke gehören, würden Redundanzen auftreten und somit die Fehleranfälligkeit steigen. Daher folgt eine Transformation wie in folgendem
Schema.
Auto
Marke
Kennzeichen
Marke
MinPreis
Farbe
Abbildung 4.8.: Eigenschaften von Eigenschaften
24
4.3. Eigenschaften von Beziehungen
4.3.2. Stelligkeit
Sie beschreibt die Anzahl der beteiligten Entities. Die Mehrzahl der Beziehungen ist
zweistellig (binär), es gibt aber auch ternäre (dreistellige) und n-stellige Beziehungen.
Dazu folgendes Beispiel:
(a) ternärer Beziehungstyp
Wein
empfiehlt
Kritiker
Speise
(b) Drei binäre Beziehungstypen
Kritiker
K-S
K-W
Speise
Wein
S-W
Abbildung 4.9.: Beziehungstypen im ER-Modell
Es ist aber nicht immer möglich, eine n-stellige Beziehung in mehrere binäre aufzuteilen. Angenommen der Kritiker Huber empfiehlt zur Speise Schnitzel den Wein Grüner
Veltliner und zum Henderl einen Eiswein, so entstehen folgende binäre Beziehungen:
• Huber – Schnitzel
• Huber – Henderl
• Schnitzel – Veltliner
• Henderl – Eiswein
Es geht aber Information verloren, dass Huber nur zum Schnitzel einen Veltliner
empfiehlt (Verlustlosigkeit ).
4.3.3. Kardinalität – Konnektivität
Neben der Anzahl der Entitäten ist auch die Anzahl der Instanzen entscheidend. So
kann für die hergestellt-aus-Beziehung festgelegt werden, dass ein Wein aus mindestens einer Rebsorte hergestellt werden muss, oder auf der Rechnung eines Kunden
mehrere Artikel enthalten sein dürfen, oder zu einem Mitarbeiter nur ein Foto gespeichert werden darf. Solche Kriterien werden als Kardinalität bezeichnet. Es gibt 3
Formen:
• 1 : 1-Beziehung: ein Mitarbeiter hat nur ein Foto, ein bestimmtes Foto gehört
nur zu einem Kunden.
25
4. Entity-Relationship-Modell
• 1 : N -Beziehung: eine Mutter kann mehrere Kinder haben, ein Kind hat jedoch
nur eine (biologische) Mutter.
• M : N -Beziehung: ein Autor kann mehrere Bücher schreiben, an einem Buch
können mehrere Autoren beteiligt sein.
Achtung!! Es kommt auf die richtige Fragestellung an. Eine falsche und für die Sache
nicht logische Fragestellung wäre:
Mehrere Autoren schreiben mehrere Bücher
Denn dieser Satz sagt nichts darüber aus, wie viele Bücher ein einzelner Autor
schreibt, bzw. wie viele Autoren an einem bestimmten Buch schreiben. Notationen
Für Kardinalitäten gibt es unterschiedliche Methoden der Darstellung.
Autor
[0, ∗]
schreibt
[1, 1]
Buch
(a) [min, max]-Notation bei 1 : N
Autor
1
schreibt
N
Buch
(b) Chen-Notation
Autor
schreibt
Buch
(c) Krähenfuß-Notation
Abbildung 4.10.: Notationen für Kardinalitäten
Von der Kardinalität wird oft die Konnektivität unterschieden, die die tatsächliche
Anzahl der beteiligten Entities angibt. Dies ist im ER-Modell insofern wichtig, da
daraus Informationen für Applikationen und Programme gewonnen werden. In einer
Datenbank ist es unmöglich, Konnektivität darzustellen, außer es werden sog. Trigger
eingesetzt. Beispiele für Konnektivität sind: In einer Firma betreut 1 Berater mindestens 1, maximal aber 3 Kunden, 1 Kunde wird von mindestens 1 Berater, maximal
aber von 3 beraten. Die Kardinalität ist hier M : N , die Konnektivität ist (1,5), bzw.
(1,3) – je nach Seite. üblicherweise wird nur im Chen-Modell die Konnektivität angegeben, und zwar in runden Klammern.
M : N -Beziehungen sind in relationalen Datenbanken nicht abbildbar, daher müssen
26
4.3. Eigenschaften von Beziehungen
diese in 1 : N -Beziehungen überführt werden.
schreibt
Autor
Autor
1
N
schreibt
Buch
N
1
Buch
Abbildung 4.11.: Abbildung M : N -Beziehung
4.3.4. Stärke der Beziehung
Von einer schwachen Beziehung spricht man, wenn zwei Entitäten voneinander unabhängig existieren können. Umgekehrt wird von einer starken Beziehung gesprochen,
wenn zwei Entitäten voneinander abhängig sind.
Beispiel für eine schwache Beziehung – unterstrichene Wörter markieren Primärschlüssel:
KUNDENKATEGORIE (KATEG ID, Bez)
KUNDE (KUND ID, KATEG ID, NAME, ADRESSE)
In der Tabelle KUNDE existiert ein Fremdschlüssel (KATEG ID), dieser ist jedoch
nicht Teil des Primärschlüssels, daher ist die Beziehung schwach.
Beispiel für eine starke Beziehung – unterstrichene Wörter markieren Primärschlüssel:
RECHNUNG (RECHNUNG ID, DATUM, KUNDE ID)
RECHNUNGPOSTEN (POS ID, RECHNUNG ID, ARTIKEL, ANZAHL, PREIS)
In der Tabelle RECHNUNGPOSTEN existiert ein Fremdschlüssel (RECHNUNG ID),
der zusätzlich Teil des Primärschlüssels ist. Daher liegt hier eine starke Beziehung vor.
Starke Beziehungen werden im Krähenfuß-Diagramm mit durchgezogenen Linien dargestellt, schwache mit strichlierten Linien.
4.3.5. Optionalität
Bei einer optionalen Beziehung ist die minimale Kardinalität 0, bei einer nicht-optionalen
mindestens 1. Optionale Beziehungen werden im Krähenfußmodell durch einen kleinen
27
4. Entity-Relationship-Modell
(a) schwache Beziehung
(b) starke Beziehung
Abbildung 4.12.: Notation für Stärke der Beziehung
Kreis auf der optionalen Seite gekennzeichnet, nicht-optionale durch einen senkrechten
Strich.
Autor
schreibt
Buch
Abbildung 4.13.: (Nicht)optionale Beziehung
Ein Autor muß nicht unbedingt ein Buch geschrieben haben, aber ein Buch ist ohne
Autor nicht denkbar.
4.3.6. Abhängige Entity-Typen, IST-Beziehung
Dieser Spezialfall tritt häufig auf, ein Beispiel ist die Beziehung Wein – Schaumwein.
Jeder Wein weist gewisse Eigenschafen auf (Jahrgang, Restsüße, Farbe), ein Spezialwein wie ein Schaumwein weist zusätzliche Eigenschaften (Art der Erzeugung, Gehalt
an CO2 , . . . ) auf, die die übrigen Weine nicht besitzen.
• Jeder Schaumwein ist ein Wein, aber
• nicht jeder Wein ist ein Schaumwein
Die Attribute von Wein werden aber zusätzlich an Schaumwein vererbt (und nicht
umgekehrt).
4.3.7. Redundante Beziehungen
Redundanzen sollten normalerweise vermieden werden. Gründe dafür sind:
28
4.3. Eigenschaften von Beziehungen
• mehrfache Eingabe der Daten nötig
• unnötig Speicherplatz
• Gefahr von Anomalien und inkonsistenten Daten
Folgendes Beispiel soll dies demonstrieren.
1 Kunde kann mehrere Aufträge tätigen, 1 Auftrag kann nur von 1 Kunden kommen.
1 Auftrag kann mehrere Artikel beinhalten, 1 Artikel kommt durchaus auf mehreren Aufträgen vor.
Artikel
Kunde
Auftrag
Abbildung 4.14.: zyklische Beziehung
Wenn die Beziehung zwischen Kunde und Artikel vom Typ bestellt ist, dann ist die
Beziehung redundant, da ja die Artikel über einen Auftrag kommen. Ist die Beziehung
jedoch vom Typ reklamiert, dann ist die Beziehung nicht redundant, da ja aus der
Bestellung nicht unmittelbar eine Stornierung folgt (zumindest nicht bei funktionierenden Firmen). Ob die Beziehung redundant ist, kann also nicht aus dem ER-Modell
abgeleitet werden, erst eine Analyse der Daten bringt Klarheit.
29
4. Entity-Relationship-Modell
Zusammenfassend eine Übersicht der Begriffe:
Begriff
Bedeutung
Entity
Objekt der Realität (Zinfandel, Jahrgang 2004, Alkohol 12%)
Entity-Typ
Gruppierung von Entities mit gleichen
Eigenschaften (Weine)
Beziehungstyp
Gruppierung von Beziehungen zwischen
Entities (Produzent erzeugt Wein)
Attribut
Eigenschaft einer Entity oder Beziehung (Name, Jahrgang, . . . )
Schlüssel
identifizierende Eigenschaft (Nummer)
Kardinalität
wie oft nimmt Entity an Beziehung teil
(1 : 1, 1 : N, M : N )
Konnektivität
wie viele Entities minimal/maximal beteiligt sind
Stärke
Entity abhängig (stark)/nicht abhängig
(schwach) von anderer Entity
Stelligkeit
Anzahl der beteiligten Entity-Typen
(binär, ternär)
abhängige Entities
z.B IST-Beziehung
Optionalität
ein Weinanbaugebiet kann oder muss in
einer Region liegen
Tabelle 4.1.: Begriffe des ER-Modells
4.4. Beispiel eines ER-Modells
Es soll eine Datenbank für eine Bibliothek erstellt werden. Dabei werden Daten über
Bücher erhoben, jedes Buch trägt einen Titel, eine Seitenanzahl, eine Kurzbeschreibung. Manche Bücher weisen eine ISBN auf, ältere nicht, dennoch soll jedes Buch
eindeutig identifiziert werden können.
Zusätzlich werden Daten über die Schriftsteller (Autoren) erhoben, diese haben einen
Vor- und Nachnamen, sowie ein Geburtsjahr.
Es werden noch Daten über Kunden gespeichert (Vor- und Nachnamen, sowie eine
Adresse).
Es gelten folgende Regeln: Ein Autor kann mehrere Bücher schreiben, ein Buch kann
30
4.4. Beispiel eines ER-Modells
auch von mehreren Autoren geschrieben werden (Beispiel Fachbücher). Ein Buch erscheint bei einem Verlag, ein Verlag kann aber mehrere Bücher herausbringen.
Ein Kunde kann mehrere Bücher ausleihen, dazu muss ein Datum vermerkt werden,
wann das Buch ausgeliehen wurde, wann es fällig ist und wann es zurückgebracht wurde.
Autoren, Verlage, Bücher und Kunden müssen eindeutig identifizierbar sein.
Verlag
VerlagNr
1
1 Verlag kann ein Buch herausbringen
2
1 Buch muss unbedingt von 1 Verlag sein
3
1 Autor kann 1 Buch schreiben
4
1 Buch muss unbedingt von 1 Autor sein
Name
1
2
Buch
BuchNr
Titel
Seiten
ISBN
Verleih
5
3
4
Autor
AutorNr
Name
Adresse
6
ausleihDat
retourDat
fällig
7
5
1 Verleih muss ein Buch haben
6
1 Buch kann auf einem Verleih sein
7
1 Kunde kann ein Buch ausleihen
8
1 Verleih muss einen Kunden haben
8
Kunde
KundenNr
Name
Adresse
Abbildung 4.15.: Beispiel ER-Modell
Verleih entsteht aus der Beziehung zwischen Buch und Kunde, da die Angaben wie
ausleihDat, fällig, retourDat weder Eigenschaften des Buches noch Eigenschaften des
Kunden sind.
Bei 1 : N -Beziehungen müssen noch in den Tabellen Fremdschlüssel als Attribute
eingetragen werden, damit zum Beispiel später festgestellt werden kann, welches Buch
von welchem Verlag herausgebracht wird. Nun ist hier die Frage wichtig, bei welcher
Tabelle ein Fremdschlüssel eingetragen wird. Das soll am Beispiel der Beziehung Verlag
– Buch mit Testdaten demonstriert werden. Zuerst wird in der Tabelle verlag ein
Fremdschlüssel (verweist auf Tabelle buch) eingetragen. Beide Bücher werden vom
selben Verlag herausgebracht.
31
4. Entity-Relationship-Modell
VerlagNr
Name
Ort
BuchNr
Titel
Seiten
ISBN
100
Suhrkamp
Stuttgart
1
1
Gehen
150
978-3-12
200
Fischer
Berlin
3
2
Frost
200
978-3-13
100
Suhrkamp
Stuttgart
2
3
Der Prozess
120
978-3-14
BuchNr
Tabelle 4.2.: Verlag
Tabelle 4.3.: Buch
Da der Verlag Suhrkamp hier zwei Bücher herausgebracht hat, muss für jedes Buch
eine Zeile in der Tabelle Verlag eingezogen werden. Sofort ist hier erkennbar, dass einerseits gewisse Werte redundant vorliegen (VerlagNr, Name, Ort) – hier rot gekennzeichnet, andererseits wäre auch die Voraussetzung für einen Primärschlüssel (Einmaligkeit)
nicht mehr gegeben (VerlagNr 100 wäre doppelt). Redundante Werte führen zu Anomalien. Daher wäre es falsch, in der Tabelle Verlag den Fremdschlüssel einzutragen.
Nun der Versuch, in der Tabelle Buch den Fremdschlüssel (Verweis auf Tabelle verlag)
einzutragen.
VerlagNr
Name
Ort
100
Suhrkamp
Stuttgart
200
Fischer
Berlin
BuchNr
Titel
Seiten
ISBN
1
Gehen
150
978-3-12
100
2
Frost
200
978-3-13
100
3
Der Prozess
120
978-3-14
200
Tabelle 4.4.: Verlag
VerlagNr
Tabelle 4.5.: Buch
Hier sind keine redundanten Werte vorhanden, somit ist das Schema akzeptabel.
Bei M : N -Beziehungen müsste man auf einer der beiden Tabellen Fremdschlüssel
eintragen, hätte somit auf jeden Fall redundante Werte, daher wird hier ein anderes
Schema angewendet – es wird eine Zwischentabelle eingezogen.
BuchNr
Titel
Seiten
100
SQL
120
200
PHP
200
Tabelle 4.6.: Buch
BuchNr
AutorNr
AutorNr
Name
100
1
1
Huber
100
2
2
Meier
200
2
3
Dorfer
Tabelle 4.7.: Autor Buch
Tabelle 4.8.: Autor
Dies Zwischentabelle besteht aus mindestens 2 Spalten, sie besitzt einen kombinierten (hier 2-spaltigen) Primärschlüssel – sowohl BuchNr alleine als auch AutorNr alleine
32
4.4. Beispiel eines ER-Modells
wären nicht primärschlüsselfähig. Jede Spalte für sich ist ein Fremdschlüssel auf eine
andere Tabelle (BuchNr verweist auf Tabelle Buch und AutorNr verweist auf Tabelle
Autor).
Verlag
VerlagNr
Name
Buch
BuchNr
Titel
Seiten
ISBN
VerlagNr
Verleih Buch
Kunde fällig
BuchNr
FID
FID
fällig
retourDat
ausleihDat
KundenNr
Autor Buch
BuchNr
AutorNr
Kunde
KundenNr
Name
Adresse
Autor
AutorNr
Name
Adresse
Abbildung 4.16.: Beispiel fertiges ER-Modell
Die beiden Tabellen Verleih Buch und Kunde fällig sind am ehesten aus Dummydaten ersichtlich. Wenn man davon ausgeht, dass ein Kunde mit einer Ausleihaktion
mehrere Bücher ausleihen kann und jedes Buch zu einem anderen Zeitpunkt zurückbringen kann, dann ergibt sich zuerst diese Tabelle:
33
4. Entity-Relationship-Modell
ID
KdNr
BuchNr
ausleihDat
fällig
1
1
100
1.1
10.1
1
1
200
1.1
10.1
2
2
300
1.1
10.1
3
1
100
11.1
20.1
retourDat
Tabelle 4.9.: Ausleihtabelle
Hier fällt auf, dass zum Beispiel bei ID 1 die Spalten ID, KdNr, ausleihDat und
fällig redundant vorkommen, daher ergibt sich folgendes Bild – unter Aufspaltung der
redundanten Werte in eine neue Tabelle.
FID
KdNr
fällig
ausleihDat
1
FID
BuchNr
retourDat
1
10.1
1.1
1
100
9.1
2
2
10.1
1.1
1
200
3
1
20.1
1.1
3
100
Tabelle 4.10.: Kunde fällig
Tabelle 4.11.: Verleih Buch
Kunde fällig erhält einen einspaltigen Primärschlüssel (FID) und Verleih Dat einen
2-spaltigen, bestehend aus FID und BuchNr.
34
Index
Symbols
1:1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A
ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Applikationsserver . . . . . . . . . . . . . . . . . 12
atomar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Attribut . . . . . . . . . . . . . . . . . . . . . . . . 11, 20
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B
Baumstruktur . . . . . . . . . . . . . . . . . . . . . . 15
Beziehung
1:1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Kardinalität . . . . . . . . . . . . . . . . . . . 23
M:N . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Optionalität . . . . . . . . . . . . . . . . . . . 23
rekursiv . . . . . . . . . . . . . . . . . . . . . . . 22
schwache . . . . . . . . . . . . . . . . . . . . . . 26
starke . . . . . . . . . . . . . . . . . . . . . . . . . 26
Stelligkeit . . . . . . . . . . . . . . . . . . . . . 23
Beziehungstypen . . . . . . . . . . . . . . . . . . . 20
C
C ++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
C/C ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Client-Server . . . . . . . . . . . . . . . . . . . . . . . 12
D
Data Dictionary . . . . . . . . . . . . . . . . . . . . . 9
Dateiverwaltungssystem . . . . . . . . . . . . . 8
Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Datenbankmanagementsystem . . . 8, 10
Datenbanksystem. . . . . . . . . . . . . . . .8, 10
Datenredundanz . . . . . . . . . . . . . . . . . . . . 7
Datentyp . . . . . . . . . . . . . . . . . . . . . . . . . . 20
char . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
date . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
integer, int . . . . . . . . . . . . . . . . . . . . 20
Datenunabhängigkeit . . . . . . . 8 f., 11, 15
dauerhaft . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
DB, Datenbank . . . . . . . . . . . . . . . . . . . . 10
DB2, Informix . . . . . . . . . . . . . . . . . . . . . 12
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Drei-Ebenen-Architektur . . . . . . . . . . . 12
Dreischichtensysteme . . . . . . . . . . . . . . .12
E
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 f.
Entitytypen . . . . . . . . . . . . . . . . . . . 20
Entity-Typ . . . . . . . . . . . . . . . . . . . . . . . . .20
Entity-Typen . . . . . . . . . . . . . . . . . . . . . . 20
ER-Diagramm . . . . . . . . . . . . . . . . . . . . . 20
ER-Modell . . . . . . . . . . . . . . . . . . . . . . . . . 19
externe Ebene. . . . . . . . . . . . . . . . . . . . . .11
H
Hierarchische Datenbanken . . . . . . . . . 15
Hierarchisches Modell . . . . . . . . . . . . . . 15
I
Informationen . . . . . . . . . . . . . . . . . . . . . . 19
Inkonsistenz . . . . . . . . . . . . . . . . . . . . . . . . . 7
Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Integrität . . . . . . . . . . . . . . . . . . . . . . . . 9, 19
interne Ebene . . . . . . . . . . . . . . . . . . . . . . 11
ISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
isoliert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IST-Beziehung . . . . . . . . . . . . . . . . . . . . . 27
J
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . .12, 16
K
Kardinalität . . . . . . . . . . . . . . . . . . . . . . 23 f.
Katalog, Data Dictionary . . . . . . . . . . . 9
35
Index
Konnektivität . . . . . . . . . . . . . . . . . . . . 24 f.
konsistent . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . 9
konzeptuelle Ebene. . . . . . . . . . . . . . . . .11
L
referentielle Integrität . . . . . . . . . . . . . . 19
Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Relationale DBS . . . . . . . . . . . . . . . . . . . 16
Relationenmodell . . . . . . . . . . . . 8, 11, 19
Relationenschema . . . . . . . . . . . . . . . . . . 11
Relationship . . . . . . . . . . . . . . . . . . . . . . . 20
LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
S
M
Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
künstliche Schlüssel . . . . . . . . . . . . 22
Kandidaten. . . . . . . . . . . . . . . . . . . .22
natürliche Schlüssel . . . . . . . . . . . . 22
Primärschlüssel . . . . . . . . . . . . . . . . 22
Schlüsselattribute . . . . . . . . . . . . . 22
Schlüsselbedingung . . . . . . . . . . . . 19
Sichten, views . . . . . . . . . . . . . . . . . . . . . . . 9
Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . 16
sperren, Sperre . . . . . . . . . . . . . . . . . . . . . . 8
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SQL Server, Microsoft. . . . . . . . . . . . . .12
Stelligkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 23
M:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Microsoft, SQL SERVER. . . . . . . . . . .12
Middleware . . . . . . . . . . . . . . . . . . . . . . . . 13
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
MySQL Query Browser . . . . . . . . . . . . 12
MySQL, SUN . . . . . . . . . . . . . . . . . . . . . . 12
N
Netzwerkmodell . . . . . . . . . . . . . . . . . . . . 15
Non-First-Normal-Form, NF2 . . . . . . 19
O
Objekt
Objekttyp . . . . . . . . . . . . . . . . . . . . . 20
schwacher Objekttyp . . . . . . . . . . 21
Objektorientierte DBS . . . . . . . . . . . . . 16
ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Open Source . . . . . . . . . . . . . . . . . . . . . . . 12
Optionalität . . . . . . . . . . . . . . . . . . . . 23, 26
Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
T
Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Transaktionen . . . . . . . . . . . . . . . . . . . . . . . 9
Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Tupel . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 20
U
UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
P
V
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
PHPMyAdmin . . . . . . . . . . . . . . . . . . . . . 12
PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . 12
Primärschlüssel . . . . . . . . . . . . . . . . . . . . 22
Primary Key . . . . . . . . . . . . . . . . . . . . . . . 22
Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . 27
Verlustlosigkeit. . . . . . . . . . . . . . . . . . . . .24
Z
Zweischichtensystem . . . . . . . . . . . . . . . 12
R
Rechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 f.
redundant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
redundant, nicht-redundant . . . . . . . . . 9
36