Why?

 
MMX Framework's schema is simple: just six tables, three to describe metamodels and three to store metadata. But when it comes to accessing the stored data, users, especially novice users get confused. 
 
SELECT 
    object_id, object_nm 
FROM
    MD_OBJECT 
WHERE
    object_type_cd = mmxmd.get_object_type('Core', 'Document')
 
"Why can't we just have a table Documents?" they ask. You tell them (again) about metamodels and how all this is so flexible and stuff. And then they want a list of documents with some properties and gets complicated. And when you step into the MD_RELATION realm, you have usually lost about 2/3 of your followers. Now what?
 
Or there is an application in your system, legacy or not, that needs to access the MMX data and it's developers are not willing to access anything more complex than a view. A typical integration case, as we have encountered.
 
Or you want migrate an old app to MMX and do not wish to update all those integration points you have built for it other the year. 
So you have to build an view on top of MMX tables for clean and the-way-the-things-always-were access of you MMX data.
 

How?

 
There are three obvious choices on how to materialize MMX data:
  • views
  • materialized views or table for high performance need
  • tables with a set of INSTEAD_OF  triggers that gently allow user to update metadata in MMX schema without actually accessing the actual MMX tables.
The last option is obviously something you will never want to implement. There is an application level in Java or .Net or Ruby to handle all those things the they should.
 
In this series we will be operating under following assumption: we build views to read data, not up update it.
 
Whatever the metamodel that you will be materializing; we suggest that you always should use LEFT OUTER JOINs to bind MD_OBJECT, MD_PROPERY and MD_RELATION tables. You should do this at least for these two reasons:
  1. metamodels are build that way - properties and relations are not required
  2. metadata quality does not allow you to presume that the required properties and relations exist
 
Using a lot of LEFT OUTER JOINs means slower performance. If your data is read often, it may become a performance issue. To counter that, physical materialization of the views is suggested. Different database platforms that MMX supports provide different options for physical materialization, just pick your favorite, but bear in mind, that no physical materialization is needed unless the load from your integration point will become noticeable.
 
In the next three parts of these series we will:
  • build object materialization view generator
  • talk about advance object materialization options
  • build many-to-many relations materialization generator.