Иптышев А.А., Морозов Д.И., Городилов А.А., Иптышев М.А. Базы данных

Подождите немного. Документ загружается.

13.5. КОМПОНЕНТ TQRSYSDATA

Компонент TQRSysData используется для показа вспомогательной и

системной информации. Вид показываемой информации определяется свойством

property Data: TQRSysDataType;

Ниже указаны основные значения этого свойства:

qrsDate – текущая дата;

qrsDateTime – текущие дата и время;

qrsDetailNo – номер текущей записи в наборе данных;

qrsPageNumber – номер текущей страницы отчета;

qrsPageCount – общее количество страниц отчета;

qrsTime – текущее время

Свойство property Text: TCaption – определяет текст, помещаемый перед

отображаемой величиной.

13.6. ПРИМЕР СОЗДАНИЯ ОТЧЕТА С ПОМОЩЬЮ QREPORT

Давайте в качестве примера использования всех этих компонентов рассмотрим

создание простого отчета. Он содержит некоторый текст и рисунки, имеет нижние

колонтитулы, в которых печатается название отчета и номер страницы. Кроме того,

мы хотим, чтобы на первой странице над нижним колонтитулом было написано

«Красноярск» и дата создания отчёта.

1.Начните новый проект.

2.Перенесите на форму компонент QuickRep и в его свойстве Bands

установите True подсвойство HasDetail - основная полоса, в которой вы будите

писать текст, и подсвойство HasPageFooter - полоса нижних колонтитулов.

Свойство HasTitle можно установить в True, а можно не устанавливать,

поскольку различие между заголовком отчета и его полосой детализации

проявляться в нашем случае не будет. Дело в том, что при работе с базами данных

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

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

полоса детализации будет печататься один раз, так что она не отличается от

заголовка.

Если вы установили в true свойства HasDetail и HasPageFooter, то на поле

компонента QuickRep появятся слабо видимые полосы с надписями "Detail " и

"Page Footer ".

1. Перенесите в верхнюю часть полосы детализации компонент QRImage.

Щелкните на кнопке, с многоточием около его свойства Picture и загрузите в него

какую - нибудь картинку.

2. Перенесите в полосу детализации компонент QRLabel, расположите его

под рисунком и задайте заголовок отчета в свойстве Caption. Установите свойство

Alignment в taCenter и AlignToBand в true. Это обеспечит размещение заголовка в

центре страницы по горизонтали. Назовите эту метку QRLTitle. В дальнейшем нам

надо будет на нее ссылаться.

3. Разместите примерно в центре страницы компонент QRRichText, в котором

будет писаться основной текст. Напишите какой - нибудь текст в свойстве Lines.

Теперь на страницу надо добавить строку с текстом " Москва " и датой

создания отчета. Но если мы разместим ее под компонентом QRRichText, то в

отчете она окажется непосредственно под текстом. А мы хотим разместить ее внизу

страницы. Поэтому нам надо ввести в отчет еще одну полосу.

4. Перенесите на форму компонент QRSubDetail. Установите его свойство

AligneToBottom в true. Это обеспечит размещение полосы внизу страницы.

5. Разместите на полосе Sub Detail компонент QRLabel, написав в его

свойстве Caption текст “Красноярск”.

6. Разместите правее метки компонент QRSysData. В его свойстве Data

установите значения qrsData. Этот компонент будет отображать дату создания

отчета.

Это не лучший вариант, так как при этом будет отображаться день, месяц и

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

вместо QRSysData компонент QRExpr . Подумайте, как это можно сделать. В

качестве подсказки могу сказать, что можно для решения этой задачи

воспользоваться функцией Copy.

Осталось внести информацию в нижний колонтитул страницы.

7. Перенесите на полосу “Page Footer” компонент QRLabel, задайте в его

свойстве Caption текст (например, “Отчет по изучению Delphi”). Установите

свойство Alignment в taLeftJustify и AlignToBand в true. Это обеспечит

выравнивание метки по левому краю страницы. Установите в свойстве Frame

подсвойство DrawTop в true. Это обеспечит появление линии, отделяющей

колонтитул от текста.

8. Перенесите на полосу “Page Footer” компонент QRSysData. В его свойстве

Data установите значение qrsPageNumber. Этот компонент будет отображать

номер страницы. Установите свойство Alignment в taRightJustify и AlignToBand в

true. Это обеспечит выравнивание номера по правому краю страницы.

Проектирование отчета завершено. Щелкните правой кнопкой мыши на

компоненте QuickRep и из всплывшего меню выберите команду Preview. Перед

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

Подберите размещение компонентов и размеры шрифтов в них так, чтобы все

выглядело прилично.

Конечно, подобный отчет совсем не интересен, так как он весь создан в

процессе проектирования. К тому же вы никак не использовали возможностей

форматирования текста в компоненте QRRichText. Поэтому текст выглядит

некрасиво. Давайте теперь создадим форму, которая управляла бы построением,

просмотром и печатью этого отчета.

1. Дайте имя FRep вашей форме (свойство Name). По этому имени вы потом

сможете ссылаться на ее компоненты.

2. Проверьте, что свойство Visible этой формы установлено в false. Это

необходимо сделать, так как форма в дальнейшем должна быть невидимой.

3. Сохраните проект, дав файлу формы имя URep. Это имя автоматически

присвоится модулю текста формы и по нему вы сможете впоследствии сослаться на

этот модуль.

4. Откройте командой File/New новую форму.

5. Выполните команду Project/Options, в открывшемся окне Опций проекта

перейдите на страницу Forms и в списке Main Form выберите главной текущую

форму Form1. Форма FRep должна быть вспомогательной.

6. Сохраните модуль новой формы, дав его файлу имя URep1.По этому имени

вы сможете ссылаться на него из модуля URep.

7. Перенесите на новую форму компоненты главное меню MainMenu,

FontDialog, RichEdit, Edit и Button. В меню введите раздел Отчет с подразделами

Показать и Печать, и раздел Правка с подразделом Шрифт. В свойство Lines

компонента RichEdit введите некоторый начальный текст, например, тот, который

вы ранее вводили в QRRichText. В окно редактирования Edit введите текст

заголовка вашего отчета.

Теперь осталось связать друг с другом две формы и написать небольшие

команды управления.

8. Перейдите в модуль формы отчета URep и в его разделе implementation

напишите оператор

uses URep1;

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

формы.

9. Перейдите в модуль главной формы URep1 и в его разделе implementation

напишите оператор

uses URep;

10. В компоненте QRRichText формы URep раскройте выпадающий список в

свойстве ParentRichEdit. В этом списке должна появится ссылка на компонент

RichEdit формы Form1. Установите это свойство, чтобы связать окна

редактирования друг с другом.

11. В обработчик события OnClick кнопки на форме Form1 внесите оператор

FRep.QRLTitle.Caption:=Edit1.Text;

Он обеспечит пересылку в метку заголовка отчета QRLTitle текста, который

пользователь ввел в окно Edit1.

1. В обработку команды меню Шрифт вставьте операторы

if FontDialog1.Execute then

with RichEdit1.SelAttributes do begin

Color:=FontDialog1.Font.Color;

Name:=FontDialog1.Font.Name;

Size:=FontDialog1.Font.Size;

Style:=FontDialog1.Font.Style;

end;

RichEdit1.SetFocus;

2. В обработку команды меню Просмотр вставьте оператор

FRep.QuickRep1.Preview;

Приложение закончено. Запустите его на выполнение. Отформатируйте текст

в окне. Выполните команду Просмотр. Появится окно в котором вы можете

просматривать отчет, изменяя размер изображения, переходить со страницы на

страницу, (ваш отчет имеет одну страницу, так что переходы в нем невозможны),

сохранять отчет в файле, проводить установку принтера, печатать отчет, сохранять

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

файла.

14. ИНСТРУМЕНТЫ И ТЕХНОЛОГИИ СОЗДАНИЯ КЛИЕНТ-

СЕРВЕРНЫХ ПРИЛОЖЕНИЙ

Логическим развитием архитектуры информационных систем, причем

развитием на качественно новом уровне, стала архитектура “клиент-сервер”.

Архитектура “клиент-сервер” относится к описанию взаимодействия программ,

причем как находящихся на одном компьютере, так и на разных. Данная

архитектура получила широкое распространение благодаря широкому внедрению

вычислительных сетей. Рассмотрим основные идеи этой архитектуры.

Если мы вернемся к архитектуре информационных систем на основе идеи

файл-сервера, то принципиальным недостатком такой архитектуры являлось

разнесение программ, обрабатывающих данные, и самих данных. Основным

принципиальным недостатком терминальной архитектуры являлось слишком

сильное разнесение пользователя и программы обработки. Архитектура “клиент-

сервер” устраняет эти недостатки.

Архитектура “клиент-сервер” (рис.30) подразумевает наличие двух типов

программ - программы-клиента и программы-сервера. Программа-клиент является

“активной” программой, то есть в ее задачи входит генерация некоторых обращений

за услугами к программе-серверу. Программа-сервер является пассивной

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

Когда такой запрос поступает, программа-сервер отрабатывает его и, при

необходимости, возвращает программе-клиенту некоторые результаты.

Рис. 30. Многопользовательская информационная система на основе архитектуры “клиент-

сервер”.

Естественно, взаимодействие между программой-клиентом и программой-

сервером должно происходить по четко определенному интерфейсу. В противном

случае, они рискуют не понять друг друга.

14.1. РЕАЛИЗАЦИЯ АРХИТЕКТУРЫ “КЛИЕНТ-СЕРВЕР” ДЛЯ БАЗ

ДАННЫХ

Рассмотрим причины, по которым архитектура “клиент-сервер” может быть

полезна для систем доступа к данным и, в частности, для систем управления базами

данных. Для начала, предположим, что имеется некоторая простая программа,

автоматизирующая деятельность какого-то предприятия. Эта программа

запрашивает у пользователя информацию и помещает ее в файл, либо читает

некоторые данные из файла и показывает их пользователю. Когда такая программа

пишется в виде единой программы, предназначенной для использования на

персональном компьютере, на котором в каждый момент с этими данными работает

только один человек проблем почти не возникает. Но представим себе, что

компьютер поставили в сеть, и сразу несколько человек захотели поработать с этими

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

не происходит.

Но как только какой-то пользователь (или сразу несколько пользователей)

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

некоторые данные, думая что они правильные, кто-то может их поменять. В

результате то, что видит большинство пользователей оказывается не соответствует

тому, что есть на самом деле. Простой пример: на счету некой фирмы 10 миллионов

рублей. Два служащих отдела закупок видят эту цифру и решают сделать закупку.

Один подписывает контракт на 6 миллионов, другой - на 7 миллионов. Каждый

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

обнаруживается, что оба контракта вместе невозможны! Но они уже подписаны! В

них стоят штрафные санкции за срыв контракта! Кто виноват? Поэтому при

переходе к многопользовательскому доступу к данным приходится ставить

механизм блокировки, который должен запрещать менять, а иногда и показывать

значения, которые были кем-то прочитаны, но еще не обработаны.

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

Функцией такого механизма должна стать координация доступа. Кроме того, по

многим причинам имеет смысл возложить на этот механизм и, собственно, все

функции доступа к данным. Перечислим эти причины.

Первое. Программа из нашего примера с функциональной точки зрения

состоит из функций, обеспечивающих интерфейс с пользователем, и функций,

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

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

и другие функции. Но ведь функции доступа для всех пользователей одинаковы и

перенос этих функций из программы, работающей с пользователем в программу-

координатор доступа позволяет экономить ресурсы.

Второе. Разработчики должны быть уверены, что программист, вследствие

ошибки или злого умысла не обойдет наш механизм координации доступа к

данным. То есть, нужно быть уверенным, что отслеживание прав доступа,

поддержание целостности и т.д. работают всегда и работают правильно.

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

к данным. А что может быть ближе чем программа-координатор?

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

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

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

усложняет сопровождение всей системы в целом.

Таким образом, вместо одной программы, содержащей в себе и интерфейс с

пользователем, и доступ к данным, мы получили две общающиеся между собой

программы - программу, работающую с пользователем (программа-клиент) и

программу, реализующую доступ к данным (программа-сервер). То есть получили

систему, построенную по архитектуре “клиент-сервер”.

14.1.1. Обзор функций сервера базы данных

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

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

реализована в информационной системе, ложится на сервер базы данных.

Перечислим теперь основные функции, которые должна выполнять программа-

сервер базы данных:

Выполнять клиентские запросы по извлечению и модификации

данных;

Обеспечивать одновременный доступ к данным нескольких

пользователей;

Обеспечивать идентификацию пользователей и разграничение прав дост

упа

разных пользователей к разным данным;

Обеспечивать целостность и непротиворечивость данных в случае

аппаратных и программных сбоев;

Защищать данные от несанкционированного доступа;

Предоставлять дополнительные средства администрирования

информационной системы.

Рассмотрим эти требования более подробно.

Выполнять клиентские запросы по извлечению и модификации данных.

Вообще говоря, это основная функция сервера баз данных. Механизм реализации

этой функции может быть скрыт от пользователя, то есть пользователь (а, точнее,

работающая с ним программа-клиент) просто формулирует ЧТО ему нужно, а

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

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

различают различные типы СУБД. Более подробно о том, какие бывают СУБД,

будет говориться в отдельной главе.

Предоставлять механизм одновременного доступа к данным нескольких

пользователей. Как мы уже видели в рассмотренном выше примере, при

многопользовательском доступе к данным возникают дополнительные задачи,

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

данных. Блокировка означает, что часть данных в некоторые моменты времени

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

Другой аспект многопользовательского доступа - это распараллеливание

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

одновременно. Другими словами, если два пользователя почти одновременно

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

обрабатывать их строго по очереди (“вначале выполнить целиком один запрос, а

только затем другой”). В противном случае, какой-то один очень сложный запрос

может заставить ждать многих пользователей с простыми запросами. В этом аспекте

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

Обеспечивать идентификацию и разграничение прав доступа разных

пользователей к разным данным. В реальных информационных системах должно

существовать разграничение по правам доступа к данным. Какие-то пользователи

могут и читать и модифицировать данные, какие-то пользователи могут только

читать, а кто-то вообще может только вводить данные, а читать не имеет право (см.

Пример про резервирование билетов во Введении). Таким образом, сервер баз

данных должен, во-первых, уметь понимать команды, которые описывают такое

разграничение прав, а, во-вторых, в процессе обслуживания запросов пользователя

контролировать соблюдение этих разграничений.

Обеспечивать целостность и непротиворечивость данных в случае

аппаратных и программных сбоев. Несмотря на то, что за последнее время

надежность аппаратной части существенно выросла, абсолютно надежной техники

не бывает. В случае внезапного выключения и последующего включения

компьютера, на котором работает сервер базы данных, информация не должна быть

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

котором работает программа-клиент, сервер базы данных должен определить этот

факт и снять те блокировки, которые данная программа-клиент установила, откатить

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

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

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

могут привести к таким же последствиям. Например, списывание денег с

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

или к появлению расходного документа. То есть нельзя просто так списать или

начислить деньги на счет. Злоумышленник, получивший доступ к банковской

системе, не должен иметь возможность просто так увеличить сумму на своем счете.

Кроме того, при программировании банковской системы в нее может закрасться

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

данных должен уметь проверять корректность производимых манипуляций с

данными.

Естественно, некоторые действия могут выглядеть совершенно правильно, но

при этом таковыми не являться. Например, операционист может просто ошибиться с

вводом номера счета, и операция будет неправильной. Отследить такие ошибки

очень трудно. Однако если некоторые зависимости можно описать формально, то

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

Защищать данные от несанкционированного доступа. В современных

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

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

категорий пользователей, сервер базы данных должен обеспечивать защиту от

попыток получить доступ к данным тем лицам, которые не являются

пользователями информационной системы.

Предоставлять средства администрирования информационной системы.

В реальной информационной системе очень важно обеспечить технологичность, то

есть информационная система позволять добавлять или удалять пользователей,

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

восстановления системы после такого форс-мажорного события, как, например,

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

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

существовать процедура архивирования и восстановления данных. Также

существует вероятность, что в процессе проектирования системы не были

предусмотрены какие-то типы запросов, и при их реализации оказалось, что они

работают слишком медленно. Следовательно, сервер базой данных должен уметь

управлять ресурсами и производительностью.

Вся деятельность данного типа относится к администрированию сервера базы

данных. Качественный сервер базы данных должен предоставлять достаточный

набор возможностей по администрированию, а именно, возможность настройки по

производительности, средства анализа потока запросов и определения причин

недостаточной скорости работы, средства созданий резервных копий (архивов) и

восстановления с них и т.д.

14.1.2. Функции программы-клиента базы данных

Как правило, программа-клиент в системах управления базами данных

отвечает за взаимодействие с пользователем. Взаимодействие может, строится на

основе каких-либо экранных форм или диалога (как именно, в нашем рассмотрении

не важно). На основе команд, введенных пользователем, программа-клиент

формирует запрос к серверу базы данных. После того, как запрос будет отработан и

нужные данные найдены и переданы программе-клиенту, программа-клиент выдает

их на экран.

Могут существовать программы-клиенты, которые не ведут никакого диалога

с пользователем, а выполняют системные задачи. Например, принимают сообщения

по почте, извлекают из них данные и заносят в базу данных. В любом случае,

программа=клиент выполняет роль взаимодействия с внешним миром, но не

занимается вопросами внутреннего представления и хранения данных.

14.2. СОЗДАНИЕ ПОДКЛЮЧЕНИЕ К КЛИЕНТ-СЕРВЕРНОЙ БАЗЕ

ДАННЫХ

Для создания подключения необходимо воспользоваться следующими

компонентами: TIBDatabase, TIBtransaction.

14.2.1. Компонент TIBDatabase

Компонент, осуществляющий подключения к сетевой базе данных. В этом

компоненте необходимо настроить свойства представленные в таблице 12.

Таблица 12

Свойства компонента TIBDataBase

Название Тип данных Описание

DataBaseName String Полный путь к базе даны в

формате «имя сервера : полный

путь к файлу базы данных »

Params TStrings Параметры подключения базы

данных.

DefaultTransaction

TIBTransaction

Название компонента

управляющий транзакциями по

умолчанию

Connected Boolean Св-во определяющее подключен

ли компонент к базе данных или

нет

Свойство Params необходимо заполнять согласно определенному формату,

представленному в таблице 13.

Таблица 13

Формат параметров подключения к базе данных.

Название

Описание Пример использования

User

name

Имя пользователя User_name = SYSDBA

Password

Пароль Password = masterkey

lc_ctype Кодировка символов

используемых в базе

данных

lc_ctype=WIN1251

Пример использования компонента TIBDatabase для подключения к базе

данных:

procedure TForm1.DBConnect(server_name, database_name, user_name, password: string);

begin

try

IBDatabase1.DatabaseName:=server_name+':'+database_name;

//Указываем полный путь к файлу базы данных

with IBDatabase1.Params do

begin

Clear; // Очищаем список параметров подключения

Add('user_name='+user_name); // Указываем имя пользователя

Add('password='+password); // Указываем пароль

end;

IBDatabase1.Connected := true; // Устанавливаем подключение к базе данных

except