ステージングテーブルと、それらのテーブルを更新するストアドプロシージャを独自のスキーマに配置することを考えていました。SomeTableからデータウェアハウスにデータをインポートするときに、Initial.StageSomeTableプロシージャを実行して、データをInitial.SomeTableテーブルに挿入します。このようにして、初期ステージングを処理するすべてのプロシージャとテーブルがグループ化されます。次に、ETLのその段階などの検証スキーマがあります。
これは、これらすべての非常に類似したテーブルに一意の名前を付けようとするよりもクリーンなようです。これは、各テーブルがステージングプロセス全体でそれ自体の複数のインスタンスを持つためです。
質問：ユーザースキーマを使用してテーブル/プロシージャ/ビューをグループ化し、MS SQL Serverでのユーザースキーマの適切な使用法ですか？または、オブジェクトのアクセス許可をグループ化するなど、セキュリティのためにユーザースキーマを使用することになっていますか？
私はそれが十分に適切であると思います、それは実際には問題ではありません、あなたが好きなら別のデータベースを使うことができます、それは実際に私たちがしていることです。
なぜ検証スキーマが必要なのかわかりませんが、そこで何をしますか？
リストする両方の理由（目的/意図、セキュリティ）は、スキーマを使用する正当な理由です。それらを使い始めたら、オブジェクトを参照するときに常にスキーマを指定する必要があります（ただし、私は怠惰で、dboを指定することはありません）。
私たちが使用するトリックの1つは、いくつかのスキーマのそれぞれに同じ名前のテーブルを配置し、テーブルのパーティション分割（SQL 2005以降で使用可能）と組み合わせることです。最初のスキーマにデータをロードし、検証されたら、パーティションをdboに「スワップ」します。dboパーティションをテーブルの「ダンプスター」スキーマコピーにスワップした後です。純生産のダウンタイムは秒単位で測定され、宣言されたトランザクションにすべて慎重にラップされます。
これは実際に推奨される方法です。ProjectRealのMicrosoftBusinessIntelligenceETL設計プラクティスをご覧ください。ウェアハウス内のオブジェクトをグループ化および識別するためにかなりの数のスキーマを使用していることがわかります（最初のリンクからドキュメントをダウンロードしてください）。
dboとetlに加えて、admin、audit、part、olapなども使用します。