Предисловие (стр. 32 )

Имеются многочисленные примеры языков СУБД, объединяющих возможности описания данных и манипулирования данными в единых синтаксических рамках. Весьма популярным среди языков такого рода является реляционный язык SQL, прототип которого – язык SEQUEL был разработан в исследовательской лаборатории компании IBM в Сан-Хосе и реализован в середине 70-х годов в экспериментальной реляционной СУБД System R, а впоследствии и в коммерческих системах компании - SQL/DS и DB2.

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

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

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

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

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

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

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

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

Попытки преодоления указанных трудностей привели к созданию еще в середине 70-х годов и активному развитию в 80-х годах направления в технологиях баз данных, посвященного разработкам новых языков, которые стали называться языками программирования баз данных, и основанных на этих языках систем программирования. Указанные языки – это целостные языки программирования, основанные на единой модели данных, соединяющие на единой концептуальной основе как возможности новейших языков программирования, так и функции, свойственные языковым средствам традиционных СУБД. Ряд таких языков был создан и реализован в нашей стране и за рубежом. Они представляли собой расширения известных языков программирования Паскаль, Ада, Модула либо являлись оригинальными языками, например, Атлант, Тексис, Галилео и др.

Хотя языки программирования баз данных оказали большое влияние на развитие не только общеупотребительных языков программирования, но и моделей данных в базах данных, тем не менее, они не нашли широкого практического распространения. Вероятно, причины этого заключаются в интенсивном внедрении в практическое программирование во второй половине 80-х - начале 90-х гг. объектного языка C++, основанного на привычном большому кругу программистов языке C. В середине 90-х гг. к нему добавился также язык Java. Наконец, сыграло свою роль создание стандарта объектных баз данных ODMG, определяющего интерфейсы прикладного программирования для указанных объектных языков. Сочетание объектного языка программирования и объектной базы данных снимает проблему несоответствия импеданса - главную причину рождения языков программирования баз данных.

Контрольные вопросы

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

Для реализации какого принципа организации интерфейса конечного пользователя был создан язык QBE, каковы возможности этого языка, кем и когда он был разработан?

Какие две основные функции выполняют языковые средства моделей данных?

Для каких целей служат языки определения данных в СУБД?

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

Средствами каких языков определяются в СУБД междууровневые отображения данных?

Какие функции выполняют языки манипулирования данными?

Приведите пример языка, который выполняет функции как определения данных, так и манипулирования данными.

Когда и для чего был создан язык SQL?

Каково назначение языков запросов СУБД?

Какие языки СУБД называют автономными?

На какие языковые средства программирования ориентированы интерфейсы прикладного программирования СУБД?

Какие языки программирования называют включающими языками и почему?

Какое явление в технологиях баз данных принято называть несоответствием импеданса?

Для каких целей разрабатывались языки программирования баз данных?

Каким образом решается проблема несоответствия импеданса в современных технологиях баз данных? 

8.9. Организация среды хранения базы данных

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

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

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

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

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