Database Modeling with Object Role Modeling

http://dotnet.sys-con.com/node/38984

It is no secret that proper modeling when developing complex, multitiered applications is vital to the success of a project. Countless studies investigating the poor success rate of enterprise-level application projects point to a lack of adequate modeling and design techniques as a major contributor to the dismal failure rate. By implementing consistent, proven modeling techniques, you facilitate communication between the business stakeholders and the application developers. Proper modeling helps to break up complex systems into smaller, more manageable structures and helps define the scope and requirements of the system.

As Microsoft continues to evolve the .NET languages, Visual Studio .NET, and SQL Server, the lines of distinction between application programmers and database programmers are increasingly blurring. In addition, as companies trim staff, application programmers are taking on responsibilities traditionally handled by database programmers. As a result, application developers need skills in modeling both the system's application interfaces and the database structures with which the system interacts.

Many developers are familiar with using Entity Relationship Diagrams (ERDs) to model relational databases. While ERDs are excellent tools for modeling the logical structure of a database, they are not well suited for developing the conceptual model. The conceptual model bridges the gap between the business requirements and the logical design of the system. Without properly developing a conceptual model before developing the logical and physical models of a database, the database is unlikely to meet the business requirements of the system and the application has a much greater risk of failure.

This article is the first in a series of articles that introduce Object Role Modeling (ORM). ORM is an excellent modeling methodology you can use to construct the conceptual database model. Object Role Modeling is an approach to describing data in terms of objects and the roles they play . An elementary fact is a statement affirming that an object has a property or participates in a relationship with one or more other objects. ORM expresses these elementary facts in a natural language that is easily understood and verifiable by the domain experts . In addition, ORM Source Modeling is supported by Microsoft and can be implemented using Visio for Enterprise Architects.

The Stages of Database Modeling
The process of developing a database to support business applications consists of a series of phases. The first phase involves developing the conceptual model. During this phase you work with the domain experts to define and confirm the business requirements. The domain experts are the people who have a clear understanding of the business process that the system is attempting to automate. They understand the data and the data processing that needs to occur. The domain experts include people responsible for data entry, data processing, and data analysis .

The next step after creating a conceptual model is the creation of the logical model . It is during this phase that the business requirements modeled in the conceptual stage transform into the tables, relationships, and constraints that will comprise the relational database . You create the conceptual model using ORM and transform the ORM model into the logical model. The more familiar Entity Relationship Model is often used to construct the logical database design. By using a modeling tool such as Visio, which supports both ORM and ERD modeling to create the conceptual model, the logical model can be auto-generated from the conceptual model.

The last stage of database modeling is the creation of the physical mode l . During this stage, the structure of the database as defined in the logical model is transformed into the actual implementation schema. This schema is dependent upon the database management system chosen, e.g., DB2, Oracle, or Microsoft SQL Server.

Fact-Driven Design
The first step in creating the conceptual model is to gather facts about the data. Interviewing the domain experts and reviewing current record-keeping forms along with the required data analysis reports reveals the data types and the data relationships that will comprise the system. The data facts are then broken down into fact types . A fact type is a single assessment of the relationship between data values. Fact types consist of natural-language action statements that are easily verifiable by the domain experts. For example, "a member borrows a book" is a fact type pertaining to a library loan application.

The fact type is composed of object types and a predicate. The noun phrases identify the object types ; in the previous example, "member" and "book" are object types. Object types can be entities or values . Entities represent a person, place, or thing. Both the member and the book represent entity types. Values are simple properties of entity types. For example in the fact type "a book has a title", "title" represents a value type . In order to identify an instance of an entity type, it must be associated with a value type that distinguishes the instance from other instances of the same type. For example, you can identify an instance of a member by social security number and a book by its International Standard Book Number (ISBN). The identifying value of an object type is its reference mode.

Predicates define the relationship between object types. The verb phrase in the fact type identifies the predicate . In the fact type "a member borrows a book", "borrows" is the predicate. An important feature of the predicate is the ability to reverse the reading . Instead of "a member borrows a book", we can write it as "a book is borrowed by a member". Another feature of the predicate is its arity ; the number of roles the predicate is involved in determines the arity. A unary predicate involves one role, a binary two roles, a ternary three roles, and so on. The fact type "a member borrows a book" contains a binary predicate because two roles are involved in the predicate, "member" and "book". An example of a unary predicate in a fact type is "a book is overdue". In this case, the predicate involves only one role played by the "book". An example of a ternary predicate is contained in the fact type "member is contacted at location during time" this predicate involves three roles: "member", "location", and "time". The most common predicate type is the binary. When constructing a fact type, make sure it is elementary . A non-elementary fact type is actually composed of two or more fact types. The fact type "member borrows book identified by ISBN" is not ternary but rather comprised of two binary-predicated fact types: "member borrows book" and "book is identified by ISBN".

Visualizing Fact Types
After identifying the fact types that make up the data use cases, the next stage in the development of the ORM model is the creation of a visualization of the fact types . As the old adage says, "A picture is worth a thousand words." In an ORM diagram, ovals represent object types, while rectangular boxes represent predicates. Figure 1 represents the visualization of the fact type "member borrows book". Since this is a binary-predicated fact type, the predicate rectangle consists of two sections (role boxes). Lines connect the object types to the role they play in the predicate. The border of the oval distinguishes entity types from value types . A dashed border indicates a value type, while the entity type's border is solid. Figure 2 symbolizes the fact type "book has page count", where "book" is an entity type and "page count" is a value type. Notice that the "book" entity includes the ISBN value type in parentheses. The ISBN represents the reference mode of the "book" entity. As a final example, Figure 3 shows a unary-predicated, a binary-predicated, and a ternary-predicated fact type - all involving the "book" entity.

 

 

 

 

Using Visio to Construct an ORM Model
Now that you are familiar with some of the notations used to construct an ORM model, you are ready to investigate the use of Visio to create such a model. Note:  You need Visio for Enterprise Architects in order to create an ORM Source Model.
1.  Start up Visio. From the File menu, choose New > Database > ORM Source Model.
2.  If the Business Rules editor (see Figure 4) is not visible at the bottom of the window, choose View > Business Rules from the Database menu.

 

3.  Double-click the first Object Type cell in the Business Rules editor. Create a Member entity object type with a reference mode of MemberNo. Repeat this procedure, entering the object types shown in Figure 5. Note:  Do not worry about the Physical Data Type at this time.

 

4.  Select the Fact Types tab at the bottom of the Business Rules editor. Press the F2 key to launch the Fact Editor window. Using the left Object dropdown, choose Member. In the relationship textbox enter "borrows". In the right object dropdown, choose Book. Figure 6 shows the completed entries. Notice the bottom of the window contains the natural language syntax expression of the fact type. This natural language syntax plays an important role when verifying the model with the domain experts. Click Apply to save the fact type.

 

5.  Repeat Step 4 to enter the fact types shown in Figure 7. Notice that there is a unary-predicated and a ternary-predicated fact type.

 

6.  Click and drag the fact types from the Business Rules editor onto the drawing surface. After a little rearranging, your completed diagram should look similar to Figure 8. Save the ORM model and close Visio.

 

Review
This article has introduced you to Object Role Modeling. ORM is an excellent aid for modeling the data and data relations that will comprise the back-end database structure of your application. The real strength of ORM is its ability to extract the business data requirements from the domain experts into a conceptual model that is easily understood and verifiable by those same domain experts. By spending time creating a thorough and accurate conceptual model, the application's chances of success as it progresses to the logical and physical stages significantly increase.

This article focused on identifying object types and fact types. The various common types of predicate arities were discussed and the use of Visio to construct an ORM source model was demonstrated. In a future article I will continue the study of ORM source modeling using Visio. I will cover primitive entity types, subtypes, derived fact types, and unique constraints. In addition, I will demonstrate the process of applying population checks to verify the the ORM model.

Object Role  Modeling  ( ORM ) is an excellent  modeling  methodology that you can use to construct a conceptual  database  model. This article is the second in a series of articles that introduce  ORM .

Object Role  Modeling  is an approach to describing data in terms of objects and the roles they play. An elementary fact is a statement affirming that an object has a property or participates in a relationship with one or more other objects.  ORM  expresses these elementary facts in a natural language that is easily understood and verifiable by the domain experts. In addition,  ORM  source  modeling  is supported by Microsoft and can be implemented using Visio for Enterprise Architects.

The focus of the first article in this series (.NETDJ , Vol.1, issue 10) was working with domain experts to identify the various object types and fact types that need to be included in a conceptual model. It introduced the various common types of predicate arities, as well as the use of Visio to construct an ORM  source model. This article continues the study of  ORM  source  modeling  using Visio. The process of developing a  database  model is iterative and involves the continual refinement and verification of the various fact types and object types that make up the model. This article introduces some of the concepts involved in the refinement process. It focuses on the concepts of primitive entity types, subtypes, derived fact types, and unique constraints. In addition, this article covers the process of using Visio to incorporate the concepts into an  ORM  model.

Primitive Entity Types, Subtypes, and Derived Fact Types
As you develop the  database  model using  ORM  you need to continually refine and verify the model. One of the tasks of model refinement is to ensure that the entity types defined in the model are in primitive form. Primitive entity types are mutually exclusive, which means the populations of the entity types do not overlap. As an example, you may be tempted to model the fact type verbalizations "a class begins at start time" and "a class is over at end time," as shown in Figure 1. In reality, the entity types "start time" and "end time" are not mutually exclusive. The primitive entity type "time" plays both roles, "start time" and "end time", in these fact types. Figure  2  shows the updated representation of the fact types.

 

 

As you examine your  database  model you may find that some of the entity types have common characteristics or that a fact type needs to be expanded to include similar entity types. For example, the fact type "a parking permit is issued for a car" is examined, and it is determined that this needs to be expanded to include motorcycles. Cars and motorcycles share many common characteristics. An atomic primitive entity type "vehicle" becomes a supertype in the model. The entity types "car" and "vehicle" become subtypes of the "vehicle" primitive entity type. Figure 3 demonstrates how subtypes are modeled using  ORM . A solid arrow connects the subtype to the primitive entity supertype pointing toward the supertype.

 

In the initial stages of your  database  design, you may have identified entity types that are not primitive entity types but rather are the result of a derivation from primitive entity types. As an example, consider the fact type "class lasts for duration". You may be tempted to model the role "duration" as a primitive entity type. In reality, the fact type "class lasts for duration" is a derived fact type. It derives from the role "time" in the fact types "class begins at time" and "class ends at time". Figure 4 shows the  ORM  representation of the derived fact type "class lasts for duration". The asterisk appended to the predicate shape indicates that "duration" is a derived (through a query) entity type.

CIO, CTO & Developer Resources

 

Modeling  Subtypes and Derived Fact Types in Visio 
The following activity demonstrates adding subtypes and derived fact types to a Visio  ORM  model. Note: You need Visio for Enterprise Architects in order to create an  ORM  source model.

Modeling  Subtypes:

1. Start up Visio. From the File menu, choose New >  Database  >  ORM  Source Model.
2. If the Business Rules Editor (see Figure 5) is not visible at the bottom of the window, choose View > Business Rules from the  Database  menu.

 

1. Double-click the first Object Type cell in the Business Rules Editor. Create a Vehicle entity object type. Repeat this procedure to create Car, Motorcycle, and Parking Permit entity object types. Note:  Do not worry about the Physical Data or Reference Mode at this time.
2. Select the Fact Types tab at the bottom of the Business Rules Editor. Press the F2 key to launch the Fact Editor window. Using the left Object dropdown list, choose Parking Permit. In the relationship text box enter "is issued for". Choose Vehicle from the right object dropdown list. Figure 6 shows the completed entries. Notice that the bottom of the widow contains the natural language syntax expression of the fact type. This natural language syntax plays an important role in verifying the model with the domain experts. Click OK to save the fact type and close the window.

 

1. Click and drag the fact type from the Business Rules Editor onto the drawing surface. Drag the Car and Motorcycle object types onto the design surface and arrange them to the right of the Vehicle object type.
2. From the object toolbox window, drag a Subtype Relationship arrow to the design surface. Attach the tail to the Car object type and the head to the Vehicle object type. Repeat this procedure to connect the Motorcycle object type to the Vehicle object type. The completed diagram should resemble Figure 3.
3. Select the Car object type in the diagram. In the Business Rules Editor select the Data Base properties tab. Select Subtype from the Categories dropdown list. Notice that the Vehicle Object type is designated as the Primary supertype (see Figure 7).

 

Modeling  a Derived Fact Type:

1. Using the Business Rules Editor, create a class entity object type, a Time value type, and a Duration value type. Note: Do not worry about the Physical Data or Reference Mode at this time.
2. Using the Fact Editor, create "Class starts at Time", "Class ends at Time", and "Class lasts for Duration" fact types.
3. Click and drag the fact types from the business rules editor onto the drawing surface.
4. Right-click the "starts at" predicate phrase on the design surface and choose  Database Properties in the pop-up menu. In the  Database  Properties Editor, select Readings in the Categories list. Enter a role name of "StartTime" in the Role name text box (see Figure 8). Repeat this procedure to add a Role name of "EndTime" for the "ends at" predicate phrase.

 

1. Right-click the "lasts for" predicate phrase on the design surface and choose  Database Properties from the pop-up menu. In the  Database  Properties Editor, select Derived in the Categories list. Click on the Derived option button and enter a rule definition of "Class.EndTime – Class.StartTime" in the Rule text box (see Figure 9). Notice that an asterisk is appended to the predicate phrase on the design surface. The completed diagram should look similar to Figure 4.

 

Identifying Constraints
Enforcement of constraints is fundamental to designing the structure of relational data. Constraints limit the involvement of roles within the defined predicates. Remember that predicates are verb phrases defining the relationships between the various roles defined in the model. If you are designing a  database  system to track students enrolled at a computer-training center, a valid fact type could be "a student has a last name".

In addition to defining the fact type, you often need to define conditions for the fact type. These conditions usually take the form of constraints. For example, if you want to ensure that every student has a last name recorded, you need to define a mandatory constraint on the student role. Placing a solid dot on the role connector line in the  ORM  diagram indicates that the role is mandatory. The fact type verbalization changes to "each student has a last name", where the word "each" indicates the mandatory constraint. By examining the supporting data documents of the student tracking system you find that not only must each student have a last name, but each student can have only one last name. Placing an arrow above the last name role box in the predicate phrase restricts each student to having only one last name. Figure 10 shows the  ORM  visualization of the previous fact type with the unique constraint added.

 

In some instances a unique constraint spans two or more roles defined in the predicate. For example, a student can enroll in multiple classes and a class contains multiple students, but the same student cannot enroll in the same class more than once. This constrains the combination of student and class as unique. Figure 11 demonstrates the visualization of this type of constraint. Figure 12 shows a separate line drawn above each role in the predicate phrase. In this case, each student is associated with zero or one vehicle, and each vehicle is associated with exactly one student. Compare this with the constraint shown in Figure 10, which constrains each student to have only one last name but allows several students to have the same last name. The examples covered thus far have been for binary fact types. Figure 13 demonstrates the same types of constraints applied to a ternary fact type as well. In this case a unique constraint spans the room role and time role. In other words, two different classes cannot occupy the same room at the same time. A unique constraint also applies to the time and class roles. This restricts two different instances of the same class from occurring at the same time.

 

 

 

Using Visio to Add Constraints to the  ORM  Model
Follow these steps to add constraints to a Visio  ORM  model.

1. Start up Visio. From the File menu, choose New >  Database  >  ORM  Source Model.
2. If the Business Rules Editor (see Figure 5) is not visible at the bottom of the window, from the Database  menu choose View > Business Rules.
3. Double-click the first Object Type cell in the Business Rules Editor. Create Class, Student, and Room entity object types. Also create a Time value object type. Note: Don't worry about the Physical Data or Reference Mode at this time.
4. Select the Fact Types tab at the bottom of the Business Rules Editor. Press the F2 key to launch the Fact Editor window. Choose Student from the left Object dropdown list. In the relationship text box enter "attends". Choose Class from the right object dropdown list.
5. Click on the Constraints tab in the Fact Editor. Experiment with the various selections in the righthand constraint dropdowns. Notice how the various selections alter the fact type diagram and the verbalization at the bottom of the editor. After experimenting, choose the selections as shown in Figure 14, and click OK.

 

1. Select the Fact Types tab at the bottom of the Business Rules Editor. Press the F2 key to launch the Fact Editor window. In the input style section, select the Guided option and choose Ternary from the dropdown list. Choose Class from the left Object dropdown list. In the relationship text box, enter "occurs at". Choose Time from the right object dropdown list. In the second row relationship text box enter "in". Choose Room from the object dropdown list.
2. Click on the Constraints tab in the Fact Editor. Experiment with the various constraint selections. Notice how the various selections alter the fact type diagram and the verbalization at the bottom of the editor. After experimenting, choose the options as shown in Figure 15, and click OK.

 

Conclusion
ORM  is an excellent aid for  modeling  the data and data relations that will comprise the back-end database  structure of your application. The real strength of  ORM  is its ability to extract the business data requirements from the domain experts into a conceptual model that is easily understood and verifiable by those same domain experts. By spending time creating a thorough and accurate conceptual model, an application's chance of success as it progresses to the logical and physical stages significantly increases.

The process of developing the  database  model involves the refinement and verification of the various fact types and object types that make up the model. This article introduced some of the concepts involved in the refinement process. It focused on the concepts of primitive entity types, subtypes, derived fact types, and unique constraints. In addition, this article covered the process of using Visio to incorporate the concepts into an  ORM  model. A future article will continue the study of  ORM  source  modeling  using Visio. It will cover additional types of constraints commonly enforced in many  database  models. In addition, it will examine the process of verifying the  ORM model with the domain experts using the fact verbalizer and population checks.

This article is the third in a series introducing Object Role Modeling (ORM). ORM is an excellent modeling methodology you can use to construct the conceptual database model. It is an approach to describing data in terms of objects and the roles they play.

The focus of the first article (.NETDJ , Vol. 1, issue 10) was working with domain experts to identify the various object types and fact types that need to be included in the conceptual model . It introduced you to the various common types of predicate arities as well as the use of Visio to construct an ORM source model. The second article (.NETDJ , Vol. 1, issue 12) continued the study of ORM source modeling. The process of developing the database model is iterative and involves the continual refinement and verification of the various fact types and object types that make up the model. It introduced some of the concepts involved in the refinement process and focused on the concepts of primitive entity types, subtypes, derived fact types, and unique constraints.

This article examines the process of modeling other types of constraints commonly enforced in relational database systems. It focuses on constraints such as external uniqueness, disjunctive role, and set constraints . In addition, it covers applying population checks to verify the conceptual database model.

Uniqueness Constraints, Reference Schemes, and Mandatory Role Constraints
Enforcing constraints is fundamental to designing the structure of a relational database. There are many different types of constraints to consider when defining the model. For example, Figure 1 shows a fact type with an arrow placed above the student role box in the predicate phrase. The arrow models a frequency constraint indicating that a student has at the most one SSN. Figure 1 also models a mandatory role constraint. The dot on the line connecting the student role to the predicate phrase indicates that each student must have a SSN. Figure 2 further constrains the roles in the fact type. It places similar constraints on the SSN role making it mandatory and unique. A student and SSN combination must be unique in the database. Since a student's SSN is unique, it can distinguish between different instances of the student entity. A unique constraint used to distinguish between identity types is the primary unique constraint (PUC) and modeled by tagging the constraint with a P. The PUC of an entity type is referred to as its reference mode, and it is often more convenient to indicate the reference mode by placing it in parenthesis within the entity role shape. Figure 3 demonstrates the two ways of modeling a reference mode.

Up to this point, the constraints modeled have been internal to a particular fact type. When defining constraints, you must also consider external constraints that apply across a group of fact types. For example, students can have the same first name and/or the same last name but the combination of first name, middle name, and last name must be unique. To symbolize external uniqueness constraints in ORM, a dashed line connects the roles involved in the constraint to a circled letter U symbol (see Figure 4). There may be times when an external uniqueness constraint uniquely identifies instances of an entity type. This type of constraint is a compound reference scheme and a P replaces the U in the model (see Figure 5).

In modeling external constraints sometimes it is necessary to model exclusive, or constraints. For example, it is necessary to be able to contact students by phone. Students must have either a home phone or a cell phone or both. In ORM terminology, this is a disjunctive mandatory role constraint (see Figure 6). Dashed lines connect the roles involved in the constraint to a circle symbol containing a solid dot.

Constraint modeling in ORM is very robust and ORM can represent very intricate constraints as part of the conceptual model. Set constraints restrict the population of two roles and are primarily external in nature. They come in three flavors: exclusion, equality, and subset constraints. Exclusion constraints prevent instances of one set from appearing in another. The exclusion constraint symbol consists of a circled x with dashed lines connecting the roles involved in the constraint (see Figure 7). This constraint restricts the classifications of instructors to either full-time or part-time.

An equality constraint ensures that all instances of one set appear in a related set. Figure 8 shows an equality constraint stipulating that full-time instructors get a salary. This is in contrast to part-time instructors who get a stipend. Notice that the symbol for this type of constraint is an equality symbol. A subset constraint ensures the instance of one set is also included in the instance of another. Figure 9 shows a subset constraint stipulating department chairs must also be full-time instructors. The symbol for the subset is a sideways underlined U. Notice that an arrow head has been added that points to the superset.

Modeling External Constraints Using Visio
The following activity demonstrates adding external constraints to a Visio ORM model.  Note:   You need Visio for Enterprise Architects in order to create an ORM Source Model.

1.  Start up Visio. On the File menu, choose New > Database > ORM Source Model.

2.  If the Business Rules Editor is not visible at the bottom of the window, on the Database menu, choose View > Business Rules.

3.  Double-click the first Object Type cell in the Business Rules Editor. Create an Instructor entity object type with a reference mode of EmpNo. Repeat this procedure to add the rest of the object types shown in Figure 10.

4.  Select the Fact Types tab at the bottom of the Business Rules Editor. Press the F2 key to launch the Fact Editor window. Using the left Object dropdown choose Instructor. In the relationship textbox enter "is a". In the right object drop down choose Full Time Emp. Repeat this procedure to add the rest of the fact types shown in Figure 11.

5.  Click and drag the fact types "Instructor is a Part Time Emp" and "Instructor is a Full Time Emp" from the Business Rules Editor onto the drawing surface.

6.  Select both fact types on the design surface by clicking on the predicate phrases while holding down the shift key. Right click on one of the predicate phrases and choose Add Constraints, which launches the Add Constraint dialog box.

7.  Select exclusion from the constraint type dropdown and select the instructor role in each of the predicate phrases listed by clicking in the role box (see Figure 12). Click OK to close the Add Constraint dialog. The resulting diagram is similar to that in Figure 7.

8.  Experiment with adding the various types of constraints. See if you can construct a diagram similar to that in Figure 13.

Verifying the Conceptual Model using Verbalizations and Population Checks
One of the most powerful features of ORM is the ability to verify the model with the domain experts using verbalizations and population checks. Verbalizations are natural language statements of the fact type and applied constraints that domain experts can easily understand and verify. Providing an ORM diagram such as Figure 14 to the domain experts for verification would not be very effective. Instead, a verbalization of the fact type is generated that can be easily understood and verified against the data artifacts that have been collected. Figure 15 contains the verbalization of the fact type of Figure 14. Using Visio, you can export the verbalizations of the various fact types contained in the model to a report. This report is very useful to the domain experts when they verify the model.

Population checks are an extremely useful way to verify the accuracy of the constraints modeled. Sample populations represent data from a variety of sources such as reports and forms that currently exist to maintain and manage the data. In order to achieve a valid and useful population check, the sample data must be actual real world data and not fictitious data created to conform to the constraints of the model. Figure 16 shows a sample population entered for the fact type in Figure 14. Using the sample population, Visio can verify the constraints, report any errors and make recommendations for modifying the constraints. In order for a proper analysis, it is important that the sample population is large enough to be statistically significant.

Analyzing Constraints Using Visio
1.  Start up Visio. On the File menu, choose New > Database > ORM Source Model.

2.  If the Business Rules Editor is not visible at the bottom of the window, on the Database menu, choose View > Business Rules.

3.  Double-click the first Object Type cell in the Business Rules Editor. Create a class object type, room object type and a time value type.

4.  Select the Fact Types, tab at the bottom of the Business Rules Editor. Press the F2 key to launch the Fact Editor window. Construct the ternary fact type using the settings shown in Figure17. Add the constraint settings using the constraint tab shown in Figure 18.

5.  Select the Examples tab and enter a sample population as shown in Figure 16. Click the Analyze button and examine the results. Experiment with changing the sample population to see how it affects the resulting analysis.

6.  Close the Fact Editor and drag the fact type to the design surface.

7.  Under the Database menu, select Report. The New Report Wizard launches. Select the Fact Type Report, click Next, and then finish. Experiment with the different report setting options and preview the report.

Review
This article concludes this series on Object Role Modeling. ORM is an excellent aid to modeling the data and data relations that will comprise the backend database structure of your application. The real strength of ORM is its ability to extract the business data requirements from the domain experts into a conceptual model that is easily understood and verifiable by those same domain experts. By spending time creating a thorough and accurate conceptual model, the application's chance of success as it progresses to the logical and physical stages significantly increases.

The goal of this series was to give you a sufficient introduction into the process of ORM modeling with Visio so that you are comfortable enough to start experimenting with the process. As you become more comfortable with ORM and Visio, you will gain an appreciation of its capabilities and benefits. Remember that the ORM model does not replace the traditional entity relationship model. ORM captures the conceptual requirements while the ER model describes the logical requirements. Once the ORM model is developed, you can use Visio to create and refine the logical and physical models of the relational database system. Although this series of articles did not cover the process of developing the logical and physical database models, it may be fodder for a future series. Let me know if this would be of interest to you.