使用 ERD 和 Crow Foot Notation 进行数据建模
4.87/5 (13投票s)
架构数据结构
引言
在本文中，我将向您展示如何使用实体关系图（ERD）和乌鸦脚符号（Crow Foot Notation）的数据建模技术来构建数据结构。
背景
数据架构师在设计数据模型时使用了许多技术，例如实体关系图（ERD）和数据矩阵等。本文将仅演示最常用的技术，即 ERD。在 ERD 中，数据架构师使用多种符号来表示数据实体之间的关系和基数。其中一些符号包括 OMT、IDEF、Bachman、Chen、Martin、UML 和 Crow Foo。然而，本文仅演示乌鸦脚符号。
关系和基数/多重性
理解实体之间的关系和基数/多重性对于建模数据库系统至关重要。当涉及到实体之间的关系时，两个实体之间可能存在以下三种关系之一。
- 一对一
- 一对多
- 多对多
我将通过一些例子来解释它们。
- 一辆汽车需要一张税票（一对一）
- 一辆汽车有四个轮子（一对多）
- 一辆汽车可以载不止一个人（一对多）
- 一名司机可以驾驶多辆汽车，而一辆汽车也可以由多名司机驾驶（多对多）。
人们必须理解表/实体在关系中可能存在的基数。基数是指一个表在关系中可以拥有的行数。正如您可能注意到的，我互换使用了“表”和“实体”这两个词，原因是实体最终会成为数据库中的表。我们将在接下来的章节中详细介绍这一点。
可能的基数包括
- 正好一个
- 一个或多个
- 零个、一个或多个
- 零个或一个
在我们关系部分提到的关系中，当我们说一辆汽车可以载不止一个人时，我们就知道汽车至少会载一个人，那就是司机。而且，根据车辆的不同，它还可以载 5、7 个或更多人。因此，我们现在可以添加进一步的约束——**一对（一个或多个）**。“一个或多个”被称为关系中的基数/多重性。
让我们看一些更多的例子。
一辆汽车只能拥有一张税票——**一对（正好一个）**
一名司机可以驾驶多辆车，但同时他可能不需要拥有汽车，可以使用公共交通。在这种情况下，司机不驾驶任何车辆——**一对（零个、一个或多个）**。
一辆汽车可以声明报废，不需要税票。在这种情况下，汽车没有税票——**一对（零个或一个）**。
汽车所有人或所有人的配偶或任何持有全牌照的人都可以驾驶车主的汽车——（多对一）。同样，汽车可以声明报废，没有人可以驾驶它——**（零个、一个或多个）对一**
您明白了！
乌鸦脚符号
现在，让我们在深入研究数据建模之前，先看一下乌鸦脚符号并理解它们的含义。
为了在 ERD 中说明上述实体之间的关系和基数，将使用带基数的乌鸦脚符号。乌鸦脚的符号及其含义如下。括号中的符号在 UML 中使用。
我确信这些符号是自明之意的，不需要进一步解释。但是，如果您有任何问题，请随时通过本文底部的评论与我联系，我将非常乐意为您提供帮助。
数据模型
数据建模过程涉及三个级别的数据模型。概念模型和逻辑模型可能会经过多次迭代，直到所有实体和关系都被识别、最终确定并与所有利益相关者达成一致。然后开发最终的物理模型来创建数据库。
现在，让我们看看这三个模型级别
- 概念模型
- 逻辑模型
- 物理模型
为了演示这三个数据模型，我将使用一个简化的**在线汽车保险报价系统**。数据模型这三个级别将按照给定的顺序执行。
注意：**请注意，此模型绝非一个完整的在线汽车报价系统，并且为了简单起见，我忽略了系统中的许多数据元素，例如付款等。**
概念模型
在此级别，通过让所有相关利益相关者参与来识别实体及其关系。当需求准备就绪后，数据架构师会与业务分析师、产品负责人和其他利益相关者进行讨论，创建概念模型。概念模型是逻辑模型的抽象形式，它显示了所有高层实体，而无需考虑属性（列）及其类型等详细结构。
对于我们的在线汽车保险报价系统，已识别出以下实体和关系。
实体
用户引用车辆驱动程序索赔定罪策略MTA批注文档
关系与基数
- 一个用户可以有一个或多个报价（零个、一个或多个）。- 一对（零个、一个或多个）
- 一个报价只能有一辆车（保险公司不接受同一份保单有多辆车）– 一对（正好一个）
- 一个报价可以有一个或多个驾驶员。（一对（一个或多个）
- 一名驾驶员可以有一个或多个索赔（零个、一个或多个）- 一对（零个、一个或多个）
- 一名驾驶员可以有一个或多个定罪（零个、一个或多个）- 一对（零个、一个或多个）
- 一个报价可以有一个或零个保单 - 一对（零个或一个）
- 一个保单可以有一个或多个批注（零个、一个或多个）- 一对（零个、一个或多个）
- 一个保单可以有一个或多个 MTA（修改）。一对（零个、一个或多个）
一个文件可以属于一个或多个保单，一个保单可以有一个或多个文件。（一个或多个）对（一个或多个）
在概念模型获得功能团队的同意和批准之前，此过程将经历多次迭代。上述需求的 are 概念模型如下图所示
注意事项
虚线表示 - 弱（非识别）关系
- 实体的存在独立于其他实体
- 子实体的外键不包含父实体的外键
实线表示 - 强（识别）关系
- 子实体的存在依赖于父实体
- 子实体的外键包含父实体的外键
逻辑模型
一旦概念模型被接受并获得功能团队的批准，逻辑模型就有助于定义实体及其关系的详细结构。逻辑模型是物理模型的基础。这是一个非常重要的级别，因为这个模型清楚地表示了业务需求和系统所需的数据结构。
通过借鉴概念模型的结果，在逻辑模型中设计每个实体的详细结构。在此级别识别实体的属性及其类型，但类型是平台无关的。实际的表名和列名不一定与逻辑模型中的实体名称和属性匹配。
为了简洁起见，我没有包含所有属性，但在现实世界中，您会期望更多的属性。原因在于，这是为了传达数据建模的概念，而不是提供一个完整的系统。
下图是系统中实体之间关系的逻辑模型。
逻辑模型定义了每个实体的属性（列）及其类型（数据类型），但是
它仍然是平台无关的。这意味着，通过一个逻辑模型，可以在任何
数据库中实现，例如 Oracle 或 SQL Server。
物理模型
物理数据模型直观地表示了实际的数据库模式，并且是平台特定的。这意味着物理模型可以实现为为其设计的数据库。例如，如果一个物理模型是为 SQL Server 设计的，那么它不能简单地实现到 ORACLE 中，因为数据结构是数据库特定的，并且其列的数据类型只在目标数据库上才能工作。
例如，在我们的示例中，列类型是针对 SQL SERVER（下面第一个图）数据库生成的。这意味着物理模型需要针对 Oracle 等其他数据库进行修改（下面第二个图）。原因是 SQL Server 物理模型中的数据类型 VARCHAR 不能在 Oracle 中使用，因为该数据类型无效。
这意味着物理模型是数据库模型的实际表示，并且可以从物理模型直接创建实际的数据库模式，并使用正确的工具直接在 DBMS 中运行。市面上有许多工具可以完成这项工作。
此外，通过引入链接表 PolicyDocument，在物理模型中实现了 Policy 和 Document 之间的多对多关系。请记住，多对多关系在没有链接表的情况下无法在任何两个实体之间实现。
目标数据库的表名、列名和列数据类型在物理模型中最终确定，如下所示。红色圆圈只是为了强调多对多关系的实际实现已在物理模型中完成，仅此而已。
我使用一个工具从同一个逻辑模型生成了两个物理模型，工作量不大。第一个是为 SQL SERVER，第二个是为 ORACLE。
我们也可以从工具生成目标数据库的 SQL 脚本，但这超出了本文的范围。希望您觉得这篇文章有用，如果您有任何问题，我很乐意解答。
如果您觉得这篇文章有用，请不要忘记投票支持我。谢谢！