SQLをテストする方法がよく分からなくなったこと

PG中のSQLにバグがないことを検証する単体テストをしろって言われたんだけど、テストの設計はあまりやった事がないのでちょっと困った・・・

＜テストの条件＞
１．PGの機能は、元のデータベース（A）からSQLで取得したデータを
　　別のデータベース（B）のテーブルに書き込む
　　というもの

２．SQLは複数のテーブルを結合していて
　　それぞれにWHERE文で抽出条件を指定していて、やや複雑

３．テスト内容は、下記の形でPGの正当性を示せ、という物
　①「PGを実行すると、データベースＡからはＮ件のデータが取得されるはず」
　②そして実際に実行してみると
　　「データベースBにＮ件のデータが追加された」
　③よってこのＳＱＬは正しい


４．データベースＡには本番データをもとに作ったテストデータが現在入っているが
　　このデータは参照のみ許可されており、削除・編集してはならない
　　データベースＢのデータは好きにいじってよい（全部空にしちゃってもよい）


＜考えた事＞

データベースＡの特定のデータ２，３件を抽出して
「このデータはＢに書き込まれる」「このデータは書き込まれない」というのを
検証するのは簡単だ。私も今まではそういう風にテストしていた。

しかし、今回の指示はそう簡単ではない。
データベースＡをのデータを一つ一つ見て行って
「このデータはＢに書き込まれる」「このデータは書き込まれない」と調べていけば
原理的には検証可能だが、そんな全数調査できるほど小規模なデータ数ではない。

ＳＱＬ中に出てくる各抽出条件すべてを総ナメするように
テストパターンを機械的に作って、それをデータベースＡに入れたうえで
テストすれば、「Ｎ件出てくるはず」というテストはできるだろうが
今回の場合、データベースＡの中身はいじるなと言われているのでそれはできない

かといって、他にどういう方法をとったとしても結局
　①　ＰＧ中で実行しているＳＱＬを実行する→Ｎ件取得される
　②　ＰＧを実際に実行する→Ｎ件取得される
①と②の件数が一致したのでテスト成功です！
という「お前、それ同じＳＱＬ流してるんだから当たり前じゃん」という
テストと等しい内容のテストしか思いつかなくて行き詰ってしまいました

＜知りたい事＞

１）何か上記の条件を満たすいいテスト方法はないでしょうか

２）そもそも、どんなテストも厳密に完全にＰＧの正当性を検証することはできない
　（同じＰＧを二回作って検証することになってしまう）
　と思うので、自分のアプローチ（もしくは上司からの指示）がそもそも間違っている気がします。

　この状況で全件数モレなく取得することを検証するテストを考えるのが無駄であるならば
　せめて、一般的にＳＱＬの正しさを検証するテストにおける頻出チェックポイント
　みたいなものがあったら教えてください。