Having knowledge of how you database is structured is not easy. It is often available through complex tools accessible to DBA (Database Administrator), not even developers. Management may not have access to those tools. This structure is data about the data, it is called metadata.

This article introduces the needs for a XML dialect to store the database’s metadata.

Why is it important?

In our times, people want to measure impacts more closely than ever. What happens when my supplier delivers updates of the software? What impacts has this change on your database? What impacts has it on your data?

ITIL (IT Infrastructure Library) recommends that changes should be tracked in the CMDB (Configuration Management Database). Other recommendations, including Sarbanes-Oxley, impose such archives. And simply, it is a best practice with a lot of common sense.

The problem is that there is no standard way to access, store & exploit this information.

Why is it important to have a standard?

It is important to have a standard way of storing those elements because most companies, those days, have multiple databases and multiple vendors supplying the data servers itself. It is not rare to find a shop with an ERP on Oracle, a retail application on Informix and a few web sites handling data from MySQL. Nobody is shocked.

Tools to access all those databases exist from Quest, Embarcadero, etc. But a lot of tools remain proprietary (like Command Center of DB2) or dedicated such as AGS ServerStudio for Informix…

This is the purpose of an XML dialect for storing database schema (aka database structure or database metadata).

Why not DDL (Data Definition Language)?

DDL uses SQL (Structured Query Language) and is proprietary to every vendor, and may evolve over time. DDL is not easy to parse, unless you are fluent in EBNF (Extended Backus–Naur Form).

Seeing differences between two versions of DDL can be done by using the Unix diff command, which results is not very user-intuitive. Just try to bring the result of a diff over 2 DDL files, to your CIO (Chief Information Officer), for fun.


Be extensible: all databases are different. Storing the different capabilities is not the goal, but it is critical to see where things differ and to be sure that you have a format that follows the evolution and your data server assets.