Did you know data modules are actually part of Cognos BI v10? The release of Cognos Analytics R7 is spurring renewed interest in this functionality. Data modules allow end users to bring in external files and blend together existing packages—all without bringing in IT. Read on to learn how to make the most of data modules and understand their limitations.
Origins
It’s easy to see why people think data modules are new to the current Cognos Analytics release. However, this technology has actually been available since v10, albeit in a much more trimmed down version.
Back then it was called “upload external files” and was built into the Report Studio interface. Report authors could upload an XLS or CSV file, join it to an existing package, specify cardinality, and use the newly imported data right alongside the existing package. All without ever waiting for IT or a DBA to get involved. Sound familiar? It should, as this is the core functionality of today’s data module.
Benefits of data modules
In principle, the purpose of using data modules is to allow users to quickly get to data that may not be in an existing package or even available through more traditional means such as the enterprise data warehouse. As we all know, trying to get new data added into an existing system like an enterprise data warehouse can be challenging. The task requires IT knowledge, ETL people to modify existing scripts, a plan to automate updates to the data, someone to model the new data into a package and finally an administrator to make it all available. And don’t forget a project manager to oversee all this to keep it on track and manage the different pieces of the puzzle. Whew! That’s a lot going on! But you need a report today! Data modules are the perfect way to bridge the gap between immediate need and solid foundation.
Data modules are not limited to just bringing in external files. They can also be used to blend together existing packages. While this is the less common use, it is something else to consider. Data modules can be used to join any data connection to any package to any file. This gives the author great flexibility in what can be used on a report.
Working with data modules
To use a file as a data module, select the Upload Files option from the main portal. You must have this functionality enabled for your security profilem, not just for uploading the source files, but for using data modules as well. With the newly uploaded file, you can create a data module. The main purpose would be to connect it to an existing package. Think of your budget data sitting in an XLS file and needing to report on it against the actuals data in the existing package – a perfect place for a data module.
To use data modules, you do need to have some knowledge and understanding of modeling concepts. While it’s billed as “light-weight modeling,” it’s modeling none the less. A “join” must be made between the files that will be in the final data module. This would be the common field between the tables providing a link for reporting. In addition to joins, the user will need to understand the concept of cardinality, i.e. does this side need a “many to one” or a “one to one?” These questions can sometimes be beyond the self-service user’s capabilities. While IBM Cognos has done its best to make data modules non-technical in nature, it is still not for every user.
Limitations of data modules
Too many users think that using data modules will solve their problems forever. In practice, data modules should be considered a starting place. A good Framework Manager (FM) model is always the better solution. FM modeling with best practices will always result in something much more customizable, secure and efficient. Things like row level or object level security can’t be placed into a data module. In addition, there are things like advanced calculations, parameter mapping, macro and functions, complex database design issues (ambiguous joins, SCDs, role-playing dimensions, etc.), and much more that data modules were never built to handle. These features will need to be handled by an experienced modeler in the FM tool.
You can never assume either that all users will have the knowledge or skills to properly join together different tables or to set cardinality correctly. Even with the advantage of self-service modeling, a good QA process to vet the results needs to be established. This should be done as soon as a data module is available to prevent undesired results from getting distributed.
Conclusion
Data modules are a great enhancement to the Cognos platform. When used properly they can provide an excellent short-term solution for getting much needed data quickly. They open up doors to authors by providing insight to data previously unavailable in their central reporting tool.
And like all things, remember to use data modules with a long-term goal in mind. Talk with your modeler about meeting your long-term needs and make sure to get all business owners and data owners involved in your process. Have a solid plan for introducing the new data into your enterprise data solution. Leverage your internal resources to automate the process through well-built ETL processes. Have someone validating the quality of the data. While data modules can get you over an immediate crisis or need, they are only one part of the bigger picture.
If you could benefit from some outside perspective and guidance, schedule a free consultation with Senturus and we can discuss your data modeling strategy. You might also be interested in our on-demand webinar, Data Acquisition & Storytelling in Cognos Analytics, which includes how-to demos on data modules.
