Home > Articles > Web Services > XML

  • Print
  • + Share This
This chapter is from the book



As of DB2 V9, XML data can be stored natively in DB2 databases. This implementation is known as pureXML. With pureXML, you can treat XML as another data type that can be managed by DB2. This means that you can CREATE tables with XML columns, ALTER existing tables to add XML columns, INSERT XML data (optionally validated against XML schemas), CREATE indexes on XML data, search XML data, and generally manipulate XML as part of your DB2 databases.

DB2’s support for XML with pureXML is novel in that the XML data is integrated into the DB2 database system enabling access and management of the XML using DB2 functions and capabilities.

Creating a Table with an XML Column

Similar to LOB data, XML data is physically stored in separate table spaces from the base tables that contain the XML columns. But unlike with LOBs, the storage structures are transparent to the user. You do not need to define and manage the storage mechanisms used by DB2 for XML data.

For example, the following SQL creates a new table with an XML column, which can be used to store the customer XML example shown previously:


When a table is defined with an XML column, DB2 generates a hidden column in the base table called a DOCID, which contains a unique identifier for the XML column. There is a single DOCID column even if the table contains more than one XML column. The DOCID column is purely internal; it does not show up in a SELECT *, for example. In addition, DB2 automatically creates a document ID index for the XML column, too.

The XML data is not stored directly in the XML column. Instead, a separate internal table in a separate table space is created for each XML column in the base table. A single XML document may be physically split across multiple rows in the XML table, but it logically still belongs to a single row in the base table, which is the table created with the XML column definition. The internal XML table is composed of three columns:


The DOCID column is used as a pointer between the base table and the XML table. In any given row, the MIN_NODEID column stores the lowest node stored in the XMLDATA column of the row. This information optimizes DB2’s capability to process XML documents. The XMLDATA column contains a region of an XML document formatted as a parsed tree. The internal table is clustered by DOCID and MIN_NODEID.

The internal XML table always has a 16-KB page size. This is so regardless of the page size of the base table containing the XML column. The table space used by the internal XML table is a Universal table space. If the base table resides in a partitioned table space, the XML table space will be range-partitioned; if not, the XML table space will be partition-by-growth.

The TBSBPXML DSNZPARM system parameter is available to specify the default buffer pool for XML table spaces. The default is BP16K0; however, because the DB2 Catalog uses this buffer pool, it is a good idea to use different 16-K buffer pools for your XML table spaces.

XML Document Trees

DB2’s pureXML implementation follows the XPath 2.0 and the XQuery 1.0 data model, which provides an abstract representation of XML documents. By using the data model, all permissible values of expressions in XPath can be defined, including values used during intermediate calculations. The pureXML data model is described in terms of sequences and items, atomic values, and nodes.

The primary difference between XPath and XQuery is that XPath is a subset of XQuery for addressing parts of a document. XPath cannot be used to construct new XML documents, nor does it support complex join, grouping, and ordering.

XML is hierarchic in nature and, as such, every XML document can be represented as a node tree. When XML data is queried or modified, the hierarchical structure of the document must be traversed. To assure that XML data is accessed as efficiently as possible, DB2 physically stores XML documents in hierarchical format, as trees of nodes with parent-child relationships between the nodes.

To better understand this concept of hierarchic trees, work through an example. To start, examine the following sample XML:

   <addr country="US">
       <street>100 Easy St</street>
   <phone type="work">412-555-1000</phone>
   <phone type="mobile">972-555-8174</phone>

This basic XML document contains customer data. At the root of the tree is the root element, customer. There are various direct children elements as well: first_name, last_name, addr, and two occurrences of phone.

The element addr is composed of multiple elements as well: street, city, state, and zip_code. And addr also has an attribute for the country. The element phone has an attribute, type, associated with it, as well.

Figure 10.1 illustrates a representation of this XML document as a hierarchical tree. You can build these trees by parsing an XML document using an XML parser.

Figure 10.1

Figure 10.1. An XML document tree.

XML data is stored in DB2 as an XML document tree. When XML is inserted or loaded into an XML column, DB2 parses the XML document to produce the hierarchical format, and that is what is stored in the XML table space. If one or more columns are of type XML, and you select the entire XML column, DB2 retrieves the XML document tree and converts it back into the text XML document. This process is called serialization.

When the XML data is larger than a page, the document tree is divided into groups of nodes; each group is usually a subtree of nodes. The divided data is stored in the XMLDATA column of the internal XML table. Nodes are grouped bottom up, up to the largest row size of a page. One document can be physically stored across many rows and pages.

DB2 stores XML data as an XML document tree to optimize performance when accessing XML data. The document tree is further optimized by replacing tag names with 4-byte identifiers. So the internal storage does not look exactly like the tree shown in Figure 10.1. Tag names are mapped to stringIDs and stored in the DB2 Catalog in the table SYSIBM.SYSXMLSTRINGS. DB2 caches the mapping table to optimize performance. Furthermore, XML query evaluation and traversal of XML documents can operate on integers, which is typically much faster than operating on strings. There will be only one 4-byte identifier for a particular string, even if that string (that is, “name”) is used in many different XML columns.

The exact shape of the document tree can vary from document to document; it depends upon the content of each XML document. The document tree is not built or predefined based on the XML Schema. The actual XML data is stored as VARBINARY data, composed of the XML document tree (or a sequence of subtrees) with context path.

Serializing and Parsing XML Data

An XML value can be transformed into a textual XML value that represents the XML document by using the XMLSERIALIZE function or by retrieving the value into an application variable of an XML, string, or binary data type.

The inverse can also be achieved. The textual XML document can be turned into the XML value using the XMLPARSE function or by storing a value from a string, binary, or XML data type to an XML column.

Altering a Table to Contain XML Data

Modifying a table to add an XML column is also a simple endeavor. All that is necessary is a simple ALTER, such as the following:


This statement adds the JOBHISTORY column as XML to the EMP table. Of course, when an XML column is added to an existing table, DB2 creates the same internal table and index to support the XML data as it would for a new table.

Schema Validation

As you have seen, XML is flexible. XML has no rigorously enforced schema applied when data is added, such as with a DBMS such as DB2. But you can validate XML against a schema with a process known as XML schema validation. XML schema validation can determine whether the structure, content, and data types of an XML document are valid according to an XML schema. In addition, XML schema validation removes whitespace that can be ignored from the XML document being validated.

You can validate an XML document in DB2 in two ways:

  • Automatically, by specifying an XML type modifier in the XML column definition of the CREATE or ALTER TABLE statement. When a column has an XML type modifier, DB2 implicitly validates documents that are inserted into the column or documents in the column that are updated.
  • Manually, by executing the DSN_XMLVALIDATE built-in function when you INSERT a document into an XML column or UPDATE a document in an XML column.

If you perform XML schema validation using DB2, you need to set up an XML Schema Repository. A DB2 for z/OS XML schema repository (XSR) is a set of DB2 tables where you can store XML schemas. XSR requires additional software: WLM, z/OS XML System Services, Java 2 Technology Edition 31 bit (V5 or later), and IBM Data Server Driver for JDBC and SQLJ.

Refer to the IBM manual, pureXML Guide (SC19-2981) for additional information on using an XML Schema Repository, as well as additional information on using type modifiers.

XML Namespaces

XML namespaces are a W3C XML standard for providing uniquely named elements and attributes in an XML document. XML documents may contain elements and attributes that have the same name but belong to different domains. A namespace can be used to remove the ambiguity when referencing such elements and attributes.

Namespaces are supported by all DB2 pureXML features including SQL/XML, XML indexes, and XML Schema validation.

A namespace must be declared with a prefix assigned to a Universal Resource Identifier (URI) before it can be used. Now augment your example XML with a namespace:

<c:customer xmlns:c="http://ddgsample.org">
   <c:addr country="US">
       <c:street>100 Easy St</c:street>
   <c:phone type="work">412-555-1000</c:phone>
   <c:phone type="mobile">972-555-8174</c:phone>

The attribute xmlns:c declares that c is a namespace prefix bound to the URI http://ddgsample.org. The prefix c can be used for the customer element and all other elements or attributes in the document that are descendants of customer.

Not every node in a document must belong to the same namespace. Furthermore, an XML document can contain multiple namespaces. Specify namespace declarations as needed within your XML documents according to your needs for accessing elements of the XML document.

If all elements in a document belong to the same namespace, you can declare a default namespace and avoid the use of prefixes:

<customer xmlns="http://ddgsample.org">
   <addr country="US">
        <street>100 Easy St</street>
   <phone type="work">412-555-1000</phone>
   <phone type="mobile">972-555-8174</phone>

In this case, all elements belong to the declared http://ddgsample.org namespace.

Indexing XML Data

You can build indexes on data stored in XML columns to improve the efficiency of queries against XML documents. Indexes on XML data differ from DB2 indexes on relational data. A typical DB2 index lists a column, or series of columns, and the index is built upon those columns. An XML index is based upon a part of the data in the XML column, not the entire column.

A typical DB2 index has one entry for each row in the table, even if the value is NULL, whereas an XML index does not have an entry for a row if the XML document in that row does not contain that element.

An XML index uses an XML pattern expression to index paths and values in XML documents stored within a single XML column. The index entries in XML indexes provide access to nodes within the XML document. Because multiple parts of a XML document can satisfy an XML pattern, DB2 might generate multiple index keys when it inserts values for a single document into the index.

XML indexes are built using the CREATE INDEX statement (and dropped using DROP INDEX). Instead of listing columns, the GENERATE KEY USING XMLPATTERN clause is used to indicate what portion of the XML document you want to index:

GENERATE KEY USING XMLPATTERN '/customerinfo/custname/last_name'

The GENERATE KEY USING XMLPATTERN clause provides information about what you want to index. This clause is called an XML index specification. The XML index specification contains an XML pattern clause. The XML pattern clause in this example indicates that you want to index the values of the last_name attribute of each customer element. The index entries are to be stored as VARCHAR(20).

Every XML pattern expression specified in index CREATE statement must be associated with a data type. The only supported data types are VARCHAR, DECFLOAT, DATE, and TIMESTAMP.


Only one index specification clause is allowed in each CREATE INDEX statement, but it is permissible to create multiple XML indexes on each XML column.

To identify the portion of the XML to be indexed, you specify an XML pattern to identify a set of nodes in the XML document. This pattern expression is similar to an XPath expression. (But only a subset of the XPath language is supported.)

Namespace Declarations in XML Indexes

In the XMLPATTERN clause of the CREATE INDEX statement, you can specify an optional namespace declaration that maps a URI to a namespace prefix. Then you can use the namespace prefix when you refer to element and attribute names in the XML pattern expression.

For example, consider the following index creation statement:

GENERATE KEY USING XMLPATTERN 'declare namespace s="http://ddgsample.org/";
/s:customer/s:phone/@s:type' AS SQL VARCHAR(12)

The namespace declaration maps the namespace URI http://ddgsample.org to the character s. It can then be used to qualify all elements and attributes with that namespace prefix.

XML Indexes and UNIQUE

Specifying UNIQUE in an XML index definition is a little bit different than in traditional, relational indexes. For a traditional index, the UNIQUE keyword enforces uniqueness across all rows in the table. For XML indexes, the UNIQUE keyword enforces uniqueness across all documents in an XML column. This means the index can ensure uniqueness. not only across all rows in the table, but also within a single document within a row.

For an XML index, DB2 enforces uniqueness for the following:

  • Data type of the index.
  • XML path to a node.
  • Value of the node after the XML value has been cast to the SQL data type specified for the index.

Querying XML Data

Of course, after you create tables with XML data in them, you want to access that data in your DB2 applications. Doing so requires a basic understanding of XPath.


XPath is a programming language designed by the World Wide Web Consortium (W3C) for querying and modifying XML data. DB2 supports a subset of the language constructs in the XPath 2.0 specification. In XPath, there are seven kinds of nodes: element, attribute, text, namespace, processing-instruction, comment, and document nodes.

XML documents are treated as trees of nodes. The top element of the tree is called the root element. Now look at some sample XML again:

   <addr country="US">
       <street>100 Easy St</street>
   <phone type="work">412-555-1000</phone>
   <phone type="mobile">972-555-8174</phone>

Examples of nodes in this XML document include <customer>, which is the root element node, <city>Pittsburgh</city>, which is an element node, and Type="work", which is an attribute node.

There is a relationship among the nodes that you need to understand for XML processing. Each element and attribute has one parent. In the example, XML the addr element is the parent of street, city, state, and zip_code. Element nodes can have zero, one, or more children. Nodes that have the same parent are siblings. The street, city, state, and zip_code nodes are siblings of each other, as well as children of addr.

Descendants are any children of a node as well as the children’s children, and so on. So in your example, the descendants of customer include custname, first_name, last_name, addr, street, city, state, zip_code, and phone.

XPath uses path expressions to select nodes or node-sets in an XML document. The node is selected by following a path or steps. If you are familiar with Windows® or UNIX® file structure, an XPath specification will look familiar to you. Table 10.1 outlines some useful path expressions.

Table 10.1. XPath Expressions




Selects all child nodes of the named node


Selects from the root node


Selects nodes in the document from the current node that match the selection no matter where they are


Selects the current node


Selects the parent of the current node


Selects attributes

To select the last_name element of the customer XML document using XPath you would specify the following:


Or to select all attributes that are named phone using XPath, you can specify the following:


Use DB2 XPath in the following contexts:

  • As an argument to the XMLQUERY built-in function, which extracts data from an XML column.
  • As an argument to the XMLEXISTS predicate, which is used for evaluation of data in an XML column.
  • In an XML index, to determine the nodes in an XML document to index. (Only a subset of XPath, called an XML pattern, is valid in this context.)

The XMLQUERY Function

You can use the XMLQUERY function to execute an XPath expression from within SQL. You can pass variables to the XPath expression specified in XMLQUERY. XMLQUERY returns an XML value, which is an XML sequence. This sequence can be empty or can contain one or more items.

When you execute XPath expressions from within an XMLQUERY function, you can allow XML data to participate in SQL queries. Furthermore, you can retrieve parts of XML documents, instead of the entire XML document. This gives you the ability to operate on both relational and XML data in the same SQL statement. And you can apply additional SQL to the returned XML values after using XMLCAST to cast the results to a non-XML type.

Consider the following query, which returns the phone number information extracted from the XML for each customer in the CUST table:

   XMLQUERY ('declare default element namespace "http://ddgsample.org";
   /customer/phone' passing XMLCUST)

You can use the XMLEXISTS predicate to restrict the result set based on values in XML columns. To do so, an XPath expression is specified to the XMLEXISTS predicate. If the XPath expression returns an empty sequence, the value of the XMLEXISTS predicate is false. Otherwise, XMLEXISTS returns true and the row is returned.

For example, consider this SQL statement:

WHERE  XMLEXISTS ('declare default element namespace "http://ddgsample.org";
  //addr[city="Pittsburgh"]' passing XMLCUST)
AND XMLEXISTS ('declare default element namespace "http://ddgsample.org";
/customer[last_name="Mullins"]' passing XMLCUST)

This matches your sample XML document in which customer city is Pittsburgh and last_name is Mullins, so that row will be returned (as would any other where both of these conditions are true).

The XMLTABLE() Function

The XMLTABLE() function though can be used to produce XML query results comparable to XQuery. The following example uses the XMLTABLE() function to query your sample table and XML document, returning the city, street, state, and zip_code as columns in a result table:

       XMLTABLE (XMLNAMESPACES(DEFAULT 'http://ddgsample.org'),
         PASSING XMLCUST as "x"
         ZIP_CODE INT         PATH '@zip_code',
         STREET   VARCHAR(50) PATH 'street',
         CITY     VARCHAR(30) PATH 'city',
         STATE    VARCHAR(2)  PATH 'state') AS X

Recall that the XML column in the CUST table is named XMLCUST, therefore you code PASSING XMLCUST.

To enable this query to use an XML index, can add a predicate using XMLEXISTS, for example:

WHERE XMLEXISTS('$x/customer/addr[@zip=15215]'PASSING XMLCUST AS "x")

The XMLTABLE() function can be used when converting XML data into a relational result set. It can be beneficial to use XMLTABLE() in views where the SQL referencing the view does not have to code XPath expressions. The optimizer can still use XML indexes when view is referenced.

Access Methods

DB2 supports several access methods for XML data. The basic access method is the DocScan, which traverses XML data and evaluates XPath expressions using an IBM-patented technique called QuickXScan (see Note). There is no access type indicator for DocScan in the PLAN_TABLE because it is part of a scan if there is a predicate on an XML column involved.

XML indexes are used only for the XMLEXISTS predicate and XMLTABLE function evaluation. There are three access types for XML index-based access. Similar to RID list access, ANDing, and ORing, they include the following:

  • DocID list access (DX)
  • DocID list ANDing (DI for DocID list Intersection)
  • DocID list ORing (DU for DocID list Union)

Inserting XML Data

Inserting XML data is as simple as inserting any other type of data. For example, assume that you want to use the CUSTOMER table described earlier in this chapter to INSERT an XML document. The following SQL achieves this goal:

VALUES (1000, 'Y',
    <addr country="US">
        <street>100 Easy St</street>
    <phone type="work">412-555-1000</phone>
   <phone type="mobile">972-555-8174</phone>

This SQL statement inserts a new customer into the CUSTOMER table, giving it a CUSTNO of 1000 and a STATUS of Y. The XML data is inserted into the XML column defined as XMLCUST.

Deleting XML Data

You can use the SQL DELETE statement to delete rows that contain XML documents. Nothing special is required, just code the DELETE as normal including any WHERE clause that you want. When the row is deleted, the XML data for that row is deleted, too.

Of course, you might want to DELETE based upon values in the XML document. You can do this using XPath expressions within XMLEXISTS, for example, to DELETE rows from CUST table for which the value of the city element is Pittsburgh (in the XMLCUST column):

WHERE XMLEXISTS ('declare default element namespace "http://ddgsample.org";
//addr[city="Pittsburgh"]' passing XMLCUST)

Updating XML Data

You can also update XML data, either the entire XML document, or a portion of the XML document.

Updating an Entire XML Document

To update an entire XML document in an XML column, supply the XML data to the UPDATE statement, being sure to specify a WHERE clause for the rows to be updated. The input to the XML column must be a well-formed XML document (as defined in the XML 1.0 specification).

Updating a Portion of an XML Document


You can also use the UPDATE statement with the XMLMODIFY function to update a portion of an XML document in an XML column. The XMLMODIFY function specifies a basic updating expression that you can use to insert nodes, delete nodes, replace nodes, or replace the values of a node in XML documents stored in XML columns.

The following UPDATE statement modifies the document for CUSTNO 100 changing the value of the city element to “Houston”:

SET XMLCUST=XMLMODIFY('replace value of node/customer/addr/city with "Houston" ')

The following update expressions are supported in the XMLMODIFY function:

  • delete expressions: To remove elements or attributes from a document
  • insert expressions: To add elements or attributes to a document
  • replace value of node expressions: To change the value of an element or attribute
  • replace node expressions: To replace an existing element or attribute with a different one
  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020