Лекция 2. Введение в теорию баз данных

Лекция 2. Введение в теорию баз данных

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

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

Основные понятия

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

Можно выделить три свойства, которые отличают БД от простой совокупности данных:

1.       БД хранится и обрабатывается в вычислительной системе.

2.       Данные в БД хорошо структурированы, т.е. выделены основные элементы, их типы и связи между элементами, а также ограничения на допустимые операции.

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

Наиболее распространенным типом БД являются реляционные базы данных. Рассмотрим основные структурные элементы реляционной БД:

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

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

3.       Собственно таблица (отношение).

Система баз данных

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

Различают однопользовательские и многопользовательские системы.

Однопользовательская система (Single-user system) – это система, в которой в одно и то же время к БД может получить доступ только один пользователь.

Многопользовательская система (Multi-user system) – это система, в которой в каждый момент времени к БД могут получить доступ несколько пользователей. Основная задача такой системы – позволить пользователю работать с БД как с однопользовательской.

Обычно в СБД выделяют четыре основных элемента:

1.  Данные.

2.  Аппаратное обеспечение.

3.  Программное обеспечение (ПО).

4.  Пользователи.

Упрощенная схема СБД представлена на рис. 1.1.

Рис. 1.1. Элементы системы баз данных

Данные

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

Аппаратное обеспечение

К нему относятся:

·     накопители для хранения информации вместе с устройствами ввода/вывода;

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

Программное обеспечение

Основная часть ПО – это система управления базами данных, СУБД (DBMS – DataBase Management System – диспетчер БД).

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

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

Пользователи

Различают три группы пользователей СБД:

1.       Прикладные программисты. Для целей разработки прикладных программ, которые используют базы данных, применимы различные языки и среды программирования: Visual Basic, C++, Java, C# и другие. Прикладные программы получают доступ к базе данных посредством выдачи соответствующего запроса к СУБД (обычно это операторы SQL).

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

3.       Администраторы БД. Занимаются управлением работы сервера БД.

Организация данных в БД

В базе данных выделяют следующие элементы:

·     данные;

·     объекты;

·     связи;

·     свойства.

Данные

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

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

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

Объекты

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

Связи

Связи отображают зависимости между объектами. Как правило, они бывают двусторонними. Допустим, есть два объекта Students и Groups, по связи между ними можно ответить на два вопроса:

1)    какой группе принадлежит данный студент;

2)    какие студенты входят в данную группу.

Схема, на которой представлены объекты и их связи, называется Схема объект-отношение или Диаграмма объект-отношение (рис. 1.2.).

Рис. 1.2. Связь между таблицами Students и Groups

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

Свойства

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

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

Ядром любой БД является модель данных. Модель данных – это совокупность структуры данных и операций их обработки.

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

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

·     каждый узел связан только с одним вышестоящим узлом, кроме вершины;

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

·     от каждого узла существует единственный путь к вершине;

·     связь не может быть установлена между объектами, находящимися через уровень;

·     связь между узлами первого уровня не определяется.

Примеры.

1)      Файловая структура организации информации.

2)      Структура организации (директор, заместитель, руководители отделов, сотрудники) (рис.1.3).

Рис. 1.3. Иерархическая структура данных

Преимущества:

1.     Простота.

2.     Минимальный расход памяти.

Недостатки:

1.       Отсутствие универсальности – не всякую информацию можно выразить в иерархической модели данных.

2.       Исключительно навигационный принцип доступа к данным.

3.       Доступ к данным только через корневой элемент.

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

Свойства сетевой модели:

·     связь не может быть установлена между объектами, находящимися через уровень;

·     связь между узлами первого уровня не определяется.

Пример. Рассмотрим работу над проектами: можно выделить три вида объектов – сотрудники, проекты, заказчики (рис.1.4).

Рис. 1.4. Сетевая структура данных

Преимущества:

1.       Универсальность.

2.       Возможность доступа к данным через значения нескольких отношений.

Недостатки:

1.       Сложность – обилие понятий, вариантов их взаимосвязей и способов реализации.

2.       Допустимость только навигационного принципа доступа к данным.

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

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

·     пользователю предоставляются операторы, генерирующие новые таблицы из старых (для выборки данных).

Пример. Рассмотрим отношения Студенты и Группы:

Students:

StudentID	LastName	FirstName	MiddleName	GroupID
1	Казаков	Петр	Владимирович	1
2	Васильев	Иван	Аркадьевич	2
4	Шишкина	Дарья	Сергеевна	1

Groups:

GroupID	Supervisor
1	Царев С.М.
2	Пестов Д.Н.

Преимущества:

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

2.       Теоретическое обоснование. Существуют строгие методы нормализации данных в таблицах (будет подробно рассмотрено в лекциях 10-11).

3.       Независимость данных. При изменении БД, ее структуры необходимы бывают лишь минимальные изменения прикладных программ.

Недостатки:

1.       Низкая скорость, т.к. требуются операции соединения.

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

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

Пример. Рассмотрим объекты Сотрудники и Зарплата.

Сотрудники:

Сотрудник	Должность
01 Иванов	программист
02 Сидоров	лаборант
03 Шишкин	преподаватель
04 Васильев	преподаватель

Зарплата:

Сотрудник	Дата	Сумма
05 Иванов	1.10.2008	5000
06 Сидоров	5.10.2008	7500
07 Иванов	3.12.2008	10000
08 Шишкин	3.12.2008	8000
09 Васильев	25.01.2009	5000
10 Васильев	27.01.2009	8750

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

Пример: инвертированный список Должность:

·     программист – 01;

·     лаборант – 02;

·     преподаватель – 03, 04

Список связей составляется только по основным столбцам.

Пример: рассмотрим два списка связей:

·     Сотрудники – Зарплата:

o  01 – 05, 07

o  02 – 06

o  03 – 08

o  04 – 09, 10

·     Зарплата – Сотрудники:

o  05 – 01

o  06 – 02

o  07 – 01

o  08 – 03

o  09 – 04

o  10 – 04

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

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

Архитектура БД

Существует архитектура БД, предложенная исследовательской группой ANSI/SPARC[1] и называется архитектурой ANSI/SPARC.

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

Принято выделять три уровня в архитектуре СУБД.

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

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

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

Подробная схема архитектуры системы баз данных представлена на рис. 1.5.

Рис. 1.5. Уровни архитектуры систем баз данных

Классификация БД

Базы данных классифицируют по различным признакам, рассмотрим основные из них.

1.     По технологии обработки.

·        Централизованные. Хранятся в памяти одной вычислительной системы.

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

2.     По способу доступа к данным.

·        С локальным доступом. Характеризуется тем, что к такой БД имеется доступ пользователя одной ЭВМ.

·        С удаленным (сетевым) доступом. Доступно для всех пользователей сети.

3.     По архитектуре.

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

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

4.     По содержимому.

·        Географические.

·        Исторические.

·        Научные.

·        Мультимедийные.

·        и т.д.

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

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

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

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

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

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

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

o    определение данных;

o    определение представлений;

o    обработку данных;

o    условия целостности;

o    идентификация прав доступа;

o    границы транзакций (начало, завершение и отмена).

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

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

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

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

Ограничения реляционных баз данных.

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

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

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

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

Первые работы, в которых отмечались эти и ряд других недостатков, появились уже в начале 80-х годов. Одна из наиболее ярких статей была опубликована в 1990 г. - Системы баз данных третьего поколения: Манифест. Вслед за первым манифестом последовали Манифест систем объектно-ориентированных баз данных. (М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С.Здоник, СУБД № 4 1995) и Третий манифест (Х.Дарвин, К.Дэйт, СУБД № 1 1996).

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

---

Литература:

• Д.Васкевич Кризис баз данных и проблема выбора: повестка дня до 2001 года. СУБД N1, 1995
• С.Д.Кузнецов Направления исследований в области управления базами данных: краткий обзор. СУБД N 1, 1995
• А.Зильбершатц, М.Стоунбрейкера, Дж.Ульман Базы данных: достижения и перспективы на пороге 21-го столетия. СУБД N 3, 1996

Постреляционные СУБД.

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

---

Литература:

• Т.В. Грачева ADABAS - основа технологий SOFTWARE AG. СУБД N 2 1995
• Л.Л. Винокуров, Д.В. Леонтьев, А.Ф. Гершельман СУБД ADABAS - основа универсального сервера баз данных. СУБД N2, 1997
• Т.Г. Лаврентьева, И.Г. Шабаев UNIVERSE - Развитие реляционных стандартов. СУБД N 2 1995
• Е.К. Ким, И.Г. Шабаев, В.А. Бычков Проектирование трехмерных баз данных в СУБД uniVerse. СУБД N 3 1996
• Д.Рамодин Многомерный мир базы данных. Мир ПК, N 3, 1997

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

Термин "объект" в программной индустрии впервые был введен в языке Simula (1967 г.) и означал какой-либо аспект моделируемой реальности. Сейчас под объектом понимается "нечто, имеющее четко определенные границы" (определение известного американского специалиста Г.Буча). Объекты, обладающие одинаковыми свойствами, составляют классы (например, курица, пингвин и чайка - объекты класса "птицы"). Обычно класс описывается как новый тип данных, а объекты (экземпляры класса) - определенные на его основе переменных.

---

6.3.1.Объектно-ориентированная парадигма.

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

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

·           Class Point {              // вводим новый тип данных - объект "точка"

·              X,Y : int;                // данные объекта - координаты точки

·              .........

·              Point(X : int, Y : int);  // конструктор объекта - процедура, вызываемая при 

·                                        // определении переменной на базе объекта и 

·                                        // присваивающая значения его данным

·              .........

·              Draw();                   // метод "нарисовать точку"

·              Erase();                  // метод "стереть точку"

·              Move(newX,newY);          // метод "переместить точку" (изменяет данные объекта)

·              int GetX();               // метод "получить значение поля X"

·              int GetY();               // метод "получить значение поля Y"

·              .........

·                                        // все методы должны быть описаны, например

·                                        // реализация метода Move:

·              

·              Move(newX : int, newY : int) {

·                X=newX;                 // запись новых данных в объект

·                Y=newY;                 //

·              }

·            }                           // конец описания объекта

·          

·            Begin                       // основная процедура программы

·          

·              Point A(0,0);             // создать новый объект и присвоить ему данные

·          

·              for i=1 to 100            // создать цикл

·                  A.Draw();             // нарисовать точку 

·                  A.Hide();             // стереть точку

·                  A.Move(i,i*10);       // присвоить экземпляру объекта новые данные

·              endfor;                   // 

·          

·              print(A.GetX(),A.GetY()); // получить и напечатать данные объекта

·          

   End.

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

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

·           Class Circle extend Point {   // создаем новый объект "окружность", наследующий

·                                           // свойства объекта "точка"

·           Radius : int;                   // добавляем новое поле "радиус", поля X и Y наследуются

·                                           // от родительского объекта

·           .............

·           Circle(X:int,Y:int,Radius:int); // конструктор нового объекта

·           .............

·           Draw();                         // переопределяем некоторые методы

·           Hide();                         // родительского объекта, метод Move наследуется

·           .............

·           ChangeRadius(Radius);           // вводим новый метод "изменить радиус"

·           .............

·           GetRadius();                    // вводим новый метод "получить значение радиуса"

·                                           // методы GetX и GetY наследуются от родительского

·                                           // объекта

  }

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

·          Begin

·           Point A(100,100);

·           Circle B(200,200,50);

·          

·           A.Draw();        // рисует точку

·           B.Draw();        // рисует окружность

 End.

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

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

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

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

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

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

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

---

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

Появление объектно-ориентированных СУБД вызвано потребностями программистов на ОО-языках, которым были необходимы средства для хранения объектов, не помещавшихся в оперативной памяти компьютера. Также важна была задача сохранения состояния объектов между повторными запусками прикладной программы. Поэтому, большинство ООСУБД представляют собой библиотеку, процедуры управления данными которой включаются в прикладную программу. Примеры реализации ООСУБД как выделеного сервера базы данных крайне редки.
В качестве примера рассмотрим объектно-ориентированную СУБД ObjectStore, которая обеспечивает долговременное хранение в базе данных объектов, созданных программами на языках C++ и Java. Вся работа с объектами ведется обычными средствами включающего ОО-языка. При этом СУБД как бы расширяет виртуальную память операционной системы. Происходит это следующим образом. Когда прикладная программа обращается к объекту, то ищет его по адресу в оперативной памяти. Нужная страница оперативной памяти может быть вытеснена в виртуальную память (область хранения неиспользуемых страниц оперативной памяти на диске). Если объекта с таким адресом в виртуальной памяти не существует, то операционная система генерирует ошибку. СУБД эту ошибку перехватывает и извлекает объект из базы данных.
ObjectStore поддерживает транзакции (в данный момент времени может существовать только одна транзакция), допускает методы доступа: хеш-таблица для несортированных данных и B-дерево для сортированных, также возможно использование SQL.
Бесплатную копию ObjectStore можно получить с веб-сервера компании Object Design Inc.

---

6.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 (см. параграф 6.3.1) за счет введения таких свойств как связи и транзакции для обеспечения функциональности, требуемой при взаимодействии с базами данных. Ключевые концепции объекной модели 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, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программмирования и доступа к данным.

Более подробно содержание стандарта ODMG (более ранней его версии) рассмотрено в статье Л.А.Калиниченко Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния. СУБД N 1, 1996.

---

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

Попытки совместить средства манипулирования данными реляционной модели и способы описания внешнего мира объектно-ориентированной модели получили развитие в языке SQL-3. (см. статью Д.Бича К объектным базам данных, опубликованную в журнале "Открытые системы" N 4 за 1994 г.). Здесь мы рассмтотрим только предлагаемые способы определения данных.
Разработчики 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;

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

      Сreate table People of new type Person (

             name char (30),

             address Address,

             birthdate date,

      );

Наследование определяется с помощью фразы under.

     Create type Employee under Person (

         empno char(10),

         dept ref(Department)

     );

Здесь атрибут dept является ссылкой на объект, хранящийся в таблице Department. Т.е. в понятиях реляционной модели в этом столбце должен быть записан внешний ключ, указывающий на на одну из строк таблицы Department. На самом деле, в SQL-3 предполагается, что каждый объект имеет уникальный идентификатор - OID, именно он используется при создании ссылок на объекты.

Также в операторе CREATE TABLE можно определить и методы доступа к вновь созданным типам данных:

 Create table People of new type Person (

     name char(30),

     address Address,

     birthdate date

     function age(:р ref(Person)) return date;

     begin

        current_age:=:р.birthdate-current_date;

        return current_age;

     end;

 );

В этом примере задана функция age, которая вычисляет текущий возраст объекта типа Person, хранимого в таблице People. К данной функции можно обращаться из оператора SELECT.

Здесь свойства SQL-3 рассмотрены весьма кратко. Более полное представление о них можно получить из указанной статьи Д.Бича, а также из литературы, посвященной возможностям СУБД Oracle 8, которая подерживает данный язык.
Заметим, что К.Дейт придерживается мнения, что областью определения объекта надо считать не строку, а столбец реляционной таблицы. Подробнее об этом см. в его книге.
Еще один подход к объединению свойств реляционной модели и объектно-оринетированного программирования обсуждается в следующем параграфе.

---

Литература:

• М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С.Здоник Манифест систем объектно-ориентированных баз данных. СУБД N 4, 1995
• А. Ю. Медников Объектно-ориентированные базы данных сегодня или завтра? Открытые системы N 4, 1994
• Ким Вон Технология объектно-ориентированных баз данных. Открытые системы N 4, 1994
• В. Пржиялковский Новые одежды знакомых СУБД: Объектная реальность, данная нам. СУБД N4, 1997
• С. Кузнецов Объектно-ориентированные базы данных - основные концепции, организация и управление: краткий обзор.

Объектно-реляционные СУБД.

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

1.     Типы, операторы и методы доступа, определяемые пользователем. Вспомним пример с земельными участками из главы 6.1. Для решения этой задачи мы можем определить новый тип данных "участок", необходимые операции над ним (например, вычисление площади), а также метод доступа, поскольку с помощью B-дерева нельзя выполнить двумерный поиск в задаче о перекрывающихся многоугольниках. Здесь целесообразно использовать дерево более высокой размерности (R-дерево) или другие методы.

2.     Поддержка сложных объектов, представляющих собой наборы других объектов.

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

SELECT владелец FROM участки WHERE расположение_участка IN заданная_область

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

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

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

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

Реализация описанных свойств позволила М.Стоунбрейкеру так спозиционировать объектно-реляционные СУБД относительно реляционных и объектно-ориентированных систем:

	Простые данные	Сложные данные
Наличие средств запросов	Реляционные системы	Объектно-реляционные системы
Отсутствие средств запросов	Файловые системы	Объектно-ориентированные системы

Кроме того, Postgres обладает свойствами, которые позволяют назвать его темпоральной СУБД. При любом обновлении записи создается ее новая копия, а предыдущий вариант продолжает существовать вечно. Даже после удаления записи все накопленные варианты сохраняются в базе данных. Можно извлечь из базы данных любой вариант записи, если указать момент или интервал времени, когда этот вариант был текущим. Достижение этих свойств позволило также пересмотреть схемы журнализации и отката транзакций.
Сейчас все вышеописанные функции развиваются в коммерческой СУБД Informix. Тем не менее, проект Postgres продолжается до сих пор, уже международной группой независимых разработчиков. К возможностям СУБД добавлены поддержка SQL (в перспективе планируется обеспечение совместимости со стандартом ANSI SQL-92), поэтому несколько было изменено название СУБД - теперь это PostgreSQL, оптимизатор запросов на основе генетических алгоритмов и многое другое. При этом PostgreSQL остается свободно распространяемой системой, причем бесплатно можно получить как исходный код, так и бинарные файлы, собранные для той или иной платформы (поддерживаются практически все разновидности ОС Unix). Более подробная информация находится на сервере www.postgresql.org.

---

Литература:

• М. Стоунбрейкер Объектно-реляционные системы баз данных. Открытые Системы N 4 1994
• Е. Булах Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95. СУБД N 2, 1997
• 
  

---

[1] ANSI/SPARC (American National Standards Institute / Standards Planning and Requirements Committee – Американский национальный институт стандартов / Комитет планирования стандартов) – исследовательская группа в рамках Американского национального института стандартов. Архитектура ANSI/SPARC была предложена в 1975 году.