データモデルの設計とベストプラクティス(第1部)

データモデルの設計とベストプラクティス(第1部)

  • Dale Anderson
    Dale Anderson is a Customer Success Architect at Talend. Over a 30 year career, Mr. Anderson has gained extensive experience in a range of disciplines including systems architecture, software development, quality assurance, and product management and honed his skills in database design, modeling, and implementation, as well as data warehousing and business intelligence. A keen advocate for an appropriate temperance of the software workflow process, he has applied his innovations to the often overlooked lifecycle of a database. The Database Development Lifecycle Mr. Anderson has developed incorporates data modeling best practices to address the complexities involved in modeling adaptations, multi-environment fulfilments, fresh installations, schema upgrades, and data migrations for any database implementation.

ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります(または、そうあるべきです)。この点を常に念頭に置きましょう。あるいは、(よく見られることですが)完全に無視することがないように注意してください。

データモデルこそが、Eコマースから、PoS、財務、製品、顧客管理、ビジネスインテリジェンス、IoTまで、Talendの高価値でミッションクリティカルのビジネスソリューションのほとんどすべての支柱です。適切なデータモデルがなければ、ビジネスデータはおそらく失われてしまうでしょう!

Talendのジョブ設計パターンとベストプラクティスについて取り上げたブログシリーズ(第1部第2部第3部第4部)では、32のベストプラクティスを紹介し、Talendでジョブを構築する最善の方法について述べました。その中で予告したデータモデリングについて、以下に述べたいと思います。

データモデルとデータモデリングの方法論は、ずっと以前(コンピューティングが始まった頃)からありました。構造は、データが意味を成すために必要であり、コンピューターが実際に処理するうえでの一手段を提供します。確かに、今日では非構造化データや半構造化データも処理されるようになっています。しかし、それは単に、一層洗練された規範へとデータ処理が進化したことを意味するだけではないでしょうか。したがって、データモデルの意義は現在も変わるものではなく、高度なビジネスアプリケーションを構築するための基盤となっています。Talendのベストプラクティスと同様、データモデルとデータモデリングの手法にも真剣に向き合う必要があります。

ダウンロード >> Talend Open Studio for Data Integration

新たな洞察を得るべく、データモデリングの歴史を振り返ってみましょう。

データモデルの進化

「コンピューティングの暗黒時代」には、フラットなレコードのレイアウト(配列)が使用され、すべてのデータは後で取得できるようにテープや大規模ディスクドライブに保存されていました。しかし、1958年に、J. W. YoungとH. K. Kentが、情報システムのモデリングは「データ処理の問題の情報的かつ時間的特徴を規定するための正確で抽象的な方法」であると論じました。その後すぐに(1959年)、CODASYLConference/Committee on Data Systems Languages)というコンソーシアムがミネソタ大学のチャールズ・バベッジ研究所により結成されました。これを契機として、COBOLのような標準プログラミング言語が作成され、1960年代にはGE/Honeywell社でIntegrated Data Store(IDS)という初期のデータベーステクノロジーがチャールズ・バックマンによって設計されました。IDSは使いにくいものであったため、Integrated Database Management System(IDMS)がB. F. Goodrich(米国のタイヤメーカーですが、当時は航空宇宙製造企業)により開発され、Cullinane Database Systemsにより販売されました(現在はComputer Associatesが所有)。これら2つのデータモデリングの方法論は、それぞれ「階層型データモデル」と「ネットワーク型データモデル」と呼ばれ、50年にわたってメインフレームコンピューティングで広く使用されてきました。現在でも使用しているケースがあります。

1960年代末、当時IBM社の社員だったエドガー・F・コッドは、クリス・J・デイト(『An Introduction to Database Systems』の著者)と協力し、自身の革新的なデータモデリング理論を確立して、1970年に「A Relational Model of Data for Large Shared Data Banks(大規模共有データバンクのデータ関係モデル)」という論文を発表しました。コッドは、ベンダーが方法論を正しく実装できるよう推進するため、1985に有名な「Twelve Rules of the Relational Model(リレーショナルモデルの12の規則)」を発表しました。これは、実際には規則0から規則12まであり、13の規則です。コッドは、当時のコンピューター領域で明らかに卓越した知識を持っていました。リレーショナルモデルは、「正規化」の概念ももたらし、「5つの正規形」が定義されました。現在でも「3NF」(第3正規形)について広く議論されていますが、その定義方法をご存知でしょうか。これら2つのリンクを読み進めて、自分の知識が確かなものか確認できます。最後にクイズもあります...というのは冗談です。

次に登場した画期的なデータモデリング方法論は、1996年にラルフ・キンボール現在は引退)によって、「The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling(データウェアハウスツールキット:多次元モデリングのための完全ガイド)」(マーギー・ロスとの共著)で提唱されました。広く採用されたキンボールのスタースキーマモデルは、1970年にビル・インモン(2007年にComputerworldがコンピューティング史初期40年で最も大きな影響を及ぼした10人に選出)が最初に提案したデータウェアハウス規範で示された概念を応用したものです。インモンが1991年に発表した「Building the Data Warehouse(データウェアハウスの構築)」は、あらゆるデータウェアハウスコンピューティングにおけるデファクトスタンダードとなりました。データウェアハウスの実装における適切なアプローチについては、インモンとキンボールの見解が一致しないこともありましたが、Kimball Groupのマーギー・ロスは、「Differences of Opinion(意見の相違)」と題する記事で公正かつバランスのとれた説明を展開しており、一読に値します。

最近になって新たに登場した強力なデータモデリング方法論が、データボルトです。考案者のダン・リンステット(Dan Linstedt)は、1990年にデータボルトを着想し、2001年にパブリックドメインに著作を公開しました。データボルトモデルは、インモンとキンボールの主張における多くの競合を解決し、データ履歴のリネージを取り入れ、適応性/監査性/拡張性の高い規範を提供しており、非常に大きな改善です(私見ですが)。これについては、私のブログ「"データボルト"とは?その必要性とは?」もぜひお読みください。リンステットのデータボルトは、米国の国防総省、国家安全保障局、さらには企業のいくつかの重要なプロジェクトで非常に高い価値を発揮しています。2013年にリンステットが発表したData Vault 2.0は、ビッグデータ、NoSQL、非構造化データ、半構造化データの統合、その使用方法に関するSDLCのベストプラクティスを提示し、時宜を得たものとなっています。このような経緯をたどり、データモデルの方法論は現在に至っています。

データモデルの概要

これまでに提唱されてきたデータモデリングの方法論は、次のように簡単にまとめることができます。

  • フラットモデルデータ要素の単一の2次元配列
  • 階層型モデルフィールドとセットを含むレコードが、親子の階層を定義
  • ネットワーク型モデル階層型モデルに似ており、分岐の「リンク」テーブルのマッピングを使用して1対多の関連を許可
  • リレーショナルモデルとりうる値と値の組み合わせへの制約を記述する、有限の述語変数を超える述語の集合
  • スタースキーマモデル正規化されたファクトテーブルとディメンションテーブルが、データ集約のためにカーディナリティ度の低い属性を排除
  • データボルトモデルハブ、サテライト、リンクテーブルを使用して、複数のデータソースから長期の履歴データを記録

データベース開発ライフサイクル — DDLC

今日の議論は、データの複雑さと非常に大きなボリュームに集中しています。それも確かに重要なことですが、データモデルも重要トピックとして討議すべきであることを改めて強調したいと思います。要件の進化に伴ってスキーマ(データモデル)の進化や主導が求められており、いずれの場合も管理が必要とされます。そこで役立つのがデータベース開発ライフサイクルです。

データが関与するそれぞれの環境(開発/テスト/実稼働のような)向けに、開発者はコードをその必然的構造変化に対応/適応させる必要があります。ソフトウェア開発ライフサイクル(SDLC)と同様、データベースも適切なデータモデル設計とベストプラクティスを取り入れるべきです。私は、これまで多くのデータモデルを設計する中で、以下のような明確な教訓を得ました。

  • 適応性機能強化や修正に対応するスキーマを作成すること
  • 拡張性予想以上に拡大するスキーマを作成すること
  • 基本性特性/機能性を実現するスキーマを作成すること
  • 移植性異なるシステムでホスト可能なスキーマを作成すること
  • 活用ホストテクノロジーを最大限活用するスキーマを作成すること
  • 効率的なストレージスキーマのディスクフットプリントを最適化すること
  • 高いパフォーマンス優れたパフォーマンスを提供する最適化されたスキーマを作成すること

設計に関するこれらの教訓は、相反することもあるモデリング方法論のいずれを選択する場合も、それぞれの本質的要素に対応します。私の経験では、これらの違いにかかわらず、データモデルのライフサイクル全体を以下の3段階に分けることができます。

  • 新規インストールスキーマの現行バージョンに基づく
  • アップグレードの適用データベースオブジェクトをドロップ/作成/変更し、あるバージョンから次のバージョンへとアップグレード
  • データ移行中断を伴う「アップグレード」が発生(テーブルやプラットフォームの分割など)

データモデルの設計には、代償を求めない自発性が求められることもあり、細心の注意と同時に曖昧さを抽象化する創造力を伴います。私は個人的に難解なスキーマに惹かれ、修正すべき部分を探しますが、これらの問題は以下のようにさまざまな形で顕在化します。

  • χ 複合プライマリーキー:効果的であったり適切であったりすることはほとんどないため、避けましょう。データモデルによっては例外もあります。
  • χ 不正なプライマリーキー:通常、日付時刻や文字列(GUIDやハッシュを除く)は不適切です。
  • χ 不正な索引化:少なすぎる、または多すぎるのいずれかです。
  • χ 列のデータ型:整数のみが必要な場合、特にプライマリーキーでは、長整数(または大整数)を使用しないでください。
  • χ ストレージ割り当て:データサイズと成長の可能性を考慮しません。
  • χ 循環参照:テーブルAがテーブルBと関係を持ち、テーブルBがテーブルCと関係を持ち、そしてテーブルCがテーブルAと関係を持つ状況であります。これは、単純に設計の問題であると思います。

次に、データベース設計のベストプラクティスとして、データモデルの設計とリリースのプロセスについて検討します。データモデルを作成する際は、次のような規定プロセスに従うべきでしょう。

多くの人にとっては自明のことでしょうが、このプロセスを採用することの重要性を強調しておきます。スキーマの変更は避けられませんが、ソフトウェア開発プロジェクトの早い段階で確実なデータモデルを確立することが肝心です。アプリケーションコードへの影響を最小限に抑えることは、ソフトウェアプロジェクトを成功させるためには間違いなく望ましいことです。スキーマの変更は大きなコストを伴う命題になることもあるため、データベースのライフサイクルとその役割を理解することが非常に重要になります。データベースモデルのバージョン管理は重要です。グラフィカルな図を使用して、設計を説明しましょう。「データ辞書」や「用語集」を作成し、経時的変更についてリネージを追跡します。これはより高次の規律ですが、役立ちます!

データモデリングの方法論

データモデルの進化、そして設計で採用するベストプラクティスを理解することは、ほんの始まりに過ぎません。トランザクション(OLTP)アナリティクス(OLAP)の両方のモデルでデータベースアーキテクトとして活動した経験から、上記に挙げた最初の3つのステップが作業の約8割を占めることがわかりました。これについて、次に検討しましょう。

データモデルの構築は、簡素または小規模であるために容易なこともあれば、反対に複雑さ、多様性、データの規模や形状、企業内での使用場所などにより非常に困難になることもあります。データの内容と場所、データを使用するアプリケーション/システムとの相互の影響、そもそもデータがそこに存在する理由について、早期に理解するする必要があります。誰が何を必要としているか、それをどのように提供するかを見極めるのは簡単ではありません。堅実なデータモデルであることを確実に明らかにすることが目標となります。最適なデータモデリング方法論の選択は非常に重要です。

データモデルのビジネス価値

TalendのETL/ELTジョブはデータの読み書きのために記述されます。これは、明らかにビジネスに価値をもたらすためです。それでは、なぜデータモデルが必要となり、どのような目的で役立つのでしょうか。また、単純に処理するだけではいけないのでしょうか。技術的観点からは、データモデルはデータフローを操作するための構造を与えます。データモデルのライフサイクルは、ジョブ設計、パフォーマンス、およびスケーラビリティに直接影響します。しかも、厳密に言うと、これは氷山の一角にすぎません。また、ビジネスの観点はさらに抽象的です。何よりも、データモデルはビジネス要件を検証します。システム統合とビジネスで使用されるデータの構造的制御のための重要な定義を提供し、それによって多様な機能上/運用上の原則を保証します。データモデルなしでは、ビジネスの効率性が完全に損なわれると思いますが、皆さんはどのようにお考えでしょうか。

まとめ

データモデルとTalendのようなツールがなければ、データはビジネス価値を提供することに完全に失敗します。場合によっては、不正確さ、誤用、誤解によってビジネスの成功を妨げかねません。私の経験では、明確に定義されたデータモデルとDDLCのベストプラクティスを使用することで、データのビジネス価値が加速・増大します。

本シリーズの第2部では、論理データモデルと物理データモデルの基本と価値について説明します。また、まず全体論的な観点から、次に概念的な詳細を切り離して、データを区別する方法を拡張し、そのうえで論理的設計と物理的設計を検討します。これらは、データの理解を深め、データをモデル化し、データベース設計のモデルを検証するために役立ちます。

それまでの間、ここで提供した情報について検討してください。コメントや質問をお待ちしています。提示されている原則についても討論してください。

第2部はこちら

ダウンロード >> Talend Open Studio for Data Integration

ディスカッションに参加

0 Comments

コメントを残す

Your email address will not be published. Required fields are marked *