Текстология

Программное обеспечение банков данных (прагматический подход)

А. Н. Наумов, А. М. Вендров, В. К. Иванов (СССР).

Текст статьи взят с сайтаopen in new window, изображения с сайтаopen in new window журнала «Программные продукты и системы». Статья опубликована в выпуске журнала № 3 за 1988 год.

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

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

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

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

К 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).

Рис. 1. Пример таблицы систематизированных параметров СУБД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • имитационное моделирование;
  • экспериментальные исследования;
  • получение эксплуатационных характеристик на функционирующих БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • комплексность разработок (необходимая степень функциональной полноты), ПС окружения, их концептуальное единство для различных ЭВМ;
  • минимизация количества разработок до объективно необходимой номенклатуры для ЭВМ общего назначения, мини-ЭВМ, мегамини-ЭВМ не более 3-4 новых образцов, микроЭВМ и микропроцессорных устройств 5-10 новых образцов;
  • максимальный учет требований пользователей всех категорий;
  • соответствие разрабатываемых СУБД статусу программного изделия;
  • оригинальность разработки (на уровне исходных тестов);
  • соответствие планируемых к решению частных проблем в конкретной разработке планируемым возможностям вычислительной техники;
  • наличие стабильного коллектива разработчиков;
  • выработка и неукоснительное соблюдение принципа «пирамиды применений», который заключается в минимизации количества применяемых СУБД на уровне АС отраслей, регионов, ведомств, крупных предприятий и объединений с расширением их числа вниз по уровням управления.

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

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

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

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

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

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

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

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

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

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

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

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

  • язык имеет достаточную полноту, поскольку включает средства определения данных, манипулирования ими и спецификации ограничений целостности;
  • сочетает средства как конечного пользователя, так и прикладного программиста, прост в освоении и использовании;
  • обладает развитыми возможностями разграничения доступа и контроля целостности данных;
  • текущая версия языка признана международным стандартом, его подмножества реализованы в таких СУБД, как DB2, ORACLE, IDMS, ADABAS, TIS/XA, SQL/DS, INGRES.

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

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

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

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

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

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

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

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

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

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

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

Последниее изменение: