Некорректность, объем и разрозненность данных. Но, даже если в банке налажен сбор данных, нередки случаи, что работа с ними все равно представляет проблему для скоринг-вендора. Зачастую данные на разных участках банковской инфраструктуры собираются в совершенно разных форматах. Одновременно могут существовать базы различных типов, например, ORACLE, MS SQL, таблицы MS Excel и MS Access, а также базы в формате собственной учетной системы, разработанной программистами банка. Наиболее оптимальный, хотя и дорогостоящий вариант в этом случае - внедрение единого хранилища данных, в котором бы собиралась информация обо всей деятельности банка, а также максимально полная информация о клиентах.

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

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

Также наглядно реализован в процессе "Контроль за возвратом/невозвратом кредита клиентом через установленный договором срок" (См. рис.11.):

1. Осуществить проверку погашения кредита полностью

2. Выявить причину непогашения кредита полностью

3. Переоформить договор с клиентом на определенный срок

4. Определить погашение кредита поручителем

5. Определить погашение кредита через продажу собственности клиента

Рис.11. Декомпозиция

"Контроль завозвратом/невозвратомкредита клиентом черезустановленныйдоговором срок", представленная в нотации DFD

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

Риски кредитора:

кредитный риск;

риск ликвидности;

риск процентной ставки;

валютный риск;

инфляционный риск;

социально-политический риск;

риск законодательных изменений.

Риски заемщика:

риск утраты и повреждения предмета ипотеки;

риск утраты или понижения дохода;

валютный риск;

инфляционный риск;

социально-политический риск;

риск законодательных изменений.

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

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

2.3 Диаграмма IDEF3

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

Модель, выполненная в IDEF3, может содержать следующие элементы:

· Единицы работы (UnitofWork) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

· Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:

o Связь предшествования (Precedence) - показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.

o Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.

· Поток объектов (Object Flow) - показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя.

Диаграмма IDEF3 может также содержать перекрестки и объекты ссылок.

В данной нотации предоставлен процесс "Формирование экспертами банка пакета информации о клиенте (См. рис.12.).

Рис.12. Декомпозиция бизнес-процесса "Формирование экспертами банка пакета информации о клиенте", представленная в нотации IDEF3

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

Клиент обращается за услугой в банк (связь 1 к 1), там он должен получить договор (связь 1 к 1), недвижимость (связь 1 к 1), полиса страхования (связь 1 к N). Для этого с клиентом работают оценщики (связь 1 к N), специалисты (связь 1 к 1), агенты (связь 1 к N), бухгалтерия (связь 1 к N). При этом специалисты банка работают со страховой компанией (связь 1 к 1), которая предоставляет полиса страхования клиенту (связь 1 к N). Также клиент должен иметь поручителей (данное условие не обязательно) и имущество (связь 1 к N), которое будет выступать при неоплате кредита. С другой стороны поручителей (связь 1 к N) и имущество клиента (связь 1 к N) оценивает оценщик банка, а также он проверяет статус клиента в БКИ.

(ИНН сотрудника (является ключом), Фамилия, Имя, Отчество, время работы)

Атрибуты Сущности "Взносы по кредиту"

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

Атрибуты сущности "Семейноепопложение"

(Кодсемейное положение (является ключом), Состояние брака)

Атрибуты сущности "Вид платежа"

(Кодвида платежа (является ключом), Вид платежа)

2.4 Разработка инфологической модели

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

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

Инфологическая модель по предметной области ипотечное кредитование (См. рис.12.). Главными сущностями моей предметной области являются клиент (с атрибутами ИНН, ФИО, паспортные данные), поручители клиента (с атрибутами ИНН, ФИО, паспортные данные), имущество клиента (с атрибутами оценка, наименование), банк (с атрибутами ОКОНХ, ОКУД, юридический адрес), договор (с атрибутами срок выполнения, процентная ставка), недвижимость (с атрибутами оценка, наименование), полис страхования (с атрибутами номер полиса, наименование), страховая компания (с атрибутами ОКОНХ, ОКУД, юридическийадрес), БКИ (с атрибутами статус, долг), а также оценщики, специалисты, агенты, бухгалтерия (с атрибутами ИНН, ФИО, паспортные данные).

Клиент обращается за услугой в банк (связь 1 к 1), там он должен получить договор (связь 1 к 1), недвижимость (связь 1 к 1), полиса страхования (связь 1 к N). Для этого с клиентом работают оценщики (связь 1 к N), специалисты (связь 1 к 1), агенты (связь 1 к N), бухгалтерия (связь 1 к N). При этом специалисты банка работают со страховой компанией (связь 1 к 1), которая предоставляет полиса страхования клиенту (связь 1 к N). Также клиент должен иметь поручителей (данное условие не обязательно) и имущество (связь 1 к N), которое будет выступать при неоплате кредита. С другой стороны поручителей (связь 1 к N) и имущество клиента (связь 1 к N) оценивает оценщик банка, а также он проверяет статус клиента в БКИ.

Рис.13. Инфологическая модель предметной области "ипотечное кредитование"

Вывод: Во втором - специальном разделе были смоделированы бизнес - процессы операции ипотечного кредитования с помощью средства AllFusionProcessModeler7, заданы к системе вопросы, на которые она отвечает, разработана инфологическая модель.

3. Прикладной раздел

3.1 Реализация в Access

Теперь реализуем данную модель в СУБД Access

Какие вопросы представляются в данной СУБД.

1. Имеет ли возможность клиент банка взять ипотечный кредит;

2. Имеются ли долги у клиента банка в бюро кредитных условиях;

3. Все ли документы клиентом банка сданы;

4. Выполняются ли клиентом взносы по предоставленному ипотечному кредиту;

5. ФИО сотрудников банка работающего с клиентом;

6. Фамилия поручителей, связанных с клиентом банка;

7. Имеет ли клиент банка полисы страхования кредита;

8. Какая недвижимость выступает в предмет ипотечного кредита;

В данной СУБД будут реализованы такие виды запросов:

Личная информация о клиенте банка;

Осуществляется запрос оценщиками, специалистами и агентами банка

Информация о заключенном договоре с клиентом банка;

Осуществляется запрос специалистами и бухгалтерией банка

Информация о взносах клиентом денежных сумм по договору в определенные сроки;

Осуществляется запрос специалистами и бухгалтерией банка

Информация о статусе клиента из БКИ;

Осуществляется запрос оценщиками банка

Информация о банке, в котором клиент хочет получить кредит;

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

Информации об оценке личного имущества клиента;

Осуществляется запрос оценщиками банка

Информация о недвижимости, выступающей в роли ипотеки;

Осуществляется запрос оценщиками, специалистами, агентами и бухгалтерией банка

Информация о поручителях клиента банка;

Осуществляется запрос специалистами и оценщиками банка

Информация о страховой компании, предоставляемой полиса;

Осуществляется запрос специалистами банка

Информации о персонале банка, работающего с клиентом.

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

Ниже на рис.14 представлена схема данных в Access.

Рис.14. Схема данных в Access

3.2 Примеры форм, запросов и отчетов

Так выглядит главное окно базы данных на рис.15.

Рис.15. Главное окно базы данных

Данное окно имеет две кнопки:

Редактирование БД

Запросы

При нажатии "Редактирование БД" появится следующего окно, которое предоставлено ниже рис.16.

Рис.16. Окно "Редактирование БД"

При выборе определенного критерия появляется соответствующая форма, в которую вносятся определенные изменения. Например, при нажатии кнопки "Личные данные клиента" появляется следующая форма, представленная ниже на рис.17.

Рис.17. Форма заполнения личных данных клиента

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

Рис.18. Форма "Запросы"

Например, при нажатии кнопки "Отчет по взносам" появляется диалоговое окно, которое просит указать нужный ему номерадоговора. В случае правильного введения номера появляется отчет, в котором указываются его взносы по осуществлению погашения ипотечного кредита рис. 19.

Рис. 19. Запрос выглядит в виде отчета, на котором указаны взносы конкретного клиента.

3.3 Разработка даталогической модели

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

В данной ER-модели присутствует 16 сущностей с различного рода атрибутами. Почти каждая сущность такие как "личные данные клиента", "Кредитный договор", "БКИ", "Данные о поручителе", "Недвижимость в роли ипотеки" "Страховая компания", "Имущество клиента", "Банк", а также сотрудники банка связаны с сущностью "Список клиентов", первичный ключ которого "ИНН клиента".

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

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

Рис. 20. Применение CASE-технологий ERWIN для определения сущностей, их атрибутов и связей

3.4 Нормализация отношений

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

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

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

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

Определив каждую сущность, можно определить набор ее атрибутов.

Каждый заемщик (как и поручитель) имеет следующий набор сведений:

1. ИНН клиента

2. Фамилия

3. Имя

4. Отчество

5. Серия паспорта

6. Номер паспорта

7. Место регистрации

8. Место проживания

9. Номер связи

Если заключается договор по ипотечному кредитованию, то в нем указывается:

1. Номер договора

2. Фамилия

3. Имя

4. Отчество

5. Дата заключения договора

6. Дата окончания договора

7. % ставка

8. Вид платежа

Недвижимость, выступающая в роли ипотеки, имеет параметры:

1. Табельный номер недвижимости

2. Оценка

3. Наименование

4. Местонахождение

5. Описание

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

1. ИНН сотрудника

2. фамилия

3. имя

4. отчество

5. Время работы

6. Дата заключения по найму на работу

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

Попробуем привести отношения ко второй нормальной форме (2NF).

Для этого выделим следующие функциональные зависимости:

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

(ИНН клиента, Фамилия, Имя, Отчество, номер договора, дата заключения договора, дата окончания договора, % ставка, вид платежа)

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

Таким образом у нас определятся два следующие отношения:

(ИНН клиента, Фамилия, Имя, Отчество)

(номер договора, дата заключения договора, дата окончания договора, % ставка, вид платежа)

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

Теперь попробуем привести отношение к третьей нормальной

форме (3NF).

Рассмотрим отношение, связывающее сотрудников банка с клиентами:

(Фамилия клиента, Имя клиента, Отчество клиента, ИНН клиента, номер договора, дата заключения договора, дата окончания договора, % ставка, вид платежа, Фамилия сотрудника, Имя сотрудника, Отчество сотрудника, ИНН сотрудника)

Первичным ключом данного отношения является ИНН клиента, но стоит рассмотреть и другие функциональные зависимости:

ИНН клиента > Фамилия клиента, Имя клиента, Отчество клиента

ИНН клиента > номер договора

номер договора > дата заключения договора

номер договора > дата окончания договора

номер договора > % ставка

номер договора> вид платежа

ИНН сотрудника> Фамилия сотрудника, Имя сотрудника, Отчество сотрудника

Большинство этих зависимостей образуют транзитивные группы, во избежание этого следует выделить такие наборы отношений:

(ИНН клиента, Фамилия клиента, Имя клиента, Отчество клиента, номер договора)

(номер договора, дата заключения договора, дата окончания договора, % ставка, вид платежа)

(ИНН сотрудника, Фамилия сотрудника, Имя сотрудника, Отчество сотрудника)

Первичные ключи отношений выделены.

3.5 Разработка физической модели

Логическая архитектура выделяет, прежде всего, вопросы взаимодействия компонент системы, интерфейсы и используемые протоколы. Это представление позволяет эффективно организовать параллельную разработку. Физическая реализация, которая описывает привязку к конкретным узлам размещения, типам оборудования, характеристикам окружения, таким как, например, используемые операционные системы и т.п. Реализация данной модели осуществляется через MicrosoftOfficeAccess 2003 и SQL, таким образом, физическая модель приобретает некоторые изменения связанные со структурными изменениями атрибутов (См. рис.21 и 22.).

Атрибуты сущности "Список клиентов"

(ИНН клиента (является ключом), ОКВД банка, ОКУД банка, ОКВД страховой компании, ОКУД страховой компании, ОКВД БКИ, ОКУД БКИ, Номер договора, Код недвижимости, ИНН агента банка, ИНН бухгалтера банка, ИНН оценщика банка, ИНН специалиста банка)

Атрибуты сущности "Личные данные клиента"

(ИНН клиента (является ключом), Фамилия, Имя, Отчество, Дата рождения, Серия паспорта, Номер паспорта, Место регистрации, Место проживания, Место работы, Адрес места работы, Дата заключения по найму на работу, Заработная плата, Номер связи)

Атрибуты сущности "Данные о поручителе"

(ИНН поручителя (является ключом), ИНН клиента, Фамилия, Имя, Отчество, Серия паспорта, Номер паспорта, Место регистрации, Место проживания, Номер связи)

Атрибуты сущности "Недвижимость в роли ипотеки"

(Код недвижимости (является ключом), оценка, наименование, местонахождение, описание)

Атрибуты сущности "Страховая компания"

(ОКВД страховой компании (является ключом), ОКУД, наименование страховой компании, юридический и фактический адрес, номер полиса страхования жизни, номер полиса риска утраты имущества, номер полиса страхования титула)

Атрибуты сущности "БКИ"

(ОКВД БКИ (является ключом), ОКУД, Фактический и юридический адрес, Период времени, Состояние долга, Статус)

Атрибуты сущности "Кредитный договор"

(Номер договора (является ключом), дата заключения, дата окончания, % ставка, вид платежа)

Атрибуты сущности "Банк"

(ОКВД банка (является ключом), ОКУД, Наименование компании, Фактический и юридический адрес)

Атрибуты сущности "Имущество клиента"

(Код имущества (является ключом), ИНН клиента, наименование, оценка, местонахождение, описание)

Атрибуты сущности "Агенты банка"

(ИНН сотрудника (является ключом), Фамилия, Имя, Отчество, время работы)

Атрибуты сущности "Бухгалтерия банка"

(ИНН сотрудника (является ключом), Фамилия, Имя, Отчество, время работы)

Атрибуты сущности "Оценщики банка"

(ИНН сотрудника (является ключом), Фамилия, Имя, Отчество, время работы)

Атрибуты сущности "Специалисты банка"

(ИНН сотрудника (является ключом), Фамилия, Имя, Отчество, время работы)

Атрибуты Сущности "Взносы по кредиту"

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

Атрибуты сущности "Семейноепопложение"

(Кодсемейное положение (является ключом), Состояние брака)

Атрибуты сущности "Вид платежа"

(Кодвида платежа (является ключом), Вид платежа)

Рис.21. Применение CASE-технологий ERWIN, схема данных применимая в Access

Рис.22. Применение CASE-технологий ERWIN, схема данных применимая в SQLServer

Вывод: В третьем - прикладном разделе была разработана база данных в MicrosoftOfficeAccess, разработана даталогическая модель, физическая модель, разработаны интерфейсы форм, отчётов и запросов.

Заключение

В данной курсовой работе рассмотрена банковская процедура "Ипотечный Кредит".

Проделанная работа состоит из следующих этапов:

· анализ предметной области;

· программная реализация БД;

Для моделирования бизнес-процессов предметной области в нотациях IDEF0, DFD и IDEF3 использовано CASE - средство AllFusion Process Modeler 7. База данных реализована в СУБД: MSAccess 2010.

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

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

Источники информации

1. MicrosoftCorporation. Проектирование и реализация БД Microsoft SQL Server 2000: Учебный курс MCAD/MSE, MCDBA. - 2-е изд., испр. - М.: Русская редакция, 2003. - 512 с.

2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. - 4-е изд., доп. и перераб. - СПб.: КОРОНА принт, 2004. - 736 с.

3. Карпова Т.С. Базы данных: Модели, разработка, реализация. - СПб.: Питер, 2002. - 304 с.

4. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. - М: Финансы и статистика, 2004. - 192 с.

5. http://www.basegroup.ru/solutions/loans. htm

6. http://www.aptem.net.ru/nets/case/glava5_4. htm

7. http://www.basegroup.ru/deductor/deductor_server. htm

8. http://www.citforum.ru/database/mssql/overview/mssgl. htm

9. http://alice. pnzgu.ru/~dvn/uproc/studs/ivankina/index. htm

Приложения

Приложение - TARGET

ТАРГЕТ, TARGET (от англ. Trans-EuropeanAutomatedReal-timeGrossSettlementExpressTransferSystem) - межбанковская платежная система, позволяющая в режиме реального времени осуществлять международные расчеты внутри Европейского союза. Первая версия системы, введённая 1 января 1999 года, включала 16 национальных платёжных систем и платёжный механизм Европейского центрального банка. C 2007 года введена новая версия системы TARGET2.

Цели создания системы TARGET

Основными целями системы ТАРГЕТ являются:

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

· повышение эффективности платежей между странами-членами Европейского союза;

· содействие в проведении единой денежно-кредитной политики Европейским Центробанком.

В системе ТАРГЕТ связующая система построена на основе международной системы SWIFT (англ. SocietyforWorldwideInterbankFinancialTelecommunication).

Система ТАРГЕТ повышает ликвидность, являющуюся необходимым условием системы расчётов. Она предусматривает возможность получения ее участниками дополнительных ликвидных средств, которые могут быть использованы для осуществления платежей. Центральные банки предоставляют беспроцентные дневные кредиты под соответствующее обеспечение, которые могут быть использованы в течение рабочего дня неоднократно. В качестве обеспечения принимаются все активы, которые используются при проведении операций рефинансирования. Система работает ежедневно, за исключением выходных дней (суббота и воскресенье) и общенациональных праздников. В июне 2006 года через систему ТАРГЕТ было проведено более 7 миллионов платежей с общим объёмом более 47000 миллиардов евро.

TARGET2

Последняя версия системы, TARGET2, унифицирует технологическую инфраструктуру 26 центральных банков стран-членов Европейского союза. Она введена в действие 19 ноября 2007 года.

Стоимость услуг в системе TARGET2

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

1. фиксированная стоимость плюс оплата за каждую трансакцию:

o месячный платёж: 100 €;

o стоимость одной трансакции: 0,80 €;

2. фиксированная стоимость плюс оплата за каждую трансакцию в зависимости от их числа:

o месячный взнос: 1250 €;

o оплата каждой трансакции в зависимости от их числа:

Рис.23. Стоимость услуг в системе TARGET2

Размещено на Allbest.ru