|
|
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Добрый день! Столкнулся с задачей, которая по всей видимости требует не очевидного решения. Хотя думаю достаточно распространена. Есть орг структура: Организация - Клиника - Отделение в отделениях есть специализации, связь многие ко многим так как в одном отделении может быть несколько специализаций, и одна специализация может быть в нескольких отделениях. Дальше еще интереснее под конкретной специализацией есть врачи, опять связь многие ко многим, т.е. к одной специализации может относиться несколько врачей, и один врач может быть в разных специализациях и соответственно работать в разных отделениях. в исходной системе есть одна табличка (назовем ее связка) которая связывает ид врача, ид специализации, ид отделения. в хранилище как я понимаю нужны таблицы bridge для организации связи между отделениями и специализациями, и еще одна между специализациями и врачами. Рассмотрим например организацию связи отделения - специализации: если таблицу bridge сделать с 2 полями ид отделения и ид специализации, то если факты будут лежать на специализации то мы не поймем по какому точно отделению они так как к специализации привязано несколько отделений. Все факты по итогу лежат на врачах, т.е. есть врач, он оказал услуги, на такую то сумму, как правильно организовать данные в таблице фактов, и связи многие ко многим чтоб можно было отследить что факт по такому то врачу был сделан по данной специализации в данном отделении, не могу понять. Хранить в таблицах бридж и фактах еще один указатель на ид из таблицы связка, чтоб точно понимать по какой специализации и отделению этот факт, но как тогда должны выглядеть таблицы измерений и таблицы bridge. Спасибо большое если поможете, завис чет с этой задачей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2017, 18:50 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Роман Логачев, на первый взгляд связь многие ко многим вам не нужна. Фактом является оказание врачом услуги. И для этого факта можно однозначно определить и врача, и отделение, и специализацию. Просто три разных измерения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2017, 23:32 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
s_ustinovРоман Логачев, на первый взгляд связь многие ко многим вам не нужна. Фактом является оказание врачом услуги. И для этого факта можно однозначно определить и врача, и отделение, и специализацию. Просто три разных измерения. Да, такой подход имеет место быть -- преимущества -- простота и удобство для конкретной задачи. Если (бы... мы точно не знаем) нужны репорты типа: сколько врачей по конкретной специальности есть в таком-то отделении или "какие врачи НЕ используют некоторые свои специализации", то тут нужно будет связки, но не как бридже а как законные факты: ФактСпециализацияВрача (по диплому, без привязки с госпиталю), ФактРасписаниеСпециалистов (конкретный человек принимает как такой-то специалист в таком-то госпитале) Повторю: дополнительные навороты нужны если они нужны по бизнез задаче... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 05:04 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Роман ЛогачевДобрый день! Столкнулся с задачей, которая по всей видимости требует не очевидного решения. ... Все факты по итогу лежат на врачах, т.е. есть врач, он оказал услуги, на такую то сумму, как правильно организовать данные в таблице фактов, и связи многие ко многим чтоб можно было отследить что факт по такому то врачу был сделан по данной специализации в данном отделении, не могу понять. ... Вам нужно уметь в бизнес-приложении или ETL определять тип услуги по факту ее оказания. То есть запись об оказании услуги должна иметь следующие атрибуты: Врач Услуга Где оказана (в каком отделении, кабинете и пр) Кому оказана По услуге вы можете определить специализацию. Это факты, и аналитика не может их синтезировать или выдумать. Что могу предложить - вы можете попробовать обогощать данные в ETL процессе как-то. Как сказали ранее, аналитика может ответить на вопрос "как работают врачи по своим специализациям" или "как связаны услуги врачей с отделениями", восстановление фактов - не задача аналитики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 09:12 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Спасибо, коллеги за ответы, но так и не пойму какое же решение задачи. Сделаю еще пару вводных, почему решил делать связи так это потому что нужно сделать иерархию вида: организация - клиника - отделение - специализация - врач для организации фильтрации параметров в отчетах и т.д. момент с организацией 3 отдельных измерений проработан и реализован уже, вопрос именно в том чтобы связать эти измерения для организации нормальной фильтрации, выбрал клинику отфильтровались, отделения, выбрал отделение отфильтровались специализации и т.д. не совсем понял про связки но не типа моста а типа законные факты, это как.. как я вижу в фактах есть услуга, врач и признак в каком отделении оказана услуга т..е. ид из таблицы связки в исходной системе, но как дальше привязывать факты к измерениям врачей, по двум ключам получается?? врач и ид признака связки ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 09:56 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Роман Логачев, сложностей на этом этапе минимум. Измерения: ОУ (образовательное учреждение можно опустить), ЛУ (лечебное учреждение), Специализация, Специалист, Дата Факты: образование, штатное расписание, услуги т.е. Специалист получил образование по Специализации в ОУ Специалист работает по Специальности в ЛУ по Расписанию(Дата) Специалист оказал услуги по Специальности в ЛУ в Дата связь m2m можно сделать между образованием и штатным расписанием и/или оказанием услуг иерархия "организация - клиника - отделение - специализация - врач" немного надумана. лучше 3 измерения "организация - клиника - отделение", "специализация", "врач" иначе 1 и тот же Специалист при наличии нескольких мест работы будет фактически разными людьми (ключ). то же самое и про Специальность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 10:42 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Роман Логачев Сделаю еще пару вводных, почему решил делать связи так это потому что нужно сделать иерархию вида: организация - клиника - отделение - специализация - врач для организации фильтрации параметров в отчетах и т.д. момент с организацией 3 отдельных измерений проработан и реализован уже, вопрос именно в том чтобы связать эти измерения для организации нормальной фильтрации, выбрал клинику отфильтровались, отделения, выбрал отделение отфильтровались специализации и т.д. ... Как ранее сказали, ваша иерархия приведет к проблемам. Лучше разбить ее на 3 измерения. У вас вопрос не по дизайну, а по среде отображения отчетов. Чтобы при выборе отделения - в списке специализаций пропали не активные. Как решить (на вашем примере) - я делал некую dummy группу мер - которая 1 для всех отделений, и привязывал ее через M2M к специализациям. Через измерения связок (отделение-код заказа и код заказа-специализация) подхода M2M и в Reporting Services - запрашивал что выбрано в иерархии (отделение). Далее - делал запрос к мере dummy связок, чтобы он выводил ненулевые строчки. Из результата ответа - формировал список специализаций. Это работало в SSRS, так как там есть механизм связанных параметров и можно сложным отразом обновлять список значений зависимого параметра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 15:03 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Роман Логачевне совсем понял про связки но не типа моста а типа законные факты, это как.. коротко: мост -- это вспомогательный элемент, вариант имплементации, его можно рефакторить факт -- основной "елемент" вокруг которого вертится бизнез задача. конкретно по теме: Если у вас есть расписание врачей и есть задача по анализу занятости врачей -- то полезно будет иметь рассписание как факт. Если таких зада4 не стоит и у вас только база посешений -- то "рассписание" можно сделать как вспомогательный бридже заполяя его только из фактов "визит к врачу" Аналогично "врачи и специальности" -- если есть независимый список и есть задачи по анализу етого списка ("работают ли врачи по своим специальности(ям)") то это скорее факт. Если нет задач и нет списка -- то это может быть бридже. --------- Опять же поддерживаю все предыдущих орателей которые советуют рефакторить бридже на независимые дименшины Т.е. возможное решение (без брижей): FactAppointment -- DimDoctor, DimService, DimSpeciality, DimLocation, DimDate Если нужно: FactSpecialization -- DimDoctor, DimSpeciality FactSchedule -- DimDoctor, DimLocation, DimDate, DimSpeciality Сервис и Специальность может быть одним дименшеном, но мне кажется лучше разделить, это зависит от гранулярности визита, рассписания, специализации. Что у вас записано в визите: "визит к окулисту" или "визит к окулисту: (1) осмотр глазного дна, (2) подбор очков (3) подбор линз" ? DimLocation --- хиерархия кабинет-госпиталь-организация... или прямо сюда или отдельно можно географию прикрутить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 15:52 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
Роман Логачевмомент с организацией 3 отдельных измерений проработан и реализован уже, вопрос именно в том чтобы связать эти измерения для организации нормальной фильтрации, выбрал клинику отфильтровались, отделения, выбрал отделение отфильтровались специализации и т.д. ...вопрос ребром: вам нужны (а) только данные по реальным визитам ? (б) данные по визитам и анализ простоев врачей (врач дежурил но принял никого) (это как обычный JOIN супротив LEFT JOIN) если (а), то все связки уже имеются в основном ФактВизит , т.е. факт табле является бриджем! Фильтруйте через факт на здоровье! (ну если только не 100 квадрилионов записей) если (б) то связка из независимого источника нужна по любому. лично я бы назвал ьто ФактРасписание --- это не просто М2М бридж, а как миниму 4-стороны связка Врач-Специальность-Кабинет-Дата ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 16:09 |
|
||
|
Связь с измерением многие ко многим
|
|||
|---|---|---|---|
|
#18+
ShIgorиерархия "организация - клиника - отделение - специализация - врач" немного надумана. лучше 3 измерения "организация - клиника - отделение", "специализация", "врач" иначе 1 и тот же Специалист при наличии нескольких мест работы будет фактически разными людьми (ключ). то же самое и про Специальность. +1 То есть можно сделать отдельную таблицу фактов "Оказываемые услуги" И каждая строка этой таблицы фактов у вас состоит из ссылок на три измерения - отделение - специализация - врач Этот факт будет означать, что в данном отделении (иерархическое измерение "организация - клиника - отделение") данный врач оказывает услуги по данной специализации. Если в этом же отделении этот же врач оказывает услуги по другой специализации - добавляем еще одну строку, где отделение и врач те же, а специализация другая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 19:16 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=39519949&tid=1858116]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 247ms |
| total: | 387ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...