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

Размещено на http://www.allbest.ru/

72

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

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

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

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

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

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

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

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

6.050101 - "Комп'ютерні науки"

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

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

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

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

Київ 2012

Анотація

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

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

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

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

Зміст

Вступ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновок

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

Додаток

Вступ

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

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

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

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

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

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

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

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

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

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

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

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

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

Існує два підходи до побудови БД, що базуються на двох підходах до створення автоматизованої системи управління(АСУ).

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

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

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

У роботі БД можливий одно-і багатокористувацький (кілька користувачів підключаються до одного комп'ютера через різні порти) режими.

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

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

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

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

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

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

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

Низхідне проектування включає операції декомпозиції, що передбачає заміну вихідної множини відношень, що входять в схему БД, іншою множиною відношень, які є проекціями вихідних відношень. Цей підхід рекомендується застосовувати у тих випадках, коли кількість, різноманітність та складність сутностей, зв'язків і транзакцій значна за розмірами. Найбільш поширеними моделями для цього проектування є моделі "сутність ? зв'язок" (ER-моделі, Entity-Relationship model).

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

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

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

При проектуванні бази даних вирішуються дві основні проблеми:

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

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

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

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

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

У ході аналізу предметної області необхідно:

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

- визначити й виділити первісний набір сутностей і атрибутів предметної області.

До функціональних характеристики системи відносяться:

- первинне введення інформації в БД;

- зміна змісту БД:

* введення нових даних;

* зміна існуючих даних;

* архівація даних.

- здійснення пошуку в БД за запитом користувача;

- дистанційний доступ до системи за протоколом TCP/IP;

- забезпечення захисту й безпеки даних, зокрема:

* розмежування прав доступу до ресурсів сервера (власник, група і т.д.);

* контроль інформації, що вводиться;

* забезпечення цілісності БД.

- виведення знайденої інформації.

Проектування інфологічної, даталогічної та фізичної моделей, побудова ER-моделей:

Моделювання даних - це процес створення логічного представлення структури бази даних.

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

На цей час існує два основних підходи до моделювання даних:

- модель бази даних типу «сутність - зв'язок» (entity-relationship model), що має значну кількість прихильників серед професіоналів;

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

При проектуванні бази даних використаємо перший, найпоширеніший метод моделювання даних - «сутність - зв'язок».

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

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

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

Опис системи:

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

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

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

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

Схема складається з 3-х підсистем:

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

- Вибору діяльності людини

- Пакет анкет для користувача. Огляд таблиць.

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

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

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

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

Підсистема «Створення облікової анкети» виконує наступні функції:

- Ввід даних та редагування на сайті

- Зберігання інформації та отримання від системи контролю за обліком.

- Формування корзини для товарів

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

Вибору діяльності людини :

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



Размещено на http://www.allbest.ru/

72

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Размещено на http://www.allbest.ru/

72

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

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

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

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

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



Размещено на http://www.allbest.ru/

72

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

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 сутностей, такі як:

1. Фірма;

2. Модель;

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

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

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

6. Корзина;

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

8. Новинки;

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

Бази Даних в CASE-засобі для проектування и документування баз даних AllFusion ERwin Data Modeler буде мати наступний вигляд:

Висновок

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

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

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

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

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

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

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

Сьомий етап безпосередньо побудова ER-моделі в CASE-засобі для проектування й документування баз даних AllFusion ERwin Data Modeler, та представлення в даній курсовій роботі скриншотів вже побудованої, готової для використання, бази даних.

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

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

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

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

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

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

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

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

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

Додаток

SQL-код БД

CREATE TABLE Firm

(

name_firm VARCHAR2(200) NOT NULL,

kod_modeli NUMBER(30) NOT NULL,

adres_firm VARCHAR2(200) NULL,

kod_firm NUMBER(30) NOT NULL,

kod_komplektuechego NUMBER(30) NOT NULL,

kod_obladnya NUMBER(30) NOT NULL,

name VARCHAR2(200) NOT NULL,

familia VARCHAR2(200) NOT NULL,

kod_tovary NUMBER(30) NOT NULL,

name_models VARCHAR2(200) NOT NULL

);

CREATE 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);

ALTER TABLE Firm

ADD CONSTRAINT XPKФірма PRIMARY KEY (kod_firm,kod_modeli,kod_komplektuechego,kod_obladnya,name,familia,name_firm,name_models);

CREATE TABLE Komplektuechi

(

name_firm VARCHAR2(200) NULL,

name_models VARCHAR2(200) NULL,

kod_models NUMBER(30) NOT NULL,

name_komplektuechego VARCHAR2(200) NULL,

kod_komplektuechego NUMBER(30) NOT NULL,

Price CHAR(18) NULL,

kod_firm NUMBER(30) NOT NULL,

kod_obladnenya NUMBER(30) NOT NULL

);

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

(kod_firm ASC,kod_models ASC,kod_komplektuechego ASC,kod_obladnenya ASC);

ALTER TABLE Komplektuechi

ADD CONSTRAINT XPKКомплектуючі PRIMARY KEY (kod_firm,kod_models,kod_komplektuechego,kod_obladnenya);

CREATE TABLE Koristyvach

(

Name VARCHAR2(200) NOT NULL,

Familia VARCHAR2(200) NOT NULL,

God_Rogdenia DATE NULL,

adres_progivania NUMBER(30) NULL,

stati VARCHAR2(200) NULL,

kod_firn NUMBER(30) NOT NULL

);

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

(Name ASC,Familia ASC,kod_firn ASC);

ALTER TABLE Koristyvach

ADD CONSTRAINT XPKКористувач PRIMARY KEY (Name,Familia,kod_firn);

CREATE TABLE Korzina

(

kod_tovary NUMBER(30) NULL,

name_tovary VARCHAR2(200) NULL,

name_firm VARCHAR2(200) NULL,

kod_firm NUMBER(30) NOT NULL,

Price CHAR(18) NULL

);

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

(kod_firm ASC);

ALTER TABLE Korzina

ADD CONSTRAINT XPKКорзина PRIMARY KEY (kod_firm);

CREATE TABLE Models

(

kod_modely NUMBER(30) NOT NULL,

Name_Firm VARCHAR2(200) NULL,

name_models VARCHAR2(200) NULL,

Price CHAR(18) NULL,

kod_firm NUMBER(30) NOT NULL,

kod_komplektuechgo NUMBER(30) NOT NULL,

kod_obladnya NUMBER(30) NOT NULL,

Characteristics VARCHAR2(2500) NULL

);

CREATE UNIQUE INDEX XPKМодель ON Models

(kod_modely ASC,kod_firm ASC,kod_komplektuechgo ASC,kod_obladnya ASC);

ALTER TABLE Models

ADD CONSTRAINT XPKМодель PRIMARY KEY (kod_modely,kod_firm,kod_komplektuechgo,kod_obladnya);

CREATE TABLE News

(

Name_firm VARCHAR2(200) NOT NULL,

Name_models VARCHAR2(200) NOT NULL,

Data INTERVAL YEAR TO MONTH NULL,

inPrice CHAR(18) NULL

);

CREATE UNIQUE INDEX XPKНовинки ON News

(Name_firm ASC,Name_models ASC);

ALTER TABLE News

ADD CONSTRAINT XPKНовинки PRIMARY KEY (Name_firm,Name_models);

CREATE TABLE Obladnenya

(

kod_obladnenya NUMBER(30) NOT NULL,

Name_obladnenya VARCHAR2(200) NULL,

Price CHAR(18) NULL

);

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

(kod_obladnenya ASC);

ALTER TABLE Obladnenya

ADD CONSTRAINT XPKОбладнення PRIMARY KEY (kod_obladnenya);

ALTER TABLE Obladnenya

ADD CONSTRAINT Инв._номер UNIQUE (kod_obladnenya);

CREATE TABLE Shogi_tovary

(

Name_Firm VARCHAR2(200) NOT NULL,

Name_tovary VARCHAR2(200) NULL,

kod_firm NUMBER(30) NOT NULL,

kod_tovary NUMBER(30) NOT NULL,

Price CHAR(18) NULL,

Name_models VARCHAR2(200) NOT NULL

);

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

(Name_Firm ASC,kod_firm ASC,kod_tovary ASC,Name_models ASC);

ALTER TABLE Shogi_tovary

ADD CONSTRAINT XPKСхожі_Товари PRIMARY KEY (Name_Firm,kod_firm,kod_tovary,Name_models);

ALTER TABLE Firm

ADD (CONSTRAINT R_1 FOREIGN KEY (kod_modeli, kod_firm, kod_komplektuechego, kod_obladnya) REFERENCES Models (kod_modely, kod_firm, kod_komplektuechgo, kod_obladnya));

ALTER TABLE Firm

ADD (CONSTRAINT R_5 FOREIGN KEY (name, familia, kod_firm) REFERENCES Koristyvach (Name, Familia, kod_firn));

ALTER TABLE Firm

ADD (CONSTRAINT R_7 FOREIGN KEY (name_firm, kod_firm, kod_tovary, name_models) REFERENCES Shogi_tovary (Name_Firm, kod_firm, kod_tovary, Name_models));

ALTER TABLE Komplektuechi

ADD (CONSTRAINT R_3 FOREIGN KEY (kod_obladnenya) REFERENCES Obladnenya (kod_obladnenya))

ALTER TABLE Koristyvach

ADD (CONSTRAINT R_4 FOREIGN KEY (kod_firn) REFERENCES Korzina (kod_firm));

ALTER TABLE Models

ADD (CONSTRAINT R_2 FOREIGN KEY (kod_firm, kod_modely, kod_komplektuechgo, kod_obladnya) REFERENCES Komplektuechi (kod_firm, kod_models, kod_komplektuechego, kod_obladnenya));

ALTER TABLE Shogi_tovary

ADD (CONSTRAINT R_6 FOREIGN KEY (Name_Firm, Name_models) REFERENCES News (Name_firm, Name_models));

CREATE TRIGGER tI_Firm BEFORE INSERT ON Firm for each row

-- ERwin Builtin Trigger

-- INSERT trigger on Firm

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Models Firm on child insert restrict */

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

CHILD_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_1", FK_COLUMNS="kod_modeli""kod_firm""kod_komplektuechego""kod_obladnya" */

SELECT count(*) INTO NUMROWS

FROM Models

WHERE

/*%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;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20002,

'Cannot insert Firm because Models does not exist.'

);

END IF;

/* ERwin Builtin Trigger */

/* Koristyvach Firm on child insert restrict */

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

CHILD_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

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

SELECT count(*) INTO NUMROWS

FROM Koristyvach

WHERE

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

:new.name = Koristyvach.Name AND

:new.familia = Koristyvach.Familia AND

:new.kod_firm = Koristyvach.kod_firn;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20002,

'Cannot insert Firm because Koristyvach does not exist.'

);

END IF;

/* ERwin Builtin Trigger */

/* Shogi_tovary Firm on child insert restrict */

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

CHILD_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

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

SELECT count(*) INTO NUMROWS

FROM Shogi_tovary

WHERE

/*%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;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20002,

'Cannot insert Firm because Shogi_tovary does not exist.'

);

END IF;

-- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tU_Firm AFTER UPDATE ON Firm for each row

-- ERwin Builtin Trigger

-- UPDATE trigger on Firm

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Models Firm on child update restrict */

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

CHILD_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_1", FK_COLUMNS="kod_modeli""kod_firm""kod_komplektuechego""kod_obladnya" */

SELECT count(*) INTO NUMROWS

FROM Models

WHERE

/*%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;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20007,

'Cannot update Firm because Models does not exist.'

);

END IF;

/* ERwin Builtin Trigger */

/* Koristyvach Firm on child update restrict */

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

CHILD_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

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

SELECT count(*) INTO NUMROWS

FROM Koristyvach

WHERE

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

:new.name = Koristyvach.Name AND

:new.familia = Koristyvach.Familia AND

:new.kod_firm = Koristyvach.kod_firn;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20007,

'Cannot update Firm because Koristyvach does not exist.'

);

END IF;

/* ERwin Builtin Trigger */

/* Shogi_tovary Firm on child update restrict */

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

CHILD_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

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

SELECT count(*) INTO NUMROWS

FROM Shogi_tovary

WHERE

/*%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;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20007,

'Cannot update Firm because Shogi_tovary does not exist.'

);

END IF;

-- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tI_Komplektuechi BEFORE INSERT ON Komplektuechi for each row

-- ERwin Builtin Trigger

-- INSERT trigger on Komplektuechi

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Obladnenya Komplektuechi on child insert restrict */

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

CHILD_OWNER="", CHILD_TABLE="Komplektuechi"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_3", FK_COLUMNS="kod_obladnenya" */

SELECT count(*) INTO NUMROWS

FROM Obladnenya

WHERE

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

:new.kod_obladnenya = Obladnenya.kod_obladnenya;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20002,

'Cannot insert Komplektuechi because Obladnenya does not exist.'

);

END IF;

-- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tD_Komplektuechi AFTER DELETE ON Komplektuechi for each row

-- ERwin Builtin Trigger

-- DELETE trigger on Komplektuechi

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Komplektuechi Models on parent delete restrict */

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

CHILD_OWNER="", CHILD_TABLE="Models"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_2", FK_COLUMNS="kod_firm""kod_modely""kod_komplektuechgo""kod_obladnya" */

SELECT count(*) INTO NUMROWS

FROM Models

WHERE

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

Models.kod_firm = :old.kod_firm AND

Models.kod_modely = :old.kod_models AND

Models.kod_komplektuechgo = :old.kod_komplektuechego AND

Models.kod_obladnya = :old.kod_obladnenya;

IF (NUMROWS > 0)

THEN

raise_application_error(

-20001,

'Cannot delete Komplektuechi because Models exists.'

);

END IF;

-- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tU_Komplektuechi AFTER UPDATE ON Komplektuechi for each row

-- ERwin Builtin Trigger

-- UPDATE trigger on Komplektuechi

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Komplektuechi Models on parent update restrict */

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

CHILD_OWNER="", CHILD_TABLE="Models"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_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

THEN

SELECT count(*) INTO NUMROWS

FROM Models

WHERE

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

Models.kod_firm = :old.kod_firm AND

Models.kod_modely = :old.kod_models AND

Models.kod_komplektuechgo = :old.kod_komplektuechego AND

Models.kod_obladnya = :old.kod_obladnenya;

IF (NUMROWS > 0)

THEN

raise_application_error(

-20005,

'Cannot update Komplektuechi because Models exists.'

);

END IF;

END IF;

/* ERwin Builtin Trigger */

/* Obladnenya Komplektuechi on child update restrict */

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

CHILD_OWNER="", CHILD_TABLE="Komplektuechi"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

FK_CONSTRAINT="R_3", FK_COLUMNS="kod_obladnenya" */

SELECT count(*) INTO NUMROWS

FROM Obladnenya

WHERE

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

:new.kod_obladnenya = Obladnenya.kod_obladnenya;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20007,

'Cannot update Komplektuechi because Obladnenya does not exist.'

);

END IF;

-- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tI_Koristyvach BEFORE INSERT ON Koristyvach for each row

-- ERwin Builtin Trigger

-- INSERT trigger on Koristyvach

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Korzina Koristyvach on child insert restrict */

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

CHILD_OWNER="", CHILD_TABLE="Koristyvach"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

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

SELECT count(*) INTO NUMROWS

FROM Korzina

WHERE

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

:new.kod_firn = Korzina.kod_firm;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error(

-20002,

'Cannot insert Koristyvach because Korzina does not exist.'

);

END IF;

-- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tD_Koristyvach AFTER DELETE ON Koristyvach for each row

-- ERwin Builtin Trigger

-- DELETE trigger on Koristyvach

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Koristyvach Firm on parent delete restrict */

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

CHILD_OWNER="", CHILD_TABLE="Firm"

P2C_VERB_PHRASE="", C2P_VERB_PHRASE="",

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

SELECT count(*) INTO NUMROWS

FROM Firm

WHERE

/*%JoinFKPK(Firm,:%Old," = "," AND") */