概念データモデル

特定の製品や実装方式に依存せず、業務の対象と関係だけを表したデータモデル。E-R図で表現されることが多い。まずこれを作り、論理・物理データモデルへと具体化していく。

特定のDBMSや実装技術に依存せず、業務で扱う情報の構造をエンティティとリレーションシップで表したモデル。E-R図で記述されることが多く、業務の理解と関係者の合意形成に用いる。

現実世界のデータ要件を、DBMS非依存の形で抽象化して表現したモデル。ER図が代表的な表記法で、エンティティ、属性、関連を用いてデータ構造を記述する。データベース設計の第一段階として作成される。

実装方式を意識せず、業務上の実体と関係だけを表現したデータモデル。利用部門と合意を形成するための共通言語として使われる。

業務で扱うデータを、エンティティ、属性、エンティティ間の関連として表したデータモデル。特定のDBMSや実装方式に依存しない形で業務の意味を表現するもので、E-R図やUMLのクラス図で記述する。利用部門と業務ルールを確認する手段となり、これを論理データモデル、物理データモデルへと具体化していく。

対象とする業務で扱うデータを、特定のDBMSや実装方法に依存しない形で、実体（エンティティ）、属性、実体間の関連（リレーションシップ）として表したデータモデル。E-R図などで記述し、業務の理解と利用者との合意形成に使い、論理データモデルの基になる。

対象業務で扱うデータの構造、データ間の関連、データが守るべき制約（整合性制約）を、決められた表記で表したもの。抽象度に応じて、業務の実体と関連をE-R図などで表す概念データモデル、関係モデルなど特定のデータベースの方式に沿って表す論理データモデル、格納構造やインデックスまで決める物理データモデルの段階があり、上位から順に変換して設計する。

業務で扱うデータの要素とそれらの関係を図や記法で表現し、データ構造を設計すること。概念データモデル、論理データモデル、物理データモデルの順に詳細化し、E-R図などを用いる。システム間でデータの意味をそろえ、データ統合や品質確保の土台になる。

データベース設計において、同じデータが複数の場所に重複して格納されることを排除すること。正規化によりデータの一貫性を保ち、更新時の矛盾を防止する。

システム要件定義で明らかにする、データベースに関する要件。扱うデータの種類と量、保存期間、更新の頻度、アクセスの方法、整合性やバックアップの要件などを定め、データベース設計の前提にする。

対象の性質や特徴を表すデータ項目。オブジェクト指向ではクラスが持つデータを指し、操作（メソッド）と組にして定義する。データモデルではエンティティが持つ項目を指し、関係データベースでは表の列に対応する。

E-R図などで、関連する2つのエンティティのインスタンスが何対何で対応するかを表す性質。1対1、1対多、多対多があり、相手が存在しない場合を許すかどうか（0を含むか）も併せて表す。データベースの物理設計では、列に含まれる異なる値の個数を指す意味でも使い、値の種類が少ない列はビットマップインデックス、多い列はB木インデックスが向くといった索引の選択の根拠になる。