В. И. Швецов Базы данных
 Скачать 8.45 Mb.
|
|
ð+ переход из прикладной программы к запросу осуществляется вызовом специальной функции ð скомпилированная вместе с текстом запроса прикладная программа автоматически выполняется ð при неоднократном выполнении одного и того же запроса используется один и тот же программный модуль ð+ при каждом выполнении одного и того же запроса используются разные программные модули Задача 5. Характеристика команд динамического SQL Вариант 1. Какие операторы могут быть использованы в динамическом SQL? ð+ SELECT ð+ DELETE ð+ INSERT ð DECLARE TABLE ð EXEC SQL ð+ OPEN ð+ DECLARE CURSOR ð+ PREPARE ð+ EXECUTE Вариант 2. Какие специальные операторы могут быть использованы в динамическом SQL? ð SELECT ð DELETE ð INSERT ð DECLARE TABLE ð EXEC SQL ð GET DIAGNOSTIC ð+ DECLARE CURSOR ð+ PREPARE ð+ EXECUTE Вариант 3. Какие специальные операторы могут быть использованы в динамическом SQL для подготовки и выполнения SQL- запроса? ð DECLARE TABLE ð EXEC SQL ð GET DIAGNOSTIC ð+ PREPARE ð+ EXECUTE Задача 6. Характеристика интерфейсов программирования приложений (API). Вариант 1. Чем удобны интерфейсы программирования приложений? ð не требуется изучать алгоритмический язык программирования ð+ не требуется изучать специальные инструкции статического и динамического SQL ð+ соответствующий подход может применяться с использованием разных языков программирования ð не требуется изучать язык SQL Вариант 2. Как компилируется прикладная программа, использующая интерфейсы программирования приложений? ð+ прикладная программа компилируется вместе с вызовом функций библиотек ð вызов функций библиотек компилируется отдельно ð сформированный модуль запроса вставляется в модуль прикладной программы ð+ в модуль прикладной программы вставляется вызов функции библиотеки Вариант 3. Как выполняется программа с использованием интерфейсов программирования приложений? ð параметрами функций библиотеки интерфейсов программирования приложений являются имена таблиц, атрибутов и константы ð+ параметрами функций библиотеки интерфейсов программирования приложений являются тексты SQL- запросов ð+ переход из прикладной программы к запросу осуществляется вызовом специальной функции ð скомпилированная вместе с текстом запроса прикладная программа автоматически выполняется ð+ при неоднократном выполнении одного и того же запроса используется один и тот же программный модуль ð при каждом выполнении одного и того же запроса используются разные программные модули Задача 7. Что такое протокол ODBC? Вариант 1. Какова цель создания протокола ODBC? ð создание интерфейса с конкретной СУБД ð создание универсального интерфейса с СУБД ð+ создание универсального интерфейса с СУБД на уровне конкретной операционной системы ð создание библиотеки функций для обеспечения связи прикладной программы и СУБД Вариант 2. Что такое драйверы ODBC? ð программа- интерфейс между прикладной программой на алгоритмическом языке и вызовом функции API ð+ программа- интерфейс между вызовом функции API и программой, реализующей функции конкретной СУБД ð программа- интерфейс между прикладной программой на алгоритмическом языке и программой, реализующей функции конкретной СУБД ð программа- интерфейс между прикладной программой на алгоритмическом языке и программой, реализующей функции любой СУБД Вариант 3. Для чего в этом протоколе используются драйверы? ð для сокращения времени реализации запроса ð+ для создания возможности использования этого протокола в разных СУБД ð для удобства разработки прикладных программ ð для упрощения текста запроса к базе данных Задача 8. Что такое протокол JDBC? Вариант 1. Какова цель создания протокола JDBC? ð создание интерфейса с конкретной СУБД ð создание универсального интерфейса с СУБД ð создание универсального интерфейса с СУБД на уровне конкретной операционной системы ð+ создание библиотеки функций для обеспечения связи прикладной программы и СУБД ð+ создание интерфейса программы, написанной на определенном алгоритмическом языке, с СУБД Вариант 2. Что такое драйверы JDBC? ð программа-интерфейс между прикладной программой на определенном алгоритмическом языке и вызовом функции API ð+ программа-интерфейс между вызовом функции API и программой, реализующей функции конкретной СУБД ð программа-интерфейс между прикладной программой на алгоритмическом языке и программой, реализующей функции конкретной СУБД ð программа-интерфейс между прикладной программой на алгоритмическом языке и программой, реализующей функции любой СУБД Вариант 3. Для чего в этом протоколе используются драйверы? ð для сокращения времени реализации запроса ð+ для создания возможности использования этого протокола в разных СУБД ð для удобства разработки прикладных программ ð для упрощения текста запроса к базе данных ð для создания возможности обращения к функциям API из программы, написанной на языке Java Литература
Лекция 14. Направления развития баз данных В лекции рассматриваются перспективные направления в теории и практике создания баз данных – объектно-ориентированные и распределенные базы данных, а также новое направление в аналитической обработке данных = хранилища данных. Ключевые термины: направления развития баз данных, объектно-ориентированные базы данных, системы управления объектно-ориентированными базами данных, объект, класс, методы класса, наследование, системы управления объектно-реляционными базами данных, распределенные базы данных, системы управления распределенными базами данных, хранилища данных. Цель лекции: выделить основные черты в новых направлениях развития теории и практики создания баз данных (новые свойства, присущие объектно-ориентированным и распределенным базам данных) и хранилищ данных. 14.1. Объектно-ориентированный подход к организации баз данных В начале 90-х годов XX века начались активные попытки по внедрению объектно-ориентированных технологий в отрасль проектирования и разработки баз данных. Бытовала точка зрения о том, что соответствующие технологии быстро вытеснят все остальные, так же как и во многих других программистских отраслях, но ничего подобного не произошло. Объектно-ориентированное программирование Рассмотрим термин «объектно-ориентированное программирование». Заметим, что это термин, принятый преимущественно в российской литературе. В западной литературе [2] под этим понимается сразу три аспекта:
Объектно-ориентированный анализ – это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.
Объектно-ориентированное проектирование – это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.
Объектно-ориентированное программирование – это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. Здесь и далее по тексту условимся не отступать от традиций и понимать под объектно-ориентированным программированием (ООП) сразу три указанных выше аспекта. Основой объектно-ориентированной технологии является так называемая объектная модель, которая возникает как результат объектно-ориентированной декомпозиции. Она выделяет основные абстракции предметной области, определяет классы абстракций и выясняет, какими данными (атрибутами) описывается каждая абстракция, какую функциональность эти абстракции должны обеспечивать. В отличие от традиционных технологий программирования объектно-ориентированная технология представляет программу как совокупность классов и объектов, взаимодействующих друг с другом. Объект – конкретная материализация абстракции; сущность с хорошо определенными границами, в которой инкапсулированы состояние и поведение. Объект ООП – инкапсулированная структура, имеющая атрибуты и методы. Термин «инкапсулированная структура» означает, что объект является самодостаточным, программы, внешние по отношению к объекту, ничего «не знают» о его структуре и такое «знание» им не требуется. «Внешний» вид объекта называется его интерфейсом. В таком понимании объект – это черный ящик, нам неизвестно, чтó у него внутри, мы лишь можем вызвать его методы и только через них взаимодействовать с ним. Кроме этого, объекты могут принадлежать иерархии «от общего к частному», которая реализуется путем наследования. Инкапсулированные состояния объекта могут быть как простыми типами данных, так и другими объектами, или даже массивами объектов. Каждый объект содержит определенную совокупность методов, классы взаимодействуют друг с другом посредством механизма сообщений. Объекты идентифицируются с помощью специальных указателей – дескрипторов. Методы объектов ООП представляют собой последовательности инструкций, выполняемых объектом. Например, у объекта может быть метод, отображающий данный объект, создающий данный объект и изменяющий его. Предметная область моделируется как множество классов взаимодействующих объектов. Объект характеризуется набором свойств, которые являются как бы его пассивными характеристиками, и набором методов работы с этим объектом. Работать с объектом можно только с использованием его методов. Атрибуты объекта могут принимать множество допустимых значений, набор конкретных значений атрибутов определяет состояние объекта. Используя методы работы с объектом можно изменять значение его атрибутов и тем самым как бы изменить состояние самого объекта. Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута. К числу основных идей объектно-ориентированной технологии, как правило, относят [1]: абстрагирование, инкапсуляцию, модульность, иерархичность, типизацию, полиморфизм, наследование. Инкапсуляция ограничивает область видимости имени атрибута пределами того объекта, в котором оно определено. Смысл этого атрибута будет определяться тем объектом, в котором оно инкапсулировано. Полиморфизм – способность одного и того же программного кода работать с разнообразными данными. Другими словами, он допускает возможность в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Наследование. Допускается порождение нового класса на основе уже существующего класса, и этот процесс называется наследованием. В этом случае новый класс, называемый подклассом существующего класса, наследует все атрибуты и методы класса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различают случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного класса, во втором случае – на основе нескольких классов. Набор классов образует иерархическую структуру. Объектно-ориентированные базы данных К настоящему моменту терминология еще не устоялась, существует много разных определений и трактовок. Представляется, что объектно-ориентированная база данных (ООБД) – база данных, основанная на принципах объектно-ориентированной технологии. К основным описательным моментам, связанным с ООБД, в литературе [2] относят:
Схема представления объекта приводится на рис. 14.1  Рис. 14.1. Схема представления объекта Система управления объектно-ориентированной базой данных называется объектно-ориентированной СУБД (ООСУБД). Цель ООСУБД – обеспечение постоянного хранения объектов, причем в отличие от традиционной СУБД ООСУБД должна хранить в составе объекта данные и программы. Поскольку каждый объект данного класса имеет один и тот же набор методов, методы сохраняются только один раз – как методы класса (данные каждого экземпляра объекта хранятся отдельно). Схема представления класса объектов приводится на рис. 14.2  Рис. 14.2. Схема представления класса объектов Используя наследование, всем объектам ПОДРАЗДЕЛЕНИЕ можно приписать свойство объекта-родителя (ФАКУЛЬТЕТ) – название факультета, номер факультета. Схема представления объектов ФАКУЛЬТЕТ и ПОДРАЗДЕЛЕНИЕ приводится на рис.14.3.  Рис. 14.3. Фрагменты представления конкретных объектов Сравнивая объектно-ориентированный и реляционный подходы к БД, можно отметить следующие особенности. В реляционных БД (РБД) реальные объекты представляются как структуры, состоящие из набора элементарных типов данных. Такое представление имеет понятную интерпретацию – строка в плоской таблице. В том случае, когда специфика предметной области позволяет работать с такого рода приближением реальных объектов, РБД отлично справляются со своей задачей. Довольно часто реляционная модель и ее способ описания предметной области в виде набора плоских таблиц не отражают внутренней структуры для многих предметных областей, являются искусственными и становятся совершенно непонятными при увеличении количества таблиц. Основная причина несостоятельности реляционного подхода заключается в слишком сильной абстракции реального объекта, что ведет к потере семантики. В отличие от реляционных баз данных объектно-ориентированные базы данных обладают простой и естественной связью с предметной областью, представляя ее структуру и состав, что облегчает проектирование и положительно сказывается на понимании принципов функционирования программ. Так, в сложных неоднородных предметных областях использование ООБД (в частности, там, где разные объекты имеют разные методы) должно действительно упростить процесс проектирования и разработки. К сожалению, в ООБД существуют свои проблемы. В ООБД отсутствует универсальная модель данных, и соответственно, отсутствует мощная математическая база, как, например, в реляционной модели. В связи с этим у ООБД нет языка запросов высокого уровня, аналогичного SQL, и при доступе к данным используется мало эффективный навигационный подход. ООСУБД отличаются от реляционных СУБД тем, что программный интерфейс создания приложения либо очень слаб, либо вообще отсутствует. Это означает, для написании приложения, работающего с ООБД не существует мастеров и конструкторов (не считая, например, конструктора создания списка полей в объекте, который поставляется вместе с ООСУБД ObjectStore). Поэтому разработчик создает приложения на одном из алгоритмических языков. По нашему мнению, существенным ограничением развития объектно-ориентированного подхода к созданию баз данных является то, что методы объекта содержатся внутри объекта и неразрывно связаны с ним. Это делает, по сути, невозможным создание для объектно-ориентированной базы данных соответствующей системы управления базой данных в традиционном понимании СУБД, функциями которой, в частности, является реализация операций обработки данных. Поэтому ООСУБД часто является не системой управления базами данных, а библиотекой программ, с помощью которой можно построить объектно-ориентированную базу данных. Примером такой библиотеки является ООСУБД ObjectStore. В связи с этим, возникает проблема реализации непредвиденных запросов. Для перехода к объектно-ориентированным БД стандарт объектного программирования был дополнен стандартизованными средствами доступа к базам данных (стандарт ODMG 93; Object Database Management Group – группа управления объектно-ориентированными базами данных). К настоящему времени этот стандарт не реализован. Состояние проблемы подробно описано также в работах [2-6 и др.]. Отметим только, что ООБД используются, но пока не стали реальной альтернативой реляционным базам данных. Объектно-ориентированные возможности появляются в ведущих современных СУБД, таких, как, например, Oracle. Предпринимаются попытки внесения изменений в стандарты языка SQL с целью его частичной адаптации к ООБД. Так, новый стандарт SQL-3 включает большой раздел, посвященный этому вопросу. |