Содержание к диссертации
Введение
Глава 1. Методы и средства автоматизации учета на предприятии 9
1.1 Постановка задачи автоматизации учета и основные понятия 9
1.1.1 Предварительные этапы процесса создания информационных систем 9
1.1.2 Основные этапы процесса создания информационных систем... 13
1.2. Обзор современных технологий и средств для построения автоматизированных систем масштаба предприятия 13
1.2.1. Архитектура клиент-серверных приложений 14
1.2.2 Организация хранения данных 16
1.2.3. Топология систем 17
1.2.4. Сервис-ориентированная архитектура (SOA) 21
1.2.5. Расширение SOA применением архитектуры, управляемой событиями (EDA) 25
1.2.6. Web-технологии 29
1.3. Обзор типовых систем для автоматизации учета 33
1.4. Выводы 39
Глава 2. Разработка подхода к автоматизации учета на бюджетных предприятиях 41
2.1 Анализ предметной области 41
2.2 Формулировка и обоснование разработанного подхода к автоматизации 43
2.2.1 Суть разработанного подхода к автоматизации 44
2.2.2 Требования к учетным системам 45
2.3 Разработка подхода к созданию учетных систем 46
2.3.1 Основные идеи, сформулированные в рамках подхода к созданию учетных систем 46
2.3 Выводы 48
Глава 3. Автоматизация финансового учета 49
3.1 Ведение бухгалтерского и налогового учета на рассматриваемом предприятии до 2005 года 49
3.2 Внедрение системы бухгалтерского учета на платформе «1С:Предприятие» версии 7.7 51
3.3. Возникшие при внедрении системы бухгалтерского учета проблемы и их решение 53
3.4. Организация ведения налогового учета 54
3.5. Результаты автоматизации бухгалтерского и налогового учета 56
3.6. Выводы 57
Глава 4. Разработка инструментария для построения учетных систем 59
4.1. Проектирование архитектуры инструментального комплекса 59
4.2. Функциональные возможности и вопросы реализации 61
4.2.1. Механизм семантической разметки структуры БД 62
4.2.2 Средства обработки данных 64
4.2.3 Средства защиты данных 66
4.2.3.1 Математическая модель системы прав доступа 68
4.2.3.2 Ролевое управление доступом 70
4.2.3.3 Дискреционное управление доступом 79
4.2.3.4 Механизм управление доступом на основе семантической разметки структуры БД 81
4.2.4. Особенности построения пользовательского интерфейса 83
4.2.5. Механизм выполнения действий и генерации отчетов 92
4.3 Выводы 100
Глава 5. Интеграция систем 102
5.1 Постановка задачи 102
5.2 Средства интеграции систем 103
5.3 Формат передачи данных между системами 106
5.4 Сервисная шина 107
5.5 Подключение учетных систем на платформе «1С:Предприятие» к сервисной шине 109
5.6 Подключение систем на основе инструментального комплекса к сервисной шине 112
5.7 Система предварительной обработки данных 113
5.8 Выводы 115
Заключение 116
Список литературы 117
Приложение
- Обзор современных технологий и средств для построения автоматизированных систем масштаба предприятия
- Формулировка и обоснование разработанного подхода к автоматизации
- Внедрение системы бухгалтерского учета на платформе «1С:Предприятие» версии 7.7
- Функциональные возможности и вопросы реализации
Введение к работе
Актуальность темы. Деятельность любого предприятия связана с достижением определенных целей. Ими могут быть получение прибыли, развитие производства, создание востребованных научных разработок и т.п. Достижение целей предприятия неразрывно связано с такой характеристикой его деятельности как эффективность. Одним из средств достижения необходимого уровня эффективности работы является комплексная автоматизация различных областей финансового и управленческого учета, позволяющая повысить достоверность информации, оперативность ее представления, полноту, надежность хранения, а также увеличить скорость ее обработки.
Существующие подходы к автоматизации учета сводятся к применению типовых или к разработке собственных информационных систем. У каждого из этих подходов есть свои преимущества и недостатки. При этом эффективность автоматизации во многом зависит от способа комбинации собственных и типовых информационных систем для решения учетных задач. Также следует учитывать, что при ведении учета на бюджетных предприятиях возникает целый ряд дополнительных проблем.
Для автоматизации учета бюджетных предприятий необходимо выработать эффективный подход, учитывающий их специфику и сочетающий в себе как внедрение и адаптацию типовых информационных систем, так и создание собственных автоматизированных учетных систем, и обеспечение интеграции и верификации данных различных систем.
В условиях необходимости разработки собственных учетных систем для решения нетиповых задач учета важно иметь эффективные средства, с использованием которых создание таких систем было бы быстрым и удобным. Существующие средства не обладают достаточной гибкостью и не являются простыми в освоении. Поэтому актуальной является задача создания комплекса простых, гибких и удобных инструментальных средств для быстрой разработки информационных систем автоматизации учета на предприятии.
Цели диссертационной работы. Основными целями диссертационной работы являются разработка подхода, повышающего эффективность автоматизации финансового и управленческого учета бюджетных организаций, а также создание
комплекса инструментальных средств для быстрой и удобной разработки учетных систем.
Для достижения поставленных целей требуется решить следующие задачи:
Описать модель предметной области финансового и управленческого учета бюджетных организаций.
Выработать и обосновать подход, повышающий эффективность автоматизации финансового и управленческого учета бюджетных организаций.
Создать инструментальный комплекс для быстрой и удобной разработки автоматизированных учетных систем.
С использованием разработанного инструментального комплекса создать ряд систем для автоматизации нетиповых областей учета на крупном бюджетном предприятии.
Спроектировать и реализовать механизмы интеграции и верификации данных различных систем.
Научная новизна. В данной работе выработан, обоснован и успешно применен подход к автоматизации учета, сочетающий в себе как внедрение и адаптацию типовых систем, так и создание для решения нетиповых задач собственных автоматизированных учетных систем с последующей их интеграцией и верификацией данных на основе принципов сервис-ориентированной архитектуры. Такой подход позволяет повысить эффективность процессов обработки данных при автоматизации учета на бюджетных предприятиях.
Выработан новый подход к созданию специализированных учетных систем, позволяющий существенно сократить сроки их разработки и снизить объем навыков и знаний, необходимых разработчику. Этот подход реализован в созданном инструментальном комплексе.
Практическая ценность. Реализован инструментальный комплекс для быстрого создания автоматизированных учетных систем. С его помощью на крупном бюджетном предприятии были разработаны и реализованы системы для автоматизации ряда нетиповых задач управленческого учета. Разработаны средства интеграции и верификации данных различных учетных систем.
Апробация. Основные положения диссертации докладывались на VIII общероссийской научной конференции «Математика и безопасность информационных технологий», Москва, МГУ им. М.В. Ломоносова, 2009; на научном
семинаре «Проблемы современных информационно-вычислительных систем», МГУ им. М.В. Ломоносова, 2009; на научно-исследовательском семинаре «Проблемы проектирования и реализации базового аппаратно-программного обеспечения» в НИИ системных исследований РАН.
Публикации. По теме диссертационной работы опубликованы 3 печатные работы, из них 1 в издании по перечню ВАК.
Объем и структура работы. Диссертация состоит из введения, пяти глав, заключения и двух приложений. Список использованной литературы содержит 77 наименований. Текст диссертации содержит 133 страницы машинописного текста, включая 25 рисунков.
Обзор современных технологий и средств для построения автоматизированных систем масштаба предприятия
Существует целый ряд подходов к построению архитектуры программных систем и организации взаимодействия между подсистемами. Их применение позволяет сократить время на разработку и добиться желаемой эффективности готовой системы. Вначале рассмотрим подходы к построению архитектуры автоматизированных систем предприятия.
Автоматизированные учетные системы предприятия, как правило, являются многопользовательскими. Их архитектура подразумевает, что различные пользователи со своих рабочих компьютеров одновременно могут получать доступ к информации, хранящейся в системе. Такая архитектура носит название «клиент-сервер» [22].
При проектировании клиент-серверных приложений необходимо принять решение о том, какие задачи будут выполняться на клиентском рабочем месте, а какие на сервере. Это решение в значительной степени влияет на стоимость клиентских и серверных частей системы, устойчивость и безопасность приложения в целом, гибкость разработки для дальнейшей модификации и адаптации.
Можно выделить варианты построения клиент-серверной системы с использованием так называемых тонких или толстых клиентов [28]. Тонким клиентом принято называть компьютер-клиент в сети с клиент-серверной архитектурой, который переносит большинство задач по обработке информации на сервер [55]. Для нормальной работы такого компьютера-клиента всегда необходим сервер. Этим тонкий клиент отличается от толстого клиента, который, напротив, производит основную обработку информации независимо от сервера, используя последний в основном лишь для хранения данных. Толстый клиент периодически соединяется с центральным сервером по сети, но в то же время способен выполнять многие функции локально, без соединения с сервером. Основные преимущества архитектуры с использованием толстых клиентов: Не требуется высокопроизводительный сервер, т.к. клиент сам выполняет большую часть обработки данных. Это приводит к значительному удешевлению серверов. Возможность работы клиентов в автономном режиме. Как правило, им не требуется постоянного соединения с центральным сервером.
Большая гибкость в случае использования на клиентском рабочем месте ресурсоемкого ПО. Запуск подобных приложений на тонком клиенте может быть затруднителен или невозможен. Преимущества архитектуры с использованием тонких клиентов [26]:
Снижение затрат на администрирование. Обновление и управление ПО тонкого клиента практически полностью осуществляется с сервера. Кроме того, аппаратные средства имеют меньшую вероятность отказа из-за малой нагрузки на них, а ПО клиента меняется крайне редко, что позволяет организовать централизованное администрирование системы и обеспечить защиту от вредоносных программ.
Повышение уровня защиты информации. ПО тонкого клиента может быть спроектировано так, чтобы на клиенте не хранились никакие данные. Тем самым обеспечивается централизованная защита от утечки информации, и минимизируются риски физического повреждения данных.
Обеспечение непрерывности работы в случае аппаратных сбоев. При поломке оборудования тонкого клиента на время ремонта пользователю может быть быстро предоставлена полноценная замена, т.к. все данные хранятся на сервере.
Расширением архитектуры клиент-серверных приложений с тонким клиентом является трехуровневая организация составных частей системы, которая предполагает наличие следующих компонентов приложения: клиентская часть, сервер приложений и сервер базы данных [24].
В клиентской части обычно реализуется простейшая логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с уже загруженными данными.
Сервер приложений располагается на втором уровне. В нем сосредоточена большая часть логики приложения, осуществляется взаимодействие с базой данных и генерация интерфейса [4]. Сервер базы данных обеспечивает хранение информации и представляет собой отдельный уровень [10]. Обычно это реляционная или объектно-ориентированная СУБД. На этом уровне может быть реализована логика приложения с помощью триггеров и хранимых процедур.
Для хранения информации многие годы успешно используется реляционная модель данных. Реляционная СУБД MySQL является широко применяемым решением для малых и средних приложений. Обычно она используется в качестве сервера БД, к которому обращаются локальные или удаленные клиенты. СУБД MySQL хорошо зарекомендовала себя в составе серверного ПО при разработке Web-приложений. Благодаря открытой архитектуре и использованию лицензии GPL, в СУБД MySQL постоянно добавляются новые возможности. Так, с выходом пятой версии в этой СУБД появилась практически полная поддержка стандарта SQL: 1999, что обусловлено следующими нововведениями [35]: хранимые процедуры и функции; обработчики ошибок; курсоры; триггеры; представления; информационная схема (так называемый системный словарь, содержащий метаданые).
Этих функциональных возможностей часто вполне достаточно для использования MySQL в качестве СУБД в учетных системах предприятия.
Использование реляционной модели для хранения информации об объектах реального мира часто приводит к тому, что приложение должно уметь обрабатывать данные в объектно-ориентированном виде, но при этом хранить эти же данные в реляционной форме. Эта постоянная необходимость в преобразовании существенно снижает производительность и создает трудности для программистов, поскольку обе формы данных накладывают ограничения друг на друга.
Формулировка и обоснование разработанного подхода к автоматизации
Как было показано в главе 1, существующие подходы к автоматизации учета сводятся либо к внедрению и доработке типовых, либо к разработке собственных информационных систем. От правильности комбинации этих двух подходов в значительной степени и зависит эффективность автоматизации. Проведенный анализ предметной области показал, что финансовый учет на бюджетном предприятии включает в себя ряд типовых задач, поэтому для его автоматизации целесообразно использовать типовую информационную систему. Однако особенности финансового учета могут потребовать решения нетиповых задач, обусловленных спецификой предприятия. Управленческий же учет, как правило, специфичен для каждого предприятия. Поэтому для решения задач управленческого учета чаще всего целесообразна разработка собственной учетной системы.
Учитывая вышесказанное, можно сформулировать подход, повышающий эффективность автоматизации финансового и управленческого учета на бюджетном предприятии. Такой подход предусматривает как использование типовых, но адаптированных информационных систем для автоматизации типовых областей учета, так и разработку собственных информационных систем для нетиповых областей учета с последующей их интеграцией и верификацией данных между ними.
Эффективность подхода к автоматизации обеспечивается совокупностью принципов, которыми следует руководствоваться как при выборе типовых, так и при разработке собственных учетных систем. Рассмотрим эти принципы. Для разных областей учета целесообразно использование различных информационных систем с последующей их интеграцией. Это позволит сделать системы менее громоздкими и максимально эффективными. Для автоматизации типовых областей учета целесообразно применение тиражируемых информационных систем, обеспечивающих эффективное решение типовых учетных задач и не требующих.ресурсов на разработку. Используемые типовые информационные системы должны иметь развитые возможности для их адаптации. Это важно для возможной реализации в них алгоритмов решения специфических учетных задач и интеграции с другими информационными системами предприятия. Для автоматизации нетиповых областей учета целесообразна разработка собственных информационных систем, изначально ориентированных на специфику конкретного предприятия. Используемые информационные системы должны удовлетворять совокупности технологических требований и требованиям к функциональности. Необходима разработка средств интеграции учетных систем. Интеграция позволит не только осуществлять обмен информацией, но и решить важную задачу, возникающую при ведении учета, — верификацию данных, путем установления различия между информацией, хранящейся в разных системах. Информационные системы, применяемые для автоматизации финансового и управленческого учета бюджетных предприятий, должны удовлетворять ряду требований, обусловленных как спецификой таких предприятий, так и областью применения систем. В рамках предложенного подхода к автоматизации был выработан ряд функциональных и технологических требований к учетным системам. Рассмотрим главные функциональные требования для систем финансового и управленческого учета, определяющие перечень реализуемых в них возможностей. 1. Наличие механизмов надежного хранения и обработки данных, гарантирующих их достоверность. 2. Адекватность алгоритмов обработки и представления информации актуальным нормативным требованиям. 3. Наличие развитых средств защиты информации и разграничения доступа к данным. 4. Удобство и функциональность интерфейса, имеющего развитые средства контроля вводимых данных. 5. Возможность оперативного формирования разнообразной отчетности. Технологические требования касаются вопросов построения архитектуры и организации систем. Выделим среди них главные. 1. Архитектура системы должна обеспечивать централизованное администрирование и защиту данных, в том числе и при удаленном многопользовательском доступе 2. Система должна обладать свойствами адаптируемости и расширяемости для настройки и доработки 3. В системе должны содержаться функции по взаимодействию с внешним окружением, благодаря которым возможна ее интеграция с другими системами Как уже было сказано ранее, для автоматизации нетиповых областей учета и решения специфических задач можно применить типовую информационную систему, адаптировав и доработав ее, либо разработать собственную. Узкоспециализированная система более эффективна для решения задач, на которые она рассчитана. Однако для разработки подобной системы требуются, как правило, значительные затраты ресурсов. Предлагаемый подход к созданию прикладных учетных систем позволяет минимизировать эти затраты. Для повышения скорости и удобства создания прикладных учетных систем необходимо предоставить разработчику инструментарий, удовлетворяющий ряду требований, главными из которых являются: 1. Наличие в инструментарии средств для быстрого создания типичных для предметной области механизмов обработки и представления информации. 2. Инструментарий должен быть пригоден для построения на его основе широкого круга прикладных систем в пределах предметной области. 3. Простота использования инструментария. За счет этого его освоение будет требовать меньше времени, навыков и знаний разработчика. 4. Инструментальные средства должны быть удобными и эффективными в использовании, что способствует увеличению скорости разработки систем и упрощению их настройки, а также уменьшению времени отладки и нахождения ошибок. 5. Гибкость и открытость архитектуры инструментария, позволяющие при необходимости осуществлять доработку его функциональности.
Внедрение системы бухгалтерского учета на платформе «1С:Предприятие» версии 7.7
В качестве платформы для функционирования выбранной системы БУ использовался сервер под управлением ОС «Windows Server 2003» в соответствии с системными требованиями к платформе «1С:Предприятие» версии 7.7 [2]. В качестве хранилища информации системы можно использовать БД формата DBase или СУБД «Microsoft SQL Server». Был проведен анализ производительности обоих вариантов на предполагаемом уровне нагрузки (размер БД с данными за год менее 1Гб), в результате чего было принято решение использовать БД формата DBase. Такой вариант обеспечивает высокий уровень быстродействия и не требует приобретения дополнительного ПО.
При организации доступа пользователей к системе БУ было решено реализовать архитектуру с тонким клиентом, для этого были использованы средства «Microsoft Terminal Server» [71]. Такой подход обеспечивает дополнительную защищенность конфиденциальных бухгалтерских данных за счет их централизованного хранения. Кроме того, при таком варианте архитектуры обеспечить требуемую скорость работы можно, использовав производительный сервер, не увеличивая производительности рабочих станций и пропускную способность сети.
Внедрение типовой конфигурации «Бухгалтерия для бюджетных учреждений» включало в себя ее доработку, что обусловлено в первую очередь спецификой предприятия. При этом было принято решение следовать концепции минимизации вносимых изменений с целью сокращения затрат при обновлении программы. В типовую конфигурацию необходимо было внести ряд изменений. В частности, был реализован, учет коммерческой деятельности бюджетного предприятия по договорам, а также расширены стандартные средства отбора данных. Кроме того, были разработаны дополнительные средства контроля и обработки информации и ряд отчетов. Некоторые внесенные изменения были реализованы в виде внешних модулей, которые не входят в состав конфигурации и не влияют на трудоемкость ее обновления и размер базы данных.
Перед вводом системы на платформе «1С:Предприятие» в эксплуатацию, в нее потребовалось перенести данные из прежней системы бухгалтерского учета. Благодаря наличию в обеих системах интерфейсов, применимых для организации обмена данными, удалось с минимальными затратами осуществить перенос информации, создав для этого ряд автоматизированных средств.
Система «1С:Предприятие» обладает встроенным языком, используемым для ее настройки. Этот язык является процедурно-ориентированным, несложен в освоении и позволяет настроить поведение и взаимодействие объектов системы в широких пределах. Редактор программного кода обладает рядом удобств, среди которых цветовая разметка кода, контекстная справка, автоматическое форматирование, наличие конструкторов, позволяющих в режиме диалога быстро создавать типовые составные части модулей.
Как показала практика внедрения, используемая в платформе «1С:Предприятие» структура объектов, а также средства конфигурирования, настройки и программирования, весьма удобны для разработки многопользовательских учетных систем.
В процессе эксплуатации системы на платформе «1 ( Предприятие» пришлось решить ряд текущих задач, наиболее сложными из которых оказались переход на новую версию конфигурации в связи с серьезным изменением законодательства и объединение информационных баз трех учреждений в связи с реорганизацией предприятия.
Для решения первой задачи требовалось выполнить перенос информации в конфигурацию с другой структурой данных, при этом данные должны были быть определенным образом преобразованы. Компания «1С» предоставила средства переноса и преобразования данных, однако они оказались ограниченно применимы для базы данных учетной системы предприятия из-за внесенных в конфигурацию изменений, касающихся и плана счетов, и структуры метаданных. Поэтому стандартная процедура переноса информации была изучена на уровне программного кода, и в нее были добавлены правила переноса специфических справочников, реквизитов документов, счетов и элементов аналитики. Важно отметить, что выполнение процедуры переноса информации в конфигурацию новой версии не вызвало сбоев в работе бухгалтерии и срывов в предоставлении отчетности.
Во втором случае стояла задача объединения в одну систему информации из трех информационных баз с различной структурой метаданных, причем перенос требовалось выполнить в середине отчетного периода, что существенно осложняло задачу и ограничивало средства ее решения. Одна из систем была принята в качестве основной, а информация из двух других извлекалась, преобразовывалась и вносилась в основную. Все программные средства для осуществления преобразований данных были написаны на встроенном языке системы «1С:Предприятие». В качестве основной системы была выбрана информационная база с наибольшим объемом данных и с наиболее измененной, по сравнению с типовой, структурой в плане расширения функциональности и детализации учета.
Во второй системе аналитический учет был реализован путем введения субсчетов к балансовым счетам, а не при помощи субконто, как это сделано в типовой конфигурации. Кроме того, план счетов был серьезно переработан. Однако данную структуру удалось согласовать со структурой основной системы без потери информации.
В третьей системе были несколько переработаны основные алгоритмы работы ряда документов. В результате этого в объединенной системе до окончания отчетного периода существовали документы одного вида, заполненные единообразно, но формирующие разные бухгалтерские проводки из-за того, что ранее относились к разным информационным базам. Отдельной проблемой был поиск соответствия между сущностями, находящимися в разных базах и обозначающими одно и то же. Объединение было также проведено без привлечения сторонних специалистов и не привело к проблемам со сдачей бухгалтерской отчетности.
Функциональные возможности и вопросы реализации
В качестве ORM-модуля в инструментальном комплексе используется компонент DBIx [5], поскольку он наиболее распространен в системах на основе Catalyst и активно развивается. Функциональность инструментария сосредоточена в модуле управления. Она включает в себя: Гибкие средства построения пользовательского интерфейса, отражающего логику и семантику приложения. Средства для реализации логики приложения в БД. Систему управления доступом к данным. Механизмы выполнения действий и генерации отчетов. Рассмотрим подробнее вопросы реализации отдельных компонентов инструментального комплекса. Выбранный подход к распределению логики системы, при котором логика приложения реализуется в БД, потребовал реализации в ядре инструментария специальных механизмов, при помощи которых разработчик мог бы программировать поведение системы, пользуясь лишь средствами БД. Одним из таких механизмов является семантическая разметка структуры БД. DBIx-реализация ORM позволяет анализировать БД при ее подключении. При этом автоматически определяется состав и атрибуты полей таблиц, а также установленные связи между таблицами.
Это дает возможность создания приложения, автоматически настраивающегося согласно декларированной структуры БД. Возможность реализации таких средств является следствием выбора подхода, при котором логика прикладной задачи описывается средствами БД. При помощи созданного в инструментарии механизма семантической разметки можно управлять следующими параметрами интерфейса системы: Режим отображения таблицы (список, поиск значений, последние записи); Видимость колонки таблицы; Режим редактирования полей колонки таблицы; Порядок сортировки записей в таблице; Автоматический подсчет итогов по числовым колонкам таблицы; Параметры отображения связей между таблицами; Ограничение выбора возможных вводимых значений; Доступность интерфейсных элементов в зависимости от прав доступа. Всю необходимую информацию, описывающую семантику объектов и их связи, в том числе о правах доступа к данным, можно хранить либо в полях комментариев, либо в служебных таблицах БД. Поскольку максимальная длина комментария к полю таблицы больше максимальной длины комментария к таблице, то семантические атрибуты таблицы удобнее хранить в комментарии к ее полю id1. К сожалению, современная реализация DBIx не распознает комментарии к объектам MySQL, поэтому такой анализатор был дополнительно реализован в инструментарии. Был выбран следующий формат семантической разметки комментариев к полям и таблицам БД MySQL, используемый в инструментальном комплексе. Комментарий может быть добавлен к любому полю таблицы БД. Формат комментария следующий: COMMENT видимое_имя_поля # список_атрибутов , где видимое_имя_поля — это имя, отображаемое в пользовательском интерфейсе. Если его нет, то используется имя поля таблицы базы данных. список_атрибутов состоит из разделенных пробелом выражений вида: +имя_атрибута: значение_атрибута Кроме анализа комментариев к таблицам и полям таблиц средства инструментального комплекса позволяют распознавать суффиксы в именах полей.
Например, использование окончания «_ргос», указывает, что значение данного поля представляет собой величину, выраженную в процентах. В соответствии с выбранным подходом к распределению логики приложения функциональность прикладной системы можно реализовать при помощи триггеров и хранимых процедур базы данных. Преимущество триггеров в том, что они выполняются при определенных действиях с данными, поэтому не требуется создания дополнительного механизма для их вызова. Поскольку функциональность триггеров в MySQL ограничена, в частности, в триггерах запрещена рекурсия [42], то в ряде случаев могут возникать серьезные проблемы при разработке эффективной прикладной системы. Поэтому инструментарий был спроектирован таким образом, что в системах на его основе функциональность реализуется при помощи хранимых процедур. Этот подход потребовал создания механизма их вызова. Созданный механизм предусматривает, что каждая такая хранимая процедура привязана к определенной таблице базы данных и вызывается при наступлении определенного события. Данные привязки определяются синтаксисом имени хранимой процедуры: имя таблицы _ ключевое слово ,где имя таблицы — имя таблицы базы данных ключевое слово — одно из ключевых слов, определяющих событие, при котором вызывается данная процедура. В настоящее время предусмотрены следующие ключевые слова: update Хранимая процедура с таким ключевым словом вызывается каждый раз при отображении строк соответствующей таблицы на Web-странице. Такие процедуры можно использовать, например, для пересчета значений в базе данных. Процедура выполняется последовательно для каждой строки таблицы при построении списка, если для нее не указан атрибут +no_s_update.
Также она выполняется при открытии карточки объекта. Входным параметром процедуры является идентификатор текущей строки таблицы. check Такие процедуры выполняются каждый раз при изменении строки соответствующей таблицы. Они могут генерировать ошибку и сообщение с предупреждением. Эти процедуры используются для контроля корректности вводимых данных. init Процедуры данного вида выполняются при создании строки соответствующей таблицы. Они могут быть полезны для автоматического заполнения реквизитов создаваемого объекта. info В данной процедуре можно описать наполнение информационного поля, которое отображается на Web-странице. тар В данной процедуре можно описать алгоритм быстрого перехода с текущей страницы по нажатию кнопки «Перейти». access При помощи таких процедур реализуется механизм дискреционного управления доступом, описанный в следующем параграфе. В них проверяется, имеет ли текущий пользователь право на доступ к объекту. При поступлении в модуль управления запроса на выполнение действия с данными проверяется наличие в БД соответствующих процедур и вызывается их выполнение. С помощью данного механизма разработчик прикладного решения может реализовать анализ и обработку данных, поддержание логической целостности информации и другие необходимые функции. Далее подробно рассмотрим средства защиты данных, реализованные в инструментальной системе.
