データ・モデル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

データモデル(またはデータモデル[1] [2] [3] [4] [5]は、データの要素を整理し、それらが相互に、および実世界のエンティティのプロパティにどのように関連するかを標準化する抽象的なモデルです。たとえば、データモデルは、車を表すデータ要素が、車の色とサイズを表し、その所有者を定義する他の多くの要素で構成されることを指定できます。

データモデルという用語は、2つの異なるが密接に関連する概念を指す場合があります。特定のアプリケーションドメインで見つかったオブジェクトと関係の抽象的な形式化を指す場合もあります。たとえば、製造組織で見つかった顧客、製品、注文などです。また、そのような形式化を定義する際に使用される一連の概念を指す場合もあります。たとえば、エンティティ、属性、リレーション、テーブルなどの概念です。したがって、銀行アプリケーションの「データモデル」は、実体関連の「データモデル」を使用して定義できます。この記事では、両方の意味でこの用語を使用しています。

データモデリングコンテキストの概要:データモデルは、データ、データ関係、データセマンティック、およびデータ制約に基づいています。データモデルは、保存する情報の詳細を提供し、最終製品がアプリケーションのコンピューターソフトウェアコードの生成、またはコンピューターソフトウェアの製造または購入の決定を支援する機能仕様の準備である場合に主に使用されます。この図は、プロセスモデルとデータモデル間の相互作用の例です。 [6]

データモデルは、データの構造を明示的に決定します。データモデルは通常、データスペシャリスト、データライブラリアン、またはデジタルヒューマニティーズの学者によってデータモデリング表記で指定されます。これらの表記は、多くの場合、グラフィック形式で表されます。[7]

データモデルは、特にプログラミング言語のコンテキストでは、データ構造と呼ばれることがありますデータモデルは、特にエンタープライズモデルのコンテキストでは、機能モデルによって補完されることがよくあります

概要

大量の構造化データと非構造化データを管理することは、情報システムの主要な機能ですデータモデルは、リレーショナルデータベースなどのデータ管理システムに格納されているデータの構造、操作、および整合性の側面を記述します。これらは通常、ワードプロセッシングドキュメント、電子メールメッセージ、画像、デジタルオーディオ、ビデオ などの非構造化データについては説明していません。

データモデルの役割

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

データモデルの主な目的は、データの定義と形式を提供することにより、情報システムの開発をサポートすることです。West and Fowler(1999)によると、「これをシステム間で一貫して行うと、データの互換性を実現できます。同じデータ構造を使用してデータを保存およびアクセスすると、異なるアプリケーションでデータを共有できます。この結果を上に示します。 。ただし、システムとインターフェースは、構築、運用、保守に必要以上のコストがかかることがよくあります。また、ビジネスをサポートするのではなく制約する可能性もあります。主な原因は、システムとインターフェースに実装されたデータモデルの品質が低いことです。 "。[8]

  • 「特定の場所での作業方法に固有のビジネスルールは、データモデルの構造に固定されていることがよくあります。つまり、ビジネスの実行方法を少し変更すると、コンピューターシステムとインターフェイスが大きく変更されます。」[8]
  • 「エンティティタイプが識別されないか、誤って識別されることがよくあります。これにより、データ、データ構造、および機能の複製が発生し、開発と保守におけるその複製の付随コストが発生する可能性があります。」[8]
  • 「異なるシステムのデータモデルは任意に異なります。その結果、データを共有するシステム間に複雑なインターフェイスが必要になります。これらのインターフェイスは、現在のシステムのコストの25〜70%を占める可能性があります。」[8]
  • 「データの構造や意味が標準化されていないため、顧客やサプライヤーとデータを電子的に共有することはできません。たとえば、エンジニアリング設計データやプロセスプラントの図面は、紙で交換されることがあります」。[8]

これらの問題の理由は、データモデルがビジネスニーズを満たし、一貫性を保つことを保証する標準の欠如です。[8]

データモデルは、データの構造を明示的に決定します。データモデルの典型的なアプリケーションには、データベースモデル、情報システムの設計、およびデータ交換の有効化が含まれます。通常、データモデルはデータモデリング言語で指定されます。[3]

3つの視点

ANSI / SPARCの3レベルのアーキテクチャこれは、データモデルが外部モデル(またはビュー)、概念モデル、または物理モデルである可能性があることを示しています。これはデータモデルを確認する唯一の方法ではありませんが、特にモデルを比較する場合に便利な方法です。[8]

データモデルインスタンスは、1975年のANSIによると3種類のうちの1つである可能性があります。 [9]

  1. 概念データモデル:モデルのスコープであるドメインのセマンティクスを記述します。たとえば、組織または業界の関心領域のモデルである場合があります。これは、ドメイン内で重要なものの種類を表すエンティティクラスと、エンティティクラスのペア間の関連付けに関する関係アサーションで構成されます。概念スキーマは、モデルを使用して表現できる事実または命題の種類を指定します。その意味で、モデルのスコープによって制限されるスコープを持つ人工的な「言語」で許可された式を定義します。
  2. 論理データモデル:特定のデータ操作テクノロジによって表されるセマンティクスを記述します。これは、テーブルと列、オブジェクト指向クラス、XMLタグなどの説明で構成されています。
  3. 物理データモデル:データが保存される物理的手段を記述します。これは、パーティション、CPU、テーブルスペースなどに関係します。

ANSIによると、このアプローチの重要性は、3つの視点が互いに比較的独立していることを可能にすることです。ストレージテクノロジーは、論理モデルまたは概念モデルに影響を与えることなく変更できます。テーブル/列の構造は、(必然的に)概念モデルに影響を与えることなく変更できます。もちろん、いずれの場合も、構造は他のモデルと一貫性を保つ必要があります。テーブル/列の構造は、エンティティクラスと属性の直接変換とは異なる場合がありますが、最終的には、概念的なエンティティクラス構造の目的を実行する必要があります。多くのソフトウェア開発プロジェクトの初期段階では、概念データモデルの設計に重点が置かれています。このような設計は、論理データモデルに詳細化できます。後の段階で、このモデルは物理データモデルに変換される可能性がありますただし、概念モデルを直接実装することもできます。

歴史

情報システムのモデリングにおける初期の先駆的な研究の1つは、Young and Kent(1958)[10] [11]によって行われ、「データ処理問題の情報と時間の特性を正確かつ抽象的な方法で特定する」と主張しました。彼らは、「アナリストがあらゆるハードウェアの問題を整理できるようにする表記法」を作成したいと考えていました。彼らの仕事は、さまざまなハードウェアコンポーネントを使用してさまざまな代替実装を設計するための抽象的な仕様と不変の基盤を作成する最初の取り組みでした。 ISモデリングの次のステップはCODASYLによって行われました、1959年に結成されたIT業界コンソーシアムであり、基本的にYoung and Kentと同じこと、つまり「データ処理のシステムレベルでのマシンに依存しない問題定義言語の適切な構造」の開発を目的としていました。これは、特定のIS情報代数の開発につながりました。[11]

1960年代に、データモデリングは、管理情報システム(MIS)の概念の開始により重要性を増しました。 Leondes(2002)によると、「当時、情報システムは管理目的でデータと情報を提供していました。統合データストア(IDS)と呼ばれる第1世代のデータベースシステムは、 GeneralElectricのCharlesBachmanによって設計されました。2つの有名なデータベースモデル、ネットワークデータモデル階層データモデルは、この期間中に提案されました。」[12] 1960年代の終わりに向けて、エドガーF.コッドはデータ配置の理論を考案し、一階述語論理に基づくデータベース管理のリレーショナルモデル[13]

1970年代に、実体関連モデリングは、1976年にPeterChenによって最初に提案された新しいタイプの概念データモデリングとして登場しました実体関連モデルは、要件分析中の情報システム設計の最初の段階で、データベースに格納される情報のニーズまたは情報のタイプを記述するため使用されていました。この手法は、特定の関心領域について、任意のオントロジー、つまり、概念とそれらの関係の概要と分類を記述することができます。

1970年代にGMNijssenは「NaturalLanguageInformation Analysis Method」(NIAM)メソッドを開発し、1980年代にTerry Halpinと協力してオブジェクトロールモデリング(ORM)に開発しました。ただし、オブジェクトロールモデリングの基礎となる正式な基盤を作成したのは、テリーハルピンの1989年の博士論文でした。

ビル・ケントは、1978年の著書「データと現実」[14]で、データモデルを領土の地図と比較し、現実の世界では「高速道路は赤く塗られておらず、川には郡の境界線が中央を流れていない」と強調しています。 、そしてあなたは山の等高線を見ることができません」。数学的にクリーンでエレガントなモデルを作成しようとした他の研究者とは対照的に、ケントは現実世界の本質的な混乱と、真実を過度に歪めることなく混乱から秩序を作り出すというデータモデラーの仕事を強調しました。

Jan L. Harrington(2000)によると、1980年代には、「オブジェクト指向パラダイムの開発により、データの見方とデータを操作する手順に根本的な変化がもたらされました。従来、データと手順は別々に保存されます:データベース内のデータとそれらの関係、アプリケーションプログラム内のプロシージャ。ただし、オブジェクト指向は、エンティティのプロシージャとそのデータを組み合わせたものです。」[15]

1990年代初頭、3人のオランダの数学者Guido Bakema、Harm van der Lek、およびJanPieter Zwartは、GMNijssenの作業の開発を続けまし彼らはセマンティクスのコミュニケーション部分にもっと焦点を合わせました。1997年に、彼らはメソッドFully Communication Oriented Information ModelingFCO -IMを公​​式化しました。

タイプ

データベースモデル

データベースモデルは、データベースの構造と使用方法を説明する仕様です。

そのようなモデルがいくつか提案されています。一般的なモデルは次のとおりです。

フラットモデル
これは、データモデルとして厳密に適格ではない場合があります。フラット(またはテーブル)モデルは、データ要素の単一の2次元配列で構成され、特定の列のすべてのメンバーが同様の値であると見なされ、行のすべてのメンバーが相互に関連していると見なされます。
階層モデル
階層モデルはネットワークモデルに似ていますが、階層モデルのリンクがツリー構造を形成するのに対し、ネットワークモデルでは任意のグラフを使用できます。
ネットワークモデル
このモデルは、レコードとセットと呼ばれる2つの基本的な構成を使用してデータを編成します。レコードにはフィールドが含まれ、セットはレコード間の1対多の関係(1人の所有者、多くのメンバー)を定義します。ネットワークデータモデルは、データベースの実装で使用される設計概念を抽象化したものです。
リレーショナルモデル
一階述語論理に基づくデータベースモデルです。その中心的な考え方は、データベースを述語変数の有限集合上の述語のコレクションとして記述し、可能な値と値の組み合わせに対する制約を記述することです。リレーショナルデータモデルの力は、その数学的基礎と単純なユーザーレベルのパラダイムにあります。
オブジェクトリレーショナルモデル
リレーショナルデータベースモデルに似ていますが、オブジェクト、クラス、および継承は、データベーススキーマとクエリ言語で直接サポートされています。
オブジェクトロールモデリング
「属性フリー」および「ファクトベース」として定義されているデータモデリングの方法。その結果、検証可能な正しいシステムが得られ、そこからERD、UML、セマンティックモデルなどの他の一般的なアーティファクトを導き出すことができます。データオブジェクト間の関連付けは、データベースの設計手順中に記述されるため、正規化はプロセスの必然的な結果です。
スタースキーマ
最も単純なスタイルのデータウェアハウススキーマ。スタースキーマは、任意の数の「ディメンションテーブル」を参照するいくつかの「ファクトテーブル」(おそらく1つだけ、名前を正当化する)で構成されます。スタースキーマは、スノーフレークスキーマの重要な特殊なケースと見なされます

データ構造図

データ構造図の例

データ構造図(DSD)は、エンティティとその関係、およびそれらをバインドする制約を文書化するグラフィカルな表記を提供することにより、概念的なデータモデルを記述するために使用される図とデータモデルです。DSDの基本的なグラフィック要素は、エンティティを表すボックスと、関係を表す矢印です。データ構造図は、複雑なデータエンティティを文書化するのに最も役立ちます。

データ構造図は、実体関連モデル(ERモデル)を拡張したものです。 DSDでは、属性はエンティティボックスの外側ではなく内側で指定されますが、関係は、エンティティをバインドする制約を指定する属性で構成されるボックスとして描画されます。 DSDはERモデルとは異なり、ERモデルは異なるエンティティ間の関係に焦点を当てていますが、DSDはエンティティ内の要素の関係に焦点を当てており、ユーザーは各エンティティ間のリンクと関係を完全に確認できます。

データ構造図を表すにはいくつかのスタイルがありますが、カーディナリティの定義方法に顕著な違いがあります。選択肢は、矢印の頭、逆向きの矢印の頭(カラスの足)、またはカーディナリティの数値表現の間です。

IDEF1X自体をモデル化するために使用されるIDEF1Xエンティティ関係図の例[16]

実体関連モデル

実体関連図(ERD)と呼ばれることもある実体関連モデル(ERM)は、構造化データを表すためにソフトウェアエンジニアリングで使用される抽象的な概念データモデル(またはセマンティックデータモデルまたは物理データモデル)を表すために使用できます。 。 ERMにはいくつかの表記法が使用されています。 DSDと同様に、属性はエンティティボックスの外側ではなく内側で指定されますが、関係は線として描画され、関係の制約は線の説明として描画されます。 ERモデルは堅牢ですが、複数の属性を持つエンティティを表す場合、視覚的に煩雑になる可能性があります。

データ構造図を表すにはいくつかのスタイルがありますが、カーディナリティの定義方法に顕著な違いがあります。選択肢は、矢印の頭、逆向きの矢印の頭(カラスの足)、またはカーディナリティの数値表現の間です。

地理データモデル

地理情報システムのデータモデルは、地理オブジェクトまたはサーフェスをデータとして表すための数学的構成です。例えば、

  • ベクトルデータモデルは、地理を点、線、およびポリゴンとして表します
  • ラスターデータモデルは、地理を数値を格納するセルマトリックスとして表します。
  • 三角分割不規則ネットワーク(TIN)データモデルは、地理を連続した重なり合わない三角形のセットとして表します[17]

汎用データモデル

汎用データモデルは、従来のデータモデルを一般化したものです。それらは、標準化された一般的な関係タイプを、そのような関係タイプによって関連付けられる可能性のあるものの種類とともに定義します。汎用データモデルは、従来のデータモデルのいくつかの欠点を解決するためのアプローチとして開発されています。たとえば、モデラーが異なれば、通常、同じドメインの従来のデータモデルも異なります。これは、さまざまな人々のモデルをまとめるのが困難になる可能性があり、データ交換とデータ統合の障害になります。ただし、常に、この違いは、モデルの抽象化のレベルの違いと、インスタンス化できるファクトの種類(モデルのセマンティック表現機能)の違いに起因します。

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

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

ソフトウェアエンジニアリングのセマンティックデータモデルは、他のデータとの相互関係のコンテキスト内でデータの意味を定義する手法です。セマンティックデータモデルは、格納されたシンボルが実世界にどのように関連するかを定義する抽象化です。[16]セマンティックデータモデルは、概念データモデルと呼ばれることもあります

データベース管理システム(DBMS)の論理データ構造は、階層ネットワークリレーショナルのいずれであっても、範囲が限定され、DBMSで採用されている実装戦略に偏っているため、データの概念的な定義の要件を完全に満たすことはできません。したがって、概念的な観点からデータを定義する必要がありますセマンティックデータモデリング技術の開発につながりました。つまり、他のデータとの相互関係のコンテキスト内でデータの意味を定義する手法です。図に示すように。リソース、アイデア、イベントなどの観点から、現実の世界は物理データストア内で象徴的に定義されます。セマンティックデータモデルは、格納されたシンボルが実世界にどのように関連するかを定義する抽象化です。したがって、モデルは実世界の真の表現でなければなりません。[16]

トピック

データアーキテクチャ

データアーキテクチャは、ターゲット状態の定義と、ターゲット状態に到達するために必要なその後の計画に使用するデータの設計です。これは通常、エンタープライズアーキテクチャまたはソリューションアーキテクチャの柱を形成するいくつかのアーキテクチャドメインの1つです。

データアーキテクチャは、ビジネスやそのアプリケーションで使用されるデータ構造を記述します。ストレージ内のデータと移動中のデータの説明があります。データストア、データグループ、およびデータ項目の説明。そして、それらのデータアーティファクトのデータ品質、アプリケーション、場所などへのマッピング。

ターゲット状態を実現するために不可欠なデータアーキテクチャは、特定のシステムでデータがどのように処理、保存、および利用されるかを記述します。これは、データフローを設計し、システム内のデータフローを制御することを可能にするデータ処理操作の基準を提供します。

データモデリング

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

ソフトウェアエンジニアリングにおけるデータモデリングは、データモデリング手法を使用して正式なデータモデル記述を適用することにより、データモデルを作成するプロセスです。データモデリングは、データベースのビジネス要件を定義するための手法です。データモデルは最終的にデータベースに実装されるため、データベースモデリングと呼ばれることもあります。[19]

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

データプロパティ

データのいくつかの重要な特性[8]

要件を満たす必要があるデータのいくつかの重要なプロパティは次のとおりです。

  • 定義関連のプロパティ[8]
    • 関連性:ビジネスのコンテキストにおけるデータの有用性。
    • 明快さ:データの明確で共有された定義の可用性。
    • 一貫性:異なるソースからの同じタイプのデータの互換性。
  • コンテンツ関連のプロパティ
    • 適時性:必要な時点でのデータの可用性と、そのデータがどの程度最新であるか。
    • 精度:データが真実にどれだけ近いか。
  • 定義とコンテンツの両方に関連するプロパティ
    • 完全性:必要なデータのどれだけが利用可能か。
    • アクセシビリティ:どこで、どのように、誰にデータを利用できるか、または利用できないか(セキュリティなど)。
    • コスト:データを取得して使用できるようにするために発生するコスト。

データ編成

別の種類のデータモデルは、データベース管理システムまたは他のデータ管理テクノロジを使用してデータを整理する方法を記述します。たとえば、リレーショナルテーブルと列、またはオブジェクト指向のクラスと属性について説明します。このようなデータモデルは、物理データモデルと呼ばれることもありますが、元のANSI 3スキーマアーキテクチャでは、「論理」と呼ばれます。そのアーキテクチャでは、物理モデルはストレージメディア(シリンダー、トラック、およびテーブルスペース)を記述します。理想的には、このモデルは、上記のより概念的なデータモデルから派生します。ただし、処理能力や使用パターンなどの制約を考慮すると、異なる場合があります。

データ分析はデータモデリングの一般的な用語ですが、実際には、分析(より一般的なものからコンポーネントの概念を特定する)よりも、合成のアイデアや方法特定インスタンスから一般的な概念を推測する)との共通点があります。 {システムシンセサイザーとは誰も言えないので、おそらく私たちは自分たちをシステムアナリストと呼んでいます。データモデリングは、不要なデータの冗長性を排除し、データ構造を関係と関連付けることにより、対象のデータ構造をまとまりのある、分離できない全体にまとめようとします。

別のアプローチは、データの暗黙的なモデルを自律的に作成できる 人工ニューラルネットワークなどの適応システムを使用することです。

データ構造

分木、単純なタイプの分岐リンクされたデータ構造

データ構造は、データを効率的に使用できるようにコンピューターに保存する方法です。これは、データの数学的および論理的概念の編成です。多くの場合、慎重に選択されたデータ構造により、最も効率的な アルゴリズムを使用できます。多くの場合、データ構造の選択は、抽象データ型の選択から始まります。

データモデルは、特定のドメイン内のデータの構造を記述し、暗黙的に、そのドメイン自体の基礎となる構造を記述します。これは、データモデルが実際には、そのドメイン専用の人工言語専用の文法を指定していることを意味します。データモデルは、企業が情報を保持したいエンティティのクラス(種類)、その情報の属性、およびそれらのエンティティ間の関係、およびそれらの属性間の(多くの場合暗黙の)関係を表します。このモデルは、コンピューターシステムでデータがどのように表現されるかに関係なく、ある程度データの編成を記述します。

データモデルによって表されるエンティティは有形のエンティティである可能性がありますが、そのような具体的なエンティティクラスを含むモデルは時間の経過とともに変化する傾向があります。堅牢なデータモデルは、多くの場合、そのようなエンティティの抽象化を識別します。たとえば、データモデルには、組織とやり取りするすべての人を表す「Person」というエンティティクラスが含まれる場合があります。このような抽象エンティティクラスは、通常、「ベンダー」または「従業員」と呼ばれるクラスよりも適切です。これらのクラスは、これらの人々が果たす特定の役割を識別します。

データモデル理論

データモデルという用語には、次の2つの意味があります。[20]

  1. データモデル理論、つまり、データを構造化してアクセスする方法の正式な説明。
  2. データモデルインスタンス。つまり、データモデル理論を適用して、特定のアプリケーション用の実用的なデータモデルインスタンスを作成します。

データモデル理論には、次の3つの主要な要素があります。[20]

  • 構造部分:データベースによってモデル化されたエンティティまたはオブジェクトを表すデータベースを作成するために使用されるデータ構造のコレクション。
  • 整合性の部分:構造の整合性を確保するためにこれらのデータ構造に課せられる制約を管理するルールのコレクション。
  • 操作部分:データベースに含まれるデータを更新および照会するために、データ構造に適用できる演算子のコレクション。

たとえば、リレーショナルモデルでは、構造部分は数学的関係の修正された概念に基づいています。整合性部分は一階述語論理で表現され、操作部分は関係代数タプル計算ドメイン計算を使用して表現されます。

データモデルインスタンスは、データモデル理論を適用して作成されます。これは通常、企業の要件を解決するために行われます。ビジネス要件は通常、セマンティック論理データモデルによってキャプチャされます。これは物理データモデルインスタンスに変換され、そこから物理データベースが生成されます。たとえば、データモデラーは、データモデリングツールを使用して、一部の企業の企業データリポジトリの実体関連モデルを作成できます。このモデルはリレーショナルモデルに変換され、リレーショナルデータベースが生成されます

パターン

パターン[21]は、多くのデータモデルで発生する一般的なデータモデリング構造です。

関連モデル

データフロー図

データフロー図の例[22]

データフロー図(DFD)は、情報システムを介したデータの「フロー」をグラフィカルに表現したものです。プログラムの制御フローではなくデータフローを示しているため、フローチャートとは異なります。データフロー図は、データ処理の視覚化(構造化設計)にも使用できます。データフロー図は、MartinとEstrinの「データフローグラフ」計算モデルに基づいて 、構造設計の最初の開発者であるLarryConstantineによって発明されました[23] 。

システムと外部エンティティ間の相互作用を示すコンテキストレベルのデータフロー図を最初に作成するのが一般的な方法です。DFDは、システムがどのように小さな部分に分割されているかを示し、それらの部分間のデータの流れを強調するように設計されています。次に、このコンテキストレベルのデータフロー図を「展開」して、モデル化されているシステムの詳細を表示します。

情報モデル

情報モデルは一種のデータモデルではなく、多かれ少なかれ代替モデルです。ソフトウェアエンジニアリングの分野では、データモデルと情報モデルの両方を、プロパティ、関係、およびそれらに対して実行できる操作を含むエンティティタイプの抽象的な正式な表現にすることができます。モデル内のエンティティタイプは、ネットワーク内のデバイスなどの実世界のオブジェクトの種類である場合もあれば、課金システムで使用されるエンティティの場合など、それ自体が抽象的である場合もあります。通常、これらは、エンティティタイプ、プロパティ、関係、および操作の閉集合によって記述できる制約付きドメインをモデル化するために使用されます。

Lee(1999)[24]によると、情報モデルは、選択された論議領界のデータセマンティクスを指定するため の概念、関係、制約、規則、および操作の表現です。ドメインコンテキストの情報要件の共有可能で安定した組織化された構造を提供できます。[24]より一般的には、情報モデルという用語は、施設、建物、プロセスプラントなどの個々のもののモデルに使用されます。これらの場合、概念は施設情報モデル建物情報モデルに特化しています。、プラント情報モデルなど。このような情報モデルは、施設のモデルと施設に関するデータおよびドキュメントを統合したものです。

情報モデルは、問題の記述がソフトウェアの実際の実装にどのようにマッピングされるかを制約することなく、問題領域の記述に形式を提供します。情報モデルの多くのマッピングがあるかもしれません。このようなマッピングは、オブジェクトモデルUMLを使用するなど)、エンティティ関係モデル、またはXMLスキーマであるかどうかに関係なく、データモデルと呼ばれます。

オブジェクトモデル

コンピュータサイエンスのオブジェクトモデルは、プログラムがその世界の特定の部分を調べて操作できるオブジェクトまたはクラスのコレクションです。言い換えれば、あるサービスまたはシステムへのオブジェクト指向インターフェース。このようなインターフェースは、表現されたサービスまたはシステムのオブジェクトモデルであると言われます。たとえば、Document Object Model(DOM) [1]は、Webブラウザのページを表すオブジェクトのコレクションであり、スクリプトプログラムがページを調べて動的に変更するために使用します。別のプログラムからMicrosoftExcelを制御するためのMicrosoftExcelオブジェクトモデル[25]と、ASCOMがあります。望遠鏡ドライバー[26]は、天体望遠鏡を制御するためのオブジェクトモデルです。

オブジェクトモデルという用語の計算では、特定のコンピュータープログラミング言語、テクノロジー、表記法、またはオブジェクトを使用する方法論におけるオブジェクトの一般的なプロパティの明確な2番目の意味があります。たとえば、JavaオブジェクトモデルCOMオブジェクトモデル、またはOMTのオブジェクトモデル。このようなオブジェクトモデルは通常、クラスメッセージ継承ポリモーフィズムカプセル化などの概念を使用して定義されます。プログラミング言語の形式的セマンティクスのサブセットとして、形式化されたオブジェクトモデルに関する広範な文献があります

オブジェクトロールモデル

「地質表面のスキーマ」におけるオブジェクトロールモデリングの適用例、Stephen M. Richard(1999)[27]

オブジェクトロールモデリング(ORM)は、概念モデリングの方法であり、情報およびルール分析のツールとして使用できます。[28]

オブジェクトロールモデリングは、概念レベルでシステム分析を実行するためのファクト指向の方法です。データベースアプリケーションの品質は、その設計に大きく依存します。正確性、明快さ、適応性、生産性を確保するために、情報システムは、人々が容易に理解できる概念と言語を使用して、最初に概念レベルで指定するのが最適です。

概念設計には、データ、プロセス、および動作の観点が含まれる場合があり、設計の実装に使用される実際のDBMSは、多くの論理データモデル(リレーショナル、階層、ネットワーク、オブジェクト指向など)の1つに基づく場合があります。[29]

統一モデリング言語モデル

統一モデリング言語(UML)は、ソフトウェアエンジニアリングの分野で標準化された汎用モデリング言語です。これは、ソフトウェアを多用するシステムの成果物を視覚化、指定、構築、および文書化するためのグラフィカル言語です。統一モデリング言語は、次のようなシステムの青写真を書くための標準的な方法を提供します。[30]

UMLは、機能モデル、データモデル、およびデータベースモデルの組み合わせを提供します。

も参照してください

参考文献

  1. ^ 「データモデル-UMLドメインモデリング-スタックオーバーフロー」スタックオーバーフローStack ExchangeInc 2017年2月4日取得
  2. ^ 「XQueryおよびXPathデータモデル3.1」World Wide Webコンソーシアム(W3C)W3C 2017年2月4日取得
  3. ^ 「データモデル」npmnpm、Inc 2017年2月4日取得
  4. ^ 「DataModel(Java EE 6)」JavaドキュメントOracle 2017年2月4日取得
  5. ^ オストロフスキー、スタン。「iOS:モデルからコントローラーにデータを渡す3つの方法」ミディアムミディアムコーポレーション2017年2月4日取得
  6. ^ Paul R. Smith&Richard Sarfaty Publications、LLC 2009
  7. ^ Michael R. McCaleb(1999)。「データムシステムの概念データモデル」 2008年9月21日にウェイバックマシンでアーカイブされました。米国国立標準技術研究所。1999年8月。
  8. ^ a b c d e f g h i j k Matthew West and Julian Fowler(1999)。高品質のデータモデルの開発欧州プロセス産業STEPテクニカルリエゾンエグゼクティブ(EPISTLE)。
  9. ^ 米国規格協会。1975年。データベース管理システムに関するANSI / X3 / SPARC研究会。中間報告FDT(ACM SIGMODの報告)7:2。
  10. ^ ヤング、JW、およびケント、HK(1958)。「データ処理問題の抽象的な定式化」。で:インダストリアルエンジニアリングのジャーナル1958年11月-12月。9(6)、pp.471-479
  11. ^ a b Janis A. Bubenko jr(2007)「情報代数からエンタープライズモデリングおよびオントロジーへ-情報システムのモデリングに関する歴史的展望」。で:情報システム工学における概念モデリングJohn Krogstie etal。eds。pp 1-18
  12. ^ Cornelius T. Leondes(2002)。データベースとデータ通信ネットワークシステム:技術とアプリケーション7ページ
  13. ^ 「大規模なデータバンクに保存されている関係の導出可能性、冗長性、および一貫性」、EF Codd、IBM Research Report、1969年
  14. ^ データと現実
  15. ^ Jan L. Harrington(2000)。オブジェクト指向データベースの設計が明確に説明されています。p.4
  16. ^ a b c d FIPS Publication 184 国立標準技術研究所(NIST)のコンピューターシステム研究所によってIDEF1XがリリースされたWaybackMachineで2013年12月3日にアーカイブされました。1993年12月21日(2008年に撤回)。
  17. ^ Wade、T。およびSommer、S.eds。AからZへのGIS
  18. ^ a b c d David R.Soller1およびThomasM。Berg(2003)。National Geologic Map Database Project:Overview and Progress US Geological Survey Open-File Report 03–471。
  19. ^ ホイッテン、ジェフリーL .; ロニー・D・ベントレーケヴィン・C・ディットマン(2004)。システム分析と設計方法第6版。ISBN0-256-19906 -X 
  20. ^ a b Beynon-Davies P.(2004)。データベースシステム第3版。パルグレイブ、ベイジングストーク、英国。ISBN 1-4039-1601-2 
  21. ^ 「データモデルリソースブック:データモデリングのためのユニバーサルパターン」Len Silverstone&Paul Agnew(2008)。
  22. ^ ジョンアッツォリーニ(2000)。システムエンジニアリングプラクティスの概要2000年7月。
  23. ^ W. Stevens、G。Myers、L。Constantine、「Structured Design」、IBM Systems Journal、13(2)、115-139、1974。
  24. ^ a b Y. Tina Lee(1999)。「設計から実装までの情報モデリング」米国国立標準技術研究所。
  25. ^ Excelオブジェクトモデルの概要
  26. ^ 「ASCOMの一般的な要件」2011-05-13 2014年9月25日取得
  27. ^ スティーブンM.リチャード(1999)。地質学的概念モデリング米国地質調査所オープンファイルレポート99-386。
  28. ^ Joachim Rossberg and Rickard Redler(2005)。プロスケーラブルな.NET2.0アプリケーション設計。27ページ
  29. ^ オブジェクトロールモデリング:概要(msdn.microsoft.com)2008年9月19日取得。
  30. ^ Grady Booch、Ivar Jacobson&Jim Rumbaugh(2005) OMG統一モデリング言語仕様

さらに読む

  • デビッドC.ヘイ(1996)。データモデルパターン:思考の慣習ニューヨーク:Dorset House Publishers、Inc。
  • レンシルバーストン(2001)。データモデルリソースブックボリューム1/2。ジョン・ワイリー&サンズ。
  • レン・シルバーストン&ポール・アグニュー(2008)。データモデルリソースブック:データモデリングボリューム3のユニバーサルパターン。JohnWiley&Sons。
  • マシューウェストとジュリアンファウラー(1999)。高品質のデータモデルの開発欧州プロセス産業STEPテクニカルリエゾンエグゼクティブ(EPISTLE)。
  • Matthew West(2011)高品質データモデルの開発Morgan Kaufmann