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

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

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

Для обеспечения переносимости приложений из среды одной СУБД в среду другой важное значение имеет стандартизация интерфейсов прикладного программирования СУБД. В настоящее время разработаны индустриальные и международные стандарты интерфейсов прикладного программирования, основанные на различных моделях (см. разд. 5.6) данных и ориентированные на разные языки программирования. Так, для реляционных СУБД разработаны стандарты ODBC (для различных языков программирования), JDBC и SQLJ (для программ на языке Java), SQL/OLB (общий для объектных языков компонент стандарта SQL:1999). Для объектных СУБД  разработаны стандарты интерфейсов прикладного программирования, ориентированные на языки C++, Smalltalk и Java.

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

Что такое «кнопочный» интерфейс?

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

Какие виды интерфейсов конечных пользователей применяются в СУБД?

Что такое язык четвертого поколения?

Какого рода интерфейсы СУБД используются для доступа приложений к базе данных?

Каким образом осуществляется взаимодействие приложений и СУБД при помощи интерфейса прикладного программирования?

Почему актуально проблема стандартизации интерфейсов прикладного программирования СУБД?

8.6. Модели данных

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

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

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

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

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

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

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

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

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

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

Еще в конце 60-х годов, на ранних стадиях разработки программного обеспечения систем баз данных были выдвинуты идеи многоуровневой архитектуры таких систем. Эти идеи получили в дальнейшем конструктивное развитие в исследованиях Рабочей группы по базам данных CODASYL, в широко известном отчете рабочей группы по базам данных Комитета по планированию стандартов Американского национального института стандартов (ANSI/X3/SPARC), в работах М. Сенко, Я. Палмера, Г. Найсена и других специалистов в области систем баз данных.

Разработка новых архитектурных подходов, основанных на концепциях многоуровневого представления данных, породила, в свою очередь, проблемы отображения данных. Необходимость их решения возникла и в связи с исследованиями в области распределенных баз данных. Именно в связи с этим вторая половина 70-х - начало 80-х годов стали периодом значительной активизации исследований и разработок в области моделей данных, которые привели к трансформации содержания термина модель данных и к формированию его современной трактовки.

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

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