Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

1.1 Исследование информационных потребностей пользователя

В компании существует сотрудник - менеджер клиентской службы, в обязанности которого входит:

· ежедневно заносить данные о клиентах из «Анкет покупателей» в электронные таблицы MS Excel;

· в конце отчетного периода обобщать все данные и формировать из них необходимые отчеты, в том числе для сотрудников смежных отделов;

· ежедневная рассылка поздравлений клиентов с Днем рождения и другими праздниками;

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

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

Также имеет место «человеческий фактор»: в суете менеджер может что то забыть, из-за невнимательности предоставить неверные данные, во множестве файлов не найти вовремя необходимые сведения. Любые последствия «человеческого фактора» являются неприятными и недопустимыми, и могут негативно сказаться на работе компании. Велика вероятность дублирования вводимых данных и возникающей при этом противоречивости.

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

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

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

При этом программная система должна выполнять функции по хранению информации и генерированию отчетов.

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

С разрабатываемой программной системой будет работать следующий персонал:

· сотрудники отдела PR и рекламы;

· сотрудники отдела продаж;

· сотрудники отдела ассортиментной политики;

На данный момент совместный доступ к информации о клиентах невозможен, так как MS Excel не является многопользовательской программой. Сотрудникам приходится использовать их только «на чтение» или «плодить» локальные копии файлов, что, в конечном итоге, приводит к использованию недостоверной или неактуальной информации.

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

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

· анкета на сайте компании заполняется для вступления в клуб покупателей и получения по электронной почте купона на 5% скидку;

· анкета из коробки с обувью заполняется покупателем и высылается по почте или передается продавцу в магазине. За время работы компании данный вид анкет не раз перерабатывался и в зависимости от года выпуска приобретенной пары покупатель заполняет анкету различного вида;

· анкета, заполняемая покупателем при покупке обуви в фирменном магазине для получения дисконтной карты;

Основной информацией содержащейся во всех видах анкет является:

· Ф.И.О. покупателя;

· пол;

· дата рождения;

· контактный телефон;

· адрес электронной почты;

· регион;

· номер дисконтной карты;

· артикул приобретенной пары.

Дополнительная информация, содержащаяся в остальных видах анкет:

· домашний адрес (иногда отдельно выделяется город);

· семейное положение;

· род занятий;

· материальное положение.

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

· критерии при покупке обуви;

· марки ранее приобретенной или желаемой обуви;

· откуда узнали о марке RALF Ringer;

· основные характеристики обуви RALF Ringer;

· высказывания о стоимости обуви RALF Ringer;

· разнообразие марок приобретаемой обуви;

· предпочитаемые СМИ (телеканалы, телепрограммы, газеты, журналы).

Каждый отдел использует свои данные для получения необходимой именно им отчетности.

Основной информацией используемой отделом продаж является:

· анализ региона;

· анализ продаж конкретной модели в различных регионах;

· % продаж конкретных моделей от общего количества продаж.

Основной информацией используемой отделом PR и рекламы является:

· распределение клиентов по регионам;

· анализ популярности СМИ.

Основной информацией используемой отделом ассортиментной политики является:

· анализ популярности марок;

· анализ характеристик обуви;

· анализ критериев при покупке обуви.

1.2 Анализ коммерческих программных продуктов

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

Рис. 1.1. Наиболее популярные в России CRM-системы

Terrasoft CRM

Terrasoft CRM - мощная CRM-система, которая охватывает основные сферы управления взаимоотношениями с клиентами и организации внутренних процессов компании.

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

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

Основными технологическими преимуществами CRM-системы Terrasoft является использование передовых технологий, поддержка популярных СУБД разного масштаба, функционала и стоимости (Microsoft SQL Server, Oracle и Firebird), проверенных стандартов и протоколов.

Рис. 1.2. Пример окна Terrasof CRM

Эти и другие факторы обеспечивают высокую надежность, производительность и масштабируемость CRM-систем Terrasoft.

Программный продукт Terrasoft CRM позволяет решать следующие задачи:

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

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

· Планирование и управление продажами: управление потенциальными сделками, управление проектами, контроль сроков оплаты, поставки и выполнения других обязательств, воронка продаж.

· Управление маркетинговыми кампаниями: функционал для планирования и проведения маркетинговых кампаний любой сложности, маркетинговые исследования, проведение анкетирования, рассылки, отчеты.

· Управление проектами: планирование, распределение, мониторинг использования ресурсов в проекте; мониторинг хода проекта по выделенным стадиям; управление календарными сроками по проекту (диаграмма Гантта);

· Управление ресурсами: учет затрат, оценка прибыльности клиента, управление товарооборотом, планирование работ.

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

· Управление рабочим временем: органайзер, групповой календарь.

· Электронная почта: интеграция с MS Outlook, автоматизация массовых персонифицированных E-mail рассылок с использованием шаблонов.

Таблица 1.1

Характеристика	Значение характеристики
Интеграция с MS Office:	Да
Рекомендуемые СУБД:	MS SQL, Oracle, Firebird
Стоимость клиентской лицензии:	200-500 $
Стоимость серверной лицензии:	Не требуется
Стоимость поддержки (12 мес):	10-25% в год от стоимости лицензий

Microsoft Dymanics CRM

Microsoft Dynamics CRM - гибкое и доступное решение для управления взаимоотношениями с клиентами, объединяющее инструменты для сотрудников отделов продаж, маркетинга и обслуживания клиентов. Система позволяет сократить цикл продажи, сделать его более предсказуемым и увеличить количество успешно закрытых сделок.

Рис. 1.3. Пример окна Microsoft Dynamics CRM

Основные преимущества Microsoft Dynamics CRM:

· удобный пользовательский интерфейс;

· полная интеграция с Microsoft Office System;

· мощные инструменты анализа данных;

· простота управления бизнес-процессами;

· контроль за выполнением поставленных задач;

· низкая совокупная стоимость владения;

· быстрый возврат инвестиций.

Система Microsoft Dynamics CRM работает более чем в 20 000 компаний на более чем 1 млн. рабочих мест во всем мире.

В России Microsoft Dynamics CRM используют такие компании из разных отраслей, таких как, например, авиакомпании, радиостанции, банки и многие другие

В 2008 году российскому рынку была представлена система Microsoft Dynamics CRM 4.0. В числе особенностей новой версии:

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

· Многоязыковая поддержка, благодаря которой пользователи внутри одной компании могут работать с интерфейсом на разных языках (из 25 доступных) и переключать их в случае необходимости.

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

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

· Новый механизм автоматизации бизнес-процессов на основе технологии Microsoft Windows Workflow Foundation, который позволяет быстро и легко настраивать бизнес-процессы как внутри CRM-системы, так и между различными информационными системами организации.

· Улучшенная интеграция с продуктами Microsoft Office, включая Microsoft Office Communication Server 2007 с возможностью задействовать индикаторы присутствия пользователей CRM-системы, что упрощает и ускоряет взаимодействие сотрудников внутри компании с помощью обмена мгновенными сообщениями, технологий VoIP и других каналов.

Таблица 1.2

Характеристика	Значение характеристики
Интеграция с MS Office:	Да
Рекомендуемые СУБД:	MS SQL
Стоимость клиентской лицензии:	500-1000 $
Стоимость серверной лицензии:	>1000 $
Стоимость поддержки (12 мес):	<10% в год от стоимости лицензий
Стоимость аренды лицензии (12 мес):	<100 $

1С:CRM 8

Система 1С:CRM 8 предназначена для предприятий сферы услуг и торговли, использующих в качестве основной учетной системы «1С: Бухгалтерию 8», для компаний, реализующих товары и услуги в режиме многоэтапных продаж, применяющих систему заказов и договорную схему ценообразования.

Использование 1С:CRM 8 способствует реализации клиенто-ориентированной стратегии без приобретения дорогостоящих решений по управлению торговлей и продажами.

Рис. 1.4. Пример окна 1С:CRM 8

Функционал 1С:CRM 8 позволяет получать и эффективно использовать разноплановую оперативную информацию о состоянии клиентской базы, объеме и составе продаж, организовывать программы лояльности, контролировать и корректировать работу сбытовых и прочих служб.

Программа решает задачи:

· Организации процесса работы с клиентами путем учета обращений и контактов клиентов с сотрудниками, персонификации обслуживания и адресной работы с клиентами;

· Контроля использования средств, выделяемых на проведение маркетинговых мероприятий;

· Планирования продаж и работы с клиентами, а также контроля исполнения таких планов;

· Обеспечения преемственности работы с клиентом, выявление причин оттока клиентов;

· Стандартизации документооборота и предоставления участникам процесса достоверной оперативной и аналитической информации.

Таблица 1.3

Характеристика	Значение характеристики
Интеграция с MS Office:	Да
Язык прикладной части:	1Сv8
Рекомендуемые СУБД:	MS SQL, Oracle, Postgre, SQL
Стоимость клиентской лицензии:	<100 $
Стоимость серверной лицензии:	Не требуется
Стоимость поддержки (12 мес):	<10% в год от стоимости лицензий
Стоимость аренды лицензии (12 мес):	<100 $

Каждая из рассмотренных систем предоставляет широкий выбор средств и инструментов для управления взаимоотношениями с клиентами. Однако выделим основные недостатки всех рассмотренных систем для рассматриваемой компании:

1) высокие системные требования;

2) высокая стоимость внедрения, сопровождения и лицензирования;

3) лишний функционал.

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

1.3 Разработка общей структуры ИС

Большинство современных CRM систем базируются на клиент-серверной архитектуре. При этом сама система состоит из трех основных звеньев:

· клиентское ПО;

· ПО хранилища данных;

· собственно системы CRM.

Клиентское программное обеспечение будет реализовано как stand-alone программа («толстый» клиент), обеспечивающая максимум комфорта и производительности.

Программным обеспечением хранилищ данных выбрана реляционная база данных от известного и хорошо зарекомендовавшего себя поставщика - Microsoft SQL Server. Так как платформой для CRM выбрана Windows, то Microsoft SQL Server вне конкуренции - развитые средства управления, поддержка многопроцессорных конфигураций и отличная интеграция с другими приложениями от Microsoft позволяют использовать данное решения для предприятий малого и среднего масштаба.

В качестве среды программирования выбрана Delphi.

Embarcadero Delphi, ранее Borland Delphi и CodeGear Delphi, - интегрированная среда разработки программного обеспечения для Microsoft Windows на языке Delphi (ранее Object Pascal), созданная первоначально фирмой Borland и на данный момент принадлежащая и разрабатываемая Embarcadero Technologies. Embarcadero

Cреда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений (RAD - rapid application development), поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. VCL - библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами.

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

Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре «клиент-сервер».

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

· организовать многопользовательский режим работы с программной системой;

· реализовать распределение прав доступа - полный доступ, редактирование базы данных, только чтение;

· реализовать простой и эргономичный пользовательский интерфейс;

· реализовать удобный доступ к информации о клиентах (возможность выбора видимых полей, различные виды поиска, сортировки, группировки и экспорта данных);

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

· реализовать возможность ведения списка клиентов (добавление, редактирование);

· реализовать возможность ведения продуктового каталога;

· реализовать возможность интеграция с MS Office, импорта и экспорта в MS Excel;

· реализовать возможность интеграции с почтовым клиентом MS Outlook;

· реализовать возможность создания именных рассылок;

· реализовать возможность формирования статистических диаграмм и аналитических отчетов.

2. Разработка программного обеспечения

2.1 Разработка информационной модели

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

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

Одним из основных компьютерных способов распознавания сущностей в базе данных является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом.

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

Сущности не существуют отдельно друг от друга. Между ними имеются реальные отношения (Relationship), и они должны быть отражены в информационной модели предметной области. Обычно связь обозначается глаголом.

Типичной формой документирования информационной модели предметной области являются диаграммы «сущность-связь» (ER-диаграммы). ER-диаграмма позволяет графически представить все элементы информационной модели

Связи характеризуются степенью связи и классом принадлежности сущности к связи. Степень (мощность) связи - это отношение числа сущностей, участвующих в образовании связи. Например, «один-к-одному», «один-ко-многим», «многие-ко-многим». Класс принадлежности сущности - это характер участия сущности в связи. Различают обязательные и необязательные классы принадлежности сущности к связи. Обязательным является такой класс принадлежности, когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности.

В результате анализа предметной области были выявлены следующие сущности:

1) Клиенты - сущность, содержащая информацию о клиентах компании, потенциальный ключ - Код клиента;

2) Контакты - сущность, содержащая информацию о контактах клиента компании, потенциальный ключ - Код контакта;

3) Типы контактов - сущность, содержащая информацию о типах контактов, потенциальный ключ - Код типа контакта;

4) Дисконтные карты - сущность, содержащая информацию о дисконтных картах клиента компании, потенциальный ключ - Номер дисконтной карты;

5) Типы дисконтных карт - сущность, содержащая информацию о типах дисконтных карт, потенциальный ключ - Код типа дисконтной карты;

6) Анкеты - сущность, содержащая информацию о предпочтениях клиентов компании, потенциальный ключ - Код Анкеты;

7) Тип вопроса - сущность, содержащая вопросы для выявления предпочтений клиентов компании, потенциальный ключ - Код Вопроса;

8) Средства массовой информации (СМИ) - сущность, содержащая информацию о СМИ, предпочитаемых клиентами компании, потенциальный ключ - Код СМИ;

9) Тип СМИ - сущность, содержащая информацию о типах СМИ, потенциальный ключ - Код типа СМИ;

10) Род занятий - сущность, содержащая информацию о родах занятий клиентов компании, потенциальный ключ - Код рода занятия;

11) Источники знаний - сущность, содержащая информацию об источниках знаний клиентов о компании, потенциальный ключ - Код источника знаний;

12) Материальное положение - сущность, содержащая информацию о материальном положении клиентов компании, потенциальный ключ - Код материального положения;

13) Регионы - сущность, содержащая информацию о регионах проживания клиентов компании, потенциальный ключ - Код региона;

14) Продажи - сущность, содержащая информацию о продажах клиентам компании, потенциальный ключ - Код продажи;

15) Товары - сущность, содержащая информацию о товарах компании, потенциальный ключ - Артикул;

16) Фасон - сущность, содержащая информацию о фасонах товаров компании, потенциальный ключ - Код фасона;

17) Модель - сущность, содержащая информацию о моделях товаров компании, потенциальный ключ - Код модели;

18) Сезон - сущность, содержащая информацию о сезонах товаров компании, потенциальный ключ - Код сезона;

Между сущностями выявлены связи, а также степени связи и классы принадлежности сущностей:

1) Клиенты - Контакты - связь между сущностями Клиенты (необязательный класс принадлежности) и Контакты (обязательный класс принадлежности). Контакт может принадлежать только одному клиенту. У Клиента может быть несколько контактов. Степень связи: один-ко-многим.



Рис. 2.1. Связь Клиенты - Контакты

2) Типы контактов - Контакты - связь между сущностями Типы контактов (необязательный класс принадлежности) и Контакты (обязательный класс принадлежности). Контакт может иметь только один тип. Один и тот же тип контакта могут иметь несколько контактов. Степень связи: один-ко-многим.

Рис. 2.2. Связь Типы контактов - Контакты

3) Клиенты - Дисконтные карты - связь между сущностями Клиенты (необязательный класс принадлежности) и Дисконтные карты (обязательный класс принадлежности). Дисконтная карта может принадлежать только одному клиенту. У Клиента может быть несколько дисконтных карт. Степень связи: один-ко-многим.

Рис. 2.3. Связь Клиенты - Дисконтные карты

4) Типы дисконтных карт - Дисконтные карты - связь между сущностями Типы дисконтных карт (необязательный класс принадлежности) и Дисконтные карты (обязательный класс принадлежности). Дисконтная карта может иметь только один тип. Один и тот же тип могут иметь несколько дисконтных карт. Степень связи: один-ко-многим.



Рис. 2.4. Связь Типы дисконтных карт - Дисконтные карты

5) Клиенты - СМИ - связь между сущностями Клиенты (необязательный класс принадлежности) и СМИ (обязательный класс принадлежности). Каждая запись о предпочитаемой СМИ принадлежит только одному клиенту. Клиент может предпочитать множество СМИ. Степень связи: один-ко-многим.

Рис. 2.5. Связь Клиенты - СМИ

6) Тип СМИ - СМИ - связь между сущностями Тип СМИ (необязательный класс принадлежности) и СМИ (обязательный класс принадлежности). СМИ может иметь только один тип. Один и тот же тип могут иметь несколько СМИ. Степень связи: один-ко-многим.

Рис. 2.6. Связь Тип СМИ - СМИ

7) Клиенты - Анкеты - связь между сущностями Клиенты (необязательный класс принадлежности) и Анкеты (обязательный класс принадлежности). Каждая запись об ответе на вопрос принадлежит только одному клиенту. Клиент может отвечать на вопросы множество раз. Степень связи: один-ко-многим.



Рис. 2.7. Связь Клиенты - Анкеты

8) Тип вопроса - Анкеты - связь между сущностями Тип вопроса (необязательный класс принадлежности) и Анкеты (обязательный класс принадлежности). Одна запись Анкеты может иметь только один вопрос. На один и тот же вопрос могут отвечать несколько раз. Степень связи: один-ко-многим.

Рис. 2.8. Связь Тип СМИ - СМИ

9) Клиенты - Род занятий - связь между сущностями Клиенты (обязательный класс принадлежности) и Род занятий (необязательный класс принадлежности). У Клиента может быть только один Род занятия. Один и тот же Род занятий могут иметь несколько Клиентов. Степень связи: один-ко-многим.

Рис. 2.9. Связь Клиенты - Род занятий

10) Клиенты - Материальное положение - связь между сущностями Клиенты (обязательный класс принадлежности) и Материальное положение (необязательный класс принадлежности). У Клиента может быть только одно Материальное положение. Одно и то же Материальное положение могут иметь несколько Клиентов. Степень связи: один-ко-многим.



Рис. 2.10. Связь Клиенты - Материальное положение

11) Клиенты - Источник знаний - связь между сущностями Клиенты (обязательный класс принадлежности) и Источник знаний (необязательный класс принадлежности). У Клиента может быть только один Источник знаний. Один и то же Источник знаний могут иметь несколько Клиентов. Степень связи: один-ко-многим.

Рис. 2.11. Связь Клиенты - Источник знаний

12) Клиенты - Регионы - связь между сущностями Клиенты (обязательный класс принадлежности) и Регионы (необязательный класс принадлежности). Клиент может проживать только в одном регионе. В каждом регионе может проживать множество клиентов. Степень связи: один-ко-многим.

Рис. 2.12. Связь Клиенты - Регионы

13) Клиенты - Продажи - связь между сущностями Клиенты (необязательный класс принадлежности) и Продажи (обязательный класс принадлежности). Каждая продажа совершается только одним клиентом. Клиент может совершить множество продаж. Степень связи: один-ко-многим.

Рис. 2.13. Связь Клиенты - Продажи

14) Продажи - Товары - связь между сущностями Продажи (обязательный класс принадлежности) и Товар (необязательный класс принадлежности). Один и тот же товар может быть продан несколько раз. За один раз может быть продан только один товар. Степень связи: один-ко-многим.

Рис. 2.14. Связь Продажи - Товары

15) Фасоны - Товары - связь между сущностями Фасоны (необязательный класс принадлежности) и Товары (обязательный класс принадлежности). Один товар может иметь только один Фасон. К одному и тому же Фасону могут принадлежать несколько Товаров. Степень связи: один-ко-многим.

Рис. 2.15. Связь Фасоны - Товары

16) Модели - Товары - связь между сущностями Модели (необязательный класс принадлежности) и Товары (обязательный класс принадлежности). Один товар может принадлежать только одной Модели. К одной и той же Модели могут принадлежать несколько Товаров. Степень связи: один-ко-многим.

Рис. 2.16. Связь Модели - Товары

17) Сезоны - Товары - связь между сущностями Сезоны (необязательный класс принадлежности) и Товары (обязательный класс принадлежности). Один товар может принадлежать только одному Сезон. К одному Сезону могут принадлежать несколько Товаров. Степень связи: один-ко-многим.

Рис. 2.17. Связь Сезоны - Товары

2.2 Разработка серверной части ИС

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

1) нормализация сущностей предметной области:

· получить список атрибутов сущности;

· определить возможные ключи отношения;

· определить функциональные зависимости (ФЗ) в сущности;

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

Выявим атрибуты сущностей и назначим первичные ключи:

1) Сущность Клиенты содержит атрибуты: Код клиента, Ф.И.О. полностью, Пол, Дата рождения, E-Mail, Город, Код региона, Адрес, Семейное положение, Материальное положение, Род занятий, Откуда узнали, Примечание. Первичный ключ - Код клиента.

2) Сущность Контакты содержит атрибуты: Код контакта, Тип контакта, Контакт, Код клиента. Первичный ключ - Код контакта.

3) Сущность Типы контактов содержит атрибуты: Код типа контакта, Тип контакта. Первичный ключ - Код типа контакта.

4) Сущность Дисконтные карты содержит атрибуты: Номер дисконтной карты, Тип дисконтной карты, Код клиента. Первичный ключ - Номер дисконтной карты.

5) Сущность Типы дисконтных карт содержит атрибуты: Код типа дисконтной карты, Тип дисконтной карты. Первичный ключ - Код типа дисконтной карты.

6) Сущность Средства массовой информации (СМИ) содержит атрибуты: Код СМИ, Тип СМИ, Название СМИ, Код клиента. Первичный ключ - Код СМИ.

7) Сущность Тип СМИ содержит атрибуты: Код типа СМИ, Тип СМИ. Первичный ключ - Код типа СМИ.

8) Сущность Анкеты содержит атрибуты: Код анкеты, Тип вопроса, Ответ, Код клиента. Первичный ключ - Код Анкеты.

9) Сущность Тип вопроса содержит атрибуты: Код типа вопроса, Тип вопроса. Первичный ключ - Код типа вопроса.

10) Сущность Род занятий содержит атрибуты: Код рода занятия, Род занятий. Первичный ключ - Код рода занятия.

11) Сущность Источники знаний содержит атрибуты: Код источники знаний, Источники знаний. Первичный ключ - Код источники знаний.

12) Сущность Материальное положение содержит атрибуты: Код материального положения, Материальное положение. Первичный ключ - Код материального положения.

13) Сущность Регионы содержит атрибуты: Код региона, Регион, Страна. Первичный ключ - Код региона.

14) Сущность Продажи содержит атрибуты: Код продажи, Артикул, Дата продажи, Цена, Код клиента. Первичный ключ - Код продажи.

15) Сущность Товар содержит атрибуты: Артикул, Код фасона, Код модели, Код сезона, изображение. Первичный ключ - Артикул.

16) Сущность Фасоны содержит атрибуты: Код фасона, Фасон. Первичный ключ - Код фасона.

17) Сущность Модели содержит атрибуты: Код модели, Модель. Первичный ключ - Код фасона.

18) Сущность Сезоны содержит атрибуты: Код сезона, Сезон. Первичный ключ - Код сезона.

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

1) Связь Клиенты - Контакты. Получим отношение:

Рис. 2.18. Отношение Клиенты - Контакты

2) Связь Типы контактов - Контакты. Получим отношение:

Рис. 2.19. Отношение Типы контактов - Контакты

3) Связь Клиенты - Дисконтные карты. Получим отношение:

Рис. 2.20. Отношение Клиенты - Дисконтные карты

4) Связь Типы дисконтных карт - Дисконтные карты. Получим отношение:

Рис. 2.21. Отношение Типы дисконтных карт - Дисконтные карты

5) Связь Клиенты - СМИ. Получим отношение:

Рис. 2.22. Отношение Клиенты - СМИ

6) Связь Тип СМИ - СМИ. Получим отношение:

Рис. 2.23. Отношение Тип СМИ - СМИ

7) Связь Клиенты - Анкеты. Получим отношение:

Рис. 2.24. Отношение Клиенты - Анкеты

8) Связь Тип вопроса - Анкеты. Получим отношение:

Рис. 2.25. Отношение Тип вопроса - Анкеты

9) Связь Клиенты - Род занятий. Получим отношение:

Рис. 2.26. Отношение Клиенты - Род занятий

10) Связь Клиенты - Материальное положение. Получим отношение:

Рис. 2.27. Отношение Клиенты - Материальное положение

11) Связь Клиенты - Источник знаний. Получим отношение:

Рис. 2.28. Отношение Клиенты - Источник знаний

12) Связь Клиенты - Регионы. Получим отношение:

Рис. 2.29. Отношение Клиенты - Регионы

13) Связь Клиенты - Продажи. Получим отношение:

Рис. 2.30. Отношение Клиенты - Продажи

14) Связь Продажи - Товары. Получим отношение:

Рис. 2.31. Отношение Продажи - Товары

15) Связь Фасоны - Товары. Получим отношение:

Рис. 2.32. Отношение Фасоны - Товары

16) Связь Модели - Товары. Получим отношение:

Рис. 2.33. Отношение Модели - Товары

17) Связь Сезоны - Товары. Получим отношение:

Рис. 2.34. Отношение Сезоны - Товары

Различают несколько типов нормальных форм (НФ). Каждая из них ограничивает присутствие определенного класса функциональных зависимостей (ФЗ) в отношении.

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

Отношение находится в первой нормальной форме (1НФ), если все атрибуты отношения являются простыми (требование атомарности атрибутов в реляционной модели), т.е. не имеют компонентов. Иными словами, домен атрибута должен состоять из неделимых значений и не может включать в себя множество значений из более элементарных доменов. Каждый простой атрибут должен иметь свою колонку в таблице.

В проектируемой базе данных все таблицы (отношения) находятся в 1НФ, так как имеют ключевые поля, которые по определению являются уникальными индексами.

Отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и все неключевые атрибуты отношения функционально полно зависят от составного ключа отношения. Иными словами, 2НФ требует, чтобы отношение не содержало частичных ФЗ.

Все отношения (таблицы), первичный ключ которых не является составным, в рассматриваемой базе также находятся в 2НФ.

Отношение находится в третьей нормальной форме (3НФ), если оно находится во 2НФ, и все неключевые атрибуты отношения зависят только от первичного ключа. Иными словами, 3НФ требует, чтобы отношение не содержало транзитивных ФЗ неключевых атрибутов от ключа, т.е. отсутствуют ФЗ между неключевыми атрибутами.

Отношение находится в нормальной форме Бойса-Кодда (НФБК), если оно находится в 3НФ, и в нем отсутствуют зависимости ключевых атрибутов от неключевых атрибутов.

Проверим принадлежность каждого из отношений к НФБК.

1) Отношение «Clients»:

Рис. 2.35. Диаграмма функциональной зависимости «Clients»

2) Отношение «Contacts»:

Рис. 2.36. Диаграмма функциональной зависимости «Contacts»

3) Отношение «ContactType»:

Рис. 2.37. Диаграмма функциональной зависимости «ContactType»

4) Отношение «Discounts»:

Рис. 2.38. Диаграмма функциональной зависимости «Discounts»

5) Отношение «DiscountType»:

Рис. 2.39. Диаграмма функциональной зависимости «DiscountType»

6) Отношение «SMI»:

Рис. 2.40. Диаграмма функциональной зависимости «SMI»

7) Отношение «SMIType»:

Рис. 2.41. Диаграмма функциональной зависимости «SMIType»

8) Отношение «Blanks»:

Рис. 2.42. Диаграмма функциональной зависимости «Blanks»

9) Отношение «BlankType»:

Рис. 2.43. Диаграмма функциональной зависимости «BlankType»

10) Отношение «LifeStatus»:

Рис. 2.44. Диаграмма функциональной зависимости «LifeStatus»

11) Отношение «FamilyPosition»:

Рис. 2.45. Диаграмма функциональной зависимости «FamilyPosition»

12) Отношение «Knows»:

Рис. 2.46. Диаграмма функциональной зависимости «Knows»

13) Отношение «Regions»:

Рис. 2.47. Диаграмма функциональной зависимости «Regions»

14) Отношение «Sales»:

Рис. 2.48. Диаграмма функциональной зависимости «Sales»

15) Отношение «Article»:

Рис. 2.49. Диаграмма функциональной зависимости «Article»

16) Отношение «Fashion»:

Рис. 2.50. Диаграмма функциональной зависимости «Fashion»

17) Отношение «Model»:

Рис. 2.51. Диаграмма функциональной зависимости «Model»

18) Отношение «Season»:

Рис. 2.52. Диаграмма функциональной зависимости «Season»

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

Схема реализованной базы данных представлена в Приложении 3.

При разработке данной программной системы был обеспечен контроль целостности данных по 3-уровневой схеме:

1) Контроль целостности связи.

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

3) Уровень клиентского приложения. Перед вызовом хранимых процедур приложение самостоятельно проверяет семантику некоторых передаваемых параметров. И после проверки передает управление хранимым процедурам, которые в свою очередь возвращают коды ошибок в случае нарушения целостности базы данных.

Частные ограничения целостности данных приведены в таблице 2.1.

Таблица 2.1

Таблица	Атрибут	Ограничения целостности	Обязательное поле
Clients	IDClients FIO Sex BirthDate EMail City Region Address FamilyStatus FamilyPosition LifeStatus Know Node	INT, PRIMARY KEY, IDENTITY char(50) char(7) datetime char(30) char(30) int char(50) char(20) int int int char(100)	NOT NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL

Для ограничения целостности также были разработаны следующие хранимые процедуры:

1) sp_Add_Clients (@FIO (char(50)), @Sex (char(7)), @BirthDate (datetime), @EMail (char(30)), @City (char(30)), @Region (int), @Address (char(50)), @FamilyStatus (char(20)), @FamilyPosition (int), @Knows (int), @LifeStatus (int), @Node (char(100)), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о новых клиентах. Если введены некорректные данные, то процедура возвращает соответствующее значение параметра Returns, на основании которого пользователю будет выдано сообщение. Если данные корректны - запись будет добавлена.

2) sp_Add_Article (@Article (char(10)), @Fashion (int), @Model (int), @Season (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о новых товарах. Принцип действия аналогичен sp_Add_Clients.

3) sp_Add_Blanks (@BlankType (int), @Answer (char(45)), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации об ответах клиентов на вопросы анкет. Принцип действия аналогичен sp_Add_Clients.

4) sp_Add_Contact (@ContactType (int), @Contact (char(15)), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о контактах клиентов. Принцип действия аналогичен sp_Add_Clients.

5) sp_Add_Discount (@IDDiscount (int), @DiscountType (int), @DiscountSize (int), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о дисконтных картах клиента. Принцип действия аналогичен sp_Add_Clients.

6) sp_Add_Sales (@Article (char(10)), @Article (char(10)), @Price (int), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о новых продажах клиентам. Принцип действия аналогичен sp_Add_Clients.

7) sp_Add_SMI (@SMIType (int), @SMI (char(30)), @Client (int), Returns (int)). Процедура предназначена для проверки целостности данных при добавлении информации о предпочитаемых клиентами СМИ. Принцип действия аналогичен sp_Add_Clients.

8) sp_Update_Client (@ID(int), @FIO (char(50)), @Sex (char(7)), @BirthDate (datetime), @EMail (char(30)), @City (char(30)), @Region (int), @Address (char(50)), @FamilyStatus (char(20)), @FamilyPosition (int), @Knows (int), @LifeStatus (int), @Node (char(100)), Returns (int)). Процедура предназначена для проверки целостности данных при изменении информации о товарах. Если введены некорректные данные, то процедура возвращает соответствующее значение параметра Returns, на основании которого пользователю будет выдано сообщение. Если данные корректны - запись будет изменена.

9) sp_Update_Article (@Article (char(10)), @Fashion (int), @Model (int), @Season (int), Returns (int)). Процедура предназначена для проверки целостности данных при изменении информации о клиентах. Принцип действия аналогичен sp_Update_Client.

2.3 Разработка клиентской части ИС

Организация взаимодействия клиентской программы с БД

Приложение разрабатывалось в среде Borland Delphi 7.0. Взаимодействие с БД осуществляется с помощью следующих компонентов, входящих в стандартный набор этой системы:

1. ADO - Компоненты доступа к данным с помощью технологии ADO:

· tADOConnection - используется для указания базы данных и работы с транзакциями, обеспечивает расширенное управление соединением и позволяет обращаться к данным нескольким компонентам одновременно;

· tADOTable - обеспечивает использование в приложениях Delphi таблиц БД, подключенных через провайдеры OLE DB;

· tADOQuery - обеспечивает применение запросов SQL при работе с данными через ADO. Это может быть как запрос, в результате которого возвращаются данные и базы (например, SELECT), так и запрос, не возвращающий данных (например, INSERT).

2. Data Controls - Визуальные компоненты представления данных:

· tDBGrid - компонент инкапсулирует двумерную таблицу, в которой строки представляют собой записи, а столбцы - поля набора данных;

· tDBEdit - стандартный однострочный текстовый редактор, в котором отображаются и изменяются данные из поля связанного набора данных;

· tDBComboBox - отображает текущее значение связанного с ним поля набора данных и позволяет изменить его на любое фиксированное из списка;

· tDBMemo - представляет собой обычное поле редактирования, к которому подключается поле с типом данных Memo. Основное преимущество компонента - возможность одновременного просмотра и редактирования нескольких строк переменной длины;

· tDBImage - Компонент предназначен для просмотра изображений, хранящихся в базах данных в графическом формате;

· tDBLookupComboBox - представляет собой комбинированный список значений поля синхронного просмотра для поля, заданного свойством DataField, из набора данных DataSource. Его основное назначение - автоматически устанавливать соответствие между полями двух наборов данных по одинаковому значению заданного поля исходной таблицы и ключевого поля таблицы синхронного просмотра. В списке синхронного просмотра отображаются возможные значения для редактирования поля основной таблицы;

· tDBChart - предназначен для представления данных из некоторого набора данных в виде графиков различных видов.

3. Data Access - Компоненты доступа к данным. Включает в себя невизуальные компоненты, предназначенные для доступа к данным и являющиеся общими для всех технологий (tDataSourse ).

4. Quick Reports - Визуальные компоненты для формирования отчетов по БД (tQuickRep, tQRlabel, tQRDBText).

В проект добавлен модуль данных (Data Module) (рис. 3.17). Модуль данных - это не визуальный контейнер для размещения на нем не визуальных компонентов подключения к данным (ADOConnection), компонентов - наборов данных (ADOTable, ADOQuery) и компонентов DataSource, которые обеспечивают связь наборов данных и компонентов отображения / редактирования данных. Модуль данных не имеет формы, но сохраняется как модуль в файле *.pas.

Рис. 2.53. Окно модуля данных (Data Module)

Разработка интерфейса пользователя

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

Проект содержит следующие формы:

fMain - главная форма приложения. Основные данные для работы менеджера отображаются с помощью компонента DBGrid, связанного с компонентом ADOQuery - qMain. При первом запуске приложения свойство qMain. Sql содержит следующий текст запроса:

SELECT Clients.IDClients. Clients.FIO, Clients. Sex, Clients. BirthDate,

Clients.EMail, Clients. City, Regions. Region, Clients. Address,

FamilyPosition. FamilyPosition, Clients. FamilyStatus, Knows. Knows,

LifeStatus. LifeStatus, Clients. Node

FROM Clients INNER JOIN FamilyPosition ON Clients. FamilyPosition =

FamilyPosition.IDFamilyPosition INNER JOIN Knows ON Clients. Know =

Knows.IDKnows INNER JOIN LifeStatus ON Clients. LifeStatus =

LifeStatus.IDLifeStatus INNER JOIN Regions ON Clients. Region =

Regions.IDRegion

Дополнительные данные отображаются в виде таблиц, расположенных на пяти вкладках справа от основной таблицы: контакты, покупки, дисконтные карты, СМИ, анкеты, содержащих информацию из соответствующих таблиц (рис. 2.54).

Рис. 2.54. Окно главной формы проекта

Сверху над основной таблицей расположены кнопки управления, которые дублируются в главном и контекстном меню:

1) sbtAddClients - кнопка, при нажатии на которую открывается форма «Редактирование клиента» (fEdit) на добавление информации;

2) sbtEditClients - кнопка, при нажатии на которую открывается форма «Редактирование клиента» (fEdit) на изменение информации;

3) sbtVisible - кнопка, при нажатии на которую открывается форма «Видимые поля» (fvisible) - форма выбора видимых полей для таблицы на главной форме (рис. 2.55);

Рис. 2.55. Окно формы «Видимые поля»

4) sbtFilter - кнопка, при нажатии на которую открывается форма «Фильтр» (fFilter) (рис. 2.56) - форма выбора фильтров и значений для таблицы на главной форме. Фильтрация записей производится с помощью свойства компонента ADOQuery. Filter;

Рис. 2.56. Окно формы «Фильтр»

5) sbtPrintPreview - кнопка, при нажатии на которую открывается форма отчета «Анкета покупателя» (fReportBlank).

6) sbtSendMail - кнопка, при нажатии на которую открывается форма «Отправить письмо» (fSendMail) - форма для отправки писем конкретным покупателям через учетную запись MS Outlook (рис. 2.57).

Рис. 2.57. Окно формы «Отправить письмо»

Работа с почтовой программой Outlook организована с помощью автоматизации OLE. Это реализовано следующим кодом:

uses ComObj;

var Outlook: OleVariant;

Letter: OleVariant;

…

Outlook:= CreateOleObject ('Outlook. Application');

Далее использованы объекты, содержащиеся в Outlook. Application, их свойства и методы, например:

· Letter. Recipients;

· Letter. Subject;

· Letter. Body;

· Letter. Attachments;

· Letter. Send.

7) sbtExpExcel - кнопка, при нажатии на которую открывается производится экспорт данных из главной таблицы формы в приложение Microsoft Excel;

8) sbtExit - кнопка, при нажатии на которую осуществляется выход из приложения.

fEditor - форма «Редактирование клиента» предназначена для добавления и редактирования информации о клиентах (рис. 3.58).

Содержит компонент Panel, с расположенными на нем визуальными компонентами представления данных (Edit и ComboBox), связанными с таблицей Clients, и компонент PageControl, содержащий пять вкладок для представления данных о клиентах из связанных таблиц: Contacts, Discounts, Sales, SMI, Blanks. На каждой вкладке расположена кнопка Добавить для множественного добавления данных в связанные таблицы, с помощью соответствующих хранимых процедур.

Рис. 2.58. Окно формы добавления и редактирования данных

Внизу основной панели расположены две кнопки «Добавить» и «Сохранить изменения», видимость которых определяется в зависимости от способа запуска формы (на добавление или редактирование). При нажатии на кнопку «Добавить» запускается хранимая процедура sp_Add_Client. При нажатии на кнопку «Сохранить» запускается хранимая процедура sp_Update_Client.

Добавления данных в таблицы на страницах компонента PageControl осуществляется с помощью соответствующих хранимых процедур при нажатии на кнопки «Добавить» на каждой странице. Листинг модуля формы fEdit представлен в Приложении.

Справа от компонентов ComboBox расположены кнопки , при нажатии на которые открывается окно формы «Редактирование справочников» (fEditType), содержащее информацию из соответствующей таблицы (рис. 2.59).

Рис. 2.59. Окно формы добавления и редактирования данных

Для добавления и редактирования записей в справочниках использованы стандартные методы таблицы ADOTable:

· Edit - переключает таблицу в режим редактирования.

· Post - сохраняет результаты редактирования в таблицу.

· Insert - вставляет новую строку в месте указателя, и включает режим редактирования.

· Append - вставляет пустую строку в конец таблицы, переводит указатель на нее и включает режим редактирования.

· Cancel - отменяет внесенные, но не зафиксированные изменения, и отключает режим редактирования.

fEditArticles - форма для добавления и редактирования информации в справочник «Товары» (рис. 3.60). При нажатии на кнопку «Добавить» запускается хранимая процедура sp_Add_Article. При нажатии на кнопку «Сохранить» запускается хранимая процедура sp_Update_Article. При нажатии на кнопку «Изменить» визуальные компоненты представления данных (Edit и ComboBox) заполняются данными выделенной в таблице записи.

Рис. 2.60. Окно формы «Справочник Товары»

fBirthDate - форма для массовых именных рассылок поздравлений с Днем рождения (рис. 2.61). Листинг модуля формы fBirthDate представлен в Приложении.

Рис. 2.61. Окно формы «Поздравить с Днем рождения»

На форме использованы компоненты библиотеки Internet Direct (Indy):

· tIDSMTP - Клиентский компонент, предназначенный для применения в приложениях протокола SMTP (Simple Mail Transfer Protocol), обеспечения поддержки аутентификации, а также для поддержки многобайтных символов;

· tIDMessage - Компонент используется в комбинации с другими компонентами, чтобы должным образом расшифровать или кодировать сообщения. Это могут быть POP-, SMTP- и NNTP-компоненты.

При выборе одного из пунктов компонента RadioGroup в таблице «Кому» отобразятся только записи удовлетворяющие запросу. При нажатии на кнопку «Отправить» всем клиентам из этой таблицы будут оправлены письма с параметрами указанными в соответствующих компонентах Edit. Вложение выбирается с помощью компонента OpenDialog.

Разработка отчетов

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

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

...