1

私は次の問題に直面しています。

私は（たとえば）人間の情報のためのデータベースを作成しています。すべての人間は、成人女性、成人男性、子供という3つのカテゴリのいずれかに分類できます。「身長」や「体重」などのパラメータがすべてのカテゴリに適用できることは明らかです。パラメータ「子供の数」は大人にのみ適用され、パラメータ「妊娠の数」は女性にのみ適用されます。また、各パラメーターは、カテゴリーに応じて必須またはオプションに分類される場合があります（たとえば、成人の場合、パラメーター「元パートナーの数」はオプションです）。

「height」と「weight」をロードするとき（たとえば）、これら2つのフィールドの情報に一貫性があるかどうかを確認します。つまり、高さ= 6'4''、重量= 10ポンドのレコードを間違いとしてマークします（明らかに、これは物理的に不可能です）。同様の検証ルールがいくつかあります。

人間に関するレコードを挿入するときは、情報の次の特性を反映する必要があります。

  1. この特定の人間のカテゴリについて可能な最大の情報（すべてのオプションのパラメータを含む）。
  2. カテゴリに必要な最小限の情報（つまり、必須フィールドのみ）
  3. この特定の人間のために実際に挿入されたもの（つまり、必要な最小限の情報の量よりも少ないかどうかに関係なく、この人のために私が持っているものは何でも挿入できます）。ここでの重要な問題は、フィールド「XXX」に何も挿入したことがないため、または意図的に正確にNULL値を挿入したために、フィールド「XXX」にNULL値が含まれる可能性があることです。デフォルト値を持つフィールドと同じロジック。したがって、私がこの特定のフィールドを処理したことをどこかに反映する必要があります。
  4. 挿入された情報の量が検証されました（つまり、5つのフィールドをロードしても、残りの2つを無視して、3つのフィールドのみの自己整合性をチェックできます）。

だから私の質問は、それを技術的に整理する方法です。現在、これらの必要な機能はすべて、統合ロジックなしでハードコーディングされているか、完全に独立したブロックに分割されています。統一されたアプローチを作成する必要があります。

この点に関して、私は頭の中にいくつかの素朴な考えを持っています。たとえば、人間のカテゴリごとに、可能なフィールドのリストを作成して保存できます（これを「テンプレート」と呼びます）。Aは、必須のフィールドにマークを付けることができます。

人間に関するレコードを挿入するときは、テンプレートをコピーして、このテンプレートのどのフィールドが実際に処理されたかをマークします。次の段階で、このテンプレートのコピーに、現在検証されるフィールドをマークできます。

検証モジュールは、次のように特別に修正されます。検証手順ごとに、この特定の検証手順で使用されているフィールドのリストを作成します。次に、検証対象の特定の人間のテンプレートのコピーで実際に「検証対象」とマークされているフィールドを持つ検証手順のみを呼び出します（前の節を参照）。

ご覧のとおり、これはこの問題を解決するための最も簡単な方法です。しかし、私の推測では、私が気付いていない非常に標準化されたアプローチがたくさんあります。私がこのような問題を解決したのは世界で初めてだとは本当に思えません。レコードで発生するすべての「更新」をこのコピーされたテンプレートに正しく反映するコードを記述するのは非常に苦痛なので、私のソリューションは好きではありません。

ですから、この問題をどのように解決していくのか、ご意見をお聞かせください。

4

3 に答える 3

2

ここには2つの質問があると思います。

  • ポリモーフィックデータをデータベースに保存するにはどうすればよいですか？
  • 複雑なビジネスルールを検証するにはどうすればよいですか？

それらに別々に対処する必要があります-両方を同時に解決しようとするのはおそらく難しすぎます。

RDBMSのポリモーフィックデータにはいくつかのアプローチがあります。たとえば、ORMは継承マッピングという用語を使用します。ここでの3つのソリューション（クラス階層ごとのテーブル、サブクラスごとのテーブル、および具象クラスごとのテーブル）は、「純粋な」リレーショナルソリューションです。「Entity-Attribute-Value」デザインを使用することも、ドキュメントアプローチ（XMLやJSONなどの構造化された形式でデータを保存する）を使用することもできます。これらは「純粋な」リレーショナルオプションではありませんが、代わりに使用できます。

複雑なビジネスルールの検証は、多くの場合、ルールエンジンを使用して行われます。これらは非常に優れたテクノロジーですが、問題がソリューションに本当に適合していることを確認する必要があります。ルールエンジンに投資することを決定すると、プロジェクトがルールエンジンプロジェクトに変更されます。 、「人間」プロジェクトではありません。あるいは、これに対するほとんどの主流のソリューションは、アプリケーションのビジネスロジック層のエンティティに関するビジネスロジックを具体化します。あなたはこれを超えているように聞こえます。

于 2013-03-26T18:40:54.093 に答える
1

この正確な問題は、健康の観点からも金融商品の観点からも、MartinFowlersの著書AnalysisPatternsの主要な例として使用されています。それは広範なトピックです。@NevilleKが言うように、あなたは2つの質問に対処しようとしているので、それらを別々に処理するのが最善です。これらの問題に取り組む非常に単純化された方法の1つは次のとおりです。

1ポリモーフィックデータの保存-カテゴリに共通の必須データのみをカテゴリテーブルに配置します。オプションのデータの場合、これらをカテゴリテーブルと1-1の関係で別のテーブルに配置します。記録する値がある場合にのみ、これらのオプションのテーブルにエントリが作成されます。データの検証の記録は、これらの追加のテーブルに入れることもできます。

2複雑なビジネスルールを検証します-発生する可能性のあるエラーの種類を検討すると便利です。エラーを分類する方法はいくつかありますが、私が最も役立つと思ったのは、（a）データを見るだけで値がエラーであることがわかるタイプエラーです（例：1980-02-30）。（b）以前にキャプチャされた日付を参照することによってのみエラーを検出できるコンテキストエラー-たとえば、DoB 1995-03-15、結婚日1996-08-26。（c）システムにあります-データ型は問題ありません。コンテキストは問題ありません。しかし、情報が不正確であると検出できるのは、後日、より多くの情報が明らかになったときです。たとえば、DoBを1990-12-31として登録した場合、それが何か別のものになります。この後者のクラスのエラーは、通常、開発中のシステム外の手順で処理する必要があります。

于 2013-03-26T20:16:11.817 に答える
0

パーティーロールパターン（シルバーストン）を使用します：

Party
id
name

Individual : Party
current_weight
current_height

PartyRole
id
party_id
from_date
to_date (nullable)

AdultRole : PartyRole
number_of_children

FemaleAdultRole : AdultRole
number_of_pregnancies

Postgresには一時的な拡張機能があり、パーティが一度に1つの役割しか果たせないように強制できます（ただし、役割の履歴は維持されます）。

テーブルの継承を使用します。簡単にするために、単一テーブル継承（nullがある）を使用します。nullがない場合は、クラステーブル継承を使用します。

于 2013-03-26T19:24:44.857 に答える