Принципы формирования запросов на языке реляционной алгебры

Отметим следующие особенности построения языков запро­сов с использованием рассмотренных выше операций реляци­онной алгебры. Во-первых, в любые языки манипулирования данными включаются дополнительные операторы включения, удаления и модификации кортежей отношений базы данных. Кроме того, формула F операции селекции может включать выполнение арифметических вычислений, а также сравнения, например, вида А =В+3. В состав операторов языка включа­ются команды присваивания некоторого имени вычисленному экземпляру отношения и печати этого экземпляра. Наконец, над столбцами отношений обеспечивается выполнение таких операций, как нахождение среднего значения, суммы, миниму­ма или максимума из заданного набора значений.

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

— взять некоторое отношение (или группу отношений), вы­полнить над ним операцию селекции;

— объединить результат селекции с другим объектом с по­мощью операции -соединения или естественного соединения;

— найти проекцию полученного результата и ее напечатать в качестве ответа на запрос.

Описанная схема содержания запроса может быть названа схемой «селекции—соединения—проекции».

Пусть R, S — исходные отношения, из которых должен быть сформулирован ответ на некоторый запрос. Общая структура формулы, называемой реляционным выражением, для формирования ответа, может иметь вид

(10)

где — операции реляционной алгебры, — неко­торое подмножество множества атрибутов R и S, F₁, F₂ — фор­мулы исчисления предикатов, выражающие условия селекции кортежей R и S.

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

63. Понятие и виды функциональных зависимостей. Нормальные формы отношений

4.2.1.Функциональные зависимости.

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

Определение:

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

Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения.

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

Некоторые функциональные зависимости могут быть нежелательны.

Определение:

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

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

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

не должны появляться ранее отсутствовавшие кортежи;

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

Нормализация отношений. Нормальные формы отношений

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

ОПРЕДЕЛЕНИЕ

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

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

Препода­ватель	День недели	Номер пары	Название дисциплины	Тип занятий	Группа
Петров В. И.	Понед.	1	Теор.выч.проц.	Лекция	4906
	Вторник	1	Комп.графика	Лаб. раб.	4907
	Вторник	2	Комн.графика	Лаб. раб.	4906
Киров В. А.	Понед.	2	Теор. информ.	Лекция	4906
	Вторник	3	Пр-е на C++	Лаб. раб.	4907
	Вторник	4	Пр-е на C++	Лаб. раб.	4906
Серов А. А.	Понед.	3	Защита инф.	Лекция	4944
	Среда	3	Пр-е на VB	Лаб. раб.	4942
	Четверг	4	Пр-е на VB	Лаб. раб.	4922

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

Для приведения отношения «Расписание» к первой нормальной форме необхо­димо дополнить каждую строку фамилией преподавателя.

ОПРЕДЕЛЕНИЕ

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

Отношение находится по второй нормальной форме тогда и только тогда, когда оно нахо­дится в первой нормальной форме и не содержит неполных функциональных зависимо­стей непервичных атрибутов от атрибутов первичного ключа.
Препода­ватель	День недели	Номер пары	Название дисциплины	Тип занятий	Группа
Петров В. И	Понед.	1	Теор. выч. проц.	Лекция	4906
Петров В. И	Вторник	1	Комп.графика	Лаб. раб.	4907
Петров В. И	Вторник	2	Комн.графика	Лаб. раб.	4906
Киров В. А.	Понед.	2	Теор. информ.	Лекция	4906
Киров В. А.	Вторник	3	Пр-е на C++	Лаб. раб.	4907
Киров В. А.	Вторник	4	Пр-е на C++	Лаб. раб.	4906
Серов А. А.	Понед.	3	Защита инф.	Лекция	4944
Серов А. А.	Среда	3	Пр-е на VB	Лаб. раб. ..	4942
Серов А. А.	Четверг.	4	Пр-е на VB.	Лаб. раб. -	4922

Рассмотрим отношение, моделирующее сдачу студентами текущей сессии. Струк­тура этого отношения определяется следующим набором атрибутов:

(ФИО. Номер зач.кн., Группа, Дисциплина, Оценка)

Так как каждый студент сдает целый набор дисциплин в процессе сессии, то первичным ключом отношения может быть (Номер, зач.кн. Дисциплина), кото­рый однозначно определяет каждую стоку отношения. С другой стороны, атри­буты ФИО и Группа зависят только от части первичного ключа — от значения ат­рибута Номер зач. кн., поэтому мы должны констатировать наличие неполных функциональных зависимостей в данном отношении. Для приведения данного отношения ко второй нормальной форме следует разбить его на проекции, при этом должно быть соблюдено условие восстановления исходного отношения без потерь. Такими проекциями могут быть два отношения:

(ФИО, Номер.зач.кн. Группа) (Номер зач.кн., Дисциплина, Оценка)

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

А почему надо приводить отношения ко второй нормальной форме? Иначе го­воря, какие аномалии или неудобства могут возникнуть, если мы оставим ис­ходное отношение и не будем его разбивать на два? Давайте рассмотрим ситуа­цию, когда студент переведен из одной группы в другую. Тогда в первом случае (если мы не разбивали исходное отношение на два) мы должны найти все запи­си с данным студентом и в них изменить значение атрибута Группа на новое. Во втором же случае меняется только один кортеж в первом отношении. И конеч­но, опасность нарушения корректности (непротиворечивости содержания) БД в первом случае выше. Может получиться так, что часть кортежей поменяет значения атрибута Группа, а часть по причине сбоя в работе аппаратуры останет­ся в старом состоянии. И тогда наша БД будет содержать записи, которые отно­сят одного студента одновременно к разным группам. Чтобы этого не произошло, мы должны принимать дополнительные непростые меры, например, организовы­вать процесс согласованного изменения с использованием сложного механизма транзакций, который мы будем рассматривать в главах, посвященных вопросам распределенного доступа к БД. Если же мы перешли ко второй нормальной форме, то мы меняем только один кортеж. Кроме того, если у нас есть студенты, которые еще не сдавали экзамены, то в исходном отношении мы вообще не мо­жем хранить о них информацию, а во второй схеме информация о студентах и их принадлежности к конкретной группе хранится отдельно от информации, ко­торая связана со сдачей экзаменов, и поэтому мы можем в этом случае отдельно работать со студентами и отдельно хранить и обрабатывать информацию об ус­певаемости и сдаче экзаменов, что в действительности и происходит.

ОПРЕДЕЛЕНИЕ

Отношение находится в третьей нормальной 4юрме тогда и только тогда, когда оно нахо­дится во второй нормальной форме и не содержит транзитивных зависимостей.

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

(ФИО, Номер зач.кн., Группа. Факультет, Специальность, Выпускающая кафедра)

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

Номер зач.кн. -> ФИО

Номер зач.кн. -> Группа

Номер зач.кн. -> Факультет

Номер зач.кн. -> Специальность

Номер зач.кн. -> Выпускающая кафедра

Группа -> Факультет

Группа -> Специальность

Группа -> Выпускающая кафедра

Выпускающая кафедра -> Факультет

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

(Номер.зач.кн., ФИО., Специальность. Группа)

(Группа. Выпускающая кафедра)

(Выпускающая- кафедра; Факультет)

Первичные ключи отношений выделены.

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

Полученный набор отношений находится в третьей нормальной форме.

ОПРЕДЕЛЕНИЕ

Отношение находится в нормальной форме Бойса—Кодда, если оно находится в третьей нормальной форме и каждым детерминант отношения является возможным ключом от­ношения.

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

(Номер зач.кн., Идентификатор_студента, Дисциплина, Дата. Оценка)

Возможными ключами отношения являются Номер_зач.кн, Дисциплина, Дата и Иден-тификатор_студента, Дисциплина, Дата. ,

Какие функциональные зависимости у нас имеются?

Номер_зач.кн, Дисциплина, Дата -> Оценка:

Идентификатор_студента, Дисциплина. Дата -> Оценка;

Номер зач.кн. -> Идентификатор_студента:

Идентификатор_студента -> Номер зач.кн.

• Откуда взялись две последние функциональные зависимости? Но ведь мы предварительно описали, что каждому студенту ставится в соответствие один номер зачетной книжки и один Идентификатор_студента, поэтому по значению Номер зач.кн. можно однозначно определить Идентификатор_студента (это третья зависимость) и обратно (и это четвертая зависимость). Оценим это отноше­ние.

• Это отношение находится в третьей нормальной форме, потому что непол­ных функциональных зависимостей не первичных атрибутов от атрибутов возможного ключа здесь не присутствует и нет транзитивных зависимостей. А как же третья и четвертая зависимости, разве они не являются неполны­ми? Нет, потому что зависимым не является не первичный атрибут, то есть атрибут, не входящий ни в один возможный ключ. Поэтому придраться к этому мы не можем. Но вот под четвертую нормальную форму наше отноше­ние не подходит, потому что у нас есть два детерминанта Номер зач.кн. и Идентификатор_студента, которые не являются возможными ключами отноше­ния. Для приведения отношения к нормальной форме Бойса-Кодда надо разделить отношение, например, на два со следующими схемами:

(Идентификатор_студента. Дисциплина, Дата, Оценка)

(Номер зач.кн. Идентификатор_студента)

или наоборот:

(Номер зач.кн.. Дисциплина. Дата. Оценка)

(Номер зач.кн. Идентификатор_студента)

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

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

ОПРЕДЕЛЕНИЕ

В отношении R (А, В, С) существует многозначная зависимость (multi valid dependence, MVD) R.A -» R.B в том и только в том случае, если множество значений В, соответ­ствующее паре значений А и С, зависит только от А и не зависит от С.

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

(Номер зач.кн. Группа. Дисциплина)

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

В данном отношении существуют следующие две многозначные зависимости:

Группа -» Дисциплина Группа -» Номер зач.кн.

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

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

В теории реляционных баз данных доказывается, что в общем случае в отноше­нии R (А, В, С) существует многозначная зависимость R.A -» R.B в том и только в том случае, когда существует многозначная зависимость R.A -» R.C.

Дальнейшая нормализация отношений, подобных нашему, основывается на тео­реме Фейджина.

ТЕОРЕМА ФЕЙДЖИНА

Отношение R (А, В, С) можно спроецировать без потерь в отношения R1 (А, В) и R2 (А, С) в том и только в том случае, когда существует MVD А -» В | С ( что равнозначно нали­чию двух зависимостей А -» В и А -» С).

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

ОПРЕДЕЛЕНИЕ

Отношение R находится в четвертой нормальной форме (4NF) в том и только в том слу­чае, если в случае существования многозначной зависимости А -» В все остальные атри­буты R функционально зависят от А.

В нашем примере можно произвести декомпозицию исходного отношения в два отношения:

(Номер зач. кн., Группа) (Группа, Дисциплина)

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

Последней нормальной формой является пятая нормальная форма 5NF, которая связана с анализом нового вида зависимостей, зависимостей «проекции соедине­ния» (project-join зависимости, обозначаемые как PJ-зависимости). Этот вид зависимостей является в некотором роде обобщением многозначных зависимостей.

ОПРЕДЕЛЕНИЕ

Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих про­екций на X, Y, ..., Z. Здесь X, Y, ..., Z — наборы атрибутов отношения R.

Наличие PJ-зависимости в отношении делает его в некотором роде избыточным и затрудняет операции модификации.

ОПРЕДЕЛЕНИЕ

Отношение R находится в пятой нормальной форме (нормальной форме проекции-соеди­нения — PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.

Рассмотрим отношение R1:

R1 (Преподаватель, Кафедра, Дисциплина).

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

Введем следующие обозначения наборов атрибутов:

ПК (Преподаватель, Кафедра)

ПД (Преподаватель. Дисциплина)

КД (Кафедра. Дисциплина)

Допустим, что отношение R1 удовлетворяет зависимости проекции соединения (ПК, ПД, КД). Тогда отношение R1 не находится в NF/PJ, потому что един­ственным ключом его является полный набор атрибутов, а наличие зависимости PJ связано с наборами атрибутов, которые не составляют возможные ключи от­ношения R1. Для того чтобы привести это отношение к NF/PJ, его надо пред­ставить в виде трех отношений:

R2 (Преподаватель. Кафедра)

R3 (Преподаватель. Дисциплина)R4 (Кафедра, Дисциплина)

Пятая нормальная форма редко используется на практике. В большей степени она является теоретическим исследованием. Очень тяжело определить само на­личие зависимостей «проекции—соединения», потому что утверждение о нали­чии такой зависимости делается для всех возможных состояний БД, а не только для текущего экземпляра отношения R1. Однако знание о возможном наличии подобных зависимостей, даже теоретическое, нам все же необходимо.

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

63. Я зык запросов SQL. Оператор языка SQL для создания и изменения структуры таблицы баз данных.

Создание БД

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

В указанной иерархии в стандарте предусмотрены только средства регламен­тации механизма создания и удаления схем — самой нижней ступени дан­ной иерархии. Механизмы создания всего остального закладываются в саму СУБД. Оператор создания схемы БД определяется следующим образом:

CREATE SCHEMA [ Имя_схемы | AUTHORIZATION Имя_пользователя]

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

CREATE SCHEMA ФАКУЛЬТЕТ AUTHORIZATION Иванов;

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

DROP SCHEMA Имя_схемы [RESTRICT | CASCADE]

По умолчанию принимается установка режима restrict, при которой уда­ление выполняется только в том случае, если схема пуста. В противном слу­чае данный оператор не выполняется. Использование альтернативного ре­жима cascade должно производиться с большой осторожностью, так как реализация его приводит к автоматическому удалению всех связанных с уда­ляемой схемой объектов.

Хотя рассмотренные два оператора определены в стандарте, на практике они реализованы в очень редких случаях. Вместо операторов create schema и drop schema успешно используются не нуждающиеся в дополнительных пояснениях операторы:

CREATE DATABASE Имя_БД

DROP DATABASE Имя_ БД

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

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

1. Создание, изменение структуры и удаление таблицы

Главными компонентами базы данных являются ее таблицы, представляющие отношения проекта БД. Создание таблицы осуществляется посредством оператора create table. Его упрощенная версия выглядит сле­дующим образом:

CREATE TABLE Имя_таблицы ( Имя_столбца Тип_даных [NULL | NOT NULL ] [,...])

Оператор такого вида приведет к созданию таблицы с именем <Имя_таблицы>, которая будет содержать столько столбцов, сколько их зада­но в операторе. При определении столбца необходимо задать его имя, тип данных, к которому будут относиться значения этого столбца, а также опре­делить, можно ли в качестве значения рассматриваемого столбца использо­вать ключевое слово null. Ключевым словом null помечается такой стол­бец, который может содержать неопределенные значения. Такая ситуация возможна для столбцов, соответствующих непервичным атрибутам отноше­ния. Определения столбцов первичных ключей отношений всегда должны содержать ключевые слова not null. Любая попытка ввести в такой столбец NULL-значение будет отвергнута, и, следовательно, будет заблокирована возможность нарушения ссылочной целостности данных. По причинам, об­суждавшимся ранее, использование NULL-значений очень часто запрещают и для столбцов внешних ключей.

Для того чтобы создать таблицу БД СЕССИЯ, необходимо использовать оператор вида

CREATE TABLE S1 (

ФИО VARCHAR (20) NOT NULL,

Дисциплина VARCHAR (20) NOT NULL,

Оценка SMALLINT NOT NULL);

В данном определении таблицы указаны три столбца, типы данных этих столбцов, и все они помечены определителем not null. Запрет на NULL-значения в данной таблице введен не из соображений поддержки целостно­сти данных, а из стремления иметь в таблице только тех студентов, которые успешно сдали экзамены. Если же допустить присутствие в таблице всех студентов, которые должны были сдавать определенные для группы экзаме­ны, то естественно допустить для столбца Оценка NULL-значения для тех студентов, кто по той или иной причине не сдавал экзамен. Оператор в этом случае примет вид

CREATE TABLE S1 (

ФИО VARCHAR (20) NOT NULL,

Дисциплина VARCHAR (20) NOT NULL,

Оценка SMALLINT);

Полное описание оператора create table должно включать средства под­держки целостности данных. Такие средства представляют собой специфи­каторы, позволяющие задать ограничения для предотвращения попыток на­рушить согласованность данных. Базовое определение оператора create table имеет следующий формат:

CREATE TABLE имя_таблицы

({ имя_столбца тип_даных [NOT NULL] [UNIQUE]

[DEFAULT значение по умолчанию] [CHECK (условие проверки на допустимость)] [,...]}

[PRIMARY KEY (список столбцов),]

{[UNIQUE (список столбцов),] [,...]}

{[FORING KEY (список столбцов внешних ключей)

REFERENCES имя родительской таблицы [(список столбцов ключей-кандидатов)],

[MATCH {PARTIAL | FULL}

[ON UPDATE правило ссылочной целостности]

[ON DELETE правило ссылочной целостности]] [,...]}

{[CHECK (условие проверки на допустимость)] [,...]})

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

□ контроль возможности использовать NULL-значения;

□ ограничения для доменов атрибутов;

□ категорная целостность;

□ ссылочная целостность;

□ ограничения предметной области.

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

Спецификатор check предназначен для задания ограничений для доменов атрибутов. Так, например, для столбца Оценка можно задать следующее оп­ределение:

Оценка SMALLINT CHECK(Оценка >= 2 AND Оценка <= 5);

Присутствие в определении таблицы строки со спецификатором primary Key призвано обеспечить категорную целостность данных. Обеспечение категорной целостности состоит в том, что первичный ключ таблицы должен иметь уникальное непустое значение в каждой ее строке. Первичный ключ Таблицы S1 является составным и включает два столбца (ФИО, Дисциплина), его можно определить следующей фразой:

PRIMARY KEY (ФИО, Дисциплина).

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

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

Например, чтобы связать таблицы S1 и S2 базы данных Сессия, таблицу S2 необходимо определить как родительскую с первичным ключом фио, а таб­лицу S1 — как дочернюю. В таблице S1 столбец ФИО является внешним ключом, который должен обязательно ссылаться на первичный ключ табли­цы S2, так как экзамены в сессию могут сдавать только студенты, обучаю­щиеся в определенной группе и присутствующие в таблице S2. Таким обра­зом, для таблицы S1 необходимо определить внешний ключ, для чего служит фраза foring key. Данный ключ определяется следующим образом:

FORING KEY ФИО REFERENCES S2.

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

В операторе create table есть средства регламентировать деятельность сис­темы и в случаях обновления информации посредством таких операторов, как update и delete. Поддержка ссылочной целостности предполагает рег­ламентацию поведения системы в случае попытки с помощью операторов update или delete обновить или удалить значение потенциального ключа в родительской таблице, если с ним связана хотя бы одна строка дочерней таблицы. Указанная регламентация осуществляется посредством фраз on update и on delete предложения foring key. Пользователь должен выбрать один из возможных квалификаторов:

□ cascade — удаление (изменение) строки из родительской таблицы при­ водит к автоматическому удалению (изменению) всех ссылающихся на нее строк дочерней таблицы; если дочерняя таблица связана с другими таблицами, то изменения распространяются далее аналогичным образом;

□ set null — удаление строки из родительской таблицы приводит к авто­матическому присвоению внешним ключам ссылающихся строк дочер­ ней таблицы NULL-значений; этот вариант может использоваться только в том случае, если в определений столбца внешнего ключа отсутствует ключевое слово not null;

□ set default — удаление строки из родительской таблицы приводит к автоматическому присвоению внешним ключам ссылающихся строк дочерней таблицы значений, принимаемых по умолчанию; этот вариант может использоваться только в том случае, если в определении столбца внешнего ключа присутствует ключевое слово default и задано значе­ние, используемое по умолчанию;

□ no action — удаление (изменение) строки из родительской таблицы от­меняется; этот квадификатор используется по умолчанию также и в том случае, когда фраза on delete (on update) опущена.

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

Способ обработки значений внешнего ключа может быть уточнен определи­телем match. Если для таблицы указывается определитель match full, to предполагается, что все компоненты внешнего ключа имеют либо некоторое конкретное значение, либо значение null.

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

Исходя из сказанного, перепишем оператор создания таблицы S1 БД Сессия следующим образом:

CREATE TABLE S1 (

ФИО VARCHAR (20) NOT NULL,

Дисциплина VARCHAR (20) NOT NULL,

Оценка SMALLINT NOT NULL);

PRIMARY KEY (ФИО, Дисциплина),

PORING KEY ФИО REFERENCES S2 ;

ON UPDATE CASCADE

ON DELETE CASCADE);

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

Обновление таблиц

В уже созданную таблицу изменения могут быть внесены с помощью опера­тора alter table, который имеет следующий обобщенный формат:

ALTER TABLE имя_таблицы [ADD [COLUMN] имя столбца тип_даных [NOT NULL] [UNIQUE]

[DEFAULT значение по умолчанию] [CHECK (условие проверки на допустимость)]]

[DROP [COLUMN] ] имя_столбца [RISTRICT | CASCADE]] [ADD [CONSTRAINT [имя ограничения]] ограничение] [DROP CONSTRAINT имя ограничения [RISTRICT | CASCADE]] [ALTER [COLUMN] SET DEFAULT значение по умолчанию] [ALTER [COLUMN] DROP DEFAULT]

В данном формате предусмотрены возможности для выполнения ряда дей­ствий:

О добавить новый столбец в существующую таблицу — add column;

удалить столбец из существующей таблицы — drop column;

добавить в определение таблицы новое ограничение — add constraint;

удалить из определения таблицы существующее ограничение — drop constraint;

задать для существующего столбца значение по умолчанию — alter

[COLUMN] SET DEFAULT;

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

[COLUMN] DROP DEFAULT.

Параметр "ограничение" во фразе add constraint может принимать одно из следующих значений: primary key, unique, foring key, check. Таким обра­зом, используя эту фразу можно определять первичные, потенциальные и внешние ключи и задавать дополнительные ограничения.

Фразы, связанные с удалением компонентов таблиц, — будь то столбец или ограничения, содержат дополнительный квалификатор, позволяющий уточ­нить порядок удаления:

□ cascade — удаление осуществляется каскадным образом с удалением ссылок на удаляемый компонент;

□ ristrict — удаление отменяется, если существуют ссылки на удаляемый компонент; это значение квалификатора используется по умолчанию.

Значения остальных указанных в операторе alter table параметров совпа­дают со значениями параметров в определении оператора create table.

Одним оператором alter table можно провести только одно изменение таблицы, например, за один раз можно добавить один столбец. Чтобы доба­вить два столбца в таблицу, необходимо использовать два оператора.

Добавить в таблицу S1 столбец Группа, содержащий символьный тип дан­ных, можно с помощью оператора:

ALTER TABLE S1

ADD Группа varchar (7) NOT NULL

Удаление таблиц

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

DROP TABLE имя таблицы [RISTRICT | CASCADE].

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

Удалим таблицу S1:

DROP TABLE S1;

В данном операторе ключевые слова ristrict и cascade не использовались, так как таблиц, зависимых от таблицы S1, в базе данных нет.

63. Назначение и формат оператора SELECT. Простые и сложные критерии отбора записей в операторе SELECT.

Синтаксис оператора Select

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

Синтаксис оператора select:

SELECT [DISTINCT| ALL] {*| [<список полей>]} FROM <список таблиц>

[WHERE <предикат-условие выборки или соединения>]

[GROUP BY <список полей результата>]

[HAVING <предикат-условие для группы>]

[ORDER BY <список полей, по которым требуется упорядочить вывод>]

Указанный порядок следования фраз в операторе select не может быть из­менен, но не все его части являются обязательными. К обязательным пред­ложениям относятся только фразы select и from. Все остальные части опе­ратора могут быть использованы по усмотрению программиста. Поясним каждую фразу данного оператора.

□ Фраза select:

• наличие ключевого слова all (по умолчанию) означает, что в результирующую таблицу включаются все строки, удовлетворяющие услови­ям запроса, что может привести к появлению в результирующей таблице одинаковых строк;

• ключевое слово distinct предназначено для приведения таблицы в соответствие с принципами теории отношений, где предполагается отсутствие дубликатов строк;

• символ "*" определяет очень часто встречаемую ситуацию, когда в ре­зультирующий набор включаются все столбцы из исходной таблицы запроса. Таким образом, программист может выбрать один из воз­можных вариантов формирования результирующих таблиц: включение только указанных столбцов или включение всех столбцов таблицы.

• Во фразе from задается перечень исходных таблиц запроса.

• Во фразе where определяются условия отбора строк результата или условия соединения строк исходных таблиц, подобно операции условного со­единения в реляционной алгебре. exist и not exist, используемые во встроенных подзапросах.

• Во фразе group by задается список полей группировки.

• Во фразе having задаются предикаты-условия, накладываемые на каждую группу.

• Во фразе order by задается список полей упорядочения результата, то есть список полей, который определяет порядок сортировки в результи­рующей таблице.

Рассмотрим ряд простых запросов.

Запрос 1

Вывести сведения о кафедрах университета.

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

SELECT * FROM kafedra;

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

Kod_kaf Name_kaf Nom_telef Nom_Auditoria Col_sotr Zav_kaf

001	Физики	23-34-24	132	25	Иванов Т.М.
002	Общей математики	23-65-43	003	22	Махов К.Л.
003	Истории	23-78-72	465	16	Росс Л.Т.
004	Графики	23-99-77	385	18	Фирсов С.С.
005	Прикладной математики	23-66-62	028	24	Ляхова И.Т.

Запрос 2

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

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

SELECT Name_kaf, Nom_telef FROM kafedra;

Результирующая таблица приведена ниже:

Name_kaf	Nom_telef
Физики	23-34-24
Общей математики	23-65-43
Истории	23-78-72
Графики	23-99-77
Прикладной математики	23-66-62

До сих пор в запросах использовались только два обязательных предложе­ния select, from и предложение для указания условия поиска where.

Рассмотрим ряд запросов с использованием других фраз.

В общем случае строки в результирующей таблице выводятся в неупорядо­ченном каким-либо образом состоянии. Просматривать и анализировать такой материал не всегда удобно. Для сортировки строк по какому-либо столбцу применяется фраза order by. Она включает список разделенных запятыми наименований столбцов, по которым требуется упорядочить вы­водимую информацию. Данная фраза должна всегда располагаться послед­ней в операторе select и при ее наличии появляется возможность отсорти­ровать строки по возрастанию (asc) или убыванию (desc) значений указанного столбца или комбинации указанных столбцов, независимо от того, присутствуют эти столбцы в результирующей таблице или нет.

Запрос 5

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

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

SELECT *

FROM kafedra

ORDER BY Name_kaf ASC;

Kod_kaf	Name_kaf	Nom_telef	Nom_Auditoria	Col_sotr	Zav_kaf
002	Общей математики	23-65-43	003	22	Малахов К. Л.
005	Прикладной математики	23-66-62	028	24	Ляхова И.Т.
001	Физики	23-34-24	132	25	Иванов Т. М.

Результат данного запроса:

Kod_kaf	Name_kaf	Nom_telef	Nom_Auditoria	Col_sotr	Zav_kaf
004	Графики	23-99-77	385	18	Фирсов С.С.
003	Истории	23-78-72	465	16	Росс Л.Т.

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

Задание условий отбора

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

• сравнения " = , <>, >, <, >=, <=" - для сравнения результатов вы­ числения двух выражений; более сложные выражения строятся с по­ мощью логических операторов AND, OR, NOT; значения выражений вычисляются в порядке, который определяется приоритетом исполь­ зуемых операторов и наличием скобок в выражении;

• between a and в — предикат истинен, когда вычисленное значение выражения попадает в заданный диапазон (предикат not between a and в истинен тогда, когда сравниваемое значение не попадает в за­ данный интервал);

• in — предикат истинен тогда, когда сравниваемое значение входит в множество заданных значений; при этом множество значений может быть задано простым перечислением или встроенным подзапросом (предикат not in истинен тогда, когда сравниваемое значение не вхо­ дит в заданное множество);

• like и not like — предикаты, смысл которых противоположен, тре­ буют задания шаблона, с которым сравнивается заданное значение; предикат like истинен тогда, когда сравниваемое значение соответст­ вует шаблону, и ложен в противном случае;

• is null — предикат, применяющийся для выявления равенства зна­ чения некоторого атрибута неопределенному значению:

- <имя атрибута> is null — принимает значение true, если в дан­ной строке указанный атрибут имеет неопределенное значение и значение false, в противном случае: - <имя атрибута> IS NOT NULL — все ПРОИСХОДИТ Наоборот.

Рассмотрим несколько примеров.

Запрос 3

Вывести сведения о кафедре графики. Запрос будет выглядеть следующим образом:

SELECT * FROM kafedra

WHERE Name_kaf = 'Графики';

Ответ на такой запрос будет содержать только одну строку:

Kod_kaf	Nom_kaf	Nom_telef	Nom_auditoria	Col_sotr	Zav_kaf
004	Графики	23-99-77	385	18	Фирсов С.С.

Посмотрим, как работают другие предикаты, например between a and в.

Запрос 4

Вывести сведения о кафедрах университета, находящихся на первом этаже, учитывая тот факт, что номера аудиторий первого этажа лежат в диапазо­не от 1 до 99.

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

SELECT *

FROM kafedra

WHERE Nom_Auditoria BETWEEN 1 AND 99;

Результат запроса:

Kod_kaf	Name_kaf	Nom_telef	Norn_Auditoria	Col_sotr	Zav_kaf
002	Общей математики	23-65-43	003	22	Махов К.Л.
005	Прикладной математики	23-66-62	028	24	Ляхова И.Т.