Embedded Files
Модель "сутність-зв'язок"
Розробник бази даних повинен описати певну предметну область, змоделювати її для використання у вигляді бази даних. Така модель називається моделлю сутність-зв'язок. Розглянемо її побудову.
Ми знаємо, що найбільш поширеною є реляційна модель, в основі якої лежать таблиці з наборами однотипних об’єктів. Тобто передусім, аналізуючи предметну область, потрібно виділити об’єкти і виокремити серед них сутності – множини об’єктів, котрі мають однаковий набір параметрів, суттєвих для бази даних. Так, у школі є різні класи – це об’єкти, котрі належать до сутності Клас. У класі вчаться учні – що належать до сутності Учень. У бібліотеці зберігаються книги – сутність Книга. У кожному випадку конкретний екземпляр сутності, конкретний об’єкт, має такий же набір властивостей, як й інші об’єкти тієї ж сутності, але різні значення властивостей.
Сутність - це множина об'єктів, які мають однаковий набір параметрів.
Об’єкти можуть перебувати у зв’язках з іншими об’єктами. Наприклад, учитель викладає у класі, учень вчиться у класі, а читач бере книгу в бібліотеці.
Опис сутностей та зв’язків предметної області називається моделлю сутність-зв'язок, і для графічного позначення моделі використовуються схеми, як показано на рисунку.
Сутності записуються у прямокутниках, під якими вказується перелік їхніх властивостей або атрибутів. Варто зазначити, що неможливо перелічити всі властивості об’єкта, адже у різних базах даних будуть важливими різні параметри. Так, у базі даних школа неважливим є колір волосся чи очей учнів та вчителів. А у базі даних перукарня – ця інформація є важливою і тому має зберігатись як параметр сутності Клієнт. Ця сама людина у базі даних поліклініки матиме ще атрибут група крові чи вага.
Деякі з атрибутів є ключовими – вони дозволяють унікально ідентифікувати об’єкт сутності. Наприклад, у людей можуть повторюватись прізвище, ім’я, по батькові, проте не може повторюватись номер паспорту. І знаючи цей номер, ми можемо точно дізнатись, котрий саме Іваненко Тарас Михайлович відкрив рахунок у банку. Отже людину можна ідентифікувати за номером паспорта.
Учня школи можна ідентифікувати, наприклад, за прізвищем,іменем, але ж вони можуть збігатись. Навряд-чи можливо, щоб збігалась ще й дата народження, тож ці три поля разом можуть формувати ключ для сутності Учень. Проте по-перше, ми не можемо бути впевнені, що не буде повторів, а по-друге, надалі зручніше працювати з простим ключем, тож часто вводиться певний штучний код для використання у вигляді ключа.
У різних базах даних це можуть бути різні коди та номери – наприклад, ідентифікаційний код для громадянина; індекс для поштових відділень. Проте наприклад за індексом дізнатись точну адресу неможливо. Як і за назвою вулиці, без уточнення міста. Квиток в кіно обов’язково містить ряд і місце, які разом з назвою фільму та часом початку сеансу ідентифікують перегляд його глядачем у певному кінотеатрі.
Поняття моделі даних
Базою даних є структурована сукупність даних, які відображають стан об'єктів певної предметної області та зв'язки між ними. Об'єкти БД характеризуються сукупністю елементарних одиниць даних, між якими будуть встановлені однозначні зв'язки. Це означає, що основою будь-якої структури даних є відображення елементарної одиниці даних у вигляді трійки: <об'єкт, атрибут об'єкта, значення атрибута>.
Приклад, <учень, клас, 9>.
Існують різні способи відображення зв’язків між даними, тобто різні моделі даних. Нині є три класичні моделі даних: ієрархічна, мережева і реляційна. Ієрархічна і мережева моделі засновані на таких поняттях, як рівень, вузол, зв’язок.
Основним недоліком ієрархічних і мережевих БД є складність їх розроблення, тому нині поширення набула реляційна модель даних — фактографічна база даних, що є набором взаємопов’язаних таблиць. Основна перевага цієї моделі полягає у простоті розроблення БД і систем управління ними.
Найпростіша БД містить одну таблицю, а складні — десятки й навіть сотні таблиць.
Розглянемо приклад найпростішої реляційної БД, яка містить тільки одну таблицю УЧНІ.
Не кожна таблиця може бути об’єктом БД. Для того щоб таблиця стала об’єктом БД, потрібно виконати її нормалізацію. Сутність нормалізації полягає в тому, що таблиця повинна бути перетворена відповідно до основних вимог.
Основні вимоги до таблиці як об’єкта БД такі:
• кожне поле повинно мати унікальне ім’я;
• усі поля мають бути однорідними, тобто значення елементів одного поля можуть бути лише одного типу (наприклад, тільки числовими, тільки рядковими);
• у таблиці не може бути однакових записів, вони мають відрізнятися значеннями хоча б одного поля;
• таблиця повинна мати ключове поле, або ключ.
Зазвичай таблиця має унікальне поле або кілька полів, які ідентифікують записи. Таке поле називають ключовим (ключем). Воно використовується для швидкого пошуку даних, а також для зв’язування даних із різних таблиць. Ключ, який містить тільки одне поле, називають простим, а який містить кілька полів — складним. У таблиці УЧНІ складним ключем можна вважати поля Прізвище і Дата народження, оскільки вони однозначно ідентифікують записи. У таблиці може бути кілька ключів, але тільки один із них можна визнати як первинний. Найкраще первинним ключем вибрати простий ключ і бажано, щоб він мав цілочисловий тип. У цьому випадку операції опрацювання даних виконуватимуться швидше. У таблиці УЧНІ простим є поле з іменем Номер.
У таблиці часто використовують поле — воно називається лічильником, яке використовується для того, щоб зробити кожний запис унікальним. Крім того, лічильник забезпечує нумерацію записів. У таблиці УЧНІ лічильником є поле з іменем Номер.
В основній таблиці вибирають первинний ключ, а в допоміжній — зовнішній ключ. Зовнішній ключ повинен однозначно визначати поле основної таблиці. У ньому не може бути даних, відсутніх у первинному ключі, інакше зв’язок буде некоректним. Часто для забезпечення зв’язку між таблицями в допоміжну таблицю спеціально вводять поле з таким самим іменем, що й ім’я первинного ключа основної таблиці. У такому випадку деякі СУБД автоматично встановлюють зв’язок між таблицями. Якщо імена зазначених полів різні, то користувач повинен сам встановити зв’язок між ними. Пояснимо сутність зв’язків між двома таблицями на прикладі 2.
Таким чином, зв’язки між таблицями дозволяють отримати дані з кількох таблиць. Окрім того, вони забезпечують цілісність даних у пов’язаних таблицях, якщо з деяких причин сталися зміни в одній таблиці.
Між таблицями можуть існувати 4 види зв’язку:
Найчастіше між таблицями реляційної БД існує зв’язок одиндобагатьох.
Практичне завдання. Працюємо у MS Word
Увага! Під час роботи з комп'ютером дотримуйтеся вимог безпеки життєдіяльності та санітарно-гігієнічних норм.
Завдання 1. Дайте відповіді на питання.
Завдання 2. Створіть модель «Турфірма»
Завдання 3. Визначте первинний ключ у таблиці Постачальники. Чи може бути такий самий первинний ключ у таблиці Товари? Чому?
Page updated
Google Sites
Report abuse