Software & Systems

Опыт создания банков данных показы нает, что методы и средства организации хранения данных определяют качество автоматизированных систем (АС) и возможность получения информации, необходимой пользователям всех уровней. Концепции интегрированного хранения, централизованного управления и многоаспектного коллективного использования данных получили наибольшее признание в последние годы. Эффективным способом реализации этих концепций является метод построения информационного обеспечения АС на базе программно-совместимых компонент-систем управления базами данных (СУБД) и программных средств (ПС) их окружения.

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

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

В СССР в течение 1986 г ряда лет анализировалось состояние разработки и внедрения СУБД и ПС их окружения, а также определяются перспективы развития.

К . в нашей стране насчитывалось уже более 50 СУБД. Однако правильная техническая политика позволила применять около 10—15 систем.

В реализации СУБД и ПС их окружения отмечаются существенные различия:

поддерживаемая модель данных и организация баз данных в целом (иерархические, сетевые, дескрипторные, реляционные системы и их многочисленные разновидности);

способы организации структуры хранения данных (среда хранения, представление и размещение, методы доступа);

программная реализация СУБД: соотношение между комплексным интегрированным ПС (с возможными вариантами) и в качестве альтернативы совокупностью собственно СУБД (ядро) и ПС системного и функционального окружения.

Такое положение имеет как позитивные (ориентация на конкретные классы приложений, стимулирование разработок, поиск новых решений), так и негативные (трудности выбора СУБД, дублирование разработок) стороны.

Тем не менее в мире определился набор СУБД, обладающих высокой конкурентоспособностью: TIS/XA (TOTAL), IDMS, IMS/VS, DB2, ADABAS, ORACLE, DATACOM/DB, INGRES.

Анализ значительной части разработанных и используемых в настоящее время в нашей стране СУБД проводился по следующим направлениям:

классификация по обобщенным параметрам;

систематизация по функциональным возможностям и характеристикам;

оценка применяемости.

Анализ позволил оценить качество СУБД и сформулировать концепции их дальнейшего создания и внедрения.

Классифицированы по обобщенным параметрам следующие СУБД, разработанные в 16 организациях страны: ОКА, ИНЕС, БАНК-ОС, СЕТОР-3.0, СИОД-3-ОС, АИСТ-Развитие, ПАРМА, РЕБД, ВЕРА, БАЙКАЛ, УНИСОН, ДАБУ, КВАНТ, ДИСОД, СЕТЬ, РИС, ПАЛЬМА, СПЕКТР, ЕНФ, СЕТОР-СМ, МИРИС, КВАНТ-М, БАРС, БАЗА-CM, БАЗИС, МИКРОСЕТОР, КАРС.

Перечисленные системы следует рассматривать как промышленно-сопровождаемые и экспериментальные (см. табл.).

К промышленно-сопровождаемым отнесены СУБД, внедренные на большом количестве промышленных предприятий, включенные в состав межотраслевых фондов, и перечень СУБД, рекомендованных для применения, например: ОКА, ИНЕС, БАНК-ОС, СЕТОР-3.0 (СЕТОР-СМ, МИКРОСЕТОР), СИОД-3-ОС, ДИСОД (МИРИС, АИСТ-Развитие), СЕТЬ, БАЗА-CM, КАРС. Они, как правило, централизованно сопровождаются, их техническая документация выполнена в соответствии с требованиями ЕСПД.

К экспериментальным отнесены СУБД, внедренные на отдельных объектах, включенные в отраслевые или республиканские фонды и сопровождаемые организациями-разработчиками.

По функциональным возможностям и характеристикам СУБД систематизировались на основе представленных разработчиками таблиц с некоторыми уточнениями и дополнениями. Такие таблицы можно считать «паспортом» конкретной СУБД (рис. 1).

По классу поддерживаемой на концептуальном уровне модели данных и некоторым другим характерным признакам можно выделить следующие СУБД, ориентированные на поддержку:

Классификация СУБД по обобщенным параметрам
ОКА, ИНЕС — в основном иерархической модели, но имеется возможностыюцдержки и ограниченной сетевой модели;

СЕТЬ, БАНК-ОС, ПАРМА, БАЙКАЛ, СИОД-3-ОС — сетевой модели;

СЕТОР-3.0, СЕТОР-СМ, МИКРОСЕТОР — ограниченной сетевой модели;

ДИСОД, АИСТ-Развитие, КВАНТ. СПЕКТР, КВАНТ-М, МИРИС — специальной файловой модели, промежуточной по отношению к плоским моделям и моделям «сущность-связь»;

РЕБД, ВЕРА, УНИСОН, РИС, БАЗИС, ДАБУ. ЕНФ — реляционной модели данных, но не являются реляционно-полны ми по отношению к языку манипулирования данными (ЯМД). поэтому целесообразно считать их реляционно-ориентированными:

КАРС, ПАЛЬМА — реляционной модели.

Управление размещением данных в среде хранения характерно в основном для иерархических и сетевых СУБД и нехарактерно для реляционных.

Практически все СУБД имеют средства вторичной индексации, кроме БАНК-ОС, СИОД-3-ОС, БАЙКАЛ, БАЗИС, ЕНФ.

Сжатие данных характерно для СУБД ЕС ЭВМ, так как при поддержке крупных баз данных значительно экономится внешняя память.

Типичный набор включающих языков для СУБД ЕС ЭВМ: ПЛ/1. КОБОЛ, ассемблер (реже ФОРТРАН), а для СМ ЭВМ: ФОРТРАН, КОБОЛ, ассемблер. Используются также языки Паскаль (БАЗИС, БАРС, КВАНТ-М), БЕЙСИК (МИРИС).

Минимальный набор функций (хранение, актуализация и доступ к данным), реализуемых каждой СУБД, обеспечивается их языковыми и программными компонентами. Однако функциональная полнота системы определяется наличием средств,

Рис 2 Состав функций по созданию и ведению БД

пользователей: конечный пользователь, не имеющий специальной подготовки для работы с СУБД; конечный пользователь-— специалист по проблемной области, имеющий подготовку для работы с применением средств СУБД для непрограммиста; прикладной программист, администратор задач (приложений); администратор БД. Функциональная тошнота СУБД может быть также охарактеризована степенью основных функций по созданию и ведению БД (рис.2). Для большинства п ромы иг ленно -сопровождаемых ('УВД разработаны словари-справочники, средства чагручки. генераторы отчетов, языки ча-иросов для пол ьзо вате лей-непрограммистов. В достаточной степени во всех СУБД представлены программные средства администратора БД.

При вводе и jarpyjKe данных можно иыделить следующие варианты:

применение достаточно апробированных генераторов (интерпретаторов) программ ивода (ГВ-ОС, СПЦ-ОС), имеющих средства кон-троля вводимых данных:

разработка интерфейсных программ загрузки для конкретных СУБД (например, СУБД ОКА — ППГТ КОМПАКТ, СУБД СЕТОР — ППП СЕТОР-ДОСТУП);

использования комплексированьк; с СУБД программных средств или специальных утилит (ИНЕС. ДИСОД, КАРС, СЕТЬ).

Для организации удаленного теледоступа используется пакет прикладных программ (ППП) КАМА. для некоторых СУБД (СЕТОР, ДИСОД) обеспечивается работ;] локальных терминалов с ППП ПРИМУС или под управлением ОС ЕС в режиме разделения времени. СУБД ИНЕС и СЕТЬ могут применить собственные телемониторы. Некоторые компоненты одних СУБД можно использовать с другими, например телемонитор и язык сценарии диалога СУБД ИНЕС в СУБД СЕТОР.

Генераторы программ отчетов или аналогичные им программные средства разработаны также в различны* вариантах: непосредственно для конкретной СУБД (ИНЕС, СЕТЬ, ДИСОД, КАРС), с исиоль-чованием возможностей других ППП (СЕТОР 3.0-СПД. ОКА-КОМИС, СИОД-3-ОС-СОПД), в тон числе с предварительной линеаризацией выходных файлов, содержащих данные для отчетов (БАЗА-СМ). Словари-скравочники данных реализованы как интегрированные с СУБД (СЕТЬ, ИНЕС. БАЗА-СМ) или независимые (ДИСОД, СЕТОР).

Для взаимодействия пользователей-непрограммистов с СУБД разработаны языки запросов (ЯЗ). Ь частности, один из них, реализованный в ППП ТЕЛССПРА8КА. ориентирован на работу с СУБД ОКА, СИОД-3-ОС, СЕТОР; существует версия этого языка для СУБД ДИСОД, для некоторых СУБД разработаны ЯЗ типа -запрос по примеру» (ИНЕС, ДИСОД, СЕТОР-СМ. БАЗА-CM. СЕТЬ).

Важной чертой СУБД является возможность их использования в комплексе с функциональными ППП, например СУБД СИОД-3-ОС с системой ППП ИСУП, ИНЕС с ППП ПМОУ, ОКА с ППП ЛП АСУ.

Для широко применяемых СУБД необходимо иметь набор функциональных ППП. по крайней мере для наиболее «консервативных» подсистем (управление кадрами, финансами, бухгалтерский учет).

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

И большинстве случаев вопрос использования СУБД в АС определяется соотношением доступных и требующихся ресурсов. В этой связи регламентированность применения СУБД в анализ рационального использования возможностей и преемственности СУБД при развитии АС является важным фактором определения данного соотношения. Кроме того, регламентированность применения СУБД объективно предполагает и определенную регламентированность их разработок.

Зарубежный рынок СУБД предлагает пользователям широкий выбор фактически равноценных по качественным характеристикам систем. Например, во Франции используется 27 СУБД, однако наиболее часто внедряемыми являются TOTAL и ADABAS. Это зависит в основном от конкуренции между фирмами в сфере сбыта ПО и, по-кидимому, в ближайшее время не изменится, В большинство новых разработок включаются компоненты, способствующие «поглощению» СУБД фирмы-конкурента илн обеспечивающие их совместное внедрение в будущем.

Для стран—членов СЭВ также характерно широкое использование отдельных разработок (ГДР — DBS/R,I1IIP —РОДАН, ЧССР —IDMS).

Все изложенное позволяет говорить о целесообразности применения ограниченного числа СУБД. концентрации усилий на решении проблем и* функциональной полноты и унификации программных компонент.

В течение 3-5 лет после завершения разработки СУБД происходит естественный отбор наиболее «жи-вучих» из них. «Выживанию» и значительной мере способствует организация централизованного сопровождения ПС. Квалифицированная поддержка СУБД, их модернизация, оказание услуг пользователям являготси гарантией массового внедрения конкретной СУБД. Однако следует учесть, что трудовые ресурсы любой централизованной службы сопровождения ограничены, поэтому промышленное сопровождение 20-30 СУБД вряд ли оправдано экономически.

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

Анализ использования систем позволил выявить следующие особенности:

одни и те же СУБД применяются в АС различных уровней;

разнородные подсистемы АС функционируют на 6aie одной и той же СУБД;

применяемый тип СУБД не зависит от объекта управления (тип производства, его характер и т. п.).

Эти особенности подтверждают универсальность СУБД и случайность их выбора пользователями.

Неудачи в применении СУБД связаны чаще всего с первоначальными ошибками а их выборе, попытками замены одной системы другой под влиянием моды на конкретный тип СУБД или конъюнктурных соображений. Такие ошибки характерны для определенного контингента пользователей — администраторов БД (системы) или приложений и совершаются, как правило, в условиях достаточной информированности об основных функциональных возможностях СУБД, но oei учета технической политики в вопросах, касающихся, например, применения типовых ПС в сходных по характеру и типу производства предприятиях одной подотрасли, перспектив развития выбрапгюй для применения СУБД, возможностей коллектива разработчиков и службы сопровождения и ряда других факторов.

Рис 3 Динамика спроса на промышленно-сопророждаемые СУБД

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

быстрая реакция на каждую вновь объясняемую СУБД и попытка создания АС на ее основе с потерей задела по функционирующим или проектируемым приложениям;

принятие недостаточно обоснованного директивного решения (на уровне отрасли) о переходе на использование одной конкретной разработки во всех АС.

Анализ показывает, что динамика спроса практически на все промышленно-сопровождасмые СУБД имеет одинаковый характер (рис. 3).

Решение о выборе СУБД зависит о г множества факторов, однако должны приниматься во внимание те из них, которые в меньшей степени поддаются формализуемым оценкам:

наличие отраслевой технической ПОЛИТИКИ при регламентации применения СУБД, основанной на опыте базовых объектов и особенностях объектон автоматизации;

разумный консерватизм, связанный с учетом соотношения затрат на полное перепроектирование или модернизацию АС.

Следует отметить большое влияние системотехнических параметров на оценку СУБД.

Нельзя также исключать возможности применения двух и более СУБД в рамках одной системы или обеспечения плавного перехода от одной СУБД к другой конвертированием данных и программ.

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

Головным организациям отраслей целесообразно определить наиболее Приемлемые СУБД для использования в АС верхнего (отраслевого), среднего (объединения) и нижнего (предприятия) уровней с учетом специфики,-опыта применений, типовых проектных решений и необходимости в дальнейшем интеграции локальны* БД. При этом должно быть предусмотрено создание стандартных интерфейсов для обеспечения возможности замены СУБД без существенной переработки прикладных программ (например конвертирующие системы! и унифицированных ПС окружения.

Рекомендации по использованию СУБД, основанные на опыте их ннедрсния, приведены на рис. 4. Разработаны методические материалы общеотраслевого и отраслевого уровней. По основным про-мьппленно-сопровождаемым СУБД имеются данные об их производительности в различных режимах работы (загрузка, корректировка и поиск), полученные на единой тестовой БД. Они могут служить основой выбора СУБД для конкретного применения

В более широком смысле выбор и рациональное использование СУБД должны основываться на еди-

ной методологии оценки их качества. Она должна включать систематизированный перечень показателей качества и правила ил определения для конкретных СУБД.

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

Цель разработки любой СУБД — создание такого ПС, которое максимально соответствовало бы потребностям пользователей и было обеспечено технологическим процессом производства, поддержки и поставки.

Ранее рассмотренные параметры оценки функциональных возможностей и характеристик СУБД, а также некоторые дополнительные параметры сгруппированы в соответствии с выбранной целью таким образом, что можно выделить ряд показателей качества, степень соответствия которых максимально возможной величине будет определять в сумме степень соответствия конкретной разработки «статус СУБД».

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

характеризовать СУБД как продукцию производственно-технического начначения;

оцениваться количественно;

охватывать создание и эксплуатацию БД

6 зависимости от характера оцениваемых свойств СУБД существуют группы показателей качества:

показатели назначения;

показатели надежности функционирования;

показатели технологичности;

эргономические показатели;

конструктивные показатели;

показатели унификации;

эксплуатационные показатели.

Одним из наиболее важных показателей качества является производительность СУБД. Это объясняется следующим обстоятельством.

Качественный характер сравниваемы* характеристик СУБД (когда оценки тех или иных показателей имеют значение типа «да-нет», «имеется-отсутствует», «хорошо-удовлетворительно-плохо» и т. п.) ча-

Рнс. 4. Области применения СУ&Д

сто приводит к тому, что в рез)отьтате выбора СУБД появляется несколько претендентов на использование фактически равноценных по критериям, которые применялись при выборе, а в отдельных случаях он нера.фешим: подходит все сравниваемые СУБД. В дальнейшем внедрение выбранной СУБД нередко приводит к неудовлетворительным результатам, так как на этапе промышленной эксплуатации важнейшее значение приобретает производительность системы как по отдельным выполняемым функциям, так и среднее значение по всем функциям. Опыт доказывает необходимость использования на лтапе выбора количественных оценок производительности СУБД. Отсутствие аналитического метода ее оценки позволяет применять три подхода к решению этой задачи:

имитационное моделирование;

э кспе ри ме нтал ьны с иссл едова иия;

получение эксплуатационных характеристик на функционирующих БД.

Первые два подхода сопряжены со значительными трудозатратами, но имитационное моделирование предпочтите;! ьнее как более у ни нереальное. Однако при разработке имитационной модели СУБД возникает проблема оценки ее точности, эталоном которой могут служить результаты экспериментов Третий подход довольно сложен при реализации.

Исследовали ряд отдельных СУБД. Целью являлось получение сравнительных характеристик выбранных для конкретного применении систем, н которых о&^нинались параметры рациональной организации БД, сопоставлялись обьемно-временные характеристики загрузки и доступа для ЬД определенного состава и структуры. В любой случае результаты исследований позволяют получить характеристики, достаточные для установления динамики изменения производительности СУБД при переходе от одной области применения к другой.

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

В соответствии с предложенной методикой исследовались промышленио-сопровождаемыс СУБД: ОКА, БАНК-ОС. СЕТОР, ИНЕС, АИСТ-Развитие, ДИСОД, СЕТЬ, КАРС и др.

Исследования производительности СУБД выполнялись для следующих процессов:

)агрузка БД;

корректировка БД (включение, модификация и удаление данных);

обработка запросов к БД.

При этом были удовлетворены следующие условия:

при нескольких вариантах реализации исследуемых процессов для конкретной СУБД выбирался лучший;

входная информация была идентичной по обьему. составу и структуре для всех исследуемых СУБД;

время выполнения процесса замерялось через одинаковые порции входной или выходной информации;

исследования проводились на одинаковых вычислительных установках в монопольном режиме.

Полученные данные являются одним из основных факторов, определяющих выбор конкретной СУБД.

ПС (в том числе и СУБД), несовершенные по ряду параметров, развиваются двумя возможными путями, которые можно условно назвать «революционным» и «эволюционным». Под "революционным» путем понимается преобладающее внедрение только отечественных разработок практически во всех приложениях или стремление к применению одного типа СУБД на максимально возможном количестве объектов. «Эволюционный* предполагает постепенное вытеснение ПС, имеющих зарубежные анало-ги и. при параллельной проработке «революционного» пути на длительную перспективу, а также более жесткую регламентацию номенклатуры ПС и рекомендуемых сфер внедрения СУБД с учетом возможностей планирования и контроля, присущих социалистической экономике.

На рис. 5 приведена возможная интерпретация <■ эволюционного» пути по годам. При разработке стратегических планов развития ПО БД по этому варианту совершенно необходимо учитывать реальное состояние дел. Не стоит строить иллюзий, что наметившуюся еще в 1964—1965 гг. тенденцию копирования зарубежных образцов при разработке можно быстро приостановить.

С учетом предложенных путей развитии можно сформулировать следующие требования к разработкам и внедрению СУБД:

комплексность разработок (необходимая степень функциональной полноты), ПС окружения, их концептуальное единство для различных ЭВМ;

минимизация количества разработок до объективно необходимой номенклатуры для ЭВМ общего на!начения, мини-ЭВМ. мегамини-ЭВМ не более 3-4 новых образцов, микроЭВМ и микропроцессорных устройств 5-10 новых образцов;

максимальный учет требований пользователей всех категорий;

соответствие рафабатынаемых СУБД статусу программного изделия;

оригинальность разработки (на уровне исходных тестов);

соответствие планируемых к решению частных проблем в конкретной разработке планируемым возможностям вычислительной техники;

наличие стабильного коллектива разработчиков;

Рис 5 Возможная интерпретация эволюционного варианта развития ПО БД

выработка и неукоснительное соблюдение принципа ■«пирамиды применений», который заключается в минимизации количества применяемых СУБД на уровне АС отраслей, регионов, ведомств, крупных предприятий и объединений с расширением их числа внт по уровням управления

Выполнение этих требований будет способствовать сбалансированному сочетанию работ по созданию новых образцов СУБД и их эффективному применению. В этой связи целесообразно еще раз подчеркнуть особую важность проблемы регламентированного использования разработок, так как от правильного се решения (в том числе на межгосударственном уровне стран—-членов СЭВ) в значительной степени чависит объем необходимых ресурсов на дальнейшее развитие работ.

Многоаспсктность обсуждаемой проблемы и многообразие путей ее решения требуют всестороннего анализа наиболее актуальных и целесообразных направлений работ, таких как:

прагматическое, связанное с эволюционным характером развития СУБД;

научное. Определяющее основные направления фундаментальны* и прикладных исследований по проблеме:

опытно-конструкторское, связанное с реализацией принципиально новых образцов СУБД на основе научных исследований.

Прагматический аспект предполагает выполнение работ, способствующих:

расширению перечня промышлен но -сопровождаемых СУБД за ечет экспериментальны» и создаваемых систем, достижение ими статуса программной продукции:

повышению уровня комплексности разработок, т. е. созданию унифицированных проблемно-ориентированных Я1ЫК0Н запросов, языков конечного пользователя и систем интеллектуального доступа, генераторов программ отчетов и ввода данных, словарей, интерфейсов с функциональными ПГШ, средств конвертирования данных и прикладных программ, средств поддержки распределенных баз данных (РБД) и интеграции неоднородных БД;

модификации промьшшенно-сопровождасмых СУБД в соответствии с изменением среды функционирования;

определению рациональных сфер применяемости и производительности СУБД в основных режимах работы.

Научные исследования СУБД должны базироваться на анализе текущего состояния проблемы и смежных областей (базы знаний, экспертные системы, искусственный интеллект) и включать следующие работы:

упорядочение архитектуры и создание единой терминологии;

стандартизацию архитектуры перспективных СУБД, языковых средств пользователей, моделей и уровней представления данных, декомпозицию архитектуры до уровня типовых модулей;

разработку принципов построения адаптивных СУБД, спецпроцессоров БД. СУБД с многоуровневым представлением данных, дли хранения и организации доступа к графическим и неструктурированным данным, для многопроцессорных систем, для различных классов проблемных областей; ' обеспечение переносимости СУБД на разные типы ЭВМ.

Опытно-конструкторские работы (ОКР) должны основываться на опережающих результатах туч-нь&х исследований по названной тематике и требованиях к качеству СУБД. Результатом ОКР должны стать принципиально новые СУБД, предназначенные для функционирования ни перспективных моделях ЭВМ типа ЕС ЭВМ (РЯД-3, РЯД-4), СМ-1420, СМ-1700, ВК Эльбрус в среде мобильной операционной системы.

Для применения в 1990—1995 гг. необходима разработка следующих перспективных образцов СУБД:

адаптивной на основе унифицированных компонент с системой генерации;

с многоуровневым представлением данных;

для хранения и организации доступа к графическим и неструктурированным данным;

рели ционно-полной;

для многопроцессорных систем;

спецпроцессора БД, СУБД с микропрограммным управлением;

системы интеллектуального доступа и поддержки баз знаний.

В АС нередко возникает необходимость перехода к использованию новой СУБД, обладающей более развитыми функциональными возможностями и лучшими эксплуатационными характеристиками. В то же время такая потребность не обеспечивается средствами самих СУБД и ПС их окружения. Следует отметить, что временные и материальные затрать] при переходе к использованию новой СУБД являются ключевым фактором при принятии решения. Затраты могут быть существенно снижены только при использовании специальных ПС конвертирования БД типа ППН КОНВЕРТ.

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

Первым шагом к созданию такого интерфейса является разработка ППП «Язык запросов конечного пользователя» (ЯЗКП) для СУБД ИНЕС и ППП ПЛЮС-П, основанных на использовании представления запроса к БД по аналогии с известным ЯЗ табличного типа Query-By-Example (QBE). Однако из-за ограниченных возможностей QBE в качестве основы для реализации интерфейса используется более развитый язык SQL, Его выбор объясняется следующим:

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

сочетает средства как конечного пользователя, так и прикладного программиста, прост в освоении и использовании;

обладает развитыми возможностями разграничения доступа и контроля целостности данных;

текущая версия языка признана международным стандартом, его подмножества реализованы в такт СУБД, как DB2, ORACLE. 1DMS, ADABAS, TIS/XA, SQL/DS, INGRES.

Унифицированный интерфейс конечного пользователя разрабатывается на основе развития системы интеграции неоднородных БД в рамках КП НТП. Реализация интерфейса предполагается для СУБД СЕТЬ, ДИСОД. ИНЕС, а также для СУБД персональных ЭВМ.

В состав интерфейса (рис. 6) входят следующие основные компоненты:

генератор диалекта пользователя, выбирающий вариант языковых спецификаций интерфейса в соответствии с заданной лексикой конечного пользователя;

языковой процессор, выполняющий лексический и синтаксический анализы запросов на языке SQL, генерацию текста запросов на языке реляционной алгебры процессора данных системы интеграции и иывод сообщений о лексических и синтаксических ошибках;

диалоговый монитор, управляющий взаимодействием всех компонент системы в сеансе работы пользователя;

прскомпилятор, предварительно обрабатывающий операторов языка SOL в тексте прикладной программы;

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

интерфейс информационного обмена, реализующий обмен данными между БД, поддерживаемой примышлен но-сопровождаемыми СУБД на ЕС ЭВМ, и БД персональны* ЭВМ.

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

. Одним из требований к СУБД является гибкость и адаптивность отдельных ее компонент и системы БД в целом. Это требование вытекает из объективности изменения параметров внешней среды функционирования СУБД (например характеристик потока запросов к данным), а также в связи с развитием самой БД.

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

Рис. 6. Архитектура унифицированного диалогового интерфейса конечного пользователи

анализ существующих методов и средств адаптации npoiраммных и технических систем,

определение адаптивных свойств и параметров адаптации СУБД;

разработка структуры и функций системы в цепом и ее отдельных компонент, в том числе реализующих механизм адаптации;

сочданне алгоритмов функционирования и методов реализации системы;

анализ возможностей реализации принципов создания адаптивной СУБД средствами промышленное сопровождаемых СУБД:

разработка программной модели адаптивной СУБД.

Результаты могут исполковаться при конструировании СУБД, которые должны обладать способностью целенаправленного изменения своей структуры и параметров отнелыньи компонент в соответствии с изменяющимися критериями, функционирования к зависимости от внешней среды (предметной области).

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

В настоящее время разрабатываются методы и средства создания адаптивных структур хранения данных (в том числе для распределенных систем БД). Основная цель — поддержка самоорганизующихся структур «ранения, рассматриваемых как совокупность среды хранения (пространства памяти ЭВМ различных типов), хранимой БД (наборов взаимосвязанных записей манных) к правил ее отображения на среду хранения. В результате предполагается подготовить npoi-раммно-технологическую систему (с соответствующим методическим обеспечением) для создания и поддержки адаптивных структур хранения для промышленносопровождземых СУБД.