スキーマは、データベース自体よりも前の「上位ラッパー」オブジェクトだと思っていました。というのは DB.schema.<what_ever_object_name_under_schema>
。
さて、カタログの「ラッパー」は非常に混乱しています。なぜカタログが必要なのですか?どのような目的で、正確にカタログを使用する必要がありますか?
リレーショナルの観点から:
カタログは、(とりわけ)すべてのさまざまなスキーマ(外部、概念、内部)および対応するすべてのマッピング(外部/概念、概念/内部)が保持される場所です。
つまり、カタログには、関心のあるさまざまなオブジェクトに関する詳細情報(記述子情報またはmetadataと呼ばれることもある)が含まれていますシステム自体。
たとえば、オプティマイザーは、インデックスおよびその他の物理ストレージ構造に関するカタログ情報、およびその他の多くの情報を使用して、ユーザー要求の実装方法を決定するのに役立ちます。同様に、セキュリティサブシステムは、ユーザーに関するカタログ情報とセキュリティ制約を使用して、そもそもこうした要求を許可または拒否します。
データベースシステムの概要、第7版、C.J。Date、p 69-70。
カタログは、SQL環境のスキーマの名前付きコレクションです。 SQL環境には、ゼロ個以上のカタログが含まれます。カタログには1つ以上のスキーマが含まれますが、情報スキーマのビューとドメインを含むINFORMATION_SCHEMAという名前のスキーマが常に含まれます。
データベース言語SQL 、(DIS 9075の改訂テキストの提案)、p 45
多くの場合、カタログはdatabaseと同義です。ほとんどのSQL dbmsでは、information_schemaビューをクエリすると、「table_catalog」列の値がデータベースの名前にマッピングされることがわかります。
catalogを使用してプラットフォームがこれら3つの定義のいずれよりも広い場合、それはデータベースよりも広いもの、つまりデータベースクラスター、サーバー、またはサーバークラスターを指している可能性があります。しかし、プラットフォームのドキュメントで簡単に見つけることができたので、ちょっと疑っています。
Mike Sherrill 'Cat Recall' は 優れた回答 を出しました。 Postgres という1つの例を追加します。
Postgresをマシンにインストールすると、そのインストールはclusterと呼ばれます。ここでの「クラスタ」は、複数のコンピューターが連携して動作する hardwareの意味 を意味しません。 Postgresでは、clusterは、同じPostgresサーバーエンジンを使用して、複数の無関係なデータベースをすべて稼働させることができるという事実を指します。
Word clusterも [〜#〜] sql [〜#〜]Standard によって定義されます。 Postgres。 SQL標準に厳密に従うことは、Postgresプロジェクトの主な目標です。
SQL-92 仕様には次のように書かれています:
クラスターは、実装定義のカタログのコレクションです。
そして
正確に1つのクラスターがSQLセッションに関連付けられています
これは、クラスターがデータベースサーバーである(各カタログはデータベースである)と言うわかりにくい方法です。
したがって、PostgresとSQL Standardの両方に、次の包含階層があります。
この図は、単一のクラスターを表しています。 Postgresの場合、ホストコンピューター(または仮想OS)ごとに複数のクラスターを持つことができます。 Postgresの新しいバージョンをテストおよびデプロイするために、複数のクラスターが一般的に行われます(例: 9.0 、 9.1 、 9.2 、 9.3 、 9.4 、 9.5 )。
複数のクラスターがある場合は、上の図が複製されていることを想像してください。
異なるポート番号を使用すると、複数のクラスターを同時に並行して稼働させることができます。各クラスターには、独自のポート番号が割り当てられます。通常の5432
はデフォルトであり、ユーザーが設定できます。各クラスタは、着信データベース接続用に割り当てられた独自のポートでリッスンしています。
たとえば、企業に2つの異なるソフトウェア開発チームがいる場合があります。 1つは倉庫を管理するソフトウェアを作成し、もう1つのチームは販売とマーケティングを管理するソフトウェアを作成します。各開発チームには独自のデータベースがあり、他のチームにはまったく気付きません。
しかし、IT運用チームは、単一のコンピューターボックス(Linux、Macなど)で両方のデータベースを実行することを決定しました。そのため、彼らはPostgresをインストールしました。したがって、1つのデータベースサーバー(データベースクラスター)。このクラスターでは、各開発チームのカタログという2つのカタログを作成します。1つは「warehouse」、もう1つは「sales」です。
各開発チームは、さまざまな目的とアクセスロールを持つ多数のテーブルを使用します。したがって、各開発チームはテーブルをスキーマに編成します。偶然にも、両方の開発チームはアカウンティングデータの追跡を行っているため、各チームは「accounting」という名前のスキーマを持っています。カタログにはそれぞれ独自の namespace があるため、同じスキーマ名を使用しても問題はありません。衝突は発生しません。
さらに、各チームは最終的に「元帳」という名前の会計目的のテーブルを作成します。繰り返しますが、名前の衝突はありません。
この例を階層として考えることができます…
Postgres 9.2
クラスター(インストール)warehouse
カタログ(データベース)inventory
スキーマaccounting
スキーマledger
テーブルsales
カタログ(データベース)selling
スキーマaccounting
スキーマ(上記と同じ名前)ledger
テーブル(上記と同じ名前)Postgres 9.3
クラスター各開発チームのソフトウェアは、クラスターに接続します。その際、どのカタログ(データベース)が自分のものであるかを指定する必要があります。 Postgresでは、1つのカタログに接続する必要がありますが、そのカタログに限定されません。その初期カタログは単なるデフォルトであり、SQLステートメントがカタログの名前を省略したときに使用されます。
そのため、開発チームが他のチームのテーブルにアクセスする必要がある場合、データベース管理者が privileges にアクセスするようにifを与えます。アクセスは、パターン内の明示的な命名で行われます:catalog.schema.table。そのため、「倉庫」チームが他のチーム(「販売」チーム)元帳を確認する必要がある場合、sales.accounting.ledger
を使用してSQLステートメントを記述します。自分の元帳にアクセスするには、単にaccounting.ledger
と書くだけです。同じソースコードの両方の元帳にアクセスする場合、独自の(オプションの)カタログ名warehouse.accounting.ledger
対sales.accounting.ledger
を含めることで混乱を避けることができます。
ところで…
特定のデータベースのテーブル構造の設計全体を意味する、より一般的な意味で使用されるWord schemaを聞くことができます。対照的に、SQL標準では、WordはCluster > Catalog > Schema > Table
階層内の特定のレイヤーを意味します。
Postgresは、 CREATE DATABASE コマンドなどのさまざまな場所で、Word databaseとcatalogの両方を使用します。
すべてのデータベースシステムがCluster > Catalog > Schema > Table
のこの完全な階層を提供するわけではありません。カタログ(データベース)が1つしかないものもあります。スキーマを持たないテーブルもあります。 Postgresは非常に強力な製品です。