2.2 Разработка базы данных на основе даталогического моделирования в среде ms Access
Даталогическая модель предметной области ориентирована на среду хранения и манипулирования данными. Существует огромное количество различных средств проектирования систем управления базами данных. Можно выбрать низкоуровневые программные системы разработки СУБД, высокоуровневые и автоматизированные системы разработки на основе CASE-технологий [8, с. 389].
Ранее на этапе выбора программного обеспечения нами была выбрана среда разработки СУБД MS Access. Особенность этой системы в том, что она входит в комплект MS Office, широко распространена, практична и легка в применении. Применение этой системы позволяет без особого труда проектировать реляционные СУБД. Поэтому, даталогическое моделирование выполним применительно к среде разработки СУБД MS Access.
Даталогическое проектирование является проектированием логической структуры базы данных. Но на него оказывает влияние возможности физической организации данных, предоставляемой конкретной СУБД. Поэтому даталогическое моделирование имеет 2 уровня: логический и физический уровни.
Физические модели баз данных определяют способы размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне. Среда проектирования СУБД MS ACCESS обладает надежными средствами организации хранения и доступа к данным. Поэтому вопросы физического моделирования в работе не рассматриваются, полагаясь в этом вопросе на возможности среды разработки [23, с. 82].
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе (функциональных зависимостей между атрибутами отношений). Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:
первая нормальная форма;
вторая нормальная форма;
третья нормальная форма;
нормальная форма Бойса – Кодда;
четвертая нормальная форма;
пятая нормальная форма, или форма проекции-соединения.
Сформулируем требования при нормализации базы данных.
Первая нормальная форма требует, чтобы все значения полей были атомарными и все записи уникальными.
Модель находится во второй нормальной форме, если она, во-первых, находится в первой нормальной форме; и, во-вторых, не содержит не ключевых атрибутов, находящихся в частичной функциональной зависимости от первичного ключа.
Модель находится в третьей нормальной форме, если она находится во второй нормальной форме и не имеет транзитивных зависимостей. Транзитивная зависимость – это зависимость между не ключевыми атрибутами.
В большинстве случаев достаточно довести нормализацию базы данных до третьей нормальной формы. Более высокий уровень нормализации приводит к усложнению работы с базой данных. При проектировании базы данных для автоматизированной системы документооборота кафедры достижение третьей нормальной формы будет достаточно.
Спроектировать логическую структуру базы данных означает определить все информационные единицы и связи между ними, задать их имена, задать тип далее неструктурируемых единиц.
Реляционное отношение в среде MS Access представляется в виде двумерной таблицы. Структура таблиц в MS Access разрабатывается в режиме конструктора. На этом этапе даются имена полям таблицы, устанавливается тип данных каждого поля, а также задаются ключевые поля (первичный ключ и внешние ключи). Результаты проектирования структуры таблиц приводятся в таблицах 2 – 7.
Всего в данной БД существует 13 таблиц:
Болезни;
Вид Животного;
Владельцы;
Должности;
Обращения;
Паспорт Животного;
Пол;
Порода;
Процедуры;
Реквизиты Клиники;
Склад Лекарственных Средств Оборудования;
Сотрудники;
Услуги.
Далее определим типы и размеры полей таблиц.
Таблица 2
Таблица 2
Структура таблицы «Болезни»
Имя поля | Тип поля | Примечание |
КодБолезни | Счетчик | Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются. |
НаименованиеБолезни | Текстовый | Длина 50 символов |
В данной таблице использовались следующие типы полей:
Текстовый – для ввода текста или комбинации текста и чисел, не требующих вычисления. Длина поля выбирается исходя из возможной длины самого длинного значения атрибута.
Таблица 3
- Глава 1. Анализ применения информационных систем документооборота в ветеринарии 3
- Глава 2. Проектирование информационной системы документооборота сети ветеринарных клиник 19
- Глава 3. Руководство пользователя программы 34
- Введение
- Глава 1. Анализ применения информационных систем документооборота в ветеринарии
- 1.1 Информационные системы управления
- 1.2 Описание документооборота ветеринарных клиник
- 1.3 Анализ технологии документооборота на основе диаграмм sadt (idef0)
- 1.4 Обоснование проектных решений по видам обеспечения
- Глава 2. Проектирование информационной системы документооборота сети ветеринарных клиник
- 2.1 Информационно-логическая модель предметной области на основе er
- 2.2 Разработка базы данных на основе даталогического моделирования в среде ms Access
- Структура таблицы «ВидЖивотного»
- Структура таблицы «Должности»
- Структура таблицы «ПаспортЖивотного»
- Структура таблицы «Пол»
- Структура таблицы «Порода»
- Структура таблицы «Процедуры»
- Структура таблицы «РеквизитыКлиники»
- Структура таблицы «Сотрудники»
- Структура таблицы «СкладЛекарственныхСредствОборудования»
- Структура таблицы «Услуги»
- 2.3 Функционально-структурная схема автоматизированной системы документооборота клиники
- Глава 3. Руководство пользователя программы
- 3.1 Информационное обеспечение арм
- 3.1.1 Выбор средств программирования
- 3.2 Описание программной реализации
- 3.3 Результаты реализации проекта
- Заключение
- Литература
- Приложение а