【第3回】データベース設計入門：在庫管理アプリの要件定義からER図まで

AppSheetでアプリ開発を進める中で、あなたはデータ連携の重要性を実感し、Ref型や逆参照といった機能の強力さを体験したことでしょう。しかし、アプリが複雑になるにつれて、「このデータはどこに置くべきか？」「どうすればデータの重複を防げるのか？」といった、より根本的な疑問に直面するかもしれません。これこそが、データベース設計の入り口です。

私自身、AppSheetで簡単な在庫管理アプリを作り始めた頃は、スプレッドシートにデータを詰め込むだけで十分だと考えていました。しかし、管理する物品の種類が増え、入出庫の履歴が複雑になるにつれて、データの管理が煩雑になり、意図しない在庫数の不整合に悩まされるようになりました。その時、データベース設計の基礎を学ぶことの重要性を痛感したのです。

この連載第3回では、初級ITエンジニアの皆さんが、ビジネスの要件をどのようにデータベースの構造に落とし込むのか、そしてデータの整合性を保つための「正規化」とは何かを、具体的な演習を通して習得することを目的とします。特に、在庫管理アプリを例に、要件定義からエンティティ・属性の抽出、そしてER図の作成までを実践的に解説します。この記事を読み終える頃には、あなたはAppSheetアプリの裏側にあるデータ構造をより深く理解し、より堅牢で拡張性の高いアプリを設計するための基礎を身につけているはずです。さあ、データベース設計の奥深い世界へ踏み出しましょう！

[目次を開く]

本記事でできるようになることデータベース設計の全体像と重要性第1章：要件定義からテーブル設計へ（業務フローをモデリングする方法）第2章：ER図の作成演習（在庫管理アプリ） AppSheet用語表 FAQ 次回予告/CTA 関連記事

本記事でできるようになること

データベース設計の重要性と、要件定義からテーブル設計までの全体プロセスを理解できます。
在庫管理アプリを題材に、業務ヒアリング、ユースケース定義、業務シナリオ、ユーザーストーリーを通じて、ビジネス要件を明確にする方法を習得できます。
業務プロセスからエンティティ（テーブル候補）と属性（カラム候補）を抽出し、データベースの基礎構造を設計するスキルを身につけます。
ER図（Entity-Relationship Diagram）の基本記号と、エンティティ間のリレーションシップ（1対1、1対多、多対多）の表現方法を理解し、実際にER図を作成できます。
多対多の関係を中間テーブルで解消する方法や、マスタテーブルの設計など、実践的なER図作成演習を通じて、より複雑なデータ構造を設計する力を養います。
AppSheetアプリのデータ構造をより深く理解し、堅牢で拡張性の高いアプリを設計するためのデータベース設計の基礎を習得できます。

データベース設計の全体像と重要性

AppSheetのようなノーコードツールを使えば、データベースの知識がなくても手軽にアプリを作成できます。しかし、アプリが成長し、扱うデータ量が増え、機能が複雑になるにつれて、データの管理がボトルネックになることが少なくありません。ここで重要になるのが「データベース設計」です。

データベース設計とは、ビジネスの要件を分析し、それを効率的かつ整合性の取れたデータの構造に落とし込むプロセスです。このプロセスをきちんと踏むことで、以下のようなメリットが得られます。

データの整合性: 重複や矛盾のない、信頼できるデータを維持できます。
データの効率性: 必要な情報を素早く取得・更新できる構造になります。
アプリの拡張性: 将来的な機能追加や変更に柔軟に対応できる基盤ができます。
メンテナンス性: データ構造が明確になり、問題発生時の原因特定や修正が容易になります。

私自身、初期のAppSheetアプリ開発では、スプレッドシートにデータを無計画に追加していった結果、後からデータの修正が困難になったり、新しい機能を追加しようとすると既存のデータ構造が邪魔になったりといった経験をしました。その経験から、たとえAppSheetであっても、その裏側にあるデータ構造を意識し、適切に設計することの重要性を痛感しました。

データベース設計は、大きく分けて以下のステップで進められます。

1.要件定義: 何を解決したいのか、どのようなデータが必要なのかを明確にする。

2.概念設計: 業務上の概念（エンティティ）とそれらの関係性を洗い出す。

3.論理設計: 概念設計を基に、具体的なテーブルとカラム、リレーションシップを定義する（ER図の作成）。

4.物理設計: 論理設計を特定のデータベース管理システム（DBMS）に合わせて最適化する。

この連載では、特に初級ITエンジニアの皆さんがAppSheetアプリ開発に活かせるよう、要件定義から論理設計（ER図作成）までのプロセスに焦点を当てて解説していきます。

第1章：要件定義からテーブル設計へ（業務フローをモデリングする方法）

この章では、ビジネスの要件をどのようにデータベースの構造に落とし込んでいくか、そのプロセスを具体的に学びます。特に、業務フローを理解し、そこからデータベースのテーブル候補を抽出する方法に焦点を当てます。

要件定義とは何か（業務ヒアリング〜ユースケース定義）

システム開発は、まず「何を作るべきか」を明確にすることから始まります。この「何を作るべきか」を明確にするプロセスが要件定義です。要件定義が曖昧だと、開発の途中で方向性がブレたり、完成したシステムがビジネスのニーズに合わないものになったりするリスクがあります。

要件定義の初期段階では、主に以下の活動が行われます。

業務ヒアリング: システムを導入する現場の担当者から、現在の業務内容、課題、システムに求めることなどを詳細に聞き取ります。これにより、現状の業務フローや潜在的なニーズを把握します。
ユースケース定義: ヒアリングで得られた情報をもとに、システムが提供する機能と、それを利用するユーザーとの相互作用を具体的に記述します。例えば、「ユーザーは物品を登録する」「ユーザーは在庫を出庫する」といった形で、システムの振る舞いを明確にします。

実体験: 私が初めて在庫管理システム開発に携わった際、要件定義の重要性を痛感しました。現場の担当者から「在庫数を正確に把握したい」という要望を聞き、すぐに開発に取り掛かった結果、入出庫の細かいルールや棚卸しのプロセスなど、考慮すべき点が抜け落ちていたのです。その経験から、開発を始める前に徹底的な業務ヒアリングとユースケース定義を行うことの重要性を学びました。特に、現場の「暗黙のルール」をいかに引き出すかが、要件定義の腕の見せ所だと感じています。

業務フローの整理（業務シナリオ・ユーザーストーリー作成）

要件定義で得られた情報を整理し、システムの利用イメージを具体化するために、業務フローを整理します。これには、業務シナリオやユーザーストーリーの作成が有効です。

業務シナリオ: 特定の業務プロセスにおける具体的な一連の操作や出来事を、物語形式で記述します。これにより、システムがどのように使われるかを詳細にシミュレーションできます。
1.ユーザーがログインする。

2.ユーザーが出庫したい物品を検索し、選択する。

3.出庫数量を入力する。

4.出庫先の現場リストを選択または新規作成する。

5.出庫内容を確認し、出庫を確定する。

6.在庫数が減少し、出庫履歴が記録される。
ユーザーストーリー: アジャイル開発でよく用いられる手法で、「〜として、〜したい。なぜなら〜だからだ。」という形式で、ユーザーの視点から機能の価値を簡潔に記述します。
- 現場担当者として、現場に持ち出す物品を簡単に出庫したい。なぜなら、作業を効率化したいからだ。
- 管理者として、現在の在庫数をリアルタイムで把握したい。なぜなら、欠品を防ぎたいからだ。
- ユーザーとして、過去の入出庫履歴を確認したい。なぜなら、物品の動きを追跡したいからだ。

エンティティ抽出（名詞からテーブル候補を見つける）

業務フローやシナリオ、ユーザーストーリーを詳細に分析すると、データベースに保存すべき「情報の実体」が見えてきます。これがエンティティです。エンティティは、通常、名詞として表現されることが多いです。

上記の在庫管理アプリの例から、エンティティ候補を抽出してみましょう。

在庫マスタ (ITEMS)
入出庫履歴 (HISTORY)
現場リスト (PROJECTS)
現場持ち出し明細 (PROJECT_ITEMS)
ユーザー (USERS)
物品種類 (ITEM_CATEGORIES)
保管場所 (LOCATIONS)
現場カテゴリ (PROJECT_CATEGORIES)

これらのエンティティ候補が、後のデータベースのテーブルの元となります。

属性抽出（動詞・状態からカラム候補を見つける）

エンティティが抽出できたら、次にそのエンティティがどのような「情報」を持っているかを考えます。これが属性です。属性は、エンティティを具体的に記述するもので、動詞や状態を表す言葉から見つけることができます。

例えば、「在庫マスタ (ITEMS)」エンティティには以下のような属性が考えられます。

ItemID (Key, Text) 物品を一位に識別するID
物品名 (Text) 物品の名前
写真 (Image) 物品の写真
型式 (Text) 物品の型式やモデル番号
数量 (Number) 現在の在庫数
物品種類 (Ref) ITEM_CATEGORIESテーブルを参照
保管場所 (Ref) LOCATIONSテーブルを参照
状態 (Enum) 「正常」「要修理」などの状態
登録日 (DateTime) このデータが作成された日時

これらの属性が、データベースのテーブルにおけるカラムの候補となります。

テーブル候補をグルーピング（ER図の準備段階）

抽出したエンティティと属性を、関連性の高いもの同士でグループ化します。この段階で、それぞれのエンティティが独立したテーブルになるイメージを持ちます。そして、各テーブルの主キー（Primary Key）となる属性を検討します。

在庫管理アプリのテーブル候補

在庫マスタ (ITEMS)
ItemID (PK)
物品名
写真
型式
数量
物品種類 (FK)
保管場所 (FK)
状態
登録日
入出庫履歴 (HISTORY)
HistoryID (PK)
日時
物品ID (FK)
操作者 (FK)
操作種別
数量変更
関連現場リストID (FK)
現場リスト (PROJECTS)
ProjectID (PK)
現場名
カテゴリ (FK)
作成者 (FK)
状態
作成日
完了日
現場持ち出し明細 (PROJECT_ITEMS)
DetailID (PK)
現場リストID (FK)
物品ID (FK)
持ち出し数量
ユーザー (USERS)
UserID (PK)
名前
メールアドレス
顔写真
物品種類 (ITEM_CATEGORIES)
CategoryID (PK)
種類名
保管場所 (LOCATIONS)
LocationID (PK)
場所名
現場カテゴリ (PROJECT_CATEGORIES)
ProjectCategoryID (PK)
カテゴリ名
アイコン

第2章：ER図の作成演習（在庫管理アプリ）

この章では、前章で学んだエンティティと属性の概念を基に、実際にER図（Entity-Relationship Diagram）を作成する演習を行います。在庫管理アプリを例に、データベースの構造を視覚的に表現するスキルを習得します。

ER図の基本記号（エンティティ、リレーション、カーディナリティ）

ER図は、データベースの設計図であり、主に以下の3つの要素で構成されます。

エンティティ (Entity): データベースに保存される情報の「実体」を表します。通常、四角形で表現されます。
リレーションシップ (Relationship): 2つ以上のエンティティ間の関連性を表します。通常、線で表現され、その線上にリレーションシップの種類が記述されることもあります。
カーディナリティ (Cardinality): リレーションシップにおいて、あるエンティティのインスタンスが、関連する他のエンティティのインスタンスといくつ関連するかを示すものです。線の端に記号で表現されます。

1対多、多対多、1対1の表現方法

カーディナリティは、エンティティ間の関連の強さや種類を示し、主に以下の3種類があります。

1対1 (One-to-One): あるエンティティの1つのインスタンスが、別のエンティティの1つのインスタンスにのみ関連する場合。例：ユーザーとユーザー詳細情報。
1対多 (One-to-Many): あるエンティティの1つのインスタンスが、別のエンティティの複数のインスタンスに関連する場合。例：顧客と注文（1人の顧客は複数の注文をする）。
多対多 (Many-to-Many): あるエンティティの複数のインスタンスが、別のエンティティの複数のインスタンスに関連する場合。例：学生と科目（1人の学生は複数の科目を履修し、1つの科目は複数の学生に履修される）。

Mermaid記法では、リレーションシップを以下のように表現します。

||--o{: 1対多（必須-任意）
||--|{: 1対多（必須-必須）
}|--||: 多対1（任意-必須）

演習①：在庫管理アプリの主要エンティティ関係を描く

前章で抽出したエンティティ候補と、添付されたER図を基に、在庫管理アプリの主要なエンティティ間の関係をMermaid記法で表現してみましょう。

在庫管理アプリのER図

erDiagram
ITEMS ||--|{ HISTORY : "1 つの在庫に 1 つ以上の複数履歴"
ITEMS }o--|| PROJECT_ITEMS : "現場持ち出し明細に 0 個以上の複数在庫"
ITEMS ||--|| ITEM_CATEGORIES : "1 つの在庫に 1 つの物品種類"
ITEMS ||--|| LOCATIONS : "1 つの在庫に 1 つの保管場所"
PROJECTS ||--o{ HISTORY : "現場リストに 0 個以上の複数履歴"
PROJECTS }o--|| PROJECT_ITEMS : "現場持ち出し明細に 0 個以上の複数現場リスト"
PROJECTS ||--|| PROJECT_CATEGORIES : "1 つの現場リストに 1 つの現場カテゴリ"
USERS ||--o{ HISTORY : "ユーザーに 0 個以上の複数履歴"
USERS ||--o{ PROJECTS : "ユーザーに 0 個以上の複数現場リスト"

ITEMS {
  int item_id PK "在庫マスタ ID"
  string name "物品名"
  image photo "物品画像"
  string model "型式"
  int quantity "数量"
  string item_category_id FK "物品の種類 ID"
  string locations_id FK "保管場所 ID"
  string status "状態"
  date regist_day "登録日"
}
HISTORY {
  int history_id PK "入出庫履歴 ID"
  date timestamp "日時"
  string item_id FK "在庫マスタ ID"
  string user_id FK "ユーザー ID"
  string action_type "操作種別"
  int number_change "数量変更"
  string project_id FK "現場リスト ID"
}
PROJECTS {
  int project_id PK "現場リスト ID"
  string project_name "現場名"
  string project_category_id FK "現場カテゴリ ID"
  string user_id FK "ユーザー ID"
  string status "状態"
  date create_date "作成日"
  date complete_date "完了日"
}
PROJECT_ITEMS {
  int project_item_id PK "現場持ち出し明細 ID"
  string project_id FK "現場リスト ID"
  string item_id FK "在庫マスタ ID"
  int number_check "持ち出し数量"
}
USERS {
  int user_id PK "ユーザー ID"
  string name "ユーザー名"
  string email "メールアドレス"
  image photo "顔写真"
}
ITEM_CATEGORIES {
  int item_category_id PK "物品種類 ID"
  string name "物品種類名"
}
LOCATIONS {
  int location_id PK "保管場所 ID"
  string name "保管場所名"
}
PROJECT_CATEGORIES {
  int project_category_id PK "現場カテゴリ ID"
  string name "現場カテゴリ名"
  image icon "アイコン"
}

解説

上記のER図は、在庫管理アプリの主要なエンティティとその関係性を示しています。

ITEMS (在庫マスタ): アプリの中心となる物品情報を管理します。ITEM_CATEGORIES (物品種類) と LOCATIONS (保管場所) を参照し、物品の詳細な分類と保管場所を紐付けます。HISTORY (入出庫履歴) と PROJECT_ITEMS (現場持ち出し明細) から参照されます。
HISTORY (入出庫履歴): 物品の入庫、出庫、返却などの履歴を記録します。ITEMS、USERS、PROJECTSを参照し、どの物品が、誰によって、どの現場で、どのような操作が行われたかを追跡します。
PROJECTS (現場リスト): 物品が持ち出される現場やプロジェクトの情報を管理します。PROJECT_CATEGORIES (現場カテゴリ) と USERS (作成者) を参照します。HISTORY と PROJECT_ITEMS から参照されます。
PROJECT_ITEMS (現場持ち出し明細): どの現場にどの物品が、どれだけ持ち出されたかの詳細を記録します。PROJECTS と ITEMS を参照し、多対多の関係を解消する中間テーブルの役割も果たします。
USERS (ユーザー): アプリを利用するユーザーの情報を管理します。HISTORY と PROJECTS から参照されます。
ITEM_CATEGORIES (物品種類): 物品のカテゴリを管理するマスタテーブルです。ITEMS から参照されます。
LOCATIONS (保管場所): 物品の保管場所を管理するマスタテーブルです。ITEMS から参照されます。
PROJECT_CATEGORIES (現場カテゴリ): 現場のカテゴリを管理するマスタテーブルです。PROJECTS から参照されます。

演習②：多対多の解消（中間テーブルの設計）

このER図では、PROJECTS (現場リスト) と ITEMS (在庫マスタ) の間に PROJECT_ITEMS (現場持ち出し明細) という中間テーブルが導入されています。これは、1つの現場リストには複数の物品が関連し、1つの物品は複数の現場リストに持ち出される可能性があるという「多対多」の関係を解消するためです。

PROJECT_ITEMS テーブルは、ProjectID (FK) と ItemID (FK) を持ち、これら2つの外部キーの組み合わせで一意の持ち出し明細を識別します。これにより、多対多の関係が「PROJECTSとPROJECT_ITEMSの1対多」と「ITEMSとPROJECT_ITEMSの1対多」という2つの1対多の関係に分解され、データベースでの管理が容易になります。

演習③：カテゴリや場所などのマスタテーブルを追加する

ITEM_CATEGORIES、LOCATIONS、PROJECT_CATEGORIESは、それぞれ物品の種類、保管場所、現場カテゴリといった「マスタデータ」を管理するためのテーブルです。これらのテーブルを独立させることで、以下のようなメリットがあります。

データの整合性: 例えば、物品の種類を直接ITEMSテーブルに文字列で入力すると、表記ゆれが発生し、集計や検索が困難になります。マスタテーブルとして定義し、Ref型で参照させることで、常に正確なデータが入力されるようになります。
メンテナンス性: 物品の種類や保管場所が変更された場合でも、マスタテーブルのレコードを修正するだけで、関連するすべてのデータにその変更が反映されます。
拡張性: 新しい種類や場所が追加された場合でも、マスタテーブルにレコードを追加するだけで対応できます。

これらのマスタテーブルは、AppSheetでいうところのEnumやRef型の選択肢の元データとなるため、非常に重要な役割を果たします。

最終確認：リレーションの整合性と属性の粒度チェック

ER図が完成したら、以下の点を確認し、設計の整合性と品質を向上させましょう。

リレーションシップの整合性: すべてのエンティティ間の関連が正しく表現されているか。外部キー（FK）が適切に設定されているか。
カーディナリティの妥当性: 1対1、1対多、多対多の関係がビジネス要件と一致しているか。
属性の粒度: 各属性がそれ以上分割できない最小単位になっているか。例えば、「住所」を「都道府県」「市区町村」「番地」などに分割すべきか、といった検討です。粒度が細かすぎると管理が煩雑になり、粗すぎると柔軟なデータ利用が難しくなります。
主キーの適切性: 各テーブルの主キーが一意であり、変更されない値であるか。
命名規則: エンティティ名、属性名が一貫した命名規則に従っているか。可読性を高めるために重要です。

これらの確認を行うことで、より堅牢で使いやすいデータベース設計に近づけることができます。

AppSheet用語表

AppSheetには独自の用語がいくつかあります。ここで、今回の記事で登場した主要な用語をまとめておきましょう。

用語	意味	具体例	初心者の落とし穴
要件定義	システム開発の最初の段階で、どのようなシステムを作るべきかを明確にするプロセス。	業務ヒアリング、ユースケース定義	曖昧なままだと手戻りが多い
エンティティ	データベースに保存される情報の「実体」。ER図では四角形で表現。	在庫マスタ、現場リスト、ユーザー	業務上の概念と混同しやすい
属性	エンティティが持つ具体的な「情報」や「特性」。データベースのテーブルでは「カラム（列）」に相当。	物品名、数量、登録日	粒度が適切でないとデータ管理が複雑化
テーブル	リレーショナルデータベースにおいて、関連するデータを格納するための構造。	ITEMS、PROJECTS、USERS	正規化されていないとデータ不整合の原因に
ER図	データベースの設計図。エンティティとリレーションシップを視覚的に表現。	在庫管理アプリER図	複雑な関係性を表現しきれないことがある
リレーションシップ	2つ以上のエンティティ間の関連性。	在庫と入出庫履歴	カーディナリティの誤解による設計ミス
カーディナリティ	リレーションシップにおいて、あるエンティティのインスタンスが、関連する他のエンティティのインスタンスといくつ関連するかを示すもの。	1対1、1対多、多対多	ビジネス要件との乖離
正規化	データベースの設計において、データの重複を排除し、整合性を保つためのプロセス。	第1正規形、第2正規形、第3正規形	過度な正規化はパフォーマンス低下を招く
主キー(PK)	各行を一意に識別するための列。重複は許されない。	ItemID, ProjectID	変更される可能性のある値を設定すると問題発生
外部キー(FK)	別のテーブルの主キーを参照する列。テーブル間の関連性を定義する。	HISTORYテーブルのItemID	参照整合性制約の違反
中間テーブル	多対多のリレーションシップを解消するために導入されるテーブル。	PROJECT_ITEMSテーブル	設計を複雑にしすぎることがある

FAQ

Q: データベース設計はAppSheet開発でも必須ですか？

A: AppSheetはノーコードツールですが、大規模なアプリや複雑なデータ連携が必要な場合は、データベース設計の知識が非常に役立ちます。データの整合性や拡張性を保つ上で、設計の基礎を理解しておくことは重要です。

Q: 在庫管理アプリの設計で最も重要なことは何ですか？

A: 在庫数の正確な管理と、入出庫履歴の追跡可能性です。これにより、欠品防止や棚卸しの効率化、不正防止につながります。

Q: ER図はどのようなツールで作成するのがおすすめですか？

A: 無料で手軽に使えるDraw.io (diagrams.net) や、テキストベースでバージョン管理しやすいMermaid記法がおすすめです。プロジェクトの規模やチームの慣習に合わせて選びましょう。

Q: 正規化はどこまで行えば良いですか？

A: 一般的には第3正規形までを目指すことが多いですが、過度な正規化はパフォーマンス低下を招くこともあります。ビジネス要件やシステムの特性に応じて、非正規化を検討するケースもあります。

Q: 在庫管理アプリのER図で多対多の関係を解消するメリットは何ですか？

A: データの重複を防ぎ、整合性を保つことができます。また、中間テーブルを介することで、より柔軟なデータ管理や複雑なビジネスロジックの実装が可能になります。

次回予告/CTA

本記事では、データベース設計の第一歩として、在庫管理アプリを題材に、要件定義からER図作成までのプロセスを学びました。ビジネス要件をデータ構造に落とし込むことの重要性、エンティティと属性の抽出、そしてリレーションシップの表現方法について、実践的に解説しました。

次回、連載第4回では、今回作成したER図をもとに、AppSheetでViewを作成する具体的な手順を解説します。論理設計で定義したテーブル、カラム、リレーションシップをAppSheet上でどのように実現するのか、そして正規化の概念をAppSheetのデータ構造にどう反映させるのかを、手を動かしながら学んでいきましょう。お楽しみに！

📄【第1回】AppSheetで在庫表から最短テーブル作成！初級エンジニア向け入門ガイド