Разработка АИС учета валютных вкладов

     2. Платежные поручения клиентов  банка на обмен валюты:

     Реквизиты документа:

     - номер платежного поручении; 

     - дата платежного поручения; 

     - реквизиты плательщика: идентификационный  номер налогоплательщика (ИНН), название  организации, номер расчетного  счета, название банка, город  банка, номер кор-респондентского  счета, БИК банка; 

     - реквизиты получателя: идентификационный  номер налогоплательщика (ИНН), название  организации, номер расчетного  счета, название банка, город  банка, номер кор-респондентского  счета, БИК банка; 

     - назначение платежа: номер депозитного  договора, дата договора;

     - сумма в соответствующей валюте.

     3. Платежные поручения банка на  возврат депозита и перечисление  начисленных процентов по депозиту.

     Реквизиты документа:

     - номер платежного поручения; 

     - дата платежного поручения; 

     - реквизиты плательщика: идентификационный  номер налогоплательщика (ИНН), название  организации, номер расчетного  счета, название банка, город  банка, номер кор-респондентского  счета, БИК банка; 

     - реквизиты получателя: идентификационный  номер налогоплательщика (ИНН), название  организации, номер расчетного  счета, название банка, город  банка, номер кор-респондентского  счета, БИК банка; 

     - назначение платежа: номер депозитного  договора, дата договора, тип платежа  – возврат депозита / перечисление  процентов; 

     - сумма в соответствующей валюте;

     4. Выписка банка по выделенному  депозитному счету: 

     Используемые  реквизиты:

     - дата выписки; 

     - номер платежного поручения; 

     - признак поступления / расходования  средств; 

     - ИНН плательщика; 

     - номер договора;

     - тип платежа: внесение депозита, возврат депозита, перечисление  процентов; 

     - сумма в рублях*.

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

Если форма  документа студенту неизвестна, то она разрабатывается им оригинально. 

2.1. Проектирование комплекса информационной системы

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

    SADT – одна из самых известных методологий анализа и проектирования информационных систем, введенная в 1973 году Россом.

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

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

• графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интеРАейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интеРАейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
• строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
• связность диаграмм (номера блоков);
• уникальность меток и наименований (отсутствие повторяющихся имен);
• синтаксические правила для графики (блоков и дуг);
• разделение входов и управлений (правило определения роли данных).
• отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.

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

   Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих  ссылки друг на друга. Диаграммы –  главные компоненты модели, все функции  ИС и интеРАейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интеРАейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.

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

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

     2. Атрибуты. Атрибуты описывают сущность. Они представляются овалами с  указанием имен, которые прикреплены  к сущности. В моем случае проекту  соответствуют: номер проекта.  Деталям соответствуют: размер, номер  детали, маркировка, название. Поставщикам  соответствуют: ФИО, ИНН, адрес,  идентификационный номер поставщика. Заказу соответствуют: номер заказа, номер проекта, номер деталей,  идентификационный номер поставщика. Служащим соответствуют: ФИО,  ИНН, должность.

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

     

     Рисунок 5– Структура АИС

       Построение реляционной  модели

     В реляционной базе данных все данные хранятся в таблицах. Названия сущностей  станут заголовками таблиц, а атрибуты станут столбцами. Целостность данных в реляционной базе данных основывается на концепции ключей. Первичный ключ (PK) – это атрибут который можно  использовать для уникальной идентификации  таблицы. Так у таблицы “Организация” - ключом станет идентификационный номер наименования, мы обозначили как “id”. У таблицы “Юридические лица” - номер юридических лиц, мы обозначили как “id”. У таблицы “КурсВалюты” - номер курс валюты мы обозначили как “id”. Внешний ключ (ID) – это атрибут, который существует в нескольких таблицах и является первичным ключом одной из этих таблиц. Связь проводим от первичного ключа одной таблицы до внешнего ключа другой таблицы.  

       

     Рисунок 7- Формат записи таблицы “Курс Валюты”.

     Рисунок 8- Формат записи таблицы “Организация”.

     Рисунок 9- Формат записи таблицы “Юридические лица”.

     Нормализация

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

     Первая  нормальная форма требует, чтобы  все значения полей были атомарными и все записи уникальными. Реляционная  модель представленная на рисунках 7, 8, 9  находится в первой нормальной форме.

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

     Модель  находится в третьей нормальной форме, если она находится во второй нормальной форме и не имеет транзитивных зависимостей. Транзитивная зависимость  – это зависимость между не ключевыми атрибутами. Таким образом, выделяем  не ключевые атрибуты “№ паспорта” и “дата” таблицы “юридические лица”. Несмотря на наличие зависимости отдельной таблицы “дополнительные сведения”. Получаем модель в третьей нормальной форме, которая представлена на рисунке 6. 

     

     Рисунок 6 – Третья нормальная форма

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

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

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

 
 

Рис.1.6 Схема данными при работе с  БД

      Цикл  взаимодействия пользователя с БД с помощью приложения можно разделить на следующие основные этапы.

1. Пользователь терминала (1) процесса диалога с приложением формулирует запрос (2) на некоторые данные из БД.

2. Приложение (3) на программном уровне средствами языка манипулирования данными формулирует запрос (4), с которым обращается к СУБД.

3. Используя свои системные управляющие блоки и таблицы, СУБД с помощью словаря данных определяет местоположение требуемых данных и обращается (5) за ними к ОС.

4. Программы  методов доступа файловой системы  ОС считывают (6) из внешней  памяти искомые данные и помещают  их в системные буферы СУБД.

5. Преобразуя  полученные данные к требуемому  формату, СУБД пересылает их (7) в соответствующую область программы и сигнализирует (8) о завершении операции каким-либо образом (например, кодом возврата ).

6. Результаты  выбора данных из базы приложение (3) отображает (9) на терминале пользователя (1).

В случае работы пользователи в диалогом режиме с СУБД (без приложения) цикл взаимодействия пользователя с БД упрощается. Его можно представить следующими этапами: