Реферат: Объектно-ориентированные СУБД
Оъекгно-СУБД
Оглавление
1. 20 лет эволюции программногообеспечения.
2. Реляционные базыданных.
3. Объектно-реляционныеметоды.
4. Объектно-ориентированные базыданных.
4.1 WhyODBMS?
4.2 Спорные моментытехнологии.
4.3 Стандарты объектных базданных.
4.4 Поставщики ООСУБД.
5.Заключение.
6.Глоссарий
1.
2. 20 лет эволюциипрограммного обеспечения.
Рисунок 1
Управление информацией всегда было основной сферойприменения компьютеров и,
надо думать, будет играть еще большую роль вбудущем.Системы управления базами
данных[1] (СУБД, DBMS – Database Management System) напротяжении всего пути
развития компьютерной техники совершенствовались,поддерживая все более сложные
уровни абстрактныхданных, заданных пользователем, иобеспечивая взаимодействие
компонентов, распределенных в глобальных сетях ипостепенно интегрирующихся
стелекоммуникационными системами. Позволив себерассуждения в стиле Билла
Гейтса, предположим, что результатом будет становлениесистем
управленияинформацией одной из частей повседневной жизникаждого.
История развития компьютерной техники – это историянепрерывного движения от
языка и уровня коммуникации машины к уровнюпользователя.Если первые машины
требовали от пользователя оформления того, что ему нужно(то есть написания
программ), в машинных кодах, то языкипрограммированиячетвертого уровня (4GLs)
позволяли конечным пользователям, неявляющимсяпрофессиональными программистами,
получать доступ к информации без детального описаниякаждого шага, но только с
встроенными предопределенными типами данных– например,таблицами.
Последним шагом в этом направлении сталаобъектно-ориентированная
технология, радикально изменившая сферу разработкипрограммного обеспечения уже в
1990-х годах (Рисунок1). Объектно-ориентированный подходпозволяет упаковывать
данные и код для их обработки вместе. Таким образомпрактически снимается
ограничение натипы данных, позволяя работать на любомуровне абстракции.
Эволюция систем управления информацией шла параллельноэтому прогрессу, начиная
с низкоуровневых программ, которые, например,напрямуюпроизводили операции
чтения и записи со всей памятью без ограничения доступа,лентой, цилиндрами и
дорожками диска и более высокоуровневыми средствами–файловыми системами,
которые оперировали с такими понятиями, как массивы,записи и индексы для
повышения производительности. Базы данных в своюочередьначинали с модели
записей и индексов (ISAM и др.), приобретая со временемспособность
восстановленияпосле сбоев, проверки целостности данных ивозможности работы
нескольких пользователей одновременно. Эти ранние моделиданных(CODASYL)
относились скорее к уровнюмашинной ориентации. Вдальнейшем реляционные базы
данных, пришедшие на смену в 1980‑ х годах,приобрели механизм запросов,
позволяющий пользователю указать требуемое, предоставивСУБД самой оптимальным
образом найти результат, используя динамическуюиндексацию.
Обьектно-ориентированные СУБД (ООСУБД) сталиразрабатываться с середины 80‑ х
годов восновном для поддержки приложений САПР. Сложныеструктуры данных систем
автоматизированного проектирования оказалось очень удобнооформлять в
видеобъектов, а технические чертежи проще хранить в базеданных, чем в файлах.
Это позволяет обойтись без декомпозиции графическихструктур на элементы и
записи их в файлы послезавершения работы с чертежом,выполнения обратной
операции при внесении любого изменения. Если типичныереляционные базы данных
имеют связи глубиной в двауровня, то иерархическаяинформация чертежей САПР
обычно включает порядка десяти уровней, что требует достаточносложных операций
для “сборки”результата. Объектные базы данных хорошосоответствовали подобным
задачам, и эволюция многих СУБД началась именно с рынкаСАПР.
Между тем рынок САПР был быстро насыщен, и в начале90‑ х годов производители
ООСУБД обратили внимание на другие области применения,ужепрочно занятые
реляционными СУБД. Для этого потребовалось оснаститьООСУБД функциями
оперативной обработки транзакций (OLTP), утилитамиадминистратора баз данных
(database administrator – DBA), средствамирезервногокопирования/восстановления
и т. д. Работы в данном направлении продолжаются исегодня, но уже можно
сказать, что переход к коммерческим приложениямидетдостаточно успешно.
3. Реляционные базы данных.
В реляционных базах данных (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”. База данных рядового предприятия общепита(клиенты – Джордж Буш и
Эдди Мэрфи) состоит изчетырех таблиц.
Еще один крупный недостаток реляционных баз данных – этовысокая трудоемкость
манипулирования информацией и изменения связей.
4. Объектно-реляционные методы.
Несмотря на рассмотренные в п. 3 недостатки реляционныхбаз данных, они обладают
рядом достоинств:
разделение таблиц разными программами;
развернутый “код возврата” при ошибках;
высокая скорость обработки запросов (команда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, применяемый всочетании сее ООБД Ontos/DB.
5. Объектно-ориентированные базы данных.
5.1Why ODBMS?
“Белыми книгами” с названием, вынесенным в заголовок, сизбытком снабдит любая
компания, занимающаяся объектными базами данных. Кое-чтоопреимуществах и
недостатках объектно-ориентированных СУБД уже упоминалосьвыше, подведем в таком
случае итог.
Объектно-ориентированные базы данных применяются с конца1980-х для обеспечения
управления базами данных приложениями, построеннымивсоответствии с концепцией
объектно-ориентированного программирования. Объектнаятехнология расширяет
традиционную методику разработки приложенийновыммоделированием данных и
методами программирования. Для повторного использованиякода и улучшения
сохранности целостности данных в объектномпрограммированииданные и код для их
обработки организованы в объекты. Таким образом,практически полностью снимаются
ограничения на типы данных.
Если данные состоят из коротких, простых полейфиксированной длины (имя, адрес,
баланс банковского счета), то лучшим решениембудетприменение реляционной базы
данных. Если, однако, данные содержат вложеннуюструктуру, динамически
изменяемый размер, определяемые пользователемпроизвольныеструктуры
(мультимедиа, например), представление их в табличнойформе будет, как минимум,
непростым. В то же время в ООСУБД каждаяопределеннаяпользователем структура –
это объект, непосредственно управляемый базой данных.
В РСУБД связи управляются пользователем, создающимвнешние ключи. Затем для
обнаружения связей динамически во время выполнениясистемапросматривает две (или
больше) таблицы, сравнивая внешние ключи до достижениясоответствия. Этот
процесс, называемый объединением (join), является слабойсторонойреляционной
технологии. Более двух или трех уровней объединений –сигнал, чтобы искать
лучшее решение. В ООСУБД пользователь просто объявляетсвязь, и
СУБДавтоматически генерирует методы управления,динамически создавая, удаляя и
пересекая связи. Ссылки при этом прямые, нетнеобходимости в просмотре
исравнении или даже поиске индекса, который может сильносказаться на
производительности. Таким образом, применение объектноймодели
предпочтительнеедля баз данных с большим количествомсложных связей:
перекрестных ссылок, ссылок, связывающих несколькообъектов с несколькими
(many-to-many relationships)двунаправленными ссылками.
В отличие от реляционных, ООСУБД полностью поддерживаютобъектно-ориентированные
языки программирования. Разработчики, применяющие С++илиSmalltalk, имеют дело с
одним набором правил (позволяющих использовать такиепреимуществаобъектной
технологии, как наследование, инкапсуляция иполиморфизм). Разработчик не должен
прибегать к трансляцииобъектной модели в реляционную иобратно. Прикладные
программы обращаются и функционируют с объектами,сохраненными в базе данных,
которая используетстандартную объектно-ориентированнуюсемантику языка и
операции. Напротив, реляционная база данных требует,чтобы разработчик
транслировал объектнуюмодель к поддерживаемой моделиданных и включил
подпрограммы, чтобы обеспечить это отображение во времявыполнения. Следствием
являются дополнительные усилияпри разработке и уменьшениеэффективности.
И, наконец, ООСУБД подходят (опять же без трансляциймежду объектной и
реляционной моделями) для организации распределенныхвычислений.Традиционные
базы данных (в том числе и реляционные и некоторыеобъектные) построены вокруг
центрального сервера, выполняющего все операции надбазой. Посуществу, эта
модель мало отличается от мэйнфреймовой организации60‑ х годов с центральной ЭВМ
– мэйнфреймом (mainframe), выполняющей все вычисления, ипассивных
терминалов.Такая архитектура имеет ряд недостатков,главным из которых является
вопрос масштабируемости. В настоящее время рабочиестанции (клиенты)
имеютвычислительную мощность порядка 30 ‑ 50 %мощности сервера базы данных, то
есть большая часть вычислительных ресурсов распределенасреди клиентов.Поэтому
все больше приложений, и в первую очередь базы данных исредства принятия
решений, работают в распределенных средах, в которыхобъекты(объектные
программные компоненты) распределены по многим рабочимстанциям и серверам и где
любой пользователь может получить доступ к любомуобъекту.Благодаря стандартам
межкомпонентного взаимодействия (об этом позже) все этифрагменты кода
комбинируются друг с другом независимо отаппаратного, программного обеспечения,
операционных систем, сетей, компиляторов, языковпрограммирования, различных
средств организации запросов и формирования отчетовидинамически изменяются при
манипулировании объектами без потери работоспособности.
5.2 Спорныемоменты технологии.
Все ООСУБД по определению поддерживают сохранение иразделение объектов. Но,
когда дело доходит до практической разработкиприложенийна разных ООСУБД,
проявляется множество отличий в реализации поддержки треххарактеристик:
Целостность;
Масштабируемость;
Отказоустойчивость.
Отметим, что ООБД не требуют многих из тех внутреннихфункций и механизмов,
которые столь привычны и необходимы в реляционныхБД.Например, при небольшом
числе пользователей, длинных транзакциях и незначительнойзагрузке сервера
объектные СУБД не нуждаются в поддержке сложныхмеханизмоврезервного
копирования/восстановления (исторически сложилось так,что первые ООБД
проектировались для поддержки небольших рабочих групп –порядка десятичеловек –
и не были приспособлены для обслуживания сотенпользователей). Тем не менее
технология БД определенно созрела для крупных проектов.
Дляиллюстрации первой категории рассмотрим механизмкэширования объектов.
Большинство объектных СУБД помещают код приложениянепосредственно в то
жеадресное пространство, где работает сама СУБД.Благодаря этому достигается
повышение производительности часто в 10‑100разпо сравнению с раздельными
адресными пространствами. Но при такой модели объект сошибкой может повредить
объекты и разрушить базу данных.
Существуют два подхода к организации реакции СУБД дляпредотвращения потери
данных.Большинство систем передают приложению указателина объекты, и рано или
поздно такие указатели обязательно становятся неверными.Так, они всегда
неправильныпосле перехода объекта к другому пользователю(например, после
перемещения на другой сервер). Если программист,разрабатывающий приложение,
пунктуален, тоошибки не возникает. Если же приложениепопытается применить
указатель в неподходящий для этого момент, то в лучшемслучае произойдет крах
системы, вхудшем – будет утеряна информация в серединедругого объекта и
нарушится целостность базы данных.
Есть метод, лучший, чем использование прямых указателей(Рисунок 3). СУБД
добавляетдополнительный указатель и при необходимости,если объект перемещается,
система может автоматически разрешить ситуацию(перезагрузить, если это
необходимо, объект) без возникновения конфликтнойситуации.
Существует еще одна причина для применения косвеннойадресации: благодаря этому
можноотслеживать частоту вызовов объектов для организацииэффективного механизма
свопинга.
Это необходимо для реализации уже второго необходимогосвойства баз данных –
масштабируемости. Опять следует упомянутьорганизациюраспределенных компонентов.
Классическая схема клиент-сервер, где основная нагрузкаприходится на клиента
(такая архитектура называется еще “толстыйклиент-тонкийсервер”), лучше
справляется с этой задачей, чем мэйнфреймовая структура,однако ее все равно
нельзя масштабировать до уровня предприятия.Благодарямногозвенной архитектуре
клиент-сервер (N-Tier architecture) происходитравномерноераспределение
вычислительной нагрузки между сервером и конечнымпользователем. Нагрузка
распределяется по трем и более звеньям, обеспечивающим
дополнительнуювычислительную мощность. К чему же ещеведет такая практика?
“Архитектура клиент-сервер, еще совсем недавносчитавшаяся сложной средой,
постепеннопревратилась в исключительно сложную среду.Почему? Благодаря
ускоренному переходу к использованию систем клиент-сервернескольких звеньев”
(PCMagazine).Разработчикам приходится расплачиватьсядополнительными
сложностями, большими затратами времени и множествомпроблем, связанных с
интеграцией. Оставимочередное упоминание распределенныхкомпонентов на этой не
лишенной оптимизма ноте.
Рисунок 3 Прямая и косвенная адресации.
Третье необходимое качество базы данных – этоотказоустойчивость. Именно это
свойство отличает программныйпродукт от “прилады”.Существуют несколько способов
обеспечения отказоустойчивости:
резервное копирование и восстановление;
распределение компонентов;
независимость компонентов;
копирование.
Руководствуясь первым принципом, программист определяетпотенциально опасные
участки кода и вставляетв программу некоторые действия,соответствующие началу
транзакции – сохранение информации, необходимой длявосстановления после сбоя, и
окончанию транзакции –восстановление или, в случаеневозможности, принятие
каких-то других мер, например, отправка сообщенияадминистратору. В современных
СУБД этот механизмобеспечивает восстановление в случаевозникновения практически
любой ошибки системы, приложения или компьютера, хотя,конечно, нельзя говорить
об идеальнойзащите от сбоев.
В мэйнфреймовой архитектуре единственным источником сбоевбыла центральная ЭВМ.
При переходе к распределенной многозвеннойорганизацииошибки могут вызывать не
только компьютеры, включенные в сеть, но икоммуникационные каналы. В
многозвенной архитектуре при сбое одного из звеньевбезспециальных мер
результаты работы других окажутся бесполезными. Поэтомупри разработке
распределенных систем обеспечивается принципиально болеевысокийуровень
обеспечения отказоустойчивости. Назовем обязательные длясовременных
распределенных СУБД свойства:
прозрачный доступ ко всем объектам независимо отихместоположения, благодаря
чему пользователю доступны все сервисы СУБД и может производиться
перераспределение компонентов без нежелательныхпоследствий.
так называемый “трехфазный монитор транзакций”(third-party transaction
monitor), благодаря которомутранзакция выполняется не вдва, а в три этапа –
сначала посылается запрос о готовности к транзакции.
Что произойдет, если один из компонентов выйдет из строя?Система, созданная в
соответствии только с вышеизложеннымидоводами, приостановит работу всех
пользователей и прервет все транзакции. Поэтому важнотакое свойство СУБД, как
независимость компонентов.
При сетевом сбое сеть разделяется на части, компонентыкаждой из которых не
могут сообщаться с компонентами другой части. Длятого, чтобы сохранить
возможность работы внутри каждой такой части, необходимодублирование критически
важной информации внутри каждого сегмента.Современныесистемы позволяют
администратору базы данных динамически определятьсегменты сети, варьируя таким
образом уровень надежности всей системы в целом.
И, наконец, о копировании (replication) данных.Простейшим способом является
добавление к каждому (основному) серверу резервного.После каждойоперации
основной сервер передает измененные данные резервному,который автоматически
включается в случае выхода из строя основного.Естественно, такаясхема не лишена
недостатков. Во-первых, это приводит к значительнымнакладным расходам при
дублировании данных, что не только сказываетсянапроизводительности, но и само
по себе является потенциальным источником сбоев.Во-вторых, в случае сбоя,
повлекшего за собой разрыв соединения междудвумясерверами, каждый из них должен
будет работать в своем сегменте сети в качестве основногосервера, причем
изменения, сделанные на серверах за время работы втакомрежиме, будет невозможно
синхронизовать даже после восстановленияработоспособности сети.
Более совершенным является подход, когда создаетсянеобходимое (подбираемое в
соответствии с требуемым уровнем надежности) числокопий всегменте. Таким
образом увеличивается доступность копий и даже (прираспределении нагрузки между
серверами) повышается скорость чтения.Проблеманевозможности обновления данных
несколькими серверами одновременно в случае их взаимнойнедоступности решается
за счет разрешения проведения модификацийтолько в одномиз сегментов, например
имеющем наибольшее число пользователей. При хорошонастроенной схеме кэширования
затраты на накладные расходы придублированиимодифицированных данных близки к
нулю.
5.3 Стандартыобъектных баз данных.
Для обеспечения переносимости приложений (приложениеможет работать на разных
СУБД) и совместимости с СУБД (может взаимодействоватьсразными СУБД),
естественно, необходима выработка стандартов. Сразузаметим, что установление
стандартов лишает производителя в некоторой степенисвободы впринятии решений и
увеличивает стоимость продукта за счет лицензионныхотчислений и больше не будем
обсуждать целесообразность (прямо скажем, очевидную)стандартизации.
В области объектных СУБД в настоящее время выработаныстандарты для:
объектной модели;
языка описания объектов;
языка организации запросов (Object Query Language –OQL);
“связующего” языка (C++ и, конечно же, Smalltalk);
администрирования;
обмена (импорт/экспорт);
интерфейсов инструментария и др.
Хотя у Microsoft и свое мнение на этот счет, организацией,выработавшей наиболее
используемые насегодня и устоявшиеся стандарты, являетсяконсорциум поставщиков
ООСУБД ODMG (ООСУБД), которого поддерживаютпрактическивсе действующие лица
отрасли. В сотрудничестве с OMG, ANSI, ISO идругимиорганизациями был создан
стандарт ODMG-93. Этот стандарт включает в себя средствадля
построениязаконченного приложения, которое будет работать(после перекомпиляции)
в любой совместимой с этой спецификацией ООСУБД. В книгуODMG-93 входят
следующие разделы:
Язык определения объектов (Object Definition Language –ODL);
Язык объектных запросов (Object Query Language – OQL);
Рисунок 4 Схема использования ODL для построенияприложения.
Связывание с C++;
Связывание со Smalltalk.
ODL. В качестве языка определения объектов (ODL) ODMG былвыбран существующий
язык IDL(Interface Definition Language – язык описанияинтерфейсов), который был
дополнен такими необходимыми дляобъектных БД свойствами,как определение
коллекций, двунаправленных связей типа “многие-ко-многим”,ключей и др. В
сочетании со средствами языка IDL определения атрибутов иопераций, это
позволяет определять практически любые объекты. Вседополнения реализованы в
видедоопределения методов, что обеспечивает совместимостьсо стандартами OMG,
например стандартом CORBA.
Рисунок 4 показывает работоспособную схему для построенияприложения на
стандартных языках программирования, в процессе которой
автоматическигенерируются метаданные, заголовочные файлыи методы. Приведем
также пример на языке ODL из “белой книги” компанииObjectivity,
которыйиллюстрирует связи типа “один-ко-многим”,объявленные между
преподавателем и студентами:
interface professor: employee {
attribute string <32> name;
unique attribute lang unsigned ssn;
relationship dept works_in inverse faculty; relationship set<section>
teaches inverse taught_by; … operations…
{
interface section: class {
… taught_by: professor… ;
… .
}
OQL. За основу языка OQL была взята команда SELECT языкаSQL2 (или SQL-92) и
добавлены возможностьнаправлять запрос к объекту иликоллекции объектов и
возможность вызывать методы в рамках одного запроса.Данные, полученные в
результате запроса, могутбыть скалярными (включаякортежи), объектами или
коллекциями объектов. Некоторые примеры наязыке OQL (тотже источник):
• Select x from x in faculty where x.salary >
x.dept.chair.salary
•sort s in (select struct (name: x.name, s:x.ssn) from
x in faculty where for all y in
x.advisees:y.age<25) by s.name
• Chair.salary
• Students except TAs
•list (1,2) + list (count (jse.advisees), 1+2)
• exists x in faculty [1:n]: x.spouse.age<25
C++. Спецификация ODMG-93 позволяет программистам легкоиспользовать объекты в
то время как ООСУБД прозрачнымобразом управляет ими. Приопределении стандарта
члены ODMG руководствовались следующими принципами:
Использование стандартных компиляторов обеспечиваетсятем, что все расширения
реализуютсясредствами языка – библиотеками классов иперегрузкой операторов.
Определение временных экземпляров (Transient Instance)и экземпляров,
создаваемых на длительный срок (Transient Instance)припомощи оператора new().
При перегрузке оператора new() оба типа экземпляровмогут создаваться от
одного класса, который может существоватьпродолжительноевремя.
Обеспечение устойчивости через стандартный механизмнаследования; пользователь
можетопределять экземпляры временные и рассчитанные напродолжительное
использование средствами оригинальной версии языка.
Использование специального механизма указателей (SmartPointers). Связи между
объектами объявляются при помощи шаблона Ref<> иперегрузки оператора ->; это
позволяет использовать специальныеуказатели(контролируемые системой; см.,
например, идентичность в словарике (стр. 21) иупоминание косвеннойадресации
(стр. 10) как обычные.
class Professor: Employee {
long ssn;
char* name;
int age;
Ref<Department>dept inverse faculty;
Set<Section> teachesinverse taught_by;
… .
void grant_tenure()
void assign_course(section)
}
… .
Ref<Professor>prof;
… .
prof = new(db, Professor);
prof->name=«Smith»;
prof->age+prof->age+1;
На этом, пожалуй, чувство благодарности компанииObjectivity в значительной мере
ослабеет, так как примеров на языке Smalltalk найти неудалось.
Smalltalk. ODMG-93 поддерживает ту же объектную модельдля Smalltalk, что и для
С++, IDL и запросы на языке OQL; это позволяетразделятьодин и тот же объект
пользователям С++ и Smalltalk. Спецификация поддерживаеттипы (возможны
бестиповые поля) и синтаксис оригинальной версииSmalltalk.
Рисунок 5 ООСУБД, построенная на основе стандартовODMG во взаимодействии
с CORBA.
Взаимодействие с другими стандартами. Многие стандартысовместимы с объектными
базами данных, например STEP, CFI,TINA-C, ISO ODP, ANSIX3H7, OpenGIS и др.
Сейчас они могут напрямую взаимодействовать с любойстандартной ООСУБД, хотя в
некоторые из них и быливнесены изменения для обеспечениясовместимости. Два
других стандарта заслуживают более детального описания –OMGи SQL.
Стандарты OMG. Первым результатом деятельности OMG сталоутверждение (OMG не
создает стандартов, апринимает одну из существующихреализаций) Архитектуры
Брокера Объектных Запросов (Common Object Request BrokerArchitecture – CORBA)
–средства диспетчеризации запросов между объектами ипользователями; в
дальнейшем были добавлены некоторые сервисы. ИнтерфейсODMG сейчас
полностьюадаптирован к спецификации Persistence ObjectService консорциума OMG,
что позволяет пользователям систем, основанных наархитектуреCORBA, пользоваться
преимуществами от ООСУБД, которые могут содержатьобъекты, отвечающие стандарту
OMG и используемые так же, как и любые другие(“мелкие”)объекты спецификации OMG
(Рисунок 5). Объекты OMG в свою очередь доступны черезинтерфейс ODMG.
Язык SQL. Из-за распространенности SQL был заложен воснову OQL, который был
дополнен средствами поддержки объектной модели. Внастоящее время
разрабатывается версия языка SQL, известная под названиемSQL3, в которой будут
реализована поддержка объектов и SQL будет приведен всоответствие современным
понятиям о полноценном языкепрограммирования. В отличиеот ODMG, в SQL не
планируется привязка к ODL, а также C++ и Smalltalk,которыеважны для
пользователей ООСУБД. Несмотря на это, возможности SQL3 ворганизации запросов
совпадают с возможностями OQL. Когда SQL3 будет готов(разработки ведутся сейчас
на раннейстадии обсуждения основных вопросов относительнообъектной модели),
ODMG, вероятно, дополнит его, как это уже сделано для С++и Smalltalk.
5.4Поставщики ООСУБД.
Рисунок 6 Современный рынок СУБД.
Список современных коммерческих объектно-ориентированныхсистем включает в себя
следующие продукты:
Objectivity/DB компании Objectivity, Inc. (последняяверсия – 2.1) идеально,
позаявлениям фирмы, подходит для приложений, которыеработают в распределенных
средах, требуют гибкой модификации данных, организациисложных связей, а
такженуждаются в высокой производительности и работы сбольшими объемами
данных. Вероятно, все компании, производящие ООСУБД,ставят своей целью
сложить такоевпечатление относительно собственныхразработок у читателей
распространяемых ими документов (хотя некоторые иделают это в более
деликатной форме). Болеесодержательно, Objectivityобеспечила интеграцию
инструментария СУБД и разработки приложений с такимисредствами
программирования, как SoftBench и C++ SoftBench.Благодаря интегрированному
графическому интерфейсу разработки схемы БД иинструментамотладки и анализа
упрощается задание модели базы данных и,соответственно, разработки приложений
для Objectivity/DB.
СУБД GemStone корпорации GemStone Systems, Inc.известнав последней редакции
под номером 5.0. GemStone традиционно сосредоточена нарынке Smalltalk (хотя
не так давно и была выпущена версия для С++) иимеетзаказчиков, способных
продемонстрировать на производстве крупномасштабные,целевые применения ее
продуктов. К сожалению, списком этих заказчиковобъеминформации, которую
компания хочет донести до интересующихся (WWW),ограничивается.
ONTOS Corp., разработчик СУБД ONTOS (кто быподумал), потрадиции занимается
развитием сервера объектно-ориентированной СУБД, но впоследнее время придает
особое значение своим Службам ИнтеграцииОбъектов(Object Integration
Services).
Построенная на основе реляционной СУБД AllBase, системаOpenODB фирмы
Hewlett-Packard также, как иObjectivity/DB, интегрирована с системой SoftBench
и существует в версии для С++. Благодаря глубокойинтеграции, SoftBench
распознает файлы приложений OpenODB для установкиоптимальнойконфигурации,
может создавать базы данных формата OpenODB из своейинтегрированной среды,
обеспечивает оперативную помощь из среды разработки ит. д.
Object Design Inc. со своей СУБД ObjectStoreзанимаетлидирующее положение в
отрасли, осуществляя около 33% поставок на рынкеобъектно-ориентированных СУБД
и последняя модернизация системы (клиент языкаSQL ишлюз к реляционной СУБД)
должны только укрепить положение фирмы. Object Designподдерживает версиисвоей
СУБД как для С++, так и для Smalltalk.
Versant Object Technology, Inc. (СУБД Versant) проводитдвойнуюстратегию,
предлагая средство обеспечения объектно-ориентированнойСУБД высокого класса
для телекоммуникаций и инструментальные средстваSmalltalk дляболее общих
случаев разработки приложений. Используя разработанныйфирмой интерфейс
VERSANT Smalltalk Language Interface, СУБД совместимакак с
версиейязыкаSmalltalk компании ParcPlace-Digitalk, таки с Visual Age for
Smalltalk корпорации IBM.
СУБД UniSQL компании UniSQL Inc. – хорошоустоявшаясясистема, позволяющая
пользователям осуществлять запросы и модификацию базыпри помощи
разработанного компанией языка SQL/X (подобные языки,носящие условное
название Object SQL, разработаны и некоторымидругимипоставщиками). Вся БД
UniSQL может состоять одновременно из связей влокальных РСУБД иклассов в
локальных объектных базах UniSQL. Благодаря механизмукаталогов, СУБД передает
запросы имодификации данных в локальные базы данных и,обработав (перевод в
другой формат, группирование, сортировка и т. д.)полученный от них
результат, возвращает его пользователю.
Кроме того ООСУБД предлагают: Object Database, Inc.(Object Database),
ItascaSystems Inc. (Itasca) O2 Technology (O2) инекоторые другие компании.
6. Заключение.
В 1996 г. наметился заметный сдвиг в области освоенияобъектных СУБД. Уже
существуют примеры практического их использованиякрупнымибиржами, банками,
страховыми компаниями, а также в сфере производства ителекоммуникаций, где
базам данных, содержащим гигабайты информации,приходитсяобслуживать сотни
пользователей. Они оказались хорошей альтернативой в техслучаях, когда
применение реляционных БД вынуждало строить сложную схемусчрезмерно большим
числом межтабличных связей.
Благодаря значительному прогрессу в развитии объектнойтехнологии, за последние
пять лет производителям удалось довести свои ООСУБДдотакого уровня, что они
стали вполне отвечать реальным требованиям рынка.
Несмотря на то, что технология объектных СУБД созрела длякрупных проектов, для
действительно массового ее распространениянеобходимспециальный инструментарий.
В настоящий момент ощущается настоятельная потребность винтеграции ООСУБД с
существующими инструментальными средствами.Разработчикиуже сегодня могли бы
продуктивно использовать версии Visual Basic, PowerBuilder, Forte или Delphi,
поддерживающие ООСУБД.Большинство продуктов для созданияприложений в той или
иной мере являются объектно-ориентированными, но работаютпо-прежнему с
реляционными БД.Специалисты считают, что партнерствопроизводителей ООСУБД и
средств программирования способно привести к появлениюстоль
необходимогоинструментария.
Эксперты уже неоднократно объявляли наступающий год“годом объектных баз
данных”, однако сейчас все говорит о том, что 1997г.действительно имеет шансы
наконец им стать. Основными стимулами растущего интересак ООСУБД аналитики
считают расширение применениямультителиа-приложений иновых средств, улучшающих
их стыкуемость с существующими базами данных.
7. Глоссарий
4GL (4th Generation Language) – Язык программированиячетвертого поколения
¨ Языкпрограммирования, при создании которогоиспользуются языки программирования
третьего уровня (3GL) –процедурные языки типа C и Pascal.4GL проще в
использовании, чем 3GL, им обычно отдают предпочтение присоставлении программ
обслуживания баз данных и применяют всочетании ссоответствующими средствами
разработки.
Blob (Binary Large Object) – Двоичный большой объект,блоб. ¨ Длинныйлинейный
блок данных (например, цифровое изображение иливидеоклип), который наиболее
подходит для хранения в ООСУБД.
CORBA (Common Object Request Broker Architecture)Архитектура брокера объектных
запросов ¨ Стандартвзаимодействия распределенныхкомпонентов, разработанный OMG.
DBMS (Database Management System) – Система управлениябазами данных, СУБД
N — звенная архитектура (N-Tier Model)¨ Архитектура клиент-серврер, в которой
применяются средства разбиения программили распределенныеобъекты для разделения
вычислительной нагрузки среди такого количества серверовприложений, которое
необходимо при имеющемся уровненагрузки. При многозвенноймодели системы
количество возможных клиентских мест значительно больше,чем при использовании
двухзвенной модели. См также middleware.
ODBMS (Object Database Management System) –Объектно-ориентированная СУБД –
ООСУБД. ¨ СУБД, хранящая данные и взаимосвязимежду ее элементами непосредственно
в самой базеданных в виде объектов, содержащих, какправило, алгоритмы обработки
этих данных.
ODMG (Object Database Management Group)¨ Консорциум производителейобъектных баз
данных для выработки стандартов (ODMG-93, ODMG-95).
OMG (Open Management Group) ¨ Консорциумпоставщиков всфере объектной технологии
для выработки стандартов межкомпонентного взаимодействия.Объединяет практически
всех ведущих производителей (более чем500); членствоMicrosoft, видимо, лишь
условно.
OQL (Object Query Language) Язык объектных запросов¨ Разработанныйконсорциумом
ODMG язык описания запросов, за основу которого былпринят SQL-92.
RDBMS (Relational Database Management System) –Реляционная СУБД – СУБД,
хранящая взаимосвязи междуэлементами в виде двумерныхтаблиц и использующая для
запросов язык SQL.
SQL (Structured Query Language) – Язык структурированныхзапросов
¨ Интерпретируемыйязык, описывающий операции(создание, обработка и извлечение)
над реляционнымибазами данных.
Архитектура клиент-сервер (Client-server architecture)¨ Архитектура,
обеспечивающаяраспределение нагрузки между клиентом исервером. Обычно эти
функции выполняют два разных компьютера, объединенных припомощи сети.
Атрибуты (Attributes) ¨ Видимая за пределамиобъекта информация о состоянии
этого объекта.
“Белая книга” (White Paper) ¨ Официальноеиздание.
Гибриды (Hybrids) ¨1. Средства связи междумирами объектных и реляционных баз
данных, включая базыданных, которые хранят информацию вреляционной форме, но
используют объектные буферные средства. См. такжеобъектно-реляционныеметоды 2.
СУБД, которые могут хранить и табличные данные, иобъекты. Этого определения я
старалсяпридерживаться.
Идентичность (Identity) ¨ Возможность полученияуникального адреса объекта
независимо от его местоположения и атрибутов.
Инкапсуляция (Encapsulation) ¨ Объединениеданныхи кода в один модуль – объект,
доступ к которому может осуществляться только черезстрого определенный
интерфейс.
Метаданные (Metadata) ¨ Данные, являющиесяописанием других данных (например,
схема базы данных по отношению кее содержимому).
Наследование (Inheritance) ¨ Механизм, благодарякоторому определения класса
распространяется на классы, лежащие нижеего в иерархииобобщения классов. Это
позволяет многократно изменять определения, внося по меренеобходимости
изменения, связанные соспециализацией.
Объектно-реляционные методы (Object-relational Approaches) ¨ Подходы,
позволяющиевоспользоваться преимуществами объектных базданных, не отказываясь
полностью от реляционных БД.
Отображение (Mapping) ¨ Процесс установлениясвязей между приложениями,
построенными вокругобъектно-ориентированных и реляционныхбаз данных.
Полиморфизм (Polymorphism) ¨ Способностьобъектовразличных классов и самих
классов удовлетворять одним и тем же протоколам илиотдельным
сообщениям, выполняя при этом различные действия,предписываемые их собственными
методами.
Промежуточное обеспечение (Middleware)¨ ПО, служащее посредником между клиентом
и сервером, например, для предоставления общихинтерфейсов. Следуя традиции, и я
тоже напишу, что промежуточное ПО – этослэш в термине“клиент/сервер”.
Протокол (Protocol) ¨ Набор сообщений, накоторые может ответить класс (протокол
класса) или его объекты(протокол объекта). Протоколопределяется заданными
методами. Все объекты одного класса отвечают одномупротоколу.
СУБД – Система Управления БазамиДанных.¨ Лежащая в основе базы данныхприкладная
программа, выполняющая операции над хранимой информацией.
Транзакция (Transaction) – обработка запроса¨ Выполнение элементарнойцелостной
операции над данными, в течение которой база данныхнаходится в неустойчивом
состоянии.
ООСУБД (ODBMS)– Объектно-Ориентированная СистемаУправления Базами Данных.