Распределенные баз данных и распределенных СУБД (стр. 6 из 8)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

Клиент

банк

наз_фирм

адр_кл

тел_кл

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

НЗ

Клиент

ннтов

цена

кол_во

срок

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

ннтов

наз_тов

стоим

без_НДС

кол_во_скл

ед_изм

ТМБ

марка

гост

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

ИДП

ФИО_пос

наим_фир

адр_пос

тел_пос

счет

рс

мфо

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

тн

ФИО

адрес

тел

дата_рож

рнн

стаж

оклад

долж

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

ГЛОССАРИЙ

№п/п	Новое понятие	Содержание
1	Распределенная база данных (Distributed DataBase - DDB)	база данных, включающая фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД
2	Однородная распределенная база данных	каждая локальная база данных управляется одной и той же СУБД
3	Неоднородная распределенная база данных	локальные базы данных могут относиться даже к разным моделям данных
4	Локальная автономия	управление данными на каждом из узлов распределенной системы выполняется локально
5	Независимость от центрального узла	все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных
6	Непрерывные операции	возможность непрерывного доступа к данным в рамках DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах
7	Прозрачность расположения	Пользователь, обращающийся к DDB, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы.
8	Прозрачная фрагментация	возможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое
9	Тиражирование данных	асинхронный процесс переноса изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы
№п/п	Новое понятие	Содержание
10	Прозрачность тиражирования	возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы.
11	Обработка распределенных запросов	возможность выполнения операций выборки над распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL.
12	Обработка распределенных транзакций	возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных.
13	Независимость от оборудования	качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей - от мэйнфреймов до "персоналок".
14	Независимость от операционных систем	многообразие операционных систем, управляющих узлами распределенной системы.
15	Прозрачность сети	в распределенной системе возможны любые сетевые протоколы.
16	Независимость от баз данных	распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК