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

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

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

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


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

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

  • зміна;
  • тільки читання.

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

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

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

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

Інші моделі даних:

  • ієрархічна;
  • мережева;
  • ER-модель (сутність - зв 'язок);
  • об 'єктно-орієнтована;
  • об 'єктно-реляційна та ін.

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


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

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

Найосновніша категорія, яка має важливе практичне значення: застосовність системи для вирішення завдання. Тут можна всі СУБД розділити на чотири основні групи:

  • модель даних;
  • розподіленість;
  • способи доступу;
  • рівень універсальності.

Це загальна класифікація сучасних СУБД.

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

Способи доступу до даних теж важливі: сайт може вимагати інформації з БД, керованої Oracle, але отримання/запис тут будуть зовсім не так влаштовані, як при використанні MySQL.

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

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

Дотримуючись сформованої традиції, класифікація та функції СУБД відіграють істотну роль при розробці технічного завдання або ІТ проекту, в якому фігурують великі обсяги даних. При цьому термін "великі" може означати рівень конкретного даного (обробка зображень) або кількості записів (обробка тексту).


Функціональність завдання та очікуваного рішення може виставляти чіткі вимоги. Зокрема, вибір СУБД (класифікація за даними):

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

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

  • террабайти інформації (один великий файл, дуже багато маленьких файлів);
  • мегабайти (кілька файлів, що описують одну БД, і дані, що містяться в ній).

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

Зазвичай перший критерій визначає як безумовного лідера Oracle, другий - MySQL. У них багато спільного, але дуже багато кардинальних відмінностей. Коли виникає завдання з 'єднати веб-ресурс з базою даних Oracle без використання її власних інструментів і технологій, виникає безліч питань. Складний connect - давно не рідкість, а часто просто умова для досягнення рішення.

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


Фактично в реальній практиці важливі всі складові: архітектура СУБД, класифікація СУБД за функціональністю, варіантністю підключення і пропускною здатністю каналів зв 'язку.

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

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

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

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

Дивно, що розробники СУБД не стурбовані цими фактами, але якби вони зробили потрібні кроки і закрили раз і назавжди питання доступності даних за межами системи управліннями ними, то утворилася б дилема: за СУБД класифікація спростилася б до межі:


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

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

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

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

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

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

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


  • файл-сервер;
  • клієнт-сервер;
  • вбудована база даних.

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

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

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

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

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

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