Задачи информационных систем

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

информационной системы. Во-вторых, наличие нескольких файлов данных разной 
структуры 
неявно 
предполагает, 
что 
при 
выполнении 
некоторых 
функций 
информационной системы потребуется выборка согласованной (по заданному критерию) 
информации из нескольких файлов. Такие возможности никогда не поддерживаются 
файловыми системами.
Известны примеры реально функционирующих информационных систем, в которых 
хранилище данных планировалось основывать на файлах. В результате развития 
большинства таких систем в них выделился отдельный компонент, который представляет 
собой примитивную разновидность системы управления базами данных (СУБД). 
Самодельные СУБД - главный бич информационных систем. Поначалу кажется, что все 
очень просто: набор возможных запросов становится известным при проектировании 
информационной системы; для каждого типа запроса можно придумать эффективный 
способ выполнения запроса. После этого остается простая программистская работа, и 
специализированная СУБД готова. Однако, потом оказывается, что не все возможные 
запросы были учтены при проектировании. Бедный разработчик СУБД постоянно 
добавляет в нее новые функции, пока не решает создать общий язык запросов, на котором 
можно сформулировать любой запрос к базе данных соответствующей информационной 
системы. Через некоторое время в корпорации принимают решение разработать еще одну 
информационную систему, структуры хранимых данных которой, естественно, 
отличаются от тех, что были в базе данных первой информационной системы. Что же, 
делать еще одну специализированную СУБД? Нет, говорит начальство. У нас уже есть 
одна. Давайте попробуем применить ее. И это приводит к тому, что наивный самодельщик 
вынужден сделать простую (скорее всего, персональную) СУБД общего назначения, 
которая может получить из базы данных информацию о структуре ее файлов (т.е. в базе 
данных хранятся теперь еще и метаданные, определяющие структуры обычных данных, - 
схема базы данных), а также выполнить произвольный запрос к этой базе данных. В 
результате, даже если удается добиться работоспособности разработанной СУБД, это 
означает всего лишь изобретение еще одного велосипеда, поскольку СУБД такого уровня 
существует великое множество. Они дешевы и поддерживаются производителями.
До сих пор мы говорили о тех функциях информационной системы, которые требуют 
выборки данных из внешнего хранилища, например, производят отчеты. Но откуда 
берутся данные во внешнем хранилище? Каким образом поддерживается соответствие 
хранимой информации состоянию предметной области? Конечно, для этого должны 
существовать 
дополнительные 
функции 
информационной 
системы, 
которые 
обеспечивают ввод, обновление и удаление данных. Поддержка этих функций 
существенно повышает уровень требований к СУБД.
Если говорить о групповых или корпоративных информационных системах, то их наличие 
предполагает возможность работы с системой с нескольких рабочих мест. Некоторые из 
конечных пользователей изменяют содержимое базы данных (вводят, обновляют, удаляют 
данные). Другие выполняют операции, связанные с выборкой из базы данных. Третьи 
делают и то, и другое. Вся проблема состоит в том, что такая коллективная работа должна 
производиться 
согласованно 
и 
желательно, 
чтобы 
согласованность 
действий 
обеспечивалась автоматически. Под согласованностью действий мы понимаем то, что 
оператор, формирующий отчеты, не сможет воспользоваться данными, которые начал, но 
еще не закончил формировать другой оператор. Оператор формирующий данные, не 
сможет выполнить операцию над данными, которыми пользуется другой оператор, 
начавший, но не закончивший формировать отчет. Оператор, желающий обновить или 
удалить данные, не сможет выполнить операцию до тех пор, пока не закончится 
аналогичная операция над теми же данными, которую ранее начал, но еще не закончил 

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

жүктеу 239,39 Kb.

Достарыңызбен бөлісу: