Розробка бази даних та застосування для Інтернет-магазину комп'ютерної техніки

Розробка бази даних та застосування для Інтернет-магазину комп'ютерної техніки

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

ІНСТИТУТ СПЕЦІАЛЬНОГО ЗВ’ЯЗКУ ТА ЗАХИСТУ ІНФОРМАЦІЇ

НАЦІОНАЛЬНОГО ТЕХНІЧНОГО УНІВЕРСИТЕТУ УКРАЇНИ

КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ

Тема: Розробка бази даних та застосування для Інтренет-магазину комп’ютерної техніки

Пояснювальна записка

з дисципліни "Організація баз даних та знань - 1"

до курсової роботи за напрямом підготовки

.050101 - "Комп’ютерні науки"

Керівник курсової роботи

доцент каф. Я.Ю. Дорогий

Розробив студент гр. С16

Клименко М.А.

Київ 2012

Анотація

В результаті виконання курсової роботи з дисципліни "Організація баз даних та знань " студент показує свої знання в галузі проектування баз даних; вміння використовувати знання з захисту інформаційних ресурсів баз даних від порушення їх цілісності, доступності; вміння використовувати системний підхід до проектування баз даних; навички з аналізу предметної області; знання з моделювання баз даних за допомогою CASE-засобів; вміння розробляти застосування з використанням спроектованих БД; вміння обирати найкращу СКБД відповідно до заданого критерію.

Дана курсова робота ставить на меті розробити концептуальну модель БД, розробити логічну модель БД;,розробити фізичну модель БД за даною темою. Та показати навички та вміння користування програмою для створення БД : ERWin та Oracle 11G XE.

Темою даної курсової роботі є Інтернет-магазин Комп’ютерної техніки. Курсова робота та допоміжні лабораторні роботи дають можливість курсанту(слухачеві) побудувати власну модель Бази Даних та отримати навіки створення таких БД для майбутньої роботи.

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

Зміст

Вступ

. Концепція побудови БД

. Основні відомості про БД

. Аналіз предметної області

.1 Створення облікової анкети на сайті

.2 Пакет анкет для користувача

.3 Підсистема обробки запитів

. Концептуальна модель даних

. Інфологічна модель

.1 Первинні й зовнішні ключі

. Даталогічна модель

. Фізична модель

8. Проектування

8.1 Проектування логічної моделі даних

.2 Проектування фізичної моделі даних

. Побудова ER-моделей

Висновок

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

Додаток

Вступ

Сучасні інформаційні технології - це методи й засобу для збору, зберігання, обробки й одержання інформації на основі сучасних засобів обчислювальної техніки.

Складовими частинами будь-якої інформаційної системи є БД і застосування для обробки даних. Поява персональних машин, сімейства операційних систем Windows і різного програмного забезпечення дозволяють автоматизувати ручні операції, вести будь-які види робіт з накопичення інформації, її обробки й одержанню різних вихідних форм.

У курсовій роботі ставиться завдання - розробити проект бази даних для накопичення необхідної інформації в організації, створити (наповнити) базу даних. Розробити застосування, що дозволяє вести облік, контроль, а також одержувати різні вихідні документи. База даних повинна бути спроектована з урахуванням реалізації запитів різного типу.

Цілями проектування бази даних є:

. Ефективна структуризація інформації, що дозволяє заощадити час і гроші.

. Виключення або зведення до мінімуму повторюваних даних шляхом задання ефективної структури БД.

. Забезпечення всім користувачам швидкого доступу до інформації бази даних.

. Забезпечення розширення бази новими даними.

. Забезпечення цілісності даних.

. Запобігання несанкціонованого доступу до даних.

. Полегшення створення застосувань, призначених для введення, редагування, виводу даних, а також ведення звітності.

Реалізація всіх перерахованих вище завдань повинна покладатись на систему керування базами даних.

1. Концепція побудови БД

Існує два підходи до побудови БД, що базуються на двох підходах до створення автоматизованої системи управління <#"601052.files/image001.gif">

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

Зовнішні сутності:

Сайт. Тип виробничого об'єднання підприємства або Адміністратора. В цій ситуації сайт виступає як продавець. Вона дозволяє вибирати і замовляти комп’ютерний товар.

Клієнт. Людина, що зареєструвалася на сайті і потребує послуг сайту для покупки товару. Клієнт відсилає запит на реєстрування на сайті.

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

Робота модулів підсистеми:

Облік - форма запису інформації о користувачеві для подальшого користування послугами сайту.

Введення - набір інформації користувача для створення модуля «облік»

Перевірка - модуль, що отримує дані від модулю «введення» та перевіряє інформацію на вірність введення.

Обробка - модуль що отримує інформацію від модуля «Введення» та «Перевірка» та на висновках цього модуля обробляє всю інформацію и дає(чи не дає) змогу на реєструванні користувача в системі сайту.

Перегляд - модуль отриманій с модуля «Обробка» и дає змогу зберегти інформацію про користувача в базі даних системи сайту, а користувачеві дає змогу переглянути про себе інформації і вразі необхідності його редагувати на біль достовірну.

Підсистема «Формування корзини для товарів»:

Ця підсистема формує так звану «корзину» для зареєстрованих користувачів сайту, куди є можливість зберігати та купувати вибраний раніше товар з сайту. В корзині зберігається: код товару,номер користувача,ціна товару, коротка характеристика товару, та можливість зрівняння декількох вибраних раніше товарів в системі сайту.

Перевірки правильності введених даних:

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

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

3.2 Пакет анкет для користувача

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

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

Діаграма 1: Приклад таблиці порівняння

Структура створення облікового запису на сайті:

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

3.3 Підсистема обробки запитів

-   реєстрацію нових користувачів;

-          визначення прав доступу зареєстрованого користувача;

-          обробку запитів;

-          приймання реєстраційних даних від користувачів;

-          запис даних у БД Користувачів;

-          запис даних у БД зареєстрованих користувачів.

Відповідно до виконуваних функцій система працює з наступними даними:

реєстраційними даними користувачів;

особистими даними користувачів;

інформацією про користувача

ідентифікаційними даними користувачів;

інформацією про систему;

запитами;

службовою інформацією (для Адміністратора);

Визначення категорії - модуль, що визначає категорію користувача.

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

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

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

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

4. Концептуальна модель даних

Розглянемо виділення інформаційних об'єктів на даної предметної області " Інтернет магазин Комп’ютерної ".

У результаті аналізу предметної області виявляються документи-джерела даних для створення бази даних.

Довідкова інформація зберігається в документах: "Список Комп’ютерної техніки ", "Список Комплектуючих ", "Список Обладнання","Список Користувачів", "Список Схожих товарів".

Список Комп’ютерної техніки №

Кількість Комп’ютерної техніки _________

Список Комплектуючих №

Назва Фірми ________________ Назва Моделі ________________

Список Обладнання №

Список Користувачів №

Місце реєстрування ____________________________________

Список Схожих товарів №

Назва Фірми ____________________________________

Назва Моделі ___________________________________

Назва Обладнання _______________________________

Головним списком серед наведених вище є Список Комп’ютерної техніки та Список Користувачів, так як в список Комп’ютерної техніки є можливість розширити та занести короткі записи щодо інших Списків, а список Користувачів дає можливість відстежувати (зробити моніторинг) найчастіших відвідувачів та покупців сайту, і тоді звісно стає легше зробити інші маніпуляції (наприклад зробити скидку для окремого покупця (користувача)).

На сайті запитом буде виклик БД Користувачем. Покупець після реєстрації на сайті отримує всю інформацію про товари.

5. Інфологічна модель

У базах даних утримується інформація про об'єкти, що існують у реальному світі. Усі ці об'єкти є матеріальними та мають деякі властивості й поведінку. При створенні програмного продукту, властивості об'єктів зберігаються в базі даних, а їх поведінка реалізується в застосуванні за допомогою методів - процедур, які являють собою відгук на події, що ініціюються користувачем.

Інфологічна модель є проблемно-орієнтованою й системно-незалежною, тобто не залежить від конкретної СКБД, операційної системи й апаратного забезпечення ЕОМ.

Основною вимогою до інфологічної моделі, що випливають з її призначення, є вимога адекватного відображення предметної області. Інфологічна модель повинна бути несуперечливою. Вона є єдиним інтегрованим описом предметної області й відображає погляди й потреби всіх користувачів системи.

Інфологічна модель представляє інформаційні потоки, сутності й зв'язку даної предметної області. Вона може бути представлена у вигляді ER-моделі й реляційної схеми.

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

Центральним компонентом інфологічної моделі є опис об'єктів предметної області й зв'язків між ними (ER-модель).

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

Тому інфологічну модель даних намагаються будувати за аналогією з природною мовою (остання не може бути використана у чистому вигляді через складність комп'ютерної обробки текстів і неоднозначності будь-якої природної мови).

Основними конструктивними елементами інфологічної моделі є сутності, зв'язки між ними, ідентифікатори (ключі) та властивості (атрибути).

Сутність - кожний помітний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про який необхідно зберігати в базі даних.

Необхідно розрізняти такі поняття, як тип сутності й екземпляр сутності.

Екземпляр сутності відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути КОМП'ЮТЕР, а екземпляром - Asus, Acer і т.д.

Атрибут - пойменована характеристика сутності.

Його назва повинна бути унікальною для конкретного типу сутності, але може бути однаковою для різного типу сутностей

Абсолютна відмінність між типами сутностей і атрибутами відсутня.

Атрибут є таким тільки у зв'язку з типом сутності. В іншому контексті атрибут може виступати як самостійна сутність.

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

Зв'язок - асоціювання двох або більше сутностей. Якби призначенням бази даних було тільки зберігання окремих, не зв'язаних між собою даних, то її структура могла б бути дуже простою. Однак, одна з основних вимог до організації бази даних - це забезпечення можливості пошуку одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки.

При побудові інфологічних моделей можна використовувати мову ER- діаграм.

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

Між двома сутностям, наприклад, А и В можливі чотири види зв'язків.

Перший тип - зв'язок ОДИН-ДО-ОДНОГО (1:1): у кожний момент часу кожному представнику (екземпляру) сутності А відповідає 1 або 0 представників сутності В (рис.1).

Другий тип - зв'язок ОДИН-ДО-БАГАТЬОХ (1:М): одному представнику сутності А відповідають 0, 1 або декілька представників сутності В (рис. 2)

Так як між двома сутностями можливі зв'язки в обох напрямках, то існує ще два типи зв'язку БАГАТО-ДО-ОДНОГО (М:1) і БАГАТО-ДО-БАГАТЬОХ (М:N).

Класифікація сутностей:

У термінології сутностей К. Дейт визначає три основні класи сутностей: стрижневі, асоціативні й характеристичні, а також підклас асоціативних сутностей - позначення.

Стрижнева сутність (стрижень) - це незалежна сутність.

У розглянутих раніше прикладах стрижні - це "Курсант", "Казарма", назви які поміщені в прямокутники.

Асоціативна сутність (асоціація) - це зв'язок виду "багато-до-багатьох" між двома або більше сутностями або екземплярами сутності. Асоціації розглядаються як повноправні сутності; вони можуть брати участь в інших асоціаціях і позначеннях в такий же спосіб, як і стрижневі сутності

Характеристична сутність (характеристика) - це зв'язок виду "багато-до-одного" або " один-до-одного" між двома сутностями (окремий випадок асоціації). Єдина мета характеристики в рамках розглянутої предметної області полягає в описі або уточненні деякої іншої сутності.

Елементи розширеної мови ER-Діаграм зображені на рис.3:

Позначення й характеристики не є повністю незалежними сутностями, оскільки вони припускають наявність деякої іншої сутності, яка буде "позначатися" або "характеризуватися". Однак вони все-таки являють собою окремі випадки сутності й можуть, звичайно, мати властивості, можуть брати участь в асоціаціях, позначеннях і мати свої власні (більш низького рівня) характеристики.

5.1 Первинні й зовнішні ключі

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

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

Кожна сутність має хоча б один можливий ключ. Один з них вибирається первинним ключем.

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

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

Зовнішні ключі. Якщо сутність С зв'язує сутності А і В, то вона повинна включати зовнішні ключі, відповідні до первинних ключів сутностей А і В.

Якщо сутність В позначає сутність А, то вона повинна включати зовнішній ключ, відповідний до первинного ключа сутності А.

Зв'язок між первинними та зовнішніми ключами сутностей ілюструється рис. 4.

Обмеження цілісності:

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

Рис. 4.

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

Виділяють три групи правил цілісності:

цілісність за сутностями;

цілісність за посиланнями;

цілісність, обумовлена користувачем.

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

Значення зовнішнього ключа повинно або:

бути рівним значенню первинного ключа мети;

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

Для будь-якої конкретної бази даних існує ряд додаткових специфічних правил, які ставляться до неї однієї й визначаються розробником.

Побудова інфологічної моделі:

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

6. Даталогічна модель

Даталогічна модель є моделлю логічного рівня і являє собою відображення логічних зв'язків між елементами даних безвідносно до їхнього змісту й середовищу зберігання.

Ця модель будується в термінах інформаційних одиниць, припустимих у тій конкретній СКБД, у середовищі якої проектується база даних. Етап створення даталогічної моделі називається даталогічним проектуванням. Опис логічної структури бази даних мовою СКБД називається схемою.

Хоча даталогічне проектування є логічною структурою бази даних, на нього впливають можливості фізичної організації даних, що представляються конкретною БД. Тому знання особливостей фізичної організації даних є корисним при проектуванні логічної структури.

Для даної курсової роботи даталогічна модель зображена на рис. 5, в ній вказана структура роботи Інтернет-магазину, за допомогою цієї структури можлива більш вірна побудова та наглядність БД.

Рис. 5. Даталогічна модель БД

7. Фізична модель

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

Для прив'язки даталогічної моделі до середовища зберігання використовується модель даних фізичного рівня (для стислості часто називається фізичною моделлю). Ця модель визначає використовувані запам'ятовувальні пристрої, способи фізичної організації даних у середовищі зберігання. Модель фізичного рівня також будується з урахуванням можливостей, що представляються СКБД. Опис фізичної структури бази даних називається схемою зберігання. Відповідний етап проектування бази даних називається фізичним проектуванням. Основним завданням цього етапу проектування є визначення відповідності типів логічної моделі даних до типів даних, що використовуються у потрібній СКБД.

8. Проектування

база сайт інтернет магазин

8.1 Проектування логічної моделі даних

Для створення інтернет-магазину, та БД для цього сайту потрібно мати 8 сутностей, такі як:

. Фірма;

. Модель;

. Комплектація;

. Обладнання;

. Користувач;

. Корзина;

. Схожі товари;

. Новинки;

Всі ці сутності дають змогу створити гідний сайт и також БД для Адміністратора. Кожна з цих сутностей буде мати свою БД для моніторингу та корекції.

Атрибути сутності «Фірма»:

Атрибути сутності «Модель»:

Атрибути сутності «Комплектуючі»:

Атрибути сутності «Обладнання»:

Атрибути сутності «Схожі товари»:

Атрибути сутності «Новинки»:

Атрибути сутності «Користувач»:

Атрибути сутності «Корзина»:

Дані таблиці будуть маті наступній вигляд в ER-діаграмі:

При проведенні зв'язку між сутностями первинний ключ мігрує в дочірню сутність.

Наступним етапом при побудові логічної моделі є визначення ключових атрибутів і типів атрибутів:

8.2 Проектування фізичної моделі даних

Метою створення фізичної моделі є забезпечення адміністратора відповідною інформацією для переносу логічної моделі даних у СКБД.

Erwin підтримує автоматичну генерацію фізичної моделі даних для конкретної СКБД. При цьому логічна модель трансформується у фізичну за наступним принципом: сутності стають таблицями, атрибути стають стовпцями, а ключі стають індексами.

Для даної курсової роботи така модель буде виглядати так:

Отримана фізична модель даних:

9. Побудова ER-моделі

Бази Даних в CASE <#"601052.files/image027.gif">

Висновок

Таким чином, дана курсова робота дала змогу побудувати ER-модель для заданої тематики «Інтернет-магазин комп’ютерної техніки», і побачити як повинна виглядати БД для різних закладів і підприємств.

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

Наступним етапом було створення проектування концептуальної моделі даних, в якому створюємо додаткову інформацію в вигляді списків. Ця інформація розроблена для моніторингу системи в цілому.

Третій етап є створення інфологічної моделі,яка відображає предметну область, а точніше опис предметної області й відображає погляди й потреби всіх користувачів системи. Метою побудови цієї структури є виявлення й об'єднання інформаційних вимог користувача, зв'язків між елементами даних без врахування їх змісту й середовища їх зберігання. Центральним компонентом інфологічної моделі є опис об'єктів предметної області й зв'язків між ними (ER-модель). Інфологічна модель представляє інформаційні потоки, сутності й зв'язку даної предметної області. Вона може бути представлена у вигляді ER-моделі й реляційної схеми. Також в ній класифікуються сутності та визначаються первинні й зовнішні ключі,які використаються в даній роботі.

Четвертий етап - побудова даталогічної моделі. Ця модель є моделлю логічного рівня і являє собою відображення логічних зв'язків між елементами даних безвідносно до їхнього змісту й середовищу зберігання.

П’ятий етап - це побудова фізичної моделі. Модель являє собою таблицю, кожний рядок якої (запис) містить деякі відомості про описуваний об'єкт. Всі записи бази даних мають ідентичну, задану користувачем структуру й розміри. Модель фізичного рівня також будується з урахуванням можливостей, що представляються СКБД.

Наступний шостий етап являє собою проектування логічної і фізичної моделі, визначення в них атрибутів сутностей, тип та розмір.

Сьомий етап безпосередньо побудова ER-моделі в CASE <http://ru.wikipedia.org/wiki/CASE>-засобі для проектування й документування баз даних <http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85> AllFusion ERwin Data Modeler, та представлення в даній курсовій роботі скриншотів вже побудованої, готової для використання, бази даних.

Основним результатом є правильно побудовані різні типи моделі даних і аналізована предметна область для Бази Даних, вивчені основні цілі проектування бази даних та виконані основні завдання курсової роботи - розробити проект бази даних для накопичення необхідної інформації в організації, створити базу даних. Розроблена застосування, що дозволяє вести облік, контроль, а також одержувати різні вихідні документи. База даних повинна бути спроектована з урахуванням реалізації запитів різного типу.

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

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

Як було сказано раніше, ця база даних може реалізуватися в реальному Інтернет-магазині та спокійно використатися Адміністратором цього сайту та його помічниками і користувачами. А як наведено було в мінусі БД, перспективою є розширення и нормалізація цієї бази даних для більшої наглядності як і Адміністратором так і користувачем.

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

1. Методичні вказівки до виконання курсової роботи з дисципліни "Організація баз даних та знань - 1" / Я.Ю. Дорогий.

. Савчук Т.О. Організація баз даних і знань. − Вінниця: ВДТУ, 2000.

3. Степанов Ю.Л. Разработка приложений баз данных для СУБД.

4. Вінер Н. Бази даних. − М.: Наука, 1993.

Додаток

SQL-код БДTABLE Firm

(_firm VARCHAR2(200) NOT NULL,_modeli NUMBER(30) NOT NULL,_firm VARCHAR2(200) NULL,_firm NUMBER(30) NOT NULL,

kod_komplektuechego NUMBER(30) NOT NULL,

kod_obladnya NUMBER(30) NOT NULL,VARCHAR2(200) NOT NULL,VARCHAR2(200) NOT NULL,_tovary NUMBER(30) NOT NULL,_models VARCHAR2(200) NOT NULL

);UNIQUE INDEX XPKФірма ON Firm

(kod_firm ASC,kod_modeli ASC,kod_komplektuechego ASC,kod_obladnya ASC,name ASC,familia ASC,name_firm ASC,name_models ASC);TABLE FirmCONSTRAINT XPKФірма PRIMARY KEY (kod_firm,kod_modeli,kod_komplektuechego,kod_obladnya,name,familia,name_firm,name_models);TABLE Komplektuechi

(_firm VARCHAR2(200) NULL,_models VARCHAR2(200) NULL,_models NUMBER(30) NOT NULL,_komplektuechego VARCHAR2(200) NULL,

kod_komplektuechego NUMBER(30) NOT NULL,

Price CHAR(18) NULL,_firm NUMBER(30) NOT NULL,_obladnenya NUMBER(30) NOT NULL

);UNIQUE INDEX XPKКомплектуючі ON Komplektuechi

(kod_firm ASC,kod_models ASC,kod_komplektuechego ASC,kod_obladnenya ASC);TABLE KomplektuechiCONSTRAINT XPKКомплектуючі PRIMARY KEY (kod_firm,kod_models,kod_komplektuechego,kod_obladnenya);TABLE Koristyvach

(VARCHAR2(200) NOT NULL,VARCHAR2(200) NOT NULL,_Rogdenia DATE NULL,_progivania NUMBER(30) NULL,VARCHAR2(200) NULL,_firn NUMBER(30) NOT NULL

);UNIQUE INDEX XPKКористувач ON Koristyvach

(Name ASC,Familia ASC,kod_firn ASC);TABLE KoristyvachCONSTRAINT XPKКористувач PRIMARY KEY (Name,Familia,kod_firn);TABLE Korzina

(_tovary NUMBER(30) NULL,_tovary VARCHAR2(200) NULL,_firm VARCHAR2(200) NULL,_firm NUMBER(30) NOT NULL,CHAR(18) NULL

);UNIQUE INDEX XPKКорзина ON Korzina

(kod_firm ASC);TABLE KorzinaCONSTRAINT XPKКорзина PRIMARY KEY (kod_firm);TABLE Models

(_modely NUMBER(30) NOT NULL,_Firm VARCHAR2(200) NULL,_models VARCHAR2(200) NULL,CHAR(18) NULL,_firm NUMBER(30) NOT NULL,_komplektuechgo NUMBER(30) NOT NULL,_obladnya NUMBER(30) NOT NULL,VARCHAR2(2500) NULL

);UNIQUE INDEX XPKМодель ON Models

(kod_modely ASC,kod_firm ASC,kod_komplektuechgo ASC,kod_obladnya ASC);TABLE ModelsCONSTRAINT XPKМодель PRIMARY KEY (kod_modely,kod_firm,kod_komplektuechgo,kod_obladnya);TABLE News

(_firm VARCHAR2(200) NOT NULL,_models VARCHAR2(200) NOT NULL,INTERVAL YEAR TO MONTH NULL,CHAR(18) NULL

);UNIQUE INDEX XPKНовинки ON News

(Name_firm ASC,Name_models ASC);TABLE NewsCONSTRAINT XPKНовинки PRIMARY KEY (Name_firm,Name_models);TABLE Obladnenya

(_obladnenya NUMBER(30) NOT NULL,_obladnenya VARCHAR2(200) NULL,CHAR(18) NULL

);UNIQUE INDEX XPKОбладнення ON Obladnenya

(kod_obladnenya ASC);TABLE ObladnenyaCONSTRAINT XPKОбладнення PRIMARY KEY (kod_obladnenya);TABLE ObladnenyaCONSTRAINT Инв._номер UNIQUE (kod_obladnenya);TABLE Shogi_tovary

(_Firm VARCHAR2(200) NOT NULL,_tovary VARCHAR2(200) NULL,_firm NUMBER(30) NOT NULL,_tovary NUMBER(30) NOT NULL,CHAR(18) NULL,_models VARCHAR2(200) NOT NULL

);UNIQUE INDEX XPKСхожі_Товари ON Shogi_tovary

(Name_Firm ASC,kod_firm ASC,kod_tovary ASC,Name_models ASC);TABLE Shogi_tovaryCONSTRAINT XPKСхожі_Товари PRIMARY KEY (Name_Firm,kod_firm,kod_tovary,Name_models);TABLE Firm(CONSTRAINT R_1 FOREIGN KEY (kod_modeli, kod_firm, kod_komplektuechego, kod_obladnya) REFERENCES Models (kod_modely, kod_firm, kod_komplektuechgo, kod_obladnya));TABLE Firm(CONSTRAINT R_5 FOREIGN KEY (name, familia, kod_firm) REFERENCES Koristyvach (Name, Familia, kod_firn));TABLE Firm(CONSTRAINT R_7 FOREIGN KEY (name_firm, kod_firm, kod_tovary, name_models) REFERENCES Shogi_tovary (Name_Firm, kod_firm, kod_tovary, Name_models));TABLE Komplektuechi(CONSTRAINT R_3 FOREIGN KEY (kod_obladnenya) REFERENCES Obladnenya (kod_obladnenya))TABLE Koristyvach(CONSTRAINT R_4 FOREIGN KEY (kod_firn) REFERENCES Korzina (kod_firm));TABLE Models(CONSTRAINT R_2 FOREIGN KEY (kod_firm, kod_modely, kod_komplektuechgo, kod_obladnya) REFERENCES Komplektuechi (kod_firm, kod_models, kod_komplektuechego, kod_obladnenya));TABLE Shogi_tovary(CONSTRAINT R_6 FOREIGN KEY (Name_Firm, Name_models) REFERENCES News (Name_firm, Name_models));TRIGGER tI_Firm BEFORE INSERT ON Firm for each row

- ERwin Builtin Trigger

- INSERT trigger on FirmNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Models Firm on child insert restrict */

/* ERWIN_RELATION:CHECKSUM="0003b9bb", PARENT_OWNER="", PARENT_TABLE="Models"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_1", FK_COLUMNS="kod_modeli""kod_firm""kod_komplektuechego""kod_obladnya" */

SELECT count(*) INTO NUMROWSModels

/*%JoinFKPK(:%New,Models," = "," AND") */

:new.kod_modeli = Models.kod_modely AND

:new.kod_firm = Models.kod_firm AND

:new.kod_komplektuechego = Models.kod_komplektuechgo AND

:new.kod_obladnya = Models.kod_obladnya;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot insert Firm because Models does not exist.'

);IF;

/* ERwin Builtin Trigger */

/* Koristyvach Firm on child insert restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="Koristyvach"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_5", FK_COLUMNS="name""familia""kod_firm" */count(*) INTO NUMROWSKoristyvach

/*%JoinFKPK(:%New,Koristyvach," = "," AND") */

:new.name = Koristyvach.Name AND

:new.familia = Koristyvach.Familia AND

:new.kod_firm = Koristyvach.kod_firn;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot insert Firm because Koristyvach does not exist.'

);IF;

/* ERwin Builtin Trigger */

/* Shogi_tovary Firm on child insert restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="Shogi_tovary"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_7", FK_COLUMNS="name_firm""kod_firm""kod_tovary""name_models" */count(*) INTO NUMROWSShogi_tovary

/*%JoinFKPK(:%New,Shogi_tovary," = "," AND") */

:new.name_firm = Shogi_tovary.Name_Firm AND

:new.kod_firm = Shogi_tovary.kod_firm AND

:new.kod_tovary = Shogi_tovary.kod_tovary AND

:new.name_models = Shogi_tovary.Name_models;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot insert Firm because Shogi_tovary does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_Firm AFTER UPDATE ON Firm for each row

- ERwin Builtin Trigger

- UPDATE trigger on FirmNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Models Firm on child update restrict */

/* ERWIN_RELATION:CHECKSUM="0003a835", PARENT_OWNER="", PARENT_TABLE="Models"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_1", FK_COLUMNS="kod_modeli""kod_firm""kod_komplektuechego""kod_obladnya" */

SELECT count(*) INTO NUMROWSModels

/*%JoinFKPK(:%New,Models," = "," AND") */

:new.kod_modeli = Models.kod_modely AND

:new.kod_firm = Models.kod_firm AND

:new.kod_komplektuechego = Models.kod_komplektuechgo AND

:new.kod_obladnya = Models.kod_obladnya;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

);IF;

/* ERwin Builtin Trigger */

/* Koristyvach Firm on child update restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="Koristyvach"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_5", FK_COLUMNS="name""familia""kod_firm" */count(*) INTO NUMROWSKoristyvach

/*%JoinFKPK(:%New,Koristyvach," = "," AND") */

:new.name = Koristyvach.Name AND

:new.familia = Koristyvach.Familia AND

:new.kod_firm = Koristyvach.kod_firn;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot update Firm because Koristyvach does not exist.'

);IF;

/* ERwin Builtin Trigger */

/* Shogi_tovary Firm on child update restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="Shogi_tovary"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_7", FK_COLUMNS="name_firm""kod_firm""kod_tovary""name_models" */count(*) INTO NUMROWSShogi_tovary

/*%JoinFKPK(:%New,Shogi_tovary," = "," AND") */

:new.name_firm = Shogi_tovary.Name_Firm AND

:new.kod_firm = Shogi_tovary.kod_firm AND

:new.kod_tovary = Shogi_tovary.kod_tovary AND

:new.name_models = Shogi_tovary.Name_models;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot update Firm because Shogi_tovary does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tI_Komplektuechi BEFORE INSERT ON Komplektuechi for each row

- ERwin Builtin Trigger

- INSERT trigger on KomplektuechiNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Obladnenya Komplektuechi on child insert restrict */

/* ERWIN_RELATION:CHECKSUM="000104c6", PARENT_OWNER="", PARENT_TABLE="Obladnenya"_OWNER="", CHILD_TABLE="Komplektuechi"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_3", FK_COLUMNS="kod_obladnenya" */

SELECT count(*) INTO NUMROWSObladnenya

/*%JoinFKPK(:%New,Obladnenya," = "," AND") */

:new.kod_obladnenya = Obladnenya.kod_obladnenya;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot insert Komplektuechi because Obladnenya does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tD_Komplektuechi AFTER DELETE ON Komplektuechi for each row

- ERwin Builtin Trigger

- DELETE trigger on KomplektuechiNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Komplektuechi Models on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM="000124b7", PARENT_OWNER="", PARENT_TABLE="Komplektuechi"_OWNER="", CHILD_TABLE="Models"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_2", FK_COLUMNS="kod_firm""kod_modely""kod_komplektuechgo""kod_obladnya" */

SELECT count(*) INTO NUMROWSModels

/*%JoinFKPK(Models,:%Old," = "," AND") */.kod_firm = :old.kod_firm AND.kod_modely = :old.kod_models AND.kod_komplektuechgo = :old.kod_komplektuechego AND.kod_obladnya = :old.kod_obladnenya;(NUMROWS > 0)_application_error(

,

'Cannot delete Komplektuechi because Models exists.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_Komplektuechi AFTER UPDATE ON Komplektuechi for each row

- ERwin Builtin Trigger

- UPDATE trigger on KomplektuechiNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Komplektuechi Models on parent update restrict */

/* ERWIN_RELATION:CHECKSUM="0002b5fc", PARENT_OWNER="", PARENT_TABLE="Komplektuechi"_OWNER="", CHILD_TABLE="Models"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_2", FK_COLUMNS="kod_firm""kod_modely""kod_komplektuechgo""kod_obladnya" */

IF

/*%JoinPKPK(:%Old,:%New," <> "," OR ") */

:old.kod_firm <> :new.kod_firm OR

:old.kod_models <> :new.kod_models OR

:old.kod_komplektuechego <> :new.kod_komplektuechego OR

:old.kod_obladnenya <> :new.kod_obladnenya

THENcount(*) INTO NUMROWSModels

/*%JoinFKPK(Models,:%Old," = "," AND") */.kod_firm = :old.kod_firm AND.kod_modely = :old.kod_models AND.kod_komplektuechgo = :old.kod_komplektuechego AND.kod_obladnya = :old.kod_obladnenya;(NUMROWS > 0)_application_error(

,

'Cannot update Komplektuechi because Models exists.'

);IF;IF;

/* ERwin Builtin Trigger */

/* Obladnenya Komplektuechi on child update restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="Obladnenya"_OWNER="", CHILD_TABLE="Komplektuechi"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_3", FK_COLUMNS="kod_obladnenya" */

SELECT count(*) INTO NUMROWSObladnenya

/*%JoinFKPK(:%New,Obladnenya," = "," AND") */

:new.kod_obladnenya = Obladnenya.kod_obladnenya;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot update Komplektuechi because Obladnenya does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tI_Koristyvach BEFORE INSERT ON Koristyvach for each row

- ERwin Builtin Trigger

- INSERT trigger on KoristyvachNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Korzina Koristyvach on child insert restrict */

/* ERWIN_RELATION:CHECKSUM="0000e9b6", PARENT_OWNER="", PARENT_TABLE="Korzina"_OWNER="", CHILD_TABLE="Koristyvach"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_4", FK_COLUMNS="kod_firn" */count(*) INTO NUMROWSKorzina

/*%JoinFKPK(:%New,Korzina," = "," AND") */

:new.kod_firn = Korzina.kod_firm;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot insert Koristyvach because Korzina does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tD_Koristyvach AFTER DELETE ON Koristyvach for each row

- ERwin Builtin Trigger

- DELETE trigger on KoristyvachNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Koristyvach Firm on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM="0000ec92", PARENT_OWNER="", PARENT_TABLE="Koristyvach"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_5", FK_COLUMNS="name""familia""kod_firm" */count(*) INTO NUMROWSFirm

/*%JoinFKPK(Firm,:%Old," = "," AND") */.name = :old.Name AND.familia = :old.Familia AND.kod_firm = :old.kod_firn;(NUMROWS > 0)_application_error(

,

'Cannot delete Koristyvach because Firm exists.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_Koristyvach AFTER UPDATE ON Koristyvach for each row

- ERwin Builtin Trigger

- UPDATE trigger on KoristyvachNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Koristyvach Firm on parent update restrict */

/* ERWIN_RELATION:CHECKSUM="00023bc0", PARENT_OWNER="", PARENT_TABLE="Koristyvach"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_5", FK_COLUMNS="name""familia""kod_firm" */

/*%JoinPKPK(:%Old,:%New," <> "," OR ") */

:old.Name <> :new.Name OR

:old.Familia <> :new.Familia OR

:old.kod_firn <> :new.kod_firncount(*) INTO NUMROWSFirm

/*%JoinFKPK(Firm,:%Old," = "," AND") */.name = :old.Name AND.familia = :old.Familia AND.kod_firm = :old.kod_firn;(NUMROWS > 0)_application_error(

,

'Cannot update Koristyvach because Firm exists.'

);IF;IF;

/* ERwin Builtin Trigger */

/* Korzina Koristyvach on child update restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="Korzina"_OWNER="", CHILD_TABLE="Koristyvach"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_4", FK_COLUMNS="kod_firn" */count(*) INTO NUMROWSKorzina

/*%JoinFKPK(:%New,Korzina," = "," AND") */

:new.kod_firn = Korzina.kod_firm;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot update Koristyvach because Korzina does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tD_Korzina AFTER DELETE ON Korzina for each row

- ERwin Builtin Trigger

- DELETE trigger on KorzinaNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Korzina Koristyvach on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM="0000d7be", PARENT_OWNER="", PARENT_TABLE="Korzina"_OWNER="", CHILD_TABLE="Koristyvach"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_4", FK_COLUMNS="kod_firn" */count(*) INTO NUMROWSKoristyvach

/*%JoinFKPK(Koristyvach,:%Old," = "," AND") */.kod_firn = :old.kod_firm;(NUMROWS > 0)_application_error(

,

'Cannot delete Korzina because Koristyvach exists.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_Korzina AFTER UPDATE ON Korzina for each row

- ERwin Builtin Trigger

- UPDATE trigger on KorzinaNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Korzina Koristyvach on parent update restrict */

/* ERWIN_RELATION:CHECKSUM="0001065b", PARENT_OWNER="", PARENT_TABLE="Korzina"_OWNER="", CHILD_TABLE="Koristyvach"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_4", FK_COLUMNS="kod_firn" */

/*%JoinPKPK(:%Old,:%New," <> "," OR ") */

:old.kod_firm <> :new.kod_firmcount(*) INTO NUMROWSKoristyvach

/*%JoinFKPK(Koristyvach,:%Old," = "," AND") */.kod_firn = :old.kod_firm;(NUMROWS > 0)_application_error(

,

'Cannot update Korzina because Koristyvach exists.'

);IF;IF;

- ERwin Builtin Trigger;

/TRIGGER tI_Models BEFORE INSERT ON Models for each row

- ERwin Builtin Trigger

- INSERT trigger on ModelsNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Komplektuechi Models on child insert restrict */

/* ERWIN_RELATION:CHECKSUM="00015c81", PARENT_OWNER="", PARENT_TABLE="Komplektuechi"_OWNER="", CHILD_TABLE="Models"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_2", FK_COLUMNS="kod_firm""kod_modely""kod_komplektuechgo""kod_obladnya" */

SELECT count(*) INTO NUMROWSKomplektuechi

/*%JoinFKPK(:%New,Komplektuechi," = "," AND") */

:new.kod_firm = Komplektuechi.kod_firm AND

:new.kod_modely = Komplektuechi.kod_models AND

:new.kod_komplektuechgo = Komplektuechi.kod_komplektuechego AND

:new.kod_obladnya = Komplektuechi.kod_obladnenya;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot insert Models because Komplektuechi does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tD_Models AFTER DELETE ON Models for each row

- ERwin Builtin Trigger

- DELETE trigger on ModelsNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Models Firm on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM="00012069", PARENT_OWNER="", PARENT_TABLE="Models"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_1", FK_COLUMNS="kod_modeli""kod_firm""kod_komplektuechego""kod_obladnya" */

SELECT count(*) INTO NUMROWSFirm

/*%JoinFKPK(Firm,:%Old," = "," AND") */.kod_modeli = :old.kod_modely AND.kod_firm = :old.kod_firm AND

Firm.kod_komplektuechego = :old.kod_komplektuechgo AND.kod_obladnya = :old.kod_obladnya;

IF (NUMROWS > 0)_application_error(

,

'Cannot delete Models because Firm exists.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_Models AFTER UPDATE ON Models for each row

- ERwin Builtin Trigger

- UPDATE trigger on ModelsNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Models Firm on parent update restrict */

/* ERWIN_RELATION:CHECKSUM="0002e12e", PARENT_OWNER="", PARENT_TABLE="Models"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_1", FK_COLUMNS="kod_modeli""kod_firm""kod_komplektuechego""kod_obladnya" */

IF

/*%JoinPKPK(:%Old,:%New," <> "," OR ") */

:old.kod_modely <> :new.kod_modely OR

:old.kod_firm <> :new.kod_firm OR

:old.kod_komplektuechgo <> :new.kod_komplektuechgo OR

:old.kod_obladnya <> :new.kod_obladnya

THENcount(*) INTO NUMROWSFirm

/*%JoinFKPK(Firm,:%Old," = "," AND") */.kod_modeli = :old.kod_modely AND.kod_firm = :old.kod_firm AND

Firm.kod_komplektuechego = :old.kod_komplektuechgo AND.kod_obladnya = :old.kod_obladnya;

IF (NUMROWS > 0)_application_error(

,

'Cannot update Models because Firm exists.'

);IF;IF;

/* ERwin Builtin Trigger */

/* Komplektuechi Models on child update restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="Komplektuechi"_OWNER="", CHILD_TABLE="Models"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_2", FK_COLUMNS="kod_firm""kod_modely""kod_komplektuechgo""kod_obladnya" */

SELECT count(*) INTO NUMROWSKomplektuechi

/*%JoinFKPK(:%New,Komplektuechi," = "," AND") */

:new.kod_firm = Komplektuechi.kod_firm AND

:new.kod_modely = Komplektuechi.kod_models AND

:new.kod_komplektuechgo = Komplektuechi.kod_komplektuechego AND

:new.kod_obladnya = Komplektuechi.kod_obladnenya;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot update Models because Komplektuechi does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tD_News AFTER DELETE ON News for each row

- ERwin Builtin Trigger

- DELETE trigger on NewsNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* News Shogi_tovary on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM="0000f5bf", PARENT_OWNER="", PARENT_TABLE="News"_OWNER="", CHILD_TABLE="Shogi_tovary"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_6", FK_COLUMNS="Name_Firm""Name_models" */count(*) INTO NUMROWSShogi_tovary

/*%JoinFKPK(Shogi_tovary,:%Old," = "," AND") */_tovary.Name_Firm = :old.Name_firm AND_tovary.Name_models = :old.Name_models;(NUMROWS > 0)_application_error(

,

'Cannot delete News because Shogi_tovary exists.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_News AFTER UPDATE ON News for each row

- ERwin Builtin Trigger

- UPDATE trigger on NewsNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* News Shogi_tovary on parent update restrict */

/* ERWIN_RELATION:CHECKSUM="00012959", PARENT_OWNER="", PARENT_TABLE="News"_OWNER="", CHILD_TABLE="Shogi_tovary"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_6", FK_COLUMNS="Name_Firm""Name_models" */

/*%JoinPKPK(:%Old,:%New," <> "," OR ") */

:old.Name_firm <> :new.Name_firm OR

:old.Name_models <> :new.Name_modelscount(*) INTO NUMROWSShogi_tovary

/*%JoinFKPK(Shogi_tovary,:%Old," = "," AND") */_tovary.Name_Firm = :old.Name_firm AND_tovary.Name_models = :old.Name_models;(NUMROWS > 0)_application_error(

,

'Cannot update News because Shogi_tovary exists.'

);IF;IF;

- ERwin Builtin Trigger;

/TRIGGER tD_Obladnenya AFTER DELETE ON Obladnenya for each row

- ERwin Builtin Trigger

- DELETE trigger on ObladnenyaNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Obladnenya Komplektuechi on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM="0000f377", PARENT_OWNER="", PARENT_TABLE="Obladnenya"_OWNER="", CHILD_TABLE="Komplektuechi"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_3", FK_COLUMNS="kod_obladnenya" */

SELECT count(*) INTO NUMROWSKomplektuechi

/*%JoinFKPK(Komplektuechi,:%Old," = "," AND") */.kod_obladnenya = :old.kod_obladnenya;(NUMROWS > 0)_application_error(

,

'Cannot delete Obladnenya because Komplektuechi exists.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_Obladnenya AFTER UPDATE ON Obladnenya for each row

- ERwin Builtin Trigger

- UPDATE trigger on ObladnenyaNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Obladnenya Komplektuechi on parent update restrict */

/* ERWIN_RELATION:CHECKSUM="00011a77", PARENT_OWNER="", PARENT_TABLE="Obladnenya"_OWNER="", CHILD_TABLE="Komplektuechi"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",_CONSTRAINT="R_3", FK_COLUMNS="kod_obladnenya" */

IF

/*%JoinPKPK(:%Old,:%New," <> "," OR ") */

:old.kod_obladnenya <> :new.kod_obladnenyacount(*) INTO NUMROWSKomplektuechi

/*%JoinFKPK(Komplektuechi,:%Old," = "," AND") */.kod_obladnenya = :old.kod_obladnenya;(NUMROWS > 0)_application_error(

,

'Cannot update Obladnenya because Komplektuechi exists.'

);IF;IF;

- ERwin Builtin Trigger;

/TRIGGER tI_Shogi_tovary BEFORE INSERT ON Shogi_tovary for each row

- ERwin Builtin Trigger

- INSERT trigger on Shogi_tovaryNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* News Shogi_tovary on child insert restrict */

/* ERWIN_RELATION:CHECKSUM="0000fd9a", PARENT_OWNER="", PARENT_TABLE="News"_OWNER="", CHILD_TABLE="Shogi_tovary"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_6", FK_COLUMNS="Name_Firm""Name_models" */count(*) INTO NUMROWSNews

/*%JoinFKPK(:%New,News," = "," AND") */

:new.Name_Firm = News.Name_firm AND

:new.Name_models = News.Name_models;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot insert Shogi_tovary because News does not exist.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tD_Shogi_tovary AFTER DELETE ON Shogi_tovary for each row

- ERwin Builtin Trigger

- DELETE trigger on Shogi_tovaryNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Shogi_tovary Firm on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM="0001114b", PARENT_OWNER="", PARENT_TABLE="Shogi_tovary"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_7", FK_COLUMNS="name_firm""kod_firm""kod_tovary""name_models" */count(*) INTO NUMROWSFirm

/*%JoinFKPK(Firm,:%Old," = "," AND") */.name_firm = :old.Name_Firm AND.kod_firm = :old.kod_firm AND.kod_tovary = :old.kod_tovary AND.name_models = :old.Name_models;(NUMROWS > 0)_application_error(

,

'Cannot delete Shogi_tovary because Firm exists.'

);IF;

- ERwin Builtin Trigger;

/TRIGGER tU_Shogi_tovary AFTER UPDATE ON Shogi_tovary for each row

- ERwin Builtin Trigger

- UPDATE trigger on Shogi_tovaryNUMROWS INTEGER;

/* ERwin Builtin Trigger */

/* Shogi_tovary Firm on parent update restrict */

/* ERWIN_RELATION:CHECKSUM="00028ee1", PARENT_OWNER="", PARENT_TABLE="Shogi_tovary"_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_7", FK_COLUMNS="name_firm""kod_firm""kod_tovary""name_models" */

/*%JoinPKPK(:%Old,:%New," <> "," OR ") */

:old.Name_Firm <> :new.Name_Firm OR

:old.kod_firm <> :new.kod_firm OR

:old.kod_tovary <> :new.kod_tovary OR

:old.Name_models <> :new.Name_modelscount(*) INTO NUMROWSFirm

/*%JoinFKPK(Firm,:%Old," = "," AND") */.name_firm = :old.Name_Firm AND.kod_firm = :old.kod_firm AND.kod_tovary = :old.kod_tovary AND.name_models = :old.Name_models;(NUMROWS > 0)_application_error(

,

'Cannot update Shogi_tovary because Firm exists.'

/* ERwin Builtin Trigger */

/* News Shogi_tovary on child update restrict */

/* ERWIN_RELATION:CHECKSUM="00000000", PARENT_OWNER="", PARENT_TABLE="News"_OWNER="", CHILD_TABLE="Shogi_tovary"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_6", FK_COLUMNS="Name_Firm""Name_models" */count(*) INTO NUMROWSNews

/*%JoinFKPK(:%New,News," = "," AND") */

:new.Name_Firm = News.Name_firm AND

:new.Name_models = News.Name_models;(

/*%NotnullFK(:%New," IS NOT NULL AND") */= 0

)_application_error(

,

'Cannot update Shogi_tovary because News does not exist.'

);IF;

- ERwin Builtin Trigger;

/