« Privacy and Syndicated Data | Main | DIdn't Anyone Notice Incorrect Reports Before MDM? »
January 30, 2007
Will Web Services Degrade the Relational Idea?
Sometimes things are so obvious that we never think to actually utter them. It can be an enlightening experience to try to tease these things out of our various mental models. It can just as likely be sort of upsetting too, but I’m confining this to discussions about technology.
For instance, what is the big deal about data integration? If I have a ton of data in SAP R/3 and I want to use it somewhere else (and by “use” that could mean extract and transform, or just read or something in between), and that data, no matter how obscure, is in a relational database, why can’t I just read it?
That previous paragraph is a rhetorical question, of course.
One of the reasons it is so hard to explain to people (clients) why this is so difficult is that data IN a relational database is not necessarily modeled that way. What does that mean? It means, if your application program uses the relational database as a big bag of persistent data, but carries all of the relevant logic within its application code, it isn’t, strictly speaking, relational.
When relational databases first emerged for business applications, many IT shops were urged by their vendor (IBM) to move things to DB2. Application vendors, in the pre ERP days, like Walker Interactive, did crazy things like move the entire code block of the chart of accounts to a single, concatenated text field. This made it impossible to select or join anything, one had to read the transactions sequentially and parse them in COBOL code to do anything with the system. This is the opposite of the desired effect of a relational database, where the data is supposed to be arranged in a logical schema (well, a physical representation of one), and at least some semantics are understandable such as ACCOUNT_NUMBER means account number and DIVIVSION means division.
But with the massive functional reach of something like SAP R/3, the database is used as a dumb container and the real data is first buried under a few layers of indirection (because the application code is object-oriented, and some data is class data and some is object data, though that is a wild oversimplification).
R/3 also compresses what should be some 10's of thousands of tables into a few thousand by combining many, unlike tables into one. Learngin all the tricks and hidden hard and soft pointers is possible, but it doesn't take into consideration the amount of customization that is routinely applied before one of these systems goes live.
But this begs a very important question – what’s wrong with that? Why in the world would you want to try to grab raw data from something as complicated as R/3? Wouldn’t you rather rely on its own internal services to handle requests and serve up exactly what you asked for, without ever having to worry about things changing? In fact, in a web services world, isn’t that exactly where we want to be?
Something to think about…
Posted by Neil Raden at January 30, 2007 4:45 PM
Comments
Neil,
This is an excellent point. In fact, I'm pretty sure you violate your license if you go right after the tables.
Web Services really are a kinder, gentler BAPI, if you will (Which in and of itself is a good thing.).
The only problem I see is that vendors can sometimes make these interfaces proscriptive. A good case in point is Salesforce.com. Their SOQL (Salesforce Object Query Language) is accessed via SOA, and can query for what you're looking for, but it can't do joins. Which means that if you want to join stuff, you need to put it back into a relational database. Oh, my head hurts. Plus ca change...
Posted by: Tim Matthews at February 5, 2007 5:05 PM
