SQL Server 2008リリース時に日本独自にパートナー様と共同実施したCQI (Center of Quality Innovation) の成果がホワイトペーパーだけでなくさらなる有益な情報を加えて書籍となりました。日経BPソフトプレス様より順次出版とのことですので、書店等でぜひご覧いただければと思います。技術者の方にはじっくり読める書籍もまだまだ重要と位置づけております。

引き続き「大規模データウェアハウス」シナリオ検証で得られたTipsや注意点についてご紹介していきたいと思います。

今回は「緩やかに変化するディメンジョン」への対処方法について説明したいと思います。

簡単に「緩やかに変化するディメンジョン」とは何かについて触れたいと思います。DWHシナリオでは、ディメンジョンの多くが時間の経過に伴って変化します。多くの場合それらの変化はファクトデータの変化に比べて緩やかで、徐々に起きる変化を反映するディメンジョンのことを、「緩やかに変化するディメンジョン」と呼びます。この時、ディメンジョンテーブルに生じた変化にどのように対処するか、によっていくつかのパターンがあります。主なパターンは以下に分類されます。例えば以下のようなレコードがあり、場所の移転に伴って店舗名称を「代々木店」から「新宿店」に変更するケースについて各パターンを考えてみます。

店舗テーブル

1.      タイプ1

変更があったデータを、新しいデータで上書きする方法です。変更後のレコードは以下のようになります。

2.      タイプ2

変更前と変更後の両方のデータを保持し、レコードの有効/無効を判断する列を追加する方法です。レコードの有効フラグ列を追加するパターンと、レコードの開始/終了日時を追加するパターンがあります。以下の例では、開始/終了日時の列に加え、一意性を表す代替キー（サロゲートキー）の列が追加されています。

3.      タイプ3

変更のあったデータの履歴をレコード内に保持し、変更があった日付を追加する方法です。レコードのサイズにより、保持できるデータ履歴の数が制限されます。複数の列が更新されるシナリオではレコードサイズが大きくなります

4.      タイプ4

ディメンジョンテーブルは新しいデータで更新し、変更のあったレコードの履歴を別のテーブルで管理する方法です。このようにすると、保持できる履歴データの制限がなくなります。

店舗テーブル

店舗履歴テーブル

この他、全く対処しない場合（タイプ0）や、タイプ1, タイプ2, タイプ3を組み合わせたタイプ6（ハイブリッド）と呼ばれるものがあります。どのタイプを使用するべきか、についてはビジネス要件に依存します。そして、変化するディメンジョンへの対処方法によって、ディメンジョンテーブル、および、ファクトテーブルの設計に影響があります。例えばタイプ2を使用する場合はディメンジョンテーブルに、代替キーの列、および、開始/終了日時の列を追加する必要があります。加えて、ファクトテーブルのデータについても代替キーに変更する必要があります。上記の例では、ファクトデータの「店舗コード」を「店舗ID」で置き換える必要があります。

SQL ServerのIntegration Servicesを使用すると、上記のディメンジョンテーブルの変更をウィザードを利用して設定することができます。また、ファクトテーブルにおける代替キーとビジネスキーの変換も、「データフロータスク」において行うことが可能です。これらの設定方法に関する詳細は、公開予定のホワイトペーパーにて説明する予定です。今回、検証したシナリオでは変化するディメンジョンに対して、タイプ1とタイプ2を組み合わせたハイブリッド方式を採用しました。実装に関してはホワイトペーパーにて詳しく説明させて頂いているので、ここではどのようなビジネス要件が満たされるのか、簡単な例を見ていきたいと思います。

例えばファクトデータとして以下のようなレコードがあるとします。

売上テーブル

ディメンジョンを表すテーブルとして前述の店舗テーブルを使用する場合、テーブルスキーマは以下のようになります。

店舗テーブル

上記のファクトデータを店舗ごとに集計する場合、移転があった店舗をどのように集計するかが問題となります。分析観点により複数の集計方法がありますが（例えば、移転の前後で別々の店舗として売り上げを集計する、または、同一の店舗とみなして集計する）、最も多い要望は、「移転の前後で分けた場合と、同一店舗とみなした場合の両方の集計を行う」というものです。この要望は上記の店舗テーブルの「店舗名称（現）」、「店舗名称（履歴）」をディメンジョンとする事で実現できます。

集計例

どのような観点に基づいてファクトデータを分析するかによって他にも方法があると思いますが、ここでは一例を取り挙げさせていただきました。ディメンジョンの変更に対して、どの方法を用いるのが良いかはディメンジョンのデータ特性、分析観点によると思いますが（例えば、顧客テーブルにおける名前の変更は集計に影響を当たる可能性が小さいのでタイプ1で処理する等）、今回説明させていただいた内容が何かの参考になれば幸いです。

インターネットの普及とともに情報は世界レベルで発信され、特にITにおける新しいテクノロジー、モデルなどの情報は英語で記述される場合が多いのが現状です。我々はできる限り日本語での情報をオリジナルからの作成を含め、有効な情報をセレクトして翻訳・レビュー等の後提供しているのですが、やはりそのプロセスの間には人が入っており、コンテンツの品質を保つためには時間とコストがかかります。

タイムリーな情報収集には原文をできる限り読むことをお勧めしますが、英語が得意でない方は、Windows Live Translator という翻訳ツールをご利用いただくとよいかもしれません。このツールには Side-by-Sideで2つの言語を同時に表示可能な機能があり原文を比較しながら読み進めることができます。ページはダイナミックに読み込まれ、少し反映するまでに時間を要しますが、随時翻訳されたテキストに変更されていきます。選択したセンテンスをハイライト表示もできます。個人的な感想ですが、英語から日本語の自動翻訳は言語的構造がその他の欧米諸国の言語と比べて複雑なためまだまだ発展途上といえるでしょう。特に文脈や前後関係が不明な場合などは不自然で理解困難な日本語を返してきたりします。このあたりはページ内のFAQ (一部引用) を一読することをお勧めします。

SQL Server 徹底検証シリーズ、ご活用されていますか？

弊社では、SQL Server の製品出荷前から、各機能の多岐にわたる検証作業をフィールドから集めたシナリオをベースに行っています。

この検証作業は、CQI（Center of Quality Innovation）というプロジェクトで、マイクロソフト調布技術センター (東京都調布市) にて、マイクロソフトの製品開発担当部門、SE 部門、コンサルティング部門、サポート部門の各担当者およびマイクロソフトのパートナー各社との共同プロジェクトとして実施されています。

その検証結果をホワイトペーパーにまとめ、「SQL Server 2008 徹底検証シリーズ」として公開させていただいております。

既にご好評をいただいている 「コンプライアンス実現のためのガイドライン」に加え、新たに以下の３種類のホワイトペーパーを追加いたしました。

l  データベース サーバー統合実践ガイド

l  ISMS/ISO27001 コンプライアンスのためのガイドライン

l  旧バージョンからの移行とアップグレード実践ガイド

「データベースサーバー統合実践ガイド」は、分散されたデータベースサーバー環境を SQL Server 2008 に統合するための実践ガイドです。データベース サーバー統合を三種類の手法で解説しています。関連する SQL Server の各機能、性能測定の結果を解説しながら各手法のメリット、デメリットも解説しています。本シナリオは、日本ヒューレット・パッカード株式会社(日本HP)殿と共同検証を行い、その結果をホワイトペーパーにまとめたものです。一方で、現在、日本HP殿で性能測定の検証結果を詳細にまとめたホワイトペーパーを作成中です。

「ISMS/ISO27001 コンプライアンスのためのガイドライン」は、SQL Server 2008 を利用したデータベース運用環境において、情報セキュリティのマネジメント サイクルを確立し、ISMS (ISO27001) コンプライアンスを実現するためのガイドです。ISMS 規格 (ISO/IEC 27001:2005) からデータベース運用に深く関わる 31 の管理策を選んで、管理策ごとに ISMS 運用の Plan (計画)、Do (実行)、Check (評価)、Act (改善) を実現するための手順を解説しています。なお、長年 ISMS 運用に取り組まれてきた「東芝セミコンダクター社」様における SQL Server 2008 のセキュリティ運用事例も掲載しています。

「旧バージョンからの移行とアップグレード実践ガイド」は、SQL Server 2000、SQL Server 2005 で構築されたシステムを SQL Server 2008 へ移行またはアップグレードするための実践ガイドです。データベースエンジン、Analysis Services, Integration Services、Reporting Services の旧バージョンからの移行手順、性能の比較などを解説しています。

本シナリオは、日本ユニシス株式会社殿と共同検証を行い、その結果をホワイトペーパーにまとめたものです。

いずれも約数か月の期間、社内の各部門とパートナー様でバーチャルチームを編成して、検証と議論を重ねた結果をホワイトペーパーにまとめました。

ぜひ、ご活用いただければと思います。

まだ、 「大規模データ ウェアハウス実践ガイド」の作業が若干残っていて、現在、最後のレビューを行っているところです。

近日公開できると思いますので、こちらもご期待ください。

笹瀬

前回、前々回と続けてきた SQL Server 2008 からの新機能「透過的なデータ暗号化」を、他の機能の組み合わせて使うときの注意点を紹介するというテーマの最終回です。
今回は「ログ配布」、「データベースミラーリング」、「フェールオーバークラスタリング」を取り上げてみます。

それぞれ機能の基本的な動作を考えてみると、注意点や必要な事前準備を推測することができると思います。

まず「ログ配布」について考えてみます。
通常の場合は初期同期のための作業として、プライマリデータベースをセカンダリサーバーに復元します。
その際に、プライマリデータベースが暗号化されていると、セカンダリサーバーへの復元が失敗してしまいます。

次に「データベースミラーリング」の場合です。
ミラーリングの設定の事前準備として、プリンシパルサーバーのデータベースをミラーサーバーに復元しておく必要があります。
その際に、プリンシパルサーバーのデータベースが暗号化されていると(ログ配布の場合と同様に)、ミラーサーバへの復元時にエラーが発生してしまいます。

さて、この問題を回避するには、どうすればよいでしょうか?
その答えは前々回のエントリで紹介してあります。それぞれの場合の事前準備として、「ログ配布」の場合はセカンダリサーバーで、「データベースミラーリング」の場合はミラーサーバーで、サービスマスターキーの作成と証明書の復元を行っておく必要があります。
それ以外は、通常の設定方法と同じです。

最後に「フェールオーバークラスタリング」について紹介します。
フェールオーバークラスタリングが構成されている SQL Server インスタンスに暗号化されているデータベースが存在したとしても、特に事前準備はありません。
クラスタリング環境では、複数のノードのうちのいづれかひとつのノードで SQL Server インスタンスが稼働することができます。しかし、実体としてのデータベース (ユーザデータベースおよびシステムデータベース) は複数のノード分存在するのではなく、全ノードで共有しています。
そのため、サービスマスターキーや証明書も、どのノードで SQL Server インスタンスが起動しても同じものを使用していることになります。
ということで、事前に特別な考慮をすることなくクラスタ環境で暗号化されたデータベースを使用することができます。

前回のブログで記述しましたが、以下社員でチーム or 個人単位で運営するSQL Serverに関するブログのリストです。ほとんどがUS本社開発チームからの情報発信ですが、それ以外の部署やUS以外のチームもあります。ブログという性質上今回発見できなかったり、今後増えたり、何らかの理由でしばらく更新が止まっているものもあると思いますのでご了承ください。URLのほかにタイトルと補足情報を追加させていただいております。個人のブログに関してはトピックがさまざまなため実際に見ないとわからないかも知れませんが、参考にしていただければと思います。ブログはそれぞれの人間のカラーが出ますので、本当に社内にも幅広くいろいろなチーム・人がいるなと実感してます。

レプリケーションでパブリッシュしようとするデータベースが暗号化されていても、サブスクライバへレプリケートを行うときに必要となる情報は、暗号化されていない状態で distribution データベースに格納されています。
つまり、レプリケート実行時にデータを復号化する必要がないため、サブスクライバ側でのサービスマスターキーの作成や証明書のリストアは必須ではありません。また、この動作はいずれレプリケーションのタイプにも当てはまります。

といった前提のもとに、暗号化されたデータベースをレプリケートする場合の注意点は次のようになります。

注意点 1:
パブリッシャデータベースが暗号化されていたとしても、サブスクライバデータベースが自動的に暗号化されることはありません。必要に応じて個別に暗号化を行ってください。
サブスクライバの暗号化の際には、必ずしもパブリッシャと同じ証明書を使用する必要はありません。

注意点 2:
パブリッシャデータベースが暗号化されていても、スナップショットレプリケーションや他のタイプのレプリケーションの初期化時に使用されるデータベースの初期スナップショットは暗号化されていません。つまり、ネイティブ形式のファイルとして出力されていても、バイナリエディタなどで展開されてしまうと、ファイルの内容をのぞき見られてしまう危険性があります。
そのため、スナップショットファイルを配置するフォルダの権限を適切に管理することで対処する必要があります。

注意点 3:
レプリケーションに関連するサイト間の通信を、より堅牢にするためにパブリッシャ、ディストリビュータ、サブスクライバ間の伝送経路の暗号化を検討してください。

最近社内の world-wideのコミュニティにてSQL Server に関するブログ リストをまとめてくれた人がおり、マイクロソフト社員からSQL Server をメインで情報発信しているブログの数は個人を含めるとなんと60程ありました。後日、アクティブな状態を確認できたリストを公開したいと考えておりますが、今回はその中で個人的にお勧めのものをピックアップしたいと思います。

·         Microsoft SQL Server Development Customer Advisory Team (SQLCAT)

https://blogs.msdn.com/sqlcat/, https://sqlcat.com

技術系の中でDeepで常にお客様視点で活動を続ける SQLCATメンバーが運営しているブログとそのポータルです。メンバーはNASDAQに代表される大規模データベース構築を10年以上経験しているなど社内でも有名な技術者で構成されており、彼らのノウハウが集積されている Best Practice 関連の情報はお勧めです。いくつかの Best Practice Testingや最近ではTop10リストなど人気の高いコンテンツの日本語化と技術レビューに我々のチームが参加しております。日本にも頻繁に来てくれます。

·         Microsoft SQL Server News Blog - Data Platform Insider

https://blogs.technet.com/dataplatforminsider/ Microsoft's Data Platform official news

マーケティング チームが運営しているブログです。製品開発チームと常に密接に動いているチームです。技術系ではないですが、製品アップデート、イベントやプレスリリースなどに関連する情報が入手可能です。

·         Microsoft PSS SQL Support

https://blogs.msdn.com/psssql/ This is the official team Web Log for Microsoft PSS SQL Support. Posts are mostly provided by the PSS SQL Escalation Services team.

サポートチームによるブログで、主に Escalation Engineer という技術的にトップクラスのメンバーがポストしております。サポートポリシーの情報やトラブル シューティングなどの技術情報がアップされます。

その他USでの SQL Server のブログ リスト

https://technet.microsoft.com/en-us/sqlserver/bb671052.aspx

日本におけるSQL Server 最大コミュニティであるPASSJブログ

https://blogs.sqlpassj.org/

他製品も含む、マイクロソフト日本法人のブログ リスト

https://www.microsoft.com/japan/communities/blogs/default.mspx