Now that we have XML data, it's time to learn how to use it.

In previous articles (parts 1 and 2), we began to explore DB2's pureXML capabilities. While DB2 provides exceptional XML data-handling, it's not enough to simply be able to store and retrieve XML data. In any real world business application, you'll also need to integrate that XML data with your existing relational data. This article shows how to do just that.

Converting from XML to Relational

Our premise is that no business stores all data as XML. This makes sense; even though XML is a very flexible way to store hierarchical data, that flexible storage requires a lot of processing power to extract the data. In our real-world scenario, master files will store the traditional data used by our business applications while the XML may be stored a little deeper. In our first foray into relational data, we'll learn how to cast XML data into relational data one field at a time. Upcoming articles will show how to use advanced techniques to build entire relation tables from your XML data. But let's start first with converting some data from XML so that we can use it.

We're going to keep using the same data from the previous articles. Here's a quick recap of the CUSTOMER table:

Figure 1: The CUSTOMER table is just a key and some XML (and an unused history field).

Hopefully, that's familiar. In the next couple of steps, we're going to extract some data from that XML. First, we'll just grab the name. This is a recap, but let's show it quickly.

Figure 2: Extracting an element from the XML using the XMLQUERY clause shows the data as an XML element.

The XMLQUERY function returns the data, but as you can see, it returns it with the data enclosed within the tag. As we'll see in a moment, that won't work when trying to integrate with our relational data. You can change the data from XML to relational by casting it, but you can't use the standard CAST function; instead, you have to use the special XMLCAST function, which is specifically designed to convert between relational and XML data. With XMLCAST, the data looks more familiar:

Figure 3: XMLCAST converts the result of the XMLQUERY function to a traditional relational value.

Now it looks more like a traditional query, and at this point you can actually use your SQL knowledge to start executing true data operations on your XML data. How do you know when you need to convert? Well, the easy answer is that you always need to convert the data, but in case you're not quite sure, just look for an error like the following:

Figure 4: When comparing XML and non-XML data, you'll see a compatibility error like this one.

The SQL engine can't reconcile the two data types, so it throws an error telling you that the types are incompatible. You might be tempted to think it's because I didn't enclose the name in the tage (<name> and </name>), but trust me, attempting that will return the same error. And really, do you want to have to compare things by formatting beginning and ending XML tags? I sure don't. But the good news is that you don't have to do that; the XMLCAST function will strip the tag information and return the data however you want to see it.

Figure 5: The XMLCAST function not only removes the tag information but also makes the data compatible with traditional relational data.

Now that's more like it! We can not only see XML elements without the tag baggage, but also compare to that data. In this case, we're getting the ID field for only those records that have Kathy Smith as the name. Interestingly, there are two records for Kathy Smith, which means the result set returns two rows. We could then use that result set as a Common Table Expression (using WITH T1 AS…) and then use that to select records from other tables. That's one way to join to XML data, although we'll see a more direct method in a moment. First, let's finish up our XML to relational exercise. The last thing we can do is convert the XML data to something other than a character value. Remember that the only other field in the CUSTOMER file is the ID field. Well, that same ID actually is embedded as an attribute in the XML data. We can use our newfound XMLCAST expertise to extract that attribute. Let's see what that would look like:

Figure 6: Here, we can see the relational ID field from the data record compared to the embedded attribute (Cid).

Here's a nice query. It seems very simple, but in reality it's quite sophisticated: the SQL engine is digging into the data, extracting the attribute from the XML, and then converting that to a BIGINT. We see that converted value side by side with the relational field, and we can use that for a quick visual check on the data. We could also do a programmatical check and extract exceptions for intervention. We're not limited in our data types; we could just as easily convert the XML to a decimal number, something we'd definitely want to do for things like currency amounts and bill-of-material quantities. One caveat: if you have any non-numeric data within your XML tags, the conversion will throw an error and the entire transaction will fail. There are definitely pros and cons to using XMLCAST to convert to numeric values; the most important prerequisite is that your XML data is very clean.

A Last Look at What We Can Do With XMLCAST

These articles are taking baby steps into pureXML. One reason for that is because the technology is really very large and you just have to bite off small pieces. The other is because, frankly, some of it isn't entirely intuitive; it's taken me quite a bit of trial and error to get things to work in the way I would have expected. A perfect example of that counter-intuitive side of pureXML is the syntax required to join data. Since you can quite easily create a selection expression using XMLCAST, you might expect a JOIN to be just as easy, using that same comparison operation within the ON clause. Sadly, that's not the case. Here's what happens:

Figure 7: XMLCAST cannot be used within the ON clause of a JOIN.

This really threw me for a loop. It might in fact make one think that relational and XML data might not work together after all. But then I decided to try something a little old school: I went to the old fashioned WHERE syntax for a JOIN.

Figure 8: By using the old-school JOIN syntax, I am able to use the next-generation XML functionality. Who knew?

And there you have it! We're where we expected to be, able to mix and match data. It's just a little odd that the only way to use the newfangled XMLCAST is through the rather retro WHERE syntax for the JOIN. But the point is that it works and we can now successfully join our two worlds of data.

We'll continue this exploration more in subsequent articles, but for now this should give you some more to play with. Enjoy!