By Rick Ryan, Envisn, Inc.
In the first blog in this series published last month we presented the four key data groups in the Cognos Metadata Universe and described them in some detail. These are shown again on the left side of Figure 1 below. In that blog we also listed some of the things we would cover in subsequent blogs. One of these was the importance of having an architecture to deal with Cognos metadata.
Having a data architecture begins with the desired outcome of the process. Which is the answer to the question of how we want to use the data.
The goal of an architecture for our purpose has three principal goals:
The Content Store by itself is Big Data. It can have thousands of objects each of which can have hundreds of properties. A conservative count total for the number of metadata elements that a report object can have, for example, is around 800. Depending on type, some objects will have more and others less. We want to capture all of them.
Are the numbers really important here? Up to a point. We’re not looking for precision but it’s worth knowing that there is a lot of stuff from these four groups that we need to capture, transform, store and manage.
Coming up with the right architecture is important since whatever we create will either enable or limit what we can do with the metadata, both now and in the future. Ideally you should be able to use any of the metadata for any purpose and get an accurate representation of what you want.
An obvious question here is why not just go to the Content Store directly for the metadata whenever it’s needed. After all, that’s what the Content Store is for isn’t it, to provide the metadata that will be mapped to the physical data for each user’s need.
You can do this, but there are some reasons you may not want to take this approach. These include:
If your decision is to persist the data from these sources you have to choose between using a relational database such as MS SQL, DB2 or Oracle, versus a No SQL database of which there are a number of alternatives. Here we chose the No SQL approach. Our view is that its advantages are clearly superior.
Once you’ve completed the challenge of capturing all the Cognos metadata sources shown in the left side of Figure 1, you need a process that transforms, stores and accesses this metadata for use. This really is what you might call the secret sauce since it determines what you are able to do with the metadata. Essentially this involves providing dimensionality around key parameters such as time, relationships, state, change and a host of other parameters. The connectedness if you will, of the metadata elements. Doing this successfully is what enables you to use the metadata for multiple purposes. Again, we’re focused here on two principal areas:
Some of the key tasks are shown in the right pane of Figure 1. These include documentation, object dependency, version control, deployments, and security management. But there is virtually no limit to the things you can do once you have all the metadata.
Simple concept? Yes. Easy? Not so much.
There are literally thousands of metadata elements that we need to capture and be able to use in the Cognos metadata universe. In our next blog we will begin to explore some of the more novel and creative ways that all of this data can be used to address real world issues that Cognos administrators face every day.