Схема модели «Объект-отношение» приведена на рисунке 3.1.
Было выбрано 6 объектов – студент, группа, ВУЗ, врач и диагноз и специализация. Объект студент имеет 4 свойства: ФИО, место жительства, год рождения, № зачетки. Объект группа имеет 2 свойства: год набора и букву. Объект ВУЗ имеет 6 свойств: адрес, полное название, аббревиатура, дата окончания, телефон учебной части и ФИО ректора. Объект врач представлен 2 свойствами: ФИО, № кабинета. Объект диагноз имеет одно свойство – название. Объект специализация так же имеет одно свойство – область специализации.
В данной схеме используются связи 1 ко многим, а также многие ко многим. Между объектами студент и группа выбрана связь многие к одному. Учитываем, что названия специальностей в ВУЗах уникальны и каждый студент учится лишь в одной группе; в одной группе могут учиться много студентов. Между объектами группа и ВУЗ представлена связь многие к одному: одному ВУЗу могут принадлежать несколько групп; каждая группа принадлежит одному ВУЗу. Между объектами студент и врач нет прямой связи. Объекты врач и диагноз представлены связью многие ко многим, – один врач может поставить несколько диагнозов; один диагноз может быть поставлен несколькими врачами. Между объектами студент и диагноз представлена связь многие ко многим: одному студенту могут быть поставлены несколько диагнозов; один диагноз может быть поставлен нескольким студентам. Между объектами Врачи и специализация представлена связь один-ко-многим: один врач числится в больнице по одной специализации; в одной больнице могут работать несколько врачей одинаковой специализации. К связи между объектами студент и диагноз добавлено 4 свойства – тип лечения, дата начала заболевания, дата окончания заболевания и комментарии.
Рисунок 3.1 – Схема объект-отношение
Обоснование выбора модели данных
Типы моделей данных
Различают сетевую, иерархическую и реляционную модели данных. Каждая из них имеет свои преимущества и свои недостатки. Ниже мы рассмотрим подробно эти модели данных.
Иерархическая модель данных
В иерархической модели связи между данными описывают с помощью упорядоченного графа (или дерева). Тип является составным. Он включает в себя подтипы («поддеревья»), каждый из которых, в свою очередь, является типом «дерево». Каждый из элементарных типов, включенных в тип «дерево», является простым или составным типом «запись».
Таким образом, иерархическая модель данных представляет собой упорядоченную совокупность экземпляров типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи).
Пример реализации иерархической модели данных для разрабатываемой БД представлен на рисунке 3.2.
 учится
учится
|
 имеет
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
диагностируется
Рисунок 3.2 – Реализации иерархической модели данных
Достоинством иерархической модели является эффективное использование памяти, однако такие модели сложны для понимания. В таких моделях отсутствует механизм поддержки целостности данных между записями различных ветвей и обработка информации со сложными логическими связями довольно громоздка. Использование данной модели не рационально, так как невозможно определить связь типа многие ко многим.
Изображенная на рисунке схема отображает вырожденное дерево, у которого каждый объект имеет не более одного ребенка. Основным недостатком иерархической модели для данного программного продукта являются громоздкая форма записи реляционной модели, что, в свою очередь, приводит к осложнению понимания пользователем базы.
Сетевая модель данных
Сетевая модель позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных.
В СМ используются два основных понятия: тип записи и тип набора. Записи определяются записями владельца и члена, которые логически связаны. Диаграмма структуры данных СМ состоит из прямоугольников, представляющих типы записей и стрелок, устанавливающих отношения между типами записей. Эти отношения получают имена и называются типами наборов.
Схема сетевой модели данных для данной БД показана на рисунке 3.3.
|
|
|
|
СМД выгодны по параметрам использования памяти, быстродействия и дают возможность образования произвольной связи, однако имеют ослабленный контроль целостности данных и являются довольно сложными. Использование такой модели также не будет эффективным при выполнении поставленных задач.
Реляционная модель данных
Предпочтение было отдано реляционной модели по следующим причинам:
- реляционная модель является более простой моделью, чем сетевая;
- схема данных позволяет представить структуру в виде таблиц (после некоторых преобразований);
- в настоящее время реляционные базы данных являются более распространенными, чем сетевые;
- использование реляционных баз данных удобнее, чем сетевых;
- сетевая модель данных сложна для изучения пользователем, проще разобраться с реляционной МД;
- реляционная МД нагляднее представляет структуру данных.
В отличие от ИМД и СМД, РМД обеспечивает логический доступ к данным, не зависящий от физической реализации. Недостатками реляционных моделей являются сложность в описании иерархических, сетевых связей и отсутствие стандартных средств идентификации отдельных записей.
Для проектируемой БД реляционная модель представлена на рисунке 3.4.
1
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Рисунок 3.4 – Реляционная модель | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1
УРОВНИ ДОСТУПА К СУБД
Описание групп пользователей
В разработанной СУБД выполнены три уровня доступа: для медсестры ВУЗа, для медсестры больницы и для врача, аналогичные типам: гость, пользователь и администратор.
Медсестра ВУЗа может заходить в базу без пароля. Данный уровень доступа не позволяет вносить или редактировать какую-либо информацию. Доступными являются лишь просмотр информации и ее распечатывание.
Медсестра больницы может зайти в базу лишь под паролем. Данный доступ отличается от предыдущего доступа. Этому типу пользователя позволяется вносить и корректировать изменения в базе, но «Архив» студентов остается закрытым.
Врач (аналог администратор).Вход в базу осуществляется под паролем администратора. Имеет полный доступ ко всей базе. Права врача неограниченны. Он может редактировать структуры таблиц, изменять и удалять любые данные. Далее – более подробно о правах пользователей.
Медсестра ВУЗа
Как сказано ранее, этот пользователь заходит в базу без пароля и не имеет в ней никаких прав на изменение данных – лишь их просмотр и печать на принтере. На всех формах кнопки «Добавить запись», «Сохранить запись» и «Удалить запись» недоступны. Кнопки «Добавить Студента» и «Архив» в форме «Вход» так же недоступны. Область действий – просмотр данных из базы и распечатка их на принтере.
Медсестра больницы
Для входа в базу под правами медсестры больницы необходимо знать пароль. Права Пользователя отличаются от прав предыдущего пользователя лишь тем, что медсестра больницы имеет доступ к кнопке «Добавить студента», «Архив», «Диагностика студента», так как медсестры в больнице работают со студентами, то могут добавлять новых студентов в базу.
Врач
Для входа в базу под правами врача необходимо знать пароль администратора. Врач не имеет никаких ограничений в базе. Он может изменять, добавлять и удалять любые данные в базе, изменять структуру таблиц и форм.
ВЫВОДЫ
За время создания курсового проекта и написания пояснительной записки была досконально изучена предметная область проекта; разработана концептуальная модель БД: объект-отношение; выбрана реляционная модель для создания эффективной БД; разработаны основные модели запросов для работы с данными БД.
В БД была организована целостность данных посредством ввода каскадного удаления между некоторыми объектами. Была обеспечена защита данных посредством ввода различных групп пользователей и запроса пароля.
Также была организована архивация данных.
В результате создания данной системы, требования, изложенные в постановке задачи, выполнены.
Разработка имеет дружественный интуитивно понятный графический интерфейс, позволяющий даже с минимальным знанием компьютера провести автоматизацию учета студентов в больнице. Таким образом, система готова к эксплуатации. Она может обеспечить пользователю поступление необходимой информации, а также облегчить получение статистических наблюдений.
Разрабатываемая база позволяет получить всю необходимую информацию о студентах больницы, принимающих врачах , отчеты: по заболеваемости студентов, по временному периоду и по приму врачей; при необходимости позволяет получить информацию о проектировщике базы.
Приложение А
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
А 1 Общие сведения
А.2 Этапы разработки и сроки выполнения
Сроки выполнения приведены в таблице А.1.
А 3 Назначение и цели создания проекта
БД разрабатывается для систематизации обработки данных о больных студентах, обучающихся в ВУЗах.
Целью создания базы данных является обеспечение целостности и компактности хранимых данных, увеличение скорости получения информации об интересующих студентах, понижение трудозатрат по обработке данных.
А 3 Характеристика объекта автоматизации
А 3.1 Сведения об объекте автоматизации
Объектом автоматизации данного курсового проекта является процесс анализа, обработки, поиска, удаления и учета информации о больных студентах.
А 3.2 Сведения об условиях эксплуатации КП
Данная БД разрабатывается с использованием СУБД Access, которая оснащена инстинктивно понятным интерфейсом и может использоваться широким кругом пользователей нуждающихся в учете информации о студентах. Данной БД может пользоваться любой пользователь, умеющий пользоваться компьютером.
А 4 Требования к проекту
А 4.1 Требования к КП в целом
КП в целом должен :
-иметь обширную систему помощи, включающую сведения о КП в целом, руководство по использованию отдельных частей, корректные сообщения об ошибках пользователя, если таковые имеются; осуществлять добавление, изменение, удаление и поиск информации из имеющейся БД;
- обеспечить не избыточность, компактность, целостность хранимых данных.
А 4.2 Требования к задачам и функциям КП
Проектируемый программный продукт должен реализовывать следующие задачи:
- иметь систему помощи, т.е. выдавать корректные сообщения при ошибках, возникающих в процессе работы;
- позволять получать информацию по определённым запросам пользователя. (запросы на выборку, на добавление и удаление записей в архиве, запросы для создания пользовательских форм и отчетов. Отчетов: «Заявка о начале учета в больнице», «Прием врачей», форм: больных студентов определенного врача, заболевания определенного студента), а так же:
- хранить информацию о больных студентах;
- хранить информацию о ВУЗах;
- хранить информацию о группе;
- хранить информацию о заболевании;
- хранить информацию о лечащем враче;
- хранить информацию о диагностике;
- корректный выбор информации по какой-либо характеристике;
- поиск по ключевым словам.
А 4.3 Требования к видам обеспечения
А 4.3.1 Требования к программному обеспечению
К программному обеспечению (ПО) предъявляются следующие требования:
-монитор типа SVGA;
-операционная система- Microsoft Windows 98 и выше;
- установленная прикладная программа Access 2003 из программного пакета Microsoft Office.
А 4.3.2 Требования к техническому обеспечению
Техническое обеспечение должно удовлетворять следующим требованиям:
-тип компьютера- INTEL 5x 86;
-объем памяти RAM 16Мб;
А 4.3.3 Требования к организационному обеспечению
К программной документации предъявляются следующие требования:
-наличие технического задания;
-пояснительной записки, включающей приложения.
Приложение Б
ЗАПОЛНЕННЫЕ ТАБЛИЦЫ
| Врач | |||
| #КВ | ФИО | № кабинета | специализация |
| 1 | Василюк А.Г. | 14 | хирург |
| 2 | Сидоров Б.П. | 25 | окулист |
| 3 | Петров Ю.К. | 12 | травматоло |
| 4 | Версетилова Н.П. | 16 | окулист |
| 5 | Бочкарева Ю.П. | 19 | терапевт |
| 6 | Вишневская А.Ю. | 22 | лор |
| 8 | Абдулова А.О. | 36 | терапевт |
| ВУЗ | |||||
| #КВ | Название ВУЗа | Адресс ВУЗа | Аббревиатура | ФИО ректора | Телефон |
| 1 | Интеллект | Богдана Хмельницкого | ДонГУИИИ | Шевченко А.И. | 381-56-45 |
| 2 | Политехнич | Артема 135 | ДонНТУ | Борисов А.Г. | 381-42-36 |
| 3 | Национальн | Университетская 25 | ДонНУ | Шевчук Г.И. | 381-25-65 |
| Группа | ||
| #КГ | Аббревиатура | |
| 1 | ИС-06а | |
| 2 | ПО-06г | |
| 3 | ИС-06б | |
| 4 | САУ-06 | |
| 5 | ИС-06в | |
| 6 | ПО-06а | |
| 7 | ПО-06в | |
| 8 | ПО-06б | |
Диагноз | ||
| #КД | Название | |
| 1 | Свинка | |
| 2 | Корь | |
| 3 | ОРЗ | |
| 4 | Воспаление легких | |
| 5 | Отит | |
| 6 | Глаукома | |
| Диагностика | |||||||
| #КД | ФИО Врача | Название Диагноза | ФИО Студента | Дата начала заболевания | Дата окончания заболевания | Тип лечения | Комментарии |
| 1 | Василюк А.Г. | Свинка | Михайлюк П.Ф. | 12.05.2005 | 15.06.2008 | амбулаторно | |
| 2 | Сидоров Б.П. | ОРЗ | Рогоза А.Р. | 11.09.2008 | 15.09.2008 | стационарно | |
| 3 | Версетилова Н.П. | Отит | Арефьев А.В. | 01.01.2007 | 10.01.2007 | стационарно | |
| 4 | Василюк А.Г. | Воспаление легких | Митрофанова А.П. | 12.03.2007 | 01.04.2007 | амбулаторно | |
| 5 | Бочкарева Ю.П. | Корь | Арефьев А.В. | 12.08.2008 | 02.09.2008 | амбулаторно | |
| 8 | Сидоров Б.П. | Свинка | Рогоза А.Р. | 12.09.1999 | 03.05.2007 | амбулаторно | |
| Специализация | ||||||
| # КСп | область специализации | |||||
| 1 | терапевт | |||||
| 2 | хирург | |||||
| 3 | окулист | |||||
| 4 | лор | |||||
| 5 | травматоло | |||||
| 6 | дерматолог | |||||
| Студент | ||||||
| #КС | ФИО | Место жительства | Дата рождения | № зачетки | ВУЗ | Группа |
| 1 | Михайлюк П.Ф. | Донецк | 15.02.1989 | 06/063 | ДонГУИИИ | ИС-06а |
| 2 | Митрофанова А.П. | Львов | 02.06.1989 | 06/055 | ДонНТУ | ИС-06в |
| 3 | Рогоза А.Р. | Макеевка | 09.09.1989 | 06/035 | ДонНТУ | ИС-06б |
| 4 | Арефьев А.В. | Донецк | 02.07.1989 | 06/044 | ДонНУ | ПО-06б |
| 5 | Андросова А.А. | Донецк | 05.06.1990 | 07/022 | ДонГУИИИ | ПО-06а |
| 6 | Поганский А.И. | Донецк | 03.04.1989 | 06/098 | ДонНТУ | ИС-06в |
| 7 | Павленко Н.Г. | Макеевка | 05.11.1990 | 07/054 | ДонГУИИИ | ПО-06в |
| 8 | Первостроев А.Е. | Луганск | 06.12.1990 | 07/023 | ДонГУИИИ | ПО-06а |
| 9 | Андропова К.К. | Макеевка | 11.11.1990 | 07/058 | ДонНТУ | ПО-06а |
| 10 | Малаева А.П. | Донецк | 14.02.1989 | 06/024 | ДонНУ | ИС-06а |
| 11 | Прогматова Г.Г. | Донецк | 16.01.1989 | 06/043 | ДонНТУ | САУ-06 |
| 12 | Пономаренко А.А. | Донецк | 11.08.1989 | 06/085 | ДонГУИИИ | ПО-06б |
| 13 | Жидаев К.Л. | Донецк | 16.05.1990 | 07/011 | ДонНТУ | ПО-06в |
| 14 | Жмурко В.А. | Горловка | 12.01.1989 | 06/012 | ДонГУИИИ | ПО-06б |
| 15 | Кондратенко В.А. | Горловка | 14.09.1999 | 06/056 | ДонГУИИИ | САУ-06 |
| 20 | Ефимцева К.Е. | Горловка | 28.03.1989 | 06/230 | ДонГУИИИ | САУ-06 |
Приложение В
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЮ
В.1 Инсталляция
Для установки приложения достаточно скопировать его файлы в любую папку на компьютере.
В.2 Начало работы с программой
В.2.1 Запуск приложения
После запуска приложения, первое окно которые вы видите - это форма входа в СУБД под названием «Вход», на которой расположены кнопки трех видов пользователей: Медсестра ВУЗа, Медсестра больницы и Врач. Они имеют типы Гость, Пользователь и Администратор соответственно.
После выбора одного из типа пользователя выводится форма пароля.
В.2.2 Смена пользователя
Для смены пользователя необходимо выбрать соответствующую кнопку на форме «Главная», после чего происходит закрытие текущей формы и открывается форма «Вход».
В.3 Руководство администратора
При входе в базу администратору необходимо ввести пароль «2». Если же пароль окажется неверным, система сообщит об ошибке и попросит повторить попытку или отменить выполнение действия и вернуться на предыдущую форму.
Дата: 2019-12-22, просмотров: 274.
