固定列とキー値のペアのメタデータのペアを作成するには？

Question

複数の支社の複数の出席者からの勤務時間データを格納するテーブルを作成するように求められました。この表は高レベルのレポート作成に使用されるため、基本的に各システム（存在する可能性がある）ごとに表を作成し、最終製品の内容に直接移動する手順はスキップしています。

要求は、時間の各タイプのディメンションを持っているかのように支払うことだった：

date  | employee_id | type   | hours | amount 
2016-04-22  abc123  regular   80  3500 
2016-04-22  abc123  overtime   6  200 
2016-04-22  abc123  adjustment  1  13 
2016-04-22  abc123  paid time off  24  100 
2016-04-22  abc123  commission     600 
2016-04-22  abc123  gross total    4413 

あり、従業員ごとに複数の行があるが、しかしプロセスは、これが彼らならば、私たちは新しい次元をキャプチャできるようになるということですが加えられる。

データはいくつかのソースから来ていますが、私はETLについて心配しないように言われましたが、究極のテーブルを設計してどのシステムでも機能させるように言われました。それらを記入するために我々は他の人にこのフォーマットを提供する

私はそれのように一つのシステムからの生データを見ています。

date | employee_id | gross_total_amount | regular_hours | regular_amount | OT_hours | OT_amount | classification | amount | hours 

それはかなり厄介です。従業員の複数行とgross_totalなどの値は、各行を繰り返します。 PTO（有給休暇）、調整、空の値、手数料などの項目を持つ分類列があります。繰返し値のため、単にデータを合計してgross_total_amountに等しくすることはできません。

とにかく、私は、各行が休暇を取った従業員の時間を表す列ベースの方法をとっているのが好きです。私もそのようにフォーマットされたデータにより使用されています

date | employee_id | gross_total_amount | commission_amount | regular_hours | regular_amount | overtime_hours | overtime_amount | paid_time_off_hours | paid_time_off_amount | holiday_hours | holiday_amount 

：一つの問題は、私はので、私は必ずしもようにテーブルを作成することはできません可能な時間の可能性のある種類のすべてを知っていないということです。懸念事項は、必要な列をすべて取得できない場合や、新しいものが追加された場合です。 （例えば、出産休暇、父親休暇、死別休暇、その他の地域には夜間の労働に関する法律などがあります）

アドバイスはありますか？私の上司から私に示唆されたテーブルは実行可能な解決策ですか？

Answer 1

私が基本的な仕事であると理解していることを繰り返します。

異なるソースから、構造が異なるデータを取得します。あなたの仕事は、これらのすべてのデータに関する質問に答えるために単一のデータベースにそれらを統合することです。 「ETLについて心配しないで、究極のテーブルを設計する」というヒントを理解しているのは、統合データベースに元のデータに存在する可能性のあるすべての詳細情報が含まれている必要はなく、統合データベースに対する特定の要件を満たしていること。

あなたの上司がこれらの要件について十分に確信している限り、これは賢明です。その場合、各ソースから統合された構造に送られる情報を減らします。

いずれにせよ、各ソースからのデータのドメインセマンティクスをキャプチャする必要があります。あなたのドメインのセマンティクスへのアクセスが不足している、私はあなたのための反復値の混乱を明確にすることはできません。たとえば、詳細レコードと総計レコードがある場合、実際の作業時間の2倍の時間がかかるため、すべてのレコードの時間を追加するのは間違いです。だから誰かがETLについて心配する必要があります。つまり、従業員のためのすべてのエントリと1営業日で構成されたレコードの各セットを解釈し、その意味を見つけ出し、それらを統合構造に変換します。

質問の別の部分はメタデータの使用についてのことです。休暇や出産休暇のような考え方には異なる列を持つことができます。また、これらの概念をキーと値のペアとして含むメタデータテーブルを持ち、メインテーブルのキーを参照することもできます。あなたのデータベースを再設計することなく、父親の休暇のような新しいタイプを導入することができるので、メタデータの方法はよりフレキシブルであると称賛されることがあります。ただし、新しいタイプを使用するためには、ソフトウェアのフィッティングを再設計したり、おそらくテーブルをクエリする必要があります。とにかく、新しいソフトウェアリリースを開発して展開しなければならず、テーブルにいくつかの列を追加するだけでその開発努力の一部となります。

属性としてすべての概念を含む広い表とメタデータのアプローチには大きな違いがあります。ある期間、値のすべてまたはいずれかが存在することを確認したい場合は、広範なテーブルで簡単です。すべての属性を「nullではない」にするだけです。これをメタデータ・ソリューションにすることは、使用するデータベース・システムに応じて使用可能な場合と使用できない場合がある、かなり複雑な制約を意味します。

ことが主な要件ではない場合、私は実用的な道を行くだろうと私はそうでないもののみのタイプの一握り、および独立したキーと値のテーブルを期待する場合は、別の列を使用しています。

これらのすべての考慮事項は、統合テーブルが今日知られている要件を満たす必要があることをあなたの上司の主張に依存しているため、これらの要件のために必要でない場合は元の詳細情報を自由に放棄できます。私はそのようなアサーションには注意が必要です。いくつかの情報源が追加の情報を提供していると仮定しましょう。それから誰かがこの情報を含んでいる報告書をどこかに尋ねることは、おそらく起こりそうです。あなたのデータ構造が今日必要なものだけを含んでいれば、これは不可能です。

これに対処する2つの方法、つまり将来のニーズに対応する方法があります。各追加ソースからのデータを知った後、統合データベースを拡張してそこから来るすべてのデータ構造をカバーすることができます。これは、さまざまなソースが異なるデータを使用して同じ概念を表現する可能性があるため、データを匹敵させるためにそれらを統合する必要があります。また、実際の統合データベースに必要な詳細情報のすべてが実際に必要となるわけではないので、あなたの努力のすべてが問題になるわけではない可能性もあります。したがって、よりエレガントなもう1つの方法は、各ソースに対してインポートする元のデータを保持し、具体的な新しい要件の場合にのみ、データベースを拡張し、追加の詳細をカバーするためにソースからデータを再インポートすることです。ストレージの価格はそのままですが、これは最適なコスト・ベネフィット比をもたらす可能性があります。

Answer 2

TAMには多くの点があり、さらに2つの提案があります。

まず、上記のようにテーブルに偽のデータを生成し、必要なレポートを生成できるかどうかを確認します。偽のデータに基づいてマネージャーにそれぞれのレポートを表示し、偽のデータがOKであることを確認します。 （報告書は最終的な目的であると思われるので、そこから戻って作業してください）

第2に、可能な限り多くの入力システムからサンプルデータを取得することをお勧めします。これは、あなたがしなければならないことがすべてのシステムで可能であることを再確認することです。 ETLを設計したり、新しい要件を集めたりすることはできません。紙にすべてをテストするだけです（頭の中のETLを実行する）。これを使って偽のデータを更新し、新しい偽のレポートを生成し、レポートを再度チェックします。