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

Бойко И. Объектно-ориентированные СУБД. Оглавление 1. 20 лет эволюции программного обеспечения. 2. Реляционные базы данных. 3. Объектно-реляционные методы. 4. Объектно-ориентированные базы данных. 4.1 Why ODBMS 4.2 Спорные моменты технологии. 4.3 Стандарты объектных баз данных. 4.4 Поставщики ООСУБД. 5. Заключение. 6. Глоссарий 1. 1. 20 лет эволюции программного обеспечения. Рисунок 1 Управление информацией всегда было основной сферой применения компьютеров и, надо думать, будет играть еще большую роль в будущем.

Системы управления базами данных Термины, выделенные курсивом, как правило, приведены в словарике на стр. 21 СУБД, DBMS Database Management System на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами.

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

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

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

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

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

Это позволяет обойтись без декомпозиции графических структур на элементы и записи их в файлы после завершения работы с чертежом, выполнения обратной операции при внесении любого изменения. Если типичные реляционные базы данных имеют связи глубиной в два уровня, то иерархическая информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для сборки результата. Объектные базы данных хорошо соответствовали подобным задачам, и эволюция многих СУБД началась именно с рынка САПР. Между тем рынок САПР был быстро насыщен, и в начале 90х годов производители ООСУБД обратили внимание на другие области применения, уже прочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями оперативной обработки транзакций OLTP, утилитами администратора баз данных database administrator DBA, средствами резервного копированиявосстановления и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно сказать, что переход к коммерческим приложениям идет достаточно успешно. 2. Реляционные базы данных. В реляционных базах данных Relational Database System, RDBS все данные отображаются в двумерных таблицах.

База данных, таким образом, это ни что иное, как набор таблиц.

RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации Indexed Sequential Access Method ISAM и являются стандартными системами, использующимися в большинстве современных программных продуктов.

Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL IBM, Quel Ingres и RDO Digital Equipment, причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД. Оригинальная версия SQL это интерпретируемый язык, предназначенный для выполнения операций над базами данных.

Язык SQL был создан в начале 70х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные и не только реляционные системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 или SQL-92, включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.

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

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

Такой подход сильно усложняет создание сколько нибудь сложных взаимосвязей в базе данных. Желающим убедится, что это действительно так и не пожалевшим на это определенный отрезок времени, компания POET Software любезно предоставляет возможность ознакомиться с примером в своей белой книге POET Technical Reference. База данных рядового предприятия общепита клиенты Джордж Буш и Эдди Мэрфи состоит из четырех таблиц. Еще один крупный недостаток реляционных баз данных это высокая трудоемкость манипулирования информацией и изменения связей. 3. Объектно-реляционные методы. Несмотря на рассмотренные в п. 2 недостатки реляционных баз данных, они обладают рядом достоинств разделение таблиц разными программами развернутый код возврата при ошибках высокая скорость обработки запросов команда SELECT языка SQL результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию Рисунок 2 Возможные подходы к объединению объектных и реляционных БД. сама концепция объектных баз данных довольно сложна и требует от программистов серьезного и длительного обучения относительно высокая скорость при работе с большими объемами данных.

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

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

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

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

Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут сами выполнять роль мощного объектно-реляционного адаптера, позволяя объектно-ориентированным приложениям обращаться к реляционным БД. Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например в качестве связующего ПО, объединяющего объектно-ориентированные приложения с реляционными СУБД. Объектно-реляционные шлюзы.

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

Каждая РСУБД состоит из двух уровней уровня управления данными data manager layer и уровня управления носителем storage manager layer. Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать как с уровнем данных то есть обращаться к РСУБД при помощи SQL, так и с уровнем носителя вызовами процедур низкого уровня.

Производительность в первом случае намного ниже например, система OpenODB фирмы Hewlett-Packard, которая может выполнять роль шлюза, поддерживает только на высоком уровне. Гибридные СУБД. Еще одним решением может стать создание гибридных объектно-реляционных СУБД, которые могут хранить и традиционные табличные данные, и объекты. Многие аналитики считают, что будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД начинают или планируют добавлять к своим продуктам объектно-ориентированные средства.

В частности, Sybase и Informix собираются в следующих версиях СУБД ввести поддержку объектов. Подобные разработки намерены вести и независимые фирмы. Например, компания Shores готовится оснастить объектно-ориентированными средствами СУБД Oracle8, выпуск которой намечен на конец 1996 г. С другой стороны, производители объектных СУБД, такие как компания Object Design, сознают, что объектно-ориентированные базы данных в обозримом будущем не заменят реляционные СУБД. Это вынуждает их создавать шлюзы для поддержки реляционных и иерархических баз данных иди различного рода интерфейсы, характерным примером которых является объектно-реляционный интерфейс Ontos Integration Server фирмы Ontos, применяемый в сочетании с ее ООБД OntosDB. 4. Объектно-ориентированные базы данных. 4.1

Why ODBMS

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

Спорные моменты технологии

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

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

Сразу заметим, что установление стандартов лишает производителя в неко... В книгу ODMG-93 входят следующие разделы Язык определения объектов Obj... В качестве языка определения объектов ODL ODMG был выбран существующий... При перегрузке оператора new оба типа экземпляров могут создаваться от... Стандарты OMG.

Поставщики ООСУБД

Поставщики ООСУБД. Рисунок 6 Современный рынок СУБД. СУБД GemStone корпорации GemStone Systems, Inc. Itasca O2 Technology O2 и некоторые другие компании. 5.

Заключение

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

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

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

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

Глоссарий

RDBMS Relational Database Management System Реляционная СУБД СУБД, хра... Белая книга White Paper Официальное издание. также объектно-реляционные методы 2. Этого определения я старался придерживаться. Идентичность Identity Возможность получения уникального адреса объекта...

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

Промежуточное обеспечение Middleware ПО, служащее посредником между клиентом и сервером, например, для предоставления общих интерфейсов.

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

ООСУБД ODBMS Объектно-Ориентированная Система Управления Базами Данных.