mysql - 如何为丢失主键和外键信息的数据库生成ERD/UML？

Question

我有一个结构良好的数据库的表创建脚本。
但是，出于某种原因，可以说，表创建脚本不包含主键或外键信息。

为使用这些脚本创建的数据库生成 ERD/UML 的最佳方法是什么 - 假设索引完好无损。是否有任何工具可用于检查列名并生成 ERD/UML？

我应该手动执行此操作吗？

Answer 1

您问题的答案 - 我应该手动执行此操作吗？ - 是的，恐怕。

让我们考虑自动检测主键和外键的可能性。无论这样的算法是已经存在还是由您自己编写，它都必须从给定的数据库方案中确定哪些属性组合符合 PK 和 FK。

有一个简单的案例，但我怀疑这不适用于您的数据库，否则您不会问这个问题。如果有命名约定(非常值得推荐)，例如只需调用每个 PK id和每个 FK <referenced table>_id ，那么从 PK 和 FK 所在的表定义的句法属性中就可以清楚地看到。但是，您的数据库定义将自行回答您的问题。

另一种方法是表及其属性的语义。例如，如果您有 person包含 place_of_birth 的表属性，只有一张表叫 city可能包含这样的地方，那么很可能你已经找到了一个 FK。但是这种推理很难自动化，因为它需要大量的数据库基础领域知识，以及该领域术语的含义和关系。

剩余的算法可能性基于数据库 key 的正式定义。键是一个属性或属性组合，对于表中的每条记录都具有唯一值。不幸的是，这是一个扩展定义，即它指的是您在特定时间点拥有的数据库内容。假设，例如，您有一张 table person带属性 first_name和 last_name .您可以找到或编写一种算法来检测一个或多个列是否有资格作为关键候选者，并且今天它可能会确定名字和姓氏是否符合条件，因为表中没有两条记录共享相同的值对。但是明天，一个叫 Jack Miller 的人可能会出现在您的数据库中，而另一个 Jack Miller 也在场，这将使您的 PK 假设无效。

因此，一个稳定的键概念必须伴随着一个内涵论证，一个确保特定键组合对于每个域对象都是并且将保持唯一的域法则。

通常，这种困难可以通过引入人工 key 来避免，例如 id .虽然可以推荐这样做，但恐怕您的数据库不会太严格地遵循这一点，否则您会注意到它并且它至少可以部分解决您的问题。

谈到 FK，也会出现类似的困难。在语法上，表中的每个属性组合 t1其值组合是另一个表中属性组合的子集t2可能是该表的 FK。但即使在您已经确定主键的简单情况下，也许对于一些包含引用数据的语义清晰的表，算法应该如何判断，对于包含 1 到 100 的潜在 FK 值，哪些表具有从 1 到(至少)100 被引用？

所以我担心主要任务将是手动的，或者更好地说，使用一些领域知识在大脑中执行。在应用自下而上的方法，分析值(value)组合的范围之前，应该有一些自上而下的推理。您的域的主要业务对象是哪些，如何识别它们，以及它们需要如何相互关联？一旦你找到了一个假设，那么算法验证就很容易了。要伪造关键候选人，请执行如下查询

select key_candidate, count(*) as ct
from table
group by key_candidate
having ct > 1

如果它产生多于零条记录，则 key_candidate不能是 key 。要伪造外键，请执行

select *
from table t
where not exists (
   select *
   from referenced_table rt
   where t.fk_candidate = rt.key
)

如果它产生多于零条记录，则 fk_candidate不是 FK 或 key不是要引用的预期键。但那些算法论点只是对你的语义研究的补充。