LINEスタンプ制作代行サービス・LINEスタンプの作り方!

お電話でのお問い合わせ:03-6869-8600

stampfactory大百科事典

データモデル

データ・モデルは、班・要員間の意思疎通のための事業データを文書化し、組織化し、そして特にどのようにデータを格納し利用するかの、応用ソフト設計のための計画として使うソフトウエア工学の一つの抽象モデルである。Hoberman (2009)によれば、「データ・モデルは、組織内での意思疎通を改善し、それによってより柔軟で安定したアプリケーション環境に導く、真の情報の部分集合を正確に説明するシンボルとテキストの集合を使う、事業とIT専門家の両方のための、道筋を見つける道具である。」データ・モデルは、データまたは"構造化データ"の構造を明示的に決める。データモデルの代表的な応用は、データベース・モデル、情報システム の設計、及びデータの交換を可能にすることを含む。通常データ・モデルは、データ・モデリング言語によって規定する。コミュニケーションと精度は、データ・モデルがデータを使い交換する応用へもたらす2つの主要な利益である。データ・モデルは、異なる背景と異なる経験水準からなる事業要員がお互い意思疎通する媒体である。 精度は、データ・モデルにおける用語と規則をただ1つの方法で解釈することができ、そして曖昧さが無いことを仮定する。データ・モデルは、時には、特にプログラミング言語の文脈における、データ構造として参照する。データ・モデルは、事業体モデルの文脈で、しばしば、機能モデルで補完する。大量の構造化されたデータや構造化されないデータを管理することは、情報システムの主要な機能である。データ・モデルは、リレーショナル・データベースのようなデータ管理システムでの記憶装置のための構造化されたデータを記述する。 それらは、典型的に、ワードプロセッサ文書、電子メール、ピクチャ、音声あるいはビデオのような、非構造化データを記述しない。データ・モデルの主な目的は、データの定義とフォーマットを提供することによって、情報システムの開発を支援することである。West とFowler (1999)によれば、「もしこれがシステムを通して一貫して行われたら、そこでデータの互換性が達成されうる。もし同じデータ構造がデータの格納やアクセスに使われるなら、そこで異なるアプリケーションがデータを共有できる。これの結果は上で示される。しかしながら、システムとインタフェースは、しばしば、構築し、運用し、そして維持するため、それらがあるべきより多くのコストを費やす。それらは、事業を支援するよりむしろ制約するかもしれない。1つの大きな原因は、システムとインタフェースに実装されるデータ・モデルの品質が貧弱だったことである。」これらの問題の理由は、データ・モデルが事業ニーズと一貫性を保つことの両方に合致することを確かにする標準が不足していることである。データ・モデル"インスタンス"は、1975年のANSIに沿った3つの種類の1つかもしれない。ANSIによれば、このアプローチの重要性は、3つの観点がそれぞれ相対的に独立であることを可能にすることである。格納技術は、論理的あるいは概念モデルのいずれにも影響することなく変更できる。テーブル/カラム構造は、概念モデルに(必要なら)影響することなく変更できる。いずれの場合も、もちろん、その構造は他のモデルとの一貫性を残さなければならない。テーブル/カラム構造は、エンティティ・クラスや属性の直接変換からは異なるかもしれないが、しかし、それは究極的に概念エンティティ・クラス構造の目的の外で扱わなくてはならない。多くのソフトウエア開発プロジェクトの初期段階は、の設計を強調する。このような設計は、で詳細化される。その後段で、このモデルは、に変換されるかもしれない。しかしながら、概念モデルを直接実装することも可能である。情報システムのモデリングにおける最も初期の業績の1つは、「情報を規定する正確で抽象的な方法とデータ処理問題の時間的特徴」を論じた、Young と Kent (1958) によって為された。彼らは、「ハードウエアのあらゆる部分を取り巻く問題のためのに可能となるべき1つの表記法」を作ることを望んだ。彼らの作業は最初、異なるハードウエア・コンポーネントを使う異なる代替的実装を設計するための、1つの抽象仕様と不変の基盤を作る努力であった。情報システム・モデリングにおける次のステップは、「データ処理のシステム・レベルで、マシン独立の問題定義言語の正しい構造」を開発すると言う、本質的にYoung と Kentと同じことを目指した、1959年に編成されたIT業界コンソーシアムである、CODASYLによって行われた。これが1つの特定な情報システムの情報代数学 () の開発に導いた。1960年代にデータ・モデリングは、経営情報システム概念の導入と共に更にその重要性を増大させた。Leondes (2002)によれば、「必要なとき、情報システムは、管理目的のためデータと情報を提供する。この統合データ・ストア () と呼ばれる、第一世代データベースシステムが、GEのチャールズ・バックマンによって設計された。2つの有名なデータベース・モデル:ネットワーク型データモデル、及び階層型データモデルがこの期間中に提案された。」 1960年代の終わりに向けて、エドガー・F・コッドは、彼のデータ編成の理論を練り、一階述語論理に基づいたデータベース管理のためのリレーショナル・モデルを提案した。1970年代に実体関連モデルが、1976年にピーター・チェンによって初めて提案され、概念データ・モデルの新しいタイプとして出現した。実体関連モデルは、データベースに格納される情報ニーズや情報のタイプを記述するための、 要求分析中の情報システム設計の最初のステージで使われた。この技術は、あらゆる概念体系 、すなわち、一定の関心の領域のための、概念の全貌と分類とそれらの関連、を記述できる。 1970年代、 は、「自然言語情報分析手法」(NIAM) を開発し、そして1980年代にそれを発展させたオブジェクト役割モデリング () を と一緒に開発した。Jan L. Harrington (2000)によれば、更に1980年代に、「オブジェクト指向パラダイムの開発が、我々がデータとデータに作用する手続きを見る方法に基本的な変化をもたらした。伝統的に、データと手続きは:データベースにデータとそれらの関連、アプリケーション・プログラムに手続きをと、別々に格納されていた。オブジェクト指向では、しかしながら、そのデータと共にエンティティの手続きを組み合わせた。」データベース・モデル (database model)は、どのようにデータベースが構造化され、使われるかを記述する理論または仕様である。いくつかのそのようなモデルは提案されてきた。広く知られたモデルは以下を含む:データ構造ダイアグラム (DSD) は、エンティティとそれらの関連、及びそれらを拘束する制約 (constraints) を文書化する図式表記法を提供するよって、概念データモデルを記述するため使われる1つのダイアグラムでありデータ・モデルである。DSDの基本的図形要素は、エンティティを表すボックスと、関連を表す矢である。データ構造ダイアグラムは、複雑なデータ・エンティティを文書化するため最も有用である。データ構造ダイアグラムは、実体関連モデルの1つの拡張である。DSDで、関連が、エンティティ群を束ねる制約を規定する属性から構成されるボックスとして描かれる一方で、属性は、エンティティの、外側でなく、内側で規定される。実体関連モデルは、堅牢である一方で、関連同士の制約を規定する方法を提供せず、そして、いくつかの属性を持つエンティティを表現するとき視覚的に扱い難くなる。DSDは、DSDが1つのエンティティ内での要素の関連に焦点を当て、そしてユーザーに各エンティティ間のリンクと関連を完全に見せることができるのに対して、実体関連モデルでは異なるエンティティ間の関連に焦点を当てる点で、異なる。データ構造ダイアグラムを表現するため、多重度 (cardinality) を定義する方法に顕著な違いを伴う、いくつかのスタイルがある。選択は、鏃 、逆向き鏃 (鳥足) 、あるいは多重度の数値表現の間に存在する。実体関連モデルは、構造化されたデータを表現するためソフトウエア工学で使われる、1つの抽象概念スキーマ(または、意味的データモデル (semantic data model) )である。実体関連モデルのため使われるいくつもの表記法が存在する。地理情報システムにおけるデータモデル (data model) は、データとして地理的オブジェクトまたは地表を表現するための数学的概念である。たとえば、汎用データ・モデル (Generic data model) は、通常のデータ・モデルの一般化されたものである。それらは、そのような関係タイプによって関連付けられるかもしれないものの種類と一緒に、標準化された一般の関係タイプを定義する。汎用データ・モデルは、従来のデータ・モデルの欠点を解決する1つのアプローチとして開発された。例えば、異なるモデラーは一般に、同じドメインの異なる従来のデータ・モデルを作り出す。これは、異なる人々のモデルを一緒に集めることにおいて困難を導き、そしてデータ交換やデータ統合の障害である。しかしながら、この違いはいつも、モデルにおける抽象レベルの違いと、インスタンス化される事実の種類における違い(モデルの意味的表現能力)に帰因する。モデラーは、違いをより重要でないものにするため、より具体的に提示すべきである一定の要素についてコミュニケートし合意する必要がある。ソフトウエア工学における意味的データ・モデル (semantic data model) は、その他のデータとの相互関係性の文脈内でのデータの意味を定義する1つの技法である。意味的データ・モデルは、どのように格納シンボルがその実世界に関係させるかを定義する1つの抽象である。意味的データ・モデルは、時には、概念データモデル (conceptual data model) と呼ばれる。階層型、ネットワーク型データモデル、あるいはリレーショナル であろうと、データベース管理システム (DBMS) の論理的データ構造は、それがスコープとDBMSによって採用される実装戦略への偏った方向における限界があることから、データの概念的定義への要求を完全に満たすことはできない。そこで、概念的ビュー (conceptual view) からデータを定義する必要性が、意味的データ・モデリング技法の開発に導いた。それは、他のデータとの相互関係性の文脈内でのデータの意味を定義する技法である。図に示されるように。資源、アイデア、イベント、などの条項で、現実世界は、物理的データ・ストア内でシンボル化されて定義される。意味的データ・モデルは、どのように格納されるシンボルを実世界に関係させるかを定義する1つの抽象である。そこで、そのモデルは実世界の真の表現でなければならない。データ仕組 (Data architecture)は、目標状態の定義に使われるデータの設計であり、かつ目標状態に合致させるため必要とされる次に続く計画である。それは普通、事業体仕組、またはソリューション仕組 (solution architecture) の芯柱を形成するいくつかの仕組ドメイン (architecture domain) の1つである。データ仕組は、事業あるいはそのアプリケーションによって使われるデータ構造を記述する。データの格納と動きの2つの記述がある。格納におけるデータ記述はデータ・グループとデータ項目を記述し、動きにおけるデータの記述はデータの品質、アプリケーション、場所などへのそれらデータ創作物のマッピングを記述する。目標状態を実現する上で必須な、データ仕組の記述はどのようにデータが、与えられたシステム内で、処理され、格納され、取扱われるかである。それは、そのシステム内での、データ・フローを設計し、データの流れをコントロールすることも可能にするデータ処理運用のための基準を提供する。ソフトウエア工学における データ・モデリングは、データ・モデリング技法を使って公式のデータ・モデル記述を適用することによるデータ・モデルを作成するプロセスである。データ・モデリングは、データベースのための事業要求を定義するための1つの技法である。それは時には、1つのデータモデルがやがて1つのデータベースに実装されることから、"データベース・モデリング"と呼ばれる。図は、今日のデータ・モデルが開発され、そして使われる方法を描いている。概念データモデル (conceptual data model) は、開発されているアプリケーションのためのデータ要求に基づき、おそらくアクティビティ・モデルの文脈で開発される。そのデータモデルは通常、エンティティ・タイプ、属性、関連、完全性ルール、及びそれらのオブジェクトの定義から成る。これは、そこでインタフェースまたはデータベース設計のためのスタート・ポイントとして使われる。要求に合致するに必要なデータのいくつか重要な特性は:データ・モデルのもう1つの種類は、データベース管理システムまたは他のデータ管理技術を使って、どのようにデータを組織化するかを記述する。それは、例えば、リレーショナル・テーブルとカラムまたはオブジェクト指向クラスと属性を記述する。そのようなデータ・モデルは、時には、"物理データモデル (physical data model) "として参照されるが、ANSIのオリジナルの3層スキーマ仕組でそれは「論理的」と呼ばれる。その仕組において、その物理的モデルは、格納媒体(シリンダー、トラック、及びテーブル空間)を記述する。理想的にこのモデルは、上で記述されたより概念的なデータモデルから派生される。それは異なるかもしれないが、しかしながら、処理能力た用途パターンのような制約を記録する。"データ分析"がデータモデリングの共通の用語である一方で、実際的な活動は、それが(より一般的な概念から構成要素の概念を識別する)分析を伴って行われるより、(特定のインスタンスから一般の概念を推定する)"合成"の考えや手法を伴うのがより共通である。{"おそらく誰もシステム合成者と呼ばないことから、我々が我々自身をシステム分析者 (systems analysts) "と呼ぶ。} データ・モデリングは、不必要なデータの冗長性を排除し、関連でデータ構造を関連付けることで全体を、緊密し、分離不可に、一緒の関心のデータ構造にする努力をする。1つの異なるアプローチは、データの暗黙的モデルを自律的に作り出す人工ニューラル・ネットワークのような、適合システム (adaptive systems) の利用を通してである。データ構造は、データを効率的に使えるようコンピュータに格納する1つの方法である。それは、データの数学的かつ論理的な概念の1つの組織化である。しばしば、注意深く選ばれたデータ構造が、最も効率的なアルゴリズムの利用を可能とする。データ構造の選択はしばしば、抽象データ型の選択から始まる。データ・モデルは、与えられたドメイン内のデータの構造を、そのドメイン自身の基盤をなす構造をほのめかすことによって、記述する。これは、そのドメインに専用の人工言語の専用"文法"を、実際に規定することを意味する。データ・モデルは、企業が保持しようと望む情報、その情報の属性、及びそれらのエンティティ間の関連と(時には暗示的に)それらの属性間の関連についての、エンティティのクラス(ものの種類)を表現する。そのモデルは、どのようにデータがコンピュータ・システム内で表現されるかにかかわらず、いくらかの広がりへのデータの組織を記述する。データ・モデルによって表現されるエンティティは、触知可能なエンティティであり得るが、そのような具体的エンティティ・クラスを含むモデルは、時間を越えて変化する傾向がある。堅牢なデータ・モデルは、しばしばそのようなエンティティの抽象概念を認識する。たとえば、1つのデータ・モデルが、ある組織と関連する全ての人間を表す、「人材」と呼ばれるエンティティ・クラスを含むかもしれない。そのような抽象エンティティクラスは、それらの人材によって演じられる特定の役割を識別する「ベンダー」または「従業員」と呼ばれるより、一般に適切である。用語「データ・モデル」は、2つの意味を持ち得る:データ・モデル理論は、3つの主要なコンポーネントを持つ:例えば、関係モデルにおける、構造部分は数学的関係を修正した概念に基づき、完全性部分は一階述語論理で表現され、そして操作部分は 関係代数、タプル関係論理、及び ドメイン関係論理を使って表現される。データ・モデル・インスタンスは、データ・モデル理論を適用することで生成される。これは典型的に、ある事業の事業体要求を解決する。事業要求は、通常意味的論理モデル (logical data model) によって獲得される。これは、物理的データベースに生成されることから、物理的データ・モデル・インスタンスに変換される。例えば、データ・モデラーは、いくつかの事業の事業体の企業データ・リポジトリの実体関連モデルを生成するため、データ・モデリング・ツールを使う。このモデルは、リレーショナル・データベースを生成するため、リレーショナル・モデルに変換される。パターンは、多くのデータ・モデルで現れる共通のデータ・モデリング構造である。データ・フロー・ダイアグラムは、プログラムの"コントロール"の流れを示すフローチャートとは違い、情報システムを通しての"データ"の「流れ」を示す、図式表現である。データ・フロー・ダイアグラムはまた、データ処理 (構造化設計) の可視化 (visualization) のため使われうる。データ・フロー・ダイアグラムは、Martin と Estrin の コンピュータの「データ・フロー・グラフ」に基づいた構造化設計のオリジナル開発者である、Larry Constantine (Larry Constantine) によって考案された。それは、システムと外側のエンティティ間の相互作用を最初に示す、文脈レベル・データ・フロー・ダイアグラム (context-level Data flow diagram) を描く共通の実践である。DFDは、どのようにシステムが、分割された部分間のデータの流れに着目してより小さな部分に分割するかを示すため設計される。この文脈レベル・データ・フロー・ダイアグラムは、そこでモデル化されているシステムをより詳細に示すため「激増」される。情報モデルは、データ・モデルの一つのタイプではないが、一つの代替モデルより多いかまたは少ない。ソフトウエア工学の分野でのデータ・モデルと情報モデルの両方は、特性、関連、及びそれらで実行され得る操作を含め、エンティティ・タイプの抽象であり、公式表現である。モデル内のエンティティ・タイプは、ネットワーク内の機器のような、実世界のオブジェクトの種類かもしれないし、またそれらは、勘定システム内で使われるエンティティのような、抽象化されたそれら自身かもしれない。典型的に、それらは、エンティティ・タイプ、特性、関連、及び操作の閉じたセットによって記述される、制約されたドメインをモデル化するのに使われる。Lee (1999)によれば 、情報モデルは、選ばれた概説のドメインのデータ意味論 (data semantics) を規定する、概念、関連、制約、ルール、あるいは演算子の表現である。 それは、そのドメインの文脈のための共有性、安定性、及び情報要求の組織化された構造を提供する。一般的用語"情報モデル"はさらに、施設、ビルディング、プロセス・プラントなどのような、個々のもののモデルのため使われる。このような場合、概念は、ファシリティ情報モデル (Facility Information Model) 、ビルディング情報モデル (Building Information Model) 、プラント情報モデルなどと特定される。そのような情報モデルは、施設についてのデータと文書を伴う施設のモデルの統合である。情報モデルは、どのようにその記述がソフトウエアにおいて実際の実装にマップされたかの記述を制約することなく、問題ドメイン記述の形式主義を提供する。情報モデリングのマッピングには多くもものが存在する。そのようなマッピングは、それらが(UMLを使った)オブジェクトモデル (object model) 、実体関連モデル、または XMLのスキーマ (XML schema) であるかどうかにかかわらず、データ・モデルと呼ばれる。コンピュータ科学におけるオブジェクト・モデル (object model) は、プログラムがその世界のある特定な部分を試しそして操作できるオブジェクトあるいはクラスの集合である。言い換えるなら、ある種のサービスまたはシステムへのオブジェクト指向インタフェースである。そのようなインタフェースは、表現されたサービスまたはシステムの"オブジェクト・モデル"であると言える。たとえば、Document Object Modelは、ページを調べて動的変化をプログラムするスクリプトを使う、ウェブブラウザにおけるページ表現の集合である。Microsoft Excelを他のプログラムからコントロールするための、Microsoft Excelオブジェクト・モデルが存在するし、またASCOM (AStronomy Common Object Model)Telescope Driver は、天体望遠鏡をコントロールするための1つのオブジェクト・モデルである。コンピューティングにおける用語"オブジェクト・モデル"は、プログラミング言語技術、表記法、または 方法論を使うある特定なコンピュータにおけるオブジェクトの一般的特性とは別の2番目の意味をもつ。例は: "Javaオブジェクト・モデル"、 "Component Object Model"、あるいは、 "オブジェクトモデル化技法 (OMT) "。このようなオブジェクト・モデルは通常、 クラス、メッセージ、継承、多態性、 情報隠蔽のような概念を使って定義される。プログラミング言語の形式意味論 のサブセットとして形式化されたオブジェクト・モデルに関する膨大な文献が存在する。オブジェクト役割モデリング (ORM) は、概念的モデリング (conceptual modeling) のための1つの手法であり、情報やルールの分析のための1つのツールとして利用できる。オブジェクト役割モデリングは、概念レベルでのシステム分析のための1つの事実指向の手法である。データベース・アプリケーションの品質は、その設計に重大に依存する。正しさ、明確さ、適合性、及び生産性を確かにするのを助けるため、情報システムは、人々が容易に理解できる概念と言語を使って概念レベルで最初に規定されることがベストである。概念的設計は、データ、プロセス、及び振る舞い的観点を含むかもしれないし、その設計を実装のため使われた実際のDBMSは、(リレーショナル、階層型、ネットワーク型、オブジェクト指向等の)多くの論理的データ・モデルの1つに基づいたかもしれない。統一モデリング言語 (UML) は、ソフトウエア工学分野での、1つの標準汎用モデリング言語である。それは、ソフトウエア集約システムの成果物 (ソフトウエア開発) (artifacts) を、可視化し、規定し、構築し、そして文書化するための1つの図式言語 (graphical language) である。統一モデリング言語は、以下を含む、システムの青写真を描く標準方法を提供する。UML は、機能モデル、データ・モデル、及びデータベースモデル (database model) の1つのミックスを提供する。

出典:wikipedia

LINEスタンプ制作に興味がある場合は、
下記よりスタンプファクトリーのホームページをご覧ください。