Труды КНЦ вып.3 (ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ вып.1 3/2010(3))

реализации в реляционном стиле запроса —Опреде­ лить все прямоугольники, которые покрывают неко­ торую область заданного квадрата” (впервые пред­ ложенный Стоунбрейкером). Этот пример иллюст­ рирует, что запросы к реляционной базе данных об­ ладают довольно низкой степенью наглядности. По­ следнее препятствует анализу их смысла. Перечисленные недостатки привели к появлению направления семантического моделирования и ши­ рокому использованию объектного подхода при ор­ ганизации хранения и обработки информации БД. Объектно-ориентированный подход [5] был соз­ дан для решения задачи повышения уровня абстрак­ ции данных и стал фактическим стандартом разра­ ботки программного обеспечения. В объектно­ ориентированных языках программирования (ОО- ЯП) предметная область описывается в виде сово­ купности экземпляров различных типов, которые определяются программистом. ООЯП поддерживают три парадигмы: 1) инкапсуляция данных; 2) наследование; 3) полиморфизм. Разработчики современных СУБД стремятся тем или иным способом реализовать объектные парадиг­ мы, расширяя возможности базовых моделей дан­ ных. При этом возникает вопрос о целесообразности применения объектно-ориентированного подхода при организации хранения данных. Несмотря на то, что области языков программирования и управления базами данных имеют много общего, в некоторых весьма важных аспектах они отличаются. В частно­ сти, по определению прикладная программа предна­ значена для решения заранее определенного набора специфических задач, а базы данных - для решения задач, формулировка которых может быть не извест­ на в момент создания базы данных. Инкапсулиро­ ванным объектам при разработке прикладной про­ граммы, очевидно, необходима некоторая доля —ра­ зумности”, поскольку это позволяет сократить код управления этими объектами, повысить эффектив­ ность работы программиста, улучшить сопровожде­ ние программы и т.д. Для баз данных использование в чистом виде объектно-ориентированного подхода зачастую может оказаться вредным, поскольку огра­ ничивает возможность выполнения незапланирован­ ных запросов. Причина в том, что ООП обеспечивает инкапсуляцию данных и задает жестко регламенти­ рованные интерфейсы для объектов, тем самым на­ следуя недостатки иерархической (сетевой) модели данных. Далее рассматриваются особенности различных расширений реляционного похода. Исследуются их возможности в представлении семантических огра­ ничений предметной области и организации на их основе интеллектуальных процедур. Совместное использование реляционного и объектно-ориентированного подходов В зависимости от того, каким образом реализу­ ются парадигмы объектно-ориентированного про­ граммирования, среди современных СУБД можно выделить три основных направления: • постреляционные; • объектно-ориентированные (ООСУБД); • объектно-реляционные (ОРСУБД). Первое и третье направление появились в резуль­ тате развития реляционного подхода. Второе на­ правление представляет собой логическое продол­ жение иерархического и сетевого подходов к пред­ ставлению БД. Постреляционные СУБД - результат эволюции РСУБД. Они позволяют создавать пользовательские типы данных (с некоторыми ограничениями) и таб­ лицы с композитными столбцами. В качестве домена столбца может выступать таблица, а точнее - тип данных, соответствующий структуре таблицы и соз­ даваемый одновременно с таблицей. Композитные типы создаются на основе некоторого базового мно­ жества элементарных типов, априорно поддержи­ ваемых СУБД. Современные постреляционные СУБД (например, PostgreSql 8.02 [6]) не позволяют напрямую (средствами языка SQL или его объектных расширений) создавать массивы для хранения произ­ вольных структур, несмотря на то, что сами пользо­ вательские типы данных определяются без особого труда. Создание массивов пользовательских типов средствами таких СУБД требует описания на одном из объектно-ориентированных языков (чаще всего на С++ [5, 8]) самого массива, а также операторов пре­ образования массива в строку и обратно. Постреля- ционные СУБД позволяют хранить функции обра­ ботки данных, которые используют в качестве пара­ метров определяемые пользователем типы. В PostgreSql поддерживается возможность множест­ венного наследования таблиц, которая вызывает ряд проблем (например, уникальность значений ключе­ вых полей таблиц-наследниц). Проблемы возникают из-за неадекватности отображения —объектный класс - таблица”, характерного для постреляционных СУБД [4]. Реляционную таблицу нельзя считать ана­ логом объектного класса, несмотря на то, что она тоже описывается набором атрибутов, по следую­ щим причинам: 1. Таблица, в отличие от объектного класса, яв­ ляется коллекцией однотипных объектов. В связи с этим, таблица должна иметь ключевой атрибут, ко­ торый не характерен для объектного класса. 2. Таблица не имеет методов. Конечно, можно описать функции, работающие с данной таблицей. Но между вызовами “table.method(3)” и “procedure(table,3)” нельзя ставить знак равенства, поскольку разрушается инкапсуляция объектного класса - ключевая парадигма ООП. 24