-
Marketplace
-
Channel Resources
Articles from this Site
Information Builders to Extend WebFOCUS to Predictive Analysis
A Statistical Stocking Stuffer for the Holidays
What are your views on the advantages and/or disadvantages ETL tools and data modeling versus code?
New Interfaces Integrated into MEGA International Modeling Software
Which would be a better choice of classes for career growth in data warehousing - ETL architecture or dimensional modeling?
White Papers
Best Practices: Eight Tips for Improving Your Professional Services Business
Metadata Management for Enterprise Applications
UML for C#
PHP Code Design
Domain-Specific Modeling: 10x Faster than UML
Web Seminars
Modeling Unstructured Data
Creative Strategies for Achieving 24/7 Uptime
Closing the Loop: Real-Time Event Detection and Response
Learning from Others: Best Practices for Data Governance
Books
Data Mining Cookbook: Modeling Data for Marketing, Risk and Customer Relationship Management
Data Modeler's Workbench: Tools and Techniques for Analysis and Design
The Data Modeling Handbook: A Best-Practice Approach to Building Quality Data Models
Data Mining Using SAS Applications
Data Mining: Concepts, Models, Methods and Algorithms
Could you recommend a review process for the logical model of our pilot data warehouse?
Question: We have been asked to review the logical model for our pilot data warehouse with the business. Could you recommend a review process? Are there key questions we should anticipate as part of the review? Are there typical concerns from the business that we want to be sure to address? An example of what I would deem as a typical question would be: Are the relationships marked properly?
Clay Rehm's Answer: I would ask a question such as "are the relationships marked properly?" Please keep in mind that your business partners/users may not be technically focused. Even a question such as "are the relationships marked properly?" will make for a very long meeting, or a very short meeting since they will not answer properly. Many users don't want to appear unknowledgeable in front of others and will not ask what it means so they can properly answer the question.
The best advice I can give is to focus less on the "data model" including terms such as entities, attributes, foreign keys, etc. - and focus on business terms and concepts. Focus on terminology your business partners are comfortable with. You may not even start the meeting with looking at the data model. You may get up in front of the room and draw circles, objects or "thoughts" on a white board and eventually describe and connect these objects after describing them.
Maybe a lead in to this is to ask them what is important to them. Leave it open ended - don't ask what data they want to see on a report - ask them what is important to them and what do they need to be more successful? Try to make the meeting as interesting as possible so your users want to be there, and so they want you to know as much as possible to design the correct solution.
Larissa Moss' Answer: The best way to review a logical data model with business people is to use examples. Rather than asking, "Are the relationships marked properly," you would want to ask questions like, "Is it true that every loan can be sold to more than one investor? What are the exceptions? Does that apply to every loan type? Can an investor buy a partial loan? Can a loan be split up among multiple investors? Are loans packaged by loan type? Can fixed rate loans be combined with adjustable-rate loans in the same package?" and so on.
It also helps to create a matrix or list of real values to demonstrate data relationships. For example, to show that a loan can be sold to multiple investors and an investor can buy multiple loans, show examples from the real world using real loan numbers and investor IDs and put together valid and invalid combinations for the users to look at.
The key questions during a review must also include data definitions and business rules. Again, don't just let the users read a definition and ask if it's OK. Most likely, they will say yes, even if it's not OK. Instead, explore multiple variations of a definition. To use an example from Michael Brackett's book The Data Warehouse Challenge: Taming Data Chaos, you may have an attribute called "well depth feet." Don't just write a short definition "depth of the well in feet" and ask the users if it's OK. Most likely they will say it is. However, this definition does not say if the depth is the total depth of the well, the depth of the casing, the depth to high water, the depth to low water, etc.
Therefore, draw the specifics out of your users and come up with a more complete and meaningful definition such as "The total depth of the well in feet from the surface of the surrounding ground to the deepest point dug or drilled regardless of the depth of the well casing."
There are too many topics to describe in this column. I would advise the reader to get Michael Brackett's book mentioned above, as well as his book Data Resource Quality: Turning Bad Habits Into Good Practices.
In terms of a review process, identify all potential user areas that currently use the data that is modeled in your logical data model. Each user area should send a representative to the review meetings so that you can get agreement and consensus on the data names, data definitions, data domains, data relationships and business rules across the organization. Many data collisions are discovered when users from different departments get together and discuss what they think the data means or should mean.
Be sure to have a "dispute resolution process" in place and know which person or group has the authority to be the official tie breaker (e.g., data owners, data stewards, division/department managers, etc).
Larissa Moss is founder and president of Method Focus Inc., a company specializing in improving the quality of business information systems. She has more than 20 years of IT experience with information asset management. Moss is coauthor of three books: Data Warehouse Project Management (Addison-Wesley, 2000), Impossible Data Warehouse Situations (Addison-Wesley, 2002) and Business Intelligence Roadmap: The Complete Project Lifecycle for Decision- Support Applications (Addison-Wesley, 2003). Moss can be reached at methodfocus@earthlink.net.
Clay Rehm, CCP, PMP, is president of Rehm Technology (www.rehmtech.com), a consulting firm specializing in data integration solutions. Rehm provides hands-on expertise in project management, assessments, methodologies, data modeling, database design, metadata and systems analysis, design and development. He has worked in multiple platforms and his experience spans operational and data warehouse environments. Rehm is a technical book editor and is a co-author of the book, Impossible Data Warehouse Situations with Solutions from the Experts. In addition, he is a Certified Computing Professional (CCP), a certified Project Management Professional (PMP), holds a Bachelors of Science degree in Computer Science and a Masters Degree in Software Engineering from Carroll College. He can be reached at clay.rehm@rehmtech.com.
For more information on related topics, visit the following channels:


