How do I get attributes from a database into saml assertions ?

LTM/APM isn't capable of making direct database calls, so you'd necessarily need to initiate a sideband call to a web server that can perform the lookup and return the results. Once you have the results, assign them to APM session variables and define those variables as SAML attributes in the IdP service configuration.

Is there an example iRule sideband that would do the http request?

A use case would be, If I did a get with the username in question and it returned a set of attributes.

Here's a fairly standard sideband call implementation. Details to follow:

when RULE_INIT {
     user-defined: name of internal web server virtual server
    set static::WSVIP "webserver.vs"

     user-defined: debug enable/disable (1/0)
    set static::DEBUG 1
}
when HTTP_REQUEST {
     Prepare the sideband call
    set conn [connect -timeout 3000 -idle 30 -status conn_status $static::WSVIP]

    if { $static::DEBUG } { log local0. "conn_status = $conn_status" }

    if { $conn eq "" } {
    if { $static::DEBUG } { log local0. "Sideband IdP connection could not be established" }
        return
    }       

     Prepare user information to transmit to web server sideband call 
    set userdata "bob.user@example.net"

     Create the data to send to the web server VIP
    set data "GET / HTTP/1.1\r\nHost: [HTTP::host]\r\nUser-Agent: cUrl\r\nAccept: */*\r\nUSER: $userdata\r\n\r\n"

    if { $static::DEBUG } { log local0. "data = $data" }

     Send the sideband call
    set send_info [send -timeout 3000 -status send_status $conn $data]

    if { $static::DEBUG } { log local0. "send_status = $send_status" }

     Receive the web server response (via data "peek")
    set start [clock clicks -milliseconds]
    for {set i 0} {$i <= $static::retries} {incr i} {
        set recv_data [recv -peek -status peek_status -timeout 10 $conn]
        if { [string match "HTTP/*\r\n\r\n*" $recv_data] } {
            if { [string match -nocase "*Content-Length: *" $recv_data] }{
                set header_length [expr {[string first "\r\n\r\n" $recv_data] + 4}]
                set payload_length [findstr [string tolower $recv_data] "content-length: " 16 "\r"]
                if { $payload_length ne "" and $payload_length > 0 } {
                    set recv_data [recv -peek -timeout 3000 -status recv_status [expr {$header_length + $payload_length}] $conn]
                    break
                } else {
                    break
                }
            } else {
                break
            }
        }
    }

    set returned_data [findstr $recv_data "\r\n\r\n" 4]

    if { $static::DEBUG } { log local0. "recv_data = $recv_data" }
    if { $static::DEBUG } { log local0. "filtered data = $returned_data" }

     Close the connection
    close $conn

     The data returned from the web server is now in the $returned_data variable...
     ...do something here...
}

First thing you want to do is configure another LTM VIP to actually load balance the web server. It isn't expressly required, but a good general practice. Configure the sideband call to use the virtual server by name:

set static::WSVIP "webserver.vs"

Next you need to define what you want to say to the web server. The following is just an example, but ultimately you want to create a full HTTP request (GET or POST) to send to the web server:

 Prepare user information to transmit to webserver sideband call 
set userdata "bob.user@example.net"

 Create the data to send to the web server VIP
set data "GET / HTTP/1.1\r\nHost: [HTTP::host]\r\nUser-Agent: cUrl\r\nAccept: */*\r\nUSER: $userdata\r\n\r\n"

Here I'm just setting an arbitrary header (USER: bob.user@example.net), but you might more likely need to pass a query string or POST payload.

set returned_data [findstr $recv_data "\r\n\r\n" 4]

if { $static::DEBUG } { log local0. "recv_data = $recv_data" }
if { $static::DEBUG } { log local0. "filtered data = $returned_data" }

 Close the connection
close $conn

 The data returned from the web server is now in the $returned_data variable...
 ...do something here...

The web server will respond to the sideband call with a full HTTP response (headers and payload). The $recv_data variable will contain that full response, while the $returned_data will just contain the payload data.

Since you're doing this with APM, you can actually change the HTTP_REQUEST event to the ACCESS_SESSION_STARTED event, collect the sideband results, and then store them directly in session variables right there. How you do that depends on how the web server's returned data is formatted. Example:

ACCESS::session data set session.custom.sqldata $returned_data

You can still use the HTTP_REQUEST event, but you're guaranteed to be in an active APM session in the ACCESS_SESSION_STARTED event.

How would this change, if we wanted to pull the username from the session created in APM?

The only thing that might change is where you initiate the sideband call. So let's say for instance that you're collecting username from a logon form. Directly after the logon form, or perhaps after some preliminary AD/LDAP checks, insert an iRule agent into the visual policy. Now take the HTTP_REQUEST event in the above sideband iRule and change it to an ACCESS_POLICY_AGENT_EVENT event. You'll also potentially need to change the send string to send the username from the session. Example:

set data "GET / HTTP/1.1\r\nHost: [HTTP::host]\r\nUser-Agent: cUrl\r\nAccept: */*\r\nUSER: [ACCESS::session data get session.logon.last.username]\r\n\r\n"

The sideband call will be sent mid-access session.

This again will insert the session username into an HTTP header called "USER". You may need to do something different, like insert it via query string or POST payload.