Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: NotTemp от 01 Октября 2009, 12:08:17
-
Подскажите, как реализовать следующую схему:
Таблица содержит иерархическую структуру подразделений некой организации. Необходимо реализовать отношение «подразделение» —1—взаимодействует—N— «подразделение», причем возможна ситуация, когда одно подразделение взаимодействует со всеми остальными подразделениями. Взаимодействие начинает свое действие на основании документа, и ограничено периодом, указанным в документе.
-
Я бы сделал так:
1. Приказ - Документ о взаимодействии со сроком и галкой - со всеми
2. Подразделение - иерархия подразделений
Подразделение 1..N-0..N Приказ
Приказ 1..N-0..N Подразделение
Нужно всегда брать последний по дате приказ от подразделения.
-
Вопрос в том, какова должна быть структура данных?
Самопересечение таблицы подразделений, отношение М к N, реализуется через дополнительную таблицу связи, в которой помимо кодов подразделений, участвующих в конкретном взаимодействии приводятся данные о документе-основании, это взаимодействие определяющем.
На организационном уровне должен быть определен предмет взаимодействия - конкретный частный случай: процесс/процедура, в котором задействованы оба подразделения, или документ, который передается из подразделения в подразделение.
-
Все равно не понятно. Схему на UML, пожалуйста..
-
Все равно не понятно. Схему на UML, пожалуйста..
Э нет постойте - это Вы Схему на UML, пожалуйста! Кто у нас обратился за советом?
-
На мой взгляд, вариантов, как все это запроектировать, явно больше одного и выбор лучшего из них часто зависит от контекста решаемой задачи. Что в вашем случае первичнее: информация о самом по себе взаимодействии, атрибутами которого тогда будут являться взаимодействующие подразделения, период взаимодействия, документ-основание, или вам достаточно сохранить сведения обо всех взаимодействиях данного конкретного подразделения с другими подразделениями, например? В принципе, второе является частным случаем первого... Если вы указали, что подразделение А взаимодействует с подразделением В, то означает ли это, что В на основании того же документа взаимодействует с А? Т.е. является ли в вашем случае одно подразделение основным участником взаимодействия, а остальные - второстепенными или они равноправны? Нужно ли вам отдельно сохранять сведения о документах, являющихся основаниями для взаимодействий? Что в вашем случае является взаимодействием, в конце-концов? Я намекаю на то, что, возможно, взаимодействие у вас должно быть отдельной сущностью (таблицей БД)...
-
Подскажите, как реализовать следующую схему:
Таблица содержит иерархическую структуру подразделений некой организации. Необходимо реализовать отношение «подразделение» —1—взаимодействует—N— «подразделение», причем возможна ситуация, когда одно подразделение взаимодействует со всеми остальными подразделениями. Взаимодействие начинает свое действие на основании документа, и ограничено периодом, указанным в документе.
Если честно то абсолютно не понял что Вам необходимо реализовать - Диарамму классов, ERD диаграмму, Организационно оформить, нарисовать UI или что-то еще. ..
Потрудитесь пожалуйста корректно сформулировать вопрос ...
p.s. Интересно как много предложений решений получено, на неполно сформулированную задачу
-
Подразделение 1..N-0..N Приказ
Приказ 1..N-0..N Подразделение
Нужно всегда брать последний по дате приказ от подразделения.
Не, периоды действия приказов могут пересекаться во времени, более поздний приказ может не отменять, а дополнять действие предыдущего. Недостаточно вводных для предложения конкретной схемы.
-
Ну допустим вот UML:
(http://yuml.me/diagram/scruffy/class/[Document]-[Interaction%7Cto_date],[Interaction]-party1-[OrgUnit],[Interaction]-party2-[OrgUnit],[OrgUnit]%3C%3E-[OrgUnit])
-
Несколько комментариев:
Нужно спроектировать БД, поэтому нужна ER диаграмма.
Выяснилось что понятие «Взаимодействует» не единственное вид связи между объектами. Возможны и другие виды связи подразделений: «Подчиняется», «Руководит», «Оценивает», «Оценивается», «Контролирует», «Контролируется» и др. парные значения.
В понятиях UML мне проще выразить через класс-ассоциацию следующим образом - см. вложение (надеюсь, не ошибся).
Время жизни любого типа соединений не может быть более, чем время жизни связанного объекта.
Вот как бы это выразить в ER диаграмме?
-
Нужно спроектировать БД, поэтому нужна ER диаграмма.
Выяснилось что понятие «Взаимодействует» не единственное вид связи между объектами. Возможны и другие виды связи подразделений: «Подчиняется», «Руководит», «Оценивает», «Оценивается», «Контролирует», «Контролируется» и др. парные значения.
Вот как бы это выразить в ER диаграмме?
в формате ER-диаграммы нет таких видов соотношений :о)) пользуйтесь поведенческими диаграммами, предварительно ответив на вопрос: что значит "руководит" и прочее?
-
Если еще актуально :) ...
Логическая модель БД в ErWin будет, по-моему, будет такой:
(http://pic.ipicture.ru/uploads/091007/39Z5LVSU5b.gif)
Если в одном документе определяется несколько типов взаимодействия (руководит и контролирует), то связь <Справочник...> - <Взаимодействие> будет идентифицируемой (Код типа станет ключевым полем).
Если у документа нет уникального номера, думаю, целесообразно ввести ID.
-
Логическая модель БД в ErWin будет, по-моему, будет такой:
Согласен. Но есть один вопрос: как в такой схеме отобразить взаимодействие типа "Взаимодействует", то есть когда подразделения равноправны? Если одно из них условно назначить "гл", а второе "подч", то по запросу 'все подразделения, которые "взаимодействуют" друг с другом' отберется только половина подразделений
-
Спасибо, kayten, еще актуально :)
-
по запросу 'все подразделения, которые "взаимодействуют" друг с другом' отберется только половина подразделений
ну это как запрос написать...
если руками, то проблем не будет :о))
-
Согласен. Но есть один вопрос: как в такой схеме отобразить взаимодействие типа "Взаимодействует", то есть когда подразделения равноправны? Если одно из них условно назначить "гл", а второе "подч", то по запросу 'все подразделения, которые "взаимодействуют" друг с другом' отберется только половина подразделений
ну это как запрос написать...
если руками, то проблем не будет :о))
Действительно - не меняя структуры БД, в коде можно просто перечислить типы взаимодействия, по которым подразделения считаются равноправными и для них применить свою логику (если это необходимо). Название Подразделений - гл и подч - это же условность.
Или изменить структуру - ввести в Справочник еще одно поле - признак взаимодействия (равноправный или подчиненный). И разруливать логику по нему.
Второй вариант лучше, если по каим-то причинам возможно изменение признака (раньше взаимодействие считалось "равноправный", а теперь по каким-то причинам "подчиненный"), так как не требует правки кода. А сопровождать справочник, как правило, легче и проще (иногда это можно доверить пользователю системы)) ).