The function of calculating storage space for the data and making sure it's backed up-- and that restore works!-- is a crucial function-- but one that is very easy to perform with the SQL Server toolset. It isn't a fulltime job, and in my case combines very naturally with database design, query planning and index "design." In the Ingres days, there were fine points of index design to master; now it's simply "which index should be the clustered index?" plus "is the read benefit of this index worth the write cost?"-- leaving more time for investigation/validation of data relationships.

The general point that job functions may be too broad (pilot has to be rested) or too narrow (overspecialized out of existence) calls for analysis of WHICH job functions should be combined. I think the combining of user interface design with database design is a mistake, and of course object-oriented programmers disagree with me. I was an entry-level statistician before I became a database programmer/DBA, and I saw some wild misconceptions from PhD statisticians who did know how to analyze data relationships but weren't familiar with the database design and thus didn't know what was in their data. For instance-- assumption that the table named "employees" held records for all employees when a look at the database diagram might have raised the question "what's in the table employees_former_contract?" And, without a DBA familiar with the business use of the data, there is no sanity check on database size. I've worked with DBA/network administrators quite proud of their facility in managing large and growing data volumes; then I look at the database and see that 90 percent of it is redundant and whitespace.