Datenbanken in der Praxis 6. Integrität, DBS-Architektur, Sichten

Transkript

1 Datenbanken in der Praxis 6. Integrität, DBS-Architektur, Sichten

2 Inhalt Konsistenz von Daten Datenintegrität Referentielle Integrität Architektur von Datenbanksystemen Drei-Ebenen-Architektur Individuelle Datensichten Definition von Views Update von Views 192

3 Konsistenz von Daten Aufgabe eines DBMS ist neben Bereitstellung von Anfrage- und Ablagefunktionalität für große Datenmengen auch die Sicherung der Konsistenz der Daten. Potentielle Beeinträchtigung der Konsistenz Systemfehler Mehrbenutzerzugriff Unerlaubte Manipulation von Daten Inkonsistente Bearbeitung von Daten Mögliche Resultate Datenverlust Verletzung der Datenintegrität 193

4 Datenintegrität Wir kennen bereits verschiedene Anforderungen an die Datenintegrität und haben die Gewährleistung dieser Integritätsbedingungen implizit (durch Verwendung spezifischer Modellierungskonstrukte) oder explizit (über die Möglichkeiten des DBMS) sichergestellt: Integrität von Schlüsselattributen Die Definition von Schlüsselattributen bedingt, dass keine zwei Tupel mit gleichem Wert in allen Schlüsselattributen existieren dürfen. Realisierung via DBMS bei Schemadefinition durch explizite Attributspezifikation als primary key Integrität von 1:N-Beziehungen Durch Integration des Schlüssels der Relation der 1-Seite der Beziehung als Fremdschlüssel in die Relation der N-Seite der Beziehung ist die Semantik einer 1:N-Beziehung - dass die Entities der N- Seite nur zu genau einem Entity der 1-Seite, aber ein Entity der 1-Seite mit beliebig vielen Entities der N-Seite in Beziehung stehen können - sichergestellt. 194

5 Datenintegrität Wir kennen schon verschiedene Anforderungen an die Datenintegrität und haben die Gewährleistung dieser Integritätsbedingungen implizit (durch Verwendung spezifischer Modellierungskonstrukte) oder explizit (über die Möglichkeiten des DBMS) sichergestellt: Integrität von 1:1-Beziehungen Analog einer 1:N-Beziehung kann durch Integration eines Fremdschlüssels in eine Relation ausgedrückt werden, dass ein Entity nur mit einem anderen Entity in Beziehung stehen kann. Allerdings fehlt jetzt noch der weitere Aspekt einer 1:1-Beziehung - die Exklusivität einer derartigen Beziehung (denn einem anderen Tupel könnte durchaus noch einmal derselbe Fremdschlüssel zugewiesen werden). Deshalb muss ein Fremdschlüsselattribut bei der Schemadefinition noch explizit als unique (und ggf. als not null) gekennzeichnet werden, damit die Semantik einer 1:1-Beziehung in der Datenbank korrekt modelliert ist und die Datenintegrität gewährleistet werden kann. 195

6 Datenintegrität Beispiel Name Bei der zweiten Übungsaufgabe fungierte jeweils ein PersNr anderer Mitarbeiter als Leiter eines Projekts. n MITARBEITER Aus diesem Grund muss beim Ausdruck der Beziehung leitet der Fremdschlüssel PersNr als unique 1 n Tätigkeit gekennzeichnet werden. Dabei spielt es keine Rolle, ob eine separate Beziehungsrelation erstellt oder der Fremdschlüssel leitet arbeitet an kap in die Tabelle PROJEKT übernommen wird. Name create table PROJEKT ( 1 m PROJEKT ProjNr ProjNr integer primary key, PersNr integer unique ) Priorität Ende Beginn 196

7 Datenintegrität Wir kennen schon verschiedene Anforderungen an die Datenintegrität und haben die Gewährleistung dieser Integritätsbedingungen implizit (durch Verwendung spezifischer Modellierungskonstrukte) oder explizit (über die Möglichkeiten des DBMS) sichergestellt: Datenintegrität durch Domänenspezifikation Selbst die Tatsache, dass Attributen bei ihrer Definition ein Wertebereich zugeordnet werden muss, ist ein Aspekt von Datenintegrität. So kann z.b. ausgedrückt werden, dass eine Matrikelnummer ganzzahlig sein muss. Allerdings sind diese datentypbasierten Domänenspezifikationen nicht allzu aussagekräftig, da der Wertebereich einzelner Attribute in der Praxis meist wesentlich kleiner ist als der Wertebereich vordefinierter Datentypen (z.b. Geburtsdatum eines lebenden Menschen vs. irgendein Datum) Aus diesem Grund können derartige Bereichseinschränkungen als statische Integritätsbedingungen explizit in SQL mit Hilfe der check-anweisung formuliert und einer Attributdefinition hinzugefügt werden. 197

8 Statischer Integritätscheck Beispiel Personal über ein Unternehmen ist bekannt: es gibt drei Abteilungen Mitarbeiter verdienen mindestens 1000 im Monat, aber höchstens create table Personal ( Personal Name Beruf Abteilung Gehalt Heinz Graser Elektroingenieur Silke Danilow Bürokauffrau Anita Eckart Controller Olaf Ruß-Möller Produktmanager Tatjana Koslowski Dolmetscher Sven Riedel Informatiker Gudrun Lange Buchhalter Wolf von Bülow Unternehmensberate r Name Beruf varchar(30) not null, varchar(30), Abteilung integer check (Abteilung >= 1 and Abteilung <= 3), Gehalt integer check (Gehalt >= 1000 and Gehalt <= 10000) ); 198

9 Statischer Integritätscheck Beispiel Prüfung über eine Universität ist bekannt: Vorlesungsnummern sind dreistellig Matrikelnummern sind minimal fünf- und maximal sechsstellig Prüfung VorlNr MatrNr Note Noten liegen im Bereich 1.0 bis 5.0 create table Prüfung ( ); VorlNr integer check ( Nummer >= 100 and Nummer <= 999 ), MatrNr integer check ( Nummer >= and Nummer <= ), Note numeric(2,1) check ( Note >= 1.0 and Note <= 5.0 ), primary key (VorlNr, MatrNr) Primärschlüssel, die aus mehreren Attributen bestehen, können erst nach der Definition aller vorkommenden Attribute spezifiziert werden. 199

10 Referentielle Integrität Konsistenz zwischen Relationen

11 Referentielle Integrität (1) Motivation Wir können mittlerweile Beziehungen in SQL derart formulieren, dass die Semantik der verschiedenen Kardinalitäten ausgedrückt werden kann. Allerdings sind wir bisher nicht in der Lage, sicherzustellen, dass referenzierte Tupel einer Beziehung auch tatsächlich existieren: Beispiel insert into Lehrveranstaltung values (500, Mathematik, 7111) Problem Es gibt in der Tabelle Lehrkraft im Schlüssel PersNr (auf den der Fremdschlüssel PersNr der Tabelle Lehrveranstaltung verweist) keinen Datensatz mit dem Attributwert Lehrveranstaltung Nummer Titel PersNr 123 Datenstrukturen Datenbanken in der Praxis Datenbanken Grundlagen Übung Datenstrukturen Mathematik 7111 Lehrkraft PersNr Name 6123 Prof. Benn 6897 Dr. Seifert Prof. Zanger? 201

12 Referentielle Integrität (2) Gegeben zwei Relationen R und S. die Attribut(menge) K sei Schlüssel von R und die Attribut(menge) FK sei Fremdschlüssel von R in S Forderung Zur Gewährleistung referentieller Integrität muss für R und S immer folgende Bedingung erfüllt sein: π[fk](s) π[k](r). Bedeutung Wenn zwei Relationen R und S über eine Schlüssel- / Fremdschlüsselbeziehung in Beziehung stehen, dann muss jeder Attributwert des Fremdschlüssels auch als Attributwert des Schlüssels existieren. 202

13 Referentielle Integrität (3) Beispiel R: Lehrkraft S: Lehrveranstaltung K: Lehrkraft.PersNr FK: Lehrveranstaltung.PersNr Lehrveranstaltung Nummer Titel PersNr 123 Datenstrukturen Datenbanken in der Praxis Datenbanken Grundlagen Übung Datenstrukturen 6897 Vergleich der Schlüsselattributprojektionen π[fk](s) π[k](r) {6897, 6123} {6123, 6897, 43424} Bedingung für referentielle Integrität erfüllt Lehrkraft PersNr Name 6123 Prof. Benn 6897 Dr. Seifert Prof. Zanger 203

14 Referentielle Integrität (4) Beispiel insert into Lehrveranstaltung values (500, Mathematik, 7111) R: Lehrkraft S: Lehrveranstaltung K: Lehrkraft.PersNr Lehrveranstaltung Nummer Titel PersNr 123 Datenstrukturen Datenbanken in der Praxis Datenbanken Grundlagen Übung Datenstrukturen Mathematik 7111 FK: Lehrveranstaltung.PersNr Vergleich der Schlüsselattributprojektionen π[fk](s) π[k](r) {6897, 6123, 7111} {6123, 6897, 43424} Bedingung für referentielle Integrität nicht erfüllt Lehrkraft PersNr Name 6123 Prof. Benn 6897 Dr. Seifert Prof. Zanger 204

15 Referentielle Integrität (5) Damit referentielle Integrität gewährleistet werden kann, sind Änderungen an den Relationen R und S nur unter folgenden Bedingungen erlaubt: Einfügen eines Tupels s in S Für den Attributwert fk der Attributmenge FK von s muss gelten: fk π[k](r) Verändern des Wertes der Attributmenge FK eines Tupels s der Relation S Für den geänderten Attributwert fk der Attributmenge FK von s muss gelten: fk π[k](r) Ändern des Wertes der Attributmenge K eines Tupels r der Relation R Für den ursprünglichen Attributwert k der Attributmenge K muss gelten: σ[fk=k](s) = Löschen eines Tupels r in R Für den ursprünglichen Attributwert k der Attributmenge K von r muss gelten: σ[fk=k](s) = 205

16 Referentielle Integrität in SQL Definition Um referentielle Integrität in SQL gewährleisten zu können, muss bei der Schemadefinition die Schlüssel - Fremdschlüsselbeziehung zwischen zwei (oder mehreren) Tabellen definiert werden. Hierzu wird die Attributdefinition um eine references-klausel erweitert, die auf die Tabelle verweist, in der das Attribut Primärschlüssel ist. Falls ein Fremdschlüssel mehrere Attribute umfasst, muss er nach Definition aller Attribute explizit mittels foreign key als Fremdschlüssel gekennzeichnet werden und mittels der references- Klausel der Verweis auf die Tabelle hergestellt werden, in der die Attributkombination Primärschlüssel ist. Die durch foreign key bzw. die references-klausel gekennzeichneten Fremdschlüssel können auch Nullwerte annehmen, falls sie nicht explizit als not null markiert wurden. Verhalten Damit ein Tupel geändert oder eingefügt werden kann, müssen die darin enthaltenen Fremdschlüsselreferenzen existieren. Ebenso lassen sich jetzt keine Tupel mehr löschen, die noch an anderer Stelle referenziert werden. 206

17 Beispiel create table Prüfung ( VorlNr integer check ( Nummer >= 100 and Nummer <= 999 ), MatrNr integer check ( Nummer >= and Nummer <= ), Note numeric(2,1) check ( Note >= 1.0 and Note <= 5.0 ), primary key (VorlNr, MatrNr), foreign key (VorlNr) references Lehrveranstaltung, foreign key (MatrNr) references Student ); Hinweis Prüfung VorlNr MatrNr Note Durch die Referenzierung der Tabellen Lehrveranstaltung und Student wird automatisch die Korrespondenz zwischen dem Fremdschlüssel VorlNr und dem Primärschlüssel der Tabelle Lehrveranstaltung sowie dem Fremdschlüssel MatrNr und dem Primärschlüssel von Student hergestellt. Dazu müssen natürlich die Primärschlüssel in diesen Tabellen festgelegt worden sein. 207

18 Propagieren von Änderungen Neben der standardmäßigen Gewährleistung der referentiellen Integrität durch Ablehnen verletzender Änderungen an Schlüsselattributen kann optional auch eine automatische Kaskadierung von Änderungsoperationen als Maßnahme zur Integritätssicherung eingestellt werden: Wird ein Primärschlüsselwert geändert, werden alle korrespondierenden Fremdschlüsselwerte auf die gleiche Weise geändert. Hierzu wird in SQL on update cascade zur references- Klausel hinzugefügt. Wird das zu einem Primärschlüsselwert korrespondierende Tupel einer Tabelle gelöscht, werden alle Tupel, die in einer Fremdschlüsselbeziehung zu dieser Tabelle stehen, ebenfalls gelöscht. Hierzu muss die references-klausel von SQL um on delete cascade ergänzt werden. Achtung Das kaskadierende Löschen ist gefährlich. Zwar bleibt die referentielle Integrität erhalten, aber es könnten bei ungeschickter Modellierung durchaus Datensätze unbeabsichtigt aus der Datenbank entfernt werden. 208

19 Beispiel - Änderungspropagation Ausgangspunkt Lehrkraft PersNr Name zwei Tabellen mit on update cascade - Referenzierungssemantik 6123 Prof. Benn 6897 Dr. Seifert create table Lehrkraft Prof. Zanger ( PersNr integer primary key, Name varchar(30) Lehrveranstaltung ) Nummer Titel PersNr 123 Datenstrukturen 6897 create table Lehrveranstaltung 234 Datenbanken in der Praxis 6897 ( 345 Datenbanken Grundlagen 6123 Nummer integer primary key, 456 Übung Datenstrukturen 6897 Titel varchar(30), PersNr integer references Lehrkraft on update cascade ); 209

20 Beispiel - Änderungspropagation Ausgangspunkt create table Lehrkraft ( PersNr integer primary key, Name varchar(30) ) create table Lehrveranstaltung ( Nummer integer primary key, Titel varchar(30), PersNr integer references Lehrkraft on update cascade ); Update-Operation Lehrkraft PersNr Name update Lehrkraft 6123 Prof. Benn set PersNr = Dr. Seifert where PersNr = 6897; Resultat Prof. Zanger Die Änderung eines Primärschlüsselwerts bewirkt jetzt automatisch die gleichartige Änderung aller korrespondierenden Fremdschlüsselwerte: Lehrveranstaltung Nummer Titel PersNr 123 Datenstrukturen Datenbanken in der Praxis Datenbanken Grundlagen Übung Datenstrukturen

21 Beispiel - Löschpropagation Ausgangspunkt create table Lehrkraft ( ) PersNr integer primary key, Name varchar(30) create table Lehrveranstaltung ( ); Nummer integer primary key, Titel varchar(30), PersNr integer references Lehrkraft on delete cascade Änderungsoperation delete from Lehrkraft where PersNr = 6897 Resultat Lehrveranstaltung PersNr Lehrkraft Name 6123 Prof. Benn 6897 Dr. Seifert Prof. Zanger Das Löschen des Tupels mit dem Primärschlüsselwert 6897 aus der Tabelle Lehrkraft bewirkt automatisch auch das Entfernen aller Tupel mit dem Fremdschlüsselwert 6897 aus der Tabelle Lehrveranstaltung. Obwohl dadurch die referentielle Integrität gewahrt bleibt, erscheint es fraglich, ob diese Funktionalität tatsächlich gewünscht ist. Nummer Titel PersNr 123 Datenstrukturen Datenbanken in der Praxis Datenbanken Grundlagen Übung Datenstrukturen

22 Nullsetzen von Fremdschlüsseln Neben der standardmäßigen Gewährleistung der referentiellen Integrität durch Ablehnen verletzender Änderungen an Schlüsselattributen, kann optional auch eine automatische Nullsetzung von Fremdschlüsselattributen als Maßnahme zur Integritätssicherung eingestellt werden: Wird ein Primärschlüsselwert geändert, werden alle korrespondierenden Fremdschlüsselwerte auf den Nullwert null gesetzt. Hierzu wird in SQL die references-klausel um on update set null ergänzt. Wird das zu einem Primärschlüsselwert korrespondierende Tupel einer Tabelle gelöscht, werden die Fremdschlüsselwerte aller Tupel, die in einer Fremdschlüsselbeziehung zu dieser Tabelle stehen auf denn Nullwert null gesetzt. Die Realisierung erfolgt in SQL durch Hinzufügen von on delete set null zur references-klausel. 212

23 Beispiel - Nullsetzen Ausgangspunkt Resultat Lehrkraft create table Lehrkraft ( PersNr integer primary key, Name varchar(30) ) create table Lehrveranstaltung ( Nummer integer primary key, Titel varchar(30), PersNr integer references Lehrkraft on delete set null ); Änderungsoperation delete from Lehrkraft where PersNr = 6897 PersNr Name Das Löschen des Tupels mit dem 6123 Prof. Benn Primärschlüsselwert 6897 der 6897 Dr. Seifert Tabelle Lehrkraft bewirkt automa- tisch das Nullsetzen aller in Bezie Prof. Zanger hung stehender Tupel mit dem Fremdschlüsselwert 6897 aus Tabelle Lehrveranstaltung. Dieses Verhalten bewahrt ebenfalls die referentielle Integrität und erscheint adäquater, da das Löschen einer Lehrkraft nicht immer das Löschen aller assoziierten Lehrveranstaltungen nach sich zieht. Lehrveranstaltung Nummer Titel PersNr 123 Datenstrukturen 6897 null 234 Datenbanken in der Praxis 6897 null 345 Datenbanken Grundlagen Übung Datenstrukturen 6897 null 213

24 Architektur von Datenbanksystemen

25 Sichten auf ein DBS Wir haben uns bisher mit der semantischen Modellierung eines Realweltausschnitts beschäftigt und diesen in ein konkretes Datenmodell übertragen. Wir haben uns jedoch noch nicht mit der konkreten Verwendung dieser Daten in verschiedenen Anwendungsgebieten beschäftigt und auch nicht mit Fragen der technischen Realisierung. Demzufolge unterscheiden wir drei Sichten auf ein Datenbanksystem: Konzeptuelle Sicht (DB-Designer, DB-Programmierer) Dies ist der Aspekt der Datenmodellierung, den wir bisher betrachtet haben. Wir haben die logischen Strukturen von Objekten und deren Beziehungen identifiziert und in einem konkreten Datenmodell hinterlegt. Externe Sicht (DB-Anwender) Die Aufgabe eines DBS ist es, die Datenverwaltung verschiedener externer Anwendungen zu übernehmen. Aus diesem Grund hat jede externe Anwendung einer Datenbank eigene Anforderungen an die zu verarbeitenden Daten und des Zugriffsschutzes und demzufolge eine eigene Sicht auf die modellierten Strukturen und Beziehungen einer Datenbank. Interne Sicht (DB-Administrator) Optimierte Anordnung von Daten auf Speichermedien und Zugriffsoptimierung. 215

26 Konzeptuelles Schema Die drei Sichten werden durch jeweils ein Schema formal beschrieben: Konzeptuelles Schema enthält alle Eigenschaften von Objekten und deren Beziehungen, die für die Datenverwaltung eine Rolle spielen. erfasst und definiert Aspekte einer korrekten Datenverarbeitung, z.b. Integritätsbedingungen ist ein stabiler Bezugspunkt für alle darauf basierenden Anwendungen (der externen Sicht). Es ändert sich eher selten, z.b. wenn sich die Unternehmensstruktur ändert. stellt auch eine einheitliche Dokumentation wesentlicher Aspekte des Problembereiches eines Unternehmens dar kontrolliert die Verwendung von Daten an zentraler Stelle 216

27 Externes und internes Schema Die drei Sichten werden durch jeweils eigene Schemata formal beschrieben: Externes Schema beschreibt die Aspekte konzeptueller Objekte und deren Beziehungen, die für die Datenverwaltung einer Anwendung eine Rolle spielen erfasst und definiert Aspekte einer korrekten Datenverarbeitung einer externen Anwendung definiert Transformationsregeln und beschreibt die Herleitung externer Objekte aus den Objekten des konzeptuellen Schemas Internes Schema beschreibt wie und wo einzelne Attribute gespeichert sind, z.b. physische Trennung wenig benötigter von häufig benutzten Attributen Anlegen zusätzlicher Zugriffsstrukturen (Indexe) für Attribute siehe Physische Datenorganisation 217

28 Drei-Ebenen-Architektur externe Ebene (externes Schema) Studenten- sekretariat Zentrales Prüfungsamt Personalabteilung Student Student prüfen Hiwi Mitarbeiter Raum- planung Raum Transformationsregeln konzeptuelle Ebene (konzeptuelles Schema) Unternehmensmodell TU-Chemnitz Student Lehrveranstaltung Lehrkraft hört Raum prüfen interne Ebene (internes Schema) Hardwarenahe Organisation und Verwaltung der Daten Transformationsregeln PersNr: int (2 Byte) auf Platte 1 Gehalt: float (4 Byte) auf Platte 2 218

29 Individuelle Datensichten

30 Datenindividualisierung In den Anwendungen der externen Ebene müssen die Daten der Datenbank in einer für die jeweilige Benutzergruppe geeigneten Form bereitgestellt werden. Diese individuelle Bereitstellung erfolgt aus zwei Gründen Bereitstellung nur von relevanten Daten für eine Nutzergruppe Verwirklichung von Datenschutzaspekten, d.h. nicht jeder Nutzer darf alle Daten sehen Grundlage der Realisierung beider Aspekte ist die Partitionierung von Tabellen 220

31 Partitionierung Individuelle Datensichten bzw. Zugriffseinschränkungen können vielfältiger Natur sein: Vertikale Partitionierung Zugriff nur auf bestimmte Tupel einer Relation. Horizontale Partitionierung Zugriff nur auf bestimmte Spalten einer Relation. Gruppierende & aggregierende Partitionierung Kein Zugriff auf individuelle Tupel, sondern nur auf gruppierte Werte und die Ergebnisse von Aggregatfunktionen auf Gruppen. Kombinierte Partitionierung Oft werden die verschiedenen Partitionierungen gemeinsam verwendet. 221

32 Realisierung von Sichten Wie wir gesehen haben, realisieren Sichten den Zugriff nur auf bestimmte Teile von Tabellen und können somit mittels select-statement definiert werden. Um einer Anwendung der externen Ebene ausschließlich Zugriff auf partitionierte Tabellen zu ermöglichen, definiert man virtuelle Tabellen als Ergebnis einer Partitionierung mittels eines select-statements. Diese virtuellen Tabellen heißen Views (Sichten) und können direkt in SQL definiert werden: create view Name as ( select-statement ) Indem man externen Applikationen den Zugriff auf Views gewährt, aber nicht auf die Originaltabellen, wird auf diesem Wege sowohl der Datenschutz gewährleistet als auch die Bereitstellung nur bestimmter Informationsaspekte realisiert. Views können - zumindest bei Anfragen - wie normale Tabellen Verwendung finden. 222

33 Views - Beispiel (1) Wunsch Die Sachbearbeiter der verschiedenen Studiengänge im zentralen Prüfungsamt sollen nur Zugriff auf die Studenten ihres Studienganges haben. Realisierung Wir definieren Sichten für Mathematik- und Philosophiestudenten: create view Mathematikstudent as ( select MatrNr, Name from Student where Studiengang = Mathematik ); Student MatrNr Name Studiengang Archimedes Mathematik Pythagoras Mathematik Sophokles Philosophie Eratosthenes Mathematik Platon Philosophie Philosophiestudent MatrNr Name Sophokles Platon Mathematikstudent MatrNr Name Archimedes Pythagoras Eratosthenes create view Philosophiestudent as ( select MatrNr, Name from Student where Studiengang = Philosophie ); Die Views Philosophiestudent und Mathematikstudent können für Anfragen wie normale Tabellen verwendet werden, z.b. select * from Mathematikstudent 223

34 Views - Beispiel (2) Wunsch Abteilungsleiter benötigen für ihre Budget- planungen auch Informationen über andere Abteilungen. Allerdings dürfen sie aus Datenschutzgründen nicht erfahren, was Mitarbeiter anderer Abteilungen verdienen. Personal Name Beruf Abteilung Gehalt Heinz Graser Elektroingenieur Silke Danilow Bürokauffrau Anita Eckart Controller Olaf Ruß-Möller Produktmanager Tatjana Koslowski Dolmetscher Realisierung Wir definieren eine Sicht, die Informationen über die einzelnen Abteilungen nur in aggregierter Form enthält: Sven Riedel Informatiker Gudrun Lange Buchhalter Wolf von Bülow Unternehmensberate r create view Abteilungsstatistik(Abteilung, Mitarbeiter, Gehälter) as ( select Abteilung, count(*), sum(gehalt) ); from Personal group by Abteilung Bei der Vergabe eines Namens an einen View können gleichzeitig die Attribute des Views (um-)benannt werden. Abteilungsstatistik Abteilung Mitarbeiter Gehälter

35 Views - Beispiel (3) Weitere Verwendung Views können auch zur Vereinfachung von Anfragen eingesetzt werden, in- dem komplexere Anfragen (z.b. Joins) in Views abgelegt und dann einfachere Anfragen an den View gestellt werden: Lehrveranstaltung Nummer Titel PersN 123 Datenstrukturen 6897 r 234 Datenbanken in der Datenbanken Praxis Grundlagen Übung Datenstrukturen 6897 Lehrkraft PersNr Name 6123 Prof. Benn 6897 Dr. Seifert Prof. Zanger create view Lehrbelastung(Name, Anzahl) as ( select Name, count(*) from Lehrveranstaltung natural join Lehrkraft group by Name ); Beispielanfrage Lehrbelastung Name Anzahl Dr. Seifert 3 Prof. Benn 1 select * from Lehrbelastung where Anzahl > 1 statt: select Name, count(*) as Anzahl from Lehrveranstaltung natural join Lehrkraft group by Name having Anzahl > 1 Anfrageergebnis Name Anzahl Dr. Seifert 3 225

36 Spezialisierungen mit Views Views sind eine Möglichkeit, Spezialisierungen in SQL auszudrücken: Weg Die Datensätze werden zentral in einer Tabelle mit allen Informati- onen verwaltet. Anhand bestimmter Attribute werden virtuelle Ta- bellen (Sichten) mit Teilinformationen des Datenbestandes gebildet. Somit ist zumindest anfragetechnisch die Bildung einer kompletten Spezialisierungshierarchie denkbar. Beispiel create view Mathematikstudent as ( select MatrNr, Name from Student where Studiengang = Mathematik ); create view Philosophiestudent as ( select MatrNr, Name from Student where Studiengang = Philosophie ); Student MatrNr Name Studiengan Archimedes g Mathematik Pythagoras Mathematik Sophokles Philosophie Eratosthene Mathematik s Platon Philosophie Mathematikstudent MatrNr Name Archimedes Pythagoras Eratosthenes Philosophiestudent MatrNr Name Sophokles Platon 226

37 Generalisierungen mit Views Views sind eine Möglichkeit, Generalisierungen in SQL auszudrücken: Weg Die Datensätze verschiedener Tabellen werden in einem View (unter Wegfall aller Informationen, die nicht in allen Tabellen vorhanden ist) vereinigt, der damit eine generalisierende Sicht darauf bietet. Die Verwaltung der Datensätze erfolgt weiterhin in den Basistabellen. Beispiel create view AlleStudenten as AlleStudenten ( select MatrNr, Name MatrNr Name from Mathematikstudent Archimedes ) Pythagoras union Sophokles ( select MatrNr, Name Eratosthenes from Philosophiestudent Platon ); Mathematikstudent MatrNr Name Semeste Archimedes r Pythagoras Eratosthene s Philosophiestudent MatrNr Name Sophokles Platon 2 227

38 Update von Views Wir haben gesehen dass Views u.a. auch Spezialisierungs- und Generalisierungshierarchien in SQL ausdrücken können. Allerdings haben wir hierbei bisher nur Anfragefunktionalität untersucht. Frage Sind Views auch veränderbar? Können insert-, update- oder delete-operationen ausgeführt werden? Anwort Merke Der Update eines Views ist möglich, wenn der View weder Aggregatfunktionen bzw. Anweisungen wie having, distinct oder group by enthält in der select-projektionsliste nur eindeutige Spaltennamen und einen Schlüssel der Basistabelle enthält nur genau eine Tabelle beinhaltet, die natürlich veränderbar sein muss Selbst wenn ein View theoretisch änderbar sein sollte, bedeutet dies nicht, dass SQL diese Änderung auch gestattet. 228