На сегодняшний день наиболее широкое распространение получила модель Чена «Сущность-связь» (Entity Relationship), она стала фактическим стандартом в инфологическом моделировании, и получило название ER – модель.

Выбор СУБД осуществляется на основе различных требований к БД и, соответственно, возможностей СУБД, а также в зависимости от имеющегося опыта разработчиков.

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

Для ликвидации возможных аномалий предполагается проведение нормализации отношений БД.

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

• 
  Описание концептуальной схемы БД в терминах выбранной СУБД.
  
• 
  Описание внешних моделей в терминах выбранной СУБД.
  
• 
  Описание декларативных правил поддержки целостности БД.
  
• 
  Разработка процедур поддержки семантической целостности БД.
  

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

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

---

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

С другой стороны могут использоваться преимущества многопроцессорных систем.

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

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

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

1.3 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ

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

Анализ предметной области сводится к рассмотрению организационной сущности задачи получения пациентом талона на прием к врачу при посещении лечебного учреждения (рисунок 2).



Рисунок 2 - Организационная модель предметной области

Организационная сущность задачи заключается в следующем.

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

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

Пациент, имея на руках амбулаторную карту и талон, следует на прием к врачу, где, как правило, приходится повторно стоять в очереди.

Врач проводит осмотр пациента, производит необходимые записи в амбулаторной карте и в случае необходимости, помимо назначений на лечение, выписывает рецепт на получение или изготовление лекарственных средств. Помимо этого врач производит дозаполнение талона на прием статистической информацией.

---

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

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

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

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

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

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

Исходя из концепции деления системы на Front-офис и Back-офис, провести разделение проекта на две части: клиентское и администраторское приложение, причем клиентское приложение подразделено на 3 взаимозависимых интерфейса.

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

Реализовать специфические возможности системы.

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

Пациент для осуществления заявки на прием к врачу должен предоставить паспортные данные и данные полиса ОМС. Должен иметь возможность по номеру талона контролировать его состояние, в том случае если заявка становится подтвержденной, пациент должен иметь возможность напечатать талон на прием к врачу.

1.4 ВЫБОР СИСТЕМЫ УПРАВЛЕНИЯ БАЗЫ ДАННЫХ

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

---

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

В качестве языка программирования выбран РНР – легкий в освоении язык для быстрой разработки малых и средних Web-приложений. Он позволяет быстро разработать многомодульную программу, в которой каждый модуль отвечает за свою конечную функциональность.

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

В качестве Web-сервера для связки PHP+MySQL традиционно используется Apache – проверенный и надёжный продукт.

Опишем указанные технологии более подробно.

РНР — это серверный язык создания сценариев (или стороны сервера), разработанный специально для Web. В HTML-страницу можно внедрить код РНР, который будет выполняться при каждом ее посещении.

Код РНР интерпретируется Web-сервером и генерирует HTML или иной вывод, наблюдаемый посетителем страницы.

РНР — это продукт с открытым исходным кодом (Open Source). У пользователя имеется доступ к исходному коду. Его можно использовать, изменять и свободно распространять другим пользователям или организациям.

К числу конкурентов РНР относятся Perl, Active Server Pages (ASP) от Microsoft, Java Server Pages (JSP) и Allaire Cold Fusion.

PHP обладает множеством преимуществ по сравнению с этими продуктами, в числе которых:

• 
  высокая производительность;
  
• 
  наличие интерфейсов ко многим различным системам баз данных;
  
• 
  встроенные библиотеки для выполнения многих общих задач, связанных с Web;
  
• 
  бесплатность;
  
• 
  простота изучения и использования;
  
• 
  переносимость;
  
• 
  доступность исходного кода.
  

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

---

Web-сервер Apache называют самым главным сокровищем движения «Открытые программные системы». Его можно получить совершенно бес­платно. Он имеет отличные рабочие характеристики и поэтому используется более широко, чем все остальные Web-серверы вместе взятые. В настоящий момент более 65 процентов всех Web-узлов в мире созданы с использова­нием сервера Apache.

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

Достоинства Web-сервера Apache:

• 
  модульность структуры, которая позволяет: подключать только необходимые модули, гибко регулируя со­отноше­ние между функциональностью и размером программы сервера; создавать дополнительные модули (яркий пример – модуль mod_charset, обеспечивающий обслуживание кириллических кодиро­вок);
  
• 
  открытая архитектура (можно скачать как исходный код, так и от­компи­лированнный вариант);
  
• 
  работоспособность под несколькими платформами: (Unix, Linux, Windows, Netware);
  
• 
  бесплатное распространение;
  
• 
  возможность использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и так далее;
  
• 
  поддержка IPv6.
  
• 
  надёжность и гибкость конфигурации.
  

1.5 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

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

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



Отчет об отпуске лекарственных средств:

SELECT Льготный_отпуск.ФИО_больного, Льготный_отпуск.Номер_рецепта, Лекарства.Код_лекарства, Лекарства.Название, Льготы.Категория_льгот, Льготный_отпуск.Стоимость, Льготный_отпуск.Скидка, Льготный_отпуск.Сумма

FROM (Льготы INNER JOIN Учет_льготников ON Льготы.[Код_пациента] = Учет_льготников.[Код_пациента]) INNER JOIN (Лекарства INNER JOIN Льготный_отпуск ON Лекарства.[Код_лекарства] = Льготный_отпуск.[Код_лекарства]) ON Учет_льготников.[Код_пациента] = Льготный_отпуск.[Код_пациента];

2) Вывести список тех, у кого скидка больше 50%

SELECT Льготный_отпуск.ФИО_больного, Льготный_отпуск.Номер_рецепта, Льготный_отпуск. Скидка

FROM Льготный_отпуск

WHERE (((Льготный_отпуск.Скидка)>50));

---

Смотрите также файлы

• 1 Дайте развернутые ответы на вопросы Дайте определение экологии как науки. Назовите автора термина.docx

• Каковы, на ваш взгляд, причины возникновения правового нигилизма в России и пути его преодоления.doc

• Методические указания по планированию и организации внеаудиторной самостоятельной работы для студентов очного отделения.docx

• Проект Моделирование корреляционных зависимостей.docx

• С целью подготовки учащихся к гиа.docx