Kapitel 6: Sichten und Zugriffskontrolle

Kapitel 6: Sichten und Zugriffskontrolle Sichten und Zugriffskontrolle Sichtenkonzept, auf Sichten, vergabe in Datenbanksystemen, Autorisierung und Authentifikation, Statistische Datenbanken. Datenbankeinsatz: Sichten und Zugriffskontrolle 1 Datenbankeinsatz: Sichten und Zugriffskontrolle 2 Folie aus DWM Hergeleitete Datenelemente Basisdaten werden von außen aktualisiert, keine Berechnung aus anderen Daten in der Datenbank, Hergeleitete Daten aus den Basisdaten hergeleitete Daten, können aus anderen hergeleiteten Daten berechnet sein. Gesamtkosten der Branche Arbeitskosten der Branche Sichten Sichten: virtuelle Relationen bzw. virtuelle Datenbankobjekte in anderen Datenmodellen; englisch: view. Sichten sind externe DB-Schemata folgend der 3-Ebenen-Schemaarchitektur. Gegenteil : Basis-Relationen. Gesamtkosten des Departements Arbeitskosten des Departements Hergeleitete Elemente Projektkosten Arbeitskosten des Projekts Branchen Overhead Materialkosten Aktivitätskosten Basisdaten Updates von außen Datenbankeinsatz: Sichten und Zugriffskontrolle 3 Datenbankeinsatz: Sichten und Zugriffskontrolle 4

Definition von Sichten in SQL Beispiel Zugrundeliegende Relation: MGA(Mitarbeiter, Gehalt, Abteilung) create view highincomema as select Mitarbeiter, Gehalt where Gehalt > 20 View dann im Prinzip verwendbar wie normale Relation, z. B.: select * from highincomema where Gehalt < 50 insert into highincomema values ('Klemens', 35000) Tupel in der Sicht existieren nicht wirklich. Stattdessen Rewrite der Query gegen die Sicht. Definition einer Sicht Angegeben werden muß Relationenschema (explizit oder implizit aus Ergebnistyp der Anfrage), Berechnungsvorschrift (Anfrage) für virtuelle Relation. create view SichtName [SchemaDeklaration] as SQLAnfrage [with check option] der Sicht, die nicht sichtbaren Teil der Daten betreffen, werden zurückgewiesen. Datenbankeinsatz: Sichten und Zugriffskontrolle 5 Datenbankeinsatz: Sichten und Zugriffskontrolle 6 Einsatz von Sichten am Beispiel Sichten Vorteile und Nachteile Prüf(Studienfach, Fach, Student, Prüfer, Datum, Note) 1. Fakultät für Informatik sieht nur die Daten der Informatikstudenten. 2. Prüfungsamt sieht alle Daten. 3. Jeder Student darf seine eigenen Daten sehen, aber nicht ändern. 4. Kommission für die Vergabe von Promotionsstipendien darf von Studenten die Durchschnittsnote sehen. 5. Dekan darf statistische Daten über die Absolventen des letzten Jahrgangs lesen. 6. Sekretariate dürfen die Prüfungsdaten der zugehörigen Professoren einsehen. Vorteile: Vereinfachung von Anfragen, Strukturierung der Datenbank, Konzepte werden benamt; logische Datenunabhängigkeit (Sichten stabil bei der Datenbankstruktur), Beschränkung von Zugriffen, Datenschutz. Probleme: Automatische Anfragetransformation, Durchführung von auf Sichten. z Datenbankeinsatz: Sichten und Zugriffskontrolle 7 Datenbankeinsatz: Sichten und Zugriffskontrolle 8

Beispielszenario im Relationenmodell MGA(Mitarbeiter, Gehalt, Abteilung) AL(Abteilung, Leiter) MGA speichert Daten über Zugehörigkeit von Mitarbeitern zu Abteilungen und ihr jeweiliges Gehalt. AL gibt für jede Abteilung den Abteilungsleiter an. Projektionssicht (1) MA := π Mitarbeiter, Abteilung (MGA) In SQL mit create view-anweisung: create view MA as select Mitarbeiter, Abteilung Änderungsanweisung für die Sicht MA: insert into MA values ('Zuse', 'Info') Korrespondierende Anweisung auf der Basisrelation MGA: insert into MGA values ('Zuse', null,'info') Datenbankeinsatz: Sichten und Zugriffskontrolle 9 Datenbankeinsatz: Sichten und Zugriffskontrolle 10 Projektionssicht (2) Projektionssicht (3) Problem der Konsistenzerhaltung, falls Gehalt als not null deklariert. Konsistenzerhaltung wäre gegeben, wenn wir irgendeinen Wert als Gehalt einsetzten. Recht starke Annahme unnatürlich. Widerspricht Minimalität. Weiteres Beispiel: Person PersoNr Name 354590 Böhm 4711 Böhm Sicht create view PName as select distinct Name from Person Jetzt Änderung von Böhm in Prof. Böhm. Problematisch, wenn mehrere Böhms in DB. Datenbankeinsatz: Sichten und Zugriffskontrolle 11 Datenbankeinsatz: Sichten und Zugriffskontrolle 12

Selektionssichten MG := σ Gehalt>20 (π Mitarbeiter, Gehalt (MGA)) create view MG as select Mitarbeiter, Gehalt where Gehalt > 20 Tupelmigration: Ein Tupel MGA('Zuse', 25, 'Info') wird aus der Sicht herausbewegt : update MG set Gehalt = 15 where Mitarbeiter = 'Zuse' Datenbankeinsatz: Sichten und Zugriffskontrolle 13 Kontrolle der Tupelmigration create view MG as select Mitarbeiter, Gehalt where Gehalt > 20 with check option Einfügen von Tupeln in die Sicht, die Gehalt > 20 nicht erfüllen, wird zurückgewiesen, ebenso Updates. Datenbankeinsatz: Sichten und Zugriffskontrolle 14 Verbundsichten (1) MGAL := MGA AL In SQL: create view MGAL as select Mitarbeiter, Gehalt, MGA.Abteilung, Leiter, AL where MGA.Abteilung = AL.Abteilung Änderungsoperationen in der Regel nicht eindeutig übersetzbar: insert into MGAL values ('Turing', 30, 'Info', 'Zuse') Mitarbeiter Gehalt Abteilung Leiter Verbundsichten (2) Änderung wird transformiert zu insert into MGA values ('Turing', 30, 'Info') plus 1. Einfügeanweisung auf AL: insert into AL values ('Info','Zuse') 2. oder alternativ: update AL set Abteilung = 'Info' where Leiter = 'Zuse' Besser bezüglich Minimalitätsforderung. Hat aber Seiteneffekte. (Widerspricht Effektkonformität.) Datenbankeinsatz: Sichten und Zugriffskontrolle 15 Datenbankeinsatz: Sichten und Zugriffskontrolle 16

Verbundsichten (3) MGAL := MGA AL insert into MGAL values ('Turing', 30, 'Info', 'Zuse') Änderung wird transformiert zu insert into MGA values ('Turing', 30, 'Info') plus update AL set Abteilung = 'Info' where Leiter = 'Zuse' Warum Seiteneffekte? M G A Buchmann 30.000 Info A L Info Böhm Pipapo Zuse Verbundsichten (4) MGAL := MGA AL In SQL: create view MGAL as select Mitarbeiter, Gehalt, MGA.Abteilung, Leiter, AL where MGA.Abteilung = AL.Abteilung Es gibt aber auch Änderungsoperationen, die eindeutig übersetzbar sind. Geben Sie Beispiele. in Sicht M G A L Buchmann 30.000 Info Böhm wird zu Buchmann 30.000 Info Zuse Datenbankeinsatz: Sichten und Zugriffskontrolle 17 Datenbankeinsatz: Sichten und Zugriffskontrolle 18 Aggregierungssichten create view AS (Abteilung, SummeGehalt) as select Abteilung, sum(gehalt) group by Abteilung Folgende Änderung ist nicht eindeutig umsetzbar: update AS set SummeGehalt = SummeGehalt + 1000 where Abteilung = 'Info' Kriterien für auf Sichten Effektkonformität: Benutzer sieht Effekt, als wäre die Änderung auf der Sichtrelation direkt ausgeführt worden. Minimalität: Basisdatenbank sollte nur minimal geändert werden, um den erwähnten Effekt zu erhalten. Konsistenzerhaltung: Änderung einer Sicht darf zu keinen Integritätsverletzungen der Basisdatenbank führen. Respektierung des Datenschutzes: Wird die Sicht aus Datenschutzgründen eingeführt, darf der bewußt ausgeblendete Teil der Basisdatenbank von der Sicht nicht betroffen werden. Datenbankeinsatz: Sichten und Zugriffskontrolle 19 Datenbankeinsatz: Sichten und Zugriffskontrolle 20

Respektierung des Datenschutzes Illustration Zugrundeliegende Relation: MGA(Mitarbeiter, Gehalt, Abteilung) create view highincomema as select Mitarbeiter, Gehalt where Gehalt > 20 insert into highincomema values ('Klemens', 15) Klassifikation der Problembereiche (1) 1. Verletzung der Schemadefinition, z. B. Einfügen von Nullwerten bei Projektionssichten. 2. Datenschutz: Seiteneffekte auf nicht-sichtbaren Teil der Datenbank vermeiden (Tupelmigration, Selektionssichten). 3. Nicht immer eindeutige Transformation: Auswahlproblem. Datenbankeinsatz: Sichten und Zugriffskontrolle 21 Datenbankeinsatz: Sichten und Zugriffskontrolle 22 Klassifikation der Problembereiche (2) Maßnahme 4. Aggregierungssichten (u. a.): Keine sinnvolle Transformation möglich. 5. Elementare Sichtänderung soll genau einer atomaren Änderung auf Basisrelation entsprechen: 1:1-Beziehung zwischen Sichttupeln und Tupeln der Basisrelation (kein Herausprojizieren von Schlüsseln). Einschränkung der Möglichkeiten, Sichten zu ändern. z Datenbankeinsatz: Sichten und Zugriffskontrolle 23 Datenbankeinsatz: Sichten und Zugriffskontrolle 24

Behandlung von Sichten in SQL Aktueller Standard SQL-92: Integritätsverletzende Sichtänderungen nicht erlaubt, datenschutzverletzende Sichtänderungen: Benutzerkontrolle (with check option), Sichten mit nicht-eindeutiger Transformation: Sicht nicht änderbar (SQL-92 restriktiver als notwendig). Datenbankeinsatz: Sichten und Zugriffskontrolle 25 Beispiel Sicht: Bibliothek = proj[nachname,isbn](buch_exemplare JOIN Ausleihe JOIN Personen) Die folgende Änderung ist eindeutig: delete from Bibliothek where Nachname= Böhm and ISBN= 4711 Entsprechende Instanz aus Ausleihe löschen. Löschung der Person wäre nicht effektkonform, weil Person i. a. noch andere Bücher ausgeliehen hat. Datenbankeinsatz: Sichten und Zugriffskontrolle 26 für Sichtänderungen (1) für Sichtänderungen (1) Datenbankeinsatz: Sichten und Zugriffskontrolle 27 Datenbankeinsatz: Sichten und Zugriffskontrolle 28

für Sichtänderungen (1) für Sichtänderungen (2) Änderbar nur Selektions- und Projektionssichten (Verbund und Mengenoperationen nicht erlaubt). Was kann bei Mengenoperationen in Sichtdefinition anbrennen? kein distinct in Projektionssichten, um 1:1-Zuordnung von Sichttupeln zu Basistupeln zu erreichen In SQL: select vs. select distinct. Arithmetik und Aggregatfunktionen im select-teil sind verboten. Beispiel: select Name, PersKosten + laufendekosten as Gesamtkosten from Abteilung Genau eine Referenz auf einen Relationsnamen im from-teil erlaubt, d. h. keine Verbundsichten und auch kein Selbstverbund, group by und having verboten Warum? keine Unteranfragen mit Selbstbezug im where-teil erlaubt, d. h. Relationsname im obersten SFW-Block nicht in from-teilen von Unteranfragen verwenden. Datenbankeinsatz: Sichten und Zugriffskontrolle 29 Datenbankeinsatz: Sichten und Zugriffskontrolle 30 Quantoren und Mengenvergleiche Auswertung von Anfragen an Sichten Beispiel aus vorangegangenem Kapitel. select Note from Prüft where Matrikelnummer = 'HRO-912291' and Note all ( select Note from Prüft where Matrikelnummer = 'HRO-912291') Äquivalent zu: select max(note) from Prüft where Matrikelnummer = 'HRO-912291' select: Sichtattribute eventuell umbenennen bzw. durch Berechnungsterm ersetzen, from: Namen der Originalrelationen, konjunktive Verknüpfung der where-klauseln von Sichtdefinition und Anfrage, eventuell Umbenennungen. z Datenbankeinsatz: Sichten und Zugriffskontrolle 31 Datenbankeinsatz: Sichten und Zugriffskontrolle 32

Auswertung von Anfragen an Sichten Beispiel Sicht: create view MGAL2 (name, salary, dept, boss) as select Mitarbeiter, Gehalt, MGA.Abteilung, Leiter, AL where MGA.Abteilung = AL.Abteilung and Gehalt > 20 Query: select name, salary L2 where boss = 'Klemens' Wird zu: select Mitarbeiter, Gehalt from MAG, AL where Leiter = 'Klemens' and MGA.Abteilung = AL.Abteilung and Gehalt > 20 Datenbankeinsatz: Sichten und Zugriffskontrolle 33 Probleme bei Aggregierungssichten (1) create view DS (Abteilung, GehaltsSumme) as select Abteilung, sum(gehalt) group by Abteilung Anfrage: Abteilungen mit hohen Gehaltsausgaben. select Abteilung from DS where GehaltsSumme > 500 Nach syntaktischer Transformation: select Abteilung Datenbankeinsatz: Sichten und Zugriffskontrolle 34 Probleme bei Aggregierungssichten (2) Nach syntaktischer Transformation: select Abteilung where sum(gehalt) > 500 group by Abteilung Keine syntaktische korrekte SQL-Anfrage. Korrekt wäre: select Abteilung group by Abteilung having sum(gehalt) > 500 Probleme bei Aggregierungssichten (3) select avg (GehaltsSumme) from DS Anfrage müßte wie folgt transformiert werden: select avg(sum (Gehalt)) group by Abteilung Aber geschachtelte Aggregatfunktionen sind in SQL nicht erlaubt. z Datenbankeinsatz: Sichten und Zugriffskontrolle 35 Datenbankeinsatz: Sichten und Zugriffskontrolle 36

vergabe in Datenbanksystemen vergabe in Datenbanksystemen Sichten insbesondere nützlich in Kombination Zugriffsrechten. Bestimmte Nutzer haben nur bestimmte jeweilige Sicht auf den Datenbestand. Ansonsten: Benutzer könnte an den Sichten vorbei auf den Datenbestand zugreifen. Thema im Folgenden: Zugriffsrechte. Zugriffsrechte Aufbau in hier betrachteter Modellierung: (AutorisierungsID, DB-Ausschnitt, Operation) AutorisierungsID ist interne Kennung eines Datenbankbenutzers. Datenbank-Ausschnitte: Relationen und Sichten. DB-Operationen: Lesen, Einfügen, Ändern, Löschen. Datenbankeinsatz: Sichten und Zugriffskontrolle 37 Datenbankeinsatz: Sichten und Zugriffskontrolle 38 Benutzer: db_1 Benutzer: vldke 1 3 4 2 5 7 6 9 8 10 11 Datenbankeinsatz: Sichten und Zugriffskontrolle 39 Datenbankeinsatz: Sichten und Zugriffskontrolle 40

vergabe in SQL (1) grant <> on <Tabelle> to <BenutzerListe> [with grant option] vergabe in SQL (2) Erläuterungen: In <>-Liste: all bzw. Langform all privileges oder Liste aus select, insert, update, delete. Recht für insert beinhaltet nicht select. Hinter on: Relationen- oder Sichtname. Hinter to: Autorisierungsidentifikatoren, auch public, group. Spezielles Recht: Recht auf die Weitergabe von n (with grant option). Datenbankeinsatz: Sichten und Zugriffskontrolle 41 Datenbankeinsatz: Sichten und Zugriffskontrolle 42 Autorisierung für public create view MeineAufträge as select * from AUFTRAG where KName = user; grant select, insert on MeineAufträge to public; Jeder Benutzer kann seine Aufträge sehen und neue Aufträge einfügen, aber nicht löschen. Zurücknahme von n revoke <> on <Tabelle> from <BenutzerListe> [restrict cascade] restrict: Falls Recht bereits an Dritte weitergegeben: Abbruch von revoke. cascade: Rücknahme des Rechts mittels revoke an alle Benutzer propagiert, die es von diesem Benutzer mit grant erhalten haben. Datenbankeinsatz: Sichten und Zugriffskontrolle 43 Datenbankeinsatz: Sichten und Zugriffskontrolle 44

Statistische Datenbanken Statistische Datenbanken: Beispiel (1) Einzeleinträge unterliegen Datenschutz, statistische Informationen (aggregierte Werte), Zugriffsüberwachung muß Zugriff auf Daten über Einzeleinträge verhindern, Beispiel: Benutzer X darf Daten über Kontoinhaber sowie statistische Daten wie Kontosummen sehen. Zugrundeliegende Relation: Konto(Name, Ort, Kontostand) Teilnehmer darf nicht auf Attribut Kontostand zugreifen. Anfragen/Sichten mit Aggregatfunktionen sind ihm aber gestattet. Datenbankeinsatz: Sichten und Zugriffskontrolle 45 Datenbankeinsatz: Sichten und Zugriffskontrolle 46 Statistische Datenbanken: Beispiel (2) Statistische Datenbanken: Beispiel (3) select count() from Konto where Ort = 'Teterow' Nur ein Treffer dann Kontoinhaber bestimmen: select Name from Konto where Ort = 'Teterow' Erlaubte Anfrage liefert Einzelergebnis: select sum(kontostand) from Konto where Ort = 'Teterow' Regel deshalb: In Aggregation müssen mindestens n Tupel eingehen. Gleiche Annahmen wie eben, außerdem Aggregation nur über mindestens n Tupel. Person X ist selbst Kontoinhaber, will Kontostand von Y herausfinden. X weiß, daß Y nicht in Magdeburg lebt, hat abgefragt, daß in Magdeburg mehr als n Kontoinhaber leben, daher erlaubt: select sum(kontostand) from Konto where Name = :X or Ort = 'Magdeburg' select sum(kontostand) from Konto where Name = :Y or Ort = 'Magdeburg' Datenbankeinsatz: Sichten und Zugriffskontrolle 47 Datenbankeinsatz: Sichten und Zugriffskontrolle 48

Sichten und 3-Ebenen Architektur Warum erlaubt man überhaupt auf Sichten? Externes Schema 1... Externes Schema n Anfragebearbeitung Konzeptuelles Schema Internes Schema Datenvisualisierung Datenbankeinsatz: Sichten und Zugriffskontrolle 49 Datenbankeinsatz: Sichten und Zugriffskontrolle 50 Mögliche Prüfungsfragen, beispielhaft Vor- und Nachteile von Sichten? Welche Anforderungen sollten/müssen bei auf Sichten erfüllt sein? Geben Sie Beispiele für Erfüllung/Nicht-Erfüllung dieser Anforderungen. <Die diversen von Sicht-Änderungsmöglichkeiten in SQL-92 erklären können.> Warum sind Aggregationsfunktionen problematisch hinsichtlich Zugriffsüberwachung? Datenbankeinsatz: Sichten und Zugriffskontrolle 51