photobank.kiev.ua - Fotolia
Is data modeling outdated? This excerpt from the book Data Modeling for MongoDB: Building Well-Designed and Supportable MongoDB Databases by Steve Hoberman argues that data modeling concepts are still vital to business success and introduces useful terminology and tips for simplifying a complex information landscape with MongoDB applications. Hoberman is the most requested data modeling instructor in the world and has educated more than 10,000 people across five continents about data modeling and BI techniques. In this excerpt, he emphasizes the necessity for businesses to implement data modeling concepts and explores a variety of business uses for data models.
Confirming and documenting different perspectives
The reason we do data modeling is to confirm and document our understanding of different perspectives. A data model is a communication tool. Think of all of the people involved in building even a simple application: business professionals, business analysts, data modelers, data architects, database developers, database administrators, developers, managers, etc. People have different backgrounds and experiences and varying levels of business knowledge and technical expertise. The data model allows us to confirm our knowledge of the area and make sure people see the information landscape similarly or, at a minimum, have an understanding of the differences that exist.
A data model can describe a new information landscape, or it can describe an information landscape that currently exists. This figure contains the new and existing areas where data modeling can be leveraged:
Traditionally, data models have been built during the analysis and design phases of a project to ensure that the requirements for a new application are fully understood and correctly captured before the actual database is created (i.e., forward engineering). There are, however, other uses for modeling than simply building databases. Among these uses are the following:
- Risk mitigation. A data model can capture the concepts and interactions that are impacted by a development project or program. What is the impact of adding or modifying structures for an application already in production? One example of impact analysis would be to use data modeling concepts to determine what impact modifying its structures would have on purchased software.
- Reverse engineer. We can derive a data model from an existing application by examining the application's database and building a data model of its structures. The technical term for the process of building data models from existing applications is "reverse engineering." The trend in many industries is to purchase software and to build less internally; therefore, our roles as modelers are expanding and changing. Instead of modeling a new application, the data modeler may capture the information in existing applications.
- Understand the business. As a prerequisite to a large development effort, it usually is necessary to understand how the business works before you can understand how the applications that support the business will work. Before building an order entry system, for example, you need to understand the order entry business process. The data and relationships represented in a data model provide a foundation on which to build an understanding of business processes.
- Knowledge transfer. When new team members need to come up to speed or developers need to understand requirements, a data model is an effective explanatory medium. Whenever a new person joined our department, I spent some time walking through a series of data models to educate the person on concepts and rules as quickly as possible.
Data modeling is not optional!
The power of the data model as a tool to confirm and document our understanding of different perspectives has, as the root of its power, one word: Precision. Precision, with respect to data modeling concepts, means that there is a clear, unambiguous way of reading every symbol and term on the model. You might argue with others about whether the rule is accurate, but that is a different argument. In other words, it is not possible for you to view a symbol on a model and say, "I see A here" and for someone else to view the same symbol and respond, "I see B here." In a data model, precision is primarily the result of applying a standard set of symbols. The traffic circles the gas station attendant drew for me were standard symbols that we both understood. There are also standard symbols used in data models, as we will discover shortly.
The process of understanding and precisely documenting data is not an optional process. As long as there is at least some data in the application and at least two people involved in building or using the application, there is a need to confirm and document our understanding of their perspectives.
This excerpt is from the book Data Modeling for MongoDB: Building Well-Designed and Supportable MongoDB Databases, by Steve Hoberman. Published by Technics Publications, LLC, Basking Ridge NJ, ISBN 9781935504702. Copyright 2014, Technics Publications.
Take Customer for example. You can start off with the innocent question, "How do you define Customer?" This question is not as easy to answer as it may appear because of the many different perspectives on Customer. Once you get your answer, you can move on to other data modeling questions, such as:
- How do you identify a Customer?
- How do you describe a Customer?
- Can a Customer own more than one Account?
- Can an Account be owned by more than one Customer?
- Can a Customer exist without owning any Accounts?
These are some of the many questions that get asked during the data modeling process. Asking and getting answers to questions like these is called elicitation, and data modeling includes eliciting and documenting data requirements. There is an iterative process between eliciting and documenting data requirements:
While data modeling, we ask questions to increase the precision of our data model, and then through the process of documenting our data model, we ask more questions. This loop continues until we are done with our model. A lot of knowledge is gained as the people involved in the modeling process challenge each other about terminology, assumptions, rules and concepts.
Gain further insights on data modeling in this Q&A with Steve Hoberman.
Get a better understanding of MongoDB with this definition
Learn what conference-goers had to say about NoSQL database MongoDB
LexisNexis enterprise architect talks ins and outs of database schema design in an era of big data disruption.