База данных «Карточка амбулаторного больного»

1. Теоретическая часть

1.1 Анализ и оценка эффективности существующей системы обработки информации

1.2 Особенности СУБД

1.3 Выбор технических и программных средств

1.4 Описание этапов проектирования

2. Практическая часть

2.1 Разработка инфологической модели

2.2 Разработка базы данных

2.3 Разработка программного приложения Заключение Список литературы Приложения

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

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

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

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

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

1. Теоретическая часть

1.1 Анализ и оценка эффективности существующей системы обработки информации

В данной курсовой работе рассматривается система ведения карточек больных в больнице. Карточка заводиться на каждого человека с момента его рождения и ведется до конца его жизни. Первый этап ведения карточек начинается с ее оформления куда записывается: Фамилия, Имя, Отчество, Дата рождения, Домашний адрес, Пол, СНИЛС, Инвалидность, Профессия, Код льготы, Адрес поликлиники к которому относится человек.

Заполнение карточки начинается с введением в нее данных о дате рождения, о весе, росте, о сроке беременности, поле, имя врача принимающего роды, имя, фамилия, отчество матери и отца родившегося ребенка, а также состояние ребенка после появления на свет (к примеру крик был сразу или нет). На 5 день после рождения ребенку делают БЦЖ (прививка от туберкулеза) после отпадения пупка по нормальному состоянию матери ребенка и самого ребенка их выписывают домой под наблюдением детского участкового врача. С этого момента до года в карточке ведется запись данных полученных при ежемесячном потранаже за состоянием ребенка участковым детским врачом и медсестрой. В карточке отмечаются сделанные прививки, советы по уходу за ребенком и в случае заболевания врач в карточке указывает вид заболевания, назначение лекарственных препаратов и отмечается ход лечения вплоть до выздоровления. До года ведется наблюдение за состоянием ребенка ежемесячно. При достижение ребенка годовалого возраста он проходит полное медицинское обследование полученные данные записывают в карточку, но при выявлении хронического заболевания ребенок получает дальнейшее лечение амбулаторное или стационарное. При достижение 18 лет амбулаторная карточка подростка передается во взрослую поликлинику под наблюдение и дальнейшее лечение участковым врачом до конца жизни. При необходимости участковый врач направляет больного на консультацию к узким специалистам (например, к окулисту, хирургу, невропатологу и др.)

Участковый врач проводит и отмечает в амбулаторной карточке результаты ежегодных медицинских осмотров. В дальнейшем в случае выявлений заболеваний в карточке отмечаются результаты обследований (УЗИ, ЭКБ-электродиаграмма, рентген, флюорография, анализы) а также назначение к его лечению. В случае необходимости больного отправляют в больницу на лечение. В больнице на больного заводиться новая карточка в момент его поступления в приемный покой. В приемном покое врач и медсестра заполняют медицинскую стационарную карточку, где отмечается время поступления, дата поступления, фамилия, имя, отчество, домашний адрес, телефон, профессия, диагноз, температура, давление больного и карточка передается в отделение, куда направляют больного. В отделении врач назначает лечение и ряд обследований (анализы, УЗИ, ЭКГ, ФГСД, флюорографию, рентгенографию и т. д.). В карточке т. е. в Истории болезни врач отмечает результаты ежедневных наблюдений за состоянием здоровья больного. В Истории болезни отмечается ход болезни вплоть до его выздоровления или смерти. По окончании лечения больной выписывается из больницы. В случае необходимости в Истории болезни отмечается дата выдачи больничных листов. При выписке больного из стационара или в случае смерти больного стационарная карточка передается в архив больницы. Весь этот процесс учет введения карточек в больнице очень трудоемкий и требует много времени, с целью ускорения обработки всех этих операций разрабатываются специализированные программы, такие как BORLAND C++BUILDER и многие др.

1.2 Особенности СУБД

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

1- Интеграция данных т. е. данные хранятся централизованно составляя динамические обновляемые требования предметной области

2- Максимальная независимость программ от данных выполнение этих требований ведет к тому, что создаются отдельные блоки данных и разрабатываются программы манипулирующие данными на физическом уровне. 1-е называются базами данных, а 2-е СУБД.

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

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

Основная особенность СУБД — это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры.

1.3 Выбор технических и программных средств

Для моей базы данных минимальные требования к используемым техническим и программным средствам: операционная система Microsoft Windows 07 корпорации Microsoft Corporation, процессор 468DX, объем оперативной памяти 16 (32) Мб, занимаемый объем на ЖМД 80 Мб, текстовый редактор Microsoft Word, принтер, а также программа С++ Builder.

С++ Builder — среда объектно-ориентированного визуального проектирования, в которой можно создавать офисные, бухгалтерские, инженерные, информационно-поисковые программы, взаимодействующие во время использования с пользователем благодаря многооконному графическому интерфейсу. Среда Builder позволяет работать с простыми локальными удаленными базами данных и с многозвенными распределенными БД. В среде C++Builder разработка программ ведется на основании современного метода — объектно-ориентированного программирования.

Приложения строятся средой Borland C++ Builder в виде специальных конструкций-проектов, которые выглядят для пользователя как совокупность нескольких файлов. Ни одна программа не может существовать вне структуры-проекта. Действия по управлению проектами осуществляет специальный программный комплекс — Менеджер проектов.

С++ Builder позволяет:

?создавать базы данных любых типов с помощью его инструментария Database Desktop;

?формировать и печатать из приложения сложные отчеты с графиками и таблицами;

? создавать системы помощи для своих и других приложений;

?связывать свои приложения с продуктами Microsoft Excel, Word;

? создавать системы работы с локальными и удаленными базами данных любых типов.

1.4 Описание этапов проектирования

1.Инфологическая модель БД.

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

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

Требования к инфологической модели:

— адекватное отображение предметной области;

— непротиворечивость;

— должна отражать взгляды и потребности всех пользователей системы;

— однозначная трактовка моделей;

— модель должна быть конечной;

— модель должна быть легко расширяемой, то есть иметь возможность ввода новых (удаления) данных без изменения ранее определенных;

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

— должна быть легко реализуемой на ЭВМ;

— должна быть независимой от оборудования и языков организации базы данных на ЭВМ.

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

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

Сущность — любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т. д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром — Москва.

Атрибут — поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т. д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности.

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

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

2. Даталогическая модель БД.

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

3. Физическая модель БД.

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

2. Практическая часть

2.1 Разработка инфологической модели

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

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

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

— наименование заболевания;

— лечение;

— тяжесть;

— лечащий врач.

На рис. 1 представлена полученная инфологическая модель.

S

S

S

S

S

S

S

S

S

S

D

S

S

D

S

S

S

S

S

2.2 Разработка базы данных для хранения и обработки информации

На основе полученной инфологической модели построим схему данных (даталогическую модель данных). Она представлена в двух таблицах (для каждой сущности).

Схема данных для хранения информации о магазинах.

Таблица 1. Схема данных для хранения информации о поставщиках.

Таблица 2.

Прежде, чем начать строить приложения, работающие с базами данных, надо иметь сами базы данных. Вместе с BDE и Borland C++Builder поставляется программа Database Desktop, которая позволяет создавать таблицы баз данных некоторых СУБД, задавать и изменять их структуру.

Для каждого поля создаваемой таблицы, прежде всего, указывается имя (Field Name) — идентификатор поля. Он может включать до 25 символов и не может начинаться с пробела (но внутри пробелы допускаются). Затем надо выбрать тип (Type) данных этого поля. Для этого перейдите в раздел Type поля и щелкните правой кнопкой мыши. Появится список доступных типов, из которого вы можете выбрать необходимый вам.

Разные СУБД по-разному организуют и хранят базы данных. СУБД Paradox используют для каждой таблицы отдельный файл. В этом случае база данных — это каталог, в котором хранятся файлы таблиц. Для создания такого каталога — базы данных необходимо запустить инструмент BDE Administrator (Borland Database Engine) из меню Пуск| Программы| C++Builder.В левой половине окна расположен список существующих баз данных. Создадим новую базы данных. Для этого с главного меню зададим команду Object | New. На данную команду BDE выведет окно. Переименовав название STANDART на BOLNIE, и задав путь, где располагаются таблицы базы данных (Path — обычно это каталог Database DesktopWorkdir) закончим работу с BDE. Итак, мы можем создавать таблицы для базы данных Больных. Загрузим инструментарий Database Desktop. Через главное меню составим команду File | New | Table. На запрос системы выберем платформу таблиц СУБД Paradox v.7. В открывшееся окно введем структуру таблицы Больные.db. Аналогичными действиями создадим таблицу вид заболевания.db.В этой таблице первичным ключом установим наименование заболевания (поле Naim). Введем данные сначала в таблицу вид заболевания. Для этих целей можно использовать горячую кнопку «Open Table». В открывшуюся таблицу можно внести данные о наименованиях заболеваний. Для этих целей на панели инструментов расположена кнопка редактирования (Edit Data), «нажатие» которой добавляет новую запись с данными по умолчанию, готовую для редактирования. Введем наименования заболевания. После этого закроем окно с таблицей.

Откроем таблицу Больные. Выберем пункт меню Table|Restructure, позволяющий изменять свойства таблицы, при этом окно аналогично окну создания таблицы. Выберем в спадающем списке пункт Secondary Indexes. Нажав кнопку «Define.» откроем окно, в котором слева расположены поля таблицы, а справа пустое окно, в которое заносятся поля, по которым создается индекс.

Следующим свойством таблицы настроим Table Lookup. Нажмем на кнопку Define. — на что система откроет окно. В поле Fields выберем Naim.(A25) и нажмем на кнопку со стрелкой направленную от окна с полями. С правой стороны последовательно выберем Alias — больные, а в ней таблицу вид заболевания. db и нажмем на кнопку со стрелкой налево. Закрепим установки кнопкой ОК.

Теперь введем в таблицу Больные данные о 12 больных в больнице, при этом в поле Naim можно занести данные только те, которые введены в таблицу вид заболевания. Для этого нажимаем клавиши Ctrl+Space, что приводит к открытию окна Lookup Help, после чего выбираем существующие наименования заболевания. Следующим шагом настроим свойства таблицы Больные Referential Integrity. Прежде, чем связать две таблицы, необходимо выбрать их как головную и вспомогательную. Но сначала надо установить в качестве рабочего каталога, каталог с таблицами. Для этого зададим команду File | Working Directory. Затем откроем таблицу Больные, и войдем для нее в режим реструктуризации (Restructure) и в окне Table properties выберем раздел Referential Integrity.

Затем щелкнем на кнопке «Define…», после чего откроется диалоговое окно. На его левой панели Fields выбираем поле Naim (A30), связываемых с ключевым полем головной таблицы (Больные.db), и кнопкой со стрелкой перенесем их в список дочерних полей Child fields.

Затем на правой панели Table можно указать головную таблицу и кнопкой со стрелкой перенести ключ в список ключей родительской таблицы Parent’s key. (Приложение 1)

2.3 Разработка программного приложения

Язык SQL (Structured Query Language — язык структурированных запросов) был создан Microsoft в конце 70-ых годов и получил через некоторое время широкое распространение. Он позволяет формировать весьма сложные запросы к базам данных. Запрос — это вопрос к базе данных, возвращающий запись или множество записей, удовлетворяющих вопросу.

C++Builder позволяет приложению при помощи запросов SQL использовать данные:

* Таблиц PARADOX и dBase используется синтаксис локального SQL.

* Локального сервера InterBase — полностью поддерживается соответствующий синтаксис.

* Удаленных серверов SQL через драйверы SQL Links.

В Borland C++Builder имеется специальный компонент набора данных Query, являющийся аналогом Таblе, но позволяющий работать с SQL

1. Создание простого приложение. Подключение к форме компонентов DataSource, Query, DBGrid, причем в качестве базы данных используем таблицы созданные в лабораторной работе № 2. Выведение в сетку таблицы (DBGrid).

Откроем новое приложение (File/New/Application) Borland C++Builder, перенесём на форму компонент Query со страницы библиотеки Data Access (BDE) и установим его свойство DatabaseName равным имени созданной нами базы данных (BOLNIE). Поместим на форму компонент DataSource со страницы Доступ к данным (Data Access). Его свойству Name соответствует Datasource1, а свойству DataSet задайте Queryl. Поместим также на форму компонент DBGrid (Управление данными — Data Control) и в его свойстве DataSource зададим DataSourcel

Теперь наше приложение для экспериментов с языком SQL готово. Операторы SQL можем писать в свойстве SQL компонента Queryl, а чтобы увидеть результаты выполнения написанного оператора, надо будет устанавливать значение свойства Active компонента Queryl в true. Это надо будет делать после записи каждого нового оператора. В свойстве SQL запишем оператор: Select Naim as Наим_заболевания, Lech. as Лечение, TYAJ as Тяжесть, LECH_V as Лечащий_врач from VID_ZABOLEVANIYA

Установим свойство Active в true и убедимся, что все работает нормально: в DBGridI должно отобразиться содержимое таблицы VID_ZABOLEVANIYA. Добавив компоненту DBNavigator и установив свойство DataSource равным DataSource1 запустим на выполнение полученное приложение.

Создадим другую аналогичную цепочку, перенеся на форму компоненты Query2, DataSource2. DBGrid2, и связав ее с таблицей BOLNIYE запросом:

Select * from BOLNIYE

в компоненте Qnery2. Установим свойство Active компонента Query2 в true и в DBGrid2 должно отобразиться содержимое таблицы BOLNIYE. Запустим приложение и убедимся, что оно работает, причем таблицы независимы. Теперь давайте, свяжем эти таблицы. Делается это следующим образом. Изменим текст запроса в свойстве SQL вспомогательного компонента набора данных Query2 на:

Select NOM_K as НОМЕР_КАРТОЧКИ, NOM_STRAH as НОМЕР_СТРАХ_ПОЛИСА, KOD_L as КОД_ЛЬГОТЫ, NOM_TEL as НОМЕР_ТЕЛЕФОНА, ADRES_MED as АДРЕС_МЕД_УЧРЕЖДЕНИЯ, FAM as Фамилия, IMYA as Имя, OTCHESTVO as Отчество, POL as Пол, ADRES_POST_JITELSTVA as АДРЕС_ПОСТ_ЖИТЕЛЬСТВА, ADRES_REGIS as АДРЕС_РЕГИСТРАЦИИ, INVALIDNOST as ИНВАЛИДНОСТЬ, PROFESSIYA as ПРОФЕССИЯ, NAIM as НАИМ_ЗАБОЛЕВАНИЯ from BOLNIYE where (NAIM=:НАИМ_ЗАБОЛЕВАНИЯ) В этом запросе мы указываем условие отбора: значение поля NAIM должно быть равно параметру НАИМ_ЗАБОЛЕВАНИЯ. В данном случае не надо определять этот параметр с помощью редактора параметров, вызываемого из свойства Params компонента Query2. Вместо этого в свойстве DataSource компонента Query2 надо сослаться на: DataSourcel — источник данных, связанный с таблицей VID_ZABOLEVANIYA. Это скажет приложению, что оно должно взять значения параметра НАИМ_ЗАБОЛЕВАНИЯ из текущей записи этого источника данных. Таким образом, вспомогательная таблица, запрашиваемая в Query2, оказывается связанной с головной таблицей, запрашиваемой в Queryl

Добавив компоненты визуализации Label (свойство Caption) DBText (свойства DataSource=DataSource1, DataField = наим_заболевания) получим конечную форму приложении.

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

Рис. 2. Страница запросы к данным На странице ввод и редактирование размещаем: компоненты доступа к данным DataSource3, Table1. К компоненте Table1 в ИО установим свойства DatabaseName = BOLNIYE, TableName = BOLNIYE.db, а компоненте DataSource свойство DataSet = Table1. Для отображения данных используем компоненты DBGrid1, Edit. Для управления перемещением используем компоненту DBNavigator, причем используем только кнопки перемещения, заблокировав остальные (VisibleButton).Для работы установим основное свойство DataSource = DataSource1. Установим также три кнопки (TButton) для ввода, редактирования и удаления записей. Для выбора наим_заболевания используем компоненту ComboBox. Для улучшения внешнего вида расставим метки (Label) отображающие пояснительный текст на приложении, а также настроим таблицу DBGrid. Для этого выполним двойной щелчок на компоненте Table, что приведет к открытию окна. Указав на поле окна и нажав на правую кнопку мыши, выберем пункт «Добавить все поля». Используя свойства Alignment, DisplayLabel (заголовок столбца), DisplayWidth (ширина столбца), DisplayValues(отображаемые значения), ReadOnly (только для чтения), Visible (видимость поля). Закончим настройку окна приложения. При открытии приложения необходимо передать значения в поля окон редактирования. Для этого в обработчик событий ИО для события OnCreate вводим соответствующий код. При перемещении по базе данных с использованием навигатора либо непосредственно в сетке таблицы (DBGrid) необходимо обновлять значения полей окон редактирования для этого в обработчик событий ИО AfterScroll для Table1 вводим соответствующий код. Перейдем к компонентам TButton. Для кнопки «Записать», «Вставить» и «Удалить» в событие OnClick вводим соответствующий код. (Приложение 2).

Для запуска нажимаем кнопку (рис 3)

Рис. 3. Страница ввод и редактирование На странице Поиск и Фильтрация размещаем: по одному компоненту DBGrid, DBNavigator, 5 компонентов Edit, 1 компонент ComboBox и 1 компонент RadioGroup (с именем RGF). Со страницы Samples на форму перенесены 2 компоненты CSpinEdit, с помощью которых данные о больных фильтруются по его количеству. Для компоненты CSpinEdit1 установлены свойства: MinValue=4, MaxValue=34 609.Такие же свойства задаем для компоненты CSpinEdit2: MinValue=4, MaxValue=34 609. В свойстве Name компонентов CSpinEdit1 и CSpinEdit2 меняем имена соответственно на SEmin, SEmax.

Для компоненты RadioGroup установлены такие свойства: Caption=Фильтрация, Items=Все, Поставщик, Количество тавара, Columns=3. В событии OnClick компонента RadioGroup записываем код который будет осуществлять фильтрацию (Приложение 2).

В свойствах Items для компонента ComboBox внесена информация о поставщиках. Свойству ItemIndex присвоено значение 0. Для каждой компоненты Edit размещены компоненты Label с соответствующими надписями. Для компоненты Edit1 в событии OnChange записываем соответствующий код который будет осуществлять поиск (Приложение 2). Использованные также свойства Font и Color придали странице вид. После выполнения всех указанных действий и создания программного кода на этой странице компоненты PageControl будет происходить поиск и фильтрование данных.

Рис. 3. Страница Поиск и фильтрация данных.

Для создания отчетов в Borland C++Builder включена система QuickReport. Компоненты этой системы размещены на странице QReport палитры компонентов. Для создания отчета на странице Отчет размещаем 2 кнопки Button. 1-му присваиваем имя-Печать, 2-му — Предварительный просмотр. На форме 1 создаем форму 2 и размещаем следующие компоненты: QuickRep, Table, DataSource.Зададим для Table имя базы данных и имя таблицы (DatabaseName = BOLNIYE, TableName= BOLNIYE.db), а для источника данных DataSource (DataSet = Table3).

Свяжем компонент отчетов QuickRep с таблицей данных (DataSet = Table3). Разместим на верхней строке отчета компоненту QRSysData. В свойстве Data установим вывод системной даты.

Установим печать заголовка и поместим в ней метку QRLabel с заголовком «Список больных», а также шапку таблицы.

Перенесем компонент QRSubDetail, который осуществляет циклический вывод записей на печать. Остается вставить компоненты QRDBText задав им свойства DataSet и DataField - Table1 и имена соответствующих полей. Затем сохраняем Unit2 через File- Include Unit Hdr., аналогично сохраняем Unit. Для кнопки «Печать» и «Предварительный просмотр» в событие On Click записываем соответствующий код.(Приложение 2)

После завершения работы на C++Builder задаем имя нашему проекту для хранения его в БД и закрываем приложение. Для запуска нажимаем кнопку (рис 4)

Заключение

Вся проделанная работа заключалась в автоматизации введения карточек в больнице с помощью программы Borland C++ Builder 6. С помощью этой программы можно осуществлять автоматизации и других предметных областей.

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

Работа с программой Borland C++ Builder 6 актуальна в наше время, многие информатики-экономисты используют ее в своей практической работе.

1. Диго С. М. Проектирование баз данных. М.: Финансы и статистика, 2002 г.

2. Марков А. С. Базы данных.

Введение

в теорию и методологию. М.: Финансы и статистика, 2002 г.

3. Мейер Д. Теория реляционных баз данных. М., 1987. 608 с., ил.

4. Тихонов А. Ф., Тихонова Л. Н. Visual FoxPro 5.0. М., 1997. 466 с.

5. Архангельский А. Я. Программирование в C++ Builder 6 — М: ЗАО «Издательство БИНОМ» 2002 г.

6. Архангельский А. Я. Интегрированная среда разработки C++ Builder 5 — М: ЗАО «Издательство БИНОМ», 2000 г.

7. Архангельский А. Я. Работа с локальными базами данных в C++ Builder 5 — М: ЗАО «Издательство БИНОМ», 2000 г.

8. Архангельский А. Я. Язык SQL в C++ Builder 5 — М: ЗАО «Издательство БИНОМ», 2000 г.

Приложение

Приложение 1

Приложение 2

#include

#pragma hdrstop

#include «Unit1.h»

//—————————————————————————————————————;

#pragma package (smart_init)

#pragma link «CSPIN»

#pragma resource «*.dfm»

TForm1 *Form1;

//—————————————————————————————————————;

__fastcall TForm1: TForm1(TComponent* Owner)

: TForm (Owner)

{

}

//—————————————————————————————————————;

void __fastcall TForm1: FormCreate (TObject *Sender)

{ENOM_K->Text = Table1NOM_K->AsString;

ENOM_STRAH->Text = Table1NOM_STRAH->AsString;

EKOD_L->Text = Table1KOD_L->AsString;

EFAM->Text = Table1FAM->AsString;

EIMYA->Text = Table1IMYA->AsString;

EOTCHESTVO->Text = Table1OTCHESTVO->AsString;

EADRES_MED->Text = Table1ADRES_MED->AsString;

EADRES_REGIS->Text = Table1ADRES_REGIS->AsString;

EINVALIDNOST->Text = Table1INVALIDNOST->AsString;

EPOL->Text = Table1POL->AsString;

EPROFESSIYA->Text = Table1PROFESSIYA->AsString;

CDNAIM -> ItemIndex =CDNAIM->Items->IndexOf (Table1NAIM->AsString);

EFAM1->Text = Table1FAM->AsString;

EIMYA1->Text = Table1IMYA->AsString;

EOTCHESTVO1->Text = Table1OTCHESTVO->AsString;

EPROFESSIYA1->Text = Table1PROFESSIYA->AsString;

ENOM_TEL1->Text = Table1NOM_TEL->AsString;

}

//—————————————————————————————————————;

void __fastcall TForm1: Table1AfterScroll (TDataSet *DataSet)

{

ENOM_K->Text = Table1NOM_K->AsString;

ENOM_STRAH->Text = Table1NOM_STRAH->AsString;

EKOD_L->Text = Table1KOD_L->AsString;

EFAM->Text = Table1FAM->AsString;

EIMYA->Text = Table1IMYA->AsString;

EOTCHESTVO->Text = Table1OTCHESTVO->AsString;

EADRES_MED->Text = Table1ADRES_MED->AsString;

EADRES_REGIS->Text = Table1ADRES_REGIS->AsString;

EINVALIDNOST->Text = Table1INVALIDNOST->AsString;

EPOL->Text = Table1POL->AsString;

EPROFESSIYA->Text = Table1PROFESSIYA->AsString;

CDNAIM->ItemIndex =CDNAIM->Items->IndexOf (Table1NAIM->AsString);

EFAM1->Text = Table2FAM->AsString;

EIMYA1->Text = Table2IMYA->AsString;

EOTCHESTVO1->Text = Table2OTCHESTVO->AsString;

EPROFESSIYA1->Text = Table2PROFESSIYA->AsString;

ENOM_TEL1->Text = Table2NOM_TEL->AsString;

}

//—————————————————————————————————————;

void __fastcall TForm1: Button1Click (TObject *Sender)

{

AnsiString s;

const AnsiString s1=", «;

s="" ;

if (Table1NOM_K->AsString ≠ ENOM_K->Text)

s= «НОМЕР КАРТОЧКИ» ;

if (Table1NOM_STRAH->AsString ≠ENOM_STRAH->Text)

{

if (s ≠"") s+=s1;

s= «НОМЕР СТРАХ. ПОЛИСА» ;

}

if (Table1KOD_L->AsString ≠EKOD_L->Text)

{

if (s ≠"") s+=s1;

s= «КОД ЛЬГОТЫ» ;

}

if (Table1FAM->AsString ≠EFAM->Text)

{

if (s ≠"") s+=s1;

s= «ФАМИЛИЯ» ;

}

if (Table1IMYA->AsString ≠EIMYA->Text)

{

if (s ≠"") s+=s1;

s= «ИМЯ» ;

}

if (Table1OTCHESTVO->AsString ≠EOTCHESTVO->Text)

{

if (s ≠"") s+=s1;

s= «ОТЧЕСТВО» ;

}

if (Table1ADRES_MED->AsString ≠EADRES_MED->Text)

{

if (s ≠"") s+=s1;

s= «АДРЕС МЕД. УЧРЕЖДЕНИЯ» ;

}

if (Table1ADRES_REGIS->AsString ≠EADRES_REGIS->Text)

{

if (s ≠"") s+=s1;

s= «АДРЕС РЕГИСТРАЦИИ» ;

}

if (Table1INVALIDNOST->AsString ≠EINVALIDNOST->Text)

{

if (s ≠"") s+=s1;

s= «ИНВАЛИДНОСТЬ» ;

}

if (Table1POL->AsString ≠EPOL->Text)

{

if (s ≠"") s+=s1;

s= «ПОЛ» ;

}

if (Table1PROFESSIYA->AsString ≠EPROFESSIYA->Text)

{

if (s ≠"") s+=s1;

s= «ПРОФЕССИЯ» ;

}

if (Table1NAIM->AsString ≠CDNAIM->Text)

{

if (s ≠"") s+=s1;

s= «НАИМЕНОВАНИЕ ЗАБОЛЕВАНИЯ» ;

}

if (s ≠"")

{

if (Application->MessageBox (

(«Действительно хотите изменить запись?» +s+" ?").c_str (),

" Подтвердите изменение" ,

MB_YESNO+MB_ICONQUESTION)==IDYES)

{

Table1->Edit ();

Table1NOM_K->Text = Table1NOM_K->AsString;

Table1NOM_STRAH->Text = Table1NOM_STRAH->AsString;

Table1KOD_L->Text = Table1KOD_L->AsString;

Table1FAM->Text = Table1FAM->AsString;

Table1IMYA->Text = Table1IMYA->AsString;

Table1OTCHESTVO->Text = Table1OTCHESTVO->AsString;

Table1ADRES_MED->Text = Table1ADRES_MED->AsString;

Table1ADRES_REGIS->Text = Table1ADRES_REGIS->AsString;

Table1INVALIDNOST->Text = Table1INVALIDNOST->AsString;

Table1POL->Text = Table1POL->AsString;

Table1PROFESSIYA->Text = Table1PROFESSIYA->AsString;

Table1NAIM->AsString = CDNAIM->Text;

}

} }

//—————————————————————————————————————;

void __fastcall TForm1: Button2Click (TObject *Sender)

{

Table1->Insert ();

}

//—————————————————————————————————————;

void __fastcall TForm1: Button3Click (TObject *Sender)

{

if (Application->MessageBox (

" Действительно хотите удалить запись?" ,

" Подтвердите решение" ,

MB_YESNO+MB_ICONEXCLAMATION)==IDYES)

Table1->Delete ();

}

//—————————————————————————————————————;

void __fastcall TForm1: RGFClick (TObject *Sender)

{ if (RGF->ItemIndex==0)

Table2->Filtered = false;

else

{

if (RGF->ItemIndex==1)

Table2->Filter="NOM_STRAH='" +CBNOM_STRAH->Text+" '" ;

else

Table2->Filter="(KOD_L<="+

IntToStr (SEmax->Value)+") and (KOD_L>="+

IntToStr (SEmin->Value)+")" ;

Table2->Filtered = true;

} }

//—————————————————————————————————————;

void __fastcall TForm1: ENOM_K1Change (TObject *Sender)

{

RGF->ItemIndex=0;

Table2->FindNearest (&TVarRec (ENOM_K1->Text), 0);

}

//—————————————————————————————————————;

void __fastcall TForm1: Button4Click (TObject *Sender)

{

Form2->QuickRep1->Print ();

}

//—————————————————————————————————————;

void __fastcall TForm1: Button5Click (TObject *Sender)

{

Form2->QuickRep1->Preview ();

}

//—————————————————————————————————————;