Размещено на http://www.allbest.ru/

2

Оглавление

Введение

1. Объектно-ориентированный подход

1.1 Объектно-реляционные методы

1.2 Стандарты объектных баз данных

2. Объектно-ориентированные базы данных

2.1 ODBMS

2.2 Спорные моменты технологии

Заключение

Список использованных источников

Введение

Информационные технологии занимают прочное место в нашей жизни. Хотя изначально компьютеры создавались для численных расчетов, скоро выяснилось, что они могут обрабатывать и другие виды информации. Ведь любая информация может быть представлена в числовой форме. Необходимы лишь средства для преобразования нужного вида информации в числовую форму и обратно. Поэтому история развития компьютеров тесно связана с таким направлением деятельности человека как программирование и представляет собой историю непрерывного движения от языка и уровня коммуникации машины к уровню пользователя. На начальном этапе применялись так называемые языки низкого уровня (машинные языки и машинно-ориентированные языки), которые требовали указания мелких деталей процесса обработки данных. Позднее были созданы языки высокого уровня, имитирующие естественные языки, используя некоторые слова разговорного языка и математические символы. Они более удобны для человека и делятся на:

· процедурные (алгоритмические) (Basic, Pascal, C и др.), которые предназначены для однозначного описания алгоритмов; для решения задачи процедурные языки требуют в той или иной форме явно записать процедуру ее решения;

· логические (Prolog, Lisp и др.), которые ориентированы не на разработку алгоритма решения задачи, а на систематическое и формализованное описание задачи с тем, чтобы решение следовало из составленного описания;

· объектно-ориентированные (Object Pascal, C++, Java и др.), в основе которых лежит понятие объекта, сочетающего в себе данные и действия над нами. Программа на объектно-ориентированном языке, решая некоторую задачу, по сути описывает часть мира, относящуюся к этой задаче. Описание действительности в форме системы взаимодействующих объектов естественнее, чем в форме взаимодействующих процедур..

История развития систем управления базами данных (СУБД), в свою очередь, начиналась с модели записей и индексов (ISAM и др.), позднее приобретя способность восстановления после сбоев, проверки целостности данных и возможности работы нескольких пользователей одновременно. Эти ранние модели данных (CODASYL) можно отнести скорее к уровню машинной ориентации. Позднее появились реляционные базы данных, которые приобрели механизм запросов, позволявший пользователю указать требуемое ему, предоставив СУБД самой найти результат оптимальным образом, используя динамическую индексацию.

Разработка систем объектно-ориентированных баз данных началась ещё в середине 80-х годов в связи с необходимостью удовлетворения требований приложений, отличных от тех приложений обработки данных, которые характерны для систем реляционных баз данных. Попытки использования технологий реляционных баз данных в таких сложных приложениях, как автоматизированное проектирование (CAD); автоматизированное производство (CAM); технология программирования; системы, основанные на знаниях, и мультимедийные системы, обнажили ограничения систем реляционных баз данных. В условиях, когда появилось новое поколение приложений баз данных, возникли потребности, которые лучшим образом удовлетворялись при применении объектно-ориентированных баз данных.

Актуальность выбранной темы курсовой работы состоит в том, что СУБД служит посредником между пользователями и базой данных.

Цель данной курсовой работы - изучение и определение объектно - ориентированный подход к проектированию базами данных.

Для достижения поставленной цели в курсовой работе необходимо решить следующие задачи:

· определить объектно-ориентированный подход;

· рассмотреть объектно-реляционные методы;

· дать характеристику объектно-ориентированным базам данных;

· определить спорные моменты технологии.

Структура курсовой работы. Работа включает введение, две главы, параграфы, заключение и список использованных источников.

1. Объектно-ориентированный подход

1.1 Объектно-реляционные методы

Объектно-ориентированный подход при создании систем управления базами данных дает возможность упаковывать вместе данные и код для их обработки. Тем самым, фактически снимаются ограничения на типы данных, что позволяет работать на любом уровне абстракции.

Однако во всем мире очень широкое развитие получили реляционные СУБД и многие организации не уверены, что немалые затраты, которые связаны с переходом на объектно-ориентированные базы данных, скоро окупятся [5, c.4].

Компромиссным является комбинированный подход, который дает возможность пользователям воспользоваться достоинствами объектно-ориентированных баз данных, не отказываясь при этом полностью от своих реляционных баз данных.

Применение объектных расширений и дополнений к существующим реляционным СУБД часто является более экономичной альтернативой. Такие компромиссные решения дают возможность поддержать баланс между объектами и реляционными таблицами.

Размещено на http://www.allbest.ru/

2

Объектно-реляционные адаптеры. Применение объектно-реляционного адаптера позволяет автоматически выделять программные объекты и сохранять их в реляционных БД. В данном случае объектно-ориентированное приложение работает как рядовой пользователь СУБД.

Такой подход дает программистам возможность полностью сконцентрироваться на объектно-ориентированной разработке, несмотря на небольшое снижение производительности. Также, все имеющиеся на предприятии приложения могут по-прежнему обращаться к данным, которые хранятся в реляционной форме. Например, объектно-реляционный адаптер Odapter фирмы Hewlett-Packard для СУБД Oracle, можно с успехом применять во многих областях, например в качестве связующего программного обеспечения, которое объединяет объектно-ориентированные приложения с реляционными базами данных.

Некоторые из существующих объектных СУБД, например GemStone, могут сами выступить в роли объектно-реляционного адаптера, тем самым давая возможность объектно-ориентированным приложениям обращаться к реляционным базам данных.

Объектно-реляционные шлюзы. В данном случае пользователь взаимодействует с базой данных с применением языка ООСУБД, а используемый шлюз производит замену всех объектно-ориентированных элементов такого языка на их реляционные компоненты. Недостатком данного способа также является снижение производительности. К примеру, объектно-реляционный шлюз должен осуществить преобразование объектов в набор связей, генерацию оригинальных идентификаторов (OID) объектов и потом передать их в реляционную базу данных. Далее шлюз должен каждый раз при использовании интерфейса реляционной базы данных преобразовывать OID, найденный в базе, в соответствующий объект, который сохранен в реляционной СУБД [10, c.32].

Отметим, что производительность работы в рассмотренных выше двух подходах зависит от способа доступа к реляционной БД. Каждая такая база данных включает два уровня: уровень управления данными (data manager layer) и уровень управления носителем (storage manager layer). Уровень управления данными производит обработку операторов на языке SQL, а уровень управления носителем отображает данные в базу. Адаптер или шлюз могут взаимодействовать как с уровнем данных (обращаться к реляционной БД при помощи языка SQL), так и с уровнем носителя (использовать вызовы процедур низкого уровня). В первом случае производительность намного ниже. Примером может служить система OpenODB компании Hewlett-Packard, которая может выполнять роль шлюза, поддерживаемую только на высоком уровне.

Гибридные СУБД. Еще одним решением является создание гибридных объектно-реляционных СУБД, которые могут хранить как традиционные табличные данные, так и объекты. Ведущие поставщики реляционных СУБД начинают добавлять к своим продуктам объектно-ориентированные средства. Например, Sybase и Informix ввели в поддержку объектов СУБД. Подобные разработки вводят и другие независимые компании. К примеру, компания Shores оснастила объектно-ориентированными средствами СУБД Oracle8.

Производители объектных СУБД, такие как фирма Object Design, понимают, что объектно-ориентированные БД в обозримом будущем не заменят полностью реляционные базы данных. Поэтому они создают шлюзы, поддерживающие реляционные и иерархические базы данных, или различного рода интерфейсы. Наглядным примером такого интерфейса является объектно-реляционный интерфейс Ontos Integration Server компании Ontos, который применяется в сочетании с ее ООСУБД Ontos/DB .

1.2 Стандарты объектных баз данных

Несколько наиболее крупных компаний-разработчиков образовали группу Object Database Management Group (ODMG) с целью определения стандартов, необходимых для ООСУБД. В состав этой группы в настоящее время входят компании Sun Microsystems, eXcelon Corporation, Objectivity Inc., POET Software, Computer Associates и Versant Corporation. Группа ODMG создала объектную модель, в которой определяется стандартная модель семантики объектов базы данных. Эта модель имеет очень большое значение, поскольку в ней определена встроенная семантика, которая может быть отражена и предписана в ООСУБД. Проект библиотек классов и приложений, в которых применяется эта семантика, должен быть переносимым во все ООСУБД, в которых поддерживается эта объектная модель.

Ниже перечислены основные компоненты архитектуры ODMG для ООСУБД.

· Объектная модель (Object Model -- ОМ).

· Язык определения объектов (Object Definition Language -- ODL).

· Размещено на http://www.allbest.ru/

2

Язык объектных запросов (Object Query Language -- OQL).

· Средства связывания объектной модели с объектами языков C++, Java и Smalltalk.

Первая версия стандарта ODMG была выпущена в 1993 году.

С тех пор было выпущено несколько небольших поправок к ней, а следующая обновленная версия ODMG 2.0 была принята в сентябре 1997 года. Она включает следующие дополнения:

· новые средства связывания объектной модели с объектами языка программирования Java компании Sun;

· полностью пересмотренная версия объектной модели с новой метамоделью, поддерживающей семантику объектной базы данных во многих языках программирования;

· стандартная внешняя форма для данных и схемы данных, обеспечивающая обмен данными между базами данных.

В конце 1999 года была выпущена версия ODMG 3.0, в которую вошел целый ряд дополнений к объектной модели и средствам связывания Java. В период между выпусками версий 2.0 и 3.0 группа ODMG расширила свой устав и включила в него разработку спецификаций универсальных стандартов хранения объектов. В тот же период группа ODMG изменила расшифровку аббревиатуры своего обозначения с Object Database Management Group на Object Data Management Group в соответствии с расширением своих обязанностей, которые вышли за пределы задач простой разработки стандартов хранения для объектных баз данных [4, c.32].

Стандарт на хранение объектов ODMG разработан на основе трех существующих стандартов: управление базами данных (SQL), объекты (стандарты OMG - Object Management Group) и стандарты на объектно-ориентированные языки программирования (C++, Smalltalk, Java).

ODMG добавляет возможности взаимодействия с базами данных в объектно-ориентированные языки программирования: определяются средства долговременного хранения объектов и расширяется семантика языка, вносятся операторы управления данными. Стандарт состоит из нескольких частей:

Размещено на http://www.allbest.ru/

2

Объектная модель - унифицированная основа всего стандарта. Она расширяет объектную модель консорциума OMG за счет введения таких свойств как связи и транзакции для обеспечения функциональности, требуемой при взаимодействии с базами данных. Ключевые концепции объектной модели ODMG:

· наделение объектов такими свойствами как атрибуты и связи

· методы объектов (поведение)

· множественное наследование

· идентификаторы объектов (ключи)

· определение таких совокупностей объектов как списки, наборы, массивы и т.д.

· блокировка объектов и изоляция доступа

· операции над базой данных

Язык описания объектов ODL - средство определения схемы базы данных (по аналогии с DDL в реляционных СУБД). ODL является расширением IDL (Interface Definition Language - язык описания интерфейсов) модели OMG и предоставляет средства для определения объектных типов, их атрибутов, связей и методов. ODL создает слой абстрактных описаний так, что схема базы данных становится независима как от языка программирования, так и от СУБД. ODL рассматривает только описание объектных типов данных, не вдаваясь в детали реализации их методов. Это позволяет переносить схему БД между различными ODMG-совместимыми СУБД и языками программирования, а также транслировать ее в другие DDL.

Приведем пример из “белой книги” фирмы Objectivity [4, с. 79-90] на языке ODL, иллюстрирующий связи типа “один-ко-многим”, которые объявлены между преподавателем и студентами:

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 - это SQL - подобный декларативный язык, который предоставляет эффективные средства для извлечения объектов из базы данных, включая высокоуровневые примитивы для наборов объектов и объектных структур. Синтаксис оператора SELECT, определенный SQL-92, является подмножеством OQL, это гарантирует, что SELECT-утверждения, выполняемые над реляционными таблицами, сохранят работоспособность и с наборами объектов ODMG. OQL-запросы могут вызываться из ОО-языка, точно также из OQL-запросов могут делаться обращения к процедурам, написанным на OO-языке. OQL предоставляет средства обеспечения целостности объектов (вызов объектных методов и использование собственных операторов изменения данных).

Приведем некоторые примеры на языке 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++, Smalltalk и Java определяет OML (Object Manipulation Language) - язык манипулирования объектами, который расширяет базовые ОО-языки средствами манипулирования и хранения объектов. Также включаются OQL, средства навигации и поддержка транзакций. Каждый ОО-язык имеет свой собственный OML, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программирования и доступа к данным.

Взаимодействие с другими стандартами. Многие стандарты обладают совместимостью с объектными БД, например CFI, STEP, ISO ODP, TINA-C, X3H7, ANSI OpenGIS и др. В настоящее время они могут напрямую взаимодействовать с любой стандартной объектно-ориентированной СУБД, хотя в ряд из них и были для обеспечения совместимости внесены изменения. Следующие два стандарта заслуживают более подробного описания - это OMG и SQL.

Размещено на http://www.allbest.ru/

2

Стандарты OMG. Первым результатом деятельности OMG стало утверждение архитектуры брокера объектных запросов CORBA (Common Object Request Broker Architecture) - средства для диспетчеризации запросов между объектами и пользователями; в дальнейшем также были добавлены ряд других сервисов. В настоящее время интерфейс ODMG полностью адаптирован к спецификации Persistence Object Service консорциума OMG, что дает возможность пользователям систем, которые основаны на архитектуре CORBA, использовать преимущества от объектно-ориентированных СУБД, которые могут содержать объекты, отвечающие стандарту OMG и используемые так же, как и любые другие (“мелкие”) объекты спецификации OMG. В свою очередь объекты OMG доступны через интерфейс ODMG.

Язык SQL. Из-за своей распространенности SQL был заложен в основу OQL, который был дополнен средствами поддержки объектной модели. В 1999 году была разработана версия языка SQL, известная под названием SQL3, в которой была добавлена поддержка регулярных выражений, рекурсивных запросов, поддержка триггеров, базовые процедурные расширения, нескалярные типы данных и некоторые объектно-ориентированные возможности. В отличие от ODMG, в SQL не планируется привязка к ODL, а также C++ и Smalltalk, которые важны для пользователей объектно-ориентированных СУБД. Несмотря на это, возможности SQL3 в организации запросов совпадают с возможностями OQL.

2. Объектно-Ориентированные базы данных

2.1 ODBMS

Рассмотрим преимущества и недостатки, которыми обладают объектно-ориентированные СУБД.

Объектно-ориентированные базы данных (ODBMS - Object-oriented Database Management System) применяют с конца 1980-х для обеспечения управления БД приложений, которые построены в соответствии с концепцией объектно-ориентированного программирования. Объектная технология позволяет расширить традиционную методику разработки приложений новым моделированием данных и новыми методами программирования. В объектном программировании для улучшения сохранности целостности данных и повторного применения кода, данные и код для их обработки организуются в объекты. Таким образом, практически полностью снимаются ограничения на типы данных [14, c.67].

Если данные состоят из коротких, простых полей фиксированной длины (имя, адрес, телефон, баланс счета), то оптимальным решением будет использование реляционной БД. Но если данные содержат вложенную структуру, имеют динамически изменяемый размер, определяемые пользователем произвольные структуры (например, мультимедиа), то их представление в табличной форме будет представлять определенную сложность. Тогда как в объектно-ориентированной СУБД каждая определенная пользователем структура является объектом, который непосредственно управляется базой данных.

В реляционной СУБД связи управляются пользователем, который создает внешние ключи. Далее для обнаружения связей во время выполнения система динамически просматривает две (или больше) таблицы и сравнивает внешние ключи до достижения соответствия. Этот процесс, который называется объединением (join), является слабой стороной реляционной технологии. Наличие более двух или трех уровней объединений является сигналом для поиска лучшего решения. В объектно-ориентированной СУБД пользователь просто объявляет связь, и далее СУБД автоматически генерирует методы управления, динамически создавая, удаляя и пересекая связи. Ссылки при этом прямые, поэтому нет необходимости в просмотре и сравнении или даже поиске индекса, что может сильно отразиться на производительности. Таким образом, использование объектной модели более предпочтительно для БД с большим количеством сложных связей: перекрестных ссылок, ссылок, которые связывают несколько объектов с несколькими (many-to-many relationships) двунаправленными ссылками.

В отличие от реляционных СУБД, объектно-ориентированные СУБД полностью поддерживают объектно-ориентированные языки программирования. Программисты, которые применяют С++ или Smalltalk, имеют дело с одним набором правил позволяющим использовать такие преимущества объектной технологии, как полиморфизм, наследование и инкапсуляция. Ему нет необходимости прибегать к трансляции объектной модели в реляционную и наоборот. Прикладные программы обращаются и функционируют с объектами, которые сохранены в БД, использующей стандартную объектно-ориентированную семантику языка и операции. В реляционной БД необходимо, чтобы разработчик транслировал объектную модель к поддерживаемой модели БД и включил подпрограммы для обеспечения этого отображения во время выполнения. Следствием этого является потребность в дополнительных усилиях при разработке, а также уменьшение эффективности.

Объектно-ориентированные СУБД также подходят (тоже без трансляций между объектной и реляционной моделями) для организации распределенных вычислений. Традиционные БД (в том числе и реляционные и некоторые объектные базы данных) построены вокруг центрального сервера, который выполняет все операции над базой. Данная модель мало отличается от мэйнфреймовой организации 1960-х годов с центральной ЭВМ - мэйнфреймом (mainframe), которая производила все вычисления, и пассивных терминалов. Главным недостатком такой архитектуры является вопрос масштабируемости. В настоящее время вычислительную мощность рабочих станций (клиентов) составляет порядка 30 - 50 % от мощности сервера БД, то есть значительная часть вычислительных ресурсов распределена между клиентами. Поэтому все больше приложений, и в первую очередь СУБД и средства принятия решений, в настоящее время работают в распределенных средах, в которых объекты (объектные программные компоненты) распределены по многим рабочим станциям (клиентам) и серверам и в которых любой пользователь может получить доступ к любому объекту. С помощью стандартов межкомпонентного взаимодействия все эти фрагменты кода комбинируются друг с другом независимо от аппаратного, программного обеспечения, операционных систем, сетей, языков программирования, компиляторов, различных средств организации запросов и формирования отчетов и динамически изменяются при манипулировании объектами без потери работоспособности.

2.2 Спорные моменты технологии

Все объектно-ориентированные СУБД по определению поддерживают сохранение и разделение объектов. Но, как только дело касается практической разработки приложений, на разных объектно-ориентированные СУБД, проявляется различия в реализации поддержки трех характеристик:

· Целостность;

· Масштабируемость;

· Отказоустойчивость.

Отметим, что в объектно-ориентированных БД не требуются многие из тех внутренних функций и механизмов, которые привычны и необходимы в реляционных БД. Например, при небольшом количестве пользователей, длинных транзакциях и малой загрузке сервера объектно-ориентированные СУБД не требуют поддержки сложных механизмов резервного копирования/восстановления данных Связано это с тем, что исторически первые объектно-ориентированные БД были спроектированы для поддержки небольших рабочих групп (порядка десяти человек) и не были приспособлены для обслуживания сотен пользователей. Однако со временем технология БД созрела для крупных проектов.

Чтобы проиллюстрировать первую категорию рассмотрим механизм кэширования объектов. Большинство объектно-ориентированных СУБД помещают код приложения непосредственно в то же адресное пространство, в котором работает сама СУБД. Этим достигается повышение производительности на 1-2 порядка по сравнению с раздельными адресными пространствами. Однако надо учитывать, что при такой модели объект с ошибкой может повредить объекты и разрушить базу данных.

В настоящее время существуют несколько подходов к организации реакции СУБД для предотвращения потери данных. Большинство СУБД передают приложению указатели на объекты, и с неизбежностью такие указатели обязательно со временем становятся неверными. Например, они всегда неправильны после перехода объекта к другому пользователю (например, после перемещения на другой сервер). Если программист, который разрабатывает приложение, пунктуален, то такой ошибки не возникает. Если же приложение попытается использовать указатель в неподходящий для этого момент, то в лучшем случае произойдет крах СУБД, а в худшем случае будет потеряна информация в середине другого объекта и нарушится целостность БД.

Однако есть метод, лучший, чем применение прямых указателей. СУБД добавляет дополнительный указатель и в случае необходимости, если объект перемещается, то система может автоматически разрешить ситуацию (перезагрузить, если это необходимо, объект) без возникновения конфликтной ситуации. В случае применения косвенной адресации также можно отслеживать частоту вызовов объектов для организации эффективного механизма свопинга. Это является необходимым для реализации уже второго необходимого свойства БД - масштабируемости. Здесь опять необходимо упомянуть организацию распределенных компонентов. Классическая схема клиент-сервер, в которой основная нагрузка приходится на клиента (так называемая архитектура “толстый клиент - тонкий сервер”), лучше справляется с этой задачей, чем мэйнфреймовая структура, но ее все равно нельзя масштабировать до уровня предприятия. Благодаря многозвенной архитектуре клиент-сервер (N-Tier architecture) вычислительная нагрузка равномерно распределяется между сервером и конечным пользователем. Нагрузка распределяется по трем и более звеньям, которые обеспечивают дополнительную вычислительную мощность. Здесь можно привести цитату из журнала «PC Magazine»: “Архитектура клиент-сервер, которая еще совсем недавно считалась сложной средой, постепенно превратилась в исключительно сложную среду. Почему? Благодаря ускоренному переходу к использованию систем клиент-сервер нескольких звеньев”.

Поэтому разработчикам БД приходится расплачиваться дополнительными сложностями, большими затратами времени и множеством проблем, которые связаны с интеграцией.

Третье необходимое качество БД - это отказоустойчивость. Именно отказоустойчивость отличает качественный программный продукт от “прилады”.

Существуют несколько способов для обеспечения отказоустойчивости системы:

· резервное копирование и восстановление;

· распределение компонентов;

· независимость компонентов;

· копирование.

Руководствуясь принципом резервного копирования и восстановления, программист определяет потенциально опасные участки кода и вставляет в программу определенные действия, которые соответствуют началу транзакции - сохранение информации, необходимой для восстановления после сбоя, и окончанию транзакции - восстановление или, в случае невозможности, принятие каких-то других мер, например, отправка системного сообщения администратору.

В современных СУБД данный механизм обеспечивает восстановление системы в случае возникновения практически любой ошибки системы, приложения или компьютера, хотя, конечно, речь не идет об идеальной защите от сбоев.

В архитектуре мэйнфрейма единственным источником сбоев являлась центральная ЭВМ.

После перехода к распределенной многозвенной организации ошибки могут вызвать не только компьютеры, которые включены в сеть, но и коммуникационные каналы. В многозвенной архитектуре при сбое одного из звеньев без специальных мер защиты результаты работы других звеньев окажутся бесполезными.

Поэтому при разработке распределенных систем необходимо обеспечивать принципиально более высокий уровень отказоустойчивости системы [6, c.98].

Для современных распределенных СУБД обязательными являются следующие свойства:

· прозрачный доступ ко всем объектам системы независимо от их местоположения, благодаря чему пользователю становятся доступны все сервисы СУБД и может производиться перераспределение компонентов без нежелательных последствий.

· трехфазный монитор транзакций (third-party transaction monitor), благодаря которому транзакция выполняется не в два, а в три этапа - предварительно посылается запрос о готовности к транзакции.

В случае, если какой-то компонент выйдет из строя, то система приостановит работу всех пользователей и прервет все транзакции. Поэтому большое значение имеет такое свойство СУБД, как независимость компонентов.

В случае сетевого сбоя сеть разделяется на части, компоненты каждой из которых не могут сообщаться с компонентами другой части. Для сохранения возможности для работы внутри каждой такой части, необходимо обеспечить дублирование критически важной информации внутри каждого сегмента.

Современные СУБД позволяют администратору базы данных динамически определять сегменты сети, меняя таким образом уровень надежности всей системы в целом.

Копирование (replication) данных. Простейшим способом копирования данных является добавление к каждому (основному) серверу резервного. После каждой операции основной сервер передает измененные данные резервному серверу, который, в случае выхода из строя основного сервера, автоматически включается в работу. Разумеется, такая схема работы не лишена недостатков.

Перечислим данные недостатки:

1. Такой способ приводит к значительным накладным расходам при дублировании данных. Это не только отражается на производительности системы, но и само по себе становится потенциальным источником сбоев.

2. Если сбой повлек за собой разрыв соединения между двумя серверами, то каждый из них станет работать в своем сегменте сети в качестве основного сервера. В таком случае изменения, которые будут сделаны на серверах за время работы в таком режиме, будет невозможно синхронизовать даже после восстановления работоспособности сети.

Представляется более совершенным подход при котором создается необходимое (подбираемое в соответствии с требуемым уровнем надежности) число копий в сегменте.

Тем самым увеличивается доступность копий и даже (при распределении нагрузки между серверами) происходит повышение скорости чтения. Проблема невозможности обновления данных несколькими серверами одновременно в случае их взаимной недоступности решается за счет разрешения проведения модификаций только в одном из сегментов (например, имеющее наибольшее число пользователей).

При хорошо настроенной схеме кэширования затраты на накладные расходы при дублировании модифицированных данных близки к нулю.

Заключение

Рассмотрим основные достижения и проблемы, связанные с нынешним состоянием ООСУБД.

Причиной появления систем объектно-ориентированных баз данных была потребность в более адекватном представлении и моделировании сущностей реального мира, поскольку ООСУБД обеспечивают гораздо более развитую модель данных, нежели традиционные -- реляционные базы данных. Парадигма ООСУБД основывается на ряде базовых понятий, таких как объект, идентифицируемость, класс, наследование, перегрузка и отложенное связывание.

В объектно-ориентированной модели данных любая сущность реального мира представляется всего одним понятием -- объектом. С объектом ассоциируется состояние и поведение. Состояние объекта определяется значениями его свойств -- атрибутов. Значениями свойства могут являться примитивные значения (такие, как строки или целые числа) и непримитивные объекты. Непримитивный объект, в свою очередь, состоит из набора свойств. Следовательно, объекты можно рекурсивно определять в терминах других объектов. Поведение объекта определяется с помощью методов, которые оперируют над состоянием объекта.

Объектно-ориентированные базы данных позволяют представлять сложные объекты более непосредственным образом, нежели реляционные системы.

Системы ООСУБД позволяют пользователям определять абстракции; облегчают проектирование некоторых связей; устраняют потребность в определяемых пользователями ключах; поддерживают новый набор предикатов сравнения; в некоторых случаях устраняют потребность в соединениях; в некоторых ситуациях обеспечивают более высокую производительность, нежели системы, основанные на реляционной модели; обеспечивают поддержку версий и длительных транзакций. Наконец, разработана объектная алгебра -- хотя, возможно, пока и не столь детально, как реляционная алгебра.

До последнего времени ООСУБД на рынке относились к области риска. С одной стороны, имеется много примеров удачного использования этих продуктов в реализованных приложениях. С другой стороны, сектор рынка ООСУБД очень узок и пока не может приносить больших доходов. Как следствие, сравнительно стабильно существует ряд продуктов ООСУБД. Крупные софтверные компании, такие как Oracle, Informix, Sybase, Microsoft и IBM, не собираются развивать свою линию продуктов ООСУБД. Вместо этого они предлагают свои подходы к расширению реляционных баз данных объектными свойствами. Однако на технологию объектно-ориентированных баз данных серьезное внимание обратила одна из крупнейших софтверных компаний Computer Associates, которая приняла решение о стратегическом партнерстве с японской компанией Fujitsu и о фактическом приобретении ее продукта ООСУБД Jasmine. В исходном продукте не было ничего принципиально нового, но новым было то, что ООСУБД заинтересовалась одна из лидирующих софтверных компаний. Это означает новый уровень доводки продукта до промышленного образца, новый уровень рекламы и маркетинга. В настоящее время при планировании информационной системы имеется выбор между чисто реляционными, объектно-реляционными и объектно-ориентированными системами баз данных. Чисто реляционные системы слегка туповаты (обратная сторона простоты и эффективности), но зато спокойно справляются с терабайтами информации. Объектно-реляционные системы привлекают тем, что не заставляют полностью пересматривать свой способ мышления и обещают тот же уровень надежности, эффективности и масштабируемости, что чисто реляционные системы. Наконец, объектно-ориентированные СУБД предоставляют новый, привлекательный способ создания информационных систем, но пока не обладают коммерческими качествами реляционных систем.

Список использованных источников

1. Гуде С.В., Ревин С.Б. Информационные системы. Учебное пособие. /[Текст] С.В Гуде. -М., 2012. - 67 c.

2. Дунаев С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. /[Текст] С.Дунаев - М., 2015. - 65 c.

3. Информатика: Учебник /[Текст] Каймин В.А., 2-е изд. перераб. и доп. - М: Инфра-М., 2012. - 134 c.

4. Информатика: Учебник /[Текст] Под ред. Н.В.Макаровой, 3-е изд., перераб. и доп. - М.: Финансы и статистика, 2011. - 67 c.

5. Информатика: Учебник для вузов /[Текст] Острейковский В.А., М: Высшая школа, 2011. - 654 c.

6. Информатика: Учебник для вузов/[Текст] Козырев А.А. - СПб., 2012. - 54 c.

7. Мейер Д. Теория реляционных баз данных: пер. с англ. /[Текст] Д. Мейер - М., 2015. - 76 c.

8. Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов /[Текст] Г.И. Ревунков - Под ред. В.Н.Четверикова. - М., 2013. - 532 c.

9.Фаронов В.В., Шумаков П.В. Руководство разработчика баз данных. /[Текст] В.В. Фаронов - М.: Нолидж, 2010. - 67 c.

10.Фундаментальные основы информатики: социальная информатика.: Учебное пособие для вузов /[Текст] Колин К.К. - М.: Академ.проект: Деловая книга Екатеринбург, 2010. - 74 c.

11. Атре Ш. Структурный подход к организации баз данных. /[Текст] Ш. Атре - М.: Финансы и статистика, 2013. - 320 с.

12. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. /[Текст] В.В. Бойко- М.: Финансы и статистика, 2012. - 351 с.

13. Дейт К. Руководство по реляционной СУБД DB2. /[Текст] К. Дейт - М.: Финансы и статистика, 2012. - 320 с.

14. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. /[Текст] Г. Джексон - М.: Мир, 2013. - 252 с.

15. Кириллов В.В. Структуризованный язык запросов (SQL). /[Текст] В.В. Кириллов - СПб.: ИТМО, 2011. - 80 с.

16. Мартин Дж. Планирование развития автоматизированных систем. /[Текст] Дж. Мартин - М.: Финансы и статистика, 2010. - 196 с.

17. Мейер М. Теория реляционных баз данных. /[Текст] М. Мейер - М.: Мир, 2012. - 608 с.

18. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., /[Текст] Тиори Т.- М.: Мир, 2012. Кн. 1. - 287 с.: Кн. 2. - 320 с.

19. Ульман Дж. Базы данных на Паскале. /[Текст] Дж. Ульман - М.: Машиностроение, 2012.-386 с.

20. Хаббард Дж. Автоматизированное проектирование баз данных. /[Текст] Дж. Хаббард- М.: Мир, 2012. - 294 с.

21. Цикритизис Д., Лоховски Ф. Модели данных. /[Текст] Д. Цикритизис - М.: Финансы и статистика, 2012. - 344 с.

Размещено на Allbest.ru

...