Разработка ИС компании Content по доставке и отправке почты

 

Основными целями проекта автоматизации  компании “Content” являются:

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

—Повышение эффективности работы всех подразделений компании и обеспечение  ведения учета в единой информационной системе.

 

1. Проектирование  БД

1.1. Анализ предметной  области

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

Модель предметной области. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Из наиболее известных можно назвать методику структурного анализа SADT и основанную на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методику объектно-ориентированного анализа UML, и др. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.

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

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

В рамках проекта развертывание  новой системы предполагается осуществить  только в следующих подразделениях “Content”.

• Дирекция
• Операционный отдел;
• Офисные работники;
• Офис менеджер;
• Группа планирования и маркетинга;
• Группа логистики;
• Учетно-операционный отдел;
• Учетный отдел;
• IT менеджер;
• Отдел ЖД перевозок;
• Отдел Авиаперевозок;
• Отдел Автоперевозок;
• Таможенный отдел;
• Отдел сертификации;
• Бухгалтерия.

 

Одно из основных требований компании “Content” к будущему решению состоит в том, чтобы оно было построено на фундаменте единой интегрированной системы, а работа всех сотрудников велась в одном информационном пространстве.

 

Ключевые функциональные требования к информационной системе:

1. Мощные средства защиты данных от несанкционированного доступа. Разграничения доступа к данным в соответствии с должностными обязанностями.
2. Возможность удаленного доступа.
3. Управление запасами. Оперативное получение информации об остатках на складе.*
4. Управление закупками. Планирование закупок в разрезе поставщиков.
5. Управление продажами. Контроль лимита задолженности с возможностью блокировки формирования отгрузочных документов.
6. Полный контроль взаиморасчетов с поставщиками и клиентами.
7. Получение управленческих отчетов в необходимых аналитических срезах - как детальных для менеджеров, так и агрегированных для руководителей подразделений и директоров фирмы.

1.2. Инфологическая модель  данных

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

 

База данных «Почтовое  отделение» содержит следующие сущности:

1. Сущность «Операция» - содержит информацию о проведенных операциях: код операции и вид: прием, отправку почты, или подписку на прессу;
2. Сущность «Получение» - содержит информацию о полученной почте: код операции, вид получения, данные отправителя и получателя, вес и ценность;
3. Сущность «Отправка» - содержит информацию об отправленной почте: код операции, вид отправки, данные отправителя и получателя, вес и ценность;
4. Сущность «Подписка» - содержит информацию о произведенных подписках на газету или журнал: код операции, код подписчика, шифр издания, срок и стоимость подписки.
5. Сущность «Подписчик» - содержит информацию о подписчике, а именно: код подписчика, Ф.И.О и адрес.
6. Сущность «Издание»- содержит информации о газетах и журналах доступных для подписки: шифр издания, название газеты или журнала, цена.

Связь «получает» - М:1-несколько  получений, являются лишь одной операцией  получения.

Связь «отправляет» - М:1-несколько  отправлений, являются лишь одной операцией  отправления.

Связь «подписывает» - М:1-несколько  подписок, являются лишь одной операцией  подписка.

Связь «подписывается» - 1:М - один подписчик может оформить несколько подписок.

Связь «заказывает» - 1:М –  на одно издание можно оформить несколько  подписок.

 

Рис.1. Инфологическая модель БД «Почтовое отделение».

1.3. Даталогическая модель данных

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

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

 

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

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

2. Физическая реализация  базы данных.

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

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

При разработке  физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно  ли выбраны индексы? Насколько много программного кода в виде триггеров и хранимых процедур необходимо разработать для поддержания целостности данных?

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

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

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

2.1. Структура таблиц БД  “Content”

Таблица 1. «Операционный  отдел»

Таблица 2. «Отдел ЖД перевозок»

Таблица 3. «Отдел авиа-перевозок»

Таблица 4. «Отдел авто-перевозок»

Таблица 5. «Таможенный  отдел»

Таблица 6. «Бухгалтерия»

 

 

Таблица 7. IT- менеджер

.

Таблица 8. Офис менеджер

.

Таблица 9. Дирекция

.

 

 

 

 

Таблица 10. Офисные сотрудники

 

 

Рис.2.  Связи между таблицами в базе данных

2.2. Создание Запросов

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

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

Для того чтобы создать запрос, необходимо выбрать запросы в менеджере  проектов и выбрать на панели создать. После чего откроется окно «Новый запрос» в котором необходимо выбрать, с помощью чего вы хотите создать запрос. Запросы можно создавать с помощью: конструктора, мастера. При выборе конструктора запросов, мы видим, что окно разделено на две панели. Верхняя панель содержит выбранные для данного запроса таблицы. Таблицы представлены списками полей. Нижняя панель является бланком запроса, который нужно заполнить.

При формировании столбца бланка запроса  необходимо знать следующее:

• Во вкладке Поле включается имя поля, используемое в запросе
• Во вкладке Объединение задается объединение таблиц
• Во вкладке Условие отбора задаются условия отбора записей
• В строке Сортировка выбирается порядок сортировки записей результата
• В строке Группировка выбирается порядок группировки записей результата