こんにちは！ 要件定義①【情報活用とデータベース編】 (羽生章洋)
書籍情報
- 著者:羽生章洋(著)
- 発行日: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は必ず列として持つ！
- データ構造を疎結合に保つ
- 「いつ」「誰が」「どのように」コード体系を決めるのか
第2章 必要な情報を定義する
そもそも情報とは何か？
- 情報とは何か？
- データの集まり
- データとは何か？
- 項目と値のセット
- 例:
{name: "Taro"}
- データ構造とは何か？
- 複数のデータの組み合わせ
データ構造とインスタンス
- データ構造 == 雛形
- インスタンス == 雛形のデータ構造に具体的な値が入った状態
仕事に必要な情報を考える
- N/A
情報屋さんとしてのITくんの仕事を考える
- 必要な情報に名前を付ける
- 情報の名前の重複はNG
情報を構成するデータ構造を考える
- データ構造を考える
- データモデリングを行う
- データ構造の名前とそこに入る項目名
- データ構造を図にするのがデータモデリング
- ITを活用するにはデータモデリングが重要
- 項目名の重要性
- 項目名が曖昧だと後続の作業の品質に大きな影響を与える
窓口と裏方に分けて考える
- ITがユーザーに提供する価値2種
- 情報をユーザーに提供する
- ユーザーから受け取った情報を保管する
- 本書での呼び方
- Get系のAPI
- Put系のAPI
- [MEMO]
- 想定読者が非エンジニアなので分かりやすさ優先