概念データモデルで扱うデータ構造とは何か。
一言で表現すると「データ項目とデータ項目の関係」です。
ただし、業務的になんらかの意味が対応することが条件です。
データ項目とデータ項目の関係をもう少し細かくみると、次の関係が見つかります。
１ ＫＥＹとＲＫＥＹ（リファレンシングＫＥＹ）の関係
ＫＥＹはエンティティの存在を（エンティティとしてではなく）データとして表現したものです。ＫＥＹとＲＫＥＹの関係は、意味的にはエンティティとエンティティの関係に対応します。
２ ＫＥＹと従属データ項目の関係
まさに関数従属の関係です。ＫＥＹの値を決めると従属データ項目の値が決まります。ただし、概念データモデル上では第一正規形や第二正規形を扱いませんから注意が必要です。エンティティとそのエンティティが持つデータ項目の関係と言ってもよいでしょう。
３ 加工データと加工元データの関係
概念データモデル上には加工データ（導出データと呼ぶ人もいる）も表現します。加工データの値は、いくつかの加工元データを計算して求められます。図上で加工データかそうでないかを表現することは可能ですが、加工式まで記述することはありません。一般に、加工データと加工元データの関係は、データ定義書に記述されることになります。
４ チェックデータとチェック元データの関係
いくつかのデータ項目どうしの整合性を保つために、チェックデータが必要になることがあります。受注年月日＜出荷年月日をチェックするために、揮発性のデータ（プログラムの中だけで生まれて死んでいくデータ）たとえば「受注出荷順序チェックデータ」を認識し、そのチェックデータと受注年月日・出荷年月日の関係を定義します。以前の日記でデータ制約としても紹介しています。
上記の１・２は概念データモデル上で確認できますが、３・４は確認できません。また、１・２だけをデータ構造とみなす人もいるでしょう。
いずれにしても、データ構造とは業務的に意味のあるデータ項目間の関係です。正しい業務設計のためには３・４まで含めてユーザのレビュが必要であると思います。
