Распределенные баз данных и распределенных СУБД

      Проведем  анализ связей между сущностями:

      КЛАДОВЩИК, ЗАКАЗ - оформляет; связь типа М:М;

      КЛАДОВЩИК, ТОВАР – получает, связь типа М:М;

      ПОСТАЩИК, ТОВАР - поставляет, связь типа М:М;

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

      

 

 

 
 

Рис. 7 Концептуальная схема «Склад». 

     2.2 Этап логического проектирования 

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

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

      1. ЗАКАЗ (НЗ, Клиент, банк, наз_фирм, адр_кл, тел_кл, ннтов, цена, кол_во, срок);

      Заказ определяется по номеру заказа, поэтому в качестве ключевого выберем атрибут «Номер заказа».

      НЗ аà [все атрибуты].

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

      ЗАКАЗ (НЗ, Клиент, ннтов, цена, кол_во, срок);

      КЛИЕНТ(Клиент, банк, наз_фирм, адр_кл, тел_кл);

      В новом отношении Клиент ключевыми  атрибутами являются Клиент и банк, то есть

      КЛИЕНТ, БАНКаà [все атрибуты].

      Других  функциональных зависимостей в отношениях нет, оба отношения находятся в 3НФ

      2. ТОВАР (ннтов, наз_тов, стоим, без_НДС, кол_во_скл, ед_изм, ТМБ, марка, гост);

      Товары  учитываются по номенклатурным номерам, поэтому в качестве ключевого атрибута выберем «ННТОВ» - номенклатурный номер товара.

      ННТОВ аà [все атрибуты].

      Других  ФЗ отсутствуют, отношение находится  в 3НФ.

      3. ПОСТАВЩИК (ИДП, ФИО_пос, наим_фир, адр_пос,тел_пос, счет, рс, мфо );

      .

      Поставщики определяется по идентификационному коду, поэтому в качестве ключевого выберем атрибут «ИДП».

      ИДП аà[все атрибуты].

      Другие  ФЗ отсутствуют, отношение находится  в 3НФ.

      4. КЛАДОВЩИК (тн, ФИО, адрес, тел, дата_рож, рнн, стаж, оклад, долж);

      Кладовщик определяется по табельному номеру, поэтому в качестве ключевого выберем атрибут «ТН».

      ТН аà[все атрибуты].

      Другие  ФЗ отсутствуют, отношение находится  в 3НФ.

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

     Отношение КЛИЕНТ:

 

     Отношение ЗАКАЗ:

 

     Отношение ТОВАР:

 

     Отношение ПОСТАВЩИК:

 

     Отношение КЛАДОВЩИК:

 

     Ключи отношений выделены подчеркиванием. 

     2.3 Этап машинного проектирования 

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

      На  данном этапе выполняется описание структуры таблиц с указанием  имен, типов, размерностей полей, входящих в состав БД.

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

 

       ЗАКЛЮЧЕНИЕ 

            В данной курсовой работе были рассмотрены аспекты создания распределенных баз данных на примере Systrm R*. Рассмотрена структура распределенных БД, требования к распределенным БД.

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

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

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

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

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

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

 

       ГЛОССАРИЙ