Sie sind auf Seite 1von 113

2

e
ng t e m
u
rles sys
Vo ns
t io
a
o rm Modul 1
f
In

Grundlagen von
Datenbanken

a.Univ.-Prof. Dr. Werner Retschitzegger

Department of
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Inhalt

n Einführung
l Motivation und Historie
l Architektur
l Existierende Systeme
n Konzeptionelle Datenmodelle
n Realisierungs-Datenmodelle
n Datenbankentwurf
n SQL

Der vorliegende Foliensatz basiert vorwiegend auf:


n Gunter Saake, Kai-Uwe Sattler, Andreas Heuer: Datenbanken – Konzepte und Sprachen,
MITP Verlag, 6. Auflage, 800 Seiten, 2018

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 2/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Motivation
Ohne Datenbanken ... 1/2

n Basis- oder Anwendungssoftware verwaltet ihre eigenen


Daten in ihren eigenen (Datei-)Formaten
l Textverarbeitung: Texte, Artikel und Adressen
l Buchhaltung: Artikel, Adressen
l Lagerverwaltung: Artikel, Aufträge
l Auftragsverwaltung: Aufträge, Artikel, Adressen
l ...

n Daten sind redundant gespeichert – zahlreiche Probleme:


l Verschwendung von Speicherplatz
l „Vergessen“ von Änderungen (_ Anomalien)
l keine zentrale, „genormte“ Datenhaltung

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 3/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Motivation
Ohne Datenbanken ... 2/2

n Andere SW-Systeme können große Datenmengen


nicht effizient verarbeiten

n Mehrere Benutzer oder Anwendungen können


nicht parallel auf den gleichen Daten arbeiten

n Anwendungsprogrammierer / Benutzer können Anwendungen


nicht programmieren / benutzen, ohne
l interne Darstellung der Daten
l Speichermedien oder Rechner
zu kennen – Datenunabhängigkeit nicht gewährleistet

n Datenschutz und -Sicherheit sind nicht gewährleistet

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 4/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Motivation
Mit Datenbanken ... Datenintegration

n Die gesamte Anwendungs-SW arbeitet auf


denselben Daten
l z.B. Adressen und Artikel werden nur einmal gespeichert
n DBS können große Datenmengen effizient verwalten
l Anfragesprachen, Optimierung, Interne Ebene
n Benutzer können parallel auf DB arbeiten
l Transaktionskonzept
n Datenunabhängigkeit
l Drei-Ebenen-Konzept
n Datenschutz
l kein unbefugter Zugriff
n Datensicherheit
l kein ungewollter Datenverlust

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 5/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Motivation
Historie

n Anfang 60er Jahre


l elementare Dateien, anwendungsspezifische Datenorganisation
l geräteabhängig, redundant, inkonsistent

n Ende 60er Jahre


l Dateiverwaltungssysteme (SAM, ISAM)
mit Dienstprogrammen (Sortieren)
l geräteunabhängig, aber redundant und inkonsistent

n 70er Jahre
l Datenbanksysteme
l Geräte- und Datenunabhängigkeit, redundanzfrei, konsistent

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 6/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Motivation
Historie von Relationalen DBS

n 1970: Edgar F. Codd (IBM) _ Relationenmodell


als konzeptionelle Grundlage von RDBS E. F. Codd
(Turing Award 1981)

n 1974: System R (IBM) _ erster Prototyp eines RDBS


l Anfragesprache SEQUEL
l erste Installation 1977

n 1975: University of California at Berkeley _ Ingres


l Anfragesprache QUEL
l Vorgänger von Postgres, Sybase, . . .

n 1979: Oracle Version 2


n ...

Codd E.F.: A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM, Volume 13, Issue 6, 377-387, 1970

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 7/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Architektur
Die Codd'schen Regeln (1985!)

1. Integration
w einheitliche, nichtredundante Datenverwaltung
2. Operationen
w Speichern, Suchen, Ändern, Einfügen
3. Katalog
w Zugriffe auf Datenbankbeschreibungen im Data Dictionary
4. Benutzersichten
w Sichten auf eine Datenbank
5. Integritätssicherung
w Korrektheit des Datenbankinhalts
6. Datenschutz
w Ausschluss unauthorisierter Zugriffe
7. Transaktionen
w mehrere DB-Operationen als Funktionseinheit
8. Synchronisation
w parallele Transaktionen koordinieren
9. Datensicherung
w Wiederherstellung von Daten nach Systemfehlern
w ...

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 8/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Architektur
Komponenten eines DBS im Überblick

n Besteht aus
l einer oder mehreren Datenbanken (DB)
l einem Data Dictionary (DD)
l und einem Datenbankmanagementsystem (DBMS)

Anwendung 1 Anwendung 2 ... Anwendung n Software für die


Definition, Konstruktion
und Manipulation von
DBMS (Datenbankmanagementsystem) Datenbanken

DD (Data DB 1 DB n
Dictionary (Daten- ...
Gespeicherte mit DB- bank)
Datenbank- Schema)
definition
(Metadaten)
DBS (Datenbanksystem)

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 9/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Architektur
Komponenten eines DBS im Detail
Anwendungs-
programmierer

Anwendungsprogramme
Gelegentliche
Datenbankadministrator Benutzer
Pre-Compiler
Host Language
DDL-Anweisungen Privilegierte Befehle Interaktive Anfrage
Compiler

Anfrage- DML- Kompilierte


Übersetzer Anweisungen (vorgeplante)
Transaktionen
DDL-Compiler Data DML-Compiler
Dictionary
Laufzeit-
komponente
des Daten-
banksystems

Storage Subsysteme für Nebenläufigkeitskontrolle,


Manager Datensicherung und Wiederverwendung

Datenbank
COOPERATIVE INFORMATION SYSTEMS, JKU Linz 10/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Architektur
Drei-Schichten-Architektur 1/3

Benutzer

EXTERNE Externes Schema ... Externes Schema


Ebene

Anfragebearbeitung

Datendarstellung
externe/konzeptuelle Abbildung Logische Datenbankunabhängigkeit

KONZEPTUELLE/ Konzeptuelles/logisches Schema


LOGISCHE
Ebene Physische Datenbankunabhängigkeit
konzeptuelle/interne Abbildung
Internes/physisches Schema
INTERNE/
PHYSISCHE
Ebene

Gespeicherte Datenbank
Standardisiert: ANSI/X3/SPARC
COOPERATIVE INFORMATION SYSTEMS, JKU Linz 11/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Architektur
Drei-Schichten-Architektur 2/3

n Konzeptuelles / logisches Schema


l = Ergebnis der Datenmodellierung/-definition
n Internes / physisches Schema
l = Tabellen mit SQL-Befehlen erzeugen, Dateiorganisation,
Zugriffspfade und Hilfsstrukturen aufbauen
n Externes Schema
l = Ergebnis der Sichtdefinition

auf jeder Ebene

n Trennung Schema – Instanz


l Schema (DB-Struktur, Metadaten) – „Intension“
l Instanz (DB-Inhalt, -zustand bzw. -ausprägung) – „Extension“

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 12/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Architektur
Drei-Schichten-Architektur 3/3

n Physische Datenunabhängigkeit
“Implementierungsunabhängigkeit“
l Änderungen der Dateiorganisationen und Zugriffspfade
haben keinen Einfluss auf das konzeptuelle Schema

n Logische Datenunabhängigkeit
“Anwendungsunabhängigkeit“
l eventuell externe Schemata betroffen (Ändern von
Attributen)

l eventuell Anwendungsprogramme betroffen –


Rekompilieren der Anwendungsprogramme, eventuell
Änderungen nötig

l nötige Änderungen werden jedoch vom DBMS erkannt und


überwacht

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 13/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Existierende Systeme
Eigenschaften von RDBS im Überblick

n Drei-Ebenen-Architektur nach ANSI-SPARC nur zum Teil

n SQL als einheitliche Datenbanksprache

n Einbettung von SQL in Programmiersprachen

n Diverse Werkzeuge für Definition, Anfrage, Darstellung von


Daten, Entwurf und Benutzer-Interaktion

n Kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle und


Datensicherheitsmechanismen

n Verfügbar für die wichtigsten Betriebssystemplattformen


(auch Microsoft SQL Server seit 2017 für Linux verfügbar!)

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 14/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Existierende Systeme
Entwicklungshistorie von RDBS

n Umfassende Liste von RDBS


http://de.wikipedia.org/wiki/Datenbank_%28Liste%29

Chamberlin, D.D., et al.: A History and Evaluation of the System R,


Communications of the ACM (CACM), 24(10), October 1981

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 15/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Existierende Systeme
Open Source RDBS – Beispiele

n MySQL (www.mysql.com)
l weit verbreitet (Linux, Solaris, Windows)
l gute SQL-Unterstützung
l keine Stored Procedures- und Trigger-Unterstützung
l eingeschränkte Transaktionsunterstützung
n Firebird (www.firebirdsql.org)
l weit verbreitet (Linux, Solaris, Windows)
l gute SQL-Unterstützung
l kompakt, geringer Speicherbedarf
l unterstützt verteilte Transaktionen
n PostgreSQL (www.postgresql.org)
l umfangreiches Angebot an Erweiterungen durch Dritthersteller,
wie z. B. PostGIS zur Verwaltung von Geo-Daten
l PostgreSQL ist in den meisten Linux-Distributionen enthalten
l Apple liefert PostgreSQL als Standarddatenbank aus

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 16/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Existierende Systeme
Einsatzgebiete von RDBS

n Klassische Einsatzgebiete
l Große Datenmengen, viele Nutzer
l Wohlstrukturiertes Schema
l Redundanzfreiheit
l Flexibel abfragbar
l Von mehreren Anwendungen gleichzeitig nutzbar, bei hoher
Aktualität der Daten
l Ausfallsicherheit
l ...

n Grenzen
l Flexible Schemata
l Gezielte Redundanzen zur Performanz-Steigerung
l "Unschärfe" bei Abfragen – „similarity search“
l Flexibles Konsistenzmodell
l …

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 17/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Existierende Systeme
Klassifikation von DBS

n Hierarchische Systeme
l z.B. IMS/IBM

n Netzwerkmodell-basierte Systeme
l z.B. UDS/Siemens
n (Objekt)-Relationale Systeme
l z.B. Oracle, DB2, SQLServer

n Objektorientierte Systeme
l z.B. ObjectStore, Poet, Versant, GemStone

n XML-basierte Systeme
l z.B. TAMINO/Software AG, eXcelon
n NoSQL-Systeme
l z.B. MongoDB, Hbase, Cassandra

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 18/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Existierende Systeme
Non-Standard Anwendungsbereiche

n Multimedia
l Verwaltung multimedialer Objekte (Bilder, Audio, Video)

n Verteilte Datenhaltung
l Verteilung von Daten auf verschiedene Rechnerknoten

n Föderierte Datenbanken, Multidatenbanken, Mediatoren


l Integration von Daten heterogener Quellen (z.B. Web)

n Mobile Datenbanken
l Datenverwaltung auf Kleinstgeräten (PDA, Handy, . . . )

n Data Warehouses
l Datenverwaltung für Analysezwecke

n …

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 19/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Inhalt

n Einführung
n Konzeptionelle Datenmodelle
l Modellbegriff
l Datenmodelle
l Vorgehensmodell für den DB-Entwurf
l ER-Modelle
l Objektorientierte Modelle – UML
n Realisierungs-Datenmodelle
n Datenbankentwurf
n SQL

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 20/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Modellbegriff
Abbildungsmerkmal

n Ein Modell stellt eine Abstraktion eines Realitätsausschnitts


dar
l Um Information verständlicher darzustellen
l Um essentielle Systemaspekte aufzuzeigen
l Zur Kommunikation (Projektmitarbeiter, Kunden)
l Um komplexe Architekturen darstellen zu können
n Ein Diagramm ist die grafische Repräsentation eines
Modells bzw. eines Modell-Ausschnitts
cd A Person

Platz
Sitzplatz
Reihe
EndeZeit=BeginnZeit+Film.Dauer N

Assistent Mitarbeiter
EndeZeit
Kino
1 BeginnZeit
reserviert
besitzt Datum
N 1 ReservierungsNr
1 N 1 N
Saal spieltIn Vorführung gehörtZu Reservierung Verfallsdauer
1 N N N

Realitäts-
Verfallszeit
SaalNr Verfallszeit=
hat macht Vorführung.BeginnZeit -

Modell
Bezeichnung Verfallsdauer

Sicht Sicht
Anz. Reihen 1
1 ID
Anz. Plätze

ausschnitt Modell
Film Person Vorname
entwertenKarten
Code Nachname
giltFür
Titel IS_A IS_A

Dauer
Mitarbeiter Besucher
FreigegebenAb 1
Kartenabreißer SVNr
N IS_A
Platz IS_A Adresse
Eintrittskarten Preis Name
Reihe
IS_A Produkt N verkaufen 1 Verkäufer arbeitetAn Ticketschalter
GNr N N
Gutschein

Diagramme
Gültigkeit

Modell: Konkretes oder gedankliches Abbild eines vorhandenen Gebildes


(~Realitätsausschnitt) oder Vorbild für ein zu schaffendes Gebilde in der
COOPERATIVE INFORMATION
Wahrnehmung SYSTEMS
der beteiligten
, JKU LinzPersonen für einen bestimmten Verwendungszweck. 21/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Modellbegriff
Verkürzungsmerkmal

n Modelle erfassen meist nicht alle Individuen und Attribute des


Originals
l Bewusste Abstraktion
n Es wird nur das modelliert, was den Modellschaffenden
wichtig/nützlich/notwendig erscheint
l Wahrnehmung, Erfahrung, Erkenntnis der Personen
n Das Modell kann Individuen und Attribute enthalten, die
keine Entsprechung im Original haben

Bsp:

Original Modell

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 22/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ein Datenmodell

n Ein Datenmodell ist eine Menge von Konzepten zur


Beschreibung der Syntax und Semantik von Daten
n Es sollten 3 Aspekte spezifiziert werden können:
1. Statische Eigenschaften
a. Objekte
b. Beziehungen
inklusive der Standard-Datentypen, die Daten über die
Beziehungen und Objekte darstellen können
2. Dynamische Eigenschaften
a. Operationen
b. Beziehungen zwischen Operationen
3. Integritätsbedingungen an
a. Objekte
b. Operationen

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 23/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Arten von Datenmodellen

n Klassische Datenmodelle sind speziell geeignet für


l große Informationsmengen mit relativ starrer Struktur und
l die Darstellung statischer Eigenschaften und
Integritätsbedingungen (also die Bereiche 1(a), 1(b) und 3(a))

n Konzeptionelle (Analyse/Entwurfs-) Modelle


l (E)ER-Modell
l UML

n Realisierungsmodelle
l Relationenmodell
l Objektorientierte Modelle
l Semistrukturierte Modelle

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 24/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Vorgehensmodell für den DB-Entwurf

Konzeptionelles (Analyse/Entwurfs-) Modell

Phase Modell Ergebnis


ANF 5.4: Eine Rechnung wird durch
Anforderungs- Anforderungs- Pflichtenheft Realitäts- eine fortlaufende RechNr. eindeutig
ausschnitt identifiziert und kann sich auf eine
analyse modell (Use-Cases, ...)
Bestellung beziehen. ...

Konzeptioneller Entity Relationship Konzeptuelles Modell


Entwurf (UML, ...) DB-Schema

relational
(hierarchisch, objekt-
Logischer orientiert, objekt- Logisches Rechnung(RechNr, Datum, ...)
Entwurf relational, semi- DB-Schema Bestellung(BestellNr, Datum, ...)
strukturiert, ...)

CREATE TABLE Rechnung (


Physischer Data Definition Physisches Oracle, DB2, RechNr NUMBER(10) PRIMARY KEY,
Entwurf Language DB-Schema SQLServer,
Datum DATE,
MySql, ...
...
);
Realisierungsmodell

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 25/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Das ER-Modell
n Das Entity-Relationsship-Modell wurde 1976 in einem
wegweisenden Aufsatz von Peter Chen vorgestellt
Dr. Peter Chen

n Wie der Name schon ausdrückt, modelliert dieses Modell


Gegenstände (Entities) und die Beziehungen
(Relationships) zwischen diesen

n Notation wurde später erweitert ð EER-Modell

n Viele unterschiedliche graphische Notationen – die


Konzepte (Entity, Relationship, Attribut, Schlüssel, Rolle) sind
jedoch überall dieselben

Chen P.: The Entity-Relationship Model - Toward a Unified View of Data.


ACM Transactions on Database Systems, Band 1, Nr. 1, 9-36, 1976
(http://bit.csc.lsu.edu/~chen/pdf/erd.pdf)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 26/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Das ER-Modell
Grundkonzepte

n Entity
l Objekt der realen oder der Vorstellungswelt, über das
Informationen zu speichern sind z.B. Produkt, Hersteller oder
Kunde
l aber auch Informationen über Ereignisse, wie z.B. Bestellungen
n Relationship
l beschreibt eine Beziehung zwischen Entities, z.B. ein Kunde
bestellt ein Produkt oder ein Hersteller liefert ein Produkt
n Attribut
l repräsentiert eine Eigenschaft von Entities oder Beziehungen,
z.B. Name eines Kunden, Bezeichnung eines Produktes oder
Datum einer Bestellung

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 27/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Das ER-Modell
Beispiel

RechNr Datum BestellNr Datum Menge Preis

1 bezieht 1 m n
Rechnung sich Bestellung umfasst Produkt Bezeichnung
n m
ProduktNr

1
Versand bestellt liefert

Name Telefon LieferantenNr


1 n
Kunde Lieferant Name

Adresse
KundenNr Name
Adresse

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 28/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Das ER-Modell
Einschätzung

n ER-Diagramme sind eine weit verbreitete Art der


konzeptuellen Modellierung

n Die Konzepte sind nicht allzu schwer zu begreifen, d.h.


der Sachverhalt kann auch mit Domain-Experten (die den
Fachbereich kennen) diskutiert werden

n Prinzipiell „mit Papier und Bleistift“ verwendbar, doch auch


von Werkzeugen unterstützt

n Wegen Einschränkungen vermehrt Verdrängung der ER-


Diagramme durch objektorientierte Modelle (UML)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 29/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Objektorientierte Datenmodelle

n Seit Beginn der 90er Jahre Booch, Jacobson, Rumbaugh

l Ansätze für OO Analyse und Entwurf

n Ansätze der ersten Generation


l OMT – Object Modeling Technique
(J. Rumbaugh et al.)
¡ Starker Bezug zur Datenmodellierung
(erweiterte ER-Diagramme)
l Booch-Methode (Grady Booch)
¡ Starker Programmiersprachenbezug
(Modellierung von Echtzeitsystemen)
l OOSE – Object-Oriented Software Engineering
(I. Jacobson)
¡ Stark in der Beschreibung von Anforderungen
(Use-Case-orientiert)

n Ab Mitte der 90er Jahre


l Vereinheitlichung zur Unified Modeling Language (UML)
OMG: http://www.omg.org/technology/documents/formal/uml.htm
OMG UML Resource Page: www.uml.ac.at/

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 30/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Objektorientierte Datenmodelle
Ziele von UML

n Bereitstellung einer ausdrucksstarken


Modellierungssprache
l Zur Formulierung unterschiedlicher Typen
von Modellen
l Zum Austausch von Modellen
l Zur Spezifikation, Konstruktion, Visualisierung und
Dokumentation der Artefakte eines SW-Systems

n Bedeutung des Begriffs »Unified«


l Unterstützung des gesamten Entwicklungsprozesses
l Flexibilität in Bezug auf Vorgehensmodelle
l Unabhängigkeit von Entwicklungswerkzeugen und –plattformen,
sowie Programmiersprachen
l Einsetzbarkeit für verschiedenste Anwendungsbereiche
l Generizität der Sprachkonzepte u. in einem Metamodell definiert

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 31/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Objektorientierte Datenmodelle
Historische Entwicklung von UML
Konsolidierung
2015 UML 2.5 Öffentliches
Feedback
Fundamentale UML 2
2005 Neuerungen
Erweiterung
Öffentliches
2004 Aktionsmodell Feedback

2003 UML 1.5 Industrialisierung


Komponenten,
2002 Profile,
Kollaboration
2001 UML 1.4 Öffentliches
Feedback
2000 XMI

1999 UML 1.3


OCL
1998 Standardisierung
UML 1.1
durch OMG
1997
UML 1
Öffentliches
1996 UML 0.9 Feedback

1995 Unified Method 0.8 Vereinheitlichung

Diverse Fragmentierung
OOAD OMT OOSE
Methoden

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 32/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL
Anwendungsfalldiagramm
Objektorientierte Datenmodelle
UML-Diagrammarten

Diagrammart

Strukturdiagramm Verhaltensdiagramm

Klassen- Paket- Komponenten- Verteilungs- Anwendungsfall- Zustands-


diagramm diagramm diagramm diagramm diagramm diagramm

Objekt- Kompositionsstruktur- Interaktions- Aktivitäts-


diagramm diagramm diagramm diagramm

Sequenz- Kommunikations- Zeit- Interaktionsübersichts-


diagramm diagramm diagramm diagramm
Klassendiagramm

Paketdiagramm
COOPERATIVE INFORMATION SYSTEMS Sequenzdiagramm
, JKU Linz 33/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Objektorientierte Datenmodelle
Beispiel UML-Klassendiagramm

1 1
CALENDARIUM
verwaltet verwaltet

Personengruppe *
* Eintrag
* nimmtTeil
* Benutzer 1..* * {abstract} Kalender
* 1..*
ergehtAn name /auszeichnung: Farbe gehörtZu istOffen: bool
1..* berechtigung beschreibung: String {ordered} *
* typ: Termintyp
stelltDar
Notifikation 0..3 erinnertAn 1
*
Ansicht
Termin Serie ToDoEintrag
beginn: DatumZeit whDauer fälligPer: Datum
dauer: Zeit whFrequenz 1..*
hyperlink [0..1]: URL 0..1 0..1
* anzahlTermine: Int {ordered}
/kollidiertMit
* 1..* {xor}
{ordered}

vgl.: W. Retschitzegger, E. Kapsammer, M. Hitz, G. Kappel: UML@Work. dpunkt.verlag

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 34/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Inhalt

n Einführung
n Konzeptionelle Datenmodelle
n Realisierungs-Datenmodelle
l Relationenmodell
l NF2-Datenmodell
l Objektorientierte Modelle
l Semistrukturierte Modelle – XML
n Datenbankentwurf
n SQL

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 35/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Datenmodelle für die Realisierung

n Klassische Datenmodelle
l Hierarchisches Datenmodell
l Netzwerk-Datenmodell
l Relationenmodell
n Erweiterte relationale Datenmodelle
l NF2-Datenmodell
n Objektorientierte Datenmodelle
n Semistrukturierte Datenmodelle
l eXtensible Markup Language (XML)

Zeichnen sich dadurch aus, dass sie


§ weniger abstrakt und
§ implementierungsnäher sind sowie
§ mit konkreten Anfrage- und Änderungs-
operationen verbunden sind
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 36/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Relationenmodell
Grundkonzepte 1/3

n E.F. Codd im Jahre 1970 entwickelt (ð Turing Award)

Relationenname Attribut(-namen)

R A1 ... An Relationenschema

... ... ...


Tupel Relation
... ... ...

Attributwerte

Codd E.F.: A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM, Volume 13, Issue 6, 377-387, 1970

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 37/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Relationenmodell
Grundkonzepte 2/3

n Jede Zeile (Tupel) ist eindeutig und beschreibt ein Objekt


der Realität
n Die Ordnung der Zeilen
l ... ist ohne Bedeutung; durch ihre Reihenfolge wird keine für den
Benutzer relevante Information ausgedrückt
n Die Ordnung der Spalten
l ... ist ohne Bedeutung, da sie einen eindeutigen Namen
(Attributnamen) tragen
n Jeder Datenwert innerhalb einer Relation ist ein
atomares Datenelement
n Alle für den Benutzer bedeutungsvollen Informationen
sind ausschließlich durch Datenwerte ausgedrückt
n Es existiert ein Primärschlüssel

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 38/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Relationenmodell
Grundkonzepte 3/3

Begriff Informale Bedeutung


Attribut Spalte einer Tabelle
Wertebereich Mögliche Werte eines Attributs (Domäne)
Attributwert Element eines Wertebereichs
Relationenschema Menge von Attributen
Relation Menge von Zeilen einer Tabelle (Ausprägung eines
Relationenschemas)

Tupel Zeile einer Tabelle


Datenbankschema Menge von Relationenschemata
Datenbank Menge von Relationen (Basisrelationen)
Schlüssel Minimale Menge von Attributen, deren Werte ein Tupel
einer Tabelle eindeutig identifizieren

Primärschlüssel Ein beim DB-Entwurf ausgezeichneter Schlüssel


Fremdschlüssel Attributmenge, die in anderer Relation Schlüssel ist

Fremdschlüssel- Alle Attributwerte des Fremdschlüssels erscheinen


bedingung in der anderen Relation als Werte des Schlüssels

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 39/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Relationenmodell
Schlüssel

n Attribute einer Spalte identifizieren eindeutig gespeicherte


Tupel ð Schlüsseleigenschaft
l etwa KNr für Tabelle Kunde
Kunde
KNr Vorname Name PLZ Ort

101 Karl Maier 4040 Linz

102 Franz Huber 4232 Hagenberg

103 Hans Humer 1010 Wien

n Auch Attributkombinationen können Schlüssel sein


n Schlüssel soll minimal sein
n Kein Schlüsselwert darf NULL sein
Ø Entitätsintegrität!

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 40/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Relationenmodell
Fremdschlüssel 1/2

n Schlüssel einer Tabelle können in einer anderen (oder


derselben) Tabelle als eindeutige Verweise genutzt
werden ("relationenübergreifende Information")
n Etwa Produkt.HerstNr als Verweis auf Hersteller.HerstNr
n Fremdschlüssel = Schlüssel in einer "fremden" Tabelle

Produkt Fremdschlüssel Hersteller Primärschlüssel


ProduktNr Bezeich Preis Bestand HerstNr HerstNr Name
101 x 99.0 77 10 10 A

102 y 77.6 60 11 11 B

103 z 55.7 2 11 12 C

104 w 66.5 100 12 referenzierte Relation


referenzierende Relation
Primär- und Fremdschlüssel
müssen gleichen Wertebereich
Ø Referenzielle Integrität! haben!

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 41/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Relationenmodell
Fremdschlüssel 2/2

n Fremdschlüssel können Nullwerte aufweisen


l wenn sie nicht Teil eines Primärschlüssels sind oder
l wenn nicht explizit NOT NULL spezifiziert ist

n Eine Relation kann mehrere Fremdschlüssel besitzen


l welche die gleiche oder verschiedene Relationen
referenzieren

n Fremdschlüssel kann auch die eigene Relation


referenzieren ("self-referencing table")

n Zyklen sind möglich

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 42/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

NF2-Relationenmodell

n Zweck
l Verarbeitung komplexer Attributwerte
l Strukturierte und mengenwertige Attribute

n Merkmale
l Nichtatomare Attributwerte werden zugelassen (1.NF wird nicht
gefordert - Non First Normal Form - NFNF _ NF2)
l Attributwerte können demnach atomar oder wiederum
Relationen sein _ "geschachtelte" Relationen
l Operationen zum Schachteln (Nesting) und Entschachteln von
Relationen notwendig

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 43/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

NF2-Relationenmodell
Beispiel einer NF2-Relation

Lehrpersonal
Studiengang Belegschaft
PersNr Nachname Telefone Eintrittsjahr
Telefon
07236-3888-2020
101 Dobler 1996
0664-3476543

Software Engineering 102 Kurschl 07236-3888-2029


2001

07236-3888-2023
103 Altmann 2005
0669-8765434
0732-594054

07236-3888-2024
104 Hinterholzer 1998

07236-3888-2700
Bioinformatik 144 Pröll 1999
0676-3456789

Attribut Belegschaft enthält


mehrspaltige Untertabelle Attribut Telefone enthält
einspaltige Untertabelle
(Multiple Felder)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 44/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Objektorientierte Datenmodelle

n Merkmale
l Objekte
l Objektidentität (unveränderliche OIDs)
l Kapselung
l Typen, Klassen und Beziehungen
l Spezialisierung
n Entwicklungslinien
l Erweiterung objektorientierter Programmiersprachen
(z.B. ObjectStore, Poet)
l komplette Neuentwicklungen (z.B. O2)
l Erweiterung von RDBS
_ Objektrelationale DBS
z.B. Oracle, IBM DB2, SQL Server
Weiterentwicklung von SQL2 zu SQL3 (enthält oo Konzepte!)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 45/113


B
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Semistrukturierte Datenmodelle
XML 1/2
h
n Strukturierung der Daten
l nicht immer sinnvoll, oft nicht bekannt, oft nicht für alle
Dokumente gleich, oft nicht gewünscht, oft zu aufwendig,
wechselt oft, ...
l optionale Teile
l Wiederholungen
l Reihenfolge relevant

n Schema implizit in jedem Dokument enthalten und explizit


über Schemadefinitionssprachen spezifizierbar
l Zwei W3C-Standards für XML (eXtensible Markup Language) –
DTD (Document Type Definition) und XML-Schema
l Grammatiken zur Definition XML-basierter Sprachen –
erlaubte Tag-Namen, mögliche Schachtelung, Datentypen, etc.

n Zugriff auf semistrukturierte Daten pfadorientiert


l W3C-Standard XPath

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 46/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Semistrukturierte Datenmodelle
XML 2/2

UML Klassendiagramm XML-Dokument


...
HandyKatalog <!DOCTYPE HandyKatalog [
<!ELEMENT HandyKatalog (Hersteller*)>
* <!ELEMENT Hersteller (HerstellerNr, Modell+)>
Hersteller <!ATTLIST Hersteller name CDATA #REQUIRED>
name <!ELEMENT HerstellerNr EMPTY>
<!ATTLIST HerstellerNr nr ID #REQUIRED> Grammatik
<!ELEMENT Modell (Gewicht, Preis+)> (logische Struktur)
1 1..*
<!ATTLIST Modell name CDATA #REQUIRED>
HerstellerNr Modell <!ELEMENT Gewicht (#PCDATA)>
nr name <!ELEMENT Preis (#PCDATA)>
<!ATTLIST Preis vertrag (ja|nein) "nein">
1 1..* ]>
<HandyKatalog>
Gewicht Preis
<!–- NOKIA -->
vertrag <Hersteller name="NOKIA">
<HerstellerNr nr="h1234"/>
<Modell name="7110"> Instanz
<Gewicht>141g</Gewicht> (physische Struktur)
<Preis vertrag="ja">999</Preis>
</Modell>
</Hersteller>
</HandyKatalog>

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 47/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Inhalt

n Einführung
n Konzeptionelle Datenmodelle
n Realisierungs-Datenmodelle
n Logischer Entwurf
l Zwei Kernaufgaben
l Abbildung ER-RM
l Verbesserung des relationalen Schemas
¡ Redundanzen und Anomalien
¡ Funktionale Abhängigkeiten
¡ Normalformen
¡ Schema-Eigenschaften
¡ Transformationseigenschaften
n SQL

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 48/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Logischer Entwurf
Zwei Kernaufgaben

(1) Abbildung auf Relationenmodell (RM)


l Vorgehensweisen
¡ Transformation nach Faustregeln manuell
¡ automatische Transformation
l Ziel: „kapazitätserhaltende“ Abbildung

(2) Verbesserung des relationalen Schemas


l anhand von Gütekriterien
¡ Minimierung redundanter Speicherung
(ð Normalisierung)
¡ Effizienzsteigerung beim Zugriff
(ð Zugriffspfade, Denormalisierung, ...)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 49/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Abbildung auf RM
Konzeptionelles DM Realisierungs-DM
Verlag
Name Verlag Name Ort Plz
Ort
Plz
1..1
gibtHeraus
1..* Buch ISBN Titel Name
Buch
ISBN
Titel ISBN ID
0..* schreibt
schreibt
1..* ID Vorname Nachname
Autor
Autor
ID
Vorname
Nachname

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 50/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Abbildung auf RM
Regeln am Beispiel 2/3

n Ternäre Beziehug wird eine Relation


n Die Primärschlüsseln der beteiligten Klassen werden in die
Relation aufgenommen

Lieferant
*

* *
Teil Lieferung Projekt

Verwendung von vier Relationen erforderlich:

Teil (TeilNr, Bezeichnung, ..., Gewicht)


Projekt (ProjektNr, Projektname, ...)
Lieferant (LieferantNr, Lieferantname, ...)
Lieferung (LieferantNr, ProjektNr, TeilNr, Datum, ...)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 51/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Abbildung auf RM
Zusammenfassung

n Klassen
l jeweils auf Relationenschemata abbilden
n Attribute
l Attribute des Relationenschemas, Schlüssel werden übernommen
n Kardinalitäten der Beziehungen
l durch Wahl der Schlüssel bei den zugehörigen Relationenschemata
ausdrücken
n Beziehungen
l *:*-Beziehung ist durch eine eigene Relation darzustellen
n Generalisierung/Spezialisierung
l keine direkte Unterstützung im Relationenmodell
l Auswahl einer geeigneten Abbildung hängt von konkreter
Problemstellung ab
l Abwägung von Speichereffizienz und Laufzeiteffizienz
l Relevant bei Abbildung OO ó Relational

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 52/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Abbildung auf RM
Regeln am Beispiel 3/3

n Vererbungshierarchie
l Jede Klasse wird durch eine Relation abgebildet
l Jede Instanz ist genau einmal und vollständig in ihrer "Basis-
relation" gespeichert
Ø Es wird eine horizontale Partitionierung der Instanzen erreicht

FH-Angehöriger SVNR Name

111 Ernie
SVNR
FH-Angehöriger
Name
Angestellter SVNR Name Vertr.Kat.
IST-EIN
007 Garfield 2L
Angestellter Student
Vertragskategorie
.... Techniker SVNR Name Vertr.kat Erfahrung
IST-EIN
123 Donald 1A Linux
Techniker Wiss-Mitarbeiter
Erfahrung
Diplom Wiss-Mitarbeiter SVNR Name Vertr.kat Diplom Spez.Geb.
Spez-Geb.
777 Grouch 1L BIN C++

333 Daisy 1L SE UML

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 53/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Ziele
n Redundanzen vermeiden
l Belegen unnötigen Speicherplatz (eher unwichtig)
l Änderungsop. bei Redundanzen schwer korrekt umsetzbar
¡ wenn Information redundant vorkommt, muss eine Änderung diese Information
in allen ihren Vorkommen verändern
¡ mit normalen relationalen Änderungsoperationen und lokalen
Integritätsbedingungen (Schlüssel) schwer realisierbar
n Anomalien (sich wiedersprechende Daten) vermeiden
l Änderungsanomalien: Beim Ändern eines Wertes müssen viele Tupel
ebenfalls geändert werden
l Einfügeanomalien: Beim Einfügen eines Tuples können bestimmte
Werte nicht angegeben werden, da sie noch nicht bekannt sind (wenn
Schlüsselwerte fehlen, kann Tupel nicht einmal eingefügt werden)
l Löschanomalien: Beim Löschen eines Tuples geht mehr Information
verloren als beabsichtigt
n OHNE
l semantische Informationen zu verlieren (Abhängigkeitstreue)
l die Möglichkeit zur Rekonstruktion der Relationen zu verlieren
(Verbundtreue)
à Wartung einer DB vereinfachen
Normalformen à Konsistenz gewährleisten
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 54/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Beispiel für eine Anomalie

n Einfügen in die mit Redundanzen behaftete Produkt-


Hersteller-Relation:
ProduktNr Bezeichnung Preis Bestand HerstellerNr Name
207 A 44 6 100 HerstellerA
210 B 55 88 101 HerstellerB

Einfügen

230 C 77 90 100 HerstellerC

n Dem Hersteller mit der Nummer 100 ist eigentlich der


Herstellername „HerstellerA“ zugeordnet und nicht der
Name „HerstellerC“
n Integritätsbedingung verletzt, die in dieser Relation durch
eine Schlüsselbedingung nicht spezifiziert werden kann

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 55/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Funktionale Abhängigkeiten 1/2

n Funktionale Abhängigkeit zwischen Attributmengen X


und Y einer Relation gilt,
l wenn in jedem Tupel der Attributwert unter den X-Komponenten
den Attributwert unter den Y-Komponenten festlegt
l unterscheiden sich zwei Tupel in den X-Attributen nicht, so
haben sie auch gleiche Werte für alle Y-Attribute
n Beispiel:
l ProduktNr à Bezeichnung, HerstellerNr

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 56/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Funktionale Abhängigkeiten 2/2

n Es ist unrealistisch, alle möglichen Tupel einer Relation in


der Praxis zu überprüfen
n Funktionale Abhängigkeiten müssen aus dem
Hintergrundwissen über die Anwendung abgeleitet
werden
n Beispiel:
l ProduktNr à Bezeichnung, HerstellerNr
l HerstellerNr à Name

n Was machen wir jetzt mit diesen funkt. Abhängigkeiten?


n Man kann einen Schlüssel für die Relation identifizieren!

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 57/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Eigenschaften von Schlüsseln

n Eigenschaften eines Schlüssels X:


1. X ⊆ R
2. X à R (Vollständigkeit)
3. Es gibt kein X' ⊆ X so dass X'à R (Minimalität)

n X wird auch Kandidatenschlüssel genannt


l es kann mehr als ein X geben, das obige Eigenschaften erfüllt

n Ein X wird als Primärschlüssel gewählt

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 58/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Erste Normalform

n Erlaubt nur atomare Attribute in den Relationenschemata


l d.h. als Attributwerte sind Elemente von Standard-Datentypen
wie integer oder string erlaubt, aber keine Konstruktoren wie
array oder set
n Nicht in 1NF

Bestellung BestellNr Datum KNr VersandNr ProduktNr


207 2.4.95 44 6 100
210 3.4.05 55 88 {101, 102}
n in 1NF

Bestellung BestellNr Datum KNr VersandNr ProduktNr


207 2.4.95 44 6 100
210 3.4.05 55 88 101
210 3.4.05 55 88 102

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 59/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Zweite Normalform 1/2

n Partielle Abhängigkeit liegt vor, wenn ein Attribut


funktional schon von einem Teil des Schlüssels abhängt
BestellNr à Datum
und
BestellNr, ProduktNr à Datum, KNr, VersandNr

n Verstoß gegen 2NF deutet darauf hin, dass verschiedene


Beziehungen (zwischen Entitätstypen) in einer Relation
gemischt wurden

n Zweite Normalform eliminiert derartige partielle


Abhängigkeiten bei Nichtschlüssel-Attributen (NSA)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 60/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Zweite Normalform 2/2

Eliminierung partieller Abhängigkeiten

Schlüssel K

Teil des abhängiges


Schlüssels X Attribut A

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 61/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Dritte Normalform 1/2

n Eliminiert (zusätzlich) transitive Abhängigkeiten


l bei denen NSA über andere NSA vom Schlüssel abhängen

n Etwa ProduktNr à HerstellerNr und HerstellerNr à Name

n Man beachte: 3NF betrachtet nur NSA (!) als Endpunkt


transitiver Abhängigkeiten

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 62/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Dritte Normalform 2/2

Eliminierung transitiver Abhängigkeiten

Schlüssel K

Attribut- abhängiges
menge X Attribut A
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 63/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Boyce-Codd Normalform

n Verschärfung der 3NF: Eliminierung transitiver Abhängigkeiten auch


zwischen primen Attributen
n Beispiel:
Produkt(ProduktNr, Hersteller, Lieferant, Preis)
n Funktionale Abhängigkeiten:
ProduktNr, Hersteller à Preis
Hersteller à Lieferant
Lieferant à Hersteller
n Schlüsselkandidaten: ProduktNr,Hersteller u.
ProduktNr,Lieferant
n à in 3NF, nicht jedoch in BCNF
n Schema in BCNF:
Produkt (ProduktNr, Hersteller, Preis)
HerstLief (Hersteller, Lieferant)
n BCNF kann jedoch die Abhängigkeitstreue verletzen, daher oft
nur bis 3NF

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 64/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Schema-Eigenschaften – Zusammenfassung

Schema- Kurzcharakteristik
Eigenschaft
1NF nur atomare Attribute
2NF keine partielle Abhängigkeit eines NSA
von einem Schlüssel
3NF keine transitive Abhängigkeit eines NSA
von einem Schlüssel

BCNF keine transitive Abhängigkeit eines


Attributes von einem Schlüssel
Minimalität minimale Anzahl von Relationenschemata,
die die anderen Eigenschaften erfüllt

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 65/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Transformations-Eigenschaften – Zusammenfassung

n Bei der Zerlegung einer Relation in mehrere Relationen ist


darauf zu achten, dass
l nur semantisch sinnvolle und konsistente Daten dargestellt
(Abhängigkeitstreue) und
l alle Daten aus den Basisrelationen hergeleitet werden können
(Verbundtreue)

Transformations- Kurzcharakteristik
Eigenschaft
Abhängigkeitstreue alle gegebenen funktionalen Abhängigkeiten sind durch
Primär- und Fremdschlüssel repräsentiert
Verbundtreue die Originalrelationen können durch den Verbund der
Basisrelationen wieder gewonnen werden

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 66/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Verbesserung des Relationalen Schemas


Einschätzung der Normalisierung

n Normalisierung kann sich negativ auf die Performanz


auswirken, weil Verbunde sehr teuer auszuwerten sind

n Nicht jede funktionale Abhängigkeit berücksichtigen


l Abhängigkeiten zw. Wohnort, Vorwahl, Postleitzahl

n Man kann SQL-Integritätsbedingungen formulieren, um


Anomalien zu vermeiden – z.B. Trigger

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 67/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Inhalt
n Einführung
n Konzeptionelle Datenmodelle
n Realisierungs-Datenmodelle
n Logischer Entwurf
n SQL
l SQL-Standardisierung
l Ausgewählte DDL-Konzepte
¡ CHECK-Bedingung
¡ DOMAIN-Definition
¡ Referentielle Integrität
l Ausgewählte Anfrage-Konzepte
¡ Outer-Join
¡ Gruppierung durch Rollup- und Cube-Operator
¡ Rekursive Anfragen
l Ausgewählte DML-Konzepte
¡ Merge-Anweisung
¡ Generierung eindeutiger Schlüssel
¡ Materialisierte Sicht
l Prozedurale Erweiterungen
¡ Stored Procedures
¡ Trigger

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 68/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
Structured Query Language (SQL)

n SQL ist "de facto"-Standard in der relationalen Welt


l 1986 von ANSI, 1987 von ISO akzeptiert

Lebenszyklus ISO-Standardisierung
n Weiterentwicklung des
Standards in vier Stufen

n Mächtigkeit von SQL


l Auswahlvermögen äquivalent dem Relationen-Kalkül und der
Relationen-Algebra

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 69/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
Historie

DBMS-Produkte
Sprachentwicklung
Chamberlin, D., Boyce, R.F. SEQUEL: A Structured English Query
n SEQUEL (1974, IBM Research Labs San Jose) Language. Proc. ACM SIGFIDET Conf., Ann Arbor, MI, May 1974.
http://www.almaden.ibm.com/cs/people/chamberlin
n SEQUEL2 (1976, IBM Research Labs San Jose)
Codd, E.F.: A Relational Model of Data for Large Shared Data Banks,
n SQL (1982, IBM) Communications of the ACM, Vol. 13, No. 6, June 1970,
n ANSI-SQL (SQL1 oder SQL:86) http://www.acm.org/classics/nov95/toc.html
n ISO-SQL (SQL1 + Integrity Enhancement Feature oder SQL:89)
n (ANSI / ISO) SQL2 (als SQL:92 verabschiedet)
n (ANSI / ISO) SQL3 (als SQL:1999 verabschiedet)
n (ANSI / ISO) SQL:2003 (verabschiedet)
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 70/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
Standards im Historischen Überblick
https://modern-sql.com/de/standard
n SQL:1986 – SQL1
l erste Version der SQL-Norm 1986 veröffentlicht
l DDL, DML, eingebaute Typen, Privilegien für den Zugriff auf Tabellen, ...
n SQL:1989
l Erste Revision von SQL:1986
l Erweiterung um referentielle Integrität
n SQL:1992 – SQL2
l Zusätzliche Datentypen, OuterJoins, Kataloge, Domänen,
Zuweisungen, temporäre Tabellen, referentielle Aktionen, dynamisches SQL, ...
l laufende Revisionen: prozedurale Konstrukte wie Stored Procedures, Schema
Manipulation
n SQL:1999 – SQL3
l Standard wird in fünf Teile gegliedert
l zusätzliche Typen (wie CLOB, BLOB), objekt-relationale Erweiterungen, rekursive
Abfragen, Sicherungspunkte (Savepoints), Rollen, Trigger, ...
n SQL:2003
l neuer Teil: SQL/XML (Verknüpfung von XML und SQL)
l SQL/OLB und SQL/JRT: Verbindung zwischen SQL und Java
l generierte Spalten (berechnen sich aus anderen Spalten)
l MULTISET-Typen (speichern eine beliebige Anzahl von Werten mit Duplikaten)
l Merging (fügt zwei Tabellen zusammen)
l Identitätsspalten (stellen automatisch inkrementierte Werte bereit), ...

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 71/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
Neue Anforderungen an SQL:1999-2007

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 72/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
SQL:2007 – Umfang

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 73/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
Konformität von SQL:2007: Core-SQL vs. SQL/XML

Prof. Dr. Wloka, Entwicklung des SQL-Standards – Vom Hoffnungsträger zum Ideengrab,
Hochschule für Technik und Wirtschaft, Dresden, Vortragsunterlagen, März 2007
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 74/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
SQL:2007

n Struktur und wesentliche „alte Inhalte bleiben gleich


l Geringe Änderungen bei SQL/Schema
l Änderungen bei SQL/Foundation
n Umfangreiche Entwicklungen bei SQL/XML
n Zusätzliche Neue Features (außerhalb von SQL/XML)
l Materialized views
l Ermöglichung von Bulkinserts
l Unterstützung der history (stripped-down temporal)
l Unterstützung von streaming data
l Reguläre Ausdrücke
l BINARY datatype
l FIRST n (LIMIT TO n, TOP n, …)
l IEEE 754 floatingdecimal datatype

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 75/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
SQL:2011

n Temporale DB-Konzepte = hauptsächliche Neuerung


l Viele Daten weisen 2 Zeitdimensionen auf die unterschiedlich
sein können
¡ „Valid (application) time (z.B. Gehaltserhöhungen)
¡ „Transaction (system) time (z.B. Fehlerkorrektur)
l 4 verschiedene Tabellen-Typen u. SQL-DML Erweiterungen
Application-Time Period Table System-Versioned Table

n Weitere neue Features


l Innerhalb eines MERGE nun auch Delete möglich
l Innerhalb SELECT nun auch DML-Ops erlaubt ("Pipelined DML")
l Non-enforced table constraints
l Einige neue DDL-features bei Identitätsspalten
l Erweiterungen von collection types
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 76/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

SQL-Standardisierung
SQL:2016 – aktuelle Version!

n Delta v.a. in Part 2 des Standards (“SQL Foundation”)


l SQL:2007: 1323 Seiten
l SQL:2011: 1472 Seiten
l SQL:2016: 1732 Seiten (+ 260 Seiten / ~18%)
à 44 neue optionale Funktionen, keine obligatorischen
n Zeilenmustererkennung (“Row Pattern Recognition”)
l durch reguläre Ausdrücke Analyse von Zeitreihen
l z.B. zusammenhängende Ereignisse / Löcher in WebLog erkennen
n JSON-Unterstützung
l JSON-Objekte erzeugen/über Pfadausdrücke auf Element zugreifen
l Umwandlung JSONàSQL und SQLàJSON
n Polymorphe Tabellen-Funktionen
l Liefern eine Tabelle als Ergebnis, deren Ergebnistyp
(Spalten-Namen und -Typen) zur Laufzeit festgelegt werden kann
n Weitere analytische Funktionen
l Trigonometrische | Logarithmische
http://modern-sql.com/de/blog/2017-06/was-ist-neu-in-sql-2016
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 77/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
DDL‘s im Überblick

n SQL
l DDL (Data Definition Language)
à Teil der Standardsprache für RDBS
l DDL-Erweiterungen von SQL:1999
à objektrelationale Konzepte
l DDL-Erweiterungen von SQL:2003
à XML-Konzepte

n XML
l DTD (Document Type Declaration)
l XML Schema

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 78/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
CHECK-Bedingung

n Logische Bedingung zugeordnet zu Attributen von Tabellen


n Wird bei DML-Operationen geprüft
l TRUE: DML-Operation erlaubt
l FALSE: DML-Operation zurückgewiesen

CREATE TABLE base-table (base-table-element-list)


base-table-element
::= column-def | base-table-constraint-def
CREATE TABLE Buch_Versionen (
ISBN CHAR(10) PRIMARY KEY
ISBN CHAR(10) NOT NULL UNIQUE,
Auflage SMALLINT CONSTRAINT Check_Auflage
CHECK(Auflage > 0),
Jahr INTEGER CONSTRAINT Check_Jahr
CHECK (Jahr BETWEEN 1800 AND 2020),
Seiten INTEGER DEFAULT 0);

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 79/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
DOMAIN-Definition

n Domänen stellen benutzerdefinierte Wertebereiche dar


n Basieren auf existierenden Datentypen
n Können wie ein herkömmlicher Datentyp für die
Attributdefinition verwendet werden
n Spezifikationsmöglichkeiten
l Optionale Angabe von Default-Werten
l Wertebereichseingrenzung durch CHECK-Bedingung möglich

CREATE DOMAIN domain [AS] data type


[DEFAULT {literal|NULL}
[[CONSTRAINT constraint] CHECK (cond-exp)]

CREATE DOMAIN ALTER AS INT


DEFAULT NULL
CONSTRAINT Altersbegrenzung
CHECK (VALUE=NULL OR (VALUE>18 AND VALUE<70))

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 80/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Referentielle Integrität 1/4

n RM unterstützt nur wertbasierte Beziehungen


l oo Datenmodelle haben referenzbasierte Beziehungen!
n Fremdschlüssel (FK) und zugehöriger Primärschlüssel (PK)
repräsentieren eine Beziehung
l gleiche Wertebereiche!
n Spezifikationsmöglichkeiten in SQL:
l PK PRIMARY KEY (implizit: UNIQUE + NOT NULL)
l FK [UNIQUE] [NOT NULL]
n Fremdschlüsseldeklaration in KindKTabelle:

Vatertabelle Kind-Tabelle
0..1 0..* FK ...
1..1 0..* FK ... NOT NULL
0..1 0..1 FK ... UNIQUE
1..1 0..1 FK ... UNIQUE NOT NULL
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 81/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Referentielle Integrität 2/4

n Referentielle Integritätsbedingung zwischen Primär- und


Fremdschlüssel

Vater-Tabelle: Kind-Tabelle:
CREATE TABLE Verlage ( CREATE TABLE Bücher (
Verlagsname VARCHAR(30), ISBN CHAR(10),
... Titel VARCHAR(200),
CONSTRAINT PK_Verlagsname Verlagsname VARCHAR(30),
PRIMARY KEY CONSTRAINT PK_ISBN
(Verlagsname), PRIMARY KEY (ISBN),
... CONSTRAINT FK_Verlagsname
); FOREIGN KEY (Verlagsname)
REFERENCES Verlage (Verlagsname)
);

n Zu jedem Fremdschlüsselwert der referenzierenden


Kindtabelle (Bücher) muss ein entsprechender Schlüssel-
wert in der referenzierten Vatertabelle (Verlage)
exisiteren
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 82/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Referentielle Integrität 3/4

Potentielle Gefährdung der Kind-Tabelle:

n Operationen in der Kind-Tabelle


l Einfügen eines Tupels
l Ändern des FK in einem Tupel
l Löschen eines Tupels

n Welche Maßnahmen sind erforderlich?


l Beim Einfügen erfolgt eine Prüfung, ob in einem Vater-Tupel ein
PK-Wert gleich dem FK-Wert des einzufügenden Tupels existiert
l Beim Ändern eines FK-Wertes erfolgt eine analoge Prüfung
l Löschen eines Tuples ist immer unkritisch!

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 83/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Referentielle Integrität 4/4

Potentielle Gefährdung der Vater-Tabelle:


n Operationen in der Vater-Tabelle
l Einfügen eines Tupels
l Ändern des PKs in einem Tupel
l Löschen eines Tupels

n Welche Aktion ist wann möglich/sinnvoll?


l Einfügen eines Tuples ist immer unkritisch!
l Verbiete Ändern/Löschen falls abhängige Tupel oder
l Ändere/Lösche rekursiv Tupel mit zugehörigen FS-Werten
¡ Falls Kind-Tupel erhalten bleiben soll (nicht immer möglich, z.B. bei
Existenzabhängigkeit), setze FK-Wert zu NULL oder Default

l Referentielle Aktionen nur für das Löschen und Ändern von


Vater-Tupeln von Interesse!

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 84/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Referentielle Aktionen bei ON DELETE / ON UPDATE 1/2

CREATE TABLE Bücher (


n SQL2-Standard führt ISBN CHAR(10),
„referential actions“ ein! Titel VARCHAR(200),
l werden bei DELETE oder Verlagsname VARCHAR(30),
UPDATE der Vatertabelle auf CONSTRAINT PK_ISBN
die Kindtabelle ausgeführt, PRIMARY KEY (ISBN),
um referentielle Integrität CONSTRAINT FK_Verlagsname
zu gewährleisten FOREIGN KEY (Verlagsname)
REFERENCES Verlage
Referentielle Aktion wird auf Bücher-
(Verlagsname)
Tabelle (=Kindtabelle) ausgeführt ON DELETE CASCADE
);

n Spezifiziert bei FS Oracle nur: ON DELETE{CASCADE|SET NULL}


l ON DELETE
{CASCADE|RESTRICT|SET NULL|SET DEFAULT|NO ACTION}
l ON UPDATE
{CASCADE|RESTRICT|SET NULL|SET DEFAULT|NO ACTION}

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 85/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Referentielle Aktionen bei ON DELETE / ON UPDATE 2/2

n RESTRICT
l Operation nur ausgeführt, wenn keine zugehörigen (FK-Werte)
l entspricht dem Fall, dass die gesamte Klausel weggelassen wird
n CASCADE
l Operation propagiert zu allen zugehörigen Sätzen
n SET NULL
l FK wird in zugehörigen Sätzen auf NULL gesetzt
n SET DEFAULT
l FK wird in den zugehörigen Sätzen auf einen
benutzerdefinierten Default-Wert gesetzt
n NO ACTION
l Für Referenz keine referentielle Aktion
l Durch DB-Op können jedoch mehrere Referenzen (mit
unterschiedlichen Optionen) betroffen sei
l Am Ende aller referentiellen Aktionen wird die Einhaltung der
referentiellen Integrität geprüft
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 86/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Abarbeitung von Referentiellen Aktionen 1/2

CREATE TABLE T1 (... PRIMARY KEY K1)


T1
ON DELETE ON DELETE
CREATE TABLE T2 (... PRIMARY KEY K2 CASCADE CASCADE
FOREIGN KEY (K1) REFERENCES T1(K1)
ON DELETE CASCADE) T2 T3
CREATE TABLE T3 (... PRIMARY KEY K3 ON DELETE ON DELETE
FOREIGN KEY (K1) REFERENCES T1(K1) CASCADE RESTRICT
ON DELETE CASCADE) T4

CREATE TABLE T4 (... PRIMARY KEY K4


FOREIGN KEY (K3) REFERENCES T3(K3)
DELETE in T1:
ON DELETE RESTRICT)
FOREIGN KEY (K2) REFERENCES T2(K2) Aktionen von T3 vor T4 vor T2 7
ON DELETE CASCADE) Aktionen von T2 vor T4 vor T3 ü

ð Es können reihenfolgeabhängige Ergebnisse auftreten!

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 87/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DDL-Konzepte
Abarbeitung von Referentiellen Aktionen 2/2

CREATE TABLE T1 (... PRIMARY KEY K1)


T1
ON DELETE ON DELETE
CREATE TABLE T2 (... PRIMARY KEY K2 CASCADE CASCADE
FOREIGN KEY (K1) REFERENCES T1(K1)
ON DELETE CASCADE) T2 T3
CREATE TABLE T3 (... PRIMARY KEY K3 ON DELETE ON DELETE
FOREIGN KEY (K1) REFERENCES T1(K1) CASCADE NO ACTION
ON DELETE CASCADE) T4

CREATE TABLE T4 (... PRIMARY KEY K4


FOREIGN KEY (K3) REFERENCES T3(K3)
ON DELETE RESTRICT) NO ACTION
FOREIGN KEY (K2) REFERENCES T2(K2)
ON DELETE CASCADE)

à Bei NO ACTION wird Test der referenzierenden Relation ans Ende der Op verschoben
à Verletzung der referentiellen Beziehung à ROLLBACK
ð Schema ist immer sicher

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 88/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte Anfrage-Konzepte
SFW-Block

5n SELECT
l Projektionsliste (= Ergebnisschema)
l arithmetische Operationen und Aggregatfunktionen
Auswertungsreihenfolge

1n FROM
l zu verarbeitende Relationen, evtl. Umbenennungen

2n WHERE
l Selektions-, Verbundbedingungen
l Geschachtelte Anfragen (wieder ein SFW-Block)

3n GROUP BY
l Gruppierung für Aggregatfunktionen

4n HAVING
l Selektionsbedingungen an Gruppen
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 89/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte Anfrage-Konzepte
Äußerer Verbund 1/2

n Zusätzlich zu klassischem Verbund (INNER JOIN)


l seit SQL2 auch äußerer Verbund
l _ Übernahme von Tupel in das Ergebnis, die keine Join-
Partner in der jeweiligen anderen Relation haben und
l _ Auffüllen mit Nullwerten

n OUTER JOIN
l übernimmt alle Tupel beider Operanden
l Langfassung: (NATURAL) FULL OUTER JOIN
n LEFT OUTER JOIN
l übernimmt alle Tupel des linken Operanden
n RIGHT OUTER JOIN
l übernimmt alle Tupel des rechten Operanden

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 90/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte Anfrage-Konzepte
Äußerer Verbund 2/2

LINKS A B RECHTS B C
NATURAL JOIN A B C
1 2 3 4
2 3 4
2 3 4 5

SELECT * FROM LINKS NATURAL JOIN RECHTS;

RIGHT OUTER JOIN FULL OUTER JOIN


A B C A B C SELECT *
2 3 4 1 2 NULL FROM LINKS NATURAL FULL OUTER JOIN
2 3 4
RECHTS;
NULL 4 5
NULL 4 5

LEFT OUTER JOIN


A B C SELECT L.A, L.B, R.C
1 2 NULL FROM LINKS L LEFT OUTER JOIN RECHTS R
2 3 4
ON L.B=R.B;

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 91/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte Anfrage-Konzepte
ROLLUP-Operator

n ROLLUP ist eine Erweiterung der GROUP BY-Klausel


n Mit dem ROLLUP-Operator können kumulative Aggregate,
z.B. Zwischensummen, erstellt werden
SELECT A, B, SUM(D)
FROM REL
WHERE D <= 7
A B SUM(D)
GROUP BY ROLLUP (A, B);
1 2 9
A B C D 1 3 5
1 2 3 4 1 14
1 2 4 5 2 3 4
1 3 4 5 Superaggregate
ROLLUP 2 4
für A (= 1,2,3)
2 3 3 4 3 3 5
3 3 4 5 3 4 7
3 4 6 7 3 12
Gesamtsumme
4 3 6 8 30

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 92/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte Anfrage-Konzepte
CUBE-Operator

n CUBE ist ebenso eine Erweiterung der GROUP BY-Klausel


n Mit dem CUBE-Operator können mit einer einzelnen SELECT-
Anweisung Kreuztabellenwerte erstellt werden
SELECT A, B, SUM(D) A B SUM(D)
FROM REL 30 Gesamtsumme
WHERE D <= 7
2 9
GROUP BY CUBE (A, B); nach B zusammen-
3 14 gefasst
A B C D 4 7
1 2 3 4 1 14 nach A zusammen-
1 2 4 5 gefasst
1 2 9
1 3 4 5 nach A und B
CUBE 1 3 5
zusammengefasst
2 3 3 4 2 4
3 3 4 5 2 3 4
3 4 6 7 3 12
4 3 6 8 3 3 5
3 4 7
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 93/113
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL
Flug:
Ausgewählte Anfrage-Konzepte Flugnr Abflug Ziel Preis

Rekursive Anfrage 1/3


LH131 Frankfurt Sydney 1009
BA170 Zürich London 599
AF691 Paris New York 1299
UA103 Sydney New York 1549
SR163 Zürich Frankfurt 499
n Ermittle alle von Zürich aus direkt erreichbaren TK911 Paris Istanbul 799
Ziele! BA297 London Frankfurt 299

Zürich
SELECT Abflug, Ziel Abflug Ziel
London Frankfurt
FROM Flug Zürich London

WHERE Abflug = 'Zürich'; Zürich Frankfurt Frankfurt Sydney

Sydney New York


n Ermittle alle von Zürich aus indirekt erreichbaren Ziele!
New York
SELECT Abflug, Ziel
Abflug Ziel
FROM Flug
London Frankfurt
WHERE Abflug IN ( SELECT Ziel
Frankfurt Sydney
FROM Flug
WHERE Abflug = 'Zürich');
Abflug Ziel

n Ermittlung aller von Zürich aus erreichbaren Ziele Zürich London

kann mit den vorgestellten Mitteln jedoch in SQL Zürich Frankfurt

nicht formuliert werden. Zürich Sydney


Zürich New York

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 94/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte Anfrage-Konzepte
Rekursive Anfrage – SQL-Standard 2/3

WITH RECURSIVE Erreichbar(Abflug, Ziel) AS


(
SELECT Abflug, Ziel
FROM Flug 1 Abflug Ziel
WHERE Abflug = 'Zürich' Zürich London
UNION ALL Zürich Frankfurt
SELECT e.Abflug, f.Ziel Zürich Sydney
2 FROM Erreichbar e, Flug f
Zürich New York
WHERE e.Ziel = f.Abflug
)
SELECT DISTINCT *
FROM Erreichbar;

Rekursionsinitialisierung berechnet alle direkten


Verbindungen in der Rekursionsrelation Erreichbar

Rekursionsschritt berechnet alle indirekten Verbindungen


basierend auf den bereits berechneten Zielorten

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 95/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte Anfrage-Konzepte
Rekursive Anfrage – Oracle 3/3

n Implementierungen in konkreten Systemen (Oracle, DB2)


schon vor der Standardisierung vorhanden!
n Beispiel in Oracle:

SELECT Abflug, Ziel


FROM Flug
CONNECT BY PRIOR Ziel = Abflug
START WITH Abflug = 'Zürich';

Rekursionsbedingung: gibt die Spalten an, in denen die


PRIOR-Beziehung zwischen Vater- und Kindknoten besteht

Rekursionsinitialisierung: gibt die Anfangsknoten der Hierarchie an


bei denen begonnen werden soll

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 96/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
MERGE-Anweisung 1/2

n NEU in SQL:2003
n Kombination von mehreren UPDATE- und INSERT-
Anweisungen, die ausgewählte Spaltenwerte bzw. Tupel
aus einer Tabelle in eine andere Tabelle übernimmt

n Bedingungsabhängiges Aktualisieren oder Einfügen:


l UPDATE-Anweisung, wenn Zeile vorhanden ist
l INSERT-Anweisung, wenn neue Zeile NICHT vorhanden ist

n Vorteile:
l Vermeidet separate Aktualisierungen
l Steigert Performanz und Benutzerfreundlichkeit
l Nützlich z.B. für Data Warehousing-Anwendungen

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 97/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
MERGE-Anweisung 2/2
Zieltabelle, deren Daten aktualisiert oder ergänzt werden

MERGE INTO ziel_relation [AS ziel_relation_alias]


USING referenz_relation
Quelle kann Tabelle, Sicht oder Unteranfrage sein
ON verbund_bedingung
WHEN [MATCHED THEN UPDATE SET spalten_zuweisung]
[NOT MATCHED THEN INSERT[(attribute1..n)] VALUES (werte1..n)]

Aktualisiere bestehende Zeile Füge neue Zeile ein

n Je nachdem, ob die Verbundbedingung erfüllt ist oder nicht,


wird die jeweilige Klausel ausgeführt
MERGE INTO Lieferant l
USING Hersteller h
ON (l.LiefId = h.HerstId)
WHEN MATCHED THEN UPDATE SET
l.Name = h.Name
NOT MATCHED THEN INSERT
(LiefId, Name) VALUES (h.HerstId, h.Name);

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 98/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Generierung Eindeutiger Schlüssel – Sequenzgenerator

n Seit SQL:2003, automatische Generierung von eindeutigen


numerischen Werten
l z.B. zur Vergabe von künstlichen Schlüsselwerten
l Parametrisierung: Startwert, Inkrement, Überlaufbehandlung

CREATE SEQUENCE PersonIDGen AS INT


START WITH 5000 INCREMENT BY 1
MINVALUE 1000 MAXVALUE 99999
CYCLE;

n CYCLE-Klausel bestimmt über den nächsten Schritt, wenn beim


Inkrementieren der Maximalwert (bzw. beim Dekrementieren der
Minimalwert) erreicht wird
l NO CYCLE beendet Generierung mit einer Ausnahmebedingung
l CYCLE setzt die Generierung mit dem Minimalwert fort

n Anwendung:
INSERT INTO MitarbeiterTupeltabelle (MNr, Name)
VALUES (NEXT VALUE FOR PersonIDGen, 'Harry');

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 99/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Generierung Eindeutiger Schlüssel – Identitätsspalten

n Seit SQL:2003, automatische Generierung von Schlüsseln mit


Hilfe eines impliziten Sequenzgenerators
n Eine Tabelle darf maximal eine Identitätsspalte enthalten
CREATE TABLE Produkt (
ProdId INTEGER GENERATED ALWAYS AS IDENTITY
( START WITH 5000 INCREMENT BY 1
MINVALUE 1000 MAXVALUE 99999
NO CYCLE),
Bezeichnung VARCHAR(20), Preis DECIMAL(9,2), ...
);
INSERT INTO Produkt (Bezeichnung, Preis, ...)
VALUES ( 'Messer', 20,...);

n Wert der generierten Spalte wird automatisch berechnet


l z.B. DB2, SQLServer realisieren Identitätsspalte

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 100/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Sichten (Views) im Allgemeinen

n Eigenschaften
l "dynamisches Fenster" auf Basistabellen
l Sichten auf Sichten möglich
l prinzipiell wie eine Tabelle behandelbar … ABER:

n Unterschied Sicht – Tabelle


l keine Integritätsbedingungen
l keine Indizes
l keine Trigger
l änderbare und nicht-änderbare Sichten

n Einsatz
l logische Datenunabhängigkeit
l vorformulierte Anfragen
l Sichten als "Zwischentabellen"
l Datenschutz

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 101/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Materialisierte Sichten – Vorteile & Einsatz

n = Gespeicherte Tabelle
l Daten aus einer/mehreren Basistabellen oder anderen Sichten
l wie Basistabelle verwendbar
¡ SELECT ... FROM MaterializedView WHERE ...

n Vorteile
l Überwiegend lesender Zugriff auf stabiler Datenbasis
¡ geringer Aufwand bei Sicht-Aktualisierung
l Verbesserung der Performanz (Reduktion der Antwortzeit)
¡ DBS kann automatisch Anfrageteile erkennen, deren (Teil-)
Ergebnisse durch materialisierte Sichten zur Verfügung stehen

n Einsatz
l Data-Warehouses
l Replikation in verteilten DBS

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 102/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Materialisierte Sichten – Auswahl und Wartung

n Auswahl materialisierter Sichten


l Speicherbedarf für redundant gehaltene Daten
l zusätzlicher Verwaltungsaufwand durch Materialisierung
(Materialisierungskonfiguration)
l erwartete Reduktion von Antwortzeiten

n Wartung materialisierter Sichten


l Änderungen in Basistabellen erfordern
¡ Neuberechnung der Sicht (ð Rematerialisierung) oder
¡ Propagierung der Änderungsoperationen zu den Sichten
(ð inkrementelle Aktualisierung)
l Zeitpunkt der Aktualisierung erfolgt
¡ sofort (synchrone)
¡ verzögert Nächste Folie ...
¡ durch Snapshot (asynchron)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 103/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Materialisierte Sichten – Aktualisierungszeitpunkt

n Sofortige (synchrone) Aktualisierung


l Sichten immer aktuell
l dafür werden die Modifikationstransaktionen behindert

n Verzögerte Aktualisierung
l Entkoppelung der Aktualisierung von Modifikationstransaktion;
bei Zugriff auf Sicht wird diese aktualisiert
l Sicht beim Lesen immer aktuell
l Lesende Transaktion trägt die Aktualisierungskosten
l Unter Umständen müssen viele Modifikationen nachgezogen
werden, wenn auf die Sicht lange nicht zugegriffen wurde

n Snapshot-Aktualisierung
l asynchron zur Modifikation und zum Lesezugriff nach
anwendungsspezifischen Gesichtspunkten

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 104/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Materialisierte Sichten in ORACLE

n Automatisiert den Aktualisierungs(Refresh)-Prozess


n CREATE MATERIALIZED VIEW-Recht erforderlich!

Name der materialisierten Sicht

CREATE MATERIALIZED VIEW MGAL


REFRESH FORCE WIE? Aktualisierung erst dann,
Aktualisierungs-
strategie ON COMMIT WANN? wenn Änderungen in Basistabellen
WITH PRIMARY KEY festgeschrieben wurde (= commit)
AS
SELECT Mitarbeiter, Gehalt, MGA.Abteilung, Leiter
FROM MGA, AL
WHERE MGA.Abteilung = AL.Abteilung;
Berechnungsvorschrift, die den Inhalt für
materialisierte Sicht festlegt

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 105/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Ausgewählte DML-Konzepte
Materialisierte Sichten in ORACLE – Aktualisierung

n Wann wird aktualisiert


l ON DEMAND: Nur bei Aufruf von speziellen Funktionen
l ON COMMIT: Beim Abschluss von Transaktionen, die
mindestens eine Basistabelle verändern
l START WITH date NEXT date: Aktualisiert Sicht zunächst
basierend auf START WITH date - mit NEXT date erfolgt
Aktualisierung in Intervallen

n Wie wird aktualisiert


l COMPLETE: Komplette Neuberechnung der Sicht bei
Änderungen an mindestens einer Basistabelle
l FAST: Inkrementelles Nachführen von Änderungen - nur bei
einfachen materialisierten Sichten möglich (= Daten nur aus
einer Basistabelle)
l FORCE: Ausführung von FAST, wenn möglich; sonst COMPLETE

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 106/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Prozedurale Erweiterungen
Stored Procedures 1/2

n Erweiterung von SQL um prozedurale Konstrukte oder mittels


externer Programmiersprachen wie Java
l SQL/PSM (Persistent Stored Modules) – seit 1992 SQL-Standard!
n Erlauben die Ausführung komplexer DB-orientierter Operationen
innerhalb des DB-Servers
l Kontrolle muss nicht nach jeder SQL-Operation an das
Anwendungsprogramm zurückgegeben werden
l Performanz, Wiederverwendbarkeit, Wartungsfreundlichkeit

CREATE FUNCTION DEPT_SIZE (IN deptno INTEGER)


RETURNS VARCHAR[7]
DECLARE TOT_EMPS INTEGER;

SELECT COUNT (*) INTO TOT_EMPS


FROM SELECT EMPLOYEE WHERE DNO = deptno;
IF TOT_EMPS > 100 THEN RETURN “HUGE”
ELSEIF TOT_EMPS > 50 THEN RETURN “LARGE”
ELSEIF TOT_EMPS > 30 THEN RETURN “MEDIUM”
ELSE RETURN “SMALL”
ENDIF;
COOPERATIVE INFORMATION SYSTEMS 107/113
, JKU Linz
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Prozedurale Erweiterungen
Stored Procedures 2/2

Compound statement BEGIN [ATOMIC] SQL-Anweisungen END;


SQL variable declaration DECLARE Variable Datentyp;
IF statement IF Prädikat THEN SQL-Anweisungen
ELSE SQL-Anweisungen END IF;
CASE statement CASE X WHEN Wert THEN SQL-Anweisungen
ELSE SQL-Anweisungen END CASE;
LOOP statement LOOP SQL-Anweisungen END LOOP;
WHILE statement WHILE Prädikat DO SQL-Anweisungen END WHILE;
REPEAT statement REPEAT SQL-Anweisungen UNTIL Prädikat END REPEAT;
FOR statement FOR Loop-Variable AS Cursor-Spezifikation
DO SQL-Anweisungen END FOR;
RETURN statement RETURN Rückgabewert;
CALL statement CALL Routine(Parameterliste);
Assignment statement SET Variable = Wert;
SIGNAL statement SIGNAL Ausnahme;

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 108/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Prozedurale Erweiterungen
Trigger

n Reagiert automatisch auf vordefinierte Ereignisse in der


Datenbank mit entsprechenden Aktionen
l Event/Condition/Action-Rule (ECA-Regel)
l Basieren auf SQL/PSM
l "aktive DB-Konzepte"

n Einsatzgebiete
l Wahrung von Integritätsbedingungen (z.B. onUpdateCascade)
l Zugriffsschutz (z.B. zeitabhängige Zugriffserlaubnis)
l Definition von Geschäftsregeln (z.B. Rabattberechnung)
l Protokollierung (z.B. Tracing von Zugriffen)

n Erst mit SQL:1999 standardisiert


l obwohl kommerzielle Systeme Trigger schon lange unterstützen
l Sybase führte Trigger bereits 1987 ein

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 109/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Prozedurale Erweiterungen
Trigger – Bestandteile

n Triggerereignis
l INSERT/DELETE/UPDATE auf Basistabelle
n Triggeraktivierungszeitpunkt
l BEFORE/AFTER Triggerereignis
n Triggergranularität
l FOR EACH ROW/STATEMENT
n Triggerbedingung CREATE TRIGGER OnUpdateCascadeMNr
l SQL-Bedingung AFTER UPDATE OF MNr ON Mitarbeiter
REFERENCING OLD AS AltMit NEW AS NeuMit
l Aktion nur dann FOR EACH ROW
ausgeführt, wenn WHEN(EXISTS(SELECT * FROM Mitarbeiter
Bedingung erfüllt ist WHERE Manager= AltMit.MNr))
n Triggeraktion BEGIN ATOMIC
UPDATE Mitarbeiter
l Sequenz von SET Vorgesetzter=NeuMit.MNr
SQL-Anweisungen WHERE Vorgesetzter=AltMit.MNr;
END;

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 110/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Prozedurale Erweiterungen
Trigger – Standard vs. Systemunterstützung

SQL- DB2 ORACLE SQL Postgres-


Standard SERVER SQL
BEFORE-TRIGGER

AFTER-TRIGGER

INSERT-TRIGGER

UPDATE-TRIGGER

DELETE-TRIGGER

INSTEAD-OF-TRIGGER --- ---


Multiple-TRIGGER ?
DDL-TRIGGER --- ---
Rekursive-TRIGGER ? ?
ALTER-TRIGGER ---
DROP-TRIGGER

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 111/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Literatur

n Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman: Concurrency control & recovery in DBS, Addison-Wesley (1987)
n Philip A. Bernstein, E. Newcomer: Principles of Transaction Processing, Morgan-Kaufmann, San Francisco, 1997.
n C.J. Date, An Introduction for Database Systems, Pearson Education, 2004
n Ramez Elmasri, Shamkant B. Navathe: Grundlagen von Datenbanksystemen – 7. Auflage, Pearson Studium (2016)
n Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom, Database Systems – The Complete Book, Prentice Hall, 2002
n Jim Gray, Andreas Reuter: Transaction processing: concepts and techniques. San Mateo, Kaufmann, (1994)
n M. Tamer Özsu, Patrick Valduriez: Principles of Distributed Database Systems, Third Edition, Prentice-Hall (2011)
n Erhard Rahm, Theo Härder: Datenbanksysteme - Konzepte und Techniken der Implementierung, Springer-Verlag, (1999)
n Gunter Saake, Andreas Heuer, Kai-Uwe Sattler: Datenbanken-Implementierungstechniken, 3. Auflage, MITP Verlag (2011)
n Gunter Saake, Andreas Heuer: Datenbanken - Konzepte und Sprachen, 6. Auflage, MITP Verlag (2018)
n Gunter Saake, Andreas Heuer: Datenbanken kompakt, MITP Verlag (Neuauflage 2003)
n Dennis Shasha and Phillipe Bonnet: Database Tuning: Principles Experiments and Troubleshooting Techniques, Morgan
Kaufmann Publishers (2002)
n Michael Stonebraker, Dorothy Moore: Object-relational DBMSs: the next great wave, San Francisco, Kaufmann (1996)
n Jeffrey D. Ullman: Principles of database and knowledge-base systems. - Vol. I & II, Computer Science Press (1988)
n Gottfried Vossen: Datenbankmodelle, Datenbanksprachen und Datenbank-Management-Systeme, Oldenbourg (1999)
n Gerhard Weikum, Gottfried Vossen: Transactional Information Systems, Morgan Kaufmann Publishers (2002)

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 112/113


Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL

Anhang

n F. Zemke, What‘s new in SQL:2011,


SIGMOD Record, Vol. 41, No. 1, March 2012

n K. Kulkarni et al., Temporal features in SQL:2011,


SIGMOD Record, Vol. 41, No. 3, September 2012

n J. Michels et al., The New and Improved SQL:2016


Standard,
SIGMOD Record, Vol. 47, No. 2, June 2018

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 113/113