Building a meta data repository is no longer an option for corporations, but an absolute requirement. One of the most important tasks in the development of a repository is the construction of the meta model (a physical database that holds meta data). Building the meta model can be a difficult task at the best of times. There are many factors to consider, such as what types of meta data you need to store, how you are going to store it, who has access to it and who is going to build it. As we go through this article we'll discuss the types of information that you need to start designing your meta model.

As is the case in most things, there is no silver bullet that answers every possible meta data requirement and is still easy to use and understand. We'll examine two ways of modeling a meta data model ­ generic object and traditional relational. In order to understand which approach is best for your company, we'll walk through the differences of using each approach.

The Meta Model

A meta model is the physical database model that is used to store all of the meta data. A meta model differs from typical models in that it contains the business functions and rules that govern the data in our systems. Therefore, a meta model is simply a model created at a higher level of abstraction than that being modeled. In this case, you make a model of the business functions and rules that form the data we use everyday in our corporation. In a nutshell, this is a model to store information about your data. Of course, as with most things, there is a tradeoff between being able to store anything and not having to change the meta model versus being able to store only predetermined things and having to frequently change the model. In a traditional model, you have entities (tables) that have relationships to other entities. These entities form the basis for the physical design of the database. On the other hand, in an object model your model comprises a fixed number of entities that hold the relationships and entity information in their structure.

The traditional model starts with a more complex model design but has less complex programs that use it. The object model has a very simple model design, but all of the "smarts" go into the programs that use it. To determine which model is better suited for your needs, you need to examine the specifics of your organization (see Figure 1).

Factor Question
Data architect/modeler experience level Can the data architect/modeler perform the task?
Time frame for deployment Does this repository need to be built quickly or is the time frame flexible?
Programmer experience level Can the programmers writing the front end that will access the repository perform the task?
Program complexity versus model complexity Do you want a model that is simple to maintain and the access programs are complex or do you want the model to be somewhat complex and the access programs to be simple?
IT infrastructure Can the current environment support the model being proposed?
Flexibility Do you want to be able to add anything at anytime to the repository without changing its structure?

Figure 1: Influential Factors in Your Choice of a Model Text for Figure 2 Model Complexity Access Program Complexity Expandability Development Time Ease of Understanding

As you can see, there is a lot that has to be done to build a quality meta model that can grow with your company's needs and still remain flexible. In this article, we described the two types of models that can store meta data (object and traditional) and have examined the factors and rules that help us decide on a model type for our company. Things like project schedules, model flexibility and staff experience levels all play a role in selecting a model type.

Both types of models have advantages and disadvantages (see Figure 2 for a summary). The object model is more scalable and flexible than a traditional model, but also less intuitive and harder to understand by looking at it. This is because the object model stores in its tables the actual structure of the meta data that you are storing. The traditional model, on the other hand, contains many more entities and relationships, but is easier to understand and work with than an object model. The choice of an appropriate model type depends on your particular environment and user requirements for the meta data and requires careful research on your part to make an informed decision.

  Object Model Traditional Model
Model Complexity The object model is very simplistic in its design. The traditional model has entities for each type of information that you want to store. The model is more complex because of all the relationships and tables that must be defined.
Access Program Complexity The access programs for the generic object model are complex. The access program must understand the rules that allow the data to be put back into information. The accesses programs for the traditional model are quite straightforward. Depending on the information that is required, the access program may simply be a series of joins.
Expandability The object model is infinitely expandable. The traditional model is expandable but grows increasingly complex as the number and type of information required grows. The model could easily grow to incorporate tens or hundreds of tables.
Development Time The majority of the development time for the object model is in understanding the information required and the rules that define that information. Most of the development time for the traditional model is spent understanding the information that is required.
Ease of Understanding The object model is not an easy model to understand just by looking at it. It reveals none of the information contained within it. To understand the information within you need to examine the values contained within the model. The traditional model is much easier to understand. By examining the model you can see the kinds information contained within it and the relationships between that information.

Figure 2: Object Model Versus Traditional Model

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