Ограничение ключа xs key в значении элемента. Ограничение PRIMARY KEY

Контрольная по информационным сетям и телекоммуникациям (Лабораторная работа)

Брейман А.Д. Сети ЭВМ и телекоммуникации. Глобальные сети (Документ)

Дипломная работа - Построение сети широкополосного абонентского доступа на ГТС г. Алматы (Дипломная работа)

Презентация - Технологии широкополосного доступа. IP-телфония (Реферат)

Дипломный проект - Сеть абонентского доступа (Дипломная работа)

Дипломная работа - Планирование сети доступа NGN для новых групп пользователей (Дипломная работа)

Дипломный проект - Модернизации и расширения сети телекоммуникаций с использованием возможностей системы беспроводного доступа (Дипломная работа)

Наукова стаття - Пассивные оптические сети (PON) (Документ)

Протоколы родительских собраний (Документ)

Шувалов В.Н. Телекоммуникационные системы и сети (3/3) (Документ)

n1.doc

3.3. УРОВЕНЬ LAPD

Протоколы уровня 2 (LAPD - Link Access Procedure on the D-channel) как базового, так и первичного доступа определены в рекомендациях ITU-T 1.440 (основные аспекты) и 1.441 (подробные спецификации). Эти же рекомендации в серии Q имеют номера Q.920 и Q.921. Обмен информацией на уровне LAPD осуществляется посредством информационных блоков, называемых кадрами и схожих с сигнальными единицами ОКС- 7.

Сформированные на уровне 3 сообщения помещаются в информационные поля кадров, не анализируемые уровнем 2. Задачи уровня 2 заключаются в переносе сообщений между пользователем и сетью с минимальными потерями и искажениями. Форматы и процедуры уровня 2 основываются на протоколе управления звеном передачи данных высокого уровня HDLC (High-level Data-Link Control procedures), первоначально определенном Международной организацией по стандартизации ISO и образующем подмножество других распространенных протоколов: LAPB, LAPV5 и др. Протокол LAPD, также входящий в подмножество HDLC, управляет потоком кадров, передаваемых по D-каналу, и предоставляет информацию, необходимую для управления потоком и исправления ошибок.

Рис. 3.8. Формат кадра

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

Каждый кадр начинается и заканчивается однобайтовым флагом. Комбинация флага (0111 1110) такая же, как в ОКС-7. Имитация флага любым другим полем кадра исключается благодаря запрещению передачи последовательности битов, состоящей из более чем пяти следующих друг за другом единиц. Это достигается с помощью специальной процедуры, называемой «бит-стаффингом» (bit-stuffing), которая перед передачей кадра вставляет ноль после любой последовательности из пяти единиц, за исключением флага. При приеме кадра любой ноль, обнаруженный следом за последовательностью из пяти единиц, изымается.

Адресное поле (байты 2 и 3) кадра на рис. 3.8 содержит идентификатор точки доступа к услуге SAPI (Service Access Point Identifier) и идентификатор терминала TEI (Terminal Equipment Identifier) и используется для маршрутизации кадра к месту его назначения. Эти идентификаторы, уже упоминавшиеся в первом параграфе данной главы, определяют соединение и терминал, к которым относится кадр.

Идентификатор пункта доступа к услуге SAPI занимает 6 битов в адресном поле и фактически указывает, какой логический объект сетевого уровня должен анализировать содержимое информационного поля. Например, SAPI может указывать, что содержимое информационного поля относится к процедурам управления соединениями в режиме коммутации каналов или к процедурам пакетной коммутации. Рекомендацией Q.921 определены значения SAPI, приведенные в табл. 3.1.
Таблица 3.1. Значения SAPI

Идентификатор TEI указывает терминальное оборудование, к которому относится сообщение. Код TEI=127 (1111111) указывает на вещательную (циркулярную) передачу информации всем терминалам, связанным с данной точкой доступа. Остальные значения (0-126) используются для идентификации терминалов. Диапазон значений TEI (табл. 3.2) разделяется между теми терминалами, для которых TEI назначает сеть (автоматическое назначение TEI), и теми, для которых TEI назначает пользователь (неавтоматическое назначение TEI).

Таблица 3.2. Значения TEI

При подключении УПАТС (представляющей собой функциональный блок NT2) к АТС ISDN общего пользования с использованием интерфейса PR1 в соответствии с требованиями стандартов ETSI, принятых и в России, ТЕ1==0. В этом случае процедуры назначения TEI не применяются.

Бит идентификации команды/ответа C/R (Command/Response bit) в адресном поле перенесен в DSS-1 из протокола Х.25. Этот бит устанавливается LAPD на одном конце и обрабатывается на противоположном конце звена. Значение C/R (табл.3.3) классифицирует каждый кадр как командный или как кадр ответа. Если кадр сформирован как команда, адресное поле идентифицирует получателя, а если кадр является ответом, адресное поле идентифицирует отправителя. Отправителем или получателем могут быть как сеть, так и терминальное оборудование пользователя.

Таблица 3.3. Биты C/R в поле адреса

Бит расширения адресного поля ЕА (Extended address bit) служит для гибкого увеличения длины адресного поля. Бит расширения в первом байте адреса, имеющий значение 0, указывает на то, что за ним следует другой байт. Бит расширения во втором байте, имеющий значение 1, указывает, что этот второй байт в адресном поле является последним. Именно такой вариант приведен на рис. 3.8. Если впоследствии возникнет необходимость увеличить размер адресного поля, значение бита расширения во втором байте может быть изменено на 0, что будет указывать на существование третьего байта. Третий байт в этом случае будет содержать бит расширения со значением 1, указывающим, что этот байт является последним. Увеличение размера адресного поля, таким образом, не влияет на остальную часть кадра.

Два последних байта в структуре кадра на рис. 3.8 содержат 16-битовое поле проверочной комбинации кадра PCS (Frame check sequence) и генерируются уровнем звена данных в оборудовании, передающем кадр. Это поле имеет ту же функцию, что и поле СВ (контрольные биты) в сигнальных единицах ОКС-7 (глава 10 тома 1), и позволяет LAPD обнаруживать ошибки в полученном кадре. В поле FSC передается 16-битовая последовательность, биты которой формируются как дополнение для суммы (по модулю 2), в которой: а) первым слагаемым является остаток от деления (по модулю 2) произведения х k (x 15 +x 14 +…+x+l) на образующий полином (х 16 +х 12 +х 5 +1), где k - число битов кадра между последним битом открывающего флага и первым битом проверочной комбинации, исключая биты, введенные для обеспечения прозрачности;

б) вторым слагаемым является остаток от деления (по модулю 2) на этот образующий полином произведения х16 на полином, коэффициентами которого являются биты кадра, расположенные между последним битом открывающего флага и первым битом проверочной комбинации, исключая биты, введенные для обеспечения прозрачности. Обратное преобразование выполняется уровнем звена данных в оборудовании, принимающем кадр, с тем же образующим полиномом для адресного поля, полей управления, информационного и FCS. Протокол LAPD использует соглашение, по которому остаток от деления (по модулю 2) произведения х16 на полином, коэффициентами которого являются биты перечисленных полей и FCS, всегда составляет 0001110100001111 (десятичное 7439), если на пути от передатчика к приемнику никакие биты не были искажены. Если результаты обратного преобразования соответствуют проверочным битам, кадр считается переданным без ошибок. Если же обнаружено несоответствие результатов, это означает, что при передаче кадра произошла ошибка.

Поле управления указывает тип передаваемого кадра и занимает в различных кадрах один или два байта. Существует три категории форматов, определяемых полем управления: передача информации с подтверждением (I-формат), передача команд, реализующих управляющие функции (S-формат), и передача информации без подтверждения (U-формат). Табл. 3.4, являющаяся ключевой в этом параграфе, содержит сведения об основных типах кадров протокола DSS-1.

Рассмотрим эти типы несколько подробнее.

Информационный кадр (I) сопоставим со значащей сигнальной единицей MSU в ОКС-7 (параграф 10.2 первого тома). С помощью 1-кадров организуется передача информации сетевого уровня между терминалом пользователя и сетью. Этот кадр содержит информационное поле, в котором помещается сообщение сетевого уровня. Поле управления 1-формата содержит порядковый номер передачи, который увеличивается на 1 (по модулю 128) каждый раз, когда передается кадр. При подтверждении приема 1-кадров в поле управления вводится порядковый номер приема. Процедура организации порядковых номеров рассматривается в следующем параграфе данной главы.

Управляющий кадр (S) используется для поддержки функций управления потоком и запроса повторной передачи. S-кадры не имеют информационного поля и сравнимы с сигнальными единицами состояния звена LSSU в ОКС-7 (параграф 10.2 первого тома). Например, если сеть временно не в состоянии принимать 1-кадры, пользователю посылается S-кадр «к приему не готов» (RNR). Когда сеть снова сможет принимать 1-кадры, она передает другой S-кадр - «к приему готов» (RR). S-кадр также может использоваться для подтверждения и содержит в этом случае порядковый номер приема, а не передачи.
Таблица 3.4. Основные типы кадров LAPD

формат	Команды	Ответы	Описание
Информационные кадры (I)	Информация	-	Используется в режиме с подтверждением для передачи нумерованных кадров, содержащих информационные поля с сообщениями уровня 3
Управляющие	К приему готов (PR-receive ready)	К приему готов (RR-receive ready)	Используется для указания готовности встречной стороны к приему I-кадра или для подтверждения ранее полученных 1-кадров
кадры (S)	К приему не готов (RNR)	К приему не готов (RNR)	Используется для указания неготовности встречной стороны к приему I-кадра
	Отказ/переспрос (REJ-reject)	Отказ/переспрос (REJ-reject)	Используется для запроса повторной передачи 1-кадра
	Ненумерованная информация (UI-unnumbered information)		Используется в режиме передачи без подтверждения
		Отключено (DM-disconnected mode)
Ненумерованные кадры (U)	Установка расширенного асинхронного балансного режима (SABME-set asynchronous balanced mode extended)		Используется для начальной установки режима с подтверждением
		Отказ кадра (FRMR-frame reject)
	Разъединение (DISC-disconnect)		Используется для прекращения режима с подтверждением
		Ненумерованное подтверждение (UA-unnumbered ask)	Используется для подтверждения приема команд установки режима, например, SABME, DISC

Управляющие кадры можно передавать или как командные, или как кадры ответа.

Ненумерованный кадр (U) не имеет аналогов в ОКС-7. В этой группе имеется кадр ненумерованной информации (UI), единственный из группы содержащий информационное поле и несущий сообщение сетевого уровня. U-кадры используются для передачи информации в режиме без подтверждения и для передачи некоторых административных директив. Чтобы транслировать сообщение ко всем ТЕ, подключенным к шине S-интерфейса, станция передает кадр UI с ТЕ1==127. Поле управления U-кадров не содержит порядковых номеров.

Как следует из вышеизложенного, информационное поле имеется в кадрах только некоторых типов и содержит информацию уровня 3, сформированную одной системой, например, терминалом пользователя, которую требуется передать другой системе, например, сети. Информационное поле может быть пропущено, если кадр не имеет отношения к конкретной коммутируемой связи (например, в управляющих кадрах, S-формат). Если кадр относится к функционированию уровня 2 и уровень 3 не участвует в его формировании, соответствующая информация включается в поле управления.

Биты P/F (poll/final) поля управления идентифицируют группу кадров (из табл. 3.4), что также заимствовано из спецификаций протокола Х.25. Путем установки в 1 бита Р в командном кадре функции LAPD на одном конце звена данных указывают функциям LAPD на противоположном конце звена на необходимость ответа управляющим или ненумерованным кадром. Кадр ответа с F== 1 указывает, что он передается в ответ на принятый командный кадр со значением Р= 1. Оставшиеся биты байта 4 идентифицируют конкретный тип кадра в пределах группы.

И в заключение данного параграфа, с учетом уже детально проанализированной структуры кадра уровня 2 протокола DSS-1, еще раз рассмотрим оба способа передачи кадров: с подтверждением и без подтверждения.

Передача с подтверждением. Этот способ используется только в соединениях звена данных, имеющих конфигурацию «точка-точка», для передачи информационных кадров. Он обеспечивает исправление ошибок путем повторной передачи и доставку не содержащих ошибок сообщений в порядке очередности. Этот способ подобен основному методу защиты от ошибок при передаче значащих сигнальных единиц MSU в системе ОКС-7.

Поле управления информационного кадра имеет подполя «номер передачи» и «номер приема» . Эти подполя сопоставимы с полями FSN, BSN в сигнальных единицах MSU системы ОКС-7 (параграф 10.2 первого тома). Протокол LAPD присваивает возрастающие порядковые номера передачи N(S) последовательно передаваемым информационным кадрам, а именно: N(S)=0, 1, 2,... 127, О, 1,... и т.д. Он также записывает передаваемые кадры в буфер повторной передачи и хранит эти кадры в буфере вплоть до получения положительного подтверждения их приема.

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

Предположим, что последний принятый информационный кадр имел номер N(S)== 11 и что информационный кадр с номером N(S)=12 передан с ошибкой, в результате которой отбракован функциями LAPD на стороне сети. Следующий информационный кадр с N(S)= 13 успешно проходит проверку на ошибки, но поступает к сети с нарушением очередности и отбрасывается ею при проверке порядка следования. Тогда сеть передает кадр отказа (REJ) с номером N(R)=12, который запрашивает повторную передачу информационных кадров из буфера повторной передачи терминала, начиная с кадра с N(S)=12. Сетевая сторона продолжает отбрасывать информационные кадры при проверке их на порядок следования, пока не примет повторно переданный кадр с номером N(S)= 12.

Два потока сообщений от терминала к сети и в обратном направлении для этого соединения «точка-точка» независимы друг от друга и от потоков сообщений в других соединениях «точка-точка» в том же D-канале. В D-канале с n соединениями типа «точка-точка» могут присутствовать 2п независимых последовательностей N(S)/N(R).

Передача неподтверждаемых сообщений. Управляющие кадры S и ненумерованные кадры U не содержат подполя N(S). Они принимаются, если получены без ошибок, и не подтверждаются. Управляющие кадры содержат поле N(R) для подтверждения принятых информационных кадров.

Ненумерованные информационные кадры UI не содержат ни поля N(S), ни поля N(R), поскольку они передаются в вещательном режиме с ТЕ1==127, а возможность координировать порядковые номера передачи и приема для групповых функций во всех терминалах, подключенных к одному S-интерфейсу, отсутствует.

Протокол DSS- /; Физический уровень и уровень звена данных 83

Control procedures), первоначально определенном Международной организацией по стандартизации ISO и образующем подмножество других распространенных протоколов: LAPB, LAPV5 и др. Протокол LAPD, также входящий в подмножество HDLC, управляет потоком кадров, передаваемых по D-каналу, и предоставляет информацию, необходимую для управления потоком и исправления ошибок.

Рис. 3.8. Формат кадра

84Глава 3______________

Таблица 3.1. ЗначенияSAPI

Идентификатор TEI указывает терминальное оборудование, к которому относится сообщение. Код TEI=127 (1111111) указывает на вещательную (циркулярную) передачу информации всем терминалам, связанным с данной точкой доступа. Остальные значения (0-126) используются для идентификации терминалов. Диапазон значений TEI (табл. 3.2) разделяется между теми терминалами, для которых TEI назначает сеть (автоматическое назначение TEI), и теми, для которых TEI назначает пользователь (неавтоматическое назначение TEI).

Таблица 3.2. ЗначенияTEI

Протокол DSS-1: Физический уровень и уровень звена данных 8 5

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

Таблица 3.3. БитыC/R в поле адреса

86_____Глава 3 ______________________________________

верочной комбинации, исключая биты, введенные для обеспечения прозрачности. Обратное преобразование выполняется уровнем звена данных в оборудовании, принимающем кадр, с тем же образующим полиномом для адресного поля, полей управления, информационного и FCS. Протокол LAPD использует соглашение, по которому остаток от деления (по модулю 2) произведения х 16 на полином, коэффициентами которого являются биты перечисленных полей и FCS, всегда составляет 0001110100001111 (десятичное 7439), если на пути от передатчика к приемнику никакие биты не были искажены. Если результаты обратного преобразования соответствуют проверочным битам, кадр считается переданным без ошибок. Если же обнаружено несоответствие результатов, это означает, что при передаче кадра произошла ошибка.

Поле управления указывает тип передаваемого кадра и занимает в различных кадрах один или два байта. Существует три категории форматов, определяемых полем управления: передача информации с подтверждением (I-формат), передача команд, реализующих управляющие функции (S-формат), и передача информации без подтверждения (U-формат). Табл. 3.4, являющаяся ключевой в этом параграфе, содержит сведения об основных типах кадров протокола DSS-1.

Рассмотрим эти типы несколько подробнее.

Протокол DSS-1: Физический уровень и уровень звена данных 87

Таблица 3.4. Основные типы кадров LAPD

88 Глава 3 _______________

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

Управляющие кадры можно передавать или как командные, или как кадры ответа.

Протокол DSS-1: Физический уровень и уровень звена данных 89

90 Глава 3

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

Столбцы какого типа и размера будут составлять каждую из таблиц, какие требуется выбрать имена для столбцов таблиц?
Какие столбцы могут содержать значение NULL ?
Будут ли использованы ограничения целостности , значения по умолчанию и правила для столбцов?
Необходимо ли индексирование столбцов, какие типы индексов будут применены для конкретных столбцов?
Какие столбцы будут входить в первичные и внешние ключи .

Для создания таблиц в среде MS SQL Server используется команда:

<определение_таблицы> ::= CREATE TABLE [ имя_базы_данных.[владелец]. | владелец. ]имя_таблицы (<элемент_таблицы>[,...n])

<элемент_таблицы> ::= {<определение_столбца>} | <имя_столбца> AS <выражение> | <ограничение_таблицы>

Обычно владельцем таблицы (dbo) является тот, кто ее создал.

<Выражение> задает значение для вычисляемого столбца . Вычисляемые столбцы - это виртуальные столбцы, т. е. физически в таблице они не хранятся и вычисляются с использованием значений столбцов той же таблицы. В выражении для вычисляемого столбца могут присутствовать имена обычных столбцов, константы и функции, связанные одним или несколькими операторами. Подзапросы в таком выражении участвовать не могут. Вычисляемые столбцы могут быть включены в раздел SELECT при указании списка столбцов, которые должны быть возвращены в результате выполнения запроса. Вычисляемые столбцы не могут входить во внешний ключ , для них не используются значения по умолчанию. Кроме того, вычисляемые столбцы не могут участвовать в операциях INSERT и DELETE .

<определение_столбца> ::= { имя_столбца <тип_данных>} [ [ DEFAULT <выражение> ] | [ IDENTITY (начало, шаг) ]]] [<ограничение_столбца>][...n]]

В определении столбца обратим внимание на параметр IDENTITY , который указывает, что соответствующий столбец будет столбцом-счетчиком . Для таблицы может быть определен только один столбец с таким свойством. Можно дополнительно указать начальное значение и шаг приращения. Если эти значения не указываются, то по умолчанию они оба равны 1. Если с ключевым словом IDENTITY указано NOT FOR REPLICATION , то сервер не будет выполнять автоматического генерирования значений для этого столбца, а разрешит вставку в столбец произвольных значений.

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

<ограничение_столбца>::= [ CONSTRAINT имя_ограничения ] { [ NULL | NOT NULL ] | [ {PRIMARY KEY | UNIQUE } [ CLUSTERED | NONCLUSTERED ] [ WITH FILLFACTOR=фактор_заполнения ] [ ON {имя_группы_файлов | DEFAULT } ] ] ] | [ [ FOREIGN KEY ] REFERENCES имя_род_таблицы [(имя_столбца_род_таблицы) ] [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] [ NOT FOR REPLICATION ]] | CHECK [ NOT FOR REPLICATION](<лог_выражение>) } <ограничение_таблицы>::= { [ {PRIMARY KEY | UNIQUE } [ CLUSTERED | NONCLUSTERED ] {(имя_столбца [,...n])} ] |FOREIGN KEY[(имя_столбца [,...n])] REFERENCES имя_род_таблицы [(имя_столбца_род_таблицы [,...n])] [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] | NOT FOR REPLICATION ] | CHECK [ NOT FOR REPLICATION ] (лог_выражение) }

Рассмотрим отдельные параметры представленных конструкций, связанные с ограничениями целостности данных . Ограничения целостности имеют приоритет над триггерами, правилами и значениями по умолчанию. К ограничениям целостности относятся ограничение первичного ключа PRIMARY KEY , ограничение внешнего ключа FOREIGN KEY , ограничение уникальности UNIQUE , ограничение значения NULL , ограничение на проверку CHECK .

Ограничение первичного ключа (PRIMARY KEY)

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

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

Таблица может иметь только одно ограничение PRIMARY KEY , причем ни один из включенных в первичный ключ столбцов не может принимать значение NULL . При попытке использовать в качестве первичного ключа столбец (или группу столбцов), для которого ограничения первичного ключа не выполняются, первичный ключ создан не будет, а система выдаст сообщение об ошибке.

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

Ограничение внешнего ключа (FOREIGN KEY)

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

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

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

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

Ограничение ссылочной целостности задает требование, согласно которому для каждой записи в дочерней таблице должна иметься запись в родительской таблице. При этом изменение значения столбца связи в записи родительской таблицы при наличии дочерней записи блокируется, равно как и удаление родительской записи (запрет каскадного изменения и удаления), что гарантируется параметрами ON DELETE NO ACTION и ON UPDATE NO ACTION , принятыми по умолчанию. Для разрешения каскадного воздействия следует использовать параметры ON DELETE CASCADE и ON UPDATE CASCADE .

Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных (Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.

Для разработчиков баз данных

Книга:

Ограничение PRIMARY KEY

Разделы на этой странице:

Ограничение PRIMARY KEY

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

Если вы пришли в Firebird из СУБД, которые поддерживают концепцию "первичного индекса" для определения ключа (обычно основанные на файлах системы, такие как Paradox, Access и MySQL), то Firebird и мир стандартов SQL вам понятны. Первичный ключ является не индексом, а ограничением. Одним из правил для такого ограничения является то, что ограничение должно иметь определенный уникальный индекс из одного или более связанных с ним непустых элементов.

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

ВНИМАНИЕ! Не надо импортировать существующий "первичный индекс" из наследуемой системы, основанной на файлах, или создавать такой индекс в ожидании объявления ограничения первичного ключа. Firebird не может накладывать ограничение первичного ключа поверх существующего индекса - по крайней мере в существующих версиях, включая 1.5, - а оптимизатор запросов не будет правильно работать при дублировании индексов.

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

ВНИМАНИЕ! Если вы конвертируете базу данных в Firebird из любого другого источника за исключением InterBase или Oracle, то вы должны обратить особое внимание на схему в отношении имен и ограничений первичного ключа.

Хотя само ограничение PRIMARY KEY не является ссылочным ограничением, оно обычно является обязательной частью любого ссылочного ограничения, будучи потенциальным объектом предложения REFERENCES ограничения FOREIGN KEY. Подробности см. в главе 17.

Выбор первичного ключа

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

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

* Атрибут NOT NULL должен быть объявлен для всех столбцов в группе из одного или более столбцов. Целостность ключа может быть осуществлена только сравнением значений, a NULL не является значением.

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

К этим теоретическим "установкам" должна быть добавлена третья.

* Общий размер кандидата в ключи должен быть 252 байта или меньше. Дело здесь не просто в подсчете символов. Этот лимит должен быть уменьшен - в некоторых случаях радикально - если присутствует несколько столбцов, недвоичная последовательность сортировки или многобайтовый набор символов.

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

Используя таблицу EMPLOYEE базы данных employee.fdb из каталога /examples корневого каталога Firebird (employee.gdb в версии 1,0.x), давайте посмотрим, как реальные данные могут привести к ошибочности ваших теоретических предположений об уникальности. Вот объявление, которое показывает имеющие смысл данные, хранимые в этой таблице:

CREATE TABLE EMPLOYEE (

FIRST_NAME VARCHAR(15) NOT NULL,

/* предположение: служащий должен иметь имя */

LAST_NAME VARCHAR(20) NOT NULL,

/* предположение: служащий должен иметь фамилию */

PHONE_EXT VARCHAR(4),

HIRE_DATE DATE DEFAULT CURRENT_DATE NOT NULL,

DEPT_NO CHAR(3) NOT NULL,

JOB_CODE VARCHAR (5) NOT NULL,

JOB_GRADE SMALLINT NOT NULL,

JOB_COUNTRY VARCHAR(15) NOT NULL,

SALARY NUMERIC (15, 2) DEFAULT 0 NOT NULL,

FULL_NAME COMPUTED BY FIRST_NAME || " " || LAST_NAME) ;

Фактически эта структура не имеет кандидата в ключи. Невозможно идентифицировать одну строку служащего, используя (FIRST_NAME, LAST_NAME) в качестве ключа, поскольку комбинация двух элементов с вероятностью от средней до высокой может дублироваться в организации. Мы не сможем сохранить записи двух служащих с именем John Smith.

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

Суррогатные ключи

Мы уже рассматривали суррогатный ключ во вводной теме о ключах в главе 14. Суррогатный первичный ключ - значение, гарантирующее уникальность и не имеющее смыслового содержания, которое используется в качестве заменителя ключа в структуре таблицы, которая не может предоставить кандидата на ключ в собственной структуре. По этой причине в таблицу EMPLOYEE добавляется EMP_NO (объявляется через домен) для выполнения роли суррогатного ключа:

CREATE DOMAIN EMPNO SMALLINT ;

ALTER TABLE EMPLOYEE

ADD EMP_NO EMPNO NOT NULL,

ADD CONSTRAINT PK_EMPLOYEE

PRIMARY KEY(EMP_NO) ;

Эта база данных также содержит генератор с именем EMP_NO_GEN и триггер Before insert (перед добавлением) с именем SET_EMP_NO для таблицы EMPLOYEE для получения значения данного ключа в момент добавления новой строки. В разд. "Реализация автоинкрементных ключей" главы 31 эта техника описывается в деталях. Это рекомендованный способ реализации суррогатных ключей в Firebird.

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

Составные первичные ключи

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

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

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

* Составные ключи обычно являются составленными из неатомарных элементов ключа- т.е. выбранные столбцы имеют смысловое значение (они являются "значимыми данными") и, несомненно, уязвимы для внешних изменений и ошибок ручного ввода.

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

* Ключи - внешние, так же как и первичные - имеют постоянные индексы. Составные индексы имеют более строгие ограничения по размеру, чем индексы из одного столбца.

* Составные индексы имеют тенденцию к большим размерам. Большие индексы используют больше страниц базы данных, что приводит к тому, что индексные операции (сортировка, соединение и сравнение) выполняются медленнее, чем необходимо.

Атомарность столбцов первичного ключа

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

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

Синтаксис объявления первичного ключа

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

Ограничение PRIMARY KEY может применяться в любой из следующих фаз создания метаданных:

* в определении столбца в операторах CREATE TABLE или ALTER TABLE как часть определения столбца;

* в определении таблицы в операторах CREATE TABLE или ALTER TABLE как отдельно определенное ограничение таблицы.

Определение первичного ключа как часть определения столбца

В следующей последовательности создается и подтверждается (commit) домен, не допускающий пустое значение, затем определяется столбец первичного ключа, основанный на этом домене, и одновременно применяется ограничение PRIMARY KEY к этому столбцу:

CREATE DOMAIN D_IDENTITY AS BIGINT NOT NULL;

CREATE TABLE PERSON (

PERSON_ID D_IDENTITY PRIMARY KEY,

Firebird создает ограничение таблицы с именем INTEG_M и индекс с именем RDB$PRIMARYnn. (пл в каждом случае - число, полученное от генератора. Эти два числа не связаны друг с другом.) Вы не можете повлиять на то, какими будут эти имена, и не можете поменять их.

Результат будет похожим, если вы используете тот же подход при добавлении столбца, используя оператор ALTER TABLE и создавая первичный ключ в одном предложении:

ALTER TABLE BOOK

ADD BOOK_ID D_IDENTITY PRIMARY KEY;

Определение первичного ключа как именованного ограничения

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

CREATE TABLE ATABLE (

ID BIGINT NOT NULL,

ANOTHER_COLUMN VARCHAR (20),

CONSTRAINT PK_ATABLE PRIMARY KEY(ID));

Теперь вместо использования сгенерированного системой имени RDB$PRIMARYnnn Firebird использует PK_ATABLE В качестве имени этого ограничения. В Firebird 1.5 и выше он также применяет определенное пользователем имя ограничения для поддерживающего уникального индекса. В этом примере индекс получит имя PK_ATABLE, когда в других версиях его имя будет RDB$PRIMARYnnn.

Элемент key определяет значение атрибута или элемента как ключ (ненулевой, уникальный и всегда присутствующий) в содержащем элементе формируемого документа. Элемент имеет следующий формат:

< префикс : key

id = ID

name = NCName

(annotation ?, (selector , field + ))

префикс : key>

Атрибуты id иname unique .

key , selector и field :

xs : key >

В этом примере поля " forename " и" surname " используются в качестве ключа с именемfullName .

Элемент keyref определяет, что значение атрибута или элемента соответствует значениям заданного ключа или уникального элемента и имеет следующий формат:

< префикс : keyref

id = ID

name = NCName

refer = QName

(annotation ?, (selector , field +))

префикс: keyref >

Атрибуты id иname имеют тот же смысл, что и для элементаunique , а обязательный атрибутrefer определяет имя ключа или уникального элемента, определенного в данной или другой схеме.

Пример использования элементов keyref , selector и field :

В этом примере поля "@ first " и"@ last " соответствуют значениям ключа определенного выше элемента с именемfullName .

4.2.9. Определение комплексного типа в схемеXml

Комплексный элемент типа complexType – это элементXML, содержащий другие элементы и/или атрибуты. Существует четыре вида комплексных элементов:

пустые элементы;

4.2.9.1. Формат определения элементаcomplexType

Определение комплексного типа имеет следующий формат:

< префикс : complexType

name = NCName

id = ID

abstract = boolean : false

mixed = boolean : false

block = (#all | List (extension | restriction ))

final = (#all |List (extension | restriction ))

(annotation ?, (simpleContent | complexContent |

((sequence | group | all | choice )?,

((attribute | attributeGroup )*, anyAttribute ?))))

префикс : complexType>

Атрибуты name иid в элементеcomplexType имеют тот же смысл, что и в элементеattribute , а атрибуты abstract , block и final – тот же смысл, что и в элементе element . Атрибут mixed определяет, могут ли символьные данные появляться между дочерними элементами определения комплексного типа.

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

элемент simpleContent ;

элемент complexContent ;

один из элементов group , all , choice или sequence (0 или 1 раз), один из элементов attribute или attributeGroup (0 и более раз) и элемент anyAttribute (0 или 1 раз).

Рассмотрим дочерние элементы элемента complexType .

4.2.9.2. Элементы sequence, any, choice, all и group

Элемент sequence определяет, что дочерние элементы данного элемента должны появляться в заданной последовательности и имеет следующий формат:

< префикс : sequence

id = ID

maxOccurs = (nonNegativeInteger | unbounded ) : 1

minOccurs = nonNegativeInteger : 1

(annotation ?, (element | group | choice | sequence | any )*)

префикс : sequence >

Необязательный атрибут id maxOccurs иminOccurs задают максимальное и минимальное значение для количества включений данной последовательности в родительский элемент.

Пример использования элемента sequence:

xs : element >

В примере задан элемент с именем personinfo (данные о сотруднике). Этот элемент содержит дочерние элементыfirstname иlastname , а также последовательность элементовchild (ребенок) – эта последовательность может отсутствовать или содержать неограниченное количество элементовchild .

Как видно, из объявления элемента sequence , в содержимом этого элемента может быть задан дочерний элементany . Этот элемент позволяет расширить документXMLэлементами, которые не определены в схеме, и имеет следующий формат:

< префикс : any

id = ID

maxOccurs = (nonNegativeInteger | unbounded ) : 1

minOccurs = nonNegativeInteger : 1

namespace = ((##any | ##other ) | List (anyURI |

(##targetNamespace | ##local ))) : ##any

processContents = (strict | lax | skip ) : strict

(annotation ?)

префикс : any >

Необязательный атрибут id задает уникальный идентификатор элемента, а необязательные атрибутыmaxOccurs иminOccurs задают максимальное и минимальное значение для количества включений элементаany в родительский элемент. Необязательный атрибутnamespace определяет пространства имен, содержащих элементы, которые могут быть использованы в родительском элементе, и может иметь одно из следующих значений:

## any – допустимы элементы из любого пространства имен;

## other – могут присутствовать элементы из любого пространства имен, отличного от пространства имен, заданного для родительского элемента;

## local – элементы должны задаваться не из пространства имен;

## target Namespace – могут присутствовать элементы из пространства имен, заданного для родительского элемента;

List (anyURI | (## targetNamespace |## local ))) – могут присутствовать элементы из заданного списка.

Необязательный атрибут processContents определяет, как процессорXMLдолжен организовать обработку элементов, определенных данным элементомany и может иметь одно из следующих значений:

strict – процессорXMLдолжен получить схему необходимых пространств имен и проверить действительность элементов;

lax – аналогичноstrict , но если схема не может быть получена, сообщение об ошибке не генерируется;

skip – процессорXMLпропускает проверку действительности элементов.

any :

< xs : element name =" person ">

xs : complexType >

xs : element >

С помощью использования элемента any можно расширить содержимое элементаperson (после элементаlastname ) любым другим элементом.

Элемент choice разрешает задавать в родительском элементе только один из присутствующих в списке элементов и имеет следующий формат:

< префикс : choice

id = ID

maxOccurs = (nonNegativeInteger | unbounded ) : 1

minOccurs = nonNegativeInteger : 1

(annotation ?, (element | group | choice | sequence | any )*)

префикс : choice >

Пример использования элемента choice:

< / xs:element>

Элемент person должен содержать один из описанных ранее элементов:employee (постоянный сотрудник) илиfreelance (контрактник).

Элемент all определяет, что элементы, содержащийся в нем, могут появляться в родительском элементе в любом порядке, и каждый элемент может появляться 0 или 1 раз. Элемент имеет следующий формат:

< префикс : all

id = ID

maxOccurs = 1 : 1

minOccurs = (0 | 1 ) : 1

(annotation ?, element *)

префикс : all >

Необязательный атрибут id задает уникальный идентификатор элемента. Необязательный атрибутmaxOccurs должен иметь значение 1, а необязательный атрибутminOccurs задает минимальное значение для количества включений выбранного элемента в родительский элемент (0 или1 ).

Пример использования элемента all :

< xs : element name =" person ">

Элементы firstname иlastname могут появляться в элементе в элементеperson в любом порядке и один или оба элемента могут отсутствовать.

Элемент group используется для задания группы элементов в определении комплексного типа и имеет следующий формат:

< префикс : group

id = ID

name = NCName

ref = QName

maxOccurs = nonNegativeInteger | unbounded : 1

minOccurs = nonNegativeInteger : 1

(annotation ?, (all | choice | sequence ))

префикс : group>

Атрибут name задает имя элемента. Он является обязательным только в том случае, если родительским элементом данного элемента является элементschema или элементredefine . Атрибутref задает ссылку на имя другой группы (атрибутыname иref являются взаимоисключающими). Необязательные атрибутыmaxOccurs иminOccurs задают максимальное и минимальное значение для количества включений элементов группы в родительский элемент.

Пример использования элемента group :

< xs : group name =" custGroup ">

xs : complexType >

В этом примере определена группаcustGroup , состоящая из двух элементов:customer (покупатель) иorderDetails (детали заказа), а затем эта группа использована (с помощью ссылки) в определении комплексного типаorderType .