Why Data Modeling Is Still Relevant

Written by John Pocknell, Senior Product Manager, Quest

INTRODUCTION Another way to say this is that data modeling concentrates on There are those who think data modeling is passé or irrelevant. issues that lead to a solid database design, while the other After all, data modeling theory is more than 30 years old and techniques focus on issues that result in better application some data modeling tools have been around for 20 years. But design or the things useful to programmers, such as data data modeling is still essential. In fact, it may be more necessary structures, objects, classes, methods, application code now than ever. Let’s look at several key reasons why data generation, and so on. modeling is experiencing a resurgence, and how effective data Case in point: I’ve personally been an expert witness at modeling can benefit your organization. several trials in which plaintiffs were suing for serious financial remuneration because custom database applications had The unique value of data modeling performance and/or data accuracy problems. In every single While there are other modeling techniques and notations, case, the defendant had failed to create the data model for such as Business Process Modeling and Unified Modeling the business requirements, and therefore data effectiveness Language, data modeling is uniquely designed to accurately suffered. In many cases, ad-hoc database design or database capture business data requirements and transform them into a design using more programmatic techniques and tools had also reliable database structural design. The key differentiator is that resulted in inefficient database design, and no amount of coding only data modeling focuses on the “data at rest”; all the other trickery could overcome this. So in every case, the plaintiff won. techniques and notations focus on “data in motion.” ET

•OLTP •App #1 •VSAM Staging area

ETL L •OLTP •App #2 •Sybase •ODS •Oracle

•OLTP •App #2 •Oracle

Figure 1. Data warehouse via intermediate ODS

One reason data Using data modeling in There is much debate as to which data warehousing approach is superior; I won’t address modeling has One reason data modeling has seen those arguments here. Instead, I will point seen measurable measurable resurgence is the growth of out that, regardless of which approach data warehousing. Because storage is is taken, the database design (i.e., the resurgence is the cheap these days, most organizations data at rest) is paramount, because in a growth of can afford to retain historical data warehouse, the data itself and the aggregate or summary data for making business information it contains is the data warehousing. significant strategic decisions. With the most relevant and valuable asset. Typical accumulation of numerous source legacy data warehouse queries and reports OLTP (online transaction processing) issued via business intelligence tools systems, there are two keys ways to process that asset to yield key strategic approach populating a data warehouse: decision-making results.

• Directly from source to warehouse One key way in which data modeling (see Figure 1) supports the data warehousing effort is by mapping legacy data fields to their • Through an intermediary database, data warehouse counterparts. Carefully which is often referred to as an ODS mapping front-line business data to the (operational data store) (see Figure 2) data warehouse helps with the design of queries and reports, as well as with ETL (extract, translate and load) programming

•OLTP •App #1 •VSAM Staging area

ET L

•OLTP •App #2 •Sybase Staging area Enterprise DW

•OLTP •App #2 •Oracle Staging area

Figure 2. Data warehouse via separate feeds

2 efforts. Without such a mapping, as your Figure 3 shows how both conceptual and OLTP legacy systems evolve, you would physical data modeling should fit into have no automatic tie to the dependent an overall database design process — data warehousing information; therefore, whether it’s for a totally new system or for you would have to almost totally an existing system that’s being updated re-engineer, rather than simply follow, or even completely re-engineered. the OLTP source data ramifications that trickle downstream to the DW and BI Data modeling as part of a formal end points. development process There’s one final reason why data Using data modeling in modeling has been getting more systems development attention these days. In many cases, Data modeling is important not organizations are finally requiring data only for data warehousing projects, models as a sign-off deliverable in the but also for more traditional OLTP development process. I attribute this systems development. Unfortunately, to organizations attempting to adhere people often get so caught up in to the Software Engineering Institute’s novel paradigms such as “extreme Capability Maturity Model and Capability programming,” “agile software Maturity Model Integration concepts. No matter what development,” or “scrum” that they The idea here is quite simple: To make compromise on — or even skip your development process more mature, development entirely — data modeling. regardless of technique, you need to think in terms of both the processes and methodology The problem is that these new tools used to achieve the desired result. you choose, data approaches don’t always spell out For example, the proper and effective exactly how data modeling should be use of project management tools is modeling should incorporated, and therefore people often often cited as the single best way to forego it. My belief is that no matter what escalate from Level 1 (Chaos) to Level 2 be integrated into development methodology you choose, (Repeatable). The central idea that both your development data modeling should be integrated into processes and tools can lead to maturity your development process wherever it has helped to reinvigorate the interest in process wherever it makes sense. data modeling. makes sense.

Analysis Design Conceptual Reengineer

Physical

Monitor Develop Deploy and maintain

Figure 3. Overview of database design

3 CONCLUSION John has spent the last 14 years Data modeling has come a long way successfully evangelizing Toad to since its inception. Even though customers at various events throughout the heydays of CASE and software Europe, the U.S. and the AsiaPac region, engineering ended in the ’90s, the need and he writes many blogs and papers on for — and usefulness of — data models the Toad user community, Toad World, has not subsided. Data modeling can as well as technical briefs about Toad on assist with any effort, regardless of the Quest website. John has worked in IT development methodology or paradigm. for 30 years, most of that time in Oracle So don’t pass up data modeling just application design and development. because it’s a mature technique.

ABOUT THE AUTHOR Data modeling John Pocknell is a senior manager of product management at Quest. Based can assist with any in the U.K., John is responsible for the strategy and roadmap for the Toad effort, regardless portfolio of products worldwide. He of development has been with Quest since 2000, working in the database design, methodology development and deployment product or paradigm. areas, and he has run many Toad training courses for customers.

This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software Inc.

The information in this document is provided in connection with Quest Software products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest Software products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST SOFTWARE ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST SOFTWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest Software makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest Software does not make any commitment to update the information contained in this document.

Patents

Quest Software is proud of our advanced technology. Patents and pending patents may apply to this product. For the most current information about applicable patents for this product, please visit our website at www.quest.com/legal.

Trademarks

Quest, and the Quest logo are trademarks and registered trademarks of Quest Software Inc. in the U.S.A. and other countries. For a complete list of Quest Software trademarks, please visit our website at www.quest.com/legal. All other trademarks, servicemarks, registered trademarks, and registered servicemarks are the property of their respective owners.

If you have any questions regarding your potential use of this material, contact:

Quest Software Inc. Attn: LEGAL Dept 4 Polaris Way Aliso Viejo, CA 92656

Refer to our Web site (www.quest.com) for regional and international office information.

Whitepaper-DataModelingRelevance-US-EC-24998