Разработка информационной системы Поликлиника. Диплом. Содержание Введение 4 1 Теоретическая часть 6 2 Обоснование выбора среды разработки 13
 Скачать 1.03 Mb.
|
 Содержание Введение 4 1 Теоретическая часть 6 2 Обоснование выбора среды разработки 13 3 Описание разработанного проекта 21 3.1 Описание предметной области 21 3.2 Концептуальная модель 23 3.3 Логическая модель базы данных 28 3.4 Модель физической организации данных 30 3.5 Разработка экранных форм 34 3.6. Разработка отчетов 40 3.7 Руководство пользователя 41 4 Экономическая часть 43 5 Техника безопасности при работе с ПК 52 5.1 Общие требования безопасности 52 5.2 Требования безопасности перед началом и во время работы 54 5.3 Требования безопасности в аварийных ситуациях 61 5.4 Требования безопасности по окончании работы 62 Заключение 63 Список использованных источников 65 Приложение А Отчеты информационной системы 67 ВведениеОдной из актуальных проблем любого вида человеческой деятельности является проблема обработки увеличивающегося потока информации. Перспективным способом решения данной проблемы является автоматизация работы с информацией, в частности, создание компьютерных баз данных, позволяющих хранить, систематизировать и обрабатывать данные. Компьютерные информационные технологии находят все большее применение в медицинской деятельности. За последние годы значительно увеличилось количество новых методов диагностики и лечения. Объем информации о состоянии здоровья пациентов, который необходимо обрабатывать врачу, значительно вырос. К примеру, номенклатура различных лабораторных показателей, постоянно расширяясь, достигла в настоящее время 400 , при этом по оценкам экспертов, результаты работы лаборатории предоставляют врачу до 80% наиболее важной и необходимой для диагностики информации. Кроме того, данные о состоянии здоровья каждого пациента рассредоточены, как правило, по нескольким медицинским учреждениям, оказывающим помощь в профилактике и лечении заболеваний. В 2008 году в России появляется ГОСТ Р 52636-2006 «Электронная история болезни» [1, 2, 3, 4], который установил общие положения для разработки требований к организации создания, сопровождения и использования информационных систем типа «электронная история болезни»[5]. Целью данной работы является создание базы данных больницы. Она предназначена для хранения информации о врачах, пациентах клиники, вспомогательной информации о распорядке работы больницы (кабинеты, графики работы) и приеме больных, с возможностью внесения данных, выборки и изменения данных, вывода информации в необходимом формате. Объектом исследования является работа поликлиники. Предмет исследования в дипломной работе является информационная система автоматизирующая работу поликлиники. В соответствии с поставленной целью в работе определены следующие задачи: произвести анализ литературы и Internet-источников, посвященных работе регистратора поликлиники с целью разработки базы данных поликлиника; произвести опрос регистраторов поликлиники и наблюдать за их работой; изучить предметную область; составить модель данных; реализовать модель с помощью выбранной СУБД. 1 Теоретическая частьВсякая прикладная программа, является отображением какой – то части реального мира и поэтому содержит его формализованное описание в виде данных. Крупные массивы данных размещают, как правило, отдельно от исполняемой программы, и организуют в виде Базы данных. Базу данных можно определить как совокупность взаимосвязанных хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений; данные запоминаются так, чтобы они были независимы от программ, использующих эти данные; для добавления новых или модификации существующих данных, а также для поиска данных в базе данных применяется общий управляемый способ. [7, 8]. Начиная с 60-х годов для работы с данными, стали использовать особые программные комплексы, называемые системами управления базами данных (СУБД). Системы управления базами данных отвечают за: физическое размещение данных и их описаний; поиск данных; поддержание баз данных в актуальном состоянии; защиту данных от некорректных обновлений и несанкционированного доступа; обслуживание одновременных запросов к данным от нескольких пользователей (прикладных программ). В теории проектирования информационных систем предметную область принято рассматривать в виде трех представлений: представление предметной области в том виде, как она реально существует как ее воспринимает человек (имеется в виду проектировщик базы данных) как она может быть описана с помощью символов. Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление. Методически правильно начинать работу с карандашом и листом бумаги в руках, не используя компьютер. Неоптимальные решения и прямые ошибки, заложенные на этапе проектирования, впоследствии очень трудно устраняются, поэтому этот этап является основополагающим. При проектировании концептуальной модели структурируют данные и выявляют взаимосвязи между ними, без рассмотрения особенностей реализации и вопросов эффективности обработки. Концептуальная модель изменяется так, чтобы она могла быть обеспечена конкретной моделью данных. В результате формируется логическая модель. Логическая модель, отражающая логические связи между элементами данных вне зависимости от их содержания и среды хранения. Логическая модель может быть реляционной, иерархической или сетевой. Логическая модель отображается в физическую память, так чтобы она могла быть обеспечена конкретной СУБД. Внутренняя модель системы это физическая модель, определяющая размещение данных, методы доступа и технику индексирования. Процесс построения информационной модели изображен на рисунке 1.  Рисунок 1 - Процесс построения информационной модели Требования к БД БД должна удовлетворять информационным требованиям организации; БД должна обеспечивать получение требуемых данных за определенное время; БД должна легко расширяться и изменяться; доступ к данным должен быть ограничен. Необходимо защитить данные от несанкционированного использования или изменения. Основные этапы, на которые разбивается процесс проектирования базы данных информационной системы. Этап 1. Проектирование инфологической концептуальной модели баз данных: исследование предметной области применения и выявление требований конечных пользователей и решаемых задач; анализ данных: сбор основных данных (объекты, связи между объектами); моделирование и интеграция всех представлений [9]. Построение ER-диаграммы базы данных [10]. Концептуальное проектирование - сбор, анализ и редактирование требований к данным. По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь" [11]. Концептуальное представление – это представление всей информации БД в несколько более абстрактной форме (как и случае внешнего представления) по сравнению с физическим способом хранения данных. Однако концептуальное представление существенно отличается от способа представления данных какому-либо отдельному пользователю. Концептуальное представление – это представление данных такими, какие «они есть на самом деле», а не такими, какими вынужден их видеть пользователь в рамках, например, определенного языка или используемого аппаратного обеспечения. Концептуальное представление состоит из множества экземпляров каждого типа концептуальной записи. Например, оно может состоять из набора экземпляров записей, содержащих информацию об отдельных, плюс набор экземпляров, содержащих информацию о деталях и т.д. Концептуальная запись вовсе не обязательно должна совпадать с внешней записью, с одной стороны, и с хранимой записью- с другой. Концептуальное представление определяется с помощью концептуальной схемы, которая включает определения каждого типа концептуальных записей. Концептуальная схема использует другой язык определения данных - концептуальный. Концептуальное представление – это представление всего содержимого базы данных, а концептуальная схема – это определение такого представления. Однако было бы ошибкой полагать, что концептуальная схема – это не более чем набор определений, больше напоминающих простые отношения записей в программе на языке COBOL (или каком-либо другом) [12]. Этап 2. Проектирование даталогической модели базы данных (учитывать требования СУБД). Потенциально возможные прикладные программы: сбор информации о потенциальных возможностях использования данных [10]. Логическое проектирование - преобразование требований к данным в структуры данных. Описание, создаваемое по инфологической модели данных, называют даталогической моделью данных. Даталогическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения. Пользователям выделяются подмножества этой логической модели, называемые внешними моделями, отражающие их представления о предметной области. Внешняя модель соответствует представлениям, которые пользователи получают на основе логической модели, в то время как концептуальные требования отражают представления, которые пользователи первоначально желали иметь и которые легли в основу разработки инфологической модели. Даталогическая модель отображается в физическую память, такую, как диск, лента или какой-либо другой носитель информации. Даталогическая модель в основном используется прикладными программистами для реализации требований, которые выдвинули конечные пользователи, отражённых в инфологической концептуальной модели. Типы даталогических моделей это есть не что иное, как Модели данных, т.о. даталогическая модель данных может быть реляционной, иерархической или сетевой. При разработке даталогической модели, кроме требований предъявляемых для построения инфологической модели, предъявляются дополнительные требования: загруженные в базу данных корректные данные должны оставаться корректными; данные до включения в базу данных должны проверяться на достоверность; доступ к данным, размещаемым в базе данных, должны иметь только лица с соответствующими полномочиями; разрешение проблем, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами); способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа. Если инфологическая модель данных предназначена для наглядного отражения представления пользователей, т.е. является человеко-ориентированной, то даталогическая модель уже является компьютеро-ориентированной. С её помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных [10]. На выходе получаем СУБД - ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей [9]. Этап 3. Проектирование физической модели базы данных (оценка эксплуатационных характеристик прикладных программ) [11]. Физическая модель данных – модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она так же называется внутренней моделью системы. Внешние модели (даталогические модели) никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах. Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Физическая модель данных является полностью компьютерно-ориентированной. Конечные пользователи, а порой и прикладные программисты, не имеют никакого представления о том, каким образом данные запоминаются и извлекаются или каким способом организуются индексы в таблицах для быстрого поиска или ссылочная целостность. Эти и множество других функций по методам доступа и поддержании баз данных на внешних носителях, а также способов поиска и доступа к данным в современных СУБД обеспечивается в основном ядром базы данных, что значительно облегчает задачу создания БД и их ведение. Трехуровневая архитектура (инфологический (концептуальный), даталогический (логический) и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. Администратор БД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. Администратор БД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений. Этап 4. Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках) [10]. Таблица 1 - Различие уровней представления данных на каждом этапе проектирования
|