- Вопрос или проблема
- Ответ или решение
- Основные понятия и теоретический фундамент
- Теория:
- Пример:
- Ответы на ваши вопросы
- 1. Может ли две или более таблиц измерений использовать один и тот же внешний ключ из таблицы фактов?
- 2. Объединение измерений: следует ли объединять таблицы «сердце» и «печень» в одну таблицу измерений?
- 3. Как решить проблему с отсутствующими данными в таблице измерения?
- Заключение
Вопрос или проблема
У меня есть следующий дизайн схемы. Для упрощения этого примера я просто использую идентификатор пациента в качестве ключа, чтобы проиллюстрировать свой вопрос.
В моей таблице фактов есть некоторые факты, которые относятся к пациентам, и я хочу знать, у каких пациентов была проведена биопсия печени или сердца. Эти таблицы измерений относятся в целом к пациенту, а не обязательно к какой-либо отдельной строке фактов.
Однако в моей операционной системе вы должны ввести информацию в разделы печени и сердца, чтобы данные были записаны в таблицы базы данных. Таким образом, например, если для сердца не требуется ввод информации в систему, люди просто пропустят ввод информации.
Итак, вы можете видеть, что пациент 2 даже не включен в мою таблицу измерений печени, а пациент 1 отсутствует в таблице сердца.
У меня есть несколько вопросов
-
Могут ли 2 или более таблицы измерений использовать один и тот же FK таблицы фактов? Могу ли я использовать идентификатор пациента для связи обеих таблиц измерений с таблицей фактов
-
В звездной схеме, было бы лучше просто объединить таблицы измерений сердца/печени в одну? Я понимаю, что это полностью мое решение, но мне интересно, есть ли правило или лучшая практика, согласно которой, если один и тот же ключ может связывать 2 разные таблицы измерений, они действительно должны быть одной таблицей измерений.
-
Если я оставлю их отдельными и захочу вытащить данные о том, у скольких пациентов была проведена биопсия печени, я получу 2 Да, 1 Нет и 1 пустую строку (Пациент 2). Как бы я исправил это, не перенося каждого пациента в таблицу измерений печени и не делая каждую строку, кроме биопсии, NULL?
Ответ или решение
Введение в проектирование схем баз данных в звездной схеме может быть сложной задачей, особенно когда возникает необходимость правильно связать таблицу фактов с таблицами измерений, как в вашем случае. Давайте рассматривать каждый из ваших вопросов более подробно и с точки зрения профессионального подхода к проектированию базы данных.
Основные понятия и теоретический фундамент
Звездная схема – это архитектурный шаблон для организации данных в хранилищах данных, который включает одну или несколько таблиц фактов и набор связанных таблиц измерений. Таблица фактов содержит измеряемые данные, такие как продажи или транзакции, тогда как таблицы измерений предоставляют контекст для этих фактов, например, информация о клиентах, продуктах или времени.
Теория:
-
Связь между фактами и измерениями: Каждая запись в таблице фактов связана с таблицами измерений с использованием внешних ключей. Обычно каждая таблица измерений представляет собой отдельный аспект бизнес-домена, например пациенты, процедуры или временные периоды.
-
Взаимосвязь между измерениями: Каждая таблица измерений часто содержит уникальный первичный ключ, который затем ссылается на внешние ключи в таблице фактов, и обычно таблицы измерений не напрямую связаны друг с другом в звездной схеме.
Пример:
Например, представьте таблицу фактов «Медицинские процедуры», содержащую данные о процедурах, проведенных пациентам — «пациент ID», «идентификатор процедуры», «дата процедуры». Связанные таблицы измерений могут включать «Пациенты», «Типы процедур» и «Календарь».
Ответы на ваши вопросы
1. Может ли две или более таблиц измерений использовать один и тот же внешний ключ из таблицы фактов?
Теория: Да, в звездной схеме возможно, чтобы две или более таблиц измерений использовали один и тот же внешний ключ из одной таблицы фактов. Это не противоречит основным принципам проектирования в звездной схеме.
Пример: Если у вас есть таблицы измерений «Лечебное сердце» и «Лечебная печень», обе они могут содержать «пациент ID» в качестве внешнего ключа, связанного с таблицей фактов «Процедуры».
Применение: В вашем случае вы можете присвоить «пациент ID» в обоих измерениях, что обеспечит возможность получить две отдельные измерения пациента, если данные о обеих процедурах (сердце и печень) доступны в вашей системе.
2. Объединение измерений: следует ли объединять таблицы «сердце» и «печень» в одну таблицу измерений?
Теория: Решение объединять или изолировать измерения зависит от целей анализа, требований бизнеса и особенностей данных. Вообще, объединение измерений может быть логичным, если они имеют схожие атрибуты и используются для одинаковых анализов.
Пример: Если таблицы «сердце» и «печень» имеют много общих полей, таких как дата процедуры, тип процедуры и врач, то объединение может упростить структуру схемы, уменьшая количество таблиц и связей.
Применение: Объединение возможно в целях упрощения анализа, например, если вы проводите исследования, касающиеся общего состояния здоровья пациентов. Но это будет значить, что анализ ограничится данными, которые существуют для обоих видов процедур, что может не всегда быть желательным.
3. Как решить проблему с отсутствующими данными в таблице измерения?
Теория: Одним из распространенных методов работы с пропущенными данными является использование так называемых «псевдозаписей», которые представляют собой строки, заполняемые нулевыми или стандартными значениями. Это позволяет представлять данные, где информация отсутствует.
Пример: В вашем случае можно вставить строки с уникальными идентификаторами пациентов, где процедура отсутствует, оставляя соответствующие атрибуты null или с помощью специального значения, такого как «не проведена».
Применение: Вы можете добавить строки для всех пациентов в таблицы измерений «Лечебное сердце» или «Лечебная печень», чтобы обеспечить целостность данных. Черта «не проведена» может быть полезной для дальнейшего анализа наличия или отсутствия информации.
Заключение
Правильное проектирование звездной схемы играет ключевую роль для обеспечения эффективности анализа данных и формирования логически связанного хранилища данных. Ваша задача как архитектора – балансировать между нормализацией данных и простотой четырехзвездной структуры, чтобы достичь наилучших результатов для вашего бизнеса. Такие решения должны всегда быть основаны на требованиях анализа, технических ограничениях и бизнес-процессах организации.