前言
当我们要构筑一个赋能基层治理的“数据平台”时，有了质量“好用”的数据，和人性化的数据交互设计就够了吗？还不够。我们还需要一个好的工程化方案来缝合两者。
用建筑工程来打比方的话，我们只是有了优质的建筑材料，以及一套逼真的效果图，但在一座壮丽建筑的背后，还有肉眼无法看到的复杂地基与内部结构，来支撑建筑对抗自然环境，适应人类行为活动。越复杂的建筑，结构难度越大；越优秀的建筑，结构设计越精妙。
同样的，在数字化工作中，我们也需要有精巧的“数据结构”来组织数据，以支撑快捷轻盈的数据交互。
但是，我们为基层治理构建的“数字城市”，其复杂度远高于物理世界的建筑。物理建筑造完后是凝固的，而我们用数据构筑出的这座“城市”不是，它是动态变化的，是“新陈代谢”的，是一个复杂、流动、立体的数据之网：
每时每刻不同来源的数据从不同渠道和部门汇入，有的由系统汇入，有的由采集汇入。每时每刻大量不同层级不同权限的用户对数据进行查询、增加、删除、修改。不仅如此，这座“数字城市”还在不断地变化和发展，逐步纳入不曾获取的数据类目，淘汰不再延续的业务类目，如同生命体不断更新细胞，生长血肉。
那么，怎样的“数据结构”才能支撑如此复杂的系统？
我们先看看业内最常用的关系型数据库。
PART.01
传统关系型数据库的局限性
传统的关系型数据库的核心是“表格”（Table），每一行数据代表一个记录。当我们需要表达某个内容，这个内容相关信息需要存放于同一张“表”中被读取。例如，假如我们想表达“居住在某楼宇属于某志愿组织的居民志愿者参与了哪些志愿活动”，就需要用类似下图所示的一张大宽表把相关属性信息都放在一行行记录里。
用“表格”将所有相关信息放在一行行记录里来表达内容
现实中，通常情况下数据是分门别类搜集和管理的。比如，楼宇数据和志愿活动信息属于两个部门管理。此外，在同一张大表上修改某一个字段信息涉及的数据量会很大，影响管理效率。因此，工作中我们一般会对表做最小化拆分。每张最小拆分的表格只管理某一类主体的某类属性信息。
当要整合多个信息来表达更加复杂的内容的时候，我们就需要找到共同信息字段作为“桥梁”来关联多个表格，比如“人的姓名”。为了方便记录和保证唯一性，我们设计了各种各样的代码来对应各类主体，比如“身份证号”、“志愿者编号”、“企业代码”等等。这样，各种主体各类属性，都可以通过若干张“关系表”串联起来。
比如，市民居住信息表可以通过“身份ID”和“楼宇编号”来关联；志愿者活动表可以通过“身份ID”和“志愿者编号”关联
城市的复杂性决定了记录各类主体信息的属性表数量不会少：居民表，党员表，企业表，居委表，组织部门表，小区表等等。主体之间的关系也错综复杂，有些关系相互独立，有些关系相互勾连，比如上下从属或者排他互斥。为了保证信息的准确、唯一和一致，部分“关系”也需要用“表格”来加以约束。要应对以上种种情况，对数据表结构的设计能力有着比较高的要求。
而在基层治理工作中，存在多个用户同时对数据进行不同层面的“查增删改”的情况。当不同基层用户都需要快速出结果，且系统中的数据还要保持整体“一致性”时候，关系型数据库的结构就会暴露出它的缺陷：
1）查询的问题：查询对象信息横跨超过两组关系时查询速度会急剧下降。
比如，想了解“住在A楼的志愿者最常参与哪个志愿组织的志愿活动？”时，需要横跨5张基础表关联，并聚合统计。依据乘法原则, 实际要操作的数据将多达每个表行数的乘积，需耗费大量时间
2）修改的问题：如果对单个属性表本身设计进行改动，修改过程中数据库不可用。如果要修改的内容涉及多个表，很难保持秒级的一致性。
比如，企业地址表的列本来包括省、市、区、园区、路弄号；但随着政府管理模式改变，街道也要加入营商服务，那么需要在地址列里加入“街道”，在数据更新过程中无法正常使用数据库
3）增加的问题：即便不对现有单个表进行修改，而是新增一个属性表，但是表的数量增加引起的关系复杂度增长是非线性增长。
比如，当增加“志愿者特长”属性表格后，每个志愿者都可以对应多个特长，关联后表格的数据行数会急剧增加
这一系列问题反映到基层用户的使用感受中，就是：数据量大时系统查询速度慢性能差，要新增一些采集字段系统就需要被关停升级，用户A改了一个数据用户B在另一个平台短时间看到的还是老样子，等等。
而这背后根本性问题，是关系型数据库的结构更适用于一个“凝固”的数字城市，一个有确定范畴的数字城市。就像造一座物理建筑，建造之前精确地设计好每一根梁和柱的位置，水泥浇筑之后它们就很难被调整，除非物理性的拆除——而房子在装修过程里，人也是不能住的。关系型数据库并不适用于一个时刻变化、生长、优化的复杂的数字城市。
如果希望关系型数据库好用，那么地址表在“施工图”里是几列最好永远是几列，人的属性也最好永远保持最初建表那几个。不要多，不要少，不要变化。
但是真实情况显然不可能这样。基层所需要的数据很难一次性全部定义清楚和收集完整。难道我们就不做一个1.0版本先让基层用户用起来吗？城市的管理层级和手势随着时代和社会的变化动态调整是很自然的事情，难道我们每次遇到这种情况都要说：需求变了，给我半个月重新开发？
我们需要更灵活的数据结构，来有效地映射变化的、复杂的城市，并与之同频共振。
我们要如何去做呢？
我们需要回归城市这个复杂巨系统的底层本质，更好地拆解它、简化它。
PART.02
城市复杂系统的本质：
“实体”与“关系”
城市是人类最复杂的造物，它不仅是建筑物、人口的集聚，同时也是生产、消费、交换的集中地。卡尔维诺在《看不见的城市》中诗意性的描绘到：“城市”像个神秘的庞然大物，人们生活在其中，它的真相却总在人们的视线之外：它是记忆的集合，也是欲望的载体，或者是其他的东西。马克思在《论费尔巴哈》中提出，人的本质不是单个人所固有的抽象物，在其现实性上，它是一切社会“关系”的总和。
从这个视角出发，我们可以把城市简化成两层：“看得见的城市”与“看不见的城市”。前者是“实体”，包括物理实物的土地、河流、道路、建筑物等等，以及社会共识下的概念：居民、企业、店铺等等；后者则是它们之间的“关系”的总和，比如：人出生于一个医院，居住于一间房屋，就业于一个企业，求学于一所高校，消费于某个商场，等等。
从哲学的范畴来看，人类社会6到19世纪的科学成就，是建立在物理世界的“实体”思维基础上，20世纪40年代以来的系统科学直至今天的信息科学技术革命则是建立在“关系”思维基础上。
因此，在数字城市的复杂系统中，我们可以通过“实体-关系”模型来描摹真实世界。在这个思路下，无论多么复杂的城市系统，都可以得以简化；无论城市在物理上如何更新，信息流动上如何交错，都不会脱离“实体-关系”的范畴：如果增加了“实体”，我们就增加一个“点”，如果发生或解除了“关系”，我们就增加或减少一条“线”——不会对原本的数字世界产生结构性的大改。
“实体-关系”模型也即是图数据库的基本结构。
PART.03
图数据库：一种更适合“城市复杂系统”的模式
用“实体”构成对对象的刻画，即“点”，用“关系”来表征对象之间的连接，即为“线”。这样我们就得到了一个非常简洁的数据结构方案。
1）实体：一切可以定义的事物或概念，都可以被定义为实体。
实体只有ID（主键）和属性（外键）两列，属性列中可以自由的增删内容，而不影响表的结构。
实体的ID主键和属性外键，属性可以有相互独立的若干个
2）关系：两个实体关联的方式，可以任意定义。
关系可以是出生于，居住于，就业于，求学于……，关系本身也可以定义ID以及属性，比如“就业了‘1年’，‘2年’，‘3年’，……”。
比如，“志愿者”“参与了”“志愿活动”，其中“参与了”的关系我们还可以进一步定义其“参与时间”、“参与地点”等等。每一种关系，都可以通过连线将不同实体关联
在图数据结构下，传统关系型数据库的几个困境便迎刃而解：
1）可以对属性列进行任意修改而不影响表结构。
比如，对属性列修改、增删而不改变整体表结构
2）可以从旧实体的属性分裂新实体而不影响旧实体的结构。
比如，增加志愿者的技能特长信息，只需要创建一组技能特长实体，用“擅长”关系进行连接即可
比如，市民的志愿者身份，既可以通过“注册在”“某志愿者组织”表达，也可以分裂出“有”“志愿者身份”表达。当要改变志愿者身份类别时，修改该实体并改变连线关系即可；而关系型数据库修改时则会导致数据库不可用
3）可以在我们逐步掌握更多信息时做便捷的增加。
比如，前文企业地址的例子，图数据结构中地址可以被描述成一组管理边界实体通过层层“从属”的关系连接；当增加“街道”实体时，并不需要改动现有节点，增加一个节点和调整几条连线即可
4）此外，这个结构的查询速度非常快。
关系型数据库的内容是关联多个表格计算出来的，关联数据量可以达到行数的N次方；而图数据库的内容是通过连线读出来的，按照节点顺着路径查询即可。因此，关联越多越复杂，图数据的查询速度相对更快。比如当关系的深度达到5级，图数据库可以秒读，而关系型数据库则时常陷入无尽的等待中。
数据来源：https://zhuanlan.zhihu.com/p/505939537
这样我们就构建了一个可以真实“映射”复杂城市系统，并且真正“可生长，可叠加”的数据结构。
真实城市中各类要素之间不断变化、生长、迭代的错综复杂的“实体-关系”数据网络
最后的话
为什么好的数据结构会这么重要？
有一个好的数据结构，才能使城市庞大的、繁杂的多源数据在多个基层用户使用过程中也能够及时更新，敏捷响应。当基层工作者要在数十万的人口基数中寻找服务对象时，再也不用被无数个表格所淹没，而是通过几个标签叠加，几秒钟找到目标对象。
有一个好的数据结构，才能使建“数字城市”这个复杂的系统，可以先从最容易获取的房屋、人口等基础信息为起点，后期再逐步添砖加瓦。当基层工作者有迫切需求时，我们的系统能够以最轻量化的模式和最快的速度落地。
有一个好的数据结构，才能使“数字城市”和真实世界一样保持动态变化，同频共振。将复杂的不确定性解耦成一个个小的确定性的模块，来灵活应对千变万化的管理服务背后千变万化的数据需求。
这样，基层工作者才能真正持续、稳定地“用好”“好用”的数据，得到数据的赋能，在现实世界中去沟通，去服务，去创造更多价值。
这才是我们需要的“数据结构”。
有商业合作需求，欢迎联系我们
请备注：基层治理平台
↓添加企业微信↓
ABOUT US
上海脉策数据科技有限公司（简称脉策科技）成立于2015年，是国内数据智能领域中具有引领性的科技公司、高新技术企业、市区两级“专精特新”企业、杨浦区小巨人，上海市经信委下属的大数据创新企业成员。致力于城市数字化领域，结合智库能力和数据科技，基于自主研发自主产权的低代码数据系统开发平台和领域算法，叠加行业认知和数据服务，提供多样化综合解决方案能力。主要业务是为政府和大型企业提供智库咨询、数据研究、算法服务、平台产品及系统解决方案。