What’s new in Optim Development Studio and pureQuery – (Also trial is now ready for download!)
IBM_Optim 27000269HS Visits (3763)
Updated September 16 to correct an error. To clarify, the SQL literal replacement capability is available for DB2, IDS, and Oracle databases as stated correctly in this feature table.
It’s only been a few months since our last release, and my team and I have been busy taking our products closer to realizing the Integrated Data Management vision for integrated lifecycle development and heterogeneous database support.
So what's different in this release? With the announcement and release of Optim Development Studio 2.2 (formerly Data Studio Developer), we added:
As the architect for pureQuery tools, I wrote a new developerWorks article that goes into some detail on the new capabilities, mostly from a pureQuery perspective. (You can see more about the other Oracle support capabilities in Venkatesh's blog.) I’ll give you some highlights of this release from a pureQuery perspective in hopes that it will convince you to go read the article and download the trial code!
Some of the important features –
Oracle pureQuery support
The big news of course is support for pureQuery capabilities for Oracle databases – pureQuery code generation, SQL content assist, validation and all the editing capabilities ( now also available for JDBC, and native SQL in JPA and Hibernate applications), client optimization, dependency analysis, hot spot analysis. If you aren’t familiar with these capabilities, my article does review them.
The screenshot below shows a sample pureQuery application that was run against Oracle. Using the SQL outline (formerly called pureQuery outline), you can see the performance metrics from the Oracle queries. You can also see predicted cost using the EXPLAIN Data option. (That EXPLAIN Data option is new for DB2 and IDS as well.)
Visibility of data privacy attributes to developers
The other interesting integration work that was done is the ability to maintain data privacy attributes from modeling through development and test. Anson Kokkat touched on this in his recent blog. Production databases often contain sensitive information such as credit card numbers or social security numbers. When data architects create data models for such databases using InfoSphere Data Architect, they can identify which attributes or columns contain sensitive information and specify appropriate privacy policies to be used with them.
By associating this model with their database, developers can easily see which columns are identified as containing sensitive information and this can help them maintain compliance in how they handle that data in their applications. This protection also extends further to their applications - they can see how those private columns are being used in context to ensure they are not doing something inappropriate, such as printing out data in those columns.
The screenshot below shows the private columns in the SQL outline (a little padlock icon is used to indicate a private column), their privacy properties, and how you can navigate to the model to get more information.
Other key capabilities include:
There are really a lot more enhancements, but you’ll need to read the article – I don’t have room to list everything here. We’re also working on some videos that will show these features in action. (Now available starting here!)