嗨各位，我想以此系列文章來記錄我從零開始學習資料建模基礎一路上的種種。
請注意，此系列文章雖然只聚焦Data Modelling-Specific的資料建模技術（Classic ER和Crow’s Foot註記法），但其中提到的資料建模技巧和方法都是囊括在資料建模核心觀點之內的。
Let’s get started.
資料模型vs.資料
我想用模型飛機和飛機的關係來類比它們倆的關係。模型飛機是你能在玩具店或模型店看到的超級縮小版飛機。它可能不會飛，可能能在滿足某些特定條件下，用電波等方式讓模型飛機能像真實飛機一樣飛行，但它的飛行方式絕不跟真正的飛機如出一轍。儘管如此，我們仍能從它身上一窺真實飛機的尺寸和特徵。資料模型和真實世界中的資料的關係也是如此。資料模型並不會儲存任何資料，而是能夠代表（抽象化）真實世界的資料，提供我們一覽套用在資料上的特徵和規則。理想上我們想從資料模型中了解到：資料主體，資料主體的屬性，資料主體間的關係和套用在資料上的商業規則。
什麼是資料建模？
資料建模是一種被用於定義和分析資料需求的過程 我們需要資料需求來支持組織內相應訊息系統的業務過程
如果我們想從零開始製造一架飛機，我想第一件該做的事是絕不會是進工廠敲敲打打，而是著手完成飛機的藍圖等各種圖解和設計。等到哪天你滿意了，製造過程才會啟動。資料建模也是如此，我們會建立資料模型，過程中為了與現實世界銜接加入種種特徵和規則後，才會開始建立你的資料庫或大數據環境並讓資料寫入。以上的流程我們稱作順向工程。當然如果現在情境反過來，假設你的任務是負責維護資料庫，一開始就有現成的資料庫但你找不到相關的文件或說明，你能做的就是逆向工程，順著一套準則，將那些真實世界的資料庫轉換為資料模型。
資料建模vs.資料庫設計
到底資料建模跟資料庫設計是不是一樣的東西？在這裡就由我來為大家解開疑惑。
首先讓我們看看資料庫設計有哪些特徵：
- 顯而易見的我們想＂設計資料庫＂
- 受特定的資料庫模型約束（如關聯式Relational等）
- 不只面對資料表和資料綱要（Schema），還要更進一步面對實體的資料儲存問題
- 在設計的一開始就導入系統執行和針對特定產品的一套規則、指導方針和限制
而資料建模則有以下特徵：
- 從概念或語意層級著手
- ＂天馬行空＂
- 不受資料庫模型的執行規則限制
- 比資料庫設計更接地氣（貼近真實世界）
從結果可以看到，資料建模確實跟資料庫設計有幾分相似，也有部分重疊的部分，而這也是為什麼它們容易被混為一談的理由。
概念＆術語
讓我們一起看看些基礎的資料建模概念和術語。
實體Entity：資料主體。想想這個世界中存在的各種人事物，如在學術場合中的老師、學生、班級、成績、學系、系館等等。在關聯性資料庫的世界中，我們可以粗略地將一個實體類比於一個資料表。
屬性Attribute：與實體（資料主體）相關，且通常會在實體出現後才會存在（Top-down Data Modelling）。可以類比於資料表中的欄位（Columns/Fields）。同樣的屬性時常被不同實體所共用（例如老師和學生這兩個實體都能擁有ID、姓名等屬性）。
關係Relationship：基於真實世界資料的關係所立。關係命名有分為單向命名（One-direction Naming）和雙向命名（Bidirectional Naming）。單向命名只會標示其中一個方向的關係（老師教導學生），而雙向命名則是兩個方向的關係都會標示（老師教導學生；學生被老師教）。關係有兩種類型，其中一種是有關實體數量和關係數量，如兩個實體間可以存在一個以上的關係（老師教導學生 + 老師責備學生，這樣就是兩個）、三個實體間也能存在關係（Three-entity Relationship）、實體也能跟自己產生關係（Recursive Relationship）等等。另一個種關係則是實體間能存在階層（Hierarchy）。眾所皆知的＂界門綱目科屬種＂，就是生物分類法的階層。在資料建模領域也是如此，運用階層將實體分組和歸類。
商業規則Business Rules：如數據建模的基數（Cardinality）、關係的強制與否、可允許的屬性值（是否能容許NULL）、資料動態等等。
生命週期簡介
生命週期分為三個階段：從概念資料建模（Conceptual Modelling）、邏輯資料建模（Logical Modelling）到實體資料建模（Physical Modelling）。
概念資料建模：
- 天馬行空，不用擔心限制
- 貼近真實世界
邏輯資料建模：
- 投入（關聯性）資料庫結構，所以模型可能需要些轉換和調整
實體資料建模：
- 探討更底層的細節，並引入索引值、特定分割資料方法等等
- 聚焦在如何有效率地運作資料庫
下一篇我們將深入探討如何建構實體、屬性與關係，和如何利用上述提到的東西表達各式各樣的商業角色和彼此之間的關係。