Happy Friday the 13th, everyone! Hope your day was lucky and your weekend is good.
Today I want to dig down a little bit on how data modeling can help DBAs be better at their jobs and become more valuable to the organization. You have probably heard about the key benefits of the IBM Integrated Data Management portfolio, including improving productivity, saving time, reducing costs, and improving collaboration among roles. I’d like to propose that as much as any data development or performance monitoring tool, using InfoSphere Data Architect for data design and discovery can provide tangible (and not so tangible) benefits to DBAs and the organization both in the short term (rapid response to changes) and long term (improved skills, better quality data models, etc.).
Let’s look at skills and productivity in a heterogeneous environment first. Data Architect is a heterogeneous tool. If your shop is like many I see, you have to deal with multiple databases, such as Oracle and DB2 for z/OS. Or DB2 and SQL Server. Or Informix Dynamic Server and DB2 and MySQL. Whatever combination you may have, what you really want is a single tool that works with all these different data servers.
Having a single tool that generates the DDL from several different database vendors means you don't need to be an expert in all of them. It allows the DBAs to become more skilled across more products and thus allows DBAs to do more with less, and as their skills grow they become more productive and valuable to the enterprise.
Even if you don't have multiple database systems to deal with, InfoSphere Data Architect can help DBAs be more responsive to ‘agile’ development scenarios (or any scenario in which requirements come in late – all of them?). Designing databases from scratch is always difficult, but having a data modeling tool to can really ease the pain. So, if a developer says "I just remembered, we forgot to take the modules from Sally's group into account," it’s pretty easy to manage that kind of change with InfoSphere Data Architect. My recommendation is to manage all design changes through the logical data model, and then transform as appropriate to the physical model required for the target database, which, by the way, might very well be different vendors between development, test and production. You don’t have to follow this approach, but it is a best practice.
Another scenario: Let's say that your company has recently acquired a company and it’s your job to integrate their database into the main corporate database. And by the way, they have no or little documentation on what is in their databases. No problem. Use the Data Source Explorer in InfoSphere Data Architect to reverse engineer the existing database to get a nice diagram of the physical data model to see what they have already. Then you can compare what they have with what you have (for example, do we really need another customer table? Or can we just migrate their data to ours by maybe adding or modifying a column?). If you need to make changes to accommodate their data model, you can generate the necessary DDL to do so and can even deploy directly from the tool if you like.
Speaking of inheriting database, another DBA might pass you a database model that has cryptic table names or cryptic schema names. Just looking at the table name you can’t tell what it means and it doesn’t match anything else you have seen before. InfoSphere Data Architect can help you "decipher" the cryptic database model against a glossary that defines your enterprise standards. The glossary is a way for you to enforce naming conventions or decipher a table you created in the past. If there are any discrepancies or a newly created table doesn’t match the glossary, the tool will help report these back to you so you can fix them.
The nice thing about Data Architect that is different from other modeling tools is that it does include some cool capabilities in the Data Source Explorer such as being able to sample live data. And because it integrates seamlessly with products like Rational Software Architect for WebSphere Software
, it’s that much easier to collaborate with the application architects and exchange models with them.
Anyway, this is a lot of words, I know. I recommend that you check out this great new 'how to' demo
on developerWorks that goes through some basic scenarios so you can see the tool in action. If you want more details on the capabilities, go to the web site
, post a question using the comment link below, or send me a mail at ansonk at ca.ibm.com.
-- Anson Kokkat