Non sono particolarmente d'accordo, per la domanda posta, a parte per l'ultima affermazione.
O meglio i concetti ci sono, ma un po'... confusi
1) PHP/Java/JavaScript/C++/stic..a non ha nulla a che vedere con la progettazione database
2) SQL-NoSQL: dipende essenzialmente dall'ambito in cui si lavora. Ambito gestionali? SQL. Ambito applicazioni web? SQL. E così via. NoSQL solo per minime, minimissime aree davvero specializzate. In sostanza se ti serve un db NoSQL significa che sai già il perchè
3) oracle-mysql-sqlserver: non c'entrano nulla, o quasi, con la progettazione database
4) teoria relazionale? non basta, è "roba" vecchissima, di prima che nascessi, quindi parliamo di una 50ina di anni fa. Ci vuole la versione 2017, non la "solita" menata delle tre forme normali e così via (sempre roba di 50 anni fa). Google o Facebook, per capirci, non esisterebbero (e non potrebbero esistere) secondo queste metodiche.
5) ovviamente bisogna conoscere perfettamente la teoria relazionale, è l'elemento base. come talvolta spiego però ci vorrebbe la versione 2017. per analogia è come il freno a mano: a scuola guida ti insegnano che serve per fermare l'auto (di stazionamento). e tu devi sapere che questo è l'impiego principale. poi, però, quando fai un corso di rally (o di drift) imparerai che con il freno a mano ci fai... le curve (cosa vietatissima secondo il metodo "scuola guida"). ovviamente, però, se arrivi a livello "pilota" (sia pure amatoriale) devi aver già chiarissimo tutta la versione "scuola guida", prima di avventurarti oltre
Allora, in concreto, chi progetta i db? La risposta è: dipende da quale azienda stiamo parlando.
Se parliamo di una miniazienda con 10 dipendenti, la risposta è "il primo che capita", perchè mancheranno le competenze specifiche.
Se l'azienda ha poniamo 100 dipendenti, la risposta tipica è "uno dei più vecchi", cioè uno dei "programmatori" con più esperienza, che hanno seguito progetti per decenni, e ormai conoscono i pattern e gli antipattern come il palmo delle loro mani
Per aziende più grandi (che in Italia essenzialmente non esistono, nel senso che praticamente sempre sono il conglomerato di altre sub-aziende o rami, insomma la faccio breve) può esistere qualche figura specializzata, che poi è "uno dei più vecchi",... in formato... ultravecchio
Perchè tutto questo? Semplice, perchè il db non è un fine, ma un mezzo per ottenere uno scopo.
Praticamente sempre non si parte con un progetto da zero (parlo in azienda), quasi sempre (per non dire sempre) si parte da una base già fatta (cioè il proprio "bagaglio" di strumenti, programmi eccetera) cui poi verranno apportate delle modifiche più o meno ampie, ed è in questa fase che c'è l' INTEGRAZIONE (nel senso di modifica, ampliamento).
Quindi LI' ti trovi a dover ragionare con un db già fatto, che ha una sua logica, che devi bene o male seguire.
E' il caso tipico di una verticalizazzione della diba di un cliente, un qualche metodo strano per valorizzare il magazzino eccetera.
---
Nei rarissimi casi in cui si parte da zero (ma nella mia esperienza l'ho visto solo 2 volte, con risultati disastrosi per la verità) allora - di solito - un miniteam di "vecchi" inizia a fare un po' di brainstorming
---
Riassunto netto: se speri di essere assunto da qualcuno (in Italia) per progettare database tutto il santo giorno, penso che te lo puoi scordare. Ti capiterà, se sei particolarmente esperto, di farlo una o due volte nella vita.
Poi accadrà invece, più frequentemente, diciamo una volta al mese, di dover aiutare qualche collega con qualche personalizzazione "strana e pesante" dal punto di vista del db.
Addirittura è più facile (relativamente) trovare impiego (all'estero) come consulente dei db, cioè come modificare un db già fatto per migliorarlo (negli USA i top in questo ambito si fanno pagare $1000 all'ora, e anche più).
Ma non credo che queste figure esistano (in Italia), o per lo meno non le conosco (ovviamente conosco "quasi" tutto il mercato, ma non di sicuro "tutto").
Spero di essere stato utile.