|03. Building a Pentaho Metadata Domain||02. Pentaho Metadata Editor Getting Started Guide||05. Adding Security to Metadata Business Objects|
Presumably the end goal when creating a metadata domain is to have a model that is available to end-users and applications that allows them to consistently and richly enhance the data they are working with. Whether that be through formatting, security metadata, or some other custom metadata, it all should result in a more efficient, consistent, clearer and smarter view of the data.
So far, we have walked through modeling your database in a fashion that is more intuitive than its physical representation. The second half of the metadata work is in, well, defining the metadata! The Pentaho metadata paradigm uses the term concept to mean a collection of metadata properties that can be applied to a given business object (business table or column, for example).
Here is the official definition of a concept:
This excerpt from the Metadata Business Model Overview describes some of the details regarding concepts and how they are used:
Like all exceptions, the exceptions to the metadata inheritance logic is complex, but sound. There are two sets of properties that change how the typical inheritance is realized - required properties and the default concept.
Required properties and the default concept are two very different things.
All physical and some business objects in the metadata model have a set of required properties. These properties are set automatically on creation of the object, and are not removable (you can change their values though!). The purpose for required properties is to not allow the user to get into a predicament where they have removed a property that is integral to the SQL generation process. For instance, if a physical table did not have a Target Table property set, the SQL generator would complain loudly, since it would not know what physical table to query. So we make Target Table required and do not allow the user to remove it, although the value is modifiable.
This has ramifications. Using our previous example, when you set a parent concept on the physical table, and the parent concept has a Target Table property, the physical table will not recognize the parent concept's value for Target Table. This is because the physical table already has a Target Table property as part of it's self concept, and the self concept always overrides the parent concept. And since you cannot remove a required property, the parent concept's Target Table will never be recognized at the physical level.
So how do you override a physical object's required property? You set a parent concept at the business model or business view level. Since the inherited properties are override-able, the parent concept at the business level wins.
All physical metadata objects, the business categories and the business model have required properties. You can see what's required for each here.
Now that you have a better understanding of the terms and ideas regarding Pentaho metadata let's go about understanding how to apply metadata to your business model using the Pentaho Metadata Editor.