Разработка схемы объект-отношение
Поможем в ✍️ написании учебной работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

 

Схема модели «Объект-отношение» приведена на рисунке 3.1.

Было выбрано 6 объектов – студент, группа, ВУЗ, врач и диагноз и специализация. Объект студент имеет 4 свойства: ФИО, место жительства, год рождения, № зачетки. Объект группа имеет 2 свойства: год набора и букву. Объект ВУЗ имеет 6 свойств: адрес, полное название, аббревиатура, дата окончания, телефон учебной части и ФИО ректора. Объект врач представлен 2 свойствами: ФИО, № кабинета. Объект диагноз имеет одно свойство – название. Объект специализация так же имеет одно свойство – область специализации.

В данной схеме используются связи 1 ко многим, а также многие ко многим. Между объектами студент и группа выбрана связь многие к одному. Учитываем, что названия специальностей в ВУЗах уникальны и каждый студент учится лишь в одной группе; в одной группе могут учиться много студентов. Между объектами группа и ВУЗ представлена связь многие к одному: одному ВУЗу могут принадлежать несколько групп; каждая группа принадлежит одному ВУЗу. Между объектами студент и врач нет прямой связи. Объекты врач и диагноз представлены связью многие ко многим, – один врач может поставить несколько диагнозов; один диагноз может быть поставлен несколькими врачами. Между объектами студент и диагноз представлена связь многие ко многим: одному студенту могут быть поставлены несколько диагнозов; один диагноз может быть поставлен нескольким студентам. Между объектами Врачи и специализация представлена связь один-ко-многим: один врач числится в больнице по одной специализации; в одной больнице могут работать несколько врачей одинаковой специализации. К связи между объектами студент и диагноз добавлено 4 свойства – тип лечения, дата начала заболевания, дата окончания заболевания и комментарии.

 

Рисунок 3.1 – Схема объект-отношение

Обоснование выбора модели данных

 

Типы моделей данных

Различают сетевую, иерархическую и реляционную модели данных. Каждая из них имеет свои преимущества и свои недостатки. Ниже мы рассмотрим подробно эти модели данных.

 

Иерархическая модель данных

В иерархической модели связи между данными описывают с помощью упорядоченного графа (или дерева). Тип является составным. Он включает в себя подтипы («поддеревья»), каждый из которых, в свою очередь, является типом «дерево». Каждый из элементарных типов, включенных в тип «дерево», является простым или составным типом «запись».

Таким образом, иерархическая модель данных представляет собой упорядоченную совокупность экземпляров типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи).

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

 

                                                учится
ВУЗ
#К.В. Название ВУЗа Адрес ВУЗа Аббревиатура ФИО ректора Телефон
счет текст текст текст текст текст

 

Студент

 
#К.С ФИО М.жит-ва Дата рожд № зач

Дата окон

счетч симв симв дата/вр текст

д/вр

             

             

                     

 

      учится

             

Студент

 
#К.С ФИО М.жит-ва Дата рожд

№ зач

счетч симв симв дата/вр

текст

           

 

Группа

#К.Г Аббревиатура
счет текст

 

                

              

 

 

                                               имеет
Врач
#К.Вр. ФИО № кабинета
счет текст текст

 

Специализация

# К.Сп Область спец-ии
счет текст

 

Врач
#К.Вр. ФИО № кабинета Специализация
счет текст текст числ

                                                диагностируется

 

 

Диагноз

#К.Д

Название

Дата начала Дата окон
счет текст

д/вр

д/вр
         

 

                                                      

 

Диагноз
#К.Д Название
счет текст

 

принадлежит

 

Студент

 
#К.С ФИО М.жит-ва Дата рожд № зач ВУЗ Группа Дата нач

Дата окон

счетч симв симв дата/вр текст дл.цл дл.цл. д/вр

д/вр

 

                   

 

                                                

4                           
Диагноз
#К.Д Название
счет текст

                                               

Врач

#К.Вр. ФИО № кабинета Специализация Дата нач Дата окон
счет текст текст числ

д/вр

                                  

    

 

Студент
#К.С ФИО М.жит-ва Дата рожд № зач ВУЗ Группа
счетч симв симв дата/вр текст дл.цл дл.цл.

 

Диагноз

#К.Д

Название

Дата начала Дата окон
счет текст

д/вр

д/вр
         

 

 

                                                

                          

 

 

Рисунок 3.2 – Реализации иерархической модели данных

 

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

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

 

Сетевая модель данных

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

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

Схема сетевой модели данных для данной БД показана на рисунке 3.3.

 

наблюдает
Врач
Студент

ставится
Рисунок 3.3 – Схема сетевой модели данных

 

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

 

Реляционная модель данных

Предпочтение было отдано реляционной модели по следующим причинам:

- реляционная модель является более простой моделью, чем сетевая;

- схема данных позволяет представить структуру в виде таблиц (после некоторых преобразований);

- в настоящее время реляционные базы данных являются более распространенными, чем сетевые;

- использование реляционных баз данных удобнее, чем сетевых;

- сетевая модель данных сложна для изучения пользователем, проще разобраться с реляционной МД;

- реляционная МД нагляднее представляет структуру данных.

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

Для проектируемой БД реляционная модель представлена на рисунке 3.4.

 

 


1                                                                                             1                                   1                                           1

Студент

 

Группа

 

Специализация

 

Диагноз

 

 
#К.С ФИО Место жит-ва Дата рожд № зач Дата оконч.   ВУЗ

Группа

 

#К.Г

Аббревиатура

 

# К.Сп

Область спец-ии

 

#К.Д

Название

 

счетч симв симв дата/вр текст дата/вр дл.цл

дл.цл.

 

счет

текст

 

счет

текст

 

счет

текст

 

                                                   

                                                              

                                                                                                                                                                           

                                                                                                                                       

 


 

                                 1                                                                                                                                   1

ВУЗ

 

Врач

#К.В. Название ВУЗа Адрес ВУЗа Аббревиатура ФИО ректора Телефон

 

#К.Вр.

ФИО № кабинета Специализация
счет текст текст текст текст текст

счет

текст текст числ
                         

 

 

 


                                                                             

Диагностика

#К.Дг ФИО врача Название диагноза Фио студента Дата начала заболев Дата олконч. заболев Тип лечения Комментарии
счет числ числ числ дл.цл дл.цл текст текст

 

Рисунок 3.4 – Реляционная модель

 

 




УРОВНИ ДОСТУПА К СУБД

 

Описание групп пользователей

В разработанной СУБД выполнены три уровня доступа: для медсестры ВУЗа, для медсестры больницы и для врача, аналогичные типам: гость, пользователь и администратор.

Медсестра ВУЗа может заходить в базу без пароля. Данный уровень доступа не позволяет вносить или редактировать какую-либо информацию. Доступными являются лишь просмотр информации и ее распечатывание.

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

Врач (аналог администратор).Вход в базу осуществляется под паролем администратора. Имеет полный доступ ко всей базе. Права врача неограниченны. Он может редактировать структуры таблиц, изменять и удалять любые данные. Далее – более подробно о правах пользователей.

Медсестра ВУЗа

Как сказано ранее, этот пользователь заходит в базу без пароля и не имеет в ней никаких прав на изменение данных – лишь их просмотр и печать на принтере. На всех формах кнопки «Добавить запись», «Сохранить запись» и «Удалить запись» недоступны. Кнопки «Добавить Студента» и «Архив» в форме «Вход» так же недоступны. Область действий – просмотр данных из базы и распечатка их на принтере.

Медсестра больницы

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

Врач

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



ВЫВОДЫ

 

За время создания курсового проекта и написания пояснительной записки была досконально изучена предметная область проекта; разработана концептуальная модель БД: объект-отношение; выбрана реляционная модель для создания эффективной БД; разработаны основные модели запросов для работы с данными БД.

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

Также была организована архивация данных.

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

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

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



Приложение А

 

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

 

А 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, просмотров: 240.