Система управління базами даних (СУБД): класифікація, визначення та функції

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

Базова функціональність СУБД

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

Концепції систем управління даними

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


Інші моделі даних: ієрархічна; мережева; ER-модель (сутність - зв'язок); об'єктно-орієнтована; об'єктно-реляційна та ін. Вони мають свої ніші, але в кожній з них в основі лежать ті ж реляційні відношення. По суті, у різних концепцій про даних, організованих у системи даних, безперечно і очевидно тільки одне: всі дані завжди мають сенс. Як відобразити зміст формальної комп'ютерної моделі бази даних? Судячи з нечисленним найменуваннями моделей БД, особливої проблеми тут немає, але все ж «чисті реляційні відношення» знаходять саме що ні на є практичне застосування: як назвати вирішеної задачу обробки даних, яке прикметник прикласти до найменуванню її бази даних - неважливо, важливо, що задача вирішена.

Класифікація систем управління даними

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

Функціональність СУБД

Слідуючи традиції, що склалася, класифікація та функції СУБД відіграють істотну роль при розробці технічного завдання або ІТ проекту, в якому фігурують великі обсяги даних. При цьому термін «великі» може означати рівень даного конкретного (обробка зображень) або кількості записів (обробка тексту). Функціональність завдання та очікуваного рішення може виставляти чіткі вимоги. Зокрема, вибір СУБД (класифікація за даними): подання даних (відео, аудіо, текст, різні комбінації); структуризація/формалізація (структуровані, неструктуровані); характер/джерело (ієрархічні, реляційні, мережеві); формат та місце зберігання (локальні, розподілені); користувачі (один, багато). Ця сторона питання зачіпає тільки частина важливих моментів для переваги однієї СУБД іншого. Є безліч прикладних сфер, в яких для вибору СУБД класифікація за будь-яким критерієм не має ніякого значення. Наприклад, вибір системи управління сайтом для цілей розробки сайту поставить розробника перед однозначним вибором тільки однієї конкретної бази даних.

Великі СУБД і складний connect

Сучасний інформаційний рівень СУБД (класифікація за значимістю і відповідальності): терабайт інформації (один великий файл, дуже багато маленьких файлів); мегабайти (кілька файлів, що описують одну БД, і в ній містяться дані). Але значущість і відповідальність тут завжди великі не тільки в першому випадку. Є багато відповідальних проектів, коли малі обсяги інформації обумовлюють прийняття відповідальних рішень.
Зазвичай перший критерій визначає як безумовного лідера Oracle, другий - MySQL. У них багато спільного, але дуже багато кардинальних відмінностей. Коли виникає завдання поєднати веб-ресурс з базою даних Oracle без використання її власних інструментів і технологій, виникає безліч питань. Складний connect - давно не рідкість, а часто просто умова для досягнення рішення. Меншою кількість проблем з доставкою даних виникає при їх знаходженні в локальній мережі на сервері MS SQL Server, до якого з'єднання доступне через кілька апаратних маршрутизаторів. Фактично в реальній практиці важливі всі складові: архітектура СУБД, класифікація СУБД по функціональності, варіантності підключення і пропускної спроможності каналів зв'язку.

Безпека доступу і зберігання даних

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

Соціальний аспект СУБД

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

Реляційні відносини: перспективи

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