As you know, relational databases represent data in terms of tables, rows, and columns. Some XML documents, such as our product catalog document, map fairly cleanly onto a relational model. Example 24-1 shows catalog2.xml, a slightly simplified version of the product catalog document used throughout this book.

<catalog>
  <product dept="WMN">
    <number>557</number>
    <name>Fleece Pullover</name>
  </product>
  <product dept="ACC">
    <number>563</number>
    <name>Floppy Sun Hat</name>
  </product>
  <product dept="ACC">
    <number>443</number>
    <name>Deluxe Travel Bag</name>
  </product>
  <product dept="MEN">
    <number>784</number>
    <name>Cotton Dress Shirt</name>
    <desc>Our favorite shirt!</desc>
  </product>
</catalog>

Because the product catalog document is relatively uniform and does not contain any repeating relationships between objects, the product catalog can be represented as a single relational table, shown in Table 24-1. Each product is a row, and each possible property of the product is a column.

Some of the products do not have descriptions, which means that nulls (or zero-length strings) are stored in the desc column for these rows. XML does not have a direct equivalent of null values in the relational model. In XML, a "missing" value could be represented as an element or attribute that is simply omitted, as in our example, where the desc element does not appear when it does not apply. It could also be represented as an empty element (<desc></desc> or <desc/>). Yet another representation uses the XML Schema concept of "nilled" elements, as in <desc xsi:nil="true"/>.

Some XML documents encompass multiple "entities" with repeating relationships between them. The order document (order.xml) is such a document, since it describes a hierarchical relationship between an order and the items it contains. There are properties of the order itself, as well as properties of each item, so each needs to be represented by a table (see Tables 24-2 and 24-3).