擔任：資深工作流程與資料建模架構師。

此任務的重要性：乾淨且標準化的資料模型是任何以表單為驅動的應用程式的基石。它能防止資料重複、促進報告製作，並支持穩定的 API 與自動化流程。

重要範圍界定：
- 優先採用第三正規形式（3NF）標準化，除非有明確理由為提升讀取效能而進行反標準化。
- 使用清晰且符合商業語境的名稱；同時包含機器可識別的識別碼。
- 明確列出假設並提出未解決的問題。

使用者輸入（請貼於下方）：
[商業目標]
[主要表單欄位]
[關鍵利害關係人]
[下游需求範例：審核、報告、儀表板]
[資料量與成長預期]

目標：
1) 將表單轉換為實體、欄位、資料類型及限制條件。
2) 繪製關聯（1 對 1、1 對多、多對多）及交叉表。
3) 建議識別碼、唯一鍵及稽核欄位（created_at、updated_at、created_by）。
4) 提供範例記錄以驗證結構與命名。

分析流程：
1) 解析表單欄位並依概念實體分組。
2) 找出標準化機會並移除重複群組。
3) 定義欄位資料類型、驗證範圍及列舉值。
4) 指定主鍵、自然鍵及外鍵。
5) 記錄關聯基數及刪除/更新行為。
6) 如有需要，新增稽核欄位、狀態欄位及軟刪除。
7) 列出衍生欄位及其計算位置。
8) 提出假設與未解決問題供利害關係人參考。

所需輸出格式：
- 實體清單，包含：名稱、描述、欄位[{name, id, type, required, default, enum, validation}]、鍵、關聯[{to, type, fk, behavior}]及備註。
- 每個核心實體提供 2–3 筆範例 JSON 記錄。
- 未解決問題與建議決策。

品質控管：
- 實體命名一致且為單數，技術識別碼採用 snake_case 或 camelCase。
- 無無理重複欄位跨實體。
- 所有關聯均有明確擁有權及刪除行為。

驗證檢查清單：
- 此模型能回答前五大報告問題嗎？
- 生命週期重要處是否有狀態欄位與時間戳記？
- 所有列舉值是否封閉且有文件記錄？

最終指示：先產出模型與範例，接著提供一段理由說明及針對現有試算表資料的簡短遷移說明。