enterprise|visual|数据|数据库
图 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 DepartmentEach Employee works for at most one DepartmentEach Employee has some EmployeeNameEach Employee has at most one EmployeeNameEach Employee has at most one MobileNrIt 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 源模型，可以对更高级的功能有个初步了解。如果您对本文有任何建设性的反馈意见，请给我发送电子邮件(TerryHa@microsoft.com)。参考书目
- Halpin, T. A. Object Role Modeling: An Overview（英文），MSDN，2001（也可以访问 www.orm.net，1998）。
- 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（英文）。
- Halpin, T.A.“Information Modeling and Relational Databases”（San Francisco：Morgan Kaufmann Publishers，2001），也可以访问 http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-672-6（英文）。
（本文最初发表在 InConcept, Inc. 的 The Journal of Conceptual Modeling。）
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索数据库
， 编辑器
， 模型
， 图模型
， 类型
， 选择
， 类型约束
示例
visio和visual studio、visual studio visio、enterprise architect、dvd architect studio、studio enterprise，以便于您获取更多的相关知识。