УДК 004.05
Программное
сопровождение системы управления базами данных «профилактика»
Для
ГБУЗ «Сахалинский областной онкологический диспансер»
Лапушко
Ирина Ивановна
Сахалинский
государственный университет, студент
Агаширинова
Валентина Юрьевна
Сахалинский государственный университет, институт естественных наук и
техносферной безопасности
Старший
преподаватель кафедры информатики
Аннотация
В
статье рассматривается процесс автоматизации процесса обработки данных
Радиологическим отделением ГБУЗ «Сахалинский областной онкологический
диспансер», которая позволила автоматизировать подготовку ежегодного отчёта
отделения.
Ключевые
слова:
автоматизация, информационная система, запрос, отчет.
Design
and development of software for the automation of MBOU to "Children's Art
School Nevelsk"
Ksenofontov
Sergey Sergeevich
Sakhalin
State University
Student
Agashirinova
Valentina Yuryevna
Sakhalin
State University, Institute of Natural Sciences and technosphere safety
Senior
Lecturer of the Department of Informatics
Abstract
The
article discusses the process of automation of activity with the process of
computerization of data processing radiology department GBUZ "Sakhalin
Regional Oncology Center, which will automate the preparation of the annual
report department.
Keywords: automation,
information system, query, report.
Проблема охраны здоровья населения остается одним из
главных приоритетов не только мировой, но и государственной политики Российской
Федерации. Во все времена здоровье человека считалось величайшим благом и
естественной, абсолютной и непреходящей ценностью, поэтому здоровью населения
придается первостепенное значение при планировании и осуществлении
экономической политики государства. Научно-технический и промышленный прогресс
значительно улучшил условия жизни и увеличил ее среднюю продолжительность, сделал
менее страшными по своим последствиям инфекционные и многие другие болезни, но
одновременно так изменил среду обитания человека, его образ жизни, что стали
массовыми ранее не столь значимые заболевания.
Для успешного создания работоспособной, отказоустойчивой
и удобной информационной системы необходимо тщательное изучение предметной
области, сбор исходных данных и их анализ. Необходимо выделить круг
автоматизируемых задач и заложить требования к функциональности системы.
С помощью анализа нормативной документации, опроса
были составлены требования пользователей к разрабатываемой базе данных, который
представляет собой список запросов с указанием их интенсивности и объемов
данных. Разработчиком определяются требования к вводу, обновлению и
корректировке информации. Требования пользователей уточняются и дополняются при
анализе имеющихся и перспективных задач [6, с. 74].
Для подготовки годового отчёта отделения необходимы
следующие данные:
·
количество
процедур по каждому аппарату;
·
статистика
пролеченных больных по стадиям;
·
статистика
пролеченных больных по нозологиям;
·
статистика
по видам лечения;
·
статистика
по методам лечения;
·
эффект
от лечения.
Paбoтa c бoльшим oбъeмoм инфopмaции oчeнь
зaтpуднитeльна и oтнимaeт мнoгo вpeмeни. В peзультaтe иccлeдoвaния пpeдмeтнoй
oблacти были выявлeны вxoдныe дaнныe. Сoздaны массивы вxoдных дaнных coдepжащие
cлeдующую инфopмaцию:
·
инфopмaция
o пaциeнтax;
·
инфopмaция
o вpaчax;
·
инфopмaция
o полученных процедурах;
·
инфopмaция
o процедурах на аппаратах лучевой терапии и предлучевой подготовки.
Для бoлee удoбнoй paбoты c инфopмaциeй были
paзpaбoтaны выxoдныe дoкумeнты в виде oтчeта.
Тaк кaк инфopмaция o зaбoлeвaнияx и cocтoянии здopoвья
бoльныx являeтcя кoнфидeнциaльнoй, то дocтуп к БД имеют coтpудники,
занимающихся подготовкой отчёта.
Первый шаг в
построении концептуальной модели данных состоит в определении основных объектов
(сущностей), которые могут интересовать пользователя и, следовательно, должны
храниться в БД.
Для данной
концептуальной модели были выделены следующие объекты (сущности): пациенты,
врачи, общие нозологии, виды лечения, диагнозы, стадии, эффект от лечения,
методы лечения.
Каждая сущность должна обладать некоторыми
свойствами:
·
должна иметь уникальное имя, и к одному и тому же
имени должна всегда применяться одна и та же интерпретация;
·
обладать одним или несколькими атрибутами, которые либо
принадлежат сущности, либо наследуются через связь;
·
обладать одним или несколькими атрибутами
(первичным ключом), которые однозначно идентифицируют каждый экземпляр
сущности, т. е. делают уникальной каждую строку таблицы;
·
может обладать любым количеством связей с другими
сущностями.
Рисунок 1 - Концептуальная схема информационной системы
Логическое проектирование представляет собой
необходимый этап при создании базы данных. Основной задачей логического
проектирования является разработка логической схемы, ориентированной на
выбранную модель данных.
Этапы логического проектирования:
·
выбор модели данных;
·
отображение концептуальной схемы на логическую
схему;
·
выбор ключей.
Модель данных – представление о предметной
области в виде данных и связей между ними. То есть, модель данных – это
совокупность взаимосвязанных структур данных и операций над этими структурами [5,
стр.84].
Понятие “Модель данных” включает три
компонента:
1. Организацию данных (количество и типы объектов модели данных,
ограничения на структуру данных);
2. Множество допустимых операций над данными: операции выборки (поиск), операции
модификации (включить, удалить, изменить данные);
3. Средства обеспечения логической целостности и достоверности данных
(ограничения на значения данных и связи), с помощью которых достигается
непротиворечивость хранимой информации.
Выбор модели данных зависит от объема
информации, сложности решаемых задач и имеющегося технического и программного
обеспечения.
СУБД поддерживает один из типов моделей
данных – сетевую, иерархическую или реляционную.
Иерархическая модель. При использовании
иерархической модели представления данных связи между данными можно
охарактеризовать с помощью упорядоченного графа (или дерева). В
программировании при описании структуры иерархической базы данных применяют тип
данных
«дерево».
Основными достоинствами иерархической модели данных являются:
·
эффективное использование памяти ЭВМ;
·
высокая скорость выполнения основных операций над
данными;
·
удобство работы с иерархически упорядоченной информацией.
Системы управления базами данных, построенные
на основе сетевой модели, также не получили широкого распространения на
практике.
Реляционная модель
основывается на понятии «отношения» (relation). Простейшим примером отношения
служит двумерная таблица[6, с.68].
Достоинствами реляционной
модели представления данных (по сравнению с иерархической и сетевой моделями)
являются ее понятность, простота и удобство практической реализации реляционных
баз данных на
ЭВМ[16, с.276].
Рисунок 3 - Графическое изображение реляционной модели
К недостаткам реляционной модели представления данных относятся:
1. отсутствие стандартных средств идентификации отдельных записей;
2. сложность описания иерархических и сетевых связей.
Большинство СУБД, применяемых как
профессиональными, так и непрофессиональными пользователями, построены на
основе реляционной модели данных (Visual FoxPro и Access фирмы Microsoft,
Oracle фирмы Oracle и др.).
Реляционную модель отличает от остальных
достаточно ценные свойства, одно из которых и самым важным является то, что в
реляционной базе данных можно менять структуру, не внося изменений в
приложения. Такого не скажешь о приложениях, созданных на основе других
структур. Предположим, например, что в таблицу базы данных нужно добавить один
или несколько новых столбцов. В этом случае нет необходимости менять никакое из
написанных приложений, которые будут продолжать обрабатывать эту таблицу,
только если не изменяется столбец, с которым работают эти приложения.
У реляционных баз данных более гибкая
структура. Приложения для таких баз поддерживать легче, чем те, что написаны
для иерархических или сетевых баз данных. Эта гибкость структуры даёт
возможность получать такие комбинации данных, которые, возможно, еще не были
нужны при проектировании базы данных.
В современных СУБД (в том числе MS Access) процесс физического
проектирования БД осуществляется автоматизировано средствами самой СУБД.
При отображении концептуальной модели данных
на логическую реляционную модель каждый прямоугольник схемы (информационный
объект) отображается в таблицу, добавляются атрибуты [10, с. 174]. Ниже
представлена таблица 1 с отображением концептуальной схемы на логическую.
Таблица
|
Ключевое поле
|
Поле
|
Тип данных
|
Пациенты
|
V
|
ID пациента
|
Счётчик
|
|
ФИО пациента
|
Текстовый
|
|
№ карты
|
Числовой
|
|
Год рождения
|
Дата
|
|
Диагноз
|
Числовой
|
|
Стадия
|
Числовой
|
|
Врач
|
Числовой
|
|
Компьютерная
томограмма
|
Логический
|
|
Рентгеноскопия
|
Логический
|
|
Корректировка
изоцентров
|
Логический
|
|
Лучевое лечение на
ЛУ «Primus»
|
Логический
|
|
Лучевое лечение на
ЛУ «Teratron»
|
Логический
|
|
Лучевое лечение на
ЛУ «Elekta»
|
Логический
|
|
Близкофокусная
терапия
|
Логический
|
|
Укладка на
внутриполостном гамма-аппарате «MultiSourse»
|
Логический
|
|
Вид лечения
|
Мастер подстановок
|
|
Эффект от лечения
|
Мастер подстановок
|
|
Метод лечения
|
Мастер подстановок
|
|
Дата начала
лечения
|
Дата/время
|
|
Комментарии
|
Текстовый
|
Диагнозы
|
V
|
ID диагноза
|
Счётчик
|
|
Название диагноза
|
Текстовый
|
|
Общая нозология
|
Мастер подстановок
|
Общие нозологии
|
V
|
ID общей нозологии
|
Счётчик
|
|
Название общей
нозологии
|
Текстовый
|
Врачи
|
V
|
ID врача
|
Счётчик
|
|
ФИО врача
|
Текстовый
|
Стадии
|
V
|
ID стадии
|
Счётчик
|
|
Название стадии
|
Текстовый
|
Виды лечения
|
V
|
ID вида лечения
|
Счётчик
|
|
Название вида
лечения
|
Текстовый
|
Методы лечения
|
V
|
ID метода лечения
|
Счётчик
|
|
Название метода
лечения
|
Текстовый
|
Эффект от лечения
|
V
|
ID эффекта от
лечения
|
Счётчик
|
|
Название эффекта
от лечения
|
Текстовый
|
Таблица 1 – отображение
концептуальной схемы на логическую
Основные функциональные возможности
программы:
Допущенный пользователь (сотрудник организации)
имеет возможности:
1) добавления,
редактирования и удаления сведений о пациентах радиологического отделения;
2) получения
статистических данных в отчётах.
Библиографический
список
1. Базы
данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д. Хомоненко. –
4-е изд. – СПб.: Корона Принт, 2014. – 736.
2. Бемер С.
MS Access 2.0: Пер. с нем. СПб.: BHV - Санкт-Петербург, 1995. 448 с.
3. Богданова
Н. П. Access 2000 - интегрированная среда для работы с данными: Метод, указания
к практ. занятиям / РГРТА. Рязань, 2001.28с.
4. Боровиков, В. В. Microsoft Access
2002. Программирование
и разработка баз данных и приложений / В. В. Боровиков. – М. :
СОЛОН-Р, 2002. – 560 с.
5. Вашакидзе
Н.С. Математическое моделирование Интернет-проектов // Вестник СахГУ. Ю-Сах.:
XXXVI научно-практическая конференция преподавателей, аспирантов СахГУ., 2004
г.
6. Вейскас
Дж. Эффективная работа с Microsoft Access 2000 / Пер. с англ. В. Широкова.
СПб.,–М.,–СПб.,–Киев: Питер, 2000
7. Глушаков
С.В., Ломотько Д.В. «Базы данных», изд. «Фолио», Харьков, 2000г.
8. Глушаков
С.В., Ломотько Д.В. Базы данных: Учебный курс. - Харьков: Фолио; Ростов н/Д:
Феникс; Киев: Абрис, 2000. - 504 с.
9. Гольцман,
В. MySQL 5.0. Библиотека программиста / В. Гольцман. – Питер, 2011. – 370 с.
10. Гончаров A.
Microsoft Access 7.0 в примерах. СПб.: М., 1997. 256с.
11. Кучер Л.В.
Некоторые вопросы курса информатики и информационно-коммуникационных технологий
// Фундаментальные и прикладные исследования в системе образования: материалы
3-й Международной научно-практической конференции. Ч. 4. Тамбов: Першина, 2005.
12. Филиппова Г.В.
Новое информационное состояние общества-объективная причина новых целевых
установок в образовании // Вестник СахГУ. Ю-Сах.: XXXVI научно-практическая
конференция преподавателей, аспирантов СахГУ., 2004 г.
Оставьте свой комментарий
Авторизуйтесь, чтобы задавать вопросы.