本发明涉及数据处理领域，尤其涉及一种医疗数据处理方法、装置及平台。
背景技术：
：：目前绝大多数医院的信息化系统通过oracle数据库存储。现有数据存储系统各自基于相应的架构，使用不同的技术和语义标准来表示存储。这样客户端的服务器系统取决于本地硬件，软件和数据存储，每套系统可能使用不同的语言和数据库技术。这种情况下，对来自多个时常冲突的系统的数据进行准确和便捷的整合变得极为困难。技术实现要素：有鉴于此，本发明实施例期望提供一种医疗数据处理方法、装置及平台，至少部分解决医疗数据整合难度大的问题。为达到上述目的，本发明的技术方案是这样实现的：本发明实施例第一方面提供一种医疗数据整合平台建立方法，所述方法包括：在数据层，建立本地域模型；所述本地域模型用于定义存储在本地数据库中的医疗数据存储的本地约束条件；基于所述本地域模型，抽象出全局域模型；所述全局域模型用于定义存储在全局数据库中的医疗数据存储的全局约束条件；其中，所述本地域模型和所述全局域模型统称通用域模型。基于上述方案，所述建立本地域模型，包括：定义本地数据模型和本地接口模型；其中，所述本地数据模型用于提供所述本地数据库存储所述医疗数据的存储格式；所述本地接口模型用于提供基于本地数据库交互医疗数据的接口属性；所述基于所述本地域模型，抽象出全局域模型，包括：定义全局数据模型和全局接口模型；其中，所述全局数据模型用于提供所述全局数据库存储所述本地数据库提交的医疗数据的存储格式；所述全局接口模型用于提供基于全局数据库交互医疗数据的接口属性。基于上述方案，所述方法还包括：利用所述本地数据库接收来自不同数据源的医疗数据；将所述医疗数据转换成本地域模型对应的数据格式，并存储已转换后的医疗数据；建立所述数据源、本地域模型及全局域模型任意两者之间的映射关系。基于上述方案，所述方法还包括：在应用开放编程接口层，定义应用开放编程接口；其中，所述应用开放编程接口，用于访问医疗数据整合平台中的数据提供接口。基于上述方案，所述方法还包括：在应用层，基于所述通用域模型展示医疗数据。本发明实施例第二方面提供一种医疗数据整合平台建立装置，所述装置包括：建立单元，用于在数据层，建立本地域模型；所述本地域模型用于定义存储在本地数据库中的医疗数据存储的本地约束条件；抽象单元，用于基于所述本地域模型，抽象出全局域模型；所述全局域模型用于定义存储在全局数据库中的医疗数据存储的全局约束条件；其中，所述本地域模型和所述全局域模型统称通用域模型。基于上述方案，所述建立单元，具体用于定义本地数据模型和本地接口模型；其中，所述本地数据模型用于提供所述本地数据库存储所述医疗数据的存储格式；所述本地接口模型用于提供基于本地数据库交互医疗数据的接口属性；所述抽象单元，具体用于定义全局数据模型和全局接口模型；其中，所述全局数据模型用于提供所述全局数据库存储所述本地数据库提交的医疗数据的存储格式；所述全局接口模型用于提供基于全局数据库交互医疗数据的接口属性。基于上述方案，所述装置还包括：接收单元，用于利用所述本地数据库接收来自不同数据源的医疗数据；转换存储单元，用于将所述医疗数据转换成本地域模型对应的数据格式，并存储已转换后的医疗数据；所述建立单元，还用于建立所述数据源、本地域模型及全局域模型任意两者之间的映射关系。基于上述方案，所述装置还包括：定义单元，用于在应用开放编程接口层，定义应用开放编程接口；其中，所述应用开放编程接口，用于访问医疗数据整合平台中的数据提供接口。基于上述方案，所述装置还包括：展示控制单元，用于在应用层，基于所述通用域模型展示医疗数据。本发明实施第三方面提供一种医疗数据整合平台，所述平台包括：本地数据库，用于基于本地域模型进行医疗数据的存储；所述本地域模型用于定义存储在本地数据库中的医疗数据存储的本地约束条件；全局数据库，与所述本地数据库连接，用于基于全局域模型对本地数据库提交的医疗数据进行存储；其中，所述全局域模型包括基于所述本地约束条件抽象出形成的全局约束条件；其中，所述本地域模型和所述全局域模型统称通用域模型。本发明实施例提供的医疗数据处理方法、装置及平台，通过建立本地域模型和全局域模型，能够在数据层面进行数据存储和处理的约束，这样存储在所述医疗数据整合平台中的数据具有统一数据格式，方便进行医疗数据的整合；从而解决现有技术中各种医疗数据因为数据格式或数据来源导致的无法进行数据整合的问题。附图说明图1为本发明实施例提供的第一种医疗数据整合平台建立方法的流程示意图；图2为本发明实施例提供的医疗数据整合平台建立方法的部分流程示意图；图3为本发明实施例提供的医疗数据整合平台建立装置的结构示意图；图4为本发明实施例提供的一种医疗数据整合平台的结构示意图；图5为本发明实施例提供的医疗数据整合平台的数据操作示意图；图6为本发明实施例提供的医疗数据转换存储的示意图。具体实施方式以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。实施例一：如图1所示，本实施例提供一种医疗数据整合平台建立方法，所述方法包括：步骤s110：在数据层，建立本地域模型；所述本地域模型用于定义存储在本地数据库中的医疗数据存储的本地约束条件；步骤s120：基于所述本地域模型，抽象出全局域模型；所述全局域模型用于定义存储在全局数据库中的医疗数据存储的全局约束条件；其中，所述本地域模型和所述全局域模型统称通用域模型。本实施例中的所述医疗数据可包括医院信息系统中存储的各种数据、例如，病患数据、医生的个人及就诊数据、还包括用户的体检数据，例如健康医疗数据、基因数据、医疗费用数据、以及智能可穿戴设备检测的生命体征数据等各种健康相关的数据。所述医疗数据整合平台，可能对应有多个本地数据和分别与该本地数据库连接的通用数据。在本实施例中所述数据层为数据存储层面，建立本地域模型。例如，在上述平台中有n个本地数据库，则在步骤s110中可为每一个所述本地数据库建立一个针对该本地数据库的本地域模型。在该本地域模型中定义了本地数据库进行医疗数据存储的本地约束条件。那么从医疗系统、智能设备等各种接收的医疗数据。在本实施例中所述本地约束条件可包括定义了各种数据的类，例如医患的个人信息类、临床诊断病症类等。在一个类下可以多个数据值。在步骤s110中可以利用各种服务器等电子设备解析存储在本地数据库中的医疗信息，建立数据存储的类，得到所述本地域模型。在步骤s120中将基于本地约束条件，抽象出全局域模型。全局域模型至少对应有全局约束条件，例如将本地约束条件中设定到的多个类视为子类，抽象出一个上一层的类。在本地数据库通过数据解析得到了所述本地域模型以后，将本地域模型上传到全局数据库，由全局数据库的管理设备等电子设备，解析各个本地域模型，抽象出与每一个所述本地域模型都兼容的全局域模型，以后在存储在本实施例中所述的医疗数据整合平台中的数据，都需要满足所述通用域模型的约束，这样就方便了后续医疗数据整合平台中存储的医疗数据的整合，及来自不同数据源的医疗数据的交互。在本实施例中建立本地域模型可以满足不同医疗数据的灵活存储和处理，同时通过抽象本地域模型形成全局域模型，这样可以方便各种不同类型的医疗数据的整合和通用交互，这样很好的平衡了不同医疗数据的灵活性和存储特色性，同时能够很好的实现医疗数据的整合和互通。进一步地，所述步骤s110可包括：定义本地数据模型和本地接口模型；其中，所述本地数据模型用于提供所述本地数据库存储所述医疗数据的存储格式；所述本地接口模型用于提供基于本地数据库交互医疗数据的接口属性。这样连接在本地数据库之间或位于本地数据库中的不同数据主体能够根据该接口属性，利用本地接口模型对应的接口进行医疗数据的交互。所述步骤s120可包括：定义全局数据模型和全局接口模型；其中，所述全局数据模型用于提供所述全局数据库存储所述本地数据库提交的医疗数据的存储格式；所述全局接口模型用于提供基于全局数据库交互医疗数据的接口属性。进一步地，如图2所示，所述方法还包括：步骤s210：利用所述本地数据库接收来自不同数据源的医疗数据；步骤s220：将所述医疗数据转换成本地域模型对应的数据格式，并存储已转换后的医疗数据；步骤s230：建立所述数据源、本地域模型及全局域模型任意两者之间的映射关系。在本实施例中所述本地数据可可以接收不同数据源的医疗数据，例如接收医院的医院信息系统(hospitalinformationsystem，his)、电子病例(electronicmedicalrecord，emr)系统、试验信息系统(laboratoryinformationsystem，lis)、影像归档和通信系统(picturearchivingandcommunicationsystems，pacs)或临床信息系统(clinicalinformationsystem，cis)发送的不同数据格式的医疗数据。将这些数据转换成本地模型对应的数据格式，并存储这些医疗数据，这样的话，就能够方便医疗数据整合平台后续对一个本地数据库中统一数据格式的数据进行整合和归纳等信息处理。在本实施例中为了方便数据存储之后的，数据查找，在本实施例中还会建立所述数据源与本地数据库中本地域模型之间的映射关系，这样基于该映射关系，不同的数据源可以快速的找到自己存储在本地数据库中的医疗数据。进一步地，所述方法还包括：在应用开放编程接口层，定义应用开放编程接口；其中，所述应用开放编程接口，用于访问医疗数据整合平台中的数据提供接口。这里的应用开放编程接口又可称为api，对应的英文全拼为applicationprograminterface。通过利用应用开放编程接口方便对本地数据库和全局数据库的访问。进一步地，所述方法还包括：在应用层，基于所述通用域模型展示医疗数据。一条医疗数据记录可能有很多医疗信息，但是在应用层面进行信息展示可能仅需展示其中的部分，在本实施例中可以在本地域模型或全局域模型的约束下，仅显示与该应用对应的医疗信息；从而实现与不同种类的医疗应用的信息耦合和展示。实施例二：如图3所示，本实施例提供一种医疗数据整合平台建立装置，所述装置包括：建立单元110，用于在数据层，建立本地域模型；所述本地域模型用于定义存储在本地数据库中的医疗数据存储的本地约束条件；抽象单元120，用于基于所述本地域模型，抽象出全局域模型；所述全局域模型用于定义存储在全局数据库中的医疗数据存储的全局约束条件；其中，所述本地域模型和所述全局域模型统称通用域模型。本实施例中所述理疗数据整合平台建立装置，可对应于服务器等电子设备。所述建立单元110和抽象单元120可对应于处理器或处理电路；所述处理器可包括中央处理器、数字信号处理器、微处理器或可编程阵列等处理结构，能够进行信息处理。在本实施例中所述装置通过设定本地域模型和全局域模型，可设定数据存储的本地约束条件和全局约束条件，通过本地约束条件和全局约束条件的建立，能够约束数据存储的格式等，这样方便后续对存储在该平台内数据的整合。进一步地，所述建立单元110，具体用于定义本地数据模型和本地接口模型；其中，所述本地数据模型用于提供所述本地数据库存储所述医疗数据的存储格式；所述接口模型用于提供本地数据库中不同数据主体交互医疗数据的接口属性；所述抽象单元120，具体用于定义全局数据模型和全局接口模型；其中，所述全局数据模型用于提供所述全局数据库存储所述本地数据库提交的医疗数据的存储格式；所述全局接口模型用于提供全局数据库中各个数据主体交互医疗数据接口属性。在本实施例中本地域模型和全局域模型都对应于数据模型和接口模型，通过数据模型约束数据存储的格式，接口模型能够限定使得的数据主体之间进行数据互通。此外，所述装置还包括：接收单元，用于利用所述本地数据库接收来自不同数据源的医疗数据；转换存储单元，用于将所述医疗数据转换成本地域模型对应的数据格式，并存储已转换后的医疗数据；所述建立单元110，还用于建立所述数据源、本地域模型及全局域模型任意两者之间的映射关系。在本实施例所述转换存储单元，可能会对从数据源接收的数据进行清洗等操作，然后进行数据格式的转换，从而使得存储到本地数据库或全局数据库中的数据分别满足本地域模型和/或全局域模型。在本实施例中所述建立单元110还将建立数据源与本地域模型之间的映射关系，方便后续医疗数据的查找。所述装置还包括：定义单元，用于在应用开放编程接口层，定义应用开放编程接口；其中，所述应用开放编程接口，用于访问医疗数据整合平台中的数据提供接口。在本实施例中所述装置还会定义api，这样方便不同的应用或数据源访问所述医疗数据整合平台提供接口，这样更好的实现医疗数据的交互。这里的定义单元的硬件结构也可应于处理器或处理电路等。此外，所述装置还包括：展示控制单元，用于在应用层，基于所述通用域模型展示医疗数据。这样展示控制单元的设置，一方面各种不同的应用可以应用数据整合平台中存储的医疗数据，同时通过本地域模型和全局域模型的约束，可以满足不同应用展示不同的医疗数据的需求，和仅展示一条医疗数据记录中部分医疗数据的需求。实施例三：如图4所示，本实施例提供一种医疗数据整合平台，所述平台包括：本地数据库210，用于基于本地域模型进行医疗数据的存储；所述本地域模型用于定义存储在本地数据库中的医疗数据存储的本地约束条件；全局数据库230，与所述本地数据库连接，用于基于全局域模型对本地数据库提交的医疗数据进行存储；其中，所述全局域模型包括基于所述本地约束条件抽象出形成的全局约束条件；其中，所述本地域模型和所述全局域模型统称通用域模型。在本实施例中所述医疗数据整合平台分为了本地数据库和全局数据库；且本地数据库通常为多个，且通常按照地域划分分布在不同的位置，实现对数据的分布式存储的。在本实施例中可利用海杜普hadoop够将本实施例中所述医疗数据整合平台，分别采用hadoop分布文件系统(hadoopdistributedfilesystem，hdfs)建立本地数据库和/或全局数据库，实现医疗数据的分布式存储，保证所述医疗数据整合平台的大存储容量。在本实施例中通过两级数据库的设置，一方面实现了医疗数据的分层存储和管理，同时方便不同地理范围内的医疗数据的灵活存储，同时也方便了数据的通用存储和后续整合操作。在本实施例中所述全局数据库可为经过对医疗数据的分析挖掘之后，形成的共享医疗数据。如图4所示，本地数据库与各种能够提供医疗数据的信息系统相连，在图4中显示有cis、emr系统和his等系统。通常数据源与本地数据库相连，与本地数据库交互数据。总之本实施例提供了一种医疗数据整合平台，通过建立基于本地域模型的本地数据及基于全局域模型的全局数据库，能够实现医疗数据的整合处理。以下结合上述实施例提供的任意一个技术方案，提供两个具体示例。示例一：如图5所示，利用本发明实施例提供的医疗数据整合平台进行数据操作，分为4大数据操作；异构医疗数据整合、海量数据统一存储、分布式并行数据处理及数据分析和挖掘；以下分别介绍上述4大数据操作。第一、异构医疗数据整合：来自于不同来源的健康医疗数据，包括便携式设备采集的体征数据，emr电子病例数据，ehr电子健康档案，以及医院his、lis、pacs、来自公共卫生的健康医疗数据以及基因数据。这些来源多样的异构数据被清洗、转换后被整合在统一的数据模型。本示例中将利用数据汇聚和分发服务引擎dads，为多模态体征数据和可穿戴设备接入提供一站式服务能力是基本要求，满足标准化接入、可扩展性设计、高并发处理是其核心能力。标准化接入是指来自于不同厂家、不同设备类型、不同数据格式、通过不同传输协议的体征数据按照统一的格式和技术规范被汇集。可扩展性设计是指支持现有的几十余种生命体征类型、多种传输协议、不同数据格式的数据上传外，对后续的数据传输方式和格式扩展上提供系统零升级改造。高并发处理是指基于分布式计算和负载均衡技术，实现高可靠和零丢包的并发处理性能，满足业务的实时处理能力。它实现了多模态体征数据在标准化接入、可扩展性设计上的重大突破，具备将可穿戴设备接入平台并提供数据存储、分发和分析等一站式数据服务能力，解决了以往设备只能逐个对接时存在的开发周期长、代码维护成本高、升级改造受限的问题。目前已支持10余种生命体征类型(血糖、血压、运动、心电等)和多种传输协议(http/tcp/udp)，满足高并发、高性能、高可靠性、易伸缩的运营需求。网关发送的数据格式不是统一的，为了灵活解析各种格式的数据，需要在接收到数据后分析数据格式，提取其有效字段，封装成消息对象存储在内存队列中。数据格式的分析包括字节码转换、json/xml转换、文件读取处理等，最终得到平台统一的数据解析格式。第二、海量数据统一存储：医疗数据整合平台既需要管理和处理结构化的数据，也必须面临非结构化的数据存储和管理，采用hadoop成为构建本示例中所述医疗数据整合平台。医疗数据整合平台采用了基于hadoop分布式文件系统的hbase数据库对患者各种医疗海量数据进行存储和管理，有权限的用户登录云平台访问相关的数据以及进行相应的操作。hbase是运行在hadoop上的nosql数据库，它是一个分布式的和可扩展的大数据仓库。hbase是建立在mapreduce框架之上的，利用hdfs的分布式处理模式，融合键key/值value存储模式带来实时查询的能力，以及通过mapreduce进行离线处理或者批处理的能力，让用户在大量的数据中查询记录并获得综合分析报告。hbase中的数据存储采用以下四位的数据模型。这里的四维的数据模型可为所述本地域模型和/或全局域模型的数据模型。所述四维的数据模型包括：行键：每行都有唯一的行键，行键没有数据类型，可包括一个字节数组。列簇：数据在行中被组织成列簇，每行有相同的列簇，但是在行之间，相同的列簇不需要有相同的列修饰符。在引擎中，hbase将列簇存储在它自己的数据文件中，所以列簇需要事先被定义。列修饰符：列簇定义真实的列，被称之为列修饰符，你可以认为列修饰符就是列本身。版本：每列都可以有一个可配置的版本数量，你可以通过列修饰符的制定版本获取数据。关于hbase数据存储的具体实现，我们将会在下一节中详细介绍。在本示例中可进行医疗数据的分类存储：以患者的就医流程和医院管理两条路径为线索，由对挂号(his系统)、门诊(emr+lis+pacs系统)、住院(emr+cis系统)等整合，通过数据抽取形成可扩展标示语言(extensivemarkuplanguage，xml)文件。以下分别对存储医疗数据的表、行键、列簇进行介绍。表：hbase数据被建模为多维映射，其值通过四个键索引value＝map(tablename，rowkey,columnkey，timestamp)，其中tablename是表的名称；rowkey是行键同时也是表的主键，行通过行键按字典顺序排序；columnkey是列族，每个列族可以拥有任意数量的成员，它们通过标签(或修饰符)识别；timestamp为时间戳。这样方便后续根据行健对医疗数据进行查询。行健：行健对应的字节数不大于16个字节。如果行健过长会影响hfile的存储效率，同时系统将无法缓存更多的数据，降低内存的有效利用率和检索效率。行健具有唯一性，表示一条医疗数据记录对应整个平台内唯一的行键，从而方便后续快速精确查找医疗数据。以下提供一个行键的具体示例：病人id加上就诊类型加上就诊时间加上信息来源。这里的病人id可包括病人的各种标识信息，例如病人的姓名、身份证号或护照号等。这里的数据来源可来自his、lis、pacs、ris、emr系统或来自用户自行佩戴的智能设备等。列簇：由于hbase是一个面向列族的存储器，列族成员都有相同的访问模式(accesspattern)和容量特征。在一张表里列簇的个数小于预定值。例如，目前hbase的数据表中通常不要超过2～3个列簇。这样能够减少数据的溢出等异常。以下提供两种列簇，一个为用户信息簇，另一个为临床数据簇。用户信息簇userinfo，在用户信息簇内存储有个人信息及流水号索引等信息。这里的流水号索引可为就诊流水号索引等各种索引。临床数据簇，在临床数据簇内存储有挂号数据、诊断信息及住院信息等。利用hive抽取所有来源的数据，对其关联关系进行统一整合后按照以上表的设计存入hbase中。所述hive是基于hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为mapreduce任务进行运行。第三、分布式并行数据处理利用分布式处理引擎实现数据抽取转换加载(extract-transform-load,etl)操作，实时排名，数据校验、异常分析，统计分析以及数据迁移，供未来健康医疗大数据分析和挖掘使用。第四、大数据分析和挖掘在这里的大数据分析和挖掘的处理的是各种医疗数据。在医疗数据整合平台以向用户提供健康服务为目标，基于用户的心电数据、生命体征参数(呼吸、体温、脉搏血压)、行为模式数据(锻炼信息、习惯记录、地理位置)、运动信息(步态信息、睡眠监测数据)等，进行智能分析。主要包括：个性化的健康评估与指导、健康数据分析、医疗数据分析等。数据整合目标：以独立的数据存储和域模型来构建元数据为设计思想，从分布的异构系统中(包括his/emr/lis/pacs/cis以及眼视光中心和社区筛查系统)获取诊断数据信息，费用信息等各种格式的数据集，利用临床规范完成数据的整合以实现数据安全共享、高效访问和灵活分析。数据的整合在三个层次上进行(应用层、api层，数据层)，主要因面对层级不同而变化。在应用层上整合是通过在地域范围的应用上重新应用从个人应用中整合而来。在api层应用开放编程接口，使其他应用可以访问其数据。在数据层整合建立一个通用域模型，让独立开发的应用能够交换信息。这里的通用域模型可包括本地域模型和全局域模型。本框架通过数据模型来表示数据结构，通过接口模型来表示临床知识，实现数据的互操作性，数据的整合可以对不同形式(结构化或非结构化)的健康数据进行整合，数据可以存在不同的数据存储系统中，如关系型数据库，文件服务器，或者以电子健康档案的标准形式、基于通用域模型的约束条件展示应用域的概念属性，数据存储模型定义数据存储的逻辑结构，通过映射在数据源和本地域模型之间建立关系。使用彼此独立的模型来表示数据结构和临床知识，数据模型定义了数据储存的实体，表示数据存储的语义。接口模型表示临床知识和数据存储模型所定义的通用数据的约束条件。示例二：本示例提供一种医疗数据的整合方法，本示例提供的方法可应用于前述提供的医疗数据整合平台上；从数据源接收医疗数据；这里的数据源包括各种电子健康记录设备、his/emr/眼视光中心和社区筛选系统等。在通用域模型的约束下，参照数据模型形成数据本体。这里的数据本体相当于一个基于通用域模型建立的数据表。这里的通用域模型可以为本地域模型，也可以为全局域模型。汇聚多个基于通用域模型建立的数据本体，建立共享本体。基于通用域模型形成的数据本体，并抽象成共享本体的数据处理流程，可以对应于基于本地域模型进行数据清洗转换的数据处理过程，也可以为基于全局域模型进行数据处理的过程。在具体实现时，首先数据源将医疗数据交给本地数据库，本地数据库基于本地域模型进行上述数据处理，在由本地数据库向全局数据库递交数据，基于全局域模型进行数据处理。在图6中所示的医疗数据整合方法中，包括建立数据源与本地域模型、本地域模型与全局域模型及全局域模型分别与数据源之间的映射关系，方便后续数据的查找和定位。在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本
技术领域：
：的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。当前第1页12当前第1页12