ТЕХНИЧЕСКИЙ ОБЗОР
Хотя объектные базы данных пока не вышли из пеленок, они решают сложные проблемы управления данными
Реляционные БД переживают трудное время, поскольку им приходится удовлетворять возрастающие потребности корпораций в СУБД. Организации, которым нужно сохранять больше типов данных, требуют более высокой производительности и хотят стандартизировать язык объектного программирования - они надеются, что объектно-ориентированные СУБД (ОСУБД) справятся с этой задачей.
ОСУБД впервые появились в конце 80-х и только сейчас начинают применяться для работы в клиент-серверных средах на уровне предприятия.
Возможно, самой важной причиной для принятия объектной технологии является то, что ОСУБД лучше подходят для обработки сложных типов данных и транзакций, особенно в кросс-платформных и распределенных средах.
Объект в объектно-ориентированной БД состоит из данных и методов или модели поведения. Данные могут состоять из графики, видео или кода, а сами объекты легко перемещаются между серверами и рабочими станциями.
Реляционные базы данных, напротив, состоят из рядов (строк) и колонок, включающих поля фиксированной длины, преимущественно текстовые. Многие серверы баз данных обеспечивают поддержку крупных двоичных объектов, но все они плохо приспособлены к работе с видео, кодом приложений и САПР-изображениями.
Сервер реляционных БД при связи данных из отдельных таблиц также зависит от первичных и внешних ключей. Это значит, что администраторы баз данных должны нормализовать эти таблицы (что часто бывает достаточно сложно), чтобы запросы могли работать эффективно. Поэтому базами данных, которые состоят из большого числа таблиц, труднее управлять, и они могут работать медленнее, поскольку механизм баз данных должен справиться со сложным процессом фильтрации данных из каждой таблицы.
ТЕХНОЛОГИЯ СТАНОВИТСЯ НА НОГИ
У ОСУБД есть свои недостатки. Базы данных этого типа недостаточно развиты, и хотя организации вроде группы Object Database Management Group (ODMG) работают над стандартом взаимодействия, .для этих БД все еще не существует стандартного языка запросов.
Объектно-ориентированные БД облегчают совместное и многократное использование данных
Каждый из объектов базы данных слева содержит данные и присвоенную моделль поведения.
Модель поведения определяет, что объект делает после того, как ему послано сообщение
(например, от приложения типа формы вхождения заказа). В отличие от реляционных БД, в которых
для привязки таблиц используется првичный и внешний ключи, объекты в объектных БД связываются через
индификаторы объектов, а индификаторы объектов определяют отношения с другими объектами
в базе данных.
ODMG создает язык OQL (язык запросов к объектам), который станет надмножеством SQL, стандартного языка запросов к реляционным БД. Используя OQL, конечные пользователи смогут запрашивать объектные БД при помощи SQL-подобного синтаксиса. ANSI ХЗН2, группа стандартов SQL, также добавляет объектные расширения к SQL 3 - находящемуся в разработке стандарту на языки запросов к реляционным БД.
Все члены ODMG в этом месяце должны заняться поддержкой связи с Си++ и Smalltalk, самыми популярными языками объектно-ориентированного программирования. Это даст гарантию, что можно будет использовать созданные на этих языках программирования объекты при работе с ОСУБД.
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ ЯЗЫКИ
Большинство коммерческих ОСУБД прямо интегрируются со стандартными объектно-ориентированными языками программирования.
Напротив, в традиционной клиент-серверной среде необходимо писать приложения для клиентов, а затем кодировать специальные программы для сервера баз данных на собственном языке сервера. Эти программы (их называют встроенными процедурами) обрабатывают запросы, модификации и подключенные процедуры, которые все вместе составляют бизнес-логику.
Этот тип клиент-серверных продуктов сравнительно прост, но не так гибок, как разработки ОСУБД. Например, добавление таблицы в базу данных может означать, что часть клиентского приложения придется переписать и установить заново.
Изменения в ОСУБД передаются вниз в соответствии с иерархией объектов. Этот принцип, получивший название наследования, позволяет разработчикам модифицировать свойства объекта в серверном ПО, и им не приходится, к примеру, вносить большие изменения в клиентскую часть.
Еще одна веская причина для перехода на ОСУБД - возможность многократного использования объектов. Программисты объектно-ориентированных систем успели понять, что гораздо легче взять уже написанный код, чем создавать его заново для каждого нового приложения.
Многократное использование кода позволяет работать более продуктивно и быстро, облегчает контроль качества - все это важно, когда приходится создавать сложные приложения. Еще одна проблема, которую может решить объектно-ориентированное программирование, - случаи, когда язык разработки клиентского ПО не интегрирован в оригинальный язык сервера базы данных. Например, может возникнуть абсолютная несовместимость, если язык программирования клиентской части не позволяет использовать структуры данных, созданные на языке сервера БД.
ДАННЫЕ ПРИВЯЗАНЫ К МОДЕЛИ ПОВЕДЕНИЯ
Как и в объектно-ориентированном программировании, каждый объект в объектной БД содержит данные и соответствующую модель поведения (см. схему). Это принципиально отличный от реляционных БД принцип, поскольку в них данные независимы от методов. Объекты могут включать другие объекты, каждый из которых независим от других, т.е. разработчики могут модифицировать объект, не затрачивая остальных, - это называется инкапсуляцией. Термин "классы" обозначает модель поведения группы объектов.
Между элементами объекта и реляционной базы данных нет прямого соответствия. Впрочем, классы объектов соответствуют реляционным таблицам. Объект ставит в соответствие отображение и колонки, а экземпляры объектов соответствуют рядам и колонкам. Объекты соотносятся друг с другом через идентификатор объектов, который эквивалентен первичному и внешнему ключам. Объекты могут представлять полный набор информации. Например, доступ к заказам клиента можно получать, вызывая единый объект. Идентификатор объекта, который является наследуемой частью объекта, определяет взаимоотношения с другими объектами ОСУБД.
Базы данных готовятся к бою
Поскольку данные сохраняются в объекте вместе с кодом, ОСУБД облегчают управление сложными системами. При работе с большой БД, которая может включать более ста таблиц, код, определяющий работу приложения с этими данными, сохраняется как внешний, поэтому изменения, внесенные в код или таблицу, заставят разработчиков приводить системы в соответствие.
ШИРОКОГО ПРИЗНАНИЯ ПОКА НЕТ
Несмотря на достоинства объектных баз данных, для того чтобы они стали обычным явлением в работе на уровне предприятия, придется еще многое сделать. Большинство профессионалов уже освоились с реляционной технологией и могут воспринять необходимость изучения новой концепции без особого энтузиазма.
Впрочем, следует отметить, что официальные представители крупнейших производящих реляционные СУБД фирм сообщили, что в ближайшем будущем они собираются обеспечивать возможности работы с объектами. Например, корпорация Oracle, как ожидается, включит объектно-ориентированные расширения в версию 8 одноименного сервера БД, который выйдет к концу 1996 года.
Кроме того, производители ОСУБД, в том числе фирмы Versant и Objectivity, предлагают продукты, которые связывают объектные БД и существующие реляционные.
Такие БД, получившие название гибридных, расширяют реляционные БД и обеспечивают поддержку объектов, которые воспринимаются как данные особого типа. Гибридные БД приобретают все более широкую популярность, поскольку многие специалисты по информационным системам осознают необходимость расширять свои базы данных, но не готовы принять новую технологию. Гибридные БД позволяют администраторам освоить ее, и при этом им не приходится управлять базами данных двух архитектур или прекращать работу на время перехода.
Еще одной причиной нерешительности при переходе на объектно-ориентированные БД могут быть легенды, которые ходят об этой технологии: якобы такие базы данных медленно работают, плохо масштабируются и их нельзя использовать для того, чтобы выполнять запросы. Хотя все эти утверждения, может быть, и верны в отношении самых первых объектных баз данных, однако к сегодняшним ОСУБД они не относятся.
Джон Ташек
