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

МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА

РОССИЙСКОЙ ФЕДЕРАЦИИ

 

ФГОУ ВПО «ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ

УНИВЕРСИТЕТ ИМЕНИ ИМПЕРАТОРА ПЕТРА I»

 

 

 

 

ЦЕНТР   ДОТ

 

 

 

 

 

КОНТРОЛЬНАЯ РАБОТА

 

по дисциплине «БАЗЫ ДАННЫХ»

 

 

 

 

 

 

 

 

Выполнил:

студент заочного отделения

Наливайко Н.С.

набор июнь 2012

шифр ДИ/12016

Проверил:

 

 

 

 

 

 

 

 

 

 

Россошь 2013 
СОДЕРЖАНИЕ

Тема: «Распределенная обработка данных»

Вариант 6

 

I. Теоретическая часть ……..……………………………………………………..3

  1.1 Архитектура распределенной обработки данных ..……..…………………3

  1.2 Базовые архитектуры распределенной обработки………..……...….……..4

  1.3 Распределенные БД………………………………..…………………………8

  1.4 Преимущества и недостатки СУРБД …………..…………………..….…..10

  1.5 12 правил Дейта для СУРБД ……………………………………….…..…..12

II. Разработка информационно-логической модели предметной области .......14

  2.1 Описание предметной области …..…………………………….…..………14

  2.2 Информационно-логическая модель ………………………………..….....15

Список использованной литературы ……………………………….…………..17

 

I. Теоретическая часть

1.1 Архитектура распределенной обработки данных

 

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

Почти все модели организации взаимодействия пользователя с БД построены на основе модели «клиент – сервер». Но различные приложения отличаются способом распределения функций между клиентской и серверной частями.

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

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

Разделение процесса выполнения запроса на клиентскую и серверную компоненту позволяет:

  1. различным прикладным (клиентским) программам одновременно использовать общую БД;
  2. централизовать функции управления: защиту информации, обеспечение целостности данных, управление совместным использованием ресурсов;
  3. обеспечивать параллельную обработку запроса в случае распределенных БД;
  4. высвобождать ресурсы рабочих станций и сети;
  5. повышать эффективность управления данными за счет использования ЭВМ, специально разработанных для работы СУБД.

 

1.2 Базовые архитектуры распределенной обработки

 

Архитектура «файл – сервер»

Рис. 1.

 

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

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

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

Достоинство: возможность обслуживания запросов нескольких клиентов.

Недостатки:

  1. высокая загрузка сети и машин – клиентов;
  2. низкий уровень защиты данных;
  3. низкий уровень управления целостностью и непротиворечивостью информации.
Архитектура «выделенный сервер БД»

Рис. 2.

 

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

Достоинства:

  1. возможность обслуживания запросов нескольких клиентов;
  2. снижение нагрузки на сеть и машины сервера и клиентов;
  3. защита данных осуществляется средствами СУБД;
  4. сервер реализует управление транзакциями и может блокировать попытки одновременного изменения одних и тех же записей.

Недостатки:

  1. бизнес - логика функциональной обработки (правила, по которым проводится ввод, вывод и изменение данных в БД) и представление данных могут быть одинаковыми для нескольких клиентских приложений, что увеличит совокупные потребности в ресурсах при исполнении вследствие повторения части кода программ и запросов;
  2. низкий уровень управления непротиворечивостью информации, так как правила функциональной обработки сосредоточены на клиентской части.

Архитектуры «файл – сервер» и «выделенный сервер БД» называют моделями с «толстым клиентом», так как на стороне клиента выполняется большинство функций. Следующие две архитектуры «активный сервер БД» и «сервер приложений» называют моделями с «тонким клиентом».

 

Архитектура «активный сервер БД»

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

Рис. 3.

 

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

Достоинства:

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

Все рассмотренные выше архитектуры являются двухзвенными: все функции доступа и обработки распределены между программой клиента и сервером БД.

Архитектура «сервер приложений»

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

Рис. 4.

 

Достоинства:

  1. Централизованное ведение бизнес – логики. Отсутствие необходимости тиражирования изменений в клиентских приложениях.
  2. Отсутствие необходимости устанавливать на клиентских машинах компоненту программного обеспечения управления доступом к данным.
  3. Возможность отложенного обновления БД в случае изменения данных, запрошенных с сервера, в автономном режиме.

 

 

1.3 Распределенные БД

 

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

Системы распределенных БД представляют собой системы с БД, размещенными в сети разнотипных компьютеров. Распределенная БД – набор логически связанных между собой разделяемых данных (и их описаний), которые физически распределены в некоторой компьютерной сети. Такие системы обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются ресурсы БД, размещенные на различных ЭВМ сети.

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

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

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

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

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

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

 

 

1.4 Преимущества и недостатки СУРБД

 

Преимущества СУРБД:

  1. Отражение структуры предметной области. Например, крупные организации, как правило, имеют множество отделений, которые могут находиться в разных концах страны и даже за ее пределами. Вполне логично будет предположить, что используемая этой организацией БД должна быть распределена между ее отделениями. В каждом отделении поддерживается БД, содержащая сведения о его персонале, клиентах и т. д. Через сеть осуществляется доступ не только к своим данным, но и данным, хранящимся в других отделениях.
  2. Разделяемость и локальная автономность. Пользователи одного узла распределенной БД могут получать доступ к данным, сохраняемым на других узлах. Данные могут быть помещены на тот узел, на котором зарегистрированы пользователи, которые их чаще всего используют. В результате заинтересованные пользователи получают локальный контроль над требуемыми им данными и могут устанавливать или регулировать локальные ограничения на их использование.
  3. Повышение доступности данных. В централизованных СУБД отказ центрального компьютера вызывает прекращение функционирования всей СУБД. Однако отказ одного из узлов СУРБД или линии связи между узлами сделает недоступным лишь некоторые узлы, тогда как вся система в целом сохранит свою работоспособность.
  4. Повышение надежности. Если организована репликация данных, в результате чего данные и их копии размещены на более чем одном узле, отказ отдельного узла или соединительной связи между узлами не приведет к недоступности данных в системе.
  5. Повышение производительности. СУРБД способствуют повышению скорости доступа к БД по сравнению с доступом к удаленной централизованной БД.
  6. Экономические выгоды.
    1. Закон Гроша: Мощность вычислительной установки возрастает пропорционально квадрату стоимости ее оборудования. Однако, в настоящее время считается общепринятым положение, согласно которому намного дешевле собрать из небольших компьютеров систему, мощность которой будет эквивалентна мощности одного большого компьютера.
    2. В случае, когда пользователи сильно удалены от централизованной БД из-за относительно высокой стоимости передачи данных по сети (по сравнению со стоимостью их локальной обработки) оказывается экономически выгодным разделить приложение на соответствующие части и выполнять необходимую обработку на каждом из узлов отдельно.
  7. Модульность системы. В распределенной среде расширение существующей системы осуществляется намного проще. Добавление в сеть нового узла не оказывает влияния на функционирование уже существующих. В централизованных же СУБД рост размера БД может потребовать замены и оборудования, и используемого программного обеспечения.
Недостатки СУРБД
  1. Повышение сложности. Распределенные СУБД, способные скрыть от конечных пользователей распределенную природу используемых ими данных и обеспечить необходимый уровень производительности, надежности и доступности, являются более сложными программными комплексами, чем централизованные СУБД.
  2. Увеличение стоимости. Увеличение сложности означает и увеличение затрат на приобретение и сопровождение СУРБД.
  3. Проблемы защиты. В распределенных системах требуется организовать контроль доступа не только к данным, реплицируемым на несколько различных узлов, но и защиту сетевых соединений самих по себе.
  4. Усложнение контроля за целостностью данных.
  5. Отсутствие стандартов.
    1. Отсутствуют стандарты на каналы связи и протоколы доступа к данным.
    2. Не существует инструментальных средств и методологий, способных помочь пользователям в преобразовании централизованных систем в распределенные.
  6. Недостаток опыта. Распределенные системы общего назначения еще не получили широкого распространения. Еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем.
  7. Усложнение процедуры разработки БД. Разработка распределенных БД требует принятия решения о фрагментации данных, распределения фрагментов по отдельным узлам и организации процедур репликации данных.

 

 

 1.5 12 правил Дейта для СУРБД

 

  1. Правило 0. Основной принцип. С точки зрения пользователя распределенная система должна выглядеть в точности так, как и обычная, нераспределенная система.
  2. Правило 1. Локальная автономность. Узлы в распределенной системе должны быть автономными, т. е. локальные данные принадлежат локальным владельцам и сопровождаются локально.
  3. Правило 2. Отсутствие опоры на центральный узел. В системе не должно быть ни одного узла, без которого система не сможет функционировать, т. е. в системе не должно существовать центральных серверов таких служб, как управление транзакциями, оптимизация запросов и управление глобальным системным каталогом.
  4. Правило 3. Непрерывное функционирование. В системе никогда не должна возникать потребность в плановом останове ее функционирования для выполнения операций таких, как добавление или удаление узла из системы, динамическое создание или удаление фрагментов с одного или нескольких узлов.
  5. Правило 4. Независимость от расположения. Пользователь должен получать доступ к БД с любого из узлов. Пользователь должен получать доступ к любым данным так, как если бы они хранились на его узле, независимо от того, где они физически сохраняются.
  6. Правило 5. Независимость от фрагментации. Пользователь должен получать доступ к данным независимо от способа их фрагментации.
  7. Правило 6. Независимость от репликации. Пользователь не должен нуждаться в сведениях о наличии репликации данных.
  8. Правило 7. Обработка распределенных запросов. Пользователь должен иметь возможность объединять данные, расположенные более сем на одном узле.
  9. Правило 8. Обработка распределенных транзакций. СУРБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов, как в отдельных системах, так и в сети.
  10. Правило 9. Независимость от типа оборудования. СУРБД должна быть способна функционировать на оборудовании с различными вычислительными платформами.
  11. Правило 10. Независимость от операционной системы. СУРБД должна быть способна функционировать под управлением различных операционных систем.
  12. Правило 11. Независимость от сетевой архитектуры. СУРБД должна быть способна функционировать в сетях с различной архитектурой и типами носителей.
  13. Правило 12. Независимость от типа СУБД. СУРБД должна поддерживать гетерогенность.

 

II. Разработка информационно-логической модели предметной области

 

Предметная область: Автотранспортное предприятие

Минимальный список характеристик:

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

 

 

2.1 Описание предметной области

 

На автотранспортном предприятии водителю выдается путевой лист при выезде автомобиля. Разные водители могут ездить на разных автомобилях. Исходя из это, для учета работы водителей и выезда автомобилей, необходимо иметь представление о трех объектах: водителях, автомобилях и выездах в рейс.

Предметная область определена: Автотранспортное предприятие. Круг задач также определен.

Автотранспортное предприятие:

Автомобили;

Водители;

Путевые листы.

 

2.2 Информационно-логическая модель

 

Информационный объект - это информационное описание некоторого реального объекта, процесса, явления или события. Информационный объект образуется совокупностью взаимосвязанных реквизитов, представляющих качественные и количественные характеристики предметной области. Примерами информационных объектов могут быть Книги, Издательство, Автор, Читатель и т. п. Каждому информационному объекту нужно присвоить уникальное имя, соответствующее этому объекту.

Реквизиты каждого информационного объекта должны отвечать определенным требованиям:

• информационный объект должен содержать уникальный идентификатор (ключ);

• все описательные реквизиты должны быть взаимонезависимыми;

• все реквизиты, входящие в составной ключ, должны быть также взаимонезависимыми;

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

• при составном ключе описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ;

• каждый описательный реквизит не может зависеть от ключа опосредовано, т. е. через другой промежуточный реквизит.

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

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

• одно-однозначные ;

• одно-многозначные;

• много-многозначные.

На приведенной ниже схеме объект Автомобили содержит атрибуты Номерной знак автомобиля, Марка автомобиля, Техническое состояние, Средняя скорость, Грузоподъемность, Расход топлива и Мощность двигателя. Информацию об автомобилях, выезжающих в рейс содержит объект Путевые листы, поэтому соединяем объекты Автомобили и Путевые листы по атрибуту Номерной знак автомобиля. Аналогично, информацию о водителях содержат объекты Водители и Путевые листы, поэтому соединяем эти объекты по атрибуту Табельный номер. Отметим, что в объекте Водители атрибут имеет имя Табельный номер, а в объекте Путевые листы – Водитель, но по смыслу эти атрибуты идентичны. То же относится и к объектам Автомобили и Путевые листы, где атрибуты Номерной знак автомобиля и Автомобиль являются одним и тем же.

Связь между объектами Автомобили и Водители осуществляется через объект Путевые листы. Поэтому связь между объектами Автомобили и Путевые листы имеет тип «один – ко – многим» и связь между объектами Водители и Путевые листы также имеет тип «один – ко – многим»

 






 

 

 

 

 

 

 

 

 

 


 



 

 

 

 

 

 

 

 

 

 

 

Список использованной литературы

 

  1. Акулов О.А Информатика. Базовый курс / О.А. Акулов, Н.В. Медведев М.: Омега-Л, 2005. – 552 с.
  2. Гектор Г.М. Системы баз данных. Полный курс / Г.М. Гектор, Дж. Ульман, Дж.Уидом Издательство: Вильямс, 2003. – 537 с.
  3. Глушаков С. В. Базы данных / С. В. Глушаков, Д. В. Ломотько М.: АСТ,  2002. – 340 с.
  4. Д. Кренке Теория и практика построения баз данных, 8-е издание / Д. Кренке СПб.: Питер, 2003. – 460 с.
  5. Кузин А. В. Базы данных / Кузин А. В., Левонисова С. В. М.: Академия , 2008. – 423 с.
  6. Кузнецов  С. Д. Основы баз данных, 2-е издание / С. Д. Кузнецов М.: Бином, 2007. – 517с.
  7. Симонович С.В. Информатика. Базовый курс / С.В. Симонович и др. - СПб: Питер, 2004. — 640 с. 
  8. http://abc.vvsu.ru/Books/up_inform_tehnol_v_ekon/page0019.asp
  9. http://do.bti.secna.ru/lib/book_it/istor_razv.html
  10. http://www.csu.ac.ru/~iren/courses/book/KarpovaT/p10.pdf

 

 

 


 



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