|
|
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Такая задача... У сотрудника могут быть роли и должности (могут и не быть). В каждой должности он может выступать в разных ролях. И одна роль может выполняться сотрудником в разных должностях. Словом, нужна схема для хранения матричной структуры организации. Пришел к такому решению (картинка!)... Чем оно плохо? Меня смущает, что могут быть связаны должность и роль разных сотрудников. И ещё наличие цикла. Есть ещё варианты: 1) сделать отношение EmployeeResponsibility тернарным: Employee, Position, Role. Но тогда оно сможет связывать должности и роли, которых нет у сотрудника. Да и бинарное отношение как на рисунке более логичное, т.к. связываются именно должность и роль конкретного сотрудника. 2) Нарушить симметрию, сделав наличие роли у сотрудника обязательным. Т.е. если у него нет реальной роли, то ввести фэйковую роль "Сотрудник" или типа. И привязывать должность только к ролям, но не сотрудникам. Но по-моему получится безумно сложная схема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2011, 06:58 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Что такое роль сотрудника ? У неё нет временных рамок ? Если есть, то таблица EmployeeResposibility не нужна, нужная информация будет легко доступна из 3 остальных на любой момент времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2011, 12:05 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
ChAЧто такое роль сотрудника ? У неё нет временных рамок ? Если есть, то таблица EmployeeResposibility не нужна, нужная информация будет легко доступна из 3 остальных на любой момент времени. Вопрос: а какие факты Вам нужны? EmployeeResponsibility сейчас похоже на следующую формулировку: конкретный сотрудник, имея указанную должность, может выполнять обязанности конкретной закреплённой за ним роли (роли в проекте? ибо нам не видна остальная часть картинки :) )? Всё правильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2011, 12:55 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
АнатоЛойChAЧто такое роль сотрудника ? У неё нет временных рамок ? Если есть, то таблица EmployeeResposibility не нужна, нужная информация будет легко доступна из 3 остальных на любой момент времени. Вопрос: а какие факты Вам нужны? EmployeeResponsibility сейчас похоже на следующую формулировку: конкретный сотрудник, имея указанную должность, может выполнять обязанности конкретной закреплённой за ним роли (роли в проекте? ибо нам не видна остальная часть картинки :) )? Всё правильно? Вопрос не к ChA, а к ТС. А к вопросам от ChA - +2 :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2011, 12:56 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
ChA, роль - это что-то типа функциональных обязанностей. У нас медицинская тематика. Например, у сотрудника Иванова может быть 3 должности: врач-хирург, врач-педиатр, заведующий отделением. В должности врача-хирурга он может выполнять две роли: 1) врача, консультирующего пациентов в поликлинике и 2) оперирующего врача в стационаре. В должности врача-педиатра у него одна роль - врач поликлиники. На должности заведующего ролей нет. И, допустим, есть ещё роль научный исследователь, не привязанная к должностям. Получаем: СотрудникРольДолжностьИвановВрач поликлиникиВрач-хирургИвановВрач поликлиникиВрач-педиатрИвановОперирующий врачВрач-хирургИвановNULLЗаведующийИвановИсследовательNULL Даты не принципиальны, это просто атрибуты, которые важны для отдела кадров, типа доли ставки, надбавок и т.п. У ролей пока атрибутов нет, но теоретически могут быть... Если убрать EmployeeResposibility, то не получится же увязать роли сотрудника с должностями... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2011, 14:38 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
АнатоЛой, всё правильно ) можно назвать и ролью в проекте... Эту таблицу ответственности можно представить как таблицу, в которой строки - роли, столбцы - должности (как вы заметили, конкретного сотрудника! потому что должность и роль не определяют друг друга, для каждого сотрудника они могут быть связаны по-разному). И в таблице ставим галочки, если должность и роль связаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2011, 14:46 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Ares_ekbЗдравствуйте! Пришел к такому решению (картинка!)... Чем оно плохо? Меня смущает, что могут быть связаны должность и роль разных сотрудников. 1) сделать отношение EmployeeResponsibility тернарным: Employee, Position, Role. Но тогда оно сможет связывать должности и роли, которых нет у сотрудника. Да и бинарное отношение как на рисунке более логичное, т.к. связываются именно должность и роль конкретного сотрудника. С введением дат действия в атрибуты EmploуeePosition вы уже делаете контроль неполным... Поэтому предлагаю следующий вариант контроля целостности на уровне БД: 1. введением альтернативных ключей (АК) на EmployeeRole (EmployeeId, RoleId) и EmploуeePosition (EmployeeId, PositionId) 2. таблица EmployeeResponsibility (EmployeeResponsibilityId - PK, EmployeeId, PositionId, RoleId), НО не 3 внешних ключей от неё на Employee, Position и RoleId, а 2: (EmployeeId, PositionId) на АК у EmploуeePosition и (EmployeeId, RoleId) на АК у EmployeeRole :). 3. Учитывая наличие BeginDate, EndDate корректность связей по датам стоит уже вешать на триггера... Или создавать "навороченные" схемы - с попыткой контроля по сложным ключам и разбиения периодов действия на более мелкие периоды... Ares_ekbИ ещё наличие цикла. Какого цикла? Ares_ekbЕсть ещё варианты: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2011, 15:31 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
АнатоЛой, 1) Мне стыдно, но я не знал, что внешний ключ может ссылаться на АК, думал только на PK )) 2) Спасибо! Есть только один нюанс. Теоретически сотрудник может уволиться с должности, а потом снова на неё устроиться. Поэтому в EmployeePosition сделал АК - (ID, EmployeeID). И в EmployeeResponsibility абстрактной должности PositionID нет, а только должность конкретного сотрудника EmployeePositionID. 3) В принципе, здесь же важно работает сотрудник в этой должности ещё или нет. Если увольняется, то запись в EmployeeResponsibility должна просто не существовать. Возможно в ключ нужно добавить флаг работает/не работает. Хотя, пока я сделаю валидацию просто на уровне приложения ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 07:48 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
On 07.10.2011 8:48, Ares_ekb wrote: > 1) Мне стыдно, но я не знал, что внешний ключ может ссылаться на АК, думал > только на PK )) Лучше этого и не знать никогда, всегда ссылаться на PK. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 11:06 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Ares_ekbроль - это что-то типа функциональных обязанностей. У нас медицинская тематика. Например, у сотрудника Иванова может быть 3 должности: врач-хирург, врач-педиатр, заведующий отделением. В должности врача-хирурга он может выполнять две роли: 1) врача, консультирующего пациентов в поликлинике и 2) оперирующего врача в стационаре. В должности врача-педиатра у него одна роль - врач поликлиники. На должности заведующего ролей нет. И, допустим, есть ещё роль научный исследователь, не привязанная к должностям. Получаем: СотрудникРольДолжностьИвановВрач поликлиникиВрач-хирургИвановВрач поликлиникиВрач-педиатрИвановОперирующий врачВрач-хирургИвановNULLЗаведующийИвановИсследовательNULL Даты не принципиальны, это просто атрибуты, которые важны для отдела кадров, типа доли ставки, надбавок и т.п. У ролей пока атрибутов нет, но теоретически могут быть... Если убрать EmployeeResposibility, то не получится же увязать роли сотрудника с должностями...Ничего не понятно. Роли как-то фиксируются, например, вчера я исследователь, а сегодня врач, а завтра ещё что-то себе придумаю ? Как захочу, так и будет. Наверное, это как-то фиксируется, привязывается к каким-то фактам, приказам или ещё чему-то. Насколько понял, есть штатное расписание и какие-то процессы в поликлинике, в которых врач фиксируется в какой-то роли. Просто связать роли с должностями, как вы хотите, нельзя, IMHO. Роль должна быть привязана к процессу и единственная связь между ней и должностью - временная. В конкретный(!) момент, у него по должности может быть одна роль, в другой - да хоть три. Не так ? Ну, максимум, ещё дополнительный справочник, в котором описываются возможные роли по должности. В общем, тема не раскрыта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 14:36 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
MasterZivЛучше этого и не знать никогда, всегда ссылаться на PK.+1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 14:37 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
ChAMasterZivЛучше этого и не знать никогда, всегда ссылаться на PK.+1 Коллеги, вы или уж рассказывайте какие проблемы влечёт за собой ссылка на АК, либо предлагайте альтернативные варианты решения задачи. А лучше и то, и другое :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 18:52 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
On 07.10.2011 19:52, АнатоЛой wrote: > Коллеги, вы или уж рассказывайте какие проблемы влечёт за собой ссылка на АК, Никаких. Кроме недоумения коллег и необходимости JOIN-ить родительскую таблицу в запросах, если нужно иметь PK родительской таблицы. Но это не очень страшно всё. Тут дело не в проблемности, а в стиле работы. Ссылаться на AK стилестически некрасиво. Есть PK, его назначение -- идентифицировать запись в БД. AK назначение -- идентифицировать запись с точки зрения пользователя. Вот и не надо тащить AK в БД. Сегодня один AK, завтра -- другой ... > либо предлагайте альтернативные варианты решения задачи. А лучше и то, и другое :). Ссылаться на PK. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 19:01 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Ares_ekb1) Мне стыдно, но я не знал, что внешний ключ может ссылаться на АК, думал только на PK )) Мне не стыдно, но я признаюсь, что в собственной практике проектировщика и разработчика их использование тоже вспомнить не могу :) :(. Ares_ekb2) Спасибо! Есть только один нюанс. Теоретически сотрудник может уволиться с должности, а потом снова на неё устроиться. Поэтому в EmployeePosition сделал АК - (ID, EmployeeID). И в EmployeeResponsibility абстрактной должности PositionID нет, а только должность конкретного сотрудника EmployeePositionID. Коллеги уже упоминали - нужно вводить временные зависимости. Т.е. нужен не АК - а начало и окончание периода действия. Ares_ekb3) В принципе, здесь же важно работает сотрудник в этой должности ещё или нет. Если увольняется, то запись в EmployeeResponsibility должна просто не существовать. Возможно в ключ нужно добавить флаг работает/не работает. Хотя, пока я сделаю валидацию просто на уровне приложения ) Опять - нужен период действия. Флаг может только оптизировать скорость ответа на частый вопрос "Работает/не работает?". Ну или можно по вашей схеме - т.е. такая таблица отражает только текущее сосотяни - но желательно присутствие информации в системе, на основании чего это произошло - см. пост ChA на эту тему... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 19:02 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
MasterZiv> либо предлагайте альтернативные варианты решения задачи. А лучше и то, и другое :). Ссылаться на PK. Это не решение задачи - это "стилистическое" предложение. Какую конкретно схему данных для решения задачи Вы предлаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 19:06 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
ChA, приказы определяют только должности. Роли - это, действительно, роли в бизнес-процессах, которые достаточно устойчивы, и их участники не могут меняться каждый день. Не очень понял насчет временной связи между должностью и ролью... Под ролью имеется ввиду не роль в рамках конкретного экземпляра процесса, а, в принципе, какую роль может играть этот сотрудник в процессе. Ну, по сути, это и есть справочник, который вы упомянули. Только он привязан ещё и к сотруднику, потому что роли слабо коррелируют с должностями. Словом, это все возможные комбинации ролей и должностей сотрудников. В конкретном экземпляре процесса вероятно будут ссылки на эти комбинации, хотя я ещё не думал об этом... В основном, важна должность, а роль понятна из контекста. Например, если врач указан как лечащий врач в истории болезни, или как оперирующий врач в записи об операции, то его роль и так понятна. Эти роли нужны, скорей, для проверки, что бы, например, врача поликлиники не могли назначить на роль лечащего врача в стационаре у какого-то пациента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 19:27 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Ares_ekbChA, приказы определяют только должности. Роли - это, действительно, роли в бизнес-процессах, которые достаточно устойчивы, и их участники не могут меняться каждый день. Не очень понял насчет временной связи между должностью и ролью... Под ролью имеется ввиду не роль в рамках конкретного экземпляра процесса, а, в принципе, какую роль может играть этот сотрудник в процессе. Ares_ekb, а у процесса есть временное ограничение? Вы просто приводите такие интересные примеры ролей: Врач поликлиники, Оперирующий врач, Исследователь... Либо я туплю из-за того, что не видна вся схема, а догадки сильно не совпадают с реальным положением вещей, либо у вас специфические "роли" :). Из приведённых примеров я вижу, что у вас приказы скорее всего ... разные! Ибо принадлежат разным организациям: поликлинике, больнице и институту! :). А вы тут с понятием "роли" паритесь. СветИте ужЕ, что у вас там за процессы/проекты :)... Ares_ekbВ конкретном экземпляре процесса вероятно будут ссылки на эти комбинации, хотя я ещё не думал об этом... А Вы подумайте, а то как бы концепция не поменялась :). Ares_ekbВ основном, важна должность, а роль понятна из контекста. Например, если врач указан как лечащий врач в истории болезни, или как оперирующий врач в записи об операции, то его роль и так понятна. А вот и подробности полезли, и новые сущности... Ares_ekbЭти роли нужны, скорей, для проверки, что бы, например, врача поликлиники не могли назначить на роль лечащего врача в стационаре у какого-то пациента. И требования, на которых результат проектирования даных проверяться на коректность будет :). "О, сколько нам открытий чудных готовит " пятничный вечер :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2011, 20:20 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
АнатоЛой, 1) По поводу организаций... в названии нашей организации очень много слов: "Государственное бюджетное учреждение здравоохранения Свердловской области детская клиническая больница восстановительного лечения Научно-практический центр ..." ))) У нас 2 поликлиники, несколько отделений стационара, отдел координации научных исследований и много других отделов (экономисты, бухгалтеры, закупки, водители, инженеры, ИТ, аптека и т.п.) Но, мало того, поверх структурных подразделений есть ещё и функциональные: 9 областных детских центров (в них работают те же врачи, но они объединены процессом реабилитации детей с определенной нозологией). Например, в офтальмологическом центре есть офтальмологи, неврологи, педиатры, которые реабилитируют детей с нарушением зрения. Но тот же самый невролог может играть роль невролога и в другом центре. Плюс к этому есть нештатные научные консультанты, (не)штатные исследователи (которыми могут быть и врачи). И они также могут объединяться в функциональные подразделения - научно-практические лаборатории. Ещё, например, статистики, экономисты могут играть определенные роли в медицинских процессах. 2) Проблема в том, что мы делаем единую ИС для всех этих людей. У неё есть ядро, в котором определены такие сущности как пользователь, работник, сотрудник, роль, должность, подразделение и т.п. И множество опциональных модулей: медицинская первичка (пациенты, посещения, истории болезни, лечение и т.п.), закупки (договоры, контракты), кадры (всякие приказы, зарплатные коэффициенты), наука (исследователи, диссертации, публикации), оценка персонала и т.п. Представить не могу как всё это разнести по разным базам, пока у нас одна большая. 3) Как таковой сущности "процесс" у нас пока нет. Потому что всю информацию по процессу можно собрать из существующих таблиц. Например, интересует процесс реабилитации какого-то ребенка. Вытаскиваем из базы всю информацию о том, что происходило с этим ребенком - получаем процесс длительностью иногда до 18 лет. Или, например, интересует процесс написания диссертации соискателем - вытаскиваем все его публикации, конференции и т.п. Т.е. идентификатор процесса - это пациент, соискатель, функциональное подразделение или что-то ещё... Т.е. это как процесс идет по факту. Скорей всего, будет и планируемый ход процесса: когда какую операцию делать, сколько должно быть консультаций в год и т.п. 4) И, возвращаясь к субжу, роли сотрудника определяют 1) доступный ему UI, 2) возможности других сотрудников ссылаться на него (например, в качестве оперирующего врача можно указать только сотрудника, который действительно обладает этой ролью) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2011, 11:13 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
On 07.10.2011 20:06, АнатоЛой wrote: > Какую конкретно схему данных для решения задачи Вы предлаете? Как у автора, но отказаться от дополнительных суррогатных ключей в EmployeeRole, EmployeePosition, и как следствие в EmployeeResponsibility. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2011, 19:34 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
MasterZiv, В EmployeeRole и EmployeeResponsibility суррогатные ключи возможно пока не нужны. Но в EmployeePosition без него никак, т.к. сотрудник и должность не являются ключом. К тому же на эту таблицу много ссылок, и составные ключи не удобны. И, в принципе, я стараюсь их не использовать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2011, 20:09 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 07.10.2011 20:06, АнатоЛой wrote: > Какую конкретно схему данных для решения задачи Вы предлаете? Как у автора, но отказаться от дополнительных суррогатных ключей в EmployeeRole, EmployeePosition, и как следствие в EmployeeResponsibility. Красиво, 5 баллов! :) П.С.: ТС, у этого решения могут быть проблемы, если сам фреймворк заточен как раз под использование суррогатных ключей (из одного поля)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2011, 13:41 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Ares_ekb Но, мало того, поверх структурных подразделений есть ещё и функциональные: 9 областных детских центров (в них работают те же врачи, но они объединены процессом реабилитации детей с определенной нозологией). Например, в офтальмологическом центре есть офтальмологи, неврологи, педиатры, которые реабилитируют детей с нарушением зрения. Но тот же самый невролог может играть роль невролога и в другом центре. Невролог же не просто идёт в любой из ваших центров и говорит: "Я у вас буду играть роль невролога", правильно? Ares_ekbПлюс к этому есть нештатные научные консультанты, (не)штатные исследователи (которыми могут быть и врачи). И они также могут объединяться в функциональные подразделения - научно-практические лаборатории. Т.е. должны быть соответствующие договора, приказы, распоряжения, поручения, по которым закрепляется роль за работником. Если Вы в этом разберётесь - проще будет спроектировать адекватную модель (даже если сами документы пока не собираетесь автоматизировать). Ares_ekb2) ... ядро, в котором определены такие сущности как пользователь, работник, сотрудник, роль, должность, подразделение и т.п. 1. Между делом - чем у вас отличаются сотрудник от рабоника? 2. Госучреждение, к тому же медицинское. Явно с бухты барахты конкретный работник с должностью "врач-терапевт" не становится "врачом поликлиники". Вы разобрались, какими документами "роль" "Врач поликлиники" закрепляется за работником? Ares_ekb4) И, возвращаясь к субжу, роли сотрудника определяют 1) доступный ему UI, 2) возможности других сотрудников ссылаться на него (например, в качестве оперирующего врача можно указать только сотрудника, который действительно обладает этой ролью) Прежде чем появится возможность "указать только сотрудника, который действительно обладает этой ролью", нужно за этим сотрудником эту роль закрепить. Вы мучаетесь с вопросом "как этот факт хранить?", но важно также понимать "на основании каких событий/документов деятельности организации этот факт вносить в БД?" Итого, по нескольким пунктам видим разрыв между вашей сущностью "Роль" и предметной областью... Ни один из ваших работников-врачей не пользуется этим словом в работе, правильно? Вот и выясните, а как они сами-то называют это понятие. И если после этого всё-таки останется в БД понятие "Роль" - дайте ему чёткое определение - ибо потом вам это слово объяснять пользователям... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2011, 14:13 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
АнатоЛой, 1) Никаких приказов за ролями нет, это сугубо наше внутреннее "изобретение". Ну, точнее, за всем конечно есть какой-то приказ: о создании функционального подразделения и назначении его руководителя (роль - руководитель центра). Но эти приказы ничем не отличаются от других. Практически в любом приказе описывается перечень работ, которые надо выполнять, назначаются исполнители, ответственный. Например, пришел сверху приказ о том, что с позавчерашнего дня запись пациентов на прием должна осуществляться через инет. Мы делаем внутренний приказ, в котором пишем, что такие-то регистраторы должны составлять расписание на сайте, обрабатывать заявки, такой-то сотрудник должен их этому обучить, такой-то - им все настроить, такой-то - всё контролировать (т.е. всем этим людям назначаются роли). Но об этих ролях я, честно говоря, задумался только сейчас. Областные детские центры, о которых я говорил, это в принципе такие же функциональные объединения, но более глобальные что ли и устойчивые. Чтобы врачу выполнять роль врача в функциональном подразделении, достаточно устной договоренности, это не нужно согласовывать с отделом кадров. Если приходит новый сотрудник, то должность ему назначается через отдел кадров. А роли возникают после обсуждения с руководителем функционального подразделения. Назначить сам себе роль сотрудник конечно не может, это делают руководители. 2) Роль - это набор функциональных обязанностей сотрудника. Сама по себе должность не определят, что должен делать человек. По сути - это тоже самое, что подразумевается под ролью в бизнес-процессе или проекте. 3) Вообще вопросы в этой теме навели меня на одну мысль... Сотрудники роли не называют никак. Хотя косвенно говорят о них часто. Например, нам безусловно нужны отчеты по структурным подразделениям. Поэтому, например, в посещениях пациентов указывается не только сотрудник, но и его должность. Но также нужны отчеты и по функциональным подразделениям. Допустим, врач принял пациента как врач-невролог. Но одно дело, если это взрослый пациент, который не подлежит учету в центре, и совсем другое дело если это ребенок группы риска. В первом случае это будет посещение обычного врача, а во втором - это будет посещение врача, например, офтальмологического центра. Сейчас эти отчеты по функциональным подразделениям получаются по косвенным признакам. Допустим, все посещения пациентов, состоящих на учете в центре, мы относим к этому центру. Но врачами центра могут консультироваться и здоровые дети, которые в итоге на учет поставлены не будут. Либо за каждым центром можно закрепить перечень диагнозов, но в разных центрах могут консультироваться дети с одинаковыми диагнозами. Короче, смысл в том, что роль определяет не только UI. Нам действительно важна в тех же посещениях не только должность, но и роль врача. В общем, получается, что практически все остальные сущности в базе должны ссылаться именно на EmployeeResponsibility, а не на EmployeePosition как сейчас. Тогда роль - это, действительно, не временная сущность, которая определяет права пользователя на текущий момент. Роли должны храниться вечно. Тогда в EmployeeResponsibility есть смысл добавить даты действия, ссылку на человека, назначившего роль и т.п. 4) По поводу составных ключей... мы используем XPO (DevExpress), он их поддерживает, но у меня какое-то предубеждение против них... 5) Работник - это абстрактный человек, который может и не быть сотрудником. Вообще, это отдельная тема... У сотрудников необходимо указывать, например, паспортные данные. А для соискателей что-то другое. Проблема, если человек одновременно сотрудник и соискатель... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2011, 15:45 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
В общем, переделал всё так... EmployeeResponsibility убрал вообще, т.к. у сотрудника ролей больше чем должностей. И вообще, роль - это уточнение должности. Человек не может выполнять одну и ту же роль в разных должностях. В крайнем случае, можно продублировать роль. Допустим, у него 2 должности: хирург и педиатр. И он просто ведет обычный прием в поликлинике. Тогда назначаем ему две одинаковые роли "врач поликлиники", ссылающиеся на разные должности. WorkerRole.EmployeePositionID - nullable. Остальные ключи обязательные. Но остается проблема с тем, что роль может ссылаться на должность другого сотрудника. И по-моему кроме как внешним ключом с WorkerRole на альтернативный ключ EmployeePosition (ID, EmployeeID) это не решается... Т.к. в EmployeePosition без суррогатного ключа не обойтись. И ещё что вы думаете по поводу связей 1-к-1 Worker-Scientist-Employee. С одной стороны, это дает модульность. Worker и Employee определены в ядре. А Scientist и не знаю что ещё - в опциональных модулях. Можно на уровне БД и приложения делать разные правила валидации. Но с другой стороны, наш ORM-фрэймворк не поддерживает множественное наследование, и будут проблемы с учеными-сотрудниками и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2011, 08:02 |
|
||
|
Матричная структура организации
|
|||
|---|---|---|---|
|
#18+
Ещё, я, вот, думаю... Scientist и Employee в принципе связаны с WorkerRole. Тот, факт, что работник является исследователем или сотрудником с определенной должностью делает ему доступными определенные роли, но наверное решать это на уровне реляционной БД нет смысла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2011, 08:20 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37473872&tid=1541986]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
185ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
84ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 554ms |

| 0 / 0 |
