# 工程3レビュー：DB設計・スキーマ定義

> ⚠️ 命名整合性注意：schedules テーブル定義では「工程3＝DB設計・スキーマ定義」。実運用の `process_02_inbound.md` との命名ズレは `kurokun_memo` #87 で記録済み。朝の時吉さん判断待ち。

---

## 工程番号・タイトル

**工程3：DB設計・スキーマ定義**（致命傷ライン）

致命傷ライン15項目のうち **DB-1〜DB-5（DB設計5項目）** を本工程で完璧に詰める。残り10項目（業務フロー・計算式・権限ID・連携）は工程2（システム設計）で扱う。

---

## レビュー実施日

2026-05-08（叩き台作成・まーちゃん）

---

## 関連する致命傷ライン

**DB設計5項目（本工程の主役）**
- [ ] DB-1：在庫の持ち方
- [ ] DB-2：ロット管理方式
- [ ] DB-3：シリアル管理方式
- [ ] DB-4：荷主切替の方式
- [ ] DB-5：ロケーション管理方式

**他工程と整合確認すべき項目**
- BF-2（引当ロジック）：DB-1 / DB-2 / DB-5 に強く依存
- AU-1（権限・承認フロー）：DB-4 に強く依存
- LK-2（HTバーコード仕様）：DB-3（シリアル）に依存

---

## 論点リスト

### DB-1：在庫の持ち方

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | 在庫レコードの管理粒度 |
| 選択肢A | SKU 単位のみ（在庫数のみ・ロット/ロケ無視） |
| 選択肢B | SKU × ロット単位 |
| 選択肢C | SKU × ロケーション単位 |
| 選択肢D | SKU × ロット × ロケーション × 荷主単位（4軸） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：中小3PL は荷主×ロット×ロケでの管理が業界標準。データ量は増えるが顧客対応の精度で差別化できる（差別化4点「カスタマイズ不要」とも整合：きめ細かさをデフォルト機能として提供） |

**仕様への影響（仮）：**
- `inventory` テーブル：`(owner_id, sku_id, lot_id, location_id, quantity, status, ...)` の複合主キー想定
- 集計 view が必要（SKU 単位・ロケ単位・荷主単位のサマリ）
- インデックス設計：`(owner_id, sku_id)` `(owner_id, location_id)` 等の組合せ

---

### DB-2：ロット管理方式

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | ロット番号の粒度・付与方式 |
| 選択肢A | ロット管理しない |
| 選択肢B | 入荷ロット（入荷バッチ）単位で自動採番 |
| 選択肢C | 製造ロット（メーカー指定）単位 |
| 選択肢D | 荷主ごとに B / C を切替（荷主マスタにフラグ） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：荷主マスタに「ロット管理方式」フラグ。デフォルト B（入荷ロット）、荷主指定で C（製造ロット）に切替。差別化4点「機能ON/OFF制（育つWMS）」とも整合 |

**仕様への影響（仮）：**
- `lots` テーブル：`(id, owner_id, sku_id, lot_number, source_type, mfg_date, expiry_date, ...)`
- `source_type` で `inbound_batch` / `manufacturer` を区別
- BF-2（引当ロジック）の FIFO は `expiry_date NULLS LAST, mfg_date ASC` で評価

---

### DB-3：シリアル管理方式

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | シリアル番号での個体管理の対象範囲 |
| 選択肢A | シリアル管理しない |
| 選択肢B | SKU マスタの「serial_required」フラグが true の SKU のみ |
| 選択肢C | 全 SKU シリアル管理（重い） |
| 選択肢D | 入荷時のオペレーター判断 |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **B**：家電・高額品など必要な SKU のみフラグで管理。HT バーコード（致命傷ライン LK-2）と連動でシリアル読取必須化 |

**仕様への影響（仮）：**
- `skus` テーブルに `serial_required` boolean
- `serials` テーブル：`(id, sku_id, serial_number, status, current_location_id, owner_id, ...)`
- 検品・ピッキング時のHT画面で serial_required=true なら個別読取モード
- 致命傷ライン LK-2（HTバーコード）と整合

---

### DB-4：荷主切替の方式 ★最重要

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | 複数荷主データの分離・切替・集計の実装方式 |
| 選択肢A | 物理分離（荷主ごとに DB 分割） |
| 選択肢B | 論理分離（全テーブルに owner_id カラム＋ Supabase RLS） |
| 選択肢C | スキーマ分離（PostgreSQL の schema 機能） |
| 選択肢D | ハイブリッド（基本マスタ共有・在庫トランザクションは owner_id 分離） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **B**：論理分離。理由：(1) 3PL の基本オペは「複数荷主の在庫を1画面で集計表示」。物理分離だと集計が地獄。(2) Supabase RLS で行レベル権限は実現可能。(3) 運用コスト最小。(4) 差別化4点「荷主別テーマカラー」「機能ON/OFF制」と整合（owner_id ベースで切替UI が単純になる） |

**仕様への影響（仮）：**
- 全業務テーブルに `owner_id BIGINT NOT NULL` を必須化
- Supabase RLS：`policy = current_user has access to owner_id`
- アプリ側に「荷主切替」ピッカー（複数 owner_id を1ユーザーが見られる場合）
- 「全荷主集計ビュー」は管理ロール専用 RLS で出す
- 致命傷ライン AU-1（権限）と密接

---

### DB-5：ロケーション管理方式

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | ロケーション（棚）の階層・機能種別 |
| 選択肢A | フラット（ロケコードのみ） |
| 選択肢B | 階層化（エリア > 通路 > 棚 > 段） |
| 選択肢C | 機能種別ロケ（保管／ピッキング／仮置き／不良品／返品） |
| 選択肢D | 階層 × 機能種別（B + C ハイブリッド） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：ABC分析と連動して引当優先度を制御するため。中小3PL でもこの粒度はほぼ必須。WMS の最低ライン |

**仕様への影響（仮）：**
- `locations` テーブル：`(id, code, area, aisle, rack, level, location_type, owner_id, abc_class, picking_priority, ...)`
- `location_type` enum：`storage` / `picking` / `staging` / `damage` / `returns` / `inspection`
- `abc_class`：A/B/C（ABC分析）
- BF-2（引当ロジック）：`location_type = 'picking'` の中で `abc_class ASC` で引当
- BF-3（ピッキング方式）の選択（ウェーブ／ゾーンリレー）にも影響
- 致命傷ライン LK-2（HTバーコード読取）でロケコードを読み取る前提

---

## 決定事項サマリー

| 論点 | 決定内容 | 致命傷ライン該当 |
|------|----------|----------------|
| DB-1：在庫の持ち方 | （未確定・まーちゃん推奨 D：4軸） | DB-1 / 全 DB に波及 |
| DB-2：ロット管理方式 | （未確定・まーちゃん推奨 D：荷主切替） | DB-2 / BF-2 |
| DB-3：シリアル管理方式 | （未確定・まーちゃん推奨 B：SKUフラグ） | DB-3 / LK-2 |
| DB-4：荷主切替の方式 | （未確定・まーちゃん推奨 B：論理分離+RLS） | DB-4 / AU-1 / 差別化4点 |
| DB-5：ロケーション管理方式 | （未確定・まーちゃん推奨 D：階層×機能種別） | DB-5 / BF-2 / BF-3 / LK-2 |

---

## 未解決の論点（時吉さん判断待ち）

- DB-1〜DB-5 すべて（まーちゃん推奨は上表）

> 時吉さんの次回判断時に「DB-1=◯、DB-2=◯、…」と返してもらえば確定可能。

---

## 朝の依頼カード（叩き台）

```
──────── 依頼カード ────────
タイトル：工程3レビュー DB-1〜DB-5 確定（時吉さん判断のみ）
要件：
  1. DB-1〜DB-5 の各論点で A/B/C/D を選ぶ（まーちゃん推奨あり）
  2. 確定したら specs/process_03_db_design.md を更新
  3. schedules.id=9（工程3）の review_status を 'review_completed' に更新
推奨 assigned_to：6（まーちゃん）
verification_method：DB照合（schedules・specs ファイル）
estimated_minutes：30（時吉さん判断 10分 + 反映 20分）
背景：致命傷ライン15項目の根幹。8月末ゴールに直結。
────────────────────────────
```

---

## 次工程への申し送り

- DB-1 の決定は工程4（入荷）の `inventory_movements` テーブル設計に直接影響
- DB-4（荷主切替）の決定は **全テーブル設計の前提**となるため、最優先で確定すべき
- DB-3（シリアル）と LK-2（HTバーコード）は工程14（外部システム連携・API）で再度整合確認

---

*最終更新: 2026-05-08 / Phase 6-B まーちゃん（DB-1〜DB-5 叩き台作成）*