Sichten

12. Sichten und Zugriffskontrolle
■
Sichtenkonzept
■
Änderungen auf Sichten
■
Rechtevergabe in Datenbanksystemen
■
Autorisierung und Authentifikation
■
Statistische Datenbanken
VL Datenbanken I – 12–1
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 – 12–2
Sichten II
■
Vorteile
◆ Vereinfachung von Anfragen
◆ Strukturierung der Datenbank
◆ logische Datenunabhängigkeit (Sichten stabil bei
Änderungen der Datenbankstruktur)
◆ Beschränkung von Zugriffen (Datenschutz)
■
Probleme
◆ automatische Anfragetransformation
◆
Durchführung von Änderungen auf Sichten
VL Datenbanken I – 12–3
Drei-Ebenen-Schema-Architektur
externes Schema 1
...
externes Schema N
konzeptuelles Schema
internes Schema
VL Datenbanken I – 12–4
Definition einer Sicht
Angegeben werden muß
■
Relationenschema (explizit, implizit aus Ergebnistyp der
Anfrage)
■
Berechnungsvorschrift (Anfrage) für virtuelle Relation
VL Datenbanken I – 12–5
Definition von Sichten in SQL
create view SichtName [ SchemaDeklaration ]
as SQLAnfrage
[ with check option ]
VL Datenbanken I – 12–6
Vorteile von Sichten
■
Vereinfachung von Anfragen
■
Strukturierung der Datenbankbeschreibung
■
logische Datenunabhängigkeit:
Stabilität der Anwenderschnittstelle
■
Datensicherheit / Datenschutz
VL Datenbanken I – 12–7
Einsatz von Sichten am Beispiel
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 – 12–8
Problembereiche bei Sichten
■
automatische Anfragetransformation
■
Durchführung von Änderungen auf Sichten
VL Datenbanken I – 12–9
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 – 12–10
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 – 12–11
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 – 12–12
Selektionssichten
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 – 12–13
Kontrolle der Tupelmigration
create view MG as
select Mitarbeiter, Gehalt
from MGA
where Gehalt > 20
with check option
VL Datenbanken I – 12–14
Verbundsichten
MGAL := MGA ./ AL
In SQL:
create view MGAL as
select Mitarbeiter, Gehalt,
MGA.Abteilung, Leiter
from MGA, AL
where MGA.Abteilung = AL.Abteilung
Änderungsoperationen in der Regel nicht eindeutig
übersetzbar:
insert into MGAL
values (’Turing’, 30, ’Info’, ’Zuse’)
VL Datenbanken I – 12–15
Verbundsichten (II)
Ä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 bzgl. Minimalitätsforderung
■ widerspricht aber Effektkonformität!
■
VL Datenbanken I – 12–16
Aggregierungssichten
create view AS (Abteilung, SummeGehalt)
as
select Abteilung, sum(Gehalt)
from MGA
group by Abteilung
Folgende Änderung ist nicht eindeutig umsetzbar:
update AS
set SummeGehalt = SummeGehalt + 1000
where Abteilung = ’Info’
VL Datenbanken I – 12–17
Klassifikation der Problembereiche
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
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)
VL Datenbanken I – 12–18
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)
VL Datenbanken I – 12–19
Einschränkungen für Sichtänderungen
■
ä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 – 12–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)
VL Datenbanken I – 12–21
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 – 12–22
Probleme bei Aggregierungssichten (II)
Nach syntaktischer Transformation:
select Abteilung
from MGA
where sum(Gehalt) > 500
group by Abteilung
Keine syntaktische korrekte SQL-Anfrage! Korrekt wäre:
select Abteilung
from MGA
group by Abteilung
having sum(Gehalt) > 500
VL Datenbanken I – 12–23
Probleme bei Aggregierungssichten (III)
select avg (GehaltsSumme)
from DS
Anfrage müßte wie folgt transformiert werden:
select avg(sum (Gehalt))
from MGA
group by Abteilung
Aber: Geschachtelte Aggregatfunktionen sind in SQL nicht
erlaubt!
VL Datenbanken I – 12–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
VL Datenbanken I – 12–25
Rechtevergabe in SQL
grant <Rechte>
on <Tabelle>
to <BenutzerListe>
[with grant option]
VL Datenbanken I – 12–26
Rechtevergabe in SQL (II)
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 – 12–27
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!).“
VL Datenbanken I – 12–28
Zurücknahme von Rechten
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
VL Datenbanken I – 12–29
Authentifikation und Autorisierung
Nachweis der Identität von Benutzern:
■
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 – 12–30
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
VL Datenbanken I – 12–31
Statistische Datenbanken: Beispiel
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 – 12–32
Statistische Datenbanken (II)
■
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 – 12–33
Statistische Datenbanken (III)
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 – 12–34