IDEF1X

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
Example of an IDEF1X Diagram.

IDEF1X (情報モデリングのための統合化定義)は、意味論的データモデルsemantic data modelの開発のためのデータモデリングData modeling言語[1]である。IDEF1Xは、環境またはシステムSystem内の情報Informationの構造と意味Semanticsを表現する図式情報モデルInformation_modelを生成するのに使われる[1]

IDEF1Xの利用は、資源、情報システムの統合、及びコンピュータ・データベースDatabaseとして、データの管理を支援するのに供するかもしれない意味論データ・モデルの構築を可能にする。この標準は、ソフトウエア工学Software_engineeringの分野でのモデリング言語のIDEFファミリIDEFの一部です。

全貌[編集]

データモデリングData_modeling技術は、資源としてデータを管理するための標準で、一貫した、予測可能な方法でモデル化するのに使われる。それは組織内でデータ資源を定義し分析する標準的な手段を要求しているプロジェクトで使われ得る。このようなプロジェクトは、資源としてデータを管理し、情報システムInformation_systemsを統合し、あるいはコンピュータデータベースDatabaseを設計する一つ方法論MethodologyデータモデリングData_modeling技術の組入れを含みます。IDEF1X標準の主な目的は以下を提供することである[1]

  • 組織のデータ資源を完全に理解分析するための手段;
  • データの複雑さを表現し伝える共通手段;
  • 事業体を運営するため要求されるデータの全体的ビューを表現する技術;
  • ユーザーによって検証され、物理的データベース設計に変換可能になり得るアプリケーションに依存しないデータのビューを定義する手段;
  • 既存のデータ資源から統合されたデータ定義を得るための技術。

IDEF1Xの主な目的は、統合System integrationを支援することである。統合へのアプローチは『概念的スキーマConceptual_schema』として参照されるデータ資源の獲得、管理Management、及び一意的定義の使用に焦点を合わせる。『概念的スキーマ』は、データのアプリケーションに向けての偏見のない、そしてどのようにデータが物理的に格納あるいはアクセスされるかとは独立である、事業体内でのデータの一つに統合された定義を提供する。この概念的スキーマの主な目的は、データの整合性を統合し、共有し、そして管理するため使われ得る、データの意味と関係の整合した定義を準備することである。概念的スキーマは、3つの重要な特性を持っていなければならない。それは以下でなければならない[1]

「概念的なスキーマ」はデータがどのように物理的にストアされるか、あるいはアクセスされるかのデータのどんな一つのアプリケーションに向かってでも公平であって、そして独立しているエンタープライズの中のデータの一つの統合化された定義を提供します。 この概念的なスキーマの主要な目的はデータの完全性の人種差別を撤廃して、共にして、そして管理するために使われることができるデータの意味と相互関係の一貫した定義を提供することです。 概念的なスキーマが3つの重要な特徴を持っていなくてはなりません。 それは次のことであるければならな:

  • 事業インフラと矛盾することなくかつ全てのアプリケーション領域を横断して真であること
  • 新しい意データが前のデータ定義を変えることなく定義できるように、拡張可能であること
  • 要求されるユーザーのビューとデータ格納と構造アクセスの多様さの両方で移行可能であること。

歴史[編集]

意味論的データモデルへのニーズは、1970年代中頃に米空軍の統合されたコンピュータ支援の製造[ICAM]プログラムで最初に認識されていた。このプログラムの目的は、コンピュータ技術の体系的適用を通して製造の生産性を増大させることであった。ICAMプログラムは、製造の生産性の改善に関わる人々のためのより良い分析と伝達技術へのニースを認識した。結果として、ICAMプログラムは、以下を含む、IDEF(ICAM Definition)手法として知られる一連の技術を開発した[1]

  • IDEF0 は、そのシステムあるいはその環境内でのアクティビティやプロセスの構造化された表現手段である。
  • IDEF1 は、システムやその環境内の情報の構造と意味論を表現する『情報モデル』を作るため使われる。
  • IDEF2 は、『動的モデル』を作るため使われる。

IDEFの情報モデリング(IDEF1)への当初のアプローチは、当時の研究と業界ニーズに基づき、1981年のICAMプログラムで発行された。このアプローチの理論的ルーツは、relational theory におけるエドガー・F・コッド実体関連モデルにおけるピーター・チェンの初期の作業を軸とした。初期のIDEF1技術は、チャールズ・バックマンピーター・チェン、Dr. M.A. Melkanoff、及び Dr. G.M. Nijssenによる厳しいレビューと影響の下での、Hughes AircraftのDr. R.R. Brown と Mr. T.L. Ramey 、及びD. Appleton Company (DACOM)のMr. D.S. Coleman の作業に基づいた[1]

1983年に米空軍は、ICAMプログラムの下で、統合された情報支援システム(IISS)プロジェクトを立ち上げた。このプロジェクトの目的は、異種コンピュータのハードウエアやソフトウエアのネットワークを論理的及び物理的に統合するイネーブリング技術を準備することであった。このプロジェクトの結果及び業界の経験として、情報モデリングのための拡張された技術のニーズが認識された[1]

空軍のIDEFプログラムの契約管理の観点から、IDEF1Xは、ICAM IISS-6201 プロジェクトの結果でありかつICAM IISS-6202 プロジェクトによる更なる拡張となった。IISS-6202プロジェクト、サブコントラクタ、DACOMで認識されたデータ・モデリングの拡張要求を満たすため、論理データベース設計技術(LDDT)とその支援ソフトウエア(ADAM)のライセンスを取得した。モデリング技術の技術的内容の観点からのIDEF1Xは、LDDT の改名である。

論理データベース設計技術(LDDT)[編集]

LDDTは、1982年に、IDEFプログラムのまったく外の、さらにIDEF1の知識を持たない、データベース設計グループ(The Database Design Group)のRobert G. Brownによって開発された。それにもかかわらず、IDEF1とLDDTの中心的目標は、同じであった:実世界のエンティティに関わるモデリングによって事業体により必要とされる永続的な情報のデータベース中立モデルを作ること。LDDTは、リレーショナル・モデル、E-Rモデル、及び、データ・モデリングとデータベース設計へのデータ・モデルの変換を支援することを意図した具体的方法におけるデータ汎化の要素を結びつけた。

LDDTは、汎化/特化のモデリングと、主キーと外部キーによる関係性の名詞的表現、より良く定義されたロール名支援の手段、モデルの複数レベルを含む。主キーと曖昧さのないロール名を持つ外部キーは、時には、データベースのタイプが最終的にどのように設計されたかによって知りかつ守るべき、微妙な一意性と参照整合性制約を表現する。データベース設計が、データベースのアクセス・キー又はインデックスとして、LDDTモデルのキーに基づく整合性制約を使ったかどうかは、完全に別の意思決定であった。LDDTモデルの精度と完全性は、モデルをデータベース設計のモデルに比較的スムーズな変換を可能にすることで、重要な要素であった。初期のLDDTモデルは、IBMの階層的データベースIMSのため、データベース設計に変換された。後のモデルは、Cullinetのネットワーク・データベース、IDMS、及びリレーショナル・データベースの多くのバラエティのためのデータベース設計に変換された。

LDDTの図式構文はIDEF1のそれとは異なり、そしてより重要には、LDDTが含む相互関係モデリング概念は、IDEF1で存在しない。そこで、拡張IDEF1の代わりに、DACOMのMary E. Loomis は、可能なかぎりIDEF1と互換性のある用語を使って、LDDTの重要なサブセットの構文と意味論の簡潔な要約を書いた。DACOMは、結果をIDEF1Xと名づけ、そしてそれを1985年に発効した、ICAMプログラムに供給した(IEEE 1998, p. iii) (Bruce 1992, p. xii)[1]

IDEF1X 構築ブロック[編集]

エンティティ 
同じ特性を共有しかつ同じ関係性に参加出来ることから同じタイプと認識される、実体的または抽象的のもの(人、オブジェクト、場所、出来事、アイデア、ものの組合せ、等)のセットの表現。
ドメイン
属性インスタンスの実値が描かれる際、同じデータ・タイプの全てへのデータ値(固定、あるいはもしかすると無限数)の名前セット。各属性は、同じドメインの下で正確に一つに定義されなければならない。
属性
一つのエンティティのインスタンスの幾つか又は全てに共通な特性又は特徴。一つの属性は、エンティティの文脈における一つのドメインの利用を表現する。
キー
各エンティティのインスタンスを固有な値で識別される、一つのエンティティの一つの属性、または属性の組合せ。
主キー
一つのエンティティの固有な識別子として選ばれた候補キー。
外部キー
関係する親または汎用エンティティのインスタンスの主キーにおけるそれらと値が一致し、その一つの子供または分類エンティティのインスタンスの一つの属性または属性の組合せ。外部キーは、親または汎用エンティティの主キーを特定的接続または分類関係を通して移植した結果である。
関係
2つのエンティティ間または同じエンティティのインスタンス間の関連性。
接続関係
一つの関係で他と相互に関連され得るエンティティのインスタンスの数。制約、カーディナリティを見よ。
分類関係
実体又は抽象なもののエンティティとインスタンスの両方のを同じに表現する一つの関係。一つのエンティティ(汎化エンティティ)は、ものの完全セットを表現し、もう一つ(分類エンティティ)は、それらのもののサブタイプまたはサブクラスを表す。分類エンティティは、一つ以上の特徴または、全ての汎化エンティティ・インスタンスにより共有されない他のエンティティのインスタンスとの関係を持つかもしれない。分類エンティティの各インスタンスは、汎化エンティティのインスタンスと同時である。
非特定関係
いずれかのエンティティのインスタンスが他のインスタンスの幾つかと関係し得る一つの関係。


IDEF1X のトピックス[編集]

3層スキーマ・アプローチ[編集]

ソフトウエア工学における3層スキーマ・アプローチThree schema approachは、データ統合Data integrationを達成する鍵として概念モデルConceptual schemaを促進する、情報システム構築及びシステム情報管理の一つのアプローチである[3]

スキーマModel (abstract)|schemaは、一般にダイアグラムDiagramによって描かれ、そして時には文書記述を伴う、一つのモデルscientific modelling|modelである。三層スキーマ・アプローチは3つのスキーマのタイプを持っている[4]

  • ユーザ・ビューのための外部スキーマ
  • 外部スキーマを統合する概念スキーマConceptual schema
  • 物理的格納構造を定義する内部スキーマ

その中央の概念スキーマは、それらのユーザUser_(computing)|Userの考えとそれらについての会話として、概念Concept概念体系Ontologyを定義する。物理的スキーマは、データベースDatabaseに格納されるデータDataの内部的フォーマットを記述し、そして外部スキーマは、アプリケーション・プログラムApplication programへの表現されたデータのビューを定義する[5]。そのフレームワークは。外部スキーマのため使われるべき複数のデータ・モデルを許そうとする[6]

モデリングのガイド[編集]

フェーズ1でエンティティを合成 – エンティティ定義

モデリングのプロセスは、モデル開発の5つのステップに分けることができる。

フェーズ0-プロジェクト開始
プロジェクト開始フェーズの目的は、以下を含む:
  • プロジェクト定義 — 何がなされるべきか、なぜ、そしてどのようになされるかの一般的声明。
  • 情報源資料 — 目録やファイリングを含む、情報源資料の収集のための計画。
  • 著者の規律 — 著者がモデルを作り管理するため選んだ(選択的方法)の規律の基本的宣言。


フェーズ1 – エンティティ定義
このフェースの目的は、その問題ドメイン内でモデル化されるエンティティの識別とで異議をすることである。このプロセスの最初のステップは、エンティティの識別である。


フェーズ2 – 関係性の定義
フェーズ2の目的は、エンティティ間の基本的関係性を識別し定義することである。モデリングのこのステージで、幾つかの関係は非特定的であるかも知れず、そして続くフェーズで追加の洗練を必要とする。フェーズ2からの主な出力は:
  • 関係性マトリックス
  • 関係性定義
  • エンティティ-レベル・ダイアグラム


フェーズ3 - キーの定義
フェーズ3の目的は以下を行うことである:
  • フェーズ2からの非特定的関係を洗練する。
  • 各エンティティのためのキー属性を定義する。
  • 外部キーを確立するため、主キーを移植する。
  • 関係性とキーを検証する。


フェーズ4 - 属性定義
フェーズ4は、モデル開発の最終段階である。この計画の目的は以下をするためである:
  • 属性プールを開発する
  • 属性のオーナーシップを確立する
  • 非キー属性を定義する
  • データ構造を検証し洗練する

IDEF1X メタモデル[編集]

IDEF1Xのメタモデル

IDEF1Xは、IDEF1Xそれ自身をモデル化するのに使える。メタモデルMetamodelingは、リポジトリ設計、ツール設計、あるいはIDEF1Xモデルの有効なセットを特定するためのように、様々な目的で使われる。目的に依存し、モデル結果はいくらか異なる。『一つの正しいモデル』は存在しない。例えば、段階的なモデル構築をサポートするツールのためのモデルは、不完全さ、あるいは不整合なモデルであってもそれを許さなければならない。正規化のためのメタモデルは、正規化の概念内での整合を強調する。不完全あるいは不整合のモデルは、そのためには提供されない。メタモデルに関する2つの重要な限界が存在する。最初、それらは構文を特定し、意味を特定しない。第2に、メタモデルは、自然または公式言語の制約内で補足されなければならない。IDEF1Xの公式理論は、意味論と必要な制約を正確に表す手段の両方を提供する。

IDEF1Xのメタモデルはここで与えられる。ビューの名前はmmである。ドメイン階層と制約もまた与えられる。制約は、モデルの正規理論における文章として表される。メタモデルは非公式に、普通の方法で有効なIDEF1Xモデルのセットを定義する。メタモデルはまた公式に、以下の方法で有効なIDEF1Xモデルのセットを定義する。IDEF1Xモデルとしてのメタモデルは、正規理論との対応を持つ。理論の意味論は、標準方法で定義される。そこで理論の解釈は、個別のドメインあるいは割当てのセットから構成される:

理論における各コンスタントには、ドメインにおける個別が割当てられる。
理論における各n-進機能には、ドメインを超えたn-進機能が割当てられる。
理論における各n-進記述記号には、Tドメインを超えたn-進関係が割当てられる。

意図された解釈において、個別のドメインは、生産;エンティティのように、部品とベンダー;ドメインのように、手持ち数量;接続関係;分類クラスタ;あるいはその他のように、ビューから構成される。もし理論的に全ての公理がその解釈で真なら、そこでその解釈は理論のためのモデルと呼ばれる。IDEF1X理論の各モデルは、IDEF1Xメタモデルと対応しており、そしてその制約は、有効なIDEF1Xモデルである。

下記も見よ[編集]

参照[編集]

 この記事にはアメリカ合衆国政府の著作物であるアメリカ国立標準技術研究所ウェブサイトもしくは文書本文を含む。.

  1. ^ a b c d e f g FIPS Publication 184 released of IDEF1X by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). 21 December 1993.
  2. ^ itl.nist.gov (1993) Integration Definition for Information Modeling (IDEFIX). 21 Dec 1993.
  3. ^ STRAP SECTION 2 APPROACH. Retrieved 30 September 2008.
  4. ^ Mary E.S. Loomis (1987). The Database Book. p. 26.
  5. ^ John F. Sowa (2004). [ "The Challenge of Knowledge Soup"]. published in: Research Trends in Science, Technology and Mathematics Education. Edited by J. Ramadas & S. Chunawala, Homi Bhabha Centre, Mumbai, 2006.
  6. ^ Gad Ariav & James Clifford (1986). New Directions for Database Systems: Revised Versions of the Papers. New York University Graduate School of Business Administration. Center for Research on Information Systems, 1986.

更なる読み物[編集]

外部リンク[編集]