第14章 数据的详细设计
从软件工程框架上看，数据的详细设计位置的前面有数据概要设计（完成了数据的规划）、上面有功能详细设计（完成了数据的定义），它的工作就是要将在功能设计中产生的数据按照数据规划的要求进行数据层面的设计，给出数据之间的逻辑关系。
14.1 基本概念
14.1.1 定义与作用
1．定义
数据的详细设计，是基于数据的概要设计成果（数据规划和标准）、功能的详细设计成果（字段的定义）等资料对数据进行逻辑层面的设计，给出数据的逻辑关系，包括：数据表关系、算式规则等。
2．作用
从软件工程上数据设计的全过程看，数据的详细设计是对概要设计的数据规划、功能详细设计的业务4件套等成果进行的数据层面的详细设计。
这个环节的作用是从业务视角对数据做最后的设计，它的设计成果是后续数据应用设计的基础，也是技术设计中确定数据库关系的主要依据。从最粗的架构层规划设计开始，到对最细的数据层的细节设计为止，此后从应用设计开始，设计工作的中心就开始向应用和系统方面转移了。数据的设计过程虽然数据是在功能的详细设计（业务4件套）中定义的，但是在功能层的设计时数据是配角，是从“功能”的视角来看“数据”的。到了数据层之后，数据就成为主角，此时关注的焦点是数据，而不再关注数据来自于什么功能或是用什么方式产生的数据了。
14.1.2 内容与能力
1．作业内容
在数据的概要设计中给出了数据的规划，功能的详细设计给出了所有数据的定义，完成了数据层的三元素之一“要素”，因此，在数据的详细设计环节中要给出三元素中的数据“逻辑”，以及表达逻辑关系的“模型”。
数据要素间逻辑关系的表达方式主要有三种：主／外键、数据表以及图形，这三者在逻辑图形上的关联分别为线（键）、结构（表）和规则（图）
1）键（线）键，是赋予每个数据表的具有业务含义的编号，作为该数据表的唯一标识，并以这个业务编号作为连接“键”建立起与其他数据表之间的关联关系，这是建立数据体系的基础条件。
2）表（结构）在功能的详细设计的业务4件套中对所有的数据进行了定义和说明，功能上所有的数据构成了数据表，数据与数据之间的关系形成了“结构”关系。
3）图（关系）除了用键、数据表来表达数据的逻辑关系外，还存在着数据之间由计算公式表达的逻辑关系，表达数据关系的模型有3个。
2．能力要求
数据的详细设计与功能的详细设计的内容一样，都是业务设计师必须要掌握的基础技能，这两个能力是完整地完成业务功能设计（4件套）的必需条件，参考能力如下（不限于此）。
（1）可以看懂业务架构图、功能规划图，掌握功能之间的逻辑关系。
（2）熟练地掌握和理解业务功能规格书（业务4件套），它是数据详细设计的基础。
（3）熟练掌握数据的详细设计方法。
（4）具有一定的数据逻辑、数据库的概念和知识。
14.1.3 思路与理解
业务设计师的工作需要做到什么细度（最小粒度）呢？很多从事业务设计的业务设计师所做的正式设计文档，通常只做到简单的界面布局和控件定义，至于对数据的规划、数据表关系的建立，以及数据规则的制定等内容就不一定作为正式的交付物了（也可能根本就没有做）。这样做的结果就是在业务设计师向技术设计师等交付资料后，技术设计师和开发工程师等还要花费大量的时间与业务设计师沟通，问清楚数据的规划、数据间的关系、数据的来源、算式的规则等，从设计工程化的角度来看，这个做法的效率低、沟通成本高，严格地说，没有完全发掘出业务设计师获得的全部信息，也没有发挥出业务设计师的全部能力，所以业务设计师应该给出数据层面所有业务数据的定义和逻辑关系。业务数据、数据逻辑是对后续信息系统构建时的重要输出，如果业务设计做得到位就会有效地避免开发完成后出现的需求失真、逻辑错误等问题。业务设计师对业务数据进行详细的定义、规划、复杂关系的关联，以及建立模型进行计算等工作都是属于业务设计的工作范畴，这些内容对后续技术开发阶段的数据设计起着非常重要的作用。同时这个部分知识和经验的欠缺，也是造成业务设计人员能力不足的原因之一。
在一个系统中，用哪些维度、方法去描述数据层面的逻辑，如何表现数据之间的逻辑关系，以及如何建模以帮助理解复杂的数据计算，都是业务人员必须要完成的工作，也是资深业务设计师必须要掌握的技能，可以看成是业务设计师必须要掌握的最小限度的数据设计内容，这部分内容如果不主动地向技术工程师提供，在实际的设计过程中业务设计师也不可能躲过这部分工作，进入到了技术设计阶段后，将会被动地要求向后续的技术设计师提供各种零散的信息和资料，因为这些内容只有通过业务设计师才能获得确定。数据设计方面的内容本质上都属于业务设计范畴的知识。
14.2 数据逻辑的概念
14.2.1 数据的逻辑
数据逻辑表达的是数据层数据之间的逻辑关系，这个层的要素是主要是数据表、数据。为什么会出现业务逻辑和数据逻辑两种不同的表达方式呢？因为两种逻辑出现在不同的层面上，要素的目的不同、粒度不同、要素间的相互作用方式不同，因此要素之间的逻辑表达方法就不同，前面见过了架构层的逻辑图、功能层的界面表达方式，那么数据层的逻辑表达方式是什么样呢？数据的表现形式也很多，从“业务的视角”给出数据设计的方法（而不是从技术实现的视角，如数据库的设计方法、要求等），虽然两者的视角、方法是不一样的，但是它们的逻辑是通的。
1．架构层的逻辑表达方式
在组合原理中已经说明过了，业务架构图的逻辑的表达形式有三种，即关联、位置、包含。由于这种逻辑表达是客户的业务事理，这种逻辑的表达方式更加接近于用户的工作习惯，与用户业务的实际运行形式非常接近，所以，所有与系统开发相关的干系人（系统用户、需求、业务／应用／技术设计、编程、测试等）都容易理解。
2．数据层的逻辑表达方式
数据层用逻辑关系图的要素是数据表、数据，用数据逻辑表达也同样采用了三种方式，三种数据逻辑表达方式为：键（线）、表（结构）、图（规则）
（1）键：是用数据表的业务编号，作为连接数据表、数据之间的关系。
（2）表：指的是数据表，用表格结构表达出数据之间的上下、父子、从属等的关系。
（3）图：用各类逻辑图的形式，给出数据之间的关联关系，如算式图、数据线、勾稽图。
与架构图表达的最小粒度是两个功能之间的逻辑关系相比较，数据层表达的最小粒度是两个数据之间的逻辑关系。数据的逻辑表达是一种系统设计特有的表达形式，客户不一定能够理解（也不必理解），它对于技术设计师来说是基础知识，为了向技术设计师提供精确无误的设计资料，所以业务设计师必须要掌握数据的逻辑表达方式。
14.2.2 逻辑的目的
通过需求工程收集需求、概要设计完成从架构、功能到数据的规划，再经过功能的详细设计，收集到了全部的数据并在业务4件套中对每个字段进行了详细定义，全部的业务设计就剩下最后的一步，即设计数据间的逻辑以及表达逻辑的模型。首先说明一下数据的详细设计与上游各个设计环节之间的关系。
①通过业务架构图，获取了功能之间的业务逻辑（主要是功能之间的业务关联关系）。
②给出数据表的规划，也包括数据表间粗粒度的关系（因此时尚无具体数据）。
③通过业务4件套，给出了数据的定义（但此时重点不在数据间的关系）。
④基于①②③的内容，建立数据之间的数据逻辑关系（主／外键、数据表、关系图）。
⑤承接④的结果，进行后续的数据库设计（属于技术范畴）。
14.3 数据逻辑1——键
数据的载体是数据表，建立数据之间的逻辑关系首先要建立数据表之间的关系，而数据表之间的关系是用“键”进行关联的。
14.3.1 键的设计
1．定义
（1）键：对两组或以上的数据之间进行关联的关键数据。这个关键数据通常采用具有业务含义的业务编号或是无含义的自动编号。
（2）业务编号：是为保证每个数据表在系统中都是唯一的而建立的识别编号。因为这个编号的构成中带有业务含义，因此称之为业务编号，它是后续建立数据逻辑关系的基础。有了编号，有利于在系统中进行识别、关联、查询等操作。
2．编号的基本构成
业务编号的编制有两部分的工作，一是赋予编号名称，二是设计编号的业务内容构成。
1）编号名称编号的基本规则，通常采用“业务功能的名称”+“编号”的形式构成，因此才称之为业务编号
2）编号构成可以采用分段合成的方式，表达不同的业务含义
3）记录地点业务编号记录在“功能的详细设计——业务4件套”中，通常将业务编号作为控件定义表的第一个字段，放在控件定义模板中的第一行。
4）业务编号与数据库的主键区别这个数据表的“业务编号”与数据库的“主键”在本质上是一样的，都是作为数据表的唯一识别ID，但是一般来说，数据库的主键是没有业务含义的，它是由系统自动发布的。这里之所以采用有业务含义的业务编号主要是有以下两个目的。
（1）目的一：业务编号是快速检索的重要手段。
（2）目的二：可以让业务设计师理解数据、数据表之间的关系是如何建立的。至于在系统设计中是否采用业务编号的形式作数据表的键，取决于系统的整体规划、架构，包括业务设计和技术设计两方面的考虑，由业务设计师和技术设计师共同协商决定。
3．编号的组合方法
考虑到系统运行后会经常地发生变化，为了获得系统的应变能力，业务编号的构成应尽量采用组合方式，而不是将大量的信息融入到一个业务编码中，在一个编号中加入了太多的信息，一旦这个编号由于需求发生变化时，就会造成与这个编号相关联的信息的变动，这样编号的方式减弱了系统的应变能力，在后期系统发生需求变化时会带来系统改变的难度。因此，在设计带有复数信息的业务编码时，可以采用“主编号+属性”的方式来分散长编号的风险。
（1）主编号：代表不易发生变化部分的编号。
（2）属性：容易发生变化的部分，采用复数的独立属性编号。当部门、工作或是产品的分类容易发生变化时，可以将它们与主编号分离开来，进行组合，而不是做出一个编号，这样无论有多少变化的部分，都可以通过不断地附加属性编号解决，而不必改动主编号。
4．编号的发布方式
编号的发布方式基本上有两种：自动发布、手动发布。
1）自动发布设定一个基础编号的构成格式后，按照编号的构成格式自动增长。其优点是：编号由系统自动地按照增量规定增长，这样的编号利于检索、易排序，不会出现主键乱码或是重复的问题。其不足之处在于需要手动插入指定编号时很麻烦，例如，需要导入部分数据或是与其他系统进行集成时。另外，虽然数据库也可以自动发号，但是编号没有业务含义和规律，不能用来快速查询。
2）手动发布可以任意插入，但管理比较麻烦，且处理不好容易引起插入前后数据的混乱。
14.3.2 主键／外键
在系统中会有很多的数据表存在，这些数据表之间会发生互动，例如相互之间对数据进行参照、引用、复制等，为了实现这个互动，就必须让每个数据表都有一个唯一的标识，这个标识就称为数据表的“键”，用业务编号作为数据表的键就是其中一个代表性的做法。每个键都有两个作用：对本表是主键，对外表是外键，即每个数据表可以有两类键。
注：关于“参照、引用和复制”的区别
（1）参照：将上游功能的部分数据显示在本功能的界面上（但不保存在本功能上）。
（2）引用：本功能的计算中采用了上游功能的数据。
（3）复制：将上游功能中的部分数据复制到本功能的数据表上并保存。
1．主键
主键，是本数据表的代表名称，一个数据表里只能有一个主键。
一个数据表只能有一个主键，指的是一列或多列的组合，其值是能唯一地标识表中的每一行，通过它可强制数据表的完整性。它用于与其他表的关联，以及本记录的修改与删除等。
2．外键
外键，当一个表中除了本表的主键外，还保存了其他数据表的主键时，那么在本表中其他数据表的主键就被称为“外键”。根据参照外部数据表的数量多少，一个数据表中可以有复数的外键。
当然，主／外键是相对的，本表中的主键，在其他表看来也是外键。
14.3.3 键的应用
业务编号做成的“键”，不但可以用于关联数据、数据表之间的关系，还可以在用图形做业务设计中表达数据之间的逻辑关系。
1．数据I/O图
在功能的详细设计——业务4件套中的“控件定义”中，在数据源一栏里说明了数据的来源，但是当数据非常多，业务设计师可能对全体也不是把握得很清楚时，往往会出现数据来源的指定错误，此时采用“数据I/O图”，可以帮助业务设计师梳理清楚数据的来龙去脉。
通过数据的I/O图，可以帮助业务设计师建立一个数据来源与去处的模型，梳理数据来源多、关系复杂的功能内部数据关系，这个图完成后可以放到业务4件套的第4个模板——逻辑图形内，它可以帮助技术设计师或是编程工程师理解业务4件套——控件定义中“数据源”的数据关系。
2．业务编号架构
每个数据表都有一个唯一的编号，通过对数据表的编号设计，可以用编号之间关系进行业务过程分析，编号采用组合的形式：主编号+子编号的形式，即每个功能有一个主编号，每个主编号的下面设置子编号。
3．数据表关系
在前面的各个设计阶段中业务设计师完成了对数据不同的设计，为后续技术设计时的数据架构工作奠定了基础，技术设计师就可以参考业务设计师的数据设计结果，利用主／外键建立起全部数据之间的关系。
14.3.4 键的区别
业务设计中提到具有业务含义的“键”与技术设计数据库时定义的“键”是有区别的。
1．业务编码作为主键（业务设计）
可以用于对系统中不同输入记录的查询，例如，各类原始凭证的输入，利用业务编码查询可以做到一步查到，如果使用过滤部门、担当、时间、产品等条件的方法会非常耗时。用业务编号作主外键可以帮助业务设计师理解、分析、设计数据之间的逻辑关系。
2．数据库自动发布的键（技术设计）
技术设计师在设计数据库的表关系时，会使用数据库自动发布的主键，这个主键没有任何的业务含义，由于对外不显示，所以也不能用来进行查询，这两套键没有对应关系。
14.4 数据逻辑2——表
建立了“键”的概念之后，就可以利用“键”来建立数据表之间的关系了。
14.4.1 表的概念
1．数据表定义
数据表，是按照一定的结构形式排列的数据格式，任何数据的载体都是数据表。
用“格式”描述数据表的形式，格式包括数据结构、数字分类、数据状态三类内容。
（1）数据结构：列表结构、树状结构。
（2）数字分类：数值、货币、文本、日期、分数等。
（3）数据状态：表达在导入上游功能的数据时，该功能所处的状态，例如，编辑期限已过、功能被锁定、审批已完成、数据已被引用等。
2．数据表的作用
为什么需要有数据表的规格呢？在业务流程上处于上下游关系的活动之间，如果进行数据的复制时，不但要确认上下游活动的数据属性是否一致，还要确认上下游活动实体的数据结构是否一致，如果不一致就不能复制。同样，不在流程上的功能之间复制数据时也存在着同样的要求。因此，在研究具有数据复制关系的活动时，首先要了解各个活动的“数据结构”是否需要一致（是否需要一致是根据业务逻辑判断的，并非都需要一致）。
14.4.2 数据结构
数据结构，表达了一组数据间逻辑关系的结构形式。在业务设计中常用到两种数据的结构形式：列表结构和树状结构。
（1）列表结构：排列成线形，多条数据间无关联，简称为“列表”。
（2）树状结构：数据间存在“父子”关系，简称为“树状”。父子关系是相对的，例如，对于上级“黑色金属”来说“钢材”是“子”，但相对于下层来说“钢材”又处于“父”的位置。父子结构可以有多少层没有规定，视客户的需求而定，分层多，则管理细，但操作效率低；分层少，管理粗，但操作效率高。可以看出，在设计功能的原型界面时，一个界面呈现什么样的形式、一个界面由几种类型的细表构成等，都是根据数据结构来决定的。
14.4.3 数字分类
在业务设计中按照数据特征被划分为两种类型：数字型数据和文字型数据。其中，对数字型数据的内容还可以再进行细化分类。
（1）数字型数据：虽然都使用了“数字”，但是表达了不同的含义，这类内容都可以参与计算。
（2）文字型数据：包含中文、外文等，类型为汉字、字母等，这种类型不能参与计算。
注：本表的分类方式引用了Excel中提供的数字分类形式。
14.4.4 数据状态
数据从上游活动传递给下游活动时，不仅带过来了数据结构、数字分类等，同时还带过来了一个非常重要的信息：传递过来的数据在上游功能中受到了什么规则的约束。这些规则表达的就是数据状态，描述数据状态的内容如下（不限于此）。
（1）规则：原数据遵守了哪些业务标准、管控规则，这些标准和规则是否要延续？例如，在上游活动处理时是否遵守了期限约束，如财务、工期、合同等。
（2）完成：上游活动中的业务处理是否全部完成（提交），没完成的数据不可使用（仅供参考）。
（3）锁定：上游活动的界面是否受到系统的锁定，如果锁定，则数据不可编辑等信息。处于下游的活动受制于上游活动的信息，上游的数据及状态影响本活动中数据的处理内容和方式。
14.4.5 表的案例
复杂系统决定界面形式时，除考虑本原型内的数据构成外，还需要考虑数据输入上、下游节点的需求，有可能本原型的形式是由上游或下游原型的要求决定的。所以，在进行功能的界面设计时，界面形式的确定一定要参考数据结构的要求。
14.4.6 表的区别（业务与技术）
这里讨论的数据表、数据结构等概念是为了完成对业务的分析与设计而引入的，它们与技术的数据库表设计方法和表达方式不完全一样，但概念是相似的。因此，按照业务设计完成的数据表设计资料在技术设计阶段也是可以被继承的。
（1）业务设计的数据表是来源于业务功能的设计（业务4件套），业务功能上只表示出了业务数据（客户所需要的数据），没有系统功能相关的数据。
（2）在技术设计阶段所做的数据库用数据表上，除了业务数据之外，还存在着有很多技术实现所需要的辅助数据，例如，数据的属性、处理状态的属性等，这些数据与客户的业务无直接关系，完全是技术实现时需要的，所以数据库的数据表要大于业务的数据表。
业务设计师可以忽略技术设计时增加的属性数据，只需关注有业务数据的数据表即可。作为业务设计环节，业务的数据表符合业务逻辑，不关注技术的实现方式，技术设计的数据表为了易于实现可能与业务设计的数据表不一致，但只要实现的结果与业务设计的要求相同就可以了。这也是软件设计不同于其他制造建筑行业设计的特点，例如房屋的设计，建筑外表和应用部分的设计与内部结构的形态要完全一致，否则无法建设。但是软件设计就不同了，往往业务设计的成果仅仅为技术实现提供了逻辑依据，但是实际的技术设计与业务设计的图形并不一致，而且越是可以灵活应用的系统设计，两者之间在图形表达上的差距就越大。
14.5 数据逻辑3——图
有了“键”和“表”的概念，下面就可以去解决复杂算式的表达了，因为复杂算式中的数据是通过“键”关联了来自于不同数据“表”的数据。复杂算式模型（图）表达的也是一种数据之间的逻辑关系，这类模型对理解和传递数据间的复杂逻辑关系具有很好的表达能力。
14.5.1 复杂算式的概念
在业务分析过程中会产生很多数据，有些数据可以直接使用，有些需要进行简单的计算就可以使用，但是还有不少需要通过多重的引用和计算后才能使用。后者由于数据来源复杂、影响要素多所以很难用语言、表格等方式表达，这就需要有一套方法可以有规律地、结构化地传递设计的想法，这里要讲的复杂算式指的不仅是计算公式“＋、－、×、÷”的多重使用，而是包括建模的路线、数据的来源、逻辑关系等内容的综合使用。
● 根据设计目的，如何快速地找到合适的表达模型？
● 哪些数据参与了计算？计算数据从哪里来？
● 如何表达算式的逻辑关系？等等。
三种模型各自的特点如下。
（1）算式关联图：对于“点”的复杂处理（包括两种场景：数据计算、数据匹配）。
（2）数据勾稽图：用于“面”的复杂处理（用图的尺寸表达比例关系）。
（3）业务数据线：用于“线”的复杂处理（用数据连成虚拟“线”）。
14.5.2 算式关联图1——计算用
1．算式的基本构成
计算用的算式关联图的应用场景是：在某个“节点”上有多个数据来源的汇总、计算。这个计算可以是活动、看板或报表中的某个处理步骤，这个计算涉及复杂的数据来源、引用、关联及多重的计算。算式关联图的模型中包括两大部分：数据的来源和数据的处理。
假定在某个业务流程上的B节点①中有一个计算处理（成本核算，见数据的处理中间图标），这个计算需要有多个外部的数据来源共同参与。
2．数据来源
数据来源，是用来说明包含计算功能的位置，以及其他参与计算的数据来源。
3．数据处理
数据处理，是建立数据表的计算处理模型，以下各类要素（数据表、数据、数据库、计算处理等）必须要使用指定图标表示
可以看出，算式关联图实际上就是一个为解决某个特定问题而建立的用例图。
4．算式的设计原则
1）模型清晰每个模型一定要有一个明确的计算目标，不可在一个模型中加入过多的目标，如果目标多，为了保证计算的路径清晰，可以将它们拆分为若干个小模型，分别计算出各个目标值。要特别标注出算式的载体，其余的表等都是作为算式的数据资源。
2）模型的规律性因为模型要表达的应该是一个可以反复运行的“机制”，所以要从模型中可以看出计算过程的规律性，这个规律性对后续的技术建模起着很大的启发作用（用于功能的复用）。
3）图标的统一采用了标准的画法表达后，无论多么复杂的内容都会比较容易地且清晰地表达出来。由于是工程化的设计图，所以整个设计过程都必须要采用标准的图标、规范的标识方法，否则就无法达到工程化的设计效果，由于这些图形中传递的是“逻辑”，而逻辑的表达如果出现了各种各样的表达方式，则资料的继承者就难以从图中直接读取业务设计师想要传递的“逻辑”，他需要先去理解各类图标的含义，这样采用工程化图形表达的价值就大打折扣了。因此，采用统一的标准图标表示是非常重要的原则，这也是设计工程化的最基本要求。
4）数值的标注在数据的处理图中，数据表内必须要填写入实际的数据名称和数值。
5）业务流程的表示
由于数据的来源图的重点是表示数据来源的背景，所以当业务流程的节点比较多、流程比较长的时候，可以只画出流程中参与计算的节点，不参与计算的节点可以省略。
6）活动、数据的表示区别
这两者在图中的标注是不一样的。
（1）活动在背景流程上出现，活动的下方要标注活动中参与计算的表名称。
（2）在数据处理区域中，只给出表的名称不要活动名称，如果活动上只有一个数据表，则活动名称与表名称一致，当不止一个表时，只需标出参与计算的表名称。
（3）数据库由于是公用的，并不属于某个业务功能独有，因此不需要标出数据库的来源。
5．算式的使用场景
1）算式的载体
算式关联图可以使用在以下两个场景：有原型作载体、无原型作载体。
（1）有原型作载体。用原型作为载体，通常是某个业务功能中的计算。
（2）无原型作载体。通常是发生在数据加工过程中的某个环节上，此时没有原型作载体（是在后台运行的）。
2）业务的场景
算式关联图一般用于计算跨业务功能之间的场景计算，关联图绘制完成后，为了查看方便，通常将关联图粘贴在“业务4件套——逻辑图形”的模板上。
6．连续算式的表达方式
有一些复杂处理需要的计算不可能一步完成，通常需要经过若干次的计算才能完成，对这样的复杂计算对象需要进行拆分，然后用算式关联图模型进行数次串联计算，这样就化解了复杂对象。
可以看出，无论是多么复杂的计算，如果拆分成为若干个简单、标准的算式关联模型后，就变成了一系列的简单计算。
如果类似的多重计算不用图形表达，很难说清楚逻辑关系、计算路径，但如果使用了算式关联图，则计算过程就变得非常简单，而且易于沟通、调整，特别是后期需求发生变化时。使用了图形表达方式，就没有传统意义上的复杂计算了（因为无论是多么复杂的计算，只要拆分的粒度足够细，拆分后的计算都是简单计算）。
14.5.3 算式关联图2——匹配用
1．算式的用途
计算用算式关联图是用来做“数据计算”的模型，还可以利用此图表达“数据匹配”的模型，数据匹配的处理可以是文字或是数字，数据来源提供的是“文字”，则匹配的输出结果是文字，给出的是数字，则匹配处理的结果是数字。这种处理方式对技术设计师来说就是“查询”处理，通常就是给出几个数据作为查询条件，然后将这些数据与基础数据库、历史过程数据库内的数据进行对比，匹配出合适的结果。通常业务设计师们可能都认为，做匹配（或称之为查询）的设计工作应该是技术设计师的工作，究竟匹配设计是业务设计师的工作还是技术设计师的工作，判断的主要依据之一是看这个设计的成果是由谁来使用。如果设计成果是从事业务处理的用户使用，则它首先是业务设计师的工作；如果设计成果是客户信息中心的用户进行系统维护用的，则有可能不需要业务设计师设计而直接由技术设计师来完成。这里仅讨论由业务处理的用户使用的匹配设计，内容说明有哪些可以匹配的对象。
● 匹配例1：按照部门、销售员、产品线等区分，设计出销售成绩排名的匹配条件。
● 匹配例2：利用电商平台，设计查询某类产品有无的共同筛选条件。
● 匹配例3：针对销售数据，设计某类产品的销售额与地域分布的关联关系，等等。
为什么将这类内容的处理包括在业务设计中呢？可以看出，虽然匹配设计的内容都是在做查询工作，但是涉及的内容都属于业务设计的范畴，不懂客户需求、不懂业务设计方法是难以设计出来的，能够匹配出来结果是因为预先将查询条件设计好了，而这个查询条件就是业务设计师设计的，因此，在设计阶段的匹配设计本身不是一个技术问题。
2．算式的基本构成
1）数据来源
（1）如果仅有一个发起查询的活动，可以不画数据的来源图。
（2）基础数据和过程数据的来源表达方式与计算用模型相同。
3．算式的设计原则
数据匹配用和数据计算用的算式表达基本要求是一样的。
4．算式的使用场景
凡属于“条件→查询→匹配→结果”这样的行为，都属于匹配模型的适用范围，例如：
● 产品匹配：给出查询产品的条件，查询仓库（电商平台）是否有匹配的产品。
● 岗位匹配：给出工程需要的知识、技能等条件，查询是否存在有与条件相匹配的员工。
● 产值查询：在历史数据库中，查询某个时间段、某个部门、某个产品的销售额。
5．连续匹配的算式表达方式
如同复杂的计算场景一样，复杂的查询作业也是存在的，查询的过程也是需要一层一层地进行，此时业务需要采用多重匹配的专业方式，做法参照计算的多重模型。
14.5.4 数据勾稽图
1．勾稽图的基本构成
数据勾稽图，它的应用场景是对某个总数，从它的初始数据形态开始，经过多个阶段的不同处理后，这个总数由初始形态转变为其他形态的计算过程。这类数据勾稽图的绘制是基于“总量不变原则”。
2．勾稽图的作用
1）数据的计算勾稽图，主要用于解决总量和分量间有勾稽关系的计算。
2）数据的管控
在对生产过程进行管理时，经常会采用数据的“对比”方式来检查过程数据是否超过目标数据或是预算数据，如果超过就要采取措施。
14.5.5 业务数据线
1．数据线的基本构成
数据线，是针对某类业务设计目标，将系统中所有与该目标相关的数据按照生成的顺序、数据之间的关系，串联成为一条虚拟的线，这条线就称为××业务的“数据线”，如成本数据线、物资数据线、资金数据线等。
2．数据线的作用
1）数据的计算理解数据线的作用，可以从确立了计算目标后，建立模型的顺序看出来，一般有以下两种做法。
做法一：先检查有哪些数据可以支持做该目标的计算，根据已有的数据建立计算模型。
做法二：先建计算模型，后寻找相关的数据
2）数据的管控数据线的另一个重要作用就是管控的设计。
14.5.6 三种数据模型的关系
三种数据模型之间存在着关联关系。
1．算式关联图
它是对某个点的计算，可以作为数据线上某个节点的计算模型。
2．数据勾稽图
它可以利用数据线的节点之间的数据关系，建立勾稽模型。
3．业务数据线
它可利用算式关联图计算数据输入值，也可利用数据勾稽图计算输出结果。
小结：
采用了图形模型作为辅助计算的工具，不论什么样的复杂逻辑关系都可以比较简洁地说明、传递、检验。当然，如果通过反复设计找到了模型的规律后，为了提升设计效率，采用表格的方式替代图形也是可以的。这里为了说明概念、原理、方法等，都采用图形的方式进行表达（图形可以让“逻辑关系”直接显示出来，容易理解）。
14.6 多角度理解数据逻辑
14.6.1 逻辑的不同表达：架构层与数据层
在业务设计中，因为架构层与数据层的要素、目的、设计方法不同，因此各自的逻辑表达方式也是不同的
1．架构的逻辑表达方式架构的逻辑是采用业务架构图来表达的，架构图中的要素是业务功能，粒度从系统到功能，要素之间不显示数据粒度的内容，模型采用的是业务架构图。架构的逻辑依据来自于企业运行的业务事理，架构图中的逻辑主要是采用了“关联、位置、包含”的表达形式。
2．数据的逻辑表达方式数据的逻辑是采用数据关系图和表的方式来表达的，数据关系图和表中的要素是数据，粒度从表到数据，要素之间是用“键”关联的，模型采用的是数据关系图。数据的逻辑依据是基于架构逻辑的基础上，再加入数据特有的表达方式，包括键、表、式。架构逻辑和数据逻辑都是业务逻辑在不同层的表达方式，架构逻辑比数据逻辑高一层，数据逻辑要遵守架构逻辑的原则。
14.6.2 业务与技术的逻辑表达
业务设计阶段中用来表达数据关系的键、表和图等都是为了获得数据的业务逻辑，不是直接用于技术设计（数据库）的，因为直接采用技术设计的表达方法难以获得和充分传递业务逻辑。
在技术设计阶段表达数据的关系时，已经去掉了业务逻辑的信息，而只剩下了最终数据间的关联结果，之所以可以去掉业务逻辑信息，是因为业务设计阶段提供了业务逻辑，并依靠着这些业务逻辑的指引获得了数据之间的最终关系，所以技术设计师在设计数据库时才不必重复这些信息，只需表达最终结果就可以了（因为最终的数据库中是不需要这些业务逻辑的）。
业务设计阶段的最终成果是为技术设计阶段的设计提供支持的。
小结
数据的详细设计，是在数据的概要设计获得的数据规划、功能的详细设计获得的数据定义之后，对数据进行的细节设计，重点是表达数据层的数据逻辑关系。通过建立数据逻辑关系的表达方法（键、表、式），使得业务设计师有了应对在业务设计阶段中出现的任何数据层面细节设计的方法。
数据的详细设计完成之后，从业务视角给出了架构、功能、数据三个层面的完整设计结果。对于很多业务设计师来说，对数据层面的分析和设计工作可能做的相对比较少，使得从事业务分析和设计可以理解到，对数据层面的设计不但是必须要掌握的，而且是业务设计师可以发挥出巨大价值的地方，特别是对数据表间的关系、复杂算式的表达，这些内容的精细化设计和表达，都会为后续的设计提供坚实的依据，是保证系统开发质量、提升客户满意度的重要内容。可以看出数据设计中所用的模型、数据之间的逻辑表达等都是与业务架构和业务逻辑的表达不同的，这些作业内容也确实不是技术设计师所做的数据库方面的设计工作，在进行这些数据的设计时是需要有业务知识做支持的。
（a）为业务架构中的架构模型与逻辑表达方式，图中节点为：系统、功能等。
（b）为数据设计中的模型及逻辑表达方式，图中节点为：数据表、数据。
用图形表达数据的计算
因为设计工程化带来了设计资料表达的“标准化、图形化”，原来认为很麻烦的事用图形化的方法轻松地就解决了。同时，用图形表达的设计资料，在出现歧义的沟通时，其效率也远高于用文字的设计资料。
网友评论