データモデリングプロセス。図は、今日のデータモデルの開発と使用方法を示しています。概念データモデルは、開発中のアプリケーションのデータ要件に基づいて、おそらくアクティビティモデルの文脈で開発されます。データモデルは通常、エンティティタイプ、属性、関係、整合性ルール、およびそれらのオブジェクトの定義で構成されます。これは、インターフェースまたはデータベース設計の出発点として使用されます。[1]

ソフトウェアエンジニアリングにおけるデータモデリングとは、特定の形式的手法を適用して情報システムのデータモデルを作成するプロセスです。より広範なモデル駆動型エンジニアリング（MDE）の概念の一部として適用される場合もあります。

概要

データモデリングとは、組織内の対応する情報システムの範囲内で、ビジネスプロセスをサポートするために必要なデータ要件を 定義および分析するプロセスです。そのため、データモデリングのプロセスには、専門のデータモデラーが、ビジネスステークホルダーや情報システムの潜在的なユーザーと緊密に連携して取り組む必要があります。

要件から情報システムに使用される実際のデータベースに進む過程で作成されるデータモデルには、3 つの種類があります。[2] データ要件は、最初は概念データモデルとして記録されます。これは基本的に、データに関する技術に依存しない仕様のセットであり、ビジネス関係者と初期要件について話し合うために使用されます。次に、概念モデルは論理データモデルに変換されます。論理データモデルは、データベースに実装できるデータの構造を文書化します。 1 つの概念データモデルの実装には、複数の論理データモデルが必要になる場合があります。データモデリングの最後のステップは、論理データモデルを、データをテーブルに整理し、アクセス、パフォーマンス、およびストレージの詳細を考慮した物理データモデルに変換することです。データモデリングでは、データ要素だけでなく、その構造と要素間の関係も定義します。[3]

データモデリングの技術と方法論は、データをリソースとして管理するために、標準化され、一貫性があり、予測可能な方法でデータをモデル化するために使用されます。組織内でデータの定義と分析に標準的な手段を必要とするすべてのプロジェクト（例えば、データモデリングの使用）では、データモデリング標準の使用を強く推奨します。

  • ビジネスアナリスト、プログラマー、テスター、マニュアル作成者、ITパッケージセレクター、エンジニア、マネージャー、関連組織、クライアントが、組織の概念とそれらの相互関係を網羅した合意されたセミフォーマルモデルを理解し、使用することを支援します。
  • データをリソースとして管理する
  • 情報システムを統合する
  • データベース/データウェアハウス（データリポジトリとも呼ばれる）を設計する

データモデリングは、様々な種類のプロジェクトやプロジェクトの複数のフェーズで実施されます。データモデルは段階的に進化するものであり、ビジネスやアプリケーションにおける最終的なデータモデルというものは存在しません。むしろ、データモデルは変化するビジネスに応じて変化する生きた文書であると考えるべきです。理想的には、データモデルはリポジトリに保存し、時間の経過とともに取得、拡張、編集できるようにする必要があります。Whittenら (2004) は、2種類のデータモデリングを定義しました。[ 4]

  • 戦略的データモデリング：これは情報システム戦略の策定の一部であり、情報システムの全体的なビジョンとアーキテクチャを定義します。情報技術工学は、このアプローチを採用した方法論です。
  • システム分析中のデータ モデリング:システム分析では、新しいデータベースの開発の一環として論理データ モデルが作成されます。

データモデリングは、特定のデータベースに対するビジネス要件を詳細化する手法としても用いられます。データモデルは最終的にデータベースに実装されるため、データベースモデリングと呼ばれることもあります。 [4]

トピック

データモデル

データモデルがどのように利益をもたらすか。[1]

データモデルは、特定の定義と形式を提供することで、情報システム内で使用されるデータの枠組みを提供します。システム間でデータモデルが一貫して使用されることで、データの互換性が実現されます。同じデータ構造を使用してデータを保存およびアクセスすることで、異なるアプリケーション間でシームレスにデータを共有できます。この結果は図に示されています。しかし、システムとインターフェースの構築、運用、保守には多くの場合、費用がかかります。また、ビジネスを支援するのではなく、むしろ制約してしまうこともあります。これは、システムとインターフェースに実装されたデータモデルの品質が低い場合に発生する可能性があります。[1]

データ モデルでよく見られる問題は次のとおりです。

  • 特定の場所での業務遂行方法に特有のビジネスルールは、多くの場合、データモデルの構造に固定されています。これは、ビジネスの進め方における小さな変化が、コンピュータシステムやインターフェースに大きな変化をもたらすことを意味します。したがって、ビジネスルールは、複雑な依存関係を生じさせない柔軟な方法で実装する必要があります。むしろ、データモデルは、ビジネスの変化を比較的迅速かつ効率的にデータモデル内に実装できるほど柔軟である必要があります。
  • エンティティタイプはしばしば識別されない、あるいは誤って識別されます。これは、データ、データ構造、機能の重複につながり、開発と保守においてその重複に伴うコストの増加につながります。したがって、誤解や重複を最小限に抑えるため、データ定義は可能な限り明確かつ分かりやすく作成する必要があります。
  • 異なるシステムのデータモデルはそれぞれ異なります。その結果、データを共有するシステム間では複雑なインターフェースが必要になります。これらのインターフェースは、現在のシステムコストの25～70%を占める場合があります。データモデルを設計する際には、必要なインターフェースを本質的に考慮する必要があります。異なるシステム間でインターフェースがなければ、データモデル単体では使用できないためです。
  • データの構造と意味が標準化されていないため、顧客やサプライヤーと電子的にデータを共有することができません。実装されたデータモデルから最適な価値を引き出すには、データモデルがビジネスニーズを満たし、一貫性を保つことを保証する標準を定義することが非常に重要です。[1]

概念的、論理的、物理的なスキーマ

ANSI/SPARCの3階層アーキテクチャ。これは、データモデルが外部モデル（またはビュー）、概念モデル、物理モデルのいずれかであることを示しています。これはデータモデルを見る唯一の方法ではありませんが、特にモデルを比較する際には便利な方法です。[1]

1975年にANSIは3種類のデータモデルインスタンスを定義した。[5]

  • 概念スキーマ：ドメイン（モデルの適用範囲）のセマンティクスを記述します。例えば、組織や業界の関心領域のモデルなどが考えられます。これは、ドメインにおける重要な事柄の種類を表すエンティティクラスと、エンティティクラス間の関係性に関する関係アサーションで構成されます。概念スキーマは、モデルを用いて表現できる事実や命題の種類を指定します。つまり、モデルの範囲によって制限される適用範囲を持つ人工的な「言語」で、許容される表現を定義します。簡単に言えば、概念スキーマはデータ要件を整理するための最初のステップです。
  • 論理スキーマ：情報のある領域の構造を記述する。これは、例えば、表、列、オブジェクト指向クラス、XMLタグなどの記述から構成される。論理スキーマと概念スキーマは、同一のものとして実装されることもある。[2]
  • 物理スキーマ：データを格納するために使用される物理的な手段を記述します。パーティション、CPU、表領域などがこれに該当します。

ANSIによれば、このアプローチにより、3つの観点は互いに比較的独立していられます。ストレージ技術は、論理スキーマにも概念スキーマにも影響を与えることなく変更できます。テーブル/列構造は、概念スキーマに（必ずしも）影響を与えることなく変更できます。もちろん、いずれの場合も、構造は同じデータモデルのすべてのスキーマ間で一貫性を保つ必要があります。

データモデリングプロセス

ビジネスプロセス統合におけるデータモデリング[6]

ビジネスプロセス統合の文脈では（図を参照）、データモデリングはビジネスプロセスモデリングを補完し、最終的にはデータベースの生成につながります。[6]

データベース設計プロセスには、前述の3種類のスキーマ（概念スキーマ、論理スキーマ、物理スキーマ）の作成が含まれます。これらのスキーマに記述されたデータベース設計は、データ定義言語（DDL）を介して変換され、データベースを生成するために使用できます。完全に属性付けされたデータモデルには、その中のすべてのエンティティの詳細な属性（記述）が含まれます。「データベース設計」という用語は、データベースシステム全体の設計における様々な部分を指すことができます。主に、そして最も正確には、データの格納に使用される基本データ構造の論理設計と考えることができます。リレーショナルモデルでは、これらはテーブルとビューです。オブジェクトデータベースでは、エンティティとリレーションシップは、オブジェクトクラスと名前付きリレーションシップに直接マッピングされます。ただし、「データベース設計」という用語は、基本データ構造だけでなく、データベース管理システム（DBMS）内のデータベースアプリケーション全体の一部として使用されるフォームやクエリも含めた、設計プロセス全体を指す場合もあります。

このプロセスにおいて、システムインターフェースは現行システムの開発・サポートコストの25%から70%を占めています。このコストが発生する主な理由は、これらのシステムが共通のデータモデルを共有していないことです。システムごとにデータモデルを開発すると、重複する領域で同じ分析を繰り返すだけでなく、システム間のインターフェースを作成するためにさらなる分析を行う必要があります。組織内のほとんどのシステムは、特定の目的のために再開発された同じ基本データを含んでいます。したがって、効率的に設計された基本データモデルは、組織内の異なるシステムの目的に合わせた最小限の変更で、手戻りを最小限に抑えることができます[1] 。

モデリング手法

データモデルは、関心のある情報領域を表します。データモデルの作成方法は数多くありますが、Len Silverston (1997) [7]によれば、トップダウンとボトムアップの2つのモデリング手法が際立っています。

モデルは、アプリケーションのデータニーズと構造を考慮した手法と、サブジェクトエリアモデルを一貫して参照する手法の2つの手法を組み合わせて作成されることがあります。多くの環境では、論理データモデルと物理データモデルの区別は曖昧です。さらに、一部のCASEツールでは、論理データモデルと物理データモデルが区別されていません。[7]

実体関連図

IDEF1X自体をモデル化するために用いられるIDEF1Xエンティティ・リレーションシップ図の例。ビューの名前はmmである。ドメイン階層と制約も与えられている。制約はメタモデルの形式理論において文として表現されている。[8]

データモデリングにはいくつかの表記法があります。実際のモデルは、データ内に記述されたエンティティとリレーションシップの観点からデータを描写するため、「エンティティ・リレーションシップ・モデル」と呼ばれることがよくあります。[4]エンティティ・リレーションシップ・モデル（ERM）は、構造化データの抽象的な概念表現です。エンティティ・リレーションシップ・モデリングは、リレーショナル・スキーマ・データベース・モデリング手法であり、ソフトウェアエンジニアリングにおいて、システム（多くの場合、リレーショナル・データベース）とその要件の概念データモデル（またはセマンティック・データモデル）をトップダウン方式で作成するために使用されます。

これらのモデルは、情報システム設計の第一段階である要件分析において、情報ニーズやデータベースに保存される情報の種類を記述するために使用されます。データモデリング技術は、特定の論説領域、すなわち関心領域におけるあらゆるオントロジー（使用される用語とその関係性の概要と分類）を記述するために使用できます。

データモデルの設計には、いくつかの手法が開発されています。これらの方法論はデータモデラーの作業の指針となる一方で、同じ方法論を用いても、異なる人が全く異なる結果を出すことがよくあります。特に注目すべきものは以下のとおりです。

汎用データモデリング

汎用データモデルの例。[9]

汎用データモデルは、従来のデータモデルを一般化したものです。汎用データモデルは、標準化された一般的な関係型と、そのような関係型によって関連付けられる可能性のあるものの種類を定義します。汎用データモデルの定義は、自然言語の定義に似ています。例えば、汎用データモデルは、「分類関係」（個々のものとその種類（クラス）との間の二項関係）や、「部分全体関係」（関連するものの種類に関係なく、一方が部分の役割を持ち、もう一方が全体の役割を果たす2つのものの間の二項関係）などの関係型を定義します。

拡張可能なクラスのリストが与えられれば、あらゆる個々の事物を分類し、あらゆる個々のオブジェクト間の部分と全体の関係を規定することが可能になります。拡張可能な関係タイプのリストを標準化することで、汎用データモデルは無制限の数の事実の種類を表現できるようになり、自然言語の能力に近づきます。一方、従来のデータモデルは、モデルのインスタンス化（使用）において、モデル内で事前に定義された事実の種類しか表現できないため、ドメインスコープが固定され、限定されています。

セマンティックデータモデリング

DBMSの論理データ構造は、階層型、ネットワーク型、リレーショナル型を問わず、データの概念的定義の要件を完全に満たすことはできません。なぜなら、その範囲は限定的であり、DBMSが採用する実装戦略に偏っているからです。これは、データベースに意図的にセマンティックデータモデルを実装しない限り当てはまります。セマンティックデータモデルを実装することで、パフォーマンスに若干の影響が出る可能性はありますが、一般的には生産性が大幅に向上します。

セマンティックデータモデル[8]

したがって、データを概念的な観点から定義する必要性から、セマンティックデータモデリング技術が開発されました。これは、他のデータとの相互関係という文脈の中でデータの意味を定義する技術です。図に示されているように、リソース、アイデア、イベントなどといった実世界は、物理的なデータストア内の記述によって象徴的に定義されます。セマンティックデータモデルは、格納されたシンボルが実世界とどのように関連するかを定義する抽象化です。したがって、モデルは実世界の真の表現でなければなりません。[8]

セマンティックデータモデリングの目的は、「談話空間」と呼ばれる現実世界の一部の構造モデルを作成することです。そのために、3つの基本的な構造関係が考慮されます。

  • 分類/インスタンス化: ある程度の構造的類似性を持つオブジェクトはクラスのインスタンスとして記述される
  • 集約/分解: 構成要素を結合することで構成されたオブジェクトが得られる
  • 一般化/特殊化: 共通の性質を持つ異なるクラスは、共通の属性を持つより一般的なクラスとして再考されます。

セマンティックデータモデルは、次のような多くの目的に使用できます。[8]

  • データリソースの計画
  • 共有可能なデータベースの構築
  • ベンダーソフトウェアの評価
  • 既存データベースの統合

セマンティックデータモデルの全体的な目標は、関係概念と人工知能分野で知られるより強力な抽象概念を統合することで、データの意味をより深く捉えることです。その考え方は、現実世界の状況の表現を容易にするために、データモデルの不可欠な要素として高水準のモデリングプリミティブを提供することです。[10]

参照

参考文献

  1. ^ abcdef Matthew WestとJulian Fowler (1999). 高品質データモデルの開発 Archived September 9, 2020, at the Wayback Machine . 欧州プロセス産業STEP技術連携事務局 (EPISTLE).
  2. ^ ab シミソン、グレアム・C. & ウィット、グレアム・C. (2005).データモデリングの基礎. 第3版.モーガン・カウフマン出版社. ISBN 0-12-644551-6
  3. ^ データ統合用語集、Wayback Machineで 2009 年 3 月 20 日にアーカイブ、米国運輸省、2001 年 8 月。
  4. ^ abc Whitten, Jeffrey L. ; Lonnie D. Bentley , Kevin C. Dittman . (2005).システム分析と設計手法. 第6版. ISBN 0-256-19906-X。
  5. ^ アメリカ規格協会. 1975. ANSI/X3/SPARCデータベース管理システム研究グループ; 中間報告書. FDT (ACM SIGMOD 速報) 7:2.
  6. ^ ab Paul R. Smith & Richard Sarfaty (1993). コンピュータ支援ソフトウェアエンジニアリング（CASE）ツールを用いた構成管理のための戦略計画の作成. 1993年米国エネルギー省（DOE）／請負業者・施設CAD/CAEユーザーズグループ向け論文.
  7. ^ abcd Len Silverston, WHInmon, Kent Graziano (2007). The Data Model Resource Book . Wiley, 1997. ISBN 0-471-15364-8tdan.comのVan Scottによるレビュー。2008年11月1日にアクセス。
  8. ^ abcd FIPS Publication 184 Archived December 3, 2013, at the Wayback Machine releases of the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). December 21, 1993.
  9. ^ Amnon Shabo (2006). 薬理遺伝学と薬理ゲノミクスのための臨床ゲノミクスデータ標準 Archived July 22, 2009, at the Wayback Machine .
  10. ^ 「セマンティックデータモデリング」『メタクラスとその応用』。書籍シリーズ『Lecture Notes in Computer Science』。出版社：Springer Berlin / Heidelberg。巻：943/1995。

さらに読む

  • テル・ベッケ、ヨハネス・ヘンドリックス（1991年6月4日）。リレーショナル環境におけるセマンティック データ モデリング(PDF) (博士論文)。デルフト工科大学。2025 年 4 月 2 日のオリジナルからアーカイブ(PDF) 。2025 年4 月 2 日に取得。
  • John Vincent Carlis、Joseph D. Maguire (2001). 『データモデリングの習得：ユーザー主導型アプローチ』
  • Alan Chmura、J. Mark Heumann (2005).論理データモデリング：その概要と実践方法.
  • Martin E. Modell (1992).データ分析、データモデリング、分類.
  • M. Papazoglou、Stefano Spaccapietra、Zahir Tari (2000).オブジェクト指向データモデリングの進歩.
  • G. ローレンス・サンダース (1995).データモデリング
  • グレアム・C・シムシオン、グレアム・C・ウィット（2005年）『データモデリングの基礎』
  • マシュー・ウェスト（2011）高品質なデータモデルの開発
ウィキメディア コモンズには、データ モデリングに関連するメディアがあります。
  • アジャイル/進化型データモデリング
  • データモデリング記事 2010年3月7日アーカイブ、Wayback Machine
  • UMLによるデータベースモデリング
  • データモデリング101
  • セマンティックデータモデリング
  • システム開発、方法論、モデリング アーカイブ 2012年3月7日、Wayback Machineトニー・ドリューリーによるメモ
  • 提案依頼書 - オブジェクト管理グループの情報管理メタモデル (IMM)
  • データモデリングはDBMSだけのものではありません パート1 クリス・ブラッドリー
  • データモデリングはDBMSだけのものではありません パート2 クリス・ブラッドリー