Fine tuning your logical to physical DB transform

When you use JDeveloper's class modeler to design your logical database you are able to run the DB Transform to get a physical DB model. But have you ever been frustrated at the limitations of the transform? for instance -

• name to be used for the physical table
  
• attribute to be used as the PK column
• datatype and settings to be applied to a specific attribute
• foreign key or intersection column names
• different datatypes to be created for different database types

In JDeveloper 11.1.2 additional fine grain and reusable transform rules are available to you using a UML Profile. This is a UML2 concept but for database designers using JDeveloper it means you can set many properties at the logical model that are used when the transform to physical model(s) is run.

There is a section in Part2 of the tutorial Using Logical Models in UML for Database Development that details using the DB Profile, so I will not repeat the whole story here, but give you a flavour of the capabilities. Once you've applied the profile to the UML package of your class diagram you can set stereotypes against any element in your diagram. In the image below you are looking at the stereotype properties of the empno attribute - that will become a column in the database. Note that this column is to be used as the primary key on the table. Also note the list of Oracle and non-Oracle datatypes listed. Here you can specify exactly how empno should be transformed when multiple physical databases may be required. If the property for any of these is not set then the default transform will be applied.

You could say that having this ability as part of the class model bridges the gap between this model (being used as a logical DB model) and the tranformed physical database model - it provides some form of relative model capability.



Looking at another new feature in 11.1.2.0, the extract right shows other elements on the class diagram. I've created a primitive type (String25Type) and using the stereotype have specified how this type should be transformed. Now I can use that type on different classes in my diagram and the transformer will use it as necessary.

There are many other ways to fine tune your transform, run through the tutorial and try them for yourself

Hudson and me!

Over the past months I've been working more and more with Hudson, the continuous integration server. If you're familiar with Hudson then no doubt you are familiar with the changes that faced it in that time. If you're not - well, it's a long, well-documented story in the press and I will not bore you with it here!

But the most important thing is that Hudson is a great (free) continuous integration tool and continues to grow in popularity and status. Oracle became its supported from Sun's original open source project. As well as its community of users and developers Oracle has a full-time team working on it, including me as Product Manager, and it recently started the process of moving to the Eclipse Foundation as a top-level project.

Internally we use Hudson across the organization for all manner of build and test jobs and I know that many of you do too.

In JDeveloper 11.1.2 we've added new features to Team Productivity Center (TPC) to integrate Hudson (or Cruise Control) build/test results into the IDE and relate those to code checkins via the TPC work items. You can see a quick demo of that here

If you use Hudson I'd like to hear from you - in fact, I'd like to hear from you anyway! So please contact me at the usual Oracle address. Other ways to keep up with Hudson are through its mailing lists, wiki and of course twitter - @hudsonci