★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

23.1. 概要

ロール、データベース、テーブル空間名のような少数のオブジェクトはクラスタレベルで定義されており、pg_globalテーブル空間に格納されています。 クラスタの中には複数のデータベースがあり、互いに分離されているもののクラスタレベルのオブジェクトにはアクセスできます。 各データベースの中には複数のスキーマがあり、スキーマはテーブルや関数などのオブジェクトを含みます。 したがって階層の全体像は、クラスタ、データベース、スキーマ、テーブル(や関数などの何らかのオブジェクト)となります。

データベースサーバに接続する時、クライアントはその接続要求の中で接続するデータベース名を指定しなければなりません。 1つの接続で複数のデータベースにアクセスすることはできません。 しかし、クライアントは同じデータベースに対して複数の接続を開いたり、異なるデータベースに対して複数の接続を開いたりできます。 データベースレベルでのセキュリティには2つの構成要素があります。接続レベルで管理されるアクセス制御(21.1参照)と、権限付与システムで管理される認証制御(5.7参照)です。 外部データラッパ(postgres_fdw参照)により、1つのデータベース内のオブジェクトが他のデータベースやクラスタ内にあるオブジェクトに対するプロキシとして動作できるようなります。 古いdblinkモジュール(dblink参照)は同様の機能を提供します。 デフォルトでは、すべてユーザはすべてのデータベースにすべての接続方法で接続できます。

1つのPostgreSQLサーバクラスタに、たいていの場合お互いのことを意識しない、関係のないプロジェクトやユーザを含めるつもりなら、これらを別々のデータベースに含め、それに従って認証制御とアクセス制御を調整することが推奨されます。 複数のデータベースは物理的に分離されていて、アクセス制御は接続レベルで管理されています。 したがって、分離して、ほとんどの場面で互いに見えないようにする必要のある複数のプロジェクトやユーザを単一のPostgreSQLサーバインスタンスに収容する場合、これらを別々のデータベースに含めることが推奨されます。 もし、複数のプロジェクトやユーザが相互に関連していて互いのリソースを使用できる必要がある場合、これらは同じデータベースに含めるべきですが、スキーマを別にすることは可能です。これは名前空間での分離と認証制御によるモジュラー構造を提供します。 スキーマの管理についての詳細は5.9に記載されています。

1つのクラスタ内に複数のデータベースを作成できますが、その利点がその危険性と制限に勝るかどうか慎重に検討することを勧めます。 特に、共有のWAL(第30章参照)を持つことの影響がバックアップとリカバリのオプションにあります。 クラスタ内の個々のデータベースは、ユーザの視点から考えれば分離していても、データベース管理者の観点からは密接に結びついています。

データベースはCREATE DATABASEコマンド(23.2を参照)で作成され、DROP DATABASEコマンド(23.5を参照)で破棄されます。 既存のデータベース群を求めるには、以下の例のようにpg_databaseシステムカタログを確認してください。

SELECT datname FROM pg_database;

また、psqlプログラムの\lメタコマンドや-lコマンドラインオプションも既存のデータベースを列挙する際に役に立ちます。

注記

標準SQLでは、データベースをカタログ(catalog)と呼ぶこともありますが、実際のところ違いはありません。