ВТБ. Пояснительная записка. 1. Анализ предметной области Описание фирмы
 Скачать 5.16 Mb.
|
|
Управление взаимоотношениями с партнерами - Решения Oracle Siebel для управления взаимоотношениями с партнерами (Partner Relationship Management, PRM) предоставляют компаниям платформу масштаба предприятия для управления взаимоотношениями с партнерами и дилерами. С помощью Oracle Siebel PRM компании могут планировать и реализовать совместные программы продажи, маркетинга и обслуживания; повысить точность прогнозов и надежность информационных каналов; снизить затраты на управление партнерскими отношениями; а также усовершенствовать возможности глобального контроля над каналом сбыта. Управление взаимоотношениями с сотрудниками - Решения Oracle Siebel для управления взаимоотношениями с сотрудниками (Employee Relationship Management, ERM) - это единая система приложений, позволяющих компаниям значительно усовершенствовать штатное обучение, качество работы сотрудников и уровень их обслуживания в самых разных отраслях бизнеса. EPAM.Debt Collection Решение EPAM.Debt Collection состоит из трех интегрированных модулей: ▪ Soft Collection; ▪ Hard Collection; ▪ Legal Collection. Модуль Soft Collection полностью охватывает дистанционный этап сбора просроченной задолженности и подразумевает интеграцию с колл-центром компании. Система позволяет: ▪ автоматически отправлять должникам извещения о сроках внесения плановых платежей через SMS, IVR, e-mail, а также распространять маркетинговую информацию; ▪ в определенный срок отправлять должнику извещение о начале процесса взыскания задолженности; ▪ в автоматическом режиме формировать официальную почтовую корреспонденцию в адрес клиента; ▪ организовывать кампании по автообзвону и осуществлять контроль выполнения телефонных вызовов с участием операторов/с использованием IVR. Hard Collection автоматизирует досудебный этап (контактный сбор) и включает в себя извещение клиентов о необходимости погашения просрочки (автоматическое и с участием операторов, а также в форме почтовой корреспонденции). На этом этапе ЕРАМ.Debt Collection позволяет: ▪ хранить информацию о графике мероприятий по каждой конкретной просрочке; ▪ отражать результаты выполнения мероприятий по сбору просрочки, вносить и сохранять любые необходимые комментарии; ▪ осуществлять мониторинг процесса погашения должником просроченной задолженности; ▪ вести историю взаимодействия с должником, в том числе сохранять различные виды подтверждающих документов в отсканированном виде; ▪ отслеживать «рецидивы» клиентов в случаях возникновения повторной задолженности. Модуль Legal Collection охватывает судебный и послесудебный этапы сбора просроченной задолженности, которые включают в себя подготовку пакета документов для направления в суд, ведение приказного, искового, уголовного судопроизводств, мониторинг исполнительного производства, мониторинг и учет погашения кредита. При этом система дает возможность: ▪ автоматизировать взаимодействие между службами, отвечающими за ведение судебной и исполнительной деятельности; ▪ отслеживать время нахождения дел на каждой стадии судебного процесса; ▪ в автоматическом режиме распечатывать документы стандартной формы для направления в суд; ▪ автоматически готовить отчетность в соответствии с требованиями судебных органов различных регионов; ▪ рассчитывать госпошлину в зависимости от выбранного судопроизводства; ▪ хранить электронные шаблоны документов. Бизнес-выгоды использования EPAM.Debt Collection для розничных банков: ▪ единый инструмент для работы с должниками по различным видам кредитования на всех этапах просрочки; ▪ единая база должников, в том числе по филиалам; ▪ оперативная и аналитическая отчетность по эффективности коллекторов; ▪ эффективный контроль над подразделениями по сбору задолженности; ▪ гармоничная интеграция с любой АБС; ▪ распределение портфеля просроченной задолженности по коллекторам в зависимости от типа кредитного продукта, уровня просрочки и т.д. 2. Проектирование базы данных База Данных (БД) — структурированный организованный набор данных, описывающих характеристики каких-либо физических или виртуальных систем. 2.1 Проектирование инфологической модели сущность-связь (концептуальное проектирование) Первый этап проектирования БД – это инфологическое проектирование. На этом этапе создается частично формализованное описание объектов предметной области. Модель «сущность-связь» - это формальная модель предметной области, которая используется на этапе инфологического проектирования БД. Цель построения состоит в обеспечении разработчика схемой БД в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему БД. Проектирование инфологической модели было начато с определения сущностей и отношений между ними. В результате анализа предметной области были созданы 7 сущностей: Договоры (Dogovor), Клиенты (Klient), Звонки (Call), Сотрудники (Worker), Канал продаж (Kanal_prodaj), Продукт (Product) и Филиал (Filial). На диаграмме сущности представлены в виде прямоугольника, содержащего внутри название. Все сущности связаны отношениями между собой. Графически отношения между двумя сущностями представлены в виде соединяющего их отрезка, добавленного ромбом. У каждого отношения были определены две важные характеристики связей: степень и кардинальность. Степень – это число элементов одной сущности, связанных с одним элементом другой сущности. Кардинальность – признак, определяющий обязательность принадлежности отношений. После определения связей между сущностями были определены атрибуты сущностей. Например, атрибутами сущности Сотрудники (Worker) будут являться: код (Oid), ФИО (fio), должность (Dolgnost) и телефон (phone). Заключительным этапом построения инфологической модели «сущность-связь» являлось определение ключей. Ключ - это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Были определены первичные и внешние ключи. На диаграмме первичный ключ каждой сущности подчеркнут одинарной сплошной линией.  Рис.12 Инфологическая модель БД 2.2 Обоснование выбора СУБД СУБД - это комплекс языковых и программных средств, предназначенных для ведения, создания и совместного использования БД многими пользователями. Рассматриваемая база данных создана в серверной СУБД в MSSQL Server 2000, которая дает возможность реализовать все требования данного приложения. Одним из главных преимуществ MSSQL Server 2000 является его тесная интеграция с современными средствами разработки приложений: C# .NET, VB .NET, Delphi. СУБД MSSQL предоставляет все необходимые для выполнения работы возможности, реализует все необходимые механизмы поддержки целостности базы данных (внешние ключи, ограничение на значения атрибутов, хранимые процедуры). Кроме того, MSSQL Server имеет следующие возможности: многопользовательский режим работы, надежные системы архивации данных, удобный графический интерфейс для работы с базой данных, что упрощает доступ к данным, их редактирование. К недостаткам MSSQL Server следует отнести его платность. Тем не менее, инструменты, предоставляемые им, упрощают разработку приложений, тем самым, удешевляя её, что, в конечном счете, компенсирует стоимость СУБД, а в дальнейшем упрощает поддержку приложений. 2.3. Даталогическое проектирование Даталогическое проектирование реляционной БД осуществляется на основе модели сущность-связь. Целью данного вида проектирования является описание схемы реляционной БД в терминах выбранной СУБД. При этом необходимо обеспечить: Возможность хранения в БД всех необходимых данных; Исключение избыточности данных; Нормализацию таблиц для упрощения решения проблем, связанных с обновлением и удалением данных. Существует 2 подхода к проектированию схемы БД: классическое проектирование, которое заключается в том, что реляционная схема БД создается, минуя этап концептуального проектирования. метод, основанный на построении концептуальной модели данных, которая на этапе даталогического проектирования преобразуется в реляционную модель. В курсовой работе был использован именно второй метод. Суть преобразования концептуальной модели в реляционную заключается в том, что каждой сущности ставится в соответствие реляционная таблица, атрибутами которой становятся атрибуты сущности. Преобразование отношений осуществляется одним из трех способов в зависимости от мощности и кардинальности связи. В концептуальной модели были использованы только связи со степенью 1:М и М:М. Связь 1:М Для преобразования такой связи используются 2 правила. Фактором, определяющим выбор одного из этих правил является кардинальность n- связанной сущности. Правила преобразования: Если мощность связи 1:М и кардинальность n-связанной сущности является обязательной, то достаточно двух таблиц (по одной на каждую сущность). При этом ключ односвязной сущности должен быть добавлен как атрибут в таблицу, отводимую n-связанной сущности. Если мощность связи 1:М и кардинальности n-связанной сущности является необязательной, то необходимо создать три таблицы: по одной на каждую сущность и таблицу связи. Среди своих атрибутов таблица связи должна иметь по одному ключу от каждой сущности. Связь М:М Для преобразования такой связи используется одно правило в независимости от кардинальности сущностей. Оно звучит так: если мощность связи М:М, то необходимо использование трех таблиц: по одной на каждую сущность и одну таблицу связи. Таблица связи должна использовать ключи обеих сущностей. В концептуальной модели понадобилось введение составной сущности История болезни. Для её преобразования необходимо создать по одной таблице для каждой сущности и одну таблицу связи. После завершения преобразований всех конструкций полученную реляционную модель необходимо пересмотреть на предмет избавления от избыточности. Избыточные таблицы – это таблицы, информация которых полностью содержится в других таблицах схемы. После всех преобразований была получена следующая реляционная модель: Dogovor (id, Limit, Nomer, Valuta, Date_dogovor, Summ_dogovor, Ostatok, Tekushii, Prosrochennui, Prosr_procent, Priznak, Restruktur, Kol_dn_prosr, Kto_prin_resh, Kto_vvodil, Data_okonchania, Srok, Promo, Id_zayavki, V_status_dogovor, Poruchitel, kod_klient, kod_product, kod_kanal, kod_status); Klient (id, Fio, Data_rogdenia, Pol, Registracia, Sem_pologenie, Specialnost, Dolgnost, Zayavl_dohod, Podtv_dohod, Kol_chlenov_sem, Kol_igdivencev, Sred_mes_dohod, Dr_kredit, Avto, Dr_imushestvo, Name_work, Inn_work); Worker (id, Fio, Phone, kod_dolgnost); Product (id, Name); Kanal_prodaj (id, name); Call (id, Datezvonok, Comment, Boss_comm, kod_dogovor, kod_worker, kod_klient); Status (id, Name); Dolgnost (id, Name). Все реляционные таблицы, полученные на данном этапе проектирования, имеют третью нормальную форму, а значит дальнейшая нормализация не нужна. 2.4 Определение типов атрибутов Для реализации реляционной модели в выбранной СУБД нам необходимо было сначала определить характеристики атрибутов каждой таблицы, включая выделение ключей и правил поддержки целостности данных. Табл.6 Характеристика атрибутов
|