авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 20 | 21 || 23 | 24 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 22 ] --

Если предприятие является транснациональной корпорацией, имеющей филиа лы во многих странах мира, то модель с одним сервером баз данных будет явно Глава 18. Архитектура баз данных неудовлетворительна. Более приемлемым вариантом является установка серве ров баз данных в каждом филиале. В этом случае необходимо решить вопрос о построении баз данных. Если предполагается использование одной базы дан ных, то следует отображать ее состояние на все серверы филиалов. Для решения данной задачи можно воспользоваться подсистемой репликации данных SQL Server 2000, которая была описана в главе 14.

Физическая архитектура базы данных Физическая архитектура баз данных SQL Server 2000 полностью соответствует физической архитектуре баз данных SQL Server 7.0, которая была существенно переработана по сравнению с более ранними версиями. В SQL Server 7.0 не ис пользуются устройства (devices), в которых хранились базы данных в SQL Server 6.x. Устройство представляло собой специальный файл, в котором выде лялось место для баз данных, поэтому размер базы данных был ограничен раз мером устройства. Если нужно было увеличить размер базы данных, то админи стратор обязан был указать, из какого устройства следует добавить место в базу данных. Одно устройство могло принадлежать множеству баз данных — так же, как одна база данных могла использовать множество устройств.

База данных SQL Server 2000 хранится в самостоятельном, уникальном для каж дой БД, наборе файлов. Кроме того, теперь журнал транзакций и сами данные обязательно хранятся отдельно. Это повышает отказоустойчивость базы данных в случае сбоев системы.

Рассмотрим физическую структуру базы данных более подробно.

Файлы и группы файлов Для хранения базы данных предназначен набор файлов, персональный для лю бой базы данных. Каждый файл может принадлежать только одной базе данных.

В SQL Server 2000 существуют два типа файлов базы данных:

• Файлы данных (data file). Предназначены для хранения информации, нахо дящейся в таблицах базы данных. Кроме того, в этих файлах также размеще ны процедуры, ограничения, триггеры, индексы и другая информация.

• Файлы журнала транзакций (transaction log file). В файлы этого типа SQL Server 2000 записывает информацию о ходе выполнения транзакций. В них размешается информация о состоянии данных перед началом транзакции, о выполняемых изменениях, блокированных ресурсах и другая сопутствующая информация.

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

Часть IV. Разработка и сопровождение баз данных Рекомендуется данные, требующие много памяти для хранения ("тяжелые" дан ные), размещать в отдельных файлах. Операции чтения и записи такой инфор мации занимают довольно много времени. Если необходимо часто обращаться к ней, то для повышения производительности можно приписать данные группе, файлы которой располагаются на отдельных физических дисках.

Файлы базы данных могут располагаться на томах с любой файловой системой, поддерживаемой операционной системой. Но при использовании файловой сис темы NTFS следует учесть, что SQL Server 2000 не может работать со сжатыми файлами.

Если компьютер, на котором установлен SQL Server 2000, имеет множество фи зических дисков, то для повышения производительности настоятельно рекомен дуется для каждой базы данных создать как минимум один файл на каждом фи зическом диске. Кроме того, по возможности следует располагать файлы данных и журнала транзакций на отдельных физических дисках. Это благопри ятно скажется на производительности.

Файлы данных бывают двух типов:

П Primary File (основной или главный файл). Каждая база данных имеет один и только один главный файл. Если база данных включает только один файл данных, то этот файл будет основным. Основной файл предназначен для хранения всех системных таблиц, присутствующих в любой базе данных. В основном файле хранится информация о структуре базы данных, созданных в ней объектах, параметрах дополнительных файлов и файлов журнала тран закций. В системной базе данных Master содержится ссылка только на пер вичный файл, а описание остальных файлов размещается в основном файле самой базы данных. Помимо системной информации, в основном файле также могут храниться и пользовательские данные. По умолчанию основному файлу базы данных присваивается расширение mdf (Master Data File).

О Secondary File (вторичный или дополнительный файл). В отличие от основ ного файла, база данных может содержать множество дополнительных фай лов или не содержать их вовсе. В дополнительных файлах может храниться только пользовательская информация. Хранение любой системной информа ции не допускается. В ходе эксплуатации базы данных администратор может добавлять новые или удалять уже существующие дополнительные файлы.

Часто в базе данных создается несколько таких файлов с целью распределе ния данных среди множества физических дисков. По умолчанию для допол нительных файлов базы данных устанавливается разрешение NDF (secoNdary Data File).

Файлы журнала транзакций бывают только одного типа — Transaction Log File (файл журнала транзакций), служащего для хранения журнала транзакций. В базе данных должен быть как минимум один файл журнала транзакций. Для ускорения обработки транзакций можно использовать несколько журналов транзакций, расположенных на разных физических дисках. SQL Server 2000 ор ганизует работу с ними таким образом, что обработка транзакций распределяет ся между различными физическими дисками, что приводит к повышению про Глава 18. Архитектура баз данных изводительности. По умолчанию файлы журнала транзакций имеют расширение ldf (Log Data File).

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

Любой файл базы данных идентифицируется по двум именам:

О OS File Name (физическое имя) — имя файла на диске. Это имя необходимо, чтобы SQL Server 2000 мог вызывать функции Windows NT для работы с файлом.

• Logical File Name (логическое имя) — имя, которое будет применяться в SQL Server 2000 для ссылки на соответствующий файл. Это имя можно рассмат ривать как псевдоним.

Имена обоих типов могут совпадать, но могут быть и различными. По умолча нию SQL Server 2000 предлагает совпадающие имена. Во избежание путаницы лучше не изменять эти значения.

Файлы базы данных в SQL Server 2000 объединяются в группы. Это делается в основном с целью сохранения данных целых таблиц или даже отдельных столб цов таблиц в определенных файлах. По умолчанию в базе данных создается единственная группа. И все данные располагаются в этой группе.

Замечание Каждый файл базы данных может принадлежать только одной группе файлов.

Грамотное использование файлов баз данных может заметно упростить админи стрирование. Кроме того, правильное планирование состава файлов в группах на основе их физического расположения может также повысить и производи тельность. Планируя группы файлов, следует оценить, какие данные будут хра ниться в каждой из них, какова будет интенсивность обращения к ним, как час то данные станут обновляться и т. д.

(~ Замечание ^ Следует отдельно сказать, что создание групп файлов поддерживается только для файлов данных. Группировка файлов журнала транзакций не имеет смысла и поэтому не поддерживается. Создание пользовательских групп файлов необязательно.

Группы файлов бывают следующих типов:

• Primary File Group — основная группа файлов. Основной отличительной осо бенностью этой группы является то, что она содержит основной файл базы данных (primary file) и, как следствие, включает все системные данные. По скольку в базе данных имеется лишь один основной файл, то и основная груп 810 Часть IV. Разработка и сопровождение баз данных па файлов может быть только одна. Другой особенностью основной группы файлов является то, что в нее автоматически включаются все файлы, не при писанные явно ни к какой иной группе. Основная группа может состоять только из одного файла (primary file) и всегда существует в базе данных.

• User File Group — пользовательская группа файлов. Для объединения допол нительных файлов базы данных администратор может создать одну или более пользовательских групп. Состав файлов той или иной группы зависит от ее назначения. В принципе, в базе данных может не быть ни одной пользова тельской группы файлов.

• Default File Group — группа файлов по умолчанию. Это маркер, присваивае мый одной из созданных в базе данных групп. Основным назначением груп пы файлов по умолчанию является хранение данных, не приписанных явно ни к какой группе файлов. Создавая в базе данных новый объект, пользова тель может явно указать, в какой группе файлов он должен храниться. Если же эта информация не указывается, то объект размещается в группе по умол чанию. Допускается конфигурирование только одной группы по умолчанию.

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

Для некоторой группы файлов, включая основную, может быть установлен ре жим "только для чтения" (read only). В этом режиме не допускается внесение никаких изменений в данные. Естественно, надобность в ведении журнала тран закций отпадает. Это позволяет SQL Server 2000 ускорить операции обращения к данным "только для чтения". Обычно данный режим устанавливается для ар хивных данных. Например, внесение изменений в финансовый отчет трехлетней давности вряд ли необходимо. Помимо повышения производительности уста новка группы файлов в режим "только для чтения" может послужить надежной защитой от несанкционированного изменения данных.

Если установить в режим "только для чтения" основную группу файлов, то это за претит внесение любых изменений в состав и структуру объектов базы данных. Как уже говорилось, все объекты базы данных описываются в системных таблицах, ко торые, в свою очередь, размещаются в основном файле (primary file). Запретив вно сить изменения в основную группу файлов, вы тем самым запретите внесение изме нений в любые системные таблицы. В итоге станет невозможно изменить структуру таблиц, свойства пользователей, состав ролей, умолчания и т. д.

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

SQL Server 2000 позволяет выполнять архивирование базы данных, а также групп файлов и даже отдельных файлов, что было описано в главе 13. Отдель ные файлы могут быть восстановлены отдельно от базы данных. Резервные ко Глава 18. Архитектура баз данных 8М_ пии групп файлов, установленных в режим "только для чтения", могут быть вос становлены без восстановления журнала транзакций. Для восстановления ос тальных файлов необходимо дополнительно восстановить журнал транзакций.

С Замечание ^ Выполнять резервное копирование отдельных файлов и групп файлов могут только члены фиксированной роли сервера sysadmin или фиксированной роли базы дан ных db_owner. Члены фиксированной роли базы данных dbbackupoperator мо гут выполнять резервное копирование всей базы данных.

Следует отдельно отметить поведение SQL Server 2000 при хранении данных в группе файлов. SQL Server 2000 равномерно распределяет данные между всеми файлами в группе. То есть вместо того, чтобы заполнить сначала первый файл, потом второй и т. д., SQL Server 2000 по возможности записывает данные сразу во все файлы параллельно.

Объем информации, сохраняемой в каждом файле группы, напрямую зависит от размера файла. Система хранения SQL Server 2000 действует таким образом, чтобы заполнение всех файлов в группе было примерно одинаковым. Предпо ложим, что группа базы данных состоит их трех файлов: 10 Мбайт, 20 Мбайт и 30 Мбайт. Пользователь вставляет 180 строк в таблицу, которая хранится в опи санной группе. Система хранения распределит строки следующим образом: в первый файл (размером 10 Мбайт) будет записано 30 строк, во второй файл — 60 строк, в третий — 90 строк.

Описанный метод хранения данных обеспечивает в некоторых случаях весьма значительное повышение производительности операций ввода/вывода при ис пользовании групп файлов. Это один из нескольких методов повышения скоро сти выполнения дисковых операций. SQL Server 2000 также позволяет использо вать для повышения производительности все преимущества наборов томов с контролем четности и без него.

Страницы и группы страниц Мы уже знаем, что база данных хранится в виде обычного файла на диске, представляющего собой двоичный набор данных. Ядро SQL Server 2000 откры вает этот файл и интерпретирует данные в понятную ему форму. Структуры файлов данных и журнала транзакций существенно различаются. Файл данных имеет более сложную структуру. Объемы данных, которые могут храниться в каждом файле данных, весьма значительны. При этом один файл может содер жать данные, принадлежащие десяткам или сотням разных объектов. Для по строения надежной логической структуры используются различные служебные объекты. В итоге получается довольно сложная структура. Файл журнала тран закций представляет собой просто последовательный набор записей, содержа щих информацию о транзакциях, выполняемых в базе данных. Таким образом, в этом разделе будет рассмотрена физическая структура файлов данных.

812. Часть IV. Разработка и сопровождение баз данных Основой работы ядра SQL Server 2000 с файлом базы данных является страница (page). В виртуальной системе хранения страница представляет собой мини мальный блок, с которым может работать SQL Server 2000. При выполнении операций ввода/вывода система хранения SQL Server 2000 работает со страни цами, а не со строками. Даже если пользователь обращается к единственной строке таблицы, то все равно будет считана целая страница. Каждый файл дан ных базы данных разбит на множество страниц.

Размер страницы в SQL Server 2000 составляет 8 Кбайт. Такой же размер имела страница и в SQL Server 7.0. Однако в SQL Server 6.x размер страницы составлял всего 2 Кбайта. Размер страницы определяет максимальный размер некоторых типов данных. Дело в том, что в общем случае данные одного столбца не могут распределяться между несколькими страницами. Поэтому размер столбцов ти пов данных char, nchar, varchar, nvarchar И binary ограничен 8000 байтами.

Однако для символьных типов данных, поддерживающих стандарт Unicode, максимальное количество символов равно 4000. Это связано с тем, что один символ описывается 2 байтами. На основе сказанного нетрудно сделать вывод, что размер столбца в SQL Server 6.x ограничивался размером 2000 байт.

Замечание Заметим, что 8 Кбайт составляет 8192 байта. Однако для указанных типов данных используется всего 8000 байт. Встает законный вопрос, а куда же девается осталь ное? Ответ прост— остаток используется для хранения служебной информации.

Хотя и сказано, что максимальный размер любого столбца составляет 8000 байт, тем не менее, максимальный размер одной строки составляет 8060 байт. Таким об разом, сумма длин всех столбцов таблицы не должна превышать 8060 байт.

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

О Data. Страницы этого типа используются для хранения собственно данных пользовательских и системных таблиц. Однако страницы типа Data не пред назначена для хранения информации тяжелых столбцов — типов данных im age, t e x t И ntext.

О Index. Этот тип страниц применяется для хранения индексов таблиц и представ лений. Такая информация включает значения индексируемых столбцов, для каж дого из которых также указывается ссылка на исходную строку таблицы.

d Tex^mage. В страницах этого типа сохраняются данные столбцов таблиц, имеющих тип данных image, t e x t или n t e x t. Особенностью хранения дан ных указанного типа является то, что они могут занимать более одной стра ницы. Таким образом, в общем случае для хранения значения столбца од ного из указанных типов данных должно быть выделено более одной страницы, что невозможно при использовании страниц Data. Для хранения одного значения столбца image, t e x t или n t e x t выделяется сразу целая страница. Последующее пространство также выделяется страницами.

Глава 18. Архитектура баз данных Замечание В SQL Server 2000 имеется возможность размещать небольшие значения типов im age, t e x t или n t e x t в страницах Data, что позволяет экономить пространство в ба зе данных.

П Global Allocation Map (GAM). Этот и последующие типы страниц являются чисто служебными. Страницы рассматриваемого типа содержат информацию об использовании групп страниц (экстентов), речь о которых пойдет далее.

• Page Free Space (PFS). Страницы же данного типа содержат информацию о наличии свободного пространства на страницах файла.

• Index Allocation Map (IAM). Страницы этого типа хранят информацию об экстентах, используемых таблицами или индексами.

Страницы разного типа имеют разную структуру.

Далее в этом разделе будет рассмотрена структу ра страниц GAM, IAM и PFS. Сейчас же выяс ним, что представляет из себя страница типа Data. На рис. 18.1 схематично изображена стра ница, содержащая три строки.

Рис. 1 8. 1. Архитектура страницы типа Data Как видно, в начале каждой страницы располагается заголовок, в котором со держится системная информация — тип страницы, объем свободного простран ства на странице, идентификационный номер объекта, которому принадлежит страница, и т. д. Размер заголовка равен 96 байтам, что составляет ровно поло вину объема, резервируемого на каждой страницы для системных нужд (8192 -8000=192=96x2). Указанный заголовок имеют страницы всех типов.

Непосредственно после заголовка располагаются данные столбцов таблицы.

Каждая страница применяется для хранения строк только одной таблицы, для чего она разбивается на один или более блоков (слотов), каждый из которых используется для хранения отдельной строки. Размер слота, а следовательно и их количество на странице, зависят от размера соответствующей строки. При этом следует учитывать, что размер слота для одной и той же таблицы может быть и непостоянным. Подобная ситуация складывается при использовании типов данных переменной длины (varchar, nvarchar и varbinary). Конечно, скорость работы с такими строками снижается, но зато на странице выделяется ровно столько пространства, сколько занимают сами данные.

с Замечание Хотя на рис. 18.1 изображено, что строки располагаются на странице друг за другом, и между ними нет пустых слотов, тем не менее, слоты могут быть заполнены не подряд, а произвольным образом. Даже если первоначально все слоты были запол 814 Часть IV. Разработка и сопровождение баз данных йены и строки в них размещались упорядочений, с течением времени некоторые строки могут быть удалены, вместо них вставлены новые и т. д. В итоге на странице могут появиться пустые слоты, а строки будут храниться в произвольном порядке (если конечно для таблицы не определен кластерный индекс).

При поиске на странице нужной строки сервер должен учитывать, что строки могут иметь разную длину. Если бы размер строки был бы постоянен, то начало строки на странице было бы легко вычислить — достаточно отнять от номера строки единицу, умножить полученное число на размер строки и добавить раз мер заголовка (96 байт). Однако при работе со строками переменной длины по иск начала строки усложняется. Без использования дополнительных механизмов необходимо было бы последовательно считывать со страницы все строки, пока бы не добрались до нужной. Подобный метод нельзя назвать эффективным. По этому каждая страница содержит таблицу смещения строк (row offsets). Эта таб лица располагается в конце страницы и содержит номер байта (от начала стра ницы, а не от начала области данных — конца заголовка), с которого начинае тся соответствующая строка. Порядок перечисления строк в таблице смещения зеркален их порядку на странице. То есть самая последняя запись соответствует самой первой строке, предпоследняя — второй и т. д. Подобный подход позво ляет решить проблему с размером таблицы смещения — она может увеличивать ся до тех пор, пока не столкнется с областью данных.

Работать персонально с каждой страницей было бы неразумно с точки зрения производительности, особенно с учетом тех громадных объемов информации, которые может хранить SQL Server 2000. Поэтому для облегчения работы со страницами были созданы так называемые экстенты (extent), которые представ ляют собой группу из 8 страниц. Таким образом, общий объем экстента состав ляет 64 Кбайта. Экстент является минимальным элементом, который выделяется на уровне файла для хранения данных. Даже если необходимо сохранить всего одну страницу, то будет выделен новый экстент (если конечно страницу нельзя сохранить в одном из имеющихся экстентов).

Каждая страница имеет своего владельца, в качестве которого может выступать таблица, индекс или другой объект. Таким образом экстент может содержать страницы, принадлежащие либо одному объекту, либо разным. От этого зависит тип экстента:

• Uniform. Экстенты (рис. 18.2, внизу) этого типа содержат только страницы, принадлежащие одному владельцу. Если для таблицы, представления и т. д.

было выделено 8 страниц, то имеет смысл расположить их рядом, чтобы по высить скорость поиска, считывания и записи данных как на физическом, так и на логическом уровне. Для этого они размещаются в одном экстенте.

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

страницы одного экстента располагаются рядом.

П Mixed. В экстентах данного типа (рис. 18.2, вверху) могут содержаться стра ницы, принадлежащие разным владельцам. Это позволяет снизить непроиз водительные расходы пространства в файлах базы данных. Если бы сущест вовали только экстенты типа Uniform, то сервер стал бы выделять место в Глава 18. Архитектура баз данных файле блоками по 64 Кбайта (8 страниц), даже если в таблице имелись всего две-три строки, занимающие четверть страницы. Более того, если таблица имела бы большой размер, но количество выделенных для нее страниц не было кратно 8, то для хранения хвостов также выделялись бы блоки данных по 64 Кбайта. Подобные траты пространства были бы чрезмерно большими.

Поэтому реализована возможность хранения в экстенте страниц, принадле жащих разным объектам.

Экстент Mixed Рис. 1 8. 2. Экстенты SQL Server Мы рассмотрели, из каких компонентов состоит файл данных. Однако ничего не было сказано о том, как сервер находит свободные страницы и восстанавли вает цепочку страниц, используемых для хранения данных конкретного объекта.

При этом необходимо учитывать, что страницы одного и того же владельца мо гут располагаться более чем в одном файле, что еще более усложняет восстанов ление цепочки. Начнем с рассмотрения принципов поиска свободных страниц.

При описании типов страниц мы упомянули, что страницы Global Allocation Map (GAM) содержат информацию об использовании экстентов. Однако не по нятно, что стоит за этой фразой. Сейчас пришло время сказать, что страницы GAM хранят информацию о том, какие экстенты содержат свободные страни цы, куда можно сохранить данные. Страница GAM представляет собой битовое поле, каждый бит которого соответствует одному экстенту. Так как размер стра ницы равен 8 Кбайт, то одна страница GAM может описать 64 000 экстентов — размер области пользовательских данных страницы (8000) умножить на количе ство бит (8). Говоря об объеме данных, можно сказать, что одна страница GAM охватывает область немногим менее 4 Гбайт — 64 000 экстентов х 8 страниц х раз мер страницы 8192 байта.

Необходимо отметить, что страница GAM способна хранить два типа битовых полей, которые применяются совместно и дополняют друг друга:

• Global Allocation Map (GAM). Поле этого типа собственно и содержит ин формацию об использовании экстентов. Если бит равен 1, то соответствую щий экстент пуст и может быть использован для записи данных. Если бит установлен в 0, то экстент содержит какие-то данные.

27 Зи. Часть IV. Разработка и сопровождение баз данных gjg П Shared Global Allocation Map (SGAM). Этот тип полей предназначен для хра нения информации о типе экстента. Если описывающий экстент бит уста новлен в 1, то этот экстент имеет тип Mixed, и на нем имеется как минимум одна свободная страница. Когда же бит установлен в 0, то это означает, что либо экстент имеет тип Uniform (а значит полностью заполнен), либо тип Mixed, но не содержит пустых страниц.

Таким образом, для пустого экстента как в поле GAM, так и в поле SGAM со ответствующий бит будет установлен в 1. Рассмотрим, что же происходит при записи данных. Возможны две ситуации:

• Сохраняется 8 страниц, принадлежащих одному владельцу. В этом случае разумнее всего сохранить все данные в одном экстенте Uniform. To есть не обходимо найти в файле полностью свободный экстент. Для этого достаточ но найти в поле GAM бит, равный 1. Соответствующий этому биту экстент будет свободным. После записи данных остается только установить соответ ствующие биты полей GAM и SGAM в 0.

П Сохраняется менее 8 страниц, принадлежащих одному или разным владель цам. В этом случае можно либо использовать один из экстентов Mixed, имеющий свободные страницы, либо создать новый экстент Mixed. В по следнем случае опять же в поле GAM ищется бит, равный 1. После чего в соответствующий экстент записываются данные. Остается установить соот ветствующий бит поля GAM в 0, оставив при этом бит в поле SGAM без из менения (равным 1). Если же данные сохраняются в существующий экстент Mixed, то в случае полного заполнения экстента потребуется установить в соответствующий бит поля SGAM.

Итак, примерно на каждые 4 Гбайта (точнее на 3,95 Гбайта) данных необходимо выделить в файле данных две страницы типа GAM, общий размер которых со ставит всего 16 Кбайт. Такая спрессованность информации позволяет хранить в оперативной памяти информацию использования экстентов, что позволяет бы стро находить свободное пространство для записи данных.

Мы неоднократно говорили, что страницы GAM применяются только при по иске свободного пространства для записи страниц. Однако этих страниц для полноценной работы с данными явно недостаточно. Действительно, при сохра нении одной-двух строк нет смысла выделять для них новую страницу, если на уже выделенных для соответствующего объекта страницах достаточно свобод ного пространства. Таким образом, встает задача найти страницы, принадлежа щие объекту и определить количество свободного пространства на них.

Информация о степени заполнения страниц (не экстентов) хранится в страни цах типа Page Free Space (PFS). Каждая такая страница хранит информацию о количестве свободного пространства на 8000 страниц типа Data, Text/Image и Index. Таким образом, каждая страница описывается 1 байтом. Степень запол нения каждой страницы выражается в процентах. Однако приводится не кон кретное количество свободного пространства, а примерное. Информация указы вается с помощью битов, каждому из которых соответствует определенное состояние страницы. Одновременно может быть установлен всего один бит.

Рассмотрим, какие состояния могут быть описаны:

О страница заполнена от 81% до 95%;

• страница заполнена от 96% до 100%.

Страницы PFS предназначены для быстрого поиска страниц, имеющих доста точно свободного пространства для хранения данных. Конечно, определить ко личество свободного пространства на странице можно простым ее просканиро ванием. Однако прежде необходимо будет найти ее в файле и считать с диска.

Если же места будет недостаточно, то нужно будет считать следующую страни цу, снова проверить объем свободного пространства и т. д. Использование же страниц PFS позволяет значительным образом оптимизировать поиск страниц с необходимым объемом свободного пространства, не прибегая к сканированию самих страниц.

Однако, страницы PFS не содержат данных о том, кто именно является вла дельцем той или иной страницы. Очевидно, что эта же информация необходима для принятия решения о том, в какой именно странице файла следует сохра нить данные. Информация о владельце страницы хранится в страницах типа Index Allocation Map (IAM). Каждая страница 1АМ описывает экстенты, при надлежащие одному объекту. Таким образом, каждому объекту (таблице или индексу) должна быть сопоставлена как минимум одна страница IAM.

Страница 1АМ представляет собой битовое поле наподобие GAM. Если бит по ля установлен в 1, то в экстенте содержатся страницы, принадлежащие соответ ствующему объекту. Когда же поле IAM содержит 0, то экстент принадлежит другому объекту либо вообще пуст. Таким образом, одна страница IAM охваты вает блок данных объемом немногим менее 4 Гбайт (3,95 Гбайта), что соответст вует 64 000 экстентам.

Если же не все страницы объекта располагаются в этом интервале, то необхо димо создать дополнительную страницу IAM. При этом в первой странице ука зывается номер второй страницы IAM. Таким образом можно охватить весь файл базы данных. На рис. 18.3 схематично изображено использование страниц IAM для отслеживания принадлежащих одному владельцу таблиц.

Рис. 18.3. Использование страниц IAM 27* Часть IV. Разработка и сопровождение баз данных (~ Замечание ) Необходимо отметить, что страницы IAM создаются в файле в произвольном месте.

При этом нет гарантии, что страницы IAM одного владельца покроют весь файл.

Однако этого и не нужно.

Встает законный вопрос, а как же узнать номер первой страницы IAM? Номер страницы первого поля IAM хранится в столбце FirstiAM системной таблицы sysindexes. Зная номер первой страницы IAM, всегда можно восстановить всю цепочку страниц IAM и получить список всех экстентов, содержащих принад лежащие конкретному объекту данные. В других столбцах таблицы sysindexes указываются объекты, которым принадлежит первый IAM. Таким объектом мо жет быть индекс (кластерный или некластерный), таблица или отдельный стол бец таблицы, имеющий ТИП данных t e x t, n t e x t ИЛИ image.

( Замечание ^ В таблице sysindexes хранится много другой интересной информации. В частно сти, в столбце s t a t b l o b хранится информация о статистике, в столбце xmaxien — максимально возможный размер строки, а в столбце m i n i e n — минимально воз можный размер, в столбце keycnt — количество ключевых полей и т. д.

Замечание Напомним, что в SQL Server 2000 данные столбцов типов t e x t, n t e x t или image способны храниться в страницах Data, т. е. могут быть включены непосредственно в строку, а не размещаться отдельно.

Ранее мы уже упоминали, что страницы объекта могут располагаться более чем в одном файле. Это нисколько не затрудняет восстановление цепочки экстен тов, содержащих страницы объекта. Дело в том, что при указании номера сле дующей (или первой) страницы IAM приводится также и идентификационный номер файла, в котором расположена нужная страница. Это и позволяет рас пределять данные одного индекса, таблицы или столбца таблицы между множе ством файлов базы данных. На рис. 18.4 приведена схема распределения данных между двумя файлами. Как видно из схемы, сначала считывается номер (в том числе и номер файла) первой страницы IAM. Та же содержит ссылку на вторую страницу, которая, в свою очередь, ссылается на третью и т. д.

( Замечание ) Страницы IAM объекта создаются не во всех файлах, а только в тех, которые со держат хотя бы один экстент со страницами объекта.

Как видно из рис. 18.4, не всегда экстенты со страницами объекта располагают ся оптимальным образом. Налицо существование в файлах данных фрагмента ции экстентов. Эту проблему можно сравнить с проблемой хранения обычных файлов операционной системы на диске — они также подвержены фрагмента ции. Особенно актуальна эта проблема в файловой системе FAT. Однако при Глава 18. Архитектура баз данных работе с файлами операционной системы в распоряжении пользователя имеют ся специальные утилиты, позволяющие выполнить дефрагментацию диска. По сле выполнения дефрагментации кластеры, принадлежащие одному файлу, рас полагаются на диске последовательно друг за другом. Это позволяет повысить скорость операций чтения и записи данных.

Таблица sysindexes столбец FirstlAM Рис. 18.4. Распределение данных объекта среди множества файлов В SQL Server 2000 также имеются средства управления фрагментацией страниц.

В первую очередь, необходимо оценить степень фрагментации страниц объекта.

Для этого может использоваться команда DBCC SHOWCONTIG. ДЛЯ выполнения дефрагментации применяются команды DBCC DBREINDEX И DBCC INDEXDEFRAG.

Мы не будем сейчас рассматривать использование этих команд, оставив это до главы 25.

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

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

Теперь же рассмотрим, как распределяются в файле страницы разных типов. На рис. 18.5 приведено начало типичного файла данных. Как видно из рисунка, нумерация страниц в файле начинается с нуля. При этом используется сквозная нумерация. То есть нет различия между страницами разных типов. Тип страни цы определяется по ее заголовку. Первые четыре страницы являются стандарт ными для любого файла данных. Напомним, что страницы PFS содержат ин формацию об объеме свободного пространства на каждой странице данных.

Страницы же GAM и SGAM хранят информацию об использовании экстентов и их типе. Тип же следующих страниц может быть любым. В данном случае это страницы Data. Обязательно в файле должны присутствовать страницы IAM.

Рис. 18.5. Пример файла данных S20 Часть IV. Разработка и сопровождение баз данных Итак, мы рассмотрели физическую архитектуру файлов базы данных, примене ние страниц и экстентов, а также их типы.

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

Если на физическом уровне рассматриваются структуры, используемые для хра нения различной информации, то на логическом уровне необходимо рассматри вать объекты, которые можно создавать в базе данных, а также различные свой ства, которые влияют на работу сервера с базой данных. Под объектами здесь понимается не только собственно объект, каковым является таблица, представ ление, хранимая процедура и т. д., но также и пользователи, роли, полнотексто вые каталоги. К логическому уровню относятся и права доступа пользователей и ролей базы данных к созданным в ней объектам.

Приведем список собственно объектов базы данных, которые служат для хране ния и обработки информации:

• Таблицы (tables). Это единственный объект базы данных, предназначенный для хранения пользовательских данных. Работа с таблицами будет подробно описана в главе 21, тогда как управление хранящимися в них данными будет приводиться в главах 28 и 29.

П Представления (views). Являются виртуальными таблицами (virtual tables), ко торые отображают данные, хранящиеся в других таблицах. Для пользователя же представления во многом напоминают таблицы. Использование представ лений будет подробно описано в главе 22.

• Индексы (indexes). Объекты этого типа предназначены для повышения про изводительности работы сервера при поиске нужных данных в таблицах и представлениях, что достигается путем хранения в упорядоченном состоянии данных одного или более столбцов таблицы или представления. Таким обра зом, индексы не могут существовать сами по себе. Подробно работа с индек сами будет рассмотрена в главе 23.

П Ключи (keys). Являются одним из типов ограничения целостности. Однако они играют достаточно важную роль в базе данных и поэтому рассматрива ются как отдельные объекты. Тем не менее, реализуются они так же, как и другие ограничения целостности, которые связываются с таблицами.

О Умолчания (defaults). Этот тип объектов описывает значения, которые при сваиваются столбцам таблицы, если при добавлении строки явно не было указано значение для соответствующего столбца. Работа с умолчаниями будет рассмотрена в соответствующем разделе далее в этой главе.

Глава 18. Архитектура баз данных П Правила (rules). Являются логическим условием, ограничивающим диапазон возможных значений для столбца таблицы или определяемого пользователем типа данных. Подробно правила будут рассмотрены далее в этой главе.

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

• Хранимые процедуры (stored procedures). Представляют собой набор команд Transact-SQL, сохраненных специальным образом. Каждая процедура имеет свое имя. По этому имени пользователи могут вызывать процедуру, запуская тем самым на выполнение весь набор команд, представляющих тело проце дуры. Рассмотрению работы с процедурами, а также использования их по священа глава 30.

П Триггеры (triggers). Это специальный тип хранимых процедур, автоматически запускаемых сервером при выполнении удаления, вставки или изменения данных в конкретной таблице. То есть триггеры связываются с определенной таблицей и не могут существовать сами по себе. Работа с триггерами будет рассмотрена в главе 32.

П Определяемые пользователем типы данных (user-defined data types, UDDT).

Эти объекты представляют собой типы данных, создаваемые пользователями.

Подробно работа с ними будет представлена в одном из следующих разделов этой главы.

• Определяемые пользователем функции (user-defined function). Объекты этого типа представляют собой набор команд Transact-SQL, сохраненных пользова телем в виде функции. Как системные (встроенные) функции SQL Server 2000, так и определяемые пользователем функции будут рассмотрены в главе 27.

Необходимо отметить, что большинство приведенных в списке объектов базы данных SQL Server 2000 являются довольно сложными. Поэтому рассмотрение работы с ними вынесено в отдельные главы. Тем не менее, в базе данных также имеется ряд объектов, работа с которыми не представляет особых затруднений.

Поэтому эти объекты будут рассмотрены в следующих разделах данной главы.

Однако, прежде чем приступать к рассмотрению объектов базы данных, следует рассмотреть, как происходит именование объектов и какие отношения сущест вуют между пользователями и объектами. Этому и будут посвящены два сле дующих раздела.

Именование объектов Чтобы иметь возможность работать с объектом, необходимо как-то ссылаться на него. Наиболее простой способ обеспечить уникальную идентификацию объек та — присвоить ему имя. Хотя, конечно, это не единственный способ. Напри мер, можно обращаться к конкретному объекту, зная его адрес в памяти, на диске или в файле базы данных (в случае SQL Server 2000). На самом деле имя 822 Часть IV. Разработка и сопровождение баз данных объекта является своего рода ссылкой, за которой кроется физический адрес объекта. Однако пользователю гораздо удобнее работать с символьными имена ми объектов, чем с набором чисел, представляющих адрес объекта.

В SQL Server 2000 для обращения к объектам используются имена (идентифи каторы). Каждый объект должен иметь имя, уникальное в пределах базы дан ных. В противном случае система не сможет определить, с каким именно объек том хочет работать пользователь. Обеспечение уникальности имен объектов ле жит на SQL Server 2000. Сервер не даст создать пользователю двух объектов с одинаковыми именами.

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

При создании объектов выдвигается ряд требований к их именам. Рассмотрим эти требования.

• Максимально допустимая длина имени объекта равна 128 символам. Для хранения имени объекта отводится 256 байт, т. к. имена объектов хранятся в стандарте Unicode. Длина имени временных таблиц ограничена 116 символа ми. Остальные 12 символов используются SQL Server 2000 для служебных целей.

• При выборе имени объекта следует удостовериться, что оно не является заре зервированным словом, используемым самим SQL Server 2000. Например, нельзя создать таблицу с именем SELECT ИЛИ CASE, Т. К. ЭТИ слова являются зарезервированными. Кроме того, необходимо проверить, не существует ли уже в базе данных объекта с аналогичным именем.

• В качестве первого символа имени объекта допускается применение только символов национального или латинского алфавитов, а также символа _ (подчеркивание). То есть имя объекта не может начинаться с цифры, сим волов !, $ и т. д. Это же правило касается и имен временных таблиц. Хотя один или два первых символа имени временной таблицы могут быть #, тем не менее, следующий за ним символ должен удовлетворять описанному правилу.

• Второй и любой из следующих символов имени объекта может включать лю бые символы, определенные стандартом Unicode Standard 2.0 — символы на циональных алфавитов, десятичные цифры и символы @, #, $ и _.

• Не допускается использование в любом месте имени объекта пробелов, круг лых, квадратных и фигурных скобок, а также символов !, %, л, &, ~, -,.

(точка),, (запятая), \, * и '.

Глава 18. Архитектура баз данных С Замечание } При работе с сопоставлением (collate), не чувствительным к регистру, следует учи тывать, что SQL Server 2000 не будет различать регистра, в котором набрано имя объекта. Однако если при установке SQL Server 2000 было выбрано сопоставление, чувствительное к регистру, то одинаковые имена, набранные в разных регистрах, будут считаться различными.

Имена объектов, соответствующие описанным выше правилам, называются стандартными идентификаторами (Regular Identifiers). Примеры таких иденти фикаторов легко увидеть в базе данных pubs. Список созданных в базе данных объектов хранится в системной таблице sysobjects, в столбце Name которой указываются собственно имена объектов. С помощью приведенного ниже кода можно получить список десяти имен объектов базы данных pubs:

USE pubs SELECT TOP 10 Name FROM sysobjects После выполнения команды будет получен примерно следующий результат:

Name authors byroyalty CHECK_CONSTRAINTS CK authors au_id 08EA CK authors z ip 0AD2 A0 0 CK jobs max_lvl CK jobs min_lvl CK publisher pub_i 0DAF0CB CK_emp_id COLUMN_DOMAIN_USAGE (10 row(s) affected) Помимо стандартных идентификаторов в SQL Server 2000 существуют еще и так называемые ограниченные идентификаторы (Delimited Identifiers). Ограниченные идентификаторы позволяют обходить некоторые из описанных выше правил именования объектов. Большинство требований к именам объектов продиктова но тем, что SQL Server 2000 должен легко определять, что встреченная последо вательность символов является именем объекта, а не служебными конструкция ми, константами и т. д. Однако пользователь может явно указать, что конкрет ная последовательность символов является именем объекта, а ни чем-то иным.

Для этого в SQL Server 2000 предназначены специальные ограничители — либо квадратные скобки, либо двойные кавычки. Имена объектов, заключенные в квадратные скобки или двойные кавычки, и называются ограниченными иден тификаторами.

Когда имя объекта заключается в ограничители, в нем могут использоваться лю бые символы, включая скобки, пробелы, специальные символы, а также зарезер вированные слова. Кроме того, первым символом имени объекта может быть лю бой символ. Однако остаются требования к уникальности имени объекта.

824 Часть IV. Разработка и сопровождение баз данных Приведем пример команды, выполняющей создание таблицы, имя которой, как и имена ее столбцов, не соответствуют требованиям именования объектов и должны быть заключены в ограничители:

CREATE TABLE [3 к в. 2001 - отчет] ([01-09] i n t, [10-39] i n t, [Сумма] money) При использовании в качестве ограничителей двойных кавычек этот же код бу дет выглядеть следующим образом:

CREATE TABLE "3 кв. 2000 - отчет" ("01-09" i n t, "10-39" i n t, "Сумма" money) С Замечание ~~) Допускается комбинирование в одной команде ограничителей различных типов. Од нако для ограничения имени одного объекта можно использовать только один тип ограничителя. Например, если начало имени объекта указывается с помощью квад ратных скобок, то и конец имени также должен быть определен с помощью закры вающей квадратной скобки.

Приведенный пример демонстрирует использование квадратных скобок для ука зания имен объектов, не соответствующих стандартным правилам именования.

Как уже было сказано ранее, в качестве ограничителей могут быть также ис пользованы и двойные кавычки (double quotation marks). Однако применение двойных кавычек в SQL Server 2000 возможно двумя способами. Дело в том, что предыдущие версии SQL Server и некоторые другие программы по разному ис пользуют двойные кавычки. В одних системах двойные кавычки рассматривают ся как эквивалент одинарных кавычек (single quotation marks). To есть символы, заключенные в двойные кавычки, рассматриваются как обычный текст. В дру гих же системах символы, заключенные в двойные кавычки, воспринимаются как имена объектов.

Для обеспечения совместимости с обоими типами систем в SQL Server 2000 раз решается произвольное использование двойных кавычек. При необходимости пользователь может переключать режимы использования двойных кавычек по своему усмотрению. На уровне соединения для этого применяется следующая команда:

SET QUOTED_IDENTIFIER {ON I OFF} При выполнении команды с параметром ON двойные кавычки будут интерпре тироваться как квадратные скобки. Если же используется аргумент OFF, TO за ключенные в двойные кавычки символы станут восприниматься как обычная строка символов, а двойные кавычки будут интерпретироваться как одинарные кавычки.

Рассмотрим указание двойных кавычек на примере.

SET QUOTED_IDENTIFIER ON SELECT au_fname F O a u t h o r s, t i t l e a u t h o r RM W E E a u t h o r s. a u i d = t i t l e a u t h o r. a u id AND au l n a m e = " t i t l e i d " HR Глава 18. Архитектура баз данных 825_ В этом случае будет выведен список имен всех авторов из таблицы authors, у ко торых фамилия (столбец auiname) совпадает со значением в столбце t i t l e id.

SET Q0OTED_IDENTIFIER OFF SELECT au_fname FROM authors, titleauthor WHERE authors.au_id=titleauthor.au_id AND au_lname="title_id" В этом случае будет выведен список имен всех авторов из таблицы authors, у которых значение в столбце aulname равно строке t i t l e id.

В первом случае значение titleid рассматривалось как имя столбца, тогда как во втором случае — как обычная текстовая строка.

Замечание Логики в сравнении фамилии автора (au_lname) с идентификатором книги ( t i t l e _ i d ) конечно же нет. Приведенные команды на примере стандартной базы данных pubs иллюстрируют использование двойных кавычек.

Многие хранимые процедуры и некоторые команды Transact-SQL требуют ука зания в качестве параметра имен объектов. При этом имена объектов передают ся как параметр хранимой процедуры в виде обычной строки. Если имя объекта является ограниченным, то при выполнении хранимой процедуры или команды Transact-SQL его необходимо заключить в ограничители.

Например, для получения информации о разрешениях, выданных для таблицы [3 кв. 2000 - отчет], вызов процедуры s p _ t a b i e _ p r i v i l e g e s необходимо за писать следующим образом:

sp_table_privileges @table_name_pattern = '[3 кв. 2000 - отчет)' Доступ к объектам Каждый объект базы данных SQL Server 2000 должен иметь своего владельца (owner). Владелец объекта имеет полный контроль (full control) над своим объек том. Он может изменять его структуру, добавлять и удалять строки (если это таблица или представление), предоставлять другим пользователям различные права доступа к объекту, а также может удалить сам объект.


Владельцем объекта обычно является пользователь базы данных, который создал этот объект. Однако права владения объектом могут быть переданы и любому другому пользователю базы данных. Для передачи прав владения существует следующая хранимая процедура:

sp_changeobjectowner [@objname =] ' o b j e c t ', [@newowner =] 'owner' Имя объекта, владельца которого необходимо изменить, указывается с помощью аргумента [@objname =] ' o b j e c t '. Аргумент [@newowner =] 'owner' задает имя нового владельца объекта.

( Замечание ^ Сам владелец объекта не может передать права владения объектом другому поль зователю. Это может сделать только пользователь, являющийся членом фиксиро 826 Часть IV. Разработка и сопровождение баз данных ванной роли базы данных db_owner, db_dlladmin или db_securityadmin. Тем не менее, права на выполнение этой хранимой процедуры могут быть даны любому пользователю.

Замечание Члены фиксированной роли db_owner способны создавать объекты, владельцем которых является произвольный пользователь базы данных. Для этого при создании объекта достаточно указать помимо собственно имени объекта имя пользователя, которому должен принадлежать объект. Это позволяет не прибегать к использова нию хранимой процедуры sp_changeobjectowner.

.Помимо того, что объект принадлежит конкретному пользователю, он еще и находится в определенной базе данных. База данных, в свою очередь, размеща ется на каком-то сервере. На основе этих отношений складывается полное имя (complete name) или, как его еще называют, полностью определенное имя (full qualified name) объекта. Полное имя объекта записывается в виде:

[[[server.][database].][owner_name].]object_name Во главе дерева объектов находится сервер. Следующий уровень иерархии — это база данных. Затем указывается пользователь, которому принадлежит объект, а уже затем имя самого объекта. Когда мы говорим об уникальности имени объ екта, то имеется в виду, что должно быть уникальным только полное имя. Это означает, что один и тот же пользователь одной и той же базы данных не может создать двух одноименных объектов. В то же время допускается создание в базе данных множества объектов с одинаковыми именами, но принадлежащих раз ным пользователям.

При ссылке на объект необходимо как минимум указать имя объекта. Если ос тальные параметры опущены (имя сервера, базы данных и владельца), то будет производиться поиск объекта, расположенного на текущем сервере в текущей базе данных и принадлежащего либо владельцу базы данных (пользователь dbo), либо текущему пользователю.

Замечание Когда пользователь обращается к объекту только по его имени, сервер сначала ищет объект, принадлежащий текущему пользователю. Если такой объект не нахо дится, то сервер пытается найти объект, принадлежащий пользователю dbo. Если и такой объект не найден, то выдается сообщение об ошибке. Если же необходимо обратиться к объекту, принадлежащему не текущему пользователю и не пользова телю dbo, то следует обязательно указать имя владельца, т. к. сервер не перебира ет имен всех владельцев.

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

server.database.owner_name.object name server.database..obj ect_name Глава 18. Архитектура баз данных server..owner_name.object_name server...object_name database.owner_name.object_name database..object_name owner_name.obj ect_name object_name ) ( Замечание При обращении к объектам связанного сервера (linked server) или удаленного сер вера (remote server) не разрешается опускать часть имени. То есть необходимо все гда указывать полное имя объекта в формате s e r v e r, database, ownername.

object_name. Работа со связанными и удаленными серверами была рассмотрена в главе 10.

Приведенный формат доступа к объектам базы данных касается всех объектов — таблиц, представлений, правил, умолчаний, индексов, ограничений целостности и т. д. Однако при работе с таблицами и представлениями бывает необходимо ука зывать еще и имя столбца. Для этого к имени объекта добавляется пятый элемент:

[[[server.][database].][owner_name].]object_name.column_name Такая форма записи может быть с успехом использована, например, при выбор ке данных с помощью команды SELECT ИЛИ при выполнении обновления дан ных с помощью команды UPDATE.

Если часть полного имени объекта не соответствует стандартным правилам именования объекта (например, содержит пробелы), то она должна быть заклю чена в ограничители:

SQLSrvl.[KHSU Databases]..[RIAC People List] Умолчания Как уже было сказано, умолчания (defaults) являются объектами базы данных, предназначенными для автоматического присвоения значения столбцу таблицы при вставке новой строки, если для этого столбца явно не было указано кон кретное значение. Помимо этого, умолчание может быть связано и с пользова тельским типом данных, который, в свою очередь, может быть использован для переменной или столбца таблица. Отметим, что умолчание никак не проявляет себя при использовании пользовательских типов данных с определенным для них умолчанием для переменных. Тем не менее, во время применения пользова тельского типа данных для столбца таблицы умолчание ведет себя так же, как если бы оно было непосредственно связано со столбцом.

Необходимо отметить, что по заявлениям самой компании Microsoft умолчания являются морально устаревшими объектами, и, начиная с SQL Server 7.0, вместо них предлагается использовать ограничение целостности Default, которое указы вается на уровне столбца и включается непосредственно в структуру таблицы.

S28 Часть IV. Разработка и сопровождение баз данных Таким образом, в SQL Server 2000 значение по умолчанию может быть опреде лено двумя методами. Выбор того или иного метода зависит от пользователя.

Несмотря на предложение Microsoft отказаться от определения умолчаний как объектов базы данных, работа с ними имеет свои преимущества. Рассмотрим, какие же недостатки и достоинства имеет каждый из типов умолчаний.

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

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

Тем не менее, все же рассмотрим создание и применение умолчаний, реализо ванных в качестве самостоятельных объектов базы данных. Принятие же реше ния об их использовании (или не использовании) остается за читателем.

Итак, прежде всего, необходимо создать умолчание. Для этого служит команда CREATE DEFAULT, имеющая синтаксис:

CREATE DEFAULT d e f a u l t AS c o n s t a n t _ e x p r e s s i o n Команда имеет всего два обязательных параметра. С помощью первого указыва ется имя, которое будет присвоено умолчанию. С помощью второго аргумента задается собственне значение, которое будет присваиваться столбцу. Это значе ние может быть создано не только на основе констант, но и на основе функций.

Необходимо заметить, что при создании умолчания никаким образом не опре деляется, какой тип данных имеет указываемое значение. Поэтому следует быть внимательным при вводе выражения. Например, если предполагается использо Глава 18. Архитектура баз данных вать значение по умолчанию для символьных типов данных, то следует заклю чать его в одинарные кавычки. В противном случае сервер может по иному ин терпретировать значение. Например, если в качестве значения по умолчанию ука зывается строка 20-11-2000, то сервер будет воспринимать ее как формулу и вычислять. Хотя подобное умолчание и можно будет связать со столбцом, имею щим символьный тип данных, при добавлении строки в столбец будет вставлено значение -1991, а не 20-11-2000, как и требовалось. Решением проблемы будет заключение значения по умолчанию в кавычки — ' 20-11-2000'.

( Замечание ) При выборе имени умолчания нужно следовать стандартным правилам формирова ния имен объектов, описанных в разд. "Именование объектов" ранее в этой главе.

При необходимости можно использовать ограничители.

Например, в качестве значения по умолчанию можно указать функцию И СВЯЗатЬ уМОЛЧЭНИе СО СТОЛбцОМ O r d e r D a t e Таблицы O r d e r s базы GETDATEO данных Northwind, в котором хранится дата ввода заказа. В итоге пользователи смогут опускать значение для столбца OrderDate при добавлении новых заказов.


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

( Замечание ) Надо заметить, что при создании умолчаний нельзя ссылаться на объекты базы данных и переменные, а также использовать определяемые пользователем функ ции. Однако при работе с умолчаниями, реализованными как ограничения целост ности, разрешается применять пользовательские функции.

Рассмотрим, как же на практике осуществить приведенный пример. Сначала необходимо создать умолчание. Для этого выполним следующие команды:

USE Northwind CREATE DEFAULT def_GETDATE AS GETDATEO Затем остается только связать созданное умолчание со столбцом OrderDate таб лицы orders. Однако мы еще на рассматривали, как осуществляется связывание созданного умолчания со столбцом таблицы или с пользовательским типом данных. Для выполнения этой операции предназначена хранимая процедура:

sp_bindefault [ @defname = ] ' d e f a u l t ', [ Sobj name = ] ' obj ect_name' [, [ Sfutureonly = ] 'futureonly_flag' ] ( Замечание ) Связывать умолчание с таблицей могут только члены фиксированной роли сервера sysadmin, члены фиксированных ролей базы данных db_owner и db_ddladmin, a также владелец таблицы.

830 Часть IV. Разработка и сопровождение баз данных Рассмотрим параметры процедуры:

• [ @defname =~ ] ' d e f a u l t ' С помощью этого параметра указывается имя умолчания, которое предпола гается связать со столбцом таблицы или пользовательским типом данных.

О [ @objname = ] 'object_name' Этот же параметр служит для указания имени объекта, с которым связывается умолчание. Если имя указывается в формате tabie_name. column name, то ста нет выполняться связывание умолчания со столбцом таблицы. В противном случае будет предполагаться, что связывание необходимо выполнить с пользо вательским типом данных. В имени объекта допускается указание ограничите лей (квадратных скобок или двойных кавычек).

(~ Замечание ^ Умолчание не может быть связано со столбцом таблицы, имеющим тип данных timestamp, со столбцом-счетчиком (с установленным свойством IDENTITY). Кроме того, не разрешается связывать умолчание со столбцом, для которого было опреде лено значение по умолчанию как ограничение целостности. Когда же связывание осуществляется со столбцом или пользовательским типом данных, с которыми уже связано умолчание (объект базы данных), то происходит автоматическое отвязыва ние старого умолчания и привязывание нового.

О [ Sfutureonly = ] 'futureonly_flag' Этот необязательный параметр может иметь значение 'futureonly 1 или NULL. Указание значения 'futureonly 1 допускается только при связывании умолчания с пользовательским типом данных. Использование указанного значения позволяет не выполнять изменения в столбцах таблицы, имеющие пользовательский тип данных, с которым связывается новое значение по умолчанию. То есть для столбцов будет применяться старое значение по умолчанию. Однако при создании новых столбцов, имеющих пользователь ский тип данных, для них будет использоваться новое значение по умолча нию. Если же параметр @futureonly опускается или имеет значение NULL (которое и указывается для параметра по умолчанию), то будет выполнено обновление значений по умолчанию для всех столбцов, с которыми связан пользовательский тип данных.

С Замечание } Сервер не выполняет проверки на соответствие типа данных связываемого умолча ния с типом данных объекта. Поэтому пользователь обязан сам выполнять необхо димые проверки. Несоответствие типов обнаруживается только в момент вставки строки. Кроме этого, следует учитывать и наложенные на столбец таблицы правила и ограничения целостности. Значение по умолчанию не должно конфликтовать с ними, иначе вставка строки завершится неудачей.

Мы рассмотрели назначение параметров процедуры sp_bindefauit. Теперь можно связать созданное умолчание со столбцом OrderDate таблицы orders.

Для этого достаточно выполнить следующую команду:

EXEC spbindefault 'def_GETDATE', ' Orders. OrderDate • Глава 18. Архитектура баз данных Приведем также пример связывания умолчания defGETDATE с пользователь ским типом данных My data type:

EXEC sp_bindefault 'def_GETDATE', '[My d a t a t y p e ] ' Для полноты картины необходимо рассмотреть, как же осуществляется отвязы вание умолчания от столбца таблицы или пользовательского типа данных, а также как удалить умолчание из базы данных. Выполнение первой операции осуществляется с помощью системной хранимой процедуры sp_unbmdefauit, имеющей следующий синтаксис:

sp_unbindefault [ @objname = ] 'object_name' [, [ gfutureonly = ] 'futureonly_flag'] Рассмотрим параметры процедуры:

О [ @objname = ] 'object_name' С помощью этого параметра указывается имя объекта, от которого следует отвязать умолчание. Его использование ничем не отличается от работы с од ноименным параметром процедуры sp_bindefault, рассмотренным выше.

О [ gfutureonly = ) 'futureonly_flag' Этот необязательный параметр может иметь значение 'futureonly' или MULL. Указание значения 'futureonly' допускается только для пользователь ских типов данных. Его указание предписывает не изменять значение по умолчанию для столбцов, имеющих пользовательский тип данных, от кото рого отвязывается умолчание. При задании любого иного значения, а также когда параметр @futureoniy опускается или имеет значение NULL (которое и используется для параметра по умолчанию), то будет выполнено обновление значений по умолчанию для всех столбцов, с которыми связан пользователь ский тип данных.

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

EXEC sp_unbindefault 'Orders.OrderDate' Удаление же умолчаний выполняется с помощью команды DROP DEFAULT, имеющей синтаксис:

DROP DEFAULT { d e f a u l t } [,... n ] Единственный параметр этой команды определяет имя умолчания, которое не обходимо удалить. Как видно из синтаксиса, с помощью одной команды DROP DEFAULT можно удалить множество умолчаний. Для этого достаточно перечис лить их имена через запятую. Следует заметить, что нельзя удалить умолчание, связанное со столбцом таблицы или пользовательским типом данных. Дело в том, что сервер не выполняет автоматического отвязывания умолчания, поэтому пользователь должен вручную отвязать умолчание от всех объектов, а уже после этого удалять его.

Например, для удаления умолчания def_GETDATE достаточно выполнить команду.

DROP DEFAULT d e f GETDATE 832 Часть IV. Разработка и сопровождение баз данных Помимо рассмотренных операций работы с умолчаниями, иногда возникает не обходимость изменения существующего умолчания, что подразумевает модифи кацию собственно значения, которое будет присваиваться столбцу таблицы. Мы не рассмотрели команду, с помощью которой можно выполнять изменение умолчания. Дело в том, что такой команды нет. То есть в SQL Server 2000 не реализована возможность изменения умолчания. Таким образом, внесение из менений в умолчание может быть произведено только путем удаления его и по вторным созданием с новыми параметрами.

В некоторой степени помочь подобному изменению умолчания может хранимая процедура s p h e i p t e x t, позволяющая получить код команды CREATE DEFAULT, С помощью которой было создано умолчание. Например, для просмотра кода умолчания defGETDATE можно выполнить следующую команду:

sp_helptext 'def_GETDATE' В ответ будет получен примерно такой результат:

Text CREATE DEFAULT def_GETDATE AS GETDATEO Мы рассмотрели работу с умолчаниями средствами Transact-SQL. Однако в SQL Server 2000 имеется возможность работы с умолчаниями и средствами графиче ского интерфейса Enterprise Manager. В каждой базе данных существует папка Defaults (рис. 18.6), в которой перечислены все умолчания, созданные в базе данных. Именно с помощью этой папки и выполняется создание и удаление умолчаний, а также связывание их с пользовательскими типами данных или столбцами таблицы.

Как видно, для каждого умолчания указывается его имя, имя владельца и дата создания. Для образования нового умолчания необходимо в пустой области пра вой части окна щелкнуть правой кнопкой мыши и в открывшемся контекстном меню выбрать команду New Default. В ответ появится окно Default Properties (рис. 18.7).

В поле Name окна Default Properties указывается имя, которое будет иметь умолчание, тогда как в поле Value задается собственно значение, которое станет содержать умолчание. При работе с этими полями следует придерживаться тех же правил, что и при работе с командами Transact-SQL.

В момент создания умолчания нельзя выполнить его связывание с пользова тельскими типами данных или столбцами таблицы. Это видно из рис. 18.7, на котором недоступны кнопки Bind UDTs и Bind Columns, позволяющие, соответ ственно, выполнять связывание с пользовательскими типами данных и столбца ми таблиц. Активны указанные кнопки будут только при открытии окна свойств созданного умолчания. После нажатия кнопки Bind UDTs появится окно Bind Default to User-defined Data Types (рис. 18.8).

В столбце Name указано имя пользовательского типа данных. Системный тип данных, на основе которого создан тот или иной пользовательский тип данных, указывается в столбце Data Type. Установленный флажок в столбце Bind свиде Глава 18. Архитектура баз данных тельствует о связывании умолчания с соответствующим типом данных. Установ ка флажка в столбце Future Only позволяет не отображать на столбцах таблиц, уже имеющих соответствующий пользовательский тип данных, изменения, вы полняемые с типом данных. Окно Bind Default to User-defined Data Types может использоваться не только для связывания умолчания с пользовательским типом данных, но и для отвязывания его.

Mm Рис. 18.6. Папка Defaults РИС. 18.7. Окно Default Properties Часть IV. Разработка и сопровождение баз данных Рис. 18.8. Окно Bind Default to User-defined Data Types Рис. 18.9. Окмр Bind Default to Columns Глава 18. Архитектура баз данных Вернемся же к окну свойств умолчания. Нажав в нем кнопку Bind Columns, можно открыть окно Bind Default to Columns (рис. 18.9), с помощью которого выполняется связывание умолчания со столбцами таблиц базы данных.

В раскрывающемся списке Table выбирается имя таблицы, со столбцом которой необходимо связать умолчание. В списке Unbound columns перечислены столбцы таблицы, связанные с конфигурируемым умолчанием. Перенося имена столбцов в список Bound columns, вы тем самым связываете умолчание с соответствую щим столбцом выбранной таблицы.

( Замечание ) Необходимо отметить, что когда в Enterprise Manager открывается окно свойств соз данного умолчания, то имеется возможность изменить собственно значение, кото рое будет присваиваться столбцам таблиц. Однако изменение можно будет выпол нить только в том случае, если умолчание не связано ни с одним объектом базы данных. Это происходит из-за того, что изменение умолчания осуществляется путем удаления существующего и последующим созданием нового умолчания. Однако, как уже было сказано, нельзя удалить умолчание, связанное хоть с одним объектом.

На этом рассмотрение работы с объектами базы данных типа Defaults можно считать оконченным.

Правила Правила (rules) представляют из себя объекты базы данных, содержащие логиче ские условия, с помощью которых можно выполнить проверку значений на со ответствие определенным требованиям. Например, при работе с процентами с помощью правила можно выяснить, что указываемое значение лежит в пределах от 0 до 100. В SQL Server 2000 нет встроенных типов данных, которые обеспечи вали бы хранение значений только в диапазоне от 0 до 100. Самый близкий тип данных t i n y i n t позволяет хранить значения в диапазоне от 0 до 255. Поэтому, чтобы быть уверенным, что значение лежит в диапазоне от 0 до 100, необходимо использовать дополнительные механизмы.

Одним из таких механизмов и являются правила. Однако правила, как и умол чания, представляют собой устаревший тип объектов. Правила активно исполь зовались в SQL Server 6.x и более ранних версиях, но начиная с SQL Server 7.0, в распоряжении пользователей появился более мощный механизм — ограниче ние целостности Check.

Контроль значений с помощью ограничения целостности Check предоставляет пользователям более широкие возможности. В частности, для одного столбца можно определить множество ограничений целостности Check, тогда как при использовании правил для столбца разрешается указывать всего одно правило.

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

Когда пользователь пытается добавить в таблицу новую строку или изменить существующую, сервер проверяет, не связано ли со столбцами какое-либо пра 836 Часть IV. Разработка и сопровождение баз данных вило. Если таковые имеются, то берется значение столбца и проверяется на со ответствие правилу. Сравнение осуществляется путем подстановки значения столбца в логическое условие, на основе которого и определено правило. Если значение столбца соответствует условию, то после вычисления логического вы ражения возвращается значение TRUE (истина), и операция вставки или измене ния строки разрешается. В противном случае возвращается значение FALSE (ложь), и попытка пользователя вставить или изменить строку откатывается с выдачей соответствующего сообщения об ошибке. Если со столбцом связано правило, и определено одно или более ограничений целостности CHECK, TO зна чение проверяется на соответствие всем им. Только если значения всех столб цов соответствуют всем определенным для них ограничениям целостности CHECK и правилам, будет разрешена вставка или изменение данных.

Работа с правилами во многом напоминает работу с умолчаниями. Пользователь должен сначала создать правило как объект базы данных, а затем связать его со столбцом таблицы или пользовательским типом данных. Рассмотрим же, какие команды и хранимые процедуры используются при работе с правилами.

Замечание Как и при работе с умолчаниями, правила не отражаются на работе с локальными переменными, имеющими пользовательский тип данных. Правило проявляет себя только для столбцов таблицы.

Создание правил выполняется с помощью команды CREATE RULE, которая имеет синтаксис:

CREATE RULE rule AS cendition_expression С помощью первого аргумента определяется имя, которое будет иметь правило.

При выборе имени следует придерживаться стандартных правил именования объ ектов, рассмотренных ранее в этой главе. При необходимости можно использовать ограничители. Собственно логическое условие, которое будет выступать для про верки значений, указывается с помощью параметра c o n d i t i o n e x p r e s s i o n.

В логическом условии можно использовать одну локальную переменную, вместо которой сервер будет подставлять значение столбца. Собственно имя перемен ной не играет значения. Скажем только, что имена локальных переменных на чинаются с символа д. Допускается указание множества логических условий, связываемых в одно целое операторами AND И OR.

В качестве примера рассмотрим создание правила, выполняющего проверку значения на принадлежность к интервалу от 0 до 100:

CREATE RULE rule0_100 AS @value=0 AND @value=100, Отметим, что в правиле никаким образом не задается тип проверяемого значения.

Поэтому на вход правила могут подаваться значения любых типов. Ограничения на тип данных накладывают операторы, используемые в логическом условии.

Указание переменной в логическом условии требуется обязательно. Однако можно построить выражение таким образом, что собственно проверяемое зна чение не будет играть никакой роли, а все будет зависеть, например, от значе Глава 18. Архитектура баз данных ний, возвращаемых функцией. Следующий пример демонстрирует создание правила, зависящего только от значения, возвращаемого функцией GETDATE ().

Если текущее число меньше 15, то правило вернет значение TRUE, И выполнение изменения или вставки строки будет разрешено.

CREATE RULE rulel AS DATEPARTIdd, GETDATE())15 AND @a=@a Можно также создать правило, которое будет разрешать вставку или изменение строк только из соединений, установленных с компьютеров L I T, DM И STORAGE, И И соединений, установленных пользователями MATRIX\Administrator И И за:

Л Л C R E A T E RULE r u l e 2 A S ( H O S T _ N A M E ( ) I N ( ' L I T, ' D M ', 'STORAGE') OR SUSER SNAMEf) I N ( ' M A T R I X X A d m i n i s t r a t o r ', 'sa')) AND @a=@a Замечание В обоих последних приведенных примерах проверяемое значение не играет никакой роли, поэтому правило может быть связано с любым столбцом таблицы.

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

sp_bindrule [ @rulename = 1 ' r u l e ', [ Sobjname = ] 'object_name' [, [ @futureonly = ] 'futureonly_flag' ] Л Замечание Связывать правило с таблицей могут только члены фиксированной роли сервера sysadmin, члены фиксированных ролей базы данных db owner и db ddladmin, a также владелец таблицы.

Назначение параметров этой процедуры, а также работа с ними полностью со ответствуют процедуре sp bindefauit, работа с которой была рассмотрена в предыдущем разделе.

В качестве примера рассмотрим связывание правила r u l e l с пользовательским типом данных муот:

spjoindrule 'rulel', 'MyDT' Отвязывание правила от объекта выполняется с помощью процедуры s p u n b i n d r u i e, имеющей синтаксис:

sp_unbindrule [@objname =] 'object_name' [, [Sfutureonly =] 'futureonly_flag'] Удаление же правила осуществляется с помощью команды:

DROP RULE { r u l e } [,...n ] Единственный параметр этой команды предназначен для указания имени пра вила, которое необходимо удалить. Если надо удалить более одного правила, то достаточно перечислить их имена через запятую.

Часть IV. Разработка и сопровождение баз данных Для получения кода команды CREATE RULE, С ПОМОЩЬЮ которой было создано правило, можно использовать процедуру s p h e i p t e x t. Например, для получе ния кода правила rule2 необходимо выполнить команду:

sp_helptext 'rule2' Будет получен примерно следующий результат:

Text CREATE RULE rule2 AS (HOST_NAME() IN ('LIT, 'DM', 'STORAGE'} OR SUSER_SNAME() IN ('MATRIXYAdministrator', 'sa')) AND §a=8a Управление же правилами средствами Enterprise Manager выполняется с помо щью папки Rules (рис. 18.10), имеющейся в каждой базе данных.

Рис. 18.10. Папка Rules Для создания нового правила достаточно щелкнуть в пустом месте правой части окна правой кнопкой мыши и в открывшемся контекстном меню или непосред ственно в контекстном меню папки Rules выбрать пункт New Rule. В результате появится окно Rule Properties (рис. 18.11), с помощью которого собственно и создается правило.

Глава 18. Архитектура баз данных Рис. 18.11. Окно Rule Properties В поле Name вводится имя, которое будет присвоено создаваемому правилу. В поле Text указывается логическое условие, которое будет использоваться для проверки значений столбцов. То есть должен быть приведен тот же текст, что задается для параметра condition_expression команды CREATE RULE.

Как и при работе с умолчаниями, в нижней части окна Rule Properties имеются кнопки Bind UDTs и Bind Columns, с помощью которых соответственно осуще ствляется связывание правила с пользовательскими типами данных и столбцами таблиц. Мы не будем рассматривать выполнение этих операций, т. к. они прак тически ничем не отличаются от связывания умолчаний, которое было рассмот рено в предыдущем разделе.



Pages:     | 1 |   ...   | 20 | 21 || 23 | 24 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.