Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Definizione dei dati > Schemi
PrecedentePrivilegiEreditarietàSuccessivo

5.7. Schemi

Un cluster di database PostgreSQL™ contiene uno o più database. Utenti e gruppi di utenti sono condivisi attraverso l'intero cluster, ma nessun altro dato è condiviso tra i database. Ogni connessione da un client al server può accedere solo ai dati in un singolo database, quello specificato nella richiesta di connessione.

[Nota]

Nota

Gli utenti di un cluster non hanno necessariamente il privilegio di aver accesso ad ogni database nel cluster. La condivisione degli username significa che non ci possono essere differenti utenti chiamati, per esempio, joe in due database dello stesso cluster; ma il sistema può essere configurato per permettere a joe l'accesso solamente ad alcuni dei database.

Un database contiene uno o più schemi, che contengono tabelle. Gli schemi contengono anche altri tipi di oggetti con nome, incluso tipi di dato, funzioni, e operatori. Lo stesso nome di oggetto può essere usato in differenti schemi senza conflitti; Per esempio, sia schema1 che myschema possono contenere tabelle chiamate mytable. A differenza dei database, gli schemi non sono separati rigidamente: un utente può avere accesso a qualsiasi degli schemi nel database a cui è connesso, se ha i privilegi per farlo.

Ci sono diverse ragioni per cui potresti voler usare gli schemi:

  • Permettere a molti utenti di usare un database senza interferire tra di loro.

  • Organizzare gli oggetti di database in gruppi logici per renderli più gestibili.

  • Applicazioni di terze parti posso essere messe in schemi separati così cge non conflittino con i nome degli altri oggetti.

Gli schemi sono analoghi alle directory a livello di sistema operativo, ad eccezione che gli schemi non possono essere annidate.

5.7.1. Creare uno Schema

Per creare uno schema, usa il comando CREATE SCHEMA(7) Dai allo schema un nome a piacere. Per esempio:

CREATE SCHEMA myschema;

Per creare o accedere ad oggetti in uno schema, scrivi un nome qualificante composto dal nome dello schema e dal nome della tabella separati da un punto:

schema.table

Questo funziona ovunque sia accettato il nome di una tabella, inclusi i comandi di modifica della tabella e i comandi di accesso ai dati discussi nei seguenti capitoli. (Per brevità parleremo solo di tabelle, ma la stessa idea si applica agli altri tipi di oggetti, come tipi e funzioni.)

In realtà, anche la sintassi più generale

database.schema.table

può essere usata, ma al momento questa è solo per essere pro forma con lo standard SQL. Se scrivi il nome di un database, deve essere lo stesso del database a cui sei connesso.

So to create a table in the new schema, use: Così, per creare una tabella nel nuovo schema, usa:

CREATE TABLE myschema.mytable (
 ...
);

Per eliminare uno schema se è vuoto (tutti gli oggetti all'interno della schema sono stati eliminati), usa:

DROP SCHEMA myschema;

Per eliminare uno schema includendo tutti gli oggetti contenuti, usa:

DROP SCHEMA myschema CASCADE;

Vedi Sezione 5.11, «Dipendenze» per una descrizione del comportamento generale che sta sotto.

Spesso vorrai create uno schema posseduto da qualcun altro (dato che questo è un modo di restringere le attività dei tuoi utenti in namespace ben definiti). La sintassi per farlo è:

CREATE SCHEMA schemaname AUTHORIZATION username;

Puoi comunque omettere il nome dello schema, nel qual caso il nome dello schema sarà lo stesso dell'username. Vedi Sezione 5.7.6, «Usage Patterns» per sapere come questo può essere utile.

I nomi degli schemi che iniziano con pg_ sono riservati per scopi di sistema e non possono essere creati dagli utenti.

5.7.2. Lo Schema Public

Nelle sezioni precedenti abbiamo creato tabelle senza specificare alcuno schema. Di default quelle tabelle (e gli altri oggetti) sono automaticamente inseriti in uno schema chiamato «public». Ogni nuovo database contiene quello schema. Così, i seguenti comandi sono equivalenti:

CREATE TABLE products ( ... );

and:

CREATE TABLE public.products ( ... );

5.7.3. Il Percorso di Ricerca dello Schema

I nomi qualificati sono noiosi da scrivere, e comunque spesso è meglio non legare uno schema particolare all'applicazione. Perciò spesso ci si riferisce alle tabelle con nomi non qualificati, che consistono solo del nome della tabella. Il sistema determina a quale tabella ci stiamo riferendo seguendo un percorso di ricerca, che è un elenco di schemi in cui cercare. La prima tabella corrispondente trovata nel percorso di ricerca è considerata quella voluta. Se non ci sono risultati nel percorso di ricerca, viene riportato un errore, anche se il nome di tabella cercato esiste in altri schemi del database.

Il primo schema persente nel percorso di ricerca è chiamato lo schema corrente. Oltre ad essere il primo schema cercato, è anche lo schema in cui le nuove tabelle saranno create se il comando CREATE TABLE non specifica il nome di uno schema.

Per vedere il percorso di ricerca corrente, usa il seguente comando:

SHOW search_path;

Nell'installazione di default questo ritorna:

 search_path
--------------
 "$user",public

Il primo elemento specifica che uno schema con lo stesso nome dell'utente corrente viene cercato. Se tale schema non esiste, la voce viene ignorata. Il secondo elemento allo schema public che abbiamo già visto.

Il primo schema nel percorso di ricerca che esiste è la posizione di default per la creazione di nuovi oggetti. È la ragione per cui gli oggetti sono creati di default nello schema public. Quando gli oggetti sono richiamati in ogni altro contesto senza qualificare uno schema (modifica di tabelle, modifica di dati o query) il percorso di ricerca viene attraversato finchè non viene trovato un oggetto corrispondente. Perciò, in una configurazione standard, ogni accesso non qualificato può riferirsi solo allo schema public.

To put our new schema in the path, we use: Per inserire il nostro schema nel percorso, usiamo:

SET search_path TO myschema,public;

(Omettiamo l'$user qui perchè non ne abbiamo immediato bisogno.) E quindi possiamo accedere alla tabella senza qualificare lo schema:

DROP TABLE mytable;

Inoltre, dato che myschema è il primo elemento nel percorso, i nuovi oggetti saranno per default creati in esso.

Potevamo anche scrivere:

SET search_path TO myschema;

Così non avremo più accesso allo schema public senza esplicita qualificazione. Non c'è niente di speciale nello schema public tranne che esiste di default. Può essere anche cancellato.

Vedi anche Sezione 9.23, «Funzioni per informazioni di sistema» per altri modi di manipolare il percorso di ricerca degli schemi.

Il percorso di ricerca lavora nello stesso modo dei nomi dei tipi di dato, nomi di funzioni e nomi di operatori e nomi di tabelle. I tipi di dato e i nomi delle funzioni possono essere qualificati nello stesso identico modo dei nomi delle tabelle. Se devi scrivere un nome di operatore qualificato in una espressione, c'è una condizione speciale: devi scrivere

OPERATOR(schema.operator)

Questo è necessario per evitare ambiguità sintattiche. Un esempio è:

SELECT 3 OPERATOR(pg_catalog.+) 4;

In pratica puoi contare sul percorso di ricerca per gli operatori, così non dovrai scrivere di così orribile.

5.7.4. Schemi e Privilegi

Per default, gli utenti non possono accedere ad alcun oggetto in schemi che non possiedano. Per permettere questo, il possessore dello schema deve concedere il privilegio USAGE allo schema. Per permettere agli utenti di fare uso degli oggetti nello schema, potresti avere bisogno di concedere privilegi addizionali, appropriati per l'oggetto.

Un utente può anche essere abilitato a creare oggetti in uno schema di un altro. Per permettere ciò, devi concedere il privilegio CREATE sullo schema. Notare che di default, chiunque ha i privilegi CREATE e USAGE sullo schema public. Questo permette a tutti gli utenti che possono collegarsi a un dato database, di creare oggetti nel proprio schema public. Se non vuoi permettere ciò, puoi revocare quel privilegio:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

(Il primo «public» è lo schema, il secondo «public» significa «ogni utente». Il primo è un identificatore, il secondo una parola chiave, da cui il differente uso delle maiuscole; ricontrolla le linee guida Sezione 4.1.1, «Identificatori e parole chiave».)

5.7.5. Lo Schema Catagolo di Sistema

In aggiunta agli schemi public e a quelli creati dall'utente, ogni database ha uno schema pg_catalog, che contiene le tabelle di sistema e tutti i tipi di dato, funzioni, e operatori incorporati. pg_catalog è sempre una parte effettiva del percorso di ricerca. È cercato implicitamente prima degli altri schemi. Questo assicura che i nomi incorporati saranno sempre raggiungibili- Ad ogni modo, puoi esplicitamente posizionare pg_catalog alla fine del percorso di ricerca se preferisci avere nomi definiti dall'utente che sovrascrivano nomi incorporati.

Nelle versioni PostgreSQL™ precedenti la 7.3, i nomi delle tabelle che cominciavano con pg_ erano riservati. Questo non è più vero: quei nomi si possono usare, in ogni schema non di sistema. Comunque, è meglio continuare a evitare tali nomi, per essere sicuri di non avere conflitti se qualche versione futura definirà una tabella di sistema chiamata allo stesso modo della tua. (Con il percorso di ricerca di default, un riferimento non qualificato alla tua tabella sarebbe invece risolto come riferimento alla tabella di sistema.) Le tabelle di sistema continueranno a seguire la convenzione di avere nomi che cominciano con pg_, così che non andranno in conflitto con nomi di tabelle-utente non qualificati finche l'utente eviterà il prefisso pg_

5.7.6. Usage Patterns

Gli schemi possono essere usati per organizzare i dati in molte maniere. Ci sono alcuni modi d'uso raccomandati e supportati facilmente dalla configurazione di default:

  • Se non si crea nessun schema allora tutti gli utenti hanno accesso allo schema public implicitamente. Questo simula la situazione in chi gli schemi non sono disponibili per niente. Questa configurazione è raccomandata principalmente quando c'è un solo utente o pochi utenti cooperanti in un database. Questa situazione permette anche una transizione fluida da una che non abbia schemi.

  • Si può creare uno schema per ogni utente con lo stesso nome dell'utente. Ricordare che il percorso di ricerca di default comincia con $user, che diventa il nome dell'utente. Per questo, se ogni utente ha uno schema separato, accederà il proprio schema di default.

    Usando questa configurazione allora si potrebbe voler anche revocare l'accesso allo schema public (o eliminarlo del tutto), così gli utenti saranno realmente vincolati all'uso dei propri schemi.

  • Per installare applicazioni condivise (tabelle che tutti possano usare, funzioni addizionali messe a disposizione da terzi, ecc.), metterle in schemi separati. Si ricordi di concedere privilegi appropriati per permettere agli altri utenti di averne accesso. Gli utenti possono allora riferirsi a questi oggetti addizionali qualificandone i nomi con il nome dello schema, o possono mettere gli schemi addizionali nel loro percorso di ricerca, è una loro scelta.

5.7.7. Portabilità

Nell'SQL standard, il concetto di oggetti nello stesso schema posseduti da utenti diversi non esiste. In più, alcune implementazioni non permettono la creazione di schemi che hanno un nome diverso dal loro possessore. Infatti, i concetti di schema e utente sono quasi equivalenti in un sistema di database che implementa solo un supporto base agli schemi. Perciò, molti utenti considerano nomi qualificati composti, in realtà, da username.tablename. Così è come PostgreSQL™ si comporterà effettivamente se viene creato uno schema per ogni utente.

Inoltre, non c'è il concetto di schema public nel SQL standard. Per seguire al massimo lo standard, non dovresti usare (forse addirittura rimuovere) lo schema public.

Certamente, alcuni sistemi di database SQL potrebbero non implementare gli schemi per niente, o fornire il supporto ai namespace permettendo un accesso attraverso al databse (probabilmente limitato). Se devi lavorare con questi sistemi, allora la massima portabilità si raggiunge non usansdo per niente gli schemi.

Documentazione di PostgreSQL 9.0 > Il linguaggio SQL > Definizione dei dati > Schemi
PrecedentePrivilegiEreditarietàSuccessivo