Normalisation correcte de la base de données avec colonnes optionnelles

Question

J'ai besoin de créer une table de base de données qui stocke des descriptions paramétriques des caractéristiques physiologiques (par exemple la pression artérielle systolique, les concentrations de triglycérides, etc.) d'une cohorte hypothétique de patients. Par exemple, en supposant que l'utilisateur spécifie une distribution triangulaire pour SBP, alors le minimum, le maximum et le mode (et le type de distribution) devraient être stockés. Alternativement, l'utilisateur peut spécifier une distribution normale, nécessitant le stockage de la moyenne et de l'écart-type. Je suis aux prises avec la bonne façon de normaliser ces données. À l'heure actuelle, j'ai une table de cohorte et une table de distribution avec un certain nombre d'un à-un comme suit (certains champs omis):

 
    Cohort 
     id (INT, NOT NULL, PRIMARY) 
     name (TEXT, NOT NULL) 
     comments (TEXT) 
     systolic_blood_pressure_dist (FOREIGN KEY referencing Distributions.id) 
     triglyceride_dist (FOREIGN KEY referencing Distributions.id) 
     ...other physiological parameters 

    Distributions 
     id (INT, NOT NULL, PRIMARY) 
     distribution_type (TEXT) 
     minimum (FLOAT) 
     maximum (FLOAT) 
     mean (FLOAT) 
     mode (FLOAT) 
     sd (FLOAT) 
     ...other distribution parameters (alpha, beta, shape, scale, etc.) 

(distribution_type contient une chaîne décrivant la distribution: « Triangulaire », " Weibull ", etc.)

Je suis assez sûr que ce n'est pas la manière optimale de le faire car il me reste beaucoup de champs NULL dans chaque ligne de distributions. Mon autre pensée était d'avoir des tableaux séparés pour chaque type de distribution (un pour triangulaire, un pour gaussien, un pour uniforme, etc.) et avoir une table au milieu avec une colonne id (pour être utilisé comme un étranger clé dans les colonnes * _dist de la table de cohorte), une colonne de type de distribution et une colonne id pour stocker la clé étrangère de la ligne dans la table de distribution appropriée. La requête utiliserait l'identifiant stocké dans la colonne Cohorte pour trouver le type de distribution et l'identifiant de ligne de la table du milieu, puis rechercher les paramètres dans la table appropriée en utilisant l'ID. Cependant, en utilisant une chaîne pour sélectionner la table appropriée, alors un autre identifiant pour sélectionner la ligne appropriée est loin d'un JOIN traditionnel et ne semble pas non plus être une approche très propre.

Alors, est-ce que quelqu'un a des suggestions sur la meilleure façon d'y parvenir (en termes de normalisation et/ou de performance)?

Un grand merci, Rich

Answer 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.) 

Answer 2

Avoir des tables séparées pour les différents types de distribution sonne juste pour moi. Dans votre logique d'application, vous devrez de toute façon caser chaque type de distribution, de toute façon (je présume), car il peut avoir besoin d'un rendu différent dans l'interface utilisateur, ou de différents calculs.

Answer 3

Votre idée d'avoir un tableau pour chaque type de distribution est probablement ce que vous voulez. De cette façon, vous avez un tableau bien défini avec chaque valeur dont vous avez besoin spécifique à votre type de distribution. Cela vous permettra d'économiser de l'espace, vous permettra de verrouiller quels champs sont nullables et ceux qui ne le sont pas, et entraînera une augmentation des performances. Si chaque distribution a un ensemble commun de paramètres, vous pouvez organiser vos tables dans une relation supertype/sous-type pour normaliser davantage le schéma.

Answer 4

Comment allez-vous utiliser les données lorsque vous interrogez?

Si vous interrogez un certain nombre de cohortes, et qu'il est raisonnable que les cohortes aient des distributions différentes, alors votre résultat serait une "union", où en effet beaucoup de colonnes seraient nulles. Dans ce cas, vos résultats sont en quelque sorte "pas normaux", mais cela ne veut pas dire que le schéma devrait l'être. L'avantage de disposer de tables différentes pour différents types de distributions est que chaque table définit explicitement les colonnes qui doivent être remplies pour décrire cette distribution, vous pouvez même définir certaines colonnes comme étant "non nulles".

J'aime l'idée générale de votre proposition.

Answer 5

Votre conception semble indiquer qu'il ne peut y avoir qu'un seul type de données de distribution par élément d'information mesuré. Il semble impossible, dans votre conception, d'avoir à la fois des données de «répartition égale» et de «distribution triangulaire», par exemple, de «tension artérielle systolique». Cela semble indiquer que, pour chaque «information mesurée», vous savez déjà, dès la conception du système, quel type de données de distribution est disponible. Ceci à son tour semble indiquer qu'il n'y a aucun besoin quoi que ce soit (et d'un point de vue relationnel, il est carrément mauvais de le faire) de rassembler ces différents types de distribution dans une seule collection, seulement pour rétablir toute distinction nécessaire en ajoutant une colonne "type de distribution" superflue.

EDIT

« La colonne de type de distribution devient également nécessaire dès qu'il ya deux ou plusieurs cohortes dans la base de données avec des paramètres physiologiques distribués différemment. »

Cela semble merdique. Les cohortes distinctes possèdent des identifiants de mesure de distribution distincts et les identifiants de mesure de distribution distincts peuvent être de différents types de distribution selon votre propre conception.