資料怎麼產生？怎麼紀錄的？
要講資料怎麼產生？怎麼紀錄的？為了不要讓大家想睡覺，我來舉一個非常簡單的例子吧！
大家一定都用 App 訂過外送吧！不管是 UberEATS、Foodpanda 都是！
我們今天就用「訂外送」跟「資料之間的關係」，來解釋初學者學數據分析之前，一定要搞懂的資料表的架構，因為這會跟接下來要講到的「資料模型 (Data Model)」很有關係～
訂外送的流程跟資料表之間的關係
- 假設 Lisa 今天中午想要點外送，他開啟了外送 App，選擇了一家拉麵店，點了一碗叉燒拉麵
- 他在 App 上提交訂單的時間是 12:00，系統會記錄下「下單時間」是 12:00，系統收到之後，立刻確認，系統會記錄下「訂單成立時間」是 12:00，並標示這筆訂單已經成立，也就是「訂單是否成立」標為 1 (1 為有，0 為沒有)
- 這時拉麵店收到了 Lisa 的外送訂單，在 12:02 時，拉麵店看到訂單，決定接單做料理。這時會記錄下「商家接單時間」是 12:02，並標示商家有接這單，「商家是否接單」是 1
- 系統同時需要請外送員前往餐廳取餐，在 12:05 時外送系統派單給一位外送員，外送員在 12:06 時接單！系統記錄下「系統派單時間」、「車隊接單時間」
- 外送員先在 12:15 時去拉麵店取了料理，然後騎車送到 Lisa 公司，抵達時間是12:25。最後在 12:25 時將料理交给了 Lisa 。這時整個外送過程完成，外送員會完成訂單，時間記錄為 12:26
所以這個資料表記錄了 Lisa 這筆外送訂單從開始下單，到餐廳接單烹調、外送員取貨送貨，最後完成交貨的整個流程中每個時間點和狀態。
流程怎麼轉換成資料表 (Table, Data Mart)？
| 欄位名稱 | 欄位說明 |
|---|---|
| 消費者 id | 下單的用戶 id |
| 下單時間 | 用戶在 App 上點擊下單的時間點 |
| 訂單成立時間 | 系統接受到這筆訂單的時間 |
| 訂單是否成立 | 訂單是否成功傳入系統，1 表示成功 |
| 商家 id | 餐廳的 id |
| 商家接單時間 | 餐廳接到訂單的時間 |
| 商家是否接單 | 餐廳是否接單烹調，1 表示接單 |
| 車隊id | 車隊的 id |
| 系統派單時間 | 系統將訂單分配給外送員的時間 |
| 車隊接單時間 | 外送員接到訂單的時間 |
| 車隊取貨時間 | 外送員到店取餐的時間 |
| 車隊送貨開始時間 | 外送員開始送餐的時間 |
| 車隊抵達時間 | 外送員抵達客戶地點的時間 |
| 車隊交貨時間 | 外送員完成交貨的時間 |
| 訂單完成時間 | 整個訂單外送完成的時間 |
| 訂單是否完成 | 訂單的外送是否成功完成，1 表示成功 |
所以剛剛解釋的流程，就會一筆一筆的根據他所屬的欄位，記錄在資料表裡面！
什麼是資料模型 (Data Model)？
在剛剛的這張大表裡面，記錄了完整的行為對吧！
但通常在公司的資料庫裡面，如果要用一張大表來記錄「所有行為」，可能會需要幾千個欄位，這樣就太複雜了！運算起來還很浪費時間跟效能，所以這時候「資料模型」的概念就會導入囉！
怎麼用外送流程大表規劃資料模型？
剛剛這張大表，可以這樣設計資料模型：
- 用戶 (User) 資料模型：
- 用戶 ID
- 用戶名稱
- 電話號碼
- 地址
這張表記錄了每個訂單的用戶基本訊息
- 商家 (Restaurant) 資料模型：
- 商家 ID
- 商家名稱
- 菜單
- 地址
- 電話
這張表記錄了提供外送服務的餐廳基本訊息
- 訂單 (Order) 資料模型：
- 訂單 ID
- 用戶 ID (與 User 表互相關聯)
- 商家ID (與 Restaurant 表互相關聯)
- 下單時間
- 送達時間
- (還有其他各種時間……)
這張表記錄了一個外送訂單的主要信息，同時通過 User 和 Restaurant 的 ID，記錄了這張訂單是哪個用戶下的單、並且是跟哪個餐廳訂購的。
這就是一個簡單的資料模型例子！！它定義了主要實體 (User、Restaurant、Order) 的結構和關係，可以更好的描述和管理這個外送 App 的核心資料！
為什麼要資料模型？不能就用大表嗎？
一開始其實我也有這個疑問～今天簡單講一下核心原因！為什麼要用資料模型，而不是只用一個大表記錄所有行為的資料呢？
主要有以下幾個考量：
- 降低資料重複：如果都寫在一個大表裡，會出現很多重複的數據。例如：用戶名、商家名這些資訊會重複記錄，浪費儲存空間
- 加快查詢速度：在數據量大的情況下，只用一個大表查詢會很慢。當今天拆分為資料模型後，可以對各表做優化，加快我們在資料庫裡面的查詢
- 維護方便：如果要修改某個欄位 (屬性)，資料模型只要調整某個實體表 (User、Restaurant、Order) 即可，如果只用一個大表記錄的話，要全部調整超麻煩
- 確保數據一致性：資料模型可以設定關聯規則、限定資料值、確保數據的一致性。一個大表很難同時滿足這些限定條件
所以綜合來說，使用資料模型可以更好的「組織資料結構」，也讓數據處理可以更高效，這就是數據工程中的常見的實踐方法！
數據分析師為什麼一定要懂資料模型？
歸結來說，有以下幾個原因：
第一：一看資料，就懂業務！
其實整間公司的業務 (行銷、業務、營運、財務…) 都可以從資料模型一探究竟！
資料模型描述的不僅僅是資料本身，也反映了資料與業務之間的對應關係。如果可以知道資料模型跟公司業務是有關係的，數據分析師就可以更快的只透過「資料模型」就了解業務本身！
比方說，如果一個對於外送流程完全不懂的人，他可以從剛剛我們歸納出來的「資料模型」就知道一個訂單的流程：會包含客戶、餐廳、外送員、訂單本身。
這樣分析資料的時候，就會知道有哪些切入角度可以應用！
第二：不要 Join 錯喔！
大家應該也知道 SQL 是查詢資料庫的標準語言吧！
如果不知道資料模型的概念，就很可能不知道資料表之間的關聯，如果不知道資料表之間的關聯，可能就不知道怎麼「Join」才可以把資料串聯在一起，如果不知道如何串聯？那別談後續的分析了！！
所以資料模型是搞懂「SQL Join」背後的底層邏輯～
結論：資料架構、資料模型，講的都是這些基礎的延伸！
總之，理解業務跟數據之間的關係，才是數據分析師的「基本工作內容」！
透過「資料模型」來了解業務跟數據之間的關係，一舉數得的原因是：
- 資料模型是優化過後的數據儲存方式
- 資料模型本身就可以知道業務跟數據之間的關係
如果不理解資料模型，數據分析師很難完成分析的工作，也就無法提供有價值的分析建議。所以我會建議，如果你想成為數據分析師，在學所有工句之前，一定要知道資料的結構、資料模型的概念！
