Реляционные базы данных. Первичные ключи

• Перевод

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

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

Первичные ключи в повседневной жизни

Несколько примеров

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

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

Что характеризует первичный ключ? Характеристики первичного ключа.

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

Первичный ключ уникален.

Первичный ключ всегда имеет уникальное значение. Представьте, что его значение не уникально. Тогда его бы нельзя было использовать для того, чтобы идентифицировать данные в таблице. Это значит, что какое-либо значение первичного ключа может встретиться в столбце, который выбран в качестве первичного ключа, только один раз. РСУБД устроены так, что не позволят вам вставить дубликаты в поле первичного ключа, получите ошибку.
Еще один пример. Представьте, что у вас есть таблица с полями first_name и last_name и есть две записи:

| first_name | last_name |
| vasya |pupkin |
| vasya |pupkin |

Т.е. есть два Васи. Вы хотите выбрать из таблицы какого-то конкретного Васю. Как это сделать? Записи ничем друг от друга не отличаются. Вот здесь и помогает первичный ключ. Добавляем столбец id (классический вариант синтетического первичного ключа) и…

Id | first_name | last_name |
1 | vasya |pupkin |
2 | vasya |pupkin |

Теперь каждый Вася уникален.

Типы первичных ключей.

Обычно первичный ключ – числовое значение. Но он также может быть и любым другим типом данных. Не является обычной практикой использование строки в качестве первичного ключа (строка – фрагмент текста), но теоретически и практически это возможно.
Составные первичные ключи.
Часто первичный ключ состоит из одного поля, но он может быть и комбинацией нескольких столбцов, например, двух (трех, четырех…). Но вы помните, что первичный ключ всегда уникален, а значит нужно, чтобы комбинация n-го количества полей, в данном случае 2-х, была уникальна. Подробнее об этом расскажу позднее.

Автонумерация.

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

5. СВЯЗЫВАНИЕ ТАБЛИЦ С ПОМОЩЬЮ ВНЕШНИХ КЛЮЧЕЙ

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

Один-ко-многим.

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

Какую информацию мы будем хранить? Решаем первый вопрос.

Проектируем таблицу клиентов.

Заказы действительно принадлежат клиентам, но заказ – это это не минимальный блок информации , который относится к клиентам (т.е. этот блок можно разбить на более мелкие: дата заказа, адрес доставки заказа и пр., к примеру).
Поля ниже – это минимальные блоки информации, которые относятся к клиентам:

• customer_id (primary key) – идентификатор клиента
• first_name - имя
• last_name - отчество
• address - адрес
• zip_code – почтовый индекс
• country - страна
• birth_date – дата рождения
• username – регистрационное имя пользователя (логин)
• password – пароль

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

Создание таблицы в SQLyog. Обратите внимание, что выбран флажок первичного ключа (PK) для поля customer_id. Поле customer_id является первичным ключом. Также выбран флажок Auto Incr, что означает, что база данных будет автоматически подставлять уникальное числовое значение, которое, начиная с нуля, будет каждый раз увеличиваться на одну единицу.

Проектируем таблицу заказов.
Какие минимальные блоки информации, необходимые нам, относятся к заказу?

• order_id (primary key) – идентификатор заказа
• order_date – дата и время заказа
• customer – клиент, который сделал заказ

Ниже – пример таблицы в SQLyog.

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

Создание связи по внешнему ключу.

Вы можете задаться вопросом: “Каким образом я могу убедиться или как я могу увидеть, что поле customer в таблице заказов ссылается на поле customer_id в таблице клиентов”. Ответ прост – вы не можете сделать этого потому, что я еще не показал вам как создать связь.
Ниже – окно SQLyog с окном, которое я использовал для создания связи между таблицами.

Создание связи по внешнему ключу между таблицами заказов и клиентов.

В окне выше вы можете видеть, как поле customer таблицы заказов слева связывается с первичным ключом (customer_id) таблицы клиентов справа.

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

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

На изображении вы видите, что клиент mary поместила три заказа, клиент pablo поместил один, а клиент john – ни одного.
Вы можете спросить: “А что же именно заказали все эти люди?” Это хороший вопрос. Вы возможно ожидали увидеть заказанные товары в таблице заказов. Но это плохой пример проектирования. Как бы вы поместили множественные продукты в единственную запись? Товары – это отдельные сущности, которые должны храниться в отдельной таблице. И связь между таблицами заказов и товаров будет являться связью один-ко-многим. Я расскажу об этом далее.

6. СОЗДАНИЕ ДИАГРАММЫ СУЩНОСТЬ-СВЯЗЬ

Сущности.

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

Давайте возьмем интернет-магазин для примера. Интернет-магазин продает товары . Товар мог бы стать очевидной сущностью в системе интернет-магазина. Товары заказываются клиентами . Вот мы с вами и увидели еще две очевидных сущности: заказы и клиенты .

Заказ оплачивается клиентом… это интересно. Мы собираемся создавать отдельную таблицу для платежей в базе данных нашего интернет-магазина? Возможно. Но разве платежи – это минимальный блок информации, который относится к заказам? Это тоже возможно.

Если вы не уверены, то просто подумайте о том, какую информацию о платежах вы хотите хранить. Возможно, вы захотите хранить метод платежа или дату платежа . Но это все еще минимальные блоки информации, которые могли бы относиться к заказу . Можно изменить формулировки. Метод платежа - метод платежа заказа. Дата платежа – дата платежа заказа. Таким образом, я не вижу необходимости выносить платежи в отдельную таблицу, хотя концептуально вы бы могли выделить платежи как сущность, т.к. вы могли бы рассматривать платежи как контейнер информации (метод платежа, дата платежа).

Давайте не будет слишком академичными.

Как вы видите, есть разница между сущностью и непосредственно таблицей в базе данных, т.е. это не одно и то же. Специалисты отрасли информационных технологий могут быть ОЧЕНЬ академичными и педантичными в этом вопросе. Я не такой специалист. Эта разница зависит от вашей точки зрения на ваши данные, вашу информацию. Если вы смотрите на моделирование данных с точки зрения программного обеспечения, то вы можете прийти к множеству сущностей, которые нельзя будет перенести напрямую в базу данных. В данном руководстве мы смотрим на данные строго с точки зрения баз данных и в нашем маленьком мире сущность – это таблица.

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

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

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

Связи.

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

Определены три основных класса сущностей:

1) Стержневые – независимая сущность. Названия помещены в прямоугольник.

2) Ассоциативные – связь вида многие ко многим между двумя или более сущностями. Ассоциации рассматриваются как полноправная сущность. Могут участвовать в других ассоциациях и обладать набором атрибутов.

a. Обозначения (обозначающая сущность) – связи вида многие к одной или одна к одной между двумя сущностями. Отличается от характеристики тем, что не зависит от обозначающей сущности.

3) Характеристические (характеристика) – связь вида многие к одной или одна к одной между двумя сущностями. Является частным случаем ассоциации. Единственная цель характеристики – описание или уточнение некоторой другой сущности. Существование характеристики полностью зависит о характеризуемой сущности.

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

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

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

Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

Для каждого внешнего ключа необходимо решить три вопроса:

1) Может ли дополнительный внешний ключ принимать неопределенные значения (null-значения), короче говоря, может ли существовать некоторый экземпляр сущности, для которого известна целевая сущность, указанная внешним ключом.

2) Что должно происходить при попытке удаления целевой сущности, на которую ссылается внешний ключ.

Существуют три возможности решения данного вопроса:

· Каскадирование

· Ограничение

· Установление в определенное значение

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

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

Типы данных и домены.

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

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

1) Каждый элемент таблицы – один элемент данных

2) Все столбцы в таблице однородны – все элементы в столбце имеют одинаковый тип и длину данных

3) Каждый столбец имеет уникальное имя

4) Одинаковые строки в таблице отсутствуют

5) Порядок следования строки столбцов может быть произвольным

Типы данных

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

Как правило, типы данных делятся на три группы:

1) Простые типы данных

2) Структурированные типы данных

3) ссылочные типы данных

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

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

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

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

Домен porno.ru

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

Домен – семантическое понятие. Его можно рассматривать как подмножество значений некоторого типа данных.

Свойства домена:

1) домен имеет уникальное имя в пределах базы данных

2) домен определен на некотором простом типе данных или на другом домене

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

4) домен несет некоторую смысловую нагрузку

Например, некоторый домен D, имеющий смысл «возраст сотрудника» можно описать как некоторое подмножество множества натуральных чисел

D={nϵN: n ≥ 18 and n ≤ 60}

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

5. Отношения и их свойства, атрибуты и кортежи.
Понятие отношения является фундаментальным понятием реляционной модели данных. Атрибут отношения: <Имя_атрибута: Имя_домена>. Имена атрибутов должны быть уникальными в пределах отношения. Часто имена атрибутов совпадают с именами соответствующих доменов. Некоторое отношение R, определенное на множестве доменов D 1 ,D 2 ,…D n содержит две части: заголовок и тело. Заголовок отношения содержит фиксированное количество атрибутов отношения.

(,,…)

(,,… ).

R (,,…).

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

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

4) Все значения атрибутов атомарны.

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

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

В реляционной модели данных фиксируется два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД.

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

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

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

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

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

Существуют основные правила, которые приняты для ключей в Access:

Для удобства ключевое поле обычно указывается в структуре таблицы первым;

Если для таблицы определен первичный ключ, программа Access автоматически блокирует ввод в это поле повторяющихся значений или значения Null (пусто);

Access автоматически сортирует записи таблицы по первичному ключу;

Поле первичного ключа является индексом, с помощью которого ускоряется сортировка и поиск записей.

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

В режиме конструктора выделите поле, которое будет играть роль первичного ключа;

Кликните по кнопке Ключевое поле панели инструментов Конструктора таблиц или выберите команду главного меню Правка – Ключевое поле (слева возле имени выделенного поля появится символ ключа);

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

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

17. Типы связей и их реализация. Ссылочная целостность и ее обеспечение.

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

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

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

Виды связей между таблицами

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

Существует три вида связей между таблицами. Вид создаваемой связи зависит от того, как заданы связанные столбцы.

Связи "один ко многим"

Связь "один ко многим" - наиболее распространенный вид связи. При такой связи каждой строке таблицы А может соответствовать множество строк таблицы Б, однако каждой строке таблицы Б может соответствовать только одна строка таблицы А. Например, между таблицами "Издатели" и "Книги" установлена связь "один ко многим": каждый из издателей может опубликовать множество книг, однако каждая книга публикуется лишь одним издателем.

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

В Microsoft Access сторона связи "один ко многим", которой соответствует первичный ключ, обозначается символом ключа. Сторона связи, которой соответствует внешний ключ, обозначается символом бесконечности.

Связи "многие ко многим"

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

Связи "один к одному"

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

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

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

Чтобы изолировать часть таблицы по соображениям безопасности.

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

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

В Microsoft Access сторона связи "один к одному", которой соответствует первичный ключ, обозначается символом ключа. Сторона связи, которой соответствует внешний ключ, также обозначается символом ключа.

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

При установлении связи между таблицами связанные поля не обязательно должны иметь одинаковые названия. При этом у них должен быть один и тот же тип данных, если только поле, являющееся первичным ключом, не относится к типу "Счетчик". Поле типа "Счетчик" можно связать с полем типа "Числовой" только в том случае, если для свойства FieldSize (размер поля) каждого из них задано одно и то же значение. Например, можно связать столбцы типов "Счетчик" и "Числовой", если для свойства FieldSize каждого из них установлено значение "Длинное целое". Даже если оба связываемых столбца относятся к типу "Числовой", значение свойства FieldSize для обоих полей должно быть одинаковым.

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

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

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

Примечание – Вы могли бы использовать эти понятия при создании таблиц базы данных.

Создание первичного ключа

Вот синтаксис для определения атрибута ID в качестве первичного ключа в таблице Customers.

CREATE TABLE CUSTOMERS(ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25) , SALARY DECIMAL (18, 2), PRIMARY KEY (ID));

Для того, чтобы создать ограничение первичного ключа на столбце «ID», когда таблица CUSTOMERS уже существует, используйте следующий синтаксис SQL:

ALTER TABLE CUSTOMERS ADD PRIMARY KEY (ID);

Примечание

Если вы используете оператор ALTER TABLE, чтобы добавить первичный ключ, столбец первичного ключа (ей) должен был уже объявлен как не содержащий NULL значения (если таблица была создана первым).

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

CREATE TABLE CUSTOMERS(ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25) , SALARY DECIMAL (18, 2), PRIMARY KEY (ID, NAME));

Чтобы создать ограничение первичного ключа на колонки «ID» и «NAME», когда таблица CUSTOMERS уже существует, используйте следующий синтаксис SQL.

ALTER TABLE CUSTOMERS ADD CONSTRAINT PK_CUSTID PRIMARY KEY (ID, NAME);

Удаление первичного ключа

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

ALTER TABLE CUSTOMERS DROP PRIMARY KEY;

• PRIMARY KEY - первичный ключ таблицы.
• UNIQUE - уникальный ключ таблицы.
• FOREIGN KEY - внешний ключ , обеспечивает ссылку на другую таблицу и гарантирует ссылочную целостность между родительской и дочерней таблицами .

Примечание о терминологии

Если вы похожи на автора данного курса в том, что любите искать ответы на интересующий вас вопрос комплексно, в разных трудах разных авторов, то вы не могли не заметить некоторую путаницу в определениях главная (master) -> подчиненная (detail) таблицы. Напомним, что главную таблицу часто называют родительской, а подчиненную - дочерней.

Связано это, вероятно, с тем, как интерпретируются эти определения в локальных и SQL -серверных СУБД .

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

Рис. 18.1.

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

Но в SQL -серверах баз данных имеется другое определение связей: когда одно поле в таблице ссылается на поле другой таблицы, оно называется внешним ключом . А поле , на которое оно ссылается, называется родительским или первичным ключом . Таблицу, которая имеет внешний ключ (ссылку на запись другой таблицы) нередко называют дочерней, а таблицу с родительским ключом - родительской. Еще в определении связей говорят, что родитель может иметь только одну уникальную запись , на которую могут ссылаться несколько записей дочерней таблицы .

Так что в приведенном выше примере таблица продаж имеет два внешних ключа: идентификатор товара, и идентификатор покупателя. А обе таблицы в правой части рисунка имеют родительский ключ " Идентификатор ". Поскольку один покупатель или товар могут неоднократно встречаться в таблице продаж, то получается, что обе таблицы в правой части рисунка - родители, а таблица слева - дочерняя. Поскольку сейчас мы изучаем InterBase - SQL сервер БД , этими определениями мы и будем руководствоваться в последующих лекциях. Чтобы далее не ломать голову над этой путаницей, сразу договоримся: дочерняя таблица имеет внешний ключ (FOREIGN KEY ) на другую таблицу.

PRIMARY KEY

PRIMARY KEY - первичный ключ , является одним из основных видов ограничений в базе данных. Первичный ключ предназначен для однозначной идентификации записи в таблице, и должен быть уникальным. Первичные ключи PRIMARY KEY находятся в таблицах, которые принято называть родительскими (Parent ). Не стоит путать первичный ключ с первичными индексами локальных баз данных, первичный ключ является не индексом, а именно ограничением. При создании первичного ключа InterBase автоматически создает для него уникальный индекс . Однако если мы создадим уникальный индекс , это не приведет к созданию ограничения первичного ключа . Таблица может иметь только один первичный ключ PRIMARY KEY .

Предположим, имеется таблица со списком сотрудников. Поле "Фамилия" может содержать одинаковые значения (однофамильцы), поэтому его нельзя использовать в качестве первичного ключа. Редко, но встречаются однофамильцы, которые вдобавок имеют и одинаковые имена. Еще реже, но встречаются полные тезки, поэтому даже все три поля "Фамилия" + "Имя" + "Отчество" не могут гарантировать уникальности записи, и не могут быть первичным ключом. В данном случае выход , как и прежде, в том, чтобы добавить поле - идентификатор , которое содержит порядковый номер данного лица. Такие поля обычно делают автоинкрементными (об организации автоинкрементных полей поговорим на следующих лекциях). Итак,

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

Если в первичный ключ входит единственный столбец (как чаще всего и бывает), спецификатор PRIMARY KEY ставится при определении столбца :

CREATE TABLE Prim_1(Stolbec1 INT NOT NULL PRIMARY KEY, Stolbec2 VARCHAR(50))

Если первичный ключ строится по нескольким столбцам, то спецификатор ставится после определения всех полей:

CREATE TABLE Prim_2(Stolbec1 INT NOT NULL, Stolbec2 VARCHAR(50) NOT NULL, PRIMARY KEY (Stolbec1, Stolbec2))

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

UNIQUE

UNIQUE - уникальный ключ . Спецификатор UNIQUE указывает, что все значения данного поля должны быть уникальными, в связи с этим такие поля также не могут содержать значения NULL . Можно сказать, что уникальный ключ UNIQUE является альтернативным вариантом первичного ключа, однако имеются различия. Главное различие в том, что первичный ключ должен быть только один, тогда как уникальных ключей может быть несколько. Кроме того, ограничение UNIQUE не может быть построено по тому же набору столбцов, который был использован для ограничения PRIMARY KEY или другого UNIQUE . Уникальные ключи, как и первичные, находятся в таблицах, которые являются родительскими по отношению к другим таблицам.

Столбец, объявленный с ограничением UNIQUE , как и первичный ключ , может применяться для обеспечения ссылочной целостности между родительской и дочерней таблицами . При этом внешний ключ дочерней таблицы будет ссылаться на это поле (поля). Как и в случае первичного ключа, при создании уникального ключа, для него автоматически будет создан уникальный индекс . Но не наоборот. Пример создания таблицы с одним первичным и двумя уникальными ключами:

CREATE TABLE Prim_3(Stolbec1 INT NOT NULL PRIMARY KEY, Stolbec2 VARCHAR(50) NOT NULL UNIQUE, Stolbec3 FLOAT NOT NULL UNIQUE)

FOREIGN KEY

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