資料模型設計：這步錯了後面全部要重來

擺設可以改，格局要打牆 比喻：房子的格局跟擺設。沙發位置不喜歡，下午就能換；牆的位置畫錯了，要動工、要重拉水電、要重做地板。 介面是擺設，資料模型是格局。畫面客戶看一眼就有意見，改起來一天；資料模型錯了，畫面、報表、整合、已經進去的資料，全部要跟著動。 所以這一步值得多花半天想清楚。 從業務流程反推：三個動作 不要從「資料庫應該有哪些表」開始想，要從訪談內容開始。 1. 圈出名詞 → 候選實體 訪談逐字稿裡反覆出現的名詞，就是候選的實體（entity，也就是之後的資料表）：客戶、報價單、產品、業務、庫存。 2. 圈出動詞 → 關係與狀態 動詞告訴你兩件事：實體之間怎麼連（「業務開報價單」），以及有哪些狀態變化（「主管核准報價單」代表報價單有狀態）。 3. 問「一個 X 可以有幾個 Y」 這一題決定關係的形狀，而且答案一定要跟客戶確認，不能自己假設。 走一次（示意） 下面是一段虛構的訪談片段： 「業務會幫客戶開報價單，一張報價單上可能有好幾項產品，每一項的折扣可能不一樣。金額超過十萬要主管核准。客戶如果是老客戶，會有自己的專屬折扣。」 圈名詞：業務、客戶、報價單、產品。 圈動詞：開（業務 → 報價單）、核准（主管 → 報價單，而且有條件）。 問基數：一個客戶可以有多張報價單；一張報價單可以有多項產品；每一項有自己的折扣——所以折扣不在報價單上，在「報價單的每一項」上。 注意兩件事：折扣被放在「報價項目」而不是「報價單」，因為訪談裡那句「每一項的折扣可能不一樣」；以及核准被做成一張紀錄表，而不是報價單上的一個布林欄位——因為之後一定有人會問「這張是誰核准的、什麼時候」。 三種最常見的建模錯誤 一、把畫面當成資料模型 客戶給你一張 Excel 報表，你就照著報表的欄位開一張表。問題是報表是資料的一種呈現方式，不是資料本身。下一季他們想換一種看法，你的資料就撐不住。 判斷法：問自己「如果這張報表明天改版，我的表要不要動？」要動，就是建錯了。 二、該是一對多，卻塞成一個欄位 把「聯絡人」做成一個文字欄位，之後客戶說「這家公司有兩個窗口」...