第2回　SQL Server 2000を構成するコンポーネント：初めてのSQL Server 2000（2/4 ページ）

リレーショナル・データベース・エンジン

　前回説明したとおり、データベース管理システムでは、特定のアプリケーションに依存することなく、さまざまなアプリケーションからのデータ要求に応えるために、データを構造化して保存し、データ入出力のための標準的なインターフェイスを提供する。この際のアプリケーションからのデータの格納、あるいはデータ参照に対し、高速に応答できると同時に、競合する書き込みなどからデータを守り、データの信頼性を維持する。またパーソナル・レベルの小さなデータから、部門レベル、全社レベルの大規模なデータまで、幅広いスケールでデータ・アクセス・サービスを提供できる。

　リレーショナル・データベースでは、データを2次元の表形式で格納する。表の列には、その表に格納されるデータの属性が定義される。例えば社員データなら、社員番号、氏名や生年月日、住所などが列として定義されることになるだろう。そして社員1人分のデータが行として格納される（例えば「0072」「山田太郎」「1962.10.08」「東京都杉並区…」）。これらのテーブルは、オブジェクトとして存在している。実際のデータベース・システムでは、多数のテーブルに対し、必要に応じてリレーション（＝テーブル間の関連）をとることで、仮想的なテーブルを構成し、アプリケーションのデータ要求を処理する（例えば、社員テーブルと人事考課テーブルから社員番号をキーとしてレコードの情報を組み合わせ、その社員の氏名と人事考課情報を読み出すなど）。

　データベース・エンジンは、アプリケーションからのデータの問い合わせ（クエリ：Query）に応える。この際のアプリケーションからデータベースへのアクセスでは、DBMSによって定義された言語が使用される。リレーショナル・データベースで最も一般的な問い合わせ言語はSQL（Structured Query Language）である。前回述べたように、SQL Server 2000は、ANSIとISOによって標準化されたSQL-92をベースとするTransact-SQLと呼ばれる構文をサポートしている。

　またSQL Server 2000のデータベース・エンジンは、新しいインターネット・アプリケーションで利用が広がっているXMLにも対応している。SQL Server 2000は、XMLドキュメントのデータベースへの追加、XMLベースの問い合わせ言語であるXPathクエリのサポート、問い合わせ結果のXML形式での出力に対応している。

　さらにデータベース・エンジンの主要な機能の1つは、データベース・アクセスを行うアプリケーション向けに標準的なインターフェイスを提供することだ。標準的なアクセス・インターフェイスが提供されれば、アプリケーションは、特定のRDBMSに依存せずに上位のアプリケーションを開発できる。これにより、アプリケーションからデータを独立させ、異なるRDBMSで管理されるデータベースを透過的に扱うことが可能になる。

　具体的にSQL Server 2000リレーショナル・データベース・エンジンは、ODBC（Open DataBase Connectivity）やADO（ActiveX Data Object）、OLE DBといったデータ・アクセス・インターフェイスを提供している（→用語解説）。

SQL Server 2000がサポートするデータベース・アクセス・インターフェイス
SQL Server 2000は、ODBCやADO、OLE DBといったマイクロソフトの標準データ・アクセス・インターフェイスを提供している。アプリケーションは、インターフェイスさえ提供されれば、特定のRDBMSに依存しない基本機能については、下位のRDBMSが何であるかを意識することなく接続できる。

　これ以外にも、データベース・システムでは、高いスケーラビリティとセキュリティが保証されることが重要である。小規模のデータから、大規模のデータまでを、実用的な速度でアプリケーションに提供できなければならない。このため例えばSQL Server 2000には、データベースの接続ユーザー数が増加したときに、ダイナミックにリソースを確保し、ユーザーがログオフするとリソースを解放する自己チューニング機能や、Windowsドメインとの統合認証機能（Windowsドメイン・コントローラでの認証結果をデータベース・アクセスにも適用する）などが提供されている。

レプリケーション

　例えば、日本全国に小売店舗網を持つ企業の販売管理システムを考えてみよう。最も単純な方法は、本社にデータベース・サーバを置き、全店舗を光ファイバなどの超高速なネットワークで接続して、すべてのデータベース・アクセスをリアルタイムで本社のサーバに接続することだ。これはつまり、閉じたLANの内部での処理に近く、構成としては理解しやすい。データベースは常に1つで情報も分散しないので、管理作業や後のデータ分析などは非常に容易である。

　しかし全国の支店を高速なネットワークで結ぶには多大なコストがかかる。昨今は安価なインターネットVPNが利用できるようになってきたとはいえ、規模も小さく販売量も少ない地方のすべての支店を接続するのは現実的ではない。遅い回線を使っても本社へのデータベース・アクセスは可能だが、あまりに遅いと店舗の業務に支障をきたす。

　このような場合に利用するのがデータベースのレプリケーション（replication）である。レプリケーション（replication）は「複製」という意味で、データベースを一時的に別のコンピュータに複製し、後で変更点を同期させることができる。

　例えばいまの例なら、店舗が閉店している深夜時間帯に本社のデータベースから、支店に必要なデータをレプリケーションとして作成し、このレプリケーションを支店のサーバに送っておく。店舗が開店したら、取りあえずは店舗内LANで店舗サーバのデータベースにアクセスし、販売処理を行う。遅い回線を使って本社にアクセスしなくてよいので高速な処理が可能だ。そして店舗が閉店したら、レプリケーションを本社のデータベースに同期させる。

　SQL Server 2000のレプリケーションでは、出版物の流通をモデルに、コンポーネントやプロセスを命名している。これらを図示すると次のようになる。

SQL Server 2000のレプリケーション・モデル
SQL Server 2000では、出版物の流通をモデルとしてレプリケーションのコンポーネントやプロセスを命名している。データはパブリッシャ（出版社）から、（必要ならば）ディストリビュータ（卸）を経由して、サブスクライバ（購読者）へ配布される。

　パブリッシャ（publisher）は「出版社」の意味で、レプリケーションの元となるデータを提供するサーバである。パブリッシャは、レプリケーションに必要なデータをパブリケーション（publication＝「出版物」）として定義する。

　パブリケーションは、データベースからの1つないし複数のアーティクル（article＝「記事」）の集合である。アーティクルは、テーブルやレプリケーション用に指定されたデータベース・オブジェクトだ。アーティクルには、テーブル全体はもちろん、特定の列のみ、特定の行のみ、ストアド・プロシージャ、定義されたビュー、ユーザー定義関数などを指定できる。図にあるとおり、複数のアーティクルをグループ化して管理することで、ひとまとまりとして複製する必要があるデータやデータ・オブジェクトのセットを定義できる。

　レプリケーションの配布を効率的に実施するために、途中にディストリビュータ（distributor＝「卸売業者」、日本の出版業界なら取次に相当するもの）を配置することもできる。そして複製されたデータを利用するシステムはサブスクライバ（subscriber＝「購読者」）と呼ばれる。

データ変換サービス（DTS：Data Transformation Services）

　複数のユーザーによる同時アクセスを前提として、データ・アクセス処理を確実に実行可能にするデータベース・システムの処理はOLTP（OnLine Transaction Processing）と呼ばれる（→用語解説）。

　一般に企業のOLTPシステムには、時代時代に導入されたさまざまなプラットフォームやテクノロジをベースとするシステムがあり、それらのシステムごとにデータベース・システムが構築されていることが多い。個々のシステムを単独で使うならこのままでも問題はないが、異なるシステムの情報を統合して評価、分析し、全社的な意思決定に用いることはできない。例えば、別々に構築された販売管理システムと生産管理システムの情報を統合して、ある商品の生産から販売までのデータを分析したいなどだ。

　このような多種多様なデータから、ビジネス上の意思決定に用いることを前提に構築されたデータベース・システムは、データウェアハウス（→用語解説）やデータマート（→用語解説）と呼ばれる。そしてこれらのデータを用いて、意思決定に必要な分析のための多角的なデータ参照手段を提供する技術がOLAP（→用語解説）である。

　複数の異なるシステムから、統合的に取り扱い可能なデータウェアハウスやデータマートを構築する手法の1つは、異なるデータベース・システムに異なる形式で保存されたデータを必要に応じて変換して、形式を共通化することだ。

　このために利用できるSQL Server 2000のコンポーネントがDTS（Data Transformation Services）である。異なる形式で保存されたデータをDTSでSQL Serverにインポート、ないしSQL Serverからエクスポートし、データウェアハウスやデータマートを構築できる。この際の変換処理は、必要に応じてインタラクティブに実行することもできるし、設定したスケジュールに応じて自動的・定期的に実行することもできる。またカスタム・プログラムを作成することで、独自のカスタムデータ移動ソリューションを構築することも可能だ。

　DTSによるデータ変換では、接続インターフェイスや変換タスク、ワークフローなどを記録したDTSパッケージを作成して実行する。具体的にこのDTSパッケージには、接続（OLE DB、ODBCインターフェイスでアクセス可能）やDTSタスク（データのインポート／エクスポート、データ変換、DBオブジェクトのコピー、Transact-SQLステートメント／ActiveXスクリプトの実行など）、DTS変換（データ型変換、日付形式変換など）、DTSパッケージ・ワークフロー（パッケージのステップ実行の順序制御。タスクが正常に完了したかどうかによって処理を分岐するなど）、カスタム・プログラムなどをパッケージ化する。

Analysis Services

　Analysis Servicesは、データウェアハウスやデータマートのデータ分析を支援するためのツール集である。理由は不明だが、SQL Serverのヘルプ・ファイルを見ると、このコンポーネントの名称は英語表記のままになっている。Analysis Servicesは、OLAPアプリケーションとOLTPデータベースの中間に位置し、データ分析のための高速なデータ・アクセスを支援する。このAnalysis Servicesを利用することで、アプリケーションからOLTPデータベースを直接参照するよりも高速なデータ参照が可能になる。OLAPの詳細についてはコラム「OLAPの基礎」を参照されたい。

　SQL Server 2000のAnalysis Servicesでは、分析を支援するウィザードやエディタなどのツールが提供される。これらにより、柔軟なデータモデルやキューブの定義が可能になる。