Introduction

A relational database, as we have seen already, is tightly coupled with real world entity and data. Each tables / relations should be mapped with each other. If there are slight changes in the data or mapping, whole database will give incorrect results. In relational database, we need to take care of each and every point which is very difficult to any normal user. It requires a well educated developer to handle the data in RDBMS.

These complexities of RDBMS lead developers to think about simplest way of storing the data, which should be managed by any novice users. Hence they came up with a concept called document database. Here each data / record is stored in a document – any normal text file. It will not have any mappings or any specific relationship among the data, records or documents. User would easily trace the document by its name and will be able to fetch the data / records that they are looking for.

Document Database

Like we said above, document database is a simple text like document where the user informations will be stored. It will be a simple file where data values are simply typed in. for example, consider the address file below :

Rose Mathew,
APT 201, Lakeside terrace 1232
Lakeside Village Drive,
Clinton Township, MI, US.

William Paul,
APT 112, Shelby Apartments 2512
Shelby Township, MI, US.

This is a simple document with addresses. Any novice user would know that this document contains addresses by looking at it. He would not need any additional information or query to fetch the record or to know about this document.

But here the format of address is not the same. There could be some post box number or postal pins too. But it is not predictable just by seeing the document above. In addition, we cannot to tell what each line is for. Even though, we are familiar with addresses, and if we want to search for say street or PIN in the address, then it is not the easy task. Here, each street, state and Country is in the same line. If we have to search for any particular state or country, then it is also not a easy task. All of these require some labeling, to each line and the data that we are adding to the Document. It is always better if we have some tags for each line, so that we can easily identify what it is for. Hence above document database is modified to contain some tags for easier identification and retrieval. Thus document database gets the format of XML. Above document will now change as shown below :

<Contact>
<Name> Rose Mathew </Name>
<ApartmentNum>APT 201 </ ApartmentNum>
<AppName> Lakeside terrace 1232 </AppName>
<Street>Lakeside Village Drive </Street>
<Town> Clinton Township </Town>
<State> MI </State>
<Country> US </Country>
</Contact>

<Contact>
<Name> William Paul </Name>
 <ApartmentNum> APT 112</ ApartmentNum>
<AppName> Shelby Apartments 2512</AppName>
<Town> Shelby Township </Town>
<State> MI </State>
<Country> US </Country>
</Contact>

Now the data in the document looks meaningful. The user when looks for the data, he will clearly know which line to look for. He will not confuse with the details given in the DDB.

This is how a database is created without any relationship and SQLs. Thus this type of DDB is called NoSQL database. Above is the basic introduction on how document Database is represented and used. But when the user actually starts using documents as their repositories, they found some better way of representing the data in the document. This is how XML database is evolved.