SQL Server 2000

самой базы данных, удаляется из системных таблиц SQL Server и, таким

образом, сервер перестает ее воспринимать. Позже эту базу данных можно

присоединить (attach) на этом же или другом сервере.

Отсоединение и присоединение в основном используются для переноса баз

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

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

резервное копирование базы данных и разослать копии. Другой способ —

выполнить отсоединение базы данных и разослать пользователям все ее

файлы. У себя на сервере пользователи смогут выполнить присоединение базы

данных и сразу же начать работать с ней. Процедура отсоединения и

присоединения занимает гораздо меньше времени, чем создание и

восстановление резервной копии. Кроме того, отсоединенную базу данных

можно записать на компакт-диски и разослать пользователям. Пользователи

смогут работать с базой данных непосредственно с компакт-диска в режиме

«только для чтения». Такой подход особенно эффективен при рассылке

каталогов, которые не должны изменяться.

Если планируется скопировать базу данных на компакт-диск,

предварительно необходимо установить все ее группы файлов в режим «только

для чтения». Для этого используется команда ALTER DATABASE MODIFY

FILEGROUP filegroup_name READONLY.

Выполнять операции присоединения и отсоединения базы данных могут

только члены фиксированной роли сервера sysadmin. Эти права не могут быть

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

эту фиксированную роль сервера.

Для отсоединения базы данных используется следующая хранимая процедура:

sp_detach_db [@dbname =] "dbname" [, [@skipchecks =] "skipchecks"]

Аргумент "dbname" указывает имя базы данных, которую необходимо

отсоединить. Аргумент "skipchecks" управляет обновлением статистики при

отсоедине-

нии. Если значение этого аргумента равно TRUE, то обновление статистики

пропускается, если же указывается FALSE, то обновление статистики будет

выполнено. Для отсоединения базы данных pubs нужно использовать следующую

команду:

ЕХЕС sp_detach_db "pubs"

После отсоединения базы данных вы получаете в свое распоряжение набор

обычных файлов, с которыми можно выполнять обычные операции, в том числе

и архивирование с использованием утилиты NT Backup.

Для присоединения отсоединенной базы данных используется системная

хранимая процедура sp_attach_db:

sp_attach_db [@dbname =] "dbname", [(Pfilenamel =] "filenameji"

[,...16]

Аргумент "filename_n" должен содержать полный путь к первичному файлу

присоединяемой базы данных. Описание остальных файлов базы данных

хранится в первичном файле. Если положение этих файлов было изменено, то

необходимо явно указать их положение при вызове хранимой процедуры —

через запятую в аргументе "f i lename_n".

Количество файлов, которое можно присоединить с помощью хранимой

процедуры sp_attach_db, ограничивается 16. Если необходимо выполнить

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

команда CREATE DATABASE FOR ATTACH.

Для присоединения базы данных pubs нужно выполнить следующую команду:

sp_detach_db"pubs".

"d:\mssql\data\pubs.mdf" .

"d:\mssql\data\pubs_log.Idf"

Если база данных состоит из одного файла данных и одного файла журнала

транзакций, то ее можно присоединить, указав только первичный файл. База

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

sp_detach_db. Для присоединения такой базы данных используется следующая

хранимая процедура:

sp_attach_sing1e_file_db [@dbname =] "dbname".

[@physname =] "physicaljiame"

Сервер автоматически создаст для базы данных файл журнала транзакций и

выполнит удаление из базы данных поддержку репликации, если она была

установлена.

Для присоединения базы данных pubs с использованием только первичного

файла необходима следующая команда: sp_attach_single_file_db "pubs",

"d:\mssql\data\pubs.mdf"

Передача прав владения

Если администратор баз данных вашей компании увольняется и ему на смену

приходит другой человек, необходимо передать права владения всеми

объектами, включая базы данных, новому администратору.

Для передачи прав владения базой данных от одного пользователя другому

используется следующая хранимая процедура:

sp_changedbowner [(Ploginame =] "login"

[,[@map =] remap_al1as_f1ag]

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

[Ologiname =] "login". Имя учетной записи пользователя, которого

требуется сделать владельцем базы данных. Эта учетная запись не должна

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

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

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

пользователя базы данных.

О [map =] remap_al i as_fl ag. Этот аргумент может принимать значение

TRUE или FALSE. Значение TRUE означает, что учетная запись старого

владельца базы данных будет отображаться в учетную запись нового

владельца. Если задано FALSE, учетная запись старого владельца

уничтожается. Если этот аргумент опускается, то есть принимает значение

NULL, то все существующие dbo будут отражены в учетную запись нового

владельца базы данных. Хранимая процедура sp_changedbowner должна

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

изменить. Например, для изменения владельца базы данных KHSU необходимо

выполнить следующую команду:

USE khsu

EXEC sp_changedbowner "MATRIXXAdmlnistrator"

Изменение имени базы данных

При рассмотрении команды ALTER DATABASE мы уже говорили, что она

позволяет изменить имя базы данных. Однако для изменения имени базы

данных также можно использовать следующую хранимую процедуру:

sp_renamedb [@old_name =] "old_name". [@new_name =] "new_name"

Аргумент "old_name" должен содержать старое имя базы данных. Новое же

имя указывается с помощью аргумента "new_name".

Права на выполнение этой хранимой процедуры имеют только члены

фиксированной роли сервера sysadmin.

Просмотр свойств базы данных

Часто бывает необходимо получить исчерпывающую информацию о структуре и

параметрах базы данных. В этом разделе будут рассмотрены средства

Transact-SQL, с помощью которых можно получить различную информацию о

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

установленных с помощью хранимой процедуры sp_dboption или средствами

Enterprise Manager, можно использовать системную хранимую процедуру

sp_dboption с указанием только имени базы данных. Например, для получения

информации о параметрах базы данных pubs можно выполнить следующую

команду: EXEC sp_dbopt1on "pubs"

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

The following options are set:

published

trunc. log on chkpt. torn page detection auto create statistics auto update

statistics

Как видно, возвращается список только тех параметров, которые были

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

указать не только имя базы данных, но и имя интересующего параметра

конфигурации:

ЕХЕС spjboption "pubs", "ANSI null default"

В результате выполнения этой команды будет получен примерно следующий

результат:

OptionName CurrentSetting

ANSI null default off

Если выполнить хранимую процедуру sp_dboption вообще без аргументов, то

она выдаст список всех доступных параметров конфигурации:

Settable database options:

ANSI null default

ANSI nulls

ANSI padding

ANSI warnings

arithabort

auto create statistics

auto update statistics

autoclose

autoshrink

concat null yields null

cursor close on commit

dbo use only

default to local cursor

merge publish

numeric roundabort

offline

published

quoted identifier

read only

recursive triggers

select into/bulkcopy

single user

subscribed

torn page detection

trunc. log on chkpt.

Помимо хранимой процедуры sp_dboption для получения значения тех же и

некоторых дополнительных параметров конфигурации можно использовать

следующую команду: DATABASEPROPERTY("database_name". "property")

Аргумент database_name должен содержать имя базы данных, свойства которой

необходимо просмотреть. Возможные значения аргумента property и их

назначение перечислены в табл. 14.2.

Таблица Аргументы команды DATABASEPROPERTY

Аргумент

IsAnsiNullDefault

IsAnsiNullEnabled

IsAnsiWarningEnabled

IsAutoClose

IsAutoShrink

IsAutoUpdateStatistics

IsBulkCopy

IsCloseCursorOnCommit-Enabled

IsDboOnly

IsDetached

IsEnergencyMode

IsFulltextEnabled

IsInLoad

IsInRecovery

IsInStandby

IsLocalCursorsDefault

IsNotRecovered IsNullConcat

IsOffline IsQuotedldentifiersEnabled

leReadOnly

IsRecursiveTriggersEnabled

IsShutDown

Назначение

Аналог аргумента "ANSI null default" процедуры sp_dboption

Аналог аргумента "ANSI nulls" процедуры sp_dboption

Аналог аргумента "ANSI warning" процедуры sp_dboption

Аналог аргумента "autoclose" процедуры sp_dboption

Аналог аргумента "autoshrink" процедуры sp_dboption

Аналог аргумента "auto update statistic" процедуры sp_dboption

Аналог аргумента "select into/bulk copy" процедуры sp_dboption

Аналог аргумента "cursor close on commit" процедуры spjdboption

Аналог аргумента "dbo use only" процедуры sp_dboption

База данных отделялась командой sp_detach

Разрешение работы с «подозрительной» базой

Поддержка полнотекстового поиска

База данных была загружена из резервной копии

Выполняется восстановление базы данных

База данных работает в режиме «только для чтения»

Аналог аргумента "default to local cursor" процедуры sp_dboption

Восстановление базы данных завершилось с ошибкой

Аналог аргумента "concat null yields null" процедуры sp_dboption

Аналог аргумента "offline" процедуры sp_dboption

Аналог аргумента "quoted identifier" процедуры sp_dboption

Аналог аргумента "read only" процедуры sp_dboption

Аналог аргумента "recursive triggers" процедуры sp_dboption

В базе при запуске сервера возникают ошибки__

продолжение &

Таблица (продолжение)

Аргумент Назначение

IsSingleUser Аналог аргумента "single user" процедуры

sp_dboption

IsSuspect Имеются сомнения в целостности базы данных

IsTruncLog Аналог

аргумента "trunc. log on chkpt." процедуры

sp_dboption

Version Внутренний номер версии сервера SQL Server,

________________________ на котором была создана база

данных_________

Результатом выполнения команды DATABASEPROPERTY будет либо значение О,

соответствующее значению FALSE или OFF хранимой процедуры sp_dbopt1 on,

либо значение 1, соответствующее значению TRUE или ON. Исключением из

правила является значение, возвращаемое для параметра Version. Для этого

параметра возвращается значение типа int, которое может принимать любое

положительное значение. Если значение параметра не определено, то команда

вернет значение NULL.

Приведем пример использования команды DATABASEPROPERTY для получения

информации о режиме слияния двух значений NULL, установленном для базы

данных pubs: SELECT DATABASEPROPERTY ("pubs", " IsNullConcat")

Сервер вернет примерно следующий результат:

О

(1 row(s) affected)

Для получения некоторой общей информации о базе данных можно

использовать следующую хранимую процедуру: spjielpdb [[@dbname=] "name"]

Эта хранимая процедура выдает информацию о текущем размере базы данных

с точностью до десятков килобайт, имя учетной записи, являющейся

владельцем базы данных, идентификационный номер базы данных, дату

создания базы данных и ее текущий статус. Кроме того, эта хранимая

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

имя файла базы данных, его идентификационный номер в базе данных, текущий

и максимальный размер, шаг приращения, а также принадлежность к той или

иной группе файлов.

Для получения информации о файлах базы данных из хранимой процедуры

spjielpdb происходит вызов хранимой процедуры sp_helpfile, которая и

выдает информацию о параметрах файла. Поэтому формат результата

выполнения этих хранимых процедур одинаков. Более подробно формат данных

будет рассмотрен ниже.

Для получения информации о базе данных pubs можно использовать

следующую команду:

ЕХЕС spjielpdb "pubs"

Объем информации, возвращаемый этой командой, достаточно велик, поэтому

возможности привести эту информацию в книге нет. Однако вы можете

выполнить указанную команду в Query Analyzer и посмотреть, что же будет

выдано в ответ.

Для получения информации о конкретном файле базы данных можно

использовать следующую хранимую процедуру: sp_helpfile [[^filename = ]

"name"]

Эта процедура выдает информацию о файле в следующих столбцах: О Name —

логическое имя файла в базе данных;

О Filename— физическое имя файла в операционной системе, которое включает

полный путь к файлу;

О Filegroup— имя группы файлов, к которой принадлежит файл;

О Si ze — текущий размер файла;

О Maxsize— максимальный размер файла, установленный при его создании;

О Growth — шаг прироста размера файла;

О Usage— тип использования файла; возможно одно из двух значений: data

only (файл используется для хранения данных) или log on!у (файл

используется для хранения журнала транзакций).

Для получения информации о группе файлов можно использовать следующую

хранимую процедуру: sp_helpfilegroup [[Ofilegroupname =] "name"]

Эта хранимая процедура выполняется в контексте базы данных, информацию

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

выдана информация об идентификационном номере группы, количестве

включенных в нее файлов, а также информация о самих файлах.

Для получения информации о группе файлов PRIMARY базы данных pubs можно

использовать следующую команду: ЕХЕС sp_helpf11egroup "primary"

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

fllecount

PRIMARY 1 1

f11e_in_group fileid filename size maxsize growth

pubs 1 pubs.mdf 2688 KB Unlimited Ш

В столбце Filename будет указан полный путь к файлу.

Для просмотра информации об использовании пространства внутри базы

данных можно применить следующую, системную хранимую процедуру:

sp_spaceused [[@objname =] "objname"] [, [@updateusage =]

"updateusage"]

Аргумент "objname" содержит имя таблицы базы данных, о которой

необходимо получить информацию. Аргумент "updateusage" управляет

выполнением команды DBCC UPDATEUSAGE и может принимать значения TRUE или

FALSE.

Если процедура sp_spaceused запускается без аргументов, то будет

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

В результате выполнения sp_spaceused в контексте базы данных pubs будет

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

database_name

pubs

reserved data

database_s1ze 3.63 MB

Index size

unallocated space 1.10 MB unused

2584 KB 1120 KB 1288 KB 176 KB

Как видно, результат состоит из двух наборов. В столбце database_name

указано имя базы данных, о которой выводится информация, в столбце

database_s1 ze — первоначальный размер базы данных, а в столбце unal I

ocated space— пространство, которое было освобождено при сжатии.

В столбце reserved отображается сумма зарезервированного для базы данных

пространства (database_size - "unallocated space" = data + index_size +

unused). В столбце data указан объем памяти, занимаемый данными, а в

столбце index_size— объем памяти, занимаемый индексами. Размер свободного

пространства в базе данных выводится в столбце unused.

Чтобы получить информацию об использовании пространства в таблице

titleauthor, можно использовать следующую команду: ЕХЕС sp_spaceused "

titleauthor"

В результате процедура выдаст примерно следующее:

name rows reserved data index_size unused

titleauthor 25 48 KB 8 KB 40 KB 0 KB

В столбце name указано имя таблицы, о которой выводится информация, а в

столбце rows — число строк данных, которое введено в таблице. Объем памяти,

выделенный в базе данных для таблицы, указывается в столбце reserved (data

+ index_s1ze + unused). В столбце data указан объем памяти, занимаемой

данными, хранящимися в таблице, а в столбце i ndex_si ze — объем памяти,

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

unused

Для получения информации о журнале транзакций Transact-SQL предлагает

команду DBCC SQLPERF, выдающую информацию об использовании журналов

транзакций в каждой из баз данных, созданных на сервере.

Для получения информации об использовании журналов транзакций нужно

выполнить следующую команду: DBCC SQLPERF (LOGSPACE)

В результате будет выдана следующая информация: DatabaseName

LogSize(MB) Log Space Used ( % ) Status

|Samp! e_3 |1.9921875 |33.039215 |0 |

|Sample_2 |1.9921875 |34.264706 |0 |

|Sample 1 |1.9921875 |33.553921 |0 |

|Distributi|0.9921875 |56.98819 |0 |

|on | | | |

|Abba |0.9921875 |38.877953 |0 |

|Northwi nd|0.9921875 |46.948818 |0 |

| | | | |

|Pubs |0.9921875 |55.610237 |0 |

|Msdb |2.4921875 |35.442791 |0 |

|Tempdb |0.4921875 |85.079521 |0 |

|Model |0.7421875 |45.328949 |0 |

|Master |1.2421875 |34.709118 |0 |

(12 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your

system administrator.

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

таблицах. Хранимые процедуры обращаются к этим таблицам и возвращают

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

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

процедуры, Microsoft настоятельно советует не прибегать к прямому обращению

к системным таблицам, так как их структура может быть изменена в следующих

версиях, и поэтому программы, успешно работающие с одной из версий SQL

Server, могут работать неправильно или вообще не работать со следующими

версиями этой СУБД. При использовании хранимых процедур Microsoft

гарантирует, что совместимость будет сохранена.

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

хранится описание физической структуры базы данных.

Список файлов базы данных хранится в системной таблице sysfiles. Каждая

строка этой таблицы соответствует одному файлу базы данных. Таблица

sysfiles является виртуальной и не может быть изменена непосредственно с

помощью команд DELETE, UPDATE или INSERT. Тем не менее, пользователи могут

считывать данные из этой таблицы, используя команду SELECT. Структура

таблицы sysf i I es приведена в табл. 14.3.

Таблица. Структура системной таблицы sysfiles

|Имя |Тип данных|Назначение |

|столбца | | |

|Field |Smallint |Идентификационный номер (ID) файла |

| | |в базе данных |

|GroupID |Smallint |ID группы файлов, к которой |

| | |принадлежит файл |

|Size |Int |Текущее количество страниц в файле |

|Maxsize |Int |Максимальный размер файла. Значение|

| | |-1 означает, |

| | |что размер файла не ограничен |

|Growth |Int |Шаг приращения |

|Status |Int |Текущий статус файла |

|Perf |Int |Зарезервировано |

|Name |Nchar(128)|Логическое имя файла |

| | | |

|Filename |Nchar(260)|Физическое имя файла |

| | | |

Таблица sysf lies описывает подробную структуру файлов. Более компактное

описание файлов хранится в таблице sysfilesl, которая содержит столбцы

status, field, name и filename, назначение которых аналогично. Для

просмотра информации о файлах базы данных с помощью таблицы sysfilesl можно

выполнить следующую команду: SELECT * FROM sysfilesl

В итоге будет возвращен следующий результат:

status fileid name filename

3 1 pubs ...\data\pubs.mdf

49218 2 pubsjog ...\data\pubs_log.ldf

(2 row(s) affected)

Описание групп файлов, созданных в базе данных, хранится в системной

таблице sysfilegroups. Каждая строка этой таблицы соответствует одной

группе. Структура этой таблицы приведена в табл.

Таблица. Структура таблицы sysfilegroups

|Имя |Тип |Назначение | |

|столбца |данных | | |

|GroupID |Smallint |Идентификационный номер |DEFAULT|

|Allocpol|Smallint |группы файлов Зарезервировано| |

|icy |Ins |Текущий статус группы: 0x8— | |

|Status |Sysname |READONLY, 0x10 — Имя группы | |

|Groupnam| |файлов | |

|e | | | |

Например, для получения информации о группах файлов, определенных в базе

данных pubs, можно использовать следующий запрос:

SELECT * FROM sysfilegroups

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

groupld allocpolicy status groupname

1 0 16 PRIMARY

(1 row(s) affected)

Удаление базы данных

Для удаления базы данных используется следующая команда: DROP DATABASE

databasejiame [,...n]

Аргумент database_name указывает имя базы данных, которую необходимо

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

имена через запятую.

Например, для удаления баз данных Pubs и Northwind нужно выполнить

следующую команду: DROP DATABASE Pubs. Northwind

Управление пользовательскими типами данных

В главе 5 в разделе «Типы данных» были рассмотрены встроенные в SQL Server

2000 типы данных. Эти типы данных всегда имеются в распоряжении

пользователей и могут быть использованы для столбцов таблиц,

представлений, переменных и т. д. Однако помимо встроенных типов данных

пользователи могут на их основе создавать свои собственные типы данных —

так называемые пользовательские типы данных.

Пользовательские типы данных (user-defined data type) — это типы данных,

создаваемые пользователями. Они создаются на основе системных типов

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

нескольких таблицах необходимо хранить однотипные значения, причем

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

данных и чувствительность к данным NULL. Например, с помощью

пользовательского типа данных можно хранить номера и серии паспорта.

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

хранимая процедура sp_addtype:

sp_addtype [ @typename = ] type. [ @phystype = ] system_data_type [ .

[ @nulltype = ] "null_type" ] [ , [ @owner = ] "owner name" ]

Если необходимо сделать пользовательский тип данных доступным во всех

создаваемых базах данных, добавьте этот тип в базу данных model.

Здесь используются следующие аргументы.

О type — имя создаваемого типа данных. При выборе имени создаваемого типа

данных необходимо следовать установленным правилам именования объектов.

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

именами других объектов. Разные пользователи могут употреблять

одинаковые имена для создаваемых объектов.

О system_data_type — системный тип данных, на основе которого создается

пользовательский тип данных. Можно выбрать один из следующих типов

данных:

"binary(n)" Image smalldatetime

Bit Int smallint

"char(n)" "nchar(n)" ' text

Datetime Ntext tinyint

Decimal Numeric uniqueidentifier

"decimal[(p[,s])]" "numeric[(p[,s])]" "varbinary(n)"

Float "nvarchar(n)" "varchar(n)"

"float(n)" Real

Кавычки необходимы, когда помимо самого типа данных требуется указание

дополнительных параметров. Аргумент п идентифицирует длину системного

типа данных в пользовательском типе данных, аргумент р — максимальное

суммарное (до и после десятичной точки) количество цифр для числовых

типов данных в пользовательском типе данных, аргумент s — максимальное

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

данных.

Нельзя создать пользовательский тип данных на основе системного типа

timestamp.

О "null _type". Значение этого аргумента определяет, будет ли

пользовательский тип данных хранить значения NULL Аргумент null_type

имеет тип varchar(S) и может принимать одно из трех следующих значений:

NULL (разрешается хранение NULL), NOT NULL (хранение NULL запрещается)

или NONULL (используется значение по умолчанию). Если аргумент

null_type не указывается, то при создании пользовательского типа

используется значение по умолчанию, установленное для базы данных с

помощью системной хранимой процедуры sp_dboption. Текущее значение,

установленное в базе данных, можно получить с помощью функции

GETANSINULL

Значение аргумента null_type требуется для пользовательского типа данных

только как значение по умолчанию при создании столбца таблицы. Если при

создании столбца явно определено свойство NULL или NOT NULL, то значение

аргумента null_type игнорируется.

О "owner_name". Определяет владельца или создателя нового типа данных. По

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

Параметр owner_name имеет тип данных sysname.

Например, при создании пользовательских типов данных для описания номеров

факса и телефона можно использовать следующий код: ЕХЕС sp_addtype

telephone, "varchar(24)", "NOT NULL" EXEC sp_addtype fax, "varchar(24)",

"NULL"

Хранимая процедура sp_addtype добавляет описание типа в системную таблицу

systypes текущей базы данных. В принципе, если посмотреть на эту таблицу,

то можно заметить, что в ней также перечислены встроенные типы данных. То

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

данных являются пользовательскими, но имеющими те же свойства и имена,

что и встроенные. Например, выберем из таблицы systypes базы данных pubs

список доступных типов данных:

SELECT name FROM systypes

Будет возвращен следующий результат:

name

image

text

uniqueidentifier

tinyint

smallint

int

smalldatetime

real

money

datetime

float

sql_variant

ntext

bit

decimal

numeric

small money

bigint

varbinary

varchar

binary

char

timestamp

nvarchar

nchar

sysname

id

tid

empid

(29 row(s) affected)

Как видно, в одной таблице перечислены и встроенные, и пользовательские

типы данных (i d, ti d и emi d).

Управление правилами

Правила (rules) являются одним из средств обеспечения целостности данных,

хранящихся в базе. Правила оставлены для обеспечения обратной

совместимости с предыдущими версиями SQL Server. В новой версии они

заменены ограничениями целостности CHECK, которые являются более мощным

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

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

таблиц. В этом разделе будут рассмотрены правила как самостоятельные

объекты базы данных.

Для столбца таблицы можно определить только одно правило, но несколько

ограничений целостности CHECK. Если для одного столбца определены

ограничения целостности и правило, то будут учитываться как ограничения

целостности, так и правило.

Создание правила не может выполняться в одном пакете с другими

командами Transact-SQL.

Для создания правила используется следующая команда Transact-SQL:

CREATE RULE rule AS condition_expression

Рассмотрим аргументы команды. О rule— имя правила. При выборе имени

необходимо придерживаться общих

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

владельца.

О condition_expression — логическое выражение, определяющее условие,

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

логические команды, арифметические операторы, встроенные функции и

предикаты (например IN, BETWEEN, LIKE). В выражении condition_expression

нельзя ссылаться на столбцы таблиц или на любые другие объекты базы

данных. Встроенные функции также не должны ссылаться на объекты базы

данных. В выражении допустима одна локальная переменная, начинающаяся с

символа @. В качестве имени переменной можно использовать произвольную

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

которое пользователь пытается ввести в столбец с помощью команды INSERT

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

Приведем пример создания правила: CREATE RULE rule_one AS @val>=100 AND

(ava1<170 CREATE RULE rule_two AS

(Plist IN ("MATRIX". "ACC", "SIS", "KIT")

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

правило не выполняет контроля данных. Созданное правило необходимо

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

может быть связано с системным типом данных и столбцами, имеющими типы

данных timestamp, text и image. При связывании правила со столбцом

таблицы или пользовательским типом данных следует убедиться, что тип

данных в правиле и в объекте привязки совпадают. Сервер не отслеживает

соответствия типов данных при связывании. Ошибка выдается только тогда,

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

правила. Строго говоря, сервер вообще не выполняет проверки соответствия

типов, он лишь констатирует ошибку при сравнении величин, имеющих

несовместимый тип.

Для связывания правила со столбцом таблицы или пользовательским типом

данных используется хранимая процедура sp_bindru1e со следующим

синтаксисом:

sp_b1ndrule [@ru1ename =] "rule". [@objname =] "objectjname" [.

[@futureonly =] "futureonlyjflag"]

Назначение параметров процедуры sp_bindrule соответствует назначению

аналогичных параметров хранимой процедуры sp_bindef ault, описанной в

предыдущем разделе.

Для «отвязывания» правила используется хранимая процедура sp_unbindrule:

sp_unb1ndrule [@objname =] "object_name" [. [@futureonly =]

"futureonly_flag"]

Для получения сведений о правиле (имени владельца и даты создания)

используйте хранимую процедуру sp_hel p с указанием в качестве аргумента

имени правила: sp_he1p "rule_name"

Для получения текста кода Transact-SQL, определяющего правило,

используйте хранимую процедуру sp_helptext: sp_helptext "rule_name "

Для изменения имени правила используйте хранимую процедуру sp_rename:

sp_rename @objname='rule_one' @newname='rule_two'

Управление умолчаниями

Умолчание (default) — это значение, которое будет присвоено столбцу

таблицы при вставке строки, если в команде вставки явно не указано

значение для этого столбца.

Как и правила, умолчания оставлены в SQL Server 2000 для обеспечения

обратной совместимости с предыдущими версиями продукта (до версии SQL

Server 7.0). Версия SQL Server 2000 позволяет задавать умолчания для

столбцов таблицы или пользовательского типа данных при их создании,

используя ключевое слово DEFAULT. Применение умолчаний и правил как

отдельных объектов базы данных было вызвано невозможностью изменения

таблиц до версии SQL Server 7.0. Было гораздо проще создать новое правило

или умолчание, чем удалять таблицу и создавать ее заново. Так как версии

SQL Server 7.0 и 2000 разрешают свободно изменять структуру таблиц, то

надобность в правилах и умолчаниях как отдельных объектах отпала сама

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

необходимости использовать устаревшие конструкции, подобные правилам и

умолчаниям. К тому же нет абсолютно никакой гарантии, что Microsoft будет

поддерживать эти объекты в следующих реализациях SQL Server, так что при

использовании правил и умолчаний перед вами рано или поздно встанет вопрос

об изменении структуры базы данных.

Сейчас мы рассматриваем умолчания, которые существуют в базе данных как

самостоятельные объекты. Умолчания предоставляют удобный способ быстро

назначать одинаковые значения по умолчанию множеству столбцов таблиц базы

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

рекомендуется, используя синтаксис команд CREATE TABLE и ALTER TABLE.

Созданное умолчание само по себе не выполняет никаких действий. Его

необходимо связать с каким-нибудь столбцом таблицы или пользовательским

типом данных. Тип данных умолчания должен соответствовать типу данных,

установленному для столбца, с которым связывается умолчание.

Для создания умолчания используется следующая команда: CREATE DEFAULT

default AS constant_expression

Здесь default— имя умолчания, a constant_express1on — его значение.

При выборе имени умолчания следует придерживаться установленных правил

именования объектов. Кроме того, имя умолчания должно быть уникально для

каждого владельца. Указание имени владельца умолчания при его создании не

обязательно.

В качестве значения constant_expression можно использовать не только

константы, но и любые математические выражения и встроенные функции.

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

бинарными данными должен указываться префикс Ох, а перед денежным типом —

символ $. Если размер значения по умолчанию превышает размер, заданный

для данных в столбце, выполняется усечение значения по умолчанию до

требуемого размера.

Приведем пример создания текстового умолчания: CREATE DEFAULT default

one AS "RIAC Industries"

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

командами Transact-SQL.

Умолчание может быть создано только в текущей базе данных. После того

как умолчание создано, его можно связать со столбцом таблицы или

пользовательским типом данных. Для связывания умолчания с объектом базы

данных используется хранимая процедура sp_bindefault, имеющая следующий

синтаксис:

sp_bindefault [@defname =] "default",

[(Pobjname =] "objectjiame"

[. [@future]only =] "futureonly_flag"]

Здесь используются следующие аргументы.

О "default" — имя умолчания. Это имя, указанное при создании умолчания в

команде CREATE DEFAULT.

О "object_name" — имя объекта, к которому привязывается умолчание. Для

связывания умолчания со столбцом таблицы имя объекта указывается в

форме col umn. tab! e. Если же используется другая форма имени, то

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

Умолчание не может быть связано со столбцом типа timestamp, столбцом с

установленным ограничением целостности IDENTITY или со столбцом,

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

от столбца старое умолчание, а уже затем привязывать новое. Если

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

и с этим типом данных связано другое умолчание, то умолчание,

определенное для столбца, имеет приоритет над умолчанием, установленным

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

недопустимые символы, то в аргументе ob ject_name необходимо

использовать разделители [ и ] для указания имени объекта.

О "futureonly_flag" — этот аргумент требуется только при связывании

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

столб-

цом таблицы. При указании этого аргумента в столбцы, имеющие

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

внесено никаких изменений. Если же аргумент f utureonl у не

указывается, то для всех столбцов пользовательского типа данных

применяется значение по умолчанию, связанное с этим типом данных.

Пример связывания умолчания со столбцом таблицы:

ЕХЕС sp_b1ndefault "default_one",

"[employes 013].[company name]"

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

ЕХЕС sp_bindefault "default_one".

"emp_data". "futureonly"

Если тип данных, определенный в умолчании, не соответствует типу данных,

определенному для связанного столбца, то при попытке вставки строки в

таблицу сервер выдаст сообщение об ошибке. При связывании умолчания со

столбцом таблицы сообщение о несоответствии типов не выдается, и

связывание проходит успешно.

Когда умолчание связывается со столбцом таблицы, информация о

связывании сохраняется в системной таблице базы данных syscolumns. При

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

сохраняется в таблице systypes.

Если умолчание связывается со столбцом таблицы или пользовательским

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

умолчание не конфликтует с правилом. В противном случае сервер будет

выдавать сообщение об ошибке всякий раз при добавлении в таблицу новой

строки без указания значения для столбца. При связывании правила и

умолчания со столбцом сервер не отслеживает возможность подобных

конфликтов, поэтому администратор должен сам позаботиться об их

отсутствии.

При вставке новой строки без указания значений для столбцов этим

столбцам присваивается либо значение по умолчанию (если таковое

определено), либо значение NULL (если для столбца разрешено хранение

значений NULL). Если для столбца не определено значение по умолчанию и

запрещено хранение значений NULL, то при вставке пустой строки сервер

выдаст сообщение об ошибке. Если для столбца разрешено хранение значений

NULL и установлено значение по умолчанию, то при вставке пустой строки

значение по умолчанию будет иметь приоритет над значением NULL.

Для удаления умолчания из базы данных используется следующая команда:

DROP DEFAULT {default} [,...n]

Здесь аргумент default определяет имя умолчания, которое необходимо

удалить. Используя одну команду DROP DEFAULT, можно удалить несколько

умолчаний. Для этого необходимо перечислить их через запятую.

Нельзя удалить умолчание, связанное со столбцом таблицы или

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

умолчание от всех объектов, а уже затем выполнять команду DROP DEFAULT.

Для отвязывания умолчания используется хранимая процедура sp_unbindefault

со следующим синтаксисом:

sp_unbindefault [@objname =] "object_name"

[, [@futureonlу =] "futureonly_flag"]

Здесь используются следующие аргументы.

О "object_name" — имя столбца таблицы или пользовательского типа данных, от

которых необходимо отвязать умолчание. Когда умолчание отвязывается от

пользовательского типа данных, оно автоматически отвязывается ото всех

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

с этими столбцами явно и в команде не указан аргумент "futureonly".

О " f utureonl y_f 1 ag" — указывается только для пользовательских типов

данных. Если этот аргумент имеет значение "futureonly", то умолчание не

отвязывается от столбцов, имеющих пользовательский тип данных. Если этот

аргумент отсутствует, сервер автоматически отвяжет умолчание от всех

столбцов. Для получения сведений о представлении (имени владельца и даты

создания) используйте хранимую процедуру sp_help с указанием в качестве

аргумента имени умолчания: spjielp "default_one"

Для получения текста кода Transact-SQL, определяющего умолчание,

используйте хранимую процедуру sp_helptext: sp_helptext "default_one"

Для изменения имени умолчания используйте хранимую процедуру sp_rename:

sp_rename @objname='defaul t_one' @newname='default_two'

Список литературы

1. Мамаев Е., Шкарина Л. «Microsoft SQl Server 2000 для профессионалов».-

СПб:Питер, 2001

2. Хоторн Роб «Разработка баз данных, Micrososoft SQL Server 2000».-

Вильямс, 2001

3. Шарон Б., Мэйбл Грэг «Sql Server 2000, Энциклопедия программиста».-

ДиаСофт, 2001

Страницы: 1, 2, 3, 4, 5, 6, 7