Utilizatorul sau schema
Utilizatorul sau schema?
RDBMS Oracle, precum și toți concurenții săi reali - vechiul sistem. sarbatorit recent 25-a aniversare. O astfel de longevitate nu ar fi posibilă fără un număr de soluții tehnice cu succes (în acest punct de vedere) a propus în zilele vechi. Dar, împreună cu acest sistem, există, de asemenea, exemple de defecte de proiectare inițiale. Odată ce acestea nu par așa, și apoi le repara a fost foarte dificil, astfel încât numai în cele mai recente versiuni, cum ar fi a noua, a devenit modalități palpabile de rezolvare a problemei programate accidental. Aceasta este problema „utilizatori“ și „circuite“.
Pentru dezvoltator, aceste două concepte nu sunt identice. Astfel, sistemul este un fel de container stocat în obiectele bazei de date, care transportă sarcină funcțională tradițională dublă: ca mijloc de organizare a datelor (obiecte în lot, dar nu toate aplicațiile de care sunt interesați) și modul în care protecția datelor din aplicațiile neautorizate. Utilizatorul, în conformitate cu ideea sa originală - această persoană care se poate conecta la baza de date pentru a lucra cu anumite date, verificate de autoritatea monitorizate pentru acțiunea angajată, și așa mai departe ..
Acestea fac parte din sistemul de informații, întreprindere, iar utilizatorii pot angaja și foc. Cum de a simula acest mod de lucru în Oracle?
Poate că cineva a venit deja cu o soluție la această problemă sa. Dacă nu - puteți utiliza următoarele.
Pentru instalațiile de depozitare „departamentul de personal“, pentru a crea o schema (-user) HR:
CREA hr UTILIZATOR IDENTIFICAT DE hr;
În plus, după cum este necesar să se specifice toate proprietățile acestui sistem, de exemplu:
ALTER USER hr DEFAULT hr_ts TABLESPACE DEFAULT TABLESPACE temp; și așa mai departe.
Pentru persoane fizice crea utilizatori Oracle, de exemplu:
CREATE USER IDENTIFICAT DE Pete thisismepete;
CREATE USER mary IDENTIFICAT DE maryiam;
...
În plus, utilizatorii trebuie să atribuie proprietățile cerute. De obicei, acestea sunt toate la fel, asa ca are sens să scrie un singur script care dă fiecare nou „Petia“ sau „Masha“ autoritatea necesară. Că ar trebui să fie incluse. La un nivel minim, sistem de privilegii CREATE SESSION. Dar, în plus, pentru a avea acces la mesele lor, în numele HR ar trebui să dea ceva de genul
GRANT SELECT, INSERT, UPDATE, DELETE PE main_hr_table LA PETE;
Asta nu e tot. Utilizatorul PETE într-adevăr să fie acum posibilitatea de a se conecta la baza de date în nume propriu și să lucreze cu masa MAIN_HR_TABLE, cu toate acestea, se referă la ea, el va avea numele complet: HR.MAIN_HR_TABLE, din moment ce nu era masa lui. Pot evita acest lucru și să-l simt „acasă“? Posibil. Este suficient pentru a da:
ALTER SESSION SET CURRENT_SCHEMA = h;
Este mai convenabil, cu toate acestea, această echipă, „înfășurat“ în trăgaci, atunci când vă conectați la „schema“ PETE, adică, pentru a da, de exemplu, în numele SYS:
CREATE OR REPLACE TRIGGER set_hr_schema_for_pete
DUPĂ pete.SCHEMA de autentificare pe
BEGIN
EXECUTE IMMEDIATE „ALTER SESSION SET
CURRENT_SCHEMA = hr „;
END;
/
Acum, conectarea la baza de date, utilizatorul va vedea PETE obiecte HR „ca propria lor“, numele scurt, deși propriile lor tabele, el va fi obligat să cheme „întreg“, de exemplu PETE.MY_PETE_TABLE, dar se pare că, nu contează.
Caracteristici ale soluțiilor propuse
- este necesar pentru a automatiza
- este imposibil de a crea și șterge obiecte
- Puteți utiliza sistemul de audit
Oferit în Oracle 9.0: „utilizatorii corporate“ și serverul de nume.