《数据架构参考(同名7673)》由会员分享，可在线阅读，更多相关《数据架构参考(同名7673)（81页珍藏版）》请在金锄头文库上搜索。
1、1 数据架构设计（数据架构组）1.1 概述1.1.1 总体描述相对于业务架构和应用架构，数据架构在总体架构中处于基础和核心地位。因为信息系统支撑下的海关业务运作状况，是通过信息系统中的数据反映出来的，数据信息系统管理的重要资源。因此构建海关的IT总体架构时，首先要考虑数据架构对当前业务的支持。理想的IT总体架构规划逻辑上是数据驱动的，即：首先根据业务架构分析定义数据架构；然后根据数据架构结合业务功能定义应用架构；最后根据应用架构与数据架构的定义，来设计技术架构。1.1.2 数据架构蓝图1.1.2.1 逻辑蓝图图：数据架构总体逻辑蓝图数据架构的六个统一，即统一数据规划、统一存储、统一计算、统一服
2、务、统一接入、统一数据治理。1.1.2.2 物理蓝图图4-1-1l 通过万兆连接核心交换区，实现网络高速交换，确保可靠性 l 各服务器均双线连接数据区核心交换机，消除单点故障 l 结构清晰，层次分明1.1.3 设计原则1、整体性原则共享服务平台必须根据统一的总体方案的统筹规划，按总署、直属海关、隶属海关的功能划分实行多级部署，同时按照职责分工进行建设和管理，保证三个层级的部署构成一个整体，各部分通信畅顺，信息共享，形成一个全国性的共享服务平台。2、标准化原则总署统一制定信息资源共享服务的技术标准、通信协议标准、数据交换报文标准，提供数据访问功能、基本业务逻辑处理功能的标准组件。系统的开发、集成
3、按照规定的标准进行，保证海关共享服务平台的结构一致性和技术规范性。3、安全与效率并重原则总结和汲取超大业务量海关的成功经验，采取充分足够的技术手段和管理制度，在保证共享服务平台与海关业务应用系统之间高速的数据交换，在保证共享服务平台良好运行效率的同时，保证海关业务运行网和业务管理网的信息安全和运行安全。系统设计方面要充分考虑共享服务平台数据量大、负荷高等因素，严格控制程序流程设计、严把程序编制质量、同步制定配套的系统运行管理办法，确保共享服务平台运行的高效性和稳定性。4、系统功能与职责分工相适应原则平台多方共建，发挥各方面的积极性，信息系统、业务系统与业务管理或操作运行的主体之间的关系和分工必
4、须明确。5、一致性原则共享服务平台在体系架构上必须与金关业务解决方案的框架保持一致，在系统开发建设的设备选型、开发技术、认证授权、门户框架、数据定义、参数管理、通信协议、网络结构、安全运维等方面必须与金关总体技术方案保持一致，保证共享服务平台成为现代海关综合管理系统的有机组成部分。注:整体统筹原则数据层和应用层解耦数据的高可靠服务的高可用1.1.4 设计目标“信息资源体系建设”是一项长期工程，是支撑海关各个业务条线之间实现充分协作信息共享基础架构。将确保金关工程二期在海关信息资源开发利用方面抓住数据一致性、规范性等数据质量源头建设,形成统一顶层设计，做到海关信息资源一盘棋，数据统一管控，统一开
5、发利用，促进海关信息共享、业务协作效率和科学决策水平的更高提升。总体目标主要包括以下五个方面内容：1、实现信息资源整合信息资源规划的一项很重要的目标就是要解决目前信息系统建设中的重复建设问题，达到信息系统的整合和集约，信息资源规划是信息系统顶层设计的一部分，能够从整体上对信息资源进行设计，并能够提供信息系统建设的标准和规范，这样信息系统就能够以此为标准，进行适时、适度、逐步整合，最终达到消除冗余，集约良性发展的效果。2、提高技术响应速度业务需求的变化和技术的响应速度之间一直是一对矛盾，信息资源规划通过对信息系统，尤其是信息资源架构进行科学设计，可以增强信息资源架构的稳定性，当业务需求变化时，可
6、以通过很少的数据结构和程序变动就能够满足业务需求，这样不但提高了技术响应速度，而且能够增强系统的稳定性，降低故障率。3、实现信息共享信息资源规划通过建设信息共享服务平台，实现了数据的集中存储和计算，并实现了对外统一的服务接口，不论是对于海关内部的信息共享需求，还是外部的数据共享需求；不论是直接面向用户的共享查询，还是面向应用系统的数据服务，都可以通过数据服务共享平台解决。4、实现大数据分析海关要实现智能海关，必须实现海关信息系统的物联化、互联化、智能化，而最重要的就是智能化，即通过大数据分析，为海关准确决策提供信息支持。信息资源规划通过设计和实现数据共享服务平台，引入并行数据库、分布式数据库等
7、大数据存储和计算技术，能够解决海关的大数据分析问题，达到数据用得好、决策准的业务目标。5、提升数据质量 信息资源规划通过设定标准规范、业务管理流程，能够规范数据的定义、存储、使用、传输、交换，使得数据采集更加规范、数据传输更加准确高效，数据使用更加安全方便，通过各种管理流程和规范，能够大幅提升数据质量。1.2 数据定义1.2.1 总体描述数据的基本结构分三个层次，反映了观察数据的三种不同角度。(1)概念数据层。它是数据的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据所有对象的逻辑关系，而不是它们的物理情况。(2)物理数据层。它是物理存贮设备上实际存
8、储的数据的集合。这些数据是原始数据，是用户加工的对象，由内部模式描述的指令操作处理的位串、字符和字组成。(3)逻辑数据层。它是用户所看到和使用的数据，表示了一个或一些特定用户使用的数据集合，即逻辑记录的集合。数据建模1.2.2 业务域根据目前海关不同的网络，运行网、管理网和接入网以及总署和直属的这种物理关系，梳理出每个域中业务情况和相互的关联关系划分出不同的业务域。海关目前的现状梳理出来的业务域有： 公共域、首长决策域、公共办公域、业务管理域、综合保障域和内部监控公共域：1) 公共时间域2) 公共金融域3) 公共位置域4) 公共人员域5) 公共机构域6) 公共参数域首长决策：1) 署长办公公共
9、办公：1) 办公2) 国际事务业务管理：1) 政法2) 关税3) 监管4) 物流5) 加贸6) 稽查7) 缉私8) 统计综合保障：1) 科技2) 财务3) 关务保障4) 人事内部监控1) 督查审计2) 监察根据业务 划分核心数据和非核心数据。1.2.3 概念模型设计概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，它以数据类的方式描述企业级的数据需求，数据类代表了在业务环境中自然聚集成的几个主要类别数据。概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性，也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。概念数据模型的目标是统
10、一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。根据业务域的划分，梳理跨业务域的端到端的业务流程，从而梳理出大的对象之间的关系和小的业务流程。例如，用户（user）ER图1.2.4 逻辑模型设计逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。 逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。 逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如
11、何来实现。逻辑数据建模不仅会影响数据库设计的方向，还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多，那么在物理数据模型设计时就可以有许多可供选择的方法。解决端到端的业务流程梳理出大量的小流程和对象关系，进一步梳理出各个业务域的业务对象及其行为和属性。1.2.5 物理模型设计物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。 物理数据模型的内容包括确定所有的表和列，定义外键用于确定表之间的关系，基于用户的需求可能进行发范式化等内容。在物理实现上的考虑，可能会导致物理数据模型和逻辑数据模型有较大的不同。物理
12、数据模型的目标是指定如何用数据库模式来实现逻辑数据模型，以及真正的保存数据。常用的设计范式，以及对于数据量大的业务，在数据模型层面不处理表之间的主外键之间的关系。主要将逻辑模型的各个业务对象及之间的关系，以表、主外键及关联表的方式表示。针对各个逻辑模型勾勒出各个域的ER模型。1.3 数据分布1.3.1 总体描述将数据物理分布式处理方式逐步转为集中式处理方式，本节主要描述数据在各个业务子系统之间的逻辑分布，以及数据物理分布。1.3.2 逻辑分布系统名称分系统名称子系统名称系统应用类型业务应用类数据业务分析类数据缉私监控指挥企业信息应用归类风险监控审单执法企业综合资信数据交换应急指挥情报预警监测决
13、策分析风险监测物流链监控分析专家会诊审单数据信息管理全国HG监控指挥系统风险管理分系统风险监控子系统实时性要求不高的OLTP风险处置子系统实时性要求不高的OLTP应急指挥分系统应急监控预警子系统实时性要求不高的OLTP应急指挥调度子系统实时性要求不高的OLTP决策分析分系统决策分析分系统OLAP值班管理分系统值班管理分系统实时性要求不高的OLTP预案管理分系统预案管理子系统实时性要求不高的OLTP演练管理子系统实时性要求不高的OLTP缉私作战指挥分系统实战管理子系统实时性要求不高的OLTP信息支持子系统实时性要求不高的OLTP地理信息子系统实时性要求不高的OLTP移动应用分系统移动客户端框架子系统实时性要求不高的OLTP移动端统一入口子系统实时性要求不高的OLTP移动应用服务中间件子系统实时性要求不高的OLTP移动应用管理子系统实时性要求不高的OLTP移动设备管理子系统实时性要求不高的OLTP业务应用插件子系统 实时性要求不高的OLTP
