Объектно-ориентированные субд. Объектно-ориентированные субд (оосубд)

Связь между записью-владельцем и записью-членом также имеет вид 1:N.

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

деревья (a) и (b), показанные на рис. 4.2 , заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения;
для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для связи записей КОНТРАКТ и СОТРУДНИК, (см. рис. 4.3). Отметим, что в этой записи может храниться и полезная информация, например, доля данного сотрудника в общем вознаграждении по данному контракту.

Рис. 4.3.

Каждый экземпляр группового отношения характеризуется следующими признаками:

Способ упорядочения подчиненных записей:

произвольный,
хронологический /очередь/,
обратный хронологический /стек/,
сортированный.

Если запись объявлена подчиненной в нескольких групповых отношениях, то в каждом из них может быть назначен свой способ упорядочивания.

Режим включения подчиненных записей:

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

Режим исключения.

Принято выделять три класса членства подчиненных записей в групповых отношениях:

Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи -владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предполагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗЧИК", поскольку контракт не может существовать без заказчика.
Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены.
Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных не прикрепляя к другому владельцу. При удалении записи -владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Примером такого группового отношения может служить "ВЫПОЛНЯЕТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками.

Операции над данными в сетевой модели БД

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

Ограничения целостности

Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).

Достоинства и недостатки ранних СУБД

Достоинства ранних СУБД:

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

Недостатки ранних СУБД:

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

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

Объектно-ориентированные СУБД

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

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

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

Структура

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

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

Целостность данных

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

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

Средства манипулирования данными

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

Подведем теперь некоторые итоги

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

В то же время, ОО - модели присущ и ряд недостатков :

отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста;
вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES ) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).

Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 80-х гг. Однако наиболее активно это направление развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных коммерческих и экспериментальных систем.

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

Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.

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

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

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

В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях:

· объекта и идентификатора объекта;

· атрибутов и методов;

· классов;

· иерархии и наследования классов.

Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния объекта.

Каждый объект имеет состояние и поведение. Состояние объекта – набор значений его атрибутов. Поведение объекта – набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта – это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов осуществляется на основе передачи сообщений и выполнении соответствующих методов.

Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.

Допускается порождение нового класса на основе уже существующего класса – наследование. В этом случае новый класс, называемый подклассом существующего класса (суперкласса), наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различаются случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, во втором случае суперклассов может быть несколько. Если в языке или системе поддерживается единичное наследование классов, набор классов образует древовидную иерархию. При поддержании множественного наследования классы связаны в ориентированный граф с корнем, называемый решеткой классов. Объект подкласса считается принадлежащим любому суперклассу этого класса.

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

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

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

1. Язык SQL – функции запросов и основные возможности

Развитие языка SQL

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

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

Появление теории реляционных баз данных и предложенного Коддом Э.Ф. языка запросов “alpha”, основанного на реляционном исчислении, инициировало разработку ряда языков запросов, которые можно отнести к двум классам:

1. Алгебраические языки запросов – языки, позволяющие выражать запросы средствами специализированных операторов, применяемых к отношениям (JOIN – соединить, INTERSECT – пересечь, SUBTRACT – вычесть и т.д.).

2. Языки исчисления предикатов – набор правил для записи выражения, определяющего новое отношение из заданной совокупности существующих отношений.

Разработка, в основном, шла в отделениях фирмы IBM (языки ISBL, SQL – Structured Query Language – структурированный язык запросов, QBE – Query-By-Example – запрос по образцу) и университетах США (PIQUE, QUEL). Последний создавался для СУБД INGRES (Interactive Graphics and Retrieval System), которая была разработана в начале 1970-х годов в университете шт. Калифорния и сегодня входит в пятерку лучших профессиональных СУБД. Из всех этих языков полностью сохранились и развиваются QBE и SQL (которые и будут рассматриваться в данной юните), а из остальных взяты в расширение внутренних языков СУБД только наиболее интересные конструкции. В начале 1980-х годов SQL “победил” другие языки запросов и стал фактическим стандартом таких языков для профессиональных реляционных СУБД. В 1986 году он стал международным стандартом языка баз данных и начал внедряться во все распространенные СУБД персональных компьютеров.

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

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

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

Для исключения указанных и некоторых других недостатков была предложена технология “клиент-сервер” – технология обработки данных в сетях ЭВМ, по которой запросы пользовательских ЭВМ (клиент) обрабатываются на специальных серверах баз данных (сервер), а на ЭВМ-клиент возвращаются лишь результаты обработки запроса. При этом, естественно, нужен единый язык общения с сервером и в качестве такого языка выбран SQL. Поэтому все современные версии профессиональных реляционных СУБД (DB2, Oracle, Ingres, Informix, Sybase, Progress, Rdb) и даже нереляционных СУБД (например, Adabas) используют технологию “Клиент-Сервер” и язык SQL. К тому же приходят разработчики СУБД персональных ЭВМ, многие из которых уже сегодня снабжены языком SQL.

Стандартизация SQL

Статус de facto SQL как стандартного языка реляционной базы данных был зафиксирован с принятием его в 1986 г. в качестве стандарта Американского Национального Института стандартов (ANSI). Другими стандартами для SQL являются SQL Access Group SAG – группа стандартов, поддерживаемая более чем 40 крупными государственными и коммерческими пользователями, ISO (Национальная Организация Стандартов), X/Open (группа стандартов для UNIX), собственно SQL, утвержденный IBM System Application Architecture и даже федеральным правительством США.

К моменту принятия последней спецификации ISO SQL-92 она поддерживалась не всеми коммерческими продуктами (ISO SQL-92 и ANSI SQL-92 являются аналогичными стандартами). Вследствие этого в настоящее время наиболее полно реализованным стандартом является спецификация ANSI SQL-89.

Стандарт ANSI SQL-89 поддерживает три формы SQL: модульный язык (позволяет создавать процедуры, которые затем могут вызываться из традиционных языков программирования), встроенный SQL (статический SQL – предложения которого физически встраиваются в исходный код программы) и непосредственный вызов (запросы выполняются интерактивно). Можно говорить о двойном назначении SQL – использованного языка SQL как интерактивного (для выполнения запросов) и как встроенного (для построения прикладных программ).

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

И в интерактивной и во встроенной формах SQL имеются многочисленные части, или субподразделения. К сожалению, эти термины не используются повсеместно во всех реализациях. Они подчеркиваются ANSI и полезны на концептуальном уровне, но большинство SQL программ практически не обрабатывают их отдельно, так что они, по существу, становятся функциональными категориями команд SQL. DDL (Data Definition Language – язык определения данных) – так называемый язык описания схемы в стандарте ANSI, состоит из команд, которые создают объекты (таблицы, индексы, просмотры и т.д.) в базе данных. DML (Data Manipulation Language – язык манипулирования данными) – это набор команд, которые определяют, какие значения представлены в таблицах в любой момент времени. DCL (Data Control Language – язык управления данными) – комплекс средств, которые определяют, разрешить ли пользователю выполнять определенные действия или нет.

Реализация в SQL концепции операций, ориентированных на табличное представление данных, позволило создать компактный язык с небольшим (менее 30) набором предложений. Как в интерактивном, так и в встроенном SQL существуют следующие предложения:

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

3) предложения модификации данных (добавление, удаление и изменение данных);

4) предложения управления данными (предоставление и отмена привилегий на доступ к данным, управление транзакциями и другие).

Кроме того, SQL предоставляет возможность выполнять в этих предложениях следующее:

a) арифметические вычисления (включая разнообразные функциональные преобразования), обработку текстовых строк и выполнение операций сравнения значений арифметических выражений и текстов;

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

c) создание представлений (виртуальных таблиц), позволяющих пользователям иметь свой взгляд на данные без увеличения их объема в базе данных;

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

e) агрегатирование данных: группирование данных и применение к этим группам таких операций, как среднее, сумма, максимум, минимум, число элементов и т.п.

Типы данных

Основные типы данных SQL – используемые языком SQL основные типы данных, форматы которых могут несколько различаться для разных СУБД: целое число; десятичное число; вещественное число; символьная строка фиксированной или переменной длины; дата в формате (по умолчанию mm/dd/yy); время в формате (по умолчанию hh.mm.ss); деньги в формате, определяющем символ денежной единицы и его расположение (суффикс или префикс) и др.

Рассмотрим основные типы данных SQL:

INTEGER – целое число (обычно до 10 значащих цифр и знак);

SMALLINT – “короткое целое” (обычно до 5 значащих цифр и знак);

DECIMAL(p,q) – десятичное число, имеющее p цифр (0 < p < 16) и знак; с помощью q задается число цифр справа от десятичной точки (q < p, если q = 0, оно может быть опущено);

FLOAT – вещественное число с 15 значащими цифрами и целочисленным порядком, определяемым типом СУБД;

CHAR(n) – символьная строка фиксированной длины из n символов (0 < n < 256);

VARCHAR(n) – символьная строка переменной длины, не превышающей n символов (n > 0 и разное в разных СУБД, но не больше 4096);

DATE – дата в формате, определяемом специальной командой (по умолчанию mm/dd/yy); поля даты могут содержать только реальные даты, начинающиеся за несколько тысячелетий до нашей эры и ограниченные V–X тысячелетием нашей эры;

TIME – время в формате, определяемом специальной командой (по умолчанию hh.mm.ss);

DATETIME – комбинация даты и времени;

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

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

4. 1.4. Средства определения схемы

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

С точки зрения пользователя базу данных можно представить следующим образом (рис 1).

Рис. 1. База данных в восприятии пользователя

При этом следует различать базовые и виртуальные таблицы. Базовая таблица – таблица реляционной БД, для каждой строки которой в действительности имеется некоторый двойник, хранящийся в физической памяти ЭВМ, и которая создается с помощью предложения CREATE TABLE (создать таблицу). Виртуальная таблица (представление) – таблица, которая не существует в базе данных, но как бы существует с точки зрения пользователя и в которой формируются результаты запросов на получение данных из базовых таблиц.

Таблицы создаются командой CREATE TABLE. Эта команда создает структуру таблицы. Значения вводятся с помощью DML команды INSERT (см. далее). Команда CREATE TABLE в основном определяет имя таблицы в виде описания набора имен столбцов, указанных в определенном порядке. Она также определяет типы данных и размеры столбцов. Каждая таблица должна иметь, по крайней мере, один столбец.

При записи синтаксических конструкций используются следующие обозначения:

– звездочка (*) для обозначения “все” – употребляется в обычном для программирования смысле, т.е. “все случаи, удовлетворяющие определению”;

– квадратные скобки () – означают, что конструкции, заключенные в эти скобки, являются необязательными (т.е. могут быть опущены);

– многоточие (...) – указывает на то, что непосредственно предшествующая ему синтаксическая единица факультативно может повторяться один или более раз;

– прямая черта (|) – означает наличие выбора из двух или более возможностей. Например обозначение элемент 1 |элемент 2 указывает, можно выбрать один из элементов элемент 1 или элемент 2 ; когда же один из элементов выбора заключен в квадратные скобки, то это означает, что он выбирается по умолчанию (так, [элемент 1 ]| элемент 2 означает, что отсутствие всей этой конструкции будет восприниматься как выбор элемент1 );

– точка с запятой (;) – завершающий элемент предложений SQL;

– запятая (,) – используется для разделения элементов списков;

– пробелы () – могут вводиться для повышения наглядности между любыми синтаксическими конструкциями предложений SQL;

– термины таблица, столбец , ... – заменяют (с целью сокращения текста синтаксических конструкций) термины имя_таблицы, имя_столбца , ..., соответственно.

Согласно этим правилам синтаксис команды CREATE TABLE будет следующим:

CREATE TABLE базовая_таблица (столбец тип_данных

[,столбец тип_данных] ...);

Таблицы принадлежат пользователю, который их создал, и имена всех таблиц, принадлежащих данному пользователю, должны отличаться друга от друга, как и имена всех столбцов внутри данной таблицы. Отдельные таблицы могут использовать одинаковые имена столбцов, даже если они принадлежат одному и тому же пользователю. Ссылаться к этим таблицам можно с помощью имени владельца этих таблиц, сопровождаемого точкой. Например, таблица Employees, созданная Smith, будет называться Smith.Employees, когда она упоминается каким-то другим пользователем. Порядок столбцов в таблице определяется порядком, в котором они указаны.

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

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

Предположим, что таблица заказчиков имеет тысячи входов, а требуется найти заказчика с номером=2999. Так как строки не упорядочены, программа будет просматривать всю таблицу, строку за строкой, проверяя каждый раз значение поля номера на равенство значению 2999. Однако, если бы имелся индекс в столбце “номер”, то программа могла бы выйти на номер 2999 прямо по индексу. В то время как индекс значительно улучшает эффективность запросов, использование индекса несколько замедляет операции модификации DML (такие, как INSERT и DELETE), что связано с затратами времени на создание или удаление индекса, а сам индекс занимает объем памяти. Следовательно, каждый раз, когда создается таблица, необходимо принимать решение, индексировать ее или нет. Индексы могут состоять из многочисленных полей. Если больше чем одно поле указывается для одного индекса, второе упорядочивается внутри первого, третье внутри второго и т.д.

Предложение для создания индекса обычно следующее (следует заметить, что стандарт ANSI не поддерживает индексы, хотя они очень полезны и широко применяемы):

CREATE INDEX ON (имя_столбца[,] ...);

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

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

Представление создается командой CREATE VIEW. Она состоит из слов CREATE VIEW (создать представление), имени представления, которое нужно создать, слова AS (как) и, далее, запроса.

Синтаксис предложения CREATE VIEW имеет вид:

CREATE VIEW имя_представления

[(столбец[,столбец] ...)]

AS подзапрос;

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

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

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

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

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

Похожая информация.

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

Характеристики ООСУБД подразделяются на триопределяющие группы:

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

- по выбору, позволяющие улучшать ООСУБД, но не являющиесябазовыми,

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

В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД в ее классическом понимании и быть объектно-ориентированной системой (ООС), т.е. в определенной степени она должна быть совместимой с современными объектно-ориентированными ЯВУ.Первый критерий включает следующие пять характеристик, присущих классической СУБД: сохранность и реентерабельность данных, развитое управление внешней памятью, возможность совмещения обработки и поиска данных, поддержка средств восстановления и возможность быстрого доступа к БД по запросу пользователя. Отмеченные характеристики в той или иной мере обсуждались выше.Второй критерий предполагает наличие следующихвосьми характеристик, присущих собственно объектно-ориентированной технологии: понятие сложных объектов, идентичность объектов, инкапсуляция, типы или классы, наследование, настройка (сочетающаяся с отложенным присвоением), расширяемость и вычислительная полнота. Характеристики первого критерия хорошо известны пользователям традиционных СУБД (INGRES , dBase , R:Base, IMS , Reflex и др.), поэтому кратко остановимся на характеристикахвторого критерия, соотнося их с уже рассмотренными вопросами ООП-технологии.

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

Объектные конструкторы должны удовлетворятьпринципу ортогональности: любой конструктор может применяться к любому объекту. Например, конструкторы РБД не обладают данным свойством (так конструктор множества может применяться только к кортежам, а конструктор кортежей - только к первичным типам). Наряду с этим для обеспечения работы со сложными объектами требуются также соответствующиеоператоры, которые оперируют с объектом как с единым целым. Таким образом,операции над сложным объектом должны распространяться транзитивно и на все его составляющие компоненты.

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

(1) два объектаидентичны (одинаковы) или (2)равны (имеют одно и то же значение). Эти понятия влекут за собой соответственно две импликации: разделение объектов и ихобновление. Разделение предполагает возможность разделения двумя объектами некоторой ихобщей компоненты, тогда как в случае обновления объектов общие компоненты двух объектов обновляютсянезависимо при обновлении любого из них.Идентичность объектов является мощной первичной операцией над данными, которая может быть положена в основу операций над множеством, кортежем сложных объектов, а также над рекурсивными сложными объектами.

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

3. Понятиеинкапсуляции связано с необходимостью как прояснить различие между спецификацией и реализацией операции, так и с применением модульного принципа организации ПС. Наинкапсуляцию существует две точки зрения: (1) со стороны ЯВУ (именно здесь зародилось это понятие) и (2) адаптированная со стороны СУБД точка зрения. Впервом случае понятие инкапсуляции восходит к абстрактным типам данных, когдаобъект имеет интерфейсную и обрабатывающую части. Интерфейсная часть специфицирует множество операций, которые могут быть выполнены над объектом. Тогда как обрабатывающая часть, в свою очередь, состоит из данных и процедур: данные определяют состояние или представление объекта, а процедуры на некотором ЯВУ (например Turbo - Pascal , C++, SmallTalk и др.) описывают применение к объекту каждой допустимой для него операции.

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

4. В ООС существуют две основные категории, поддерживающие соответственно понятиекласса и типа. К первой категории можно отнести SmallTalk - подобные системы (SmallTalk , Vision , GemStone и др.) и все созданные на основе Zi"sp-языка системы (Flavors , G - Base , Orion , Lore и др.). Тогда как ко второй категории можно отнести такие системы, как: C++, Trellis , VBase , Simula и др. Понятиетипа в ООС суммирует общие черты множества объектов с одинаковыми характеристиками. Оно соответствует понятию типа абстрактных данных. Тип состоит из двух частей: интерфейсной и обрабатывающей. Для пользователя видна толькоинтерфейсная часть, содержащая список допустимых для данного типа операций с их сигнатурой (типы входных параметров и результата). Тогда какобрабатывающая часть скрыта от пользователя и состоит, в свою очередь, также из двух частей: данных и процедур. Частьданных описывает собственно внутреннюю структуру данных объекта и в зависимости от возможностей ООС данная часть может быть более или менее сложной.Процедуры поддерживают выполнение операций из интерфейсной части объекта.

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

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

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

6. В целом ряде случаев необходимо располагать однимименем, используемым для различныхреализации одной и той же операции. Например, используется операция GS(X), которая в зависимости от типа Х -объекта обеспечиваетразличные алгоритмы обработки. Естественно, что в момент компиляции программы тип Х -объекта неизвестен. Поэтому в традиционной технологии программист в своей программе обеспечивает проверку на тип Х -объекта (переменной) и в зависимости от ее результата осуществляет ветвление вычислительного алгоритма. В условиях ООСУБД такая операция GS(X) определяется на уровнеобъектного (наиболее общего в системе) типа; однако реализация операции переопределяется (настраивается) для каждого из типов обрабатываемых Х -объектов. В этом случае, применяя операцию GS(X), мы предоставляем возможность самой системе динамически отыскивать (настраивать) подходящую реализацию операции согласно типа Х -объекта. Для обеспечения этой новой черты ООС не может связывать имена операций с программами их реализации в период компиляции. Следовательно, присваивание имен реализациям должно осуществляться динамически, т.е. поддерживается принципотложенного присвоения имен операционным программам. Следует отметить, что несмотря на то, что отложенное присвоение существенно усложняет проверкутипов (а в ряде случаев делает ее просто невозможной), полностью оно такую проверку не исключает.

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

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

8. Согласно устоявшимся на сегодня понятиям каждая СУБД, наследующая рассмотренные выше черты и характеристики, относится к классу ООСУБД. Однако наряду с определяющими ООСУБД могут обладать и дополнительными (по выбору) характеристиками, позволяющими в том или ином отношении улучшать систему. Некоторые из них имеют объектно-ориентированную природу (например множественное наследование), другие - черты сугубо традиционных СУБД (например реализацию транзакций). Первые из них преследуют цель повышения уровня объектно-ориентированности системы, не являясь для неебазовыми. Вторые, как правило, преследуют цели улучшения функциональных и эксплуатационных характеристик системы с точки зрения классических СУБД и пользователя без акцента на ее объектно-ориентированном аспекте. Большинство таких характеристик преследуют цели улучшения обслуживания для новых приложений ООСУБД (CAD/CAM, CAP, CASE, управление, финансы, делопроизводство и др.) и носят скорее прикладную, чем технологическую направленность. Так как многие современные ООСУБД ориентированы именно на эти новые приложения, то возникает ряд противоречий между их дополнительными чертами прикладной ориентации и объектно-ориентированной природой самих систем.

9. Современные ООСУБД, представляющие собой четвертое поколение в технологии управления данными, в коммерчески пригодном исполнении появились относительно недавно. Они поддерживают все рассмотренные выше черты и характеристики как традиционных СУБД, так и объектно-ориентированной технологии (ООТ). В плане выразительных возможностей прикладной семантики ООСУБД существенно мощнее традиционных реляционных СУБД. Превосходный сравнительный анализ реляционных СУБД и ООСУБД можно найти в . Первыми разработчиками ООСУБД в 1990 г. явились фирмы Object Design, OBJECT-Sciences, Objectivity, OntoLogic и Servio (США). Наряду с ними ряд разработчиков классических реляционных СУБД расширили свои системы объектно-ориентированными средствами. Среди наиболее удачных разработок можно отметить, в первую очередь, ООСУБД VERSANT фирмы Versant Object Technology , которая поддерживает ряд широко используемых стандартов, а также концепцию ООСУБД, рассмотренную выше. В качестве примера кратко рассмотрим вопросы VERSANT-технологии управления данными, базирующейся на ООСУБД VERSANT, на сегодня являющейся одним из стандартов дефакто для такого типа ООС.

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

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

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

Второй уровень содержит единственную компоненту VERSANT Star системы, осуществляющую интеграцию различных СУБД. Она управляет доступом кобъектам, находящимся в системе БД первого уровня архитектуры. С этой целью она использует набор БД-драйверов, поддерживающих индивидуальные БД-форматы. По этой причине в настоящее время поддерживаютсятолько наиболее популярные СУБД (ORACLE , DB /2, IMS и др.), но данный список постоянно расширяется. Этому способствует и переход к новому единому ASCII-стандарту для реляционных СУБД.

В отличие от некоторых ООСУБД система VERSANT не использует единого языка программирования и не требует от пользователя использования какого-либо конкретного компилятора или транслятора. Она позволяет для работы со своими БД использовать многие как традиционные, так и объектно-ориентированные ЯВУ(третий уровень; смотри рисунок 5.6). Достигается это посредством введения языковых интерфейсов в виде библиотек классов и функций. Посредством использования данных библиотек в своих прикладных программах пользователь получает доступ ко всем ресурсам VERSANT-системы на широком спектре различных ЯВУ. В настоящее время поддерживаются пять базовых языков: Pascal , С, C++, SmallTalk и Object SQL . Последний является расширением SQL-стан-дарта, позволяющим управлять структурами объектно-ориентированных данных. В свою очередь, С-интерфейс может быть использован любым языком программирования, допускающим вызовы внешних С -функций (Pascal , Fortran , Cohol и др.). Это позволяет пользователю писать свои прикладные программы на подходящем ЯВУ, обеспечивая доступ к любой БД, интегрированной в VERSANT -систему. Следующие три уровня архитектуры определяют (ЗхЗ)-матрицу средств, предназначенных для облегчения разработки прикладных программ и администрирования интегрированной ООСУБД VERSANT-системы.

Четвертый уровень содержит средства, расширяющие возможности прикладных программ, написанных на ЯВУ уровня 3 и совместимых с ними. Компонента этого уровня Object Modeler является наиболее многоцелевым средством, позволяющим средствами графического интерфейса на экране определять объектно-атрибутные структуры данных. Затем эти структуры данных могут автоматически транслироваться в С -структуры, {С+ SmallTalk } -классы или SQL-таблицы, позволяя существенно сокращать время разработки прикладных программ.

Средство Object Modeler оказывает неоценимую помощь в деле повышения продуктивности пользователя, так как позволяет только один раз определять структуры данных, а затем повторно использовать их во многих различных приложениях безотносительноязыка, на котором они были запрограммированы, или БД, к которым организуется доступ. Вторым важным преимуществом данного средства является то, что оно может непосредственно использоваться системотехниками, воспитанными на традиционной технологии, а не на ООТ. Два других средства уровня 4 обеспечивают поддержку языка запросов SQL-стандарта. Так, на базе средства SQL Gateway (шлюза) пользователь в своих программах на языках C++ и/или SmallTalk может организовывать запросы в SQL-стандарте и автоматически получать результаты запросов в соответствующие объекты программы. Средство же Embedded SQL позволяет использовать предложения языка Object SQL для расширенного доступа к объектно-ориентированным структурам данных.

Пятый уровеньархитектуры (смотри рисунок 5.6) включает средства для администратора БД, предназначенные для настройки и управления распределенными БД. Данные средства пригодны также и для прикладных программистов, но только первое из них обычно ими используется. Средство Designer представляет собой графический инструмент для программистов и администратора БД, позволяющий в рамках VERSANT-баз создавать и управлять иерархиями классов. Средство автоматически генерирует определения классов для языка C++ из их графического представления. Более того. Designer может просматривать БД, позволяя пользователю или администратору проверять (просматривать) определения классов в БД, включая их атрибуты, отношения и методы. С его помощью можно проверять, изменять или удалять (т.е.редактировать} отдельные элементы в БД. Средство Repository Builder позволяет администратору БД определять и обслуживать метаданные из архива данных системы. По функционированию данное средство несколько напоминает предыдущее, но включает ряд специальных возможностей для обеспечения доступа именно к информации архива системы. Наконец,Administrator представляет собой набор средств администратора БД, поддерживающих: командный (оперативный) режим управления пользователями и доступом к БД, операции восстановления, а также выполнять другие стандартные сервисные функции по обслуживанию ООСУБД VERSANT-системы.

Шестой уровень включает средства, предназначенные для быстрой генерации мощных объектно-ориентированных прикладных программ на основе библиотек классов, поддерживаемых системой. Графическое Screen -средство ориентировано на разработку необходимыхграфических интерфейсов для приложений. Наряду с этимScreen имеет развитые средства для управленияшироким набором носителей информации Например, можно вводить диаграммы, производить поиск в БД фотографий, карт или осуществлять другие процедуры (не поддерживаемые традиционными пакетами) по работе с форматированной информацией. Средство Report предназначено для подготовки отчетов и при необходимости может выполнять роль традиционногогенератора отчетов. Наконец, Object 4 GL представляет собой ЯВУ программирования БД, который может быть использован для состыковки операций и объектов, созданных другими средствами системы. Следует отметить, что графические интерфейсы, отчеты и процедуры, созданные средствами шестого уровня, сохраняются в архиве системы (Repository ) и становятся доступными для всех приложений в среде VERSANT-системы. Более того, по причине определения этих прикладных конструкций в терминах абстрактных категорий и атрибутов, они могут использоваться и с другими типами СУБД.

Седьмой уровень архитектуры (смотри рисунок 5.6) представляютспециализированные приложения (библиотеки классов), специально адаптированные к нуждам той или иной области приложений VERSANT-системы (проектирование, конструирование, производство, строительство, сетевое моделирование и др.). Средства данного уровня стали возможными благодаря принципу многократного использования, поддерживаемому ООТ.

Наконец, навосьмом уровнеархитектуры представлены фактические (конечные) приложения VERSANT-технологии. Используя средства седьмого уровня или создавая свои собственные, пользователь завершает создание конкретного функционально полного приложения VERSANT-системы. На рисунке 5.6 условно показано, какнекоторый интегрированный пакет для проектирования в области разработки и производства интегральных схем (CIM Applications ) может быть перенастроен на основе средств седьмого уровня (Engineering , Manufacturing , Finance ), используя их функциональные возможности, чтобы быстро связывать изменения проектных решений с производственными затратами и оценивать их влияние на себестоимость конечного изделия. Практическое использование VERSANT-технологии позволяет говорить о ее большихпотенциях для разработчиков АСУП и АСУТП всех уровней.

Первоначально средства VERSANT-технологии были разработаны и эксплуатировались на платформах Sun 3/4, мини-ЭВМ IBM RISC System /6000, DEC -станциях, HP 9000/400, системах Silicon Graphics , InterGraph 6000 и последующих сериях мультипроцессорных ЭВМ. В настоящее время указанные ООС функционируют также на платформах Unix , Windows , OS/2 и Macintosh . Эти реализации делают VERSANT-технологию доступной для широкого круга пользователей IBM-совместимых ПК и существенно расширяют ее возможности для обеспечения распределенной обработки информации в условиях функционирования различного назначения ИИС.

Лекция 7 (2 часа)

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

Структура :

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

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

наследование - подразумевает возможность создавать из классов объектов новые классы объекты, которые наследуют структуру и методы своих предков, добавляя к ним черты, отражающие их собственную индивидуальность. Наследование может быть простым (один предок) и множественным (несколько предков);

полиморфизм - различные объекты могут по разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы.

Целостность данных:

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

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

Средства манипулирования данными:

Подведем теперь некоторые итоги:

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

В то же время, ОО-модели присущ и ряд недостатков:

· осутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста;

· вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Объектно-ориентированные базы данных – базы данных, в которых информация представлена в виде объектов, как в объектно-ориентированных языках программирования.

Применять или не применять объектно-ориентированные системы управления базами данных (ООСУБД) в реальных проектах сегодня? В каких случаях их применять, а в каких нет?

Вот преимущества использования ООСУБД:

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

Интересно? Тогда стоит попробовать!

В статье описано все, что требуется для начала работы с ООСУБД db4o .

Установка db4o

На сегодняшний день db4o – одна из самых популярных объектно-ориентированных систем управления базами данных.

Для начала скачиваем дистрибутив последней версии с сайта db4o (есть версии для Java, .NET 2.0, 3.5). На момент написания статьи последняя версия – 7.9. В дистрибутив также входит Object Manager Enterprise (OME) – полезный плагин для IDE (Eclipse, Visual Studio), который позволяет работать с базой данных автономно. В последнюю продуктивную поставку (на данный момент - 7.4) OME не входит, поэтому для ознакомления c ООСУБД рекомендуется версия 7.9.

После установки db4o в соответствующем месте можно найти отличный tutorial, входящий в комплект. Именно к нему я рекомендую обратиться после прочтения данной статьи, если сама тема покажется вам интересной.

Отмечаю, что все ПО для работы с db4o и сама СУБД бесплатны для некоммерческого использования.

Cоединение с БД

Для проведения экспериментов над db4o создаем в нашей IDE проект любого типа, например, консольное приложение и добавляем ссылки на сборки (пакеты) db4o: Db4objects.Db4o.dll и Db4objects.Db4o.Linq.dll (если требуется).

Чтобы выполнять какие-либо действия над объектной базой в приложении, первым делом необходимо получить объект типа IObjectContainer . Это фасад к базе данных: через него выполняются запросы к БД на выборку, сохранение, добавление и удаление данных.

Способ получения объекта зависит от типа соединения с базой данных.

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

// получаем доступ к файлу БД
IObjectContainer db = Db4oFactory.OpenFile(filename);
try
{
// работаем с ООБД
}
finally
{
// закрываем файл, освобождаем ресурсы
db.Close();
}

Файл базы данных в этом случае открывается в эксклюзивном режиме и, следовательно, возникают трудности при реализации многопользовательских приложений. Однако такое решение отлично подходит для однопользовательских stand-alone приложений, которые имеют сложную модель данных и которым необходимо сохранять эти данные между запусками приложения. Пример, САПР-приложения.

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

// создаем сервер
IObjectServer server = Db4oFactory.OpenServer(filename, 0);
try
{
// подключаем клиентов
IObjectContainer client = server.OpenClient();
IObjectContainer client2 = server.OpenClient();
// работаем с ООБД через экземпляры IObjectContainer
Client.Close();
client2.Close();
}
finally
{
// закрываем файл, освобождаем ресурсы сервера
server.Close();
}
* This source code was highlighted with Source Code Highlighter .

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

Второй параметр функции OpenServer – номер порта, равный 0, означает, что сервер будет доступен только локальным клиентам, создаваемым с помощью server.OpenClient() .

Приведенный пример искусственный. В реальном приложении клиенты, скорее всего, будут открываться в отдельных потоках.

И последний вариант – расширение предыдущего для случая удаленных клиентов.

// создаем сервер
IObjectServer server = Db4oFactory.OpenServer(filename, serverPort);
server.GrantAccess(serverUser, serverPassword);
try
{
IObjectContainer client = Db4oFactory.OpenClient("localhost" , serverPort,
serverUser, serverPassword);
// работаем с ООБД
client.Close();
}
finally
{
server.Close();
}
* This source code was highlighted with Source Code Highlighter .

Этот вариант отличается от предыдущего следующим.

Указывается реальное значение порта, который будет прослушивать сервер (используется TCP/IP) при вызове OpenServer .
Указываются авторизационные данные для доступа к БД.
Клиент создается с использованием Db4oFactory.OpenClient и, таким образом, это может происходить не только в другом потоке, но и совершенно в другом приложении, запущенном на удаленной машине.

Итак, мы рассмотрели все три способа подключения к базе данных и научились получать объект типа IObjectContainer . Посмотрим теперь, как работать с данными, используя этот объект.

Работа с данными

Пусть где-то в нашем приложении объявлен класс User с полями Login , Password и Age , а db – это объект типа IObjectContainer (тот, что мы получили в прошлом разделе).

Сохранение объекта (INSERT)

User user1 = new User("Vasya", "123456", 25);
db.Store(user1);
* This source code was highlighted with Source Code Highlighter .

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

Запросы к данным (SELECT)

Существует несколько способов выполнить запрос к данным, сохраненным в базе данных.

Применение естественных запросов (Native Queries, NQ) – гибкий, мощный и удобный метод выполнения запросов над данными в ООБД.

IList result = db.Query(usr => usr.Age >= 18
&& usr.Login.StartsWith("V"));
* This source code was highlighted with Source Code Highlighter .

Здесь делается запрос к объектам класса User , причем всё, что только можно, в данном примере строго типизировано. Объекты фильтруются таким образом, чтобы удовлетворять условию: возраст пользователя больше или равен 18 и имя пользователя начинается с заглавной буквы «V». Вместо лямбда-выражения функции Query можно передавать делегаты или объекты типа Predicate . Predicate - интерфейс, содержащий единственную функцию Match , принимающую параметр типа T и возвращающую bool . Query вернет те объекты, для которых Match возвращает true .

Концепция ООБД отлично ложиться на идею использования интегрированных в язык запросов (LINQ).
Перепишем предыдущий запрос с использованием LINQ.

IEnumerable result = from User usr in db
where usr.Age >= 18 && usr.Login.StartsWith("V" )
select usr;
* This source code was highlighted with Source Code Highlighter .

Запрос опять же строго типизирован и легко поддается рефакторингу.

Существуют и другие методы выполнения запросов, кроме NQ и LINQ.

Запросы по образцу (query by example). Самый простой, но недостаточно мощный способ. Выборка данных осуществляется на основе сопоставления с заранее подготовленным экземпляром объекта - образцом. Результат-выборка не является строго типизированной. Сложно представить ситуации, когда этот метод может оказаться полезным.
SODA. Низкоуровневый язык запросов, с которым работает db4o. Запросы, использующие синтаксис SODA, не безопасны с точки зрения типов, не строго типизированы, занимают много места, но зато максимально гибки и позволяют отточить производительность приложения там, где это требуется.

Обновление объектов (UPDATE)

Перед тем как обновить объект, извлечем его из БД, затем изменим его и сохраним обратно.

User usr = db.Query(usr => usr.Login == "Vasya" );
usr.SetPassword("111111" );
db.Store(usr);
* This source code was highlighted with Source Code Highlighter .

Удаление объектов (DELETE)

Удаление объектов происходит аналогично:

User usr = db.Query(usr => usr.Login == "Vasya" );
db.Delete(usr);
* This source code was highlighted with Source Code Highlighter .

Составные объекты

До этого момента мы рассматривали, как работать с достаточно простыми объектами User , которые содержали только поля элементарных типов (string и int ). Однако объекты могут быть составными и ссылаться на другие объекты. Например, в классе User может быть объявлено поле friends (друзья пользователя):

public class User
{
// ...
IList friends = new List ();
}
* This source code was highlighted with Source Code Highlighter .

Все операции с таким классом производятся также, как и раньше – составное поле корректно сохраняется в БД, однако есть некоторые особенности.

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

// глубина активации глобально для всех классов
db.Ext().Configure().ActivationDepth(2);
// глубина активации для класса User
db.Ext().Configure().ObjectClass(typeof (User)).MinimumActivationDepth(3);
db.Ext().Configure().ObjectClass(typeof (User)).MaximumActivationDepth(4);
// каскадная активация для объектов User (нет ограничения на глубину)
db.Ext().Configure().ObjectClass(typeof (User)).CascadeOnActivate(true );
* This source code was highlighted with Source Code Highlighter .

Здесь приведены примеры, устанавливающие глубину активации как для всех сразу, так и для отдельного класса. Функция Ext() возвращает расширенный объект IExtObjectContainer для доступа к продвинутым функциям вроде настроек конфигурации базы данных. Это сделано для удобства, чтобы не засорять основной интерфейс IObjectContainer .

В случае, когда запрос уже отработал, но каких-либо данных не хватает, то есть не все нужные данные были активированы (загружены в память), можно использовать метод Activate , применительно к отдельному хранимому объекту:

// первый параметр – активируемый объект, второй – глубина активации
db.Activate(usr, 5);
* This source code was highlighted with Source Code Highlighter .

Во многом похожая проблема возникает при сохранении составных объектов. По умолчанию сохраняются только поля самого объекта, но не объектов, на которые он ссылается. То есть, глубина обновления (update depth ) по умолчанию равна 1. Изменить её можно следующим образом:

// глубина обновления глобально для всех классов
db.Ext().Configure().UpdateDepth(2);
// глубина обновления для класса User
db.Ext().Configure().ObjectClass(typeof (User)).UpdateDepth(3);
// каскадное обновление для объектов User (нет ограничений на вложенность)
db.Ext().Configure().ObjectClass(typeof (User)).CascadeOnUpdate(true );
* This source code was highlighted with Source Code Highlighter .

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

// каскадное удаление (нет ограничений на вложенность)
db.Ext().Configure().ObjectClass(typeof (User)).CascadeOnDelete(true );
* This source code was highlighted with Source Code Highlighter .

Понятия «глубины удаления» не предусмотрено.

Транзакции

Каждый раз, когда открывается контейнер (IObjectContainer ), неявным образом создается контекст транзакции. При выполнении операции Close автоматически происходит commit текущей транзакции.

Для более гибкого управления транзакциями в интерфейсе IObjectContainer присутствуют два метода:

Commit() . Явное завершение транзакции (commit) с записью всех изменений в БД.
Rollback() . Откат транзакции – изменения произошедшие с момента открытия транзакции (контейнера) не будут зафиксированы в БД.

Уровень изоляции транзакций, принятый в db4o - read committed .

Заключение

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

ООП

Java

CSharp

LINQ

Добавить метки