PostgreSQLスキーマ管理の基本

Postgresqlスキーマとは何か、なぜそれらが重要なのか、スキーマを使用してデータベース実装をより堅牢で保守しやすくする方法について疑問に思っていますか？この記事では、Postgresqlのスキーマの基本を紹介し、いくつかの基本的な例を使用してスキーマを作成する方法を示します。今後の記事では、実際のアプリケーションのスキーマを保護して使用する方法の例について詳しく説明します。

まず、潜在的な用語の混乱を解消するために、Postgresqlの世界では、「スキーマ」という用語が残念ながら過負荷になっている可能性があることを理解しましょう。リレーショナルデータベース管理システム（RDBMS）のより広い文脈では、「スキーマ」という用語は、データベースの全体的な論理的または物理的な設計、つまり、すべてのテーブル、列、ビュー、およびその他のオブジェクトの定義を指すと理解される場合があります。データベース定義を構成します。そのより広い文脈では、スキーマは、実体関連（ER）ダイアグラム、またはアプリケーションデータベースのインスタンス化に使用されるデータ定義言語（DDL）ステートメントのスクリプトで表現される場合があります。

Postgresqlの世界では、「スキーマ」という用語は「名前空間」としてよりよく理解される可能性があります。実際、Postgresqlシステムテーブルでは、スキーマは「名前空間」と呼ばれるテーブル列に記録されます。これは、IMHOではより正確な用語です。実際問題として、Postgresqlのコンテキストで「スキーマ」を見ると、「名前空間」と言っていると黙って再解釈します。

しかし、「名前空間とは何ですか？」と尋ねることができます。一般に、名前空間は、名前で情報を整理および識別するためのかなり柔軟な手段です。たとえば、隣接する2つの世帯、スミス、アリスとボブ、およびジョーンズ、ボブとキャシーを想像してみてください（図1を参照）。名だけを使用すると、ボブについて話すときにどの人物を意味するのか混乱する可能性があります。ただし、名前にSmithまたはJonesを追加することで、意味する人物を一意に識別できます。

多くの場合、名前空間はネストされた階層で編成されます。これにより、膨大な量の情報を、たとえばインターネットドメインネームシステムなどの非常にきめ細かい構造に効率的に分類できます。トップレベルでは、「。com」、「。net」、「。org」、「。edu」などが、特定のエンティティの登録名である広い名前空間を定義します。たとえば、「severalnines.com」および「postgresql.org」は一意に定義されます。ただし、それぞれの下には、「www」、「mail」、「ftp」などの一般的なサブドメインがいくつかあります。これらは単独では重複しますが、それぞれの名前空間内では一意です。

Postgresqlスキーマは、これと同じ目的で整理および識別を行いますが、上記の2番目の例とは異なり、Postgresqlスキーマを階層にネストすることはできません。データベースには多くのスキーマが含まれている場合がありますが、レベルは1つしかないため、データベース内ではスキーマ名は一意である必要があります。また、すべてのデータベースには少なくとも1つのスキーマが含まれている必要があります。新しいデータベースがインスタンス化されるたびに、「public」という名前のデフォルトスキーマが作成されます。スキーマのコンテンツには、テーブル、ビュー、ストアドプロシージャ、トリガーなど、他のすべてのデータベースオブジェクトが含まれます。視覚化するには、スキーマが構造のどこに適合するかを示すmatryoshka人形のようなネストを示す図2を参照してください。 Postgresqlデータベース。

スキーマは、データベースオブジェクトを論理グループに編成して管理しやすくするだけでなく、名前の衝突を回避するという実用的な目的を果たします。 1つの運用パラダイムには、データベースユーザーごとにスキーマを定義して、ある程度の分離を提供することが含まれます。これは、ユーザーが互いに干渉することなく独自のテーブルとビューを定義できるスペースです。もう1つのアプローチは、サードパーティのツールまたはデータベース拡張機能を個々のスキーマにインストールして、関連するすべてのコンポーネントを論理的にまとめることです。このシリーズの後半の記事では、データベースの物理設計の公開を制限する間接的な手段としてスキーマを採用し、代わりに合成キーを解決して長期的な保守と構成管理を容易にするユーザーインターフェイスを提示する、堅牢なアプリケーション設計への新しいアプローチについて詳しく説明します。システム要件が進化するにつれて。

コードを書いてみましょう！

データベース内にスキーマを作成するための最も簡単なコマンドは

CREATE SCHEMA hollywood;

このコマンドにはデータベースでの作成権限が必要であり、新しく作成されたスキーマ「hollywood」は、コマンドを呼び出すユーザーが所有します。より複雑な呼び出しには、別の所有者を指定するオプションの要素が含まれる場合があり、スキーマ内のデータベースオブジェクトをすべて1つのコマンドでインスタンス化するDDLステートメントが含まれる場合もあります。

一般的な形式は

CREATE SCHEMA schemaname [ AUTHORIZATION username ] [ schema_element [ ... ] ]

ここで、「username」はスキーマの所有者であり、「schema_element」は特定のDDLコマンドの1つである可能性があります（詳細については、Postgresqlのドキュメントを参照してください）。 AUTHORIZATIONオプションを使用するには、スーパーユーザー権限が必要です。

したがって、たとえば、「films」という名前のテーブルと「winners」という名前のビューを含む「hollywood」という名前のスキーマを1つのコマンドで作成するには、次のようにします。

CREATE SCHEMA hollywood
    CREATE TABLE films (title text, release date, awards text[])
    CREATE VIEW winners AS
        SELECT title, release FROM films WHERE awards IS NOT NULL;

その後、追加のデータベースオブジェクトを直接作成できます。たとえば、

CREATE TABLE hollywood.actors (name text, dob date, gender text);

上記の例では、テーブル名の前にスキーマ名が付いていることに注意してください。これが必要なのは、デフォルトでは、つまり明示的なスキーマ指定がないため、現在のスキーマ内に新しいデータベースオブジェクトが作成されるためです。これについては、次に説明します。

上記の名前空間の例で、Bobという名前の2人がいたことを思い出してください。また、名前を含めることで、競合を解消または区別する方法を説明しました。しかし、スミスとジョーンズの各世帯内では、各家族は「ボブ」がその特定の世帯に付随するものを指すことを理解しています。したがって、たとえば、それぞれの世帯のコンテキストでは、アリスは夫をボブジョーンズと呼ぶ必要はなく、キャシーは夫をボブスミスと呼ぶ必要はありません。それぞれが「ボブ」と言うことができます。

Postgresqlの現在のスキーマは、上記の例の世帯のようなものです。現在のスキーマ内のオブジェクトは修飾なしで参照できますが、他のスキーマ内の同様の名前のオブジェクトを参照するには、上記のようにスキーマ名の前に付けて名前を修飾する必要があります。

現在のスキーマは、「search_path」構成パラメーターから派生しています。このパラメータは、スキーマ名のコンマ区切りのリストを格納し、コマンドで調べることができます

SHOW search_path;

または

SET search_path TO schema [, schema, ...];

リストの最初のスキーマ名は「現在のスキーマ」であり、スキーマ名の修飾なしで指定された場合に新しいオブジェクトが作成される場所です。

スキーマ名のコンマ区切りのリストは、システムが既存の修飾されていない名前付きオブジェクトを検索するための検索順序を決定するのにも役立ちます。たとえば、スミスとジョーンズの近所に戻ると、「ボブ」だけに宛てた小包の配達では、「ボブ」という名前の最初の居住者が見つかるまで、各世帯を訪問する必要があります。これは意図した受信者ではない可能性があることに注意してください。同じロジックがPostgresqlにも当てはまります。システムは、スキーマ内のテーブル、ビュー、およびその他のオブジェクトをsearch_pathの順序で検索し、最初に見つかった名前一致オブジェクトが使用されます。スキーマ修飾された名前付きオブジェクトは、search_pathを参照せずに直接使用されます。

デフォルトの構成では、search_path構成変数を照会すると、この値が明らかになります

SHOW search_path;
 Search_path
--------------
 "$user", public

システムは、上記の最初の値を現在ログインしているユーザー名として解釈し、各ユーザーに他のユーザーとは別のワークスペース用のユーザー名付きスキーマが割り当てられる前述のユースケースに対応します。そのようなユーザー名のスキーマが作成されていない場合、そのエントリは無視され、「パブリック」スキーマが新しいオブジェクトが作成される現在のスキーマになります。

したがって、「hollywood.actors」テーブルを作成する前の例に戻ると、テーブル名をスキーマ名で修飾していなかった場合、テーブルはパブリックスキーマで作成されます。特定のスキーマ内にすべてのオブジェクトを作成することを想定している場合は、

SET search_path TO hollywood,public;

データベースオブジェクトを作成またはアクセスするために、修飾されていない名前を入力する手間を省きます。

クエリで現在のスキーマを返すシステム情報関数もあります

select current_schema();

スペルを太くする場合、スキーマの所有者は名前を変更できます。ただし、ユーザーがデータベースの作成権限も持っている場合は、

ALTER SCHEMA old_name RENAME TO new_name;

そして最後に、データベースからスキーマを削除するために、ドロップコマンドがあります

DROP SCHEMA schema_name;

スキーマにオブジェクトが含まれている場合、DROPコマンドは失敗するため、最初にオブジェクトを削除する必要があります。または、オプションで、CASCADEオプションを使用してスキーマのすべての内容を再帰的に削除できます

DROP SCHEMA schema_name CASCADE;

これらの基本事項により、スキーマの理解を始めることができます！