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

Вид материала

Документы

Содержание From customer From customer FTpaeimo 1. Система должна поддерживать сложные объекты. Правило 2. Система должна поддерживать идентификацию объекта. Правшго 3. Объекты должны быть инкапсулированы. Правило 4. Система должна поддерживать типы или классы. Правило 7. Система должна быть законченной в вычислительном отношении. Правило 8. Система должна быть расширяемой. Правило 9. Система должна помнить местонахождение данных. Правило 10. Система должна обеспечивать возможность управления большими ба­зами данных. Правило 13. Запросы к данным должны быть простыми. Поддержка множественного наследования. Поддержка распределенных ООСУБД. Поддержка контроля версий. 11.7. Влияние объектно-ориентированного подхода на проектирование баз данных 11.8.00СУБД: преимущества и недостатки 11.9. Влияние объектно-ориентированных представлений на реляционную модель IBM представляет собой проверенную базу данных, которая используется более чем в 1000 корпораций. Система IBM 11.10. Новое поколение Основные термины ... Полное содержание

Подобный материал:

• Системы управления базами данных (субд). Назначение и основные функции, 30.4kb.
• Программа курса лекций "Базы данных в научных исследованиях", 49.32kb.
• Система управления базами данных это комплекс программных и языковых средств, необходимых, 150.5kb.
• Лекция 2 Базы данных, 241.25kb.
• Любая программа для обработки данных должна выполнять три основных функции: ввод новых, 298.05kb.
• Вопросы к государственному экзамену по специальности «Информационные системы и технологии», 39.93kb.
• Лекция № Технологии баз данных, 92.24kb.
• Проектирование базы данных, 642.58kb.
• Системы управления базами данных, 313.7kb.
• Программа дисциплины Системы управления базами данных Семестры, 22.73kb.

11.5.6. Доступ

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

SELECT *

FROM CUSTOMER

WHERE CUS_YTD_BUYS >= 5000;

Если значение параметра CUS_YTD_BUYS не определено, SQL "понимает", что условие означает "все значения" и сокращает оператор запроса следующим образом:

SELECT *

FROM CUSTOMER;

Поскольку семантика в ОО-модели данных более выраженная, в модели ООМД соз­дается схема, в которой связи составляют часть структуры БД. Доступ к пространст­ву структурированных объектов похож на доступ в режиме последовательной обра­ботки записей (record-at-time access) в старых иерархических и сетевых моделях, особенно при использовании языков 3GL или даже объектно-ориентированных языков программирования, поддерживаемых ООСУБД. Модель ООМД приспособ­лена для поддержки как навигационного (последовательного) доступа, так и досту­па, ориентированного на множественность значений. Навигационный доступ реали­зуется в ООМД напрямую с помощью идентификаторов OID, которые используются для навигации по структуре пространства объектов, разработанной программистом.

Ассоциативный доступ, ориентированный на множества, в ООМД осуществляется с помощью явно определенных методов. Поэтому проектировщик должен реализовать операции для манипуляции экземплярами объектов в схеме объекта. Реализация таких операций влияет на производительность БД и возможности управления дан­ными. Это было главной проблемой при появлении объектной модели: недостаточ­ная универсальность основных математических моделей для манипуляции данными. Отсутствие такого универсального доступа препятствует широкому распространению ООМД, поскольку каждая реализация требует создания собственной версии объект­но-ориентированного языка запросов (OQL, Object Query Language). OQL — это язык запросов к базе данных, используемый в ООСУБД. Конечно, различные поставщи­ки создают различные версии OQL, и это в свою очередь ограничивает возможность взаимодействия. Тем не менее, есть несколько групп (например, Object Management Group, OMG — рабочая группа по развитию стандартов объектного программирова­ния), которые в настоящее время работают над разработкой стандартов объектно-ориентированных технологий. Группа OMG очень интенсивно работает над созда­нием стандарта OQL².

² Во время написания этой книги OQL еще нельзя было считать стандартом 00. Зайдите на сайт 0MG (www.orag.org), чтобы посмотреть самую свежую информацию о разработке OQL.


В OQL нет стандартного способа манипулирования множествами, а в стандартном SQL реляционной модели нет возможности манипулирования объектами объектно-ориентированной БД. Однако различие между OQL и SQL несколько уменьшилось после опубликования ANSI нового стандарта SQL в 1999 году. Этот стандарт SQL, известный как SQL3 или SQL-99, ведет к интеграции объектно-ориентированных свойств и реляционных баз данных. Для получения более подробных сведений об этом стандарте см. документ ANSI/ISO/IEC за номером 9075, ч. 1—5 на www.ansi.org (щелкните мышью на nssn, затем введите "SQL" в окне поиска).

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

11.6. Объектно-ориентированная система управления базой данных (ООСУБД)





Рис. 11.34. Объектно-ориентированная СУБД

В течение последних нескольких лет управление данными и среда приложений ста­ли гораздо сложнее, чем могли себе это представить разработчики иерархических, сетевых или реляционных СУБД. Такие сложные структуры приложений могут проще всего обслуживаться объектно-ориентированными СУБД (ООСУБД). ООСУБД представляет собой СУБД, в которой используются все преимущества обычных сис­тем баз данных с мощными возможностями моделирования ООМД (рис. 11.34).





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

Некоторые продукты в области ООСУБД, такие как ObjectStore корпорации Object Design, Objectivity/DB корпорации Objectivity, Versant ODBMS корпорации Versant, ONTOS*Integrator корпорации ONTOS и FastObjects компании Poet Software, ис­пользуются при проектировании перечисленных ниже сложных систем.

• Медицинские приложения, управляющие цифровыми данными при рентгенов­ской съемке, магнито-резонансном и ультразвуковом сканировании вместе с тек­стовыми данными в медицинских исследованиях и при анализе истории болезни пациента.
  
• Финансовые приложения в управлении портфелем активов и рисковом управле­нии. Такие приложения отображают данные в реальном времени и основаны на
  многочисленных расчетах и агрегатных вычислениях над данными, извлекаемы­
  ми из сложных глобальных транзакций. Такие приложения могут управлять дан­ными, расположенными по "временным рядам", как неким типом данных, опре­деленным пользователем со своим внутренним представлением и методами.
  
• Телекоммуникационные приложения, например, приложения, управляющие
  конфигурацией коммуникационных сетей, которые автоматически наблюдают,
  отслеживают и переконфигурируют сеть на основе сотен параметров в реальном
  масштабе времени. Для поддержки своих телекоммуникационных приложений
  ООСУБД используют такие компании, как Ericsson, Ameritech и Bay Networks.
  Система Indium Global Communications System компании Motorola управляет
  сложной сетью спутников и наземных станций также с помощью ООСУБД.
  
• В эксперименте Стэндфордского центра Linear Accelerator BaBar Physics с помо­щью ООСУБД ежедневно вводится 1 терабайт данных.
  
• В системах автоматизированного проектирования (САПР) и системах автомати­зированного управления (САУ). В таких приложениях используются сложные
  отношения данных, а также множественные типы данных.
  
• В системах CASE (автоматизированная разработка программного обеспечения), создаваемых для управления большими объемами взаимосвязанных данных.
  
• Мультимедийные приложения, например, географические информационные сис­темы (геоинформационные системы, ГИС), в которых используются видео, звук
  и высококачественная графика, требующие специальных возможностей по управ­лению данными (например, перекрывание, вхождение, указание, обводка и вы­деление).
  

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


11.6.1. Возможности ООСУБД

Как показано на рис. 11.34, ООСУБД представляет собой результат комбинирования объектно-ориентрованных возможностей, таких как наследование класса, инкапсу­ляция и полиморфизм, с возможностями БД, такими как целостность, безопасность, непрерывность, управление транзакциями, управление параллельным выполнением, резервное копирование, восстановление, манипулирование данными и настройка системы. Публикация "Object-Oriented Database System Manifesto" (Atkinson и др., 1989)³ — первая внятная попытка определить возможности ООСУБД — включает 13 обязательных свойств, а также необязательные свойства ООСУБД. Эти трина­дцать правил представлены в табл. 11.4. Мы вкратце обсудим каждое из них.

Таблица 11.4. Тринадцать правил для ООСУБД



³ Malcolm Atkinson и др., "The Object-Oriented Database System Manifesto". Этот официальный документ впервые был представлен на I Международной Конференции по Дедуктивным и Объектно-Ориентированным Базам Данных (First International Conference on Deductive and Object-Oriented Databases), Киото, Япония, 1989 год. Его можно найти на сайте группы Object Data Management Group www.odmg.org. Выберите на этой странице White Papers, затем Database и The 00 Database System Manifesto. Здесь вы также сможете найти серию официальных доку­ментов, посвященных текущим (1997—1999) стандартам и расширениям правил. Эти докумен­ты разработаны для подтверждения манифеста и никоим образом его не подменяют.

• FTpaeimo 1. Система должна поддерживать сложные объекты. В системе должна
  быть возможность конструирования сложных объектов из имеющихся в наличии.
  Примерами таких объектов могут быть множества, списки и кортежи, которые
  позволяют пользователю определять объединения объектов в качестве атрибутов.
  
• Правило 2. Система должна поддерживать идентификацию объекта. OID должен
  быть независящим от состояния объекта. Эта возможность позволяет сравнивать
  объекты в системе на двух уровнях: сравнение OID (идентичность объектов) и
  сравнение состояния объектов (равные или почти равные объекты).
  

Если объекты имеют различные OID, но их атрибуты совпадают, то эти объекты не счи­таются идентичными, но рассматриваются как почти равные ("shallow equal"). Точно так же, как близнецы хотя и очень похожи, но все же отличаются.

• Правшго 3. Объекты должны быть инкапсулированы. Объекты имеют внешний ин­терфейс, но внутреннюю (скрытую)' реализацию данных и методов. Возможность
  инкапсуляции гарантирует, что видима только внешняя сторона объекта, в то
  время как подробности реализации скрыты.
  
• Правило 4. Система должна поддерживать типы или классы. Это правило позво­ляет проектировщику выбирать для системы поддержку классов или типов. Типы
  в основном используются на этапе компиляции для проверки ошибок в типах
  при присвоении значений атрибутам. Классы используются для хранения и ма­нипулирования схожими объектами во время выполнения. Иначе говоря, класс
  это более динамичное понятие, а тип — более статичное.
  
• Правило 5. Система должна поддерживать наследование. Объект должен наследо­вать свойства своего суперкласса в иерархии. Это свойство обеспечивает возмож­ность многократного использования кода.
  
• Правило 6. Система должна избегать раннего связывания. Эта особенность позволяет
  использовать одинаковые названия для методов в разных классах. ОО-система ре­шает, к какой из реализаций необходимо обеспечивать доступ во время выполне­ния, принимая во внимание класс, которому объект принадлежит. Это правило также известно как правило позднего или динамического связывания.
  
• Правило 7. Система должна быть законченной в вычислительном отношении. Базовые
  свойства языков программирования расширяются возможностями языка манипу­лирования данными (Data Manipulation Language, DML) базы данных, позволяя та­ким образом выразить на языке программирования любой тип операции.
  
• Правило 8. Система должна быть расширяемой. Последняя особенность, касающая­ся 00, связана с возможностью определения новых типов. Не существует различий
  в управлении типами данных, определенными пользователем и системой.
  
• Правило 9. Система должна помнить местонахождение данных. Традиционные СУБД постоянно хранят информацию на диске, т. е. СУБД обеспечивают устой­чивость данных. ОО-системы обычно держат все пространство объектов в памя­ти; как только система выключается, все пространство объектов теряется. Мно­гие исследователи ООСУБД стараются найти способ непрерывного хранения объектов во вторичной памяти (диски) и извлечения их оттуда.
  
• Правило 10. Система должна обеспечивать возможность управления большими ба­зами данных. Обычные ОО-системы ограничивают пространство объектов разме­ром доступной оперативной памяти. Например, Smalltalk не может обрабатывать объекты размером более 64 Кбайт. Поэтому важнейшая особенность ООСУБД состоит в оптимизации управления устройствами вторичного хранения инфор­мации с помощью буферов, индексов, кластеризации данных и выбора методов определения путей доступа.
  
• Правило 11. Система должна обслуживать нескольких пользователей. Традицион­ные СУБД прекрасно с этим справляются. ООСУБД должны обеспечивать такой же уровень параллельной работы, как и обычные системы.
  
• Правило 12. Система должна обеспечивать возможность восстановления после ап­паратного или программного сбоя. ООСУБД должны предлагать тот же уровень защиты от неисправностей оборудования и программного обеспечения, что и традиционные СУБД, т. е. ООСУБД должны обеспечивать поддержку автомати­ческого создания резервных копий и восстановления системы.
  
• Правило 13. Запросы к данным должны быть простыми. Эффективность запро­
  сов — одна из наиболее важных характеристик любой СУБД. Реляционные
  СУБД предоставляют стандартный способ выполнения запросов к БД с помо­
  щью SQL, а ООСУБД должны обеспечить такую же возможность с помощью
  языка OQL. Группа Object Management Group продвигает спецификацию OQL в
  качестве стандарта для доступа к данным в объектно-ориентированных базах
  данных (см. www.omg.org).
  

К необязательным свойствам ООСУБД относятся следующие.

• Поддержка множественного наследования. Множественное наследование приводит
  к усложнению системы и требует управления конфликтующими свойствами ме­
  жду классами и подклассами.
  
• Поддержка распределенных ООСУБД. Стремление к интеграции системных при­ложений является мощным аргументом в пользу распределенных БД. Если необ­ходимо обеспечить корректное взаимодействие ООСУБД с другими системами по сети, то база данных должна обеспечивать возможности распределения.
  
• Поддержка контроля версий. Контроль версий является новой характеристикой
  ООСУБД, которая особенно важна в приложениях САПР/САУ (CAD/CAM).
  Контроль версий позволяет вести историю преобразования объектов. Поэтому
  мы можем просматривать все состояния объекта, что позволит вернуть его в
  прежнее состояние и перейти в некоторое последующее.
  

11.7. Влияние объектно-ориентированного подхода на проектирование баз данных

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

Вы, наверное, обратили внимание, что представленный в книге процесс проектиро­вания базы данных, в основном, направлен на идентификацию элементов данных, а не на определение операций с данными. Фактически определение ограничений на данные и преобразование данных обычно рассматриваются на более поздних этапах проектирования БД и реализуются во внешнем программном коде. Иначе говоря. операции не являются частью модели БД.

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

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

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

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

• построение иерархии класса или сети класса (если допустимо множественное
  наследование) с помощью базовых типов данных и имеющихся классов. Решение
  этой задачи определит отношения между кассами и подклассами;
  
• определение отношений внутри класса (связи атрибут-класс) с помощью базовых
  типов данных и абстрактных типов данных (АТД).
  

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

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

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

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

Как и в любой объектно-ориентированной технологии, недостаток стандартизации затрагивает и сферу проектирования ООБД. В настоящее время не существует ни стандартная методология процесса проектирования ООБД, ни критерии (как, на­пример, правила нормализации в реляционной модели) для надлежащей оценки проекта. Однако положение дел постепенно улучшается. В 1989 году отдельные группы практиков объектно-ориентированных технологий сформировали Object Management Group (OMG, рабочая группа по развитию стандартов объектного про­граммирования) для обеспечения взаимодействия различных объектно-ориенти­рованных систем (языки, инфраструктуры, базы данных и т. д.). Группа OMG раз­рабатывает независимые стандарты и спецификации для объектно-ориентированных систем и компонентов. Группа OMG разработала язык UML (Unified Modeling Language, унифицированный язык моделирования), представляющий собой графи­ческий язык для моделирования, проектирования и визуализации объектно-ориентированных систем. Язык UML используется не только для моделирования компонентов баз данных, но и для разработки процессов, модулей, сетевых компо­нентов и описания взаимодействия между ними. Группой OMG также были созда­ны стандарты объектов, определяющие Object Management Architecture (ОМА, тех­нология управления объектом), которая допускает взаимодействие объектов на различных платформах и системах. Стандарт ОМА включает в себя Common Object Request Broker Architecture (CORBA, технология построения распределенных объ­ектных приложений) и Common Object Services Specification (COSS, спецификация на общие средства объектного сервиса). Эта структура используется поставщиками ООСУБД и разработчиками для реализации систем, которые должны взаимодейст­вовать с другими ООСУБД, а также СУРБД и более старыми СУБД.

Некоторые поставщики уже предлагают продукты, соответствующие спецификаци­ям OMG CORBA и COSS, например, System Object Model (SOM) компании IBM и Object Request Broker (ORB) компании Hewlett-Packard. Другие объектные архитек­туры также появляются как альтернатива разработкам стандартов, в частности это относится к технологиям OLE (object linking and embedding, технология связывания и внедрения объектов) и Component Object Model (COM, модель компонентных объектов) корпорации Microsoft. Хотя спецификации OLE/COM не являются обще­принятым стандартом, широкое распространение на рынке сделало ее стандартом де-факто в среде Microsoft Windows.


11.8.00СУБД: преимущества и недостатки

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

Проблема рынка ООСУБД состоит еще и в том, что многие возможности 00-подхода встраиваются в СУРБД при сохранении концептуальной простоты этих мо­делей, тем самым снижая привлекательность самих ООСУБД. Тем не менее, пока в РСУБД не включены рекомендованные К. Дейтом реализации доменов, ООСУБД обладает достаточными преимуществами, на которые стоит обратить внимание⁴ Большую часть этих достоинств в смысле возможностей управления сложными объ­ектами мы рассмотрели достаточно подробно. Полнота использования всех досто­инств ООСУБД зависит от объектно-ориентированного языка программирования. Именно поэтому, указывая на некоторые преимущества ООСУБД, мы ссылаемся на определенные языки программирования.

Преимущества

• ООСУБД допускает включение подробной семантической информации в базу
  данных, что обеспечивает более естественное и реалистичное представление объ­ектов реального мира.
  
• ООСУБД хорошо приспособлена для работы со сложными объектами, что делает
  ее особенно удобной в специализированных приложениях. Традиционные базы
  данных просто не могут эффективно работать в области CAD/САМ, медицине
  (обработка изображений), с пространственными изображениями и специализи­рованными мультимедийными приложениями.
  
• ООСУБД позволяет расширять базовые типы данных, что позволяет увеличить I
  как функциональные возможности БД, так и возможности моделирования.
  
• Если платформа допускает эффективное кэширование, то ООСУБД обеспечивает
  исключительную производительность по сравнению с реляционными БД при ра­боте со сложными объектами.
  
• Контроль версий представляет собой очень важную особенность в специализиро­ванных приложениях CAD/САМ, при обработке изображений в медицине, при работе с пространственными изображениями, обработке текстов и в настольных типографских системах.
  

⁴ См. С. J. Date "Back to the Relational Future", www.dbpd.com/vault/9808date.html.

• Возможность многократного использования классов позволяет ускорить и упро­стить разработку баз данных и их приложений.
  
• Ускоренная разработка приложений за счет наследования и возможности много­
  кратного использования. Это преимущество достигается только после проработ­ки таких особенностей 00, как:
  

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

Недостатки

• ООСУБД сталкиваются с сильным и эффективным сопротивлением со сторо­ны устоявшихся СУРБД, особенно в связи с тем, что СУРБД (например, DB2
  Universal Database и Oracle 8.0) включили в себя многие 00-возможности, не дав
  таким образом ООСУБД шанс выйти вперед в конкурентной борьбе за рынок
  обработки сложных данных.
  
• ООСУБД основаны на объектной модели, которой не хватает солидной теорети­
  ческой базы, имеющейся у реляционной модели, используемой в СУРБД.
  
• В некотором смысле ООСУБД рассматриваются как возврат к устаревшим сис­
  темам указателей, которые использовались в иерархических и сетевых моделях.
  Эта критика не связана с тем, что в старых СУБД система указателей связыва­лась с навигационным стилем манипулирования данных и фиксированными пу­тями доступа, и в сравнении с этим реляционные системы выглядели более при­влекательными. Тем не менее, сложность системы указателей ООСУБД нельзя
  отрицать.
  
• ООСУБД не имеет стандартного языка нерегламентированных запросов, как ре­ляционные системы. В настоящее время разработка языка OQL еще далека от за­вершения. В некоторых реализациях ООСУБД имеются расширения реляцион­ного SQL, обеспечивающие возможность интеграции ООСУБД и СУРБД.
  
• Реляционные СУБД предоставляют комплексное решение баз данных для бизне­са и управления, поддерживающих обе модели данных и набор четких правил
  нормализации для проектирования и оценки реляционных БД. ООСУБД пока
  еще не обладают такими возможностями.
  
• Стоимость изучения ООСУБД достаточно высока. Если вы рассмотрите прямые
  затраты на обучение и время, необходимые для овладения преимуществами объ­ектно-ориентированного подхода, вы поймете, почему ООСУБД редко рассмат­ривают в качестве лучшего варианта при поиске решений для несложных бизнес-
  задач.
  
• Недостаточное предложение ООСУБД на рынке вкупе с высокой стоимостью ее
  изучения приводит к недостаточному числу специалистов по использованию
  мощных ОО-технологий. Большинство технологий в настоящее время нацелены