Разработка крупных проектов на Access-97 (ч.1) - (NSA) |
Автор Андрей Гордиенко | ||||||
18.11.2001 г. | ||||||
Статья написана уже давно. Первая ее часть (анализ быстродействия для клиент-серверных реализаций) совершенно потеряла актуальность после выхода в свет Access-2000 и возможность разрабатывать ADP-приложения. Некоторые идеи второй части также претерпели существенные изменения с того времени
Некоторые соображения по поводу разработки крупных проектов на Access-97 (оригинал) Статья написана уже давно. Первая ее часть (анализ быстродействия для клиент-серверных реализаций) совершенно потеряла актуальность после выхода в свет Access-2000 и возможность разрабатывать ADP-приложения. Некоторые идеи второй части также претерпели существенные изменения с того времени. Андрей Гордиенко Ни в коей мере не претендую на знание истины в конечной инстанции. Хочу поделиться своими соображениями по поводу разработки крупных проектов. Возможно, кому-то эта информация поможет. Все сказанное ниже относится к Access-97 в составе русского MS Office-97. MS Access НЕ является подходящим инструментом для крупных проектов. Это первая и важная мысль, которую нужно "подумать" прежде чем браться за проект.
Однако, не смотря на выше перечисленные аргументы, вы либо ваше руководство может, тем не менее, прийти к решению разрабатывать крупный проект средствами MS Access. Причин тому может быть множество, среди которых:
Таким образом, если вы все-таки решили использовать MS Access, то следующие усилия должны быть направлены на преодоление перечисленных выше недостатков MS Access. А именно:
О технологии "клиент-сервер" Возможно, вы тешите себя надеждой на то, что в дальнейшем сможете перевести свой проект на технологию "клиент-сервер". В таком случае необходимо заранее построить структуру проекта таким образом, чтобы его можно было перевести на работу с SQL-сервером наименьшими усилиями. Если вы полагаетесь на всякого рода мастера или самостоятельные case-средства (например, ErWin), то ожидания вас могут обмануть. Я пытался использовать MS Upsizing Tools v 8.10.0128 для перевода серверной базы данных (содержащей только таблицы и связи между ними) в MS SQL Server v 6.5. Не то, чтобы СОВСЕМ ничего не вышло, но по крайней мере половина информации перенеслась некорректно. В частности, не на всех таблицах установился PRIMARY KEY там, где он стоит в Access. Некорректно построились поля типа "счетчик" - в SQL Server они потеряли способность к автоинкрементации. Подозреваю, что проблемы связаны с несовместимостью данного визарда с русским Accessом, хотя все таблицы и наименования полей я задавал только латинскими буквами. Необходимость "перелопачивать" вручную после визарда все самому плюс отсутствие возможности изменить настройки ключа на уже созданной таблице (см. выше) приводит к тому, что трудоемкость перевода таблиц с использованием визарда соизмерима с трудоемкостью "рукопашного" перевода. Пытался построить структуру таблиц и связей между ними в ErWin, а затем качнуть их в Access и в SQL Server. В Access качает терпимо (особых нарушений логики я не заметил). А вот в SQL Server - врет. Толи я с ним плохо разобрался, то ли его плохо кракнули. Есть там еще одна проблема. На сколько я понял, он годится только для стартовой подготовки проекта. Если таблицы уже заполнены информацией, и вы производите модификацию проекта параллельно с его эксплуатацией - для этих целей он вообще не годится. Ну и кроме того, он однобокий и работает только в направлении ОТ ErWin. Структуру базы, изначально сделанной в Access, качнуть в ErWin мне не удалось. Таким образом, на сегодняшний день мне не известны средства, позволяющие легко и просто перевести серверную БД Access в БД SQL Server (возможно, они известны кому-либо из читателей - с удовольствием выслушаю советы и пожелания). Есть слабая надежда на то, что к моменту подрумянивания проекта такие средства найти удастся. Однако, сильно на это я не рассчитываю, и полагаюсь больше на собственные силы. А по сему собственный проект разрабатываю таким образом, чтобы "рукопашный" перенос в SQL Server был наименее болезненным. Для этого в одном из модулей сделал глобальные функции обращения к запросам и таблицам через объект Recordset. В специальной "системной" таблице заведен перечень всех остальных таблиц и указано место нахождение таблицы - в БД Access или БД SQL Server. В дальнейшем при переносе таблицы на SQL-сервер достаточно будет поставить галочку в соответствующей записи "системной" таблицы, чтобы все программные обращения к "переехавшей" таблице переадресовать на SQL Server. Аналогично с SQL-запросами. Функция программного создания объекта Recordset на базе "на ходу компонующегося" текста SQL принимает дополнительный параметр, через который сообщается место запуска запроса. В зависимости от источников данных запрос может быть запущен в Access, а может быть переадресован серверу. Поскольку диалекты языка SQL в Access и на сервере различаются, добавляю минимальный синтаксический анализатор, который модифицирует уже сформированный запрос на SQL Access в Transact-SQL (убирает завершающую точку с запятой, заменяет конструкции с nz() и т.п.). При программировании в среде Access нужно сразу учесть ограничения SQL-сервера. В частности, он сможет открыть только на чтение запрос, в котором есть фраза SORT BY (а Access может и на запись!). Перевод на SQL-сервер серверной части Access-ного проекта (БД, содержащая только таблицы и связи между ними) может не только не привести к существенному ускорению в работе, но и замедлить работу, поскольку обращение идет через ODBC-драйвер, а объемы передаваемой по сети информации не уменьшатся. Для получения ускорения придется переводить на SQL-сервер все запросы (в форме View), по возможности использовать курсоры и хранимые процедуры. Одним словом, переносить существенную долю обработки данных с клиентской части на серверную (это принято называть переходом от технологии "толстого" клиента к технологии "тонкого" клиента). Такой переход должен производиться поэтапно. На первом этапе производится постепенный перенос таблиц без получения существенного выигрыша в быстродействии. На втором этапе - все запросы переадресовываются на сервер (это может еще больше снизить быстродействие). На третьем - придется переводить запросы в View и хранимые процедуры сервера. Это довольно трудоемко, но только на этом этапе реально получить выигрыш от перехода на технологию "клиент-сервер". Проводился такой эксперимент. Создавали таблицу на MS SQL Server 6.5 объемом около 300000 записей. Затем пытались интерактивно с ней работать из Access двумя способами:
В первом и в третьем случае перемещение к последней записи производилось почти мгновенно. Во втором - с задержкой на пару минут. Я пришел к выводу, что работать SQL сервером лучше через линки к View, которые "видны" в Access как присоединенные таблицы. О базовой структуре системы, ее объектах и администрировании Откровенно говоря, я бы не взялся за Access, если бы нормально все работало в 1С:Предприятии v 7.5 (с SQL-сервером). Просто великолепная концепция этого продукта полностью перечеркнута качеством его реализации. Такое количество ошибок и глюков отсутствует даже в микромягких бета-версиях. Попытка наладить надежный контакт с производителем для устранения выявленных ошибок не удалась не смотря на то, что продукт был приобретен официально. Однако, концепция объектов там выбрана очень красиво, и при программировании на Access я стараюсь придерживаться тамошних базовых понятий, хотя привношу собственные идеи и подходы. Вкратце дело обстоит так. Базовые объекты проекта должны быть не "таблицы", "запросы", "формы", "макросы" и "модули", а "справочники", "регистры", "журналы", "документы", "отчеты". Эти понятия гораздо ближе к предметной области (далее они называются "макрообъекты"), и по этим понятиям легче всего разбить проект на модули, чтобы убить сразу трех зайцев:
Ниже вкратце рассмотрена структура и назначение каждого макрообъекта. Справочник - это просто перечень чего-либо, в общем случае открытый для пополнения и корректировки. Пример - справочник контрагентов, справочник номенклатуры. Он предназначен для построения аналитических разрезов регистров и журналов, для ссылок из других справочников (нормализация и удобство работы), для ссылок из документов. В общем случае он может быть иерархическим, причем с большим количеством уровней иерархии (группы товара - подгруппы товара - :. - номенклатурная позиция). Одни справочники могут "подчиняться" другим. К примеру, справочник "Города" может подчиняться справочнику "Страны". В этом случае каждая запись справочника "Города" имеет внутреннюю привязку к определенной записи справочника "Страны". При выборе записи из справочника "Города" сначала необходимо выбрать запись в справочнике "Страны", после чего в подчиненном справочнике производится выбор из числа только тех городов, которые находятся в указанной стране. Для иерархического справочника необходимо задать правила его ведения. Можно ли на одном уровне размещать группы и простые элементы, задать перечень полей, указать, какие из них используются только для групп, какие только для простых элементов, а какие в обоих случаях, какие из полей работают в механизме наследования. Поскольку проект крупный, наверняка он выполняется для солидной конторы, для которой фраза "коммерческая тайна" не является пустым звуком. Посему необходимо разграничение доступа к справочникам на уровне записи. Механизм защиты на уровне записи должен предусматривать возможность закрытия от редактирования верхних уровней иерархического справочника определенным группам пользователей (иначе какой-нибудь кладовщик случайно может удалить или испортить наименование целой группы товаров). Если в справочниках содержится конфиденциальная информация, для определенного круга пользователей даже на просмотр должно выводиться не все содержимое справочника, а только разрешенное ему для просмотра. Следует сказать пару слов о механизме наследования. В номенклатурном справочнике для группы товара может быть задан перечень технических характеристик (выбирается из справочника "Характеристики"). При добавлении любых записей в номенклатурную группу "Насосы" они автоматически наследуют перечень характеристик из родительской записи. При этом остается возможность его откорректировать, уточнить и дополнить. К примеру, для подгруппы "Насосы К8/18" можно задать значение некоторых характеристик: высота=0,321м, ширина=0,257м, длина=0,768м, масса=64кг. При дальнейшем вводе конкретного насоса в эту подгруппу он наследует перечень характеристик ВМЕСТЕ С ИХ ЗНАЧЕНИЯМИ. Для характеристик, значения которых не заданы, они запрашиваются в диалоге (поскольку предполагается, что для простого элемента справочника они должны быть заданы). Механизм наследования позволяет сильно облегчить работу по заполнению справочника и его ведению (подправить пару технических характеристик проще, чем вводить весь их перечень от начала до конца и задавать значения). К слову, поиск товара по характеристикам с учетом имеющихся остатков - задача, которую я не видел реализованной ни в одной тиражируемой системе оперативного учета. Для устранения возможной путаницы, ошибок ввода и т.п. при ведении иерархического справочника, для вновь созданной группы должны фиксироваться правила ввода информации внутри этой группы (допускается ли ввод подгрупп, простых элементов, или и того и другого), а также справочная информация для облегчения дальнейшей группировки. К примеру, руководитель отдела ввел в номенклатурный справочник группу "Насосы" и указал, что внутри этой группы должны формироваться только товарные подгруппы (не наименования конкретных насосов!), причем подгруппы формируются по признаку ("Марка насосной части"). Когда рядовой сотрудник захочет добавить в группу "Насосы" новый насос, у него перед глазами "повиснет" информация о том, ЧТО он должен вводить на следующем уровне - "Марка насосной части!". Волей-неволей отпадет желание группировать товар на этом уровне по мощности двигателя. Представляете, что будет в справочнике, если каждый начнет группировать по одному ему ведомым критериям? Справочник на первый взгляд кажется объектом, хранящим информацию статического плана. Однако, это не совсем так Допустим, у вас есть справочник контрагентов, и в нем запись "Фирма ЛТД", которая задействована в каких-то документах, регистрах и т.д. Через два года контрагент присылает вам извещение о том, что он изменил название на "Фирма ДДТ". Что выбудете делать? Откорректируете запись справочника? Тогда при попытке распечатать любой старый документ в нем будет фигурировать новое название. Если оставите старое наименование, оно будет распечатываться в новых документах и тоже все испортит. Если вы создадите отдельную запись с отдельным наименованием, система никогда не догадается, что обороты по двум разным контрагентам "Фирма ЛТД" и "Фирма ДДТ" необходимо сгруппировать вместе, поскольку на самом деле это один и тот же контрагент. Подобных примеров можно привести множество (смена фамилии при выходе замуж, смена ставки налога и т.д.). Справочник должен иметь возможность корректно отрабатывать подобные ситуации. Ну и желательно предоставить администратору пути выяснить в дальнейшем, кто ввел в справочник некорректную запись или удалил жизненно важную информацию. Все это делается с помощью концепции "не удаляй физически". Любая запись любого справочника имеет "системные" поля, в которые записывается специальная информация - календарная дата и время создания, учетная дата и время создания (начиная с которой запись считается действительной в учете), ссылка на пользователя, создавшего запись, календарная дата и время удаления, учетная дата и время удаления (начиная с которой запись считается недействительной в учете) и ссылка на пользователя, удалившего запись. Если запись справочника действительна в настоящий момент, то три последних поля пустые. Если кто-либо производит корректировку записи, старая запись помечается как удаленная, причем фиксируется дата календарная, учетная и автор удаления (кто корректировал), а в справочнике автоматически появляется новая запись с тем же самым ID, но с новым содержимым полей. Первые три "системные" поля у нее совпадают с содержимым трех последних "системных" полей в удаленной записи. При многократных корректировках создается множество записей, причем в любой момент учетного времени не более одной из них может считаться действительной. Если же запись удаляется пользователем, она помечается как удаленная (с записью соответствующей информации в системные поля), а новая более не создается. При такой схеме не возникает проблемы с исправлением "Фирмы ЛТД" на "Фирму ДДТ". Справочник сам спросит, с какого учетного времени зафиксировать это изменение. В прежних учетных периодах во всех документах действительной будет фигурировать запись "Фирма ЛТД", а в новых "Фирма ДДТ". Поскольку у записей одинаковый ID, и обороты по ним будут собираться как по одному контрагенту. А если системный администратор захочет посмотреть, кто когда что изменял или удалял, у него всегда есть такая возможность - эта информация лежит в самом справочнике, и не нужен отдельный LOG на каждый чих (в который, по сути все записывается по второму разу, да еще пойди найди то, что нужно:). Необходимо учесть, что справочник может иметь несколько визуальных форм. Например, подробный для просмотра (основная часть GRID-образная), краткий для выбора (основная часть GRID-образная), для ввода/корректировки простого элемента (бланкоподобная на одну запись), для ввода/корректировки группы (бланкоподобная на одну запись), для вывода на печать (отчет!). Запись справочника идентифицируется уникальным ID.
Справочник содержит некоторую совокупность объектов MS Access (таблиц, форм, запросов, отчетов и т.д.). В специальной "системной" таблице прописывается набор компонентов Access, из которых строится конкретный справочник. Специально помечается главная форма (используемая для просмотра и выбора). Специально помечается главная таблица (в которой хранится ID записи справочника). Через эту же "системную" таблицу, хранящую описание компонентов справочника, производится администрирование на уровне объектов типа "справочник" (права доступа). В связке с этой "системной" таблицей хранится схема размножения прав доступа к справочнику на компоненты уровня Access. Если в дальнейшем администратор будет изменять права доступа к справочнику, специальный модуль администрирования сам найдет все формы, таблицы, запросы и т.д. и изменит к ним права доступа на уровне MS Access.
Как обычно, проект разбивается на серверную часть (с таблицами) и клиентскую часть (все остальное). При изменении прав доступа пользователей к справочнику модуль администрирования прописывает права доступа к таблицам в серверной части и к линкам в клиентской части, за которой работает администратор. Кроме того, он корректирует права доступа к запросам и формам в клиентской части, ЗА КОТОРОЙ РАБОТАЕТ АДМИНИСТРАТОР. После этого в клиентской части в специальной таблице VERSION увеличивается на единицу номер версии, а сама клиентская часть копируется на сетевой диск, с которого должно производиться ее "размножение" по остальным пользователям. При очередном запуске приложения с места какого-нибудь кладовщика запускается не сама клиентская часть, а небольшой MDB-файл, который сравнивает номер версии клиентской части на сетевом диске "для размножения" с номером версии клиентской части на локальном диске самого кладовщика. Если версии не совпадают, запускается копирование клиентской части с "диска размножения" на локальный диск пользователя, после чего свежескопированной клиентской части передается управление. Так производится автоматическое обновление версий клиентской части и размножение прав доступа к объектам по всем клиентским частям. Может, все это работает не так оперативно, как хотелось бы, но лучше придумать не удалось. С помощью такого подхода решается еще одна серьезная проблема - взаимные помехи работающих пользователей и развивающего систему программиста. Чаще всего изменения производятся именно в клиентской части. Программист может снять копию с действующей клиентской части, внести в нее изменения, переустановить номер версии и "вывалить" на сетевой диск для размножения. Размножится по пользователям она сама. Пара слов о том маленьком MDB-файле, который сверяет и копирует версии. Сам он не обновляется. Поэтому именно в нем я храню индивидуальные настройки пользователя. В частности, там сохраняется информация о том, в какие места каких справочников пользователь заглядывал в последний раз. В связи с этим, даже после смены версии, справочник у пользователя развернется именно на том месте, где он его "смотрел" в последний раз. Это исключает лишние шевеления пользователя, связанные с навигацией по справочнику для попадания в нужный ему раздел при каждом его открытии (представьте, что некий коммерсант работает в основном только с одной группой товара - зачем его заставлять каждый раз искать в справочнике эту группу?). Любое обращение к справочникам производится через вызов глобальной функции, которой передается имя справочника, код действия (выбор, просмотр/редактирование и т.д.) и место начального позиционирования. Регистр - это аналог бухгалтерского счета. На нем учитывается ДВИЖЕНИЕ ресурсов. Под ресурсами понимаются деньги, материальные ценности, ценные бумаги, дебиторская и кредиторская задолженность и т.д. По одному регистру может вестись учет движения одновременно нескольких ресурсов (например, суммового выражения товара в рублях, в валюте, и количества в натуральном выражении - итого 3 ресурса). Для отслеживания движения в определенных аналитических разрезах, у регистра назначаются аналитические уровни (в виде набора ссылок на справочники). Структура регистра должна быть построена таким образом, чтобы легко и удобно можно было строить запросы типа "каков остаток такой-то номенклатуры товара (в рублях, валюте, в штуках) на всех складах на такую-то дату?", "сколько пришло такой-то номенклатуры товара (в рублях, валюте, в штуках) на такой-то склад с такой-то по такую-то дату?", "сколько ушло товара в суммовом выражении всех номенклатур со всех складов с такой-то по такую-то дату?" и т.д. Кстати, в данном случае, "Склад" и "Номенклатура товара" выступают в качестве аналитических разрезов регистра "Товар" в виде ссылок на соответствующие справочники. Очевидно, что объем регистра может очень быстро расти. Типичная проблема - как достаточно быстро получить остатки по регистру на любую учетную дату, если отражается в нем только движение? Обычно регистр дробится на отрезки определенной протяженности, между которыми фиксируются промежуточные значения остатков. Фиксировать остатки после КАЖДОГО движения не рационально - слишком много в регистре будет информации, которую можно получить расчетным путем, и слишком велико потребление вычислительных ресурсов на пересчет всех остатков при проведении операций "задним числом". Однако, завязывать систему на операции "закрытия учетного периода" тоже некрасиво. В крупной системе пользователи должны иметь возможность вполне нормально работать в разных учетных периодах без каких-либо взаимных помех. Я предпочитаю, чтобы промежуточные остатки по регистру вообще не привязывались к учетному периоду. В своем проекте я привязываю их к критическому количеству прошедших по регистру движений. К примеру, промежуточные остатки могут подсчитываться после каждых 100 движений регистра с одинаковыми аналитическими признаками. В этом случае регистр сам сохранит несколько промежуточных значений остатков даже на протяжении одного дня, если по регистру "товары" за 1 день произошло около 300 движений одной номенклатуры на одном и том же складе. И в то же время по регистру "Ценные бумаги" может несколько кварталов учетного времени вообще не подсчитываться промежуточный остаток, если по этому регистру осуществляются единичные движения. Для получения остатков на запрошенную пользователем дату система извлекает из регистра ближайший к запрошенной дате промежуточный остаток (хранящийся в регистре), добавляет приход и вычитает расход за период до запрошенной даты и расчетным путем получает остаток на запрошенную дату. Технология расчета промежуточных остатков через 100 записей гарантирует, что при этом будет просмотрено не более 100 записей, и время ответа системы будет приемлемым. Регистр, как и справочник, представляет некоторую совокупность таблиц, запросов, форм и отчетов. Основные идеи по администрированию и организации совпадают с аналогичными для справочника. Следует заметить лишь некоторые особенности этого макрообъекта. Должно существовать специфическое право на закрытие/открытие учетных периодов регистра. Оно дается руководителям определенного уровня (например, главному бухгалтеру). В случае, если за прошедший период произведена выверка регистра (например, движения денежных ресурсов по кассе), все документы за этот период обработаны, и необходимо исключить возможность случайного проведения какого-либо документа этим периодом, главный бухгалтер должен иметь возможность "закрыть" регистр за этот учетный период. Ну, соответственно, и открыть в случае необходимости. Движение в регистре может происходить только при сохранении в системе электронных документов. Каждое движение в регистре хранит ссылку на вызвавший это движение документ (первопричину). В случае внесения изменений в документ или его удаления движение в регистре корректируется соответствующим образом (см. замечание о принципе "не удаляй физически"). К регистру могут быть привязаны особые функции контроля. Например, запрет движения, либо выдача предупреждения регистра при отрицательных остатках на складе, либо превышении лимита по кассе. Кстати, об отрицательных остатках товара. Почти все известные мне программные продукты "спотыкаются" об один и тот же подводный камень, который не мешало бы иметь в виду. Представьте, что на начало месяца на складе имеется 10 единиц товара. Юзер берет из вороха первичных документов на столе первый попавшийся (а там сверху обычно лежат те, которые сдали позже). Ему попадается накладная от 22 числа на отпуск 8 единиц товара. Он ее вводит в систему. Регистр проверяет: на 22 число есть 10 единиц товара, значит 8 можно отпустить - и молча выполняет операцию. После этого юзер берет следующую накладную - тоже расходную, но от 11 числа на 7 единиц товара и вводит ее в систему. Регистр проверяет: на 11 число есть 10 единиц товара, значит 7 можно отпустить. И опять молча разрешает операцию. А в результате по двум накладным отпущено 7+8=15 единиц, на 5 больше, чем было изначально. 22 числа возникает отрицательный остаток -5 единиц, который система не отловила. Контроль неотрицательности остатков должен производиться не на момент выполнения операции, а на всем протяжении учетного времени начиная от момента выполнении операции до самой последней совершенной операции. Любые движения регистра производятся через процедуру, которой передаются аргументы: имя регистра, код действия (приход/расход/вступит.остатки), набор аналитик для выполнения движения, набор ресурсов. Получение сводной информации об остатках или оборотах по регистру с любой степенью сворачивания или разворачивания аналитик производятся через пару процедур (одна для оборотов, другая для остатков). Документ - это некоторая форма, содержащая набор унарных полей (для одного документа ровно одно значение, например, поставщик в накладной) и grid-образную часть (каждое поле в которой может иметь множество значений, например, наименование номенклатуры в накладной). Документ может быть помечен как "черновик". В этом случае он просто сохраняется в архиве черновых документов, не вызывая никакого движения по регистрам. Если при вводе нового документа в систему на нем не поставлена метка "черновик", либо эта метка снята, запускается процедура проведения документа, которая привязывается к настройкам документам и вызывает движение по регистрам. Эта процедура выполняется в режиме транзакции. Если выполнить все движения регистров по какой-либо причине не удалось, производится откат транзакции, и документ возвращается в состояние до попытки его сохранения. Обработка проведения - это модуль, привязанный к форме документа и запускаемый в момент попытки сохранения документа, либо снятия метки "черновик". В случае внесения изменений в документ, старый вариант документа логически уничтожается (с откатом всех произведенных им движений в регистрах) и создается новый - в новой редакции (с повторным движением регистров). Таким образом, имеется возможность просмотра истории изменений одного и того же документа. Документ имеет, как правило, две формы - экранную для ввода и коррекции информации (форма MS Access) и печатную для вывода на бумагу (отчет MS Access). Документ так же, как регистр и справочник, представляет некоторую совокупность таблиц, запросов, форм и отчетов. Так же задействован в общей схеме администрирования и управления правами доступа. Документ одного вида может иметь специальные модули формирования на базе ранее оформленного документа, в том числе другого вида. Так, по ранее оформленному счету должна иметься возможность сформировать накладную и счет-фактуру, по накладной - счет и счет-фактуру, по счету-фактуре - накладную и счет. Должна иметься возможность установки гипертекстовых ссылок из одних документов в другие, с ними связанных (независимо от того, одинаковый у них тип или разный, и к каким учетным периодам они относятся). Должны быть разработаны специальные функции для обращения к полям документов и процедуры для запуска "бланка" документа для ввода нового документа, корректировки или удаления существующего. Журнал - массив информации, в который заносится информация о сохраненных в системе документах. Он играет роль своего рода предметного указателя для быстрого поиска нужного документа. В системе необходимо иметь один общий журнал, в котором аккумулируется информация о ВСЕХ документах ВСЕХ типов, по одному журналу на один вид документа (для поиска документа нужного вида), а так же произвольное количество журналов, в которые записывается информация о документах разного вида, объединяемых по какому-либо признаку (например, все виды накладных - приходные, расходные, на внутреннее перемещение и т.д.). Таким образом, во время записи документа в систему он проходит регистрацию в нескольких журналах. Настройки журнала содержат информацию о перечнях документов, которые должны проходить регистрацию в журнале и схему привязки полей журнала и документов. Журнал содержит поисковые средства, с помощью которых можно произвести поиск или отбор документов по совокупности полей журнала, а также простейшие средства для расчета итогов по числовым полям журналов (например, "всего продано на сумму:"). В случае удаления документа, он полностью из журнала не удаляется, лишь помечается как удаленный. Журнал документов имеет дополнительный атрибут прав доступа, через который администратор определяет, какие пользователи могут просматривать в журнале удаленные и/или отредактированные документы в прежних редакциях. Журнал так же, как справочник, регистр и документ, представляет некоторую совокупность таблиц, запросов, форм и отчетов. Так же задействован в общей схеме администрирования и управления правами доступа. Отчет - пожалуй, о нем особенно говорить нечего. Отчет - он и в Африке отчет. Единственное, что хотелось бы обратить внимание. Отчет-макрообъект может включать множество отчетов MS Access, запускаемых через форму MS Access (тоже компонента отчета в терминах системы). В форме обычно запрашиваются варианты компоновки отчета, группировки информации, степени детализации и т.п. Естественно, он также задействован в общей схеме администрирования и управления правами доступа. Просмотров: 15979
|