Visual Studio .NET Enterprise Architect 中基于 Visio 的数据库建模：第一部分

摘要：本文是介绍 Microsoft Visual Studio .NET Enterprise Architect 中基于 Visio 的数据库建模组件系列文章中的第一篇，重点介绍该工具提供的对象角色建模 (ORM) 支持。

目录

• 简介
• 创建新的 ORM 模型
• 使用 Fact Editor（事实编辑器） 添加句子类型
• 使用 Fact Editor（事实编辑器） 添加基本内部约束
• 在事实类型中添加示例
• 在绘图上显示句子类型
• 将 ORM 模型映射到逻辑数据库模型
• 总结
• 参考书目

简介

Microsoft® Visio® Enterprise 2000 中的数据建模解决方案为使用对象角色模型 (ORM) 进行概念性信息分析，以及使用关系、IDEF1X、Crowsfoot 和对象关系表示法进行逻辑数据库建模提供了基本的支持。ORM 架构可以通过实施正向工程获得逻辑数据库架构，从中可以生成用于多种数据库管理系统 (DBMS) 的物理数据库架构。对物理数据库的结构实施反向工程可以获得逻辑数据库架构或 ORM 架构。最新发布的 Microsoft Visio 2002 产品只包含 Standard 版和 Professional 版，Professional 版包含了以前单独的 Technical 版，但不包含 Enterprise 版。虽然 Visio 2002 Professional 包含 ORM 模具，但仅用于绘图，因为它的 ORM 图表无法映射到逻辑数据库架构，并且无法通过实施反向工程从物理数据库获得。Visio 2002 Professional 包含数据库建模解决方案，用于定义新的逻辑数据库架构或从现有数据库对其实施反向工程，但是不能实施正向工程获得物理数据库架构。

Microsoft 曾经一度在其 Visual Studio 产品范围内支持数据库设计和程序代码设计（使用 UML）。在收购了 Visio Corporation 之后，Microsoft 有两种独立的产品（Visio Enterprise 和 Visual Studio）都支持数据库设计和 UML，从而在功能上有明显的重复。为了统一这些产品功能，首先 Visio Enterprise 内原有的深层建模解决方案已被增强并转移到 Microsoft 新产品 Visio for Enterprise Architects (VEA) 中（该产品包含在 Microsoft® Visual Studio® .NET Enterprise Architect 中）。这些基于 Visio 的建模解决方案都包含在 Visual Studio .NET Enterprise 的 Beta 2 中，随后发布的最终版本也会包括这些方案。VEA 中的深层 ORM 解决方案与 Visio Professional 中简单的 ORM 绘图模具完全不同，并且二者不能互相转换。不过，VEA 中的数据库建模解决方案可以从 Visio Professional 中导入，然后对其实施正向工程，获得 DDL 脚本或物理数据库架构。

本系列文章简单介绍了如何在 VEA 内使用数据库建模解决方案。Microsoft Corporation 已获得文中各方面信息（例如，公司名、产品名、用户界面）的商标权、版权或专利权。本文主要介绍 ORM 解决方案的基本内容，假定本文的读者已经熟悉 ORM 和关系数据库建模。ORM 的概述可从网上下载 [参考书目 1 和参考书目 2]。ORM 的深层处理和数据库建模将在我最新出版的书 [参考书目 3] 中讨论。

创建新的 ORM 模型

基于 Visio 的建模工具在 Visual Studio .NET Enterprise Architect 中作为独立的解决方案运行。打开该工具时，Beta 版的打开屏幕如图 1 所示。选择 Database （数据库）作为绘图类型，然后选择相关 ORM 模板。如果用户所在地为美国，通常选择 ORM Source Model (US units)，如下所示（默认的页面大小为 Letter，默认的度量单位为英寸）。将光标悬停在模板图标上时，图标将突出显示并在左侧显示工具提示。Visio 提供美国版本和国际（公制）版本两种模板。如果选择不带 (US units) 的 ORM Source Model，默认的页面大小为 A4，默认单位为公制。

注意：在最终的版本中，除非选择其他版本，否则仅安装适用于用户所在国家/地区的标准单位系统。

选择 ORM 源模型模板时，将显示如图 2 所示的屏幕。除了位于顶部的菜单和图标外，还有一个 ORM 模具、一个 Drawing（绘图）窗口和一个用于显示 Business Rules 编辑器、数据库属性表以及可能打开的其他窗口（例如，Verbalizer（描述器））的区域。

图 1：选择使用 ORM Source Model（ORM 源模型）（单击图像以查看大图片）

图 2：ORM 模具、Drawing（绘图）窗口和 Business Rules（业务规则）窗口（单击图像以查看大图片）

为了减少图 2 所占用的空间，我已经对其显示的大小作了最大程度的调整。通常 Drawing 窗口将占据大部分屏幕。默认情况下，ORM 模具中的三种形状显示在同一水平行中。通过减少 ORM 模具的宽度使三种形状垂直排列，可以为 Drawing 窗口提供更多空间，如此处所示。要调整模具宽度，请将光标悬停在模具和绘图窗口之间的边框上，光标变为调整大小光标时，将边框向左侧拖动。

使用 Fact Editor（事实编辑器） 添加句子类型

通过将 Object Type（对象类型）和 Predicate（谓词）形状从模具拖到 Drawing 窗口，可以将句子类型（事实类型或引用类型）添加到 ORM 模型中。另外，还可以使用 Fact Editor（事实编辑器）添加句子类型。现在，让我们使用 Business Rules 编辑器来进行此操作。将光标移到 Business Rules（业务规则）窗口中的 Fact Types（事实类型）窗格的底端行（在本例中只有一行）。输入事实类型或按 F2 键。显示 Fact Editor（事实编辑器）。还可以通过从屏幕顶部的 Database（数据库）菜单中选择 Database|View|Fact Editor （数据库|视图|事实编辑器）来调用 Fact Editor（事实编辑器）。默认情况下，Fact Editor （事实编辑器）的输入样式是 Guided（导向），如图 3 所示。

图 3：使用 Guided （导向）输入样式窗口的 Fact Editor（事实编辑器）（单击图像以查看大图片）

可以输入二元关系，提供正向阅读（例如，Employee works for Department[雇员就职于部门]）和反向阅读（例如，Department employs Employee [部门雇用雇员]）方式。如果需要，可以从二元中选择不同的设置更改关系中的数量（角色数目）。Object 窗格允许用户将对象类型分为实体类型、值类型或外部对象类型。如果实体类型具有简单的标识方案，则可以添加其引用模式（例如，雇员编号和部门代码）。

熟悉 Fact Editor（事实编辑器） 后，您可能希望将其输入样式更改为 Freeform（自由绘制），这样就可以通过使用正式语法更加快捷地输入句子类型。要将输入样式更改为 Freeform，可以使用选项按钮，还可以通过以下步骤使 Freeform 成为默认类型：转到屏幕顶部的 Database（数据库） 菜单，选择 Database | Options | Modeling...（数据库 | 选项 | 建模...），然后打开 Fact Editor （事实编辑器）窗格并将首选模式设置为 Freeform，如图 4 所示。在许多语言中，通过首字母大写命名对象类型，将其名称假设为一个词语（例如 Employee [雇员] 和 VicePresident [副总统]），可以很方便地标识对象类型。对于不适于使用这种方法的语言，或当名称由以空格分隔的多个词语组成时，应该选择括号模式：将对象类型名称用方括号括起来（例如，[employee]、[vice president]）。

图 4：将 Fact Editor（事实编辑器） 的默认输出样式设置为 Freeform

在 Freeform 模式中，引用模式显示在对象类型名称后面的括号中。如果应用了反向阅读，则使用反斜杠 (/) 来区分正向阅读和反向阅读。

图 5 为一个示例。

图 5：使用 Freeform 输出样式的 Fact Editor（事实编辑器）（单击图像以查看大图片）

为实体类型提供引用方案后，就不需要在以后指定事实类型时重复引用方案了。与实体类型不同，值类型（例如，EmployeeName [雇员姓名]、RoomNr [房间号]）没有引用方案，由于其实例仅为文字常数（例如，用于命名或引用实体的字符串或数字），因此它们可以标识其自身。在 Freeform 模式中，值类型通过附加空括号 [()] 来标识。下面提供了使用正式的、自由绘制语法的某些事实类型的示例：

Employee(empNr) works for / employs Department(code)
Employee has EmployeeName()
Employee has MobileNr()
Employee drives / is driven by Car(regNr)

现在，使用 Fact Editor （事实编辑器）输入这些事实类型（使用 Guided 或 Freeform 输入）。单击前三个事实类型后面的 Apply（应用） 按钮添加事实类型。输入第四个事实类型后，单击 OK（确定）。此操作将添加最后一个事实类型，并关闭 Fact Editor（事实编辑器）。这些事实类型尚未显示在绘图窗口中，但是现在已列在 Business Rules 编辑器中了。如果将光标移到其中一个 Fact Editor （事实编辑器）上，其右侧将显示一个 Edit（编辑） 按钮（参阅图 6）。如果单击 Edit（编辑） 按钮，将弹出 Fact Editor（事实编辑器），显示要编辑的事实类型。此操作提供了一种在 Fact Editor（事实编辑器） 中添加基本约束和示例的方法。

图 6：事实类型列在 Business Rules 编辑器中，并且可以编辑（单击图像以查看大图片）

使用 Fact Editor（事实编辑器）添加基本内部约束

如果约束仅应用到一个谓词，则为内部约束，否则为外部约束。使用 Fact Editor（事实编辑器） 可以声明以下内部约束：内部唯一性、简单强制、内部频率和环式约束，但不能指定内部集合比较约束（例如，同一谓词的两个角色之间的排斥约束）、外部约束（例如，外部唯一性约束或两个谓词之间的集合比较约束）或值约束（例如，将 Sexcode [性别代码] 值限制为 {M, F}）。实际上，Fact Editor（事实编辑器） 中声明的约束最好限制为简单内部唯一性约束和简单强制约束。要声明其他类型的约束，有一个快捷方法（请参阅此系列文章的第二部分）。

要向 Fact Editor（事实编辑器）中显示的事实类型添加约束，请选择 Constraints（约束）选项卡。默认情况下，constraints（约束）窗格将唯一性和强制性约束组合在一起，以便更快地对其做出指定。例如，在图 7 中，选择“exactly one”（恰好为一）表示“at least one”（至少一个，强制）和“at most one”（至多一个，唯一）两种情况。约束符号和描述信息将自动显示，以帮助用户查看选择的结果。如果不想使用默认的快捷方式，请打开 Database Modeling Preferences（数据库建模首选参数）对话框（图 4），并取消选中指示组合了唯一性和强制性的选项 (UM)。

图 7：在 Fact Editor（事实编辑器） 中添加约束（单击图像以查看大图片）

请添加以下约束，练习使用 Fact Editor（事实编辑器）添加约束。在当前版本的工具中，在最终的约束中使用“some”（某些）取代“the same”（同一），表示“drives”（拥有）关系是可选的并且是多对多的关系。

Each Employee works for some Department
Each Employee works for at most one Department
Each Employee has some EmployeeName
Each Employee has at most one EmployeeName
Each Employee has at most one MobileNr
It is possible that the same Employee drives more than one Car and that 
   the same Car is driven by more than one Employee

在事实类型中添加示例

最好为所有事实类型包含示例。要向 Fact Editor（事实编辑器） 中显示的事实类型添加约束，请单击 Examples（示例）选项卡，然后输入足够的示例以阐明相关约束。例如，图 8 显示了 Employee works for Department（雇员就职于部门）事实类型的三个事实示例。此处，雇员 101 和 102 就职于销售部门 (SLS)，而雇员 103 就职于市场部门 (MKTG)。这种填充与我们的解决方案一致，即每个雇员就职于至多一个部门（第一列中的值是唯一的），但是同一部门可以雇用一些雇员（SLS 在第二列中是重复的）。

图 8：为 Employee works for Department （雇员就职于部门）添加示例事实实例（单击图像以查看大图片）

可以使用 Analyze（分析） 按钮来请求工具，减少示例中的约束，或者检查数据和约束规范之间是否存在不一致。自己试一试。此功能对于验证约束十分有用。

保存模型

要保存模型，请从 File （文件）菜单中选择 File | Save（文件 | 保存），或单击 Save （保存）图标。将会打开 SaveAs （另存为）对话框。选择要保存模型的文件夹，为模型添加文件名，在对话框中单击 Save（保存）按钮，然后在 properties 对话框中单击 OK（确定）。保存的文件将使用扩展名 .vsd（Visio 文档）。

在绘图上显示句子类型

要在图表中显示使用 Fact Editor（事实编辑器） 输入的句子类型，请在 Business Rules 编辑器中找到感兴趣的事实类型。要选择一系列连续的事实类型，请按住 Shift 键，并选择该系列的第一个和最后一个事实类型。所有事实类型（除第一个类型外）将突出显示。然后，将事实类型拖到绘图页面上所需的位置。

现在，请尝试对模型中的四个事实类型执行此操作。默认情况下，显示的图表如图 9 所示，您可以通过来回移动谓词文本和对象类型来优化显示。

另一种便捷的方法是，打开 Business Rules（业务规则）窗口中的 Object Types（对象类型）窗格，拖出一个或多个相关的对象类型，然后使用 Show Relationships（显示关系）关系选项。例如，如果将 Employee（雇员）对象类型拖到绘图页面上，用鼠标右键单击 Employee （雇员）并从快捷菜单中选择 Show Relationships（显示关系），则在该页上将显示 Employee（雇员）所具有的所有关系。这个 ShowRelationships（显示关系）功能在架构浏览和反向工程中非常有用，它是以前在 VisioModeler 或 Visio Enterprise 中未提供的许多新功能之一。

图 9：通过从 Business Rules（业务规则）编辑器中拖动四种事实类型而形成的图表

将 ORM 模型映射到逻辑数据库模型

要将 ORM 模型映射到逻辑数据库模型，首先将 ORM 模型添加到数据库模型项目中，然后生成它。从 File（文件）菜单中，选择 File | New | Database | Database Model Diagram (US units)（文件 | 新建 | 数据库 | 数据库模型图表 (US 单位)），打开逻辑数据库建模解决方案。如果要使用公制模板，请选择不带 (US units) 的 Database Model Diagram（数据库模型图表）。此时的屏幕如图 10 所示，只是绘图窗口的大小已被我明显缩小了。可以使用 Entity Relationship 模具来从头创建逻辑数据库模型，但是现在，我们将从 ORM 模型中导出数据库模型。

图 10：逻辑数据库建模解决方案（单击图像以查看大图片）

要创建数据库模型项目，请从 Database（数据库）菜单中选择 Database | Project | Add existing document（数据库 | 项目 | 添加现有文档）。将显示 Add Document to Project（将文档添加到项目中）对话框。使用 Look in: 字段浏览到保存的 ORM 模型，然后单击 Open（打开） 按钮。在项目窗口中将列出 ORM 模型（此处的模型名为 JCM1.vsd）。单击主菜单上的 Save（保存） 图标，并给出文件名（我选择了 ProjJCM1）来保存项目文件。项目文件的扩展名也是 .vsd。当前模型的名称和页面始终列在屏幕顶部的标题栏中。图 11 显示了此时应显示的屏幕。

图 11：包含 ORM 源模型的数据库项目（单击图像以查看大图片）

现在，从 Database（数据库） 菜单中选择 Database | Project | Build（数据库 |项目 | 生成），来创建逻辑模型。关系架构自动生成，并且在屏幕左侧的 Tables and Views （“表和视图”）窗口中显示结果表方案（参阅图 12）。

图 12：通过映射 ORM 模型建立的两个表方案（单击图像以查看大图片）

要在图表上查看这些表方案，请将其拖到绘图页面中。结果如图 13 所示，有两个表方案，方案之间由一个外键连接。每个表的名称以阴影标题显示，标题的下方列出了各列。主键带下划线，用“PK”标记，并显示在该列的顶格中。强制（非空）列以粗体表示。外键列标记为 FKn，其中 n 是表外键的编号。本例中只有一个外键，指向 Employee 表的主键。外键连接其实就是从外键到目标键的箭头。

图 13：从 ORM 模型映射的关系架构

在本例中，表和列的名称将在默认情况下自动生成。在实际应用中，通常我们会重命名其中的许多名称，并且更改已选择的许多默认的数据类型。有多种配置选项，可用来控制表和列的名称的生成方式。在实际应用中，最好在 ORM 模型上设置数据类型，在该模型上，对象类型对应于概念上的域。然后，正确的数据类型将自动基于这些域传播所有属性。本文对此类问题不加详述。

生成物理数据库架构

在 Database（数据库）菜单中单击 Database | Generate（数据库 | 生成），可以生成所选目标 DBMS 的内部架构。生成架构时，用户可以选择生成 DDL 脚本，而不是使用工具建立表。通常最好先生成 DDL 脚本，以便以后在所选的 DBMS 中执行。请遵循生成向导中的步骤：选择驱动程序（例如 Microsoft® SQL Server 2000），输入数据库名称（例如 mydb），接受下一屏幕中的默认设置，选择 Yes（是） 以查看生成的 DDL 脚本，然后将 DDL 脚本保存为文本文件。

总结

本文简单介绍了有关创建简单 ORM 模型，将其映射到逻辑数据库架构，然后再映射到物理数据库架构的基本信息。在后续的文章中，将阐述如何指定更加强大的 ORM 模型（包括高级约束和嵌套），并更详细地介绍逻辑数据库建模功能。使用随本产品发布的示例文件中包含的 Employee ORM 源模型，可以对更高级的功能有个初步了解。如果您对本文有任何建设性的反馈意见，请给我发送电子邮件。

参考书目

1. Halpin, T. A. Object Role Modeling: An Overview（英文），MSDN，2001（也可以访问 www.orm.net，1998）。
2. Halpin, T.A. “Object Role Modeling (ORM/NIAM)”，Handbook on Architectures of Information Systems 的第四章，P. Bernus, K. Mertins 和 G. Schmidt 编（Heidelberg：Springer-Verlag，1998），也可以访问 www.orm.net（英文）。
3. Halpin, T.A.“Information Modeling and Relational Databases”（San Francisco：Morgan Kaufmann Publishers，2001），也可以访问 www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-672-6（英文）。

（本文最初发表在 InConcept, Inc. 的 The Journal of Conceptual Modeling。）

本文地址：http://com.8s8s.com/it/it46194.htm