Бази даних та інформаційні системи

Загальні положення реляційної моделі даних. �Реляційна цілісність даних.

Лекції 1,2,3

Загальна інформація:

• Лектор: Яковлева Олена Володимирівна
• доцент каф. Інформатики
• e-mail: olena.yakovleva@nure.ua
• блог: http://infdbis.blogspot.com/
• Telegram-група: ITINF_23_DB_Yakovleva

посилання: https://t.me/+JN7J0q8vx2IyNDQy

• Робочий простір у MS Teams: ITINF_23_DB_Yakovleva | Загальне | Microsoft Teams

MS Teams WEB: https://teams.microsoft.com/v2/?clientexperience=t2

• ZOOM : https://nure-ua.zoom.us/j/83410071108?pwd=c2ZwSFJEM2FpSEpybXlYR2hEbGl1Zz09

Ідентифікатор конференції: 834 1007 1108

Код доступу: ITINF_22

• Система тестування SQL запитів STPtestSQL : https://stp.sytoss.com/

Інформація про систему:https://drive.google.com/file/d/1DFTraitQ6QHJP-h9qk2Nc1WdD92VOAGx/view?usp=sharing

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

2

Силабус до БДІС

​

• Дисципліна «Бази даних та інформаційні системи» викладається разом з дисципліною «Організація баз даних», яка починається на 1 місяць пізніше. Таким чином, дисципліни «Бази даних та інформаційні системи», «Організація баз даних» викладається в одному семестрі як одна велика дисципліна на 10 ЄКТС кредитів, що складається з двох частин, за кожную з яких студент отримує окрему оцінку.
• �«Бази даних та інформаційні системи» (частина1) знайомить студентів з тенденціями розвитку БД, основними принципами реляційних БД (первий, зовнішний ключі, цілісність даних), мовою SQL DQL (складного рівня, але без віконних функцій over, умовного оператора case, розширення group by, pivot, CTE, view, рекурсивних запитів, індексів та оптимізації), мовою SQL DML (insert, delete, update).
• Головний фокус на мові SQL

Пряме посилання: https://goo.su/VDUPa

Посиланння на сайт кафедри: https://goo.su/WGaE

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

3

Заповніть форму «Знайомство»:

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

4

https://forms.gle/uEpwLgtEk1iWRF7D6

�Джерела з вивчення мови SQL �та проектування реляційних БД:

1. Берко А.Ю. Системи баз даних та знань, книга 2: Навчальний посібник (рек.МОН України) / Берко А.Ю., Верес О.М. , Пасічник В.В – Магнолія 2006, 2021. – 584 с.

2. Foster, E. C., & Godbole, S. V. (2023). Database systems: A pragmatic approach. CRC Press.

3. Hernandez, M. J. (2021). Database design for mere mortals: A hands-on guide to relational database design. Addison-Wesley.

4. Mark Reed. (2022) SQL: 3 books 1 - The Ultimate Beginner, Intermediate & Expert Guides To Master SQL Programming Quickly with Practical Exercises Paperback.

5. Taylor, A. G. (2019). SQL for dummies. For Dummies, a Wiley brand.

6. Product support - erwin data modeler. (n.d.). Retrieved January 13, 2023, from https://support.quest.com/erwin-data-modeler/12.1

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

5

План лекції

Вступ

1. Структура реляційних даних
• Тип даних
• Домен
• Атрибути
• Кортежі
• Заголовок відношень
• Тіло відношень
• Значення відношення або відношення-екземпляр
2. Подання схем у реляційній моделі (РМ)
3. Властивості відношень
4. Реляційні ключі
5. Реляційна цілісність
• Порожні значення
• Цілісність сутностей (відношень)
• Цілісність посилань
• Корпоративні обмеження цілісності
• Підтримка реляційної цілісності

Висновок

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

6

Вступ

Коротенька історія

• 3600 до н.е. - глиняні таблички у стародавніх шумерів;
• 1968 г. - перша промислова СУБД фірми IBM;
• 1972 р. - компанія IBM почала дослідницький проєкт із розроблення РСУБД;
• 1974 г. - Реймонд Бойс і Дональд Чамберлен в IBM створили мову запитів до РБД SEQUEL (Structured English Query Language)
• 1979 г. - вихід першої РСУБД Oracle (перша комерційна РСУБД на основі мови запитів SQL);
• 1980 г. - поява dBase II;
• 1981 г. - поява IBM PC;
• 1982 г. - вихід DB2 фірми IBM;
• 1986 р. - стандартизація SQL (ANSI), остання версія SQL:2023
• 1988г. - вихід SQL Server 1.0;
• 1992 р. - з'являється СУБД MS Access;
• 1993 г. - вихід Intel Pentium, Seagate Medalist 425xe 428.1MB HDD;
• 1994 г. - вихід Oracle для PC;
• 1995 г. - поява MySQL;
• 1996 р. - поява PostgreSQL;
• 2005 г. - поява Hadoop;
• 2009 г. - поява MongoDB - NoSQL .

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

7

Вступ

База даних (БД) - це взаємопов'язана інформація (дані) про об'єкти, що організована спеціальним чином і зберігається на будь-якому носії.

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

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

8

Вступ

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

Перевагами реляційного підходу прийнято вважати такі властивості:

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

9

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

Едгар Франк Кодд

Вступ

СУБД - система управлінням базою даних

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

10

Навіщо потрібні СУБД ?

​

Оскільки дані – це ядро будь-якої програми, є необхідною:

• Стандартизація роботи з даними
• Надійне зберігання та масштабування даних
• Готовий функціонал для
• транзакцій (цілісність даних)
• індексування (прискорення)
• блокування, конкурентний доступ

​

​

Вступ

Реляційні рішення (використовують SQL)

Реляційний - від англ. relation (відношення, залежність, взаємозв'язок)

​

​

​

​

​

​

​

​

​

​

​

​

​

Рисунок 1.1 - Приклади реляційних СУБД

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

11

Вступ

Нереляційні бази даних

(NoSQL - не тільки SQL)

​

​

​

​

​

​

​

Рисунок 1.2 - Приклади NoSQL СУБД

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

12

Найпопулярніші бази даних - 2006/2023

У лютому 2023 року найбільш часто використовуваними і популярними базами даних є:

Oracle - 31,2%,

MySql - 21,9%

SQL Server - 11,8%.

​

​

​

​

​

​

​

​

​

​

Графік був створений з використанням даних, представлених в індексі TOPDB Top Database, і відноситься до відсотка пошуків за окремими базами даних у Google - найбільш використовуваної пошукової платформи у світі

https://www.youtube.com/watch?v=hfKnFvv9vRU&t=24s

Сайт: http://statisticsanddata.org/

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

13

Рейтинг найпопулярніших СУБД у світі станом на червень 2024 р.

https://www.statista.com/statistics/809750/worldwide-popularity-ranking-database-management-systems/

https://www.geeksforgeeks.org/most-popular-databases/

https://db-engines.com/en/ranking

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

14

Парадигми та принципи СУБД

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

Ці принципи охоплюють різні аспекти від цілісності даних і продуктивності до зручності використання та масштабованості.

Основні парадигми, які оцінюють якість СУБД:

• ACID (Atomicity, Consistency, Isolation, Durability)
• BASE (Basically Available, Soft state, Eventual consistency)
• CAP-теорема (Consistency, Availability, Partition tolerance)
• Масштабованість (Scalability)
• Надійність і відмовостійкість (Reliability and Fault tolerance)
• Продуктивність (Performance)
• Гнучкість (Flexibility)
• Зручність використання (Usability)
• Безпека (Security)
• Підтримка транзакцій і запитів (Transaction and Query Support)
• Для реляційних + 12 правил Кодда

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

15

wikipedia: https://goo.su/9zfszM

ACID-парадигма (1983)

Концепція ACID була введена в 1983 році Андреа Рейтером і Тео Хардером.�ACID парадигма стала основою для розробки надійних СУБД, які забезпечують цілісність і надійність даних у різних додатках (особливо в фінансових системах, де критично важливо уникати втрати даних або некоректних записів).

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

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

Основні властивості ACID

• Атомарність (Atomicity): �Гарантує, що транзакція буде виконана повністю або не буде виконана зовсім. Якщо одна з операцій у транзакції не вдалася, всі зміни, внесені в рамках цієї транзакції, скасовуються.
• Узгодженість (Consistency): �Після завершення транзакції база даних повинна залишатися в узгодженому стані. Це означає, що всі правила та обмеження цілісності повинні дотримуватися до і після виконання транзакції.
• Ізоляція (Isolation): �Транзакції повинні виконуватися незалежно одна від одної. Це означає, що результати однієї транзакції не повинні бути видимими для інших транзакцій, поки перша не завершиться.
• Довговічність (Durability): �Після того, як транзакція була зафіксована, її результати повинні зберігатися в системі, навіть у разі збою системи або відмови обладнання.

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

16

wikipedia: https://goo.su/9zfszM

ACID-парадигма - приклад

Приклад: Транзакція з переказу грошей з одного банківського рахунку на інший.

​

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

​

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

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

17

12 правил Кодда (1985) – це є СУБД реляційною?

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

​

0. Фундаментальне правило (Foundation Rule)�Система, яка рекламується або позиціонується як РСУБД, має бути здатною керувати базами даних, використовуючи виключно свої реляційні можливості

1. Інформаційне правило (Information Rule)�Інформація має бути представлена у вигляді даних, що зберігаються в комірках. Дані, що зберігаються у комірках, мають бути атомарними. Порядок рядків у реляційній таблиці не повинен впливати на зміст даних і їх обробку.

2. Правило гарантованого доступу (Guaranteed Access Rule)�Доступ до даних має бути вільним від двозначності. До кожного елементу даних має бути гарантований доступ за допомогою комбінації імені таблиці, первинного ключа рядку й імені стовпця.

3. Систематична обробка Null-значень (Systematic Treatment of Null Values)�Невідомі значення NULL, відмінні від будь-якого відомого значення, мають підтримуватись для всіх типів даних при виконанні будь-яких операцій. Наприклад, для числових даних невідомі значення не повинні розглядатись як нулі, а для символьних даних — як порожні рядки.

4. Правило доступу до системного каталогу на основі реляційної моделі (Dynamic On-line Catalog Based on the Relational Model)�Словник даних (метадані) має зберігатись у формі реляційних таблиць, і СУБД повинна підтримувати доступ до нього за допомогою стандартних мовних засобів, тих самих, що використовуються для роботи з реляційними таблицями, які містять дані користувача.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

18

wikipedia: https://goo.su/Xa40UGh

5. Правило повноти підмови маніпулювання даними (Comprehensive Data Sublanguage Rule)�СУБД підтримує операції визначення даних, визначення предствлень, маніпулювання даними (інтерактивні та програмні), обмежувачі цілісності, управління доступом та операції управління транзакціями (begin, commit і rollback).

6. Правило модифікації розрізів (View Updating Rule)�Кожне VIEW має підтримувати усі операції маніпулювання даними, які підтримують реляційні таблиці: операції вибірки, вставки, модифікації і видалення даних.

7. Правило високорівневих операцій модифікації даних (High-level Insert, Update, and Delete)�Операції вставки, модифікації і видалення даних мають підтримуватись не тільки щодо одного рядку реляційної таблиці, але й щодо будь-якої безлічі рядків.

8. Правило фізичної незалежності даних (Physical Data Independence)�Додатки не повинні залежати від використовуваних способів зберігання даних на носіях, від апаратного забезпечення комп'ютерів, на яких знаходиться реляційна база даних.

9. Правило логічної незалежності даних (Logical Data Independence)�Представлення даних в додатку не повинно залежати від структури реляційних таблиць. Якщо в процесі нормалізації одна реляційна таблиця розділяється на дві, подання має забезпечити об'єднання цих даних, щоб зміна структури реляційних таблиць не позначалась на роботі додатків.

10. Правило незалежності контролю цілісності (Integrity Independence)�Вся інформація, необхідна для підтримки цілісності, має бути у словнику даних. Мова для роботи з даними має виконувати перевірку вхідних даних і автоматично підтримувати цілісність даних.

11. Правило незалежності від розміщення (Distribution Independence)�База даних може бути розподіленою, може перебувати на кількох комп'ютерах, і це не повинно впливати на додатки, як і перенесення бази даних на інший комп'ютер.

12. Правило узгодженості мовних рівнів (The Nonsubversion Rule)�Якщо використовується низькорівнева мова доступу до даних, вона не повинна ігнорувати правила безпеки і правила цілісності, які підтримуються мовою більш високого рівня.

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

19

1.Структура реляційних даних

• Реляційна модель даних будується на відношеннях (таблицях)

​

​

​

​

​

​

​

​

​

​

Рисунок 1.3 - Основні поняття реляційних баз даних

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

20

Тип даних

• Значення даних, що зберігаються в реляційній базі даних, є типізованими, тобто відомий тип кожного збереженого значення.
• Поняття типу даних у реляційній моделі даних повністю відповідає поняттю типу даних у мовах програмування.
• Традиційне (нестроге) визначення типу даних складається з трьох основних компонентів:
• визначення множини значень даного типу;
• визначення набору операцій, які можуть бути застосованими до значень типу;
• визначення способу зовнішнього представлення значень типу.
• У всіх сучасних реляційних базах даних допускається зберігання базових типів:
• логічний;
• числових даних;
• символьних;

а також спеціалізованих типів:

• спеціалізованих числових даних (таких, як "грошовий");
• спеціальних "темпоральних"/"календарних" даних (дата, час, часовий інтервал);
• бінарні строкові дані (зображення);
• інші (документи xml, векторні об'єкти, json ...).

Активно розвивається підхід до впровадження в реляційні системи можливостей визначення користувачами власних типів даних.

• У прикладі на рис.1.3 ми маємо справу з даними трьох типів: символьний, цілі числа і "грошовий".

​

​

​

​

​

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

21

Домен

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

З кожним доменом пов'язується ім'я, унікальне серед імен усіх доменів відповідної бази даних.

• ! Таким чином, домен - це обмеження базового типу даних, що задається деяким логічним виразом.
• ! Якщо деякий атрибут відношення визначається на деякому домені, то надалі обмеження домену відіграє роль обмеження цілісності, що накладається на значення цього атрибута.

​

​

​

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

22

Домен

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Зауваження!

• Дані вважаються порівнянними тільки в тому випадку, коли вони належать до одного домену;
• Арифметичні операції між значеннями різних доменів можливі.
• Наприклад, заробітна плата (домен визначено на грошовому типі) може бути помножена на кількість відпрацьованих місяців (домен визначено на цілому типі).
• Як випливає з прикладів, забезпечити повну реалізацію поняття домену зовсім непросто, тому в багатьох реляційних СУБД вони підтримуються не повністю, а лише частково.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

23

Таблиця 1.1 - Приклади доменів деяких атрибутів

Домен

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Зауваження!

• Дані вважаються порівнянними тільки в тому випадку, коли вони належать до одного домену;
• Арифметичні операції між значеннями різних доменів можливі.
• Наприклад, заробітна плата (домен визначено на грошовому типі) може бути помножена на кількість відпрацьованих місяців (домен визначено на цілому типі).
• Як випливає з прикладів, забезпечити повну реалізацію поняття домену зовсім непросто, тому в багатьох реляційних СУБД вони підтримуються не повністю, а лише частково.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

24

Таблиця 1.1 - Приклади доменів деяких атрибутів

Атрибут

Атрибут - це властивість об'єкта предметної області.

Будемо позначати А

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

25

Відношення (сутність)

• Поняття відношення є найбільш фундаментальним у реляційному підході до організації баз даних.
• Це відображено і в загальній назві підходу - термін реляційний (relational) походить від relation (відношення).
• Для уточнення терміна відношення r виокремлюють поняття:
• заголовок (або схема) відношення (Hr) ;
• кортеж (tr) (tuple);
• тіло стосунків (Br);
• значення (відношення-екземпляр) (Vr);

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

26

Відношення (сутність)

• Заголовком (або схемою) відношення r (Hr) називається скінченна множина пар виду

{< A, T> },

де A ім'я атрибута;

T ім'я деякого базового типу або домену.

! Потрібно, щоб усі імена атрибутів у заголовку відношення були різні.

• Заголовком відношення СЛУЖБОВЦІ (рис.1.1) є множина пар

{< слу_номер, номери_пропусків>, < слу_ім'я, імена>,

< слу_зарп, розміри_виплат>, < слу_відд_номер, номери_відділів>}.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

27

Відношення (сутність)

• Кортежем tr, що відповідає заголовку Hr, називається множина впорядкованих триплетів виду

{< A, T, v> },

по одному такому триплету для кожного атрибута в Hr,

v -допустиме значення типу даних або домену T.

• Заголовку відношення СЛУЖБОВИК відповідають, наприклад, такі кортежі:

{< слу_номер, номери_пропусків, 2934>, <слу_ім'я, імена, Іванов>, <слу_зарп, розміри_виплат, 22.000>, <слу_відд_номер, номери_відділів, 310>}},

​

{< слу_номер, номери_пропусків, 2940>, <слу_ім'я, імена, Кузнєцов>, <слу_зарп, розміри_виплат, 35.000>, <слу_відд_номер, номери_відділів, 320>}.

• Тілом Br відношення r називається поточна множина кортежів tr.

Одне з можливих тіл відношення СЛУЖБОВЕЦЬ показано на рис.1.1.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

28

Відношення (сутність)

• Значенням Vr відношення r (або просто відношенням r, або відношенням-екземпляром) називається пара множин Hr і Br.

Одне з допустимих значень відношення СЛУЖБВЕЦЬ показано на рис. 1.1.1.

• У реляційній базі даних зберігаються відношення, значення яких змінюються в часі.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

29

Відношення (сутність)

• Ступенем ("арністю") заголовка відношення, кортежа, що відповідає цьому заголовку, тіла відношення і значення відношення є потужність заголовка відношення (кількість атрибутів).
• 1 атрибут - відношення унарне;
• 2 атрибути - відношення бінарне;
• 3 - тернарне;
• 4 - кватернарним;
• n - n-арне.
• Наприклад, ступінь відношення СЛУЖБОВЦІ дорівнює чотирьом, тобто воно є 4-арним (кватернарним).
• Кардинальність (або кардинальне число) відношення - кількість кортежів.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

30

Математичні відношення

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

31

Математичні відношення

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

32

Відношення (2 варіант)

​

• Relation (на думку Кодда) - це зв'язок між ключовим атрибутом (первинним ключем) і набором неключових атрибутів
• ! Це не зв'язок між таблицями

​

​

• Таким чином, термін «відношення» підкреслює математичну природу і структурованість даних у реляційних базах даних

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

33

Подання схем у РМ

Схема відношень: вираз

r(A₁ , ...,A_n ),

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

Приклад.

Схема стосунків СЛУЖБОВЕЦЬ:

СЛУЖБОВЕЦЬ(Слу_номер, Слу_ім'я, Слу_зарп, Слу_від_номер).

​

Реляційна база даних - набір зв’язаних нормалізованих відношень r, які розрізняються за іменами.

Схемою реляційної бази даних називається кінцевий набір схем відношень

R={r₁ , ..., r_p }.

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

34

Фундаментальні властивості відношень

Відношення має такі характеристики:

1. Кожен кортеж є унікальним, тобто дублікатів кортежів бути не може
2. Теоретично порядок проходження кортежів у відношенні не має значення (зміна порядку розташування рядків у таблиці не призводить до виникнення нового відношення). (Але практично цей порядок може істотно вплинути на ефективність доступу до них)
3. Порядок слідування атрибутів не має значення (перестановка атрибутів не породжує нової схеми)
4. Кожна комірка відношення містить тільки одне атомарне (неподільне) значення, тобто належить одному домену.
5. Кожен атрибут має унікальне ім'я.
6. Значення атрибута беруться з одного й того самого домену.
7. Відношення має ім'я, яке відрізняється від імен усіх інших відношень у реляційній схемі.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

35

Фундаментальні властивості відношень

1. Кожен кортеж є унікальним

Ця властивість реалізується за допомогою призначення первинного ключа

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

Для деяких відношень можлива наявність декількох потенційних ключів

Оголошення первинного і потенційних ключів дають СУБД можливість підтримувати цілісність бази даних навіть у разі спроб занесення в неї некоректних даних

Первинний ключ (primary key) - потенційний ключ, який обрано для унікальної ідентифікації кортежів усередині відношення.

Рекомендації до вибору первинного ключа з кількох потенційних:

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

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

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

36

�Фундаментальні властивості відношень�Мінімальність первинного ключа

​

​

• Службовець(Слу_номер, Слу_ім'я, Слу_зарп, Слу_від_номер)

​

​

​

• Службовець(Слу_номер, Слу_ім'я, Слу_зарп, Слу_від_номер)

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

37

Приклад 1.1

БП: Номер службовця унікальний у рамках усього підприємства

БП: Номер службовця унікальний у межах відділу підприємства

�Фундаментальні властивості відношень�Мінімальність первинного ключа

​

​

​

СТУДЕНТ (Номер_заліковки, ПІБ, Група, Деканат, Рейтинг)

Нехай як ПК обрано не мінімальний набір атрибутів.

Варіант 1. ПК: Номер_заліковки, Група

СТУДЕНТ (Номер_заліковки, ПІБ, Група, Деканат, Рейтинг)

Відношення-екземпляр

​

​

​

​

​

Варіант 2. ПК: Номер_заліковки, Група, Деканат

СТУДЕНТ (Номер_заліковки, ПІБ, Група, Деканат, Рейтинг)

Відношення-екземпляр

​

​

​

.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

38

Приклад 1.2

БП: Номер заліковки унікальний у межах усього університету

�Фундаментальні властивості відношень�Мінімальність первинного ключа

​

​

​

СТУДЕНТ (Номер_заліковки, ПІБ, Група, Деканат, Рейтинг)

Нехай як ПК обрано не мінімальний набір атрибутів.

Варіант 1. ПК: Номер_заліковки, Група

СТУДЕНТ (Номер_заліковки, ПІБ, Група, Деканат, Рейтинг)

Відношення-екземпляр

​

​

​

​

​

Варіант 2. ПК: Номер_заліковки, Група, Деканат

СТУДЕНТ (Номер_заліковки, ПІБ, Група, Деканат, Рейтинг)

Відношення-екземпляр

​

​

​

.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

39

Приклад 1.2

БП: Номер заліковки унікальний у межах усього університету

�Фундаментальні властивості відношень�Мінімальність первинного ключа

Варіант 1.

1.Номер проєкту унікальний у рамках підприємства, проєкт обов'язково ділиться на багато етапів

2. Номер етапу_проєкту унікальний у межах проєкту, етап належить тільки одному проєкту

Зміст_етапу (Номер_проекту, Номер_етапу, Дата_початку, Дата_закінчення, Опис_етапу)

Відношення-екземпляр

​

​

​

​

Варіант 2.

1.Номер проєкту унікальний у рамках підприємства, проєкт обов'язково ділиться на багато етапів

2. Номер етапу_проєкту унікальний у межах підприємства, етап належить тільки одному проєкту

Зміст_етапу (Номер_проекту, Номер_етапу, Дата_початку, Дата_закінчення, Опис_етапу)

Відношення-екземпляр

​

​

​

.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

40

Приклад 1.3

Зміст_етапу (Номер_проєкту, Номер_етапу, Дата_початку, Дата_закінчення, Описаний_етапу)

�Фундаментальні властивості відношень�Мінімальність первинного ключа

Завдання : визначити ПК

БП. 1. Авто береться не більше, ніж на добу

Варіант1 БП. 2. Певний клієнт певний автомобіль бере в 1 дату тільки 1 раз

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар)

Варіант2 БП. 2.Певний автомобіль в 1 дату можуть взяти тільки 1 раз

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар)

Варіант3 БП. 2. Певний клієнт в 1 дату може взяти авто тільки 1 раз

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар)

Варіант4 БП. 2. Певне авто можуть взяти тільки 1 раз

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар)

Варіант5 БП. 2. Певний клієнт може взяти авто тільки 1 раз

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар)

Варіант 6 БП. 2. Певне авто за певною ціною здається тільки 1 раз

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар)

Варіант7 БП. 2. Авто за певною ціною здається тільки 1 раз

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар)

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

41

Приклад 1.4

Оренда_авто (Номер_авто, Паспорт_клієнта, Дата_оренди, Оплата, Коментар

�Фундаментальні властивості відношень�Мінімальність первинного ключа

Варіант1

БП.

1.Студент може взяти конкретну книжку тільки 1 раз у певну дату, але в інший день може взяти повторно

​

Варіант2

БП.

1 Студент може звернутися до читальної зали (узяти книжку) лише 1 раз у визначену дату.

​

Варіант3

БП.

1.Студент може взяти конкретну книжку тільки 1 раз.

​

Завдання : визначити ПК

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

42

Приклад 1.5

Читальний_зал (Номер_заліковки, Шифр_книжки, Дата_видачі, Відгук_студента)

�Фундаментальні властивості відношень�Мінімальність первинного ключа

​

​

Завдання : визначити ПК

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

43

Приклад 1.6

Іспити (Номер_учень, Назва_предм, Номер_вчитель, Оцінка, Дата)

Фундаментальні властивості відносин

4. Кожна комірка відношення містить тільки одне атомарне значення

​

​

​

​

Рисунок 1.4 - Ненормалізоване відношення ВІДДІЛИ-СЛУЖБОВЦІ

​

​

​

Рисунок 1.5 - Нормалізований варіант відношення ВІДДІЛИ-СЛУЖБОВЦІ

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

44

Реляційна модель даних (РМД)

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

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

Загальна характеристика РМД

Згідно з трактуванням Дейта, реляційна модель складається з трьох частин, що описують різні аспекти реляційного підходу:

• структурної частини,
• маніпуляційної частини,
• цілісної частини.
• Під структурою даних РМД розуміють кінцевий набір нормалізованих n-арних відношень. У структурній частині моделі даних визначено поняття доменів, атрибутів, кортежів, заголовка, тіла і змінної відношення.
• У маніпуляційній частині РМД визначено два фундаментальні механізми маніпулювання реляційними БД - реляційну алгебру і реляційне обчислення:
• перший механізм базується здебільшого на класичній теорії множин (з деякими уточненнями і доповненнями);
• другий - на класичному логічному апараті обчислення предикатів першого порядку.

Основною функцією маніпуляційної частини реляційної моделі є забезпечення міри реляційності будь-якої конкретної мови реляційних БД.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

45

Реляційна модель даних (РМД)�Реляційна цілісність

• У цілісній частині РМД фіксуються дві базові вимоги цілісності, які мають підтримуватися в будь-якій реляційній СУБД:
• цілісність сутностей (відношень);
• цілісність за посиланнями (посилальна цілісність),

а також додаткове (корпоративні) обмеження цілісності.

​

Корпоративні обмеження цілісності - додаткові правила підтримки цілісності даних, що визначаються користувачами або адміністратором БД

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

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

46

Реляційна цілісність.�Цілісність сутностей

Вимога цілісності сутності (відношення):

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

​

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

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

47

Тризначна логіка

• При використанні NULL відбувається перехід до роботи з логікою вищого порядку

Якщо X - це значення деякого типу даних або NULL,

оп_а - будь-яка двомісна "арифметична" операція цього типу даних

оп_ср - операція порівняння значень цього типу ,

то за визначенням:

X оп_а NULL = NULL

NULL оп_a X = NULL

X оп_ср NULL = unknown

NULL оп_ср X = unknown

• Тут unknown - це третє значення логічного, або булевського, типу, що має такі властивості:

NOT unknown = unknown

true AND unknown = unknown

true OR unknown = true

false AND unknown = false

false OR unknown = unknown

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

48

Реляційна цілісність.�Посилальна цілісність

Цілісність за посиланнями �(посилальна цілісність, цілісність зовнішнього ключа) - це узгодженість між пов'язаними відносинами

Зовнішній ключ - атрибут або множина атрибутів усередині відношення, яке відповідає потенційному ключу деякого (можливо, того самого) відношення.

​

Вимога цілісності за посиланнями:

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

Визначення первинного і зовнішнього ключа являє собою визначення обмежень цілісності БД.

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

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

49

Реляційна цілісність.�Підтримка цілісності СУБД

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

При оновленні, видаленні кортежу з відношення, на яке веде посилання, існує 4 підходи:

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

​

Відділ (ІН_Відділ, Відділ_назва)

​

Службовець (ІН_Слубовець, Слу_ім'я, Слу_запр, Слу_відд_номер (ВК) )

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

50

Реляційна цілісність.�Підтримка цілісності СУБД

​

Відділ (ІН_Відділ, Відділ_назва)

​

Службовець (ІН_Слубовець, Слу_ім'я, Слу_запр, Слу_відд_номер (ВК) )

​

Відділ

​

​

​

​

Службовець

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

51

Реляційна цілісність.�Підтримка цілісності СУБД

​

Країна (ІН_країна, Назв_стр, Прапор_стр, Гімн_стр)

Регіон (ІН_регіон, Назв_регіон, ІН_країна (ВК))

Місто (ІН_місто, Назва_місто, населення, ІН_регіон (ВК))

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

52

Посилання

Загальна інформація:

• DB-Engines Ranking�https://db-engines.com/en/ranking
• Types of Databases: Relational vs. Columnar vs. Document vs. Graph vs. Vector vs. Key-value & more�https://www.youtube.com/watch?v=VfcRxtBKI54
• !!! Which Database Model to Choose?�https://www.youtube.com/watch?v=9mdadNspP_M
• Що таке Реляційна База Даних�https://www.youtube.com/watch?v=MlHC0CtjRhg
• SQL vs NoSQL�https://www.youtube.com/watch?v=YgNvOFSuSG4�https://www.youtube.com/watch?v=ruz-vK8IesE
• SQL vs NoSQL or MySQL vs MongoDB�https://www.youtube.com/watch?v=ZS_kXvOeQ5Y
• Sql vs tsql vs plsql�https://www.youtube.com/watch?v=xM51sGAo3Jg
• SIMPLY EXPLAINED: MYSQL vs POSTGRESQL vs SQL SERVER�https://www.youtube.com/watch?v=Q7i6zxHVj2Q

Ключі в БД:

• Database Keys Made Easy - Primary, Foreign, Candidate, Surrogate, & Many More�https://www.youtube.com/watch?v=8wUUMOKAK-c&list=PLNITTkCQVxeXryTQvY0JBWTyN9ynxxPH8&index=3

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

53