Разработка АРМ регистратуры учреждения здравоохранения ООО Меридиан (стр. 5 из 5)
Исполнителем должны быть разработаны:
Описание структуры системы и подсистем с указанием разработанных программных модулей, входных и выходных данных каждого модуля, связей между модулями.
Описание структур данных с указанием имен данных, типа данных, смысловой характеристики данных, связей между данными.
Руководства пользователей для всех модернизируемых подсистем
Руководство системного администратора
10. Проектирование базы данных в MSAccess
Разработку информационного обеспечения АРМ регистратора проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP.
СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.
При проектировании базы данных, в первую очередь, необходимо определить, что именно нужно хранить.
Данная СУБД была выбрана по следующим причинам:
§ простота средств реализации,
§ легкость освоения инструментарием разработчика (VBA),
§ наглядность визуализации информации.
Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:
· загрузка модулей по требованию;
· оптимизация дерева вызовов;
· использование файлов MDE;
· автоматическая поддержка компилированного состояния;
· использование библиотек Windows API;
· индивидуальная настройка системы;
· эффективное использование индексов;
· встроенный оптимизатор запросов.
Прежде чем начинать проектирования БД, необходимо провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.
Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД.
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный и требует обсуждений с заказчиком и со специалистами в предметной области. Наконец, при разработке серьезных информационных систем проект базы данных является тем фундаментом, на котором строится вся система в целом. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД.
Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.
Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не конкретного экземпляра.
Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности - сильной по отношению к ней. Например, сущность «Подчиненный» является слабой по отношению к сущности «Сотрудник»: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчинении также должны быть удалены.
Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Атрибуты используются для определения того, какая информация должна быть собрана о сущности.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность.
Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
Справочник врачей хранится в таблице VRACH, структура и правила поддержки целостности данных которой приводятся в таблицах.
Таблица 1
Таблица VRACH
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_VRACH | Integer | Primary Key | Код врача | |
| FAM_VRACH | Char | 25 | Not NULL | Фамилия врача |
| IMYA_VRACH | Char | 25 | Not NULL | Имя врача |
| OTCH_VRACH | Char | 25 | Отчество врача | |
| CODE_DOLGN | Integer | Код специализации | ||
| CODE_KABINET | Integer | Код занимаемого кабинета | ||
| CODE_TIME | Integer | Код времени приема |
Справочник пациентов хранится в таблице PACIENT, структура и правила поддержки целостности данных которой приводятся в табл. 2.
Таблица 2
Таблица PACIENT
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_ PACIENT | Integer | Primary Key | Код пациента | |
| FAM_ PACIENT | Char | 25 | Not NULL | Фамилия пациента |
| IMYA_ PACIENT | Char | 25 | Имя пациента | |
| OTCH_ PACIENT | Char | 25 | Отчество пациента | |
| CODE_VRACH | Integer | Not NULL | Код врача | |
| CODE_DATE | Integer | Код даты приема |
Данные о специализации врачей хранятся в таблице DOLGN, структура и правила поддержки целостности данных которой приводятся в табл. 3.
Таблица 3
Таблица DOLGN
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_DOLGN | Integer | Primary Key | Код специализации | |
| DOLGN | Char | 25 | Название специализации |
Для хранения данных о номерах кабинетов заполняется таблица KABINET, структура и правила поддержки целостности данных которой приводятся в табл. 4.
Таблица 4
Таблица KABINET
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_KABINET | Integer | Primary key | Код кабинета | |
| KABINET | Integer | Номер кабинета | ||
| SUMMATOR | Integer | Not NULL | Количество врачей в кабинете | |
| CODE_DOLGN | Integer | Код специализации | ||
| POLOJENIE | Char | 25 | Положение кабинета( свободен или занят) |
Для хранении данных о времени приема врача заполняется таблица TIME, структура и правила поддержки целостности данных которой приводятся в табл. 5.
Таблица 5
Таблица TIME
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_TIME | Integer | Primary key | Код времени приема | |
| TIME | Char | 25 | Время приема |
Для хранения информации о дате приема к врачу создана таблица DATE_PRIEM , структура и правила поддержки целостности данных которой приводятся в табл. 6.
Таблица 6
Таблица DATE_PRIEM
| Название | Тип данных | Размер | Ограничения | Назначение | |
| CODE_DATE | Integer | Primary Key | Код даты | ||
| DATE_PRIEM | Date | Дата приема | |||
| CODE_VRACH | Integer | Not NULL | Код врача | ||
| SUMMATOR | Integer | Количество пациентов | |||
Связи между таблицами инфологической модели
Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:
- один-к-одному (одной записи в первой таблице соответствует одна запись во второй);
- один-ко-многим (одной записи в первой таблице соответствует много записей во второй);
- много-к-одному (многим записям в первой таблице соответствует одна запись во второй);
- много-ко-многим (одной записи в первой таблице соответствует много запией во второй и одной записи во второй таблице соответствует много записей в первой).
Инфологическая модель применяется после словесного описания предметной области.
Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).
Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.
Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.
Связь «многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.
Схема данных регистратуры поликлиники
