Data, Data Everywhere and Not a Lot to Synch

With release V4R4 of OS/400, IBM renamed the database (again) to Universal Database for AS/400 or DB2 UDB for AS/400. Got that? Actually, with this release and expected enhancements later this year, the 400's stepchild of a database moves ever closer to its other platform siblings.

Newly included is the ability to support different data types such as graphics files, sound files, BLOBS and even pointers to other databases storing data that your program thinks is in your database. This is done with a new data link technology imbedded into the database engine. A URL points to the actual data, while your applications think they're getting the data directly, giving it great flexibility. So no matter where the data is physically stored, your application thinks it's coming from the AS/400's DB.

What does all this mean for you? Well, if you use Windows NT and databases in your shop, you probably use SQL Server from Microsoft. It's not a bad database, but it's not DB2. Until recently, it was really your only choice anywhere outside of Sybase SQL. Especially since SQL Server came with Microsoft BackOffice. Unfortunately, because it's not the AS/400, you have to manage the dblog, disks and all the things that we take for granted on the 400. On top of that, getting data from the AS/400 to SQL Server is not as easy as it should be.

If you put DB2 UDB on your PC (Windows 95,98 or NT) there's a plethora of tools to help you link your AS/400 data to your PC database. There's a configuration tool to assist in setting up the environment as well as tools to help in data replication. Now that IBM has announced UDB for Windows CE, you can even put your data on your handheld PC.

What all this means is that IBM is trying harder than anyone else to put DB2 everywhere (even Linux). It also means that you can standardize on one database, which greatly simplifies your life. There are still differences between the AS/400 version and the rest. This is mostly because we're spoiled and don't want to give up anything we have, so IBM has to figure out how to give us the new capabilities of UDB while not breaking DDS and the rest of the things we've come to know and love.

As our database grows, so does the demand to integrate some of that data to other platforms--remote, laptop, data warehouse servers, etc. Each of these can use the UDB support and keep your data implementation consistent. Nothing is more frustrating than to have to change SQL statements because one DB Engine wants double quotes and another wants single quotes.

Making sure that the data is up to date and accurate is critical to any application, as well as keeping your users' confidence. Using the Capture feature you can trap data from one database and move it to another. The Apply feature then takes this data and puts it into the target database.

Another new feature available is the Transform function, which allows you to define logic about the data you're moving back and forth. This is a great boon to data warehouse folks, as they can now group records together in the definition of the export, helping to reduce the complexity, as well as adding to the usefulness of the data. Data warehouses rely on accurate and summary data. Now IBM is giving us what we need to do that.

Data warehousing has grown over the last several years to the point that most shops at least know what it is, wish they had it, but still don't know how to get it. The problem is frequently that the production AS/400 doesn't have the horsepower to deliver standard applications as well as data warehousing capabilities. With UDB, you can add an NT, or soon, a Linux box and let your users beat the thing to death without killing your customer service department's order entry.

I've talked with IT directors that have told me they don't want to become too dependent on one vendor for hardware or software. That way if they have to make a change they think they can do it more quickly. The reality is that they can't. So pick a vendor and live or die with them if they've been good enough and promise to continue to provide for the future. Seems to me that IBM is finally doing this with UDB (I wish they'd put OS/400 on Intel years ago!)

Why have two, three or four database engines when one will work where you need it? Start that replication process (I wish I had more stock in the disk manufacturers!) and let your data be scattered. Scary isn't it?

Must Read Articles