|
|
Реляционные системы управления базы данныхСОДЕРЖАНИЕ ЗАДАНИЕ 3 ВВЕДЕНИЕ 4 1. ОСНОВЫ РЕЛЯЦИОННЫХ СУБД 5 2. ПОСТРОЕНИЕ ЛОГИЧЕСКОЙ МОДЕЛИ БАЗЫ ДАННЫХ 8 3. СОЗДАНИЕ СТРУКТУР ТАБЛИЦ 10 4. ФОРМЫ ВВОДА И РЕДАКТИРОВАНИЯ ДАННЫХ 13 5. ФОРМИРОВАНИЕ ЗАПРОСОВ 15 6. ПРОЕКТИРОВАНИЕ ОТЧЁТОВ 19 7. МАКРОСЫ 21 8. СТРУКТУРА МЕНЮ И ОСНОВНЫЕ ПРАВИЛА РАБОТЫ 24 ЗАКЛЮЧЕНИЕ 25 ЛИТЕРАТУРА 27 ПРИЛОЖЕНИЯ 28 ЗАДАНИЕ на курсовое проектирование Создайте на основе системы управления базами данных Access фрагмент системы учёта договоров страхования жизни, имущества и ответственности. Система учёта должна включать в себя несколько связанных таблиц, например: договоров (с полями, например, тип договора, фамилия, имя, отчество клиента, дата заключения договора, срок действия, сумма договора, выплаты и т.п.), клиентов (с полями, например, тип договора, фамилия, имя, отчество клиента, дата рождения, адрес, номер договора, страховая сумма и т.п.), филиалов, поступление страховых взносов, анализ работы страховой компании, агентов, справочные таблицы и т.п. Одну из таблиц обязательно создать на основе запроса на создание таблиц. Создать итоговую таблицу на основе имеющихся, включив в неё поля с помощью мастера подстановок. Все таблицы системы должны формироваться через специально разработанные формы. Обязательной для каждой работы является форма бланка страхового полиса. Вся работа системы начинается с загрузки начальной заставки и формы бланка полиса, на которой должны находиться кнопки для запуска нужных форм и одна из них загружаться как подчинённая форма. На основе разработанных таблиц и форм необходимо создать несколько типовых отчётов о договорах, клиентах, анализа работы страховой компании и т.п. Сформировать несколько разнообразных по типу запросов к системе, сохранив их, например, максимальная сумма договора, договоры одного филиала, подборка договоров по типу (жизни, имущественные, ответственности) и др. Разработанная система должна допускать возможность введения в неё новой информации, как сточки зрения данных, так и сточки зрения таблиц, запросов, отчётов и форм. Система должна включать макросы autoexec, завершения работы, печати основных отчётов (autokeys), вызова форм с помощью кнопок и др. по вашему усмотрению. Основные отчётные формы необходимо включить в отчёт по курсовой работе. Текст курсовой работы должен быть сдан в бумажном и электронном виде. ВВЕДЕНИЕ Долгое время автоматизация учреждений в России осуществлялась в виде различного рода подсистем АСУ, основанных на базах данных (кадры, канцелярия, бухгалтерия, зарплата, контроль исполнения и др.) Не умоляя значимости этих подсистем, заметим, что они охватывали лишь до 15-20% общего объема информации, циркулирующей в учреждении. Нужды по электронной обработке документов удовлетворялись применением функциональных пакетов (редакторов текста и электронных таблиц) и интегрированных пакетов программ Microsoft Office, Perfect Office, Lotus Smart Suite. Эти средства оказались недостаточными для управления огромными потоками бумажных и электронных документов, циркулирующих как внутри одного предприятия, так и между ними. В целом такой подход грешил отсутствием комплексности в автоматизации делопроизводства и управления документооборотом. В настоящее время развитие информационных технологий привело к появлению методов и средств, обеспечивающих интегрированные решения по автоматизации офиса, позволяющие автоматизировать ручные операции и поиск документов, автоматически передавать и отслеживать перемещение документов и контролировать выполнение поручений, связанных с документами. Цель данной курсовой работы - освоить основы управления и программирования реляционной СУБД на конкретной задаче, для чего в работе выполняется самостоятельное построение фрагмента автоматизированного учёта договоров страховой компании в среде СУБД Access 97. 1. ОСНОВЫ РЕЛЯЦИОННЫХ СУБД Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей базы данных, используемой для решения множества задач. Подобные системы служат для поддержания базы данных в актуальном состоянии и обеспечивают эффективный доступ пользователей к содержащимся в ней данным в рамках предоставленных пользователям полномочий. СУБД общего назначения не ориентированы на какую-либо предметную область или информационные потребности какой-либо группы пользователей. Каждая система такого рода реализуется как программный продукт, способный функционировать на некоторой дели ЭВМ в определенной операционной системе и поставляется многим пользователям с коммерческое изделие. Такие СУБД обладают средствами настройки на работу с конкретной базой данных. Использование СУБД общего назначения в качестве инструментального средства для создания автоматизированных информационных систем, основанных на технологии баз данных, позволяет существенно сокращать сроки разработки, экономить трудовые ресурсы. Этим СУБД присущи развитые функциональные возможности и даже определенная функциональная избыточность. СУБД общего назначения - это сложные программные комплексы, предназначенные для выполнения всей совокупности функций, связанных с созданием и эксплуатацией базы данных информационной системы. Используемые в настоящее время СУБД обладают средствами обеспечения целостности данных и надежной безопасности, что дает возможность разработчикам гарантировать большую безопасность данных при меньших затратах сил на низкоуровневое программирование. Продукты, функционирующие в среде WINDOWS, выгодно отличаются удобством пользовательского интерфейса и встроенными средствами повышения производительности. Остановим свой выбор на пакете Microsoft Access 97 SR-2, интегрированном в состав популярного русифицированного комплекса Microsoft Office 97. По сравнению с предыдущими версиями пакет получил принципиальные усовершенствования. В Microsoft Access 97 SR-2 добавлены некоторые средства для значительного повышения производительности. Microsoft Access без необходимости не производит загрузки программ, таких как процедуры Visual Basic для приложений и объектов доступа к данным (DAO), без которых некоторые базы данных могут обойтись. Это сокращает время загрузки базы данных и повышает полную производительность. Открытие нескольких форм и отчетов происходит теперь гораздо быстрее из-за отсутствия модулей у форм и отчетов, которые не содержат процедуры обработки событий. Для оптимизации запросов на обновление крупных объемов данных из источников данных ODBC достаточно послать на сервер запрос, обрабатывающий все соответствующие записи одновременно, вместо их последовательного перебора. До момента выполнения программы Visual Basic из модуля, в том числе из модуля формы, Microsoft Access не выполняет его загрузки. Это повышает полную производительность. Возможна поддержка откомпилированного состояния базы данных пользователя даже при ее изменении. Перекомпилируются только измененные программы и все программы, зависящие от измененных. В Microsoft Access увеличена производительность встроенных элементов ActiveX. Непосредственно база данных в Microsoft Access представляет собой один компилированный файл, названный по желанию пользователя и имеющий расширение *. mdb. Ему сопутствует одноимённый файл с записями о регистрации заблокированных записей *.ldb. Внутри база данных разбита на взаимосвязанные сегменты, выполняющие определённые им функции. Несмотря на всю мощь системы управления базами данных Ассеss 97, эта программа сделана так, чтобы работать с ней было легко. Многие проблемы, возникающие во время работы с системой, связаны с многообразием ее возможностей и с теми новыми технологиями, которые предоставляет программа, опираясь на графический интерфейс пользователя, заложенный в основу операционной системы Windows. Даже в таких простейших операциях, как установка программы и создание элементарных баз данных, существует известное число потенциально проблемных областей. Одни пользователи испытывают трудности при установке Access 97 в сетевом окружении. Другие же находят, что базы данных становятся трудно-управляемыми при заполнении их графической информацией. В Access под базой данных (database) понимается отдельный файл, содержащий различные объекты (objects) Access: таблицы, запросы, формы, отчеты, макросы и модули. Работа с базой данных и состоит в работе с этими объектами. Когда база данных открывается, на экране появляется окно База данных (Database), содержащее объекты базы. Шесть вкладок этого диалогового окна соответствуют шести видам объектов, входящим в базу данных. В зависимости от того, какая вкладка в данный момент выбрана, в окне изображаются объекты соответствующего вида. Таблицы (Tables) - это объекты, в которых непосредственно хранятся сами данные. Таблицы организованы как бухгалтерские ведомости и имеют строки и столбцы. Столбцы называются полями (/1е1а). В каждом поле может храниться информация одного типа, например фамилии людей или номера их телефонов. Строки называются записями (гесога). В каждой строке хранится информация обо всех полях, относящихся к одной записи. Например, в нее может входить фамилия, имя, адрес, город, штат, почтовый индекс и телефонный номер клиента. В современных системах управления базами данных, таких как Access, базы данных часто содержат много различных таблиц, данные в которых могут быть взаимосвязаны. Например, в базе данных, созданной для учета проката видеофильмов в небольшом салоне видеопроката, может быть одна таблица для клиентов и другая таблица для учета выданных клиентам фильмов. Запросы (Queries) предназначены для формирования вопросов, относящихся к данным, содержащимся в базе. В зависимости от того, как запрос сформирован, данные могут извлекаться из разных таблиц базы и могут комбинироваться. Например, можно создать запрос о том, сколько клиентов просрочили оплату или сколько сотрудников компании работают в ней пять лет и более. С помощью запросов можно также производить действия над группами данных, например обновлять или исключать определенные группы записей. Формы (Forms) - это специальные окна, предназначенные для облегчения просмотра существующих записей базы данных или для ввода новых записей. В Access можно создать формы, которые позволяют работать как с одной таблицей, так и со многими таблицами одновременно. Формы можно не только просматривать на экране, но и выдавать на печать. Отчеты (Reports), как и формы, служат для воспроизведения данных, но они предназначены в первую очередь для печати и не могут использоваться для ввода данных. Макросы (Маcros) служат для того, чтобы хранить в них последовательности операций в Access. Их используют для автоматизации регулярно повторяющихся действий и упрощения работы. Модули (Modules) - это процедуры, написанные на языке программирования Visual Basic для приложений (УВА). Этот язык лежит в основе Access. С помощью УВА можно написать программу, выполняющую специальные операции, которые нельзя выполнить с помощью макросов Access. Создаваемые формы, запросы и отчеты позволяют быстро и эффективно обновлять данные, получать ответы на вопросы, осуществлять поиск нужных данных, анализировать данные, печатать отчеты, диаграммы и почтовые наклейки. В базе данных сведения из каждого источника сохраняются в отдельной таблице. При работе с данными из нескольких таблиц устанавливаются связи между таблицами. Для поиска и отбора данных, удовлетворяющих определенным условиям создается запрос. Запросы позволяют также обновить или удалить одновременно несколько записей, выполнить встроенные или специальные вычисления. Для просмотра, ввода или изменения данных прямо в таблице применяются формы. Форма позволяет отобрать данные из одной или нескольких таблиц и вывести их на экран, используя стандартный или созданный пользователем макет. Для анализа данных или распечатки их определенным образом используется отчет. Например, можно создать и напечатать отчет, группирующий данные и вычисляющий итоги, или отчет для распечатки почтовых наклеек. 2. ПОСТРОЕНИЕ ЛОГИЧЕСКОЙ МОДЕЛИ БАЗЫ ДАННЫХ В базе данных требуется хранить все сведения о результатах сделок по заключению договоров страхования по разным видам страховки для определённого клиента. Перечислим все возможные элементы данных (поля), составляющие запись о заключении договора: Тип договора, номер договора, фамилия клиента, имя клиента, отчество клиента, серия паспорта, номер паспорта, паспорт выдан, адрес клиента или имущества, дата заключения договора, срок действия, сумма договора, сумма взноса, дата поступления взноса, номер филиала, название филиала, адрес филиала, телефон, директор, фамилия агента, имя агента, отчество агента, дата найма, адрес, телефон, рейтинг. КЛИЕНТ (номер договора, тип договора, код клиента, фамилия клиента, имя клиента, отчество клиента, серия паспорта, номер паспорта, паспорт выдан, адрес клиента или имущества, телефон, дата заключения договора, срок действия, сумма договора, сумма взноса, дата поступления взноса, всего поступило взносов). Первичным ключом назначаем код клиента, так как его значение уникально. Выделим элементы данных, которые могут повторяться для одного клиента, то есть они составляют повторяющуюся группу. Обозначим её RG: КЛИЕНТ (код клиента, фамилия клиента, имя клиента, отчество клиента, серия паспорта, номер паспорта, паспорт выдан, адрес клиента или имущества, телефон, RG(номер договора, тип договора, дата заключения договора, срок действия, сумма договора, сумма взноса, дата поступления взноса)). Приводим запись к первой нормальной форме, выделив повторяющуюся группу в отдельное отношение под именем ДОГОВОР: 1NF КЛИЕНТ (код клиента, фамилия клиента, имя клиента, отчество клиента, серия паспорта, номер паспорта, паспорт выдан, адрес клиента или имущества, телефон). ДОГОВОР(код клиента, номер договора, тип договора, дата заключения договора, срок действия, сумма договора, сумма взноса, дата поступления взноса). Первичный ключ для нового отношения будет составным: код клиента&номер договора Приводим это отношение ко 2-й нормальной форме, то есть проверяем, существует ли зависимость между неключевыми элементами и частью составного ключа). Такие зависимости есть: поля дата поступления взноса и сумма взноса не зависят от второй части составного ключа - кода клиента). Выделим названные поля в отдельное отношение под названием ВЗНОС: 2NF КЛИЕНТЫ (код клиента, фамилия клиента, имя клиента, отчество клиента, серия паспорта, номер паспорта, паспорт выдан, адрес клиента или имущества, телефон). ДОГОВОРА (код клиента, номер договора, тип договора, дата заключения договора, срок действия, сумма договора). ВЗНОСЫ (номер договора, сумма взноса, дата поступления взноса). Проверяем все отношения на предмет соответствия 3-й нормальной форме, то есть на предмет отсутствия зависимостей между неключевыми элементами. В данном случае таких зависимостей нет: 3NF = 2NF Нормализованная база данных будет содержать 3 таблицы: КЛИЕНТЫ ДОГОВОРА ВЗНОСЫ Дополнительно вводим в состав базы данных независимые таблицы со сведениями о филиалах страховой компании, страховых агентах и справочными материалами. ФИЛИАЛ (номер филиала, название филиала, адрес филиала, телефон, директор). АГЕНТ (фамилия агента, имя агента, отчество агента, дата найма, адрес, телефон, рейтинг). 3. СОЗДАНИЕ СТРУКТУР ТАБЛИЦ Таблицы являются сердцем баз данных. Это объекты Access, в которых хранятся все данные базы. Таблицы должны быть созданы и заполнены до создания и применения форм, запросов и отчетов. Приступая к проектированию таблиц, можно принять некоторые меры, которые впоследствии позволят упростить ввод данных. Во многих случаях процессом ввода и отображения данных можно управлять с помощью установок, выполняемых на этапе создания таблиц. А в тех случаях, когда от базы данных требуется высокая скорость выполнения поисковых операций и создание отчетов с включением в них данных из многих таблиц, при проектировании базы необходимо предусмотреть также использование в таблицах первичных ключей и индексов. Таблицы являются основой для хранения данных. Создание структуры таблицы заключается в задании ее полей, в которых данные и будут храниться. Каждое поле содержит один тип данных, например: адрес, имя, номер телефона. Таблицы состоят из записей, которые представляют собой полный набор данных об объекте. Каждый столбец является полем таблицы, а каждая строка - записью. Запроектированная база данных содержит три основных таблицы (Договора, Клиенты, Взносы), две дополнительных независимых таблицы (Агенты, Филиалы) и одну вспомогательную (Элементы кнопочной формы) (рис. 1). Рис. 1. Пример формирования структуры таблицы договора приведён в таблице 1. Аналогичным образом соответствующая структура назначена в остальных таблицах базы данных. Таблица 1 Структура таблицы Договора Поле Field Имя Name Тип Type Длина Width Примечание Index 1 Номер договора текстовый 10 2 Код клиента Числовой ключевое 3 Тип договора Текстовый 50 4 Дата заключения Дата/время 10 5 Срок Дата/время 6 Сумма Денежный Авто В соответствии с нормализованной логической моделью в схеме данных необходимо ввести связи (рис. 2). В реляционных базах данных существует три способа для задания связей между таблицами. Таблицы могут иметь связи типа один-к-одному, один-ко-многим и многие-ко-многим. Программа Ассеss 97 напрямую поддерживает только два первых типа связей, но связь типа "многие-ко-многим" можно создать косвенным путем. Для этого структура базы создается таким образом, чтобы группа таблиц, последовательно связанных отношениями "один-ко-многим", имитировала бы пару таблиц, связанных отношением "миогие-ко-многим" Основными понятиями реляционных баз данных являются понятия главная таблица и подчиненные таблицы, которые связаны с главной. Например, мы можем создать связь между таблицей Клиенты и таблицей Договора. Эта связь определяет, какими клиентами какие договора были заключены. В этом случае таблица Договора является главной таблицей, а таблица Клиенты - подчиненной. Иногда подчиненную таблицу называют "чужой" таблицей. Связывая две таблицы, мы исключаем необходимость хранения сведений о клиенте в таблице договора. Вместо этого в ней можно хранить только регистрационный код клиента, размещая его в каждой записи о сделанном заказе. Прочие данные, такие как имя и адрес клиента, необходимые для изготовления полиса или отчетов по продажам, можно получать из таблицы Клиенты. Связь "один-к-одному" определяет такое отношение между таблицами, когда каждой записи в подчиненной таблице соответствует только одна запись в главной таблице. Наличие связей между таблицами "один-к-одному" обычно не говорит о хорошей структуре базе данных, поскольку свидетельствует о том, что две таблицы имеют полностью совпадающие поля, а это ведет к нерациональному расходу дискового пространства. В большинстве случаев можно было бы просто добавить поля из подчиненной таблицы в главную и сделать одну большую таблицу. Однако встречаются ситуации, когда связь "один-к-одному" является необходимой. Связь "один-ко-многим" в структурах баз данных является наиболее общепринятой. При этом типе связи каждой записи главной таблицы соответствует одна или несколько записей в подчиненной таблице. О такой связи мы и говорили в приведенном выше примере о клиентах и их заказах. Любой клиент может заключить несколько договоров, но каждый договор относится только к одному клиенту. Структура связей типа "один-ко-многим" позволяет избежать избыточности данных и дублирования записей. Связь типа "многие-ко-многим" выражает такое отношение между таблицами, когда многие записи одной таблицы могут быть связаны со многими записями другой таблицы. Ассезз (как и многие другие системы управления базами данных на платформе IВМ РС) напрямую не поддерживает такой тип связей. Однако такую связь можно обеспечить, объединив две связи "один-ко-многим" в один запрос. Независимо от того, какой тип связи применяется, для реализации связей между таблицами нам понадобятся так называемые ключевые поля, содержащие уникальные (неповторяющиеся) данные. При наличии ключевых полей связь между таблицами устанавливается просто и эффективно. Вот почему программа Ассеss так настойчиво предлагает задать поле первичного ключа после создания новой таблицы. Рис. 2 Между таблицами Договора и Взносы вводится связь, реализующая отношение один-ко-многим по уникальному полю Номер договора, между таблицами Договора и Клиенты назначается связь по ключевому полю Код клиента. 4. ФОРМЫ ВВОДА И РЕДАКТИРОВАНИЯ ДАННЫХ В программе Ассеss формы предназначены для ввода и отображения данных. В качестве источника данных для формы можно использовать таблицы или запросы, а также их комбинации. Для отображения данных в формах используются объекты, которые называются элементами управления. Элементы управления участвуют также в оформлении внешнего вида форм. Формы особенно полезны, если приложение рассчитано на неподготовленного пользователя. Тщательное проектирование структуры позволяет создавать такие формы, которые окажут пользователю поддержку при вводе, редактировании и получении данных из вашей базы. Качественно спроектированные формы позволяют также ограничить возможность ошибок при вводе. В запроектированной базе данных используется девять форм (рис. 3). Рис. 3. Агенты - для ввода и корректировки данных таблицы личных данных страховых агентов. Взносы - для регистрации вносимых платежей. Взносы подчиненная форма - для отображения списка перечисленных платежей по определённому договору в составе формы Договора. Договора - сложная форма, оперирующая даннимы состояния дел по определённому страховому договору. Заключение договора - автоматизирует процесс занесения данных по заключаемому договору и позволяет осуществить распечатку заполненного страхового полиса. Заставка - обеспечивает 5-секундный показ рекламного логотипа фирмы при запуске базы данных. Кнопочная форма - отвечает за систему меню управления базой данных. Справка - позволяет выполнить обращение к справочным документам. Филиалы - оперирует сведениями о филиалах страховой компании. Наглядно сложная форма Договора (включающая в себя подчинённую форму) представлена на рис. 4. Рис. 4. Кнопка Печать отчёта запускает макрос вывода на принтер отображаемой на текущей момент в форме записи (приложение 5). 5. ФОРМИРОВАНИЕ ЗАПРОСОВ Эффективность применения запросов в Ассеss в значительной степени обязана использованию графической технологии, в основе которой лежит так называемый бланк запроса по образцу. Заполняя ячейки строк этого бланка, мы сообщаем программе те условия, которые должны быть использованы при обработке данных. Строки бланка запроса по образцу позволяют выбрать поля, данные из которых будут обрабатываться в запросе, выбрать порядок сортировки данных, установить режим скрытия или отображения полей в таблице, полученной по результатам работы запроса, а также задать те условия отбора, от которых зависит, какие записи будут отображены в результате. Бланк запроса по образцу содержит следующие строки. Строка Поле (Field) содержит имена полей. Ввести в нее имена нужных нам полей можно путем перетаскивания их из списка полей, помещенного в верхней области бланка запроса по образцу. Можно также выбрать имена полей из раскрывающегося списка, который появится, если щелкнуть внутри одной из ячеек строки Поле (Field). Кроме обычных полей, в строку Поле (Field) можно включить и так называемые вычисляемые поля. Они представляют собой выражения, с помощью которых по значениям одного или нескольких полей, включенных в выражение, вычисляется новое значение. Строка Сортировка (Sort) служит для задания того, каким образом будут отсортированы записи, включенные в набор записей, полученный по результатам работы запроса. Cтрока Вывод на экран (Show) определяет, будет ли это поле отображаться в результирующем наборе записей или же оно будет скрыто. Строка Условие отбора (Criteria) содержит условие, которое определяет, какие записи войдут в набор записей, а какие - нет. Существует три основных этапа в создании запроса. Сначала надо указать системе, из каких таблиц или из каких запросов будут отбираться данные. (В системе, управления базами данных Асcess запросы могут быть основаны на таблицах, на других запросах или на тех и других вместе.) После этого надо указать Access, какие поля следует включить в результат работы запроса. И наконец, надо задать порядок сортировки и условия отбора, которые должны быть использованы при отображении результата. Поиск нужной информации внутри таблиц базы данных и осуществление её выборки и представления по требуемом виде осуществляется посредством запросов, представляющих собой комплект условий отбора данных. База данных содержит пять запросов, позволяющие получить осуществить выборку информации по типу договоров, списку договоров и сумме перечисленных по заданному договору взносов (рис. 5). Рис. 5. Заполнение бланка запроса по образцу для получения списка договоров показано в качестве примера на рис. 6. Выборка данных осуществляется из двух свызанных по полю код клиента таблиц (Договора и Клиенты). Рис. 6. По такому же принципу формируются остальные запросы. Стандартным языком управления данными в реляционных СУБД является SQL, который удобно использовать при формировании запросов для выполнения задания. Записанные в форме SQL запросы выглядят следующим образом. Договора жизни SELECT Договора.[Номер договора], Договора.[Тип договора], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Телефон, Договора.[Дата заключения], Договора.Сумма FROM Клиенты INNER JOIN Договора ON Клиенты.[Код клиента] = Договора.[Код клиента] WHERE (((Договора.[Тип договора])="страхование жизни")) ORDER BY Клиенты.Фамилия; Договора имущества SELECT Договора.[Номер договора], Договора.[Тип договора], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Телефон, Договора.[Дата заключения], Договора.Сумма FROM Клиенты INNER JOIN Договора ON Клиенты.[Код клиента] = Договора.[Код клиента] WHERE (((Договора.[Тип договора])="страхование имущества")) ORDER BY Клиенты.Фамилия; Договора ответственности SELECT Договора.[Номер договора], Договора.[Тип договора], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Телефон, Договора.[Дата заключения], Договора.Сумма FROM Клиенты INNER JOIN Договора ON Клиенты.[Код клиента] = Договора.[Код клиента] WHERE (((Договора.[Тип договора])="страхование ответственности")) ORDER BY Клиенты.Фамилия; Перечислено взносов SELECT Договора.[Номер договора], Договора.[Тип договора], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Серия, Клиенты.Номер, Клиенты.Телефон, Договора.[Дата заключения], Договора.Срок, Договора.Сумма, Sum(Взносы.[Сумма взноса]) AS [Sum_Сумма взноса] FROM Клиенты INNER JOIN (Договора INNER JOIN Взносы ON Договора.[Номер договора] = Взносы.[Номер договора]) ON Клиенты.[Код клиента] = Договора.[Код клиента] GROUP BY Договора.[Номер договора], Договора.[Тип договора], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Серия, Клиенты.Номер, Клиенты.Телефон, Договора.[Дата заключения], Договора.Срок, Договора.Сумма; Список договоров SELECT Договора.[Номер договора], Договора.[Тип договора], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Договора.[Дата заключения], Договора.Срок, Договора.Сумма, Клиенты.Телефон FROM Клиенты INNER JOIN Договора ON Клиенты.[Код клиента] = Договора.[Код клиента]; Все запросы подробно можно просмотреть в прилагаемой к работе в электронной форме базе данных. 6. ПРОЕКТИРОВАНИЕ ОТЧЁТОВ Таблица, содержащая результаты выполнения запроса практически малоудобна для чтения, поэтому упорядочивание, оформление и подготовка документа к печати производиться посредством отчётов. Источником данных для отчётов могут служить как сами таблицы, так и выборки запросов. Отчеты в Асcеss содержат указания к системе управления базами данных о том, как вы хотите распечатывать данные из таблиц или запросов. Отчеты, в отличие от форм, не могут быть использованы для ввода данных. Создавать отчеты можно как вручную, так и с использованием одного из мастеров отчетов. Разделы структуры отчета Отчеты, в отличие от форм, содержат больше разделов, и для эффективной ( работы с ними необходимо хорошо понимать назначение каждого раздела и взаимосвязи между разделами. Знание того, как и в каком порядке распечатываются разделы отчета, облегчает создание удобных и практичных отчетов. Итак, отчет может содержать следующие разделы. Заголовок отчета. Этот раздел распечатывается в самом начале отчета. Верхний колонтитул. Распечатывается в верхней части каждой страницы, но ниже заголовка отчета. Заголовок группы. Выводится над областью данных первой записи каждой группы. Область данных. Содержит отдельные записи отчета. Примечание группы. Выводится под областью данных последней записи каждой группы. При проектировании в базу данных заложено пять отчётов (рис. 7). Рис. 7. Договора жизни - выводит список договоров страхования жизни (приложение 2). Договора имущества - выводит список договоров страхования имущества (приложение 3). Договора ответственности - выводит список договоров страхования имущества (приложение 4). Договора отчёт - выводит сведения по определённому договору страхования (приложение 5). Вывод результатов отчёта на печать производиться через опцию Печать главного меню Access. 7. МАКРОСЫ Макросы применяют для управления вводом данных и для упрощения работы с формами и отчетами. Возможности макросов не столь глубоки и разносторонни, как возможности процедур Visual Basic для приложений (VBA), которые обеспечивают полный набор средств программирования, но зато макросы прекрасно подходят для более простых задач. Технология создания макросов в Access существенно отличается от того, как создаются макросы в других приложениях Windows, например в Microsoft Word или Excel. В Word и Excel макросы создаются автоматической записью последовательности действий пользователя. В Access же создание макроса - это программирование запланированных действий на специальном бланке в окне Макрос. В основе концепции макросов лежат некоторые термины и понятия, которые вам следует знать, чтобы получить наибольшую пользу от ответов, приведенных в этой главе. Макрокоманда описывает действие, которое макрос должен выполнить, например открыть форму или напечатать отчет. Логическое выражение, расположенное в столбце Условие (Condition), следующим за столбцом макрокоманды, определяет, когда действие должно совершаться, а когда - нет. Если условие соблюдается, происходит выполнение макрокоманды. В противном случае макрокоманда игнорируется. Если вы хотите, чтобы одно условие относилось к нескольким макрокомандам, его достаточно ввести один раз для первой макрокоманды, а для следующих макрокоманд в столбце Условие (Condition) достаточно ввести "..." (многоточие). Макрос - это набор макрокоманд. Макрос может храниться или как отдельный объект базы данных, или как часть группы макросов - в этом случае объектом базы является группа макросов. Набор именованных макросов, хранящийся как отдельный объект базы данных, называется группой макросов. Каждый макрос в группе - должен иметь имя, которое записывается в столбце Имя макроса (Macro Name). Имя макроса записывается в строке его первой макрокоманды. Все последующие макрокоманды до следующей строки, содержащей имя макроса, относятся к одному макросу группы. Для того чтобы обратиться по имени к макросу, входящему в группу, сначала надо записать имя группы макросов, а затем через точку записать имя макроса в группе. Макрос - это список автоматически выполняемых заданий, поэтому для любой задачи, которая выполняется достаточно регулярно, имеет смысл рассмотреть возможность создания макроса. Это может быть открытие и закрытие форм, печать отчетов и задание значений элементов управления в формах. Имена макросов приводятся в столбце Имя макроса (Macro Name). В той же строке приводится первая макрокоманда макроса. Если окно макроса содержит только один макрос, а не группу, столбец Имя макроса пуст и может не отображаться. Столбец Условие (Condition) содержит те условия, которые определяют, нужно ли выполнять макрокоманду, указанную справа. Столбец Макрокоманда (Action) содержит инструкцию, которая подлежит исполнению. При перемещении по строкам в верхней половине окна в его нижней половине отображаются аргументы макрокоманды. Создание макросов выполняется в окне макросов (рис.8). Для создания макроса руководствуемся следующим порядком действий. 1. В окне База данных (Database) открываем вкладку Макросы (Macros). 2. Щелкните на кнопке Создать (New). Откроется окно Макрос1:макрос. Рис. 8. 3. В окне макроса щелкнуть на первой пустой строке в столбце Макрокоманда (Action). 4. В ячейку строки ввести нужную макрокоманду или выбрать ее из раскрывающегося списка, щелкнув на раскрывающей кнопке. 5. Ввести необходимые примечания в столбец Примечание (Comment) в той же самой строке, в какой записана макрокоманда. 6. Щелкнуть в нижней части диалогового окна (или нажать клавишу F6). Задайте необходимые аргументы макрокоманды. 7. Сохранить макрос командой Файл ? Сохранить (File ? Save). Разработанная в качестве примера СУБД содержит 15 макросов, которым назначены соответствующие элементы управления (кнопки) в соответствующих формах (рис. 9). Рис. 9. Autoexec - автоматически исполняется при загрузке базы данных, обеспечивает загрузку рекламного логотипа страховой компании. Autokeys - дублирует функции кнопок печати специальным сочетанием клавиш: Ctrl + P для печати полиса, Ctrl + О для печати отчёта по договору. Закрыть заставку - выполняет закрытие заставки по истечении установленной выдержки таймера (5 секунд) с переходом в главное кнопочное меню базы данных. На весь экран - обеспечивает вывод некоторых форм на экран в развёрнутом виде. Отчёт по договорам - выводит на печать сведения о договоре, отображаемом в данный момент в форме. Печать полиса - выводит на печать заполненный в форме официальный бланк полиса. Кнопки - открывает справочную форму. Остальные макросы обеспечивают открытие справочного документа в сооветствующем приложении, в данном случае - в текстовом процессоре. 8. СТРУКТУРА МЕНЮ И ОСНОВНЫЕ ПРАВИЛА РАБОТЫ Файл базы данных прилагается к курсовому проекту на дискете 3,5" и выполнен в виде самораспаковывающегося архива. Распаковку архива нужно производить на логический диск С:, это обусловлено жёсткой привязкой файлов справочной документации к структуре каталогов, в противном случае нужно переназначить пути ссылок в соответствующих макросах на новый путь к файлам программы. Для запуска программы необходимо наличие на компьютере операционной системы Windows 95, 98, 2000 или МЕ, а также СУБД ACCESS 97, 2000. После запуска программы на экране в течении 5 секунд демонстрируется рекламный логотип страховой компании, по истечении временного интервала заставка закрывается и пользователь получает доступ к главному меню. Структура меню построена по принципу многоуровневой кнопочной формы и графически представлена на рис. 10. Функциональные возможности всех элементов управления соответствуют нанесенным на них надписям. Рис. 10. Пополнять или изменять сведения в базе данных можно в соответствующих формах. Вносимые данные должны соответствовать типу (текст, число, дата) и не содержать некорректных значений (отрицательных чисел, несуществующих дат и т.п.). Возврат из формы осуществляется нажатием кнопки ОК. Структура базы данных не защищена, поэтому программа доступна для внесения любых изменений, поправок и дополнений. ЗАКЛЮЧЕНИЕ В индустрии управления документами наблюдаются динамичные изменения. Потребности пользователей постоянно растут, в связи с этим появляются все новые и новые технологии, и дистрибьюторы не упускают шанс поставить на них. Наряду с технологиями, передовые аппаратные средства, а также стратегические альянсы на рынке диктуют новый подход к накоплению данных в организациях и выдвигают дополнительные требования к обработке информации. По моему мнению, одно из основных изменений, которое имеет место в области управления документами, - это тенденция к единению, т. е. объединение документов и содержащихся в них данных. Налицо тот факт, что все большее количество документов изначально рождается в электронном виде. Такие технологии, как обмен электронными данными (EDI), intranet и цифровая подпись, размывают границы между данными, документами и записями. Они ликвидировали необходимость "вырабатывать" заполненные информацией листы бумаги. Данные для бизнес-транзакций создаются в электронном виде, поэтому бумага как промежуточный шаг в осуществлении транзакции больше не используется. Несмотря на то что есть типы документов, например факсы или образы (images), где данные безнадежно переплетаются с формой, я полагаю, что значение их в дальнейшем будет падать, и в качестве центральной точки информационных систем, на которой следует сфокусировать внимание, можно принять сервер баз данных. Сейчас на горизонте появляется технология цифровой подписи, которая призвана обеспечить авторизацию электронных документов. Сообщение - это оцифрованный отпечаток зашифрованного содержания. Цифровая подпись сообщения означает, что документ не был изменен во время передачи. Узаконивание электронной авторизации уже близко. Предыдущие различия между управлением данными, управлением документами, информацией и записями в структурированных бизнес-транзакциях, по всей видимости, становятся менее заметными. База данных формирует единый репозитарий и является фокусом всей структурированной деловой информации. Технология реляционных баз данных, как часть корпоративной информационной технологии, уже имеет устойчивое положение и находит себе достойное применение. Структурированные документы/записи (транзакции) станут одной из областей систем управления базами данных. На сегодняшний день доступны четыре метода управления электронными документами: "родная" файловая система, системы управления реляционными базами данных (RDBMS), системы управления объектно-ориентированными базами данных (OODBMS) и системы управления объектно-реляционными базами данных (ORDBMS). Ведущие производители технологий баз данных сконцентрировали усилия на объектно-реляционной технологии, которая позволяет новым системам работать со сложными типами данных, какими являются электронные документы. Говоря о новых тенденциях развития баз данных, ориентированных на индустрию управления документами, нельзя игнорировать такую важную деталь, как поиск и вывод информации. ЛИТЕРАТУРА Джонс Э., Джонс Дж. М. Access 97 - СПб.: Питер, 1998. Закис А. Технология создания и кастомизации офисных информационных систем. М.: DataX/Florin, 1999. Информатика: учебник / под. ред. проф. Н.В. Макаровой. - М.: Финансы и статистика, 1997. Том Д. Эволюция документных баз данных. - М.: ЭлисКом, 1999. Хенсем Г., Камарга Б. Базы данных: реализация и управление. - М.: Финансы и статистика, 1995. Приложение 1 Страховая компания "Феникс" Р/с N 7467525 в ОПУ Промстройбанка России, МФО 299082 Корр. счет N 468161500 в РКЦ ГУ ЦБ РФ, Москва, МФО 201791 Россия, 129226, Москва, ул. Сельскохозяйственная, 12А Тел. (095) 181-86-29. Факс (095) 181-50-25 СТРАХОВОЙ ПОЛИС № 000004 страхование ответственности Страхователь Васильев Степан Алексеевич Паспорт: серия XII-РУ № 623852 Выдан: Кунцевский РОВД г. Москвы 17 июля 1975 г. Адрес: г. Москва, Полесский проезд, 14, кв. 62 Телефон: 175-15-53 Сумма договора 1 900 000,00р. Вступительный платеж на расчетный счет Страховщика внесён. 25 октября 1999 г. Остальные платежи должны быть внесены до 25 октября 2004 г. Страхователь с Правилами страхования ознакомлен. Страхователь От имени и по поручению Страховщиков ______________________ _______________________ (подпись) (подпись) МП МП Приложение 2 Список договоров по страхованию жизни Номер договора Тип договора Фамилия Имя Отчество Телефон Дата заключения Сумма 000005 страхование жизни Куклева Татьяна Владимировна 175-98-16 14 января 2001 г. 250 000,00р. 000006 страхование жизни Серебряков Афанасий Павлович 245-78-89 25 июля 1999 г. 400 000,00р. 000010 страхование жизни Трубецкова Светлана Васильевна 156-85-95 15 июля 2000 г. 600 000,00р. ИТОГО: 1 250 000,00р. 19 января 2001 г. Страница 1 из 1 Приложение 3 Список договоров по страхованию имущества Номер договора Тип договора Фамилия Имя Отчество Телефон Дата заключения Сумма 000002 страхование Крылова Анна Вениаминовна 403-84-79 16 января 2000 г. 900 000,00р. имущества 000003 страхование Королькова Инесса Львовна 402-56-79 28 марта 2000 г. 1 500 000,00р. имущества 000007 страхование Прохорова Зинаида Петровна 146-54-56 12 апреля 1998 г. 2 000 000,00р. имущества ИТОГО: 4 400 000,00р. 19 января 2001 г. Страница 1 из 1 Приложение 4 Список договоров по страхованию ответственности Номер договора Тип договора Фамилия Имя Отчество Телефон Дата заключения Сумма 000001 страхование Иванов Иван Иванович 405-18-92 13 января 2001 г. 10 000,00р. ответственности 000004 страхование Васильев Степан Алексеевич 175-15-53 25 октября 1999 г. 1 900 000,00р. ответственности 000008 страхование Ивашинцев Артём Васильевич 410-56-92 15 ноября 2000 г. 300 000,00р. ответственности 000009 страхование Коломиец Илья Фёдорович 156-56-31 12 октября 1999 г. 500 000,00р. ответственности ИТОГО: 2 710 000,00р. 19 января 2001 г. Страница 1 из 1 Приложение 5 Отчет о состоянии дел по договору страхования Номер договора Тип договора 000005 страхование жизни Фамилия Имя Отчество Телефон Куклева Татьяна Владимировна 175-98-16 Дата 14 января 2001 г. Срок 14 января 2006 Сумма 250 000,00р. Перечислено платежей: 41 800,00р. 19 января 2001 г. Страница 1 из 1 2 Работа на этой странице представлена для Вашего ознакомления в текстовом (сокращенном) виде. Для того, чтобы получить полностью оформленную работу в формате Word, со всеми сносками, таблицами, рисунками, графиками, приложениями и т.д., достаточно просто её СКАЧАТЬ.  |
|
Банк готовых работ
Форма заказа
Скачать работу
экономические  Copyright © refbank.ru 2005-2024
Все права на представленные на сайте материалы принадлежат refbank.ru. Перепечатка, копирование материалов без разрешения администрации сайта запрещено. |
|