KB 1120 KB 1288 KB 176 KB

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
Distribution	0.9921875	56.98819	0
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 Allocpolicy Status Groupname	Smallint Smallint Ins Sysname	Идентификационный номер группы файлов Зарезервировано Текущий статус группы: 0x8— READONLY, 0x10 — Имя группы файлов	DEFAULT

Например, для получения информации о группах файлов, определенных в базе данных 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 Ser­ver 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'

Список литературы Мамаев Е., Шкарина Л. «Microsoft SQl Server 2000 для профессионалов».-СПб:Питер, 2001 Хоторн Роб «Разработка баз данных, Micrososoft SQL Server 2000».-Вильямс, 2001 Шарон Б., Мэйбл Грэг «Sql Server 2000, Энциклопедия программиста».-ДиаСофт, 2001