0% нашли этот документ полезным (0 голосов)
9 просмотров5 страниц

SB 4

Загружено:

Shah Fighter
Авторское право
© All Rights Reserved
Мы серьезно относимся к защите прав на контент. Если вы подозреваете, что это ваш контент, заявите об этом здесь.
Доступные форматы
Скачать в формате DOCX, PDF, TXT или читать онлайн в Scribd
0% нашли этот документ полезным (0 голосов)
9 просмотров5 страниц

SB 4

Загружено:

Shah Fighter
Авторское право
© All Rights Reserved
Мы серьезно относимся к защите прав на контент. Если вы подозреваете, что это ваш контент, заявите об этом здесь.
Доступные форматы
Скачать в формате DOCX, PDF, TXT или читать онлайн в Scribd

МИНИСТЕРСТВО ОБРАЗОВАНИЯ АЗЕРБАЙДЖАНСКОЙ

РЕСПУБЛИКИ
АЗЕРБАЙДЖАНСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра: Информационные технологии и


программирование
Предмет: Основы баз данных

Самостоятельная работа 4
на тему

Современные направления развития баз данных

Педагог: Мustafayev Rauf


Курс: 2
Группа: 689r
Студент: Mustafa Afzali
Интегрированные или федеративные системы и мультибазы
данных

Направление интегрированных или федеративных систем


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

Основной задачей интеграции неоднородных БД является


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

При строгой интеграции неоднородных БД локальные


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

Как правило, для внешнего представления


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

Конечно, несмотря на всю их привлекательность,


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

Одним из основных положений реляционной модели


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

Однако с появлением эффективных реляционных СУБД их


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

Направление Postgres. Основная характеристика:


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

Направление Exodus/Genesis. Основная характеристика:


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

Вам также может понравиться