如何记录数据库

由于您可以与处于同一条船上的其他开发人员一起工作，因此我建议询问他们的感受，以便最容易地传达所需的信息。我的公司有超过100张桌子，我的老板给了我一个 ERD，用于一个特定的桌子，所有的桌子都连接在一起。所以，你也许想尝试把一个大规模的 ERD 分解成一堆更小的、可管理的 ERD。

需要考虑的一件事是内置在 DBMS 中的 COMMENT 工具。如果将注释放在 DBMS 本身的所有表和所有列上，那么您的文档将放在数据库系统中。

使用 COMMENT 工具不会对模式本身进行任何更改，它只是将数据添加到 USER _ TAB _ COMMENT 目录表中。

我们使用 企业架构师作为数据库定义。我们包括存储过程、触发器和 UML 中定义的所有表定义。该节目的三大亮点是:

1. 从 ODBC 连接导入 UML 关系图。
2. 一次为整个数据库生成 SQL 脚本(DDL)
3. 生成数据库的自定义模板文档。

您可以在 UML 工具中编辑您的类/表定义，并使用包含图片的文档生成一个完整的描述。自动生成的文档可以有多种格式，包括 MSWord。我们的模式中只有不到100个表，而且非常容易管理。

在我10多年的开发生涯中，我从未对任何其他工具如此印象深刻。EA 一举支持 Oracle、 MySQL、 SQLServer (多个版本)、 PostGreSQL、 Interbase、 DB2和 Access。任何时候我遇到问题，他们的论坛都会及时回答我的问题。强烈推荐! ！

当数据库发生更改时，我们在 EA 中进行操作，生成 SQL，并将其签入到版本控制(svn)中。我们使用 哈德森来构建数据库，当它看到您已经修改了签入的 sql 时，它会从脚本自动构建数据库。

(大部分都是从我另一个答案里偷来的)

Wiki 解决方案支持超链接和协同编辑，但 wiki 的好坏取决于保持其组织性和最新性的人。无论您使用什么工具，您都需要有人来获得文档项目的所有权。那个人可能需要其他知识渊博的人来填充细节，但是一个人应该负责组织信息。

如果你不能使用一个工具通过逆向工程生成 ERD，你就必须使用 TOAD 或 VISIO 手工设计一个。

任何有数百个对象的 ERD 对于开发人员来说可能都是没有用的，因为有这么多的方框和线条，它将是不可读的。在一个拥有如此多对象的数据库中，很可能存在由几十个表和视图组成的“子系统”。因此，您应该为这些子系统制作自定义图表，而不是期望一个工具为您完成这项工作。

您还可以设计一个伪 ERD，其中表组在一个关系图中由单个对象表示，而该组在另一个关系图中展开。

单个 ERD 或 ERD 的集合不足以记录这种复杂性的系统，任何类图都不足以记录面向对象系统。你必须写一个文件，使用 ERD 的作为插图。你需要文本描述每个表、每列的含义和用法，以及表之间的关系(特别是这种关系是隐式的而不是由参照完整性约束表示的)。

所有这一切都是大量的工作，但它将是值得的。如果有一个清晰和最新的地方记录了模式，整个团队都会从中受益。

这个答案延伸了基耶夫利的上述观点，我对此表示赞同。如果你的 EA 版本支持对象角色建模(楚格设计，对比逻辑设计 = ERD) ，对此进行逆向工程，然后用它给你带来的丰富表现力来填充模型。

廉价而轻量级的选项是从 MS 免费下载 Visiomodeler，并对其进行同样的操作。

ORM (称为 ORMDB)是我所发现的唯一一个支持和鼓励与非 IS 涉众就 BL 对象和关系进行数据库设计对话的工具。

现实检查的方式来生成您的 DDL，它通过一个完整的停止 ERD 阶段，您可以满足您的问题，是否有任何螺旋。不会的。它可能会显示出你自己设计的 ERD 的弱点。

ORMDB 是一个经典的案例，其原则是: 工具概念化程度越高，市场规模就越小。女孩子只想找乐子，程序员只想写代码。

根据我的经验，ER (或 UML)图并不是最有用的工件——对于大量的表来说，图(尤其是逆向工程的)通常是一团乱麻，没有人能从中学到任何东西。

在我看来，一些良好的人类可读的文档(也许还附有系统较小部分的图表)将为您提供最大的帮助。对于每个表，这将包括:

• 描述表的含义以及如何在功能上使用它(在 UI 中，等等)
• 描述每个属性的含义(如果不是很明显)
• 解释此表与其他表之间的关系(外键) ，反之亦然
• 附加约束和/或触发器的说明
• 如果主要的视图和过程没有被很好的记录下来，那么对它们进行额外的解释

综上所述，不要为了编写文档而编写文档——重述显而易见的事实的文档只会妨碍人们的工作。相反，把注意力集中在那些一开始让你感到困惑的事情上，花几分钟时间写出非常清晰、简洁的解释。这将帮助您仔细考虑，并且 非常严重将帮助其他第一次使用这些表的开发人员。

正如其他人所提到的，有各种各样的工具可以帮助您管理这些工具，比如 企业架构师、 红门 SQL 文档以及来自各种供应商的内置工具。但是，尽管工具支持很有帮助(在更大的数据库中甚至是至关重要的) ，但是完成 理解和 解释的艰苦工作，数据库的概念模型才是真正的胜利。从这个角度来看，你甚至可以在一个文本文件中做到这一点(尽管使用 Wiki 格式可以让几个人协作增量地添加文档——因此，每次有人弄明白了一些事情，他们就可以立即将其添加到不断增长的文档中)。

嗯，一张图片可以说明一千个单词，所以我建议创建 ER 图，在这里您可以一目了然地查看表之间的关系，这对于纯文本描述是很难做到的。

您不必在一个关系图中完成整个数据库，可以将它分成若干部分。我们在工作中使用可视化范式，但是 EA 和 ERWIN 一样是一个很好的选择，毫无疑问还有很多其他的选择也一样好。

如果您有足够的耐心，那么使用 html 来记录表和列可以使您的文档更容易访问。

在我们的团队中，我们找到了有用的方法来记录遗留的大型 Oracle 和 SQLServer 数据库。我们使用 再见记录数据库模式元素(数据字典)并创建 ERD 图。Dataedo 附带了文档存储库，这样所有团队都可以在线编写和阅读最近的文档。而且您不需要干扰数据库(Oracle 注释或 SQLServerMS _ Description)。

首先导入模式(所有表、视图、存储过程和函数——包括触发器、外键等)。然后定义逻辑域/模块，并将所有对象(拖放)分组到它们中，以便能够分析和处理较小的数据库块。对于每个模块，您创建一个 ERD 关系图并编写顶级描述。然后，当您发现表和视图的意义时，为每个表和视图写一个简短的描述。对每个列执行相同的操作。Dataedo 允许您为每个对象和列添加有意义的标题-如果对象名称不明确或无效，这很有用。专业版使您能够描述外键，唯一的键/约束和触发器-这是有用的，但不是必不可少的了解数据库。

您可以通过 UI 访问文档，也可以将其导出为 PDF 或交互式 HTML (后者只有 Pro 版本可用)。

这里所描述的是一个连续的过程，而不是一次性的工作。如果数据库发生变化(比如新列、视图) ，应该定期同步文档(使用 Dataedo 进行两次单击)。

参见示例文档: Http://dataedo.com/download/dataedo%20repository.pdf

关于文件处理的一些准则:

图表:

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

描述:

• 不要记录显而易见的东西——不要为 Document.date 列写描述“ Document date”。如果没有什么有意义的添加，只是留空,
• 如果存储在表中的对象具有类型或状态，最好在表的一般描述中列出它们,
• 定义预期的格式，例如将日期存储在文本字段中的“ mm/dd/广州欢聚时代”,
• 列出所有已知的/重要的值和它的含义，例如状态列可以是这样的: “文档状态: A-Active，C-Cancled，D-Delete”,
• 如果一个表有任何 API-一个应该用来读取数据的视图和插入/更新数据的函数/过程-在表的描述中列出它,
• 描述行/列的值来自哪里(过程、表单、接口等) ,
• 对不应该使用的列使用“[弃用]”标记(或类似的标记)(title 列对此很有用，解释应该在 description 字段中使用哪个字段)。

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

该软件允许您使用 API 将诸如表名、列名、列数据类型、外键等元数据信息导入其内部存储库。对 JDBC 数据源的支持是内置的，当 API 源在 ASL 2.0下发布时，可以进一步扩展。它被编码为读取来自许多 RDBMS 的注释/备注。您总是可以手动重写导入的信息。可以使用自定义字段扩展存储有关表和列的信息。

Data Dictionary Manager 使用“ Data object”和“ tribute”术语而不是 table 和 column，因为它不是专门为关系数据库设计的。

笔记

• 如果描述数据库的技术方面，例如触发器, 统计很重要，这个软件不是最好的选择。 然而，将技术解决方案与此相结合是可能的 使用超链接自定义字段的软件。
• 软件不会产生 ERD

我在开发这个产品的公司工作。