MCD：将"我们需要一个数据库"转化为实际需求的罗塞塔石碑

摘要: 本文解释了 MERISE 方法论中的概念数据模型（Conceptual Data Model，MCD）如何作为对话框架，通过在编写任何 SQL 代码之前系统地定义实体、关系和基数，将"我们需要一个数据库"这类模糊请求转化为具体需求。

原文链接

---

MERISE 系列第二篇*

新来的？第一篇介绍了 MERISE 存在的原因以及它与 ER 建模的区别。简而言之：它是一个对话框架，迫使业务相关方在您编写一行 SQL 之前就明确表达他们的实际规则。

上次，我介绍了 MERISE 以及为什么这个法国方法论在数据库建模方面表现出色。今天，我们将深入探讨第一步，也是最关键的一步：概念数据模型（Conceptual Data Model，MCD）。

这是大多数 DBA 误解的地方：他们认为 MCD 只是画一些漂亮的方框。其实不是。

MCD 是一个对话工具。它是如何防止 3 年后的灾难的：数据不一致因为约束不存在、性能崩溃因为列被随意添加、更新异常因为同一数据存在于五个地方。

所有这一切都始于一个错误的决定：跳过对话，直接编写 CREATE TABLE。

为什么要用 MCD

在编写任何 SQL 之前，您需要答案。MCD 为您提供了一个结构化的方式来提出正确的问题：

1. 存在什么？（实体）
2. 事物如何连接？（关系）
3. 规则是什么？（基数 + 属性）

让我们通过一个真实案例来演示这一点。

在我们走过这个动物园示例时，请注意我会在最后指出的红旗——它们是表明您需要深入挖掘的信号。

动物园数据库：一个案例研究

我将使用我的培训中的动物园示例。它足够简单以便于理解，足够复杂以显示问题出在哪里。

步骤 1：初始请求

业务方说：“我们需要跟踪我们的动物。”

好的。什么是动物？

看起来不错，对吧？错了。这就是您开始提问的地方。

步骤 2：物种问题

您：“等等，物种只是文本？如果两个人对’非洲象’的拼写不同怎么办？”

业务方：“哦，是的，物种应该是标准化的。我们还需要拉丁名称。”

现在我们有了：

基数问题：一个动物可以属于多个物种吗？（不，显然不能。）一个物种可以有多个动物吗？（是的，希望如此。）

这是一个一对多关系。¹

步骤 3：围栏问题

业务方：“动物生活在围栏中。”

您：“一个动物，一个围栏？还是动物可以移动？”

业务方：“嗯，有时我们会为了繁殖项目移动它们……”

啊。现在变得有趣了。

基数：一个动物一次住在一个围栏中（1,1）。一个围栏可以容纳多个动物（1,n）。

但是等等——"一次"这个词承担了很多工作。这是您可能需要历史跟踪的线索。记下来。继续。

步骤 4：繁殖项目

业务方：“我们需要跟踪繁殖项目。”

您：“好的。什么是繁殖项目？”

业务方：“就是我们为了配对在动物园之间转移动物。”

您：“所以一个动物可以参与多个项目？”

业务方：“是的。”

您：“一个项目涉及多个动物？”

业务方：“是的。”

这是一个多对多关系：

注意到关系有自己的属性了吗？在 MERISE 中，关系（椭圆形）可以有属性，它们还不是实体。这与传统的 ER 建模不同，在传统 ER 建模中您会创建一个连接实体。

步骤 5：喂养问题

业务方：“我们需要跟踪喂养时间表。”

您：“喂养是按动物还是按物种？”

业务方：“按物种。所有大象吃同样的饮食。”

关键洞察：您几乎通过将动物链接到食物而错误地建模了这一点。MCD 对话挽救了您。

步骤 6：员工问题

业务方：“动物园管理员需要分配到围栏。”

您：“一个管理员一个围栏？”

业务方：“不，多个管理员轮换。”

您：“一个管理员可以管理多个围栏？”

业务方：“是的。”

您：“而且一个管理员可以在系统中存在而尚未分配吗？”

业务方：“不能。”

您：“那关于入职、休假、病假呢？管理员在这些情况下是否可以在系统中存在而没有围栏分配？”

业务方：“啊，好观点。是的，我们在分配之前先雇佣人。”

又是多对多关系，管理员侧最小基数为 0：

步骤 7：最终的 MCD

经过所有这些对话，我们有了：

三个神奇的问题

每个实体-关系对都需要回答这些问题：

1. 最小基数

“这个可以没有另一个而存在吗？”

• 没有物种的动物？不能 → 最小 1
• • 没有动物的物种？可以（新添加的物种）→ 最小 0
• • 没有动物的围栏？可以（新的/空的）→ 最小 0

2. 最大基数

“这个可以连接到多个吗？”

• 动物在多个围栏中？不能 → 最大 1
• • 围栏有多个动物？可以 → 最大 n
• • 员工分配到多个围栏？可以 → 最大 n

3. 关系属性

“这个连接有自己的数据吗？”

• 分配有 start_date 和 shift
• • 参与有 role（donor/receiver）
• • 像"属于"这样的简单链接没有属性

MCD 对话中的红旗

这些模式告诉您还有更多需要探索：

业务方说：“把所有东西都放在一个表里。” 请他们走一遍具体示例。“假设我们明天添加一个新动物，我们需要什么信息？” 真实场景会暴露隐藏的复杂性。

业务方说：“我们稍后会弄清楚细节。” 选择一个细节深入。“让我们现在就澄清这一个关系。它需要 5 分钟，但会节省我们之后几周的时间。” 从小处着手，建立信心。

业务方使用"有时"：“有时动物在两个围栏中。” “有趣！那什么时候发生？是在移动期间临时性的，还是别的什么？”"有时"这个词隐藏了一个您需要捕捉的业务规则。

业务方无法回答基数：“我不知道是 0 还是 1。” “没问题。让我们思考一下场景。您可以有一种物种在系统中而没有任何动物吗？当该物种的最后一只动物死亡时会发生什么？” 使其具体化，而不是抽象化。

目标不是审问人们。是帮助他们表达他们知道但尚未正式化的规则。

为什么这很重要

当您完成 MCD 时，您已经：

1. 记录了他们不知道自己有的业务规则
2. 在代码之前捕捉到矛盾
3. 让他们对基数做出承诺（之后不能反悔）
4. 识别出多对多关系隐藏的地方

MCD 不是关于 SQL 的。是关于强制清晰度。

当相关方签署您的 MCD 时，他们签署的是业务逻辑。不是实现，是规则。当他们六个月后回来说*“但我以为……”*时，这就是您的保险单。

您指向 MCD。您说：“我们同意了这个。”

下一步是什么

在下一篇文章中，我们将把这个 MCD 转化为逻辑数据模型（Logical Data Model，MLD），在那里我们添加主键、外键，并将那些带有属性的 MERISE 关系（如"参与"和"被分配"）转化为实现用的连接表。

但这里是秘密：如果您的 MCD 是坚实的，MLD 就是机械的。它只是应用转换规则。

MCD 是您项目成败的地方。

---

• MERISE: 0,1 1,1 0,n 1,n
• Chen ERD: 1 N M
• Crow’s Foot: |o || >o >|
• UML: 0..1 1 0..* 1..*

我见过团队浪费数小时争论哪个符号"是正确的"。它们都是正确的。选择一个，记录下来，继续。重要的是：业务人员能看您的图表并理解规则吗？如果能，您的符号就有效。如果他们困惑了，添加图例。

此外，一些标准将基数放在它们描述的实体上，另一些放在另一端。对您的约定要明确。

目标是沟通，不是关于 ERD 标准的宗教战争。

---

PostgreSQL | data modeling | Performance | SQL

---

1. MERISE 符号基础：存在的实体是矩形，连接事物的关系是椭圆形。两者都可以有属性。我注意到我写基数像"1,n"和"0,1"，这是最小、最大的符号。但关键是：只要您保持一致并添加图例，符号并不重要。不同的方法使用不同的符号： ↩︎