The database layer is intended to isolate the rest of the application from the details of the database -- how to make a connection, the syntax used to talk to the db engine, etc.
The .Net Entity Framework version of your code would be:
var id = customer.id;
var customerOrdersTotal = db.Orders.
Where(o => o.CustomerId == id && o.Active).
Sum(o => o.Total);
Note that this would get translated into your sql version, but the exact same thing could be done without involving sql at all.
If you have a Customer that has Orders, then it would be:
var customerOrdersTotal = customer.Orders.
Where(o => o.Active).Sum(o => o.Total);
And this version could be written regardless of whether Orders is a virtual list or an actual list of orders.
The business doesn't care where the data is kept or how it is retrieved. The point of a DAL is to abstract away the "how is this bit of data retrieved" and turn it into just the necessary (i.e. unavoidable) "how to request the data I want". Without a DAL you have to mix the two functions together, which means you can't change one without changing the other.
Note that about half the time, you don't ever end up making any changes...but when you do it's a real pain if they are mixed together.