你好！ 我叫安德烈·谢苗诺夫 (Andrey Semenov)，是 Sportmaster 的高级分析师。 在这篇文章中，我想提出 ERP 系统数据库的非规范化问题。 我们将研究一般条件以及具体示例 - 假设这将是海盗和水手的绝佳垄断酒馆。 其中海盗和水手必须得到不同的服务，因为这些好先生的审美观念和消费模式明显不同。
如何让大家都开心呢？ 如何才能避免疯狂地设计和维护这样的系统呢？ 如果不只是平常的海盗和水手开始来到酒馆怎么办？
一切都在削减之中。 但我们还是按顺序来吧。
1. 限制和假设
以上所有内容仅适用于关系数据库。 不考虑以修改、删除和插入异常形式出现的非规范化的后果，这些后果已被广泛报道，包括在互联网上。 在本出版物的范围之外，非规范化也很常见，典型的例子是：护照系列和号码、日期和时间等。
这篇文章使用了直观且实际适用的范式定义，没有参考数学术语。 它们可以应用于实际业务流程 (BP) 的检查和工业软件的设计。
有人认为，数据仓库、报告工具和集成协议（使用信息的表格表示）的设计与 ERP 系统数据库的设计不同，因为易于使用和使用有意识的非规范化来实现它可能优先于完整性保护数据。 我同意这个观点，下面描述的内容仅适用于 ERP 系统的主数据和事务数据模型。
使用大多数读者在日常水平上可以理解的示例来解释范式。 然而，作为视觉说明，在第4-5段中，故意使用了一个故意“虚构”的任务。 如果你不这样做，并采取一些教科书的例子，例如，与第2点相同的顺序存储模型，你可能会发现自己处于这样一种情况：读者的焦点将从建议的过程分解转移到模型中，个人经验和对如何构建在 IS 中存储数据的流程和模型的看法。 换句话说，聘请两名合格的 IT 分析师，其中一名为运送乘客的物流人员提供服务，另一名为运输微芯片生产机器的物流人员提供服务。 要求他们创建一个数据模型来存储有关铁路旅行的信息，而无需提前讨论自动化 BP。
在所提出的模型中，您不仅会发现一组明显不同的属性，而且还会发现不同的实体组，这是非零概率的，因为每个分析师都会依赖于他熟悉的流程和任务。 在这种情况下，不可能说哪个模型是“正确的”，因为没有评价标准。
2. 范式
数据库的第一范式 要求所有属性的原子性。
特别是，如果对象 A 具有非键属性 a 和 b，例如 c=f(a,b) 并且在描述对象 A 的表中存储属性 c 的值，则数据库中违反了第一范式。 例如，如果订单规格指示数量，则其计量单位取决于产品类型：在一种情况下，它可以是件，另一升，在由件组成的第三个包装中（在上面的 Good_count_WR 模型中） ，那么数据库中就违反了属性的原子性。 在这种情况下，为了说出订单规范的表簇应该是什么，你需要对IS中的工作流程进行有针对性的描述，并且由于流程可能不同，因此可能有很多“正确”的版本。
数据库的第二范式 要求与 IS 中的工作流程相关的每个实体遵守第一个表格及其自己的表格。 如果在一个表中存在依赖关系 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. 可以通过对代码和测试进行彻底的初步研究来减轻已创建的 IS 中数据模型非规范化的任何后果。
4、非规范化是将人力成本从研究数据源、设计业务流程阶段转移到开发阶段，从实施期转移到系统开发期的一种方式。
5. 如果满足以下条件，建议采用数据库的第三范式：
- 自动化业务流程的变革方向很难预测
- 实施和/或开发团队内部分工薄弱
- 集成电路中包含的系统按照自己的计划开发
- 数据不一致可能会导致公司失去客户或金钱
6. 数据模型的设计应由分析师仅结合目标业务流程和IS 中的流程的模型来进行。 如果开发人员正在设计数据模型，他必须将自己沉浸在该主题领域中，特别是要了解属性值之间的差异 - 这是隔离原子属性的必要条件。 因此，承担了不寻常的功能。
4 说明问题
假设您在港口有一家小型机器人酒馆。 您的细分市场：进港需要休息的水手和海盗。 你向水手出售加百里香的茶，向海盗出售用于梳理胡须的朗姆酒和骨梳。 酒馆本身的服务由机器人女主人和机器人调酒师提供。 你们以高品质、低价格赶走了竞争对手，让所有下船的人都来到你们的小酒馆，这是港口里唯一的一家。
酒馆信息系统综合体由以下软件组成：
- 一种根据特征识别其类别的客户预警系统
- 机器人服务员和机器人调酒师控制系统
- 仓库和配送管理系统到销售点
- 供应商关系管理系统（SURP）
过程：
预警系统可以识别离开船只的人员。 如果一个人胡子刮得干干净净，她就认定他是水手；如果发现一个人留着胡须，那么他就认定他是海盗。
进入酒馆，客人会听到机器人女主人按照他的类别打招呼，例如：“嗬嗬嗬，亲爱的海盗，到No号桌去……”
客人来到指定的餐桌，机器人调酒师已经按照品类为他准备好了商品。 机器人调酒师向仓库系统发送信息，告知下一批交货应该增加；仓库IS根据存储的剩余余额，在管理系统中生成采购请求。
虽然预警系统可能是由您的内部 IT 开发的，但酒吧机器人管理程序可能是由外部承包商专门为您的业务创建的。 用于管理仓库和与供应商关系的系统是来自市场的定制打包解决方案。
5. 非规范化的例子及其对软件开发的影响
在设计业务流程时，受访主题专家一致表示，世界各地的海盗喝朗姆酒，用骨梳梳理胡须，水手喝百里香茶，总是把胡子刮得干干净净。
客户类型目录显示有两个值：1 - 海盗，2 - 水手，对于公司的整个信息回路来说是通用的。
客户通知系统立即将图像处理结果存储为识别出的客户的标识符（ID）及其类型：水手或海盗。
识别的对象ID
客户类别
100500
海盗
100501
海盗
100502
水手
让我们再次注意
1.我们的水手其实都是剃光头的人
2.我们的海盗其实都是有胡子的人
在这种情况下需要消除哪些问题，以便我们的结构力求第三范式：
- 属性原子性违规 - 客户端类别
- 将分析的事实和结论混合在一张表中
- 不同实体的属性之间固定的功能关系。
以标准化形式，我们将得到两个表：
- 识别结果以一组既定特征的形式出现，
识别的对象ID
胡子
100500
是
100501
是
100502
没有
- 确定客户端类型的结果，作为嵌入在 IS 中的逻辑的应用程序来解释已建立的特征
识别的对象ID
身份识别码
客户类别
100500
100001
海盗
100501
100002
海盗
100502
100003
水手
规范化的数据存储组织如何促进IP综合体的发展？ 假设您突然有了新客户。 就算是日本海盗，他们可能没有胡子，但他们走路时肩上扛着一只鹦鹉，而环保海盗，你可以通过左胸上格蕾塔的蓝色侧面轻松认出他们。
环境海盗自然不能使用骨梳，而需要由回收的海洋塑料制成的类似物。
您需要根据新的输入重新设计程序算法。 如果遵循规范化规则，那么您只需补充某些系统中某些流程分支的输入，并仅针对那些情况和那些面部毛发很重要的 IS 中创建新分支。 但是，由于没有遵循规则，您将必须分析整个电路中的整个代码，其中使用了客户端类型目录的值，并明确确定在一种情况下该算法应考虑专业客户的活动以及其他身体特征。
以一种形式 旨在 为了规范化，我们将得到两个包含操作数据的表和两个目录：
- 识别结果以一组既定特征的形式出现，
识别的对象ID
格蕾塔在左胸
肩膀上的鸟
胡子
100510
1
1
1
100511
0
0
1
100512
1
0
- 确定客户端类型的结果（让它成为显示目录描述的自定义视图）
检测到的非规范化是否意味着系统无法修改以满足新条件？ 当然不是。 如果我们想象所有的信息系统都是由一个团队创建的，人员流动率为零，开发过程有详细记录，并且信息在团队内部传输而不会丢失，那么所需的更改可以毫不费力地完成。 但如果我们回到问题的原始条件，1,5个键盘将被删除，只是用于打印共同讨论的协议，另外0,5个键盘用于处理采购程序。
在上面的例子中，所有三种范式都被违反了，让我们尝试分别违反它们。
违反第一范式：
假设货物是通过您酒馆的一只 1.5 吨瞪羚提货从供应商仓库运送到您的仓库的。 相对于供应商的营业额，您的订单规模非常小，因此它们总是一对一完成，无需等待生产。 您是否需要具有这样的业务流程的单独表格：车辆、车辆类型，是否有必要将订单中的计划和事实分开给离职的供应商？
想象一下，如果您使用下面的模型来开发程序，您的程序员将需要编写多少“额外”连接。
假设我们认为所提出的结构不必要地复杂；在我们的例子中，将订单记录中的计划和事实分开是冗余信息，并且生成的订单规范是根据到货验收结果重写的，很少会出现错误。 - 质量不合格的货物的分级和到达在 IS 之外进行结算。
然后有一天，你看到整个酒馆大厅里挤满了愤怒且蓬头垢面的海盗。 发生了什么？
事实证明，随着您的业务增长，您的消费也在增长。 曾几何时，管理层做出了一项决定，如果瞪羚的体积和/或重量超载（这种情况极为罕见），供应商将优先考虑超载，而不是饮料。
未交付的货物最终进入下一个订单并搭乘新航班离开；酒馆仓库中存在最低余额，因此可以不注意到丢失的情况。
最后一个竞争对手在港口关闭，瞪羚超载的刺穿案例，通过基于最小余额充足和车辆定期装载不足的假设的优先顺序来绕过，成为常见的做法。 理想情况下，创建的系统将按照嵌入其中的算法运行，并且将被剥夺任何跟踪履行计划订单的系统故障的机会。 只有声誉受损和不满意的客户才能发现问题。
细心的读者可能已经注意到，第2节和第5节中的订单规格（T_ORDER_SPEC）中的订购数量可能满足也可能不满足第一范式的要求。 这完全取决于给定选定的商品种类，本质上不同的计量单位是否可以属于同一领域。
违反第二范式：
随着您的需求增长，您会购买更多不同尺寸的车辆。 在上述情况下，创建车辆目录被认为是多余的；因此，所有满足交付和仓库需求的数据处理算法都将货物从供应商到仓库的移动视为专门 1,5 吨的航班。羚羊。 因此，在购买新车的同时，您仍然创建一个车辆目录，但在最终确定时，您必须分析引用货物移动的所有代码，以查明是否在每个特定位置都暗示了该特征的引用业务开始的那辆车。
违反第三范式：
在您开始创建忠诚度计划的某个时刻，会出现常客的记录。 例如，如果在忠诚度计划开始时，客户感兴趣的所有内容都可以放在客户的记录中，为什么要花时间创建材料视图来存储单个客户的销售汇总数据以用于报告和传输到分析系统？ 事实上，乍一看，没有任何意义。 但是，每次您的业务连接（例如新的销售渠道）时，您的分析师中都应该有人记住这种聚合属性的存在。
在设计每个新流程时，例如互联网上的销售、通过连接到通用忠诚度系统的分销商进行的销售，必须记住所有新流程都必须确保代码级别的数据完整性。 对于一个拥有一千张表的工业数据库来说，这似乎是一项不可能完成的任务。
当然，经验丰富的开发人员知道如何阻止上述所有问题，但在我看来，经验丰富的分析师的任务不是揭露这些问题。
我要向主要开发人员 Evgeniy Yarukhin 在本书准备过程中提供的宝贵反馈表示感谢。
文学
康诺利·托马斯，贝格·卡罗琳。 数据库。 设计、实施和支持。 理论与实践
来源： habr.com