Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
SQL Serverのデータベーススキーマは、単一データベース内のテーブル、ビュー、ストアドプロシージャなど関連するデータオブジェクトをグループ化する名前付き論理コンテナです。データ構造の定義とアクセス制御の境界を定めます。
SQL Server 2005以前は、オブジェクトは作成したユーザーに直接紐付けられていました。バージョン2005以降、スキーマはユーザーから独立したため、DB管理者はアプリケーションコードを修正することなく、オブジェクトの所有権移転やアクセス権限の再構成が可能になりました。
SQL Server標準搭載スキーマ
すべてのSQL Serverデータベースには事前定義されたスキーマが用意されています。
dbo：ユーザー作成オブジェクトの既定スキーマです。スキーマを指定せずテーブルを作成するとこちらに配置されます。小規模システムでは問題ありませんが、大規模システムでdboにすべてのオブジェクトを格納するのは設計上の不備となるケースが多いです。sys：システムカタログビューと内部関数専用の予約領域です。ここにユーザーオブジェクトを作成してはいけません。INFORMATION_SCHEMA：テーブル名やカラム定義といったデータベース構造のメタデータを照会する規格準拠の手段で、各種SQLプラットフォームで統一された動作を実現します。guest：guestユーザーアカウントに紐付いたスキーマです。本番環境では明示的なデータベースアカウントを持たないユーザーからのアクセスを遮断するため、通常アクセスを制限します。SQL Serverのスキーマ作成にはT-SQL、またはSQL Server管理ツール（SSMS）のGUI画面を使用できます。SSMSは単発作業に適しますが、開発・検証・本番環境間でスクリプトの再利用やバージョン管理が容易なため、多くのDB管理者はT-SQLを利用します。
以下の例では、頻出する4種類のスキーマ操作（スキーマ作成、スキーマ内へのオブジェクト作成、スキーマ間のオブジェクト移動、既存スキーマ一覧取得）を解説します。
CREATE SCHEMA文を使用して新しいスキーマを定義します。オプションで所有者（通常はデータベースロールまたはユーザー）を指定可能です。
-- 既定所有者でスキーマを作成
CREATE SCHEMA Sales;
GO
-- 所有者を指定してスキーマを作成
CREATE SCHEMA Production AUTHORIZATION dbo;
GO
スキーマ作成後、スキーマ名.オブジェクト名の記法でオブジェクトを作成します。スキーマプレフィックスを省略すると、SQL Serverは既定スキーマ（通常はdbo）にオブジェクトを配置します。
CREATE TABLE Sales.Orders (
OrderID INT PRIMARY KEY,
OrderDate DATETIME,
CustomerID INT
);
GO
誤ったスキーマに作成したオブジェクトはALTER SCHEMA ... TRANSFERで移動可能で、テーブルの削除・再作成は不要です。
-- dboスキーマからSalesスキーマへテーブルを移動
ALTER SCHEMA Sales TRANSFER dbo.OldOrders;
GO
現在のデータベースに定義されている全スキーマを確認するには、sys.schemasカタログビューをクエリ実行します。
SELECT name AS SchemaName, schema_id, principal_id AS OwnerID
FROM sys.schemas; 
SSMS画面からスキーマを作成する手順は以下の通りです。
Finance）を入力します。
実運用において全テーブルをdboに格納すると管理が困難になります。エンタープライズシステムでは組織構造やデータライフサイクルに合わせてスキーマを分ける設計が一般的で、データベースの閲覧性向上とセキュリティ制御の簡素化を実現します。
代表的な4つの設計パターンを紹介します。
大規模ERPは複数の業務機能で構成されるため、スキーマで業務領域を明確に分離します。
production.WorkOrders：製造工程管理データprocurement.Vendors ：サプライヤー情報管理finance.GeneralLedger：機密性の高い財務データこの設計により、財務チームにfinanceスキーマのフルアクセス権を付与しつつ、productionのデータへのアクセスを完全に遮断するといった権限制御が可能です。
CRMデータベースには機密レベルやアクセス頻度の大きく異なるデータが混在するため、スキーマで分離します。
crm.Leads：更新頻度の高い営業見込み顧客データcontract.Agreements：厳格なアクセス制御が必要な法的契約書データsupport.Tickets：カスタマーサポート対応履歴契約データと顧客見込みデータを分離することで、頻繁に更新されるテーブルと高機密データを論理的に隔離できます。
SaaS製品の一部ではテナントごとに独立したスキーマを割り当てる設計を採用します。
tenant_acme.Userstenant_globex.Users強固なデータ隔離を実現でき、顧客解約時に該当テナントのスキーマのみ削除するだけで他顧客のデータに影響を与えません。
分析パイプラインでは、データの加工段階ごとにスキーマを分けます。
bronze.RawIngestion：連携元から取得した未加工の生データsilver.CleanedData：重複除去・フォーマット調整済みデータgold.Reporting：Power BIやTableauなどBIツール向けの集計済みテーブル分析担当者はgold層のクリーンなデータのみ参照し、生データ層を誤って読み込む事態を回避できます。
スキーマ作成自体は簡単ですが、データベースの規模拡大に伴って長期的に運用可能な設計には熟考が必要です。以下は現場の熟練DB管理者が本番環境で実践しているルールです。
スキーマ名はTables、StoredProcsといったオブジェクト種別ではなく、Sales、Inventory、HRなど業務機能名に統一します。業務の実態とデータベース構造を一致させ、開発者が関連オブジェクトを容易に探せるようにします。
オブジェクト参照時はSales.Ordersのようにスキーマプレフィックスを付け、Ordersだけの記述を避けてください。理由は2点あります。
dboは便利ですが、全てのオブジェクトの格納先とするべきではありません。大規模システムでは共通設定テーブルや複数業務で利用する汎用ユーティリティのみdboに配置し、それ以外は専用スキーマに分けることで、スキーマ単位のセキュリティ制御と論理グループ分けのメリットを最大限活用できます。
大規模システムではチームまたはアプリケーション機能ごとにスキーマを1つ割り当てます。マーケティング開発チームにMarketingスキーマの完全な所有権を付与し、給与計算のPayrollスキーマへのアクセスを遮断するといった権限管理が簡素化され、複雑なデータベースにおける最小権限の原則を実践できます。
適切なスキーマ設計はデータ管理の一部に過ぎません。データベースの規模拡大に伴い、マイグレーション、バージョンアップ、クロスプラットフォーム移行時のデータ消失、破損、予期せぬダウンタイムリスクが増大します。SQL Serverを運用するエンタープライズ環境では、スキーマ設計と連携するレプリケーション・事業継続レイヤーが不可欠です。
i2Streamはエンタープライズ向けデータベースレプリケーションソリューションで、同種・異種混合データベース環境向けのリアルタイムデータ同期、災害復旧、移行支援機能を提供します。停止許容できない本番システム向けに開発されています。
i2Streamの主な機能
複数環境に跨る複雑なSQL Serverスキーマを管理する運用チームにとって、i2Streamはシステム拡大に伴う運用リスクを解消します。スキーマ設計がデータの構造を定義し、i2Streamがその構造とデータの一貫性・安全性・可用性をあらゆる環境で保証します。
Q1：オブジェクトが残ったスキーマを削除できますか？
できません。オブジェクトが残存するスキーマに対しDROP SCHEMAを実行するとエラーが返されます。スキーマを削除するには事前に内部のすべてのオブジェクトを移動または削除する必要があります。ALTER SCHEMA ... TRANSFERでオブジェクトを移動するか、DROP TABLEで削除した後、DROP SCHEMA スキーマ名を実行してください。
Q2：SQL Server内の全スキーマを確認する方法は？
sys.schemasカタログビューにクエリを実行します。
SELECT name AS SchemaName, schema_id, principal_id AS OwnerID
FROM sys.schemas;
SSMSではオブジェクトエクスプローラーから対象データベース→セキュリティ→スキーマを展開すると一覧を閲覧可能です。
Q3：SQL Serverにデータベーススキーマを作成する方法は？
T-SQLのCREATE SCHEMA文を使用します。
CREATE SCHEMA Sales;
GO
またはSSMS上でセキュリティ配下のスキーマを右クリックし、新しいスキーマ…を選択します。詳細な手順は上記「スキーマを作成する方法」セクションを参照してください。
Q4：SQL Serverのスキーマ名を変更する方法は？
SQL Serverにはスキーマ名を直接変更する機能が存在しません。一般的な代替手段は、希望する名称の新しいスキーマを作成し、ALTER SCHEMA ... TRANSFERで全オブジェクトを移動後、ビュー・ストアドプロシージャ・アプリケーションコード内の参照箇所を修正し、最後に古いスキーマを削除する手順です。
SQL Serverのスキーマは単なるデータ整理ツールではなく、安全で保守性・拡張性に優れたデータベースを構築する基盤です。初期段階で適切な設計を行うことで、後続の運用工数を大幅に削減できます。
要点は以下の通りです。業務ドメイン名でスキーマを命名し、常にスキーマプレフィックス付きでオブジェクトを参照、dboに過度なオブジェクトを配置せず、スキーマ構造を組織やアプリケーションの業務フローに適合させます。
本番環境において、スキーマ設計だけでは十分な保護は実現できません。Info2softのi2Streamといった信頼性の高いレプリケーションソリューションと組み合わせることで、プラットフォーム移行、複数地域へのスケーリング、並行運用する複数環境管理のいずれの場面でも、データベースの成長に伴いデータの一貫性と安全性を維持できます。
