Доступ к данным в БД Основные концепции. Особенности СУБД Oracle

данным:
Последовательная обработка области БД. Областью БД может быть файл или

другое множество страниц (блоков) памяти. Последовательная обработка предполагает, что система последовательно просматривает страницы, пропускает пустые участки и выдаёт записи в физической последовательности их хранения.
Доступ по ключу базы данных (КБД). КБД определяет местоположение записи в памяти ЭВМ. Зная его, система может извлечь нужную запись за одно обращение к памяти.
Доступ по ключу (в частности, первичному). Если система обеспечивает доступ по ключу, то этот ключ также может использоваться при запоминании записи (для определения места размещения записи в памяти). В базах данных применяются такие способы доступа по ключу, как индексирование, хеширование и кластеризация.
Доступ по структуре: используется в иерархических, сетевых и объектно-реляционных БД.

таблице с помощью специальной структуры – индекса.
Индекс – это структура,

которая определяет соответствие значения ключа записи (атрибута или группы атрибутов) и местоположения этой записи – КБД. Каждый индекс связан с определённой таблицей, но является внешним по отношению к таблице и обычно хранится отдельно от неё.

файле или отдельной области памяти.
Пустые значения атрибутов (NULL) не

индексируются.
Индексирование используется для ускорения доступа к записям по значению ключа и не влияет на размещение данных этой таблицы. Ускорение поиска данных через индекс обеспечивается за счёт:
упорядочивания значений индексируемого атрибута. Это позволяет просматривать в среднем половину индекса при линейном поиске;
индекс занимает меньше страниц памяти, чем сама таблица, поэтому система тратит меньше времени на чтение индекса, чем на чтение таблицы.
Индексы поддерживаются динамически.
Каждый индекс относится к одной таблице, на одну таблицу можно создать несколько индексов.

Большинство СУБД автоматически строят индекс по первичному ключу и по

уникальным столбцам.
Плотные и неплотные. В плотных для каждого значения ключа имеется отдельная запись индекса, указывающая место размещения конкретной записи. Неплотные (разреженные) индексы строятся в предположении, что на каждой странице памяти хранятся записи, отсортированные по значениям индексируемого атрибута. Тогда для каждой страницы в индексе задаётся диапазон значений ключей хранимых в ней записей, и поиск записи осуществляется среди записей на указанной странице.
Сжатые и несжатые.
Одиночные и составные.
Линейные и многоуровневые.

одной таблицы. Последовательность вхождения столбцов в индекс определяется при его

создании.

Оно растёт вверх, и корневая вершина может меняться. Параметрами B-дерева

являются порядок n и количество уровней. Порядок – это количество ссылок из вершины i-го уровня на вершины (i+1)-го уровня.
Каждое B-дерево должно удовлетворять следующим условиям:
Все конечные вершины расположены на одном уровне, т.е. длина пути от корня к любой конечной вершине одинакова.
Каждая вершина может содержать n адресных ссылок и (n-1) ключей. Ссылка влево от ключа обеспечивает переход к вершине дерева с меньшими значениями ключей, а вправо – к вершине с большими значениями.
Любая неконечная вершина имеет не менее n/2 подчинённых вершин. (Для деревьев нечётного порядка значение n/2 округляется в большую сторону).
Если неконечная вершина содержит k (k

виде.
Все блоки-листья в дереве расположены на одном уровне, следовательно, поиск

любой записи в индексе занимает примерно одно и то же время.
B-деревья обеспечивают хорошую производительность для широкого спектра запросов, включая поиск по конкретному значению и поиск в открытом и закрытом интервалах (благодаря ссылкам между блоками-листьями).
Модификация данных таблицы выполняется достаточно эффективно, т.к. в блоках индекса обычно есть свободное место для размещения новых значений, а полная перестройка дерева выполняется достаточно редко.
Производительность B-дерева одинаково хороша для маленьких и больших таблиц, и не меняется существенно при росте таблицы.

,...])
[];
Имя индекса должно быть уникальным среди имён объектов БД.
Если

индекс составной, то входящие в него поля перечисляются через запятую. Необязательные <параметры> зависят от используемой СУБД.
Например, в Oracle с помощью следующей команды можно создать составной индекс для таблицы СОТРУДНИКИ (EMP) по полям Фамилия (fam) и Имя (name):
create index ind_emp_name on emp(fam, name)
TABLESPACE MY_INDEXES;
Индексы и таблицы желательно создавать в разных табличных пространствах.

очередь выбираются столбцы, которые часто встречаются в условиях поиска.
Стоит

индексировать столбцы, которые используются для соединения таблиц или являются внешними ключами. В последнем случае наличие индекса позволяет обновлять строки подчинённой таблицы без блокировки основной таблицы, когда происходит интенсивное конкурентное обновление связанных между собою таблиц.
Нецелесообразно индексировать столбцы с низкой селективностью. Исключения для низкой селективности составляют случаи, при которых выборка чаще производится по редко встречающимся значениям.
Не индексируются столбцы, которые часто обновляются, т.к. команды обновления ведут к потере времени на обновление индекса.
Не индексируются столбцы, которые часто используются как аргументы выражений или функций: как правило, это не позволяет использовать индекс.

а именно:
Если в запросах часто используются только столбцы, участвующие

в индексе, система может вообще не обращаться к таблице для поиска данных.
Несколько столбцов с низкой селективностью в комбинации друг с другом могут дать гораздо более высокую селективность.
Обращение к составному индексу возможно только в том случае, если в условиях выбора участвуют столбцы, представляющие собой лидирующую часть составного индекса. Если индекс, например, включает поля (X, Y, Z), то обращение к индексу будет происходить в тех случаях, когда в условии запроса участвуют поля XYZ, XY или X, причём именно в таком порядке.

значение индексируемого поля.
Достаточное условие использования индекса: запрос по индексу выполняется

быстрее, чем без индекса (повышение эффективности).

Вопрос. Будет ли система пользоваться индексом при выполнении следующих запросов:
1) SELECT * FROM emp;
2) SELECT * FROM emp
WHERE name = 'Даль';
3) SELECT * FROM emp
WHERE sex = 'ж';
SELECT depno, count(*)
FROM emp
GROUP BY depno;
5) SELECT * FROM emp e, child c
WHERE e.tabno=c.tabno;

данных Oracle:
Индекс имеет смысл, если нужно обеспечить доступ одновременно

не более чем к 4-5% данных таблицы. Помните, что применение индексов для извлечения строк требует двух операций чтения: индекса и затем таблицы.
Избегайте создания индексов для сравнительно небольших таблиц. Для таких таблиц больше подходит полное сканирование. В случае маленьких таблиц нет необходимости в хранении данных и таблиц, и индексов.
Создавайте первичные ключи для всех таблиц. При назначении столбца в качестве первичного колюча Oracle автоматически создаст индекс по этому столбцу.
Индексируйте столбцы, участвующие в многотабличных операциях соединения.
Индексируйте столбцы, которые часто используются в конструкциях WHERE.

данных Oracle:
Индексируйте столбцы, участвующие в операциях ORDER BY

и GROUP BY или других операциях, таких как UNION и DISTINCT, включающих сортировку. Поскольку индексы уже отсортированы, объем работы по выполнению необходимой сортировки данных для упомянутых операций будет существенно сокращен.
Столбцы, стоящие из длинно-символьных строк, обычно плохие кандидаты на индексацию.
Столбцы, которые часто обновляются, в идеале не должны быть индексированы из-за связанных с этим накладных расходов.
Индексируйте таблицы в которых мало строк имеют одинаковые значения.
Сохраняйте количество индексов небольшим.
Составные индексы могут понадобиться там, где одностолбцовые значения сами по себе не уникальны. В составных индексах первым столбцом ключа должен быть столбец в котором количество строк с одинаковым значением минимально.

указания значения индексированного столбца. Это идеальный индекс для столбца с

низкой кардинальностью (число уникальных записей в таблице мало) при большом размере таблицы.

Эти индексы обычно не годятся для таблиц с интенсивным обновлением, но хорошо подходят для приложений хранилищ данных. Битовые индексы состоят из битового потока (единиц и нулей) для каждого столбца индекса. Битовые индексы очень компактны по сравнению с нормальными индексами на основе B-деревьев.

INDEX day_ind ON tab(day) TABLESPACE MY_INDEXES;

по сути, то же самое, что и индексы B-деревьев, за

исключением того, что байты данных ключевого столбца при индексации меняют порядок на противоположный. Порядок столбцов остается нетронутым, меняется только порядок байтов. Самое большое преимущество применения индексов с реверсивным ключом состоит в том, что они исключают неприятные последствия упорядоченной вставки значений в индекс. Вот как создается индекс с реверсированным ключом:
CREATE INDEX reverse_idx ON employee(emp_id) REVERSE; При использовании индекса с реверсированным ключом базы данных не сохраняет ключи индекса друг за другом в лексикографическом порядке. Таким образом, когда в запросе присутствует предикат неравенства, ответ получается медленнее, поскольку база данных вынуждена выполнять полное сканирование таблицы. При индексе с реверсированным ключом база данных не может запустить запрос по диапазону ключа индекса.

повышением производительности можно за счет создания индекса со сжатым ключом.

Всякий раз, когда индексируемый ключ имеет повторяющийся компонент, или же создается уникальный многостолбцовый индекс, получается выигрыш от использования сжатия ключа. Вот пример: CREATE INDEX emp_indx1 ON employees(ename) TABLESPACE MY_INDEXES COMPRESS 1; Приведенный выше оператор сжимает все дублированные вхождения индексированного ключа в листовом блоке индекса (на уровне 1).

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

Когда конструкция WHERE содержит вызовы функций, то основанные на функциях индексы являются идеальным способом индексирования столбца. Ниже показано, как создать индекс на основе функции LOWER CREATE INDEX lastname _idx ON emp(LOWER(name));

Этот оператор CREATE INDEX создаст индекс по столбцу name, хранящему фамилии сотрудников в верхнем регистре. Однако этот индекс будет основан на функции, поскольку база данных создаст его по столбцу name, применив к нему предварительно функцию LOWER для преобразования его значения в нижний регистр.

во внимание при создании плана выполнения оператора. Невидимый индекс можно

применять в качестве временного индекса для определенных операций или его тестирования перед тем, как сделать его «официальным». Сделать индекс невидимым можно временно, чтобы протестировать эффект от его уничтожения. База данных поддерживает невидимый индекс точно так же, как и нормальный (видимый) индекс. После объявления индекса невидимым, его и все прочие невидимые индексы можно сделать вновь видимым для оптимизатора, установив значение параметра optimizer_use_invisible_index равным TRUE на уровне сеанса или всей системы. Значением этого параметра по умолчанию является FALSE, а это означает, что оптимизатор по умолчанию не может использовать невидимые индексы.
Создание невидимого индекса:
1) CRETE INDEX имя_индекса имя_таблицы(поля) INVISIBLE; 2) ALTER INDEX имя_индекса INVISIBLE / VISIBLE;

его таблицей. Индексы часто становятся слишком большими, если происходит много

удалений сток: пространство, занятое удаленными значениями, автоматически повторно индексом не используется.
Команда REBUILD позволяет реорганизовать индексы и сделать их более компактными, а потому и более эффективными, а также изменить параметры хранения, которые устанавливаются во время начального создания индекса. ALTER INDEX sales_idx REBUILD; Перестройка индексов лучше уничтожения и воссоздания неудачного индекса, потому что при этой операции пользователи продолжают иметь доступ к индексу в процессе его перестройки. Однако индексы в процессе перестройки накладывают много ограничений на действия пользователя.
Команду REBUILD можно использовать в оперативном (online) режиме. Во время оперативной перестройки индекса разрешено применение всех операций DML, но не операций DDL. ALTER INDEX sales_idx REBUILD ONLINE [NOLOGGING]; NOLOGGING: база данных не будет генерировать данные повторного выполнения для операции перестройки индекса.