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 1: A Picture Is Worth a Thousand Words

Database Modeling with ORM - Part 1: A Picture Is Worth a Thousand Words

  • Database Modeling with Object Role Modeling - Part 3
  • Database Modeling with ORM - Part 2 

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


    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.

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