4Проектування бази даних інформаційної системи

4.1 Проектування інфологічної моделі

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

База даних «Dip» збережена на віддаленому сервері, та тримає зв'язок через інтернет ресурс.

Завдання концептуального інфологічного проектування полягає в отриманні БД у термінах сутностей та зв’язку між ними, що не залежить від СУБД і узагальнює вимоги користувачів інформаційної системи. Розрізняються два методи концептуального інфологічного проектування: низхідне проектуваня і висхідне проектування. Ці методи недостатньо формалізовані, єдиних правил використання їх не існує.

Одним з найнадійніших є перший метод, який складається з двох частин.

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

"Velo"

1 - ID, 2 -name, 3 –category.

"velo_info"

1 - ID, 2 - Image, 3 -Name, 4 –Class, 5 –Color, 6 – Rozm, 7 – Rama, 8 – Karet, 9 – Vilka, 10 – shatun, 11 – Zperekl, 12 – Pperecl, 13 – Caseta, 14 – Cep, 15 – Kperedach, 16 – Typeform, 17 – Tormoz, 18 – Rtormoz, 19 – Obod, 20 – Pokr, 21 – Diametrcol, 22 – Rul, 23 – Vrul, 24 – Shtir, 25 – Sidlo, 26 – Pedali, 27 – Weight, 28 – Guarantee, 29 – Price, 30 – Category,31 – vID .

"Profile"

1 - ID, 2 – login,3 –psswd, 4 –initcialu, 5 – Amail, 6 – phone, 7 – secret, 8 – vd, 9 – adresa, 10 – index1, 11 – role.

"zakaz"

1 – ID, 2 – status, 3 – cid,4 – pid, 5–lid,6–uID.

"Velo"

1 -> 2,3

"velo_info"

1-> 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31

"Profile"

1 -> 2,3,4,5,6,7,8,9,10,11

"Oform"

1 -> 2,3,4,5

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

Між двома сутностями, наприклад, А і В, можливі чотири види зв’язків.

Зв’язок один-до-одного (1:1): у кожен момент часу кожному екземпляру сутності А відповідає 1 або 0 екземпляр сутності В.

Студент може не одержувати стипендію, одержати звичайну або одну з підвищених стипендій.

Зв’язок один-до-багатьох (1:М): одному представнику сутності А відповідають 0, 1 або декілька представників сутності В.

Оскільки між двома сутностями можливі зв’язки в обох напрямах, то існує ще два типу зв’язку: Багато-до-одного (М:1) і багато-до-багатьох (М:N).

Проставимо зв’язки між сутностями:

Таблиця ”product” має зв’язок один-до-багатьох, тобто 1 → N

"Velo" → "Velo_info";

"Velo" → "Oform";

Таблиця ”Velo_info” має зв’язок один-до-одного, тобто 1 → 1

"Velo_info" →"Oform";

Таблиця ”Profile має зв’язок один-до-одного, тобто 1 →1

"Profile" → "Oform";

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

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

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

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

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

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

Кожна сутність володіє хоч би одним можливим ключем. Один з них береться за первинний ключ. При виборі первинного ключа слід віддавати перевагу нескладеним ключам або ключам, складеним з мінімального числа атрибутів. Недоцільно також використовувати ключі з довгими текстовими значеннями (переважно використовувати цілочисельні атрибути). Так, для ідентифікації студента можна використовувати або унікальний номер залікової книжки, або набір з прізвища, імені, по батькові, номера групи і може бути додаткових атрибутів, оскільки не виключено появи в групі двох студентів з однаковими прізвищами та іменами. Погано також використовувати як ключ назву, наприклад “Закуска з плавлених сирків "Дружба" з шинкою”.

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

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

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

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

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

Обмеження цілісності сутності і по посиланнях повинні підтримуватися СУБД.

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

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

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

Таблиця 4.1 – Akses.

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Name	VARCHAR(50)	Назва
Category	VARCHAR(50)	Категорія

Таблиця 4.2 – Akses_info

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Diametr	VARCHAR(50)	Діаметр
Color	VARCHAR(50)	Колір
Weight	VARCHAR(50)	Вага
Guarantee	VARCHAR(50)	Гарантія
Price	VARCHAR(50)	Ціна
#vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.3 – Amor

Назва поля	Тип поля	Опис
Id	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Color	VARCHAR(50)	Колір
Rozm	VARCHAR(50)	Ромір
Type	VARCHAR(50)	Тип
Dlina	VARCHAR(50)	Довжина
Hod	VARCHAR(50)	Матеріал
Price	VARCHAR(50)	Ціна
Guarantee	VARCHAR(50)	Гарантія
#vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.4 – Komp

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Name	VARCHAR(50)	Назва
Category	VARCHAR(50)	Категорія

Таблиця 4.5–Kyrtki

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Color	VARCHAR(50)	Колір
Razm	VARCHAR(50)	Розмір
Material	VARCHAR(50)	Матеріал
Pokr	VARCHAR(50)	Покрой
Osob	VARCHAR(50)	Особливості
Price	VARCHAR(50)	Ціна
vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.6–Nakol

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Razm	VARCHAR(50)	Розмір
Krip	VARCHAR(50)	Кріплення
Material	VARCHAR(50)	Матеріал
Price	VARCHAR(50)	Ціна
uID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.7 – Obod

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Type	VARCHAR(50)	Тип
Material	VARCHAR(50)	Матеріал
Diametr	VARCHAR(50)	Діаметр
Shir	VARCHAR(50)	Ширина
Vis	VARCHAR(50)	Висота
Rozm	VARCHAR(50)	Розмір
Otv	VARCHAR(50)	Кількість отворів
Color	VARCHAR(50)	Колір
Weight	VARCHAR(50)	Вага
Guarantee	VARCHAR(50)	Гарантія
Price	VARCHAR(50)	Ціна
VID	VARCHAR(50)	Зовнішній ідентифікатор

Таблиця 4.8 – pokr

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Rozm	VARCHAR(50)	Розмір
Kord	VARCHAR(50)	Корд
Davl	VARCHAR(50)	Тиск
Nagr	VARCHAR(50)	Навантаження
Weight	VARCHAR(50)	Вага
Guarantee	VARCHAR(50)	Гарантія
Price	VARCHAR(50)	Ціна
vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.9–rul

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Забраження
Name	VARCHAR(50)	Назва
Type	VARCHAR(50)	Тип
Material	VARCHAR(50)	Матеріал
Color	VARCHAR(50)	Колір
Price	VARCHAR(50)	Ціна
vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.10 – shlem

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Забраження
Name	VARCHAR(50)	Назва
Type	VARCHAR(50)	Тип
Vyd	VARCHAR(50)	Вид
Razm	VARCHAR(50)	Розмір
Otv	VARCHAR(50)	Отвори
Smen	VARCHAR(50)	Змінні вставки
Weight	VARCHAR(50)	Вага
Color	VARCHAR(50)	Колір
Guarantee	VARCHAR(50)	Гарантія
Price	VARCHAR(50)	Ціна
vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.11 – Sporyad

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Name	VARCHAR(50)	Назва
Category	VARCHAR(50)	Категорія

Таблиця 4.12–Velo

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Name	VARCHAR(50)	Назва
Category	VARCHAR(50)	Категорія

Таблиця 4.13–Velo_info

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Class	VARCHAR(50)	Клас
Color	VARCHAR(50)	Колір
Rozm	VARCHAR(50)	Розмір
Rama	VARCHAR(50)	Тип рами
Karet	VARCHAR(50)	Каретка
Vilka	VARCHAR(50)	Вилка
Shatun	VARCHAR(50)	Шатун
Zperekl	VARCHAR(50)	Задній перемикач передач
Rperekl	VARCHAR(50)	Передній перемикач передач
Caseta	VARCHAR(50)	Касета
Cep	VARCHAR(50)	Цеп
Kperedach	VARCHAR(50)	Кількість передач
Rypeform	VARCHAR(50)	Форма
Tormoz	VARCHAR(50)	Гальма
Rtormoz	VARCHAR(50)	Рульові гальма
Obod	VARCHAR(50)	Обод
Pokr	VARCHAR(50)	Покриття
Diametrkol	VARCHAR(50)	Діаметр колеса
Rul	VARCHAR(50)	Курмо
Vrul	VARCHAR(50)	Розміщення
Shtir	VARCHAR(50)	Довжина амортизатора
Sidlo	VARCHAR(50)	Сідло
Pedali	VARCHAR(50)	Педалі
Weight	VARCHAR(50)	Вага
Guarantee	VARCHAR(50)	Гарантія
price	VARCHAR(50)	Ціня
category	INT(11)	Категорія
vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.14 – Vilka

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Weight	VARCHAR(50)	Вага
Reg	VARCHAR(50)	Регулятор
Prug	VARCHAR(50)	Пружина
Color	VARCHAR(50)	Колір
Guarantee	VARCHAR(50)	Гарантія
Price	VARCHAR(50)	Ціна
vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.15 – Zamki

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Typ	VARCHAR(50)	Тип
Dop	VARCHAR(50)	Додаткова інформація
Color	VARCHAR(50)	Колір
Guarantee	VARCHAR(50)	Гарантія
Price	VARCHAR(50)	Ціна
vID	INT(11)	Зовнішній ідентифікатор

Таблиця 4.15 – Zekala

Назва поля	Тип поля	Опис
ID	INT(11)	Індивідуальний номер
Image	VARCHAR(50)	Зображення
Name	VARCHAR(50)	Назва
Color	VARCHAR(50)	Колір
Priznach	VARCHAR(50)	Призначення
Sovmest	VARCHAR(50)	Сумісність
Reg	VARCHAR(50)	Регулювання
Montag	VARCHAR(50)	Тип монтажу
Diametr	VARCHAR(50)	Діаметр
Material	VARCHAR(50)	Матеріал
Weight	VARCHAR(50)	Вага
Guarantee	VARCHAR(50)	Гарантія
Price	VARCHAR(50)	Ціна
vID	INT(11)	Зовнішній ідентифікатор