Разработка приложения в среде Delphi, взаимодействующего с базами данных в Access

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

. НАЗНАЧЕНИЕ РАЗРАБОТАННЫХ ПРОГРАМНЫХ СРЕДСТВ

. ВСТРОЕННЫЕ ТИПЫ ДАННЫХ ACCESS

.1 Типы данных Access

.2 Свойства полей Access

. СРЕДСТВА РАЗРАБОТКИ

.1 Компоненты наборов данных ADOTable, ADOQuery, ADOStoredProc, ADODataSet

.2 Понятие базы данных

.3 Структура базы данных для клиники, используемая в приложении

. ВЗАИМОДЕЙСТВИЕ ПОЛЬЗОВАТЕЛЯ С ПРИЛОЖЕНИЕМ

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

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

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

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

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

В ходе выполнения курсовой работы были решены следующие задачи:

-       разработана база данных для клиники;

-       проработана структура базы данных;

-       разработано многооконное приложение;

-       разработаны экранные формы для отображения справочников;

-       разработан алгоритм построения запросов, облегчающих фильтрацию данных пользователю;

-       была налажена работа между приложением и СУБД Access.

1. НАЗНАЧЕНИЕ РАЗРАБОТАННЫХ ПРОГРАМНЫХ СРЕДСТВ

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

-       врачи;

-       диагноз;

-       должности;

-       лекарства;

-       пациенты;

-       процедуры;

-       назначение лекарств;

-       назначение процедур;

-       отделение;

-       палата.

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

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

Рисунок 1.1 - Взаимодействие пользователя с БД

2. ВСТРОЕННЫЕ ТИПЫ ДАННЫХ ACCESS

визуализация поле база экранный

2.1 Типы данных Access

В таблице перечисляются типы данных Access и их описание.

Таблица 1 - Типы данных Access

2.2 Свойства полей Access

В приведенной ниже таблице перечисляются возможные свойства полей Access и их описание.

Таблица 2 - Свойства полей Access

3. Средства разработки

3.1 Компоненты наборов данных ADOTable, ADOQuery, ADOStoredProc, ADODataSet

Рассмотрим сначала особенности компонентов наборов данных ADO на примере ADOTable. Этот компонент может использоваться в приложениях вместо компонента Table, выполняющего аналогичные функции. Он вступает в контакт с указанной таблицей базы данных. База данных задается свойствами ConnectionString или Connection. Для управления таблицей в приложение вводится, помимо компонента ADOTable, обычный компонент источника данных DataSource, в свойстве DataSet которого задается имя компонента ADOTable. Далее к этому источнику данных DataSource подключаются любые компоненты отображения данных.

Имя таблицы, как и в компоненте Table, задается свойством TableName. Однако не все провайдеры поддерживают непосредственный доступ к таблице по ее имени. Они могут требовать доступ с помощью оператора SQL SELECT. Какой именно вариант доступа: прямой или посредством оператора SELECT будет использоваться, определяется свойством TableDirect. По умолчанию TablcDirect = Создание приложений для работы с базами данных в сети false, что означает автоматическое создание компонентом ADOTable соответствующего оператора SELECT. Соединение с базой данных осуществляется так же, как и в компонентах BDE, методом Open или установкой в true свойства Active. Но при этом, если связь с базой данных осуществляется через компонент ADOConnection, взаимосвязь свойства Active компонента ADOTable и свойства Connected компонента ADOConnection. В компоненте ADOTable имеется два свойства, характеризующие курсор, используемый при навигации по таблице. Одно из них - Cursor Location. Другое - CursorType описывает иные характеристики курсора. Это свойство может иметь значения:

-       ctUnspecified;

-       ctOpenForwardOnly;

-       ctKeyset;

-       ctDynamic;

-       ctStatic.

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

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

Свойство Marshal Options определяет, какие именно записи возвращаются на сервер, если при работе используется клиентский курсор. При значении MarshalOptions = moMarshalAll (значение по умолчанию) на сервер возвращаются все записи, считанные в локальный набор записей клиента. При значении MarshalOptions = mo Marshal Modi fiedOnly на сервер возвращаются только измененные записи.

Свойство CachcSize указывает, сколько записей заносится в локальный буфер оперативной памяти. По умолчанию CacheSize = 1. Если задать, например, CacheSize = 10, то при открытии базы данных в буфер загрузятся первые 10 записей. Пока будет идти работа с этими записями, все операции будут проводится в оперативной памяти без обращения к базе данных. Если указатель таблицы вышел за пределы 10, то в память загрузятся следующие 10 записей и т.д. Естественно, что буферизация записей повышает эффективность работы.

Основные способы работы с ADOTable не отличаются от способов, для Table. Точно так же двойной щелчок на компоненте вызывает Редактор Полей, в котором можно задать свойства отдельных полей, ничем не отличающиеся от полей компонентов BDE. Впрочем, одно печальное отличие есть: в компонентах ADO невозможно работать со словарями. Так что в каждом компоненте свойства полей приходится задавать вручную. Кроме того, надо иметь в виду, что не все драйверы ADO могут работать с любыми типами полей. Например, драйвер Paradox ADO не работает с полями изображений. Так что в таблице Pers базы данных dbP, используемой в данной книге, не будет доступно поле Photo - фотографии сотрудников. Для драйвера InterBase (в наших примерах для базы данных ib) такого ограничения нет.

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

Программный доступ к полям осуществляется так нее, как в компоненте Table: по индексу через свойство Fields[i:integer], по имени поля с помощью метода FieldByName('<HMfl>'), по имени объекта поля.

Ограничения на вводимые значения в компоненте ADOTable можно обеспечивать только на уровне полей. Свойства, аналогичного Constraints в компоненте Table, в ADOTable нет.

Связь друг с другом компонентов ADOTable, работающих с разными таблицами, одна из которых главная, а другая - вспомогательная, осуществляется так же, как в компонентах Table, с помощью свойств MasterSource и Master Fields.

Упорядочивание отображаемых записей производится установкой свойства IndexFieldNames. В этом свойстве можно задавать любое сочетание имен полей, по которым вы хотите упорядочить отображение, разделяя их точками с запятой. Например, строка 'Dep' упорядочит записи в таблице Pers по значению поля Dep -отдел. А строка 'Dep;Fam;Nam;Par' упорядочит записи по значению поля Dep -отдел, а внутри каждого отдела упорядочит по фамилии, имени и отчеству сотрудников. В отличие от свойства IndexFieldNames компонентов BDE, в компонентах ADO можно задавать любые сочетания полей, независимо от того, была ли индексирована таблица при ее создании по этим полям. В этом проявляется дополнительная гибкость компонентов ADO. Но зато в этих компонентах не работает свойство Index Name (хотя оно присутствует в Инспекторе Объектов), позволяющее использовать индексы, сформированные при создании таблицы.

Свойство только для чтения IndexFieldCount позволяет определить число полей, использованных при индексации.

Фильтрация отображаемых данных может осуществляться так же, как в компонентах BDE, с помощью свойства Filter, в котором записываются условия отбора (см. разд. 9.5.6). Отличие от компонентов BDE заключается в том, что в компонентах ADO в строке Filter имена полей обязательно должны отделяться пробелами от операций отношения. Также пробелами должны окружаться логические операции and и or. Например, если в компонентах BDE фильтр может быть записан в виде:

(Year_b<=1960)and (Year_b>=1940)

то в компонентах ADO эта строка должна иметь вид:

[Year_b <= 1960) and <Year_b >= 1940)

Свойство Filter работает, если свойство Filtered = true.

Можно также использовать для фильтрации обработчик событий OnFilterRecord. Эти события наступают каждый раз при смене активной записи, если свойство Filtered = true. В обработчике этих событий вы можете анализировать любые поля записи И возвращать значение параметра Accept = true, если поля записи удовлетворяют сформулированным вами условиям, и Accept = false в противном случае. При использовании обработчика событий OnFilterRecord надо следить за тем, чтобы строка свойства Filter не противоречила условиям, сформулированным в обработчике OnFilterRecord. Нельзя также изменять индексацию (свойство IndexFieldNames). пока Filtered = true, так как это может привести к зацикливанию программы. Перед сменой индексации надо установитьв false, затем изменить IndexFieldNames, а затем установить Filtered в true.

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

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

-       fgUnassigncd;

-       fgNone;

-       fgPendingRecoгds;

-       fgAffесtedReсогds;

-       fgFetchedRecords;

-       fgPredicate;

-       fgConflictingRecords.оказывает влияния на фильтрацию. Значение по умолчанию J Отменяет текущую фильтрацию и делает видимыми все записи.

Отфильтровываются записи, которые были изменены, но еще не занесены в таблицу методом UpdateBatch или прерваны методом CancclBatch.

Отфильтровываются последние измененные записи. Отфильтровываются записи, которые были изменены при последней очистке кэша.

Отфильтровываются только что удаленные записи. Отфильтровываются записи, которые должны были быть изменены, но это не получилось из-за ошибок. Методы, используемые при программировании работы с базой данных, в ADOТаЫе в основном те же, что в Table. Навигация по таблице осуществляется методами First, Next, Last и Prior. При редактировании данных используются также методы, рассмотренные ранее для Table: Insert, Edit, Post и другие. Из методов поиска В ADO реализованы только методы Locate и Lookup. Из методов, отсутствующих в компонентах BDE, интересными представляются методы сохранения набора данных в файле и чтения его из файла. Сохранение в файле осуществляется методом SaveToFUe;SaveToFile (const Filename: String = ' ' ,-

Format: TPersistForraat = pfADTG);

Параметр FileName указывает имя файла, в котором сохраняется набор данных. Необязательный параметр Format определяет формат файла. Этот параметр может принимать одно из двух значений: pfADTG - формат ADTG (AdvancedData Tablegram), или pfXML - формат XML (для версий ADO 2.1 и выше). По умолчанию принято значение pfADTG. Так что если оно устраивает, то сохранение набора данных в файле может осуществляться, например, таким оператором:.SaveToFile('Test.adt');

Чтение данных из файла осуществляется процедурой LoadFromFile:

procedure LoadFromFile(const FileName: WideString) .-где FileName - имя файла. Загружать файл в набор данных можно даже при закрытом соединении с базой данных. В момент загрузки соединение автоматически откроется.

Методы SaveToFile и LoadFromFile удобно использовать для получения как бы мгновенного портрета данных на какой-то момент времени. Это может требоваться, например, для того, чтобы можно было восстановить запомненное, а затем из-за каких-то ошибок испорченное состояние базы данных.

Теперь коротко рассмотрим компонент ADOQuery, который является аналогом компонента Query, используемого при работе с BDE. Этот компонент используется для выполнения произвольных запросов SQL. Его основное свойство SQL, содержащее запрос и методы выполнения этого запроса, ничем не отличаются от компонента Query.

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

Это массив параметров, причем доступ к значениям отдельных параметров во время выполнения может осуществляться или по индексу, или по имени с помощью метода ParamByName. Например, возможны следующие операторы:

// значение параметра типа string

Queryl.Params[0]-Value :=Editl.Text;.Params[0].AsString := Editl.Text;. ParamByNameC EDep'1-Value := Editl.Text;

// значение параметра типа integr.Params[1].Value := Edit2.Test;.Params[1].Aslnteger := StrTOInt(Edit2.Text];.ParamByName [ 'year' 1 .Value := Edit2.Text,-.Pararns.FindParamf'year'i .Value := Edit2.Text;

В компоненте ADOQuery объекты, соответствующие параметрам, указанным в свойстве SQL, расположены в свойстве Parameters типа TParameters. Это тоже массив параметров, но его свойства и методы отличаются от свойств и методов TParams. Доступ к отдельным параметрам во время выполнения может осуществляться по индексу, но при этом значение определяется только функцией Value, а методы AsString, Aslnteger и т.п. отсутствуют. Доступ к отдельным параметрам может осуществляться по имени с помощью метода ParamByName, который является методом не самого компонента ADOQuery (как В Query), а его свойства Parameters. При этом значение параметра определяется методом Value. Наконец, доступ к параметрам может осуществляться методами FindPsram, GetParamList, ParamValues свойства Parameters, которые не отличаются от аналогичных методов свойства Params в Query. Например, возможны следующие операторы:

ADOQueryl.Parameters[0].Value := Editl.Text;

ADOQueryl.Parameters.ParamByNsrae('EDep').Value := Editl.Text;.Parameters.ParamValuest 'EDep'] := EditI.Text,-

// значение параметра типа integr.Paranieters[l].Value := Edit2.Text;.Parameters.ParamByNarae('year1).Value := Edit2.Text;.Parameters.ParamValues['year1 ] := Edit2.Text;

Еще одно отличие параметров в компонентах ADOQuery и Query заключается в том, что во время проектирования компонент Query содержит только те параметры, которые указаны в запросе SQL. А в ADOQuery предусмотрена возможность вводить параметры во время проектирования. Для этого надо нажать кнопку с многоточием около свойства Parameters в окне Инспектора Объектов, затем в появившемся окне редактора параметров щелкнуть правой кнопкой мыши и выбрать в контекстном меню раздел Add (вместо этого можно нажать соответствующую быструю кнопку).

Компонент ADOStoredProc является аналогом компонента StoredProc, используемого при работе с BDE. Этот компонент используется для выполнения хранимых на сервере процедур. В целом он работает так же, как его аналог StoredProc.

Свойство, в котором задается имя выполняемой процедуры, называется РгосеdureName, а не StoredProcName, как в StoredProc. После того как вы зададите имя процедуры, в свойстве Parameters, аналогичном рассмотренному выше для Создание приложений для работы с базами данных в сети компонента ADOQuery, появятся входные параметры процедуры. Выходные параметры представляются объектами полей компонента ADOStoredProc. Вы можете увидеть их и изменить их свойства, если сделаете двойной щелчок на компоненте ADOStoredProc, в появившемся окне Редактора Полей сделаете щелчок правой кнопкой мыши и выберете раздел Add all fields. В окне появятся поля, соответствующие всем выходным параметрам процедуры.

Таким образом, при работе с хранимыми процедурами вы сначала должны задать значения входных параметров, затем выполнить вызов процедуры оператором вида:.ExecProc;

а к возвращенным параметрам обращаться как к объектам полей компонента ADOStoredProc.

Универсальный компонент ADODataSet может выполнять функции компонентов ADOTable, ADOQuery, ADOStoredProc. Режим работы ADODataSet задается двумя взаимосвязанными параметрами: CommandType и CommandText.

Параметр CommandType может принимать значения:

-       cmdUnknown;

-       cmdText;

-       cmdTable;

-       cmdStoredProc;

-       cmdFile;

-       cmdTableDirect.

Таким образом, при значениях cmdTable или cmdTableDirect компонент работает как ADOTable, при значении cmdText - как ADOQuery (только при запросе SELECT), при значении cmdStoredProc - как ADOStoredProc. При значении cmdFile компонент работает как ADOTable, беря значения данных из файла, в котором они были ранее сохранены методом SaveToFile. Значение cmdUnknown может использоваться только как временное. Перед соединением с базой данных это значение должно быть изменено. После установки значения свойства CommandType в свойстве CommandText автоматически устанавливается выпадающий список, соответствующий значению CommandType. Например, при значениях cmdTable и cmdTableDirect в свойстве CommandText появляется список таблиц. При значении cmdStoredProc в свойстве CommandText появляется список хранимых процедур. При значении cmdText в свойстве CommandText появляется кнопка с многоточием. Ее нажатие вызывает редактор запроса SQL. При значении cmdFile в свойстве CommandText также появляется кнопка с многоточием. Ее нажатие вызывает обычный диалог открытия файла.

Следует подчеркнуть, что в режиме cmdText компонент может выполнять только оператор SELECT. Для выполнения операторов языка манипулирования данными, таких, как DELETE, INSERT или UPDATE, надо использовать компонент ADOQuery или описанный далее компонент ADOCommand.

3.2 Понятие базы данных

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

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

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

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

Рисунок 3.2.1 - Приложение для начисления зарплаты, использующее систему управления файлами

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

Проблемы сопровождения больших систем, основанных на файлах, привели в конце 60-х годов к появлению СУБД. В основе СУБД лежала простая идея: изъять из программ определение структуры содержимого файла и хранить её вместе с данными в базе данных.

3.3 Структура базы данных для клиники, используемая в приложении

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

В данных таблицах перечислены все таблицы базы данных:

Таблица 3 - Перечень таблиц базы данных

Таблица 4 - Врачи

Таблица 5 - Диагноз

Таблица 6 - Должности

Таблица 7 - Лекарства

Таблица 8 - Назначения лекарств

Таблица 9 - Назначения процедур

Таблица 10 - Отделение

Таблица 11 - Палата

Таблица 12 - Пациенты

Таблица 13 - Процедуры

На рисунке 3.3.1 приведены связи между таблицами.

Рисунок 3.3.1 - Схема базы данных приложения

4. ВЗАИМОДЕЙСТВИЕ ПОЛЬЗОВАТЕЛЯ С ПРИЛОЖЕНИЕМ

Пока грузится приложение, пользователь может увидеть заставку приложения, которое будет отображаться либо в течение пяти секунд, либо пока пользователь не нажмет любую клавишу.

После этого пользователю предлагается войти в систему в качестве пользователя, либо с правами администратора (см. Рисунок 4.1).

Рисунок 4.1 - Вход в систему

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

После нажатия кнопки «Пользователь» открывается главная экранная форма, имеющая вид многооконного приложения. А при нажатии кнопки «Администратор» для того чтобы открыть главную экранную форму, необходимо ввести пароль ( см. Рисунок 4.2).

Рисунок 4.2 - Ввод пароля

Главная экранная форма (см. Рисунок 4.3) содержит такие пункты меню как: «Справочники» (с подпунктами меню содержащими названия всех справочников), «Окно» (подпункты определяют расположение дочерних форм приложения).

Рисунок 4.3 - Родительская форма приложения

При выборе любого подпункта меню пункта меню «Справочники» открывается экранная форма, содержащая выбранный пользователем справочник (как показано на рисунке 4.4). Экранная форма имеет пункты меню «Фильтр» и «Отмена фильтра», которые позволяют произвести фильтрацию информации или отмена фильтрации. Пользователь заполняет необходимые поля, что позволяет ускорить поиск необходимой для него информации(см. Рисунок 4.5). После чего на экранной форме со справочником содержится информация, удовлетворяющая введенным параметрам пользователя (отображено на рисунке 4.6)

Рисунок 4.4 - Справочник «Должности»

Рисунок 4.5 - Окно параметров фильтрации

Рисунок 4.6 - Результат фильтрации

Так же при нажатии на пункт меню «Окно» можно выбрать режим расположения дочерних форм (как показано на рисунках 4.7, 4.8, 4.9 ):

-       каскад;

-       по горизонтали;

-       по вертикали.

Рисунок 4.7 - Каскадное расположение форм

Рисунок 4.8 - Расположение форм по горизонтали

Рисунок 4.9 Расположение форм по вертикали

ЗАКЛЮЧЕНИЕ

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

Внедрение данного ПС экономически обосновано.

Все задачи, поставленные на курсовое проектирование, выполнены полностью.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1 Архангельский, А.Я. Программирование в Delphi / А.Я. Архангельский М.: ООО «Бином-Пресс», 2003. - 1152 с.

Сухарев, М.В. Основы Delphi. Профессиональный подход/ М.В. Сухарев СПб.: Наука и Техника, 2004. - 600 с.

Кенту, М. Delphi 7. Для профессионалов/ М. Кенту СПб.: Питер, 2004. - 1101 с.

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

Понамарев, В. Базы данных в Delphi 7. Самоучитель/ В. Понамарев СПб.: Питер, 2003. - 224 с.

Луни, К., Брила, Б. 101: Oracle Database 10g Настольная книга администратора / К. Луни, Б. Брила М.: Издательство «Лори», 2008. - 729 с.

Конноли, Томас, Бегг, Каролин Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. - М.: Издательский дом “Вильяме”, 2003. - 1440 с.

ПРИЛОЖЕНИЕ

unit UDolj;

interface, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, Grids, DBGrids, DB, ADODB, Menus, ExtCtrls, DBCtrls;= class(TForm): TDBGrid;: TMainMenu;: TMenuItem;: TMenuItem;: TDBNavigator;N2Click(Sender: TObject);FormClose(Sender: TObject; var Action: TCloseAction);N1Click(Sender: TObject);

{ Private declarations }VisibleEdit(bRight : Boolean);

{ Public declarations };: TFormDolj;, UFilterDolj;

{$R *.dfm}TFormDolj.VisibleEdit(bRight : Boolean);.Visible:=bRight;.ReadOnly:=bRight;;TFormDolj.N2Click(Sender: TObject);.ADOQueryDolj.Active:=False;.ADOQueryDolj.SQL.Text:='Select * from Должности';.ADOQueryDolj.ExecSQL;.ADOQueryDolj.Active:=True;;TFormDolj.FormClose(Sender: TObject; var Action: TCloseAction);:=caFree;;TFormDolj.N1Click(Sender: TObject);.ShowModal;;.UFilterDolj;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, ExtCtrls, jpeg;= class(TForm): TButton;: TButton;: TImage;: TLabeledEdit;: TLabeledEdit;: TLabeledEdit;Button2Click(Sender: TObject);Button1Click(Sender: TObject);

{ Private declarations }

{ Public declarations };

Фильтр должности

var: TFormFilterDolj;;

{$R *.dfm}TFormFilterDolj.Button2Click(Sender: TObject);;;TFormFilterDolj.Button1Click(Sender: TObject);: Boolean;:=False;.ADOQueryDolj.Active:=False;.ADOQueryDolj.SQL.Text:='SELECT * FROM Должности';LEName.Text<>'' thenb=False then:=True;.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+' where';.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+' and';.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+

' Наименование='''+LEName.Text+'''';

end;LEOklad.Text<>'' thenb=False then:=True;.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+' where';.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+' and';.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+

' Оклад>='+LEOklad.Text;;LEOtpusk.Text<>'' thenb=False then:=True;.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+' where';.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+' and';.ADOQueryDolj.SQL.Text:=DM.ADOQueryDolj.SQL.Text+

' Отпуск='+LEOtpusk.Text;;.ADOQueryDolj.Active:=True;;;.UMain;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, Menus, DB, DBTables, ADODB, jpeg, ExtCtrls;= class(TForm): TMainMenu;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TImage;FormShow(Sender: TObject);MKaskadClick(Sender: TObject);MVertClick(Sender: TObject);MHorizClick(Sender: TObject);MDoctorClick(Sender: TObject);MPacientClick(Sender: TObject);MDoljnClick(Sender: TObject);N1Click(Sender: TObject);N2Click(Sender: TObject);N3Click(Sender: TObject);

{ Private declarations }: Boolean;

{ Public declarations };

Главная форма

: TFMain;, UString, UDoctors, UDolj, UOtdel, UPalata, UPacient, UDoljn,, UEnter;

{$R *.dfm}TFMain.FormShow(Sender: TObject);.ShowModal;.ShowModal;;TFMain.MKaskadClick(Sender: TObject);;;TFMain.MVertClick(Sender: TObject);:=tbVertical;;;TFMain.MHorizClick(Sender: TObject);:=tbHorizontal;;;TFMain.MDoctorClick(Sender: TObject);:=TFDoctors.Create(Self);.VisibleEdit(bRight);.Show;;TFMain.MPacientClick(Sender: TObject);:=TFTablePacients.Create(Self);.VisibleEdit(bRight);.Show;;TFMain.MDoljnClick(Sender: TObject);:=TFormDolj.Create(Self);.VisibleEdit(bRight);.Show;;TFMain.N1Click(Sender: TObject);:=TFOtdel.Create(Self);.VisibleEdit(bRight);.Show;;TFMain.N2Click(Sender: TObject);:=TFPalata.Create(Self);.VisibleEdit(bRight);.Show;;TFMain.N3Click(Sender: TObject);:=TFDiagnoz.Create(Self);.VisibleEdit(bRight);.Show;;.

Пароль

UPassword;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, jpeg, ExtCtrls;= class(TForm): TEdit;: TButton;: TButton;: TImage;BOkClick(Sender: TObject);BCancelClick(Sender: TObject);

{ Private declarations }

{$R *.dfm}TFPassword.BOkClick(Sender: TObject);EPassword.Text='admin' then.Show;;.Close;(Self.Handle,'Неправильный пароль','Ошибка',MB_OK);;TFPassword.BCancelClick(Sender: TObject);.Show;;;