АННОТАЦИЯ 

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

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

     В данном курсовом проекте была разработана база данных «Медицинское страхование» в СУБД Visual FoxPro 9.0. Программа, работающая с БД, позволяет вести учет клиентов ателье  и дает возможность сформировать отчеты по различным категориям.

     Выбор FoxPro обусловлен прежде всего разносторонностью  этой СУБД, удобством как для разработчика приложений, так и для обычного пользователя. Наличие в ней языка программирования позволяет создавать сложные системы обработки данных, ориентированные на конкретные задачи и даже под конкретного пользователя. С другой стороны, в ней отражены и в разной мере используются многие современные технологии программирования: ActiveX, COM, SQL, OLE, API и многое другое.

     Пользователями  БД выступают служащие ателье, регистрирующие клиентов.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     1.Обследование  предметной области. 

     Предметной  областью называется фрагмент реальности, который описывается или моделируется с помощью БД и ее приложений. В предметной области выделяются информационные объекты – идентифицируемые объекты реального мира, процессы, системы, понятия и т.д., сведения о которых хранятся в БД.

     В результате в БД «Медицинское страхование» используются следующие входные данные:

• информация о сотрудниках медицинского страхования,
• информация об отделах медицинского страхования,
• информация об уровне сервиса медицинского страхования,
• информация о районах медицинского страхования,
• информация о полисах медицинского страхования.

     Выходными данными являются выходные запросы, формы и отчеты. Информация выводится  на экран в специальных формах, упрощающих работу с записями таблиц БД. На формах реализован поиск, с помощью  которого пользователь может получить нужную информацию.

2. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ

     В проекте «Медицинское страхование» главной таблицей является «Полисы». Если таблицу не разбивать на подтаблицы, то можно наблюдать избыточность данных, а это недопустимо. В соответствии с предметной областью были созданы таблицы:

• «Полисы» - хранится информация о полисах медицинского страхования.
• «Должности» - хранится информация о должностях сотрудников медицинского страхования;
• «Отделы» - хранится информация об отделах медицинского страхования.
• «Уровень сервиса» - хранится информация об уровне сервиса медицинского страхования.
• «Районы» - хранится информация о районах медицинского страхования.

      2.2 Перечень атрибутов

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

     1. Таблица polis (Полис) содержит:

• polis_id– уникальный код полиса;
• date_polis – дата выдачи полиса;
• polis_n –– наименование полиса;
• people_fio– инициалы сотрудника;
• district_id– уникальный код района;
• depart_id– уникальный код отдела;

• 2. Таблица  dolg (Должности) содержит:
• dolg _id – уникальный код должности сотрудника ;
• dolg _name–наименование должности сотрудника;
• dolg _adress – адрес  сотрудника;
• dolg _telefone – телефон  сотрудника.

     3. Таблица type_serv (Уровень сервиса) содержит:

• type_serv _id – уникальный код сервиса;
• type_serv_name– наименование сервиса;
• type_serv_number– номер сервиса.

     4. Таблица district (Район) содержит:

• district_id – уникальный код района;
• district _name – название района;
• district _kod – код района;
• district _adress – адрес района.

     5. Таблица depart (Отдел) содержит:

• depart_id – уникальный код отдела ;
• depart_name– наименование  отдела;
• depart_telefone–телефон отдела;
• depart_adress– адрес отдела.

3. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ  БД

     Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

     Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.

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

     Абсолютное  различие между типами сущностей  и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность.

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

     Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

     При определении инфологической модели необходимо принимать во внимание следующее:

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

     3.1 Модель «сущность  - связь»

      Модель  «сущность - связь» основана на использовании 3-х основных конструктивных элементах:

1. Сущность.
2. Атрибут.
3. Связь.

      Взаимосвязи между таблицами БД могут быть типизированы по следующим основным видам:

1. Отношение “один к одному” (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;
2. Отношение “один ко многим” (1:М) возникает, когда одна запись взаимосвязана со многими другими;
3. Отношение “многие к одному” означает, что многие записи связаны с одной (М:1);
4. Отношение “многие ко многим” (M:N) возникает между двумя таблицами в тех случаях, когда:

• Одна  запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

• Одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

      Недостатком данной модели является то, что одни и те же элементы могут выступать одновременно и в качестве сущности, и в качестве атрибута, и в качестве связи. В данном случае, будем считать, что каждый объект может выступать только в качестве одного конструктивного элемента. Схема модели «сущность-связь» приведена в Приложении А.

3.2 Классификация  связей

     В своей курсовой работе я использовал  следующие типы связей (Таблица 3.2.1):

Таблица 3.2.1 –  Классификация связей

     Таблица 3.2.1 показывает классификацию связей между таблицами.  Связь  под  номером один, между таблицами  «dolg – polis». Один сотрудник может выдать несколько полисов.

Вторая связь имеет тип «1:M» «type_ser –polis».Один уровень сервиса может быть предоставлен по нескольким полисам.

 Третья  связь «deport –polis». Один отдел может выдать несколько полисов.

Четвертая связь «district–polis» По одному району может быть выдано несколько полисов.

5.РЕЛЯЦИОННАЯ МОДЕЛЬ БД

В реляционных  базах данных вся информация сведена  в таблицы, строки и столбцы которых  называются записями и полями соответственно. Эти таблицы получили название реляций . Записи в таблицах не повторяются. Их уникальность обеспечивается первичным ключом, содержащим набор полей, однозначно определяющих запись. Для быстрого поиска информации в базе данных создаются индексы по одному или нескольким полям таблицы. Значения индексов хранятся в упорядоченном виде и содержат ссылки на записи таблицы. Для автоматической поддержки целостности связанных данных, находящихся в разных таблицах, используются первичные и внешние ключи. Для выборки данных из нескольких связанных таблиц используются значения одного или нескольких совпадающих полей.

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

4.1 Функциональные зависимости между атрибутами

      В разработанной базе данных «Медицинское страхование» существуют следующие функциональные зависимости между атрибутами:

   Таблица 4.1.1 dolg (Должности)

     Таблица 4.1.2 polis (Полисы)

     Таблица 4.1.3 type_serv (Уровень сервиса)

     Таблица 4.1.4 district (Район)

     Таблица 4.1.5 depart (Отдел)

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

4.2 Выбор ключей

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

     Использование ключей и индексов позволяет:

      – Однозначно идентифицировать записи;

      – Избегать дублирования значений в ключевых полях;

      – Выполнять сортировку таблиц;

      – Ускорять операции поиска в таблицах;

      – Устанавливать связи между отдельными таблицами БД.

      – При поддержке целостности данных обеспечивается правильность ссылок между таблицами.

     Таблица 4.2.1 Ключи

4.3 Нормализация отношений

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

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

    Проведем  нормализацию имеющихся сущностей.

    Таблица в первой НФ требует, чтобы все значения всех атрибутов были атомарны. Другими словами, каждый атрибут отношения должен хранить одно-единственное значение и не являться ни списком, ни множеством значений.

Все таблицы  находятся в первой нормальной форме, так как все атрибуты в них  атомарны.

    В контексте БД «Охрана обьектов» данные понятия являются атомарными, и их деление на составные части не имеет смысла, т.к. только внесет в БД излишнюю громоздкость.

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

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

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

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

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

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

5. ДАТАЛОГИЧЕСКОЕ  ПРОЕКТИРОВАНИЕ БД

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

5.1 Состав таблиц  БД

Таблица 5.1.1 dolg

Таблица 5.1.2 Polis

Таблица 5.1.3 Type_serv 

Таблица 5.1.4 District 

Таблица 5.1.5 Depart