Загрузка...
Учебная работа. Реферат: Объектно-ориентированные базы данных
Оглавление
Введение. 2
1. Общие понятия объектно-ориентированного подхода и их преломление в ООБД3
2. Потенциал объектно-ориентированных баз данных. 6
3. Объектно-ориентированные модели данных. 9
4. Языки программирования систем ООБД и языки запросов. 11
5. Ограничения. 18
5.1 Ограничения систем неизменного хранения.18
5.2 Ограничения систем баз данных.19
6. Заключение. 20
Перечень использованной литературы:21
Введение
Появление направления объектно-ориентированных баз данных (ООБД) определялось, до этого всего, потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых разработка предыдущих систем баз данных не была полностью удовлетворительной.
естественно, ООБД появились не на пустом месте. Соответственный базис обеспечивался как прошлыми работами в области баз данных, так и издавна развивающимися направлениями языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.
Что касается связи с прошлыми работами в области баз данных, то более мощное воздействие на работы в области ООБД оказали проработки реляционных СУБД и последующего хронологически за ними семейства БД, в каких поддерживалось управление сложными объектами. Эти работы обеспечили структурную базу организации OOБД.
1. Общие понятия объектно-ориентированного подхода и их преломление в ООБД
Принципное различие меж структурным и объектно-ориентированным подходом заключается в методе декомпозиции системы. Объектно-ориентированный подход употребляет объектную декомпозицию, при всем этом статическая структура системы описывается в определениях объектов и связей меж ними, а объект системы владеет своим своим поведением, моделирующим объект при собственном разработке получает генерируемый системой неповторимый идентификатор, который связан с объектом во все время его существования и не изменяется при изменении состояния объекта.
Любой объект имеет состояние и поведение. Состояние объекта — набор значений его атрибутов. объект либо огромное количество объектов. Состояние и количество объектов с одним и этим же набором атрибутов и способов образует класс объектов. объект должен принадлежать лишь одному классу (если не учесть способности наследования, см. последующий абзац). Допускается наличие простых предопределенных классов, объекты-экземляры которых не имеют атрибутов: целые, строчки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, именуется доменом этого атрибута.
Допускается порождение новейшего класса на базе уже имеющегося класса — наследование. В этом случае новейший класс, именуемый подклассом имеющегося класса (суперкласса) наследует все атрибуты и способы суперкласса. В подклассе, не считая того, могут быть определены доп атрибуты и способы. Различаются случаи обычного и множественного наследования. В первом случае подкласс может определяться лишь на базе 1-го суперкласса, во 2-м случае суперклассов быть может несколько. Если в языке либо системе поддерживается единичное наследование классов, набор классов образует древовидную иерархию. При поддержании множественного наследования классы соединены в направленный граф с корнем, именуемый сеткой классов. объект подкласса считается принадлежащим хоть какому суперклассу этого класса.
одной из наиболее поздних мыслях объектно-ориентированного подхода является мысль вероятного переопределения атрибутов и способов суперкласса в подклассе (перегрузки способов). Эта возможность наращивает упругость, но порождает доп делему: при компиляции объектно-ориентированной программки могут быть неопознаны структура и программный код способов объекта, хотя его класс (в общем случае — суперкласс) известен. Для разрешения данной для нас задачи применяется так именуемый способ позднего связывания, значащий, на самом деле дела, интерпретационный режим выполнения программки с определением деталей реализации объекта во время выполнения посылки сообщения к нему. Введение неких ограничений на метод определения подклассов дозволяет достигнуть действенной реализации без потребностей в интерпретации.
Специфичность внедрения объектно-ориентированного подхода для организации и управления БД востребовала уточненного толкования традиционных концепций и некого их расширения. Это определяется потребностями длительного хранения объектов во наружной памяти, ассоциативного доступа к объектам, обеспечения согласованного состояния ООБД в критериях мультидоступа и тому схожих способностей, характерных базам данных. Выделяются три нюанса, отсутствующие в классической парадигме, но требующиеся в ООБД.
1-ый нюанс касается потребности в средствах спецификации познаний при определении класса (ограничений целостности, правил дедукции и т.п.) 2-ой нюанс — Потребность в механизме определения различного рода семантических связей меж объектами совершенно говоря различных классов. Практически это значит требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использовании ООБД в сфере автоматического проектирования и инженерии. В конце концов, 3-ий нюанс связан с пересмотром понятия класса. В контексте ООБД оказывается наиболее комфортным разглядывать класс как огромное количество объектов данного типа, т.е. сразу поддерживать понятия и типа и класса объектов.
2. Потенциал объектно-ориентированных баз данных
Объектно-ориентированный язык программирования обеспечивает средства для того, чтоб создавать классы, описывающие объекты, создавать объекты, сформировывать иерархии наследования и вызывать способы для доступа к определенным объектам. По аналогии с сиим, объектно-ориентированная система баз данных обязана обеспечивать такие же средства. Но, не считая того, являясь системой баз данных, она обязана обеспечивать обычные средства, характерные современным системам баз данных, в том числе реляционным, включая способности непроцедурных запросов для подборки объектов, автоматическую оптимизацию и обработку запросов, динамическое изменение схемы (изменение определений классов и структуры наследования), автоматическое управление способами доступа (к примеру, индексное B+-дерево, расширяемая хэш-таблица, сортировка и т.д.) для увеличения эффективности обработки запросов, автоматическое управление транзакциями, одновременный доступ, восстановление опосля сбоев системы, сохранность и авторизацию. Языки программирования нацелены на 1-го юзера и сравнимо малые базы данных, системы баз данных — на огромное число юзеров и весьма огромные базы данных, потому производительность, сохранность, авторизация, параллельный доступ и динамические конфигурации схем преобразуются в принципиальные вопросцы. Не считая того, системы баз данных употребляются для сопровождения критических данных, потому важны и управление транзакциями и восстановление.
Так как система баз данных является системным программным обеспечением, функции которого вызываются приложением, написанным на определенных базисных языках, можно выделить два разных подхода к проектированию ООБД. 1-ый состоит в хранении и управлении объектами, сделанными программками, которые написаны на определенных объектно-ориентированных языках, а именно, на С++ либо Smalltalk естественно, для этого можно употреблять и РБД. Но такие базы данных ничего не знают о объектах, способах и наследовании. Потому нужно написать «Менеджеробъектов» либо «объектно-ориентированный слой» для управления способами и наследованием и для трансляции объектов в кортежи отношений. Но Менеджеробъектов вкупе с РБД и дают ООБД (естественно, с низкой производительностью).
иной подход предоставляет доступ к объектно-ориентированным средствам юзерам обычных языков. Этот подход, на самом деле, превращает такие языки, как С, FORTRAN, COBOL и т.д., в объектно-ориентированные языки. Спроектированные таковым образом ООБД могут употребляться для хранения и управления объектами, сделанными программками, написанными и на объектно-ориентированных языках. Хотя для отображения таковых объектов в объекты базы данных также нужен программный слой, он намного проще, чем Менеджеробъектов, требуемый РБД.
Так как С++, невзирая на его растущую популярность, не единственный язык программирования, который употребляют либо будут употреблять создатели приложений баз данных, и меж языком и базой данных есть значимый разрыв, 2-ой подход является наиболее удобным. Да и независимо от подхода, ООБД, изготовленные верно, приводят к квантовому переходу в продуктивность разрабов приложений баз данных и даже в эффективность самих приложений.
один из источников этого квантового перехода состоит в переиспользовании программ, которое объектно-ориентированный подход делает вероятным в первый раз в эволюционной исаории технологий баз данных. Объектно-ориентированные концепции вначале предусмотрены для сокращения трудности разработки и развития сложных программных систем и проектов. Инкапсуляция и наследование разрешают неоднократно употреблять атрибуты и программки как базис для построения сложных баз данных. Конкретно данной для нас целью направлялось развитие технологий управления данными от файловых систем к реляционным системам баз данных в течение 3-х прошедших десятилетий. ООБД владеет потенциалом, способным уменьшить трудность проектирования весьма огромных и сложных баз данных.
Еще один источник технологического скачка — массивные средства конструирования типов данных, подразумеваемые объектно-ориентированным подходом. Эти средства избавляют недочеты, имеющиеся в РБД.
3. Объектно-ориентированные модели данных
Первой формализованной и общепризнанной моделью данных была реляционная модель Кодда. В данной для нас модели, как и во всех последующих, выделялись три нюанса — структурный, целостный и манипуляционный. Структуры данных в реляционной модели основываются на плоских нормализованных отношениях, ограничения целостности выражаются при помощи средств логики первого порядка и, в конце концов, манипулирование данными осуществляется на базе реляционной алгебры либо равносильного ей реляционного исчисления. Как отмечают почти все исследователи, своим фуррором реляционная модель данных почти во всем должна тому, что опиралась на серьезный математический аппарат теории множеств, отношений и логики первого порядка. Создатели хоть какой определенной реляционной системы считали своим долгом показать соответствие собственной определенной модели данных общей реляционной модели, которая выступала в качестве меры «реляционности» системы.
Главные трудности объектно-ориентированного моделирования данных проистекают из того, что такового развитого математичекого аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. В большенный степени потому до сего времени нет базисной объектно-ориентированной модели. С иной стороны, в со ссылкой на труднодоступную нам работу Майера утверждается, что общая объектно-ориентированная модель данных в традиционном смысле и не быть может определена из-за непригодности традиционного понятия модели данных к парадигме объектной ориентированности.
Не приводя резонов в пользу этого утверждения Майера, да и не оспаривая его, Беери дает в общих чертах формальную базу ООБД, далековато не полную и не являющуюся моделью данных в классическом смысле, но позволяющую исследователям и разрабам систем ООБД по последней мере гласить на одном языке (если, естественно, предложения Беери будут развиты и получат поддержку). Независимо от предстоящей судьбы этих предложений мы считаем полезным коротко их пересказать.
Во-1-х, следуя практике почти всех ООБД, предлагается выделить два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структурном уровне поддерживаются сложные объекты, их идентификация и разновидности связи «isa». База данных — это набор частей данных, связанных отношениями «заходит в класс» либо «является атрибутом». Таковым образом, БД может рассматриваться как направленный граф. Принципиальным моментом является поддержание вместе с понятием объекта понятия значения
Принципиальным нюансом является точное разделение схемы БД и самой БД. В качестве первичных концепций схемного уровня ООБД выступают типы и классы. Отмечается, что во всех системах, использующих лишь одно понятие (или тип, или класс) это понятие безизбежно перегружено: тип подразумевает наличие некого огромного количества значений, определяемого структурой данных этого типа; класс также подразумевает наличие огромного количества объектов, но это огромное количество определяется юзером. Таковым образом, типы и классы играют разную роль, и для строгости и недвусмысленности требуются одновременное поддержание обоих понятий.
Принципиальным, хотя и недостаточно обоснованным предположением Беери будет то, что 2-ух обычных уровней — схемы и данных для ООБД недостаточно. Для четкого определения ООБД требуется уровень мета-схемы, содержимое которой обязано определять виды объектов и связей, допустимых на схемном уровне БД. Мета-схема обязана играться для ООБД такую же роль, какую играет структурная часть реляционной модели данных для схем реляционных баз данных.
4. Языки программирования систем ООБД и языки запросов
Как отмечают почти все исследователи и создатели, объектно-ориентированная система БД представляет собой объединение системы программирования и СУБД (другая, но не наиболее проясняющая сущность дела точка зрения заключается в том, что объектно-ориентированная СУБД — это СУБД, основанная на объектно-ориентированной модели данных).
Основная практическая надобность в ООБД связана с потребностью в некой встроенной среде построения сложных информационных систем. В данной для нас среде должны отсутствовать противоречия меж структурной и поведенческой частями проекта и обязано поддерживаться действенное управление сложными структурами данных во наружной памяти. С данной для нас точки зрения языковая среда ООБД — это объектно-ориентированная система программирования, естественно включающая средства работы с долговременными объектами. «Естественность» включения средств работы с БД в язык программирования значит, что работа с долговременными (хранимыми во наружной БД) объектами обязана происходить на базе тех же синтаксических конструкций (и с той же семантикой), что и работа со временными, существующими лишь во время работы программки объектами.
Эта сторона ООБД более близка схожему направлению языков программирования БД. Языки программирования ООБД и БД в почти всех собственных чертах различаются лишь терминологически; значимым различием является только поддержание в языках первого класса подхода к наследованию классов. Не считая того, языки второго класса, обычно, наиболее развиты как в отношении системы типов, так и в отношении управляющих конструкций.
Иным нюансом языкового окружения ООБД является Потребность в языках запросов, которые можно было бы употреблять в интерактивном режиме. Если доступ к объектам наружной БД в языках программирования ООБД носит в главном навигационный нрав, то для языков запросов наиболее комфортен декларативный стиль. Декларативные языки запросов к ООБД наименее развиты, чем языки программирования ООБД, и при их реализации появляются значительные задачи. Ниже мы разглядим имеющиеся подходы и их ограничения наиболее тщательно. Но начнем с языков программирования ООБД.
Начало расцвета направления ООБД совпало с пиком популярности языка Smalltalk-80. Этот язык оказал огромное воздействие на разработку первых систем ООБД, и, а именно, употреблялся в качестве языка программирования. Почти во всем опирается на Smalltalk и популярная коммерчески доступная система GemStone.
Трудности с действенной практической реализацией языка Smalltalk побудили разрабов систем ООБД к поиску других базисных языков. Популярная близость объектно-ориентированного и многофункционального подходов к программированию дозволяет довольно удачно опираться на многофункциональные языки программирования. А именно, язык Лисп (Common Lisp) является основой проекта ORION. В этом проекте Лисп является и инструментальным языком, и базой объектно-ориентированного языка программирования в среде ORION.
потребности в еще наиболее действенной реализации принуждают употреблять в качестве базы объектно-ориентированного языка языки наиболее низкого уровня. к примеру, в системе VBASE наряду со специально разработанным языком TDL, созданным для определения типов, употребляется объектно-ориентированное расширение языка Си — COP (C Object Processor). В уже упоминавшемся проекте O2 вместе с многофункциональным объектно-ориентированным языком программирования употребляются два объектно-ориентированных расширения языков Бейсик и Си. При всем этом, как можно судить по публикациям, наибольшее распространение посреди юзеров данной для нас системы (она уже коммерчески доступна) получил язык CO2, являющийся расширением языка Си. Может быть это соединено только с широкой (и все наиболее растущей) популярностью языка Си (и его объектно-ориентированного потомка Си++), ставшего воистину лозунгом «реальных программистов». Быть может, предпосылки наиболее глубинны (к примеру, языки наиболее высочайшего уровня очень ограничительны для программистов-профессионалов; недаром большая часть современных реализаций языков наиболее высочайшего уровня производятся конкретно на языке Си). Тем не наименее, современная ситуация конкретно такая, и мы считаем полезным привести короткое описание главных особенностей языка CO2.
До этого всего, CO2 не является вполне самостоятельным языком. Этот язык заходит во многоязыковую среду O2 и предназначен для программирования способов ранее определенных классов. Определение классов, сигнатур способов (практически, прототипов функций в терминологии языка Си) и имен повсевременно хранимых значений и объектов делается с внедрением отдельного языка определения схемы БД.
Основой манипулирования объектами, хранимыми в БД, является расширенное по сопоставлению с языком Си средство итерации. Итератор применим к значениям-множествам либо перечням. Практически он значит последовательное применение оператора-тела цикла ко всем элементам огромного количества либо перечня.
Потребность в поддержании в объектно-ориентированной СУБД не только лишь языка (либо семейства языков) программирования ООБД, да и развитого языка запросов в истинное время осознается фактически всеми разрабами. Система обязана поддерживать просто осваиваемый интерфейс, прямо доступный конечному юзеру в интерактивном режиме. один из подходов основывается на поддержании обходчиков. В этом случае конечный интерфейс обычно является графическим. На дисплее отображается схема (либо подсхема) ООБД, и юзер производит доступ к объектам в навигационном стиле. По воззрению Бансилона в этом случае уместно игнорировать принцип инкапсуляции объектов и предъявлять юзеру внутренность объектов. В большинстве имеющихся систем ООБД схожий интерфейс существует, но всем понятно, что навигационный язык запросов — это в неком смысле шаг вспять по сопоставлению с языками запросов даже реляционных систем. Ведутся активные поиски подходов к организации декларативных языков запросов к ООБД.
Беери отмечает существование 3-х подходов. 1-ый подход — языки, являющиеся объектно-ориентированными расширениями языков запросов реляционных систем. Более всераспространены языки с синтаксисом, близким к известному языку SQL. Это соединено, естественно, с общим признанием и очень широким распространением этого языка. А именно, в собственном Манифесте третьего поколения СУБД М. Стоунбрекер и его коллеги по комитету многообещающих систем БД говорят необходимость поддержания SQL-подобного интерфейса во всех СУБД последующего поколения.
2-ой подход основывается на построении полного логического объектно-ориентированного исчисления. По поводу построения такового исчисления имеются теоретические работы, но законченный и фактически реализованный язык запросов нам неизвестен. Видимо, к этому же направлению строго на теоретическом уровне обоснованных языков запросов можно отнести и работу Леллани и Спиратоса, основанную на алгебраической теории категорий.
В конце концов, 3-ий подход основывается на применении дедуктивного подхода. В главном это отражает рвение разрабов к сближению направлений дедуктивных и объектно-ориентированных БД. Примером обычного дедуктивного объектно-ориентированного языка запросов может служить.
Независимо от используемого для разработки языка запросов подхода перед разрабами встает одна мировозренческая неувязка, решение которой не укладывается в обычное русло объектно-ориентированного подхода. Понятно, что основой для формулирования запроса должен служить класс, представляющий в ООБД огромное количество однотипных объектов. Но что может представлять собой итог запроса? Набор главных понятий объектно-ориентированного подхода не содержит пригодного к данному случаю понятия. Обычно из положения выходят, расширяя базисный набор концепций концепцией огромного количества объектов и полагая, что результатом запроса является некое подмножество объектов-экземпляров класса. Это достаточно ограничительный подход, так как автоматом исключает возможность наличия в языке запросов средств, подобных реляционному оператору соединения. В конце этого раздела мы кратко изложим собственные (в достаточной степени подготовительные) суждения по этому поводу, но поначалу коротко разглядим индивидуальности нескольких определенных декларативных языков запросов к ООБД.
В языке запросов объектно-ориентированной СУБД ORION вполне поддерживается принцип инкапсуляции объектов. В реализованном варианте языка запросы могут основываться лишь на одном классе (хотя в описывается подход к определению запроса на нескольких классах в стиле расширения семантики реляционного оператора соединения). Синтаксис языка нацелен на SQL. Весьма развит набор допустимых предикатов селекции. А именно, для атрибута, доменом которого является суперкласс, можно указать имя интересующего юзера подкласса.
Язык запросов системы Iris находится в значимой степени под воздействием реляционной парадигмы. Даже заглавие этого языка OSQL отражает его тесноватую связь с реляционным языком SQL. На самом деле дела, OSQL — это реляционный язык, рассчитанный на работу с ненормализованными отношениями. Естественно, при таком подходе в OSQL нарушается инкапсуляция объектов.
На наш взор, особенный энтузиазм представляет декларативный язык запросов системы O2 RELOOP. В общих словах, это декларативный язык запросов с SQL-ориентированным синтаксисом, основанный на специально разработанной для модели O2 алгебре объектов и значений. (К слову, это не единственная работа в направлении построения алгебры для объектно-ориентированных моделей данных. На наш взор, в особенности впечатляющим качеством языка RELOOP является естественность его построения в общем контексте модели O2. запрос задается постоянно на значении-множестве либо перечне. Если мы вспомним, что длительному классу в O2 соответствует одноименное запрос на любом хранимом классе. Результатом запроса может являться объект, значение-множество либо значение-список. При всем этом элементами значений-множеств могут являться объекты (обычная подборка), или значения-кортежи с элементами-объектами различных классов (к примеру). В совокупы эти индивидуальности языка разрешают формулировать запросы над несколькими классами (специфичное соединение, порождающее не новейшие объекты, а кортежи из имеющихся объектов), также употреблять вложенные подзапросы.
сейчас коротко остановимся на собственных предложениях. Сущность их заключается в том, чтоб попробовать выстроить алгебру классов объектов, оставаясь в границах базисного набора концепций объектно-ориентированного подхода. Для этого довольно, чтоб была возможность интерпретации результата выполнения алгебраической операции над классами в виде класса. Предлагаемый подход, аналогично модели O2, отчасти основывается на семантике включения, т.е. суперкласс как огромное количество объектов включает все огромного количества объектов подклассов, хотя некие операции не соответствуют данной для нас семантике.
Мысль нашего предложения основывается на последующем наблюдении. Посреди операций реляционной алгебры имеются два вида операций: теоретико-множественные операции и операция селекции сформировывают из операндов-отношений отношение-результат с той же схемой; операции же проекции и соединения сформировывают отношение-результат со схемой, которая в общем случае не описывалась статически в составе схемы БД, т.е. в иной терминологии эти операции сформировывают не только лишь
Встает вопросец: почему бы не попробовать распространить схожий подход на классы объектов? Может быть, к примеру, последующее неформальное определение алгебры классов объектов. Эта алгебра включает набор теоретико-множественных операций, также операции декартова произведения, селекции и проекции. Теоретико-множественные операции определяются для «однотипных» классов, и класс результата помещается в сетку классов схемы БД в согласовании с семантикой включения. (Во время вычисления алгебраического выражения сразу формируется соответственный временный вариант сетки классов.) Операция декартова произведения сформировывает класс, включающий объединение наборов способов классов-операндов и являющийся их подклассом. Операция селекции сформировывает класс, являющийся подклассом класса-операнда. Операция проекции сформировывает класс, включающий обозначенное подмножество способов класса-операнда и являющийся его суперклассом. С внедрением операций декартова произведения и проекции можно найти операцию соединения классов. Можно расширить алгебру операцией присваивания, и в этом случае класс, которому присваивается итог алгебраического выражения должен быть определен в схеме БД заблаговременно.
5. Ограничения
5.1 Ограничения систем неизменного хранения.
одна из целей современных ООБД — унификация языков программирования и баз данных в одном языке (к примеру, С++ либо Smalltalk). Эта цель вызвана текущим положением дел, когда прикладные программки пишутся на всепригодном языке программирования (в главном, COBOL, FORTRAN, PL/I, С), а интегрированные в приложение функции управления базой данных — на языке базы данных (к примеру, SQL). Всепригодный язык программирования и язык базы данных очень различны по синтаксису и модели данных (структурам и типам данных), и необходимость учить и употреблять два различных языка при разработке приложений баз даннь~х нередко рассматривается как основной недочет. Так как C++ и Smalltalk уже включают средства для определения классов и их иерархии (т.е. определения данных), эти языки являются неплохой основой для унификации. 1-ый шаг, предпринятый производителями ранешних ООБД, заключался в том, чтоб создать неизменными кроссы и экземпляры кроссов, другими словами поместить их во вторичную память и отдать возможность доступа к ним даже опосля окончания программ, которые их обусловили и сделали.
Большая часть современных ООБД не делают существенного шага вперед к полным способностям запросов по сопоставлению с РБД; они владеют ординарными средствами извлечения неизменных объектов. Так либо по другому, даже те ООБД, которые предоставляют неизменное хранилище для объектно-ориентированных языков, накладывают некие ограничения в определении неизменных данных. А именно, большая часть систем по-разному трактуют неизменные и непостоянные данные (к примеру, неприемлимо в неизменном объекте наличие идентификатора временного объекта); потому юзеры должны очевидно объявлять, неизменный объект либо нет. Не считая того, некие типы данных недозволено создать неизменными, и потому они запрещаются.
5.2 Ограничения систем баз данных.
2-ой, еще наиболее суровый, показатель незрелости большей части современных ООБД — недочет средств, к которым привыкли и которые ждут юзеры баз данных. В их число входят полный непроцедурный язык запросов, автоматическая оптимизация и обработка запросов, одновременный доступ, авторизация, динамическое изменение схем.
— Большая часть ООБД мучается от недочета средств запросов; обычно не предусматриваются вложенные подзапросы, операции над огромными количествами (объединение, пересечение, разность), функции агрегирования и группировки и т.д. — средства, вполне поддерживаемые в РБД.
— РБД автоматом устанавливают и снимают блокировки при обработке запросов, которые делают юзеры, а некие современные ООБД требуют, чтоб юзеры очевидно устанавливали и снимали блокировки.
— РБД поддерживают авторизацию, т.е. разрешают наделять (и лишать) юзеров преимуществами читать либо изменять данные остальных юзеров, также изменять определение отношений, сделанных иными юзерами. Большая часть же ООБД не поддерживает авторизации.
— РБД разрешают динамически изменять схему базы данных с помощью команды ALTER; можно добавить новейший столбец к отношению, можно удалить отношение, время от времени — удалить столбец из дела.
— РБД разрешают улучшить производительность системы, поддерживая огромное число характеристик, которые инсталлируются системным админом. Существенное число ООБД владеют ограниченными способностями опции.
6. Заключение
Объектно-ориентированные БД в наиблежайшее время сумеют занять достойное пространство на рынке ПО . В крайнее десятилетие объектно-ориентированная разработка отыскала свое пространство в языках программирования, пользовательских интерфейсах, базах данных, операционных системах… Продукты, помеченные как объектно-ориентированные системы баз данных, возникли на рынке, а производители реляционных систем баз данных объявляют, что они расширяют свои продукты объектно-ориентированными способностями.
По мере укрепления рынка ООБД, будут создаваться группы поддержки, которые будут заниматься лишь продажей и поддержкой опций. В данной для нас области принципиально сделать обычный механизм импорта / экспорта опций. Потому вырастет актуальность повсеместного внедрения UML как средства хранения описаний объектов, интерфейсов и программных комплексов в целом. Эти же средства можно будет использовать для оценки свойства ПО .
Перечень
использованной литературы:
1. Объектно-ориентированные базы данных — главные концепции, организация и управление. Лаконичный обзор: [электрический ресурс].- Электрон. дан. — Режим доступа:
HTTP://www.citforum.ru/database/articles/art_24.html
– загл. с экрана.
2. Объектно-ориентированные базы данных: [электрический ресурс].- Электрон. дан.- Режим доступаhttp://www.p-stone.ru/libr/db/teoretic/data/public3/– загл. с экрана.
3. Объектно-ориентированные базы данных: среда разработки программ плюс хранилище объектов: [электрический ресурс].- Электрон. дан.- Режим доступа:
HTTP://old.ulstu.ru/people/SOSNIN/umk/Basis_of_Artificial_Intelligence/mirrors/inteltec/www.inteltec.ru/publish/articles/objtech/oodbms_o.shtml.html— загл. с экрана.
4. Разработка объектно-ориентированных баз данных: [электрический ресурс].- Электрон. дан.- Режим доступа:
HTTP://db.snipetz.com/oobd.htm#VVVOOBD– загл. с экрана.]]>