Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 Связь с измерением многие ко многим  [new]
Роман Логачев
Member

Откуда:
Сообщений: 2
Добрый день!
Столкнулся с задачей, которая по всей видимости требует не очевидного решения. Хотя думаю достаточно распространена.
Есть орг структура:
Организация - Клиника - Отделение

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

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

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

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

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

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

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

Спасибо большое если поможете, завис чет с этой задачей.
11 сен 17, 18:50    [20788039]     Ответить | Цитировать Сообщить модератору
 Re: Связь с измерением многие ко многим  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1750
Роман Логачев,
на первый взгляд связь многие ко многим вам не нужна.
Фактом является оказание врачом услуги.
И для этого факта можно однозначно определить и врача, и отделение, и специализацию.
Просто три разных измерения.
11 сен 17, 23:32    [20788493]     Ответить | Цитировать Сообщить модератору
 Re: Связь с измерением многие ко многим  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17060
s_ustinov
Роман Логачев,
на первый взгляд связь многие ко многим вам не нужна.
Фактом является оказание врачом услуги.
И для этого факта можно однозначно определить и врача, и отделение, и специализацию.
Просто три разных измерения.



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

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

Повторю: дополнительные навороты нужны если они нужны
по бизнез задаче...
12 сен 17, 05:04    [20788639]     Ответить | Цитировать Сообщить модератору
 Re: Связь с измерением многие ко многим  [new]
Ferdipux
Member

Откуда: Москва
Сообщений: 399
Роман Логачев
Добрый день!
Столкнулся с задачей, которая по всей видимости требует не очевидного решения. ...

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

Вам нужно уметь в бизнес-приложении или ETL определять тип услуги по факту ее оказания. То есть запись об оказании услуги должна иметь следующие атрибуты:
  • Врач
  • Услуга
  • Где оказана (в каком отделении, кабинете и пр)
  • Кому оказана
    По услуге вы можете определить специализацию.
    Это факты, и аналитика не может их синтезировать или выдумать. Что могу предложить - вы можете попробовать обогощать данные в ETL процессе как-то.
    Как сказали ранее, аналитика может ответить на вопрос "как работают врачи по своим специализациям" или "как связаны услуги врачей с отделениями", восстановление фактов - не задача аналитики.
  • 12 сен 17, 09:12    [20788880]     Ответить | Цитировать Сообщить модератору
     Re: Связь с измерением многие ко многим  [new]
    Роман Логачев
    Member

    Откуда:
    Сообщений: 2
    Спасибо, коллеги за ответы, но так и не пойму какое же решение задачи.

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

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

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

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

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

    как я вижу в фактах есть услуга, врач и признак в каком отделении оказана услуга т..е. ид из таблицы связки в исходной системе, но как дальше привязывать факты к измерениям врачей, по двум ключам получается?? врач и ид признака связки ??
    12 сен 17, 09:56    [20789026]     Ответить | Цитировать Сообщить модератору
     Re: Связь с измерением многие ко многим  [new]
    ShIgor
    Member

    Откуда: Нижний Новгород
    Сообщений: 1955
    Роман Логачев,

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

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

    иерархия "организация - клиника - отделение - специализация - врач" немного надумана.
    лучше 3 измерения "организация - клиника - отделение", "специализация", "врач" иначе 1 и тот же Специалист при наличии нескольких мест работы будет фактически разными людьми (ключ). то же самое и про Специальность.
    12 сен 17, 10:42    [20789177]     Ответить | Цитировать Сообщить модератору
     Re: Связь с измерением многие ко многим  [new]
    Ferdipux
    Member

    Откуда: Москва
    Сообщений: 399
    Роман Логачев

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

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

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

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

    Как ранее сказали, ваша иерархия приведет к проблемам. Лучше разбить ее на 3 измерения.
    У вас вопрос не по дизайну, а по среде отображения отчетов. Чтобы при выборе отделения - в списке специализаций пропали не активные.
    Как решить (на вашем примере) - я делал некую dummy группу мер - которая 1 для всех отделений, и привязывал ее через M2M к специализациям. Через измерения связок (отделение-код заказа и код заказа-специализация) подхода M2M и в Reporting Services - запрашивал что выбрано в иерархии (отделение). Далее - делал запрос к мере dummy связок, чтобы он выводил ненулевые строчки. Из результата ответа - формировал список специализаций. Это работало в SSRS, так как там есть механизм связанных параметров и можно сложным отразом обновлять список значений зависимого параметра.
    12 сен 17, 15:03    [20790186]     Ответить | Цитировать Сообщить модератору
     Re: Связь с измерением многие ко многим  [new]
    javajdbc
    Member

    Откуда: Montreal
    Сообщений: 17060
    Роман Логачев
    не совсем понял про связки но не типа моста а типа законные факты, это как..


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

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

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

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

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

    ---------

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

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

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

    Если нужно:

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

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

    DimLocation --- хиерархия кабинет-госпиталь-организация...
    или прямо сюда или отдельно можно географию прикрутить...
    12 сен 17, 15:52    [20790446]     Ответить | Цитировать Сообщить модератору
     Re: Связь с измерением многие ко многим  [new]
    javajdbc
    Member

    Откуда: Montreal
    Сообщений: 17060
    Роман Логачев
    момент с организацией 3 отдельных измерений проработан и реализован уже, вопрос именно в том чтобы связать эти измерения для организации нормальной фильтрации, выбрал клинику отфильтровались, отделения, выбрал отделение отфильтровались специализации и т.д.



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

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

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

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

    если (б) то связка из независимого источника нужна по любому.
    лично я бы назвал ьто ФактРасписание --- это не просто М2М бридж,
    а как миниму 4-стороны связка Врач-Специальность-Кабинет-Дата
    12 сен 17, 16:09    [20790541]     Ответить | Цитировать Сообщить модератору
     Re: Связь с измерением многие ко многим  [new]
    s_ustinov
    Member

    Откуда: Lugano, CH
    Сообщений: 1750
    ShIgor
    иерархия "организация - клиника - отделение - специализация - врач" немного надумана.
    лучше 3 измерения "организация - клиника - отделение", "специализация", "врач" иначе 1 и тот же Специалист при наличии нескольких мест работы будет фактически разными людьми (ключ). то же самое и про Специальность.

    +1

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

    Этот факт будет означать, что в данном отделении (иерархическое измерение "организация - клиника - отделение") данный врач оказывает услуги по данной специализации. Если в этом же отделении этот же врач оказывает услуги по другой специализации - добавляем еще одну строку, где отделение и врач те же, а специализация другая.
    12 сен 17, 19:16    [20791075]     Ответить | Цитировать Сообщить модератору
    Все форумы / OLAP и DWH Ответить