Проектирование информационной системы регистратуры поликлиники

Содержание

Введение

1 Проектирование автоматизированных  информационных систем

2 Анализ существующих систем управления базами данных и выбор наилучшей

3 Создание автоматизированной  информационной системы "Поликлиника"

3.1 Информационная модель

3.2 Определение сущностей

3.3 Нормализация отношений

3.4 Определение взаимосвязей

3.5 Описание физической  модели

3.6 Проектирование интерфейса

4 Алгоритм работы информационной системы

Заключение

Введение

Компьютеры давно и  прочно вошли в такие области  управления, как бухгалтерский учет, управление складом, ассортиментом и закупками. Однако современный бизнес требует гораздо более широкого применения информационных технологий в управлении предприятием. Жизнеспособность и развитие информационных технологий объясняется тем, что современный бизнес крайне чувствителен к ошибкам в управлении. Интуиции, личного опыта руководителя и размеров капитала уже мало для того, чтобы быть первым. Для принятия любого грамотного управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности, будь то: торговля, производство или предоставление каких-либо услуг. Поэтому современный подход к управлению предполагает вложение средств в информационные технологии. И чем крупнее предприятие, тем серьезнее должны быть подобные вложения. Они являются жизненной необходимостью — в жесткой конкурентной борьбе одержать победу сможет лишь тот, кто лучше оснащен и наиболее эффективно организован.

Информационная система «Поликлиника» включает в себя данные о врачах, пациентах, кабинетах и вызовах, которые необходимые для работы поликлиники. База данных позволяет осуществлять добавление, изменение, поиск и удаление данных, а также просматривать эти данные.

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

Цель работы: собрать  материал и спроектировать информационную систему для работы регистратуры поликлиники.

1 Проектирование автоматизированных  информационных систем

Модель жизненного цикла (ЖЦ) - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. Существует несколько моделей и стандартов, в той или иной степени регламентирующих жизненный цикл, большинство из них относятся к заказному программному обеспечению и кроме непосредственно ЖЦ регламентируют также и процессы разработки:

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

• Обследование объекта автоматизации (анализ) и формулирование требований пользователей к системе управления.
• Постановка целей. Анализ существующих методов и средств автоматизации аналогичных объектов и формулирование на основании требований пользователя достижимых целей функционирования системы управления. Цели должны быть четкими, явными и измеримыми. Цели должны определять: общее назначение системы, определение разных групп пользователей и их роли, подробное перечисление функций системы, виды необходимой документации, параметры эффективности (производительности), совместимость с другими продуктами и стандартами, конфигурации аппаратуры, средства обеспечения безопасности, методы и средства настройки и обслуживания, методы обеспечения надежности системы. Цели не должны конфликтовать между собой, так как ими необходимо руководствоваться для выработки компромиссных решений на следующих этапах проектирования.
• Разработка архитектуры системы (декомпозиция функциональной структуры и определение связей между ее элементами). Выделение уровней управления, подсистем, комплексов задач, задач и функций управления.
• Разработка инфологической модели системы, описывающей статику и динамику объекта. Формализация моделей состояния объекта, материальных, финансовых и информационных (управляющих) потоков и их взаимодействия между собой.
• Разработка системы классификации объектов учета и управления и идентификации их параметров. Словари описывают основные понятия предметной области системы, необходимые для разработки стандартных алгоритмов обработки данных. Классификаторы описывают структуру объекта (подразделения, сотрудники, должности), внешней среды (клиенты, районы, пункты погрузки/разгрузки), характеристики материальных потоков (партии, фонды, ед. измерения, показатели качества, типы цен, виды оплаты). Типовые операции описывают алгоритмы управления (обработки информации).
• Разработка информационной модели системы (проектирование структур баз данных и их связей).
• Синтез структуры программного обеспечения (агрегирование системы). При объединении отдельных функций управления в программные модули необходимо стремиться к высокой "прочности" и слабому "сцеплению" модулей. Прочность и сцепление модуля являются, соответственно, мерами его внутренних и внешних связей. В зависимости от назначения модулей необходимо стремиться либо к их функциональной прочности (объединение взаимосвязанных функций управления), либо к информационной прочности (объединение функций, выполняемых на ограниченном подмножестве информационного пространства системы).
• Выбор метода сборки и тестирования системы. Известно несколько методов сборки и тестирования сложных программных систем: восходящий, нисходящий, модифицированный нисходящий, большого скачка, метод сэндвича, модифицированный метод сэндвича. Рекомендуется использовать для тестирования системы модифицированный метод сэндвича, при котором модули нижних уровней управления тестируются снизу вверх, а модули верхних уровней управления сначала тестируются автономно, а затем собираются в агрегаты нисходящим методом. Преимуществами предложенного метода являются: высокий параллелизм в программировании модулей, небольшое количество заглушек, минимальное время появления рабочей версии системы. Отметим, что от выбранного метода сборки и тестирования сильно зависит последовательность проектирования и программирования отдельных модулей. Поэтому метод сборки системы необходимо выбрать до начала этапа проектирования модулей.
• Проектирование модулей. Разработка внешних спецификаций, описывающих сопряжения (связи) между модулями, и проектирование логики (алгоритмов) модулей.
• Программирование модулей на выбранных программных средствах. При программировании необходимо помнить, что текст программы необходим для общения с людьми, а не с машиной. Важность этого утверждения станет очевидна, когда наступит этап сопровождения системы. Для повышения надежности программного обеспечения необходимо использовать при программировании метод взаимного недоверия модулей, то есть каждый модуль системы должен относиться с определенной долей недоверия, в разумных пределах, к полученным входным данным и проверять их перед обработкой.
• Интеграция (сборка) системы в соответствии с выбранным методом и ее тестирование. Этапы тестирования: автономное тестирование - контроль отдельного программного модуля изолированно от других модулей, тестирование сопряжений - контроль сопряжений между частями системы, тестирование функций - контроль выполнения системой автоматизируемых функций управления, комплексное тестирование - испытание поведения системы по отношению к исходным целям, тестирование приемлемости - проверка соответствия системы требованиям пользователей. Тестирование - процесс выполнения программы с целью найти в ней ошибки. Существует два подхода к проектированию тестов - тестирование по отношению к спецификациям (не заботясь о тексте программы) и тестирование по отношению к тексту программы (не заботясь о спецификациях). Разумный компромис лежит где-то посередине, смещаясь в ту или другую сторону в зависимости от функций, выполняемых конкретным модулем. Также отметим, что стоимость этапа тестирования составляет до 25% от общей стоимости затрат на разработку системы.
• Разработка методического обеспечения. Руководства пользователей, инструкции по эксплуатации, технологические инструкции.
• Внедрение системы на объекте.
• Сопровождение системы: устранение ошибок и замечаний пользователей, разработка дополнительных режимов и функций управления, функциональное расширение системы. В соответствии со спиральной моделью жизненного цикла программного обеспечения осуществляется переход на 1 - 10 этапы проектирования системы.

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

2 Анализ существующих систем управления базами данных и выбор наилучшей

Современные СУБД в основном являются приложениями Windows, так как  данная среда позволяет более  полно использовать возможности  персональной ЭВМ. Снижение стоимости  высокопроизводительных персональных компьютерах обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам элетроннно-вычислительной машины.

Среди наиболее ярких представителей систем управления базами данных можно  отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии “клиент-сервер”. Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом “де-факто” стала “быстрая разработка приложений” или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе “открытом подходе”, то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с “классическими” СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами “классических” СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии “клиент-сервер”.

Таким образом, на сегодняшний день разработчик не связан рамками какого-либо конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные приложения. Поэтому, более важным представляется общее направление развития СУБД и других средств разработки приложений в настоящее время.

Рассмотрим более подробно программные  продукты компании Microsoft, а именно Visual FoxPro 3.0, Paradox, Visual Basic 4.0, Visual С++, Access 7.0.

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

FoxPro (фирма Fox Software) обладала исключительно высокими скоростными характеристиками и в этом отношении заметно выделялась среди интерпретирующих систем. Сравнительно с dBaseIV ее скорость в несколько раз выше и не уступает скорости систем-компиляторов. Практически по всем показателям Fox-программы работают значительно быстрее Clipper-программ. (Напоминаем - речь пока о версии для DOS’a.) Набор команд и функций, предлагаемых разработчиками FoxPro, по мощи и гибкости отвечает любым требованиям к представлению и обработке данных. Может быть реализован максимально удобный и эффективный пользовательский интерфейс. В FoxPro поддерживаются разнообразные всплывающие и многоуровневые меню, работа с окнами и мышью, реализованы функции низкоуровнего доступа к файлам, управление цветами, настройками принтера, данные могут быть представлены с виде «электронных таблиц» и много еще приятностей и удобностей. В «довиндовскую» эпоху FoxPro был самой быстрой, самой удобной и самой мощной СУБД для компьютеров стандарта IBM PC.

версии 3.0 – процессор 468DX, Windows 3.1, 95, NT, объем оперативной памяти 8 (12) Мб, занимаемый объем на ЖМД 15-80 Мб, а  для Visual FoxPro версии 5.0 (выпущена в 1997 году) – Windows 95 или NT, 486 с тактовой частотой 50 МГц, 10 Мб ОЗУ, от 15 до 240 Мб на ЖМД.

Paradox был разработан компанией  Ansa Software, и первая его версия  увидела свет в 1985 году. Этот  продукт был впоследствии приобретен  компанией Borland. С июля 1996 года  он принадлежит компании Corel и является составной частью Corel Office Professional.В конце 80-х - начале 90-х годов Paradox, принадлежавший тогда компании Borland International, был весьма популярной СУБД, в том числе и в нашей стране, где он одно время занимал устойчивые позиции на рынке средств разработки настольных приложений с базами данных.

Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase - каждая таблица хранится в своем  файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.px).

Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому  для доступа к данным этого  формата требуются специальные  библиотеки. Например, в приложениях, написанных на C или Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая основой Borland Database Engine. Эта библиотека используется ныне в приложениях, созданных с помощью средств разработки Borland (Delphi, C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным различными версиями этой СУБД.

Отметим, однако, что отсутствие <открытости> формата данных имеет и свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью <знающих> этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании <открытых> форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах - все эти сервисы предоставляются Paradox, начиная с первых версий этой СУБД.

По сравнению с аналогичными версиями dBase ранние версии Paradox обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE - Query by Example (запрос по образцу), средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL (Paradox Application Language).

Windows-версии СУБД Paradox, помимо перечисленных выше сервисов, позволяли также манипулировать  данными других форматов, в частности  dBase и данными, хранящимися в  серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных (существенно облегченная версия Paradox 7 под названием Database Desktop по-прежнему входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Paradox как средство разработки приложений и манипуляции данными.

Текущая версия данной СУБД - Paradox 9, поставляется в двух вариантах - Paradox 9 Standalone Edition и Paradox 9 Developer's Edition. Первый из них предназначен для использования в качестве настольной СУБД и входит в Corel Office Professional, второй - в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат: