Building and analyzing trends in a database I am quite new to working with databases but have spent a few hours reading about XML and trying to understand the use of CML for building databases and find myself completely at a loss. 
Here is what I hope to do : 
1. I have a few hundred xml files storing the service and operation history of a instrument with the following format : 

&lt;history title="History Report"&gt;
   &lt;infos&gt;
      &lt;record date="01/01/2000" time="24:00"&gt;
         &lt;item&gt;
         &lt;name&gt;Name&lt;/name&gt;
         &lt;comment&gt;SYS1&lt;/name&gt;
         &lt;/item&gt;
         &lt;item&gt;
         &lt;name&gt;Catalog No&lt;/name&gt;
         &lt;comment&gt;ABCD&lt;/name&gt;
         &lt;/item&gt;
         .
         .
         .
         &lt;item&gt;
         &lt;name&gt;Country&lt;/name&gt;
         &lt;comment&gt;XYZ&lt;/name&gt;
         &lt;/item&gt;
      &lt;/record&gt;
   &lt;/infos&gt;
   &lt;operation&gt;
      &lt;record date="01/01/2000" time="24:00"&gt;
         &lt;item&gt;
         ....
         &lt;/item&gt;
         .
         .
         .
         &lt;item&gt;
         ....
         &lt;/item&gt;
      &lt;/record&gt;
   &lt;/operation&gt;
....
&lt;/history&gt;



I want to build a database with the data from these xml files and query things like : 
Q) How many of Cat No. 123 went to country ABCD 


We have traditionally used excel for this kind of work, which I realize is a not a good idea in the long term. I am thus trying to figure out how to directly parse and analyze the xml files.

I am completely at a loss as to how to get started on this. Any help would be appreciated.
Although many DBMS support XML storage and processing it is not the native format. To gain the greatest benefit from a move to a DB you must pull the data from their current files and store then in tables. This is known as an Extract, Transform, Load (or ETL) job. There are specific ETL tools available. The major vendors have them, and independent and open-source tools exist. There is, of course, an overhead to learning these tools and writing the ETL jobs. They are most useful when there is an on-going need to process new files into the future.

For one-off or ad hoc tasks the native capabilities within the DBMS itself often suffice. My suggestion is you create a staging table with a single column of type XML (if your chosen technology supports it). Load the file directly into here without any processing. Then use the DBMS's native XML tools to shred the XML and populate the "real" tables.

Next comes the question of what the destination tables should look like. Relational databases work best when table design is normalised. Simply reproducing to record / item structure will not suffice. It will be a nightmare to query and performance will be awful.

Table design and normalisation is part science and part craft. It depends on the inherent structure of the data and also the meaning users impart to the data. If all your records have the same number of items, and all the items have the same meaning across records you may be OK with a single table. There will be one column per item (properly named, NOT item1, item2 ...) and a row per record. If the current Excel sheet has a very regular, ordered, no-nonsense, one-value-per-cell layout you could start by reproducing that then refining as experience and confidence grows.