7 многомерная и объектно ориентированная модели данных. Объектно-ориентированная модель баз данных

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

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных).

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

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

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

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа Каталог добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов Абонент и Каталог. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга, являющимся потомками объекта типа Каталог, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свойств всеми дочерними объектами Абонент, Книга и Выдача. Не случайно поэтому значения свойства билет классов Абонент и Выдача, показанных на рис. 2.9, являются одинаковыми - 00015.

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

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

Рис. 2.9 Логическая структура БД библиотечного дела

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

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

К объектно-ориентированным СУБД относятся POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

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

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

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

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

1. Разработка банков данных состоит из 4-х этапов:

1этап. Формирование и анализ требований к системе:

Составляется спецификация системы, включающая список задач, которые должен решать БнД;

Перечень конечных пользователей и их функций;

Перечень требований к БД;

Составляется схема документооборота в организации.

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

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

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

2. Основные задачи, решаемые персоналом банка данных

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

Перечислим основные функции и задачи, решаемые персоналом при разработке и эксплуатации базы данных:

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

2) проектирование структуры базы данных (определение состава и структуры файлов БД, описание ее схемы на языке описания данных);

3) задание ограничений целостности БД;

4) загрузка и ведение БД (к ведению БД относится изменение, удаление и добавление записей); разработка технологии загрузки и ведения; разработка форм ввода данных; ввод и контроль данных;

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

6) обеспечение восстановления БД;

7) анализ эффективности БнД и развитие системы;

8) работа с пользователями (сбор откликов, обучение);

9) сопровождение системного программного обеспечения (приобретение, установка и развитие);

10) организационно-методическая работа (выбор методов проектирования и модернизации, планирование развития БнД, разработка документации).

3. Пользователи банков данных

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

Проектирование,

Реализация,

Поддержка,

Обновление и разработка,

Полная реорганизация.

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

Конечные пользователи

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

Администраторы банка данных

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

Разработчики и администраторы приложений

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

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

Рассмотрим их более детально.

Часть группы администратора БнД должна быть:

Системные комментаторы;

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

Разработчики технологических процессов обработки данных;

Системные и прикладные программисты;

Действующие компании и эксперты в ремонтной службе.

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

Основные функции группы администраторов БД

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

2. Разработка строения БД: определение сочинения и строение файлов БД и связи промежуточный, выбор методов оптимизации данных и методов доступа для информации, описания БД на языке описания данных (ЯОД).

3. Задание ограничений целостности в описании структуры БД и процедурах обработки БД:

Задание декларативных ограничений целостности, свойственной от области данных;

Определение динамичных ограничений целостности, свойственной от области данных в ходе изменения информации, хранившей в БД;

Определение ограничений целостности вызывается строением БД;

Разработка процедур поддержки целостности БД при вводе и корректировке данных;

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

4. Инициирование загрузки и руководство БД

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

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

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

5. Предохранение данных

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

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

Разработка средств фиксации доступа к данным и попыткам нарушения системы защиты;

Тестирование системы защиты;

Исследование случаев нарушения системы защиты и разработки динамичных методов предохранения информации в БД.

6. Поддержка восстановления БД

Разработка организационных означает архивирования и принципы восстановления БД;

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

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

8. Исследование эффективности функционирования БнД:

Исследование индексов функционирования БнД

Планирующая перестройка структуры (структурное изменение) БД и реорганизация БнД.

9. Работа с конечными пользователями:

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

Сбор информации об оценке работ БнД;

Тренировка потребителей, консультация потребителей;

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

10. Приготовление и поддержка системных средств:

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

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

Проверка работоспособности искупленного матобеспечения перед их соединением с БнД;

Контроль соединения нового матобеспечения к БнД.

11. Организационно-систематическая работа при разработке БнД:

Выбор или создание метода разработки БД;

Определение целей и направление разработки системы в целом;

Планирование стадий развития БнД;

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

Монтаж внешних моделей разработанных приложений;

Контроль соединения нового приложения к работе БнД;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандартная ООМ описана в рекомендациях стандарта ODMG-93 (Object Database Management Group – группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

Структура ОО БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class).

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

Пример логической структуры ОО БД библиотечного дела приведен на рис. 3.14. Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор .

Рис.3.14. Логическая структурабазы данныхбиблиотечного дела

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

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к ООМ БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов АБОНЕНТ и КАТАЛОГ. Смысл такого свойства будет определяться тем объектом, в котором оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся потомками объекта типа КАТАЛОГ, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковыми – 00015.

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

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

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

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

Рис.3.15. Фрагмент базы данных с объектом-целью

Вновь обратимся к задаче Заказы, представленной в виде реляционной модели данных на рис. 3.8, и рассмотрим ее в терминах объектно-ориентированной базы данных. Всего в примере три класса: «Клиенты », «Заказы » и «Товары ». Объектами класса «Клиенты » являются конкретные клиенты; свойства класса - № клиента, Имя клиента Город, Статус и т.п. Методы класса – «Создать заказ », «Оплатить счет » и т.п. Метод – это некоторая операция, которую можно применить к объекту; метод – это то, что должен делать объект. Класс, соответствующий таблице «Сведения о заказе », не требуется. Данные таблицы могут быть частью класса «Заказы ». Наличие в классе «Клиенты » метода «Создать заказ » приводит к взаимодействию с объектами классов «Заказы » и «Товары ». При этом пользователю не надо знать об этом взаимодействии объектов. Пользователь лишь обращается к объекту «Заказы » и использует метод «Создать заказ ». Факт воздействия на другие базы данных может быть скрыт от пользователя. Если метод «Создать заказ », в свою очередь, обращается к методу «Проверить кредитоспособность клиента », то этот факт также может быть скрыт от пользователя. В реляционных базах данных для выполнения тех же функций требуется писать процедуры на языке Visual Basic for Application (VBA).

В 90-е годы существовали экспериментальные прототипы ОО систем управления базами данных. В настоящее время такие систем получили широкое распространение. В частности, к ним относятся следующие СУБД: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (научно-производственный центр «Интелтек Плюс»), а также Iris, Orion и Postgres.

Введение

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

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

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

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

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

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

встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;

расширение существующего языка работы с базами данных объектно-ориентированными функциями;

создание объектно-ориентированных библиотек функций для работы с БД;

создание нового языка и новой объектно-ориентированной модели данных.

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

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

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

Стандартная ООМ описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

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

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

Стандартизованная объектно-ориентированная модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group – Группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрошенную модель объектно-ориентированной БД.

Структура объектно-ориентированной БД (например, Versant Object Database, Object Store и др.) графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым – string) или типом, конструируемым пользователем (определяется как class).

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект – экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект – экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.

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

Ограниченно могут применяться операции, подобные командам языка SQL (например, для создания БД).

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта.

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

Типы данных

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

числовые. Примеры значений данных: 0,43; 328; 2Е+5;
символьные (алфавитно-цифровые). Примеры значений данных: "пятница", "строка", "программист";
даты, задаваемые с помощью специального типа "Дата" или как обычные символьные данные. Примеры значений данных: 1.12.97, 23/2/1999.

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

временны́е и дата-временны́е, предназначенные для хранения информации о времени и (или) дате. Примеры значений данных: 31.01.85 (дата), 9:10:03 (время), 6.03.1960 12:00 (дата и время);
символьные переменной длины, предназначенные для хранения текстовой информации большой длины, например документа;
двоичные, предназначенные для хранения графических объектов, аудио- и видеоинформации, пространственной, хронологической и другой специальной информации. Например, в MS Access таким типом является тип данных "Поле объекта OLE", который позволяет хранить в БД графические данные в формате BMP (Bitmap) и автоматически их отображать при работе с БД;
гиперссылки (hyperlinks), предназначенные для хранения ссылок на различные ресурсы (узлы, файлы, документы и т.д.), находящиеся вне базы данных, например в сети Интернет, корпоративной сети интранет или на жестком диске компьютера.

В современных СУБД с различными моделями данных могут использоваться все перечисленные типы данных.