1

患者の仮想コホートの生理学的特性 (収縮期血圧、トリグリセリド濃度など) のパラメトリック記述を格納するデータベース テーブルを作成する必要があります。

たとえば、ユーザーが SBP の三角分布を指定すると仮定すると、最小値、最大値、最頻値 (および分布タイプ) を保存する必要があります。別の方法として、平均値と標準偏差の保存を必要とする正規分布を指定することもできます。

これらのデータを正規化する正しい方法に苦労しています。現在、次のように多数の 1 対 1 の関係を持つ Cohort テーブルと Distribution テーブルがあります (一部のフィールドは省略されています)。

    コホート
        id (INT、NOT NULL、プライマリ)
        名前 (TEXT、NOT NULL)
        コメント (テキスト)
        systolic_blood_pressure_dist (Distributions.id を参照する外部キー)
        triglyceride_dist (Distributions.id を参照する FOREIGN KEY)
        ...その他の生理学的パラメーター

    ディストリビューション
        id (INT、NOT NULL、プライマリ)
        配布タイプ (TEXT)
        最小 (FLOAT)
        最大 (FLOAT)
        平均 (FLOAT)
        モード (FLOAT)
        sd (フロート)
        ...その他の分布パラメータ (アルファ、ベータ、形状、スケールなど)

(distribution_type は、分布を説明する文字列を保持します: "Triangular"、"Weibull" など)。

Distributions の各行に NULL フィールドが大量に残っているため、これが最適な方法ではないことは確かです。

私のもう1つの考えは、分布タイプごとに個別のテーブル（三角形用、ガウス用、均一用など）を作成し、中央にid列（コホートの外部キーとして使用される）を持つテーブルを作成することでした。テーブル *_dist 列)、適切な分散テーブルに行の外部キーを格納するための分散型列と id 列。

クエリは、Cohort 列に格納されている ID を使用して、中央のテーブルから分散タイプと行 ID を検索し、ID を使用して適切なテーブルのパラメーターを検索します。ただし、文字列を使用して適切なテーブルを選択し、別の ID を使用して適切な行を選択することは、従来の JOIN とはかけ離れており、あまりクリーンなアプローチとは思えません。

それで、これを最もよく達成する方法（正規化および/またはパフォーマンスの観点から）に関する提案はありますか？

どうもありがとう、リッチ

4

5 に答える 5

1 
Cohort
    id (INT, NOT NULL, PRIMARY)
    name (TEXT, NOT NULL)
    comments (TEXT)

Parameters
    id (INT, NOT NULL, PRIMARY)
    name (TEXT, NOT NULL) ("systolic blood pressure", "trygliceride", ...)

CohortParameters
    id (INT, NOT NULL, PRIMARY)
    cohort_id (FOREIGN KEY referencing Cohort.id)
    parameter_id (FOREIGN KEY referencing Parameters.id)
    value (TEXT)

DistributionTypes
    id (INT, NOT NULL, PRIMARY)
    name (TEXT, NOT NULL) ("Triangular", "Weibull", ...)

Distributions
    id (INT, NOT NULL, PRIMARY)
    distribution_type_id (FOREIGN KEY referencing DistributionTypes.id)
    cohort_id (FOREIGN KEY referencing Cohort.id)
    parameter_id (FOREIGN KEY referencing Parameter.id)
    minimum (FLOAT)
    maximum (FLOAT)
    mean (FLOAT)
    mode (FLOAT)
    sd (FLOAT)
    ...other distribution parameters (alpha, beta, shape, scale, etc.)
于 2009-08-09T16:59:33.740 に答える
0

あなたの設計は、測定された情報の項目ごとに単一のタイプの分布データしか存在できないことを示しているようです。あなたの設計では、「収縮期血圧」などの「均等分布」と「三角分布」の両方のデータを持つことは不可能に思えます。

これは、個々の「測定情報」ごとに、システム設計時に、どのような分布データが利用可能かを事前に知っていることを示しているようです。

これは、これらの異なる種類のディストリビューションを単一のコレクションに集める必要がまったくないことを示しているようです (リレーショナルの観点からは、そうするのはまったく悪いことです)。余分な「配布タイプ」列。

編集

「分布タイプの列も、異なる分布の生理学的パラメーターを持つ 2 つ以上のコホートがデータベースに存在するとすぐに必要になります。」

それはがらくたのようです。個別のコホートは個別の分布測定 ID を保持し、個別の分布測定 ID は、独自の設計によって異なる分布タイプにすることができます。

于 2009-08-09T21:46:00.370 に答える
0

分布の種類ごとにテーブルを作成するという考えは、おそらくあなたが望むものです。そうすれば、配布タイプに固有の必要な各値を含む明確に定義されたテーブルが得られます。これにより、スペースが節約され、どのフィールドが null 可能で、どのフィールドがそうでないかを特定できるため、パフォーマンスが向上します。各ディストリビューションに共通のパラメーター セットがある場合は、テーブルをスーパータイプ/サブタイプの関係に配置して、スキーマをさらに正規化できます。

于 2009-08-09T17:02:36.327 に答える
0

クエリを実行するときにデータをどのように使用しますか?

多数のコホートをクエリしており、コホートの分布が異なることが合理的である場合、結果は「ユニオン」になり、実際には多くの列が null になります。その場合、結果はある意味で「正常ではない」ですが、それはスキーマがそうあるべきだという意味ではありません。

分布の種類ごとに異なるテーブルを使用する利点は、各テーブルが、その分布を記述するために入力する必要がある列を明示的に定義することです。その後、一部の列を「null 以外」に設定することもできます。

私はあなたの提案の一般的な考え方が好きです。

于 2009-08-09T17:03:37.493 に答える
0

さまざまな分布タイプに個別のテーブルを用意するのは、私にはぴったりのように思えます。アプリケーション ロジックでは、UI での異なるレンダリングや異なる計算が必要になる可能性があるため、とにかく (私は推測します) 各ディストリビューション タイプを特殊なケースにする必要があります。

于 2009-08-09T17:00:00.403 に答える