VL 1.5 Sichten und Zugriffskontrolle

Question 1

Vor- und Nachteile von Sichten?

Answer 1

Vorteile:

• • Vereinfachung von Anfragen,
• • Strukturierung der Datenbank,
• • Konzepte werden benamt; logische
• +Datenunabhängigkeit (Sichten stabil bei Änderungen der Datenbankstruktur),
• • Beschränkung von Zugriffen,
• • Datenschutz.

Probleme:

• • Automatische Anfragetransformation, - Durchführung von Änderungen auf Sichten.

Question 2

Wofür sind Sichten geeignet?

Answer 2

Sichten sind Mittel der Wahl, wenn es darum geht für bestimmte Benutzergruppen den Zugriff auf den Datenbestand einzuschränken

Question 3

Was muss bei einer Anfrage auf eine Sicht datenbankintern passieren?

Answer 3

Anfrage die sich auf eine Sicht bezieht muss übersetzt werden in eine Anfrage, die sich auf den tatsächlichen Datenstand bezieht.

Question 4

Wo stößt man bei Sichten auf Grenzen?

Answer 4

Dem Benutzer wird mit der Sicht “vorgegaukelt” , dass er auf dem tatsächlichen Datenbestand arbeitet und auch Änderungen durchführen kann.

⇒ nicht alle Änderungen sind über Sichten möglich! + Automatische Anfragetransformation

Question 5

Was passiert mit doppelten/redundanten Werten bei Projektion?

Answer 5

Projektion Operator der rel. Alg. eliminiert Duplikate

–> korrekt in SQL Select DISTINCT

Question 6

Was ist der Unterschied zwischen Projektionssicht und Selektionssicht?

Answer 6

Sichten sind nichts anderes als Anfragen. Daher können wir mit Operatoren der relationalen Algebra Sichten definieren Bei Verwendung des:

• Projektionsopetaror –> Projektionssicht
• Selektionsoperator –> Selektionssicht zur

Definition der Sicht (Wohlgemerkt bei rAlgebra, derjenige Operator, der ganz links steht, also “außen”)

Question 7

Welche Anforderungen sollten/müssen bei Änderungen auf Sichten erfüllt sein? Geben Sie Beispiele für Erfüllung/Nicht-Erfüllung dieser Anforderungen.

Answer 7

Kriterien für Änderungen auf Sichten

Effektkonformität: Es soll nur durch die Änderung das geändert werden was intendiert war (geplant) und keine Seiteneffekte auftreten (wie neuer Abteilungsleiter von Buchman)

Minimalität: Basisdatenbank sollte nur minimal geändert werden, um den erwähnten Effekt zu erhalten.

• –> keine Annahmen machen (Bsp. irgendein Gehalt einfügen)

Konsistenzerhaltung: Änderung einer Sicht darf zu keinen Integritätsverletzungen der Basisdatenbank führen.

• Bsp Gehalt keine NULL-Werte erlaubt

Respektierung des Datenschutzes: bewusst ausgeblendete Teil darf von Änderungen der Sicht nicht betroffen werden.

• Lösung: Möglichkeit “with check option”

Question 8

Illustrieren Sie, dass diese Anforderungen im Gegensatz zueinander stehen.

Answer 8

daad

Question 9

Mitarbeiter führt Änderung auf Sicht durch! Was könnte hier das Problem der Änderung sein?

Answer 9

Nur problemlos, wenn für Gehalt NULL-Werte zulässig sind!

⇒ Ansonsten Verstoß gegen Konsistenzbedingung!

Siehe –> Kriterien für Änderung Konsistenzerhaltung: Änderung einer Sicht darf zu keinen Integritätsverletzungen der Basisdatenbank führen.

Lösung(vermeindlich):

• (1) Einfügung zurückweisen oder
• (2) irgendeinen Wert einfügen

Problem: (

• (1) Einfüger weiß nicht, warum er Zurückweisung erhält
• (2) keine Annahmen machen
  
  • ⇒irgendeinen Wert zu nehmen beinhaltet eine Annahmen zu machen!

Punkt (2) widerspricht der Minimalität (Kriterien für Änderungen)

+ 2. Problem der Minimalität siehe Bild

Minimalität: Basisdatenbank sollte nur minimal geändert werden, um den erwähnten Effekt zu erhalten.

Question 10

Was ist das Problem der Änderung?

Answer 10

⇒ der zugreifende Mitarbeiter (Zugriff auf Sicht) sollte nur MA´s mit Gehalt > 20 sehen können

• Darf er jetzt nun das Gehalt auf 15 ändern, weiß er nun dass Zuse ein Gehalt kleiner 20 hat != Datenschutz Kriterium verletzt –>

siehe Kriterium Respektierung des Datenschutzes:

Wird die Sicht aus Datenschutzgründen eingeführt, darf der bewusst ausgeblendete Teil der Basisdatenbank von Änderungen der Sicht nicht betroffen werden.

Lösung:

• With Check Option

Bsp siehe Bild!

Question 11

Was könnte hier das Problem beim Einfügen sein?

Was könnten hier die Seiteneffekte sein?

Welcher Anforderung für Änderungen widerspricht das?

Welchen Spezialfall gibt es?

Answer 11

Wir müssten beide zugrundeliegenden Relationen updaten also MGA und AL(Abteilungsleiter)

⇒Möglicherweise gibt es schon einen Leiter der Info-Abteilung, der nicht “Zuse” heißt.

Was nun?

1. Komplett neu einfügen
2. oder update

Gemäß Minimalitätsbedingung wäre ein Update besser als einen doppelt einzufügen?!

⇒ D.h. dieser würde mit “Zuse” überschrieben!

⇒ Plötzlich hat Buchman neuen Abteilungsleiter, das war nicht gewollt

⇒Effektkonformität: Es soll nur durch die Änderung das geändert werden was intendiert war (geplant) und keine Seiteneffekte auftreten (wie neuer Abteilungsleiter von Buchman)

Take Away: Es gibt keine Möglichkeiten Insert-Statements in Sichten Seiten Seiteneffektfrei abzubilden

Spezialfall –> einfügen in 2 leere Relationen (Spezialfall Verbundsicht)

Bild!

Question 12

Was ist hier das Problem? Aggregierungssicht

Answer 12

Wie werden die 1000 in der ursprungsrelation verteilt?

• Gleichmäßig auf alle MA verteieln?
• Der Abteilungsleiter bekommt alles?

Keine Lösung

Grund: Minimalität ⇒ keine Annahmen machen!

Question 13

Was ist bei dieser transformation der Anfrage auf die Aggregierungssicht verkehrt?

Answer 13

Die Gruppierung der Abteilungen muss vor der Summenberechnung geschehen!

Deshalb mit Having gelöst!

Gruppierung ⇒ dann Having mit Bedingung

Denn Bedingungen die sich auf Gruppen als ganzes Beziehen müssen in der Having Klausel erscheinen

Question 14

Was ist hier das Problem der Transformation?

Answer 14

Geschachtelte Aggregatfunktionen sind in SQL nicht erlaubt.

denn Hier nicht klar:

• Bezieht sich die Gruppierung schon auf den Druchschnitt
• oder auf die Summe?

Question 15

Warum sind Insert Statements problematisch?

Welchen Spezialfall gibt es?

Answer 15

Take away: Insert Statements in Sichten sind nicht Seiteneffektfrei durchzuführen!

⇒ Daher Inserts in Verbundsicht generell verboten! Bsp. ohne Seiteneffekt

–> einfügen in 2 leere Relationen (Spezialfall Verbundsicht)

Question 16

Welche Einschränkung von Sichtenänderung in SQL (92) gibt es?

Answer 16

Standard SQL-92: -

• Integritätsverletzende Sichtänderungen nicht erlaubt,
• datenschutzverletzende Sichtänderungen:
  
  • ⇒Benutzerkontrolle (with check option),
• Nicht erlaubt: Sichten mit nicht-eindeutiger Transformation:
  
  • d.h. unklar ob durch Überschreiben oder neues Tupel einfügen

Question 17

1. Was kann bei Mengenoperationenin Sichtdefinition ‚anbrennen‘?
2. kein distinct in Projektionssichten?
3. Arithmetik und Aggregatfunktionen im select-Teil sind verboten. Warum
4. Warum ist Selbsverbund problematisch?
5. Group By / Having verboten warum?
6. Keine Unteranfragen mit „Selbstbezug“ (geschachtelte Anfragen)

Answer 17

1. Lösche Tupel aus Schnittmengesicht
   
   1. Wie wird das umgesetzt?
      
      1. Aus 1 Menge löschen
      2. Aus 2 Menge löschen
      3. Aus beiden
      4. ⇒ Keine Eindeutigkeit, nicht erlaubt!
2. Duplikate werden durch Projektion eliminiert
3. Siehe Bsp. Summe+1000. Wie die 1000 verteilen?
   
   1. keine Eindeutigkeit
4. Gleicher Grund wie allgemein Verbund
   
   1. ⇒Seiteneffekte
5. Kommt meistens mit Aggregatfunktionen daher (sum() etc.)
   
   1. siehe Punkt 3
6. ​​​lassen sich auf Verbundsichten abbilden
   
   1. siehe Verbunds. Seiteneffekte

Question 18

Welche 2 Motivationen gibt es bei dem Kriterium Minimalität?

Answer 18

1. Das leichtgewichtigere nehmen
   
   1. –> z.b Update anstatt Einfügen
2. keine Annahmen machen

Question 19

Wie wird eine Anfrage auf eine Sicht übersetzt auf eine Anfrage auf die zugrundeliegenden Relationen (Schritte) ?

Answer 19

1. Attributbezeichner zu basis Attributbez.
2. Sichtbezeichnung muss ersetzt werden durch basis Relationen
   
   • Zb. Join wieder abbilden
3. Bedingungen, die für die Sicht gelten müssen verwendet werden (Sum(Gehalt), WHERE Gehalt > 20 etc)

Question 20

Wie kann man Zugriffsrechte für Nutzer vergeben?

Answer 20

Durch die Nutzung von Sichten. Idee: Sicht definieren, die genau beinhalten was bestimmmte Nutzergruppen sehen dürfen und mit den Sichten Zugriffsechte in Verbindung setzten.

Wir haben:

• (1)Nutzer auf die sich das Zugriffsrecht bezieht
• (2)Information, auf welchen Ausschnitt der Datenbank das Zugriffsrecht gilt
• (3)Art des Zugriffs // Lesen, Einfügen, Ändern, Löschen

[with grant option] // Befugniss Rechte weiterzugeben

**Recht für insert beinhaltet nicht select.

**Hinter on: Relationen- oder Sichtname.

**Hinter to: Autorisierungsidentifikatoren, auch public, group. Funktioniert größtenteils super ABER:

Question 21

Erteile Lesezugriff an einen Nutzer db_2 auf DB-Ausschnitt vldke.kbbuecher! und anschließend wieder entziehen!

Answer 21

SQL Syntax grant on to [with grant option]

• grand select on vldke.kbbuecher to db_2
• revoke select on vldke.kbbuecher from db_2

Question 22

Was kommt als Anfrage auf eine Sicht, für die man keine Zugriffsrechte hat zurück und warum?

Answer 22

“Tabelle oder View nicht vorhanden” –>

Es ist egal, ob die Sicht existiert und derjenige keine Zugangsrechte für die Sicht hat oder die Sicht gar nicht exisitert

–> Dem Anfragenden wird obiges angezeigt, denn er soll nicht wissen, ob die Sicht überhaupt existiert.

Allein das Wissen darüber soll nicht gestattet sein (z.B. Existens Sicht “SchwarzeKasse”?!) Siehe ausführliche Beispiel aus älteren VL + Mitschnitt gut erklärt

Question 23

(1) Was bedeutet das restrict im folgenden Bsp:
* revoke select on kbbuecher from db_1 restrict
(2) Was passiert wenn man den Befehl ohne “restrict” ausführt

Answer 23

(1)Das Zugriffsrecht wird db_1 wieder entzogen, SOFERN es nicht schon weiter gegeben wurde!

Also: hat db_1 schon eine weitere Zugriffsrechte verteilt mit “grant … to “ Erscheint ein Fehler Idee: Es kann sein dass schon koplexe Abhängigkeiten aufgebaut wurden und diese Abhängigkeiten sollen nicht “kaputt” gemacht werden

(2) Allen Benutzern werden die Zugriffsrechte entzogen, also auch denjenigen, die vom ursprünglichen Rechteempfänger Rechte per “Delegation” erhalten haben!

Question 24

Kann man auch Nutzern Zugriffsrechte von Rollen zuweisen?

Answer 24

Bild!

Question 25

Wie kann man gewährleisten, dass ein Nutzer nur auf seine eigenen Daten zugreifen kann? Beispiel?!

Answer 25

Bild

„Jeder Benutzer kann seine Aufträge sehen und neue Aufträge einfügen, aber nicht löschen.“ Es handelt sich wirklich um seine Aufträge, nicht die des Benutzers, der die View generiert und Rechte vergeben hat.

Question 26

Weitergabe von Rechten

K erteilt G und S ein Recht. G und S geben Recht unabhängig voneinander an C weiter. Was passiert, wenn G C später das Recht wieder entzieht?

Answer 26

C hat Recht noch, von S.

Question 27

Wie funktioniert die Zurücknahme von Rechten von Nutzern?

Answer 27

Zurücknahme von Rechten revoke on from [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.

Question 28

Was ist das Inferenzproblem?

Answer 28

Inferenzproblem. ⇒ Autorisierung ist mit Problemen verbunden

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.

Vorgehen:

• Ort mit nur einem Kontoinhaber ausfindig machen
• falls gefunden
  
  • Namen der Person rausfinden
  • Kontosumme des Ortes rausfinden

Question 29

Warum sind Aggregationsfunktionen problematisch hinsichtlich Zugriffsüberwachung?
Beispiele geben können.

Answer 29

da