カタログとリレーショナルデータベースのスキーマの違いは何ですか？
スキーマは、データベース自体よりも前の「上位ラッパー」オブジェクトだと思っていました。というのは 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インストール
Postgresをマシンにインストールすると、そのインストールはclusterと呼ばれます。ここでの「クラスタ」は、複数のコンピューターが連携して動作する hardwareの意味 を意味しません。 Postgresでは、clusterは、同じPostgresサーバーエンジンを使用して、複数の無関係なデータベースをすべて稼働させることができるという事実を指します。
Word clusterも [〜＃〜] sql [〜＃〜]Standard によって定義されます。 Postgres。 SQL標準に厳密に従うことは、Postgresプロジェクトの主な目標です。
SQL-92 仕様には次のように書かれています：
クラスターは、実装定義のカタログのコレクションです。
そして
正確に1つのクラスターがSQLセッションに関連付けられています
これは、クラスターがデータベースサーバーである（各カタログはデータベースである）と言うわかりにくい方法です。
クラスター>カタログ>スキーマ>テーブル>列と行
したがって、PostgresとSQL Standardの両方に、次の包含階層があります。
- コンピューターには、1つまたは複数のクラスターがあります。
- データベースサーバーはclusterです。
- クラスターには catalogs があります。 （カタログ=データベース）
- カタログにはschemasがあります。 （スキーマ=テーブルの namespace 、およびセキュリティ境界）
- スキーマには tables があります。
- テーブルには rows があります。
- 行には、 列 で定義される値があります。
これらの値は、ユーザーの名前、請求書の期日、製品価格、ゲーマーの高得点など、アプリやユーザーが関心を持つビジネスデータです。この列は、値の data type （テキスト、日付、数値など）を定義します。
複数のクラスター
この図は、単一のクラスターを表しています。 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は非常に強力な製品です。