月別: May 2019

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

データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知しているTalendの開発者は、以下のようにデータモデルを定義しています。 ビジネスシステムデータの構造的定義 ビジネスデータのグラフィカルな表現 ビジネスソリューションを構築するためのデータ基盤 これらはいずれも真実かもしれません。しかしあえて言うなれば、いずれも本質的な定義ではありません。それぞれ単独では、データモデルが本来実現すべき核心/目的あるいは目標に到達するものではなく、末梢的であるためです。 では、何が本当にデータモデルであると言えるのでしょうか。あれこれ思いつくものの、やはり一点に尽きるのではないでしょうか。私にとって、データモデルは、ビジネス情報システムをグラフィカルな方法で明確に特徴付けるものとして表現される構造基盤です。どう思われますか? 上記の定義と同一というわけではありませんね。この定義は、すべての要素を単一の目的に包含します。つまり、データだけでなく、構造的にビジネスのユースケースに関する情報を識別するための手段なのです。 このブログシリーズの第1部では、50年間のデータモデリングの歴史を4つの短い段落にまとめました。省いた部分もありますが、前任者から学んだ教訓と改善の結果として、データモデリングに関する私たちの知識や達成がどのように実現したのかを理解できるのではないでしょうか。今日、ほとんどの企業が要件を検証するために活用してるデータモデルには、真のビジネス価値があります。しかし、これらの企業が正しい方法を理解しているかどうかを疑問に思うことがよくあります。多くの場合、永続性のあるデータモデルに対する幻想は、とりあえずモデルが存在するという事実のみによって推定され、それが正しいかどうかは確認または検証されていないのです。 私は、データアーキテクチャーとデータベース設計の実務家として、あまりにも多くの粗悪なデータモデルを目にしてきたため、ほとんどのデータモデルには何らかの問題があると言わざるを得ません。その一方で優れたモデルも多く見てきましたが、それではデータモデルの良し悪しをどのように判断できるのでしょうか。それは重要なことなのか、データの出入りに問題がなければ十分ではないのか、と疑問に思われるかもしれません。しかし、データモデルの良し悪しは明らかに重要なのです。データモデルを基盤として/データモデルと協調して運営されるビジネスシステムを確実に成功させるためには、データモデル自体が優れたものである必要があります。データモデルはビジネスの本質です。したがって、包括的であり、非の打ちどころがなく、回復力のあるものでなければなりません。 このことから、優れたデータモデルを使用する動機は明らかです。Talend StudioのようなETL/ELTツールを使ってデータを出し入れし始めると、それが明らかになります(ほとんどの人には)。どのようなソフトウェアプロジェクトでも、データモデルは欠かすことのできない3つの技術的要素の1つです。ほかの2つの要素は、アプリケーションコードとユーザーインターフェイスです。 本シリーズの第1部では、私が設計するすべてのデータモデルで採用されているデータベース開発ライフサイクル(DDLC)の方法論を取り上げましたが、お読みいただいたでしょうか。この方法論は私にとって役立つものであり、データベース開発に本気で取り組んでいるすべてのチームはぜひとも採用すべきです。このプロセスを理解して採用することで、データモデルの実装と保守を合理化/自動化/改善できます。しかし、このプロセスについては、ほかの事柄も検討する必要あります。ビジネスに貢献する信頼性、柔軟性、正確性を備えたデータモデルを促進できる、追加のベストプラクティスをご紹介します。 データモデリングのベストプラクティス 多くのデータモデルは、モデラーが論理モデルを作成してから物理モデルを作成するプロセスによって設計されます。通常、論理モデルは実体と属性、および両者を結び付ける関係を記述して、データのビジネス目的を明確に表現します。続いて、物理モデルは論理モデルを実装します(論理モデルは、テーブル、列、データ型、索引として、簡潔なデータ整合性規則と共に実装されます)。これらの規則は、プライマリーキーと外部キー、およびデフォルト値を定義します。さらに、必要に応じて実装をサポートするために、ビュー、トリガー、ストアドプロシージャーが定義されることがあります。物理モデルは、ほとんどのホストシステム(Oracle、MS SQL Server、MySQLなど)が提供する特定の構成オプションに基づいて、ディスク上のストレージ割り当ても定義します。 納得できることですね。それにもかかわらず、私は論理モデルと概念モデルの違いをめぐる激しい議論を何度も経験してきました。多くの人は、これら2つは同じであり、どちらもビジネスデータの実体と属性を提示するものであると言います。私も同意見です!概念モデルは、データに対するビジネス上の理解(技術的な理解ではありません)についてコンテキストを提供することを目的とします。概念モデルはすべてのステークホルダーが理解できるものであり、多くの人が実体と属性に取り組んでいます。適切な概念モデルは、すべての関係者にとってビジネスデータのコミュニケーションのために最善のツールになります。統一モデリング言語(UML)の側面を使用することで、概念モデルを図解して、細かい事柄にとらわれずにシンプルに保持できます。詳細は論理モデルと物理モデルで不可欠ですが、それぞれで洗練させればよいでしょう。 一般的に多くのアプリケーションシステムを使用しているエンタープライズビジネスでは、データのモデル化で高次の懸念が生じます。概念モデル、論理モデル、物理モデルだけでは十分ではありません。そこで登場するのが、全体論的データモデル(少なくとも、私がそれを改造したモデル)です! 全体論的データモデルの目的は、企業全体でデータサイロを識別・抽象化することです。これにより、データサイロが存在する場所、必要な場所、相互に関連する場所、そして最も効果的に使用するために体系づける方法を大局的に説明します。 データモデリングプロセスの4つの階層 企業内に4タイプの異なるデータモデルが存在する可能性を考慮して、定義、理解の洗練化、および具体的な設計のために、「階層」としてトップダウン型で従うデータモデリングプロセスを次のように提案します。各レベルの主要な役割については、プロセスのどこで誰が関与したかを明確にします。 全体論的データモデル: 全体論的な層は、全社的なデータサイロの抽象的な環境を表します。このデータモデルは、広範なビジネスデータガバナンスを確立する機会を生み出し、それによって企業に固有のすべてのデータ関係に対する理解を深めることができます。それらのサイロは、社内外のアプリケーションからのデータを取り込むことを目的としています。バブルチャートを使用すると、全体論的データモデルを図解できます。以下のように設計します。 バブルチャート – データサイロ バブルチャートは、一意のデータサイロを表す単純なバブルで構成されます。2つ(2つだけ)のバブルを結ぶ線(「リンク」)は、2つの間に何らかの関係が存在することを示します。基本的には、バブルの各集合(多くの場合、放射状の「スポーク」を持つ中心の「ハブ」として示されます)は、企業全体で識別された特定のデータサイロのセットを具体化するものであり、それ以上でもそれ以下もありません。要素の詳細は以下のとおりです。 青色の実線で表されたリンクは、2つのデータサイロ間の直接的な関係を示します。赤色の破線で表されたリンクは、2つのデータサイロ間の間接的な関係を示します。緑色の点線で表されたリンクは、2つのデータサイロ間の拡張された関係を示します。これらのリンクは、複数の関係(概念層で定義)を表すことがあるため、主観的に使用します。単に関係が存在すると定義します。 バブルの周囲を、より大きいバブルが囲むことがあります。大きい方のバブルは、そのデータサイロに固有の分類を体系化するオントロジーが存在する(または存在すべきである)ことを意味します。オントロジーとその分類メタデータは、それが囲むサイロへの有意義なマッピングを提供します。これは、データを高度に検索可能にするのに大いに役立つものであり、この層で識別されるべきです。 バブルチャートは、ビジネス情報の特定の集合を定義します。その目的は、サポート対象のアプリケーション、実装または技術的詳細がない情報を識別、単純化、統合することです。全体論的データモデルのメリットは、すべてのオーディエンスが単一の包括的かつ単純化されたビューで企業データ環境を理解でき、基盤となるデータモデルをほとんど/まったく中断することなく新しいデータを識別してモデルに挿入する(後述)ための柔軟な出発点を提供できることです。 ここに示したのは、完全に定義された全体論的データモデルの図解の一例です。プリンターで大きく印刷して壁に貼り、皆で検討することで、活発で生産的な会話が生まれ、それがビジネスにとって効果的で価値ある資産になります。 概念データモデル: 概念層は、ビジネスデータ要素とそれらの関係の抽象的な定義を表します。このデータモデルは、アプリケーションの観点から企業データ環境のセマンティクスを定義し、これによって基盤となるビジネス情報の理解が深まります。UMLは、このモデルを設計するためのグラフィカルな手段となります。要素オブジェクトから成る概念データモデルは、全体論的モデルのデータサイロから抽出された情報クラスを定義します。基本的には、これを情報モデルと考えることができます。以下のように設計します。 UML情報アーキテクチャー >各要素オブジェクトは、データサイロの特定部分と、2つ(やはり2つだけ)の要素間の関係を定義する接続線(「リンク」)をカプセル化します。特定の要素項目(「特性」)は、オブジェクトの理解と目的をさらに支援するために定義され、以下のいずれかになります。> 保護(値は事前に決定) パブリック(値は可変)