Прошу подсказать. Есть намерение предоставить пользователю (не рядовому, а, скажем, АБД) возможность самому создавать и редактировать различные классификации документов. Фиг его знает, сколько штук ему захочется их создать. Одним так удобно, другим – эдак, третьим – и так и эдак. Поэтому как вариант – таблицы (3 основных - CLASSIFICATIONS_DOCUMENTS, CATEGORIES_DOCUMENTS, DOCUMENTS и 2 связующих trelCLASSIFICATIONS_DOCUMENTS_CATEGORIES_DOCUMENTS, trelCATEGORIES_DOCUMENTS_DOCUMENTS):

CLASSIFICATIONS_DOCUMENTS: idsCLASSIFICATION_ID, chrCLASSIFICATION_NAME

trelCLASSIFICATIONS_DOCUMENTS_CATEGORIES_DOCUMENTS: idsCLASSIFICATION_ID, idsCATEGORY_ID, idsCATEGORY_ID_AS_PARENT

CATEGORIES_DOCUMENTS: idsCATEGORY_ID, chrCATEGORY_NAME

trelCATEGORIES_DOCUMENTS_DOCUMENTS: idsCATEGORY_ID, ids DOCUMENTS_ID

DOCUMENTS: ids DOCUMENTS_ID, chr DOCUMENTS_NAME

Подойдет такой вариант для реализации планируемого функционала? Вопросы прав доступа и т.д. пока не рассматриваем.

Так я вроде бы первый вариант и описал?

2 Estets
Эх, если бы было так…

2 ModelR
> В структурах - да. В тексте же про общность/специфичность категорий ничего не было сказано.
Примем, что общность/специфичность категорий произвольная, т.е. вариант 1. Единственное, кажется, что должны быть СЧЕТА и ЗАЯВКИ (см. ниже).

Попробую расписать постановку задачи и структуру данных максимально полно. Прошу прощения, если будет путано 
Требуется обеспечить хранение и управление документацией (далее – Д). Но Д скорее ближе к архивному варианту, чем к docflow, хотя как сказать. По источнику получения Д делится на получаемую со стороны (в основном – ГОСТы и счета) и разрабатываемую в стенах учреждения (в основном инструкции и заявки). По "виду" Д может быть бумажная и электронная (в основном – файлы Word). Требуется учитывать и отслеживать каждую копию документа (например, если ГОСТ устарел или заменен новым – изымаем у всех сотрудников все копии устаревшего и выдаем копии нового). Соответственно требуется четко знать какой документ отменяет (заменяет и т.д.) другой документ. Если в документах (инструкциях) сделаны изменения нужно знать кто, что и когда поменял. Где какой экземпляр хранится – само собой. Да, кстати, документ может и отсутствовать в учреждении, но в базе быть должен (на него используются ссылки).
Теперь небольшой шаг в сторону. Учреждение формирует заявки на приобретение расходных материалов, оборудования и документов, предоставляет их другим учреждениям, получает счета, оплачивает и т.д. Так вот сами заявки и счета (в смысле физического существования) рассматриваются как документы и к ним должны быть применены все положения предыдущего абзаца.

Описание некоторых таблиц и полей:

DOCUMENTS (ДОКУМЕНТЫ)
blnELECTRONIC_DOCUMENT – был ли документ создан как электронный
blnIT_IS – имеется в наличии
dtmBEGIN – дата начала действия
dtmRECEIVE – дата поступления в подразделение

UNITS_DOCUMENTS (ЭКЗЕМПЛЯРЫ_ДОКУМЕНТОВ)

CLASSIFICATIONS_DOCUMENTS (КЛАССИФИКАЦИИ_ДОКУМЕНТОВ)

CATEGORIES_DOCUMENTS (КАТЕГОРИИ_ДОКУМЕНТОВ)

RELATIONS_DOCUMENTS (ОТНОШЕНИЯ_МЕЖДУ_ДОКУМЕНТАМИ)
idsDOCUMENT_ID - Код документа, к которому осуществляется отношение (заменяемый, дополняемый и т.д.)
idsDOCUMENT_ID_AS_PARENT - Код документа, которым осуществляется отношение (заменяющий, дополняющий и т.д.)

TYPES_RELATIONS_DOCUMENTS (ТИПЫ ОТНОШЕНИЙ МЕЖДУ ДОКУМЕНТАМИ) (замена, дополнение и т.д.)

STATUSES_DOCUMENTS (СТАТУСЫ_ДОКУМЕНТОВ) - Статусы документов (изъят, сдан в архив и т.д.)

CHANGES_DOCUMENTS (ИЗМЕНЕНИЯ_В_ДОКУМЕНТАХ)
memPRIMARY_INFORMATION – что поменяли
memLAST_INFORMATION – на что поменяли
chrPLACE_IN_DOC – место в документе
lngREASON – причина изменений
idsPERSONA_ID – ответственный за внесение изменения

VERSIONS_ELEC_DOCS (ВЕРСИИ_ЭЛЕКТРОННЫХ_ДОКУМЕНТОВ)

STATUSES_BUSY (СТАТУСЫ_ЗАНЯТОСТИ) - Статусы занятости в той или иной работе (разработчик, ответственный и т.д.)

REQUESTS (ЗАЯВКИ)

BILLS (СЧЕТА)

Прикладываю также схему (поля жирным шрифтом – ключевые)

2 guest_20040621

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

> Если Вы регистрируете дату начала действия документа, регистрируйте и основание начала действия
> (регистрация в Минюсте, публикация, распоряжение и пр.). Возможен вариант, когда Вы получили
> количество экземпляров меньше, чем заказано? Значит, не все подразделения получат свой экземпляр
> одновременно.
Да нет, этого вроде бы не требуется. Учреждение обязано руководствоваться документом с того времени, когда он поступил в него. Заказывается один экземпляр, затем он размножается и раздается в подразделения (правовую сторону этого вопроса опустим). Так что можно сказать, что все подразделения получают его одновременно. Если же мы будем пытаться исправлять возможно напортаченное между датой вступления в силу документа и датой его поступления в учреждение (а это может быть не один год), то, боюсь, никто не сможет предсказать к чему это может привести. По счастью, такие ситуации бывают редко (я имею ввиду разницу в сроках). И еще никогда не было необходимости что-то переделывать. Хорошо, что документы и не сильно меняются. В основном от редакции к редакции там тоже самое, только другими словами. Хотя, конечно, потенциальные грабли есть. И в принципе, дату вступления документов в силу можно регистрировать хотя бы для того, чтобы потом, собрав статистику как много документов мы получили не вовремя, ткнуть ей в нос начальству. Глядишь, оно осознает, что это большая нужная работа.


> Вы сами через год не вспомните, что имели в виду под классификацией, а что - под категоризацией.
Согласен, можно оставить одну таблицу, скажем, CATEGORIES (idsCATEGORY_ID, chrCATEGORY_NAME), а отношения между категориями "многие-ко-многим" вынести в отдельную trelCATEGORIES_RELATIONS (idsCATEGORY_ID, idsCATEGORY_ID_PARENT)? Хотя, по сути, это практически одно и тоже, но с точки зрения структур данных, наверное, будет правильнее. Ну и Ваше замечание совершенно справедливо. Только вот сложно будет установить группу для какой-л. части категорий, которые будут к ней относиться. Скажем, удобно в одних случаях классифицировать по "нопмеклатуре" (ГОСТ, РД и т.д.), в других случаях удобно сделать разбивку по назначению документов внутри учреждения, без оглядки на их "номенклатуру". В первоначальном варианте это делается легко. Кстати, Estets тоже выделил классификаторы. А что предлагаете Вы?


> Я бы порекомендовал описать это как жизненный цикл документа; просто регистрации отношений
> недостаточно.
Нужно обеспечить отслеживание - когда какой документ приобрел тот или иной статус. Если он был заменен другим документом – это нужно тоже проследить. Возможно, здесь у меня путаница в терминологии. Статусами (STATUSES_DOCUMENTS) я назвал состояния документа как бы самого по себе (изъят, сдан в архив и т.д.). А отношениями между документами (RELATIONS_DOCUMENTS) – состояния документа, возникающие по отношению к другим документам.
Можно такой вариант: TYPES_RELATIONS_DOCUMENTS обозначает тип отношений между документами (замена, отмена и т.д.). Таблица trelRELATIONS_DOCUMENTS обозначает отношения между документами и время наступления этих отношений, для чего добавим поле с датой dtmDATE_BEGIN_RELATION. Таблицу статусов (STATUSES) переименовываем в СОСТОЯНИЯ (CONDITIONS), смысловое наполнение ее останется тем же, но привязано будет не к документу, а к экземпляру документа (это и правильно – ведь изымают, сдают в архив и т.д. не документ вообще, а конкретный экземпляр).
Может быть, я не очень представляю себе жизненный цикл документа, но в моей схеме основные стороны вроде бы отражены? История перемещения экземпляров между лицами и местами хранения, плюс то, что изложено выше. Что еще важное я упустил?

Меня больше затрудняет засовывание в эту схему заявок и счетов. Собственно, в приведенном мной варианте оно никак не реализовано. Можно попробовать сделать "жесткие" категории – СЧЕТА и ЗАЯВКИ.

2 ModelR
> Для вопроса на форум слишком много всего сразу.
Да, согласен, с поправкой – не на форум, а для одного топика. С другой стороны, все связано, не стоит раздергивать?

> По изменениям. На ГОСТы вроде выпускаются специальные документы Извещение об изменении.
> Одно извещение может менять несколько ГОСТов.
> Организация внесения изменений по Извещениям в учтенные бумажные копии ГОСТов может быть
> разной. Либо нужно организовывать рассылку копий извещений оставляя внесение изменений на совести
> абонентов, либо горы (бумажные копии ГОСТов) должны ходить к Магомету (отдел стандартизации), либо
> Магомет обходить горы. Соответственно и базы несколько разные. В худшем случае могут применяться
> все три способа для разных подразделений.
> Естественно, сами Извещения как документы подлежат регистрации.
Я думаю, это уложится в отношениях, описанных в trelRELATIONS_DOCUMENTS. Пользователь в курсе, что есть документ, изменяющий в какой-л. части другой. Дальше его дело – знакомиться с этим изменением или нет.
В таблице CHANGES_DOCUMENTS я подразумевал изменения, внесенные в документы, разработанные внутри учреждения по окончании разработки. Может быть, ее как-н. связать с таблицей VERSIONS_ELEC_DOCS?
Чуть подробнее об этой последней таблице. В процессе разработки какого-л. документа над ним могут работать в несколько заходов, да еще несколько человек. Естественно, что могут быть допущены ошибки или просто принято решение вернуться к более удачной ранней версии. Чтобы не исправлять единственную оставшуюся последнюю версию, подумал, что было бы неплохо хранить их все. Если кто-то открывает документ, чтобы там что-то отредактировать, то автоматически создается новая копия, к названию файла добавляется очередной номер версии, в базе прописывается пользователь, сотворивший сие. Не пришел пока к решению, что делать, когда разработка закончена. То ли удалять предыдущие версии, то ли нет. Может быть, что и после окончания разработки найдутся ошибки.
Еще можно такой вариант. Документы все равно разрабатываются на компьютере и изменения в них вносятся там же. Поэтому для этого можно использовать таблицу VERSIONS_ELEC_DOCS. Где-н. только ставить флаг, что разработка закончена, чтобы все изменения, сделанные после этой даты, брались на контроль и немедленно отзывались устаревшие бумажные (электронные) копии и т.д. А таблицу CHANGES_DOCUMENTS использовать для отслеживания изменений, отмен и т.д. в документах, приходящих извне (типа ГОСТов). Правда, не знаю, есть ли смысл городить огород с отслеживанием изменений конкретной информации (что на что), т.к. обычно они сводятся к изложению того же самого другими словами. Т.е. пользователь в курсе, что есть документ, изменяющий в какой-л. части другой. Дальше его дело – знакомиться с этим изменением или нет.

2 Сам себе (на всеобщее обсуждение)
> Меня больше затрудняет засовывание в эту схему заявок и счетов. Собственно, в приведенном
> мной варианте оно никак не реализовано. Можно попробовать сделать "жесткие" категории – СЧЕТА
> и ЗАЯВКИ.
Можно попробовать создать таблицы связи между экземплярами документов и счетами (заявками) – trelUNITS_DOCS_BILLS (trelUNITS_DOCS_REQUESTS). Не очень красиво, конечно, но лучше ничего не придумалось.
Вопросы вызывает и таблица trelREQUESTS_BILLS. В предложенном варианте в одной позиции (т.е. строке) будет заполнен только один столбец из idsDOCUMENT_ID, idsMATERIAL_ID, idsDEVICE_ID, для двух других придется ставить NULL, что не очень хорошо. Зато нет потенциальных проблем с идентификацией. Или можно прикрутить доп. таблицу с обозначением вида заявляемого (документ, материал или оборудование) и на уровне бизнес-логики предлагать вставлять в столбец идентификатор документа, материала или оборудования, но тогда могут быть потенциальные проблемы с целостностью и непротиворечивостью в случае удаления/изменения идентификатора. Хотя вроде бы при такой схеме изменений идентификаторов не должно быть, а удаление записей будет только логическим.
Странно, что по теме больше нет никаких комментариев… То ли все хорошо, то ли очень плохо?

Неужели тема себя исчерпала?

Спасибо, пошел искать.

Спасибо за наводки. Посмотрел www.documentum.ru. Правда, именно классификации документов я не нашел, но почитать было очень интересно. Если только под классификацией имелось ввиду разделение документов на финансовые, технические, организационные?
А вот что особенно заинтересовало - подсистема информационных сообщений для пользователей. Т.е. когда любое (как я понял) событие в базе может порождать сообщение определенного типа. Интересно, ну, если это жестко в коде зашить, то еще туда-сюда, но если это еще и устанавливать можно, то вообще непонятно как они это сделали. Но круто!