Import from a Database
If you already have an existing system with a SQL Server database then you can jump-start
Xomega object modeling by importing the model from the database using this generator.
It will build the objects and fields from the corresponding database tables and
columns and will define the logical types for the fields that will preserve relationships
between objects. Prior to running the generator though, you need to make sure you
pre-configure the model as described below.
The generator will try to map the database types to one of the existing Xomega types
or, if not possible, will define a new type that derives from one of the existing
types. Therefore, before you run the import you may want to make sure the existing
types' configuration is consistent with your current system standards. For example,
the boolean type maps by default to a SQL Server type bit. However if the standard
for your current system is tinyint to store a boolean, then you should update the
Xomega type to map to tinyint, so that it can be properly identified by the generator.
By the same token, the generator can identify groups of fields that match one of
the field-sets defined in the model and use a reference to the field-set instead
of those fields. If all or most of your tables, for example, have a set of standard
columns, such as the user who created the record and the creation time stamp then
you can just define such a fieldset in your model first and it will be automatically
used by the imported objects. If later on you will want to also add the user who
last modified the record and the last modification time stamp then you could just
add them to that field-set definition and they will be automatically included in
all the objects that use that field-set.
What you should also be cognizant of is that Xomega subobjects are inseparable from
their parent objects and require a cascading deletion whenever their parent object
is deleted. As a result, for the Import generator to define objects as subobjects
their foreign key relationship to the parent object should have cascading deletion
and the columns on both ends of the relationship should have the same names. If
you would like some tables to be imported as child objects then you may want to
consider updating their foreign key relationship accordingly before the import.
When importing the model from a database you should first of all define the database
connection for the generator.
You can do it via the Database Connection Configuration dialog that pops up from
the generator's Properties page. In that dialog you should specify an OLE
DB connection string to your database, which Xomega will validate and use to
read your database metadata. On the next tab of the dialog you can specify which
database tables you would like to exclude from the model. Next, the system will
try to determine if your database names are case-sensitive and will set the
Database Case to CamelCase or your choice of UPPER_CASE or lower_case
respectively, which will be used for generating tables for all new objects as
It makes sense to save this database configuration as default project settings,
which will be one of the options in the dialog, so that all other
database-related generators could reuse the same settings. This way, for
example, the database change script generator won't try to remove the tables
that have been explicitly excluded from the model. If you save it as a default
configuration then it will be available in the project Properties page and the
corresponding generator properties will be set to the 'Use Project Setting'
The generated Xomega files will be automatically added to the project under the
folder designated by the Output Destination property. You can leave it blank to
output to the project folder but you may want to consider generating it in some
project sub-folder initially (such as the default Import/ folder). This will
allow you to review the generated files and if you realize that you need to make
some of the prerequisite adjustments then you will be able to safely clean the
generated output without affecting any of the existing files and rerun the
generator. Keep in mind that the Clean or Regenerate commands will just delete
all files in the destination folder that match the output patterns specified in
the following property. It is recommended to keep the default Output Patterns
for this generator (**/*.xom), which refers to all .xom files in the output
destination directory and its subdirectories, since this is the default
extension for Xomega Editor.
Finally, you may want to configure additional generator parameters that allow
you to preserve certain database names in your model. This can make your model
significantly larger, but it will ensure that the model objects and fields
always map to the same tables and columns even if you rename any objects or
fields in the model. The table and column names for new objects and fields will
be derived from their names unless you specifically configure them to use
certain database names.