Adobe DTM/Analytics and Demandbase Attribute Mapping
Does anyone know how the Demandbase attributes are mapped to Adobe Analytics variables within DTM? I have scoured the web and can't find anything yet! All I got was a table 9see image). I have the integration part completed, I just now need to map these attributes but can't find any info on how? 
If you are paying for Demandbase (DB) (which you should be; AFAIK there is no free version), you should have been assigned a DB resource to explain how the integration works and walk you through it. That should be part of what you paid for. So I would firstly suggest you contact DB to help you if you are having issues. And that resource should [have] explain[ed] everything you are about to read below.
Especially as far as understanding and configuring what DB data points you will actually push to Adobe Analytics (AA), because DB has many data points, and you only select a handful of them to push to AA. Your SS above shows 10 data points pushed to 4 eVars. Well DB has.. I'm not sure how many they actually have, but I've seen at least 50+ from various clients I've worked with.
But in general, this is the way the DB / AA integration works:
First, you add the DB snippet to all of your site's pages. This snippet makes an async http request to the demand API, which responds with the DB data. The DB script then pushes the data to a cookie. The DB script then reads the cookie and populates Adobe Analytics (AA) Context Data (CD) variables. Because the API call is async, the CD variables may or may not be popped in time for the initial AA hit, but should be available for subsequent AA hits since it looks for the cookie. Main thing to note about this is it makes landing page AB/MV testing based on DB info unreliable.
DB pushes the designated data points to CD vars. The data points are grouped, usually based on average/max character length of the values, not to exceed the max length of the eVar (255 chars). The CD var names themselves may vary, but based on your screenshot, they get popped something like this:
s.contextData['s_dmdbase'] = 'demandbase_sid:marketing_alias:annual_sales';
s.contextData['s_dmdbase_custom1'] = 'industry:sub_industry:revenue_range';
s.contextData['s_dmdbase_custom2'] = 'employee_range:city:state';
s.contextData['s_dmdbase_custom3'] = 'company_name';
Where the actual values for the data points are popped, not the attribute names (e.g. demandbase_sid would really be 12345 or whatever).
Meanwhile, within the AA interface, you should have your designated eVars enabled (based on your screenshot, eVar52-55).
(Sidenote: I think this is the direct answer to your immediate question) Next, you should have Processing Rules (PRs) set up to map the CD vars to the eVars. Simple PRs that just say if CD variable s_dmdbase is set, set eVar52 with value of s_dmdbase. One for each eVar (can be in the same PR group).
Next, you should have classifications setup for the eVars, for each of the data points to be pushed to them. So for example, for eVar52 you should have (example naming conventions..do what you want):
(v52) Demandbase Group 1
> (v52) DB: SID
> (v52) DB: Marketing Alias
> (v52) DB: Annual Sales
Next, you should have classification rules setup in the Classification Rule Builder (CRB) for each eVar. Each CRB should look something like below. Using v52 as example, you should have 3 rules in the ruleset, one for each data point. The Rule Type and Match Criteria will be the same for all of them:
Rule Type: Regular Expression
Match Criteria: ^([^:]*):([^:]*):([^:]*)$
Then set the Classification column, one for each column (3 columns, 3 rows). Then, for the "To" column, put $1 for the first row, $2 for the second, and $3 for the third, which lines up with how they appear in the raw key.
Having said all this... This is how the DB>AA integration is setup. However, the standard implementation is not to do all of this manually (e.g. setup the PRs, Classifications, CRBs yourself). Instead, you setup a Data Connector (DC). Your Demandbase Rep should [have] provide[d] you with instructions for that. But basically within the AA interface, you navigate to Admin > Data Connectors, and choose Demandbase from the list and then configure it based on your DB setup. Your Demandbase representative should have provided you with some info for this, including a tag uid and api key.
And the rest of the Data Connector setup is fairly straight forward. Basically you just specify the eVar(s), the classification column names, etc. and then the Data Connector creates the PRs, Classifications, and CRBs for you. One major thing I will note about going the Data Connector route is that it expects you to specify exactly 8 data points for each eVar.
Problem is in practice, this hasn't jived with virtually every DB integration I have done for clients (I've done like 30 now). In practice, you work with the DB rep and configure the CD vars, and the name of the game is to stuff as many data points into an eVar as possible, to minimize how many eVars you burn and maximize how many data points you push to AA. So in practice, I usually see eVars with anywhere from 7 to 15 data points.
Meanwhile, the Data Connector expects exactly 8, no more, no less. So, setting up the AA interface/config stuff via the Data Connector is more often than not, not an option. But you can do all of it manually as described above.
The main downsides to NOT using the Data Connector is the Data Connector also generates some dashboards (though in practice, I have never seen a client favor them over their own custom dashboards - no big loss). Also, supposedly, the Data Connector is a 2-way street. Supposedly it enables data to be exported from AA to DB for AA>DB integration. I'm not sure how true that actually is, or how robust it is if it is true, though. I've never had a client actually care about pushing AA to DB or look at reports in DB so I've never really dived into any of that. But point is, you lose that by not going the Data Connector route.