Иптышев А.А. Курс лекций по дисциплине базы данных

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

101

13.5 Компонент TQRSysData

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

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

ством

property Data: TQRSysDataType;

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

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

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

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

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

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

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

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

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

13.5Пример создания отчета с помощью QReport

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

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

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

страницы. Кроме того, мы хотим, чтобы на первой странице над нижним ко-

лонтитулом было написано «Красноярск» и дата создания отчёта.

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

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

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

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

тулов.

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

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

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

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

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

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

она не отличается от заголовка.

102

Если вы установили в 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. Это обеспе-

103

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

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

ляющей колонтитул от текста.

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

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

отображать номер страницы. Установите свойство Alignment в taRightJusti-

fy и 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 введите некоторый начальный текст,

104

например, тот, который вы ранее вводили в QRRichText. В окно редактиро-

вания Edit введите текст заголовка вашего отчета.

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

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

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

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

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;

105

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

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

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

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

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

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

можно было загрузить его опять из файла.

106

МОДУЛЬ 3. ПРОГРАММИРОВАНИЕ СУБД

АРХИТЕКТУРЫ КЛИЕНТ-СЕРВЕР

РАЗДЕЛ 1. АРХИТЕКТУРА КЛИЕНТ-СЕРВЕРНЫХ

ПРИЛОЖЕНИЙ БАЗ ДАННЫХ

Тема 14. Инструменты и технологии создания клиент-

серверных приложений

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

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

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

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

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

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

туры.

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

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

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

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

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

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

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

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

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

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

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

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

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

торые результаты.

107

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

ент-сервер”.

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

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

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

14.1 Реализация архитектуры “клиент-сервер” для баз данных

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

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

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

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

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

либо читает некоторые данные из файла и показывает их пользователю. Ко-

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

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

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

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

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

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

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

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

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

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

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

фирмы 10 миллионов рублей. Два служащих отдела закупок видят эту цифру

и решают сделать закупку. Один подписывает контракт на 6 миллионов, дру-

гой - на 7 миллионов. Каждый думает, что он прав. Но как только в данные

вносятся изменения тут же обнаруживается, что оба контракта вместе невоз-

можны! Но они уже подписаны! В них стоят штрафные санкции за срыв кон-

108

тракта! Кто виноват? Поэтому при переходе к многопользовательскому дос-

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

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

прочитаны, но еще не обработаны.

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

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

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

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

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

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

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

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

гружаются и те, и другие функции. Но ведь функции доступа для всех поль-

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

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

сурсы.

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

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

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

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

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

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

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

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

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

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

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

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

между собой программы - программу, работающую с пользователем (про-

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

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

сервер”.

109

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

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

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

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

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

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

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

ных;

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

а-

телей;

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

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

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

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

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

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

р-

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

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

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

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

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

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

мулирует ЧТО ему нужно, а сервер базы данных исполняет этот запрос. В за-

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

модели данных можно иметь на сервере, различают различные типы СУБД.

Более подробно о том, какие бывают СУБД, будет говориться в отдельной

главе.

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

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

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

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

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

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

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

110

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

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

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

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

вер не должен обрабатывать их строго по очереди (“вначале выполнить це-

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

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

простыми запросами. В этом аспекте сервер баз данных аналогичен многоза-

дачной операционной системе.

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

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

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

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

пользователи могут только читать, а кто-то вообще может только вводить

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

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

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

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

блюдение этих разграничений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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