目次

第1章　仕事と情報とIT

• もっとITを活用したい！
• ITとは何か？
• 情報とは何か？
• 情報に囲まれた日常生活
• 情報がなくなるとどうなる？
• なぜ情報が必要になるのか
• 情報とは、残したいこと
• 情報を扱うためのテクノロジー
• 忘却との戦い
• 紙とデジタル
• コンピュータの登場
• 日常生活と仕事
• 仕事とは何か
• 仕事とは──活動と成果
• 仕事とは──インプット・活動・アウトプット
• 仕事の本質──変換、状態の変化
• プロセス
• 仕事を行うタイミング
• 他からのリクエストがあったとき
• ある条件を満たしたことを検知したとき
• ストア（保管）の重要性
• ストアをめぐる問題
• 仕事と情報
• 喫茶店の事例
• 仕事における情報とは
• 情報は事実の後追い
• 仕事における情報を扱うためのIT
• UI ──人とデジタルの接面
• ITを活用する目的

第2章　必要な情報を定義する

• そもそも情報とは何か？
• 情報の定義
• データとは
• データ構造
• データ構造とインスタンス
• データ構造＝ひな形
• インスタンスとは
• 仕事に必要な情報を考える
• 要件を定義する
• 小さいレストランの仕事の流れ
• インプットから始める
• 情報屋さんとしてのITくんの仕事を考える
• 情報屋さんとしてのITくんの立場で考える
• 必要な情報を集めて名前をつける
• 情報を構成するデータ構造を考える
• データ構造名を考える
• データモデリングを行う
• 項目名の重要性
• 繰り返し項目の明示
• 窓口と裏方に分けて考える
• ゲット系の情報とプット系の情報
• APIの利点
• ゲット系のAPIとプット系のAPI

第3章　情報をつくる処理を考える

• データベースを扱うという仕事
• アウトプットのための処理を考える
• パターン1：そのままコピペする
• パターン2：計算する
• パターン3：変換する
• 絞り込む
• 集計する
• 並べ替える
• アウトプットする項目に値を設定する
• 保存系のアクション
• 取得系に必要なデータを正しく保存する
• データ構造を正規化する
• 正規化の必要性
• 人間は面倒くさがり
• データ（構造）を整理整頓しよう
• 1つの事実は1つの場所に
• エンティティを設定する
• エンティティ
• データ構造とエンティティの関係
• エンティティの定義＝データ構造の定義
• 1つの項目には1つの値のみ
• @で繰り返しを表す
• 共通のデータを切り出して1つのエンティティにまとめる
• 明細部分を切り出して別のエンティティにする
• リレーションシップ（関係／関連）
• 削除する
• 更新する
• 複数のエンティティを同時に扱う
• ジョイン（結合）
• トランザクション（一括処理）

第4章　実務に沿ったデータモデルを考える

• 現実をエンティティに写し取る
• データモデリングの手順を再確認する
• データモデリング手順のポイント
• レストランの業務で実践してみる
• 知りたい情報の定義とAPI設計
• データの流れ（データフロー）とプット系API
• さらに記録が必要になったとき
• 情報の名前づけ
• エンティティの統合
• 存在系と活動系
• 「注文」データモデルに見る存在系と活動系
• 存在系と活動系の見分け方
• 「概念系」の導入
• 「状態」という概念
• 区分による状態管理
• 「区分」で見分けるのではなく、別々のエンティティと捉える
• 状態系エンティティの捉え方
• 「残」という概念
• 残系をエンティティとして扱う
• 仕事どうしの紐づけ
• 紐づけを管理する交差エンティティ
• 複雑な仕事への柔軟な対応
• 活動系は交差エンティティか？
• その他の交差エンティティの例
• 対応づけとしての「構成」
• 親子関係と同一エンティティ内のリレーションシップ
• 部品表
• 複雑な分類の構造を考える
• 分類も親子関係として扱う
• 交差と交差が交差すると？
• 交差エンティティの発展形
• プロセス系エンティティ
• ビジネスのデジタル化とデジタルツイン

第5章　エンティティの項目を考える

• 項目とは何か
• 項目名の決め方
• 定量化と単位の重要性
• 項目を分割する際の注意点
• 項目名に持たせる意味を統一する
• 「備考」という項目名をどう扱うか
• エリアス・ホモニム・シノニムの問題
• IT活用を成功させる項目名定義
• 入れてもよい値を制限する
• 値の制限とバリデーションルール
• データ型の設定
• 項目が持つデータ型は1つだけ
• 値の制約と列挙型
• 外部参照制約
• 値の決まり方を考える
• 導出項目と導出ルール
• 導出ルールの設定手順
• ビジネス要件による導出ルールの複雑化
• 初期値、デフォルト値
• リクエストパラメータにまつわる項目
• 表示にまつわる項目
• 並び順の管理
• 並び順を決めるのは「人間の仕事」
• 表示／非表示を切り替える
• 論理削除
• 値が定まらない場合
• NULL値とは何か
• NULL値の使用をめぐる論争
• NULL値を避ける弊害
• 「事実がない」という事実の記録
• NULL値による「事実がない」ことの表現
• 部分と一括と数
• 部分対応と一括対応：注文と出荷の例
• 数量（個数）という概念の再考
• 本質的な事実を捉える

第6章　キーとID

• キーとは何か
• キー（候補キー）の決め方
• プライマリーキー、セカンダリーキー
• ユニークキーと重複キー
• キーの定義＝制約
• 複合キー
• 「事実の存在そのもの」を表現するためのID
• IDとキーの違い
• 事実、記録、キーのライフサイクル
• IDを識別の手がかりとする
• キーの値は人間が決める
• IDの値の決め方
• IDとキーは併存できるか
• 本章のまとめ

第7章　サンプル集

• 本章のはじめに
• 異なるコード体系を紐づけて統一的に扱う
• 商品とオプションの対応関係
• 有効期間と事前登録
• 区分と種別
• 契約エンティティ
• 所属エンティティ
• 履歴やバージョン管理の扱い
• 階層構造と親子関係
• 状態の遷移
• 状態の表現
• 期間とNULLの扱い
• 未登録あるいは事後登録の扱い
• 残系エンティティ：在庫と残高
• 横持ちデータ

第8章　まとめ

• データモデリング手順のまとめ
• STEP 1 IT活用対象の仕事を決める
• STEP 2 必要な情報を定義する
• STEP 3 情報の中身＝データ構造を定義する
• STEP 4 情報のやり取り方法（API）を定義する
• STEP 5 裏方の活動（アクション）の中身を考える
• STEP 6 必要なデータがデータベースに保存されているか
• 確認する
• STEP 7 データ構造を正規化（整理）する
• STEP 8 ERD（ER図）を描く
• エンティティの分類
• 基本的なエンティティの分類
• エンティティ同士の紐づけとしての交差エンティティ
• エンティティの項目
• 項目の設計視点：6W3H
• 意味のブレ防止
• データ型と制約（バリデーション）
• キーとID
• キーの定義と目的
• IDの本質（キーとの違い）
• 「こんにちは！」の日々の証に

コラム

• スキーマ
• 混ぜるな項目名！
• 繰り返しを表す「＠」について
• 情報伝達とデータベースの関係
• インターフェイスという考え方
• SQLを使う：SELECT文
• INSERT文
• ID項目の命名規則
• データモデルの表記法について
• エンティティとテーブルの話
• テーブルと表計算ソフト
• データのライフサイクルを考える
• DELETE文
• UPDATE文
• 更新禁止？
• 実際には削除していない？
• JOIN ... ON
• RDB以外のデータベース
• SQLノススメ
• 存在系／活動系とリソース系／イベント系
• 「在庫」は最大級のグローバル変数
• リレーションシップとは何か？
• 「関係というインスタンス」のライフサイクル
• 本書の例における顧客マスターのこと
• 交差エンティティをマトリックスで表現すると
• プロセス系エンティティの名前づけ
• ロングトランザクション
• プロセス系エンティティと状態管理
• 汎用的なリファレンスモデルとしての飲食業
• 事業／業務の複雑さはエンティティ数とリレーションシップに現れる
• ビジネスや業務のすべてをデータモデルだけで表せるわけではない
• 定量化ということ
• 人間は面倒くさがり
• 項目名をエンティティ名で修飾するかどうか問題
• ブール値とブール型
• 可変長と固定長
• COBOLが根強い理由
• 「数値のみ」という想定の落とし穴
• すべてを文字列型にする？
• 制約ルールの明記とモデリング
• 導出ルールのドキュメント化とデータモデル
• 導出項目は排除すべきか
• 「率」という導出項目
• 入力支援について
• 論理削除についての私見
• マイクロトランザクション
• GROUP BYで考えると
• UIで入力した数量分だけインスタンスを作る作戦
• ビッグデータは細かい？
• キーの本性
• アスタリスクとインスタンス
• IDとCREATE TABLE文のPK制約
• サロゲートキーの話
• IDは必ず列として持つ！
• データ構造を疎結合に保つ
• 「いつ」「誰が」「どのように」コード体系を決めるのか