КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Общие понятия объектно-ориентированного подхода к разработке СУБД
Поддержка динамической информации и темпоральных запросов Обычные реляционные БД хранят мгновенный снимок модели предметной области. Любое изменение в момент времени t некоторого объекта приводит к недоступности состояния этого объекта в предыдущий момент времени. На самом деле в большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа к нему со стороны пользователя нет. Конечно, можно ввести в хранимые отношения временной атрибут и поддерживать его значения на уровне приложений. В большинстве случаев так и поступают. Так, в стандарте SQL появились специальные типы данных: date и time. Но в таком подходе имеются недостатки: СУБД не знает семантики временного поля отношения и не может контролировать корректность его значений. В связи с этим появляется дополнительная избыточность хранения (предыдущее состояние объекта хранится и в основной БД, и в журнале изменений). Существует отдельное направление исследований и разработок в области так называемых темпоральных БД, где исследуются вопросы моделирования данных, языки запросов, организация данных во внешней памяти и т.д. Основные темпоральные системы на том принципе, что для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются (и доступны пользователям) все его состояния во временном интервале [t1,t2]. Создание прототипов темпоральных СУБД обычно выполняется на основе некоторой реляционной СУБД в виде надстройки над реляционной системой. ГЛАВА 15. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ СУБД Создание объектно-ориентированных баз данных началось в середине 1980-х гг. Наиболее активно ООБД развиваются в последние годы. Развитие ООБД определяется, прежде всего, потребностями практики — необходимостью разработки сложных информационных прикладных систем. Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечили как предыдущие работы в области БД, так и развивающиеся языки программирования с абстрактными типами данных и объектно-ориентированные языки программирования. Что касается связи с предыдущими работами в области БД, то, на наш взгляд, наиболее сильное влияние на развитие ООБД оказывают проработки реляционных СУБД и создаваемое на их основе семейство БД, поддерживающих управление сложными объектами. Кроме того, исключительное влияние на идеи и концепции создания ООБД оказало семантическое моделирование данных. Свое влияние оказывает также развитие параллельно с ООБД дедуктивных и активных БД. В наиболее общей постановке объектно-ориентированный подход базируется на следующих концепциях: • объект и идентификатор объекта; • атрибут и метод; • класс; • иерархия и наследование классов. Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния этого объекта. Каждый объект характеризуют состояние и поведение. Состояние объекта — набор значений его атрибутов. Поведение объекта — набор методов (программный код), оперирующих его состоянием. Значение атрибута объекта — это тоже некоторый объект или множество объектов. Состояние и поведение инкапсулированы в объекте. Взаимодействуют объекты на основе передачи сообщений и выполнения соответствующих методов. Множество объектов с одним и тем же набором атрибутов и методов образуют класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута. Допускается создание нового класса на основе уже существующего класса — наследование. В этом случае новый класс, называемый подклассом существующего класса (суперкласса), наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различают случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, а во втором случае суперклассов может быть несколько. Если в языке или системе поддерживается единичное наследование классов, то набор классов образует древовидную иерархию. При поддержании множественного наследования классы связаны в ориентированный граф с корнем, называемый решеткой классов. Объект подкласса считается принадлежащим любому суперклассу этого класса. Одной из более поздних идей объектно-ориентированного подхода к созданию СУБД является переопределение атрибутов и методов суперкласса в подклассе (перегрузка методов). Это увеличивает гибкость системы проектирования, но порождает дополнительную проблему: при компиляции объектно-ориентированной программы могут быть неизвестны структура и программный код описаний объекта, хотя его класс (в общем случае — суперкласс) известен. Для разрешения этой проблемы применяется так называемый метод позднего связывания, означающий интерпретационный режим выполнения программы с распознаванием деталей реализации объекта во время выполнения посылки сообщения к нему. Введение некоторых ограничений на способ определения подклассов позволяет добиться эффективной реализации СУБД. При таком наборе базовых понятий, если не принимать во внимание возможности наследования классов и соответствующие проблемы, объектно-ориентированный подход очень близок к языкам программирования с абстрактными (произвольными) типами данных. С другой стороны, если абстрагироваться от поведенческого аспекта объектов, объектно-ориентированный подход аналогичен семантическому моделированию данных. Фундаментальные абстракции, лежащие в основе семантических моделей, неявно используются и в объектно-ориентированном моделировании. В состав сложных объектов могут входить и другие объекты со своими значениями атрибутов. Абстракция группирования — основа формирования классов объектов. На абстракциях специализации (обобщения) основано построение иерархии или решетки классов. Наиболее важным новым качеством ООБД, которое позволяет достичь объектно-ориентированный подход, является поведенческий аспект объектов. В прикладных информационных системах, основывавшихся на БД с традиционной организацией (вплоть до тех, которые базировались на семантических моделях данных), существовал принципиальный разрыв между структурной и поведенческой частями. Структурная часть системы поддерживалась всем аппаратом БД, ее можно было моделировать, изменять, но поведенческая часть при этом создавалась изолированно. В частности, отсутствовали формальный аппарат и системная поддержка совместного моделирования и гарантирование согласованности структурной (статической) и поведенческой (динамической) частей. В среде ООБД проектирование, разработка и сопровождение прикладной системы становятся процессом, в котором интегрируются структурный и поведенческий аспекты. Конечно, для этого требуются специальные языки, позволяющие определять объекты и создавать на их основе прикладную систему. Специфика применения объектно-ориентированного подхода к организации и управлению БД потребовала уточнения толкования классических концепций и некоторого их расширения. Это определяется потребностью долговременного хранения объектов во внешней памяти, ассоциативным доступом к объектам, обеспечением согласованного состояния ООБД в условиях мультидоступа и тому подобными возможностями, свойственными базам данных. Выделяют три аспекта, отсутствующих в традиционном методе проектирования БД, но требующихся в ООБД. Первый аспект касается потребности в средствах спецификации знаний при определении класса (ограничений целостности, правил дедукции и т.п.). Второй аспект — потребность в механизме определения разного рода семантических связей между объектами разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использованием ООБД в сфере автоматизированного проектирования. Третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа, и класса объектов.
Дата добавления: 2014-01-07; Просмотров: 677; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |