Sichten

13. Sichten und Zugriffskontrolle
■
Sichtenkonzept
■
Änderungen auf Sichten
■
Rechtevergabe in Datenbanksystemen
■
Autorisierung und Authentifikation
■
Statistische Datenbanken
Sichten
Sichten: virtuelle Relationen (bzw virtuelle Datenbankobjekte
in anderen Datenmodellen) (englisch view)
■
Sichten sind externe DB-Schemata folgend der
3-Ebenen-Schemaarchitektur
■
Sichtdefinition
◆ Relationenschema (implizit oder explizit)
◆ Berechnungsvorschrift für virtuelle Relation, etwa
SQL-Anfrage
VL Datenbanken I – 13–1
Sichten II
■
■
VL Datenbanken I – 13–2
Drei-Ebenen-Schema-Architektur
Vorteile
◆ Vereinfachung von Anfragen
◆ Strukturierung der Datenbank
◆ logische Datenunabhängigkeit (Sichten stabil bei
Änderungen der Datenbankstruktur)
◆ Beschränkung von Zugriffen (Datenschutz)
externes Schema 1
...
externes Schema N
konzeptuelles Schema
Probleme
◆ automatische Anfragetransformation
◆
Durchführung von Änderungen auf Sichten
internes Schema
VL Datenbanken I – 13–3
VL Datenbanken I – 13–4
Definition von Sichten in SQL
Definition einer Sicht
Angegeben werden muß
■
Relationenschema (explizit, implizit aus Ergebnistyp der
Anfrage)
■
Berechnungsvorschrift (Anfrage) für virtuelle Relation
create view SichtName [ SchemaDeklaration ]
as SQLAnfrage
[ with check option ]
VL Datenbanken I – 13–5
Einsatz von Sichten am Beispiel
Vorteile von Sichten
■
Vereinfachung von Anfragen
■
Strukturierung der Datenbankbeschreibung
■
logische Datenunabhängigkeit:
Stabilität der Anwenderschnittstelle
■
Datensicherheit / Datenschutz
VL Datenbanken I – 13–6
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
VL Datenbanken I – 13–7
VL Datenbanken I – 13–8
Problembereiche bei Sichten
■
automatische Anfragetransformation
■
Durchführung von Änderungen auf Sichten
Kriterien für Änderungen 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
Änderungen der Sicht nicht betroffen werden
VL Datenbanken I – 13–9
Beispielszenario im Relationenmodell
MGA(Mitarbeiter, Gehalt, Abteilung)
AL(Abteilung, Leiter)
■
■
MGA speichert Daten über Zugehörigkeit von
Mitarbeitern zu Abteilungen und deren jeweiliges Gehalt
AL gibt für jede Abteilung den Abteilungsleiter an
VL Datenbanken I – 13–10
Projektionssicht
MA := πMitarbeiter,Abteilung (MGA)
In SQL mit create view-Anweisung:
create view MA as
select Mitarbeiter, Abteilung from MGA
Ä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’)
→ Problem der Konsistenzerhaltung falls Gehalt als not
null deklariert!
VL Datenbanken I – 13–11
VL Datenbanken I – 13–12
Kontrolle der Tupelmigration
Selektionssichten
create view MG as
select Mitarbeiter, Gehalt
from MGA
where Gehalt > 20
with check option
MG := σGehalt>20 (πMitarbeiter,Gehalt (MGA))
create view MG as
select Mitarbeiter, Gehalt
from MGA
where Gehalt > 20
Tupelmigration: Ein Tupel MGA(0 Zuse0 , 25,0 Info0 ), wird aus
der Sicht „‘herausbewegt“’:
update MG set Gehalt = 15
where Mitarbeiter = ’Zuse’
VL Datenbanken I – 13–13
VL Datenbanken I – 13–14
Verbundsichten (II)
Verbundsichten
Änderung wird transformiert zu
MGAL := MGA ./ AL
In SQL:
insert into MGA values (’Turing’, 30, ’Info’)
plus
create view MGAL as
select Mitarbeiter, Gehalt,
MGA.Abteilung, Leiter
from MGA, AL
where MGA.Abteilung = AL.Abteilung
1. Einfügeanweisung auf AL:
insert into AL values (’Info’,’Zuse’)
2. oder alternativ:
Änderungsoperationen in der Regel nicht eindeutig
übersetzbar:
update AL set Abteilung = ’Info’
where Leiter = ’Zuse’
■
insert into MGAL
values (’Turing’, 30, ’Info’, ’Zuse’)
■
VL Datenbanken I – 13–15
besser bzgl. Minimalitätsforderung
widerspricht aber Effektkonformität!
VL Datenbanken I – 13–16
Aggregierungssichten
Klassifikation der Problembereiche
create view AS (Abteilung, SummeGehalt)
as
select Abteilung, sum(Gehalt)
from MGA
group by Abteilung
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
Folgende Änderung ist nicht eindeutig umsetzbar:
4. Aggregierungssichten (u.a.): keine sinnvolle
Transformation möglich
update AS
set SummeGehalt = SummeGehalt + 1000
where Abteilung = ’Info’
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)
VL Datenbanken I – 13–17
Behandlung von Sichten in SQL
VL Datenbanken I – 13–18
Einschränkungen für Sichtänderungen
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)
VL Datenbanken I – 13–19
■
änderbar nur Selektions- und Projektionssichten
(Verbund und Mengenoperationen nicht erlaubt)
■
1:1-Zuordnung von Sichttupeln zu Basistupeln: kein
distinct in Projektionssichten
■
Arithmetik und Aggregatfunktionen im select-Teil sind
verboten
■
genau eine Referenz auf einen Relationsnamen im
from-Teil erlaubt (auch kein Selbstverbund)
■
keine Unteranfragen mit “Selbstbezug” im where-Teil
erlaubt (Relationsname im obersten SFW-Block nicht in
from-Teilen von Unteranfragen verwenden)
■
group by und having verboten
VL Datenbanken I – 13–20
Auswertung von Anfragen an Sichten
■
select: Sichtattribute evtl. umbenennen bzw. durch
Berechnungsterm ersetzen
■
from: Namen der Originalrelationen
■
konjunktive Verknüpfung der where-Klauseln von
Sichtdefinition und Anfrage (evtl. Umbenennungen)
Probleme bei Aggregierungssichten
create view DS (Abteilung, GehaltsSumme) as
select Abteilung, sum(Gehalt)
from MGA
group by Abteilung
Anfrage: Abteilungen mit hohen Gehaltsausgaben
select Abteilung
from DS
where GehaltsSumme > 500
VL Datenbanken I – 13–21
Probleme bei Aggregierungssichten (II)
Nach syntaktischer Transformation:
select Abteilung
from MGA
where sum(Gehalt) > 500
group by Abteilung
VL Datenbanken I – 13–22
Probleme bei Aggregierungssichten (III)
select avg (GehaltsSumme)
from DS
Anfrage müßte wie folgt transformiert werden:
Keine syntaktische korrekte SQL-Anfrage! Korrekt wäre:
select Abteilung
from MGA
group by Abteilung
having sum(Gehalt) > 500
VL Datenbanken I – 13–23
select avg(sum (Gehalt))
from MGA
group by Abteilung
Aber: Geschachtelte Aggregatfunktionen sind in SQL nicht
erlaubt!
VL Datenbanken I – 13–24
Rechtevergabe in Datenbanksystemen
■
Zugriffsrechte
(AutorisierungsID, DB-Ausschnitt,
Operation)
■
AutorisierungsID ist interne Kennung eines
„‘Datenbankbenutzers“’
■
Datenbank-Ausschnitte: Relationen und Sichten
■
DB-Operationen: Lesens, Einfügen, Ändern, Löschen
Rechtevergabe in SQL
grant <Rechte>
on <Tabelle>
to <BenutzerListe>
[with grant option]
VL Datenbanken I – 13–25
Rechtevergabe in SQL (II)
VL Datenbanken I – 13–26
Autorisierung für public
Erläuterungen:
■
In <Rechte>-Liste: all bzw. Langform all privileges
oder Liste aus select, insert, update, delete
■
Hinter on: Relationen- oder Sichtname
■
Hinter to: Autorisierungsidentifikatoren (auch public,
group)
■
spezielles Recht: Recht auf die Weitergabe von Rechten
(with grant option)
VL Datenbanken I – 13–27
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!).“
VL Datenbanken I – 13–28
Authentifikation und Autorisierung
Zurücknahme von Rechten
Nachweis der Identität von Benutzern:
revoke <Rechte>
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
■
Was der Benutzer weiß: Paßwörter, PINs, Geburtsdatum
der Mutter, . . .
■
Was der Benutzer besitzt: etwa Scheckkarte oder
Schlüssel
■
Was der Benutzer selbst hat: Fingerabdrücke, Stimme,
...
VL Datenbanken I – 13–29
VL Datenbanken I – 13–30
Statistische Datenbanken: Beispiel
Statistische Datenbanken
■
Einzeleinträge unterliegen Datenschutz, statistische
Informationen (aggregierte Werte)
■
Zugriffsüberwachung muß Zugriff auf Daten über
Einzeleinträge verhindern!
■
Bsp.: Benutzer X darf Daten über Kontoinhaber sowie
statistische Daten wie Kontosummen sehen
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: in Aggregation müssen mindestens n Tupel eingehen
VL Datenbanken I – 13–31
VL Datenbanken I – 13–32
Statistische Datenbanken (II)
■
Statistische Datenbanken (III)
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’
VL Datenbanken I – 13–33
Statistische Anfragen sollten nicht erlaubt werden, die
paarweise einen Durchschnitt von mehr als m vorgegebenen
Tupeln betreffen
■
Ergebnisgröße n
■
Größe der Überlappung der Ergebnismengen m
■
Sind nur Ergebnisse von Aggregatfunktionen erlaubt,
dann benötigt eine Person 1 + (n − 2)/m Anfragen, um
einen einzelnen Attributwert zu ermitteln
VL Datenbanken I – 13–34