Pensavo che lo schema fosse l'oggetto "wrapper superiore" prima del database stesso. Voglio dire DB.schema.<what_ever_object_name_under_schema>.
Bene, il "wrapper" del catalogo ora è abbastanza confuso. Perché dovremmo aver bisogno di un catalogo? A quale scopo, precisamente, dovrebbe essere utilizzato il catalogo?
Risposte:
Dal punto di vista relazionale:
Il catalogo è il luogo dove - tra le altre cose - vengono conservati tutti i vari schemi (esterno, concettuale, interno) e tutte le corrispondenti mappature (esterno / concettuale, concettuale / interno).
In altre parole, il catalogo contiene informazioni dettagliate (a volte chiamate informazioni descrittive o metadati ) riguardanti i vari oggetti che sono di interesse per il sistema stesso.
Ad esempio, l'ottimizzatore utilizza le informazioni del catalogo sugli indici e altre strutture di archiviazione fisiche, nonché molte altre informazioni, per decidere come implementare le richieste degli utenti. Allo stesso modo, il sottosistema di sicurezza utilizza le informazioni di catalogo sugli utenti e i vincoli di sicurezza per concedere o negare tali richieste in primo luogo.
An Introduction to Database Systems, 7th ed., CJ Date, p 69-70.
I cataloghi sono raccolte di schemi denominate in un ambiente SQL. Un ambiente SQL contiene zero o più cataloghi. Un catalogo contiene uno o più schemi, ma contiene sempre uno schema denominato INFORMATION_SCHEMA che contiene le viste ei domini dello schema delle informazioni.
Database Language SQL , (Testo rivisto proposto di DIS 9075), p 45
Un catalogo è spesso sinonimo di database . Nella maggior parte dei dbms SQL, se interroghi le viste information_schema, troverai che i valori nella colonna "table_catalog" sono associati al nome di un database.
Se trovi la tua piattaforma che utilizza il catalogo in un modo più ampio di una qualsiasi di queste tre definizioni, potrebbe riferirsi a qualcosa di più ampio di un database: un cluster di database, un server o un cluster di server. Ma ne dubito, dal momento che lo avresti trovato facilmente nella documentazione della tua piattaforma.
Mike Sherrill "Cat Recall" ha dato un'ottima risposta . Aggiungerò semplicemente un esempio: Postgres .
Quando installi Postgres su una macchina, quell'installazione viene chiamata cluster . "Cluster" qui non è inteso nel senso hardware di più computer che lavorano insieme. In Postgres, cluster si riferisce al fatto che è possibile avere più database non correlati tutti attivi e in esecuzione utilizzando lo stesso motore del server Postgres.
Anche la parola cluster è definita dallo standard SQL allo stesso modo di Postgres. Seguire da vicino lo standard SQL è un obiettivo primario del progetto Postgres.
La specifica SQL-92 dice:
Un cluster è una raccolta di cataloghi definita dall'implementazione.
e
Esattamente un cluster è associato a una sessione SQL
Questo è un modo ottuso per dire che un cluster è un server di database (ogni catalogo è un database).
Quindi sia in Postgres che nello standard SQL abbiamo questa gerarchia di contenimento:
Questo diagramma rappresenta un singolo cluster. Nel caso di Postgres, puoi avere più di un cluster per computer host (o sistema operativo virtuale). Di solito vengono eseguiti più cluster per testare e distribuire nuove versioni di Postgres (es: 9.0 , 9.1 , 9.2 , 9.3 , 9.4 , 9.5 ).
Se hai più cluster, immagina il diagramma sopra duplicato.
Numeri di porta diversi consentono ai cluster multipli di vivere fianco a fianco tutti attivi e funzionanti allo stesso tempo. A ogni cluster verrà assegnato il proprio numero di porta. Il solito 5432è solo l'impostazione predefinita e può essere impostato da te. Ogni cluster è in ascolto sulla propria porta assegnata per le connessioni al database in entrata.
Ad esempio, un'azienda potrebbe avere due diversi team di sviluppo software. Uno scrive software per gestire i magazzini mentre l'altro team costruisce software per gestire le vendite e il marketing. Ogni team di sviluppo ha il proprio database, beatamente ignaro di quello dell'altro.
Ma il team delle operazioni IT ha deciso di eseguire entrambi i database su un singolo computer (Linux, Mac, qualunque cosa). Quindi su quella scatola hanno installato Postgres. Quindi un server di database (cluster di database). In quel cluster, creano due cataloghi, un catalogo per ogni team di sviluppo: uno denominato "warehouse" e uno denominato "sales".
Ogni team di sviluppo utilizza molte dozzine di tabelle con scopi e ruoli di accesso diversi. Quindi ogni team di sviluppo organizza le proprie tabelle in schemi. Per coincidenza, entrambi i team di sviluppo tengono traccia dei dati contabili, quindi ogni team ha uno schema denominato "contabilità". L'utilizzo dello stesso nome schema non è un problema perché i cataloghi hanno ciascuno il proprio spazio dei nomi, quindi nessuna collisione.
Inoltre, ogni squadra alla fine crea una tabella per scopi contabili denominata "libro mastro". Ancora una volta, nessuna collisione di nomi.
Puoi pensare a questo esempio come a una gerarchia ...
Postgres 9.2 cluster (installazione)
warehouse catalogo (database)
inventory schema
accounting schema
ledger tavolosales catalogo (database)
selling schema
accounting schema (coincidente stesso nome come sopra)
ledger tabella (coincidente con lo stesso nome di sopra)Postgres 9.3 grappolo
Il software di ogni team di sviluppo effettua una connessione al cluster. Quando lo fanno, devono specificare quale catalogo (database) è loro. Postgres richiede la connessione a un catalogo, ma non sei limitato a quel catalogo. Quel catalogo iniziale è semplicemente un valore predefinito, utilizzato quando le istruzioni SQL omettono il nome di un catalogo.
Quindi, se il team di sviluppo ha mai bisogno di accedere alle tabelle dell'altro team, può farlo se l'amministratore del database ha dato loro i privilegi per farlo. L'accesso avviene con una denominazione esplicita nel pattern: catalog.schema.table . Quindi, se il team "magazzino" ha bisogno di vedere il registro dell'altro team (team "vendite"), scrive le istruzioni SQL con sales.accounting.ledger. Per accedere al proprio libro mastro, si limitano a scrivere accounting.ledger. Se accedono a entrambi i libri mastri nella stessa porzione di codice sorgente, possono scegliere di evitare confusione includendo il proprio nome di catalogo (opzionale), warehouse.accounting.ledgerrispetto a sales.accounting.ledger.
A proposito…
Potresti sentire la parola schema usata in un senso più generale, che significa l'intero progetto della struttura della tabella di un particolare database. Al contrario, nello standard SQL la parola significa specificamente il particolare livello nella Cluster > Catalog > Schema > Tablegerarchia.
Postgres utilizza sia il database di parole che il catalogo in vari punti, come il comando CREATE DATABASE .
Non tutti i sistemi di database forniscono questa gerarchia completa di Cluster > Catalog > Schema > Table. Alcuni hanno un solo catalogo (database). Alcuni non hanno schema, solo un insieme di tabelle. Postgres è un prodotto eccezionalmente potente.
PostgreSQL (pg_catalog), il catalogo del sistema, le decine di tabelle "pg_" che memorizzano le definizioni di metadati dei database, ad esempio pg_index, pg_triggere pg_constraint. (2) ANSI (information_schema), la visualizzazione di sola lettura dello stesso catalogo di sistema definito dallo standard SQL come information_schema. Un nome migliore per il nodo "Cataloghi" in pgAdmin potrebbe essere "Sistema" o "Tabelle di sistema".
...Catalog > Schema..., qualcuno può dirmi perché i nodi "Catalogo" e "Schema" in pgAdmin (interfaccia utente PostgreSQL) sono nodi fratelli, invece del nodo Schema come nodo figlio del Catalogo?