Frequently Asked Questions (FAQ)
I feel like I'm talking to myself when I'm writing these things.  It's oddly comforting.

Q) What does XMI2SQL stand for?
A) The "2" in XMI2SQL means it is a tool for getting SQL out of XMI.  XMI stands for XML Metadata Interchange.  You can read more about XMI at  XML stands for Extensible Markup Language.  You can read more about XML at  SQL stands for Structured Query Language.  There's really no official place to read about SQL unfortunately.  The ANSI/ISO organization charges a lot of money for their standards, so ordinary people like you and me are not allowed to see them or use them.  That is why I prefer to work with Open Standards.  You can take a look at for some outdated, but useful, information on SQL.

Q) What does XMI2SQL do?
A) XMI2SQL fills a need that exists in the area of database design.  To put it simply, there is no easy, loosely-coupled method for converting a data design (in UML) into implementation (a Database Management System (DBMS) running with the tables as the user expects them to be).  To be sure, there exist methods for doing it, but they are, as a rule, tightly coupled with both DBMS vendors and CASE tool vendors, removing a lot of power from the user.  XMI2SQL provides a way out, so the user can have control over which CASE tool and DBMS to use, as well as the conversion method.  The user creates a data model using a CASE tool of choice, and then exports that model into XMI format, the standard format for UML diagrams in XML.  Then the user inputs that file into XMI2SQL, along with information about what format the user would prefer the SQL to follow, and XMI2SQL outputs the appropriate SQL commands for implementing the database.  Therefore the user has ultimate control over both the CASE tool used for modeling, and the DBMS used for implementing.

Q) But UML is for object oriented software, not relational databases.  How can I stuff a fully featured data model into a UML diagram?
A) A data model needs to encapsulate all the metadata required to implement the model, while being in a human friendly format. (read diagrams)  UML is the defacto standard for data modeling.  But UML is designed for representing object oriented software design.  Relational databases are not object oriented, and therefore there are some disconnects between the needs of a data modeler and the UML language he is confined to using.
To overcome these disconnects, a UML Profile must be used.  A UML Profile consists of a standard interposed on top of the UML standard, requiring a certain set of Stereotypes and Tagged Values to encode further information about the UML elements.  Unfortunately, not all CASE tools equally support the Tagged Value extension.  Hopefully that will not be the case forever.  But for now, users of XMI2SQL will need to use CASE tools that support Tagged Values for attribute elements.

Q) So what is this "Data Profile"?
A) There are two popular UML Data Profiles - the Agile Data Profile and the Rational Data Profile.  Both accomplish the same goal - allow database designers to encode their data models in UML.  I chose to use the Agile Data Profile because it is more intuitive, more accessible to humans (as opposed to the Rational Data Profile that seems to be mostly designed for their CASE tool "Rose".)  The Agile Data Profile makes use of both the Stereotype and Tagged Value UML extensions.  The Agile Data Profile also is a collaborative effort, and the author (Scott Ambler) accepts requests from people that would like to see changes or additions to the profile.  I actually helped to define the "source column" tagged value in Table 6.  In order for XMI2SQL to understand a data model, it must use the Agile Data Profile.