1.业务语义层数据查询引擎方案设计第二期的建设内容，也会尽量继承第一期的基础设计和复用底层组件服务。
这里对特性和专属的设计做专项描述。
1.1.基于数据架构资产开发的业务语义层数据查询引擎技术方案1.1.1.数据架构资产开发的特点数据架构模型基于B/S的多层Web应用，采用Mysql/Oracle数据库和JSP、Spring、Hibernate、AJAX技术，利用MVC设计模式将表示层和逻辑层分离。
后台使用Mysql/Oracle进行数据库开发，并利用Hibernate技术完成对数据库的封装映射。
可配置多套物理表方案，搭建业务语义层（逻辑方案）。
数据架构模型包括概念模型、逻辑模型和物理模型三大功能模块。
概念模型和逻辑模型可辅助企（事）业、政府部门或其他组织进行可视化的架构构建工作；可通过ODBC等形式以SQL语法查询逻辑模型数据。
物理模型可辅助开发设计人员对数据库方面进行方便、快捷的维护和设计工作。
可对接实际物理数据库，实现多套物理表方案路由，获取元数据信息，进行版本间比较、库与库间比较，显示差异内容，形成差异的SQL语句。
设有独立的图形引擎，可快速实现数据实体、数据表、属性和它们之间的关系。
1.1.2.数据架构资产开发的价值1)能够维护数据的概念模型、逻辑模型、物理模型专注既有资产，数据层出发。
支持从概念模型到物理模型的管理,实际上模型管理涵盖了主题域、概念主题、逻辑实体、信息系统、物理数据库、物理表等。
2)能够直连指定数据库环境，对比数据资产的变化能对接实际物理数据库，支持连接多种数据库（数据源，如MySQL、Oracle、SQL Server、DB2、PostgreSQL等），通过快捷的配置从物理库中抓取元数据以满足各种用户操作，主要是比对(与既有设计模型对比)、双向同步、版本管理等，实时反应对比数据资产的变化。
3)能够提供辅助的数据库设计功能自顶向下，从概念模型出发、到逻辑模型、到物理模型最后生成数据库脚本（SQL）。
以此来支持应用开发的数据库设计，并能对数据库设计进行规范化管理。
同时,重要用途之一是为了规范数据库设计工作，提供了初步数据库设计功能，可通过设计者模式快速进行数据库及数据表等的设计工作并生成DDL甚至可直接创建表至开发库。
4)提高数据库设计标准化，以保证数据质量通过信息分类编码及企业数据元集等方式，尽可能提高数据模型设计的规范性。
现行版本主要包括设计时重复提醒、数据元集引用、孤立元素检查（为归集元素）、合规性检查等手段，提高设计规范性。
同时还提供了设计与物理实例的比对，可以及时发现异常操作。
1.1.3.数据架构资产开发设计原理数据架构资产开发以企业架构（Enterprise Architecture，简称EA）方法为设计指导方法论，根据EA的方法进行产品本身的设计，同时又是产品承载的核心价值所在和方法固化。
1)主题域主题域是对概念主题的归类、分组，提供对主题域的维护及其下概念主题的访问功能。
包含对主题域的增、删、改、查、浏览等操作。
2)概念主题概念主题是企业数据划分的顶层构思模型，提供维护功能，包括增、删、改、查、浏览等操作。
可以查看对象关联的逻辑实体以及与该对象存在操作关系的信息系统。
3)逻辑实体逻辑实体是对概念主题进一步分解，经过全局协调，分析实体的属性并规范化数据结构产生的数据实体。
可进行增、删、改、查、浏览等操作。
4)信息系统数据库通常与信息系统联系在一起，提供对信息系统的管理功能包括对信息系统功能模块的维护功能。
5)物理数据库可对接多种物理数据库，支持多种数据源：普通数据库（MySQL、Oracle、SQL Server、DB2、PostgreSQL等），文件式（Excel、CSV、Txt），大型数据集群类型（HIVE、Spark）6)物理表提供设计人员专用模式，设计人员可以类似于一般数据库软件客户端的形式设计数据表。
数据架构是用于描述支持业务流程运行中信息与数据，提供了信息标准化描述和组织的模型。
应用架构从功能构件和信息服务层面来描述，它是衔接数据与业务、数据与用户之间的纽带和桥梁。
1.1.4.数据架构资产开发能解决的问题1)一般规模企业现状，理不清元数据。
2)业务系统繁多，经常性更新维护。
3)仅靠几个文件夹进行管理，数据库设计质量欠佳。
4)系统开发数据库设计管理不规范。
5)系统更新迭代频繁，造成数据库设计资料缺失或不同步。
6)开发测试生产数据库环境差异大。
7)主力系统更迭次数较多。
1.1.5.数据架构资产开发功能架构图支撑自顶向下与自底向上相结合的架构开发模式，智能辅助数据库设计。
1.1.6.数据架构资产开发功能设计1.1.6.1.概念模型概念模型是最终用户对数据存储的看法，是对用户信息需求的综合概括。
1.1.6.1.1.主题域对概念主题的归类、分组。
可对主题域进行添加、删除、修改操作。
1.1.6.1.2.概念主题企业数据划分的顶层构思模型，是最终用户对数据存储的看法，反映了用户的综合性信息需求。
可对概念主题进行添加、删除、修改等操作。
可查看该概念主题包含的逻辑实体和关联的存取系统。
1.1.6.2.逻辑模型逻辑模型是系统分析设计人员的观点，是对概念数据库的进一步分解和细化。
1.1.6.2.1.逻辑实体对概念主题进一步分解，经过全局协调，分析实体的属性并规范化数据结构产生的数据实体。
可对逻辑实体进行添加、删除、修改。
可对该逻辑实体的实体属性信息进行相关操作。
可与物理表创建关联关系。
1.1.6.2.2.实体关系图提供表示数据实体、属性和它们之间关系（联系）的方法，用来描述现实世界的抽象数据模型。
双击进入图形引擎，可对实体关系图进行相关操作，可新建、修改实体关系图。
1.1.6.2.3.数据映射图用于表达实体和数据来源间的关系。
双击进入图形引擎，可对数据映射图进行相关操作，可新建、修改数据映射图。
1.1.6.2.4.数据元标准最小的不可再分的信息单位，是一类数据的总称，也简称为数据元。
可添加、删除、修改数据元信息。
1.1.6.2.5.信息分类编码根据信息内容的属性或特征，将信息按一定的原则和方法进行区分和归类，并建立起一定的分类系统和排列顺序，以便管理和使用信息。
可添加、删除、修改编码信息。
可对其编码规则、编码结构、编码记录以及关联的数据元素进行管理。
1.1.6.3. 物理模型企业真实物理环境下的存储的数据库模型。
1.1.6.3.1. 信息系统现有信息系统的具体划分，可添加、删除、修改信息系统。
可查看信息系统下的功能模块。
可查看系统关联的物理数据库。
1.1.6.3.1.1.功能模块功能模块用于表现信息系统的内部行为。
可添加、删除、修改系统功能。
可用CRUD矩阵表达功能和物理表的存取分布关系。
1.1.6.3.2.设计库企业真实物理环境中存在的关键数据库信息。
项目经理的工作空间。
项目经理可添加、删除、修改设计库信息。
1.1.6.3.2.1.数据表双击设计库可显示该设计库下所有的表信息、表结构及表关联的实体信息。
可添加、删除、修改等操作。
1.1.6.3.2.2.物理数据库设计设计人员对数据库进行设计的工作空间。
包括表信息的修改，表字段添加、删除、合规性检查，索引的创建修改，建表语句的创建等。
但不可添加、删除、修改物理库信息。
1.1.6.3.2.3.数据库比对设计库可分别与开发库、生产库、测试库进行关联比对，显示差异结果。
差异结果可同步到设计库，也可导出差异部分的alter文。
1.1.6.3.3.测试库、生产库、开发库实际的物理数据库，是通过元数据获取功能获得的，表信息、表结构等不可修改。
1.1.6.3.3.1.版本比对获取的各版本之间可进行比对，显示差异。
1.1.6.3.4.物理实体关系图提供表示物理表、属性和它们之间关系（联系）的方法，用来描述现实世界的抽象数据模型。
双击进入图形引擎，可对物理实体关系图进行相关操作。
1.2.基于通用语义层理论的业务语义层数据查询引擎技术方案1.2.1.通用语义层特点通用语义层（Common Semantic Layer），检称CSL，最早起源与BO，目的在于让业务用户能够通过自己的业务术语，自由安全的访问、分析以及分享信息的技术，有如下特点：1.业务用户自主操作；2.提高用户对于各种企业数据的操作体验；3.提供一致可信的数据，确保同一业务术语的引用能够贯穿整个企业；4.让所有的商务智能工具都可以使用；5.让信息部门可以控制和确保信息访问的安全性；6.可以快速检索，迅速定位。
1.2.2.语义层带来的价值1.2.2.1.给业务用户带来的价值简洁一致的用户体验，让业务用户可以简便的访问企业内的数据；减少企业的培训成本；保障业务用户始终使用可信的信息；业务用户自创式创建各种商务智能的内容；可重用的查询、计算、参数、过滤条件、值列表简化用户使用；为普通用户提供了一个简化的界面，访问复杂的企业数据。
1.2.2.2.给IT 用户带来的价值降低BI项目的投入成本，保护现有IT数据投资；支持多数据源的语义层，提高服务质量；支持完整BI项目生命周期，项目开发、测试、投产；语义层与数据源的变化相同步；支持和扩展数据库的安全性；预定义的可重用的查询、参数、过滤、计算、值列表等。
1.2.3.语义层设计原理通用语义层模型设计基于业务（如保险）核心价值链上的核心业务对象和业务事件，采用维度总线架构思想来构建；业务对象通常用维度实现，业务事件通常用事实表实现，按照事实表的不同类型分为：累计快照事实表、周期快照事实表、交易基础事实表。
通用语义模型设计面向管理决策和经营分析，是公共维度和共性基础指标的实现载体，支持80%以上的共性应用需求；通用语义模型设计采用维度化的逆范式设计模式，通常采用以下策略：●预连接处理：按照总线架构维度和事实表的要求，将分散在多张相关实体表的数据属性进行预连接操作，使相关的维度尽可能组织在特定的维表或者事实表，如保单维、保单责任维、代理人维、客户维、赔案维等；●预计算处理：按照总线架构维度和事实表的要求，对事实表中的基础指标进行加工计算，保证基础指标逻辑加工的“Golden Copy”，如保单事件、核保事件、保全事件、查勘事件、理赔事件等；●汇总处理：针对共性的复杂指标，按照对应的维度进行提前聚合处理，以保证共性复杂指标逻辑加工的“Golden Copy”，避免重复加工，提供数据一致性和响应效率，如保单层面指标汇总，机构层面指标汇总，产品层面指标汇总，代理人层面指标汇总，客户层面指标汇总等；通用语义层模型的粒度尽可能保留到最细交易粒度（汇总处理除外），以保持模型间的连通性，并能够最大程度、最快速地响应新需求。
源系统数据中的维度、事实表经过统一梳理、整合，使得事实表和汇总结果表中数据存在稳定的、一致的关联关系；使得集市表不至于成“碎片”，基础指标在语义层已经计算完毕，尽量复用这些计算结果使得集市表间不同粒度指标汇总结果一致，都是来源于语义层；能够快速响应业务用户提出的新的报表需求（前提：基于已有指标），缩短响应时间使得BI工具内部建模简单，可读性好，且查询数据速度快，让开发人员集中精力在数据分析方式上；数据仓库模型简单，可维护性、可扩展性好，能够使得系统更加稳定运行。
