Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Проектирование реляционных баз данных.docx
Скачиваний:
55
Добавлен:
16.03.2016
Размер:
189.97 Кб
Скачать

5.2. Практика индексирования

Подавляющее большинство СУБД автоматически строит индекс по первичному ключу. Индексирование по неключевым полям задает разработчик базы данных. Индексы строятся по полям, наиболее часто встречающимся в условиях выборки. К таким полям на практике обычно относятся возможные ключи, хотя это не обязательно. Зная, как работают индексы СУБД и каковы требования предметной области, проектировщик базы данных должен грамотно определить набор индексов.

Рис. 5.5. Отличие В-дерева от В*-дерева

Индекс, построенный по технологии В*-дерева, должен обладать высокой избирательностью. Избирательность отражает количество записей, содержащих заданное значение ключа. Например, если в таблице «Служащий» подсистемы отдела кадров ввести индекс по полю «Пол», имеющему всего два значения (мужской или женский), избирательность индекса будет очень низкой. Затраты памяти на хранение индексной структуры и времени на ее поддержание при операциях вставки и удаления данных будут неоправданными. Скорость поиска при этом может даже замедлиться по сравнению с использованием неиндексированного поля. Замедление происходит за счет обращения сначала к индексу, а потом к данным, хранящимся в таблице. При отсутствии индекса поиск ведется сразу в таблице.

Требование высокой избирательности относится к древовидным индексам. Для битовых индексов, которые в данной работе не рассматриваются, избирательность, наоборот, должна быть низкой.

Также надо обратить внимание на поля, имеющие большое количество значений NULL (не введено, не известно). Некоторые СУБД такие значения в индексное дерево не включают. Другие СУБД не выделяют эти значения из общего ряда.

При создании индекса может быть задана опция уникальности. СУБД отслеживает вводимые или изменяемые значения и пресекает попытки занести в индексируемые столбцы данные, нарушающие их уникальность. Если уникальный индекс создается на заполненной таблице, все данные индексируемых столбцов проверяются на уникальность. Ее нарушение вызывает отказ со стороны СУБД в создании индекса.

Индексирование более эффективно на полях небольшой длины. Размер узла В*-дерева фиксирован (рис.5.4). При коротком индексном ключе большее количество индексных записей помещается в узел, что снижает высоту дерева и, как следствие, количество обращений к внешней памяти для подкачки индексных данных.

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

Проектирование словарной системы должно опираться на существующие системы классификации и кодирования. Имеется ряд общероссийских классификаторов технико-экономической и социальной информации, которые входят в национальную систему стандартизации. Они являются обязательными для применения при создании государственных информационных систем и информационных ресурсов и межведомственном обмене информацией, а также в правовых актах в социально-экономической области. В настоящее время существует 34 общероссийских классификатора и система их автоматизированного ведения. Обеспечивается также гармонизация общероссийских классификаторов с международными и региональными классификациями и стандартами ООН, ЕС, МОТ, ИСО и другими. Структура каждого классификатора и правила построения кодов описаны. Примерами классификаторов являются:

  • Общероссийский классификатор услуг населению (ОКУН);

  • Общероссийский классификатор видов экономической деятельности, продукции и услуг (ОКДП);

  • Общероссийский классификатор продукции (ОКП);

  • Общероссийский классификатор предприятий и организаций (ОКПО);

  • Общероссийский классификатор управленческой документации (ОКУД);

  • Общероссийский классификатор изделий и конструкторских документов (Классификатор ЕСКД);

  • Общероссийский классификатор основных фондов (ОКОФ);

  • Общероссийский классификатор валют (ОКВ);

  • Общероссийский классификатор единиц измерения (ОКЕИ);

  • Общероссийский классификатор профессий рабочих, должностей служащих и тарифных разрядов (ОКПДТР);

  • Общероссийский классификатор информации о населении (ОКИН);

  • Общероссийский классификатор объектов административно-территориального деления (ОКАТО);

  • Общероссийский технологический классификатор деталей машиностроения и приборостроения (ОТКД);

  • Общероссийский классификатор стран мира (ОКСМ);

  • Общероссийский классификатор форм собственности (ОКФС);

  • Общероссийский классификатор организационно-правовых форм (ОКОПФ);

  • Общероссийский классификатор видов экономической деятельности (ОКВЭД)

  • Общероссийский классификатор полезных ископаемых и подземных вод (ОКПИиПВ);

  • Общероссийский классификатор территорий муниципальных образований (ОКТМО).

Кроме общероссийских имеются также отраслевые и ведомственные классификаторы. Их наличие также надо учитывать. При отсутствии соответствующего классификатора создаются собственные словари-справочники. Для формирования кодов обычно используются автоинкрементные типы данных, предоставляемые СУБД.

Наиболее эффективен индекс, построенный на целочисленных полях. Не случайно почти все автоинкрементные типы данных современных СУБД являются целочисленными. Они легко упорядочиваются, обеспечивают удобный и эффективный обход дерева (рис. 5.5). Возможно индексирование и полей других типов. Проектировщик базы данных должен оценить затраты на переход к целочисленным индексам путем кодирования по сравнению с непосредственным индексированием значений, содержащихся в полях. Очень часто эффективность второго решения выше, т.к. дополнительные словари усложняют схему данных, требуют затрат на свое ведение, имеют большой объем в силу большого разнообразия значений исходного поля. Таким образом, можно сделать вывод, что целочисленные индексы предпочтительны, но возводить это в абсолют не следует.

Как видно из рис. 5.4, в индексе повторяются значения соответствующих полей. Поэтому поиск ведется по всему значению. Если требуется искать по части значения используя, например, шаблон со знаками ? (любой символ), * (любая последовательность символов), индекс использоваться не будет. Аналогично, не задействуются индексы, построенные по нескольким отдельным полям, если в критерии поиска используется выражение, построенное на этих полях. Для ускорения поиска в этом случае индексирование должно производиться по соответствующему выражению.

В качестве примера можно рассмотреть проектирование следующей таблицы:

Табельный номер

Ф.И.О.

Стаж

Адрес

Профессия

Особые отметки

Здесь, скорее всего, потребуется суррогатный ключ (см. п. 4.2). Его следует сделать автоинкрементным, индекс будет построен автоматически.

Если по полю «Табельный номер» поиск идет часто, его надо проиндексировать без создания словаря.

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

Вопрос об индексировании поля «Стаж» решается с учетом избирательности.

Поле «Адрес» при необходимости частого поиска также требует разбиения на составляющие. При этом для кодирования элементов адреса следует использовать Общероссийский классификатор объектов административно-территориального деления (ОКАТО), Общероссийский классификатор территорий муниципальных образований и др. Существуют также ведомственные справочники улиц. Наиболее широко распространен справочник пенсионного фонда и службы социальной защиты.

Поле «Профессия» необходимо рассмотреть с точки зрения длины значений. Если значения короткие, по ним можно строить индекс без преобразования. Если названия профессий длинные, индекс будет неэффективен (рис. 5.4, 5.5), требуется кодирование с помощью словаря. При относительно небольшом разнообразии профессий использование общероссийского классификатора может оказаться избыточным и замедлит поиск. В этом случае создается собственный словарь, коды образуются аналогично суррогатным ключам.

Поле «Особые отметки» и другие аналогичные поля как аргументы поиска обычно не используются. Индекс не требуется.