Документарный подход

Исследование документарного состава предметной области всегда было и остается одним из важнейших этапов в проектировании баз данных.

Именно документ дает максимальное количество информации о тех составляющих (атрибутах, связях, структурах), которые должны найти отражение в модели базы данных. Многие информационные системы ориентированы на работу с документами, не выделяя прочих информационных структур и тем самым сильно ограничивая возможности обработки информации. Однако, такой подход к построению информационной системы является тоже обоснованным, когда целью ставится организовать работу сотрудника, подразделения, организации на основе документооборота и работы с документами.

Такая работа с данными долгое время являлась фактически единственным вариантом рассмотрения структур данных, особенно в период отсутствия специализированных подходов и средств для моделирования бизиес- нроцессов организации, а также рассмотрения деятельности организации, подразделения, сотрудника в качестве источника и потребителя информации, представляемой в форме документов. Основной парадигмой в организации деятельности организации всегда рассматривалась работа с документами. И это абсолютно правильно, поскольку только документ может содержать все необходимые для работы достоверные сведения. Именно документарный подход обычно применяется, когда необходимо принимать какие-либо решения.

Процесс использования документарного подхода в проектировании баз данных представляется следующими последовательными этапами.

1. Выделение состава документов, используемых в предметной области.

2. Выделение состава пользователей документов, разделяя их на потребителей, составителей и наполнителей, а также внутренних, внешних и системных.

3. Формирование схемы документооборота между пользователями документов, иллюстрируя не только связь пользователей через документы, но и направленность движения документов, учитывая внешних пользователей.

4. Выделение из документов состава атрибутов, специфицируя их но типам данных, используемости, изменяемости, смысловой нагруженности и т.д.

5. Создание на основе атрибутов атрибутивных сущностей.

6. Установление прямых и косвенных связей между атрибутивными

сущностями.

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

8. Построение конечной (публикация для различных категорий участников процесса разработки) модели базы данных.

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

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

Первые этапы рассмотрения предметной области в информационном плане заключаются в идентификации документов, их структур и движения между пользователями, что для удобства дальнейшего рассмотрения и использования в процессе разработки базы данных представляется в форме таблиц спецификации и соответствующих диаграмм, некоторые из которых были рассмотрены ранее. В результате такого рассмотрения, в рамках используемого примера электронного магазина, разработчиком выделен некоторый состав документов (табл. 4.1).

Таблица 4.1

Пример выделенных документов предметной области ^[1]

№ п/п	Документ	Наименование/Описание
1	Д1	Документ "Заказ" Состав документа представляется указанием на клиента (организация или физическое лицо), дату составления, перечень товаров, которые клиентом заказаны, с указанием цены, количества и стоимости по каждой позиции и общей стоимости заказа в числовом и символьном выражении. Документ формируется клиентом в процессе наполнения "корзины" товарами и передастся оператору п менеджеру по продажам
2	Д2	Документ "Требование-накладная" Состав документа определяет перечень товаров, которые должны быть выданы со склада для отправки клиенту, с указанием количества. Формируется менеджером по продажам и передается на склад
3	дз	Документ "Товарный чек" Состав документа: указание на клиента; перечень заказанных товаров. указание их количества, цены и стоимости; общая стоимость заказа в числовом и символьном выражении; дата и время формирования; ответственное лицо; признаки подтверждения (подпись) от ответственного лица и клиента. Документ формируется бухгалтером п передается от менеджера по продажам клиенту
4	Д4	Документ "Счет" Состав документа содержит сведения об организации-клиенте, заказанных товарах с указанием количества, цены и стоимости, общей стоимости заказа в числовом и символьном выражении, руководителе и бухгалтере продавца, дате выставления, сроке оплаты. Документ формируется бухгалтером и передается в организацию-клиент
5	Д5	Документ "Счет-фактура"

№ п/п	Документ	Наименование/Описание
6	Дб	Документ "Товарная накладная" <...>
7	Д7	Документ "Кассовый чек" <...>

Представленные в таблице описания документов определяют основной атрибутивный состав документов, который дополняется формами документов, откуда можно получить полный перечень атрибутов. Также в описании указывают источник и потребителя документа, представляя сведения о движении документа, что позволяет не только построить схему документооборота, но и выделить состав пользователей документов. Некоторые документы используются вне информационной системы, что требует разделять состав пользователей на внутренних и внешних.

Внутренние пользователи являются генераторами документов, используемых для реализации процессов организации, и представляются сотрудниками этой организации. Внешними пользователями являются такие, которые нс относятся к деятельности организации, но формируют исходные сведения для работы внутренних пользователей или получают результирующие документы от организации. Таким образом, в предметной области могут быть выделены следующие категории пользователей (табл. 4.2).

Таблица 4.2

Пример состава пользователей № Внутрен 11 и й пол ьзоватсл ь Внешний пользователь 1 2 1 Оператор Клиент (физическое лицо) 2 Менеджер по продажам Клиент (организация) 3 Кладовщик 4 Бухгалтер 5 Руководитель

Для удобства дальнейшего использования указателей на соответствующих пользователей, чтобы не указывать полные названия, каждому пользователю присваивается определенный код, который формируется из таблицы состава пользователей по кодам строки и столбца, где указан нужный пользователь. Так, например, для пользователя "Кладовщик", находящегося в строке с кодом "3" и столбце с кодом "1", будет указываться код <3.1>, для пользователя "Клиент (организация)" — <2.2>. Обрамление кода в угловые скобки обусловлено тем, что это позволит однозначно выделить в каком-либо описании этот код, не спутав его с другими кодами или символами описания.

В результате этого описания можно сформировать описание взаимодействия пользователей с документами (табл. 4.3), определяя необходимость

формирования определенных информационных потребностей пользователей, распределив права доступа к документу.

Таблица 43

Пример распределения прав доступа к документам № Документ Пользователь Право доступа 1 Д1 <1.2>, <2.2> С И У Ч П 2 <1.1>, <2.1> И Ч П 3 Д2 <2.1> СИУЧП 4 <3.1 > И Ч П 5 <4.1> Ч П 6 дз <2.1> Ч П 7 <1.2> ч 8 <4.1> С И У ч п 9 <5.1> и ч 10 Д4 <2.2> ч 11 <4.1> СИУЧП 12 <5.1> ич 13 <2.1>, <2.2> ч 14 Д5 <4.1> СИУЧП 15 <2.2> Ч 16 <5.1> ич ... ... ... ...

Для описания нрав доступа используются следующие обозначения:

• С (создание) — операция, предполагающая, что соответствующий пользователь является источником документа, формируя все его основные данные, включая помер документа, дату его создания и многие другие, а также наполняет некоторыми необходимыми сведениями, входящими в его компетентность;

• И (изменение) — операция, определяющая возможность внесения изменений в документ, включая установление определенных признаков, корректировку ранее внесенных и дополнение новых сведений в соответствии со структурой документа;

• У (удаление) — право на уничтожение документа, если этот документ еще не зафиксирован в качестве источника данных или передан в последующую инстанцию для использования;

• Ч (чтение) — право на вывод документа на экран с целью прочтения всех или части данных, записанных в нем;

• П (печать) — право на публикацию документа через печатающее устройство, передачу по каналам связи или с помощью магнитного носителя в виде отдельного файла.

Конечно, данное описание не даст всей полноты информации о правах доступа к документу, поскольку существуют требования по доступу пользователей к отдельным атрибутам или конкретным данным. Например, менеджеры но продажам могут быть разделены по видам товаров и тогда у каждого из них может быть право на модификацию только сведений по товарам, относящимся к соответствующему виду, а читать сведения обо всех товарах в документе. Эти особенности прав доступа определяются при описании отдельных атрибутов, подготавливая информацию для последующего использования при реализации физической базы данных (рис. 4.1).

Рис. 4.1. Пример схемы документооборота

В данной схеме движения документов между участниками информационной системы (пользователями) для удобства чтения диаграммы использованы названия каждого пользователя, но в сложноорганизованных системах диаграммы документооборота могут быть достаточно сложными и использование полных наименований будет только мешать чтению диаграммы, поэтому обычно рекомендуется использовать кодовые обозначения пользователей.

Дальнейшая работа по подготовке информации для моделирования базы данных при документарном подходе требует описания атрибутов каждого документа (табл. 4.4). Поскольку на этом этапе еще неясно, как будут между собой связаны атрибуты и как они будут объединены, то в этом описании представляют все атрибуты каждого документа с указанием их характеристик, основываясь на логическом анализе документа и предметной области, учитывая особенности представления каждого значения описываемого атрибута. Эти описания позволят разработчику в последующем моделировании правильно применить правила нормализации и построить эффективную базу данных.

Таблица 4.4

Описание атрибутов по документам

№ п/п	Документ	№ п/п	Атрибут	Тип данных	Описание
1	Д1	1	Номер заказа	С-Ч	Порядковый номер заказа, формируемый при его составлении, 11 рСДСТа В Л Я еТСЯ С И N1 вол ьно-ч ис - ловмм обозначением в формате СС-ХЫЫ. где первые два символа обозначают тип клиента (физическое лицо, организация), а последние три символа обозначают порядковый числовой номер заказа
		2	Дата заказа	Д	Дата, когда заказ сформирован и отправлен на обработку оператору магазина
		3	Клиент	С	Фамилия, имя, отчество физического лица или наименование организации, делающих заказ
		4	Номер товара	Ч	Порядковый номер товара в таблице заказанных товаров
		5	Товар	С	Наименования заказанных товаров
		6	Количество товара	ч	Количество товара по каждой позиции, которые заказал клиент
		7	Цена товара	ч	Денежное выражение стоимости единицы товара с двумя знаками после десятичной запятой
		8	Стоимость товара	ч	Денежное выражение стоимости указанного количества заказанных товаров с указанием двух знаков после десятичной запятой. Вычисляется перем ножен нем цены товара и его количества
		9	Стоимость заказа	ч	Денежное выражение стоимости всех заказанных товаров с указанием двух знаков после десятичной запятой. Вычисляется суммированием значений стоимости товара но всем позициям заказан! I ых товаров
		10	Символьная стоимость заказа	с	Денежное выражение стоимости заказа, представленное символьной записью
...	...	...	...	...	...

Аналогичным образом описываются вес документы предметной области. При использовании инструментальных средств моделирования базы данных каждый атрибут документа может быть представлен соответствующей сущностью с единственным атрибутом идентичного названия и для которого формируется нужное описание. Представление этой таблицы может быть реализовано в виде отчета получающейся модели базы данных. Однако применение инструментального средства на этом этапе достаточно проблематично ввиду слишком большого количества атрибутов, которые будут сгенерированы.

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