• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Описание оргструктуры предприятия

  • Автор темы LuMee
  • Дата начала
L

LuMee

Подскажите, плз, как лучше всего описать оргструктуру предприятия (у него есть отделы, у отделов - свои отделы, в отделах каждого уровня - люди). Сначала думал обойтись двумя документами: один описывает Отдел, другой - Сотрудника, оба response-to-response. Предполагается, что документы, описывающие подчиненные Отделы, будут ответами на соотв. вышестоящие Отделы, ну а Сотрудники - просто ответы на свои отделы. Однако тут не придумалось, как быть с отделами самого выского уровня, которые ни с чем уже не связаны (соотв-но, не могут быть ответами).
Думал тогда ввести еще один документ, описывающий такой Отдел верхнего уровня, но показалось, что это будет уже слишком запутанно.
Наконец, была мысль вообще сделать документ-Отдел не ответным, а потом эти документы уже программно (с помощью NotesDocument.MakeResponse()) связывать друг с другом, что, впрочем, еще более запутанно.
Расскажите, как обычно это делается?
 
E

Elena Nefedova

Не знаю, как обычно, а у нас документы верхнего уровня - это организации
 
A

Axel

<!--QuoteBegin-Elena Nefedova+10:07:2006, 11:43 -->
<span class="vbquote">(Elena Nefedova @ 10:07:2006, 11:43 )</span><!--QuoteEBegin-->У меня тоже одна. Но можно и две ввести, если потребуется. К тому же, где-то надо хранить реквизиты и прочее
[snapback]39788" rel="nofollow" target="_blank[/snapback]​
[/quote]

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

Мы еще делали подчиненные организации -- то есть организация, которая является юридически самостоятельным лицом, но реально является подразделением более крупной организации.
 
G

Guest

не забудьте только в форме поле $refOptions
 
G

Guest

$refOptions забивает свойство формы Type и позволяет сохранять респонсные документы по форме с тайп Document и наоборот
Разместите cwd-поле $refOptions с формулой @If(@IsResponseDoc; "1"; "0")
в форме документа Подразделения (только не в подформе) - иначе при интерфейсном сохранении ответные документы станут главными (если тип формы - Document) или нотес будет ругаться при сохранении главных документов (если тип формы - Response)
 
V

Veselinka

Модель построения оргструктуры следующая:
1. сущность подразделение. Технологически строится как иерархия документов по альтернативному полю (не $REF)
2. сущность должность - сылается на подразделение (так же альтернативным полем)
3. сущность Сотрудник - назначается на должность, может совмещать несколько должностей.
4. Полномочия, компетенции и пр - является атрибутами должности.
5. Личные данные, резюме, выданные в подотчет матценности, курсы и тренинги пройденные и пр - является атрибутами сотрудника.

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

LuMee

Неужто стандартные методы Lotus, т.е. ответы, так ограничивают?
И потом, если строить связи на основе reference-полей (чтобы иметь возможность строить иерархии во вью на основании этих связей), то при копировании документов в другую БД все эти связи нарушатся.
Если же просто использовать текстовые поля с некими уникальными значениями, то эти связи не отразишь во вью, да и находить связанные документы будет небыстро.
 
G

GROMILA

... при копировании документов в другую БД все эти связи нарушатся.
Я извиняюсь, но задам Вам вопрос в стиле лотус-программистов B)
А ЗАЧЕМ ВАМ КОПИРОВАТЬ ДОКУМЕТЫ В ДРУГУЮ БАЗУ ???????

и отвечу в стиле лотус-программистов :)
НЕ КОПИРУЙТЕ :D))))

(да простят меня лотусисты, но критика не помешает)

Структура предприятия является справочником общего пользования и должна быть ОДНА на всю систему и даже на несколько систем, если речь идет о корпорации!!!

По поводу построения БД
Веселинка правильно рассказала про сущности, добавить нечего.
Замени слово СУЩНОСТЬ на слово ФОРМА и усе будзе добра.

Но вопрос к Веселинке
Технологически строится как иерархия документов по альтернативному полю (не $REF)
А почему не REF и уточните пожалуста про альтернативное поле ????
 
V

valmont

Для: Veselinka

поподрбобнее можно с моделью и желательно на примерах...
 
L

LuMee

Я извиняюсь, но задам Вам вопрос в стиле лотус-программистов :)
А ЗАЧЕМ ВАМ КОПИРОВАТЬ ДОКУМЕТЫ В ДРУГУЮ БАЗУ ???????

и отвечу в стиле лотус-программистов ;)
НЕ КОПИРУЙТЕ :)))))
Ну со структурой организации понятно - одна на всех. А вот в других ситуациях копирование вполне может занадобиться, и тут с альтернативными полями придется изрядно помучиться.
 
L

LuMee

Я извиняюсь, но задам Вам вопрос в стиле лотус-программистов :)
А ЗАЧЕМ ВАМ КОПИРОВАТЬ ДОКУМЕТЫ В ДРУГУЮ БАЗУ ???????

и отвечу в стиле лотус-программистов ;)
НЕ КОПИРУЙТЕ :)))))
Ну со структурой организации понятно - одна на всех. А вот в других ситуациях копирование вполне может занадобиться, и тут с альтернативными полями придется изрядно помучиться.
 
E

Elena Nefedova

Если же просто использовать текстовые поля с некими уникальными значениями, то эти связи не отразишь во вью, да и находить связанные документы будет небыстро.
Еще как отразишь - нужно просто использовать правильную иерархию ключей в поле.
Например, "ЗАО Фреска\Отдел кадров" в категоризированной колонке отображается соответствующим образом.

$Ref - это возможножность, конечно, хорошая, и я часто пользуюсь; но при этом из группы документов можно построить единственное иерархическое дерево, что бывает маловато
 
30.05.2006
1 345
12
BIT
0
$Ref - это возможножность, конечно, хорошая, и я часто пользуюсь; но при этом из группы документов можно построить единственное иерархическое дерево, что бывает маловато
$REF-ов можно сделать несколько! К сожалению, не получилось сделать multivalue ссылочное поле, но несколько ссылок, каждая в своем поле - программно создаются элементарно.
Для отображения деревьев во view потом используется конструкция DEFAULT $REF:=...
 
E

Elena Nefedova

$REF-ов можно сделать несколько! К сожалению, не получилось сделать multivalue ссылочное поле, но несколько ссылок, каждая в своем поле - программно создаются элементарно.
Для отображения деревьев во view потом используется конструкция DEFAULT $REF:=...
А как вы многие $Ref'ы создаете?
У меня в свое время получилось только при помощи копирования имеющихся полей $Ref под другими именами: notesItem.CopyItemToDocument( document, newName$ )
Ну я и решила, что это, наверное, кривизна, и лотусом корректно не поддерживается. И бросила это дело.
Скажите, для DEFAULT $REF=.. обязательно использовать поля типа Response или можно текстовые?
 
L

LuMee

А как вы многие $Ref'ы создаете?
У меня в свое время получилось только при помощи копирования имеющихся полей $Ref под другими именами: notesItem.CopyItemToDocument( document, newName$ )
Ну я и решила, что это, наверное, кривизна, и лотусом корректно не поддерживается. И бросила это дело.
Скажите, для DEFAULT $REF=.. обязательно использовать поля типа Response или можно текстовые?
Годятся только Reference-поля. Жалко, что они не пересчитываются при копировании только (Лотус следит только за $Ref).
 
30.05.2006
1 345
12
BIT
0
Годятся только Reference-поля. Жалко, что они не пересчитываются при копировании только (Лотус следит только за $Ref).
Да, только правильные ссылки. Побочный эффект: "нормальный" $REF использовать нельзя (иначе DEFAULT смысл потеряет).
А если копировать док-ты с сохранением исходных UNID-ов, то все ссылки остаются живыми!
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!