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

Однако важно, чтобы только один из них внес изменения в таблицу TOVARY, поэтому в теле использованы альтернативные IF-условия.

В триггере AU_RASXOD0 используется еще одно (внутреннее) IF-условие и связанный с ним оператор SELECT.

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

В нашем случае, если в таблице «Товары» изменится значение поля KOD_TOVAR, то в дочерней таблице «Расход» будет выполнено каскадное обновление согласно объявленному ограничению ссылочной целостности. Это обновление инициирует запуск всех UPDATE-триггеров таблицы RASXOD… для каждой обновляемой её строки… Далее можно просчитать, что такой косвенный вызов не должен повлечь перерасчета количества товаров на складе в таблице «Товары»… а он произойдет и даст неправильный результат…

SELECT-оператор и последующее IF-условие позволяют проверить, имеется ли OLD.KOD_TOVAR в таблице TOVARY… отсутствовать он может только в случае косвенного вызова триггера AU_RASXOD0, инициированного тем самым каскадным обновлением. Возможно, это не самое лучшее решение проблемы, но решение…

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

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

CREATE GENERATOR TOVARY_KOD;

Инициализация генератора производится оператором

SET GENERATOR TOVARY_KOD TO 100;

Соответствующие операторы для таблиц POKUPATELI и RASXOD выглядят следующим образом:

CREATE GENERATOR POKUPATELI_KOD;

SET GENERATOR POKUPATELI_KOD TO 100;

CREATE GENERATOR RASXOD_KOD;

SET GENERATOR RASXOD_KOD TO 100;

Далее необходимо определить хранимые процедуры, изменяющие на 1 значения этих переменных.

CREATE PROCEDURE GET_KOD_TOVAR

BEGIN NR=GEN_ID (TOVARY_KOD, 1); END

CREATE PROCEDURE GET_KOD_POKUP

RETURNS (NR INTEGER) AS

BEGIN NR=GEN_ID (POKUPATELI_KOD, 1); END

CREATE PROCEDURE GET_KOD_RASXOD

RETURNS (NR INTEGER) AS

BEGIN NR=GEN_ID (RASXOD_KOD, 1); END

В результате наших действий на сервере формируется следующая база:

/* Extract Database c:\uchbase\sklad\ib_sklad.gdb */

CREATE DATABASE «c:\uchbase\sklad\ib_sklad.gdb» PAGE_SIZE 1024

DEFAULT CHARACTER SET WIN1251;

/* Domain definitions */

CREATE DOMAIN KEY_TYPE AS INTEGER DEFAULT 0 NOT NULL;

/* Table: POKUPATELI, Owner: SYSDBA */

CREATE TABLE POKUPATELI (KOD_POKUP KEY_TYPE,

POKUP VARCHAR(30) CHARACTER SET WIN1251 NOT NULL COLLATE PXW_CYRL,

GOROD VARCHAR(20) CHARACTER SET WIN1251 DEFAULT ''

COLLATE PXW_CYRL,

ADRES VARCHAR(25) CHARACTER SET WIN1251 DEFAULT ''

COLLATE PXW_CYRL,

TEL VARCHAR(8) CHARACTER SET WIN1251 COLLATE PXW_CYRL,

PRIMARY KEY (KOD_POKUP));

/* Table: RASXOD, Owner: SYSDBA */

CREATE TABLE RASXOD (KOD_RASH KEY_TYPE,

DATA_RASH TIMESTUMP NOT NULL,

KOLVO INTEGER DEFAULT 0,

STOIM KEY_TYPE,

KOD_TOVAR KEY_TYPE,

KOD_POKUP KEY_TYPE,

PRIMARY KEY (KOD_RASH));

/* Table: TOVARY, Owner: SYSDBA */

CREATE TABLE TOVARY (KOD_TOVAR INTEGER NOT NULL,

TOVAR VARCHAR(20) CHARACTER SET WIN1251 NOT NULL COLLATE PXW_CYRL,

ED_IZM VARCHAR(10) CHARACTER SET WIN1251 DEFAULT ''

COLLATE PXW_CYRL,

ZENA INTEGER DEFAULT 0,

COUNT_TOV INTEGER,

PRIMARY KEY (KOD_TOVAR));

ALTER TABLE RASXOD ADD CONSTRAINT TOV_RASH FOREIGN KEY (KOD_TOVAR) REFERENCES TOVARY (KOD_TOVAR) ON UPDATE CASCADE ON DELETE CASCADE;

ALTER TABLE RASXOD ADD CONSTRAINT POK_RASH FOREIGN KEY (KOD_POKUP) REFERENCES POKUPATELI (KOD_POKUP);

CREATE GENERATOR TOVARY_KOD;

CREATE GENERATOR POKUPATELI_KOD;

CREATE GENERATOR RASXOD_KOD;

ALTER TABLE TOVARY ADD

CHECK (ZENA >= 0);

COMMIT WORK;

SET AUTODDL OFF;

SET TERM ^;

/* Stored procedures */

CREATE PROCEDURE GET_KOD_POKUP AS BEGIN EXIT; END ^

CREATE PROCEDURE GET_KOD_RASXOD AS BEGIN EXIT; END ^

CREATE PROCEDURE GET_KOD_TOVAR AS BEGIN EXIT; END ^

ALTER PROCEDURE GET_KOD_POKUP RETURNS (NR INTEGER) AS

BEGIN NR=GEN_ID (POKUPATELI_KOD, 1);

END

^

ALTER PROCEDURE GET_KOD_RASXOD RETURNS (NR INTEGER) AS

BEGIN

NR=GEN_ID (RASXOD_KOD, 1);

END

^

ALTER PROCEDURE GET_KOD_TOVAR RETURNS (NR INTEGER) AS

BEGIN

NR=GEN_ID (TOVARY_KOD, 1);

END

^

SET TERM; ^

COMMIT WORK;

SET AUTODDL ON;

SET TERM ^;

/* Triggers only will work for SQL triggers */

CREATE TRIGGER AU_POKUPATELI FOR POKUPATELI

ACTIVE AFTER UPDATE POSITION 0 AS

BEGIN

IF (OLD.KOD_POKUP <> NEW.KOD_POKUP) THENUPDATE RASXOD SET KOD_POKUP=NEW.KOD_POKUP WHERE KOD_POKUP = OLD.KOD_POKUP; END

^

CREATE TRIGGER AD_POKUPATELI FOR POKUPATELI

ACTIVE AFTER DELETE POSITION 0 AS

BEGIN

DELETE FROM RASXOD

WHERE RASXOD.KOD_POKUP = POKUPATELI.KOD_POKUP;

END

^

CREATE TRIGGER AI_RASXOD1 FOR RASXOD

ACTIVE AFTER INSERT POSITION 1 AS

BEGIN

UPDATE TOVARY

SET COUNT_TOV= COUNT_TOV-NEW.KOLVO

WHERE KOD_TOVAR = NEW.KOD_TOVAR;

END

^

CREATE TRIGGER AU_RASXOD1 FOR RASXOD

ACTIVE AFTER UPDATE POSITION 1 AS

BEGIN

IF ((OLD.KOLVO <> NEW.KOLVO) AND

(OLD.KOD_TOVAR = NEW.KOD_TOVAR)) THEN

UPDATE TOVARY

SET COUNT_TOV= COUNT_TOV+OLD.KOLVO-NEW.KOLVO

WHERE KOD_TOVAR = OLD.KOD_TOVAR;

END

^

CREATE TRIGGER BD_RASXOD1 FOR RASXOD

ACTIVE BEFORE DELETE POSITION 0 AS

BEGIN

CREATE TRIGGER AU_RASXOD0 FOR RASXOD

ACTIVE AFTER UPDATE POSITION 0 AS

INTO: OldKod;

IF (OldKod IS NOT NULL) THEN

BEGIN

UPDATE TOVARY

SET COUNT_TOV= COUNT_TOV+OLD.KOLVO

WHERE KOD_TOVAR = OLD.KOD_TOVAR;

UPDATE TOVARY

SET COUNT_TOV= COUNT_TOV-NEW.KOLVO

WHERE KOD_TOVAR = NEW.KOD_TOVAR;

END

END

END

SET TERM; ^

/* Grant permissions for this database */

При завершении работы в WINDOWS IB_CONSOLE необходимо зафиксировать изменения в базе данных, выбрав пункт меню «TRANSACTION > COMMIT». Выбор пункта меню TRANSACTION > ROLLBACK» приведет к отказу от всех изменений, произведенных в текущем сеансе работы (после последнего COMMIT).

Заполнение данных в таблице может быть выполнено в двух режимах:

1. Заполнение записей таблицы в интерактивном режиме с использованием средств IB CONSOLE. Для этого необходимо вызвать на экран интерактивное окно свойств соответствующей таблицы и, щелкнув на вкладке Data, начать набор данных. При вводе данных отрабатывают все триггера, определенные в базе данных.

2. Другим вариантом заполнения таблицы является использование операторов языка SQL. Для этого (используя любой редактор текстов, например WordPad) подготовим SQL-программу (SQL-Script) (см. файл ..\TBLOAD.SQL) и выполним ее в окне Interactive SQL (пункт меню Qwery > LOAD Script).

По

Ниже приведен протокол работы этой программы:

SET NAMES WIN1251;

CONNECT 'SKLAD\Ib_sklad.gdb'

USER 'SYSDBA' PASSWORD 'masterkey';

DELETE FROM RASXOD;

DELETE FROM POKUPATELI;

DELETE FROM TOVARY;

SELECT * FROM POKUPATELI;

INSERT INTO POKUPATELI (KOD_POKUP, POKUP, GOROD, ADRES, TEL)

VALUES (1,'Алиса', 'Казань', 'ул. Латышских стрелков', '92-45-67');

INSERT INTO POKUPATELI (KOD_POKUP, POKUP, GOROD, ADRES, TEL)

VALUES (2,'Буратино', 'Рим', 'Италия', '23-45-35');

INSERT INTO POKUPATELI (KOD_POKUP, POKUP, GOROD, ADRES, TEL)

VALUES (5,'Тротилла', 'Пруд', 'Италия', NULL);

INSERT INTO POKUPATELI (KOD_POKUP, POKUP, GOROD, ADRES, TEL)

VALUES (6,'Шекспир', 'Лондон', 'Англия', NULL);

SELECT * FROM POKUPATELI;

KOD_POKUP POKUP GOROD ADRES TEL

1 Алиса Казань ул. Латышских стрелков 92-45-67

2 Буратино Рим Италия 23-45-35

5 Тротилла Пруд Италия <null>

6 Шекспир Лондон Англия <null>

SELECT * FROM TOVARY;

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (1,'Сахар', 'кг', 12,1442);

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (2,'Макароны', 'кг', 5,86);

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (3,'Огурцы весовые', 'кг', 6,250);

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (4,'Огурцы баночные', 'банки', 10,475);

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (5,'Крупа манная', 'кг', 8,1010);

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (2,'Масло подсолнечное', 'л', 10,1977);

Statement failed, SQLCODE = -803

violation of PRIMARY or UNIQUE KEY constraint «INTEG_4» on table «TOVARY»

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (6,'Масло подсолнечное', 'л', - 10,1977);

Statement failed, SQLCODE = -297

Operation violates CHECK constraint INTEG_3 on view or table TOVARY

INSERT INTO TOVARY (KOD_TOVAR, TOVAR, ED_IZM, ZENA, COUNT_TOV)

VALUES (6,'Масло подсолнечное', 'л', 10,1977);

SELECT * FROM TOVARY;

KOD_TOVAR TOVAR ED_IZM ZENA COUNT_TOV

1 Сахар кг 12 1442

2 Макароны кг 5 86

3 Огурцы весовые кг 6 250

4 Огурцы баночные банки 10 475

5 Крупа манная кг 8 1010

6 Масло подсолнечное л 10 1977

SELECT * FROM RASXOD;

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (2,'12.04.98', 10,120,1,6);

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (5,'12.07.00', 12,120,4,5);

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (6,'13.09.00', 5,25,2,2);

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (11,'12.04.03', 10,50,2,6);

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (7,'15.09.00', 1,10,6,6);

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (8,'16.07.00', 7,70,6,1);

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (9,'23.05.00', 11,110,400,1);

Statement failed, SQLCODE = -530

violation of FOREIGN KEY constraint «TOV_RASH» on table «RASXOD»

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (9,'23.05.00', 11,110,4,100);

Statement failed, SQLCODE = -530

violation of FOREIGN KEY constraint «POK_RASH» on table «RASXOD»

INSERT INTO RASXOD (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (9,'23.05.00', 11,110,4,1);

SELECT * FROM RASXOD;

KOD_RASH DATA_RASH KOLVO STOIM KOD_TOVAR KOD_POKUP

2 12-APR-1998 10 120 1 6

5 12-JUL-2000 12 120 4 5

6 13-SEP-2000 5 25 2 2

11 12-APR-2003 10 50 2 6

7 15-SEP-2000 1 10 6 6

8 16-JUL-2000 7 70 6 1

9 23-MAY-2000 11 110 4 1

SELECT * FROM TOVARY;

KOD_TOVAR TOVAR ED_IZM ZENA COUNT_TOV

1 Сахар кг 12 1432

2 Макароны кг 5 71

3 Огурцы весовые кг 6 250

4 Огурцы баночные банки 10 452

5 Крупа манная кг 8 1010

6 Масло подсолнечное л 10 1969

EXIT;

Отметим, что в процессе работы этой программы SQL-сервер проверял описанные ограничения целостности БД и прерывал выполнение операторов, которые нарушали эти ограничения:

Первое сообщение об ошибке (Statement failed…) связано с попыткой вставить в таблицу TOVARY строку с ключом (KOD_TOVAR=2), который уже был использован во второй строке.

Второе сообщение связано с попыткой вставить в таблицу TOVARY строку со значением поля ZENA=-10, для которого объявлен предикат CHECK (ZENA>=0).

Следующие два сообщения связаны с попытками нарушить требование межтабличной целостности - вставить в таблицу RASXOD строки с кодом товара (KOD_TOVAR=400) и кодом покупателя (KOD_POKUP=100), которые не встречаются в таблицах TOVARY и POKUPATELI, соответственно.

Отметим, что после загрузки данных в таблицу RASXOD содержимое таблицы TOVARY тоже изменилось (значение поля COUNT_TOV в некоторых записях) - это отрабатывал триггер AI_RASXOD1.

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

Не выполнялись также и хранимые процедуры, связанные с генераторами. В отличие от триггеров, хранимые процедуры вызываются явно оператором процедуры, а таковых в нашей программе не было. Кстати, именно в связи с этим выше рекомендована инициализация генераторов значением 100 (например, SET GENERATOR TOVARY_KOD TO 100;), так зарезервировано некое число кодов для установки в обход типового случая.

Теперь определим представление (View) для пользователей, которых интересуют покупки только не Казанских покупателей. Для этого опять подготовим SQL-программу ..\VCREATE.SQL и выполним ее. Протокол работы этой программы:

SET NAMES WIN1251;

CONNECT 'SKLAD\Ib_sklad.gdb'

USER 'SYSDBA' PASSWORD 'masterkey';

DROP VIEW RasxodDoc;

DROP VIEW RasxodNoKz;

CREATE VIEW RasxodDoc

(KOD_RASH, DATA_RASH, KOLVO, STOIM,

KOLVO_ZENA,

POKUP, GOROD, ADRES, TEL,

TOVAR, ED_IZM, ZENA, COUNT_TOV)

AS SELECT

RASXOD.KOD_RASH, RASXOD.DATA_RASH, RASXOD.KOLVO, RASXOD.STOIM,

RASXOD.KOLVO*TOVARY.ZENA,

POKUPATELI.POKUP, POKUPATELI.GOROD, POKUPATELI.ADRES, POKUPATELI.TEL,

TOVARY.TOVAR, TOVARY.ED_IZM, TOVARY.ZENA, TOVARY.COUNT_TOV

FROM RASXOD, POKUPATELI, TOVARY

WHERE ((RASXOD.KOD_POKUP=POKUPATELI.KOD_POKUP) AND

(RASXOD.KOD_TOVAR=TOVARY.KOD_TOVAR) AND

(POKUPATELI.GOROD<>'Казань'));

SELECT * FROM RasxodDoc ORDER BY KOD_RASH;

См. результат RDOC.DOC

INSERT INTO RasxodDoc (KOD_RASH, DATA_RASH, KOLVO, STOIM)

VALUES (20,'23.05.02', 110,1100);

Statement failed, SQLCODE = -150

cannot update read-only view RASXODDOC

INSERT INTO Rasxod (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (20,'23.05.02', 110,1100,4,5);

SELECT * FROM RasxodDoc ORDER BY KOD_RASH;

SELECT * FROM Rasxod ORDER BY KOD_RASH;

KOD_RASH DATA_RASH KOLVO STOIM KOD_TOVAR KOD_POKUP

2 12-APR-1998 10 120 1 6

5 12-JUL-2000 12 120 4 5

6 13-SEP-2000 5 25 2 2

7 15-SEP-2000 1 10 6 6

8 16-JUL-2000 7 70 6 1

9 23-MAY-2000 11 110 4 1

11 12-APR-2003 10 50 2 6

20 23-MAY-2002 110 1100 4 5

CREATE VIEW RasxodNoKz

AS SELECT * FROM RASXOD WHERE

('Казань'<>(SELECT GOROD FROM POKUPATELI

WHERE (RASXOD.KOD_POKUP=POKUPATELI.KOD_POKUP)));

SELECT * FROM RasxodNoKz ORDER BY KOD_RASH;

KOD_RASH DATA_RASH KOLVO STOIM KOD_TOVAR KOD_POKUP

2 12-APR-1998 10 120 1 6

5 12-JUL-2000 12 120 4 5

6 13-SEP-2000 5 25 2 2

7 15-SEP-2000 1 10 6 6

11 12-APR-2003 10 50 2 6

20 23-MAY-2002 110 1100 4 5

INSERT INTO RasxodNoKz (KOD_RASH, DATA_RASH, KOLVO, STOIM, KOD_TOVAR, KOD_POKUP)

VALUES (21,'23.05.02', 120,1200,4,5);

SELECT * FROM RasxodNoKz ORDER BY KOD_RASH;

KOD_RASH DATA_RASH KOLVO STOIM KOD_TOVAR KOD_POKUP

2 12-APR-1998 10 120 1 6

5 12-JUL-2000 12 120 4 5

6 13-SEP-2000 5 25 2 2

7 15-SEP-2000 1 10 6 6

11 12-APR-2003 10 50 2 6

20 23-MAY-2002 110 1100 4 5

21 23-MAY-2002 120 1200 4 5

SELECT * FROM Rasxod ORDER BY KOD_RASH;

KOD_RASH DATA_RASH KOLVO STOIM KOD_TOVAR KOD_POKUP

2 12-APR-1998 10 120 1 6

5 12-JUL-2000 12 120 4 5

6 13-SEP-2000 5 25 2 2

7 15-SEP-2000 1 10 6 6

8 16-JUL-2000 7 70 6 1

9 23-MAY-2000 11 110 4 1

11 12-APR-2003 10 50 2 6

20 23-MAY-2002 110 1100 4 5

21 23-MAY-2002 120 1200 4 5

EXIT;

Представление RasxodDoc для каждого документа о покупке содержит полную пользовательскую информацию - включает реквизиты покупателя и товара вместо их кодов. Отметим, что реквизит «стоимость покупки» вычислим и определен в этом представлении (KOLVO_ZENA)… использование хранимого значения этого реквизита в поле STOIM таблицы RASXOD требует обоснования…

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

Представление RasxodNoKz имеет такие же поля, как и таблица Rasxod, но оно включает строки только о покупках не Казанских покупателей. RasxodNoKz - модифицируемое представление, это иллюстрирует третий INSERT, который добавляет строку в RasxodNoKz. Эта строка появляется и в таблице Rasxod, что опять же иллюстрирует специфику представлений.

3. Администрирование базы данных. BDE. Создание псевдонима

Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). BDE представляет собой совокупность динамических библиотек и драйверов, позволяющих осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода (обрабатывается отдельно каждая запись таблицы), так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных (одновременно обрабатывается группа записей). Приложение через BDE передает запрос к базе данных и получает требуемые данные.

Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный «ODBC socket», который позволяет встраивать их в BDE.

Все инструментальные средства баз данных Borland - Paradox, dBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или dBase, «наследуются» BDE, и поэтому этими же особенностями обладает и Delphi.

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

Удобно не указывать путь доступа к таблицам базы данных, а использовать для этого некий заменитель - псевдоним, называемый алиасом. Он сохраняется в отдельном конфигурационном файле и позволяет исключить из программы прямое указание пути доступа к базе данных. Такой подход дает возможность располагать данные в любом месте, не перекомпилируя при этом программу. Кроме пути доступа, при алиасе указываются тип базы данных, языковый драйвер и много другой управляющей информации. Поэтому использование алиасов позволяет легко переходить от локальных баз данных к SQL-серверным базам (естественно, при выполнении требований разделения приложения на клиентскую и серверную части).

Для создания алиаса необходимо запустить утилиту конфигурации BDE (BDE administrator, программу BDEADMIN.EXE), находящуюся в директории, в котором располагаются динамические библиотеки BDE. После запуска необходимо выбрать режим создания нового алиаса (пункт меню Object > New), выбрать в появившемся списке драйверов драйвер IntrBase и настроить пункты появившейся формы:

LangDriver - Pdox Ansi Cyrillic (обработка русской кириллицы в Ansi-кодировке)

Server Name - C:\UCHBASE\SKLAD\Ib_sklad.gdb (полный путь к базе данных)

User Name - SYSDBA (системное имя пользователя)

В правой части экрана необходимо заменить стандартный алиас IntrBase на свой (в примере использован алиас Al_Sklad).

база данные товар покупатель

4. Разработка клиентского места

В данной методической разработке рассмотрены две реализации клиентского приложения на Object_Pascal и C++. Причем для сопоставимости в качестве среды разработки выбраны DELPHI6 BORLAND C++BUILDER6. Такой выбор позволил продемонстрировать реализацию клиентского приложения с использованием одной и той же объектной библиотеки, а отличия в коде связаны только с особенностью используемых языков программирования. Коды используемых процедур приводятся в виде таблицы, левая колонка которой связана с языком Object_Pascal, а правая - с C++. При выполнении курсового проекта студент может выбрать любую реализацию.

Основная экранная форма

Имеются несколько основных компонент (классов), которые используются для доступа к БД. Эти классы делятся на три группы:

невизуальные: TDataBase, TTable, TQuery, TField

визуальные: TDBGrid, TDBEdit

связующие: TDataSource

Первая группа включает невизуальные классы, которые используются для управления базами данных, таблицами и запросами. Эта группа сосредотачивается вокруг компонент типа TDataBase, TTable, TQuery и TField. В Палитре Компонент они расположены на странице BDE.

Вторая важная группа классов - визуальные, которые показывают данные пользователю, и позволяют ему просматривать и модифицировать их. Эта группа классов включает компоненты типа TDBGrid, TDBEdit, TDBImage и TDBComboBox. В Палитре Компонент они расположены на странице Data Controls.

Третий тип, используется для того, чтобы связать предыдущие два типа объектов. К этому типу относится невизуальный компонент TDataSource (на странице Data Access).

Рассмотрим последовательность действий построения клиентской части программы ..\PRG0\SKLAD.DPR.

Параметр Login prompt должен иметь значение false. В противном случае, при любом обращении к базе данных система будет запрашивать у пользователя пароль доступа к БД. Поле отметки Keep Inactive Connection в отмеченном состоянии означает, что соединение с БД будет сохраняться даже, если ни один набор данных этой базы данных не будет открыт. В окне Parameter overrides можно переустановить параметры псевдонима БД и драйвера.

Элемент типа TDataBase создается для каждого факта соединения с отдельной базой данных. Случаи явного использования в приложении компонента TDataBase чаще всего связаны с работой в архитектуре клиент-сервер. Явно определенный в программе компонент TDataBase облегчает управление БД, создавая постоянные соединения с ней, настраивая сеанс соединения с базой данных, управляя транзакциями, создавая локальные псевдонимы BDE. Каждый набор данных, работающий с таблицами одной и той же БД, может иметь с этой базой отдельное соединение. Однако это нерационально, поскольку каждое соединение съедает системные ресурсы. Для минимизации их использования рекомендуется создавать единственное соединение с базой данных при помощи компонента TDataBase, а все наборы данных, реализующие действия над БД, соединять с этим компонентом. Соединение активизируется установкой свойства Connected в значение true. Свойство DataBaseName определяет локальный псевдоним БД, который может использоваться при доступе к БД вместо псевдонима BDE.

3. Доступ к конкретной таблице БД регулируется компонентом TTable из набора Data Access. Для организации доступа к таблице «Товары» необходимо переместить копию компонента TTable на экранную форму и настроить в инспекторе объектов свойства DataBaseName (установить алиас UchSklad), свойство TableName (установить TOVARY). Кроме того, установим имя Name объекта как TovaryTable

Доступ к таблице регулируется установкой значения свойства Active в true. В программном коде открытие (закрытие) таблицы осуществляется также с помощью метода TovaryTable. Open (TovaryTable. Close).

TTable представляет собой пример невизуального компонента и становится невидимым при запуске программы. Для визуализации данных таблицы и интерактивной работы с ними служит компонент TDBGrid в группе Data Controls. Связь между визуальными и невизуальными компонентами осуществляется компонентом TdataSource. Этот класс используется в качестве проводника между TTable или TQuery и компонентами, визуализирующими данные, типа TDBGrid, TDBEdit и TDBComboBox (data-aware components). В большинстве случаев, все, что нужно сделать с DataSource - это указать в свойстве DataSet соответствующий TTable или TQuery. Затем, у data-aware компонента в свойстве DataSource указывается TDataSource, который используется в настоящее время. Любая таблица может быть открыта на этапе проектирования. При этом визуальные компоненты, связанные с таблицей, отображают текущее состояние записей соответствующего набора данных, но перемещение и редактирование записей невозможны. Исключение составляет возможность перемещения текущего указателя с помощью полосы прокрутки для визуальной компоненты TDBGrid.

TDataSource также имеет свойство Enabled, и оно может быть полезно всякий раз, когда Вы хотите временно отсоединить, например, DBGrid от таблицы или запроса. Это требуется, например, если нужно программно пройти через все записи в таблице. Ведь, если таблица связана с визуальными компонентами (DBGrid, DBEdit и т.п.), то каждый раз, когда Вы вызываете метод TTable. Next, визуальные компоненты будут перерисовываться. Даже если само сканирование в таблице двух или трех тысяч записей не займет много времени, то может потребоваться значительно больше времени, чтобы столько же раз перерисовать визуальные компоненты. В случаях подобных этому, лучше всего установить поле DataSource. Enabled в False. Это позволит просканировать записи без перерисовки визуальных компонент. Такая операция может увеличить скорость в некоторых случаях в десятки и сотни раз.

Свойство TDataSource. AutoEdit указывает, переходит ли DataSet автоматически в режим редактирования при вводе текста в data-aware объекте.

Перенесем компонент TDataSource на форму и установим свойство DataSet равным TovaryTable.

4. Перенесем компонент TDBGrid на форму. Установим значение свойства DataSource равным DataSource1. Добавим на форму компонент TDBNavigator, свойство DataSource которого установим равным DataSource1. Прежде чем запустить программу добавим на форму компонент TStoredProc, свойство DatabaseName которого установим равным UchSklad, а имя процедуры StoredProcName GET_KOD_TOVAR (Напомним, что эту процедуру мы создали ранее на сервере).

Далее найдем для объекта TovaryTable событие AfterInsert и определим обработчик этого события в виде процедуры

Оператор StoredProc1. ExecProc (В C++ функция StoredProc1->ExecProc();) запускает процедуру с именем GET_KOD_TOVAR на сервере. Полученный результат присваивается полю Kod_Tovar. При помощи этой процедуры можно автоматически увеличивать значение поля Kod_Tovar на 1.

Кнопки объекта DBNavigator1 имеют слева направо следующие значения:

Первая запись

Предыдущая

Следующая

Последняя запись

Вставка записи

Удаление записи

Редактирование записи

Подтверждение редактирования

Отказ от изменений

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

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

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

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

на уровне операционной системы (через настройку свойств «языки и стандарты» панели управления)

на уровне BDE (настройка параметров драйверов)

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

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

Системная переменная (модуля SysUtils) DateSeparator описывает разделитель, переменные ShortDateFormat и ShortTimeFormat задают форматы дат и времени. Процедура отрабатывает при запуске программы при создании формы.

В качестве примера динамического перепрограммирования свойств объектов приведем пример обслуживания одним навигатором двух таблиц «Товары» и «Покупатели». Как уже упоминалось выше, в навигаторе свойство DataSource необходимо настроить на имя компонента TDataSource, связывающий навигатор с определенной таблицей. Изменяя динамически эту связь можно одним навигатором обслуживать различные таблицы.

Перенесем на форму копию компонента Tlabel и напишем обработчик события OnEnter для объекта DBGrid1.

Аналогичную процедуру

будем использовать как обработчик события OnEnter для объекта DBGrid2.

Запустив программу можно убедиться, что любое переключение между объектами Grid для таблиц «Товары» и «Покупатели» изменяет состояние метки Label1, которое показывает, какой таблицей в настоящий момент управляет навигатор.

Для таблицы «Расход товара» построим собственный навигатор, используя методы объекта TTable.

В частности, если на форме имеется объект Table1, то методы Table1. First, Table1. Last, Table1. Next, Table1. Prior - осуществляют соответственно переход к первой, последней, следующей и предыдущей записи.

Добавление новой записи осуществляется с использованием метода Table1. Add или Table1. Insert. Отличие метода Table1. Add от Table1. Insert состоит в том, что в первом случае запись добавляется в конец таблицы, а во втором - запись вставляется непосредственно перед записью, на который указывает курсор. Метод Table1. Delete удаляет текущую запись.

Метод Table1. Edit переводит таблицу в режим редактирования. Методы Table1. Post и Table1. Cancel означают соответственно подтверждение или отказ от сделанных изменений. Метод Table1. Refresh обновляет содержимое таблицы на форме. Необходимо помнить, что всякий раз, когда происходит смещение указателя с текущей записи, в таблице автоматически будут сохранены введенные данные. Это означает, что вызовы First, Next, Prior и Last всегда выполняют Post, если Вы находились в режиме редактирования. Если Вы работаете с данными на сервере и транзакциями, тогда правила, приведенные здесь, не применяются. Тем не менее, даже если Вы не работаете с транзакциями, Вы можете все же отменить результаты вашего редактирования в любое время, до тех пор, пока не вызвали напрямую или косвенно метод Post. Например, если Вы перевели таблицу в режим редактирования, и изменили данные в одном или более полей текущей записи, Вы можете всегда вернуть текущую запись в исходное состояние вызовом метода Cancel.

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

Перечислим основные состояния набора данных:

dsInactive - набор данных закрыт;

dsBrowse - набор данных находится в состоянии просмотра. Переход в этот режим происходит из режимов dsEdit и dsInsert при вызове одного из методов Post или Cancel.

dsEdit - набор данных находится в состоянии редактирования. Переход в этот режим происходит из режимов dsBrowse при вызове метода Edit.

dsInsert - набор данных находится в состоянии добавления новой записи. Переход в этот режим происходит из режимов dsBrowse при вызове одного из методов Insert, InsertRecord, Append или AppendRecord.

dsSetKey - режим поиска записей, удовлетворяющих некоторому условию. Переход в этот режим происходит из режимов dsBrowse при вызове одного из методов SetKey, FindKey, GotoNearest или FindNearest. Возможен только для компоненты типа TTable, для компоненты TQuery отбор записей осуществляется средствами языка SQL.

dsOpening - набор данных находится в открытом состоянии.

Построим на форме кнопки «Следующая» (Next) и «Вставить» (Add), выбирая компонент Button из палитры Standart. В обработчик события OnClick первой кнопки вставим процедуру

а в соответствующий обработчик второй кнопки процедуру

Задача: Построить код для своего навигатора таблицы «Расход товара», смоделировав работу навигатора из визуальной библиотеки компонент.

Выше уже отмечалось, что таблицы «Товары» и «Расход товара» связаны по формулам:

Стоимость купленного товара:=Количество купленного товара * цена единицы товара,

Количество товара на складе:= Количество товара на складе - Количество купленного товара.

При этом заметим, «Количество купленного товара» и «цена единицы товара» («Количество товара на складе») лежат в разных таблицах. Решением второй задачи мы уже занимались.