使用關注點導航資料體系結構
是我們重新構模組化式、資料模型和資料架構的獨特機會。我們确實需要做一些更好的事情。
現實世界充滿了憂慮，其中有些或多或少是沖突的。一個很好的例子是模式（Schema）生命周期讨論：模式優先？模式最後？沒有模式？顯然主要是技術層面的問題。但同樣，一些業務需求隻能通過極其嚴格的資料設計來解決。以金融部門的合規報告為例。然而，其他的商業機會并不是真的依賴于強大的、先期的模式設計。靈活的、逐漸的模式演化作為一個持續的過程，肯定有它的吸引力。
2019年的唯一機會是出現了一種用于屬性圖的标準圖形查詢語言（standard graph query language for property graphs）（參見https://www.gqlstandards.org/home). 這包括對模式支援的考慮。挑戰在于：我們能否在2019年建構一個适合大多數上下文、業務情況和開發風格的模式架構？
讓我們首先探索現代資料和資訊體系結構的基礎，駛向2019年風雨交加的大海。
全級别(scale)資料架構
一個非正式的歐洲資料架構師組織稱為全尺寸資料架構師（Full Scale Data Architects），它在将資料體系結構融入當今現實方面取得了長足的進步。以下是集團創始人之一荷蘭人Martijn Evers的使命宣言：
作為一個開始，RonaldDamhof和我正試圖讓資料架構師們掌握資料的新現實，以及如何重新獲得控制權。為此，我們發起了一場更全級别的資料架構師運動，幫助我們應對不斷增長的資料海嘯。為了提高認識，我們為（有抱負的）全面資料架構師設定了10條戒律。加入我們對抗資料熵的任務”。
他們的元架構概述如下：
實質上，四象限将兩個互相競争的次元結合起來：
- 資料控制與資料靈活性
- 資料傳送（推送）與資料消費(拉取）
以下是我對基本要素的個人“藝術印象”：
我特别喜歡他們對控制與靈活性困境的視覺隐喻
你必須牢牢抓住兩角來控制進攻的公牛。你可以稍微改變一下路線，但代價是要麼降低品質，要麼降低靈活性。
好的，現在我們（在荷蘭人的幫助下）已經确定了全尺寸資料架構的元特征。那麼，什麼決定了哪些事物進入哪個象限？
我們需要追溯到1974年，讓（荷蘭）計算機科學先驅埃德斯格迪傑克斯特拉（Edsger Dijkstra）善意地提醒我們，在他的“關于科學思想的作用”中，“關注點分離”的重要性。
多層次關注架構
Edsger Dijkstra正與Peter Naur教授一起研究歐洲Algol 60項目。彼得·諾爾（Peter Naur）是我的教授，我在哥本哈根大學（University of哥本哈根）注冊的第二年，他第一次擔任該大學計算機科學（computing science）這一新領域的教授。我記得迪克斯特拉教授很好。是以，我感謝馬蒂金·埃弗斯提醒我關注點哲學的分離。我将讓Martijn解釋關注點在資料架構中的作用：
在技術和商業需求的推動下，新的“資料/資訊”模組化思想、方法和設計的數量正在激增。作為架構師，我們需要掌握這種新的動态…這是我改變遊戲的線索。我不想設計另一種類型的資料保管庫（ Data Vault）、錨定模組化（Anchor Modeling）或基于事實的模組化，而是想扭轉局面。不是模組化技術/方法應該具有中心階段，而是它們的潛在關注點。各種各樣的模組化是無止境的，但是他們試圖管理的關注點并不是……因為我們看到一個運動，一方面我們有嚴格和精益的模組化方法，這些方法不能獨立發揮作用，而隻關注一組特定的關注點，另一方面，我們看到了一些占主導地位的模組化方法，它們試圖做所有的事情，但是做得不太好。一件合身的衣服越來越不現實了。此外，資料模組化架構一直被視為非常靜态的，但這也在迅速變化。我們不能一次解決所有問題，是以組織進行資料模組化/組織的方式逐漸改變變得越來越重要。這一切使我相信，了解和管理“資料模組化”的不可知論方法正成為一種必要。
換言之，我們必須把這些問題公之于衆。我們必須了解他們是如何互相依賴的。這将給我們一個“路線圖”的幾個不同的路線，你可以采取解決一些具體的資料傳遞挑戰。
在我（2016）的關于NoSQL和SQL的圖形資料模組化的書中。我開發了一套全面的資料模組化需求。我現在已經把馬蒂金·埃弗斯的擔憂和我的一樣，合并成了多層次的。我建議這三個層次：
- 業務級關注點
- 解決方案級别（邏輯級别）關注點
- 實施問題
讓我們在模式設計的上下文中檢視這三個級别。請注意，屬性圖（property graphs）（即将釋出的标準GQL标準的主題區域）非常接近業務概念級别（從白闆到資料庫可能非常容易），這意味着所有3個級别也都與圖的模式設計上下文（不太窄）相關。
關于資料象限矩陣，大多數（但不是所有）關注點在其中一個象限中有一個自然的“家”（見下表）。有些問題與兩個或多個象限有關。
還要注意的是，3個級别的類型都有一些“先天遺傳”。
一般關注
- 面向業務的術語應該在所有表示級别（可能有一些文法上的變化）中占主導地位，Q1，但是在所有4個級别中都有展現，如相關的
- 設定各級代數支援（我最喜歡的愛好馬），Q1-4
- 模式優先；在許多業務領域中是一個有效的關注點，需要可靠的、經過驗證的、受治理的、經業務準許的定義和盡可能高品質的資料，Q1
- 無模式；在許多業務領域也是一個有效的關注點，現在這裡需要大量具有意義和結構的資料，這些資料尚未被發現，Q3，Q4
- 精化；（感謝Martijn提出了一個重要的問題）——……許多人假設所有模型都有相同的精化級别，即轉換在語義上是等價的，甚至是同構的。但有些模型可能包含不同層次的抽象。為此，模型需要成為一個三維矩陣。在這個立方體中旅行是需要的，以表示我們在實際資料/資訊模組化中看到的抽象和精化。Q1,Q4
業務級關注點
- 應啟用商業術語（包括定義），Q2
- 基本依賴（概念之間的關系，功能依賴和結構依賴），Q1
- 業務友好的啟發和可視化，面向業務的級别必須建立在概念模型範例（我的另一個最喜歡的愛好馬）的基礎上，Q1，Q2
- 最小努力的業務概念模型；簡短的“從白闆到第一個剪切模式的路徑”，應該易于維護，Q3
- 解決方案獨立性，概念級架構詳細資訊應可從解決方案級架構詳細資訊派生，Q1
- 标準可視化範例，Q1-4
- 标準概念類型（Q1）：業務對象業務對象的屬性示例值（用于說明）。
- 标準關系類型（Q1）：具有簡單基數的命名、定向關系業務對象之間關系的定向樣式業務對象與其屬性之間關系的無向樣式。
- 一般資料類型（數字、字元串、日期、金額…），Q1
- 在模式中作為文本注釋寫出的簡單業務規則，Q1
解決方案級别的關注點
- 平台獨立性，解決方案級别的資料架構詳細資訊必須獨立于資料存儲平台，Q1
- 解決方案派生；解決方案級架構應該從業務概念架構（其子集）派生；一些概念成為邏輯業務對象，而其他概念成為這些業務對象的屬性，Q1，Q4
- 逐漸的解決方案優化；解決方案級别的模式應該是漸進和疊代擴充的（有設計決策），Q1，Q3
- 圖和子圖（包括集合），Q1-4圖（節點和關系的集合）子圖（圖的子集，例如通過集合代數）集合（集合代數）
- 唯一性；限制條件，例如連接配接的業務密鑰應該是可定義的，Q1
- Identity；Identity與惟一性密切相關，對解決方案級細節（與實作細節分離）的支援也應該是可定義的，包括對辨別符和代理項的支援；參見下一個，Q1
- 可更新性；確定所有功能依賴項都已在語義上得到解決，而沒有懸挂屬性和關系，并且所有辨別都已就位（在某些上下文中，這個問題可以放寬），Q1
- 模式控制的審計跟蹤和沿襲；解決方案級别的模式應該能夠包含技術審計資料，Q1
- 時間完整性，Q1，Q2
- 時間序列方面，Q1，Q2
- 屬性圖類型（Q1）：泛型節點（否則為無類型節點）業務對象（标記為概念）多類型節點業務對象或無類型節點的屬性（屬性是概念，共享擁有它們的業務對象的辨別）在适用的情況下，具有精确基數的命名、定向關系
- 強制屬性；應可定義，Q1
實體層面的擔憂
- 智能接收；推斷或隐式類型，加載泛型節點類型，标記節點類型和關系類型，但沒有顯式的預先模式定義（但有可用的事後實體模式詳細資訊），Q3，Q4
- 轉換的簡單映射；例如：實體級别的模式細節應該很容易映射回解決方案級别的模式細節，例如通過抽象的可視化等，Q1
- 完整的沿襲；從實體模式到解決方案模式再到業務概念模型的簡單回溯，Q1
- 限制設施（以支援解決方案架構詳細資訊），Q1
- 辨別、唯一性和排序索引工具，Q1
- 時間完整性支援，Q1
- 把以上所有的問題都看作是一個初步的賭注。當然有事情要讨論！
到最終模式的不同路徑
整合意味着很多關注點！
從上面的清單中可以看到，嚴格的治理（Q1）相當于許多關注點；事實上，三分之二的關注點。它們之間必然有相當多的依賴關系。
隻有兩個問題在第一季度沒有發現：
- 無模式，以及
- 智能攝取
它們之間有些聯系，有點與嚴格治理的理念對立。
一些關注點是“全局的”：集合代數、可視化範式、逐漸求精、圖和子圖以及時間序列。
還有一些問題，适用于幾個象限。
關注點依賴
我做了一個快速的第一輪的依賴關系之間的關注。有些關切需要存在其他關切：
我将這些問題與任何先決條件（暫時）無關：
- 面向業務的術語
- 商業術語
- 轉換的簡單映射
- 圖和子圖
- 平台獨立性
- 精煉
- 集合代數
- 解決方案獨立性
- 逐漸求精
- 時間完整性
- 時間序列
“先決條件”，即“模式設計者使用者”必須指定由關注點處理的内容。
我幾乎肯定忽略了一些事情；時間會證明…
使用模式的一些可能場景
我們現在能夠回答有關如何使用即将開發的屬性圖模式工具的問題。看看上面的依賴關系圖。
我們能少用模式嗎（沒有預先的模式定義）？是的，我們可以，隻要“智能攝取”到位。
我們能先處理schema嗎？哦，是的，我們可以。
首先可工作的模式的最低要求是什麼？好吧，我們需要能夠指定模式詳細資訊，它們是屬性圖類型。除此之外，還有其他幾個值得關注的領域，這些領域可以根據實際的上下文被模式語言所覆寫。關注點按治理類型和“模式産品”的傳遞類型分組。
我必須開始幾乎定義一個業務術語表（術語定義）？不，任何其他問題都不需要這種特殊的問題。
如何以簡單的方式在模式中建立業務概念模型？嗯，我必須能夠映射到标準概念類型和标準關系類型。反過來，這兩個要求我們可以命名基本依賴項，它們成為建立屬性和關系的鑒别器。它還需要一些對業務友好的啟發式工具，在我看來，這是可視化（概念模型的可視化），但這種關注是可選的，至少在上圖中描述的元架構中是這樣。
我可以使用schema last方法嗎？是的，設計關注的是将模式細節從實體解決方案提升到邏輯解決方案，從實體解決方案提升到面向業務的級别。