СодержаниеОГЛАВЛЕНИЕ
ВВЕДЕНИЕ 2
1. Проектирование базы данных 6
1.1. Концептуальная модель 6
Проектирование модели данных ERD 7
Проектирование физической модели данных 8
2. РАЗРАБОТКА ПРИЛОЖЕНИЯ 13
2.1. Назначение приложения 13
2.2. Структура приложения 15
2.3. Описание приложения 15
2.4. ТЕСТИРОВАНИЕ 20
2.5.Руководство пользователя 21
ЗАКЛЮЧЕНИЕ 23
БИБЛИОГРАФИЯ 24
ПРИЛОЖЕНИЕ 25
ВВЕДЕНИЕ
В наши дни ни одно учреждение не обходится без электронной документации, будь то бухгалтерские отчёты или учётные записи клиентов. Информационные технологии внедряются для повышения скорости (уменьшения задержки) и эффективности (уменьшение шанса искажения и/или утраты данных) работы с архивами данных, поэтому ожидается, что при использовании оргтехники и специализированного программного обеспечения скорость и качество работы с банками данных, которые при переводе в электронный вид получают название «баз данных», возрастают. Для этого необходимы не только терминальная ЭВМ, локальная сеть и навыки оператора ЭВМ, но и вышеупомянутое специализированное программное обеспечение, позволяющее быстро находить и изменять нужные записи, добавлять новые, без труда генерировать полные отчёты, сортировать записи, предохранять базу данных от ошибок и сбоев, и при этом доступное в освоении и нетребовательное к любым ресурсам пользователя (оборудование, профессионализм, время). Поэтому всякое учреждение, пользующееся вычислительной техникой для ведения документации, использует либо коммерческие системы управления базами данных (в дальнейшем СУБД), специально разработанные для решения универсальных задач определённого круга, либо ПО, разработанное штатными программистами учреждения.
Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия или учреждения.
Такая система должна обеспечивать получение общих и/или детализированных отчетов по итогам работы; позволять легко определять тенденции изменения важнейших показателей; обеспечивать получение информации, критичной по времени, без существенных задержек; выполнять точный и полный анализ данных. Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, чем среда MS-DOS. Снижение стоимости высокопроизводительных ПК обусловило не только повсеместный переход к среде Windows, где разработчик программного обеспечения может в меньшей степени заботиться о распределении ресурсов, но также сделало программное обеспечение СУБД менее критичным к аппаратным ресурсам ЭВМ.
Среди наиболее надежных и мощных систем управления базами данных можно отметить: Microsoft Access, Microsoft Visual FoxPro, а также базы данных Microsoft SQL Server, используемые в приложениях, построенных по технологии «клиент-сервер».
В курсовой работе освещена проблема автоматизации ведения электронной документации регистратуры поликлиники: спроектирована многопользовательская база данных, разработаны дружественные клиентские интерфейсы и пакет документации, реализованы ADО и СОМ технологии, добавлена справочная информация, позволяющая разобраться в программном интерфейсе.
Опыт применения ЭВМ для построения прикладных систем обработки данных показывает, что самым эффективным инструментом здесь являются не универсальные алгоритмические языки высокого уровня, а специализированные языки для создания систем управления данными. Такие средства обычно включаются в состав СУБД, но они могут существовать и отдельно. СУБД дают возможность пользователям осуществлять непосредственное управление данными, а программистам быстро разрабатывать более совершенные программные средства их обработки.
Работа данного программного продукта осуществляется на базе платформ MS SQL Server 2005 и BORLAND DELPHI 7.
Система Delphi давно пользуется репутацией самого эффективного средства разработки приложений баз данных, то есть программ, обслуживающих электронные хранилища информации. Начиная с версии 5.0 Delphi поддерживает технологию ADO (ActiveX Data Objects), которая усиленно развивается корпорацией Microsoft. Основные особенности использования технологии ADO не зависят от архитектуры БД: эта технология характерна не только для файл-серверных, но и для клиент-серверных, а также трёхзвенных БД, основным же достоинством технологии ADO является её естественная ориентация на создание «облегчённого» клиента. В рамках этой технологии на машине разработчика устанавливаются базовые объекты MS ADO и соответствующие компоненты Delphi. На машине сервера данных (это может быть файловый сервер в рамках файл-серверной технологии или машина с сервером данных – в технологии клиент-сервер) устанавливается так называемый провайдер данных – некоторая надстройка над специальной технологией OLE DB, распознающая запросы объектов ADO и трансформирующая эти запросы в нужные действия с данными. Взаимодействие компонентов ADO и провайдера осуществляется на основе универсальной для Windows технологии ActiveX, причем провайдер выступает в качестве СОМ-сервера, а ADO-компоненты – в качестве СОМ-клиентов.
Модель СОМ представляет собой возможность создания многократно используемых объектов в различных приложениях, поддерживающих этот интерфейс. Объектами СОМ являются приложения-серверы, специально оформленные и зарегистрированные в системе. Они могут быть представлены в формате EXE- или DLL-модулей. Эти серверы могут загружаться и выполняться как в адресном пространстве вызывающего приложения, так и в виде самостоятельного процесса, или на другом компьютере сети (распределенная модель СОМ - DCOM). Они должны быть написаны на любом языке, поддерживающем интерфейс СОМ.
Развитие технологии СОМ продолжает её подмножество – технология OLE Automation(автоматизация OLE). Её отличие в том, что она позволяет использовать возможности СОМ не только языкам-компиляторам, но и интерпретаторам, и обеспечивает связь с вызываемыми методами на стадии выполнения приложения. Такой способ вызова называется поздним связыванием. Методы при таком способе вызова выполняются медленнее, причем нельзя заранее проверить правильность написания объектов и их методов. Преимуществом такого метода является независимость выбора среды разработки от объекта, который нужно программировать.
В разработанном приложении реализован СОМ-интерфейс (в частности, у пользователя есть возможность вывода полных отчётов по вакансиям, клиентам или фирмам в виде листов Excel), позволяющий пользователю получать выходные данные в удобном для дальнейшей обработки формате электронных таблиц; среда Delphi поддерживает методы вызова серверов автоматизации.
Система управления базами данных типа "клиент-сервер" состоит из двух компонентов:
• Программы, предоставляющей пользовательский интерфейс клиентских приложений для доступа к базе данных.
• Структура базы данных, реализующая управление и хранение данных на сервере.
База данных в SQL Server 2000 состоит из коллекции таблиц, в которой хранится особый набор структурированных данных. Таблица содержит коллекцию строк, также называемых записями или кортежами, и столбцов, также называемых атрибутами. Каждый столбец в таблице предназначен для хранения конкретного типа данных, например дат, имен, денежных сумм или чисел.
У таблиц есть несколько типов элементов управления: ограничения, триггеры, значения по умолчанию, хранимые процедуры, а также пользовательские типы данных, которые гарантируют достоверность данных. Чтобы обеспечить согласованность взаимосвязанных данных в различных таблицах, в таблицу можно добавить декларативные ограничения ссылочной целостности. У таблиц могут быть индексы, похожие на алфавитные указатели в книгах, позволяющие быстро найти нужные записи. Выбор MS SQL Server 2005 в качестве СУБД обусловлен многопользовательской архитектурой разрабатываемого приложения, а также простотой и гибкостью подъязыка данных T-SQL.
1. Проектирование базы данных
1.1. Концептуальная модель
Диаграмма потоков данных (DFD) является средством моделирования функций требований к проектированию системы. С их помощью представлены эти требования в виде иерархий функций компонентов, связанных потоков процессов. Главная цель такого преставления – демонстрация того, что каждый процесс использует свои входные и выходные данные. Процесс представляет собой преобразование входных потоков данных в соответствии с заложенным алгоритмом в выходные данные.
Разрабатываемая база данных является реляционной, т.е. структура базы будет представлена в виде 2-х мерных таблиц.
1. Входная информация
Список специальностей врачей
Список кабинетов
Список врачей
Список пациентов
Расписание
2. Информационные объекты
Регистрация посещения врачей пациентами
Запрос поиска по расписанию
Запрос поиска по специальности
3. Выходные данные
Статистическая информация
Отчет по приему врачей
Схема DFD представлена в таблице №2:
Таблица №2 “Схема потоков данных”
Входные Данные (на бумаге) Накопительные данные (Представления электронных таблиц) Выходные данные
Список
врачей Список врачей
Список пациентов Список пациентов Отчет по приему врачей
Список дней недели Список дней недели Расписание приема
Статистический отчет
Запрос приема врачом
Проектирование модели данных ERD
После выделения информационных объектов необходимо установить связи между ними и построить информационно-логическую модель данных (схема ERD).
Связь между парой информационных объектов являются логической связью. Связи двух информационных объектов характеризуются групповыми отношениями одного из видов:
- один к одному (1: 1);
- один ко многим (1: М);
- многие ко многим (М: N).
Графически схема ERD выглядит следующим образом:
Рис.1 Модель данных ERD (Стандарт IDEF1X)
Проектирование физической модели данных
В этом разделе приведена структура всех таблиц, включающая смысловое значение поля, тип данных и ограничения.ВведениеВ состав базы данных входят следующие объекты:
Представления
1. VIEW_doctor содержит информацию о фамилиях врачей, специальностях, названиях и номерах кабинетов.
2. VIEW_raspisanie содержит информацию о фамилии врача, названии дня недели, времени начала и окончании приема.
3. VIEW1 содержит информацию о фамилии врача, специальности, кабинете, времени приема в настоящий день.
4. stat_priem содержит информацию офамилии, специальности и количестве пациентов, принятых данным врачом.
Хранимые процедуры.
1. Процедура redrasp(@v int ,@d int,@b int,@e int) с параметрами
@v – идентификатор врача;
@d – идентификатор названия дня;
@b – час начала приема;
@e – час окончания приема.
Если запись о приеме в данный день недели присутствует, то она корректируется, в противном случае добавляется в таблицу.
2. РАЗРАБОТКА ПРИЛОЖЕНИЯ
2.1. Назначение приложения
Автоматизированная информационная система (в дальнейшем АИС) позволяет пользователю формировать команды операций с данными на высоком уровне, приближенном к человеческому восприятию, не вдаваясь в технические подробности реализации процессов. АИС обеспечивает:
• ввод и хранение необходимой для работы информации;
• целостность данных;
• обновление информации в базе данных (БД);
Задачи, решаемые АИС:
• хранение информации о пациентах;
• хранение информации о врачах;
• хранение информации о кабинетах;
• формирование отчетных документов.
Требования к надежности и безопасности
АИС должна помимо эргономики и технологичности иметь определённый «запас прочности», обеспечивающий работоспособность системы в непредвиденных ситуациях. В АИС должны быть предусмотрены следующие меры защиты данных и работоспособности:
• контроль вводимой информации;
• блокировка некорректных действий пользователя при работе с базой;
• запросы на подтверждение необратимых действий (удаление);
• резервное копирование данных и восстановление в случае утраты.
Требования к составу и параметрам технических средств
Минимальные системные требования:
• Тип процессора: Pentium-II 400 Mhz;
• Объем оперативного запоминающего устройства (RAM): 512 Mb;
• Объём свободного дискового пространства не менее 200 Мб.
Требование к оперативной памяти устанавливается в силу системных требований MS SQL Server 2005.
Рекомендуемые системные требования:
• Тип процессора: Pentium-III 600 Mhz;
• Объем оперативного запоминающего устройства (RAM): 1024 Mb;
• Объём свободного дискового пространства не менее 350 Мб.
Условия эксплуатации
Для устойчивой работы программы пользователь должен указывать все параметры, заданные раскрывающимися списками, и не вводить в поля, требующие числовой информации, символьные данные.
Требования к информационной и программной совместимости
Система должна работать под управлением семейства информационных систем: Windows 2000, Windows XP, Windows Vista и последующих модификаций.
2.2. Структура приложения
Разработанная программа имеет многопользовательскую, а именно трёхзвенную архитектуру, так как предполагается хранение данных на сервере и одновременная работа с ними нескольких клиентских приложений. Основной целью использования трехзвенной архитектуры является снижение требований к клиентским компьютерам; для достижения этой цели значительная часть программных ресурсов клиента выносится в промежуточное звено между клиентом и сервером – сервер приложений. Как следствие, программы с трёхзвенной архитектурой можно использовать на дешёвых бездисковых терминалах.
2.3. Описание приложения
Пользовательский интерфейс реализован на уровне свободной навигации: доступ к различным компонентам приложения осуществляется через строку главного меню. Используется SDI-интерфейс в силу непопулярности MDI-интерфейсов и отсутствия необходимости использования дочерних форм.
Все программные модули написаны при использовании среды разработки Delph 7.0.
В проекте используются следующие классы форм:
1. Form1 – форма главного окна программы. Содержит главное меню, через элементы которого осуществляется доступ к другим формам, а так же содержит таблицу с расписанием приёма в поликлинике.ЛитератураГолицына О., Максимов Н., Попов И. Базы Данных – Учебное пособие. М.: ФОРУМ: ИНФРА-М, 2005. – 352 стр.
Крёнке Д., Теория и практика построения баз данных. 9-е изд. – СПб: ПИТЕР, 2005, 859 стр.
Фаронов В. Delphi. Программирование на языке высокого уровня: Учебник для вузов – СПб: ПИТЕР, 2005. – 640 стр.
Фаронов В. Программирование баз данных в Delphi. Учебный курс. – СПб: ПИТЕР, 2005. – 459 стр.
|
|
