オブジェクトを整理したい？SQL Serverのスキーマ（Schema）の仕組みと活用方法をやさしく解説
SQL Serverでデータベースを管理していると、テーブルやビュー、ストアドプロシージャなどのオブジェクトが増えて複雑になりがちです。
そんなときに役立つのがスキーマ（Schema）です。
スキーマはオブジェクトをグループ化して整理する仕組みであり、同時に権限管理や運用分離にも活用できます。
この記事では、スキーマの基本概念から作成・権限設定・実務活用のポイントまでを初心者向けにわかりやすく解説します。
目次
スキーマ（Schema）とは？
スキーマの基本概念
スキーマとは、テーブルやビュー、ストアドプロシージャなどのオブジェクトを論理的にまとめる「フォルダ」のようなものです。
SQL Serverでは、各オブジェクトは必ずどこかのスキーマに所属しています。
例えば、次のようにスキーマ名を付けてテーブルを指定します。
SELECT * FROM Sales.Customers;
ここで Sales がスキーマ名、Customers がテーブル名です。
スキーマを使うことで、同じデータベース内でもオブジェクトを整理して扱うことができます。
スキーマを使うメリット
1. オブジェクトを分類・整理できる
業務ごとにスキーマを分けることで、オブジェクト構成をわかりやすく整理できます。
| スキーマ名 | 用途 | 例 |
|---|---|---|
| Sales | 販売関連 | Sales.Orders, Sales.Customers |
| Master | マスタデータ | Master.Products, Master.Stores |
| Report | 分析・集計用 | Report.MonthlySummary |
こうしてスキーマごとに役割を分けると、管理や検索がしやすくなります。
2. 権限をスキーマ単位で設定できる
スキーマを使えば、テーブル単位ではなく「グループ単位」でアクセス権を設定できます。
GRANT SELECT ON SCHEMA::Sales TO SalesUser;
この例では、Salesスキーマ内のすべてのテーブルに対してSELECT権限を一括付与しています。
これにより、セキュリティ管理が簡単になります。
3. 名前の衝突を防げる
異なるスキーマに同じ名前のオブジェクトを作成できるため、開発やテスト環境を分離するのにも役立ちます。
CREATE TABLE Dev.Customers (...);
CREATE TABLE Prod.Customers (...);
スキーマを使うことで、同じデータベース内で複数のバージョンを共存させられます。
スキーマの作成・変更・削除
スキーマを作成する
新しいスキーマを作るには CREATE SCHEMA を使います。
CREATE SCHEMA Sales AUTHORIZATION dbo;
AUTHORIZATION句では、そのスキーマを所有するユーザー（またはロール）を指定します。
スキーマを変更する（所有者の変更）
ALTER AUTHORIZATION ON SCHEMA::Sales TO SalesManager;
この例では、Salesスキーマの所有者をSalesManagerに変更しています。
スキーマを削除する
スキーマ内にオブジェクトが残っていると削除できません。
中身をすべて削除してから次のコマンドを実行します。
DROP SCHEMA Sales;
削除は慎重に行いましょう。
スキーマとユーザー・権限の関係
スキーマ所有者と権限の考え方
スキーマはユーザー（またはロール）によって所有されます。
所有者は、そのスキーマ内のすべてのオブジェクトに対する完全な権限を持ちます。
-- スキーマとユーザーを同時に作成する例
CREATE SCHEMA Accounting AUTHORIZATION Accountant;
また、GRANTやDENYを使って特定ユーザーにスキーマ単位で権限を設定することも可能です。
権限設定の例
-- SELECT権限をスキーマ単位で付与
GRANT SELECT ON SCHEMA::Master TO ReportUser;
-- 変更権限を禁止
DENY UPDATE ON SCHEMA::Master TO ReportUser;
これにより、データ閲覧はできても変更はできないよう制御できます。
実務での活用パターン
① 部署や機能ごとにスキーマを分ける
業務システムでは、「販売」「会計」「人事」などの業務単位でスキーマを分けるのが一般的です。
| スキーマ名 | 担当部署 | 例 |
|---|---|---|
| Sales | 営業部 | Sales.Orders, Sales.Customers |
| Accounting | 経理部 | Accounting.Invoices, Accounting.Payments |
| HR | 人事部 | HR.Employees, HR.Salaries |
部署ごとにスキーマを分けることで、責任範囲を明確にし、アクセス権を分離できます。
② 開発環境・本番環境をスキーマで分離
同じデータベース内に Dev・Test・Prod のようなスキーマを設けることで、環境を論理的に分離できます。
Dev.Customers
Prod.Customers
物理的なデータベースを分けずに環境切り替えができるため、小規模開発では便利です。
③ 外部アプリケーション用のアクセス制御
外部アプリに渡すデータだけをまとめたスキーマを作り、そのスキーマに限定的な権限を与えることでセキュリティを強化できます。
CREATE SCHEMA ApiData AUTHORIZATION Dbo;
GRANT SELECT ON SCHEMA::ApiData TO ExternalAppUser;
こうすることで、他の機密データにはアクセスさせずに安全にデータ提供が可能です。
まとめと次のステップ
学んだ内容の整理
- スキーマはオブジェクトを整理し、権限を分離するための論理的なフォルダ。
- CREATE SCHEMAで作成し、GRANT文でスキーマ単位の権限を設定できる。
- 部署・機能・環境単位で分けると運用効率が上がる。
- 名前の衝突防止やセキュリティ強化にも役立つ。
参考リンク
0 件のコメント:
コメントを投稿