Урок 2. Поняття моделі подання даних, основні моделі подання даних.

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

Опрацювати теоретичний матеріал, скласти конспект

Теоретичний матеріал.

Як вже зазначалося, об’єкти предметної галузі характеризуються сукупністю атрибутів (властивостей) та їх значеннями. Одне значення атрибута називають елементарною одиницею даних. Наприклад, для об’єкта АВТОМОБІЛЬ його елементарними одиницями можуть бути марка — Volkswagen і двигун — дизельний. Таким чином, об’єкти БД характеризуються сукупністю елементарних одиниць даних, між якими повинні бути встановлені однозначні зв’язки. Це означає, що основою будь-якої структури даних є відображення елементарної одиниці даних у вигляді трійки: <об’єкт, атрибут об’єкта, значення атрибута>, наприклад: <учень, прізвище, Костирко>; <учень, клас, 11>.

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

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

Із рис. 1.4 видно, що в цьому випадку ієрархічна модель містить три рівні об’єктів. На верхньому рівні міститься головний об’єкт, на другому рівні розташовано два вузли, на третьому — три вузли. Зв’язки між вузлами зображено стрілками. Як бачимо, вузли верхнього рівня мають зв’язки з вузлами найближчого нижнього рівня. Мережева модель містить два рівні (їх може бути скільки завгодно), на кожному з яких є два вузли. Звернемо увагу на те, що в цій моделі кожний вузол може мати зв’язок із будь-яким іншим вузлом. Основним недоліком ієрархічних і мережевих БД є складність їх розроблення, тому нині поширення набула реляційна модель даних — фактографічна база даних, що є набором взаємопов’язаних таблиць. Основна перевага цієї моделі полягає у простоті розроблення БД і систем управління ними. Найпростіша БД містить одну таблицю, а складні — десятки й навіть сотні таблиць. Розглянемо приклад найпростішої реляційної БД, яка містить тільки одну таблицю УЧНІ (табл. 1.1).

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

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

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

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

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

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