I'm not a DBA, nor a DB developer, nor someone whose main work is to do with using or managing databases. Nor have I ever had a job of that type.
But I've been involved with databases on and off for about 40 years (not SQL or anything relational at first, obviously).
That involvement includes being chief architect of a massively parallel relational data engine (that was about 33% of my job at the time - the other 70% was being chief software architect for the rest or the Alvey Flagship massively parallel system and its applications and trying to keep our academic partners in the real world) in the 80s and early 90s;
designing a a lock manager to allow Oracle to run on the EDS massively parallel system;
researching deadlock detection methods and acquiring patents in deadlock detection for distributed and parallel RDBM systems for my employer (that bunch was again about 30% of my job: the rest was putting together proposals for massive research projectss, while holding together research collaborations covering everything to do with parallel and declarative systems and involving industrial and academic partners from several countries)
running a project that included development of a new ODBMS (never again - I'd had previous experience of ODBMS and it was all dire but I was naive and trusted the people who said they needed it and also the people who told me they could do it: wrong on both counts)
proposing SQL extensions for implementation in various Esprit projects
throwing IBM and their DB2 out of a company and replacing it by SQL Server 2000 for a "map the web" project that I was running (needed a locally distributed system with a total of 42TBytes of data in a set of linked relational databases - vertical partitioning onto 40 servers and 2 servers handling metadata and overall control to keep the other 40 productive; but the main thing was developing extremely efficient spiders, so the database didn't get too much attention)
and finally from 2002 to mid-2009 being technical lead (various job titles, ending up as Chief Architect and Technical Director) in a company providing interactive entertainment systems and content to 5 star hotels (and to the ruler of Qatar for his summer residence) where everything was data driven from data held in SQL databases and the current system state was made persistent in the DB instead of in filestore too (and there was a requirement for 24X7 operation, another requirement for monthly content upgrade) and a very firm requirement that the customers' IT staff couldn't get their sticky fingers into the servers.
I reckon none of that makes me a DBA or a DB Developer.
I had to learn to understand the relational model and how its multi-valued logics worked (the latter was easy - I started life as a mathematician and my thesis was about the semantics of logical calculi, so I had a head start) but understanding the relational model meant people started regarding me as a database expert, and then I had to understand SQL and doing that made people regard me as more of a database expert, and then it somehow came to be that in my various jobs I knew more about databases than anyone else in the company (or, while I was still employed by ICL, anyone else in the same division of the company) and that made people think of me even more as a database man, and these days there are a lot of people who think I'm a DBA.
But people like Gary and Grant and Gail (just to take one letter [G] of the alphabet - we can easily find as many more for J, or indeed for most of the other letters) each know 100 times more about being a DBA (whatever the A stands for) or a DB Developer than I know or probably ever will know, so it always feels wrong to be called either of those things. I can talk about the theory (having been involved in a lot of research collaborations involving academics I have had to understand the theory, not just the jargon but the real ideas behind it) and I can do some of the practical things pretty well, but the real DBAs or DBDs who contribute SQL Server Central can run rings around me on th epractical stuff on on how the SQL Server technology works any day of the year. And these people work with relational databases as their main job - they are the real DBAs (whether the A stands for Administrators, Architects, Appliers, or Alphas).
PS: I saw the "true DBA" idea in some of the comments. Don't know what it means. I guess it's the opposite of a "false DBA", but I don't know what one of them is either. Hence "real" and not "true" above.