Designing the Optimal Meta Data Tool (part 2 of 3)

By David Marco

In part one, I started walking through 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

In part one I 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 which is persistently cataloging and storing the actual meta data. The repository, and its corresponding meta model comprise the backbone of the MME. Therefore, in listing out 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. Anytime an MME is being implemented there are allows integration processes that need to be custom built in order to bring meta data into the repository. 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 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 extendible.

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, Sybase) so that standard SQL can be used with the repository.

Semantic Taxonomy

Many government agencies and large corporations IT departments are looking to define an enterprise level classification/definition scheme for their data. This semantic taxonomy would then 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 includes many functions, including (see Figure 1: Meta Data Management Layer):

  • 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 – is the classic tuning of the database for the meta model
  • Environment Management – is the processes that allow the repository administrator to manage and migrate between the different versions/installs of the meta data repository
  • Job scheduling – would 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 would be tightly tied into the backup and archiving facilities of repository
  • Security Processes – would provide the functionality to define security restrictions from an individual and group perspective
  • Versioning – meta data is historical, so this tool would need to version the meta data by date/time of entry into the MME

Meta Data Management Layer

Common Meta Data Management Layer Functions

  • Archiving
  • Backup
  • Database Modifications
  • Database Tuning
  • Environment Management
  • Job scheduling
  • Purging
  • Recovery
  • Security Processes
  • Versioning


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 serious in the meta data arena they must “eat their own dog food”.

Next month I will conclude designing our optimal meta data management tool bypresenting the key functions and features for our tool for the final two components of the MME: Meta Data Marts and the Meta Data Delivery Layer.

Free Expert Consultation