Реляційні СУБД: огляд бази даних, приклади

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

Історія розробки

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

До 1960-м років зібралася величезна кількість даних, що зберігаються на нових мэйнфрейм-комп’ютерах світу, багато з яких були комп’ютерами IBM System 360. Це стало проблемою для подальшого розвитку цифрових технологій. Розрахунки на мэйнфреймах були дорогими, часто коштували сотні доларів за хвилину. Істотною частиною цих витрат була складність, пов’язана з управлінням базою даних (БД).

У 1973 році лабораторія Сан-Хосе, нині Almaden, почала розробляти програму під назвою System R (реляционый) з метою застосувати теорію відносин з допомогою так званої промислової реалізації. Це якість стало визначальним, щоб визначити, які СУБД називаються реляційними. В результаті реалізації цього проекту було винайдено нова революційна система зберігання, що стала основою успіху IBM.

Дон Чемберлін і Рей Бойс винайшли SQL для структурованих даних, що сьогодні найбільш широко застосовуються. Патриція Селингер розробила оптимізатор на основі витрат, що робить роботу з реляційними БД більш рентабельною та ефективною. А Раймон Лорі винайшов компілятор, що зберігає процедури запитів до БД для майбутнього використання.

У 1983 році IBM представила друге сімейство реляційних СУБД DB2 з метою управління даними. Сьогодні DB2 раніше виробляють мільярди транзакцій кожен день, будучи самим успішним програмним продуктом IBM. За словами Арвинда Крішни, генерального менеджера IBM Information Management, DB2 продовжує залишатися лідером в області інноваційного для реляційних баз даних (РБД).

Доктор Кодд, відомий своїм колегам як Тед, був удостоєний звання стипендіата IBM у 1976 році, а в 1981 році Асоціація обчислювальної техніки вручила йому премію Тюрінга за внесок, внесений в розробку РБД.

Принципи створення

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

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

Терміни та типи

Реляційні СУБД включають таблиці, що містять рядки і стовпці. При створенні РБД визначають область можливих значень у стовпці даних і додаткові обмеження, які можуть застосовуватися до цього значення. Наприклад, домен клієнтів може дозволити до 10 можливих імен, але в одній таблиці можна обмежити його вказівкою лише трьох із цих імен клієнтів. Два обмеження стосуються цілісності даних, а також первинного та зовнішнього ключів. Цілісність об’єкта гарантує, що первинний унікальний ключ і що значення не дорівнює нулю. Посилальна цілісність вимагає, щоб кожне значення у стовпці зовнішнього ключа було знайдено в первинному ключі таблиці, з якої воно сталося.

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

Альтернативні структури

База даних NoSQL – це альтернатива РБД, яка особливо корисна для роботи з великими наборами розподілених даних.

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

Приклади реляційних СУБД

SQLite – це популярна БД SQL з відкритим вихідним кодом. Може зберігати всю БД в одному файлі. Самим значним перевагою, яке вона забезпечує, є те, що всі дані можуть зберігатися локально без підключення до сервера. SQLite стала популярною для БД в мобільних телефонах, КПК, MP3-плеєрах, телевізійних приставках і інших електронних гаджетів.

MySQL – ще одна популярна реляційна модель баз даних SQL з відкритим вихідним кодом. Зазвичай вона застосовується у веб-додатках і часто доступна з допомогою PHP. Головні її переваги – простота використання, цінова доступність, надійність. Деякі з недоліків виявляються в тому, що при масштабуванні вона страждає від низької продуктивності, розробка із застосуванням відкритого вихідного коду відстає з тих пір, як Oracle встановив контроль над MySQL і не включає в себе деякі додаткові функції.

PostgreSQL – це реляційна модель даних СУБД SQL з використанням відкритого вихідного коду, яка не контролюється будь-якої корпорацією. Зазвичай її використовують для розробки веб-додатків. PostgreSQL – проста, надійна і бюджетна програма з великим співтовариством розробників. Має додаткові функції у вигляді підтримки зовнішнього ключа, не вимагаючи складної установки. Головний її недолік – вона працює повільніше, ніж інші БД, такі як MySQL. Вона також менш популярна, ніж MySQL, що ускладнює доступ хостів або постачальників послуг, які пропонують керовані примірники PostgreSQL.

Система управління RDBMS

RDBMS – система управління реляційними базами даних, розроблена EF Codd від IBM і здатна створювати, змінювати і адмініструвати РБД. Багато існуючих на сьогодні БД є продовженням цієї вікової моделі. Збережені дані обробляються із застосуванням реляційних операторів в СУРБД.

SQL використовують в якості мови запитів баз даних – це логічна група даних. Вона містить набір пов’язаних табличних та індексних просторів. Як правило, БД містить всі дані, пов’язані з одним додатком або пов’язаної з групою. Наприклад, може бути БД заробітної плати або інвентаризації.

Відмінності RDBMS від звичайної СУБД

СУБД зберігає дані у вигляді файлів, тоді як RDBMS зберігає дані у вигляді таблиці. СУБД дозволяє нормалізувати дані, а RDBMS підтримує зв’язок між даними, що зберігаються в її таблицях. Звичайна СУБД не надає посилання. Вона просто зберігає дані своїх файлів. Структурований підхід RDBMS підтримує розподілену РБД на відміну від звичайної системи управління базами даних. СУБД орієнтована на широкий спектр застосувань, її особливості дозволяють використовувати її у всьому світі.

Особливості RDBMS:

  • Загальна реалізація стовпця, а також багатокористувацький доступ включені в функції RDBMS.
  • Потенціал цієї моделі реляційних СУБД був більш ніж виправданий сучасними можливостями застосування.
  • Краща безпека забезпечується створенням таблиць.
  • Деякі таблиці можуть бути захищені системою.
  • Користувачі можуть встановлювати бар’єри доступу до контенту. Це дуже корисно в компаніях, де менеджер може вирішити дані, які надаються співробітникам і клієнтам. Таким чином, можна налаштувати індивідуальний рівень захисту даних.
  • Забезпечення майбутніх вимог, оскільки нові дані можуть бути легко додані до існуючих таблиць і узгоджені з раніше доступним вмістом. Це функція, якої немає ні в одній БД плоских файлів.
  • Структурна таблиця

    Таблиця – це логічна структура, яка складається з рядків і стовпців. Рядки не мають фіксованого порядку, тому, якщо отримано дані, може знадобитися відсортувати їх. Порядок стовпців вказується при створенні таблиці адміністратором БД. На перетині стовпця і рядка знаходиться певний елемент даних, званий значенням, або, точніше, атомарним значенням. Таблиця іменується високорівневим класифікатором ідентифікатора користувача власника, за яким слідує ім’я таблиці, наприклад TEST.DEPT або PROD.DEPT.

    Існує кілька типів таблиць:

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

  • Стовпці мають упорядкований набір: DEPTNO, DEPTNAME, MGR і ADMK DEPT. Всі вони повинні бути однотипними даними.
  • Рядки – кожна містить дані для одного відділу.
  • Значення на перетині стовпця і рядка. Наприклад, PLANNING – це значення стовпця DEPT NAME в рядку для відділу B01.
  • Індекс – це впорядкований набір покажчиків на рядки таблиці. На відміну від рядків таблиці, які не перебувають у певному порядку, індекс DB2 повинен завжди підтримувати порядок.

    Індекс використовується для двох цілей:

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

    Основні ключі

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

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

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

    Переваги мережевої БД:

  • Концептуально проста і легка в розробці.
  • Доступ до даних простіше і гнучкіше по відношенню до ієрархічної моделі і не дозволяє члену існувати без батька.
  • Може обробляти дані з-за свого відношення «багато до багатьох». Це дозволяє більш природне моделювання відносин між записами або об’єктами реляційної СУБД на відміну від ієрархічної.
  • Завдяки своїй гнучкості легше переміщається і знаходить інформацію в мережевий БД.
  • Така структура ізолює керуючі програми від складних фізичних даних.
  • Об’єктно-орієнтована система

    В об’єктно-орієнтованих БД всі дані не є об’єктами. Вони можуть бути пов’язані один з одним відношенням «є частиною» для представлення більш великих складових елементів.

    Наприклад, дані, що описують автомобіль, можуть зберігатися як складова частина конкретного двигуна, шасі, коробки передач, системи рульового управління і ін. Класи об’єктів можуть утворювати ієрархію, в якій окремі об’єкти успадковують властивості об’єктів вище. Наприклад, всі об’єкти класу «моторний транспорт» будуть мати двигун (вантажівка, автомобіль або літак). Аналогічно двигуни також є об’єктами даних, і атрибут двигуна конкретного транспортного засобу буде посиланням на конкретний об’єкт двигуна.

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

    Процес проектування

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

    Алгоритм проектування:

  • Визначають мету БД для аналізу вимог.
  • Збирають вимоги. Виконують збір даних, організацію таблиць і вказують первинні ключі.
  • Вибирають один або кілька стовпців в якості так званого первинного ключа з метою ідентифікації рядків.
  • Створюють зв’язки між таблицями. Сила реляційної БД полягає у відносинах між таблицями. Найбільш важливим аспектом при розробці РБД є виявлення взаємозв’язків між ними.
  • Необхідно вибрати необхідний тип даних для конкретного стовпця. Зазвичай типи даних містять: цілі числа, рядок (або текст), дату, час, двійковий код, колекцію, наприклад перерахування і набір.
  • Уточнюють дизайн, додавши більше стовпців.
  • Створюють нову таблицю для необов’язкових даних, використовуючи ставлення один до одного.
  • Розбивають великий стіл на два менших столу.
  • Застосовують правила нормалізації, щоб перевірити, чи є база даних структурно правильної і оптимальною.
  • Індекс може бути визначений для одного стовпця, набору стовпчиків, званого складеним індексом, або частини стовпця, званої частковим індексом. Можна створити більше одного індексу в таблиці. Наприклад, якщо часто шукають клієнта, використовуючи або customer Name або phone Number, можна прискорити пошук, побудувавши індекс стовпця customer Name, а також phone Number.
  • Більшість СУБД автоматично будує індекс по первинному ключу.
  • Створення БД Access

    Коли використовується реляційна СУБД Access, можна просто почати процес введення даних. Потрібно застосувати дизайн РБД, поділивши інформаційний блок на ряд таблиць. Вони з’єднуються з використанням реляційних об’єднань, коли поле однієї збігається з полем іншої таблиці.

    Алгоритм створення БД:

  • Попередньо визначають дані і складають список необхідних полів (фрагментів інформації) з використанням різних типів даних.
  • Усувають зайві поля. Не допускається зберігати однакову інформацію більш ніж в одному місці. У разі коли можна обчислити одне поле, використовуючи інше, зберігають одне.
  • Організовують поля. Формують їх відповідно до опису, у зв’язку з чим кожна група перетворюється в таблицю.
  • Додають таблиці кодів з скороченнями.
  • Включають в БД таблицю назв і коди з двох літер.
  • Вибирають первинний ключ.
  • Пов’язують таблиці.
  • Таким чином, можна підвести підсумок, що основні переваги РБД полягають у тому, що вони дозволяють користувачам просто класифікувати та зберігати дані, легко розширюються і не залежать від фізичної організації. Після створення вихідної БД можна додати нову категорію даних без зміни всіх існуючих додатків.