БАЗИ ДАНИХ
РЕЛЯЦІЙНА
МОДЕЛЬ
МАГІСТР
СОЛОМАХІН МИКОЛА
ЗМІСТ
Історія розвитку
Ієрархічна модель
Реляційна модель
Терміни та розповсюдженність
Зв’язки
Нормалізація
Історія активного розвитку баз даних починається з одного з найзначніших і неоднозначних подій: польоту на Місяць (проект Apollo ~ 1960р.).
Вся інформація на той період зберігалася в файлової системі, яка мала ряд недоліків:
• Надмірність даних
• Неузгодженість даних
• Залежність структур даних і прикладних програм
Ці недоліки послужили поштовхом, який змусив розробників інформаційних систем запропонувати новий підхід до управління інформацією.
1968 рік - введення в експлуатацію першої СУБД система IMS фірми IBM.
1975 року - з'явився перший стандарт асоціації по мовам систем обробки даних - Conference of Data System Languages (CODASYL)
1986 рік - перший стандарт мови SQL був прийнятий ANSI (American National Standards Institute)
ІСТОРІЯ
РОЗВИТКУ
ІЄРАРХІЧНАПоле ID - унікальний ідентифікатор кожного елемента. Поле Name - назва елемента.
МОДЕЛЬ Поле Id_Parent - вказуємо батьківський елемент, який повинен бути в полі ID.
Таким чином, завдяки ієрархічній моделі, було виведено кілька фундаментальних понять: Первинний ключ (Primary Key [PK]) - обмеження, що дозволяє однозначно ідентифікувати кожну запис в таблиці. Первинний ключ повинен містити унікальні значення і не може бути порожній. Вторинний ключ (Foreign Key [FK]) - це обмеження, що дозволяє посилатися на будь-якої Primary Key. Найчастіше, може бути неунікален і містити порожні безлічі.
У прикладі, наведеному раніше, Id - це первинний ключ. Id_Parent - контрольний ключ.
РЕЛЯЦІЙНА
МОДЕЛЬ
У реляційної моделі Кодда, дані можна описувати в їх природному вигляді, без обмежень, які накладаються середовищем фізичного зберігання. Головна особливість: залежність всіх таблиць один від одного.
• СУБД - система управління базами даних, програмний |
|
комплекс. |
|
• База даних - набір логічно пов'язаних таблиць. |
|
• Реляційна база даних - набір логічно взаємопов'язаних |
|
таблиць. |
|
• Таблиця - сукупність даних, що зберігаються в |
|
структурованому вигляді. |
ТЕРМІНИ |
• SQL - це мова програмування, призначений для роботи |
|
з таблицями. |
|
• Запит - це спеціальне строкове звернення до бази |
|
даних, до однієї або декількох таблиць. |
|
• Предикат - будь-який вираз, результатом якого є |
|
значення TRUE, FALSE або UNKNOWN. |
|
РОЗПОВСЮДЖЕННІСТЬ
ЗВ’ЯЗКИ
«Один-до-одного» (1: 1) - будь-якого екземпляру сутності А відповідає тільки один екземпляр сутності В, і навпаки.
Наприклад (зазвичай), у одного чоловіка може бути лише одна дружина і у однієї дружини - тільки один чоловік.
«Один-до-багатьох» (1: М) - будь- якого екземпляру сутності А відповідає 0, 1 або кілька екземплярів сутності В, але будь- якому екземпляру сутності В відповідає тільки один екземпляр сутності А.
Наприклад, у поета може бути багато віршів, але автор у них один.
«Багато-до-багатьох» - будь-якого екземпляру сутності А відповідає 0, 1 або кілька екземплярів сутності В, і будь-якого екземпляру сутності В відповідає 0, 1 або кілька екземплярів сутності А
Наприклад, у кожного викладача може бути безліч студентів. У свою чергу, кожного студента навчає деякий безліч викладачів.
НОРМАЛІЗАЦІЯ
Нормальна форма (НФ або NF) - вимога, пред'являється до структури таблиць в теорії реляційних баз даних для усунення з бази надлишкових функціональних залежностей між атрибутами.
Процес перетворення відносин бази даних до «Нормальному» виду, називається нормалізацією. вона призначена для приведення структури БД до виду з мінімальної логічної надмірністю, і не має метою зменшення або збільшення продуктивності роботи або фізичного обсягу бази даних. кінцевою метою нормалізації є зменшення потенційної суперечливості збереженої в базі даних інформації.
1NF
Таблиця знаходиться в першій нормальній формі (1NF) тоді і тільки тоді, коли кожне з значень його полів атомарному. Наприклад, у нас є неправильна таблиця співробітників і їх телефонів. Для того, щоб вихідну таблицю перевести в 1NF потрібно забезпечити знаходження тільки одного значення в кожній з елементів таблиці:
2NF
Для другої нормальної форми (2NF) таблиця повинна знаходитися в першій нормальній формі. Будь-яке її поле, що не входить до складу первинного ключа, функціонально повно повинно залежати від первинного ключа. Наприклад, нехай в наступному відношенні первинний ключ утворює пари атрибутів {Співробітник, Посада}:
Зарплату співробітнику кожен начальник встановлює сам (хоча її кордони залежать з посади). Наявність же комп'ютера у співробітника залежить тільки від посади, тобто залежність від первинного ключа неповна. В результаті приведення до 2NF вихідне відношення слід декомпозировать (логічно розбити) на два відносини:
3NF
Для третьої нормальної форми (3NF) таблиця повинна знаходитися в другій нормальній формі. Будь її не ключовий атрибут функціонально залежить тільки від первинного ключа. Розглянемо в якості відповідає 3NF. прикладу ставлення, яке знаходиться у 2NF, але не.
Відносно атрибут «Співробітник» є первинним ключем. Особистих телефонів у співробітників немає, і телефон співробітника залежить виключно від відділу. Таким чином, відносно існують такі функціональні залежності: Співробітник → Відділ, Відділ → Телефон, співробітник → Телефон. залежність Співробітник → Телефон є побічної, отже, ставлення не перебуває у 3NF. В Внаслідок поділу відносини виходять два відносини, що знаходяться в 3NF: