Zusammenfassung Datenbanksysteme I

Zusammenfassung Datenbanksysteme I
Prof. Küspert, Zusammenfassung Fabian Stutzki
20. Juli 2008
Diese Zusammenfassung umfasst die Vorlesung Datenbanksysteme I und II (2007/2008).
Bei Fehlern bitte ich um Korrekturhinweise.
Inhaltsverzeichnis
1 Datenverwaltung mit Dateisytemen
5
1.1
Sequentielle Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2
Indexsequentielle Datei
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
Hash-Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4
Probleme der Datenverwaltung in Dateien
5
. . . . . . . . . . . . . . . . . . .
2 Funktionalität von Datenbanksystemen
6
2.1
Grundlegende Anforderung
2.2
Datenbank / Datenbanksystem / Datenbankmanagementsystem
2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . .
6
. . . . . . .
7
2.2.1
Datenbanksystem-Betriebsmodi . . . . . . . . . . . . . . . . . . . . .
7
2.2.2
Datenintegrität
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.1
ANSI/SPARC - 3 Ebenen . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.2
DIAM - 4 Ebenen
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.3
5 Schichten 51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Datenbank-Architekturen
3 Datenmodellierung im Entity-Relationship-Modell (ERM)
8
3.1
Entity / Entitytyp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3
Beziehungen / Beziehungstypen . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
ER-Diagramme
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
9
10
3.4.1
Kardinalität / Komplexität
3.4.2
schwache Entitytypen . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4.3
Erweiterungen für Attributen
10
. . . . . . . . . . . . . . . . . . . . . .
10
3.4.4
Spezialisierung und Generalisierung . . . . . . . . . . . . . . . . . . .
11
3.4.5
Attribute und Beziehungstypen als Entitytypen . . . . . . . . . . . . .
11
1
4 Hierarchisches Datenmodell
4.1
Eigenschaften / Beziehungen
4.1.1
4.2
4.3
11
. . . . . . . . . . . . . . . . . . . . . . . . . .
12
virtuelle Entitytypen . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Bemerkungen zum HDM
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
IMS als Beispiel für ein HDM . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.3.1
IMS-Notation und -Terminologie
13
4.3.2
Database Denition Language (DDL)
4.3.3
Data Language / One (DL/1)
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . .
13
5 Netzwerk-Datenmodell
5.1
5.2
Set-Typen
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vom ER-Modell zum NDM
5.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
14
14
5.2.2
Rekursive 1:n Beziehungen
5.2.3
Nichtrekursive n:m Beziehungen
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
14
5.2.4
Rekursive n:m Beziehungen . . . . . . . . . . . . . . . . . . . . . . .
15
5.2.5
Mehrstellige Beziehungstypen . . . . . . . . . . . . . . . . . . . . . .
15
Grundsätzliche Eigenschaften des NDM (Vergleich zum HDM)
5.4
Beispielschema eines NDM
. . . . . . . .
15
. . . . . . . . . . . . . . . . . . . . . . . . . . .
16
6 Relationales Datenmodell
6.2
6.3
. . . . . . . . . . . . . .
17
6.1.1
Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
6.1.2
Vom ER-Modell zum relationalen Modell . . . . . . . . . . . . . . . .
17
Sprachen für das relationale Modell: Relationenalgebra und Relationenkalkül
Relationenalgebra
6.3.6
6.3.7
Zusammengesetzte Beispiele in Relationenalgebra
6.3.3
6.3.4
6.3.5
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
P JAttr R oder πAttr R . .
Selektion: SLF R oder δF R . . . . .
Verbund (Join): R JNF S . . . . . .
Vereinigung (Union): R U N S
. . .
Durchschnitt (Intersection): R IN S
Dierenz: R DF S . . . . . . . . . .
6.3.2
6.5
16
Begrie und Eigenschaften des relationalen Modells
6.3.1
6.4
14
Nichtrekursive 1:n Beziehungen . . . . . . . . . . . . . . . . . . . . .
5.3
6.1
12
Projektion:
18
19
. . . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . . .
20
. . . . . . . . . . .
20
Relationenkalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
6.4.1
. . . . . . . . . . . . . . . . . . . . . .
21
. . . . . . . . . . . . . . . . . . . . . . .
21
6.5.1
Create Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
6.5.2
Create Domain
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6.5.3
Alter Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6.5.4
Drop Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6.5.5
Create / Drop Index . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Beispiele im Relationenkalkül
Structured Query Language (SQL)
6.5.6
Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6.5.7
Delete
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6.5.8
Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2
6.5.9
Select from where . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
6.5.10 Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
6.5.11 Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
6.5.12 Zugrisrechte
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Transaktionen / Fehlerbehandlung
23
7.1
ACID-Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
7.2
Fehlerszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
Bemerkungen
24
7.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1
Checkpoints
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
7.3.2
Dirty Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
7.3.3
Page Cleaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
7.3.4
Steal / No Steal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
7.3.5
Write-Ahead Logging
. . . . . . . . . . . . . . . . . . . . . . . . . .
25
7.3.6
Group Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
7.3.7
Datenvolumen der Log-Dateien . . . . . . . . . . . . . . . . . . . . .
25
7.3.8
Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
7.3.9
Force / No Force
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
7.3.10 Atomic / Not Atomic . . . . . . . . . . . . . . . . . . . . . . . . . .
26
8 Synchronisation im Mehrbenutzerbetrieb
26
8.1
Fehlerklassen und Probleme bei unkontrolliertem Mehrbenutzerbetrieb
. . . .
26
8.2
Concurrency Control / Synchronisation . . . . . . . . . . . . . . . . . . . . .
26
8.3
8.4
8.5
Pessimistic Concurrency Control (PCC) . . . . . . . . . . . . . . . . . . . . .
26
8.3.1
Sperr- und Freigabestrategien . . . . . . . . . . . . . . . . . . . . . .
26
8.3.2
Sperrgranulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
8.3.3
Sperrmodi
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
8.3.4
Sperrhierarchie / Intention Locks . . . . . . . . . . . . . . . . . . . .
27
8.3.5
Sperreskalation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
8.3.6
Sperrgraph / Wartegraph . . . . . . . . . . . . . . . . . . . . . . . .
27
Optimistic Concurrency Control (OCC) . . . . . . . . . . . . . . . . . . . . .
28
8.4.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Kurzzeitsperren / Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
BOCC / FOCC
9 Embedded SQL / API
9.0.1
9.1
9.2
. . . . . .
28
Precompiler / Vorübersetzung . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Cursor-Konzept
29
9.2.1
9.3
28
Konzepte für Datenbankzugri aus Anwendungsprogramm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmstruktur mit Cursor am Beispiel von ESQL
dynamisches ESQL
. . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3
10 Normalformen / Erweiterungen
30
10.0.1 Probleme nichtadäquater Datenmodellierung . . . . . . . . . . . . . .
10.1 Normalformen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Funktionale Abhängigkeiten / Functional Dependencies
10.3 weiteres
30
31
. . . . . . . . . . . .
31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4
- Externspeicher
heißt Magnetplatte (Sekundärspeicher),
1 Datenverwaltung
mit Dateisytemen
Magnetband, opt. Speicher o.ä. (Tertiärspeicher)
Dateien,
für die
ein schneller (u. ggf. wahlfreier) Zugriff („random
Datei:
geordnete (meist homogene) Sammlung von Datensätzen,
access“) benötigt wird, müssen auf Magnetplatte stehen, andernfalls
wendung in Felder strukturiert
können auch (kostengünstigere) Tertiärspeicher Verwendung finden
- Felder
/ Struktur heißt,
dass ein Datensatz sich aus Sicht der
Sortierung:
entweder entry sequenced (Einfügereihenfolge) oder
Anwendung(!) nicht einfach als „byte string“ darstellt, sondern als
einem Schlüsselwert)
strukturierteslich
Gebilde.
Bsp.: satz
Buchungs- Betrag Kto- Zahlungsnr.
nr. empfänger
3 Bytes
4 Bytes 2 Bytes
meist aus Sicht der An-
key sequenced
(bezüg-
...
16 Bytes
Felder 1 ... 4
N.B.: So sieht das Anwendungsprogramm bzw. der Benutzer den Datensatz bzw. interpretiert ihn in dieser Form; das Betriebssystem (Dateisystem)
ist u.U. viel „dümmer“, hat doch nur die Sicht des langen „byte strings“
(Datensatz =Datensätze
1 „byte string“),
kennt keine Felder
sequentiell (fortlaufend) abgelegt, Ordnung durch
1.1 Sequentielle Datei
Zugri auf die Daten
Datenbanksysteme 1
22.10.2007
Einfügereihenfolge entstanden,
22
ˆ
bei variabel langen Datensätzen: nur sequentielle Suche möglich
ˆ
bei fest langen Datensätzen: wahlfreier Zugri oder über Sortierkriterium (bsp. Personalnummer oder Name)
1.2 Indexsequentielle Datei
Datensätze oder Verweise auf Daten in den Blättern eines Baumes abgelegt, meist als B*Baum realisiert, nur ein Sortierungskriterium möglich, Zugri sequentiell oder wahlfrei über
das im Baum gegebene Schlüsselfeld
1.3 Hash-Datei
Ein Feld wird als Schlüsselfeld festgelegt, eine Hashfunktion rechnet diese in Speicheradressen
um, Zugri wahlfrei mit Schlüsselwert oder (je nach Implementierung auch) sequentiell
1.4 Probleme der Datenverwaltung in Dateien
vgl. Anforderungen in Abschnitt 2.1
ˆ
schneller Zugri nur über indexsequentielle oder Hash-Dateien möglich, Anwendung
muss diesen Zugri direkt implementiert haben (Datenunabhängigkeit!)
ˆ
keine hohe Verfügbarkeit: Datenverlust auf der Platte, Datenreorganisation
ˆ
keine Flexibilität bei Datenzugri oder -auswertung
ˆ
keine integrierte Auswertbarkeit über Abfragesprache
5
ˆ
ein Zugri pro Datei, besonders bei Schreibvorgängen
ˆ
Zugrisberechtigung nur auf Dateiebene, nicht Wertbasiert (nur Mitarbeiter mit PNr
< 500)
1.4 Datenbanksysteme u. ihre Eigenschaften und Terminologie im Überblick
2 Funktionalität
von Datenbanksystemen
1.4.1
Datenbank/Datenbanksystem/Datenbank-Verwaltungssystem
(DBVS, DBMS)
konkrete Datenbank + DBMS = Datenbanksystem
Begriffliche Abgrenzung und Einordnung
Benutzer
Client
DBVS ! DBMS
DatenbankVerwaltungssystem
(DBVS)
liegt üblicherweise auf
separatem
DB-Server
BS
Datenbanksystem
Dateiverwaltung
no n
o
ClientServer
Datenbank
Bemerkung dazu:
ˆ Datenbankverwaltungssystem
DBVS (=
Datenbankmanagementsystem
DBMS)
• DBVS*
(auch Database Management
System
(DBMS) genannt) verwaltet
denverwaltete Datenbestand
Datenbestand;
alle Zugriffe zum Datenbestand (anlegen, lesen, einfügen, ändern,
löschen) gehen ausschließlich über das DBVS, d.h. DBVS übt vollständig Kontrolle
ˆ alle
Zugrie nur aus
über das DBMS
über
Datenbestand
* in seltenen
Fällen auch
Datenbank-Betriebssystem
genannt
ˆ Struktur:
Primärdaten,
Indexe, Beschreibungsinformationen
Datenbanksysteme
talog / 1Data Dictionary)
ˆ
(Metadaten, Datenbankka-
24.10.2007
32
DBMS kann aktiv Änderung von Datenbeständen beim Eintreten von Bedingungen
durchführen
ˆ
Programme / gespeicherte Prozeduren (stored procedures)
2.1 Grundlegende Anforderung
Persistente Datenhaltung:
Speicherung auf nichtüchtigen Speichern (Magnetplatte, Ma-
gnetband oder optische Speicher)
Datenkapazität:
Performance:
Giga-, Tera- oder Petabytes, möglichst nur durch physischen Platz begrenzt
Sehr schneller Zugri zum Lesen und Bearbeiten, möglichst ohne sequentielle
Suche
Verfügbarkeit:
24-7-Betrieb z.B. für Flugbuchungssysteme oder Banken
6
integrierte Auswertbarkeit (Flexibilität):
Abfragen wie Welche Mitarbeiter der Firma sind
seit über 10 Jahren im Unternehmen und haben Kurse ...
Datenverteilung (Flexibilität):
Mitarbeiterdaten in Hamburg, Kursdaten in Frankfurt, Pro-
jektdaten in Dresden, aber trotzdem integrierte Auswertung
Lastverteilung (Flexibilität):
Von mehreren Rechern soll auf einen Datenbestand zugegrif-
fen werden können (transparent für den Benutzer)
Benutzerfreundlichkeit:
leicht erlernbare, aber dennoch mächtige Abfragesprache
Sicherheit vor Datenverlust:
Auch bei plötzlichem Systemausfall kein irreversibler Daten-
verlust (oder zumindest in wohl denierten Grenzen)
Zugrisrechte:
möglichst feine und präzise Einstellung für Datenzugrisrechte
Paralleler Zugri:
mehrere Benutzer arbeiten auf einem Datenbestand ohne dass Konikte
auftreten (logischer Einbenutzerbetrieb trotz physikalischem Mehrbenutzerbetrieb)
semantische Integrität:
Datenunabhängigkeit:
automatisch vom System garantiert
Strukturelle Änderung am Datenbestand, soll nach auÿen nicht sicht-
bar werden.
XXX
noch 33 2.2 Datenbank / Datenbanksystem / Datenbankmanagementsystem
32
2.2.1 Datenbanksystem-Betriebsmodi
Unterscheidung zwischen
Online Transaction Processing (OLTP):
viele kurze Verarbeitungsvorgänge, schnelle Ant-
wortzeit (Buchung)
Online Analytical Processing (OLAP):
wenige lange Zugrie, häug aggregierte (aufge-
sammelte) Daten, vorwiegend lesend (Verkehrsanalyse)
2.2.2 Datenintegrität
Unterscheidung zwischen
physische:
logische:
Daten in sich korrekt (DBMS überwacht dies selbstständig)
bezüglich externen Bedingungen (z.B. Gehalt < 7000) und muss daher explizit
programmiert werden (Integritätsbedingungen)
7
2.3 Datenbank-Architekturen
2.3.1 ANSI/SPARC - 3 Ebenen
ˆ
Entstanden in den 1970er Jahren
ˆ
3 Ebenen
externes Schema: Wie dem Nutzer präsentiert? Teilsichten - Benutzer
konzeptuelles Schema: Was gespeichert? (logische, möglichst systemunabhängige und
anwendungsunabhängige Ebene (Tabellen, Attribute, Beziehungen, Entity-Relationship))
- Anwendungsadministrator
internes Schema:
Wie werden Daten gespeichert? (systemspezisch, physische Dar-
stellung, internes Satzformat, Zugrispfade ...) - Datenbankadministrator
ˆ
Datenunabhängigkeit: Änderungen am internen Schema haben keine Auswirkung auf
konzeptuelle / externe Sicht oder können verborgen werden (VIEW-Denition)
ˆ
Datenbanksystemunabhängigkeit: Von DBMS-Produkt X auf Y nur internes Schema
verändert, falls normkonform keine Auswirkungen auf höhere Ebenen
2.3.2 DIAM - 4 Ebenen
Entity:
Ein Objekt der realen Welt, das in der Datenbank dargestellt wird. Auf oberster
Ebene werden Objektmengen (Entitätsmengen) dargestellt und verwaltet
String Model:
DBMS kennt logische Zugrispfade (z.B. Index auf PNr, Datensätze intern
nach ANr sortiert ...)
Encoding Model:
Beschreibt wie Daten im Speicher physisch darfestellt werden (z.B. Index
auf PNr ist ein B*-Baum mit fest langen Einträgen je 4 Byte ...)
Physical Device Model:
Dateisystem (Tabelle Personen steht in Datei xyz auf Platte D001
...)
2.3.3 5 Schichten 51
xxx
3 Datenmodellierung im Entity-Relationship-Modell (ERM)
3.1 Entity / Entitytyp
Entity / Entität:
bestimmtes, wohl unterscheidbares Objekt der realen Welt
8
Entitytyp / Entitätstypen:
Menge alle möglichen Entities mit gleichen charakterisierenden
Merkmalen, z.B.Angestellter Meier und Müller sind Entities, dann bilden sie Entitytyp
ANGEST
Verschiedene Entitytypen müssen nicht unbedingt disjunkt sein (z.B. PERSON und
STUDENT)
entity set:
tatsächlich vorhandene Entitymengen (endlich)
Attribute:
Entitiytypen E werden Attributmengen A zugeordnet (z.B. {PNr, Name, Vorna-
me, Gehalt ...}), Name ist beispielsweise ein Attribut
Attributwerte:
einem einzelnen Entity e sind entsprechende Attributwerte a (z.B. 17, Meier,
Hans, 1050
¿
...) zugeordnet
Wertebereiche / Domänen:
Jedem Attribut ist ein Wertebereich (Domäne) zugeordnet
(z.B. dom(PNr) = INTEGER, dom(Name)=VARCHAR, dom(Haarfarbe)={blond, blau
...})
3.2 Schlüssel
Schlüssel ermöglichen eine eindeutige Identizierung eines Entities innerhalb eines Entitytyps,
also innerhalb aller möglichen Entitites. (z.B. künstlicher Schlüssel PNr)
Schlüssel
K
bestehend aus Schlüsselattributen, dann muss
Minimalität oft gefordert, d.h.
K⊆A
@K 0 ⊂ K : K 0 Schlüssel
Häug gibt es meherere mögliche Schlüssel (auch bei Minimalitätsforderung) die als Schlüsselkandidaten bezeichnet werden, genau einer wird als Primärschlüssel ausgewählt
3.3 Beziehungen / Beziehungstypen
Beziehungen:
bestehen zwischen einzelnen Entities verschiedener oder gleicher Entitytypen
Beziehungstyp:
die Menge aller möglichen Beziehungen (z.B. kartesisches Produkt ARBEI-
TET_AN = ANGEST x PROJEKTE)
relationship set:
tatsächlich vorhandene Beziehungsmengen
1:1 Beziehungstyp:
XXX
n:1 Beziehungstyp:
n:m Beziehungstyp:
(many to many relation ship type)
Integritätsregeln:
1. von jeder Beziehung genau eine Kante (beim zweistelligen Beziehungstyp)
2. nicht jeder Entity muss in einer Beziehung stehen
3. jede Beziehung nur einmal,
r1 = (e, e0 ) = r2
verletzt
9
nicht möglich, da Mengeneigenschaft
3.4 ER-Diagramme
Ausschnitt der
realen Welt
Miniwelt
Beziehungstyp
Titel
Zeitplan
Entitätstyp
liest/wird
gelesen
Professor
Vorlesung
Entitätstyp
Name
Semester
Fach
Telefon#
empfiehlt/wird
empfohlen zu
Autor
Attribute
Buch
Titel
Hinweis: Dies ist ein
ISBN
unvollständiges EntityRelationship-Diagramm
Zusätzliche Erweiterungen
des E/R-Modells
(warum?)
Datenbanksysteme
1
nicht vollständig,
24.10.2007
da Schlüsselkennzeichnung
sowie der E/R-Diagrammdarstellung
Entitätstyp
fehlt
55
1. Erweiterungen bei Attributen
3.4.1Attribute
Kardinalität
a) Optionale
/ Komplexität
3 4Optionale
Beziehungen 56),,78+9:+;<,=>25?@A:+2%'>B2C,*:*022+! ! C22
(min,max)-Notation
darf :,28+9:+;<,=2D2/*+;+,29<2C,*:*02+" ! CEF2muss )-+D2,:G;*H2
1:n-Notation
8/I#B2J:*)D-+:*2K@,2L,=+/*+AA*+,2:,2MD@N+.*+,O2
3 Optionales AttributB2
3.4.2 schwache Entitytypen
L**D:-<*2+P:/*:+D*2QRD2C,*:*0*0I2-9S#28+9:+;<,=/*0IF2muss
aber nicht für
jedes Entity / jede Beziehung einen definierten Wert annehmen
3.4.3b)Erweiterungen
für Attributen
Strukturierte Attribute
51#)#T#B2)A/2T+D*2+P:/*:+D+,>
3 Strukturiertes
Attribut /+*4*22/5672)8/2),9+:+,2;**:5-8*+,2
ˆ optionale
Attribute
3 Graphische
Notation
(Bsp.:)
<=+5,>)67+:+,? ;**:5-8*+,@248/)11+,22
(Primär-)Schlüssel dürfen
ANGEST
nicht opt. 5,27E7+:+,2F:BG:)115+:/H:)67+,@
sein.
<A2:+6B:9C
B9+:2/*:86*CDB,/*:8.*
optionales Attribut
3 Engl.: composite attribute
MVW
T+;DU:+,/*XK@,X-:/
3 (5+2Komponenten
+5,+/2/*:8.*8:5+:*+,2;**:5-8*/2/5,92!@2benannt 8,92
"@25#9#I#2-+4JGK567257:+:2(B1L,+,2<M+:*+-+:+567+@2inhomogen
5?RD2+:,+ weibliche L,=+/*+AA*+2+P:/*:+D*2U:+2T+;DU:+,/*),=)-+2,:G;*#
3 GraphischeAttribute
Notation (Bsp.:)
5S)D21)A2QDR;+D2/@2:,2(+<*/G;A),U##>2C,*/ID+G;+,U2-+:28+9:+;<,=/*0I+,
ˆ strukturierte
()*+,-),./0/*+1+2!
!"#!!#"$$%
&'
ANGEST
!
atomares Attribut
;9:+//+
FNI
FOP
ODP
S:*
nichtatomares
strukturiertes Attribut
Q*:)R+
Attribut
T)8/,811+:
(Teil)attribut
FOPU
3 M+5*+:+2Schachtelung 1EGK567
3 ;8672)K/2,567*2)*B1):+/2;**:5-8*2-+4+567,+*
()*+,-),./0/*+1+2!
!"#!!#"$$%
10
&'
c) Mengenwertige Attribute
3 Mengenwertige Attribute4222Attributwert = Wertemenge
562/+*789,/*:;.*2<,2=>=+:+,2?@A
3 Engl.: multivalued attribute
3 (<+2Elemente B+:2C+:*+1+,D+2+<,+/21+,D+,E+:*<D+, F**:<-;*/2/<,B2
!A2unbenannt ;,B2"A2-+GHDI<J=2<=:+:2(91K,+25C+:*+-+:+<J=/A2homogen
3 Graphische
Notation (Bsp.:)
ˆ mengenwertige
Attribute
berechnete
d) Virtuelle
Attribute (auch abgeleitete Attribute genannt)
ANGEST
nichtatomares
!
!
!
2 Nicht real gespeichert 340()*56(76.6*5)891(7.1:*5);1.<+=*5+1=>5?@1
mengenwertiges Attribut
A*5*?@+>+B.C<5.?@56D)1*506))*7)
?UT
V+I+W9,X
2 Engl.: derived attribute
2 Graphische Notation
(Bsp.:)
3 C+<*+:+2Schachtelung
1>DI<J=L2);J=2<,2M+:-<,B;,D21<*2strukt.
Attribut
ˆ virtuelle Attribute
5G#N#42O+,D+2P9,2FB:+//+,A
virtuell
virtuell
2. Erweiterung um Spezialisierung sinnvoll
und Generalisierung,
„nötig“
3 F;J=2)I/2,<J=*)*91):+/2F**:<-;*2-+G+<J=,+*
ANGEST Sub- und Supertypen
IS-A-Beziehung,
• Hinweis: Spezialisierung und Generalisierung sind – wie auch schon
Q<,E+</2G;:2M9:/<J=*4
QRS
K*@(7)
K*,G'()
H(@5*.B*@(7)
L7)*5
optionale/strukturierte/mengenwertige/berechnete
Attribute –
O<*2strukturierten
;,B2mengenwertigen
Attributen
/9II*+2<12RST7O9B+II2
Bestandteil sog. erweiterter E/R-Modelle virtuelle Attribute
wohlüberlegt ;1D+D),D+,2E+:B+,L2E+<I4
K*@(7).0<+()*
Semantische Datenmodelle
()*+,-),./0/*+1+2!
!"#!!#"$$%
&'
( „extended entity-relationship
models angegeben
)
2 '6*1Berechnungsvorschrift
0>..1mit
E*5=*+;1F#A#
Generalisierung
istund
die Bildung
eines allgemeineren („generischen“)
G H(@5*.B*@(7)1IJ1K*@(7)1!
K*@(7).0<+()*
3.4.4 •Spezialisierung
Generalisierung
Entitytyps
aus einer Anzahl „ähnlicher“
G L7)*51IJ1L-)>*77*.1'()>01M
K*,G'() Entitytypen
Beispiel:
ˆ Die
Beziehung ⇒wird auch =(5D1B5>+=.N)F76?@1beliebig
als IS-A-Beziehung bezeichnet
2• '6*1Berechnungsvorschrift
komplex
.*6+;1.6*10>..1.6?@1C<51(77*01+6?@)1>+,*=6+B)1+>51(>D1L))56,>)E*5)*1=*.1
MITARBEITER
Spezialisierung
Generalisierung
B7*6?@*+1O+)6)6*.1,*F6*@*+13E6*1601<,6B*+1A*6.P6*71F>DN776B1B*B*,*+9;1
'()*+,(+-./.)*0*1!
ˆ
ˆ
ANGEST
ARBEITER
!"#!!#"$$%
&&
Der umgekehrte Vorgang wird als Spezialisierung bezeichnet.
• Die entstehende Beziehung „!“ wird auch als IS-A-Beziehung
bezeichnet: Jeder Angestellte ist ein Mitarbeiter, jeder Arbeiter ist ein
Arten von Generalisierung und Spezialisierung
Mitarbeiter.
Vererbung aller Attribute des Vaters auf die Kinder
Datenbanksysteme 1
19.11.2007
91
disjunkte Subtypen: Mitarbeiter, Verkäufer, Schreibkraft, Mechaniker
nicht disjunkte Subtypen (überlappend): Fussballvereinsmitglieder, Spieler, Trainer
Vollständigkeit / Unvollständigkeit der Subtypbildung
3.4.5 Attribute und Beziehungstypen als Entitytypen
XXX S. 100
4 Hierarchisches Datenmodell
zu modellierende Miniwelt wird ausschlieÿlich mit Hierarchien (entspricht Datenbanken)
dargestellt
ˆ
Typebene
Dabei Ordnungsreihenfolge der Kinder von Bedeutung (Abarbeitungsreihenfolge: lin-
Bsp.: Erweiterung des zu modellierenden Miniweltausschnitts um
über Rechnungen und Rechnungsposten
Darstellung im HDM
• Typebene
KUNDE
ker dann rechter
Sohn)
Informationen
AUFTRAG
RECHNUNG
AU-POS
RE-POS
Baum
• Ausprägungsebene (Instanzenebene, Satzebene)
(Entity-Ebene)
Lüdenscheid
" Einstiegspunkte
Müller
11
Meyer
A1
AU-Pos11
AU-Pos12
A2
AU-Pos21
Wald
A3
AU-Pos11
Jeder untergeordnete Satz (Sohn, Kind) ist genau einem
übergeordneten Satz (Vater) zugeordnet; ! keine Waisenkinder
[zum untergeordneten Satz greift man über den übergeordneten Satz zu]
Datenbanksysteme 1
26.11.2007
113
Bsp.: Erweiterung des zu modellierenden Miniweltausschnitts um
Informationen über Rechnungen und Rechnungsposten
Darstellung im HDM
• Typebene
KUNDE
ˆ
AUFTRAG
RECHNUNG
AU-POS
RE-POS
Baum
Ausprägungsebene / Instanzebene / Satzebene
• Ausprägungsebene (Instanzenebene, Satzebene)
(Entity-Ebene)
Lüdenscheid
" Einstiegspunkte
Müller
Meyer
A1
AU-Pos11
Wald
A2
AU-Pos12
A3
AU-Pos21
AU-Pos11
Jeder untergeordnete Satz (Sohn, Kind) ist genau einem
übergeordneten Satz (Vater) zugeordnet; ! keine Waisenkinder
[zum untergeordneten Satz greift man über den übergeordneten Satz zu]
4.1 Eigenschaften / Beziehungen
Datenbanksysteme 1
26.11.2007
ˆ
Jeder Entitytyp gehört zu genau einer Hierarchie
ˆ
oberster Entitytyp wird als Wurzeltyp bezeichnet
ˆ
für den Wurzeltyp existiert ein Primärschlüssel
113
4.1.1 virtuelle Entitytypen
Zwei gleiche Entitytypen in zwei Hierarchien nicht zulässig, daher virtuelle Entitytypen einführen
2. Einführung von sog. virtuellen Entity(Satz)typen
1. Beispiel
ABTEILUNG
ANGEST
POSITION
Zeiger
virtueller
ANGEST
oder:
4.2 Bemerkungen zumABTEILUNG
HDM
ˆ
ˆ
ˆ
virtueller
POSITION
Zeiger
ANGEST
kein direkter Zugri aufANGEST
einen beliebigen Entity möglich, lediglich auf Wurzelebene des
Idee:
Baums
• Nur in einer Hierarchie existieren die ANGEST-Entities physisch (d.h.
sind sie tatsächlich gespeichert)
entspricht Verarbeitungsmodell
auf Dateiebene
• Aus anderen Hierarchien heraus wird auf diese Entities per Zeiger
Operation gehe
zum Vater nicht benötigt, da nach Top-Down-Vorgehensweise der
verwiesen
Vater ohnehin
vorher
besucht
(vollständiger
hierarchischer
Pfad)
• Die
Benutzer
sehenwurde
diese Form
der unterschiedlichen
Realisierung
(mal physisch direkt gespeichert, mal nur über Zeiger referenziert)
nicht! (lediglich der Datenbankadministrator/Anwendungsadministrator
bekommt sie zu sehen bzw. muss sie definieren)
!
4.3 IMS als Beispiel
für ein HDM
Datenbanksysteme 1
Information Management
System (von IBM) 26.11.2007
123
ˆ
erweitertes hierarchisches Datenbankmodell
ˆ
Ende 1960er eingeführt
ˆ
auch heute noch weit verbreitet, meist Koexistenz und nur langsame Ablösung
ˆ
hohe Stabilität
ˆ
hohe Performance
12
4.3.1 IMS-Notation und -Terminologie
ˆ
Knoten in der Typhierarchie werden Segments genannt
ˆ
jedes Segment besteht aus Feldern
ˆ
ein ausgezeichnetes Wurzel-Segment (root segment), die anderen als abhängige Segmente (dependent segments)
ˆ
weitere Begrie: Vater-Segment, Kind-Segment, Geschwister-Segment
4.3.2 Database Denition Language (DDL)
XXX
4.3.3 Data Language / One (DL/1)
one record at a time
ˆ
GET UNIQUE (GU): Direktes Positionieren auf bestimmtem record und Lesen
ˆ
GET NEXT (GN): Zugri auf nächsten record
ˆ
GET NEXT WITHIN PARENT (GNP): wie GN, aber nur innerhalb des aktuellen Vaterrecord
ˆ
GET HOLD (GHU): Zugri auf einen record, um ihn anschlieÿend zu ändern
ˆ
INSERT (INSRT): Einfügen eines neuen records
ˆ
DELETE (DLET): Löschen eines records (zuvor GET HOLD)
ˆ
REPLACE (REPL): Ändern eines records (zuvor GET HOLD)
5 Netzwerk-Datenmodell
ˆ
NDM von vornherein mit dem Ziel entstanden einen nichtproprietären Ansatz zu entwickeln (anders als HDM), an CODASYL waren viele Hersteller beteiligt
ˆ
Ziel Spezikation von DDL und DML
ˆ
ab Anfang der 1970er Jahre
13
5.1 Set-Typen
ˆ
Zweistelliger Beziehungstyp
wobei
R 6=
S
zwischen Record-Typ
R
(Owner) und
ˆ
Graphisch im sogenannten Bachman-Diagramm
ˆ
implizit 1:n-Beziehungstyp
ˆ
Aus Ausprägungsebene (occurrences): Zu jeder Record Occurrence
zit eine Set Occurrence
R0
(Member),
R0
s∈S
und jeder
r 0 ∈ R0
r∈R
gehört maximal zu einer
Owner Record zu jedem Member Record eindeutig deniert
⇒
gehört impli-
s∈S
Set Occurences
sind Baum-Ausprägungen
ˆ
Waisenkinder grunsätzlich erlaubt
Ordnung: Es existiert immer eine Ordnung (Einfügereihenfolge oder Sortierkriterium)
der Member-Sätze, in der sie wieder aufgefunden werden (FIND NEXT ... WITHIN
SET ...)
ˆ
Implementierung
Verkettete Implementierung (MODE IS CHAIN)
mittels Zeigertabelle (MODE IS POINTER-ARRAY)
via Memberliste
(MODE IS
Modellierung
vonLIST)
Beziehungen
im NDM oder: Vom E/R-Modell zum NDM
I. Nichtrekursive 1:n Beziehungen
E/R-Diagramm
ABTEILUNG
5.2 Vom ER-Modell zum NDM
(0,*)
5.2.1 Nichtrekursive 1:n Beziehungen
1
hat
Modellierung von Beziehungen im NDM oder: Vom E/R-Modell zum NDM (0,1)
n
ER-Diagram
Netzwerk-Datenmodell
(Bachman-Diagram)
MITARBEITER
I. Nichtrekursive 1:n Beziehungen
E/R-Diagramm
ABTEILUNG
im Netzwerk-Datenmodell
(0,*)
1
ABTEILUNG
hat (Bachman-Diagramm)
(0,1)
hat
n
MITARBEITER
MITARBEITER
hat
im Netzwerk-Datenmodell
Was macht man,
ABTEILUNG
(Bachman-Diagramm)
wenn?
5.2.2 Rekursive 1:n Beziehungen
a)
(1,1)
MITARBEITER
hat
MITARBEITER
direkte Rekursion
im NDM nicht erlaubt, daher Lösung:
b)
Was macht man,
5.2.3
wenn?
Ket-Record-Typ XXX 152
ABTEILUNG
(1,*)
hat
„Waisenverbot“ kann mittelshat
Nichtrekursive
n:m (1,1)
Beziehungen
a)
DDL-Klausel bei Set Type
MITARBEITER
Datenbanksysteme 1
03.12.2007
Bachman-Diagramm im V-Schema Definition vereinbart werden
b)
ABTEILUNG
(1,*)
hat
Datenbanksysteme 1
nicht per DDL spezifizierbar
! muss von Anwendung
überwacht werden!
03.12.2007
150
14
„Waisenverbot“ kann mittels
DDL-Klausel bei Set Type
Definition vereinbart werden
nicht per DDL spezifizierbar
! muss von Anwendung
überwacht werden!
150
Lösung: Wiederum Kett-Record-Typ (plus 2 Set-Typen)
LIEFERANT
oder:
LIEFERANT
liefert
liefert_TEIL
Menge
liefert
wird_geliefert
wird liefert
liefert_TEIL
IV. Rekursive n:m Beziehungen
TEIL
Fertigteil
Beispiel: Stückliste
A
Bachman-Diagramm
1
Baugruppe
Ausprägungsebene
3
L1
B
TEIL
Menge
„DAG“
„V-Schema“
gerichteter
azyklischer
L4
Graph
L3
4
C
7
1
5
2
L2
D
E
5.2.4 Rekursive n:m Beziehungen
Einzelteil
F
liefert
Kett-RecordL1,T1,20
L1,T2,7
L1,T3,9
L2,T1,100
L2,T1,100
L3,T4,10
z
x
y
bedeutet:
z Exemplare
{der that
Baugruppe
des Teils
X} gehen
Occurrence(sonst Kanten
Gozinto-Graph
(Zeparzat
Gozinto
- the part
goes x,
into),
Waisenverbot
in eine Baugruppe y ein
wird_geliefert
ohne Knoten)
T1
T2
T3
T4
sog. Gozinto-Graph
!
T5 goes into „Zeparzat Gozinto“ - the part that
• Kett-Record-Occurrences
enthalten LNr,
TNr, Menge
E/R-Diagramm
Bachman-Diagramm
Datenbankschema
imgesp.
NDM
redundant,
deshalb nicht
TNr
• 1 Kett-Record-Occurrence pro Lieferung (Beziehungsausprägung)
TEIL
zwischen Lieferant und Teil)
Teil
Datenbanksysteme 1
03.12.2007
(0,!)
155
ist_enthalten_in
(1:n)
enthält
(1:n)
(0,!)
enthält/
ist_enthalten_in
Mehrstellige
Beziehungstypen (k>2)
MengeE/R-Diagramm
Beispiel:
Datenbanksysteme 1
Mehrstellige Beziehungstypen (k>2)
ER-Diagram
Kett-Record-Typ
Projekt
(0,*)
03.12.2007
5.2.5 Mehrstellige Beziehungstypen
Struktur
„Waisenkinder“?
Menge
liefert
156
(0,*)
Lieferant
(0,*)
Netzwerk-Datenmodell (Bachman-Diagram)
Artikel
Projekt
Beispiel: E/R-Diagramm
(0,*)
Menge
Bachman-Diagramm
(0,*)
Lieferant
liefert
Projekt
P_l
(0,*)
Artikel
Kett-Record-Typ
Lieferant
L_l
liefert
Artikel
A_l
Menge
ist wiederum Kett-Record-Typ
5.3 Grundsätzliche•• liefert
Eigenschaften
des NDM (Vergleich zum HDM)
Bei der Definition der drei Set-Typen (P_l,L_l,A_l) muss jeweils
Bachman-Diagramm
Projekt
Lieferant
L_l
P_l
spezifiziert
mit * Unterschied zu HDM
Kett-Record-Typ
Artikel
A_l
werden, dass Waisenkinder verboten sind (jede liefertAusprägung
muss
Mengein drei Set-Ausprägungen Member sein)
liefert
Datenbanksysteme 1
03.12.2007
158
1. * Jeder Record-Typ kann Owner oder Member in beliebig vielen Set-Typen sein
2. Kett-Record-Typ
In einem Set-Typ muss Owner 6= Member sein (keine direkte Rekursion)
• liefert ist wiederum
• Bei der Definition der drei Set-Typen (P_l,L_l,A_l) muss jeweils
3. dass
* Zwischen
einemverboten
Owner-Record-Typ
dürfen beliebig viele Set-Typen existieren (und in
spezifiziert werden,
Waisenkinder
sind (jede liefertAusprägung muss inbeliebiger
drei Set-Ausprägungen
Richtung) Member sein)
Datenbanksysteme 1
03.12.2007
158
4. alleinstehende Record-Typen sind erlaubt
5. * Einstieg für beliebigen Record-Typ möglich, keine ausgezeichneten Einstiegspunkte
15
6. * Wenn ein Record-Typ Member eines Set-Typs S ist, so müssen nicht alle RecordAusprägungen s von S sein: Waisenkinder erlaubt
7. Für Member-Record-Ausprägungen muss stets eine Reihenfolge festgelegt sein
auch beim NDM: one record at a time
5.4 Beispielschema eines NDM
Lesender Zugri
ˆ
Direkter Einstieg von auÿen: FIND ANY ANGEST ( name ='Müller' )
ˆ
Member
ˆ
Owner
→
→
Owner: FIND OWNER ...
Member: FIND ANY ... oder FIND FIRST ANGEST ( Gehalt > 5000 ) ...
oder FIND NEXT und prüfen
Update
ˆ
FIND ANY ...
ˆ
ins Programm übergeben und berechnen
ˆ
Zurückschreiben mit MODIFY (kann teuer werden, wenn damit neue Reihenfolge oder
zu einer anderen Set-Ausprägung wechseln)
Löschen
ˆ
FIND ANY ...
ˆ
Löschen mit ERASE
Einfügen
ˆ
STORE
6 Relationales Datenmodell
Entwicklungsziel
ˆ
Einfaches Datenmodell
ˆ
Einfache Datenbanksprache
ˆ
Konsistenz- / Integritätsüberwachung durch DBMS
16
Ergebnis
ˆ
Datenmodell und Datenbanksprache leichter zu erlernen
ˆ
Datenbankzugri auch ad-hoc möglich
ˆ
Inkonsistenten unwahrscheinlich
ˆ
Inezienter Datenbankzugri unwahrscheinlicher, da das DMBS das
wie
bestimmt
Geschichte
ˆ
Erste Prototypen ab Mitte der 1970er Jahre (IBM San Jose, University Berkeley)
ˆ
Erste Produkte ab Ende 1970er: SQL/DS, DB2, Ingres, Oracle ...
Kurzschreibweise
6.1 Begrie und Eigenschaften
des(2341516(7,8(,*99*
relationalen :6(7,*;1<*7)=11>*++1?@*1
Modells
L))7@,2)menge
A2B*4C7@B*+1'D0E+*+FG+)*B7@)E).,*?@+B2+B*+1
Darstellung in Form von Relationen
R (Menge!) als Teilmengen des kartesischen Produkts
.*H(7()1,*.347@*,*+1.@+?1
der Domänen (Wertebereiche)
D1 × . . . × Dn , dabei wird ein Element r als Tupel von R
I J.H#$5 K*9()@D+..34*0(1L+B*.)1:M(0*;1J*72N;1<D4+D7);1O*,P(47=
:Q1'D0E+*+FG+)*B7@)E).,*?@+B2+B*+=
bezeichnet
(9.1'(7.)*992+B1RD+1Schema + Daten
Attribut(name)
Schemaname
L+B*.)
Tupel
(als Tabellenzeilen dargestellt
M(0*
WU99*7
W*@*7
T3429A*
J*72N
T347*@+*7
T340@*?
J*7B0(++
<D4+D7)
O*,P(47
Schema
P*+(
P*+(
T*@NN*+
!X&"
!XYZ
!X[Y
Daten,
konkrete
Relation
Attribut(wert)
I J*0*7-2+B*+5
S Menge RD+1K*9()@D+..34*0()(1:0@)1.@3412+)*7.34*@?*+?*+1
Relationen können T34*0(+(0*+=1Q1A2.E)A9@34*1G+)*B7@)E).,*?@+B2+B*+1
auch als Tabellen dargestellt werden, wobei man die Tupel als Tabel:7*9()@D+..34*0(U,*7B7*@N*+?=1*7B@,)1Datenbankschema
lenzeilen (rows) und die Komponenten der Tupel als Tabellenspalten (columns) identiziert.
S J*B7@NN9@341>@7?1A>@.34*+1K*9()@D+..34*0(12+?1K*9()@D+1+@34)1
Meist ndet man folgende
Schreibweise für die Tabellenschemata:
@00*71.)7@-)12+)*7.34@*?*+V1>*++1RD+1Relation ?@*1K*?*1@.);1>@7?1
0*@.)1?(72+)*71(2341?(.1T34*0(1.2,.20@*7)1:?#4#1'()*+1Q1T34*0(1
ANGEST ( PNr, Name, Vorname, Gehalt, ...)
D?*71(2341+271T34*0(=
'()*+,(+-./.)*0*1!
!"#!$#$""%
!%&
6.1.1 Schlüssel
Da Relationen Mengen sind, dürfen keine identischen Tupel auftauchen
→(minimaler) Schlüs-
sel gefordert, meist künstlicher Schlüssel
Primärschlüssel darf keine NULL-Werte haben!
6.1.2 Vom ER-Modell zum relationalen Modell
nicht rekursive 1:n-Beziehung
Zwei Relationen mit Fremdschlüssel-Beziehung, Kardinalitäten (z.B. (3,7) ) nicht direkt übernehmbar
17
Abbildung E/R-Modell ! relational
!#1+234)15*-65.27*1!8+9:*;2*46+<*+
E/R-Diagramm
Relational
ABTEILUNG
I:BAZ[\J]1GIJDX1I^5)X1###H
(0,*)
hat
Fremdschlüssel
GWX%H1! <*4)1,*21I,,#17*5EF5*+1G.*0#1Y*5E6.)H
(1,1)
(0,1)
MITARBEITER
KZBID:AZBAD1GMJDX1J(0*X1###X1IJDH
4()1IJD
= >,*5?@456+<1A+)2)/9B/C1! D*E()2F+G..34*0(H
= IJD12+1K2)(5,*2)*512.)1Fremdschlüssel 02)1:*;6<1(6?1L*+1M520N5.34E@..*E17F+1
rekursive
1:n-Beziehung
I,)*2E6+<1"
repräsentiert Beziehungstyp O4()P (6.1L*01AQD9'2(<5(001
G>,*5?@456+<1L*.1:*;2*46+<.)/C.12+1*2+*1*2<*+.)N+L2<*1D*E()2F+1.F02)1+234)1
Eine Relation
mit Fremdschlüsselbeziehung innerhalb der Relation
*5?F5L*5E234H
= GI)F0(5*H1I))52,6)*1*2+*.1A+)2)/9B/C.1R*5L*+16+02))*E,(512+1I))52,6)*1L*51S*R*2E.1
*+).C5*34*+L*+1D*E()2F+1@,*5+F00*+T1Vorsicht bei Schlüsselüberführung
nicht GK2+20(E2)N).?F5L*56+<1L*.15*E()2F+(E*+1KFL*EE.12+1,*;6<1(6?1U34E@..*EH
rekursive n:m-Beziehung
= O:*E2*,2<*1V(5L2+(E2)N)*+P G;#:#1GWX%HH1+234)1L25*-)12015*E()2F+(E*+1KFL*EE1
Lieferant liefert Teile mit Beziehungsattribut Menge, sehr analog zum V-Schema (siehe 5.2.3),
L(5.)*EE,(5
dabei Fremdschlüssel von LIEFERT auf LIEFERANT und TEIL
'()*+,(+-./.)*0*1!
!"#!$#$""%
!&"
LIEFERANT ( LieferNr, Name, Ort, ... )
TEIL ( TeilNr, Bezeichnung, ... )
LIEFERT ( TeilNr, LieferNr, Menge )
rekursive n:m-Beziehung
vgl. Gozinto-Graph, in zwei Relationen überführen, dabei besitzt STRUKTUR zwei Fremdschlüssel auf TEIL
TEIL ( TeilNr, Bezeichnung, ... )
STRUKTUR ( Oberteil, Unterteil, Menge )
nicht atomare Attribute
entweder in zwei Tabellen (Abruf durch JOIN aufwendiger) oder in gleiche Tabelle (dann geht
Zusammengehörigkeitsinformation verloren)
6.2 Sprachen für das relationale Modell: Relationenalgebra und
Relationenkalkül
ˆ
nicht navigierend und satzorientiert, sondern mengenorientiert und deskriptiv
ˆ
Mengen von Tupeln gelesen / verarbeitet
ˆ
potentieller Performancegewinn (da DBMS mit Optimizer komplexe Sprachanweisungen
in möglichst performante Teile zuerlegt (semantisch äquivalente Transformation für
minimale Ausführungskosten))
18
ˆ Was
statt
wie
Wenige Basisoperationen notwendig:
ˆ
Selektion
ˆ
Projektion
ˆ
Verbund (Join)
ˆ
Mengenvereinigung, -dierenz, -durchschnitt
Kriterien für Anfragesprachen
ˆ
Ad-hoc-Formulierung
ˆ
Mengenorientiert
ˆ
Deskriptiv
ˆ
Abgeschlossenheit (Anfrageergebnis ist wieder eine Relation , die als nächste Eingabe
verwendet werden kann)
→
everything is a relation
ˆ
Adäquatheit: Alle Konstrukte des Datenmodells unterstützt
ˆ
Orthogonalität: Sprachkonstrukte sind miteinander weitgehend frei kombinierbar (Voraussetzung: Abgeschlossenheit)
z.B. SL_{F1}(SL_{F2} R)
ˆ
Optimierbarkeit: Sprache besteht aus wenigen Operationen, die mit Optimierungsregeln
umgebaut werden können
ˆ
Eizienz: Im Relationenmodell hat jede Operation eine Komplexität
ˆ
Sicherheit: Keine syntaktisch korrekte Anfrage, darf in eine Endlosschleife geraten oder
6 O(n2 )
unendliches Ergebnis liefern
ˆ
Eingeschränktheit: Anfragesprache darf keine komplette Programmiersprache sein (folgt
aus Sicherheit und Optimierbarkeit)
ˆ
Vollständigkeit: Sprache muss mindestens die Anfragen einer Standardsprache erfüllen
Heutige Produkte erfüllen obige Anforderungen weitgehen, teilweise weisen sie aber Schwächen (z.B. in Bezug auf Orthogonalität) auf.
6.3 Relationenalgebra
Werte sind Relationen, Operationen durch Basisoperationen gegeben, Anfrageergebnisse werden durch Schachtelung von Basisoperationen bestimmt
19
6.3.1 Projektion: P JAttr R oder πAttr R
P JAttr R
wählt jene Spalten von R aus, die in Attr angegeben sind (es wird auf jene Spalten
projiziert):
ˆ P J{N ame} Ausleihe projiziert Ausleihe auf Spalte Name, teure Projektion (kein Schlüssel)
ˆ P J{InvN r,ISBN } Buch
projiziert Buch auf die zwei Spalten InvNr und ISBN, billige
Projektion (Schlüssel enthalten)
6.3.2 Selektion: SLF R oder δF R
SLF R
wählt jene Zeilen von R aus, die der Bedingung F genügen:
ˆ SLInvN r>3333 Buch
wählt alle Bücher mit InvNr > 3333 aus
Bedingung dabei mit logischen Verknüpfungen (AND, OR, ...) sowie Vergleichsoperatoren
(=,>,...) beschreibbar.
6.3.3 Verbund (Join): R JNF S
RJNF S
kontakateniert die Tupel der Relation R und S, die die Verbundbedingung F
erfüllen:
ˆ BuchJNInvN r=InvN r Ausleihe
konkateniert jene Tupel aus der Relation Buch und
Ausleihe, deren Werte InvNr übereinstimmen. (Equi-Join, InvNr im Ergebnis nur einmal
vorhanden)
6.3.4 Vereinigung (Union): R U N S
RU N S
vereinigt die gleichen Relationsschemata R und S (Namen- und Domänengleichheit)
und liefert alle Tupel (möglicherweise Duplikatelemination notwendig)
ˆ (SLInvN r>3333 Buch) U N (SLInvN r63333 Buch)
gibt alle Tupel der Buch-Relation
6.3.5 Durchschnitt (Intersection): R IN S
siehe Abschnitt 6.3.4
6.3.6 Dierenz: R DF S
siehe Abschnitt 6.3.4
6.3.7 Zusammengesetzte Beispiele in Relationenalgebra
XXX S. 212
20
6.4 Relationenkalkül
Es wird beschrieben, welche Bedingungen (= Prädikate) die Tupel erfüllen müssen (rein
deskriptive Vorgehensweise des Was)
Tupelvariablen
sind jeweils einer Relation zugeordnet und müssen deniert werden, einer
Relation können mehrere Tupelvariablen zugeordnet werden
Tupelkomponenten:
Sei U der Relation R zugeordnet und A ein Attribut von R, so bezeich-
net U.A die Tupelkomponente (entspricht Attributwert)
Bedingungen:
Sind x und y zwei kompatible Konstanten oder Tupelkomponenten, so spezi-
ziert x=y eine Bedingung (auch <, >,
Formeln
6=,
... )
stellen eine Kombination von Bedingungen dar, mit Klammerung, Negation, Bool-
schen Operatoren (AND, OR), Quantoren (∃ oder
Freie und gebundene (Tupel-)Variablen:
∀)
Tupelvariablen werden durch Quantoren oder
automatisch gebunden, dabei kann sie nur einmal innerhalb eines Ausdrucks gebunden werden
ˆ
U.Autor=Heuer ist eine Bedingung mit der freien Variablen U
ˆ
U.Autor=Heuer
∧U.Titel=Objektbanken
ˆ ∃U(U.Autor=Heuer)
ist eine Formel mit der freien Variablen U
ist eine Formel mit der gebunden Variable U
6.4.1 Beispiele im Relationenkalkül
XXX S. 224
6.5 Structured Query Language (SQL)
Die Norm-Datenbanksprache für relationale Datenbanksysteme, deckt alle drei Ebenen der
ANSI/SPARC-Architektur (siehe Abs 2.3.1) ab.
externe ebene
konzeptuelle Ebene
interne Ebene
create view
create table / domain
create index
6.5.1 Create Table
CREATE TABLE
relationenname ( spaltenname1 wertebereich1 [NOT NULL], ...)
ˆ
Wertebereiche wie integer, smallint, oat)p=, decimal, char, varchar, bit, date
ˆ
NOT NULL-Klausel verbietet das Auftreten von Nullwerten
ˆ
Primärschlüssel / Schlüssel in SQL nicht erzwungen, daher als letztes Attribut angeben
PRIMARY KEY spaltenname1)
21
ˆ
Fremschlüssel ebenfalls beim Erzeugen der Tabelle angeben
ˆ
DEFAULT-Klausel für Standardwerte, wenn beim Insert nichts angegeben wurde
ˆ
CHECK-Klausel kann Integritätsbedingungen für Attributwerte erstellen CHECK ( InvNr
BETWEEN 5 AND 999 )
6.5.2 Create Domain
CREATE DOMAIN
gebiet VARCHAR(20) DEFAULT Informatik CHECK ( VALUE IN
(Informatik, Mathe ...) )
ˆ
erlaubt Denition neuer Datentypen
6.5.3 Alter Table
ALTER TABLE
relationenname ADD spaltenname wertebereich
ALTER TABLE
relationenname DROP spaltenname
ALTER TABLE
relationenname ALTER spaltenname {SET default_denition | DROP DEFAULT}
ˆ
nicht in allen Produkten erlaubt, da heikle Fragen: Was mit vorhandenen Daten? Wann
Auswirkung der Änderung?
6.5.4 Drop Table
DROP TABLE
relationenname { RESTRICT | CASCADE}
6.5.5 Create / Drop Index
CREATE [UNIQUE] INDEX
indexname ON relationenname (spalte1 [ASC | DESC], ... )
6.5.6 Update
UPDATE
relationenname SET spaltenname1 = audruck1, ... [WHERE bedingung]
6.5.7 Delete
DELETE FROM
relationenname [WHERE bedingung]
6.5.8 Insert
INSERT INTO
relationenname ( spaltenname1, ... ) VALUES ( wert1, ... )
22
SyntaxSelect
der SQL-SELECT-Anweisung*
6.5.9
from where
SELECT
ziel-liste
**
FROM
relation
ALL
variable
,
DISTINCT
WHERE
where-Bedingung
GROUP BY
attr-ref
attr-ref
,
HAVING
nur die Ergebnisdarstellung betreffend
have-Bedingung
ORDER BY
attr-ref
ASC
DESC
* entnommen aus: K. Neumann:
Datenbanktechnik für Anwender.
Carl Hanser Verlag, München Wien, 1996
** vereinfacht!!
Datenbanksysteme 1
attr-ref
21.01.2008
,
262
6.5.10 Joins
XXX S. 281
6.5.11 Sichten
CREATE VIEW
sichtname AS SELECT relationenname FROM ... WHERE ...
6.5.12 Zugrisrechte
über GRANT
7 Transaktionen / Fehlerbehandlung
Eine Transaktion ist eine Folge zusammengehöriger Operationen auf der Datenbank, die die
ACID-Eigenschaften erfüllen muss.
7.1 ACID-Eigenschaften
erstmals formuliert von Härder / Reuter 1983
atomicity:
Eine TA wird entweder komplett oder gar nicht ausgeführt.
consistency:
TA überführt Datenbank von einem logisch konsistenten Zustand in einen lo-
gisch konsistenten Zustand.
isolation:
Änderungen innerhalb einer TA werden erst beim Commit (End-of-Transaction)
für andere Nutzer sichtbar.
23
durability:
Alle Änderungen einer erfolgreich abgeschlossenen TA müssen auch im evtl. Feh-
lerfall wiederherstellerbar sein.
7.2 Fehlerszenarien
Transaktionsversagen:
Eine einzelne TA wird abgebrochen (durch Benutzer, Anwendung
oder DBMS)
R1:
DBMS setzt betroene TA auf Anfangszustand zurück, alle Änderungen werden
rückgängig gemacht (Transaction Rollback) mit before images
Systemversagen:
Das DBMS stürzt ab. Hauptspeicherinhalt geht verloren, Festplattenin-
halte noch vorhanden
R2: Nachfahren (Redo) aller Transaktionen seit letztem Checkpoint (wegen Dauerhaftigkeit) mit after images
R3: Zurücksetzen (Undo) noch nicht beendeter Transaktionen (wegen Atomarität) mit
before images
Externspeicherversagen:
Datenverlust auf Externspeicher und damit Datenbank ganz oder
teilweise zerstört
R4:
Backup muss eingespielt werden, anschlieÿendes Nachfahren mit after images
Alle Änderungen von Transaktionen müssen protokolliert werden. Hierzu benötigt man zum
einen before images mit dem Stand vor der Transaktion und zum anderen after images mit
dem Stand nach der Transaktion.
7.3 Bemerkungen
7.3.1 Checkpoints
Problem beim Nachfahren:
Lösung:
Wie weit muss in der Vergangenheit begonnen werden?
Checkpoints denieren konsistente Datenbankzustände in vordenierten Intervallen.
Dabei wird der Puerinhalt komplett in die Datenbank geschrieben. Dies minimiert den
Aufwand für R2-Recovery.
7.3.2 Dirty Data
Der Begri dirty data wird sowohl im Zusammenhang mit Transaktionen genutzt (uncommited
data) als auch für geänderte Daten, die noch nicht auf der Festplatte gesichert wurden (change
ag).
7.3.3 Page Cleaner
Puer wird nicht nur zum Checkpoint auf die Festplatte geschrieben, sondern zu unplanbaren
Zeitpunkten (z.B. Puer voll). Um dies zu vermeiden, wird in Produkten ein proaktiver Page
Cleaner eingesetzt, der bei geringer Last auf der Datenbank den Puer möglichst weit von
schmutzigen Daten (= Daten nicht auf Externspeicher vorhanden) befreit.
24
7.3.4 Steal / No Steal
Bei der Steal-Strategie können schmutzige Daten (= uncommited data) aus dem Puer
bereits vor Transaktionsende auf die Festplatte geschrieben werden. (Produkte bevorzugen
Steal)
7.3.5 Write-Ahead Logging
Vor dem Schreiben eines Datenblocks in die Datenbank muss der zugehörige Log-Eintrag auf
der Platte geschrieben sein, um bei eventuellem Ausfall nachfahren zu können.
7.3.6 Group Commit
Datenblöcke im Log-Puer sind meist nicht komplett gefüllt, das Datenbanksystem kann
über Group Commit einzelne Transaktionen zu Gruppen zusammenfassen, die gemeinsam
freigegeben werden können. Zum Commit-Zeitpunkt wird über Teilnahme am Group Commit
entschieden.
7.3.7 Datenvolumen der Log-Dateien
Eigentlich werden before images von abgeschlossenen TAs und after images von TAs vor dem
letzten Checkpoint für R2-Recovery nicht mehr benötigt. Leider ist selektives Löschen der
nicht benötigten Logs zu teuer und after images werden noch für R4-Recovery benötigt. Als
Lösung bietet sich an, das Log automatisch zu archivieren und den Datenplatz zyklisch zu
überschreiben.
7.3.8 Backup
Probleme beim Backup ergeben sich durch sehr groÿe Datenmengen und die Behinderung des
laufenden Betriebs.
Online-Backup
während laufendem Betrieb beispielsweise über zweites System
Paralleles-Backup
von mehreren Datenbank-Geräten auf mehrere Sicherungsgeräte
Inkrementelles Backup
Partielles Backup
sichert nur die Änderungen seit dem letzten Vollbackup
sichert nur Teile der gesamten Datenbank, andere Teile zu anderer Zeit
In den meisten Systemen werden die Verfahren gemeinsam genutzt.
7.3.9 Force / No Force
Force fordert, dass geänderte Platten direkt beim Commit auf die Festplatte geschrieben
werden, No Force erst später. (Produkte bevorzugen No Force)
25
7.3.10 Atomic / Not Atomic
Bei atomarem Fortschreiben ist die Datenbank immer in einem wohldenierten Zustand, bei
nicht atomarem Fortschreiben in irgendeinem Zustand. (Produkte bevorzugen Not Atomic)
8 Synchronisation im Mehrbenutzerbetrieb
8.1 Fehlerklassen und Probleme bei unkontrolliertem Mehrbenutzerbetrieb
Lost-Update-Problem:
Zwei TAs arbeiten auf ihren gelesenen Zuständen und Schreiben
nacheinander auf die Datenbank. Erstes Ergebnis wird dabei vom zweiten überschrieben.
Inkonsistente Analyse:
Eine TA ändert Attribute während eine andere TA lesende Analysen
durchführt. (Ehefrau verheiratet, Ehemann nicht mehr)
Phantomproblem
(Spezialfall der inkon. Analyse): Einfügen neuer Datensätze während eine
andere TA eine Analyse durchführt (z.B. Integritätsregel verletzt, obwohl auf Datenbank
konsistent)
→
sehr teuer zu behebn, da Phantome nicht sperrbar (nur Tabellensper-
ren?), Praxis lebt meist mit Phantomproblem
Nicht wiederholbares Lesen
(Spezialfall der inkon. Analyse): TA erhält bei wiederholen-
der Analyse unterschiedliche Ergebnisse, weil eine andere TA unterdessen Änderungen
vornimmt
→
Benutzer kann also mitbekommen, dass es andere Benutzer gibt
Abhängigkeit von nicht freigegebenen Änderungen:
Eine verändernde TA wird zurück-
gesetzt, obwohl unterdessen eine andere TA bereits die Werte ausgelesen hat.
8.2 Concurrency Control / Synchronisation
Eine Synchronisation wird im Mehrbenutzerbetrieb benötigt. Sperren stellen dabei eine (naheliegende) Möglichkeit dar, es gibt aber auch andere.
Logischer Einbenutzerbetrieb bei physischem Mehrbenutzerbetrieb
Es sollen nur solche Datenbankzustände erzeugt werden könne, die auch bei einer seriellen
Abarbeitung der Transaktionsmenge entstehen können. (Serialisierbarkeit )
8.3 Pessimistic Concurrency Control (PCC)
Beim pessimistischen Ansatz geht man davon aus, dass etwas passieren könnte und schlieÿt
dies durch Sperrung der entsprechenden Ressource für andere TAs aus.
8.3.1 Sperr- und Freigabestrategien
Sperrstrategien:
TA sperrt alle benötigten DB-Objekte zu TA-Beginn (preclaiming ) oder
jeweils spätestens beim Zugri (sukzessives Sperren)
26
Freigabestrategien:
Sperren zum Ende der TA freigeben (lange Sperren) oder zu einem
früheren Zeitpunkt, wenn diese nicht mehr benötigt (kurze Sperren)
Für Schreibsperren wird meist sukzessives Sperren mit langen Sperren genutzt, bei Lesesperren
sukzessive kurze Sperren.
8.3.2 Sperrgranulate
Es existieren viele Möglichkeiten der Sperrgranulatie: logische DB-Objekte wie Datenelemente,
Sätze (Tupel) und Tabellen oder physische DB-Objekte wie Seiten, Datenbanksegmente und
Datenbank.
Für hohe Parallelität und Performance muss ein Kompromiss gefunden werden, daher heute
in den meisten Systemen folgende Granulate implementiert: Tupel, Relationen, Segmente und
Datenbank
8.3.3 Sperrmodi
Schreibsperren (eXclusive):
Es darf nur eine TA das Objekt verändern, andere Zugrie
müssen warten
Lesesperren (Shared):
Es dürfen mehrere TAs parallel lesen, aber keine X-Sperre existieren
8.3.4 Sperrhierarchie / Intention Locks
TAs müssen sich an Sperrprotokoll halten und Vorhaben in höheren Ebenen ankündigen (Intention Shared / Intention eXclusive). Dabei muss top-down angekündigt und bottom-up
freigegeben werden.
Sperrgraph / Wartegraph
8.3.5 Sperreskalation
Unter Umständen kann es vorkommen, dass eine TA viele kleine Sperren setzt (UPDATE
• Information
welche
Resource
aktuell
gesperrt
hat / wer
angest darüber,
...). Dies führt wer
zu einer
Vielzahl von
Aufrufen an den
Sperrverwalter,
Sperrtabelle
im Hauptspeicher wächst. Als Lösung kann die TA ihre Sperren in eine höhere Hierarchie
auf welche
Ressource wartet (weil sie aktuell gesperrt ist) ! kann in
verlagern (z.B. von Tupel auf Tabelle), allerdings nicht immer möglich, da auch andere TAs
Form eines
Graphen
werden (ob´s auch als solcher
nicht kompatible
Sperrenaufgefasst
halten können.
implementiert ist – oder sich der Graph als „Sicht“ auf die
8.3.6 Sperrgraph / Wartegraph
Sperrtabelle
oben darstellt! – ist dabei zunächst unerheblich)
Wer auf wen wartet, kann in einem Graph dargestellt werden.
• Beispiel für Sperrgraphen:
R1
TAx
TAy
R3
TAw
R2
TAz
• Semantik: TAx wartet auf die Freigabe von Ressource R1 durch TAy
etc. etc.
27
• Nutzung des Sperrgraphen: Vor allem
auch zur Deadlock-Erkennung,
Deadlocks führen nämlich zu Zyklen im Graphen (erkennbar mittels
Standard-Graphenalgorithmen)
• Deadlock-Auflösung durch systemseitiges „Abschießen“ (Rücksetzen,
Transaction Failure) einer Transaktion
• Problem hierbei u.a.: Verhungern („starvation“) einer Transaktion
Dabei wartet TAx auf die Freigabe der Ressourcen R1 durch TAy und TAy wiederum auf
die Freigabe der Ressource R3 durch TAw ...
8.4 Optimistic Concurrency Control (OCC)
Der optimistische Ansatz geht vom Gelingen der TA aus und greift nur im Fehlerfall durch
Zurücksetzen und erneutes Starten ein.
Sperrprobleme und Performance-Einbuÿen durch Sperrverwaltung fallen weg, dafür muss
bei Konikten die bereits durchgeführte TA zurückgesetzt werden. Bei vielen Konikten ist der
Sperransatz daher performanter, treten Konikten selten auf, so ist die OCC performanter.
Im Allgemeinen ist PCC die Standard-Einstellung der DBMSe.
8.4.1 BOCC / FOCC
Man unterscheidet zwischen zwei Verfahren der OCC.
Backward Oriented Concurrency Control:
Validierung nur gegenüber bereits beendeten
Transaktionen
Forward Oriented Concurrency Control:
Validierung gegen noch laufende Transaktionen
8.5 Kurzzeitsperren / Latches
Neben der aufwändigen Sperrverwaltung für TAs benötigt ein DBMS kurze Sperren bei
Schreibzugrien, beispielsweise im System-Cache für einzelne Seiten. Diese Kurzzeitsperren
oder Latches müssen sehr performant sein und werden in der Regel nur sehr kurz gehalten.
Kurzzeitsperren sind immer exklusiv und müssen über eine atomare Funktion des Prozessors
(Compare and Swap) umgeschaltet werden, damit sich zwei Operationen nicht in die Quere
kommen.
Implementierung unter Umständen als busy wait (statt lazy wait ), ferner muss darauf
geachtet werden, dass Latches nicht lang werden (z.B. durch I/O, Paging des Puers)
können.
9 Embedded SQL / API
Impedance Mismatch:
Der Mengenorientierung und Deskriptivität in SQL steht eine satz-
orientierte und prozedurale Programmiersprache gegenüber, beide kaum vereinbar. Problematisch sind zudem unvorhersehbare Gröÿe von SQL-Anfragen, unterschiedliche Datentypen und groÿe Attributlängen.
9.0.1 Konzepte für Datenbankzugri aus Anwendungsprogramm
Man unterscheidet zwischen fünf grundlegenden Konzepten, die sich im Bezug auf Integrationsgrad unterscheiden. Enge Bindung zwischen Programmiersprache und DB-Sprache hat
Einuss auf Benutzbarkeit, Performance und Erweiterbarkeit.
28
Pre-Compiler Ansatz:
Programmcode enthält markierte DB-Anweisungen, die von einem
Precompiler vorübersetzt und eingebaut werden. (Beispiele: eSQL)
DBMS-Aufrufe als Unterprogramme (Call Level Interface / CLI):
Datenbankanbindung
über Programmierschnittstellen (Framework), kein Precompiler oder Programmiersprachenerweiterung nötig. (Beispiele: ODBC, JDBC)
Einfache Programmiersprachenerweiterung:
Erweiterung der Programmiersprachensyn-
tax und -semantik, damit ist ein erweiterter Programmiersprachencompiler notwendig.
(Beispiel: Einbindung von CODASYL-Datenbanken)
Komplexe Programmiersprachenerweiterung:
Auch Datentypen werden in die Program-
miersprache eingebunden, z.B. Relation as a Data Type oder Programmschleifen über
Tabelleninhalte. Relationale Objekte wie normale Programmiersprachenobjekte. (Beispiele: Pascal/R, Modula/R, Data Base Programming Language (DPBL))
4GL-Sprachen:
höhere Programmspiersprache mit integriertem Datenbankzugri, meist in
proprietären Entwicklungen zu nden. (Beispiele Advanced Business Application Programming (ABAP von SAP), NATURAL (Software AG))
9.1 Precompiler / Vorübersetzung
Die Vorübersetzung ist ein wichtiger Ansatz in der Praxis und in embedded SQL (ESQL) umgesetzt. Der Precompiler muss nur geringe Kenntniss über die Host-Programming-Language
(C++, Java ...) besitzen, er sucht und ersetzt nur markierte Teile mit Präx EXEC SQL.
Der Precompiler kann bereits syntaktische Prüfungen durchführen, die eingebetteten SQLAnweisungen werden an den Server geschickt, dort als Package gespeichert und analysiert.
Der Precompiler erzeugt Kontrollblöcke (Hilfsvariablen) für SQL-Statusinformationen und
Unterprogrammaufrufe für Verbindungsaufbau, Ausführung und Verarbeitung.
9.2 Cursor-Konzept
Das Cursor-Konzept wurde entwickelt, um den Impedance Mismatch zu lösen. Der DatenbankCursor ist eine spezielle Laufvariable zum satzweisen Abarbeiten der Ergebnismenge einer
SQL-SFW-Anweisung.
ˆ
DECLARE CURSOR: Legt Bindung an eine SQL-SFW-Anweisung fest.
ˆ
OPEN CURSOR: Setzt Cursor vor den ersten Tupel der Ergebnismenge, die auch leer
sein darf.
ˆ
FETCH CURSOR: Bewegt Cursor mit Schrittweite 1 über Ergebnismenge und überträgt
ein Ergebnistupel ins Anwendungsprogramm.
Bei Anfragen, die maximal ein Ergebnistupel liefern, kann auf das Cursor-Konzept verzichtet
werden.
29
9.2.1 Programmstruktur mit Cursor am Beispiel von ESQL
EXEC SQL BEGIN DECLARE SECTION;
int betrag, nummer, umsatz; string name;
// deniert gemeinsame Variablen
EXEC SQL END DECLARE SECTION;
EXEC SQL INCLUDE SQLCA;
// SQL Communication Area z.B. für Fehler
EXEC SQL DECLARE c CURSOR FOR
SELECT KdNr, Name, Umsatz
FROM Kunde
WHERE umsatz>:betrag;
// nur hier Variablen möglich
read betrag;
// Variable muss vor OPEN CURSOR eingelesen sein
EXEC SQL OPEN c;
// setzt Cursor vor den ersten Ergebnistupel
EXEC SQL FETCH c INTO :nummer, :name, :umsatz;
// holt ersten Datensatz
while (SQLCA.SQLCODE==0)
{
output (nummer, name, umsatz);
EXEC SQL FETCH c INTO :nummer, :name, :umsatz;
}
EXEC SQL CLOSE c;
EXEC SQL COMMIT / ROLLBACK WORK;
9.3 dynamisches ESQL
ESQL erlaubt nach dem ersten Standard nur SQL-Anweisungen, die im Programm zum Übersetzungszeitpunkt vollständig bekannt waren (halb-dynamisch auch Werte von Host-Variablen
im WHERE-Bereich, die beispielsweise durch Platzhalter ersetzt werden). Auch die Struktur
des Ergebnisses muss bereits bekannt sein. Statisches ESQL bietet damit den Vorteil, dass
bereits umfangreiche Prüfungen und Optimierungen zum Übersetzungszeitpunkt möglich sind
und die Handhabung einfach ist. Allerdings ist statisches ESQL sehr unexibel.
dynamisches ESQL:
SQL-Anweisungen können bei Bedarf angepasst werden, Ergebnisstruk-
tur muss erst zur Laufzeit bekannt sein, Cursor können gegebenenfalls dynamisch erzeugt werden. dynamisches ESQL benötigt die SQL Description Area (nach der SQL
Declare Section).
10 Normalformen / Erweiterungen
10.0.1 Probleme nichtadäquater Datenmodellierung
Am Beispiel Kursleiter(PersNr, Name, PersSachb, PPersNr, TelNr)
Insertion Anomaly:
Ein neuer Personalsachbearbeiter kann nicht eingefügt werden, wenn
nicht gleichzeitig ein betreuter Mitarbeiter eingefügt wird.
Deletion Anomaly:
Informationen über Sachbearbeiter werden mitgelöscht, wenn ein Mit-
arbeiter gelöscht wird.
Update Anomaly:
Die neue Telefonnummer einer Sachbearbeiters muss in mehreren Zeilen
geändert werden.
30
⇒
Informationen über verschiedene Entitytypen sollten nicht in einer Relation gespeichert
werden (Lösung: zwei Relationen mit Fremdschlüsselbeziehung)
10.1 Normalformen
Jede Normalform schränkt gegenüber ihrer übergeordneten die Menge der zulässigen relationalen DB-Schmata weiter ein. Höhere Normalformen bestehen damit aus einer gröÿeren
Zahl von (kleinen) Relationen und setzen mehr Wissen über die Daten / Miniwelt voraus
(inhaltliche Abhängigkeiten, Zusammenhänge).
extended non rst normal form (eN F 2 ): Beliebige Kombination von Tupeln, Mengen und
Listen möglich, volle Orthogonalität
non rst normal form (N F 2 ): Erlaubt Subrelationen (geschachtelte Relationen, nested Relations). Ein Tupel kann seinerseits wieder aus Relationen bestehen. Damit werden
Baumstrukturen möglich. Ansonsten nur Relationen, Tupel und atomare Attribute erlaubt.
1NF:
2NF:
Alle Attribute sind atomar
Nichtschlüsselattribute müssen voll funktional abhängig von Schlüsselattributen sein,
jede Relation modelliert nur einen Sachverhalt.
3NF:
Keine trans. Abhängigkeit zwischen Schlüssel- und Nichtschlüsselattribute
BCNF-Telation (Boyce/Codd):
⇒
Nur Abhängigkeiten von Schlüsselattributen
Höhere Normalformen nicht um jeden Preis anstreben, sondern auch Konsequenzen
(viele kleine Relationen unhandlich und erfordern viele Joins, Detailwissen könnte sich ändern)
berücksichtigen.
10.2 Funktionale Abhängigkeiten / Functional Dependencies
Funktionale Abhängigkeitten liefern Aussagen über Abhängigkeiten zwischen Attributen, müssen aus der realen Welt abgeleitet werden und sind allgemeingültig (nicht nur für vorliegende
(meist unvollständige) Datenkonstellation).
Y ist
funktional abhängig von
der zwei Tupel
t1
und
t2
X→Y
ˆ
X
X → Y ), wenn es keine
X x1 = x2 aber
y1 6= y2 haben.
(kurz
den selben Wert für
⇐⇒
Relation
R
geben kann, in
verschiedene Werte für
Y
∀(t1 , t2 ) : x1 = x2 ⇒ y1 = y2
Aus konkreter Datenkonstellation darf nur auf fehlende FD geschlossen werden, keinesfalls FD-Nachweis.
ˆ
In einem Relationstyp sind alle Attribute vom identizierenden Attribut (Schlüssel) funktional abhängig.
ˆ
Die Menge aller FDs heiÿt closure of F (transitive Hülle)
31
10.3 weiteres
32