2

これは、最近私に寄せられたリクエストのために私が尋ねる理論的な質問です。私は、一連のデータ テーブル (マスター データを含む) と一連のルックアップ テーブル (参照コードのリストとその説明を含む) を維持するマスター運用データ ストアのサポートを所有しています。最近、ダウンストリーム アプリケーションから、2 つの構造 (データとルックアップ値) をプレゼンテーション レイヤーで論理的に結合して、データ全体に更新があったかどうかを簡単に確認できるようにする動きがありました。要求は理解できますが、最初に考えたのは、ソースではなくインターフェース レベルで実装する必要があるということです。2 つのテーブルを ODS レベルで論理的に結合する (last_update_date) ことは、データの非正規化とほとんど同じであり、ルックアップとデータを分離しておくという考えに反しているように見えます。そうは言っても、それが正しいように「見えない」という事実を除けば、ODSレベルでそれを行うべきではない理由は考えられません...そのようなアプローチが必要な理由とすべきでない理由について誰か考えがありますか?フォローされる？

簡単にするために、ここに例をリストしています。

Data table
ID    Name    Emp_typ_cd  Last_update_date
1     X       E1          2014-08-01
2     Y       E2          2014-08-01

Code table
Emp_typ_cd     Emp_typ_desc    Last_Update_date
E1             Employee_1      2014-08-23
E2             Employee_2      2013-09-01

ダウンストリーム要求は、データを次のように表すことです。

Data view
ID    Name    Emp_typ_cd  Last_update_date
1     X       E1          2014-08-23
2     Y       E2          2014-08-01

また

Data view
ID    Name    Emp_typ_cd  Emp_typ_desc   Last_update_date
1     X       E1          Employee_1     2014-08-23
2     Y       E2          Employee_2     2014-08-01
4

1 に答える 1

1

おっしゃる通り、誰かが特定の方法でデータを見たいと思っているため、データベースの士気をくじいているのです。ご存知のように、副作用は、データの複製、柔軟性の低下、テーブルサイズの増加、異なるオブジェクトの保存などです。また、それらの問題をどこかまたは他の方法で解決する必要があることも正しいです。データベースを変更したい方法で変更しても、彼らが望むものは得られません。「全体的なデータに更新があったかどうかを簡単に見つけられる」ようにしたいが、大量のデータを複製している場合、エラーが発生する可能性があります。あなたの例では、Emp_typ_cd Updated 値は、その emp タイプ コードを持つすべての従業員に対して更新する必要があります。適切な update ステートメントはそれを行いますが、それでも、

常にルックアップ テーブルを使用します。ルックアップ テーブルに新しい値を追加し、その新しい属性への fk を使用して従業員をデータベースに追加すると、そのテーブルに結合されたすべてのレポートに ID、値、並べ替え順序などが追加されます。「ベテラン」を追加するとします。 ' lu_Work_Experience に。ベテランの fk_Id を持つ従業員を追加すると、lu_Work_Experience に参加する既存のクエリがその値を持つようになります。職務経験をアルファベット順または事前定義された並べ替えで並べ替えます。

ただし、データ構造をフラット化する正当な理由があり、それは速度です。非常に大きなレポートを実行している場合は、現在の結合 (および適切なインデックス作成) を使用すると高速になります。非常に大きなレポートを何度も実行することがわかっていて、エンド ユーザーの待ち時間が心配な場合は、その 1 つのレポートに対して 1 つのテーブルを作成することをお勧めします。計算されたメジャーのために常にそれを行います。特定の分析レポートに大量の集計と結合があることがわかっている場合は、データをデータ ストアに事前に集計します。そうは言っても、分析にキューブを使用するため、SQL ではそれほど頻繁には実行しません。

では、なぜデータベースでルックアップ テーブルを使用するのでしょうか。データの論理的分離。従業員には従業員コードがありますが、従業員コードが更新された日付はありません。重複データを減らします。設計の複雑さを最小限に抑えます。特定のレポート用にテーブルを作成した後に、似たようなデータがある場合でも、別のレポート用に別のテーブルを作成する必要がないようにするため。

とにかく、私の議論の残りはデータベースの正規化ウィキペディアのページからの事実で構成されているので、スキップします。

于 2014-09-11T02:41:31.253 に答える