Data modeling objects
In this section, I show you some of the many data objects that you can model in Rational XDE.
The database object
At the time this article was written, the Rational XDE plug-in supports lots of databases, including DB2 UDB for Linux, UNIX, and Windows (from Version 8 back to Version 5) and DB2 UDB for z/OS (from Version 7 (V8 is coming soon) back to Version 5).
Each Rational XDE project can contain multiple data models and each data model can contain multiple databases. To keep it simple, I illustrate a single database (shown below). You can add the database to your model by right-clicking on the Main object in the Model Explorer and selecting Add Data Modeler->Add Database. (Note that this object is not synchronized to your deployment environment - if you want to forward engineer objects you create to this database, it should already exist.)
The table space object
A table space maps the logical design of the database to disk. Using the Add Data Modeler option in the Model Explorer window, you can add a table space to your data model. After defining the table space, you can drag-and-drop it onto the data model and its association with the TESTDB database is automatically generated:
Once you have added the table space to your data model, you can define its properties by selecting the table space, right clicking the mouse button, and selecting Data Modeler->Open Specification.
You can see in the previous figure that you have most of the options that you would expect to have when creating a DB2 UDB table space, including: prefetch size, extent size, assigning a buffer pool to the table space, specifying how the table space will be managed, and so on.
The domain object
Rational XDE has a domain object that can be used to set business rules for the database. Using a domain, you can define rules such as required fields and default values. The great thing about a domain is that you create it once and bind it to as many fields in the database as you want. This object is especially useful when the application development teams have the autonomy to create the schemas, yet the database administration team wants to ensure the development teams implement new schemas in a 'best practices' or 'practiced standards' manner.
The domain object is a new approach for database administrators (DBAs) in that they are used to defining these rules on a per table basis. More advanced DBAs utilize a user-defined type (UDT) to enforce these type of restrictions, yet they are on a per database level.
Consistency and maintenance benefits can be accrued using domains in a data model. For example, if you implement a Phone Number domain, then all phone numbers in your data model (home, work, cellular, and so on) can inherit the rules that you define for any sort of phone numbers (they must include the country code, and so on). In addition to this, if the data ever needs to be changed, you can do so in one location and trickle down the rule to all data columns that are built from the domain (for example, adding an area code to a phone number to support local calling).
The following figure shows an example of defining a domain - notice the Check Constraints where you can define code check for the data.
The table object
Once you have created a database and specified how it will be defined physically on disk (remember, the domain object is optional), you can add a table to your data model. You can add a table to your data model by selecting the Table object from the Data Modeler Toolbox and dragging the object onto the palette. This action will open the Table Specification window, as shown below:
You can see that you have most of the DB2 UDB options that you would expect when creating a table. You can define columns and their data types (including identity columns), referential integrity (RI) constraints, triggers, domain associations, key constraints, and more.
Once you have finished defining your table, the schema will be updated in the data model, as shown below. (Simply associate the table with the database by drawing a Database Realization line from the database to the table - this object is available in the Data Modeler Toolbox.)
You could continue to model additional objects, including stored procedures, triggers, Primary and Foreign key relationships, RI rules, views, and more.