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

Содержание

Введение

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

    При
автоматизации бизнес процессов 
очень часто возникают задачи,
которые не решают уже готовые 
программы и базы данных. При этом
аналитическая информация показывает,
что даже если использовать сложные и
дорогостоящие 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 – Таблицы базы данных.

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

Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 50-34.698-90.

Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».

Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».

Ниже приведен состав руководства пользователя в соответствии с ГОСТ. Внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделен вертикальной чертой).

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

1. Введение.
2. Назначение и условия применения.
3. Подготовка к работе.
4. Описание операций.
5. Аварийные ситуации.
6. Рекомендации по освоению.

1. Введение

В разделе «Введение» указывают:

1. область применения;
2. краткое описание возможностей;
3. уровень подготовки пользователя;
4. перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю.

2. Назначение и условия применения Oracle Discoverer Plus

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

1. виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
2. условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).

3. Подготовка к работе

В разделе «Подготовка к работе» указывают:

1. состав и содержание дистрибутивного носителя данных;
2. порядок загрузки данных и программ;
3. порядок проверки работоспособности.

4. Описание операций

В разделе «Описание операций» указывают:

1. описание всех выполняемых функций, задач, комплексов задач, процедур;
2. описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.

Для каждой операции обработки данных указывают:

1. наименование;
2. условия, при соблюдении которых возможно выполнение операции;
3. подготовительные действия;
4. основные действия в требуемой последовательности;
5. заключительные действия;
6. ресурсы, расходуемые на операцию.

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

5. Аварийные ситуации

В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.

6. Рекомендации по освоению

В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ БАЗЫ ДАННЫХ «НЕВОСТРЕБОВАННЫЕ ЛИЧНЫЕ ДОКУМЕНТЫ» 

1. НАЗНАЧЕНИЕ БАЗЫ ДАННЫХ

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

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

Работа с базой данных ведется в диалоговом режиме с помощью системы меню и сопровождающих подсказок. Запуск выполнения всех команд и перемещение по экрану реализованы в соответствии со стандартами, принятыми для Access и его приложений, для чего используется клавиатура и мышь.

Пользователь БД «Невостребованные личные документы» имеет право работать в режиме «Таблицы», в режимах «Конструктор» и «Создать» работает только создатель данной базы.

Ответственный за базу данных имеет право редактирования (добавление, изменение и удаление данных – с обязательным сохранение данных при внесении изменений), пользователь на приеме граждан имеет право на поиск документов по базе – без её сохранения.

База данных позволяет выполнять операции:

-добавить в таблицу одну или несколько записей;

-удалить из таблицы одну или несколько записей;

-найти одну или несколько записей, удовлетворяющих заданному условию.

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

1.1.      ОПИСАНИЕ БАЗЫ ДАННЫХ И НАЧАЛО РАБОТЫ С НЕЙ

Запуск программы производим двойным щелчком мыши по файлу с  названием «Невостребованные личные документы».mdb на рабочем столе.

Открывается диалоговое окно, в режиме «Таблица» существует один элемент – «Трудовые книжки», выделяем его и нажимаем «Открыть».

На экране появится  окно с содержимым таблицы. В верхней части таблицы располагаются  имена полей (ячеек, расположенных в одном столбце таблицы), за которыми ниже следуют записи (строки таблицы), в которых находятся данные. Одна запись всегда является текущей и рядом с ней расположен указатель текущей записи (стрелка слева от поля «Заголовок дела» при установлении курсора на одну из записей).

Содержание таблицы.

Таблица состоит из полей: заголовок дела, № фонда, № описи, № дела, вид документа, дата:

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

-вид документа: трудовая книжка, свидетельства об образовании, о рождении; аттестаты, дипломы о среднем образовании, удостоверения;

-дата последней записи в личном документе.

Для перемещения по записям таблицы используются кнопки, расположенные на нижней границе окна таблицы:

переход на первую,

переход на предыдущую,

переход на следующую,

переход на последнюю запись

Там же находятся:  номера текущей записи (например, запись 1),

                                кнопка создания новой записи и

                     указатель общего количества записей в таблице                                        

                     (например: 91 запись всего в базе).

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

При вводе или удалении данных необходимо сохранять исправления, для этого на панели инструментов «Файл» нажать «Сохранить».

1. РАБОТА С ЗАПИСЯМИ В РЕЖИМЕ ТАБЛИЦЫ

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

2.1.      ВВОД И ИЗМЕНЕНИЕ ДАННЫХ

Основанием для ввода данных в таблицу являются  сами невостребованные личные документы или электронный вариант (Word) описи невостребованных личных документов, поступивших на хранение в архив.

Если ввод данных происходит с личного документа, то, чтобы добавить новую запись, нажмите на кнопку (новая запись)

и в поле «Заголовок дела» вводим фамилию, имя и  отчество с документа.

Переходим в другое поле «№ фонда» нажатием кнопки «Tab»:  вводим № фонда, в следующем поле – № описи, далее –  № дела.

Для удобства ввода данных в поле таблицы предусмотрена возможность создания списка подстановок, из которых можно выбирать значения для ввода в данное поле. Это применимо для поля «Вид документа». Курсором встаем на поле, справа появляется кнопка со стрелкой, нажимаем на нее, появляется список значений этого поля, выбираем из списка нужное и щелкаем на него. В следующее поле заносим дату последней записи в личном документе: например: 01.05.1995 – обязательно с точками.

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

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

Если ввод данных происходит с таблицы документа Word, то выделяем столбец таблицы Word с ФИО, нажимаем кнопку  копировать:

Встать в поле «Заголовок дела» таблицы Access и нажимаем на кнопку создания новой записи.  Заходим в меню «Правка» и нажимаем «Добавить из буфера». Программа спросит «Предпринимается попытка вставить следующее число записей: ___. Вставить записи», нажать «Да».  Второе, третье, четвертое поля заполняются вручную. Вид документа выбирается из списка. Поле «Дата» заполняется: если в  Wordе заполнен столбец  «Конечная дата», то выделяем весь столбец, а в Access выделяем нужное количество ячеек в поле «Дата», если в Wordе – 10 записей, то в Access выделяются 10 ячеек поля «Дата» и нажимаем значок на панели инструментов «Вставка»

Программа спросит: «Предпринимается попытка вставить следующее число записей ___Вставить записи», нажимаем «Да».

2.2.      ПОИСК И УДАЛЕНИЕ ДАННЫХ

2.2.1. Для поиска документа встаем в поле «Заголовок дела», на панели инструментов нажимаем значок  бинокля

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

База данных позволяет выявить наличие не одного, а нескольких личных документов конкретного заявителя. Для этого используем фильтрацию данных: выделяем ячейку «Заголовок дела» с уже найденными сведениями, нажимаем на панели инструментов значок «Фильтр по выделенному» и из всей базы данных выберется список записей с необходимой информацией. Если выдается список из нескольких записей, то проверяем, сходятся ли даты рождения и возможные другие данные по самим личным документам. После проверки нажимаем значок «Удалить фильтр», для того чтобы вернуться в режим таблицы

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

Чтобы удалить запись, встаем на любое поле этой записи, на панели инструментов заходим в «Правка» и нажимаем «Удалить запись»,  подтверждаем удаление  —   нажимаем «Да». Запись удалена и не восстановима. На расписке о выдаче документа ставим дату удаления записи из базы и подпись ответственного за базу данных.

2.3.  СОРТИРОВКА ДАННЫХ

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

Для этого установим курсор на любую строку столбца «Дата» и нажимаем на кнопку на панели инструментов: сортировка по возрастанию

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

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

Выход из программы осуществляем нажатием на «×» в правом верхнем углу окна таблицы. Аналогично закрывается и всё приложение Access.

СОГЛАСОВАНО

ЭМК МУ «Архив города Перми»

Протокол от 04.08.2005 г.  № 9