DFD・E-R図・決定表とコード設計

結論：図は「何を描くか」で見分ける

設計図の問題は、その図が何を描くためのものかを言えれば解けます。データの流れならDFD、データ同士の関係ならE-R図、状態の変化なら状態遷移図、条件の組合せなら決定表です。

選択肢では、ほかの図の説明がそのまま混ぜられます。キーワードで見分けてください。

DFD：○はプロセス、二本線はデータストア

DFD（Data Flow Diagram）は、業務のなかでデータがどこからどこへ流れ、どこで加工されるかを描く図です。処理の順番や分岐は描きません。記号は4つだけで、試験には「○は何か」「表記として正しいのはどれか」の形で出ます。

たとえるなら、DFDは宅配便の配送図です。荷物（データ）が矢印に沿って動き、営業所（○）で仕分けされ、倉庫（＝）に保管され、送り主・受取人（□）が両端にいます。

flowchart LR
  A["□ 外部：顧客"] -->|"注文データ"| B(("○ プロセス：受注処理"))
  B -->|"受注データ"| C[("＝ データストア：受注ファイル")]
  C -->|"受注データ"| D(("○ プロセス：出荷指示"))
  D -->|"出荷指示"| E["□ 外部：倉庫"]

ひっかけの型：円に「ファイル名を付ける」（→それはデータストア）、四角に「画面や帳票の名前を付ける」（→四角は外部の人・組織）、二本線を「同期」と説明する（→同期の意味はない）。正しいのは矢印にデータの名前を付けるです。選択肢「アクティビティ」はUMLのアクティビティ図の用語で、DFDの記号ではありません。

E-R図：実体と関連でデータを描く（最頻出）

E-R図（Entity-Relationship図）は、システムで管理したい対象をエンティティ（実体）として、エンティティどうしのつながりをリレーションシップ（関連）として描く図です。「顧客」「注文」「商品」が箱になり、「顧客は注文を複数する」のような関係を線で結びます。

• エンティティ：管理対象のこと。顧客・商品のような物だけでなく、「注文」「契約」のような形のない出来事もエンティティになります。
• 属性（アトリビュート）：エンティティの特性。顧客なら氏名・住所。エンティティは属性をもつのが正しい説明です。
• インスタンス：エンティティの具体的な1件（顧客「山田さん」）。エンティティ1つにインスタンスは多数あるので、「1対1」ではありません。
• リレーションシップ：エンティティ間の関係。1対多・多対多などの数の対応を表します。業務の手順や状態遷移は表しません。

E-R図は概念データモデル（実装方法を決める前に、業務のデータを整理したもの）です。そのため「関係データベースの表として実装することを前提に表現する」は誤りです。

ひっかけの型：「時間や行動に応じて状態が変化する」（→状態遷移図）、「データの流れを表す」（→DFD）、「データの生成から消滅までの操作」（→E-R図の役割ではない）、「オブジェクト指向モデル」（→UML）。実体と関連の2語があればE-R図です。

状態遷移図：イベントで状態が変わるシステム向け

状態遷移図は、システムがとる状態、状態を変えるきっかけ（イベント：時間の経過・センサの信号・ボタン操作など）、そのとき実行する動作を描く図です。信号機が「青→黄→赤」と時間で切り替わるのが典型的な例です。

「状態遷移図が向くシステムはどれか」もよく出ます。答えはセンサや信号で状態が変わる制御系です（例：温室制御・エレベータ・自動販売機）。

集計・計算・帳票出力のようなバッチ処理（データをまとめて処理する方式）は、データの流れが中心なのでDFDやE-R図で設計します。

決定表とデータ中心アプローチ

決定表（デシジョンテーブル）は、条件の組合せと、それぞれに対してどの動作をするかを表の形で整理したものです。「会員か」「購入額が1万円以上か」の組合せごとに割引率を決める、という使い方をします。

データ中心アプローチ（DOA：Data Oriented Approach）は、業務の処理手順よりも先に、業務で扱うデータの構造に注目してシステムを設計する考え方です。データを全社の共有資源とみなして一元管理するので、業務の手順が変わってもデータ構造は変わりにくくなります。

ファイルの項目から出せる集計を判断する

「このファイルで出力できる集計はどれか」という問題は、集計の軸ごとに、その期間のデータがどのファイルにあるかを確かめれば解けます。表を結合すれば何でも出せる、と考えると間違えます。

確認するのは次の2点です。

1. 集計の軸（顧客別・商品別・担当者別など）を表す項目が、そのデータに付いているか。
2. 期間（当月・過去の月・日別）のデータがあるか。日別の集計なら日付の項目が必要です。

解き方は下の例題を見てください。

コード設計：コード体系とチェックディジット

コード設計は、商品・顧客などに付ける番号の付け方を決める作業です。試験には体系の名前を答える問題と、入力ミス対策の問題が出ます。

チェックディジット（検査文字）は、コードの値から決まった計算（モジュラス11など）で求めた数字を末尾に付け、入力されたコードの値の誤り（打ち間違い・数字の入れ替え）を見つける仕組みです。入力ミスが業務に重大な影響を与えるコードでは採用します。

コード設計の原則は次のとおりです。

• 付番は業務を知っている人が行う（システム設計担当者に任せない）。
• 属性や桁数は、コンピュータの処理効率より使いやすさ・将来の拡張を重視して決める。
• 追加・廃止・変更の保守方法は設計段階で決める（運用テストまで待たない）。

試験での問われ方

• 「○は何か」：プロセス。二本線（データストア）・矢印（データフロー）・アクティビティ（UMLの用語）を混ぜてきます。
• 「〇〇図の説明はどれか」：4つの選択肢が、DFD・E-R図・状態遷移図・決定表／流れ図／UMLの説明になっています。キーワード（データの流れ／実体と関連／状態とイベント／条件の組合せ）で選びます。
• 「状態遷移図が適切なシステム」：センサや信号を使う制御系を選びます。集計・計算・帳票のシステムはひっかけです。
• 「チェックディジットの目的」：コードの値の誤りの検出です。英字の混入（数値チェック）、桁数（桁数チェック）、範囲外の値（範囲チェック）は、それぞれ別の入力チェックです。
• 「出せない情報はどれか」：日付・期間・集計軸の項目が、本当にその表にあるかを確かめます。