Welcome!

Microsoft Cloud Authors: Pat Romanski, Liz McMillan, Lori MacVittie, Elizabeth White, Yeshim Deniz

Related Topics: Microsoft Cloud

Microsoft Cloud: Article

Database Modeling with ORM - Part 2

A thorough and accurate conceptual model significantly increases the chance of an application's success.

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.

 

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.

     

  3. 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.
  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 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.

     

  5. 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.
  6. 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.
  7. 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.

     

  5. 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.

     

  6. 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.
  7. 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.

More Stories By Dan Clark

Dan is a Microsoft Certified Trainer, Microsoft Certified Solution Developer, and a Microsoft Certified Database Administrator. For the past seven years he has been developing applications and training others how to develop applications using Microsoft technologies. Dan has been developing and training Microsoft's .NET technologies since the early betas. He has recently authored the book "An Introduction to Object-Oriented Programming with Visual Basic .NET," published by Apress.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...