The power of Rational Data Architect

An overview of Rational Data Architect and SOA

Learn about the salient features of Rational® Data Architect (RDA) and its place and use within the software development lifecycle using the Rational Software Development Platform (SDP). In today's world of Service-Oriented Architecture (SOA), data is a vital component. This article explains how RDA addresses the issue of data's importance in SOA, and how RDA is used in a business environment.


Periasamy Girirajan (, I/T Architect, IBM

Periasamy GirirajanPeriasamy Girirajan is an IT Architect working with IBM. He has a decade of experience in the IT industry. His specialization includes application, information, and infrastructure architectures.

02 August 2007


The evolution of software development has taken a paradigm shift from the monolithic architectures of the past that used conventional procedure-based programming. After procedural programming came the era of client-server computing, where there was a notable distinction between data and the client and business logic. This is the era where the programmers began looking at data as a separate entity, but more at an application level. Next, the e-business era paved the way for manipulating data in a more secure fashion.

Today, in the current SOA era, data is regarded as a service at the enterprise level, and the importance of data has increased dramatically. Every business alignment service must have a data model. State-of-the-art products such as DB2® 9 help to unleash the power of data as direct XML content, as required by Web services in the SOA environment.

Rational Data Architect is one of the flagship products of the IBM Software Development Platform. It is part of the IBM Information Management software portfolio and enables SOA development and implementation. RDA works with many industry-standard database servers, incluing DB2, Informix® Dynamic Server, Sybase, Oracle, SQL Server, and Cloudscape™. It supports DB2 on System z™ and System i™ platforms.

RDA is Eclipse-based and has a standardized user interface, like other products within the SDP. RDA also integrates with Rational RequisitePro® for requirements management, and ClearCase® for versioning and team work.

In many development projects, data is not given much importance compared with the application architecture. In many cases, industry-standard tools are not used for the data architecture portion of the project. Rational Data Architect helps data architects close the gap between the application architecture and information architecture, and ensures seamless alignment of data in the overall solution architecture.

RDA provides transformation from Unified Modeling Language (UML) to the Logical Data Model and vice versa. Proper usage of data modeling tools helps to avoid re-factoring of the application at later stages. Rational Data Architect is an end-to-end tool that can be used for data modeling, transformation, DDL script generation, and to build, debug, and manage database objects such as SQL stored procedures and functions.

In the SOA environment, data is critical factor for successful implementation, as the entire process choreography is all about invocation of services through messages that have the data encapsulated within them. Messaging between services and data models is closely related. The data models must have sufficient detail as required by the service. If the service has to execute complex queries or stored procedures to get the required data, then the performance of the service will be at stake, reducing the quality of service.

RDA's place in the IBM SOA foundation

Like the Rational Software Development Platform suite of products, IBM Information Management software has a suite of products which handles the information layer in an SOA environment. This can be best understood with respect to the IBM SOA foundation illustrated in the figure below.

Figure 1. IBM SOA foundation
IBM SOA Foundation

The SOA lifecycle consists of four phases

We'll look at each of the four phases below.


This phase typically deals with requirements gathering with customers. The requirements include business process models, functional requirements, and translating the requirements into architectures of various domains, including application, information, and infrastructure. Rational Data Architect helps in this domain to study the existing information model or build a new one based on the business process model and functional requirements.

The other SDP tools which are used in this phase are Rational RequisitePro, WebSphere® Business Modeler, and Rational Software Architect. Rational Data Architect has a tight, seamless integration with RSx (Rational Systems Developer, Rational Software Architect and Modeler) in the sense that it can perform a logical data model to UML transformation and vice versa. This feature helps to ensure that every application component or service identified has an underlying data component as well. ClearCase, one of the products in Rational SDP, is used for configuration management. Rational Data Architect can be integrated with it for data model version control and team development.


This phase involves the development of services, components, the underlying physical data model, and database objects. RDA supports several database servers such as DB2 (including System i and System z), Informix, and Cloudscape. RDA has wizards, an editor, and a debugger for DB2 that helps in the development of SQL statements, stored procedures and user-defined functions.


This phase involves the deployment of the components which are assembled in the previous phase. Typically the WebSphere stack is used in this layer.


The services and business processes which are deployed are managed and monitored primarily by products like WebSphere Business Monitor. Service level characteristics are calculated to ensure smooth running of the application in the runtime environment.

Let's look at the capabilities of Rational Data Architect much more closely as an accelerator for information architecture development. RDA helps in the following areas:


Most of the time, the development environment is not a "green field" environment, because there will be existing assets and databases which need to be considered for new development. Often, due to development timeline pressure, documentation might not exist, or, if it does exist, it might not be in synchronization with the physical data model in production. RDA can be helpful to handle such scenarios. RDA can be connected to the existing database using standard JDBC connectivity. The Database Explorer discovers the existing physical data model in real time, without requiring a complete reverse engineering of the existing database

Figure 2. Existing database discovery
Existing database discovery

The discovery allows users to analyze the objects that are part of the physical data model. This feature helps in identification of Information which might be required for the target application that is being developed. Using this feature, data optimization can also be achieved at an enterprise level.

Figure 3. Discovered PDM
Discovered PDM

Data modeling

Like UML models that are abstractions of the application architecture, data models represent the abstraction of the information model. In information engineering, data models are classified in the following categories, based on the elaboration levels that span from conceptual to the operational data store. RDA supports the creation and use of the following models:

Domain model: Domain models primarily contain domain types which are used in multiple places across the application model, for example for fields such as currency and sex, which have predefined data types or values. It is primarily used with logical data model.

Glossary model: This is used to ensure the data model uses pre-defined naming conventions in naming data entities. In most organizations, these data models are at the enterprise levels.

Logical data model: Logical data model represents the enterprise entities, their attributes (data) and the relationship among them. They are database-independent entity-relationship models that are target independent. The following are the relationships an entity can have:

  • Generalization
  • Identifying foreign key relationship
  • Non-identifying mandatory foreign key relationship
  • Non-identifying one-to-one foreign key relationship
  • Non-identifying optional foreign key relationship
  • Many-to-many relationship

In a SOA scenario, these logical entities would ideally map on to a service component which would in turn realize atomic or composite services. The logical data model primarily consists of packages and entities. Entities are representation of real world objects which can have constraints and relationship with another entity, as shown in Figure 4.

Figure 4. Logical data model
Logical Data Model

Physical data model: Physical data models are database specific and represent the database schema. They are transformations of logical data model where the entities and relationships are transformed into tables, columns, primary keys, foreign keys, and constraints.

Figure 5. Physical data model
Physical Data Model


RDA helps architects in normalization of the developed model. It checks the naming conventions, syntax, and normalization levels. There are pre-defined rules which are used to validate model and databases. These rules are also extensible beyond the available standard set. This feature helps in standardization across enterprise.

Figure 6. Model standardization
Model Standardization


This feature is primarily used to compare models, databases, objects in databases and models. It also helps in synchronization of logical data models and physical models. Either a report can be generated or the models can be synchronized online.

Figure 7. Model synchronization
Model Synchronization


This feature helps in data conversion between TO-BE and AS-IS systems. where the databases are compared to find out the level of complexity required for data transformation to migrate the data to the target systems. It helps in comparison of columns and helps identify relationship among source and target objects. It also helps in types of relationship between source and target, such as aggregations, transformations, and arithmetic operations. It also helps in generation of data migration maps, to perform dependency analysis and also helps in optimization of target system data model. There are several techniques used in relation building though the interactive GUI and intelligent discovery. The existing mappings also can be combined to build a composite mapping.

Figure 8. Relate


This feature helps in generation of mappings between remote schema and federated schema. Transformation functions and mapping groups can be used for generating the code for WebSphere Federation Server.

DB2 development

Rational Data Architect provides the IDE required for DB2 object development such as stored procedures and user-defined functions. The IDE also has debugging capabilities for these objects. Apart from these features, RDA also supports the building and editing of DML statements using the SQL builder.

Figure 9. DB2 development
DB2 development

As Rational Data Architect is based on the Eclipse framework, it provides team support using standard tools such as CVS.


This article has introduced the basics of Rational Data Architect and how it fits into the IBM SOA foundation. Refer to the resources below to deepen your knowledge and learn how to implement it in your environment.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Information management on developerWorks

Zone=Information Management, Architecture, Rational, SOA and web services
ArticleTitle=The power of Rational Data Architect