9: Datenbanken Dateien vs. Datenbanken (1)

9: Datenbanken
Inhalt:
 Dateien vs. Datenbanken
 Datenbanken: Tabellen, Attribute und Datentyp
 Datenmodellierung mit dem
Entity-Relationship-Modell
 Normalformen einer Datenbank
 Structured Query Language SQL
 Tabellen und Abfragen
 Zugriff aus einer C++ -Anwendung auf eine Datenbank
Peter Sobe
1
Dateien vs. Datenbanken (1)
Dateien:
 sind benannte Objekte, die eine Speicherung von
Anwendungsdaten auf einem linearen Adressraum
zulassen
 Persistente Speicherung, d.h. Daten bleiben nach
Beendigung der Anwendung und auch nach Abschalten
des Systems erhalten
 Dateisystem als Teil des Betriebssystems sorgt für Zugriff
mit Dateinamen, Verzeichnisse, Pufferung, Zugriffsschutz
 Datei-Daten können beliebig strukturiert sein:
 Binärdaten
 Textdaten (lesbarer Text)
 XML Datenformate
 es werden keine Regelmäßigkeiten der abgespeicherten
Datenstrukturen vorausgesetzt.
Peter Sobe
2
Dateien vs. Datenbanken (2)
Dateien (Fortsetzung):
 Wenn Daten eine Struktur bzw. Regelmäßigkeiten
aufweisen, so wird dieser Umstand nicht vom Dateisystem
gespeichert und nicht verwaltet.
 Hinweis auf Typ/Struktur der Datei über Dateityp, z.B.
bild.jpg ist eine Bilddatei im JPEG-Format … aber nicht
mehr
 Zugriff auf Daten in vollständiger Kontrolle des
Anwendungsprogramms
 Konkurrierende Zugriffe durch mehrere Anwendungen
sind nicht berücksichtigt und werden höchstens durch
Sperren der gesamten Datei vermieden.
Peter Sobe
3
Dateien vs. Datenbanken (3)
Datenbanken:
 Tabellen mit gleichartig aufgebauten Datensätzen
 Beziehungen zwischen Tabellen durch geeigneten
Datenbankentwurf
 Zugriff entweder durch Satzzugriff auf einzelne Sätze einer
Tabelle
 oder Zugriff durch eine Abfragesprache (SQL)
 Die Datenbank-Tabellen werden als Dateien gespeichert,
oder als Image auf einem Speichermedium, ein direkter
Zugriff über Datei-Operation ist aber nicht vorgesehen.
 Die regelmäßige Struktur der Daten wird in der Datenbank
gespeichert und zur Steuerung der Zugriffe ausgenutzt.
Peter Sobe
4
Dateien vs. Datenbanken (4)
Datenbanken (Fortsetzung):
 Ein Datenbank-Management-System dient zur Laufzeit dem
Zugriff auf die Datenbank. Das sind i.d.R. Serverprozesse,
die im Hintergrund ausgeführt werden.
 Persistente Speicherung, d.h. Daten bleiben nach
Beendigung der Anwendung und auch nach Abschalten des
Systems erhalten (wie Dateien)
 Konkurrierende Zugriffe erlaubt, Verhalten bei Konflikten
durch Transaktionen geregelt
Peter Sobe
5
Dateien vs. Datenbanken (5)
Datenbank
DB-Server
Metadaten
(Data
Dictionary),
daten-modellbezogen
Peter Sobe
organisatorische Da-ten
(Schlüs-sel,
Indexdateien, ...),
bezogen auf
internes
Schema
reale Daten
Installation
Nutzerverwaltung
bezogen auf
externes
Schema
Datenbanksoftware
organisatorische
Festlegung zum
Datenbankbetrieb
(DatenbankAdministrator)
Datenbasis
Hardware
Datensicherheit
Datenbankbetriebssystem
(DBMS)
Datenbanksprache
Nutzerprogramme
Entwicklungsumgebung
SQL
6
Tabellen, Attribute und Datentyp
Tabellenname
Attribut
Wetter
Ortsnr
Ortsname
Temperatur
Luftdruck
1
Dresden
22
1012
2
Leipzig
20
1010
3
Berlin
25
998
…
…
…
…
Tupel,
auch
Datensatz
oder Zeile
Wert mit einem
speziellen Datentyp, der
je Attribut definiert ist
Peter Sobe
7
Datenmodellierung mit dem
Entity-Relationship-Modell







Definition der mathematischen Relation
Wertebereiche, Eigenschaften und Relationenformat
Definition der Relation im Relationalen Datenmodell
Entität, Entitätsmenge und Primärschlüssel
Beispiele für Entitäten
Tabellensicht der Relation
Definition des Relationstyps
Peter Sobe
8
Definition der mathematischen Relation (1)
Das Relationale Datenmodell (RM) basiert auf dem mathematischen
Relationenbegriff. Durch die Einfachheit (Tabellensicht) und klare
mathematische Basis konnte sich das RM in der Entwicklung der
Datenbanktechnologie seit 1970 durchsetzen.
(mathematische) Definition der Relation:
Gegeben seien die nichtleeren Mengen W1, W2, ... Wn mit
W1xW2x...xWn = {(w1,w2,...,wn) | wi є Wi (i=1,2,...,n)}
Dann ist jede nichtleere Teilmenge R  W1xW2x...xWn eine n-stellige
Relation über W1, W2, ..., Wn . Die Wi müssen nicht alle paarweise
verschieden sein.
Ein Tupel (w1,w2,...,wn) =
(4989; Möbius; Wilhelm; Ja; 01.01.66; 80686; gesch; 2; DBADM; 4.360,50).
könnte z.B. zu R gehören. Als Trennzeichen zwischen den Tupelwerten
wurde das Semikolon verwendet, da das Komma in Dezimalzahlen
vorkommen kann.
Peter Sobe
9
Definition der mathematischen Relation (2)
(4989; Möbius; Wilhelm; Ja; 01.01.66; 80686; gesch; 2; DBADM; 4.360,50).
Für das obige Beispiel wären die Mengen Wi konkret festgelegt:
W1 ganze Zahl (int), W2 Zeichenkette (varchar), W4 Besonderes (bit), W5
Datum und Zeit (datetime), …, W10 Währung (money).
Peter Sobe
10
Wertebereiche, Eigenschaften
und Relationenformat (1)
Wir deuten jetzt die Mengen Wi als Wertebereiche (Domänen) und die
wi є Wi als Werte und verbinden die Wi , genauer das Kreuzprodukt
W1xW2x...xWn , mit einer Interpretation I
E={E1,E2,...,En } = I(W1xW2x...xWn ) für i=1,2,...,n
Diese Ei werden als Eigenschaften (Attribute) von Entitäten gedeutet.
Für das obige Beispiel wären die Eigenschaften Ei wie folgt gedeutet:
E1 MNR (Mitarbeiternummer), E2 Name (Familienname),
E4 Geschlecht , E5 Geburtsdatum, … ,E10 Gehalt.
Mit dieser Semantik würde das Tupel
(4989; Möbius; Wilhelm; Ja; 01.01.66; 80686; gesch; 2; DBADM; 4.360,50)
die Entität „Herr Möbius“ eindeutig charakterisieren.
Peter Sobe
11
Wertebereiche, Eigenschaften
und Relationenformat (2)
E nennt man Relationenformat.
Das Relationenformat bildet den Kern einer Relation im Sinne
der Datenbanktheorie. Zusammen mit der Interpretation definiert
das Relationenformat eine Relation im Sinne des Relationalen
Datenmodells. Manche Autoren betrachten als Relationenformat
gleich die Menge der Paare (Ei,Wi) für i=1,2,...,n .
An den Begriff Relation werden aber noch einige Forderungen
gestellt. Es ist möglich, dass ein Eigenschaftswert fehlt, d.h.
undefiniert ist. Dieser Fall wird durch den (Sonder-)Wert NULL
angezeigt.
Peter Sobe
12
Definition der Relation im Relationalen Datenmodell
Eine Relation R= R(E1,E2,...,En) ist eine Menge von Tupeln,
wobei R der Name der Relation, E={E1,E2,...,En } das
Relationenformat und die Ei (i=1,2,...,n) die Eigenschaften sind,
deren Werte wi aus den zugeordneten Wertebereichen Wi
stammen müssen. Die Ei , die zu einer Relation gehören,
müssen paarweise verschieden sein. Ist r ein Tupel der Relation,
bezeichnet wi = r.Ei den Wert der i-ten Eigenschaft des Tupels r є
R (W1xW2x...xWn ). n heißt Grad der Relation.
Peter Sobe
13
Charakteristische Eigenschaften der Relation
Eine Relation hat folgende charakteristische Eigenschaften:
1. R ist eine Menge. Damit gibt keine paarweise identischen
Tupel. R hat deshalb einen Primärschlüssel, der jedes Tupel
eindeutig identifiziert.
2. R ist eine Menge. Deshalb ist die Reihenfolge der Tupel in R
ohne Belang.
3. Die Reihenfolge der Eigenschaften Ei in R ist ohne Belang.
4. Die Eigenschaftswerte wi = r.Ei mit r є R müssen einfach sein,
d.h. dürfen nicht mengenwertig oder nicht strukturiert sein.
wi = NULL ist aber möglich.
Peter Sobe
14
Entität, Entitätsmenge und Primärschlüssel (1)
Eine Relation R im RM beschreibt damit eine Entitätsmenge. Jedes
Tupel r є R charakterisiert damit eindeutig eine Entität im zu
modellierenden Diskursbereich.
Eine Entität ist eine Person, Sache oder gedankliches Konstrukt, das im
zu modellierenden Diskursbereich real existiert und eindeutig
identifizierbar ist. Eine Entität ist Träger von Eigenschaften E1,E2,...,En.
Eine Entitätsmenge ist die Zusammenfassung aller Entitäten mit der
gleichen Menge von Eigenschaften {E1,E2,...,En }, die zu einer
bestimmten Zeit im Diskursbereich existieren. Eine Relation R mit dem
Relationenformat E eignet sich zur Beschreibung einer Entitätsmenge.
Man beachte, dass damit eine Relation während der Lebensdauer einer
Datenbank zeitabhängig ist.
Peter Sobe
15
Entität, Entitätsmenge und Primärschlüssel (2)
PS heißt Primärschlüssel der Relation R=R(E1,E2,...,En ), falls gilt:
1. PS  E und
2. PS ist in E identifizierende Eigenschaft bzw.
Eigenschaftskombination, d.h. jedes Tupel r є R
hat einen eindeutigen PS-Wert psr=r.PS und psr ≠ NULL.
Ein Primärschlüssel PS heißt minimal, falls es keine echte Teilmenge
PS‘ PS gibt, für die die obigen Beziehungen 1. und 2. gelten.
Peter Sobe
16
Beispiel
Entitätsmenge
( = Relation)
Einzur
Beispiel
zur Entitätsmenge
(Relation)
Die Entitätsmenge (Ausschnitt) könnte jetzt so aussehen (MNR
ist Primär-schlüssel):
MNR
1235
Name
Vorname
Krause
Steffen
2467
Sonntag
Thomas
2477
Thaler
Katja
3814
Walther
Philip
4724
Lüders
Anne
4962
Graumeier
Adolf
4989
Möbius
Wilhelm
4991
Karstens
Beate
4992
Rudolph
Claus
4994
Forschmann
Beatrix
5001
Claasen
Christian
5289
Meißer
Sven
5367
Willers
Lisa
.....
....
......
Geschl
Gebtag
Ja
13.04.66
Ja
27.11.50
Nein
09.12.58
Ja
11.03.66
Nein
01.06.71
Ja
09.09.51
Ja
01.01.66
Nein
24.09.64
Ja
PLZ
80995
Famst
verh
Kinder
JobKurz
2
PROGR
Gehalt
1.850,50 €
10117
verh
4
PLEIT
01069
verw
1
PLEIT
4.010,50 €
80796
gesch
0
KONST
2.159,00 €
14197
ledig
0
ORGAN
1.600,00 €
80686
verh
5
ALEIT
6.575,00 €
80686
gesch
2
DBADM
80809
verh
3
ALEIT
5.950,00 €
18.03.66
01069
verw
2
NZADM
2.375,00 €
Nein
03.04.65
01067
ledig
1
SEKRE
2.750,50 €
Ja
02.12.62
01249
verh
0
PROGR
3.050,50 €
Ja
29.12.59
80337
gesch
1
KONST
2.450,00 €
Nein
13.06.55
80999
verh
2
PROGR
2.870,00 €
Peter Sobe
3.200,00 €
2.360,50 €
17
TabellensichtTabellenansicht
der Relation
der Relation
Eine Entitätsmenge / Relation kann als einfache Tabelle dargestellt
werden. Die Tabelle trägt den Namen der Relation. Die
Spaltenbezeichnungen sind die Eigenschaften Ei i=1,2,...,n. Die Spalten
selbst enthalten die Werte r.Ei zur Eigenschaft Ei aller zur Zeit in der
Relation erfassten Entitäten. Werte einer Spalte sind keine Menge
sondern ein „bag“, da Werte mehrfach vorkommen können. Die Zeilen
(Tupel) der Tabelle repräsentieren die Entitäten. Diese r є R sind
paarweise verschieden. Ein Tupel r enthält für die dargestellte Entität alle
Werteausprägungen aller Eigenschaften. Es ist üblich, den
Primärschlüssel zu unterstreichen.
MNR
Name
Vorname
Geschl
Gebtag
PLZ
Famst
Kinder
JobKurz
Gehalt
1235
Krause
Steffen
Ja
13.04.66
80995
verh
2
PROGR
1.850,50 €
2467
Sonntag
Thomas
Ja
27.11.50
10117
verh
4
PLEIT
3.200,00 €
2477
Thaler
Katja
Nein
09.12.58
01069
verw
1
PLEIT
4.010,50 €
3814
Walther
Philip
Ja
11.03.66
80796
gesch
0
KONST
2.159,00 €
4724
Lüders
Anne
Nein
01.06.71
14197
ledig
0
ORGAN
.....
....
......
Peter Sobe
1.600,00 €
18
Definition
des Relationentyps
Definition des
Relationstyps
Da eine Relation R im RM eine Entitätsmenge beschreibt und damit
zeitabhängig ist, besteht die Notwendigkeit, eine zeitunabhängige
Beschreibung von R vorzunehmen. Mit dem Begriff des Relationstyps wird
diese zeitunabhängige, formale Beschreibung einer Relation im RM
realisiert.
Definition des Relationstyps:
R( E | IB ) heißt Relationstyp der Relation R wenn gilt:
- R ist der Name der Relation
- E = {E1,E2,...,En } ist das Relationenformat von R
- Ei sind die Eigenschaften von R, deren Werte aus den zugeordneten
Wertebereichen Wi stammen müssen
- IB ist eine Menge von semantischen Integritätsbedingungen (constraints)
In der Datenbanktechnologie sind neben der semantischen Integrität noch
die operationale und physische Integrität von Bedeutung.
Peter Sobe
19
Entwurf von Relationalen Datenbanken (1)
In der Regel werden Diskursbereiche durch mehrere Relationen
(Tabellen) abgebildet.
Ziele:
 Vermeiden von Redundanz in Relationen
 Vermeiden von Inkonsistenzen
 Effizienzsteigerung, wenn nur wirklich benötigte Daten gelesen
werden, bzw. nur die Informationen in wenigen Tupeln
aktualisiert werden müssen.
Beispiel: eine Datenbank über Verkäufe, eine Tabelle ‘Gesamt‘
Gesamt
Verkaufs-Nr.
Produkt
Einzelpreis
Anzahl
Käufer
Käufer-Adresse
…
…
…
…
…
…
Peter Sobe
20
Entwurf von Relationalen Datenbanken (2)
Gesamt
Verk.-Nr.
Produkt
Einzelpreis
Anzahl
Käufer
Käufer-Adresse
1
Tomate
0.20
4
Heidi
33333 Wiesenhain,
Am Waldrand 1
2
Apfelsaft
1.40
2
Heidi
33333 Wiesenhain,
Am Waldrand 1
3
Katzenfutter
2.30
1
Kurt
33221 Bachhagen,
Hauptstr. 23
4
Apfelsaft
1.40
3
Kurt
33221 Bachhagen,
Hauptstr. 23
5
Gurke
0.55
1
Peter
33200 Feldstadt
Am Markt 5
6
Tomate
0.20
8
Peter
33200 Feldstadt
Am Markt 5
7
Bier
0.78
4
Kurt
22331 Bachhagen,
Hauptstr. 23
…
…
…
…
…
…
Redundanzen und Inkonsistenz
Peter Sobe
21
Entwurf von Relationalen Datenbanken (2)
Produkte
Verkaeufe
Produkt-ID
Name
Preis
T
Tomate
0.20
42
A
Apfelsaft
1.40
2
42
K
Katzenfutter
2.30
K
1
20
G
Gurke
0.55
4
A
3
20
B
Bier
0.78
5
G
1
17
…
6
T
8
17
Kunden
7
B
4
20
Käufer-ID
Name
Adresse
…
…
…
…
17
Peter
33200 Feldstadt
Am Markt 5
20
Kurt
33221 Bachhagen,
Hauptstr. 23
42
Heidi
33333 Wiesenhain,
Am Waldrand 1
…
…
…
Verk.
Nr.
ProduktID
Anzahl
1
T
4
2
A
3
Käufer-ID
 Redundanz ist jetzt
beseitigt
 Inkonsistenzen können jetzt
nicht mehr auftreten
Peter Sobe
…
22
Entwurfsregeln (1)
Identifikation der Entitätsmengen und der Beziehungsmengen
Regel 1: Jede Entitätsenge muss erst einmal als eigenständige
Tabelle mit einem eindeutigen Primärschlüssel definiert werden.
Merkmale gehen als Attribute in die Tabellen ein.
Regel 2: Beziehungsmengen können als eigenständige Tabellen
definiert werden. Die Merkmale der Beziehungen erscheinen in
den Attributen der Tabelle. Der Verweis aus die Entitätsmengen
geschieht durch die Aufnahme der Schlüssel in die Tabelle
(Fremdschlüssel).
Peter Sobe
23
Entwurfsregeln (2)
Entitäten
Beziehungen
Abteilung
1
A. Meier:
Relationale Datenbanken –
Leitfaden für die Praxis.
5. Auflage, 2004 Springer
Verlag
m
Unterstellung
Abteilungsleiter
c
1
Mitarbeiter
Beispiel aus:
mc
Zugehörigkeit
Regel 1:
m
Projekt
Einzelne Tabellen für Entitäten
Abteilung
Anr
Bezeichnung
…
…
Peter Sobe
Mitarbeiter
Projekt
Pnr
Bezeichnung
…
…
Mnr
Name
Vorname
…
…
…
24
Entwurfsregeln (2)
Entitäten
Beziehungen
Abteilung
1
m
Unterstellung
Abteilungsleiter
c
Assoziationstypen:
1 – genau ein
c – kein oder ein
m – ein oder mehrere
mc – kein, ein oder
mehrere
1
Mitarbeiter
mc
Zugehörigkeit
Regel 2:
m
Projekt
Tabellen oder
Fremdschlüsselbeziehungen
für Beziehungen
Peter Sobe
25
Entwurfsregeln (3)
Beziehungs-Komplexität:
Die Mächtigkeit der in Beziehung stehenden Mengen definiert
verschiedene Klassen:
von/zu
1
c
m
mc
1
(1,1)
(1,c)
(1,m)
(1,mc)
c
(c,1)
B1 (c,c)
(c,m)
B2 (c,mc)
m
(m,1)
mc
(mc,1)
B2
(m,c)
(m,m)
(mc,c)
(mc,m)
B3
(m,mc)
(mc,mc)
B1: einfach-einfache Beziehungen
B2: einfach-komplexe Beziehungen
B3: komplex-komplexe Beziehungen
Peter Sobe
26
Entwurfsregeln (4)
Regel 3:
Komplex-komplexe Beziehungen (m zu m, m zu mc,
mc zu m, mc zu mc) müssen als eigenständige
Tabelle definiert werden.
Mitarbeiter
mc
Zugehörigkeit
m
Projekt
Mitarbeiter
Projekt
Mnr
Name
Vorname
Mnr
Pnr
Prozent
Pnr
Bezeichnung
…
…
…
…
…
…
…
…
Zugehoerigkeit
Peter Sobe
27
Entwurfsregeln (5)
Regel 4:
einfach-komplexe Beziehungen (m zu 1, 1 zu m und
weitere) können ohne eigenständige Tabelle durch
die beigen zugeordneten Tabellen
der Entitätsmengen ausgedrückt werden.
Abteilung
m
Unterstellung
1
Mitarbeiter
Fremdschlüssel-Beziehung
Mitarbeiter
Abteilung
Anr
Bezeichnung
Mnr
Name
Vorname
…
…
…
…
…
Peter Sobe
Abt_Unterstell
28
Entwurfsregeln (6)
Regel 5:
einfach-einfache Beziehungen (1 zu 1, 1 zu c und weitere)
können ohne eigenständige Tabelle durch die beigen
zugeordneten Tabellen der Entitätsmengen
ausgedrückt werden.
Abteilung
1
c
Abteilungsleiter
Mitarbeiter
Fremdschlüssel-Beziehung
Abteilung
Anr Bezeichnung Abtleiter
…
Mitarbeiter
Mnr
Name
Vorname
…
…
…
…
Peter Sobe
Fremdschlüssel-Beziehung
Abt_Unterstell
29
Entwurfsregeln (7)
Regel 6:
Generalisierung – Eigenständige Tabellen für übergeordnete
Entitätsmenge und für jede Spezialisierung
Regel 7:
Part-Of-Beziehung - Eigenständige Tabellen für Entität und
Beziehungsmenge, falls Beziehungstyp komplex-komplex ist
… hier nur zur Vollständigkeit erwähnt.
Peter Sobe
30
Entwurfsregeln (9)
Wie wäre ein regelbasierter Entwurf für das eingangs benutzte
Beispiel ausgegangen?
Verk.-Nr.
Produkt
Einzelpreis
Anzahl
Käufer
Käufer-Adresse
…
…
…
…
…
…
mc
Produkt
Attribut
wird
gekauft
mc
Attribut
Einzelpreis
drei
Tabellen,
wie auf
Folie 22
Anzahl
Käufer
Attribut
Adresse
Peter Sobe
31
Normalformen (1)
Ziele:
 Vermeiden von Redundanz in Relationen – bei
ungünstiger Struktur der Tabellen würde gleiche
Information u.U. mehrfach gespeichert. Eine
Strukturierung entsprechend der dritten Normalform
verhindert das.
 Vermeiden von Anomalien – bei ungünstigen Entwurf
können Informationen u.U. ungewollt verloren gehen.
Peter Sobe
32
Normalformen (2)
Verk.-Nr.
Produkt
Einzelpreis
Anzahl
Käufer
Käufer-Adresse
…
…
…
…
…
…
Anomalien:
 Einfügeanomalie – Neue Sachverhalte können nicht
eingefügt werden. Im Beispiel oben kann keine neues
Produkt mit einem Preis eingefügt werden, ohne einen
Kaufvorgang zu beschreiben.
 Löschanomalie – Das Löschen von Kaufvorgängen
bedingt u.U. den Verlust von Produktinformationen und
Käuferdaten.
 Änderungsanomalie – Das Abändern eines Sachverhalts
verlang oft das Ändern vieler Datensätze (bei
Redundanz von z.B. Käufer-Adressen)
Peter Sobe
33
Zweck der Normalformen
Ein Datenbankentwurf nach dem Entity-Relationship-Modell bringt
die Tabellen automatisch in eine redundanzfreie und anomaliefreie
Struktur.
ERModell
regelbasierter
Entwurf
Existierender
Datenbestand
Umstrukturierter
Datenbestand
Redundanzfreie
und
anomaliefreie
Datenbank
Herstellung der
Normalformen
Für existierende Datenbanken können Probleme behoben
werden, indem das Vorhandensein der Normalformen geprüft wird
und diese durch Umstrukturierung der Tabellenstruktur hergestellt
werden.
Peter Sobe
34
Erste Normalform (1)
Eine Tabelle ist in der ersten Normalform (1NF), falls die
Wertebereiche der Merkmale atomar sind.
1NF verlangt, dass jedes Merkmal Werte aus einem
unstrukturierten Wertebereich aufnimmt. Damit dürfen keine
Mengen, Aufzählungstypen oder Wiederholungsgruppen in
den einzelnen Merkmalen vorkommen.
Beispiel für eine nicht erfüllte 1NF:
Matrnr
Name
Vorname
Studiengänge
11
Schmidt
Robert
{Mathemetik, Physik}
47
Schulze
Klaus
{Sport, Erziehungswissenschaften}
78
Peters
Karoline
{Informatik}
Peter Sobe
35
Erste Normalform (2)
Beispiel mit atomarem Wertebereich für Studiengang
Matrnr
Name
Vorname
Studiengang
11
Schmidt
Robert
Mathematik
11
Schmidt
Robert
Physik
47
Schulze
Klaus
Sport
47
Schulze
Klaus
Erziehungswissenschaften
78
Peters
Karoline
Informatik
Peter Sobe
36
Zweite Normalform (1)
Eine Tabelle ist in der zweiten Normalform (2NF), wenn sie in 1NF
ist und wenn jedes Nichtschlüsselmerkmal von jedem Schlüssel
voll funktional abhängig ist.
Voll funktional abhängig bezieht sich aus zusammengesetzte
Schlüssel (S1,S2) von denen alle Nichtschlüsselmerkmale
abhängig sind: (S1,S2) -> N
Sie dürfen dabei aber nicht funktional abhängig von einem
Teilschlüssel sein, z.B. S1->N
Im Beispiel sind Name und Vorname Nichtschlüsselmerkmale, der
Schlüssel setzt sich aus Matrnr und Studiengang zusammen.
(Matrnr, Studiengang) -> Name
aber auch Matrnr -> Name … damit keine 2NF
Peter Sobe
37
Zweite Normalform (2)
Herstellung der zweiten Normalform (2NF): Tabellenteilung
Alle Merkmale, die von einem Teilschlüssel abhängig sind werden
in eine eigene Tabelle ausgegliedert.
Matrnr
Name
Vorname
Matrnr
Studiengang
11
Schmidt
Robert
11
Mathematik
47
Schulze
Klaus
11
Physik
78
Peters
Karoline
47
Sport
47
Erziehungswissenschaften
78
Informatik
Peter Sobe
38
Dritte Normalform (1)
Eine Tabelle ist in der dritten Normalform (3NF), wenn sie in 2NF ist
und kein Nichtschlüsselmerkmal von irgendeinem Schlüssel
transitiv abhängig ist
Ein Beispiel für nicht erfüllte 3NF:
Matrnr
WohnPLZ
Wohnort
11
01217
Dresden
47
01219
Dresden
78
14197
Berlin
89
14197
Berlin
95
01217
Dresden
Matr
nr
Wohn
PLZ
Wohn
ort
Wohnort tritt
redundant auf.
Peter Sobe
39
Dritte Normalform (2)
Überführung in dritte Normalform (3NF), indem transitiv
abhängiges Merkmal in eine neue Tabelle ausgegliedert wird. Das
Merkmal von dem die letzte Stufe der Abhängigkeit ausgegangen
ist, wird als Fremdschlüssel in die neue Tabelle aufgenommen.
Matrnr
WohnPLZ
PLZ
Ort
11
01217
01217
Dresden
47
01219
14197
Berlin
78
14197
01219
Dresden
89
14197
95
01217
Peter Sobe
40
Relationenalgebra und SQL
 Begriff der Algebra
 klassische Mengenoperationen
(Vereinigung, Durchschnitt, Differenz)
 Operationen auf Relationen
 Projektion
 Selektion
 Kreuzprodukt
 Innerer Verbund / Gleichverbund
Peter Sobe
41
Zum Begriff der Algebra
In der Mathematik ist eine Algebra ein Paar von Trägermenge T
und einer Menge von Operationen Op, also (T,Op).
Die Operationen sind auf T erklärt. Jede Operation muss als
Ergebnis wieder ein Element von T liefern.
Relationenalgebra:
In der Relationenalgebra ist die Trägermenge die Menge der
Relationen MR. Die Menge der Operationen enthält die Elemente:
- Vereinigung
- Durchschnitt
- Differenz
- Projektion
- Selektion
- Kreuzprodukt
- Inner Join (mit seinen Varianten)
- Outer Join (mit seinen Varianten)
Peter Sobe
42
Klassische Mengenoperationen (1)
Vereinigung:
Es seien R und S zwei Relationen, die das gleiche Relationenformat E
besitzen müssen. Dann heißt
R U S = { r | r є R ODER r є S }
die Vereinigung von R und S.
Die Vereinigung ist unersetzbar. In SQL ist dieser Operator durch UNION
repräsentiert und wird von nahezu allen DBMS realisiert.
Durchschnitt:
Es seien R und S zwei Relationen, die das gleiche Relationenformat E
besitzen müssen. Dann heißt
R ∩ S = { r | r є R UND r є S }
der Durchschnitt von R und S.
Der Durchschnitt ist ersetzbar durch die Selektion mit EXISTS-Prädikat.
In SQL ist dieser Operator durch INTERSECT repräsentiert, wird aber
von wenigen DBMS realisiert.
Peter Sobe
43
Klassische Mengenoperationen (2)
Differenz:
Es seien R und S zwei Relationen, die das gleiche
Relationenformat E besitzen müssen. Dann heißt
R - S = { r | r є R UND r S }
die Differenz von R und S.
Die Differenz ist ersetzbar durch die Selektion mit NOT
EXISTS-Prädikat. In SQL ist dieser Operator durch EXCEPT
repräsentiert, wird aber von wenigen DBMS realisiert.
Peter Sobe
44
Operationen auf Relationen - Projektion
Die Projektion ist eine der am meisten benutzten relationalen
Operationen. Es wird dabei auf eine Teilmenge von Eigenschaften des
Relationenformats einer Relation R projiziert.
Projektion:
Es sei R eine Relation mit dem Relationenformat E. Dann heißt
Π Ea,Eb,Ec,... ( R ) = { (r.Ea, r.Eb, r.Ec,...) | r є R UND {Ea,Eb,Ec,...}  E }
die Projektion von R auf die Eigenschaften {Ea,Eb,Ec,...} .
Die Projektion wird in SQL in der SELECT-Klausel kodiert. Die
projizierten Eigenschaften werden hinter SELECT als Liste angegeben.
Wird keine Projektion durchgeführt, d.h. es sind alle Eigenschaften des
Relationenformats ausgewählt, wird dies in SQL durch eine Stern (*)
anstelle der Liste angegeben.
Peter Sobe
45
Operationen auf Relationen – Selektion (1)
Die Selektion ist eine der am meisten benutzten relationalen
Operationen. Es wird dabei ein Prädikat P über Eigenschaften des
Relationenformats einer Relation R gebildet. Nur Tupel r є R , für die das
Prädikat erfüllt ist, werden in die Ergebnisrelation Σ( R ) aufgenommen.
Selektion:
Es sei R eine Relation mit dem Relationenformat E. Dann heißt
Σ ( R ) = { r | r є R UND P(r)=wahr }
die Selektion von r bezüglich des Prädikates P.
Zur Kodierung des Prädikats gibt es mehrere Möglichkeiten. Es kann
durch einfache Vergleichsausdrücke realisiert werden. Teilausdrücke
können durch die Junktoren AND, OR, NOT verknüpft werden. In diesen
Ausdrücken sind auch Standardfunktionen erlaubt. Weiterhin können
auch bestimmte Standardprädikate, wie IN, IS, LIKE auftreten. Bei
Benutzung von Subselects treten standardmäßig Prädikate ALL, ANY,
EXISTS auf.
Peter Sobe
46
Operationen auf Relationen – Selektion (2)
Das Prädikat P wird in SQL in der WHERE-Klausel kodiert.
Beispielhaft sollen hier einige Möglichkeiten für die Nutzung von
Prädikaten angegeben werden.
Vergleichsausdrücke:
Gehalt>=2000 AND Geschlecht= ‘m‘
YEAR(Geburtstag)<1980
Standardprädikate:
Name LIKE ‘%nn%‘
Ort IN (‘Bautzen‘, ‘Dresden‘)
Telefon IS NULL
Peter Sobe
47
Operationen auf Relationen – Kreuzprodukt
In der Datenbanktechnologie wird das Kreuzprodukt selbst nur selten
benutzt. Es bildet aber das Gerüst für die sehr wichtigen und häufig
angewendeten Join-Operationen.
Kreuzprodukt:
Es seien R eine Relation mit dem Relationenformat ER und S eine
Relation mit dem Relationenformat ES. Dann heißt
R * S = { (er1,er2,...,ern,es1,es2,...,esm) | (er1,er2,...,ern) є R UND
(es1,es2,...,esm) є R UND E = ER U ES}
der Cross Join von R und S. E ist das Relationenformat von R * S
Das Kreuzprodukt (Cross Join) liefert als Resultat alle
zusammengesetzten Tupel, die sich aus allen Kombinationen der
Tupel der beiden Relationen ergeben. In SQL werden alle (expliziten)
Join-Operatoren in der FROM-Klausel kodiert. R * S wird durch R
CROSS JOIN S repräsentiert. Alle DBMS realisieren diese
Operation.
Peter Sobe
48
Inner JoinOperationen
- Equi-Join auf Relationen – JOIN
Der Equi-Join ist die am meisten benutzte Join-Operation.
Das =-Zeichen ist die Vergleichsoperation in der Join-Bedingung.
Equi-Join (Vereinigung über Gleichheit ausgew. Eigenschaften):
Es seien R eine Relation mit dem Relationenformat ER und S eine Relation
mit dem Relationenformat ES. Es existiert eine Eigenschaft ERk von R und
eine Eigenschaft ESj von S deren Wertebereiche gleich sind, Wk = Wj .
Dann heißt
R
S = { q | q є R * S Λ
B
q.ERk = q.ESj Λ E = ER U ES}
der Join von R u. S.
E ist das Relationenformat von R B S und
B ist die Join-Bedingung q.ERk = q.ESj .
Der Equi-Join liefert als Resultat nur diejenigen zusammengesetzten Tupel
q aus R * S, die gleiche Werte in den bezogenen Eigenschaften ERk und
ESj haben, d.h. die die Join-Bedingung B erfüllen.
Peter Sobe
49
Inter- vs. Intrarelationales JOIN (1)
Interrelationale Join-Operationen
Der interrelationale Verbund verknüpft entsprechend einer
Verbundbedingung Tupel (Entitäten) von zwei verschiedenen Relationen.
Diese Operationen gehören zu den Standard-Anwendungen in der
Datenbanktechnologie. In der Regel werden solche Operationen
ausgeführt, wenn im Diskursbereich eine Beziehung zwischen zwei oder
mehreren Entitätsmengen definiert ist, wie z.B. Menge der Personen und
Menge der Abteilungen mit der Beziehung „gehört zu“.
Im Standardfall werden bei obligatorischen Beziehungen durch Inner Joins
die aktuellen Zuordnungen der Tupel ermittelt und bei konditionalen
Beziehungen kann man mit einer Outer Join Variante, diejenigen Tupel
selektieren, die nicht in Beziehung stehen.
Es wird noch eine weitere Unterscheidung bei Verbundoperationen
vorgenommen:
- implizite Joins und
- explizite Joins
Peter Sobe
50
Inter- vs. Intrarelationales JOIN (2)
Intrarelationale Join-Operationen (Auto-Join oder Self-Joins)
Der intrarelationale Verbund verknüpft entsprechend einer Verbundbedingung Tupel (Entitäten) ein und derselben Relation. Die Anwendung
kann sinnvoll sein, wenn im Diskursbereich eine Beziehung in der
gleichen Entitätsmenge definiert ist, wie z.B. Menge der (Buch-) Autoren
mit der Beziehung „ist Mitautor“. Aber auch ohne eine solche Beziehung
gibt es sinnvolle Anwendungen. Betrachten wir unsere Beispiel-DB mit
der Relation PERSON.
Anfrage: Welche Mitarbeiter wohnen im gleichen Ort (PLZ) ?
SELECT E.MNR,Z.MNR, E.PLZ FROM Person AS E,Person AS Z
WHERE E.PLZ=Z.PLZ
Da hier gleiche Namen verwendet werden, ist es erforderlich, durch eine
Bereichsvariable die Kopien auseinander zu halten. Alle (expliziten) JoinOperatoren in der FROM-Klausel kodiert. R * S wird durch
R CROSS JOIN S repräsentiert. Manche DBMS kodieren sie auch
durch R, S .
Peter Sobe
51
Inter- vs. Intrarelationales JOIN (3)
Das Ergebnis ist (Ausschnitt):
MNR
MNR
PLZ
1235 1235 80995
2467 2467 10117
2477 2477 01069
4992 2477 01069
2589 2589 80997
2612 2612 80999
4952 2612 80999
......... .......... ...........
Wir sehen, dass leider alle Kombinationen von Mitarbeitern kommen,
sogar die Verknüpfung mit sich selbst. Um das auszuschließen,
ergänzen wir die Abfrage:
SELECT E.MNR,Z.MNR, E.PLZ FROM Person AS E,Person AS Z
WHERE E.PLZ=Z.PLZ AND E.MNR<Z.MNR
Peter Sobe
52
Inter- vs. Intrarelationales JOIN (4)
Jetzt erhalten wir das gewünschte Ergebnis mit paarweise
verschiedenen Personen, die im gleichen Ort wohnen:
MNR
2477
2612
2612
4952
4962
.........
MNR
4992
4952
5367
5367
4989
..........
PLZ
01069
80999
80999
80999
80686
...........
Auch mit geschachtelten SELECT-Anweisungen (Subselects) lassen sich
ähnliche Fragestellungen bearbeiten.
Peter Sobe
53
SQL
SQL: Structured Query Language
 Datenbankspezifische Manipulations- und Abfragesprache
 eine relational vollständige Sprache
 Eine Deklarative Sprache – Man beschreibt das Ziel der
Operation, Unterschied gegenüber imperativer Programmierung,
wie z.B. mit C/C++
 In den siebziger Jahren entwickelt, inzwischen ISO-Norm
 Weit verbreitet: MS-ACCESS, MS-SQL-Server, mySQL u.v.a.m.
 In der Vorlesung bislang schon zur Erklärung der Operationen
der Relationenalgebra benutzt
Peter Sobe
54
Tabellen und Abfragen mittels SQL (4)
Abfragen innerhalb einer Datenbanksoftware:
z.B. Microsoft Office Access –
Abfrageeditor, mit SQL-Ansicht
Peter Sobe
55
Tabellen und Abfragen mittels SQL (5)
Abfragen innerhalb einer Datenbanksoftware:
PHPMyAdmin für mySQL-Datenbanken
(vorrangig im LINUX-Umfeld)
Peter Sobe
56
Tabellen und Abfragen mittels SQL (6)
SQL – Syntax und Funktionalität
Grundform einer Abfrage:
SELECT "Spalten_Name" FROM "Tabellen_Name" WHERE "Bedingung“
Beispiel mit Tabelle, die auch für weiter SQL-Abfragen benutzt wird:
ID
Stadt
Bundesland
1 Dresden
Einwohner
Sachsen
Vorwahl
523000
KFZ-Kennzeichen
351 DD
Höhe
113
2 Leipzig
Sachsen
522000
341 L
113
3 Chemnitz
Sachsen
243000
371 C
296
4 Zwickau
Sachsen
5 Erfurt
Thüringen
93750
375 Z
267
204000
361 EF
195
6 Jena
Thüringen
104000
7 Gera
Thüringen
100000
3641 J
155
365 G
205
8 Berlin
Berlin
3459000
30 B
34
9 Cottbus
Brandenburg
102000
355 CB
70
10 Postdam
Brandenburg
155000
331 P
35
11 FrankfurtOder
Brandeburg
61000
335 FF
40
12 Rostock
Mecklenburg-Vorpommern
201000
381 HRO
13
13 Schwerin
Mecklenburg-Vorpommern
95000
385 SN
38
14 Neubrandenb
Mecklenburg-Vorpommern
65000
395 NB
20
Peter Sobe
57
Tabellen und Abfragen mittels SQL (7)
Beispiel einer Abfrage:
SELECT Stadt, Bundesland FROM Staedte WHERE Einwohner>=100000
DISTINCT - Option:
Allgemeine Form:
SELECT DISTINCT "Spalten_Name“ FROM "Tabellen_Name"
gibt für die als DISTINCT markierte Spalte nur ein Tupel je Wert zurück
Beispiel:
SELECT DISTINCT Bundesland FROM Staedte;
Ergebnis:
ohne DISTINCT-Option
mit DISTINCT-Option
Bundesland
Berlin
Brandenburg
Mecklenburg-Vorpommern
Sachsen
Thüringen
Peter Sobe
Bundesland
Sachsen
Sachsen
Sachsen
Sachsen
Thüringen
Thüringen
Thüringen
….
58
Tabellen und Abfragen mittels SQL (8)
ORDER BY :
Allgemeine Form:
SELECT "Spalten_Name“ FROM "Tabellen_Name“ [WHERE "Bedingung"]
ORDER BY "Spalten_Name" [ASC, DESC]
Ordnet die Ausgabe nach Werten in der angebenen Tabellenspalte, auf
Anwendungsseite kann das Sortierverfahren eingespart werden.
Beispiel:
SELECT Stadt, Höhe FROM Staedte
ORDER BY Höhe;
Ergebnis rechts …
Peter Sobe
Stadt
Rostock
Neubrandenb
Berlin
Postdam
Schwerin
FrankfurtOder
Cottbus
Leipzig
Dresden
Jena
Erfurt
Gera
Zwickau
Chemnitz
Höhe
13
20
34
35
38
40
70
113
113
155
195
205
267
296
59
Tabellen und Abfragen mittels SQL (9)
COUNT - Funktion:
Allgemeine Form:
SELECT COUNT("Spalten_Name") FROM "Tabellen_Name“
 gibt die Anzahl verschiedener Werte in der angegebenen Spalte zurück.
 wird oft zum Zählen der Datensätze benutzt, die einem bestimmten
Kriterium entsprechen.
Beispiel:
SELECT Count(Bundesland) FROM Staedte
Ergebnis: 14 … weil 14 Spalten
SELECT COUNT (DISTINCT Bundesland) FROM Staedte
Ergebnis: 5 … da 5 nur verschiedene Spalten
(funktioniert leider nicht mit ACCESS, aber mit SQL-SERVER)
Peter Sobe
60
Tabellen und Abfragen mittels SQL (10)
Group By
Allgemeines Beispiel:
SELECT "Spalten_Name1", SUM("Spalten_Name2")
FROM "Tabellen_Name" GROUP BY "Spalten_Name1„
 GROUP BY gruppiert die Ausgabe entsprechend gleicher
Ausgaben in einer Spalte. Auf andere Spalten kann dann eine
arithmetische Operation ausgeführt werden
 Die Gruppierung erfolgt immer nach der Spalte, die nicht in die
arithmetische Operation einbegriffen ist.
Beispiel:
SELECT Bundesland, COUNT(Stadt) FROM Staedte
GROUP BY Bundesland;
Peter Sobe
61
Tabellen und Abfragen mittels SQL (11)
Group By - Beispiel:
SELECT Bundesland, COUNT(Stadt) FROM Staedte
GROUP BY Bundesland
Ergebnis:
Bundesland
Expr1001
Berlin
1
Brandenburg
3
Mecklenburg-Vorpommern
3
Sachsen
4
Thüringen
3
Ein weiteres Beispiel:
SELECT Bundesland, SUM(Einwohner) FROM Staedte GROUP
BY Bundesland
Bundesland
Expr1001
Berlin
Brandenburg
Mecklenburg-Vorpommern
Sachsen
Thüringen
Peter Sobe
3459000
318000
361000
1381750
408000
62
Tabellen und Abfragen mittels SQL (12)
Having
Allgemeine Form:
SELECT "Spalten_Name1", SUM("Spalten_Name2")
FROM "Tabellen_Name„ GROUP BY "Spalten_Name1"
HAVING (arithmetische Funktionsbedingung)
mit der HAVING Klausel kann man Tupel über Bedingungen
auswählen, welche die aggregierte Information betreffen
Beispiel:
SELECT Bundesland, SUM(Einwohner) FROM Staedte GROUP BY
Bundesland HAVING (SUM(Einwohner) >400000)
Bundesland
Peter Sobe
Expr1001
Berlin
3459000
Sachsen
1381750
Thüringen
408000
63
Tabellen und Abfragen mittels SQL (13)
Tabellen JOINS
Allgemeines Beispiel:
SELECT "Spalten_Name1", “Spalten_Name2“ FROM "Tabellen_Name1“,
“Tabellen_Name2“ WHERE “JoinBedingung“
Die relationenalgebraischen Konzepte der JOIN-Operation wurden bereits
unter Relationenalgebra behandelt.
In Access gibt man das Komma zwischen den Tabellen anstelle des JOIN
Schlüsselworts an.
Alias-Namen: Wird aus auf Spalten mit gleicher Bezeichnung aus
verschiedenen Tabellen Bezug genommen, so ist für die Tabellen ein AliasName in der Anfrage anzugeben.
Beispiel mit Alias:
SELECT s1.Stadt, s2.Stadt FROM Staedte AS s1, Bahnstrecken, Staedte AS
s2 WHERE s1.Stadt=Von AND s2.Stadt=Nach
Peter Sobe
64
Tabellen und Abfragen mittels SQL (14)
Unterabfragen
Allgemeines Beispiel:
SELECT "Spalten_Name1", "Spalten_Name2"
FROM "Tabellen_Name1“ WHERE Spalten_Name2 IN (SELECT
“Spalten_Name3“ FROM "Tabellen_Name2“ WHERE Bedingung )
Beispiel:
SELECT Bundesland, SUM(Einwohner) FROM Staedte WHERE Stadt
in (SELECT Stadt FROM Staedte WHERE Höhe>100) GROUP BY
Bundesland
Ergebnis:
Bundesland
Sachsen
Thüringen
Expr1001
1381750
408000
Hier werden nur jene
Städte ausgewertet, die
höher als 100 Meter
liegen.
Peter Sobe
65
Views (1)
Ein „View“ ist eine virtuelle Relation, die durch eine SQL-Abfrage
erstellt wird. Ist der View definiert, so kann der View wir eine Tabelle
angesehen werden und in neue SQL-Abfragen eingeschlossen
werden.
Allgemeines Beispiel:
CREATE VIEW “View_name“ AS SELECT “Spalten_name1“,
“Spalten_name2“ FROM "Tabellen_Name“ WHERE Bedingung
Beispiel:
CREATE VIEW Laender AS SELECT DISTINCT Bundesland FROM
Staedte;
SELECT COUNT (*) FROM Laender;
Peter Sobe
66
Views (2)
Ein „View“ kann innerhalb der Access-Bedienoberfläche als Abfrage
abgespeichert werden.
Es ist möglich, neue Abfragen auf bestehenden, gespeicherten
Abfragen zu definieren.
Peter Sobe
67
Tabellen-Manipulation mittels SQL (1)
SQL – Erzeugen neuer Tabellen: Create Table
Allgemeine Form:
CREATE TABLE "Tabellen_Name"
("Spalte1" "Datentyp_für_Spalte1", "Spalte2" "Datentyp_für_Spalte2",
... )
Beispiel:
CREATE TABLE Bahnstrecke (Von CHAR, Nach CHAR, Distanz INTEGER)
Einfügen neuer Tupel mittels Insert Into:
Allgemeine Form:
INSERT INTO "Tabellen_Name" ("Spalte1", "Spalte2", ...)
WertS ("Wert1", "Wert2", ...)
Allgemeine Form:
INSERT INTO Bahnstrecke (Von, Nach, Distanz)
VALUES (‘Dresden‘, ‘Berlin‘, 185)
Peter Sobe
68
Tabellen-Manipulation mittels SQL (8)
SQL – Ändern einzelner Werte: Update
Allgemeine Form:
UPDATE "Tabellen_Name„ SET "Spalte1" = [Wert]
WHERE {Bedingung}
Beispiel:
UPDATE Staedte SET Einwohner=524000
WHERE Stadt=‘Dresden‘
Es ist immer eine Selektion eines (oder mehrerer) Tupel
vorzunehmen, die geändert werden sollen.
Peter Sobe
69
Tabellen-Manipulation mittels SQL (8)
SQL – Löschen einzelner Tupel einer Tabelle: Delete From
Allgemeine Form:
DELETE FROM "Tabellen_Name“ WHERE “Bedingung“
Beispiel:
DELETE FROM Bahnstrecke WHERE Von=‘‘Cottbus‘
AND Nach=‘Dresden‘
Löschen einer Tabelle oder eines Views: Drop bzw. Truncate
Allgemeine Form:
DROP TABLE "Tabellen_Name"
Wird von Access nicht unterstützt, DELETE stattdessen
TRUNCATE TABLE "Tabellen_Name“
Nur die Daten (Tupel) werden gelöscht. Das Tabellenformat bleibt bestehen.
Peter Sobe
70
Weitere SQL-Beispiele (1)
Ausgangsbasis ist die Datenbank firma.mdb.
Frage: Anzahl der Personen, die in ihren Räumen selbst
Raumverantwortliche sind?
SELECT Count(ID) FROM personen AS p, raeume AS r
WHERE p.Raumnr = r.Raumnr AND ID=Rverantw
Peter Sobe
71
Weitere SQL-Beispiele (2)
Frage: Alle Abteilungsleiter und die jeweilige Anzahl der
unterstellten Personen.
SELECT Abtleiter, COUNT(ID) FROM abteilungen AS a , personen AS
p WHERE a.Abtnr = p.Abtnr
AND a.Abtleiter <>p.ID GROUP BY Abtleiter
Peter Sobe
72
Weitere SQL-Beispiele (3)
Frage: Alle Abteilungsleiter, die mindestens eine andere Person in
ihrer Abteilung leiten.
SELECT Vorname, Famname FROM personen WHERE ID IN
(SELECT DISTINCT Abtleiter FROM abteilungen AS a , personen
AS p WHERE a.Abtnr = p.Abtnr AND a.Abtleiter <>p.ID)
Peter Sobe
73
Weitere SQL-Beispiele (4)
Frage:
Maximale Anzahl Personen, die in einem Raum arbeiten.
Erster Schritt … Anzahl von Personen gruppiert nach Raumnr
SELECT Count (ID) FROM personen GROUP BY Raumnr
Zweiter Schritt …erste Abfrage als Unterfrage
SELECT Max( Count (ID) ) FROM (SELECT Count (ID) FROM
personen GROUP BY Raumnr)
Peter Sobe
74
Weitere SQL-Beispiele (5)
Zweiter Schritt …erste Abfrage als Unterfrage
SELECT Max( Count (ID) ) FROM (SELECT Count (ID) FROM
personen GROUP BY Raumnr)
… mit MS-Access wird angezeigt:
Fehler: Aggregatfunktion im Ausdruck (Max(COUNT(ID)))
nicht möglich
Lösung über Aliasnamen:
SELECT Max(x) FROM (SELECT Count(ID) AS x FROM
personen GROUP BY Raumnr)
Peter Sobe
75
Zugriff aus einer C++ -Anwendung auf eine
Datenbank (1)
Aufbau einer OLEDB-Verbindung (siehe Vorführung Beispiel der
Datenbank auf Folie 22)
using namespace System;
int main(array<System::String ^> ^args)
{
String^ connectionString="Provider=Microsoft.ACE.OLEDB.12.0;
Data Source=c:\\Temp\\laden.accdb;Persist Security Info=False";
System::Data::OleDb::OleDbCommand ^command;
System::Data::OleDb::OleDbDataReader ^reader;
System::Data::OleDb::OleDbConnection^ connObj = gcnew
System::Data::OleDb::OleDbConnection(connectionString);
…
Peter Sobe
76
Zugriff aus einer C++ -Anwendung auf eine
Datenbank (2)
Ausführen eines SQL-Kommandos und anschließendes Auslesen der
Resultate mit einem s.g. „reader“-Objekt
…
Console::WriteLine(L"Connection to Database");
try {
connObj->Open();
command = connObj->CreateCommand();
command->CommandText = "SELECT * FROM kunden";
reader = command->ExecuteReader();
while (reader->Read())
{ Console::Write(reader->GetInt32(0)); Console::Write("\t");
Console::Write(reader->GetString(1)); Console::Write("\t");
Console::WriteLine(reader->GetString(2));
}
reader->Close();
} catch(System::Data::OleDb::OleDbException^ ex) { Console::WriteLine(ex->Message); }
connObj->Close();
return 0;
}
Peter Sobe
77
Zugriff aus einer C++ -Anwendung auf eine
Datenbank (3)
Prinzip:
 Das C++-Programm stellt eine Verbindung zur Datenbank her
 Ein Kommando wird als SQL- Anweisung zur Datenbank gesendet
 Die Ergebnisse werden durch das C++ Programm verarbeitet
 Das Schreiben von Daten in die Datenbank erfolgt auch über ein SQLKommando (SQL INSERT …)
 Sämtliche Such-, Auswahl- und Verknüpfungsoperationen werden durch
entsprechende SQL-Anweisungen der Datenbanksoftware übergeben.
 Das Anwendungsprogramm muss diese Operation nicht implementieren,
es wertet ausschließlich die Ergebnisse aus.
Peter Sobe
78