Разработка базы данных на основе даталогического моделирования в среде MS Access

Даталогическая модель предметной области ориентирована на среду хранения и манипулирования данными. Существует огромное количество различных средств проектирования систем управления базами данных. Можно выбрать низкоуровневые программные системы разработки СУБД, высокоуровневые и автоматизированные системы разработки на основе CASE-технологий [8, с. 389].

Ранее на этапе выбора программного обеспечения нами была выбрана среда разработки СУБД MS Access. Особенность этой системы в том, что она входит в комплект MS Office, широко распространена, практична и легка в применении. Применение этой системы позволяет без особого труда проектировать реляционные СУБД. Поэтому, даталогическое моделирование выполним применительно к среде разработки СУБД MS Access.

Даталогическое проектирование является проектированием логической структуры базы данных. Но на него оказывает влияние возможности физической организации данных, предоставляемой конкретной СУБД. Поэтому даталогическое моделирование имеет 2 уровня: логический и физический уровни.

Физические модели баз данных определяют способы размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне. Среда проектирования СУБД MS ACCESS обладает надежными средствами организации хранения и доступа к данным. Поэтому вопросы физического моделирования в работе не рассматриваются, полагаясь в этом вопросе на возможности среды разработки [23, с. 82].

Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе (функциональных зависимостей между атрибутами отношений). Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей [45, с. 297]. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

- первая нормальная форма;

- вторая нормальная форма;

- третья нормальная форма;

- нормальная форма Бойса – Кодда;

- четвертая нормальная форма;

- пятая нормальная форма, или форма проекции-соединения.

Сформулируем требования при нормализации базы данных.

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

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

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

В большинстве случаев достаточно довести нормализацию базы данных до третьей нормальной формы. Более высокий уровень нормализации приводит к усложнению работы с базой данных. При проектировании базы данных для автоматизированной системы документооборота кафедры достижение третьей нормальной формы будет достаточно [44, с. 17].

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

Реляционное отношение в среде MS Access представляется в виде двумерной таблицы. Структура таблиц в MS Access разрабатывается в режиме конструктора. На этом этапе даются имена полям таблицы, устанавливается тип данных каждого поля, а также задаются ключевые поля (первичный ключ и внешние ключи). Результаты проектирования структуры таблиц приводятся в таблицах 2 – 7.

Всего в данной БД существует 6 таблиц:

1. Номенклатура дел;

2. Документы;

3. Сотрудники кафедры;

4. Подразделения института;

5. Штат кафедры;

6. Группы студентов.

Далее определим типы и размеры полей таблиц.

Таблица 2

Структура таблицы «Номенклатура дел»

В данной таблице использовались следующие типы полей:

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

Таблица 3

Структура таблицы «Документы»

В данной таблице использовались следующие типы полей:

Поле «ID» (номер по порядку) тип данных которого – счетчик. Поле, в которое при добавлении записи автоматически вводится уникальное число. Созданный для записи номер уже не может быть удален или изменен.

Текстовый – для ввода текста или комбинации текста и чисел, не требующих вычисления. Данный тип выбран для следующих полей: «КодКл», «Название подразделения», «Учебный год», «Группа», «ФИО сотрудника». Длина поля выбирается исходя из возможной длины самого длинного значения атрибута.

Дата/время – для вывода даты или времени. Данный тип удобен для поля «Дата» с кратким форматом даты.

Гиперссылка – цветной подчеркнутый текст или графический объект, по щелчку которого выполняется переход к файлу, фрагменту документа. Данный тип данных выбран для поля «Название документа».

Таблица 4

Структура таблицы «Сотрудники кафедры»

В таблице 4 использовались следующие типы полей:

Текстовый – для ввода текста или комбинации текста и чисел, не требующих вычисления. Данный тип выбран для следующих полей: «ТабНом», «ФИО», «Название должности», «Ученая степень», «Ученое звание», «Условия привлечения». Длина поля выбирается исходя из возможной длины самого длинного значения атрибута.

Таблица 5