Fact-oriented modeling approaches such as Object-Role Modeling ORM include a rich graphical notation for capturing business constraints, allowing modelers to visualize fine details of their data models. These data models should be validated with domain experts who best understand the business requirements, even if unfamiliar with the graphical notation. Hence, the data models are best validated by verbalizing the models in a controlled natural language, and by populating the relevant fact types with examples. Comparatively little support exists for verbalizing fact-based models in non-English languages, especially Asian languages. This paper describes the authors' work on verbalizing ORM models in Bahasa Melayu Malay and Mandarin. The authors specify some typical transformation patterns, discuss features of these languages requiring special treatment e.g. noun classifiers, repositioning of modal operators, and different uses for terms equivalent to "who" and "that" in English, and describe their current implementation efforts.

This appendix provides a brief summary of many of the most useful operators and predicates that are pre-defined in LogiQL.

When using natural language, people typically refer to individual things by using proper names or definite descriptions. Data modeling languages differ considerably in their support for such linguistic reference schemes. Understanding these differences is important for modeling reference schemes within such languages and for transforming models from one language to another. This article provides a comparative review of reference scheme modeling within the Unified Modeling Language version 2.5, the Barker dialect of Entity Relationship modeling, Object-Role Modeling version 2, relational database modeling, and the Web Ontology Language version 2.0. The author identifies which kinds of reference schemes can be captured within these languages as well as those reference schemes that cannot be. The author's analysis covers simple reference schemes, compound reference schemes, disjunctive reference and context-dependent reference schemes.

Fact-oriented modeling approaches such as Object-Role Modeling (ORM) have long supported several varieties of ring constraints, such as irreflexivity, asymmetry, intransitivity, and acyclicity, on pairs of compatible roles. The latest version of the Web Ontology Language (OWL 2) supports five kinds of ring constraint on binary predicates. Recently, three more ring constraint types (local reflexivity, strong intransitivity, and transitivity) were added to ORM. This paper discusses these new additions to ORM, as implemented in the Natural ORM Architect (NORMA) tool, and identifies important ways in which ORM and OWL differ in their support for ring constraints, while noting different mapping alternatives. We determine which combinations of elements from this expanded set of ring constraints are permitted, and provide verbalization patterns for the new additions. Graphical shapes for the new constraints and constraint combinations are introduced and motivated, and NORMA's new user interface for entry of ring constraints is illustrated.

This chapter discusses the configuration, manipulation, and reuse of object-role modeling (ORM) models. ORM modeling solution tool applies various default settings to determine how it displays the user interface and how it reacts to certain user commands. These settings can be changed to suit the personal preferences by entering personal choices in the Database Modeling Preferences dialog. To access this dialog, Database > Options > Modeling should be chosen from the main menu. The dialog includes Fact Editor and ORM Diagram panes for setting ORM preferences. The other two panes deal with preferences for the logical modeling solution. The Object type name field allows controlling the base default name for new object types. By default, this is “Object.” The Append ordinal check box is used to append numbers 2, 3, etc., to the default names of second and later object types. In an ORM schema, object types may be connected by predicates and/or subtype relationships. Graphically, a predicate is depicted as a named sequence of one or more role boxes and a subtype relationship is depicted as an arrow from subtype to super type. Each object type is either an entity type or a value type and is defined in exactly one model. It is possible to define an object type or predicate in one model and then reference it from one or more other models.

Object-role modeling (ORM) object type is either a value type or an entity type. A value corresponds to an entry in a table and is denoted as a character string or numeric constant (e.g., “Ireland,” 56). A value identifies or refers to itself, so there is no need to specify a reference scheme (identification scheme) for it. An entity is identified by the means of a reference scheme that uses one or more values. A simple reference scheme uses only one value (e.g., the Country with the Country Code “US”). Therefore, the country code “US” is a value, but the actual country (the United States of America) is an entity. Entities and values in an ORM model correspond to real world objects in the application domain, not tables and columns in the logical database model. The Visio tool allows an object type to be declared external. This means that the object type is previously defined (either as an entity type along with its associated reference scheme or as a value type) in another model and is simply being reused, so there is no need to redefine it in the current model. The Visio tool also allows adding new object types and editing them using the Business Rules window, the Fact Editor, or the ORM Source stencil. In ORM, an object type is said to be an independent object type if its instances can exist without playing other roles. Independent object types always map to a key, total table when the logical model is built (i.e., their identifier is used as the primary key of the table and the table contains all their instances).

This chapter gives an overview of forward engineering process, the process of transforming higher-level models to lower-level models that starts at the conceptual level object-role modeling (ORM) for mapping to the logical level (ER or relational) and generating the physical database model. The first stage of mapping ORM models to logical database models is called the build process. The second stage of transforming a logical database model to a physical database schema is called the generate process. It is best to first generate the data definition language (DDL) script containing the structured query language (SQL) statements for creating the relational schema. With some DBMSs, it can also generate the database schema directly if connected to the DBMS. When a logical database model is built from one or more ORM source models, the tool creates a project to house relevant documents. In addition to the logical database model, the project may contain nonsource documents, such as a text file that might be added to the project for further documentation. To transform a set of one or more ORM models to a logical database model, the ORM model(s) should be added first to a database model project for the purpose of project building.

This chapter describes the importing reverse engineering to object-role modeling (ORM). A database should always be developed applying the process of forward engineering from ORM to a logical model and then to a physical database schema. To reverse engineer, an existing database, an open database connectivity (ODBC) data source is needed to enable access to that database. Visio refers to a data source by a data source name (DSN). If the data source does not exist, it can be created using either the Windows ODBC Data Source Administrator dialog or Visio's Reverse Engineering Wizard. In addition to reverse engineering physical databases, the tool can import ORM models and logical models that are built using Visio Modeler or Info Modeler (version 1.5 onwards). To import such a model, first step is to open the ORM Source Model solution, for choosing the menu option Database > Import/Export and selecting the the relevant import option. For Visio Modeler files, options for ORM models, logical models, and dictionary files are distinguished by a relevant suffix (.IMO, .IML, .IMD, respectively). When the import dialog appears, path type and file name should be typed for the desired model, or the Browse button should be pressed to browse for and select the relevant file. After then the OK button should pressed to import the file.

This chapter covers several areas of importance, including how to get an object-role modeling (ORM) project started, model navigation, annotations, backgrounds, the Visio Reader, shape protection, and several other topics. Many of these topics are useful in extending the richness and features that Visio as a platform brings to the modeling team. It briefly explains two scenarios: a management presentation to get approval for a database modeling project and a typical domain expert fact review that would take place during the project. Scenario one discusses the fundamentals of getting approval for the database modeling project. This scenario can be used for any project by changing the content but keeping the structure. Scenario two is to get the project moving right along by getting the facts from domain experts, and this scenario is also used as a template for this task. Adapting the approach outlined in scenario one is a very helpful presentation for instant deployment.