こんにちは！ 要件定義①【情報活用とデータベース編】 (羽生章洋)

書籍情報

• 著者:羽生章洋(著)
• 発行日:2025-10-21
• ISBN:9784297152376
• URL:https://gihyo.jp/book/2025/978-4-297-15237-6

書籍目次

• 目次
• 第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は必ず列として持つ！
  • データ構造を疎結合に保つ
  • 「いつ」「誰が」「どのように」コード体系を決めるのか