An NXD often contains and stores more than one XML document like collections of XML fragments. An NXD can contain XML documents from different types where the documents are about different topics containing independent data. For example, one collection consists of the data of a firm's customers while the other collection contains demographic data of the countries from the Earth. In addition, the XML fragments' structure in each collection can differ from the others. Every simple fragment in a collection can have different structure from the other fragment in the given collection. This result structural and scheme independent XML data.

The collections, if validation required for the XML data, can have poses a relation to schemes. Scheme independent XML makes development spectacularly flexible, faster and easier. However, the flexibility comes with low data integrity and with the risk of faults among the data inside the database. In reality, there are uncountable reasons why we should transform our collection of XML documents into an NXD for achieving better performance and storing methods.

Nevertheless, the misunderstanding and misinterpretation of this flexibility can cause problems. The repetition of too many data, too much or not enough structural complexity can lead to surprisingly many faults. The list of potential pitfalls is as long as the possible different variations of a topic made by an XML-like tool's flexibility. We can represent this through a simple example where we would like to describe a region:

<?xml version="1.0"?>
<database name="Africa">
	<collections>
		<collection name="Countries">
		</collection>
	</collections>
</database>

The example above did not contains any data but it consists more collections where every collection stands for a state. In this example the states belong to the African region. We can add new regions to achieve a multilevel database.

<?xml version="1.0"?>
<databases>
	<database name="Africa">
		<collections>
			<collection name="Countries">
			</collection>
		</collections>
	</database>
	<database name="Europe">
		<collections>
			<collection name="Countries">
			</collection>
		</collections>
	</database>
</databases>

In spite of this, we can go back to the way of getting more collection inside the database:

<?xml version="1.0"?>
<database>
	<collections>
		<collection name="Regions">
			<region name="Africa">
				<population>789548670</population>
			</region>
			<region name="Europe">
				<population>488674441</population>
			</region>
		</collection>
		<collection name="Countries">
			<country name="Finland" region="Europe">
				<population>5231372</population>
			</country>
			<country name="Germany" region="Europe">
				<population>82422299</population>
			</country>
		</collection>
	</collections>
</database>

Collections inside of a collection can also be arranged into real hierarchies just like the countries into the appropriate regions:

<?xml version="1.0"?>
<database>
	<collections>
		<collection name="Regions">
			<region name="Africa">
				<population>789548670</population>
			</region>
			<region name="Europe">
				<population>488674441</population>
				<country name="Finland" region="Europe">
					<population>5231372</population>
				</country>
				<country name="Germany" region="Europe">
					<population>82422299</population>
				</country>
			</region>
		</collection>
	</collections>
</database>

When continuing this example we can see how limitless the options for further evolution in these schema-free XML databases. However, they are carrying all the aforementioned risks which can easily turn into problems and faults. Of course, if we assign a scheme to an XML document we loose this flexibility but the other hand, the database system gain the power to enforce structural constraints.

We can already be familiar with the techniques of indexing related to relational database systems, where one of our aims is to get the data with the least I/O processes. In case of relational tables the most commonly used indexing methods are binary trees, hash algorithms and bitmaps. When we talk about indexing, there is one important thing that we have to emphasize: there is a sequence in it. That is, when we are reading an index, we are reading the data in the sequence as the index has created them, independent from the order that can be found in the table or in the XML document. However XML document already contain an inner sequence, which is based on the XML structure, so the arranged index is not necessarily an advantage in case of XML data bases. XML data bases have different indexing methods. Probably every native XML data base applies different ways of indexing in their actual implementation.

The most widely used indexing method in case of XML documents in relational databases, even in case of XML data type, is separating those elements that need indexing. This way the index will contain a simple field about every record in the table. This single field contains a name about every region. Furthermore, the index will contain another pointer/indicator, which makes the linking of index and the table (or XML document) possible; it a physical address on I/O level. In other words, the database has to have a physical address about every (indexed) element in the XML document. This way the index contains the address of this pointer. The result is the following: when it finds a region in the index, the indicator related to the index will be given to a function, which finds the record in the table, or in an XML document on the basis of the hard disk address of the entrance record. The hard disk addresses get assigned to the table or the elements of the XML document when the whole pile of data or the index are created. The process and the steps of the process fully depend on the software used to reach the XML database, or which makes a simple XML document or a set of XML documents as one collection (These collections are obviously stored as XML).

Some questions may rise at this point, such as:

Why don’t we store XML documents in XML data type, if indexing the XML data type is problematic, and it may be subordinated to the indexing of the relational data base?

or:

Why don’t we simple store data in relational tables and convert them to XML, if needed?

At first sight, we should examine the second question at first. Converting is not necessary, if the storage is in XML format. What’s more, we will have access to such useful XML tools like XPath and XQuery. Answering the first question: index is index. Some databases have more friendly indexing techniques than others. There is no reason, why XML indexing would be less effective than any other indexing, no matter what kind of relational database we talk about. Naturally, XML data can be stored in relational table. It’s the matter of choice. Both ways have their own advantages and disadvantages. In general we can say, that the bigger the database, the more sensible it is to store data in relational table – and not the XML stored in an XML data type. Unless we use XML data type collections. Keeping these in mind, we know 4 ways of indexing:

XML documents contain data, metadata and some kind of semantics in their inner hierarchical structure. Document centred documents are better for human application. However, they can be data-centred as well. These are more generic, and mainly used for processing by script languages.

Document-centred XML

A document-centred XML, which is also good for human consumption, is hardly interpretable for a computer, if it is possible at all. The document-centred XML is a document, which is normally handwriting – as a Word document, PDF file, or something similar to these notes. These kind of XML documents are usually stored as wholes and they are normally not understandable by programming methods, or by an XML element's content. Sometimes these documents are indexed for index searching, like the library of technical papers. Contrarily, there are some databases that contain technical data, which mixes data and document centrality. For example in the database of a library, which stores technical data of several years of the past, it is worth to categorize data according to authors, subject, time of publishing, or other kind of descriptive information. The content of these documents could be indexed, so that it would give general information about the subject of the given text.

A special type of document-centred native XML is called Content Management System (CMS). Content management systems permit some kind of control and management through XML data written by human beings, which are stored as XML types in a native XML database.

Data-centred XML

A data-centred XML document uses XML data in their simplest way for data transmission among computers. In reality, XML often contains the mixture of data-centric and document-centric features. The part, which has been made by humans and which can be interpreted for human beings belongs to the document-centred features. Something, that is generic, and available for a programme as it is reproducible, belongs to the data-centric part.

Maybe the best examples for data-centric documents can be found on websites, like Amazon or Ebay. These pages contain a mass of information, with the widest range of diversity. For example a book on the Amazon website, or better say every feature of it, such as ISBN number, author, or other kind of data are data-centric. On the other hand, many books on Amazon are available in PDF format. PDF files are document-centric, specific to a given book, and can be programmed correlated to the PDF document, in contrast with the content of the PDF.

It is important to go through the different aspect of the usage of native XML databases