Розробка бази даних та застосування для інтернет-магазину продажу музичних інструментів
Розробка бази
даних та застосування для інтернет-магазину продажу музичних інструментів
Пояснювальна записка
з дисципліни «Організація баз даних та знань-1»
до курсової роботи за напрямком підготовки
.050101 - «Комп’ютерні науки»
Керівник курсової роботи
Доцент каф. ______ Я.Ю. Дорогий
Розробив курсант гр. С-16
_____________________ Шурашкевич А.О.
Курсову роботу захищено
з оцінкою____________________
_________________ ______20__р.
(Підпис керівника) (Дата)
________________ ___________
(Підпис члена комісії) (Дата)
Київ-2013
МІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ
УКРАЇНИ
ІНСТИТУТ СПЕЦІАЛЬНОГО ЗВЯЗКУ ТА ЗАХИСТУ
ІНФОРМАЦІЇ
НАЦІОНАЛЬНОГО ТЕХНІЧНОГО УНІВЕРСИТЕТУ УКРАЇНИ
«КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ»
КАФЕДРА КІБЕРБЕЗПЕКИ ТА ЗАСТ
ЗАТВЕРДЖУЮ
Зав. спец. кафедри №5, д.т.н., проф.
___________________В.В. Мохор
«__»____________________20__р.
Протокол №__від_____________
ІНДИВІДУАЛЬНЕ ЗАВДАННЯ
на курсову роботу з дисципліни «Організація баз даних та
знань-1»
Курсанту групи С-16 Шурашкевичу А.О.
Тема: «Розробка бази даних та застосування для
Інтернет-магазину музичних інструментів»
. Здійснити огляд літературних джерел з
підходів до проектування баз даних.
. Провести аналіз предметної області,
виявити всі сутності, їх атрибути, зв’язки між сутностями.
. Розробити концептуальну, логічну та
фізичну моделі БД.
. Розробити застосування для роботи з
проектованою БД.
Вхідні дані: Інтернет-магазин.
Дата видачі____________________ 20__р. Керівник
_______________Я.Ю. Дорогий
Завдання отримав __________Шурашкевич А.О.
Анотація
Метою цієї роботи є створення якісної бази даних
магазину, яка буде вести облік музичного обладнання, обліку покупців та
проданих товарів. До цієї інформації будуть мати доступ як працівники так і
директор магазину, кожен згідно своїх отриманих прав від адміністратора БД.
Підготовка до даних для внесення в БД робиться спеціальними експертами, а сам
запис - оператором.
Вступ
Бази даних - це сукупність структур, призначених
для зберігання великих обсягів інформації і програмних модулів, що здійснюють
управління даними, їх вибірку, сортування та інші подібні дії.
Інформація бази даних зберігається в одній або
кількох таблицях. Будь-яка таблиця з даними складається з набору однотипних
записів, розташованих один за одним. Вони являють собою рядки таблиці, які
можна додавати, видаляти або змінювати.
Кожен запис є набором іменованих полів, або
осередків, які можуть зберігати найрізноманітнішу інформацію, починаючи від
дати народження і закінчуючи докладним описом кулінарного рецепту. Однотипні
поля різних записів утворюють стовпець таблиці.
Створивши одну таблицю, ви вже отримуєте
повноцінну базу даних. Однак у реальному житті структури баз даних, а
відповідно і способи їх створення, набагато складніше.
В останні роки на перший план висувається нова
галузь - інформаційна індустрія, пов'язана з виробництвом технічних засобів,
методів, технологій для виробництва нових знань. Ця індустрія тісно пов'язана з
розвитком комп'ютерних технологій.
В інформаційному суспільстві домінує виробництво
інформаційного продукту, а матеріальний продукт стає більш інформаційно ємним.
Зміняться весь уклад життя, система цінностей: зростає значимість культурного
дозвілля, зростає попит на знання, від людини вимагається здатність до
інтелектуальної праці і творчості. У результаті з'явилися протиріччя між
обмеженими можливостями людини по сприйняттю і переробці інформації та
існуючими масивами зберігається і передається.
Виникло велике число надлишкової інформації, в
якій іноді важко зорієнтуватися і вибрати потрібні відомості.
Для вирішення подібних проблем застосовуються
автоматизовані бази даних. Вони стали невід'ємною частиною практично всіх
комп'ютерних систем - від галузі до окремого підприємства. За останні кілька
років виріс рівень споживчих якостей систем управління базами даних (СКБД):
різноманітність підтримуваних функцій, зручний для користувача інтерфейс, пару
з програмними продуктами, зокрема з іншими СУБД, можливості для роботи в мережі
і т.д. СУБД дозволяє зводити воєдино інформацію з самих різних джерел
(електронні таблиці, інші бази даних) і допомагає швидко знайти необхідну
інформацію, донести її до оточуючих за допомогою звітів, графіків або таблиць.
До теперішнього часу накопичений значний досвід
проектування БД, призначених для управління виробництвом, це дозволяє зробити
процес створення БД більш ефективним.
В даний час серед розробників бази даних (БД)
великою популярністю користується реляційна СУБД Oracle. Дружній
інтерфейс і простота настройки, ефективні засоби створення таблиць, форм,
запитів, інтеграція з іншими додатками пакета, засоби організації роботи з
базами даних і захист інформації - ось далеко не повний перелік переваг цього
додатка.
Основні функції СУБД - це опис структури бази
даних, обробка даних і управління даними. Будь-яка СУБД дозволяє виконувати
чотири найпростіші операції з даними:
Додати в таблицю одну або декілька записів;
Видалити з таблиці одну або декілька записів;
Оновити значення деяких полів в одній або
декількох записах;
Знайти одну або кілька записів, що задовольняють
заданій умові.
Для виконання цих операцій використовується
механізм запитів. Результатом виконання запитів є або відібране за певними
критеріями безліч записів, або зміна в таблицях.
1. Аналіз відомих підходів до проектування баз даних
Проектування баз даних - процес створення схеми
бази даних і визначення необхідних обмежень цілісності.
1.1 Основні завдання проектування баз даних
Основні завдання:
. Забезпечення зберігання в БД всієї
необхідної інформації.
. Забезпечення можливості отримання даних
по всім необхідним запитам.
. Скорочення надмірності та дублювання
даних.
. Забезпечення цілісності даних
(правильності їх змісту): виключення суперечностей у змісті даних, виключення
їх втрати і т.д.
1.2 Основні етапи проектування баз даних
Концептуальне (Інфологічне) проектування -
побудова семантичної моделі предметної області, тобто інформаційної моделі
найбільш високого рівня абстракції. Така модель створюється без орієнтації на
якусь конкретну СУБД і модель даних. Терміни «семантична модель», «концептуальна
модель» і «інфологічна модель» є синонімами. Крім того, в цьому контексті
рівноправно можуть використовуватися слова «модель бази даних» і «модель
предметної області» (наприклад, «концептуальна модель бази даних» і
«концептуальна модель предметної області»), оскільки така модель є як спосіб
реальності, так і спосіб проектованої бази даних для цієї реальності.
Найчастіше концептуальна модель бази даних
включає в себе опис інформаційних об'єктів або понять предметної області і
зв'язків між ними та опис обмежень цілісності, тобто вимог до допустимих
значень даних і до зв'язків між ними.
Логічне (Даталогічне) проектування - створення
схеми бази даних на основі конкретної моделі даних, наприклад, реляційної
моделі даних. Для реляційної моделі даних даталогічна модель - набір схем
відносин, зазвичай із зазначенням первинних ключів, а також «зв'язків» між
відносинами, що представляють собою зовнішні ключі.
Фізичне проектування - створення схеми бази даних
для конкретної СУБД. Специфіка конкретної СУБД може включати в себе обмеження
на іменування об'єктів бази даних, обмеження на підтримувані типи даних і т. п.
Крім того, специфіка конкретної СУБД при фізичному проектуванні включає вибір
рішень, пов'язаних з фізичним середовищем зберігання даних (вибір методів
управління дискової пам'яттю, поділ БД по файлах і пристроям, методів доступу
до даних), створення індексів і т.д.
1.3 Моделі
«сутність-зв'язок»
Модель «сутність-зв'язок» (англ.
«Entity-Relationship model»), або ER-модель, запропонована П. Ченом в 1976 р.,
є найбільш відомим представником класу семантичних (концептуальних,
інфологічних) моделей предметної області. ER-модель зазвичай представляється в
графічній формі, з використанням оригінальної нотації П. Чена, званої
ER-діаграма, або з використанням інших графічних нотацій (Crow'sFoot,
InformationEngineering та ін.)
Основні переваги ER-моделей:
. Наочність;
. Моделі дозволяють проектувати бази даних
з великою кількістю об'єктів і атрибутів;
. ER-моделі реалізовані в багатьох
системах автоматизованого проектування баз даних (наприклад, ERWin).
Основні елементи ER-моделей:
. Об'єкти (сутності);
. Атрибути об'єктів;
. Зв'язки між об'єктами.
Зв'язок між сутностями (об'єктами предметної
області, що має атрибути) характеризується:
. Типом зв'язку (1:1, 1: N, N: М);
. Класом приналежності.
Клас може бути обов'язковим і необов'язковим.
Якщо кожен екземпляр сутності бере участь у зв'язку, то клас приналежності -
обов'язковий, інакше - необов'язковий.
1.4 Ієрархічна,
мережева та реляційна моделі представлення даних
база реляційний мережевий модель
Інформація в базі даних деяким чином
структурована, тобто її можна описати моделлю представлення даних (моделлю
даних), які підтримуються СУБД. Ці моделі підрозділяють на ієрархічні, мережеві
і реляційні.
При використанні ієрархічної моделі представлення
даних зв'язку між даними можна охарактеризувати за допомогою упорядкованого
графа (або дерева). У програмуванні при описі структури ієрархічної бази даних
застосовують тип даних «дерево». Незначне число СУБД побудовано на ієрархічній
моделі даних.
Мережева модель може бути представлена як розвиток і узагальнення ієрархічної моделі
даних, що дозволяє відображати різноманітні взаємозв'язки даних у вигляді
довільного графа.
Системи управління базами даних, побудовані на
основі мережної моделі, також не отримали широкого розповсюдження на практиці.
Реляційна модель представлення даних була
розроблена співробітником фірми 1ВМЕ. Коддом. Його модель ґрунтується на
понятті «ставлення» (relation). Найпростішим прикладом відносини служить
двовимірна таблиця.
Більшість СУБД, застосовуваних як професійними,
так і непрофесійними користувачами, побудовані на основі реляційної моделі
даних (Visual FoxPro і Access фірми Microsoft, Oracle фірми Oracle та ін.)
1.5 Реляційна модель бази даних
Реляційна модель отримала свою назву від
англійського слова relation (відношення) і була запропонована 1970-х роках
Едгаром Коддом
Ця модель являє собою сукупність таблиць,
зв’язаних відношенням. Різниця між таблицею у звичному розумінні і поняттям
відношення полягає в тому, що у відношенні не має порядку - це впорядкована
множина записів. Порядок визначається не відношенням, а чіткою вибіркою із
відношення.
Достоїнствами реляційної моделі даних є простота,
гнучкість структури, зручність реалізації на комп’ютері, висока
стандартизованість.
До недоліків можна віднести обмеженість і
попереднє визначення набору можливих типів даних. Це ускладнює використання
реляційної моделі для деяких сучасних додатків.
Реляційна база даних - це реалізація реляційної
моделі на фізичному рівні.
Конструкція реляційної моделі має широкий та
загальний характер, вона дозволяє описувати структуру бази даних незалежним від
СКБД чином. Крім того, реляційна модель є основою майже усіх СКБД.
Відношення - це двомірна таблиця. Кожен рядок в
таблиці містить дані, які відносяться до якоїсь речі або її частини. кожен
стовпчик таблиці описує який-небудь атрибут цієї речі. Іноді рядки називають
кортежами, а стовпці - атрибутами.
Кожна таблиця має свою структуру, яка складається
з таких елементів:
. Опис полів;
. Ключі;
. Індекси;
. Обмеження на значення полів;
. Обмеження посилочної цілісності між
таблицями;
. Права доступу.
Модель даних - найабстрактніший рівень проектування баз даних.
Елементами описання моделі даних є сутності, атрибути, домени та відношення.
У Кренке Дано таке визначення поняття «сутність»:
«Сутність - це деякий об'єкт системи, що ідентифікується в робочому середовищі
користувача, який має певний набір атрибутів. Атрибутом називають пойменовану
характеристику сутності»
Домен - це набір усіх допустимих значень, які
може містити даний атрибут. Визначення домену включає в себе більш детальний
опис допустимих значень даних.
Крім атрибутів кожної сутності модель даних
повинна визначати зв’язки між сутностями. На концептуальному рівні зв’язки
представляють собою проектні асоціації між сутностями.
Існує декілька типів зв’язків між сутностями -
один до одного, один до багатьох, багато до багатьох.
Зв’язки один до одного зустрічаються досить
рідко, в основному, між сутностями надтипів та підтипів.
Зв’язки один до багатьох зустрічаються більш
частіше.
Зв’язки багато до багатьох неможливо реалізувати
в реляційній моделі, але її перетворена реалізація досить проста та однозначна.
Участь кожної сутності в певному зв’язку може
бути частковою або повною. Якщо існування даної сутності повністю визначається
її участю у зв’язку, то така участь буде повною, в іншому випадку - частковою.
Один із самих важливих і тонких моментів в
процесі створення моделі даних - схема повинна містити вірні значення зв’язків
для кожної сутності протягом всього строку експлуатації системи.
1.6 Організація обмежень посилальної цілісності
Одним з основних понять щодо структури БД - є
поняття її об'єкту або сутності. Будь-який об'єкт, який розглядається в БД як
окремий та автономний від інших; будь який процес - може бути сутністю. Всі
сутності однієї бази даних, як правило, зв'язані між собою.
Сутності, між якими існують зв’язки, називаються
учасниками, а число учасників зв’язку - розмірністю зв’язку. Більшість зв’язків
між сутностями - це подвійні зв’язки, тобто такі в яких беруть участь дві
сутності. Зустрічаються також унарні та потрійні зв’язки.
Участь кожної сутності у зв’язку буває повною або
частковою, залежності від того, чи може ця сутність існувати, якщо даний
зв’язок не визначений.
Сутності також класифікуються на слабкі та
звичайні. Слабкі сутності можуть існувати тільки при на явності зв’язків з
іншими сутностями, у той час коли звичайні сутності існують незалежно від
наявності зв’язків між ними і іншими сутностями.
Отже, зв’язки можна класифікувати один із трьох
можливих способів:
· повні та часткові;
· обов’язкові та
необов’язкові;
· слабкі та звичайні
сутності.
Зв’язки один до одного між двома сутностями - це
такі зв’язки, при яких кожен екземпляр однієї сутності може буди зв’язаним
тільки з одним з одним екземпляром другої сутності.
Хоча зв’язки типу один до одного в реальному
світі зустрічаються досить рідко, в проектуванні баз даних вони широко
використовуються, наприклад, для зменшення числа атрибутів у відношеннях, а
також при моделюванні підкласів сутностей. Існують обмеження числа полів в
таблиці. Звичайно моделі даних не виходять за рамки цих обмежень, оскільки
таблиці з такою великою кількістю полів зустрічаються досить рідко.
Визначити, яке з відношень, що беруть участь у
зв’язку один до багатьох, буде посилатися, а яке - посилочним, дуже просто. Так
як відношення, яке бере участь у зв’язку один до багатьох, зі сторони один
завжди є посилальними, і його ключ-кандидат копіюється у відношення, яке бере
участь у зв’язку зі сторони «багато», яке є посилочним. Ключ-кандидат
посилочного відношення часто виступає як частина, яка входить до складу
відношення, яке бере участь у зв’язку зі сторони «багато», але не забезпечує
унікальну ідентифікацію кортежів посилаючого відношення. Щоб сформувати
ключ-кандидат посилаючого відношення, ключ посилочного відношення слід
скомбінувати з декількома іншими атрибутами.
Зв’язки багато до багатьох часто зустрічаються у
реальному світі, але в реляційній базі даних реалізувати такий зв’язок
неможливо. При моделюванні використовують проміжкові зв’язки до один до
багатьох з кожним з відношенням - учасників зв’язку багато до багатьох. Таке
проміжкові відношення називається проміжковою таблицею. Відношення, яке бере участь
у зв’язку «один до багатьох» зі сторони «один» завжди є посилочним. Це значить,
що всі попередні сутності, тобто сутності, які беруть участь у зв’язку «багато
до багатьох», заміненої двома зв’язками «один до багатьох», в даній моделі
будуть посилочними відношеннями, а проміжкова таблиця - посилаючимся.
Ключі-кандидати проміжковою таблиці включають ключі-кандидати попередніх
відношень, зв’язаних з проміжковою таблицею.
В унарних зв’язках існує тільки один учасник -
відношення зв’язане з собою. Принципи моделювання таких зв’язків не
відрізняються від принципу моделювання зв’язків між двома учасниками. Єдина
різниця в тому, що ссилочне та ссилаюче відношення у даному випадку - одне і
теж відношення.
Унарні зв’язки можуть мати різну потужність.
Унарні зв’язки «один до багатьох» допомагають реалізувати ієрархії. Унарні
зв’язки «багато до багатьох», як і подвійні зв’язки цього типу, реалізуються за
допомогою проміжкових таблиць. Такі зв’язки можуть бути необов’язкові для одної
із сторін.
Потрійні зв’язки не можливо безпосередньо
моделювати в реляційній базі даних, і в цьому полягає їх відмінність від
відношення багато до багатьох.
2. Аналіз предметної області
В даному курсовому проекті в якості предметної
області розглядається магазин продажу музичних інструментів. Наша база даних
вирішує наступні завдання: облік товару, видача даних про постачальників і
поставляються ними товари (фірма-постачальник, його реквізити, найменування
товарів, характеристики, ціни), обчислює суми оплати.
У режимі форми обчислює вартість товару з
націнкою магазину в 50%. Реалізує запити впорядкування по полях: товари,
постачальники, ціна. Здійснює пошук відомостей про фірму-постачальника якогось
товару. Проводить підрахунок вартості та кількості залишився в магазині товару,
а також видає звіт про відсутніх товарах.
Застосовувана СКБД: Oracle.
Вихідні дані про магазин: магазин розташовується
в декількох приміщеннях (склад, торговий зал). У фірми є постачальники,
здійснюють поставку комп'ютерів та комплектуючих на склад магазину. Так само в
магазині є свій штат співробітників: менеджери і консультанти, які здійснюють
продаж товару, бухгалтер, комірники, вантажники-водії. Клієнт, приходячи в
магазин, взаємодіє з менеджером, який, у свою чергу, здійснює продаж дисків.
Операції з коштами і відбиття чека здійснює так само менеджер. При купівлі
товару, клієнт отримує чек із зазначенням товару та його вартості, на підставі
якого зі складу йому відвантажують необхідний товар. При відсутності товару на
складі працівник магазину вибирає відсутні товари та на підставі цих даних
складає заявку на ім'я фірми-постачальника.
Система складається з декількох підсистем:
Транспорт товару до магазину
Продаж Товарів
Підсистема «Транспорт товару до магазину»:
Вхідними даними для цієї системи є:
1) Назва фірми - постачальника
) Країна постачальник
) Номер поставки
) Об’єм поставки
) Дата поставки
) Ціна товару
) Назва товару
На виході маємо наступні дані:
) Облік на звітність по всім товарам що є на
складі магазина
) Вибірка потрібної інформації з БД по запитам
Підсистема «транспорт товару до магазину» виконує
наступні функції (рисунок 2.1):
Рисунок 2.1 - «Транспорт товару до магазину»
) Ввід, вивід, оновлення та зберігання даних про
поставку
) Зберігання даних про колишні поставки та про
поставника.
)Інформацію товар на складі
) Облік всіх товарів на складі
) Комісія перевіряє товар від постачальника та
вирішує розміри поставки
) Комісія оцінює кінцеву ціну товару та прибуток
отриманий від угоди
) Робиться звіт по постачанню товару
) Визначається та встановлю кінцеву ціну товару
) Товар потрапляє на склад
) Вся звітність потрапляє до завідуючого складу
) Завідуючим складом відбувається перевірка
складу
Зовнішні сутності
1) Постачальник - фірма або фізичні лиця яка
постачають товар магазину
) Партія - сукупність товарів які прийшли від
постачальника(виробника) в один день.
) Товар - Об’єкт відносно котрого ведеться облік
) Склад - місце зберігання всього товару магазину
Модулі підсистеми
) Верифікація товару - оцінка якості і початкової
ціни товару, прийняття рішення о доцільності замовлення товару.
) Оцінка товару - оцінка кінцевої ціни товару
) Звітність по партії - інформація про розмір,
дату та виробника партії
) Перевірка складу - Запланована перевірка вмісту
складу.
Підсистема «Продаж Товарів»
Вхідними даними для підсистеми є:
) Облік Клієнтів - Платоспроможність, район міста в якому він
живе та інформація про повернення товару
) Кур’єрська служба - інформація про час
доставки, ким доставлено та кількість доставлених товарів.
) Типи товарів, їх кількість та інша інформація
про товари.
Вихідними даними підсистеми є:
)Є генерація чеку
) Пошук в БД інформації за запитом
) Вибірка з БД інформації
Підсистема «Продаж Товарів» виконує наступні
функції (рис 2.2):
Рисунок 2.2 - Підсистема «Продаж Товарів»
) Облік заказів клієнтів
) Облік інформації про клієнтів
) Облік інформації про доставку товару
Зовнішні сутності:
) Товари - Інформація про товар
) Курьєри - інформація про доставку товару,
кількість доставленого товару клієнту та інше.
) Клієнти - облік інформації про клієнта
) Чек - генерація інформації про заказ клієнта
Зовнішні модулі
) Замовлення - запис отриманій заявці
) Обробка замовлення - перевірка наявності товару
на складі та інше
) Генерація чеку - авто генерація чеку в якому
зберігається ціна замовлення, тип оплати та інше.
Мета й завдання системи:
Система буде забезпечувати зберігання, видачу й
відновлення інформації підсистем інформації про товар та обліку партій (Рисунок
2.4);
а саме:
представляти й одержувати накопичену інформацію з
конкретних об'єктів;
представляти й одержувати інформацію від
підсистеми інформації облік товару;
представляти й одержувати інформацію від
підсистеми обліку партій;
забезпечувати розмежування доступу до
інформаційних ресурсів системи;
забезпечувати моніторинг активних і пасивних
користувачів і системних подій;
забезпечувати користувачів можливістю
інформаційного обміну;
забезпечувати зв'язок між відділами та
працівниками магазину;
забезпечувати регулярне оновлення даних про
товарів та склад;
забезпечувати пошук даних за запитами
2.1 Категорії користувачів
При роботі з системою на стадіях заповнення,
експлуатації БД необхідна участь наступних категорій користувачів:
адміністратора БД;
групи експертів.
Адміністратор системи здійснює заповнення БД
інформацією, що групою експертів. Внесення змін у БД системи здійснюється лише
адміністратором системи під керівництвом групи експертів. Працівники та
керівники є зовнішніми користувачами, що працюють з системою відповідно до
ролей доступу в інформаційно-пошуковому режимі. Можливості, що надаються
користувачам системи:
Співробітнику:
) введення даних про товар;
) введення даних про партію;
) введення даних про виробника
) перегляд зведених таблиць і графіків;
Керівнику
) Повну інформацію про клієнтів
)Інформації про чек
)Інформацію про кур’єрів;
Адміністратору БД:
) введення й корегування системних даних;
) контроль роботи системи;
) здійснення контролю захисту системи від
несанкціонованого доступу;
) зміна фізичної моделі даних системи;
оператору:
) інформації про товар;
) заповнення полів БД системи (введення
інформації);
) пошук у БД даних про товар за запитом;
Під інформаційним об'єктом зберігання
(інформаційним елементом) розуміється логічна однорідна одиниця інформації, для
зберігання якої досить одного запису таблиці. Інформаційні об'єкти зберігання
для БД системи:
А) Загального призначення:
Виробник;
Країна постачальник;
Фірма або фізична лице постачальник;
Поставка;
Клієнти;
Кур’єри;
Чек;
Склад
Платоспроможність,
Дата поставки та інше;
Б) Службові:
запис про активне з'єднання;
запис про користувацьку транзакцію;
рівень доступу в систему;
обліковий запис повноважень користувача (для
організації захисту від несанкціонованого доступу).
3. Концептуальне проектування
Мета інфологічного моделювання - забезпечення
найбільш природних для людини способів збору й представлення тієї інформації,
яку передбачається зберігати в створюваній базі даних.
Тому інфологічну модель даних намагаються будувати за
аналогією з природною мовою (остання не може бути використана у чистому вигляді
через складність комп'ютерної обробки текстів і неоднозначності будь-якої природної мови).
Основними конструктивними елементами інфологічної моделі є
сутності, зв'язки між ними, ідентифікатори (ключі) та властивості (атрибути).
Сутність - кожний помітний об'єкт (об'єкт, який
ми можемо відрізнити від іншого), інформацію про який необхідно зберігати в
базі даних.
Необхідно розрізняти такі поняття, як тип сутності й
екземпляр сутності.
Екземпляр сутності відноситься до конкретної речі в наборі.
Наприклад, типом сутності може бути КОМП'ЮТЕР, а екземпляром - Asus, Acer і т.д.
Атрибут - пойменована характеристика сутності.
Його назва повинна бути унікальною для конкретного типу сутності,
але може бути однаковою для різного типу сутностей
Абсолютна відмінність між типами сутностей і атрибутами
відсутня. Атрибут є таким тільки у зв'язку з типом сутності. В іншому контексті
атрибут може виступати як самостійна сутність.
Ключ - мінімальний набір атрибутів, за значеннями яких можна
однозначно знайти необхідний екземпляр сутності.
Зв'язок - асоціювання двох або більше сутностей. Якби
призначенням бази даних було тільки зберігання окремих, не зв'язаних між собою
даних, то її структура могла б бути дуже простою. Однак, одна з основних вимог
до організації бази даних - це забезпечення можливості пошуку одних сутностей
за значеннями інших, для чого необхідно встановити між ними певні зв'язки.
При побудові інфологічних моделей можна використовувати мову
ER - діаграм. У них сутності зображуються позначеними прямокутниками, асоціації
- позначеними ромбами або шестикутниками, атрибути - позначеними овалами, а
зв'язки між ними - ненаправленими ребрами, над якими може проставлятися ступінь
зв'язку.
3.1 Приклад документів
Сутність - об'єкт будь-якої природи дані, про
якому зберігаються у відношенні (таблиці, в якій містяться дані).
У розглянутій предметній області можна виділити
наступні сутності:
. Поставники-містить інформацію про номер
поставника, назву поставника, назву фірми поставника і степінь довіри (таблиця
3.1.1)
Таблиця 3.1.1 - Поставники
|
Номер поставника
|
Країна поставника
|
Назва фірми-поставника
|
Степінь довіри
|
|
…
|
…
|
…
|
…
|
|
…
|
…
|
…
|
…
|
. Поставка - містить інформацію про номер
поставки, номер поставника, кількість вантажу та дату поставки (Таблиця 3.1.2 -
Поставка).
Таблиця 3.1.2 - Поставка
|
Номер поставкиНомер поставникаКількість
вантажуДата поставки
|
|
|
|
|
…
|
…
|
…
|
…
|
|
…
|
…
|
…
|
…
|
. Інструменти - містить інформацію про
товар (таблиця 3.1.3)
Таблиця 3.1.3 - Інструменти
|
Номер поставки
|
Номер поставника
|
Інвентарний номер
|
Ціна
|
Вага
|
Розмір
|
Тип інструменту
|
|
…
|
…
|
…
|
…
|
…
|
…
|
…
|
|
…
|
…
|
…
|
…
|
…
|
…
|
…
|
. Склад - містить інформацію про номер поставки,
номер поставника, інвентарний номер та інш (таблиця 3.1.4)
Таблиця 3.1.4 - Склад
|
Номер поставки
|
Номер поставника
|
Інвентарний номер
|
Процент заповнення складу
|
К-сть духових
|
К-сть ударних
|
К-сть струнних
|
|
…
|
…
|
…
|
…
|
…
|
…
|
…
|
|
…
|
…
|
…
|
…
|
…
|
…
|
…
|
3.2 Побудова ER-діаграми
Рисунок 3.2.1 - ER-Діаграма «Поставник - поставка»
Рисунок 3.2.1 - ER-Діаграма «Поставка - склад»
Рисунок 3.2.3 - ER-Діаграма «Склад - Товар»
Рисунок. 3.2.4 - Загальна ER-діаграма системи
3.3 Виділення об'єктів довідкової інформації
Визначимо функціональні залежності між
реквізитами документа «Товар», попередньо включивши їх перелік у таблицю. З
аналізу документа очевидно, що реквізити назва фірми, країна постачальник,
степень довіри є описовими і кожний з них залежить тільки від ключового
реквізиту - номер постачальника, який у той же час виконує роль загального
ідентифікатора списку постачальників. Реквізити - Назва товару, Ціна товару,
Фірма однозначно визначаються ключовим реквізитом Таб. номер Товару. Зверніть
увагу на зв'язок реквізитів номер постачальника і Таб. номер Товару. У цьому
функціональному зв'язку виконується необхідна умова - одному значенню ключа
Таб. номер Товару відповідає одне значення залежного реквізиту Код
Постачальника. Цей реквізит відіграє роль описового реквізиту для
співробітника. Якщо такий зв'язок не встановлений, то вся множина реквізитів
документа розділиться на дві не зв'язані між собою підмножини, а це є
нелогічним для реквізитів одного документа. Всі встановлені функціональні
залежності реквізитів документа «Список товарів» відбиті в таблиці 3.1
Таблиця 3.1 - «Список товарів постачальника»
|
Документ
|
Найменування реквізитів
|
Назва реквізиту
|
Функціональні залежності
|
|
Список товарів постачальника
|
Код постачальника
|
Код відділу
|
|
|
Назва постачальника
|
Назва відділу
|
|
|
Країна постачальника
|
Адреса відділу
|
|
|
|
Начальник відділу
|
|
|
Таб.номер товару
|
Таб.номер
|
П.І.Б.
|
|
|
Фірма
|
Посада
|
|
Код постачальника одночасно виступає в ролі
описового реквізиту в одному зв'язку й ключового - в іншому зв'язку. Таким
чином, тут виникає транзитивна залежність. Реквізит Назва постачальника
транзитивно залежить від Таб. номер через Код постачальника. Проте спеціальних
дій по розщепленню цієї залежності не потрібно при використанні наведених
правил.
Виберемо за функціональними зв'язками реквізити,
що залежать від інших реквізитів і вкажемо для них ключові реквізити. Так, при
перегляді списку реквізитів зверху знаходимо перший залежний (описовий)
реквізит Код постачальника і визначаємо його ключовий реквізит Таб. номер. Далі
знаходимо другий залежний (описовий) реквізит Назва постачальника і визначаємо
ключовий. Аналогічно знаходимо описовий реквізит адреса відділу і визначаємо
ключовий і так далі. Виявлена відповідність описових і ключових реквізитів
представлене нижче в таблиці 3.2.
Таблиця 3.2 - «Відповідність описових і ключових реквізитів
документа»
|
Описові (залежні)
|
реквізити Ключові реквізити
|
|
Код постачальника
|
Таб. номер
|
|
Назва постачальника
|
Номер постачальника
|
|
Країна постачальника
|
Номер постачальника
|
|
Степень довіри
|
Номер постачальника
|
|
Таб.номер
|
Таб. номер
|
|
Ціна
|
Таб. номер
|
|
Фірма
|
Таб. номер
|
Згрупуємо реквізити, залежні від тих самих
ключових реквізитів, і об'єднаємо їх з ключовими реквізитами в один
інформаційний об'єкт. Результат групування реквізитів документа «Список товарів
постачальника» наведений у таблиці 3.3.
Таблиця 3.3 - Групування реквізитів за інформаційними об’єктами документа
«Список товарів постачальника»
|
Реквізити об’єкта
|
Ознака унікальності ключа
|
Назва інформаційного об’єкта
|
Семантика об’єкта
|
|
Код постачальника
|
П, У
|
Постачальник
|
Відомості про всі постачальники
|
|
Назва постачальника
|
|
|
|
|
Країна постачальника
|
|
|
|
|
Степень довіри
|
|
|
|
|
Ціна
|
|
Товар
|
Відомості про всі товари
|
|
Таб.номер
|
П, У
|
|
|
|
Назва
|
|
|
|
|
Посада
|
|
|
|
3.4
Модель «сутність-зв'язок»
Інфологічна модель повинна включати таке
формалізований опис предметної області, яке легко буде «читатися» не тільки
фахівцями по базах даних.
Інфологічное проектування, насамперед, пов'язано
зі спробою представлення семантики предметної області в моделі БД. Реляційна
модель даних у силу своєї простоти і лаконічності не дозволяє відобразити
семантику, тобто зміст предметної області.
Проблема подання семантики давно цікавила
розробників, і в сімдесятих роках було запропоновано кілька моделей даних,
названих семантичними моделями. До них можна віднести семантичну модель даних,
запропоновану Хаммером (Hammer) і Мак-Леоном (McLeon) в 1981 році,
функціональну модель даних Шипман (Shipman), також створену в 1981 році, модель
«сутність-зв'язок», запропоновану Ченом (Chen) в 1976 році, і ряд інших
моделей. У всіх моделей були свої позитивні і негативні сторони, але
випробування часом витримала лише остання. І зараз саме модель Чена
«сутність-зв'язок», або «EntityRelationship», стала фактичним стандартом при
інфологіческого моделювання баз даних.
Модель «сутність-зв'язок» називають також
«ER-моделлю» (essence-сутність, relation-зв'язок).
3.5 Класифікація зв'язків
При проектуванні БД інформацію зазвичай
розміщують у кількох таблицях. Таблиці при цьому пов'язують з семантикою
інформації. В реляційній СКБД для вказівки зв'язків в таблиці виробляють
операції їх зв'язування. Розглянемо найбільш часто зустрічаються бінарні
зв'язки:
. Зв'язку вила 1:1 утворюється у випадку, коли
всі поля запису основної таблиці та додаткової таблиці є ключовими.
. Зв'язок 1: М може бути у випадку, коли одного
запису основної таблиці відповідає кілька записів додаткової таблиці.
. Зв'язок М: 1 може бути тоді, коли декільком
записам основної таблиці ставиться у відповідності один запис додаткової.
. Зв'язок М: М виникає в тому випадку коли
декільком записам основної таблиці відповідає кілька записів додаткової. У
реляційної БД зв'язок М: М реалізується через додаткові таблиці.
Розглянемо зв'язки між виявленими сутностями:
. Між атрибутами співробітники і трудовий договір
буде зв'язок 1:1, так як співробітник з даною фірмою укладає трудовий договір
всього один раз.
. Між атрибутами співробітники і відрядження буде
зв'язок 1: М, так як співробітник може скільки завгодно разів їздити у
відрядження.
. Між атрибутами співробітники і лікарняний буде
зв'язок 1: М, так як співробітник може скільки завгодно разів йти на
лікарняний.
. Між атрибутами співробітники і відпустка буде
зв'язок 1: М, так як співробітник може скільки завгодно разів ходити у
відпустку.
. Між атрибутами співробітники та курси
підвищення кваліфікації (переклад) буде зв'язок 1: М, так як співробітник може
проходити курси підвищення кваліфікації скільки завгодно разів.
. Між атрибутами співробітники і звільнення буде
зв'язок 1:1, так співробітник може звільнитися тільки один раз.
. Між атрибутами співробітники і табель робочого
часу буде зв'язок 1:1, так як одному співробітнику відповідає тільки один запис
кожного місяця у табелі.
4. Логічне проектування БД
Реляційна модель баз даних була запропонована
співробітником фірми IBM Е. Кодом на початку 70-х років. Будучи математиком,
він запропонував використовувати для обробки даних апарат теорії множин
(об'єднання, перетин, різниця і Декартовий твір). Він показав, що будь-яке
представлення даних зводиться до сукупності двовимірних таблиць особливого
виду, відомих в математиці як відношення.
Одна з головних ідей полягає в тому, що зв'язки
між даними повинні бути встановлені відповідно до їх внутрішніми логічними взаєминами.
У реляційної моделі однією командою можуть оброблятися цілі файли.
Реляційна БД являє собою інформацію про об'єкт,
представлену у вигляді двовимірного масиву - таблиці об'їдених визначеними
зв'язками.
Розглянемо процес побудови логічної моделі на прикладі
БД співробітників системи «інформація про співробітників». Першим етапом є
визначення сутностей і атрибутів. У БД будуть зберігатися записи про
співробітників, отже, сутністю буде працівники.
4.1 Склад таблиць
Таблиця 4.1 - Постачальники
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер постачальника
|
Текстовий
|
Ключове
|
String
|
|
Країна постачальника
|
Текстовий
|
|
String
|
|
Назва фірми-постачальника
|
Текстовий
|
|
String
|
|
Ступінь довіри
|
Числовий
|
|
Number
|
Таблиця 4.2 - Поставка
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер постачальника
|
Числовий
|
Ключове
|
Number
|
|
Номер поставки
|
Числовий
|
Ключове
|
Number
|
|
Кількість вантажу
|
Числовий
|
|
Number
|
|
Дата поставки
|
Дата/час
|
|
DateTime
|
Таблиця 4.3 - Склад
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер поставки
|
Числовий
|
Ключове
|
Number
|
|
Номер постачальника
|
Числовий
|
Ключове
|
Number
|
|
Інвентарний номер
|
Числовий
|
Ключове
|
Number
|
|
Процент заповнення складу
|
Числовий
|
|
String
|
|
Кількість духових на складі
|
Числовий
|
|
String
|
|
Кількість ударних на складі
|
Числовий
|
|
String
|
|
Кількість струнних на складі
|
Числовий
|
|
String
|
Таблиця 4.4 - Клієнти
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Ціни заказу
|
Числовий
|
Ключове
|
Number
|
|
Дата сплати
|
Дата/час
|
Ключове
|
DateTime
|
|
Сплатоздатність
|
Числовий
|
|
String
|
|
Район міста
|
Текстовий
|
|
String
|
|
Повернення товару
|
Текстовий
|
|
String
|
Таблиця 4.5 - Чек
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Ціна заказу
|
Числовий
|
Ключевое
|
Number
|
|
Дата оплати
|
Дата/час
|
Ключевое
|
DateTime
|
|
Тип оплати
|
Числовий
|
|
Number
|
Таблиця 4.6 - Кур’єри
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер поставки
|
Числовий
|
Ключове
|
Number
|
|
Номер постачальника
|
Числовий
|
Ключове
|
Number
|
|
Інвентарний номер
|
Числовий
|
Ключове
|
Number
|
|
Час доставик товару
|
Дата/час
|
|
DateTime
|
|
Кількість свободних кур’єрів
|
Числовий
|
|
Number
|
|
Кількість кур’єрів у роз’їзді
|
Числовий
|
|
Number
|
Таблиця 4.7 - Інструменти
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер поставки
|
Числовий
|
Ключове
|
Number
|
|
Номер постачальника
|
Числовий
|
Ключове
|
Number
|
|
Інвентарний номер
|
Числовий
|
Ключове
|
Number
|
|
Ціна
|
Фінансовий
|
|
Number
|
|
Вага
|
Числовий
|
|
Number
|
|
Розмір
|
Числовий
|
|
Number
|
|
Тип інструменту
|
Текстовий
|
|
String
|
Таблиця 4.8 - Духові
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер поставки
|
Числовий
|
Ключове
|
Number
|
|
Номер постачальника
|
Числовий
|
Ключове
|
Number
|
|
Інвентарний номер
|
Числовий
|
Ключове
|
Number
|
|
Тип металу
|
Числовий
|
|
Number
|
|
Висота звука
|
Числовий
|
|
Number
|
|
Тип духового
|
Числовий
|
|
Number
|
Таблиця 4.9 - Ударні
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер поставки
|
Числовий
|
Ключове
|
Number
|
|
Номер постачальника
|
Числовий
|
Ключове
|
Number
|
|
Інвентарний номер
|
Числовий
|
Ключове
|
Number
|
|
Тип деревини
|
Числовий
|
|
Number
|
|
Кількість кухні
|
Числовий
|
|
Number
|
|
Наявність рами
|
Числовий
|
|
Number
|
|
Ножне управління
|
Числовий
|
|
Number
|
|
Тип барабанів
|
Числовий
|
|
Number
|
Таблиця 4.10 - Ударні
|
Назва
|
Тип даних
|
Тип поля
|
Тип
|
|
Номер поставки
|
Числовий
|
Ключове
|
Number
|
|
Номер постачальника
|
Числовий
|
Ключове
|
Number
|
|
Інвентарний номер
|
Числовий
|
Ключове
|
Number
|
|
Кількість струн
|
Числовий
|
|
Number
|
|
Колір
|
Числовий
|
|
Number
|
|
Тип струнного
|
Числовий
|
|
Number
|
Атрибут значення, якого ідентифікується кортежами
(рядками таблиці) називається ключем. Ставлення може містити і кілька ключів,
один з яких оголошується первинним. Первинні ключі не можуть оновлюватися. Всі
інші ключі відносин є можливими ключами.
Якщо у відношенні кортеж ідентифікується
з'єднанням значень декількох атрибутів, то такий ключ називається складеним.
Атрибут представляють собою копії ключів інших
відносин називається зовнішнім ключем. Реляційна модель накладає на зовнішні
ключі обмеження для забезпечення цілісності даних. Це означає, що до кожного
значенням зовнішнього ключа повинні відповідати рядки в пов'язуються
відносинах.
У розробляється БД сутність табельний номер
співробітника буде ключем для атрибутів співробітники, відпустка, звільнення,
відрядження, трудовий договір та підвищення кваліфікації (переклад).
Атрибут співробітники так само має унікальні
поля, такі як номер паспорта та ІПН, але номер паспорта не може бути ключем,
так як номер паспорта може мінятися, а ІПН може бути ключовим, але нам зручніше
використовувати як ключ табельний номер.
Для атрибута табель робочого часу ключем буде дві
сутності, номер співробітника і період, тобто ключ буде складовим.
4.2 Нормалізація відносин
Нормалізація - розбиття таблиці на дві або
більше, що володіють кращими властивостями включенні, зміну або видалення
даних. Скінченна мета нормалізації зводиться до отримання такого проекту БД в
якому кожен факт з'являється лише в одному місці, тобто виключена надмірність
інформації.
Нормалізація відносин - формальний апарат
обмежень, на формування відносин якого дозволяє усунути дублювання, забезпечити
несуперечність збережених у базі даних, зменшити трудовитрати на ведення БД.
Перша НФ: Відношення називається нормалізованим
або приведеним до першої нормальної формі тоді і тільки тоді, коли всі його
атрибути прості (неподільні). Таблиця знаходиться в першій нормальній формі
тоді і тільки тоді, коли жодна з її рядків не містить в будь-якому її полі
більше одного значення, і не одне з її ключових полів не порожньо. Для того щоб
привести наші відносини до першої нормальної формі треба сутність інструменти
розбити на три окремі. Так само слід винести в окрему таблицю поставка, склад
та кур’єри, щоб не допустити надмірності даних. В окрему таблицю виносяться чек
та клієнти.
Друга НФ: Таблиця знаходиться в другій нормальній
формі, якщо вона задовольняє визначенню першої нормальної форми і всі її поля,
що не входять в первинний ключ, пов'язані повної функціональної залежністю з
первинним ключем. Для того щоб наші відносини привести у другу нормальну форму
треба винести кур’єрів в окрему таблицю.
Складемо ER-діаграму, визначаючи типи атрибутів і
зв'язки між сутностями (рисунок. 4.1). Всі сутності будуть залежними від сутності «Склад».
Зв'язки будуть типу «один-до-багатьох». (рисунок 4.1)
Рисунок 4.1 - ER
- Діаграма БД
На отриманій діаграмі поруч з зв'язком відбивається
її ім'я, що показує співвідношення між сутностями. При проведенні зв'язку між
сутностями первинний ключ мігрує в дочірню сутність. Наступним етапом при
побудові логічної моделі є визначення ключових атрибутів і типів атрибутів який
був описаний вище.
Використана література
1. Дейт, К.Дж. Введение в системы баз
данных, 8-е издание.: Пер. с англ. /К.Дж. Дейт. - М.: Издательский дом
«Вильямс», 2005. - 1328 с.: ил. - Парал. тит. англ.
. Конноли Т. Базы данных: проектирование и
сопровождение. Теория и практика. /Т. Конноли, К. Бегг, А. Страчан.
. Луни К. Oracle Database 10G. Полный
справочник в 2 томах. / К. Луни. - М.: Издательство «Лори», 2004.
. Дорогий Я.Ю. Методична розробка до
виконання лабораторної роботи «Створення застосувань в Oracle 11G XE» [Електронне
видання]. / Я.Ю. Дорогий. - К.: ІССЗІ НТУУ «КПІ», 2012.
Додаток A: SQL-код БД:
TABLE Chek
(_zak INTEGER NOT NULL,_pay INTEGER NOT
NULL,_type VARCHAR2 (20) NULL
);UNIQUE INDEX XPKЧек ON Chek
(pay_zak ASC, date_pay ASC);TABLE ChekCONSTRAINT
XPKЧек PRIMARY KEY (pay_zak, date_pay);TABLE Dyhovue
(_met VARCHAR2 (20) NULL,_zv VARCHAR2 (20)
NULL,_di VARCHAR2 (20) NULL,_post INTEGER NOT NULL,_no INTEGER NOT NULL,_numb
INTEGER NOT NULL
);UNIQUE INDEX XPKДуховые ON Dyhovue
(nom_post ASC, post_no ASC, inv_numb ASC);TABLE
DyhovueCONSTRAINT XPKДуховые PRIMARY KEY (nom_post, post_no, inv_numb);TABLE
Instrymentu
(INTEGER NULL,INTEGER NULL,
разм INTEGER NULL,_instr VARCHAR2 (20) NULL,_post
INTEGER NOT NULL,_no INTEGER NOT NULL,_numb INTEGER NOT NULL
);UNIQUE INDEX XPKИнструменты ON Instrymentu
(nom_post ASC, post_no ASC, inv_numb ASC);TABLE
InstrymentuCONSTRAINT XPKИнструменты PRIMARY KEY (nom_post, post_no,
inv_numb);TABLE Klientu
(CHAR(18) NULL,_gor VARCHAR2 (20) NULL,_zak
INTEGER NOT NULL,INTEGER NULL,_pay INTEGER NOT NULL
);UNIQUE INDEX XPKКлиенты ON Klientu
(pay_zak ASC, date_pay ASC);TABLE
KlientuCONSTRAINT XPKКлиенты PRIMARY KEY (pay_zak, date_pay);TABLE Kyrjeru
(_svob INTEGER NULL,_pole INTEGER NULL,INTEGER
NULL,_post INTEGER NOT NULL,_no INTEGER NOT NULL,_numb INTEGER NOT NULL
);UNIQUE INDEX XPKКурьеры ON Kyrjeru
(nom_post ASC, post_no ASC, inv_numb ASC);TABLE
KyrjeruCONSTRAINT XPKКурьеры PRIMARY KEY (nom_post, post_no, inv_numb);TABLE
Postavka
(_gr INTEGER NULL,_post INTEGER NULL,_post INTEGER
NOT NULL,_no INTEGER NOT NULL
);UNIQUE INDEX XPKПоставка ON Postavka
(nom_post ASC, post_no ASC);TABLE
PostavkaCONSTRAINT XPKПоставка PRIMARY KEY (nom_post, post_no);TABLE
Postavshiki
(_no INTEGER NOT NULL,VARCHAR2 (20)
NULL,_firm_post VARCHAR2 (20) NULL,_dov INTEGER NULL
);UNIQUE INDEX XPKПоставщики ON Postavshiki
(post_no ASC);TABLE PostavshikiCONSTRAINT
XPKПоставщики PRIMARY KEY (post_no);TABLE Sklad
(_skl INTEGER NULL,_skl_dyx INTEGER
NULL,_zap_bara INTEGER NULL,_skl_str INTEGER NULL,_post INTEGER NOT NULL,_no
INTEGER NOT NULL,_numb INTEGER NOT NULL
);UNIQUE INDEX XPKСклад ON Sklad
(_str INTEGER NULL,VARCHAR2 (20) NULL,_str
VARCHAR2 (20) NULL,_post INTEGER NOT NULL,_no INTEGER NOT NULL,_numb INTEGER
NOT NULL
);UNIQUE INDEX XPKСтрунные ON Strynnue
(nom_post ASC, post_no ASC, inv_numb ASC);TABLE
StrynnueCONSTRAINT XPKСтрунные PRIMARY KEY (nom_post, post_no, inv_numb);TABLE
Ydarnue
(_dere VARCHAR2 (20) NULL,_kyx INTEGER NULL,_ram
INTEGER NULL,_yp VARCHAR2 (20) NULL,_bara VARCHAR2 (20) NULL,_post INTEGER NOT
NULL,_no INTEGER NOT NULL,_numb INTEGER NOT NULL
);UNIQUE INDEX XPKУдарные ON Ydarnue
(nom_post ASC, post_no ASC, inv_numb ASC);TABLE
YdarnueCONSTRAINT XPKУдарные PRIMARY KEY (nom_post, post_no, inv_numb);TABLE
Dyhovue(FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Instrymentu
(nom_post, post_no, inv_numb) ON DELETE CASCADE);TABLE Instrymentu(CONSTRAINT
R_28 FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Sklad (nom_post,
post_no, inv_numb));TABLE Klientu(CONSTRAINT R_25 FOREIGN KEY (pay_zak,
date_pay) REFERENCES Chek (pay_zak, date_pay));TABLE Kyrjeru(CONSTRAINT R_31
FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Sklad (nom_post, post_no,
inv_numb));TABLE Postavka(CONSTRAINT R_21 FOREIGN KEY (post_no) REFERENCES
Postavshiki (post_no));TABLE Sklad(CONSTRAINT R_27 FOREIGN KEY (nom_post,
post_no) REFERENCES Postavka (nom_post, post_no));TABLE Strynnue(FOREIGN KEY
(nom_post, post_no, inv_numb) REFERENCES Instrymentu (nom_post, post_no,
inv_numb) ON DELETE CASCADE);TABLE Ydarnue(FOREIGN KEY (nom_post, post_no,
inv_numb) REFERENCES Instrymentu (nom_post, post_no, inv_numb) ON DELETE
CASCADE);TRIGGER tD_Chek AFTER DELETE ON Chek for each row
ERwin Builtin Trigger
DELETE trigger on ChekNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Chek Klientu on parent delete restrict */
/* ERWIN_RELATION:CHECKSUM= «0000e777»,
PARENT_OWNER=»», PARENT_TABLE= «Chek»_OWNER=»», CHILD_TABLE=
«Klientu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_25», FK_COLUMNS=
«pay_zak»«date_pay» */count(*) INTO NUMROWSKlientu
/* %JoinFKPK (Klientu,:%Old,» =»,» AND»)
*/.pay_zak =:old.pay_zak AND.date_pay =:old.date_pay;(NUMROWS > 0)_application_error
(
,
'Cannot delete Chek because Klientu exists.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Chek AFTER UPDATE ON Chek for each
row
ERwin Builtin Trigger
UPDATE trigger on ChekNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Chek Klientu on parent update restrict */
/* ERWIN_RELATION:CHECKSUM= «00011786»,
PARENT_OWNER=»», PARENT_TABLE= «Chek»_OWNER=»», CHILD_TABLE=
«Klientu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_25», FK_COLUMNS=
«pay_zak»«date_pay» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.pay_zak <>:new.pay_zak OR
:old.date_pay <>:new.date_paycount(*) INTO
NUMROWSKlientu
/* %JoinFKPK (Klientu,:%Old,» =»,» AND»)
*/.pay_zak =:old.pay_zak AND.date_pay =:old.date_pay;(NUMROWS >
0)_application_error (
,
'Cannot update Chek because Klientu exists.'
);IF;IF;
ERwin Builtin Trigger;
/TRIGGER tI_Dyhovue BEFORE INSERT ON Dyhovue for
each row
ERwin Builtin Trigger
INSERT trigger on DyhovueNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Dyhovue on child insert restrict
*/
/* ERWIN_RELATION:CHECKSUM= «000119f9»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Dyhovue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSInstrymentu
/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */
:new.nom_post = Instrymentu.nom_post AND
:new.post_no = Instrymentu.post_no AND
:new.inv_numb = Instrymentu.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Dyhovue because Instrymentu does
not exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Dyhovue AFTER UPDATE ON Dyhovue for
each row
ERwin Builtin Trigger
UPDATE trigger on DyhovueNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Dyhovue on child update restrict
*/
/* ERWIN_RELATION:CHECKSUM= «000118b6»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Dyhovue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSInstrymentu
/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */
:new.nom_post = Instrymentu.nom_post AND
:new.post_no = Instrymentu.post_no AND
:new.inv_numb = Instrymentu.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Dyhovue because Instrymentu does
not exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tI_Instrymentu BEFORE INSERT ON
Instrymentu for each row
ERwin Builtin Trigger
INSERT trigger on InstrymentuNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Sklad Instrymentu on child insert restrict */
/* ERWIN_RELATION:CHECKSUM= «00011048»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Instrymentu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_28»,
FK_COLUMNS= «nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSSklad
/*%JoinFKPK (:%New, Sklad,» =»,» AND») */
:new.nom_post = Sklad.nom_post AND
:new.post_no = Sklad.post_no AND
:new.inv_numb = Sklad.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Instrymentu because Sklad does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tD_Instrymentu AFTER DELETE ON
Instrymentu for each row
ERwin Builtin Trigger
DELETE trigger on InstrymentuNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Dyhovue on parent delete cascade
*/
/* ERWIN_RELATION:CHECKSUM= «0002730b»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Dyhovue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */FROM Dyhovue
/* %JoinFKPK (Dyhovue,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;
/* ERwin Builtin Trigger */
/* Instrymentu Ydarnue on parent delete cascade
*/
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Ydarnue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */FROM Ydarnue
/* %JoinFKPK (Ydarnue,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;
/* ERwin Builtin Trigger */
/* Instrymentu Strynnue on parent delete cascade
*/
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE= «Strynnue»C_VERB_PHRASE=»»,
C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS= «nom_post»«post_no»
«inv_numb» */FROM Strynnue
/* %JoinFKPK (Strynnue,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;
ERwin Builtin Trigger;
/TRIGGER tU_Instrymentu AFTER UPDATE ON
Instrymentu for each row
ERwin Builtin Trigger
UPDATE trigger on InstrymentuNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Dyhovue on parent update cascade
*/
/* ERWIN_RELATION:CHECKSUM= «000530cb»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Dyhovue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.nom_post <>:new.nom_post OR
:old.post_no <>:new.post_no OR
:old.inv_numb <>:new.inv_numbDyhovue
/* %JoinFKPK (Dyhovue,:%New,» =»,»,») */.nom_post
=:new.nom_post,.post_no =:new.post_no,.inv_numb =:new.inv_numb
/* %JoinFKPK (Dyhovue,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;IF;
/* ERwin Builtin Trigger */
/* Instrymentu Ydarnue on parent update cascade
*/
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE= «Ydarnue»C_VERB_PHRASE=»»,
C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS= «nom_post»«post_no»
«inv_numb» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.nom_post <>:new.nom_post OR
:old.post_no <>:new.post_no OR
:old.inv_numb <>:new.inv_numbYdarnue
/* %JoinFKPK (Ydarnue,:%New,» =»,»,») */.nom_post
=:new.nom_post,.post_no =:new.post_no,.inv_numb =:new.inv_numb
/* %JoinFKPK (Ydarnue,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;IF;
/* ERwin Builtin Trigger */
/* Instrymentu Strynnue on parent update cascade
*/
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Strynnue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.nom_post <>:new.nom_post OR
:old.post_no <>:new.post_no OR
:old.inv_numb <>:new.inv_numbStrynnue
/* %JoinFKPK (Strynnue,:%New,» =»,»,»)
*/.nom_post =:new.nom_post,.post_no =:new.post_no,.inv_numb =:new.inv_numb
/* %JoinFKPK (Strynnue,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;IF;
/* ERwin Builtin Trigger */
/* Sklad Instrymentu on child update restrict */
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Instrymentu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_28»,
FK_COLUMNS= «nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSSklad
/*%JoinFKPK (:%New, Sklad,» =»,» AND») */
:new.nom_post = Sklad.nom_post AND
:new.post_no = Sklad.post_no AND
:new.inv_numb = Sklad.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Instrymentu because Sklad does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tI_Klientu BEFORE INSERT ON Klientu for
each row
ERwin Builtin Trigger
INSERT trigger on KlientuNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Chek Klientu on child insert restrict */
/* ERWIN_RELATION:CHECKSUM= «0000f135»,
PARENT_OWNER=»», PARENT_TABLE= «Chek»_OWNER=»», CHILD_TABLE=
«Klientu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_25», FK_COLUMNS=
«pay_zak»«date_pay» */count(*) INTO NUMROWSChek
/*%JoinFKPK (:%New, Chek,» =»,» AND») */
:new.pay_zak = Chek.pay_zak AND
:new.date_pay = Chek.date_pay;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Klientu because Chek does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Klientu AFTER UPDATE ON Klientu for
each row
ERwin Builtin Trigger
UPDATE trigger on KlientuNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Chek Klientu on child update restrict */
/* ERWIN_RELATION:CHECKSUM= «0000f78c»,
PARENT_OWNER=»», PARENT_TABLE= «Chek»_OWNER=»», CHILD_TABLE=
«Klientu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_25», FK_COLUMNS=
«pay_zak»«date_pay» */count(*) INTO NUMROWSChek
/*%JoinFKPK (:%New, Chek,» =»,» AND») */
:new.pay_zak = Chek.pay_zak AND
:new.date_pay = Chek.date_pay;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Klientu because Chek does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tI_Kyrjeru BEFORE INSERT ON Kyrjeru for
each row
ERwin Builtin Trigger
INSERT trigger on KyrjeruNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Sklad Kyrjeru on child insert restrict */
/* ERWIN_RELATION:CHECKSUM= «00010666»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Kyrjeru»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_31», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSSklad
/*%JoinFKPK (:%New, Sklad,» =»,» AND») */
:new.nom_post = Sklad.nom_post AND
:new.post_no = Sklad.post_no AND
:new.inv_numb = Sklad.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Kyrjeru because Sklad does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Kyrjeru AFTER UPDATE ON Kyrjeru for
each row
ERwin Builtin Trigger
UPDATE trigger on KyrjeruNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Sklad Kyrjeru on child update restrict */
/* ERWIN_RELATION:CHECKSUM= «00010829»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Kyrjeru»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_31», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSSklad
/*%JoinFKPK (:%New, Sklad,» =»,» AND») */
:new.nom_post = Sklad.nom_post AND
:new.post_no = Sklad.post_no AND
:new.inv_numb = Sklad.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Kyrjeru because Sklad does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tI_Postavka BEFORE INSERT ON Postavka
for each row
ERwin Builtin Trigger
INSERT trigger on PostavkaNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Postavshiki Postavka on child insert restrict
*/
/* ERWIN_RELATION:CHECKSUM= «0000f5ca»,
PARENT_OWNER=»», PARENT_TABLE= «Postavshiki»_OWNER=»», CHILD_TABLE=
«Postavka»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_21», FK_COLUMNS=
«post_no» */count(*) INTO NUMROWSPostavshiki
/*%JoinFKPK (:%New, Postavshiki,» =»,» AND») */
:new.post_no = Postavshiki.post_no;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Postavka because Postavshiki does
not exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tD_Postavka AFTER DELETE ON Postavka for
each row
ERwin Builtin Trigger
DELETE trigger on PostavkaNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Postavka Sklad on parent delete restrict */
/* ERWIN_RELATION:CHECKSUM= «0000e1a0»,
PARENT_OWNER=»», PARENT_TABLE= «Postavka»_OWNER=»», CHILD_TABLE=
«Sklad»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_27», FK_COLUMNS=
«nom_post»«post_no» */count(*) INTO NUMROWSSklad
/* %JoinFKPK (Sklad,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no;(NUMROWS >
0)_application_error (
,
'Cannot delete Postavka because Sklad exists.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Postavka AFTER UPDATE ON Postavka for
each row
ERwin Builtin Trigger
UPDATE trigger on PostavkaNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Postavka Sklad on parent update restrict */
/* ERWIN_RELATION:CHECKSUM= «0002289b»,
PARENT_OWNER=»», PARENT_TABLE= «Postavka»_OWNER=»», CHILD_TABLE=
«Sklad»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_27», FK_COLUMNS=
«nom_post»«post_no» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.nom_post <>:new.nom_post OR
:old.post_no <>:new.post_nocount(*) INTO
NUMROWSSklad
/* %JoinFKPK (Sklad,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no;(NUMROWS > 0)_application_error
(
,
'Cannot update Postavka because Sklad exists.'
);IF;IF;
/* ERwin Builtin Trigger */
/* Postavshiki Postavka on child update restrict
*/
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Postavshiki»_OWNER=»», CHILD_TABLE=
«Postavka»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_21», FK_COLUMNS=
«post_no» */count(*) INTO NUMROWSPostavshiki
/*%JoinFKPK (:%New, Postavshiki,» =»,» AND») */
:new.post_no = Postavshiki.post_no;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Postavka because Postavshiki does
not exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tD_Postavshiki AFTER DELETE ON
Postavshiki for each row
ERwin Builtin Trigger
DELETE trigger on PostavshikiNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Postavshiki Postavka on parent delete restrict
*/
/* ERWIN_RELATION:CHECKSUM= «0000d5f0»,
PARENT_OWNER=»», PARENT_TABLE= «Postavshiki»_OWNER=»», CHILD_TABLE=
«Postavka»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_21», FK_COLUMNS=
«post_no» */count(*) INTO NUMROWSPostavka
/* %JoinFKPK (Postavka,:%Old,» =»,» AND»)
*/.post_no =:old.post_no;(NUMROWS > 0)_application_error (
,
'Cannot delete Postavshiki because Postavka
exists.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Postavshiki AFTER UPDATE ON
Postavshiki for each row
ERwin Builtin Trigger
UPDATE trigger on PostavshikiNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Postavshiki Postavka on parent update restrict
*/
/* ERWIN_RELATION:CHECKSUM= «0000fb42»,
PARENT_OWNER=»», PARENT_TABLE= «Postavshiki»_OWNER=»», CHILD_TABLE=
«Postavka»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_21», FK_COLUMNS=
«post_no» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.post_no <>:new.post_nocount(*) INTO
NUMROWSPostavka
/* %JoinFKPK (Postavka,:%Old,» =»,» AND»)
*/.post_no =:old.post_no;(NUMROWS > 0)_application_error (
,
'Cannot update Postavshiki because Postavka
exists.'
);IF;IF;
ERwin Builtin Trigger;
/TRIGGER tI_Sklad BEFORE INSERT ON Sklad for each
row
ERwin Builtin Trigger
INSERT trigger on SkladNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Postavka Sklad on child insert restrict */
/* ERWIN_RELATION:CHECKSUM= «0001007f»,
PARENT_OWNER=»», PARENT_TABLE= «Postavka»_OWNER=»», CHILD_TABLE=
«Sklad»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_27», FK_COLUMNS=
«nom_post»«post_no» */count(*) INTO NUMROWSPostavka
/*%JoinFKPK (:%New, Postavka,» =»,» AND») */
:new.nom_post = Postavka.nom_post AND
:new.post_no = Postavka.post_no;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Sklad because Postavka does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tD_Sklad AFTER DELETE ON Sklad for each
row
ERwin Builtin Trigger
DELETE trigger on SkladNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Sklad Instrymentu on parent delete restrict */
/* ERWIN_RELATION:CHECKSUM= «000217ef»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Instrymentu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_28»,
FK_COLUMNS= «nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSInstrymentu
/* %JoinFKPK (Instrymentu,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;(NUMROWS > 0)_application_error (
,
'Cannot delete Sklad because Instrymentu exists.'
);IF;
/* ERwin Builtin Trigger */
/* Sklad Kyrjeru on parent delete restrict */
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Kyrjeru»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_31», FK_COLUMNS= «nom_post»«post_no»
«inv_numb» */count(*) INTO NUMROWSKyrjeru
/* %JoinFKPK (Kyrjeru,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;(NUMROWS > 0)_application_error (
,
'Cannot delete Sklad because Kyrjeru exists.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Sklad AFTER UPDATE ON Sklad for each
row
ERwin Builtin Trigger
UPDATE trigger on SkladNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Sklad Instrymentu on parent update restrict */
/* ERWIN_RELATION:CHECKSUM= «0003a2dd»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Instrymentu»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_28»,
FK_COLUMNS= «nom_post»«post_no» «inv_numb» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.nom_post <>:new.nom_post OR
:old.post_no <>:new.post_no OR
:old.inv_numb <>:new.inv_numbcount(*) INTO
NUMROWSInstrymentu
/* %JoinFKPK (Instrymentu,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;(NUMROWS > 0)_application_error (
,
'Cannot update Sklad because Instrymentu exists.'
);IF;IF;
/* ERwin Builtin Trigger */
/* Sklad Kyrjeru on parent update restrict */
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Sklad»_OWNER=»», CHILD_TABLE=
«Kyrjeru»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_31», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */
/*%JoinPKPK (:%Old,:%New,» <>»,» OR») */
:old.nom_post <>:new.nom_post OR
:old.post_no <>:new.post_no OR
:old.inv_numb <>:new.inv_numbcount(*) INTO
NUMROWSKyrjeru
/* %JoinFKPK (Kyrjeru,:%Old,» =»,» AND»)
*/.nom_post =:old.nom_post AND.post_no =:old.post_no AND.inv_numb
=:old.inv_numb;(NUMROWS > 0)_application_error (
,
'Cannot update Sklad because Kyrjeru exists.'
);IF;IF;
/* ERwin Builtin Trigger */
/* Postavka Sklad on child update restrict */
/* ERWIN_RELATION:CHECKSUM= «00000000»,
PARENT_OWNER=»», PARENT_TABLE= «Postavka»_OWNER=»», CHILD_TABLE=
«Sklad»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «R_27», FK_COLUMNS=
«nom_post»«post_no» */count(*) INTO NUMROWSPostavka
/*%JoinFKPK (:%New, Postavka,» =»,» AND») */
:new.nom_post = Postavka.nom_post AND
:new.post_no = Postavka.post_no;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Sklad because Postavka does not
exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tI_Strynnue BEFORE INSERT ON Strynnue
for each row
ERwin Builtin Trigger
INSERT trigger on StrynnueNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Strynnue on child insert restrict
*/
/* ERWIN_RELATION:CHECKSUM= «00011f2f»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Strynnue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSInstrymentu
/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */
:new.nom_post = Instrymentu.nom_post AND
:new.inv_numb = Instrymentu.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Strynnue because Instrymentu does
not exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Strynnue AFTER UPDATE ON Strynnue for
each row
ERwin Builtin Trigger
UPDATE trigger on StrynnueNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Strynnue on child update restrict
*/
/* ERWIN_RELATION:CHECKSUM= «00011df7»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Strynnue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSInstrymentu
/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */
:new.nom_post = Instrymentu.nom_post AND
:new.post_no = Instrymentu.post_no AND
:new.inv_numb = Instrymentu.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Strynnue because Instrymentu does
not exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tI_Ydarnue BEFORE INSERT ON Ydarnue for
each row
ERwin Builtin Trigger
INSERT trigger on YdarnueNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Ydarnue on child insert restrict
*/
/* ERWIN_RELATION:CHECKSUM= «00012269»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Ydarnue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSInstrymentu
/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */
:new.nom_post = Instrymentu.nom_post AND
:new.post_no = Instrymentu.post_no AND
:new.inv_numb = Instrymentu.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot insert Ydarnue because Instrymentu does
not exist.'
);IF;
ERwin Builtin Trigger;
/TRIGGER tU_Ydarnue AFTER UPDATE ON Ydarnue for
each row
ERwin Builtin Trigger
UPDATE trigger on YdarnueNUMROWS INTEGER;
/* ERwin Builtin Trigger */
/* Instrymentu Ydarnue on child update restrict
*/
/* ERWIN_RELATION:CHECKSUM= «0001299c»,
PARENT_OWNER=»», PARENT_TABLE= «Инструменты»_OWNER=»», CHILD_TABLE=
«Ydarnue»C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,_CONSTRAINT= «is_a», FK_COLUMNS=
«nom_post»«post_no» «inv_numb» */count(*) INTO NUMROWSInstrymentu
/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */
:new.nom_post = Instrymentu.nom_post AND
:new.post_no = Instrymentu.post_no AND
:new.inv_numb = Instrymentu.inv_numb;(
/*%NotnullFK (:%New,» IS NOT NULL AND») */= 0
)_application_error (
,
'Cannot update Ydarnue because Instrymentu does
not exist.'
);IF;
ERwin Builtin Trigger;
/