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

Методы 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 - Процедуры