技术领域
本发明涉及数据挖掘领域，尤其涉及一种通用的数据库图形化分析系统。
背景技术：
关系数据库产生于上世纪七十年代，它出现以后迅速占领了市场，淘汰了旧的数据库。今天，全世界的主流数据库产品都是关系数据库，绝大多数企业和政府部门的绝大多数结构化数据都是以关系数据库的形式存储的。
关系数据库之所以大获成功，在于它有一个坚实的理论基础，这就是ER模型(实体关系模型)和关系代数。当然它也存在需要继续完善的地方。
关系数据库的核心是实体关系模型，每个数据库都是围绕着“实体”和“关系”这两种对象建立的。所谓实体，就是人员、企业、宾馆、航班等等；所谓关系，就是两个实体之间的关系，诸如什么人在什么企业上班，什么人入住什么宾馆，什么人乘坐什么航班之类。每个数据库都是由不同的数据库工程师手工建立的。这样就会产生一个问题：每个数据库的本质都是一样的，都是人员、企业、宾馆、航班等实体以及它们之间的关系；但是，每个数据库又不完全一样，因为人手工做的东西肯定会有差异。所以，每个数据库在理论上是一致的，在实际上又是不一致的。这样，不同数据库之间的数据就很难交流，很难放到一起来比对，这是关系数据库的第1个问题。
关系数据库里面一般来说只会保存最基本的关系，比如：张三在A公司上班，A公司的地点在杭州。那么，数据库里就只会保存“张三在A公司上班”和“A公司的地点在杭州”这两个最基本的关系，不会保存“张三的工作地点在杭州”这样的关系，因为这个关系可以由两个基本关系推导出来，这就叫关系代数，或者关系运算。从理论上讲这样做是正确的，因为这样可以消除重复、消除歧义、减少存储空间、优化数据库结构。如果要想得到“张三的工作地点在哪里？”这类问题的答案，使用SQL语言(结构化查询语言，关系数据库的标准语言)推导一下，也就是说进行一下关系运算就可以了。但是，业务人员既不会使用SQL语言，也不会进行关系运算，只有专业的数据库工程师才会。而且，对于那些复杂的关系，往往要关联十几张表才能得到，这样的工作即便对于数据库工程师也是非常费时费力的。业务人员不会关系运算，这就是关系数据库的第2个问题。
关系数据库不仅具有关系运算功能，同时也具有包括统计分析在内的数学运算功能。业务人员同样也不掌握数学运算功能。一般是由数据库工程师代为查询，或者由程序员写好固定的统计分析的前台界面，系统运行以后业务人员就只能使用这几个固定的界面。这种方法对于结构比较简单、比较固定的数据库是可行的，但对于结构复杂并且经常有新的数据表导入的数据库来说则是不可行的，因为几个固定的界面是不可能实现所有的统计分析运算的。这是关系数据库的第3个问题。
数据库工程师在建立关系数据库之前要进行设计，设计工作包括画一张ER图(实体关系图)。ER图能简单明了、形象直观地反映出该数据库中的主要实体以及它们之间的关系。因为人类的大脑与计算机正好相反，计算机处理文字的速度比处理图像要快，而人类大脑处理图像比处理文字要快。但是，ER图只是保存在设计草稿中，数据库在建立完毕以后，数据库里并没有这样一张图。这对于数据库工程师来说问题不大，因为他们经过专业的训练，对数据库很熟悉，所以他们的脑海里会有一张ER图。而对于业务人员来说问题就大了：他们不熟悉数据库，脑子里根本没有ER图，所以他们很难理解数据库里有哪些对象，其关系是什么。即便给他们一张ER图也不能解决问题，因为这张图是静态的，不能随着数据库结构的变化而变化；而且ER图的符号也不够直观、丰富、生动，业务人员理解起来还是有难度。所以，缺乏图形化的展现方式，业务人员难以理解，这就是关系数据库的第4个问题。
关系数据库的第5个问题、同时也是它的最严重的问题在于：关系数据库的核心是ER模型，ER模型说明：世界是由实体组成的，实体之间存在关系，但却没说明实体是什么，关系是什么。这样，每个数据库在建立时，都要从头建立一套实体以及它们之间的关系。也就是说，每个数据库都是零散的、肤浅的。
打个比方，ER模型告诉我们：这座楼房是用砖头和水泥搭建的。砖头和水泥只是组成的楼房的最基本的组件，至于说这座楼房的整体结构是什么样的，ER模型没说，我们也不知道。或许有人会反驳：每座楼房的结构都不同，不可能把所有楼房的结构都列举出来。实际上不是这样。楼房的结构千变万化，但总有其内在的统一的规律。比如：所有楼房的结构都是三维的。这个规律就很基本很重要。但是很遗憾，ER模型不包含这个规律。
所以说，关系数据库理论告诉我们世界是由实体和关系组成的，但却没说是由哪些实体和哪些关系组成的，以及如何组成这个世界的，连一些最基本的规律都没有。前面提到的4个问题都是表象，这第5个问题才是关系数据库的所有问题的核心和本质。
总之，一方面关系数据库是一种成功的数据库，目前绝大多数企业和政府部门的结构化数据都存放在关系数据库中；另一方面关系数据库又存在很大的不足，表现在：第一，不同的数据库难以放到一起进行对比；第二，业务人员不掌握关系运算和数学运算功能，难以实现灵活的关联查询和统计分析；第三，缺乏图形化的展现方式，业务人员难以理解。关系数据库的所有问题的本质在于：关系数据库仅仅说明了世界是由实体和关系组成的，但却没说明是由哪些实体和哪些关系组成的，以及组成世界的基本规律是什么。
技术实现要素：
本发明的目的是提供一种通用图形化分析系统，以解决关系数据库存在的缺乏图形化显示和分析界面和不包含实体和关系如何组成世界的基本规律这两方面问题的不足。
本发明的目的是通过以下技术方案来实现：
一种通用图形化分析系统，包括数据层、RIA中间件层和Web界面层，所述数据层包括一个核心数据库以及一些业务数据库，核心数据库是本发明自带的数据库，业务数据库是企业或政府部门原有的数据库；核心数据库设有一个数据接口；所述RIA中间件层包括关系网查询界面和三维数据立方界面两种图形化界面，三维数据立方界面设有三维全显显示界面和二维切片显示界面，所述Web界面层是图形化的浏览器界面；
所述核心数据库的数据结构既表现为核心表结构，又表现为核心网络结构，所述核心网络的基础是一个三维的网络，三维包括时间维、集合维和客体维，时间维有先、后两个方向，先为负，后为正、集合维有下、上两个方向，下为负，上为正、客体维有左、右两个方向，左为负，右为正，所述时间维的正方向与集合维的正方向的乘积左旋就是客体维的左方向，乘积右旋就是客体维的右方向，所述核心网络的核心是人。所述时间维是三维的基础，任何实体、任何关系，都显式或隐式地蕴含着时间。时间维反映的是实体以及实体内各节点的先后关系，或者说序列关系。所述集合维是建立在时间维的基础之上的，是垂直于时间维的。集合维反映的是实体之间的集合关系，或者说从属关系。所述客体维是建立在时间维和集合维基础之上的，是垂直于时间维和集合维的。客体维是对同一时间、同一集合的实体的进一步区分。
在不同的业务数据库中的不同的业务表里，会有关于同一个实体的多条记录。当这些业务表融合到核心表里以后，关于这同一个实体的多条记录就变成核心网络的多个节点。每个节点都有三维坐标，把每个节点都描绘出来，就能得到这个实体在三维网络中的立体图形。如果把两个以上的实体都描绘出来，就会看到这些实体之间可能会存在的相交、相切、相离、包含等立体关系。
表，是关系数据库中的数据的存储方式，所述核心数据库的表包括控制表、临时表、转换表、核心表和统计表，所述控制表包括组表、用户表、用户组表、实体权限表和日志表；组表包括组编号、组名；用户表包括用户编号、用户名、密码。用户组表包括组编号和用户编号；实体权限表包括实体编号和用户编号。日志表包括日志编号、日志时间、日志内容；控制表主要是控制用户对核心数据库的访问。通过两种方式来控制：一种是通过用户组表实现按组对用户进行授权，这种权限比较广泛，涵盖了用户对核心数据库所作的所有操作；一种是通过实体权限表实现按实体对用户进行授权，这种权限比较精细，可以精确到每一个实体。
所述临时表的表结构与业务数据库的业务表的表结构完全一致，它里面存放的数据就是从业务表导入的数据。如果业务表发生变动，临时表也要随之修改。临时表的数据结构(即表个数和字段个数)在运行时是可以变化的，其它表的数据结构在运行时是不变的。
所述转换表只有一张表，存放的是临时表各个表的各个字段与核心表各个表的各个字段的对应关系，用于把临时表的数据导入到核心表中；以及核心表各表的字段与统计表各表的字段的对应关系，用于把核心表的数据导入到统计表中。
所述核心表主要包括连线种类表、连线表、节点表、图片表、实体表、实体自指表和实体数值表，其中连线种类表存放的是数量有限的连线种类及其图形表示方式，连线种类包括“上级”、“下级”、“以后”、“朋友”、“同事”等，图形表示方式包括线型、箭头、颜色等；图片表存放的是图片的编号、名称、地址以及图片本身，图片表用于实体节点的图形化显示。实体表存放的是实体编号、名称、图片编号、缺省图片编号等；实体的图片编号是指每个实体有一张图片的情况，比如人员的照片；如果该实体本身的图片找不到，就使用缺省图片编号，比如人员照片找不到，可以用一张卡通图片来代替。实体自指表包括实体编号、自指名、自指值；实体自指表是指每个实体可能有多种自指方式，比如“张三”这个姓名、张三的身份证号、张三的手机号都是张三这个实体的自指。如果临时表中出现张三的身份证号，那么可以认为它代表的就是张三这个实体。实体数值表包括实体编号、数值名、数值值；实体数值表是指实体的数值属性，比如张三的体重，张三的收入等，这些属性不能与其它实体关联起来，所以需要存在实体数值表中；节点表包括节点编号和实体编号，多个节点可以对应一个实体。连线表包括源节点编号、目的节点编号、节点种类编号，它的任务是把源节点和目的节点连接起来，并能够图形显示。
所述统计表主要包括时间维表、集合维表、客体维表、立方表和立方数据表。时间维表、集合维表、客体维表包括编号和名称2个字段，它们是从核心表综合归纳得到的三张维表。立方表包括立方编号、统计值编号、统计值名称3个字段，它记录了每一次统计得到的数据立方，以及这个立方的统计值是什么，比如销售额、失业人数等等。立方数据表包括立方编号、实体编号、时间维编号、集合维编号、客体维编号、统计值1、统计值2、统计值3等字段；立方数据表存储的是每个立方的具体的三维坐标以及统计值。
所述三维数据立方的三维全显界面中，除了节点和连线这两种基本元素以外，还显示了时间维、集合维、客体维这三个维度，这样就能表示出每个实体的各个时期，以及实体的上下级、实体的客体；工具面板增加了3个功能：绕时间维旋转、绕集合维旋转、绕客体维旋转，它们的功能是使整个图形界面绕不同的轴旋转；右键菜单增加了3个功能：节点时间维切片、节点集合维切片、节点客体维切片，它们的功能是在某个节点上按照与某个维垂直的方向进行切片，得到二维切片界面。
所述二维切片显示界面中，只有两个维度，工具面板中只有一个旋转功能，就是绕切片中不显示的那个维进行旋转，右键菜单中没有切片功能，而是变成返回三维视图的功能。
所述关系网查询界面的规则是：主要的界面元素是节点和连线，节点代表实体，连线代表关系。不同的节点用它们各自的照片来表示，如果没有照片，就用缺省图标来表示。不同的连线用不同的颜色、线型、箭头来表示。节点上显示该实体的名称，连线上显示该关系的名称。其它的界面元素有：工具面板、工具提示、右键菜单；工具面板是针对界面的整体操作面板，与具体的节点无关，它包括界面显示比例缩放条和鼠标移选选项。工具提示是指鼠标放在某个节点上时，会显示出该节点的更多信息。右键菜单是在某个节点上点击右键时弹出的针对此节点的功能菜单，包括删除节点、深入查找此节点等功能。
所述Web界面层是图形化的浏览器界面，而RIA中间件层是进一步强化浏览器的图形处理功能的插件，对于较简单的DDL、DML、DCL语言，直接用Web界面层包装一下就可以了，对于复杂的DQL语言，必须通过RIA中间件层和Web界面层的两层包装，SQL语言的DDL语言经过包装，变成图形化的数据定义模块；DML语言经过包装，变成图形化的数据操纵模块；DCL语言经过包装，变成图形化的数据控制模块；DQL语言经过包装，变成图形化的数据查询模块。
本发明的有益效果为：通用图形化分析系统是专为业务人员开发的一种简单方便、快捷高效的数据分析和挖掘工具，它能有效地弥补关系数据库的不足，提高现有数据的利用率，提高业务人员工作效率，使之能够快速地理解、掌握数据库中的数据，从中挖掘出宝贵的知识。
附图说明
图1为本发明发明实施例所述通用图形化分析系统的总体架构示意图。
具体实施方式
如图1所示，本发明所述的一种通用图形化分析系统，包括数据层、RIA中间件层和Web界面层，所述数据层包括一个核心数据库以及一些业务数据库，核心数据库是本发明自带的数据库，业务数据库是企业或政府部门原有的数据库；核心数据库设有一个数据接口；所述RIA中间件层包括关系网查询界面和三维数据立方界面两种图形化界面，三维数据立方界面设有三维全显显示界面和二维切片显示界面，所述Web界面层是图形化的浏览器界面；
所述核心数据库的数据结构既表现为核心表结构，又表现为核心网络结构，所述核心网络的基础是一个三维的网络，三维包括时间维、集合维和客体维，时间维有先、后两个方向，先为负，后为正、集合维有下、上两个方向，下为负，上为正、客体维有左、右两个方向，左为负，右为正，所述时间维的正方向与集合维的正方向的乘积左旋就是客体维的左方向，乘积右旋就是客体维的右方向，所述核心网络的核心是人。所述时间维是三维的基础，任何实体、任何关系，都显式或隐式地蕴含着时间。时间维反映的是实体以及实体内各节点的先后关系，或者说序列关系。所述集合维是建立在时间维的基础之上的，是垂直于时间维的。集合维反映的是实体之间的集合关系，或者说从属关系。所述客体维是建立在时间维和集合维基础之上的，是垂直于时间维和集合维的。客体维是对同一时间、同一集合的实体的进一步区分。
在不同的业务数据库中的不同的业务表里，会有关于同一个实体的多条记录。当这些业务表融合到核心表里以后，关于这同一个实体的多条记录就变成核心网络的多个节点。每个节点都有三维坐标，把每个节点都描绘出来，就能得到这个实体在三维网络中的立体图形。如果把两个以上的实体都描绘出来，就会看到这些实体之间可能会存在的相交、相切、相离、包含等立体关系。
表，是关系数据库中的数据的存储方式，所述核心数据库的表包括控制表、临时表、转换表、核心表和统计表，所述控制表包括组表、用户表、用户组表、实体权限表和日志表。组表包括组编号、组名。用户表包括用户编号、用户名、密码。用户组表包括组编号和用户编号。实体权限表包括实体编号和用户编号。日志表包括日志编号、日志时间、日志内容。控制表主要是控制用户对核心数据库的访问。通过两种方式来控制：一种是通过用户组表实现按组对用户进行授权，这种权限比较广泛，涵盖了用户对核心数据库所作的所有操作；一种是通过实体权限表实现按实体对用户进行授权，这种权限比较精细，可以精确到每一个实体。
所述临时表的表结构与业务数据库的业务表的表结构完全一致，它里面存放的数据就是从业务表导入的数据。如果业务表发生变动，临时表也要随之修改。临时表的数据结构(即表个数和字段个数)在运行时是可以变化的，其它表的数据结构在运行时是不变的。
所述转换表只有一张表，存放的是临时表各个表的各个字段与核心表各个表的各个字段的对应关系，用于把临时表的数据导入到核心表中；以及核心表各表的字段与统计表各表的字段的对应关系，用于把核心表的数据导入到统计表中。
所述核心表主要包括连线种类表、连线表、节点表、图片表、实体表、实体自指表和实体数值表，其中连线种类表存放的是数量有限的连线种类及其图形表示方式，连线种类包括“上级”、“下级”、“以后”、“朋友”、“同事”等，图形表示方式包括线型、箭头、颜色等。图片表存放的是图片的编号、名称、地址以及图片本身，图片表用于实体节点的图形化显示。实体表存放的是实体编号、名称、图片编号、缺省图片编号等。实体的图片编号是指每个实体有一张图片的情况，比如人员的照片。如果该实体本身的图片找不到，就使用缺省图片编号，比如人员照片找不到，可以用一张卡通图片来代替。实体自指表包括实体编号、自指名、自指值。实体自指表是指每个实体可能有多种自指方式，比如“张三”这个姓名、张三的身份证号、张三的手机号都是张三这个实体的自指。如果临时表中出现张三的身份证号，那么可以认为它代表的就是张三这个实体。实体数值表包括实体编号、数值名、数值值。实体数值表是指实体的数值属性，比如张三的体重，张三的收入等，这些属性不能与其它实体关联起来，所以需要存在实体数值表中。节点表包括节点编号和实体编号，多个节点可以对应一个实体。连线表包括源节点编号、目的节点编号、节点种类编号，它的任务是把源节点和目的节点连接起来，并能够图形显示。
所述统计表主要包括时间维表、集合维表、客体维表、立方表和立方数据表。时间维表、集合维表、客体维表包括编号和名称2个字段，它们是从核心表综合归纳得到的三张维表。立方表包括立方编号、统计值编号、统计值名称3个字段，它记录了每一次统计得到的数据立方，以及这个立方的统计值是什么，比如销售额、失业人数等等。立方数据表包括立方编号、实体编号、时间维编号、集合维编号、客体维编号、统计值1、统计值2、统计值3等字段。立方数据表存储的是每个立方的具体的三维坐标以及统计值。
所述三维数据立方的三维全显界面中，除了节点和连线这两种基本元素以外，还显示了时间维、集合维、客体维这三个维度，这样就能表示出每个实体的各个时期，以及实体的上下级、实体的客体。工具面板增加了3个功能：绕时间维旋转、绕集合维旋转、绕客体维旋转，它们的功能是使整个图形界面绕不同的轴旋转。右键菜单增加了3个功能：节点时间维切片、节点集合维切片、节点客体维切片，它们的功能是在某个节点上按照与某个维垂直的方向进行切片，得到二维切片界面。
所述二维切片显示界面中，只有两个维度，工具面板中只有一个旋转功能，就是绕切片中不显示的那个维进行旋转。右键菜单中没有切片功能，而是变成返回三维视图的功能。
所述关系网查询界面的规则是：主要的界面元素是节点和连线，节点代表实体，连线代表关系。不同的节点用它们各自的照片来表示，如果没有照片，就用缺省图标来表示。不同的连线用不同的颜色、线型、箭头来表示。节点上显示该实体的名称，连线上显示该关系的名称。其它的界面元素有：工具面板、工具提示、右键菜单。工具面板是针对界面的整体操作面板，与具体的节点无关，它包括界面显示比例缩放条和鼠标移选选项。工具提示是指鼠标放在某个节点上时，会显示出该节点的更多信息。右键菜单是在某个节点上点击右键时弹出的针对此节点的功能菜单，包括删除节点、深入查找此节点等功能。
所述Web界面层是图形化的浏览器界面，而RIA中间件层是进一步强化浏览器的图形处理功能的插件，对于较简单的DDL、DML、DCL语言，直接用Web界面层包装一下就可以了，对于复杂的DQL语言，必须通过RIA中间件层和Web界面层的两层包装，SQL语言的DDL语言经过包装，变成图形化的数据定义模块；DML语言经过包装，变成图形化的数据操纵模块；DCL语言经过包装，变成图形化的数据控制模块；DQL语言经过包装，变成图形化的数据查询模块。
以个人为中心，所有实体可以分为以下几类：
a)个人在不同时期的截面：2008年的个人、2009年的个人、2010年的个人。它们不是实体而是实体沿时间维分布的一系列节点。
b)个人的指代标志：姓名、身份证号、护照号、手机号、QQ号、银行账号。这些标志代表个人本人。
c)个人所拥有的财产：房产、汽车、存款、现金、债务、物品。个人是这些财产的上级。
d)个人所属的集合：省、市、县、公司、人群(诸如失业人群、QQ群等)。
个人是这些集合的下级。
e)个人的亲属及社会关系：父母、子女、妻子、丈夫、老板、员工、同事、朋友、同乡。他们是与个人相对应的客体，是另外的个人。
可见，关系数据库的所有实体和关系都可以归类为个人的标志和个人在三维上的投影。这就是所有业务表都可以导入到核心网络的依据。
至此，我们就找到了第二个问题的答案。组成世界的主要实体是：人、象人的实体、在人的基础上构建的实体。比如：人、公司、政府这些都是组成世界的实体。而身份证号、资金、汽车等等则不是组成世界的主要实体，它们只是人的标志、人的财产、人的附庸。对于科学工作者来说，动物、植物、星球往往是他们关注的主要实体，动物、植物、星球不是人，但在科学工作者眼中，它们是象人一样的实体，它们也有名字、有性格、有生老病死。
组成世界的主要关系是：时间维、集合维、客体维这三个大维以及其包含的小维。一种维其实就是一种关系。三个大维囊括了实体之间可能存在的所有关系。比如，张三父亲与张三的关系是先后关系，可以在时间维上表示；张三与A公司是从属关系，可以在集合维上表示；张三与同事李四是客体关系，可以在客体维上表示。除了三大维以外还有一个非常特殊的关系，就是自指关系。“张三”这个名字与张三这个人之间是自指关系，张三的身份证号与张三这个人之间也是自指关系。自指关系不是实体与实体之间的关系，而是实体与实体本身的关系。
明白了两个问题的答案以后，就可以据此建立核心数据库，把业务数据库的业务表导入到核心数据库的临时表，再把临时表导入到核心表。由于核心表的数据结构是固定的，无非是一个以人为核心的三维网络，所以，针对核心表的数据查询模块也是固定的。也就是说，只要针对核心表开发一套图形化显示界面，它就能显示从各业务表导入的任何数据，而不需作任何修改。
还有一个新问题：以人为核心的三维网络，如何与图形化显示界面相结合。
网络是由节点和连线组成的。连线的种类是有限的，无非就是“向上”、“向下”、“向后”、“朋友”、“同事”这几种。建一张连线种类表，给每种连线设置一种线型、箭头、颜色，就能图形化显示了。
至于节点的显示，应该在核心数据库中建一张图片表，图片表里可以存储二进制图片文件，也可以只存储图片在文件系统中的存放位置。每个实体引用相应的图片，而每个节点又是属于相应的实体，这样节点就可以用它所属的实体图片来表示。
这样，本发明就综合解决了关系数据库的缺乏图形化显示、分析界面和缺乏客观世界的组成规律这一表一里两方面问题，以及它们衔接的问题。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。