Data Access Layer and Business Objects
How small is small?  Hibernate, JPA and so on would help you get rid of a lot of boilerplate code.

That said.


I'd change selectOne to selectById, similarly for other querying functions, which I'm sure you'll get a lot of, or in general find a good, consistent naming scheme for those functions.
Keep in mind that int has a particular size if you already have a large legacy database.
If possible remove all the statics and make DalProgression a real object (so you can set and reuse QueryRunner/SLDHelper and create better tests).
Did I mention tests. (Legacy == ) please write tests. It honestly helps so much.
In order to do that get rid of the SLDHelper singleton,
which is not a good name, since it has both an unknown acronym in it (at least to me, otherwise you'd have to explain the name) and additionally Helper, which can also mean everything (the acronym goes for DalProgression as well, less so since you've mentioned Data Access Layer; still I'd say something like ProgressionRepository, ProgressionStore or so would be better). If possible I'd just avoid such names.
Move the exception conversion into a separate class so you can reuse that, even if you have to create a wrapper for the QueryRunner.
You could also just directly return from inside the try block and initialise the variables with their values directly, i.e. try { QueryRunner qr = ...; return qr.query(...); } catch ....
I'd also create a SQLRuntimeException or so in order to catch exactly those later instead of grepping for RuntimeException.
Have a plan for transactions in your API, unless you already have, that is.
IgnoreUnderscoreBeanHandler is already generic, there are options (e.g. via reflection) to get rid of the class literal argument.
Unless you have a specific use for that particular toString method I wouldn't use that, rather have something to identify the object in a stacktrace, let's say, the id ("&lt;Progression id=42 name=whatever&gt;").
Thinking about it, if you have the ID and the timestamps in all business objects, create an abstract base class or an interface to capture that notion.


For the joins, I guess that unless you have extra data in join tables, creating separate business objects isn't necessary.  So I'd imagine it would be easier to understand if you just have methods List&lt;Foo&gt; selectFooForProgression(Progression) or Map&lt;Foo, Progression&gt; selectFoosForProgressions(List&lt;Progression&gt;) in the DalProgression class, basically where you start the join from.