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