Question

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

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

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

Answer 1

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

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

有一个简单的案例，但我怀疑你的数据库不是这样，否则你不会问这个问题。如果有名称约定（非常值得推荐），例如调用每个PK id和每个FK <referenced table>_id，然后从表定义的句法属性中可以清楚地知道PK和FK的位置。但是，您的数据库定义将自行回答您的问题。

另一种方式是表及其属性的语义。例如，如果您的person表包含place_of_birth属性，并且只有一个名为city的表可能包含此类地点，则很可能您已找到FK。但是这种推理很难实现自动化，因为它需要大量了解数据库的基础知识域，以及该域名的含义和关系。

剩下的算法可能性基于数据库密钥的正式定义。键是属性或属性组合，具有表中每个记录的唯一值。不幸的是，这是一个扩展定义，即它指的是您在特定时间点拥有的数据库内容。例如，假设您有一个包含属性person和first_name的表last_name。您可以找到或编写一个算法来检测一个或多个列是否有资格作为关键候选者，并且它现在可以确定名字和姓氏是否合格，因为表中没有两个记录共享相同的值对。但是明天，一个名叫杰克米勒的人可能会被插入你的数据库，而另一个杰克米勒也会出现，并且会使你的PK假设失效。

因此，一个稳定的密钥概念必须伴随着一个内涵参数，一个域法则确保某个密钥组合对每个域对象都是唯一的。

通常，通过引入人工密钥（例如id）可以避免这种困难。虽然这可以推荐，但我担心你的数据库不会严格遵守这个规则，否则你会注意到它，它至少会部分解决你的问题。

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

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

的查询

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

如果它产生的记录多于零，则key_candidate不能成为密钥。要伪造外键，请执行

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

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

Answer 2

从数据中心的角度来看，任务的手动部分基本上是业务分析。这是耗时且乏味的。从主题专家那里获得尽可能多的帮助。发现业务规则以及主题专家始终处理的实体。了解他们如何识别这些权利的实例。

TAM在他的回答中概述了这项任务的可自动化部分。

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

2 个答案: