Операции над данными

Модель данных определяет множество действий, которые допустимо производить над некоторой реализацией БД для её перевода из одного состояния в другое. Это множество соотносят с языком манипулирования данными (Data Manipulation Language, DML).

Любая операция над данными включает в себя селœекцию данных (select), то есть выделœение из всœей совокупности именно тех данных, над которыми должна быть выполнена требуемая операция, и действие над выбранными данными, ĸᴏᴛᴏᴩᴏᴇ определяет характер операции. Условие селœекции - ϶ᴛᴏ некоторый критерий отбора данных, в котором бывают использованы логическая позиция элемента данных, его значение и связи между данными.

По типу производимых действий различают следующие операции:

• идентификация данных и нахождение их позиции в БД;
• выборка (чтение) данных из БД;
• включение (запись) данных в БД;
• удаление данных из БД;
• модификация (изменение) данных БД.

Обработка данных в БД осуществляется с помощью процедур базы данных – транзакций. Транзакцией называют упорядоченное множество операций, переводящих БД из одного согласованного состояния в другое. Транзакция либо выполняется полностью, ᴛ.ᴇ. выполняются всœе входящие в неё операции, либо не выполняется совсœем, в случае если в процессе её выполнения возникает ошибка.

Ограничения целостности - ϶ᴛᴏ правила, которым должны удовлетворять значения элементов данных. Ограничения целостности делятся на явные и неявные .

Неявные ограничения определяются самой структурой данных. К примеру, тот факт, что запись типа СОТРУДНИК имеет поле Дата рождения , служит, по существу, ограничением целостности, означающим, что каждый сотрудник организации имеет дату рождения, причём только одну.

Явные ограничения включаются в структуру базы данных с помощью средств языка контроля данных (DCL, Data Control Language). В качестве явных ограничений чаще всœего выступают условия, накладываемые на значения данных. К примеру, номер паспорта является уникальным, зарплата не должна быть отрицательной, а дата приёма сотрудника на работу обязательно будет меньше, чем дата его перевода на другую работу.

Также различают статические и динамические ограничения целостно-сти. Статические ограничения присущи всœем состояниям ПО, а динамические определяют возможность перехода ПО из одного состояния в другое. Примерами статических ограничений целостности могут служить требование уникальности индивидуального номера налогоплательщика (ИНН) или задание ограниченного множества значений атрибута "Пол" ("м" и "ж"). В качестве примера динамического ограничения целостности можно привести правило, ĸᴏᴛᴏᴩᴏᴇ распространяется на поля-счётчики: значение счётчика не может уменьшаться.

За выполнением ограничений целостности следит СУБД в процессе своего функционирования. Она проверяет ограничения целостности каждый раз, когда они бывают нарушены (к примеру, при добавлении данных, при удалении данных и т.п.), и гарантирует их соблюдение. В случае если какая-либо команда нарушает ограничение целостности, она не будет выполнена и система выдаст соответствующее сообщение об ошибке. К примеру, в случае если задать в качестве ограничения правило ʼʼОстаток денежных средств на счёте не должна быть отрицательнымʼʼ, то при попытке снять со счёта денег больше, чем там есть, система выдаст сообщение об ошибке и не позволит выполнить эту операцию. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, ограничения целостности обеспечивают логическую непротиворечивость данных при переводе БД из одного состояния в другое.

Сегодня разработано много различных моделœей данных. Основные - ϶ᴛᴏ сетевая, иерархическая и реляционная модели.

Ограничения целостности - понятие и виды. Классификация и особенности категории "Ограничения целостности" 2017, 2018.

- Ограничения целостности

Манипулирование данными Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие: Найти указанное дерево БД (например, отдел 310); Перейти от одного дерева к другому; Перейти от одной записи к другой внутри дерева... .

- Ограничения целостности в модели сущность-связь

Здесь рассматриваются три типа ограничений: 1. Ограничения на допустимые значения в множестве значений. Атрибут отображает сущность из множества сущностей на множество значений. Допустимые значения определяются значениями в соответствующем множестве значений.... .

- Ограничения целостности

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

Операции над данными

Модель данных определяет множество действий, которые допустимо производить над некоторой реализацией БД для её перевода из одного состояния в другое. Это множество соотносят с языком манипулирования данными (Data Manipulation Language, DML).

Любая операция над данными включает в себя селекцию данных (select), то есть выделение из всей совокупности именно тех данных, над которыми должна быть выполнена требуемая операция, и действие над выбранными данными, которое определяет характер операции. Условие селекции – это некоторый критерий отбора данных, в котором могут быть использованы логическая позиция элемента данных, его значение и связи между данными.

По типу производимых действий различают следующие операции:

• идентификация данных и нахождение их позиции в БД;
• выборка (чтение) данных из БД;
• включение (запись) данных в БД;
• удаление данных из БД;
• модификация (изменение) данных БД.

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

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

Неявные ограничения определяются самой структурой данных. Например, тот факт, что запись типа СОТРУДНИК имеет поле Дата рождения , служит, по существу, ограничением целостности, означающим, что каждый сотрудник организации имеет дату рождения, причём только одну.

Явные ограничения включаются в структуру базы данных с помощью средств языка контроля данных (DCL, Data Control Language). В качестве явных ограничений чаще всего выступают условия, накладываемые на значения данных. Например, номер паспорта является уникальным, заработная плата не может быть отрицательной, а дата приёма сотрудника на работу обязательно будет меньше, чем дата его перевода на другую работу.

Также различают статические и динамические ограничения целостно-сти. Статические ограничения присущи всем состояниям ПО, а динамические определяют возможность перехода ПО из одного состояния в другое. Примерами статических ограничений целостности могут служить требование уникальности индивидуального номера налогоплательщика (ИНН) или задание ограниченного множества значений атрибута "Пол" ("м" и "ж"). В качестве примера динамического ограничения целостности можно привести правило, которое распространяется на поля-счётчики: значение счётчика не может уменьшаться.

За выполнением ограничений целостности следит СУБД в процессе своего функционирования. Она проверяет ограничения целостности каждый раз, когда они могут быть нарушены (например, при добавлении данных, при удалении данных и т.п.), и гарантирует их соблюдение. Если какая-либо команда нарушает ограничение целостности, она не будет выполнена и система выдаст соответствующее сообщение об ошибке. Например, если задать в качестве ограничения правило «Остаток денежных средств на счёте не может быть отрицательным», то при попытке снять со счёта денег больше, чем там есть, система выдаст сообщение об ошибке и не позволит выполнить эту операцию. Таким образом, ограничения целостности обеспечивают логическую непротиворечивость данных при переводе БД из одного состояния в другое.

В настоящее время разработано много различных моделей данных. Основные – это сетевая, иерархическая и реляционная модели.

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

Таблицы с ограничениями в стандарте языка

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

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

Большая часть перечисленных ограничений задается в операторах CREATE TABLE и ALTER TABLE .

Создание таблицы

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

<определение_таблицы> ::= CREATE TABLE имя_таблицы {(имя_столбца тип_данных [ NOT NULL ][ UNIQUE] [ CHECK (<условие_выбора>)][,...n]} ) {)} ) REFERENCES имя_род_таблицы [(имя_столбца_род_таблицы [,...n])], {[,...n]})

Ограничения

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

Обязательные данные

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

Требования конкретного предприятия

Обновления данных в таблицах могут быть ограничены существующими в организации требованиями (бизнес-правилами). Стандарт SQL позволяет реализовать бизнес-правила предприятий с помощью предложения CHECK и ключевого слова UNIQUE .

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

Каждый столбец имеет собственный домен - некоторый набор допустимых значений. Стандарт SQL предусматривает два различных механизма определения доменов. Первый состоит в использовании предложения CHECK , позволяющего задать требуемые ограничения для столбца или таблицы в целом, а второй предполагает применение оператора CREATE DOMAIN .

Целостность сущностей

Первичный ключ таблицы должен иметь уникальное непустое значение в каждой строке. Стандарт SQL позволяет задавать подобные требования поддержки целостности данных с помощью фразы PRIMARY KEY . В пределах таблицы она может указываться только один раз. Однако существует возможность гарантировать уникальность значений и для любых альтернативных ключей таблицы, что обеспечивает ключевое слово UNIQUE . Кроме того, при определении альтернативных ключей рекомендуется использовать и спецификаторы NOT NULL .

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

Внешние ключи представляют собой столбцы или наборы столбцов, предназначенные для связывания каждой из строк дочерней таблицы, содержащей этот внешний ключ , со строкой родительской таблицы, содержащей соответствующее значение потенциального ключа. Стандарт SQL предусматривает механизм определения внешних ключей с помощью предложения FOREIGN KEY , а фраза REFERENCES определяет имя родительской таблицы, т.е. таблицы, где находится соответствующий потенциальный ключ. При использовании этого предложения система отклонит выполнение любых операторов INSERT или UPDATE , с помощью которых будет предпринята попытка создать в дочерней таблице значение внешнего ключа , не соответствующее одному из уже существующих значений потенциального ключа родительской таблицы. Когда действия системы выполняются при поступлении операторов UPDATE и DELETE , содержащих попытку обновить или удалить значение потенциального ключа в родительской таблице, которому соответствует одна или более строк дочерней таблицы, то они зависят от правил поддержки ссылочной целостности , указанных во фразах ON UPDATE и ON DELETE предложения FOREIGN KEY . Если пользователь предпринимает попытку удалить из родительской таблицы строку, на которую ссылается одна или более строк дочерней таблицы, язык SQL предоставляет следующие возможности:

• CASCADE - выполняется удаление строки из родительской таблицы, сопровождающееся автоматическим удалением всех ссылающихся на нее строк дочерней таблицы;
• SET NULL - выполняется удаление строки из родительской таблицы, а во внешние ключи всех ссылающихся на нее строк дочерней таблицы записывается значение NULL ;
• SET DEFAULT - выполняется удаление строки из родительской таблицы, а во внешние ключи всех ссылающихся на нее строк дочерней таблицы заносится значение, принимаемое по умолчанию;
• NO ACTION - операция удаления строки из родительской таблицы отменяется. Именно это значение используется по умолчанию в тех случаях, когда в описании внешнего ключа фраза ON DELETE опущена.

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

Определитель MATCH позволяет уточнить способ обработки значения NULL во внешнем ключе .

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

В операторе CREATE TABLE используется необязательная фраза DEFAULT , которая предназначена для задания принимаемого по умолчанию значения, когда в операторе INSERT значение в данном столбце будет отсутствовать.

Фраза CONSTRAINT позволяет задать имя ограничению, что позволит впоследствии отменить то или иное ограничение с помощью оператора ALTER TABLE .

Изменение и удаление таблицы

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

• добавление в таблицу нового столбца;
• удаление столбца из таблицы;
• добавление в определение таблицы нового ограничения;
• удаление из определения таблицы существующего ограничения;
• задание для столбца значения по умолчанию;
• отмена для столбца значения по умолчанию.

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

<изменение_таблицы> ::= ALTER TABLE имя_таблицы имя_столбца тип_данных [ NOT NULL ] [ CHECK (<условие_выбора>)]] имя_столбца ] ] [{PRIMARY KEY (имя_столбца [,...n]) |)} |) REFERENCES имя_род_таблицы [(имя_столбца_род_таблицы [,...n])], [ MATCH {PARTIAL | FULL} |[,...n]}] ] SET DEFAULT <значение>] DROP DEFAULT]

Здесь параметры имеют то же самое назначение, что и в определении оператора CREATE TABLE .

Оператор ALTER TABLE реализован не во всех диалектах языка SQL. В некоторых диалектах он поддерживается, однако не позволяет удалять из таблицы уже существующие столбцы.

Для удаления таблицы используется команда DROP TABLE .

Таблицы в среде MS SQL Server

Создание таблицы

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

• Столбцы какого типа и размера будут составлять каждую из таблиц, какие требуется выбрать имена для столбцов таблиц?
• Какие столбцы могут содержать значение 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 .

Ограничение уникального ключа (UNIQUE)

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

Ограничение на значение (NOT NULL)

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

Ограничение проверочное (CHECK) и правила

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

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

Допускается применение нескольких ограничений CHECK к одному и тому же столбцу. В этом случае они будут применимы в той последовательности, в которой происходило их создание. Возможно применение одного и того же ограничения к разным столбцам и использование в логических выражениях значений других столбцов. Указание параметра NOT FOR REPLICATION предписывает не выполнять проверочных действий, если они выполняются подсистемой репликации.

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

Правило может быть создано командой:

CREATE RULE имя_правила AS выражение

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

sp_bindrule [@rulename=] "rule" [@objname=] "object_name" [,[@futureonly=["futureonly_flag"]

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

sp_unbindrule [@objname=] "object_name" [,[@futureonly=["futureonly_flag"]

Удаление правила производится командой

DROP RULE {имя_правила} [,...n].

Ограничение по умолчанию (DEFAULT)

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

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

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

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

CREATE DEFAULT имя_умолчания AS константа

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

sp_bindefault [@defname=] "default", [@objname=] "object_name" [,[@futureonly=] "futureonly_flag"],

может быть представлен как

"имя_таблицы.имя_столбца"

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

DROP DEFAULT {имя_умолчания} [,...n]

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

sp_unbindefault [@objname=] "object_name" [,[@futureonly=] "futureonly_flag"]

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

Ключевые слова CLUSTERED и NONCLUSTERED позволяют создать для столбца кластерный или некластерный индекс . Для ограничения PRIMARY KEY по умолчанию создается кластерный индекс , а для ограничения UNIQUE - некластерный . В каждой таблице может быть создан лишь один кластерный индекс , отличительной особенностью которого является то, что в соответствии с ним изменяется физический порядок строк в таблице. ASC и DESC определяют метод упорядочения данных в индексе.

С помощью параметра WITH FILLFACTOR=фактор_заполнения задается степень заполнения индексных страниц при создании индекса. Значение фактора заполнения указывается в процентах и может изменяться в промежутке от 0 до 100.

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

Изменение таблицы

Изменения в таблицу можно внести командой:

<изменение_таблицы> ::= ALTER TABLE имя_таблицы {)] [ NULL | NOT NULL ] | {ADD | DROP } ROWGUIDCOL }] | ADD { [<определение_столбца>] | имя_столбца AS выражение } [,...n] | ADD { <ограничение-таблицы> } [,...n] | DROP { имя_ограничения | COLUMN имя_столбца}[,...n] | {CHECK | NOCHECK } CONSTRAINT {ALL | имя_ограничения[,...n]} | {ENABLE | DISABLE } TRIGGER {ALL | имя_триггера [,...n]}}

В дополнение к уже названным параметрам определим параметр {ENABLE | DISABLE } TRIGGER ALL_ , предписывающий задействовать или отключить конкретный триггер или все триггера, связанные с таблицей.

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

Удаление таблицы выполняется командой:

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

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

CREATE TABLE Товар (КодТовара INT IDENTITY(1,1) PRIMARY KEY, Название VARCHAR(50) NOT NULL UNIQUE, Цена MONEY NOT NULL, Тип VARCHAR(50) NOT NULL, Сорт VARCHAR(50) NOT NULL CHECK(сорт in("первый","второй","третий")), Город VARCHAR(50) NOT NULL, Остаток INT CHECK(остаток>=0)) Пример 9.1. Создание родительской таблицы Товар с ограничениями.

CREATE TABLE Клиент (КодКлиента INT IDENTITY(1,1) PRIMARY KEY, Фирма VARCHAR(50) NOT NULL, Фамилия VARCHAR(50) NOT NULL, Город VARCHAR(50) NOT NULL, Телефон CHAR(10) NOT NULL CHECK(Телефон LIKE "--")) Пример 9.2. Создание родительской таблицы Клиент с ограничениями.

CREATE TABLE Сделка (КодСделки INT IDENTITY(1,1) PRIMARY KEY, КодТовара INT NOT NULL, КодКлиента INT NOT NULL, Количество INT NOT NULL DEFAULT 0, Дата DATETIME NOT NULL DEFAULT GETDATE(), CONSTRAINT fk_Товар FOREIGN KEY(КодТовара) REFERENCES Товар, CONSTRAINT fk_Клиент FOREIGN KEY(КодКлиента) REFERENCES Клиент) Пример 9.3. Создание дочерней таблицы Сделка с ограничениями.

Пусть создана таблица без ограничений:

CREATE TABLE Товар (КодТовара INT, Название VARCHAR(20), Тип VARCHAR(20), Дата DATETIME, Цена MONEY, Остаток INT)

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

Пример 9.9. Поле КодТовара необходимо сделать первичным ключом. Выполнение следующей команды будет отвергнуто, поскольку поле КодТовара допускает внесение значений NULL .

ALTER TABLE Товар ADD CONSTRAINT pk1 PRIMARY KEY(КодТовара) Пример 9.9. Поле КодТовара необходимо сделать первичным ключом.

Сначала нужно изменить объявление столбца КодТовара , запретив внесение значений NULL :

ALTER TABLE Товар ALTER COLUMN КодТовара INT NOT NULL

И только потом создать ограничение первичного ключа:

Пример 9.10. Удалить столбец целого типа и добавить столбец-счетчик.

CREATE DEFAULT df1 AS 0 sp_bindefault "df1", "Товар.Остаток" CREATE DEFAULT df2 AS GETDATE() sp_bindefault "df2", "Товар.Дата" Пример 9.14. Создание и добавление умолчания столбцу.

Пример 9.15. Создать правило и добавить правило столбцу.

CREATE RULE r1 AS @m IN ("мебель","бытовая химия","косметика") sp_bindrule "r1","Товар.Тип" Пример 9.15. Создание и добавление правила столбцу.

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

Целостность сущностей описывается совокупностью ограничений которые должны выполняться для любых отношений в любых реляционных базах данных. Теоретики баз данных формулируют эти ограничения по-разному. Например, в называют «Условиями целостности … будем называть особые, отдельно хранящиеся данные, которыми на концептуальном уровне … представлено … правило (закон, критерий) принадлежности кортежей отношению, представленному этими данными (записями) в базе данных. К уровням целостности базы данных, как правило, присоединяются также спецификации условий принадлежности значений каждого из атрибутов реляционной таблицы к соответствующему ему домену в базе данных».

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

1. Все строки таблицы должны иметь одинаковую структуру, одно и то же количество атрибутов.

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

3. Значения атрибутов должны быть атомарными.

4. Значения каждого атрибута должны быть взяты из некоторого фиксированного множества значений (домена).

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

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

1. отсутствие кортежей-дубликатов (данное требование предъявляется лишь к атрибутам первичных ключей);

2. отсутствие атрибутов с множественным характером значений.

1. Найти соответствие условий целостности из условиям, названным выше, (1 – 4).

2. Составить перечень атрибутов для сведений об адресе отношения СОТРУДНИК, обеспечивающих атомарность.

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

Пример 1. Рассмотрим отношение СОТРУДНИКИ с внешним ключом «Код отдела» и связано с отношением ОТДЕЛЫ с первичным ключом «Код отдела» (см. рис. 8). Если существует сотрудник Волков И. И., работающий в отделе О1, то соответствующий отдел должен существовать и данные о нем должны храниться в таблице ОТДЕЛЫ .

Отношение Сотрудники

Отношение Отделы

Пример 2. Связь между таблицами Студент и Сдал осуществляется по полю НОМЕР_Зачетки, это связь типа один-ко-многим (1:М). Причем главной является таблица Студент, а подчиненной - таблица Сдал, т.к. в ней возможно любое количество записей со значением в поле НОМЕР_Зачетки, которое в таблице Студент может быть только один раз. Поле связи должно быть обязательно первичным ключом главной таблицы. Главную таблицу иногда называют родительской, а подчиненную - дочерней.

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

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

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

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

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

Задания для самостоятельной работы

1. Добавить в таблицу СОТРУДНИКИ запись о Фроловой О.А., работающей в отделе кадров. Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.

2. Удалить из таблицы ОТДЕЛЫ запись со значением атрибута Краткое_наим_отдела «ЛИД». Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.

Замечания

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

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

Все операции над базой данных сводятся к манипуляциям с записями и полями таблиц. Обращаясь к нашему студенческому архиву (см. Таб.1), возможно, захочется узнать, кто из студентов учится в группе 407 – ответ: Сидоров (запись 3) и Соловьев (запись 4). Другой пример: кто среди студентов самый старший – ответ: Петров (запись 2). Это примеры простейших операций выборки.

Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное счисление .

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

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

Набор операций, предложенный Коддом, содержит восемь операций:

1)теоретико-множественные операции, такие как объединение, пересечение, разность и декартово произведение, а ко второму - селекция, проекция, соединение и деление

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

Пример 1. Объединение. R3 = R1 È R2

Пусть отношение R1 - это таблица «Абитуриенты - победители олимпиады», а R2 - таблица «Абитуриенты, прошедшие по конкурсу на основании экзаменов».

Таблица Абитуриенты - победители олимпиады.

Таблица Абитуриенты, прошедшие по конкурсу на основании экзаменов.

Пусть основанием для зачисления в университет является победа в олимпиаде, либо успешная сдача вступительных экзаменов. Результат объединения (R3), который мы назовем «Абитуриенты, зачисленные в университет», включает все строки первой таблицы и недостающие строки из второй.

Таблица Абитуриенты, зачисленные в университет.

Пример 2. Пересечение. R3 = R1 Ç R2

Исходные данные те же, что и в случае объединения. Результат пересечения включает только те строки первой таблицы, которые есть во второй. В нашем случае результатом будет таблица, которую можно назвать «Абитуриенты, зачисленные в университет по двум показателям».

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

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

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

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

Основная задача при проектировании реляционных БД -формирование оптимальных отношений.

Пример 1. Рассмотрим БД «Объединение кооперативов». В отношении ПОСТАВЩИКИ (НАЗВАНИЕ ПОСТАВЩИКА, АДРЕС ПОСТАВЩИКА, ТОВАР, ЦЕНА), в связи с такой его схемой, могут возникают следующие проблемы:

1. Аномалия избыточность: адрес поставщика повторяется для каждого повторяемого товара.

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

3. Аномалия удаления: при необходимости удаления всех товаров, поставляемых данным поставщиком, непреднамеренно можно утратить его адрес.

4. Аномалия включения: в БД может быть записан адрес поставщика, который в настоящее время не поставляет товар, можно поместить неопределенные значения атрибутов ТОВАР и ЦЕНА. Но если он начнет поставлять некоторый товар, можно забыть удалить кортеж с неопределенными значениями. ТОВАР и НАЗВАНИЕ ТОВАРА образуют ключ данного отношения, а поиск кортежей с неопределенными значениями может быть затруднен или невозможен.

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

· Аномалии вставки (INSERT)

· Аномалии обновления (UPDATE)

· Аномалии удаления (DELETE)

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

· Сотрудник Иванов, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 1 и во втором проекте "Климат" задание 1.

· Сотрудник Петров, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 2.

· Сотрудник Сидоров, работающий во 2 отделе, выполняет в первом проекте "Космос" задание 3 и во втором проекте "Климат" задание 2.

Это состояние отражается в таблице СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (курсивом выделены ключевые поля).

Свойство (С) - согласованность транзакций определяется наличием понятия согласованности базы данных.

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

Определение 3 . База данных находится в согласованном (целостном) состоянии , если выполнены (удовлетворены) все ограничения целостности, определённые для базы данных.

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

- Отказ выполнить "незаконную" операцию.

Выполнение компенсирующих действий.

17.3. Классификация ограничений целостности.

Ограничения целостности можно классифицировать несколькими способами:

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

17.3.1. Классификация ограничений целостности по способам реализации

Каждая система обладает своими средствами поддержки ограничений целостности. Различают два способа реализации:

• Декларативная поддержка ограничений целостности.
• Процедурная поддержка ограничений целостности.

Определение 4 . Декларативная поддержка ограничений целостности заключается в определении ограничений средствами языка определения данных (DDL - Data Definition Language). Обычно средства декларативной поддержки целостности (если они имеются в СУБД) определяют ограничения на значения доменов и атрибутов, целостность сущностей (потенциальные ключи отношений) и ссылочную целостность (целостность внешних ключей). Декларативные ограничения целостности можно использовать при создании и модификации таблиц средствами языка DDL или в виде отдельных утверждений (ASSERTION).

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

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

17.3.2. Классификация ограничений целостности по времени проверки.

По времени проверки ограничения делятся на:

• Немедленно проверяемые ограничения.
• Ограничения с отложенной проверкой.

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

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

17.3.3. Классификация ограничений целостности по области действия.

По области действия ограничения делятся на:

• Ограничения домена
• Ограничения атрибута
• Ограничения кортежа
• Ограничения отношения
• Ограничения базы данных

17.3.3.1. Ограничения домена.

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

Проверка ограничения . Ограничения домена сами по себе не проверяются. Если на каком-либо домене основан атрибут, то ограничение соответствующего домена становится ограничением этого атрибута.

17.3.3.2. Ограничения атрибута.

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

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

17.3.3.3. Ограничения кортежа.

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

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

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

17.3.3.4. Ограничения отношения.

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

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

Ограничение отношения может быть как немедленно проверяемым с отложенной проверкой .

Ограничение отношения, являющееся ограничением потенциального ключа является немедленно проверяемым ограничением.

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

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

17.3.3.5. Ограничения базы данных.

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

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

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

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