As data integration becomes more complex and far reaching to need to make sense of the hundreds, sometimes thousands of data stores within an enterprise or trading community is becoming critical. Indeed, corporate data typically exists in many different types of data storage technologies and schema types. Thus creating a common view of the information for any purpose is essential in both establishing a strategic integration infrastructure, as well as making business decisions using live, and meaningful corporate data.
Indeed, we've seen the rise of data abstraction middleware designed to place any number of enterprise databases, sometimes APIs, and even Web services, behind an database abstraction layer. This is really nothing new, we've been creating virtual databases in middleware for years. However, the capabilities of certain vendors have made this type of technology carry an enhanced value proposition, and this type of solution will find its way into many enterprises.
Of course, this is EII (Enterprise Information Integration), and older term and class of technologies, that continues to have value. This is also known as virtual databases, also known as data federation. For our purposes let's call it what it really is...database abstraction. Data abstraction layers, and the technology that provides this mechanism, could indeed become one of the most important integration tools in the arsenal, making use of many heterogeneous databases much easier to deal with, and thus making those databases more strategic in nature.
The notion of data abstraction layers follows a few basic principles:
First, it's better, less risky, and less expensive to leave the data where it is, instead representing it differently depending on the required pattern of use. When using this type of technology the idea is to leave it be and make it useful in other less invasive ways.
Second, provide a flexible mechanism, allowing the data view (represented schema) to change based on how the data needs to be seen. Thus, we can represent one or many physical schemas in many different ways, depending on the need. You can create hundreds of views customized for hundreds of different purposes, even reusing views from interface to interface, purpose to purpose.
Finally, provide a single update mechanism to multiple databases, database types, and database schemas. This mean a single update may be applied across many different physical databases.
Leave a comment