Лекция: Классификация методов доступа в СУБД.

Технический прогресс, приведший к замене совокупности отдельных персональных компьютеров вычислительными сетями, перенес на них все существующие проблемы информационных систем. Центральной из них остается проблема организации совместной работы многих пользователей с большими базами данных (БД) в реальном масштабе времени. Интеграция вычислительных ресурсов повлекла за собой информационную интеграцию, усложнив работу с большими БД практически во всех областях человеческой деятельности. Известны три технологии, используемые в настоящее время для решения указанной проблемы. Одна из них основана на естественном желании использовать на рабочих станциях ЛВС широко распространенные СУБД, совмещающие операции поиска и чтения записей, поместив при этом БД на файл-сервере. Эту технологию будем называть далее для краткости технологией А. В соответствии с другим подходом и БД, и СУБД помещаются на одном компьютере, называемом SQL-сервером или сервером БД. Соответствующую технологию будем далее именовать технологией В или технологией “клиент-сервер”. И, наконец, последняя технология так же, как технология А, предлагает помещать БД на файл-сервере, однако на рабочих станциях устанавливать СУБД, разделяющие операции поиска и чтения. Эту технологию назовем Нуреr-технологией по наименованию лежащей в ее основе СУБД HyTech. Технология А: Попытка использовать для ведения сетевой БД, хранимой на файл-сервере, популярные для IBM совместимых персональных компьютеров СУБД, расположенные на рабочих станциях, не дала желаемого результата по двум причинам. Во-первых, при такой конфигурации программно-аппаратного комплекса для дальнейшей обработки на рабочих станциях приходится пересылать по вычислительной сети фрагменты файлов БД значительных объемов. В результате сетевой трафик быстро насыщается, а время реакции информационной системы стремительно возрастает. Во-вторых, при использовании СУБД на рабочих станциях остаются нерешенными проблемы быстрого поиска. Опыт работы с большими многопользовательскими БД в локальных сетях, построенных по технологии А, показал, что при числе станций, близком к десяти, большинство известных пакетов теряет свою работоспособность, в частности, и те из них, которые отлично справляются со своими задачами на малых БД. Укажем особенности организации данных, реализованные в СУБД Btrieve и СУБД семейства dBase, которые определяют их поведение при работе с файл-сервером. 1. Основная система запоминания файлов реализована средствами файловой системы MS-DOS. 2. Даже простая операция “вставить запись” не будет выполнена без предварительной обработки СУБД, поскольку MS DOS не имеет доступа к информации о внутренней организации файлов конкретной СУБД. 3. Выполнение одной операции с БД может привести к выполнению нескольких операций файлового уровня. Например, чтобы определить нахождение некоторой записи, обычно требуется выполнить поиск нескольких индексных блоков (индексных страниц, узлов). 4. Из-за блочной организации файлов БД при выполнении каждой операции “чтение/запись” обычно выполняется чтение/запись всего блока. · При обработке многоключевых запросов к БД с использованием технологии А время реакции системы резко ухудшается. Действительно, время обработки запроса складывается из времени поиска в БД необходимого фрагмента по главному ключу, которое линейно зависит от длины записей и числа записей, целей и времени считывания фрагмента БД на рабочую станцию, где осуществляется проверка соответствия найденной информации другим ключам. Если необходимо уточнить или расширить исходный запрос, описанная процедура полностью повторяется. Объем передаваемой на рабочую станцию информации при этом нередко составляет десятки килобайт. Отказаться от пересылки на рабочую станцию фрагмента БД, который, возможно, содержит много ненужной информации, нельзя, так как операции поиска и чтения совмещены и поиск выполняется описанным выше способом. Для решения проблемы организации совместной работы многих пользователей с большими базами данных в реальном масштабе времени американской фирмой Oracle Corp., европейской фирмой EuroSoft и некоторыми другими было предложено создавать SQL-серверы, называемые так по наименованию интерфейсного языка SQL (Structured Query Language). Этот подход позволяет устранить первую причину неприемлемости технологии А — необходимость пересылки на рабочие станции для дальнейшей обработки значительных объемов информации. Обработка запросов в СУБД типа “клиент-сервер” происходит на сервере; каждому пользователю отсылаются только необходимые ему фрагменты БД. Приведем соображения, ставящие под сомнение взгляд на технологию “клиент-сервер” как на безусловно лучшее решение проблемы совместной работы многих пользователей с большими БД. В технологии В SQL-север при работе с БД играет роль одной большой ЭВМ, обслуживающей многих пользователей. Время обработки запроса складывается из времени поиска необходимых данных в БД на сервере выполняемого СУБД и времени пересылки данных по сети на рабочую станцию пользователя (операции поиска и чтения данных совмещены). Эта технология позволяет несколько улучшить сетевой трафик, однако предполагает слабое использование вычислительных мощностей рабочих станций, которые выполняют в этом случае лишь функции терминалов. Некоторая пассивность рабочих станций оборачивается необходимостью формирования сервером для каждого пользователя его модели данных и пересылки ее на рабочую станцию. В конечном итоге это приводит к значительному увеличению общего времени обработки запросов к БД на сервере из-за увеличения времени ожидания начала обработки. При обеспечении режима наибольшего благоприятствования для функционирования SQL-сервера технология “клиент-сервер” дает выигрыш во времени по сравнению с обработкой запроса на рабочей станции только для некоторых наборов поисковых предписаний, тогда как для других приводит к противоположному результату. Поэтому на вопрос о том, быстрее ли SQL-сервер обработает запрос пользователя, чем рабочая станция, дать однозначный ответ невозможно. Язык SQL не имеет приемлемых средств, позволяющих пользователю на любом шаге формирования сложного запроса определить число найденных записей, удовлетворяющих критерии поиска, поскольку для обеспечения такой возможности необходимо, чтобы процессы поиска записей в БД и их чтения из БД были разделены. Необходимость в определении числа записей особенно остро ощущается при работе с большими БД. Рассмотрим для примера итерационный режим работы с БД, характерный для очень широкого класса автоматизированных информационных систем. Пользователь, перед тем как начать читать данные по сети, обычно итерационно уточняет или расширяет поисковое предписание в диалоговом режиме. И только после того, как поиск завершен, он начинает чтение необходимой информации из БД. Язык SQL имеет два типа поисковых операторов: Select и Select Count. Первый из них обеспечивает отбор записей и их пересылку по ходу поиска. Между тем, поскольку нет никакой гарантии, что именно эта информация нужна, вероятность того, что работа окажется безрезультатной, весьма велика. При расширении или уточнении запроса к БД процедура будет выполняться заново. Таким образом, оператор Select нельзя рассматривать как средство разделения процессов поиска записей и их чтения. Второй оператор не обеспечивает пересылки данных по сети и является счетчиком числа записей-целей в БД. Однако и он имеет серьезные недостатки: по своей сути он попадает в класс операторов “последовательной обработки”, время выполнения которых линейно зависит от числа записей в БД и от длины записи, следовательно, для больших БД оно будет измеряться десятками минут, а возможно, и часами; так же, как и в случае использования оператора Select, запросы, уточняющие или расширяющие исходный, выполняются заново. Кроме того, имеется еще ряд причин, сдерживающих применение серверов для организации совместной работы многих пользователей с большими БД: в каждом сервере используется собственная версия языка SQL, имеющая определенные отличия от других; установка и эксплуатация SQL-cepbepa — непростая задача, требующая высокой квалификации программистов. Hyper технология, позволяющая отказаться от обязательной пересылки больших объемов данных на рабочие станции и обеспечивающая быстрый поиск, основана на использовании инвертированных списков. Поиск в БД, находящейся на сервере (как простой, так и сложный), ведется только в специально построенном ассоциаторе, который хранится отдельно от собственно данных. Если ассоциатор представить в виде матрицы и оглавления, то поиск физических адресов записей целей можно вести не в самом ассоциаторе, а в крайних векторах матрицы, хранящих первый и поздний физические номера записей-целей. Подсчет числа записей целей производится по оглавлению ассоциатора без считывания всего оглавления. Заметим, что объем внешней памяти, занимаемый ассоциатором полностью инвертированных файлов, может быть больше объема памяти, выделенного под сами данные. Известно, что инвертированные списки обеспечивают самый быстрый метод доступа к записям целям как при простом, таки при многоключевом поиске. Поэтому СУБД НуТесh, построенная на инвертированных списках, особенно эффективна в локальных сетях, где используются БД больших объемов; ее применение позволит устранить причины неработоспособности технологии А. Особенность технологии обработки запросов в СУБД НуТесh заключается в том, что операции чтения и поиска данных разделены. Преимущества такого решения становятся очевидными при анализе действий, выполняемых ядром СУБД. Так, при поиске записей в БД по одному ключу результатом являются крайние векторы матрицы ассоциатора, и передачи собственно данных по сети не происходит. Результатом выполнения сложных запросов также являются крайние векторы и указатели на записи цели по каждому атомарному условию логического выражения. При этом передачи самих данных по сети также не происходит. Нуреr технология обработки запросов позволила увеличить быстродействие существующих популярных СУБД на IBM PC в сотни и тысячи раз. По этой причине ответ на вопрос о целесообразности перехода на более мощные ЭВМ или необходимости использования SQL-серверов становится еще более неопределенным. При работе с небольшими БД в системах, рассчитанных на три-пять пользователей, можно с некоторой долей риска применять технологию А. Технология В наиболее полно раскрывает свои возможности в неоднородных вычислительных сетях, компьютеры которых, работая в различных операционных системах, обмениваются информацией на унифицированном языке SQL. Для работы с большими БД в MS DOS и в сетевых средах и при необходимости получения ответа на нерегламентированные запросы в реальном масштабе времени целесообразнее всего использовать Нурег технологию. Она обеспечивает как лучшее время реакции системы, так и лучшее отношение производительности системы к ее стоимости. Классификация СУБД По степени универсальности различаются два класса СУБД: системы общего назначения (Использование СУБД общего назначения в качестве инструментального средства для создания автоматизированных информационных систем, основанных на технологии баз данных, позволяет существенно сокращать сроки разработки, экономить трудовые ресурсы. Развитые функциональные возможности таких СУБД, присущая им, как правило, функциональная избыточность позволяют иметь значительный «запас мощности», необходимый для безболезненного эволюционного развития построенных на их основе информационных систем в рамках их жизненного цикла. Вместе с тем средства настройки дают возможность достигнуть приемлемого уровня производительности информационной системы в процессе ее эксплуатации.Однако в некоторых случаях доступные СУБД общего назначения не позволяют добиться требуемых характеристик производительности и/или удовлетворить заданные ограничения по объему памяти, предоставляемой для хранения базы данных. Тогда приходится разрабатывать специализированную СУБД для данного конкретного применения. Решение указанных проблем при этом может оказаться возможным благодаря знанию специфических особенностей данного применения, к которым оказываются нечувствительными средства настройки доступных СУБД общего назначения, либо за счет ущемления каких-либо функций системы, не имеющих жизненно важного значения. Как правило, в этой роли оказываются прежде всего функции, обеспечивающие комфортную работу пользователя.) специализированные системы (Создание специализированной СУБД — весьма трудоемкое дело даже в сравнительно простых случаях, и для того, чтобы избрать этот путь, нужно иметь действительно веские основания и твердую убежденность в невозможности или нецелесообразности использования какой-либо СУБД общего назначения.) По технологии работы с базами данных различаются: централизованные СУБД (Централизованная СУБД — система управления базой данных, которая хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе данных — доступ к ней пользователей различных ЭВМ данной сети. Такой способ использования баз данных часто применяют в локальных сетях персональных ЭВМ. Появление сетей ЭВМ позволило наряду с централизованными создавать и распределенные базы данных.) распределенные СУБД (Распределенная база данных состоит из нескольких, возможно, пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Однако пользователь распределенной базы данных не обязан знать, каким образом ее компоненты размещены в узлах сети, и представляет себе эту базу данных как единое целое. Работа с такой базой данных осуществляется с помощью системы управления распределенной базой данных (СУРБД). Данные, содержащиеся в распределенной базе данных, их представление на всех уровнях архитектуры СУРБД и размещение в сети описываются в системном справочнике, который сам может быть декомпозирован и размещен в различных узлах сети. Части распределенной базы данных, размещенные на отдельных ЭВМ сети, управляются собственными (локальными) СУБД и могут использоваться одновременно как самостоятельные локальные базы данных. Локальные СУБД не обязательно должны быть одинаковыми в разных узлах сети. Объединение неоднородных локальных баз данных в единую распределенную базу данных является сложной научно-технической проблемой. Ее решение потребовало проведения большого комплекса научных исследований и экспериментальных разработок.) В зависимости от способов разработки приложений, которые предусматриваются системой: непрограммируемые СУБД (Системы первого типа ориентированы на непрограммирующего пользователя, работающего в интерактивном режиме. Предназначенные для достаточно простых случаев, например для поддержки разнообразных картотек, они обладают весьма ограниченными возможностями. Непрограммируемые системы оперируют обычно структурами плоских файлов и позволяют настраиваться на нужную структуру записи. Обычно в них предусматриваются простейшие операции манипулирования данными — вставка и исключение записей из файла, просмотр и редактирование записей, поиск записей по простейшим критериям. Пользовательские интерфейсы такого рода систем строятся, как правило, в стиле меню с применением простейших форм ввода-вывода данных, автоматически генерируемых системой в соответствии с заданной структурой файла. Примером такой системы может служить Filer фирмы IBM Согр. К числу непрограммируемых относится и ряд систем реляционного типа — Superbase, XTrieve, Power Base и др. Эти программные продукты обладают более развитыми возможностями манипулирования данными и генерации отчетов, средствами экспорта-импорта данных и защиты данных по паролям.) программируемые СУБД (Другой полюс рассматриваемой классификации представляют программируемые системы. Еще на ранней стадии формирования технологии баз данных была принята дихотомия пользовательских интерфейсов программируемых СУБД по характеру их языковых средств — интерфейсы автономного (самостоятельного) языка и интерфейсы включающем языка программирования. Созданные в период середины 60-х — начала 70-х годов системы обычно обладали одним из таких интерфейсов. В более поздних СУБД стали предусматриваться, как правило, интерфейсы обоих типов, иногда даже на основе одного и того же языка. В преобладающем большинстве СУБД для персональных ЭВМ интерфейсы языка программирования реализованы по принципу автономного языка. Таковы Рагаdох с его языком РАL, системы DataEase и R:base (во всех ее версиях), все dBase-совместимые системы. Во многих случаях функциональные возможности таких языков оказываются вполне достаточными для того, чтобы полностью реализовать прикладную систему их средствами. Автономные языки программирования СУБД часто не являются таковыми в полном смысле слова. Так, из программ, написанных на языке dBase, на языке системы R:base можно вызывать загрузочные модули, заблаговременно созданные на обычном языке программирования. При этом обмен данными между вызывающей и вызываемой программами осуществляется через параметры командной строки, инициирующей вызываемую программу, и ASCII-файлы операционной системы, в которые эти СУБД легко экспортируют данные из базы данных и из которых они легко их импортируют. На практике существуют, однако, случаи, когда функциональные возможности автономных языков, ориентированных главным образом на задачи обработки данных, не позволяют эффективно реализовать приложение. Такие ситуации могут возникнуть, например, при создании прикладных систем с интенсивным использованием сложных математических методов на основе имеющихся типовых программных пакетов. Доминирующую роль в системах подобного рода должен играть не инструментарий баз данных, который является здесь лишь вспомогательным, а, скорее, один из традиционных языков программирования. Взаимодействие с базой данных целесообразно при этом строить по принципу интерфейсов включающего языка. Примером СУБД таком типа, предназначенной для работы с базами данных сетевой структуры, может служить система db_VistaIII фирмы Raima Согр. Она обеспечивает доступ к базам данных для прикладных программ, написанных на языке «С». Нужно заметить, что такие СУБД, ориентированные на программиста, — сравнительно редкое явление в технологии баз данных на ПЭВМ. Даже для системы db_VistaIII был разработан основанный на языке SQL модуль интерактивного доступа к базе данных. Гораздо чаще практикуется иной подход, когда для развитых интерактивных систем создаются средства интерфейса включающего языка. В «классическом» стиле с использованием технологии препроцессоров реализован такой интерфейс в системе ПАЛЬМА-ПК, а также в системе Oracle Server. Обычно под термином «интерфейс включающего языка» понимается компонент СУБД, предоставляющий средства для взаимодействия прикладной программы, написанной на включающем языке программирования, с этой системой. Таким образом, имеется ввиду интерфейс между прикладной программой и СУБД. В технологии баз данных на ПЭВМ средства такого функционального назначения часто не являются компонентом СУБД. Они реализуются, как правило, в форме самостоятельных пакетов, исключающих библиотеки функций или процедур, используемых в прикладной программе для доступа к базе данных. При этом с помощью таких средств прикладная программа непосредственно взаимодействует с базой данных. Следовательно, мы имеем здесь дело с интерфейсом между прикладной программой и базой данных, а не СУБД. В качестве примера продуктов такого рода можно привести пакет dbcIII Library фирмы Lattice Inc — библиотеку функций на языке «С», позволяющую реализовать доступ к базам данных dBase-совместимых систем из программ на языке «С». Аналогичную роль для программ на языках Turbo С, Мiсгоsоft QuickC и Мiсгоsоft С играет пакет Code Base 4, разработанный Sequiter Software Inc. (Заметим, что этот пакет выгодно отличается наличием в его библиотеках ряда функций высокого уровня, эквивалентных командам языка dBase.) Фирма AJS Publishing Inc. создала подобное средство db/LIB для системы программирования QuickBASIC. Пакет The WKS Library фирмы Raima Согр. позволяет выполнять простейшие операции манипулирования данными над dBase-файлами в программах на языках Тurbо С, Lattice С, Мiсгоsоft С версии 5.0, Мiсгоsоft QuickC, а также на Мiсrosoft QuickBasic 4. С базами данных системы R:base позволяет работать программный продукт PI (Program Interfase) фирмы Мiсгosoft, поставляемый совместно с системами R: Ьаsе System V и R: Ьаsе for DOS. Он обеспечивает доступ к базам данных из программ, написанных на языках Мiсгоsоft Fortran, Мiсгоsоft Раsсаl, Мiсгоsоft С. Пакет R:bridge, созданный Synchronicity Research, оснащает таким же возможностями аналогичные системы программирования фирмы Borland International Inc. — ТuгЬо Fortran, ТuгЬо Раsсаl, Turbo C. Он включает резидентный модуль манипулирования данными, для которого существует и мультипользовательская версия, а также ряд утилит. В 1990 г. программный продукт для работы с базами данных ее СУБД Рагаdох выпустила фирма Вогlаnd Int. Библиотека Рагаdоx Еngine предоставляет интерфейс включающего языка для программ на языке «С». Менее известное средство для тех же целей — пакет АссSys for С Рагаdох, разработанный фирмой Сорiа International LTD., располагающий как монопользовательской, так и мультипользовательской версиями. интерфейсы обоих типов Имеются в виду специальные дружественные интерфейсы для непрограммирующих пользователей в некоторых развитых программируемых системах. Интерфейс такого рода вызывается для пользователей системы dBaseIII PLUS с помощью команды ASSIST. При этом выбранные пользователем в разветвленном иерархическом меню альтернативы и введенные значения параметров система отображает в команды ее языка программирования и непосредственно их исполняет. Результаты исполнения заданных таким неявным способом команд предоставляются пользователю вместе с информационными и диагностическими сообщениями системы. С помощью таких пошаговых действий пользователь решает в конце концов стоящую перед ним задачу. При всей комфортности работы в режиме, аналогичном ASSIST, ясно, что решение более или менее сложных регулярно повторяющихся задач такими средствами чрезвычайно неэффективно. Поэтому в подобных случаях нужно воспользоваться средствами языка программирования и создать прикладную систему, избавляющую пользователя от необходимости выполнения большого количества операций, задаваемых вручную, и значительных потерь времени. В то же время использование таком дружественного интерфейса чрезвычайно удобно для оперативного выполнения разнообразных процедур разового характера. Интерфейсами указанного характера обладают помимо системы dBaseIII PLUSE, также dBaseIV, R:base, Paradox, позднее версии продуктов фирмы Fox Software и ряд других систем.) Пользователи базы данных Роль пользователей базы данных Пользователями базы данных являются: администратор БД, администраторы функциональных подсистем, системные и прикладные программисты, конечные пользователи. Вполне естественно, что их роль при работе с базой данных различна. Роль администратора БД: На стадии проектирования БД администратор БД выступает как идеолог и конструктор системы, руководит работами по созданию программного окружения БД. На стадии эксплуатации администратор БД — ответственное лицо за функционирование информационной системы; он управляет режимом использования данных. Основные задачи администратора БД при эксплуатации: защита данных от разрушения, обеспечение достоверности данных, анализ эффективности использования ресурсов информационной системы. Роль администратора функциональных подсистем: Администратор функциональных подсистем совместно с администратором БД разрабатывают программные «фильтры » для пользователей. Кроме того администратора функциональных подсистем определяют алгоритмы обработки данных, необходимые при проектировании информационной системы. Роль системных программистов: Системные программисты выполняют генерацию СУБД, следя за ее функционированием в среде операционной системы. Разрабатывают по заданию администратора БД программные компоненты, расширяющие программное обеспечение СУБД. Роль прямых конечных пользователей: Прямые конечные пользователи обращаются с базой данных в диалоговом режиме. Часть из них умеет обращаться к заранее составленным приложениям и интерпретировать ответы информационной системы. Другие умеют самостоятельно разрабатывать новые приложения. Роль косвенных конечных пользователей: Косвенные конечные пользователи не обращаются с ЭВМ непосредственно. Они формулируют свои запросы службе администратора БД, а затем получают ответы на бумаге, которые перед тем, как их передавать заказчику, интерпретируются специалистами. Администратор базы данных: Администратор базы данных (АБД) — под этим понятием подразумевается лицо (или группа лиц, возможно, целое штатное подразделение), на которое возложено управление средствами базы данных организации. АБД должен быть энергичной и способной личностью, организатором по призванию, желательно с техническим уклоном. Должен уметь поддерживать взаимосвязи, как с руководством высшего уровня, так и с пользователями, обрабатывающими данные, а также руководить штатом технических специалистов. Этот штат должен включать в себя лица, имеющие опыт работы в таких областях, как программное обеспечение СУБД, операционные системы, техническое обеспечение ЭВМ, прикладное программирование, системное проектирование. Важно так же, чтобы в этот штат были включены лица, имеющие представление об организации и ее информационных потребностях. Персонал АБД должен уметь поддерживать хорошие отношения с другими группами, не входящими в отдел обработки данных. Внедрение БД занимает довольно продолжительное время, так как их развитие происходит по мере разработки и интеграции прикладных программ, расширения БД. Поэтому функции АБД долгосрочные и направлены на координацию всех этапов проектирования, реализации и поддержания БД. На стадии проектирования БД администратор выступает как идеолог и главный конструктор системы, руководит всеми работами по выбору и приобретению (или разработке) системного программного обеспечения, по проектированию и созданию БД и прикладных программ, обучению специалистов, которые будут эксплуатировать систему, координирует вопросы приобретения оборудования и программных средств и т. п. На стадии эксплуатации банка данных АБД выступает не только как идеолог системы, но и как лицо, ответственное за нормальное функционирование БД, управляющее режимом его работы и использования, отвечающее за сохранность данных. Место АБД было определено тогда, когда организации осознали необходимость централизованного управления ресурсами данных, обработкой данных и другими аспектами, связанными с базой данных. Группы пользователей и отдельные пользователи должны обслуживаться всеми средствами исходя из целей и возможностей организации в целом. Поэтому АБД является ответственным за анализ потребностей пользователей, проектирование базы данных, ее внедрение, обновление или, если необходимо, реорганизацию базы данных, а также за консультацию и обучение пользователей. Функции администратора: координировать все действия по проектированию, реализации и ведению БД; учитывать перспективные и текущие требования пользователей; следить, чтобы БД удовлетворяла актуальным информационным потребностям; решать вопросы, связанные с расширением БД в связи с изменением границ ПО; разрабатывать и реализовывать меры по обеспечению защиты данных от некомпетентного их использования, от сбоев технических средств, по обеспечению секретности определенной части данных и разграничению доступа к данным; выполнять работы по ведению словаря данных; контролировать избыточность и противоречивость данных, их достоверность; следить за тем, чтобы БнД отвечал заданным требованиям по производительности, т. е. чтобы обработка запросов выполнялась за приемлемое время; — выполнять при необходимости изменения методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определять степень влияния изменений в данных на всю БД; — координировать вопросы технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию; координировать работы системных программистов, разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы. координировать работы прикладных программистов, разрабатывающих новые ПП и выполнять проверку и включение прикладных программ в состав программного обеспечения системы. Прикладной программист: При работе с БД могут возникнуть ситуации, когда целесообразно составить специальную прикладную программу для обработки ряда запросов, которые предполагались произвольными, но оказались относительно постоянными по содержанию и времени поступления. Поэтому в составе обслуживающего персонала БД имеются специалисты в области обработки данных, выполняющие программирование функциональных задач, т. е. разрабатывающие прикладные программы. Пользователи этой категории обычно умеют работать на нескольких алгоритмических языках программирования, знакомы со средствами обработки, имеющимися в составе используемого банка данных. Для обеспечения нормальной работы этой категории пользователей необходимо наличие в системе словаря данных и хорошо поставленной службы слежения за его состоянием. Из словаря данных узнают о наличии соответствующих типов данных, их структуре и связях между ними, обо всех изменениях, происходящих в структуре информационной модели. Параметрический пользователь: Параметрических пользователей еще называют конечными пользователями — наиболее многочисленная группа лиц, для удовлетворения информационных потребностей которых и создается банк данных. Это специалисты в своей области деятельности (руководители подразделений предприятия, работники медицинских учреждений, читатели тематических библиотек, кассиры в сберегательных кассах и т. д.), которые обычно не имеют специальной подготовки по программированию. Они охотнее обращаются к системе, если не требуется много затрат на подготовку запроса. Для этой группы пользователей идеальной может быть система, общение с которой выполняется на естественном языке. Поэтому целесообразно обеспечивать конечных пользователей специальным формализованным языком запросов, напоминающим естественный язык, и работать на этом языке в режиме диалога <пользователь — система>, целью которого является уточнение запроса пользователя, оказание пользователю помощи в ознакомлении с возможностями системы. Классификация пользователей базы данных Пользователей базы данных по признаку постоянства общения с базой данных можно разделить на две группы: постоянных и разовых пользователей. Постоянные пользователи — такие, которые регулярно пользуются услугами базы данных и для которых можно заранее сформулировать типы запросов, определяющие круг их интересов. Постоянные пользователи могут обращаться к системе и с произвольными по содержанию запросами. Разовые пользователи — те, которые не имеют постоянных запросов, но могут обращаться к системе с произвольными по содержанию запросами. Пользователей базы данных различают также по уровню компетенции, характеризующему возможность доступа пользователя к тем или иным данным. Речь идет о защите определенной части данных от тех пользователей, которые по различным причинам не должны иметь возможность их получения или изменения. Следовательно, БД должна иметь специальные средства для обеспечения санкционированного доступа пользователей к данным. Пользователи базы данных отличаются друг от друга по форме представления запросов, с которыми они обращаются к системе, а также по форме представления затребованной информации. По этим признакам всех пользователей разделяют на две группы: пользователи-задачи и пользователи-люди. Пользователи-задачи обращаются к базе данных с регламентированными по форме и по содержанию запросами. Выдаваемая им информация соответствующим образом обрабатывается и компонуется на основании принятых в системе формальных правил и соглашений. Пользователи-люди обращаются к базе данных с произвольными либо с регламентированными по содержанию запросами. Выдаваемая им информация должна иметь удобную для человека форму представления: в виде текста на естественном языке, таблиц с пояснениями, графиков и т. п. Методы и сценарий организации диалога пользователя с базой данных: В настоящее время используются два основных режима организации диалога пользователя с базой данных: пакетный; диалоговый. Суть пакетного режима сводится к накоплению запросов пользователей в течение некоторого интервала (обычно от нескольких часов до нескольких суток), оформлению их в виде пакета программ и автономной обработке на ЭВМ без вмешательства пользователей. Такой режим обеспечивает высокую степень загрузки ЭВМ, однако, с увеличением объема предоставляемых услуг, качества и возможностей современных компьютеров растут и потребности лиц, пользующихся ЭВМ, поэтому пакетный режим работы уже не устраивает пользователей. Основным недостатком такого взаимодействия являются неприемлемо большие сроки удовлетворения информационных потребностей с момента их возникновения у конечных пользователей. В последнее время большой интерес пользователей вызывает диалоговый режим. Для реализации диалогового режима необходимо учитывать программистскую квалификацию потенциальных пользователей базы данных. В большинстве случаев пользователи — это лица, мало знакомые, как с языками программирования, так и с приемами и средствами обработки информации с помощью ЭВМ. Даже знания какого либо языка программирования высокого уровня недостаточно для эффективной обработки информации средних и больших объемов, поэтому одним из важных при разработке информационных систем является вопрос лингвистического обеспечения диалога пользователей с БД. Диалоговый режим обеспечивает: непосредственный контакт между пользователем и системой, т. е. прием и выдачу разнообразных сообщений посредством локального или удаленного терминала; оперативный поиск необходимых пользователю данных и (или) программ; возможность практически одновременно обслуживать нескольких пользователей в условиях, когда потребность в обслуживании непредсказуема. В диалоговом режиме типа «запрос—ответ» взаимодействие с пользователем осуществляется в нескольких вариантах: на языке, близком к естественному, путем заполнения пользователем форматов, предъявляемых машиной — это пассивный диалог; путем выбора из «меню» необходимого варианта решения задачи — активный диалог. Такая организация взаимодействия существенно облегчает обучение работе с системой пользователей, не обладающих специальными навыками работы с автоматизированными средствами обработки информации. При диалоговом режиме система должна быть: нечувствительна к ошибкам пользователя: если смысл неправильно введенного сообщения можно определить из контекста, система должна корректировать неправильный ответ, поэтому в формулировке запросов пользователей должна допускаться некоторая избыточность сообщений; если у пользователя возникнут какие либо затруднения в процессе диалога, система должна дать ему информацию о дальнейших действиях; пользователю должна быть дана возможность на любой стадии диалога и выполнения задания корректировать ранее введенные сообщения; обязательно должен осуществляться контроль на допустимость ответов пользователя, содержащих числовые параметры; должна быть предусмотрена система сообщений об ошибках, которая давала бы возможность обнаруживать их и исправлять, а также система регистрации ошибок пользователя. Анализ работы неподготовленных пользователей показывает, что даже набор одного слова вызывает у них трудности, неуверенность в выборе. В системах, где предлагается вводить лишь номер предлагаемого варианта либо использовать выбор варианта в режиме непосредственного перемещения курсора на экране дисплея, пользователи осваиваются быстро и в основном без помощи оператора. Такой диалог менее гибок, так как пользователь должен выбрать вариант из предложенного ему списка, однако эта последовательность может иметь ответвления на любом шаге, что позволяет выполнять смежные работы. Язык меню освобождает пользователя от изучения мнемоники языка или программных операторов и позволяет ему без специальной под готовки работать с обширным набором различных программ, не делая ошибок. Поэтому для многих проблемно ориентированных систем это наиболее подходящая форма интерфейса «человек — ЭВМ».