Автор работы: Пользователь скрыл имя, 03 Января 2012 в 18:54, курсовая работа
В данном курсовом проекте была разработана база данных «Медицинское страхование» в СУБД Visual FoxPro 9.0. Программа, работающая с БД, позволяет вести учет клиентов ателье и дает возможность сформировать отчеты по различным категориям.
Выбор FoxPro обусловлен прежде всего разносторонностью этой СУБД, удобством как для разработчика приложений, так и для обычного пользователя. Наличие в ней языка программирования позволяет создавать сложные системы обработки данных, ориентированные на конкретные задачи и даже под конкретного пользователя. С другой стороны, в ней отражены и в разной мере используются многие современные технологии программирования: ActiveX, COM, SQL, OLE, API и многое другое.
Пользователями БД выступают служащие ателье, регистрирующие клиентов.
В разработанной базе данных «Медицинское страхование» существуют следующие функциональные зависимости между атрибутами:
Таблица 4.1.1 dolg (Должности)
| Наименование атрибутов | Функциональные
зависимости |
| dolg
_id
dolg _name dolg_adress dolg_telefone |
Таблица 4.1.2 polis (Полисы)
| Наименование атрибутов | Функциональные
зависимости |
| polis_id
date_begin date_polis polis_n people_fio district_id dolg_id depart_id type_serv-id adres |
Таблица 4.1.3 type_serv (Уровень сервиса)
| Наименование атрибутов | Функциональные
зависимости |
| type_serv_id
type_serv _name type_serv _number |
Таблица 4.1.4 district (Район)
| Наименование атрибутов | зависимости |
| district
_id
district _name district _kod district _adress |
Таблица 4.1.5 depart (Отдел)
| Наименование атрибутов | Функциональные
зависимости |
| depart_id
depart_name depart_telefon depart_adress |
Во всех таблицах неключевые атрибуты нетранзитивно зависят от первичного ключа и независимы между собой.
Ключ
– минимальный набор атрибутов, по значениям
которых можно однозначно найти требуемый
экземпляр сущности. Минимальность означает,
что исключение из набора любого атрибута
не позволяет идентифицировать сущность
по оставшимся.
Использование ключей и индексов позволяет:
– Однозначно идентифицировать записи;
– Избегать дублирования значений в ключевых полях;
– Выполнять сортировку таблиц;
– Ускорять операции поиска в таблицах;
– Устанавливать связи между отдельными таблицами БД.
– При поддержке целостности данных обеспечивается правильность ссылок между таблицами.
Таблица 4.2.1 Ключи
| Таблица | Ключ | Тип ключа |
| polis | type_serv | regular |
| polis | depart_id | regular |
| polis | dolg_id | regular |
| polis | district_id | regular |
| polis | polis_id | primary |
| dolg | dolg_id | primary |
| type_serv | type_serv_id | primary |
| district | district_id | primary |
| depart | depart_id | primary |
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных.
В теории нормализации существует пять нормальных форм таблиц. Эти формы предназначены для уменьшения избыточной информации от первой до пятой нормальной формы. Поэтому каждая последующая НФ должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям.
Проведем нормализацию имеющихся сущностей.
Таблица в первой НФ требует, чтобы все значения всех атрибутов были атомарны. Другими словами, каждый атрибут отношения должен хранить одно-единственное значение и не являться ни списком, ни множеством значений.
Все таблицы находятся в первой нормальной форме, так как все атрибуты в них атомарны.
В контексте БД «Охрана обьектов» данные понятия являются атомарными, и их деление на составные части не имеет смысла, т.к. только внесет в БД излишнюю громоздкость.
Таким образом, можно сказать, что все таблицы находятся в первой нормальной форме.
Таблица находится во второй НФ, если она удовлетворяет условиям первой НФ, и каждый не первичный атрибут полностью функционально зависит от ключа. Все таблицы находятся во второй нормальной форме, так как в них отсутствуют составные ключи.
Таблица находится в третьей НФ, если она удовлетворяет условиям второй НФ, и каждый не первичный атрибут не транзитивно зависит от ключа.
Другими словами чтобы привести отношение к 3НФ, необходимо устранить функциональные зависимости между неключевыми атрибутами отношения. Другими словами, факты, хранимые в таблице, должны зависеть только от ключа.
Так как в пункте 4.1 данного курсового проекта было подробно проанализирована каждая из таблиц, и транзитивной зависимости не было выявлено, можно сделать вывод, что все таблицы находятся в третьей нормальной форме, каждый неключевой атрибут в таблицах не транзитивно зависит от первичного ключа.
При решении практических задач в большинстве случаев третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к третьей нормальной форме. Данная модель не нуждается в дальнейшем приведении к четвертой и следующим формам нормализации.
В этом разделе приводится состав таблиц БД. Для каждого поля таблицы указывается размер поля (количество символов), тип. Для первичных ключей необходимо ввести запрет неопределенных значений. Для остальных полей возможность запрета неопределенных значений определяется семантикой предметной области.
Таблица 5.1.1 dolg
| Наименование атрибутов | Тип полей | Размер полей | Допустимость
неопределенных значений |
| dolg_id | Integer | 4 | Not null |
| dolg_name | Character | 50 | Not null |
| dolg_adress | Character | 50 | Not null |
| dolg_telefone | Character | 50 | Not null |
Таблица 5.1.2 Polis
| Наименование атрибутов | Тип полей | Размер полей | Допустимость
неопределенных значений |
| polis_id | Integer | 4 | Not null |
| date_polis | Date | 8 | Not null |
| polis_n | Character | 20 | Not null |
| people_fio | Character | 50 | Not null |
| district | Integer | 4 | Not null |
| dolg_id | Integer | 4 | Not null |
| depart_id | Integer | 4 | Not null |
| type_serv_id | Integer | 4 | Not null |
| adres | Character | 250 | Not null |
Таблица
5.1.3 Type_serv
| Наименование атрибутов | Тип полей | Размер полей | Допустимость
неопределенных значений |
| Type_serv_id | Integer | 4 | Not null |
| Type_serv_name | Character | 50 | Not null |
| Type_serv_number | Character | 50 | Not null |
Таблица
5.1.4 District
| Наименование атрибутов | Тип полей | Размер полей | Допустимость
неопределенных значений |
| district_id | Integer | 4 | Not null |
| district_name | Character | 50 | Not null |
| district_adress | Character | 50 | Not null |
| district_kod | Character | 50 | Not null |
Таблица 5.1.5 Depart
| Наименование атрибутов | Тип полей | Размер полей | Допустимость
неопределенных значений |
| depart_id | Integer | 4 | Not null |
| depart_name | Character | 50 | Not null |
| depart_telefone | Character | 50 | Not null |
| depart_adress | Character | 50 | Not null |