Relationale Datenbanksysteme

Werbung
MultiAugustinum
E2A/E3A
SQL
Relationale Datenbanksysteme
Mag. Christian Gürtler
2009
Inhaltsverzeichnis
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 über Artikel und Adressen.
• Die Auftragsverwaltung bearbeitet Daten über Aufträ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 unnötig belegtem Speicherplatz und andererseits (was noch
gravierender ist) zu Dateninkonsistenzen: ändert die Kundenbetreuung die Daten eines Kunden – zum Beispiel von Herrn Müller, dann müssen auch die Buchhaltung und
die Auftragsverwaltung ihre Daten ändern. Geschieht dies nicht, so haben alle Abteilungen unterschiedliche Datensätze, also inkonsistente Daten. Der Müller aus der
Kundenbetreuung ist nicht mehr der Kunde Müller aus der Auftragsverwaltung.
7
1 Vergleich Datenbankysteme – Dateisystem
Weitere Problemfelder
Um diese Daten zu verwalten, werden in den Betrieben oft zusätzlich spezielle Anwendungsprogramme entwickelt. Die Entwickler solcher Programme müssen jedoch
wissen, wie die Daten intern gespeichert werden (um die Daten in einem speziellen
Format zu speichern). Dieser Punkt wird als fehlende Datenunabhängigkeit bezeichnet.
Ein weiterer Punkt der Speicherung von Daten in einem Dateisystem betrifft fehlende Zugriffskontrolle und Datensicherheit. Meist können in einem Dateisystem die
Rechte nur bis auf Dateiebene vergeben werden, nicht jedoch auf einzelne Inhalte einer Datei. Zusätzlich existieren kaum Möglichkeiten, Dateien so zu sperren, dass sich
mehrere Benutzer beim Bearbeiten nicht gegenseitig behindern bzw. Daten gegenseitig
überschreiben (was zu Datenverlust führen kann).
Ende der 1960er-Jahre wurden Dateiverwaltungssysteme eingefü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 Geräteunabhängigkeit erreicht, die Daten
waren aber immer noch redundant gespeichert.
Die Lö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 kü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 können gleichzeitig (parallel) auf die Daten zugreifen. Transaktionen verhindern unerwünschte Nebeneffekte. Konkurrierende Transaktionen
müssen synchronisiert werden (greifen mehrere Transaktionen auf einen Datensatz zu, so müssen sie aufeinander abgestimmt werden). 1
• Datenunabhängigkeit gewährleistet die Unabhängigkeit der Programme von den
Daten und umgekehrt. Wie die Daten organisiert bzw. gespeichert werden spielt
für ein Programm keine Rolle; ein bestimmtes Programm oder eine Applikation
darf wiederum die Organisation der Daten nicht beeinflussen.
• Datenbanksysteme gewährleisten feiner abgestimmte Zugriffskontrollen und Rechte. Sichten (eingeschränkte Sicht auf die Daten) und Rechte auf einzelne Datensätze (Zeilen) sind möglich (views).
• Ein Datenbanksystem bietet Operationen zum Suchen, Ändern und Anlegen von
Datensätzen. Dazu sind deskriptive Sprachen vorhanden.
• Ein Katalog, auch Data Dictionary genannt, ermöglicht Zugriffe auf die Beschreibungen (Metadaten) der Daten und Datenbanken (um zum Beispiel zu erfahren,
wer einen bestimmten Datensatz angelegt oder geändert hat, oder welche Tabellen eine bestimmte Datenbank besitzt).
• Das Datenbanksystem gewährleistet die Datenintegrität (Konsistenz).
• Datensicherung muss die Wiederherstellung von Daten nach Fehlern gewährleisten.
1 Unter
einer Transaktion versteht man eine Zusammenfassung von Datenbankprozessen, die als
gesamtes (atomar) ausgefü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 üblich.
Folgende Tabelle erläutert die Unterschiede:
Kürzel
Begriff
Erlä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 gewä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 kümmert.
Dieses Schema gewährleistet einen wichtigen Punkt, nämlich den der Datenunabhängigkeit mit ihren zwei Teilaspekten (Implementierungsunabhängigkeit, physische Datenunabhängigkeit – wie die Daten gespeichert werden, ist für die Sicht auf die Daten egal –
und Anwendungsunabhängigkeit, logische Unabhängigkeit – Änderungen auf eine Anwendung dürfen sich nicht auf die Daten auswirken).
Modell fü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 Einträge in der Tabelle werden
als Relation zu diesem Schema bezeichnet. Ein Tupel bezeichnet eine Zeile in einer
Tabelle. Die Spaltenü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
Müller
Relationenschema
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 (läuft nur auf Microsoft-Servern) gibt es für die oben
genannten Datenbanksysteme Versionen für die gängigsten Betriebssysteme (Windows,
UNIX, Linux). Aus der Sicht einer Anwendung ist ein DBMS ein Client-Server-System.
Der Client läuft meist auf einem PC (Mysql-Query-Browser, PHPMyAdmin, . . . ), der
eine Anfrage an den Server stellt. Dieser nimmt die Anfrage auf, führt eine Bearbeitung
durch und gibt die Ergebnisse dem Client zurü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. 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 müssen in
12
2.1 Konkrete Architekturen
sämtlichen Anwendungsprogrammen die Schnittstellen geändert werden (Risiko, Zeitaufwand). Um diese Probleme zu umgehen, wurden sog. Middleware-Lösungen wie
CORBA oder ODBC entwickelt. Diese zusätzliche Schicht enthält nur die Information
(Treiber) über die darunterliegende Datenbank, das Anwendungsprogramm braucht
sich darum nicht zu kümmern. Ä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, Ästen (vertikal) und
Blättern (horizontal) gespeichert.
Firma
Vorstand
Mü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 zusätzlichem Aufwand (virtuelle Zeiger) darstellbar. Ein
ähnliches System existiert in LDAP, einem modernen plattformü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 Datenunabhängigkeit; als Programmiersprache ist weitgehend COBOL und keine eigene Abfragesprache wie SQL im Einsatz. Diese Datenbanken werden hauptsächlich noch auf
15
3 Arten von Datenbanksystemen
Großsrechnern eingesetzt. Der Datenbestand besteht hier aus netzwerkartig verketteten Datensä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 hauptsä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 Schüler mit ihrem Namen, Geburtsdatum und Noten,
Informationen werden daraus gewonnen (Notendurchschnitt, Alter). Um ein Modell
zu entwickeln, sind Informationen über
1. statische Eigenschaften von Objekten und Beziehungen,
2. dynamische Eigenschaften wie Operationen und Beziehungen zwischen Operationen,
3. Integritätsbedingungen von Objekten und Operationen
zu sammeln. Objekte sind zum Beispiel Artikel mit statischen Eigenschaften Bezeichnung, Preis etc. Beziehungen wären beispielsweise: 1 Erzeugern produziert einen Artikel, oder Schüler x geht in die Klasse y.
Dynamische Eigenschaften (Operationen) wären die Berechnung des Endpreises mit
Skonto. Eine Beziehung zwischen Operationen könnte sein, dass ein Artikel erst dann
bestellt werden darf, wenn er produziert wurde, oder ein Schüler erst dann in den
Aufbaulehrgang kommen darf, wenn er eine Fachschule absolviert hat.
Integritätsbedingungen legen zum Beispiel fest, dass ein Artikel eine eindeutige Nummer aufweisen muss (Schlüsselbedingung) und dass es zu jedem Artikel einen Erzeuger
geben muss (referentielle Integrität).
Im Relationenmodell sind sie Daten in ungeschachtelten Tabellen gespeichert (SQLDatenbanken), die Beziehungen werden durch Wertevergleich ausgedrü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 dürfen, sonst dü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 für einen Entwurf einer Datenbank
unerläß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 zurück auf eine Arbeit von P. P. Chen im Jahre 1976 und ist
heute faktisch Standard bei der Datenbankentwicklung. Zum ER-Modell gehört eine
grafische Notation (ER-Diagramm oder ERD , die die Datenbank mit ihren Daten und
Beziehungen abstrakt darstellt.
Zum ER-Modell gehören drei Begriffe:
1. Entity: ein Objekt aus der reellen Welt (Artikel, Kunden, Lieferanten,. . . ).
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 können, sind entsprechende Datentypen notwendig
(integer für ganze Zahlen, date für Datumswerte, char für Strings, . . . )
Entity-Typen
Entities sind Einheiten, in denen Objekte mit gleichen 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 für jede Ausprägung modelliert, sondern
zu Beziehungstypen zusammengefasst, also nicht, dass Artikel Feinkristallzucker von
der Firma Agrana stammt, sondern dass ein Artikel von einem Produzenten erzeugt
wird. Beziehungstypen werden als Raute dargestellt. Die Beziehungen können Zweistellig (binär) oder n-stellig sein:
20
4.2 Grundlagen des Entity-Relationship-Modells (ER-Modell)
(a) binä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.
Preis
Nummer
Artikel
Bezeichnung
Abbildung 4.3: Attributnotation eines Entity-Typs
Neben Entities können auch Beziehungen Attribute aufweisen.
Anteil
Wein
hergestellt aus
Rebsorte
Abbildung 4.4: Attributnotation für Beziehungen
21
4 Entity-Relationship-Modell
In dieser Abbildung ist die Beziehung zweier Tabellen (Entities) dargestellt, das
Attribut Anteil ist weder der Entity Wein noch der Entity Rebsorte zugeordnet.
Identifizierung durch Schlüssel
Für jede Entity gibt es den Effekt, dass einige Attribute mit ihren Werten fü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 Schlü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 künstliches Merkmal (interne Nummer)
eindeutig gekennzeichnet werden. Aus diesen Kandidaten wird einer gewählt, dieser
wird dann der sog. Primärschlüssel .
4.3 Eigenschaften von Beziehungen
Beziehungen lassen sich durch zwei Eigenschaften charakterisieren:
• die Stelligkeit gibt an, wie viele Entities an einer Beziehung beteiligt sind
• die Kardinalität gibt an, wie viele Instanzen eines Entity-Typs an einer Beziehung
beteiligt sind.
4.3.1 Stelligkeit
Sie beschreibt die Anzahl der beteiligten Entities. Die Mehrzahl der Beziehungen ist
zweistellig (binär), es gibt aber auch ternäre (dreistellige) und n-stellige Beziehungen.
Dazu folgendes Beispiel:
(a) ternärer Beziehungstyp
Wein
empfiehlt
Speise
Kritiker
(b) Drei binäre Beziehungstypen
Kritiker
K-S
K-W
Speise
Wein
S-W
Abbildung 4.5: Beziehungstypen im ER-Modell
22
4.3 Eigenschaften von Beziehungen
Es ist aber nicht immer möglich, eine n-stellige Beziehung in mehrere binäre aufzuteilen. Angenommen der Kritiker Huber empfiehlt zur Speise Schnitzel den Wein Grüner
Veltliner und zum Henderl einen Eiswein, so entstehen folgende binä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.2 Kardinalität – Konnektivität
Neben der Anzahl der Entitäten ist auch die Anzahl der Instanzen entscheidend. So
kann fü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 dürfen, oder zu einem Mitarbeiter nur ein Foto gespeichert werden darf. Solche Kriterien werden als Kardinalität bezeichnet. Es gibt 3
Formen:
• 1 : 1-Beziehung: ein Mitarbeiter hat nur ein Foto, ein bestimmtes Foto gehört
nur zu einem Kunden.
• 1 : N -Beziehung: eine Mutter kann mehrere Kinder haben, ein Kind hat jedoch
nur eine (biologische) Mutter.
• M : N -Beziehung: ein Autor kann mehrere Bücher schreiben, an einem Buch
können mehrere Autoren beteiligt sein.
Achtung!! Es kommt auf die richtige Fragestellung an. Eine falsche und für die Sache
nicht logische Fragestellung wäre:
Mehrere Autoren schreiben mehrere Bücher
Denn dieser Satz sagt nichts darüber aus, wie viele Bücher ein einzelner Autor
schreibt, bzw. wie viele Autoren an einem bestimmten Buch schreiben. Notationen
Für Kardinalitäten gibt es unterschiedliche Methoden der Darstellung.
23
4 Entity-Relationship-Modell
Autor
[0, ∗]
[1, 1]
schreibt
Buch
(a) [min, max]-Notation bei 1 : N
Autor
1
N
schreibt
Buch
(b) Chen-Notation
schreibt
Autor
Buch
(c) Krähenfuß-Notation
Abbildung 4.6: Notationen für Kardinalitäten
Von der Kardinalität wird oft die Konnektivität unterschieden, die die tatsächliche
Anzahl der beteiligten Entities angibt. Dies ist im ER-Modell insofern wichtig, da
daraus Informationen für Applikationen und Programme gewonnen werden. In einer
Datenbank ist es unmöglich, Konnektivität darzustellen, außer es werden sog. Trigger
eingesetzt. Beispiele für Konnektivitä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 Kardinalität ist hier M : N , die Konnektivität ist (1,5), bzw.
(1,3) – je nach Seite. Üblicherweise wird nur im Chen-Modell die Konnektivität angegeben, und zwar in runden Klammern.
M : N -Beziehungen sind in relationalen Datenbanken nicht abbildbar, daher müssen
diese in 1 : N -Beziehungen überführt werden.
schreibt
Autor
Autor
1
N
schreibt
Buch
N
1
Buch
Abbildung 4.7: Abbildung M : N -Beziehung
24
4.3 Eigenschaften von Beziehungen
4.3.3 Stärke der Beziehung
Von einer schwachen Beziehung spricht man, wenn zwei Entitäten voneinander unabhängig existieren können. Umgekehrt wird von einer starken Beziehung gesprochen,
wenn zwei Entitäten voneinander abhängig sind.
Beispiel für eine schwache Beziehung – unterstrichene Wörter markieren Primärschlüssel:
KUNDENKATEGORIE (KATEG ID, Bez)
KUNDE (KUND ID, KATEG ID, NAME, ADRESSE)
In der Tabelle KUNDE existiert ein Fremdschlüssel (KATEG ID), dieser ist jedoch
nicht Teil des Primärschlüssels, daher ist die Beziehung schwach.
Beispiel für eine starke Beziehung – unterstrichene Wörter markieren Primärschlüssel:
RECHNUNG (RECHNUNG ID, DATUM, KUNDE ID)
RECHNUNGPOSTEN (POS ID, RECHNUNG ID, ARTIKEL, ANZAHL, PREIS)
In der Tabelle RECHNUNGPOSTEN existiert ein Fremdschlüssel (RECHNUNG ID),
der zusätzlich Teil des Primärschlüssels ist. Daher liegt hier eine starke Beziehung vor.
Starke Beziehungen werden im Krähenfuß-Diagramm mit durchgezogenen Linien dargestellt, schwache mit strichlierten Linien.
(a) schwache Beziehung
(b) starke Beziehung
Abbildung 4.8: Notation für Stärke der Beziehung
4.3.4 Optionalität
Bei einer optionalen Beziehung ist die minimale Kardinalität 0, bei einer nicht-optionalen
mindestens 1. Optionale Beziehungen werden im Krähenfußmodell durch einen kleinen
Kreis auf der optionalen Seite gekennzeichnet, nicht-optionale durch einen senkrechten
Strich.
25
4 Entity-Relationship-Modell
Autor
schreibt
Buch
Abbildung 4.9: (Nicht)optionale Beziehung
Ein Autor muß nicht unbedingt ein Buch geschrieben haben, aber ein Buch ist ohne
Autor nicht denkbar.
4.3.5 Abhängige Entity-Typen, IST-Beziehung
Dieser Spezialfall tritt häufig auf, ein Beispiel ist die Beziehung Wein – Schaumwein.
Jeder Wein weist gewisse Eigenschafen auf (Jahrgang, Restsüße, Farbe), ein Spezialwein wie ein Schaumwein weist zusätzliche Eigenschaften (Art der Erzeugung, Gehalt
an CO2 , . . . ) auf, die die übrigen Weine nicht besitzen.
• Jeder Schaumwein ist ein Wein, aber
• nicht jeder Wein ist ein Schaumwein
Die Attribute von Wein werden aber zusätzlich an Schaumwein vererbt (und nicht
umgekehrt).
26
4.3 Eigenschaften von Beziehungen
Zusammenfassend eine Übersicht der Begriffe:
Begriff
Bedeutung
Entity
Objekt der Realitä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, . . . )
Schlüssel
identifizierende Eigenschaft (Nummer)
Kardinalität
wie oft nimmt Entity an Beziehung teil
(1 : 1, 1 : N, M : N )
Konnektivität
wie viele Entities minimal/maximal beteiligt sind
Stärke
Entity abhängig (stark)/nicht abhängig
(schwach) von anderer Entity
Stelligkeit
Anzahl der beteiligten Entity-Typen
(binär, ternär)
abhängige Entities
z.B IST-Beziehung
Optionalität
ein Weinanbaugebiet kann oder muss in
einer Region liegen
Tabelle 4.1: Begriffe des ER-Modells
27
Teil III
SQL-Abfragen
29
Index
1:1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
DB2, Informix . . . . . . . . . . . . . . . . . . . . . 12
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Drei-Ebenen-Architektur . . . . . . . . . . . 12
Dreischichtensysteme . . . . . . . . . . . . . . .12
A
E
ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Applikationsserver . . . . . . . . . . . . . . . . . 12
atomar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Attribut . . . . . . . . . . . . . . . . . . . . . . . . 11, 20
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 f.
Entity-Typ . . . . . . . . . . . . . . . . . . . . . . . . .20
ER-Diagramm . . . . . . . . . . . . . . . . . . . . . 20
ER-Modell . . . . . . . . . . . . . . . . . . . . . . . . . 19
externe Ebene. . . . . . . . . . . . . . . . . . . . . .11
Symbols
H
B
Baumstruktur . . . . . . . . . . . . . . . . . . . . . . 15
Beziehung
1:1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
M:N . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
schwache . . . . . . . . . . . . . . . . . . . . . . 24
starke . . . . . . . . . . . . . . . . . . . . . . . . . 24
Beziehungstypen . . . . . . . . . . . . . . . . . . . 20
C
C ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
C/C ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Client-Server . . . . . . . . . . . . . . . . . . . . . . . 12
Hierarchische Datenbanken . . . . . . . . . 15
Hierarchisches Modell . . . . . . . . . . . . . . 15
I
Informationen . . . . . . . . . . . . . . . . . . . . . . 19
Inkonsistenz . . . . . . . . . . . . . . . . . . . . . . . . . 7
Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . 19
interne Ebene . . . . . . . . . . . . . . . . . . . . . . 11
ISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
isoliert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IST-Beziehung . . . . . . . . . . . . . . . . . . . . . 25
J
D
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . .12, 16
Data Dictionary . . . . . . . . . . . . . . . . . . . . . 9
Dateiverwaltungssystem . . . . . . . . . . . . . 8
Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Datenbankmanagementsystem . . . 8, 10
Datenbanksystem. . . . . . . . . . . . . . . .8, 10
Datenredundanz . . . . . . . . . . . . . . . . . . . . 7
Datentyp . . . . . . . . . . . . . . . . . . . . . . . . . . 20
char . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
date . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
integer, int . . . . . . . . . . . . . . . . . . . . 20
dauerhaft . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
DB, Datenbank . . . . . . . . . . . . . . . . . . . . 10
K
Kandidaten . . . . . . . . . . . . . . . . . . . . . . . . 22
Kardinalität . . . . . . . . . . . . . . . . . . . . . . . 22
Katalog, Data Dictionary . . . . . . . . . . . 9
Konnektivität . . . . . . . . . . . . . . . . . . . . . . 24
konsistent . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . 9
konzeptuelle Ebene. . . . . . . . . . . . . . . . .11
L
LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
31
Index
M
M:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Microsoft, SQL SERVER. . . . . . . . . . .12
Middleware . . . . . . . . . . . . . . . . . . . . . . . . 13
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
MySQL Query Browser . . . . . . . . . . . . 12
MySQL, SUN . . . . . . . . . . . . . . . . . . . . . . 12
N
Netzwerkmodell . . . . . . . . . . . . . . . . . . . . 15
Non-First-Normal-Form, NF2 . . . . . . 19
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SQL Server, Microsoft. . . . . . . . . . . . . .12
Stelligkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 22
T
Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Transaktionen . . . . . . . . . . . . . . . . . . . . . . . 9
Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Tupel . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 20
U
UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
O
V
Objektorientierte DBS . . . . . . . . . . . . . 16
ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Open Source . . . . . . . . . . . . . . . . . . . . . . . 12
Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
P
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
PHPMyAdmin . . . . . . . . . . . . . . . . . . . . . 12
PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . 12
Primärschlüssel . . . . . . . . . . . . . . . . . . . . 22
Primary Key . . . . . . . . . . . . . . . . . . . . . . . 22
R
Rechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 f.
redundant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
redundant, nicht-redundant . . . . . . . . . 9
referentielle Integrität . . . . . . . . . . . . . . 19
Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Relationale DBS . . . . . . . . . . . . . . . . . . . 16
Relationenmodell . . . . . . . . . . . . 8, 11, 19
Relationenschema . . . . . . . . . . . . . . . . . . 11
Relationship . . . . . . . . . . . . . . . . . . . . . . . 20
S
Schlüssel, Schlüsselbedingung . . . . . . 19
Sichten, views . . . . . . . . . . . . . . . . . . . . . . . 9
Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . 16
sperren, Sperre . . . . . . . . . . . . . . . . . . . . . . 8
32
Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . 25
Verlustlosigkeit. . . . . . . . . . . . . . . . . . . . .23
Z
Zweischichtensystem . . . . . . . . . . . . . . . 12
Herunterladen