[МУЗЫКА] [МУЗЫКА] [МУЗЫКА] Рассмотрим создание правил целостности. Чего мы хотим добиться, используя их? Мы хотим, чтобы некорректные данные в принципе не могли попасть в нашу базу данных. Также мы хотим обеспечить возможность связывания нескольких таблиц. Какие могут быть правила целостности? Это может быть NULL или NOT NULL, это может быть правило UNIQUE или PRIMARY KEY. Также это команды CHECK и FOREIGN KEY. Поговорим об этих правилах подробнее. Когда они появляются? Эти правила целостности могут быть описаны вместе с командой создания или модификации таблицы. Если мы используем создание правила целостности вместе с созданием таблицы, то мы указываем эти описания после описания столбца или отдельно после описания всех столбцов в таблице, если наше правило целостности затрагивает несколько столбцов. Как добавить или удалить правило целостности в нашу таблицу? Это можно сделать при помощи команды ALTER TABLE, которое позволяет нам менять таблицу в целом и отдельные ее столбцы и их описание. Рассмотрим первое правило целостности NULL или NOT NULL. Оно говорит нам о том, могут или не могут конкретные столбцы таблицы принимать незаданные или неопределенные значения. Рассмотрим на примере. Если мы записываем данные в какую-то телефонную книжку, наверное, нам нужно обязательно знать номер телефона человека и как его зовут. Также в нашу телефонную книжку мы можем записать некоторую дополнительную информацию, скажем, дату рождения или адрес. Но эти данные могут быть не у всех. Вот этот пример показывает, что некоторые столбцы нашей таблицы могут принимать незаданные значения, как, например, адрес и дата рождения, а некоторые являются обязательными, NOT NULL. К таким столбцам в нашем примере относятся номер телефона и имя человека. На нашем примере созданием таблицы PERSON мы запрещаем столбцу «идентификатор человека» принимать незаданные значения. Следующее правило целостности, очень важное в базах данных, называется первичный ключ, или PRIMARY KEY. Это ограничение целостности применяется для однозначной идентификации строк таблицы. Напомним, что каждая сущность должна быть у нас каким-то образом идентифицирована. Для каждой таблицы может быть определен только один первичный ключ. Но он, впрочем, может состоять не из одного поля, а из нескольких полей, и те столбцы, на которых определяется ограничение целостности «первичный ключ», не могут принимать незаданные значения. Давайте рассмотрим пример. Мы создаем таблицу Department, в которой будем хранить информацию об отделах, и идентификатор отдела или его номер мы делаем первичным ключом. Это означает, что значения его будут уникальны и не могут принимать незаданных значений. Кроме этого, в таблице будет еще одно поле — это название отдела. Когда мы обсуждали с вами ключи, то мы говорили, что некоторые сущности могут не иметь таких им свойственных атрибутов, которые образуют естественный ключ. Тогда нам может быть полезен ключ суррогатный, выдуманный системой. Для генерации таких искусственных ключей и существует у нас поле с автонумерацией. Пример его вы видите на экране. Если вы используете такое поле, то тип этого поля должен быть целочисленным, и, задавая такое поле, вы просите систему сгенерировать для каждой новой строки таблицы его уникальный идентификатор. На следующем примере мы видим, как создать первичный ключ из нескольких полей. Рассмотрим таблицу Person, в которой есть идентификатор человека, идентификатор отдела и имя человека. Если мы предположим, что у нас идентификатор человека уникален только в рамках отдела, то нам нужно сделать первичный ключ из комбинации двух полей — это идентификатор человека и идентификатор отдела. Для того чтобы сделать составной первичный ключ из двух полей, мы после описания полей таблицы пишем первичный ключ и далее в круглых скобках указываем те поля, которые первичный ключ будут образовывать. Мы научились с вами делать первичный ключ, задавая уникальность какого-то поля или комбинации полей. И мы сказали, что первичный ключ может быть для таблицы только один. Но нам может потребоваться задать уникальность не одного поля. Например, если мы будем рассматривать студента, то у него уникальным должен быть и номер паспорта, и номер зачетки. В качестве первичного ключа логично выбрать какое-то одно поле. Как же сделать другое поле уникальным? Это можно сделать при помощи ограничения целостности UNIQUE. Рассмотрим на примере, как это сделать. Для того чтобы сделать один или несколько атрибутов уникальными, мы можем использовать ограничение целостности UNIQUE. Если мы хотим сделать уникальным один из атрибутов, мы можем просто указать это правило целостности сразу после описания атрибута. А если нам нужно сделать комбинацию атрибутов уникальной, то мы после определения атрибутов пишем слово UNIQUE и в круглых скобках перечисляем атрибуты, значения которых вместе должны быть уникальны в рамках таблицы. Следует заметить отличие от PRIMARY KEY, во-первых, тем, что значения атрибутов, которые мы назвали уникальными, могут принимать в случае одной строки незаданное значение, и то, что атрибутов уникальных в нашей таблице может быть несколько. Следующее правило целостности называется FOREIGN KEY. Мы можем установить внешний ключ в таблице. Это правило целостности позволяет нам связать две таблицы. Давайте рассмотрим на примере таблицы отделов, в которых у нас хранится информация о номере отдела и названии отдела. И у нас есть таблица персонала, который мы хотим брать на работу, оформляя сразу в какой-то отдел. Каким образом у нас реализуются в таблицах связи вида один ко многим? Мы должны добавить в таблицу сотрудников, номер отдела, в который мы этого сотрудника зачисляем. Эти столбцы должны быть одинакового типа, но пока ничто не мешает нам, имея в распоряжении лишь отдел номер один и отдел номер два, оформить сотрудника в отдел номер три, что будет неправильно. Для того чтобы мы могли записывать информацию во вторую таблицу со ссылками лишь на существующие записи родительской таблицы, мы задаем ограничение FOREIGN KEY, связывая два столбца разных таблиц. Для того чтобы связать две таблицы при помощи внешнего ключа, мы должны иметь в этих таблицах, во-первых, два поля, значения по которым берутся из одной области определения. Эти два столбца должны быть строго одного типа, то есть нельзя сделать, например, поля в одном int, bigint, они должны быть строго одного типа. И поле главной таблицы, на которое мы будем ссылаться, должно быть объявлено первичным ключом или уникальным. Для того чтобы организовать такое правило целостности «внешний ключ», мы, определяя таблицу сотрудников после определения поля, которое ссылается на поле другой таблицы, пишем команду FOREIGN KEY и указываем таблицу, на которую мы ссылаемся и в круглых скобках указываем поле, которое связывается с данным текущим полем. Что нам гарантирует такая связка? Она гарантирует нам, что подчиненная таблица будет использовать в этом поле только те значения, которые присутствуют в родительской таблице. На экране вы видите пример, в котором таблица разработчиков или сотрудников связывается с таблицей отделов. Связку «внешний ключ» можно делать и внутри одной таблицы. Давайте представим пример, что у нас есть таблица разработчиков, и мы хотим сделать некоторых разработчиков руководителями других. Что мы можем сделать для этого? Для этого мы добавляем в нашу таблицу еще одно поле, которое будет по типу таким же, как ID разработчика. Назовем его Boss, и указываем, что это поле будет ссылаться на поле «идентификатор сотрудника», DeveloperId. Таким образом, мы установим ссылочную целостность на поля одной и той же таблицы, делая рекурсивную связь. Теперь интересный вопрос: а что делать при изменении родительской записи? Просто связка «внешний ключ» не дает нам добавить в подчиненную таблицу записи со значениями, которые не присутствуют в основной таблице. Но что делать, если мы добавили записи, все произошло корректно, но после этого записи в родительской таблице как-то меняются? Эти записи могут быть изменены или удалены. Вот для этого мы можем указать каскадное правило целостности, что делать с подчиненными записями при изменении родительской. На это есть несколько стратегий. Стратегия, которая применяется по умолчанию, запрещает вам удалять или изменять родительские записи, если на них есть записи в подчиненной таблице. Следующая стратегия — это каскадное обновление. Если у вас изменяется или удаляется запись в родительской таблице, то вместе с ней изменяются и удаляются подчиненные записи. Последняя возможность — это установка незаданных значений для подчиненной записи. Следующее правило целостности, которое мы рассмотрим, называется CHECK. Это дает нам возможность проверять значение конкретного атрибута до его добавления в базу данных. На примере, приведенном на экране, мы видим несколько правил целостности. Одно из правил целостности проверяет, что зарплата человека, которого мы принимаем на работу, будет не меньше 5 000 и не больше 50 000. Второе правило целостности проверяет принадлежность значения множеству. Должность человека, которого мы принимаем на работу, должна быть либо программист, либо аналитик, либо менеджер. Таким образом, мы рассмотрели с вами пять правил целостности, которые позволяют нам ограничивать значения столбцов таблицы.
