Розробка бази даних та застосування для авторизованої інформаційної системи "Інтернет магазин шин"
Процес створення бази даних, призначеної для обліку інтернет магазина з продажу шин, обліку покупців та проданих товарів. Проведення підготовки інформації для внесення в базу даних. Аналіз проектування інформаційних систем та побудова ER-моделі.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | украинский |
| Дата добавления | 01.02.2013 |
| Размер файла | 1,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
МІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ
ІНСТИТУТ СПЕЦІАЛЬНОГО ЗВЯЗКУ ТА ЗАХИСТУ ІНФОРМАЦІЇ
НАЦІОНАЛЬНОГО ТЕХНІЧНОГО УНІВЕРСИТЕТУ УКРАЇНИ
«КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ»
КАФЕДРА КІБЕРБЕЗПЕКИ ТА ЗАСТ
Курсову робота з дисципліни: Організація баз даних та знань
Тема: Розробка бази даних та застосування для авторизованої інформаційної системи "Інтернет магазин шин"
курсант групи С 16
Дудкін В.І.
Вступ
В даний час серед розробників бази даних (БД) великою популярністю користується реляційна СУБД Oracle. Дружній інтерфейс і простота настройки, ефективні засоби створення таблиць, форм, запитів, інтеграція з іншими додатками пакета, засоби організації роботи з базами даних і захист інформації - ось далеко не повний перелік переваг цього додатка.
Основні функції СУБД - це опис структури бази даних, обробка даних і управління даними.
База даних - це сукупність відомостей про реальні об'єкти, процеси, події або явища, що відносяться до певної теми або завдання, організована таким чином, щоб забезпечити зручне представлення цієї сукупності, як в цілому, так і будь-який її частини. Реляційна база даних являє собою безліч взаємопов'язаних таблиць, кожна з яких містить інформацію про об'єкти певного типу.
Кожен рядок таблиці містить дані про один об'єкт (наприклад, клієнті, автомобілі, документі), а стовпці таблиці містять різні характеристики цих об'єктів - атрибути (наприклад, найменування та адреси клієнтів, марки і ціни автомобілів). Рядки таблиці називаються записами, всі записи мають однакову структуру - вони складаються з полів, в яких зберігаються атрибути об'єкта. Кожне поле в записі містить одну характеристику об'єкта і має строго певний тип даних (наприклад, текстовий рядок, число, дата). Усі записи мають одні й ті ж поля, тільки в них містяться різні значення атрибутів.
Будь СУБД дозволяє виконувати чотири найпростіші операції з даними:
- Додати в таблицю одну або декілька записів;
- Видалити з таблиці одну або декілька записів;
- Оновити значення деяких полів в одній або декількох записах;
- Знайти одну або кілька записів, що задовольняють заданій умові.
Для виконання цих операцій використовується механізм запитів. Результатом виконання запитів є або відібране за певними критеріями безліч записів, або зміна в таблицях.
1. Аналіз відомих підходів до проектування баз даних
Проектування баз даних - процес створення схеми бази даних і визначення необхідних обмежень цілісності.
1.1 Основні завдання проектування баз даних
Основні завдання:
1. Забезпечення зберігання в БД всієї необхідної інформації.
2. Забезпечення можливості отримання даних по всім необхідним запитам.
3. Скорочення надмірності та дублювання даних.
4. Забезпечення цілісності даних (правильності їх змісту): виключення суперечностей у змісті даних, виключення їх втрати і т.д..
1.2 Основні етапи проектування баз даних
Концептуальне (Інфологіческое) проектування - побудова семантичної моделі предметної області, тобто інформаційної моделі найбільш високого рівня абстракції. Така модель створюється без орієнтації на якусь конкретну СУБД і модель даних. Терміни «семантична модель», «концептуальна модель» і «інфологіческая модель» є синонімами. Крім того, в цьому контексті рівноправно можуть використовуватися слова «модель бази даних» і «модель предметної області» (наприклад, «концептуальна модель бази даних» і «концептуальна модель предметної області»), оскільки така модель є як спосіб реальності, так і спосіб проектованої бази даних для цієї реальності.
Конкретний вид і зміст концептуальної моделі бази даних визначається вибраним для цього формальним апаратом. Зазвичай використовуються графічні нотації, подібні ER-діаграм.
Найчастіше концептуальна модель бази даних включає в себе:
- опис інформаційних об'єктів, або понять предметної області і зв'язків між ними.
- опис обмежень цілісності, тобто вимог до допустимих значень даних і до зв'язків між ними.
Логічне (Даталогіческое) проектування - створення схеми бази даних на основі конкретної моделі даних, наприклад, реляційної моделі даних. Для реляційної моделі даних даталогіческіе модель - набір схем відносин, зазвичай із зазначенням первинних ключів, а також «зв'язків» між відносинами, що представляють собою зовнішні ключі.
Перетворення концептуальної моделі в логічну модель, як правило, здійснюється за формальними правилами. Цей етап може бути в значній мірі автоматизований.
На етапі логічного проектування враховується специфіка конкретної моделі даних, але може не враховуватися специфіка конкретної СУБД.
Фізичне проектування - створення схеми бази даних для конкретної СУБД. Специфіка конкретної СУБД може включати в себе обмеження на іменування об'єктів бази даних, обмеження на підтримувані типи даних і т.п. Крім того, специфіка конкретної СУБД при фізичному проектуванні включає вибір рішень, пов'язаних з фізичним середовищем зберігання даних (вибір методів управління дискової пам'яттю, поділ БД по файлах і пристроям, методів доступу до даних), створення індексів і т.д.
1.3 Моделі «сутність-зв'язок»
Основна стаття: ER-модель даних:
Модель «сутність-зв'язок» (англ. "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) ефективне використання пам'яті ЕОМ;
2) висока швидкість виконання основних операцій над даними;
3) зручність роботи з ієрархічно впорядкованою інформацією.
До недоліків ієрархічної моделі представлення даних відносяться:
1) громіздкість такої моделі для обробки інформації з досить складними логічними зв'язками;
2) труднощі в розумінні її функціонування звичайним користувачем.
Незначне число СУБД побудовано на ієрархічній моделі даних.
Мережева модель може бути представлена як розвиток і узагальнення ієрархічної моделі даних, що дозволяє відображати різноманітні взаємозв'язки даних у вигляді довільного графа.
Достоїнствами мережевої моделі представлення даних є:
1) ефективність у використанні пам'яті комп'ютера;
2) висока швидкість виконання основних операцій над даними;
3) величезні можливості (більші, ніж у ієрархічній моделі) освіти довільних зв'язків.
До недоліків мережевої моделі представлення даних відносяться:
1) висока складність і жорсткість схеми бази даних, яка побудована на її основі;
2) складність для розуміння і виконання обробки інформації в базі даних непрофесійним користувачем.
Системи управління базами даних, побудовані на основі мережної моделі, також не отримали широкого розповсюдження на практиці.
Реляційна модель представлення даних була розроблена співробітником фірми 1ВМЕ. Кодом. Його модель ґрунтується на понятті «ставлення» (relation). Найпростішим прикладом відносини служить двовимірна таблиця.
Достоїнствами реляційної моделі представлення даних (у порівнянні з ієрархічною і мережевий моделями) є її зрозумілість, простота і зручність практичної реалізації реляційних баз даних на ЕОМ.
До недоліків реляційної моделі представлення даних відносяться:
1) відсутність стандартних засобів ідентифікації окремих записів;
2) складність опису ієрархічних і мережевих зв'язків.
Більшість СУБД, застосовуваних як професійними, так і непрофесійними користувачами, побудовані на основі реляційної моделі даних (Visual FoxPro і Access фірми Microsoft, Oracle фірми Oracle та ін.).
1.5 Реляційна модель бази даних
Реляційна модель отримала свою назву від англійського слова relation (відношення) і була запропонована 1970-х роках Едгаром Кодом.
Ця модель являє собою сукупність таблиць, зв'язаних відношенням. Різниця між таблицею у звичному розумінні і поняттям відношення полягає в тому, що у відношенні не має порядку - це впорядкована множина записів. Порядок визначається не відношенням, а чіткою вибіркою із відношення.
Достоїнствами реляційної моделі даних є простота, гнучкість структури, зручність реалізації на комп'ютері, висока стандартизованість.
До недоліків можна віднести обмеженість і попереднє визначення набору можливих типів даних. Це ускладнює використання реляційної моделі для деяких сучасних додатків.
Реляційна база даних - це реалізація реляційної моделі на фізичному рівні. Конструкція реляційної моделі має широкий та загальний характер, вона дозволяє описувати структуру бази даних незалежним від СКБД чином. Крім того, реляційна модель є основою майже усіх СКБД.
Відношення - це двомірна таблиця. Кожен рядок в таблиці містить дані, які відносяться до якоїсь речі або її частини . кожен стовпчик таблиці описує який-небудь атрибут цієї речі. Іноді рядки називають кортежами, а стовпці - атрибутами.
Кожна таблиця має свою структуру, яка складається з таких елементів:
1. описання полів;
2. ключі;
3. індекси;
4. обмеження на значення полів;
5. обмеження посилочної цілісності між таблицями;
6. права доступу.
Назва кожного з атрибутів складається з двох частин, розділених двокрапкою. Перша частина назви - ім'я атрибуту, друга - ім'я домену.
Домен атрибуту - це вид даних, які представляє даний атрибут. На практиці домен в заголовках часто не використовується.
Щоб таблиця була відношенням, вона повинна задовольняти певні обмеження. По-перше, значення в комірках таблиці повинні бути одиночними. Усі записи в стовпці повинні бути одного типу. Кожен стовпець має унікальне ім'я; порядок стовпців в таблиці не важливий. У відношенні не може бути двох однакових рядків, і поряд рядків неважливий. Відношення може мати нульове число кортежів. Відношення являє собою набір елементів у цьому наборі за визначенням унікально ідентифіковані. Тому щоб таблиця була відношенням, кожен її рядок повинен бути унікально ідентифікованим, записи в ній не повинні повторюватись.
Кожне відношення можна розділити на дві частини - заголовок і тіло. Тіло відношення складається з кортежів.
Функціональна залежність - це зв'язок між атрибутами. Наприклад, якщо ми знаємо значення одного атрибуту , то зможемо знайти значення другого.
В функціональні залежності можуть входити групи атрибутів.
Група одного або більше атрибутів, які унікальним чином ідентифікують рядок називаються - ключем. Кожне відношення має мінімум один ключ. Ключі завжди є унікальними. Тому коли атрибут є ключем - це означає, що цей атрибут або комбінація будуть унікальними.
Ключ забезпечує:
1. однозначну ідентифікацію записів таблиці;
2. запобігає повторенню значень ключа;
3. прискорення виконання записів до БД;
4. встановлення зв'язків між окремими таблицями БД;
5. використання обмежень посилочної цілісності.
Індекс, як і ключ, будується по полям таблиці, але він може допускати повторення значень, які складають його поля. Поля, по яким побудований індекс, називається індексним. Простий індекс складається з одного поля, а складний - з декількох.
Використання індексу забезпечує:
1. збільшення швидкості доступу (пошуку) до даних;
2. сортування записів;
3. встановлення обмежень посилочної цілісності.
Модель даних - найабстрактніший рівень проектування баз даних. Елементами описання моделі даних є сутності, атрибути, домени та відношення.
У Кренке Дано таке визначення понятту “сутність”: “Сутність- це деякий об'єкт системи, що ідентифікується в робочому середовищі користувача, який має певний набір атрибутів. Атрибутом називають пойменовану характеристику сутності”.
Домен - це набір усіх допустимих значень, які може містити даний атрибут. Визначення домену включає в себе більш детальний опис допустимих значень даних.
Крім атрибутів кожної сутності модель даних повинна визначати зв'язки між сутностями. На концептуальному рівні зв'язки представляють собою проектні асоціації між сутностями.
Існує декілька типів зв'язків між сутностями - один до одного, один до багатьох, багато до багатьох.
Зв'язки один до одного зустрічаються досить рідко, в основному, між сутностями надтипів та підтипів.
Зв'язки один до багатьох зустрічаються більш частіше.
Зв'язки багато до багатьох неможливо реалізувати в реляційній моделі, але її перетворена реалізація досить проста та однозначна.
Участь кожної сутності в певному зв'язку може бути частковою або повною. Якщо існування даної сутності повністю визначається її участю у зв'язку, то така участь буде повною, в іншому випадку - частковою.
Один із самих важливих і тонких моментів в процесі створення моделі даних - схема повинна містити вірні значення зв'язків для кожної сутності протягом всього строку експлуатації системи.
1.6 Організація обмежень посилальної цілісності
Одним з основних понять щодо структури БД - є поняття її об'єкту або сутності. Будь-який об'єкт, який розглядається в БД як окремий та автономний від інших; будь який процес - може бути сутністю. Всі сутності однієї бази даних, як правило, зв'язані між собою.
Сутності, між якими існують зв'язки, називаються учасниками, а число учасників зв'язку - розмірністю зв'язку. Більшість зв'язків між сутностями - це подвійні зв'язки, тобто такі в яких беруть участь дві сутності. Зустрічаються також унарні та потрійні зв'язки.
Участь кожної сутності у зв'язку буває повною або частковою, залежності від того, чи може ця сутність існувати, якщо даний зв'язок не визначений.
Сутності також класифікуються на слабкі та звичайні. Слабкі сутності можуть існувати тільки при на явності зв'язків з іншими сутностями, у той час коли звичайні сутності існують незалежно від наявності зв'язків між ними і іншими сутностями.
Отже, зв'язки можна класифікувати один із трьох можливих способів:
- повні та часткові;
- обов'язкові та необов'язкові;
- слабкі та звичайні сутності.
Зв'язки один до одного між двома сутностями - це такі зв'язки, при яких кожен екземпляр однієї сутності може буди зв'язаним тільки з одним з одним екземпляром другої сутності.
Хоча зв'язки типу один до одного в реальному світі зустрічаються досить рідко, в проектуванні баз даних вони широко використовуються, наприклад, для зменшення числа атрибутів у відношеннях, а також при моделюванні підкласів сутностей. Існують обмеження числа полів в таблиці. Звичайно моделі даних не виходять за рамки цих обмежень, оскільки таблиці з такою великою кількістю полів зустрічаються досить рідко.
Визначити, яке з відношень, що беруть участь у зв'язку один до багатьох буде посилаючимся, а яке - посилочним, дуже просто. Так як відношення, яке бере участь у зв'язку один до багатьох, зі сторони один завжди є посилальними, і його ключ-кандидат копіюється у відношення, яке бере участь у зв'язку зі сторони „багато”, яке є посилаючимся. Ключ-кандидат посилочного відношення часто виступає як частина, яка входить до складу відношення, яке бере участь у зв'язку зі сторони „багато”, але не забезпечує унікальну ідентифікацію кортежів посилаючогося відношення. Щоб сформувати ключ-кандидат посилаючогося відношення, ключ посилочного відношення слід скомбінувати з декількома іншими атрибутами.
Зв'язки багато до багатьох часто зустрічаються у реальному світі, але в реляційній базі даних реалізувати такий зв'язок неможливо. При моделюванні використовують проміжкові зв'язки до один до багатьох з кожним з відношенням - учасників зв'язку багато до багатьох. Таке проміжкові відношення називається проміжковою таблицею. Відношення, яке бере участь у зв'язку „один до багатьох” зі сторони „один” завжди є посилочним. Це значить, що всі попередні сутності, тобто сутності, які беруть участь у зв'язку „багато до багатьох”, заміненої двома зв'язками „один до багатьох”, в даній моделі будуть посилочними відношеннями, а проміжкова таблиця - посилаючимся. Ключі-кандидати проміжковою таблиці включають ключі-кандидати попередніх відношень, зв'язаних з проміжковою таблицею. В унарних зв'язках існує тільки один учасник - відношення зв'язане з собою. Принципи моделювання таких зв'язків не відрізняються від принципу моделювання зв'язків між двома учасниками. Єдина різниця в тому, що ссилочне та ссилаюче відношення у даному випадку - одне і теж відношення.
Унарні зв'язки можуть мати різну потужність. Унарні зв'язки „один до багатьох” допомагають реалізувати ієрархії. Унарні зв'язки „багато до багатьох”, як і подвійні зв'язки цього типу, реалізуються за допомогою проміжкових таблиць. Такі зв'язки можуть бути необов'язкові для одної із сторін.
Потрійні зв'язки не можливо безпосередньо моделювати в реляційній базі даних, і в цьому полягає їх відмінність від відношення багато до багатьох.
2. Аналіз предметної області
В даному курсовому проекті в якості предметної області розглядається комп'ютерний магазин шин. Наша база даних вирішує наступні завдання: облік товару, видача даних про постачальників і поставляються ними товари (фірма-постачальник, його реквізити, найменування товарів, характеристики, ціни), обчислює суми оплати.
У режимі форми обчислює вартість товару з націнкою магазину в 50%. Реалізує запити впорядкування по полях: товари, постачальники, ціна. Здійснює пошук відомостей про фірму-постачальника якогось товару. Проводить підрахунок вартості та кількості залишився в магазині товару, а також видає звіт про відсутніх товарах.
Застосовувана СКБД: Oracle.
Вихідні дані про магазин: магазин розташовується в декількох приміщеннях (склад, торговий зал). У фірми є постачальники, здійснюють поставку шин на склад магазину. Так само в магазині є свій штат співробітників: менеджери і консультанти, які здійснюють продаж товару, бухгалтер, комірники, вантажники-водії. Клієнт, приходячи в магазин, взаємодіє з менеджером, який, у свою чергу, здійснює продаж шин. Операції з коштами і відбиття чека здійснює так само менеджер. При купівлі товару, клієнт отримує чек із зазначенням товару та його вартості, на підставі якого зі складу йому відвантажують необхідний товар. При відсутності товару на складі працівник магазину вибирає відсутні товари та на підставі цих даних складає заявку на ім'я фірми-постачальника.
- Оновити значення деяких полів в одній або декількох записах;
- Знайти одну або кілька записів, що задовольняють заданій умові.
Для виконання цих операцій використовується механізм запитів. Результатом виконання запитів є або відібране за певними критеріями безліч записів, або зміна в таблицях.
Система складається з декількох підсистем:
- Транспорт товару до магазину
- Продаж Товарів
2.1 Підсистема «Транспорт товару до магазину»:
Вхідними даними для цієї системи є:
1) Назва фірми - постачальника
2) Країна постачальник
3) Номер поставки
4) Об'єм поставки
5) Дата поставки
6) Ціна товару
7) Назва товару
На виході маємо наступні дані:
1) Облік на звітність по всім товарам що є на складі магазина
2) Вибріка потрібної інформації з БД по запитам
Підсистема «транспорт товару до магазину» виконує наступні функції:
1) Ввід, вивід ,оновлення та зберігання даних про поставку
2) Зберігання даних про колишні поставки та про поставшика
3) Інформацію товар на складі
4) Облік всіх товарів на складі
1) Комісія перевіряє товар від постачальника та вирішує розміри поставки
2) Комісія оцінює кінцеву ціну товару та прибуток отриманий від угоди
3) Робиться звіт по постачанню товару
4) Визначається та встановлю кінцеву ціну товару
5) Товар потрапляє на склад
6) Вся звітність потрапляє до завідуючого складу
7) Завідуючим складом відбувається перевірка складу
Рис 2.1 - «Транспорт товару до магазину»:
2.1.1 Зовнішні сутності
1) Постачальник - фірма або фізичні лиця яка постачають товар магазину.
2) Партія - сукупність товарів які прийшли від постачальника(виробника) в один день.
3) Товар - Об'єкт відносно котрого ведеться облік.
4) Склад - місце зберігання всього товару магазину.
2.1.2 Модулі підсистеми
1) Веріфікація товару - оцінка якості і початкової ціни товару.
2) Оцінка товару - оцінка кінцевої ціни товару.
3) Звітність по партії - інформація про розмір, дату та виробника партії.
4) Перевірка складу - Запланована перевірка вмісту складу.
2.1 Підсистема «Продаж Товарів»
Вхідними даними для підсистеми є:
1) Облік Клієнтів:
Сплатоспроможність, район міста в якому він живе та інформація про повернення товару.
2) Кур'єрська служба:
Інформація про час доставки, ким доставлено та кількість доставлених товарів.
3) Типи товарів, їх кількість та інша інформація про товари.
Вихідними даними підсистеми є:
1) Є генерація чеку
2) Пошук в БД інформації за запитом
3) Вибірка з БД інформації
2.1.2 Підсистема «Продаж Товарів» виконує наступні функції:
1) Облік заказів клієнтів
2) Облік інформації про клієнтів
3) Облік інформації про доставку товару
Рис 2.2 - Підсистема «Продаж Товарів»:
Зовнішні сутності:
1) Товари - Інформація про товар.
2) Курьєри - інформація про доставку товару, кількість доставленого товару клієнту та інше.
3) Клієнти - облік інформації про клієнта.
4) Чек - генерація інформації про заказ клієнта.
Зовнішні модулі:
1) Заказ - запис поступленій заявці.
2) Обробка заказу - перевірка наявності товару на складі та інше
3) Генерація чеку - авто генерація чеку в якому зберігається ціна заказу,тип оплати та інше.
Мети й завдання системи:
Система буде забезпечувати зберігання, видачу й відновлення інформації підсистем інформації про товар та обліку партій;
а саме:
- представляти й одержувати накопичену інформацію з конкретних об'єктів;
- представляти й одержувати інформацію від підсистеми інформації облік товару;
- представляти й одержувати інформацію від підсистеми обліку партій;
- забезпечувати розмежування доступу до інформаційних ресурсів системи;
- забезпечувати моніторинг активних і пасивних користувачів і системних подій;
- забезпечувати користувачів можливістю інформаційного обміну;
- забезпечувати зв'язок між відділами та працівниками магазину;
- забезпечувати регулярне оновлення даних про товарів та склад;
- забезпечувати пошук даних за запитами.
2.4 Категорії користувачів
При роботі з системою на стадіях заповнення, експлуатації БД необхідна участь наступних категорій користувачів:
- адміністратора БД;
- групи експертів.
Адміністратор системи здійснює заповнення БД інформацією, що групою експертів. Внесення змін у БД системи здійснюється лише адміністратором системи під керівництвом групи експертів. Працівники та начальники є зовнішніми користувачами, що працюють з системою відповідно до ролей доступу в інформаційно-пошуковому режимі. Можливості, що надаються користувачам системи:
Співробітнику:
1) o введення даних про товар;
2) о введення даних про партію;
3) о введення даних про виробника
4) o перегляд зведених таблиць і графіків;
Начальнику:
1) Повну інформацію про клієнтів
2) Інформації про чек
3) Інформацію про курьєрів;
Адміністратору БД:
- o введення й корегування системних даних;
- o контроль роботи системи;
- o здійснення контролю захисту системи від несанкціонованого доступу;
- зміна фізичної моделі даних системи;
- оператору: o інформації про товар; o заповнення полів БД системи (введення інформації);
- o пошук у БД даних про товар за запитом;
Під інформаційним об'єктом зберігання (інформаційним елементом) розуміється логічна однорідна одиниця інформації, для зберігання якої досить одного запису таблиці. Інформаційні об'єкти зберігання для БД системи:
А. Загального призначення:
- Виробник;
- Країна постачальник;
- Фірма або фізична лице постачальник;
- Поставка;
- Клієнти;
- Курьєри;
- Чек;
- Склад;
- Сплатоспроможність,
- Дата поставки та інше;
Б. Службові:
- запис про активне з'єднання;
- запис про користувацьку транзакцію;
- рівень доступу в систему;
- обліковий запис повноважень користувача (для організації захисту від несанкціонованого доступу).
3. Концептуальне проектування
Мета інфологічного моделювання - забезпечення найбільш природних для людини способів збору й представлення тієї інформації, яку передбачається зберігати в створюваній базі даних.
Тому інфологічну модель даних намагаються будувати за аналогією з природною мовою (остання не може бути використана у чистому вигляді через складність комп'ютерної обробки текстів і неоднозначності будь-якої природної мови).
Основними конструктивними елементами інфологічної моделі є сутності, зв'язки між ними, ідентифікатори (ключі) та властивості (атрибути).
Сутність - кожний помітний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про який необхідно зберігати в базі даних.
Необхідно розрізняти такі поняття, як тип сутності й екземпляр сутності. Екземпляр сутності відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути КОМП'ЮТЕР , а екземпляром - Asus, Acer і т.д.
Атрибут - пойменована характеристика сутності.
Його назва повинна бути унікальною для конкретного типу сутності, але може бути однаковою для різного типу сутностей.
Абсолютна відмінність між типами сутностей і атрибутами відсутня.
Атрибут є таким тільки у зв'язку з типом сутності. В іншому контексті атрибут може виступати як самостійна сутність.
Ключ - мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності.
Зв'язок - асоціювання двох або більше сутностей. Якби призначенням бази даних було тільки зберігання окремих, не зв'язаних між собою даних, то її структура могла б бути дуже простою. Однак, одна з основних вимог до організації бази даних - це забезпечення можливості пошуку одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки. При побудові інфологічних моделей можна використовувати мову ER- діаграм.
У них сутності зображуються позначеними прямокутниками, асоціації - позначеними ромбами або шестикутниками, атрибути - позначеними овалами, а зв'язки між ними - ненаправленими ребрами, над якими може проставлятися ступінь зв'язку.
3.1 Приклад документів
Сутність - об'єкт будь-якої природи дані, про якому зберігаються у відношенні (таблиці, в якій містяться дані).
У розглянутій предметній області можна виділити наступні сутності:
1. Товар-містить інформацію про ціну, дату виробництва, фірму виробника та інше.
Таблиця 3.1 Документ «Шини»:
|
Номер поставки |
Номер поставника |
Інвентарний номер |
Ціна |
Назва |
Фірма |
|
|
… |
… |
… |
… |
… |
… |
|
|
… |
… |
… |
… |
… |
… |
2. Постачальник - містить інформацію про країну постачальник, назву фірми постачальника, степень довіри та інше(таб 3.2).
Таблиця 3.2 Документ «Поставники»:
|
Номер поставника |
Страна поставника |
Назва фірми поставника |
Степінь довіри |
|
|
… |
… |
… |
… |
|
|
… |
… |
… |
… |
3. Поставка - містить інформацію про кількість грузу, дату поставку.
Таблиця 3.3 - Документ «Поставка»:
|
Номер поставки |
Назва поставника |
Кількість грузу |
Дата поставки |
|
4.Склад - містить інформацію про процент заповнення складу, кількість відео плат, материнських карт та перефірійних пристроїв на складі(Таб 3.4).
Таблиця 3.4 - Документ «Склад»:
|
Номер поставки |
Номер поставника |
Інвентарний номер |
Відсоток заповнення складу |
Кількість зимової гуми на складі |
Кількість літньої гуми на складі |
Кількість демісезонної гуми на складі |
|
|
… |
… |
… |
… |
… |
… |
||
|
… |
… |
… |
… |
… |
… |
3.2 Побудова ER-діаграми:
Рис. 3.1 - ER-Діаграма «Постачальник - поставка»:
Рис.3.2 - ER-Діаграма «Поставка - склад»:
Рис. 3.3 - ER-Діаграма «Склад - Товар»:
Рис. 3.4 - Загальна ER-діаграма системи:
3.3 Виділення об'єктів довідкової інформації
Визначимо функціональні залежності між реквізитами документа "Товар", попередньо включивши їх перелік у таблицю. З аналізу документа очевидно, що реквізити назва фірми, країна постачальник, степень довіри є описовими і кожний з них залежить тільки від ключового реквізиту - номер постачальника, який у той же час виконує роль загального ідентифікатора списку постачальників. Реквізити - Назва товару, Ціна товару, Фірма однозначно визначаються ключовим реквізитом Таб. номер Товару. Зверніть увагу на зв'язок реквізитів номер постачальника і Таб. номер Товару. У цьому функціональному зв'язку виконується необхідна умова - одному значенню ключа Таб. номер Товару відповідає одне значення залежного реквізиту Код Постачальника. Цей реквізит відіграє роль описового реквізиту для співробітника. Якщо такий зв'язок не встановлений, то вся множина реквізитів документа розділиться на дві не зв'язані між собою підмножини, а це є нелогічним для реквізитів одного документа. Всі встановлені функціональні залежності реквізитів документа "Список товарів" відбиті в табл. 3.12
Таблиця 3.12 - "Список товарів постачальника":
|
Документ |
Найменування реквізитів |
Назва реквізиту |
Функціональні залежності |
|
|
Список Товарів постачальника |
Код постачальника |
Код відділу |
||
|
Назва постачальника |
Назва відділу |
|||
|
Країна постачальника |
Адреса відділу |
|||
|
Начальник відділу |
||||
|
Таб.номер товару |
Таб.номер |
|||
|
Ціна |
П.І.Б. |
|||
|
Фірма |
Посада |
Код постачальника одночасно виступає в ролі описового реквізиту в одному зв'язку й ключового - в іншому зв'язку. Таким чином, тут виникає транзитивна залежність.
Реквізит Назва постачальника транзитивно залежить від Таб. номер через Код постачальника. Проте спеціальних дій по розщепленню цієї залежності не потрібно при використанні наведених правил.
Виберемо за функціональними зв'язками реквізити, що залежать від інших реквізитів і вкажемо для них ключові реквізити.
Так, при перегляді списку реквізитів зверху знаходимо перший залежний (описовий) реквізит Код постачальника і визначаємо його ключовий реквізит Таб. номер.
Далі знаходимо другий залежний (описовий) реквізит Назва постачальника і визначаємо ключовий. Аналогічно знаходимо описовий реквізит адреса відділу і визначаємо ключовий і так далі. Виявлена відповідність описових і ключових реквізитів представлене нижче в таблиці 3.13.
Таблиця 3.13 «Відповідність описових і ключових реквізитів документа»:
|
Описові (залежні) |
реквізити Ключові реквізити |
|
|
Код постачальника |
Таб. номер |
|
|
Назва постачальника |
Номер постачальника |
|
|
Країна постачальника |
Номер постачальника |
|
|
Степень довіри |
Номер постачальника |
|
|
Таб.номер |
Таб. номер |
|
|
Ціна |
Таб. номер |
|
|
Фірма |
Таб. номер |
Згрупуємо реквізити, залежні від тих самих ключових реквізитів, і об'єднаємо їх з ключовими реквізитами в один інформаційний об'єкт. Результат групування реквізитів документа "Список товарів постачальника" наведений у табл. 3.14.
Таблиця 3.14 Групування реквізитів за інформаційними об'єктами документа «Список товарів постачальника»:
|
Реквізити об'єкта |
Ознака унікальності ключа |
Назва інформаційного об'єкта |
Семантика об'єкта |
|
|
Код постачальника |
П,У |
Постачальник |
Відомості про всі постачальники |
|
|
Назва постачальника |
||||
|
Країна постачальника |
||||
|
Степень довіри |
||||
|
Ціна |
Товар |
Відомості про всі товари |
||
|
Таб.номер |
П,У |
|||
|
Назва |
||||
|
Посада |
4. Інфологіческое проектування БД
4.1 Модель «сутність-зв'язок»
Інфологіческая модель повинна включати таке формалізований опис предметної області, яке легко буде "читатися" не тільки фахівцями по базах даних.
Інфологіческое проектування, насамперед, пов'язано зі спробою представлення семантики предметної області в моделі БД. Реляційна модель даних у силу своєї простоти і лаконічності не дозволяє відобразити семантику, тобто зміст предметної області.
Проблема подання семантики давно цікавила розробників, і в сімдесятих роках було запропоновано кілька моделей даних, названих семантичними моделями. До них можна віднести семантичну модель даних, запропоновану Хаммером (Hammer) і Мак-Леоном (McLeon) в 1981 році, функціональну модель даних Шипман (Shipman), також створену в 1981 році, модель "сутність-зв'язок", запропоновану Ченом (Chen) в 1976 році, і ряд інших моделей. У всіх моделей були свої позитивні і негативні сторони, але випробування часом витримала лише остання. І зараз саме модель Чена "сутність-зв'язок", або "EntityRelationship", стала фактичним стандартом при інфологіческого моделювання баз даних.
Модель «сутність-зв'язок» називають також «ER-моделлю» (essence-сутність, relation-зв'язок). .
4.2 Класифікація зв'язків
Пріпроектірованіе БД інформацію зазвичай розміщують у кількох таблицях. Таблиці при цьому пов'язують з семантикою інформації. В реляційній СКБД для вказівки зв'язків в таблиці виробляють операції їх зв'язування. Розглянемо найбільш часто зустрічаються бінарні зв'язки:
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, так як одному співробітнику відповідає тільки один запис кожного місяця у табелі.
5. Реляційна модель БД
Реляційна модель баз даних була запропонована співробітником фірми IBM Е. Кодом на початку 70-х років. Будучи математиком, він запропонував використовувати для обробки даних апарат теорії множин (об'єднання, перетин, різниця і Декартово твір). Він показав, що будь-яке представлення даних зводиться до сукупності двовимірних таблиць особливого виду, відомих в математиці як відношення.
Одна з головних ідей полягає в тому, що зв'язки між даними повинні бути встановлені відповідно до їх внутрішніми логічними взаєминами. У реляційної моделі однією командою можуть оброблятися цілі файли.
Реляційна БД являє собою інформацію про об'єкт, представлену у вигляді двовимірного масиву - таблиці об'їдених визначеними зв'язками.
Розглянемо процес побудови логічної моделі на прикладі БД магазину системи «інформація про магазин». Першим етапом є визначення сутностей і атрибутів. У БД будуть зберігатися записи про магазин , отже, сутністю буде магазин.
5.1 Склад таблиць
Таблиця 5.2 - Поставка:
|
Название |
Тип |
|
|
Номер поставника |
Number |
|
|
Страна поставник |
String |
|
|
Назва фірми-поставника |
String |
|
|
Ступінь довіри |
Number |
|
|
Номер поставки |
Number |
|
|
Номер поставника |
Number |
|
|
Кількість груза |
Number |
|
|
Дата поставки |
Number |
Таблица 5.3 - Клієнти:
|
Наименование |
Тип |
|
|
Дата сплати |
Number |
|
|
Номер чеку |
Number |
|
|
Сплатопроможність |
String |
|
|
Район міста |
String |
|
|
Повернення товару |
Number |
Таблица 5.4 - Чек:
|
Наименование |
Тип |
|
|
Дата сплати |
Number |
|
|
Номер чека |
Number |
|
|
Ціна замови |
Number |
|
|
Тип сплати |
String |
Таблица 5.5 - Склад
|
Наименование |
Тип |
|
|
Номер поставки |
Number |
|
|
Номер поставника |
Number |
|
|
Інвентарний номер |
Number |
|
|
Відсоток заповнення складу |
Number |
|
|
Кількість зимових шин |
Number |
|
|
Кількість літніх шин |
Number |
Таблица 5.6 - Шини:
|
Наименование |
Тип |
|
|
Номер поставки |
Number |
|
|
Номер поставника |
Number |
|
|
Інвентарний номер |
Number |
|
|
Ціна |
Number |
|
|
Назва |
String |
|
|
Фірма |
String |
Таблица 5.7 - Кур'єри:
|
Наименование |
Тип |
|
|
Номер поставки |
Number |
|
|
Номер поставника |
Number |
|
|
Інвентарний номер |
Number |
|
|
Час доставки товару |
Number |
|
|
Кількість вільних кур'єрів |
Number |
|
|
Кілкість кур'єрів в роз'їзді |
Number |
Таблица 5.8 - Зимові шини:
|
Наименование |
Тип |
|
|
Номер поставки |
Number |
|
|
Номер поставника |
Number |
|
|
Інвентарний номер |
Number |
|
|
Індекс швидкості |
Number |
|
|
Виробник |
Number |
|
|
Довжина ворсинок |
Number |
|
|
Товщина гуми |
Number |
Таблица 5.9 - Літня гума:
|
Наименование |
Тип |
|
|
Номер поставки |
Number |
|
|
Номер поставника |
Number |
|
|
Інвентарний номер |
Number |
|
|
Індекс швидкості |
Number |
|
|
Виробник |
Number |
|
|
Товщина гуми |
Number |
|
|
Номер поставки |
Number |
|
|
Номер поставника |
Number |
|
|
Інвентарний номер |
Number |
|
|
Виробник |
String |
|
|
Протектор |
String |
Атрибут значення, якого ідентифікується кортежами (рядками таблиці) називається ключем. Ставлення може містити і кілька ключів, один з яких оголошується первинним. Первинні ключі не можуть оновлюватися. Всі інші ключі відносин є можливими ключами.
Якщо у відношенні кортеж ідентифікується з'єднанням значень декількох атрибутів, то такий ключ називається складеним.
Атрибут представляють собою копії ключів інших відносин називається зовнішнім ключем. Реляційна модель накладає на зовнішні ключі обмеження для забезпечення цілісності даних. Це означає, що до кожного значенням зовнішнього ключа повинні відповідати рядки в пов'язуються відносинах.
5.2 Нормалізація відносин
Нормалізація - розбиття таблиці на дві або більше, що володіють кращими властивостями включенні, зміну або видалення даних. Скінченна мета нормалізації зводиться до отримання такого проекту БД в якому кожен факт з'являється лише в одному місці, тобто виключена надмірність інформації.
Нормалізація відносин - формальний апарат обмежень, на формування відносин якого дозволяє усунути дублювання, забезпечити несуперечність збережених у базі даних, зменшити трудовитрати на ведення БД.
Кодом виведено три нормальні форми та запропоновано механізм, що дозволяє будь-яке відношення перетворити ктретей нормальній формі. Наведемо наші відносини ктретей нормальній формі.
Перша НФ: Відношення називається нормалізованим або приведеним до першої нормальної формі тоді і тільки тоді, коли всі його атрибути прості (неподільні). Таблиця знаходиться в першій нормальній формі тоді і тільки тоді, коли жодна з її рядків не містить в будь-якому її полі більше одного значення, і не одне з її ключових полів не порожньо. Для того щоб привести наші відносини до першої нормальної формі треба сутність ПІБ розбити на три окремі (Прізвище, Ім'я, По батькові). Так само слід винести в окрему таблицю структурний підрозділ, посади і найменування фірми, щоб не допустити надмірності даних. В окрему таблицю виносяться накази по особовому складу та виробничі накази, так як нумерація у наказів загальна. Атрибути місце проживання за паспортом і фактичне місце проживання не вимагають розбивки так як використовуються один раз. Друга НФ: Таблиця знаходиться в другій нормальній формі, якщо вона задовольняє визначенню першої нормальної форми і всі її поля, що не входять в первинний ключ, пов'язані повної функціональної залежністю з первинним ключем. Для того щоб наші відносини привести у другу нормальну форму треба винести всі начальників відділу в окрему таблицю.
Третя НФ: Таблиця перебуває витратах нормальній формі, якщо вона задовольняє визначенню другої нормальної форми і жодне з її не ключових полів не залежить функціонально від будь-якого іншого не ключового поля. Відносини, представлені в даній БД приведені критерій нормальній формі.
Складемо ER-діаграму, визначаючи типи атрибутів і зв'язки між сутностями (рис. Ж.1). Всі сутності будуть залежними від сутності «Шини». Зв'язки будуть типу «один-до-багатьох».(рис 5.1)
Рис. 5.1 - ER- Діаграма БД:
На отриманій діаграмі поруч з зв'язком відбивається її ім'я, що показує співвідношення між сутностями. При проведенні зв'язку між сутностями первинний ключ мігрує в дочірню сутність. Наступним етапом при побудові логічної моделі є визначення ключових атрибутів і типів атрибутів який був описаний вище.
6. Фізичне проектування БД
Проектування інформаційних систем, що включають в себе бази даних, здійснюється на фізичному і логічному рівнях. Вирішення проблем проектування на фізичному рівні багато в чому залежить від використовуваної СУБД (система управління базами даних - комплекс мовних і програмних засобів, призначених для створення, ведення, і спільного ведення БД багатьма користувачами), найчастіше автоматизовано і приховано від користувача. У ряді випадків користувачеві надається можливість налаштування окремих параметрів системи, яка не становить великої проблеми.
Метою створення фізичної моделі є забезпечення адміністратора відповідною інформацією для переносу логічної моделі даних у СКБД. Erwin підтримує автоматичну генерацію фізичної моделі даних для конкретної СКБД.
При цьому логічна модель трансформується у фізичну за наступним принципом: сутності стають таблицями, атрибути стають стовпцями, а ключі стають індексами. (рис.6.1)
Рис. 6.1 - Різниця між моделями:
Нормалізуємо БД до третьої нормальної форми. Для приведення БД у першу нормальну форму необхідно виконати умову, при якій всі атрибути містять атомарні значення. Розглянемо атрибути сутності «Склад». Працівник може мати кілька марок шин та декілька кур'єрів, що є порушенням першої нормальної форми. Необхідно створити окремі сутності «Кур'єри» і «Шини» і зв'язати їх з сутністю «Склад» (рис 6.2).
Рис 6.2 - Нормалізація відносин:
Перевіримо відповідність БД другий нормальній формі. Усі неключові атрибути повністю повинні залежати від первинного ключа. Неважко помітити, що ця умова виконується для всіх сутностей БД; отже, можна зробити вивід про те, що вона перебуває в другій нормальній формі. Одержимо БД у третій нормальній формі, так як інших транзитивних залежностей неключових атрибутів немає.
6.1 Побудова Фізичної моделі
Перейдемо до побудови фізичної моделі. Перед побудовою фізичної моделі необхідно вибрати тип бази даних у меню при створенні фізичної моделі. Виберемо в якості Database Oracle 11G. В отриманій моделі необхідно скорегувати типи й розміри полів. Крім того, на етапі створення фізичної моделі даних вводяться правила валідації колонок - списки, що визначають припустимі значення і значення за замовчуванням (закладка Oracle у атрибута).
6.1.1 Склад таблиць БД
Таблиця 6.1 - Властивості колонок таблиць фізичної моделі БД Шини:
|
Логічна назва |
Фізична назва |
Тип |
Розмір |
Правила валідації |
|
|
Номер поставки |
Nomer_postavki |
INTEGER |
|||
|
Номер поставщика |
post_no |
INTEGER |
|||
|
Інвентарний номер |
inv_numb |
INTEGER |
|||
|
Цена |
tzena |
INTEGER |
|||
|
Найменування |
Nazvanie |
VARCHAR |
20 |
||
|
Фірма |
Firma |
VARCHAR |
20 |
>0 |
Таблиця 6.2 - Властивості колонок таблиць фізичної моделі БД:
|
Логічна назва |
Фізична назва |
Тип |
Розмір |
Правила валідації |
|
|
Номер поставки |
Nomer_postavki |
INTEGER |
|||
|
Номер поставщика |
post_no |
INTEGER |
|||
|
Інвентарний номер |
inv_numb |
INTEGER |
|||
|
Індекс швидкості |
Indeks shvidkosti |
INTEGER |
|||
|
Виробник |
Virobnik |
INTEGER |
|||
|
Довжина ворсинок |
Dovjina vorsinok |
INTEGER |
>0 |
||
|
Товщина гуми |
Tovshina gymi |
INTEGER |
>0 |
Таблиця 6.3 - Властивості колонок таблиць фізичної моделі БД гумма:
|
Логічна назва |
Фізична назва |
Тип |
Розмір |
Правила валідації |
|
|
Номер поставки |
Nomer_postavki |
INTEGER |
|||
|
Номер поставщика |
post_no |
INTEGER |
|||
|
Інвентарний номер |
inv_numb |
INTEGER |
|||
|
Індекс швидкості |
Indeks shvidkosti |
INTEGER |
|||
|
Виробник |
Virobnik |
INTEGER |
>0 |
||
|
Товщина гуми |
Tovshina gymi |
INTEGER |
>0 |
Таблиця 6.4 - Властивості колонок таблиць фізичної моделі БД Димісизонна гума:
|
Логічна назва |
Фізична назва |
Тип |
Розмір |
Правила валідації |
|
|
Номер поставки |
Nomer_postavki |
INTEGER |
|||
|
Номер поставщика |
post_no |
INTEGER |
|||
|
Інвентарний номер |
inv_numb |
INTEGER |
|||
|
Виробник |
Virobnik |
VARCHAR |
20 |
||
