Автоматизированное рабочие место работника регистратуры районной поликлиники

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

     Сущность  имеет имя, уникальное в пределах модели. При этом имя сущности –  это имя типа, а не конкретного экземпляра.

     Сущности  подразделяются на сильные и слабые. Сущность является слабой, если ее существование  зависит от другой сущности – сильной  по отношению к ней. Например, сущность «Подчиненный» является слабой по отношению  к сущности «Сотрудник»: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчинении также должны быть удалены.

     

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

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

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

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

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

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

Справочник  врачей хранится в таблице Doctors, структура и правила поддержки целостности данных, которой приводятся в таблицах.

     Справочник  пациентов хранится в таблице, структура  и правила поддержки целостности данных, которой приводятся в табл. 2.

     Данные  о специализации врачей хранятся в таблице kl_dolqn, структура и правила поддержки целостности данных, которой приводятся в табл. 3 

 

     Для хранения данных о номерах кабинетов  заполняется таблица kabinets, структура и правила поддержки целостности данных, которой приводятся в табл. 4.

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

     Для хранении данных о времени приема врача заполняется таблица Raspisahie, структура и правила поддержки целостности данных, которой приводятся в табл. 6. 

     2.2 Связи между сущностями инфологической модели

     Разработку  информационного обеспечения АРМ  проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP.

     СУБД Access предназначена для разработки баз данных реляционного типа для  локального их использования на персональных компьютерах и для работы с этими базами.

     При проектировании базы данных, в первую очередь, необходимо определить, что именно нужно хранить.

     Данная  СУБД была выбрана по следующим причинам:

• простота средств реализации,
• легкость освоения инструментарием разработчика (VBA),
• наглядность визуализации информации.

     Также «Microsoft Access» предоставляет большое  количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:

• загрузка модулей по требованию;
• оптимизация дерева вызовов;

     

• использование файлов MDE;
• автоматическая поддержка компилированного состояния;
• использование библиотек Windows API;
• индивидуальная настройка системы;
• эффективное использование индексов;
• встроенный оптимизатор запросов.

     Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений  между таблицами:

     - один-к-одному (одной записи в  первой таблице соответствует  одна запись во второй);

     - один-ко-многим (одной записи в  первой таблице соответствует  много записей во второй);

     - много-к-одному (многим записям в  первой таблице соответствует  одна запись во второй);

     - много-ко-многим (одной записи в  первой таблице соответствует  много запией во второй и одной записи во второй таблице соответствует много записей в первой).

     Инфологическая  модель применяется после словесного описания предметной области.

     Между сущностями могут быть установлены  связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся  или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности

     Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).

     Связь один-ко-одному означает, что экземпляр  одной сущности связан только с одним  экземпляром другой сущности.

     

     Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный  слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.

     Связь «многие-ко-многим (М:М) означает, что  несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.

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

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

ЗАКЛЮЧЕНИЕ

      Цель курсового проектирования полностью достигнута. 

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

     Инфологическая  модель применяется на втором этапе  проектирования БД, то есть после словесного описания предметной области. Процесс  проектирования длительный и требует обсуждений с заказчиком и со специалистами в предметной области. Наконец, при разработке серьезных корпоративных информационных систем проект базы данных является тем фундаментом, на котором строится вся система в целом, и вопрос о возможном кредитовании часто решается экспертами банка на основании именно грамотно сделанного инфологического проекта БД. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, оно не должно быть привязано к конкретной СУБД. Выбор СУБД – это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.

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

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

     В результате анализа базы данных было выполнено:

     - выявлена сущность инфологической  модели и моделирование связей  между ними;

     - построение набора таблиц базы  данных и нормализация базы;

     - описание внешних моделей в  терминах выбранной СУБД;

     - реализация базы данных и организация запросов в выбранной СУБД;

     - реализация программного интерфейса  к базе данных.

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

 
 
 
 
 
 
 
 
 
 
 
 
 

БИБЛИОГРАФИЯ 

1. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002. – СПб.: БХВ-СПб., 2003. – 720 с.
2. Виноградова И.А., Грибова Е.А., Зубков В.Г. Практикум на ЭВМ. MS Access: Учебное пособие для студентов заочной (дистанционной) формы обучения. – М.: ГИНФО, 2000. – 124 с.
3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.
4. Информатика. Базовый курс. /Под ред. С.В.Симоновича. – СПб.: Питер, 1999. – 640 с.
5. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2002. – 304 с.
6. Петров В.Н. Информационные системы. – СПб.: Питер, 2003. – 688 с.