The successor to OWB is the Oracle Data Integrator. This tool has more functionalities than OWB. Next to that, it has an interface that more or less steers the user through a series of steps.
The idea is that one starts with a technical view where the file locations, databases and schemes are declared. Once that is done, one creates a set of logical names that provide the user with an understandable name that can be used to create a so-called mapping. If the mapping is created, it can be run to see if it works.
Let me first introduce the technical aspects. This can be done in a widget that is called “topology” where the technical architecture can be defined. One may see a set of technologies that allow to specify a technical object. As example, one may look at the technical indication of a file. The object file_tom provides a manner how a file is accessed. There, the driver is provided. In the object beneath, one may indicate the directory where the files are stored.
Similarly, the technology “Oracle” has an object ” Oratom” where the JDBC driver is provided. Beneath, another object is created where the scheme is provided.
Let us switch to the logical design. We have the possibility to define logical handles that link the technical concepts to logical handles. We have “File_Tom” that is logically linked to the File_Tom that we have defined in the physical architecture. The same holds for “ODI_Tom” that is the logical handle for the physical defined scheme.
A crucial link between the logical handles and the technical objects is thru the idea of ” context”. This provides a scheme where logical handles are linked to physical entities.
This is almost genial is its triviality. If we have more contexts, we may create a development, test and production contexts. Promotion into production is then just a change in context.
We are now in a situation where technical concepts like a scheme or a file location are translated into logical concepts. In a subsequent step actual files and tables can be accessed. This is done in the designer tab, under the models. We can reverse engineer the file definitions and table definitions from the physical environment. We then get something like this:
Here, we have the logical components (Names as file definition and names as table definition) that are added to the models. The file definition “names” is added to “File_Tom” that is derived from the logical component that we created. Likewise the table definition for “Names” is added to FlatFile2Table that is linked to the logical definition for the scheme that we created.
The logical definitions for the file and table can be used in a mapping. We now have a logical definition for a source and a target. This can then be used in the mapping. In this example the mapping between source and target is almost trivial:
The mapping can be run in several ways. I believe there are about 4 ways to run a mapping. When a mapping is run, one has to fill out the LKM (Loading Knowledge Module) .
This can then be run and the content of the file is loaded into the table.