Databases Reference
In-Depth Information
The approach, of course, lies somewhere in the middle, and that is to partition your
data model into a set of reusable modules, where each module is based on a logical
domain. For example, in oBay, we have defined the following schemas:
Account.xsd
: Defines every business object specific to a financial account,
that is, a record of all debit and credit activities related to a specific user
Auction.xsd
: Defines all business objects specific to an auction
Order.xsd
: Defines all business objects specific to order fulfillment, that is,
from the placement of an order through to its final shipment and delivery
User.xsd
: Defines all business objects specific to a user
Common.xsd
: This schema is used to define common objects, such as name,
address, credit card, which are used by multiple domains, but have no
obvious owner
•
•
•
•
•
Once we have partitioned our data model, we need to decide on our strategy for
namespaces. There are a number of potential approaches, which we cover below.
Single namespace
With this approach, we have a single target namespace which is used by all schema
definitions. We typically have a single master document which uses the
xsd:
include
element to combine the various schema documents into a single schema.
This approach is illustrated below, where we have a master "oBay" schema that
includes all of our other schemas:
The advantage of this approach is that it keeps it simple, as we only have a single
namespace and corresponding prefix to worry about.
