Рис. 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 | Независимость от баз данных | распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов. |
БИБЛИОГРАФИЧЕСКИЙ СПИСОК