什麼是邏輯資料模型?

邏輯資料模型用來建立資料元素的結構以及它們之間的關係,與詳細說明資料如何佈建的實體資料庫是分開獨立的。邏輯資料模型可做為使用資料的藍圖,邏輯資料模型能將更多資訊添加到概念性的資料建模元素之中,以供進一步使用。

邏輯資料模型圖

邏輯資料模型納入了在日常營運中至關重要的所有資訊元素。

邏輯資料模型的組成部分

邏輯資料模型具有三個主要組件:

  • 實體:每個實體代表一組與業務相關的事物、人或概念
  • 關係:每個關係都代表上述兩個實體之間的關聯
  • 屬性:每個屬性都是描述性的片段、特徵、或任何其他有助於進一步描述實體的資訊

在邏輯資料模型的這些組件中,每一個都被賦予各自的名稱和文字定義。它們用於持續記錄業務規則,以及概述資訊需求。但是,上述組件僅限於對業務需求的描述。並不關心如何處理、實施或儲存所述的業務需求。

現代化您的數據和分析架構
現代化您的數據和分析架構
查看這 13 個用例,以了解怎樣支援當今複雜的數據和分析環境。

對邏輯資料模型的需求

有鑑於資料是任何應用程式、程序或系統的最重要層面,高品質的資料處理和儲存系統必須奠基於強大而準確的底層資料結構之上。健全的資料結構可供應用程式開發人員自由設計最佳的使用者介面、處理系統,或設定統計分析和報告機制。

無論您的系統多麼優雅多麼高級,它都必須滿足要求、遵循規則、達成當初構建它的業務或企業目的,否則它就沒有實際用處。因此,邏輯資料建模需要同時符合應用程式開發的兩個最重要基礎條件:

  1. 業務需求
  2. 高品質資料結構

邏輯資料模型的特徵

這些是邏輯資料模型最重要的特徵:

  • 邏輯資料模型可以描述每個單獨項目的資料需求。然而,它的設計目的是當項目需要時,能夠與其他邏輯資料模型無縫整合。
  • 邏輯資料模型可以獨立於資料庫管理系統之外進行開發和設計,資料庫管理系統的類型對其影響不大。
  • 資料屬性包含具有精確長度和精度要求的資料類型。
  • 在邏輯資料建模時,不會定義主鍵或輔助鍵。在資料建模層級,必須先驗證和調整既定的連接器詳細資訊,之後才能定義關係。
  • 邏輯資料模型像是以圖形表示某一業務領域的資訊需求,本身並不是資料庫或資料庫管理系統。
  • 邏輯資料模型獨立於任何實體資料儲存設備之外,例如檔案系統。
  • 邏輯資料模型必須設計為獨立於技術之外,以免受到技術快速變遷的影響。

邏輯資料建模的細節

簡而言之,資料模型是一組資料規格和圖表,用於解釋資料需求和相關設計。一般來說,資料建模類型和活動可分為三種類型:

概念資料模型

這種資料模型基本上用來定義固有的系統內容。建立概念資料模型的人通常是企業的利益相關者和資料架構師,他們的目的是整理和定義各種業務概念與規則,並設定其參數或範圍。

邏輯資料模型

邏輯資料模型用於定義系統應如何佈建,無論是使用何種資料庫管理系統。邏輯資料模型的建立者通常是資料架構師和業務分析師,建立邏輯資料模型的目標是開發一份高階技術地圖,用來對照底層的規則和資料結構。

實體資料模型

實體資料模型與如何佈建系統、以及特定資料庫管理系統中的因素有關。此模型通常由開發人員建立,重點在於定義如何使用實際的資料庫來達成業務目標。

一般來說,概念資料建模和邏輯資料建模都是「需求分析」類型的活動,而實體資料建模被認為是設計活動。

邏輯資料模型是實體資料模型的基礎,納入了業務需求並會收集中繼資料,可以使用標準技術和資料建模符號來完成邏輯資料建模。

資料建模是一項旨在整理資料語義、描述資料、解決資料一致性限制的活動,可以比喻為建築師的圖紙或建築示意圖,它構成了概念建模的基礎,用以建立各種資料組件之間的關係。

資料建模技術分為以下兩類:

  1. 實體關係 (E-R) 模型
  2. UML(統一建模語言)

邏輯資料建模屬於實體關係模型,使用實體關係圖(稱為 ERD)構建而成,這是一種標準建模技術,被全球資料建模者當成一種溝通工具,其中包含的是完整業務需求集,而非技術組件。

邏輯資料模型軟體
認識單一的治理、管理和使用全部共用數據資產的的解決方案
使用多合一方法來管理整個企業的資料資產,避免孤島

邏輯資料模型的優點

  • 由於資料在時間推移下仍能保持穩定,因此邏輯資料模型也是穩定的,並且非常有利於資料重複使用和實際資料共享,最終導致冗餘資料的儲存需求減少。
  • 邏輯資料模型的組件可以被回收、重複使用,也可以根據更多團隊(經常變化)的需求進行調整。
  • 從長遠來看,它的優勢能夠抵消與構建和維護邏輯資料模型相關的成本,尤其是一開始就識別和整合所有的業務需求和規則,更是極大的優點。
  • 直接受益於整合和澄清業務規則,使構建過程的各個步驟(即設計、編碼、測試和部署)都能更快完成。
  • 有了邏輯資料模型,更容易在正式實施之前,於開發生命週期內進行必要更改、修正錯誤或輸入遺漏的資料,因此也更具有成本效益。
  • 由於能夠主動回應,因此可以最大限度地減少使用者提出更改請求。
  • 邏輯資料模型可用於影響力分析,因為每個業務流程和規則都連結在其中。
  • 由於邏輯資料模型中的物件都帶有符合業務用語的文字定義,因此更容易用來維護和存取系統文件。

不開發邏輯資料模型的話會發生什麼事?

簡而言之,可能會出現問題。如果不提醒使用者注意資料,使用者可能會被流程和活動牽著鼻子走,而不是將技術當做設計新系統的關鍵要素。純粹基於實際工作流程來設計資料模型,可能會忽略了具有代表性的關鍵業務需求。

如果不使用資料元素來概述業務需求,那麼設計人員創造的表格和檔案往往整理得不夠完善,缺乏健全的底層結構。若是在編碼、測試甚至部署的過程中,才從螢幕或報告佈局中發現並嘗試釐清額外的資料元素,將迫使開發人員在行動時只能被動因應。而且其輸出將成為一種難以操作或維護的混搭實體,充滿了錯誤或多餘的內容,會減損系統的文件記錄能力,耗時且可能發揮不了用處。

由於邏輯資料模型是根據基本業務需求以及它們之間的關係來定義資料元素結構,因此沒有適當的邏輯資料模型,意味著將會錯過很多可以改進業務流程的機會,只是單純讓開發人員將現有的程序自動化,或者在新技術平台上重新建立終將會過時的老舊系統而以。

應用邏輯資料建模技術,能使資料分析師不受限於最新技術進行獨立思考,專注於改進業務流程。

因此,邏輯資料模型應該當做每個應用程式開發專案中不可或缺的重要組成部分。這是一個很重要的步驟,理想情況下甚至比資料庫設計更優先。