powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Связь с измерением многие ко многим
10 сообщений из 10, страница 1 из 1
Связь с измерением многие ко многим
    #39519450
Добрый день!
Столкнулся с задачей, которая по всей видимости требует не очевидного решения. Хотя думаю достаточно распространена.
Есть орг структура:
Организация - Клиника - Отделение

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

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

в исходной системе есть одна табличка (назовем ее связка) которая связывает ид врача, ид специализации, ид отделения.

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

Рассмотрим например организацию связи отделения - специализации: если таблицу bridge сделать с 2 полями ид отделения и ид специализации, то если факты будут лежать на специализации то мы не поймем по какому точно отделению они так как к специализации привязано несколько отделений.

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

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

Спасибо большое если поможете, завис чет с этой задачей.
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519566
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Логачев,
на первый взгляд связь многие ко многим вам не нужна.
Фактом является оказание врачом услуги.
И для этого факта можно однозначно определить и врача, и отделение, и специализацию.
Просто три разных измерения.
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519601
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovРоман Логачев,
на первый взгляд связь многие ко многим вам не нужна.
Фактом является оказание врачом услуги.
И для этого факта можно однозначно определить и врача, и отделение, и специализацию.
Просто три разных измерения.


Да, такой подход имеет место быть -- преимущества --
простота и удобство для конкретной задачи.

Если (бы... мы точно не знаем) нужны репорты типа:
сколько врачей по конкретной специальности есть в таком-то отделении
или "какие врачи НЕ используют некоторые свои специализации", то
тут нужно будет связки, но не как бридже а как законные факты:
ФактСпециализацияВрача (по диплому, без привязки с госпиталю),
ФактРасписаниеСпециалистов (конкретный человек принимает как такой-то специалист в таком-то госпитале)

Повторю: дополнительные навороты нужны если они нужны
по бизнез задаче...
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519664
Ferdipux
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Роман ЛогачевДобрый день!
Столкнулся с задачей, которая по всей видимости требует не очевидного решения. ...

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

Услуга

Где оказана (в каком отделении, кабинете и пр)

Кому оказана
По услуге вы можете определить специализацию.
Это факты, и аналитика не может их синтезировать или выдумать. Что могу предложить - вы можете попробовать обогощать данные в ETL процессе как-то.
Как сказали ранее, аналитика может ответить на вопрос "как работают врачи по своим специализациям" или "как связаны услуги врачей с отделениями", восстановление фактов - не задача аналитики.
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519697
Спасибо, коллеги за ответы, но так и не пойму какое же решение задачи.

Сделаю еще пару вводных, почему решил делать связи так это потому что нужно сделать иерархию вида:

организация - клиника - отделение - специализация - врач

для организации фильтрации параметров в отчетах и т.д.

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

не совсем понял про связки но не типа моста а типа законные факты, это как..

как я вижу в фактах есть услуга, врач и признак в каком отделении оказана услуга т..е. ид из таблицы связки в исходной системе, но как дальше привязывать факты к измерениям врачей, по двум ключам получается?? врач и ид признака связки ??
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519731
ShIgor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Логачев,

сложностей на этом этапе минимум.
Измерения: ОУ (образовательное учреждение можно опустить), ЛУ (лечебное учреждение), Специализация, Специалист, Дата
Факты: образование, штатное расписание, услуги
т.е.
Специалист получил образование по Специализации в ОУ
Специалист работает по Специальности в ЛУ по Расписанию(Дата)
Специалист оказал услуги по Специальности в ЛУ в Дата

связь m2m можно сделать между образованием и штатным расписанием и/или оказанием услуг

иерархия "организация - клиника - отделение - специализация - врач" немного надумана.
лучше 3 измерения "организация - клиника - отделение", "специализация", "врач" иначе 1 и тот же Специалист при наличии нескольких мест работы будет фактически разными людьми (ключ). то же самое и про Специальность.
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519922
Ferdipux
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Роман Логачев
Сделаю еще пару вводных, почему решил делать связи так это потому что нужно сделать иерархию вида:

организация - клиника - отделение - специализация - врач

для организации фильтрации параметров в отчетах и т.д.

момент с организацией 3 отдельных измерений проработан и реализован уже, вопрос именно в том чтобы связать эти измерения для организации нормальной фильтрации, выбрал клинику отфильтровались, отделения, выбрал отделение отфильтровались специализации и т.д.
...
Как ранее сказали, ваша иерархия приведет к проблемам. Лучше разбить ее на 3 измерения.
У вас вопрос не по дизайну, а по среде отображения отчетов. Чтобы при выборе отделения - в списке специализаций пропали не активные.
Как решить (на вашем примере) - я делал некую dummy группу мер - которая 1 для всех отделений, и привязывал ее через M2M к специализациям. Через измерения связок (отделение-код заказа и код заказа-специализация) подхода M2M и в Reporting Services - запрашивал что выбрано в иерархии (отделение). Далее - делал запрос к мере dummy связок, чтобы он выводил ненулевые строчки. Из результата ответа - формировал список специализаций. Это работало в SSRS, так как там есть механизм связанных параметров и можно сложным отразом обновлять список значений зависимого параметра.
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519949
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Логачевне совсем понял про связки но не типа моста а типа законные факты, это как..

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

конкретно по теме:

Если у вас есть расписание врачей и есть задача
по анализу занятости врачей -- то полезно будет иметь рассписание как факт.

Если таких зада4 не стоит и у вас только база посешений --
то "рассписание" можно сделать как вспомогательный бридже
заполяя его только из фактов "визит к врачу"

Аналогично "врачи и специальности" -- если есть независимый список
и есть задачи по анализу етого списка ("работают ли врачи по
своим специальности(ям)") то это скорее факт.
Если нет задач и нет списка -- то это может быть бридже.

---------

Опять же поддерживаю все предыдущих орателей которые
советуют рефакторить бридже на независимые дименшины

Т.е. возможное решение (без брижей):

FactAppointment -- DimDoctor, DimService, DimSpeciality, DimLocation, DimDate

Если нужно:

FactSpecialization -- DimDoctor, DimSpeciality
FactSchedule -- DimDoctor, DimLocation, DimDate, DimSpeciality

Сервис и Специальность может быть одним дименшеном, но
мне кажется лучше разделить, это зависит от гранулярности
визита, рассписания, специализации.
Что у вас записано в визите: "визит к окулисту" или
"визит к окулисту: (1) осмотр глазного дна, (2) подбор очков (3) подбор линз" ?

DimLocation --- хиерархия кабинет-госпиталь-организация...
или прямо сюда или отдельно можно географию прикрутить...
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39519959
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Логачевмомент с организацией 3 отдельных измерений проработан и реализован уже, вопрос именно в том чтобы связать эти измерения для организации нормальной фильтрации, выбрал клинику отфильтровались, отделения, выбрал отделение отфильтровались специализации и т.д.


...вопрос ребром: вам нужны

(а) только данные по реальным визитам ?
(б) данные по визитам и анализ простоев врачей (врач дежурил но принял никого)

(это как обычный JOIN супротив LEFT JOIN)

если (а), то все связки уже имеются в основном ФактВизит ,
т.е. факт табле является бриджем! Фильтруйте через факт на здоровье!
(ну если только не 100 квадрилионов записей)

если (б) то связка из независимого источника нужна по любому.
лично я бы назвал ьто ФактРасписание --- это не просто М2М бридж,
а как миниму 4-стороны связка Врач-Специальность-Кабинет-Дата
...
Рейтинг: 0 / 0
Связь с измерением многие ко многим
    #39520065
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShIgorиерархия "организация - клиника - отделение - специализация - врач" немного надумана.
лучше 3 измерения "организация - клиника - отделение", "специализация", "врач" иначе 1 и тот же Специалист при наличии нескольких мест работы будет фактически разными людьми (ключ). то же самое и про Специальность.
+1

То есть можно сделать отдельную таблицу фактов "Оказываемые услуги"
И каждая строка этой таблицы фактов у вас состоит из ссылок на три измерения
- отделение
- специализация
- врач

Этот факт будет означать, что в данном отделении (иерархическое измерение "организация - клиника - отделение") данный врач оказывает услуги по данной специализации. Если в этом же отделении этот же врач оказывает услуги по другой специализации - добавляем еще одну строку, где отделение и врач те же, а специализация другая.
...
Рейтинг: 0 / 0
10 сообщений из 10, страница 1 из 1
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Связь с измерением многие ко многим
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]