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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


курсовая работа Распределенные СУБД

Информация:

Тип работы: курсовая работа. Добавлен: 25.05.2012. Сдан: 2011. Страниц: 13. Уникальность по antiplagiat.ru: < 30%

Описание (план):


     Содержание

ВВЕДЕНИЕ……………………………………………………………………... 3
1. РАСПРЕДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ………………… …
6
1.1. Основные понятия ………………………………………………………… 6
      Модель клиент – сервер в технологии распределенных баз данных
10
      Типы распределенных СУБД …………………………………………
12
1.4.    Размещение данных в распределенных  базах данных………………… 14
      Требования к распределенной обработке данных …………………….
15
2. РЕАЛИЗАЦИЯ РАСПРЕДЕЛЕННОЙ СУБД………………………
18
2.1. Теоретические основы СУБД сервера Informix ………………………… 18
2.2. СУБД Ingres ………………………………………………………………. 22
2.3. Архитектура Sybase System 11……………………………………………. 26
2.4. СУБД Oracle ……………………………………………………………….. 29
ЗАКЛЮЧЕНИЕ ………………………………………….…………………… 32
ГЛОССАРИЙ……………………………………………………………………. 35
СПИСОК  ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ………………………… 37
ПРИЛОЖЕНИЯ 38

     Введение

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

     Перенесение частей этой локальной БД в различные узлы сети может выполняться в более позднее время администратором БД и оно не влечет за собой изменения приложений. Более того, пользователи и разработчики приложений могут даже не знать о том, где теперь физически размещены данные, с которыми они работают. Поиск и пересылку удаленных данных автоматически выполняют программные средства СУБД.
     Конечно для того, чтобы реализовать такой  простой для конечного пользователя и разработчика механизм представления  распределенной БД, необходимо решить множество проблем. Наиболее очевидные из них связаны с обеспечением целостности и непротиворечивости данных распределенной БД, реализацией механизма поддержки "прозрачности" распределенной БД, реализацией единого механизма работы с частями БД, находящимися в СУБД различного типа и расположенными на разнотипных компьютерах с различными операционными системами, обеспечением приемлемого быстродействия прикладной системы и т.д.
     Сегодня многие фирмы - разработчики СУБД заявляют о том, что они поддерживают работу с распределенными БД, однако при ближайшем рассмотрении в большинстве случаев эти заявления оказываются несколько преувеличенными. Специалисты в области СУБД считают, что только несколько пакетов СУБД позволяют в некоторой степени реализовать распределенную базу данных.
     Дадим следующее определение распределенной БД: "Распределенная БД - это множество физических баз данных, которые выглядят для пользователя как одна логическая БД". К сожалению на сегодняшний день ни одна СУБД полностью не реализует это определение. Наиболее близко к его реализации подошли следующие СУБД:
     - Informix On-Line фирмы Informix Software;
     - Ingres Intelligent Database фирмы Ingres Corp;
     - Oracle фирмы Oracle Corp;
     - Sybase System 11 фирмы Sybase Inc.
     Хотя  ни одна из этих 4 СУБД полностью не реализует все функции распределенной СУБД, однако каждая из них реализует или в скором времени будет реализовывать поддержку работы с распределенной БД.
     В большинстве случаев распределенная СУБД состоит из ядра СУБД и набора дополнительных продуктов, покупаемых отдельно, которые обеспечивают работу с распределенной БД. Некоторые фирмы разработчики СУБД встраивают средства работы с распределенной БД в ядро СУБД. Кроме того, различные фирмы вкладывают разные понятия в термин "распределенная СУБД" и по разному определяют набор необходимых для такой СУБД функций.
     Цель  курсовой работы – дать анализ распределенным СУБД. Для этого были поставлены следующие задачи:
      Рассмотреть основные понятия распределенной обработки баз данных;
      Рассмотреть модель клиент – сервер в технологии распределенных баз данных;
      Дать анализ распределенным СУБД.

     Основная  часть

     1РАСПРЕДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ

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

Рисунок 1. Режимы работы с базами данных
     Рассмотрим  основные понятия, применяемые в  системах управления распределенными базами данных.
     Пользователь  БД— программа или человек, обращающийся к базе данных.
     Запрос  — процесс обращения пользователя к БД с целью ввода, получения или изменения информации в БД.
     Транзакция  — последовательность операций модификации данных в БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние.
     Логическая  структура БД — определение БД на физически независимом уровне; ближе всего соответствует концептуальной модели БД.
     Топология БД, или структура распределенной БД, — схема распределения физической организации базы данных в сети.
     Локальная автономность означает, что информация локальной БД и связанные с ней определения данных принадлежат локальному владельцу и им управляются.
     Удаленный запрос — запрос, который выполняется с использованием модемной связи.
     Возможность реализации удаленной транзакции — обработка одной транзакции, состоящей из множества SQL-запросов, на одном удаленном узле.
     Поддержка распределенной транзакции допускает обработку транзакции, состоящей из нескольких запросов SQL, которые выполняются на нескольких узлах сети (удаленных или локальных), но каждый запрос в этом случае обрабатывается только на одном узле.
     Распределенный  запрос — запрос, при обработке которого используются данные из БД, расположенные в разных узлах сети.
     Основной  причиной разработки систем, использующих базы данных, является стремление интегрировать все обрабатываемые в организации данные в единое целое и обеспечить к ним контролируемый доступ. Хотя интеграция и предоставление контролируемого доступа могут способствовать централизации, последняя не является самоцелью. На практике создание компьютерных сетей приводит к децентрализации обработки данных. Децентрализованный подход, по сути, отражает организационную структуру компании, логически состоящую из отдельных подразделений, отделов, проектных групп и тому подобного, которые физически распределены по разным офисам, отделениям, предприятиям или филиалам, причем каждая отдельная единица имеет дело с собственным набором обрабатываемых данных. Разработка распределенных баз данных, отражающих организационные структуры предприятий, позволяет сделать данные, поддерживаемые каждым из существующих подразделений, общедоступными, обеспечив при этом их сохранения именно в тех местах, где они чаще всего используются. Подобный подход расширяет возможности совместного использования информации, одновременно повышая эффективность доступа к ней [2].
     Распределенные  системы призваны разрешить проблему островов информации. Базы данных иногда рассматривают как некие электронные острова, представляющие собой отдельные и, в общем случае, труднодоступные места, подобные удаленным друг от друга островам. Данное положение может являться следствием географической разобщенности, несовместимости используемой компьютерной архитектуры, несовместимости используемых коммутационные протоколов и т.д. Интеграция отдельных баз данных в одно логическое целое способна изменить подобное положение дел.
     Распределенная  база данных - это набор логически связанных между собой разделяемых данных (и их описаний), которые физически распределены в некоторой компьютерной сети. Тогда распределенная СУБД - это программный комплекс, предназначенный для управления распределенными базами данных и позволяющий сделать распределенность информации прозрачной для конечного пользователя.
     Система управления распределенными базами данных (СУРБД) состоит из единой логической базы данных, разделенной на некоторое количество фрагментов. Каждый фрагмент базы данных сохраняется на одном или нескольких компьютерах, которые соединены между собой линиями связи и каждый из которых работает под управлением отдельной СУБД. Любой из сайтов способен независимо обрабатывать запросы пользователей, требующие доступа к локально сохраняемым данным (что создает определенную степень локальной автономии), а также способен обрабатывать данные, сохраняемые на других компьютерах сети.
     Пользователи  взаимодействуют с распределенной базой данных через приложения. Приложения могут быть классифицированы следующим образом: приложения, которые не требуют доступа к данным на других сайтах (локальные приложения), и приложения, которые требуют подобного доступа (глобальные приложения). В распределенной СУБД должно существовать хотя бы одно глобальное приложение, поэтому любая СУРБД должна отвечать следующим требованиям;
    иметь набор логически связанных разделяемых данных;
    сохраняемые данные разбиты на некоторое количество 
    фрагментов;

    между фрагментами может быть организована репликация 
    данных;

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

    СУБД каждого сайта поддерживает хотя бы одно глобальное 
    приложение.

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

1.2. Модель  клиент – сервер в технологии распределенных баз данных
     Вычислительная  модель клиент—сервер связана с  появлением в 1990-х гг. открытых систем. Термин «клиент—сервер» применялся к архитектуре программного обеспечения, которое состояло из двух процессов обработки информации: клиентской и серверной. Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиентских процессов. Учитывая что аппаратная реализация этой модели управления базами данных связана с созданием локальных вычислительных сетей предприятия, такую организацию процесса обработки информации называют архитектурой клиент—сервер. Основной принцип технологии клиент—сервер применительно к технологии управления базами данных заключается в разделении функций стандартного интерактивного приложения на пять групп, имеющих различную природу:
    функции ввода и отображения данных (Presentation Logic);
    прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
    функции обработки данных внутри приложения (Database Logic);
    функции управления информационными ресурсами (Database Manager System);
    служебные функции, играющие роль связок между функция 
    ми первых четырех групп.

     Структура типового приложения, работающего с  базой данных в архитектуре клиент—сервер, приведена рис. 2.
     

     Рисунок 2. Структура типового приложения, работающего с базами данных
     Презентационная логика (Presentation Logic) как часть приложения определяется тем, что пользователь видит на своем экране, когда работает приложение. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы приложения. К этой же части относится все то, что выводится пользователю на экран как результаты решения некоторых промежуточных задач либо как справочная информация. Поэтому основными задачами презентационной логики являются:
    формирование экранных изображений;
    чтение и запись в информации экранные формы;
     управление  экраном;
     • обработка движений мыши и нажатие  клавиш клавиатуры.
     Бизнес-логика, или логика собственно приложений (Business processing Logic), — это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, C++, Visual-Basic и др.
     Логика  обработки данных (Data manipulation Logic) — это часть кода приложения, которая непосредственно связана с об работкой данных внутри приложения. Данными управляет собственно СУБД. Для обеспечения доступа к данным используется язык SQL.
     Процессор управления данными (Database Manager System Processing) — это собственно СУБД. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения их надо выделить в отдельную часть приложения [3].
     В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.
     В децентрализованной архитектуре эти  задачи могут быть по-разному распределены между серверным и клиентским процессами. В зависимости от характера распределения можно выделить следующие модели распределений (таблица 1 см. приложение А):
    распределенная презентация (DP — Distribution Presentation);
    удаленная презентация (RP — Remote Presentation);
    распределенная бизнес-логика (RBL — Remote business logic);
    распределенное управление данными (DDM — Distributed data management);
    удаленное управление данными (RDM — Remote data management).
     Эта условная классификации показывает, как могут быть распределены отдельные задачи между серверным и клиентскими процессами. В этой классификации отсутствует реализация удаленной бизнес-логики. Считается, что она не может быть удалена сама по себе полностью, а может быть лишь распределена между разными процессами, которые могут взаимодействовать друг с другом. 

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

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

1.4. Размещение  данных в распределенных базах  данных
     Размещение данных в распределенных БД характеризуется следующими понятиями:
     • фрагментация. Любая запись (отношение  в случае реляционных моделей  данных) может быть разделено на некоторое количество частей, называемых фрагментами, которые затем могут  распределяться по различным узлам. Как отмечалось ранее, существуют два основных типа фрагментации: горизонтальная и вертикальная. В первом случае фрагменты представляют собой подмножества строк, а во втором — подмножества столбцов (атрибутов);
     • размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы доступа;
     • репликация. Распределенная СУБД может  поддерживать актуальную копию некоторого фрагмента на нескольких различных  узлах.
     Определение и размещение фрагментов должно проводиться  с учетом особенностей использования базы данных (в частности, на основе анализа транзакций).
     Существуют  четыре стратегии размещения данных в системе:
    Централизованное размещение. Данная стратегия предусматривает создание на одном из узлов единственной базы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети.
    Фрагментированное размещение. В этом случае база данных разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из узлов системы.
    Размещение с полной репликацией. Эта стратегия предусматривает размещение полной копии всей базы данных на каждом из узлов системы. Стоимость устройств хранения данных и уровень затрат на передачу информации об обновлениях в этом случае также будут самыми высокими. Для преодоления части этих проблем в некоторых случаях используется технология снимков. Снимок представляет собой копию базы данных в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени, например 1 раз в час или в сутки.
    Размещение с избирательной репликацией. Данная стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для них высокой локализации ссылок, тогда как другие, используемые на многих узлах, но не подверженные частым обновлениям, подвергаются репликации. Все остальные данные хранятся централизованно.
 
1.5. Требования  к распределенной обработке данных
     Прозрачность  сети. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно более широкий диапазон сетевых протоколов (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, AppleTalk и др.) [5].
     Автоматическое  преобразование форматов данных. Как только несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу возникает вопрос о согласовании форматов представления данных. Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (I6-, 32- и 64-разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т. д. Задача коммуникационного сервера состоит в том, чтобы на уровне обмена данными обеспечить согласование форматов между удаленным и локальным узлами с тем, чтобы данные, извлеченные сервером из базы на удаленном узле и переданные по сети, были правильно истолкованы прикладной программой на локальном узле.
     Автоматическая  трансляция кодов. В неоднородной компьютерной среде при взаимодействии клиента и сервера возникает также задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент — с другой (например, ASCII), при этом происходит рассогласование трактовки кодов символов. Поэтому, если на локальном узле используется одна кодовая таблица,/а на удаленном — другая, то при передаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер.
     Однако  ни одна из существующих СУБД не достигает  этого идеала вследствие следующих  практических проблем:
    низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях сильно снижает общую производительность обработки;
    обеспечение целостности данных в распределенных транзакциях базируется на принципе «все или ничего» и требует специального протокола двухфазного завершения транзакций, что приводит к длительной блокировке изменяемых данных;
    необходимо обеспечить совместимость данных стандартного типа, для хранения которых в разных системах используются разные физические форматы и кодировки;
    и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.