Розробка бази даних та застосування для інтернет-магазину продажу музичних інструментів

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 29.01.2013
Размер файла 541,5 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

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

Розробка бази даних та застосування для інтернет-магазину продажу музичних інструментів

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

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

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

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

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

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

Розробив курсант гр. С-16

_____________________ Шурашкевич А.О.

Курсову роботу захищено

з оцінкою____________________

_________________ ______20__р.

(Підпис керівника) (Дата)

________________ ___________

(Підпис члена комісії) (Дата)

Київ-2013

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

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

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

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

КАФЕДРА КІБЕРБЕЗПЕКИ ТА ЗАСТ

ЗАТВЕРДЖУЮ

Зав. спец. кафедри №5, д.т.н., проф.

___________________В.В. Мохор

«__»____________________20__р.

Протокол №__від_____________

ІНДИВІДУАЛЬНЕ ЗАВДАННЯ

на курсову роботу з дисципліни «Організація баз даних та знань-1»

Курсанту групи С-16 Шурашкевичу А.О.

Тема: «Розробка бази даних та застосування для Інтернет-магазину музичних інструментів»

1. Здійснити огляд літературних джерел з підходів до проектування баз даних.

2. Провести аналіз предметної області, виявити всі сутності, їх атрибути, зв'язки між сутностями.

3. Розробити концептуальну, логічну та фізичну моделі БД.

4. Розробити застосування для роботи з проектованою БД.

Вхідні дані: Інтернет-магазин.

Дата видачі____________________ 20__р. Керівник _______________Я.Ю. Дорогий

Завдання отримав __________Шурашкевич А.О.

Анотація

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

Вступ

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

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

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

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

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

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

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

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

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

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

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

- Додати в таблицю одну або декілька записів;

- Видалити з таблиці одну або декілька записів;

- Оновити значення деяких полів в одній або декількох записах;

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

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

1. Аналіз відомих підходів до проектування баз даних

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

1.1 Основні завдання проектування баз даних

Основні завдання:

1. Забезпечення зберігання в БД всієї необхідної інформації.

2. Забезпечення можливості отримання даних по всім необхідним запитам.

3. Скорочення надмірності та дублювання даних.

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

1.2 Основні етапи проектування баз даних

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

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

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

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

1.3 Моделі «сутність-зв'язок»

Модель «сутність-зв'язок» (англ. «Entity-Relationship model»), або ER-модель, запропонована П. Ченом в 1976 р., є найбільш відомим представником класу семантичних (концептуальних, інфологічних) моделей предметної області. ER-модель зазвичай представляється в графічній формі, з використанням оригінальної нотації П. Чена, званої ER-діаграма, або з використанням інших графічних нотацій (Crow'sFoot, InformationEngineering та ін.)

Основні переваги ER-моделей:

1. Наочність;

2. Моделі дозволяють проектувати бази даних з великою кількістю об'єктів і атрибутів;

3. ER-моделі реалізовані в багатьох системах автоматизованого проектування баз даних (наприклад, ERWin).

Основні елементи ER-моделей:

1. Об'єкти (сутності);

2. Атрибути об'єктів;

3. Зв'язки між об'єктами.

Зв'язок між сутностями (об'єктами предметної області, що має атрибути) характеризується:

1. Типом зв'язку (1:1, 1: N, N: М);

2. Класом приналежності.

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

1.4 Ієрархічна, мережева та реляційна моделі представлення даних

база реляційний мережевий модель

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

При використанні ієрархічної моделі представлення даних зв'язку між даними можна охарактеризувати за допомогою упорядкованого графа (або дерева). У програмуванні при описі структури ієрархічної бази даних застосовують тип даних «дерево». Незначне число СУБД побудовано на ієрархічній моделі даних.

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

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

Реляційна модель представлення даних була розроблена співробітником фірми 1ВМЕ. Коддом. Його модель ґрунтується на понятті «ставлення» (relation). Найпростішим прикладом відносини служить двовимірна таблиця.

Більшість СУБД, застосовуваних як професійними, так і непрофесійними користувачами, побудовані на основі реляційної моделі даних (Visual FoxPro і Access фірми Microsoft, Oracle фірми Oracle та ін.)

1.5 Реляційна модель бази даних

Реляційна модель отримала свою назву від англійського слова relation (відношення) і була запропонована 1970-х роках Едгаром Коддом

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

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

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

Реляційна база даних - це реалізація реляційної моделі на фізичному рівні.

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

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

Кожна таблиця має свою структуру, яка складається з таких елементів:

1. Опис полів;

2. Ключі;

3. Індекси;

4. Обмеження на значення полів;

5. Обмеження посилочної цілісності між таблицями;

6. Права доступу.

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

У Кренке Дано таке визначення поняття «сутність»: «Сутність - це деякий об'єкт системи, що ідентифікується в робочому середовищі користувача, який має певний набір атрибутів. Атрибутом називають пойменовану характеристику сутності»

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

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

Існує декілька типів зв'язків між сутностями - один до одного, один до багатьох, багато до багатьох.

Зв'язки один до одного зустрічаються досить рідко, в основному, між сутностями надтипів та підтипів.

Зв'язки один до багатьох зустрічаються більш частіше.

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

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

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

1.6 Організація обмежень посилальної цілісності

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

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

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

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

Отже, зв'язки можна класифікувати один із трьох можливих способів:

· повні та часткові;

· обов'язкові та необов'язкові;

· слабкі та звичайні сутності.

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

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

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

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

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

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

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

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

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

У режимі форми обчислює вартість товару з націнкою магазину в 50%. Реалізує запити впорядкування по полях: товари, постачальники, ціна. Здійснює пошук відомостей про фірму-постачальника якогось товару. Проводить підрахунок вартості та кількості залишився в магазині товару, а також видає звіт про відсутніх товарах.

Застосовувана СКБД: Oracle.

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

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

- Транспорт товару до магазину

- Продаж Товарів

Підсистема «Транспорт товару до магазину»:

Вхідними даними для цієї системи є:

1) Назва фірми - постачальника

2) Країна постачальник

3) Номер поставки

4) Об'єм поставки

5) Дата поставки

6) Ціна товару

7) Назва товару

На виході маємо наступні дані:

1) Облік на звітність по всім товарам що є на складі магазина

2) Вибірка потрібної інформації з БД по запитам

Підсистема «транспорт товару до магазину» виконує наступні функції (рисунок 2.1):

Рисунок 2.1 - «Транспорт товару до магазину»

1) Ввід, вивід, оновлення та зберігання даних про поставку

2) Зберігання даних про колишні поставки та про поставника.

3)Інформацію товар на складі

4) Облік всіх товарів на складі

1) Комісія перевіряє товар від постачальника та вирішує розміри поставки

2) Комісія оцінює кінцеву ціну товару та прибуток отриманий від угоди

3) Робиться звіт по постачанню товару

4) Визначається та встановлю кінцеву ціну товару

5) Товар потрапляє на склад

6) Вся звітність потрапляє до завідуючого складу

7) Завідуючим складом відбувається перевірка складу

Зовнішні сутності
1) Постачальник - фірма або фізичні лиця яка постачають товар магазину
2) Партія - сукупність товарів які прийшли від постачальника(виробника) в один день.
3) Товар - Об'єкт відносно котрого ведеться облік
4) Склад - місце зберігання всього товару магазину
Модулі підсистеми
1) Верифікація товару - оцінка якості і початкової ціни товару, прийняття рішення о доцільності замовлення товару.
2) Оцінка товару - оцінка кінцевої ціни товару
3) Звітність по партії - інформація про розмір, дату та виробника партії
4) Перевірка складу - Запланована перевірка вмісту складу.
Підсистема «Продаж Товарів»
Вхідними даними для підсистеми є:
1) Облік Клієнтів - Платоспроможність, район міста в якому він живе та інформація про повернення товару
2) Кур'єрська служба - інформація про час доставки, ким доставлено та кількість доставлених товарів.
3) Типи товарів, їх кількість та інша інформація про товари.
Вихідними даними підсистеми є:
1)Є генерація чеку
2) Пошук в БД інформації за запитом
3) Вибірка з БД інформації
Підсистема «Продаж Товарів» виконує наступні функції (рис 2.2):
Рисунок 2.2 - Підсистема «Продаж Товарів»
1) Облік заказів клієнтів
2) Облік інформації про клієнтів
3) Облік інформації про доставку товару
Зовнішні сутності:
1) Товари - Інформація про товар
2) Курьєри - інформація про доставку товару, кількість доставленого товару клієнту та інше.
3) Клієнти - облік інформації про клієнта
4) Чек - генерація інформації про заказ клієнта
Зовнішні модулі
1) Замовлення - запис отриманій заявці
2) Обробка замовлення - перевірка наявності товару на складі та інше
3) Генерація чеку - авто генерація чеку в якому зберігається ціна замовлення, тип оплати та інше.
Мета й завдання системи:
Система буде забезпечувати зберігання, видачу й відновлення інформації підсистем інформації про товар та обліку партій (Рисунок 2.4);
а саме:
- представляти й одержувати накопичену інформацію з конкретних об'єктів;
- представляти й одержувати інформацію від підсистеми інформації облік товару;
- представляти й одержувати інформацію від підсистеми обліку партій;
- забезпечувати розмежування доступу до інформаційних ресурсів системи;
- забезпечувати моніторинг активних і пасивних користувачів і системних подій;
- забезпечувати користувачів можливістю інформаційного обміну;
- забезпечувати зв'язок між відділами та працівниками магазину;
- забезпечувати регулярне оновлення даних про товарів та склад;
- забезпечувати пошук даних за запитами

2.1 Категорії користувачів

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

- адміністратора БД;

- групи експертів.

Адміністратор системи здійснює заповнення БД інформацією, що групою експертів. Внесення змін у БД системи здійснюється лише адміністратором системи під керівництвом групи експертів. Працівники та керівники є зовнішніми користувачами, що працюють з системою відповідно до ролей доступу в інформаційно-пошуковому режимі. Можливості, що надаються користувачам системи:

- Співробітнику:

1) введення даних про товар;

2) введення даних про партію;

3) введення даних про виробника

4) перегляд зведених таблиць і графіків;

- Керівнику

1) Повну інформацію про клієнтів

2)Інформації про чек

3)Інформацію про кур'єрів;

- Адміністратору БД:

1) введення й корегування системних даних;

2) контроль роботи системи;

3) здійснення контролю захисту системи від несанкціонованого доступу;

4) зміна фізичної моделі даних системи;

- оператору:

1) інформації про товар;

2) заповнення полів БД системи (введення інформації);

3) пошук у БД даних про товар за запитом;

Під інформаційним об'єктом зберігання (інформаційним елементом) розуміється логічна однорідна одиниця інформації, для зберігання якої досить одного запису таблиці. Інформаційні об'єкти зберігання для БД системи:

А) Загального призначення:

- Виробник;

- Країна постачальник;

- Фірма або фізична лице постачальник;

- Поставка;

- Клієнти;

- Кур'єри;

- Чек;

- Склад

- Платоспроможність,

- Дата поставки та інше;

Б) Службові:

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

- запис про користувацьку транзакцію;

- рівень доступу в систему;

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

3. Концептуальне проектування

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

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

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

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

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

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

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

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

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

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

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

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

3.1 Приклад документів

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

У розглянутій предметній області можна виділити наступні сутності:

1. Поставники-містить інформацію про номер поставника, назву поставника, назву фірми поставника і степінь довіри (таблиця 3.1.1)

Таблиця 3.1.1 - Поставники

Номер поставника

Країна поставника

Назва фірми-поставника

Степінь довіри

2. Поставка - містить інформацію про номер поставки, номер поставника, кількість вантажу та дату поставки (Таблиця 3.1.2 - Поставка).

Таблиця 3.1.2 - Поставка

Номер поставки

Номер поставника

Кількість вантажу

Дата поставки

3. Інструменти - містить інформацію про товар (таблиця 3.1.3)

Таблиця 3.1.3 - Інструменти

Номер поставки

Номер поставника

Інвентарний номер

Ціна

Вага

Розмір

Тип інструменту

4. Склад - містить інформацію про номер поставки, номер поставника, інвентарний номер та інш (таблиця 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 утворюється у випадку, коли всі поля запису основної таблиці та додаткової таблиці є ключовими.

2. Зв'язок 1: М може бути у випадку, коли одного запису основної таблиці відповідає кілька записів додаткової таблиці.

3. Зв'язок М: 1 може бути тоді, коли декільком записам основної таблиці ставиться у відповідності один запис додаткової.

4. Зв'язок М: М виникає в тому випадку коли декільком записам основної таблиці відповідає кілька записів додаткової. У реляційної БД зв'язок М: М реалізується через додаткові таблиці.

Розглянемо зв'язки між виявленими сутностями:

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

2. Між атрибутами співробітники і відрядження буде зв'язок 1: М, так як співробітник може скільки завгодно разів їздити у відрядження.

3. Між атрибутами співробітники і лікарняний буде зв'язок 1: М, так як співробітник може скільки завгодно разів йти на лікарняний.

4. Між атрибутами співробітники і відпустка буде зв'язок 1: М, так як співробітник може скільки завгодно разів ходити у відпустку.

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

6. Між атрибутами співробітники і звільнення буде зв'язок 1:1, так співробітник може звільнитися тільки один раз.

7. Між атрибутами співробітники і табель робочого часу буде зв'язок 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 с.: ил. - Парал. тит. англ.

2. Конноли Т. Базы данных: проектирование и сопровождение. Теория и практика. /Т. Конноли, К. Бегг, А. Страчан.

3. Луни К. Oracle Database 10G. Полный справочник в 2 томах. / К. Луни. - М.: Издательство «Лори», 2004.

4. Дорогий Я.Ю. Методична розробка до виконання лабораторної роботи «Створення застосувань в Oracle 11G XE» [Електронне видання]. / Я.Ю. Дорогий. - К.: ІССЗІ НТУУ «КПІ», 2012.

Додаток A: SQL-код БД:

CREATE TABLE Chek

(

pay_zak INTEGER NOT NULL,

date_pay INTEGER NOT NULL,

pay_type VARCHAR2 (20) NULL

);

CREATE UNIQUE INDEX XPKЧек ON Chek

(pay_zak ASC, date_pay ASC);

ALTER TABLE Chek

ADD CONSTRAINT XPKЧек PRIMARY KEY (pay_zak, date_pay);

CREATE TABLE Dyhovue

(

tip_met VARCHAR2 (20) NULL,

vus_zv VARCHAR2 (20) NULL,

tip_di VARCHAR2 (20) NULL,

nom_post INTEGER NOT NULL,

post_no INTEGER NOT NULL,

inv_numb INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKДуховые ON Dyhovue

(nom_post ASC, post_no ASC, inv_numb ASC);

ALTER TABLE Dyhovue

ADD CONSTRAINT XPKДуховые PRIMARY KEY (nom_post, post_no, inv_numb);

CREATE TABLE Instrymentu

(

tzena INTEGER NULL,

weight INTEGER NULL,

разм INTEGER NULL,

tip_instr VARCHAR2 (20) NULL,

nom_post INTEGER NOT NULL,

post_no INTEGER NOT NULL,

inv_numb INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKИнструменты ON Instrymentu

(nom_post ASC, post_no ASC, inv_numb ASC);

ALTER TABLE Instrymentu

ADD CONSTRAINT XPKИнструменты PRIMARY KEY (nom_post, post_no, inv_numb);

CREATE TABLE Klientu

(

money CHAR(18) NULL,

mest_gor VARCHAR2 (20) NULL,

pay_zak INTEGER NOT NULL,

reback INTEGER NULL,

date_pay INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKКлиенты ON Klientu

(pay_zak ASC, date_pay ASC);

ALTER TABLE Klientu

ADD CONSTRAINT XPKКлиенты PRIMARY KEY (pay_zak, date_pay);

CREATE TABLE Kyrjeru

(

kol_svob INTEGER NULL,

kol_pole INTEGER NULL,

time INTEGER NULL,

nom_post INTEGER NOT NULL,

post_no INTEGER NOT NULL,

inv_numb INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKКурьеры ON Kyrjeru

(nom_post ASC, post_no ASC, inv_numb ASC);

ALTER TABLE Kyrjeru

ADD CONSTRAINT XPKКурьеры PRIMARY KEY (nom_post, post_no, inv_numb);

CREATE TABLE Postavka

(

kol_gr INTEGER NULL,

date_post INTEGER NULL,

nom_post INTEGER NOT NULL,

post_no INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKПоставка ON Postavka

(nom_post ASC, post_no ASC);

ALTER TABLE Postavka

ADD CONSTRAINT XPKПоставка PRIMARY KEY (nom_post, post_no);

CREATE TABLE Postavshiki

(

post_no INTEGER NOT NULL,

country VARCHAR2 (20) NULL,

Nazv_firm_post VARCHAR2 (20) NULL,

step_dov INTEGER NULL

);

CREATE UNIQUE INDEX XPKПоставщики ON Postavshiki

(post_no ASC);

ALTER TABLE Postavshiki

ADD CONSTRAINT XPKПоставщики PRIMARY KEY (post_no);

CREATE TABLE Sklad

(

Perc_skl INTEGER NULL,

kol_skl_dyx INTEGER NULL,

kol_zap_bara INTEGER NULL,

kol_skl_str INTEGER NULL,

nom_post INTEGER NOT NULL,

post_no INTEGER NOT NULL,

inv_numb INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKСклад ON Sklad

(nom_post ASC, post_no ASC, inv_numb ASC);

ALTER TABLE Sklad

ADD CONSTRAINT XPKСклад PRIMARY KEY (nom_post, post_no, inv_numb);

CREATE TABLE Strynnue

(

col_str INTEGER NULL,

Colour VARCHAR2 (20) NULL,

tip_str VARCHAR2 (20) NULL,

nom_post INTEGER NOT NULL,

post_no INTEGER NOT NULL,

inv_numb INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKСтрунные ON Strynnue

(nom_post ASC, post_no ASC, inv_numb ASC);

ALTER TABLE Strynnue

ADD CONSTRAINT XPKСтрунные PRIMARY KEY (nom_post, post_no, inv_numb);

CREATE TABLE Ydarnue

(

tip_dere VARCHAR2 (20) NULL,

kol_kyx INTEGER NULL,

nal_ram INTEGER NULL,

nog_yp VARCHAR2 (20) NULL,

tip_bara VARCHAR2 (20) NULL,

nom_post INTEGER NOT NULL,

post_no INTEGER NOT NULL,

inv_numb INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKУдарные ON Ydarnue

(nom_post ASC, post_no ASC, inv_numb ASC);

ALTER TABLE Ydarnue

ADD CONSTRAINT XPKУдарные PRIMARY KEY (nom_post, post_no, inv_numb);

ALTER TABLE Dyhovue

ADD (FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Instrymentu (nom_post, post_no, inv_numb) ON DELETE CASCADE);

ALTER TABLE Instrymentu

ADD (CONSTRAINT R_28 FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Sklad (nom_post, post_no, inv_numb));

ALTER TABLE Klientu

ADD (CONSTRAINT R_25 FOREIGN KEY (pay_zak, date_pay) REFERENCES Chek (pay_zak, date_pay));

ALTER TABLE Kyrjeru

ADD (CONSTRAINT R_31 FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Sklad (nom_post, post_no, inv_numb));

ALTER TABLE Postavka

ADD (CONSTRAINT R_21 FOREIGN KEY (post_no) REFERENCES Postavshiki (post_no));

ALTER TABLE Sklad

ADD (CONSTRAINT R_27 FOREIGN KEY (nom_post, post_no) REFERENCES Postavka (nom_post, post_no));

ALTER TABLE Strynnue

ADD (FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Instrymentu (nom_post, post_no, inv_numb) ON DELETE CASCADE);

ALTER TABLE Ydarnue

ADD (FOREIGN KEY (nom_post, post_no, inv_numb) REFERENCES Instrymentu (nom_post, post_no, inv_numb) ON DELETE CASCADE);

CREATE TRIGGER tD_Chek AFTER DELETE ON Chek for each row

- ERwin Builtin Trigger

- DELETE trigger on Chek

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Chek Klientu on parent delete restrict */

/* ERWIN_RELATION:CHECKSUM= «0000e777», PARENT_OWNER=»», PARENT_TABLE= «Chek»

CHILD_OWNER=»», CHILD_TABLE= «Klientu»

P2C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,

FK_CONSTRAINT= «R_25», FK_COLUMNS= «pay_zak»«date_pay» */

SELECT count(*) INTO NUMROWS

FROM Klientu

WHERE

/* %JoinFKPK (Klientu,:%Old,» =»,» AND») */

Klientu.pay_zak =:old.pay_zak AND

Klientu.date_pay =:old.date_pay;

IF (NUMROWS > 0)

THEN

raise_application_error (

-20001,

'Cannot delete Chek because Klientu exists.'

);

END IF;

- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tU_Chek AFTER UPDATE ON Chek for each row

- ERwin Builtin Trigger

- UPDATE trigger on Chek

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Chek Klientu on parent update restrict */

/* ERWIN_RELATION:CHECKSUM= «00011786», PARENT_OWNER=»», PARENT_TABLE= «Chek»

CHILD_OWNER=»», CHILD_TABLE= «Klientu»

P2C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,

FK_CONSTRAINT= «R_25», FK_COLUMNS= «pay_zak»«date_pay» */

IF

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

:old.pay_zak <>:new.pay_zak OR

:old.date_pay <>:new.date_pay

THEN

SELECT count(*) INTO NUMROWS

FROM Klientu

WHERE

/* %JoinFKPK (Klientu,:%Old,» =»,» AND») */

Klientu.pay_zak =:old.pay_zak AND

Klientu.date_pay =:old.date_pay;

IF (NUMROWS > 0)

THEN

raise_application_error (

-20005,

'Cannot update Chek because Klientu exists.'

);

END IF;

END IF;

- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tI_Dyhovue BEFORE INSERT ON Dyhovue for each row

- ERwin Builtin Trigger

- INSERT trigger on Dyhovue

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Instrymentu Dyhovue on child insert restrict */

/* ERWIN_RELATION:CHECKSUM= «000119f9», PARENT_OWNER=»», PARENT_TABLE= «Инструменты»

CHILD_OWNER=»», CHILD_TABLE= «Dyhovue»

P2C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,

FK_CONSTRAINT= «is_a», FK_COLUMNS= «nom_post»«post_no» «inv_numb» */

SELECT count(*) INTO NUMROWS

FROM Instrymentu

WHERE

/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */

:new.nom_post = Instrymentu.nom_post AND

:new.post_no = Instrymentu.post_no AND

:new.inv_numb = Instrymentu.inv_numb;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error (

-20002,

'Cannot insert Dyhovue because Instrymentu does not exist.'

);

END IF;

- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tU_Dyhovue AFTER UPDATE ON Dyhovue for each row

- ERwin Builtin Trigger

- UPDATE trigger on Dyhovue

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Instrymentu Dyhovue on child update restrict */

/* ERWIN_RELATION:CHECKSUM= «000118b6», PARENT_OWNER=»», PARENT_TABLE= «Инструменты»

CHILD_OWNER=»», CHILD_TABLE= «Dyhovue»

P2C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,

FK_CONSTRAINT= «is_a», FK_COLUMNS= «nom_post»«post_no» «inv_numb» */

SELECT count(*) INTO NUMROWS

FROM Instrymentu

WHERE

/*%JoinFKPK (:%New, Instrymentu,» =»,» AND») */

:new.nom_post = Instrymentu.nom_post AND

:new.post_no = Instrymentu.post_no AND

:new.inv_numb = Instrymentu.inv_numb;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error (

-20007,

'Cannot update Dyhovue because Instrymentu does not exist.'

);

END IF;

- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tI_Instrymentu BEFORE INSERT ON Instrymentu for each row

- ERwin Builtin Trigger

- INSERT trigger on Instrymentu

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Sklad Instrymentu on child insert restrict */

/* ERWIN_RELATION:CHECKSUM= «00011048», PARENT_OWNER=»», PARENT_TABLE= «Sklad»

CHILD_OWNER=»», CHILD_TABLE= «Instrymentu»

P2C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,

FK_CONSTRAINT= «R_28», FK_COLUMNS= «nom_post»«post_no» «inv_numb» */

SELECT count(*) INTO NUMROWS

FROM Sklad

WHERE

/*%JoinFKPK (:%New, Sklad,» =»,» AND») */

:new.nom_post = Sklad.nom_post AND

:new.post_no = Sklad.post_no AND

:new.inv_numb = Sklad.inv_numb;

IF (

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

NUMROWS = 0

)

THEN

raise_application_error (

-20002,

'Cannot insert Instrymentu because Sklad does not exist.'

);

END IF;

- ERwin Builtin Trigger

END;

/

CREATE TRIGGER tD_Instrymentu AFTER DELETE ON Instrymentu for each row

- ERwin Builtin Trigger

- DELETE trigger on Instrymentu

DECLARE NUMROWS INTEGER;

BEGIN

/* ERwin Builtin Trigger */

/* Instrymentu Dyhovue on parent delete cascade */

/* ERWIN_RELATION:CHECKSUM= «0002730b», PARENT_OWNER=»», PARENT_TABLE= «Инструменты»

CHILD_OWNER=»», CHILD_TABLE= «Dyhovue»

P2C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,

FK_CONSTRAINT= «is_a», FK_COLUMNS= «nom_post»«post_no» «inv_numb» */

DELETE FROM Dyhovue

WHERE

/* %JoinFKPK (Dyhovue,:%Old,» =»,» AND») */

Dyhovue.nom_post =:old.nom_post AND

Dyhovue.post_no =:old.post_no AND

Dyhovue.inv_numb =:old.inv_numb;

/* ERwin Builtin Trigger */

/* Instrymentu Ydarnue on parent delete cascade */

/* ERWIN_RELATION:CHECKSUM= «00000000», PARENT_OWNER=»», PARENT_TABLE= «Инструменты»

CHILD_OWNER=»», CHILD_TABLE= «Ydarnue»

P2C_VERB_PHRASE=»», C2P_VERB_PHRASE=»»,

FK_CONSTRAINT= «is_a», FK_COLUMNS= «nom_post»«post_no» «inv_numb» */

DELETE FROM Ydarnue

WHERE

/* %JoinFKPK (Ydarnue,:%Old,» =»,» AND») */

Ydarnue.nom_post =:old.nom_post AND

Ydarnue.post_no =:old.post_no AND

Ydarnue.inv_numb =:old.inv_numb;

/* ERwin Builtin Trigger */


Подобные документы

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

    курсовая работа [417,6 K], добавлен 01.02.2013

  • Основні підходи до проектування баз даних. Опис сайту Інтернет-магазину, характеристика його підсистем для обробки анкет і запитів користувачів. Розробка концептуальної, інфологічної, даталогічної, фізичної моделей даних. Побудова ER-моделі в CASE-засоби.

    курсовая работа [2,3 M], добавлен 01.02.2013

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

    курсовая работа [3,5 M], добавлен 28.11.2011

  • Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.

    курсовая работа [8,8 M], добавлен 16.12.2015

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

    курсовая работа [2,4 M], добавлен 08.09.2012

  • Проектування інформаційної системи; концептуальне (інфологічне) проектування, побудова ER-діаграми, нормалізація даних. Даталогічне проектування баз даних, фізичне проектування інформаційних систем. СУБД Access: об'єкти, створення таблиць, запитів, форм.

    курсовая работа [13,9 M], добавлен 09.01.2010

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

    курсовая работа [1,4 M], добавлен 24.10.2010

  • Даталогічне проектування баз даних та концептуальне (інфологічне) проектування (побудова ER-діаграми та нормалізація даних) інформаційної системи. Фізичне проектування інформаційних систем (СУБД Access: об’єкти бази, створення таблиць, запитів та форм).

    курсовая работа [3,5 M], добавлен 09.01.2010

  • Використання баз даних та інформаційних систем. Поняття реляційної моделі даних. Ключові особливості мови SQL. Агрегатні функції і угрупування даних. Загальний опис бази даних. Застосування технології систем управління базами даних в мережі Інтернет.

    курсовая работа [633,3 K], добавлен 11.07.2015

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

    курсовая работа [55,1 K], добавлен 15.03.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.