Понятие реляционный (англ. relation — отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

Базовыми понятиями реляционных СУБД являются: 1) атрибут 2) отношения 3) кортеж

PS
С тебя плюсег

Гомогенные и гетерогенные распределенные СУБД

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

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

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

• иной тип используемого оборудования;
• иной тип используемой СУБД;
• иной тип применяемых оборудования и СУБД.

Если используется иной тип оборудования, однако на сайте установлен тот же самый тип СУБД, методы выполнения трансляции достаточно очевидны и включают замену кодов и изменение длины слова. Если типы используемых на сайтах СУБД различны, процедура трансляции усложняется тем, что необходимо отображать структуры данных одной модели в соответствующие структуры данных другой модели. Кроме того, потребуется транслировать текст запросов с одного используемого языка на другой (например, запросы с SQL-оператором SELECT потребуется преобразовать в запросы с операторами FIND и GET языка манипулирования данными сетевой СУБД). Если отличаются и тип используемого оборудования, и тип программного обеспечения, потребуется выполнять оба вида трансляции. Все это усложняет обработку данных в гетерогенных СУБД.

Дополнительные сложности возникают при попытках выработки единой концептуальной схемы, создаваемой путем интеграции независимых локальных концептуальных схем. При наличии семантической неоднородности, интеграция локальных моделей данных превращается в чрезвычайно трудную задачу. Например, атрибуты, имеющие в различных схемах одно и то же имя, на деле могут представлять совершенно отличные понятия. Аналогично, атрибуты с разными именами фактически могут представлять одну и ту же характеристику. Для более детального рассмотрения можно обратиться к работам Гарсиа-Солако и др. «Semantic heterogeneity in multidatabase systems» In Bukhres and Elmagarmid (1996), 129-195.

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

Мультибазовые системы

Это одна из разновидностей распределенных СУБД.

Мультибазовая система - распределенная система управления базами данных, в которой управ-ление каждым из сайтов осуществляется совершенно автономно.

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

Мультибазовые системы позволяют конечным пользователям разных сайтов получать доступ и совместно использовать данные без необходимости физической интеграции существующих баз данных. Они обеспечивают пользователям возможность управлять базами данных их собственных сайтов без какого-либо централизованного контроля, который обязательно присутствует в обычных типах СУРБД. Администратор локальной базы данных может разрешить доступ к определенной части своей базы данных посредством создания схемы экспорта, определяющей, к каким элементам локальной базы данных смогут получать доступ внешние пользователи. Существуют нефедеральные (не имеющие локальных пользователей) и федеральные мультибазовые системы. Федеральная система представляет собой некоторый гибрид распределенной и централизованной систем, поскольку она выглядят как распределенная система для удаленных пользователей и как централизованная система — для локальных. Информацию о классификации распределенных систем можно найти, например, в работах Букреса и Элмагармида (Bukhres and Elmagarmid, 1996).

Т.о., мультибазовая СУБД является такой СУБД, которая прозрачным образом располагается поверх существующих баз данных и файловых систем, предоставляя их своим пользователям как некоторую единую базу данных. Мультибазовая СУБД поддерживает глобальную схему, на основании которой пользователи могут строить запросы и модифицировать данные. Мультибазовая СУБД работает только с глобальной схемой, тогда как локальные СУБД собственными силами обеспечивают поддержку данных всех их пользователей. Глобальная схема создается посредством интеграции схем локальных баз данных. Программное обеспечение мультибазовой СУБД предварительно транслирует глобальные запросы и превращает их в запросы и операторы модификации данных соответствующих локальных СУБД. Затем полученные после выполнения локальных запросов результаты сливаются в единый глобальный результат, предоставляемый пользователю. Кроме того, мультибазовая СУБД осуществляет контроль за выполнением фиксации или отката отдельных операций глобальных транзакций локальных СУБД, а также обеспечивает сохранение целостности данных в каждой из локальных баз данных. Программы муль-тибазовой СУБД управляют различными шлюзами, с помощью которых они контролируют работу локальных СУБД. Например, мультибазовая система UniSQL/M фирмы UniSQL Inc. позволяет разрабатывать приложения с помощью единого глобального представления и единственного языка доступа к базе данных для работы со многими гетерогенными реляционными и объектно-ориентированными СУБД (Connolly et al., “Distributed database management systems: have they arrived?” Tech.rep. Computing and information systems, University of Paisley, Paisley, Scotland, 1994).

Функции и архитектура распределенных СУБД

Функции распределенных СУБД

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

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

Рекомендуемая архитектура распределенных СУБД

Один из примеров рекомендуемой архитектуры СУРБД представлен на рис. Он включает следующие элементы:

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

Глобальная концептуальная схема

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

Схемы фрагментации и распределения

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

Локальные схемы

Каждая локальная СУБД имеет свой собственный набор схем. Локальная концептуальная и локальная внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры ANSI-SPARC. Локальная схема отображения используется для отображения фрагментов в схеме распределения во внутренние объекты локальной базы данных. Эти элементы являются зависимыми от типа используемой СУБД и служат основой для построения гетерогенных СУРБД.

Рекомендуемая архитектура мультибазовых СУБД

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

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

Компонентная архитектура распределенных СУБД

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

локальную СУБД;
компонент передачи данных;
глобальный системный каталог;
распределенную СУБД (СУРБД).
Общий вид компонентной архитектуры распределенной СУБД представлен на рис.(см. ниже слева).

Локальная СУБД

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

Компонент передачи данных

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

Глобальный системный каталог имеет то же самое функциональное назначение, что и системный каталог в централизованных базах данных. Глобальный каталог содержит информацию, специфическую для распределенной природы системы, например схемы фрагментации и распределения. Этот каталог сам по себе может являться распределенной базой данных и поэтому подвергаться фрагментации и распределению, быть полностью реплицируемым или централизованным, как и любое другое отношение, о чем речь пойдет ниже. Полностью реплицируемый глобальный системный каталог снижает автономность отдельных сайтов, поскольку любые изменения в нем должны передаваться на все существующие сайты. Использование централизованного глобального каталога также снижает автономность сайтов и повышает их зависимость от отказов на центральном сайте. Подход, выбранный в системе R*, позволяет преодолеть все указанные недостатки. В системе R* на каждом сайте существует локальный каталог, содержащий метаданные, описывающие данные, сохраняемые на этом сайте. Что касается отношений, созданных на некотором сайте (сайте создания), то ответственность за фиксацию описания каждого его фрагмента, каждой реплики каждого фрагмента, а также хранение сведений о расположении этих фрагментов возлагается на локальный каталог данного сайта. В случае если фрагмент или реплика перемещается в другое место, сведения в локальном каталоге сайта создания соответствующего отношения необходимым образом обновляются. Следовательно, для определения расположения фрагмента или реплики отношения необходимо получить доступ к каталогу его сайта создания. Сведения о сайте создание каждого глобального отношения должны фиксироваться в каждом локальном экземпляре глобального системного каталога.

Распределенная СУБД

Компонент распределенной СУБД является управляющим по отношению ко всей системе элементом. Мы кратко познакомились с основными функциональными возможностями, которыми должен обладать этот компонент.

Разработка распределенных реляционных баз данных

Здесь обсудим следующие аспекты проектирования распределенных систем.

Фрагментация. Любое отношение может быть разделено на некоторое количество частей, называемых фрагментами, которые затем распределяются по различным сайтам. Существуют два основных типа фрагментов: горизонтальные и вертикальные. Горизонтальные фрагменты представляют собой подмножества кортежей, а вертикальные — подмножества атрибутов.

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

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

Определение и размещение фрагментов должно проводиться с учетом особенностей использования базы данных. В частности, это подразумевает выполнение анализа приложений. Как правило, провести анализ всех приложений не представляется возможным, поэтому следует сосредоточить усилия на самых важных из них. Эмпирически отмечено, что 20% выполняемых пользователями запросов создают 80% общей нагрузки на базу данных. Это же правило "80/20" вполне может использоваться при проведении анализа приложений. Проектирование должно выполняться на основе как количественных, так и качественных показателей. Количественная информация используется в качестве основы для распределения, тогда как качественная служит базой при создании схемы фрагментации.

Количественная информация включает такие показатели:
частота запуска приложения на выполнение;
сайт, на котором запускается приложение;
требования к производительности транзакций и приложений.

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

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

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

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

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

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

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

Распределение данных

Существуют четыре альтернативные стратегии размещения данных в системе:

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

Централизованное размещение

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

Раздельное (фрагментированное) размещение

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

Размещение с полной репликацией

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

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

Размещение с выборочной репликацией

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

зы
если это то что надо с тебя два плюса=)))

Добавлено (17.11.2008, 21:21)
---------------------------------------------
Лан завтро поищу еще инфу а щас спаааать

Преимущества и недостатки объектно-ориентированных баз данных.

Тяпкин Сергей Владимирович,

соискатель МАТИ - Российского Государственного Технологического Университета им. К.Э.Циолковского.

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

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

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

Каждый объект класса имеет идентификатор объекта, который используется для однозначного определения данного объекта в системе. Идентификатор назначается системой и не зависит от состояния объекта.

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

Основное преимущество СУООБД в том, что доступ к объектам базы данных организован достаточно прозрачно и взаимодействие с объектом базы данных не отличается от взаимодействия с объектом в памяти. В этом состоит основное преимущество перед СУРБД – нет необходимости использовать язык запросов или CLI интерфейсы, такие как ODBC или ADO.

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

Ниже приведен список преимуществ и недостатков при использовании связки СУООБД или СУРБД с объектно-ориентированным программированием.
Преимущества:

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

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

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

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

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

2. СУООБД обычно привязана к отдельному языку с помощью отдельного АПИ и данные доступны только через этот АПИ. СУРБД в этом плане имеет большие возможности, благодаря общему языку запросов.

3. В СУРБД, реляционная природа данных позволяет конструировать ad-hoc запросы, где можно объединять различные таблицы. В СУООБД невозможно дублировать семантику соединения двух таблиц соединением двух классов, поэтому в данном случае СУООБД уступает СУРБД в гибкости. Запросы, которые могут исполняться над данными в СУООБД, в большей мере зависят от дизайна системы.

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

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

Литература.

1. Mohammad A. Ketabchi, Valdis Berzins. Mathematical Model of Composite Objects and Its Application for Organizing Engineering Databases // IEEE Trans. on Software Eng.- 14, N 1.- 1988.- 71-84

2. Anant Jhingran, Michael Stonebraker. Alternatives in Complex Object Representation: A Performance Persrective // 6th Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 94-102

3. E. F. Codd. A Relational Model of Data for Large Shared Data Banks // Commun. ACM.- 26, N 1.- 1970.- 377-387

4. Francois Bancilhon. Query Languages for Object-Oriented Database Systems: Analysis and Proposal // Datanbanksyst. Buro, Tech. and Wiss.: GI/SI - Fashtag., Zurich, Marz. 1-3, 1989.- 1-18

5. Serge Abiteboul, Richard Hull. IFO: A Formal Semantic Database Model // ACM Trans. Database Syst.- 12, N 4.- 1987.- 525-565

6. D. Maier. Why isn't there an Object-Oriented Data Model? // Technical Report, Oregon Graduate Center, May 1989.

Не регистрирую домены, не переделываю dle под ucoz.

Тут можно много зарабатывать

5.2.1 История развития СУБД
5.2.4 Системные каталоги
5.2.5 Функции СУБД
5.2.6 Преимущества и недостатки СУБД
5.2.6 Выводы.

Вот еще чего есть. Думаю чегонибудь напишешь. Кстати нам это все читали, могу дать тетрадку.

Кстати это сайт БТИ.