Datenmanagement - DBSE

Datenmanagement
Dr.-Ing. Eike Schallehn
Universität Magdeburg
Institut für Technische & Betriebliche Informationssysteme
Sommersemester 2017
Schallehn
Datenmanagement
Sommersemester 2017
0–1
Quellen der Vorlesung
Hauptverantwortliche (siehe Literatur):
Gunter Saake
Andreas Heuer
Kai-Uwe Sattler
Weiterer Input von:
Ingo Schmidt
Thomas Leich
Holger Meyer
Eike Schallehn
Schallehn
Datenmanagement
Sommersemester 2017
0–2
Einführung
Organisatorisches: Magdeburg
Dozent: Eike Schallehn
Infos (Zeiten, Räume) & Folienkopien unter
I
I
http://wwwiti.cs.uni-magdeburg.de/ → Datenbanken → Lehre
LSF
Prüfung/ Schein
I
I
Klausur: Zulassung nach bestandener Übung (Übungsschein)
Schein: siehe Klausur mit Note <= 4.0
Feedback, Fragen, . . .
I
I
I
1. Nach der Vorlesung oder Übung
2. Mail: [email protected] ; Betreff: Datenmanagement
3. Telefon: 0391/67-52845
Schallehn
Datenmanagement
Sommersemester 2017
0–3
Einführung
Organisatorisches: Magdeburg – Übungen
Übungsleiter: (David Broneske), Holger Harzer, Florian Koch
Begleitende Übungen (siehe Übungsplan):
I
I
I
Ab zweiter Vorlesungswoche
60% der Aufgaben votieren und 4 Vorträge für Schein und Prüfung
Letzte Übungen sind praktisch (SQL)
Einschreibung ab 13 Uhr auf: https://omen.cs.
uni-magdeburg.de/einschreiben/index.php
Möglichkeit der Nutzung von SQLValidator
http://propra14.iti.cs.ovgu.de/sqlvali/
I
Passphrase: db-ss2017
Schallehn
Datenmanagement
Sommersemester 2017
0–4
Einführung
Zugrundeliegendes Lehrbuch
A. Heuer; G. Saake; K. Sattler:
Datenbanken — Konzepte und
Sprachen
5. Auflage, mitp-Verlag, 2013
Schallehn
Datenmanagement
Sommersemester 2017
0–5
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
3
Entity-Relationship-Modell
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
3
Entity-Relationship-Modell
4
Datenbankentwurf
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
3
Entity-Relationship-Modell
4
Datenbankentwurf
5
Relationale Entwurfstheorie
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
3
Entity-Relationship-Modell
4
Datenbankentwurf
5
Relationale Entwurfstheorie
6
SQL und weitere relationale Anfragesprachen
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
3
Entity-Relationship-Modell
4
Datenbankentwurf
5
Relationale Entwurfstheorie
6
SQL und weitere relationale Anfragesprachen
7
Integrität, Transaktionen und Trigger
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
3
Entity-Relationship-Modell
4
Datenbankentwurf
5
Relationale Entwurfstheorie
6
SQL und weitere relationale Anfragesprachen
7
Integrität, Transaktionen und Trigger
8
Sichten und Zugriffskontrolle
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Überblick
1
Was sind Datenbanken – Grundlegende Konzepte
2
Relationale Datenbanken – Daten als Tabellen
3
Entity-Relationship-Modell
4
Datenbankentwurf
5
Relationale Entwurfstheorie
6
SQL und weitere relationale Anfragesprachen
7
Integrität, Transaktionen und Trigger
8
Sichten und Zugriffskontrolle
9
Datenaustausch mit XML
Schallehn
Datenmanagement
Sommersemester 2017
0–6
Einführung
Weitere Literatur
G. Vossen.
Datenbankmodelle, Datenbanksprachen und
Datenbankmanagement-Systeme.
Oldenbourg-Verlag, München, 2000
R. Elmasri, S.B. Navathe.
Grundlagen von Datenbanksystemen.
Pearson, 2002
A. Kemper, A. Eickler.
Datenbanksysteme. Eine Einführung.
Oldenbourg-Verlag, München, 2004
A. Heuer, G. Saake, K. Sattler.
Datenbanken kompakt
2. Aufl., mitp-Verlag, Bonn, August 2003
G. Lausen.
Datenbanken – Grundlagen und XML-Technologien
Elsevier GmbH, 2005
Schallehn
Datenmanagement
Sommersemester 2017
0–7
Teil I
Was sind Datenbanken?
Was sind Datenbanken?
Was sind Datenbanken?
1
Überblick & Motivation
Schallehn
Datenmanagement
Sommersemester 2017
1–1
Was sind Datenbanken?
Was sind Datenbanken?
1
Überblick & Motivation
2
Architekturen
Schallehn
Datenmanagement
Sommersemester 2017
1–1
Was sind Datenbanken?
Was sind Datenbanken?
1
Überblick & Motivation
2
Architekturen
3
Einsatzgebiete
Schallehn
Datenmanagement
Sommersemester 2017
1–1
Was sind Datenbanken?
Was sind Datenbanken?
1
Überblick & Motivation
2
Architekturen
3
Einsatzgebiete
4
Historisches
Schallehn
Datenmanagement
Sommersemester 2017
1–1
Was sind Datenbanken?
Lernziele für heute . . .
Motivation für den Einsatz von
Datenbanksystemen
Schallehn
Datenmanagement
Sommersemester 2017
1–2
Was sind Datenbanken?
Lernziele für heute . . .
Motivation für den Einsatz von
Datenbanksystemen
Kenntnis grundlegender Architekturen
Schallehn
Datenmanagement
Sommersemester 2017
1–2
Was sind Datenbanken?
Überblick & Motivation
Was sind Datenbanken?
Daten = logisch gruppierte Informationseinheiten
Bank =
Die Sicherheit vor Verlusten ist eine
Hauptmotivation, etwas „auf die Bank
zu bringen“.
Eine Bank bietet Dienstleistungen für
mehrere Kunden an, um effizient
arbeiten zu können.
Eine Datenbank hat die (langfristige)
Aufbewahrung von Daten als Aufgabe.
Schallehn
Datenmanagement
Sommersemester 2017
1–3
Was sind Datenbanken?
Überblick & Motivation
Anwendungsbeispiele
Schallehn
Datenmanagement
Sommersemester 2017
1–4
Was sind Datenbanken?
Überblick & Motivation
Wie verwaltet man Datenbanken?
Ohne Datenbanken
jedes Anwendungssystem verwaltet seine eigenen Daten
Daten sind mehrfach gespeichert
Probleme
I
I
I
redundant
Verschwendung von Speicherplatz
„Vergessen“ von Änderungen
keine zentrale, „genormte“ Datenhaltung
Schallehn
Datenmanagement
Sommersemester 2017
1–5
Was sind Datenbanken?
Überblick & Motivation
Probleme der Datenredundanz
Andere Softwaresysteme können große Mengen von Daten nicht
effizient verarbeiten
Mehrere Benutzer oder Anwendungen können nicht parallel auf
den gleichen Daten arbeiten, ohne sich zu stören
Anwendungsprogrammierer / Benutzer können Anwendungen
nicht programmieren / benutzen, ohne
I
I
interne Darstellung der Daten
Speichermedien oder Rechner
zu kennen (Datenunabhängigkeit nicht gewährleistet)
Datenschutz und Datensicherheit sind nicht gewährleistet
Schallehn
Datenmanagement
Sommersemester 2017
1–6
Was sind Datenbanken?
Überblick & Motivation
Idee: Datenintegration durch Datenbanksysteme
Anwendung
...
Anwendung
DBMS
Datenbankmanagementsystem =
Software zur Verwaltung von
Datenbanken
DBS =
Datenbanksystem
Datenbank
Schallehn
Datenmanagement
strukturierter, von DBMS
verwalteter Datenbestand
Sommersemester 2017
1–7
Was sind Datenbanken?
Überblick & Motivation
Motivation
Datenbanksysteme sind
Herzstück heutiger
IT-Infrastrukturen
. . . allgegenwärtig
Datenbankspezialisten sind
gefragt
Schallehn
Datenmanagement
Sommersemester 2017
1–8
Was sind Datenbanken?
Überblick & Motivation
Fragestellungen
1
Wie organisiert (modelliert und nutzt) man Daten?
2
Wie werden Daten dauerhaft verlässlich gespeichert?
3
Wie kann man riesige Datenmengen (≥ Terabytes) effizient
verarbeiten?
4
Wie können viele Nutzer (≥ 10.000) gleichzeitig mit den Daten
arbeiten?
Schallehn
Datenmanagement
Sommersemester 2017
1–9
Was sind Datenbanken?
Überblick & Motivation
Fragestellungen
1
Wie organisiert (modelliert und nutzt) man Daten?
2
Wie werden Daten dauerhaft verlässlich gespeichert?
3
Wie kann man riesige Datenmengen (≥ Terabytes) effizient
verarbeiten?
4
Wie können viele Nutzer (≥ 10.000) gleichzeitig mit den Daten
arbeiten?
Schallehn
Datenmanagement
Sommersemester 2017
1–9
Was sind Datenbanken?
Architekturen
Prinzipien: Die neun Codd’schen Regeln
1
2
3
4
5
6
7
8
9
Integration: einheitliche, nichtredundante Datenverwaltung
Operationen: Speichern, Suchen, Ändern
Katalog: Zugriffe auf Datenbankbeschreibungen im Data
Dictionary
Benutzersichten
Integritätssicherung: Korrektheit des Datenbankinhalts
Datenschutz: Ausschluss unauthorisierter Zugriffe
Transaktionen: mehrere DB-Operationen als Funktionseinheit
Synchronisation: parallele Transaktionen koordinieren
Datensicherung: Wiederherstellung von Daten nach
Systemfehlern
Schallehn
Datenmanagement
Sommersemester 2017
1–10
Was sind Datenbanken?
Architekturen
Datenunabhängigkeit und Schemata
Basierend auf DBMS-Grobarchitektur
Entkopplung von Benutzer- und Implementierungssicht
Ziele u.a.:
I
I
I
I
Trennung von Modellierungssicht und interner Speicherung
Portierbarkeit
Tuning vereinfachen
standardisierte Schnittstellen
Schallehn
Datenmanagement
Sommersemester 2017
1–11
Was sind Datenbanken?
Architekturen
Schemaarchitektur
Zusammenhang zwischen
I
I
I
I
Konzeptuellem Schema (Ergebnis der Datendefinition)
Internem Schema (Festlegung der Dateiorganisationen und
Zugriffspfade)
Externen Schemata (Ergebnis der Sichtdefinition)
Anwendungsprogrammen (Ergebnis der
Anwendungsprogrammierung)
Schallehn
Datenmanagement
Sommersemester 2017
1–12
Was sind Datenbanken?
Architekturen
Schemaarchitektur /2
Trennung Schema — Instanz
I
I
Schema (Metadaten, Datenbeschreibungen)
Instanz (Anwenderdaten, Datenbankzustand oder -ausprägung)
Datenbankschema besteht aus
I
internem, konzeptuellem, externen Schemata und den
Anwendungsprogrammen
im konzeptuellen Schema etwa:
I
I
I
Strukturbeschreibungen
Integritätsbedingungen
Autorisierungsregeln (pro Benutzer für erlaubte DB-Zugriffe)
Schallehn
Datenmanagement
Sommersemester 2017
1–13
Was sind Datenbanken?
Architekturen
Schemaarchitektur /3
externes
Schema 1
Konzeptuelles
Schema
internes
Schema
Datenmanagement
externes
Schema N
Datendarstellung
Anfragebearbeitung
Schallehn
...
Sommersemester 2017
1–14
Was sind Datenbanken?
Architekturen
Datenunabhängigkeit /2
Stabilität der Benutzerschnittstelle gegen Änderungen
physisch: Änderungen der Dateiorganisationen und Zugriffspfade
haben keinen Einfluss auf das konzeptuelle Schema
logisch: Änderungen am konzeptuellen und gewissen externen
Schemata haben keine Auswirkungen auf andere externe
Schemata und Anwendungsprogramme
Schallehn
Datenmanagement
Sommersemester 2017
1–15
Was sind Datenbanken?
Architekturen
Datenunabhängigkeit /3
mögliche Auswirkungen von Änderungen am konzeptuellen
Schema:
I
I
eventuell externe Schemata betroffen (Ändern von Attributen)
eventuell Anwendungsprogramme betroffen (Rekompilieren der
Anwendungsprogramme, eventuell Änderungen nötig)
nötige Änderungen werden jedoch vom DBMS erkannt und
überwacht
Schallehn
Datenmanagement
Sommersemester 2017
1–16
Was sind Datenbanken?
Architekturen
Anwendungsbeispiel: Musikversand
Titel
Musiker
Jahr
Preis
Rezension(en)
Tracks
Schallehn
Datenmanagement
Sommersemester 2017
1–17
Was sind Datenbanken?
Architekturen
Ebenen-Architektur am Beispiel
Konzeptuelle Sicht: Darstellung in Tabellen (Relationen)
Musiker MNr
103
104
105
Album ANr
1014
1015
1016
1021
1025
Schallehn
Name
Apocalyptica
Subway To Sally
Rammstein
Titel
Amplified
Nord Nord Ost
Rosenrot
Engelskrieger
Reflections
Land
Finnland
Deutschland
Deutschland
Jahr
2006
2005
2005
2003
2006
Genre
Rock
Rock
Rock
Rock
Rock
Datenmanagement
MNr → Musiker
103
104
105
104
103
Sommersemester 2017
1–18
Was sind Datenbanken?
Architekturen
Ebenen-Architektur am Beispiel /2
Externe Sicht: Daten in einer flachen Relation
ANr
1014
1015
1016
1021
1025
Schallehn
Titel
Amplified
Nord Nord Ost
Rosenrot
Engelskrieger
Reflections
Jahr
2006
2005
2005
2003
2006
Genre
Rock
Rock
Rock
Rock
Rock
Datenmanagement
Musiker
Apocalyptica
Subway To Sally
Rammstein
Subway To Sally
Apocalyptica
Sommersemester 2017
1–19
Was sind Datenbanken?
Architekturen
Ebenen-Architektur am Beispiel /3
Externe Sicht: Daten in einer hierarchisch aufgebauten Relation
Musiker
Titel
Apocalyptica
Subway To Sally
Rammstein
Schallehn
Album
Jahr
Amplified
Reflections
Nord Nord Ost
Engelskrieger
Rosenrot
Datenmanagement
2006
2003
2005
2003
2005
Genre
Rock
Rock
Metal
Rock
Rock
Sommersemester 2017
1–20
Was sind Datenbanken?
Architekturen
Ebenen-Architektur am Beispiel /4
Interne Darstellung
1000
1500
2000
Baumzugriff
über
Albumnummer
teilweises
Speichern
der Datensätze
im Baum
1014 Amplified 2006
1015 Nord Nord Ost 2005
19.99 Rock
15.99 Rock
Schallehn
103
104
....
....
Überlaufbereich für
Datensätze
Datenmanagement
Sommersemester 2017
1–21
Was sind Datenbanken?
Architekturen
System-Architekturen
Beschreibung der Komponenten eines Datenbanksystems
Standardisierung der Schnittstellen zwischen Komponenten
Architekturvorschläge
I
I
ANSI-SPARC-Architektur
Drei-Ebenen-Architektur
Fünf-Schichten-Architektur
beschreibt Transformationskomponenten im Detail
Vorlesung „Datenbank-Implementierungstechniken“
Schallehn
Datenmanagement
Sommersemester 2017
1–22
Was sind Datenbanken?
Architekturen
ANSI-SPARC-Architektur
ANSI: American National Standards Institute
SPARC: Standards Planning and Requirement Committee
Vorschlag von 1978
Im Wesentlichen Grobarchitektur verfeinert
I
I
I
Interne Ebene / Betriebssystem verfeinert
Mehr Interaktive und Programmier-Komponenten
Schnittstellen bezeichnet und normiert
Schallehn
Datenmanagement
Sommersemester 2017
1–23
Was sind Datenbanken?
Architekturen
ANSI-SPARC-Architektur /2
Externe Ebene
Konzeptuelle Ebene
Interne Ebene
Optimierer
Plattenzugriff
Anfragen
Auswertung
Updates
P1
...
Pn
DBOperationen
Data
Dictionary
Einbettung
Masken
Sichtdefinition
Datendefinition
Schallehn
Datenmanagement
Dateiorganisation
Sommersemester 2017
1–24
Was sind Datenbanken?
Architekturen
Klassifizierung der Komponenten
Definitionskomponenten: Datendefinition, Dateiorganisation,
Sichtdefinition
Programmierkomponenten: DB-Programmierung mit
eingebetteten DB-Operationen
Benutzerkomponenten: Anwendungsprogramme, Anfrage und
Update interaktiv
Transformationskomponenten: Optimierer, Auswertung,
Plattenzugriffssteuerung
Data Dictionary (Datenwörterbuch): Aufnahme der Daten aus
Definitionskomponenten, Versorgung der anderen Komponenten
Schallehn
Datenmanagement
Sommersemester 2017
1–25
Was sind Datenbanken?
Architekturen
Fünf-Schichten-Architektur
Verfeinerung der Transformationsschritte
Mengenorientierte
Schnittstelle
Datensystem
Satzorientierte
Schnittstelle
Übersetzung
Zugriffspfadwahl
Zugriffssystem
Logische Zugriffspfade,
Schemakatalog, Sortierung,
Transaktionsverwaltung
Speichersystem
Speicherungsstrukturen, Zugriffspfadverwaltung, Sperrverwaltung, Logging, Recovery
Interne
Satzschnittstelle
Systempufferschnittstelle
Pufferverwaltung
Dateischnittstelle
Betriebssystem
Systempufferverwaltung,
Seitenersetzung, Seitenzuordnung
Externspeicherverwaltung,
Speicherzuordnung
Geräteschnittstelle
Externspeicher
Schallehn
Datenmanagement
Sommersemester 2017
1–26
Was sind Datenbanken?
Architekturen
Anwendungsarchitekturen
Architektur von Datenbankanwendungen tpyischerweise auf Basis
des Client-Server-Modells: Server ≡ Datenbanksystem
Client
(Dienstnehmer)
Server
(Diensterbringer)
1. Anforderung
2. Bearbeitung
3. Antwort
Schallehn
Datenmanagement
Sommersemester 2017
1–27
Was sind Datenbanken?
Architekturen
Anwendungsarchitekturen /2
Aufteilung der Funktionalitäten einer Anwendung
I
I
I
Präsentation und Benutzerinteraktion
Anwendungslogik („Business“-Logik)
Datenmanagementfunktionen (Speichern, Anfragen, . . . ).
Benutzerschnittstelle
Anwendungslogik
Benutzerschnittstelle
Client
DB-Schnittstelle
Anwendungslogik
DB-Schnittstelle
DB-Server
Zwei-Schichten-Architektur
Schallehn
Client
Applikationsserver
DB-Server
Drei-Schichten-Architektur
Datenmanagement
Sommersemester 2017
1–28
Was sind Datenbanken?
Einsatzgebiete
Einige konkrete Systeme
(Objekt-)Relationale DBMS
I
I
Oracle11g, IBM DB2 V.9, Microsoft SQL Server 2008
MySQL (www.mysql.org), PostgreSQL
(www.postgresql.org), Ingres (www.ingres.com), FireBird
(www.firebirdsql.org)
Pseudo-DBMS
I
MS Access
Objektorientierte DBMS
I
Poet, Versant, ObjectStore
XML-DBMS
I
Tamino (Software AG), eXcelon
NoSQL-Systeme
I
Graph-Datenbanksysteme (InfiniteGraph, neo4j),
Dokument-Datenbanken (MongoDB), Key-Value-Stores, ....
Schallehn
Datenmanagement
Sommersemester 2017
1–29
Was sind Datenbanken?
Einsatzgebiete
Einsatzgebiete
Klassische Einsatzgebiete:
I
I
I
viele Objekte (15000 Bücher, 300 Benutzer, 100 Ausleihvorgänge
pro Woche, . . . )
wenige Objekttypen (BUCH, BENUTZER, AUSLEIHUNG)
etwa Buchhaltungssysteme, Auftragserfassungssysteme,
Bibliothekssysteme, . . .
Aktuelle Anwendungen:
I
E-Commerce, entscheidungsunterstützende Systeme (Data
Warehouses, OLAP), NASA’s Earth Observation System
(Petabyte-Datenbanken), Data Mining
Schallehn
Datenmanagement
Sommersemester 2017
1–30
Was sind Datenbanken?
Einsatzgebiete
Datenbankgrößen
eBay Data Warehouse
10 PB (= 10 · 1015 Bytes)
Teradata DBMS, 72 Knoten, 10.000 Nutzer,
mehrere Millionen Anfragen/Tag
WalMart Data Warehouse
2,5 PB
Teradata DBMS, NCR MPP-Hardware;
Produktinfos (Verkäufe etc.) von 2.900 Märkten;
50.000 Anfragen/Woche
Facebook
x.000 MySQL-Server
400 TB
Hadoop/Hive, 610 Knoten, 15 TB/Tag
US Library of Congress
nicht digitalisiert
10-20 TB
PB für Petabyte entspricht der Größenordnung 1015
Schallehn
Datenmanagement
Sommersemester 2017
1–31
Was sind Datenbanken?
Historisches
Entwicklungslinien: 60er Jahre
Anfang 60er Jahre: elementare Dateien, anwendungsspezifische
Datenorganisation (geräteabhängig, redundant, inkonsistent)
Ende 60er Jahre: Dateiverwaltungssysteme (SAM, ISAM) mit
Dienstprogrammen (Sortieren) (geräteunabhängig, aber
redundant und inkonsistent)
DBS basierend auf hierarchischem Modell, Netzwerkmodell
I
I
I
I
Zeigerstrukturen zwischen Daten
Schwache Trennung interne / konzeptuelle Ebene
Navigierende DML
Trennung DML / Programmiersprache
Schallehn
Datenmanagement
Sommersemester 2017
1–32
Was sind Datenbanken?
Historisches
Entwicklungslinien: 70er und 80er Jahre
70er Jahre: Datenbanksysteme (Geräte- und
Datenunabhängigkeit, redundanzfrei, konsistent)
Relationale Datenbanksysteme
I
I
I
I
Daten in Tabellenstrukturen
3-Ebenen-Konzept
Deklarative DML
Trennung DML / Programmiersprache
Schallehn
Datenmanagement
Sommersemester 2017
1–33
Was sind Datenbanken?
Historisches
Historie von RDBMS
1970: Ted Codd (IBM) → Relationenmodell als konzeptionelle
Grundlage relationaler DBS
1974: System R (IBM) → erster Prototyp eines RDBMS
I
I
I
zwei Module: RDS, RSS; ca. 80.000 LOC (PL/1, PL/S, Assembler),
ca. 1,2 MB Codegröße
Anfragesprache SEQUEL
erste Installation 1977
1975: University of California at Berkeley (UCB) → Ingres
I
I
Anfragesprache QUEL
Vorgänger von Postgres, Sybase, . . .
1979: Oracle Version 2
Schallehn
Datenmanagement
Sommersemester 2017
1–34
Was sind Datenbanken?
Historisches
Entwicklungslinien: (80er und) 90er Jahre
Wissensbanksysteme
I
I
Daten in Tabellenstrukturen
Stark deklarative DML, integrierte Datenbankprogrammiersprache
Objektorientierte Datenbanksysteme
I
I
I
I
Daten in komplexeren Objektstrukturen (Trennung Objekt und seine
Daten)
Deklarative oder navigierende DML
Oft integrierte Datenbankprogrammiersprache
Oft keine vollständige Ebenentrennung
Schallehn
Datenmanagement
Sommersemester 2017
1–35
Was sind Datenbanken?
Historisches
Entwicklungslinien: heute
Unterstützung für spezielle Anwendungen
I
I
I
I
I
I
I
I
Hochskalierbare, parallele Datenbanksysteme: Umgang mit
Datenmengen im PB-Bereich
Cloud-Datenbanken: Hosting von Datenbanken, Skalierbare
Datenmanagementlösungen
Datenstromverarbeitung: Online-Verarbeitung von Live-Daten
(Börseninfos, Sensordaten, RFID-Daten, . . . )
XML-Datenbanken: Verwaltung semistrukturierter Daten
(XML-Dokumente)
Multimediadatenbanken: Verwaltung multimedialer Objekte (Bilder,
Audio, Video)
Verteilte Datenbanken: Verteilung von Daten auf verschiedene
Rechnerknoten
Föderierte Datenbanken, Multidatenbanken, Mediatoren:
Integration von Daten aus heterogenen Quellen (Datenbanken,
Dateien, Web-Quellen)
Mobile Datenbanken: Datenverwaltung auf Kleinstgeräten
(Sensorknoten, Smartphones)
Schallehn
Datenmanagement
Sommersemester 2017
1–36
Was sind Datenbanken?
Historisches
Trends
Nutzergenerierte Inhalte, z.B. Google:
I
I
I
Verarbeitung von 20 PB täglich
15h Video-Upload auf YouTube in jeder Minute
Lesen von 20 PB würde 12 Jahre benötigen bei 50 MB/s-Festplatte
Linked Data und Data Web
I
I
I
Bereitstellung, Austausch und Verknüpfung von strukturierten
Daten im Web
ermöglicht Abfrage (mit Anfragesprachen wie SPARQL) und
Weiterverarbeitung
Beispiele: DBpedia, GeoNames
Schallehn
Datenmanagement
Sommersemester 2017
1–37
Was sind Datenbanken?
Historisches
Zusammenfassung
Motivation für Einsatz von Datenbanksystemen
Codd’sche Regeln
3-Ebenen-Schemaarchitektur & Datenunabhängigkeit
Einsatzgebiete
Schallehn
Datenmanagement
Sommersemester 2017
1–38
Was sind Datenbanken?
Historisches
Kontrollfragen
Welchen Vorteil bieten Datenbanksysteme
gegenüber einer anwendungsspezifischen
Speicherung von Daten?
Schallehn
Datenmanagement
Sommersemester 2017
1–39
Was sind Datenbanken?
Historisches
Kontrollfragen
Welchen Vorteil bieten Datenbanksysteme
gegenüber einer anwendungsspezifischen
Speicherung von Daten?
Was versteht man unter
Datenunabhängigkeit und wie wird sie
erreicht?
Schallehn
Datenmanagement
Sommersemester 2017
1–39
Was sind Datenbanken?
Historisches
Kontrollfragen
Welchen Vorteil bieten Datenbanksysteme
gegenüber einer anwendungsspezifischen
Speicherung von Daten?
Was versteht man unter
Datenunabhängigkeit und wie wird sie
erreicht?
In welchen Bereichen kommen
Datenbanksysteme zum Einsatz?
Schallehn
Datenmanagement
Sommersemester 2017
1–39
Teil II
Relationale Datenbanken – Daten als
Tabellen
Relationale Datenbanken – Daten als Tabellen
Relationale Datenbanken – Daten als Tabellen
1
Relationen für tabellarische Daten
Schallehn
Datenmanagement
Sommersemester 2017
2–1
Relationale Datenbanken – Daten als Tabellen
Relationale Datenbanken – Daten als Tabellen
1
Relationen für tabellarische Daten
2
SQL-Datendefinition
Schallehn
Datenmanagement
Sommersemester 2017
2–1
Relationale Datenbanken – Daten als Tabellen
Relationale Datenbanken – Daten als Tabellen
1
Relationen für tabellarische Daten
2
SQL-Datendefinition
3
Grundoperationen: Die Relationenalgebra
Schallehn
Datenmanagement
Sommersemester 2017
2–1
Relationale Datenbanken – Daten als Tabellen
Relationale Datenbanken – Daten als Tabellen
1
Relationen für tabellarische Daten
2
SQL-Datendefinition
3
Grundoperationen: Die Relationenalgebra
4
SQL als Anfragesprache
Schallehn
Datenmanagement
Sommersemester 2017
2–1
Relationale Datenbanken – Daten als Tabellen
Relationale Datenbanken – Daten als Tabellen
1
Relationen für tabellarische Daten
2
SQL-Datendefinition
3
Grundoperationen: Die Relationenalgebra
4
SQL als Anfragesprache
5
Änderungsoperationen in SQL
Schallehn
Datenmanagement
Sommersemester 2017
2–1
Relationale Datenbanken – Daten als Tabellen
Lernziele für heute . . .
Grundverständnis zur Struktur relationaler
Datenbanken
Schallehn
Datenmanagement
Sommersemester 2017
2–2
Relationale Datenbanken – Daten als Tabellen
Lernziele für heute . . .
Grundverständnis zur Struktur relationaler
Datenbanken
Kenntnis der Basisoperationen relationaler
Anfragesprachen
Schallehn
Datenmanagement
Sommersemester 2017
2–2
Relationale Datenbanken – Daten als Tabellen
Lernziele für heute . . .
Grundverständnis zur Struktur relationaler
Datenbanken
Kenntnis der Basisoperationen relationaler
Anfragesprachen
elementare Fähigkeiten in der Anwendung
von SQL
Schallehn
Datenmanagement
Sommersemester 2017
2–2
Relationale Datenbanken – Daten als Tabellen
Relationen für tabellarische Daten
Relationenmodell
Konzeptuell ist die Datenbank eine Menge von Tabellen
WEINE
WeinID
Name
1042
2168
3456
2171
3478
4711
4961
ERZEUGER
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
Farbe
Jahrgang
Rot
Rot
Rot
Rot
Rot
Weiß
Weiß
1998
2003
2004
2001
1999
1999
2002
Weingut
Château La Rose
Creek
Helena
Creek
Helena
Müller
Bighorn
Weingut
Anbaugebiet
Region
Creek
Helena
Château La Rose
Château La Pointe
Müller
Bighorn
Barossa Valley
Napa Valley
Saint-Emilion
Pomerol
Rheingau
Napa Valley
South Australia
Kalifornien
Bordeaux
Bordeaux
Hessen
Kalifornien
Tabelle = „Relation“
Schallehn
Datenmanagement
Sommersemester 2017
2–3
Relationale Datenbanken – Daten als Tabellen
Relationen für tabellarische Daten
Darstellung von Relationen und Begriffe
Fett geschriebene Zeilen: Relationenschema
Weitere Einträge in der Tabelle: Relation
Eine Zeile der Tabelle: Tupel
Eine Spaltenüberschrift: Attribut
Ein Eintrag: Attributwert
Attribut
Relationenname
R
Tupel
A1
...
...
An
...
Relationenschema
Relation
...
Schallehn
Datenmanagement
Sommersemester 2017
2–4
Relationale Datenbanken – Daten als Tabellen
Relationen für tabellarische Daten
Integritätsbedingungen: Schlüssel
Attribute einer Spalte identifizieren eindeutig gespeicherte Tupel:
Schlüsseleigenschaft
etwa Weingut für Tabelle ERZEUGER
ERZEUGER
Weingut
Anbaugebiet
Region
Creek
Helena
Château La Rose
Château La Pointe
Müller
Bighorn
Barossa Valley
Napa Valley
Saint-Emilion
Pomerol
Rheingau
Napa Valley
South Australia
Kalifornien
Bordeaux
Bordeaux
Hessen
Kalifornien
auch Attributkombinationen können Schlüssel sein!
Schlüssel können durch Unterstreichen gekennzeichnet werden
Schallehn
Datenmanagement
Sommersemester 2017
2–5
Relationale Datenbanken – Daten als Tabellen
Relationen für tabellarische Daten
Integritätsbedingungen: Fremdschlüssel
Schlüssel einer Tabelle können in einer anderen (oder derselben!)
Tabelle als eindeutige Verweise genutzt werden: Fremdschlüssel,
referenzielle Integrität
etwa Weingut als Verweise auf ERZEUGER
ein Fremdschlüssel ist ein Schlüssel in einer „fremden“ Tabelle
Schallehn
Datenmanagement
Sommersemester 2017
2–6
Relationale Datenbanken – Daten als Tabellen
Relationen für tabellarische Daten
Fremdschlüssel /2
WEINE
WeinID
Name
1042
2168
3456
2171
3478
4711
4961
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
ERZEUGER
Farbe
Rot
Rot
Rot
Rot
Rot
Weiß
Weiß
Jahrgang
1998
2003
2004
2001
1999
1999
2002
Weingut → ERZEUGER
Château La Rose
Creek
Helena
Creek
Helena
Müller
Bighorn
Weingut
Anbaugebiet
Region
Creek
Helena
Château La Rose
Château La Pointe
Müller
Bighorn
Barossa Valley
Napa Valley
Saint-Emilion
Pomerol
Rheingau
Napa Valley
South Australia
Kalifornien
Bordeaux
Bordeaux
Hessen
Kalifornien
Schallehn
Datenmanagement
Sommersemester 2017
2–7
Relationale Datenbanken – Daten als Tabellen
SQL-Datendefinition
Die Anweisung create table
create table basisrelationenname (
spaltenname1 wertebereich1 [not null],
...
spaltennamek wertebereichk [not null])
Wirkung dieses Kommandos ist sowohl
I
I
die Ablage des Relationenschemas im Data Dictionary, als auch
die Vorbereitung einer „leeren Basisrelation“ in der Datenbank
Schallehn
Datenmanagement
Sommersemester 2017
2–8
Relationale Datenbanken – Daten als Tabellen
SQL-Datendefinition
Mögliche Wertebereiche in SQL
integer (oder auch integer4, int),
smallint (oder auch integer2),
float(p) (oder auch kurz float),
decimal(p,q) und numeric(p,q) mit jeweils q
Nachkommastellen,
character(n) (oder kurz char(n), bei n = 1 auch char) für
Zeichenketten (Strings) fester Länge n,
character varying(n) (oder kurz varchar(n) für Strings
variabler Länge bis zur Maximallänge n,
bit(n) oder bit varying(n) analog für Bitfolgen, und
date, time bzw. timestamp für Datums-, Zeit- und kombinierte
Datums-Zeit-Angaben
Schallehn
Datenmanagement
Sommersemester 2017
2–9
Relationale Datenbanken – Daten als Tabellen
SQL-Datendefinition
Beispiel für create table
create table WEINE (
WeinID int not null,
Name varchar(20) not null,
Farbe varchar(10),
Jahrgang int,
Weingut varchar(20))
primary key kennzeichnet Spalte als Schlüsselattribut
Schallehn
Datenmanagement
Sommersemester 2017
2–10
Relationale Datenbanken – Daten als Tabellen
SQL-Datendefinition
create table mit Fremdschlüssel
create table WEINE (
WeinID int,
Name varchar(20) not null,
Farbe WeinFarbe,
Jahrgang int,
Weingut varchar(20),
primary key(WeinID),
foreign key(Weingut) references ERZEUGER(Weingut
foreign key kennzeichnet Spalte als Fremdschlüssel
Schallehn
Datenmanagement
Sommersemester 2017
2–11
Relationale Datenbanken – Daten als Tabellen
SQL-Datendefinition
Nullwerte
not null schließt in bestimmten Spalten Nullwerte als
Attributwerte aus
Kennzeichnung von Nullwerte in SQL durch null; hier ⊥
null repräsentiert die Bedeutung „Wert unbekannt“, „Wert nicht
anwendbar“ oder „Wert existiert nicht“, gehört aber zu keinem
Wertebereich
null kann in allen Spalten auftauchen, außer in
Schlüsselattributen und den mit not null gekennzeichneten
Schallehn
Datenmanagement
Sommersemester 2017
2–12
Relationale Datenbanken – Daten als Tabellen
SQL-Datendefinition
Weiteres zur Datendefinition in SQL
Neben Primär- und Fremdschlüsseln können in SQL angegeben
werden:
I
I
I
mit der default-Klausel Defaultwerte für Attribute,
mit der create domain-Anweisung benutzerdefinierte
Wertebereiche und
mit der check-Klausel weitere lokale Integritätsbedingungen
innerhalb der zu definierenden Wertebereiche, Attribute und
Relationenschemata
Schallehn
Datenmanagement
Sommersemester 2017
2–13
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Anfrageoperationen auf Tabellen
Basisoperationen auf Tabellen, die die Berechnung von neuen
Ergebnistabellen aus gespeicherten Datenbanktabellen erlauben
Operationen werden zur sogenannten Relationenalgebra
zusammengefasst
Mathematik: Algebra ist definiert durch Wertebereich sowie darauf
definierten Operationen
→ für Datenbankanfragen entsprechen die Inhalte der Datenbank
den Werten, Operationen sind dagegen Funktionen zum
Berechnen der Anfrageergebnisse
Anfrageoperationen sind beliebig kombinierbar und bilden eine
Algebra zum „Rechnen mit Tabellen“ – die sogenannte relationale
Algebra oder auch Relationenalgebra
Schallehn
Datenmanagement
Sommersemester 2017
2–14
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Relationenalgebra: Übersicht
Selektion
Projektion
Verbund
Schallehn
a1
b2
b2
c3
a1
b2
c3
a2
b2
b3
c4
a2
b2
c3
a2
b3
b4
c5
a2
b3
c4
Datenmanagement
Sommersemester 2017
2–15
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Selektion σ
Selektion: Auswahl von Zeilen einer Tabelle anhand eines
Selektionsprädikats
σJahrgang>2000 (WEINE)
WeinID
2168
3456
2171
4961
Schallehn
Name
Creek Shiraz
Zinfandel
Pinot Noir
Chardonnay
Farbe
Rot
Rot
Rot
Weiß
Datenmanagement
Jahrgang
2003
2004
2001
2002
Weingut
Creek
Helena
Creek
Bighorn
Sommersemester 2017
2–16
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Projektion π
Projektion: Auswahl von Spalten durch Angabe einer Attributliste
πRegion (ERZEUGER)
Region
South Australia
Kalifornien
Bordeaux
Hessen
Schallehn
Datenmanagement
Sommersemester 2017
2–17
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Projektion π
Projektion: Auswahl von Spalten durch Angabe einer Attributliste
πRegion (ERZEUGER)
Region
South Australia
Kalifornien
Bordeaux
Hessen
Die Projektion entfernt doppelte Tupel.
Schallehn
Datenmanagement
Sommersemester 2017
2–17
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Natürlicher Verbund o
n
Verbund (engl. join): verknüpft Tabellen über gleichbenannte
Spalten, indem er jeweils zwei Tupel verschmilzt, falls sie dort
gleiche Werte aufweisen
WEINE o
n ERZEUGER
WeinID
Name
...
Weingut
Anbaugebiet
Region
1042
2168
3456
2171
3478
4711
4961
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
...
...
...
...
...
...
...
Ch. La Rose
Creek
Helena
Creek
Helena
Müller
Bighorn
Saint-Emilion
Barossa Valley
Napa Valley
Barossa Valley
Napa Valley
Rheingau
Napa Valley
Bordeaux
South Australia
Kalifornien
South Australia
Kalifornien
Hessen
Kalifornien
Schallehn
Datenmanagement
Sommersemester 2017
2–18
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Natürlicher Verbund o
n
Verbund (engl. join): verknüpft Tabellen über gleichbenannte
Spalten, indem er jeweils zwei Tupel verschmilzt, falls sie dort
gleiche Werte aufweisen
WEINE o
n ERZEUGER
WeinID
Name
...
Weingut
Anbaugebiet
Region
1042
2168
3456
2171
3478
4711
4961
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
...
...
...
...
...
...
...
Ch. La Rose
Creek
Helena
Creek
Helena
Müller
Bighorn
Saint-Emilion
Barossa Valley
Napa Valley
Barossa Valley
Napa Valley
Rheingau
Napa Valley
Bordeaux
South Australia
Kalifornien
South Australia
Kalifornien
Hessen
Kalifornien
Das Weingut „Château La Pointe“ ist im Ergebnis verschwunden
Tupel, die keinen Partner finden (dangling tuples), werden
eliminiert
Schallehn
Datenmanagement
Sommersemester 2017
2–18
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Kombination von Operationen
πName,Farbe,Weingut (σJahrgang>2000 (WEINE) o
n
σRegion=’Kalifornien’ (ERZEUGER))
ergibt
Name
Zinfandel
Chardonnay
Schallehn
Farbe
Rot
Weiß
Datenmanagement
Weingut
Helena
Bighorn
Sommersemester 2017
2–19
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Umbenennung β
Anpassung von Attributnamen mittels Umbenennung:
EMPFEHLUNG Wein
WEINLISTE Name
La Rose Grand Cru
La Rose Grand Cru
Creek Shiraz
Riesling Reserve
Zinfandel
Merlot Selection
Pinot Noir
Sauvignon Blanc
Riesling Reserve
Angleichen durch:
βName←Wein (EMPFEHLUNG)
Schallehn
Datenmanagement
Sommersemester 2017
2–20
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Mengenoperationen
Vereinigung r1 ∪ r2 von zwei Relationen r1 und r2 : sammelt die
Tupelmengen zweier Relationen unter einem gemeinsamen
Schema auf
Attributmengen beider Relationen müssen identisch sein
WEINLISTE ∪ βName←Wein (EMPFEHLUNG)
Name
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Riesling Reserve
Merlot Selection
Sauvignon Blanc
Schallehn
Datenmanagement
Sommersemester 2017
2–21
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Mengenoperationen /2
Differenz r1 − r2 eliminiert die Tupel aus der ersten Relation, die
auch in der zweiten Relation vorkommen
WEINLISTE − βName←Wein (EMPFEHLUNG)
ergibt:
Name
Creek Shiraz
Zinfandel
Pinot Noir
Schallehn
Datenmanagement
Sommersemester 2017
2–22
Relationale Datenbanken – Daten als Tabellen
Grundoperationen: Die Relationenalgebra
Mengenoperationen /3
Durchschnitt r1 ∩ r2 : ergibt die Tupel, die in beiden Relationen
gemeinsam vorkommen
WEINLISTE ∩ βName←Wein (EMPFEHLUNG)
liefert:
Name
La Rose Grand Cru
Riesling Reserve
Schallehn
Datenmanagement
Sommersemester 2017
2–23
Relationale Datenbanken – Daten als Tabellen
SQL als Anfragesprache
SQL-Anfrage als Standardsprache
Anfrage an eine einzelne Tabelle
select Name, Farbe
from WEINE
where Jahrgang = 2002
SQL hat Multimengensemantik — Duplikate in Tabellen werden in
SQL nicht automatisch unterdrückt!
Mengensemantik durch distinct
select distinct Name
from WEINE
Schallehn
Datenmanagement
Sommersemester 2017
2–24
Relationale Datenbanken – Daten als Tabellen
SQL als Anfragesprache
Verknüpfung von Tabellen
Kreuzprodukt als Basisverknüpfung
select *
from WEINE, ERZEUGER
Verbund durch Operator natural join
select *
from WEINE natural join ERZEUGER
Verbund alternativ durch Angabe einer Verbundbedingung!
select *
from WEINE, ERZEUGER
where WEINE.Weingut = ERZEUGER.Weingut
Schallehn
Datenmanagement
Sommersemester 2017
2–25
Relationale Datenbanken – Daten als Tabellen
SQL als Anfragesprache
Kombination von Bedingungen
Ausdruck in Relationenalgebra
πName,Farbe,Weingut (σJahrgang>2000 (WEINE) o
n
σRegion=’Kalifornien’ (ERZEUGER))
Anfrage in SQL
select Name, Farbe, WEINE.Weingut
from WEINE, ERZEUGER
where Jahrgang > 2000 and
Region = ’Kalifornien’ and
WEINE.Weingut = ERZEUGER.Weingut
Schallehn
Datenmanagement
Sommersemester 2017
2–26
Relationale Datenbanken – Daten als Tabellen
SQL als Anfragesprache
Mengenoperationen in SQL
Vereinigung in SQL explizit mit union
Differenzbildung durch geschachtelte Anfragen
select *
from WINZER
where Name not in (
select Nachname
from KRITIKER)
Schallehn
Datenmanagement
Sommersemester 2017
2–27
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Änderungsoperationen in SQL
insert: Einfügen eines oder mehrerer Tupel in eine Basisrelation
oder Sicht
update: Ändern von einem oder mehreren Tupel in einer
Basisrelation oder Sicht
delete: Löschen eines oder mehrerer Tupel aus einer
Basisrelation oder Sicht
Lokale und globale Integritätsbedingungen müssen bei
Änderungsoperationen automatisch vom System überprüft
werden
Schallehn
Datenmanagement
Sommersemester 2017
2–28
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Die update-Anweisung
Syntax:
update basisrelation
set
attribut1 = ausdruck1
...
attributn = ausdruckn
[ where bedingung ]
Schallehn
Datenmanagement
Sommersemester 2017
2–29
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Beispiel für update
WEINE
WeinID
2168
3456
2171
3478
4711
4961
Name
Farbe
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
Rot
Rot
Rot
Rot
Weiß
Weiß
Jahrgang
2003
2004
2001
1999
1999
2002
Weingut
Creek
Helena
Creek
Helena
Müller
Bighorn
Preis
7.99
5.99
10.99
19.99
14.99
9.90
update WEINE
set Preis = Preis * 1.10
where Jahrgang < 2000
Schallehn
Datenmanagement
Sommersemester 2017
2–30
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Beispiel für update: neue Werte
WEINE
WeinID
2168
3456
2171
3478
4711
4961
Schallehn
Name
Farbe
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
Rot
Rot
Rot
Rot
Weiß
Weiß
Jahrgang
Datenmanagement
2003
2004
2001
1999
1999
2002
Weingut
Preis
Creek
Helena
Creek
Helena
Müller
Bighorn
7.99
5.99
10.99
21.99
16.49
9.90
Sommersemester 2017
2–31
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Weiteres zu update
Realisierung von Eintupel-Operation mittels Primärschlüssel:
update WEINE
set Preis = 7.99
where WeinID = 3456
Änderung der gesamten Relation:
update WEINE
set Preis = 11
Schallehn
Datenmanagement
Sommersemester 2017
2–32
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Die delete-Anweisung
Syntax:
delete
from basisrelation
[ where bedingung ]
Löschen eines Tupels in der WEINE-Relation:
delete from WEINE
where WeinID = 4711
Schallehn
Datenmanagement
Sommersemester 2017
2–33
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Weiteres zu delete
Standardfall ist das Löschen mehrerer Tupel:
delete from WEINE
where Farbe = ’Weiß’
Löschen der gesamten Relation:
delete from WEINE
Schallehn
Datenmanagement
Sommersemester 2017
2–34
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Weiteres zu delete /2
Löschoperationen können zur Verletzung von
Integritätsbedingungen führen!
Beispiel: Verletzung der Fremdschlüsseleigenschaft, falls es noch
Weine von diesem Erzeuger gibt:
delete from ERZEUGER
where Anbaugebiet = ’Hessen’
Schallehn
Datenmanagement
Sommersemester 2017
2–35
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Die insert-Anweisung
Syntax:
insert
into basisrelation
[ (attribut1 , ..., attributn ) ]
values (konstante1 , ..., konstanten )
optionale Attributliste ermöglicht das Einfügen von
unvollständigen Tupeln
Schallehn
Datenmanagement
Sommersemester 2017
2–36
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
insert-Beispiele
insert into ERZEUGER (Weingut, Region)
values (’Wairau Hills’, ’Marlborough’)
nicht alle Attribute angegeben
Land wird null
Wert des fehlenden Attribut
insert into ERZEUGER
values (’Château Lafitte’, ’Medoc’, ’Bordeaux’)
Schallehn
Datenmanagement
Sommersemester 2017
2–37
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Einfügen von berechneten Daten
Syntax:
insert
into basisrelation
[ (attribut1 , ..., attributn ) ]
SQL-anfrage
Beispiel:
insert into WEINE
select ProdID, ProdName, ’Rot’, ProdJahr,
’Château Lafitte’
from LIEFERANT
where LName = ’Wein-Kontor’
Schallehn
Datenmanagement
Sommersemester 2017
2–38
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Zusammenfassung
Relationenmodell: Datenbank als Sammlung von Tabellen
Integritätsbedingungen im Relationenmodell
Tabellendefinition in SQL
Relationenalgebra: Anfrageoperatoren
Grundkonzepte von SQL-Anfragen und -Änderungen
Schallehn
Datenmanagement
Sommersemester 2017
2–39
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?
Schallehn
Datenmanagement
Sommersemester 2017
2–40
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?
Was definiert die Relationenalgebra?
Schallehn
Datenmanagement
Sommersemester 2017
2–40
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?
Was definiert die Relationenalgebra?
Wie wird eine Realweltobjekt in einer
relationalen Datenbank repräsentiert?
Schallehn
Datenmanagement
Sommersemester 2017
2–40
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?
Was definiert die Relationenalgebra?
Wie wird eine Realweltobjekt in einer
relationalen Datenbank repräsentiert?
Wie werden Tabellen in SQL definiert und
manipuliert?
Schallehn
Datenmanagement
Sommersemester 2017
2–40
Relationale Datenbanken – Daten als Tabellen
Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?
Was definiert die Relationenalgebra?
Wie wird eine Realweltobjekt in einer
relationalen Datenbank repräsentiert?
Wie werden Tabellen in SQL definiert und
manipuliert?
Was sind Integritätsbedingungen?
Schallehn
Datenmanagement
Sommersemester 2017
2–40
Teil III
Entity-Relationship-Modell
Entity-Relationship-Modell
Entity-Relationship-Modell
1
Datenbankmodelle
Schallehn
Datenmanagement
Sommersemester 2017
3–1
Entity-Relationship-Modell
Entity-Relationship-Modell
1
Datenbankmodelle
2
ER-Modell
Schallehn
Datenmanagement
Sommersemester 2017
3–1
Entity-Relationship-Modell
Entity-Relationship-Modell
1
Datenbankmodelle
2
ER-Modell
3
Weitere Konzepte im ER-Modell
Schallehn
Datenmanagement
Sommersemester 2017
3–1
Entity-Relationship-Modell
Datenbankmodelle
Grundlagen von Datenbankmodellen
Ein Datenbankmodell ist ein System von Konzepten zur
Beschreibung von Datenbanken. Es legt Syntax und Semantik von
Datenbankbeschreibungen für ein Datenbanksystem fest.
Datenbankbeschreibungen = Datenbankschemata
Schallehn
Datenmanagement
Sommersemester 2017
3–2
Entity-Relationship-Modell
Datenbankmodelle
Ein Datenbankmodell legt fest...
1
Statische Eigenschaften
1
2
2
inklusive der Standard-Datentypen, die Daten über die
Beziehungen und Objekte darstellen können,
Dynamische Eigenschaften wie
1
2
3
Objekte
Beziehungen
Operationen
Beziehungen zwischen Operationen,
Integritätsbedingungen an
1
2
Objekte
Operationen
Schallehn
Datenmanagement
Sommersemester 2017
3–3
Entity-Relationship-Modell
Datenbankmodelle
Datenbankmodelle
Klassische Datenbankmodelle sind speziell geeignet für
I
I
große Informationsmengen mit relativ einfacher und starrer Struktur
und
die Darstellung statischer Eigenschaften und
Integritätsbedingungen (also die Bereiche 1(a), 1(b) und 3(a))
Verschiedene Modelle für verschiedene Phasen (später
ausführlicher)
Modelle für den konzeptuellen Entwurf: ER-Modell, UML, . . .
Modell für den logischen Entwurf: Relationenmodell,
objektorientierte Modelle, . . .
Schallehn
Datenmanagement
Sommersemester 2017
3–4
Entity-Relationship-Modell
Datenbankmodelle
Einordnung: Phasenmodell des Datenbankentwurfs
Anforderungsanalyse
Konzeptioneller
Entwurf
Verteilungsentwurf
Logischer Entwurf
Datendefinition
Physischer Entwurf
Implementierung &
Wartung
Schallehn
Datenmanagement
Sommersemester 2017
3–5
Entity-Relationship-Modell
Datenbankmodelle
Datenbanken versus Programmiersprachen
Datenbankkonzept
Typsystem einer
Programmiersprache
Datenbankmodell
Typsystem
Relation, Attribut . . .
Datenbankschema
int, struct ...
Variablendeklaration
relation WEIN = (...)
Datenbank
var x: int, y: struct Wein
Werte
WEIN(4961, ’Chardonnay’, ’Weiß’, . . . )
42, ’Cabernet Sauvignon’
Schallehn
Datenmanagement
Sommersemester 2017
3–6
Entity-Relationship-Modell
Datenbankmodelle
Datenbankmodelle im Überblick
implementierungsnah
ab Mitte 1960
abstrakt
HM
NWM
1970
RM
ER
SQL
NF 2
1980
SDM
eNF2
1990
OODM
OEM
(C++)
ODMG
2000
Schallehn
ORM / SQL-99
Datenmanagement
Sommersemester 2017
3–7
Entity-Relationship-Modell
Datenbankmodelle
Datenbankmodelle im Überblick /2
HM: hierarchisches Modell, NWM: Netzwerkmodell, RM:
Relationenmodell
NF2 : Modell der geschachtelten (Non-First-Normal-Form = NF2 )
Relationen, eNF2 : erweitertes NF2 -Modell
ER: Entity-Relationship-Modell, SDM: semantische Datenmodelle
OODM / C++: objektorientierte Datenmodelle auf Basis
objektorientierter Programmiersprachen wie C++, OEM:
objektorientierte Entwurfsmodelle (etwa UML), ORDM:
objektrelationale Datenmodelle
Schallehn
Datenmanagement
Sommersemester 2017
3–8
Entity-Relationship-Modell
ER-Modell
Das Entity Relationship-Modell
Entity: Objekt der realen oder der Vorstellungswelt, über das
Informationen zu speichern sind, z.B. Produkte (Wein,
Katalog), Winzer oder Kritiker; aber auch Informationen
über Ereignisse, wie z.B. Bestellungen
Relationship: beschreibt eine Beziehung zwischen Entities, z.B. ein
Kunde bestellt einen Wein oder ein Wein wird von einem
Winzer angeboten
Attribut: repräsentiert eine Eigenschaft von Entities oder
Beziehungen, z.B. Name eines Kunden, Farbe eines
Weines oder Datum einer Bestellung
Schallehn
Datenmanagement
Sommersemester 2017
3–9
Entity-Relationship-Modell
Farbe
ER-Beispiel
ER-Modell
Name
Land
Bezeichnung
Region
Name
Rebsorte
[0,*]
Anbaugebiet
Beilage
Anteil
hergestellt
aus
Gericht
sitzt in
[0,*]
Name
Farbe
[1,7]
[0,*]
empfiehlt
Restsüße
[0,*]
produziert
von
Wein
Jahrgang
Erzeuger
Weingut
Kritiker
Adresse
besitzt
Name
LizenzNr
Organisation
Lizenz
Menge
Schallehn
Datenmanagement
Sommersemester 2017
3–10
Entity-Relationship-Modell
ER-Modell
Werte
Werte: primitive Datenelemente, die direkt darstellbar sind
Wertemengen sind beschrieben durch Datentypen, die neben
einer Wertemenge auch die Grundoperationen auf diesen Werten
charakterisieren
ER-Modell: vorgegebene Standard-Datentypen, etwa die ganzen
Zahlen int, die Zeichenketten string, Datumswerte date etc.
jeder Datentyp stellt Wertebereich mit Operationen und
Prädikaten dar
Schallehn
Datenmanagement
Sommersemester 2017
3–11
Entity-Relationship-Modell
ER-Modell
Entities und Entity Typen
Entities sind die in einer Datenbank zu repräsentierenden
Informationseinheiten
Im Gegensatz zu Werten nicht direkt darstellbar, sondern nur über
ihre Eigenschaften beobachtbar
Entities sind eingeteilt in Entity-Typen, etwa E1 , E2 . . .
Wein
In ER-Diagrammen werden Entity Typen dargestellt, keine
Entities!
Schallehn
Datenmanagement
Sommersemester 2017
3–12
Entity-Relationship-Modell
ER-Modell
Attribute
Attribute modellieren Eigenschaften von Entities oder auch
Beziehungen
alle Entities eines Entity-Typs haben dieselben Arten von
Eigenschaften; Attribute werden somit für Entity-Typen deklariert
Farbe
Name
Wein
Jahrgang
Textuelle Notation E(A1 : D1 , . . . , Am : Dm )
Schallehn
Datenmanagement
Sommersemester 2017
3–13
Entity-Relationship-Modell
ER-Modell
Identifizierung durch Schlüssel
Schlüsselattribute: Teilmenge der gesamten Attribute eines
Entity-Typs E(A1 , . . . , Am )
{S1 , . . . , Sk } ⊆ {A1 , . . . , Am }
In jedem Datenbankzustand identifizieren die aktuellen Werte der
Schlüsselattribute eindeutig Instanzen des Entity-Typs E
Bei mehreren möglichen Schlüsselkandidaten: Auswahl eines
Primärschlüssels
Notation: markieren durch Unterstreichung:
E(. . . , S1 , . . . , Si , . . .)
Schallehn
Datenmanagement
Sommersemester 2017
3–14
Entity-Relationship-Modell
ER-Modell
Beziehungstypen
Beziehungen zwischen Entities werden zu Beziehungstypen,
Relationship Types zusammengefasst
Allgemein: beliebige Anzahl n ≥ 2 von Entity-Typen kann an
einem Beziehungstyp teilhaben
Zu jedem n-stelligen Beziehungstyp R gehören n Entity-Typen
E1 , . . . , En
Schallehn
Datenmanagement
Sommersemester 2017
3–15
Entity-Relationship-Modell
ER-Modell
Beziehungstypen /2
Notation
Erzeuger
produziert
Wein
Textuelle Notation: R(E1 , E2 , . . . , En )
Wenn Entity-Typ mehrfach an einem Beziehungstyp beteiligt:
Vergabe von Rollennamen möglich
verheiratet(Frau: Person, Mann: Person)
Schallehn
Datenmanagement
Sommersemester 2017
3–16
Entity-Relationship-Modell
ER-Modell
Beziehungsattribute
Beziehungen können ebenfalls Attribute besitzen
Attributdeklarationen werden beim Beziehungstyp vorgenommen;
gilt auch hier für alle Ausprägungen eines Beziehungstyps
Beziehungsattribute
Anteil
Wein
hergestellt
aus
Rebsorte
Textuelle Notation: R(E1 , . . . , En ; A1 , . . . , Ak )
Schallehn
Datenmanagement
Sommersemester 2017
3–17
Entity-Relationship-Modell
ER-Modell
Merkmale von Beziehungen
Stelligkeit oder Grad:
I
I
I
Anzahl der beteiligten Entity-Typen
häufig: binär
Beispiel: Lieferant liefert Produkt
Kardinalität oder Funktionalität:
I
I
I
I
Anzahl der eingehenden Instanzen eines Entity-Typs
Formen: 1:1, 1:n, m:n
stellt Integritätsbedingung dar
Beispiel: maximal 5 Produkte pro Bestellung
Schallehn
Datenmanagement
Sommersemester 2017
3–18
Entity-Relationship-Modell
ER-Modell
Zwei- vs. mehrstellige Beziehungen
Gericht
empfiehlt
Wein
Kritiker
Schallehn
Datenmanagement
Sommersemester 2017
3–19
Entity-Relationship-Modell
ER-Modell
Zwei- vs. mehrstellige Beziehungen
Gericht
empfiehlt
Wein
Kritiker
Schallehn
Datenmanagement
Gericht
G-W
G-K
Wein
Kritiker
K-W
Sommersemester 2017
3–19
Entity-Relationship-Modell
ER-Modell
Ausprägungen im Beispiel
g1
w1
g2
w2
Gericht
Wein
k1
k2
Kritiker
Schallehn
Datenmanagement
Sommersemester 2017
3–20
Entity-Relationship-Modell
ER-Modell
Ausprägungen im Beispiel
g1
w1
g1
w1
g2
w2
g2
w2
Gericht
Wein
k1
k2
Wein
k1
Kritiker
Schallehn
Gericht
k2
Kritiker
Datenmanagement
Sommersemester 2017
3–20
Entity-Relationship-Modell
ER-Modell
Rekonstruktion der Ausprägungen
g1
w1
g2
w2
Gericht
Wein
k1
k2
Kritiker
Schallehn
Datenmanagement
Sommersemester 2017
3–21
Entity-Relationship-Modell
ER-Modell
Rekonstruktion der Ausprägungen
g1
w1
g2
w2
Gericht
g1 – k1 – w1
Wein
k1
k2
Kritiker
Schallehn
Datenmanagement
Sommersemester 2017
3–21
Entity-Relationship-Modell
ER-Modell
Rekonstruktion der Ausprägungen
g1
w1
g2
w2
g1 – k1 – w1
g1 – k2 – w2
Gericht
Wein
k1
k2
Kritiker
Schallehn
Datenmanagement
Sommersemester 2017
3–21
Entity-Relationship-Modell
ER-Modell
Rekonstruktion der Ausprägungen
g1
w1
g2
w2
g1 – k1 – w1
g1 – k2 – w2
g2 – k2 – w1
Gericht
Wein
k1
k2
Kritiker
Schallehn
Datenmanagement
Sommersemester 2017
3–21
Entity-Relationship-Modell
ER-Modell
Rekonstruktion der Ausprägungen
g1
w1
g2
w2
g1 – k1 – w1
g1 – k2 – w2
g2 – k2 – w1
Gericht
Wein
k1
aber auch: g1 – k2 – w1
k2
Kritiker
Schallehn
Datenmanagement
Sommersemester 2017
3–21
Entity-Relationship-Modell
ER-Modell
1:1-Beziehungen
jedem Entity e1 vom Entity-Typ E1 ist maximal ein Entity e2 aus E2
zugeordnet und umgekehrt
Beispiele: Prospekt beschreibt Produkt, Mann ist verheiratet mit
Frau
E1
Schallehn
E2
Datenmanagement
Sommersemester 2017
3–22
Entity-Relationship-Modell
ER-Modell
1:N-Beziehungen
jedem Entity e1 vom Entity-Typ E1 sind beliebig viele Entities E2
zugeordnet, aber zu jedem Entity e2 gibt es maximal ein e1 aus E1
Beispiele: Lieferant liefert Produkt, Mutter hat Kinder
E1
Schallehn
E2
Datenmanagement
Sommersemester 2017
3–23
Entity-Relationship-Modell
ER-Modell
N:1-Beziehung
invers zu 1:N, auch funktionale Beziehung
zweistellige Beziehungen, die eine Funktion beschreiben:
Jedem Entity eines Entity-Typs E1 wird maximal ein Entity eines
Entity-Typs E2 zugeordnet.
R : E1 → E2
Wein
Schallehn
produziert
von
Datenmanagement
Erzeuger
Sommersemester 2017
3–24
Entity-Relationship-Modell
ER-Modell
1:1-Beziehung
Erzeuger
Schallehn
besitzt
Datenmanagement
Lizenz
Sommersemester 2017
3–25
Entity-Relationship-Modell
ER-Modell
M:N-Beziehungen
keine Restriktionen
Beispiel: Bestellung umfasst Produkte
E1
Schallehn
E2
Datenmanagement
Sommersemester 2017
3–26
Entity-Relationship-Modell
ER-Modell
[min,max]-Notation
E1
[min1, max1]
R
[min2, max2]
[minn, maxn]
En
...
E2
schränkt die möglichen Teilnahmen von Instanzen der beteiligten
Entity-Typen an der Beziehung ein, indem ein minimaler und ein
maximaler Wert vorgegeben wird
Notation für Kardinalitätsangaben an einem Beziehungstyp
R(E1 , . . . , Ei [mini , maxi ], . . . , En )
Kardinalitätsbedingung: mini ≤ |{r | r ∈ R ∧ r .Ei = ei }| ≤ maxi
Spezielle Wertangabe für maxi ist ∗
Schallehn
Datenmanagement
Sommersemester 2017
3–27
Entity-Relationship-Modell
ER-Modell
Kardinalitätsangaben
[0, ∗] legt keine Einschränkung fest (default)
R(E1 [0, 1], E2 ) entspricht einer (partiellen) funktionalen Beziehung
R : E1 → E2 , da jede Instanz aus E1 maximal einer Instanz aus E2
zugeordnet ist
totale funktionale Beziehung wird durch R(E1 [1, 1], E2 ) modelliert
Schallehn
Datenmanagement
Sommersemester 2017
3–28
Entity-Relationship-Modell
ER-Modell
Kardinalitätsangaben: Beispiele
partielle funktionale Beziehung
lagert_in(Produkt[0,1],Fach[0,3])
„Jedes Produkt ist im Lager in einem Fach abgelegt, allerdings
wird ausverkauften bzw. gegenwärtig nicht lieferbaren Produkte
kein Fach zugeordnet. Pro Fach können maximal drei Produkte
gelagert werden.“
totale funktionale Beziehung
liefert(Lieferant[0,*],Produkt[1,1])
„Jedes Produkt wird durch genau einen Lieferant geliefert, aber
ein Lieferant kann durchaus mehrere Produkte liefern.“
Schallehn
Datenmanagement
Sommersemester 2017
3–29
Entity-Relationship-Modell
ER-Modell
Alternative Kardinalitätsangabe
[1,1]
Produkt
N
Produkt
Schallehn
geliefert
von
geliefert
von
Datenmanagement
[0,*]
Lieferant
1
Lieferant
Sommersemester 2017
3–30
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Abhängige Entity-Typen
abhängiger Entity-Typ: Identifikation über funktionale Beziehung
WeinJahrgang
gehört-zu
Jahr
Wein
Name
Restsüße
Farbe
Abhängige Entities im ER-Modell: Funktionale Beziehung als
Schlüssel
Schallehn
Datenmanagement
Sommersemester 2017
3–31
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Abhängige Entity-Typen /2
Mögliche Ausprägung für abhängige Entities
gehört-zu
Jahr: 2004
Restsüße: 1,2
Name: Pinot Noir
Farbe: Rot
gehört-zu
Jahr: 2003
Restsüße: 1,4
Name: Zinfandel
Farbe: Rot
gehört-zu
Jahr: 1999
Restsüße: 6,7
Schallehn
Name: Riesling Reserve
Farbe: Weiß
Datenmanagement
Sommersemester 2017
3–32
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Abhängige Entity-Typen /3
Alternative Notation
WeinJahrgang
N
gehört-zu
Jahr
Wein
Name
Restsüße
Schallehn
1
Farbe
Datenmanagement
Sommersemester 2017
3–33
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Die IST-Beziehung
Spezialisierungs-/Generalisierungsbeziehung oder auch ISTBeziehung (engl. is-a relationship)
textuelle Notation: E1 IST E2
IST-Beziehung
entspricht semantisch einer injektiven funktionalen
Beziehung
Herstellung
Schaumwein
Schallehn
Name
IST
Datenmanagement
Wein
Farbe
Sommersemester 2017
3–34
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Eigenschaften der IST-Beziehung
Jeder Schaumwein-Instanz ist genau eine Wein-Instanz
zugeordnet
Schaumwein-Instanzen werden durch die funktionale ISTBeziehung identifiziert
Nicht jeder Wein ist zugleich ein Schaumwein
Attribute des Entity-Typs Wein treffen auch auf Schaumweine zu:
„vererbte“ Attribute
Schaumwein(Name,Farbe,Herstellung)
|
{z
}
von Wein
nicht nur die Attributdeklarationen vererben sich, sondern auch
jeweils die aktuellen Werte für eine Instanz
Schallehn
Datenmanagement
Sommersemester 2017
3–35
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Ausprägung für IST-Beziehung
w1
w1
w2
w4
w2
w3
w4
w5
Schaumweine
w6
Weine
Schallehn
Datenmanagement
Sommersemester 2017
3–36
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Alternative Notation für IST-Beziehung
Herstellung
Name
Schaumwein
Schallehn
Farbe
Wein
Datenmanagement
Sommersemester 2017
3–37
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Kardinalitätsangaben: IST
für Beziehung E1 IST E2 gilt immer: IST(E1 [1, 1], E2 [0, 1])
Jede Instanz von E1 nimmt genau einmal an der IST-Beziehung
teil, während Instanzen des Obertyps E2 nicht teilnehmen müssen
Aspekte wie Attributvererbung werden hiervon nicht erfasst
Schallehn
Datenmanagement
Sommersemester 2017
3–38
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Optionalität von Attributen
Land
Weingut
Region
Adresse
Erzeuger
Schallehn
Name
sitzt in
Datenmanagement
Anbaugebiet
Sommersemester 2017
3–39
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Konzepte im Überblick
Begriff
Informale Bedeutung
Entity
Entity-Typ
Beziehungstyp
Attribut
zu repräsentierende Informationseinheit
Gruppierung von Entitys mit gleichen Eigenschaften
Gruppierung von Beziehungen zwischen Entitys
datenwertige Eigenschaft eines Entitys oder einer Beziehung
identifizierende Eigenschaft von Entitys
Einschränkung von Beziehungstypen bezüglich der mehrfachen Teilnahme von Entitys an der Beziehung
Anzahl der an einem Beziehungstyp beteiligten EntityTypen
Beziehungstyp mit Funktionseigenschaft
Entitys, die nur abhängig von anderen Entitys existieren
können
Spezialisierung von Entity-Typen
Attribute oder funktionale Beziehungen als partielle Funktionen
Schlüssel
Kardinalitäten
Stelligkeit
funktionale Beziehung
abhängige Entitys
IST-Beziehung
Optionalität
Schallehn
Datenmanagement
Sommersemester 2017
3–40
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Schallehn
Datenmanagement
Sommersemester 2017
3–41
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-Modell
Schallehn
Datenmanagement
Sommersemester 2017
3–41
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Schallehn
Datenmanagement
Sommersemester 2017
3–41
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Basis: Kapitel 3 von [SSH10]
Schallehn
Datenmanagement
Sommersemester 2017
3–41
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Was
unterscheidet Modell und Schema?
Schallehn
Datenmanagement
Sommersemester 2017
3–42
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Was
unterscheidet Modell und Schema?
Welche Konzepte definiert das
ER-Modell?
Schallehn
Datenmanagement
Sommersemester 2017
3–42
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Was
unterscheidet Modell und Schema?
Welche Konzepte definiert das
ER-Modell?
Durch welche Eigenschaften sind
Beziehungstypen charakterisiert?
Schallehn
Datenmanagement
Sommersemester 2017
3–42
Entity-Relationship-Modell
Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Was
unterscheidet Modell und Schema?
Welche Konzepte definiert das
ER-Modell?
Durch welche Eigenschaften sind
Beziehungstypen charakterisiert?
Was unterscheidet abhängige
Entity-Typen von normalen Entity-Typen?
Schallehn
Datenmanagement
Sommersemester 2017
3–42
Teil IV
Datenbankentwurf
Datenbankentwurf
Datenbankentwurf
1
Phasen des Datenbankentwurfs
Schallehn
Datenmanagement
Sommersemester 2017
4–1
Datenbankentwurf
Datenbankentwurf
1
Phasen des Datenbankentwurfs
2
Weiteres Vorgehen beim Entwurf
Schallehn
Datenmanagement
Sommersemester 2017
4–1
Datenbankentwurf
Datenbankentwurf
1
Phasen des Datenbankentwurfs
2
Weiteres Vorgehen beim Entwurf
3
Kapazitätserhaltende Abbildungen
Schallehn
Datenmanagement
Sommersemester 2017
4–1
Datenbankentwurf
Datenbankentwurf
1
Phasen des Datenbankentwurfs
2
Weiteres Vorgehen beim Entwurf
3
Kapazitätserhaltende Abbildungen
4
ER-auf-RM-Abbildung
Schallehn
Datenmanagement
Sommersemester 2017
4–1
Datenbankentwurf
Phasen des Datenbankentwurfs
Entwurfsaufgabe
Datenhaltung für mehrere Anwendungssysteme und mehrere
Jahre
daher: besondere Bedeutung
Anforderungen an Entwurf
I
I
I
Anwendungsdaten jeder Anwendung sollen aus Daten der
Datenbank ableitbar sein (und zwar möglichst effizient)
nur „vernünftige“ (wirklich benötigte) Daten sollen gespeichert
werden
nicht-redundante Speicherung
Schallehn
Datenmanagement
Sommersemester 2017
4–2
Datenbankentwurf
Phasen des Datenbankentwurfs
Phasenmodell
Anforderungsanalyse
Konzeptioneller
Entwurf
Verteilungsentwurf
Logischer Entwurf
Datendefinition
Physischer Entwurf
Implementierung &
Wartung
Schallehn
Datenmanagement
Sommersemester 2017
4–3
Datenbankentwurf
Phasen des Datenbankentwurfs
Anforderungsanalyse
Vorgehensweise: Sammlung des Informationsbedarfs in den
Fachabteilungen
Ergebnis:
I
I
informale Beschreibung (Texte, tabellarische Aufstellungen,
Formblätter, usw.) des Fachproblems
Trennen der Information über Daten (Datenanalyse) von den
Information über Funktionen (Funktionsanalyse)
„Klassischer“ DB-Entwurf:
I
nur Datenanalyse und Folgeschritte
Funktionsentwurf:
I
siehe Methoden des Software Engineering
Schallehn
Datenmanagement
Sommersemester 2017
4–4
Datenbankentwurf
Phasen des Datenbankentwurfs
Konzeptioneller Entwurf
erste formale Beschreibung des Fachproblems
Sprachmittel: semantisches Datenmodell
Vorgehensweise:
I
I
I
Modellierung von Sichten z.B. für verschiedene Fachabteilungen
Analyse der vorliegenden Sichten in Bezug auf Konflikte
Integration der Sichten in ein Gesamtschema
Ergebnis: konzeptionelles Gesamtschema, z.B. ER-Diagramm
Schallehn
Datenmanagement
Sommersemester 2017
4–5
Datenbankentwurf
Phasen des Datenbankentwurfs
Phasen des konzeptionellen Entwurf
konzeptioneller
Entwurf
Sichtenentwurf
Sichtenanalyse
Sichtenintegration
Schallehn
Datenmanagement
Sommersemester 2017
4–6
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Weiteres Vorgehen beim Entwurf
ER-Modellierung von verschiedenen Sichten auf
Gesamtinformation, z.B. für verschiedene Fachabteilungen eines
Unternehmens
konzeptueller Entwurf
I
I
Analyse und Integration der Sichten
Ergebnis: konzeptionelles Gesamtschema
Verteilungsentwurf bei verteilter Speicherung
Abbildung auf konkretes Implementierungsmodell (z.B.
Relationenmodell)
logischer Entwurf
Datendefinition, Implementierung und Wartung
Entwurf
Schallehn
Datenmanagement
physischer
Sommersemester 2017
4–7
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Sichtenintegration
Analyse der vorliegenden Sichten in Bezug auf Konflikte
Integration der Sichten in ein Gesamtschema
Sicht #2
Sicht #1
Konsolidierung
Globales
Schema
Sicht #3
Schallehn
Datenmanagement
Sommersemester 2017
4–8
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Integrationskonflikte
Namenskonflikte: Homonyme / Synonyme
I
I
Homonyme: Schloss; Kunde
Synonyme: Auto, KFZ, Fahrzeug
Typkonflikte: verschiedene Strukturen für das gleiche Element
Wertebereichskonflikte: verschiedene Wertebereiche für ein
Element
Bedingungskonflikte: z.B. verschiedene Schlüssel für ein
Element
Strukturkonflikte: gleicher Sachverhalt durch unterschiedliche
Konstrukte ausgedrückt
Schallehn
Datenmanagement
Sommersemester 2017
4–9
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Logischer Entwurf
Sprachmittel: Datenmodell des ausgewählten
„Realisierungs“-DBMS z.B. relationales Modell
Vorgehensweise:
1
2
(automatische) Transformation des konzeptionellen Schemas z.B.
ER → relationales Modell
Verbesserung des relationalen Schemas anhand von Gütekriterien
(Normalisierung, siehe Kapitel 5):
Entwurfsziele: Redundanzvermeidung, . . .
Ergebnis: logisches Schema, z.B. Sammlung von
Relationenschemata
Schallehn
Datenmanagement
Sommersemester 2017
4–10
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Datendefinition
Umsetzung des logischen Schemas in ein konkretes Schema
Sprachmittel: DDL und DML eines DBMS z.B. Oracle, DB2, SQL
Server
I
I
I
Datenbankdeklaration in der DDL des DBMS
Realisierung der Integritätssicherung
Definition der Benutzersichten
Schallehn
Datenmanagement
Sommersemester 2017
4–11
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Physischer Entwurf
Ergänzen des physischen Entwurfs um Zugriffsunterstützung bzgl.
Effizienzverbesserung, z.B. Definition von Indexen
Index
I
I
Zugriffspfad: Datenstruktur für zusätzlichen, schlüsselbasierten
Zugriff auf Tupel (hSchlüsselattributwert, Tupeladressei)
meist als B*-Baum realisiert
Sprachmittel: Speicherstruktursprache SSL
Schallehn
Datenmanagement
Sommersemester 2017
4–12
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Indexe in SQL
create [ unique ] index indexname
on relname (
attrname [ asc | desc ],
attrname [ asc | desc ],
...
)
Beispiel
create index WeinIdx on WEINE (Name)
Schallehn
Datenmanagement
Sommersemester 2017
4–13
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Notwendigkeit für Zugriffspfade
Beispiel: Tabelle mit 100 GB Daten, Festplattentransferrate ca. 50
MB/s
Operation: Suchen eines Tupels (Selektion)
Implementierung: sequentielles Durchsuchen
Aufwand: 102.400/50 = 2.048 sec. ≈ 34 min.
Schallehn
Datenmanagement
Sommersemester 2017
4–14
Datenbankentwurf
Weiteres Vorgehen beim Entwurf
Implementierung und Wartung
Phasen
I
I
I
I
I
der Wartung,
der weiteren Optimierung der physischen Ebene,
der Anpassung an neue Anforderungen und Systemplattformen,
der Portierung auf neue Datenbankmanagementsysteme
etc.
Schallehn
Datenmanagement
Sommersemester 2017
4–15
Datenbankentwurf
Kapazitätserhaltende Abbildungen
Umsetzung des konzeptionellen Schemas
Umsetzung auf logisches Schema
I
I
I
Beispiel: ER → RM
korrekt?
Qualität der Abbildung?
Erhaltung der Informationskapazität
I
I
I
Kann man nach der Abbildung genau die selben Daten
abspeichern wie vorher?
... oder etwa mehr?
... oder etwa weniger?
Schallehn
Datenmanagement
Sommersemester 2017
4–16
Datenbankentwurf
Kapazitätserhaltende Abbildungen
Kapazitätserhöhende Abbildung
Lizenz
besitzt
Erzeuger
LizenzNo
Weingut
Abbildung auf
R = {LizenzNo, Weingut}
mit genau einem Schlüssel
K = {{LizenzNo}}
mögliche ungültige Relation:
BESITZT LizenzNo
007
42
Schallehn
Datenmanagement
Weingut
Helena
Helena
Sommersemester 2017
4–17
Datenbankentwurf
Kapazitätserhaltende Abbildungen
Kapazitätserhaltende Abbildung
Lizenz
besitzt
Erzeuger
LizenzNo
Weingut
korrekte Ausprägung
BESITZT LizenzNo
007
42
Weingut
Helena
Müller
korrekte Schlüsselmenge
K = {{LizenzNo}, {Weingut}}
Schallehn
Datenmanagement
Sommersemester 2017
4–18
Datenbankentwurf
Kapazitätserhaltende Abbildungen
Kapazitätsvermindernde Abbildung
Wein
enthält
Rebsorte
WName
Sortenname
Relationenschema mit einem Schlüssel {WName}
als Ausprägung nicht mehr möglich:
ENTHÄLT WName
Zinfandel Red Blossom
Bordeaux Blanc
Bordeaux Blanc
Sortenname
Zinfandel
Cabernet Sauvignon
Muscadelle
kapazitätserhaltend mit Schlüssel beider Entity-Typen im
Relationenschema als neuer Schlüssel
K = {{WName, Sortenname}}
Schallehn
Datenmanagement
Sommersemester 2017
4–19
Datenbankentwurf
ER-auf-RM-Abbildung
Beispielabbildung ER-RM: Eingabe
Anteil
Rebsorte
Farbe
WName
enthält
Wein
Sortenname
Erzeuger
Farbe
produziert
Jahrgang
Restsüße
Weingut
Schallehn
Adresse
Datenmanagement
Sommersemester 2017
4–20
Datenbankentwurf
ER-auf-RM-Abbildung
Beispielabbildung ER-RM: Ergebnis
1
2
3
4
5
REBSORTE = {Farbe, Sortenname} mit
KREBSORTE = {{Sortenname}}
ENTHÄLT = {Sortenname, WName, Anteil} mit
KENTHÄLT = {{Sortenname, WName}}
WEIN = {Farbe, WName, Jahrgang, Restsüße} mit
KWEIN = {{WName}}
PRODUZIERT = {WName, Weingut} mit
KPRODUZIERT = {{WName}}
ERZEUGER = {Weingut, Adresse} mit
KERZEUGER = {{Weingut}}
Schallehn
Datenmanagement
Sommersemester 2017
4–21
Datenbankentwurf
ER-auf-RM-Abbildung
ER-Abbildung auf Relationen
Entity-Typen und Beziehungstypen: jeweils auf
Relationenschemata
Attribute: Attribute des Relationenschemas, Schlüssel werden
übernommen
Kardinalitäten der Beziehungen: durch Wahl der Schlüssel bei
den zugehörigen Relationenschemata ausgedrückt
in einigen Fällen: Verschmelzen der Relationenschemata von
Entity- und Beziehungstypen
zwischen den verbleibenden Relationenschemata diverse
Fremdschlüsselbedingungen einführen
Schallehn
Datenmanagement
Sommersemester 2017
4–22
Datenbankentwurf
ER-auf-RM-Abbildung
Abbildung von Beziehungstypen
neues Relationenschema mit allen Attributen des Beziehungstyps,
zusätzlich Übernahme aller Primärschlüssel der beteiligten EntityTypen
Festlegung der Schlüssel:
I
I
I
m:n-Beziehung: beide Primärschlüssel zusammen werden
Schlüssel im neuen Relationenschema
1:n-Beziehung: Primärschlüssel der n-Seite (bei der funktionalen
Notation die Seite ohne Pfeilspitze) wird Schlüssel im neuen
Relationenschema
1:1-Beziehung: beide Primärschlüssel werden je ein Schlüssel im
neuen Relationenschema, der Primärschlüssel wird dann aus
diesen Schlüsseln gewählt
Schallehn
Datenmanagement
Sommersemester 2017
4–23
Datenbankentwurf
ER-auf-RM-Abbildung
n:m-Beziehungen
WName
Farbe
Wein
Restsüße
Anteil
enthält
Jahrgang
Rebsorte
Sortenname
Farbe
Umsetzung
1
2
3
REBSORTE = {Farbe, Sortenname} mit
KREBSORTE = {{Sortenname}}
ENTHÄLT = {Sortenname, WName, Anteil} mit
KENTHÄLT = {{Sortenname, WName}}
WEIN = {Farbe, WName, Jahrgang, Restsüße} mit
KWEIN = {{WName}}
Attribute Sortenname und WName sind gemeinsam Schlüssel
Schallehn
Datenmanagement
Sommersemester 2017
4–24
Datenbankentwurf
ER-auf-RM-Abbildung
1:n-Beziehungen
sitzt in
Erzeuger
Weingut
Adresse
Anbaugebiet
Name
Region
Umsetzung (zunächst)
I
I
I
ERZEUGER mit den Attributen Weingut und Adresse,
ANBAUGEBIET mit den Attributen Name und Region und
SITZT_IN mit den Attributen Weingut und Name und dem
Primärschlüssel der n-Seite Weingut als Primärschlüssel dieses
Schemas.
Schallehn
Datenmanagement
Sommersemester 2017
4–25
Datenbankentwurf
ER-auf-RM-Abbildung
Mögliche Verschmelzungen
optionale Beziehungen ([0,1] oder [0,n]) werden nicht
verschmolzen
bei Kardinalitäten [1,1] oder [1,n] (zwingende Beziehungen)
Verschmelzung möglich:
I
I
1:n-Beziehung: das Entity-Relationenschema der n-Seite kann in
das Relationenschema der Beziehung integriert werden
1:1-Beziehung: beide Entity-Relationenschemata können in das
Relationenschema der Beziehung integriert werden
Schallehn
Datenmanagement
Sommersemester 2017
4–26
Datenbankentwurf
ER-auf-RM-Abbildung
1:1-Beziehungen
Lizenz
LizenzNo
Erzeuger
besitzt
HektoLiter
Weingut
Adresse
Umsetzung (zunächst)
I
I
I
ERZEUGER mit den Attributen Weingut und Adresse
LIZENZ mit den beiden Attributen LizenzNo und Hektoliter
BESITZT mit den Primärschlüsseln der beiden beteiligten EntityTypen jeweils als Schlüssel dieses Schemas, also LizenzNo und
Weingut
Schallehn
Datenmanagement
Sommersemester 2017
4–27
Datenbankentwurf
ER-auf-RM-Abbildung
1:1-Beziehungen: Verschmelzung
Umsetzung mit Verschmelzung
I
I
I
verschmolzene Relation:
ERZEUGER
Weingut
Adresse LizenzNo
Rotkäppchen
Freiberg
42-007
Weingut Müller Dagstuhl 42-009
Erzeuger ohne Lizenz erfordern Nullwerte:
ERZEUGER
Weingut
Adresse LizenzNo
Rotkäppchen
Freiberg
42-007
Weingut Müller Dagstuhl ⊥
freie Lizenzen führen zu weiteren Nullwerten:
ERZEUGER
Weingut
Adresse LizenzNo
Rotkäppchen
Freiberg
42-007
Weingut Müller Dagstuhl ⊥
⊥
⊥
42-003
Schallehn
Datenmanagement
Hektoliter
10.000
250
Hektoliter
10.000
⊥
Hektoliter
10.000
⊥
100.000
Sommersemester 2017
4–28
Datenbankentwurf
ER-auf-RM-Abbildung
Abhängige Entity-Typen
WeinJahrgang
Restsüße
N
gehört-zu
Jahr
Wein
1
WName
Farbe
Umsetzung
WEINJAHRGANG = {WName, Restsüße, Jahr} mit
KWEINJAHRGANG = {{WName, Jahr}}
WEIN = {Farbe, WName} mit KWEIN = {{WName}}
1
2
I
Attribut WName in WEINJAHRGANG ist Fremdschlüssel zur Relation
WEIN
Schallehn
Datenmanagement
Sommersemester 2017
4–29
Datenbankentwurf
ER-auf-RM-Abbildung
IST-Beziehung
Herstellung
WName
Schaumwein
Farbe
Wein
Umsetzung
WEIN = {Farbe, WName, Jahrgang, Restsüße} mit
KWEIN = {{WName}}
SCHAUMWEIN = {WName, Herstellung} mit
KSCHAUMWEIN = {{WName}}
1
2
I
WName in SCHAUMWEIN ist Fremdschlüssel bezüglich der Relation
WEIN
Schallehn
Datenmanagement
Sommersemester 2017
4–30
Datenbankentwurf
ER-auf-RM-Abbildung
Rekursive Beziehungen
Name
nach
Anbaugebiet
grenzt-an
von
Region
Umsetzung
1
2
ANBAUGEBIET = {Name, Region} mit
KANBAUGEBIET = {{Name}}
GRENZT_AN = {nach, von} mit KGRENZT_AN = {{nach, von}}
Schallehn
Datenmanagement
Sommersemester 2017
4–31
Datenbankentwurf
ER-auf-RM-Abbildung
Rekursive funktionale Beziehungen
Name
Mentor
Kritiker
Organisation
SchülerVon
Schüler
Umsetzung
1
KRITIKER = {Name, Organisation, Mentorname} mit
KKRITIKER = {{Name}}
I
Mentorname ist Fremdschlüssel auf das Attribut Name der Relation
KRITIKER.
Schallehn
Datenmanagement
Sommersemester 2017
4–32
Datenbankentwurf
ER-auf-RM-Abbildung
Mehrstellige Beziehungen
Bezeichnung
Beilage
WName
Gericht
empfiehlt
Farbe
Wein
Restsüße
Jahrgang
Kritiker
Name
Organisation
jeder beteiligte Entity-Typ wird nach den obigen Regeln behandelt
für Beziehung Empfiehlt werden Primärschlüssel der drei beteiligten EntityTypen in das resultierende Relationenschema aufgenommen
Beziehung ist allgemeiner Art (k:m:n-Beziehung): alle Primärschlüssel bilden
zusammen den Schlüssel
Schallehn
Datenmanagement
Sommersemester 2017
4–33
Datenbankentwurf
ER-auf-RM-Abbildung
Mehrstellige Beziehungen: Ergebnis
1
2
3
4
EMPFIEHLT = {WName, Bezeichnung, Name} mit
KEMPFIEHLT = {{WName, Bezeichnung, Name}}
GERICHT = {Bezeichnung, Beilage} mit
KGERICHT = {{Bezeichnung}}
WEIN = {Farbe, WName, Jahrgang, Restsüße} mit
KWEIN = {{WName}}
KRITIKER = {Name, Organisation} mit
KKRITIKER = {{Name}}
Die drei Schlüsselattribute von EMPFIEHLT sind Fremdschlüssel
für die jeweiligen Ursprungsrelationen.
Schallehn
Datenmanagement
Sommersemester 2017
4–34
Datenbankentwurf
ER-auf-RM-Abbildung
Übersicht über die Transformationen
ER-Konzept
wird abgebildet auf relationales Konzept
Entity-Typ Ei
Attribute von Ei
Primärschlüssel Pi
Beziehungstyp
Relationenschema Ri
Attribute von Ri
Primärschlüssel Pi
Relationenschema
Attribute: P1 , P2
weitere Attribute
P2 wird Primärschlüssel der Beziehung
P1 und P2 werden Schlüssel der Beziehung
P1 ∪ P2 wird Primärschlüssel der Beziehung
R1 erhält zusätzlichen Schlüssel P2
dessen Attribute
1:n
1:1
m:n
IST-Beziehung
E1 , E2 : an Beziehung beteiligte Entity-Typen,
P1 , P2 : deren Primärschlüssel,
1 : n-Beziehung: E2 ist n-Seite,
IST-Beziehung:
Schallehn
E1 ist speziellerer Entity-Typ
Datenmanagement
Sommersemester 2017
4–35
Datenbankentwurf
ER-auf-RM-Abbildung
Zusammenfassung
Phasen des Datenbankentwurfs
Schallehn
Datenmanagement
Sommersemester 2017
4–36
Datenbankentwurf
ER-auf-RM-Abbildung
Zusammenfassung
Phasen des Datenbankentwurfs
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Schallehn
Datenmanagement
Sommersemester 2017
4–36
Datenbankentwurf
ER-auf-RM-Abbildung
Zusammenfassung
Phasen des Datenbankentwurfs
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-Modell
Schallehn
Datenmanagement
Sommersemester 2017
4–36
Datenbankentwurf
ER-auf-RM-Abbildung
Zusammenfassung
Phasen des Datenbankentwurfs
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-Modell
ER-Erweiterungen: Spezialisierung, Generalisierung,
Partitionierung
Schallehn
Datenmanagement
Sommersemester 2017
4–36
Datenbankentwurf
ER-auf-RM-Abbildung
Zusammenfassung
Phasen des Datenbankentwurfs
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-Modell
ER-Erweiterungen: Spezialisierung, Generalisierung,
Partitionierung
weitere Entwurfsschritte
Schallehn
Datenmanagement
Sommersemester 2017
4–36
Datenbankentwurf
ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst der
Datenbankentwurfsprozess?
Schallehn
Datenmanagement
Sommersemester 2017
4–37
Datenbankentwurf
ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst der
Datenbankentwurfsprozess?
Welche Forderungen müssen die
Abbildungen (Transformationen) zwischen
den einzelnen Entwurfsschritten erfüllen?
Warum?
Schallehn
Datenmanagement
Sommersemester 2017
4–37
Datenbankentwurf
ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst der
Datenbankentwurfsprozess?
Welche Forderungen müssen die
Abbildungen (Transformationen) zwischen
den einzelnen Entwurfsschritten erfüllen?
Warum?
Wie werden die Konzepte des ER-Modells
auf die des Relationenmodell abgebildet?
Schallehn
Datenmanagement
Sommersemester 2017
4–37
Datenbankentwurf
ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst der
Datenbankentwurfsprozess?
Welche Forderungen müssen die
Abbildungen (Transformationen) zwischen
den einzelnen Entwurfsschritten erfüllen?
Warum?
Wie werden die Konzepte des ER-Modells
auf die des Relationenmodell abgebildet?
Wie werden die verschiedenen
Kardinalitäten von Beziehungstypen bei
der Abbildung berücksichtigt?
Schallehn
Datenmanagement
Sommersemester 2017
4–37
Teil V
Relationale Entwurfstheorie
Relationale Entwurfstheorie
Relationale Entwurfstheorie
1
Zielmodell des logischen Entwurfs
Schallehn
Datenmanagement
Sommersemester 2017
5–1
Relationale Entwurfstheorie
Relationale Entwurfstheorie
1
Zielmodell des logischen Entwurfs
2
Relationaler DB-Entwurf
Schallehn
Datenmanagement
Sommersemester 2017
5–1
Relationale Entwurfstheorie
Relationale Entwurfstheorie
1
Zielmodell des logischen Entwurfs
2
Relationaler DB-Entwurf
3
Normalformen
Schallehn
Datenmanagement
Sommersemester 2017
5–1
Relationale Entwurfstheorie
Relationale Entwurfstheorie
1
Zielmodell des logischen Entwurfs
2
Relationaler DB-Entwurf
3
Normalformen
4
Transformationseigenschaften
Schallehn
Datenmanagement
Sommersemester 2017
5–1
Relationale Entwurfstheorie
Relationale Entwurfstheorie
1
Zielmodell des logischen Entwurfs
2
Relationaler DB-Entwurf
3
Normalformen
4
Transformationseigenschaften
5
Entwurfsverfahren
Schallehn
Datenmanagement
Sommersemester 2017
5–1
Relationale Entwurfstheorie
Relationale Entwurfstheorie
1
Zielmodell des logischen Entwurfs
2
Relationaler DB-Entwurf
3
Normalformen
4
Transformationseigenschaften
5
Entwurfsverfahren
6
Weitere Abhängigkeiten
Schallehn
Datenmanagement
Sommersemester 2017
5–1
Relationale Entwurfstheorie
Zielmodell des logischen Entwurfs
Relationenmodell
WEINE
WeinID
1042
2168
3456
2171
3478
4711
4961
Name
Farbe
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
Rot
Rot
Rot
Rot
Rot
Weiß
Weiß
ERZEUGER Weingut
Creek
Helena
Château La Rose
Château La Pointe
Müller
Bighorn
Schallehn
Jahrgang
1998
2003
2004
2001
1999
1999
2002
Weingut
Château La Rose
Creek
Helena
Creek
Helena
Müller
Bighorn
Anbaugebiet
Region
Barossa Valley
Napa Valley
Saint-Emilion
Pomerol
Rheingau
Napa Valley
South Australia
Kalifornien
Bordeaux
Bordeaux
Hessen
Kalifornien
Datenmanagement
Sommersemester 2017
5–2
Relationale Entwurfstheorie
Zielmodell des logischen Entwurfs
Begriffe des Relationenmodells
Begriff
Attribut
Wertebereich
Attributwert
Relationenschema
Relation
Tupel
Datenbankschema
Datenbank
Schallehn
Informale Bedeutung
Spalte einer Tabelle
mögliche Werte eines Attributs (auch Domäne)
Element eines Wertebereichs
Menge von Attributen
Menge von Zeilen einer Tabelle
Zeile einer Tabelle
Menge von Relationenschemata
Menge von Relationen (Basisrelationen)
Datenmanagement
Sommersemester 2017
5–3
Relationale Entwurfstheorie
Zielmodell des logischen Entwurfs
Begriffe des Relationenmodells /2
Begriff
Schlüssel
Primärschlüssel
Fremdschlüssel
Fremdschlüsselbedingung
Schallehn
Informale Bedeutung
minimale Menge von Attributen, deren
Werte ein Tupel einer Tabelle eindeutig
identifizieren
ein beim Datenbankentwurf ausgezeichneter Schlüssel
Attributmenge, die in einer anderen
Relation Schlüssel ist
alle Attributwerte des Fremdschlüssels
tauchen in der anderen Relation als
Werte des Schlüssels auf
Datenmanagement
Sommersemester 2017
5–4
Relationale Entwurfstheorie
Zielmodell des logischen Entwurfs
Formalisierung Relationenmodell
Attribute und Domänen
I
I
I
I
I
U nichtleere, endliche Menge: Universum
A ∈ U: Attribut
D = {D1 , . . . , Dm } Menge endlicher, nichtleerer Mengen: jedes Di :
Wertebereich oder Domäne
total definierte Funktion dom : U −→ D
dom(A): Domäne von A
w ∈ dom(A): Attributwert für A
Schallehn
Datenmanagement
Sommersemester 2017
5–5
Relationale Entwurfstheorie
Zielmodell des logischen Entwurfs
Formalisierung Relationenmodell /2
Relationenschemata und Relationen
I
I
I
I
I
R ⊆ U: Relationenschema
Relation r über R = {A1 , . .S
. , An } (kurz: r (R)) ist endliche Menge
m
von Abbildungen t : R −→ i=1 Di , Tupel genannt
Es gilt t(A) ∈ dom(A) (t(A) Restriktion von t auf A ∈ R)
für X ⊆ R analog t(X ) X-Wert von t
Menge aller Relationen über R: REL(R) := {r | r (R)}
Schallehn
Datenmanagement
Sommersemester 2017
5–6
Relationale Entwurfstheorie
Zielmodell des logischen Entwurfs
Formalisierung Relationenmodell /3
Datenbankschema und Datenbank
I
I
I
I
Menge von Relationenschemata S := {R1 , . . . , Rp }:
Datenbankschema
Datenbank über S: Menge von Relationen d := {r1 , . . . , rp }, wobei
ri (Ri )
Datenbank d über S: d(S)
Relation r ∈ d: Basisrelation
Schallehn
Datenmanagement
Sommersemester 2017
5–7
Relationale Entwurfstheorie
Zielmodell des logischen Entwurfs
Integritätsbedingungen
Identifizierende Attributmenge K := {B1 , . . . , Bk } ⊆ R:
∀t1 , t2 ∈ r [t1 6= t2
=⇒
∃B ∈ K : t1 (B) 6= t2 (B)]
Schlüssel: ist minimale identifizierende Attributmenge
I
I
{Name, Jahrgang, Weingut} und
{WeinID} für WEINE
Primattribut: Element eines Schlüssels
Primärschlüssel: ausgezeichneter Schlüssel
Oberschlüssel oder Superkey: jede Obermenge eines Schlüssels
(= identifizierende Attributmenge)
Fremdschlüssel: X (R1 ) → Y (R2 )
{t(X )|t ∈ r1 } ⊆ {t(Y )|t ∈ r2 }
Schallehn
Datenmanagement
Sommersemester 2017
5–8
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Relationaler DB-Entwurf: Überblick
Verfeinern des logischen Entwurfs
Ziel: Vermeidung von Redundanzen durch Aufspalten von
Relationenschemata, ohne gleichzeitig
I
I
semantische Informationen zu verlieren (Abhängigkeitstreue)
die Möglichkeit zur Rekonstruktion der Relationen zu verlieren
(Verbundtreue)
Redundanzvermeidung durch Normalformen (s.u.)
Schallehn
Datenmanagement
Sommersemester 2017
5–9
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Relation mit Redundanzen
WEINE
WeinID
1042
2168
3456
2171
3478
4711
4961
Name
...
Weingut
Anbaugebiet
Region
La Rose Gr. Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Res.
Chardonnay
...
...
...
...
...
...
...
Ch. La Rose
Creek
Helena
Creek
Helena
Müller
Bighorn
Saint-Emilion
Barossa Valley
Napa Valley
Barossa Valley
Napa Valley
Rheingau
Napa Valley
Bordeaux
South Australia
Kalifornien
South Australia
Kalifornien
Hessen
Kalifornien
Schallehn
Datenmanagement
Sommersemester 2017
5–10
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Redundanzen
Redundanzen in Basisrelationen aus mehreren Gründen
unerwünscht:
I
I
Redundante Informationen belegen unnötigen Speicherplatz
Änderungsoperationen auf Basisrelationen mit Redundanzen nur
schwer korrekt umsetzbar: wenn eine Information redundant
vorkommt, muss eine Änderung diese Information in allen ihren
Vorkommen verändern
F
Schallehn
mit normalen relationalen Änderungsoperationen und den in
relationalen Systemen vorkommenden lokalen
Integritätsbedingungen (Schlüsseln) nur schwer realisierbar
Datenmanagement
Sommersemester 2017
5–11
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Änderungsanomalien
Einfügen in die mit Redundanzen behaftete WEINE-Relation:
insert into WEINE (WeinID, Name, Farbe, Jahrgang,
Weingut, Anbaugebiet, Region)
values (4711, ’Chardonnay’, ’Weiß’, 2004,
’Helena’, ’Rheingau’, ’Kalifornien’)
I
I
I
WeinID 4711 bereits anderem Wein zugeordnet: verletzt FD
WeinID → Name
Weingut Helena war bisher im Napa Valley angesiedelt: verletzt FD
Weingut → Anbaugebiet
Rheingau liegt nicht in Kalifornien: verletzt FD
Anbaugebiet → Region
auch update- und delete-Anomalien
Schallehn
Datenmanagement
Sommersemester 2017
5–12
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Funktionale Abhängigkeiten
funktionale Abhängigkeit zwischen Attributmengen X und Y einer
Relation
Wenn in jedem Tupel der Relation der Attributwert unter den X Komponenten den Attributwert unter den Y -Komponenten festlegt.
Unterscheiden sich zwei Tupel in den X -Attributen nicht, so haben
sie auch gleiche Werte für alle Y -Attribute
Notation für funktionale Abhängigkeit (FD, von functional
dependency): X → Y
Beispiel:
WeinID
→ Name, Weingut
Anbaugebiet → Region
aber nicht: Weingut → Name
Schallehn
Datenmanagement
Sommersemester 2017
5–13
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Schlüssel als Spezialfall
für Beispiel auf Folie 5-10
WeinID → Name, Farbe, Jahrgang, Weingut, Anbaugebiet, Re
Immer: WeinID → WeinID,
dann gesamtes Schema auf rechter Seite
Wenn linke Seite minimal: Schlüssel
Formal: Schlüssel X liegt vor, wenn für Relationenschema R FD
X → R gilt und X minimal
Ziel des Datenbankentwurfs: alle gegebenen funktionalen
Abhängigkeiten in „Schlüsselabhängigkeiten“ umformen, ohne dabei
semantische Information zu verlieren
Schallehn
Datenmanagement
Sommersemester 2017
5–14
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Ableitung von FDs
r A
a1
a2
a3
a4
B
b1
b1
b2
b1
C
c1
c1
c1
c1
genügt A → B und B → C
dann gilt auch A → C
nicht ableitbar C → A oder C → B
Schallehn
Datenmanagement
Sommersemester 2017
5–15
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Ableitung von FDs /2
Gilt für f über R SATR (F ) ⊆ SATR (f ), dann impliziert F die FD f
(kurz: F |= f )
obiges Beispiel:
F = {A → B, B → C} |= A → C
Hüllenbildung: Ermittlung aller funktionalen Abhängigkeiten, die
aus einer gegebenen FD-Menge abgeleitet werden können
Hülle FR+ := {f | (f FD über R) ∧ F |= f }
Beispiel:
{A → B, B → C}+ = {A → B, B → C, A → C, AB → C, A → BC, . . . ,
AB → AB, . . . }
Schallehn
Datenmanagement
Sommersemester 2017
5–16
Relationale Entwurfstheorie
Relationaler DB-Entwurf
Ableitungsregeln
F1
F2
F3
F4
F5
F6
Reflexivität
Augmentation
Transitivität
Dekomposition
Vereinigung
Pseudotransitivität
X ⊇ Y =⇒ X → Y
{X → Y } =⇒ XZ → YZ sowie XZ → Y
{X → Y , Y → Z } =⇒ X → Z
{X → YZ } =⇒ X → Y
{X → Y , X → Z } =⇒ X → YZ
{X → Y , WY → Z } =⇒ WX → Z
F1-F3 bekannt als Armstrong-Axiome (sound, complete)
gültig (sound): Regeln leiten keine FDs ab, die logisch nicht
impliziert
vollständig (complete): alle implizierten FDs werden abgeleitet
unabhängig (independent) oder auch bzgl. ⊆ minimal: keine
Regel kann weggelassen werden
Schallehn
Datenmanagement
Sommersemester 2017
5–17
Relationale Entwurfstheorie
Normalformen
Schemaeigenschaften
Relationenschemata, Schlüssel und Fremdschlüssel so wählen,
dass
alle Anwendungsdaten aus den Basisrelationen hergeleitet werden
können,
nur semantisch sinnvolle und konsistente Anwendungsdaten
dargestellt werden können und
die Anwendungsdaten möglichst nicht-redundant dargestellt
werden.
1
2
3
Hier: Forderung 3
I
I
Redundanzen innerhalb einer Relation: Normalformen
globale Redundanzen: Minimalität
Schallehn
Datenmanagement
Sommersemester 2017
5–18
Relationale Entwurfstheorie
Normalformen
Normalformen
legen Eigenschaften von Relationenschemata fest
verbieten bestimmte Kombinationen von funktionalen
Abhängigkeiten in Relationen
sollen Redundanzen und Anomalien vermeiden
Schallehn
Datenmanagement
Sommersemester 2017
5–19
Relationale Entwurfstheorie
Normalformen
Erste Normalform
erlaubt nur atomare Attribute in den Relationenschemata, d.h. als
Attributwerte sind Elemente von Standard-Datentypen wie
integer oder string erlaubt, aber keine Konstruktoren wie
array oder set
Nicht in 1NF:
Weingut
Anbaugebiet
Region
WName
Ch. La Rose
Creek
Helena
Müller
Bighorn
Saint-Emilion
Barossa Valley
Napa Valley
Rheingau
Napa Valley
Bordeaux
South Australia
Kalifornien
Hessen
Kalifornien
La Rose Grand Cru
Creek Shiraz, Pinot Noir
Zinfandel, Pinot Noir
Riesling Reserve
Chardonnay
Schallehn
Datenmanagement
Sommersemester 2017
5–20
Relationale Entwurfstheorie
Normalformen
Erste Normalform /2
in erster Normalform:
Weingut
Anbaugebiet
Region
WName
Ch. La Rose
Creek
Creek
Helena
Helena
Müller
Bighorn
Saint-Emilion
Barossa Valley
Barossa Valley
Napa Valley
Napa Valley
Rheingau
Napa Valley
Bordeaux
South Australia
South Australia
Kalifornien
Kalifornien
Hessen
Kalifornien
La Rose Grand Cru
Creek Shiraz
Pinot Noir
Zinfandel
Pinot Noir
Riesling Reserve
Chardonnay
Schallehn
Datenmanagement
Sommersemester 2017
5–21
Relationale Entwurfstheorie
Normalformen
Zweite Normalform
partielle Abhängigkeit liegt vor, wenn ein Attribut funktional schon
von einem Teil des Schlüssels abhängt
Name
Weingut
Farbe
Anbaugebiet
Region
La Rose Grand Cru
Creek Shiraz
Pinot Noir
Zinfandel
Pinot Noir
Riesling Reserve
Chardonnay
Ch. La Rose
Creek
Creek
Helena
Helena
Müller
Bighorn
Rot
Rot
Rot
Rot
Rot
Weiß
Weiß
Saint-Emilion
Barossa Valley
Barossa Valley
Napa Valley
Napa Valley
Rheingau
Napa Valley
Bordeaux
South Australia
South Australia
Kalifornien
Kalifornien
Hessen
Kalifornien
f1 :
f2 :
f3 :
f4 :
Preis
39.00
7.99
10.99
5.99
19.99
14.99
9.90
Name, Weingut → Preis
Name
→ Farbe
Weingut
→ Anbaugebiet, Region
Anbaugebiet → Region
Zweite Normalform eliminiert derartige partielle Abhängigkeiten
bei Nichtschlüsselattributen
Schallehn
Datenmanagement
Sommersemester 2017
5–22
Relationale Entwurfstheorie
Normalformen
Eliminierung partieller Abhängigkeiten
Schlüssel K
Teil des
Schlüssels X
Schallehn
abhängiges
Attribut A
Datenmanagement
Sommersemester 2017
5–23
Relationale Entwurfstheorie
Normalformen
Zweite Normalform /2
Beispielrelation in 2NF
R1(Name, Weingut, Preis)
R2(Name, Farbe)
R3(Weingut, Anbaugebiet, Region)
Schallehn
Datenmanagement
Sommersemester 2017
5–24
Relationale Entwurfstheorie
Normalformen
Zweite Normalform /3
Hinweis: partiell abhängiges Attribut stört nur, wenn es kein
Primattribut ist
2NF formal: erweitertes Relationenschema R = (R, K),
FD-Menge F über R
Y hängt partiell von X bzgl. F ab, wenn die FD X → Y nicht
linksreduziert ist
Y hängt voll von X ab, wenn die FD X → Y linksreduziert ist
R ist in 2NF, wenn R in 1NF ist und jedes Nicht-Primattribut von
R voll von jedem Schlüssel von R abhängt
Schallehn
Datenmanagement
Sommersemester 2017
5–25
Relationale Entwurfstheorie
Normalformen
Dritte Normalform
eliminiert (zusätzlich) transitive Abhängigkeiten
etwa Weingut → Anbaugebiet und Anbaugebiet →
Region in Relation auf Folie 5-30
man beachte: 3NF betrachtet nur Nicht-Schlüsselattribute als
Endpunkt transitiver Abhängigkeiten
Schallehn
Datenmanagement
Sommersemester 2017
5–26
Relationale Entwurfstheorie
Normalformen
Eliminierung transitiver Abhängigkeiten
Schlüssel K
Attributmenge X
Schallehn
abhängiges
Attribut A
Datenmanagement
Sommersemester 2017
5–27
Relationale Entwurfstheorie
Normalformen
Dritte Normalform /2
transitive Abhängigkeit in R3, d.h. R3 verletzt 3NF
Beispielrelation in 3NF
R3_1(Weingut, Anbaugebiet)
R3_2(Anbaugebiet, Region)
Schallehn
Datenmanagement
Sommersemester 2017
5–28
Relationale Entwurfstheorie
Normalformen
Dritte Normalform: formal
Relationenschema R, X ⊆ R und F ist eine FD-Menge über R
A ∈ R heißt transitiv abhängig von X bezüglich F genau dann,
wenn es ein Y ⊆ R gibt mit X → Y , Y 6→ X , Y → A, A 6∈ XY
erweitertes Relationenschema R = (R, K) ist in 3NF bezüglich F
genau dann, wenn
6 ∃A ∈ R :
A ist Nicht-Primattribut in R
∧ A transitiv abhängig von einem K ∈ K bezüglich F .
Schallehn
Datenmanagement
Sommersemester 2017
5–29
Relationale Entwurfstheorie
Normalformen
Boyce-Codd-Normalform
Verschärfung der 3NF: Eliminierung transitiver Abhängigkeiten
auch zwischen Primattributen
Name
Weingut
Händler
Preis
La Rose Grand Cru
Creek Shiraz
Pinot Noir
Zinfandel
Pinot Noir
Riesling Reserve
Chardonnay
Château La Rose
Creek
Creek
Helena
Helena
Müller
Bighorn
Weinkontor
Wein.de
Wein.de
GreatWines.com
GreatWines.com
Weinkeller
Wein-Dealer
39.90
7.99
10.99
5.99
19.99
19.99
9.90
FDs:
Name, Weingut → Preis
Weingut
→ Händler
Händler
→ Weingut
Schlüsselkandidaten: { Name, Weingut } und { Name, Händler }
in 3NF, nicht jedoch in BCNF
Schallehn
Datenmanagement
Sommersemester 2017
5–30
Relationale Entwurfstheorie
Normalformen
Boyce-Codd-Normalform /2
erweitertes Relationenschema R = (R, K), FD-Menge F
BCNF formal:
6 ∃A ∈ R : A transitiv abhängig von einem K ∈ K bezüglich F .
Schema in BCNF:
WEINE(Name, Weingut, Preis)
WEINHANDEL(Weingut, Händler)
BCNF kann jedoch Abhängigkeitstreue verletzen, daher oft nur bis
3NF
Schallehn
Datenmanagement
Sommersemester 2017
5–31
Relationale Entwurfstheorie
Normalformen
Minimalität
Global Redundanzen vermeiden
andere Kriterien (wie Normalformen) mit möglichst wenig
Schemata erreichen
Beispiel: Attributmenge ABC, FD-Menge {A → B, B → C}
Datenbankschemata in dritter Normalform:
S = {(AB, {A}), (BC, {B})}
S 0 = {(AB, {A}), (BC, {B}), (AC, {A})}
Redundanzen in S 0
Schallehn
Datenmanagement
Sommersemester 2017
5–32
Relationale Entwurfstheorie
Normalformen
Schemaeigenschaften
Kennung
S 1
Schemaeigenschaft
Kurzcharakteristik
1NF
2NF
nur atomare Attribute
keine partielle Abhängigkeit eines
Nicht-Primattributes von einem
Schlüssel
3NF
keine transitive Abhängigkeit eines Nicht-Primattributes von einem
Schlüssel
keine transitive Abhängigkeit eines
Attributes von einem Schlüssel
BCNF
S 2
Schallehn
Minimalität
minimale Anzahl von Relationenschemata, die die anderen Eigenschaften erfüllt
Datenmanagement
Sommersemester 2017
5–33
Relationale Entwurfstheorie
Transformationseigenschaften
Transformationseigenschaften
Bei einer Zerlegung einer Relation in mehrere Relationen ist
darauf zu achten, dass
1
2
nur semantisch sinnvolle und konsistente Anwendungsdaten
dargestellt (Abhängigkeitstreue) und
alle Anwendungsdaten aus den Basisrelationen hergeleitet werden
können (Verbundtreue)
Schallehn
Datenmanagement
Sommersemester 2017
5–34
Relationale Entwurfstheorie
Transformationseigenschaften
Abhängigkeitstreue
Abhängigkeitstreue: eine Menge von Abhängigkeiten kann
äquivalent in eine zweite Menge von Abhängigkeiten transformiert
werden
spezieller: in die Menge der Schlüsselabhängigkeiten, da diese
vom Datenbanksystem effizient überprüft werden kann
I
I
die Menge der Abhängigkeiten soll äquivalent zu der Menge der
Schlüsselbedingungen im resultierenden Datenbankschema sein
Äquivalenz sichert zu, dass mit den Schlüsselabhängigkeiten
semantisch genau die gleichen Integritätsbedingungen ausgedrückt
werden wie mit den funktionalen oder anderen Abhängigkeiten
vorher
Schallehn
Datenmanagement
Sommersemester 2017
5–35
Relationale Entwurfstheorie
Transformationseigenschaften
Abhängigkeitstreue: Beispiel
Zerlegung des Relationenschemas WEINE (Folie 5-31) in 3NF:
R1(Name, Weingut, Preis)
R2(Name, Farbe)
R3_1(Weingut, Anbaugebiet)
R3_2(Anbaugebiet, Region)
mit Schlüsselabhängigkeiten
Name, Weingut → Preis
Name
→ Farbe
Weingut
→ Anbaugebiet
Anbaugebiet → Region
äquivalent zu FDs f1 . . . f4 (Folie 5-22)
Schallehn
Datenmanagement
abhängigkeitstreu
Sommersemester 2017
5–36
Relationale Entwurfstheorie
Transformationseigenschaften
Abhängigkeitstreue: Beispiel /2
Postleitzahl-Struktur der Deutschen Post
PLZ (P), Ort (O), Strasse(S), Hausnummer(H)
und funktionalen Abhängigkeiten F
OSH → P, P → O
für ein Datenbankschema S bestehend aus dem einzigen
Relationenschema
(OSHP, {OSH}),
ist Menge der Schlüsselabhängigkeiten
{ OSH → OSHP }
nicht äquivalent zu F und somit S nicht abhängigkeitstreu
Schallehn
Datenmanagement
Sommersemester 2017
5–37
Relationale Entwurfstheorie
Transformationseigenschaften
Verbundtreue
zur Erfüllung des Kriteriums der Normalformen müssen
Relationenschemata teilweise in kleinere Relationenschemata
zerlegt werden
für Beschränkung auf „sinnvolle“ Zerlegungen gilt Forderung, dass
die Originalrelation wieder aus den zerlegten Relationen mit dem
natürlichen Verbund zurückgewonnen werden kann
Verbundtreue
Schallehn
Datenmanagement
Sommersemester 2017
5–38
Relationale Entwurfstheorie
Transformationseigenschaften
Verbundtreue: Beispiele
Zerlegung des Relationenschemas R = ABC in
R1 = AB und R2 = BC
Dekomposition bei Vorliegen der Abhängigkeiten
F = {A → B, C → B}
ist nicht verbundtreu
dagegen bei Vorliegen von
F 0 = {A → B, B → C}
verbundtreu
Schallehn
Datenmanagement
Sommersemester 2017
5–39
Relationale Entwurfstheorie
Transformationseigenschaften
Verbundtreue Dekomposition
Originalrelation:
A
1
4
B
2
2
C
3
3
Dekomposition:
A
1
4
B
2
2
B
2
C
3
Verbund (verbundtreu):
A
1
4
Schallehn
B
2
2
Datenmanagement
C
3
3
Sommersemester 2017
5–40
Relationale Entwurfstheorie
Transformationseigenschaften
Nicht verbundtreue Dekomposition
Originalrelation:
A
1
4
B
2
2
C
3
5
Dekomposition:
A
1
4
B
2
2
B
2
2
C
3
5
Verbund (nicht verbundtreu):
Schallehn
A
B
C
1
4
1
4
2
2
2
2
3
5
5
3
Datenmanagement
Sommersemester 2017
5–41
Relationale Entwurfstheorie
Transformationseigenschaften
Transformationseigenschaften
Kennung
Transformationseigenschaft
Kurzcharakteristik
T1
Abhängigkeitstreue
T2
Verbundtreue
alle gegebenen Abhängigkeiten
sind durch Schlüssel repräsentiert
Originalrelationen können durch
den Verbund der Basisrelationen
wiedergewonnen werden
Schallehn
Datenmanagement
Sommersemester 2017
5–42
Relationale Entwurfstheorie
Entwurfsverfahren
Entwurfsverfahren: Ziele
Universum U und FD-Menge F gegeben
lokal erweitertes Datenbankschema S = {(R1 , K1 ), . . . , (Rp , Kp )}
berechnen mit
I
T 1 : S charakterisiert vollständig F
I
S 1 : S ist in 3NF bezüglich F
I
I
T 2 : Dekomposition von U in R1 , . . . , Rp ist verbundtreu bezüglich
F
S 2 : Minimalität, d.h.
6 ∃S 0 : S 0 erfüllt T 1 , S 1 , T 2 und |S 0 | < |S|
Schallehn
Datenmanagement
Sommersemester 2017
5–43
Relationale Entwurfstheorie
Entwurfsverfahren
Entwurfsverfahren: Beispiel
Datenbankschemata schlecht entworfen, wenn nur eins dieser
vier Kriterien nicht erfüllt
Beispiel: S = {(AB, {A}), (BC, {B}), (AC, {A})} erfüllt T 1 ,
S 1 und T 2 bezüglich F = {A → B, B → C, A → C}
in dritter Relation AC-Tupel redundant oder inkonsistent
korrekt: S 0 = {(AB, {A}), (BC, {B})}
Schallehn
Datenmanagement
Sommersemester 2017
5–44
Relationale Entwurfstheorie
Entwurfsverfahren
Dekomposition
Geg.: initiales Universalrelationenschema R = (U, K(F )) mit allen
Attributen und einer von erfassten FDs F über R implizierten
Schlüsselmenge
I
I
Attributmenge U und eine FD-Menge F
suche alle K → U mit K minimal, für die K → U ∈ F + gilt (K(F ))
Ges.: Zerlegung in D = {R1 , R2 , . . . } von
3NF-Relationenschemata
Schallehn
Datenmanagement
Sommersemester 2017
5–45
Relationale Entwurfstheorie
Entwurfsverfahren
Dekomposition: Beispiel
initiales Relationenschema R = ABC
funktionale Abhängigkeiten F = {A → B, B → C}
Schlüssel K = A
Schallehn
Datenmanagement
Sommersemester 2017
5–46
Relationale Entwurfstheorie
Entwurfsverfahren
Dekomposition: Bewertung
Vorteile: 3NF, Verbundtreue
Nachteile: restliche Kriterien nicht, reihenfolgeabhängig,
NP-vollständig (Schlüsselsuche)
Schallehn
Datenmanagement
Sommersemester 2017
5–47
Relationale Entwurfstheorie
Entwurfsverfahren
Syntheseverfahren
Prinzip: Synthese formt Original-FD-Menge F in resultierende
Menge von Schlüsselabhängigkeiten G so um, dass F ≡ G gilt
„Abhängigkeitstreue“ im Verfahren verankert
Verbundtreue, 3NF und Minimalität wird auch erreicht,
reihenfolgeunabhängig
Zeitkomplexität: quadratisch
Schallehn
Datenmanagement
Sommersemester 2017
5–48
WINZER Weingut Name
Relationale Entwurfstheorie
Entwurfsverfahren
WINZER Weingut
Weingut Name
WINZER Name
, FDs FU , FDsFDs
F FUFDs
FDs F FDs F
, FDsF F
Vergleich UDekomposition
— Synthese
FDs U
F , FDs F
U , FDs F
FDs F
FDs F
U , FDs F
FDs F
FDs F !
!
!
!
!
!
U , FDs F U , FDs F
FDs F
FDs F
!
!
!
!
R, K ! R, KFDs F FDs
R, K
R, K
FDs F !
FDs F
R, KF
FDs F !
!
!
!
!!
R, K
FDs F
!
R, K
FDs
!
!
!
!F
R, K
FDs F !!
!
! !
!
!
!
!
!
!
R, K
FDs F !
R, K
FDs F !
!. . ! ! ! !!!
!
! ! ! R! ., .K. !
!!!
!!
.
!!
. .1!.
.R. !n. , Kn! R!1R, K
!
!
R
,
K
R
,
K
K
,
K
!
FDs
F
FDs
F
.
.
.
FDs
F
FDs
F
nR1 , nK1 ...
n
n
1
1
n 1 n
Rn , Kn
FDs F !!
!
!
!
!
...
R!1 , K1!
R! , Kn!
FDs F !!
!
! n
!!
...
R!
R!n , Kn!
FDs
1 , K1 !
!
!
!
!F
!!
.
.
.
R1 , K1
R ,K
FDs F !!!
!
! n !n
!
!
!
!
!
!
.R
. .! , K ! R!n , K. n.! .
R!1 , K1!
FDs F !!
R!n , Kn!
FDs F !!
1
1
.
.
.
.
.
.
.
.
.
.
.
.
.K.1.
.R. n. , Kn R1R, K
.
.
.
.
.
.
...
R , Kn . . .
K1 RnR
. n. , Kn R1R
1 1, !
n , K.nR
n , 1Kn R1 , KR
11 ,, nK
nn ,, 1K
R, K
K11 R...
R, K
Knn R1 , K1 ! RnR, K
Rn , Kn
1 , nK1 n
!
!
!
!
.
.
.
.
.
.
R1 , K1
Rn , Kn
R1 , K1
Rn , Kn
...
...
R1 , K1
Rn , Kn
R1 , K1
Rn , Kn
. . .!
. .!
.
R1 , K1
Rn , Kn !
R1 , K1
Rn , Kn !
Dekomposition
Synthese
Dekomposition
Synthese
Synthese
mposition
Dekomposition Dekomposition
Synthese
Synthese
Dekomposition
Synthese
. .R.1 , K1 Rn , K. n. .
. .R
. 1 , K1 Rn , K.n . .
R1 , K1
Rn , Kn R1 , K1
Rn , Kn
Dekomposition
Synthese
Dekomposition
Synthese
Dekomposition
Synthese
!
U
!, FDs F!
!
Dekomposition
Dekomposition
Schallehn
Synthese
Datenmanagement
Synthese
Sommersemester 2017
5–49
Relationale Entwurfstheorie
Entwurfsverfahren
Synthese: Beispiel
Relationenschema und FD-Menge:
f1 :
Name, Weingut → Preis
f2 :
Name, Weingut → Weingut
f3 :
Name, Weingut → Name
f4 :
Name
→ Farbe
f5 :
Weingut
→ Anbaugebiet, Region
f6 :
Anbaugebiet → Region
minimale Überdeckung: Entfernen von f2 , f3 sowie Region in f5
Äquivalenzklassen (= Relationenschemata):
C1 = {Name, Weingut → Preis}
C2 = {Name → Farbe}
C3 = {Weingut → Anbaugebiet}
C4 = {Anbaugebiet → Region}
Schallehn
Datenmanagement
Sommersemester 2017
5–50
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Weitere Abhängigkeiten
Mehrwertige Abhängigkeit (kurz: MVD)
I
innerhalb einer Relation r wird einem Attributwert von X eine
Menge von Y -Werten zugeordnet, unabhängig von den Werten der
restlichen Attribute
Vierte Normalform
Verbundabhängigkeit (kurz: JD)
I
kann R ohne Informationsverlust in R1 , . . . , Rp aufgetrennt werden:
./ [R1 , . . . , Rp ]
Inklusionsabhängigkeit (kurz: IND)
I
auf der rechten Seite einer Fremdschlüsselabhängigkeit nicht
unbedingt den Primärschlüssel einer Relation
Schallehn
Datenmanagement
Sommersemester 2017
5–51
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Mehrwertige Abhängigkeiten
Folge der 1NF
Mehrwertige Abhängigkeiten erzeugen Redundanz:
WEIN_EMPFEHLUNG WName
Chardonnay
Chardonnay
Chardonnay
Chardonnay
Shiraz
Shiraz
Shiraz
Shiraz
I
I
I
Jahrgang
2002
2002
2003
2003
2003
2003
2004
2004
Gericht
Geflügel
Fisch
Fisch
Geflügel
Wild
Lamm
Wild
Lamm
eine (oder mehrere) Gruppe von Attributwerten ist von einem
Schlüssel bestimmt, unabhängig von anderen Attributen
hier: Menge von Jahrgängen plus Menge von Gerichten
WName →→ Jahrgang, WName →→ Gericht
Resultat: Redundanz durch Bildung aller Kombinationen
Schallehn
Datenmanagement
Sommersemester 2017
5–52
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Mehrwertige Abhängigkeiten und 4NF
wünschenswerte Schemaeigenschaft bei Vorliegen von MVDs:
vierte Normalform
fordert die Beseitigung derartiger Redundanzen: keine zwei MVDs
zwischen Attributen einer Relation
Beispiel von vorhergehender Folie verletzt diese Forderung
Prinzip
I
I
Elimination der rechten Seite einer der beiden mehrwertigen
Abhängigkeiten,
linke Seite mit dieser rechten Seite in neue Relation kopiert
Schallehn
Datenmanagement
Sommersemester 2017
5–53
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Vierte Normalform
WEIN_JAHR WName
Chardonnay
Chardonnay
Shiraz
Shiraz
WEIN_GERICHT WName
Chardonnay
Chardonnay
Shiraz
Shiraz
Schallehn
Jahrgang
2002
2003
2003
2004
Gericht
Geflügel
Fisch
Wild
Lamm
Datenmanagement
Sommersemester 2017
5–54
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Zusammenfassung
funktionale Abhängigkeiten
Normalformen (1NF - 3NF, BCNF)
Abhängigkeitstreue und Verbundtreue
Entwurfsverfahren
mehrwertige Abhängigkeiten
Schallehn
Datenmanagement
Sommersemester 2017
5–55
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierung
relationaler Schemata?
Schallehn
Datenmanagement
Sommersemester 2017
5–56
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierung
relationaler Schemata?
Welche Eigenschaften relationaler
Schemata werden bei den Normalformen
berücksichtigt?
Schallehn
Datenmanagement
Sommersemester 2017
5–56
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierung
relationaler Schemata?
Welche Eigenschaften relationaler
Schemata werden bei den Normalformen
berücksichtigt?
Was unterscheidet 3NF und BCNF?
Schallehn
Datenmanagement
Sommersemester 2017
5–56
Relationale Entwurfstheorie
Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierung
relationaler Schemata?
Welche Eigenschaften relationaler
Schemata werden bei den Normalformen
berücksichtigt?
Was unterscheidet 3NF und BCNF?
Was fordern Abhängigkeitstreue und
Verbundtreue?
Schallehn
Datenmanagement
Sommersemester 2017
5–56
Teil VI
Grundlagen von Anfragen: Algebra &
Kalkül
Grundlagen von Anfragen: Algebra & Kalkül
Grundlagen von Anfragen: Algebra & Kalkül
1
Kriterien für Anfragesprachen
Schallehn
Datenmanagement
Sommersemester 2017
6–1
Grundlagen von Anfragen: Algebra & Kalkül
Grundlagen von Anfragen: Algebra & Kalkül
1
Kriterien für Anfragesprachen
2
Anfragealgebren
Schallehn
Datenmanagement
Sommersemester 2017
6–1
Grundlagen von Anfragen: Algebra & Kalkül
Grundlagen von Anfragen: Algebra & Kalkül
1
Kriterien für Anfragesprachen
2
Anfragealgebren
3
Erweiterungen der Relationenalgebra
Schallehn
Datenmanagement
Sommersemester 2017
6–1
Grundlagen von Anfragen: Algebra & Kalkül
Grundlagen von Anfragen: Algebra & Kalkül
1
Kriterien für Anfragesprachen
2
Anfragealgebren
3
Erweiterungen der Relationenalgebra
4
Anfragekalküle
Schallehn
Datenmanagement
Sommersemester 2017
6–1
Grundlagen von Anfragen: Algebra & Kalkül
Grundlagen von Anfragen: Algebra & Kalkül
1
Kriterien für Anfragesprachen
2
Anfragealgebren
3
Erweiterungen der Relationenalgebra
4
Anfragekalküle
5
Beispiele für Bereichskalkül
Schallehn
Datenmanagement
Sommersemester 2017
6–1
Grundlagen von Anfragen: Algebra & Kalkül
Kriterien für Anfragesprachen
Einführung
bisher:
I
Relationenschemata mit Basisrelationen, die in der Datenbank
gespeichert sind
jetzt:
I
„abgeleitete“ Relationenschemata mit virtuellen Relationen, die aus
den Basisrelationen berechnet werden (Basisrelationen bleiben
unverändert)
Schallehn
Datenmanagement
Sommersemester 2017
6–2
Grundlagen von Anfragen: Algebra & Kalkül
Kriterien für Anfragesprachen
Begriffe
Anfrage: Folge von Operationen, die aus den Basisrelationen eine
Ergebnisrelation berechnet
I
I
Ergebnisrelation interaktiv auf dem Bildschirm anzeigen oder
per Programm weiterverarbeiten („Einbettung“)
Sicht: Folge von Operationen, die unter einem Sichtnamen
langfristig abgespeichert wird und unter diesem Namen wieder
aufgerufen werden kann; ergibt eine Sichtrelation
Snapshot: Ergebnisrelation einer Anfrage, die unter einem
Snapshot-Namen abgelegt wird, aber nie ein zweites Mal (mit
geänderten Basisrelationen) berechnet wird (etwa
Jahresbilanzen)
Schallehn
Datenmanagement
Sommersemester 2017
6–3
Grundlagen von Anfragen: Algebra & Kalkül
Kriterien für Anfragesprachen
Kriterien für Anfragesprachen
Ad-Hoc-Formulierung: Benutzer soll eine Anfrage formulieren
können, ohne ein vollständiges Programm schreiben zu müssen
Deskriptivität: Benutzer soll formulieren „Was will ich haben?“
und nicht „Wie komme ich an das, was ich haben will?“
Mengenorientiertheit: jede Operation soll auf Mengen von Daten
gleichzeitig arbeiten, nicht navigierend nur auf einzelnen
Elementen („one-tuple-at-a-time“)
Abgeschlossenheit: Ergebnis ist wieder eine Relation und kann
wieder als Eingabe für die nächste Anfrage verwendet werden
Schallehn
Datenmanagement
Sommersemester 2017
6–4
Grundlagen von Anfragen: Algebra & Kalkül
Kriterien für Anfragesprachen
Kriterien für Anfragesprachen /2
Adäquatheit: alle Konstrukte des zugrundeliegenden
Datenmodells werden unterstützt
Orthogonalität: Sprachkonstrukte sind in ähnlichen Situationen
auch ähnlich anwendbar
Optimierbarkeit: Sprache besteht aus wenigen Operationen, für
die es Optimierungsregeln gibt
Effizienz: jede Operation ist effizient ausführbar (im
Relationenmodell hat jede Operation eine Komplexität ≤ O(n2 ), n
Anzahl der Tupel einer Relation).
Schallehn
Datenmanagement
Sommersemester 2017
6–5
Grundlagen von Anfragen: Algebra & Kalkül
Kriterien für Anfragesprachen
Kriterien für Anfragesprachen /3
Sicherheit: keine Anfrage, die syntaktisch korrekt ist, darf in eine
Endlosschleife geraten oder ein unendliches Ergebnis liefern
Eingeschränktheit: (folgt aus Sicherheit, Optimierbarkeit,
Effizienz) Anfragesprache darf keine komplette
Programmiersprache sein
Vollständigkeit: Sprache muss mindestens die Anfragen einer
Standardsprache (wie etwa die in diesem Kapitel einzuführende
Relationenalgebra oder den sicheren Relationenkalkül)
ausdrücken können
Schallehn
Datenmanagement
Sommersemester 2017
6–6
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Anfragealgebren
Mathematik: Algebra definiert durch Wertebereich und auf diesem
definierte Operatoren
für Datenbankanfragen: Inhalte der Datenbank sind Werte, und
Operatoren definieren Funktionen zum Berechnen von
Anfrageergebnissen
I
I
Relationenalgebra
Algebra-Erweiterungen
Schallehn
Datenmanagement
Sommersemester 2017
6–7
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Relationenalgebra
Spalten ausblenden: Projektion π
Zeilen heraussuchen: Selektion σ
Tabellen verknüpfen: Verbund (Join) o
n
Tabellen vereinigen: Vereinigung ∪;
Tabellen voneinander abziehen: Differenz −
Spalten umbenennen: Umbenennung β
(wichtig für o
n und ∪, −)
Schallehn
Datenmanagement
Sommersemester 2017
6–8
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Relationenalgebra: Übersicht
Selektion
Projektion
Verbund
Schallehn
a1
b2
b2
c3
a1
b2
c3
a2
b2
b3
c4
a2
b2
c3
a2
b3
b4
c5
a2
b3
c4
Datenmanagement
Sommersemester 2017
6–9
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Projektion
Syntax
πAttributmenge (Relation)
Semantik
πX (r ) := {t(X ) | t ∈ r }
für r (R) und X ⊆ R Attributmenge in R
Eigenschaft für Y ⊆ X ⊆ R
πY (πX (r )) = πY (r )
Achtung: π entfernt Duplikate (Mengensemantik)
Schallehn
Datenmanagement
Sommersemester 2017
6–10
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Projektion: Beispiel
πRegion (ERZEUGER)
Region
South Australia
Kalifornien
Bordeaux
Hessen
Schallehn
Datenmanagement
Sommersemester 2017
6–11
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Projektion: Beispiel 2
πAnbaugebiet,Region (ERZEUGER)
Anbaugebiet
Barossa Valley
Napa Valley
Saint-Emilion
Pomerol
Rheingau
Schallehn
Region
South Australia
Kalifornien
Bordeaux
Bordeaux
Hessen
Datenmanagement
Sommersemester 2017
6–12
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Selektion
Syntax
σBedingung (Relation)
Semantik (für A ∈ R)
σA=a (r ) := {t ∈ r | t(A) = a}
Schallehn
Datenmanagement
Sommersemester 2017
6–13
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Selektionsbedingungen
Konstantenselektion
Attribut θ Konstante
boolesches Prädikat θ ist = oder 6=, bei linear geordneten
Wertebereichen auch ≤, <, ≥ oder >
Attributselektion
Attribut1 θ Attribut2
logische Verknüpfung mehrerer Konstanten- oder AttributSelektionen mit ∧, ∨ oder ¬
Schallehn
Datenmanagement
Sommersemester 2017
6–14
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Selektion: Eigenschaften
Kommutativität
σA=a (σB=b (r )) = σB=b (σA=a (r ))
falls A ∈ X , X ⊆ R
πX (σA=a (r )) = σA=a (πX (r ))
Distributivität bzgl. ∪, ∩, −
σA=a (r ∪ s) = σA=a (r ) ∪ σA=a (s)
Schallehn
Datenmanagement
Sommersemester 2017
6–15
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Selektion: Beispiel
σJahrgang>2000 (WEINE)
WeinID
2168
3456
2171
4961
Name
Farbe
Creek Shiraz
Zinfandel
Pinot Noir
Chardonnay
Rot
Rot
Rot
Weiß
Schallehn
Jahrgang
2003
2004
2001
2002
Datenmanagement
Weingut
Creek
Helena
Creek
Bighorn
Sommersemester 2017
6–16
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Verbund
Syntax des (natürlichen) Verbundes (engl.: natural join)
Relation1 o
n Relation2
Semantik
r1 o
n r2 := {t | t(R1 ∪ R2 ) ∧
[∀i ∈ {1, 2}∃ti ∈ ri : ti = t(Ri )]}
Verbund verknüpft Tabellen über gleichbenannten Spalten bei
gleichen Attributwerten
Schallehn
Datenmanagement
Sommersemester 2017
6–17
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Verbund: Eigenschaften
Schema für r (R) o
n r (S) ist Vereinigung der Attributmengen
RS = R ∪ S
aus R1 ∩ R2 = {} folgt r1 o
n r2 = r1 × r2
Kommutativität: r1 o
n r2 = r2 o
n r1
Assoziativität: (r1 o
n r2 ) o
n r3 = r1 o
n (r2 o
n r3 )
daher erlaubt:
o
npi=1 ri
Schallehn
Datenmanagement
Sommersemester 2017
6–18
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Verbund: Beispiel
WEINE o
n ERZEUGER
WeinID
Name
...
Weingut
Anbaugebiet
Region
1042
2168
3456
2171
3478
4711
4961
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
...
...
...
...
...
...
...
Ch. La Rose
Creek
Helena
Creek
Helena
Müller
Bighorn
Saint-Emilion
Barossa Valley
Napa Valley
Barossa Valley
Napa Valley
Rheingau
Napa Valley
Bordeaux
South Australia
Kalifornien
South Australia
Kalifornien
Hessen
Kalifornien
Schallehn
Datenmanagement
Sommersemester 2017
6–19
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Umbenennung
Syntax
βneu←alt (Relation)
Semantik
βB←A (r ) := {t 0 | ∃t ∈ r : t 0 (R − A) = t(R − A) ∧ t 0 (B) = t(A)}
ändert Attributnamen von alt in neu
βName←Nachname (KRITIKER)
durch Umbenennung nun möglich
I
I
I
Verbunde, wo bisher kartesische Produkte ausgeführt wurden
(unterschiedliche Attribute werden gleich benannt),
kartesische Produkte, wo bisher Verbunde ausgeführt wurden
(gleiche Attribute werden unterschiedlich genannt),
Mengenoperationen
Schallehn
Datenmanagement
Sommersemester 2017
6–20
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Berechnung des Kreuzproduktes
natürlicher Verbund entartet zum Kreuzprodukt, wenn keine
gemeinsamen Attribute existieren
Erzwingen durch Umbenennung
I
Beispiel: R1(A, B, C) und R2(C, D)
R1 × R2 ≡ R1 o
n βE←C (R2)
Kreuzprodukt + Selektion simuliert natürlichen Verbund
R1 o
n R2 ≡ σR1.C=R2.C (R1 × R2)
Schallehn
Datenmanagement
Sommersemester 2017
6–21
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Mengenoperationen: Semantik
formal für r1 (R) und r2 (R)
I
I
I
Vereinigung r1 ∪ r2 := {t | t ∈ r1 ∨ t ∈ r2 }
Durchschnitt r1 ∩ r2 := {t | t ∈ r1 ∧ t ∈ r2 }
Differenz r1 − r2 := {t | t ∈ r1 ∧ t 6∈ r2 }
Durchschnitt ∩ wegen r1 ∩ r2 = r1 − (r1 − r2 ) überflüssig
Schallehn
Datenmanagement
Sommersemester 2017
6–22
Grundlagen von Anfragen: Algebra & Kalkül
Anfragealgebren
Unabhängigkeit und Vollständigkeit
Minimale Relationenalgebra:
Ω = π, σ, o
n, β, ∪ und −
unabhängig: kein Operator kann weggelassen werden ohne
Vollständigkeit zu verlieren
andere unabhängige Menge: o
n und β durch × ersetzen
Relationale Vollständigkeit: jede andere Menge von Operationen
genauso mächtig wie Ω
strenge relationale Vollständigkeit: zu jedem Ausdruck mit
Operatoren aus Ω gibt es einen Ausdruck auch mit der anderen
Menge von Operationen
Schallehn
Datenmanagement
Sommersemester 2017
6–23
Grundlagen von Anfragen: Algebra & Kalkül
Erweiterungen der Relationenalgebra
Erweiterungen der Relationenalgebra
weitere Verbundoperationen
Division
Gruppierung und geschachtelte Relationen
...
Schallehn
Datenmanagement
Sommersemester 2017
6–24
Grundlagen von Anfragen: Algebra & Kalkül
Erweiterungen der Relationenalgebra
Verbundvarianten
für L(AB), R(BC), S(DE)
Gleichverbund (engl. equi-join): Gleichheitsbedingung über
explizit angegebene und evtl. verschiedene Attribute
r (R) o
nC=D r (S)
Theta-Verbund (engl. θ-join): beliebige Verbundbedingung
r (R) o
nC>D r (S)
Semi-Verbund: nur Attribute eines Operanden erscheinen im
Ergebnis
r (L) n r (R) = πL (r (L) o
n r (R))
äußere Verbunde (engl. outer join)
Schallehn
Datenmanagement
Sommersemester 2017
6–25
Grundlagen von Anfragen: Algebra & Kalkül
Erweiterungen der Relationenalgebra
Äußere Verbunde
Übernahme von „dangling tuples“ in das Ergebnis und Auffüllen
mit Nullwerten
voller äußerer Verbund übernimmt alle Tupel beider Operanden
r A./@ s
linker äußerer Verbund übernimmt alle Tupel des linken
Operanden
r A./ s
rechter äußerer Verbund übernimmt alle Tupel des rechten
Operanden
r ./@ s
Schallehn
Datenmanagement
Sommersemester 2017
6–26
Grundlagen von Anfragen: Algebra & Kalkül
Erweiterungen der Relationenalgebra
Äußere Verbunde /2
LINKS A
B
RECHTS B
C
n
o A
B
C
1
2
2
3
3
4
4
5
2
3
4
A./@ A
B
C
A./ A
B
C
./@ A
B
C
1
2
⊥
2
3
4
⊥
4
5
1
2
2
3
⊥
4
2
⊥
3
4
4
5
natural join
Schallehn
left outer join
right outer join
Datenmanagement
full outer join
Sommersemester 2017
6–27
Grundlagen von Anfragen: Algebra & Kalkül
Anfragekalküle
Anfragekalküle
Kalkül: eine formale logische Sprache zur Formulierung von
Aussagen
Ziel: Einsatz eines derartigen Kalküls zur Formulierung von
Datenbank-Anfragen
Logikbasierter Ansatz:
I
I
Datenbankinhalte entsprechen Belegungen von Prädikaten einer
Logik
Anfragen abgeleiteten Prädikaten
Schallehn
Datenmanagement
Sommersemester 2017
6–28
Grundlagen von Anfragen: Algebra & Kalkül
Anfragekalküle
Ein allgemeiner Kalkül
Motivation: mathematische Notation
{x 2 | x ∈ N ∧ x 3 > 0 ∧ x 3 < 1000}
Anfrage hat die Form
{f (x) | p(x)}
I
x bezeichnet Menge von freien Variablen
x = {x1 : D1 , . . . , xn : Dn }
Schallehn
Datenmanagement
Sommersemester 2017
6–29
Grundlagen von Anfragen: Algebra & Kalkül
Anfragekalküle
Ein allgemeiner Kalkül /2
Funktion f bezeichnet Ergebnisfunktion über x
I
wichtige Spezialfälle: Angabe einer Variable selber (f ist hier die
Identitätsfunktion) und Tupelkonstruktion (Ergebnis vom Typ tuple
of)
p Selektionsprädikat über freien Variablen x
I
I
I
I
Terme aus Variablen, Konstanten und Funktionsanwendungen
Prädikate der Datentypen, etwa ≤, <, >, ≥, ...
→ atomare Formeln über Termen
Bezug zur aktuellen Datenbank → Datenbankprädikate, z.B.
Relationennamen im RM
prädikatenlogischen Operatoren ∧, ∨, ¬, ∀, ∃
→ Formeln
Schallehn
Datenmanagement
Sommersemester 2017
6–30
Grundlagen von Anfragen: Algebra & Kalkül
Anfragekalküle
Ergebnisbestimmung einer Anfrage
x = {x1 : D1 , . . . , xn : Dn }
1
Bestimme aller Belegungen der freien Variablen in x, für die das
Prädikat p wahr wird.
2
Wende Funktion f auf die durch diese Belegungen gegebenen
Werte an.
Unter welchen Umständen liefern Kalkülanfragen endliche
Ergebnisse?
→ Sicherheit von Anfragen
Schallehn
Datenmanagement
Sommersemester 2017
6–31
Grundlagen von Anfragen: Algebra & Kalkül
Anfragekalküle
Relationale Kalküle
Bereichskalkül: Variablen nehmen Werte elementarer
Datentypen (Bereiche) an
Tupelkalkül: Variablen variieren über Tupelwerte (entsprechend
den Zeilen einer Relation)
Schallehn
Datenmanagement
Sommersemester 2017
6–32
Grundlagen von Anfragen: Algebra & Kalkül
Anfragekalküle
Tupelkalkül
Grundlage von SFW-Anfragen in SQL
Variablen sind tupelwertig
Beispiel:
{w | w ∈ WEINE ∧ w.Farbe = ’Rot’}
Schallehn
Datenmanagement
Sommersemester 2017
6–33
Grundlagen von Anfragen: Algebra & Kalkül
Anfragekalküle
Tupelkalkül: Beispiele
konstruierte Tupel
{hw.Name, w.Weinguti | w ∈ WEINE ∧ w.Farbe = ’Rot’}
Verbund
{he.Weinguti | e ∈ ERZEUGER∧w ∈ WEINE∧e.Weingut = w.Weing
Schachtelung
{hw.Name, w.Weinguti | w ∈ WEINE∧
∃e ∈ ERZEUGER(w.Weingut = e.Weingut∧e.Region = ’Bordeau
Schallehn
Datenmanagement
Sommersemester 2017
6–34
Grundlagen von Anfragen: Algebra & Kalkül
Beispiele für Bereichskalkül
Beispiele Bereichskalkül
Anfrage: „Alle Weingüter von Erzeugern in Hessen.“
{x | ERZEUGER(x, y , z) ∧ z = ’Hessen’}
Vereinfachte Notation: Ansonsten ungebundene Variablen (hier y
und z) im Bedingungsteil existentiell mit ∃ gebunden
Vollständige Version:
{x | ∃y ∃zERZEUGER(x, y , z) ∧ z = ’Hessen’}
Einsparung von Bereichsvariablen, indem Konstanten als
Parameter des Prädikats eingesetzt werden:
{x | ERZEUGER(x, y , ’Hessen’)}
Schallehn
Datenmanagement
Sommersemester 2017
6–35
Grundlagen von Anfragen: Algebra & Kalkül
Beispiele für Bereichskalkül
Beispiele Bereichskalkül /2
Abkürzung für beliebige, unterschiedliche existentiell gebundene
Variablen ist _ Symbol:
{x | ERZEUGER(x, _, z) ∧ z = ’Hessen’}
Verschiedene Auftreten des Symbols _ stehen hierbei für
paarweise verschiedene Variablen
Schallehn
Datenmanagement
Sommersemester 2017
6–36
Grundlagen von Anfragen: Algebra & Kalkül
Beispiele für Bereichskalkül
Zusammenfassung
formale Modelle für Anfragen in Datenbanksystemen
Relationenalgebra
I
I
operationaler Ansatz
Anfrage als Schachtelung von Operatoren auf Relationen
Anfragekalküle
I
I
logikbasierter Ansatz
Anfragen als abgeleitete Prädikate
Schallehn
Datenmanagement
Sommersemester 2017
6–37
Teil VII
SQL als relationale Anfragesprache
SQL als relationale Anfragesprache
SQL als relationale Anfragesprache
1
Der SFW-Block in Detail
Schallehn
Datenmanagement
Sommersemester 2017
7–1
SQL als relationale Anfragesprache
SQL als relationale Anfragesprache
1
Der SFW-Block in Detail
2
Erweiterungen des SFW-Blocks
Schallehn
Datenmanagement
Sommersemester 2017
7–1
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Struktur einer SQL-Anfrage
-- Anfrage
select projektionsliste
from relationenliste
[ where bedingung ]
select
Projektionsliste
arithmetische Operationen und Aggregatfunktionen
from
zu verwendende Relationen, evtl. Umbenennungen
where
Selektions-, Verbundbedingungen
Geschachtelte Anfragen (wieder ein SFW-Block)
Schallehn
Datenmanagement
Sommersemester 2017
7–2
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Auswahl von Tabellen: Die from-Klausel
einfachste Form:
I
hinter jedem Relationennamen kann optional eine Tupelvariable
stehen
select *
from relationenliste
Beispielanfrage:
select *
from WEINE
Schallehn
Datenmanagement
Sommersemester 2017
7–3
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Kartesisches Produkt
bei mehr als einer Relation wird das kartesische Produkt gebildet:
select *
from WEINE, ERZEUGER
alle Kombinationen werden ausgegeben!
Schallehn
Datenmanagement
Sommersemester 2017
7–4
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Tupelvariablen für mehrfachen Zugriff
Einführung von Tupelvariablen erlaubt mehrfachen Zugriff auf eine
Relation:
select *
from WEINE w1, WEINE w2
Spalten lauten dann:
w1.WeinID, w1.Name, w1.Farbe, w1.Jahrgang, w1.Weingut
w2.WeinID, w2.Name, w2.Farbe, w2.Jahrgang, w2.Weingut
Schallehn
Datenmanagement
Sommersemester 2017
7–5
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Natürlicher Verbund in SQL92
frühe SQL-Versionen (vor SQL92)
I
I
I
üblicherweise realisierter Standard in aktuellen Systemen
kennen nur Kreuzprodukt, keinen expliziten Verbundoperator
Verbund durch Prädikat hinter where realisieren
Beispiel für natürlichen Verbund:
select *
from WEINE, ERZEUGER
where WEINE.Weingut = ERZEUGER.Weingut
Schallehn
Datenmanagement
Sommersemester 2017
7–6
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Verbund explizit: natural join
neuere SQL-Versionen (seit SQL92)
I
I
kennen mehrere explizite Verbundoperatoren (engl. join)
als Abkürzung für die ausführliche Anfrage mit Kreuzprodukt
aufzufassen
select *
from WEINE natural join ERZEUGER
Schallehn
Datenmanagement
Sommersemester 2017
7–7
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Verbunde als explizite Operatoren: join
Verbund mit beliebigem Prädikat:
select *
from WEINE join ERZEUGER
on WEINE.Weingut = ERZEUGER.Weingut
Gleichverbund mit using:
select *
from WEINE join ERZEUGER
using (Weingut)
Schallehn
Datenmanagement
Sommersemester 2017
7–8
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Verbund explizit: cross join
Kreuzprodukt
select *
from WEINE, ERZEUGER
als cross join
select *
from WEINE cross join ERZEUGER
Schallehn
Datenmanagement
Sommersemester 2017
7–9
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Tupelvariable für Zwischenergebnisse
„Zwischenrelationen“ aus SQL-Operationen oder einem
SFW-Block können über Tupelvariablen mit Namen versehen
werden
select Ergebnis.Weingut
from (WEINE natural join ERZEUGER) as Ergebnis
as ist optional
Schallehn
Datenmanagement
Sommersemester 2017
7–10
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Die select-Klausel
Festlegung der Projektionsattribute
select [distinct] projektionsliste
from ...
mit
projektionsliste := {attribut |
arithmetischer-ausdruck |
aggregat-funktion } [, ...]
I
I
I
Attribute der hinter from stehenden Relationen, optional mit Präfix,
der Relationennamen oder Namen der Tupelvariablen angibt
arithmetische Ausdrücke über Attributen dieser Relationen und
passenden Konstanten
Aggregatfunktionen über Attributen dieser Relationen
Schallehn
Datenmanagement
Sommersemester 2017
7–11
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Die select-Klausel
Spezialfall der Projektionsliste: *
I
liefert alle Attribute der Relation(en) aus dem from-Teil
select *
from WEINE
Schallehn
Datenmanagement
Sommersemester 2017
7–12
SQL als relationale Anfragesprache
Der SFW-Block in Detail
distinct eliminiert Duplikate
select Name from WEINE
liefert die Ergebnisrelation als Multimenge:
Name
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Pinot Noir
Riesling Reserve
Chardonnay
Schallehn
Datenmanagement
Sommersemester 2017
7–13
SQL als relationale Anfragesprache
Der SFW-Block in Detail
distinct eliminiert Duplikate /2
select distinct Name from WEINE
ergibt Projektion aus der Relationenalgebra:
Name
La Rose Grand Cru
Creek Shiraz
Zinfandel
Pinot Noir
Riesling Reserve
Chardonnay
Schallehn
Datenmanagement
Sommersemester 2017
7–14
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Tupelvariablen und Relationennamen
Anfrage
select Name from WEINE
ist äquivalent zu
select WEINE.Name from WEINE
und
select W.Name from WEINE W
Schallehn
Datenmanagement
Sommersemester 2017
7–15
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Präfixe für Eindeutigkeit
select Name, Jahrgang, Weingut
from WEINE natural join ERZEUGER
-- (falsch!)
Attribut Weingut existiert sowohl in der Tabelle WEINE als auch in
ERZEUGER!
richtig mit Präfix:
select Name, Jahrgang, ERZEUGER.Weingut
from WEINE natural join ERZEUGER
Schallehn
Datenmanagement
Sommersemester 2017
7–16
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Tupelvariablen für Eindeutigkeit
bei der Verwendung von Tupelvariablen, kann der Name einer
Tupelvariablen zur Qualifizierung eines Attributs benutzt werden:
select w1.Name, w2.Weingut
from WEINE w1, WEINE w2
Schallehn
Datenmanagement
Sommersemester 2017
7–17
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Die where-Klausel
select ...from ...
where bedingung
Formen der Bedingung:
I
I
I
Vergleich eines Attributs mit einer Konstanten:
attribut θ konstante
mögliche Vergleichssymbole θ abhängig vom Wertebereich; etwa
=, <>, >, <, >= sowie <=.
Vergleich zwischen zwei Attributen mit kompatiblen
Wertebereichen:
attribut1 θ attribut2
logische Konnektoren or, and und not
Schallehn
Datenmanagement
Sommersemester 2017
7–18
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Verbundbedingung
Verbundbedingung hat die Form:
relation1.attribut = relation2.attribut
Beispiel:
select Name, Jahrgang, ERZEUGER.Weingut
from WEINE, ERZEUGER
where WEINE.Weingut = ERZEUGER.Weingut
Schallehn
Datenmanagement
Sommersemester 2017
7–19
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Bereichsselektion
Bereichsselektion
attrib between konstante1 and konstante2
ist Abkürzung für
attrib ≥ konstante1 and
attrib ≤ konstante2
schränkt damit Attributwerte auf das abgeschlossene Intervall
[konstante1 , konstante2 ] ein
Beispiel:
select * from WEINE
where Jahrgang between 2000 and 2005
Schallehn
Datenmanagement
Sommersemester 2017
7–20
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Ungewissheitsselektion
Notation
attribut like spezialkonstante
Mustererkennung in Strings (Suche nach mehreren
Teilzeichenketten)
Spezialkonstante kann die Sondersymbole ‘%’ und ‘_’ beinhalten
I
I
‘%’ steht für kein oder beliebig viele Zeichen
‘_’ steht für genau ein Zeichen
Schallehn
Datenmanagement
Sommersemester 2017
7–21
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Ungewissheitsselektion /2
Beispiel
select * from WEINE
where Name like ’La Rose%’
ist Abkürzung für
select * from WEINE
where Name = ’La Rose’
or Name = ’La RoseA’ or Name = ’La RoseAA’ ...
or Name = ’La RoseB’ or Name = ’La RoseBB’ ...
...
or Name = ’La Rose Grand Cru’ ...
or Name = ’La Rose Grand Cru Classe’ ...
...
or Name = ’La RoseZZZZZZZZZZZZZ’ ...
Schallehn
Datenmanagement
Sommersemester 2017
7–22
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Mengenoperationen
Mengenoperationen erfordern kompatible Wertebereiche für
Paare korrespondierender Attribute:
I
I
I
beide Wertebereiche sind gleich oder
beide sind auf character basierende Wertebereiche (unabhängig
von der Länge der Strings) oder
beide sind numerische Wertebereiche (unabhängig von dem
genauen Typ) wie integer oder float
Ergebnisschema := Schema der „linken“ Relation
select A, B, C from R1
union
select A, C, D from R2
Schallehn
Datenmanagement
Sommersemester 2017
7–23
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Mengenoperationen in SQL
Vereinigung, Durchschnitt und Differenz als union, intersect
und except
orthogonal einsetzbar:
select *
from (select Weingut from ERZEUGER
except select Weingut from WEINE)
äquivalent zu
select *
from ERZEUGER except corresponding WEINE
Schallehn
Datenmanagement
Sommersemester 2017
7–24
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Mengenoperationen in SQL /2
über corresponding by-Klausel: Angabe der Attributliste, über
die Mengenoperation ausgeführt wird
select *
from ERZEUGER
except corresponding by (Weingut) WEINE
bei Vereinigung: Defaultfall ist Duplikateliminierung (union
distinct); ohne Duplikateliminierung durch union all
Schallehn
Datenmanagement
Sommersemester 2017
7–25
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Mengenoperationen in SQL /2
R A
1
2
B
2
3
C
3
4
S A
2
2
C
3
4
D
4
5
R union S A
1
2
2
B
2
3
4
C
3
4
5
R union all S A
1
2
2
2
B
2
3
3
4
C
3
4
4
5
R union corresponding S A
1
2
2
C
3
4
3
R union corresponding by (A) S A
1
2
Schallehn
Datenmanagement
Sommersemester 2017
7–26
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Schachtelung von Anfragen
für Vergleiche mit Wertemengen notwendig:
I
I
Standardvergleiche in Verbindung mit den Quantoren all (∀) oder
any (∃)
spezielle Prädikate für den Zugriff auf Mengen, in und exists
Schallehn
Datenmanagement
Sommersemester 2017
7–27
SQL als relationale Anfragesprache
Der SFW-Block in Detail
in-Prädikat und geschachtelte Anfragen
Notation:
attribut in ( SFW-block )
Beispiel:
select Name
from WEINE
where Weingut in (
select Weingut from ERZEUGER
where Region=’Bordeaux’)
Schallehn
Datenmanagement
Sommersemester 2017
7–28
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Auswertung von geschachtelten Anfragen
1
Auswertung der inneren Anfrage zu den Weingütern aus
Bordeaux
2
Einsetzen des Ergebnisses als Menge von Konstanten in die
äußere Anfrage hinter in
3
Auswertung der modifizierten Anfrage
select Name
from WEINE
where Weingut in (
’Château La Rose’, ’Château La Pointe’)
Name
La Rose Grand Cru
Schallehn
Datenmanagement
Sommersemester 2017
7–29
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Auswertung von geschachtelten Anfragen /2
interne Auswertung: Umformung in einen Verbund
select Name
from WEINE natural join ERZEUGER
where Anbaugebiet = ’Bordeaux’
Schallehn
Datenmanagement
Sommersemester 2017
7–30
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Negation des in-Prädikats
Simulation des Differenzoperators
πWeingut (ERZEUGER) − πWeingut (WEINE)
durch SQL-Anfrage
select Weingut from ERZEUGER
where Weingut not in (
select Weingut from WEINE )
Schallehn
Datenmanagement
Sommersemester 2017
7–31
SQL als relationale Anfragesprache
Der SFW-Block in Detail
Mächtigkeit des SQL-Kerns
Relationenalgebra
Projektion
Selektion
Verbund
Umbenennung
Differenz
Durchschnitt
Vereinigung
Schallehn
SQL
select distinct
where ohne Schachtelung
from, where
from mit join oder natural join
from mit Tupelvariable; as
where mit Schachtelung
except corresponding
where mit Schachtelung
intersect corresponding
union corresponding
Datenmanagement
Sommersemester 2017
7–32
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Weiteres zu SQL
Erweiterungen des SFW-Blocks
I
I
I
I
innerhalb der from-Klausel weitere Verbundoperationen (äußerer
Verbund),
innerhalb der where-Klausel weitere Arten von Bedingungen und
Bedingungen mit Quantoren,
innerhalb der select-Klausel die Anwendung von skalaren
Operationen und Aggregatfunktionen,
zusätzliche Klauseln group by und having
rekursive Anfragen
Schallehn
Datenmanagement
Sommersemester 2017
7–33
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Skalare Ausdrücke
Umbenennung von Spalten: ausdruck as neuer-name
skalare Operationen auf
I
I
I
numerischen Wertebereichen: etwa +, −, ∗ und /,
Strings: Operationen wie char_length (aktuelle Länge eines
Strings), die Konkatenation k und die Operation substring
(Suchen einer Teilzeichenkette an bestimmten Positionen des
Strings),
Datumstypen und Zeitintervallen: Operationen wie current_date
(aktuelles Datum), current_time (aktuelle Zeit), +, − und ∗
bedingte Ausdrücke
Typkonvertierung
Hinweise:
I
I
skalare Ausdrücke können mehrere Attribute umfassen
Anwendung ist tupelweise: pro Eingabetupel entseht ein
Ergebnistupel
Schallehn
Datenmanagement
Sommersemester 2017
7–34
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Skalare Ausdrücke /2
Ausgabe der Namen aller Grand Cru-Weine
select substring(Name from 1 for
(char_length(Name) - position(’Grand Cru’ in Name)))
from WEINE where Name like ’%Grand Cru’
Annahme: zusätzliches Attribut HerstDatum in WEINE
alter table WEINE add column HerstDatum date
update WEINE set HerstDatum = date ’2004-08-13’
where Name = ’Zinfandel’
Anfrage:
select Name, year(current_date - HerstDatum) as Alter
from WEINE
Schallehn
Datenmanagement
Sommersemester 2017
7–35
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Bedingte Ausdrücke
case-Anweisung: Ausgabe eines Wertes in Abhängigkeit von der
Auswertung eines Prädikats
case
when prädikat1 then ausdruck1
...
when prädikatn−1 then ausdruckn−1
[ else ausdruckn ]
end
Einsatz in select- und where-Klausel
select case
when Farbe = ’Rot’ then ’Rotwein’
when Farbe = ’Weiß’ then ’Weißwein’
else ’Sonstiges’
end as Weinart, Name from WEINE
Schallehn
Datenmanagement
Sommersemester 2017
7–36
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Typkonvertierung
explizite Konvertierung des Typs von Ausdrücken
cast(ausdruck as typname)
Beispiel: int-Werte als Zeichenkette für Konkatenationsoperator
select cast(Jahrgang as varchar) || ’er ’ ||
Name as Bezeichnung
from WEINE
Schallehn
Datenmanagement
Sommersemester 2017
7–37
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Quantoren und Mengenvergleiche
Quantoren: all, any, some und exists
Notation
attribut θ { all | any | some } (
select attribut
from ...where ...)
all: where-Bedingung wird erfüllt, wenn für alle Tupel des
inneren SFW-Blocks der θ-Vergleich mit attribut true wird
any bzw. some: where-Bedingung wird erfüllt, wenn der
θ-Vergleich mit mindestens einem Tupel des inneren SFW-Blocks
true wird
Schallehn
Datenmanagement
Sommersemester 2017
7–38
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Bedingungen mit Quantoren: Beispiele
Bestimmung des ältesten Weines
select *
from WEINE
where Jahrgang <= all (
select Jahrgang from WEINE)
alle Weingüter, die Rotweine produzieren
select *
from ERZEUGER
where Weingut = any (
select Weingut from WEINE
where Farbe = ’Rot’)
Schallehn
Datenmanagement
Sommersemester 2017
7–39
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Vergleich von Wertemengen
Test auf Gleichheit zweier Mengen allein mit Quantoren nicht
möglich
Beispiel: „Gib alle Erzeuger aus, die sowohl Rot- als auch
Weißweine produzieren.“
falsche Anfrage
select Weingut
from WEINE
where Farbe = ’Rot’ and Farbe = ’Weiß’
richtige Formulierung
select w1.Weingut
from WEINE w1, WEINE w2
where w1.Weingut = w2.Weingut
and w1.Farbe = ’Rot’ and w2.Farbe = ’Weiß’
Schallehn
Datenmanagement
Sommersemester 2017
7–40
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Das exists/not exists-Prädikat
einfache Form der Schachtelung
exists ( SFW-block )
liefert true, wenn das Ergebnis der inneren Anfrage nicht leer ist
speziell bei verzahnt geschachtelten (korrelierte) Anfragen
sinnvoll
I
in der inneren Anfrage wird Relationen- oder Tupelvariablen-Name
aus dem from-Teil der äußeren Anfrage verwendet
Schallehn
Datenmanagement
Sommersemester 2017
7–41
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Verzahnt geschachtelte Anfragen
Weingüter mit 1999er Rotwein
select * from ERZEUGER
where 1999 in (
select Jahrgang from WEINE
where Farbe=’Rot’ and WEINE.Weingut = ERZEUGER.We
konzeptionelle Auswertung
1
2
Untersuchung des ersten ERZEUGER-Tupels in der äußeren
Anfrage (Creek) und Einsetzen in innere Anfrage
Auswertung der inneren Anfrage
select Jahrgang from WEINE
where Farbe=’Rot’ and WEINE.Weingut = ’Creek’
3
Weiter bei 1. mit zweitem Tupel . . .
Alternative: Umformulierung in Verbund
Schallehn
Datenmanagement
Sommersemester 2017
7–42
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Beispiel für exists
Weingüter aus Bordeaux ohne gespeicherte Weine
select * from ERZEUGER e
where Region = ’Bordeaux’ and not exists (
select * from WEINE
where Weingut = e.Weingut)
Schallehn
Datenmanagement
Sommersemester 2017
7–43
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen und Gruppierung
Aggregatfunktionen berechnen neue Werte für eine gesamte
Spalte, etwa die Summe oder den Durchschnitt der Werte einer
Spalte
Beispiel: Ermittlung des Durchschnittspreises aller Artikel oder
des Gesamtumsatzes über alle verkauften Produkte
bei zusätzlicher Anwendung von Gruppierung: Berechnung der
Funktionen pro Gruppe, z.B. der Durchschnittspreis pro
Warengruppe oder der Gesamtumsatz pro Kunde
Schallehn
Datenmanagement
Sommersemester 2017
7–44
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen
Aggregatfunktionen in Standard-SQL:
I
I
I
I
count: berechnet Anzahl der Werte einer Spalte oder alternativ (im
Spezialfall count(∗)) die Anzahl der Tupel einer Relation
sum: berechnet die Summe der Werte einer Spalte (nur bei
numerischen Wertebereichen)
avg: berechnet den arithmetischen Mittelwert der Werte einer
Spalte (nur bei numerischen Wertebereichen)
max bzw. min: berechnen den größten bzw. kleinsten Wert einer
Spalte
Schallehn
Datenmanagement
Sommersemester 2017
7–45
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen /2
Argumente einer Aggregatfunktion:
I
I
I
ein Attribut der durch die from-Klausel spezifizierten Relation,
ein gültiger skalarer Ausdruck oder
im Falle der count-Funktion auch das Symbol ∗
Schallehn
Datenmanagement
Sommersemester 2017
7–46
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen /3
vor dem Argument (außer im Fall von count(∗)) optional auch die
Schlüsselwörter distinct oder all
I
I
I
distinct: vor Anwendung der Aggregatfunktion werden doppelte
Werte aus der Menge von Werten, auf die die Funktion
angewendet wird
all: Duplikate gehen mit in die Berechnung ein
(Default-Voreinstellung)
Nullwerte werden in jedem Fall vor Anwendung der Funktion aus
der Wertemenge eliminiert (außer im Fall von count(∗))
Schallehn
Datenmanagement
Sommersemester 2017
7–47
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen - Beispiele
Anzahl der Weine:
select count(*) as Anzahl
from WEINE
ergibt
Anzahl
7
Schallehn
Datenmanagement
Sommersemester 2017
7–48
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen - Beispiele /2
Anzahl der verschiedenen Weinregionen:
select count(distinct Region)
from ERZEUGER
Weine, die älter als der Durchschnitt sind:
select Name, Jahrgang
from WEINE
where Jahrgang < (select avg(Jahrgang)
from WEINE)
alle Weingüter, die nur einen Wein liefern:
select * from ERZEUGER e
where 1 = ( select count(*) from WEINE w
where w.Weingut = e.Weingut)
Schallehn
Datenmanagement
Sommersemester 2017
7–49
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen /2
Schachtelung von Aggregatfunktionen nicht erlaubt
select f1 (f2 (A)) as Ergebnis
from R ...
-- (falsch!)
mögliche Formulierung:
select f1 (Temp) as Ergebnis
from ( select f2 (A) as Temp from R ...)
Schallehn
Datenmanagement
Sommersemester 2017
7–50
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Aggregatfunktionen in where-Klausel
Aggregatfunktionen liefern nur einen Wert
Einsatz in
Konstanten-Selektionen der where-Klausel möglich
alle Weingüter, die nur einen Wein liefern:
select * from ERZEUGER e
where 1 = (
select count(*) from WEINE w
where w.Weingut = e.Weingut)
Schallehn
Datenmanagement
Sommersemester 2017
7–51
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
group by und having
Notation
select ...
from ...
[where ...]
[group by attributliste ]
[having bedingung ]
Schallehn
Datenmanagement
Sommersemester 2017
7–52
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Gruppierung: Schema
Relation REL:
A
B
C
D
1
1
2
3
3
2
2
3
3
3
3
4
3
4
6
4
5
4
5
7
...
Anfrage:
select A, sum(D) from REL where ...
group by A, B
having A<4 and sum(D)<10 and max(C)=4
Schallehn
Datenmanagement
Sommersemester 2017
7–53
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Gruppierung: Schritt 1
from und where
A
1
1
2
3
3
B
2
2
3
3
3
C
3
4
3
4
6
D
4
5
4
5
7
à
...
Schallehn
Datenmanagement
A
1
1
2
3
3
B
2
2
3
3
3
C
3
4
3
4
6
D
4
5
4
5
7
Sommersemester 2017
7–54
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Gruppierung: Schritt 2
group by A, B
A
1
1
2
3
3
B
2
2
3
3
3
Schallehn
C
3
4
3
4
6
D
4
5
4
5
7
A
à
Datenmanagement
B
1
2
2
3
3
3
N
C
3
4
3
4
6
D
4
5
4
5
7
Sommersemester 2017
7–55
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Gruppierung: Schritt 3
select A, sum(D)
A
B
1
2
2
3
3
3
Schallehn
N
C
3
4
3
4
6
A
D
4
5
4
5
7
à
Datenmanagement
N
sum(D)
1
9
2
3
4
12
C
3
4
3
4
6
D
4
5
4
5
7
Sommersemester 2017
7–56
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Gruppierung: Schritt 4
having A<4 and sum(D)<10 and max(C)=4
A
N
sum(D)
1
9
2
3
4
12
Schallehn
C
3
4
3
4
6
D
4
5
4
5
7
à
Datenmanagement
A
1
sum(D)
9
Sommersemester 2017
7–57
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Gruppierung - Beispiel
Anzahl der Rot- und Weißweine:
select Farbe, count(*) as Anzahl
from WEINE
group by Farbe
Ergebnisrelation:
Farbe
Rot
Weiß
Schallehn
Anzahl
5
2
Datenmanagement
Sommersemester 2017
7–58
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
having - Beispiel
Regionen mit mehr als einem Wein
select Region, count(*) as Anzahl
from ERZEUGER natural join WEINE
group by Region
having count(*) > 1
Schallehn
Datenmanagement
Sommersemester 2017
7–59
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Attribute für Aggregation bzw. having
zulässige Attribute hinter select bei Gruppierung auf Relation
mit Schema R
I
I
Gruppierungsattribute G
Aggregationen auf Nicht-Gruppierungsattributen R − G
zulässige Attribute für having
I
dito
Schallehn
Datenmanagement
Sommersemester 2017
7–60
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Äußere Verbunde
zusätzlich zu klassischen Verbund (inner join): in SQL-92
auch äußerer Verbund
Übernahme von „dangling tuples“ in das
Ergebnis und Auffüllen mit Nullwerten
outer join übernimmt alle Tupel beider Operanden
(Langfassung: full outer join)
left outer join bzw. right outer join übernimmt alle
Tupel des linken bzw. des rechten Operanden
äußerer natürlicher Verbund jeweils mit Schlüsselwort natural,
also z.B. natural left outer join
Schallehn
Datenmanagement
Sommersemester 2017
7–61
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Äußere Verbunde /2
LINKS A
1
2
B
2
3
OUTER A
1
2
⊥
B
2
3
4
Schallehn
C
⊥
4
5
RECHTS B
3
4
C
4
5
LEFT A
1
2
B
2
3
Datenmanagement
C
⊥
4
NATURAL JOIN A
2
B
3
C
4
RIGHT A
2
⊥
B
3
4
C
4
5
Sommersemester 2017
7–62
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Äußerer Verbund: Beispiel
select Anbaugebiet, count(WeinID) as Anzahl
from ERZEUGER natural left outer join WEINE
group by Anbaubebiet
Anbaugebiet
Barossa Valley
Napa Valley
Saint-Emilion
Pomerol
Rheingau
Schallehn
Anzahl
2
3
1
0
1
Datenmanagement
Sommersemester 2017
7–63
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Simulation des äußeren Verbundes
linker äußerer Verbund
select *
from ERZEUGER natural join WEINE
union all
select ERZEUGER.*, cast(null as int),
cast(null as varchar(20)),
cast(null as varchar(10)),
cast(null as int),
cast(null as varchar(20))
from ERZEUGER e
where not exists (
select *
from WEINE
where WEINE.Weingut = e.Weingut)
Schallehn
Datenmanagement
Sommersemester 2017
7–64
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Sortierung mit order by
Notation
order by attributliste
Beispiel:
select *
from WEINE
order by Jahrgang
Sortierung aufsteigend (asc) oder absteigend (desc)
Sortierung als letzte Operation einer Anfrage
muss in der select-Klausel vorkommen
Schallehn
Datenmanagement
Sortierattribut
Sommersemester 2017
7–65
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Sortierung /2
Sortierung auch mit berechneten Attributen (Aggregaten) als
Sortierkriterium
select Weingut, count(*) as Anzahl
from ERZEUGER natural join WEINE
group by Weingut
order by Anzahl desc
Schallehn
Datenmanagement
Sommersemester 2017
7–66
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Sortierung: Top-k-Anfragen
Anfrage, die die besten k Elemente bzgl. einer Rangfunktion liefert
select w1.Name, count(*) as Rang
from WEINE w1, WEINE w2
where w1.Jahrgang <= w2.Jahrgang
group by w1.Name, w1.WeinID
having count(*) <= 4
order by Rang
Name
Zinfandel
Creek Shiraz
Chardonnay
Pinot Noir
Schallehn
-----
Schritt
Schritt
Schritt
Schritt
1
2
3
4
Rang
1
2
3
4
Datenmanagement
Sommersemester 2017
7–67
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Sortierung: Top-k-Anfragen
Ermittlung der k = 4 jüngste Weine
Erläuterung
I
I
I
I
Schritt 1: Zuordnung aller Weine die älter sind
Schritt 2: Gruppierung nach Namen, Berechnung des Rangs
Schritt 3: Beschränkung auf Ränge ≤ 4
Schritt 4: Sortierung nach Rang
Schallehn
Datenmanagement
Sommersemester 2017
7–68
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Behandlung von Nullwerten
skalare Ausdrücke: Ergebnis null, sobald Nullwert in die
Berechnung eingeht
in allen Aggregatfunktionen bis auf count(∗) werden Nullwerte
vor Anwendung der Funktion entfernt
fast alle Vergleiche mit Nullwert ergeben Wahrheitswert unknown
(statt true oder false)
Ausnahme: is null ergibt true, is not null ergibt false
Boolesche Ausdrücke basieren dann auf dreiwertiger Logik
Schallehn
Datenmanagement
Sommersemester 2017
7–69
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Behandlung von Nullwerten /2
and
true
unknown
false
or
true
unknown
false
true
true
unknown
false
true
true
true
true
not
true
unknown
false
Schallehn
unknown
unknown
unknown
false
unknown
true
unknown
unknown
false
false
false
false
false
true
unknown
false
false
unknown
true
Datenmanagement
Sommersemester 2017
7–70
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Selektionen nach Nullwerten
Null-Selektion wählt Tupel aus, die bei einem bestimmten Attribut
Nullwerte enthalten
Notation
attribut is null
Beispiel
select * from ERZEUGER
where Anbaugebiet is null
Schallehn
Datenmanagement
Sommersemester 2017
7–71
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
SQL-Versionen
Geschichte
I
I
I
I
I
I
I
I
SEQUEL (1974, IBM Research Labs San Jose)
SEQUEL2 (1976, IBM Research Labs San Jose)
SQL (1982, IBM)
ANSI-SQL (SQL-86; 1986)
ISO-SQL (SQL-89; 1989; drei Sprachen Level 1, Level 2, + IEF)
(ANSI / ISO) SQL2 (als SQL-92 verabschiedet)
(ANSI / ISO) SQL3 (als SQL:1999 verabschiedet)
Seitdem: SQL:2003, SQL:2006, SQL:2008, SQL:2011
trotz Standardisierung: teilweise Inkompatibilitäten zwischen
Systemen der einzelnen Hersteller
Schallehn
Datenmanagement
Sommersemester 2017
7–72
SQL als relationale Anfragesprache
Erweiterungen des SFW-Blocks
Zusammenfassung
SQL als Standardsprache
SQL-Kern mit Bezug zur Relationenalgebra
Erweiterungen
Schallehn
Datenmanagement
Sommersemester 2017
7–73
Teil VIII
Programmierung von
Datenbankanwendungen
Programmierung von Datenbankanwendungen
Programmierung von Datenbankanwendungen
1
Grundkonzepte der Programmiersprachenanbindung
Schallehn
Datenmanagement
Sommersemester 2017
8–1
Programmierung von Datenbankanwendungen
Programmierung von Datenbankanwendungen
1
Grundkonzepte der Programmiersprachenanbindung
2
JDBC als Call Level Interface
Schallehn
Datenmanagement
Sommersemester 2017
8–1
Programmierung von Datenbankanwendungen
Programmierung von Datenbankanwendungen
1
Grundkonzepte der Programmiersprachenanbindung
2
JDBC als Call Level Interface
3
Eingebettetes SQL mit SQLJ und LINQ
Schallehn
Datenmanagement
Sommersemester 2017
8–1
Programmierung von Datenbankanwendungen
Grundkonzepte der Programmiersprachenanbindung
Grundkonzepte der Programmiersprachenanbindung
Kopplungsarten:
I
prozedurale oder CALL-Schnittstellen (call level interface)
F
I
F
F
F
I
Beispiele: SQL/CLI, ODBC, JDBC, . . .
Einbettung einer DB-Sprache in Programmiersprachen
statische Einbettung: Vorübersetzer-Prinzip
SQL-Anweisungen zur Übersetzungszeit festgelegt
Beispiele: Embedded SQL, SQLJ
dynamische Einbettung:
Konstruktion von SQL-Anweisungen zur Laufzeit
Spracherweiterungen und neue Sprachentwicklungen
F
Schallehn
Beispiele: SQL/PSM, PL/SQL, Transact-SQL, PL/pgSQL
Datenmanagement
Sommersemester 2017
8–2
Programmierung von Datenbankanwendungen
Grundkonzepte der Programmiersprachenanbindung
Cursor-Konzept
Cursor: Iterator über Liste von Tupeln (Anfrageergebnis)
Anwendungsprogramm
Datenbank
Relation
Cursor
Schallehn
Datenmanagement
Sommersemester 2017
8–3
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Überblick
Datenbankzugriffsschnittstelle für Java
abstrakte, datenbankneutrale Schnittstelle
vergleichbar mit ODBC
Low-Level-API: direkte Nutzung von SQL
Java-Package java.sql
I
I
I
I
DriverManager: Einstiegspunkt, Laden von Treibern
Connection: Datenbankverbindung
Statement: Ausführung von Anweisungen über eine Verbindung
ResultSet: verwaltet Ergebnisse einer Anfrage, Zugriff auf
einzelne Spalten
Schallehn
Datenmanagement
Sommersemester 2017
8–4
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Struktur
DriverManager
getConnection
Connection
createStatement
Statement
Statement
executeQuery
ResultSet
Schallehn
Datenmanagement
ResultSet
Sommersemester 2017
8–5
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Treiberkonzept
JavaApplikation
JDBC-API
JDBCTreibermanager
NativeProtokollTreiber
JDBCNetTreiber
JDBCODBCBridge
NativeAPITreiber
DBMiddleware
ODBC
ClientBibliothek
ClientBibliothek
Schallehn
Datenmanagement
Sommersemester 2017
8–6
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Ablauf
1
Aufbau einer Verbindung zur Datenbank
I
I
2
Senden einer SQL-Anweisung
I
I
3
Angabe der Verbindungsinformationen
Auswahl und Laden des Treibers
Definition der Anweisung
Belegung von Parametern
Verarbeiten der Anfrageergebnisse
I
I
Navigation über Ergebnisrelation
Zugriff auf Spalten
Schallehn
Datenmanagement
Sommersemester 2017
8–7
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Verbindungsaufbau
1
Treiber laden
Class.forName ("com.company.DBDriver");
2
Verbindung herstellen
Connection con;
String url = "jdbc:subprotocol:datasource";
con = DriverManager.getConnection
(url, "scott", "tiger");
JDBC-URL spezifiziert
Datenquelle/Datenbank
Verbindungsmechanismus (Protokoll, Server und Port)
Schallehn
Datenmanagement
Sommersemester 2017
8–8
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Anfrageausführung
1
Anweisungsobjekt (Statement) erzeugen
Statement stmt = con.createStatement();
2
Anweisung ausführen
String query =
"select Name, Jahrgang from WEINE";
ResultSet rset = stmt.executeQuery (query);
Klasse java.sql.Statement
Ausführung von Anfragen (SELECT) mit executeQuery
Ausführung von Änderungsanweisungen (DELETE, INSERT,
UPDATE) mit executeUpdate
Schallehn
Datenmanagement
Sommersemester 2017
8–9
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Ergebnisverarbeitung
1
Navigation über Ergebnismenge (Cursor-Prinzip)
while (rset.next()) {
// Verarbeitung der einzelnen Tupel
...
}
2
Zugriff auf Spaltenwerte über getType-Methoden
I
über Spaltenindex
String wname = rset.getString(1);
I
über Spaltenname
String wname = rset.getString("Name");
Schallehn
Datenmanagement
Sommersemester 2017
8–10
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Fehlerbehandlung
Fehlerbehandlung mittels Exception-Mechanismus
SQLException für alle SQL- und DBMS-Fehler
try {
// Aufruf von JDBC-Methoden
...
} catch (SQLException exc) {
System.out.println("SQLException: "+
exc.getMessage());
}
Schallehn
Datenmanagement
Sommersemester 2017
8–11
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Änderungsoperationen
DDL- und DML-Operationen mittels executeUpdate
liefert Anzahl der betroffenen Zeilen (für DML-Operationen)
Statement stmt = con.createStatement();
int rows = stmt.executeUpdate(
"update WEINE set Preis = Preis * 1.1 " +
"where Jahrgang < 2000");
Schallehn
Datenmanagement
Sommersemester 2017
8–12
Programmierung von Datenbankanwendungen
JDBC als Call Level Interface
JDBC: Transaktionssteuerung
Methoden von Connection
I
I
commit ()
rollback ()
Auto-Commit-Modus
I
I
I
implizites Commit nach jeder Anweisung
Transaktion besteht nur aus einer Anweisung
Umschalten mittels setAutoCommit (boolean)
Schallehn
Datenmanagement
Sommersemester 2017
8–13
Programmierung von Datenbankanwendungen
Eingebettetes SQL mit SQLJ und LINQ
SQLJ: Embedded SQL für Java
Einbettung von SQL-Anweisungen in Java-Quelltext
Vorübersetzung des erweiterten Quelltextes in echten Java-Code
durch Translator sqlj
Überprüfung der SQL-Anweisungen
I
I
I
korrekte Syntax
Übereinstimmung der Anweisungen mit DB-Schema
Typkompatibilität der für Datenaustausch genutzten Variablen
Nutzung von JDBC-Treibern
Schallehn
Datenmanagement
Sommersemester 2017
8–14
Programmierung von Datenbankanwendungen
Eingebettetes SQL mit SQLJ und LINQ
SQLJ: Prinzip
SQLJ-Programm
Syntax- & Semantikprüfung
SQLJ-Translator
Java-Quellcode
SQLJ-Profile
Java-Compiler
Customizer
Bytecode
Custom-Profile
SQLJ-Laufzeitsystem
JDBC-Treiber
Schallehn
Datenmanagement
Sommersemester 2017
8–15
Programmierung von Datenbankanwendungen
Eingebettetes SQL mit SQLJ und LINQ
SQLJ-Anweisungen
Kennzeichnung durch #sql Deklarationen
Klassendefinitionen für Iteratoren
SQL-Anweisungen: Anfragen, DML- und DDL-Anweisungen
#sql { SQL-Operation };
Beispiel:
#sql { insert into ERZEUGER (Weingut, Region) values
( ’Wairau Hills’, ’Marlborough’) };
Schallehn
Datenmanagement
Sommersemester 2017
8–16
Programmierung von Datenbankanwendungen
Eingebettetes SQL mit SQLJ und LINQ
Host-Variablen
Variablen einer Host-Sprache (hier Java), die in
SQL-Anweisungen auftreten können
Verwendung: Austausch von Daten zwischen Host-Sprache und
SQL
Kennzeichnung durch ":variable"
Beispiel:
String name;
int weinID = 4711;
#sql { select Name into :name
from WEINE where WeinID = :weinID };
System.out.println("Wein = " + name);
Schallehn
Datenmanagement
Sommersemester 2017
8–17
Programmierung von Datenbankanwendungen
Eingebettetes SQL mit SQLJ und LINQ
Iteratoren
1
Deklaration des Iterators
#sql public iterator WeinIter (String Name, String Weingut,
int Jahrgang);
2
Definition des Iteratorobjektes
WeinIter iter;
3
Ausführung der Anweisung
#sql iter = { select Name, Weingut, Jahrgang from WEINE };
4
Navigation
while (iter.next()) {
System.out.println(iter.Name() + " "+
iter.Weingut() + " "+ iter.Jahrgang());
}
Schallehn
Datenmanagement
Sommersemester 2017
8–18
Programmierung von Datenbankanwendungen
Eingebettetes SQL mit SQLJ und LINQ
Dynamic SQL
SQL-Statements als zur Laufzeit konstruierte Strings
exec sql begin declare section;
AnfrageString char(256) varying;
exec sql end declare section;
exec sql declare AnfrageObjekt statement;
AnfrageString =
’delete from WEINE where WeinID = 4711’;
...
exec sql prepare AnfrageObjekt from :AnfrageString;
exec sql execute AnfrageObjekt;
Schallehn
Datenmanagement
Sommersemester 2017
8–19
Programmierung von Datenbankanwendungen
Eingebettetes SQL mit SQLJ und LINQ
Language Integrated Query (LINQ)
Einbettung einer DB-Sprache (SQL) in eine Programmiersprache
(C#)
spezielle Klassenmethoden
IEnumerable<string> res = weine
.Where(w => w.Farbe = "Rot")
.Select(w => new { w.Name });
eigene Sprachkonstrukte (ab C# 3.0)
IEnumerable<op> res = from w in weine
where w.Farbe = "Rot"
select new { w.Name };
Schallehn
Datenmanagement
Sommersemester 2017
8–20
Teil IX
Transaktionen, Integrität und Trigger
Transaktionen, Integrität und Trigger
Transaktionen, Integrität und Trigger
1
Grundbegriffe
Schallehn
Datenmanagement
Sommersemester 2017
9–1
Transaktionen, Integrität und Trigger
Transaktionen, Integrität und Trigger
1
Grundbegriffe
2
Transaktionsbegriff
Schallehn
Datenmanagement
Sommersemester 2017
9–1
Transaktionen, Integrität und Trigger
Transaktionen, Integrität und Trigger
1
Grundbegriffe
2
Transaktionsbegriff
3
Transaktionen in SQL
Schallehn
Datenmanagement
Sommersemester 2017
9–1
Transaktionen, Integrität und Trigger
Transaktionen, Integrität und Trigger
1
Grundbegriffe
2
Transaktionsbegriff
3
Transaktionen in SQL
4
Integritätsbedingungen in SQL
Schallehn
Datenmanagement
Sommersemester 2017
9–1
Transaktionen, Integrität und Trigger
Transaktionen, Integrität und Trigger
1
Grundbegriffe
2
Transaktionsbegriff
3
Transaktionen in SQL
4
Integritätsbedingungen in SQL
5
Trigger
Schallehn
Datenmanagement
Sommersemester 2017
9–1
Transaktionen, Integrität und Trigger
Grundbegriffe
Integrität
Integritätsbedingung (engl. integrity constraint oder assertion):
Bedingung für die „Zulässigkeit“ oder „Korrektheit“
in Bezug auf Datenbanken:
I
I
I
(einzelne) Datenbankzustände,
Zustandsübergänge vom alten in den neuen Datenbankzustand,
langfristige Datenbankentwicklungen
Schallehn
Datenmanagement
Sommersemester 2017
9–2
Transaktionen, Integrität und Trigger
Grundbegriffe
Inhärente Integritätsbedingungen im RM
1
Typintegrität:
I
I
2
Schlüsselintegrität:
I
3
SQL erlaubt Angabe von Wertebereichen zu Attributen
Erlauben oder Verbieten von Nullwerten
Angabe eines Schlüssels für eine Relation
Referentielle Integrität:
I
die Angabe von Fremdschlüsseln
Schallehn
Datenmanagement
Sommersemester 2017
9–3
Transaktionen, Integrität und Trigger
Transaktionsbegriff
Szenarien für Integritätsprobleme
Platzreservierung für Flüge gleichzeitig aus vielen Reisebüros
→ Platz könnte mehrfach verkauft werden, wenn mehrere
Reisebüros den Platz als verfügbar identifizieren
überschneidende Kontooperationen einer Bank
statistische Datenbankoperationen
→ Ergebnisse sind verfälscht, wenn während der Berechnung
Daten geändert werden
Schallehn
Datenmanagement
Sommersemester 2017
9–4
Transaktionen, Integrität und Trigger
Transaktionsbegriff
Transaktion
Eine Transaktion ist eine Folge von Operationen (Aktionen), die die
Datenbank von einem konsistenten Zustand in einen konsistenten,
eventuell veränderten, Zustand überführt, wobei das ACID-Prinzip
eingehalten werden muss.
Aspekte:
I
I
Semantische Integrität: Korrekter (konsistenter) DB-Zustand nach
Ende der Transaktion
Ablaufintegrität: Fehler durch „gleichzeitigen“ Zugriff mehrerer
Benutzer auf dieselben Daten vermeiden
Schallehn
Datenmanagement
Sommersemester 2017
9–5
Transaktionen, Integrität und Trigger
Transaktionsbegriff
ACID-Eigenschaften
Atomicity (Atomarität):
Transaktion wird entweder ganz oder gar nicht ausgeführt
Consistency (Konsistenz oder auch Integritätserhaltung):
Datenbank ist vor Beginn und nach Beendigung einer Transaktion
jeweils in einem konsistenten Zustand
Isolation (Isolation):
Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck
haben, dass er mit dieser Datenbank alleine arbeitet
Durability (Dauerhaftigkeit / Persistenz):
nach erfolgreichem Abschluss einer Transaktion muss das
Ergebnis dieser Transaktion „dauerhaft“ in der Datenbank
gespeichert werden
Schallehn
Datenmanagement
Sommersemester 2017
9–6
Transaktionen, Integrität und Trigger
Transaktionsbegriff
Kommandos einer Transaktionssprache
Beginn einer Transaktion: Begin-of-Transaction-Kommando BOT
(in SQL implizit!)
commit: die Transaktion soll erfolgreich beendet werden
abort: die Transaktion soll abgebrochen werden
Schallehn
Datenmanagement
Sommersemester 2017
9–7
Transaktionen, Integrität und Trigger
Transaktionsbegriff
Transaktion: Integritätsverletzung
Beispiel:
I
I
Übertragung eines Betrages B von einem Haushaltsposten K1 auf
einen anderen Posten K2
Bedingung: Summe der Kontostände der Haushaltsposten bleibt
konstant
vereinfachte Notation
Transfer = < K1:=K1-B; K2:=K2+B >;
Realisierung in SQL: als Sequenz zweier elementarer
Änderungen
Bedingung ist zwischen den einzelnen
Änderungsschritten nicht unbedingt erfüllt!
Schallehn
Datenmanagement
Sommersemester 2017
9–8
Transaktionen, Integrität und Trigger
Transaktionsbegriff
Transaktion: Verhalten bei Systemabsturz
Fehler
T1
T2
T3
T4
T5
Zeit
tf
Schallehn
Datenmanagement
Sommersemester 2017
9–9
Transaktionen, Integrität und Trigger
Transaktionsbegriff
Transaktion: Verhalten bei Systemabsturz /2
Folgen:
I
Inhalt des flüchtigen Speichers zum Zeitpunkt tf ist unbrauchbar →
Transaktionen in unterschiedlicher Weise davon betroffen
Transaktionszustände:
I
I
zum Fehlerzeitpunkt noch aktive Transaktionen (T2 und T4 )
bereits vor dem Fehlerzeitpunkt beendete Transaktionen (T1 , T3
und T5 )
Schallehn
Datenmanagement
Sommersemester 2017
9–10
Transaktionen, Integrität und Trigger
Transaktionsbegriff
Probleme im Mehrbenutzerbetrieb
Inkonsistentes Lesen (Nonrepeatable Read): bei wiederholtem
Lesen würde eine inzwischen von einer anderen Transaktion
geänderter Wert gelesen
Abhängigkeiten von nicht freigegebenen Daten (Dirty Read):
gelesen Daten, die von einer anderen Transaktion geändert
wurden, werde durch einen Abbruch dieser evtl. zurückgesetzt
Das Phantom-Problem: eine andere Transaktion fügt neue Tupel
ein oder löscht diese
Verlorengegangenes Ändern (Lost Update): eine Transaktion
überschreibt Änderungen einer anderen
Schallehn
Datenmanagement
Sommersemester 2017
9–11
Transaktionen, Integrität und Trigger
Transaktionen in SQL
Transaktionen in SQL-DBS
Aufweichung von ACID in SQL: Isolationsebenen
set transaction
[ { read only | read write }, ]
[isolation level
{ read uncommitted |
read committed |
repeatable read |
serializable }, ]
[ diagnostics size ...]
Standardeinstellung:
set transaction read write,
isolation level serializable
Schallehn
Datenmanagement
Sommersemester 2017
9–12
Transaktionen, Integrität und Trigger
Transaktionen in SQL
Bedeutung der Isolationsebenen
read uncommitted
I
I
I
schwächste Stufe: Zugriff auf nicht geschriebene Daten, nur für
read only Transaktionen
statistische und ähnliche Transaktionen (ungefährer Überblick, nicht
korrekte Werte)
keine Sperren → effizient ausführbar, keine anderen Transaktionen
werden behindert
read committed
I
nur Lesen endgültig geschriebener Werte, aber nonrepeatable read
möglich
repeatable read
I
kein nonrepeatable read, aber Phantomproblem kann auftreten
serializable
I
garantierte Serialisierbarkeit (Ergebnis äquivalent zu einer
nicht-parallelen Ausführung der Transaktionen)
Schallehn
Datenmanagement
Sommersemester 2017
9–13
Transaktionen, Integrität und Trigger
Integritätsbedingungen in SQL
Integritätsbedingungen in SQL-DDL
not null: Nullwerte verboten
default: Angabe von Default-Werten
check ( search-condition ): Attributspezifische Bedingung
(in der Regel Ein-Tupel-Integritätsbedingung)
primary key: Angabe eines Primärschlüssel
foreign key ( Attribut(e))
references Tabelle( Attribut(e) ):
Angabe der referentiellen Integrität
Schallehn
Datenmanagement
Sommersemester 2017
9–14
Transaktionen, Integrität und Trigger
Integritätsbedingungen in SQL
Integritätsbedingungen: Wertebereiche
create domain: Festlegung eines benutzerdefinierten
Wertebereichs
Beispiel
create domain WeinFarbe varchar(4)
default ’Rot’
check (value in (’Rot’, ’Weiß’, ’Rose’))
Anwendung
create table WEINE (
WeinID int primary key,
Name varchar(20) not null,
Farbe WeinFarbe,
...)
Schallehn
Datenmanagement
Sommersemester 2017
9–15
Transaktionen, Integrität und Trigger
Integritätsbedingungen in SQL
Integritätsbedingungen: check-Klausel
check: Festlegung weitere lokale Integritätsbedingungen
innerhalb der zu definierenden Wertebereiche, Attribute und
Relationenschemata
Beispiel: Einschränkung der zulässigen Werte
Anwendung
create table WEINE (
WeinID int primary key,
Name varchar(20) not null,
Jahr int check(Jahr between 1980 and 2010),
...
)
Schallehn
Datenmanagement
Sommersemester 2017
9–16
Transaktionen, Integrität und Trigger
Integritätsbedingungen in SQL
Überprüfungsmodi von Bedingungen
on update | delete
Angabe eines Auslöseereignisses, das die Überprüfung der
Bedingung anstößt
cascade | set null | set default | no action
Kaskadierung: Behandlung einiger Integritätsverletzungen pflanzt
sich über mehrere Stufen fort, z.B. Löschen als Reaktion auf
Verletzung der referentieller Integrität
deferred | immediate legt Überprüfungszeitpunkt für eine
Bedingung fest
I
I
deferred: Zurückstellen an das Ende der Transaktion
immediate: sofortige Prüfung bei jeder relevanten
Datenbankänderung
Schallehn
Datenmanagement
Sommersemester 2017
9–17
Transaktionen, Integrität und Trigger
Integritätsbedingungen in SQL
Überprüfungsmodi: Beispiel
Kaskadierendes Löschen
create table WEINE (
WeinID int primary key,
Name varchar(50) not null,
Preis float not null,
Jahr int not null,
Weingut varchar(30),
foreign key (Weingut) references ERZEUGER (Weing
on delete cascade)
Schallehn
Datenmanagement
Sommersemester 2017
9–18
Transaktionen, Integrität und Trigger
Integritätsbedingungen in SQL
Die assertion-Klausel
Assertion: Prädikat, das eine Bedingung ausdrückt, die von der
Datenbank immer erfüllt sein muss
Syntax (SQL:2003)
create assertion name check ( prädikat )
Beispiele:
create assertion Preise check
( ( select sum (Preis)
from WEINE) < 10000 )
create assertion Preise2 check
( not exists (
select * from WEINE where Preis > 200) )
Schallehn
Datenmanagement
Sommersemester 2017
9–19
Transaktionen, Integrität und Trigger
Trigger
Trigger
Trigger: Anweisung/Prozedur, die bei Eintreten eines bestimmten
Ereignisses automatisch vom DBMS ausgeführt wird
Anwendung:
I
I
I
Erzwingen von Integritätsbedingungen („Implementierung“ von
Integritätsregeln)
Auditing von DB-Aktionen
Propagierung von DB-Änderungen
Schallehn
Datenmanagement
Sommersemester 2017
9–20
Transaktionen, Integrität und Trigger
Trigger
Trigger: Entwurf und Implementierung
Spezifikation von
I
I
Ereignis und Bedingung für Aktivierung des Triggers
Aktion(en) zur Ausführung
Syntax in SQL:2003 festgelegt
verfügbar in den meisten kommerziellen Systemen (aber mit
anderer Syntax)
Schallehn
Datenmanagement
Sommersemester 2017
9–21
Transaktionen, Integrität und Trigger
Trigger
SQL:2003-Trigger
Syntax:
create trigger <Name: >
after | before <Ereignis>
on <Relation>
[ when <Bedingung> ]
begin atomic < SQL-Anweisungen > end
Ereignis:
I
I
I
insert
update [ of <Liste von Attributen> ]
delete
Schallehn
Datenmanagement
Sommersemester 2017
9–22
Transaktionen, Integrität und Trigger
Trigger
Weitere Angaben bei Triggern
for each row bzw. for each statement: Aktivierung des
Triggers für jede Einzeländerungen einer mengenwertigen
Änderung oder nur einmal für die gesamte Änderung
before bzw. after: Aktivierung vor oder nach der Änderung
referencing new as bzw. referencing old as: Binden
einer Tupelvariable an die neu eingefügten bzw. gerade
gelöschten („alten’“) Tupel einer Relation
Tupel der Differenzrelationen
Schallehn
Datenmanagement
Sommersemester 2017
9–23
Transaktionen, Integrität und Trigger
Trigger
Beispiel für Trigger
Kein Kundenkonto darf unter 0 absinken:
create trigger bad_account
after update of Kto on KUNDE
referencing new as INSERTED
when (exists
(select * from INSERTED where Kto < 0)
)
begin atomic
rollback;
end
ähnlicher Trigger für insert
Schallehn
Datenmanagement
Sommersemester 2017
9–24
Transaktionen, Integrität und Trigger
Trigger
Beispiel für Trigger /2
Erzeuger müssen gelöscht werden, wenn sie keine Weine mehr
anbieten:
create trigger unnützes_Weingut
after delete on WEINE
referencing old as O
for each row
when (not exists
(select * from WEINE W
where W.Weingut = O.Weingut))
begin atomic
delete from ERZEUGER where Weingut = O.Weingut;
end
Schallehn
Datenmanagement
Sommersemester 2017
9–25
Transaktionen, Integrität und Trigger
Trigger
Integritätssicherung durch Trigger
1. Bestimme Objekt oi , für das die Bedingung φ überwacht werden
soll
I
I
i.d.R. mehrere oi betrachten, wenn Bedingung
relationsübergreifend ist
Kandidaten für oi sind Tupel der Relationsnamen, die in φ
auftauchen
2. Bestimme die elementaren Datenbankänderungen uij auf
Objekten oi , die φ verletzen können
I
Regeln: z.B. Existenzforderungen beim Löschen und Ändern
prüfen, jedoch nicht beim Einfügen etc.
Schallehn
Datenmanagement
Sommersemester 2017
9–26
Transaktionen, Integrität und Trigger
Trigger
Integritätssicherung durch Trigger /2
3. Bestimme je nach Anwendung die Reaktion ri auf
Integritätsverletzung
I
I
Rücksetzen der Transaktion (rollback)
korrigierende Datenbankänderungen
4. Formuliere folgende Trigger:
create trigger t-phi-ij after uij on oi
when ¬φ
begin ri end
5. Wenn möglich, vereinfache entstandenen Trigger
Schallehn
Datenmanagement
Sommersemester 2017
9–27
Transaktionen, Integrität und Trigger
Trigger
Trigger in Oracle
Implementierung in PL/SQL
Notation
create [ or replace ] trigger trigger-name
before | after
insert or update [ of spalten ]
or delete on tabelle
[ for each row
[ when ( prädikat ) ] ]
PL/SQL-Block
Schallehn
Datenmanagement
Sommersemester 2017
9–28
Transaktionen, Integrität und Trigger
Trigger
Trigger in Oracle: Arten
Anweisungsebene (statement level trigger): Trigger wird ausgelöst
vor bzw. nach der DML-Anweisung
Tupelebene (row level trigger): Trigger wird vor bzw. nach jeder
einzelnen Modifikation ausgelöst (one tuple at a time)
Trigger auf Tupelebene:
Prädikat zur Einschränkung (when)
Zugriff auf altes (:old.col) bzw. neues (:new.col) Tupel
I
I
I
für delete: nur (:old.col)
für insert: nur (:new.col)
in when-Klausel nur (new.col) bzw. (old.col)
Schallehn
Datenmanagement
Sommersemester 2017
9–29
Transaktionen, Integrität und Trigger
Trigger
Trigger in Oracle /2
Transaktionsabbruch durch
raise_application_error(code, message)
Unterscheidung der Art der DML-Anweisung
if deleting then ... end if;
if updating then ... end if;
if inserting then ... end if;
Schallehn
Datenmanagement
Sommersemester 2017
9–30
Transaktionen, Integrität und Trigger
Trigger
Trigger in Oracle: Beispiel
Kein Kundenkonto darf unter 0 absinken:
create or replace trigger bad_account
after insert or update of Kto on KUNDE
for each row
when (:new.Kto < 0)
begin
raise_application_error(-20221,
’Nicht unter 0’);
end;
Schallehn
Datenmanagement
Sommersemester 2017
9–31
Transaktionen, Integrität und Trigger
Trigger
Zusammenfassung
Zusicherung von Korrektheit bzw. Integrität der Daten
inhärente Integritätsbedingungen des Relationenmodells
zusätzliche SQL-Integritätsbedingungen: check-Klausel,
assertion-Anweisung
Trigger zur „Implementierung“ von Integritätsbedingungen bzw.
-regeln
Schallehn
Datenmanagement
Sommersemester 2017
9–32