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

1. Широкое применение электронных средств, требует повышения степени формализации организационной структуры. Основные аспекты представлены на рис. 10.

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности автоматизированных информационных систем, создаваемых, как правило, на базе уже имеющихся приложений. Для успешной реализации новой информационной системы должны быть построены полные и непротиворечивые функциональные и информационные модели, что составляет логически сложную и трудоемкую задачу. При этом необходимо учесть наличие традиционных приложений, связанных с обработкой транзакций и приложений аналитической обработки, использующих нерегламентированные запросы к данным большого объема. В процессе создания информационные потребности могут изменяться, что еще более усложняет разработку. Причем, чем грандиознее и продолжительнее проект, тем сильнее он зависит от изменений в процессах. И если моделирование информационной системы на логическом уровне позволяет решить вопрос с концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных, могут быть построены на основе других логических моделей и не связаны с конкретной реализацией существующих и подлежащих замене или модернизации баз данных, то моделирование на физическом уровне, зависит от каждой конкретной реализации. Часто, в качестве стартовых и уже имеющихся баз данных выступают реляционные модели, каждая из которых построена на основе одной- двух «плоских» таблиц.

Рис. 10 - Организационная структура ведения учета

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

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

Перед организациями, уже решившими либо решающими в той или иной степени, задачи «автоматизации в малом и среднем», стоят качественно новые задачи - создание корпоративных интегрированных информационных систем, в том числе с прообразами интеллектуальных функций. При этом, с точки зрения практической целесообразности, отсутствует возможность двигаться поэтапными методами, «автоматизация в малом», «автоматизация в среднем» и т.д. Необходимо движение скачками, параллельно-поэтапными методами накопления и организации информационных массивов, с использованием наиболее перспективных информационных технологий. С другой стороны, поспешность в решении данной задачи может привести к нежелательным последствиям, когда, потратив большие финансовые, временные, интеллектуальные и прочие ресурсы, получив в итоге не совсем то или совсем не то, что необходимо. Построение и поддержка безопасной интегрированной системы потребует нового системного подхода, с рассмотрением всего спектра возможных угроз для конкретной сети и необходимостью разработки тактики их отражения. Немаловажным фактором является потребность в переобучении кадрового состава и возможно, частичная его замена. Сложность в сопровождении интегрированного банка данных, применение дорогостоящего программного обеспечения управления, потребность в новой высокопроизводительной компьютерной технике - далеко не полный перечень побочных проблем при решении данного вопроса. Многие организации не уверены, что затраты, связанные с переходом на интегрированные базы данных, быстро окупятся. Дискуссия о том, нужно или нет переходить к использованию интегрированных баз данных очень похожа на уже отшумевшие споры о пользе или вреде перехода с ассемблера на алгоритмические языки. Опыт показывает, что хотя и встречаются задачи, которые разумно реализовывать в виде отдельных локальных баз данных (функционально и структурно простые), но в условиях постоянно увеличивающейся скорости накопления информации и возрастающей сложности информационных запросов этот переход неизбежен. Отсутствие ориентации на такой переход однозначно определяет технологическое отставание в ближайшем будущем. Поэтому многие пользователи заинтересованы в комбинированном подходе, который бы им позволил воспользоваться достоинствами новых интегрированных баз данных, не отказываясь полностью от своих существующих учетов, во всяком случае, на некоторое, может и продолжительное время. Зачастую доступ к общей интегрированной информации необходим немедленно, а реализации проекта по интеграции займет продолжительное время. Одно из решений состоит в разбиении интеграционного проекта на несколько отдельных частей путем использования существующих «индивидуальных» баз данных и их связывания в форме так называемой «свободной федерации». Преимущество такого подхода - снижение остроты проблемы и осуществление проекта в виде последовательных шагов. В качестве временной меры, используемой в переходный период, для апробирования новых технологий, возможно использование так называемых адаптеров, позволяющих автоматически выделять объекты и привязывать их к существующим базам данных. Разработка таких адаптеров для данных, состоящих из простых полей фиксированной длины (например Ф.И.О.), не будет серьезным усложнением действующей системы. Несмотря на некоторое снижение производительности, такой вариант позволяет программистам целиком сконцентрироваться на объектно-ориентированной разработке. Кроме того, все имеющиеся на предприятии приложения по-прежнему будут находиться в рабочем состоянии. При этом можно организовать, в качестве привития навыков работы с ИБД, использование специфических свойств им присущих. Учитывая разную степень готовности пользователей к работе с интегрированными (или псевдо-интегрированными) данными, можно предоставить каждому пользователю в индивидуальном порядке возможность производить экспериментальные действия, которые никоим образом не отразятся на целостности баз данных.

Например, ряд полей документов, находящихся в пределах одной базы данных, при определенных видах запросов имеющих схожее смысловое значение, пользователь может объединить в так называемую «внутреннюю группу». Ряд полей документов, находящихся в разных базах данных, при определенных видах запросов, также можно интерпретировать, как имеющих аналогичное смысловое содержание. Пользователь может объединить их в так называемую «внешнюю группу». При этом “связывание” и развязывание в группы производится в произвольном порядке и в любое время, которые будут иметь силу только для данного пользователя. Можно объединить различные коллекции внешних и внутренних групп в группы по тематике- так называемые «сценарии поиска». Все произведенные действия сохраняются в индивидуальной базе данных в виде «метаданных», физическая организация базы может быть различной. Таким образом, каждый пользователь постоянно работает, как и работал ранее и только при необходимости получения дополнительной информации активизирует интеграционно - поисковый процесс. Генерацию поисковых заданий можно реализовать путем создания сравнительно простой программы- генератора исходных текстов программ на одном из языков высокого уровня, с последующей пакетной обработкой задания компилятором. Учитывая, что время выполнения запросов с каждой отдельной базой данных весьма мало, при этом используются специальные (возможно нестандартные) интерфейсы, помехозащищенность и надежность хранения данных не снижаются.

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

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

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

Для решения этой проблемы и в целях оперативного анализа данных (OnLine Analytical Processing - OLAP) реализована концепция «Хранилища данных» (Data Warehouse) путем добавления предметно-ориентированного, неизменяемого, поддерживающего хронологию набора данных, в котором концентрируется наряду с детальными данными, извлекаемыми из базы данных и суммарные показатели (агрегированные) в виде отдельных аналитических таблиц и списков с целью ускорения выполнения запросов:

"База данных -> Хранилище данных <-> Средство Анализа"

Причем Хранилище данных в прямом понимании является неизменяемым с обеспечением одновременного доступа многих пользователей. Доступ пользователей к информации реализован через WEB интерфейс.

Для реализации потребностей отдельных подразделений реализована возможность создания и ведения «Витрин данных»(Data Mart) - сравнительно небольших по объему хранилищ данных самим пользователем. Источником для большинства хранящихся там данных является Хранилище данных (Data Warehouse). Пользователь получает естественную, интуитивно понятную модель данных, организованных в виде многомерных кубов.

Осями многомерной системы координат служат наименования территориальных единиц учетов информации, вид (код) аналитического учета, время по месяцам, время по годам. На пересечениях осей - находятся данные соответствующей аналитической таблицы, содержащей определенные количественные показатели. Пользователь может "разрезать" куб по разным направлениям и получить необходимые данные и осуществлять манипуляции, необходимые в процессе анализа. Для просмотра аналитических таблиц и их возможного редактирования используется встроенный редактор или средства MS OFFICE.

Как частный случай можно рассмотреть аналитическую таблицу, состоящую из одного показателя. В данном случае выше описанный куб будет содержать просто количественные данные вместо объекта - Показатели аналитической таблицы. В качестве четвертого измерения используется время по годам. Для визуализации данных, хранящихся в кубе, применяются привычные табличные, представления, имеющие сложные иерархические заголовки строк и столбцов.

Возможно использование различных вариантов физической организации хранилища - реляционная база данных, многомерная структура или набор файлов, структура расположения информации в которых представлена метаданными (информацией о структуре, размещении и трансформации данных). Многомерное хранение или использование метаданных позволяет обращаться к данным с максимальной скоростью, благодаря чему обеспечиваются одинаково быстрые вычисления суммарных показателей и различные преобразования по любому из измерений. В целях достижения оптимального соотношения скорости выполнения аналитических запросов и недопущения чрезмерного разбухания хранилища применяется вариант гибридной OLAP (HOLAP- Hybrid OLAP) - детальные данные остаются на месте там, где они находились изначально - в реляционной БД, а показатели аналитических учетов и таблиц (агрегированные) выносятся в специально созданную структуру - Хранилище.

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22