РЕЛЯЦІЙНА МОДЕЛЬ БАЗИ ДАНИХ: ЕЛЕМЕНТИ, ЯК ЦЕ ЗРОБИТИ, ПРИКЛАД - ТЕХНОЛОГІЯ - 2025

Модель реляційної бази даних - це метод структурування даних за допомогою взаємозв'язків, використовуючи сітчасті структури, що складаються зі стовпців і рядків. Це концептуальний принцип реляційних баз даних. Це було запропоновано Едгаром Ф. Коддом у 1969 році.

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

Джерело: pixabay.com

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

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

Управління базами даних

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

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

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

Більшість реляційних баз даних використовують мову SQL для запиту та визначення даних. В даний час існує багато систем управління реляційними базами даних або RDBMS (система реляційної бази даних), такі як Oracle, IBM DB2 та Microsoft SQL Server.

Особливості та елементи

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

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

- Усі значення є скалярами. Тобто, у будь-якому заданому положенні рядка / стовпця в таблиці є лише одне значення.

-Елементи

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

Кортеж

Кожен рядок даних є кортежем, також відомим як запис. Кожен ряд є n-кортежем, але "n-" взагалі відкидається.

Стовпчик

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

Ключ

У кожному рядку є один або кілька стовпців, які називаються ключем таблиці. Це об'єднане значення є унікальним для всіх рядків таблиці. За допомогою цього ключа кожен кортеж буде однозначно ідентифікований. Тобто ключ не можна дублювати. Він називається первинним ключем.

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

-Правила цілісності

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

Ключова цілісність

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

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

Референтна цілісність

Кожне значення зовнішнього ключа повинно відповідати значенню первинного ключа посилається або первинної таблиці.

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

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

Як зробити реляційну модель?

-Збирати дані

Необхідні дані повинні бути зібрані для зберігання в базі даних. Ці дані поділяються на різні таблиці.

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

-Визначте первинні ключі

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

-Створюйте зв’язки між таблицями

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

Найважливішим аспектом при розробці реляційної бази даних є виявлення зв’язків між таблицями. Типи відносин:

Один до багатьох

У базі даних «Класового списку» вчитель може викладати нульові або більше класів, тоді як клас викладає один вчитель. Цей тип відносин відомий як один на багато.

Цей взаємозв'язок неможливо представити в одній таблиці. У базі даних «Список занять» ви можете мати таблицю під назвою «Вчителі», де зберігається інформація про вчителів.

Щоб зберігати класи, які викладав кожен викладач, ви можете створити додаткові стовпці, але ви зіткнетеся з проблемою: скільки стовпців створити.

З іншого боку, якщо у вас є таблиця під назвою Класи, яка зберігає інформацію про клас, ви можете створити додаткові стовпці для зберігання інформації про вчителя.

Однак, оскільки вчитель може викладати багато класів, його дані дублюються через багато рядків таблиці Класи.

Оформити дві таблиці

Тому вам потрібно розробити дві таблиці: таблицю Класів для зберігання інформації про класи, причому Class_Id є основним ключем, і Таблиця вчителів для зберігання інформації про вчителів, причому Teacher_Id є основним ключем.

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

Стовпець Master_Id в таблиці Класи відомий як зовнішній ключ або вторинний ключ.

Для кожного значення Master_Id у таблиці Master може бути нульове або більше рядків у таблиці Classes. Для кожного значення Class_Id у таблиці Класи є лише один рядок у таблиці Вчителі.

Багато до багатьох

У базі даних "Продаж товару" замовлення клієнта може містити кілька продуктів, а товар може з'являтися у кількох замовленнях. Цей тип відносин відомий як багато до багатьох.

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

З іншого боку, таблиця Замовлення містить замовлення клієнта, в якості основного ключа - замовлення ID.

Ви не можете зберігати замовлені товари в таблиці Замовлення, оскільки ви не знаєте, скільки стовпців зарезервувати для продуктів. З тієї ж причини замовлення не можуть зберігатися в таблиці "Продукти".

Для підтримки взаємозв'язку «багато-багато» потрібно створити третю таблицю, відому як таблиця об’єднання (OrderDetails), де кожен рядок являє собою елемент у певному порядку.

Для таблиці OrderDetails первинний ключ складається з двох стовпців: orderID та productID, що однозначно ідентифікують кожен рядок.

Стовпці orderID та productID в таблиці OrderDetails використовуються для посилання на таблиці Замовлення та продукти. Тому вони також є зовнішніми ключами в таблиці OrderDetails.

Один за одним

У базі даних "Продаж продукції" продукт може мати додаткову інформацію, таку як додатковий опис та його зображення. Якщо зберігати його всередині таблиці продуктів, це створить багато порожніх пробілів.

Тому може бути створена інша таблиця (ProductExtras) для зберігання необов'язкових даних. Буде створено лише один запис для продуктів із необов'язковими даними.

Дві таблиці, Продукти та ProductExtras, мають відношення один до одного. Для кожного рядка в таблиці Продукти міститься максимум один рядок у таблиці ProductExtras. Один і той же продуктID повинен використовуватися в якості основного ключа для обох таблиць.

Перевага

Структурна незалежність

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

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

Концептуальна простота

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

Оскільки модель реляційної бази даних звільняє дизайнера від деталей фізичного зберігання даних, дизайнери можуть орієнтуватися на логічний вигляд бази даних.

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

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

Ємність спеціального запиту

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

Мова запитів моделі реляційної бази даних, яка називається структурованою мовою запитів, або SQL, робить реальні запити ad hoc. SQL - мова четвертого покоління (4GL).

4GL дозволяє користувачеві вказати, що слід робити, не вказуючи, як це робити. Таким чином, за допомогою SQL користувачі можуть вказувати, яку інформацію вони хочуть, і залишати деталі, як отримати інформацію до бази даних.

Недоліки

Витрати на обладнання

Модель реляційної бази даних приховує складності її реалізації та деталі фізичного зберігання даних користувача.

Для цього реляційним системам баз даних потрібні комп'ютери з більш потужними апаратними засобами та пристроями зберігання даних.

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

Простота дизайну може призвести до поганого дизайну

Реляційну базу даних легко спроектувати та використовувати. Користувачам не потрібно знати складні деталі фізичного зберігання даних. Їм не потрібно знати, як дані насправді зберігаються для доступу до них.

Така простота проектування та використання може призвести до розробки та впровадження погано розроблених систем управління базами даних. Оскільки база даних ефективна, ці неефективність проектування не виявиться, коли база даних створена і коли є лише невелика кількість даних.

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

Явище «інформаційних островів»

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

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

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

Приклад

Припустимо, база даних, що складається з таблиць "Постачальники", "Запчастини" та "Відвантаження". Структура таблиць і деяких зразків записів така:

Кожен рядок у таблиці Постачальники ідентифікується унікальним номером постачальника (SNo), однозначно ідентифікуючи кожен рядок таблиці. Так само кожна частина має унікальний номер деталі (PNo).

Крім того, не може бути більше однієї поставки для даної комбінації постачальника / частини в таблиці відправлень, оскільки ця комбінація є первинним ключем відправлень, який служить об'єднаною таблицею, оскільки це відносини «багато-багато».

Взаємозв'язок між таблицями запчастин та відправлень задається спільним полем PNo (номер деталі), а взаємозв'язок між постачальниками та відправленнями виникає, якщо спільне поле SNo (номер постачальника).

Аналізуючи таблицю відправлень, можна отримати інформацію, що від постачальників Suneet і Ankit надсилається 500 горіхів, по 250 кожен.

Так само 1100 болтів було поставлено від трьох різних постачальників. 500 блакитних гвинтів було поставлено від постачальника Suneet. Червоних гвинтів немає.

Список літератури

1. Вікіпедія, безкоштовна енциклопедія (2019). Реляційна модель. Взято з: en.wikipedia.org.
2. Техопедія (2019). Реляційна модель. Взяті з: plasmapedia.com.
3. Дінеш Тхакур (2019). Реляційна модель. Примітки до електронного комп’ютера. Взято з: ecomputernotes.com.
4. Geeks для Geeks (2019). Реляційна модель. Взято з: geeksforgeeks.org.
5. Наньянський технологічний університет (2019). Швидкий посібник з реляційного дизайну баз даних. Взято з: ntu.edu.sg.
6. Адріан Ватт (2019). Глава 7 Модель реляційних даних. BC Відкриті підручники. Взято з: opentextbc.ca.
7. Топпр (2019). Реляційні бази даних та схеми. Взято з: toppr.com.