Руководство пользователю базой данных

Разработка руководства пользователя арм

При
запуска программы автоматически
открывается лист «Вход в базу данных»,
которым пользуются два типа работников:
«Начальник» и «Операторы».

После
нажатия кнопки «начальник», открывается
меню проверки, которое включает в себя
написание фамилии и пароля.

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

Только после правильного
введения фамилии и пароля, пользователь
попадает в следующее меню. Для начальника
оно выглядит так:

При
нажатии кнопки «Фамилии и пароли
операторов» появляется возможность
просматривать сколько операторов и
пароли, которыми они пользуются.

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

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

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

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

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

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

Существуют
для лёгкого поиска запросы по дате или
по номеру накладной.

Результата заносится
в таблицу таким образом.

Основные спецификации базы данных Microsoft Access

Атрибут	Максимальное значение
Размер файла базы данных Microsoft Access (.mdb)	2 Гбайт. Однако, поскольку база данных может включать связанные таблицы в других файлах, ее общий размер ограничивается только имеющимися возможностями хранения данных.
Число объектов в базе данных	32 768
Модули (включая формы и отчеты, свойство Наличие модуля (HasModule) которых имеет значение True)	1 000
Число символов в имени объекта	64
Число символов в пароле	14
Число символов в имени пользователя или имени группы	20
Число одновременно работающих пользователей	255

Если
база данных содержит программы Microsoft
Visual Basic, то при сохранении этой базы
данных Microsoft Access в виде MDE-файла будут
скомпилированы все модули, удалены все
изменяемые исходные программы, а конечная
база данных будет сжата. Программы
Visual Basic будут по-прежнему выполняться,
но их нельзя будет просматривать или
изменять, благодаря чему уменьшится
размер базы данных. Кроме того, будет
оптимизировано использование памяти,
что повысит быстродействие.

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

• Просмотр, изменение
  или создание форм, отчетов или модулей
  в режиме конструктора.

• Добавление, удаление
  или изменение ссылок на библиотеки
  объектов или базы данных.

• Изменение программы
  с помощью свойств или методов Microsoft
  Access или модели объектов VBA (MDE-файл не
  содержит текстов исходных программ).

• Импорт и экспорт форм,
  отчетов или модулей. Однако таблицы,
  запросы, страницы доступа к данным и
  макросы можно импортировать и
  экспортировать в базы данных, не
  являющиеся MDE-файлами. Любые таблицы,
  запросы, страницы доступа к данным или
  макросы в базах данных, являющихся
  MDE-файлами, могут быть импортированы в
  другую базу данных Access, но формы, отчеты
  или модули не импортируются.

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

В будущих версиях
Microsoft Access открывать, преобразовывать
или выполнять программы в MDE-файлах
Microsoft Access 2000 будет невозможно. Единственным
способом преобразования MDE-файла
Microsoft Access 2000 в формат будущих версий
будет открытие исходной базы данных
Access, в которой был создан MDE-файл, ее
преобразование и последующее сохранение
преобразованной базы данных Access в виде
MDE-файла.

Соседние файлы в папке 25 Ивлев

• #

  30.04.20131.55 Mб24вариант 25.mdb

• #

Содержание

Введение

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

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

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

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

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

    Проектирование 
БД «Страховая компания» ведется для упрощения
работы страховщика с клиентами, с договорами,
объектами страхования, с суммами выплат
по договорам, а так же со страховыми премиями.

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

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

Целями курсового 
проекта являются следующие:

1. Эффективная
   структуризация информации для экономии
   вмени и денег.
2. Исключение
   или сведение к минимуму повторяющихся
   данных путем задания эффективной структуры.
3. Обеспечение
   всем пользователям быстрый доступ к информации
   базы данных.
4. Обеспечение
   расширения базы новыми данными.
5. Обеспечение
   целостности данных для того, чтобы база
   содержала только проверенную информацию.
6. Предотвращение
   несанкционированного доступа к данным.
7. Предоставление
   доступа только к той информации, которая
   необходима для работы отдельному пользователя
   или группе пользователей.
8. Возможность
   добавления или редактирования информации
   базы данных только определенным лицам.
9. Облегчение
   создания приложений, предназначенных
   для ввода, редактирования, вывода данных,
   а так же ведения отчетности.
10. 
    Проектирование базы
    данных
1. Анализ
   предметной области

    При
проектировании базы данных необходимо
решить следующие основные проблемы:

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

В ходе
анализа предметной области необходимо:

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

    Так
как темой курсового проекта 
ставится разработка АСУ «Страховая
компания», то предметной областью моей
базы данных является страховая компания.

    Я
выделила следующие объекты данной
предметной области и их характеристики:

1. База клиентов
   – включает в себя сведения о клиентах,
   внесенных в базу данных:

• ID клиента;

• ФИО клиента;
• Пол;
• Дата рождения;
• Паспортные
  данные.

1. Сотрудники
   – включает в себя основные сведения о
   сотрудниках страховой компании:

• Код сотрудника;
• Имя;
• Фамилия;
• Адрес;
• Область;
• Дата рождения;
• Фотография.

1. Договора
   – включает в себя основные сведения о
   договорах, заключенных с клиентами страховой
   компании:

• ID;
• № договора;
• Дата заключения;
• Срок;
• ID клиентаа;
• ID объекта;
• Страховая
  премия;
• Страховая
  выплата;
• ID сотрудника.

1. Объекты страхования
   – включает в себя список объектов, которые
   может застраховать клиент страховой
   компании:

• ID;
• Объект страхования.

1. Страховые
   выплаты – включает в себя основные сведения
   о выплатах сумм, причитающихся клиентам
   по договорам:

• ID;
• Дата;
• № договора;
• Сумма выплаты.

1. Проектирование 
   инфологической, даталогической,
   физической  моделей,
   построение ER-диаграммы.

    Моделирование
данных – это процесс создания
логического представления структуры 
базы данных.

    В
настоящее время существует два 
различных подхода к моделированию 
данных:

1. Модель базы
   данных типа «сущность — связь» (entity-relationship
   model), имеющая значительное количество
   сторонников среди профессионалов;
2. Семантическая
   объектная модель (некоторые считают ее
   более простой и точной).

    При
проектировании базы данных я использовала
первый подход к моделированию данных
– «сущность — связь», так как этот подход
является более распространенным и позволяет
наиболее наглядно представить отношения
между объектами и поведение элементов
базы данных.

1. Инфологическая
   модель

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

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

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

    Инфологическая 
модель для базы данных «Библиотека»
проектировалась, как модель «Сущность-связь».

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

    Сущность
– личности, факты, объекты реального
мира, имеющие отношение к некоторой проблемной
области.

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

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

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

    Экземпляр
объекта – это один набор значений его
элементов данных.

    Связь
– это функциональная зависимость между
сущностями.

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

    Возможны 
следующие типы связей:

1. «Один к одному»
   (1:1) – каждому экземпляру сущности А соответствует
   1 или 0 экземпляров сущности В;
2. «Один ко
   многим» (1:М) – одному экземпляру сущности
   А соответствует 0, 1 или несколько экземпляров
   сущности В;
3. «Многие к
   одному» (М:1) – одному экземпляру сущности
   В соответствует 0,1 или несколько экземпляров
   сущности А;
4. «многие ко
   многим» (М:М) – 0,1 или нескольким экземплярам
   сущности А соответствует 0,1 или несколько
   экземпляров сущности В.

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

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

    В
АСУ «Страховая компания» я выделила
следующие сущности:

    —
сущность «Клиенты»

    —
сущность «Договора»

    —
сущность «Объекты страхования»

    —
сущность «Страховые выплаты»

    —
сущность «Сотрудники»

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

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

    Сущность
«Объекты страхования» содержит информацию
об объектах страхования. Отдельный экземпляр
этой сущности содержит информацию об
одном объекте. Существует связь между
сущностью «Договора» и сущностью «Объекты
страхования» типа «1:М», обязательная
со стороны сущности «Объекты страхования»
(каждому экземпляру сущности «Договора»
обязательно соответствует объект страхования
и причем только один).

    Сущность 
«Страховые выплаты» содержит информацию
о суммах страховых выплат. Между сущностью
«Страховые выплаты» и сущностью «Договора»
существует существует связь типа «1:М»,
которая означает, что страховая выплата
производится в соответствие с заключенным
договором между страховщиком и клиентом.

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

    Ключи
– уникальные идентификаторы экземпляров
каждой сущности: для сущности «Клиенты»
— это код клиента (ID), для сущности «Договора»
— код договора (ID), для сущности «Объекты
страхования» — код объекта (ID), для сущности
«Страховые выплаты » — это код выплаты
(ID), для сущности «Сотрудники» — это код
сотрудника (ID).

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

    Инфологическая 
модель АСУ «Страховая компания» имеет
следующий вид:

Рисунок
1 — Инфологическая модель базы данных
«Страховая компания» 

1. Даталогическая 
   модель

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

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

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

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

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

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

    Одно 
из требований — реляционная база
данных должна быть нормализована. Процесс 
нормализации имеет своей целью 
устранение избыточности данных и заключается
в приведении к третьей нормальной форме
(или к нормальной форме Бойса-Кодда).

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

    1
НФ – таблица должна быть 
плоской и не содержать повторяющихся 
групп. У плоской таблицы есть 
только две характеристики — длина 
(количество записей или строк) 
и ширина (количество полей или 
столбцов). Такая таблица не должна
содержать ячеек, включающих несколько
значений.

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

    3 
НФ — все не ключевые столбцы 
таблицы зависят от первичного ключа
таблицы, но независимы друг от друга.
Для этого требуется, чтобы таблицы были
приведены к 1НФ и 2НФ.

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

    5
НФ – каждая проекция, полученная
из 4 НФ, содержит не менее одного возможного
ключа и хотя бы один не ключевой атрибут
из исходного отношения.

1. Физическое
   проектирование

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

    Данные 
в таблицах Access сохраняются в определенном
формате, который называется типом данных.
Типы данных могут быть классифицированы
по четырем категориям: числовые (numeric),
символьные (character), даты (date) и BLOB.

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

    В
АСУ «Страховая компания» я использовала
следующие типы данных:

1. Текстовый
   (256 символов) – текст или числа не требующие
   проведения расчетов;
2. Числовой
   — Байт (от 0 до 255);
3. Числовой
   — Длинное целое (от -32768 до 32767);
4. Счетчик –
   уникальные последовательно возрастающие
   (на 1) или случайные числа, автоматически
   вводящиеся при добавлении каждой новой
   записи в таблицу;
5. Дата/Время
   – хранится в специальном фиксированном
   числовом формате. Дата является целой
   частью значения поля, а время его дробной
   частью;
6. Денежный
   – предназначен для хранения информации,
   выраженной в денежном эквиваленте;

1. Поле объекта
   – предназначен для хранения изображений.

Таблица
1 – структура таблиц базы данных «Страховая
компания» 

1. 
   Разработка базы
   данных

    Для
того чтобы создать таблицу необходимо
перейти на вкладку «Таблицы» и выбрать
«Создать». Выбираем «Мастер таблиц» и
жмем ОК.

    Рисунок
2 – Создание новой таблицы

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

    Рисунок
3 – Создание таблицы в режиме мастера

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

    Рисунок
4 – Создание таблица в режиме конструктора 

1. Разработка 
   схемы связей таблиц,
   нормализация базы данных 
   и приведение ее к
   НФБК

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

    Обработав
данные предметной области, я получила
реляционную схему, приведенную, к 
НФБК:

    Клиенты:
(ID, ФИО клиента, Пол, Дата рождения,
Паспортные данные);

    Договора:
(ID, № договора, Дата заключения, Срок,
ID клиента, ID объекта, Страховая премия,
Страховая выплата, ID сотрудника);

    Страховые
выплаты: (ID, Дата, № договора, Сумма
выплаты );

    Объекты
страхования: (ID, Объект страхования);

    Сотрудники:
(ID, Имя, Фотография, Фамилия, Адрес,
Область, ДатаРождения).

    Моя
база данных состоит из главной таблицы 
«Договора» и связанных с ней таблиц: Клиенты,
Объекты страхования, Страховые выплаты,
Сотрудники.

    Рисунок
5 – Таблицы базы данных.

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