3. Каждому значению первичного ключа должна соответствовать исчерпывающая информация об объекте таблицы.
4. Изменение значения любого поля таблицы, не входящего в состав первичного ключа, не должно влиять на информацию в других полях.
Структура реляционной БД всегда разрабатывается таким образом, чтобы каждая таблица, которая в ней находится, не содержала избыточной информации. Например, в БД АРМ “Секретаря” необходимо хранить данные о входящей, исходящей и внутренней документации обследуемой организации. Как следствие, нужно хранить характеристики документа. Если для этих целей будет использоваться одна таблица, то станет очевидным нерациональное использование памяти компьютера. Поэтому информацию необходимо разбить на несколько таблиц, которые будут между собой взаимосвязаны.
При создании БД АРМ “Секретаря» необходимо создать следующие таблицы:
- Атрибуты входящих документов
- Атрибуты исходящих документов
- Индексы структурных подразделений
- Название документов
- Резолюция
- Сроки исполнения исходящих документов
- Сроки исполнения исходящих документов
- Справочник по видам документов
Перед тем, как создавать таблицы, необходимо определить их структуру: набор полей и их формат. Чтобы описать очередное поле в структуре таблицы, необходимо вначале указать название поля и после этого определить тип данных, которые будут в нем храниться. Кроме этого, можно также описать назначение информации, которая будет вводиться в это поле.
Для любой таблицы в реляционной БД должен быть задан так называемый первичный ключ, который позволяет однозначно определить ту или иную запись в таблице. Он необходим для уникальности имеющихся в таблице записей.
Логическая модель БД АРМ «Секретаря».
| Атрибут | Тип | Размер | Примечание | Ключевые поля |
| Атрибуты входящих документов | ||||
| Регистрационный номер | Числовой | 8 байт | ||
| Источник | Текстовый | До 255 байт | ||
| Ответственный исполнитель | Текстовый | До 255 байт | ||
| Контрольный срок исполнения | Дата/время | 8 байт | ||
| Контролирующее лицо | Текстовый | До 255 байт | ||
| Дата документа | Дата/время | 8 байт | ||
| Код документа | Текстовый | До 255 байт | Поле со списком | |
| Аннотация | Поле МЕМО | До 65535 байт | ||
| Контрольный срок ответа | Дата/время | 8 байт | ||
| Атрибуты исходящих документов | ||||
| Регистрационный номер | Числовой | 8 байт | ||
| Ответственный исполнитель | Текстовый | До 255 байт | ||
| Контролирующее лицо | Текстовый | До 255 байт | ||
| Дата документа | Дата/время | 8 байт | ||
| Вид документа | Текстовый | До 255 байт | Поле со списком | |
| Аннотация | Поле МЕМО | До 65535 байт | ||
| Адресат | Текстовый | До 255 байт | ||
| Дата отправки | Текстовый | До 255 байт | ||
| Название документа | ||||
| Регистрационный номер | Счетчик | 4 байт | Уникальный первичный ключ | |
| Название документа | текстовый | До 255 байт | ||
| Исходный номер документа | Текстовый | До 255 байт | ||
| Резолюция | ||||
| Название документа | Текстовый | До 255 байт | ||
| Код документа | Текстовый | До 255 байт | Поле со списком | |
| Дата документа | Дата/время | 8 байт | ||
| Дата резолюции | Дата/время | 8 байт | ||
| Автор резолюции | Текстовый | До 255 байт | ||
| Исполнитель | Текстовый | До 255 байт | ||
| Резолюция | Текстовый | До 255 байт | ||
| Дата исполнения | Дата/время | 8 байт | ||
| Дата продления исполнения | Дата/время | 8 байт | ||
| Основание продления | Текстовый | До 255 байт | ||
| Регистрационный номер | числовой | 8 байт | ||
| Сроки исполнения входящей корреспонденции | ||||
| Название документа | Текстовый | До 255 байт | ||
| Дата поступления | Дата/время | 8 байт | ||
| Ответственный исполнитель | Текстовый | До 255 байт | ||
| Контрольный срок исполнения | Дата/время | 8 байт | ||
| Действие | Логический | 1 бит | ||
| Регистрационный номер | Числовой | 8 байт | ||
| Сроки исполнения исходящей корреспонденции | ||||
| Название документа | Текстовый | До 255 байт | ||
| Ответственный исполнитель | Текстовый | До 255 байт | ||
| Действие | Логический | 1 бит | ||
| Регистрационный номер | Числовой | 8 байт | ||
| Дата исполнения | Дата/время | 8 байт | ||
| Справочник видов документов | ||||
| Вид документа | Текстовый | До 255 байт | ||
| Код документа | Текстовый | До 255 байт | Уникальный первичный ключ | |
| Индексы структурных подразделений | ||||
| Индекс подразделения | Текстовый | До 255 байт | Уникальный первичный ключ | |
| Название подразделения | Поле МЕМО | До 65535 байт | ||
Реляционную модель БД можно определить как набор отношений, связанных между собой.
Связь в данном случае – это ассоциирование двух или более отношений. БД, не имеющая связей между отношениями, имеет очень простую структуру и в полной мере реляционной называться не может. Однако одно из основных требований к организации реляционной БД – это обеспечение возможности поиска одних кортежей по значениям других, для чего необходимо установить между ними связи. Существуют следующие основные виды связей:
- один к одному;
- один ко многим;
- многие к одному;
- многие ко многим;
Связь «один к одному» предполагает, что в каждый момент времени каждому элементу А соответствует 0 или 1 элемент В.
Связь «один ко многим » состоит в том, что в каждый момент времени каждому элементу А соответствует несколько элементов В.
Связь «многие к одному» предполагает, что в каждый момент времени множеству элементов А соответствует 1 элемент В.
Связь «многие ко многим» состоит в том, что в каждый момент времени множеству элементов А соответствует множество элементов В.
В БД АРМ «Секретаря» используются связи один ко многим.
Перед установлением связей между таблицами необходимо определить тип отношения между связываемыми таблицами:
· Обеспечение целостности данных;
· Каскадное обновление связанных полей;
· Каскадное удаление связанных записей.
С учетом всего вышеизложенного, были установлены связи между таблицами и создана следующая схема данных:
Приложение Access является реляционной СУБД, которая поддерживает все средства и возможности по обработке данных, свойственные реляционным моделям. При этом информация, которую необходимо хранить в соответствующих БД, может быть представлена практически в любом формате, в частности текстовом, графическом, числовом, денежном, дата или время и т.д.
Реляционную модель можно представить как особый метод рассмотрения данных, который включает как собственно данные (в виде таблиц), так и способы работы и манипуляции с ними (в виде связей). Другими словами в реляционной модели используются несколько таблиц, между которыми устанавливаются связи. Таким образом, информация, введенная в одну таблицу, может быть связана с одной или несколькими записями из другой таблицы.
Удобной возможностью является тот факт, что пользователь при обработке данных может работать не только с БД обрабатываемого в Access формата, но и экспортировать данные других СУБД, имеющие совершенно другой формат представления.
При обработке данных в Access используется структурированный язык запросов SQL, который можно назвать стандартным языком БД.
В Access предоставляются широкие возможности по созданию приложений, связанных с обработкой БД. При этом разработчику не обязательно быть программистом высокого класса, а вполне иметь представление о создании событийных приложений в среде Windows.
СУБД Access при обработке информации рассматривает БД как набор нескольких структурных элементов, каждый из которых может включать один или несколько объектов. Среди основных составляющих БД с точки зрения Access можно выделить следующие объекты:
1. Таблицы. Представляют собой объекты, которые создаются пользователем для хранения информации о предметах или субъектах в определенной структуре. Любая таблица состоит из полей (столбцов) и записей (строк).
2. Запросы. Являются объектами, которые предназначены для получения требуемых данных из имеющихся в БД таблиц. Как правило, при создании запросов используется язык SQL. При помощи запросов можно создавать выборки данных, добавлять или удалять информацию в определенной таблице. Кроме этого, с помощью запроса возможно также создание новых таблиц на основании одной или нескольких имеющихся в БД.