使用Asset数据库进行资产主数据建模

使用Asset数据库进行资产主数据建模

上一节，我们介绍了如何读写Asset数据库中的数据。本小节，我们就深入探索图数据库最独特的功能 - 关系的表达和基于图数据库的数据建模。

定义领域对象之间的关系

关系型数据库缺乏关系的直观表达

我们使用关系型数据存储、管理数据已经有几十年的时间了，但是，关系型数据库缺乏关系的直观表达方式。在最初，关系型数据库被设计成规则的表结构，这是表示实体的结构，并没有关系的直观表达方式。为了解决这个问题，关系型数据库用外键关联和连接表来表示关系。但是，连接表并不能较好的反映现实世界的特征。例如，我们生活在一个相互连接的世界中，社交网络就是一个典型的相互连接的例子。在社交网络中，只有“人”这一种对象，再就是，“朋友关系”这一种关系。如果，我们要用关系型数据库存储社交网络中的每个人和他、她相关好友的信息。那么，我们必须两张表，一张为“人”的实体表，另一张为“朋友关系”的连接表。如果，我们想查询“谁是小明和小赵共同的朋友”这种在社交网络中非常常见的查询，在关系型数据库中就会产生连接查询的噩梦。因为随着数据量的增大，连接查询的性能会成指数级的下降。

图数据库拥抱关系

在图数据库中，关系被认为和实体同等重要的一等公民，这种关系的直观表达和关系型数据库中的关系表完全是两种方式。通过定义对象的属性和相互关系，图数据库能够使我们用更加贴近现实世界的方式表达我们要处理的问题。同时，图数据库对于对象和对象之间关系的遍历有着特殊的优化。那么，上面提到的“谁是小明和小赵共同的朋友”这样的查询，在图数据库中只需要寻找一个特定对象，它的向后遍历的对象即包含小明，也包含小赵就可以了，非常的简单而直观。

Asset数据库中定义对象之间的关系

在上一节，我们用JSON描述的火车机车对象，

/locomotives/A002

拥有若干属性，如

type

，

model

等，而这些属性的值都是基本类型，如数值类型或者字符串类型等。如果某个属性的值为另一个领域对象，那么，我们就定义了对象之间的联系。

{
"uri": "/locomotives/A002",
"type": "燃气火车",
"model": "SD70ACe",
"serial_no": 450323,
"start_to_use": "2016/05/02",
"engine": "/engines/v12-1"
}

如上述JSON所示，

engine属性的值为另一个对象的URI，/engines/v12-1

，我们就在火车机车对象A002和引擎对象v12-1之间建立了联系。

数据建模

无论选用什么样的数据库（关系型数据库、文档数据库或者图数据库）管理数据，我们都需要进行数据建模。因为数据建模是一个抽象思维的过程，是从应用程序需要处理的业务逻辑和用户需求入手，然后，将这些需求映射到存储和组织数据结构中的过程。一般来说，我们可以把数据建模分成概念建模、逻辑建模和物理建模三部分。

概念建模

概念建模是从现实世界到信息世界的第一层抽象，其主要内容是理解业务逻辑，了解用户需求和使用场景，最终形成实体和实体之间的关系。我们可以使用ER图等工具进行概念建模。例如，在学生选课系统中，我们可以抽象“学生”、“课程”等实体，还有“学生选择课程”这样的关系。在概念建模阶段，我们只需要关注实体和实体间的关系，并不需要关注任何实体的属性和实现细节。可以看到概念建模的过程中，面向图数据库的思维方式和面向关系型数据库的思维方式都是一样的，目的都是确定实体本身和实体间的关系。

逻辑建模

逻辑建模是对概念建模中生成的实体和关系进一步细化的过程，是现实世界到信息世界的第二层抽象。逻辑模型既要面向用户进行设计，又要面向系统进行设计。具体来说，就是对实体进行细化，确定相应的属性字段。同时，针对不同的数据库实现方式，将实体转化成相应的对象模型。例如，在关系型数据库的设计中，我们给“学生”实体添加了“学生姓名”，“年龄”等属性，而且，为了表达“选课”这个关系，特别添加了“选课”表。而这个“选课”表，就是连接表。当我们想查找“选了课程A的学生还选了哪些课”的时候，就会用到多次的连接查询。当这三张表的数据量增大后，连接查询的性能就变得十分的低下。



而在图数据库的设计中，我们同样可以给“学生”实体添加相关的属性，同时，可以利用图数据库对于关系的直观表达，直接表示“选课”这种关系。这样，不仅使逻辑建模更加直观，不用刻意转换关系为关系表，而且图数据库对于关系的查询有特殊的优化，上述“选了课程A的学生还选了哪些课”的查询性能不会随着数据量的增加而急剧下降。

物理建模

物理建模是现实世界到信息世界的最后一层抽象，是面向计算机物理层面的模型，描述了数据在储存介质上的组织结构，它不但与具体的数据库实现有关，而且还与操作系统和硬件有关。一般来说，对于关系型数据库的物理建模而言，我们需要考虑许多因素，
每张表中不同属性的数据类型，例如，“学生”表中的id到底是int4还是bigserial。这不仅要考虑整型数值是否越界，还要考虑业务是否需要存储上十亿条学生信息。
每张表中不同属性值的约束条件。例如，“课程”表中的课程名“name”是否允许为空，等。
为了提高查询的性能，是否要添加索引，在什么属性上添加索引。
如果是自建数据库，并作为生产环境运维，那么，我们还需要考虑物理服务器的磁盘容量，是否需要固态硬盘提升读写性能，如何做备份恢复等。

而使用图数据库时，特别是Predix平台的Asset图数据库时，我们在物理建模中的绝大部分问题都极大地被简化了。
Asset图数据库默认是对象结构不敏感的。同一个收集器中对象的属性可以不一致，同一个属性的数据类型也可以不一致。就像我们前面的例子，不同对象中相同属性

serial_no

的值，有的是数值类型，有的是字符类型。
Asset图数据库对于对象属性类型也不需要特殊的限制。因为，Asset数据库中的所有对象都是通过JSON描述的，JSON本身对数值类型和字符类型是没有任何限制，并不存在整数越界或者字符太多而存不下的情况。
因为Predix平台已经帮我们管理了Asset数据库下层的物理环境，所以，我们完全不需要关心数据库所在服务器的磁盘容量，是否需要固态硬盘或者做备份恢复等操作。

综上所述，面向Asset图数据库的物理建模过程中，我们只需要定义属性的数据类型和直观的表达对象间的关系就可以了。Asset图数据库极大的简化了物理建模的复杂度和时间，使得开发人员可以更加专注在自身业务逻辑的开发上。

小结

通过本节的介绍，我们了解到，
Asset图数据库将关系认定为和实体同等重要的一等公民，拥有关系的直观表达。
只需要将对象某个属性的值赋值为另一个对象的URI就建立了对象间的关系。
面向Asset数据库数据建模的过程和面向关系型数据库建模的过程类似，也需要完成概念建模、逻辑建模和物理建模三部分。
Asset数据库极大的简化了数据建模的复杂度和时间，使得开发人员可以更加专注在自身业务逻辑的开发上。

当了解了上述信息，我们就可以非常有信心的使用Asset数据库进行数据建模并管理资产主数据了。

作者：谢品，上海创新坊首席架构师，GE数字集团

专注于工业互联网，云计算，大数据，高性能分布式存储领域，对Cloud Foundry和传统应用向云端迁移有丰富的经验，曾供职于VMware，EMC，Autodesk等知名软件公司云计算部门。