Relational data model COPYRIGHT DISCLAIMER: Presentation aggregates information from multiple open-access resources. Author does not claim for copyright.

1. Лекція 05: Реляційна модель
даних
Lecture 05: Relational data model

2. Реляційна модель даних / Relational
data model
Реляційна модель даних є основною моделлю даних,
яка широко використовується в усьому світі для
зберігання та обробки даних. Ця модель проста і
має всі властивості та можливості, необхідні для
обробки даних з ефективністю зберігання.
Relational data model is the primary data model, which is
used widely around the world for data storage and
processing. This model is simple and it has all the
properties and capabilities required to process data
with storage efficiency.
161

3. Реляційні СУБД / Relational DBMS
RDBMS
MySQL
Performance
Availability
Open-
Source/Free
MS SQL Server
Performance
Reliability
Expensive
Oracle Database
Performance
Concurrency
Very
Expensive
MS Access
Small-scale
Management
Ease
Inexpensive
162
Common
Critical factors

4. MySQL
MySQL – це база даних з відкритим вихідним кодом, розроблена
шведською компанією MySQL AB.
MySQL підтримує багато різних платформ, включаючи Microsoft Windows,
основні дистрибутиви Linux, UNIX і Mac OS.
MySQL має безкоштовні та платні версії залежно від його використання
(не комерційні або комерційні) та функцій. MySQL поставляється з
дуже швидким багатопотоковим, багатокористувацьким і надійним
сервером баз даних SQL.
MySQL is an open source SQL database, which is developed by a Swedish
company – MySQL AB.
MySQL is supporting many different platforms including Microsoft Windows,
the major Linux distributions, UNIX, and Mac OS.
MySQL has free and paid versions, depending on its usage (non-
commercial/commercial) and features. MySQL comes with a very fast,
multi-threaded, multi-user and robust SQL database server.
163

5. MS SQL Server
MS SQL Server – це система управління реляційними
базами даних, розроблена компанією Microsoft Inc.
Окрім високої продуктивності та доступності, надає
можливості щодо бізнес-аналітики (SQL Server
Analytics Services) та хмарних обчислень (Azure SQL
Database).
MS SQL Server is a Relational Database Management
System developed by Microsoft Inc. Besides high
performance and availability it provides Business
Intelligence (SQL Server Analytics Services) and Cloud
Computing features (Azure SQL Database).
164

6. Oracle Database
Це дуже велика багатокористувацька система управління базами
даних. Oracle Database – це реляційна система управління
базами даних, розроблена корпорацією Oracle.
Це відмінний вибір сервера баз даних для клієнтських або
серверних обчислень. Oracle Database підтримує всі основні
операційні системи для клієнтів і серверів.
It is a very large multi-user based database management system.
Oracle Database is a relational database management system
developed by 'Oracle Corporation'.
It is an excellent database server choice for client/server computing.
Oracle Database supports all major operating systems for both
clients and servers.
165

7. MS Access
Це один з найпопулярніших продуктів Microsoft. Microsoft Access – це
СУБД початкового рівня. База даних MS Access не тільки недороге, але
потужне рішення для малих проектів.
MS Access використовує певний діалект мови SQL (іноді називається Jet
SQL).
MS Access постачається з професійним виданням пакета MS Office. MS
Access має простий у використанні інтуїтивно зрозумілий графічний
інтерфейс.
This is one of the most popular Microsoft products. Microsoft Access is an
entry-level database management software. MS Access database is not
only inexpensive but also a powerful database for small-scale projects.
MS Access uses a specific SQL language dialect (sometimes referred to as Jet
SQL).
MS Access comes with the professional edition of MS Office package. MS
Access has easy-to-use intuitive graphical interface.
166

8. RDBMS Market Share 2018
167
https://terraencounters.wordpress.com/2018/02/02/learning-
relational-databases/

9. Подібність синтаксису SQL / Similarity
of SQL syntax
168
https://support.dbconvert.com/hc/en-us/articles/201359981-Views-and-Queries-translation-
between-different-databases-

10. Основні поняття / Concepts
• Таблиці – у реляційній моделі даних
відношення зберігаються у форматі таблиць.
Цей формат зберігає відношення між
суб'єктами. У таблиці є рядки та стовпці, де
рядки представляють записи, а стовпці –
атрибути.
• Tables − In relational data model, relations are
saved in the format of Tables. This format stores
the relation among entities. A table has rows and
columns, where rows represents records and
columns represent the attributes.
169

11. Таблиці / Tables
170

12. • Кортеж – окремий рядок таблиці, що містить
єдиний запис для цього відношення, називається
кортежем.
• Tuple − A single row of a table, which contains a single
record for that relation is called a tuple.
• Екземпляр відношення – кінцевий набір кортежів у
реляційній базі даних представляє екземпляр
відношення. Екземпляри відношення не мають
дублікатів кортежів.
• Relation instance − A finite set of tuples in the
relational database system represents relation
instance. Relation instances do not have duplicate
tuples.
171

13. Кортежі та екземпляр відношення /
Tuple and relation instance
172
Relation instance
Tuple

14. • Схема відношення – схема відношення описує ім'я
відношення (назву таблиці), атрибути та їхні імена.
• Relation schema − A relation schema describes the
relation name (table name), attributes, and their
names.
• Ключ відношення – кожен рядок має один або
декілька атрибутів, відомих як ключ відношення,
який може однозначно ідентифікувати рядок у
відношенні (таблиці).
• Relation key − Each row has one or more attributes,
known as relation key, which can identify the row in
the relation (table) uniquely.
173

15. Схема та ключ відношення / Relation
schema and key
174
Key
Relation schema

16. • Область визначення атрибутів – кожен
атрибут має певну заздалегідь визначену
область визначення, відому як домен
атрибута.
• Attribute domain − Every attribute has some
pre-defined value scope, known as attribute
domain.
175

17. Правила Кодда / Codd’s rules
Д-р Едгар Кодд, після тривалих досліджень щодо
реляційної моделі систем баз даних, висунув
дванадцять власних правил, які, на його думку,
повинна виконувати база даних для того, щоб
вважатися справжньою реляційною базою
даних.
Dr Edgar Codd, after his extensive research on the
Relational Model of database systems, came up
with twelve rules of his own, which according to
him, a database must obey in order to be
regarded as a true relational database.
176

18. Ці правила можуть бути застосовані до будь-
якої системи бази даних, яка управляє
збереженими даними, використовуючи
лише свої реляційні можливості. Це
основне правило, яке є основою для всіх
інших правил.
These rules can be applied on any database
system that manages stored data using only its
relational capabilities. This is a foundation
rule, which acts as a base for all the other
rules.
177

19. Правило 1: Інформаційне правило /
Rule 1: Information
Дані, що зберігаються в базі даних, які можуть
бути користувацькими даними або
метаданими, повинні бути значенням
деякої комірки таблиці. Все в базі даних
повинно зберігатися у форматі таблиці.
The data stored in a database, may it be user
data or metadata, must be a value of some
table cell. Everything in a database must be
stored in a table format.
178

20. 179

21. 180

22. Правило 2: Гарантований доступ /
Rule 2: Guaranteed Access
Для кожного елемента даних (значення)
гарантований логічний доступ за комбінацією
імені таблиці, первинного ключа (значення
рядка) та імені атрибута (значення стовпця).
Інших засобів, таких як покажчики, не можна
використовувати для доступу до даних.
Every single data element (value) is guaranteed to
be accessible logically with a combination of
table-name, primary-key (row value), and
attribute-name (column value). No other means,
such as pointers, can be used to access data.
181

23. 182

24. Правило 3: Систематична обробка NULL /
Rule 3: Systematic Treatment of NULL Values
Ставлення до значень NULL в базі даних повинне
бути систематичним та однорідним. Це дуже
важливе правило, оскільки значення NULL
може бути інтерпретовано як: дані відсутні,
дані невідомі або дані не можуть бути
застосовні.
The NULL values in a database must be given a
systematic and uniform treatment. This is a very
important rule because a NULL can be
interpreted as one the following − data is missing,
data is not known, or data is not applicable.
183

25. Правило 4: Активний онлайн-каталог
/ Rule 4: Active Online Catalog
Опис структури всієї бази даних має зберігатися в
онлайн-каталозі, відомому як словник даних, до
якого можуть отримати доступ авторизовані
користувачі. Користувачі можуть використовувати ту
ж мову запитів для доступу до каталогу, який вони
використовують для доступу до самої бази даних.
The structure description of the entire database must be
stored in an online catalog, known as data dictionary,
which can be accessed by authorized users. Users can
use the same query language to access the catalog
which they use to access the database itself.
184

26. 185
SQL query language
statements

27. Правило 5: Повнота підмножини мови /
Rule 5: Comprehensive Data Sub-Language
Доступ до БД можна отримати лише за допомогою мови,
що має лінійний синтаксис, що підтримує визначення
даних, маніпулювання даними та операції з управління
транзакціями. Цю мову можна використовувати
безпосередньо або за допомогою певної програми.
Якщо база даних дозволяє отримати доступ до даних
без допомоги цієї мови, то це вважається порушенням.
A database can only be accessed using a language having
linear syntax that supports data definition, data
manipulation, and transaction management operations.
This language can be used directly or by means of some
application. If the database allows access to data without
any help of this language, then it is considered as a
violation.
186

28. 187
WHEN?
WHEN?

29. Правило 6: Оновлення представлення /
Rule 6: View Updating
Всі представлення бази даних, які теоретично
можуть бути оновлені, також повинні бути
придатні до оновлення системою.
All the views of a database, which can
theoretically be updated, must also be
updatable by the system.
188

30. Правило 7: Вставка, оновлення та видалення
високого рівня / Rule 7: High-Level Insert,
Update, and Delete
База даних повинна підтримувати вставку,
оновлення та видалення високого рівня. Це не
повинно обмежуватися одним рядком, тобто
вона також повинна підтримувати операції
об'єднання, перетину та доповнення для
отримання множини записів даних.
A database must support high-level insertion,
updation, and deletion. This must not be limited
to a single row, that is, it must also support union,
intersection and minus operations to yield sets of
data records.
189

31. 190

32. Правило 8: Фізична незалежність даних /
Rule 8: Physical Data Independence
Дані, що зберігаються в базі даних, повинні бути
незалежними від програм, які мають доступ до
бази даних. Будь-які зміни в фізичній структурі
бази даних не повинні мати ніякого впливу на
те, як зовнішні програми отримують доступ до
даних.
The data stored in a database must be independent
of the applications that access the database. Any
change in the physical structure of a database
must not have any impact on how the data is
being accessed by external applications.
191

33. 192
http://lazysupply.co/schema-database-logical-architecture-diagram.html

34. Правило 9: Логічна незалежність даних /
Rule 9: Logical Data Independence
Логічні дані в базі даних повинні бути незалежними від
перегляду користувача (програми). Будь-яка зміна
логічних даних не повинна впливати на програми, що їх
використовують. Наприклад, якщо дві таблиці
об'єднуються або одна поділяється на дві різні таблиці,
користувацькі застосунки не повинні зазнавати впливу або
змін. Це одне з найважчих правил щодо виконання.
The logical data in a database must be independent of its user’s
view (application). Any change in logical data must not affect
the applications using it. For example, if two tables are
merged or one is split into two different tables, there should
be no impact or change on the user application. This is one of
the most difficult rule to apply.
193

35. 194
http://www.mysqltutorial.org/introduction-to-sql-stored-procedures.aspx

36. Правило 10: Незалежність контролю
цілісності / Rule 10: Integrity Independence
База даних повинна бути незалежною від програми, яка її
використовує. Усі її обмеження цілісності можуть бути
незалежно модифіковані без необхідності будь-яких змін у
додатку. Це правило створює базу даних, незалежну від
зовнішньої програми та її інтерфейсу.
A database must be independent of the application that uses it.
All its integrity constraints can be independently modified
without the need of any change in the application. This rule
makes a database independent of the front-end application
and its interface.
195

37. Правило 11: Незалежність від розміщення /
Rule 11: Distribution Independence
Кінцевий користувач не повинен мати змоги бачити,
що дані розподіляються по різних місцях.
Користувачам завжди потрібно створити враження,
що дані розміщуються лише в одному місці. Це
правило розглядається як основа розподілених
систем баз даних.
The end-user must not be able to see that the data is
distributed over various locations. Users should always
get the impression that the data is located at one site
only. This rule has been regarded as the foundation of
distributed database systems.
196

38. 197
https://en.wikipedia.org/wiki/Data_integration

39. Правило 12: Узгодженість мовних
рівнів / Rule 12: Non-Subversion
Якщо в системі є інтерфейс, що забезпечує
доступ до записів низького рівня, то
інтерфейс не повинен мати змоги зламати
систему та обходити обмеження безпеки та
цілісності.
If a system has an interface that provides access
to low-level records, then the interface must
not be able to subvert the system and bypass
security and integrity constraints.
198

40. Обмеження / Constraints
Для кожного відношення існують деякі умови, які повинні для
нього виконуватися. Ці умови називаються реляційними
обмеженнями цілісності. Існує три основних обмеження
цілісності:
• ключів;
• доменів;
• посилань.
Every relation has some conditions that must hold for it to be a valid
relation. These conditions are called Relational Integrity
Constraints. There are three main integrity constraints:
• Key constraints;
• Domain constraints;
• Referential integrity constraints.
199

41. Обмеження ключів / Key constraints
У відношенні повинна бути принаймні одна
мінімальна підмножина атрибутів, яка може
однозначно ідентифікувати кортеж. Ця мінімальна
підмножина атрибутів називається ключем для
цього відношення. Якщо існує декілька таких
мінімальних підмножин, вони називаються
потенційними ключами.
There must be at least one minimal subset of attributes in
the relation, which can identify a tuple uniquely. This
minimal subset of attributes is called key for that
relation. If there are more than one such minimal
subsets, these are called candidate keys.
200

42. Обмеження ключів визначають, що:
• у відношенні з ключовим атрибутом, два кортежі не
можуть мати ідентичні значення для ключових
атрибутів.
• ключовий атрибут не може мати значення NULL.
Обмеження ключів також називаються обмеженнями
сутності.
Key constraints force that:
• in a relation with a key attribute, no two tuples can
have identical values for key attributes.
• a key attribute can not have NULL values.
Key constraints are also referred to as Entity Constraints.
201

43. Обмеження доменів / Domain
constraints
В реальності атрибути мають певні значення. Наприклад,
вік може бути лише позитивним цілим числом. Ті самі
обмеження спробували застосувати до атрибутів
відношення. Кожен атрибут повинен мати певний
діапазон значень. Наприклад, вік не може бути менше
нуля, а номери телефонів не можуть містити цифри за
межами 0-9.
Attributes have specific values in real-world scenario. For
example, age can only be a positive integer. The same
constraints have been tried to employ on the attributes of a
relation. Every attribute is bound to have a specific range of
values. For example, age cannot be less than zero and
telephone numbers cannot contain a digit outside 0-9.
202

44. Обмеження цілісності посилань /
Referential integrity constraints
Обмеження цілісності посилань оперують з концепцією зовнішніх
ключів. Зовнішній ключ є ключовим атрибутом відношення, на
який можна посилатися в іншому відношенні.
Обмеження цілісності посилань вказує, що якщо відношення
посилається на ключовий атрибут іншого або того ж самого
відношення, то цей ключовий атрибут повинен існувати.
Referential integrity constraints work on the concept of Foreign Keys.
A foreign key is a key attribute of a relation that can be referred in
other relation.
Referential integrity constraint states that if a relation refers to a key
attribute of a different or same relation, then that key element
must exist.
203

45. 204
1) Double-click on
the relation
2) Check the first
box to enforce
referential integrity

46. Реляційна алгебра / Relational
algebra
Реляційна алгебра є процедурною мовою запитів, яка приймає
екземпляри відношень та повертає екземпляри відношень.
Вона використовує оператори для виконання запитів. Оператор
може бути як унарним, так і бінарним. Вони приймають
відношення та повертають також відношення. Реляційна
алгебра виконується рекурсивно на відношенні, а проміжні
результати також розглядаються як відношення.
Relational algebra is a procedural query language, which takes
instances of relations as input and yields instances of relations as
output. It uses operators to perform queries. An operator can be
either unary or binary. They accept relations as their input and
yield relations as their output. Relational algebra is performed
recursively on a relation and intermediate results are also
considered relations.
205

47. Операція вибору / Select operation
Він вибирає кортежі, які задовольняють даному предикату, з
відношення.
Позначення – σp(r).
Де σ означає предикат вибору, а r – відношення. p – формула
логіки препозиції, яка може використовувати з’єднувачі, такі як
AND, OR, та NOT. Ці умови можуть використовувати реляційні
оператори, такі як: =, ≠, ≥, <,>, ≤.
It selects tuples that satisfy the given predicate from a relation.
Notation − σp(r).
Where σ stands for selection predicate and r stands for relation. p is
prepositional logic formula which may use connectors like AND, OR,
and NOT. These terms may use relational operators like: =, ≠, ≥, < ,
>, ≤.
206

48. 207
Book Pages Type
SQL Cookbook 218 Technical
Harry Potter and bla-bla-bla 411 Novel
LotR 593 Fantasy
C in Examples 299 Technical
The Walking Dead #39 18 Comics
r = ‘literature’
σp = Pages < 300 AND Type = ‘Comics’ (r = ‘literature’)
RESULT?

49. Операція проекції / Project operation
Вона проектує стовпчик(и), що задовольняє заданому
предикату.
Позначення – ∏A1, A2, …, An (r).
Де A1, A2, …, An – назви атрибутів відношення r.
Дубльовані рядки автоматично виключаються, оскільки
відношення є множиною.
It projects column(s) that satisfy a given predicate.
Notation − ∏A1, A2, An (r).
Where A1, A2, …, An are attribute names of relation r.
Duplicate rows are automatically eliminated, as relation is a
set.
208

50. 209
Book Pages Type
SQL Cookbook 218 Technical
Harry Potter and bla-bla-bla 411 Novel
LotR 593 Fantasy
C in Examples 299 Technical
The Walking Dead #39 18 Comics
r = ‘literature’
∏Book, Pages (r = ‘literature’)
RESULT?

51. Операція об’єднання / Union
operation
Вона виконує об’єднання двох відношень і визначається як:
r ∪ s = {t | t ∈ r or t ∈ s}.
Де r та s – це відношення бази даних або результуючі відношення
(тимчасові відношення).
Для того, щоб операція об’єднання була дійсною, r та s повинні мати
однакову кількість атрибутів; домени атрибутів повинні бути
сумісними; дубльовані кортежі автоматично виключаються.
It performs binary union between two given relations and is defined as:
r ∪ s = {t | t ∈ r or t ∈ s}.
Where r and s are either database relations or relation result set (temporary
relation).
For a union operation to be valid, r and s must have the same number of
attributes; attribute domains must be compatible; duplicate tuples are
automatically eliminated. 210

52. 211
Book Pages Type
SQL Cookbook 218 Technical
C in Examples 299 Technical
r1 = ‘technical’
r1 ∪ r2 = {t | t ∈ r1 or t ∈ r2}
RESULT?
Book Pages Type
Harry Potter and bla-bla-bla 411 Novel
LotR 593 Fantasy
The Walking Dead #39 18 Comics
r2 = ‘other’

53. Різниця множин / Set difference
Результатом операції різниці множин є кортежі, які
присутні в одному відношенні, але не в другому
відношенні.
Позначення – r – s.
Знаходить всі кортежі, які присутні в r, але не в s.
The result of set difference operation is tuples, which are
present in one relation but are not in the second
relation.
Notation − r − s.
Finds all the tuples that are present in r but not in s.
212

54. Декартів добуток / Cartesian product
Поєднує інформацію з двох різних відношень в одне.
Позначення – r Χ s.
Де r та s – відношення, і їх результат буде визначений
як:
r Χ s = {q t | q ∈ r and t ∈ s}.
Combines information of two different relations into one.
Notation − r Χ s.
Where r and s are relations and their output will be
defined as:
r Χ s = {q t | q ∈ r and t ∈ s}.
213

55. 214
Book Pages
SQL Cookbook 218
LotR 593
r1 = ‘books’
r1 X r2 = {q t | q ∈ r1 and t ∈ r2}
RESULT?
r2 = ‘book types’
Book Type
SQL Cookbook Technical
LotR Fantasy

56. Операція перейменування / Rename
operation
Результати реляційної алгебри - це також відношення,
але без назви. Операція перейменування дозволяє
нам перейменувати вихідне відношення.
Позначення – ρx (E).
Де результат виразу E зберігається з назвою х.
The results of relational algebra are also relations but
without any name. The rename operation allows us to
rename the output relation.
Notation − ρx (E).
Where the result of expression E is saved with name of x.
215

57. Реляційне обчислення / Relational
Calculus
На відміну від реляційної алгебри, реляційне
обчислення є не процедурною мовою
запитів, тобто вона визначає, що робити,
але ніколи не пояснює, як це зробити.
In contrast to Relational Algebra, Relational
Calculus is a non-procedural query language,
that is, it tells what to do but never explains
how to do it.
216

58. Реляційне обчислення кортежів /
Tuple Relational Calculus (TRC)
Фільтрація кортежів за змінними
Filtering variable ranges over tuples
{ T | Condition }
Повертає усі кортежі Т, що задовольняють умові
Returns all tuples T that satisfies a condition
{ T.name | Supplier(T) AND T.id = ‘3’ }
Яким буде результат?
What will be the output?
217

59. Реляційне обчислення доменів /
Domain Relational Calculus (DRC)
Змінні фільтрації використовують домен атрибутів замість усіх значень
кортежу (як це реалізовано в TRC)
In DRC, the filtering variable uses the domain of attributes instead of entire
tuple values (as done in TRC)
{ a1, a2, …, an | P (a1, a2, …, an) }
Де a1, a2, …, an – атрибути, P – формула, заснована на атрибутах.
Where a1, a2, …, an are attributes and P stands for formulae built by inner
attributes.
{ <name, address> | ∈ Supplier ∧ id = ‘3’ }
Яким буде результат?
What will be the output?
218