If we think about executing a query against a database, we may only require a subset of the information that it holds. For example, an e-commerce site stores data with relationships that model everything the customer has bought in the past, as well as current orders being processed. If we were writing a CRM application, we would not necessarily need to retrieve all of their past purchases - only those that had recently been placed.

In short, the scope of the document that we are creating is driven by business requirements - what the data is going to be used for, and how it is going to be used - and these business requirements may vary widely.

For example, our business requirement could be to transmit information to our accounting office about summarizing the monthly invoice totals, as well as a customer-by-customer breakdown so that billing may be performed. In this case, we may want to send only a certain subset of the information to our accounting office (the shaded tables):

An alternative business requirement might be to transmit an XML copy of an invoice to a customer each time a new invoice is submitted, in which case the subset of the information we would be transmitting might look like this:

Additionally, we might want to control the specific columns that are transmitted. For example, say our customer wanted to query a product they had ordered; they have their invoice number to identify their purchase, but they aren't necessarily going to care about the invoice tracking number that our application uses internally. The extra number may in fact confuse them more.

By identifying the specific set of tables and columns that are going to be transmitted, we can start to get a feel for how the XML document needs to be laid out. If we happen to have access to a logical data diagram of the database, such as an ErWIN model, it can also be very helpful when constructing our XML.

Rule 1: Choose the Data to Include.

Based on the business requirement the XML document will be fulfilling, decide which tables and columns from our relational database will need to be included in our documents.

For the purposes of our example, we'll assume that all the information in our structure is relevant to the process (with the exception of the system-generated keys, which we can discard).