1

私は最初にEntityFrameworkコードを利用するWebアプリ（MVC）に取り組んでおり、これをモデル化する方法を理解しようとしています。クラス（データベース内のビット）に15個のブール値を追加することは確かにできますが、それはそれを回避するための哀れな方法のようです。現在、下の画像に示されているポリシーのオブジェクトを含む顧客オブジェクトがあります。

ここに画像の説明を入力してください

私の見解を上記のように見せたいので、現在6番目を追加する予定はありませんが、その可能性をサポートするようにモデルを設計することが重要です。

public class customer{
   //some random properties like Id, Name, Owner, Etc.
   //I could put 15 bools here for the policies in the image
   //I could put a policy object here?
}
4

4 に答える 4

2

これは、シンプルで、自己記述的で、スケーラブルで、正規化され、拡張可能な設計です。システムを再コンパイルせずに、ポリシー タイプまたは患者タイプを追加できます。使用しているデータベース エンジンを指定していないため、ほとんどのデータベース プラットフォームで動作させるために、TPCを使用することをお勧めします。

ダイアグラム

患者は、システム内で人 (別名パーティー) が果たす単なる役割です。「医師」、「従業員」、「保険契約者」など、それぞれ独自のデータを持つ他の役割を持つことができます。役割は一時的なものであることに注意することが重要です。つまり、その人がシステム内で他の役割を実行している間、1 つの役割を無効にすることができます。

「既存」、「AgeIn」、「NewPatient」が Role または Party のプロパティを調べることで判断できる場合、PatientType は必要ありません。忍耐の種類がどのように定義されているかが不明なため、追加しました。それを定義するために、Patient にプロパティを設定するだけでよいでしょう。

当事者は、任意の法人を表します。当事者には、ビジネスにとってしばしば重要な関係があります。したがって、「サム」（人）が「ドクター」（役を演じている人）のところに来るとき、彼女のお父さんボブ（人）の「方針」が請求書を支払うことになることを知ることが重要です. したがって、Person が別のテーブルにマップされる理由です。

PolicyType は、ポリシーが実際にどのタイプのポリシーであるかを定義します。あなたの場合、ExistingOriginalMediCare、AgeInOriginalMediCare など、18 の異なるポリシー タイプがあるとします。これは、ポリシーの「ルール」に影響を与えるデータを保存できる場所です。たとえば、一部の種類のポリシーは、カリフォルニア州に住む人々のみが利用できます。私が取り組んだ 1 つのシステムには、アプリケーションがビジネス ルールを推測するために使用する数百のプロパティを持つ数千のポリシー タイプがありました。これにより、企業は、システムとそれに依存するすべてのものを再コンパイルすることなく、新しいポリシー タイプと「ルール」を作成できました。

ただし、同じ機能を維持しながら継承を削除することで、単純化できます。ここでは、「患者」以外に「役割」はなく、「人」以外に「当事者」は存在しないものとします。

簡略化されたモデル

とは言っても、データが他のアプリケーションによって再利用されるかどうか、および一時的なデータと関連付けが実際にどのように行われるかによって異なります。自由に適応してください。システムを設計するときは、次の本をよく参照します。

  1. エンタープライズ パターンと MDA: アーキタイプ パターンと UML を使用してより優れたソフトウェアを構築する
  2. エンタープライズ モデル パターン: 世界の記述 (UML バージョン)
  3. The Data Model Resource Book, Volume 3: データ モデリングのユニバーサル パターン

それらは、私の「データ」の見方を根本的に変えました。

于 2012-04-06T02:24:09.867 に答える
1

あなたのデータ要件については完全にはわかりませんが、次のように、1 つまたは 2 つのテーブル内でシンプルに保ちたいと思います... 

public class Customer
{
    public int CustomerID { get; set; }
    // or implement it via enum like below for policy type
    public bool Existing { get; set; }
    public bool AgeIn { get; set; }
    public bool New{ get; set; }
    // no 'virtual' means it's 'required', with virtual could be 'null'
    public Policy Policy { get; set; }
}
public enum PolicyBits
{
    None = 0x00,
    ExistingOriginalMediCare = 0x01,
    // ...
    AgeInOriginalMediCare = 0x100,
    // ...
}
public class Policy
{
    public int PolicyID { get; set; }
    public int PolicyTypeValue { get; set; }
    [NotMapped]
    public PolicyBits PolicyType
    {
        get { return (PolicyBits)PolicyTypeValue; }
        set { PolicyTypeValue = (int)value; }
    }
}

...列挙型は「ビット」の数を減らすのに役立ちます-しかし、それはまだ正式にサポートされておらず、次のバージョンからのものであり、これまでのところ実験的なVS 2011および.NET 4.5でのみサポートされます(私が思い出したように)。

ただし、以下のような方法で一時的に回避できます。

テーブルのモデルについては、既存のユーザー、新規ユーザー、または年齢の高いユーザーの間でどのように「切り替え」たいのかわかりません。または、両方または3つすべてを同時に持つことができますかなど.すべてがビットであるため、私は1つのフィールドで十分だと考えています-そして、おそらくそれを別のテーブルに入れて、ほとんどを分離します-つまり、それを再定義したり、新しいものを追加したり、新しいレコードを導入したりできます.

于 2012-04-06T00:01:36.037 に答える
1

これについては、 TPT (Table Per Type) を参照してください。-in-entity-framework.aspx

これは、基本テーブルを拡張するこれらのさまざまな概念のそれぞれについてテーブルを持つことができることを意味します。この方法の利点は、後で特定のタイプに追加情報を追加できることです。

たとえば、customer がルート テーブルになり、OriginalMedicareCustomer などの概念で拡張されます。

于 2012-04-05T23:26:52.587 に答える
1

正規化する場合は、次のようにすることをお勧めします。

public class Customer {
  // id, name, owner, etc
  public virtual IList<CustomerPolicy> Policies { get; set; }
}

public class CustomerPolicy {
  // id, name, etc
  public bool ExistingPatient { get; set; }
  public bool AgeInPatient { get; set; }
  public bool NewPatient { get; set; }
}

あなたのアプリケーションについて詳しく知らなければ、何とも言えませんが、各ポリシーの 3 つのブール値は相互に排他的だと思いますか? もしそうなら、私は代わりに次のようなことをします：

public enum PatientType { Existing, AgeIn, NewPatient };

public class CustomerPolicy {
  // id, name, etc
  public PatientType PatientType { get; set; }
}
于 2012-04-05T23:29:03.253 に答える