МЕТОДИЧЕСКОЕ ПОСОБИЕ ДЛЯ ВЫПОЛНЕНИЯ КУРСОВОЙ РАБОТЫ по дисциплине БАЗЫ ДАННЫХ. «Разработка баз данных InterBase и клиентских приложений в среде Borland C++».


Чтобы посмотреть этот PDF файл с форматированием и разметкой, скачайте его и откройте на своем компьютере.
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИ
И

ФЕДЕРАЛЬНОЕ ГОСУДАРС
ТВЕННОЕ АВТОНОМНОЕ О
БРАЗОВАТЕЛЬНОЕ УЧРЕЖ
ДЕНИЕ ВЫСШЕГО ПРОФЕС
СИОНАЛЬНОГО ОБРАЗОВА
НИЯ

«Национальный исследовательский ядерный университет «МИФИ»

Технологический институт




филиал
федерального государственного автономного образовательного учреждения высшего
профессионального образования «Национальный исследовательский ядерный университет «МИФИ»

(ТИ НИЯУ МИФИ)


КАФЕДРА

ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И ПРИКЛАДНОЙ МАТЕМАТИКИ

С.Н.Артамкин

Кафедральный регистрационный номер №
2.004




МЕТОДИЧЕСКОЕ ПОСОБИЕ

ДЛЯ
ВЫПОЛНЕНИЯ
КУРСОВОЙ РАБОТЫ

по дисциплине


БАЗЫ ДАННЫХ


«Разработка баз данных
InterBase

и клиентских

приложений в среде
Borland

C
++
»


Направление подготовки

09.03.01

Информатика и вычислительная техника


Профиль подготовки

Системы автоматизированного проектирования в машиностроении


Квалификация (степень) выпускника

бакалавр

(бакалавр, магистр, специалист)


Форма обучения

очная

(очная, очно
-
заочная и др.)


Лесной

2014

Базы данных Методическое пособие по курсовой работе


2


Артамкин С.Н. Методическое пособие для выполнения курсовой работы по
дисциплине Базы данных «Разработка баз данных InterBase и клиентских приложений в
среде Borland C++» / С.Н.

Артамкин.


Лесной : ТИ НИЯУ МИФИ, 2014.


58

с.



Утверждено на заседании ка
федры

29

сентября


201
4

г., протокол №
2



Данное пособие предназначено для студентов бакалавриата направления подготовки
09.03.01

Информатика и вычислительная техника, профиль подготовки
Системы
автоматизированного проектирования в машиностроении
.
Описано проектирование
модели данных базы данных в ErWin, разработка клиентских приложений в среде Borland
C++, отдельно дан пример модели данных, базы данных и клиентского приложения.

На
сайте кафедры и в локальной сети представлены дополнительные к метод
ическому
пособию материалы в электронном виде.



Базы данных Методическое пособие по курсовой работе


3


Оглавление

1.

Проектирование модели данных базы данных в
ErWin

..............................

5

1.1.

Создание логической модели данных

................................
.....................

5

1.1.1.

Отображение модели данных в
ERWin
.

................................
...........

5

1.1.2.

Уровни логический модели

................................
...............................

7

1.1.3.

Сущности и атрибуты

................................
................................
........

7

1.1.4.

Связи

................................
................................
................................
.

11

1.1.5.

Ключи

................................
................................
...............................

16

1.1.6.

Домены

................................
................................
.............................

19

1.2.

Создание логической модели данных

................................
...................

22

1.2.1.

Выбор сервера

................................
................................
..................

22

1.2.2.

Таблицы, столбцы и представления

................................
...............

23

1.2.3.

Представления

................................
................................
.................

24

1.2.4.

Создание генераторов и автоинкрементных полей

.......................

25

1.2.5.

Прямое проектирование (генерация базы данных)

........................

29

2.

Разработка клиентских приложений в среде
Borland

C
++

........................

31

2.1.

Работа с компонентами IBX или использование InterBase eXpress в
приложениях на C++Builder, с СУБД Firebird и InterBase

............................

31

2.1.1.

Клиентская библиотека

................................
................................
...

31

2.1.2.

Организация доступа к данным

................................
......................

32

2.1.3.

Подсоединение к БД

................................
................................
........

35

2.1.4.

Создание БД

................................
................................
.....................

35

2.1.5.

TIBTransaction

................................
................................
..................

36

2.1.6.

Датасеты

................................
................................
...........................

38

2.1.7.

IBDataSet

................................
................................
..........................

38

2.1.8.

Буферизация записей

................................
................................
.......

43

2.1.9.

Обновление данных

................................
................................
.........

43

2.1.10.

Перебор записей

................................
................................
...............

44

2.1.11.

Master
-
Detail

................................
................................
.....................

44

2.1.12.

Locate (поиск)

................................
................................
...................

45

2.1.13
.

IBTable

................................
................................
..............................

45

2.1.14.

Locate

................................
................................
................................

46

2.1.15.

IBQuery

................................
................................
.............................

46

Базы данных Методическое пособие по курсовой работе


4


2.1.16.

Пара
метризированные запросы

................................
......................

47

2.1.17.

Фильтрация

................................
................................
......................

48

IBTable

................................
................................
................................
.........

48


................................
................................
.....................

48

OnFilterRecord

................................
................................
............................

48

2.1.18.

IBUpdateSQL

................................
................................
....................

49

2.1.19.

IBSQL

................................
................................
...............................

49

2.1.20.

IBStoredProc

................................
................................
.....................

49

2.1.21.

EIBError

................................
................................
............................

50

2.1.22.

IBDatabaseInfo

................................
................................
..................

50

2.1.23.

IBSQLMonitor

................................
................................
...................

50

2.1.24.

IBExtract

................................
................................
...........................

51

2.1.25.

IB
Script

................................
................................
.............................

52

2.1.26.

IBDatabaseINI

................................
................................
...................

53

2.2.

Компоненты

Services API (InterBase Admin)

................................
........

53

2.3.

Использование и управление IBTransaction в приложениях

...............

55

3.

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

..........

57

Список литературы

................................
................................
............................

57




Базы данных Методическое пособие по курсовой работе


5


1.

Проектирование модели данных базы данных в
ErWin

1.1.

Создание логической модели данных

1.1.1.

Отображение модели данных в
ERWin
.

ERWin

имеет два уровня представления модели


логический и
физический.

Логический уровень



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

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

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

(см. рис.1 )





Рис.
1
.
Внешний вид
ERWin
.

Палитра инструментов
ERWin

выгляд
и
т различно на разных уровнях
отображения модели. На логическом уровне (см. рис. 2) палитра
инструментов
имеет:

1)

Слева направо, верхний ряд:



кнопку указателя (режим мыши)


в этом режиме можно установить
фокус на каком
-
либо объекте модели;



кнопку внесения сущности


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



кнопку категории. Категория, или категориальная связь,
-

специальный
тип связи между сущностями (здесь не рассматривается).



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

Переключатель
физическая/логическая
модель

Базы данных Методическое пособие по курсовой работе


6


2)

Слева направо, нижний ряд:



кнопку переключения атрибутов внутри

сущностей и между ними.
Атрибуты могут перемещены способом drag&drop;



кнопку создания связей: идентифицирующую, “многие
-
ко
-
многим” и не
идентифицирующую.








Рис. 2
.

Палитра инструментов на логическом уровне.


На физическом уровне (рис. 3) палитра инструментов имеет:



вместо кнопки категорий кнопку

внесения представлений (
view
);



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








Рис.
3
.

Палитра инструментов на физическом уровне.

Режим мыши


Перемещение
колонок между
или внутри
таблиц

Таблица и
представление

Текст

Связь

Режим мыши

Сущность

Категория

Текст

Перемещение
атрибутов
между или
внутри

сущностей

Связь

Базы данных Методическое пособие по курсовой работе


7


1.1.2.

Уровни логический модели

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



диаграмма

сущность
-
связь

(Entity Relationship Diagram, ERD);



модель данных, основанная на ключах (
Key

Based

model
,
KB
);



полная

атрибутивная

модель

(Fully Attributed model, FA).

Диаграмма сущность
-
связь представляет собой модель данных верхнего
уровня. Она включает сущности и
взаимосвязи, отражающие основные
бизнес
-
правила предметной области. Такая диаграмма не слишком детали
-
зирована, в нее включаются основные сущности и связи между ними, ко
-
торые удовлетворяют основным требованиям, предъявляемым к ИС. Диа
-
грамма сущность
-
связ
ь может включать связи многие
-
ко
-
многим и не
включать описание ключей. Как правило,
ERD

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

Модель данных, основанная на ключах
-

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

Полная атрибутивная модель
-

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


1.1.3.

Сущности и атрибуты

Основные компоненты диаграммы
Erwin

-

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

строка в таблице, а
атрибут
у


колонка таблицы.

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

Щелчок

пра
вой кнопкой мыши по сущности и выбор из всплывающего
меню пункта
Entity

Editor

позволяет вызвать диалог
Entity

Editor
, в котором
определяются имя, описание и комментарии сущности (рис. 4).

Базы данных Методическое пособие по курсовой работе


8



Рис 4. Диалоговое окно
Entity

Editor
.


Каждая сущность должна быть полностью определена с помощью тек
-
стового описания в закладке
Definition
. Закладки
Note
,
Note

2,
Note

3,
UDP

(
User

Defined

Properties

-

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

-

Закладка
Definition

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

COMMENT

on

entity
_
name
).

-

Заклады
Note

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

-

В закладке
Note

2

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

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

-

Закладка
Note

3 позволяет вводить примеры данных для сущности (в
произвольной форме).

-

В закладке
Icon

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

Базы данных Методическое пособие по курсовой работе


9


Для определения
UDP

служит диалог
User
-
Defined

Property

Editor

(вызывается из меню
Edit
/
UDPs
). В нем необходимо указать вид объекта, для
которого заводится
UDP

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

ERwin

поддерживает для
UDP

шести типов данных:



Date
. Дата. Испол
ьзуется формат
MM
/
DD
/
YY
. Для выбора значения даты
можно использовать контекстный календарь;



Int
. Целое число;



Real
. Действительное число;




Text
.
Строка

(ASCII);



List
. Список. При задании списка в диалоге
User
-
Defined

Property

Editor

значения следует разделять запятой, значение по умолчанию выделяется
символом "~"



Command
. Команда
-

выполняемая строка.



Рис

5.
User
-
Defined Property Editor.

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

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

Для описания атрибутов следует щелкнуть
правой кнопкой по сущности

и

выбрать в появ
ившемся меню пункт
Attribute

Editor

(см. рис. 6).

Базы данных Методическое пособие по курсовой работе


10



Рис 6.
Attribute

Editor



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

Attribute

можно указать имя атрибута, имя

колонки,

соответствующе
й

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

Рис 7. Диалоговое окно
New

Attribute
.



Для атрибутов первичного ключа н
а вкладке
General

диалога
Attribute

Editor

необходимо сделать пометку в окне
Primary

Key
.


Базы данных Методическое пособие по курсовой работе


11


-

Закладка
Definition

позволяет записывать определения отдельных атри
-
бутов. Определения атрибутов можно также сгенерировать как часть
схемы (
CREATE

COMMENT

on

entity
_
name
.
attribute
_
name
).

-

Закладка
Note

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

-

Закладка
UDP

служит для задания зна
чений свойств, определяемых
пользователем. Предварительно эти свойства должн
ы быть внесены в
диалог
User
-
Defined

Property

Editor

как свойства атрибутов.


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

диалога
Attribu
te

Editor

вызывает диалог
Migrate

Attribute

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




1.1.4.

Связи

Связь является логическим соотношением между сущностями.

Каждая связь должна именоваться глаголом или глагольной фразой
(
Relationship

Verb

Phrases
).

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

Optio
ns
/
Relationship

и затем
включить опцию
Verb

Phrase
.

На логическом уровне можно установить идентифицирующую связь
один
-
ко
-
многим, связь многие
-
ко
-
многим и неидентифицирующую связь
один
-
ко
-
многим (соответственно это кнопки слева направо в палитре ин
-
струмент
ов).

В
IDEF
1
X

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

Идентифицирующая связь устанавливается между независимой
(родительский конец связи) и зависимой (дочерний конец связи) сущностями.
Когда
рисуется идентифи
цирующая связь,
ERwin

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

(
FK
).

Базы данных Методическое пособие по курсовой работе


12


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

NULL
, что означает невозможность внесения записи в
дочернюю (зависимую) сущность без и
нформации о родительской (главной)
сущности.

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

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


пунктирной.

Для создания новой связи следует:



установить курсор на

нужной кнопке в палитре инструментов
(идентифицирующая или неидентифицирующая связь) и нажать левую
кнопку мыши;



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

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

Для редактирования свойств связи следует "кликнуть" правой кнопкой
мыши по связи и выбрать на контекстном меню пункт
Relationship

Editor

(см.
рис. 8)


Рис. 8 Диалог
Relationship

Editor
.

Базы данных Методическое пособие по курсовой работе


13



В закладке
General

появившегося диалога можно задать мощность, имя
и тип связи
.

Мощность связи (
Cardinality
) служит для обозначения отношения чис
ла
экземпляров родительской сущно
сти к числу экземпляров дочерней.

Различают четыре типа мощности:



общий случай, когда одному экземпляру родительской сущности соот
-
ветствуют 0, 1 или много экземпляров дочерней сущности
(
не помечает
ся
каким
-
либо символом
)
;



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



символом
Z

помечается случай, когда одному экземпляру родительской
сущности соответствует 0 или 1 экземпляр дочерней сущност
и
(исключены множественные значения);



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

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

Options
/
Relationship

и затем
включить опцию
Cardinality
.


Тип связи (идентифицирующая/не идентифицирующая).

Для не идентифицирующей связи можно указать обязательность (
Nulls
).
В случае обязательной связи (
No

Nulls
) при генерации схемы БД атрибут
внешнего ключа пол
учит признак
NOT

NULL

несмотря на то
,

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

Allowed
) внешний ключ может принимать
значение
NULL
. Необязательная не идентифицирующая связь помечается
проз
рачным ромом со стороны родительской сущности.

В закладке
Definition

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

В закладке
Rolename
/
RI

Actions

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

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

По умолчанию в списке атрибутов показывается
только имя роли. Для
отображения полного имени атрибута (как функционального имени, так и
имени роли) следует в контекстном меню, которое появляется, если
щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому
объектами модели, вы
брать пункт
D
isplay

Options
/
Entities

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


14


опцию
Rolename
/
Attribute
. Полное имя показывается как функциональ
ное
имя и базовое имя, разделенные точкой.






Рис
. 9.
Вкладка

Rolename/RI Actions
диалога

Relationship Editor



Правила ссылочной целостности
(
referential

integrity
,
RI
)
-

логические
конструкции, которые выражают бизнес
-
правила использования данных и
представляют собой правила вставки, замены и удаления. При генерации
схемы БД на основе опций логической модели, задаваемых в закладке
Rolename
/
RI

Actions
, будут сгенерирова
ны правила декларативной ссылоч
-
ной целостности, которые должны быть предписаны для каждой связи, и
триггеры, обеспечивающие ссылочную целостность. Триггеры представляют
собой программы, выполняемые всякий раз при выполнении команд встав
ки,
замены или уда
ления (
INSERT
,
UPDATE

или
).



ERwin

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

по умолчанию (приведены в
табл. 1), могут бы
ть изменены в редакторе
Referential

Integrity

Default
,
который вызывается, если щелкнуть по кнопке
RI

Defaults

диалога
Target

Server

(меню
Server
/
Target

Server
).



Базы данных Методическое пособие по курсовой работе


15


Таблица 1.

Значения
RI
, присваиваемые в
ERwin

no

умолчанию, возможные режимы для
тип
ов

связи



Идентифици
-
рующая
связь


Неидентифи
-
цирующая связь
(
Nulls

Allowed
)


Неидентифи
-
цирующая связь


(
No

Nulls
)


Категориаль
-
ная связь


Child


Возможные
режимы

RESTRICT,
CASCADE,
NONE


RESTRICT,
CASCADE, NONE,
DEFAULT


RESTRICT, CASCADE,


RESTRICT,
CASCADE,
NONE .


Child


Режимы по
умолчанию

NONE


NONE


NONE


NONE


Child

Insert

Возможные
режимы


RESTRICT,
CASCADE,
NONE


RESTRICT,
CASCADE, NONE,
DEFAULT


RESTRICT,
CASCADE,


RESTRICT,
CASCADE,
NONE


Child

Insert

Режимы по
умолчанию


RESTRICT




RESTRICT


RESTRICT


Child

Update

Возможные

режимы


RESTRICT,
CASCADE,

NONE


RESTRICT,
CASCADE, NONE,
DEFAULT


RESTRICT,
CASCADE,


RESTRICT,
CASCADE,

NONE


Child

Update

Режимы по
умолчанию


RESTRICT




RESTRICT


RESTRICT


Возможные

режимы


RESTRICT,
CASCADE,
NONE


RESTRICT,
CASCADE, NONE,
DEFAULT


RESTRICT, CASCADE,


RESTRICT,
CASCADE,
NONE


Parent


Режимы по
умолчанию


RESTRICT




RESTRICT


CASCADE


Parent Insert
Возможные

режимы


RESTRICT,
CASCADE,
NONE


RESTRICT,
CASCADE, NONE,



RESTRICT, CASCADE,
DEFAULT


RESTRICT,
CASCADE,
NONE


Parent

Insert

Режимы по
умолчанию


NONE


NONE


NONE


NONE


Parent

Update

Возможные
режимы


RESTRICT,
CASCADE,
NONE


RESTRICT,
CASCADE, NONE,
DEFAULT


RESTRICT, CASCADE,


RESTRICT,

CASCADE,
NONE


Parent

Update

Режимы по
умолчанию


RESTRICT




RESTRICT


CASCADE


Базы данных Методическое пособие по курсовой работе


16


1.1.5.

Ключи

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

Первичный ключ (
primary

key
)

-

это атрибут или группа атрибутов,
одно
значно идентифицирующая экземпляр сущности. Атрибуты первичного
ключа на диаграмме не требуют специального обозначения
-

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

При внесени
и нового атрибута в диалоге
Attribute

Editor

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

Key

в нижней части закладки
General

.

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

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

претендующих
на роль первичного ключа. Такие претенденты называются потенциальными
ключами (
candidate

key
).

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

это
список атрибуто
в выше горизонтальной линии.

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



Уникальность. Два экземпляра не должны иметь одинаковых
значений возможного ключа.



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


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

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

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

Каждая сущность должна иметь по крайней мере один потенциальный
ключ. Многие сущности имеют только один потенциальный ключ. Такой
ключ становится первичным. Некоторые сущности могут иметь более од
ного
возможного ключа. Тогда один из них
становится первичным, а ос
тальные
-

альтернативными ключами.

Альтернативный ключ (
Alternate

Key
)
-

это потенциальный ключ, не
ставший первичным.

Базы данных Методическое пособие по курсовой работе


17


ERwin

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

При работе ИС часто бывает необходимо обеспечить доступ к несколь
-
ким экземплярам сущности, объединенным каким
-
либо одним признаком.
Для повышения производительности в этом случае используются неун
и
-
кальные индексы.
ERwin

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

Entries

(инверсионные входы).


Inversion

Entry

-

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

генерирует
неуникальный индекс для каждого
Inversion

Entry
.

Создать альтернативные ключи и инверсио
нные входы можно в заклад
-
ке
Key

Group

диалога
Attribute

Editor

(рис. 10). Если щелкнуть по кнопке
,

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

Group

Editor

(рис. 11). В верхней части диалога находится список ключей, в
нижней
-

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

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



Рис
. 10.
Вкладка

Key Group
диалога

Attribute Editor.





Базы данных Методическое пособие по курсовой работе


18




Рис
. 11.
Диалог

Key Group Editor.


Дл
я создания нового ключа следует

щелкнуть по кнопке
New
. Появля
-
ется диалог
New

Key

Group

(рис. 12).



Рис. 12. Диалог
New

Key

Group

Каждому ключу соответствует индекс, имя которого также присваивает
-
ся автоматически ("
XAKNENTITY
" для альтернативного ключа и "
XIENENTITY
" для инверсионного входа, где N
-

порядковый номер ключа,
ENTITY

-

имя сущности). Имена ключа и индекса при

желании можно
изменить вручную.

На диаграмме атрибуты альтернативных ключей обозначаются как
(
AKn
.
m
), где
n

-

порядковый номер ключа,
m

-

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

ставится после
каждого.

Инверсион
ные входы обозначаются как (
lEn
.
m
), где
n

-

порядковый
номер входа
,

m

-
порядковый номер атрибута.

Базы данных Методическое пособие по курсовой работе


19


Если один атрибут входит в состав нескольких ключей, ключи
перечисляются в скобках через запятую (атрибут
Дата рождения
входит в
состав АК1 и
IE
4). По умолчанию номера альтернативных ключей и инвер
-
сионных входов рядом с именем атрибута на диаграмме не показываются.
Для отображения номера следует в контекстном меню, которое появляется,
если щелкнуть левой кнопкой мыши по лю
бому месту диаграммы, не заня
-
тому объектами модели, выбрать пункт
Display

Options
/
Entities

и затем
включить опцию
Alternate

Key

Designator

(
AK
)
.

Внешние ключи (
Foreign

Key
)

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

атрибуты первичного ключа в
дочерней сущности и эти атрибуты образуют внешний ключ в дочерней
сущности (миграция ключа). Атрибуты внешнего ключа обозначаются сим
-
волом (
FK
) после своего имени.

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

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

Group

диалога
Attribute

Editor

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

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

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


1.1.6.

Домены

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

В
ERwin

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

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

Для создания домена в логической модели служит диалог
Domain


Dictionary

Editor

(рис. 13).

Его можно вызвать из меню
Edit
/
Domain

Dictionary

Базы данных Методическое пособие по курсовой работе


20


п
o

кнопке,
расположенной в верхней левой части закладки
General

диалога
Attribute

Editor

(см. рис. 6).



Рис. 13. Диалог
Domain

Dictionary

Editor

Для создания нового домена в диалоге
Domain

Dictionary

Editor

следует:



щелкнуть по кнопке
New
. Появляется диалог
New

Domain

(рис. 14);



выбрать родительский домен из списка
Domain

Parent
. Новый домен
можно создать на основе уже созданного пользователем домена либо на
основе изначально существующего. По умолчанию
ERwin

имеет четыре
предопределенных домена (
String
,
Number
,
Blob
,
). Новый до
мен
наследует все свойства родительского д
омена. Эти свойства в даль
нейшем
можно переопределить;



набрать имя домена в поле
Logical

Name
. Можно также указать имя до
-
мена на физическом уровне в поле
Physical

Name
. Если физическое имя не
указано, по умолчанию оно принимает значение логического имени
;



щелкнуть по кнопке ОК.


Рис. 14. Диалог
New

Domain


Базы данных Методическое пособие по курсовой работе


21


Каждый домен может быть описан в закладке
Definition
, снабжен ком
-
ментарием в закладке
Note

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

На физическом уровне диалог
Domain

Dictionary

Edito
r

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

На рис. 15 показана закладка
ORACLE
. Имя этой закладки зависит от
выбранного сервера БД. На ней можно задать конкретный тип данных,
соответствующих домену, правила присвоения
NULL
-

значений, правила
в
алидации (правила проверки допус
тимых значений) и задания значения по
умолчанию. Для вызова диалогов редактирования правил валидации и
значений по умолчанию служат кнопки (…) справа от соответствующего
списка выбора (
Valid

и
Default
).




Рис. 15. Диалог
Domain

Dictionary

Editor

на физическом уровне


General
.

Задание родительского домена (
Domain

Parent
) и имени, присваиваемого
колонке при ее создании с помощью
Independent

Column

Browser
. С
помощью опции
Physical

Only

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


Comment
.

Внесение комментария к атрибуту.


UDP
.

Свойства, определяемые пользователем.


Visual

Basic



PowerBuilder
.

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

Базы данных Методическое пособие по курсовой работе


22



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

удобства работы с данными.

При выборе соответствующего сервера на закладке
General

появляется
флажок:



Distinct Types

-

для

DB2/CS
и

DB2/UDB;



Domains

-

для

Rdb
и

Interbase;



User Datatypes
-

для

SQL Anywhere, SQL Server
и

SYBASE.

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


1.2.

Создание логической модели данных

1.2.1.

Выбор сервера

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

Server

(меню
Server
/
Target

Server

… доступно только на физическом уровне) (рис. 1
6
)



Рис. 1
6.

Диалог
овое окно выбора сервера (СУБД)


Базы данных Методическое пособие по курсовой работе


23


ErWin

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

1.2.2.

Таблицы, столбцы и представления

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


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

как и на логическом уровне. Щелкнув правой
клавишей мыши и выбрав во всплывающем меню пункты
Table

Editor

и
Column

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

Редактор
Table

Editor

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



Рис.
17
.
Работа со столбцами таблицы (
Column

Editor
)
.


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

Закладка
, соответствующая выбранной СУБД (в данном случае это
закладка
InterBase
). Имя закладки устанавливается автоматически
соответствующей выбранной СУБД. Позволяет задать тип данных, опци
ю
NULL
, правила валидации (набор допустимых значений, принимаемых
колонкой) и значение по умолчанию.

Comment
. Служит для внесения комментария к каждой колонке.

UPD
. Задает свойства, определяемые пользователем.

Index
. Служит для включения колонки в состав и
ндексов.

Базы данных Методическое пособие по курсовой работе


24





1.2.3.

Представления


Представление (
view
) представляет собой объект БД, данные в котором
не хранятся постоянно, как в таблице, а формируются динамически при
обращении к представлению. Представление не может существовать сома по
себе, а о
пределяется только в терминах одной или нескольких таблиц.

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

Для редактирования представлений служит диалог
View

Editor

(ри
с.
18
).
Для его вызова следует щелкнуть правой кнопкой мыши по представлению и
выбрать пункт меню
View

Editor
.



Рис.
18
.
Свойства представления (
View

Editor
)
.


Диалог
View

Editor

имеет следующие закладки:

Select
. Имеет два списка: в правом отображаются колонки
представления, в левом колонки доступные для включения в представление.
Кнопка
New

Expression

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

включает в
представл
ение все колонки родительских таблиц.

Базы данных Методическое пособие по курсовой работе


25


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

Where
. Закладка содержит три поля


Where
,
Group

By
, и
Having
. На
основе этой информации
E
RWin

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

SQL
. Закладка содержит поле, в котором отображается запрос создания
представления и окно выбора
User
-
Defined

SQL
. По умолчанию опция
User
-
Defined

SQL

выключена, и
SQL
-
запрос генерируется автоматически на
основе информации, занесенной в закладках
Select
,
From

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

В закладке
Comment

можно внести комментарий для представления.

Stored

Procedure

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

Pre

and

Post

Script

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

PowerBuilder

служит для внесения расширенных атрибутов для
генерации клиентского приложения на
PowerBuilder
.

UPD

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


1.2.4.

Создание генераторов и автоинкрементных полей

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

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

1.

Выбрать для таблиц
ы,

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

пункт меню
Pre

&
Post

Script

из меню
Table

Editor
,

активизировав
его нажатием правой кнопкой мыши.

Базы данных Методическое пособие по курсовой работе


26



Рис.
19
. Диалог
Table

Editor
.


В левом окне (
Attached

Script
) будут показаны (если они есть) имена
фрагментов кода, связанные с данной таблицей. В правом окне (
Unattached

Script
) соответственно все доступные имена фрагментов кодов.

Кнопки
Attach

и

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

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

Tenplate

и ввести новый фрагмент

кода, указав его имя используя кнопку
New

и собственно сам код в окне
Table

Script

Template
.

Пример на рис.
20

демонстрирует создание нового фрагмента кода с
именем
CREATE
_
PLACE
_
GEN
.

Базы данных Методическое пособие по курсовой работе


2
7



Рис.
20
. Создание
pre
-

и
post
-
скриптов генерации

в
ERWin
.

Радио
-
кнопки

Pre
-
Table

Creation

и
Post
-
Table

Creation

позволяют
соответственно указать
,

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

Завершающей операцией является установление связи между созданным
фрагментом кода и таблицей (осуществляется нажатием кнопки
Attach

в
диалоге
Table

Editor
).



Рис. 21.
Создание
pre
-

и
post
-
скриптов генерации в
ERWin
.
Предопределенные шаблоны.

Базы данных Методическое пособие по курсовой работе


28



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

Для создания (или изменения триггера)служит диалог
Table

Trigger

Viewer
, активизируемы
й

нажатием правой кнопкой мыши на таблицы и
выбором команды [имя СУБД]
tr
igger
.


Рис. 22.
Триггеры

Кнопка
InterBase

Table

Trigger

служит для создания и модификации
триггеров.



Рис. 23.
Триггеры таблицы

Базы данных Методическое пособие по курсовой работе


29


Создание триггера
,

так же как и создание присоединяемого фрагмента
кода
,

начинается с нажатия кнопки
New

и ввода имя вновь создаваемого
триггера, а так же указания вида триггера и времени его выполнения. В
приведенном выше примере создается триггер
Insert
_
Rec
_
Tplace
,

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


Внимание! Если триггер создается для дочер
ней таблице, то в окне
Template

Code

ERWin

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


Рис. 24.
Редактирование кода триггера.


Окно
Expanded

Code

(
Read
-
Only
) служит для просмотра
SQL
-
кода
триггера после замены
ERWin

символов подстановки.


1.2.5.

Прямое проектирование (генерация базы данных)


Для создания базы данных необходимо наличие пустой база, созданной
WISQL
,

и наличие
ODBC

источника данных, настройка которого
осуществляется вызовом диалога
ODBC

Data

Sources

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

Базы данных Методическое пособие по курсовой работе


30



Рис. 25.
Настройка источника данных


Проектирование базы в
ERWin

осуществляется выбором пункта меню
Task/Forward Engeneer/Schema Generation
и

нажатием

кнопки

Generate
.



Базы данных Методическое пособие по курсовой работе


31


2.

Разработка клиентских приложений в среде
Borland

C
++

2.1.

Работа с компонентами IBX

или
использование InterBase eXpress в приложениях на C++Builder,
с СУБД Firebird и InterBase


Закладка InterBase на палитре компонент в C++Builder

е
сть в любой
версии C++Builder (кроме бесплатного Turbo Explorer
, см рис.26
)
.



Рис. 26.
Компоненты
IBX

для баз данных
InterBase
,
Yaffil
,
FireBird
.


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


2.1.1.

Клиентская библиотека

IBX может работать только с библиотекой gds32.dll. Для работы с
Firebird необходимо при помощи входящей в комплект утилиты instclient
создать gds32.dll из fbclient.dll, т.к. компоненты ориентируются на версию
gds32.dll не ниже 6.0, а в fbclient.dll указана версия Firebird, которая ниже 6.0
(1.5, 2.0, 2.1, 2.5).

Usage:


instclient i[nstall] [
-
f[orce] ] library


q[uery] library


r[emove] library

Наиболее удобным является размещение gds32.dll рядом с вашим exe.
В
этом случае приложение загрузит именно эту библиотеку, а не какую
-
то
другую, например из System32.

Также нужно помнить, что компоненты в IDE тоже загружают gds32.dll.
Поэтому перед началом работы необходимо проверить диски на присутствие
лишних, старых или "неправильных" gds32.dll.



Базы данных Методическое пособие по курсовой работе


32


2.1.2.

Организация доступа к данным

Исключительно для
начинающих:















Рис. 27.
Взаимосвязи компонент
ов для отображение данных из БД в
клиентском приложении


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

1.

IBDatabase
. Это центральный компонент для
соединения с базой
данных. Один компонент может быть связан только с одной базой
данных в конкретный момент времени.

2.

IBTransaction
. Вне контекста транзакции в InterBase и Firebird нельз
я
выполнить никаких действий с данными и метаданными БД.

IBTransaction1
-

DefaultDatabase=IBDatabase1;

3.

датасет (
,
IB
Query
)

либо
IBSQL
.
Он
связывается с базой
данных и транзакцией

IBQuery1
-

Database=IBDatabase1;

IBQuery1
-

Transaction=IBTransaction1;

4.

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

DataSource1
-


5.

DBGrid. Он связывается только с DataSource.

DBGrid
-

DataSource:=DataSource1;

Легче всего данные связи осуществить прямо в дизайнере, в свойствах
компонент, помещая их по очереди (в указанном порядке) на форму. То

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




Базы данных Методическое пособие по курсовой работе


33



















Рис. 28.
Схема связи компонентов для организации вывода информации


Для вывода данных в грид требуется заполнить IBQuery1
-

SQL
запросом на
выборку (например, select * from employee), а затем

1.

IBDatabase1
-

Open
()
;

2.

IBTransaction1
-

StartTransaction
()
;

3.

IBQuery1
-

Open
()
;

С
войства IBDatabase, IBTransaction и т.п. необходимо
из
менять и
настраивать.

Необходимо отметить, что в InterBase и Firebird
является нормальным
:



привязка нескольких IBTransaction к одному IBDatabase. При этом
операции в разных транзакциях можно совершать по очереди без
проблем.



привязка нескольких датасетов (IBDataSet, IBQuery, IBSQL и т.п.) к
одной транзакции. С датасетами в одной транзакции также можно
работать по очереди без проблем.

TIBDatabase

Предназначен для осуществления соединения с базой данных.

Основные свойства:



Data
baseName

-

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

localhost:c:
\
dir
\
data.gdb,
server:c:
\
dir
\
data.gdb.

при ошибках локального соединения (путь к БД без имени сервера)



Params

-

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

Базы данных Методическое пособие по курсовой работе


34




















Рис. 29.
Редактор свойств

компонента
TIBDatabase


Если воспользоваться редактором свойств TIBDatabase (двойной клик на
компоненте), то упомянутые свойства будут заполнены автоматически.
Например, для базы
данных, созданной с default character set win1251
параметры будут такими:

user_name=SYSDBA

password=masterkey

lc_ctype=WIN1251

На диалоге редактора свойств есть кнопка Test, которая позволяет
проверить соединение с указанными сервером и базой данных. Если
проверка прошла нормально, то можно установить свойство Connected в
True.

Для задания свойств остальных компонент (
TIBTable
,
T
IBQuery
,
TIBDatabase
) потребуется соединение с сервером БД при помощи
вышеупомянутого Connected=True.

В параметрах TIBDatabase можно дополнительно прописывать
разнообразные параметры (конс
танты) соединения, указанные в ApiGuide.pdf
(isc_dpb_...). Обработка этих констант производится процедурой
GenerateDPB в модуле IBDatabase.pas.

Дополнительные свойства:



Connected

-

управление подсоединением к БД, или проверка состояния
соединения



DefaultT
ransaction

-

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


35


операций IBDatabase. Если это свойство не назначено явно, IBDatabas
e
создаст себе экземпляр IBTransaction самостоятельно.




-

по умолчанию 0. Определяет время, в течение которого при
отсутствии активных действий соединение с БД закроется
автоматически.



SQLDialect

-

1 или 3. По умолчанию 3. Определяет
диалект
, в котором
будет работать клиентская часть. Собственно, когда IBDatabase
подсоединяется к серверу и БД, из БД считывается номер диалекта, и
устанавливается SQLDialect. Менять не рекомендуется.



TraceFlags

-

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

или внешние приложения,
поддерживающие такую функциональность.

2.1.3.

Подсоединение к БД

Соедини
ться с базой можно
,

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


IBDatabase1
-

Params.Clear
()
;


IBDatabase1
-

LoginPrompt=False;


IBDatabase1
-

DatabaseName=

servername:c:
\
dir
\
data.gdb

;


IBDatabase1
-

Params.Add(

user_name=SYSDBA

);


IBDatabase1
-

Params.Add(

password=masterkey

);


IBDatabase1
-

Params.Add(

lc_ctype=win1251

);


IBDatabase1
-

Connected=True;


2.1.4.

Создание БД

Обычно базу данных создают в
IBConsole, IBExpert, IBDevStudio, isql

и
ли

другом

инструменте разработчика. Из приложения БД создавать обычно
не принято, т.к. в этом случае потребуется все метаданные (структуры
таблиц, триггеров и т.п.) создавать опять же в приложении, что увеличит
размер приложения. Гораздо проще вместе с приложением
поставлять
пустую или наполненн
ую частично базу данных. Однако

создать БД из
приложения
можно

сделать
следующим способом:


IBDatabase
1
-

Params
-

Clear
()
;


IBDatabase
1
-

DatabaseName
=

servername
:
c
:
\
dir
\
data
.
gdb

;


IBDatabase1
-

Params
-

Add(

user 'SYSDBA


password 'masterkey'

);


IBDatabase1
-

Params
-

Add(

page_size 4096

);


IBDatabase1
-

Params
-

Add(

default character set win1251

);


IBDatabase1
-

CreateDatabase
()
;


IBDatabase1
-

Connected
=
False;

После
этого

можно подсоединиться к БД любым способом, указанным
выше
.

Последняя строка в этом примере (Connected
=
False) нужна потому,
что в IBX после CreateDatabase база остается в открытом состоянии,
при этом

Базы данных Методическое пособие по курсовой работе


36


не задан
набор символов

подсоединения к БД, а также непол
ноценно
инициализировано соединение с БД в IBX
.

Именно поэтому после создания
БД к ней нужно снова подсоединиться нормальным способом
.


При создании БД разные версии серверов InterBase и Firebird могут по
-
разному устанавливать параметр БД Forced Writes
.

Если Forced Writes =
Off, то в случае сбоя компьютера содержимое базы данных может быть
повреждено
.

При использовании IBDatabase (IBX) в многопоточных (multithreaded)
приложениях, в том числе с web
-

или com
-
серверами, нужно соблюдать
следующие правила:

1.

соединение с БД не должно быть "локальным"
.

То есть не
c:
\
dir
\
data
.
gdb, а сетевым
-

localhost:c:
\
dir
\
data
.
gdb
.

2.

в одном thread допускается работа только с одним IBDatabase
.


o

Попытка осуществить работу с одним коннектом из разных
threads может быть успешной,

если использовать блокировки
thread при обращении к этому коннекту (на мютексах, семафорах
и т
.
п
.
)
.

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

превратится в псевдо
-
многопоточн
ую

по
причине блокирово
к между threads при работе с

од
ним
коннектом
.

Действительно
,

параллельно в разных thread могут
выполняться только операции над разными коннектами
(IBDatatabase)
.

o

иногда при подсоединении к БД в созданном thread может
возникнуть ошибка на вызове isc_attach_database (собственно на
функ
ции, которая и осуществляет соединение к БД при вызове
IBDatatase
-

Connected
=
True)
.

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


2.1.5.

TIBTransaction

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

Клиентская часть InterBase допускает выполнение любых действий
только в контексте транзакции
.

Поэтому если вы смогли получить доступ к
данным без явного вызова IBTransaction
-

StartTransaction
()
, то
это
значит
,
что

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

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

Для корректной работы
приложений с базой данных желательно управлять транзакциями вручную,
то есть явно вызывать методы StartTransaction, Commit и Rollback

компонента TIBTransaction
.

Основные свойства:



Active

-

управление стартом или завершением транзакции, а также
проверка состояния транзакции
;

при вызове Active
=
False транзакция
будет безусловно завершена по Rollback



DefaultDatabase

-

компонент
TIBDatabase



Params

-

параметры транзакции

Базы данных Методическое пособие по курсовой работе


37




AllowAutoStart

-

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

По умолчанию True
.





-

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



DefaultAction

-

результат автоматического завершения транзакции в
случае окончания IdleTimer
-

taRollbackretaining
.

Также именно этим способом будут
завершены все
открытые транзакции в момент вызова IBDatabase
-

Close
()

(Connected
=
False)
.

Умолчательное значение зависит от версии компонент, и может быть
как taRollback
,

так и taCommit
.




AutoStopAction

-

свойство, аналогичное DefaultAction по значениям
(плюс saNone, по умолчанию), указывает на метод завершения
транзакции, когда все DataSet
-
ы, подключенные к ней, закрываются
.












Рис. 30.
Параметры транзакции


В параметрах транзакции (картинка
слева, вызывается по двойному
клику на компоненте, или при нажатии кнопки в свойстве Params)
указываются константы, соответствующие IB API (без префикса isc_tpb_)
.

Если параметры не указаны (пусто), то IBX использует
параметры
транзакции по умолчанию
, которые соответствуют уровню изолированности
snapshot+wait+write (FIBPlus, в отличие от IBX, при пустых параметрах
самостоятельно прописывает параметры"read write read
_committed no wait",
т
.
е
.

с другим уровнем изолированности и режимом ожидания)
.

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

Это является
самой известной проблемой

для начинающих разработчиков, когда
"приложение видит изменения только после перезапуска" (и именно поэтому
разработчики FIBPlus при обнаружении незаданных параметров у
pFIBTransaction меняют уровень изолированности на read_committed)
.

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

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

-
перечитывания данных)
.

Базы данных Методическое пособие по курсовой работе


38


В приложении можно
использовать сколько угодно компонентов
TIBTransaction
.

Худшими случаями являются как один компонент на все
приложение
,

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

Необходимо

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

приложения
.

В коде не рекомендуется для старта или завершения транзакции
использовать property Active
-

явный вызов методов StartTransaction
()
,
Commit
()

и Rollback
()

отлично
само

документирует приложение, может быть
найден поиском, и кроме того, Active
=
False завершит транзакцию
безусловным вызовом Rollback
.


Для работы в режиме "только чтение"

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

раздельными транзакциями для чтения и записи) в FB 1
.
X

и IB 7
.
X

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

read

read_committed

rec_version

Такая
транзакция в InterBase 6
.
0 и выше (все версии IB 7
.
0, 7
.
1, 7
.
5,
Firebird и Yaffil) может быть открытой сколь угодно долгое время (дни,
недели, месяцы), без блокирования других транзакций или влияния на
накопление мусора в базе данных

(потому что на самом деле н
а сервере такая
транзакция
стартует как committed
)
.

Однако, такая транзакция
(read_committed) во время перечитывания данных будет видеть все новые
committed
-
изменения, и для отчетов

ее испол
ьзовать нельзя
.


2.1.6.

Датасеты

Работать с данными в IBX можно при помощи компонент
,
IBQuery
,
IBTable
,
IBStoredProc
,
IBSQL
, но IBSQL не является датасетом
, а
IBStoredProc хоть и является датасетом, получать из него выборки
невозможно (см
.

далее)
.

TIBDataSet, TIBQuery, IBTable, TIBStoredProc унаследованы от
.



2.1.7.


Основной компонент, пришедший из FreeIBComponents
.

Остальные, то
есть
IBTable
,
IBQuery

(+
IBUpdateSQL
)
-

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

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

Назначение компонента
-

буферизация записей, выбираемых оператором
SELECT, для представления этих данных в Grid, а также для обеспечения
"редактируемости" записи (текущей в буфере (гриде)) путем автоматического
или ручного задания запросов Insert, Delete и Update
.

Д
ля выполнения отдельных запросов
insert
,
update
,
delete
,
execute

procedure

и операторов
DDL

вместо
IBDataSet

следует использовать
IBQuery

или
IBSQL
.


Базы данных Методическое пособие по курсовой работе


39


Основные свойства:



BufferChunks

-

размер буфера (число записей), аллокируемого
IBDataS
-
ом за 1 раз
.




Database

-

связь с компонентом
IBDatabase



DataSource

-

ссылка на Master
-
источник данных (TDataSource) для
IBDataSet, используемого в качестве Detail
.



ForcedRefresh

-

при False перечитывание данных (текущей записи)
производится только при явном вызове Refresh
.

При True
-

происходит
автоматически при Post
.

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

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

и открыть датасет, то есть повторно выполнить запрос,
хранимый в свойстве SelectSQL (дальше)
.



GeneratorField

-

по нажатию на кнопке


выводится диалог для
конфигурирования "автоинкремента"
-

какому столбцу, какой
генератор, с каким шагом, и по какому дейс
твию (onNewRecord, onPost,
onServer)
.

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



ParamCheck

-

проверять или нет наличие в запросе параметров
(:param)
.

По умолчанию True
.

Для выполнения операторов DDL (create
procedure, alter, drop и т
.
п
.
) нужно выставить в False
.



Transaction

-

к какой транзакции привязан компонент
.



UniDirectonal

-

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

При True
размер буфера ограничен, просмотр записей "вверх" на определенном
этапе будет невоз
можен
.



UpdateObject

-

свойство для подключения IBUpdateSQL, не нужно
.



Запросы:

o

SelectSQL

-

основной запрос, который возвращает данные
.

o

RefreshSQL

-

запрос
для обновления текущей строки
.

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

o

InsertSQL

-

запрос для вставки записи

o

UpdateSQL

-

запрос для обновления записи

o


-

запрос для удаления записи

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

1.

Соединить его с нужным IBDatabase, и с IBTransaction (если это не тот
IBTransaction, который указан для IBDatabase
-

DefaultTransaction)
.

2.

Определить запрос, выбирающий данные
.

В этот момент
подсоединенные IBDatabase и IBTransaction должны быть активны
.

Запрос можно указать

o

щелкнув на кнопку


свойства SelectSQL

o

нажав на компоненте правую кнопку, выбрать в меню Edit SQL

Базы данных Методическое пособие по курсовой работе


40


















Рис. 31.
. Определение запроса.


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

после Active
=
True
компонент выберет данные (которые будут видны, если к IBDataSet уже
подсоединены TDataSource и TDBGrid)
.

Иначе можно задать за
просы
Insert/Update/Delete/Refresh
.


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

Нажмите на IBDataSet
правую кнопку, выберите DataSet Editor
.

Появится диалоговое окно

(рис.31)
.

Базовая

информация (имя таблицы, столбцы), уже получена из Select SQL
.

В
диалоге нужно указать столбцы первичного ключа (key fields) и обновляемые
столбцы (update fields)
.

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

Теперь можно нажать
Generate SQL
.

Появится диалоговое окно с переключателями 4
-
х запросов,
сгенерированными автоматически
.

RefreshSQL

-

как было сказано выше, для считывания (перечитывания)
одной записи (текущей в гриде, например)
.

InsertSQL

-

для вставки записи
.

Если столбцы первичного ключа не
указаны в Update Fields, то они не попадут и в сгенерированный оператор
SQL
.

То есть

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

Базы данных Методическое пособие по курсовой работе


41



-

для удаления текущей записи
.

Условия отбора в where
должны совпадать с
RefreshSQL
.



















Рис. 32.
Окно
SQL


UpdateSQL

-

для обновления текущей записи
.

Если столбцы первичного
ключа не исключены из Update Fields, то они будут упомянуты в update set
field =:field, и соответственно могут обновляться
.

Изменение значений
столбцов первичных ключей
-

плохая

операция,

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

У IBDataSet есть специальные параметры, которые могут быть
использованы в запросах
.

Параметры именуются автоматически, и
соответствуют именам столбцов, предваряемые префиксами old_ и new
_.

Например
-

old_client_name, new_client_name
.

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

те, которые
ввел польз
ователь при редактировании
.

Пример
.
Пусть имеется
таблица


create table X(


id int not null,


name varchar(30),

constraint PK_X primary key (id))


Тогда

SelectSQL = select * from X

InsertSQL = insert into X (id, name) values (:ID, :NAME)

ModifySQL = update


Базы данных Методическое пособие по курсовой работе


42



RefreshSQL = Select ID, NAME from X where ID = :ID

Обратите внимание, что автоматически генерируемый UpdateSQL
проверяет только соответствие первичного ключа (where field = :o
ld_field)
.

То
есть

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

Это поведение отличается от умолчательного поведения
компонент
BDE TTable и TQuery
.

У них было свойство UpdateMode, которое
отвечало за проверки модификации записи
.

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

Другими словами,

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



upWhereAll

(по умолчанию
)
-

проверка на существование записи по
первичному ключу + проверка всех столбцов на старые значения
.

например

update table set


where pkfield = :old_ pkfield and client_name =
:old_client_name and info = :old_info

В

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

Особенно это важно, если существуют
взаимозависимости между значениями столбцов
-

например,
минимальная и максимальная зарплата, и т
.
п
.




upWhereChanged

-

проверка записи на суще
ствование по первичному
ключу + плюс проверка на старые значения только изменяемых
столбцов
.

update table set


where pkfield = :old_pkfield and client_name =
:old_client

В этом случае мы меняем имя клиента со старого на новое
.

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




upWhereKeyOnly

-

проверка записи на существование по первичному
ключу
.


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

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

И, разумеется, также необходимо при реализации аналога
upWhereChanged удалять лишние изменения столбцов в update table set
-

т.е.

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

Это

означает необходимость динамического конструирования запроса
UpdateSQL
.

Если вы не хотите это делать и используете ClientDataSet, то
вполне можно о
бойтись корректными настройками DataSetProvider (свойства
ResolveDataSet и Options)
.

Базы данных Методическое пособие по курсовой работе


43


Вместо запросов в InsertSQL/UpdateSQL/DeleteSQL (
допускается
заполнять

не все, а

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

Это позволяет "редактировать"
запросы, которые представляют собой объединения нескольких таблиц,
агрегаты (группировки) и т
.
п
.

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

В

коде приложения для открытия и закрытия IBDataSet рекомендуется
вызывать его методы Open/Close, а не управлять свойством Active

(
Open/Close лучше читаются и не допускают неоднозначностей
,

например
IBDataSet
-

Active
=
MyVar)
.


Описание методов ExecQuery, Pre
pare аналогично IBQuery
.

2.1.8.

Буферизация записей

Открытие запроса, возвращающего набор записей (Active
=
True или
вызов Open), приводит всего лишь к выполнению запроса, но не к выборке
записей
.

Выборка записей начинается только тогда, когда происходит вызов
методов Next
()
, Last
()

или FetchAll
()

(Locate
()

рассмотрен дальше, отдельно)
.

Соответственно, свойство RecordCount показывает только число выбранных
в буфер (с сервера) записей
.

IBCustomDataset и его наследники после Open
()

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

Если DataSet подключен к DBGrid, то DBGrid, показывая записи,
автоматически вызовет DataSet
-

Next
()

столько раз, сколько поместилось
за
писей на экран
.

При дальнейшем продвижении в DBGrid будут
считываться остальные записи
.

По достижении конца выборки (последней
записи) сервер сообщает клиентской части
,

что записи кончились, после чего
все выбранные записи находятся в буфере DataSet, и люб
ое продвижение по
записям вверх или вниз (Next
()
, Prev
()
) приводит только к перемещению
указателя внутри буфера DataSet (без обращения к серверу)
.

Если запрос не вернул ни одной записи, то оба свойства
-

BOF и EOF
,

-

будут равны True
.

Если результат
запроса обрабатывается по одной записи

по мере их
получения с сервера

и далее обработанные записи ни для чего не нужны,
вместо кэширующих датасетов IBTable, IBDataSet и IBQuery следует
использовать
IBSQL

-

он не кэширует записи
.


2.1.9.

Обновление данных

У тех, кто
освоил

механизм
ы

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

описание
IBTransaction
)
.

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

У
видеть новые (committed) данные можно только
выполнив запрос
снова
.

Для этого нужно закрыть и открыть
IBDataSet

(или
IBQuery
/
IBSQL
)
.

Переоткрытие (Close/Open) датасета приведет к уничтожению старого
буфера записей, перевыполнению запроса, и считыванию записей в буфер
.

Базы данных Методическое пособие по курсовой работе


44


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

выполненные другими
приложениями (или в других транзакциях) опять будут "не видны"
.


2.1.10.

Перебор записей

Для обработки всех записей, возвращаемых запросом, можно
использовать цикл:

IBDataSet
-

Open
()
;

while
(!
IBDataSet
-

EOF
)

{



-

Next
()
;

}

Аналогичный код будет работать и для IBTable, IBQuery
.

Если перебор записей делается только с целью их однократной
обработки, или экспорта, то вместо указанных компонент следует
использовать
IB
SQL
, который не кэширует записи
.

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


2.1.11.

Master
-

Пример
:

1.

кладем IBDatabase, IBTransaction, соединяем их

2.

кладем

2 IBDataSet (IBQuery)
и

2 TDataSource
.

Соединяем

IBDataSet
с

IBDataBase, IBTransaction
и

DataSource

3.

В базе есть 2 таблицы
-

клиенты и заказы
.

Клиенты
-

master, заказы


.

4.

IBDataSet1 + DataSource1 называем MDS и MasterSrc соответственно
.

Прописываем у MDS в SelectSQL запрос

select * from clients

5.

IBDataSet2 + DataSource2 называем DDS и DetailSrc соответственно
.

Прописываем

у

DDS
в

SelectSQL
запрос


select * from orders where client_id = :cid
.


Здесь имя параметра :cid должно совпадать с и
менем столбца
первичного ключа в таблице clients
.

В данном примере этот столбец и
называется CID
.

6.

у DDS указываем свойство DataSource = MasterSrc
.


7.

Активируем IBDatabase, IBTransaction, затем сначала MDS, затем DDS
(можно еще проверить на форме, нажав прав
ую кнопку и в меню
CreationOrder, что компоненты создаются и активируются
(открываются) в правильном порядке, и MDS+MasterSrc создаются
раньше чем DDS+DetailSrc)
.

8.

Подсоединяем

2 DBGrid,
к

MasterSrc
и


9.

Запускаем приложение
.

При перемещен
ие по гриду

master
показываются с
оответствующие записи таблицы detail

Н
е пыта
йтесь

генерировать идентификатор мастера в триггере
.

Иначе неоткуда будет взять

идентификатор мастера для вставки в
таблицу detail
.

И
дентификатор надо сначала получить (например,
Базы данных Методическое пособие по курсовой работе


45


установкой свойства GeneratorField у
IBDataSet

или
IBQuery
), использовать
для вставки запись в master
-
таблицу, а затем в таб
лице detail этот
идентификатор "возьмется" автоматически
.

Или он уже и так будет
известен даже при ручной вставке записи в таблицу detail
.

Кроме того, при работе с CachedUpdates (если нужен режим
CachedUpdates) необходимо тщательно следить за порядком отпр
авки
записей на сервер
-

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


.

Для этого нужно вызывать методы ApplyUpdates
()

соответствующих
компонент в правильном порядке (а не вызывать IBDatabase
-

ApplyUpdates
()
,
т
.
к
.

в этом случае

нарушается

правильный порядок)
.

2.1.12.

Locate (поиск)

В выбранных IBDataSet (IBQuery) записях можно производить поиск
,

вызывая метод Locate
().

Поскольку запрос, выбирающий записи, указан явно
в SelectSQL, компонент по очереди
будет
перебирать выбранные записи от
начала до
конца (от First до EOF, путем вызова Next
()
), и производить поиск
в буфере
.

Если IBDataSet был только что открыт, и FetchAll
()

не вызывался,
то вызов Locate
()

приведет к выборке на клиента (в локальный буфер) всех
записей, возвращаемых запросом
.

2.1.13.

IBTable

Это заменитель компонента TTable

для облегчения перехода с BDE (как
и IBQuery)
.

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

С
войства
:



TableName

-

имя таблицы
.




-

типы таблиц, отобра
жаемые в выпадающем списке
.

TableName
-

ttSystem включает выборку системных таблиц (rdb$, tmp$),
а ttView включает выборку VIEW
.



IndexName

-

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

Так же, как и в BDE, имя
индекса используется косвенно, для получения столбцов индекса, и
добавления фразы ORDER BY INDEXFIELD1, INDEXFIELD2 к
автоматически конструируемому запросу
.

Поэтому для сортировки по
любому столбцу, даже непроиндексированному, сле
дует использовать
свойство IndexFieldNames
.

Явно сортировку записей в обратном порядке (DESC) указать
невозможно
.



Filter

-

условие фильтрации
.

Текст свойства Filter добавляется как
условие where к автоматически конструируемому запросу
.


Поскольку свойство
ReadOnly по умолчанию False, IBTable сразу готов к
редактированию данных
.

Т.к.

запрос на чтение формируется из одной
таблицы, то запросы insert/update/delete могут быть легко сформированы
автоматически
.

Сортировка записей по умолчанию (order by) производит
ся
по столбцам первичного ключа (primary key)
.

Базы данных Методическое пособие по курсовой работе


46


2.1.14.

Locate

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

для IBQuery
.

Условия поиска раскладываются в соответствующую конструкцию where,
после чего выполняется запрос
.

Если такие записи найдены, то поиск
производится вызовом

-

Locate
()

(
аналогично

.


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

Компонент
IBTable
не
рекомендуют

использовать. И
спользование
IBTable не
рекомендуют и считают "ламерским"
.

Дело в том, что
,

как уже было сказано
выше, IBTable формирует SQL
-
запросы к БД самостоятельно
.

А это при
работе с SQL
-
серверами считается некорректным
.

Т
.
е
.

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

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

Н
егативное отношение к IBTable базируется на аналогич
ном
отношении к его "родителю", компоненту
TTable
, который мог приводить к
серьезным проблемам с производительностью приложений
.

TTable предназначен для имитации "навигационного" доступа, к
которому
привыкли пользователи десктопных СУБД, и плох для SQL
-
сервера
.

IBTab
le наследует его характеристики

и предназначен для
облегчения переноса приложений BDE на компоненты IBX
.

Тем не менее

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


И
значально в компонентах FreeIBDatabase
не было
IBTable
.

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

IBDataSet
.

И
уже от него произошли и IBQuery, и IBTa
ble
.


2.1.15.

IBQuery

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

Если не требуется выполнять
"редактирование" записей запроса, то IBQuery можно использовать вместо
IBDataSet
.

К
ак замену IBDataSet можно использовать комбинацию IBQuery +
IBUpdateSQL
.

Дополнительно к свойствам IBDataSet (кроме отсутствующих
Refresh/Insert/Update/DeleteSQL) имеет свойство
Constrain
ts

(отсутствие
данного свойства у IBDataSet связано с недоделками, т
.
к
.

компоненты
IBTable, IBQuery и IBDataSet
-

унаследованы от IBCustomDataSet)
.

Для запросов, возвращающих набор записей, можно установить
свойство Active в True или вызвать метод Open
()
.

Для остальных запросов,
таких как insert/update/delete, execute или операторов DDL (create table, alter,
drop


) нужно вызывать метод ExecQuery
()
, т
.
к
.

эти запросы не возвращают
записи, а возвращают только результат выполнения оператора SQL
.



IBQuery при выполнении запросов SELECT буферизирует записи точно
так же, как и IBDataSet
.

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


47


экспортировать их в файл или другую СУБД
, нужно
использ
овать

небуферизирующий компонент
IBSQL
.

Д
ля выполнения процедур, возвращающих данные (execute procedure)
,

следует использовать
IBSQL

или
IBStoredProc
, т
.
к
.

вызов IBQuery
-

ExecSQL
()

не заполняет Fields данными, полученными от процедуры
.


2.1.16.

Параметризированные запросы

Компоненты IBDataSet, IBQuery и IBSQL могут выполнять как
статический, так и динамический SQL
.

Динамический SQL отличается от
статического наличием параметров
.


Пример статического SQL:

select * from table


where field� 5

Если вместо цифры 5 предполагается использовать значение,
полученное как ввод данных пользователем, то следует использовать
параметризированный запрос (ParamCheck
=
True):

select * from table


where field� :param

Двоеточие или символ '?' означают, что запрос предполагает задание
параметра
.

Делается это следующим образом:

IBQuery
-

SQL
-

Clear
()
; // очистить текст sql

IBQuery
-

SQL
-

Add(
«
select * from table where field � :param
»
); //
задать

текст

запроса

IBQuery
-

Prepare
()
; // отправить запрос на сервер, проверить его
корректность и т
.
п
.

IBQuery
-

ParamByName(

param

)
-

A
sInteger
=
5; //
задать

значение

параметра

IBQuery
-

Open
()
; //
или

IBQuery
-

ExecSQL
()

Для статических запросов вызов Prepare необязателен
-

компонент сам
его выполнит автоматически, если Prepare не был вызван
.

После
Prepare можно обратиться к свойству Plan, т
.
к
.

именно после
Prepare сервер сообщает план выполнения запроса
.

Prepare
()

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

с разными значениями параметра
.

При этом Prepare
()

вызывается
один раз, а установка параметров и вызов ExecQuery
()

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

Чаще всего такой способ используется для запросов
Insert и Update
.

И
мена параметров поддерживаются только клиентской библиотекой
;

сервер понимает параметры только в виде символа '?'
.

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

select * from table


where field� ?

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

Базы данных Методическое пособие по курсовой работе


48


2.1.17.

Фильтрация

В

BDE или ином используемом до IBX наборе компонент доступа к БД
активно применял
ась

фильтраци
я

записей
.

Ф
ильтрация в IBX работает
практически так же, как и в BDE
.

IBTable

Для этого компонента в свойстве Filter должны быть описаны условия
фильтрации так, как будто добавляет
ся
условие where к обычному запросу
SQL
.

IBTable сконструирует запрос, используя заданное в TableName имя
таблицы, добавит как where условие фильтрации из Filter, и добавит
конструкцию ORDER BY
,

если указана "сортировка" результирующего
набора при помощи свойств IndexFieldNames или IndexName
.
По
этому, в
Filter должен быть указан текст с учетом всех особенностей синтаксиса
InterBase или Firelbird
.


Пример:

LasName like 'A%'

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

select id, LastName, FirstName



from TABLE

where LastName like 'A%'

,
IBQuery

Эти компоненты выполняют запросы, четко заданные в свойствах
SelectSQL или
SQL
.

Поэтому дополнительная фильтрация возможна только
методом OnFilterRecord
.


OnFilterRecord

Компоненты IBTable, IBDataSet и IBQuery позволяют использовать это
событие для фильтрации записей
.

В отличие от IBTable, где в свойстве Filter
можно указать допо
лнительное условие отбора для запроса, выполняемого на
сервере, OnFilterRecord определяет "видимость" записи, уже принятой
DataSet
-
ом с сервера
.

Метод имеет два параметра
-

DataSet, то есть что за
компонент запросил фильтрацию (для возможности получения да
нных из
"текущей" записи), и Accept, который определяет, показывать данную запись
подключенному компоненту DataSource или нет
.

Для того, чтобы
имитировать фильтрацию, показанную выше на примере для IBTable, в
OnFilterRecord нужно написать примерно следующе
е:

Accept
=
(DataSet
-

FieldByName(

LastName

)
-

A
sString� =


A

) and


-

FieldByName(”
LastName

)
-

A
sString

B

);

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

То есть
если в программе предполагается небольшое
число
вариантов фильтрации, то имеет смысл уменьшить нагрузку на клиентскую
часть и при изменении фильтра конструировать запрос для SelectSQL с
нужным условием where (точно так же как это делает IBTable, только строк
а

where добавля
ется

к тексту запроса)
.

Базы данных Методическое пособие по курсовой работе


49


2.1.18.

I
BUpdateSQL

К
омбинация IBQuery + IBUpdateSQL представляет собой аналог
IBDataSet
.

Для работы такой связки не требуется включение режима
CachedUpdates, как это требовалось в
BDE
.



2.1.19.

IBSQL

Компонент, являющий
ся минимальной надстройкой над InterBase API
.

В
отличие от
IBTable
,
IBQuery

и
,

он не буферизирует выбираемые
записи
-

для доступа к текущей записи существует только свойство Current
(IBSQL не является наследником DataSet)
.

Работа с параметрами и столбцами
нес
колько отличается от обычной, т
.
к
.

они являются TIBXSQLVAR, то есть
прямыми ссылками на структуры InterBase API
.

У IBSQL есть свойство GoToFirstRecordOnExecute
-

если True (по
умолчанию), то в случае select компонент запросит у сервера первую запись
и
заполнит ее данными Current
.

Если False
-

Current будет пустым,
то

для
считывания данных с сервера необходимо выполнить IBSQL
-

Next
().


Предназначен для выполнения операторов Insert/update/delete, execute
procedure, или select для небуферизированного
перебора записей (например
,

при импорте/экспорте данных или при массовой обработке записей на
клиенте)
.

Пример
:


IBSQL1
-

SQL
-

Clear
()
;


IBSQL1
-

SQL
-

Add(

select * from table

);


IBSQL1
-

ExecQuery
()
;


while

(!
IBSQL
1
-

Eof
)

{


// получение данных столбца в переменную



=
IBSQL1
-

FieldByName(“
fieldname

)
-

As…
;


IBSQL1
-

Next
()
;

}




2.1.20.

IBStoredProc

Компонент для выполнения хранимых процедур
.

В
ыполнять процедуры
можно
при
выз
ове

EXECUTE PROCEDURE в компонентах
IBQuery

и
IBSQL
.

Унаследован от IBCustomDataSet, но DataSet
-
ом не является
.

Поэтому для
выборки из селективных процедур (select *
from proc) следует использовать
обычные
IBDataSet
, IBQuery, IBSQL (IBStoredProc не умеет работать как
DataSet по простой причине
-

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

procedure)
.

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

имеет
проблему с обработкой ошибок
.

П
роблема с обработкой ошибок относится к вызовам execute procedure
во всех компонентах IBX
-

IBStor




Базы данных Методическое пособие по курсовой работе


50


2.1.21.

EIBError

Базовый класс ошибок IBX
.

Имеет свойства (кроме унаследованных от
EDatabaseError):



SQLCode

-

номер ошибки (статус вектора) при выполнении
операторов SQL



IBErrorCode

-

целое число, идентифицирующее ошибку
.

Описание всех ошибок сервера находится в LangRef
.
pdf

На

основе EIBError в IBX существует несколько дополнительных
классов
:



EIBInterBaseError
-

общая ошибка сервера



EIBInterBaseRoleError
-

ошибки при использовании ROLE



EIBClientError
-

ошибки, специфичны
е для клиентской части (gds32
.
dll,
fbclient
.
dll)
.

В основном для указания на несовместимости конкретной
клиентской части
.




EIBPlanError
-

ошибка получения плана запроса

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

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

2.1.22.

IBDatabaseInfo

Компонент для получения информации о параметрах БД и статистике
вы
полнения запросов
.

Подсоединяется к
IBDatabase
, информацию
возвращает только посредством runtime
-
свойств
.

Наиболее часто
используемые свойства



UserNames

-

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

Для Classic возвращает только текущего
пользователя
.



Reads
,
Writes
,
Fetches

-

информация о числе чтений, записи и
обращений к страницам БД
.

Аналог информации, выводимой IBExpert
и др
.

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



PageSize
,
ODSxxx
,
NumBuffers
,
SweepInterval

-

информация о
свойствах БД



ReadSeqCount
,
UpdateCount
,
InsertCount

-

счетчики
соответствующих операций, выводятся для всех таблиц
.

В предыдущих
версиях IBX представляли с
обой integer, что неверно (выводился мусор
вместо правильной информации)
.

Аналог информации, выводимой в
закладке Performance Info IBExpert
.

2.1.23.

IBSQLMonitor

Компонент для мониторинга действий клиентского приложения
(вызовов IB API)
.

Для мониторинга необходимо в событии OnSQL сохранять
EventText и EventTime либо в файле, либо в компоненте TMemo на какой
-
либо форме (например
Memo
-

Lines
-

Add(EventText)
)
.

Возможен
мониторинг (свойство TraceFlags):



tfQPrepare
-

вызов Prepare запроса

Базы данных Методическое пособие по курсовой работе


51




tfQExecute
-

вызов Execute запроса
.

Выдается текст запроса, хотя в этот
момент он на сервер не передается (был уже передан при Prepare)



-

выборка записей



tfError
-

ошибки, возникающие на сервере



tfStmt
-

операции с запросами (аллокирование,
закрытие, и т
.
п
.
)



tfConnect
-

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



tfTransact
-

операции

с

транзакциями

-

Start, Commit, Rollback,



tfBlob
-

операции с blob (чтение, запись)



tfService
-

вызовы Services API



tfMisc
-

о
стальное

Для активации монитора нужно у соответствующего компонента IBDatabase
также выставить опцию TraceFlags
.

В
старых

версиях IBX были проблемы с мониторингом (зави
сало
приложение) в том случае, когда
компонент IBSQLMonitor использовался в
приложениях,

работающих как сервис
.

2.1.24.

IBExtract

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


Основные свойства:



IncludeSetTerm
-

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

Необходимо (true) для последующего выполнения скрипта в isql,
IBExpert и др
.



ShowSystem
-

выводить в скрипт ddl системных таблиц (rdb$


)



DatabaseInfo (runtime)
-

локальный экземпляр
IBDatabaseInfo



Items
-

результирующий скрипт с метаданными



Database
-

связь с компонентом
IBDatabase



Transaction
-

связь с компонентом
IBTransaction

Пример:

Извлечь полный скрипт


IBExtract1
-

ExtractObject(eoDatabase);


IBExtract1
-

Items
-


d:
\
a
.
ddl

);

Извлечь

только

скрипт

таблиц
:


IBExtract1
-

ExtractObject(eoTable);


IBExtract1
-

Items
-

“d:
\
a.ddl”
);

Извлечь

данные

для

таблицы

Customer


IBExtract1
-

ExtractObject(eoData,

CUSTOMER

);


IBExtract1
-

Items
-

“d:
\
a.ddl”
);

Извлечь

скрипт

таблицы

EMPLOYEE


IBExtract1
-

ExtractObject(eoTable,

EMPLOYEE

);


IBExtract1
-

Items
-

“d:
\
a.ddl”
);

Извлечь скрипт таблицы EMPLOYEE плюс все ее индексы, триггеры,
домены, гранты, check и данные

IBExtract1
-

ExtractObject(eoTable,

EMPLOYEE

,

Базы данных Методическое пособие по курсовой работе


52





IBExtract1
-

Items
-

“d:
\
a.ddl”
);

Извлечь

скрипт

процедуры

SHIP_ORDER


IBExtract1
-

ExtractObject(eoProcedure,

SHIP_ORDER

);


IBExtract1
-

Items
-

“d:
\
a.ddl”
);

Извлечь

скрипт

(create
и

alter)
процедуры

SHIP_ORDER


IBExtract1
-

ExtractObject(eoProcedure,

SHIP_ORDER

);


IBExtract1
-

Items
-

“d:
\
a.ddl”
);

2.1.25.

IBScript

Компонент для выполнения скриптов (набора команд в текстовом файле)
.

Основные
свойства:



AutoDDL
-

автоматически вызывать Commit после выполнения DDL
-
операторов



-

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

Рекомендуется
IBQuery
.



Database
-

база данных, над

которой нужно выполнить скрипт
(
IBDatabase
)



Transaction
-

транзакция, в которой будет выполняться скрипт
(
IBTransac
tion
)



Terminator
-

разделитель SQL
-
операторов в скрипте



Script
-

текст скрипта (TStrings, соответственно можно вызывать
LoadFromFile и т
.
п
.
)



Statistics
-

статистика выполнения скрипта



Paused (runtime, read/write)
-

индикатор состояния выполнения скрипта



Validating (runtime, readonly)
-

индикатор выполнения проверки скрипта
(только prepare)



CurrentTokens (runtime)
-

набор токенов выполняемого SQL
-
оператора

События:



OnExecuteError
-

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



OnParse
-

при успешном выполнении очередного оператора скрипта
позволяет узнать тип оператора (TIBParseKind) и его те
кст
.



OnParseError
-

при ошибке парсинга оператора позволяет вывести
оператор, ошибку и номер строки в скрипте
.




OnParamCheck
-

если у конкретного оператора есть параметры, и это не
DDL, то позволяет задать параметры оператора SQL перед его
выполнением (Par
ams и ParamByName)
.

Методы:



ValidateScript
-

выполнять только prepare всех операторов скрипта,
чтобы убедиться, что они могут быть выполнены (синтаксически корректны
)
.



ExecuteScript
-

выполнить скрипт

Базы данных Методическое пособие по курсовой работе


53


2.1.26.

IBDatabaseINI

Компонент для записи и считывания настроек
IBDatabase

в ini
-
файле
.


Пример:

Сохранение информации
:


IBDatabaseINI
1
-

ReadFromDatabase
()
;


IBDatabaseINI
1
-

()
;

Считывание
информации
:


IBDatabaseINI1
-

ReadFromIni
()
;


IBDatabaseINI1
-


Информация хранится в файле, указанном в свойстве FileName, в виде


database=localhost:D:
\
Firebird
\
examples
\
employee
.
fdb

user_name=SYSDBA

password=masterke
y

sql_role=

lc_ctype=win1251

2.2.

Компоненты

Services API (InterBase Admin)






















Рис.

33. Ф
орма примера Admin в DesignTime.


Этот набор компонент находится на отдельной закладке, и показывается
в палитре компонент только в том случае, если на компьютере в path
Базы данных Методическое пособие по курсовой работе


54


присутствует gds32
.
dll от InterBase 6
.
0 и выше или совместимая (для Firebird
обязательно указание установки совместимой
gds32
.
dll в инсталляторе, или
ручная установка gds32
.
dll из fbclient
.
dll при помощи утилиты instclient
.
exe)
.

Компоненты используют Services API, введенный в InterBase 6
.
0 для
backup/restore, проверки БД и других операций
.

Пример использования этих
компонен
т есть в поставке и называется Admin
.

Services API как таковое
должно поддерживаться сервером, и поддерживается во всех версиях
архитектуры SuperServer, начиная с InterBase 6
.

Для Classic полноценно
Services API поддерживается либо в Yaffil, либо в Firebir
d начиная с версии
1
.
5
.
2
.

Примечание
: Services API в данном случае
-

набор сервисных функций
СУБД Firebird или InterBase
, а не
сервис
ы

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

У всех компонент Services API подключение к серверу и БД
производится двумя свойствами
-

ServerName

и DatabaseName
.

В отличие от
TIBDatabase в свойстве DatabaseName должен быть указан только локальный
путь к БД (без имени сервера), а в ServerName
-

только имя сервера
.

Например
:

IBS
-

DatabaseName
=

c:
\
dir
\
data
.
gdb

;

IBS
-

ServerName
=

server

;


Если

в

DatabaseName
указать

и

имя

сервера

(“
server:c:
\
dir
\
data
.
gdb

),
компонент

будет

выдавать

ошибку

'Error reading data from the connection'
.


Все компоненты Services API предназначены для выполнения сервером
определенных команд
.

Сами компоненты (за исключением TIBInstall,
TIBUninstall) никаких действий (кроме передачи команд серверу и получения
результата) не производят
.

У всех компонент (за исключением TIBInstall, TIBUninstall) имя
пользователя и пароль задаются в свойстве Param
s
.

Например
:


IBBackupService1
-

Params
-

Add(

user_name=SYSDBA

);


IBBackupService1
-

Params
-

Add(

password=masterkey

);

TIBConfigService

-

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

TIBBackupService

-

передает серверу команду на выполнение
резервного копирования базы данных, аналог
gbak
-
b с опцией
-
se
.

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

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

LocalSystem не имеет и не может
получить никаких прав на доступ к сетевым ресурсам)
;
этому пользователю
да
ются

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

TIBRestoreService

-

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

c с опцией
-
se
.


Базы данных Методическое пособие по курсовой работе


55


TIBValidationService

-

аналог gfix, осуществляет проверку БД и/или
ремонт повреждений в БД, если
они

есть
.


TIBStatist
icalService

-

аналог gstat, получает статистику из базы данных
.

TIBLogService

-

позволяет получить содержимое interbase
.
log с сервера
.

TIBSecurityService

-

управляет пользователями в isc4
.
gdb, admin
.
ib или
security
.
fdb (посредством сервера
)
.

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

TIBServerProperties

-

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

конфигурационны
х

параметр
ах
.

TIBLi
censingService

-

работает только с платными версиями InterBase
.

Позволяет управлять пользовательскими и процессорными лицензиями на
сервере (также серверными для 7
.
0
.

В 7
.
1 и 7
.
5 серверные и unlimited users
лицензии регистрируются только через инсталлятор)
.

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


TIBInstall
,
TIBUninstall

-

компоненты, обеспечивающие установку,
регистрацию и деинсталляцию InterBase в системе
.

2.3.

Использование и управление IBTransaction в
приложениях

Существование
IBTransaction

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

В

BDE

практически никакого
управления транзациями не

было

(одна транзакция на коннект
.

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

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

Если же управлять транзакциями явно, то можно создать
эффективную систему
.

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

П
ри отсутствии контроля над транзакциями
невозможно

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

В
InterBase 7
.
5 и выше или Firebird 2
.
1 и выше
можно

выяснить (при
помощи временных системных таблиц tmp$ или mon$ соответственно),
какие

транзакци
и

активн
ы

длительное время
, и сколько их вообще существует
.

Возможно также

принудительно завершить
транзакции
,

но нельзя их

исправить
.


IBX (как и FIBPlus)
позволяет полноценно управлять транзакциями

с
помощью применения следующих

правил:

Обращать внимание

на defaultTransaction
,
отказавшись от
неявн
ого

старт
а

транзакций или их автоматическо
го

завершени
я
.

В

коде
должно быть

Базы данных Методическое пособие по курсовой работе


56


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

Commit/Rollback в другом модуле относительно StartTransaction)
.

Не рекомендуется стартовать или завершать транзакции
обращением к свойству IBTransaction
-

Active


дизайн
-
тайме

при

клика
нии

на свой
ство active в Object Inspector).
Е
сли транзакция в
IBTransaction уже активна, то при вызове IBTransaction
-

Active
=
False;
транзакция безусловно завершится по Rollback
.

Поэтому


для улучшения
читаемости кода
)

свойство Active рекомендуется использовать только для
проверки состояния компоне
нта (для эт
ого есть свойство inTransaction
)
.

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

Примечание
: в FIBlus свойство TimeoutAction (аналогичное
DefaultAction в IBX) равно taRollback
.

Это нужно учитывать, особенно если
планирует
ся

заменить IBX на FIBPlus
.

Е
сли при закрытии IBDatabase к нему
"прицеплены" активные транзакции, то они завершаются по
TimeoutAction/DefaultAction, а не как Active
=
False
.

Соответственно, при
таком завершении (I
BDatabase
-

Close, IBTransaction
-

Free) приложения в
IBX изменения, произведенные в незакрытых к этому моменту транзакциях
,

сохранятся, а в FIBPlus


исчезнут
.

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

Транзакция
-

это блок логической работы

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

То есть, между
StartTransaction и Commit/Rollback может быть любое число команд

SQL, но
оно должно быть осмысленным и взаимосвязанным
.

Самый типичный пример транзакций
-

перевод денег с одного счета на
другой
.

StartTransaction
()
;


update accounts set ac1 = ac1
-

100 where user_id = :x;


update accounts set ac2 = ac2 + 100 where user_id = :x;

Commit
()
;

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

прибавляет эту сумму к другому счету
.

Если бы не было транзакций,
то при сбое после выполнения 1
-
го оператора у

некоего пользователя
пропали бы 100 единиц в денежном эквиваленте
.

Или, если после первого
оператора другая программа успевает выполнить подсчет баланса (до
выполнения второго update), она бы увидела отсутствие этих 100 единиц
.

При работе с транзакциями н
и одна конкурирующая транзакция
(приложение) не увидит изменений (перевода денег с одного на другой счет),
пока "переводящая" транзакция не завершится
.

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

Если

необходимо

оформить
выписк
у

накладной в одной транзакции
, то

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


57


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

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

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

При использовании
коротких транзакций
для

"списывания" товара
(путем update таблицы товаров) при его выписке в накладной (триггером на

в том случае,

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

Следовательно, один оператор будет ждать другого, а это в
99% случаев неприемлемо
.

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


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




3.

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


Состав
каталога

(Example)
:



Distribute


каталог, содержащий приложение



Model


модель базы данных в
ErWin



Project


проект приложения (клиента БД)



Script


скрипт генерации БД и необходимых процедур





Список литературы

1.
Кириллов, В.В. Введение в реляционные
базы данных /

В.В.
Кириллов, Г.Ю.Громов


С
.
-
Пб. : БХВ
-
Петербург, 2012.


272

с.

2.
Агальцов В.П. Базы данных. Распределенные и удаленные базы
данных. Учебник. / В.П.Агальцов


М

:
Форум
, 20
09
.


464 с.




Интернет
-
ресурсы

http://www.webmaster.ee/MySQL/Chapter%201/1.htm

http://www.softtime.ru/bookphp/gl12_2.php

http://life
-
prog.ru/view_shpargalkiCompStroi.php?id=84





Базы данных Методическое пособие по курсовой работе


58



АРТАМКИН СЕРГЕЙ НИКОЛАЕВИЧ

Ст.преподаватель каф.ИТПМ

МЕТОДИЧЕСКОЕ ПОСОБИЕ

ДЛЯ
ВЫПОЛНЕНИЯ
КУРСОВОЙ РАБОТЫ

по дисциплине


БАЗЫ ДАННЫХ


«Разработка баз данных
InterBase

и
клиентских

приложений в среде
Borland

C
++
»


Направление подготовки

09.03.01

Информатика и вычислительная техника


Профиль подготовки

Системы автоматизированного проектирования в машиностроении


Квалификация (степень) выпускника

бакалавр

(бакалавр, магистр, специалист)


Форма обучения

очная

(очная, очно
-
заочная и др.)





Множительная мастерская ТИ НИЯУ МИФИ

Рек
омендовано к печати кафедрой ИТ
ПМ

Тираж
15



Приложенные файлы

  • pdf 7446588
    Размер файла: 1 MB Загрузок: 1

Добавить комментарий