From the perspective of the database user, the backend is generally irrelevant if they understand some basic concepts.
First and most important concept for the non-technical user is GIGO (Garbage in Garbage out). Bad data is useless data. Check everything you enter into a database for correctness. You really don't want the customer's product to be mailed to San Diego, VA instead of CA.
Then next most important thing is to really understand your user interface and how it works. I've spent a lot of time fixing up junk because users didn't know what they were supposed to put in fields in databases (it would have helped if the developers had not allowed non-email type data to be entered into the email field, but you can't send an email to 757-111-6789). It is never a good idea to put the wrong kind of data into a field because you don't have another place to put it. As a user, you may have no idea what the database is going to use that data for and wrong data can completely stop a process or break something really important. If you don't know what to put in a field, then ask. Don't put junk into a field just because it is required. (Hint, it is required for a reason, that usually means this is data critical to the operation of the database, do not fake this information.)
Now if this person is doing reporting, then the critical concepts become understanding boolean algebra and a very strong undertanding of joins. If you have these two concepts down pat, you have 80-90% of what you need to query a database.
The specifics of the database supported also become important. You need to understand what is stored in what tables (or what views to use) and how they relate to each other. Coming into a new job, I would sit down with the developers if possible and get an overview of the design and whatI would need to know to get the data. I would review existing report queries to see how the data is currently being retrieved and use that to ask questions if I don't understand what the person did. Even a database expert will need to spend some time doing this when faced with a new database, so there is no reason to be shy in asking these questions when you are new.
Final thing is to learn how to report a problem to the developers. Problems that are not reported don't get fixed! Problems that are not reproducable because the user didn't provide screen shots and a context for what she was doing when the error occurred, don't get fixed either. New data fields that are needed as business requirements change, don't get added to the database until the developers know about them (Please ask for a Notes field if you need it instead of entering junk data into a field like email that you personally are not using for instance). New business requirements often require a lot of work in the backend to change how things work, it isn't as simple as adding a field on a form. Please be aware of that too when you make requests.