ПЕРЕЛІК ДИСЦИПЛІН:
  • Адміністративне право
  • Арбітражний процес
  • Архітектура
  • Астрологія
  • Астрономія
  • Банківська справа
  • Безпека життєдіяльності
  • Біографії
  • Біологія
  • Біологія і хімія
  • Ботаніка та сільське гос-во
  • Бухгалтерський облік і аудит
  • Валютні відносини
  • Ветеринарія
  • Військова кафедра
  • Географія
  • Геодезія
  • Геологія
  • Етика
  • Держава і право
  • Цивільне право і процес
  • Діловодство
  • Гроші та кредит
  • Природничі науки
  • Журналістика
  • Екологія
  • Видавнича справа та поліграфія
  • Інвестиції
  • Іноземна мова
  • Інформатика
  • Інформатика, програмування
  • Юрист по наследству
  • Історичні особистості
  • Історія
  • Історія техніки
  • Кибернетика
  • Комунікації і зв'язок
  • Комп'ютерні науки
  • Косметологія
  • Короткий зміст творів
  • Криміналістика
  • Кримінологія
  • Криптология
  • Кулінарія
  • Культура і мистецтво
  • Культурологія
  • Російська література
  • Література і російська мова
  • Логіка
  • Логістика
  • Маркетинг
  • Математика
  • Медицина, здоров'я
  • Медичні науки
  • Міжнародне публічне право
  • Міжнародне приватне право
  • Міжнародні відносини
  • Менеджмент
  • Металургія
  • Москвоведение
  • Мовознавство
  • Музика
  • Муніципальне право
  • Податки, оподаткування
  •  
    Бесплатные рефераты
     

     

     

     

     

     

         
     
    Створення баз даних в InterBase SQL Server
         

     

    Інформатика, програмування

    Створення баз даних в InterBase SQL Server

    Я не буду захаращувати текст докладним описом всіх операторів для створення об'єктів у базі даних. Для цього є документація. Навпаки, на простих прикладах спробую показати як і коли потрібно робити так чи інакше. Тут описується робота з SQL сервером InterBase 6.0.

    Створення бази даних

    База даних створюється простим скриптом. Тут і надалі я буду SQL оператори виділяти жирним шрифтом.

    CREATE DATABASE '... PFO_POKAZATELI.GDB' USER 'ADM_PFO_POK' PASSWORD '12345 '

    PAGE_SIZE = 8192

    DEFAULT CHARACTER SET WIN1251;

    CREATE DATABASE - це і є оператор, що створить базу даних. База даних буде являти собою файл, який буде створено в каталозі, вказаному після оператора. Розширення файлу може бути будь-яким, але прийнято, що GDB - розширення для файлу бази даних, а, наприклад, GBP - для резервної копії.

    USER і PASSWORD задають ім'я користувача і пароль. Цей користувач повинен бути зареєстрований на сервері до створення бази даних, інакше InterBase видасть повідомлення про помилку.

    PAGE SIZE задає розмір сторінки даних у файлі за замовчуванням. Сторінка буде викачуватися з жорсткого диска тільки цілком. Тому, можна вважати, що це мінімальний розмір буфера роботи з файлом бази даних. Сторінка повинна бути такого розміру, щоб в неї помістилася хоча б один запис в будь-якій з таблиць. Тут не потрібно враховувати розмір BLOB поля, тому що для його зберігання виділяються додаткові сторінки. Розміри сторінок можуть бути від 1024 до 8192 Kb. Розмір сторінок впливає на швидкодію і ступінь заповнення даними файлу бази даних. Так, якщо наступний запис не поміщається повністю в активну сторінку, то для неї буде виділена нова сторінка. Тому слід прагнути до кратному сторінці розміром запису. Це, звичайно досить проблематично, тому що у Вас в БД може бути кілька таблиць з різними розмірами запису. Занадто великий розмір сторінки призводить до зчитування з диска записів, які можуть не знадобитися у вихідних даних запиту, що повинно знижувати швидкодію всієї системи в цілому. Очевидно, це відбувається при маленьких розмірах запису в порівнянні з розміром сторінки. Однак, численні досліди показують, що швидкодія може і знижується, але на таку маленьку величину, яку неможливо зафіксувати і зміряти в реальних грамотно побудованих додатках.

    DEFAULT CHARACTER SET визначає кодування символів у базі даних. Якщо Ви маєте намір використовувати російську мову, то ви повинні встановити значення WIN 1251. Для інших мов є свої кодіровочние таблиці. Зазвичай базу даних створюють в IBConsole. Там потрібно вибрати пункт меню "Database | Create Database ". У що з'явилося, вікні заповнити поля введення параметрів операторів для створення БД.

    Ви можете створити БД з декількох файлів, які будуть заповнюватися даними по черзі. Або створити дзеркало на іншому жорсткому диску для захисту від катастрофи основного жорсткого диска (див. документацію). Створення таблиць

    InterBase - це не зовсім те, про що писав Коддом. Тут повністю не реалізовано поняття домену. Домени служать в InterBase не для зв'язку таблиць по первинному та зовнішньому ключу, а для опису типу поля, певного користувачем. Більш того, якщо Ви почнете створювати таблиці з полями стандартного типу, то кожному з цих полів буде поставлено у відповідність свій домен. Це призводить до того, що кількість об'єктів у базі даних збільшується за рахунок доменів прямо пропорційно кількості полів всіх таблиць. Тому, зазвичай створюють достатню кількість доменів для опису таблиць в БД, а потім створюють самі таблиці. Ось витяг з реальної бази даних для створення доменів:

    CREATE DOMAIN IZMER_NUM INTEGER NOT NULL;

    CREATE DOMAIN ACTIVITIES_NUM INTEGER NOT NULL;

    . . .

    CREATE DOMAIN NAMES_TYPE VARCHAR (45) COLLATE PXW_CYRL;

    CREATE DOMAIN FLOAT_TYPE DOUBLE PRECISION;

    CREATE DOMAIN BOOL_TYPE CHAR (1) DEFAULT "F" CHECK (VALUE = "T" OR VALUE = "F ");

    CREATE DOMAIN FORMULA_TYPE BLOB SUB_TYPE 1 SEGMENT SIZE 256 CHARACTER SET WIN1251;

    CREATE DOMAIN INTEGER_TYPE INTEGER;

    . . .

    CREATE DOMAIN BY_USER VARCHAR (30) DEFAULT USER;

    CREATE DOMAIN BY_DATE TIMESTAMP DEFAULT "now";

    Команда CREATE DOMAIN створює новий домен. Далі, йде ім'я домену. Потім - його тип. Є безліч типів даних, які підтримує InterBase. Ви можете дізнатися цю інформацію з документації. Далі, можна поставити обмеження на значення, заводімое в полі таблиці типу цього домену. Наприклад, NOT NULL зобов'язує завжди заводити будь-які дані в це поле при додаванні нового рядка в таблицю, тобто це поле обов'язково має бути заповнено. DEFAULT "F" заповнює поле значенням за замовчуванням - символом "F". Конструкція CHECK (VALUE = "T" OR VALUE = "F") перевіряє вихід значення поля за задані межі. Конструкція COLLATE PXW_CYRL дозволяє правильно вести сортування рядків таблиці по полю типу цього домену. Ця конструкція застосовується при створенні домену або при оголошенні індексу (про це пізніше). Конструкція CREATE DOMAIN FORMULA_TYPE BLOB SUB_TYPE 1 SEGMENT SIZE 256 CHARACTER SET WIN1251 створює домен типу BLOB, тобто набір байтів, які розглядаються як текст (SUB_TYPE 1), сторінки у файлі БД для цього тексту виділяються по 256 байт відразу і текст в цьому полі записується в кодуванні WIN1251. Останні два домену можуть зберігати інформацію про користувача та дату і час про останній зміни запису. Тепер створимо якусь таблицю.

    CREATE TABLE IZMER_NAMES

    (

    ID_NUM IZMER_NUM,

    NAME NAMES_TYPE,

    USER_NAME BY_USER,

    CHANGE_DATE BY_DATE,

    PRIMARY KEY (ID_NUM)

    );

    Оператор CREATE TABLE власне, створює таблицю, далі йде її унікальне в межах БД ім'я. Між дужками стоять визначення стовпчиків таблиці і додаткові оператори. Ми бачимо, що таблиця складається з чотирьох стовпчиків, а їх тип описаний через домени, які ми описали раніше. Якщо Ви створите ще одну таблицю з полем типу NAMES_TYPE, то кількість доменів у Вас не збільшиться, а якщо б Ви створили дві таблиці, у яких було б по одному полю типу VARCHAR (45), то це привело б до створення двох доменів, що описують ці поля. Причому, імена цих доменів присвоїли б за замовчуванням, а значить, абсолютно нечитабельні. Оператор PRIMARY KEY пределяет ім'я або імена полів, які розглядаються як первинний ключ. Поля первинного ключа повинні бути NOT NULL і поєднання їх значень повинно бути унікально в межах таблиці. Це як би відбиток пальців запису - набір значень полів, за якими ми завжди зможемо відрізнити один запис від іншої. Якщо Ви не можете виділити первинний ключ в таблиці для зберігання Ваших даних, значить, швидше за все, Ви недостатньо добре продумали всі питання зі зберігання даних у табліце.Связиваніе таблиць

    Зв'язати можна хоча б дві таблиці, тому визначимо друга:

    CREATE TABLE ACTIVITIES

    (

    ID_NUM ACTIVITIES_NUM,

    ID_IZMER_NAMES IZMER_NUM,

    POZITION INTEGER_TYPE,

    NAME NAMES_TYPE,

    IS_DECCIPHERAD_INFO BOOL_TYPE,

    USER_NAME BY_USER,

    CHANGE_DATE BY_DATE,

    PRIMARY KEY (ID_NUM),

    FOREIGN KEY (ID_IZMER_NAMES) REFERENCES IZMER_NAMES (ID_NUM));

    У другій таблиці є поле з типом IZMER_NUM - це домен, який використовується в першій таблиці для визначення поля первинного ключа. Ми можемо створити зовнішній ключ для зв'язку двох таблиць: FOREIGN KEY (ID_IZMER_NAMES) REFERENCES IZMER_NAMES (ID_NUM). Що буквально означає: "Зовнішній ключ по полю ID_IZMER_NAMES як посилання в таблицю IZMER_NAMES по полю ID_NUM ". Такий зв'язок гарантує нам, що в таблиці IZMER_NAMES завжди буде присутній рядок з номером, що ми запишемо в полі ID_IZMER_NAMES. Якщо хто-небудь спробує видалити з довідника одиниць виміру рядок, яку ми використовуємо в довіднику діяльності, то станеться виняткова ситуація. Така поведінка БД називається контроль посилальної цілісності. Тепер, трохи слів про план побудови БД. Добре, якщо у Вас є якийсь ніякої Case інструмент, наприклад, Rational Rose. Кажуть, що в Microsoft Office з'явився Visio. Я підозрюю, що це щось не зовсім те, що потрібно, але краще зараз працювати хоч на чомусь, що довго чекати хороший інструмент. Ну, а якщо ні Case, то слід враховувати ряд невеликих правил:

    Складіть текст БД, а потім вводите запити. Текст стане в нагоді Вам для перевірки перед введенням. У процесі введення, Ви знайдете ряд помилок, які відразу заносите в текст БД (скрипт).

    Спочатку створюються довідники, які не мають зовнішніх зв'язків, потім ті таблиці, які мають зв'язки на ці довідники і т.д. від простого до складного, або Вам доведеться все зв'язку визначати після створення таблиць.

    Не використовуйте для створення БД візуальні програми типу Database Desctop або SQL Explorer. Вводите все у вигляді SQL запитів, наприклад у Interactive SQL. По крайней мере, Ви точно будете знати який саме запит Ви намагаєтеся виконати.

    Сурогатні ключі

    Є два типи ключових полів. Перше - це природні ключі. Візьмемо, наприклад, медичну картку в поліклініці. Природний ключ - це номер медичної карти. На медичну карту "чіпляються" талони (зв'язок головний - підлеглі), у яких природний ключ - це номер медичної карти хворого, звітний рік і номер талона (з нового року нумерація починається з одиниці). До талонами "чіпляються" відвідування, у яких природний ключ - номер медичної карти хворого, звітний рік, номер талону і дата відвідування. До відвідувань - послуги і т.д. Ми бачимо, що розмір первинного ключа збільшується, принаймні, на одне поле з кожною новою таблицею. Відповідно, зростає обчислювальна навантаження, яке можна оцінити потужністю домену, на сервер БД. Як же можна протистояти розростання первинного ключа? Багато програмістів, і я в тому числі, вважають, що унікальність запису і первинний ключ - це поняття, взагалі-то різні, тому ми завжди, де це потрібно, застосовуємо т.зв. скорочення первинного ключа. Для цього використовуються сурогатні (тобто неприродні) ключі. Що таке сурогатний ключ? Це поле цілого типу, яке має унікальне значення, що утворить домен з іншими таблицями. Візьмемо, для прикладу, випадок з поліклінікою. Для таблиці з талонами вводиться унікальне поле цілого типу, в якому буде зберігається послідовність цілих чисел 1, 2, 3 ... N і т.д. Це поле оголошено первинним ключем, а щоб не завести декілька талонів з однаковими номерами, оголошується унікальний індекс по полях звітний рік і номер талона. Зовнішній ключ, як і годиться - по полю номера медичної карти. У результаті, ми скоротили розмір первинного ключа, який тепер є сурогатним. Ці цілі числа будуть використовуватися в таблиці з відвідинами, де теж можна скорочувати первинний ключ. Зауважте, що в таблиці з відвідинами, тепер, не потрібно зберігати не номер медичної карти, не звітний рік, не номер талона, а тільки значення первинного ключа, тобто одне ціле число на запис.

    Ось кілька прикладів для роботи з сурогатними ключами.

    Для початку, потрібно створити механізм підтримки унікальності значень сурогатного ключа.CREATE GENERATOR GET_IZMER_NAMES_NUM;

    Цей оператор створює т.зв. генератор, де буде зберігатися попереднє значення нашій унікальній послідовності цілих чисел. Механізм гарантує, що тільки одна користувач може мати доступ до генератора в один момент часу. Решта будуть чекати, поки генератор не звільниться.

    SET GENERATOR GET_IZMER_NAMES_NUM TO 50;

    Цим оператором ми встановили початкове значення генератора. Далі, можна або створити тригер, який спрацює при додаванні нового запису в таблицю, або створити простеньку процедуру, яка поверне чергове значення з генератора:

    SET TERM!! ;

    CREATE PROCEDURE SET_IZMER_NAMES_NUM

    RETURNS (NUM INTEGER)

    AS

    BEGINNUM = GEN_ID (GET_IZMER_NAMES_NUM, 1);

    END!!

    SET TERM;!!

    GEN_ID - це вбудована процедура, яка просто збільшує значення генератора на величину, що була передана в другому параметрі і повертає результат. Якщо Ви використовуєте тригер, то після додавання нового запису, Вам доведеться оновлювати весь набір даних, щоб знати значення первинного ключа, тому краще використовувати процедуру.

    "Дерев'яні" списки

    Бувають випадки, коли ставлення головний-підлеглий притаманне записів одній і тій же таблиці, наприклад, відносини між відділами організації або між структурами держапарату і т.д. і т.п. Одна запис може бути головною для декількох інших, які в свою чергу можуть бути головними для наступних. Така структура нагадує дерево з гілками, розташованими вниз по таблиці. Перший запис (записи) - головний вузол (вузли) від яких йдуть гілки (підлеглі запису). Якщо ці записи мають свої підлеглі (вкладені) запису, то вони утворюють наступні за ієрархічним списком вузли. Простіше за все, представити це у просторі у вигляді шарів записів. Кожен запис може містити в собі вкладений шар із записами. Незважаючи на всю позірну складність, реалізація такої структури дуже проста. Для цього потрібно мати, як мінімум, два стовпчика в таблиці: перший стовпчик - це сурогатний первинний ключ, а другий - посилання на перший стовпчик із значенням первинного ключа запису - Власника. Ось реалізація такої таблиці:

    CREATE TABLE ACTIVITIES

    (

    ID_NUM ACTIVITIES_NUM,

    ID_OWNER ACTIVITIES_NUM,

    ID_IZMER_NAMES IZMER_NUM,

    POZITION INTEGER_TYPE,

    NAME NAMES_TYPE,

    USER_NAME BY_USER,

    CHANGE_DATE BY_DATE,

    PRIMARY KEY (ID_NUM),

    FOREIGN KEY (ID_IZMER_NAMES) REFERENCES IZMER_NAMES (ID_NUM));

    Таблиця містить первинний ключ в поле ID_NUM, посилання на головну запис у полі ID_OWNER, посилання на одиницю виміру в поле ID_IZMER, поле POZITION цілого типу, що визначає позицію записи, для можливості переміщення запису вгору і низ, найменування виду дечтельності в поле NAME. Далі, йдуть лічильник і процедура для роботи з первинним ключем.

    CREATE GENERATOR GET_ACTIVITIES_NUM;

    SET GENERATOR GET_ACTIVITIES_NUM TO 50;

    SET TERM!! ;

    CREATE PROCEDURE SET_ACTIVITIES_NUM

    RETURNS (NUM INTEGER)

    AS

    BEGINNUM = GEN_ID (GET_ACTIVITIES_NUM, 1);

    END!!

    SET TERM;!!

    Далі, йде індекс для сортування рядків по позиції. Назва POZITION прийнято мною не тому, що я не знаю про англійською слові POSITION, а тому, що POSITION - зарезервований ідентифікатор SQL.

    CREATE UNIQUE INDEX ACTIVITIES_POSITION ON ACTIVITIES (ID_OWNER, POZITION);

    Тригер UPDATE_ACTIVITIES оновлює значення полів, ідентіфіцірующіз користувача який вніс останні зміни.

    SET TERM!! ;

    CREATE TRIGGER UPDATE_ACTIVITIES FOR ACTIVITIES

    BEFORE UPDATE AS

    BEGIN

    NEW.USER_NAME = USER;

    NEW.CHANGE_DATE = 'now'

    END!!

    SET TERM;!!

    Нарешті, доданий зовнішній індекс таблиці на саму себе. В описі таблиці це не можна було зробити, тому що ні поля ID_OWNER, ні поля ID_NUM, ні самої таблиці не існувало.

    ALTER TABLE ACTIVITIES

    ADD

    FOREIGN KEY (ID_OWNER) REFERENCES ACTIVITIES (ID_NUM) ON DELETE CASCADE;

    Далі, йде процедура переміщення рядки в шарі даних вгору або низ. Мається на увазі, що в шарі не більше 2147483646 рядків.

    SET TERM!! ;

    CREATE PROCEDURE SET_ACTIVITIES_POSITION (OWNER_NUM INTEGER, OLD_POSITION INTEGER, NEW_POSITION INTEGER)

    AS

    BEGINUPDATE ACTIVITIES

    SET

    POZITION = 2147483647

    WHERE

    POZITION =: NEW_POSITION AND

    ID_OWNER =: OWNER_NUM;

    UPDATE ACTIVITIES

    SET

    POZITION =: NEW_POSITION

    WHERE

    POZITION =: OLD_POSITION AND

    ID_OWNER =: OWNER_NUM;

    UPDATE ACTIVITIES

    SET

    POZITION =: OLD_POSITION

    WHERE

    POZITION = 2147483647 AND

    ID_OWNER =: OWNER_NUM;

    END!!

    SET TERM;!!

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

    Робота з подіями

    Це зовсім просто:

    SET TERM!! ;

    CREATE TRIGGER CHANGE_ACTIVITIES FOR ACTIVITIES

    AFTER UPDATE POSITION 0 AS

    BEGIN

    POST_EVENT 'Update Activities !';

    END!!

    SET TERM;!!

    Залишилося тільки зареєструвати це подія в додатку користувача, і якщо воно відбудеться на сервер, то додаток користувача його отримає. Так можна, наприклад, спостерігати за змінами курсів валют на біржі. При зміні курсу, клієнт отримує подія і пере відкриває запит, щоб побачити зміни.

    Робота з винятками

    Для початку, виключення потрібно визначити в БД.

    CREATE EXCEPTION DELETE_MAIN_PARENT 'DO NOT DELETE THIS RECORD! THIS RECOCT IS PARENT FOR ALL RECORDS. ';

    Далі, потрібно визначити тригер, який зловить виняткову ситуацію. Наприклад, при видаленні головного узда дерева, віддалиться вся БД цілком. Зрозуміло, що такого бути не повинно. Давайте спіймаємо це виняток.

    SET TERM!! ;

    CREATE TRIGGER CHECK_DELETE_TYPES FOR ACTIVITIES

    BEFORE DELETE POSITION 0 AS

    BEGIN

    IF (ACTIVITIES.ID_NUM = ACTIVITIES.ID_OWNER) THEN

    EXCEPTION DELETE_MAIN_PARENT;

    END!!

    SET TERM;!!

    Якщо виняткова ситуація настане, то користувачу нічого не залишиться зробити, окрім як відмінити транзакцію.

    Процедури, тригери

    Поняття процедур і тригерів має, перш за все, асоціюватися з поняттям бізнес-логіка. Процедури реалізують документований інтерфейс до даних в БД, а тригери - перевірку коректності вводяться даних і закулісну роботу. Якщо у Вас є можливість перекласти всю бізнес-логіку на сервер у вигляді тригерів і процедур, то так і потрібно робити. Навіть якщо Ви в програмі контролюєте правильність даних, що вводяться, не забудьте в БД продублювати це ж в тригері. Такий підхід гарантує, що при написанні додаткового модуля або ще однієї програми, що оперує з даними БД, Вам не вдасться порушити правила роботи з даними. Я думаю, що прикладів тригерів і процедур було достатньо. Але, починаючі програмісти часто відмовляються від використання має також вантажопасажирську версіюпро найпотужнішого механізму БД з за прикрих помилок в синтаксисі запитів. Їм здається, що в додатку користувача легше зробити те ж саме, до того ж і працює воно швидше ... Це оману. Одна справа, коли Ви пишете і тестуєте програму локально, і зовсім інше, коли до БД підключені користувачі. Жодна програма не зробить зміни до БД так само швидко і коректно, як вбудовані механізми. Ось тоді вони будуть працювати локально, а ваша програма - по мережі. Тому я дам без коментарів приклад процедури з великою кількістю операторів. З цього приклад буде ясно де ставити, а де ні крапки з комою, двокрапки і т.д. Думаю, що це допоможе Вам у Ваших розробках.

    SET TERM!! ;

    CREATE PROCEDURE CHECK_USER_SECURITY (ID_USER INTEGER, ID_DOC INTEGER, UP_TREE INTEGER)

    RETURNS (IS_SHOW CHAR (1), IS_EDIT CHAR (1), IS_APPEND CHAR (1), IS_DELETE CHAR (1))

    AS

    DECLARE VARIABLE TREE_NUMBER INTEGER;

    DECLARE VARIABLE TREE_OWNER INTEGER;

    DECLARE VARIABLE USER_NUM INTEGER;

    DECLARE VARIABLE DOC_NUM INTEGER;

    DECLARE VARIABLE EDITING CHAR (1);

    DECLARE VARIABLE APPENDING CHAR (1);

    DECLARE VARIABLE DELETING CHAR (1);

    BEGINIS_EDIT = 'F';

    IS_APPEND = 'F';

    IS_DELETE = 'F';

    IS_SHOW = 'F';

    FOR SELECT ID_NUM, ID_OWNERFROM DATA_LIST

    WHERE DATA_LIST.ID_NUM =: ID_DOC

    INTO TREE_NUMBER, TREE_OWNER

    DO

    BEGIN

    IF (TREE_NUMBER = UP_TREE) THEN EXIT;

    FOR SELECT ID_USER, ID_DOC, IS_EDIT, IS_APPEND, IS_DELETE

    FROM DOCS_USERS

    WHERE DOCS_USERS.ID_USER =: ID_USER

    INTO USER_NUM, DOC_NUM, EDITING, APPENDING, DELETING

    DO

    BEGIN

    IF (TREE_NUMBER = DOC_NUM) THEN

    BEGIN

    IS_EDIT = EDITING;

    IS_APPEND = APPENDING;

    IS_DELETE = DELETING;

    IS_SHOW = 'T';

    EXIT; END

    END

    ID_DOC = TREE_OWNER; END

    END!!

    SET TERM;!!

    Ця процедура використовується сервером додатків для перевірки прав користувача в таблиці у вигляді ієрархічного дерева. Зрозуміло, що визначити права користувача до окремого запису стандартними шляхами не можна, тому вся БД працює під управлінням сервера додатків і за допомогою DCOM дає інтерфейси клієнтам. Оскільки сервер додатків запущений в адресному просторі сервера, то такий підхід до Security можна вважати виправданим.

    UDF функції

    Звичайно, тут дають приклад, як порахувати яку-небудь математичну формулу, і повернути її результат як стовпчик відповіді на запит. Я ж вирішив показати приклад з рядками, тому що це перше, на чому зазвичай вперше спотикаються. Це лише приклад. У реальному БД такого не роблять. Отже, додамо до таблиці ACTIVITIES поле TREE_INFO VARCHAR (255). Будемо в ньому зберігати шлях від головного вузла. Цей шлях простіше всього будувати в тригері по додавання запису в таблицю. Але сама рядок з шляхом буде створюватися в DLL. Для початку оголосимо нащу функцію в DLL:

    DECLARE EXTERNAL FUNCTION CREATEPATH (CSTRING (256), INTEGER)

    RETURNS CSTRING (256)

    ENTRY_POINT "CreatePath"

    MODULE_NAME "UDF_INCL";

    Ми вказали ім'я в БД, що передаються переметри, що повертає значення, ім'я в DLL, і ім'я самої DLL. Ця бібліотека повинна знаходиться в каталозі UDF. У мене це D: Program FilesBorlandInterBaseUDF. А використовувати функцію будемо так:

    SET TERM!! ;

    CREATE TRIGGER INSERT_ACTIVITIES FOR ACTIVITIES

    BEFORE INSERT

    AS

    DECLARE VARIABLE PATH_TREE VARCHAR (256);

    BEGIN

    SELECT TREE_INFO

    FROM ACTIVITIESWHERE (NEW.ID_OWNER = ID_NUM)

    INTO PATH_TREE;

    NEW.TREE_INFO = CREATEPATH (PATH_TREE, NEW.ID_NUM);

    END!!

    SET TERM;!!

    У InterBase все UDF передають у параметрах посилання, тому рядок передають як покажчик. Використовуються VARCHAR рядки, тому що вони явно не доповнюються пробілами до максимальної довжини. Інакше, Ви б вже нічого до неї не додали. Ось реалізація DLL в Delphi:

    library UDF_INCL;

    //

    //

    // Copyright 2000 Bannikov N.A. Stikriz Technology

    //

    //

    uses

    SysUtils,

    Classes;

    ($ R *. RES)

    function CreatePath (MainPath: PChar; var IntVal: LongInt): PChar; cdecl; export;

    begin

    Result: = PChar (AnsiString (MainPath) + IntToStr (IntVal )+'');

    end;

    exports

    CreatePath;

    begin

    end.

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

    Банников Н.А. Створення баз даних в InterBase SQL Server.

    Для підготовки даної роботи були використані матеріали з сайту http://delphid.dax.ru .

         
     
         
    Реферат Банк
     
    Рефераты
     
    Бесплатные рефераты
     

     

     

     

     

     

     

     
     
     
      Все права защищены. Reff.net.ua - українські реферати ! DMCA.com Protection Status