Building and analyzing trends in a database
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.