In my October column, I discussed the key functions and features that my optimal meta data tool would have. In order to categorize these functions and features, I am utilizing the six major components of a managed meta data environment (MME):

  • Meta Data Sourcing
  • Meta Data Integration Layers
  • Meta Data Repository
  • Meta Data Management Layer
  • Meta Data Marts
  • Meta Data Delivery Layer

October's column walked through the meta data sourcing and meta data integration layers. This month, I will present the key functions and features of my optimal meta data tool in the MME categories of meta data repository and meta data management layer.

Meta Data Repository

The meta data repository component is the physical database that persistently catalogs and stores the actual meta data. The repository and its corresponding meta model comprise the backbone of the MME. Therefore, in listing the optimal meta data tool's functionality, I will pay special attention to the design and implementation of the meta model.

Meta Model Design

A meta model is a physical database schema for meta data. There are integration processes that must be custom built in order to bring meta data into the repository any time an MME is implemented. Therefore, a good meta model needs to be understandable to the repository developers working with it. As a result, the meta model should not be designed in a highly abstracted, object-oriented manner. Instead, mixing classic relational modeling with structured object-oriented design is the preferable approach to designing a meta model. On the other hand, when highly cryptic (abstracted) object-oriented design is used for the construction of the meta model, it becomes unwieldy and difficult for the information technology (IT) developers to work with.

The possible exception to this guideline would be if the abstracted object-oriented model has relational views built on the model that would allow for read/write/update capabilities. These views must be understandable and fully extendable.

Meta Model Implementation

The meta data repository must not be housed in a proprietary database management system. Instead, it should be stored on any of the major open relational database platforms (e.g., SQL Server, Oracle, DB2, Informix, Teradata or Sybase) so that standard structured query language (SQL) can be used with the repository.

Semantic Taxonomy

Many IT departments in government agencies and large corporations are looking to define an enterprise-level classification/definition scheme for their data. This semantic taxonomy would provide these organizations with the ability to classify their data in order to identify data and process redundancies in their IT environment. Therefore, the optimal meta data tool would provide the capabilities to capture, maintain and publish a semantic taxonomy for the meta data in the repository.

Meta Data Management Layer

The purpose of the meta data management layer is to provide the systematic management of the meta data repository and the other MME components. This layer (see Figure 1) serves many functions, including:

  • Archiving of the meta data within the repository
  • Backup of the meta data on a scheduled basis
  • Database modifications –­ allows for the extending of the repository
  • Database tuning –­ the classic tuning of the database for the meta model
  • Environment management –­ the processes that allow the repository administrator to manage and migrate between the different versions/installs of the meta data repository
  • Job scheduling to manage both the event- based and trigger-based meta data integration processes
  • Purging ­– should handle the definition of the criteria required to define the MME purging requirements
  • Recovery –­ process should be tightly tied into the backup and archiving facilities of the repository
  • Security processes –­ provide the functionality to define security restrictions from an individual and group perspective
  • Versioning –­ meta data is historical, and this tool needs to version the meta data by date/time of entry into the MME

Figure 1: Meta Data Management Layer

The optimal meta data tool would also have very good documentation on all of its components, processes and functions. Interestingly enough, too many of the current meta data vendors neglect to provide good documentation with their tools. If a company wants to be taken seriously in the meta data arena, it must "eat its own dog food."

Next month, I will conclude the design of our optimal meta data management tool by presenting the key functions and features for the final two components of the MME: meta data marts and the meta data delivery layer.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access