信息管理平台-系统整合
信息管理平台-系统整合思路
项目功能模块说明
从现有开发项目功能模块分析而言，抽离公共的功能代码模块，每个子系统作为一个大的功能模块单独独立出来。如果子系统之间需要调用接口，则可通过HttpClient或者是其他方式实现API调用。
基于公共的用户权限管理模块，完善后台系统管理体系，整合前台用户系统，优化系统结构
1.公有子模块抽离
a.公有模块说明
（1）用户角色权限(RBAC)模块
RBAC模块说明
RBAC权限设计模型：（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联，从而获得某些功能的使用权限。权限被赋予给角色，而不是用户，但是一个用户可以拥有若干个角色，当一个角色被赋予给某一个用户时，此用户就拥有了该角色所包含的功能权限。
是否需要引入用户组？角色组？
用户组：如果用户的数量非常大的时候，需要给系统的每一个用户逐一授权(分配角色)。为了简化单个操作流程，可以增加一个用户组，每个用户组内有多个用户，除了给单个用户授权外，还可以给用户组授权。通过一次授权，就可以同时给多个用户授予相同的权限，而这时用户的所有权限就是用户个人拥有的权限与该用户所在组所拥有的权限之和（去除重复权限设定）
结合实际项目需求考虑，引入用户组、角色组概念是否会导致权限多次重复分配？如果运维不当会导致角色权限冲突而触发未知错误。此外，考虑到系统模块之间的所访问的用户并不一定是同一个体系，每个子系统之间所引用的用户群体并不完全相同，因此简单提供“用户-角色-权限”（多对多）概念足以完善系统逻辑。在系统设计的时候要结合考虑系统实际应用的场景，避免过度的功能设计无畏增加了系统的使用复杂度。
例如，系统并无法访问全量的用户数据，且由于诸多不确定性用户数据可能隔段时间便会有相应的大变动，因此针对每个系统的用户数据维护都是通过管理员批量操作导入用户数据实现，除却个别用户需要额外单独处理。在这种情况下，如果需要机构管理员去匹配“无效”的用户进行相应变更，难免工作量巨大且容易遗漏数据。因此部分系统针对这种情况，每次执行批量导入便是执行“系统初始化操作”，后台会相应清理所有用户相关的关联数据，避免造成数据库数据冗余，触发不必要的误差。
综上所述，为了简化系统功能，此处结合实际更加倾向于不引入复杂的用户角色权限管理设计，此处进行简单说明：
1.子系统均提供批量导入操作，可以默认给用户指定角色
2.简化管理员功能操作，避免因概念混淆导致角色权限冲突触发未知错误
3.在用户数据不确定性的限制下，用户组的设定反而趋于无用功
一个用户拥有若干角色，每一个角色拥有若干功能权限，从而构造成“用户-角色-权限”的授权模型。为简化用户角色权限模型，此处“权限”可拆分为多级权限概念，对应不同的“概念”，从而构成“用户-角色-权限-资源”的授权模型。例如“菜单”、“页面元素”、“功能操作”、“数据范围限定”、“文件操作”等均可理解为权限的概念。因此，在数据库建模的时候考虑将“功能操作”和“资源管理”统一起来进行管理，用标识进行概念区分，用权限表进行关联，更具有便捷性和易扩展性
功能点拆分
综上所述，考虑将用户角色权限模块拆分为以下功能点
登录注销：提供单点登录入口，实现用户登陆一次便可访问关联的系统。由于此处是通过拆分工程模块达到划分子系统的目的，因此此处只是抽离公共的登录、注销入口API，以供子模块进行调用。如果后续需要进一步完善系统，可以考虑“微服务架构”，在这种思维导向下再去实现真正意义的SSO
统一登录入口：登录验证通过，主页面显示不同的子系统访问入口
用户表数据整合思路1：
不同子系统相应维护自己的用户表，但可共用一套角色权限管理体系
思路分析：如果要限定统一登录入口，用户信息要从n个子系统用户表中进行筛选
登录验证：
本地登录：通过用户编号和密码进行登录，需要从n个子系统用户表中筛选数据
远程登录：通过UASS账号密码登录验证，获取用户编号再进行登录验证
系统访问权限校验：
登录验证通过后可以获取到当前用户的用户编号数据，当用户想访问任意一个子系统的时候，便可通过“系统唯一标识”定位指定用户表，并以“用户编号+密码”进行访问，后台根据参数查找到相应匹配当前系统的角色和权限信息；且不同子系统间的session域互不影响
用户表数据整合思路2：
将所有子系统的用户数据整合到一张表中，通过系统唯一标识划定用户组的概念。
思路分析：由于没有系统全量用户维护的概念，如果将所有子系统的用户信息整合到一起，可能多个子系统之间会有重叠的用户记录（用户编号作为用户身份唯一标识），但每个用户的user_id是作为其在平台的唯一标识（用户编号、系统唯一标识作为双主键亦可唯一确定）。而每个子系统内部的user_num和login_account是其内部的唯一标识，两者概念要进行区分，避免在代码设计上混淆概念，导致系统错误
登录验证：
本地登录：通过用户编号和密码进行登录，只要mip_user表中包括指定user_num数据，则认为登录验证通过（可以理解为其在平台中拥有多个系统访问权限的身份标识）
远程登录：通过UASS账号密码登录验证，获取用户编号再进行登录验证
系统访问权限校验：
用户执行登录操作验证之后，进入系统主页。当用户想访问某个子系统的时候，则根据“用户编号、系统唯一标识”查找mip_user表中其关联的用户信息；且不同子系统间的session域互不影响
用户管理：维护用户基本信息；每个子系统限定管理其管辖范围的用户数据
角色管理：维护用户角色信息；每个子系统限定管理其管辖范围的角色数据
权限管理：维护功能权限信息；由超级管理员进行各个子系统的权限信息维护，管理角色权限关联关系
机构管理：维护组织机构信息（用户所属网点、所属机构）；由于没有全量的组织机构信息，因此此处组织机构的获取更多的是依赖于子系统的用户列表，只提供获取机构信息列表的公有接口，不额外进行机构信息维护
针对用户表设计：提供primary_class、secondary_class字段用于存储用户所属机构、所属网点信息，由于没有相应的所属机构、所属网点列表管理数据表（部门表），因此此处筛选条件的填充则以当前子系统的用户列表的数据为准：以此统计所有部门、网点的分类数据信息，也便于后续调整
获取“所属机构”列表：
select distinct(ui.primary_class)
from user_info as ui
获取“所属网点”列表：
select distinct (ui.secondary_class)
from user_info as ui
where ui.primary_class = '罗湖支行'
（2）系统日志管理
提供操作日志表:查看业务操作日志信息
提供系统运行日志表：查看系统运行日志表
约定好日志记录规则、定时清理日志数据，系统管理员可通过获取后台日志信息及时跟踪程序异常
（3）数据字典管理
配置公有数据字典
（4）其他公有子模块
例如定时任务设定：实现定时任务的动态配置
系统监控：在线用户、数据监控、服务监控等
数据库访问操作监听
b.公有模块设计
（1）数据库逻辑设计说明
| 表名 | 描述 |
|---|---|
| 用户角色权限模块相关 | |
| mip_user | 用户信息表:存储用户基本信息 |
| mip_role | 角色信息表:存储每个子系统对应的角色信息 |
| mip_authority | 权限/菜单信息表:存储相关的功能权限/菜单模块信息 |
| mip_user_role | 用户角色关联表:关联用户和角色的关系（用户-角色：一对多） |
| mip_role_authority | 角色权限信息表:关联角色和权限的关系（角色-权限：一对多） |
| 系统管理模块相关 | |
| mip_sys_config | 系统配置表 |
| mip_data_dict | 数据字典表 |
| mip_sys_oper_log | 系统操作日志表 |
（2）数据库物理设计说明
- mip_user：用户表
mip_user表主要用于存储用户基本信息，其具体设计如下表所示。其中user_id作为主键，每个用户拥有属于自己的基本信息，且对应着不同的账号信息。
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| user_id | varchar2(50) | primary key | 用户id |
| user_num | varchar2(50) | not null | 用户编号 |
| user_name | varchar2(255) | not null | 用户名称 |
| primary_class | varchar2(255) | / | 所属机构(一级分类) |
| secondary_class | varchar2(255) | / | 所属网点(二级分类) |
| login_account | varchar2(50) | not null | 登陆账号(UASS账号) |
| login_password | varchar2(255) | / | 登陆密码 |
| is_party_member | varchar2(50) | / | 是否为党员(0-否；1-是) |
| is_leader | varchar2(50) | / | 是否为一把手(0-否/其他领导干部;1-是/主要负责人) |
| user_status | varchar2(50) | / | 用户状态(0-禁用;1-启用) |
| logic_del | varchar2(50) | / | 软删除（逻辑删除标识）（0-未删除;1-已删除） |
| user_status | varchar2(50) | / | 用户账号启用禁用状态(0-禁用;1-启用) |
| system_identify | varchar2(255) | not null | 子系统唯一标识 |
| create_time | datetime | / | 创建时间 |
| update_time | datetime | / | 修改时间 |
说明：
平台无全量用户，各个子系统的用户数据需结合实际业务需求各自去维护 不同子系统对用户的属性要求不同，在数据库设计层面，除基础属性(用户编号)，其余属性不作额外限制，而是在代码层面进行控制 主键user_id亦或是“user_num、system_identify”作为双主键 由于没有系统全量用户的概念，每个系统子模块都独立有着自己的用户模块；因此用户组的概念更多是倾向于针对每个子模块 超级管理员不归属于任何一个子模块体系，为了不对业务逻辑造成影响，其system_identify设置为‘mip’，表示归属于平台，不纳入任意一个子系统(模块)统计范畴
针对用户表设计：提供primary_class、secondary_class字段用于存储用户所属机构、所属网点信息，由于没有相应的所属机构、所属网点列表管理数据表（部门表），因此此处筛选条件的填充则以当前的用户列表的数据为准：以此统计所有部门、网点的分类数据信息，也便于后续调整 获取“所属机构”列表：
select distinct(ui.primary_class)
from user_info as ui
获取“所属网点”列表：
select distinct (ui.secondary_class)
from user_info as ui where ui.primary_class = '罗湖支行'
为了实现业务的可扩展性，在不影响原有业务逻辑的情况下，可相应冗余多个用户属性字段，子系统可根据实际业务需求将所需字段进行封装，调用接口获取数据
- mip_role：角色表
mip_role表主要用于存储用户角色信息，其具体设计如下表所示。其中role_id作为主键，一个角色只能归属某个机构，一个机构可设置多个角色信息。
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| role_id | varchar2(50) | primary key | 角色id |
| role_key | varchar2(255) | unique | 角色标识 |
| role_name | varchar2(255) | not null | 角色名称 |
| remark | varchar2(1000) | / | 角色描述 |
| data_scope | varchar2(50) | / | 访问数据权限自定义实现数据过滤AOP |
| role_status | varchar2(50) | / | 角色状态(0-禁用;1-启用) |
| system_identify | varchar2(255) | not null | 子系统唯一标识 |
| create_time | datetime | / | 创建时间 |
| update_time | datetime | / | 修改时间 |
说明：
针对不同的子系统一个用户可能需要对应多个不同的角色，但需要注意针对单个功能项其角色对应的访问功能不能够重复，否则无法仅仅通过用户角色限定其所要筛选的范围（例如分行管理员、支行管理员都可以进行针对所管辖的范围进行数据统计操作，如果为一个用户指派两个功能覆盖的角色则有可能出现筛选数据混乱的情况，因此更要根据实际应用情景和需求进行角色权限关系设计）
role_key：角色标识，用于权限控制（@RequiresRoles(“”)）,必须校验唯一性
data_scope：如果需要对角色的数据访问权限进行限制，则相应需要关联“部门表”，由于用户所属部门都是根据导入的用户数据进行限定，因此在限定数据访问权限的时候可参考现有的用户表的机构数据进行操作，过滤数据（为了简化后台实现，亦可参考以往系统的设计思路，通过判断用户角色id来指定数据范围）
实际的角色和权限由shiro进行控制，数据过滤则可借助data_scope指定过滤的标准（从而取消项目对role_id的依赖）：
1-仅本人数据权限
2-本部门管辖范围内数据权限
3-本部门及以下管辖范围内数据权限
4-自定义数据权限
5-全部数据权限
基于上述定义，后台代码可通过判断data_scope字段来处理不同的数据
或者是根据data_scope字段借助AOP实现数据过滤拦截
- mip_authority：权限表
mip_authority表主要用于存储菜单信息(权限信息)，其具体设计如下表所示。其中authority_id作为主键，且权限之间设定了上下级关联关系（多级权限管理）。每个用户对应一个角色，而每个角色对应相应的多个不同的菜单访问权限。
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| authority_id | varchar2(50) | primary key | 权限id |
| parent_id | varchar2(50) | foreign key | 上级权限id |
| authority_key | varchar2(255) | unique | 权限标识 |
| authority_name | varchar2(255) | not null | 权限名称 |
| authority_url | varchar2(1000) | / | 权限访问url |
| authority_icon | varchar2(255) | / | 权限图标 |
| is_leaf | varchar2(50) | 0.父节点 1.子节点 | 是否为子节点 |
| authority_type | varchar2(255) | not null | 权限类型 |
| order_num | varchar2(255) | not null | 菜单排列顺序 |
| remark | varchar2(1000) | / | 权限描述 |
| system_identify | varchar2(255) | not null | 子系统唯一标识 |
| create_time | datetime | / | 创建时间 |
| update_time | datetime | / | 修改时间 |
说明：
目前权限(菜单)设定考虑构建多级菜单的基本属性，后续根据具体需求完善功能设计、完善菜单配置属性
authority_type为权限类型：他可以指定权限所概括的含义，可以理解为一个常量枚举（可从数据字典中进行配置）例如‘MENU’表示菜单访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等
为了简化系统表设计，此处将页面和操作整合成一个权限信息表，通过构建多级父子节点进行数据关联
权限数据设定对应到每个子系统，超级管理员可以对所有的权限进行管理，而针对某个子系统的管理员只能管理相应范围的权限数据
authority_key：权限标识，对应@RequiresPermissions("")
- mip_user_role：用户角色关联表
mip_user_role表主要用于存储用户角色关联信息，其具体设计如下表所示。其中user_role _id作为主键，标识不同的用户匹配相应的角色信息
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| user_role_id | varchar2(50) | primary key | 用户角色id |
| user_id | varchar2(50) | foreign key | 用户id |
| role_id | varchar2(50) | foreign key | 角色id |
说明：
暂定设定一个用户对应一个角色，每个角色拥有相应的菜单访问权限。
后续根据如果是一个用户对应多个角色权限，则针对角色重复的菜单权限需要剔除。此外，考虑到如果用户-角色为“一对多”，则角色权限设定还需要考虑权限重复、冲突的情况，一般来说一种状态下只激活一种角色，且角色的权限设定不应该存有冲突，这便要求系统运维的时候要尤其注意根据系统业务去划分角色权限的概念
- mip_role_authority：角色权限关联表
mip_role_authority表主要用于存储角色权限关联信息，其具体设计如下表所示。其中role_authority_id作为主键，标识不同的角色拥有不同的权限信息(一个角色可拥有多个不同的菜单访问权限)。
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| role_authority_id | varchar2(50) | primary key | 角色权限id |
| role_id | varchar2(50) | foreign key | 角色id |
| authority_id | varchar2(50) | foreign key | 权限id |
说明：
此处设定一个用户对应一个角色，每个角色拥有相应的菜单访问权限。如果是一个用户对应多个角色权限，则针对角色重复的菜单权限需要剔除
- mip_data_dict：数据字典表
mip_data_dict数据字典表主要用于维护数据，其具体设计如下表所示。其中data_id作为主键，data_type作为索引类型用以关联同一类型的数据。
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| data_id | int | primary key | 数据id(自增主键) |
| data_code | varchar2(255) | not null | 数据编码 |
| data_name | varchar2(255) | not null | 数据名称 |
| data_pid | varchar2(255) | 数据父节点编码 | |
| data_type | varchar2(255) | / | 数据类型 |
| create_time | datetime | / | 创建时间 |
| update_time | datetime | / | 修改时间 |
说明：
mip_data_dict用以维护页面某些静态数据，通过java代码封装成所需的下拉框数据
data_type：关联归属于同一类型、集合的数据
data_code：数据在指定类型、集合的唯一编码（避免出现重复的数据编码导致数据封装异常）
data_pid：增加父子节点概念，用以封装树状菜单
- mip_sys_oper_log：系统操作日志表
mip_sys_oper_log系统操作日志表主要用于记录每次请求的具体内容，供开发人员查阅调试，其具体设计如下表所示。其中log_id作为主键
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| log_id | varchar2(50) | primary key | 日志id |
| log_title | varchar2(1000) | not null | 日志标题 |
| business_type | varchar2(255) | / | 业务类型（CRUD） |
| oper_type | varchar2(255) | 操作类别 | |
| oper_crew | varchar2(2000) | 操作人员(包含操作人员基本信息:user_num、user_name等) | |
| oper_host_ip | varchar2(100) | 操作主机ip | |
| oper_location | varchar2(2000) | 操作地点 | |
| oper_time | datetime | 操作时间 | |
| oper_status | varchar2(50) | 操作状态(0-正常;1-异常) | |
| request_mode | varchar2(255) | 请求方式 | |
| request_method | varchar2(255) | 请求方法名称 | |
| request_url | varchar2(1000) | 请求url | |
| request_param | varchar2(1000) | 请求参数 | |
| response_result | varchar2(2000) | 返回结果 | |
| error_msg | varchar2(2000) | 错误消息提示 | |
说明：
操作日志：
oper_type：操作类别可包括不同的客户端（网页端用户、手机端用户等）
business_type：操作类型可包含增加、删除、修改操作（查询操作过于频繁因此不纳入监听范畴）
- mip_sys_config：系统配置表(待定)
mip_sys_config表主要用于存储系统配置信息，其具体设计如下表所示。其中role_authority_id作为主键，标识不同的角色拥有不同的权限信息(一个角色可拥有多个不同的菜单访问权限)。
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| config_id | 配置id | ||
| config_type | 配置类型 | ||
| config_code | 配置参数 | ||
| config_status | 配置状态说明 | ||
| system_identify | varchar2(255) | not null | 子系统唯一标识 |
说明：根据系统需求添加配置项
2.系统子模块扩展
在已有项目构建的基础上，除却公有的模块，引入自身子系统的项目配置，独立开发
创建子模块（规范命名）
引入公有模块依赖，继承父工程
独立开发
a.后台管理系统
数据字典管理
表单设计管理
mip_form：表单管理表
mip_form表主要用于存储表单数据，其具体设计如下表所示。其中form_id作为主键，一个按钮(类似新增、修改时需要反显的表单)只能对应一个表单。
| 字段名称 | 字段类型 | 约束 | 描述 |
|---|---|---|---|
| form_id | varchar2(50) | primary key | 表单id |
| form_name | varchar2(255) | not null | 表单名称 |
| remark | varchar2(1000) | / | 表单描述 |
| form_data | varchar2(2000) | / | 表单数据(JSON字符串) |
| publish_status | varchar2(50) | / | 模板发布状态(0-禁用;1-启用) |
| system_identify | varchar2(255) | not null | 子系统唯一标识(表单归属子系统) |
| create_time | datetime | / | 创建时间 |
| update_time | datetime | / | 修改时间 |
说明：
在authority表中新增relate_form字段(关联表单)，一个功能块组件关联一个表单
系统操作日志管理
后台查看处理日志
b.员工线上评议系统
| annex | varchar2(255) | file(路径存储) | 附件信息(路径)（针对被评议人） |
|---|---|---|---|
user_flag：用户标识（不同用户标识用于匹配相应的问卷）,用户本身可能既作为评议人又作为被评议人，为了便于用户设定数据(减轻业务工作量)，用is_party_member、is_leader字段进行替代，待启用评议（发布评议）的时候由后台校验后再指定要绑定的问卷并发布
考虑附件信息通过建立关联表去进行关联操作：被评议人的附件信息annex关联：由管理员批量上传附件信息（附件命名均按照一定的规则，例如“用户编号-姓名.xxx”），然后再通过附件信息批量进行匹配
数据监控、数据监测数据库数据
定时任务（自定义）