Разработка информационной системы компрометации банковских карт

Размещено на http://www.allbest.ru/

КУРСОВОЙ ПРОЕКТ

по дисциплине «Проектирование информационных систем»

Тема проекта

Разработка информационной системы

Введение

1. Выбор, описание предметной области и выявление требований, предъявляемых к информационной системе

2. Разработка и описание функциональной модели (точка зрения, границы модели, контекстная диаграмма, диаграммы декомпозиции, отчет по хранилищам данных (методологии IDEF0, DFD, IDF3))

3. Создание локальных концептуальных моделей (анализируется отчет по хранилищам данных)

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

5. Создание и проверка глобальной логической модели данных

6. Разработка физической модели данных. Прямое проектирование

7. Проектирование приложения (Delphi)

Заключение

Список используемых источников

компрометация база данные модель

Введение

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

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

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

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

Всё выше указанное поставило следующую задачу: обработку информации о данных банковских карт (включая ФИО владельцев, паспортные данные, номера счетов, контактную информацию и т.д.). Именно эти проблемы должна решить созданная база данных с использованием ЭВМ, позволяющих решить возникшие трудности за короткие промежутки времени с наименьшими затратами.

В данном курсовом проекте ставится задача на построение функциональной модели, разработку базы данных. Для решения данной задачи применяются специальные методологии и инструментальные средства (Bpwin, Erwin, Microsoft Project, Delphi).

1. Выбор, описание предметной области и выявление требований, предъявляемых к информационной системе

Выбор предметной области

Предметная область под названием «Компрометация банковских карт» выбрана по причине своей актуальности в настоящее время. Фонд «Общественное мнение» представляет результаты исследования распространенности банковских карт в РФ, количестве их пользователей, активности, социально-демографического портрета держателей карт. По данным статистики более чем 70% населения РФ владеют банковскими карами, и каждый год количество пользователей увеличивается (например, на 2011 год количество пользователей банковскими картами составил 40% населения РФ).

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

Описание предметной области

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

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

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

Случаи компрометации:

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

Открытая передача информации. Имеются в виду открытые каналы связи типа интернета в кафе или ресторане. Никогда не сообщайте свои секретные сведения таким опасным способом! Риск попадания информации не в те руки слишком велик.

Несанкционированный доступ злоумышленников к носителю информации. Имеется в виду подробный визуальный осмотр или проникновение в место хранения карты. Даже при подозрении на произошедшее следует обращаться в свой банк.

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

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

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

Выявление требований, предъявляемых к информационной системе

Рассмотрим ситуацию, которая может возникать у владельцев банковских карт. Для того, чтобы избежать больших затрат со стороны банка и клиента, платежные системы периодически присылают в банки списки скомпрометированных карт. Речь идет о карточных данных, которые могли быть украдены мошенниками (номер карты, CVV2 код, номер счета, дата выпуска карты и т.д.). В таких случаях платежные системы рекомендуют банкам обратиться к своим клиентам и сообщить, что данные с их карт могли быть украдены. Хотя это всего лишь рекомендация, многие банки, чтобы обезопасить деньги клиентов, могут сразу заблокировать карту.

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

Нужно построить систему таким образом, чтобы не производилось блокирование карт без предупреждения клиента, а так же блокировались карты строго попавшие в список «риска».

2. Разработка и описание функциональной модели (точка зрения, границы модели, контекстная диаграмма, диаграммы декомпозиции, отчет по хранилищам данных (методологии IDEF0, DFD, IDF3))

Для проведения анализа и реорганизации бизнес-процессов предназначено CASE-средство BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (Workflow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих на предприятии бизнес-процессов (так называемая модель AS-IS). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействие с окружающим миром (контекстная диаграмма), после этого проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.

Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как "внешняя ссылка" и "хранилище данных", что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

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

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

InterBase - это система управления реляционными базами данных. Она обеспечивает полную SQL-поддержку для всех реляционных концепций и структур. Для доступа к локальной БД InterBase на компьютере должна быть запущена программа IBServer (Firebird 2.1).

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

SQL - это легкий для понимания язык и в то же время универсальное программное средство управления данными.

Клиентское приложение предназначено для удобной работы с созданной базой данных. Программный продукт Turbo Delphi 2006 позволяет создавать клиентские приложения для сколь угодно сложных по своей структуре баз данных. Данное программное средство позволяет с удобством работать с БД сервера InterBase (FireBird). При достаточной подготовке разработчика, созданное им при помощи Delphi клиентское приложение обладает удобным интерфейсом и помогает пользователю решать его задачи, не задумываясь о сохранении целостности данных.

Инструментальное средство MS Project 2007 достаточно хорошо отражает временные взаимосвязи, существующие между отдельными работами проекта. Он позволяет управлять несколькими проектами, распределять ресурсы между проектами и внутри проекта, импортировать и экспортировать данные о проектах, создавать аналитические отчеты и контролировать процесс работы над проектом.

Построение контекстной диаграммы

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

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

Блок А0 - «Компрометация банковской карты», представленный на рисунке 1, может быть описан более подробно на другой диаграмме, расположенной на один уровень ниже в иерархии. Диаграмма нижнего уровня, или диаграмма-потомок, как бы показывает внутреннее содержание блока - родителя. Процесс создания более детальных диаграмм называется декомпозицией.

Рисунок 1. - Контекстная диаграмма

Декомпозиция моделируемой системы

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

Блок А1 - «Получение выгрузки от платежной системы»;

Блок А2 - «Обработка полученных данных».

Блок А3 - «Проверка корректности составленных списков».

Блок А4 - «Информирование владельца карты о предстоящей блокировке карты».

В процессе третьей подоперации происходит непосредственная реализация книжной продукции.

Design/IDEF определяет, представляет ли дуга, соединенная с декомпозируемым блоком, вход, выход, управление или механизм, и помещает соответствующий ICOM- код в лотовый узел на новой странице: I - для входной дуги (Input), С - для дуги управления (Control), О - для выходной дуги (Output), M - для дуги механизма (Mechanism).

Рисунок 2. - IDEF0-диаграмма первого уровня функциональной модели

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

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

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

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

Каждый из этих этапов может быть описан более подробно на другой диаграмме, расположенной одним уровнем ниже.

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

DFD-диаграмма содержит:

функции обработки информации (работы);

документы (стрелки) и объекты, которые участвуют в обработке информации;

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

таблицы для хранения документов или объектов (хранилище данных).

DFD-диаграмма блока «Получение выгрузки от платежной системы» будет иметь вид, представленный на рисунке 3.



Рисунок 3. - Диаграмма потоков данных для функционального блока «Получение выгрузки от платежной системы»

На данной диаграмме фиксируется информация о способе совершения платежа, даты и времени, регионе оплаты. После чего мы получаем список банковских карт (БК), который передается для сверки в базу данных банка.

Аналогично, DFD-диаграмма блока «Обработка полученных данных» будет иметь вид, представленный на рисунке 4.

Рисунок 4. - DFD-диаграмма блока «Обработка полученных данных»

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

В свою очередь, DFD-диаграмма блока «Проверка корректности составленных списков» будет иметь вид, представленный на рисунке 5.

Рисунок 5. - DFD-диаграмма блока «Проверка корректности составленных списков»

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



Рисунок 6 .- DFD-диаграмма блока «Информирование владельца карты о предстоящей блокировке карты»

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

3. Создание локальных концептуальных моделей (анализируется отчет по хранилищам данных)

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

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

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

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

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

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

Выявление и определение сущностей

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

Выявление и определение сущностей на основе анализа DFD-диаграммы:

На DFD-диаграмме информация, которую необходимо хранить в БД, изображается с помощью «хранилищ». Таким образом, выявляя на диаграммах потоков данных хранилища информации, мы определяем перечень сущностей, которые в дальнейшем потребуется создать при построении локальных концептуальных и логических моделей данных.

Рассмотрим DFD-диаграммы блоков. Из хранилищ данных выделим сущности и дадим им имена. Проанализируем DFD - диаграмму блока «Получение выгрузки от платежной системы», представленную на рисунке 3. Данная DFD - диаграмма содержит 3 хранилища: «Регион оплаты», «Способ оплаты», «Совершенные операции клиентом». Следовательно, в локальной концептуальной модели на логическом уровне должны быть представлены три сущности, соответствующие этим хранилищам. Назовем их соответственно «Регион», «Способ», «Операция». Аналогично, анализируя остальные три DFD - диаграммы, получим следующие сущности.

На диаграмме «Обработка полученных данных», представленной на рисунке 4 имеется три хранилища данных (выделяем три сущности): «Карты», «Операции», «БД_Банк».

На диаграмме «Проверка корректности составленных списков», представленной на рисунке 5 имеется четыре хранилища данных (выделяем четыре сущности): «БД_Банка», «Клиенты», «Ведущий», «Карты».

На диаграмме «Информирование владельца карты о предстоящей блокировке карты», представленной на рисунке 6 имеется три хранилища данных (выделяем три сущности): «Клиенты», «Правила», «Специалист».

Определение связей между сущностями

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

Могут быть выражены следующие отношения мощности:

Zero, One or Many(Ноль, Один или более);

Zero or Many(Ноль или один)-(Z);

One or Many(Один или более)-(P);

Exactly(Точное значение);

Рассмотрим отношения между сущностями «Регион», «Способ», «Операция», полученными из DFD - диаграммы блока А1 - «Получение выгрузки от платежной системы». Из неё следует, что: в одном регионе может быть совершено много операций; один способ оплаты присутствует во множестве регионов; одна операция может быть совершена только различными способами. На рисунке 1 представлена ER-диаграмма, показывающая связь между сущностями «Регион» и «Способ».

Рисунок 7. - ER-диаграмма, показывающая связь между сущностями «Регион» и «Способ»

Более наглядного представления всех связей между сущностями составим таблицу.

Таблица 1. - Определение связей между сущностями

Главная сущность	Наименование отношения	Дочерняя сущность	Тип связи
Регион	производится	Операции	один-ко-многим
Способ	выполняется	Операции	один-ко-многим
Операции	выполняется	Карты	один-ко-многим
БД_Банка	содержит	Карты	один-ко-многим
Клиент	содержит	Карты	один-ко-многим
БД_Банка	содержит	Клиент	один-ко-многим
Ведущий	обслуживает	Клиент	один-ко-многим
Правила	выполняется	Клиент	один-ко-многим
Специалист	обслуживает	Клиент	один-ко-многим

Определение атрибутов сущностей и первичных ключей

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

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

Список всех первичных ключей приведён в таблице 2.

Таблица 2. - Список первичных ключей сущностей

Сущность	Первичный ключ
Регион	Номер_региона
Способ	Название_способа_оплаты
Операции	Номер_операции
БД_Банка	Номер_регистрации
Карты	Номер_карты
Клиент	ФИО_Клиента, ПД_Клиента
Правила	Номер_тарифа
Специалист	Логин_Специалиста
Ведущий	Логин_Ведущего

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

	Атрибут	Тип атрибута	Формат атрибута
Регион	Номер_региона	Числовой	Длинное целое
	Название_региона	Текстовый	30
Способ	Название_способа	Текстовый	10
	Название_платежной_системы	Текстовый	10
Операции	Номер_операции	Числовой	Длинное целое
	Номер_региона	Числовой	Длинное целое
	Название_способа	Текстовый	10
	Сумма	Двойное с плавающей точкой	Длинное целое
	Дата_операции	Дата	Дата
	Время_операции	Время	Время
	Номер_карты	Числовой	Длинное целое
Карты	Номер_карты	Числовой	Длинное целое
	Номер_операции	Числовой	Длинное целое
	ФИО_Клиента	Текстовый	30
	Номер_регистрации	Числовой	Длинное целое
БД_Банка	Номер_регистрации	Числовой	Длинное целое
	ФИО_Клиента	Текстовый	30
	ПД_Клиента	Текстовый	10
	Номер_карты	Числовой	Длинное целое
Клиент	ФИО_Клиента	Текстовый	30
	ПД_Клиента	Текстовый	10
	Номер_Карты	Числовой	Длинное целое
	Номер_тарифа	Числовой	Длинное целое
	Логин_Ведущего	Числовой	Длинное целое
	Логин_Специалиста	Числовой	Длинное целое
	Номер_регистрации	Числовой	Длинное целое
Правила	Номер_тарифа	Числовой	Длинное целое
	ФИО_Клиента	Текстовый	30
	ПД_Клиента	Текстовый	10
Специалист	Логин_Специалиста	Числовой	Длинное целое
	ФИО_Клиента	Текстовый	30
Ведущий	Логин_Ведущего	Числовой	Длинное целое
	Номер_Карты	Числовой	Длинное целое
	ПД_Клиента	Текстовый	10

Создание диаграммы «сущность-связь»

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

На основании проделанной ранее работы, изобразим в виде ER-диаграмм локальные концептуальные модели.

Рисунок 8. - ER-диаграмма локальной концептуальной модели блока «Получение выгрузки от платежной системы»

Рисунок 9. - ER-диаграмма локальной концептуальной модели блока «Обработка полученных данных»

Рисунок 10. - ER-диаграмма локальной концептуальной модели блока «Проверка корректности составленных списков»



Рисунок 11. - ER-диаграмма локальной концептуальной модели блока «Информирование владельца карты о предстоящей блокировке карты»

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

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

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

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

- второй нормальной форме (сущность находится во 2НФ, если она находится в 1НФ и каждый неключевой атрибут полностью зависит от ПК (не должно быть зависимости от части ключа); 2НФ имеет смысл только для сущностей, имеющих сложный ПК);

- третьей нормальной форме (сущность находится в ЗНФ, если она находится во 2НФ и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимосвязи между неключевыми атрибутами)).

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

ER-диаграмма локальной логической модели блока «Получение выгрузки от платежной системы» представлена на рисунке 12. Модель удовлетворяет 3НФ.

Рисунок 12. - Локальная логическая модель блока «Получение выгрузки от платежной системы»

На рисунке 12 представлена модель, в которой нет сложной связи, связи «Много-ко- многому», рекурсивных связей. Введем атрибуты для сущностей. ER-диаграмма локальной логической модели блока «Обработка полученных данных» представлена на рисунке 13.

Рисунок 13. - Локальная логическая модель блока «Обработка полученных данных»

Рисунок 14. - Локальная логическая модель блока «Проверка корректности составленных списков»

Рисунок 15. - Локальная логическая модель блока «Информирование владельца карты о предстоящей блокировке карты»

5. Создание и проверка глобальной логической модели данных

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

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

При объединении локальных логических моделей необходимо придерживаться следующих правил:

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

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

Слияние общих сущностей из отдельных моделей с одинаковыми именами и первичными ключами. В этом случае атрибуты сущностей объединяются в одну сущность.

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

Две или более сущности могут моделировать одинаковые объекты, но в различных моделях имеют разные имена. Они могут быть объединены в одну сущность.

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

Таким образом, мы получили глобальную логическую модель рисунок 16:

Рисунок 16. - Глобальная логическая модель данных

6. Разработка физической модели данных. Прямое проектирование

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

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

Так как логическая модель данных уже была создана, то для просмотра физической модели можно воспользоваться списком выбора, расположенным в правой части панели инструментов ERwin (вместо Logical выбрать Phisical).

В данном курсовом проекте используется СУБД: InterBase. Для выбора сервера служит редактор Target Server (меню Server\Target Server), поэтому именно в нём указывается - InterBase.

Построение физической модели на основе логической предполагает ряд действий:

Задание правил валидации и значений по умолчанию для значений колонок таблиц. Это можно осуществить, выбрав пункт Column Editor/Interbase и щелкнув мышью по кнопке “…”

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

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

Создание генераторов, триггеров и хранимых процедур. Тексты созданных в проекте триггеров и процедур можно просмотреть в меню Trigger Editor и Table Editor\Stored Procedure соответственно.

Существуют также триггеры ссылочной целостности для поддержания целостности между двумя связанными таблицами. Если в данной таблице выполняется вставка (Insert), изменение (Update) или удаление (Delete), то триггер ссылочной целостности сообщает СУБД, что нужно делать с теми строками у других таблиц, у которых значения внешнего ключа совпадают со значениями первичного ключа вставляемой, изменяемой или удаляемой строки.

ERwin автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграмму. Режимы RI, присваиваемые ERwin по умолчанию, могут быть изменены в редакторе Referent Integrity Default который вызывается, если щелкнуть по кнопке RI Defaults диалога Target Server.

Определение доменов для всех атрибутов логической модели, или создание собственных доменов, создать который можно в подменю Edit\Domain Dictionary.

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

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

Для каждой связи между всеми родительскими и дочерними сущностями, присутствующими в модели, должно быть указано одно из типовых правил ссылочной целостности - RESTRICT, CASCADE, SET NULL, SET DEFAULT или NONE.

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

Также установим условные обозначения операций и правил:

D - Delete ;

U - Update ;

I - Insert ;

R - Restrict;

N - None;

C - Cascade;

SN - SET NULL;

SD - SET DEFAULT.

Физическая модель представлена на рисунке 17.

Рисунок 17. - Физическая модель данных

Прямое проектирование

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

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

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

Создание драйвера БД.

Для доступа к БД на основе спецификации Open Database Connectivity, разработанной компанией Microsoft, используются драйверы ODBC. ERwin может подключиться к БД, используя 32-разрядные драйверы ODBC. Для создания ODBC-драйвера выполним следующие действия:

Создадим пустую базу данных, используя IB Expert.

Откроем окно Пуск/Настройки/Панель управления/Производительность и обслуживание/Администрирование/Источники данных ODBC, прейдем на закладку «Пользовательский DSN».

Введем имя создаваемого драйвера.

Укажем в поле DataBase полный путь к созданной ранее БД.

Введем имя пользователя (SYSDBA) и пароль (masterkey) и нажмем кнопку <OK>.

Генерация системного каталога.

Процесс генерации можно провести двумя способами:

Напрямую из Erwin, используя ODBC драйвер.

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

Мы будем использовать второй способ. Для этого откроем созданную нами модель в Erwin и перейдем в пункт Tasks\Forward Engineering\Schema Generation. В открывающемся диалоге выберем набор установок, определяющий какие элементы и как должны войти в схему БД. Нажмем кнопку Report и сохраним файл на диске с расширением .sql. Откроем скрипт - файл в текстовом редакторе и дополним его нужными операторами, сохраним его. Перейдем в IBExpert. Создадим пустую базу, перейдем в редактор скриптов и выполним наш скрипт.

7. Проектирование приложения (Delphi)

Приложение проектировалось в интегрированной среде разработки Delphi 7. При этом использовались следующие страницы палитры компонентов: Standart, Additional, Win32, Data Access, Data Controls, InterBase, FastReport.

Существует большое количество способов доступа к данным из среды программирования. Наиболее распространенные это ADO, BDE, и InterBase Express. В данном курсовом проекте используется технология InterBase Express. Достоинством данной технологии является ориентация на «облегчённого клиента». Она представляет способ непосредственного обращения к серверу InterBase без использования BDE.

Все не визуальные компоненты, используемые для доступа к данным, такие как DataSource или Table, размещены на модуле данных (рисунок 18). Основным назначением которого является централизованное хранение компонентов доступа к данным. Модуль данных позволяет отделить управление БД от обработки данных и создать модуль, совместно используемый несколькими приложениями.

Рисунок 18. - Модуль данных

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

TDataBase- предназначен для осуществления соединения с базой данных.

Основные свойства:

DatabaseName - имя сервера и путь к базе данных (или псевдоним, если поддерживается сервером). Например - localhost:D:\Kurs\BDTEST.gdb, server:c:\Data\BD.gdb.

Params - параметры соединения: имя пользователя, пароль, кодовая страница символов и т.п. Если воспользоваться редактором свойств TIBDatabase (двойной клик на компоненте), то упомянутые свойства будут заполнены автоматически. Например, для базы данных, созданной с default character set win1251 параметры будут такими:

user_name=SYSDBA

password=masterkey

lc_ctype=WIN1251

На диалоге редактора свойств есть кнопка Test, которая позволяет проверить соединение с указанными сервером и базой данных. Если проверка прошла нормально, то можно установить свойство Connected в True.

Доступ к данным БД (как чтение так и модификация) осуществляется через три компонента типов: TQuery, TDataSource, TTable. Для каждого нужного набора данных созданы такие объекты.

TStoredProc- компонент для вызова хранимой процедуры.

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

CREATE PROCEDURE Kolvo (TDataSob date)

RETURNS (Karti integer)

AS BEGIN

FOR SELECT count(*)

FROM BD_Bank db

WHERE db.datasob = :TDataSob

INTO : Karti

DO

SUSPEND;

END

В свойстве компонента StoredProcName указываем имя хранимой процедуры - Kolvo.

В тексте запроса входным параметром является TDataSob. После чего необходимо найти свойство Params и нажать кнопку в строке этого свойства, в результате появится параметр TDataSob, для него необходимо указать:

- Data Type - ftString;

- Name - TDataSob;

- Param Type - ptInput.

TDataSource - обеспечивает взаимодействие набора данных с компонентами отображения данных.

Чаще всего одному набору данных соответствует один компонент TDataSource, хотя их может быть несколько. Для настройки свойств компонента необходимо выполнить следующие действия. Связать набор данных и компонент TDataSource. Для этого используется свойство DataSet компонента TDataSource, доступное через Инспектор объектов. Это указатель на экземпляр компонента доступа к данным. В списке этого свойства в Инспекторе объектов перечислены все доступные компоненты наборов данных. Переименовать компонент. Это не обязательное действие. Тем не менее, желательно присваивать компонентам осмысленные имена, соответствующие названиям связанных наборов данных. Обычно название компонента комбинирует имя набора данных (например, dsCalend).

Свойства остальных компонентов тех же типов задаются аналогично.

На следующем рисунке приведена главная форма приложения.

На ней расположено главное меню приложения (рисунок 19):

Рисунок 19. - Главная форма

Для подключения к базе данных необходимо воспользоваться меню «Файл» (рисунок 20).

Рисунок 20. - Меню «Файл»

И выбрать пункт меню «Подключение к базе», в результате чего появится диалоговое окно, в котором необходимо ввести путь к базе данных, имя пользователя (USER_NAME=SYSDBA) и пароль (PASSWORD=masterkey) - рисунок 21.

Рисунок 21. - Подключение к базе данных

После ввода необходимой информации нужно нажать на кнопку «Тест», и если все данные введены корректно, то будет выдано сообщение (рисунок 22).

Рисунок 22. - Успешное подключение

Обработчик кнопки «Тест» приведён ниже:

procedure TForm_Podkl.Button1Click(Sender: TObject);

begin

DataModul.dmModel.dbModel.Params.Clear;

DataModul.dmModel.dbModel.Params.Add('user_name=' +Edit1.Text);

DataModul.dmModel.dbModel.Params.Add('password=' + Edit2.Text);

try

DataModul.dmModel.dbModel.Connected := true;

finally

if DataModul.dmModel.dbModel.Connected then

ShowMessage('Подключение успешно!')

else

ShowMessage('Ошибка!');

end;

end;

Если введённая информация окажется неправильной, то будет выдано сообщение об ошибке - рисунок 23.

Рисунок 23. - Сообщение об ошибке

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

Рисунок 24. - Раздел Списки

Рассмотрим основные подпункты меню «Списки»:

Пункт «Карты»



Рисунок 25. - Список «Карты»

Пункт «Способы»

Рисунок 26. - Список «Способы»

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

Рассмотрим пункт «Карты - Клиенты».

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

Также, к примеру, рассмотрим отчет «Операции - Способы - Карты».

В данной форме также можно изменять, вносить и удалять информацию о клиенте с помощью навигатора.

Заключение

В результате курсового проекта была спроектирована автоматизированная информационная система "Компрометация карт".

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

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

Список используемых источников

1. Создание логических моделей в ERwin: Метод. указ. к практ. зан. / Рязан. гос. радиотехн. акад.; сост.: В.Е. Борзых, А.В. Борзых. Рязань, 2000. - 12с.

2. Создание физических моделей в ERwin: Метод. указ. к практ. зан. /Рязан. гос. радиотехн. акад.; сост.: В.Е. Борзых, А.В. Борзых. Рязань, 2001. - 12с.

3. Создание баз данных: Метод. указ. к теме /Рязан. гос. радиотехн. акад.; сост.: В.Е. Борзых, Рязань, 2002. - 24с.

4. Разработка локальных концептуальных моделей данных: Методические указания / Рязан. гос. радиотехн. ун-т; Сост. В.Е. Борзых. Рязан, 2006, 2006.. 16с.

5. Разработка приложений баз данных: Метод. указ. к лабораторным работам/Рязан. гос. радиотехн. ун-т; сост.: В.Е. Борзых. Рязань, 2009. - 40 с.

6. Разработка IDEF- моделей в Ramus Educational: методические указания к теме . Рязан. гос. радиотехн. ун-т; сост. В.Е. Борзых.- Рязань, 2011.-24 с.

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

...