Loading article…
データモデルは、データの要素を整理し、それらが互いに、また現実世界のエンティティのプロパティとどのように関連しているかを標準化する抽象モデルです。[ 2 ] [ 3 ]例えば、データモデルでは、車を表すデータ要素が、車の色やサイズを表し、所有者を定義する他の複数の要素で構成されるように指定することができます。
対応する専門的な活動は、一般的にデータモデリング、より具体的にはデータベース設計と呼ばれます。データモデルは通常、データエキスパート、データスペシャリスト、データサイエンティスト、データライブラリアン、またはデータスカラーによって指定されます。データモデリング言語と表記法は、多くの場合、図などのグラフィカルな形式で表現されます。[ 4 ]
データモデルは、特にプログラミング言語の文脈では、データ構造と呼ばれることもあります。データモデルは、特にエンタープライズモデルの文脈では、関数モデルによって補完されることがよくあります。
データモデルはデータの構造を明示的に規定するものであり、逆に構造化データとは、明示的なデータモデルまたはデータ構造に従って整理されたデータのことである。構造化データは、非構造化データや半構造化データとは対照的である。
データモデルという用語は、密接に関連しながらも異なる2つの概念を指す場合があります。一つは、特定のアプリケーション領域に存在するオブジェクトと関係性を抽象的に形式化したものを指す場合です。例えば、製造業における顧客、製品、注文などがこれに該当します。もう一つは、そのような形式化を定義する際に用いられる概念群を指す場合です。例えば、エンティティ、属性、リレーション、テーブルといった概念がこれに該当します。したがって、銀行アプリケーションの「データモデル」は、エンティティとリレーションシップの関係性に基づく「データモデル」を用いて定義される可能性があります。本稿では、この用語を両方の意味で使用します。
大量の構造化データと非構造化データを管理することは、情報システムの主要な機能です。データモデルは、リレーショナルデータベースなどのデータ管理システムに格納されるデータの構造、操作、および整合性に関する側面を記述します。また、ワープロ文書、電子メールメッセージ、画像、デジタルオーディオ、ビデオなど、より緩やかな構造を持つデータも記述できます。たとえば、XDMはXML文書のデータモデルを提供します。
データモデルの主な目的は、データの定義と形式を提供することで情報システムの開発を支援することです。WestとFowler（1999）によれば、「これがシステム間で一貫して行われると、データの互換性が実現されます。同じデータ構造を使用してデータを保存およびアクセスすると、異なるアプリケーションがデータを共有できます。その結果は上記のとおりです。しかし、システムとインターフェースは、構築、運用、保守に必要以上にコストがかかることがよくあります。また、ビジネスを支援するどころか、制約となる場合もあります。主な原因は、システムとインターフェースに実装されているデータモデルの品質が低いことです。」[ 5 ]
これらの問題の原因は、データモデルがビジネスニーズを満たし、かつ一貫性を保つことを保証する標準規格が欠如していることにある。[ 5 ]
データモデルは、データの構造を明示的に定義します。データモデルの典型的な用途には、データベースモデル、情報システムの設計、データ交換の実現などがあります。通常、データモデルはデータモデリング言語で記述されます。[3]
1975年のANSIによると、データモデルインスタンスは次の3種類のいずれかである可能性がある。 [ 6 ]
ANSI によれば、このアプローチの重要な点は、3 つの視点が互いに比較的独立していることを可能にすることです。ストレージ技術は、論理モデルまたは概念モデルに影響を与えることなく変更できます。テーブル/列構造は、（必ずしも）概念モデルに影響を与えることなく変更できます。もちろん、いずれの場合も、構造は他のモデルと一貫性を保つ必要があります。テーブル/列構造は、エンティティ クラスと属性の直接的な変換とは異なる場合がありますが、最終的には概念エンティティ クラス構造の目的を達成する必要があります。多くのソフトウェア開発プロジェクトの初期段階では、概念データ モデルの設計が重視されます。このような設計は、論理データ モデルに詳細化できます。後の段階で、このモデルは物理データ モデルに変換できます。ただし、概念モデルを直接実装することも可能です。
情報システムのモデリングにおける初期の先駆的な研究の 1 つは Young と Kent (1958) [ 7 ] [ 8 ]によって行われ、彼らは「データ処理問題の情報特性と時間特性を正確かつ抽象的に指定する方法」を主張しました。彼らは「アナリストがあらゆるハードウェアを中心に問題を整理できるようにする表記法」を作成したいと考えていました。彼らの研究は、異なるハードウェア コンポーネントを使用してさまざまな代替実装を設計するための抽象的な仕様と不変の基盤を作成する最初の試みでした。IS モデリングの次のステップは、1959 年に設立された IT 業界のコンソーシアムであるCODASYLによって取られました。彼らは基本的に Young と Kent と同じこと、つまり「データ処理のシステム レベルで、マシンに依存しない問題定義言語のための適切な構造」の開発を目指していました。これが特定の IS情報代数の開発につながりました。[ 8 ]
1960年代には、経営情報システム（MIS）の概念の導入に伴い、データモデリングの重要性が増しました。Leondes（2002）によれば、「当時、情報システムは経営目的のためのデータと情報を提供していました。統合データストア（IDS）と呼ばれる第一世代のデータベースシステムは、ゼネラル・エレクトリックのチャールズ・バッハマンによって設計されました。この時期には、ネットワークデータモデルと階層データモデルという2つの有名なデータベースモデルが提案されました。」 [ 9 ] 1960年代後半には、エドガー・F・コッドがデータ配置の理論を練り上げ、一階述語論理に基づくデータベース管理のための関係モデルを提案しました。[ 10 ]
1970年代には、エンティティ関係モデリングが新しいタイプの概念データモデリングとして登場し、1976年にピーター・チェンによって初めて体系化されました。エンティティ関係モデルは、情報システム設計の最初の段階である要件分析において、情報ニーズやデータベースに格納される情報の種類を記述するために使用されていました。この手法は、特定の関心領域におけるあらゆるオントロジー、すなわち概念とその関係の概要と分類を記述することができます。
1970年代にGM Nijssenは「自然言語情報分析法」（NIAM）を開発し、1980年代にはTerry Halpinと協力してこれをオブジェクト役割モデリング（ORM）へと発展させた。しかし、オブジェクト役割モデリングの正式な基盤を築いたのは、Terry Halpinが1989年に発表した博士論文であった。
ビル・ケントは、1978年の著書『データと現実』[ 11 ]の中で、データモデルを領土の地図に例え、現実世界では「高速道路は赤く塗られておらず、川の真ん中に郡境が走っておらず、山の等高線は見えない」と強調した。数学的にクリーンでエレガントなモデルを作成しようとした他の研究者とは対照的に、ケントは現実世界の本質的な混沌と、真実を過度に歪めることなく混沌から秩序を作り出すことがデータモデラーの課題であることを強調した。
Jan L. Harrington (2000) によると、1980 年代には「オブジェクト指向パラダイムの開発により、データとデータを操作する手順の見方に根本的な変化がもたらされました。従来、データと手順は別々に格納されていました。データとその関係はデータベースに、手順はアプリケーション プログラムに格納されていました。しかし、オブジェクト指向は、エンティティの手順をそのデータと組み合わせました。」[ 12 ]
1990年代初頭、オランダの数学者であるグイド・バケマ、ハルム・ファン・デル・レク、ヤン・ピーター・ズワルトの3人は、 GM・ナイセンの研究を発展させ続けました。彼らは意味論のコミュニケーション部分に重点を置き、1997年に完全コミュニケーション指向情報モデリング（FCO-IM）という手法を体系化しました。
データベースモデルとは、データベースの構造と使用方法を記述した仕様書のことである。
こうしたモデルはいくつか提案されている。一般的なモデルとしては以下のようなものがある。
データ構造図（DSD）は、概念データモデルを記述するために使用される図およびデータモデルであり、エンティティとその関係、およびそれらを束縛する制約をグラフィカルな表記法で示します。DSDの基本的なグラフィック要素は、エンティティを表すボックスと、関係を表す矢印です。データ構造図は、複雑なデータエンティティを文書化するのに最も役立ちます。
データ構造図（DSD）は、エンティティ関係モデル（ERモデル）の拡張です。DSDでは、属性はエンティティボックスの外側ではなく内側に指定され、関係はエンティティ同士を結びつける制約を指定する属性で構成されたボックスとして描かれます。DSDは、ERモデルが異なるエンティティ間の関係に焦点を当てているのに対し、エンティティ内の要素間の関係に焦点を当て、各エンティティ間のリンクと関係をユーザーが完全に把握できるようにするという点で、ERモデルとは異なります。
データ構造図を表現する方法にはいくつかのスタイルがあり、特にカーディナリティの定義方法に顕著な違いが見られます。選択肢としては、矢印の先端、逆矢印（カラスの足）、または数値によるカーディナリティの表現があります。
エンティティ関係モデル（ERM）は、エンティティ関係図（ERD）とも呼ばれ、ソフトウェアエンジニアリングにおいて構造化データを表現するために使用される抽象的な概念データモデル（または意味データモデル、物理データモデル）を表すために使用できます。ERMにはいくつかの表記法があります。DSDと同様に、属性はエンティティボックスの外側ではなく内側に指定され、関係は線で描かれ、関係制約は線上の説明として示されます。ERモデルは堅牢ですが、属性が多数あるエンティティを表現する場合、視覚的に煩雑になることがあります。
データ構造図の表現方法にはいくつかのスタイルがあり、特にカーディナリティの定義方法に大きな違いが見られます。選択肢としては、矢印の先端、逆矢印（カラスの足跡）、または数値によるカーディナリティの表現があります。
地理情報システムにおけるデータモデルとは、地理的なオブジェクトや表面をデータとして表現するための数学的な構成要素です。例えば、
汎用データモデルは、従来のデータモデルを一般化したものです。これらは、標準化された一般的な関係型と、そのような関係型によって関連付けられる可能性のあるものの種類を定義します。汎用データモデルは、従来のデータモデルのいくつかの欠点を解決するためのアプローチとして開発されました。たとえば、異なるモデラーは、同じドメインであっても異なる従来のデータモデルを作成することがよくあります。これは、異なる人々のモデルを統合することを困難にし、データ交換やデータ統合の障害となります。しかし、この違いは、必然的に、モデルにおける抽象化レベルの違いと、インスタンス化できる事実の種類（モデルの意味表現能力）の違いに起因します。違いを小さくするためには、モデラーは、より具体的に表現すべき特定の要素についてコミュニケーションを取り、合意する必要があります。
ソフトウェアエンジニアリングにおけるセマンティックデータモデルは、他のデータとの相互関係のコンテキスト内でデータの意味を定義する手法です。セマンティックデータモデルは、格納されたシンボルが現実世界とどのように関連しているかを定義する抽象化です。[ 13 ]セマンティックデータモデルは、概念データモデルと呼ばれることもあります。
データベース管理システム（DBMS）の論理データ構造は、階層型、ネットワーク型、リレーショナル型に関わらず、その範囲が限定され、DBMSが採用する実装戦略に偏っているため、データの概念的定義の要件を完全に満たすことはできません。そのため、概念的な観点からデータを定義する必要性から、セマンティックデータモデリング技術が開発されました。つまり、他のデータとの相互関係のコンテキスト内でデータの意味を定義する技術です。図に示すように、リソース、アイデア、イベントなどの観点から、現実世界は物理的なデータストア内で記号的に定義されます。セマンティックデータモデルは、格納された記号が現実世界とどのように関連しているかを定義する抽象化です。したがって、モデルは現実世界の真の表現でなければなりません。[ 13 ]
データアーキテクチャとは、目標状態を定義し、その目標状態を達成するために必要な計画を策定する際に使用するデータの設計のことです。通常、エンタープライズアーキテクチャやソリューションアーキテクチャの柱となる複数のアーキテクチャドメインの1つです。
データアーキテクチャとは、企業やそのアプリケーションで使用されるデータ構造を記述するものです。これには、保存されているデータと転送中のデータの記述、データストア、データグループ、データ項目の記述、そしてこれらのデータ成果物とデータ品質、アプリケーション、場所などとのマッピングが含まれます。
目標とする状態を実現するために不可欠なデータアーキテクチャは、特定のシステムにおいてデータがどのように処理、保存、利用されるかを記述します。データアーキテクチャは、データフローの設計とシステム内のデータフローの制御を可能にするデータ処理操作の基準を提供します。
ソフトウェアエンジニアリングにおけるデータモデリングとは、データモデリング技術を用いて形式的なデータモデル記述を適用してデータモデルを作成するプロセスです。データモデリングは、データベースのビジネス要件を定義するための技術です。データモデルは最終的にデータベースに実装されるため、データベースモデリングと呼ばれることもあります。 [ 16 ]
この図は、今日のデータモデルの開発と使用方法を示しています。概念データモデルは、開発中のアプリケーションのデータ要件に基づいて、おそらくアクティビティモデルのコンテキストで開発されます。データモデルは通常、エンティティタイプ、属性、関係、整合性ルール、およびそれらのオブジェクトの定義で構成されます。これは、インターフェースまたはデータベース設計の出発点として使用されます。[ 5 ]
要件を満たす必要があるデータの重要な特性には、次のようなものがあります。
もう一つのデータモデルは、データベース管理システムやその他のデータ管理技術を用いてデータをどのように整理するかを記述するものです。例えば、リレーショナルテーブルと列、あるいはオブジェクト指向のクラスと属性などを記述します。このようなデータモデルは、物理データモデルと呼ばれることもありますが、ANSIの3スキーマアーキテクチャでは「論理データモデル」と呼ばれていました。このアーキテクチャでは、物理モデルは記憶媒体（シリンダ、トラック、テーブルスペース）を記述します。理想的には、このモデルは上述の概念的なデータモデルから派生したものです。ただし、処理能力や使用パターンといった制約を考慮するため、異なる場合もあります。
データモデリングはデータ分析という用語でよく使われますが、実際には分析（より一般的な概念から構成要素となる概念を特定すること）よりも合成（特定の事例から一般的な概念を推論すること）の考え方や方法と共通点が多いです。{おそらく、システムシンセシストとは誰も言えないので、私たちは自分たちをシステムアナリストと呼んでいるのでしょう。 } データモデリングは、不要なデータの冗長性を排除し、データ構造を関係性で結びつけることによって、関心のあるデータ構造をまとまりのある不可分な全体にまとめることを目指します。
別の方法としては、人工ニューラルネットワークのような適応型システムを用いて、データの暗黙的なモデルを自律的に生成する方法がある。
データ構造とは、コンピュータ上でデータを効率的に利用できるように格納する方法のことです。これは、データの数学的および論理的な概念を体系化したものです。多くの場合、慎重に選択されたデータ構造によって、最も効率的なアルゴリズムが利用できるようになります。データ構造の選択は、多くの場合、抽象データ型の選択から始まります。
データモデルは、特定のドメイン内のデータの構造、ひいてはそのドメイン自体の基盤となる構造を記述します。つまり、データモデルは、そのドメイン専用の人工言語のための専用の文法を規定するものです。データモデルは、企業が情報を保持したいエンティティ（物の種類）のクラス、その情報の属性、エンティティ間の関係、そして（多くの場合暗黙的な）属性間の関係を表します。このモデルは、データがコンピュータシステム内でどのように表現されるかに関わらず、ある程度データの構成を記述します。
データモデルで表現されるエンティティは、具体的な実体である場合もありますが、そのような具体的なエンティティクラスを含むモデルは、時間の経過とともに変化する傾向があります。堅牢なデータモデルでは、多くの場合、そのようなエンティティの抽象化が用いられます。例えば、データモデルには、組織とやり取りするすべての人を表す「人物」というエンティティクラスが含まれる場合があります。このような抽象的なエンティティクラスは、人々が担う具体的な役割を識別する「ベンダー」や「従業員」といったクラスよりも、一般的に適切です。
データモデルという用語には2つの意味があります。[ 17 ]
データモデル理論には3つの主要な構成要素があります。[ 17 ]
例えば、関係モデルでは、構造部分は数学的関係の修正された概念に基づいており、整合性部分は一階述語論理で表現され、操作部分は関係代数、タプル計算、ドメイン計算を用いて表現されます。
データモデルインスタンスは、データモデル理論を適用することによって作成されます。これは通常、企業のビジネス要件を解決するために行われます。ビジネス要件は通常、意味論的論理データモデルによって表現されます。これは物理データモデルインスタンスに変換され、そこから物理データベースが生成されます。たとえば、データモデラーはデータモデリングツールを使用して、ある企業の企業データリポジトリのエンティティ関係モデルを作成する場合があります。このモデルはリレーショナルモデルに変換され、そこからリレーショナルデータベースが生成されます。
パターン[ 18 ]は、多くのデータモデルに現れる一般的なデータモデリング構造です。
データフロー図（DFD）は、情報システムにおけるデータの「流れ」をグラフィカルに表現したものです。フローチャートとは異なり、プログラムの制御フローではなくデータフローを示します。データフロー図は、データ処理（構造化設計）の視覚化にも使用できます。データフロー図は、構造化設計の元祖開発者であるラリー・コンスタンティン[ 20 ]が、マーティンとエストリンの「データフローグラフ」計算モデルに基づいて考案しました。
システムと外部エンティティ間の相互作用を示すコンテキストレベルのデータフロー図を最初に作成するのが一般的です。DFDは、システムがどのように小さな部分に分割されているか、そしてそれらの部分間のデータの流れを明確に示すように設計されています。このコンテキストレベルのデータフロー図は、モデル化対象システムの詳細を示すために「展開」されます。
情報モデルはデータモデルの一種ではなく、むしろ代替モデルと言えるでしょう。ソフトウェアエンジニアリングの分野では、データモデルと情報モデルはどちらも、エンティティ型のプロパティ、関係、およびそれらに対して実行可能な操作を含む、抽象的で形式的な表現となり得ます。モデル内のエンティティ型は、ネットワーク内のデバイスなど、現実世界のオブジェクトの種類である場合もあれば、課金システムで使用されるエンティティのように、それ自体が抽象的なものである場合もあります。通常、これらは、閉じたエンティティ型、プロパティ、関係、および操作の集合によって記述できる、制約のあるドメインをモデル化するために使用されます。
Lee (1999) [ 21 ]によると、情報モデルは、選択された議論領域のデータ意味を指定するための概念、関係、制約、ルール、および操作の表現です。これは、ドメインコンテキストの情報要件の共有可能で安定した組織構造を提供できます。 [ 21 ]より一般的には、情報モデルという用語は、施設、建物、プロセスプラントなどの個々のもののモデルに使用されます。これらの場合、概念は施設情報モデル、建物情報モデル、プラント情報モデルなどに特化されます。このような情報モデルは、施設のモデルと施設に関するデータおよびドキュメントの統合です。
情報モデルは、問題領域の記述に形式的な枠組みを与えるものであり、その記述をソフトウェアにおける実際の実装にどのようにマッピングするかを制約するものではありません。情報モデルには多くのマッピングが存在する可能性があります。このようなマッピングは、オブジェクトモデル（ UMLなど）、エンティティ関係モデル、XMLスキーマのいずれであっても、データモデルと呼ばれます。
コンピュータサイエンスにおけるオブジェクトモデルとは、プログラムがその世界の特定の部分を調べたり操作したりできるオブジェクトまたはクラスの集合です。言い換えれば、何らかのサービスまたはシステムへのオブジェクト指向インターフェースです。このようなインターフェースは、表現されるサービスまたはシステムのオブジェクトモデルと呼ばれます。例えば、ドキュメントオブジェクトモデル（DOM）などです。これは、 Web ブラウザーのページを表すオブジェクトの集合であり、スクリプトプログラムがページを調べて動的に変更するために使用されます。Microsoft Excel を別のプログラムから制御するためのMicrosoft Excelオブジェクト モデル[ 22 ]があり、ASCOM Telescope Driver [ 23 ]は天体望遠鏡を制御するためのオブジェクト モデルです。
コンピュータ分野において、 「オブジェクトモデル」という用語は、特定のプログラミング言語、技術、表記法、または方法論においてオブジェクトが持つ一般的な特性を指す、明確な第二の意味を持つ。例えば、Javaオブジェクトモデル、COMオブジェクトモデル、OMTのオブジェクトモデルなどが挙げられる。こうしたオブジェクトモデルは通常、クラス、メッセージ、継承、ポリモーフィズム、カプセル化といった概念を用いて定義される。プログラミング言語の形式意味論のサブセットとして、形式化されたオブジェクトモデルに関する文献は数多く存在する。
オブジェクト役割モデリング（ORM）は概念モデリングの手法であり、情報やルールの分析ツールとして使用できます。[ 25 ]
オブジェクト・ロール・モデリングは、概念レベルでシステム分析を行うための事実に基づいた手法です。データベース・アプリケーションの品質は、その設計に大きく左右されます。正確性、明瞭性、適応性、生産性を確保するためには、情報システムはまず概念レベルで、人々が容易に理解できる概念と用語を用いて仕様を策定するのが最適です。
概念設計には、データ、プロセス、および動作の観点が含まれる場合があり、設計を実装するために使用される実際の DBMS は、多くの論理データモデル (関係型、階層型、ネットワーク型、オブジェクト指向型など) のいずれかに基づいている可能性があります。[ 26 ]
統一モデリング言語 (UML) は、ソフトウェアエンジニアリングの分野における標準化された汎用モデリング言語です。これは、ソフトウェア集約型システムの成果物を視覚化、仕様化、構築、および文書化するためのグラフィカル言語です。統一モデリング言語は、システム設計図を記述するための標準的な方法を提供します。これには以下が含まれます。[ 27 ]
UMLは、機能モデル、データモデル、データベースモデルを組み合わせたものを提供します。
