Datenmanagement
Dr.-Ing. Eike Schallehn
Universität MagdeburgInstitut für Technische & Betriebliche Informationssysteme
Sommersemester 2019
Schallehn Datenmanagement Sommersemester 2019 0–1
Quellen der Vorlesung
Hauptverantwortliche (siehe Literatur):
Gunter SaakeAndreas HeuerKai-Uwe Sattler
Weiterer Input von:
Ingo SchmidtThomas LeichHolger MeyerEike Schallehn
Schallehn Datenmanagement Sommersemester 2019 0–2
Einführung
Organisatorisches: Magdeburg
Dozent: Eike SchallehnInfos (Zeiten, Räume) & Folienkopien unter
I http://wwwiti.cs.uni-magdeburg.de/→ Datenbanken→ LehreI LSF
Prüfung/ ScheinI Klausur: Zulassung nach bestandener Übung (Übungsschein)I Schein: siehe Klausur mit Note <= 4.0
Feedback, Fragen, . . .I 1. Nach der Vorlesung oder ÜbungI 2. Mail: [email protected] ; Betreff: DatenmanagementI 3. Telefon: 0391/67-52845
Schallehn Datenmanagement Sommersemester 2019 0–3
Einführung
Organisatorisches: Magdeburg – Übungen
Übungsleiter: (David Broneske), Paul Blockhaus, Fabian KrauseBegleitende Übungen (siehe Übungsplan):
I Ab dritter VorlesungswocheI 60% der Aufgaben votieren und 4 Vorträge für Schein und PrüfungI Letzten Übung ist praktisch (SQL)
Einschreibung ab 13 Uhr auf im LSFMöglichkeit der Nutzung von SQLValidatorhttp://propra14.iti.cs.ovgu.de/sqlvali/
I Passphrase: dm-ss2019
Schallehn Datenmanagement Sommersemester 2019 0–4
Einführung
Zugrundeliegendes Lehrbuch
A. Heuer; G. Saake; K. Sattler:Datenbanken — Konzepte undSprachen
5. Auflage, mitp-Verlag, 2013
Schallehn Datenmanagement Sommersemester 2019 0–5
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte
2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell4 Datenbankentwurf5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen
3 Entity-Relationship-Modell4 Datenbankentwurf5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell
4 Datenbankentwurf5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell4 Datenbankentwurf
5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell4 Datenbankentwurf5 Relationale Entwurfstheorie
6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell4 Datenbankentwurf5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen
7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell4 Datenbankentwurf5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger
8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell4 Datenbankentwurf5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle
9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Überblick
1 Was sind Datenbanken – Grundlegende Konzepte2 Relationale Datenbanken – Daten als Tabellen3 Entity-Relationship-Modell4 Datenbankentwurf5 Relationale Entwurfstheorie6 SQL und weitere relationale Anfragesprachen7 Integrität, Transaktionen und Trigger8 Sichten und Zugriffskontrolle9 Datenaustausch mit XML
Schallehn Datenmanagement Sommersemester 2019 0–6
Einführung
Weitere LiteraturG. Vossen.Datenbankmodelle, Datenbanksprachen undDatenbankmanagement-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 kompakt2. Aufl., mitp-Verlag, Bonn, August 2003
G. Lausen.Datenbanken – Grundlagen und XML-TechnologienElsevier GmbH, 2005
Schallehn Datenmanagement Sommersemester 2019 0–7
Teil I
Was sind Datenbanken?
Was sind Datenbanken?
Was sind Datenbanken?
1 Überblick & Motivation
2 Architekturen
3 Einsatzgebiete
4 Historisches
Schallehn Datenmanagement Sommersemester 2019 1–1
Was sind Datenbanken?
Was sind Datenbanken?
1 Überblick & Motivation
2 Architekturen
3 Einsatzgebiete
4 Historisches
Schallehn Datenmanagement Sommersemester 2019 1–1
Was sind Datenbanken?
Was sind Datenbanken?
1 Überblick & Motivation
2 Architekturen
3 Einsatzgebiete
4 Historisches
Schallehn Datenmanagement Sommersemester 2019 1–1
Was sind Datenbanken?
Was sind Datenbanken?
1 Überblick & Motivation
2 Architekturen
3 Einsatzgebiete
4 Historisches
Schallehn Datenmanagement Sommersemester 2019 1–1
Was sind Datenbanken?
Lernziele für heute . . .
Motivation für den Einsatz vonDatenbanksystemen
Kenntnis grundlegender Architekturen
Schallehn Datenmanagement Sommersemester 2019 1–2
Was sind Datenbanken?
Lernziele für heute . . .
Motivation für den Einsatz vonDatenbanksystemenKenntnis grundlegender Architekturen
Schallehn Datenmanagement Sommersemester 2019 1–2
Was sind Datenbanken? Überblick & Motivation
Was sind Datenbanken?
Daten = logisch gruppierte InformationseinheitenBank =
Die Sicherheit vor Verlusten ist eineHauptmotivation, etwas „auf die Bankzu bringen“.
Eine Bank bietet Dienstleistungen fürmehrere Kunden an, um effizientarbeiten zu können.
Eine Datenbank hat die (langfristige)Aufbewahrung von Daten als Aufgabe.Schallehn Datenmanagement Sommersemester 2019 1–3
Was sind Datenbanken? Überblick & Motivation
Anwendungsbeispiele
Schallehn Datenmanagement Sommersemester 2019 1–4
Was sind Datenbanken? Überblick & Motivation
Wie verwaltet man Datenbanken?
Ohne Datenbankenjedes Anwendungssystem verwaltet seine eigenen DatenDaten sind mehrfach gespeichert redundantProbleme
I Verschwendung von SpeicherplatzI „Vergessen“ von ÄnderungenI keine zentrale, „genormte“ Datenhaltung
Schallehn Datenmanagement Sommersemester 2019 1–5
Was sind Datenbanken? Überblick & Motivation
Probleme der Datenredundanz
Andere Softwaresysteme können große Mengen von Daten nichteffizient verarbeitenMehrere Benutzer oder Anwendungen können nicht parallel aufden gleichen Daten arbeiten, ohne sich zu störenAnwendungsprogrammierer / Benutzer können Anwendungennicht programmieren / benutzen, ohne
I interne Darstellung der DatenI Speichermedien oder Rechner
zu kennen (Datenunabhängigkeit nicht gewährleistet)Datenschutz und Datensicherheit sind nicht gewährleistet
Schallehn Datenmanagement Sommersemester 2019 1–6
Was sind Datenbanken? Überblick & Motivation
Idee: Datenintegration durch Datenbanksysteme
Datenbank
...
DBMS
Anwendung Anwendung
strukturierter, von DBMSverwalteter Datenbestand
Datenbankmanagementsystem =Software zur Verwaltung von Datenbanken
DBS = Datenbanksystem
Schallehn Datenmanagement Sommersemester 2019 1–7
Was sind Datenbanken? Überblick & Motivation
Motivation
Datenbank-systeme sindHerzstück heutigerIT-Infrastrukturen
. . . allgegenwärtig
Datenbank-spezialisten sindgefragt
Schallehn Datenmanagement Sommersemester 2019 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 2019 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 2019 1–9
Was sind Datenbanken? Architekturen
Prinzipien: Die neun Codd’schen Regeln
1 Integration: einheitliche, nichtredundante Datenverwaltung2 Operationen: Speichern, Suchen, Ändern3 Katalog: Zugriffe auf Datenbankbeschreibungen im Data
Dictionary4 Benutzersichten5 Integritätssicherung: Korrektheit des Datenbankinhalts6 Datenschutz: Ausschluss unauthorisierter Zugriffe7 Transaktionen: mehrere DB-Operationen als Funktionseinheit8 Synchronisation: parallele Transaktionen koordinieren9 Datensicherung: Wiederherstellung von Daten nach
Systemfehlern
Schallehn Datenmanagement Sommersemester 2019 1–10
Was sind Datenbanken? Architekturen
Datenunabhängigkeit und Schemata
Basierend auf DBMS-GrobarchitekturEntkopplung von Benutzer- und ImplementierungssichtZiele u.a.:
I Trennung von Modellierungssicht und interner SpeicherungI PortierbarkeitI Tuning vereinfachenI standardisierte Schnittstellen
Schallehn Datenmanagement Sommersemester 2019 1–11
Was sind Datenbanken? Architekturen
Schemaarchitektur
Zusammenhang zwischenI Konzeptuellem Schema (Ergebnis der Datendefinition)I Internem Schema (Festlegung der Dateiorganisationen und
Zugriffspfade)I Externen Schemata (Ergebnis der Sichtdefinition)I Anwendungsprogrammen (Ergebnis der
Anwendungsprogrammierung)
Schallehn Datenmanagement Sommersemester 2019 1–12
Was sind Datenbanken? Architekturen
Schemaarchitektur /2
Trennung Schema — InstanzI Schema (Metadaten, Datenbeschreibungen)I Instanz (Anwenderdaten, Datenbankzustand oder -ausprägung)
Datenbankschema besteht ausI internem, konzeptuellem, externen Schemata und den
Anwendungsprogrammen
im konzeptuellen Schema etwa:I StrukturbeschreibungenI IntegritätsbedingungenI Autorisierungsregeln (pro Benutzer für erlaubte DB-Zugriffe)
Schallehn Datenmanagement Sommersemester 2019 1–13
Was sind Datenbanken? Architekturen
Schemaarchitektur /3
Konzeptuelles Schema
externesSchema 1
externesSchema N
internesSchema
...
Anfragebearbeitung
Datendarstellung
Schallehn Datenmanagement Sommersemester 2019 1–14
Was sind Datenbanken? Architekturen
Datenunabhängigkeit /2
Stabilität der Benutzerschnittstelle gegen Änderungenphysisch: Änderungen der Dateiorganisationen und Zugriffspfadehaben keinen Einfluss auf das konzeptuelle Schemalogisch: Änderungen am konzeptuellen und gewissen externenSchemata haben keine Auswirkungen auf andere externeSchemata und Anwendungsprogramme
Schallehn Datenmanagement Sommersemester 2019 1–15
Was sind Datenbanken? Architekturen
Datenunabhängigkeit /3
mögliche Auswirkungen von Änderungen am konzeptuellenSchema:
I eventuell externe Schemata betroffen (Ändern von Attributen)I eventuell Anwendungsprogramme betroffen (Rekompilieren der
Anwendungsprogramme, eventuell Änderungen nötig)
nötige Änderungen werden jedoch vom DBMS erkannt undüberwacht
Schallehn Datenmanagement Sommersemester 2019 1–16
Was sind Datenbanken? Architekturen
Anwendungsbeispiel: Musikversand
Musiker
Titel
Jahr
Tracks
PreisRezension(en)
Schallehn Datenmanagement Sommersemester 2019 1–17
Was sind Datenbanken? Architekturen
Ebenen-Architektur am Beispiel
Konzeptuelle Sicht: Darstellung in Tabellen (Relationen)
Musiker MNr Name Land103 Apocalyptica Finnland104 Subway To Sally Deutschland105 Rammstein Deutschland
Album ANr Titel Jahr Genre MNr → Musiker1014 Amplified 2006 Rock 1031015 Nord Nord Ost 2005 Rock 1041016 Rosenrot 2005 Rock 1051021 Engelskrieger 2003 Rock 1041025 Reflections 2006 Rock 103
Schallehn Datenmanagement Sommersemester 2019 1–18
Was sind Datenbanken? Architekturen
Ebenen-Architektur am Beispiel /2
Externe Sicht: Daten in einer flachen Relation
ANr Titel Jahr Genre Musiker1014 Amplified 2006 Rock Apocalyptica1015 Nord Nord Ost 2005 Rock Subway To Sally1016 Rosenrot 2005 Rock Rammstein1021 Engelskrieger 2003 Rock Subway To Sally1025 Reflections 2006 Rock Apocalyptica
Schallehn Datenmanagement Sommersemester 2019 1–19
Was sind Datenbanken? Architekturen
Ebenen-Architektur am Beispiel /3
Externe Sicht: Daten in einer hierarchisch aufgebauten Relation
Musiker AlbumTitel Jahr Genre
Apocalyptica Amplified 2006 RockReflections 2003 Rock
Subway To Sally Nord Nord Ost 2005 MetalEngelskrieger 2003 Rock
Rammstein Rosenrot 2005 Rock
Schallehn Datenmanagement Sommersemester 2019 1–20
Was sind Datenbanken? Architekturen
Ebenen-Architektur am Beispiel /4
Interne Darstellung
1000 1500 2000
1014 Amplified 2006
1015 Nord Nord Ost 2005
19.99 Rock 103 ....15.99 Rock 104 ....
Überlauf-bereich für Datensätze
Baumzugriff über
Albumnummer
teilweises Speichern
der Datensätze im Baum
Schallehn Datenmanagement Sommersemester 2019 1–21
Was sind Datenbanken? Architekturen
System-Architekturen
Beschreibung der Komponenten eines DatenbanksystemsStandardisierung der Schnittstellen zwischen Komponenten
ArchitekturvorschlägeI ANSI-SPARC-Architektur Drei-Ebenen-Architektur
I Fünf-Schichten-Architektur beschreibt Transformationskomponenten im DetailVorlesung „Datenbank-Implementierungstechniken“
Schallehn Datenmanagement Sommersemester 2019 1–22
Was sind Datenbanken? Architekturen
ANSI-SPARC-Architektur
ANSI: American National Standards InstituteSPARC: Standards Planning and Requirement CommitteeVorschlag von 1978Im Wesentlichen Grobarchitektur verfeinert
I Interne Ebene / Betriebssystem verfeinertI Mehr Interaktive und Programmier-KomponentenI Schnittstellen bezeichnet und normiert
Schallehn Datenmanagement Sommersemester 2019 1–23
Was sind Datenbanken? Architekturen
ANSI-SPARC-Architektur /2
Data Dictionary
Optimierer Auswertung PlattenzugriffAnfragen
Updates
SichtdefinitionDatendefinition
Datei-organisation
DB-Operationen
Einbettung
Masken
P1
Pn
...
Externe Ebene Konzeptuelle Ebene Interne Ebene
Schallehn Datenmanagement Sommersemester 2019 1–24
Was sind Datenbanken? Architekturen
Klassifizierung der Komponenten
Definitionskomponenten: Datendefinition, Dateiorganisation,SichtdefinitionProgrammierkomponenten: DB-Programmierung miteingebetteten DB-OperationenBenutzerkomponenten: Anwendungsprogramme, Anfrage undUpdate interaktivTransformationskomponenten: Optimierer, Auswertung,PlattenzugriffssteuerungData Dictionary (Datenwörterbuch): Aufnahme der Daten ausDefinitionskomponenten, Versorgung der anderen Komponenten
Schallehn Datenmanagement Sommersemester 2019 1–25
Was sind Datenbanken? Architekturen
Fünf-Schichten-Architektur
Verfeinerung der Transformationsschritte
Datensystem
Zugriffssystem
Speichersystem
Pufferverwaltung
Betriebssystem
MengenorientierteSchnittstelle
SatzorientierteSchnittstelle
InterneSatzschnittstelle
Systempuffer-schnittstelle
Datei-schnittstelle
Geräteschnittstelle
Externspeicher
ÜbersetzungZugriffspfadwahl
Logische Zugriffspfade, Schemakatalog, Sortierung,Transaktionsverwaltung
Speicherungsstrukturen, Zugriffs-pfadverwaltung, Sperr-verwaltung, Logging, Recovery
Systempufferverwaltung, Seitenersetzung, Seitenzuordnung
Externspeicherverwaltung,Speicherzuordnung
Schallehn Datenmanagement Sommersemester 2019 1–26
Was sind Datenbanken? Architekturen
Anwendungsarchitekturen
Architektur von Datenbankanwendungen tpyischerweise auf Basisdes Client-Server-Modells: Server ≡ Datenbanksystem
1. Anforderung
3. Antwort
2. Bearbeitung
Client(Dienstnehmer)
Server(Diensterbringer)
Schallehn Datenmanagement Sommersemester 2019 1–27
Was sind Datenbanken? Architekturen
Anwendungsarchitekturen /2
Aufteilung der Funktionalitäten einer AnwendungI Präsentation und BenutzerinteraktionI Anwendungslogik („Business“-Logik)I Datenmanagementfunktionen (Speichern, Anfragen, . . . ).
Benutzerschnittstelle
Anwendungslogik
DB-Schnittstelle
DB-Server
Client
Zwei-Schichten-Architektur
Benutzerschnittstelle
Anwendungslogik
DB-Schnittstelle
Applikations-server
DB-Server
Client
Drei-Schichten-Architektur
Schallehn Datenmanagement Sommersemester 2019 1–28
Was sind Datenbanken? Einsatzgebiete
Einige konkrete Systeme
(Objekt-)Relationale DBMSI Oracle11g, IBM DB2 V.9, Microsoft SQL Server 2008I MySQL (www.mysql.org), PostgreSQL
(www.postgresql.org), Ingres (www.ingres.com), FireBird(www.firebirdsql.org)
Pseudo-DBMSI MS Access
Objektorientierte DBMSI Poet, Versant, ObjectStore
XML-DBMSI Tamino (Software AG), eXcelon
NoSQL-SystemeI Graph-Datenbanksysteme (InfiniteGraph, neo4j),
Dokument-Datenbanken (MongoDB), Key-Value-Stores, ....
Schallehn Datenmanagement Sommersemester 2019 1–29
Was sind Datenbanken? Einsatzgebiete
Einsatzgebiete
Klassische Einsatzgebiete:I viele Objekte (15000 Bücher, 300 Benutzer, 100 Ausleihvorgänge
pro Woche, . . . )I wenige Objekttypen (BUCH, BENUTZER, AUSLEIHUNG)I 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 2019 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 PBTeradata DBMS, NCR MPP-Hardware;Produktinfos (Verkäufe etc.) von 2.900 Märkten;50.000 Anfragen/Woche
Facebook 400 TBx.000 MySQL-ServerHadoop/Hive, 610 Knoten, 15 TB/Tag
US Library of Congress 10-20 TBnicht digitalisiert
PB für Petabyte entspricht der Größenordnung 1015
Schallehn Datenmanagement Sommersemester 2019 1–31
Was sind Datenbanken? Historisches
Entwicklungslinien: 60er Jahre
Anfang 60er Jahre: elementare Dateien, anwendungsspezifischeDatenorganisation (geräteabhängig, redundant, inkonsistent)Ende 60er Jahre: Dateiverwaltungssysteme (SAM, ISAM) mitDienstprogrammen (Sortieren) (geräteunabhängig, aberredundant und inkonsistent)DBS basierend auf hierarchischem Modell, Netzwerkmodell
I Zeigerstrukturen zwischen DatenI Schwache Trennung interne / konzeptuelle EbeneI Navigierende DMLI Trennung DML / Programmiersprache
Schallehn Datenmanagement Sommersemester 2019 1–32
Was sind Datenbanken? Historisches
Entwicklungslinien: 70er und 80er Jahre
70er Jahre: Datenbanksysteme (Geräte- undDatenunabhängigkeit, redundanzfrei, konsistent)Relationale Datenbanksysteme
I Daten in TabellenstrukturenI 3-Ebenen-KonzeptI Deklarative DMLI Trennung DML / Programmiersprache
Schallehn Datenmanagement Sommersemester 2019 1–33
Was sind Datenbanken? Historisches
Historie von RDBMS
1970: Ted Codd (IBM)→ Relationenmodell als konzeptionelleGrundlage relationaler DBS1974: System R (IBM)→ erster Prototyp eines RDBMS
I zwei Module: RDS, RSS; ca. 80.000 LOC (PL/1, PL/S, Assembler),ca. 1,2 MB Codegröße
I Anfragesprache SEQUELI erste Installation 1977
1975: University of California at Berkeley (UCB)→ IngresI Anfragesprache QUELI Vorgänger von Postgres, Sybase, . . .
1979: Oracle Version 2
Schallehn Datenmanagement Sommersemester 2019 1–34
Was sind Datenbanken? Historisches
Entwicklungslinien: (80er und) 90er Jahre
WissensbanksystemeI Daten in TabellenstrukturenI Stark deklarative DML, integrierte Datenbankprogrammiersprache
Objektorientierte DatenbanksystemeI Daten in komplexeren Objektstrukturen (Trennung Objekt und seine
Daten)I Deklarative oder navigierende DMLI Oft integrierte DatenbankprogrammierspracheI Oft keine vollständige Ebenentrennung
Schallehn Datenmanagement Sommersemester 2019 1–35
Was sind Datenbanken? Historisches
Entwicklungslinien: heuteUnterstützung für spezielle Anwendungen
I Hochskalierbare, parallele Datenbanksysteme: Umgang mitDatenmengen im PB-Bereich
I Cloud-Datenbanken: Hosting von Datenbanken, SkalierbareDatenmanagementlösungen
I Datenstromverarbeitung: Online-Verarbeitung von Live-Daten(Börseninfos, Sensordaten, RFID-Daten, . . . )
I XML-Datenbanken: Verwaltung semistrukturierter Daten(XML-Dokumente)
I Multimediadatenbanken: Verwaltung multimedialer Objekte (Bilder,Audio, Video)
I Verteilte Datenbanken: Verteilung von Daten auf verschiedeneRechnerknoten
I Föderierte Datenbanken, Multidatenbanken, Mediatoren:Integration von Daten aus heterogenen Quellen (Datenbanken,Dateien, Web-Quellen)
I Mobile Datenbanken: Datenverwaltung auf Kleinstgeräten(Sensorknoten, Smartphones)
Schallehn Datenmanagement Sommersemester 2019 1–36
Was sind Datenbanken? Historisches
Trends
Nutzergenerierte Inhalte, z.B. Google:I Verarbeitung von 20 PB täglichI 15h Video-Upload auf YouTube in jeder MinuteI Lesen von 20 PB würde 12 Jahre benötigen bei 50 MB/s-Festplatte
Linked Data und Data WebI Bereitstellung, Austausch und Verknüpfung von strukturierten
Daten im WebI ermöglicht Abfrage (mit Anfragesprachen wie SPARQL) und
WeiterverarbeitungI Beispiele: DBpedia, GeoNames
Schallehn Datenmanagement Sommersemester 2019 1–37
Was sind Datenbanken? Historisches
Zusammenfassung
Motivation für Einsatz von DatenbanksystemenCodd’sche Regeln3-Ebenen-Schemaarchitektur & DatenunabhängigkeitEinsatzgebiete
Schallehn Datenmanagement Sommersemester 2019 1–38
Was sind Datenbanken? Historisches
Kontrollfragen
Welchen Vorteil bieten Datenbanksystemegegenüber einer anwendungsspezifischenSpeicherung von Daten?
Was versteht man unterDatenunabhängigkeit und wie wird sieerreicht?In welchen Bereichen kommenDatenbanksysteme zum Einsatz?
Schallehn Datenmanagement Sommersemester 2019 1–39
Was sind Datenbanken? Historisches
Kontrollfragen
Welchen Vorteil bieten Datenbanksystemegegenüber einer anwendungsspezifischenSpeicherung von Daten?Was versteht man unterDatenunabhängigkeit und wie wird sieerreicht?
In welchen Bereichen kommenDatenbanksysteme zum Einsatz?
Schallehn Datenmanagement Sommersemester 2019 1–39
Was sind Datenbanken? Historisches
Kontrollfragen
Welchen Vorteil bieten Datenbanksystemegegenüber einer anwendungsspezifischenSpeicherung von Daten?Was versteht man unterDatenunabhängigkeit und wie wird sieerreicht?In welchen Bereichen kommenDatenbanksysteme zum Einsatz?
Schallehn Datenmanagement Sommersemester 2019 1–39
Teil II
Relationale Datenbanken – Daten alsTabellen
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 2019 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 2019 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 2019 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 2019 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 2019 2–1
Relationale Datenbanken – Daten als Tabellen
Lernziele für heute . . .
Grundverständnis zur Struktur relationalerDatenbanken
Kenntnis der Basisoperationen relationalerAnfragesprachenelementare Fähigkeiten in der Anwendungvon SQL
Schallehn Datenmanagement Sommersemester 2019 2–2
Relationale Datenbanken – Daten als Tabellen
Lernziele für heute . . .
Grundverständnis zur Struktur relationalerDatenbankenKenntnis der Basisoperationen relationalerAnfragesprachen
elementare Fähigkeiten in der Anwendungvon SQL
Schallehn Datenmanagement Sommersemester 2019 2–2
Relationale Datenbanken – Daten als Tabellen
Lernziele für heute . . .
Grundverständnis zur Struktur relationalerDatenbankenKenntnis der Basisoperationen relationalerAnfragesprachenelementare Fähigkeiten in der Anwendungvon SQL
Schallehn Datenmanagement Sommersemester 2019 2–2
Relationale Datenbanken – Daten als Tabellen Relationen für tabellarische Daten
Relationenmodell
Konzeptuell ist die Datenbank eine Menge von TabellenWEINE
WeinID Name Farbe Jahrgang Weingut
1042 La Rose Grand Cru Rot 1998 Château La Rose2168 Creek Shiraz Rot 2003 Creek3456 Zinfandel Rot 2004 Helena2171 Pinot Noir Rot 2001 Creek3478 Pinot Noir Rot 1999 Helena4711 Riesling Reserve Weiß 1999 Müller4961 Chardonnay Weiß 2002 Bighorn
ERZEUGER Weingut Anbaugebiet Region
Creek Barossa Valley South AustraliaHelena Napa Valley KalifornienChâteau La Rose Saint-Emilion BordeauxChâteau La Pointe Pomerol BordeauxMüller Rheingau HessenBighorn Napa Valley Kalifornien
Tabelle = „Relation“
Schallehn Datenmanagement Sommersemester 2019 2–3
Relationale Datenbanken – Daten als Tabellen Relationen für tabellarische Daten
Darstellung von Relationen und Begriffe
Fett geschriebene Zeilen: RelationenschemaWeitere Einträge in der Tabelle: RelationEine Zeile der Tabelle: TupelEine Spaltenüberschrift: AttributEin Eintrag: Attributwert
A1 ... An
...
...
...
R
Relationenname Attribut
Tupel Relation
Relationenschema
Schallehn Datenmanagement Sommersemester 2019 2–4
Relationale Datenbanken – Daten als Tabellen Relationen für tabellarische Daten
Integritätsbedingungen: Schlüssel
Attribute einer Spalte identifizieren eindeutig gespeicherte Tupel:Schlüsseleigenschaftetwa Weingut für Tabelle ERZEUGER
ERZEUGER Weingut Anbaugebiet Region
Creek Barossa Valley South AustraliaHelena Napa Valley KalifornienChâteau La Rose Saint-Emilion BordeauxChâteau La Pointe Pomerol BordeauxMüller Rheingau HessenBighorn Napa Valley Kalifornien
auch Attributkombinationen können Schlüssel sein!Schlüssel können durch Unterstreichen gekennzeichnet werden
Schallehn Datenmanagement Sommersemester 2019 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ätetwa Weingut als Verweise auf ERZEUGERein Fremdschlüssel ist ein Schlüssel in einer „fremden“ Tabelle
Schallehn Datenmanagement Sommersemester 2019 2–6
Relationale Datenbanken – Daten als Tabellen Relationen für tabellarische Daten
Fremdschlüssel /2WEINE
WeinID Name Farbe Jahrgang Weingut→ ERZEUGER
1042 La Rose Grand Cru Rot 1998 Château La Rose2168 Creek Shiraz Rot 2003 Creek3456 Zinfandel Rot 2004 Helena2171 Pinot Noir Rot 2001 Creek3478 Pinot Noir Rot 1999 Helena4711 Riesling Reserve Weiß 1999 Müller4961 Chardonnay Weiß 2002 Bighorn
ERZEUGER Weingut Anbaugebiet Region
Creek Barossa Valley South AustraliaHelena Napa Valley KalifornienChâteau La Rose Saint-Emilion BordeauxChâteau La Pointe Pomerol BordeauxMüller Rheingau HessenBighorn Napa Valley Kalifornien
Schallehn Datenmanagement Sommersemester 2019 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 sowohlI die Ablage des Relationenschemas im Data Dictionary, als auchI die Vorbereitung einer „leeren Basisrelation“ in der Datenbank
Schallehn Datenmanagement Sommersemester 2019 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 qNachkommastellen,character(n) (oder kurz char(n), bei n = 1 auch char) fürZeichenketten (Strings) fester Länge n,character varying(n) (oder kurz varchar(n) für Stringsvariabler Länge bis zur Maximallänge n,bit(n) oder bit varying(n) analog für Bitfolgen, unddate, time bzw. timestamp für Datums-, Zeit- und kombinierteDatums-Zeit-Angaben
Schallehn Datenmanagement Sommersemester 2019 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 2019 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 2019 2–11
Relationale Datenbanken – Daten als Tabellen SQL-Datendefinition
Nullwerte
not null schließt in bestimmten Spalten Nullwerte alsAttributwerte ausKennzeichnung von Nullwerte in SQL durch null; hier ⊥null repräsentiert die Bedeutung „Wert unbekannt“, „Wert nichtanwendbar“ oder „Wert existiert nicht“, gehört aber zu keinemWertebereichnull kann in allen Spalten auftauchen, außer inSchlüsselattributen und den mit not null gekennzeichneten
Schallehn Datenmanagement Sommersemester 2019 2–12
Relationale Datenbanken – Daten als Tabellen SQL-Datendefinition
Weiteres zur Datendefinition in SQL
Neben Primär- und Fremdschlüsseln können in SQL angegebenwerden:
I mit der default-Klausel Defaultwerte für Attribute,I mit der create domain-Anweisung benutzerdefinierte
Wertebereiche undI mit der check-Klausel weitere lokale Integritätsbedingungen
innerhalb der zu definierenden Wertebereiche, Attribute undRelationenschemata
Schallehn Datenmanagement Sommersemester 2019 2–13
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Anfrageoperationen auf Tabellen
Basisoperationen auf Tabellen, die die Berechnung von neuenErgebnistabellen aus gespeicherten Datenbanktabellen erlaubenOperationen werden zur sogenannten RelationenalgebrazusammengefasstMathematik: Algebra ist definiert durch Wertebereich sowie daraufdefinierten Operationen→ für Datenbankanfragen entsprechen die Inhalte der Datenbankden Werten, Operationen sind dagegen Funktionen zumBerechnen der AnfrageergebnisseAnfrageoperationen sind beliebig kombinierbar und bilden eineAlgebra zum „Rechnen mit Tabellen“ – die sogenannte relationaleAlgebra oder auch Relationenalgebra
Schallehn Datenmanagement Sommersemester 2019 2–14
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Relationenalgebra: Übersicht
a1 b2
a2 b2
b2 c3
b3 c4
a2 b3 b4 c5
a1 b2
a2 b2
a2 b3
c3
c3
c4
Verbund
Selektion Projektion
Schallehn Datenmanagement Sommersemester 2019 2–15
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Selektion σ
Selektion: Auswahl von Zeilen einer Tabelle anhand einesSelektionsprädikats
σJahrgang>2000(WEINE)
WeinID Name Farbe Jahrgang Weingut
2168 Creek Shiraz Rot 2003 Creek3456 Zinfandel Rot 2004 Helena2171 Pinot Noir Rot 2001 Creek4961 Chardonnay Weiß 2002 Bighorn
Schallehn Datenmanagement Sommersemester 2019 2–16
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Projektion π
Projektion: Auswahl von Spalten durch Angabe einer Attributliste
πRegion(ERZEUGER)
Region
South AustraliaKalifornienBordeauxHessen
Die Projektion entfernt doppelte Tupel.
Schallehn Datenmanagement Sommersemester 2019 2–17
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Projektion π
Projektion: Auswahl von Spalten durch Angabe einer Attributliste
πRegion(ERZEUGER)
Region
South AustraliaKalifornienBordeauxHessen
Die Projektion entfernt doppelte Tupel.
Schallehn Datenmanagement Sommersemester 2019 2–17
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Natürlicher Verbund on
Verbund (engl. join): verknüpft Tabellen über gleichbenannteSpalten, indem er jeweils zwei Tupel verschmilzt, falls sie dortgleiche Werte aufweisen
WEINE on ERZEUGER
WeinID Name . . . Weingut Anbaugebiet Region
1042 La Rose Grand Cru . . . Ch. La Rose Saint-Emilion Bordeaux2168 Creek Shiraz . . . Creek Barossa Valley South Australia3456 Zinfandel . . . Helena Napa Valley Kalifornien2171 Pinot Noir . . . Creek Barossa Valley South Australia3478 Pinot Noir . . . Helena Napa Valley Kalifornien4711 Riesling Reserve . . . Müller Rheingau Hessen4961 Chardonnay . . . Bighorn Napa Valley Kalifornien
Das Weingut „Château La Pointe“ ist im Ergebnis verschwunden Tupel, die keinen Partner finden (dangling tuples), werdeneliminiert
Schallehn Datenmanagement Sommersemester 2019 2–18
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Natürlicher Verbund on
Verbund (engl. join): verknüpft Tabellen über gleichbenannteSpalten, indem er jeweils zwei Tupel verschmilzt, falls sie dortgleiche Werte aufweisen
WEINE on ERZEUGER
WeinID Name . . . Weingut Anbaugebiet Region
1042 La Rose Grand Cru . . . Ch. La Rose Saint-Emilion Bordeaux2168 Creek Shiraz . . . Creek Barossa Valley South Australia3456 Zinfandel . . . Helena Napa Valley Kalifornien2171 Pinot Noir . . . Creek Barossa Valley South Australia3478 Pinot Noir . . . Helena Napa Valley Kalifornien4711 Riesling Reserve . . . Müller Rheingau Hessen4961 Chardonnay . . . Bighorn Napa Valley Kalifornien
Das Weingut „Château La Pointe“ ist im Ergebnis verschwunden Tupel, die keinen Partner finden (dangling tuples), werdeneliminiert
Schallehn Datenmanagement Sommersemester 2019 2–18
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Kombination von Operationen
πName,Farbe,Weingut(σJahrgang>2000(WEINE) onσRegion=’Kalifornien’(ERZEUGER))
ergibt
Name Farbe Weingut
Zinfandel Rot HelenaChardonnay Weiß Bighorn
Schallehn Datenmanagement Sommersemester 2019 2–19
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Umbenennung β
Anpassung von Attributnamen mittels Umbenennung:
WEINLISTE Name
La Rose Grand CruCreek ShirazZinfandelPinot NoirRiesling Reserve
EMPFEHLUNG Wein
La Rose Grand CruRiesling ReserveMerlot SelectionSauvignon Blanc
Angleichen durch:βName←Wein (EMPFEHLUNG)
Schallehn Datenmanagement Sommersemester 2019 2–20
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Mengenoperationen
Vereinigung r1 ∪ r2 von zwei Relationen r1 und r2: sammelt dieTupelmengen zweier Relationen unter einem gemeinsamenSchema aufAttributmengen beider Relationen müssen identisch sein
WEINLISTE ∪ βName←Wein(EMPFEHLUNG)
Name
La Rose Grand CruCreek ShirazZinfandelPinot NoirRiesling ReserveMerlot SelectionSauvignon Blanc
Schallehn Datenmanagement Sommersemester 2019 2–21
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Mengenoperationen /2
Differenz r1 − r2 eliminiert die Tupel aus der ersten Relation, dieauch in der zweiten Relation vorkommen
WEINLISTE− βName←Wein(EMPFEHLUNG)
ergibt:
Name
Creek ShirazZinfandelPinot Noir
Schallehn Datenmanagement Sommersemester 2019 2–22
Relationale Datenbanken – Daten als Tabellen Grundoperationen: Die Relationenalgebra
Mengenoperationen /3
Durchschnitt r1 ∩ r2: ergibt die Tupel, die in beiden Relationengemeinsam vorkommen
WEINLISTE ∩ βName←Wein(EMPFEHLUNG)
liefert:
Name
La Rose Grand CruRiesling Reserve
Schallehn Datenmanagement Sommersemester 2019 2–23
Relationale Datenbanken – Daten als Tabellen SQL als Anfragesprache
SQL-Anfrage als Standardsprache
Anfrage an eine einzelne Tabelle
select Name, Farbefrom WEINEwhere Jahrgang = 2002
SQL hat Multimengensemantik — Duplikate in Tabellen werden inSQL nicht automatisch unterdrückt!Mengensemantik durch distinct
select distinct Namefrom WEINE
Schallehn Datenmanagement Sommersemester 2019 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, ERZEUGERwhere WEINE.Weingut = ERZEUGER.Weingut
Schallehn Datenmanagement Sommersemester 2019 2–25
Relationale Datenbanken – Daten als Tabellen SQL als Anfragesprache
Kombination von Bedingungen
Ausdruck in Relationenalgebra
πName,Farbe,Weingut(σJahrgang>2000(WEINE) onσRegion=’Kalifornien’(ERZEUGER))
Anfrage in SQL
select Name, Farbe, WEINE.Weingutfrom WEINE, ERZEUGERwhere Jahrgang > 2000 and
Region = ’Kalifornien’ andWEINE.Weingut = ERZEUGER.Weingut
Schallehn Datenmanagement Sommersemester 2019 2–26
Relationale Datenbanken – Daten als Tabellen SQL als Anfragesprache
Mengenoperationen in SQL
Vereinigung in SQL explizit mit unionDifferenzbildung durch geschachtelte Anfragen
select *from WINZERwhere Name not in (
select Nachnamefrom KRITIKER)
Schallehn Datenmanagement Sommersemester 2019 2–27
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Änderungsoperationen in SQL
insert: Einfügen eines oder mehrerer Tupel in eine Basisrelationoder Sichtupdate: Ändern von einem oder mehreren Tupel in einerBasisrelation oder Sichtdelete: Löschen eines oder mehrerer Tupel aus einerBasisrelation oder SichtLokale und globale Integritätsbedingungen müssen beiÄnderungsoperationen automatisch vom System überprüftwerden
Schallehn Datenmanagement Sommersemester 2019 2–28
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Die update-Anweisung
Syntax:
update basisrelationset attribut1 = ausdruck1
...attributn = ausdruckn[ where bedingung ]
Schallehn Datenmanagement Sommersemester 2019 2–29
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Beispiel für update
WEINE
WeinID Name Farbe Jahrgang Weingut Preis
2168 Creek Shiraz Rot 2003 Creek 7.993456 Zinfandel Rot 2004 Helena 5.992171 Pinot Noir Rot 2001 Creek 10.993478 Pinot Noir Rot 1999 Helena 19.994711 Riesling Reserve Weiß 1999 Müller 14.994961 Chardonnay Weiß 2002 Bighorn 9.90
update WEINEset Preis = Preis * 1.10where Jahrgang < 2000
Schallehn Datenmanagement Sommersemester 2019 2–30
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Beispiel für update: neue Werte
WEINE
WeinID Name Farbe Jahrgang Weingut Preis
2168 Creek Shiraz Rot 2003 Creek 7.993456 Zinfandel Rot 2004 Helena 5.992171 Pinot Noir Rot 2001 Creek 10.993478 Pinot Noir Rot 1999 Helena 21.994711 Riesling Reserve Weiß 1999 Müller 16.494961 Chardonnay Weiß 2002 Bighorn 9.90
Schallehn Datenmanagement Sommersemester 2019 2–31
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Weiteres zu update
Realisierung von Eintupel-Operation mittels Primärschlüssel:
update WEINEset Preis = 7.99where WeinID = 3456
Änderung der gesamten Relation:
update WEINEset Preis = 11
Schallehn Datenmanagement Sommersemester 2019 2–32
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Die delete-Anweisung
Syntax:
deletefrom basisrelation[ where bedingung ]
Löschen eines Tupels in der WEINE-Relation:
delete from WEINEwhere WeinID = 4711
Schallehn Datenmanagement Sommersemester 2019 2–33
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Weiteres zu delete
Standardfall ist das Löschen mehrerer Tupel:
delete from WEINEwhere Farbe = ’Weiß’
Löschen der gesamten Relation:
delete from WEINE
Schallehn Datenmanagement Sommersemester 2019 2–34
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Weiteres zu delete /2
Löschoperationen können zur Verletzung vonIntegritätsbedingungen führen!Beispiel: Verletzung der Fremdschlüsseleigenschaft, falls es nochWeine von diesem Erzeuger gibt:
delete from ERZEUGERwhere Anbaugebiet = ’Hessen’
Schallehn Datenmanagement Sommersemester 2019 2–35
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Die insert-Anweisung
Syntax:
insertinto basisrelation
[ (attribut1, ..., attributn) ]values (konstante1, ..., konstanten)
optionale Attributliste ermöglicht das Einfügen vonunvollständigen Tupeln
Schallehn Datenmanagement Sommersemester 2019 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 Wert des fehlenden AttributLand wird null
insert into ERZEUGERvalues (’Château Lafitte’, ’Medoc’, ’Bordeaux’)
Schallehn Datenmanagement Sommersemester 2019 2–37
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Einfügen von berechneten Daten
Syntax:
insertinto basisrelation
[ (attribut1, ..., attributn) ]SQL-anfrage
Beispiel:
insert into WEINEselect ProdID, ProdName, ’Rot’, ProdJahr,
’Château Lafitte’from LIEFERANTwhere LName = ’Wein-Kontor’
Schallehn Datenmanagement Sommersemester 2019 2–38
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Zusammenfassung
Relationenmodell: Datenbank als Sammlung von TabellenIntegritätsbedingungen im RelationenmodellTabellendefinition in SQLRelationenalgebra: AnfrageoperatorenGrundkonzepte von SQL-Anfragen und -Änderungen
Schallehn Datenmanagement Sommersemester 2019 2–39
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?
Was definiert die Relationenalgebra?Wie wird eine Realweltobjekt in einerrelationalen Datenbank repräsentiert?Wie werden Tabellen in SQL definiert undmanipuliert?Was sind Integritätsbedingungen?
Schallehn Datenmanagement Sommersemester 2019 2–40
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?Was definiert die Relationenalgebra?
Wie wird eine Realweltobjekt in einerrelationalen Datenbank repräsentiert?Wie werden Tabellen in SQL definiert undmanipuliert?Was sind Integritätsbedingungen?
Schallehn Datenmanagement Sommersemester 2019 2–40
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?Was definiert die Relationenalgebra?Wie wird eine Realweltobjekt in einerrelationalen Datenbank repräsentiert?
Wie werden Tabellen in SQL definiert undmanipuliert?Was sind Integritätsbedingungen?
Schallehn Datenmanagement Sommersemester 2019 2–40
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?Was definiert die Relationenalgebra?Wie wird eine Realweltobjekt in einerrelationalen Datenbank repräsentiert?Wie werden Tabellen in SQL definiert undmanipuliert?
Was sind Integritätsbedingungen?
Schallehn Datenmanagement Sommersemester 2019 2–40
Relationale Datenbanken – Daten als Tabellen Änderungsoperationen in SQL
Kontrollfragen
Was ist eine Relation?Was definiert die Relationenalgebra?Wie wird eine Realweltobjekt in einerrelationalen Datenbank repräsentiert?Wie werden Tabellen in SQL definiert undmanipuliert?Was sind Integritätsbedingungen?
Schallehn Datenmanagement Sommersemester 2019 2–40
Teil III
Entity-Relationship-Modell
Entity-Relationship-Modell
Entity-Relationship-Modell
1 Datenbankmodelle
2 ER-Modell
3 Weitere Konzepte im ER-Modell
Schallehn Datenmanagement Sommersemester 2019 3–1
Entity-Relationship-Modell
Entity-Relationship-Modell
1 Datenbankmodelle
2 ER-Modell
3 Weitere Konzepte im ER-Modell
Schallehn Datenmanagement Sommersemester 2019 3–1
Entity-Relationship-Modell
Entity-Relationship-Modell
1 Datenbankmodelle
2 ER-Modell
3 Weitere Konzepte im ER-Modell
Schallehn Datenmanagement Sommersemester 2019 3–1
Entity-Relationship-Modell Datenbankmodelle
Grundlagen von Datenbankmodellen
Ein Datenbankmodell ist ein System von Konzepten zurBeschreibung von Datenbanken. Es legt Syntax und Semantik vonDatenbankbeschreibungen für ein Datenbanksystem fest.
Datenbankbeschreibungen = Datenbankschemata
Schallehn Datenmanagement Sommersemester 2019 3–2
Entity-Relationship-Modell Datenbankmodelle
Ein Datenbankmodell legt fest...1 Statische Eigenschaften
1 Objekte2 Beziehungen
inklusive der Standard-Datentypen, die Daten über dieBeziehungen und Objekte darstellen können,
2 Dynamische Eigenschaften wie1 Operationen2 Beziehungen zwischen Operationen,
3 Integritätsbedingungen an1 Objekte2 Operationen
Schallehn Datenmanagement Sommersemester 2019 3–3
Entity-Relationship-Modell Datenbankmodelle
Datenbankmodelle
Klassische Datenbankmodelle sind speziell geeignet fürI große Informationsmengen mit relativ einfacher und starrer Struktur
undI die Darstellung statischer Eigenschaften und
Integritätsbedingungen (also die Bereiche 1(a), 1(b) und 3(a))
Verschiedene Modelle für verschiedene Phasen (späterausführlicher)Modelle für den konzeptuellen Entwurf: ER-Modell, UML, . . .Modell für den logischen Entwurf: Relationenmodell,objektorientierte Modelle, . . .
Schallehn Datenmanagement Sommersemester 2019 3–4
Entity-Relationship-Modell Datenbankmodelle
Einordnung: Phasenmodell des Datenbankentwurfs
Anforderungsanalyse
KonzeptionellerEntwurf
Verteilungsentwurf
Logischer Entwurf
Datendefinition
Physischer Entwurf
Implementierung &Wartung
Schallehn Datenmanagement Sommersemester 2019 3–5
Entity-Relationship-Modell Datenbankmodelle
Datenbanken versus Programmiersprachen
Datenbankkonzept Typsystem einerProgrammiersprache
Datenbankmodell TypsystemRelation, Attribut . . . int, struct ...Datenbankschema Variablendeklaration
relation WEIN = (...) var x: int, y: struct WeinDatenbank Werte
WEIN(4961, ’Chardonnay’, ’Weiß’, . . . ) 42, ’Cabernet Sauvignon’
Schallehn Datenmanagement Sommersemester 2019 3–6
Entity-Relationship-Modell Datenbankmodelle
Datenbankmodelle im Überblick
NWM
HMab Mitte 1960
1970
1980
1990
2000
implementierungsnah
ODMG
abstrakt
ER
SDM
OEM
RM
eNF
SQL
OODM(C++)
ORM / SQL-99
NF2
2
Schallehn Datenmanagement Sommersemester 2019 3–7
Entity-Relationship-Modell Datenbankmodelle
Datenbankmodelle im Überblick /2
HM: hierarchisches Modell, NWM: Netzwerkmodell, RM:RelationenmodellNF2: Modell der geschachtelten (Non-First-Normal-Form = NF2)Relationen, eNF2: erweitertes NF2-ModellER: Entity-Relationship-Modell, SDM: semantische DatenmodelleOODM / C++: objektorientierte Datenmodelle auf Basisobjektorientierter Programmiersprachen wie C++, OEM:objektorientierte Entwurfsmodelle (etwa UML), ORDM:objektrelationale Datenmodelle
Schallehn Datenmanagement Sommersemester 2019 3–8
Entity-Relationship-Modell ER-Modell
Das Entity Relationship-Modell
Entity: Objekt der realen oder der Vorstellungswelt, über dasInformationen 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. einKunde bestellt einen Wein oder ein Wein wird von einemWinzer angeboten
Attribut: repräsentiert eine Eigenschaft von Entities oderBeziehungen, z.B. Name eines Kunden, Farbe einesWeines oder Datum einer Bestellung
Schallehn Datenmanagement Sommersemester 2019 3–9
Entity-Relationship-Modell ER-Modell
ER-BeispielRebsorte
Anbaugebiet
Wein
sitzt in
produziertvon Erzeuger
hergestellt aus
empfiehlt
Gericht
Kritiker
[0,*]
[1,7]
[0,*]
[0,*]
[0,*]
Anteil
NameFarbe
Weingut Adresse
NameRegion
Name
Restsüße
Farbe
Jahrgang
Bezeichnung
Beilage
Name
Organisation
Land
Lizenz
besitzt
LizenzNr
Menge
Schallehn Datenmanagement Sommersemester 2019 3–10
Entity-Relationship-Modell ER-Modell
Werte
Werte: primitive Datenelemente, die direkt darstellbar sindWertemengen sind beschrieben durch Datentypen, die nebeneiner Wertemenge auch die Grundoperationen auf diesen WertencharakterisierenER-Modell: vorgegebene Standard-Datentypen, etwa die ganzenZahlen int, die Zeichenketten string, Datumswerte date etc.jeder Datentyp stellt Wertebereich mit Operationen undPrädikaten dar
Schallehn Datenmanagement Sommersemester 2019 3–11
Entity-Relationship-Modell ER-Modell
Entities und Entity Typen
Entities sind die in einer Datenbank zu repräsentierendenInformationseinheitenIm Gegensatz zu Werten nicht direkt darstellbar, sondern nur überihre Eigenschaften beobachtbarEntities sind eingeteilt in Entity-Typen, etwa E1,E2 . . .
Wein
In ER-Diagrammen werden Entity Typen dargestellt, keineEntities!
Schallehn Datenmanagement Sommersemester 2019 3–12
Entity-Relationship-Modell ER-Modell
Attribute
Attribute modellieren Eigenschaften von Entities oder auchBeziehungenalle Entities eines Entity-Typs haben dieselben Arten vonEigenschaften; Attribute werden somit für Entity-Typen deklariert
Wein
Name Farbe
Jahrgang
Textuelle Notation E(A1 : D1, . . . ,Am : Dm)
Schallehn Datenmanagement Sommersemester 2019 3–13
Entity-Relationship-Modell ER-Modell
Identifizierung durch Schlüssel
Schlüsselattribute: Teilmenge der gesamten Attribute einesEntity-Typs E(A1, . . . ,Am)
S1, . . . ,Sk ⊆ A1, . . . ,Am
In jedem Datenbankzustand identifizieren die aktuellen Werte derSchlüsselattribute eindeutig Instanzen des Entity-Typs EBei mehreren möglichen Schlüsselkandidaten: Auswahl einesPrimärschlüsselsNotation: markieren durch Unterstreichung:
E(. . . ,S1, . . . ,Si , . . .)
Schallehn Datenmanagement Sommersemester 2019 3–14
Entity-Relationship-Modell ER-Modell
Beziehungstypen
Beziehungen zwischen Entities werden zu Beziehungstypen,Relationship Types zusammengefasstAllgemein: beliebige Anzahl n ≥ 2 von Entity-Typen kann aneinem Beziehungstyp teilhabenZu jedem n-stelligen Beziehungstyp R gehören n Entity-TypenE1, . . . ,En
Schallehn Datenmanagement Sommersemester 2019 3–15
Entity-Relationship-Modell ER-Modell
Beziehungstypen /2
Notation
WeinErzeuger produziert
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 2019 3–16
Entity-Relationship-Modell ER-Modell
Beziehungsattribute
Beziehungen können ebenfalls Attribute besitzenAttributdeklarationen werden beim Beziehungstyp vorgenommen;gilt auch hier für alle Ausprägungen eines Beziehungstyps Beziehungsattribute
RebsorteWeinhergestellt
aus
Anteil
Textuelle Notation: R(E1, . . . ,En; A1, . . . ,Ak )
Schallehn Datenmanagement Sommersemester 2019 3–17
Entity-Relationship-Modell ER-Modell
Merkmale von Beziehungen
Stelligkeit oder Grad:I Anzahl der beteiligten Entity-TypenI häufig: binärI Beispiel: Lieferant liefert Produkt
Kardinalität oder Funktionalität:I Anzahl der eingehenden Instanzen eines Entity-TypsI Formen: 1:1, 1:n, m:nI stellt Integritätsbedingung darI Beispiel: maximal 5 Produkte pro Bestellung
Schallehn Datenmanagement Sommersemester 2019 3–18
Entity-Relationship-Modell ER-Modell
Zwei- vs. mehrstellige Beziehungen
Weinempfiehlt
Gericht
Kritiker
Schallehn Datenmanagement Sommersemester 2019 3–19
Entity-Relationship-Modell ER-Modell
Zwei- vs. mehrstellige Beziehungen
Weinempfiehlt
Gericht
Kritiker
WeinG-K
Gericht
Kritiker
G-W
K-W
Schallehn Datenmanagement Sommersemester 2019 3–19
Entity-Relationship-Modell ER-Modell
Ausprägungen im Beispiel
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
Schallehn Datenmanagement Sommersemester 2019 3–20
Entity-Relationship-Modell ER-Modell
Ausprägungen im Beispiel
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
Schallehn Datenmanagement Sommersemester 2019 3–20
Entity-Relationship-Modell ER-Modell
Rekonstruktion der Ausprägungen
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
g1 – k1 – w1
g1 – k2 – w2
g2 – k2 – w1
aber auch: g1 – k2 – w1
Schallehn Datenmanagement Sommersemester 2019 3–21
Entity-Relationship-Modell ER-Modell
Rekonstruktion der Ausprägungen
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
g1 – k1 – w1
g1 – k2 – w2
g2 – k2 – w1
aber auch: g1 – k2 – w1
Schallehn Datenmanagement Sommersemester 2019 3–21
Entity-Relationship-Modell ER-Modell
Rekonstruktion der Ausprägungen
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
g1 – k1 – w1
g1 – k2 – w2
g2 – k2 – w1
aber auch: g1 – k2 – w1
Schallehn Datenmanagement Sommersemester 2019 3–21
Entity-Relationship-Modell ER-Modell
Rekonstruktion der Ausprägungen
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
g1 – k1 – w1
g1 – k2 – w2
g2 – k2 – w1
aber auch: g1 – k2 – w1
Schallehn Datenmanagement Sommersemester 2019 3–21
Entity-Relationship-Modell ER-Modell
Rekonstruktion der Ausprägungen
Gericht
Kritiker
Wein
g1
g2
w1
w2
k1 k2
g1 – k1 – w1
g1 – k2 – w2
g2 – k2 – w1
aber auch: g1 – k2 – w1
Schallehn Datenmanagement Sommersemester 2019 3–21
Entity-Relationship-Modell ER-Modell
1:1-Beziehungen
jedem Entity e1 vom Entity-Typ E1 ist maximal ein Entity e2 aus E2zugeordnet und umgekehrtBeispiele: Prospekt beschreibt Produkt, Mann ist verheiratet mitFrau
E1 E2
Schallehn Datenmanagement Sommersemester 2019 3–22
Entity-Relationship-Modell ER-Modell
1:N-Beziehungen
jedem Entity e1 vom Entity-Typ E1 sind beliebig viele Entities E2zugeordnet, aber zu jedem Entity e2 gibt es maximal ein e1 aus E1
Beispiele: Lieferant liefert Produkt, Mutter hat Kinder
E1 E2
Schallehn Datenmanagement Sommersemester 2019 3–23
Entity-Relationship-Modell ER-Modell
N:1-Beziehung
invers zu 1:N, auch funktionale Beziehungzweistellige Beziehungen, die eine Funktion beschreiben:Jedem Entity eines Entity-Typs E1 wird maximal ein Entity einesEntity-Typs E2 zugeordnet.
R : E1 → E2
Weinproduziert
von Erzeuger
Schallehn Datenmanagement Sommersemester 2019 3–24
Entity-Relationship-Modell ER-Modell
1:1-Beziehung
Erzeuger besitzt Lizenz
Schallehn Datenmanagement Sommersemester 2019 3–25
Entity-Relationship-Modell ER-Modell
M:N-Beziehungen
keine RestriktionenBeispiel: Bestellung umfasst Produkte
E1 E2
Schallehn Datenmanagement Sommersemester 2019 3–26
Entity-Relationship-Modell ER-Modell
[min,max]-Notation
E1 EnR[min1, max1] [minn, maxn]
E2
[min2, max2]...
schränkt die möglichen Teilnahmen von Instanzen der beteiligtenEntity-Typen an der Beziehung ein, indem ein minimaler und einmaximaler Wert vorgegeben wirdNotation für Kardinalitätsangaben an einem Beziehungstyp
R(E1, . . . ,Ei [mini ,maxi ], . . . ,En)
Kardinalitätsbedingung: mini ≤ |r | r ∈ R ∧ r .Ei = ei| ≤ maxiSpezielle Wertangabe für maxi ist ∗
Schallehn Datenmanagement Sommersemester 2019 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 BeziehungR : E1 → E2, da jede Instanz aus E1 maximal einer Instanz aus E2zugeordnet isttotale funktionale Beziehung wird durch R(E1[1,1],E2) modelliert
Schallehn Datenmanagement Sommersemester 2019 3–28
Entity-Relationship-Modell ER-Modell
Kardinalitätsangaben: Beispiele
partielle funktionale Beziehunglagert_in(Produkt[0,1],Fach[0,3])
„Jedes Produkt ist im Lager in einem Fach abgelegt, allerdingswird ausverkauften bzw. gegenwärtig nicht lieferbaren Produktekein Fach zugeordnet. Pro Fach können maximal drei Produktegelagert werden.“totale funktionale Beziehung
liefert(Lieferant[0,*],Produkt[1,1])
„Jedes Produkt wird durch genau einen Lieferant geliefert, aberein Lieferant kann durchaus mehrere Produkte liefern.“
Schallehn Datenmanagement Sommersemester 2019 3–29
Entity-Relationship-Modell ER-Modell
Alternative Kardinalitätsangabe
geliefert vonProdukt Lieferant
[1,1] [0,*]
geliefert vonProdukt Lieferant
N 1
Schallehn Datenmanagement Sommersemester 2019 3–30
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Abhängige Entity-Typen
abhängiger Entity-Typ: Identifikation über funktionale Beziehung
WeinJahrgang Weingehört-zu
Jahr
Restsüße
Name
Farbe
Abhängige Entities im ER-Modell: Funktionale Beziehung alsSchlüssel
Schallehn Datenmanagement Sommersemester 2019 3–31
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Abhängige Entity-Typen /2
Mögliche Ausprägung für abhängige Entities
Name: Pinot NoirFarbe: Rot
Name: Riesling ReserveFarbe: Weiß
Name: ZinfandelFarbe: Rot
gehört-zu
gehört-zu
gehört-zu
Jahr: 2004Restsüße: 1,2
Jahr: 2003Restsüße: 1,4
Jahr: 1999Restsüße: 6,7
Schallehn Datenmanagement Sommersemester 2019 3–32
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Abhängige Entity-Typen /3
Alternative Notation
NWeinJahrgang Weingehört-zu
1
Jahr
Restsüße
Name
Farbe
Schallehn Datenmanagement Sommersemester 2019 3–33
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Die IST-Beziehung
Spezialisierungs-/Generalisierungsbeziehung oder auch IST-Beziehung (engl. is-a relationship)textuelle Notation: E1 IST E2
IST-Beziehung entspricht semantisch einer injektiven funktionalenBeziehung
WeinSchaumwein IST
Name
Farbe
Herstellung
Schallehn Datenmanagement Sommersemester 2019 3–34
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Eigenschaften der IST-Beziehung
Jeder Schaumwein-Instanz ist genau eine Wein-Instanzzugeordnet Schaumwein-Instanzen werden durch die funktionale IST-Beziehung identifiziertNicht jeder Wein ist zugleich ein SchaumweinAttribute des Entity-Typs Wein treffen auch auf Schaumweine zu:„vererbte“ Attribute
Schaumwein(Name,Farbe︸ ︷︷ ︸von Wein
,Herstellung)
nicht nur die Attributdeklarationen vererben sich, sondern auchjeweils die aktuellen Werte für eine Instanz
Schallehn Datenmanagement Sommersemester 2019 3–35
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Ausprägung für IST-Beziehung
Schaumweine
Weine
w1
w2
w3
w1
w2
w5
w4
w6
w4
Schallehn Datenmanagement Sommersemester 2019 3–36
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Alternative Notation für IST-Beziehung
WeinSchaumwein
Name FarbeHerstellung
Schallehn Datenmanagement Sommersemester 2019 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-Beziehungteil, während Instanzen des Obertyps E2 nicht teilnehmen müssenAspekte wie Attributvererbung werden hiervon nicht erfasst
Schallehn Datenmanagement Sommersemester 2019 3–38
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Optionalität von Attributen
Anbaugebietsitzt inErzeuger
Weingut AdresseName
RegionLand
Schallehn Datenmanagement Sommersemester 2019 3–39
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Konzepte im Überblick
Begriff Informale BedeutungEntity zu repräsentierende InformationseinheitEntity-Typ Gruppierung von Entitys mit gleichen EigenschaftenBeziehungstyp Gruppierung von Beziehungen zwischen EntitysAttribut datenwertige Eigenschaft eines Entitys oder einer Bezie-
hungSchlüssel identifizierende Eigenschaft von EntitysKardinalitäten Einschränkung von Beziehungstypen bezüglich der mehr-
fachen Teilnahme von Entitys an der BeziehungStelligkeit Anzahl der an einem Beziehungstyp beteiligten Entity-
Typenfunktionale Beziehung Beziehungstyp mit Funktionseigenschaftabhängige Entitys Entitys, die nur abhängig von anderen Entitys existieren
könnenIST-Beziehung Spezialisierung von Entity-TypenOptionalität Attribute oder funktionale Beziehungen als partielle Funk-
tionen
Schallehn Datenmanagement Sommersemester 2019 3–40
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-ModellWeitere Konzepte im ER-ModellBasis: Kapitel 3 von [SSH10]
Schallehn Datenmanagement Sommersemester 2019 3–41
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)Entity-Relationship-Modell
Weitere Konzepte im ER-ModellBasis: Kapitel 3 von [SSH10]
Schallehn Datenmanagement Sommersemester 2019 3–41
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)Entity-Relationship-ModellWeitere Konzepte im ER-Modell
Basis: Kapitel 3 von [SSH10]
Schallehn Datenmanagement Sommersemester 2019 3–41
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Zusammenfassung
Datenbankmodell, Datenbankschema, Datenbank(instanz)Entity-Relationship-ModellWeitere Konzepte im ER-ModellBasis: Kapitel 3 von [SSH10]
Schallehn Datenmanagement Sommersemester 2019 3–41
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Wasunterscheidet Modell und Schema?
Welche Konzepte definiert dasER-Modell?Durch welche Eigenschaften sindBeziehungstypen charakterisiert?Was unterscheidet abhängigeEntity-Typen von normalen Entity-Typen?
Schallehn Datenmanagement Sommersemester 2019 3–42
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Wasunterscheidet Modell und Schema?Welche Konzepte definiert dasER-Modell?
Durch welche Eigenschaften sindBeziehungstypen charakterisiert?Was unterscheidet abhängigeEntity-Typen von normalen Entity-Typen?
Schallehn Datenmanagement Sommersemester 2019 3–42
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Wasunterscheidet Modell und Schema?Welche Konzepte definiert dasER-Modell?Durch welche Eigenschaften sindBeziehungstypen charakterisiert?
Was unterscheidet abhängigeEntity-Typen von normalen Entity-Typen?
Schallehn Datenmanagement Sommersemester 2019 3–42
Entity-Relationship-Modell Weitere Konzepte im ER-Modell
Kontrollfragen
Was definiert ein Datenbankmodell? Wasunterscheidet Modell und Schema?Welche Konzepte definiert dasER-Modell?Durch welche Eigenschaften sindBeziehungstypen charakterisiert?Was unterscheidet abhängigeEntity-Typen von normalen Entity-Typen?
Schallehn Datenmanagement Sommersemester 2019 3–42
Teil IV
Datenbankentwurf
Datenbankentwurf
Datenbankentwurf
1 Phasen des Datenbankentwurfs
2 Weiteres Vorgehen beim Entwurf
3 Kapazitätserhaltende Abbildungen
4 ER-auf-RM-Abbildung
Schallehn Datenmanagement Sommersemester 2019 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 2019 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 2019 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 2019 4–1
Datenbankentwurf Phasen des Datenbankentwurfs
Entwurfsaufgabe
Datenhaltung für mehrere Anwendungssysteme und mehrereJahredaher: besondere BedeutungAnforderungen an Entwurf
I Anwendungsdaten jeder Anwendung sollen aus Daten derDatenbank ableitbar sein (und zwar möglichst effizient)
I nur „vernünftige“ (wirklich benötigte) Daten sollen gespeichertwerden
I nicht-redundante Speicherung
Schallehn Datenmanagement Sommersemester 2019 4–2
Datenbankentwurf Phasen des Datenbankentwurfs
Phasenmodell
Anforderungsanalyse
KonzeptionellerEntwurf
Verteilungsentwurf
Logischer Entwurf
Datendefinition
Physischer Entwurf
Implementierung &Wartung
Schallehn Datenmanagement Sommersemester 2019 4–3
Datenbankentwurf Phasen des Datenbankentwurfs
Anforderungsanalyse
Vorgehensweise: Sammlung des Informationsbedarfs in denFachabteilungenErgebnis:
I informale Beschreibung (Texte, tabellarische Aufstellungen,Formblätter, usw.) des Fachproblems
I Trennen der Information über Daten (Datenanalyse) von denInformation über Funktionen (Funktionsanalyse)
„Klassischer“ DB-Entwurf:I nur Datenanalyse und Folgeschritte
Funktionsentwurf:I siehe Methoden des Software Engineering
Schallehn Datenmanagement Sommersemester 2019 4–4
Datenbankentwurf Phasen des Datenbankentwurfs
Konzeptioneller Entwurf
erste formale Beschreibung des FachproblemsSprachmittel: semantisches DatenmodellVorgehensweise:
I Modellierung von Sichten z.B. für verschiedene FachabteilungenI Analyse der vorliegenden Sichten in Bezug auf KonflikteI Integration der Sichten in ein Gesamtschema
Ergebnis: konzeptionelles Gesamtschema, z.B. ER-Diagramm
Schallehn Datenmanagement Sommersemester 2019 4–5
Datenbankentwurf Phasen des Datenbankentwurfs
Phasen des konzeptionellen Entwurf
Sichtenentwurf
Sichtenanalyse
Sichtenintegration
konzeptioneller Entwurf
Schallehn Datenmanagement Sommersemester 2019 4–6
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Weiteres Vorgehen beim Entwurf
ER-Modellierung von verschiedenen Sichten aufGesamtinformation, z.B. für verschiedene Fachabteilungen einesUnternehmens konzeptueller Entwurf
I Analyse und Integration der SichtenI Ergebnis: konzeptionelles Gesamtschema
Verteilungsentwurf bei verteilter SpeicherungAbbildung auf konkretes Implementierungsmodell (z.B.Relationenmodell) logischer EntwurfDatendefinition, Implementierung und Wartung physischerEntwurf
Schallehn Datenmanagement Sommersemester 2019 4–7
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Sichtenintegration
Analyse der vorliegenden Sichten in Bezug auf KonflikteIntegration der Sichten in ein Gesamtschema
Sicht #1 Sicht #2
Sicht #3
GlobalesSchema
Konsoli-
dierung
Schallehn Datenmanagement Sommersemester 2019 4–8
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Integrationskonflikte
Namenskonflikte: Homonyme / SynonymeI Homonyme: Schloss; KundeI Synonyme: Auto, KFZ, Fahrzeug
Typkonflikte: verschiedene Strukturen für das gleiche ElementWertebereichskonflikte: verschiedene Wertebereiche für einElementBedingungskonflikte: z.B. verschiedene Schlüssel für einElementStrukturkonflikte: gleicher Sachverhalt durch unterschiedlicheKonstrukte ausgedrückt
Schallehn Datenmanagement Sommersemester 2019 4–9
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Logischer Entwurf
Sprachmittel: Datenmodell des ausgewählten„Realisierungs“-DBMS z.B. relationales ModellVorgehensweise:
1 (automatische) Transformation des konzeptionellen Schemas z.B.ER→ relationales Modell
2 Verbesserung des relationalen Schemas anhand von Gütekriterien(Normalisierung, siehe Kapitel 5):Entwurfsziele: Redundanzvermeidung, . . .
Ergebnis: logisches Schema, z.B. Sammlung vonRelationenschemata
Schallehn Datenmanagement Sommersemester 2019 4–10
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Datendefinition
Umsetzung des logischen Schemas in ein konkretes SchemaSprachmittel: DDL und DML eines DBMS z.B. Oracle, DB2, SQLServer
I Datenbankdeklaration in der DDL des DBMSI Realisierung der IntegritätssicherungI Definition der Benutzersichten
Schallehn Datenmanagement Sommersemester 2019 4–11
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Physischer Entwurf
Ergänzen des physischen Entwurfs um Zugriffsunterstützung bzgl.Effizienzverbesserung, z.B. Definition von IndexenIndex
I Zugriffspfad: Datenstruktur für zusätzlichen, schlüsselbasiertenZugriff auf Tupel (〈Schlüsselattributwert, Tupeladresse〉)
I meist als B*-Baum realisiert
Sprachmittel: Speicherstruktursprache SSL
Schallehn Datenmanagement Sommersemester 2019 4–12
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Indexe in SQL
create [ unique ] index indexnameon relname (
attrname [ asc | desc ],attrname [ asc | desc ],
...)
Beispiel
create index WeinIdx on WEINE (Name)
Schallehn Datenmanagement Sommersemester 2019 4–13
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Notwendigkeit für Zugriffspfade
Beispiel: Tabelle mit 100 GB Daten, Festplattentransferrate ca. 50MB/sOperation: Suchen eines Tupels (Selektion)Implementierung: sequentielles DurchsuchenAufwand: 102.400/50 = 2.048 sec. ≈ 34 min.
Schallehn Datenmanagement Sommersemester 2019 4–14
Datenbankentwurf Weiteres Vorgehen beim Entwurf
Implementierung und Wartung
PhasenI der Wartung,I der weiteren Optimierung der physischen Ebene,I der Anpassung an neue Anforderungen und Systemplattformen,I der Portierung auf neue DatenbankmanagementsystemeI etc.
Schallehn Datenmanagement Sommersemester 2019 4–15
Datenbankentwurf Kapazitätserhaltende Abbildungen
Umsetzung des konzeptionellen Schemas
Umsetzung auf logisches SchemaI Beispiel: ER→ RMI korrekt?I Qualität der Abbildung?
Erhaltung der InformationskapazitätI Kann man nach der Abbildung genau die selben Daten
abspeichern wie vorher?I ... oder etwa mehr?I ... oder etwa weniger?
Schallehn Datenmanagement Sommersemester 2019 4–16
Datenbankentwurf Kapazitätserhaltende Abbildungen
Kapazitätserhöhende Abbildung
Lizenz besitzt Erzeuger
WeingutLizenzNo
Abbildung aufR = LizenzNo,Weingut
mit genau einem Schlüssel
K = LizenzNomögliche ungültige Relation:
BESITZT LizenzNo Weingut
007 Helena42 Helena
Schallehn Datenmanagement Sommersemester 2019 4–17
Datenbankentwurf Kapazitätserhaltende Abbildungen
Kapazitätserhaltende Abbildung
Lizenz besitzt Erzeuger
WeingutLizenzNo
korrekte AusprägungBESITZT LizenzNo Weingut
007 Helena42 Müller
korrekte Schlüsselmenge
K = LizenzNo, Weingut
Schallehn Datenmanagement Sommersemester 2019 4–18
Datenbankentwurf Kapazitätserhaltende Abbildungen
Kapazitätsvermindernde Abbildung
Wein enthält Rebsorte
SortennameWName
Relationenschema mit einem Schlüssel WNameals Ausprägung nicht mehr möglich:
ENTHÄLT WName Sortenname
Zinfandel Red Blossom ZinfandelBordeaux Blanc Cabernet SauvignonBordeaux Blanc Muscadelle
kapazitätserhaltend mit Schlüssel beider Entity-Typen imRelationenschema als neuer Schlüssel
K = WName,Sortenname
Schallehn Datenmanagement Sommersemester 2019 4–19
Datenbankentwurf ER-auf-RM-Abbildung
Beispielabbildung ER-RM: Eingabe
Rebsorte
Wein
produziertErzeuger
enthält
Anteil
SortennameFarbe
Weingut Adresse
Restsüße
Farbe
Jahrgang
WName
Schallehn Datenmanagement Sommersemester 2019 4–20
Datenbankentwurf ER-auf-RM-Abbildung
Beispielabbildung ER-RM: Ergebnis
1 REBSORTE = Farbe,Sortenname mitKREBSORTE = Sortenname
2 ENTHÄLT = Sortenname,WName,Anteil mitKENTHÄLT = Sortenname,WName
3 WEIN = Farbe,WName,Jahrgang,Restsüße mitKWEIN = WName
4 PRODUZIERT = WName,Weingut mitKPRODUZIERT = WName
5 ERZEUGER = Weingut,Adresse mitKERZEUGER = Weingut
Schallehn Datenmanagement Sommersemester 2019 4–21
Datenbankentwurf ER-auf-RM-Abbildung
ER-Abbildung auf Relationen
Entity-Typen und Beziehungstypen: jeweils aufRelationenschemataAttribute: Attribute des Relationenschemas, Schlüssel werdenübernommenKardinalitäten der Beziehungen: durch Wahl der Schlüssel beiden zugehörigen Relationenschemata ausgedrücktin einigen Fällen: Verschmelzen der Relationenschemata vonEntity- und Beziehungstypenzwischen den verbleibenden Relationenschemata diverseFremdschlüsselbedingungen einführen
Schallehn Datenmanagement Sommersemester 2019 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 Entity-TypenFestlegung der Schlüssel:
I m:n-Beziehung: beide Primärschlüssel zusammen werdenSchlüssel im neuen Relationenschema
I 1:n-Beziehung: Primärschlüssel der n-Seite (bei der funktionalenNotation die Seite ohne Pfeilspitze) wird Schlüssel im neuenRelationenschema
I 1:1-Beziehung: beide Primärschlüssel werden je ein Schlüssel imneuen Relationenschema, der Primärschlüssel wird dann ausdiesen Schlüsseln gewählt
Schallehn Datenmanagement Sommersemester 2019 4–23
Datenbankentwurf ER-auf-RM-Abbildung
n:m-Beziehungen
Wein enthält Rebsorte
Sortenname Farbe
WName
Restsüße
Farbe
Jahrgang
Anteil
Umsetzung1 REBSORTE = Farbe,Sortenname mit
KREBSORTE = Sortenname2 ENTHÄLT = Sortenname,WName,Anteil mit
KENTHÄLT = Sortenname,WName3 WEIN = Farbe,WName,Jahrgang,Restsüße mit
KWEIN = WNameAttribute Sortenname und WName sind gemeinsam Schlüssel
Schallehn Datenmanagement Sommersemester 2019 4–24
Datenbankentwurf ER-auf-RM-Abbildung
1:n-Beziehungen
Anbaugebietsitzt inErzeuger
Adresse RegionWeingut Name
Umsetzung (zunächst)I ERZEUGER mit den Attributen Weingut und Adresse,I ANBAUGEBIET mit den Attributen Name und Region undI SITZT_IN mit den Attributen Weingut und Name und dem
Primärschlüssel der n-Seite Weingut als Primärschlüssel diesesSchemas.
Schallehn Datenmanagement Sommersemester 2019 4–25
Datenbankentwurf ER-auf-RM-Abbildung
Mögliche Verschmelzungen
optionale Beziehungen ([0,1] oder [0,n]) werden nichtverschmolzenbei Kardinalitäten [1,1] oder [1,n] (zwingende Beziehungen)Verschmelzung möglich:
I 1:n-Beziehung: das Entity-Relationenschema der n-Seite kann indas Relationenschema der Beziehung integriert werden
I 1:1-Beziehung: beide Entity-Relationenschemata können in dasRelationenschema der Beziehung integriert werden
Schallehn Datenmanagement Sommersemester 2019 4–26
Datenbankentwurf ER-auf-RM-Abbildung
1:1-Beziehungen
Lizenz besitzt Erzeuger
Weingut AdresseHektoLiterLizenzNo
Umsetzung (zunächst)I ERZEUGER mit den Attributen Weingut und AdresseI LIZENZ mit den beiden Attributen LizenzNo und HektoliterI BESITZT mit den Primärschlüsseln der beiden beteiligten Entity-
Typen jeweils als Schlüssel dieses Schemas, also LizenzNo undWeingut
Schallehn Datenmanagement Sommersemester 2019 4–27
Datenbankentwurf ER-auf-RM-Abbildung
1:1-Beziehungen: VerschmelzungUmsetzung mit Verschmelzung
I verschmolzene Relation:ERZEUGER
Weingut Adresse LizenzNo Hektoliter
Rotkäppchen Freiberg 42-007 10.000Weingut Müller Dagstuhl 42-009 250
I Erzeuger ohne Lizenz erfordern Nullwerte:ERZEUGER
Weingut Adresse LizenzNo Hektoliter
Rotkäppchen Freiberg 42-007 10.000Weingut Müller Dagstuhl ⊥ ⊥
I freie Lizenzen führen zu weiteren Nullwerten:ERZEUGER
Weingut Adresse LizenzNo Hektoliter
Rotkäppchen Freiberg 42-007 10.000Weingut Müller Dagstuhl ⊥ ⊥⊥ ⊥ 42-003 100.000
Schallehn Datenmanagement Sommersemester 2019 4–28
Datenbankentwurf ER-auf-RM-Abbildung
Abhängige Entity-Typen
NWeinJahrgang Weingehört-zu1
JahrRestsüße WName Farbe
Umsetzung1 WEINJAHRGANG = WName,Restsüße,Jahr mit
KWEINJAHRGANG = WName,Jahr2 WEIN = Farbe,WName mit KWEIN = WName
I Attribut WName in WEINJAHRGANG ist Fremdschlüssel zur RelationWEIN
Schallehn Datenmanagement Sommersemester 2019 4–29
Datenbankentwurf ER-auf-RM-Abbildung
IST-Beziehung
WeinSchaumwein
WName FarbeHerstellung
Umsetzung1 WEIN = Farbe,WName,Jahrgang,Restsüße mit
KWEIN = WName2 SCHAUMWEIN = WName,Herstellung mit
KSCHAUMWEIN = WName
I WName in SCHAUMWEIN ist Fremdschlüssel bezüglich der RelationWEIN
Schallehn Datenmanagement Sommersemester 2019 4–30
Datenbankentwurf ER-auf-RM-Abbildung
Rekursive Beziehungen
Anbaugebiet grenzt-an
nachName
Regionvon
Umsetzung1 ANBAUGEBIET = Name,Region mit
KANBAUGEBIET = Name2 GRENZT_AN = nach,von mit KGRENZT_AN = nach,von
Schallehn Datenmanagement Sommersemester 2019 4–31
Datenbankentwurf ER-auf-RM-Abbildung
Rekursive funktionale Beziehungen
Kritiker SchülerVon
MentorName
Organisation Schüler
Umsetzung1 KRITIKER = Name,Organisation,Mentorname mit
KKRITIKER = Name
I Mentorname ist Fremdschlüssel auf das Attribut Name der RelationKRITIKER.
Schallehn Datenmanagement Sommersemester 2019 4–32
Datenbankentwurf ER-auf-RM-Abbildung
Mehrstellige Beziehungen
Weinempfiehlt
Gericht
Kritiker
WName
Restsüße
Farbe
Jahrgang
Bezeichnung Beilage
Name Organisation
jeder beteiligte Entity-Typ wird nach den obigen Regeln behandeltfür Beziehung Empfiehlt werden Primärschlüssel der drei beteiligten Entity-Typen in das resultierende Relationenschema aufgenommenBeziehung ist allgemeiner Art (k:m:n-Beziehung): alle Primärschlüssel bildenzusammen den Schlüssel
Schallehn Datenmanagement Sommersemester 2019 4–33
Datenbankentwurf ER-auf-RM-Abbildung
Mehrstellige Beziehungen: Ergebnis
1 EMPFIEHLT = WName,Bezeichnung,Name mitKEMPFIEHLT = WName,Bezeichnung,Name
2 GERICHT = Bezeichnung,Beilage mitKGERICHT = Bezeichnung
3 WEIN = Farbe,WName,Jahrgang,Restsüße mitKWEIN = WName
4 KRITIKER = Name,Organisation mitKKRITIKER = Name
Die drei Schlüsselattribute von EMPFIEHLT sind Fremdschlüsselfür die jeweiligen Ursprungsrelationen.
Schallehn Datenmanagement Sommersemester 2019 4–34
Datenbankentwurf ER-auf-RM-Abbildung
Übersicht über die TransformationenER-Konzept wird abgebildet auf relationales KonzeptEntity-Typ Ei Relationenschema Ri
Attribute von Ei Attribute von Ri
Primärschlüssel Pi Primärschlüssel Pi
Beziehungstyp RelationenschemaAttribute: P1, P2
dessen Attribute weitere Attribute1 : n P2 wird Primärschlüssel der Beziehung1 : 1 P1 und P2 werden Schlüssel der Beziehungm : n P1 ∪ P2 wird Primärschlüssel der BeziehungIST-Beziehung R1 erhält zusätzlichen Schlüssel P2
E1, E2: an Beziehung beteiligte Entity-Typen,P1, P2: deren Primärschlüssel,1 : n-Beziehung: E2 ist n-Seite,IST-Beziehung: E1 ist speziellerer Entity-Typ
Schallehn Datenmanagement Sommersemester 2019 4–35
Datenbankentwurf ER-auf-RM-Abbildung
Zusammenfassung
Phasen des Datenbankentwurfs
Datenbankmodell, Datenbankschema, Datenbank(instanz)Entity-Relationship-ModellER-Erweiterungen: Spezialisierung, Generalisierung,Partitionierungweitere Entwurfsschritte
Schallehn Datenmanagement Sommersemester 2019 4–36
Datenbankentwurf ER-auf-RM-Abbildung
Zusammenfassung
Phasen des DatenbankentwurfsDatenbankmodell, Datenbankschema, Datenbank(instanz)
Entity-Relationship-ModellER-Erweiterungen: Spezialisierung, Generalisierung,Partitionierungweitere Entwurfsschritte
Schallehn Datenmanagement Sommersemester 2019 4–36
Datenbankentwurf ER-auf-RM-Abbildung
Zusammenfassung
Phasen des DatenbankentwurfsDatenbankmodell, Datenbankschema, Datenbank(instanz)Entity-Relationship-Modell
ER-Erweiterungen: Spezialisierung, Generalisierung,Partitionierungweitere Entwurfsschritte
Schallehn Datenmanagement Sommersemester 2019 4–36
Datenbankentwurf ER-auf-RM-Abbildung
Zusammenfassung
Phasen des DatenbankentwurfsDatenbankmodell, Datenbankschema, Datenbank(instanz)Entity-Relationship-ModellER-Erweiterungen: Spezialisierung, Generalisierung,Partitionierung
weitere Entwurfsschritte
Schallehn Datenmanagement Sommersemester 2019 4–36
Datenbankentwurf ER-auf-RM-Abbildung
Zusammenfassung
Phasen des DatenbankentwurfsDatenbankmodell, Datenbankschema, Datenbank(instanz)Entity-Relationship-ModellER-Erweiterungen: Spezialisierung, Generalisierung,Partitionierungweitere Entwurfsschritte
Schallehn Datenmanagement Sommersemester 2019 4–36
Datenbankentwurf ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst derDatenbankentwurfsprozess?
Welche Forderungen müssen dieAbbildungen (Transformationen) zwischenden einzelnen Entwurfsschritten erfüllen?Warum?Wie werden die Konzepte des ER-Modellsauf die des Relationenmodell abgebildet?Wie werden die verschiedenenKardinalitäten von Beziehungstypen beider Abbildung berücksichtigt?
Schallehn Datenmanagement Sommersemester 2019 4–37
Datenbankentwurf ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst derDatenbankentwurfsprozess?Welche Forderungen müssen dieAbbildungen (Transformationen) zwischenden einzelnen Entwurfsschritten erfüllen?Warum?
Wie werden die Konzepte des ER-Modellsauf die des Relationenmodell abgebildet?Wie werden die verschiedenenKardinalitäten von Beziehungstypen beider Abbildung berücksichtigt?
Schallehn Datenmanagement Sommersemester 2019 4–37
Datenbankentwurf ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst derDatenbankentwurfsprozess?Welche Forderungen müssen dieAbbildungen (Transformationen) zwischenden einzelnen Entwurfsschritten erfüllen?Warum?Wie werden die Konzepte des ER-Modellsauf die des Relationenmodell abgebildet?
Wie werden die verschiedenenKardinalitäten von Beziehungstypen beider Abbildung berücksichtigt?
Schallehn Datenmanagement Sommersemester 2019 4–37
Datenbankentwurf ER-auf-RM-Abbildung
Kontrollfragen
Welche Schritte umfasst derDatenbankentwurfsprozess?Welche Forderungen müssen dieAbbildungen (Transformationen) zwischenden einzelnen Entwurfsschritten erfüllen?Warum?Wie werden die Konzepte des ER-Modellsauf die des Relationenmodell abgebildet?Wie werden die verschiedenenKardinalitäten von Beziehungstypen beider Abbildung berücksichtigt?
Schallehn Datenmanagement Sommersemester 2019 4–37
Teil V
Relationale Entwurfstheorie
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 2019 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 2019 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 2019 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 2019 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 2019 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 2019 5–1
Relationale Entwurfstheorie Zielmodell des logischen Entwurfs
RelationenmodellWEINEWeinID Name Farbe Jahrgang Weingut
1042 La Rose Grand Cru Rot 1998 Château La Rose2168 Creek Shiraz Rot 2003 Creek3456 Zinfandel Rot 2004 Helena2171 Pinot Noir Rot 2001 Creek3478 Pinot Noir Rot 1999 Helena4711 Riesling Reserve Weiß 1999 Müller4961 Chardonnay Weiß 2002 Bighorn
ERZEUGER Weingut Anbaugebiet Region
Creek Barossa Valley South AustraliaHelena Napa Valley KalifornienChâteau La Rose Saint-Emilion BordeauxChâteau La Pointe Pomerol BordeauxMüller Rheingau HessenBighorn Napa Valley Kalifornien
Schallehn Datenmanagement Sommersemester 2019 5–2
Relationale Entwurfstheorie Zielmodell des logischen Entwurfs
Begriffe des Relationenmodells
Begriff Informale BedeutungAttribut Spalte einer TabelleWertebereich mögliche Werte eines Attributs (auch Do-
mäne)Attributwert Element eines WertebereichsRelationenschema Menge von AttributenRelation Menge von Zeilen einer TabelleTupel Zeile einer TabelleDatenbankschema Menge von RelationenschemataDatenbank Menge von Relationen (Basisrelationen)
Schallehn Datenmanagement Sommersemester 2019 5–3
Relationale Entwurfstheorie Zielmodell des logischen Entwurfs
Begriffe des Relationenmodells /2
Begriff Informale BedeutungSchlüssel minimale Menge von Attributen, deren
Werte ein Tupel einer Tabelle eindeutigidentifizieren
Primärschlüssel ein beim Datenbankentwurf ausge-zeichneter Schlüssel
Fremdschlüssel Attributmenge, die in einer anderenRelation Schlüssel ist
Fremdschlüsselbedingung alle Attributwerte des Fremdschlüsselstauchen in der anderen Relation alsWerte des Schlüssels auf
Schallehn Datenmanagement Sommersemester 2019 5–4
Relationale Entwurfstheorie Zielmodell des logischen Entwurfs
Formalisierung Relationenmodell
Attribute und DomänenI U nichtleere, endliche Menge: UniversumI A ∈ U : AttributI D = D1, . . . ,Dm Menge endlicher, nichtleerer Mengen: jedes Di :
Wertebereich oder DomäneI total definierte Funktion dom : U −→ DI dom(A): Domäne von A
w ∈ dom(A): Attributwert für A
Schallehn Datenmanagement Sommersemester 2019 5–5
Relationale Entwurfstheorie Zielmodell des logischen Entwurfs
Formalisierung Relationenmodell /2
Relationenschemata und RelationenI R ⊆ U : RelationenschemaI Relation r über R = A1, . . . ,An (kurz: r(R)) ist endliche Menge
von Abbildungen t : R −→⋃m
i=1 Di , Tupel genanntI Es gilt t(A) ∈ dom(A) (t(A) Restriktion von t auf A ∈ R)I für X ⊆ R analog t(X ) X-Wert von tI Menge aller Relationen über R: REL(R) := r | r(R)
Schallehn Datenmanagement Sommersemester 2019 5–6
Relationale Entwurfstheorie Zielmodell des logischen Entwurfs
Formalisierung Relationenmodell /3
Datenbankschema und DatenbankI Menge von Relationenschemata S := R1, . . . ,Rp:
DatenbankschemaI Datenbank über S: Menge von Relationen d := r1, . . . , rp, wobei
ri (Ri )I Datenbank d über S: d(S)I Relation r ∈ d : Basisrelation
Schallehn Datenmanagement Sommersemester 2019 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 AttributmengeI Name, Jahrgang, Weingut undI WeinID für WEINE
Primattribut: Element eines SchlüsselsPrimärschlüssel: ausgezeichneter SchlüsselOberschlü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 2019 5–8
Relationale Entwurfstheorie Relationaler DB-Entwurf
Relationaler DB-Entwurf: Überblick
Verfeinern des logischen EntwurfsZiel: Vermeidung von Redundanzen durch Aufspalten vonRelationenschemata, ohne gleichzeitig
I semantische Informationen zu verlieren (Abhängigkeitstreue)I die Möglichkeit zur Rekonstruktion der Relationen zu verlieren
(Verbundtreue)
Redundanzvermeidung durch Normalformen (s.u.)
Schallehn Datenmanagement Sommersemester 2019 5–9
Relationale Entwurfstheorie Relationaler DB-Entwurf
Relation mit RedundanzenWEINE
WeinID Name ... Weingut Anbaugebiet Region
1042 La Rose Gr. Cru . . . Ch. La Rose Saint-Emilion Bordeaux2168 Creek Shiraz . . . Creek Barossa Valley South Australia3456 Zinfandel . . . Helena Napa Valley Kalifornien2171 Pinot Noir . . . Creek Barossa Valley South Australia3478 Pinot Noir . . . Helena Napa Valley Kalifornien4711 Riesling Res. . . . Müller Rheingau Hessen4961 Chardonnay . . . Bighorn Napa Valley Kalifornien
Schallehn Datenmanagement Sommersemester 2019 5–10
Relationale Entwurfstheorie Relationaler DB-Entwurf
Redundanzen
Redundanzen in Basisrelationen aus mehreren Gründenunerwünscht:
I Redundante Informationen belegen unnötigen SpeicherplatzI Änderungsoperationen auf Basisrelationen mit Redundanzen nur
schwer korrekt umsetzbar: wenn eine Information redundantvorkommt, muss eine Änderung diese Information in allen ihrenVorkommen verändern
F mit normalen relationalen Änderungsoperationen und den inrelationalen Systemen vorkommenden lokalenIntegritätsbedingungen (Schlüsseln) nur schwer realisierbar
Schallehn Datenmanagement Sommersemester 2019 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 WeinID 4711 bereits anderem Wein zugeordnet: verletzt FDWeinID→Name
I Weingut Helena war bisher im Napa Valley angesiedelt: verletzt FDWeingut→Anbaugebiet
I Rheingau liegt nicht in Kalifornien: verletzt FDAnbaugebiet→Region
auch update- und delete-Anomalien
Schallehn Datenmanagement Sommersemester 2019 5–12
Relationale Entwurfstheorie Relationaler DB-Entwurf
Funktionale Abhängigkeiten
funktionale Abhängigkeit zwischen Attributmengen X und Y einerRelation
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 habensie auch gleiche Werte für alle Y -AttributeNotation für funktionale Abhängigkeit (FD, von functionaldependency): X→YBeispiel:WeinID →Name, WeingutAnbaugebiet→Region
aber nicht: Weingut→Name
Schallehn Datenmanagement Sommersemester 2019 5–13
Relationale Entwurfstheorie Relationaler DB-Entwurf
Schlüssel als Spezialfall
für Beispiel auf Folie 5-10
WeinID→Name, Farbe, Jahrgang, Weingut, Anbaugebiet, Region
Immer: WeinID→WeinID,dann gesamtes Schema auf rechter SeiteWenn linke Seite minimal: SchlüsselFormal: Schlüssel X liegt vor, wenn für Relationenschema R FDX→R gilt und X minimal
Ziel des Datenbankentwurfs: alle gegebenen funktionalenAbhängigkeiten in „Schlüsselabhängigkeiten“ umformen, ohne dabeisemantische Information zu verlieren
Schallehn Datenmanagement Sommersemester 2019 5–14
Relationale Entwurfstheorie Relationaler DB-Entwurf
Ableitung von FDs
r A B Ca1 b1 c1a2 b1 c1a3 b2 c1a4 b1 c1
genügt A→B und B→Cdann gilt auch A→Cnicht ableitbar C→A oder C→B
Schallehn Datenmanagement Sommersemester 2019 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, dieaus einer gegebenen FD-Menge abgeleitet werden könnenHülle F+
R := f | (f FD über R) ∧ F |= fBeispiel:
A→B,B→C+ = A→B,B→C,A→C,AB→C,A→BC, . . . ,AB→AB, . . .
Schallehn Datenmanagement Sommersemester 2019 5–16
Relationale Entwurfstheorie Relationaler DB-Entwurf
AbleitungsregelnF1 Reflexivität X ⊇ Y =⇒ X→YF2 Augmentation X→Y =⇒ XZ→YZ sowie XZ→YF3 Transitivität X→Y ,Y→Z =⇒ X→ZF4 Dekomposition X→YZ =⇒ X→YF5 Vereinigung X→Y ,X→Z =⇒ X→YZF6 Pseudotransitivität X→Y ,WY→Z =⇒ WX→Z
F1-F3 bekannt als Armstrong-Axiome (sound, complete)
gültig (sound): Regeln leiten keine FDs ab, die logisch nichtimpliziertvollständig (complete): alle implizierten FDs werden abgeleitetunabhängig (independent) oder auch bzgl. ⊆ minimal: keineRegel kann weggelassen werden
Schallehn Datenmanagement Sommersemester 2019 5–17
Relationale Entwurfstheorie Normalformen
Schemaeigenschaften
Relationenschemata, Schlüssel und Fremdschlüssel so wählen,dass
1 alle Anwendungsdaten aus den Basisrelationen hergeleitet werdenkönnen,
2 nur semantisch sinnvolle und konsistente Anwendungsdatendargestellt werden können und
3 die Anwendungsdaten möglichst nicht-redundant dargestelltwerden.
Hier: Forderung 3I Redundanzen innerhalb einer Relation: NormalformenI globale Redundanzen: Minimalität
Schallehn Datenmanagement Sommersemester 2019 5–18
Relationale Entwurfstheorie Normalformen
Normalformen
legen Eigenschaften von Relationenschemata festverbieten bestimmte Kombinationen von funktionalenAbhängigkeiten in Relationensollen Redundanzen und Anomalien vermeiden
Schallehn Datenmanagement Sommersemester 2019 5–19
Relationale Entwurfstheorie Normalformen
Erste Normalform
erlaubt nur atomare Attribute in den Relationenschemata, d.h. alsAttributwerte sind Elemente von Standard-Datentypen wieinteger oder string erlaubt, aber keine Konstruktoren wiearray oder setNicht in 1NF:
Weingut Anbaugebiet Region WName
Ch. La Rose Saint-Emilion Bordeaux La Rose Grand CruCreek Barossa Valley South Australia Creek Shiraz, Pinot NoirHelena Napa Valley Kalifornien Zinfandel, Pinot NoirMüller Rheingau Hessen Riesling ReserveBighorn Napa Valley Kalifornien Chardonnay
Schallehn Datenmanagement Sommersemester 2019 5–20
Relationale Entwurfstheorie Normalformen
Erste Normalform /2
in erster Normalform:
Weingut Anbaugebiet Region WName
Ch. La Rose Saint-Emilion Bordeaux La Rose Grand CruCreek Barossa Valley South Australia Creek ShirazCreek Barossa Valley South Australia Pinot NoirHelena Napa Valley Kalifornien ZinfandelHelena Napa Valley Kalifornien Pinot NoirMüller Rheingau Hessen Riesling ReserveBighorn Napa Valley Kalifornien Chardonnay
Schallehn Datenmanagement Sommersemester 2019 5–21
Relationale Entwurfstheorie Normalformen
Zweite Normalform
partielle Abhängigkeit liegt vor, wenn ein Attribut funktional schonvon einem Teil des Schlüssels abhängt
Name Weingut Farbe Anbaugebiet Region Preis
La Rose Grand Cru Ch. La Rose Rot Saint-Emilion Bordeaux 39.00Creek Shiraz Creek Rot Barossa Valley South Australia 7.99Pinot Noir Creek Rot Barossa Valley South Australia 10.99Zinfandel Helena Rot Napa Valley Kalifornien 5.99Pinot Noir Helena Rot Napa Valley Kalifornien 19.99Riesling Reserve Müller Weiß Rheingau Hessen 14.99Chardonnay Bighorn Weiß Napa Valley Kalifornien 9.90
f1: Name, Weingut→Preisf2: Name →Farbef3: Weingut →Anbaugebiet, Regionf4: Anbaugebiet →Region
Zweite Normalform eliminiert derartige partielle Abhängigkeitenbei Nichtschlüsselattributen
Schallehn Datenmanagement Sommersemester 2019 5–22
Relationale Entwurfstheorie Normalformen
Eliminierung partieller AbhängigkeitenSchlüssel K
abhängigesAttribut ATeil des
Schlüssels XSchallehn Datenmanagement Sommersemester 2019 5–23
Relationale Entwurfstheorie Normalformen
Zweite Normalform /2
Beispielrelation in 2NFR1(Name, Weingut, Preis)R2(Name, Farbe)R3(Weingut, Anbaugebiet, Region)
Schallehn Datenmanagement Sommersemester 2019 5–24
Relationale Entwurfstheorie Normalformen
Zweite Normalform /3
Hinweis: partiell abhängiges Attribut stört nur, wenn es keinPrimattribut ist2NF 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 nichtlinksreduziert istY hängt voll von X ab, wenn die FD X→Y linksreduziert istR ist in 2NF, wenn R in 1NF ist und jedes Nicht-Primattribut vonR voll von jedem Schlüssel von R abhängt
Schallehn Datenmanagement Sommersemester 2019 5–25
Relationale Entwurfstheorie Normalformen
Dritte Normalform
eliminiert (zusätzlich) transitive Abhängigkeitenetwa Weingut → Anbaugebiet und Anbaugebiet →Region in Relation auf Folie 5-30man beachte: 3NF betrachtet nur Nicht-Schlüsselattribute alsEndpunkt transitiver Abhängigkeiten
Schallehn Datenmanagement Sommersemester 2019 5–26
Relationale Entwurfstheorie Normalformen
Eliminierung transitiver AbhängigkeitenSchlüssel K
abhängigesAttribut AAttributmenge X
Schallehn Datenmanagement Sommersemester 2019 5–27
Relationale Entwurfstheorie Normalformen
Dritte Normalform /2
transitive Abhängigkeit in R3, d.h. R3 verletzt 3NFBeispielrelation in 3NFR3_1(Weingut, Anbaugebiet)R3_2(Anbaugebiet, Region)
Schallehn Datenmanagement Sommersemester 2019 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∈ XYerweitertes Relationenschema R = (R,K) ist in 3NF bezüglich Fgenau 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 2019 5–29
Relationale Entwurfstheorie Normalformen
Boyce-Codd-Normalform
Verschärfung der 3NF: Eliminierung transitiver Abhängigkeitenauch zwischen PrimattributenName Weingut Händler Preis
La Rose Grand Cru Château La Rose Weinkontor 39.90Creek Shiraz Creek Wein.de 7.99Pinot Noir Creek Wein.de 10.99Zinfandel Helena GreatWines.com 5.99Pinot Noir Helena GreatWines.com 19.99Riesling Reserve Müller Weinkeller 19.99Chardonnay Bighorn Wein-Dealer 9.90
FDs:Name, Weingut→PreisWeingut →HändlerHändler →Weingut
Schlüsselkandidaten: Name, Weingut und Name, Händler in 3NF, nicht jedoch in BCNF
Schallehn Datenmanagement Sommersemester 2019 5–30
Relationale Entwurfstheorie Normalformen
Boyce-Codd-Normalform /2
erweitertes Relationenschema R = (R,K), FD-Menge FBCNF 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 bis3NF
Schallehn Datenmanagement Sommersemester 2019 5–31
Relationale Entwurfstheorie Normalformen
Minimalität
Global Redundanzen vermeidenandere Kriterien (wie Normalformen) mit möglichst wenigSchemata erreichenBeispiel: Attributmenge ABC, FD-Menge A→B,B→CDatenbankschemata in dritter Normalform:
S = (AB, A), (BC, B)
S′ = (AB, A), (BC, B), (AC, A)
Redundanzen in S′
Schallehn Datenmanagement Sommersemester 2019 5–32
Relationale Entwurfstheorie Normalformen
Schemaeigenschaften
Kennung Schemaeigenschaft Kurzcharakteristik1NF nur atomare Attribute2NF keine partielle Abhängigkeit eines
Nicht-Primattributes von einemSchlüssel
S 1 3NF keine transitive Abhängigkeit ei-nes Nicht-Primattributes von einemSchlüssel
BCNF keine transitive Abhängigkeit einesAttributes von einem Schlüssel
S 2 Minimalität minimale Anzahl von Relationen-schemata, die die anderen Eigen-schaften erfüllt
Schallehn Datenmanagement Sommersemester 2019 5–33
Relationale Entwurfstheorie Transformationseigenschaften
Transformationseigenschaften
Bei einer Zerlegung einer Relation in mehrere Relationen istdarauf zu achten, dass
1 nur semantisch sinnvolle und konsistente Anwendungsdatendargestellt (Abhängigkeitstreue) und
2 alle Anwendungsdaten aus den Basisrelationen hergeleitet werdenkönnen (Verbundtreue)
Schallehn Datenmanagement Sommersemester 2019 5–34
Relationale Entwurfstheorie Transformationseigenschaften
Abhängigkeitstreue
Abhängigkeitstreue: eine Menge von Abhängigkeiten kannäquivalent in eine zweite Menge von Abhängigkeiten transformiertwerdenspezieller: in die Menge der Schlüsselabhängigkeiten, da diesevom Datenbanksystem effizient überprüft werden kann
I die Menge der Abhängigkeiten soll äquivalent zu der Menge derSchlüsselbedingungen im resultierenden Datenbankschema sein
I Äquivalenz sichert zu, dass mit den Schlüsselabhängigkeitensemantisch genau die gleichen Integritätsbedingungen ausgedrücktwerden wie mit den funktionalen oder anderen Abhängigkeitenvorher
Schallehn Datenmanagement Sommersemester 2019 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→PreisName →FarbeWeingut →AnbaugebietAnbaugebiet →Region
äquivalent zu FDs f1 . . . f4 (Folie 5-22) abhängigkeitstreu
Schallehn Datenmanagement Sommersemester 2019 5–36
Relationale Entwurfstheorie Transformationseigenschaften
Abhängigkeitstreue: Beispiel /2
Postleitzahl-Struktur der Deutschen PostPLZ (P), Ort (O), Strasse(S), Hausnummer(H)
und funktionalen Abhängigkeiten FOSH→P, P→O
für ein Datenbankschema S bestehend aus dem einzigenRelationenschema
(OSHP, OSH),ist Menge der Schlüsselabhängigkeiten
OSH→OSHP nicht äquivalent zu F und somit S nicht abhängigkeitstreu
Schallehn Datenmanagement Sommersemester 2019 5–37
Relationale Entwurfstheorie Transformationseigenschaften
Verbundtreue
zur Erfüllung des Kriteriums der Normalformen müssenRelationenschemata teilweise in kleinere Relationenschematazerlegt werdenfür Beschränkung auf „sinnvolle“ Zerlegungen gilt Forderung, dassdie Originalrelation wieder aus den zerlegten Relationen mit demnatürlichen Verbund zurückgewonnen werden kann Verbundtreue
Schallehn Datenmanagement Sommersemester 2019 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 verbundtreudagegen bei Vorliegen von
F ′ = A→B,B→C
verbundtreu
Schallehn Datenmanagement Sommersemester 2019 5–39
Relationale Entwurfstheorie Transformationseigenschaften
Verbundtreue Dekomposition
Originalrelation:
A B C1 2 34 2 3
Dekomposition:
A B1 24 2
B C2 3
Verbund (verbundtreu):
A B C1 2 34 2 3
Schallehn Datenmanagement Sommersemester 2019 5–40
Relationale Entwurfstheorie Transformationseigenschaften
Nicht verbundtreue Dekomposition
Originalrelation:A B C1 2 34 2 5
Dekomposition:A B1 24 2
B C2 32 5
Verbund (nicht verbundtreu):A B C1 2 34 2 51 2 54 2 3
Schallehn Datenmanagement Sommersemester 2019 5–41
Relationale Entwurfstheorie Transformationseigenschaften
Transformationseigenschaften
Kennung Transformationseigenschaft KurzcharakteristikT1 Abhängigkeitstreue alle gegebenen Abhängigkeiten
sind durch Schlüssel repräsentiertT2 Verbundtreue Originalrelationen können durch
den Verbund der Basisrelationenwiedergewonnen werden
Schallehn Datenmanagement Sommersemester 2019 5–42
Relationale Entwurfstheorie Entwurfsverfahren
Entwurfsverfahren: Ziele
Universum U und FD-Menge F gegebenlokal erweitertes Datenbankschema S = (R1,K1), . . . , (Rp,Kp)berechnen mit
I T 1 : S charakterisiert vollständig FI S 1 : S ist in 3NF bezüglich FI T 2 : Dekomposition von U in R1, . . . ,Rp ist verbundtreu bezüglich
FI S 2 : Minimalität, d.h.6 ∃S′ : S′ erfüllt T 1 , S 1 , T 2 und |S′| < |S|
Schallehn Datenmanagement Sommersemester 2019 5–43
Relationale Entwurfstheorie Entwurfsverfahren
Entwurfsverfahren: Beispiel
Datenbankschemata schlecht entworfen, wenn nur eins dieservier Kriterien nicht erfülltBeispiel: 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 inkonsistentkorrekt: S′ = (AB, A), (BC, B)
Schallehn Datenmanagement Sommersemester 2019 5–44
Relationale Entwurfstheorie Entwurfsverfahren
Dekomposition
Geg.: initiales Universalrelationenschema R = (U ,K(F )) mit allenAttributen und einer von erfassten FDs F über R impliziertenSchlüsselmenge
I Attributmenge U und eine FD-Menge FI suche alle K→U mit K minimal, für die K→U ∈ F+ gilt (K(F ))
Ges.: Zerlegung in D = R1,R2, . . . von3NF-Relationenschemata
Schallehn Datenmanagement Sommersemester 2019 5–45
Relationale Entwurfstheorie Entwurfsverfahren
Dekomposition: Beispiel
initiales Relationenschema R = ABCfunktionale Abhängigkeiten F = A→B,B→CSchlüssel K = A
Schallehn Datenmanagement Sommersemester 2019 5–46
Relationale Entwurfstheorie Entwurfsverfahren
Dekomposition: Bewertung
Vorteile: 3NF, VerbundtreueNachteile: restliche Kriterien nicht, reihenfolgeabhängig,NP-vollständig (Schlüsselsuche)
Schallehn Datenmanagement Sommersemester 2019 5–47
Relationale Entwurfstheorie Entwurfsverfahren
Syntheseverfahren
Prinzip: Synthese formt Original-FD-Menge F in resultierendeMenge von Schlüsselabhängigkeiten G so um, dass F ≡ G gilt„Abhängigkeitstreue“ im Verfahren verankertVerbundtreue, 3NF und Minimalität wird auch erreicht,reihenfolgeunabhängigZeitkomplexität: quadratisch
Schallehn Datenmanagement Sommersemester 2019 5–48
Relationale Entwurfstheorie Entwurfsverfahren
Vergleich Dekomposition — Synthese
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
...
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
...
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
WEINE WeinID Name Farbe Jahrgang Weingut
ERZEUGER Weingut Anbaugebiet Region
WINZER Weingut Name
. . .R1,K1 Rn,Kn . . .R1,K1 Rn,Kn
Dekomposition Synthese
. . .R!1,K !
1 R!n,K !
n FDs F !!
FDs F !
FDs F
R,K
U, FDs F
!
!
!
!
!
!
i
...
Dekomposition Synthese
Schallehn Datenmanagement Sommersemester 2019 5–49
Relationale Entwurfstheorie Entwurfsverfahren
Synthese: Beispiel
Relationenschema und FD-Menge:f1: Name, Weingut→Preisf2: Name, Weingut→Weingutf3: Name, Weingut→Namef4: Name →Farbef5: Weingut →Anbaugebiet, Regionf6: Anbaugebiet →Region
minimale Überdeckung: Entfernen von f2, f3 sowie Region in f5Äquivalenzklassen (= Relationenschemata):
C1 = Name,Weingut→PreisC2 = Name→FarbeC3 = Weingut→AnbaugebietC4 = Anbaugebiet→Region
Schallehn Datenmanagement Sommersemester 2019 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 derrestlichen 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 2019 5–51
Relationale Entwurfstheorie Weitere Abhängigkeiten
Mehrwertige Abhängigkeiten
Folge der 1NFMehrwertige Abhängigkeiten erzeugen Redundanz:
WEIN_EMPFEHLUNG WName Jahrgang Gericht
Chardonnay 2002 GeflügelChardonnay 2002 FischChardonnay 2003 FischChardonnay 2003 GeflügelShiraz 2003 WildShiraz 2003 LammShiraz 2004 WildShiraz 2004 Lamm
I eine (oder mehrere) Gruppe von Attributwerten ist von einemSchlüssel bestimmt, unabhängig von anderen Attributen
I hier: Menge von Jahrgängen plus Menge von GerichtenWName →→ Jahrgang, WName →→ Gericht
I Resultat: Redundanz durch Bildung aller Kombinationen
Schallehn Datenmanagement Sommersemester 2019 5–52
Relationale Entwurfstheorie Weitere Abhängigkeiten
Mehrwertige Abhängigkeiten und 4NF
wünschenswerte Schemaeigenschaft bei Vorliegen von MVDs:vierte Normalformfordert die Beseitigung derartiger Redundanzen: keine zwei MVDszwischen Attributen einer RelationBeispiel von vorhergehender Folie verletzt diese ForderungPrinzip
I Elimination der rechten Seite einer der beiden mehrwertigenAbhängigkeiten,
I linke Seite mit dieser rechten Seite in neue Relation kopiert
Schallehn Datenmanagement Sommersemester 2019 5–53
Relationale Entwurfstheorie Weitere Abhängigkeiten
Vierte Normalform
WEIN_JAHR WName Jahrgang
Chardonnay 2002Chardonnay 2003Shiraz 2003Shiraz 2004
WEIN_GERICHT WName Gericht
Chardonnay GeflügelChardonnay FischShiraz WildShiraz Lamm
Schallehn Datenmanagement Sommersemester 2019 5–54
Relationale Entwurfstheorie Weitere Abhängigkeiten
Zusammenfassung
funktionale AbhängigkeitenNormalformen (1NF - 3NF, BCNF)Abhängigkeitstreue und VerbundtreueEntwurfsverfahrenmehrwertige Abhängigkeiten
Schallehn Datenmanagement Sommersemester 2019 5–55
Relationale Entwurfstheorie Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierungrelationaler Schemata?
Welche Eigenschaften relationalerSchemata werden bei den Normalformenberücksichtigt?Was unterscheidet 3NF und BCNF?Was fordern Abhängigkeitstreue undVerbundtreue?
Schallehn Datenmanagement Sommersemester 2019 5–56
Relationale Entwurfstheorie Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierungrelationaler Schemata?Welche Eigenschaften relationalerSchemata werden bei den Normalformenberücksichtigt?
Was unterscheidet 3NF und BCNF?Was fordern Abhängigkeitstreue undVerbundtreue?
Schallehn Datenmanagement Sommersemester 2019 5–56
Relationale Entwurfstheorie Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierungrelationaler Schemata?Welche Eigenschaften relationalerSchemata werden bei den Normalformenberücksichtigt?Was unterscheidet 3NF und BCNF?
Was fordern Abhängigkeitstreue undVerbundtreue?
Schallehn Datenmanagement Sommersemester 2019 5–56
Relationale Entwurfstheorie Weitere Abhängigkeiten
Kontrollfragen
Welches Ziel hat die Normalisierungrelationaler Schemata?Welche Eigenschaften relationalerSchemata werden bei den Normalformenberücksichtigt?Was unterscheidet 3NF und BCNF?Was fordern Abhängigkeitstreue undVerbundtreue?
Schallehn Datenmanagement Sommersemester 2019 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
2 Anfragealgebren
3 Erweiterungen der Relationenalgebra
4 Anfragekalküle
5 Beispiele für Bereichskalkül
Schallehn Datenmanagement Sommersemester 2019 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 2019 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 2019 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 2019 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 2019 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 bleibenunverändert)
Schallehn Datenmanagement Sommersemester 2019 6–2
Grundlagen von Anfragen: Algebra & Kalkül Kriterien für Anfragesprachen
Begriffe
Anfrage: Folge von Operationen, die aus den Basisrelationen eineErgebnisrelation berechnet
I Ergebnisrelation interaktiv auf dem Bildschirm anzeigen oderI per Programm weiterverarbeiten („Einbettung“)
Sicht: Folge von Operationen, die unter einem Sichtnamenlangfristig abgespeichert wird und unter diesem Namen wiederaufgerufen werden kann; ergibt eine SichtrelationSnapshot: Ergebnisrelation einer Anfrage, die unter einemSnapshot-Namen abgelegt wird, aber nie ein zweites Mal (mitgeänderten Basisrelationen) berechnet wird (etwaJahresbilanzen)
Schallehn Datenmanagement Sommersemester 2019 6–3
Grundlagen von Anfragen: Algebra & Kalkül Kriterien für Anfragesprachen
Kriterien für Anfragesprachen
Ad-Hoc-Formulierung: Benutzer soll eine Anfrage formulierenkönnen, ohne ein vollständiges Programm schreiben zu müssenDeskriptivitä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 Datengleichzeitig arbeiten, nicht navigierend nur auf einzelnenElementen („one-tuple-at-a-time“)Abgeschlossenheit: Ergebnis ist wieder eine Relation und kannwieder als Eingabe für die nächste Anfrage verwendet werden
Schallehn Datenmanagement Sommersemester 2019 6–4
Grundlagen von Anfragen: Algebra & Kalkül Kriterien für Anfragesprachen
Kriterien für Anfragesprachen /2
Adäquatheit: alle Konstrukte des zugrundeliegendenDatenmodells werden unterstütztOrthogonalität: Sprachkonstrukte sind in ähnlichen Situationenauch ähnlich anwendbarOptimierbarkeit: Sprache besteht aus wenigen Operationen, fürdie es Optimierungsregeln gibtEffizienz: jede Operation ist effizient ausführbar (imRelationenmodell hat jede Operation eine Komplexität ≤ O(n2),nAnzahl der Tupel einer Relation).
Schallehn Datenmanagement Sommersemester 2019 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 eineEndlosschleife geraten oder ein unendliches Ergebnis liefernEingeschränktheit: (folgt aus Sicherheit, Optimierbarkeit,Effizienz) Anfragesprache darf keine kompletteProgrammiersprache seinVollständigkeit: Sprache muss mindestens die Anfragen einerStandardsprache (wie etwa die in diesem Kapitel einzuführendeRelationenalgebra oder den sicheren Relationenkalkül)ausdrücken können
Schallehn Datenmanagement Sommersemester 2019 6–6
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Anfragealgebren
Mathematik: Algebra definiert durch Wertebereich und auf diesemdefinierte Operatorenfür Datenbankanfragen: Inhalte der Datenbank sind Werte, undOperatoren definieren Funktionen zum Berechnen vonAnfrageergebnissen
I RelationenalgebraI Algebra-Erweiterungen
Schallehn Datenmanagement Sommersemester 2019 6–7
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Relationenalgebra
Spalten ausblenden: Projektion πZeilen heraussuchen: Selektion σTabellen verknüpfen: Verbund (Join) onTabellen vereinigen: Vereinigung ∪;Tabellen voneinander abziehen: Differenz −Spalten umbenennen: Umbenennung β(wichtig für on und ∪,−)
Schallehn Datenmanagement Sommersemester 2019 6–8
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Relationenalgebra: Übersicht
a1 b2
a2 b2
b2 c3
b3 c4
a2 b3 b4 c5
a1 b2
a2 b2
a2 b3
c3
c3
c4
Verbund
Selektion Projektion
Schallehn Datenmanagement Sommersemester 2019 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 REigenschaft für Y ⊆ X ⊆ R
πY (πX (r)) = πY (r)
Achtung: π entfernt Duplikate (Mengensemantik)
Schallehn Datenmanagement Sommersemester 2019 6–10
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Projektion: Beispiel
πRegion(ERZEUGER)
Region
South AustraliaKalifornienBordeauxHessen
Schallehn Datenmanagement Sommersemester 2019 6–11
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Projektion: Beispiel 2
πAnbaugebiet,Region(ERZEUGER)
Anbaugebiet Region
Barossa Valley South AustraliaNapa Valley KalifornienSaint-Emilion BordeauxPomerol BordeauxRheingau Hessen
Schallehn Datenmanagement Sommersemester 2019 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 2019 6–13
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Selektionsbedingungen
KonstantenselektionAttribut θ Konstante
boolesches Prädikat θ ist = oder 6=, bei linear geordnetenWertebereichen auch ≤, <, ≥ oder >Attributselektion
Attribut1 θ Attribut2
logische Verknüpfung mehrerer Konstanten- oder Attribut-Selektionen mit ∧,∨ oder ¬
Schallehn Datenmanagement Sommersemester 2019 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 2019 6–15
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Selektion: Beispiel
σJahrgang>2000(WEINE)
WeinID Name Farbe Jahrgang Weingut
2168 Creek Shiraz Rot 2003 Creek3456 Zinfandel Rot 2004 Helena2171 Pinot Noir Rot 2001 Creek4961 Chardonnay Weiß 2002 Bighorn
Schallehn Datenmanagement Sommersemester 2019 6–16
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Verbund
Syntax des (natürlichen) Verbundes (engl.: natural join)Relation1 on Relation2
Semantik
r1 on r2 := t | t(R1 ∪ R2) ∧[∀i ∈ 1,2∃ti ∈ ri : ti = t(Ri)]
Verbund verknüpft Tabellen über gleichbenannten Spalten beigleichen Attributwerten
Schallehn Datenmanagement Sommersemester 2019 6–17
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Verbund: Eigenschaften
Schema für r(R) on r(S) ist Vereinigung der AttributmengenRS = R ∪ Saus R1 ∩ R2 = folgt r1 on r2 = r1 × r2
Kommutativität: r1 on r2 = r2 on r1
Assoziativität: (r1 on r2) on r3 = r1 on (r2 on r3)
daher erlaubt:onp
i=1 ri
Schallehn Datenmanagement Sommersemester 2019 6–18
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Verbund: Beispiel
WEINE on ERZEUGER
WeinID Name . . . Weingut Anbaugebiet Region
1042 La Rose Grand Cru . . . Ch. La Rose Saint-Emilion Bordeaux2168 Creek Shiraz . . . Creek Barossa Valley South Australia3456 Zinfandel . . . Helena Napa Valley Kalifornien2171 Pinot Noir . . . Creek Barossa Valley South Australia3478 Pinot Noir . . . Helena Napa Valley Kalifornien4711 Riesling Reserve . . . Müller Rheingau Hessen4961 Chardonnay . . . Bighorn Napa Valley Kalifornien
Schallehn Datenmanagement Sommersemester 2019 6–19
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Umbenennung
Syntaxβneu←alt(Relation)
SemantikβB←A(r) := t ′ | ∃t ∈ r : t ′(R − A) = t(R − A) ∧ t ′(B) = t(A)ändert Attributnamen von alt in neu
βName←Nachname (KRITIKER)
durch Umbenennung nun möglichI Verbunde, wo bisher kartesische Produkte ausgeführt wurden
(unterschiedliche Attribute werden gleich benannt),I kartesische Produkte, wo bisher Verbunde ausgeführt wurden
(gleiche Attribute werden unterschiedlich genannt),I Mengenoperationen
Schallehn Datenmanagement Sommersemester 2019 6–20
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Berechnung des Kreuzproduktes
natürlicher Verbund entartet zum Kreuzprodukt, wenn keinegemeinsamen Attribute existierenErzwingen durch Umbenennung
I Beispiel: R1(A,B,C) und R2(C,D)
R1× R2 ≡ R1 on βE←C(R2)
Kreuzprodukt + Selektion simuliert natürlichen VerbundR1 on R2 ≡ σR1.C=R2.C(R1× R2)
Schallehn Datenmanagement Sommersemester 2019 6–21
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Mengenoperationen: Semantik
formal für r1(R) und r2(R)I Vereinigung r1 ∪ r2 := t | t ∈ r1 ∨ t ∈ r2I Durchschnitt r1 ∩ r2 := t | t ∈ r1 ∧ t ∈ r2I Differenz r1 − r2 := t | t ∈ r1 ∧ t 6∈ r2
Durchschnitt ∩ wegen r1 ∩ r2 = r1 − (r1 − r2) überflüssig
Schallehn Datenmanagement Sommersemester 2019 6–22
Grundlagen von Anfragen: Algebra & Kalkül Anfragealgebren
Unabhängigkeit und Vollständigkeit
Minimale Relationenalgebra:Ω = π, σ, on, β, ∪ und −
unabhängig: kein Operator kann weggelassen werden ohneVollständigkeit zu verlierenandere unabhängige Menge: on und β durch × ersetzenRelationale Vollständigkeit: jede andere Menge von Operationengenauso mächtig wie Ω
strenge relationale Vollständigkeit: zu jedem Ausdruck mitOperatoren aus Ω gibt es einen Ausdruck auch mit der anderenMenge von Operationen
Schallehn Datenmanagement Sommersemester 2019 6–23
Grundlagen von Anfragen: Algebra & Kalkül Erweiterungen der Relationenalgebra
Erweiterungen der Relationenalgebra
weitere VerbundoperationenDivisionGruppierung und geschachtelte Relationen. . .
Schallehn Datenmanagement Sommersemester 2019 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 überexplizit angegebene und evtl. verschiedene Attribute
r(R) onC=D r(S)
Theta-Verbund (engl. θ-join): beliebige Verbundbedingung
r(R) onC>D r(S)
Semi-Verbund: nur Attribute eines Operanden erscheinen imErgebnis
r(L) n r(R) = πL(r(L) on r(R))
äußere Verbunde (engl. outer join)
Schallehn Datenmanagement Sommersemester 2019 6–25
Grundlagen von Anfragen: Algebra & Kalkül Erweiterungen der Relationenalgebra
Äußere Verbunde
Übernahme von „dangling tuples“ in das Ergebnis und Auffüllenmit Nullwertenvoller äußerer Verbund übernimmt alle Tupel beider Operanden
r A./@ s
linker äußerer Verbund übernimmt alle Tupel des linkenOperanden
r A./ s
rechter äußerer Verbund übernimmt alle Tupel des rechtenOperanden
r ./@ s
Schallehn Datenmanagement Sommersemester 2019 6–26
Grundlagen von Anfragen: Algebra & Kalkül Erweiterungen der Relationenalgebra
Äußere Verbunde /2
LINKS A B1 22 3
RECHTS B C3 44 5
on A B C2 3 4
A./@ A B C1 2 ⊥2 3 4⊥ 4 5
A./ A B C1 2 ⊥2 3 4
./@ A B C2 3 4⊥ 4 5
left outer join full outer joinright outer joinnatural join
Schallehn Datenmanagement Sommersemester 2019 6–27
Grundlagen von Anfragen: Algebra & Kalkül Anfragekalküle
Anfragekalküle
Kalkül: eine formale logische Sprache zur Formulierung vonAussagenZiel: Einsatz eines derartigen Kalküls zur Formulierung vonDatenbank-AnfragenLogikbasierter Ansatz:
I Datenbankinhalte entsprechen Belegungen von Prädikaten einerLogik
I Anfragen abgeleiteten Prädikaten
Schallehn Datenmanagement Sommersemester 2019 6–28
Grundlagen von Anfragen: Algebra & Kalkül Anfragekalküle
Ein allgemeiner Kalkül
Motivation: mathematische Notation
x2 | x ∈ N ∧ x3 > 0 ∧ x3 < 1000
Anfrage hat die Formf (x) | p(x)
I x bezeichnet Menge von freien Variablen
x = x1 : D1, . . . , xn : Dn
Schallehn Datenmanagement Sommersemester 2019 6–29
Grundlagen von Anfragen: Algebra & Kalkül Anfragekalküle
Ein allgemeiner Kalkül /2
Funktion f bezeichnet Ergebnisfunktion über xI wichtige Spezialfälle: Angabe einer Variable selber (f ist hier die
Identitätsfunktion) und Tupelkonstruktion (Ergebnis vom Typ tupleof)
p Selektionsprädikat über freien Variablen xI Terme aus Variablen, Konstanten und FunktionsanwendungenI Prädikate der Datentypen, etwa ≤, <, >, ≥, ...→ atomare Formeln über Termen
I Bezug zur aktuellen Datenbank→ Datenbankprädikate, z.B.Relationennamen im RM
I prädikatenlogischen Operatoren ∧, ∨, ¬, ∀, ∃→ Formeln
Schallehn Datenmanagement Sommersemester 2019 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 dasPrädikat p wahr wird.
2 Wende Funktion f auf die durch diese Belegungen gegebenenWerte an.
Unter welchen Umständen liefern Kalkülanfragen endlicheErgebnisse?
→ Sicherheit von Anfragen
Schallehn Datenmanagement Sommersemester 2019 6–31
Grundlagen von Anfragen: Algebra & Kalkül Anfragekalküle
Relationale Kalküle
Bereichskalkül: Variablen nehmen Werte elementarerDatentypen (Bereiche) anTupelkalkül: Variablen variieren über Tupelwerte (entsprechendden Zeilen einer Relation)
Schallehn Datenmanagement Sommersemester 2019 6–32
Grundlagen von Anfragen: Algebra & Kalkül Anfragekalküle
Tupelkalkül
Grundlage von SFW-Anfragen in SQLVariablen sind tupelwertigBeispiel:
w | w ∈ WEINE ∧ w .Farbe = ’Rot’
Schallehn Datenmanagement Sommersemester 2019 6–33
Grundlagen von Anfragen: Algebra & Kalkül Anfragekalküle
Tupelkalkül: Beispiele
konstruierte Tupel
〈w .Name,w .Weingut〉 | w ∈ WEINE ∧ w .Farbe = ’Rot’
Verbund
〈e.Weingut〉 | e ∈ ERZEUGER∧w ∈ WEINE∧e.Weingut = w .Weingut
Schachtelung
〈w .Name,w .Weingut〉 | w ∈ WEINE∧∃e ∈ ERZEUGER(w .Weingut = e.Weingut∧e.Region = ’Bordeaux’)
Schallehn Datenmanagement Sommersemester 2019 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 yund z) im Bedingungsteil existentiell mit ∃ gebundenVollständige Version:
x | ∃y∃zERZEUGER(x , y , z) ∧ z = ’Hessen’
Einsparung von Bereichsvariablen, indem Konstanten alsParameter des Prädikats eingesetzt werden:
x | ERZEUGER(x , y , ’Hessen’)
Schallehn Datenmanagement Sommersemester 2019 6–35
Grundlagen von Anfragen: Algebra & Kalkül Beispiele für Bereichskalkül
Beispiele Bereichskalkül /2
Abkürzung für beliebige, unterschiedliche existentiell gebundeneVariablen ist _ Symbol:
x | ERZEUGER(x ,_, z) ∧ z = ’Hessen’
Verschiedene Auftreten des Symbols _ stehen hierbei fürpaarweise verschiedene Variablen
Schallehn Datenmanagement Sommersemester 2019 6–36
Grundlagen von Anfragen: Algebra & Kalkül Beispiele für Bereichskalkül
Zusammenfassung
formale Modelle für Anfragen in DatenbanksystemenRelationenalgebra
I operationaler AnsatzI Anfrage als Schachtelung von Operatoren auf Relationen
AnfragekalküleI logikbasierter AnsatzI Anfragen als abgeleitete Prädikate
Schallehn Datenmanagement Sommersemester 2019 6–37
Teil VII
SQL als relationale Anfragesprache
SQL als relationale Anfragesprache
SQL als relationale Anfragesprache
1 Der SFW-Block in Detail
2 Erweiterungen des SFW-Blocks
Schallehn Datenmanagement Sommersemester 2019 7–1
SQL als relationale Anfragesprache
SQL als relationale Anfragesprache
1 Der SFW-Block in Detail
2 Erweiterungen des SFW-Blocks
Schallehn Datenmanagement Sommersemester 2019 7–1
SQL als relationale Anfragesprache Der SFW-Block in Detail
Struktur einer SQL-Anfrage
-- Anfrageselect projektionslistefrom 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 2019 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 2019 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 2019 7–4
SQL als relationale Anfragesprache Der SFW-Block in Detail
Tupelvariablen für mehrfachen Zugriff
Einführung von Tupelvariablen erlaubt mehrfachen Zugriff auf eineRelation:
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 2019 7–5
SQL als relationale Anfragesprache Der SFW-Block in Detail
Natürlicher Verbund in SQL92
frühe SQL-Versionen (vor SQL92)I üblicherweise realisierter Standard in aktuellen SystemenI kennen nur Kreuzprodukt, keinen expliziten VerbundoperatorI Verbund durch Prädikat hinter where realisieren
Beispiel für natürlichen Verbund:
select *from WEINE, ERZEUGERwhere WEINE.Weingut = ERZEUGER.Weingut
Schallehn Datenmanagement Sommersemester 2019 7–6
SQL als relationale Anfragesprache Der SFW-Block in Detail
Verbund explizit: natural join
neuere SQL-Versionen (seit SQL92)I kennen mehrere explizite Verbundoperatoren (engl. join)I als Abkürzung für die ausführliche Anfrage mit Kreuzprodukt
aufzufassen
select *from WEINE natural join ERZEUGER
Schallehn Datenmanagement Sommersemester 2019 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 2019 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 2019 7–9
SQL als relationale Anfragesprache Der SFW-Block in Detail
Tupelvariable für Zwischenergebnisse
„Zwischenrelationen“ aus SQL-Operationen oder einemSFW-Block können über Tupelvariablen mit Namen versehenwerden
select Ergebnis.Weingutfrom (WEINE natural join ERZEUGER) as Ergebnis
as ist optional
Schallehn Datenmanagement Sommersemester 2019 7–10
SQL als relationale Anfragesprache Der SFW-Block in Detail
Die select-Klausel
Festlegung der Projektionsattribute
select [distinct] projektionslistefrom ...
mit
projektionsliste := attribut |arithmetischer-ausdruck |aggregat-funktion [, ...]
I Attribute der hinter from stehenden Relationen, optional mit Präfix,der Relationennamen oder Namen der Tupelvariablen angibt
I arithmetische Ausdrücke über Attributen dieser Relationen undpassenden Konstanten
I Aggregatfunktionen über Attributen dieser Relationen
Schallehn Datenmanagement Sommersemester 2019 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 2019 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 CruCreek ShirazZinfandelPinot NoirPinot NoirRiesling ReserveChardonnay
Schallehn Datenmanagement Sommersemester 2019 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 CruCreek ShirazZinfandelPinot NoirRiesling ReserveChardonnay
Schallehn Datenmanagement Sommersemester 2019 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 2019 7–15
SQL als relationale Anfragesprache Der SFW-Block in Detail
Präfixe für Eindeutigkeit
select Name, Jahrgang, Weingut -- (falsch!)from WEINE natural join ERZEUGER
Attribut Weingut existiert sowohl in der Tabelle WEINE als auch inERZEUGER!richtig mit Präfix:
select Name, Jahrgang, ERZEUGER.Weingutfrom WEINE natural join ERZEUGER
Schallehn Datenmanagement Sommersemester 2019 7–16
SQL als relationale Anfragesprache Der SFW-Block in Detail
Tupelvariablen für Eindeutigkeit
bei der Verwendung von Tupelvariablen, kann der Name einerTupelvariablen zur Qualifizierung eines Attributs benutzt werden:
select w1.Name, w2.Weingutfrom WEINE w1, WEINE w2
Schallehn Datenmanagement Sommersemester 2019 7–17
SQL als relationale Anfragesprache Der SFW-Block in Detail
Die where-Klausel
select ...from ...where bedingung
Formen der Bedingung:I Vergleich eines Attributs mit einer Konstanten:
attribut θ konstante
mögliche Vergleichssymbole θ abhängig vom Wertebereich; etwa=, <>, >, <, >= sowie <=.
I Vergleich zwischen zwei Attributen mit kompatiblenWertebereichen:
attribut1 θ attribut2I logische Konnektoren or, and und not
Schallehn Datenmanagement Sommersemester 2019 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.Weingutfrom WEINE, ERZEUGERwhere WEINE.Weingut = ERZEUGER.Weingut
Schallehn Datenmanagement Sommersemester 2019 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 andattrib ≤ konstante2
schränkt damit Attributwerte auf das abgeschlossene Intervall[konstante1, konstante2] einBeispiel:
select * from WEINEwhere Jahrgang between 2000 and 2005
Schallehn Datenmanagement Sommersemester 2019 7–20
SQL als relationale Anfragesprache Der SFW-Block in Detail
Ungewissheitsselektion
Notation
attribut like spezialkonstante
Mustererkennung in Strings (Suche nach mehrerenTeilzeichenketten)Spezialkonstante kann die Sondersymbole ‘%’ und ‘_’ beinhalten
I ‘%’ steht für kein oder beliebig viele ZeichenI ‘_’ steht für genau ein Zeichen
Schallehn Datenmanagement Sommersemester 2019 7–21
SQL als relationale Anfragesprache Der SFW-Block in Detail
Ungewissheitsselektion /2
Beispiel
select * from WEINEwhere Name like ’La Rose%’
ist Abkürzung für
select * from WEINEwhere 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 2019 7–22
SQL als relationale Anfragesprache Der SFW-Block in Detail
Mengenoperationen
Mengenoperationen erfordern kompatible Wertebereiche fürPaare korrespondierender Attribute:
I beide Wertebereiche sind gleich oderI beide sind auf character basierende Wertebereiche (unabhängig
von der Länge der Strings) oderI beide sind numerische Wertebereiche (unabhängig von dem
genauen Typ) wie integer oder float
Ergebnisschema := Schema der „linken“ Relation
select A, B, C from R1unionselect A, C, D from R2
Schallehn Datenmanagement Sommersemester 2019 7–23
SQL als relationale Anfragesprache Der SFW-Block in Detail
Mengenoperationen in SQL
Vereinigung, Durchschnitt und Differenz als union, intersectund 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 2019 7–24
SQL als relationale Anfragesprache Der SFW-Block in Detail
Mengenoperationen in SQL /2
über corresponding by-Klausel: Angabe der Attributliste, überdie Mengenoperation ausgeführt wird
select *from ERZEUGERexcept corresponding by (Weingut) WEINE
bei Vereinigung: Defaultfall ist Duplikateliminierung (uniondistinct); ohne Duplikateliminierung durch union all
Schallehn Datenmanagement Sommersemester 2019 7–25
SQL als relationale Anfragesprache Der SFW-Block in Detail
Mengenoperationen in SQL /2
R A B C
1 2 32 3 4
S A C D
2 3 42 4 5
R union S A B C
1 2 32 3 42 4 5
R union all S A B C
1 2 32 3 42 3 42 4 5
R union corresponding S A C
1 32 42 3
R union corresponding by (A) S A
12
Schallehn Datenmanagement Sommersemester 2019 7–26
SQL als relationale Anfragesprache Der SFW-Block in Detail
Schachtelung von Anfragen
für Vergleiche mit Wertemengen notwendig:I Standardvergleiche in Verbindung mit den Quantoren all (∀) oderany (∃)
I spezielle Prädikate für den Zugriff auf Mengen, in und exists
Schallehn Datenmanagement Sommersemester 2019 7–27
SQL als relationale Anfragesprache Der SFW-Block in Detail
in-Prädikat und geschachtelte Anfragen
Notation:
attribut in ( SFW-block )
Beispiel:
select Namefrom WEINEwhere Weingut in (
select Weingut from ERZEUGERwhere Region=’Bordeaux’)
Schallehn Datenmanagement Sommersemester 2019 7–28
SQL als relationale Anfragesprache Der SFW-Block in Detail
Auswertung von geschachtelten Anfragen
1 Auswertung der inneren Anfrage zu den Weingütern ausBordeaux
2 Einsetzen des Ergebnisses als Menge von Konstanten in dieäußere Anfrage hinter in
3 Auswertung der modifizierten Anfrage
select Namefrom WEINEwhere Weingut in (
’Château La Rose’, ’Château La Pointe’)
Name
La Rose Grand Cru
Schallehn Datenmanagement Sommersemester 2019 7–29
SQL als relationale Anfragesprache Der SFW-Block in Detail
Auswertung von geschachtelten Anfragen /2
interne Auswertung: Umformung in einen Verbund
select Namefrom WEINE natural join ERZEUGERwhere Anbaugebiet = ’Bordeaux’
Schallehn Datenmanagement Sommersemester 2019 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 ERZEUGERwhere Weingut not in (
select Weingut from WEINE )
Schallehn Datenmanagement Sommersemester 2019 7–31
SQL als relationale Anfragesprache Der SFW-Block in Detail
Mächtigkeit des SQL-Kerns
Relationenalgebra SQLProjektion select distinctSelektion where ohne SchachtelungVerbund from, where
from mit join oder natural joinUmbenennung from mit Tupelvariable; asDifferenz where mit Schachtelung
except correspondingDurchschnitt where mit Schachtelung
intersect correspondingVereinigung union corresponding
Schallehn Datenmanagement Sommersemester 2019 7–32
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Weiteres zu SQL
Erweiterungen des SFW-BlocksI innerhalb der from-Klausel weitere Verbundoperationen (äußerer
Verbund),I innerhalb der where-Klausel weitere Arten von Bedingungen und
Bedingungen mit Quantoren,I innerhalb der select-Klausel die Anwendung von skalaren
Operationen und Aggregatfunktionen,I zusätzliche Klauseln group by und having
rekursive Anfragen
Schallehn Datenmanagement Sommersemester 2019 7–33
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Skalare Ausdrücke
Umbenennung von Spalten: ausdruck as neuer-name
skalare Operationen aufI numerischen Wertebereichen: etwa +, −, ∗ und /,I Strings: Operationen wie char_length (aktuelle Länge eines
Strings), die Konkatenation ‖ und die Operation substring(Suchen einer Teilzeichenkette an bestimmten Positionen desStrings),
I Datumstypen und Zeitintervallen: Operationen wie current_date(aktuelles Datum), current_time (aktuelle Zeit), +, − und ∗
bedingte AusdrückeTypkonvertierungHinweise:
I skalare Ausdrücke können mehrere Attribute umfassenI Anwendung ist tupelweise: pro Eingabetupel entseht ein
Ergebnistupel
Schallehn Datenmanagement Sommersemester 2019 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 Alterfrom WEINE
Schallehn Datenmanagement Sommersemester 2019 7–35
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Bedingte Ausdrücke
case-Anweisung: Ausgabe eines Wertes in Abhängigkeit von derAuswertung eines Prädikats
casewhen prädikat1 then ausdruck1...when prädikatn−1 then ausdruckn−1[ else ausdruckn ]
end
Einsatz in select- und where-Klausel
select casewhen Farbe = ’Rot’ then ’Rotwein’when Farbe = ’Weiß’ then ’Weißwein’else ’Sonstiges’
end as Weinart, Name from WEINESchallehn Datenmanagement Sommersemester 2019 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 2019 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 attributfrom ...where ...)
all: where-Bedingung wird erfüllt, wenn für alle Tupel desinneren SFW-Blocks der θ-Vergleich mit attribut true wirdany bzw. some: where-Bedingung wird erfüllt, wenn derθ-Vergleich mit mindestens einem Tupel des inneren SFW-Blockstrue wird
Schallehn Datenmanagement Sommersemester 2019 7–38
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Bedingungen mit Quantoren: Beispiele
Bestimmung des ältesten Weines
select *from WEINEwhere Jahrgang <= all (
select Jahrgang from WEINE)
alle Weingüter, die Rotweine produzieren
select *from ERZEUGERwhere Weingut = any (
select Weingut from WEINEwhere Farbe = ’Rot’)
Schallehn Datenmanagement Sommersemester 2019 7–39
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Vergleich von Wertemengen
Test auf Gleichheit zweier Mengen allein mit Quantoren nichtmöglichBeispiel: „Gib alle Erzeuger aus, die sowohl Rot- als auchWeißweine produzieren.“falsche Anfrage
select Weingutfrom WEINEwhere Farbe = ’Rot’ and Farbe = ’Weiß’
richtige Formulierung
select w1.Weingutfrom WEINE w1, WEINE w2where w1.Weingut = w2.Weingut
and w1.Farbe = ’Rot’ and w2.Farbe = ’Weiß’
Schallehn Datenmanagement Sommersemester 2019 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 istspeziell bei verzahnt geschachtelten (korrelierte) Anfragensinnvoll
I in der inneren Anfrage wird Relationen- oder Tupelvariablen-Nameaus dem from-Teil der äußeren Anfrage verwendet
Schallehn Datenmanagement Sommersemester 2019 7–41
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Verzahnt geschachtelte Anfragen
Weingüter mit 1999er Rotwein
select * from ERZEUGERwhere 1999 in (
select Jahrgang from WEINEwhere Farbe=’Rot’ and WEINE.Weingut = ERZEUGER.Weingut)
konzeptionelle Auswertung1 Untersuchung des ersten ERZEUGER-Tupels in der äußeren
Anfrage (Creek) und Einsetzen in innere Anfrage2 Auswertung der inneren Anfrage
select Jahrgang from WEINEwhere Farbe=’Rot’ and WEINE.Weingut = ’Creek’
3 Weiter bei 1. mit zweitem Tupel . . .Alternative: Umformulierung in Verbund
Schallehn Datenmanagement Sommersemester 2019 7–42
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Beispiel für exists
Weingüter aus Bordeaux ohne gespeicherte Weine
select * from ERZEUGER ewhere Region = ’Bordeaux’ and not exists (
select * from WEINEwhere Weingut = e.Weingut)
Schallehn Datenmanagement Sommersemester 2019 7–43
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Aggregatfunktionen und Gruppierung
Aggregatfunktionen berechnen neue Werte für eine gesamteSpalte, etwa die Summe oder den Durchschnitt der Werte einerSpalteBeispiel: Ermittlung des Durchschnittspreises aller Artikel oderdes Gesamtumsatzes über alle verkauften Produktebei zusätzlicher Anwendung von Gruppierung: Berechnung derFunktionen pro Gruppe, z.B. der Durchschnittspreis proWarengruppe oder der Gesamtumsatz pro Kunde
Schallehn Datenmanagement Sommersemester 2019 7–44
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Aggregatfunktionen
Aggregatfunktionen in Standard-SQL:I count: berechnet Anzahl der Werte einer Spalte oder alternativ (im
Spezialfall count(∗)) die Anzahl der Tupel einer RelationI sum: berechnet die Summe der Werte einer Spalte (nur bei
numerischen Wertebereichen)I avg: berechnet den arithmetischen Mittelwert der Werte einer
Spalte (nur bei numerischen Wertebereichen)I max bzw. min: berechnen den größten bzw. kleinsten Wert einer
Spalte
Schallehn Datenmanagement Sommersemester 2019 7–45
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Aggregatfunktionen /2
Argumente einer Aggregatfunktion:I ein Attribut der durch die from-Klausel spezifizierten Relation,I ein gültiger skalarer Ausdruck oderI im Falle der count-Funktion auch das Symbol ∗
Schallehn Datenmanagement Sommersemester 2019 7–46
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Aggregatfunktionen /3
vor dem Argument (außer im Fall von count(∗)) optional auch dieSchlüsselwörter distinct oder all
I distinct: vor Anwendung der Aggregatfunktion werden doppelteWerte aus der Menge von Werten, auf die die Funktionangewendet wird
I all: Duplikate gehen mit in die Berechnung ein(Default-Voreinstellung)
I Nullwerte werden in jedem Fall vor Anwendung der Funktion ausder Wertemenge eliminiert (außer im Fall von count(∗))
Schallehn Datenmanagement Sommersemester 2019 7–47
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Aggregatfunktionen - Beispiele
Anzahl der Weine:
select count(*) as Anzahlfrom WEINE
ergibtAnzahl
7
Schallehn Datenmanagement Sommersemester 2019 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, Jahrgangfrom WEINEwhere Jahrgang < (select avg(Jahrgang)
from WEINE)
alle Weingüter, die nur einen Wein liefern:
select * from ERZEUGER ewhere 1 = ( select count(*) from WEINE w
where w.Weingut = e.Weingut)
Schallehn Datenmanagement Sommersemester 2019 7–49
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Aggregatfunktionen /2
Schachtelung von Aggregatfunktionen nicht erlaubt
select f1(f2(A)) as Ergebnisfrom R ... -- (falsch!)
mögliche Formulierung:
select f1(Temp) as Ergebnisfrom ( select f2(A) as Temp from R ...)
Schallehn Datenmanagement Sommersemester 2019 7–50
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Aggregatfunktionen in where-Klausel
Aggregatfunktionen liefern nur einen Wert Einsatz inKonstanten-Selektionen der where-Klausel möglichalle Weingüter, die nur einen Wein liefern:
select * from ERZEUGER ewhere 1 = (
select count(*) from WEINE wwhere w.Weingut = e.Weingut)
Schallehn Datenmanagement Sommersemester 2019 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 2019 7–52
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Gruppierung: Schema
Relation REL:A B C D1 2 3 41 2 4 52 3 3 43 3 4 53 3 6 7
. . .
Anfrage:
select A, sum(D) from REL where ...group by A, Bhaving A<4 and sum(D)<10 and max(C)=4
Schallehn Datenmanagement Sommersemester 2019 7–53
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Gruppierung: Schritt 1
from und where
A B C D1 2 3 41 2 4 52 3 3 43 3 4 53 3 6 7
. . .
à
A B C D1 2 3 41 2 4 52 3 3 43 3 4 53 3 6 7
Schallehn Datenmanagement Sommersemester 2019 7–54
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Gruppierung: Schritt 2
group by A, B
A B C D1 2 3 41 2 4 52 3 3 43 3 4 53 3 6 7
à
A B NC D
1 2 3 44 5
2 3 3 43 3 4 5
6 7
Schallehn Datenmanagement Sommersemester 2019 7–55
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Gruppierung: Schritt 3
select A, sum(D)
A B NC D
1 2 3 44 5
2 3 3 43 3 4 5
6 7
à
A sum(D) NC D
1 9 3 44 5
2 4 3 43 12 4 5
6 7
Schallehn Datenmanagement Sommersemester 2019 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 sum(D) NC D
1 9 3 44 5
2 4 3 43 12 4 5
6 7
àA sum(D)1 9
Schallehn Datenmanagement Sommersemester 2019 7–57
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Gruppierung - Beispiel
Anzahl der Rot- und Weißweine:
select Farbe, count(*) as Anzahlfrom WEINEgroup by Farbe
Ergebnisrelation:
Farbe Anzahl
Rot 5Weiß 2
Schallehn Datenmanagement Sommersemester 2019 7–58
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
having - Beispiel
Regionen mit mehr als einem Wein
select Region, count(*) as Anzahlfrom ERZEUGER natural join WEINEgroup by Regionhaving count(*) > 1
Schallehn Datenmanagement Sommersemester 2019 7–59
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Attribute für Aggregation bzw. having
zulässige Attribute hinter select bei Gruppierung auf Relationmit Schema R
I Gruppierungsattribute GI Aggregationen auf Nicht-Gruppierungsattributen R −G
zulässige Attribute für havingI dito
Schallehn Datenmanagement Sommersemester 2019 7–60
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Äußere Verbunde
zusätzlich zu klassischen Verbund (inner join): in SQL-92auch äußerer Verbund Übernahme von „dangling tuples“ in dasErgebnis und Auffüllen mit Nullwertenouter join übernimmt alle Tupel beider Operanden(Langfassung: full outer join)left outer join bzw. right outer join übernimmt alleTupel 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 2019 7–61
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Äußere Verbunde /2
LINKS A B
1 22 3
RECHTS B C
3 44 5
NATURAL JOIN A B C
2 3 4
OUTER A B C
1 2 ⊥2 3 4⊥ 4 5
LEFT A B C
1 2 ⊥2 3 4
RIGHT A B C
2 3 4⊥ 4 5
Schallehn Datenmanagement Sommersemester 2019 7–62
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Äußerer Verbund: Beispiel
select Anbaugebiet, count(WeinID) as Anzahlfrom ERZEUGER natural left outer join WEINEgroup by Anbaubebiet
Anbaugebiet Anzahl
Barossa Valley 2Napa Valley 3Saint-Emilion 1Pomerol 0Rheingau 1
Schallehn Datenmanagement Sommersemester 2019 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 allselect 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 ewhere not exists (
select *from WEINEwhere WEINE.Weingut = e.Weingut)
Schallehn Datenmanagement Sommersemester 2019 7–64
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Sortierung mit order by
Notation
order by attributliste
Beispiel:
select *from WEINEorder by Jahrgang
Sortierung aufsteigend (asc) oder absteigend (desc)Sortierung als letzte Operation einer Anfrage Sortierattributmuss in der select-Klausel vorkommen
Schallehn Datenmanagement Sommersemester 2019 7–65
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Sortierung /2
Sortierung auch mit berechneten Attributen (Aggregaten) alsSortierkriterium
select Weingut, count(*) as Anzahlfrom ERZEUGER natural join WEINEgroup by Weingutorder by Anzahl desc
Schallehn Datenmanagement Sommersemester 2019 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 Rangfrom WEINE w1, WEINE w2where w1.Jahrgang <= w2.Jahrgang -- Schritt 1group by w1.Name, w1.WeinID -- Schritt 2having count(*) <= 4 -- Schritt 3order by Rang -- Schritt 4
Name Rang
Zinfandel 1Creek Shiraz 2Chardonnay 3Pinot Noir 4
Schallehn Datenmanagement Sommersemester 2019 7–67
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Sortierung: Top-k-Anfragen
Ermittlung der k = 4 jüngste WeineErläuterung
I Schritt 1: Zuordnung aller Weine die älter sindI Schritt 2: Gruppierung nach Namen, Berechnung des RangsI Schritt 3: Beschränkung auf Ränge ≤ 4I Schritt 4: Sortierung nach Rang
Schallehn Datenmanagement Sommersemester 2019 7–68
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Behandlung von Nullwerten
skalare Ausdrücke: Ergebnis null, sobald Nullwert in dieBerechnung eingehtin allen Aggregatfunktionen bis auf count(∗) werden Nullwertevor Anwendung der Funktion entferntfast alle Vergleiche mit Nullwert ergeben Wahrheitswert unknown(statt true oder false)Ausnahme: is null ergibt true, is not null ergibt falseBoolesche Ausdrücke basieren dann auf dreiwertiger Logik
Schallehn Datenmanagement Sommersemester 2019 7–69
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Behandlung von Nullwerten /2
and true unknown falsetrue true unknown falseunknown unknown unknown falsefalse false false false
or true unknown falsetrue true true trueunknown true unknown unknownfalse true unknown false
nottrue falseunknown unknownfalse true
Schallehn Datenmanagement Sommersemester 2019 7–70
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Selektionen nach Nullwerten
Null-Selektion wählt Tupel aus, die bei einem bestimmten AttributNullwerte enthaltenNotation
attribut is null
Beispiel
select * from ERZEUGERwhere Anbaugebiet is null
Schallehn Datenmanagement Sommersemester 2019 7–71
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
SQL-Versionen
GeschichteI SEQUEL (1974, IBM Research Labs San Jose)I SEQUEL2 (1976, IBM Research Labs San Jose)I SQL (1982, IBM)I ANSI-SQL (SQL-86; 1986)I ISO-SQL (SQL-89; 1989; drei Sprachen Level 1, Level 2, + IEF)I (ANSI / ISO) SQL2 (als SQL-92 verabschiedet)I (ANSI / ISO) SQL3 (als SQL:1999 verabschiedet)I Seitdem: SQL:2003, SQL:2006, SQL:2008, SQL:2011
trotz Standardisierung: teilweise Inkompatibilitäten zwischenSystemen der einzelnen Hersteller
Schallehn Datenmanagement Sommersemester 2019 7–72
SQL als relationale Anfragesprache Erweiterungen des SFW-Blocks
Zusammenfassung
SQL als StandardspracheSQL-Kern mit Bezug zur RelationenalgebraErweiterungen
Schallehn Datenmanagement Sommersemester 2019 7–73
Teil VIII
Programmierung vonDatenbankanwendungen
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 2019 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 2019 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 2019 8–1
Programmierung von Datenbankanwendungen Grundkonzepte der Programmiersprachenanbindung
Grundkonzepte der Programmiersprachenanbindung
Kopplungsarten:I prozedurale oder CALL-Schnittstellen (call level interface)
F Beispiele: SQL/CLI, ODBC, JDBC, . . .I Einbettung einer DB-Sprache in Programmiersprachen
F statische Einbettung: Vorübersetzer-Prinzip SQL-Anweisungen zur Übersetzungszeit festgelegt
F Beispiele: Embedded SQL, SQLJF dynamische Einbettung: Konstruktion von SQL-Anweisungen zur Laufzeit
I Spracherweiterungen und neue SprachentwicklungenF Beispiele: SQL/PSM, PL/SQL, Transact-SQL, PL/pgSQL
Schallehn Datenmanagement Sommersemester 2019 8–2
Programmierung von Datenbankanwendungen Grundkonzepte der Programmiersprachenanbindung
Cursor-Konzept
Cursor: Iterator über Liste von Tupeln (Anfrageergebnis)
Relation
Cursor
Anwendungsprogramm Datenbank
Schallehn Datenmanagement Sommersemester 2019 8–3
Programmierung von Datenbankanwendungen JDBC als Call Level Interface
JDBC: Überblick
Datenbankzugriffsschnittstelle für Javaabstrakte, datenbankneutrale Schnittstellevergleichbar mit ODBCLow-Level-API: direkte Nutzung von SQLJava-Package java.sql
I DriverManager: Einstiegspunkt, Laden von TreibernI Connection: DatenbankverbindungI Statement: Ausführung von Anweisungen über eine VerbindungI ResultSet: verwaltet Ergebnisse einer Anfrage, Zugriff auf
einzelne Spalten
Schallehn Datenmanagement Sommersemester 2019 8–4
Programmierung von Datenbankanwendungen JDBC als Call Level Interface
JDBC: Struktur
DriverManager Connection
StatementStatement
ResultSet ResultSet
getConnection
createStatement
executeQuery
Schallehn Datenmanagement Sommersemester 2019 8–5
Programmierung von Datenbankanwendungen JDBC als Call Level Interface
JDBC: TreiberkonzeptJava-
Applikation
JDBC-Treibermanager
Native-API-
Treiber
JDBC-ODBC-Bridge
JDBC-Net-
Treiber
Native-Protokoll-Treiber
Client-Bibliothek
Client-Bibliothek
ODBCDB-
Middleware
JDBC-API
Schallehn Datenmanagement Sommersemester 2019 8–6
Programmierung von Datenbankanwendungen JDBC als Call Level Interface
JDBC: Ablauf1 Aufbau einer Verbindung zur Datenbank
I Angabe der VerbindungsinformationenI Auswahl und Laden des Treibers
2 Senden einer SQL-AnweisungI Definition der AnweisungI Belegung von Parametern
3 Verarbeiten der AnfrageergebnisseI Navigation über ErgebnisrelationI Zugriff auf Spalten
Schallehn Datenmanagement Sommersemester 2019 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 spezifiziertDatenquelle/DatenbankVerbindungsmechanismus (Protokoll, Server und Port)
Schallehn Datenmanagement Sommersemester 2019 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 executeQueryAusführung von Änderungsanweisungen (DELETE, INSERT,UPDATE) mit executeUpdate
Schallehn Datenmanagement Sommersemester 2019 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-MethodenI über Spaltenindex
String wname = rset.getString(1);
I über Spaltenname
String wname = rset.getString("Name");
Schallehn Datenmanagement Sommersemester 2019 8–10
Programmierung von Datenbankanwendungen JDBC als Call Level Interface
JDBC: Fehlerbehandlung
Fehlerbehandlung mittels Exception-MechanismusSQLException für alle SQL- und DBMS-Fehler
try // Aufruf von JDBC-Methoden...
catch (SQLException exc) System.out.println("SQLException: "+
exc.getMessage());
Schallehn Datenmanagement Sommersemester 2019 8–11
Programmierung von Datenbankanwendungen JDBC als Call Level Interface
JDBC: Änderungsoperationen
DDL- und DML-Operationen mittels executeUpdateliefert 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 2019 8–12
Programmierung von Datenbankanwendungen JDBC als Call Level Interface
JDBC: Transaktionssteuerung
Methoden von ConnectionI commit ()I rollback ()
Auto-Commit-ModusI implizites Commit nach jeder AnweisungI Transaktion besteht nur aus einer AnweisungI Umschalten mittels setAutoCommit (boolean)
Schallehn Datenmanagement Sommersemester 2019 8–13
Programmierung von Datenbankanwendungen Eingebettetes SQL mit SQLJ und LINQ
SQLJ: Embedded SQL für Java
Einbettung von SQL-Anweisungen in Java-QuelltextVorübersetzung des erweiterten Quelltextes in echten Java-Codedurch Translator sqljÜberprüfung der SQL-Anweisungen
I korrekte SyntaxI Übereinstimmung der Anweisungen mit DB-SchemaI Typkompatibilität der für Datenaustausch genutzten Variablen
Nutzung von JDBC-Treibern
Schallehn Datenmanagement Sommersemester 2019 8–14
Programmierung von Datenbankanwendungen Eingebettetes SQL mit SQLJ und LINQ
SQLJ: Prinzip
SQLJ-Programm
SQLJ-Translator
Java-Quellcode SQLJ-Profile
Java-Compiler Customizer
Bytecode Custom-Profile
JDBC-Treiber
SQLJ-Laufzeitsystem
Syntax- & Semantik-prüfung
Schallehn Datenmanagement Sommersemester 2019 8–15
Programmierung von Datenbankanwendungen Eingebettetes SQL mit SQLJ und LINQ
SQLJ-Anweisungen
Kennzeichnung durch #sql DeklarationenKlassendefinitionen für IteratorenSQL-Anweisungen: Anfragen, DML- und DDL-Anweisungen
#sql SQL-Operation ;
Beispiel:
#sql insert into ERZEUGER (Weingut, Region) values( ’Wairau Hills’, ’Marlborough’) ;
Schallehn Datenmanagement Sommersemester 2019 8–16
Programmierung von Datenbankanwendungen Eingebettetes SQL mit SQLJ und LINQ
Host-Variablen
Variablen einer Host-Sprache (hier Java), die inSQL-Anweisungen auftreten könnenVerwendung: Austausch von Daten zwischen Host-Sprache undSQLKennzeichnung 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 2019 8–17
Programmierung von Datenbankanwendungen Eingebettetes SQL mit SQLJ und LINQ
Iteratoren1 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 2019 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 2019 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 weinewhere w.Farbe = "Rot"select new w.Name ;
Schallehn Datenmanagement Sommersemester 2019 8–20
Teil IX
Transaktionen, Integrität und Trigger
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 2019 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 2019 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 2019 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 2019 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 2019 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 (einzelne) Datenbankzustände,I Zustandsübergänge vom alten in den neuen Datenbankzustand,I langfristige Datenbankentwicklungen
Schallehn Datenmanagement Sommersemester 2019 9–2
Transaktionen, Integrität und Trigger Grundbegriffe
Inhärente Integritätsbedingungen im RM1 Typintegrität:
I SQL erlaubt Angabe von Wertebereichen zu AttributenI Erlauben oder Verbieten von Nullwerten
2 Schlüsselintegrität:I Angabe eines Schlüssels für eine Relation
3 Referentielle Integrität:I die Angabe von Fremdschlüsseln
Schallehn Datenmanagement Sommersemester 2019 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 mehrereReisebüros den Platz als verfügbar identifizierenüberschneidende Kontooperationen einer Bankstatistische Datenbankoperationen→ Ergebnisse sind verfälscht, wenn während der BerechnungDaten geändert werden
Schallehn Datenmanagement Sommersemester 2019 9–4
Transaktionen, Integrität und Trigger Transaktionsbegriff
Transaktion
Eine Transaktion ist eine Folge von Operationen (Aktionen), die dieDatenbank von einem konsistenten Zustand in einen konsistenten,eventuell veränderten, Zustand überführt, wobei das ACID-Prinzipeingehalten werden muss.
Aspekte:I Semantische Integrität: Korrekter (konsistenter) DB-Zustand nach
Ende der TransaktionI Ablaufintegrität: Fehler durch „gleichzeitigen“ Zugriff mehrerer
Benutzer auf dieselben Daten vermeiden
Schallehn Datenmanagement Sommersemester 2019 9–5
Transaktionen, Integrität und Trigger Transaktionsbegriff
ACID-Eigenschaften
Atomicity (Atomarität):Transaktion wird entweder ganz oder gar nicht ausgeführtConsistency (Konsistenz oder auch Integritätserhaltung):Datenbank ist vor Beginn und nach Beendigung einer Transaktionjeweils in einem konsistenten ZustandIsolation (Isolation):Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruckhaben, dass er mit dieser Datenbank alleine arbeitetDurability (Dauerhaftigkeit / Persistenz):nach erfolgreichem Abschluss einer Transaktion muss dasErgebnis dieser Transaktion „dauerhaft“ in der Datenbankgespeichert werden
Schallehn Datenmanagement Sommersemester 2019 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 werdenabort: die Transaktion soll abgebrochen werden
Schallehn Datenmanagement Sommersemester 2019 9–7
Transaktionen, Integrität und Trigger Transaktionsbegriff
Transaktion: Integritätsverletzung
Beispiel:I Übertragung eines Betrages B von einem Haushaltsposten K1 auf
einen anderen Posten K2I Bedingung: Summe der Kontostände der Haushaltsposten bleibt
konstant
vereinfachte NotationTransfer = < 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 2019 9–8
Transaktionen, Integrität und Trigger Transaktionsbegriff
Transaktion: Verhalten bei Systemabsturz
1T
2T
3T
4T
5T
tZeit
Fehler
f
Schallehn Datenmanagement Sommersemester 2019 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 zum Fehlerzeitpunkt noch aktive Transaktionen (T2 und T4)I bereits vor dem Fehlerzeitpunkt beendete Transaktionen (T1, T3
und T5)
Schallehn Datenmanagement Sommersemester 2019 9–10
Transaktionen, Integrität und Trigger Transaktionsbegriff
Probleme im Mehrbenutzerbetrieb
Inkonsistentes Lesen (Nonrepeatable Read): bei wiederholtemLesen würde eine inzwischen von einer anderen Transaktiongeänderter Wert gelesenAbhängigkeiten von nicht freigegebenen Daten (Dirty Read):gelesen Daten, die von einer anderen Transaktion geändertwurden, werde durch einen Abbruch dieser evtl. zurückgesetztDas Phantom-Problem: eine andere Transaktion fügt neue Tupelein oder löscht dieseVerlorengegangenes Ändern (Lost Update): eine Transaktionüberschreibt Änderungen einer anderen
Schallehn Datenmanagement Sommersemester 2019 9–11
Transaktionen, Integrität und Trigger Transaktionen in SQL
Transaktionen in SQL-DBSAufweichung 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 2019 9–12
Transaktionen, Integrität und Trigger Transaktionen in SQL
Bedeutung der Isolationsebenen
read uncommittedI schwächste Stufe: Zugriff auf nicht geschriebene Daten, nur fürread only Transaktionen
I statistische und ähnliche Transaktionen (ungefährer Überblick, nichtkorrekte Werte)
I keine Sperren→ effizient ausführbar, keine anderen Transaktionenwerden behindert
read committedI nur Lesen endgültig geschriebener Werte, aber nonrepeatable read
möglichrepeatable read
I kein nonrepeatable read, aber Phantomproblem kann auftretenserializable
I garantierte Serialisierbarkeit (Ergebnis äquivalent zu einernicht-parallelen Ausführung der Transaktionen)
Schallehn Datenmanagement Sommersemester 2019 9–13
Transaktionen, Integrität und Trigger Integritätsbedingungen in SQL
Integritätsbedingungen in SQL-DDL
not null: Nullwerte verbotendefault: Angabe von Default-Wertencheck ( search-condition ): Attributspezifische Bedingung(in der Regel Ein-Tupel-Integritätsbedingung)primary key: Angabe eines Primärschlüsselforeign key ( Attribut(e))references Tabelle( Attribut(e) ):Angabe der referentiellen Integrität
Schallehn Datenmanagement Sommersemester 2019 9–14
Transaktionen, Integrität und Trigger Integritätsbedingungen in SQL
Integritätsbedingungen: Wertebereiche
create domain: Festlegung eines benutzerdefiniertenWertebereichsBeispiel
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 2019 9–15
Transaktionen, Integrität und Trigger Integritätsbedingungen in SQL
Integritätsbedingungen: check-Klausel
check: Festlegung weitere lokale Integritätsbedingungeninnerhalb der zu definierenden Wertebereiche, Attribute undRelationenschemataBeispiel: Einschränkung der zulässigen WerteAnwendung
create table WEINE (WeinID int primary key,Name varchar(20) not null,Jahr int check(Jahr between 1980 and 2010),...
)
Schallehn Datenmanagement Sommersemester 2019 9–16
Transaktionen, Integrität und Trigger Integritätsbedingungen in SQL
Überprüfungsmodi von Bedingungen
on update | deleteAngabe eines Auslöseereignisses, das die Überprüfung derBedingung anstößtcascade | set null | set default | no actionKaskadierung: Behandlung einiger Integritätsverletzungen pflanztsich über mehrere Stufen fort, z.B. Löschen als Reaktion aufVerletzung der referentieller Integritätdeferred | immediate legt Überprüfungszeitpunkt für eineBedingung fest
I deferred: Zurückstellen an das Ende der TransaktionI immediate: sofortige Prüfung bei jeder relevanten
Datenbankänderung
Schallehn Datenmanagement Sommersemester 2019 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 (Weingut)
on delete cascade)
Schallehn Datenmanagement Sommersemester 2019 9–18
Transaktionen, Integrität und Trigger Integritätsbedingungen in SQL
Die assertion-Klausel
Assertion: Prädikat, das eine Bedingung ausdrückt, die von derDatenbank immer erfüllt sein mussSyntax (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 2019 9–19
Transaktionen, Integrität und Trigger Trigger
Trigger
Trigger: Anweisung/Prozedur, die bei Eintreten eines bestimmtenEreignisses automatisch vom DBMS ausgeführt wirdAnwendung:
I Erzwingen von Integritätsbedingungen („Implementierung“ vonIntegritätsregeln)
I Auditing von DB-AktionenI Propagierung von DB-Änderungen
Schallehn Datenmanagement Sommersemester 2019 9–20
Transaktionen, Integrität und Trigger Trigger
Trigger: Entwurf und Implementierung
Spezifikation vonI Ereignis und Bedingung für Aktivierung des TriggersI Aktion(en) zur Ausführung
Syntax in SQL:2003 festgelegtverfügbar in den meisten kommerziellen Systemen (aber mitanderer Syntax)
Schallehn Datenmanagement Sommersemester 2019 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 insertI update [ of <Liste von Attributen> ]I delete
Schallehn Datenmanagement Sommersemester 2019 9–22
Transaktionen, Integrität und Trigger Trigger
Weitere Angaben bei Triggern
for each row bzw. for each statement: Aktivierung desTriggers für jede Einzeländerungen einer mengenwertigenÄnderung oder nur einmal für die gesamte Änderungbefore bzw. after: Aktivierung vor oder nach der Änderungreferencing new as bzw. referencing old as: Bindeneiner Tupelvariable an die neu eingefügten bzw. geradegelöschten („alten’“) Tupel einer Relation Tupel der Differenzrelationen
Schallehn Datenmanagement Sommersemester 2019 9–23
Transaktionen, Integrität und Trigger Trigger
Beispiel für Trigger
Kein Kundenkonto darf unter 0 absinken:
create trigger bad_accountafter update of Kto on KUNDEreferencing new as INSERTEDwhen (exists
(select * from INSERTED where Kto < 0))begin atomic
rollback;end
ähnlicher Trigger für insert
Schallehn Datenmanagement Sommersemester 2019 9–24
Transaktionen, Integrität und Trigger Trigger
Beispiel für Trigger /2
Erzeuger müssen gelöscht werden, wenn sie keine Weine mehranbieten:
create trigger unnützes_Weingutafter delete on WEINEreferencing old as Ofor each rowwhen (not exists
(select * from WEINE Wwhere W.Weingut = O.Weingut))
begin atomicdelete from ERZEUGER where Weingut = O.Weingut;
end
Schallehn Datenmanagement Sommersemester 2019 9–25
Transaktionen, Integrität und Trigger Trigger
Integritätssicherung durch Trigger
1. Bestimme Objekt oi , für das die Bedingung φ überwacht werdensoll
I i.d.R. mehrere oi betrachten, wenn Bedingungrelationsübergreifend ist
I Kandidaten für oi sind Tupel der Relationsnamen, die in φauftauchen
2. Bestimme die elementaren Datenbankänderungen uij aufObjekten oi , die φ verletzen können
I Regeln: z.B. Existenzforderungen beim Löschen und Ändernprüfen, jedoch nicht beim Einfügen etc.
Schallehn Datenmanagement Sommersemester 2019 9–26
Transaktionen, Integrität und Trigger Trigger
Integritätssicherung durch Trigger /2
3. Bestimme je nach Anwendung die Reaktion ri aufIntegritätsverletzung
I Rücksetzen der Transaktion (rollback)I korrigierende Datenbankänderungen
4. Formuliere folgende Trigger:
create trigger t-phi-ij after uij on oiwhen ¬φbegin ri end
5. Wenn möglich, vereinfache entstandenen Trigger
Schallehn Datenmanagement Sommersemester 2019 9–27
Transaktionen, Integrität und Trigger Trigger
Trigger in Oracle
Implementierung in PL/SQLNotation
create [ or replace ] trigger trigger-namebefore | afterinsert or update [ of spalten ]
or delete on tabelle[ for each row[ when ( prädikat ) ] ]PL/SQL-Block
Schallehn Datenmanagement Sommersemester 2019 9–28
Transaktionen, Integrität und Trigger Trigger
Trigger in Oracle: Arten
Anweisungsebene (statement level trigger): Trigger wird ausgelöstvor bzw. nach der DML-AnweisungTupelebene (row level trigger): Trigger wird vor bzw. nach jedereinzelnen 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 für delete: nur (:old.col)I für insert: nur (:new.col)I in when-Klausel nur (new.col) bzw. (old.col)
Schallehn Datenmanagement Sommersemester 2019 9–29
Transaktionen, Integrität und Trigger Trigger
Trigger in Oracle /2
Transaktionsabbruch durchraise_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 2019 9–30
Transaktionen, Integrität und Trigger Trigger
Trigger in Oracle: Beispiel
Kein Kundenkonto darf unter 0 absinken:
create or replace trigger bad_accountafter insert or update of Kto on KUNDEfor each rowwhen (:new.Kto < 0)begin
raise_application_error(-20221,’Nicht unter 0’);
end;
Schallehn Datenmanagement Sommersemester 2019 9–31
Transaktionen, Integrität und Trigger Trigger
Zusammenfassung
Zusicherung von Korrektheit bzw. Integrität der Dateninhärente Integritätsbedingungen des Relationenmodellszusätzliche SQL-Integritätsbedingungen: check-Klausel,assertion-AnweisungTrigger zur „Implementierung“ von Integritätsbedingungen bzw.-regeln
Schallehn Datenmanagement Sommersemester 2019 9–32