Производственная практика в РГП «Банковское сервисное бюро Национального Банка Республики Казахстан»

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

       Объектом  автоматизации является отдел корреспондентских отношений и платежей Управления платежных систем НБРК.

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

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

1. Определение требований разработки программного продукта «мониторинг клиринговой системы в реальном времени»

Анализ  потребности в  программе

 
 

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

Назначение разработки и основные функции

 

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

• формирование протокола запросов для пользователя;
• формирование выходных форм отчетности для просмотра и печати.

Показатели  качества программы

 

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

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

Оценка  затрат и возможная  эффективность использования

 

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

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

2. Анализ  современных систем управления базами данных

       Концепция баз данных

 

       Активная  деятельность по отысканию приемлемых способов обобществления непрерывно растущего  объема информации привела к созданию в начале 60-х годов специальных  программных комплексов, называемых "Системы управления базами данных" (СУБД). Этому предшествовал первый опыт использования файловых систем для организации баз данных. Файловые системы выявили различные проблемы обработки большого количества информации и заложили основные направления развития теории баз данных.[2] Вот список лишь нескольких потребностей, которые не покрывались возможностями систем управления файлами:

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

 

       Можно считать, что если прикладная информационная система опирается на некоторую  систему управления данными, обладающую этими свойствами, то эта система  управления данными является системой управления базами данных (СУБД). Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД). Приведем типовую схемы организации работы с СУБД [рисунок 6].

 
 

       Рис. 6  Связь программ и данных при использовании СУБД 

       Архитектура СУБД

 

       СУБД  должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

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

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

       Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных [рисунок 7]. 

       

       Рис. 7 Уровни моделей данных 

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

       Остальные модели, показанные на рисунке 7, являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных. [3]

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

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

       Инфологическая  модель данных "Сущность-связь"

 

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

       Сущность  – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать  такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва.

       Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного  типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для  многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности.

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

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

       Связь – ассоциирование двух или более  сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей. [5]

Реляционная структура данных

 

       В конце 60-х годов появились работы, в которых обсуждались возможности  применения различных табличных  даталогических моделей данных, т.е. возможности использования привычных  и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

       Будучи  математиком по образованию Э.Кодд предложил использовать для обработки  данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление  данных сводится к совокупности двумерных  таблиц особого вида, известного в математике как отношение – relation

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

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