Разработка базы данных по доставке почты

Введение.

Настоящая курсовая работа  (далее КР) посвящена вопросам разработки базы данных (далее БД) по доставке почты.

Основными проблемами данной предметной области является:

• большой объём информации (информация о почтовых отправлениях, отправителях, получателях, услугах, тарифах и т.д.), который храниться в частной организации по доставке почты;
• не удобства при работе с хранимыми документами (поиск, снятие копий, резервное копирование).

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

Большое разнообразие СУБД требует различные подходы к  процессу разработки и реализации БД. В КР для реализации БД будем использовать следующие СУБД: Visual FoxPro и InterBase.

Основными проблемами при  разработке и реализации БД являлось отсутствие:

1. знания предметной области;
2. навыков работы с Visual FoxPro и InterBase.

  Целью данной КР является формирование навыков разработки БД по доставке почты и реализации его в СУБД.

Для достижения поставленной цели требуется решит следующие  задачи:

1. описание предметной области;
2. инфологическое проектирование;
3. даталогическое проектирование;
4. реализация БД для СУБД Visual FoxPro;

5)  Реализация БД для СУБД InterBase. 
1 Описание предметной области

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

Для отправления почты  необходимо указать информацию об отправителе  и получателе, а именно Ф.И.О., адрес и почтовый индекс.

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

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

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

2  Инфологическое проектирование

2.1 Построение  инфологической модели

Как уже отмечалось ранее, инфологическая модель строится на основе приведенной предметной области.

Названия сущностей  возьмем такими, чтоб они совпадали с названиями объектов.

В результате получим ER-модель, изображенную на рисунке 2.1

Рисунок 2.1 – Полная ER-диаграмма 

2.2  Разработка  текстового описания

2.2.1 Определение сущностей  и их свойств

При анализе определенной выше предметной области можно выделить набор сущностей проектируемой базы данных.

Сущность «Почтовое отправление» определяет данные о почтовом отправлении  и содержит свойства:

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

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

в) Дата отправления. Свойство предназначено для хранения даты отправления, датой отправления считается день приема посылки; свойство также является обязательным для заполнения;

г) Ценность. Свойство предназначено для хранения информации об объявленной ценности почтового отправления в рублях, обязательно для заполнения.

Сущность «Отправитель» содержит следующие свойства:

а) Номер отправителя. Свойство предназначено для хранения уникального номера отправителя, уникально на всем множестве отправителей, обязательно для заполнения;

б) Ф.И.О. Свойство содержит информацию о фамилии, имени и отчестве отправителя;

в) Адрес. Свойство предназначено для хранения полного адреса отправления; свойство также является обязательным для заполнения;

г) Индекс. Свойство предназначено для хранения почтового индекса, обязательно для заполнения.

Сущность «Получатель» содержит следующие свойства:

а) Номер получателя. Свойство предназначено для хранения уникального номера получателя, уникально на всем множестве получателей, обязательно для заполнения;

б) Ф.И.О. Свойство содержит информацию о фамилии, имени и отчестве получателя;

в) Адрес. Свойство предназначено для хранения полного адреса получателя; свойство также является обязательным для заполнения;

г) Индекс. Свойство предназначено для хранения почтового индекса, обязательно для заполнения.

Сущность «Услуга» определяет общие данные о предоставляемой услуге по доставке почтовых отправлений  и содержит свойства:

а) Название услуги. Свойство предназначено для хранения текстового наименования услуги, обязательно для  заполнения;

б) Код услуги. Свойство предназначено для хранения уникального  номера услуги, уникально на всем множестве  услуг, обязательно для заполнения;

в) Описание услуги. Свойство предназначено для хранения текстового описания услуги, обязательно для заполнения.

Сущность «Тариф» определяет общие данные о предоставляемой услуге по доставке почтовых отправлений  и содержит свойства:

а) Название тарифа. Свойство предназначено для хранения текстового наименования тарифа, обязательно для заполнения;

б) Код тарифа. Свойство предназначено для хранения уникального номера тарифа, уникально на всем множестве тарифов, обязательно для заполнения;

в) Название города. Свойство обязательно для заполнения;

г) Срок доставки. Свойство предназначено для хранения срока доставки почтового отправления, срок задается в днях; обязательно для заполнения;

д) Тип отправления. Свойство предназначено для хранения типа отправления (посылка, бандероль, документы), обязательно для заполнения;

е) Цена. Свойство предназначено для хранения информации о стоимости тарифа, обязательно для заполнения.

Сущность «Справочник мест проведения операций» определяет общие данные о предоставляемой услуге по доставке почтовых отправлений  и содержит свойства:

а) Название ОПС. Свойство предназначено для хранения текстового наименования ОПС, обязательно для заполнения;

б) Код ОПС. Свойство предназначено для хранения уникального номера ОПС, уникально на всем множестве ОПС, обязательно для заполнения;

в) Тип ОПС. Свойство обязательно для заполнения;

г) Адрес. Свойство предназначено для хранения полного адреса ОПС; свойство также является обязательным для заполнения;

д) Индекс. Свойство предназначено для хранения почтового индекса, обязательно для заполнения;

е) Телефон. Свойство является необязательным;

ж) Режим работы. Свойство является необязательным;

2.2.2  Установление связей, определение ассоциаций

Рассмотрим сформированные объекты на предмет выявления связей различной природы между ними.

Связь «Тариф – Почтовое отправление» один ко многим, необязательная с главной стороны. Обозначает, что для одного конкретного почтового отправления обязательно нужно выбрать тариф и, причем только один. На один тариф может приходиться одно или несколько почтовых отправлений, или не приходиться вовсе.

Связь «Услуга – Тариф» один ко многим, обязательная с обеих сторон. Обозначает, что одна конкретная позиция тарифов обязательно относится к услуге и, причем только  к  одной. Одна  услуга должна объединять в себе один или несколько тарифов.

Связь «Отправитель – Почтовое отправление» один ко многим, необязательная с главной стороны. Обозначает, что одно конкретное почтовое отправление обязательно имеет отправителя и, причем только  одного. Один  отправитель может отправлять одно или несколько почтовых отправлений, или не отправлять вовсе.

Связь «Получатель – Почтовое отправление» один ко многим, необязательная с главной стороны. Обозначает, что одно конкретное почтовое отправление обязательно предназначено получателю и, причем только  одному. Один  получатель может получать одно или несколько почтовых отправлений, или не получать вовсе.

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

Связь «Справочник мест проведения операций – Отслеживание почтовых отправлений» один ко многим, необязательная с главной стороны. Обозначает, что операция над почтовым отправлением в конкретный день, месяц и год обязательно проводится в конкретном ОПС и, причем только в  одном. В одном ОПС может проводиться одна или несколько операций над почтовыми отправлениями, или не проводиться вовсе.

Ассоциация «Отслеживание почтовых отправлений» связывает сущность «Почтовое отправление» и  «Справочник мест проведения операций», и предназначена для занесения данных об операциях и датах по почтовому отправлению и включает следующие свойства:

а) Операция. Свойство предназначено для хранения текстового наименования операции, обязательно для заполнения;

б) Атрибут операции. Свойство обязательно для заполнения;

в) Дата. Свойство предназначено для хранения даты проведения операции по почтовому отправлению, обязательно для заполнения.

2.2.3 Описание ограничений  целостности

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

2.2.4 Описание информационных запросов

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

3  Даталогическое  моделирование

3.1  Модификация инфологической модели

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

После проведения описанных  преобразований получим инфологическую модель пригодную для прямого  преобразования в реляционную логическую модель. Полученная модель приведена на рисунке 3.1.

Рисунок 3.1 – Модифицированная инфологическая модель

3.2  Построение логической модели

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

Для получения  из инфологической модели даталогической выполним:

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

Полученная даталогическая модель приведена на рисунке 3.2.

Рисунок 3.2 – Даталогическая модель

3.3  Нормализация логической модели

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

3.4  Описание логической модели

3.4.1  Описание атрибутов

Все атрибуты, их описание и тип, приведем в виде таблиц.

Таблица 3.1 – Почтовое отправление

Таблица 3.2 – Отправитель

Таблица 3.3 – Получатель

Таблица 3.4 – Тариф

Таблица 3.5 – Услуга

Таблица 3.6 – Отслеживание почтовых отправлений

Таблица 3.7 – Справочник мест проведения операций

3.4.2 Правила поддержки ссылочной  целостности для связей

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

• Запрет. Операция добавления, изменения, удаления запрещается, если приведет к нарушению ссылочной целостности
• Каскад. При изменении (удалении) в родительском отношении, приводящем к нарушению ссылочной целостности, выполняются аналогичные изменения (удаления) в дочернем отношении
• Сброс. Значения внешнего ключа, переставшие соответствовать значениям первичного ключа родительского отношения, очищаются (сбрасываются в NULL)
• Переключение. Значения внешнего ключа, переставшие соответствовать значениям первичного ключа родительского отношения, заменяются на задаваемые указанным образом допустимые значения.

Зададим способ поддержки  обязательных связей в виде таблицы.

Таблица 3.8 – Способ поддержки обязательных связей

Продолжение Таблицы 3.8 – Способ поддержки обязательных связей

4 Физическое проектирование

4.1  Физическое  проектирование для СУБД Visual FoxPro

Графическое представление  БД Visual FoxPro (распечатка окна Конструктора БД) представлено на рисунке 4.1.

Рисунок 4.1 – Графическое представление  БД в Visual FoxPro

В таблице 4.1 приведены данные, введенные для описания полей созданных таблиц.

Таблица 4.1 – Описание полей таблиц

В таблице 4.2 приведены  данные, задающие индексы для создаваемых  таблиц.

Таблица 4.2 – Описание индексов таблиц

В таблице 4.3 приведены  данные, описывающие реализованные  ограничения целостности данных в таблицах.

Таблица 4.3 – Описание ограничений целостности данных в таблицах