Модель хранилища данных подход

Question

Мы находимся в процессе создания хранилища данных о состоянии здоровья.И были дискуссии по поводу базовой структуры хранилища данных.Мне нужны ваши предложения о плюсах и минусах нижеприведенных структур.DWH будет использоваться для отчетности и исследовательских целей.Это будет хранилище данных, близкое к реальному времени, с временем ожидания около 5-10 минут.

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

модель 1 ->

Таблица встреч / посещений, имеющая общие поля (например, встречи_дата, дата прибытия, тип_обслуживания и т. д.)

, а затем можно создавать дополнительные таблицы в соответствии стипы столкновений с определенными полями столкновения: Encounter_Emergency (специфичные для чрезвычайной ситуации поля, такие как экстренная диагностика, категория сортировки и т. д.) Encounter_Inpatient Encounter_outpatient

Модель 2 -> Наличие отдельных таблиц в качестве базовых таблиц, а затем создание представления сверху, которое затемвключает все типы столкновений вместе.

Encounter_Emergency (Поля, относящиеся к чрезвычайным ситуациям, такие как экстренная диагностика, категория сортировки и т. д.) Encounter_Inpatient Encounter_outpatient

модель 3 ->

Таблица встреч / посещений, имеющая таблицувсе полеds как исходная база данных и представления создаются в соответствии с типами встречи с определенными полями встречи:

view_Encounter_Emergency view_Encounter_Inpatient view_Encounter_outpatient

эти представления могут быть дополнительно объединены с таблицей emergency_diagnosis для получения диагноза или emergency_alertsтаблица для доступа к оповещениям и т. д.

Answer 1

Главным соображением будет то, как часто будут добавления, удаления или изменения в типах встреч.

Модель B потребует обширной доработки перед любыми такими изменениями только для того, чтобы обеспечить сбор данных.Любая из двух других моделей будет продолжать собирать пересчитанные данные, но для их обработки потребуется доработка.

Как между A и C, вопрос становится трафиком.Представления сравнительно легко вращаться вверх / вниз, но они будут загружать эту большую базовую таблицу.Это может быть приемлемо, если на DW не будет тонны нагрузки.Но если будет расширенная отчетность ( Pro Tip всегда будет всегда более обширная отчетность, чем обещает бизнес), может быть выгоднее разбить данные на отдельныестолы.

Конечно, есть издержки ETL на ведение всех этих таблиц.

Для скорости доставки, возможно, создайте Модель C, но разработчик Модель A в случае, если потребление требует более надежной модели.Для записи вы можете создать представления, которые не имеют префикса vw_ или какого-либо другого идентификатора в своих именах, который позволяет пользователям знать, что они являются представлениями.Затем позже вы можете заменить их таблицами с тем же именем, и устаревшие запросы к старым представлениям продолжат работать.Я сделал то же самое в противоположном направлении, пробираясь в представлениях, чтобы заменить избыточные таблицы.