「数据架构」全级别数据模式建模，宇宙最全面

使用关注点导航数据体系结构

是我们重新构建模式、数据模型和数据架构的独特机会。我们确实需要做一些更好的事情。

现实世界充满了忧虑，其中有些或多或少是矛盾的。一个很好的例子是模式（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方法吗？是的，设计关注的是将模式细节从物理解决方案提升到逻辑解决方案，从物理解决方案提升到面向业务的级别。

处理复杂性和矛盾

即将发布的属性图模式标准（property graph schema standard）既复杂又有许多相互矛盾的问题，我选择它作为演示全面架构思想最重要部分的替罪羊。从两个硬维度（治理和交付风格）的四个象限开始的全尺寸数据架构元框架，是一个很好的架构框架，甚至是一种模式语言，可以在许多不同的上下文和开发风格中使用。

谢谢大家关注，转发，点赞和点在看。