57
авторизация пользователя в системе с назначением ему соответствующих
прав и компоновки его рабочего стола (клиентская база, личная
статистика, запланированные контакты, напоминания и выполнение
задач);
подключение и взаимодействие с записями базы данных (запросы на
выборку и управляющие запросы);
завершение работы системы.
На рисунке 18 приведены сценарии диалога пользователя с CRM-
системой для всех типов пользователей.
Авторизация Подключение к БД Завершение работы
Меню топ-менеджера
Меню менеджера
Рабочий стол
Менеджеры
Организации
Все клиенты
Контакты
Задачи
Менеджеры
Организации
Все клиенты
Сегментация
клиентской
базы
МЕНЮ КОМАНД
Заметки
Задачи
Мои клиенты
По отраслям
По
менеджерам
По городам
Воронка
продаж
Воронка
продаж
Рисунок 18 – Сценарий диалогаCRM-системы
2.3.2. Характеристика базы данных
База данных проектируемой системы на этапе ее базисного
инжиниринга представляет собой концептуальную модель данных, в которой
определены основные ее информационные объекты, их атрибуты с указанием
ключевых, а также связи между ними. По результатам этой модели строится
информационно-логическая модель данных.
В таблице 6 приведена спецификация сущностей и атрибутов
информационно-логической модели данных CRM-системы.
Таблица 6
Спецификация инфологической модели данных
Сущность
Атрибут
Ключ
Описание
Client – сущность
клиента –
формирует
клиентскую базу
cliID
PK
Идентификатор
cliFurname
Фамилия
cliFirstName
Имя
cliSecondName
Отчество
cliSex
Пол
cliEmail
Адрес эл
ектронной
почты
cliJobPhone
Рабочий телефон
cliMobilePhone
Мобильный телефон
cliSkype
Скайп
cliBirthDate
Дата рождения
cliOrganizationID
FK
Организация, в которой
работает
cliManagerID
FK
Курирующий менеджер
cliPost
Должность клиента
cliStatusID
FK
Статус клиента
cliAgreementExpiredDate
Срок окончания договора
Manager –
базовые данные
учетной записи
менеджера
mgrID
PK
Идентификатор
mgrFurname
Фамилия
mgrFirstName
Имя
mgrSecondName
Отчество
mgrPost
Должность
UserAccount –
учетная запись
usrLogin
Логин
usrPassword
Пароль
59
менеджера
–
регистрационные
данные
usrAccess
Идентификатор прав
доступа
usrManagerID
PK
,
FK
Менеджер обладатель
учетной записи
Contacts – хранит
в системе
запланированные
контакты
менеджеров
cntID
PK
Идентификатор
cntClientID
FK
Клиент
cntManagerID
FK
Менеджер
cntTitle
Заголовок
cntContent
Содержание
cntDate
Дата контакта
cntResult
Результат
Organization –
справочник
организаций
клиентской базы
orgID
PK
Идентификатор
orgName
Наименование
orgFullName
Полное наименование
orgAddress
Адрес
orgPhone
Телефон
orgCity
Город
orgIndustry
Отрасль
Продолжение таблицы 6
Спецификация инфологической модели данных
Сущность
Атрибут
Ключ
Описание
Task – учет
задач
менеджеров
tskID
PK
Идентификатор
tskTitle
Заголовок
tskContent
Содержание
tskNote
Необязательный
комментарий к задаче
tskForAll
Флаг, означающий, что
задача была создана для
всех менеджеров
tskCreatorManagerID
FK
Менеджер, который создал
задачу
tskReceiverManagerID
FK
Менеджер, указанный как
получатель задачи
tskCreateDate
Дата создания задачи
создателем
tskApplyDate
Дата подтверждения задачи
получателем
tskCompleteDate
Дата завершения
выполнения задачи
tskDeadLine
Дата, установленная как
срок исполнения задачи
менеджером создателем
Status –
справочник
stsID
PK
Идентификатор
stsName
Наименование
60
статусов
клиентов
stsColor
Цветовой код статуса для
отображения в системе
Note – учет
личных заметок
для
организации
системы
органайзера
менеджеров
nteID
PK
Идентификатор
nteDate
Дата создания
nteContent
Содержание
nteCaption
Заголовок
nteManagerID
FK
Менеджер, который создал
заметку в органайзере
nteShow
Флаг, определяющий, надо
ли показывать на рабочем
столе менеджера
nteToTask
Флаг, определяющий, надо
ли создать задачу на базе
текущей заметки
nteTaskDate
Дата создания задачи (если
был установлен флаг
nteToTask)
На рисунке 19 приведена диаграмма информационно-логической
модели данных CR-системы.
Рисунок 19 –
Инфологическая модель данных
На этапе рабочего проектирования
модель данных преобразуется в модель данных, соответствующих
физическому хранению данных в таблицах БД. При этом все сущности
становятся таблицами в БД, а их атрибуты
ук
азываются его спецификации
поддерживаемый выбранной СУБД (в данном случае
(например, требования к обязательному заполнению).
Инфологическая модель данных
На этапе рабочего проектирования
системы построенная базисная
модель данных преобразуется в модель данных, соответствующих
физическому хранению данных в таблицах БД. При этом все сущности
становятся таблицами в БД, а их атрибуты
–
полями. Для каждого атрибута
азываются его спецификации
физического уровня: тип данных,
поддерживаемый выбранной СУБД (в данном случае
–
MySQL
(например, требования к обязательному заполнению).
61
Инфологическая модель данных
CRM-системы
системы построенная базисная
модель данных преобразуется в модель данных, соответствующих
физическому хранению данных в таблицах БД. При этом все сущности
полями. Для каждого атрибута
физического уровня: тип данных,
MySQL
), ограничения
62
В таблице 7 приведена спецификация таблиц и полей физической
модели базы данных CRM-системы.
Таблица 7
Спецификация физической модели данных
Таблица
Атрибут
Обязательный
Тип данных
Client
cliID
Да
INTEGER
cliFurname
Да
VARCHAR(50)
cliFirstName
Да
VARCHAR(50)
cliSecondName
Да
VARCHAR(50)
cliSex
Да
VARCHAR(6)
cliEmail
-
VARCHAR(50)
cliJobPhone
-
VARCHAR(15)
cliMobilePhone
-
VARCHAR(15)
cliSkype
-
VARCHAR(30)
cliBirthDate
-
DATETIME
cliOrganizationID
Да
INTEGER
cliManagerID
Да
INTEGER
cliPost
Да
VARCHAR(100)
cliStatusID
Да
INTEGER
cliAgreementExpiredDate
-
DATETIME
Status
stsID
Да
INTEGER
stsName
Да
VARCHAR(50)
stsColor
Да
VARCHAR(15)
Manager
mgrID
Да
INTEGER
mgrFurname
Да
VARCHAR(50)
mgrFirstName
Да
VARCHAR(50)
mgrSecondName
Да
VARCHAR(50)
mgrPost
Да
VARCHAR(50)
UserAccount
usrLogin
Да
VARCHAR(10)
usrPassword
Да
VARCHAR(10)
usrAccess
Да
INTEGER
usrManagerID
Да
INTEGER
Contacts
cntID
Да
INTEGER
cntClientID
Да
INTEGER
cntManagerID
Да
INTEGER
cntTitle
Да
VARCHAR(100)
cntContent
-
VARCHAR(255)
cntDate
Да
DATETIME
cntResult
-
VARCHAR(255)
Продолжение таблицы 7
Спецификация физической модели данных
63
Таблица
Атрибут
Обязательный
Тип данных
Organization
orgID
Да
INTEGER
orgName
Да
VARCHAR(50)
orgFullName
-
VARCHAR(150)
orgAddress
-
VARCHAR(50)
orgPhone
-
VARCHAR(50)
orgCity
Да
VARCHAR(50)
orgIndustry
Да
VARCHAR(50)
Task
tskID
Да
INTEGER
tskTitle
Да
VARCHAR(20)
tskContent
-
VARCHAR(255)
tskNote
-
VARCHAR(255)
tskForAll
-
BOOLEAN
tskCreatorManagerID
Да
INTEGER
tskReceiverManagerID
Да
INTEGER
tskCreateDate
Да
DATETIME
tskApplyDate
-
DATETIME
tskCompleteDate
-
DATETIME
tskDeadLine
-
DATETIME
Note
nteID
Да
INTEGER
nteDate
Да
DATETIME
nteContent
Да
VARCHAR(255)
nteCaption
Да
VARCHAR(20)
nteManagerID
Да
INTEGER
nteShow
Да
BOOLEAN
nteToTask
Да
BOOLEAN
nteTaskDate
-
DATETIME
Приведеннаяв таблице 7 физическая спецификация базы данных
системы переносится в среду проектирования (в данной работе используется
StarUMLверсии 3.1), в которой можно получить диаграмму физической
модели базы данных. Данная диаграмма приведена на рисунке 20. Система
StarUML позволяет в автоматическом режиме сформировать исходный ко
(скрипт) формирования физической структуры базы данных на языке
описания данных (DDL, Data Description Language). Данный скрипт
запускается в любом менеджере СУБД на выполнение, в результате чего
создается вся система физических таблиц, полей с ограничениями и связей
между ними. Текст автоматически созданного в StarUMLDDL-скрипта
формирования базы данных CRM-системы приведен в Приложении 1.
Рисунок 20
–
Реализация целостности данных осуществляется средствами
выбранной СУБД за счет
таблицах [21
]. При автоматизированном проектировании БД схема
обеспечения целостности данных может быть настроена средствами
системой StarUML
, в которой разработана физическая модель данных, и
экспортирована в сгенерированный файл скрипта создания физическ
структуры БД.
Другой аспект обеспечения целостности данных реализуется в самом
приложении верхнего уровня
–
Физическая модель данных
CRM
Реализация целостности данных осуществляется средствами
выбранной СУБД за счет
каскадного обновления и удаления записей в
]. При автоматизированном проектировании БД схема
обеспечения целостности данных может быть настроена средствами
, в которой разработана физическая модель данных, и
экспортирована в сгенерированный файл скрипта создания физическ
Другой аспект обеспечения целостности данных реализуется в самом
приложении верхнего уровня
и представляет собой:
64
CRM
-системы
Реализация целостности данных осуществляется средствами
каскадного обновления и удаления записей в
]. При автоматизированном проектировании БД схема
обеспечения целостности данных может быть настроена средствами
, в которой разработана физическая модель данных, и
экспортирована в сгенерированный файл скрипта создания физическ
ой
Другой аспект обеспечения целостности данных реализуется в самом
65
контроль корректности вводимых данных (принадлежность к типам
данных);
контроль полноты заполнения данных – проверка на наличие
обязательных параметров;
контроль логической целостности данных (например, запрет ввода
отрицательны значений или ввод противоречивых значений).
Дополнительная функциональность приложения за счет средств СУБД
может быть обеспечена с помощью представлений (запросов). Представления
БД – это логические таблицы данных, представляющие собой
поименованный запрос. В отличии от таблиц, представления не являются
самостоятельной единицей БД, но являются динамически вычисленными и
сгруппированными данными из реальных таблиц в соответствии с
запрашиваемыми условиями. Любое изменение в таблице данных
незамедлительно отображается и в соответствующих представлениях,
использующих эту таблицу [7].
Основное назначение представлений – собрать и вывести выборку
данных из одной или нескольких таблиц в соответствии с заданными
условиями.
Дополнительная функциональность системы также реализуется
посредством триггеров, реализованных в СУБД. Триггеры позволяют
упростить логику приложения и повысить производительность, поскольку
избавляют от необходимости обмениваться данными по сети [25].
В проектируемой CRM-системе триггеры применяются для
идентификации события создания автоматической задачи менеджеру:
происходит реакция БД на изменение базовых данных клиента (места
работы, занимаемой должности). Триггер отслеживает изменения данных
клиента, находит курирующего этого клиента менеджера, и создает этому
менеджеру автоматическую задачу реагирования. Преимущество
использования триггера для этой функции очевидно, поскольку снимается
дополнительная нагрузка по сетевому обмену на приложение, сокращается
программный код. Кроме того, триггер сработает всегда, независимо от того,
в какой подсистеме была выполнена операция изменения данных клиента.
Без использования триггера пришлось
кода два раза –
в подсистему управления «мои клиенты» менеджера и в
подсистему управления «все клиенты» топ
приведен программный код данного триггера на языке
Рисунок 21 –
Новый триггер на
дополнительная нагрузка по сетевому обмену на приложение, сокращается
программный код. Кроме того, триггер сработает всегда, независимо от того,
в какой подсистеме была выполнена операция изменения данных клиента.
Без использования триггера пришлось
бы вставлять фрагмент программного
в подсистему управления «мои клиенты» менеджера и в
подсистему управления «все клиенты» топ
-
менеджера. На рисунке
приведен программный код данного триггера на языке
SQL
Новый триггер на
обновление данных клиента
66
дополнительная нагрузка по сетевому обмену на приложение, сокращается
программный код. Кроме того, триггер сработает всегда, независимо от того,
в какой подсистеме была выполнена операция изменения данных клиента.
бы вставлять фрагмент программного
в подсистему управления «мои клиенты» менеджера и в
менеджера. На рисунке
21
SQL
.
обновление данных клиента