物联网的图模型
所谓“物联网”是指规模巨大的设备，传感器将实现联网，通过这些联网设备来收集数据，存储和分析，并且和人员，应用软件产生的数据相互关联，实现处理复杂的事件的最优化。基于更快地使用更多数据来提供比以前更好的结果。
以滴滴打车为例，它是通过收集、整理、存储和处理来自运行其应用程序的大量智能手机的数据而实现的“智能服务”。 这些手机充当物联网设备，可以感知客户和出租车司机的位置，并与交通流量、天气和其他活动的数据混合在一起。提供了比传统的出租车呼叫中心更佳的客户服务。
摩根士丹利最近预测，在未来五年内，全球将有大约 750 亿台联网设备投入使用。这个数字正在迅速接近人脑中估计的860亿个神经元。正如人类智能不是由我们大脑中的神经元数量产生的，而是由它们之间 100 万亿个左右的连接产生的一样，物联网的价值主要体现在这些设备的连接关系和交互。
我们以一个学校的建筑管理系统为例，一个学校有教学楼，科研楼，学生宿舍，图书馆，食堂等许多的建筑。这些建筑中有许多的楼层和房间，在这些房间中有空调，灯具和教学实验仪器。为了实现建筑自动化管理和能耗管理，学校会在许多的地方安装计量电表，遥控开关，以及温度，照度传感器。这是一个十分复杂的物理设备网络。与此同时，从学校的行政管理的角度看，某一个大楼，或者实验室，宿舍又可能属于某一个系，某个班级，甚至某一个项目组，或者学生社团。
当我们着手来构建一个大学的建筑自动化能耗系统时，我们通常会在白板上画出物理设备和建筑物的隶属关系和网络连接方式。这是相对比较直观和简单的。进一步地，我们要搞清楚设备以及教室与学校部门，学生，教师之间的隶属关系。于是，如果我们将设备，部门，学生，教师都抽象称为一个圆圈（我们称为节点node）。而将两个圆圈之间如果有直接的隶属关系，就会发现，学校的建筑自动化、能耗管理物联网变成了一个有圆圈和直线构成的图。节点之间的关系在构建物联网过程中非常重要。
另一方面，物联网将会产生大量的实时数据。它们之间是存在相互关系的。我们称数据之间的相互关系为“数据脉络”（data context，我喜欢这个中文术语！），当物联网中产生的数据存储在抽象的图节点中（下面我们指出，这些数据称为该节点的属性Property）。图能够充分地反映数据的脉络。
你可以自己去分析各自物联网，能够发现最后都能够抽象成为一张类似与上面的图。所以我们可以认为物联网就是一个图。如果我们采用图模型来构建物联网架构，存储，分析数据，实现设备交互，能使物联网的逻辑结构更加清晰。并且带来如下好处。
反映应用场景的数据脉络，适合数据分析和各种基于图论的算法。
数据查询的效率要比普通数据表的方式更高。
在普通的数据库中，如果数据是巨量的，那么查询的时间会越来糟糕。而图模型中，往往是通过链接关系，查询关联数据，所以它的查询数据的时间基本是恒定的。
系统设计更加符合设计师的思维过程
根据应用场景中各种设备之间的逻辑关系构建，更新数据模型。使系统设计更符合基于模型的设计方式。事实上，人们称图数据模型是一种“白板友好”的模型。也就是说，它直接反映的设计师在白板上画的结构图。大大提高了系统设计的效率。
有助于实现物联网的标准化
至少到目前为止，物联网应用的标准化工作进展缓慢。
图模型的几个要素
节点（Nodes）
关系（Relationship）
属性（Property）可以定义在节点和关系上
标签（Label） 代表节点的类别。
图数据库（neo4J）
图数据库是图模型数据的数据库。它的数据建立，查询和修改都是以图的形式进行的。所以，要建立图模型的物联网需要使用图数据库。neo4j是目前最流行的开源图数据库。
neo4j 的架构如下图所示：
从上图可见，数据库的管理，开发，应用程序接口，数据分析和商业使用都是基于图的。其内部的存储格式和算法也是面向图模型优化的。
图数据库与普通关系数据库的区别
普通的数据库大多数是所谓关系数据库（relation database），为什么不能用关系数据库来存储”关系“呢？其中关系数据库中的数据是通过大量的数据表格来存储数据，每个数据表中都有主键和外键。关系数据库通过主键-外键来建立数据之间的关系。
当主键和外键是一对多关系时，当模型中出现多对多关系时，必须引入一个JOIN表（或关联实体表）来保存两个参与表的外键，进一步增加了join操作成本。下图显示了通过创建一个 Person-Department 连接表将一个人（来自 Person 表）连接到一个部门（在 Department 表中）的概念，该连接表在一列中包含人的 ID 和在列中包含相关部门的 ID。
正如您可能看到的那样，这使得理解连接非常麻烦，因为您必须知道人员 ID 和部门 ID 值（执行额外的查找以找到它们）才能知道哪个人连接到哪个部门。通常通过对数据进行非规范化以减少必要的连接数量来解决这些类型的成本高昂的连接操作，从而破坏关系数据库的数据完整性。
可以试想，如果数据的关系很复杂，数据非常巨大时，这种基于表格的关系表的查询是非常耗费计算时间和内存的。因此，图数据库的专家戏称关系数据库是”逆关系“的。”没关系“的。
图模型的建模方法
图模型另一个重要的特点是可以实现面向对象的模型设计。实际上，在工业自动控制中 的OPC UA 协议中的信息模型同样采用了图形的模型来描述程序设计中的对象。
比如一个传输系统中有两个电机。每个电机有转速，功率两个参数。
那么我们可以定义两个节点 -传输带和电机，电机节点中带有两个属性 转速和功率。
节点的粒度
在实际建模过程中，我们可以在节点中定义许多的属性，也可以将节点分解成功更小的节点构建而成。具有许多属性的节点可能会造成数据的冗余。所以我们应该可能地将节点的存储颗粒分解的很细。这样表现力更强，支持更复杂的查询。
在OPC UA 的信息标准中，有8种类型的节点
对象节点
变量节点
方法节点
视图节点
对象类型节点
引用类型节点
变量类型节点
数据类型节点
一个对象使用一个节点来表示，如果该对象中拥有两个变量，那么就建立两个变量对象，然后对象节点和这两个变量类型节点之间建立了引用关系（reference relationship）。同样地，如果在一个对象中引用另一个对象，就需要定义被引用的对象，并与其建立引用关系。
OPC UA 的信息模型的节点粒度是非常高的。
参考OPC UA 的信息模型
我认为，在物联网系统建模时，可以参照OPC UA 的信息模型。一方面，OPC UA 信息模型基于面向对象程序设计概念，具有很强的物理设备建模能力，另一方面，OPC UA 已经提出了许多年，大量工业软件都支持OPC UA 协议。并且为许多物理设备建立了OPC UA 信息模块。在构建物联网信息模型是我们可以使用OPC UA 协议丰富的技术和模型经验。同时，也促进物联网技术的标准化。
事实上，我们完全可以将物联网看作一个巨大的OPC UA 服务器。而各种应用软件成为OPC UA 的Client 访问这个巨大的物联网。在这个巨大的物联网OPC UA 服务器内部采用图数据库建立巨大的OPC UA 信息模型。个人觉得这是一个大胆的想法。能够解决物联网标准缺失的问题。
利用neo4j建立OPC UA 的数据模型
neo4j 节点中，没有节点类型的属性，不过，标签起到了节点类型的作用。我们可以通过标签来区分不同的节点。
下面是一个例子，其中黄色的节点是对象类型，红色的类型是变量类型。REF 是节点之间的关系。我们建立了一个水泵的节点，它具有两个对象类型的属性，分别是位置（location） 和电机（motor1），对象location节点具有两个变量节点（variable node），它们是latitude和longitude。而电机具有两个变量节点（variable node），它们是speed和power。
这些节点通过引用关系REF 连接。
neo4j 的操作
节点的属性
基础属性（Basic property）
所有节点的都具有的属性。
名称 name
显示名称 dispayname
描述 Description
变量节点附加属性 （Variable）
value 值
dataType 数据类型
accessLevel
userAccessLevel
dataPointer 时间序列数据库指针
方法（Method）节点的附加属性
argument 方法的参数
实例
下面我们通过一个实例来研究数据模型的描述方式。在这里我们定义的一个水泵，水泵的特征包括位置，电机。而位置又包括了经纬度。电机包括转速和功率。
1 建立一个对象（pump）
2 建立motor和location 对象节点，
3 建立 pump-REF-motor和pump-REF-location 的关系
4 建立变量节点 speed，power，longitude，latitude 四个变量节点
5 建立 motor1-REF-speed，motor1-REF-power ，locattion-REF-longitude，location-REF-latitude 四个关系。
于是形成了的图如下：
访问数据库的常用方法
neo4j 图数据库使用一种查询语言Cypher （Cypher Query Language CQL）来操控数据库。Cypher 使我们更容易地操控图数据库。
例如：建立两个节点 罗密欧 和朱丽叶（Person node），它们之间的关系（LOVES）是罗密欧爱朱丽叶。
CREATE （remeo:Person {name："Remeo"})-[:LOVEE]->(juliet:Person(name:Juliet})
下面我们来建立水泵的图模型，它具有树形图结构
pump
motor
speed
power
location
longitude
latitude
1 获取 pump1 的所有子节点
MATCH (:object {name: 'pump1'})-[REF]-(p)
RETURN p
2 获取 motor 的所有子节点
MATCH (:object {name: 'motor1'})-[REF]-(p)
RETURN p
3 获取location 的所有子节点
MATCH (:object {name: 'location'})-[REF]-(p)
RETURN p
4 如果节点的label 是variable 就不再有进一步的子节点。
数据模型的构建工具
开发一种基于图模型的构建工具十分重要，它既要考虑构建的效率，有要考虑使用者的习惯和方便。大致有下面几种方式
树形目录结构。
图方式
文本方式（XML，JSON，CSV）
结束语
本文探讨图数据在物联网中应用的可能性，并且提出了使用OPC UA 信息模型来构建物联网信息模型，解决物联网标准缺失的问题。作者本人正在构建一个实验性小系统。感兴趣的读者可以一起交流。
————————————————
版权声明：本文为CSDN博主「姚家湾」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/yaojiawan/article/details/117630460
标签：数据库,节点,OPC,联网,UA,模型 来源： https://blog.csdn.net/Rust168/article/details/117735754
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。