Правильная нормализация базы данных с необязательными столбцами

Question

Мне нужно создать таблицу базы данных, в которой будут храниться параметрические описания физиологических характеристик (например, систолическое артериальное давление, концентрации триглицеридов и т. Д.) Гипотетической когорты пациентов.

Например, если пользователь задает треугольное распределение для SBP, то минимум, максимум и режим (и тип распределения) должны быть сохранены. В качестве альтернативы пользователь может указать нормальное распределение, требующее хранения среднего значения и стандартного отклонения.

Я борюсь с правильным способом нормализации этих данных. В настоящее время у меня есть таблица Cohort и таблица распределения с несколькими отношениями один к одному, как показано ниже (некоторые поля пропущены):

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

(тип_распределения содержит строку, описывающую распределение: "Треугольный", "Вейбулл" и т. Д.)

Я почти уверен, что это не оптимальный способ сделать это, так как у меня осталось множество пустых полей в каждом ряду Распределений.

Моя другая мысль заключалась в том, чтобы иметь отдельные таблицы для каждого типа распределения (одну для треугольной, одну для гауссовой, одну для равномерной и т. Д.) И иметь таблицу в середине со столбцом id (для использования в качестве внешнего ключа). в таблице Cohort * столбцы _dist), столбец типа распределения и столбец id для хранения внешнего ключа для строки в соответствующей таблице распределения.

Запрос будет использовать идентификатор, хранящийся в столбце «Когорта», чтобы найти тип распределения и идентификатор строки из средней таблицы, а затем найти параметры в соответствующей таблице, используя идентификатор. Однако при использовании строки для выбора соответствующей таблицы другой идентификатор для выбора соответствующей строки далек от традиционного JOIN и также не выглядит очень чистым подходом.

Итак, есть ли у кого-нибудь предложения относительно того, как наилучшим образом добиться этого (с точки зрения нормализации и / или производительности)?

Большое спасибо, Рич

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

Ваш дизайн, кажется, указывает, что может быть только один тип данных распределения на единицу измеренной информации. В вашей схеме кажется невозможным иметь как «равномерное распределение», так и «треугольное распределение», скажем, о «систолическом артериальном давлении».

Похоже, это указывает на то, что для каждого отдельного фрагмента "измеренной информации" вы уже заранее знаете, во время разработки системы, какие данные о распределении доступны.

Это, в свою очередь, указывает на то, что нет необходимости в том, что когда-либо (а с точки зрения отношений это совершенно нехорошо) собирать эти различные виды распределения в одну коллекцию, только для восстановления любых необходимых различие путем добавления лишнего столбца «тип распределения».

EDIT

«Столбец типа распределения также становится необходимым, как только в базе данных есть две или более когорты с физиологическими параметрами с различным распределением.»

Это кажется дерьмом. Разные когорты содержат различные идентификаторы измерения распределения, а различные идентификаторы измерения распределения могут быть разных типов распределения в зависимости от вашей собственной конструкции.

Answer 3

Как вы будете использовать данные при запросе?

Если вы запрашиваете несколько когорт, и для когорт разумно иметь разные распределения, тогда ваш результат будет "объединением", где действительно много столбцов будут нулевыми. В этом случае ваши результаты в некотором смысле «ненормальные», но это не означает, что схема должна быть.

Преимущество наличия разных таблиц для разных типов распределений состоит в том, что каждая таблица будет явно определять столбцы, которые должны быть заполнены для описания этого распределения, вы даже можете установить для некоторых столбцов значение "не нуль".

Мне нравится общая идея вашего предложения.

Answer 4

Ваша мысль иметь таблицу для каждого типа распространения, вероятно, то, что вы хотите. Таким образом, у вас есть четко определенная таблица с каждым необходимым значением, специфичным для вашего типа распространения. Это сэкономит ваше пространство, позволит вам заблокировать, какие поля можно обнулять, а какие нет, и приведет к повышению производительности. Если у каждого дистрибутива есть общий набор параметров, вы можете расположить таблицы в отношениях супертип / подтип для дальнейшей нормализации схемы.

Answer 5

Наличие отдельных таблиц для разных типов дистрибуции звучит как раз для меня. В вашей логике приложения вам, во всяком случае, придется учитывать особый случай каждого типа распределения, так как для этого может потребоваться другой рендеринг в пользовательском интерфейсе или другие вычисления.