Проектирование автоматизированной информационной системы по работе с кредитными заявками в ЗАО ЮниКредит Банк

Клиенты пишут заявление на предоставление кредита. Сотрудник ГВС сканирует комплект документов, забивает информацию в БД: вид кредита, отделения, информация о клиенте, сотрудники, № заявки. После этого прикрепляет отсканированные документы и отправляем в банк. Для того чтобы узнать результат или на какой стадии находится заявка, у нас есть хранилище данных «Статус заявки», которые также являются таблицами БД. После этого сотрудник Call-центра оповещает клиента о результате заявки и сообщает информацию о выданном кредите, которая хранится в таблице БД «Выдача кредита». Далее формируется соглашение о кредитном договоре и другие документы, необходимые для сделки. Клиент подписывает данные документы, далее сотрудник ГВС отправляет подписанную кредитную документацию на хранение в архив кредитного отдела.

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

Диаграмма DFD – движения информационных потоков также изменилась (рис.3.2.). Практически все информационные потоки проходят через информационную систему, которая в свою очередь хранит, обрабатывает и выдает всю необходимую информацию.

В модели TO-BE рассматриваются:

• 2 внешних сущности – «Клиент» и «Кредитный отдел»;

• 8 функциональных блоков – «Отсканировать комплект документов», «Создать заявку», «Прикрепить документы», «Отправить данные в банк», «Узнать о результате заявки», «Известить клиента о результате заявления», «Подготовить документы для сделки», «Подписать клиенту необходимые документы»;

• 9 хранилищ данных, из которых 2 бумажных архива – «Заявление клиента на получение кредита» и «Соглашение о кредитном договоре» и 7 таблиц БД ИС – «Виды кредита», «Отделения», «Информация о клиенте», «Сотрудники», «№ заявки», «Статус заявки», «Выдача кредита».

Функциональная модель TO-BE		Рис.3.1.

 

Движение информационных потоков TO-BE		Рис.3.2.

3.2. Моделирование структуры реляционной  БД в методологии IDEF 1X

3.2.1. Логический  уровень моделирования

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

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

База данных содержит 7 таблиц (рис. 3.3.), которые взаимосвязаны между собой связью 1:М (один-ко-многим).

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

База  данных «Заявки» состоит из следующих сущностей:

1. Cities- здесь отображается информация о названии города и количества населения в нем

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

3. Credit_type- показывает какие виды кредитов предоставляет банк и количество дней по регламенту на рассмотрение заявки

4. Departments- отображается, информация о подразделениях банка

5. Employees- предоставлена информация о сотрудниках банка

6. Credit_request- отражает полную информацию о заявках

7.Credit_issue- сущность, которая предоставляет информацию сотруднику о выдаче кредита клиенту

В  таблице 3.1.показаны атрибуты сущностей.

Таблица 3.1.

Атрибуты сущностей

Cities
city                           population	Varchar2(50) Number	PK	Название города Количество населения в городе
Clients
Client_id Client_full_name Birth_date Passport_num Passport_date Passport_issuer Phone Address	Number Varchar2(200) Date Varchar2(20) Date Varchar2(100) Varchar2(20) Varchar2(500)	PK	ID клиента ФИО клиента Дата рождения Номер паспорта Дата выдачи паспорта Кем выдан паспорт Контактный телефон Адрес
Credit_type
Credit_type_id Credit_type_name Reglament_days	Number Varchar2(50) Number	PK	ID номер типа кредита Название типа кредита Количество дней по регламенту на рассмотрение заявки по кредиту
Departments
Department_id Department_name Is_retail   City	Number Varchar2(100) Varchar2(1)not null Varchar2(50)	PK FK	ID подразделения Название подразделения или  отделения Внутреннее Подразделение или  отделение   Город, где расположено подразделение
Employees
Employee_id Full_name Department_id Is_active	Number Varchar2(100) Number Varchar2(1)not null	PK   FK	ID сотрудника ФИО сотрудника ID подразделения Сотрудник действующий или не работает
Credit_request
Request_id Credit_type_id Employee_id Client_id Submit_date Accept_date Is_accepted Accepter_id Comments Amount	Number Number not null Number not null   Number not null Date Date Varchar2(1) Number Number	PK FK FK FK       FK	Номер заявки на кредит ID типа кредита Сотрудник принявший заявку ID клиента Дата создания заявки Дата одобрения заявки Одобрено или отказано или на расм-ии Сотрудник принимающий решение Комментарий к заявке Сумма кредита
Продолжение таблицы 3.1.
Credit_issue
Request_id Department_id Credit_issue_date	Number Number Date	PK FK	Номер заявки на кредит Отделение, в котором был выдан  кредит Дата выдачи кредита

 

 

Описание связей.

 

1. Вид кредита– Заявки

Клиент может иметь счета  в банке.

Счета могут быть открыты у клиента.

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

Со стороны родительской сущности:

D:R – нельзя удалить запись из таблицы «Вид кредита», если есть заявка на данный вид кредит.

U:R – нельзя присвоить виду кредита другой номер заявки, если данный вид кредита прикреплен к определенному номеру заявки.

Со стороны дочерней сущности:

I:R – нельзя создать заявку без ссылки на вид кредита. 
U:R – нельзя  изменить заявку на несуществующее значение.

2. Сотрудники – Заявки

Сотрудники могут создавать  заявки.

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

Связь вида 1-М, т.е. сотрудник может  создавать одновременно несколько  заявок.

Со стороны родительской сущности:

D:R – нельзя удалить запись из таблицы «Сотрудники», если у сотрудника есть заявка.

U:R – нельзя присвоить сотруднику заявку, если у него нет заявки.

Со стороны дочерней сущности:

I:R – нельзя создать заявку, без ссылки на существующего сотрудника. 
U:R – нельзя  изменить заявку, присвоив несуществующего сотрудника.

3. Клиент-Заявки

Клиент может иметь заявки.

Заявки относятся к какому-либо клиенту.

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

Со стороны родительской сущности:

D:R – нельзя удалить запись из таблицы «Клиент», если у клиента есть заявка.

U:R – нельзя присвоить заявке другой номер, если заявка прикреплена к клиенту.

Со стороны дочерней сущности:

I:R – нельзя создать заявку, без ссылки на существующего клиента. 
U:R – нельзя  изменить заявку, присвоив несуществующего клиента.

4. Статус заявки – Заявки

Статус заявки принадлежит заявке.

Заявка определяет статус заявки.

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

Со стороны родительской сущности:

D:R – нельзя удалить заявку, если  у статуса есть заявка.

U:R – нельзя изменить статус, если за статусом прикреплена  заявка.

Со стороны дочерней сущности:

I:R – нельзя создать заявку, без  ссылки на существующего статуса. 
U:R – нельзя  изменить заявку, записав несуществующий статус.

5. Отделения– Сотрудники

В отделении может быть много  сотрудников.

Сотрудник может работать в одном  отделении.

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

Со стороны родительской сущности:

D:R – нельзя удалить сотрудника , если он прикреплен к отделениию.

Со стороны дочерней сущности:

I:R – нельзя создать запись о сотруднике, без ссылки на номер отделения. 
D:R – нельзя  удалить запись о сотрудники, если существует ссылка на номер отделения.

6. Клиент – Выдача кредита.

ФИО клиента отражается в таблице  «Выдачи кредита».

Выдача кредита может быть у  определенного клиента.

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

Со стороны родительской сущности:

U:R – нельзя изменить данные клиента, без изменения данных о выдаче кредита.

Со стороны дочерней сущности:

I:R – нельзя создать запись выдачи кредита, без ссылки на существующего клиента. 
D:R – нельзя  удалить запись выдачи кредита, если существует клиент.

 

3.3.2. Физический уровень моделирования

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

Если в логической модели не имеет  значения, какой конкретно тип  данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах –  таблицах, колонках, индексах, процедурах и т.д. Для этого ERwin имеет целый набор соответствующих редакторов. На основе ключей, описанных на уровне логической модели (поддерживаются первичные, внешние, альтернативные ключи и инверсионные входы) ERwin генерирует индексы. Могут быть также сгенерированы индексы, заданные дополнительно на уровне физической модели. Для поддержки целостности БД задаются правила ссылочной целостности, а также триггеры и хранимые процедуры, которые представляют собой программный код на SQL и хранятся на сервере.

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

Физическая модель данной БД изображена на рис.3.4.

 

Моделирование БД на логическом уровне		Рис.3.3.

 

Моделирование БД на физическом уровне		Рис.3.4.

 

3.3.Объектно-ориенттированное  проектирование ИС с помощью  языка UML

3.3.1. Диаграмма  вариантов использования

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

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

Диаграмма вариантов использования

Рис.3.5.

 

 

 

3.3.2. Диаграмма  классов

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