1

従業員用のマスターと詳細のテーブルを用意してもよいかどうか疑問に思っています。

要件に応じて、国別の部門別、およびレポート レベルの従業員コード別にデータをフィルタリングできます。

従業員の部門または国コードが変更された場合、変更は詳細テーブルに反映され、古いレコードは IS_ACTIVE = 'T' に設定されます。

---------------------マスターテーブル---------------------- -----------

**EMPLOYEE_CODE**      VARCHAR2(20 BYTE)  NOT NULL, 
EMAIL                  VARCHAR2(100 BYTE)
FIRST_NAME             VARCHAR2(50 BYTE)
LAST_NAME              VARCHAR2(50 BYTE)
WORKING_HOURS          NUMBER

----------------------詳細表--------------------------- -----------

**PK_USER_DETAIL_ID**     NUMBER,
FK_EMPLOYEE_CODE          VARCHAR2(20 BYTE),
FK_GROUP                  NUMBER,
FK_DEPARTMENT_CODE        NUMBER,
FK_EMPLOYER_COUNTRY_CODE  VARCHAR2(5 BYTE),
FK_MANAGER_ID             VARCHAR2(20 BYTE),
FK_ROLE_CODE              VARCHAR2(6 BYTE),
START_DATE                DATE,
END_DATE                  DATE,
IS_ACTIVE                 VARCHAR2(1 BYTE),
INACTIVE_DATE             DATE

従業員テーブルはタイムシート テーブルとリンクされ、タイムシート レポートのデータは、部門、国、および従業員コードによってフィルター処理できます。

オプション：私

  • 1 つの主キーを持つ 1 つの従業員テーブルを用意し、従業員の部門または役割が更新されるたびに新しいエントリを作成します。
  • タイムシート テーブルに国と部門コードを追加します。

--> この方法では、employee テーブルを検索する必要はありません。

オプション：Ⅱ

  • マスターテーブルとディテールテーブルがあります。
  • タイムシート テーブルに国と部門コードを追加します。

--> この方法では、従業員テーブルを検索する必要はありません。さらに、マスター詳細テーブルがあります。

オプション : NEW

  • マスターテーブルとディテールテーブルがあります。
  • タイムシート テーブルには EmpCode が含まれます。
  • ユーザーが新しい場所に移動したり、部門を変更した場合は、新しい部門コードと同じ従業員番号を使用して、詳細テーブルに新しい行を挿入します。
  • 古い行を更新し、終了日フィールドを設定して、場所または部門が変わった場合に終了日フィールドを更新する必要があるようにします。

どちらが最適なオプションで、他に利用できるより良いオプションはありますか?

4

2 に答える 2

3

これは、この要件を実装する1つの方法であり、多くの人が採用するアプローチです。ただし、これには大きな欠点があります。現在の従業員のステータスを照会するたびに、開始日と終了日の詳細をフィルタリングする必要があります。これは些細なことのように思えるかもしれませんが、それがどれほどの混乱を引き起こす可能性があるかは信じられないでしょうし、パフォーマンスにも影響があります。

ほとんどの場合、履歴に関するクエリは比較的まれにしか発生しないため、現在の詳細のみが必要になるため、これらのことが重要になります。その結果、使用頻度の低いユースケースの実装を容易にするために、最も一般的なユースケースの実装を妨げています。（もちろん、私はあなたのビジネス要件について仮定を立てています、そしておそらくあなたはありふれた従業員アプリケーションではありません...）

より良い解決策は、2つのテーブル、すべての詳細列を含むEMPLOYEESテーブルと、同じ列に開始日と終了日を加えたEMPLOYEES_HISTORYテーブルを用意することです。従業員のレコードを変更するときは、おそらくトリガーによって、履歴テーブルに古いレコードのコピーを挿入します。標準プロセスにはクエリするテーブルが1つだけあり、履歴のニーズは完全に満たされています。

ちなみに、提案したデータモデルは間違っています。Working_hours、email_address、last_nameは間違いなく変更される可能性があり、おそらく名も変更される可能性があります（たとえば、結婚などの個人的な状況の変更によって）。したがって、これらの列はすべて詳細名で保持する必要があります

于 2012-06-18T12:18:22.163 に答える
1

オプション 3 - このオプションは、レポートの視点にのみ役立つことに注意してください。

  1. データを挿入するたびDe-Normalizedに、新しいテーブルにエントリを作成します。
  2. エントリが更新されるたびに、エントリはDe-Normalized新しいテーブルで更新されます。
  3. 新しいテーブルには、従業員のすべてのDe-Normalized列が含まれます。
  4. そのため、検索の実行中に、結果が を使用せずに計算されるため、これは役に立ちますJoins。したがって、アクセス時間が短縮されます。
  5. 新しいテーブルのレコードは、挿入/更新トリガーで作成/更新されます。

オプション 2 およびオプション 1 の改善

重複する列を追加して冗長性を作成しないでください。

于 2012-06-18T15:57:24.807 に答える