如何记录数据库

Question

（注：我知道这与如何记录数据库结构？非常接近，但我认为它们并不完全相同。）

我在一个有数百个表和视图的数据库中开始工作，所有表和视图都有难以理解的名称，几乎没有元音，并且没有文档。他们也不允许对数据库模式进行任意更改，而且我不能触及除了我自己机器上的测试数据库之外的任何数据库（该数据库会被定期清空并重新创建），所以我无法添加任何对其他人有帮助的评论。

我尝试使用"Toad"创建ER图，但是在连续运行48个小时后，它仍然没有产生任何可见的结果，而我需要我的电脑回来。我和一些最近入职的同事交谈，我们都建议每当我们弄清楚特定表或某些列的含义时，我们应该在开发者维基中更新它们。

那么怎么做才好呢？只需列出表/视图及其列，并随着我们的进展填写吗？我手头的基本工具是Toad、Oracle的"SQL Developer"、MS Office和Visio。

- Paul Tomblin

---

再一次，由于我们现在的严格规定，有用的问题被关闭了好几年。 - Georgi Raychev

请查看开源项目dbml.org，您可以使用他们创建的简单DSL记录您的数据库。 - huy

@papigee请不要滥用您的编辑特权来“推动”问题进入重新开放队列。如果您想要重新开放某个问题，您应该投票支持重新开放。 - Mark Rotteveel

Answer 1

根据我的经验，ER（或UML）图表并不是最有用的文档——对于大量数据表，图表（特别是反向工程的图表）通常会变得混乱无序，没有人能从中学到任何东西。

我认为，一些良好的可读性强的文档（可能还要配合系统较小部分的图表）将为你带来最大的收益。这将包括每个表格：

• 该表格的含义和功能使用方式的说明（在用户界面中等）
• 如果属性意义不明显，则解释每个属性的含义
• 解释该表格与其他表格之间以及相反方向的关系（外键）
• 额外限制和/或触发器的解释
• 如果主要视图和处理过程对表格没有很好的文档记录，则提供更多解释

在以上所有内容中，不要为了文档而文档——重新阐述显而易见的信息只会妨碍人们。相反，专注于最初让你困惑的内容，花几分钟撰写非常清晰、简洁的说明。这将帮助你理清思路，也将极大地帮助那些第一次遇到这些表格的开发人员。

正如其他人所提到的，有各种各样的工具可帮助你管理此类文档，例如Enterprise Architect、Red Gate SQL Doc和各个供应商提供的内置工具。但是，在更大的数据库中，工具支持是有用的（甚至至关重要），但理解和解释数据库的概念模型才是真正的胜利。从那个角度来看，你甚至可以在一个文本文件中完成它（尽管在Wiki形式下进行将允许多人协作逐步添加文档——因此，每当有人解决某些问题时，他们可以立即将其添加到不断增长的文档库中）。

- Ian Varley

---

如果有人能够写出易懂的文档，我同意使用它；但是根据我的经验，需要的知识已经离开了公司，这就更凸显了文档编写的重要性。 - SqlACID

Answer 2

需要考虑的一件事是DBMS内置的COMMENT功能。如果您在DBMS本身上对所有表和所有列进行注释，则您的文档将在数据库系统内部。

使用COMMENT功能不会对模式本身进行任何更改，它只会向USER_TAB_COMMENTS目录表添加数据。

- Steven Huwig

---

就像我在原始问题中所说的那样，我无法更改模式，并且我无法更改维护模式的脚本。因此，除了我的计算机上的测试数据库之外，我无法向任何内容添加注释，而该数据库经常被清除并重新创建。 - Paul Tomblin

当您添加注释时，您并没有更改架构。但我理解那些愚蠢的数据库官僚主义情况。 - Steven Huwig

但是在information_schema数据库中，列和表的注释信息是有限的，因此可能像您回答的那样对表和列进行注释是没有用处的。 - shgnInc

信息架构中的注释可以包含JSON。 - NaturalData

根据我的经验，这是一个非常糟糕的建议。由于注释太长，我经常遇到导出、导入或传输文件的问题。 - m02ph3u5

Answer 3

在我们的团队中，我们采用了一种有用的方法来记录遗留的大型Oracle和SQL Server数据库。我们使用Dataedo来记录数据库架构元素（数据字典）并创建ERD图。Dataedo带有文档存储库，因此您的整个团队都可以在线记录和阅读最新的文档，而无需干扰数据库（Oracle注释或SQL Server MS_Description）。首先，您导入模式（所有表，视图，存储过程和函数 - 包括触发器，外键等）。然后，您定义逻辑域/模块，并将所有对象（拖放）分组到它们中，以便能够分析和处理较小的数据库块。对于每个模块，您创建一个ERD图并编写顶级描述。然后，当您发现表和视图的含义时，为每个表和视图编写简短的描述。对于每个列，也要做同样的事情。Dataedo使您能够为每个对象和列添加有意义的标题 - 如果对象名称模糊或无效，则这很有用。专业版使您能够描述外键，唯一键/约束和触发器 - 这很有用，但不是理解数据库所必需的。您可以通过UI访问文档，也可以将其导出为PDF或交互式HTML（后者仅在专业版中提供）。

这里介绍的是一个连续的过程，而不是一次性的工作。如果您的数据库发生更改（例如新列、视图），您应该定期同步文档（使用Dataedo只需几个点击）。

请参阅样例文档： http://dataedo.com/download/Dataedo%20repository.pdf 有关文档过程的一些指南：

图表：

- 保持您的图表小而易读 - 只包括重要的表格、关系和列 - 只有那些对于理解大局意义有任何意义的主/业务键、重要属性和关系。 - 在图表中使用不同的颜色来表示关键表格。 - 每个模块可以有多个图表。 - 您可以将图表添加到最重要的表格/具有最多关系的表格的描述中。

描述：

• 不要记录显而易见的内容 - 不要为document.date列编写描述“Document date”。 如果没有什么有意义的东西可以添加，就留空即可。
• 如果存储在表中的对象具有类型或状态，则最好在表的一般描述中列出它们。
• 定义预期的格式，例如，对于存储在文本字段中的日期，“mm / dd / yy”。
• 列出所有已知/重要值及其含义，例如，对于状态列，可以是这样的：“文档状态：A-活动，C-取消，D-删除”。
• 如果有任何API与表相关联 - 用于读取数据的视图和用于插入/更新数据的函数/过程 - 则将其列在表的描述中。
• 描述行/列的值来自哪里（过程、表单、接口等）。
• 对于不应使用的列（标题列对此很有用），请使用“[已弃用]”标记（或类似标记），并在描述字段中说明应该使用哪个字段代替。

- Bad Pitt

Answer 4

我们使用Enterprise Architect来定义数据库。我们包括在UML中定义的所有表定义、存储过程和触发器。该程序的三个杰出功能如下：

1. 通过ODBC连接从UML图导入
2. 一次生成整个数据库的SQL脚本（DDL）
3. 生成自定义模板化文档的数据库。

您可以在UML工具中编辑您的类/表定义，并生成一个包含图片的完全描述性文档。自动生成的文档可以是多种格式，包括MSWord。我们的模式中有不到100个表，这很容易管理。

我在10多年的开发经验中，从未对任何其他工具留下如此深刻的印象。EA支持Oracle、MySQL、SQL Server（多个版本）、PostGreSQL、Interbase、DB2和Access。每当我遇到问题时，他们的论坛都会及时回答我的问题。强烈推荐！！

当数据库更改发生时，我们在EA中进行更改，生成SQL，并将其检入版本控制（svn）。我们使用Hudson进行构建，它会从脚本自动构建数据库，当它看到您已修改检入的SQL时。

（大部分内容来自我的另一个答案）

- Kieveli

---

在EA中，我在哪里可以看到“生成自定义模板文档”？ - William Kinaan

让我们看看...我相信你在右边的某个地方右键单击，然后选择生成。这是5年前的版本。检查第8项：http://www.sparxsystems.com/products/ea/index.html - Kieveli

感谢您的回复。正确的操作是右键单击->文档->Rtch文本格式(RTF)报告，然后在“使用模板”字段中选择“数据模型模板”。 - William Kinaan

Answer 5

这篇答案是对Kieveli的回答的扩展，我点赞了他的回答。如果你使用的EA版本支持ORM（概念设计，而不是逻辑设计= ERD），请反向工程到ORM并使用它来填充具有表现力丰富性的模型。

另一个廉价且更轻量级的选择是从MS免费下载Visiomodeler，并使用它完成相同的操作。

ORMDB是我发现的唯一支持并鼓励与非IS利益相关者进行关于BL对象和关系的数据库设计讨论的工具。

现实检验-在生成DDL的过程中，它会通过完整的ERD阶段，你可以满足自己有关它是否出错的问题。它不会出错。它可能会向你展示你自己设计的ERD中的弱点。

ORMDB是一个经典案例，证明了工具越概念化，市场就越小。女孩们只想玩乐，程序员只想编码。

- le dorfier

---

ORM或对象角色建模由Terry Halpin在http://tinyurl.com/8h296m中详细解释。 - Ruben

对象角色建模与记录现有关系型数据库有什么关系？ - Gennady Vanin Геннадий Ванин

一种选择是使用反向工程功能来提取您的模式并加载它 - 在我的经验中，它运行良好。 - dkretz

Answer 6

一个wiki解决方案支持超链接和协作编辑，但是一个wiki的好坏取决于保持其组织和更新的人。你需要有人负责文件项目，无论使用什么工具。该人可能会让其他知识渊博的人填写详细信息，但应该由一人负责组织信息。

如果无法使用工具通过反向工程生成ERD，您将不得不手动使用TOAD或VISIO设计ERD。

任何具有数百个对象的ERD对开发人员来说可能都是无用的，因为其中有很多框和线条，会难以阅读。在具有如此多对象的数据库中，可能存在每个子系统包括几十个表和视图。因此，您应该制作这些子系统的自定义图表，而不是期望工具为您完成。

您还可以设计伪ERD，在一个图表中，将一组表格表示为单个对象，并在另一个图表中展开该组。

单个ERD或一组ERD对于文档化此类复杂系统是不足够的，就像类图对于文档化OO系统也是不够的。您需要编写文档，使用ERD作为说明图。您需要对每个表，每个列以及表之间的关系进行文字描述（特别是在这些关系是隐含的而不是由引用完整性约束表示的情况下）。

所有这些都需要很多工作，但是这将是值得的。如果有一个清晰而最新的地方记录了模式，整个团队都将从中受益。

- Bill Karwin

---

Bill - 你曾经使用过Visiomodeler（ORM）等建模工具吗？ - dkretz

不，我从未使用过那个。但现在它似乎已经过时且不再受支持。 - Bill Karwin

这是事实；但目前还没有可替换它的插件（至少有一个SourceForge项目正在早期阶段开发VS插件，有趣的是。我本性上会忽略自己对它的宣传，但事实上它是超越ERD的重要一步。 - dkretz

我曾经使用过对象角色建模。它与记录已存在或新创建的数据库无关。 - Gennady Vanin Геннадий Ванин

Answer 7

如果向最终用户描述数据库是您的主要目标，Ooluk数据字典管理器可能会很有用。它是一个基于Web的多用户软件，允许您将描述附加到表和列，并允许在这些描述上进行全文搜索。它还允许您使用标签逻辑分组表格，并使用这些标签浏览表格。表格以及列可以被标记以查找跨您的数据库/数据库中的类似数据项。

该软件允许您使用API将元数据信息（如表名、列名、列数据类型、外键）导入到其内部存储库中。支持JDBC数据源内置，可以进一步扩展，因为API源分布在ASL 2.0下。它被编码为从许多RDBMS中读取COMMENTS / REMARKS。您始终可以手动覆盖导入的信息。关于表和列的存储信息可以使用自定义字段进行扩展。

数据字典管理器使用“数据对象”和“属性”术语，而不是表和列，因为它不是专门为关系数据库设计的。

注

• 如果需要描述数据库的技术方面，例如触发器、索引、统计信息等，则此软件不是最佳选择。但是可以使用超链接自定义字段将技术解决方案与此软件结合使用。
• 该软件不会生成ERD。

披露：我在开发此产品的公司工作。

- uncaught_exception

Answer 8

既然你有幸和同行一起工作，我建议你问问他们觉得什么方式最容易传达所需信息。我的公司有100多个表，我的老板给了我一个特定的表集合的ERD图。因此，你也可以尝试将一个庞大的ERD图分解成一堆更小、更易管理的ERD图。

- theman_on_vista

Answer 9

嗯，一张图胜过千言万语，所以我建议创建ER图，可以一眼看到表之间的关系，这是用纯文本描述很难做到的。

你不必在一个图中绘制整个数据库，将它分成几个部分。我们在工作中使用Visual Paradigm，但EA是一个很好的替代方案，ERWIN也是如此，毫无疑问还有很多其他同样好的替代品。

如果你有耐心，使用html来记录表和列会使你的文档更易于访问。

- James Piggot