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。）
