Rechte auf partitionierte Tabellen einschränken

[Steven Troll]

Hallo NG,

gibt es eine schnelle Möglichkeit (ausser Views), User in Ihren Rechten (über eine Rolle z.Bsp) soweit einzuschränken, dass diese nur Inhalte aus bestimmten Partitionen einer partitionierten Tabelle sehen und bearbeiten können? Bsp. Eine partitionierte Tabelle, bestehend aus zwei Partitionen, welche in verschiedenen Tablespaces gespeichert werden, soll von zwei Benutzergruppen bearbeitet bzw. gesehen werde. Eine Gruppe soll nur die Daten aus Partition 1 sehen und bearbeiten, zweite Gruppe soll nur Daten aus Partition 2 sehen können. Versucht habe ich schon die User über Ihre QUOTA auf dem jeweils nicht erlaubten Tablespace einzuschränken, bringt nix. Können trotzdem lesen und schreiben. Ich suche händeringend nach einer Lösung weil wir nicht alle Views der schon bestehenden Applikation umschreiben wollen, sondern das Problem lieber (sofern möglich) über Rollen lösen wollen.

MfG Steven

[Claus Salzmann]

Umweg über View:
create view xy as select * from tab where spalte = irgendeinwert;
dann Recht auf View vergebe

[Steven Troll]

Vielen Dank für Deine Antwort. Leider war es mir schon bekannt wie ich das Prob. mit VIEWS lösen kann, daher mein Ausschluss. das Problem mit den VIEWs ist folgendes. Auf der DB sind schon eine Menge VIEWS definiert, welche dann alle umgeschrieben werden müssten. Diese Arbeit wollten wir uns ersparen und suchten deshalb nach einen Lösung über die Rollen oder Rechte. Trotzdem vielen Dank.

MfG Steve

[tp]

Hi Steven,

ich glaube, ich bin sogar etwas froh darüber, daß man nicht den Zugriff auf Partitionen einschränken kann. Denn Partitionen bedeuten physische Speicherung von Daten und betreffen nicht den logischen Aufbau einer Datenbank, zu dem die Sicherheit zweifelsohne gehört.

Nur eine Meinung ;

[Steven Troll]

Hallo Thomas,

vielleicht habe ich mich unklar ausgedrückt, ich meine nicht die Partitionen der physischen Festplatte sondern Teilbereiche eine partitionierten Tabelle, d.h. Eine Tabelle in mehrere Bereiche zerlegt, abhängig von einen Schlüsselwert wird dann der Datensatz in einer der Teilbereiche (Partitionen) gespeichert. z.Bsp kannst Du eine Tabelle in 10 Teile zerlegen, und einen Datensatz abhängig von Datum/Jahreszahl in die Tabelle xyz/Partition 4 schieben. Das kann man in einem Tablespace machen oder die Partitionen über mehrere Tablespaces verteilen. Was erreicht man damit? z.Bsp eine höhere Performance weil bei einer Suche nach Datum/Jahreszahl von der gesamten Tabelle 9/10 ausgeschlossen sind. Oracle braucht also bloss eine Partition dieser Tabelle durchsuchen um den gewünschten Row zurückzugeben. Das kann unter Umständen ziemlich vorteilhaft sein.
Aber trotzdem danke für Deine Meinung )

MfG Steve

[tp]

Hi Steven,

ist ja nett, daß Du mich für blöd verkaufen willst - klappt nur nicht.
<p>
Nach wie vor bin ich nämlich der Meinung, daß eine <i> _Oracle Partition_ </i> etwas mit <i>_Datenspeicherung_</I> zu tun hat, und nicht mit dem <i>_logischen_</i> Aufbau einer Tabelle. Brauchst mir das nicht zu erklären, was eine Oracle-Partition ist.
<p>
Aber wahrscheinlich hilft Dir "fine-grained access control" weiter. Für den Einstieg empfiehlt sich Dokument A76965-01 (p27-23) (Du weißt ja sicher, was das heißt). Würd ich nur performant implementieren, damit Dir an dieser Stelle nichts weg bricht.

Tja, wenn man einmal das Design verkorkst hat...

c

[tp]

Ach ja, ein schönes Beispiel ist auch in A68003-01, p12-31. Aber wie geagt, entweder gleich hart verdrahten oder Tabellen benutzen, die gut gecacht werden

[tp]

Und warum schaust Du eigentlich nicht selbst in die Doku

[Steven Troll]

Hallo Thomas,

nichts liegt mir ferner als Dich für dumm verkaufen zu wollen. Entschuldige bitte falls dieser Eindruck entstanden ist. Da habe ich Dich einfach falsch verstanden und einen Denkfehler gemacht (logisch - physisch).Vielen Dank für Deinen Tip, damit habe ich einen neuen Denkansatz. Das Problem mit dem Design ist wie immer gewachsen, da haben wir vor 4 Jahren im Leben nicht dran gedacht.

MfG Steve

[tp]

No prob, mußt aber auch ein wenig "zurückschießen". Am schlimmsten ist es eigentlich, wenn man ein Design (DB/App) erbt ;

[tp]

Wenn wir jetzt noch ein Beispiel zum Thema posten, wird der Thread langsam so lang wie die Delphi-Threads von Andreas Kosch. Mal sehn, ob ich heute abend Zeit hab *smile*

[Kuhlmann Robert]

Hey,

zu dem Problem der partionierten Tabellen kann nur folgendes gesagt werden:
1. Eine Berechtigung auf Objekte kann nur über den Befehl grant ... to ...; erteilt werden. Dann gilt diese Berechtigung für das gesamte Objekt!
2.Will mann das einschränken gehen daher nur über Views oder eine Applikation entfernt den direkten Blick auf die Tabellen.
3 Quotas sind nur für die Schreibberechtigung hat nix mit dem lesen zu tun, aber das habt Ihr ja eh gewußt

[tp]

Robert,

und was ist mit A76965-01 (p27-23)? "Fine-Grained Access Control"? Stichwort: Policies mit Policy-Function! Steven meinte, er wäre damit weitergekommen - habe es selber noch nicht probiert...

Übrigens: Du kannst in diesem Thread wieder Deine Meinung sagen, der War ist vorrüber

c

[Kuhlmann Robert]

Hallo Thomas

was meinst Du damit 'A76965-01' ???