技术领域
[0001] 本
发明涉及一种电动汽车模型设计方法。
背景技术
[0002] 当前，电动汽车系统没有一套完整的可纵向贯通全业务系统的企业级数据模型，我们要依据SG-CIM模型设计标准，结合电动汽车的现有系统，建立一个属于电动汽车的企业级数据模型，解决目前公司横向业务协同面临的突出问题，以
支撑当前公司重点业务以及纵向业务数据贯通为重点，开展模型设计工作。最终会通过多家省(市)公司综合试点示范应用，
迭代完善模型设计成果，提升模型可用性。具有良好的
可持续性，可根据业务需要进行扩展，不出现体系性的重大颠覆，模型设计可以保证业务系统持续稳定运行、业务共享及数据融合。
[0003] 但现有的技术存在如下缺点：
[0004] 1、无法实现横向业务协同，使系统孤立于国网同一系统之外，对数据交互以及信息传递造成一定影响。
[0005] 2、没有按照统一的模型设计标准进行模型设计，交互的数据标准不一致，导致数据传输交互困难。
[0006] 3、模型可持续性不足，无法支撑业务不断拓展增加的新需求。
发明内容
[0007] 本发明的目的是提供一种电动汽车模型设计方法，该方法依照SG-CIM统一数据模型设计规范及设计方法进行模型设计工作，保障数据标准统一，从根本上保证系统之间数据的兼容性和一致性，消除由于各应用系统自行设计开发而导致的数据分散重复、口径不一致和信息
孤岛现象。
[0008] 为解决上述技术问题，本发明提供一种电动汽车模型设计方法，包括以下步骤：
[0009] S1：映射关系设计：按照业务需求模型采集业务需求数据，结合电动汽车原数据模型按照业务数据模板从采集到的业务需求数据中提取核心业务数据对象，构建业务需求与核心业务系统数据对象之间的映射关系，并将映射结果保存到电动汽车核心业务数据对象梳理模板中，同时将不能映射的数据项作为电动汽车核心业务数据对象梳理模板的待扩充完善需求；
[0010] S2：模型完善设计：根据S1步骤中分析出的待扩充完善需求，按照SG-CIM建模方法论对电动汽车核心业务数据对象梳理模板进行扩展，完善核心业务数据对象，并将完善后的信息补充到电动汽车核心业务数据对象梳理模板中；
[0011] S3：模型整合设计：基于步骤S2得到的电动汽车核心业务数据对象梳理模板，结合电动汽车核心业务对象清单中的跨专业数据对象进行分析，将电动汽车核心业务数据对象梳理模板进行规范、统一定义、去重、归并、整合、拆分，形成电动汽车设计模型；
[0012] S4：逻辑模型设计：
抽取电动汽车设计模型中核心业务数据对象的实体类、属性和映射关系构，将实体类和属性转换为逻辑模型的数据表和字段，结合业务应用需求进行优化设计；根据源端业务系统典型设计，完成和数据模型的映射关系梳理；针对跨专业和多业务部
门共同维护的业务数据，确定唯一数据源头、必要的编码规则以及责任主体；
[0013] S5：物理模型设计：所述物理模型设计包括确定所属范式、关系模式的改进、确定表和字段名称的命名规范和确定表字段的字段类型和对应标准代码。
[0014] 进一步地，所述步骤S1具体包括：
[0015] S11：业务需求收集：根据业务需求模板，针对公司企业级端到端业务流程、跨专业业务融合等实际业务需求，开展需求收集工作，明确数据需求涉及的业务系统、数据频度、数据表以及业务需求部门信息；
[0016] S12：业务系统数据字典收集梳理：针对电动汽车业务系统数据字典收集梳理工作；其中，数据字典梳理工作以国网电动汽车业务系统为主，由涉及业务系统建设厂商完成从在运业务系统中导出数据字典信息，同时完成表、字段及关联关系业务描述信息的补充完善工作；
[0017] S13：核心业务数据对象梳理：基于结合电动汽车业务系统，结合采集到的业务需求数据，开展核心业务数据对象梳理，确定数据实体唯一性，统一数据属性含义及名称，并形成详尽的数据项名称、属性及关联关系，填充至电动汽车核心业务数据对象梳理模板中，同时结合现有业务系统数据字典，对核心业务数据对象进行补充完善，实现核心业务数据对象的全面
覆盖；
[0018] S14：业务信息梳理：基于电动汽车原业务系统，建立业务流程、业务环节与业务数据项的对应关系，填充至核心业务数据对象梳理模板中；
[0019] S15：集成数据信息梳理：根据梳理出的核心业务数据对象信息，分析、
定位提取出本领域产生的数据和非本领域产生的数据，并标示出数据项来源，填充至核心业务数据对象梳理模板中。
[0020] 进一步地，所述步骤S2的设计原则具体为：
[0021] a、IEC标准中已覆盖，直接引用IEC标准模型；
[0022] b、IEC标准不完全覆盖的，按照模型设计规范，扩充完善模型属性；
[0023] c、针对IEC标准未覆盖的，按照SG-CIM建模方法，新增模型实体。
[0024] 进一步地，所述步骤S3具体包括：
[0025] S31：根据数据模型设计规范统一模型设计的标准；
[0026] S32：统一电动汽车模型中与其他模型相同的实体定义；
[0027] S33：排除含义近似或相同，命名不同的实体，以防模型设计时出现含义混淆的情况；
[0028] S34：规划合并或拆分部分实体，以便模型设计时实体的取用。
[0029] 进一步地，所述步骤S4中所述采用的模型映射转换方法包括：
[0030] a、类与表的映射
[0031] 一般类转换为
数据库中的表，类的名称就是表的名称；继承类的父类不转换为数据库中的表，父类属性下落到子类；
[0032] b、属性与字段的映射
[0033] 在映射成数据库过程中，将实体的属性一一映射成数据库表中的字段，将具有复合特征的属性拆分成多个属性并分别映射成相应字段；
[0034] c：类与类间关系的映射
[0035] 一对一：
[0036] 对于[1-0..1]关系，将1端的表中主键放在0..1端的表中作外键；对于[0..1-0..1]关系，原则上可将任意一端的表中主键放在另一端的表中作外键，具体选择根据业务需求；
[0037] 一对多：
[0038] 对于[0..1-0..*]、[1-0..*]、[0..1-1..*]、[1-1..*]关系，将0..1或1端的表中主键放在0..*或1..*端的表中作外键；
[0039] 多对多：
[0040] 对于[0..*-0..*]、[0..*-1..*]、[1..*-1..*]关系，建立一张中间表，将0..*或1..*端中表的主键放到中间表中，共用两个类表的属性作为主键；
[0041] D：继承关系的映射
[0042] 若父类不映射成数据库物理表，作为将父类固有属性存储在子类映射成数据库物理表中对应的字段。
[0043] 若父类映射成数据库物理表，则父类中属性按属性映射方法映射成相应字段，父类映射物理表与子类映射物理表之间建立一对一关系。
[0044] 进一步地，所述步骤S5具体包括：
[0045] S51：确定所属范式：确定每个关系的所属范式，主要是通过确定数据依赖、消除冗余、确定范式三个步骤完成；
[0046] S52：关系模式的改进：为了考虑查询性能，将两个或多个关联表合并成为一张表；或者是将数据量较大的数据表，结合查询需求的不同，分解为多个子表；
[0047] S53：确定表和字段名称的命名规范：表和字段的名称遵从SG-CIM中实体和属性的命名；
[0048] S54：确定表字段的字段类型和对应标准代码：字段类型应按照
数据库管理系统的要求，在参照SG-CIM的
基础上进行重新定义。
[0049] 进一步地，在步骤S52中：当有若干个关系模式具有相同的主键，并且对这些关系模式的处理主要是查询操作，而且是多关系的查询，则对这些关系模式按照组合使用
频率进行合并，减少联接操作而提高查询效率；
[0050] 进一步地，在步骤S52中：根据应用的不同要求，可以对关系模式进行垂直分解和
水平分解；其中，水平分解是把关系的元组分为若干子集合，定义每个子集合为一个子关系；垂直分解是把关系模式的属性分解为若干子集合，原则上是把经常一起使用的属性分解出来，形成一个子关系模式。
[0051] 本发明的有益效果为：该发明依照SG-CIM统一数据模型设计规范及设计方法进行模型设计工作，保障数据标准统一，从根本上保证系统之间数据的兼容性和一致性，消除由于各应用系统自行设计开发而导致的数据分散重复、口径不一致和信息孤岛现象。并且，该设计方法还业务层面的业务对象模型中规范了业务数据的一致性层面、体现了业务数据之间的关联，由此为营配调等跨业务应用场景的业务集成提供了数模层面的支撑。
具体实施方式
[0052] 一种电动汽车模型设计方法，该设计方法包括以下步骤：
[0053] S1：映射关系设计：按照业务需求模型采集业务需求数据，结合电动汽车原数据模型按照业务数据模板从采集到的业务需求数据中提取核心业务数据对象，构建业务需求与核心业务系统数据对象之间的映射关系，并将映射结果保存到电动汽车核心业务数据对象梳理模板中，同时将不能映射的数据项作为电动汽车核心业务数据对象梳理模板的待扩充完善需求；
[0054] S2：模型完善设计：根据S1步骤中分析出的待扩充完善需求，按照SG-CIM建模方法论对电动汽车核心业务数据对象梳理模板进行扩展，完善核心业务数据对象，并将完善后的信息补充到电动汽车核心业务数据对象梳理模板中；
[0055] S3：模型整合设计：基于步骤S2得到的电动汽车核心业务数据对象梳理模板，结合电动汽车核心业务对象清单中的跨专业数据对象进行分析，将电动汽车核心业务数据对象梳理模板进行规范、统一定义、去重、归并、整合、拆分，形成电动汽车设计模型；
[0056] S4：逻辑模型设计：抽取电动汽车设计模型中核心业务数据对象的实体类、属性和映射关系构，将实体类和属性转换为逻辑模型的数据表和字段，结合业务应用需求进行优化设计；根据源端业务系统典型设计，完成和数据模型的映射关系梳理；针对跨专业和多业务部门共同维护的业务数据，确定唯一数据源头、必要的编码规则以及责任主体；
[0057] S5：物理模型设计：所述物理模型设计包括确定所属范式、关系模式的改进、确定表和字段名称的命名规范和确定表字段的字段类型和对应标准代码。
[0058] 所述步骤S1具体包括：
[0059] S11：业务需求收集：根据业务需求模板，针对公司企业级端到端业务流程、跨专业业务融合等实际业务需求，开展需求收集工作，明确数据需求涉及的业务系统、数据频度、数据表以及业务需求部门信息，为后续核心业务数据对象提取及模型验证提供依据；
[0060] S12：业务系统数据字典收集梳理：针对电动汽车业务系统数据字典收集梳理工作；其中，数据字典梳理工作以国网电动汽车业务系统为主，由涉及业务系统建设厂商完成从在运业务系统中导出数据字典信息，同时完成表、字段及关联关系业务描述信息的补充完善工作；
[0061] S13：核心业务数据对象梳理：基于结合电动汽车业务系统，结合采集到的业务需求数据，开展核心业务数据对象梳理，确定数据实体唯一性，统一数据属性含义及名称，并形成详尽的数据项名称、属性及关联关系，填充至电动汽车核心业务数据对象梳理模板中，同时结合现有业务系统数据字典，对核心业务数据对象进行补充完善，实现核心业务数据对象的全面覆盖；
[0062] S14：业务信息梳理：基于电动汽车原业务系统，建立业务流程、业务环节与业务数据项的对应关系，填充至核心业务数据对象梳理模板中；
[0063] S15：集成数据信息梳理：根据梳理出的核心业务数据对象信息，分析、定位提取出本领域产生的数据和非本领域产生的数据，并标示出数据项来源，填充至核心业务数据对象梳理模板中。
[0064] 所述步骤S2的设计原则具体为：
[0065] a、IEC标准中已覆盖，直接引用IEC标准模型；
[0066] b、IEC标准不完全覆盖的，按照模型设计规范，扩充完善模型属性；
[0067] c、针对IEC标准未覆盖的，按照SG-CIM建模方法，新增模型实体。
[0068] 所述步骤S2的设计方法为：
[0069] a、按照模型待扩充完善需求，将核心业务数据对象补充完善；
[0070] b、将完善后的类、属性、及关系信息补充至核心业务数据对象清单中。
[0071] 所述步骤S3具体包括：
[0072] S31：根据数据模型设计规范统一模型设计的标准；
[0073] S32：统一电动汽车模型中与其他模型相同的实体定义；
[0074] S33：排除含义近似或相同，命名不同的实体，以防模型设计时出现含义混淆的情况；
[0075] S34：规划合并或拆分部分实体，以便模型设计时实体的取用。
[0076] 模型整合设计遵循如下几条原则：
[0077] a、建立映射关系：针对不存在交叉管理的跨专业业务数据对象，结合跨专业业务数据对象的关联关系，相关域间交叉讨论，确定跨域类间的关联关系；
[0078] b、数据表对象拆分和合并：针对不同专业共同管理的相同业务数据对象，第一种设计方式，按照专业管理要求，将该业务数据对象拆分为不同类进行管理；第二种设计方式，将该业务数据对象管理权归属于某一个主题域负责，其他域的属性进行合并。
[0079] 进一步地，所述步骤S4中所述采用的模型映射转换方法包括：
[0080] a、类与表的映射
[0081] 一般类转换为数据库中的表，类的名称就是表的名称；继承类的父类不转换为数据库中的表，父类属性下落到子类；
[0082] b、属性与字段的映射
[0083] 在映射成数据库过程中，将实体的属性一一映射成数据库表中的字段，将具有复合特征的属性拆分成多个属性并分别映射成相应字段；
[0084] c：类与类间关系的映射
[0085] 一对一：
[0086] 对于[1-0..1]关系，将1端的表中主键放在0..1端的表中作外键；对于[0..1-0..1]关系，原则上可将任意一端的表中主键放在另一端的表中作外键，具体选择根据业务需求；
[0087] 一对多：
[0088] 对于[0..1-0..*]、[1-0..*]、[0..1-1..*]、[1-1..*]关系，将0..1或1端的表中主键放在0..*或1..*端的表中作外键；
[0089] 多对多：
[0090] 对于[0..*-0..*]、[0..*-1..*]、[1..*-1..*]关系，建立一张中间表，将0..*或1..*端中表的主键放到中间表中，共用两个类表的属性作为主键；
[0091] D：继承关系的映射
[0092] 若父类不映射成数据库物理表，作为将父类固有属性存储在子类映射成数据库物理表中对应的字段。
[0093] 若父类映射成数据库物理表，则父类中属性按属性映射方法映射成相应字段，父类映射物理表与子类映射物理表之间建立一对一关系。
[0094] 所述步骤S5具体包括：
[0095] S51：确定所属范式：确定每个关系的所属范式，主要是通过确定数据依赖、消除冗余、确定范式三个步骤完成；
[0096] 首先是确定每个关系内的数据依赖。按需求分析阶段所得到的语义，分析每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。
[0097] 再消除数据冗余，主要是对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
[0098] 再确定范式，按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。对于一个具体应用来说，规范化进行到什么程度，需权衡响应时间和潜在问题两者的利弊才能决定。并不是规范化程度越高的关系越优，一般情况，第三范式就足够。例如：当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行联接运算，而联系运算的代价是相当高的，这样关系模型低效的主要原因就是做联接运算引起的。
[0099] 如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF[0100] 若R∈1NF，且每个非主属性完全依赖于码，则称R∈2NF。
[0101] 关系模式R中，若不存在这样的码X，属性组Y及非主属性Z(ZY)，使得下式成立，
[0102] X→Y,Y→Z,Y→X则称R∈3NF。
[0103] S52：关系模式的改进：若逻辑模型设计未覆盖全部业务对象，导致某些应用不能得到支持，可结合需求分析结果，增加新的关系模式或属性；为了考虑查询性能，可将两个或多个关联表合并成为一张表，将数据量较大的数据表，结合查询需求的不同，分解为多个子表；
[0104] 合并：如果有若干个关系模式具有相同的主键，并且对这些关系模式的处理主要是查询操作，而且经常是多关系的查询，那么可对这些关系模式按照组合使用频率进行合并，减少联接操作而提高查询效率。
[0105] 分解：为了提高数据操作的效率和存储空间的利用率，最常用和最重要的模式优化方法就是分解，根据应用的不同要求，可以对关系模式进行垂直分解和水平分解。水平分解是把关系的元组分为若干子集合，定义每个子集合为一个子关系。将用户表分解为高压用户表和低压用户表；垂直分解是把关系模式的属性分解为若干子集合，原则上是把经常一起使用的属性分解出来，形成一个子关系模式。
[0106] S53：确定表和字段名称的命名规范：表和字段的名称应遵从SG-CIM中实体和属性的命名；其基本原则如下：
[0107] 字段完全遵从SG-CIM中实体属性的命名
[0108] 表的名称单个单词时完全遵从SG-CIM,多个单词组合时每个单词之间增加“_”不能超过40位，超过长度采用单词缩写
[0109] S54：确定表字段的字段类型和对应标准代码：字段类型应按照数据库管理系统的要求，在参照SG-CIM的基础上进行重新定义；其基本原则：
[0110] 字段属性，参照SG-CIM的基础上，结合具体数据库管理系统的要求重新定义；
[0111] SG-CIM中是聚合类型的属性，需要将对应表的字段定义为标准代码；
[0112] 表的字段是固定编码是，字段长度需要参考标准编码的定义要求等。
[0113] 最后说明的是，以上
实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行
修改或者等同替换，而不脱离本发明技术方案的宗旨和范围，其均应涵盖在本发明的
权利要求范围当中。
