# 概念資料模型：團隊實用指南 > 學習概念資料模型，讓業務目標與資料架構保持一致。為 2026 年打造更優系統的團隊提供清晰、實用的概覽。 Source: https://www.electe.net/tc/post/conceptual-data-modelling Site guide: https://www.electe.net/tc/llms.txt 銷售經理打開每週報告，看到一個營收數字。財務主管查核帳目，得到另一個數字。兩個數字看起來都合理，但其中一個包含了已取消的訂單，另一個則只在結算後才計入營收。原本該敲定下週促銷方案的會議，變成了一場關於「營收」定義的爭論。 企業未必需要更多資料或新的儀表板，它可能需要的是對既有資訊的共同描述。**概念資料模型**正是提供這種描述：它為重要的業務概念命名，展示它們之間的關聯，並在團隊建立報告或連接系統之前，讓關鍵假設清楚可見。 無論你使用試算表、CRM、ERP 還是分析平台，這都很重要。你不需要資料庫背景就能上手，也不需要在任何人使用之前先畫出完美的圖表。一個小而實用的模型，就能幫助團隊就定義達成共識、調查不一致的報告，並以更高的信心做出決策。本指南將說明如何運用熟悉的業務範例與組織既有的資料，逐步建立這樣的模型。 ## 為什麼你的業務資料感覺像一團謎 銷售經理與財務主管未必是出錯了，他們可能只是對同一個詞採用了不同的定義。銷售部門可能在客戶提交訂單時就計入訂單，而財務部門可能要等到付款結算後才計入。如果報告沒有清楚區分這一點，兩個團隊都能做出準確的計算，卻是在回答不同的問題。 根本問題往往在於**缺乏共同的意義，而不是缺乏資料**。一個團隊可能把 CRM 裡的任何人都稱為「客戶」，而另一個團隊則只把已購買的人稱為客戶。試算表可能把一家公司稱為帳戶，而報告則把這家公司的每個聯絡人都視為一名客戶。當這些概念沒有對齊時，連接系統或新增儀表板只會擴散混亂，而非解決問題。 ### 讓隱藏的假設清楚可見 概念模型為團隊提供一份共同的地圖，描繪他們所依賴的業務資訊。它可能顯示：一位客戶下訂單，一筆訂單包含多項產品，而一項促銷活動在特定期間內適用於某些產品。這個模型也讓人們有機會提出實際的問題：訂單能否在沒有客戶記錄的情況下存在？一項促銷能否涵蓋多項產品？「營收」指的是訂單總額、已付款金額，還是其他東西？ 這些問題並非技術上的干擾。它們關係到團隊能否比較報告、追蹤績效，或決定該推廣哪些產品。共同的詞彙有助於業務與技術同仁在建立新的資料結構之前，針對相同的概念進行討論。 > **從分歧處著手：**問問看兩份報告對哪個業務術語的解讀不同。這個問題往往能揭示模型中第一個有用的部分。 同樣的挑戰出現在許多組織中,不只是那些擁有複雜資料庫的組織。如果你的團隊正在處理相互衝突的報表定義,這份[針對報表衝突團隊的指南](https://www.electe.net/post/single-source-of-truth)提供了另一種建立共同報表意義的觀點。關鍵在於把差異視為釐清業務規則的契機,而不是把它當成有人犯錯的證據。 ## 理解概念資料模型的核心概念 想像一下建築藍圖。它顯示房間以及人們在其間的動線,但不需要指定每根管線的直徑或每個電氣接點。**概念資料模型**的運作方式類似。它描述業務中重要的事物以及它們之間的關聯,而不需要選擇資料庫資料表、儲存技術或雲端平台。 從**實體**開始:業務需要討論的人、物件、事件或概念。零售商可能會識別出客戶、訂單、產品和促銷活動。這些還不是資料庫資料表,而是人們能夠辨識並定義的有意義業務概念。 接下來,找出**屬性**,也就是有助於描述實體的性質。客戶可能有姓名和客戶狀態;訂單可能有訂單日期和業務狀態。概念模型通常著重於能釐清實體意義的屬性,而不是試圖列出系統最終可能儲存的每一個欄位。 ### 用關係連接概念 **關係**描述實體之間如何關聯。客戶下訂單。訂單包含產品。促銷活動適用於產品。用日常語言為關係命名,有助於業務同仁檢查模型是否反映了實際的工作方式。 **基數**描述一個實體的多少個實例可以與另一個實體相關聯。例如,一位客戶可能下多筆訂單,而每筆訂單可能只屬於一位客戶。團隊還需要考慮關係是否為選擇性的:客戶是否可以在下訂單之前就存在,還是每位客戶都必須有訂單? 模型還可以記錄**業務規則**,也就是使關係或定義有意義的條件。某條規則可能規定促銷活動只在指定期間內適用,或者已完成的訂單必須有結算狀態。這些規則說明業務如何運作;它們不需要描述資料庫如何強制執行這些規則。 實際價值在於溝通。業務使用者可以對定義提出質疑,分析師可以找出報表中的假設,技術團隊之後也能把達成共識的概念轉化為更詳細的設計。模型維持在團隊能夠共同推理的層次上。 ## 實體關係模型解析 **實體關係(ER)模型**為團隊提供了一種熟悉的視覺化方式,來表示實體、屬性和關係。以一家線上零售商為例。客戶是一個實體,姓名是客戶的一個屬性,而「客戶下訂單」則是一種關係。圖表能讓這些概念在同一頁上一目了然,方便同仁在設計資料庫之前先討論業務結構。 Peter Chen 於 1975 年在首屆 International Conference on Very Large Data Bases 上發表了他的 ER 模型。他的論文於 1976 年 3 月刊登在 _ACM Transactions on Database Systems_ 創刊號上。Chen 的方法讓用商業語言溝通資料需求變得更容易,同時仍為資料庫設計提供結構化的基礎([該論文的歷史背景與 ER 建模脈絡](https://dbs.academy.lv/lection/dbs_LS04EN_erd.pdf))。 ### 把圖表讀成商業語句 如果把每個連接轉換成一句話,簡單的 ER 圖表就會更容易閱讀。「客戶下訂單」描述一種關聯,「訂單包含產品」描述另一種。實體名稱標示出企業需要追蹤的對象,而屬性則提供每個概念的實用細節。 圖表也會引發一份術語清單可能無法揭露的問題。如果一張訂單可以包含多項產品,而一項產品也可以出現在多張訂單上,這種關聯就是多對多。如果一張訂單只能對應一位客戶,模型就應該清楚呈現這項預期。不同建模方法的標記方式可能有所差異,但商業意涵必須保持易於理解。 常見的爭議點在於判斷某個項目應該是實體還是關聯。如果促銷活動有自己的名稱、日期與規則,它可能值得被表示為一個實體,而不只是產品的一項簡單屬性。如果它只是記錄一個沒有獨立商業意義的簡短標籤,一個屬性可能就已足夠。答案取決於企業如何使用這個概念,而不是取決於繪圖慣例。 ER 模型之所以仍然實用,是因為它在溝通與設計之間搭起橋樑。它的概念影響了實體關係圖、邏輯綱要與資料架構的相關工作。若想找到實用的輔助資源來理解這種視覺化格式,請參閱[diagramma entità-relazione spiegato](https://www.electe.net/post/entity-relationship-diagram)。請讓圖表聚焦在人們需要做出的決策上,而不要把它變成每個系統裡每個欄位的清單。 ## 概念資料模型 vs 邏輯資料模型 vs 實體資料模型 團隊經常用「資料模型」這個詞來描述不同詳細程度的設計。將**概念**、**邏輯**與**實體**層級區分開來,能讓人更容易理解一個模型回答的是什麼問題,以及由誰來審查它。 維度概念模型邏輯模型實體模型核心問題哪些業務概念重要，彼此之間如何關聯？這些概念應該如何詳細架構？設計將如何實作與儲存？主要使用對象業務關係人與資料架構師分析師、資料建模人員與設計人員資料庫工程師與管理人員常見內容實體、業務關係、關鍵規則更完整的屬性、鍵值與關聯細節資料表、欄位、資料型態、索引，以及平台特定限制是否與技術相關？否通常不相關是範例輸出客戶、訂單與產品的高階概覽圖顯示欄位與鍵值的詳細設計針對所選系統量身打造的資料庫結構 ### 一個概念，逐步細化 **概念模型**捕捉業務視角。它可以表示訂單（Order）由客戶（Customer）下達，而不必指明任一記錄儲存在何處。這種技術獨立性是刻意為之：即使底層系統發生變化，業務含義仍應保持可用。 **邏輯模型**增加了結構。團隊可以定義更多屬性、釐清識別碼，並解決關聯關係，所得設計仍不綁定於特定資料庫平台。在這個階段，關聯式設計規則可能變得相關。例如，正規化（normalization）有助於判斷某個屬性是否屬於另一個實體，以避免更新時產生重複且相互衝突的資訊副本。在以 OrderID 和 ProductID 作為識別碼的 OrderLine 關聯中，ProductName 依賴於 ProductID，而非完整的複合鍵，因此它應歸屬於 Product，而不是作為 OrderLine 的重複屬性（[正規化規則與範例](https://www.uni-mannheim.de/media/Einrichtungen/dws/Files_Teaching/Database_Technology/FSS2026/CS460_DBT_05_NormalForms.pdf)）。 **實體模型**接著將該設計轉化為針對特定資料庫的實作細節。它涵蓋實際的資料表、欄位、資料類型以及儲存選擇。這些細節對建構與維運系統的人員而言很重要，但不需要主導關於「客戶」一詞意義的最初討論。 這三層區分有其歷史淵源。1975年，ANSI/SPARC 研究提出了一種包含外部層、概念層與內部層的架構。其概念綱要（conceptual schema）描述的是企業層級的資料視角，與實體儲存及存取方式分離。儘管它並未成為普遍實施的正式標準，但其術語有助於確立業務含義與實作細節之間的區別（[三綱要架構](https://en.wikipedia.org/wiki/Three-schema_approach)）。略過概念層可能導致技術團隊憑臆測做出業務決策。 ## 建立概念模型的實務範例 假設一家零售商想了解促銷活動如何影響銷售。它已經有一份每週促銷活動的試算表、一份來自 CRM 的客戶記錄匯出檔，以及來自其銷售系統的訂單資料。第一項任務並不是合併所有檔案，而是先就分析所需呈現的業務概念達成共識。 ### 從業務問題開始 撰寫一個淺白的情境描述：「我們想比較促銷期間下的訂單與其他訂單，並了解客戶購買了哪些產品。」這讓團隊有理由為這些資訊建模，也提供了判斷初稿該包含哪些內容的依據。 識別可能的實體： - **客戶（Customer）**，下訂單的個人或組織。 - **訂單（Order）**，零售商想要分析的購買事件。 - **產品（Product）**，可供銷售的項目。 - **促銷（Promotion）**，一項定義明確、附帶業務規則的優惠。 接著只需加入能讓這些概念清楚呈現所必要的屬性。客戶可能有客戶狀態。訂單可能有訂單日期與狀態。產品可能有產品名稱。促銷活動可能有名稱、有效期間與優惠類型。這些只是有用的起點,並非要求你把試算表的每一欄都複製過來。 ### 對應關聯並測試假設 現在用句子描述這些關係。客戶下訂單。訂單包含產品。促銷活動可以套用於產品。接著,問問在每個關係中可以有多少個實例參與。一位客戶可能下多筆訂單;一筆訂單可以包含多項產品,而一項產品也可能出現在多筆訂單中。如果促銷活動可以涵蓋多項產品,而每項產品在不同時間也可能被納入多個促銷活動,那麼這個關係就是多對多。 棘手的判斷往往在於:一個概念究竟是實體還是屬性。如果業務單位自行管理促銷活動的日期、規則與資格條件,那麼促銷活動比較可能是一個實體。如果「促銷活動」只是附加在產品上的一個簡短標籤,沒有獨立的生命週期,團隊可能會以不同方式建模。不要用猜測來解決這個問題。要詢問負責建立促銷活動的人,了解他們如何定義、變更與評估這些活動。 記錄會影響解讀方式的規則。舉例來說,促銷活動是依據訂單日期還是付款日期來套用?一筆訂單可以包含促銷資格不同的產品嗎?在評估促銷成效時,已取消的訂單是否會被納入計算?這些決定會直接影響報表所能呈現的意義。 最後,拿草稿與試算表及CRM匯出資料中的實際案例做對照檢查。留意不符合預期關係的訂單、重複的客戶標籤,以及橫跨不同產品或期間的促銷活動紀錄。目標不是讓第一版圖表做到鉅細靡遺,而是及早揭露假設,讓業務使用者有機會加以修正。 ## 概念模型為何會被棄置,以及如何避免 正式建模在規劃會議上聽起來很有價值,但一旦進入日常工作,仍可能消失無蹤。一項針對**485位資料庫專業人士**的研究,並輔以**34次訪談**,發現即使受訪者認為正式的概念資料建模有幫助,仍只有不到**40%的人持續採用**。**45.1%**的人表示會以純白板討論作為替代方式,而**42.1%**的人則表示時間不足是一大阻礙([這項關於建模實務與採用情形的研究](https://helda.helsinki.fi/server/api/core/bitstreams/3be353d2-75eb-4d4c-92a2-c3a76c3ec9f1/content))。 給中小企業的啟示並不是每個團隊都應該安排一個大型的建模專案,而是這個流程需要配合大家原本的工作方式。一個耗時太久才能建立或維護的模型,很容易變得過時。一份能釐清當下報表爭議的簡單草稿,可能比一張沒有人會再回頭檢視的精美圖表更有用。 ### 建立最小可行模型 先從回答一個業務問題所需要的概念著手。如果財務部與業務部對訂單營收的認定有分歧,先專注在客戶、訂單、相關的營收定義,以及決定訂單何時被計入的日期上。等分析需要時,再加入產品或促銷活動。你可以隨著新問題的出現,逐步擴充這個模型。 現有資料是實際可行的起點。檢視大家已經在用的試算表、CRM 匯出檔案，或是報表。圈出重複出現的業務術語，標出兩個欄位似乎意思相同的地方，並記下不同團隊使用不同標籤的情況。把這些觀察帶到與流程負責人的簡短討論中。 > **模型存在的價值在於解決決策問題，而非把頁面填滿。** 讓文件聚焦在會影響解讀方式的選擇上：一個實體代表什麼意思、它與其他概念的關係為何、關係是否為選擇性的，以及哪個日期或狀態決定一項指標。讓技術團隊之後再補上實作細節。這樣一來，早期的建模對業務使用者來說就很有用，而不需要他們去設計資料庫。 評估進展的方式，在於人們是否能夠核對報表、一致地解釋某項指標，並在討論中帶入新資料而減少誤解。如果模型不再有幫助，就修改它。這是關於業務意義的共識，不是一張必須維持不變的圖表。 ## 概念模型如何驅動現代分析與 AI 一個定義明確的模型可以在不同系統間扮演**穩定的語意層**。ERP 可能追蹤訂單，CRM 可能追蹤客戶關係，財務系統則可能記錄結算資料。即使每個系統使用不同的欄位名稱，組織仍可以在將這些系統對應整合之前，先就「客戶」、「訂單」和「營收」的意義達成共識。 當分析工作結合不同細節層級的資訊時，這種共識就變得重要。訂單層級的營收描述的是個別交易；客戶月資料則是彙總某位客戶在一段期間內的屬性。如果在未說明資料粒度的情況下連結這些概念，結果可能看似合理，實際上卻回答了錯誤的問題。模型能幫助團隊釐清每個指標代表什麼、適用哪個時間區間，以及應如何解讀這些關係。 ### 讓定義有可追溯的歸屬 概念建模也支援後設資料治理。後設資料是關於資料的資訊，例如業務定義、負責人、有效值或來源對應。ISO/IEC 11179-3:2023 規範了一套後設資料登錄中介模型，提供用於識別、定義、登錄及分類可重複使用項目的結構。相關延伸規範則涵蓋資料元素概念、概念領域及值域（[ISO/IEC 11179-3:2023](https://www.iso.org/standard/78915.html)）。 實務上，團隊可以將「淨銷售額」這類業務概念，與其定義、單位、負責人及來源欄位連結起來。這樣一來，就更容易區分淨銷售額與毛銷售額，或是訂單日期與結算日期。模型並不能保證分析結果一定正確，但它能讓分析人員和自動化流程在合併或比較指標之前，有更清楚的定義可供檢查。 隨著企業越來越多地使用語意層、自動化報表及 AI 輔助分析，這項基礎變得日益重要。關於概念模型建立的研究凸顯了反覆出現的判斷難題，尤其是在決定關係類型、指定基數以及命名關係方面。自然語言的需求可能掩蓋這些選擇：「促銷期間購買的客戶」一詞，並未明確定義什麼算是一次購買、哪個日期界定「期間」，以及客戶是否能透過多筆訂單符合資格（[關於概念建模挑戰的研究](https://link.springer.com/article/10.1007/s10270-022-01051-8?fromPaywallRec=true)）。 對於正在規劃如何提升分析實踐成熟度的團隊而言，Applied 的[資料導向團隊路線圖](https://theapplied.co/blog/analytics-maturity-model)可以為這項建模工作提供有用的背景。處理較非結構化資料來源的團隊，也可以參考[ELECTE 關於半結構化資料的見解](https://www.electe.net/post/semi-structured-data)。無論哪種情況，原則都是一樣的：在信任自動化結果之前，先定義其商業意涵。 ## 重點整理與下一步行動 概念模型是一種**溝通工具**，而非技術上的獎盃。它能幫助同事在將想法嵌入系統或自動化分析之前，就報表背後的人員、事件、產品及衡量指標達成共識。 從一個實際存在的商業問題開始，例如為什麼兩個團隊回報的營收數字不同。接著： - **命名核心概念：**找出與該問題相關的實體。 - **定義語言：**為每個重要術語撰寫簡短的商業定義。 - **連結概念：**用淺顯的句子描述關係，並釐清這些關係是選擇性的還是一對多的。 - **核對實際案例：**將草稿與試算表、CRM 匯出資料及交易紀錄進行比對，找出例外情況。 - **隨業務變化修訂：**當新的決策或報表需求出現時，補充細節。 不必等到文件完美或擁有專門的建模計畫才開始行動。第一份草稿可以只是一張小圖表，附上幾個定義,並清楚標示尚未解決的問題。將它交給使用這些資料的人，釐清會影響決策的假設,並在業務變化時更新模型。 --- ELECTE 是一個為中小企業打造的 AI 驅動資料分析平台，能連結企業資料，協助團隊探索洞察、進行預測並建立報表。如果您正在打造更清晰的定義，以實現更可靠的分析，歡迎[造訪 ELECTE](https://www.electe.net)，了解該平台如何支援您的團隊。