Ok. I'm going to make a few assumptions. You have a potentially (very??) large dataset. You ONLY want the average, not the actual values themselves, to use in your application at this particular point in time.
So, we're doing a very simple operation, to find an average of the records that meet your query criteria.
So... your options are, retrieve all those records in the db query, bundle all that data down the pipe (potentially especially damaging/expensive for distributed application where you're querying data off a foreign server into your local app), THEN parsing all that data into some local container object (not necessary, but depending on what tech you're using, it might be happening anyway, LINQ/EntityFramework etc), THEN you use your code logic to iterate through all those records and calculate the average. This is obviously NOT ideal.
An example of the sort of query name I'd expect here might be Users_GetAllExamScores(), highlighting the fact that you're returning a potentially massive dataset, then working the data down to find the average.
OR
You realise that you've already found all the data you need by doing the query, you can do the simple average operation locally in the db layer, its not really a "business logic" operation, so it doesn't offend my especially an@lly-retentive-design-theory notions, and you return a single floating value, potentially saving your data transfer load by a factor of 1000s. This, is obviously very good.
and the query might be Users_GetAverageExamScore(), highlighting the fact that you're returning a SINGLE value.
Now... you can see by my initial assumptions where this decision might suddenly and easily be made more complicated... because lets say you ALSO need each individual exam score as well, (say you're displaying them on screen), then hell, you might as well return all the data because you HAVE to anyway, and then average it locally, instead of performing BOTH queries on the database, one to get all records, one to get the average.
As an interesting side note, it's been my experience that things like this are where you really stand to blow out your application performance. People get REALLY hung up on whether
C++ is fractions of a second faster than C# when it comes to performing multidimensional integration with their awesome new algorithm... and then write a sloppy query that returns 10 billion rows of data and filtering it in application, when they REALLY needed 15 in the first place and could have made the database do the SIMPLE work earlier and saved themselves seconds of load time while your poor database breaks down in tears and your internet traffic goes through the roof...
Note I say SIMPLE work in the db... NOT business logic.
This is ESPECIALLY important when it comes to abstracted db querying frameworks like the LINQ and Entity .Net systems... which burned people REALLY badly because they often don't get a feel for what the actual SQL query will look like or do when they write up the code-side query, and Linq generates some slightly oddball SQL as a result...
Hope this helps.