Get best of the week

ERP数据库系统的非规范化及其对软件开发的影响：在Tortuga上开设一家小酒馆

你好！我叫Andrey Semenov，我是Sportmaster的高级分析师。在这篇文章中，我想提出ERP数据库系统的非规范化问题。我们将考虑一般条件以及一个特定示例-假设它将成为海盗和水手的绝妙垄断小酒馆。需要为海盗和水手提供不同的服务，因为关于这些好主人的美丽和消费模式的想法有很大不同。

如何使每个人开心？如何不疯狂设计和维护这样的系统？如果不仅熟悉的海盗和水手开始来到小酒馆怎么办？ 一切都在削减。但是，让我们按顺序进行。





1.局限性和假设


以上所有内容仅适用于关系数据库。包括Internet在内的充分照亮的情况下，未考虑以修改，删除和插入异常的形式出现的非规范化的影响。除了出版物的范围之外，在某些情况下，非正规化很常见，例如经典的例子：系列和护照号码，日期和时间等等。

该帖子使用了正常形式的直观且实际适用的定义，而没有引用数学术语。可以将它们应用于检查实际业务流程（BP）和工业软件设计的形式。

有一种观点认为，数据仓库，报告工具和集成协议的设计（使用信息的表格显示）与ERP数据库系统的设计不同，在于易用性和有意识的非规范化应用以实现该目的可以优先于完整性保护。数据。我同意这一观点，下面的描述仅适用于ERP系统的主数据模型和事务数据。

普通形式的解释通过一个示例给出，对于大多数读者而言，该示例在家庭级别是可以理解的。但是，为便于说明，在第4-5段中，故意使用了强调的“发明”任务。如果您不这样做，以某类教科书为例，例如第2条中的订单存储模型，您可能会发现自己处于读者的注意力将从拟议的流程分解转变为模型的过程中，转移到个人经验和对方法的认识上应该建立IP中数据存储的流程和模型。换句话说，请两名合格的IT分析人员，让一位为物流，运送乘客提供服务，另一位为物流，运送生产微芯片的机器提供服务。要求他们（不讨论预先自动化的BP）创建用于存储有关铁路飞行信息的数据模型。

在提议的模型中，您不仅会发现一组明显不同的属性，而且会发现一组不同的实体，这是非零概率，因为每个分析师都将依赖于他通常的流程和任务。而且在这种情况下，不可能说哪个模型“正确”，因为没有评估标准。

2.普通表格




数据库的第一种普通形式要求所有属性的原子性。
特别是，如果对象A具有非关键属性a和b，使得c = f（a，b），并且在描述对象A的表中存储了属性c的值，则数据库中将违反第一范式。例如，如果订单说明指定了一个数量单位，其计量单位取决于产品类型：在一种情况下，它可以是件，在另一升中，在由件组成的第三个包装中（在Good_count_WR上方的模型中），则数据库中属性的原子性受到侵犯。在这种情况下，要说说表的衬套对于订单规范应该是什么样的，您需要针对IP的工作过程进行针对性的描述，并且由于过程可能不同，因此可能有许多“正确”的版本。

数据库的第二种形式要求与知识产权工作流程相关的每个实体都遵循第一个表格及其自己的表格。如果在一个表中存在依赖关系c = f1（a）和d = f2（b），并且不存在依赖关系c = f3（b），则表中违反了第二种范式。在上面的示例中，“订单”表中的订单和地址之间没有任何关系。更改街道或城市的名称，不会对订单的基本属性产生任何影响。

数据库的第三范式需要遵守第二范式并且不同实体的属性之间不存在功能依赖关系。此规则可以表述为：“必须计算出所有可以计算的内容。” 换句话说，如果有两个对象A和B。在存储对象A属性的表中，显示属性C，对象B具有属性b，从而存在c = f4（b），则违反了第三范式。在下面的示例中，订单记录中的属性“件数”（Total_count_WR）显然声称违反了第三范式

3.我应用规范化的方法


1.只有目标自动化业务流程才能为分析提供创建数据存储模型时用于标识实体和属性的标准。创建流程模型是创建普通数据模型的先决条件。

2.如果满足以下部分或全部条件，则在严格意义上实现第三范式在创建ERP系统的实际实践中可能是不切实际的：

  • 自动化流程很少会发生变化，
  • 研发期限很紧，
  • 数据完整性要求相对较低（工业软件中的潜在错误不会导致软件客户损失金钱或客户）
  • 等等

在描述的条件下，从经济效率的角度来看，标识的成本，某些对象的生命周期的描述及其属性可能是不合理的。

3.通过对代码和测试进行全面的初步研究，可以阻止已经创建的IP中数据模型非规范化的任何后果。

4.非规范化是将劳动力成本从研究数据源和设计业务流程的阶段转移到从系统的实施阶段到开发阶段的开发阶段的一种方法。

5.在以下情况下，建议争取数据库的第三种正常形式：

  • 自动化业务流程的变化方向很难预测
  • 实施和/或开发团队内部存在渗透性的分工
  • 集成电路中包含的系统正在根据自己的计划进行开发。
  • 数据不一致可能导致公司损失客户或金钱

6.数据模型的设计应仅由分析人员结合目标业务流程和IP流程的模型进行。如果开发人员正在设计数据模型，他将不得不深入到主题领域，特别是他需要了解属性值之间的差异-这是区分原子属性的必要条件。因此，承担起异常的功能。

4插图任务


假设您在港口有一个小型机器人酒馆。您的细分市场：在港口停靠并需要休息的水手和海盗。对于水手，您会卖茶和百里香，而对于海盗，朗姆酒和骨头梳则是用来梳理胡须的。小酒馆本身的服务是由女主人机器人和酒保机器人提供的。由于高质量和低廉的价格，您已经排挤了所有竞争对手，以使每个离开船的人都来到您的酒馆，这是港口中唯一的酒馆。

小酒馆信息系统综合系统由以下软件组成：

  • 客户预警系统通过特征识别类别
  • 女主人机器人和调酒机器人的管理系统
  • 仓库和交货点管理系统
  • 供应商关系管理系统（SMSS）

过程：

预警系统检测到有人离开船舶。如果一个人刮胡子，则将其定义为水手，如果在一个人中发现胡须，则将其定义为海盗。

进入酒馆，客人听到女主人机器人根据其类别的问候，例如：““，亲爱的海盗，走到桌子号……。”

客人走到指示的桌子上，在那里，酒保已经准备好了。他根据商品分类。酒保机器人将信息发送到仓库系统，说明应增加下一部分交货，仓库IS根据剩余的存储量构成控制系统中的购买应用程序。

让您的内部IT开发预警系统，这是专门为您的企业设计的外部承包商，以创建酒吧机器人管理程序。仓库管理和供应商关系系统是来自市场的定制盒装解决方案。

5.非规范化及其对软件开发的影响的示例


在设计业务流程时，被采访的主题专家一致表示，世界各地的海盗喝朗姆酒，胡须与骨rest相接，水手们喝百里香茶，总是剃得很滑。

客户类型的目录从两个值出现：1-海盗，2-水手，对于公司的整个信息电路都是公用的。

客户通知系统立即将图像处理结果保存为识别出的客户的标识符（ID）及其类型：水手或海盗。

识别的对象ID客户类别
100500海盗
100501海盗
100502水手


再一次，我们注意到

1.我们的水手实际上是剃光的人
2.我们的海盗实际上是有胡子的人

在这种情况下需要解决什么问题，以便我们的结构争取第三种正常形式：

  • 属性原子冲突-客户类别
  • 将分析的事实和结论混合在一张表中
  • 固定不同实体属性之间的功能关系。

以规范化的形式，我们将得到两个表：

  • 识别结果以一组既定特征的形式出现，

识别的对象ID胡子
100500是
100501是
100502没有

  • 确定客户端类型作为应用IS嵌入的逻辑来解释已建立符号的结果


识别的对象ID识别码客户类别
100500100001海盗
100501100002海盗
100502100003水手


标准化存储组织如何促进IP复合体的开发？假设您突然有了新客户。让那些没有胡子的日本海盗，但他们带着一只鹦鹉在肩膀上行走，以及环境海盗，您可以通过左胸Greta的蓝色轮廓轻松识别它们。

当然，环境海盗不能使用骨顶，而需要使用回收的海洋塑料制成的类似物。

您需要根据新的介绍重新设计程序的算法。如果满足规范化规则，则只需要为某些流程分支添加输入，并仅针对那些情况以及面部发际线很重要的IP创建新分支。但是，由于未遵循规则，因此您将不得不在整个电路中分析整个代码，在其中使用客户端类型目录的值，并明确确定在一种情况下算法应考虑客户端的专业活动以及其他物理特征。

在倾向于规范化的视图中，我们将获得两个包含操作数据的表和两个目录：



  • 识别结果以一组既定特征的形式出现，

100510111
100511001
10051210


  • ( , )

检测到的非规范化是否意味着无法在新条件下修改系统？当然不是。如果您想象所有IP都是由一个人员流动为零的团队创建的，开发情况得到了很好的记录，并且团队中的信息得到了无损失的传递，那么所需的更改就可以用很少的精力就可以完成。但是，如果我们返回到任务的初始状态，则仅对于联合讨论的打印协议，将仅删除1.5个键盘和另外0.5个用于注册采购程序的键盘。

在上面的示例中，所有三种普通格式都被违反，让我们尝试分别对其进行违反。

违反第一种规范形式：

假设您使用属于您小酒馆的1.5吨瞪羚从供应商的仓库中将货物自费运到您的仓库。您的订单量相对于供应商的营业额而言是如此之小，以至于他们总是一对一地进行而不等待生产。对于这样的PSU，您是否需要单独的表格：车辆，车辆类型，是否需要将计划和订单中的事实分开给已离开的供应商？

试想一下，如果您使用下面的模型来开发程序，那么您的程序员将不得不编写多少“额外”连接。



假设我们决定所提议的结构不必要地复杂，对于我们而言，将计划和订单记录中的事实分开是多余的信息，并且所生成的订单规格将被接收到的货物的接受结果所覆盖，稀有的重新分类和质量不足的货物的到达都将在IP之外进行结算。
然后有一天，您将看到整个小酒馆大厅里充满了愤世嫉俗的海盗。发生了什么？

事实证明，随着业务的增长，消费也增长了。曾经做出过一项管理决策，即如果瞪羚的体积和/或重量超载（这种情况极为罕见），供应商将优先考虑饮料的装载。

未交货的货物落入下一个订单，然后搭乘新的航班出发，小酒馆的仓库中存有不可减少的余额，这使得它可能不会注意到破损的情况。

最后一个竞争者在港口关闭，通行的瞪羚超载事件是通行的做法，这种情况是基于对最小平衡和足够的车辆定期欠载的假设进行优先排序来规避的。理想情况下，所创建的系统将根据其中所规定的算法进行工作，并且将失去任何机会来跟踪系统未履行的计划订单。只有声誉受损和不满意的客户才能发现问题。

细心的读者必须注意到，第2节和第5节中的订单说明（T_ORDER_SPEC）中的订购数量可能满足或可能不满足第一标准格式的要求。对于选择的商品类别，这完全取决于是否可以将不同的计量单位归入同一领域。

违反第二种形式：

随着需求的增长，您会获得更多不同大小的车辆。在上述情况下，创建车辆目录被认为是多余的，因此，满足交付和仓库需求的所有数据处理算法都将货物从供应商到仓库的移动视为仅1.5吨瞪羚的飞行。因此，在购买新车的同时，您仍然会创建一个车辆目录，但是在最终确定时，您将必须分析涉及货物移动的整个代码，以查明是否参考了该车辆的特性。生意开始了。

违反第三种正常形式：

在某个时候，您开始创建一个忠诚度计划，出现常规的客户记录。例如，为什么要花时间创建材料表示形式，以存储单个客户的汇总销售数据，以用于报告并将其传输到分析系统，如果在忠诚度计划开始时，所有与客户有关的东西都可以放在客户自己的记录中？的确，乍一看毫无意义。但是，每当您的企业（例如新的销售渠道）建立联系时，分析师中就应该有人记住这一聚合属性。

在设计每个新流程时，例如，在Internet上销售，通过连接到通用忠诚度系统的分销商进行销售，都应记住所有新流程都应确保代码级的数据完整性。对于具有一千张表的工业数据库来说，这似乎是不可能的任务。

经验丰富的开发人员当然知道如何解决上述所有问题，但是我认为，经验丰富的分析师的任务不是引起他们的注意。

我要感谢出版准备过程中对领先开发商Evgeny Yarukhin的宝贵反馈。

文献


https://habr.com/cn/post/254773/
康诺利·托马斯（Connolly Thomas），贝格·卡罗琳（Begg Carolyn）。数据库。设计，实施和维护。理论与实践

More articles:


All Articles