7 Datenbanksysteme - ias.uni-stuttgart.de

Softwaretechnik II
ST II
§ 7 Datenbanksysteme
Lernziele
– Wissen, was Datenbanksysteme sind
– Ziele beim Einsatz von Datenbanksystemen verstehen
– Verschiedene Arten von Datenbanksystemen kennen
– Wissen, wie eine Datenbank modelliert wird
– Wissen, wie eine Datenbank implementiert wird
– SQL-Sprache kennen
Literatur
–
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme, Oldenbourg, 2000
–
G. Matthiessen, M. Unterstein: Relationale Datenbanken und SQL,
Addison-Wesley, 2000
© 2015 IAS, Universität Stuttgart
297
Softwaretechnik II
§7
Datenbanksysteme
7.1
Einführung in Datenbanksysteme
7.2
Relationale Datenbanksysteme
7.3
Datenbanksprachen
7.4
Entwurf von Relationalen Datenbanksystemen
7.5
Objektorientierte Datenbanksysteme und neue Entwicklungen
© 2015 IAS, Universität Stuttgart
ST II
298
7.1 Einführung in Datenbanksysteme
ST II
Konzept eines Datenbanksystems
– Organisatorisch zentrale Betreuung der Daten
– Zugriff und Manipulation ausschließlich über Verwaltungssystem
– Trennung der Daten von den Nutzern
© 2015 IAS, Universität Stuttgart
299
7.1 Einführung in Datenbanksysteme
ST II
Schematische Darstellung eines Datenbanksystems
Schnittstelle
(interface)
Datenbank,
Anwendungsprogramm 1
Datenbankverwaltungssystem
Datenbasis
DBVS
(data base)
(data base management
system, DBMS)
Anwendungsprogramm N
Datenbanksystem (DBS)
(data base system)
© 2015 IAS, Universität Stuttgart
300
7.1 Einführung in Datenbanksysteme
ST II
3-Ebenen-Architektur nach ANSI/SPARC
SPARC = Standard Planning and Requirements Commitee
Teilbereiche der DB
für verschiedene
Benutzergruppen,
Zugriffsrechte
Externes
Schema 1
Externes
Schema 2
...
Externes
Schema n
externe
Ebene
Beschreibung der
kompletten Datenstruktur
inkl. Konsistenzbedingungen
im Datenmodell des DBMS
logisches
Schema
logische
Ebene
Implementierungsdetails, z.B.
Aufteilung auf verschiedene
Platten, Index, ...
internes
Schema
interne
Ebene
© 2015 IAS, Universität Stuttgart
301
7.1 Einführung in Datenbanksysteme
ST II
Ziele beim Einsatz von Datenbanksystemen (1)
– Datenunabhängigkeit
Unabhängigkeit zwischen den Anwendungsprogrammen, der
Datenspeicherung und der Datenorganisation
Unterscheidung zwischen logischer und physikalischer
Datenunabhängigkeit
Späte Bindung zwischen Daten und Anwendungsprogrammen
– Benutzerorientierte Sicht der Daten
– Datenintegrität
Korrektheit der Daten und deren korrekte Verwendung
Datenkonsistenz: Übereinstimmung und Vollständigkeit der
gespeicherten Daten (semantische Integrität)
Datensicherung: Schutz gegen Zerstörung und Verfälschung durch
fehlerhafte Software, Hardware und Benutzung
Datenschutz bei Abfrage, Eingabe und Änderung
© 2015 IAS, Universität Stuttgart
302
7.1 Einführung in Datenbanksysteme
ST II
Ziele beim Einsatz von Datenbanksystemen (2)
– Vermeidung von Redundanz
Speicherplatzreduzierung
Leichtere Aktualisierung der Daten
Datensicherheit benötigt gewisse Redundanz
Schneller Zugriff auf Kopien
– Unterstützung der Datenmanipulation
 einfügen
(insert)
 ändern
(update)
 löschen
(delete)
 auffinden
(retrieve)
© 2015 IAS, Universität Stuttgart
303
7.1 Einführung in Datenbanksysteme
ST II
Ziele beim Einsatz von Datenbanksystemen (3)
– Koordinierung des Mehrbenutzerbetriebs (Synchronisation)
– Datenneutralität
Unterschiedliche Anwendungen
– Flexibilität
– Vielfältige Auswertungsmöglichkeiten
– Effizienz
Zugriff auf Daten
Verbesserung und Optimierung leicht
© 2015 IAS, Universität Stuttgart
304
7.1 Einführung in Datenbanksysteme
ST II
Arten von Datenbanksystemen (1)
– Datenbanksystem
Organisatorisch zentralisierte Datenbasis, in der durch
ein Datenbankverwaltungssystem (DBVS) die Datenunabhängigkeit, Datenintegrität, Datenmanipulation und
die Synchronisierung der Zugriffe mehrerer Benutzer auf
die Datenbasis unterstützt werden
– Informationssystem
Datenbanksystem, das um eine Methodensammlung zur
Auswertung und Darstellung der abgefragten Daten
erweitert ist
Methodensammlung mit Funktionen wie Statistik,
Optimierung, Planungs- und Arbeitstechnik, Grafik,
Berichtgestaltung
© 2015 IAS, Universität Stuttgart
305
7.1 Einführung in Datenbanksysteme
ST II
Arten von Datenbanksystemen (2)
– Transaktionssystem
Problemorientierte Benutzungsschnittstelle
Anwendungsbezogene Funktionen in Form von Menüs
Banken- oder Buchungsprogramme
– Dokumentationssystem
Auffinden von Dokumenten aus Katalogen
Documentation Retrieval Systems
© 2015 IAS, Universität Stuttgart
306
7.1 Einführung in Datenbanksysteme
ST II
Evolution von Datenbanksystemen
Dateien
Dateisysteme
(60‘er Jahre)
Netzwerk- und
Hierarchische Datenbanken
(70‘er Jahre)
Relationale
Datenbanksysteme
(80‘er Jahre)
Objektorientierte
Datenbanken
(90‘er Jahre)
Semistrukturierte
(XML) Datenbanken
(seit 2000)
© 2015 IAS, Universität Stuttgart
Objektrelationale
Datenbanksysteme
(seit 2000)
307
Frage zu Kapitel 7.1
ST II
Frage zu Kapitel 7.1
Welche Ziele gehören zur Datenintegrität?
Antwort
f  Schneller Zugriff auf Kopien

 Korrektheit der Daten
 Datenkonsistenz

f  Speicherplatzreduzierung


Datensicherung
 Datenschutz bei Abfrage

© 2015 IAS, Universität Stuttgart
308
Softwaretechnik II
§7
Datenbanksysteme
7.1
Einführung in Datenbanksysteme
7.2
Relationale Datenbanksysteme
7.3
Datenbanksprachen
7.4
Entwurf von Relationalen Datenbanksystemen
7.5
Objektorientierte Datenbanksysteme und neue Entwicklungen
© 2015 IAS, Universität Stuttgart
ST II
309
7.2 Relationale Datenbanksysteme
ST II
Relationales Datenmodell
1970
erste Veröffentlichung von E. F. Codd (IBM)
1979
erstes relationales Datenbanksystem mit SQL (Oracle)
1981
Definition Relationales Datenbanksystem (Codd):
–
Alle Daten werden in Relationen dargestellt
–
Jeder Benutzerzugriff auf die Daten erfolgt über die Werte der
Daten
–
Es werden relationale Operatoren unterstützt
Keine Kenntnis von Zeigern und Verkettungen notwendig
© 2015 IAS, Universität Stuttgart
310
7.2 Relationale Datenbanksysteme
ST II
Relation
Definition
Teilmenge des Kartesischen Produkts von Wertebereichen
Beispiel
Student
= Matrikelnr X Fachbereich = Relation
Matrikelnr
= (5001, 5003, 5007)
= Wertebereiche = Menge
Fachbereich = (ET, MA)
möglicher Werte eines Attributs
vereinfachte, anschauliche
Darstellung durch Tabellen
Student
Matrikelnr
Fachbereich
5001
ET
5003
MA
5007
ET
Tupel (Zeile, Datensatz)
Relation (Tabelle)
Attribute (Spalte)
© 2015 IAS, Universität Stuttgart
311
7.2 Relationale Datenbanksysteme
ST II
Schlüssel
Identifizierende Attributskombination (superkey)
– Kombination von Attributen, deren Werte zusammengenommen
ein Tupel eindeutig identifizieren
Schlüssel (key)
– Eine minimale identifizierende Attributs-Kombination
Primärschlüssel (primary key)
– Zur eindeutigen Identifikation von Tupeln festgelegter Schlüssel
Fremdschlüssel (foreign key)
– Die Werte dieser Attribute müssen im Primärschlüssel einer anderen
Relation (Vaterrelation) vorhanden sein
Relation mit Fremdschlüssel = abhängige Relation
© 2015 IAS, Universität Stuttgart
312
7.2 Relationale Datenbanksysteme
ST II
Relationenalgebra (1)
Ergebnis einer Operation ist wieder eine Relation
Die wichtigsten Operationen:
Auswahl (Selektion)
A1
A2
A1
A2
A3
A4
Ergebnis = alle Tupel, die eine
bestimmte Bedingung erfüllen
Projektion
A3
A4
Ergebnis = Teilmenge der Attribute
© 2015 IAS, Universität Stuttgart
313
7.2 Relationale Datenbanksysteme
ST II
Relationenalgebra (2)
Verbund (Join)
Ergebnis = Kreuzprodukt der beteiligten Relationen, wobei gemeinsame
Attribute gleiche Werte enthalten
Natürlicher Verbund (Natural Join):
Gemeinsame Attribute sind in der Ergebnisrelation nur einmal vorhanden
A
B
B
C
A
B
C
a1
b1
b1
c1
a1
b1
c1
a2
b1
b2
c2
a2
b1
c1
a3
b3
b3
c3
a3
b3
c3
=
Kombination von Operationen möglich
Film: IAS-Datenbank
© 2015 IAS, Universität Stuttgart
314
Frage zu Kapitel 7.2
ST II
Frage zu Kapitel 7.2
Welche Kriterien sprechen für den Einsatz eines relationalen
Datenbanksystems?
Antwort

 Es sind relativ einfache, formatierte Datenbestände zu verwalten
f  Es müssen komplexe graphenartige Strukturen verwaltet werden

 Die Antwortzeiten auf Anfragen sind von der Anwendung her nicht kritisch
f  Die Anwendungsprogramme bestehen aus Objekten
© 2015 IAS, Universität Stuttgart
315
Softwaretechnik II
§7
Datenbanksysteme
7.1
Einführung in Datenbanksysteme
7.2
Relationale Datenbanksysteme
7.3
Datenbanksprachen
7.4
Entwurf von Relationalen Datenbanksystemen
7.5
Objektorientierte Datenbanksysteme und neue Entwicklungen
© 2015 IAS, Universität Stuttgart
ST II
316
7.3 Datenbanksprachen
ST II
Datenbanksprachen
– Datendefinitionssprachen (Data Definition Language, DDL)
Beschreibung des logischen Schemas, d.h. des gesamten
Datenbestandes
Beschreibung des externen Schemas, d.h. der Daten aus der Sicht
einer Anwendung
– Datenmanipulationssprachen (Data Manipulating Language, DML)
Formulierung von Operationen auf Daten
Einfügen, Ändern, Löschen
– Daten-Kontrollsprachen (Data Control Language, DCL)
Formulierung von Zugriffsrechten
SQL enthält DDL, DML, DCL
© 2015 IAS, Universität Stuttgart
317
7.3 Datenbanksprachen
ST II
Geschichte
1974
SEQUEL (Structured English Query Language, IBM)
1987
ISO-Standard SQL1 (oder SQL-86, Structured Query Language)
1989
Ergänzungen: ISO-Standard SQL-89
1992
Ergänzungen und Modifikationen: ISO-Standard SQL2 (oder SQL-92)
1999
Aufnahme objektorientierter Konzepte: SQL:1999 (oder SQL3)
2003
SQL:2003 ISO/IEC 9075:2003
2006
SQL:2006 ISO/IEC 9075-14:2006 (Verbindung zu XML)
2008
SQL:2008 ISO/IEC 9075:2008
2011
SQL:2011 ISO/IEC 9075:2011 (aktuelle Revision)
Merkmale
– SQL2 wird von den aktuellen relationalen DBMS weitgehend unterstützt
– SQL ist nicht prozedural
– Auffinden von Daten erfolgt über die Beschreibung von Attributwerten mit
Hilfe von logischen Bedingungen
– Ergebnis = Tabelle
© 2015 IAS, Universität Stuttgart
318
7.3 Datenbanksprachen
ST II
DDL-Beispiel in SQL2
Erstellung einer Tabelle
CREATE TABLE tabelle
(spaltendefinitionsliste,
[tabellenintegritätsregelliste])
Beispiel
CREATE TABLE Student
( Matrikelnr
INTEGER
NOT NULL,
Fachbereich CHAR(4)
NOT NULL,
PRIMARY KEY (Matrikelnr));
Löschen einer Tabelle
DROP TABLE tabelle
Ändern einer Tabelle
ALTER TABLE ...
© 2015 IAS, Universität Stuttgart
319
7.3 Datenbanksprachen
ST II
DCL-Beispiel in SQL2
Zugriffsrechte auf Tabellen vergeben
GRANT recht ON tabellen TO benutzer
Beispiel
GRANT SELECT ON Student TO goehner;
Zugriffsrechte entziehen
REVOKE recht ON tabelle FROM benutzer
DML-Beispiele in SQL2 (1)
Zeilen in einer Tabelle einfügen
INSERT INTO tabelle [(spaltenliste)]
VALUES (werteliste)
Beispiel
INSERT INTO Student (Matrikelnr, Fachbereich)
VALUES (4711, ‘ETI‘);
© 2015 IAS, Universität Stuttgart
320
7.3 Datenbanksprachen
ST II
DML-Beispiele in SQL2 (2)
Zeilen löschen
DELETE FROM tabelle
[ WHERE prädikat ]
Beispiel
DELETE FROM Student
WHERE Matrikelnr = 4711;
Zeilen ändern
UPDATE tabelle
SET spalte = wert {spalte=wert}
[ WHERE prädikat ]
Beispiel
UPDATE Student
SET Fachbereich = ‘MA‘
WHERE Matrikelnr = 4711;
© 2015 IAS, Universität Stuttgart
321
7.3 Datenbanksprachen
ST II
DML-Beispiele in SQL2 (3)
Zeilen suchen (vereinfacht)
SELECT attributliste
FROM tabellenliste
WHERE selektionsbedingung
GROUP BY attributliste
HAVING selektionsbedingung
ORDER BY attributliste
Beispiel
SELECT Matrikelnr, Fachbereich
FROM Student
WHERE Matrikelnr > 4000
ORDER BY Fachbereich;
© 2015 IAS, Universität Stuttgart
322
Frage zu Kapitel 7.3
ST II
Frage zu Kapitel 7.3
Welche Möglichkeiten bietet SQL?
Antwort

 Definition der Daten

 Formulierung von Operationen auf Daten
f  Modellierung der Daten

 Formulierung von Zugriffsrechten
f  Graphische Darstellung der Daten
© 2015 IAS, Universität Stuttgart
323
Softwaretechnik II
§7
Datenbanksysteme
7.1
Einführung in Datenbanksysteme
7.2
Relationale Datenbanksysteme
7.3
Datenbanksprachen
7.4
Entwurf von Relationalen Datenbanksystemen
7.5
Objektorientierte Datenbanksysteme und neue Entwicklungen
© 2015 IAS, Universität Stuttgart
ST II
324
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
Vorgehen bei der Entwicklung einer Datenbank-Anwendung
Problem
ProblemAnalyse
Anforderungsdefinition
konzeptioneller
Entwurf

Konzeptionelles Schema
logischer
Entwurf

logisches Schema
physischer
Entwurf

Anforderungsdefinition
Anforderungsdefinition
Datenbankentwurf
DB-Beschreibung
Datenbankrealisierung
DBBeschr.

DB
Anwend.entwurf
Spezifikation
Anwend.implem.

Datenbank

Test und
Korrektur
Programm
physisches Schema
Endprodukt
© 2015 IAS, Universität Stuttgart
325
7.4 Entwurf von Relationalen Datenbanksystemen

ST II
Problemanalyse
z.B.
Die Datenbank soll alle Studierende der Universität Stuttgart enthalten. Für
jeden Studierenden sollen Name, Straße, Ort, Matrikelnummer, Fachbereich
und alle seine Prüfungsnoten gespeichert werden. Der Fachbereich besitzt
eine Nummer, eine Bezeichnung und einen Dekan. Die Prüfungsdaten
bestehen aus einer Nummer, einer Bezeichnung und einem Prüfer.

Ziel:
Konzeptioneller Entwurf
Erstellung eines konzeptionellen, zielsystem-unabhängigen
Datenbankschemas
Beispiele für Modellierungen für konzeptionelles Schema:
– Objektorientiertes Modell (OO-Modell)
– Entitiy-Relationship-Modell (ER-Modell)
wird vor allem beim Entwurf von RDBS eingesetzt
© 2015 IAS, Universität Stuttgart
326
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
Entity-Relationship-Modell (P. Chen, 1976) (1)
Entität (entity)
Individuelles, unterscheidbares und identifizierbares Exemplar von
Dingen, Personen oder Begriffen aus der realen oder der Vorstellungswelt
Zusammenfassung von gleichen Entitäten: Entitätstyp
Beziehung (relationship)
Wechselseitige Verbindung von zwei oder mehr Entitäten
Zusammenfassung von gleichartigen Beziehungen: Beziehungstyp
(Assoziation)
mögliche Kardinalitäten:
© 2015 IAS, Universität Stuttgart
1:1
1:C
1:N
1:NC
M:N
M:NC
und Kombinationen
327
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
Entity-Relationship-Modell (2)
Attribute
Eigenschaften von Entitäten und Beziehungen
Schlüssel
Attribute zur eindeutigen Identifizierung einer Entität
© 2015 IAS, Universität Stuttgart
328
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
Grafische Notation
Entitätstyp
Attribut
Schlüssel
Person
Name
Person
ID_Person
Person
Beziehungstyp
arbeitet in
Person
n
arbeitet in
Name
Kardinalität
der
Assoziation
_1___
1 Firma
© 2015 IAS, Universität Stuttgart
329
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
ER-Diagramm Beispiel aus Anforderung
Prüfungnr
Prüfung
Bezeichnung
Prüfer
nc
absolviert
Note
nc
Studierender
nc
gehört zu
n
Fachbereich
Matrikelnr
Fachbereichnr
Name
Bezeichnung
Straße
Dekan
Ort
© 2015 IAS, Universität Stuttgart
330
7.4 Entwurf von Relationalen Datenbanksystemen

Ziel:
ST II
Logischer Entwurf
Transformation des konzeptionellen Datenbankschemas in ein
logisches Datenbankschema in Abhängigkeit vom DBMS
z.B. bei RDBMS: relationales Modell/Datenbankschema
Transformationsregeln (vereinfacht)
– Entitätstyp
zu Tabelle
– 2 Entitätstypen mit 1:1/1:C/C:C-Beziehung
zu 1 Tabelle
– 2 Entitätstypen mit 1:N/1:NC-Beziehung
zu 2 Tabellen, Verbindung
über Fremdschlüssel
– 2 Entitätstypen mit N:N/N:NC/NC:NC-Beziehung
zu 3 Tabellen, Verbindung
über Fremdschlüssel
Transformation i.d.R. mit Werkzeugunterstützung
© 2015 IAS, Universität Stuttgart
331
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
Beispiel eines logisches Datenbankschemas
Prüfung
Prüfungnr
integer
Bezeichnung
long varchar
Prüfer
long varchar
Prüfungnr = Prüfungnr
Fachbereich
Fachbereichnr
integer
Bezeichnung
long varchar
Dekan
long varchar
Prüfungsleistung
Prüfungnr
integer
Matrikelnr
integer
Note
decimal(2,1)
Matrikelnr = Matrikelnr
Fachbereichnr = Fachbereichnr
Studierender
Matrikelnr
integer
Fachbereichnr
integer
Name
long varchar
Straße
long varchar
Ort
long varchar
© 2015 IAS, Universität Stuttgart
Matrikelnr = Matrikelnr
Relation Stud-FB
Fachbereichnr integer
Matikelnr
integer
332
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
Normalisierung
Ziel:
 keine untergeordneten Relationen
 so wenig Redundanz wie möglich
 keine Probleme bei der Datenpflege
Normalisierung erfolgt in mehreren Stufen
Beispiel: unnormalisierte Relation
Matri- Name
kelnr
5001 Müller, Mike
Straße
Ort
FBnr
FB
Mühlbach 12
Mühlhausen 10
ETI
5003
Maier, Max
Bachstr. 8
Sipplingen
12
MA
5007
Stoll, Silke
Kurzgasse 25
Stuttgart
14
EE
Dekan Prüfung
nr
Gö
1200
1212
1250
At
1200
1400
Te
1200
1312
Prüfung
Prüfer
Note
ST I
ST II
AT I
ST I
TDF
ST I
Info II
Gö
Ja
Mw
Gö
Xy
Gö
Fa
2,7
1,3
1,7
2,3
4,0
1,0
2,3
Relation Studierender
© 2015 IAS, Universität Stuttgart
333
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
1. Normalform
1. NF:
Alle Attribute sind atomar
Normalisierungsschritt: eigene Relation für jedes nichtatomare Attribut
und Verknüpfung über Fremdschlüssel
Relationen in 1. NF
Matrikelnr
5001
5003
5007
Name
Straße
Ort
Müller, Mike
Maier, Max
Stoll, Silke
Mühlbach 12
Bachstr. 8
Kurzgasse 25
Mühlhausen 10
Sipplingen
12
Stuttgart
14
Matrikelnr
5001
5001
5001
5003
5003
5007
5007
Prüfung
nr
1200
1212
1250
1200
1400
1200
1312
Prüfung
Prüfer
Note
ST I
ST II
AT I
ST I
TDF
ST I
Info II
Gö
Ja
Mw
Gö
XY
Gö
Fa
2,7
1,3
1,7
2,3
4,0
1,0
2,3
© 2015 IAS, Universität Stuttgart
FBnr
FB
Dekan
ETI
MA
EE
Gö
At
Te
Relation Studierender (1.NF)
Relation Prüfungsleistung (1.NF)
334
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
2. Normalform
2. NF:
1.NF und alle Attribute, die nicht zu einem Schlüssel
gehören, sind von diesem voll funktional abhängig
Normalisierungsschritt: neue Relation aus den Attributen, welche bereits von
einem Teil eines Schlüssels abhängig sind
Beispiel Relation Prüfungsleistung (1.NF)
Matrikelnr
5001
5001
5001
5003
5003
5007
5007
Prüfung
nr
1200
1212
1250
1200
1400
1200
1312
Prüfung
Prüfer
Note
ST I
ST II
AT I
ST I
TDF
ST I
Info III
Gö
Ja
Mw
Gö
XY
Gö
Fa
2,7
1,3
1,7
2,3
4,0
1,0
2,3
Relation
Prüfung
(2.NF)
Relation
Prüfungsleistung
(2.NF)
Schlüssel: Matrikelnr, Prüfungnr
Funktionale Abhängigkeiten:
1. Matrikelnr, Prüfungnr  Note
2. Prüfungnr  Prüfung, Prüfer
© 2015 IAS, Universität Stuttgart
()
()
Prüfung
nr
1200
1212
1250
1400
1312
Matrikelnr
5001
5001
5001
5003
5003
5007
5007
Prüfung
Prüfer
ST I
ST II
AT I
TDF
Info II
Gö
Ja
Mw
XY
Fa
Prüfung
nr
1200
1212
1250
1200
1400
1200
1312
Note
2,7
1,3
1,7
2,3
4,0
1,0
2,3
335
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
3. Normalform
3. NF:
2.NF und alle Attribute, die nicht zu einem Schlüssel
gehören, sind von diesem nicht transitiv abhängig
Normalisierungsschritt: neue Relation aus den Attributen, welche von einem
Schlüssels transitiv abhängig sind
Beispiel
Matrikelnr
Relation 5001
Studierender 5003
(1.NF+2.NF) 5007
Schlüssel: Matrikelnr
Name
Straße
Ort
Müller, Mike
Maier, Max
Stoll, Silke
Mühlbach 12
Bachstr. 8
Kurzgasse 25
Mühlhausen 10
Sipplingen
12
Stuttgart
14
Funktionale Abhängigkeiten:
1. Matrikelnr  FBnr,
2. FBnr  FB, Dekan
Matri- Name
Straße
kelnr
5001 Müller, Mike Mühlbach 12
5003 Maier, Max
Bachstr. 8
5007 Stoll, Silke
Kurzgasse 25
Relation Studierender (3.NF)
© 2015 IAS, Universität Stuttgart
Ort
Mühlhausen
Sipplingen
Stuttgart
FBnr
FB
Dekan
ETI
MA
EE
Gö
At
Te
Transitive Abhängigkeit
Matrikelnr  FB, Dekan
FBnr
FBnr
10
12
14
FB
ETI
MA
EE
Dekan
Gö
At
Te
10
12
14
Relation Fachbereich (3.NF)
336
7.4 Entwurf von Relationalen Datenbanksystemen
ST II
Weitere Normalformen
– Boyce-Codd-Normalform
– 4. Normalform
– 5. Normalform
Nachteile weiterer Normalisierung:
Viele Relationen/Tabellen entstehen
Schema wird unübersichtlich
Sinkende Performanz, da viele Verbundoperationen (Joins)
notwendig
 Stellenweise gezielte Denormalisierung
© 2015 IAS, Universität Stuttgart
337
7.4 Entwurf von Relationalen Datenbanksystemen

Ziel:
ST II
Physischer Entwurf
Entwicklung des internen Schemas
z. B.
– Aufteilung der Datenbank auf verschiedene Platten oder Server
– Indexe zur Zugriffsbeschleunigung

Ziel:
Datenbankrealisierung
Implementierung der Datenstruktur mit SQL
z. B.
CREATE TABLE Prüfungsleistung
(
Matrikelnr INTEGER
NOT NULL,
Prüfungnr INTEGER
NOT NULL,
Note
DECIMAL (2,1)
NOT NULL,
PRIMARY KEY (Matrikelnr, Prüfungnr));
© 2015 IAS, Universität Stuttgart
338
7.4 Entwurf von Relationalen Datenbanksystemen

Ziel:
ST II
Anwendungsimplementierung
Implementierung der Anwendung (Benutzungsoberfläche)
z. B. mit Hilfe von embedded SQL
SELECT count(*)
INTO :anzahl
FROM Prüfungsleistung
Speicherung der Anzahl von Prüfungen in der Variable anzahl der
Wirtssprache
SQL allein bietet keine Kontrollstrukturen
wie Verzweigungen oder Schleifen
© 2015 IAS, Universität Stuttgart
339
Frage zu Kapitel 7.4
ST II
Frage zu Kapitel 7.4
Warum werden im logischen Datenbankschema vorwiegend künstliche
Primärschlüssel verwendet?
Antwort

 Eindeutigkeit immer gegeben

 Weniger Speicherplatzbedarf als (zusammengesetzte) natürliche
Schlüsselattribute
f  Notwendig zur Vergabe der Zugriffsrechte

 Primärschlüsselwert (und ggf. Fremdschlüsselwert) muss später nicht
geändert werden
© 2015 IAS, Universität Stuttgart
340
Softwaretechnik II
§7
Datenbanksysteme
7.1
Einführung in Datenbanksysteme
7.2
Relationale Datenbanksysteme
7.3
Datenbanksprachen
7.4
Entwurf von Relationalen Datenbanksystemen
7.5
Objektorientierte Datenbanksysteme und neue Entwicklungen
© 2015 IAS, Universität Stuttgart
ST II
341
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Objektorientierte Datenbanken (OODBS)
Nachteile der Datenmodellierung mit klassischen Verfahren
– Datenobjekte nur als Tupel einfacher, unstrukturierter Attribute
– Nur einfache (Standard-) Datentypen
– Keine komplexen semantischen Integritätsbedingungen im
Datenmodell selbst
– Normalisierung mit Aufsplitterung des Datenbestandes bedeutet
viele Externspeicherzugriffe
– Diskrepanz zwischen Datenbankmodell und (OO-) Programmiersprache
 Aufwändige Transformationsoperationen
© 2015 IAS, Universität Stuttgart
342
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Definition eines objektorientierten DBS (Atkinson, 1989)
Ein objektorientiertes Datenbanksystem muss
– Ein Datenbanksystem und
–
ein objektorientiertes System sein
Grundlegende Aspekte eines objektorientierten Systems:
– Objektidentität
–
Komplexe Objekte
–
Kapselung
–
Typ-/Klassenhierarchie
–
Vererbung
–
Überladen und spätes Binden
–
Operationale Vollständigkeit
–
Erweiterbarkeit
© 2015 IAS, Universität Stuttgart
343
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Schemadefinition in
objektorientierten
Datenbanksystemen
define type Lager
supertypes = {Entity}
properties =
{ Adresse
:
Lagerflaeche
:
hat_gelagert
:
Beispiel
};
operations =
{ Anlegen ( ... );
Aufloesen ( ... );
};
end Lager;
In Lagern
können
verschiedene
Geräte vorrätig
sein, die für
bestimmte
Projekte
eingesetzt
werden
können
© 2015 IAS, Universität Stuttgart
define type Geraet
supertypes = {Entity}
properties =
{ Geraete_Nr
:
Bezeichnung
:
Standort
:
eingesetzt_bei
:
String;
Integer;
optional distributed
Set (Geraet)
invers Geraet$Standort;
Integer;
String;
Lager
invers Lager$hat_gelagert;
optional distributed
Set (Projekt)
invers Projekt$braucht;
};
operations =
{ Einlagerung (Ort: Lager);
Einsetzen (Wo: Projekt);
.
.
.
};
end Geraet;
344
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Abfragen in objektorientierten Datenbanken
Herstellerspezifische Abfragesprachen, z.B.
– O2SQL (Datenbanksystem O2)
– Erweiterung von C++ (Datenbanksystem ObjectStore)
Standardisierungsbemühungen: OQL (Object Query Language) der
ODMG (Object Data Management Group)
– Basiert auf der SELECT-Anweisung aus SQL92
– Ist deklarativ
– Neben Mengen können auch Tupel und Listen als
Anfrageergebnis ermittelt werden
– Enthält keine Änderungsbefehle
(müssen über eigene Methoden realisiert werden)
– Festgelegte Einbettung in OO-Programmiersprachen
(C++ OQL, Java OQL)
© 2015 IAS, Universität Stuttgart
345
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Objektrelationale Datenbanken (ORDBMS)
– Erweiterung von RDBMS um objektorientierte Konzepte
– Benutzerdefinierte Datentypen
– Komplexe Datentypen (nicht-atomar)
– Relationale Konzepte werden beibehalten (z.B. deklarativer Zugriff)
Heute:
Herstellerspezifische Erweiterungen
In Zukunft:
Standard SQL3
© 2015 IAS, Universität Stuttgart
346
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Deduktive Datenbanksysteme
–
Zusätzlich Regeln zur Ableitung implizit vorhandener Informationen
–
Verwaltete Informationen werden als Fakten bezeichnet
z. B.
Fakten:
Elternschaft
Elternteil Kind
Martin
Lisa
Lisa
Sandra
Maria
Michaela
Martin
Mike
Robin
Ralf
Abfrage: Wer sind die Kinder von Martin?
Logik: ?- Elternschaft(Martin, X)
Antwort: X={Lisa, Mike}
Regeln:
Vorfahre(X,Y) :- Elternschaft(X,Y).
Vorfahre(X,Y) :- Elternschaft(X,Z), Vorfahre (Z,Y).
Abfrage: Wer sind die Vorfahren von Sandra?
Logik:
?- Vorfahre(X, Sandra)
Antwort: X={Lisa, Martin}
© 2015 IAS, Universität Stuttgart
347
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Aktive Datenbanksysteme
Überwachen den Systemzustand
Veranlassen Aktionen automatisch und rechtzeitig
Mechanismen:
– Trigger
• Werden durch Modifikationsoperationen ausgelöst
• Bestehen aus einer Folge von Datenbankoperationen
– Alerter
• Reaktion mit Anwendungsbezug (z.B. Auslösen von
Nachbestellungen)
• Semantik der Reaktion ist dem DBMS nicht mehr bekannt
– Regeln
• Verarbeitungswissen in Form von WENN-DANN-Regeln
• Aktualisierung abgeleiteter Daten, wenn sich die zu Grunde liegenden
Daten ändern
• Aktivität wird auf Grund logischer Situation ausgelöst
© 2015 IAS, Universität Stuttgart
348
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Temporale Datenbanksysteme
Nachteile klassischer Datenbanksysteme
– Beschreibung der Anwendung zum jeweils aktuellen Zeitpunkt
– Vorhergegangene Werte nicht mehr verfügbar
Temporale Datenbanksysteme
– Speicherung der verschiedenen Versionen eines Objektes/Attributes
– Relation = dreidimensionales Objekt (Attribute, Werte, Zeit)
– Zeitarten: Transaktionszeit, gültige Zeit („Verfallsdatum“), benutzerdef. Zeit
Beispielrelation mit Transaktionszeit Abfrage:
Was war Martins Titel am 10.12.2010?
Name
Titel
Martin
Martin
Robin
Robin
Robin
Assistent
Professor
Student
Assistent
Professor
Trans.
Beginn
25.08.2005
15.05.2014
22.07.2004
24.11.2007
22.03.2012
© 2015 IAS, Universität Stuttgart
Trans.
Ende
15.12.2010
SELECT Titel
23.11.2007
22.03.2010
WHERE Name = ‘Martin‘
FROM Mitarbeiter
AS OF ‘10.12.2010‘
349
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Echtzeit-Datenbanksysteme
Unterschied zu DBS:
Transaktion muss innerhalb garantierter Zeit (Deadline) beendet sein
Schwierigkeiten bei harten Deadlines:
– Schwankende Auslastung des DBMS
– Unvorhersehbare Mehrbenutzereffekte (z.B. Sperrkonflikte)
Lösungsansätze
– Berücksichtigung der Deadlines durch Prioritäten für Transaktionen
– Behandlung von Synchronitätskonflikten
© 2015 IAS, Universität Stuttgart
350
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Mobile Datenbanksysteme
– Möglichst wenig Ressourcenbedarf
– Replikationsmechanismen zum Datenabgleich
Lösungsansatz:
Analyse der Anwendung und Entfernen nicht benötigter Funktionalität aus
dem DBMS
Embedded Datenbanksysteme
DBMS kann direkt in die Anwendung eingebunden werden
z.B. als Klasse in eine Java-Anwendung
© 2015 IAS, Universität Stuttgart
351
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Föderierte Datenbanksysteme
– Integration logisch und physisch verteilter Datenbanksysteme
(Komponentendatenbanksysteme KDBS)
– Erhaltung der lokalen Autonomie soweit möglich
Referenz-Architektur
FDBS
globale
– Übergreifendes Schema
Anwendung
– Verwaltung von Metainformationen
und Daten auf globaler Ebene
– Anwendungen können über eine
Schnittstelle auf gesamtes System
zugreifen
FDBMS
Präsentation
Metadaten
Integration
Datenzugriff
lokale
Anwendung
RDBMS
OODBMS
KDBS
DB 1
DB 2
FDBS
© 2015 IAS, Universität Stuttgart
352
7.5 Objektorientierte Datenbanksysteme und neue Entwicklungen
ST II
Beispiele für Datenbanksysteme
Desktop-Datenbanken: Microsoft Access, MySQL, XAMPP
– Lokaler Einbenutzerbetrieb
– Werkzeuge für einfache Erstellung von Benutzungsoberflächen
– Eingeschränkte SQL-Abfragemöglichkeiten
– Kostengünstig
Datenbank-Server: Oracle, IBM DB/2, Microsoft SQL Server
– Optimiert für viele Benutzer und hohen Datendurchsatz
– Umfangreiche Administrationswerkzeuge
– Volle SQL-Funktionalität, eigene SQL-Erweiterungen
– Objektrelationale Erweiterungen
© 2015 IAS, Universität Stuttgart
353
Frage zu Kapitel 7.5
ST II
Frage zu Kapitel 7.5
Welche Mechanismen können zur Überwachung des Systemzustands
verwendet werden?
Antwort
 Regeln

 Trigger

f  Datenmanipulation


Alerter
f  Datenspeicherung
© 2015 IAS, Universität Stuttgart
354
Vorbereitungsfragen
ST II
Vorbereitungsfragen zu § 7
Frage 1: Datenmodellierung (WS 04/05)
Was ist die Aufgabe der relationalen Datenmodellierung? Welche Teilaufgaben müssen
dabei durchgeführt werden?
Frage 2: Föderierte Datenbanksysteme (WS 07/08)
Wozu dienen die föderierten Datenbanksysteme? Welche Eigenschaften haben Sie?
Frage 3: Normalform (SS 08)
Gegeben ist folgende Tabelle:
CD-Nr.
Interpret
Albumtitel 1
Gründungsjahr der Band
1
Dire Straits
Brothers In Arms
1978
Ist diese Tabelle in der 3. Normalform? Begründen Sie Ihre Aussage. Falls Ihre Antwort
negativ ist, dann bringen Sie die Tabelle in die 3. Normalform.
Hinweis: Jedes Album kann man nur einmal kaufen.
© 2015 IAS, Universität Stuttgart
355