enterprise|visual| Data | Database Figure 5 is an example.
When you provide a reference scheme for an entity type, you do not need to repeat the schema when you specify the fact type later. Unlike entity types, value types (for example, EmployeeName [employee name], ROOMNR [room number]) do not refer to the scenario, because their instances are literal constants (for example, strings or numbers used to name or reference entities), so they can identify themselves. In Freeformmode, value types are identified by appending an empty bracket [()]. Examples of some of the fact types that use formal, freeform syntax are provided below:\
Employee (EMPNR) works For/employs Department (code) employee has EmployeeName () employee has MOBILENR () employee drives/is Driven by car (REGNR)
Now, use the Fact Editor (Fact Editor) to enter these fact types (using guided or Freeform input). After clicking the first three fact types
Apply(apply) button to add the fact type. After you enter the fourth fact type, click
OK(OK). This action adds the last fact type and closes the Fact Editor (Fact editor). These fact types are not yet displayed in the drawing window, but are now listed in the Business Rules editor. If you move the cursor over one of the Fact Editor (Fact Editor), the right side of it displays a
Edit(edit) button (see Figure 6). If you click
Edit(edit) button, the Fact Editor (Fact editor) pops up, showing the type of fact you want to edit. This action provides a way to add basic constraints and samples to the Fact Editor (Fact editor).
If the constraint applies only to one predicate, an internal constraint or an external constraint. Use the Fact Editor (fact editor) to declare the following internal constraints: intrinsic uniqueness, simple coercion, internal frequency, and ring constraints, but not internal collection comparison constraints (for example, exclusion constraints between two roles of the same predicate), external constraints (for example, An external uniqueness constraint or a set comparison constraint between two predicates, or a value constraint (for example, restricting the Sexcode [sex code] value to {M, F}). In fact, the constraints declared in the Fact Editor (Fact Editor) are best limited to simple internal uniqueness constraints and simple coercion constraints. There is a quick way to declare other types of constraints (see the second part of this series).
To add a constraint to the fact type displayed in the Fact Editor (Fact editor), select
Constraints(Constraint) tab. By default, the Constraints (constraint) pane combines uniqueness and mandatory constraints to make it more quickly specified. For example, in Figure 7, select "Exactly one" (which happens to be a) to represent "at least one" (at least a, mandatory) and "at most one" (up to a single, only) two situations. Constraint symbols and descriptive information are automatically displayed to help users see the results of the selection. If you do not want to use the default shortcut, open the
Database Modeling Preferences(Database Modeling Preferences) dialog box (Figure 4) and uncheck the option that indicates the combination of uniqueness and coercion (UM).
Add the following constraints and practice using the Fact Editor (fact Editor) to add constraints. In the current version of the tool, use "some" (some) in the final constraint to replace the "the same" (the same), indicating that the "drives" (owned) relationship is optional and many-to-many.
Each employee works for some Departmenteach employee in most one Departmenteach employee has some EMPLOYEENAMEEA CH Employee has at most one Employeenameeach employee has at most one mobilenrit was possible that same Employee drives More than one car and then the same car are driven by more than one Employee
Add an example to the fact type
It is best to include examples for all fact types. To add a constraint to the fact type displayed in the Fact Editor (Fact Editor), click
examples(sample) tab, and then enter enough examples to clarify the related constraints. For example, Figure 8 shows the
Employee works for DepartmentThree fact examples of fact types (employees working in departments). Here, Employees 101 and 102 are employed in the sales department (SLS) and employees 103 are employed in the marketing department (MKTG). This padding is consistent with our solution that each employee works in at most one department (the value in the first column is unique), but the same department can hire some employees (SLS is duplicated in the second column).
can use
Analyze(parse) button to request the tool, reduce the constraints in the example, or check for inconsistencies between the data and the constraint specification. Give it a try. This feature is useful for validating constraints.
Save model
To save the model, select the
File(file) menu, select
File | Save(File | Save), or click
Save(save) icon. Will be opened
SaveAs(Save As) dialog box. Select the folder where you want to save the model, add a file name for the model, and in the dialog box, click
Save(save) button, and then in the Properties dialog box, click
OK(OK). The saved file will use the extension. VSD (Visio document).
display sentence types on a drawing
To display the type of sentence that you entered using the Fact Editor (Fact Editor) in the chart, find the type of fact that interests you in the Business Rules editor. To select a series of consecutive fact types, hold down
ShiftKey, and select the first and last fact types for the series. All fact types (except the first type) are highlighted. Then, drag the fact type to the desired location on the drawing page.
Now, try doing this for the four fact types in the model. By default, the displayed chart, shown in Figure 9, allows you to optimize the display by moving the predicate text and object types back and forth.
Alternatively, open the Object Types pane in the Business rules (Business Rules) window, drag out one or more related object types, and then use the
Show Relationships(Show relationships) relationship options. For example, if you would
Employee(Employee) Object type onto the drawing page, right-click
Employee(employee) and select from the shortcut menu
Show Relationships(show relationship), the page will display the
EmployeeAll the relationships that the (employee) has. This showrelationships (display relationship) feature is useful in schema browsing and reverse engineering, one of many new features that were not previously available in VisioModeler or Visio Enterprise.
To map an ORM model to a logical database model, first add the ORM model to the Database model project, and then build it. From
File(file) menu, select
File | New | Database | Database Model Diagram (US units)(File | New | Database | Database Model Diagram (US unit), open the Logical database modeling solution. If you want to use a metric template, select the units (US)
Database Model Diagram(Database model diagram). The screen at this point, as shown in Figure 10, is just the size of the drawing window that I've narrowed significantly. You can use the Entity Relationship stencil to create a logical database model from scratch, but now we will export the database model from the ORM model.
To create a Database model project, use the
Database(database) menu, select
Database | Project | Add existing document(Database | Project | Add an existing document). will display
Add Document to Project(Add document to Project) dialog box. Use
Look in :field to browse to the saved ORM model, and then click
Open(open) button. The ORM model (the model named Jcm1.vsd) is listed in the Project window. On the main menu, click
Save(save) The icon, and give the filename (I chose ProjJCM1) to save the project file. The extension of the project file is also. vsd. The name and page of the current model are always listed in the title bar at the top of the screen. Figure 11 shows the screen that should be displayed at this time.
Now, from
Database(database) menu, select
Database | Project | Build(Database | project | Build) to create the logical model. The relational schema is generated automatically, and the result table scheme is displayed in the Tables and Views (table and view) window on the left side of the screen (see Figure 12).
To view these table scenarios on a chart, drag them onto the drawing page. As shown in Figure 13, there are two table scenarios with a foreign key connection between the scenarios. The name of each table is displayed with a shaded caption, and the columns are listed below the title. The primary key is underlined, marked with "PK", and displayed in the below of the column. The Force (NON-EMPTY) column is expressed in bold. The Foreign key column is marked FKN, where n is the number of the foreign key of the table. In this case, there is only one foreign key, which points to the primary key of the Employee table. The foreign key connection is actually the arrow from the foreign key to the target key.
In this case, the names of the tables and columns are automatically generated by default. In practical applications, we typically rename many of these names and change many of the default data types that have been selected. There are several configuration options that you can use to control how the names of tables and columns are generated. In practical applications, it is best to set the data type on the ORM model, where the object type corresponds to the conceptual domain. The correct data type will then automatically propagate all properties based on those fields. This article does not elaborate on such problems.
Building the physical database schema
In
Database(database) menu, click
Database | Generate(Database | Build), you can generate an internal schema for the selected target DBMS. When building a schema, users can choose to generate DDL scripts instead of using tools to build tables. Typically, the best Mr. is a DDL script for later execution in the selected DBMS. Follow the steps in the Build Wizard: Select a driver (for example, Microsoft®sql Server 2000), enter a database name (for example, MyDB), accept the default settings in the next screen, and select
Yes(yes) to view the generated DDL script, and then save the DDL script as a text file.
Summary
This article briefly describes basic information about creating a simple ORM model, mapping it to a logical database schema, and then mapping to a physical database schema. In subsequent articles, you will describe how to specify more powerful ORM models, including advanced constraints and nesting, and describe the logical database modeling feature in more detail. With the Employee ORM source model included with the sample file published with this product, you can have a rudimentary understanding of the more advanced features. If you have any constructive feedback on this article, please send me an email (TerryHa@microsoft.com).
Reference Bibliography
- Halpin, T. A. Object role Modeling:an Overview (English), msdn,2001 (also access to www.orm.net,1998).
- Halpin, t.a. "Object Role Modeling (Orm/niam)", Handbook on Architectures of Information Systems, chapter fourth, P. Bernus, K. mertins and G. Schmidt (heidelberg:springer-verlag,1998), you can also visit Www.orm.net (English).
- Halpin, T.a. " Information Modeling and Relational Databases (San Francisco:morgan Kaufmann publishers,2001) can also access http://www.mkp.com /books_catalog/catalog.asp? Isbn=1-55860-672-6 (English).
(This article was originally published in Inconcept, Inc., the Journal of conceptual modeling.) ）
