Костянтин Селезньов
Як відомо, завдання розробки СУБД в ІТ-індустрії спочатку не стояла, але були актуальні прикладні задачі, що вимагають обробки масивів структурованої інформації. Поступово з'ясувалося, що в багатьох випадках алгоритми накопичення, пошуку та аналізу даних однакові, а отже, їх можна зробити універсальними і виділити у вигляді окремих інструментальних засобів - систем управління базами даних. До прикладного ПО обробки великих обсягів інформації завжди пред'являються одні й ті ж вимоги - швидкість роботи і вартість розробки, які трансформуються у вимоги до використовуваної СУБД. Чим більш гнучкими і багатше можливості СУБД, тим простіше розробнику прикладної системи пристосовувати їх для своїх потреб, а значить, тим менше виявляється вартість створюваного ПЗ.
Таким чином, можна сформулювати найбільш загальні вимоги до СУБД - гнучкість і швидкість роботи. Інші часто пред'являються і не менш важливі вимоги, такі як підтримка широко поширених мов запитів або можливість паралельної обробки даних, спочатку не були ключовими. Зміна вимог до прикладного ПЗ тягне за собою зміну вимог до СУБД, звідки випливає, що розвиток технологій СУБД визначається потребами розробників прикладного ПЗ. Саме тому всілякі експериментальні СУБД часто залишаються незатребуваними навіть у тому випадку, якщо перевершують свої аналоги з яких-небудь характеристикам.
За багаторічну історію розвитку СУБД було вироблено кілька моделей подання структурованої інформації: ієрархічна, мережева, реляційна, об'єктно-реляційна і т. д. Найбільше поширення отримала реляційна модель, запропонована Едгаром Коддом в 1970 році, яка надовго стала стандартом представлення структурованої інформації. Причини цього випливають з сформульованих вимог до СУБД. По-перше, реляційна модель виявилася досить простою, з точки зору прикладного програміста. По-друге, вона володіє достатньою гнучкістю і дозволяє представляти інформацію з самих різних предметних областей. По-третє, в рамках цієї моделі використовується потужний і зручний підхід до маніпулювання даними (реляційна алгебра), згодом оформлений у вигляді мови SQL. По-четверте, простота і природність реляційної алгебри дозволили створити високопродуктивні та універсальні алгоритми виконання запитів, що задовольняють більшу частину потреб розробників прикладних систем. Нарешті, до сьогоднішнього дня створено безліч інструментальних засобів, орієнтованих на обробку реляційних даних, що дає ще одну перевагу реляційних СУБД.
Отже, при розробці прикладного ПО з вихідних вимог слід вибір моделі представлення інформації, а вже з неї слід вибір конкретної СУБД. Ця схема може здатися абстрактної в силу того, що на поточний момент домінуючою є реляційна модель, а вибір СУБД виробляється з досить обмеженого списку, який заздалегідь продиктований іншими факторами, такими як інтеграція, простота підтримки, вартість і т. д.
Реляційна модель передбачає оперування тільки атомарними даними і виключає обробку небудь неструктурованої інформації, а це призводить до того, що зберігання графічних, аудіо-або відео даних стає неможливим. Більше того, неможливо навіть зберігання текстових документів довільної довжини. Тому, першим відступом від класичної реляційної моделі у бік зручності розробки прикладного ПЗ можна вважати введення типу BLOB (Binary Large Object - «бінарні дані великого обсягу»), який сьогодні підтримується більшістю сучасних СУБД і закріплений в стандартах...
