出版書誌データベース

「ITを活用できる人材」が求められています。私たちの仕事のすべてにおいて「情報」が関わっているといっても過言ではありませんが、ITは「情報を活用するための文明の利器」と言えます。情報は物理的な存在ではないため、扱うのが難しく、手間もかかります。それゆえ、ITという文明の利器によって、情報をしっかり記録し、その記録を縦横無尽に活用して、仕事をもっとスムースに行いたいのです。そしてそのための基盤・土台となるのがデータベースです。
そうした社会的要請、企業活動の根本的ニーズでもあるIT活用、さらにはデジタル時代の情報活用の土台としてデータベースを活用し、データベースに保管するためには、データの要件を定義するデータモデリングを行います。
本書では、IT、そして情報をどのように捉えればよいのか解説したうえで、データモデリングの手順をわかりやすく解説します。

STEP 1　IT 活用対象の仕事を決める
STEP 2　必要な情報を定義する
STEP 3　情報の中身＝データ構造を定義する
STEP 4　情報のやり取り方法（API）を定義する
STEP 5　裏方のアクションの中身を考える
STEP 6　必要なデータがデータベースに保存されているか確認する
STEP 7　データ構造を正規化（整理）する
STEP 8　ERD（ER 図）を描く

実務でよく見かける場面を取り上げたサンプル集も収録しました。
「ビジネス × IT企画」シリーズ」第1弾として、ITを活用し、DX企画ができるようになるために必要な要件定義について、「情報活用とデータベース」にフォーカスしてお届けします。

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

著：羽生 章洋
エークリッパー・インク代表　1968 年6 月1 日生まれ、大阪育ち。1989 年、桃山学院大学社会学部社会学科を中退後、2 つのソフトウェア会社にてさまざまな業種・業態向けシステム開発を経て、アーサーアンダーセン・ビジネスコンサルティング（当時）に所属。その後、トレイダーズ証券株式会社（当時）とマネースクウェアジャパン株式会社（当時）の新規創業に参画、両社にて当時としては先進的なリッチクライアントとOSSによるオンライントレーディングシステムを実現。2006 年から2011 年まで、国立大学法人琉球大学の非常勤講師。現在は、企業向けにデジタル人材育成を中心に活動、現場主導による問題解決の企画立案や業務とIT の架け橋としての要件定義などの支援などを行っている。