20.1.1 Referentielle
Integrität
20.2 Erweiterter
Autorisierungsmechanismus
20.2.1 Gruppen-
und Prozedur-Zugriffsrechte
20.2.2 Die
erweiterte GRANT-Anweisung und die REVOKE-Anweisung
In
diesem Kapitel wird der Knowledge Management-Modul von
INGRES beschrieben. Zuerst wird
die Möglichkeit erörtert,
mit Hilfe des Knowledge
Management-Moduls benutzerdefinierte
Regel zu erstellen. Eine
der wichtigsten Anwendungen
der benutzerdefinierten
Regel ist die
Unterstützung
der referentiellen
Integrität, die definiert
und an
Beispielen erklärt wird.
Im zweiten Teile
des Kapitels
wird der erweiterte
Autorisierungsmechanismus, den Knowledge
Management auch unterstützt, erklärt. In diesem Zusammenhang
werden Gruppen- und
Anwendungs-Zugriffsrechte
dargestellt
und die in Bezug auf
erweiterte Zugriffsrechte stehenden
SQL-Anweisungen GRANT und REVOKE
erörtert.
Der Knowledge
Management-Modul ist neben
dem Object
Management-Modul das zweite
zusätzliche Produkt, das
ab
Version 6.3 von INGRES
unterstützt wird. Dieser optionale
Modul bietet zwei wichtige
funktionelle Erweiterungen an:
- die Erstellung von
benutzerdefinierten Regel und
- den erweiterten
Autorisierungsmechanismus.
Die benutzerdefinierten Regel werden in diesem Abschnitt
erörtert, während der
erweiterte
Autorisierungsmechnismus
das Thema des nächsten Abschnitts
sein wird.
Regel sind benutzerdefinierte Konstrukte, die im
Zusammenhang mit DB-Prozeduren benutzt werden
können, um
gewisse, vom Benutzer gewünschte
Tätigkeiten ausführen zu
können. Wenn bei der
Ausführung einer SQL-Anweisung die
Bedingung einer benutzerdefinierten Regel erfüllt ist, wird
die
im Zusammenhang mit der
Regel stehende DB-Prozedur
aufgerufen und ausgeführt.
Eine Regel kann in Bezug auf
- eine INSERT-, UPDATE- oder
DELETE-Anweisung;
- die Änderung eines
Datenwertes einer Tabellenspalte;
- eine Änderung, die eine spezifische, im
Zusammenhang
mit einer oder mehreren Spalten stehende
Bedingung
betrifft,
definiert werden.
Mit der Anweisung
CREATE RULE regel_name tab_bedingung
EXECUTE PROCEDURE proz_name
[(param_1=wert_1
[,param_2=wert_2,...])];
wird eine Regel definiert. regel_name ist
der Name der
benutzerdefinierten Regel während proz_name
der Name der bei
der
Erfüllung der Bedingung
aufgerufenen DB-Prozedur ist.
param_1, param_2,... sind die
Parameter der DB-Prozedur,
denen die Datenwerte wert_1, wert_2,...
in dieser
Reihenfolge zugewiesen werden.
tab_bedingung definiert die
Bedingung, die erfüllt sein muß,
um
die Regel zu aktivieren. Diese Bedingung hat folgende
Syntax
AFTER anw_1 [,anw_2,...]
ON|OF|FROM|INTO tab_name
[REFERENCING [OLD AS
alt_alias] [NEW AS neu_alias]]
[WHERE
bedingung]
anw_1,anw_2,...
stellen die SQL-Anweisungen dar, nach
derer
Ausführung die Regel regel_name
aktiviert wird. Nur folgende
SQL-Anweisungen können mit CREATE
RULE verwendet werden:
- INSERT,
- UPDATE [(spalte)] und
-
DELETE.
Jede dieser Anweisungen darf
nur einmal in
der
Anweisungsliste vorkommen.
Die UPDATE-Anwesiung ist
die
einzige, die die explizite
Angabe einer Spalte erlaubt.
(Falls keine Spalte in der
UPDATE-Anweisung angegeben ist,
wird die Regel nach
der Änderung jeder
Tabellenspalte
aktiviert.)
Die REFERENCING-Klausel
ermöglicht die Auswahl
von
Aliasnamen für einen Spaltennamen. Immer wenn wert_1,
wert_2,... Spaltennamen darstellen, müssen diese Datenwerte
mit Hilfe von Aliasnamen
gekennzeichnet werden. alt_alias
spezifiziert den
Aliasnamen für den
Datenwert vor der
Änderung während neu_alias den Aliasnamen für den Datenwert
nach der Änderung der Spalte
darstellt.
Falls die
REFERENCING-Klausel
ausgelassen wird, wird
standardmäßig
REFERRENCING OLD AS old NEW
AS new
angenommen.
bedingung kennzeichnet die Änderung der Tabelle tab_name,
die auftreten muß, um die Regel zu
aktivieren.
Eine Regel kann nur derjenige
Benutzer erstellen, der sowohl
die
in der Regel verwendete Tabelle besitzt als auch das
Recht zur Ausführung der
aufgrund der Regel aufgerufenen
DB-Prozedur hat. Jede
CREATE RULE-Anweisung verwendet eine
exklusive Sperre für die
angesprochene Tabelle.
Beispiel 20.1
CREATE RULE fuege_projekt AFTER INSERT INTO
projekt
EXECUTE PROCEDURE neu_projekt
(name=new.pr_name, nummer=new.pr_nr);
In
Beispiel 20.1 wird die Regel fuege_projekt definiert,
die
jedesmal aktiviert wird, wenn eine Reihe in der Tabelle
projekt eingefügt
wird. Die Aktivierung
dieser Regel
bedeutet, daß die DB-Prozedur neu_projekt aufgerufen
wird
und
den Parametern name und
nummer die Datenwerte
der
Spalten pr_name und pr_nr in dieser Reihenfolge zugewiesen
werden.
Beispiel 20.2
CREATE RULE mittel_grenze AFTER UPDATE(mittel)
REFERENCING OLD AS alt NEW AS neu
WHERE neu.mittel >
200000.00
EXECUTE PROCEDURE geld_limit
(name=alt.pr_name,
mittel=neu.mittel);
In Beispiel 20.2 wird die Regel mittel_grenze
erstellt, die
aktiviert wird, falls Mittel eines
existierenden Projektes
über 200.000DM erhöht werden.
Die REFERENCING-Klausel
definiert die Angabe alt
für die Kennzeichnung aller
Datenwerte vor der Änderung und die Angabe neu
für die
Kennzeichnung aller Datenwerte nach
der Änderung der Spalte.
Mit der Anweisung
DROP RULE regel_name
kann eine existierende Regel
gelöscht werden. Eine Regel
kann nur von ihrem
Eigentümer gelöscht werden. Alle Regeln,
die in Bezug zu einer
Tabelle stehen, werden
implizit
gelöscht, falls die Tabelle
mit der DROP TABLE-Anweisung
gelöscht wird.
Benutzerdefinierte Regel eignen
sich u.a. für die
Überprüfung der referentiellen Integrität einer Datenbank.
Die
referentielle Integrität beschreibt
eine besondere
Beziehung zwischen den Spalten
zweier Tabellen einer
Datenbank.
Eine Spaltengruppe der
Tabelle tab2 wird
Fremdschlüssel
genannt, falls alle ihre
Werte, die nicht
NULL-Werte
sind, identische Werte im Primärschlüssel einer anderen
Tabelle tab1 haben. Die
Tabelle tab1 wird
Zieltabelle
und die Tabelle tab2
die referenzierte Tabelle
genannt.
(Die Tabellen tab1
und tab2 können u.U. dieselbe Tabelle
darstellen.)
Die
referentielle Integrität
kennzeichnet die Eigenschaft,
daß jeder Datenwert (außer
dem NULL-Wert) eines
Fremdschlüssels den identischen Wert in dem entsprechenden
Primärschlüssel haben muß.
Diese Eigenschaft kann an den
Tabellen der
Beispieldatenbank gezeigt werden.
In der
Beispieldatenbank existieren
folgende Fremdschlüssel:
- Die Spalte abt_nr in
der Tabelle mitarbeiter. (Der
entsprechende Primärschlüssel ist die Spalte abt_nr
der Tabelle abteilung.)
- Die Spalte m_nr in
der Tabelle arbeiten. (Der
entsprechende Primärschlüssel ist die Spalte m_nr
in
der Tabelle mitarbeiter.)
- Die Spalte pr_nr in
der Tabelle arbeiten. (Der
entsprechende Primärschlüssel
ist die Spalte pr_nr in
der Tabelle projekt.)
Es
existieren insgesamt vier
Fälle, in denen das
Ändern
der Datenwerte im Fremdschlüssel bzw. in dem entsprechenden
Primärschlüssel die
Integrität einer Datenbank
verletzen kann. Alle diese Fälle
werden mit Hilfe
der
Beispieldatenbank gezeigt und
erklärt.
1) INSERT INTO arbeiten(m_nr,...)
VALUES (1111,...);
Mit
der INSERT-Anweisung wird
ein Wert in
der Spalte
m_nr der
Tabelle arbeiten eingefügt,
zu welchem dann
kein entsprechender Wert in
der Spalte m_nr der
Tabelle
mitarbeiter existiert.
2) UPDATE arbeiten
SET m_nr=11111
WHERE
......;
Mit
der UPDATE-Anweisung wird
ein existierender Wert
in
der
Spalte m_nr der
Tabelle arbeiten durch einen anderen
ersetzt, zu welchem dann kein entsprechender Wert
in der
Spalte m_nr der Tabelle mitarbeiter
existiert.
3) UPDATE mitarbeiter
SET m_nr=22222
WHERE m_nr=10102;
Mit der
UPDATE-Anweisung wird
jetzt der Wert
im
Primärschlüssel der Tabelle mitarbeiter durch einen
neuen
Wert ersetzt. Dadurch
entstehen überschüssige Werte in der
Spalte m_nr der Tabelle arbeiten.
4) DELETE FROM mitarbeiter
WHERE m_nr=10102;
Dieser Fall ist dem vorigen
ähnlich. Durch das Löschen der
Reihe in der Tabelle mitarbeiter entstehen
überschüssige
Werte in der Spalte m_nr der
Tabelle arbeiten.
Um die referentielle
Integrität in einem Datenbanksystem
zu
unterstützen, können verschiedene Ansätze gewählt
werden. Eine Möglichkeit ist, die Definition des Primär-
und
Fremdschlüssels explizit mit
Hilfe der CREATE
TABLE-Anwesiung zu
unterstützen. Die zweite
Möglichkeit
ist, dem Benutzer die
Mittel zu geben, die referentielle
Integrität selbst zu implementieren. Von den beiden
Alternativen ist die
erste aus zwei Gründen zu bevorzugen.
Erstens ist sie in
dem kommenden SQL-Standard (SQL2)
beschrieben und
dadurch für alle
Datenbanksysteme
einheitlich festgelegt. Zweitens muß der Benutzer in diesem
Fall nichts machen; die
Implementierung ist durch das System
gewährleistet.
INGRES unterstüzt mit den benutzerdefinierten Regel
des
Knowledge Management-Moduls die zweite
Möglichkeit. Es ist
zu
hoffen, daß eine der
nächsten INGRES-Versionen auch
die
Definition des Primär- und Fremdschlüssels und damit
die
explizite Unterstützung der
referentiellen Integrität
enthalten wird.
Genauso wie es verschiedene Ansätze für die
Lösung der
referentiellen Integrität
gibt, gibt es
verschiedene
Maßnahmen, um die referentielle Integrität einer
Datenbank beim Einfügen,
Löschen und Ändern
der Reihen
aufrechtzuerhalten.
Diese Maßnahmen können am besten
durch
folgende Begriffe definiert werden:
- Restriktion ("Restrict")
- Setze auf NULL
("Set NULL") und
- Kaskade ("Cascade") .
Die Restriktion erlaubt das
Löschen bzw. das
Ändern
nur solchen Reihen der
Zieltabelle, deren Werte
im
Primärschlüssel über
keine entsprechenden Werte
im
Fremdschlüssel der referenzierten Tabelle verfügen. Die
Implementierung dieser
Maßnahme mit Hilfe
von Regeln
bedeutet, daß die Anweisung, die die Regel aktiviert
hat,
zurückgesetzt werden muß,
falls die Integrität der Daten
verletzt ist. Diese Maßnahme kann
bei INGRES mit Hilfe der
RAISE ERROR-Anweisung erreicht
werden.
Die
Maßnahme Setze auf NULL erlaubt das
Löschen bzw. das
Ändern aller Reihen der Zieltabelle, wobei entsprechenden
Datenwerten der Spalten,
die den Fremdschlüssel in der
referenzierten Tabelle
bilden, der NULL-Wert
zugewiesen
wird.
Hinweis.
Die
Maßnahme Setze auf
NULL kann erweitert
werden in
dem
Sinne, daß alle
Datenwerte der Spalten,
die den
Fremdschlüssel in der
referenzierten Tabelle
bilden, ein
vordefinierter Datenwert zugewiesen
wird.
Die Kaskade kann sich
entweder auf das Einfügen der
Werte
im Fremdschlüssel oder auf
das Ändern bzw.
das Löschen
der
Werte im Primärschlüssel beziehen. Im ersten
Fall
werden für jeden neueingefügten Datenwert im Fremdschlüssel
eine zusätzliche Reihe
in der Zieltabelle, die diesen
Wert als Primärschlüssel hat,
eingefügt. Im zweiten Fall
werden für alle gelöschten bzw.
geänderten Datenwerte des
Primärschlüssels die Reihen der referenzierten Tabelle, die
diesen Datenwert als Fremdschlüssel
enthalten, gelöscht bzw.
geändert.
Beispiel 20.3
CREATE PROCEDURE loesche_mnr (nummer=INTEGER) AS
DECLARE
meldung=CHAR(80) NOT NULL;
BEGIN
meldung = 'Loeschen der Reihen mit der M_nr
"' +
:nummer + '"';
MESSAGE :meldung;
DELETE FROM arbeiten
WHERE m_nr=:nummer;
IF iirowcount > 0 THEN
Meldung='Insgesamt sind '
+ VARCHAR(iirowcount) +
+ ' Reihen
geloescht';
ELSE meldung='Keine Reihe
geloescht';
ENDIF
MESSAGE :meldung;
END;
CREATE RULE loesche_mitarb
AFTER
DELETE FROM mitarbeiter
EXECUTE PROCEDURE
loesche_mnr (nummer=old.m_nr);
In
Beispiel 20.3 ist eine Regel
erstellt worden, die die
referentielle Integrität zwischen den Tabellen mitarbeiter
und arbeiten in Form einer Kaskade aufrechterhält.
Jedesmal
wenn eine Reihe der Tabelle
mitarbeiter gelöscht wird,
wird die Regel loesche_mitarb aktiviert, die ihrerseits die
DB-Prozedur loesche_mnr
aufruft. Die DB-Prozedur loesche_mnr
löscht alle Reihen der
Tabelle arbeiten, die dieselbe
Mitarbeiternummer wie die gelöschte Reihe in der Tabelle
mitarbeiter haben. Mit der
lokalen Variablen meldung
wird
die Anzahl der gelöschten Reihen
der Tabelle arbeiten am
Bildschirm ausgegeben.
Der Knowledge
Management-Modul
unterstützt neben
der Erstellung von Regeln
auch einen erweiterten
Autorisierungsmechanismus, mit
dem Zugriffsrechte für
Datenbanken, ausgewählte
Benutzergruppen und Anwendungen
vergeben bzw. entzogen werden
können.
Die
in Kapitel 15 beschriebene GRANT-Anweisung ermöglicht
die Vergabe der
Tabellen-Zugriffsrechte entweder an einzelne
oder an alle Benutzer eines
INGRES-Systems. Dieser Weg
ist
aufwendig, wenn man einer großen
Benutzergruppe die
Zugriffsrechte vergeben wird. Mit
der Anweisung CREATE GROUP
ist
es möglich, einer im voraus erstellten Benutzergruppe
einen Namen zu geben. Dieser
Name kann anschließend in der
GRANT-Anweisung verwendet werden, um
auf eine einfache Weise
allen Benutzern dieser Gruppe
gewünschte Zugriffsrechte zu
vergeben.
Die Anweisung CREATE GROUP hat
folgende Form
CREATE GROUP gruppen_name
[WITH USERS=(ben_1
[,ben_2,...])];
gruppen_name kennzeichnet den Namen
der Benutzergruppe.
Die Information über
alle mit der CREATE GROUP-Anweisung
definierten Gruppennamen werden in der
Systemtabelle
iiusergroup abgelegt. ben_1, ben_2,... stellen
die Namen
der
Benutzer dar, die zu der mit gruppen_name definierten
Benutzergruppe gehören.
Falls die Angabe
WITH USERS
ausgelassen wird,
können Benutzer mit
Hilfe der ALTER
GROUP-Anweisung nachträglich
definiert werden.
Die CREATE GROUP-Anweisung kann
nur der
INGRES-Systemverwalter dann ausführen,
wenn er in
einer
Sitzung arbeitet, die mit der
INGRES-Master-Datenbank iidbdb
verbunden ist.
Beispiel 20.4
CREATE GROUP vertrieb
WITH USERS = (meier,mueller,berger,kunz);
In
Beispiel 20.4 wird eine Benutzergruppe namens vertrieb
definiert, zu der die Benutzer meier, mueller, berger
und
kunz gehören.
Mit der Anweisung
ALTER GROUP gruppen_name
ADD USERS (ben_1 [,ben_2,...])
| DROP USERS (ben_3
[,ben_4,...])
|
DROP ALL;
kann eine Benutzergruppe
modifiziert werden. gruppen_name
muß ein existierender Name
einer Benutzergruppe sein.
Mit der Angabe ADD USERS
können neue Benutzer
in die
Benutzergruppe aufgenommen werden.
Die DROP USERS-Angabe
dagegen löscht einen oder
mehrere Benutzer, die
einer
Benutzergruppe angehören. Die DROP
ALL-Angabe löscht alle
Benutzer einer Benutzergruppe.
Diese Angabe ist notwendig,
falls ein existierender Gruppenname
anschließend mit der
DROP GROUP-Anweisung gelöscht werden
soll.
In
einer ALTER GROUP-Anweisung
können nicht gleichzeitig
Benutzer gelöscht und
neue hinzugefügt werden.
Nur der
INGRES-Systemverwalter, der in einer mit iidbdb verbundenen
INGRES-Sitzung abeitet,
kann die Anweisung
ALTER GROUP
ausführen.
Mit der Anweisung
DROP GROUP gruppen_name1 [,gruppen_name2,...];
kann ein oder mehrere
Gruppennamen gelöscht werden.
Die
Voraussetzung für das Löschen
eines Gruppennamens ist, daß
die zugewiesene Benutzergruppe leer ist. (Das Löschen aller
Benutzer einer Benutzergruppe kann mit der Anweisung DROP
GROUP ausgeführt werden.)
Die
zweite Gruppe der
SQL-Anweisungen, die der Knowledge
Management-Modul unterstützt, regelt das Erstellen,
Modifizieren und
Löschen von Identifikatoren, die im
Zusammenhang mi den
Zugriffsrechten für INGRES-Anwendungen
stehen. Mit der Anweisung
CREATE ROLE identifikator
WITH NOPASSWORD | PASSWORD=kennwort;
kann ein Identifikator definiert
werden, der später, mit
Hilfe der erweiterten
GRANT-Anwesiung benutzt werden kann,
um
Zugriffsrechte für INGRES-Anwendungen zu vergeben.
Nachdem ein solcher Identifikator definiert ist und
die Zugriffsrechte
vergeben sind, kann er
u.a. mit der
SQL-Anweisung CONNECT verwendet werden, um die vergebenen
Zugriffsrechte innerhalb einer
INGRES-Sitzung zu aktivieren.
Die Angabe PASSWORD=kennwort
definiert das Kennwort
für
den angegebenen Identifikator. Das
Kennwort muß anschließend
in
der CONNECT-Anweisung explizit
angegeben werden, um
die vergebenen
Zugriffssrechte zu aktivieren.
Bei der
NOPASSWORD-Angabe wird
kein Kennwort definiert.
Dadurch
kann jede INGRES-Sitzung den
Zugriff auf den definierten
Identifikator und damit auch
auf die mit ihm verbundenen
Zugrifffsrechte haben.
Beispiel 20.5
CREATE ROLE mitarb_neu WITH PASSWORD='axbycz';
Mit der Anweisung
ALTER ROLE identifikator
WITH NOPASSWORD | PASSWORD=neu_kennwort;
kann ein existierendes Kennwort, das
im Zusammenhang mit
dem Identifikator identifikator steht, geändert (PASSWORD=
neu_kennwort) bzw. gelöscht (NOPASSWORD) werden. Falls das
Kennwort gelöscht wird, kann jede
INGRES-Sitzung den Zugriff
auf
den Identifikator und damit auf die mit ihm verbundenen
Zugriffsfrechte haben.
Mit der Anweisung
DROP ROLE
ident_1 [, ident_2,...];
werden die schon definierten Identifikatoren ident_1,
ident_2,... gelöscht.
Für
Anweisungen CREATE ROLE, ALTER
ROLE und DROP ROLE gilt
generell, daß nur der
INGRES-Systemverwalter sie ausführen
kann, wenn er in einer Sitzung arbeitet, die mit iidbdb
verbunden ist.
Abgesehen von der in
Kapitel 15 beschriebenen
GRANT-Anweisung, die
im allgemeinen gilt,
unterstützt
der Knowledge
management-Modul eine gleichnamige
SQL-Anweisung, die
eine erweiterte Funktionalität hat.
Die
erweiterte GRANT-Anweisung
regelt zusätzlich zu
der
Vergabe der Tabellen- und Prozeduren- auch die Vergabe der
Datenbank-Zugriffsrechte.
Die erweiterte GRANT-Anweisung hat
folgende Syntax
GRANT recht_1 [recht_2,...]
ON [obj_typ] obj_name1 [,obj_name2,...]
TO PUBLIC | [auto_typ]
id_1 [,id_2,...];
obj_typ kennzeichnet den Objekttyp, für den die
Zugriffsrechte recht_1, recht_2,... vergeben wurden. Dieser
Objekttyp kann entweder
eine Tabelle, oder eine DB-Prozedur
oder eine Datenbank sein. Falls
der Objekttyp ausgelassen
wird, wird standardmäßig Tabelle
angenommen.
Abhängig vom Objekttyp kennzeichnet obj_name1,
obj_name2,...
Tabellen-, DB-Prozedur- oder Datenbanknamen. Alle
Objektnamen einer
erweiterten
GRANT-Anweisung müssen
demselben Objekttyp angehören.
Die TO-Klausel
identifiziert den Benutzer,
dem die
Zugriffsrechte vergeben wurden.
PUBLIC kennzeichnet alle
Benutzer eines INGRES-Systems. auto_typ
spezifiziert den
Autorisierungstyp, der
- USER,
- GROUP oder
- ROLE
sein kann. id_1, id_2,... charakterisieren die
Identifikatoren jeweiligen
Autorisierungstyps. Wenn z.B.
eine erweiterte GRANT-Anweisung den Autorisierungstyp GROUP
hat, müssen die Identifikatoren Gruppennamen sein. Falls
auto_typ ausgelasen
wird, wird standardmäßig USER als
Autorisierungstyp und
Benutzernamen als Identifikatoren
angenommen.
recht_1, recht_2,... kennzeichnen die vergebenen
Zugriffsrechte, die
sich, abhängig vom
Objekttyp
unterscheiden. Die möglichen
Tabellen-Zugriffsrechte
- SELECT,
- UPDATE,
- INSERT,
- DELETE und
- ALL
sind mit allen ihren
Eigenschaften in Kapitel
15
beschrieben.
Bei den DB-Prozeduren existiert nur
ein Zugriffsrecht
- EXECUTE,
mit
dem einem oder
mehreren Benutzern die
Möglichkeit
gegeben wird, die genannte
DB-Prozedur auszuführen.
(Standardmäßig darf
nur der Eigentümer die DB-Prozedur
ausführen.)
Die Datenbank-Zugriffsrechte
werden vom DBA
oder dem
INGRES-Systemverwalter
vergeben. Mit ihnen ist es möglich,
den
Zugriff von Benutzern auf
Tabellen, DB-Prozeduren oder
anderen Datenbank-Ressourcen zu
steuern.
Zu den Datenbank-Zugriffsrechten
gehören
-
[NO]QUERY_IO_LIMIT,
-
[NO]QUERY_ROW_LIMIT,
- [NO]CREATE_TABLE,
- [NO]CREATE_PROCEDURE,
- [NO]LOCKMODE und
- [NO]DB_ADMIN.
Das Datenbank_Zugriffsrecht QUERY_IO_LIMIT definiert die
maximal erlaubte Anzahl von
E/A-Operationen für eine
Abfrage.
Dementsprechend kennzeichnet
QUERY_ROW_LIMIT die
maximal erlaubte Anzahl der
ausgewählten Reihen einer
Abfrage. NOQUERY_IO_LIMIT bzw.
NOQUERY_ROW_LIMIT sind die
Voreinstellungen, die keine
Einschränkungen bezüglich der
E/A-Operationen bzw. der
Reihenanzahl bei einer
Abfrage
setzen.
Beispiel 20.6
GRANT QUERY_ROW_LIMIT 2000
ON DATABASE beispiel, vertrieb TO
USER
peter, paul, mary;
In
Beispiel 20.6 ist die Reihenanzahl jeder Abfrage auf die
Datenbanken beispiel und vertrieb für die Benutzer peter,
paul und mary auf 2000 beschränkt. (Die Einschränkung wird
generell schon als
erfüllt betrachtet, falls der optimale
Ausführungsplan des
Optimierers für diese
Abfrage eine
größere als die maximal zulässige
Anzahl vorhersagt.)
Das
Datenbank-Zugriffsrecht
CREATE_TABLE ermöglicht die
gezielte Vergabe der
Erstellungsrechte für Tabellen
einer
Datenbank. Standardmäßig können alle Benutzer (PUBLIC) eine
Tabelle erstellen. Um dies zu
verhindern, empfiehlt es sich,
zuerst
die Anweisung
GRANT NOCREATE_TABLE ON
DATABASE db_name TO PUBLIC;
auszuführen und
damit allen Benutzern
die Erstellung
von
Tabellen für die
Datenbank db_name zu
verbieten.
Anschließend muß
mit einer zweiten
GRANT-Anweisung
gezielt gewissen Benutzern, Gruppen oder Anwendungen das
Zugriffsrecht CREATE_TABLE vergeben
werden.
CREATE_PROCEDURE erlaubt die Vergabe
der Erstellungsrechte
für Prozeduren einer Datenbank. Standardmäßig können alle
Benutzer (PUBLIC)
DB-Prozeduren erstellen. Um
dies zu
verhindern, kann
genauso vorgegangen werden
wie beim
CREATE_TABLE-Zugriffsrecht.
Das Zugriffsrecht
LOCKMODE spezifiziert, wer
die
SQL-Anweisung SET LOCKMODE verwenden darf. Standardmäßig
können alle Benutzer diese Anweisung
benutzen.
Die Vergabe des DB_ADMIN-Zugriffsrechtes an einen Benutzer
bedeutet, daß er
- alle DB-Rechte für die
angegebene Datenbank hat;
- die INGRES-Systemtabellen
ändern darf und
- den Schalter -u verwenden darf (d.h. auf
die
angegebene Datenbank als
ein anderer Benutzer
zugreifen darf.)
Beispiel 20.7
GRANT EXECUTE ON
PROCEDURE bericht TO PUBLIC;
In
Beispiel 20.7 wird die Ausführung der DB-Prozedur bericht
allen INGRES-Benutzern zugänglich
gemacht.
Mit
der Anweisung REVOKE können die mit
der erweiterten
GRANT-Anweisung vergebene
Datenbank-Zugriffsrechte wieder
entzogen werden. Diese Anweisung hat
folgende Form
REVOKE recht_1
[,recht_2,...]
ON DATABASE db_name1 [,db_name2,...]
FROM PUBLIC | [auto_typ]
id_1 [,id_2,...];
Die REVOKE-Anweisung hat dieselbe Funktion
für die
erweiterte GRANT-Anweisung wie DROP
PERMIT für die
allgemeine GRANT-Anweisung.
Beispiel
20.8
REVOKE CREATE_TABLE ON
DATABASE beispiel
FROM USER anja, uwe;
Mit der
REVOKE-Anweisung in Beispiel
20.8 wird das
Datenbank-Zugriffsrecht CREATE_TABLE den Benutzern anja und
uwe
entzogen. (In diesem Fall wird angenommen, daß dieses
Zugriffsrecht den
beiden Benutzern mit
der erweiterten
GRANT-Anweisung schon vorher
explizit vergeben wurde.)