Объекты и концепции базы данных


Содержание

Объекты базы данных

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

Таблицы. Это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят структуру базы данных (поля, их тип и свойства).

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

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

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

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

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

Страницы. Это специальные объекты баз данных, реализованные в последней версии СУБД Microsoft Access. Правда, более корректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данных, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере.

Макросы и модули. Эти категории объектов предназначены как для автоматизации повторяющихся операций при работе с системой управления базами данных, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные функциональные возможности, удовлетворить специфические требования заказчика, повысить быстродействие системы управления, а также уровень ее защищенности.

Работа с каждым объектом БД осуществляется в отдельном окне, причем предусмотрено два режима работы:

  • 1. Оперативный режим — реализуются задачи обработки данных, т. е. просмотр, изменение, выбор информации.
  • 2. Режим конструктора — создание или изменение макета, структуры объекта (например, структуру таблицы).

Для перехода из одного режима в другой используют пункт меню Вид —» Конструктор (Таблица) или кнопки Конструктор

М ’ , Таблица] Ш * | в панели инструментов.

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

Объекты и концепции базы данных

Основные объекты базы данных в Oracle [3]

Однако как объект базы данных «Пользователь» присутствует не во всех СУБД. Например он присутствyет в Oracle, но отсутствует в IBM и DB2.

Informix

Основные объекты базы данных в Informix [4]

Access

Основные объекты базы данных в Access [5] (файл .mdb)

Microsoft SQL Server

Основные объекты базы данных в Microsoft SQL Server

Схема, как объект базы данных

Схема (SCHEMA) [3] — является одним из основных объектов базы данных Oracle. SCHEMA также появилась и в Microsoft SQL Server 2005 и формально определяется как набор объектов в базе данных [6] .

В Oracle [3] и в Microsoft SQL Server 2005 [6] она привязывается пользователю (USER) и является логическим набором объектов базы данных. Схема создается при создании пользователем первого объекта, и все последующие объекты созданные этим пользователем становятся частью этой схемы. Нескольким пользователям можно назначить одну и ту же схему по умолчанию.

В Oracle схема привязывается только к одному пользователю, тогда как в Microsoft SQL Server 2005 несколько пользователей (через группы Windows или роли баз данных) могут владеть одной и той же схемой.

Однако как объект базы данных «Пользователь» присутствует не во всех СУБД. Например он присутствует в Oracle, но отсутствует в IBM и DB2. [3]

Объекты схемы Oracle

Схема может включать другие объекты, принадлежащему этому пользователю:

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

Существуют и подобъекты схемы, такие как:

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

Объекты не зависимые от схемы

Существуют объекты не зависимые от схемы

  • каталоги,
  • профили,
  • роли,
  • сегменты,
  • табличные области
  • пользователи.

Операции с объектами

Операции с объектами в базе можно проводить с помощью функций языков Data Definition Language. В случае с SQL это функции —

Примечания

Wikimedia Foundation . 2010 .

Смотреть что такое «Объект (база данных)» в других словарях:

БАЗА ДАННЫХ — как объект правовой охраны труда представляет собойобъективную форму представления и организации совокупности данных (на пример, статей, расчетов), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ … Финансовый словарь

База данных — (англ. data base) как объект правовой охраны объективная форма представления и организации совокупности данных (напр., статей, расчетов), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ.… … Энциклопедия права

БАЗА ДАННЫХ — по законодательству РФ об авторском праве объективная форма представления и организации совокупности данных (статей, расчетов и т.д.), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ. Объект… … Юридический словарь

база данных — по законодательству РФ об авторском праве объективная форма представления и организации совокупности данных (статей, расчетов и т.д.), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ. Объект… … Большой юридический словарь

Иерархическая база данных — Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний уровень занимает один объект, второй объекты второго уровня и т. д. Между объектами существуют связи, каждый объект… … Википедия

Пространственная база данных — Пространственная база данных база данных (БД), оптимизированная для хранения и выполнения запросов к данным о пространственных объектах, представленных некоторыми абстракциями: точка, линия, полигон и др. (лишь отчасти соответствующих… … Википедия

реляционная база данных — База данных, реализованная в соответствии с реляционной моделью данных. [ГОСТ 20886 85] реляционная БД База данных, логически организованная в виде набора отношений ее компонентов. Характерной особенностью реляционной базы данных является… … Справочник технического переводчика

Реляционная база данных — база данных, построенная на основе реляционной модели. В реляционной базе каждый объект задается записью (строкой) в таблице. Реляционная база создается и затем управляется с помощью реляционной системы управления базами данных. По английски:… … Финансовый словарь

Пространственная база данных (ГИС) — Пространственная база данных база данных (БД), оптимизированная для хранения и выполнения запросов к данным о пространственных объектах, представленных некоторыми абстракциями: точка, линия, полигон и др. (лишь отчасти соответствующих базовым… … Википедия

Объект (значения) — В Викисловаре есть статья «объект» Объект (от лат. objectum предмет) то, на что направлена та или иная деятельность (или то, что создано этой деятельностью); в более широком значении любой предмет вообще. Объект нечто … Википедия

Основные объекты Баз Данных

Курсовая работа

ПО МДК 02.02.Р1. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ В СУБД ACCESS

НА ТЕМУ: «Проектирование базы данных дневное отделение колледжа»

Выполнила: студентка гр. ПО-41____________________А.Р. Каримова

Руководитель: ___И.И. Шалаева

г. Стерлитамак, 2015

Содержание

I. Теоретическая часть. 5

Основные объекты Баз Данных. 5

II. Практическая часть. 10

Постановка задачи. 10

структура базы данных. 11

Список литературы.. 25

Введение

Современные информационные технологии — это методы и средства для сбора, хранения, обработки и получения информации на основе современных средств вычислительной техники.

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

Целями проектирования базы данных являются:

1.Эффективная структуризация информации, что позволяет сэкономить время и деньги.

2.Исключение или сведение к минимуму повторяющихся данных путем задания эффективной структуры.

3.Обеспечение всем пользователям быстрого доступа к информации базы данных.

4.Обеспечение расширения базы новыми данными.

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

6.Предотвращение несанкционированного доступа к данным.

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

8.Возможность добавления или редактирования информации базы данных только определенным лицам.

9.Облегчение создания приложений, предназначенных для ввода, редактирования, вывода данных, а так же ведения отчетности.

Реализация всех вышеперечисленных задач должно возлагаться на систему управления базами данных.

Задача должна быть решена с учетом требований современных информационных технологий в среде СУБД Access

I. Теоретическая часть

Основные объекты Баз Данных

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

Компьютерная база данных — это хранилище объектов. В одной базе данных может быть более одной таблицы. Например, система отслеживания складских запасов, в которой используются три таблицы, — это не три базы данных, а одна. В базе данных Access (если ее специально не настраивали для работы с данными или кодом, принадлежащими другому источнику) все таблицы хранятся в одном файле, как и другие объекты, например формы, отчеты, макросы и модули. У баз данных, созданных в формате Access 2007 (который также используется в Access 2013 и Access 2010), расширение файла — .accdb, а у баз данных, созданных в более ранних форматах Access, расширение файла — .mdb. С помощью Access 2013, Access 2010 или Access 2007 можно создавать файлы в более ранних форматах (например, в Access 2000 и Access 2002–2003).

Использование Access позволяет:

· добавлять новую информацию в базу данных, например новый артикул складских запасов;

· изменять информацию, уже находящуюся в базе, например перемещать артикул;

· удалять информацию, например если артикул был продан или утилизирован;

· упорядочивать и просматривать данные различными способами;

· обмениваться данными с другими людьми с помощью отчетов, сообщений электронной почты, внутренней сети или Интернета.

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

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

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

Строки в таблице называются записями. В записи содержатся блоки информации. Каждая запись состоит по крайней мере из одного поля. Поля соответствуют столбцам в таблице. Например, в таблице под названием «Сотрудники» в каждой записи находится информация об одном сотруднике, а в каждом поле — отдельная категория информации, например имя, фамилия, адрес и т. д. Поля выделяются под определенные типы данных, например текстовые, цифровые или иные данные.

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

2. Запрос. Объект, который позволяет пользователю получить нужные данные из одной или нескольких таблиц. Для создания запроса можно использовать бланк QBE (запрос по образцу) или инструкции SQL (структурированный язык запросов). Можно создать запросы на выборку, обновление, удаление или добавление данных. С помощью запросов можно также создавать новые таблицы, используя данные из одной или нескольких существующих таблиц.

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

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

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

4. Отчет. Отчеты используются для форматирования, сведения и показа данных. Обычно отчет позволяет найти ответ на определенный вопрос, например «Какую прибыль в этом году принесли нам наши клиенты?» или «В каких городах живут наши клиенты?» Отчеты можно форматировать таким образом, чтобы информация отображалась в наиболее читабельном виде.

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

5. Макрос. Объект, представляющий собой структурированное описание одного или нескольких действий, которые должен выполнить Access в ответ на определенное событие. Например, можно определить макрос, который в ответ на выбор некоторого элемента в основной форме открывает другую форму. С помощью другого макроса можно осуществлять проверку значения некоторого поля при изменении его содержимого. В макрос можно включить дополнительные условия для выполнения или невыполнения тех или иных указанных в нем действий. Из одного макроса можно также запустить другой макрос или процедуру VBA.

6. Модуль. Объект, содержащий программы, написанные на языке Visual Basic для приложений. Модули могут быть независимыми объектами, содержащими функции, вызываемые из любого места приложения, но они могут быть и непосредственно «привязаны» к отдельным формам или отчетам для реакции на те или иные происходящие в них изменения. Концептуальные взаимосвязи объектов Access показаны на рис. 1

Рис. 1. Взаимосвязи основных объектов в Microsoft Access.

В таблицах хранятся данные, которые вы можете извлекать с помощью запросов. Используя формы, вы можете выводить данные на экран или изменять их. Заметим, что формы и отчеты получают данные как непосредственно из таблиц, так и через запросы. Для выполнения нужных вычислений и преобразования данных запросы могут использовать встроенные функции или функции, созданные с помощью Visual Basic для приложений. События, происходящие в формах или отчетах, могут запускать макросы или процедуры VBA. Событие – любое изменение состояния объекта Microsoft Access. Например, событием является открытие формы, закрытие формы, ввод новой строки в форму, изменение содержимого текущей записи или элемента управления (объекта формы или отчета, который может содержать данные). Для обработки события вы можете создать макрос или процедуру Visual Basic для приложений

7.1 Основные понятия баз данных

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

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

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

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

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

Сущность (entity) – это реальный или представляемый тип объекта, информация о котором должна сохраняться и быть доступна. В диаграммах сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра этого типа. Примеры сущностей: ФАКУЛЬТЕТ, ГРУППА, СТУДЕНТ. Каждый экземпляр сущности (объект) должен быть отличим от любого другого экземпляра той же сущности.

Пример экземпляров сущности ФАКУЛЬТЕТ: ПС, ФМ, АТ и т.п., сущности СТУДЕНТ: Иванов А.П., Петрова Н.Н. и т.п.

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

Связь «содержит»: ГРУППА содержит много СТУДЕНТОВ. Каждый СТУДЕНТ входит только в одну ГРУППУ.

Связь «укушен»: СОБАКА может укусить много ЧЕЛОВЕК, ЧЕЛОВЕК может быть укушен многими СОБАКАМИ.

Связь «владеет»: ЧЕЛОВЕК может владеть многими СОБАКАМИ. У СОБАКИ может быть только один хозяин.

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

Свойства сущностей

Сущности имеют свойства, которые называются атрибутами (attribute).

  • сущности ФАКУЛЬТЕТ:
    • название;
    • год создания;
  • сущности ГРУППА:
    • номер;
  • сущности СТУДЕНТ:
    • фамилия;
    • имя;
    • отчество;
    • номер студенческого билета;
    • номер паспорта;
    • год рождения;
    • месяц рождения;
    • день рождения.

Любой атрибут принимает значения из некоторого множества допустимых значений, называемого доменом атрибута.

  • домен атрибута «год создания»: целые положительные числа;
  • домен атрибута «имя»: строка, не содержащая пробелов;
  • домен атрибута «год рождения»: целые положительные числа;
  • домен атрибута «месяц рождения»: январь, февраль, март … декабрь;
  • домен атрибута «день рождения»: целые числа от 1 до 31.

Ключ сущности

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

Например: ключ сущности СТУДЕНТ – номер студенческого билета, ключ ФАКУЛЬТЕТА – название. Если ключ состоит из одного атрибута, его называют простым ключом. Если ключ сущности состоит из нескольких атрибутов, его называют составным ключом.

Например, для сущности ДОМ с атрибутами «улица», «этажность», «год постройки», «номер дома», первичным ключом будет «улица»+ «номер дома».

Основные функции СУБД

  • управление данными во внешней памяти;
  • управление буферами оперативной памяти;
  • управление транзакциями;

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

Виды моделей данных

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

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

Различают три типа моделей данных, которые имеют множества допустимых информационных конструкций:

Иерархическая модель данных

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

Основные понятия иерархической структуры

Это – узел, уровень и связь.

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

Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. К каждой записи базы данных существует только один (иерархический) путь от корневой записи. Например, как видно из рисунке, для записи С4 путь проходит через записи ВЗ к А.

Пример иерархической структуры:

Сетевая модель данных

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

На рисунке изображена сетевая структура базы данных в виде графа.

Пример сетевой структуры:

Примером сложной сетевой структуры может служить структура базы данных, содержащей сведения о студентах, участвующих в научно-исследовательских работах (НИРС). Возможно участие одного студента в нескольких НИРС, а также участие нескольких студентов в разработке одной НИРС. Графическое изображение описанной в примере сетевой структуры состоит только из двух типов записей.

Реляционная модель данных

Понятие реляционный (англ. relation отношение) связано с разработками известного американского специалиста в области систем баз данных Е.Кодда.

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

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

Отношение – это плоская таблица, содержащая N столбцов, среди которых нет одинаковых. N – это степень отношения, или арность отношения. Столбец отношения соответствует атрибуту сущности. Кортеж – строка отношения (соответствует записи в таблице).

Пример реляционной модели

№ личного дела Фамилия Имя Отчество Дата рождения Группа
16493 Сергеев Петр Михайлович 01.01.90 112
16593 Петрова Анна Владимировна 15.03.89 111
16693 Антохин Андрей Борисович 14.04.90 112

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

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

Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ. В примере ключевым полем таблицы является «№ личного дела».

Концепция баз данных

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

Основныечерты концепции БД:

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

• появляются стандартизированные данные о фактографических данных – метаданные,управляемые СУБД; метаданные описывают информационные параметры и взаимосвязи фактографических данных о ПО;

СУБД совместно сметаданными представляет собой стандартизированное инструментальное средство для моделирования ПО различной природы;

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

достоверности данных и оптимизировать различные процедуры ведения и использования БД. Принято считать, что использование концепции баз данных позволяет:

1. повысить надежность, целостность и сохранность данных;

2. сохранить затраты интеллектуальноготруда;

3. обеспечить простоту и легкость использования данных;

4. обеспечить независимость прикладных программ от данных (изменений их описаний и способов хранения);

5. обеспечить достоверность данных;

6. обеспечить требуемую скорость доступа кданным;

7. стандартизовать данные в пределах одной предметной области;

8. автоматизировать реорганизацию данных;

9. обеспечить защиту от искажения и уничтожения данных;

10. сократить дублирование информации за счет структурирования данных;

11. обеспечить обработку незапланированных запросов к хранимой информации;

12. создать предпосылки для создания распределенной обработки дaнныx.

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

Понятие банка данных

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

Банк данных должен обеспечить

• хранение и модификацию больших объемов многоаспектной информации;

• заданный уровень достоверности и непротиворечивость хранимой информации, ее восстановление после сбоев и отказов;

• поиск информации по произвольной совокупности признаков;

• одновременное обслуживание большого числа пользователей;

• оперативность в обработке запросов;

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

Понятие СУБД

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

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

Информационные системы с базами данных

Итерационная процедура построения информационных систем

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

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

Низкая отдача уже существующей ИС организации на текущем этапе ее эксплуатации также становится тормозящим фактором. Изменение направлений бизнеса организации и ряд других факторов приводят к вопросу пересмотра отношения к ИС в организации, т.е. к извечному вопросу — переделать или начать с начала. Начать сначала всегда выгодней. Можно применить уже хорошо отработанные в информатике методики проектирования «сверху-вниз» или «снизу-верх». Однако рано или поздно опять встанет вопрос о соответствии требованиям сегодняшнего дня.

Илон Маск рекомендует:  Выбор данных из нескольких таблиц

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

Разработчики ИС фактически всегда находятся в методике «из-середины» (m >информационных систем . И, как следует из вышесказанного, он определяется не желанием теоретиков ИС, а жизненной необходимостью.

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

Что является основной особенностью технологии реализации итерационного подхода разработки и сопровождения ИС? Основная особенность реализации концепции разработки ИС, ориентированной на интегрированные процессы, — это наличие или отсутствие сборочного конвейера, поскольку необходимо собирать воедино многие технологические процессы обработки информации. При объединении технологических процессов обработки информации увеличивается скорость прохождения информации в системе, принятие решений на основе информационных потоков становится частью процесса обработки информации (и более состоятельной), уменьшается иерархия управленческих структур.

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

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

Концепция баз данных

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

Основные подходы к обработке информации в автоматизированных информационных системах

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

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

Торжество концепции независимости программ от данных привело к формированию в 1962 году концепции базы данных (БД) и созданию на ее основе метода баз данных для решения задач обработки информации. До середины 60-х годов прошлого века основной концепцией построения программного обеспечения являлась концепция файловой системы и так называемый позадачный метод. Такой подход по-прежнему остается доминирующим в разработке и функционировании несущих операционных платформ. В конце 80-х годов прошлого века была предложена концепция объектно-ориентированных баз данных и объектно-ориентированный подход разработки программ на основе обработки событий. На рис. 1.3 представлены основные черты для каждой из указанных выше концепций. На рис. 1.4 проведено сопоставление основных методов обработки данных.

Основные понятия и определения

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

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

Поле – столбец файлового документа (таблицы). Имя поля часто называют атрибутом.

Домен – совокупность значений одного поля.

Универсум – совокупность значений всех полей.

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

Запись логическая – поименованная совокупность данных, рассматриваемая пользователем как одно целое.

Запись физическая (совокупность данных записываемых/считываемых одним блоком) характеризует расположение данных в физической памяти ПК.

Ключ – поле с уникальными (неповторяющимися) записями, используемое для определения места расположения записи. Ключ может состоять из совокупности полей (составной ключ), называемых суперключом.

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

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

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

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

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

Архитектура – разновидность (обобщение) структуры, в которой какой-либо элемент может быть заменен на другой элемент, характеристики входов и выходов которого идентичны первому элементу. Понятие «принцип открытой архитектуры» используется при построении компьютера. Этот принцип означает, что вместо принтера одной марки (например, Epson) к компьютеру может быть подключен принтер другого типа (например, Hewlett Packard).

Безопасность – защита от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

Блокировка – неделимая операция, которая позволяет только одному процессу иметь доступ к совместно используемому ресурсу.

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

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

Внутренняя схема – описание данных на физическом уровне.

Время доступа – промежуток времени между выдачей команды записи (считывания) и фактическим получением данных.

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

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

Доступ – операция поиска, чтения данных или записи их.

Задание (работа) – программа или совокупность программ и преобразуемые этими программами данные.

Защита данных – противостояние базы данных несанкционированному доступу, преднамеренному искажению или разрушению информации.

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

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

Кортеж – совокупность полей или запись (строка).

КОДАСИЛ (CODASIL) – набор стандартов для сетевых баз данных.

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

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

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

Многозначная зависимость (MV-зависимость, зависимость 1:М) – для подсхем X, Y, Z, принадлежащих схеме R, Z = R – (XY) и кортежей t2(X) = t1(Х) и t3(Y) = t1(Y) справедливо t3(Z) = t1(Z) и t3(Z) = t2(Z).

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

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

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

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

Объектно-ориентированное программирование – методология программирования, основанная на представлении программ в виде связанной совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию по наследованию.

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

Отношение r на множествах (доменах) S1, . Sn – подмножество декартова произведения S,& . &Sn. Понятие «отношение» является основным в реляционных БД. Пусть имеется таблица с двумя полями S1 и S2 по два значения в каждом (S1 = и S2 = , т. е. в каждом домене по два значения). «Полная» таблица имеет четыре возможных записи (al, bl; al, b2; а2, М; а2, b2), которые и образуют декартово произведение. Отношением является и часть этой таблицы (например, al, bl; а2, b1). Отношение может быть и составным: r – (r1, . rn), составленным, например, из нескольких связанных таблиц.

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

Программа – полное и точное описание алгоритма на некотором формальном языке программирования.

Процедура – некоторая подпрограмма.

Распределенная база данных (РЕД) – единая БД, представленная в виде отдельных (возможно, избыточных и перекрывающихся) разделов на разных вычислительных средствах.

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

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

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

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

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

Системный журнал – журнал регистрации всех изменений БД.

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

Спецификация – операция, результатом которой является новая структура, построенная на основе структур базы данных.

Структура – совокупность элементов и нх связей.

Сущность – примитивный объект данных, отображающий элемент предметной области (человек, место, вещь и т. д.).

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

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

Функциональная зависимость (F-зависимость, зависимость 1:1): схема Y функционально зависит от X, если для кортежей t,(X) = t2(X), справедливо t1(Y) = t2(Y), причем схемы X и Y могут принадлежать схеме R.

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

Хранилище данных – предметно-ориентированный, интегрированный, привязанный ко времени и неизменный набор данных, предназначенный для поддержки принятия решений.

Целостность данных – устойчивость хранимых данных к разрушению (уничтожению), связанному с неисправностями технических средств, системными ошибками и ошибочными действиями пользователей.

Элемент данных – наименьшая единица данных, имеющая смысл при описании информации; наименьшая единица поименованных данных.

Экземпляр – отдельный экземпляр объекта, записи, элемента данных.

Язык базы данных – общий термин, относящийся к классу языков, которые используются для определения и обращения к базам данных.

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

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

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

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

Исходным элементом базы данных является таблица, структурные составляющие которой – поле и запись. Можно выделить две разновидности структуры таблиц: линейную и нелинейную. В линейной структуре поля располагаются последовательно друг за другом в произвольном порядке (табл. 1.11). В силу произвольности порядка для данной, конкретной реализации следует закрепить определенный вариант, называемый схемой пользователя.

Объектно-ориентированные базы данных: достижения и проблемы

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

Разработка систем объектно-ориентированных баз данных (так называемые технологии баз данных пятого поколения) началась в середине 80-х годов в связи с необходимостью удовлетворения требований приложений, отличных от тех приложений обработки данных, которые характерны для систем реляционных баз данных (технология баз данных четвертого поколения). Попытки использования технологий реляционных баз данных в таких сложных приложениях, как автоматизированное проектирование (computer aided design, CAD); автоматизированное производство (computer aided manufacturing, CAM); технология программирования; системы, основанные на знаниях, и мультимедийные системы, обнажили ограничения систем реляционных баз данных (РБД). В условиях, когда появилось новое поколение приложений баз данных, возникли потребности, которые лучшим образом удовлетворялись при применении объектно-ориентированных баз данных (ООБД).

Предлагалось много определений объектной ориентации и объектно-ориентированных баз данных [2, 20, 32, 8, 9, 19, 24], но мы будем определять объектно-ориентированные базы данных как базы, в которых объектная ориентация сочетается с возможностями баз данных. Объектная ориентация дает возможность более непосредственно представлять и моделировать проблемы реального мира, а функциональность баз данных требуется для обеспечения стабильности данных и многопользовательского параллельного доступа к информации приложений.

В настоящее время на рынке представлено свыше 25 систем ООБД. Среди них — система GemStone компании Servio, ONTOS компании Ontos, ObjectStore компании Object Design и многие другие [26]. Кроме того, системы управления реляционными базами данных, разработанные компаниями Oracle, Microsoft, Borland, Informix, включали объектно-ориентированные средства. Многие из этих продуктов появились еще во второй половине 80-х годов, и сегодня, по прошествии почти полутора десятилетий разработки они все еще не вступили в пору зрелости; в этом — одна из причин того, что по сей день мировой рынок реальных приложений не торопится принимать системы ООБД. Среди современных ООБД почти нет полностью оперившихся систем, сопоставимых с современными системами реляционных баз данных. Обсудим основные достижения и проблемы, связанные с нынешним состоянием ООБД.

Модель ООБД

Причиной появления систем объектно-ориентированных баз данных была потребность в более адекватном представлении и моделировании сущностей реального мира, поскольку ООБД обеспечивают гораздо более развитую модель данных, нежели традиционные — реляционные базы данных. Парадигма ООБД основывается на ряде базовых понятий, таких как объект, идентифицируемость, класс, наследование, перегрузка и отложенное связывание [2, 3, 23, 31, 36].

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

У каждого объекта имеется определяемый системой уникальный идентификатор. Объекты, обладающие одними и теми же свойствами и поведением, группируются в классы. Объект может быть экземпляром только одного класса [5, 6] или нескольких классов [11, 13].

Классы организуются в иерархии классов. Подкласс наследует свойства и методы суперкласса; кроме того, подклассы могут обладать индивидуальными свойствами и методами. В некоторых системах, например, ORION [4], у класса можется более одного суперкласса (множественное наследование), тогда как в других системах число суперклассов ограничено одним (одиночное наследование).

В большинстве моделей допускается перегрузка унаследованных свойств и методов. Перегрузка состоит в замене домена свойств новым доменом или в замене одной реализации метода другой его реализацией [7].

Достоинства модели ООБД

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

Определение пользовательских абстракций

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

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

Примером пакета ООБД, обладающего всеми упомянутыми возможностями, может служить ENCORE [37]. Модель данных в ENCORE базируется главным образом на абстракции данных. ENCORE допускает подтипизацию (наследование), инкапсуляцию, сложные структуры, идентификацию объектов и отложенное связывание методов. Кроме того, ENCORE обеспечивает возможность связывания объектов с помощью свойств. В системе ENCORE свойство p связывает объект x с набором объектов S без какого-либо указания того, каким образом вычисляется эта связь. Ее можно вычислить путем прямого указания идентификатора набора S (или идентификаторов его членов) или с помощью установления соответствий значений других свойств, как в соединении.

Облегченное проектирование некоторых связей

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

Отсутствие потребности в определяемых пользователями ключах

В модели ООБД имеется понятие идентификаторов объектов, автоматически генерируемых системой и гарантированно уникальных для каждого объекта. Это обстоятельство в сочетании с тем, что в модели ООБД устраняется потребность в определяемых пользователями ключах, дает объектно-ориентированным базам данных и другие преимущества. Во-первых, идентификатор объекта не может быть модифицирован приложением. Во-вторых, понятие идентифицируемости объекта влечет отдельное и согласованное понятие идентичности, не зависимое от того, каким образом производится доступ к объекту или как объект моделируется с помощью описательных данных [22, 36]. Следовательно, два объекта не являются идентичными, если они имеют различные идентификаторы объектов; при этом объекты могут иметь одинаковые структуры, а все их свойства — одни и те же значения. В модели РБД, где идентификация объектов осуществляется через определяемые пользователями ключи, такие объекты считались бы одним и тем же объектом [7].

Наличие предикатов сравнения

В РБД сравнение всегда базируется лишь на значениях. В этой модели два кортежа являются одной сущностью, если все их ключевые атрибуты имеют одинаковые значения. Однако в модели ООБД были разработаны и определены иные типы сравнения [36, 7].

  1. Равенство объектов на основе их идентичности. Два объекта, S1 и S2 равны, если они являются одним и тем же объектом (т.е. имеют один и тот же идентификатор объекта).
  2. Равенство объектов на основе значений. Это можно определить в два захода — (a) два примитивных объекта равны, если имеют одно и то же значение; (b) два не примитивных объекта равны, если они имеют одинаковое число свойств, и для каждого свойства pi объекта S1 существует свойство pj объекта S2, равное ему по значению.
  3. Равенство свойств на основе значений.
  4. Равенство свойств на основе их идентичности.
Меньшая потребность в соединениях

Возможность навигации по структурам объектов и проистекающие из этого путевые выражения в терминах атрибутов объектов дают нам возможность по-новому взглянуть на проблему соединений в ООБД. Реляционное соединение — это механизм, сопоставляющий два отношения на основе значений соответствующих пар атрибутов в этих отношениях. Поскольку в ООБД два класса могут иметь соответствующие пары атрибутов, в этой модели все еще может сохраняться необходимость в реляционном соединении (или явном соединении). Например, допустим, у нас имеются классы Student и School, причем в каждом из этих классов имеются атрибуты Name и Age. Хотя домены атрибутов Name и Age класса School могут не совпадать с доменами атрибутов Name и Age класса Student, мы можем захотеть связать эти классы на основе значений этих атрибутов (скажем, найти всех учащихся, чей возраст меньше возраста школы, которую посещает данный учащийся).

Но, как уже отмечалось, поддержка путевых выражений может существенно сократить потребность в соединении классов по сравнению с ситуацией в РБД [25]. Имеются даже ситуации, в которых потребность в реляционном объединении может быть полностью устранена. Например, когда доменом атрибута класса A является класс B, выборка идентификаторов объектов некоторого класса, которые хранятся как значения атрибута другого класса, устраняет потребность в неявном соединении объектов.

Таким образом, в объектно-ориентированных базах данных неявные соединения, порождаемые иерархической вложенностью объектов, отличаются от явных объединений. Последние напоминают реляционные соединения: два объекта сравниваются явным образом по значениям атрибутов или объектных идентификаторов. Более того, все явные соединения (основанные на сравнении значений или идентификаторов) не могут быть выражены на реляционном языке запросов, поскольку в РБД любой предикат может содержать только атомарные атрибуты [7].

Выигрыш в производительности

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

  1. В ООБД значение атрибута объекта X, доменом которого является другой объект Y, — это идентификатор объекта Y. Следовательно, если приложение уже извлекло объект X и теперь хотело бы извлечь объект Y, то СУБД может извлечь объект Y, отыскав его идентификатор. Если этот идентификатор представляет собой физический адрес объекта, то данный объект может быть извлечен непосредственно; если же идентификатор является логическим адресом, то объект путем нахождения соответствующего элемента хэш-таблицы (в предположении, что в системе поддерживается хэш-таблица, отображающая идентификатор объекта в физический адрес). В РБД это могло бы не получиться так просто, поскольку в РБД не поддерживаются идентификаторы объектов.
  2. Вторая особенность ООБД, обеспечивающая выигрыш в производительности, состоит в том, что в большинстве ООБД при загрузке объекта в память хранимые в этом объекте идентификаторы объектов преобразуются в указатели по памяти. Поскольку в РБД не хранятся идентификаторы объектов, в них невозможно сохранять указатели по памяти на другие кортежи. Отсутствие возможности навигации по объектам, содержащимся в памяти, является принципиальным свойством РБД, и вытекающее из этого снижение производительности не может быть компенсировано простым увеличением объема буферной памяти. Так что при выполнении приложений, которые предполагают многократную навигацию по загруженным в память связанным объектам, ООБД могут существенно превзойти РБД по производительности [25].
  3. Кроме того, даже если ООБД не проиндексированы, может оказаться удобным выполнять произвольные запросы, соответствующие структуре объектов, путем последовательного сканирования, т.е. использовать ссылочные пути между объектами. Когда запрос формулируется в направлении, не поддерживаемом ссылками, этот запрос будет обрабатываться путем последовательного сканирования [14]. Однако запросы, формулируемые на основании таких связей объектов, которые не моделируются напрямую с помощью ссылок, выполняются неэффективно.
Поддержка версий и длительных транзакций

В РБД не поддерживаются ни работа с версиями, ни длительные транзакции. Такая поддержка имеется в некоторых ООБД, хотя и с ограниченными возможностями [25].

Объектная алгебра

Объектная алгебра не столь подробно разработана и не является столь же зрелой, как реляционная алгебра. Но как бы то ни было, такая алгебра существует, и в ней определяются пять фундаментальных операций, сохраняющих объекты: union, difference, select, generate и map [29]. На основе этих фундаментальных операций могут быть определены другие операции, например, intersection. Правила преобразований для логической оптимизации выражений объектной алгебры с сохранением эквивалентности выводятся в [33] и [34]. В то время как операции union, difference и map производят, главным образом, отображение «один к одному», операции select и generate производят отображение «один ко многим». Сохранение объектов означает, что алгебраические операции возвращают объекты, принадлежащие к ранее определенным классам базы данных, и не создают новых объектов. Оператор union возвращает объекты, содержащиеся во множестве P или во множестве Q, или в обоих множествах. Оператор difference возвращает набор объектов, принадлежащих множеству P, но не множеству Q. select возвращает подмножество введенного множества. generate генерирует объекты из тех, что принадлежат входному множеству. map возвращает множество объектов, образующихся в результате каждого применения последовательности методов [34].

Недостатки модели ООБД

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

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

Отсутствие интероперабельности между РБД и ООБД

Чтобы ООБД смогли оказать значительное влияние на рынок баз данных, необходимо выполнить ряд условий.

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

Одной из самых значительных проблем в ООБД является оптимизация декларативных запросов. Оптимизацию запросов к ООБД затрудняет дополнительная сложность самой объектно-ориентированой модели данных [15]. Эта дополнительная сложность обусловлена рядом факторов.

  1. Возможность определения пользователями новых типов и классов с помощью наследования и облегчает, и осложняет оптимизацию запросов. Примером, в котором эта возможность помогает оптимизации, может служить запрос, включающий пересечение множеств Employees («сотрудники») и Supervisors («инспекторы»). Если Employee является суперклассом класса Supervisor, то оптимизатор может исходить из того, что Supervisors является собственным подмножеством Employees и упростить процедуру пересечения множеств. Пример, в котором дополнительные типы данных ограничивают возможности оптимизации, может служить объединение множеств Students и Employees; суперклассом для обоих классов является класс Person. Если бы мы захотели найти всех инспекторов студентов и служащих, мы бы сначала произвели объединение, а применили бы supervisor() [15].
  2. Запросы могут базироваться на операциях над коллекциями, но виды оптимизации, затрагивающие множества (или мультимножества, или списки и т.п.), нужно сочетать с оптимизацией над типами объектов, содержащихся в этих множествах. Объектно-ориентированный оптимизатор запросов должен быть в состоянии применять процедуры оптимизации, характерные для данных типов, а также процедуры оптимизации, учитывающие связи между объектами разных типов [27].
  3. Сложность обработки запросов в ООБД усугубляется наличием сложных объектов, методов и инкапсуляции. Сложные объекты порождают путевые выражения, которые усложняют обработку запросов. Создание индексов для путевых выражений, особенно при наличии в выражениях произвольных методов, усложняет обработку запросов. Проблема еще более осложняется, если методы обладают побочными эффектами. Еще одна проблема, связанная с путевыми выражениями, состоит в том, что они навязывают порядок вызовов методов путевого выражения, и этот порядок может быть весьма неэффективным. Например, путевое выражение Orders.part.name лучше вычислять справа налево, если имеется много заказов (Orders) и мало деталей (Parts), но если деталей много, а заказов мало — выражение лучше вычислять слева направо. Кроме того, иногда путевые выражения более эффективно обрабатываются с использованием Join. Рассмотрим, например, запрос с путевым выражением s.comp.name, где s принадлежит множеству Students (студенты). Могло бы оказаться более эффективно (если число компаний, comp, невелико) сначала вычислить название (Name) для каждой компании (Company) и сохранить результат в кортеже. Тогда вычисление выражения от студента до названия компании включало бы соединение множества Students с множеством кортежей путем сопоставления свойства comp класса student со значением атрибута Company некоторого кортежа.
  4. В языках запросов к ООБД поддерживается использование вложенных структур, которые опять-таки могут существенно усложнить процесс оптимизации, поскольку превращают его из локальной проблемы в проблему глобальную, поскольку требуется глобальное знание всего выражения запроса.
  5. Когда объекты обладают идентифицируемостью, возникает вопрос, а что же понимается под равенством двух объектов [27]. Этот вопрос переносится в язык, где операции сравнения по равенству используются в предикатах, и где необходимо принимать решение о создании новых объектов при выполнении запроса. Оптимизатор объектно-ориентированных моделей должен быть в состоянии решать проблемы, связанные с созданием новых объектов и с альтернативными определениями равенства.
Илон Маск рекомендует:  Защита shareware приложения

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

Отсутствие стандартной алгебры запросов

Еще один серьезный недостаток ООБД состоит в отсутствии стандартов алгебры запросов. Это обстоятельство тоже затрудняет оптимизацию запросов. Для ООБД было предложено несколько разных формальных языков запросов, основанных на алгебрах и исчислениях [35, 34, 16, 26, 17]. Эти алгебры и исчисления отличаются в нескольких отношениях, и по выразительности, и по поддержке оптимизирующих правил перезаписи. Почти все эти алгебры базируются на переменных, т.е. используют переменные для хранения промежуточных результатов. KOLA, один из пакетов ООБД, является чисто функциональным продуктом; переменные в нем не используются. В [10] автор утверждает, что именно благодаря отсутствию переменных алгебра KOLA позволяет строить более мощные системы правил.

В РБД существует близкое соответствие между алгебраическими операциями и низкоуровневыми примитивами физической системы [30]. Это строгое соответствие достигается за счет отображений между отношениями и файлами, а также между кортежами и записями. Однако в ООБД нет аналогичного интуитивного соответствия между операциями объектной алгебры и примитивами физических систем. При всяком обсуждении генерации плана выполнения тоже необходимо, прежде всего, определить низкоуровневые примитивы манипулирования объектами [34].

Отсутствие средств обеспечения запросов

В большинстве ООБД не хватает средств обеспечения запросов [25]. В тех же немногих системах, где имеются достаточные соответствующие средства, язык запросов не совместим с ANSI SQL. Среди этих средств обеспечения запросов нет вложенных подзапросов, запросов с множествами (union, intersection, difference), агрегатных функций и GROUP BY, соединения нескольких классов — возможностей, полностью поддерживаемых в РБД [25].

Кроме того, отсутствует стандарт для объектных запросов, хотя надо сказать, что предпринимались попытки разработать объектный язык SQL [14]. SQL3, вероятно, задерживается на несколько лет [25].

Отсутствие поддержки представлений

В ООБД не поддерживаются представления. Хотя по этому поводу было выдвинуто несколько предложений [1, 13, 18, 12, 28], не удалось придти к единому мнению относительно того, как механизм представлений должен функционировать в ООБД. Разработка объектно-ориентированного механизма представлений осложняется такими свойствами модели, как идентифицируемость объектов. Что такое идентификатор объекта в представлении? С другой стороны, высказывается точка зрения, согласно которой возможность инкапсуляции данных и наследования позволяет обойтись без явных определений представлений [14].

Проблемы с безопасностью

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

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

Отсутствие поддержки динамических изменений определений классов

В дополнение к тому, что для ООБД до сих пор не разработана единая стандартная модель данных, в большинстве ООБД не допускаются динамические изменения схемы баз данных, таких как добавление к классу нового атрибута или метода, добавление к классу нового суперкласса, удаление суперкласса класса, добавление нового класса и удаление класса. РБД позволяют пользователю динамически изменять схему базы данных с помощью команды ALTER; к отношению может быть добавлен новый столбец, отношение может быть удалено, а в некоторых случаях имеется возможность удаления столбца из отношения [25].

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

Ограниченная поддержка ограничений целостности

Отсутствуют механизмы объявления ключевых свойств атрибутов (например, атрибут класса не может быть объявлен первичным ключом класса), или ограничений уникальности, явных ограничений целостности, а также пред- и постусловий методов [14]. Хотя все это можно сделать с использованием методов, явные ограничения были бы удобнее для пользователей, порождали бы меньше ошибок и были бы более доступными для проверки и модификации.

Ограниченные возможности настройки производительности

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

Недостаточная поддержка сложных объектов

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

Ограниченная интеграция с объектно-ориентированными системами программирования

Трудно переписывать объектно-ориентированные программы для управления стабильными данными. Здесь возникает ряд проблем: конфликты по именам; необходимость переделывать иерархии классов; склонность ООБД к перегрузке системных операций [14].

Ограниченный выигрыш в производительности

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

В числе средств, пока что не поддерживаемых в ООБД, также можно назвать триггеры, средства управления метаданными [14], а также ограничения целостности, такие как UNIQUE и NULL [25].

Из-за указанных слабостей ООБД не смогли оправдать возлагавшихся на них ожиданий: обеспечить все важные средства, желательные для целевых приложений. Применительно к большинству современных систем термин «ООБД» используется неправильно. Почти все современные ООБД — не столько системы баз данных, сколько системы стабильного хранения данных для некоторого объектно-ориентированного языка программирования [25]. Так что, хотя объектно-ориентированная модель данных во многих отношениях богаче реляционной модели, объектно-ориентированная модель еще не вполне вступила в период зрелости. На сегодняшний день недостатков в системах ООБД явно больше, чем достоинств.

  1. S. Abiteboul, A. Bonner, «Objects and views». ACM SIGMOD Int. Conf. On Management of Data, 1991.
  2. M. Atkinson, et al., «Object-Oriented Database System Manifesto». Building an Object-Oriented Database System: The Story of O2. Morgan Kaufman, 1992.
  3. F. Bancilhon, «Object oriented database systems». 7th ACM SIGART/SIGMOD Conf., 1988.
  4. J. Banerjee, et al., «Data model issues for object oriented applications». ACM Trans. On Office Information Systems, Jan 1987.
  5. J. Banerjee, W. Kim, K.C. Kim, «Queries in object oriented databases». IEEE Data Engineering Conf., Feb. 1988.
  6. D. Beech, «Foundation for evolution and relational to object databases». Proc. Extended Data Base Technology, Mar. 1988.
  7. E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, «Object-Oriented Query Languages: Notion and Issues». IEEE Transactions on Knowledge and Data Engineering, Mar. 1992.
  8. A.W. Brown, Object-Oriented Databases, Applications in Software Engineering. New York: McGraw-Hill, 1991.
  9. R.G.G. Cattell, Object Data Management, Object-Oriented and Extended Relational Database Systems. Addison-Wesley, 1991.
  10. M. Cherniack, «Form(ers) over Function(s): KOLA Query Algebra». Technical Report, Brown University, Dec. 1995.
  11. S. Cluet, et al., «Reloop, Algebra based query language for an object-oriented database system». 1st Int. Conf. On Deductive and Object Oriented Databases, Dec. 1989.
  12. I.F. Cruz, DOODLE: Visual language for object-oriented databases. ACM SIGMOD Int. Conf. On Management of Data, 1992.
  13. U. Dayal, «Queries and views in object-oriented data model». 2nd Int. Work. On Database Programming Languages, June 1989.
  14. K.A. Dittrich, K.R. Dittrich, «Where Object-Oriented DBMSs Should Do Better: A Critique Based on Early Experiences». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
  15. U. Erlingsson, «Object-Qriented Query Optimization», unpublished manuscript.
  16. L. Fegaras, D. Maier, «Towards an Effective Calculus for Object Query Languages». ACM SIGMOD Int. Conf. on Management of Data, San Jose, California, May 1995.
  17. L. Fegaras, D. Maier, T. Sheard, «Specifying Rule-based Query Optimizers in a Reflective Framework». 3rd Int. Conf. on Deductive and Object-Oriented Databases, Phoenix, Arizona, Dec. 1993.
  18. S. Heiler, S. Zdonik, «Object Views: Extending the vision». 6th Int. Conf. On Data Engineering, 1990.
  19. J.G. Hughes, Object-Oriented Databases. New York: Prentice-Hall, 1991.
  20. S. Khoshafian, «Insight Into Object-Oriented Databases». Information and Software Technology, Apr. 1990.
  21. S. Khoshafian, Object-Oriented Databases, New York: John Wiley & Sons, 1993.
  22. S. Khoshafian, G. Copeland, «Object identity». 1st Int. Conf. On Object-Oriented Programming Systems, Languages, and Applications, Oct. 1986.
  23. W. Kim, «Foundation for object-oriented databases». MCC Tech. Rep., N. ACA-ST-248-88, Aug. 1988.
  24. W. Kim, Introduction to Object-Oriented Databases. MIT Press, 1991.
  25. W. Kim, «Object-Oriented Database Systems: Promises, Reality, and Future». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
  26. T.W. Leung, et al, «Aqua Data Model and Algebra». Technical Report CS-93-09, Brown University, Mar. 1993.
  27. G. Mitchell, S.B. Zdonik, U. Dayal, «Object-Oriented Query Optimization — What?s the Problem?» Technical Report CS-91-41, Brown University, June 1991.
  28. E.A. Rudensteiner, «Multiview: Methodology for supporting multiple views in object-oriented databases». 18th Int. Conf. On Very Large Databases, 1992.
  29. M. Scholl, H. Schek, «Relational object model». 3rd Int. Conf. On Database Theory, LNCS, vol. 470, Springer Verlag, 1990.
  30. P.G. Selinger, et al, «Access path selection in a relational database management system». ACM SIGMOD Int. Conf. On Management of Data, 1979.
  31. M. Stefik, D.G. Bobrow, «Object-oriented programming: Themes and variations». The AI Mag., Jan. 1986.
  32. M. Stonebraker, et al, «Third-Generation Data Base System Manifesto». Committee for Advanced DBMS Function, University of California, Berkeley, 1990.
  33. D.D. Straube, M.T. Ozsu, «Queries and query processing in object-oriented database systems». ACM Transactions on Information Systems, Oct. 1990.
  34. D.D. Straube, M.T. Ozsu, «Execution Plan Generation for Object-Oriented Data Model». 2nd Int. Conf. on Deductive and Object-Oriented Databases, Munich, Germany, Dec. 1991.
  35. S.Y.W. Su, M. Guo, H. Lam, «Association Algebra: Mathematical Foundation for Object-Oriented Databases». IEEE Transactions on Knowledge and Data Engineering, Oct. 1993.
  36. S.B. Zdonik, D. Maier, eds., Readings in Object-Oriented Database Systems, Morgan Kauffman, 1989.
  37. S.B. Zdonik, P. Wegner, «Language and Methodology for Object-Oriented Database Environments». Hawaii Int. Conf. on System Sciences, Jan. 1986.

Сиха Багуи (bagui@uwf.edu) — лектор факультета компьютерных наук университета Западной Флориды. Соавтор трех книг, посвященных базам данных: Learning SQL: A Step-by-Step Guide Using Oracle, Learning SQL: A Step-by-Step Guide Using Access (Addison Wesley) и Database Design Using Entity Relationship Diagrams (CRC Press).

Translated from «Achievements and Weaknesses of Object-Oriented Databases» by Sikha Bagui in Journal of Object Technology (JOT), vol. 2, no. 4, July-August 2003, pages 29-41. Translated into Russian for Otkrytye Systemy under special permission of the original publisher. Copyright JOT, 2003. Original article at http://www.jot.fm/issues/issue_2003_07/column2.

От редактора перевода

ООБД — зрелость или упадок?

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

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

Статья основывается на анализе 36 публикаций, посвященных объектно-ориентированным базам данных и изданных в период 1986-1995 годов. Поэтому часто используемая характеристика «современные» ООБД не совсем справедлива. Цитаты, иногда подаваемые в настоящем времени, порой выглядят довольно подозрительно.

Конечно же, в многочисленных источниках использовалась разная терминология, и в этом отношении их обзор обладает исключительной пестротой. Кроме того, многие из статей достаточно сложны с технической точки зрения, и их цитирование без обеспечения контекста только затрудняет понимание. Наиболее яркий пример — подраздел про разработку объектной алгебры. Первые три «фундаментальные» операции — union, difference, select — интуитивно понятны (хотя в действительности у авторов оригинальной статьи допускается не очень очевидный вариант выборки в форме полусоединения), но две последние — generate и map — являются сложно определяемыми и неочевидными операциями.

Хочу отметить еще одну странную особенность статьи Багуи. До 2001 года существовал международный консорциум Object Data Management Group, который опубликовал три версии предложений по стандартизации объектно-ориентированной модели данных; последняя версия — ODMG 3.0 была опубликована в 2000 году [1]. Это единственный документ, в котором предлагается сравнительно согласованная терминология и, в некоторой степени, объектно-ориентированная модель данных. Жаль, что Багуи не пользуется этим материалом.

Заметим, что в журнале «СУБД» публиковались статья, посвященная первому варианту стандарта, ODMG-93 [2]. Краткий обзор стандарта ODMG 3.0 можно найти в [3]. Также можно рекомендовать перевод Манифеста систем объектно-ориентированных баз данных [4] и очень симпатичный обзор технологии ООБД [5].

  1. The Object Data Standard: ODMG 3.0. R.G.G. Cattel, D.K. Barry, eds., Morgan Kauffmann, 2000.
  2. Л.А. Калиниченко, «Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния». // СУБД, № 1, 1996.
  3. С.Д. Кузнецов. «Три манифеста баз данных: ретроспектива и перспективы». Доклад на конференции «Базы данных и информационные технологии XXI века», Москва, сентябрь 2003, http://www.citforum.ru/database/articles/manifests.
  4. М. Аткинсон и др., «Манифест систем объектно-ориентированных баз данных», // СУБД, № 4, 1995.
  5. Арк Андреев, Дмитрий Березкин, Роман Самарев, «Внутренний мир объектно-ориентированных СУБД». // Открытые системы, № 3, 2001.

Поделитесь материалом с коллегами и друзьями

Объектно-ориентированные базы данных — основные концепции, организация и управление: краткий обзор

Written on 11 Ноября 2006 . Posted in Теория баз данных

ОГЛАВЛЕНИЕ

Что касается связи с предыдущими работами в области БД, то на наш взгляд наиболее сильное влияние на работы в области ООБД оказывают проработки реляционных СУБД и следующее хронолигически за ними семейство БД, в которых поддерживается управление сложными объектами [52-56]. Кроме того, исключительное влияние на идеи и концепции ООБД и, как кажется, всего объектно-ориентированного подхода оказал подход к семантическому моделированию данных (например, [57-59], хотя общее число публикаций по семантическому моделированию поистине безгранично). Достаточное влияние оказывают также развивающиеся параллельно с ООБД направления дедуктивных и активных БД [10, 42, 82, 84].

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

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

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

Общие понятия объектно-ориентированного подхода и их преломление в ООБД

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

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

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

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

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

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

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

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

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

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

С другой стороны, если абстрагироваться от поведенческого аспекта объектов, объектно-ориентированный подход весьма близок к подходу семантического моделирования данных [58] (даже и по терминологии). Фундаментальные абстракции, лежащие в основе семантических моделей, неявно используются и в объектно-ориентированном подходе. На абстракции агрегации основывается построение сложных объектов, значениями атрибутов которых могут быть другие объекты. Абстракция группирования — основа формирования классов объектов. На абстракциях специализации/обобщения основано построение иерархии или решетки классов.

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

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

Первый аспект касается потребности в средствах спецификации знаний при определении класса (ограничений целостности, правил дедукции и т.п.) Второй аспект — потребность в механизме определения разного рода семантических связей между объектами вообще говоря разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использовании ООБД в сфере автоматизированного проектирования и инженерии [66]. Наконец, третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа и класса объектов.

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

Объектно-ориентированные модели данных

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

Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математичекого аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. В большой степени поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, в [63] со ссылкой на недоступную нам работу Майера [99] утверждается, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности.

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

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

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

Автор [63] не представляет полной формальной модели структурного уровня ООБД, но выражает уверенность, что текущего уровня понимания достаточно, чтобы формализовать такую модель. Что же касается поведенческого уровня, предложен только общий подход к требуемому для этого логическому аппарату (логики первого уровня недостаточно).

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

Имеется достаточное количество других публикаций, отноcящихся к теме объектно-ориентированных моделей данных [61-62, 64, 65-68], но они либо затрагивают достаточно частные вопросы, либо используют слишком серьезный для этого обзора математический аппарат (к числу последних относится работа Леллани и Спиратоса [68], в которой объектно-ориентированная модель данных определяется на основе теории категорий).

Для иллюстрации текущего положения дел мы кратко рассмотрим особенности конкретной модели данных, применяемой в объектно-ориентированной СУБД O2 [29, 32] (это, конечно, тоже не модель данных в классическом смысле).

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

Возможны два вида организации данных: классы, экземплярами которых являются объекты, инкапсулирующие данные и поведение, и типы, экземплярами которых являются значения. Каждому классу сопоставляется тип, описывающий структуру экземпляров класса. Типы определяются рекурсивно на основе атомарных типов и ранее определенных типов и классов с применением конструкторов. Поведенческая сторона класса определяется набором методов.

Объекты и значения могут быть именованными. С именованием объекта или значения связана долговременность его хранения (persistency): любые именованные объекты или значения долговременны; любые объект или значение, входящие как часть в другой именованный объект или значение, долговременны.

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

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

В модели O2 поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Возможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.

Поддерживается предопределенный класс «Оbject», являющийся корнем решетки классов; любой другой класс является неявным наследником класса «Object» и наследует предопределенные методы («is_same», «is_value_equal» и т.д.).

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

В [29] приводится достаточно формализованное описание модели O2, мы для простоты изложения и понимания следовали [32], где модель описывается на содержательном уровне. В следующем разделе мы среди прочего рассмотрим особенности языков программирования и запросов системы O2, которые, конечно, тесно связаны со спецификой модели данных.

Языки программирования систем ООБД и языки запросов

Как отмечают многие исследователи и разработчики (например, [8, 70]), объектно-ориентированная система БД представляет собой объединение системы программирования и СУБД (альтернативная, но не более проясняющая суть дела точка зрения состоит в том, что объектно-ориентированная СУБД — это СУБД, основанная на объектно-ориентированной модели данных [8]).

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

Илон Маск рекомендует:  Php удаление строки из файла

Эта сторона ООБД наиболее близка родственному направлению языков программирования БД [77]. Языки программирования ООБД и БД во многих своих чертах различаются только терминологически; существенным отличием является лишь поддержание в языках первого класса подхода к наследованию классов. Кроме того, языки второго класса, как правило, более развиты как в отношении системы типов, так и в отношении управляющих конструкций.

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

К моменту написания данного обзора нам неизвестен какой-либо язык программирования ООБД, который был бы спроектирован целиком заново, начиная с нуля. Естественным подходом к построению такого языка было использование (с необходимыми расширениями) некоторого существующего объектно-ориентированного языка. Начало расцвета направления ООБД совпало с пиком популярности языка Smalltalk-80. Этот язык оказал большое влияние на разработку первых систем ООБД, и, в частности, использовался в качестве языка программирования [34, 36]. Во многом опирается на Smalltalk и известная коммерчески доступная система GemStone [22-24].

Трудности с эффективной практической реализацией языка Smalltalk побудили разработчиков систем ООБД к поиску альтернативных базовых языков. Известная близость объектно-ориентированного и функционального подходов к программированию позволяет достаточно успешно опираться на функциональные языки программирования. В частности, язык Лисп (Common Lisp) является основой проекта ORION [17]. В этом проекте Лисп является и инструментальным языком, и базой объектно-ориентированного языка программирования в среде ORION.

Потребности в еще более эффективной реализации заставляют использовать в качестве основы объектно-ориентированного языка языки более низкого уровня. Например, в системе VBASE [24] наряду со специально разработанным языком TDL, предназначенным для определения типов, используется объектно-ориентированное расширение языка Си — COP (C Object Processor). В уже упоминавшемся проекте O2 [29-32] наряду с функциональным объектно-ориентированным языком программирования [41] используются два объектно-ориентированных расширения языков Бейсик и Си. При этом, насколько можно судить по публикациям, наибольшее распространение среди пользователей этой системы (она уже коммерчески доступна) получил язык CO2, являющийся расширением языка Си. Возможно это связано лишь с широкой (и все более возрастающей) популярностью языка Си (и его объектно-ориентированного потомка Си++), ставшего поистине девизом «настоящих программистов». Может быть, причины более глубинны (например, языки более высокого уровня слишком ограничительны для программистов-профессионалов; недаром большинство современных реализаций языков более высокого уровня выполняются именно на языке Си). Тем не менее, современная ситуация именно такова, и мы считаем полезным привести краткое описание основных особенностей языка CO2 [31-32, 70].

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

Имя любого объекта трактуется как указатель на значение этого объекта; разименование производится с помощью обычного оператора Си ‘*’. Доступ к значению объекта возможен только из метода его класса, если только при перечислении методов оператор ‘*’ не объявлен явно публичным.

Поддерживается операция порождения нового объекта указанного класса. В отличие от языка Си++ в CO2 невозможно совместить создание нового объекта с его инициализаций (понятие метода-конструктора начального значения объекта в CO2 не поддерживается). Для инициализации необходимо либо явно обратиться к соответствующему методу класса с указанием вновь созданного объекта (поддерживается соответствующий механизм «передачи сообщений», означающий на самом деле вызов функции), либо воспользоваться оператором ‘*’ и явно присвоить новое значение, если ‘*’ — публичный оператор для данного класса.

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

Основой манипулирования объектами, хранимыми в БД, является расширенное по сравнению с языком Си средство итерации. Итератор применим к значениям-множествам или спискам. Фактически он означает последовательное применение оператора-тела цикла ко всем элементам множества или списка. Если мы вспомним, что долговременно хранимому классу объектов неявно соответствут одноименное значение-множество с элементами-объектами данного класса, то становится понятно, что итератор языка CO2 обеспечивает явную навигацию в классах объектов. Единственное, что остается от привычных пользователям СУБД языков запросов, — это ограниченная возможность указания характеристик требуемых в цикле объектов (это делается путем использования оператора разименования и явного указания условий на атрибуты; конечно, для этого нужно, чтобы оператор ‘*’ был объявлен публичным в данном классе).

Разработчики O2 подчеркивают, что они умышленно сделали CO2 более бедным по возможностям, чем, например, язык Си++, потому что многое по части управления объектами берет на себя общий менеджер объектов системы, явно вызываемый из рабочей программы.

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

Беери [63] отмечает существование трех подходов. Первый подход

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

Второй подход основывается на построении полного логического объектно-ориентированного исчисления. По поводу построения такого исчисления имеются теоретические работы (например, [101]), но законченный и практически реализованный язык запросов нам неизвестен. Видимо, к этому же направлению строго теоретически обоснованных языков запросов можно отнести и работу Леллани и Спиратоса [68], основанную на алгебраической теории категорий.

Наконец, третий подход основывается на применении дедуктивного подхода. В основном это отражает стремление разработчиков к сближению направлений дедуктивных и объектно-ориентированных БД. Примером простого дедуктивного объектно-ориентированного языка запросов может служить [82].

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

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

Язык запросов системы Iris [8, 20] находится в значительной степени под влиянием реляционной парадигмы. Даже название этого языка OSQL отражает его тесную связь с реляционным языком SQL. По сути дела, OSQL — это реляционный язык, расчитанный на работу с ненормализованными отношениями. Естественно, при таком подходе в OSQL нарушается инкапсуляция объектов.

На наш взгляд, особый интерес представляет декларативный язык запросов системы O2 RELOOP [74]. В общих словах, это декларативный язык запросов с SQL-ориентированным синтаксисом, основанный на специально разработанной для модели O2 алгебре объектов и значений. (Кстати, это не единственная работа в направлении построения алгебры для объектно-ориентированных моделей данных. См., например, [76].) На наш взгляд, особенно впечатляющим качеством языка RELOOP является естественность его построения в общем контексте модели O2. Запрос задается всегда на значении-множестве или списке. Если мы вспомним, что долговременному классу в O2 соответствует одноименное значение-множество, то тем самым можно определить запрос на любом хранимом классе. Результатом запроса может являться объект, значение-множество или значение-список. При этом элементами значений-множеств могут являться объекты (простая выборка), либо значения-кортежи с элементами-объектами разных классов (например). В совокупности эти особенности языка позволяют формулировать запросы над несколькими классами (специфическое соединение, порождающее не новые объекты, а кортежи из существующих объектов), а также употреблять вложенные подзапросы.

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

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

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

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

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

В настоящее время ведется очень много экспериментальных и производственных работ в области объектно-ориентированных СУБД [12-47]. Больше всего университетских работ, которые в основном носят исследовательский характер. Но уже год назад отмечалось существование по меньшей мере тринадцати коммерчески доступных систем ООБД [10]. Среди них уже упоминавшиеся в нашем обзоре системы O2 (французский консорциум Altair) [29-32], ORION (американская компания MCC) [11-17], GemStone (американская фирма Servio Logic) [22-24] и Iris (Hewlett-Packard) [18-19]. К сожалению, по поводу многих коммерческих систем практически отсутствуют доступные публикации, но и имеющейся информации достаточно, чтобы охарактеризовать типовую организацию современной объектно-ориентированной СУБД.

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

Из числа архитектур с традиционной организацией наибольшее влияние на объектно-ориентированные СУБД оказали реляционные системы. Многие объектно-ориентированные системы (по крайней мере в прототипных вариантах) строятся над некоторой существующей реляционной СУБД [37, 45-46]. Кроме такого применения реляционных систем для упрощения разработки объектно-ориентированной СУБД, развитые в реляционных СУБД методы применяются и в заново разрабатываемых объектно-ориентированных системах.

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

Другой основой объектно-ориентированных СУБД являются так называемые расширяемые системы [48-51]. Основная идея таких систем состоит в поддержании набора модулей с четко оговоренными интерфейсами, на базе которого можно быстро построить СУБД, опирающуюся на конкретную модель данных или предназначенную для конкретной области применений. В частности, как показывает опыт системы EXODUS [48], средства расширяемых систем хорошо пригодны и для построения объектно-ориентированной СУБД.

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

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

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

Перейдем теперь к чисто объектно-ориентированным СУБД. Мы рассмотрим особенности организации двух таких систем — ORION [11-17] и O2 [29-32].

Проект ORION осуществлялся с 1985 по 1989 г. фирмой MCC под руковоством известного еще по работам в проекте System R Вона Кима. Под названием ORION на самом деле скрывается семейство трех СУБД: ORION-1 — однопользовательская система; ORION-1SX, предназначенная для использования в качестве сервера в локальной сети рабочих станций; ORION-2 — полностью распределенная объектно-ориентированная СУБД. Реализация всех систем производилась с использованием языка Common Lisp на рабочих станциях (и их локальных сетях) Symbolics 3600 с ОС Genera 7.0 и SUN-3 в среде ОС UNIX. Описание реализации ORION-2 пока не опубликовано, поэтому мы рассмотрим только ORION-1 и ORION-1SX.

Основными функциональными компонентами системы являются подсистемы управления памятью, объектами и транзакциями. В ORION-1 все компоненты, естественно, располагаются в одной рабочей станции; в ORION-1SX — разнесены между разными рабочими станциями (в частности, управление объектами производится в рабочей станции-клиенте). Применение в ORION-1SX для взаимодействия клиент-сервер механизма удаленного вызова процедур позволило использовать в этой системе практически без переделки многие модули ORION-1. Сетевые взаимодействия основывались на стандартных средствах операционных систем.

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

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

Подсистема управления транзакциями обеспечивает традиционную сериализуемость транзакций, а также поддерживает средства журнализации изменений и восстановления БД после сбоев. Для сериализации транзакций применяется разновидность двухфазного протокола синхронизационных захватов с различной степенью гранулированности [103]. Конечно, при синхронизации учитывается специфика ООБД, в частности, наличие иерархии классов. Журнал изменений обеспечивает откаты индивидуальных транзакций и восстановление БД после мягких сбоев (архивные копии БД для восстановления после поломки дисков не поддерживаются).

Проект O2 реализуется французской компанией Altair, образованной специально для целей проектирования и реализации объектно-ориентированной СУБД. Начало проекта датируется сентябрем 1986 г., и он был расчитан на пять лет: три года на прототипирование и два года на разработку промышленного образца. Текущий прототип системы функционирует в режиме клиент/сервер в локальной сети рабочих станций SUN c соответствующим разделением функций между сервером и клиентами.

Основными компонентами системы (не считая развитого набора интерфейсных средств) являются интерпретатор запросов и подсистемы управления схемой, объектами и дисками. Управление дисками, т.е. поддержание базовой среды постоянного хранения обеспечивает система WiSS [104], которую разработчики O2 перенесли в окружение ОС UNIX.

Наибольшую функциональную нагрузку несет компонент управления объектами. В число функций этой подсистемы входит:

— управление сложными объектами, включая создание и уничтожение объектов, выборку объектов по именам, поддержку предопределенных методов, поддержку объектов со внутренней структурой-множеством, списком и кортежем;

— управление передачей сообщений между объектами;

— управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

— отслеживание долговременно хранимых объектов (напомним, что в O2 объект хранится во внешней памяти до тех пор, пока достижим из какого-либо долговременно хранимого объекта);

— управление буферами оперативной памяти (аналогично ORION, представление объекта в оперативной памяти отличается от его представления на диске);

— управление кластеризацией объектов во внешней памяти;

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

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

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

Проблемы выполнения и оптимизации запросов к ООБД

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

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

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

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

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

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

Особенности управления транзакциями в системах ООБД

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

Какой-либо подход, в котором предлагался бы полный набор средств управления транзакциями, полностью согласующийся с парадигмой объектной ориентированностью, нам неизвестен. Одна из наиболее продвинутых работ, проводимых в этом направлении в рамках германского проекта VODAK, описывается в [93].

В основе управления транзакциями в системе VODAK находится разработанный ранее в контексте инженерных СУБД механизм транзакций со вложенными подтранзакциями [109]: вызов любого действия в объекте равносилен образованию новой подстранзакции. В отличие от традиционного механизма вложенных подтранзакций в данном случае заранее не определена максимальная вложенность транзакций. При синхронизации транзакций используется знание о семантике объектов, в том числе информация о коммутативности операций. (Аналогичный подход описан в [110].)

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

Связь ООБД с дедуктивными и активными базами данных

Связь направления ООБД с направлением дедуктивных БД носит двоякий характер. Во-первых, для структуризации дедуктивных (и вообще логических) БД в последнее время стремятся использовать парадигму объектной ориентированности [83-84]. Это отдельная тема, для ее рассмотрения было бы необходимо предварительное введение в концепции дедуктивных БД, что находится за пределами данного обзора.

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

Работы по интеграции объектно-ориентированных и активных БД находятся в начальной стадии. Известно, что основной проблемой систем активных БД является построение эффективного механизма вычисления на основе поступающих событий условий и вызова при необходимости соответствующих действий. В [42] описывается экспериментальная работа, выполненная на базе объектно-ориентированной СУБД PROBE, в которой активность ООБД обеспечивается с помощью определения двух специальных классов объектов «active-object» и «activelist-object». При возникновении одного из предопределенных в системе событий вызывается один из методов соответствующего объекта класса «active-object», в котором в зависимости от состояния и предписанного набора правил принимается решение о дальнейших действиях. Основной вывод, который можно сделать на основании изложенного в [42] материала, — это пригодность основных средств типовой ООБД и для обеспечения ее активности.

Заключение

В этом обзоре мы рассмотрели (очень кратко) далеко не все вопросы, связанные с ООБД. Совсем не были рассмотрены проблемы проектирования ООБД и вообще объектно-ориентированного проектирования БД [59], вопросы поддержания разнородной (multi-media) информации в ООБД [12], подходы к интеграции неоднородных БД на основе объектно-ориентированного подхода [87-88], проблемы поддержания различных представлений ООБД [89] и т.д.

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

Объекты и концепции базы данных

ОБЩАЯ ХАРАКТЕРИСТИКА СУБД MICROSOFT ACCESS 2000

2. Объекты БД и их размещение

2. ХАРАКТЕРИСТИКА БАЗЫ ДАННЫХ

2.1. Объекты БД, их хранение

СУБД Access ориентирована на работу с объектами БД, к которым относятся таблицы, запросы, формы, отчеты, страницы, макросы и модули.

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

Запрос — это требование на: отбор данных, хранящихся в таблицах; выполнение вычислений над данными; изменения в БД.

Форма — созданный на экране шаблон, используемый, главным образом, для ввода, просмотра и редактирования записей БД.

Отчет — отображение на принтере или на экране информации из БД в виде, удобном для ее восприятия и анализа пользователем.

Страница доступа к данным — диалоговая Web -страница, которая поддерживает динамическую связь с БД и позволяет просматривать, редактировать и вводить данные в базу, работая в окне браузера Internet Explorer 4.0 или Internet Explorer 5.0.

Макрос — есть последовательность макрокоманд для автоматизации выполнения операций в среде Access без программирования.

Модуль — это программа для работы с БД, написанная на языке Visual Basic for Applications 6.0 ( VBA ).

Объекты БД могут быть объединены в именованные группы объектов по функциональному или иному признаку.

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

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

2.2. Инструментальные средства для создания БД.

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

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL