БД поликлиника. Проектирование и реализация базы данных районной поликлиники. Учет льготных лекарств
 Скачать 0.59 Mb.
|
1 2
КУРСОВАЯ РАБОТА по дисциплине «Управление данными» Тема: «Проектирование и реализация базы данных районной поликлиники. Учет льготных лекарств»
Екатеринбург 2023 СОДЕРЖАНИЕ Введение…………………………………………………………………………..3 Сущность и понятие баз данных ……………..……………………..…....5 Выбор логической модели данных данных………………….…………..5 Этапы проектирования баз данных……………………….…….………...9 Анализ предметной области и постановка задачи …….……………….13 Выбор системы управления базы данных………………………..……...17 Физическое проектирование базы данных…………………...…………19 Реализация базы данных………………………………………………….21 Заключение……………………………………………………………………….29 Список использованных источников…………………………………..……….30 ВВЕДЕНИЕ В последнее время в нашей жизни всё большую роль играют информационные технологии. Они вошли во все сферы жизнедеятельности, в том числе и торговлю. Использование информационных технологий позволяет любой организации совершенствовать и улучшать управленческую деятельность, увеличивать темпы производства, а для торговых организаций повышать собственный авторитет в глазах потребителей. В настоящее время существуют уже готовые программные продукты, решающие довольно узкоспециализированные задачи. Но часто бывают случаи, когда данные программы не совсем подходят для конкретных условий предприятия. Возможно, они не полностью охватывают область задачи, либо, что бывает гораздо чаще, наоборот, затрагивают более широкую предметную область, что создаёт определённые трудности и неудобства в использовании. Кроме того, они, как правило, являются довольно дорогими и сложными. Часто такие программные продукты требуют специального обучения персонала, что так же стоит немалых затрат и требует времени на обучение. Именно поэтому и разрабатываются специальные программы, автоматизирующие деятельность конкретных предприятий. На основании решаемых задач они могут быть однопользовательскими и многопользовательскими экономическими информационными системами, автоматизированными рабочими местами и многими другими. Выбранная тема исследования считается актуальной в связи со значительным упрощением и автоматизацией учёта, приёма, и выдачи льготных лекарств за счет использования информационных систем. Значимость темы исследования состоит в сокращении трудовых и временных затрат на процессы, связанные с учетом и выдачей льготных лекарств. Целью курсовой работы является формирование умений по проектированию и реализации базы данных для выбранной предметной области на основе полученных теоретических знаний. Сегодня можно с уверенностью утверждать, что решение широкого круга задач в любой сфере деятельности человека сегодня практически невозможно без использования оперативно управляемых баз данных. 1. СУЩНОСТЬ И ПОНЯТИЕ БАЗ ДАННЫХ 1.1 ВЫБОР ЛОГИЧЕСКОЙ МОДЕЛИ ДАННЫХ ДАННЫХ Термин «база данных» (БД, database) попадается на глаза всем, кто пользуется компьютером: и инженеру-программисту, и студенту, и тому, кто просто читает новости в интернете. БД — это хранилище информации, которую можно быстро вносить и редактировать. Например, оформленные в интернет-магазине заказы, даты, имена клиентов, цены, формулы для математических вычислений. Базами данных управляют через специальные системы управления. Сами БД — простейшие, реляционные, NoSQL, комбинированные — строятся по разным принципам. В статье мы расскажем, для чего предназначены базы, какие они бывают, и как иметь с ними дело. В БД указаны имена таблиц, типы данных, типы отношений между полями и ключевые поля База данных — структурированные электронные сведения. Пользователи манипулируют ими согласно правилам моделирования данных. В визуальном представлении это выглядит как книжный шкаф с документами, которые можно передвигать, сортировать, «прореживать», дополнять новыми бумагами. Если человек делает проект, в котором обращается к структурированному хранилищу информации — например, пишет программу для учета клиентов банка или собирает сайт — ему нужно знать, какие бывают базы данных, чтобы правильно выбрать их тип. Они различаются по свойствам и ограничениям, которые важно учитывать в работе. БД — это среда, которая представляет собой таблицы с информацией. Самый наглядный пример базы данных — таблицы в программе MS Excel. Их заполняют цифрами и словами вручную, составляют формулы для управления содержимым ячеек, перетаскивают это содержимое мышью для замены или копирования. База данных выглядит как таблица и хранится в отдельном файле. Если БД «прикреплена» к сайту, увидеть ее в виде таблицы не получится, зато получится написать в строке поиска текстовый запрос и увидеть в списке результатов соответствующую выборку. Еще можно составить запрос на специальном языке Structured Query Language (SQL), чтобы вывести из базы интересующий массив строк.  Рисунок 1- Пример интерфейса базы данных Как хранится информация в БД Структура базы данных представляет собой набор таблиц, которые состоят из строк (записей) и столбцов (полей). У столбцов есть уникальные имена, типы хранимых данных (текст, число, логический тип «Да/Нет», гиперссылка и др.), списки свойств и описания. Базы данных бывают централизованными и распределенными. Централизованная БД хранится на одном компьютере, распределенная — на нескольких. Для локального и удаленного доступа к распределенным базам применяют системы управления базами данных (СУБД). Если БД однопользовательская, в один момент времени с её содержимым может работать один человек, если многопользовательская — несколько человек одновременно манипулируют данными. Процесс развития технологий баз данных формируется рядом факторов: увеличение роста информационной потребности пользователя, условиями эффективного подхода к информации, возникновением новых видов машиной памяти и повышением ее емкости, иными методами и средствами в сфере телекоммуникаций и др. [5, с. 61]. К современным базам данных предъявляются следующие основные требования: 1. Высокое быстродействие (малое время отклика на запрос). Время отклика - интервал времени от момента запроса к базе данных до фактического принятия данных. Похожий термин время доступа - интервал времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом рассматривается операция чтения, поиска данных или записи их. Зачастую операции записи, удаления и модификации данных называются операциями обновления. 2. Легкость обновления данных. Важнейшими являются эти первые два противоречивых требования: для повышения быстродействия требуется упрощенная структура базы данных, что, в свою очередь, усложняет процесс обновления данных, увеличивает их избыточность. 3. Независимость данных - возможность преобразования физической и логической структуры базы данных без изменения представлений пользователей. Независимость данных подразумевает инвариантность к характеру хранения данных, техническим средствам и программному обеспечению. Она минимизирует преобразования структуры базы данных при изменениях стратегии доступа к данным и структуры самих исходных данных. 4. Совместное использование данных многими пользователями. 5. Безопасность данных - защита данных от умышленного или неумышленного нарушения секретности, разрушения или искажения. В безопасность данных включена их целостность и защита. Целостность данных - устойчивое хранение данных от разрушения и уничтожения, которое связано с неполадками технических средств, системными ошибками и ошибочными действиями пользователей. СУБД — программа для управления информацией, которая хранится в базе данных. Эти программы предназначены для работы с реляционными и объектно-реляционными БД с использованием языка запросов SQL. Запросы предназначены для определения данных, управления и манипулирования ими. Самые распространенные СУБД — MySQL, PostgreSQL, SQLite и Oracle. MySQL — самая простая и быстрая многопользовательская СУБД, способная обрабатывать таблицы с 50+ млн. строк. Система доступна в текстовом и графическом режимах. Последний удобен для тех, кто плохо знает язык запросов SQL. PostgreSQL — лишена ограничений по размеру БД. Обеспечивает надежность транзакций, легко масштабируется, подробно документирована разработчиками. SQLite — компактная и быстрая СУБД, которая позволяет хранить всю информацию в одном файле. Oracle — стабильная система, которая быстро и полноценно восстанавливается после сбоев. Она безопасная, надежно защищает хранимую информацию. 1.2 ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ Невозможно создать БД без подробного ее описания, также как и не возможно сделать какое-либо сложное изделие без чертежа и подробного описания технологий его изготовления. Другими словами, нужен проект. Проектом принято считать эскиз некоторого устройства, который в дальнейшем будет воплощен в реальность. Процесс проектирования БД представляет собой процесс переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. Конечной целью проектирования является построение конкретной БД. Очевидно, что процесс проектирования сложен и поэтому имеет смысл разделить его на логически завершенные части – этапы. Можно выделить пять основных этапов проектирования БД: 1. Сбор сведений и системный анализ предметной области. 2. Инфологическое проектирование. 3. Выбор СУБД. 4. Даталогическое проектирование. 5. Физическое проектирование. Сбор сведений и системный анализ предметной области - это первый и важнейший этап при проектировании БД. В нем необходимо провести подробное словесное описание объектов предметной области и реальных связей, присутствующих между реальными объектами. Желательно чтобы в описании определялись взаимосвязи между объектами предметной области. В общем случае выделяют два подхода к выбору состава и структуры предметной области: · Функциональный подход – применяется тогда, когда заранее известны функции некоторой группы лиц и комплексы задач, для обслуживания которых создается эта БД, т.е. четко выделяется минимальный необходимый набор объектов предметной области под описание. · Предметный подход – когда информационные потребности заказчиков БД четко не фиксируются и могут быть многоаспектными и динамичными. В данном случае минимальный набор объектов предметной области выделить сложно. В описание предметной области включаются такие объекты и взаимосвязи, которые наиболее характерны и существенны для нее. При этом БД становится предметной, и подходит для решения множества задач (что кажется наиболее заманчивым). Однако трудность всеобщего охвата предметной области и невозможность конкретизации потребностей пользователей приводит к избыточно сложной схеме БД, которая для некоторых задач будет неэффективной. Рекомендуется использовать компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи, а с другой стороны, учитывает возможность расширения приложения. Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных и входных документов при работе с БД. Инфологическое проектирование – частично формализованное описание объектов предметной области в терминах некоторой семантической модели. Дело в том, что процесс проектирования длительный, требует обсуждений с заказчиком и специалистами в предметной области. Кроме того, при разработке серьезных корпоративных информационных систем проект базы данных является фундаментом, на котором строится вся система в целом, и вопрос о возможности кредитования часто решается экспертами банка на основании именно грамотно сделанного инфологического проекта БД. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет восприниматься не только специалистами в области БД. Описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД. На сегодняшний день наиболее широкое распространение получила модель Чена «Сущность-связь» (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)); 3) Изменим структуру таблицы: В таблицу Учет льготников добавим атрибут СНИЛС: ALTER TABLE Учет льготников ADD СНИЛС INT. 2. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ Интерфейс для поликлиники по функциям: регистрация пациентов, врачей и справочных данных. Интерфейс для врача по функциям: регистрация осмотров и назначения льготных лекарств. 1 2 |