База данных "Медицинский центр"
Рассмотрение проблемы проектирования реляционной базы данных. Разработка базы, предназначенной для автоматизации работы медицинского центра. Анализ предметной области и изучение ее специфики, понятности и удобности базы для работников здравоохранения.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 06.06.2022 |
Размер файла | 2,0 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Курсовая работа
по дисциплине «Управление данными»
База данных «Медицинский центр»
Содержание
Понятие о СУБД
Основные понятия о реляционных базах данных
Проектирование базы данных «Медицинский центр»
Назначение базы данных
Структура базы данных
Заключение
Список используемой литературы
Понятие о СУБД
Цель любой информационной системы - обработка данных об объектах реального мира. Основные идеи современной информационной технологии базируются на концепции баз данных (БД).
База данных (БД) - это поименованная совокупность структурированных данных, относящихся к определенной предметной области.
Согласно данной концепции основой информационной технологии являются данные, организованные в БД, адекватно отражающие реалии действительности в той или иной предметной области и обеспечивающие пользователя актуальной информацией в соответствующей предметной области. Под предметной областью принято понимать часть реального мира, подлежащего изучению для организации управления и, в конечном счёте, автоматизации, например, предприятие, ВУЗ и так далее.
Первые БД появились уже на заре 1-го поколения ЭВМ, представляя собой отдельные файлы данных или их простые совокупности.
Создавая базу данных, пользователь стремится упорядочить информацию по различным признакам и быстро извлекать выборку с произвольным сочетанием признаков. Сделать это возможно, только если данные структурированы.
Структурирование - это введение соглашений о способах представления данных.
Неструктурированными называют данные, записанные, например, в текстовом файле.
Пользователями базы данных могут быть различные прикладные программы, программные комплексы, а также специалисты предметной области, выступающие в роли потребителей или источников данных, называемые конечными пользователями.
По мере увеличения объемов и структурной сложности хранимой информации, а также расширения круга потребителей информации, определилась необходимость создания удобных и эффективных систем интеграции хранимых данных и управления ими. Теперь создание базы данных, ее поддержка и обеспечение доступа пользователей к ней осуществляются централизованно с помощью специального программного инструментария - системы управления базами данных (СУБД).
Система управления базами данных (СУБД) - это комплекс программных и языковых средств, необходимых для создания баз данных, поддержания их в актуальном состоянии и организации поиска в них необходимой информации.
Использование СУБД обеспечивает лучшее управление данными, более совершенную организацию файлов и более простое обращение к ним по сравнению с обычными способами хранения информации.
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
· физическом размещении в памяти данных и их описаний;
· механизмах поиска запрашиваемых данных;
· проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
· способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
· поддержании баз данных в актуальном состоянии;
· и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных.
Проект базы данных надо начинается с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Проектирование обычно поручается человеку (группе лиц) - администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных.
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов, этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
С помощью остальных моделей СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Основные понятия о реляционных базах данных
Понятие реляционный (англ. relation - отношение) связано с разработками известного американского специалиста в области систем баз данных, сотрудника фирмы IBM д-ра Е. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), которым впервые был применен термин «реляционная модель данных».
В течение долгого времени реляционный подход рассматривался как удобный формальный аппарат анализа баз данных, не имеющий практических перспектив, так как его реализация требовала слишком больших машинных ресурсов. Только с появлением персональных ЭВМ реляционные и близкие к ним системы стали распространяться, практически не оставив места другим моделям.
Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
· каждый элемент таблицы - один элемент данных; повторяющиеся группы отсутствуют;
· все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
· каждый столбец имеет уникальное имя;
· одинаковые строки в таблице отсутствуют;
· порядок следования строк и столбцов может быть произвольным. Таблица такого рода называется отношением.
База данных, построенная с помощью отношений, называется реляционной базой данных.
Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы - атрибутам отношений, доменам, полям.
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ - ключ второй таблицы.
Предложив реляционную модель данных, Э.Ф. Кодд создал и инструмент для удобной работы с отношениями - реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы.
То, чем принципиально отличаются реляционные модели от сетевых и иерархических, на это можно сказать следующим образом: иерархические и сетевые модели данных - имеют связь по структуре, а реляционные - имеют связь по значению.
Проектирование баз данных традиционно считалось очень трудной задачей. Реляционная технология значительно упрощает эту задачу.
Разделением логического и физического уровней системы она упрощает процесс отображения "уровня реального мира", в структуру, которую система может прямо поддерживать. Поскольку реляционная структура сама по себе концептуально проста, она позволяет реализовывать небольшие и/или простые (и поэтому легкие для создания) базы данных, такие как персональные, сама возможность реализации которых никогда даже бы не рассматривалась в старых более сложных системах.
Теория и дисциплина нормализации может помочь, показывая, что случается, если отношения не структурированы естественным образом.
Реляционная модель данных особенно удобна для использования в базах данных распределенной архитектуры - она позволяет получать доступ к любым информационным элементам, хранящимся в узлах сети ЭВМ. Необходимо обратить особое внимание на высокоуровневый аспект реляционного подхода, который состоит во множественной обработке записей. Благодаря этому значительно возрастает потенциал реляционного подхода, который не может быть достигнут при обработке по одной записи и, прежде всего, это касается оптимизации.
Данная модель позволяет определять:
· операции по запоминанию и поиску данных;
· ограничения, связанные с обеспечением целостности данных.
Для увеличения эффективности работы во многих СУБД реляционного типа приняты ограничения, соответствующие строгой реляционной модели.
Многие реляционные СУБД представляют файлы БД для пользователя в табличном формате - с записями в качестве строк и их полями в качестве столбцов. В табличном виде информация воспринимается значительно легче. Однако в БД на физическом уровне данные хранятся, как правило, в файлах, содержащих последовательности записей.
Основным преимуществом реляционных СУБД является возможность связывания на основе определенных соотношений файлов БД.
Со структурной точки зрения реляционные модели являются более простыми и однородными, чем иерархические и сетевые. В реляционной модели каждому объекту предметной области соответствует одно или более отношений. При необходимости определить связь между объектами явно, она выражается в виде отношения, в котором в качестве атрибутов присутствуют идентификаторы взаимосвязанных объектов. В реляционной модели объекты предметной области и связи между ними представляются одинаковыми информационными конструкциями, существенно упрощая саму модель.
СУБД считается реляционной при выполнении следующих двух условий, предложенных еще Э. Коддом:
· поддерживает реляционную структуру данных;
· реализует, по крайней мере, операции селекции, проекции и соединения отношений.
В последующем был создан целый ряд реляционных СУБД, в той или иной мере отвечающих данному определению. Многие СУБД представляют собой существенные расширения реляционной модели, другие являются смешанными, поддерживая несколько даталогических моделей.
На сегодняшний день реляционные базы данных остаются самыми распространенными, благодаря своей простоте и наглядности, как в процессе создания, так и на пользовательском уровне.
Основным достоинством реляционных баз данных является совместимость с самым популярным языком запросов SQL.
С помощью единственного запроса на этом языке можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция). Так как табличная структура реляционной базы данных интуитивно понятна пользователям, то и язык SQL является простым и легким для изучения. Реляционная модель имеет солидный теоретический фундамент, на котором были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели, SQL стал основным языком для реляционных баз данных.
Но выявлены и недостатки рассмотренной модели баз данных:
· так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных;
· высокая трудоемкость манипулирования информацией и изменения связей.
Проектирование базы данных «Медицинский центр»
Задание. Выполнить проектирование и создать базу данных «Отдел кадров» для автоматизации учета информации о сотрудниках и вакансиях, имеющихся в организации.
Анализ предметной области
База данных обслуживает медицинский центр, следовательно, главные компоненты в базе - это врачи, пациенты и лекарства. С этими данными в основном и производится вся работа.
Изначально в базе данных уже хранится список врачей, которые работают в медицинском центре. У каждого врача есть свой уникальный номер, а также в базе указываются его специальность и фамилия, имя и отчество.
В базе отдельно хранятся записи о пациентах. Известны их имя, пол, домашний адрес и дату рождения. У них также есть свой уникальный номер. При появлении новых клиентов их можно внести в базу по заданным требованиям.
Основная нагрузка идет на форму с данными осмотров клиентов. В ней используются практически все данные и фактически все через нее связываются. Каждый раз, когда больной приходит в медицинский центр, создается новый кортеж со своим уникальным номером. Врач указывает в кортеже свой и пациента уникальные номера, которые исключат путаницы людей с возможно одинаковыми именами. Врач каждый раз ставит диагноз больному в соответствии с его состоянием и назначает ему лекарственные препараты. Также, врач может указать какие-либо особые предписания для каждого больного.
К списку лекарств, которые выписываются больным, имеется отдельный доступ. Можно узнать, каким людям прописали определенный препарат. В сведениях о лекарствах содержатся способы их применения и возможные побочные действия. Для удобства врачей администратором базы данных создан список наиболее частых болезней, которые можно указать в описании лекарства.
С помощью различных форм и запросов в базе данных реализована возможность разделять данные по критериям и конкретизировать их.
Назначение базы данных
База данных служит для обслуживания пациентов медицинского центра и облегчения документирования записей о больных.
Данная база данных не имеет каких-либо резко субъективных черт, которые могли бы применяться только в определенной области. Поэтому представляется возможным использование данной работы во многих здравоохранительных организациях с похожим видом деятельности.
Понятный русский стандартный интерфейс, состоящий из окон, кнопок и вкладок легок в освоении даже неопытному пользователю.
Структура базы данных
1. Таблицы
На основании предметной области создается реляционная база данных, а, следовательно, каждому значимому элементу ставится в соответствие таблица.
Таблица 1 - «Лекарственные препараты»
Предназначена для хранения данных о лекарственных препаратах.
Таблица 2 - «Список болезней»
Служит маской ввода для таблицы «Лекарственные препараты». Содержит основные болезни.
Таблица 3 - «Врачи»
В ней содержатся данные о врачах, работающих в данном медицинском учреждении.
Таблица 4 - «Пациенты»
Данная таблица содержит данные о клиентах. Она постоянно дополняется.
Таблица 5 - «Осмотр»
Является основной частью базы данных. В эту таблицу вносятся данные и о клиентах, и о врачах, работавших с пациентами. Через эту таблицу определяется большинство запросов.
Таблица 6 - Схема связей между таблицами
Здесь представлены связи, которые обеспечивают связанную работу базы данных. Ключевые поля обозначены значком «». Таблица «болезни_список», не обозначенная связями, является маской ввода в таблице «Лекарственные препараты», таблица «пол» также является маской ввода, так как данное поле может иметь только 2 значения.
Для стабильной и правильной работы базы данных введена проверка на целостность данных.
2. Формы
Рисунок 1. Главная заставка
Эта форма служит отправной точкой для работы с базой. В зависимости от направленности действий можно выбрать 4 направления, нажав соответствующие кнопки.
Таблица 7 - Форма «Врачи»
Данная форма отображает работающих в медицинском центре врачей. С помощью этой формы можно также определить, какие пациенты лечились у определенного врача, выделив интересующего врача и нажав кнопку . Результат отобразится в виде списка-формы:
Таблица 8 - Форма «Клиенты»
Разделена на 3 вкладки по роду задач.
Таблица 9 - Вкладка «Список клиентов»
Позволяет просмотреть список проходивших лечение клиентов. Служит только для просмотра. При добавлении записей для корректного отображения записей на данной вкладке есть кнопка, внизу, обновляющая данные по пациентам.
Рисунок 2. Вкладка «Информация по клиентам»
На данной вкладке можно определить следующие данные: количество осмотров и кто присутствовал на осмотрах по введенной дате; список пациентов и их количество, которые принимают определенный препарат; список препаратов для определенного пациента; список пациентов с определенной одинаковой болезнью (если такие имеются).
Рисунок 3. Вкладка «Работа с клиентами»
На данной вкладке можно более тщательно рассмотреть (данные не сливаются друг с другом) данные пациента. Основной задачей данной вкладки является добавление записей о новых пациентах или удаление записей пациентов из базы данных.
Рисунок 4. Форма «Лекарственные препараты»
Данная форма предназначена для работы с лекарствами. Можно просмотреть список имеющихся в базе лекарств:
Рисунок 5
Или же добавить с помощью запроса новое лекарство.
Таблица 10 - Форма «Осмотры»
В данной форме содержатся данные обо всех осмотрах, которые проводились сотрудниками данного медицинского центра. Для нахождения какого либо определенного осмотра вынесена кнопка «поиска», которая быстро найдет нужную информацию. Здесь же находится кнопка для добавления нового осмотра. Ввод вводится на новой форме:
Таблица 11
Запросы используются для определения, каких либо конкретных данных по базе данных. В данной базе данных использовались различные способы формирования запросов (как с помощью конструктора запросов, так и с помощью языка запросов SQL).
Рисунок 6. Определение тех пациентов, которые ходили на прием в заданную дату
Рисунок 7. Определение пациентов с одинаковой болезнью (болезнь вводится пользователем базы данных)
Рисунок 8. Показывает, каким пациентам прописали введенный пользователем препарат. Запрос исключает повторяющиеся записи
Рисунок 9. Определяет количество приемов в день по введенной пользователем дате
Рисунок 10. Показывает всех пациентов у запрошенного пользователем врача
Рисунок 11. Показывает, какие препараты прописали пациенту, которым интересуется пользователь
Рисунок 12. Добавляет в базу данных новый лекарственный препарат, описывая его свойства
Рисунок 13. Удаление из базы данных лекарства с заданным названием
Результатами запросов являются таблицы либо результаты, отражающиеся в виде форм.
Заключение
реляционный база медицинский автоматизация
На сегодняшний день реляционные базы данных остаются самыми распространенными, благодаря своей простоте и наглядности как в процессе создания так и на пользовательском уровне.
Проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состоять база данных и какие атрибуты должны быть у этих отношений.
Средствами СУБД Access из пакета программ Microsoft Office 2007 мною была разработана база данных, предназначенная для автоматизации работы медицинского центра. Был проведен анализ предметной области и изучена ее специфика, поэтому база должна быть понятна и удобна работникам здравоохранения.
База максимально настроена на выполнение требований персонала медицинского центра и имеет приятный на взгляд вид.
Список используемой литературы
1. Гетц Кен «Access. Сборник рецептов для профессионалов»; Спб; 2005 г; 782с.;
2. Ламберт Стив «Microsoft Access 2007»; М. Эконом; 2007; 432с.
3. Горев А., Макашарипов С, Ахаян Р. Эффективная работа с СУБД. СПб, «Питер», 2002.
4. Хомоненко А.Д. «Базы данных»; Спб.: КОРОНА принт; 2004 г; 736с.
Размещено на Allbest.ru
Подобные документы
Анализ предметной области с использованием моделей методологии ARIS и разработка ER-диаграммы. Описание входной и выходной информации для проектирования реляционной базы данных. Разработка управляющих запросов и связей между ними с помощью языка SQL.
курсовая работа [975,2 K], добавлен 30.01.2014Информационно-логическая модель предметной области по нотациям Ричарда Баркера. Даталогическая модель реляционной базы данных в виде диаграммы схемы отношений. Приложение интерфейса для базы данных на языке программирования С# в среде Visual Studio.
курсовая работа [3,6 M], добавлен 23.12.2014Разновидности систем управления базами данных. Анализ предметной области. Разработка структуры и ведение базы данных. Структурированный язык запросов SQL. Организация выбора информации из базы данных. Общие принципы проектирования экранных форм, макросов.
курсовая работа [3,1 M], добавлен 26.02.2016Базы данных - важнейшая составная часть информационных систем. Проектирование базы данных на примере предметной области "Оргтехника". Сбор информации о предметной области. Построение информационно-логической модели данных. Разработка логической структуры.
курсовая работа [318,6 K], добавлен 24.12.2014Проблемы внедрения информационных технологий. Автоматизация работы пользователя. Основные этапы проектирования базы данных. Функционирование предметной области. Специализированные языки обработки данных. Обоснование выбора основных технических средств.
курсовая работа [61,9 K], добавлен 08.02.2012Исследование технологии проектирования базы данных. Локальные и удаленные базы данных. Архитектуры и типы сетей. Программная разработка информационной структуры предметной области. Обоснование выбора архитектуры "клиент-сервер" и операционной системы.
дипломная работа [1,1 M], добавлен 15.02.2017Описание предметной области разрабатываемой базы данных для теннисного клуба. Обоснование выбора CASE-средства Erwin 8 и MS Access для проектирования базы данных. Построение инфологической модели и логической структуры базы данных, разработка интерфейса.
курсовая работа [3,8 M], добавлен 02.02.2014Рассмотрение теоретических основ проектирования. Анализ предметной области и разработка таблиц базы данных. Заполнение таблиц, поиск данных с помощью фильтра. Создание форм, разработка запросов. Создание и настройка отчетов, составление приложения.
курсовая работа [2,8 M], добавлен 01.06.2014Создание базы данных для информационной системы "Грузоперевозки". Анализ предметной области, разработка концептуальной и логической модели базы данных, с использованием средства MS Micrоsоft SQL Server 2005, реализация физического проектирования базы.
курсовая работа [1,3 M], добавлен 01.07.2011Особенности разработки инфологической модели и создание структуры реляционной базы данных. Основы проектирования базы данных. Разработка таблиц, форм, запросов для вывода информации о соответствующей модели. Работа с базами данных и их объектами.
курсовая работа [981,4 K], добавлен 05.11.2011