Інформатика – Поглиблений рівень

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

Деякі з атрибутів є ключовими – вони дозволяють унікально ідентифікувати об’єкт сутності. Наприклад, у людей можуть повторюватись прізвище, ім’я, по батькові, проте не може повторюватись номер паспорту. І знаючи цей номер, ми можемо точно дізнатись, котрий саме Іваненко Тарас Михайлович відкрив рахунок у банку. Отже людину можна ідентифікувати за номером паспорта.

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

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

Існують різні способи відображення зв’язків між даними, тобто різні моделі даних. Нині є три класичні моделі даних:

• ієрархічна
• мережева
• реляційна.

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

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

Найпростіша БД містить одну таблицю, а складні — десятки й навіть сотні таблиць. Розглянемо приклад найпростішої реляційної БД, яка містить тільки одну таблицю УЧНІ

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

Основні вимоги до таблиці як об’єкта БД такі:
• кожне поле повинно мати унікальне ім’я;

• усі поля мають бути однорідними, тобто значення елементів одного поля можуть бути лише одного типу (на-
приклад, тільки числовими, тільки рядковими);

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

Зазвичай таблиця має унікальне поле або кілька полів, які ідентифікують записи. Таке поле називають ключовим

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

Ключ, який містить тільки одне поле, називають простим, а який містить кілька полів — складним. У таблиці УЧНІ складним ключем можна вважати поля Прізвище і Дата народження, оскільки вони однозначно ідентифікують записи.

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

У таблиці часто використовують поле — воно називається лічильником, яке використовується для того, щоб зробити кожний запис унікальним. Крім того, лічильник забезпечує нумерацію записів. У таблиці УЧНІ лічильником є поле з іменем Номер.

В основній таблиці вибирають первинний ключ, а в допоміжній — зовнішній ключ. Зовнішній ключ повинен однозначно визначати поле основної таблиці. У ньому не може бути даних, відсутніх у первинному ключі, інакше зв’язок буде некоректним. Часто для забезпечення зв’язку між таблицями в допоміжну таблицю спеціально вводять поле з таким самим іменем, що й ім’я первинного ключа основної таблиці.
У такому випадку деякі СУБД автоматично встановлюють зв’язок між таблицями. Якщо імена зазначених полів різні, то користувач повинен сам встановити зв’язок між ними. Пояснимо сутність зв’язків між двома таблицями на прикладі 2.

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

Між таблицями можуть існувати 4 види зв’язку:

Найчастіше між таблицями реляційної БД існує зв’язок один­ до ­багатьох.

Працюємо за ПК!

Нехай у БД будівельної компанії є дві таблиці: ПОСТАЧАЛЬНИКИ і ТОВАРИ.

• Визначте первинний ключ у таблиці “Постачальник”.
• Чи може бути такий самий первинний ключ у таблиці “Товари”? Чому?