Медицинское страхование

Автор работы: Пользователь скрыл имя, 03 Января 2012 в 18:54, курсовая работа

Краткое описание

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

Содержимое работы - 1 файл

Медицинское страхование1.doc

— 1.09 Мб (Скачать файл)

АННОТАЦИЯ 

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

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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

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

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

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

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

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

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

 

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

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

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

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

          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 –  Классификация связей

    Номер связи Родительская  таблица Дочерняя таблица Тип связи
    1 dolg polis 1:M
    2 type_ser polis 1:M
    3 deport polis 1:M
    4 district polis 1:M
     

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

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

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

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

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

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

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

    Информация о работе Медицинское страхование