Курсовая работа
По Информатике на тему
“Автоматизированные рабочие места, предназначенные для финансово-кредитных органов”
Введение
Теоретическая часть
Автоматизированные рабочие места, предназначенные для кредитных органов
Классификация АБС
Архитектура прикладных систем
Архитектура АБС нового поколения
Практическая часть
Задача, решенная с использованием пакета
Электронных таблиц
Microsoft
Exel
Задача, решенная при помощи СУБД
Microsoft
Access
97
Приложение №1
Приложение №2
Приложение №3
Список используемой литературы
Введение
Курсовая работа состоит из теоретической и практической частей.
В Теоретической части рассматриваются вопросы Программного обеспечения Современных кредитных организаций. Приведена классификация систем, используемых в кредитных учреждениях по всему миру, описаны основные принципы работы Информационных систем Нового поколения.
В практической части решены 2 задачи с использованием пакета электронных таблиц MSExel и СУБД Access 97.
При написании данной работы использовался компьютер с процессором Pentium 166, монитором SyncMaster 500b и оперативной памятью 15,0 Мбайт.
Теоретическая часть
АВТОМАТИЗИРОВАННЫЕ РАБОЧИЕ МЕСТА, ПРЕДНАЗНАЧЕННЫЕ ДЛЯ ФИНАНСОВО-КРЕДИТНЫХ ОРГАНОВ
Немыслимо представить себе информационную систему, состоящую из автономных, не соединенных между собой компьютеров. Сетевые вычисления сегодня – обычное дело. Назначение сети меняется: из средства обеспечения совместной работы нескольких пользователей с одними и теми же файлами асинхронного обмена информацией она превращается в целостную среду, в которой на многих компьютерах одновременно исполняются отдельные элементы единой информационной системы.
Создание Автоматизированной Банковской Системы (АБС) занимает умы многих специалистов. На сегодняшний день существует классификация АБС по принципу технологического построения. Условно она представляет собой 6 поколений.
Классификация АБС
I поколение
Аппаратная платформа – автономные персональные компьютеры под управлением MS-DOS; СУБД – Clipper, FoxPro, Clarion; базовый элемент технологии – бухгалтерская проводка; структура АБС – автономные Автоматизированные Рабочие Места (АРМ), не связанные или слабо связанные по данным через обмен файлами (в том числе путем физического переноса на гибких дисках с компьютера на компьютер). Сейчас практически не встречается.
II
поколение
Аппаратная платформа – персональные компьютеры под управлением MS-DOS, работающие в локальной сети NovellNetWare; СУБД - Clipper, FoxPro, Clarion; базовый элемент технологии – бухгалтерская проводка; структура АБС – автономные АРМы, связанные по данным через общие файлы, лежащие на сервере и не связанные по функциям. Широко распространено до сих пор, особенно в небольших банках и в провинции.
III
поколение
Аппаратная платформа – персональные компьютеры под управлением MS-DOS (MSWindows), работающие в локальной сети NovellNetWare; СУБД – собственная разработка на базе менеджера записей Brtieve; базовый элемент технологии – бухгалтерская проводка, реже – документ; структура АБС – автономные АРМы, сильно связанные по данным через общие структуры базы данных и слабо связанные по функциям. Технология, переходная от “файл-сервер” к “клиент-сервер”. Широко распространено, в том числе в ряде крупных банков.
IV
поколение
Аппаратная платформа – персональные компьютеры под управлением MS-DOS (MSWindows), работающие в локальной сети, или же хост – компьютер с терминалами; СУБД – профессиональная реляционная (может быть постреляционная или сетевая); базовый элемент технологии – бухгалтерская проводка (реже), документ, сделка; структура АБС – автономные АРМы, сильно связанные по данным через общие структуры базы данных, в отдельных случаях связанные по функциям через общее ядро. Технология “хост-терминал” или двухуровневая “клиент-сервер”. Довольно распространено, но не у нас.
V
поколение
Аппаратная платформа – персональные компьютеры под управлением MSWindows, MS-DOS, реже UNIX, в распределенной сети (WAN) с несколькими физическими серверами приложений (которые работают под многозадачными многопользовательскими Операционными Системами (ОС)); СУБД – профессиональная реляционная плюс менеджер транзакций; базовый элемент технологии – документ или сделка; структура АБС – логические АРМы, сильно связанные как по данным, так и по функциям в пределах локальной сети или хоста и слабо связанные по данным в пределах распределенной сети. Технология трехуровневая “клиент-сервер” с использованием менеджеров транзакций. Единичные разработки.
VI
поколение
Аппаратная платформа – гетерогенная сетевая среда; СУБД - профессиональные реляционные с открытым интерфейсом (возможно одновременно несколько разных СУБД); базовый элемент технологии – сделка или документ; структура АБС – логические АРМы, динамически формируемые по компонентной технологии, сильно связанные по данным и функциям в пределах сети Intranet. Перспективная технология, появившаяся чуть больше года назад. Единичные разработки, но за ними будущее.
В настоящий момент на территории нашей страны используются АБС третьего поколения.
Архитектура прикладных систем
Иерархию функций АБС и ее технологическую платформу можно рассмотреть при помощи рисунка.
На самом нижнем (нулевом) уровне лежат функции (вызовы) ОС, обеспечивающие ввод-вывод информации. Чуть выше – функции файловой системы ОС или СУБД (в некоторых профессиональных СУБД они подменяют собой функции ОС) – это первый уровень. Еще выше – уровень процедур выборки данных СУБД (“считать текущую запись в буфер”… “переместиться на N записей” …. и т.п., сюда же относится и транзакционный механизм, сетевые блокировки и т.п.) – второй уровень. Далее следует уровень непроцедурных функций СУБД (SQL или другой непроцедурный язык манипулирования данными) – третий уровень. Следующий, четвертый уровень – это “технические” функции приложения (обеспечивающие преобразование данных, пользовательский интерфейс, интерфейс прикладного программирования и т.п., но являющиеся уже не функциями инструментального пакета СУБД, а пользовательскими функциями, созданными при программировании прикладной системы). Эти функции отвечают за логику программы. Пятый уровень – это бизнес - функции приложения, определяющие логику деятельности.
В зависимости от того, как разработчики построили АБС и к какому технологическому поколению она принадлежит , отдельные модули АБС будут по-разному использовать функции 6-ти описанных выше уровней (с нулевого по пятый). Так, ядро АБС может содержать только функции нулевого уровня (в системах I,II поколений) или первых пяти, с нулевого по четвертый (в системах IV,V поколений), а программы модулей, исполняемые на рабочих станциях системы, - соответственно, с первого по пятый или только пятый уровень. Рисунок наглядно это демонстрирует.
.Чем более высокого уровня функции объединены в ядре и доступны для рентабельного совместного использования всеми модулями системы, тем выше степень интеграции АБС (с технологической точки зрения).
В свою очередь, возможная степень интеграции АБС определяется ее технологической платформой. Так например, при использовании “персональных” СУБД и “толстых” клиентов, работающих в архитектуре “файл-сервер”, практически недостижима интеграция в ядре АБС функций выше первого уровня. Это вынуждает иметь в составе каждого модуля копии функций второго – пятого уровней, что увеличивает размер ядра, повышает требования к аппаратным ресурсам рабочих станций, усложняет их настройку и практически исключает возможность ее динамического изменения (например, переконфигурация модулей “на лету”). Если деятельность банка требует, чтобы на одной и той же рабочей станции выполнялись задачи, поддерживаемые разными модулями АБС, то динамическое изменение конфигурации может оказаться полезным. Иначе придется каждый раз при смене задачи выходить из одного модуля и загружать другой.
Общая тенденция развития технологических платформ ведет к тому, чтобы перейти от программирования информационной системы к ее настройке. При включении в ядро набора бизнес – функций пятого уровня настройка и конфигурация системы значительно упрощаются.
Широкое распространение локальных и глобальных информационно – вычислительных сетей привело к тому, что информационные системы приобретают распределенный характер. Первоначально распределенными становились только данные. Сейчас речь может идти уже и о распределенном хранении отдельных процедур и функций, так что в отдельных случаях можно говорить уже и о распределенном ядре информационной системы. Распределенное ядро может иметь система, построенная по Java – технологии или по компонентной технологии.
Преимущества распределенного ядра заключаются в том, что каждая процедура или функция исполняется на той машине, которая ближе всех к обрабатываемым данным; тем самым возрастает скорость обработки и появляется возможность ее распараллеливания. Однако технология такого рода требует наличия единой управляющей программы, которая служит “диспетчером” всех процедур и функций распределенного ядра. Наиболее перспективно решение этой задачи в форме компонентной технологии, в которой процедуры и функции II - V уровней оформляются в виде автономных компонент со стандартным интерфейсом, а в системе организуется диспетчер компонент, работающий с их очередью, подобно тому, как в системах, управляемых по событиям, функционирует процедура – диспетчер событий. В таких компонентных технологиях очень удобно создавать большие территориально распределенные информационные системы, использующие низкоскоростные каналы связи, так как сама технология допускает существенную асинхронность каналов.
Сейчас уже существуют инструментальные средства для создания информационных систем, построенных по компонентным технологиям такого типа. Примерами их в России могут служить система Miracle фирмы И.В.А. и “Элит – технология” фирмы “Открытые системы”. В первой из них диспетчером компонент является отдельный процесс, функционирующий на выделенном управляющем сервере. Вторая технология отличается тем, что в ней могут одновременно существовать несколько диспетчеров компонент.
Архитектура АБС нового поколения
На нынешнем этапе развития отечественной банковской системы определились основные задачи для систем автоматизации банков. К ним относятся, в частности, проведение финансового анализа, прогнозирование финансового положения банка, сбор и подготовка комплексных данных для принятия управляющих решений. В модели реализованы принципиально новые приемы концептуального построения АБС, которые предполагают отказаться от чисто “бухгалтерского” подхода и ориентировать систему на обработку документов, что, в свою очередь, не может не отразиться на организации интерфейса и на основных алгоритмах обработки. В ходе разработки новой автоматизированной банковской системы была поставлена и успешно решена задача “обособления” технологического ядра системы, в котором на этапе анализа реализуются определенные обобщенные абстрактные механизмы “прикладной функциональности”, что позволило оптимизировать работу системы.
В основе архитектуры новой модификации АБС лежит схема Клиент – Сервер (клиентская часть + сервер данных и хранимых процедур). Но в отличие от типовой в ней есть выделенный сервер приложений. (Рис. 1. Архитектура построения системы. Приложение № 1).
Рассмотрим элементы этой архитектуры.
Клиент
Программные модули клиентской части можно разделить на две группы:
Функциональные модули, обеспечивающие взаимодействие пользователя с системой, графический интерфейс, ввод запросов и данных, предоставление результатов по выполнению запросов;
Модули оболочки для связи с сервером данных.
Инрерфейс пользователя включает также окна с системными сообщениями о таких происходящих в АБС событиях, как поступление документа, возникновение “красного” сальдо на счете и др.
Сервер данных
· это SQL – сервер, который хранит все таблицы данных и процедуры системы. Все функции клиентской части реализуются только на основе вызова хранимых процедур (что очень важно для системы защиты).
В процессе функционирования системы хранимые процедуры подготавливают для клиентской части результаты своей работы. Эти процедуры могут вызывать другие хранимые процедуры, а так же обращаться к серверу приложений, активизируя его модули на выполнение.
Сервер приложений
исполняет специальные алгоритмы, которые неэффективно реализуются средствами сервера данных. Этот сервер может функционировать на том же компьютере, что и сервер данных, но его можно организовать и на другом компьютере. Модули сервера приложений обеспечивают функционирование системы безопасности и управления доступом, расчет процентов, формирование и обработку извещений. Все эти модули вызываются исключительно по запросам от хранимых процедур. Последние могут обращаться к серверу данных как напрямую, так и через внутренние хранимые процедуры.
Технологическое построение
Во “внутренней организации” системы можно выделить три основные составляющие: систему защиты информации и управления доступом, систему учета и систему обеспечения документооборота (Рис.2. Технологическая структура. Приложение №1).
В рамках перечисленных подсистем реализуются определенные абстрактные механизмы, которые вполне самодостаточны в том смысле, что их функционирование не зависит от работы системы.
Система защиты информации и управления доступом
является обособленной системой (ей все равно, какую прикладную систему защищать). На этом этапе разработки все объекты регистрируются в системе безопасности, после чего с учетом конкретных требований по защите от несанкционированного доступа “прописываются” процедуры прикладных систем (в основном они представляют собой вызов из прикладных процедур соответствующих им процедур системы безопасности). В результате создается некая матрица системы защиты, устанавливающая взаимосвязь между базовыми объектами и базовыми операциями. Базовый объект - это абстрактное понятие, опосредованно отражающее суть происходящего в системе. Примерами базовых объектов являются “документ” и “картотека”. Под базовой операцией понимается операция проблемной области, реализованная как целостный (неделимый) набор определенных технологических действий и описанная в терминах предметной области. Примерами базовых операций могут служить “проверка”, “проводка”, “откат”.
При эксплуатации системы технологу (или офицеру безопасности) предоставляется возможность по своему усмотрению группировать базовые операции и базовые объекты (Рис. 3. Группировка базовых объектов и операций. Приложение №1), формировать оргштатную структуру и расставлять отметки, регламентирующие доступ представителей оргштатной структуры к обобщенным объектам и операциям.
Все настройки хранятся и подвергаются корректуре в таблицах сервера данных. При работе системы информация из этих таблиц (в матрице доступа) переносится на сервер защиты (т.е. на сервер приложений). Таким образом в процессе функционирования осуществляется контроль за доступом.
Система учета
обеспечивает фактический и позиционный учет банковских операций. В ее основе - абстрактная модель бухгалтерского учета (она разработана А. Екушовым, ведущим специалистом аналитического отдела компании R-StyleSoftwareLab.), оперирующая такими понятиями, как “конто”, “показатель” и “проводка”. Конто - это элементарная единица аналитического учетного регистра для однородных банковских операций. На внешнем (прикладном) уровне конто соответствуют лицевые счета (балансовые, внебалансовые, депо) и кассовые символы. Показатель относится к области синтетического учета, он предназначен для группировки аналитических объектов при формировании отчетности и проведения анализа. На внешнем уровне показателям соответствуют счета I-II порядков, разделы плана счетов ЦБ, символы отчетности различных форм. В терминах бухгалтерской модели конто и показатели являются абстрактными счетами учетной системы. Структура показателей и конто строится на основе иерархии неограниченного уровня вложенности. И наконец, проводки формируют состояния конто - хранящиеся в системе обороты по дебету и кредиту, а также остаток. Состояния показателей рассчитываются на основе состояний иерархически подчиненных конто при помощи правил простой интеграции. При выполнении проводок фиксируется время ввода, планирования, подтверждения планирования и фактического учета.
Система учета позволяет вводить ограничения на выполнение операций над конто. На прикладном уровне такие ограничения соответствуют овердрафту, лимитам на обороты и величину остатка (как “сверху”, так и “снизу”), различным видам блокировки (вплоть до ареста) и бронированию средств на счете. Когда ограничения “включены”, учетная система проверяет, допустимо ли выполнить операцию и - в зависимости от результатов проверки - либо выполняет ее, либо предоставляет соответствующие коды возврата.
Важной особенностью учетной системы стал отказ от использования “внутреннего” понятия “операционный день”. Фактическое и планируемое состояния конто формируются в соответствии с “линейками времени”, которых в системе три: дневная, месячная и годовая. При любом текущем изменении конто анализируется дата проводки (фактическая или плановая), а также изменяются дневное, месячное и годовое состояния, соответствующие этой дате. Если при этом в системе имеются дневные состояния данного конто с более поздними датами, то эти состояния автоматически пересчитываются.
Для реализации алгоритмов учетной системы используются процедуры и таблицы сервера данных. В состав модулей системы учета входят модули клиентской части, которые обеспечивают диалоговый режим при создании счетов и работы с ними. В подавляющем большинстве случаев это - модули технолога системы, которые позволяют поддерживать структуру показателей и конто, а также организуют доступ для аудита ко всем счетам и проводкам системы учета независимо от их прикладного применения.
Поскольку учетная система в структуре АБС достаточно обособлена, взаимодействие с ней осуществляется через интерфейс прикладного программирования API (ApplicationProgrammingInterfase), который состоит из двух частей: интерфейса операционного сервиса и интерфейса информационного сервиса. Соответственным образом разделяются интерфейсные модули клиентской части.
Система обеспечения док
самая важная составляющая с точки зрения выполнения прикладных функций. Основными объектами системы являются документ и картотека. Картотеки характеризуются следующими свойствами:
их количество в системе конечно;
пользователи системы не могут создавать и уничтожать их;
разрешенные перемещения документа из одной картотеки в другую заранее предусматриваются технологом системы;
обращение к учетной системе для инициирования проводок происходит при перемещении документа из одной картотеки в другую.
Картотека объединяет документы, которые находятся на одной стадии обработки (например, документы картотеки №2).
В системе обеспечения документооборота можно выделить два звена: компоненту имитации документооборота и хранилище документов. Любая операция по обработке документов начинается с его ввода в систему. Наличие компоненты имитации документооборота позволяет выполнять определенные действия над документом в картотеке и перемещать документ из одной картотеки в другую. Когда необходимо осуществить операцию бухгалтерского учета, формируется обращение к учетной системе, с тем чтобы выполнить проводки и внести изменения в состояние конто. Следует отметить, что у компоненты имитации документооборота довольно сложная клиентская интерфейсная часть, отображающая движение документов по картотекам с учетом специфики реализуемых функций.
Документы, обрабатываемые в системе, имеют структурированную и неструктурированную (обычно текстовую) части. Обработка структурированной части выполняется с использованием кодификаторов типов документов, операций, контрагентов, ценностей и т.д. Неструктурированная часть может обрабатываться с помощью специальных алгоритмов, которые могут создаваться как разработчиками АБС, так и ее пользователями в процессе эксплуатации. Хранилище документов имеет свой API.
Система обеспечения документооборота позволяет включить в АБС элементы офисной системы, вследствие чего, во-первых, технология работы АБС приближается к естественной и привычной банковской технологии и, во-вторых, создаются предпосылки для накопления и обработки дополнительной информации, которая будет основой для финансового анализа и управленческих решений.
Взаимодействие системы обеспечения документооборота с учетной системой осуществляется через транзитную систему, которая содержит правила учета (для преобразования информации, содержащейся в документе, в проводке), а так же фонд счетов, переводящий внешнее представление счетов и идентификаторы конто и содержащий внешние атрибуты счетов.
Включение в АБС таких элементов, как справочники-классификаторы и фонд клиентов, достаточно традиционно. Модули клиентской части и хранимые процедуры сервера обеспечивают стандартный набор действий, таких как ввод информации, ее редактирование и удаление. История изменений сохраняется.
ПРАКТИЧЕСКАЯ ЧАСТЬ
Задача, решенная с использованием пакета Электронных таблиц
Microsoft
Exel
.
I
. Общая характеристика задачи.
Вычислить размер часового выпуска изделий в Январе, если известно, что рационализация производства дала возможность увеличить часовой выпуск изделий в феврале на 1,2% по сравнению с Январем, в марте – на 1,4% по сравнению с Февралем, при этом часовой выпуск изделий был доведен в Марте до 580 штук.
II
. Выбор пакета электронных таблиц.
Для решения данной задачи целесообразно использовать Приложение MicrosoftExel, входящее в интегрированный пакет программ MicrosoftOffice 97. MicrosoftExel – это электронные таблицы, позволяющие производить операции над данными, представляя их в удобном для восприятия виде.
III
. Проектирование форм выходных документов.
Спроектируем таблицу – шаблон для выполнения расчетов.
Для решения задачи создадим таблицу, шаблон которой приведен ниже:
Так как нам известно, сколько продукции было выпущено в Марте, а так же темпы рационализации, вычисления проводятся, исходя из цифры “580”.
Используя формулы, приведенные в таблице, можно вычислить объем продукции для любого другого месяца, имея исходные данные скажем по Ноябрю, и уровень рационализации за каждый месяц. Тогда шаблон будет выглядеть следующим образом:
IV
. Результаты выполнения контрольного примера.
Результаты выполнения контрольного примера приведены в следующей таблице:
Расчет контрольного примера.
Количество Изделий в Марте = 580шт., что составляет 101,4% от объема выпуска в Феврале.
Кол-во выпущенных изделий в Феврале:
580/101,4*100=571,99, с учетом округления = 572шт., что составляет 101,2% от объема изделий, выпущенных в Январе.
Количество изделий, выпущенных в Январе:
572/101,2*100=565,22, с учетом округления = 565шт.
Инструкция по применению пакета Электронных таблиц для решения нашей задачи.
Для работы с программой необходимо наличие компьютера с процессором 486 (и выше) и с объемом оперативной памяти не менее 12 Мб, операционная система MicrosoftWindows 95, интегрированный пакет программ MSOffice 97, составным элементом которого является MicrosoftExel.
Запуск программы.
В нижней части рабочего стола Windows 95 расположена линейка задач, на которой находятся кнопка Пуск
и кнопки для вызова запущенных программ. После нажатия кнопки Пуск
на экране появляется стартовое меню. Для запуска Exel следует открыть подменю Программы
стартового меню и активизировать команду Microsoft
Exel
. В результате программа Exel будет запущена и на экране появится ее окно.
Активизируйте в меню Файл
команду Открыть.
Выберите имя файла (например, таблицы.xls). На экране появится Таблица №3
.
Ввод исходных данных.
Установите курсор на пересечении строки с наименованием “Март”
и столбца с наименованием “Почасовой выпуск изделий в текущем месяце”
. Наберите с клавиатуры число, равное объему почасового выпуска продукции в Марте, нажмите Enter
.
В этом же столбце напротив граф “Январь” и “Февраль” появились цифры, которые показывают объем почасового выпуска изделий в Январе и Феврале.
Для вывода данных на печать активизируйте команду Печать
в меню Файл
, укажите тип принтера и нажмите клавишу Enter
.
Завершение работы с программой.
Существует несколько способов выхода из программы Exel:
Щелчок на кнопке, предназначенной для закрытия Exel-окна (на таких кнопках, расположенных в правом верхнем углу окна, принято изображать крестик).
Активизация команды Выход
из меню Файл
.
Вызов команды Закрыть
из контекстного меню окна программы Exel.
Задача, решенная при помощи СУБД
Microsoft
Access
97.
Общая характеристика задачи:
Автоматизация контроля за ходом выполнения графика работ. Выдача информации о незавершенных к настоящему моменту работах, предупреждение по работам, срок исполнения которых наступил.
Инструкция по использованию базы данных “График работ
”
I
. Описание конфигурации.
Для работы с программой необходимо наличие компьютера с процессором 486 (и выше) и с объемом оперативной памяти не менее 12 Мб, операционная система MicrosoftWindows 95, интегрированный пакет программ MSOffice 97, составным элементом которого является Access 97.
База данных состоит из взаимосвязанных между собою таблиц, запросов и форм. Исходные данные хранятся в таблицах, куда их удобно заносить при помощи форм. Информацию о состоянии дел удобно получать при помощи отчетов.
Подробное описание конфигурации дано в Приложении №2.
II
. Запуск программы.
В нижней части рабочего стола Windows 95 расположена линейка задач, на которой находятся кнопка Пуск
и кнопки для вызова запущенных программ. После нажатия кнопки Пуск
на экране появляется стартовое меню. Для запуска Access следует открыть подменю Программы
стартового меню и активизировать команду Microsoft
Access
. В результате программа Access будет запущена и на экране появится ее окно.
После запуска программы на экране появляются окно приложения. Активизируйте опцию “открыть базу данных”, затем выберете название базы данных (в нашем случае: “График работ”) при Экран будет выглядеть вот так:
База данных может содержать множество объектов, отсортированных по категориям и расположенных на разных вкладках ее окна. Данная база состоит из таблиц, заказов, форм и отчетов.
Таблицы.
В реляционных базах данных вся информация хранится в виде таблиц. Каждая строка таблицы представляет собой запись, а столбец – поле. Запись содержит набор данных об одном объекте (например, Фамилия, Имя, Отчество сотрудника), а поле – однородные данные о всех объектах (например, должность сотрудника).
Запросы.
Запросам присущ обширный круг функций. В первую очередь они предназначены для отбора данных на основании критериев. Благодаря запросам можно в любой момент выбрать из базы данных необходимую информацию.
Формы.
Форма представляет собой бланк, подлежащий заполнению, или маску, накладываемую на набор данных. Форма-бланк позволяет упростить процесс заполнения базы, что дает возможность поручить ввод информации персоналу невысокой квалификации. С помощью формы-маски можно ограничить объем информации, доступной пользователю, обращающемуся к базе.
Отчеты.
Отчеты служат для отображения итоговых данных из таблиц и запросов в удобном для просмотра виде.
III
. Ввод данных в базу.
Для первоначального ввода данных необходимо активизировать вкладку Формы
. Левой кнопкой мыши выделите форму “Сотрудники”.
Нажмите кнопку “Открыть”
. При этом экран будет выглядетьтак:
Установите курсор в поле “Фамилия”
и наберите фамилию сотрудника с большой буквы, нажмите “
Enter
”.
Курсор автоматически перейдет в следующее поле. Заполните форму до конца необходимым количеством сотрудников, причем машина автоматически будет присваивать им порядковые номера.
Активизируйте в меню “Файл”
команду “Сохранить”
или воспользуйтесь сочетанием клавиш “
Ctrl
+
S
”
. Закройте форму. Аналогично заполните форму “Заказы №12”
. Обратите, пожалуйста, внимание, что при выборе ответственного сотрудника, его предлагается выбрать из списка, который раскрывается, при попадании курсора в поле фамилия. В раскрывающемся списке содержатся Фамилия, Имя, Отчество и должность сотрудников, введенных в предыдущей форме. Форма ввода заказов выглядит следующим образом:
Календарь, выведенный в поле формы позволяет планировать выполнение работ не только при помощи дат, но и дня недели.
Например
, для определения того, каким днем недели будет 15 марта 1999года, надо выбрать из списка месяцев месяц “март”, из списка лет - “1999”, при помощи левой кнопки мыши указать число “15”, и убедиться в том, что 15 марта 1999г. –это вторник.
Переход к оформлению следующего заказа или же просмотр предыдущего можно осуществлять при помощи линейки прокрутки, расположенной в левом нижнем углу. При нажатии левой кнопкой мыши на стрелочку вправо, на экране отображается следующий заказ, при нажатии стрелочки влево, появляется информация о предыдущем заказе.
Для удобства использования данные можно фильтровать или сортировать по любому параметру.
Например
, для сортировки заказов по наименованию, надо активизировать окно “Наименование работы по Плану”,
находясь при этом в поле формы, выбрать из меню “Записи”
команду “Фильтр”
, “Расширенный фильтр”.
На экране появится поле, разбитое напополам по горизонтали. В нижней части экрана в строке “поле”
выберите : “НаименованиеРаботыПоПлану”,
в строке сортировка выберете, к примеру, по убыванию. Затем, активизируйте в меню “Фильтр”
команду “Применить фильтр”.
Используя расположенную в левом нижнем углу линейку прокрутки, просмотрите записи, которые теперь расположены в порядке, противоположном алфавитному. Теперь выберите команду “Удалить фильтр”
из меню “Записи”.
Заказы отсортированы по номерам.
Полный перечень заказов можно просмотреть так же в режиме таблицы. Для этого надо открыть таблицу “Заказы№1”
, расположенную во вкладке “Таблицы”.
На данные в таблице можно накладывать фильтр, по тому же принципу, что и в случаи с формами; их можно сортировать по содержимому отдельных столбцов.
1.
IV
. Получение информации о состоянии дел на текущую дату.
Подобную информацию удобно представлять в виде отчетов и форм.
Для формирования отчета активизируйте вкладку “Отчеты”
, выберете один из предлагаемых программой отчетов:
Незавершенные работы
Просроченные работы
Сотрудники
Пример.
Рассмотрим процесс формирования отчета на примере отчета “Незавершенные работы”.
Выберете отчет под названием “Незавершенные работы”,
левой кнопкой мыши нажмите кнопку “Просмотр”.
На экране появится окно с надписью “Дата Запроса”
. Ведите значение даты в формате : “09,01,99”, нажмите “ОК”.
На экране появится отчет о состоянии дел на 09 января 1999г. В графе “Осталось дней”
данные со знаком “ - ” говорят о том, что срок выполнения данной работы уже наступил, число со знаком “+” показывают, сколько дней осталось до момента выполнения задания.
Аналогично формируются отчеты “Просроченные работы” и “Сотрудники”. В отчете “Сотрудники” показывается сколько и какого плана работы сделаны каждым отдельным сотрудником.
Примеры отчетов приведены в Приложении №3.
V
. Завершение работы с программой.
Существует несколько способов выхода из программы Access 97:
Щелчок на кнопке, предназначенной для закрытия Access-окна (на таких кнопках, расположенных в правом верхнем углу окна, принято изображать крестик).
Активизация команды Выход
из меню Файл
.
Вызов команды Закрыть
из контекстного меню окна программы Access97.
Нажатие комбинации клавиш [Alt + F4].
| Приложение №1 |
|
|
Приложение №2
Приложение №3
Незавершенные работы.
Заказы
НаименованиеРаботыПоПлану
Ремонт электропроводки
Осталось дней
1
Фамилия
Чакалев
НаименованиеРаботыПоПлану
Газопровод
Осталось дней
8
Фамилия
Чакалев
НаименованиеРаботыПоПлану
Переезд отдела маркетинга в новый корпус
Осталось дней
11
Фамилия
Антонов
15 апреля 1999 г. Страница 1 из 1
Срок исполнения наступил.
Заказы
НаименованиеРаботы по Плану
Переброска кабеля на 6-ой
этаж
Просрочено
1
Фамилия
Чакалев
НаименованиеРаботы по Плану
Ремонт сервера
Просрочено
0
Фамилия
Енжов
НаименованиеРаботы по Плану
Установка и тестирование
новой программы
Просрочено
0
Фамилия
Макеев
НаименованиеРаботы по Плану
Газопровод
Просрочено
0
Фамилия
Чакалев
НаименованиеРаботы по Плану
Ремонт электропроводки
Просрочено
10
Фамилия
Чакалев
15 апреля 1999 г.
Страница 1 из 1
Статистика по сотрудникам.
Сотрудники
Фамилия
НаименованиеРаботыПоПлану
Антонов
Переезд отдела маркетинга в новый
корпус
Енжов
Ремонт сервера
Макеев
Установка и тестирование новой
программы
Чакалев
Газопровод
Ремонт электропроводки
Переброска кабеля на 6-ой этаж
15 апреля 1999 г. Страница 1 из 1
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
1. В. Пасько Access 97 Русифицированная версия. СПб.: ВНV 1998 – 365с.
2. А.Евтюшкин Снова о Банковских системах.//Банковские технологии. Июль-Август 1997. №6/97 с.20-30.
3. С.Архипенко Как добываются знания. //Банковские технологии. Февраль 1998. № 2/98 с.56-61
4. А. Евтюшкин Рассуждения о технологической платформе.//Банковские технологии. Февраль 1998. № 2/98 с.14-20
5. Т.Яковлев Архитектура АБС Нового поколения// Банковские технологии. Февраль 1998. № 2/98 с.85-88
6. Л.Спицын, С.Коротких Техническая и программная инфраструктура ММВБ//// Банковские технологии. Сентябрь 1998. №9/1998 с.77-82
7. Стефен Л. Нелсон MicrosoftExel 5 для Windows. Иллюстрированный краткий справочник./Пер. С англ. - М., Издательский отдел “Русская редакция” ТОО “ChannelTradingLtd.”, 1994. - 240с.: ил.
8. Р.Персон, К.Роуз Использование Word 6.0 для Windows/Пер. С англ.; Мн.: ООО “Попурри”, 1997. - 800с.: ил.