商业分析模型四——商业数据图（BDD）与实体关系图（ERD）

读书的时候，每个学期同学们都会收到一份当期的课程表，他们收到课表之后，会根据需要和要求选修一些课程。当课程结束后，每个课程都会设置一次该课程的考试。学期结束的时候，同学们都会收到一份成绩单。

以上“数据关系”需要在概念的层级上进行梳理：

1、一个【课程目录】里面会包含“零或多个”【科目课程表】，这多个科目课程表会仅属于一个课程目录。那么【课程目录】：【科目课程表】就在对应关系上形成了“1...n”的关系；如下图（也可结合上图）理解：

       2、一个【科目课程表】有可能在这学期有多个课程，也有可能只有一个；但是每个【课程】都只属于一个【科目课程表】（对应上图理解下）。那么，【科目课程表】：【课程】的对应关系也是“1...n”。

      3、每个【课程】有可能会被多个学生选修，也有可能没有学员选择学习它；如果从概念上理解的话，【课程】：【学生】就对应成了“0...n”的关系。

       4、每个学生对应科目课程表的关系，有可能选修多门课程，也有可能仅选修一门，或者一门都不选。那么综合一下，【学生】：【科目课程表】在数据上也形成了“0...n”的关系。

5、一个学习结束了，每个人都收到一份当期的学习成绩单。一个学员有且仅有一份属于自己的成绩单，所以【学员】：【成绩单】的对应关系是“1...1”的关系。

       6、在记录和标记的时候，数据对象的对应关系的对比位置需要注意。如上例，如果【课程目录】：【科目课程表】就记录为“1...n”（一个里面有多个）；但如果【科目课程表】：【课程目录】就要记录为“n...1”（多个都属于一个）。 

如上的这些关系在建模语言里面有个统一的叫法，被称之为“基数关系”。基数：是指一个商业数据对象和其他商业数据对象发生关系的次数，以及这种关系是否必需或可选。

那么商业数据对象是指业务或者商业思考和关注的，从商业角度得到解决方案中数据的概念视图；而不是数据库中确切的数据对象。

基数是影响软件架构的最大因素之一。比如说，我们日常的网络购物。对于用户账号有一个送货地址与多个送货地址，软件账号处理能力似乎是一件小事，但是对应用程序和业务流程有巨大的影响。

我们现在把上面的示例变成标准的商业数据图（BDD），如下图：

那么标准的商业数据图（BDD）的样子，如下：

商业数据图（BDD）和实体关系图（ERD）有些相近。下图就是一个ERD的图例。

相较于BDD，ERD多出了两个内容，一是“属性”，另一个是“联系”。“属性”就是把每个“商业数据对象”进行进一步的信息完善；“联系”就是进一步表明两个商业数据对象之间的关联关系。相较于理解“基数关系”，这两个概念并不难理解。

BDD是概念性的数据模型，它是从干系人的角度显示业务数据对象的概念关系。而ERD显示对象在数据库架构中是要实际实现的。

在任何有数据库的项目中都将可能用到BDD，这意味着大多数项目都需要他们。你可能没有必要为解决方案中的每一个对象创建一个BDD，只需要针对商业客户干系人关注的主要业务数据对象创建。

如果项目没有数据库，你很可能不需要使用BDD。

BDD显示关系，但不显示对关系有更多限制的所有业务规则。比如：BDD可以表明一个用户与层面相关，一个课程与层面相关。这里没有显示一个业务规则，客户可以选择他们层面上的课程。

我们可以利用“生态系统图”来确认系统间传输的商业数据对象。可以用“显示-操作-响应模型”（DAR）来确定需要加到BDD的附加商业数据对象。