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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Болезни;

2. Вид Животного;

3. Владельцы;

4. Должности;

5. Обращения;

6. Паспорт Животного;

7. Пол;

8. Порода;

9. Процедуры;

10. Реквизиты Клиники;

11. Склад Лекарственных Средств Оборудования;

12. Сотрудники;

13. Услуги.

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

Таблица 2

Таблица 2

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

Имя поля	Тип поля	Примечание
КодБолезни	Счетчик	Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.
НаименованиеБолезни	Текстовый	Длина 50 символов

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

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

Таблица 3