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

 

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

 

• Инкапсуляция
• Наследование
• Полиморфизм

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

 

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

 

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

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

 

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

 

2. Анализ эффективности объектно-ориентированных баз данных

Преимущества объектно-ориентированных баз данных:

 

В объектно-ориентированных базах  данных, в отличие от реляционных, хранятся не записи, а объекты. ОО-подход представляет более совершенные  средства для отображения реального  мира, чем реляционная модель:

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

Недостатки объектно-ориентированных  баз данных:

 

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

 

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами:

 

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

 

3. Стандарт ODMG.

 

ODMG (Object Data Management Group) - консорциум поставщиков ООБД и других заинтересованных организаций, созданный в 1991 г. Его задачей является разработка стандарта на хранение объектов в базах данных. В настоящее время опубликована вторая версия стандарта, которую так и называют ODMG 2.0. Рассмотрим кратко основные положения этого документа.

Стандарт на хранение объектов ODMG 2.0 разработан на основе трех существующих стандартов: управление базами данных (SQL), объекты (стандарты OMG – Object Management Group) и стандарты на объектно-ориентированные языки программирования (C++, Smalltalk, Java).

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

Объектная модель

 

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

 

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

Язык описания объектов

 

Язык описания объектов (ODL - Object Defifnition Language) - средство определения схемы базы данных (по аналогии с DDL в реляционных СУБД). ODL является расширением IDL (Interface Definition Language - язык описания интерфейсов) модели OMG и предоставляет средства для определения объектных типов, их атрибутов, связей и методов. ODL создает слой абстрактных описаний так, что схема базы данных становится независима как от языка программирования, так и от СУБД. ODL рассматривает только описание объектных типов данных, не вдаваясь в детали реализации их методов. Это позволяет переносить схему БД между различными ODMG-совместимыми СУБД и языками программирования, а также транслировать ее в другие DDL.

Язык объектных запросов

 

Язык объектных запросов (OQL - Object Query Language) - SQL - подобный декларативный  язык, который предоставляет эффективные  средства для извлечения объектов из базы данных, включая высокоуровневые  примитивы для наборов объектов и объектных структур. Синтаксис оператора SELECT, определенный SQL-92, является подмножеством OQL, это гарантирует, что SELECT- утверждения, выполняемые над реляционными таблицами, сохранят работоспособность и с наборами объектов ODMG. OQL-запросы могут вызываться из ОО-языка, точно также из OQL-запросов могут делаться обращения к процедурам, написанным на OO-языке. OQL предоставляет средства обеспечения целостности объектов (вызов объектных методов и использование собственных операторов изменения данных).

Связывание с ОО-языками

 

Связывание с ОО-языками. Стандарт связывания с C++, Smalltalk и Java определяет Object Manipulation Language (OML) - язык манипулирования  объектами, который расширяет базовые  ОО-языки средствами манипулирования и хранения объектов. Также включаются OQL, средства навигации и поддержка транзакций. Каждый ОО-язык имеет свой собственный OML, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программирования и доступа к данным.

 

4. Объектные расширения реляционных СУБД. Язык SQL-3.

 

Попытки совместить средства манипулирования  данными реляционной модели и  способы описания внешнего мира объектно-ориентированной  модели получили развитие в языке SQL-3. Здесь мы рассмотрим только предлагаемые способы определения данных.

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

 

Create type Address (	number	char (6),
	street	char (30),
	aptno	integer,
	city	char (30),
	state	char (2),
	Zip	integer);

 

На основе нового типа могут быть определены таблицы, например:

 

Create table Addresses of Address;

 

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

 

10. Базы знаний

 

1. Понятие системы баз знаний.

 

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

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

Это соответствует и точному  переводу английского названия таких  систем - Knowledge Based Systems (KBS) - система, базирующаяся на знаниях.

 

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

 

2. Структура системы базы знаний

Компоненты Системы баз знаний (СБЗ):

 

• база знаний
• механизм получения решений
• интерфейс

 

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

Примеры запросов:

 

• найти объект, удовлетворяющий заданному условию;
• какие действия нужно выполнить в такой ситуации и т.д.

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

 

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

Экстенсиональная и интенсиональная части базы данных

 

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

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

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

 

 

 

3. Активные базы данных

 

По определению БД называется активной, если СУБД по отношению к ней выполняет  не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД.

Легко видеть, что основа этой идеи содержалась в языке SQL времени System R. На самом деле, что есть определение  триггера или условного воздействия, как не введение в БД правила, в соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то, что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не полностью понятна.

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

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

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

4. Дедуктивные базы данных

 

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

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