Noob database design problem This may be a bit of a general problem to post but I could really do with some guidance and this seems like the best place.

The problem stems from the strange situation I find myself in at work; I am a data analyst in a medium sized company. We have a multitude of different systems which our IT department access/update/etc using MySQL. At present the only way for me to obtain data to work with is via manual CSV downloads, which I then work with in Access &amp; Excel, which is both ridiculously tedious and inefficient. 

Since my arrival at the company I have been pushing for SQL access to the database tables, so I can better make sense of the data and automate updates etc, but the head of IT has basically run me down every time I have taken problems to him, using my inexperience of SQL as justification for shutting me out. In short he is territorial and is unwilling to allow anyone else access to the data, making up excuses about overloading the server, not knowing the data etc etc.

Following advice from my boss I am now learning MySQL. The plan is that I get an extract of the database tables of our CRM system and fully get to grips with them using MySQL. I hope to be able to reorganise the messy tables into a new structure, good enough to sit Qlikview over. This should then allow us to go to the head of IT and counter his excuses about data access. I have used SQL in previous jobs a little and have a lot of experience with Access so I am finding it straightforward. However I am unsure where to begin in terms of designing a whole new database that I hope to use going forward (I don't want any work I do now to go to waste).

In summary:


I have MySQL installed on my PC with Heidi SQL as my workbench
I will shortly be receiving a large extract of tables from out CRM software. These are poorly documented and I will need to do a lot of work with them to get the required output
My end goal is a well structured database with well organised and documented tables, which bring together the useful data from the CRM tables
Where should I start with this?
How should I store the tables? With Access I have one 'Source Tables' database that simply contains all my major tables, and I have other project specific databases that link to these tables. This is so I only ever need to change 1 copy of the tables.
What ETL processes, tools should I use?
What else do I need to think about? I have been reading a lot about indexing etc, but is there anything specific to this problem that I may miss?


Sorry for the essay. I'm not really sure where else to go with this, IT are definitely not going to help me!

Any help would be appreciated. Thanks
Where should I start with this?


This is a really tough question. You're basically tasked with designing, administering, and migrating to a net-new database using new technologies without much support. This isn't exactly a recipe for success at the enterprise level. In my opinion, just getting your data loaded and accessible in a mySQL database will be the first and most important hurdle. Here's a response on how to convert well formatted CSV dumps to table using HeidiSQL:
https://stackoverflow.com/questions/3635166/how-to-import-csv-file-to-mysql-table

In terms of database design, I can't really help. However getting a "copy" of what current databases look like is a great starting point. This allows you to "select into new_table query_from_source_tables". 


  How should I store the tables?


I would store them as a MySQL database called something along the lines of "source" or "legacy". You can grant other databases access as needed to these tables. 


  What ETL processes, tools should I use?


Entirely up to you. I like, generally, doing 1-off queries and then turning them into views if they need to persist/update through time. ETL is entirely up to the demand of the things which access the database. In my opinion, kick the can on this until you have things working in MySQL with your legacy dump and have a decent new design. 


  What else do I need to think about? I have been reading a lot about indexing etc, but is there anything specific to this problem that I may miss?


I wouldn't worry about indexing until you're worried about performance tuning. That usually comes after proof-of-concept. I would specifically think about sustainable database design and/or migration plans to a new database structure on the applications that leverage the old database. 

In terms of specific problems, I think you've just got your work cut out for you to redesign a database system. Focus on one "major" thing at a time, so you can focus more on what you're doing.