©2001 Johann Eder Datenbanken:Einführung 2
Inhalt
1. Einführung, Grundbegriffe
2. Modellierung
3. Relationenmodell
4. Relationale Sprachen (SQL)
©2001 Johann Eder Datenbanken:Einführung 3
Ziele
Teilnehmer
verstehen die grundlegenden Funktionsweisen von
Datenbanksystemen
Kennen die charakteristischen Eigenschaften von
Datenbanken
können kleinere Datenbanken entwerfen
können Daten aus Datenbanken abfragen
©2001 Johann Eder Datenbanken:Einführung 4
Literatur
Atzeni, P.; Ceri, S.; ParaboschiS.;Torlone, R.:Database Systems: Concepts, Languagesand Architectures.McGraw-Hill Publishing Company, 1999.
Date, C.J.: An Introduction to Database Systems.Vol. I, 6th edition, Addison-Wesley, 1995.
Elmasri, R.; Navathe, Sh.B.:Fundamentals of Database Systems.Benjamin Cummings, 3rd ed., 1999.
Kemper, A; Eickler A.:Datenbanksysteme.2. Aufl., Oldenbourg Verlag, 1997
Ullmann, J.D.:Principles of Database andKnowledge-Base Systems.Vol. I, Computer Science Press, 1988.
Vossen, G.:Datenmodelle, Datenbanksprachenund Datenbankmanagement-Systeme.Oldenbourg Verlag, München, 1999.
©2001 Johann Eder Datenbanken:Einführung 5
Einführung Warum Datenbanken?
ANSI / SPARC 3-Schichten Architektur
Charakteristische Eigenschaften
Architektur und Datenmodelle
Schnittstellen
Rollen / Benutzer
©2001 Johann Eder Datenbanken:Einführung 6
Warum Datenbanken?
„... kaum eine größere Informatikanwendung ist ohne DB-Unterstützung denkbar“
„DB-Systeme ... sind heute ein selbstverständliches Hilfsmittel der betrieblichen Organisation und Verwaltung geworden“
„Datenbanken ... als Schlüsseltechnologie für die Realisierung komplexer Informationssysteme ...“
©2001 Johann Eder Datenbanken:Einführung 7
Kennzeichen der Daten
Lange Lebensdauer (Jahre, Jahrzehnte)
reguläre Strukturen
große Datenobjekte, große Datenmengen
stetig anwachsende, integrierte Bestände (Giga-, Terabyte an Informationen)
immer wiederkehrende Muster in den Objektbeziehungen
©2001 Johann Eder Datenbanken:Einführung 8
Warum Datenbanksysteme?Probleme mit Dateisystemen
Bsp.: Programm Lohnverrechnung
Datei Angestellter (SV#, Name, Adresse, Gehalt)
Programm Projekte
Datei Mitarbeiter (Projekt#, SV#, Name, Telefon#)
Datei Projekt (Projekt#, Projektbeschreibung)
LOHN
PROJEKT
Mitarbeiter
Projekt
AngestellterNachteile:
Daten-Programm-Abhängigkeit
Redundanz, Inkonsistenz
Inflexibilität
Standards schwer durchsetzbar
©2001 Johann Eder Datenbanken:Einführung 9
Warum Datenbanksysteme (2)
F 1.6 Scan
©2001 Johann Eder Datenbanken:Einführung 10
ANSI-SPARC3-Schichten Modell
Externe Modelle: Sicht von
Benutzer(gruppen) Anwendungsprogramm
en
Konzeptuelles Modell einheitliche
Gesamtschau der Unternehmensdaten
Internes Modell physische
Speicherstrukturen
Internes ModellInternes Modell
Konzeptuelles Modell
Konzeptuelles Modell
...
Externe Modelle
©2001 Johann Eder Datenbanken:Einführung 11
Vorteile von Datenbankenphysische Datenunabhängigkeit
Internes Schema kann geändert werden, ohne Anwendungsprogramme zu ändern
Änderung nur bei Abbildung konzept. Schema - internes Schema
logische Datenunabhängigkeit konzeptuelles Schema kann geändert werden ohne
Anwendungsprogramme zu ändern solange das entspr. externe Modell abgeleitet werden kann
Ändern Abb. Konzeptuelles Schema - externes Schema
integrierte zentrale Verwaltung Standards Redundanzen Konsistenz
©2001 Johann Eder Datenbanken:Einführung 12
Eigenschaften von Datenbanken
Persistenz
Management von Sekundärspeichern
Mehrbenutzerfähigkeit
Zuverlässigkeit
Datensicherheit
ad-hoc Abfragesprachen
©2001 Johann Eder Datenbanken:Einführung 13
Persistenz
Daten „überleben“ das Ende von Sitzungen, das Ende von Transaktionen
Daten sind z.T. sehr langlebig
Daten können „in situ“ aktualisiert werden
©2001 Johann Eder Datenbanken:Einführung 14
Verwaltung von Sekundärspeichern
Verwaltung großer Datenmengen üblicherweise auf Platten
Datenbanken sind Ein-/Ausgabe-intensiv
Spezifische Techniken zur Erhöhung der Performanz Pufferung (DB Puffer im Hauptspeicher) Indexierung, Cluster Abfrageoptimierung
©2001 Johann Eder Datenbanken:Einführung 15
Mehrbenutzerfähigkeit
mehrere Benutzer können gleichzeitig auf den Daten arbeiten
DBMS sorgt dafür, daß keine unerwünschten Wechselwirkungen durch gleichzeitige Manipulation derselben Daten eintreten
Erhaltung der Integrität
Lost-update
read(X)
X:= X+10
write(X)
read(X)
X:=X-20
write(X)
©2001 Johann Eder Datenbanken:Einführung 16
Zuverlässigkeit der Daten
Daten sind teuer und strategisch wichtig -
müssen daher zuverlässig sein
DBMS bestätigt jede durchgeführte Änderung
bei Systemfehler: DB-Zustand wiederherstellen, der genau alle bestätigten Änderungen enthält.
roll-backward:
Eliminieren der Auswirkungen aller unbestätigten Transaktionen
roll-forward:
Nachziehen der Auswirkungen aller bestätigten Transaktionen auf Sicherungskopie.
©2001 Johann Eder Datenbanken:Einführung 17
Datensicherheit
Schutz vor unberechtigtem Zugriff
Berechtigungssystem definieren Sicherheitssubjekte (Benutzer, Rollen, etc.) Sicherheitsobjekte (Daten) Rechte (Lesen, Schreiben - i.e. verändern) Weitergabe von Rechten
Zugriff durch Nichtberechtigte verhindern bei jedem Zugriff Berechtigungen überprüfen
©2001 Johann Eder Datenbanken:Einführung 18
Ad-hoc Abfragesprachen
Abfrage von Daten ohne eigenes prozedurales Programm schreiben zu müssen
deklarativer Zugriff
SQL, QBE, etc.
„Wie hoch ist das Durchschnitts- gehalt der Manager in den einzelnen Städten in denen mindestens 5 Manager beschäftigt sind?“
Select city, avg(salaray)
from emp, dept
where emp.deptno = dept.deptno
and emp.job = “manager“
group by city
having count(*) >= 5
©2001 Johann Eder Datenbanken:Einführung 19
Wichtige Begriffe
Datenbankmanagementsystem (DBMS)
Software, die die DB verwaltet und alle von den
Anwendungsprogrammen verlangten Funktionen
zentral durchführt
Datenbanksystem (DBS)
DBMS + DB
Datenbank (DB)
integriert vom DBMS verwaltete Dateien
©2001 Johann Eder Datenbanken:Einführung 20
Schnittstellen
DBMS-Shell SQL-Befehle eingeben und durchführen
graphische Schnittstellen (Browser)formularbasierte Schnittstellen (Masken)natürlichsprachliche SchnittstellenSchnittstellen für Anwendungsprogramme
SprachenDatendefinitionssprache (DDL)
formulieren der Schemata
Datenmanipulationssprache (DML) abfragen, einfügen, löschen, aktualisieren von Daten
©2001 Johann Eder Datenbanken:Einführung 21
Dienstprogramme
DB-Loader: Laden von Daten in eine DatenbankBackup: Erstellen von SicherungskopienReorg: Reorganisation der Datenstrukturen zur PerformanzverbesserungBerichtsgeneratoren (report writer)
formatieren von Berichten (komplexen Abfragen) Kopf-und Fußzeilen, Text Seitenumbruch, Zwischensummen, Gruppenwechsel, etc.
Anwendungsgeneratoren (4GL-Sprachen)Monitor (Performanz, Tuning)Datenwörterbuch (Data Dictionary)Kommunikationssubsysteme
©2001 Johann Eder Datenbanken:Einführung 22
Personen und Rollen
Datenbankadministrator verwaltet die Ressource Datenbank internes Schema Vergabe von Zutrittsrechten Tuning und Monitoring Sicherheit und Zuverlässigkeit
Unternehmensadministrator (Datenbankdesigner)
zuständig für konzeptuelles Schema externe Schemata Schnittstelle zu Software-Entwicklung
©2001 Johann Eder Datenbanken:Einführung 23
Personen und Rollen (2)Systemanalytiker, Anwendungsprogrammierer
Anforderungserhebung Software-Entwicklung
Endbenutzer gelegentliche Benutzer z.B. Manager
unterschiedliche, z.T. nicht vorhersehbare Informationsbedürfnisse
von „schnell mal nachschauen“ bis komplexe Analysen
parametrische Benutzer z.B. Sachbearbeiter Anwendungsprogramme, „canned transactions“
Power-User z.B. Analytiker komplexe Anforderungen gute Kenntnis von DB + Schnittstellen
©2001 Johann Eder Datenbanken:Einführung 24
Produkte
OracleDB2SQL-ServerAccessInformixSybaseIngresProgressAdabas....
©2001 Johann Eder Datenbanken:Einführung 25
Kapitel 2:Modellierung
Datenbank-Entwurf
©2001 Johann Eder Datenbanken:Einführung 26
Datenbank-Entwurf
Ziele:
• gutes Abbild der Realität
• Konsistenz
• keine ungeplanten Redundanzen
• niedrige Antwortzeiten
• niedriger Speicherplatzbedarf
• niedriger Wartungs-/Pflegeaufwand
• Einfachheit
©2001 Johann Eder Datenbanken:Einführung 27
5 Phasen der DB-Entwicklung 1. Informationsbedarfsanalyse
wer braucht welche Daten wann in welcher Qualität
2. konzeptueller Entwurf formalisierte Beschreibung des Umweltausschnitts häufig mit graphischem semantischen Datenmodell
3. logischer Entwurf Abbilden des konzeptuellen Modells auf Datenmodell des
DBS
4. physischer Entwurf Speicherstrukturen, Zugriffspfade festlegen
5. Verwendung, Wartung, Reorganisation Tuning Adaptieren
©2001 Johann Eder Datenbanken:Einführung 28
5 Phasen der DB-Entwicklung
(a) Informationsbedarfsanalyse • wer braucht wo? wann? was?
• relevante Informationen und Vorgänge aus dem und über
das Objektsystem
• Zusammenhänge zwischen
- Informationen
- Informationen und Vorgängen
• Vollständigkeit, Redundanz, Konsistenz
Was soll im zukünftigen Informationssystem enthalten sein?
Wie wird es verwendet?
©2001 Johann Eder Datenbanken:Einführung 29
5 Phasen der DB-Entwicklungb) Konzeptueller Entwurf
• formalisierte Beschreibung der ermittelten Informationen
und Funktionen
• häufig mit graphischem Darstellungsmodell
• entweder konzeptueller Entwurf des gesamten Bereiches
oder zuerst Formulierung der Modelle der einzelnen
Benutzersichten und anschließend Integration
(View-Integration)
• semantische Datenmodellierung:
Definition aller zulässigen Zustände und Zustands-
übergänge der Datenbasis des geplanten Informations-
systems
Ergebnis: konzeptuelles DB-Modell
©2001 Johann Eder Datenbanken:Einführung 30
5 Phasen der DB-Entwicklung
(c) Logischer Entwurf
Abbildung des konzeptuellen Modells auf das Datenmodell eines konkreten DBS.
Ergebnis: logisches DB-Schema
©2001 Johann Eder Datenbanken:Einführung 31
5 Phasen der DB-Entwicklung
(d) Physischer Entwurf
• Festlegen der Einzelheiten der physischen Darstellung der
Daten
• Abbildung auf Speicherstrukturen (Datenstrukturen)
• Bestimmen der Zugriffspfade
• verantwortlich für Antwortzeitverhalten und Speicherplatz-
bedarf
• erforderlich: Mengengerüst, Transaktionsprofil, Nebenbe-
dingungen (z.B. Antwortzeit für bestimmte Trans-
aktionen)
Ergebnis: physisches DB-Schema
©2001 Johann Eder Datenbanken:Einführung 32
5 Phasen der DB-Entwicklung(e) Verwendung - Wartung - Reorganisation
Reorganisation wegen:
veränderter Umweltbedingung
(dargestellte Realität hat sich gewandelt)
z.B.: - weitere Anwendungen
- modifizierte Aufgabenstellung
- veränderte gesetzliche Bestimmungen
(a)
Revidierung früherer Entwurfsentscheidungen für
Leistungsverbesserung
- Änderung der logischen Struktur (selten)
(c)
- Änderung der physischen Struktur
(d)
©2001 Johann Eder Datenbanken:Einführung 33
SemantischeDatenmodellierung
Beschreibung des betrachteten Ausschnitts der realen Welt
Miniwelt, Universe of Discourse
genaue (eindeutige, vollständige) Beschreibung aller für die Anwendung relevanten strukturellen Eigenschaftenin semantischer Beschreibungsspracheunabhängig von Hardware und Software
Ergebnis: konzeptuelles Datenbankschema
Verständigungsbasis für Entwerfer, Entwickler, Anwender
©2001 Johann Eder Datenbanken:Einführung 34
ER-Modellierung
Das Entity-Relationship (E-R) Modell ist ein konzeptuelles Datenmodell
Sprache zur Beschreibung der Datenanforderungen leicht zu verstehen und zu kommunizieren unabhängig von der tatsächlichen Realisierung in einem
DBMS-ProduktGraphische Sprache
graphische Repräsentation der Konstrukte E-R-Diagramme
Ursprung: P.Chen:´The Entity-Relationship Model -Toward a Unified
View of Data´, ACM TODS, Vol1/1, 1976viele extended E-R- Modelle
©2001 Johann Eder Datenbanken:Einführung 35
UML
Unified Modelling Language
Lingua franca der objektorientierten Softwareentwicklung
sehr großer Sprachumfang
8 Diagrammarten
hier: Teilmenge der Klassendiagramme
©2001 Johann Eder Datenbanken:Einführung 36
Entity, Gegenstand, Objekt
Einheit, Ganzheit, Gegenstand, Objekt
Modell, Abbild eines Gegenstandes, der in der betrachteten Realität erkannt und eindeutig identifiziert wird.
Beisp.: Kunde Otto Huber Bankkonto Nr 789.987.123 Buch
Objekt
©2001 Johann Eder Datenbanken:Einführung 37
AttributAttribut
Merkmale, CharakteristikBezeichnungen von Eigenschaften, die bei dem betrachteten Entity für die Anwendung relevant sindBeisp.: Vorname, Saldo, Geburtsdatum, Hausnummer
AttributsausprägungWert eines Attributes für ein bestimmtes EntityBeisp.: Mitarbeiter mit der MID 2317 wurde am 16.12.1965 geboren.
WertebereichMenge von Werten aus denen Ausprägungen eines Attributs stammen dürfen
©2001 Johann Eder Datenbanken:Einführung 38
Attribut(2)
Attribut ist eine Abbildung von einem Objekt in einen Wertebereich
Name Otto Huber
M-ID 2317
Geb.Datum 27.8.1965
©2001 Johann Eder Datenbanken:Einführung 39
Klassifikation
Objekte, bei denen dieselben Merkmale relevant sind und die semantisch gleichartig sind, werden zu Klassen zusammengefaßt.
Buch
KundeMitarbeiter
ExemplarAbteilung
©2001 Johann Eder Datenbanken:Einführung 40
Klassifikation (2)
Klasse Instanz
Mitarbeiter Karl Müller
Frieda Maier
Ottilie Huber
©2001 Johann Eder Datenbanken:Einführung 41
Assoziation (Relationships)
Repräsentieren logische Verbindungen (Beziehungen) zwischen Objekten
M1
M5
M4
M3
M6
M2 P1
P2
P3
P4
Mitarbeiter Projekte
©2001 Johann Eder Datenbanken:Einführung 42
Beispiele von Assoziationen
Mitarbeiter Projekt
ArtikelKundebestellt
zugeteilt
leitet
©2001 Johann Eder Datenbanken:Einführung 43
Assoziationen
Assoziationen können (mathematisch) als
Relationen dargestellt werden bestellt Kunde Artikel bestellt= {(k1, a1), (k2, a1), (k4, a3), (k4, a5), ...}
Assoziation hat Rollen, die von Objekten gefüllt werden:
bestellt hat die Rollen „Besteller“ und „Bestelltes“
gefüllt von Kunde und Artikel
©2001 Johann Eder Datenbanken:Einführung 44
Rekursive Beziehungen
Mitarbeiter
Kunde
Chef
Untergebener
ist Freund von
ist Vorgesetzter von
©2001 Johann Eder Datenbanken:Einführung 45
Beziehungen höheren Grades
Beispiel für eine ternäre BeziehungGrad: Anzahl der Klassen (Rollen), die an einer Beziehung teilnehmen
ArtikelLieferant liefert
Abteilung
©2001 Johann Eder Datenbanken:Einführung 46
Klasse mit Attributen
Person
PID einfaches Attribut
Name mehrfaches AttributVorname 1..3 (mehrwertiges)Hobbies 0..10 mengenwertiges Attribut
Adresse: zusammengesetztes (strukturiertes) AttributPLZ
OrtStraße
©2001 Johann Eder Datenbanken:Einführung 47
Assoziation mit Attributen
Mitarbeiter Projekt
% Zeit seit
leitet
ist zugeteilt
©2001 Johann Eder Datenbanken:Einführung 48
Beziehungsobjekte
Kunde Artikel
Mitarbeiter
bestellt
Bestellung
Datum
betreut von
©2001 Johann Eder Datenbanken:Einführung 49
Multiplizität von Assoziationen
Spezifikation der Zuordnungswertigkeit einer Beziehung
A Bi assoz. j
i: Anzahl der Instanzen der Klasse A, die mit einer Instanz
der Klasse B in Beziehung stehen können.
Angabe: Zahl, Intervall, *, Kombination
Bsp: 1; 0..5; *; 0..3, 7..9, *21, 5..*
©2001 Johann Eder Datenbanken:Einführung 50
Multiplizität - m : nSpezifikation der Zuordnungs-Wertigkeit einer Beziehung
M1
M5
M4
M3
M6
M2P1
P2
P3
P4
ProjektMitarbeiter 1..m 0..n zugeteilt
©2001 Johann Eder Datenbanken:Einführung 51
totale vs. partielle Assoziation
totale Beziehung: jede Instanz muß an einer Beziehung teilnehmenpartielle Beziehung: jede Instanz kann an einer Beziehung teilnehmen
Mitarbeiter Projekt
Abteilung
1..*
1..*
*
*
zugeteilt
arbeitet in
©2001 Johann Eder Datenbanken:Einführung 52
Multiplizität - 1:n
M1
M5
M4
M3
M6
M2P1
P2
P3
P4
ProjektMitarbeiter0..1 0..* leitet
©2001 Johann Eder Datenbanken:Einführung 53
Multiplizität - 1 : 1
M1
M5
M4
M3
M6
M2A1
A2
A3
A4
AbteilungMitarbeiter0..1 0..1leitet
©2001 Johann Eder Datenbanken:Einführung 54
Konsistenzbedingung
Mitarbeiter
GehaltMNr
Das (geplante) Ende eines Projektes darf nicht vor dem Start liegen.Der Leiter eines Projektes muß auch am Projekt mitarbeiten.Die Gesamtarbeitszeit eines Mitarbeiters an Projekten darf 100% nicht übersteigen.Kein Mitarbeiter eines Projektes darf mehr verdienen als der Projektleiter.
Projekt
StartEndePNr
leitet
arbeitet an
1 1
m n
Prozent
©2001 Johann Eder Datenbanken:Einführung 55
Multiplizität bei mehrstelligen Assoziationen
CA
B
i kj
i: Anzahl der Instanzen von A, die mit einem Paar
von Instanzen von B und C in Bezug stehen.
©2001 Johann Eder Datenbanken:Einführung 56
Multiplizität Beispiel
ÜbungStudent
Assistent
m 1
1
möglich:ein Student kann eine bestimmte Übung nur bei einem Assistenten besuchen und bei einem bestimmten Assistenten nur eine Übung
d.h.: f1: Student x Assistent Übung f2: Student x Übung Assistent
aber nicht: g1: Student Übung x Assistent g2: Assistent x Übung Student
©2001 Johann Eder Datenbanken:Einführung 57
Identifikation
Konzepte (Attribute, Entities), die ein Entity (Instanz) eindeutig identifizierenbesteht häufig aus einem oder mehreren Attributen (Schlüssel, interne Identifikatoren)Manchmal sind Attribute allein nicht ausreichend und Entities müssen über ihre Beziehung zu anderen Entities identifiziert werden - (externe) Identifikatoren
Beisp.: BLZ ist Schlüssel für Bank KontoNr nur innerhalb einer Bank eindeutig Konto wird über BLZ + KontoNr idenitifiziert
©2001 Johann Eder Datenbanken:Einführung 58
Beispiel Klassendiagramm
MitarbeiterMNr. keyNameJob
ProjektProj.Nr. keyBezeichnung
KundeKNr. keyNameAnschrift
BestellungBest.Nr. keyDaten
ProduktPreisProd.Nr. keyBezeichnung
Anteil
berichtet an
Mitarbeiter
Chef
arbeitet in
gibt auf
umfaßt
0..1 *
1
0..1
**
*
*
leitet
betreut
0..1
*
©2001 Johann Eder Datenbanken:Einführung 59
textuelle Beschreibung
Mitarbeiter haben eine MNr, einen Name und einen Job.Kunden haben eine KNr, einen Namen und eine Anschrift.Ein Mitarbeiter kann mehrere Kunden betreuen, ein Kunde wird von maximal einem Mitarbeiter betreut.Ein Produkt kann mehrfach bestellt werden.Eine Bestellung umfasst mehrere Produkte.Das Berichtswesen ist streng hierarchisch aufgebaut, jeder Mitarbeiter kann nur an einen Chef berichten.Ein Projekt wird von maximal einem Mitarbeiter geleitet, ein Mitarbeiter darf maximal ein Projekt leiten. An Projekten können mehrere Mitarbeiter arbeiten, ein Mitarbeiter kann an mehreren Projekten beteiligt sein.