Пространственное моделирование несколько вопросов

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

1) возможность сообщать о претензиях пациента по специальности и поставщику услуг (ежемесячно, ежеквартально и ежегодно)

2) претензии от направляющего поставщика к поставщику услуг

3) требования по полученным ежемесячным платежам по (1) и (2)

4) претензии по месяцам оказания услуг по (1) и (2)

Вот модель dimsion:

Заявления о фактах

Сумма платежа

Сумма платежа

Ключ даты обслуживания (FK)

Ключ даты платежа (FK)

Ключ пациента (FK)

Ключ поставщика услуг (FK)

Ключ объекта (FK)

Ключ рекомендованного провайдера (FK)

Таблицы размеров:

DimServiceProvider ServiceProviderID (SK)

Имя поставщика услуг

Специальность

DimPatient PatientID (SK)

Имя

Адрес

DimDate

DimFacility FacilityID (SK, PK)

Название объекта

ОбъектРегион

FacilityState

Вопросы: 1) Следует ли мне разделять таблицы фактов для сборов и платежей?

2) Не уверен, правильно ли я думаю о ключе указанного поставщика (который также указывает на DimServiceProvider)

3) Есть ли какое-то практическое правило объединить некоторые таблицы измерений или разделить их? каковы правила объединения таблиц измерений или разделения их?


dimensional-modeling data-modeling
person priceline    schedule 30.06.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Отдельные платежи и сборы зависят от того, какие отчеты вы собираетесь создавать. Кроме того, рассматривали ли вы выплаты / сборы по страховке, по вторичному страхованию, если применимо, и пациенту / лицу, ответственному за пациента?

Если вы сохраняете ключ рекомендованного провайдера, вы должны указать специальное значение для пациентов, которые сами назначают его.

В вашей модели нет измерений, которые можно было бы рассматривать для консолидации.

person Olaf    schedule 30.06.2011
comment
Хороший вопрос. Итак, если мне нужно получить информацию о страховании, я, вероятно, могу добавить столбец (DimSourcePaymentKey FK) в таблицу фактов и добавить новую таблицу измерений DimPaymentSource? Что касается самонаправленных пациентов, я могу добавить referProvider в таблицу DimServiceProvider и оставить идентификатор таким же для самонаправленных пациентов? - person priceline; 30.06.2011
comment
Также в соответствии с требованиями 1-4, следует ли мне хранить платежи и сборы отдельно или объединить их? За посещение может взиматься одна плата, но может взиматься несколько платежей (первичное, вторичное страхование и личные платежи). - person priceline; 30.06.2011
comment
@priceline: В случае первичного / вторичного страхования / самостоятельной оплаты вам может потребоваться отдельная оплата. Вы должны выставить счет одной или двум страховым компаниям и пациенту / ответственному лицу. Страховая компания может отклонить ваше требование, но пациент оплатит свою часть. Вы должны это отслеживать. Или страховая компания (-а) заплатит, но пациент окажется бездельником, и вам придется продать его долг коллекторскому агентству. Которые вы также можете захотеть сохранить в своем хранилище данных. - person Olaf; 30.06.2011
comment
Как мне отслеживать эти изменения? Должен ли я добавить 6 дополнительных полей в таблицу фактов? Как (PrimaryInsuranceCharge, SecondaryInsuranceCharge, SelfPaymentCharge, PrimaryInsurancePayment, SecondaryInsurancePayments и SelfPayment? Также TotalCharge и TotalPayment - person priceline; 30.06.2011
comment
@priceline: Это действительно зависит от отчетов, которые вы собираетесь запускать. Я как бы надеюсь, что тесная взаимосвязь между начислениями и платежами, связанными с услугой / посещением, отслеживается в ваших операционных данных. Вам нужно загрузить в хранилище только данные, достаточные для составления отчетов. На этом этапе вам может потребоваться опросить потребителей ваших данных. - person Olaf; 30.06.2011