Проектування та розробка бази даних

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

Вступ

база даний розробка управління

Використання баз даних є однією з характерних рис більшості сучасних інформаційних систем. По своїй суті бази даних є тим, навколо чого і будується інформаційна система будь-якого підприємства. Тому теорії створення та практиці використання баз даних приділяється достатня увага протягом періоду функціонування інформаційних систем. Досить тривалий час основним типом були реляційні бази даних, які на сьогодні вже вважаються класичними. Проте розвиток інформаційних систем поставив перед сучасними базами даних завдання, вирішення яких неможливе в межах використання тільки реляційних баз даних. Крім класичних завдань, сучасні бази даних повинні забезпечувати багатомашинну обробку та зберігання великих обсягів інформації, оперативний аналіз даних, інтеграцію із мережею Інтернет, розмежування доступу користувачів до зберігає мої інформації, захист інформації під час її передачі по мережі. Хоча на практиці і використовується чимало різноманітних баз даних, але для більшості з них існує велика кількість спільних ознак, як з погляду розробки, так і використання. Це дає можливість вивчати сучасні бази даних і відповідне прикладне та системне програмне забезпечення на прикладах, які, незважаючи на свою новизну, вже стали класичними. Як такі приклади вибрано загальні питання проектування, розробки та використання бази даних Microsoft SQL Server. Це пояснюється тим, що Microsoft SQL є однією із найпоширеніших і вдосконалених баз даних.

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

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

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

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

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



1. Основні проблеми розробки сучасних баз даних, аналіз предметної області та постановка задачі курсової роботи

1.1 Актуальність проблем розробки баз даних, основні поняття та визначення

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

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

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

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

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

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

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

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

1.2 Загальна схема процесу розробки інформаційної системи з застосуванням концепції БД

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

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

В ієрархічній моделі зв'язок даних "один до одного" (1:1) означає, що кожному значенню (екземпляру) елемента даних А відповідає одне і тільки одне значення, пов'язаного з ним елемента В. Наприклад, поміж такими елементами пар даних, як код готової продукції і її найменуванням є вищезазначений зв'язок, так як тільки кожному коду продукції відповідає одне її найменування.

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

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

В сітьовій моделі зв'язок "один до багатьох" (1:В) означає, що значенню елемента А відповідають багато (більше одного) значень, пов'язанню з ним елементів В. Наприклад, поміж елементами даних "код виробу" (елемент А) і "кодом матеріалів" (елементи В) існує такий взаємозв'язок бо на виготовлення одного виробу використовується багато різних матеріалів.

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

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

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

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

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

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

1.3.1 Глосарій проекту

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

Веб-сайт (англ. website, місце, майданчик в Інтернеті), також сайт (англ. site, місце, майданчик) -- сукупність веб-сторінок, доступних у Міжмережжі (Інтернеті), які об'єднані як за змістом, так і навігаційно. Фізично сайт може розміщуватися як на одному, так і на кількох серверах.

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

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

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

Microsoft SQL Server -- комерційна система керування базами даних, що розповсюджується корпорацією Microsoft. Мова, що використовується для запитів -- Transact-SQL, створена спільно Microsoft та Sybase.

Агрегатна функція (дослівно - функція складеного значення) -- функція, яка повертає одинарне значення з колекції вхідних значень такої як множина (set), мультимножина (multiset) або список (list).

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

Графімчний інтерфейс користувача (ГІК, англ. GUI, Graphical user interface) -- інтерфейс між комп'ютером і його користувачем, що використовує піктограми, меню, і вказівний засіб для вибору функцій та виконання команд. Зазвичай, можливе відкриття більше, ніж одного вікна на одному екрані.

FOREIGN KEY - в одній таблиці вказує на інший PRIMARY KEY.

PRIMARY KEY - це обмеження дозволяє однозначно ідентифікувати кожний запис у таблиці.

Складовий ключ - це ключ, який складається з двох чи більше атрибутів.

1.4 Постановка задачі курсової роботи

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

При розробленні бази даних необхідно створити таблиці в SQL Manager Lite for MySQL, та заповнити їх необхідними полями(атрибутами).

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

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

Створена база даних в SQL Manager Lite for MySQL повина мати підключення до створеного раніше сайту, щоб безпосередньо її використовувати.



2. Моделювання даних предметної області

2.1 Розробка концептуальної моделі даних

На створеній ER-діаграмі , яка знаходиться в додатку А присутні такі сутності як:

- Виробник - ця сутність утримує інформацію про виробника баскетбол

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

- Модель товару - тут описується характеристика моделей м'ячів, які

Знаходяться на сайті в продажі, або на складі магазину. Тут теж присутня реалізація primary key для ідентифікування кожної моделі. Ця сутність має в собі лише два інформаційні поля, один з якиз це саме primary key, а інший назва моделі. Рrimary key входить в сутність товар, яка завдяки цьому зв'язується з сутністю «модель товару».

- Рейтинг товару - ця сутність також не несе в собі багато атрибутів, і за своєю структурою схожа з сутністю модель товару, оскільки також має лише два інформаційні поля - primary key, який називається «Рейтинговый_номер_товара», та «Оцінка_товару».

- Розмір - відповідає за зберігання інформації про розміри м'ячів. Ця

Сутність з'єднується однаково, як і попередні.

- Дизайн товару - сутність відповідає за збереження товару про дизайн м'ячів.

- Матеріал - зберігає інформацію про те з якого матеріалу створено м'яч.

- Рrimary key цієї таблиці входе також як і попередні в сутність товар.

- Характеристика - в цій сутності є поля, які характеризують товар, на

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

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

- Продавець - тут описуються дані за якими можна охарактеризувати чи ідентифікувати продавця. Рrimary key цієї сутності входе в сутность «Гарантия». Завдяки такій схемі, можна зв'язати сутності як «продавець» та «товар», або «покупатель».

- Покупець - знаходяться поля, які характеризують покупця. Його рrimary key також входить у сутність «Гарантия».

- Гарантія - зберігае в собі рimary key сутностей «продавець», «покупець» та «товар», і має свої атрибути, як «час_дії_гарантії», «домовності».

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

- Товар - він включає в себе багато foreign key, щою з'єднати сутності з

Собою, та деякі поля, як ціна, артикул, знак_якості та ін..

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



Рисунок 2.1 - Панель вибору типу зв'язку.

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

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

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

В Erwin э можливість визначати яким э зв'язок між сутностями. Це можна подивитися та встановити завдяки панелі:



Рисунок 2.2 - панель relations.

Erwin має дуже зручний інтерфейс у використанні його основних функцій.

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

В базі даних магазину Sport-Devive, було розроблено необхідні запити на видання інформації з таблиць, на їх заповнення, обновлення та видалення.

Спочатку реалізувалося створення таблиць в SQL Manager Lite for MySQL. Створення таблиць, можна зробити як завдяки коду, або завдяки зручному інтерфейсу SQL Manager Lite for, який надае можливість створювати таблиці без коду, а в спеціальній вкладці:

CREATE TABLE `goods` (

`goods_ID` int(11) NOT NULL AUTO_INCREMENT,

`manufacturer_ID` int(11) DEFAULT NULL,

`model_ID` int(11) DEFAULT NULL,

`rating_number_ID` int(11) DEFAULT NULL,

`size_ID` int(11) DEFAULT NULL,

`design_ID` int(11) DEFAULT NULL,

`material_ID` int(11) DEFAULT NULL,

`characteristic_ID` int(11) DEFAULT NULL,

`measurement_ID` int(11) DEFAULT NULL,

`guarantee_ID` int(11) DEFAULT NULL,

`check_ID` int(11) DEFAULT NULL,

`price` int(11) DEFAULT NULL,

`article` varchar(20) DEFAULT NULL,

`goods_name` varchar(30) DEFAULT NULL,

`quality_symbol` varchar(30) DEFAULT NULL,

`Presence_in_a_warehouse` varchar(20) DEFAULT NULL,

PRIMARY KEY (`goods_ID`),

KEY `manufacturer_ID` (`manufacturer_ID`),

KEY `model_ID` (`model_ID`),

KEY `rating_number_ID` (`rating_number_ID`),

KEY `size_ID` (`size_ID`),

KEY `design_ID` (`design_ID`),

KEY `material_ID` (`material_ID`),

KEY `characteristic_ID` (`characteristic_ID`),

KEY `guarantee_ID` (`guarantee_ID`),

KEY `measurement_ID` (`measurement_ID`),

KEY `check_ID` (`check_ID`)

) ENGINE=MyISAM AUTO_INCREMENT=13 DEFAULT CHARSET=latin1;

Рисунок 2.3 - Результат виконання таблиці.

Тут наведений код створення таблиці товар, яка включає в себе foreng key з інших таблиць.

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

INSERT INTO manufacturer (manufacturer_name, manufacturer_adress,

manufacturer_phone, manufacturer_email, Company_rating,

certificate, director)

VALUES

("Mikasa", "Kharkov, Artema 4", "7104578", "manufacturer1@mail.ru", 9, "90.23",

"Ivanov"),

("Nike", "Kharkov, Bavarian 9", "7124779", "manufacturer2@mail.ru", 5, "90.28",

"Petrov"),

("Adidas", "Kharkov, Byrona 34", "7154578", "manufacturer3@mail.ru", 10, "91.22",

"Sidorow"),

("Sport_ball", "Kharkov, Wagnera 7", "7194578", "manufacturer4@mail.ru", 8, "90.23",

"Zajtsev"),

("Winner", "Kharkov, Vasnetsova 89", "8194578", "manufacturer5@mail.ru", 2, "99.23",

"Lebedev"),

("Mega-sport", "Kharkov, Gogoly 99", "8994773", "manufacturer6@mail.ru", 1, "100.23",

"Solovyov"),

("street-ball", "Kharkov, Gomonenko 123", "5674372", "manufacturer7@mail.ru", 3, "111.23",

"Kozlov"),

("Spalding", "Kharkov, Horkogo 71", "4654372", "manufacturer8@mail.ru", 4, "200.29",

"Fedorow"),

("Wilson", "Moscow, Darnitsky 5", "3273372", "manufacturer9@mail.ru", 6, "201.30",

"Beljaev"),

("Molten Corporation", "Moscow, Factory 345", "123678", "manufacturer10@mail.ru", 7, "207.38",

"Koroblev"),

("Rawlings", "Moscow, Ivanovsky 3", "234878", "manufacturer11@mail.ru", 11, "345.89.0",

"Orlov"),

("NBA-sport", "Moscow, Kozlova 334", "1111878", "manufacturer12@mail.ru", 12, "311.89.10",

"Buryk")

INSERT INTO model_goods (name_model)

VALUES

("BD2000 Mikasa"), ("Winner Champion (19508) "),

("BQ1000 Mikasa"), ("Winner Classik 7 (19507)"),

("BMAXPLUS Mikasa"), ("Winner Grippy 5 (19506) "),

("BX712 Mikasa"), ("Winner Orange 7 (11340)"),

("1000 Mikasa"), ("Nike ВВ0328-4005"),

("1020 Mikasa"), ("Mikasa GOLDBB ")

INSERT INTO characteristic (recommendation, measurement_ID, Value_characteristic)

VALUES

("The professional ball, is intended for carrying out of competition.", 1, 3),

("Game and training ball for educational institutions.", 2, 2),

("The professional ball, is intended for carrying out of competition.", 3, 2),

("Game and training ball for educational institutions.", 4, 2),

("The professional ball, is intended for carrying out of competition.", 5, 3),

("It is used in the street.", 6, 2),

("Game and training ball for educational institutions", 7, 2),

("It is used in the street.", 8, 2),

("Game and training ball for educational institutions.", 9, 3),

("Ball the basketball souvenir.", 10, 3),

("Game and training ball.", 11, 2),

("It is used in the street.", 12, 3)

INSERT INTO measurement (naming)

VALUES

("Butyl chamber"), ("Butyl chamber"),

("butilovo-latex chamber"), ("Butyl chamber"),

("butilovo-latex chamber"), ("butilovo-latex chamber"),

("Butyl chamber"), ("Butyl chamber"),

("butilovo-latex chamber"), ("Butyl chamber"),

("butilovo-latex chamber"), ("butilovo-latex chamber")

INSERT INTO rating_goods (estimation_goods)

VALUES

(5), (5), (5), (5), (4), (4), (4), (4), (3), (3),

(3), (3)

INSERT INTO size (size_goods)

VALUES

(7), (7), (7), (7), (5), (5), (5), (5), (3), (3),

(3), (3)

INSERT INTO design_goods (design_goods)

VALUES

("Eight panel design"), ("Twelve panel design"),

("Twelve panel design"), ("Eight panel design"),

("Twelve panel design"), ("Eight panel design"),

("Twelve panel design"), ("Twelve panel design"),

("Eight panel design"), ("Ten panel design"),

("four panel design_goods"), ("four panel design")

INSERT INTO material (material_name)

VALUES

("Genuine leather"), ("Synthetic skin"),

("Synthetic skin"), ("Synthetic skin"),

("Synthetic skin"), ("Synthetic skin"),

("Synthetic skin"), ("rubber"),

("Synthetic skin"), ("Synthetic skin"),

("rubber"), ("rubber")

INSERT INTO seller (seller_name, seller_phone, seller_email, seller_post)

VALUES

("Ilyn", "098202345", "seller1@mail.ru", "main seller"),

("Karasev", "098213346", "seller2@mail.ru", "main seller"),

("Kabanov", "098244634", "seller3@mail.ru", "assistant seller"),

("Kolbin", "097899067", "seller4@mail.ru", "assistant seller"),

("Kuzmin", "097901007", "seller5@mail.ru", "main seller"),

("Maksimov", "097123456", "seller6@mail.ru", "main seller"),

("Ivanov", "095786456", "seller7@mail.ru", "assistant seller"),

("Molchanov", "095327890", "seller8@mail.ru", "assistant seller"),

("Morgunov", "096643878", "seller9@mail.ru", "main seller"),

("Nosov", "096345679", "seller10@mail.ru", "main seller"),

("Panamachenko", "0961413893", "seller11@mail.ru", "assistant seller"),

("Polycov", "0961718894", "seller12@mail.ru", "assistant seller")

INSERT INTO client (client_name, client_phone, client_email, client_adress)

VALUES

("Bondarev", "778912", "client1@mail.ru", "Kharkov, Balashovsky 12"),

("Bondarchuk", "779012", "client2@mail.ru", "Kharkov, Beketov 13"),

("Vorobey", "4791123", "client3@mail.ru", "Kiev, Bluchera 14"),

("Vlasov", "7695124", "client4@mail.ru", "Kiev, Voloshinsky 11"),

("Voronin", "5694120", "client5@mail.ru", "Kiev, Danilevsky 10"),

("Volkov", "7663121", "client6@mail.ru", "Kiev, Yelizarov 2"),

("Glebov", "7523131", "client7@mail.ru", "Kharkov, Zhukovsky 1"),

("Gorelov", "7521145", "client8@mail.ru", "Kharkov, Ilyicha 90"),

("Yelizarov", "6522223", "client9@mail.ru", "Moscow Kirova 99"),

("Zherdev", "67292223", "client10@mail.ru", "Moscow Korolenko 45"),

("Zverev", "3729522", "client11@mail.ru", "Moscow, Lui Pasteur 11"),

("Izumov", "2229122", "client12@mail.ru", "Kharkov, Morozova 23")

INSERT INTO check_goods (goods_ID, client_ID, Purchase_date, phone_shop)

VALUES

(1, 1, "3.11.10", "235678"),

(2, 2, "7.08.10", "109078"),

(3, 3, "5.04.10", "908765"),

(4, 4, "21.03.11", "784531"),

(5, 5, "12.03.11", "456790"),

(6, 6, "5.01.11", "171324"),

(7, 7, "7.02.11", "456789"),

(8, 8, "17.04.11", "900765"),

(9, 9, "11.04.11", "123400"),

(10, 10, "15.05.11", "43452"),

(11, 11, "5.05.11", "555212"),

(12, 12, "16.05.11", "999673")

INSERT INTO goods (manufacturer_ID, model_ID, rating_number_ID, size_ID,

design_ID, material_ID, characteristic_ID, measurement_ID, guarantee_ID,

check_ID, price, article, goods_name, quality_symbol, Presence_in_a_warehouse)

VALUES

(1,1,1,1,1,1,1,1,1,1, 730, "B712", "Basketball ball", "Huisheng", "Yes"),

(2,2,2,2,2,2,2,2,2,2, 417, "19511", "Basketball ball", "Huisheng", "Yes"),

(3,3,3,3,3,3,3,3,3,3, 233, "BX712", "Basketball ball", "Huisheng", "Yes"),

(4,4,4,4,4,4,4,4,4,4, 385, "BD1500", "Basketball ball", "TFA Sports", "Yes"),

(5,5,5,5,5,5,5,5,5,5, 385, "BQ1000", "Basketball ball", "A.FSports", "Yes"),

(6,6,6,6,6,6,6,6,6,6, 456, "19507", "Basketball ball", "TFA Sports", "Yes"),

(7,7,7,7,7,7,7,7,7,7, 377, "19508", "Basketball ball", "TFA Sports", "Yes"),

(8,8,8,8,8,8,8,8,8,8, 144, "19506", "Basketball ball", "A.FSports", "Yes"),

(9,9,9,9,9,9,9,9,9,9, 80, "19505 ", "Basketball ball", "Huisheng", "No"),

(10,10,10,10,10,10,10,10,10,10, 435, "GOLDBB", "Basketball ball", "A.FSports", "Yes"),

(11,11,11,11,11,11,11,11,11,11, 100, "1020", "Basketball ball", "Huisheng", "No"),

(12,12,12,12,12,12,12,12,12,12, 400, "1000", "Basketball ball", "Huisheng", "No")

INSERT INTO guarantee (goods_ID, client_ID, seller_ID, action_guarantee, arrangement)

VALUES

(1, 1, 1, "1 month", "contract1"),

(2, 2, 2, "3 month", "contract2"),

(3, 3, 3, "3 month", "contract3"),

(4, 4, 4, "6 month", "contract4"),

(5, 5, 5, "1 month", "contract5"),

(6, 6, 6, "1 month", "contract6"),

(7, 7, 7, "6 month", "contract7"),

(8, 8, 8, "3 month", "contract8"),

(9, 9, 9, "3 month", "contract9"),

(10, 10, 10, "6 month", "contract10"),

(11, 11, 11, "6 month", "contract1"),

(12, 12, 12, "6 month", "contract12")

Тут приведений код на обновлення інформації в таблицях:

UPDATE goods SET goods.price=478 WHERE goods.goods_ID=12;

Запит на видалення даних прийматиме наступній вид:

DELETE FROM size;

Запити на вибір інформації (SELECT):

1. Визначити кількість клієнтів у яких в прізвищі присутня літера "n".

SELECT COUNT(*)

FROM client

WHERE (client.client_name LIKE "%n%");

Рисунок 2.4- Результат виконання запиту на COUNT

2. Визначити найдорожчий товар.

SELECT goods.goods_ID, goods.goods_name, model_goods.name_model,

rating_goods.estimation_goods,

material.material_name, manufacturer.manufacturer_name,

measurement.naming, characteristic.Value_characteristic,

MAX(goods.price)

AS most_expensive_price

FROM goods, model_goods, rating_goods, material, manufacturer, characteristic,

measurement

WHERE (goods.model_ID=model_goods.model_ID AND

rating_goods.rating_number_ID=goods.rating_number_ID AND

material.material_ID=goods.material_ID

AND manufacturer.manufacturer_ID=goods.manufacturer_ID AND

goods.characteristic_ID=characteristic.characteristic_ID AND

goods.measurement_ID=measurement.measurement_ID AND

characteristic.measurement_ID=measurement.measurement_ID);

Рисунок 2.5 - Результат виконання запиту на MAX.

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

400 грн..

SELECT goods.goods_ID, MIN(goods.price)

FROM goods

GROUP BY goods.goods_ID

HAVING MIN(goods.price)<400;

Рисунок 2.6.Результат виконання запиту на MIN.

4. Визначити клієнтів, які придбали товар 5.04.10".

SELECT client.client_ID, client.client_name, client_phone, client_email, client_adress

FROM client, check_goods

WHERE (check_goods.client_ID=client.client_ID and

Purchase_date="5.04.10");

Рисунок 2.7 - Результат виконання запиту на визначення дати.



5. Визначити товари вартість, яких знаходиться діапазоні від 100 до 200 грн..

SELECT goods.goods_ID, goods.goods_name, model_goods.name_model,

manufacturer.manufacturer_name, design_goods.design_goods, size.size_goods,

material.material_name, goods.price

FROM model_goods, goods, size, manufacturer, design_goods, material

WHERE (goods.model_ID=model_goods.model_ID AND

goods.size_ID=size.size_ID AND

goods.manufacturer_ID=manufacturer.manufacturer_ID AND

goods.design_ID=design_goods.design_ID AND

goods.material_ID=material.material_ID AND

price BETWEEN 100 AND 200)

ORDER BY goods.price DESC;

Рисунок 2.8 - Результат виконання запиту на BETWEEN.

6. Визначити товари та вивести інформацію про них, рейтинг, яких вищий за 8.

SELECT goods.goods_ID, goods_name, model_goods.model_ID, model_goods.name_model,

goods.price,

rating_goods.rating_number_ID

FROM goods, model_goods, rating_goods

WHERE (goods.model_ID=model_goods.model_ID AND

goods.rating_number_ID=rating_goods.rating_number_ID AND

rating_goods.rating_number_ID>8);



Рисунок 2.9 - Результат виконання запиту на на предикати «>«.

7. Необхідно зробити транзакцію на добавлення даних у таблицю з ROLBACK;

START TRANSACTION;

insert into check_goods (goods_ID, client_ID, Purchase_date, phone_shop)

values (11, 11, "17.06.10", "90-87-34");

insert into check_goods (goods_ID, client_ID, Purchase_date, phone_shop)

values (12, 12, "18.07.10", "91-88-33");

ROLLBACK;

Ця транзакція не буде виконана тому що в ній є ROLBACK, який відміняє виконання транзакції.

8. Створити транзакцію на добавлення інформації у таблицю «вироник». В цій транзакції повинна бути присутня точка збереження.

START TRANSACTION;

insert into manufacturer (manufacturer.manufacturer_ID,

manufacturer.manufacturer_name, manufacturer.manufacturer_adress,

manufacturer.manufacturer_phone,

manufacturer.manufacturer_email, manufacturer.Company_rating, manufacturer.certificate,

manufacturer.director)

values (13, "Mikasa", "Shevhenko 12 a", "896512", "manufacturer13@mail.ru",

13, "56.00001", "Shevhuk");

insert into manufacturer (manufacturer.manufacturer_ID,

manufacturer.manufacturer_name, manufacturer.manufacturer_adress,

manufacturer.manufacturer_phone,

manufacturer.manufacturer_email, manufacturer.Company_rating, manufacturer.certificate,

manufacturer.director)

values (14, "adidas", "Shevhenko 15 a", "9091512", "manufacturer14@mail.ru",

14, "57.00002", "Stanovoy");

SAVEPOINT save_point;

Рисунок 2.10 - Результат виконання запиту на створення транзакції з точкою збереження.

9. Необхідно створити транзакцію на обновлення даних.

START TRANSACTION;

UPDATE size SET size.size_goods=3 WHERE size.size_ID=3;

Рисунок 2.11 - Результат виконання запиту на створення транзакції з точкою збереження.

10. Створити тригер на обновлення даних.

CREATE TRIGGER `delete_seller`

BEFORE UPDATE ON `seller`

FOR EACH ROW

BEGIN

UPDATE seller SET seller.seller_phone="097236790" WHERE seller.seller_ID=12;

END;

Рисунок 2.12 - Результат виконання запиту на створення тригеру на видалення данихзтаблиці «seller».

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

SELECT model_goods.model_ID, model_goods.name_model

FROM model_goods, size, goods

WHERE (goods.model_ID=model_goods.model_ID AND

goods.size_ID=size.size_ID) AND size.size_goods IN

(SELECT size.size_goods

FROM size

WHERE size.size_goods=3);



Рисунок 2.13 - Результат виконання вкладеного запиту.

12. Створити запит на предикат

SELECT goods.goods_ID, goods.goods_name, model_goods.model_ID,

model_goods.name_model, manufacturer.manufacturer_name, goods.price

FROM goods, model_goods, manufacturer

WHERE (goods.model_ID=model_goods.model_ID AND

goods.manufacturer_ID=manufacturer.manufacturer_ID AND

goods.goods_ID IN (4, 9, 6, 3))

ORDER BY goods.goods_ID DESC;

Рисунок 2.14 - Результат виконання запиту на предикат IN.

13. Створити запит на предикат ALL.

SELECT DISTINCT client.client_ID, client.client_name

FROM client, guarantee, seller

WHERE guarantee.client_ID=client.client_ID AND

guarantee.seller_ID=seller.seller_ID AND client.client_ID > ALL

(SELECT seller.seller_ID

FROM seller

WHERE (seller.seller_ID=3)



Рисунок 2.15 - Результат виконання запиту на предикат ALL.

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



3. Програмна реалізація системи

3.1 Розробка системної програмної архітектури

Діаграма знаходиться в додатку Б.

Мотивований вибір СКБД та інструментальних програмних засобів для реалізації запропонованої системної архітектури

Стислий огляд сучасних типів СКБД та критерії вибору СКБД для реалізації проекту

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

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

Своїми силами. Для цього треба володіти основами програмування на мові Basic.

EMS SQL Manager для MySQL Freeware це найпотужніший інструмент для адміністрування баз даних MySQL та розвитку. Вона працює з будь-якими версіями MySQL від 3,23 до новітніх і підтримує всі новітні функції MySQL, включаючи тригери, представлення, збережені процедури і функції, зовнішні ключі InnoDB, Unicode даних і так далі. SQL Manager для MySQL дозволяє створювати і редагувати всі об'єкти баз даних MySQL, проектування баз даних MySQL, запустіть SQL скрипти, керувати користувачами і їх привілеями, а також безліч інших корисних інструментів для ефективного адміністрування MySQL. SQL Manager для MySQL має стані арт-графічний користувальницький інтерфейс з добре описано майстер системи, настільки ясно у використанні, що навіть новачкові не слід плутати з ним. Основні характеристики * Підтримка даних UTF8 * Швидка навігація і управління базами * Просте управління всіма об'єктами MySQL * Потужні інструменти управління даними * Ефективне управління параметрами безпеки * Відмінні інструменти для побудови запитів * Простота у використанні майстра для виконання завдань MySQL послуги * Підключення до MySQL Server через HTTP

3.2 Особливості інструментальних засобів програмної реалізації клієнтського додатку та бізнес-логіки системи

Системи управління базами даних (СУБД) є набором програмних засобів, необхідних для створення, використання і підтримки баз даних.

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

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

Основне призначення СУБД -- створення та підтримка в актуальному стані бази даних, а також зв'язок її з програмами розв'язування економічних завдань (прикладні програми користувачів).

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

На магнітному диску база даних може зберігатись у вигляді одного файла (бази даних MS Access, Informix та ін.) або у вигляді папки з файлами (бази даних Interbase, Paradox та ін.).

3.3 Розробка прикладного програмного забезпечення

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

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

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

Працює цей механізм, природно, через службові таблиці. У списку баз даних є одна службова база під назвою "mysql", в якій зберігаються в декількох таблицях всі службові дані, необхідні для роботи сервера. Поки нас цікавить тільки управління правами доступу, за які відповідають наступні таблиці:

columns_priv - доступ на рівні стовпців таблиці;

db - доступ до окремих баз даних;

host - доступ до баз з конкретних хостов/ip;

tables_priv - доступ до окремих таблиць бази даних;

user - глобальні настройки доступу для конкретних користувачів.

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

Має рацію, визначувані в таблиці user, є глобальними, це означає, що вони застосовуються до всіх баз даних, до яких має доступ конкретних користувач. Також в цій таблиці зберігаються самі імена користувачів і їх паролі. Причому імена користувачів зберігаються у вигляді відкритого тексту, а паролі зашифровані функцією PASSWORD(). Сервер MYSQL застосовує свій метод шифрування замість системного (якщо така функція надається ОС, наприклад, Linux/unix).

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

Якщо для одного і того ж користувача треба вирішити доступ з різних комп'ютерів, то в таблиці привілеїв треба створити дві (три або більше - скільки знадобиться) записів, визначаючи в кожній окремий параметр доступу. Наприклад, для доступу користувача root з комп'ютерів localhost і 192.168.1.138 треба в таблицю user внести два однакові записи, які розрізняються тільки полемо host. Хоча можна, звичайно, і не робити їх однаковими - тоді той же користувач, але залежно від місця, звідки він підключився, матиме різні привілеї.

Значення стовпця host можна задавати в різних форматах. Це може бути як ім'я хоста - localhost, так і IP-адрес - 192.168.1.138. При необхідності, можна застосовувати символи підстановки. Вони аналогічні тим же. Що застосовуються в синтаксисі SQL-запросов. Символ "_" означає будь-який символ, а "%" - будь-яка кількість символів. Наприклад, для дозволу доступу з будь-якого комп'ютера, що містить в імені hostinfo.ru треба прописати %.hostinfo.ru у стовпці host. Таким же способом можна задавати і діапазони IP-адресов. Для завдання маски мережі доступний також варіант написання через слеш - 192.168.1/255. Для глобального завдання доступу можна в стовпці host прописати тільки символ "%" або залишити його порожнім, що рівнозначно.

Наступні поля - user і password, визначають ім'я і пароль користувача. Ці поля вже, на відміну від host, розрізняють регістр введених символів, тому користувач Root і root - це два разних користувача. Знаки підстановки в цьому полі вже не працюють - ім'я користувача %" означає не "будь-який користувач", а саме "користувач з ім'ям %". Для завдання анонімного користувача треба просто залишити поле порожнім, інакше будь-який символ вважатиметься ім'ям користувача. Так само і в полі password - пароль зберігається в зашифрованому вигляді, знаки підстановки недійсні, а порожнє поле означає, що користувач зовсім не повинен указувати пароль, бо, що пароль може бути довільним. Нагадаємо, що просто пароль (хай і зашифрований) не можна поміщати в поле password, заздалегідь його треба шифрувати функцією PASSWORD("пароль_откритим_текстом"). Наприклад:

INSERT INTO user SET host="192.168.1.138", user="raiden", password=password("my_password");

Наступним полем є поле бази даних - db. У інших таблицях воно також присутнє, тому у всіх таблицях правила написання імен баз даних повинні бути однаковими. Дозволяється використовувати символи підстановки "%" і "_", порожнє значення відповідає "всі бази". Поле чутливе до регістра!

Далі йде цілий набір стовпців, що вирішують ті або інші дії для користувача. Наприклад, Select_priv, Insert_priv, Update_priv, Delete_priv, Index_priv і Alter_priv варто встановити в "Y" (дозволено) для звичайного користувача, оскільки такі запити найчастіше зустрічаються в звичайних застосуваннях. Решта можливостей для більшої безпеки треба відключити для всіх користувачів (особливо, якщо є обліковий запис анонімного користувача). Тому в наступних стовпцях - Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv і References_priv треба виставити значення "N"(заборонено), а при необхідності вирішити дії тільки адміністраторові і максимально обмежити можливості підключення такого користувача - вказати конкретну IP-адрес або ім'я комп'ютера, вибрати довгий і складний для підбору пароль.

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

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

Таблиця host також аналогічна описаним вище, тільки замість імен і паролів користувачів для ідентифікації привілеїв служить ім'я хоста або IP-адрес. На перший погляд, є істотне дублювання інформації. Адже таблиці db і host майже рівнозначні і містять однакові дані. Насправді це трохи не так. Таблиця host недоступна для зміни через операторів SQL GRANT і REVOKE, її можна тільки правити безпосередньо. Коли сервер приймає вирішення про допуск клієнта до баз, він спочатку шукає згадку імені хоста або IP в таблиці host. Якщо там присутній відповідний запис, то тоді має рацію з таблиць host і db обьедіняються і клієнт отримує деякі привілеї. Якщо ж в таблиці host немає вказівок на рахунок хоста або IP, то сервер навіть не розглядає далі таблицю db, оскільки якщо клієнтові не дозволено підключення з хоста, то тоді безглуздо шукати права на доступ до окремих баз.

І, наприкінці, давайте зупинимося на одному нюансі при визначенні привілеїв. Сервер MYSQL, коли шукає і порівнює привілеї, не порівнює їх безпосередньо. Наприклад, символьне позначення параметра має більший пріоритет, чим використання символів підстановки. Приклад: якщо є два записи - %.megahoster.net і admin.megahoster.net, то другий запис має більший пріоритет. Тому якщо для одного користувача існують різні привілеї залежно від хоста або інших параметрів, то вибиратиметься першою той запис, де точніше і однозначно вказаний параметр. Це ж стосується і IP-адресов.



4.Результати застосування розробленої програмної системи