MS-SQL Server 2005 ha reso il suo linguaggio SQL (Transact-SQL o T-SQL), più conforme alle specifiche ANSI SQL-92, cioè lo standard di riferimento dei DBMS, mantenendo comunque alcune particolarità. Gli "Schema di database" rientrano tra queste. Essi fornisco ai database developer (DBD) un modo più raffinato per organizzare gli oggetti in namespaces, e ai database administrator (DBA) una nuova modalità di gestione della ownership e della sicurezza degli oggetti di database.
Schema in MS-SQL Server 2000
Nella versione "2000", il concetto di "Schema" coincideva con quello di utente possessore di un oggetto di database (object owner). Questa mancata separazione tra utente e Schema creava non pochi problemi nel caso di eliminazione di un utente che fosse anche "owner" di un oggetto.
L'oggetto creato da un utente, restava irrimediabilmente legato al suo creatore e possessore (owner), rendendone impossibile l'eliminazione. Bisognava modificare l'applicazione, specificando il nuovo owner dell'oggetto per ogni query.
Altro effetto di questa relazione tra utente e Schema, è lo spiacevole fenomeno conosciuto col nome di "Broken ownership chain", che si verifica quando due (o più) oggetti, dipendenti tra loro, hanno owner differenti.
Per esempio, supponiamo che l'utente "Mary" abbia creato una vista (View1) basata su una tabella (Table1) creata dall'utente "dbo", e che conceda il permesso di SELECT all'utente "Paul". Quando Paul legge dalla vista View1, il motore di database controlla i permessi sul primo oggetto e poi sul secondo. Se Paul non ha i diritti necessari a leggere dalla tabella Table1, la sua SELECT sulla View1 restituisce un messaggio di errore.
Schema in MS-SQL Server 2005
Prima di affrontare gli Schema, è doverosa una breve premessa sul nuovo modello per la sicurezza introdotto con SQL Server 2005. Questo in quanto gli Schema possono essere sfruttati nell'ambito della gestione della sicurezza, come vedremo nel proseguo dell'articolo. Gli attori del nuovo modello per la sicurezza sono:
- Principals (chi) : individui, gruppi e processi che possono richiedere accesso a risorse di SQL Server
- Securables (cosa): risorse per le quali SQL Server prevede la messa in sicurezza mediante un sistema di autorizzazione che ne regola l'accesso
- Permissions (chi può fare cosa): le definizioni degli accessi che i principals hanno per i securables
In SQL Server 2005 gli Schema non corrispondono più agli utenti di database. Adesso, uno Schema è un namespace la cui esistenza è assolutamente indipendente dall'utente di database che lo ha creato.
Più propriamente, lo Schema è un contenitore logico di oggetti posseduto da un "principal" (utente, database o application role), alla stessa stregua di un oggetto di database qualunque, e la cui ownership può essere trasferita da un utente all'altro, eludendo agevolmente il problema legato alla eliminazione di un utente di database e riducendo la possibilità del verificarsi della "Broken ownership chain". Inoltre gli oggetti contenuti in uno Schema possono appartenere a più utenti di database.
È possibile gestire gli Schema mediante il tool di gestione Sql Server Management Studio, cercando la cartella Protezione>Schemi del database, oppure attraverso una serie di comandi T-SQL.
Creare uno Schema con CREATE SCHEMA. Sintassi
CREATE SCHEMA schema_name [AUTHORIZATION owner_name]
[
table_definition | view_definition | grant_statement | revoke_statement | deny_statement
[ ...n ]
]
Lo Schema può essere creato specificando una ownership mediante la clausola AUTHORIZATION ed è attribuibile a uno di questi principals: "utente di database", "ruolo di database" o "ruolo applicazione". La stessa ownership può essere trasferita mediante un'altra istruzione T-SQL.
Assegnare un diverso proprietario dello schema
ALTER AUTHORIZATION ON SCHEMA::[schema_name] TO [schema_name]
Contestualmente alla creazione dello Schema, è possibile creare tabelle e/o viste al suo interno, quindi impartire istruzioni di "Control Language" quali GRANT, REVOKE e DENY sugli oggetti dello Schema. L'intera istruzione, dalla creazione dello Schema fino alla concessione dei permessi, fa parte di una singola transazione.
È anche ammessa la creazione di uno Schema senza specificare lo schema_name, nel qual caso non viene creato nessun nuovo Schema, bensì i soli oggetti definiti, i quali vengono creati nello Schema predefinito "dbo". Si noti che la sintassi necessita della clausola AUTHORIZATION. Questa modalità, deprecata in quanto sarà rimossa dalle future versioni del prodotto, è supportata per compatibilità con le versioni passate. Essa può essere usata anche da chi non detiene il permesso di CREATE SCHEMA.
Il trasferimento del securable da uno Schema a un'altro si realizza mediante ALTER SCHEMA, dove il securable_name comprende anche lo Schema di appartenenza.
Tasferire il securable tra schemi diversi
ALTER SCHEMA schema_name TRANSFER securable_name
Possiamo infine eliminare uno Schema con DROP SCHEMA a patto che non contenga oggetti di database.
Eliminare uno Schema
DROP SCHEMA schema_name
Default Schema
In SQL Server 2005 ci si riferisce a uno oggetto di database usando la qualificazione completa del nome (fully qualified name).
Sintassi "fully qualified name"
Server.Database.Schema.Object
Esempio di riferimento "fully qualified"
SELECT * FROM MyServer.AdventureWorks.Sales.Customers
È possibile usare una qualificazione non completa. In tal caso, se viene omesso il nome del Server, viene assunto il server della connessione corrente. Stesso discorso vale per il Database. Se non viene specificato lo Schema, invece, viene assunto lo Schema dbo, presente in ogni database, oppure un Default Schema precedentemente definito dall'utente connesso.
Ogni nome di oggetto non qualificato sarà inizialmente risolto utilizzando lo Schema di default; se tale risoluzione non portasse ad un oggetto realmente esistente, il nome viene risolto mediante lo Schema dbo. Se anche questa risoluzione non portasse all'individuazione dell'oggetto, il motore di database restituirà un errore all'applicazione chiamante.
Lo Schema di default può essere assegnato a un utente già esistente oppure nel momento stesso della sua creazione mediante la clausola WITH DEFAULT_SCHEMA.
Definire uno Schema di default in creazione
CREATE USER user_name
FOR LOGIN login_name
WITH DEFAULT_ SCHEMA = schema_name
Modificare lo Schema di default
ALTER USER user_name
WITH DEFAULT_SCHEMA = schema_name
Gestione della protezione mediante gli Schema
Dal punto di vista della sicurezza, uno Schema può essere visto come un gruppo di securables che richiedono permessi comuni. Per cui l'amministratore di database potrà assegnare i permessi a livello di Schema anziché solo a livello di singolo oggetto. L'ereditarietà dei permessi implementata da Sql Server farà il resto, propagando il permesso su ogni singolo securable.
Per esempio, per concedere il permesso di SELECT al ruolo di database denominato "MarketingRole" sugli oggetti appartenenti allo Schema di database denominato "Marketing", possiamo eseguire la seguente istruzione T-SQL:
GRANT SELECT ON SCHEMA::Marketing TO MarketingRole
Successivamente, seguendo il principio generale che regola la gestione dei permessi secondo il quale la "negazione vince sempre", potremmo negare il permesso di SELECT a uno specifico utente appartenente al ruolo "MarketingRole", così come a uno specifico oggetto dello Schema "Marketing":
DENY SELECT ON SCHEMA::Marketing TO Paul
DENY SELECT ON Marketing.Statistics TO Paul
Conclusioni
La separazione utente-Schema e la gestione della sicurezza più dettagliata, sono i punti di forza di una base dati implementata mediante Schema, e la facilità d'implementazione con semplici istruzioni del linguaggio T-SQL ne fanno uno strumento alla portata di tutti. Gli amministratori di database che presentano un gran numero di oggetti e nel contempo un elevato numero di applicazioni e utenti, ne potranno certamente apprezzare i benefici.
