什麼是資料建模？
資料建模是建立定義一個組織之資訊收集和管理系統的視覺化表示或藍圖的程序。此藍圖或資料模型可協助不同的利害關係人 (如資料分析師、科學家和工程師) 建立其組織資料的統一檢視。該模型概述了該企業收集的資料、不同資料集之間的關係，以及用於儲存和分析資料的方法。
為什麼資料建模很重要？
當今的組織從許多不同的來源收集大量資料。然而，原始資料是不夠的。您需要分析資料以獲得可引導您做出營利業務決策的可行洞察。準確的資料分析需要高效的資料收集、儲存和處理。資料庫技術和資料處理工具有很多，不同的資料集需要不同的工具進行高效分析。
資料建模讓您有機會了解您的資料並做出正確的技術選擇，以存放和管理此資料。就像建築師在建造房屋之前設計藍圖一樣，企業利害關係人會設計資料模型，再為其組織設計資料庫解決方案。
資料建模帶來以下優勢：
- 減少資料庫軟體開發中的錯誤
- 促進資料庫設計和建立的速度和效率
- 在整個組織內建立資料文件和系統設計的一致性
- 促進資料工程師與商業智慧團隊之間的溝通
資料模型有哪些類型？
資料建模通常從概念上表示資料開始，然後在所選技術的相關內容中再次呈現。分析師和利害關係人在資料設計階段，建立若干不同類型的資料模型。以下是三種主要類型的資料模型：
概念資料模型
概念資料模型提供資料的總體檢視。他們解釋如下資訊：
- 系統包含哪些資料
- 資料屬性和資料相關條件或約束
- 資料與哪些業務規則相關
- 如何最好地整理資料
- 安全性和資料完整性要求
業務利害關係人和分析師通常會建立概念模型。這是一個簡單的圖表呈現，不遵循正式的資料建模規則。重要的是可協助技術和非技術利害關係人分享共同的願景，並就其資料專案的用途、範圍和設計達成一致。
概念資料模型範例
例如，汽車經銷商的概念資料模型可能會顯示如下資料實體：
- 展廳實體，呈現有關經銷商擁有的不同商店的資訊
- 汽車實體，呈現經銷商目前庫存的若干車輛
- 客戶實體，呈現在經銷商採購的所有客戶
- 銷售實體，呈現實際銷售資訊
- 銷售人員實體，呈現有關為經銷商工作的所有銷售人員的資訊
此概念模型還將包含如下業務需求：
- 每輛車都必須屬於特定的展廳。
- 每筆銷售都必須至少有一名銷售人員和一名與之關聯的客戶。
- 每輛車都必須有品牌名稱和產品編號。
- 每個客戶都必須提供其電話號碼和電子郵件地址。
因此，概念模型充當業務規則與底層實體資料庫管理系統 (DBMS) 之間的橋樑。概念資料模型也稱為網域模型。
邏輯資料模型
邏輯資料模型將概念資料類別映射至技術資料結構。其提供更多有關概念資料模型中識別的資料概念和複雜資料關係的詳細資訊，例如：
- 各種屬性的資料類型 (例如，字串或數字)
- 資料實體之間的關係
- 資料中的主要屬性或關鍵欄位
資料架構師與分析師協作建立邏輯模型。他們遵循幾個正式的資料建模系統之一來建立呈現。有時，敏捷團隊可能會選擇跳過這一步，直接從概念模型轉向實體模型。然而，這些模型對於設計大型資料庫 (稱為資料倉儲) 和設計自動報告系統都很有用。
邏輯資料模型範例
在我們的汽車經銷商範例中，邏輯資料模型將擴展概念模型，以及更深入地探究資料類別，如下所示：
- 展廳實體具有名稱和位置等欄位作為文字資料，以及電話號碼作為數字資料。
- 客戶實體具有格式為 [email protected] 或 [email protected] 的電子郵件地址欄位。欄位名稱的長度不能超過 100 個字元。
- 銷售實體具有客戶姓名和銷售人員姓名作為欄位，銷售日期作為日期資料類型，以及金額作為十進位資料類型。
因此，邏輯模型充當概念資料模型與開發人員用於建立資料庫的底層技術和資料庫語言之間的橋樑。然而，它們與技術無關，您可以使用任何資料庫語言來實作。資料工程師和利害關係人通常在建立邏輯資料模型後做出技術決策。
實體資料模型
實體資料模型將邏輯資料模型映射至特定 DBMS 技術，並使用軟體的術語。例如，他們提供有關以下各項的詳細資訊：
- DBMS 中呈現的資料欄位類型
- DBMS 中呈現的資料關係
- 其他詳細資訊，如效能調整
資料工程師在最終設計實作之前建立實體模型。他們還遵循正式的資料建模技術，以確保其涵蓋設計的所有方面。
實體資料模型範例
假設汽車經銷商決定在 Amazon S3 Glacier Flexible Retrieval 中建立資料封存。其實體資料模型描述以下規範：
- 在「銷售」中，銷售金額為浮點資料類型，銷售日期為時間戳記資料類型。
- 在「客戶」中，客戶名稱為字串資料類型。
- 在 S3 Glacier 靈活擷取術語中，文件庫是資料的地理位置。
您的實體資料模型還包含其他詳細資訊，例如您將在哪個 AWS 區域建立文件庫。 因此，實體資料模型充當邏輯資料模型與最終技術實作之間的橋樑。
資料建模技術有哪些類型？
資料建模技術是可用於建立不同資料模型的不同方法。由於資料庫概念和資料管控的創新，這些方法隨時間的推移而演進。以下是資料建模的主要類型：
階層式資料建模
在階層式資料建模中，您可以用樹狀格式呈現各種資料元素之間的關係。階層式資料模型呈現一對多關係，父資料類別或根資料類別映射至多個子資料。
在汽車經銷商範例中，父類展廳將實體汽車和銷售人員作為子類，因為一個展廳有多輛汽車以及在其中工作的多個銷售人員。
圖形資料建模
隨著時間的推移，階層式資料建模已經演進為圖形資料建模。圖形資料模型呈現平等對待實體的資料關係。實體能夠以一對多或多對多關係相互連結，而無需任何父子概念。
例如，一個展廳可以有多個銷售人員，如果不同地點的輪班時間不同，一個銷售人員也可以在多個展廳工作。
關聯式資料建模
關聯式資料建模是一種常用的建模方法，該方法將資料類視覺化為資料表。不同的資料表使用呈現真實世界實體關係的索引鍵聯結或連結在一起。您可以使用關聯式資料庫技術來存放結構化資料，而關聯式資料模型則是呈現您的關聯式資料庫結構的實用方法。
例如，汽車經銷商將具有呈現銷售人員資料表和汽車資料表的關聯式資料模型，如下所示：
| 銷售人員 ID | 姓名 |
| 1 | Jane |
| 2 | John |
| 汽車 ID | 汽車品牌 |
| C1 | XYZ |
| C2 | ABC |
銷售人員 ID 和汽車 ID 是唯一識別個別真實世界實體的主索引鍵。在展廳資料表中，這些主索引鍵充當連結資料區段的外部索引鍵。
| 展廳 ID | 展廳名稱 | 銷售人員 ID | 汽車 ID |
| S1 | 紐約展廳 | 1 | C1 |
在關聯式資料庫中，主索引鍵和外部索引鍵配合，以顯示資料關係。上表顯示展廳可以有銷售人員和汽車。
實體關聯式資料建模
實體關聯式 (ER) 資料建模使用形式圖表來呈現資料庫中實體之間的關係。資料架構師使用多種 ER 建模工具來呈現資料。
物件導向型資料建模
物件導向型程式設計使用稱為物件的資料結構來存放資料。這些資料物件是真實世界實體的軟體抽象。例如，在物件導向型資料模型中，汽車經銷商將擁有客戶等資料物件，其屬性包括姓名、地址和電話號碼。您將存放客戶資料，以便將每個真實世界的客戶呈現為客戶資料物件。
物件導向型資料模型克服了關聯式資料模型的許多限制，在多媒體資料庫中很常見。
維度資料建模
現代企業運算使用資料倉儲技術來存放大量資料以進行分析。您可以使用維度資料建模專案，從資料倉儲中進行高速資料儲存和擷取。維度模型使用重複或冗餘資料，其效能優於使用更少的資料儲存空間。
例如，在維度資料模型中，汽車經銷商具有汽車、展廳和時間等維度。汽車維度具有名稱和品牌等屬性，但展廳維度具有州、城市、街道名稱和展廳等階層。
什麼是資料建模程序？
資料建模程序遵循一系列步驟，您必須重複執行這些步驟，直至建立全面的資料模型。在任何組織中，不同的利害關係人聚集在一起，共同建立完整的資料檢視。雖然步驟因資料建模的類型而異，但一般概觀如下所示。
步驟 1：識別實體及其屬性
識別資料模型中的所有實體。每個實體在邏輯上應與所有其他實體不同，並且可以呈現人、地點、物件、概念或事件。每個實體各不相同，因為它具有一個或多個獨特的屬性。您可以將實體視為資料模型中的名詞，將屬性視為形容詞。
步驟 2：識別實體之間的關係
不同實體之間的關係是資料建模的核心。業務規則最初在概念層級定義這些關係。您可以將關係視為資料模型中的動詞。例如，銷售人員銷售許多汽車，或者展廳雇用了許多銷售人員。
步驟 3：確定資料建模技術
從概念上了解實體及其關係後，您可以確定最適合您使用案例的資料建模技術。例如，您可以對結構化資料使用關聯式資料建模，但對非結構化資料使用維度資料建模。
步驟 4：最佳化與反覆運作
您可以進一步最佳化資料模型，以適應您的技術和效能要求。例如，如果您打算使用 Amazon Aurora 和結構化查詢語言 (SQL)，您需要將實體直接放入資料表中，並使用外部索引鍵來指定關係。相比之下，如果您選擇使用 Amazon DynamoDB，則需要在為資料表建模之前考慮存取模式。因為 DynamoDB 優先考慮速度，所以您首先確定將如何存取您的資料，然後以將要存取的表單對您的資料進行建模。
您的技術和需求隨時間的推移而變化，您通常會反覆重新檢視這些步驟。
AWS 如何協助進行資料建模？
您還可以使用 AWS Amplify DataStore 更快、更輕鬆地進行資料建模，以建置行動和 Web 應用程式。它具有視覺化和以程式碼為基礎的介面，用於定義您的資料模型與關係，這將加速您的應用程式開發。
立即建立免費帳戶，開始在 AWS 上進行資料建模。
