Russian Belarusian English German Japanese Ukrainian

Основы

Основные аспекты и правила при работе с Базой Данных.

Архитектура «клиент-сервер»

В сетевой архитектуре «клиент-сервер» БД размещается на компьютере-сервере сети (сервере или удаленном сервере) и называется также удаленной БД. Приложение, осуществляющее работу с этой БД, находится на компьютере пользователя. Приложение пользователя является клиентом, его также называют приложением-клиентом.
 
Клиент и сервер взаимодействуют следующим образом. Клиент формирует и отсылает запрос (SQL-запрос) серверу, на котором размещена БД. Сервер выполняет запрос и выдает клиенту в качестве результатов требуемые данные. Таким образом, в архитектуре «клиент-сервер» клиент посылает запрос и получает только те данные, которые ему действительно нужны. Вся обработка запроса выполняется на удаленном сервере. К достоинствам такой архитектуры относятся следующие факторы:
  • для работы с данными используется реляционный способ доступа, что снижает нагрузку на сеть;
  • приложения не управляют напрямую базой, управлением занимается только сервер. В связи с этим можно обеспечить высокую степень защиты данных;
  • в приложении отсутствует код, связанный с управлением БД, поэтому приложения упрощаются.
Отметим, что сервером называют не только компьютер, но и специальную программу, которая управляет БД. Так как в основе организации обмена данными между клиентом и сервером лежит язык SQL, такую программу еще называют SQL-сервером, а БД - базой данных SQL. В широком смысле слова под сервером понимают компьютер, программу и саму базу данных. SQL-серверами являются промышленные СУБД, такие как InterBase, Oracle, Informix, SyBase, DB2, Microsoft SQL Server и др. Каждый из серверов имеет свои преимущества и особенности, связанные, например, со структурой БД и реализацией языка SQL, которые необходимо учитывать при разработке приложения. Далее мы будем понимать под сервером программу (т.е. SQL-сервер), а установленную на компьютере-сервере базу данных будем называть удаленной БД. При работе в архитектуре «клиент-сервер» приложение должно:
  • устанавливать соединение с сервером и завершать его;
  • формировать и отсылать запрос серверу, получая от него результаты выполнения запроса;
  • обрабатывать полученные данные.
При этом обработка данных не имеет принципиальных отличий по сравнению с обработкой данных в локальных БД.

Базы данных и приложения

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

Бизнес-правила

Бизнес-правила представляют собой механизмы управления БД и предназначены для поддержания БД в целостном состоянии, а также для выполнения ряда других действий, например, накапливания статистики работы с БД.
Бизнес-правила являются просто правилами управления БД и не имеют отношения к бизнесу как предпринимательству.
В первую очередь бизнес-правила реализуют следующие ограничения БД:
  • задание допустимого диапазона значений;
  • задание значения по умолчанию;
  • требование уникальности значения;
  • запрет пустого значения;
  • ограничения ссылочной целостности.
Бизнес-правила можно реализовывать как на физическом, так и на программном уровнях. В первом случае эти правила (например, ограничения ссылочной целостности для связанных таблиц) задаются при создании таблиц и входят в структуру БД. В дальнейшей работе нельзя нарушить или обойти ограничение, заданное на физическом уровне.
 
Вместо бизнес-правил, заданных на физическом уровне, или в дополнение к ним можно определить бизнес-правила на программном уровне. Действие этих правил распространяется только на приложение, в котором они реализованы. Для программирования в приложении бизнес-правил используются компоненты и предоставляемые ими средства. Достоинство такого подхода заключается в легкости изменения бизнес-правил и определении правил «своего» приложения. Недостатком является снижение безопасности БД, связанное с тем, что каждое приложение может устанавливать свои правила управления БД.
 
При работе с удаленными БД в архитектуре «клиент-сервер» бизнес-правила можно реализовывать также на сервере.

Варианты архитектуры БД

Локальные БД располагаются на том же компьютере, что и работающие с ними приложения. В этом случае говорят, что информационная система имеет локальную архитектуру. Работа с БД происходит, как правило, в однопользовательском режиме. При необходимости можно запустить на компьютере другое приложение, одновременно осуществляющее доступ к этим же данным. Для управления совместным доступом к БД необходимы специальные средства контроля и защиты. Эти средства могут понадобиться, например, в случае, когда приложение пытается изменить запись, которую редактирует другое приложение. Каждая разновидность БД осуществляет подобный контроль своими способами и обычно имеет встроенные средства разграничения доступа.
 
Для доступа к локальной БД процессор баз данных BDE использует стандартные драйверы, которые позволяют работать с форматами БД dBase, Paradox, FoxPro, а также с текстовыми файлами.
 
При использовании локальной БД в сети можно организовать многопользовательский доступ. В этом случае файлы БД и предназначенное для работы с ней приложение располагаются на сервере сети. Каждый пользователь запускает со своего компьютера это расположенное на сервере приложение, при этом у него запускается копия приложения. Такой сетевой вариант использования локальной БД соответствует архитектуре «файл-сервер». Приложение при использовании архитектуры «файл-сервер» также может быть записано на каждый компьютер сети, в этом случае приложению отдельного компьютера должно быть известно местонахождение общей БД.
 
При работе с данными на каждом пользовательском компьютере сети используется локальная копия БД. Эта копия периодически обновляется данными, содержащимися в БД на сервере.
 
Архитектура «файл-сервер» обычно применяется в сетях с небольшим количеством пользователей, для ее реализации подходят персональные СУБД, например, Paradox или dBase. Достоинствами этой архитектуры являются простота реализации, а также то, что приложение фактически разрабатывается в расчете на одного пользователя и не зависит от компьютера сети, на который оно устанавливается.
 
Однако архитектура «файл-сервер» имеет и существенные недостатки.
  • Пользователь работает со своей локальной копией БД, данные в которой обновляются при каждом запросе к какой-либо из таблиц. При этом с сервера пересылается новая копия всей таблицы, данные из которой затребованы. Таким образом, если пользователю необходимо несколько записей таблицы, с сервера по сети пересылается вся таблица. В результате циркуляции в сети больших объемов избыточной информации резко возрастает нагрузка на сеть, что приводит к соответствующему снижению ее быстродействия и производительности информационной системы в целом.
  • В связи с тем, что на каждом компьютере имеется своя копия БД, изменения, сделанные в ней одним пользователем, в течение некоторого времени являются неизвестными другим пользователям. Поэтому требуется постоянное обновление БД. Кроме того, возникает необходимость синхронизации работы отдельных пользователей, связанная с блокировкой в таблицах записей, которые в данный момент редактирует другой пользователь.
  • Управление БД осуществляется с разных компьютеров, поэтому в значительной степени затруднена организация управления доступом, соблюдения конфиденциальности и поддержания целостности БД.
Удаленная БД размещается на компьютере-сервере сети, а приложение, осуществляющее работу с этой БД, находится на компьютере пользователя. В этом случае мы имеем дело с архитектурой "клиент-сервер", когда информационная система делится на неоднородные части сервер и клиент БД. В связи с тем, что компьютер-сервер отделен от клиента, его называют также удаленным сервером.
 
Клиент - это приложение пользователя. Для получения данных клиент формирует и отсылает запрос удаленному серверу, на котором помещена БД. Запрос формулируется на языке SQL, который является стандартным средством доступа к серверу при использовании реляционных моделей данных. После получения запроса удаленный сервер направляет его программе SQL Server (серверу баз данных) специальной программе, управляющей удаленной БД и обеспечивающей выполнение запроса и выдачу его результатов клиенту.
 
Таким образом, в архитектуре «клиент-сервер» клиент посылает запрос на предоставление данных и получает только те данные, которые действительно были затребованы. Вся, обработка запроса выполняется на удаленном сервере. Такая архитектура обладает следующими достоинствами:
  • снижение нагрузки на сеть, поскольку теперь в ней циркулирует только нужная информация;
  • повышение безопасности информации, связанное с тем, что обработка запросов всех клиентов выполняется единой программой, расположенной на сервере;
  • сервер устанавливает общие для всех пользователей правила использования БД, управляет режимами доступа клиентов к данным, запрещая, в частности, одновременное изменение одной записи различными пользователями;
  • уменьшение сложности клиентских приложений за счет отсутствия в них кода, связанного с контролем БД и разграничением доступа к ней.
Для реализации архитектуры «клиент-сервер» обычно используются многопользовательские СУБД, например, Oracle или Microsoft SQL Server. Подобные СУБД называют также промышленными, так как они позволяют создать информационную систему организации или предприятия с большим числом пользователей. Промышленные СУБД являются сложными системами и требуют мощной вычислительной техники и соответствующего обслуживания. Обслуживание выполняет специалист (или группа специалистов), называемый системным администратором БД (администратором).
 
Основные задачи системного администратора:
  • защита БД;
  • поддержание целостности БД;
  • обучение и подготовка пользователей;
  • загрузка данных из других БД;
  • тестирование данных;
  • резервное копирование и восстановление;
  • внесение изменений в информационную систему.
Доступ приложения С++ Builder к промышленным СУБД осуществляется через драйверы SQL-Links. При работе с «родной» для С++ Builder СУБД InterBase можно обойтись без драйверов SQL-Links.
 
Описанная архитектура является двухуровневой (уровень приложения-клиента и уровень сервера БД). Клиентское приложение называют также сильным, или «толстым», клиентом. Дальнейшее развитие данной архитектуры привело к появлению трехуровневого варианта архитектуры «клиент-сервер» (приложение-клиент, сервер приложений и сервер БД).
 
В трехуровневой архитектуре часть средств и кода, предназначенных для организации доступа к данным и их обработки, из приложения-клиента выделяется в сервер приложений. Само клиентское приложение при этом называют слабым, или «тонким», клиентом. В сервере приложений удобно располагать средства и код, общие для всех клиентских приложений, например, средства доступа к БД.
 
Основные достоинства трехуровневой архитектуры «клиент-сервер» состоят в следующем:
  • разгрузка сервера от выполнения части операций, перенесенных на сервер приложений;
  • уменьшение размера клиентских приложений за счет разгрузки их от лишнего кода;
  • единое поведение всех клиентов;
  • упрощение настройки клиентов при изменении общего кода сервера приложений автоматически изменяется поведение приложений клиентов.
Локальные приложения БД называют одноуровневыми, а клиент-серверные приложения БД многоуровневыми.

Варианты создания таблиц

Создание таблицы для базы данных можно выполнить программно (в процессе выполнения приложения) или с помощью инструментального средства, например, Database Desktop (перед началом работы с приложением).
 
Приведем пример кода программного создания таблицы для базы данных:
void __fastcall TForm1::FormCreate(TObject *Sender)
{
Table1->Active = false; // Компонент Table1 должен быть не активным
Table1->DatabaseName = "BCDEMOS";
Table1->TableType = ttParadox; // Задается тип таблицы Paradox
Table1->TableName = "CustInfo1"; // Имя таблицы
if (!Table1->Exists) // Проверка существования таблицы
// Описание полей таблицы
Table1->FieldDefs->Clear();
TFieldDef *pNewDef = Table1->FieldDefs->AddFieldDef();
pNewDef->Name = "Fld1"; // Имя 1-го поля
pNewDef->DataType = ftlnteger;
pNewDef->Required = true;
pNewDef = Table1->FieldDefs->AddFieldDef();
pNewDef->Name = "Field2"; // Имя 2-го поля
pNewDef->DataType = ftString;
pNewDef->Size =30; // Описание индексов
Table1->IndexDefs->Clear(); // 1-й индекс не имеет имени, как первичный ключ в таблице Paradox
Table1->IndexDefs->Add("","Field1", TIndexOptions() << ixPrimary << ixUnique);
Table1->IndexDefs->Add("Fld2Index", "Field2" / TIndexOptions() << ixCaselnsensitive); // Создание таблицы и ее активизация
Table1->CreateTable();
Table1->Active = true; }
}
В приведенном примере в обработчике события создания формы приложения выполняется описание полей, задание индексов, создание и активизация таблицы. Такой вариант создания таблиц, по-видимому, наиболее целесообразно использовать для создания временных таблиц с последующим их использованием и удалением. Более удобным вариантом создания таблиц является использование инструментальных средств.
 
Для свойства TableTYpe, определяющего тип таблицы, могут задаваться также следующие значения:
  • ttDefauit - таблица, тип которой назначается в зависимости от расширения имени файла (db или без расширения - таблица Paradox, dbf - таблица dBASE, txt - текстовый файл);
  • ttDBase - таблица dBASE;
  • ttFoxPro - таблица FoxPro;
  • ttASCI - текстовый файл произвольной длины с ограниченными строками для каждого поля.

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

Визуальные компоненты для работы с данными расположены на странице Data Controls Палитры компонентов и предназначены для построения интерфейсной части приложения. Они используются для навигации по набору данных, а также для отображения и редактирования записей. Часть визуальных компонентов для работы с данными служит для выполнения операций с полями отдельной записи, они отображают и позволяют редактировать значение поля текущей записи. К таким компонентам относятся, например, однострочный редактор DBEdit и графическое изображение DBImage.
 
Каждый из таких компонентов имеет два свойства, через которые обеспечивается его связь с полем выбранного источника данных. Свойство DataSource задает имя источника данных, который подключен к одному из наборов данных приложения. Свойство DataField задает связь элемента управления с конкретным полем источника данных, значение этого свойства выбирается путем выбора имени поля из раскрывающегося списка. Другие компоненты служат для отображения и редактирования сразу нескольких записей. Примерами таких компонентов являются сетки DBGrid и DBCtrlGrid, выводящие записи набора данных в табличном виде.
 
Визуальные компоненты для работы с данными похожи на соответствующие компоненты страниц Standard, Additional и Win32 и отличаются, в основном, тем, что ориентированы на работу с БД и имеют дополнительные свойства DataSource и DataField. Первое из них указывает на источник данных - компонент DataSource, второе на поле набора данных, с которым связан визуальный компонент. Например, однострочный редактор DBEdit работает так же, как однострочный редактор Edit, отображая строковое значение и позволяя пользователю изменять его. Отличие компонентов состоит в том, что в редакторе DBEdit отображается и изменяется значение определенного поля текущей записи набора данных.
 
Для всех визуальных компонентов, предназначенных для отображения и редактирования значений полей, при изменении пользователем их содержимого набор данных автоматически переводится в режим редактирования. Произведенные с помощью этих компонентов изменения также автоматически сохраняются в связанных с ними полях при наступлении определенных событий, таких как потеря фокуса визуальным компонентом или переход к другой записи набора данных.
 
При программном изменении содержимого этих визуальных компонентов набор данных не переводится в режим редактирования автоматически. Для этой цели в коде должен предварительно вызываться метод Edit набора данных. Чтобы сохранить изменения в поле (полях) текущей записи, программист также должен предусмотреть соответствующие действия, например, вызов метода Post или переход к другой записи набора данных.

Доступ к значению поля

Объект поля, как и любой другой объект, имеет имя (название), определяемое его свойством Name типа Ansistring. Имя объекта Field зависит от того, является ли поле динамическим или статическим. По умолчанию для динамического поля имя объекта Field совпадает с именем соответствующего физического поля таблицы БД, для которого создан объект, и не может быть изменено. Имя статического поля является составным и по умолчанию образуется путем слияния имен набора данных и имени физического поля таблицы БД. Например, если для физического поля Name набора данных Table1 с помощью Редактора полей создано статическое поле, то оно получит имя Table1Name. Можно изменить это имя с помощью Инспектора объектов, когда соответствующее статическое поле выбрано в Редакторе полей.
 
В отличие от имени объекта Field, свойство FieldName типа Ansistring содержит имя физического поля, заданное при создании таблицы. Не следует путать свойства Name и FieldName, они обозначают разные объекты и в общем случае могут не совпадать.
 
Пример обращения к полю:
Table1->FieldByName("R_Salary")->DisplayLabel = "Оклад";
Table1R_Salary->DisplayLabel = "Оклад";
Здесь для статического поля R_salary приведены два возможных способа обращения: по имени поля в наборе данных и по имени объекта Field поля. Заметим, что свойство DisplayLabel определяет текст, отображаемый в качестве заголовка поля набора данных.
Для определения порядкового номера поля в наборе данных (нумерация начинается с единицы) можно использовать свойство FieldNo типа int, например, так:
int x = Table1->FieldByName("R_Date")->FieldNo;
Edit1->Text=IntToStr(х);
Для доступа к значению поля служат свойства value и AsXXX. Для объекта поля класса TField свойство value имеет тип variant и представляет собой фактические данные в этом объекте. При выполнении приложения это свойство используется для чтения и записи значений в поле. Если программист обращается к свойству value, то он должен самостоятельно обеспечивать преобразование и согласование типов значений полей и читаемых или записываемых значений. В таблице ниже приводятся возможные типы свойства value для ряда различных классов объектов, наследуемых от класса TField.
Тип объекта поля Тип свойства value
TField Variant
TStringField, TBLOBField Ansistring
TIntegerField, TSmalllntField, TWordField, TAutoincField int
TBCDField Currency
TFloatField, TCurrencyField double
TBooleanField bool
TDateTimeField, TDateField, TTimeField TDateTime
Рассмотрим пример, в котором доступ к значению поля осуществляется с помощью свойства value:
void fastcall TForm1::Button1Click(TObject *Sender)
{
Ansistring s;
float y;
// Доступ по имени в наборе данных
s = Table1->FieldByName("G_Salary")->Value;
у = Table1->FieldByName("G_Salary")->Value;
Label1->Caption = s;
Label2->Caption = FloatToStr(y);
// Доступ, как к отдельному компоненту
у = Table1G_Salary->Value;
Label3->Caption = FloatToStr(у);
s = Table1G_Salary->Value;
Edit1->Text=s;
}
Здесь чтение значения поля G_salary текущей записи набора данных Table1 выполняется несколькими способами. При доступе с помощью свойства value к полю по имени в наборе данных значение поля G_salary типа $ (Money) (и вещественного типа тоже) можно читать и использовать и как строковое, и как вещественное значение.
Пояснение к приведенному примеру подразумевает автоматическое допустимое преобразование типов. К примеру, вещественный тип можно преобразовать к строковому типу, обратное преобразование в общем случае невыполнимо. То же справедливо для доступа с помощью свойства value к полю как отдельному компоненту.
Доступ к полю по имени объекта типа TField, например, Table1Salary, возможен только для статических полей, которые существуют на этапе разработки приложения. Попытка использовать имя объекта динамического поля приводит к ошибке при компиляции, т.к. объект поля еще не создан.
Поскольку при доступе к полю с помощью свойства value программист должен обеспечивать преобразование и согласование типов значений, то часто более удобно использовать варианты свойства AsXXX:
  • AsBCD типа Tbcd
  • AsBoolean типа bool
  • AsCurrency типа Currency
  • AsDateTime типа TdateTime
  • AsFloat типа double
  • Aslnteger типа int
  • AsSQLTimeStamp типа TSQLTimeStamp
  • AsString типа AnsiString
  • As Variant типа Variant
При использовании любого из этих свойств выполняется автоматическое преобразование типа значения поля к типу, соответствующему названию свойства. При этом преобразование должно быть допустимо, в противном случае возникает ошибка компиляции по несоответствию типов, например, при попытке прочитать логическое значение как целочисленное.
 
Приведем теперь пример, где доступ к значению поля происходит с помощью свойств AsXXX:
Void fastcall TForm1::Button1Click(TObject *Sender)
{
// Доступ по имени поля в наборе данных
AnsiString s = Table1->FieldByName("N_Number")->AsString;
float x = Table1->FieldByName("Time")->AsFloat;
Edit1->Text= s;
Edit2->Text = FloatToStr(x);
// Доступ, как к отдельному компоненту
s = Table1Currency->AsString; // денежное поле
х = Table1Date->AsFloat; // Поле даты
Edit3->Text = s;
Edit4->Text = FloatToStr(x);
}
Как и в предыдущем примере, чтение значений полей вещественного типа, типа времени, денежного типа и типа даты осуществляется двумя способами. Доступ к полю выполняется по имени поля и по имени объекта поля, а значение поля интерпретируется как строковое или как вещественное с помощью свойств Asstring и AsFloat соответственно.
Для того чтобы записать значение в поле, оно должно допускать модификацию, а набор данных должен находиться в соответствующем режиме, например, редактирования или вставки.
При необходимости программист может запретить модификацию поля, а также скрыть его, используя свойства Readonly и Visible типа bool. Возможность модификации данных в отдельном поле определяется значением свойства CanModify типа bool. Напомним, что свойства Readonly и canModify есть также у набора данных: они определяют возможность модификации набора данных (всех его полей) в целом.
Даже если набор данных является модифицируемым и его свойство CanModify имеет значение true, для отдельных полей этого набора редактирование может быть запрещено, и любая попытка изменить значение такого поля вызовет исключение.
Если поле является невидимым (свойство visible имеет значение false), но разрешено для редактирования (свойство Readonly имеет значение false), то значение этого поля можно изменить программно.
Рассмотрим управление видимостью поля и возможностью его модификации на примере:
Table1->FieldByName("Number")->ReadOnly = true;
Table1->FieldByName("Salary")->Visible = false;
Здесь для поля Number запрещаются любые изменения, а поле salary скрывается, однако для него по-прежнему допускаются чтение и изменение значения, если его свойству Readonly не установлено значение true.
Для полей, имеющих типы TBLOBField (BLOB-объект), TGraphicField (графическое изображение) и TMemoField (текст), доступ к их содержимому выполняется обычными для объектов данного типа способами. Например, для загрузки содержимого из файла можно использовать метод LoadFromFile, а для сохранения содержимого поля в файле метод SaveToFile.

Заголовки столбцов и данные

Полосы заголовков столбцов и данных являются основными полосами, в которых размещаются компоненты, обеспечивающие табличный вывод содержимого набора данных. Заголовки столбцов выводятся на каждом листе отчета. Для заголовков столбцов данных в полосу заголовков обычно помещаются компоненты QRiabel, в которые заносится текст, соответствующий полям данных.
 
Для вывода значений полей записей в полосу данных обычно помещаются компоненты QRDBText и QRExpr. Более простым является использование компонентов QRDBText, каждый из которых отображает значение связанного с ним поля. Имя набора данных указывается в свойстве Dataset, а имя поля задается в свойстве DataFileld.
 
На этапе разработки в отчете присутствует только одна полоса данных, но при формировании отчета отдельная полоса данных будет выведена для каждой записи отчета. Напомним, что если набор данных является пустым и не содержит записей, то область данных не выводится. Чтобы для пустого набора данных были выведены остальные полосы (кроме полос данных), свойству PrintIfEmpty компонента QuickRep устанавливается значение true (по умолчанию).
 
Компонент QRExpr позволяет вставлять в отчет значение выражения, рассчитываемого обычно с участием различных полей записей. Выражение заносится в свойство Expression типа String, для формирования которого удобно использовать окно Expression Wizard (Мастер выражений), вызываемое через Инспектор объектов.
 
Для вставки в выражение имени поля нужно нажать кнопку Database Field (Поле БД) и в открывшемся окне выбрать набор данных и имя поля. В выражении можно использовать функции, которые разбиты по категориям и выбираются в специальном окне, вызываемом нажатием кнопки Function (Функция).
 
Названия полей и функций можно набирать и вручную, однако это увеличивает вероятность ошибки. Чтобы протестировать введенное выражение, следует нажать кнопку Validate, при этом выполняется проверка выражения, а разработчику выдается сообщение о корректности выражения или об ошибке. В выражении можно использовать только поля наборов данных, которые размещены на форме отчета. В противном случае набор данных оказывается недоступен для компонента QRExpr.
 
При разработке приложения такие компоненты отчета, как QRLabel, QRDBText и QRExpr, имеют одинаковый внешний вид.

Заголовок отчета

Заголовок отчета выводится один раз на первой странице сразу под верхним колонтитулом, если он есть. В полосе заголовка обычно размещаются надписи QRLabel, содержащие требуемый текст (как правило, в качестве заголовка выводится название всего отчета). При необходимости в заголовке можно разместить, например, сведения о названии, адресе и телефоне организации, а также логотип.
 
Для вывода названия отчета используется компонент QRiabel. К примеру, для названия установить шрифт Arial размером 14 пт. Логотип загружается в компонент QRImage. Для шрифта других компонентов отчета с помощью свойства Font компонента QuickRep можно установить иной размер.

Инструменты БД

Инструменты - это программы, предназначенные для обслуживания БД, а также для выполнения вспомогательных действий при разработке приложений, например, для создания таблиц и отладки SQL-запросов. Совместно с С++ Builder поставляется большое число инструментов, применимых для работы как с локальными, так и с удаленными БД.
 
Программа SQL Builder предназначена для упрощения создания SQL-запросов. С помощью этой программы разработчику достаточно удобно конструировать запросы, которые сохраняются в виде текстового файла с расширением sql. Программа SQL Builder позволяет достаточно просто и удобно выполнить связывание (соединение) таблиц.
 
С помощью программы Data Pump можно выполнить перенос данных между таблицами БД. Под переносом понимается не перемещение, а копирование данных из таблиц исходной БД (источника) в таблицы другой БД (приемника). В результате переноса в базе-приемнике автоматически создаются таблицы с именами копируемых таблиц источника, и в них дублируется информация этих таблиц.
 
Программа SQL Explorer представляет собой аналог Проводника Windows, с помощью которого можно просматривать и редактировать базу данных. В зависимости от версии эта программа имеет различные возможности и даже разные названия, например, SQL Explorer, Explorer или Database Explorer.