Проектирование схемы взаимодействия подразделений (Прочитано 23517 раз)
Подскажите, как реализовать следующую схему:
Таблица содержит иерархическую структуру подразделений некой организации. Необходимо реализовать отношение «подразделение» —1—взаимодействует—N— «подразделение», причем возможна ситуация, когда одно подразделение взаимодействует со всеми остальными подразделениями. Взаимодействие начинает свое действие на основании документа, и ограничено периодом, указанным в документе.



Я бы сделал так:
1. Приказ - Документ о взаимодействии со сроком и галкой - со всеми
2. Подразделение - иерархия подразделений


Подразделение 1..N-0..N Приказ
Приказ 1..N-0..N Подразделение

Нужно всегда брать последний по дате приказ от подразделения.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Вопрос в том, какова должна быть структура данных?
Самопересечение таблицы подразделений, отношение М к N, реализуется через дополнительную таблицу связи, в которой помимо кодов подразделений, участвующих в конкретном взаимодействии приводятся данные о документе-основании, это взаимодействие определяющем.

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



Все равно не понятно. Схему на UML, пожалуйста..



Все равно не понятно. Схему на UML, пожалуйста..
Э нет постойте - это Вы Схему на UML, пожалуйста! Кто у нас обратился за советом?



На мой взгляд, вариантов, как все это запроектировать, явно больше одного и выбор лучшего из них часто зависит от контекста решаемой задачи. Что в вашем случае первичнее: информация о самом по себе взаимодействии, атрибутами которого тогда будут являться взаимодействующие подразделения, период взаимодействия, документ-основание, или вам достаточно сохранить сведения обо всех взаимодействиях данного конкретного подразделения с другими подразделениями, например? В принципе, второе является частным случаем первого... Если вы указали, что подразделение А взаимодействует с подразделением В, то означает ли это, что В на основании того же документа взаимодействует с А? Т.е. является ли в вашем случае одно подразделение основным участником взаимодействия, а остальные - второстепенными или они равноправны? Нужно ли вам отдельно сохранять сведения о документах, являющихся основаниями для взаимодействий? Что в вашем случае является взаимодействием, в конце-концов? Я намекаю на то, что, возможно, взаимодействие у вас должно быть отдельной сущностью (таблицей БД)...
Изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе. (Карл Вигерс)
http://infiniti-gk.livejournal.com/



Подскажите, как реализовать следующую схему:
Таблица содержит иерархическую структуру подразделений некой организации. Необходимо реализовать отношение «подразделение» —1—взаимодействует—N— «подразделение», причем возможна ситуация, когда одно подразделение взаимодействует со всеми остальными подразделениями. Взаимодействие начинает свое действие на основании документа, и ограничено периодом, указанным в документе.

Если честно то абсолютно не понял что Вам необходимо реализовать - Диарамму классов, ERD диаграмму,  Организационно оформить, нарисовать UI или что-то еще. ..
Потрудитесь пожалуйста корректно сформулировать вопрос ...

p.s. Интересно как много предложений решений получено, на неполно сформулированную задачу




Подразделение 1..N-0..N Приказ
Приказ 1..N-0..N Подразделение

Нужно всегда брать последний по дате приказ от подразделения.

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



Ну допустим вот UML:




Несколько комментариев:
Нужно спроектировать БД, поэтому нужна ER диаграмма.
Выяснилось что понятие «Взаимодействует» не единственное вид связи между объектами. Возможны и другие виды связи подразделений: «Подчиняется», «Руководит», «Оценивает», «Оценивается», «Контролирует», «Контролируется» и др. парные значения.
В понятиях UML мне проще выразить через класс-ассоциацию следующим образом - см. вложение (надеюсь, не ошибся).
Время жизни любого типа соединений не может быть более, чем время жизни связанного объекта.
Вот как бы это выразить в ER диаграмме?



Цитата: NotTemp
Нужно спроектировать БД, поэтому нужна ER диаграмма.
Выяснилось что понятие «Взаимодействует» не единственное вид связи между объектами. Возможны и другие виды связи подразделений: «Подчиняется», «Руководит», «Оценивает», «Оценивается», «Контролирует», «Контролируется» и др. парные значения.
Вот как бы это выразить в ER диаграмме?

в формате ER-диаграммы нет таких видов соотношений :о)) пользуйтесь поведенческими диаграммами, предварительно ответив на вопрос: что значит "руководит" и прочее?

Лью воду...



Если еще актуально  :) ...
Логическая модель БД в ErWin будет, по-моему, будет такой:



Если в одном документе определяется несколько типов взаимодействия (руководит и контролирует), то связь <Справочник...> - <Взаимодействие> будет идентифицируемой (Код типа станет ключевым полем).

Если у документа нет уникального номера, думаю, целесообразно ввести ID.
"Все должно быть изложено так просто, как только возможно, но не проще." А. Эйнштейн



Логическая модель БД в ErWin будет, по-моему, будет такой:

Согласен. Но есть один вопрос: как в такой схеме отобразить взаимодействие типа "Взаимодействует", то есть когда подразделения равноправны? Если одно из них условно назначить "гл", а второе "подч", то по запросу 'все подразделения, которые "взаимодействуют" друг с другом' отберется только половина подразделений



Спасибо, kayten, еще актуально  :)



Цитата: div
по запросу 'все подразделения, которые "взаимодействуют" друг с другом' отберется только половина подразделений

ну это как запрос написать...
если руками, то проблем не будет :о))
« Последнее редактирование: 08 Октября 2009, 12:56:51 от Водолей »
Лью воду...




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19