6.Властивості індексів.

Індекси можуть бути простими та складними.

Простий індекс визначається тільки на одному атрибуті відношення.

Щоб індекс використовувався оператором SQL, посилання на цей стовпчик повинно бути включене в речення WHERE даного оператора.

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

Індекс може бути унікальним або не унікальним. В унікальному індексі кожне значення індексного ключа повинне бути унікальним. В не унікальному індексі допускається дублювання індексних ключів у таблиці даних. Ефективність не унікального індексу залежить від вибірковості (селективності) даного індексу.

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

7.Індексація. За і проти. Ефективність використання.

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

Для однієї таблиці можуть бути створені кілька індексів. Однак збільшення числа індексів уповільнює операції внесення, оновлення, видалення рядків таблиці, оскільки при цьому необхідно оновлювати самі індекси.

Тому перед створенням індексу потрібно впевнитися, що виграш, який планується в ефективності запитів переважить додаткові витрати ресурсів на супроводження індексу.

8.Обмеження використання індексів.

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

1.Візьмемо такий запит SQL: Select P1 from T1 where P2 like '%ров';

Цей запит повинен нам знайти всіх клієнтів, у яких прізвище закінчується на «ров», однак навіть якщо стовпxbr P2 проіндексований, СКБД все одно буде використати повний перебір таблиці.

Це пов'язане з тим, що індекси будуються в припущенні, що слова/символи йдуть зліва на право. Використання символу підстановки на початку умови пошуку виключає для СКБД можливість використання пошуку по бінарному дереву.

Ця проблема може бути вирішена створенням додаткового індексу за виразом reverse(P2) і формуванням запиту виду:

Select p1 from T1 where reverse(P2) like reverse('%ров');

У цьому випадку символ підстановки виявиться в найбільш правій позиції («вор%»), що не виключає використання індексу за reverse(P2).

8.1.Обмеження послідовності стовпців складного ключа.

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

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