Rational Data Architect

25 January 2008

 

Yes, I am shameless!  I am writing about Rational Data Architect because I am hosting a free Rational Data Architect Proof of Technology event on February 27th and want to drive attendance.  My last article was on Virtual Databases that WebSphere Federation Server allows you to implement and I’m hosting an event related to that too.  RDA Proof of Technology, Salt Lake City, 27 Feb 2008:  Learn about Rational Data Architect with lectures and hands-on labs at this free 1-day session!

 

RDA is IBM’s data modeling tool that allows you to model and implement databases as well as allowing you to model and implement virtual databases.  RDA can perform logical and physical data modeling like other good modeling tools that can create logical data models and reverse engineer existing databases, etc.  It can also do a lot more, like discovering relationships between databases in your enterprise, showing a database topology, modeling a virtual physical database and generating scripts to create a virtual or federated database.

 

Instead of my typical boring descriptions, this time I’ll tell the story of a fictional company, “IBMmyBFF, LLC” and how they used Rational Data Architect in their enterprise for data modeling and virtual database creation.  In this “intriguing” tale of data modeling we will mostly refer to Rational Data Architect as RDA.

 

IBMmyBFF, LLC purchased RDA because they wanted to discover and annotate the relationships between all of their databases and be able to see their primary data stores at a high level and to drill down into more detail into physical databases.  They also wanted to model a central virtual database, have RDA generate it, and then have applications needing a variety of data elements to just access that one database.

 

Discovery

 

The first thing that IBMmyBFF did after purchasing and installing RDA was to import the few Er/Win models that they had laying around and then they reverse engineered the rest of their databases into RDA.  Upon having all of their databases and models in RDA they could see all of their entities, attributes, and defined foreign key relationships in one place which was useful, but this activity really set them up for other things that they really wanted.   They also reverse engineered their XML schemas into RDA so that those could be described and accessible too.

 

Once the existing databases were in RDA, the Database Administrators (DBAs) told RDA to discover relationships between tables (entities) within individual databases and between tables in different databases.  RDA has some very good algorithms to discover relationships.  Once this was done, the DBAs and other staff reviewed the proposed relationships, deleted the ones that were not real and added names and descriptions of the ones that were.  Here is an example of how RDA displayed the relationships that it found between tables:

 

 

At this point IBMmyBFF had a set of physical models that began to add significant value to their organization.  Now everyone could view the relationships between databases and have the ability to drill down graphically and see specific table relationships between tables within and between individual databases.  Application developers, especially ones new to IBMmyBFF, immediately started saving development time by being able to see the tables with all of the columns defined in one place along with descriptions of objects that had been added by more experienced folks.  The DBAs were able to model changes to the databases and have RDA show the impacts of those changes and generate DDL to implement them.  This could be done for any of their IBM and non IBM relational databases.

 

Central Models and Virtual databases

 

Before they owned RDA, IBMmyBFF had to go through a lot of expense each time that they needed to create centralized applications that need data from a variety of divisional and corporate databases.  In many cases the databases were old and no common naming standards were used.  This meant that a lot of research had to be done just to determine where data resided each time they wanted to create a central application.  Further, the various databases were from a variety of database vendors so they either had to keep local corporate copies of the data or directly connect to each database. 

 

They decided that they would like one central database that had all naming standards enforced and had all entities, attributes and relationships defined for easy look up.  They did not have the money or time rebuild all of their databases so they decided that they would like to have one virtual database that had entities that could be accessed by all of their central applications as this would significantly shorten development time.  A Virtual Database appears to applications to have all of the tables that they need, but in reality the virtual database efficiently gets and updates the information from various heterogeneous data sources in the background. 

 

To meet their goals the Data Architects at IBMmyBFF created a logical model in RDA using their standard modeling processes and naming conventions.  They then used RDA to integrate the logical model with the reverse engineered databases and created a physical model of their virtual database with all objects using their standard names and abbreviations.  Finally they had RDA generate the data definition language (DDL) scripts to create a virtual database in WebSphere Federation Server and implemented that virtual database.  It would have been less work to them to have just told RDA to generate a virtual database with all of the objects in the remote data sources, but in this case they decided that the benefit of a well-modeled virtual database outweighed the cost.

 

In addition to the usual benefits of data modeling RDA allows IBMmyBFF to view the data sources in their enterprise at any level.  They can start at their corporate virtual database and drill down to the physical databases and objects within them.  In the following example, they could drill down on their STDBANK virtual database and see where the objects there really come from:

 

 

 

Now that IBMmyBFF had been using RDA for some time everyone became happier because they had:

 

Now IBMmyBFF, LLC is able to quickly build central applications on any of their information and are living happily ever after in the land of good corporate governance and compliance!

 

Don’t forget about the RDA Proof of Technology, Salt Lake City, 27 Feb 2008

 

The End

 

HOME | Search