Автор работы: Пользователь скрыл имя, 27 Ноября 2013 в 14:01, шпаргалка
Работа содержит ответы на вопросы для экзамена по "Информатике".
Все индексы имеют одинаковую В-tree структуру. SQL Server предлагает к использованию два типа индекса: кластерный (clustered) и некластерный (nonclustered). Разница между этими типами индексов будет освещена ниже.
[В начало]
3. Кластерный индекс
В RDBMS, понятие “кластерный” имеет много значений, но общая идея этого понятия – рассмотрение двух физических объектов как единую сущность. Например, в области построения сетей, кластер есть группа двух и более серверов, видимых как единая логическая сущность и используется для отказоустойчивости и выравнивания (балансировки) нагрузки. В SQL Server кластер означает индекс, смешанный с данными. Таблица представляет собой часть индекса, или индекс представляет собой часть таблицы в зависимости от вашей точки зрения.
Рис.3 Кластерный индекс
Фактически, для кластерного индекса leaf level этого индекса есть сами страницы таблицы с данными. Рис.3 показывает кластерный индекс, созданный по полю CustomerID таблицы Customers.
Поскольку сами данные таблицы являются частью индекса, то очевидно что для таблицы может быть создан только один кластерный индекс.
В SQL Server кластерный индекс является уникальным индексом по определению. Это означает что все ключи записей должны быть уникальные. Если существуют записи с одинаковыми значениями, SQL Server делает их уникальными, добавляя номера из внутреннего (невидимого снаружи) счетчика. Рис. 4 иллюстрирует этот случай. Почему архитектура SQL Server имеет такую функциональность? Ответ прост – потому что есть только два способа найти необходимую запись: по row ID или по ключу кластерного индекса. Row ID используется когда нет кластерного индекса, и кластерный индекс – в противном случае.
На Рис.3 ключ кластерного индекса построен по полю CustomerID, которое по определению имеет только уникальные значения. На Рис.4, например, предположим что кластерный ключ был изменен на поле City. Более чем один клиент может существовать в каждом городе. Например, есть 4 клиента в Mexico. Таким образом SQL Server добавит номера счетчика к дублирующимся записям Mexico, делая эти записи уникальными. Если еще одно значение Mexico будет добавлено в таблицу, его кластерный ключ будет Mexico4.
Первое дублирующееся значение не имеет значения счетчика. Счетчик начинается с первого повторения значения.
Рис.4 Кластерный индекс
Номер, добавляемый
к дублирующимся значениям
Запомните правило, когда работаете с SQL Server: запись может быть найдена либо по row ID либо по кластерному ключу. Это важное замечание, поскольку row ID или кластерный ключ будут сохраняться внутри не кластерного индекса и использоваться для получения реальных данных из записей.
[В начало]
4. Не кластерный индекс
Некластерный индекс имеет leaf level, который содержит все ключевые значения, отсортированные в том виде как был определен индекс, вместе с row ID или кластерным ключом. Сами данные не хранятся в индексе и вынимаются из таблицы, используя row ID или ключ кластерного индекса. Рис.5 иллюстрирует некластерный индекс по полю City. Как видно в указанном примере, таблица не имеет кластерного индекса потому что ссылкой на запись является row ID.
Рис.5 Некластерный индекс
Кластерный индекс использует row locator и он является частью не кластерного индекса на leaf level. Этот факт приводит к важному правилу SQL Server: создавайте кластерные ключи как можно более короткими. Каждый некластерный индекс будет использовать значения кластерного индекса. Следовательно увеличение размера кластерного индекса приводит к многократному увеличению требований по памяти для всех не кластерных индексов. Последнее приводит к увеличению времени на процессы чтения, сканирования данных и, как следствие, к снижению общей производительности системы. Еще одно наблюдение – увеличение длины ключа приводит к снижению количества записей индекса, способных уместиться в пределах одной страницы, как следствие – к увеличению операций чтения-записи. Рис.6 показывает как строится некластерный индекс поверх кластерного.
Рис 6 Некластерный индекс поверх кластерного
[В начало]
5. Составной ключ
До этого момента мы обсуждали индексы, созданные на базе одного поля таблицы. Но индекс может быть создан на основании нескольких полей. В этом случае существует только одно ограничение – длина ключа индекса не должна превышать 900 байтов. Если индекс построен по полям с фиксированным размером, сумма длин этих полей должна не превышать эти 900 байт, если индекс построен по полям с переменной длинной, сумма максимальных размеров полей может превышать 900 байт, но само значение сумм по каждой записи не может быть больше 900 байт. Например в таблице есть два поля переменной длины по 500 байт. SQL Server позволяет создать составной (композитный) ключ на базе этих двух полей, если нет записей, сумма длин по обеим полям превышает 900 байт.
Стоит обратить внимание на тот момент, что составной индекс для (Column1, Column2) является совершенно отличным от (Column2, Column1), а так же от индексов созданных по двум этим полям в отдельности. Как будет показано позже, Query Optimizer может использовать все эти индексы в зависимости от структуры запроса.
[В начало]
6. Уникальные индексы
Уникальный индекс существует для реализации целостности данных в БД. Как рассказывалось ранее целостность данных может быть гарантирована или Unique constrain или primary key. В основе обоих лежит уникальный индекс.
Уникальный индекс гарантирует что каждое значение является уникальным в индексируемом поле или в случае с составным индексом – любая группа значений по полям составного индекса является уникальной. После создания уникального индекса, при попытке вставить повторяющееся значение, вы получите сообщение об ошибке 2601: Cannot insert duplicate key row in object tablename with index indexname.
Теперь вы знакомы с терминологией и типами индексов используемых в SQL Server и мы можем приступить к рассмотрению как SQL Server производит работу с данными при наличии индексов и при их отсутствии.
С ВИКИПЕДИИ
Индекс (англ. index) — объект базы
данных, создаваемый с целью повышения
производительности поиска данных. Таблицы
в базе данных могут иметь большое количество
строк, которые хранятся в произвольном
порядке, и их поиск по заданному критерию
путем последовательного просмотра таблицы
строка за строкой может занимать много
времени. Индекс формируется из значений
одного или нескольких столбцов таблицы
и указателей на соответствующие строки
таблицы и, таким образом, позволяет искать
строки, удовлетворяющие критерию поиска.
Ускорение работы с использованием индексов
достигается в первую очередь за счёт
того, что индекс имеет структуру, оптимизированную
под поиск — например,сбалансированного
дерева.
Некоторые СУБД расширяют возможности индексов введением возможности создания индексов по столбцампредставлений[1] или индексов по выражениям.[2] Например, индекс может быть создан по выражению upper(last_name) и соответственно будет хранить ссылки, ключом к которым будет значение поля last_name в верхнем регистре. Кроме того, индексы могут быть объявлены как уникальные и как не уникальные. Уникальный индекс реализует ограничение целостности на таблице, исключая возможность вставки повторяющихся значений.
Существует два типа индексов: кластерные и некластерные. При наличии кластерного индекса строки таблицы упорядочены по значению ключа этого индекса. Если в таблице нет кластерного индекса, таблица называется кучей[3]. Некластерный индекс, созданный для такой таблицы, содержит только указатели на записи таблицы. Кластерный индекс может быть только одним для каждой таблицы, но каждая таблица может иметь несколько различных некластерных индексов, каждый из которых определяет свой собственный порядок следования записей.
Индексы могут быть реализованы
различными структурами. Наиболее частоупотребимы B*-деревья, B+
Последовательность, в которой столбцы представлены в составном индексе, достаточно важна. Дело в том, что получить набор данных по запросу, затрагивающему только первый из проиндексированных столбцов, можно. Однако в большинстве СУБД невозможно или неэффективно получение данных только по второму и далее проиндексированным столбцам (без ограничений на первый столбец).
Например, представим себе телефонный справочник, отсортированный вначале по городу, затем по фамилии, и затем по имени. Если вы знаете город, вы можете легко найти все телефоны этого города. Однако в таком справочнике будет весьма трудоёмко найти все телефоны, записанные на определённую фамилию — для этого необходимо посмотреть в секцию каждого города и поискать там нужную фамилию. Некоторые СУБД выполняют эту работу, остальные же просто не используют такой индекс.
Для оптимальной производительности запросов индексы обычно создаются на тех столбцах таблицы, которые часто используются в запросах. Для одной таблицы может быть создано несколько индексов. Однако увеличение числа индексов замедляет операции добавления, обновления, удаления строк таблицы, поскольку при этом приходится обновлять сами индексы. Кроме того, индексы занимают дополнительный объем памяти, поэтому перед созданием индекса следует убедиться, что планируемый выигрыш в производительности запросов превысит дополнительную затрату ресурсов компьютера на сопровождение индекса.
Индексы полезны
для многих приложений, однако на их
использование накладываются
SELECT first_name FROM people WHERE last_name = 'Франкенштейн';.
Для выполнения такого запроса без индекса СУБД должна проверить поле last_name в каждой строке таблицы (этот механизм известен как «полный перебор» или «полное сканирование таблицы», в плане может отображаться словом NATURAL). При использовании индекса СУБД просто проходит по B-дереву, пока не найдёт запись «Франкенштейн». Такой проход требует гораздо меньше ресурсов, чем полный перебор таблицы.
Теперь возьмём такой запрос:
SELECT email_address FROM customers WHERE email_address LIKE '%@yahoo.com';.
Этот запрос должен нам
найти всех клиентов, у которых
е-мейл заканчивается на @yahoo.com, однако даже если по столбцуemail_address есть индекс, СУБД всё равно
будет использовать полный перебор таблицы.
Это связано с тем, что индексы строятся
в предположении, что слова/символы идут
слева направо. Использование символа
подстановки в начале условия поиска исключает
для СУБД возможность использования поиска
по B-дереву. Эта проблема может быть решена
созданием дополнительного индекса по
выражению reverse(email_
SELECT email_address FROM customers WHERE reverse(email_address) LIKE reverse('%@yahoo.com');.
В данном случае символ подстановки окажется в самой правой позиции (moc.oohay@%), что не исключает использование индекса по reverse(email_address).
Разреженный индекс (англ. sparse index) в базах данных — это файл с последовательностью пар ключей и указателей.[4]Каждый ключ в разреженном индексе, в отличие от плотного индекса, ассоциируется с определённым указателем на блок в сортированном файле данных. Идея использования индексов пришла от того, что современные базы данных слишком массивны и не помещаются в основную память. Мы обычно делим данные на блоки и размещаем данные в памяти поблочно. Однако поиск записи в БД может занять много времени. С другой стороны, файл индексов или блок индексов намного меньше блока данных и может поместиться в буфере основной памяти что увеличивает скорость поиска записи. Поскольку ключи отсортированы, можно воспользоваться бинарным поиском. В кластерных индексах с дублированными ключами разреженный индекс указывает на наименьший ключ в каждом блоке.
11) Понятие транзакция.
2005 server
Транзакции обеспечивают механизм для объединения нескольких изменений базы данных в одну логическую операцию. После внесения изменений в базу данных они могут быть совместно зафиксированы или отменены. Microsoft SQL Server 2005 Compact Edition (SQL Server Compact Edition) поддерживает транзакции. Транзакции можно использовать несколькими способами:
Транзакции обеспечивают соблюдение свойств ACID (атомарность, целостность, изоляция и надежность) таким образом, который обеспечивает правильную фиксацию данных в базе. Дополнительные сведения о свойствах ACID транзакций см. в разделе "Транзакции" в электронной документации SQL Server.
Типы транзакций:
Явные транзакции
В явной транзакции явно указываются ее начало и конец. Их можно указать либо с помощью инструкций SQL, либо с помощью функций интерфейсов API базы данных.
Для определения явных транзакций с помощью SQL Server Management Studio можно использовать следующие инструкции SQL.