データモデリング

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

概要

データモデリングは、組織内の対応する情報システムの範囲内でビジネスプロセスをサポートするために必要なデータ要件を定義および分析するために使用されるプロセスです。したがって、データモデリングのプロセスには、ビジネス関係者や情報システムの潜在的なユーザーと緊密に連携する専門のデータモデラーが関与します。

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

データモデリングのテクニックと方法論は、データをリソースとして管理するために、標準的で一貫性のある予測可能な方法でデータをモデリングするために使用されます。データモデリングの使用など、組織内でデータを定義および分析するための標準的な手段を必要とするすべてのプロジェクトでは、データモデリング標準の使用を強くお勧めします。

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

データモデリングは、さまざまな種類のプロジェクトやプロジェクトの複数のフェーズで実行できます。データモデルは進歩的です。ビジネスやアプリケーションの最終的なデータモデルというものは存在しません。データモデルは、変化するビジネスに応じて変化する生きたドキュメントであると考えるべきです。データモデルは、リポジトリに保存して、時間の経過とともに取得、拡張、編集できるようにすることが理想的です。Whittenら (2004) は、 2 種類のデータモデリングを定義しました。^[4]

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

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

トピック

データモデル

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

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

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

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

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

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

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

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

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

データベースを設計するプロセスには、前述の 3 種類のスキーマ (概念、論理、物理) の作成が含まれます。これらのスキーマで文書化されたデータベース設計は、データ定義言語によって変換され、その後、データベースの生成に使用できます。完全に属性付けされたデータモデルには、その中のすべてのエンティティの詳細な属性 (説明) が含まれます。「データベース設計」という用語は、データベースシステム全体の設計のさまざまな部分を表すことができます。主に、そして最も正確には、データを格納するために使用される基本データ構造の論理設計と考えることができます。リレーショナルモデルでは、これらはテーブルとビューです。オブジェクトデータベースでは、エンティティと関係は、オブジェクトクラスと名前付き関係に直接マップされます。ただし、「データベース設計」という用語は、基本データ構造だけでなく、データベース管理システム(DBMS)内のデータベースアプリケーション全体の一部として使用されるフォームとクエリも含めた設計プロセス全体にも適用できます。

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

モデリング手法

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

ボトムアップモデルやビュー統合モデルは、多くの場合、リエンジニアリングの取り組みの結果です。これらは通常、既存のデータ構造フォーム、アプリケーション画面のフィールド、またはレポートから始まります。これらのモデルは通常、物理的で、アプリケーション固有であり、企業の観点からは不完全です。特に組織の他の部分を参照せずに構築された場合、データ共有が促進されない可能性があります。^[7]
一方、トップダウン型の論理データモデルは、主題領域を知る人々から情報を得て抽象的な方法で作成されます。システムは論理モデル内のすべてのエンティティを実装しないかもしれませんが、モデルは参照ポイントまたはテンプレートとして機能します。 ^[7]

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

エンティティ関係図

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

これらのモデルは、情報システム設計の最初の段階である要件分析で、情報ニーズやデータベースに保存する情報の種類を記述するために使用されます。データモデリング手法は、特定の論説領域、つまり関心領域に対するオントロジー(つまり、使用される用語の概要と分類、およびその関係) を記述するために使用できます。

データモデルの設計には、いくつかの手法が開発されています。これらの手法はデータモデラーの作業の指針となりますが、同じ手法を使用しても 2 人の異なる人がまったく異なる結果を出すことがよくあります。最も注目すべきものは次のとおりです。

汎用データモデリング

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

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

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

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

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

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

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

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

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

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

参照

参考文献

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

この記事には、国立標準技術研究所のパブリックドメイン資料が組み込まれています。

さらに読む

JH ter Bekke (1991)。リレーショナル環境におけるセマンティックデータモデリング
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 Chris Bradley
データモデリングは DBMS だけのものではありませんパート 2 Chris Bradley

[MW99-1] Matthew WestとJulian Fowler (1999)。高品質のデータモデルの開発。2020年9月9日にWayback Machineにアーカイブ。欧州プロセス産業STEP技術連絡事務局（EPISTLE）。

[RS001-2] シミソン、グレアム C. & ウィット、グレアム C. (2005)。データモデリングの基本。第 3 版。Morgan Kaufmann Publishers。ISBN 0-12-644551-6

[3] データ統合用語集、Wayback Machineで 2009 年 3 月 20 日にアーカイブ、米国運輸省、2001 年 8 月。

[WBD04-4] 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。

[SS93-6] Paul R. Smith & Richard Sarfaty (1993)。コンピュータ支援ソフトウェアエンジニアリング (CASE) ツールを使用した構成管理の戦略計画の作成。1993 年 National DOE/請負業者および施設 CAD/CAE ユーザーグループ向け論文。

[SIG97-7] Len Silverston、WHInmon、Kent Graziano (2007)。データモデルリソースブック。Wiley、1997年。ISBN 0-471-15364-8。tdan.comで Van Scott がレビュー。2008 年 11 月 1 日にアクセス。

[FIPS184-8] FIPS Publication 184 Archived December 3, 2013, at the Wayback Machine by 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] 「セマンティックデータモデリング」『Metaclasses and Their Application』。書籍シリーズ Lecture Notes in Computer Science。出版社 Springer Berlin / Heidelberg。巻 943/1995。

データモデリング

概要