Автоматизация процессов, происходящих в отделе прямых продаж ОАО ОТПбанк

.3 Подготовка отчётов по модели средствами Report Builder

Для анализа построенной модели следует документировать все ее компоненты. Для этого в AllFusion Erwin Data Modeler 4.1.4 используется функция построителя отчетов. Для того, чтобы вызвать мастера построителя отчётов выберем в меню пункт Tools / Report Builder.

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

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

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

Окно мастера построения отчётов:

Аналогично создаются другие секции отчёта.

После создания всех необходимых секций и задания их параметров в меню мастера построения отчётов выбирается пункт File / Run. В результате будет создан отчёт:

Титульная страница:

Описание сущностей в отчёте:

Описание атрибутов в отчёте выглядит следующим образом:

III. Построение нормализованной (до 3 НФ) реляционной модели предметной области

. Трансформация концептуальной модели данных в реляционную модель

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

Необходимо сделать одно замечание: реляционная модель данных представляет собой совокупность таблиц, связанных между собой посредством ссылок - внешних ключей, в этой связи поддержка типа связи «многие-ко-многим» представляется весьма проблематичной. Можно предложить следующее решение данной проблемы:. По правилам поддерживаемой нотации только на уровне концептуальной модели воз-можно сохранить множественные связи для точного отражения семантики предметной области.. На уровне физической, в нашем случае реляционной модели, создать дополнительную таблицу, связанную с родительскими таблицами связью типа «1 :М».. В том случае, когда множественная связь логического уровня имеет атрибуты, важные для понимания семантики предметной области, можно воспользоваться мастером трансформации (Show Association Entity), создающем дополнительную таблицу с набором внешних ключей и возможностью определения произвольного число атрибутов связи на логическом уровне представления модели.

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

Реляционная модель данных может быть представлена в виде совокупности таблиц:

Специалист отдела прямых продаж (Код специалиста прямых продаж, …)

Пакет документов (Шифр пакета, Код специалиста прямых продаж, …)

Заявление на выпуск кредитной карты (Номер заявления, Код специалиста кредитного отдела…)

Специалист кредитного отдела (Код специалиста кредитного отдела, …)

План на месяц (Название месяца, Код специалиста прямых продаж, …)

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

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

Трансформация концептуальной модели данных в реляционную модель (для случая использования CASE-средства).

.Создание системы индексов

IV. Оценка (количественная) проектируемой базы данных

Для оценки возможностей выбираемой СУБД по эффективному управлению данными, определению оптимальных характеристик аппаратной платформы, поддерживающей проектируемую систему баз данных, могут быть рассчитаны размеры физических объектов базы данных через заданный промежуток времени после начала ее эксплуатации. Эта задача решается с помощью ERWin, в котором выбирается диалог Volumetrics (Tools / Volumetrics).

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

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

начальное количество строк реляционных таблиц;

максимально возможное количество строк;

планируемый рост числа строк в месяц.

Параметры, задаваемые для отдельных атрибутов таблицы:

длина поля (для тех типов данных, где выполнение той функции возможно);

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

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

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

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

V. Построение схемы базы данных в СУБД MS Access 2000, используя процедуру прямого проектирования в AllFusio ERwin Data Modeler 4.1.4

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

В этой связи, применение САSЕ-средств позволяет, указав наименование выбранной СУБД, сгенерировать системный каталог базы данных в конкретной среде и подготовить «поле» для работы программистов, которые будут осуществлять разработку приложений и пользовательских запросов к базе данных. Эта процедура носит название прямого проектирования (Forward Engineer / Shema Generation) и выполняется только на физическом уровне. Для осуществление этой процедуры необходимо:

создать в выбранной СУБД пустую базу данных;

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

выбрать базовую СУБД - Database / Choose Database,

- указать на выполнение процедуры прямого проектирования - Тооls / Forward Engineer / Shema Generation;

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

выбрать опцию Generate, где User Name - admin, Database - адрес пустой базы данных;

указать операцию Connect,

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

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

Ниже приведены окна генерирования модели данных и схема данных, созданная в приложении Access.

Окно установления параметров:

Окно завершения генерирования:

Структура базы данных, полученная методом прямого проектирования и схема данных в приложении MS

VI. Формулировка запросов к базе данных в рамках выделенных функций предметной области

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

Для создания запросов на добавление/удаление/обновление используется конструктор запросов. Сначала добавляем нужную таблицу:

Выбираем в главном верхнем меню «Запрос - Добавление», «Удаление» или «Обновление» в зависимости от типа запроса, который делаем.

Запрос 1. На добавление

Указываем поочерёдно поля таблицы для добавления и к каждому полю записываем в квадратных скобках сообщение, которое будет видеть пользователь при добавлении данных, например запрос для таблицы 1 будет выглядеть в режиме конструктора следующим образом:

В режиме SQL запрос будет записан следующим образом:

INSERT INTO [1- СОП] ( TabSOP, FioSOP, Pasp, Tel, Adr, RabDen, Okl, BonSer, BonZol )

SELECT

[Введите табельный номе сотрудника отделка продаж] AS Выражение1,

[Введите ФИО] AS Выражение2,

[Введите паспортные данные] AS Выражение3,

[Введите телефон] AS Выражение4,

[Введите адрес] AS Выражение5,

[Введите продолжительность рабочего дня, в часах] AS Выражение6,

[Введите оклад] AS Выражение7,

[Введите бонус за серебряную карту] AS Выражение8,

[Введите бонус за золотую карту] AS Выражение9[1- СОП];

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

И т.д. у пользователя спрашиваются значения для всех полей таблицы.

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

Для добавления записи не обращаем внимания на данное сообщение и нажимаем ДА.

В результате в таблицу 1 добавляется новая запись:

Запрос 2. На обновление

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

В режиме конструктора запрос выглядит так:

В режиме SQL будет записано:[1- СОП] SET

[1- СОП].TabSOP = [Введите табельный номер сотрудника отдела продаж, по которому надо изменить данные],

[1- СОП].FioSOP = [Введите фамилию], [1- СОП].Pasp = [Введите паспортные данные],

[1- СОП].Tel = [Введите телефон],

[1- СОП].Adr = [Введите адрес],

[1- СОП].RabDen = [Введите длительность рабочего дня, в часах],

[1- СОП].Okl = [Введите оклад],

[1- СОП].BonSer = [Введите бонус за серебряную карту],

[1- СОП].BonZol = [Введите бонус за золотую карту];

Результат выполнения запроса:

Предположим, сотрудник Абрамцева вышла замуж и поменяла фамилию на Сальникова.

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

Запрос 3. На удаление

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

В режиме SQL будет записано:

DELETE [1- СОП].TabSOP[1- СОП]

WHERE ((([1- СОП].TabSOP)=[Введите табельный номер сотрудника отдела продаж, по которому необходимо удалить данные]));

Результат выполнения запроса:

Результат - Сальникова удалена из базы данных сотрудников отдела продаж.

Аналогично можно было сделать удаление записи по ФИО.

Запрос 4. Процент одобрения

Создаём два вспомогательных запроса:

.1. Сперва запрос, считающий кол-во одобренных заявлений:

Запрос в режиме конструктора:

Режим SQL:[1- СОП].TabSOP, [1- СОП].FioSOP, Count([4- Заявление].NomZ) AS [Кол-во одобренных заявлений]([1- СОП] INNER JOIN [3- Пакет] ON [1- СОП].TabSOP=[3- Пакет].TabSOP) INNER JOIN [4- Заявление] ON [3- Пакет].ShifrPak=[4- Заявление].ShifrPakBY [1- СОП].TabSOP, [1- СОП].FioSOP, [4- Заявление].Odobr((([4- Заявление].Odobr)="Да"));

Результаты выполнения запроса:

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

Запрос в режиме конструктора:

Режим SQL:[1- СОП].TabSOP, [1- СОП].FioSOP, Sum([3- Пакет].KolZ) AS [Всего сдано заявлений], Sum([Вспомогательный запрос: Кол-во одобренных заявлений по СОП].[Кол-во одобренных заявлений]) AS [Всего одобренных заявлений](([1- СОП] INNER JOIN [Вспомогательный запрос: Кол-во одобренных заявлений по СОП] ON [1- СОП].TabSOP=[Вспомогательный запрос: Кол-во одобренных заявлений по СОП].TabSOP) INNER JOIN [3- Пакет] ON [1- СОП].TabSOP=[3- Пакет].TabSOP) INNER JOIN [4- Заявление] ON [3- Пакет].ShifrPak=[4- Заявление].ShifrPak

GROUP BY [1- СОП].TabSOP, [1- СОП].FioSOP;

Результаты выполнения запроса:

Запрос в режиме конструктора:

Строим выражение «процент одобрения»:

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

Режим SQL:[Кол-во сданных и одобренных заявлений по СОП].TabSOP, [Кол-во сданных и одобренных заявлений по СОП].FioSOP, [Кол-во сданных и одобренных заявлений по СОП].[Всего сдано заявлений], [Кол-во сданных и одобренных заявлений по СОП].[Всего одобренных заявлений], [Кол-во сданных и одобренных заявлений по СОП]![Всего одобренных заявлений]/[Кол-во сданных и одобренных заявлений по СОП]![Всего сдано заявлений] AS [Процент одобренных заявлений][Кол-во сданных и одобренных заявлений по СОП];

Результаты выполнения запроса:

Запрос 5. Заработная плата СОП

Создаём три вспомогательных запроса:

.1. Запрос, определяющий, какие карты были выданы в данном месяце.

Например, построим запрос для января, тогда в последнем поле «номер месяца», ставим условие отбора =”1”, при необходимости посчитать заработную плату за февраль, будем менять условие на номер месяца =”2” и т.д.

Запрос в режиме конструктора:

Режим SQL:[1- СОП].TabSOP, [4- Заявление].NomZ, [6- Кредитная карта].Vid, Month([3- Пакет]!Data) AS [Номер месяца]([5- Клиент] INNER JOIN (([1- СОП] INNER JOIN [3- Пакет] ON [1- СОП].TabSOP = [3- Пакет].TabSOP) INNER JOIN [4- Заявление] ON [3- Пакет].ShifrPak = [4- Заявление].ShifrPak) ON [5- Клиент].KodKlient = [4- Заявление].KodKlient) INNER JOIN [6- Кредитная карта] ON [5- Клиент].KodKlient = [6- Кредитная карта].KodKlient(((Month([3- Пакет]![Data]))="1"));

Результаты выполнения запроса:

.2 и 2.3. Вспомогательные запросы, считающие кол-во золотых и серебряных карт по месяцу, выбранному в запросе 2.1. Созданы на базе результатов запроса 2.1.

Запросы в режиме конструктора:

Режим SQL:[21- Вспомогательный: карты, выданные в январе].TabSOP, Count([21- Вспомогательный: карты, выданные в январе].NomZ) AS [Кол-во золотых карт по заявлениям от данного сотрудника][21- Вспомогательный: карты, выданные в январе]BY [21- Вспомогательный: карты, выданные в январе].TabSOP, [21- Вспомогательный: карты, выданные в январе].Vid((([21- Вспомогательный: карты, выданные в январе].Vid)="Золотая"));[21- Вспомогательный: карты, выданные в январе].TabSOP, Count([21- Вспомогательный: карты, выданные в январе].NomZ) AS [Кол-во серебряных карт по заявлениям от данного сотрудника][21- Вспомогательный: карты, выданные в январе]BY [21- Вспомогательный: карты, выданные в январе].TabSOP, [21- Вспомогательный: карты, выданные в январе].Vid((([21- Вспомогательный: карты, выданные в январе].Vid)="Серебряная"));

Результаты выполнения запросов:

Наконец создаём окончательный запрос, использующий результаты запросов 2.2 и 2.3

Запрос в режиме конструктора:

Вычисление заработной платы в построителе выражений по формуле:

Оклад + Бонус за одобрение серебряной карты * Кол-во серебряных карт + Бонус за одобрение золотой карты * Кол-во золотых карт:

Режим SQL:[1- СОП].TabSOP, [1- СОП].FioSOP, [1- СОП]!Okl+[1- СОП]!BonSer*[23- Вспомогательный: Кол-во серебряных в январе по СОП]![Кол-во серебряных карт по заявлениям от данного сотрудника]+[1- СОП]!BonZol*[22- Вспомогательный: Кол-во золотых в январе по СОП]![Кол-во золотых карт по заявлениям от данного сотрудника] AS [Заработная плата сотрудника, руб]([1- СОП] INNER JOIN [22- Вспомогательный: Кол-во золотых в январе по СОП] ON [1- СОП].TabSOP=[22- Вспомогательный: Кол-во золотых в январе по СОП].TabSOP) INNER JOIN [23- Вспомогательный: Кол-во серебряных в январе по СОП] ON [1- СОП].TabSOP=[23- Вспомогательный: Кол-во серебряных в январе по СОП].TabSOP;

Результаты выполнения запроса:

Запрос 6. Получил ли конкретный клиент карту?

Запрос в режиме конструктора:

Режим SQL:[5- Клиент].FioKlient, [4- Заявление].Odobr[5- Клиент] INNER JOIN [4- Заявление] ON [5- Клиент].KodKlient=[4- Заявление].KodKlient((([5- Клиент].FioKlient)=[Введите ФИО клиента]));

Результаты выполнения запроса:

Запрос 7. Список клиентов, получивших карты

Запрос в режиме конструктора:

Режим SQL:[5- Клиент].FioKlient, [6- Кредитная карта].NomKart, [6- Кредитная карта].Vid, [6- Кредитная карта].Srok, [6- Кредитная карта].Stavka[5- Клиент] INNER JOIN [6- Кредитная карта] ON [5- Клиент].KodKlient = [6- Кредитная карта].KodKlient;

Результаты выполнения запроса:

Запрос 8. Привязка клиентов к СОП

Запрос в режиме конструктора:

Режим SQL:[5- Клиент].KodKlient, [5- Клиент].FioKlient, [1- СОП].TabSOP, [1- СОП].FioSOP[5- Клиент] INNER JOIN (([1- СОП] INNER JOIN [3- Пакет] ON [1- СОП].TabSOP = [3- Пакет].TabSOP) INNER JOIN [4- Заявление] ON [3- Пакет].ShifrPak = [4- Заявление].ShifrPak) ON [5- Клиент].KodKlient = [4- Заявление].KodKlient((([3- Пакет].ShifrPak)=[4- Заявление]![ShifrPak]));

Результаты выполнения запроса:

Запрос 9. Внесение сведений об одобрении заявлений и комментариев к ним

В данном случае используется принцип построения запроса на обновление записи:

Запрос в режиме конструктора:

Режим SQL:[4- Заявление] SET [4- Заявление].NomZ = [Введите номер заявления для внесения сведений об одобрении], [4- Заявление].Odobr = [Введите статус одобрения Да/Нет], [4- Заявление].KomZ = [Комментарий (необязательное поле)];

Результаты выполнения запроса:

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

Вид таблицы до выполнения запроса:

Выполнение запроса:

Таблица после добавления сведений:

VII Формирование отчетов

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

В рамках курсового проекта используются стандартные возможности MS Access по формированию отчетов на основе запросов пользователя, также (в случае необходимости) экспорт данных в MS Word или MS Excel.

Используем мастер создания отчётов:

Выбираем нужные поля:

Уровни группировки:

Указываем, какие итоги надо вывести:

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

Варианты отчётов:

В процессе создания отчёта можно также использовать созданные ранее запросы, например, запрос по проценту одобрения, и тогда получаем отчёт вида:

Или на базе запроса по вычислению заработной платы можно создать отчёт с подведением итогов по заработным платам в январе:

VIII. Разработка системы пользовательского интерфейса информационной системы

Критерии качественности интерфейса

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

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

органично вписывается в бизнес-процессы;

удобен и прост в применении;

обеспечивает стабильную и предсказуемую работу системы.

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

Например, для просмотра таблицы 1 кнопка создаётся следующим образом:

выбираем кнопку на панели инструментов:

размещаем её на форме, в результате чего открывается диалоговое окно для выбора действия. Выбираем «Работа с формой - открыть форму»

выбираем форму для нужной таблицы (формы для таблиц созданы ранее в пункте 4)

выбираем способ открытия формы:

выбираем рисунок дл кнопки:

делаем подпись к кнопке с помощью метки:

Повторяем действия для всех таблиц.

Далее создаём кнопки для выполнения запросов на добавление/обновление(изменение) записи. Данные кнопки создаются аналогично, но выбирается раздел «Разное - Выполнить запрос»

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

Для создания макроса переходим в соответствующий раздел и выбираем «Создать».

Записываем, что надо открыть запрос, а внизу выбираем нужный запрос:

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

Аналогично были созданы кнопки для добавления, изменения и удаления записей по всем таблицам. Также на форме были помещены кнопки выхода из приложения и перехода на форму «МЕНЮ», на которой будут размещены основные разделы базы данных.

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

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

Создание формы для запросов:

Форму создаём аналогично форме для работы с данными

Создание формы для отчётов:

Форму создаём аналогично форме для работы с данными, однако на этот раз располагаем кнопки, для которых выбираем действие «Просмотр отчёта»:

Выбирая далее нужный отчёт для каждой кнопки, получаем форму для просмотра отчётов:

Создание формы управления проектом.