2009-02-28 20 views
8

AdventureWorksデータベースでは、テーブルをグループ化するために異なるスキーマが使用されています。なぜこれが行われるのですか(セキュリティ、...?)、私が見つけるベストプラクティスはありますか?SQL Server(2008)でスキーマを使用するためのベストプラクティス

THX、リーフェンCardoenビジネスインテリジェンスのマネージャーとして

+0

[SQL 2005でスキーマを使用するためのベストプラクティス?](http://stackoverflow.com/questions/452048/best-practices-for-using-schemas-in-sql-2005) – raven

答えて

18

は、我々は論理的にグループ化し、セキュリティ管理のためのスキーマに依存しています。ここではいくつかのケースでは、我々は、スキーマを使用する方法のとおりです。

論理編成

  1. 私たちは私たちのオペレーショナルデータストア(ODSをロードする前に、もっぱらステージングデータのためのSSISパッケージによってロードされている一般的なデータベースを持っています)。このデータベースでは、スキーマを除いて、すべてのオブジェクトが元のソースに構造(表名、列名、データ型、NULL可否など)でインデントされています。スキーマを使用して、表の元のソース・システムを示します。まれに、2つの異なるデータベースに同じ名前のテーブルがあり、スキーマによってステージングデータベースで元の名前を引き続き使用できます。

  2. BIサーバーの各データベースには、各チームメンバーにtest_usernameスキーマがあります。データベースにテストオブジェクトを作成すると、オブジェクトの作成者を簡単に追跡できます。誰もが何を作ったのか誰もが知っているので、後でテストオブジェクトをパージする方がずっと簡単です。率直に言って、私たちが作ったことを知っているだけで、それがいつ、なぜ私たちが作ったのかを覚えていないときに、それが安全に削除できることを知るのに十分です。

  3. 私たちのデータコントローラデータベースでは、スキーマを使用して、レポート、etl、および一般的なリソース間のさまざまなタイプのプロセスを分けています。

  4. スタースキーマのデータウェアハウスでは、すべてのオブジェクトがディメンションおよびファクトスキーマに分割されます。

  5. 他の部署のサーバーにデータをプッシュすると、サーバー上のすべてのBIオブジェクトにスキーマbiが使用されます。これにより、二重負荷を本当に簡単に知ることができ、サーバーにない場合でもテーブルを維持できます。ターゲットサーバーが2008/2005 SQL Serverボックスではない場合は、テーブルにbi_のプレフィックスを付けます。

それに降りたとき、私たちは、スキーマが存在しない場合に、それを整理するためのオブジェクトに接頭辞や接尾辞を付加していた論理編成いつでものためのスキーマを使用しています。これを言っても、BIサーバー上でスキーマを使用しない場合がいくつかあります。私たちのWorkDBでは、すべてがdboです。私たちのWorkingDBはTempDBのように一時テーブルを作成するのに使われますが、これらのテーブルはETLプロセスが実行されるたびに作成されることがわかっている一時テーブルです。 WorkDBの特別な特性は、データベースをバックアップすることはなく、データベースを使用するすべてのETLプロセスは、表がない場合でも、オブジェクトを最初から再作成できる必要があるということです。この例では、一時的なETLプロセス以外のオブジェクトを実際に使用していないため、スキーマを使用して組織価値を追加していないと感じました。

SECURITY

  1. 我々はBIグループなので、私たちは一般的に構築し、当社独自のアプリケーションをサポートしていません。ほとんどの場合、他の人のアプリケーションを使用し、バックエンドデータベースからサーバーにデータを持ち込みます。しかし、さまざまな小さなCRUDアプリケーションのバックエンドであるbi_applicationsというデータベースがあります。これらのアプリケーションは、通常、BIで管理する必要のあるデータをキャプチャできるように、ビジネスに提供するデータ入力フォームです。これは、本番アプリケーションの中にあるべきデータをBIに取り込む一方で、優先順位の低いアプリケーションの拡張が将来の開発リストにダストを集めるのを待つ間に行われます。各アプリケーションには別々のスキーマがあり、基礎となるテーブルを更新するために使用されるアプリケーションアカウントは、関連するスキーマのオブジェクトにのみアクセスできます。これにより、別々のアプリケーションを理解し、安全に保ち、維持することが非常に簡単になります。

  2. 私はパワーユーザーがテーブルやストアドプロシージャに直接データベースアクセスできるようにしています。私たちは、オブジェクトを保護するためにロールと組み合わせたスキーマの使用に頼っています。私たちはスキーマに権限を与え、ユーザーは役割に追加されます。これにより、どのオブジェクトが誰によって使用されているのかを簡単に理解することができます。要するに

は、我々は我々がおそらく出て、自分のデータベースにオブジェクトを分離すると考えられていた場合に、セキュリティ上の目的のためにスキーマを使用して、我々はデータベースにアクセスするためにBIの外にアプリケーションまたはユーザーが期待していたとき。

これらはアプリケーション開発者のビジネス上のベストプラクティスではありませんが、私のバイケースは、ビジネスの最後にスキーマを使用するいくつかの方法を考えるのに役立ちます。

関連する問題