
Picture the scene: The data warehouse architects send an e-mail explaining to you, the BI architect, that they intend making big changes to some dimension tables, oh, and two fact tables are being completely re-designed.
You need to determine the impact of these changes on the existing set of production reports, and cubes, and dashboard. By this afternoon. Not possible, you say. We have hundreds of reports to go through to look for data items, filters, calculations...
But had you used IBM Cognos Framework Manager (FM) as your metadata modelling layer, this would have been a simple exercise. FM can find all reports, dashboards, cubes built of particular tables, views, or columns by using the "Find Report Dependencies" option.
You will find this powerful feature in the FM toolbar, under Tools > Find Report Dependencies.
Simply choose the folders that you need to hunt through, and FM will do all the work, providing you with a list of all affected objects. Just like that.

Self-help BI - a DBA's worst nightmare
The drive to put the power of BI into the hands of business users has gained tremendous momentum over the last few years. This has eased the reporting bottlenecks and given the user more freedom to analyse and interpret, instead of spending time writing specs and logging change requests.
But, many of these business users don't have a terribly good grasp on good SQL coding practice, and don't necessary understand the impact of running a "select * from dbo.thebiggesttableontheplanet".
Also, they may even unknowingly create cross joins (Cartesian joins) and wonder why their report takes hours and hours to return, filling up the entire TEMPDB in one go.
Framework Manager understands this problem, and gives the modeller a rather nice Governance GUI to help manage various situations.
This way the users can still freely explore, but without giving the DBA heart palpitations.

Who's your daddy? A look at lineage
Probably the most predictable questions that any user will ask when exploring data is "Where did this come from?" and "How is this calculated?".
Giving the user a "right-click" option that will display the source, calculations and filters there and then, is very useful!
Framework Manager to the rescue yet again. Because the reports and dashboards are actually XML files built off an XML metadata layer, the path from data to screen is a connected one.
Additional descriptions can be added in FM, or picked up from the RDBMS, giving the user and author even more context.

Model behaviour
Building a good, solid metadata layer has so many advantages that it is worth the little extra effort.
Of course, one can build Cognos reports, dashboards and cubes directly from the database using SQL and, therefore, bypassing the metadata layer entirely. But that's a real quick and dirty, so why would you? It's just more work in the end.
As my granny always said "A stitch in time saves nine".
Share