Book Image

Oracle Data Integrator 11g Cookbook

Book Image

Oracle Data Integrator 11g Cookbook

Overview of this book

Oracle Data Integrator (ODI) is Oracle's strategic data integration platform for high-speed data transformation and movement between different systems. From high-volume batches, to SOA-enabled data services, to trickle operations, ODI is a cutting-edge platform that offers heterogeneous connectivity, enterprise-level deployment, and strong administrative, diagnostic, and management capabilities."Oracle Data Integrator 11g Cookbook" will take you on a journey past your first steps with ODI to a new level of proficiency, lifting the cover on many of the internals of the product to help you better leverage the most advanced features.The first part of this book will focus on the administrative tasks required for a successful deployment, moving on to showing you how to best leverage Knowledge Modules with explanations of their internals and focus on specific examples. Next we will look into some advanced coding techniques for interfaces, packages, models, and a focus on XML. Finally the book will lift the cover on web services as well as the ODI SDK, along with additional advanced techniques that may be unknown to many users.Throughout "Oracle Data Integrator 11g Cookbook", the authors convey real-world advice and best practices learned from their extensive hands-on experience.
Table of Contents (19 chapters)
Oracle Data Integrator 11g Cookbook
Credits
Foreword
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Using one single interface to load changes that occur in any dimensions


When data is de-normalized, data that is originally in multiple source tables often ends up in a single target table. From that perspective, changes that occur in any one of the source tables have to be reflected in the same target table.

One challenge here is that if you simply join the changes from the different source tables while loading the target table, you will only have data to load if all tables have changes: that is, if we simply join the changes from SRC_EMP to the changes from SRC_DEPT, we will only have target data to process when changes occur simultaneously in both tables. If one of the sets is empty, then we will have nothing to process.

For this reason, ODI will only accept one journalized table per data set, and the interface must be duplicated to process the changes of every single one of the source tables. This can be a daunting task if you have a lot of sources and complex mappings. With this recipe...