I don't, I really don't. Teaching non-developers SQL is a nearly always a dangerous mistake. I say nearly always because in some circumstances you might be lucky to identify a user who has some aptitude for programming who can be educated up to a role where they can create ad-hoc reports and functionality of the type you imply. You can generally identify such people in an office because they'll be the ones who the others ask for help when they have computer problems. Often they'll have coded up macros in spreadsheets and other automation tasks. Taking these people under your wing and helping them out can be a great way of solving the problem.
However, you have to tie down level of access they have to the database so they cannot do any damage. A cloned reporting database is generally a good idea. Ideally on a separate server.
Why? because the best, most well intentioned, non-professional is more than capable of screwing up a database if given unlimited access. Even with just select access a couple of inadvertent cross-joins on large tables can bring a server to it's knees. If they then hit the on-off switch because they think that's needed you can end up with some very messed up server software.
The problem is solvable however. Generally when faced with this sort of situation I will do the analysis and create a set of friendly user-facing views that present the data in the format that the users will most likely want to see. I then give the users access to these views only and ideally via a reporting tool. This can be a commercial application or something custom-built that performs basic filter and join operations.
The point is that you're users are not really asking you how they can learn SQL (indeed I'd get a bit worried if my clients started asking me about T-SQL design, it would imply I'd been discussing tech with them and not how tech can be applied to their business situation). The question they are really posing is how can we create ad-hoc reports without calling on you to do them all the time and they've got a bit hung-up on SQL because that's how you've told them you do it. You need to take a step back and address the real business need, not the superficial question