Geum.ru

Организация баз данных

Методическое пособие - Педагогика

Другие методички по предмету Педагогика

?н клиент может осуществить доступ к нескольким серверам. Эта ситуация может быть реализована двумя путями.

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

    • Второй способ, по сути, является формулировкой истинной распределенной системы, смысл которой не соответствует широко распространенному смыслу термина "клиент/сервер".

     

    Литература:

     

    1. Дейт К.Дж. Введение в системы баз данных. Пер. с англ. 6-е изд. К. Диалектика, 1998. Стр. 564590.
    2. Современные постреляционные модели БД

     

    17.1Системы управления базами данных следующего поколения

    17.2Ориентация на расширенную реляционную модель

    17.3Объектно-ориентированные СУБД

     

    1. Системы управления базами данных следующего поколения

     

    В этом разделе очень кратко рассматриваются основные направления исследований и разработок в области так называемых постреляционных систем, т.е. систем, относящихся к следующему поколению (хотя термин "next-generation DBMS" зарезервирован для некоторого подкласса современных систем).

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

    1. Направление Postgres. Основная характеристика: максимальное следование (насколько это возможно с учетом новых требований) известным принципам организации СУБД (если не считать коренной переделки системы управления внешней памятью).
    2. Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея распространяется вплоть до самых базисовых слоев системы.
    3. Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.

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

     

    1. Ориентация на расширенную реляционную модель

     

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

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

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

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

     

    1. Абстрактные типы данных

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