データモデル
データアーキテクチャ(英語版)は、目標状態の定義に使われるデータの設計であり、かつ目標状態に合致させるため必要とされる次に続く計画である。それは普通、ビジネスアーキテクチャ、またはソリューション仕組(solution architecture)の芯柱を形成するいくつかの仕組ドメイン(architecture domain)の1つである。
データアーキテクチャは、事業あるいはそのアプリケーションによって使われるデータ構造を記述する。データの格納と動きの2つの記述がある。格納におけるデータ記述はデータ・グループとデータ項目を記述し、動きにおけるデータの記述はデータの品質、アプリケーション、場所などへのそれらデータ創作物のマッピングを記述する。
目標状態を実現する上で必須な、データアーキテクチャの記述はどのようにデータが、与えられたシステム内で、処理され、格納され、取扱われるかである。それは、そのシステム内での、データ・フローを設計し、データの流れをコントロールすることも可能にするデータ処理運用のための基準を提供する。
データ構造は、データを効率的に使えるようコンピュータに格納する1つの方法である。それは、データの数学的かつ論理的な概念の1つの組織化である。しばしば、注意深く選ばれたデータ構造が、最も効率的なアルゴリズムの利用を可能とする。データ構造の選択はしばしば、抽象データ型の選択から始まる。
データ・モデルは、与えられたドメイン内のデータの構造を、そのドメイン自身の基盤をなす構造をほのめかすことによって、記述する。これは、そのドメインに専用の人工言語の専用文法を、実際に規定することを意味する。データモデルは、企業が保持しようと望む情報、その情報の属性、およびそれらのエンティティ間の関連と(時には暗示的に)それらの属性間の関連についての、エンティティのクラス(ものの種類)を表現する。そのモデルは、どのようにデータがコンピュータ・システム内で表現されるかにかかわらず、いくらかの広がりへのデータの組織を記述する。
データモデルによって表現されるエンティティは、触知可能なエンティティであり得るが、そのような具体的エンティティ・クラスを含むモデルは、時間を越えて変化する傾向がある。堅牢なデータモデルは、しばしばそのようなエンティティの抽象概念を認識する。たとえば、1つのデータモデルが、ある組織と関連する全ての人間を表す、「人材」と呼ばれるエンティティ・クラスを含むかもしれない。そのような抽象エンティティクラスは、それらの人材によって演じられる特定の役割を識別する「ベンダー」または「従業員」と呼ばれるより、一般に適切である。
配列
ハッシュテーブル
連結リスト
スタック構造
論理スキーマ:特定のデータ操作技術によって表現されるような、意味論を記述する。これは、他のものの間の、テーブルおよびカラム、オブジェクト指向クラス、およびXMLタグの解説からなる。
物理スキーマ:データが格納される物理的手段を記述する。これは、パーティション、CPU、表空間、あるいはそのようなことに係わる。
ANSIによれば、このアプローチの重要性は、3つの観点がそれぞれ相対的に独立であることを可能にすることである。格納技術は、論理的あるいは概念モデルのいずれにも影響することなく変更できる。テーブル/カラム構造は、概念モデルに(必要なら)影響することなく変更できる。いずれの場合も、もちろん、その構造は他のモデルとの一貫性を残さなければならない。テーブル/カラム構造は、エンティティ・クラスや属性の直接変換からは異なるかもしれないが、しかし、それは究極的に概念エンティティ・クラス構造の目的の外で扱わなくてはならない。多くのソフトウエア開発プロジェクトの初期段階は、概念データモデル(英語版)の設計を強調する。このような設計は、論理データモデル(英語版)で詳細化される。その後段で、このモデルは、物理データモデル(英語版)に変換されるかもしれない。しかしながら、概念モデルを直接実装することも可能である。