WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 Vorlesung #6 SQL (Teil 3)

Slides:



Advertisements
Ähnliche Präsentationen
Sicherheitsaspekte Sicherheit im DBMS
Advertisements

Datenintegrität Einschränkung der möglichen Datenbankzustände und -übergänge auf die in der Realität möglichen Formulierung von Integritätsbedingungen.
Datenintegrität Integitätsbedingungen Schlüssel
Deduktive Datenbanken
© A. Kemper / A. Eickler1 Kapitel 5: Datenintegrität Integitätsbedingungen Schlüssel Beziehungskardinalitäten Attributdomänen Inklusion bei Generalisierung.
Systemüberblick Beispiele: Microsoft Access Oracle Ingres Informix
Datenintegrität, Views und Zugriffsrechte
Kapitel 5 SQL DDL + DML.
Datenintegrität, Views und Zugriffsrechte
Grundlagen Datenbanken
SQL als Abfragesprache
Datensicherheit in DBMS
IS: Datenbanken, © Till Hänisch 2000 CREATE TABLE Syntax: CREATE TABLE name ( coldef [, coldef] [, tableconstraints] ) coldef := name type [länge], [[NOT]NULL],
Datenintegrität Referentielle Integrität create table
1 Datenintegrität Statische Bedingung (jeder Zustand) Dynamische Bedingung (bei Zustandsänderung) Bisher: Definition eines Schlüssels 1:N - Beziehung Angabe.
1 Kapitel 8: Datenintegrität. 2 Datenintegrität Statische Bedingung (jeder Zustand) Dynamische Bedingung (bei Zustandsänderung) Bisher: Definition eines.
Kapitel 9: Integritätssicherung
3.5.2 Fremdschlüssel/ Referentielle Integrität (6/9)
3.5.2 Fremdschlüssel/ Referentielle Integrität (1/9)
2.2 Definition eines Datenbankschemas (SQL-DDL)
Datenbankentwicklung IV-LK
Relationale Datenbanken III
Datenintegrität Integitätsbedingungen Schlüssel
Efficient Alias Set Analysis Using SSA Form Proseminar Programmanalyse WS 11/12 André Hunke.
WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #6 SQL (Teil 3)
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #4 SQL (Teil 1)
WS 2012/13 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #6 SQL (Teil 3)
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #6 SQL (Teil 3)
WS 2007/08 Datenbanksysteme Mi 17:00 – 18:30 R Vorlesung #10 Physische Datenorganisation.
SS 2009 – IBB4C Datenmanagement Fr 15:15 – 16:45 R Vorlesung #2 Datenbankentwurf.
SS 2010 – IBB4C Datenmanagement Fr 15:15 – 16:45 R Vorlesung #2 Datenbankentwurf.
SS 2004 Datenbanken 4W Mi 13:30 – 15:00 G 2.30 Vorlesung #7 SQL (Teil 2)
WS 2011/12 Datenbanksysteme Mi 15:15 – 16:45 R Vorlesung #9 Physische Datenorganisation.
Vorlesung #4 SQL (Teil 1).
WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #8 Anfragebearbeitung.
SS 2004 Datenbanken 4W Mi 13:30 – 15:00 G 2.30 Vorlesung #3 ER Modellierung.
SS 2004 Datenbanken 4W Mi 13:30 – 15:00 G 2.30 Vorlesung #8 SQL (Teil 3)
SS 2004 Datenbanken 4W Mi 13:30 – 15:00 G 2.30 Vorlesung #5 Relationale Anfragesprachen.
WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #3 Das relationale Modell (Teil 2)
SS 2004 Datenbanken 4W Mi 13:30 – 15:00 G 2.30 Vorlesung #6 SQL (Teil 1)
WS 2012/13 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #8 SQL (Teil 5)
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #7 SQL (Teil 4)
WS 2013/14 Datenbanksysteme D0 15:15 – 16:45 R Vorlesung #5 SQL (Teil 2)
SS 2004 Datenbanken 4W Mi 13:30 – 15:00 G 2.30 Vorlesung #9 SQL (Teil 4)
WS 2007/08 Datenbanksysteme Mi 17:00 – 18:30 R Vorlesung #5 SQL (Teil 2)
WS 2012/13 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #7 SQL (Teil 4)
WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #7 SQL (Teil 4)
WS 2007/08 Datenbanksysteme Mi 17:00 – 18:30 R Vorlesung #8 Wiederholung: Referentielle Integrität/ Embedded SQL.
WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #4 SQL (Teil 1)
Datenbanksysteme für hörer anderer Fachrichtungen
WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #5 SQL (Teil 2)
Vorlesung #10 Physische Datenorganisation
Relationales Datenmodell und DDL
Structured Query Language
8 Erzeugen und Verwalten von Tabellen Ziele Kennenlernen der wichtigsten Datenbankobjekte Anlegen von Tabellen Datentypen zur Definition von Spalten.
Vorlesung #5 SQL (Teil 2).
Integritätsbedingungen (Constraints)
1 Referenzielle Konsistenz (1) Vorgehensweise: Klausel references mit nachfolgender Spezikation eines Attributs einer anderen Tabelle identifiziert ein.
WS 2014/15 Datenbanksysteme D0 15:15 – 16:45 R Vorlesung #6 SQL (Teil 3)
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #8 SQL (Teil 5)
SS 2014 – IBB4C Datenmanagement Do 17:00 – 18:30 R Vorlesung #3 ER Modellierung.
WS 2014/15 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #9 SQL Zusammenfassung.
Datenbanken erstellen mit PostgreSQL
Datenbanken abfragen mit SQL
SQL Lutz KleinostendarpJOBELMANN-SCHULE Datendefinition Die Organisation einer Datenbank basiert auf einer Anzahl verschiedener Objekte. Diese können physikalischer.
SQL Basics Schulung –
Vorlesung #4 Relationales Kalkül und SQL (Teil 1)
Vorlesung #6 SQL (Teil 3).
Vorlesung #7 SQL (Teil 4).
 Präsentation transkript:

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #6 SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Fahrplan Besprechung eines Beispiels, SQL-Übungen Rekursion Rekursion in SQL-92 Rekursion in DBMS-Dialekten (Oracle und DB2) Views (Sichten) - gespeicherte Abfragen Gewährleistung der logischen Datenunabhängigkeit Modellierung von Generalisierung UPDATE-fähige Sichten Datenintegrität Statische und dynamische Bedingungen Referentielle Integrität (primary key, foreign key) Propagieren der Primärschlüsselveränderungen (cascade) Ausblick Vorlesung #7, SQL Teil 4 Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion Rekursive Relation voraussetzen in UNI Schema voraussetzen : {[Vorgänger, Nachfolger]} Welche Vorlesungen muss man hören, um die Vorlesung Der Wiener Kreis zu verstehen? SELECT Vorgaenger FROM voraussetzen vs, Vorlesungen vo WHERE vs.Nachfolger = vo.VorlNr AND vo.Titel = 'Der Wiener Kreis' ; Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (2) Das sind aber nur die direkten Vorgänger, bzw. Vorgänger erster Stufe! Wie bekommt man alle? Zunächst Vorgänger zweiter Stufe: SELECT Vorgaenger FROM voraussetzen WHERE Nachfolger IN (SELECT Vorgaenger FROM voraussetzen, Vorlesungen WHERE Nachfolger = VorlNr AND Titel = 'Der Wiener Kreis'); Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (3) SELECT Vogänger FROM voraussetzen WHERE Nachfolger IN (SELECT Vorgänger FROM voraussetzen, Vorlesungen WHERE Nachfolger = VorlNr AND Titel = `Der Wiener Kreis´); SELECT v1.Vogänger FROM voraussetzen v1, voraussetzen v2, Vorlesungen v WHERE v1.Nachfolger = v2.Vorgänger AND v2.Nachfolger = v.VorlNr AND v.Titel = `Der Wiener Kreis´; Entschachtelung Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (4) Man kann die gewonenne entschachtelte Abfrage verallgemeinern für die Vorgänger n-ten Stufe SELECT v1.Vogänger FROM voraussetzen v1,..., voraussetzen v_n-1, voraussetzen vn, Vorlesungen v WHERE v1.Nachfolger = v2.Vorgänger AND... AND v_n-1.Nachfolger, vn.Vorgänger AND vn.Nachfolger = v.Vorgänger AND v.Titel = `Der Wiener Kreis´; Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (5) (-) sehr umständlich zu formulieren (-) ineffizient bei der Durchführung (-) leider in SQL-Standard nicht anders möglich SQL ist nicht Turing-vollständig, SQL ist deklarativ, keine Schleifen, keine Kontrollverzweigungen, keine GO TO, JUMP Befehle oder ähnliches Das Finden aller Vorgänger nennt man allgemein Berechnen der transitiver Hülle Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (6) – Transitive Hülle voraussetzen Der Wiener Kreis WissenschaftstheorieBioethik ErkenntnistheorieEthikMäeutik Grundzüge Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (7) – Transitive Hülle trans A,B (R)= {(a,b) k IN ( 1,..., k R ( 1.A= 2.B k-1.A= k.B 1.A= a k.B= b))} Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (8) – Oracle CONNECT BY Konstrukt select Titel from Vorlesungen where VorlNr in (select Vorgaenger from voraussetzen CONNECT BY Nachfolger = PRIOR Vorgaenger START WITH Nachfolger = (select VorlNr from Vorlesungen where Titel= 'Der Wiener Kreis')); Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Rekursion (9) in IBM DB2 with TransVorl (Vorg, Nachf) as (select Vorgaenger, Nachfolger from voraussetzen union all select t.Vorg, v.Nachfolger from TransVorl t, voraussetzen v where t.Nachf= v.Vorgaenger) select Titel from Vorlesungen where VorlNr in (select Vorg from TransVorl where Nachf in (select VorlNr from Vorlesungen where Titel= 'Der Wiener Kreis') ); Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (VIEWs) Aussenstehende – d.h. Datenbank-Benutzer wollen wissen, welcher Professor welche Vorlesungen liest? Benutzer wissen nichts von Schlüsseln (künstliche IDs), JOINs, verschiedenen Tabellen usw. CREATE VIEW ProfVorlesung AS SELECT Name, Titel FROM Professoren, Vorlesungen WHERE PersNr = gelesenVon; Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (2) (+) Wir zeigen den Benutzern genau das, was Sie sehen wollen Benutzerfreundlichkeit (+) Wir können die Informationen verbergen, die Benutzer nicht sehen wollen oder nicht sehen dürfen Datenschutz und Sicherheit (+) Wir können darunterliegende Basis-Tabellen verändern. Solange die Sichten angepasst werden, merken die Benutzer nichts logische Datenunabhängigkeit NAMETITEL KantGrundzuege... SELECT * FROM ProfVorlesung; Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (3) - logische Datenunabhängigkeit Relation 1Relation 2Relation 3 Benutzer 2Benutzer 1 Sicht 1Sicht 2Sicht 3 Physische Datenunabhängigkeit Logische Datenunabhängigkeit Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (4) – Beispiel logische Datenunabhängigkeit Internet-BesucherStudenten ProfVerlesung Dozenten lesen Kurse CREATE VIEW ProfVorlesung AS SELECT Name, Titel AS SELECT Name, Titel FROM Dozenten FROM Dozenten NATURAL JOIN lesen NATURAL JOIN lesen NATURAL JOIN Kurse; NATURAL JOIN Kurse; CREATE VIEW ProfVorlesung AS SELECT Name, Titel FROM Professoren, Vorlesungen WHERE PersNr = gelesenVon; Professoren Vorlesungen Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (5) – Modellierung der Generalisierungen Im relationalen Modell lassen sich Inklusion und Vererbung nicht elegant modellieren Angestellte : {[PersNr,Name]} Professoren: {[PersNr,Rang,Raum]} Assistenten: {[PersNr,Fachgebiet,Boss]} Wenn man die Relationen eins zu eins in eine SQL Datenbank umsetzt, muss man sehr oft explizit joinen, z.B. jedes Mal, wenn man den Namen (oder nach dem Namen) eines Professors oder eines Assistenten sucht. Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (6) – Untertyp als Sicht create table Angestellte (PersNrinteger not null, Namevarchar (30) not null); create table ProfDaten (PersNr integer not null, Rangcharacter(2), Raum integer); create table AssiDaten (PersNr integer not null, Fachgebiet varchar(30), Boss integer); create view Professoren as select * from Angestellte a, ProfDaten d where a.PersNr=d.PersNr; create view Assistenten as select * from Angestellte a, AssiDaten d where a.PersNr=d.PersNr; Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (7) – Obertyp als Sicht create table Professoren (PersNrinteger, Name varchar (30), Rangcharacter (2), Raum integer); create table Assistenten (PersNrinteger, Name varchar (30), Fachgebiet varchar (30), Bossinteger); create view Angestellte as (select PersNr, Name from Professoren) union (select PersNr, Name from Assistenten); Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (8) – Modellierung der Generalisierungen Sowohl Untertypen als auch Obertypen kann man als Sichten modellieren Erste Alternative: Obertyp(en) als Sicht(en), Untertyp(en) als Tabelle(n) Zweite Alternative: Obertyp(en) als Tabelle(n), Untertyp(en) als Sicht(en) Man spart sich bei den Zugriffen zusätzliche Joins, aber es entstehen Probleme beim Ändern oder Hinzufügen der Daten, da Sichten i.a. nicht veränderbar sind Die Zugriffe auf Tabellen sind i.a. Schneller und hinsichtlich der Datenänderungen unproblematisch, so dass man die Sichten für unwichtigere Entities nimmt Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (9) – UPDATE-Fähigkeit Sichten sind immer veränderbar im Bezug auf DDL- Operation, hier ist aber DML gemeint! Sichten sind i.a. nicht UPDATE fähig, da das DBMS bei einer UPDATE, DELETE oder INSERT Operation auf einer Sicht nicht weiß, welche Basis-Tabelle wie zu verändern ist: wenn Sichten Duplikatelimierung und Aggregatfunktionen (DISTINCT, GROUP BY usw.) beinhalten wenn der Schlüssel der zugrundeliegenden Tabelle(n) nicht enthalten ist Wenn durch das INSERT, UPDATE oder DELETE Statement mehr als eine Tabelle referenziert wird Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Sichten (10) – UPDATE-Fähigkeit Beispiel einer nicht UPDATABLE View: create view WieHartAlsPrüfer (PersNr, Durchschnittsnote) as select PersNr, avg(Note) from prüfen group by PersNr; alle Sichten theoretisch änderbare Sichten in SQL änderbare Sichten Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Datenintegrität Integitätsbedingungen bis jetzt Schlüssel Eindeutigkeit Beziehungskardinalitäten (min,max Notation) Attributdomänen (NUMBER, CHAR, DATE) Inklusion bei Generalisierung (Untertyp immer im Obertyp enthalten) statische Integritätsbedingungen Bedingungen an den Zustand der Datenbasis Mit Datenbank-CONSTRAINTs realisiert dynamische Integritätsbedingungen Bedingungen an Zustandsübergänge Mit Datenbank-TRIGGERn realisiert * engl. CONSTRAINT = Bedingung, TRIGGER = Auslöser Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Statische CONSTRAINTs NOT NULL UNIQUE CHECK (Regel) Vorisicht: CHECK ist auch dann erfüllt, wenn der logische Vergleich einen NULL-Wert zurückliefert CREATE TABLE MyProfessoren ( PersNr NUMBER(5,0) UNIQUE, Name VARCHAR2(30) NOT NULL, Rang CHAR(2) CHECK (Rang IN ('C1', 'C2', 'C3','C4') ) ); Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Statische CONSTRAINTs (2) Man kann CONSTRAINTs nachträglich definieren ALTER TABLE myprofessoren ADD CHECK (Rang IN ('C1', 'C2', 'C3','C4') ); löschen, verändern, suchen, auflisten, ein- und ausschalten, validieren (siehe SQL-Manual des jeweiligen DBMS, hier Oracle Syntax für das Löschen) ALTER TABLE myprofessoren DROP CONSTRAINT sys_c003798; Dynamische Constraints mit Triggern nächstes Mal (Vorlesung #9) Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Referentielle Integrität Sorgt dafür, dass die Beziehung zwischen dem Primärschlüssel und dem Fremdschlüssel bestehen bleibt (dass die Referenz - der Verweis - erhalten bleibt) Fremdschlüssel müssen auf existierende Tupel verweisen oder einen Nullwert enthalten Beispiel gelesenVon PersNr CREATE TABLE Professoren (PersNr INTEGER PRIMARY KEY...) (CREATE TABLE Vorlesungen gelesenVon INTEGER REFERENCES Professoren...) Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Referentielle Integrität (2) Schlüsselkandidat UNIQUE CONSTRAINT Primärschlüssel PRIMARY KEY Fremdschlüssel FOREIGN KEY (auch implizit durch das Wort REFERENCES in Tabellen- Definition) FOREIGN KEYs können auch NULL Werte enthalten UNIQUE FOREIGN KEY modelliert 1:1 Beziehung Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Einhaltung referentieller Integrität Änderung von referenzierten Daten Default: Zurückweisen der Änderungsoperation Propagieren der Änderungen: cascade Verweise auf Nullwert setzen: set null Dies ergibt folgende Möglichkeiten bei der Festlegung des CONSTRAINTs in der Tabellen- Definition ON [ UPDATE | DELETE ] [ SET NULL | CASCADE ] Kaskadierendes Löschen mit Vorsicht geniessen! Beispiel: wenn in Vorlesungen und hören kaskadierend gelöscht wird, verliert man die beim Löschen eines Professors die Information welcher Student was gehört hat. Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, UNI Schema mit Constraints Kemper Seite 157 URL: siehe Übungsblätter #4 und #5 Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R © Bojan Milijaš, Fazit und Ausblick Fazit SQL Teil 1 bis 3 SQL Teil 1 – Datentypen, einfache Abfragen SQL Teil 2 – komplexe Abfragen, Unterabfragen SQL Teil 3 – Rekursion, Views, Constraints Ausblick SQL Teil 4 Trigger Prozedurale Erweiterungen (PL/SQL) Einbettung in C,C++,Java SQL Schnittstellen JDBC,ODBC Query By Example QBE Vorlesung #6 - SQL (Teil 3)

WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #6 Ende