商業分析指南/資料建模和資料文件
商業資料是任何組織的關鍵資產。資料中包含的資訊在組織運營、報告和衡量組織績效方面發揮著重要作用。資訊系統提供了捕獲和共享資料以及監控業務績效的手段。健全的資料結構是普遍需要的,以確保資料完整性和最大程度地減少未來的應用程式維護成本。為資訊應用程式建立“正確”的資料儲存涉及資料治理、瞭解資料流以及開發可靠的基礎,以確保持續的可靠性、穩定性和投資的最大效益。
對資訊系統的投資對於構建新應用程式、修改現有應用程式或購買和遷移到 COTS(商用現成)解決方案來說可能非常高。為了確保這些投資能獲得最大回報,可以透過資料治理和安全的形式實施控制。這些控制可能存在於組織細分內部、跨細分或跨整個組織。一些控制甚至具有全球性質,由國際協議決定並遵循公認標準。
資料治理涉及誰負責組織資料以及如何執行治理決策和流程。資料治理可能採用一種或多種不同的方法。這些包括
- 自上而下 - 決策具有權威性,影響整個組織
- 自下而上 - 與資料相關的決策在較低級別制定(例如,命名約定)
- 自中心向外 - 通常涉及聘用顧問來考慮所有利益相關者的治理需求並提出組織範圍的建議(對於批准的決策,會導致自上而下的決策)
- 孤島內 - 多個組根據集體協議制定治理標準[1]。
資料治理的目標包括確保商業資料的質量和安全、資料符合組織標準、總體資料規則和定義,以及確保資料可信。
在建立新的資訊系統時,應用程式通常由一個或多個業務程式領域或部門贊助。組織資料治理要求識別那些將“擁有”資料的個人。這些所有者將負責監督、與組織的治理委員會協調、符合採用的標準和法律以及確保資料訪問許可權。一個“所有者”可能負責應用程式域內的資料,或者責任可能分散在多個所有者之間,分佈在一組整合應用程式中[2]。無論如何確定組織內資料所有者(或所有者),專案資料需求的批准都將來自該所有者角色。
資料冗餘是當同一資訊在同一個或多個數據儲存中被多次捕獲時造成的。如今大多數資訊系統都由基於 Edgar Codd[3]最初設計的關聯模式構建的資料儲存支援。這種型別的模式最大限度地減少了冗餘並確保資料完整性。與資料冗餘相關的問題圍繞著這些資料的多個例項之間的衝突,並導致與資料相關的更高的運營成本。這些成本包括與資料輸入、檢索和維護相關的成本[4]。它們還構成安全威脅,因為它們在資料中引入了異常——無法確保終端使用者檢視的是單個真相版本。適當的資料定義確保識別任何冗餘,並在實際設計系統之前對其進行糾正或緩解,從而降低相關的開發和持續維護成本。
應用程式資料的文件對於確保對資料中包含的資訊有共同的理解以及確保該資訊的可靠性至關重要。業務分析師通常負責為資訊系統專案建立資料文件,並將此文件與治理流程和規則保持一致。文件工件將跨越整個 SDLC,從啟動到實施。

跟蹤資料在應用程式中的流動包括識別將得到支援的資料來源、轉換和目標。目標包括資料儲存和使用資料的下游流程。資料來源可以在組織內部和組織之間共享,或者可能涉及外部實體。它們包括資料輸入、現有資料庫、計算機檔案以及來自外部應用程式的資料流。確定資料來源後,定義必須執行的轉換或操作資料的流程。這些流程包括將資料從源格式轉換為目標格式。目標包括資料庫、檔案、報告和接收轉換流程輸出的外部應用程式。資料流圖捕獲此資訊以進行驗證和設計目的。
網際網路上有很多教程可以參考來建立資料流圖。一般來說,在渲染資料輸入、處理和資料輸出方面保持一致性將實現以下目標:以一種易於理解的方式定義資料流,以便那些將審查和驗證圖內容的人能夠理解。影像右側包含使用 Yourdon/DeMarco 符號[5]的資料流圖示例。

捕獲資料元素定義最常用的格式是資料字典。該工件對於資料治理以及確保所有利益相關者對資料是什麼都有共同的理解至關重要。資料字典中通常包含的資訊包括資料所在位置的識別(資訊系統、關係表)、確切的資料庫欄位或資料元素、資料元素代表的內容以及元素的格式。右側影像提供了一個數據字典可能是什麼樣子的示例。

在專案的需求收集階段,當需要進行跨多個應用程式的資料整合,或進行某種程度的主資料管理 (MDM),或進行某種形式的組織資料治理時,會使用常用資料矩陣。它是一種資料字典的形式,包含治理域的範圍。為了構建這種矩陣,資料元素將根據治理域列出,並提供有關該資料與與其互動的組織單元或應用程式之間的資訊[6]。應構建此型別的圖表以包含與所考慮問題相關的的資訊(參見右側影像)。
考慮一個資訊系統,它使用來自其他組織(內部)應用程式的外部資料元素。這些元素的定義、含義和格式對於整合至關重要。在治理成熟度高的組織中,客戶名(例如)將在整個組織中具有相同的資料元素定義和格式。實際上,大多陣列織並未在整個組織範圍內完全統一所有資料定義;在確定整合工作專案需求時,應使用常用資料矩陣對整合專案的資料元素進行彙總。在這種情況下,矩陣中包含的資訊(矩陣單元格)可能包含資料元素格式資訊,以識別可能需要對資料進行的任何轉換以將其與專案資訊整合。
資料需求建模
[edit | edit source]為了建立新的應用程式和進行應用程式增強,在較高層次上對資料進行建模可以為設計工作提供指導。通常,業務分析師不參與應用程式的實際開發,但與專案相關的需求將決定支援專案可交付成果所需的哪些資料,反之亦然。與將高階業務需求細化為功能需求,然後詳細說明到設計規範一樣,概念資料模型可以作為定義邏輯資料模型和物理資料模型的起點。
概念模型
[edit | edit source]
根據Merriam-Webster詞典,概念描述了對事物的想法,或者其工作原理[7]。概念資料模型說明了組織想要或需要捕獲的資訊[8]。它是一個高階、面向業務的模型,捕獲運營資料需求:組織需要捕獲哪些資料?對這個問題的回答將識別需要探索以定義需求的資料“實體”。概念資料模型代表了企業為了支援組織或專案領域記憶體在的業務流程而需要的資訊[9]。
這種型別的模型非常高層次,指導應用程式資料儲存的設計。它展示了需要捕獲資訊的“事物”或實體(名詞),並指示這些識別出的“事物”之間的高階關係。該模型獨立於用於實施解決方案的任何技術,不包括諸如主鍵或實體屬性之類的細節[10]。概念資料模型在專案的需求收集階段最有幫助,並且在為問題域定義邏輯模型後可以丟棄[11]。
邏輯實體關係模型
[edit | edit source]

邏輯資料模型包含支援應用程式所需的實體,關於每個實體的資訊(包括屬性和唯一識別符號),以及實體之間所需的關係。這種型別的模型可以參考概念資料模型,但識別的實體關係結構被修改以支援(在較高層次上)技術解決方案域。
依賴於RDBMS平臺的應用程式通常會使用實體關係 (ER) 圖格式來說明邏輯資料模型。每個不同的實體都用相關的屬性定義,這樣每個屬性都特定於該實體,並且僅針對該實體。對模型中的資料進行規範化確保在建立物理資料模型時,資料架構設計將確保不會發生資料異常 - 也就是說,儲存在資料庫中的資料將具有完整性,並且使用者可以依賴這些資料。
物理資料模型
[edit | edit source]

物理資料模型為支援業務運營的資料結構提供了詳細的規範。邏輯資料模型通常使用基線專案功能需求進行完成,並且被擴充套件和修改以符合用於儲存資料的架構。這可能反映任何型別的架構 - 關係資料庫或 XML 資料儲存都需要這種規範。美國衛生與公眾服務部將這種型別的資料模型定義為“邏輯資料模型 (LDM) 的特定於資料庫的實現”[12]。
物理資料模型包括表和列的定義(對於關係資料庫)或模式和元素(對於 XML 資料庫),域(屬性或元素)值,物理資料型別,約束,唯一鍵和索引[13]。關係及其基數,XML 擴充套件,特定 RDBMS 架構資訊,可空性和值長度/精度是通常包含在模型中的其他定義。物理資料模型可以使用生成建立資料庫所需程式碼的工具建立。這些工具通常還提供逆向工程資料庫的功能,為現有應用程式生成物理資料模型[14]。
參考資料
[edit | edit source]- ↑ Thomas, Gwen. "Choosing Governance Models". 資料治理研究院. Retrieved 02/05/2014.
{{cite web}}: Check date values in:|accessdate=(help) - ↑ Thomas, Gwen. "Assigning Data Ownership". 資料治理研究院. Retrieved 02/05/2014.
{{cite web}}: Check date values in:|accessdate=(help) - ↑ "Edgar F. Codd". IBM 研究新聞. 2003. Retrieved 02/12/2014.
{{cite web}}: Check date values in:|accessdate=(help) - ↑ Streiff, John (2001). "Estimating the Costs of Data Redundancy?". Retrieved 02/12/2014.
{{cite web}}: Check date values in:|accessdate=(help) - ↑ Yourdon, E. (2006). "Just Enough Structured Analysis, 第 9 章" (PDF). 檢索於 2014 年 2 月 5 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ Seiner, Robert S. (2006). "資料管理的資料管理方法". 資料管理通訊 - TDan.com. 檢索於 2014 年 2 月 5 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ "概念". 梅里亞姆-韋伯斯特詞典. 檢索於 2014 年 10 月 2 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ Stiglich, Pete (2007). "概念資料模型的好處是什麼?". TechTarget. 檢索於 2014 年 10 月 2 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ Bowman, David (2009). "概念資料模型". 大衛·鮑曼的資訊管理清單. 檢索於 2014 年 10 月 2 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ Gottesdiener, Ellen (2005). 軟體需求記憶訓練,第 1 版. GOAL/APC. p. 183.
- ↑ Wambler, Scott. "資料建模 101". AgileData.org. 檢索於 2014 年 10 月 7 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ "物理資料模型模板". 美國衛生與公眾服務部. 2009. 檢索於 2014 年 10 月 7 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ "物理資料模型模板". 美國衛生與公眾服務部. 2009. 檢索於 2014 年 10 月 7 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助) - ↑ Ambler, Scott (2004). "物理資料模型 (PDM)s:敏捷介紹 (物件入門第 3 版,第 12 章)". 檢索於 2014 年 10 月 7 日.
{{cite web}}: 請檢查日期值:|accessdate=(幫助)