むしろ、RDBMSとSQLの基礎知識レベルは必須、むしろそこからアレンジされたDBとかも知識必要にはなってくるという認識です。
ちなみに私は、RDBMSが先です。
データを保存するという役割で、RDBMSは標準的に用いられる
通常のプログラム開発では、とても当たり前にRDBMSとSQLは基礎知識です。RoRのActive Recordのように、その存在を隠蔽する形で簡単に開発出来るようにしたものもありますが、データを保存する目的でRDBMSが一般的に用いられています。
無論KVSのようなNoSQLなDBも現在ではあります。が、RDBMSを知った上で、RDBMSで課題となる所を代用する、というものだと思ってもらった方がいいです。例えばBig Dataで用いられていたHadoopという仕組みなんかがそうなのですが、しかし、それでも、SQL扱えないの不便という事で、SQLのような形でのアクセスを可能にする、Hiveというものが作られ、わりとこちら使われています。
とややこしく書きましたが、上はある程度知識スゲーとか思ってもらう用で、身も蓋もなく言えば「データとか考える時に、SQL/RDBMSベースで思考するのが標準になっていて、それはSASだろうが同じだし」という事で学んでおいた方がいいです。
システム開発の会社で、SQLを学ばせないとかは正直有り得ないレベルです。
NoSQLについては、以下参照で逃げときます。リアルワールドデータのビッグデータ解析、なんかで出てくる事はあります。が、まあ、その時にも大抵SQLライクな言語でアクセスするようになってたり、SASの場合でもSQLプロシージャでアクセスさせたりするのが基本的になってたりします（ビッグデータ解析ではパフォーマンスの問題から、最初にかなり条件絞り込んだ上でデータを取得するようにしないと死にます）
ja.wikipedia.org
ここら辺は、ほーんとかで正直軽く知っておくだけで十分です。
SQLのハンドリングで、「あまり一気にやりすぎない」「サブクエリを駆使しすぎない」「わかりやすい中間テーブルを作る」「SQLだろうがSASだろうがややこしく書くと損する」事は気をつけて。
これらは、SQLの初学者ではまあ引っかからないのですが。
世の中のほとんどのJOIN、テーブルの結合というのはLEFT JOIN/INNER JOINで事足ります。
テーブルの結合の際、関係性として両方のテーブルが等価というのはほぼ意味がなく、大体はどちらかが複数レコードに展開されている実データ、もう一方はそのデータに対して情報を追加していくようなデータになります。よく後者をマスターテーブル、前者はスレイブとかはあんまり言わないけどシステム開発であればトランザクションテーブルと言ったりしますが、SDTM/ADaM等の場合には上手く当てはまらないと言えば当てはまらないのですが、前者が変更されにくいもの、一症例一レコードのデータ、後者が変更されるもの、一症例複数レコード（時点のキーがある）と思って貰えばと思います。
プログラムの手順考えてひと手間省けそう、というのでFULL OUTER JOINとかを使うのはオススメしません。途中で作っているデータが何なのか説明しやすいように作った方がいいです。
proc sql ; select A.x,B.xx from (select C.x from C left join D on C.ID=D.ID where D.ID is null ) as A left join B on A...... << みたいなのとかは、これくらいのサブクエリなら読めると思いますが、Aについてビューなりテーブルなりを生成するSASらしいやり方でやった方が、途中データを確認できますし分かりやすくなるとは思います。
