top of page
  • Immagine del redattoreElvis Informatico

DB Oracle: utenti app ed owner

Oggi Elvis ci ha chiamati, ha bisogno di tirare su un DB (database) dove inserire tutti i dati anagrafici dei suoi amici marziani. Niente di più semplice, oggi il mercato offre software DB potenti ed efficienti, uno su tutti è sicuramente Oracle. Per creare un DB da zero in Oracle, bisogna necessariamente creare un nuovo utente col comando create user e relativa sintassi (in cui specificare password di accesso, dimensioni del db o tablespace ecc.), il DBMS Oracle (database management system) creerà automaticamente un DB, detto schema, di cui l'utente appena creato sarà l'owner (proprietario). Quindi, per ogni utente creato viene automaticamente assegnato un suo spazio, in cui esso può inserire oggetti (tabelle, indici, procedure, viste ecc.) e dati. Generalmente, un DB viene utilizzato da persone ma soprattutto da applicazioni, le quali possono inserire, cancellare e modificare dati connettendosi allo schema. Ora attenzione, un utente proprietario del suo schema può potenzialmente fare tutto: cancellare dati, tabelle ed addirittura il contenuto dell'intero schema. Dunque, i danni possono essere potenzialmente enormi, se non viene adeguatamente gestito l'accesso ai dati di applicazioni ed utenti. Proprio per questo, l'accesso al DB non viene mai eseguito con l'utente owner, ma con un altro utente, definito generalmente applicativo, che ha delle grant (permessi) opportunamente limitate per accedere e gestire i dati dell'owner. Tra le grant concesse, non vi è per esempio la possibilità di cancellare l'intero contenuto dello schema (drop) , permesso che soltanto un utente proprietario può avere. Dunque, un utente di tipo applicativo accede allo schema owner non connettendosi a quest'ultimo, ma accedendo dal suo proprio schema, quando si trova ad interrogare le tabelle e gli oggetti dello schema owner, può utilizzare una notazione puntata nel codice sql che gli permette di utilizzare gli oggetti dello schema owner, ad esempio, se volesse interrogare la tabella squadre dello schema owner campionato, scriverà qualcosa del genere:


select * from campionato.squadre


Tuttavia esiste un modo ben più pratico di interrogare oggetti su uno schema diverso dal nostro, si tratta dei sinonimi. Un sinonimo assegna semplicemente un nome (alias) ad un oggetto di un altro schema, evitando di scrivere codice sql in notazione puntata. Se per esempio volessimo creare il sinonimo per la tabella squadre dello schema owner campionato, dovremmo anzitutto farci assegnare la grant di creazione sinonimo dall'utente owner (essendo lui il proprietario dell'oggetto, solo lui può assegnare i permessi) ed eseguire successivamente il comando di creazione sinonimo. Poniamo il caso che il nostro sinonimo si chiamerà squadre_campionato, per interrogare la tabella basterà scrivere una query così:


Select * from squadre_campionato


Anche la possibilità di creare un sinonimo su un altro schema, è una grant che deve essere permessa da chi è owner degli oggetti a cui il sinonimo punta. Insomma, grant e sinonimi sono comandi fondamentali per chi gestisce DB, che siano utenti in carne ed ossa od applicazioni. Come dici Elvis? Vuoi approfondire l'argomento DB? Ma certo, lo faremo nei prossimi articoli.




669 visualizzazioni0 commenti

Post recenti

Mostra tutti
bottom of page