Таблицы в базах данных: Общие сведения о таблицах — Служба поддержки Майкрософт

Общие сведения о таблицах — Служба поддержки Майкрософт

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

В этой статье

• 
  Overview

• 
  Свойства таблиц и полей

• 
  Типы данных

• 
  Отношения между таблицами

• 
  Keys

• 
  Преимущества использования отношений

Обзор

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

1. Запись. Содержит конкретные данные, например информацию об определенном работнике или продукте.

2. Поле. Содержит данные об одном аспекте элемента таблицы, например имя или адрес электронной почты.

3. Значение поля. Каждая запись содержит значение поля, например Contoso, Ltd. или [email protected].

К началу страницы

Свойства таблиц и полей

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

1. Свойства таблицы

2. Свойства поля

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

Свойство поля применяется к определенному полю в таблице и определяет его характеристики или определенный аспект поведения. Некоторые свойства поля можно задать в Режим таблицы. Вы также можете настраивать любые свойства в Конструкторе с помощью области </c0>Свойства поля.

Типы данных

У каждого поля есть тип данных. Тип данных поля определяет данные, которые могут в нем храниться (например, большие объемы текста или вложенные файлы).

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

• Тип данных поля задается на бланке таблицы, а не в области Свойства поля.

• Тип данных определяет, какие другие свойства есть у этого поля.

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

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

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

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

К началу страницы

Отношения между таблицами

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

• Таблица клиентов, содержащая сведения о клиентах компании и их адреса.

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

• Таблица заказов, служащая для отслеживания заказов клиентов.

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

К началу страницы

Ключи

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

• 
  Первичный ключ.    В таблице может быть только один первичный ключ. Он состоит из одного или нескольких полей, однозначно определяющих каждую запись в этой таблице. Часто в качестве первичного ключа используется уникальный идентификатор, порядковый номер или код. Например, в таблице «Клиенты» каждому клиенту может быть назначен уникальный код клиента. Поле кода клиента является первичным ключом этой таблицы. Если первичный ключ состоит из нескольких полей, он обычно включает уже существующие поля, формирующие в сочетании друг с другом уникальные значения. Например, в таблице с данными о людях в качестве первичного ключа можно использовать сочетание фамилии, имени и даты рождения. Дополнительные сведения см. в статье Добавление и изменение первичного ключа таблицы.

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

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

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

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

2. Внешний ключ (определяется по отсутствию значка ключа)

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

К началу страницы

Преимущества использования связей

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

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

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

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

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

К началу страницы

Классификация таблиц в реляционных базах данных по признакам целостности и избыточности данных / Хабр

Обоснование статьи и некоторые ключевые понятия;

1. Справочники и связки;

1.1. Виды таблиц;

1.2. Виды справочников;

1.3. Виды связок;

2. Обобщение классификации;

2.1. Классификация в табличном виде;

2.2. Классификация в схематичном виде;

3. Некоторые комментарии по применению классификации;

3.1. Применение классификации при нормализации таблиц;

Заключение.

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

Очень часто присутствовал на обучении дисциплине «Базы данных». Обучался когда-то сам… Как-то даже пришлось проводить целый курс для друзей и знакомых. Во время обучения мною было замечено, что трудности возникают уже на этапе понимания таблиц и того, как ими пользоваться. Многие просто не могли и не могут разработать простейшие базы данных. После более детального рассмотрения такого понятия как таблицы и маленькой классификации, трудности восприятия таблиц в реляционных базах данных почти всегда исчезают. Итак!

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

Для понимания дадим краткие определения целостности и избыточности данных:

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

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

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

1. Справочники и связки

1.1. Виды таблиц

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

Рисунок 1. Справочники и связки

Информацию в таблицах можно разделить на два вида. На информацию, которая описывает объекты (субъекты), связи и информацию, которая описывает действия, процессы, события, иное.

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

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

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

1.2. Виды справочников

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

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

Примером таких справочников могут служить список месяцев с названиями и номерами, список дней недели, список времён года, список океанов и так далее…

Таблица 1. Пример статичных справочников

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

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

Таблица 2. Пример статично-динамичных справочников

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

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

Код проекта	Проект	Нормативный срок выполнения	Дата добавления	Пользователь
PT102	Покраска окон	15	03.01.2014	1547
PT103	Установка дверей	10	04. 01.2014	9874
PT587	Проверка пожарных кранов	2	04.01.2014	1456
PT588	Замена люков	3	02.01.2014	0147
PT133	Очистка каналов	11	09.02.2015	1547

Таблица 3. Пример динамичных справочников

Рисунок 2. Виды справочников

1.3. Виды связок

Таблицы-связки можно разделить на два вида.

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

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

Таблица 4. Пример справочника-связки

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

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

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

Таблица 5. Пример связки

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

Рисунок 3. Виды связок

2. Обобщение классификации

2.1. Классификация в табличном виде

Вид таблицы	Описание	Примеры	Плюсы (+)	Минусы(-)
Статичный справочник	Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В статичном справочнике должна содержаться информация, которая либо вообще не изменяется, либо изменяется так редко, что этим можно принебречь. На статичный справочник ссылаются (внешний ключ), когда нужно получить названия, обозначения, нормы, количественные или качественные показатели. Иное.	Справочник (наименований и номеров) месяцев. Справочник складов и цехов предприятия. Справочник правил игры.	Иногда заменяет системные функции СУБД, позволяет более гибко работать с некоторыми данными. В случае, если меняется редко изменяемая информация, предостерегает от серьёзных последствий.	Использование таблицы с любой структурой может замедлять работу, в случае, если таблица заменяет системное хранилише. Приходится писать дополнительные функции и обработки для данной таблицы, которые не всегда правильно оптимизированны. В некоторых случаях невозможно оптимизировать.
Статично-динамичный справочник	Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах нельзя использовать внешний ключ этого справочника, однако можно использовать первичный ключ.	Справочник окладов по должностям. Справочник (размеров обуви, веса, роста, размера головы) физиологических параметров. Справочник (менеджеров, компаний) содержащий компании и менеджеров, которые эти компании обслуживают и учитывают.	Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник».	Справочник, выделенный из справочника-связки, никуда не девается и не имеет никакой реляционной связи, которая позволила бы ему превратиться в статичный или динамичный справочник. А значит, всегда избыточен.
Динамичный справочник	Таблица. Данные из неё берутся часто для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В динамичном справочнике должна содержаться информация, которая часто изменяется.	Справочник клиентов. Справочник поставщиков. Справочник контрагентов. Справочник менеджеров компании. Справочник работников. Справочник студентов.	Позволяет хранить динамичные данные, при этом давая возможность однозначно ссылаться на них.	Чаще всего накопительного типа и не делим, что создаёт определённую избыточность.
Справочник-связка	Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах.	Платёжные транзакции. Продажи. Межзаводские перемещения. График перевозок.	Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник».	Справочник-связка после нормализации превращается в связку и сводит избыточность данных к минимуму, не затрагивая целостность, однако не делим и при архивировании в текущей таблице не подлежит оптимизации.
Связка	Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах.  Таблица не может содержать кортежей, значения атрибутов в которых являются неделимыми и не уникальными.	Автоматический лог ошибок в программе. Лог запроса сервера. Результаты трассировок. Отчёты о выгрузке и загрузке компонентов. Автоматические отчёты системы безопасности.	Связка сводит избыточность данных к минимуму, не затрагивая целостность.	Накапливаясь, является неделимой таблицей. Сложно оптимизировать.

Таблица 6. Классификация

2.2. Классификация в схематичном виде

Рисунок 4. Схема классификации таблиц в реляционных базах данных по признакам целостности и избыточности данных

3. Некоторые комментарии по применению классификации

3.1. Применение классификации при нормализации таблиц

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

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

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

Заключение

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

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

Надеюсь, кому ни будь ещё поможет эта классификация при освоении дисциплины «Базы данных» и при проектировании баз данных в реляционных СУБД.

Ограничения первичного и внешнего ключа — SQL Server

• Статья
• 03.03.2023

Применимо к:
SQL Server 2016 (13.x) и более поздние версии База данных SQL Azure Управляемый экземпляр Azure SQL

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

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

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

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

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

• Таблица может содержать только одно ограничение первичного ключа.

• Первичный ключ не может превышать 16 столбцов, а общая длина ключа не должна превышать 900 байт.

• Индекс, сгенерированный ограничением первичного ключа, не может привести к тому, что количество индексов в таблице превысит 999 некластеризованных индексов и 1 кластеризованный индекс.

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

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

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

Ограничения внешнего ключа

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

Например, таблица Sales.SalesOrderHeader имеет ссылку внешнего ключа на таблицу Sales.SalesPerson , так как существует логическая связь между заказами на продажу и продавцами. Столбец SalesPersonID в таблице SalesOrderHeader соответствует столбцу первичного ключа таблицы SalesPerson . Столбец SalesPersonID в таблице SalesOrderHeader является внешним ключом для SalesPerson 9.0026 табл. При создании этой связи внешнего ключа значение для SalesPersonID не может быть вставлено в таблицу SalesOrderHeader , если оно еще не существует в таблице SalesPerson .

Таблица может ссылаться не более чем на 253 другие таблицы и столбцы как внешние ключи (исходящие ссылки). SQL Server 2016 (13.x) увеличивает ограничение количества других таблиц и столбцов, которые могут ссылаться на столбцы в одной таблице (входящие ссылки), с 253 до 10 000. (Требуется уровень совместимости не менее 130.) Повышение имеет следующие ограничения:

• Более 253 ссылок на внешние ключи поддерживаются только для операций DELETE DML. Операции UPDATE и MERGE не поддерживаются.

• Таблица со ссылкой внешнего ключа на себя по-прежнему ограничена 253 ссылками внешнего ключа.

• Более 253 ссылок на внешние ключи в настоящее время недоступны для индексов columnstore, таблиц, оптимизированных для памяти, базы данных Stretch или секционированных таблиц внешних ключей.

  Важно

  База данных Stretch устарела в SQL Server 2022 (16.x). Эта функция будет удалена в будущей версии Microsoft SQL Server. Избегайте использования этой функции в новых разработках и планируйте модифицировать приложения, которые в настоящее время используют эту функцию.

Индексы ограничений внешнего ключа

В отличие от ограничений первичного ключа создание ограничения внешнего ключа не создает автоматически соответствующий индекс. Однако ручное создание индекса для внешнего ключа часто полезно по следующим причинам:

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

• Изменения ограничений первичного ключа проверяются ограничениями внешнего ключа в связанных таблицах.

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

Хотя основной целью ограничения внешнего ключа является управление данными, которые могут храниться в таблице внешнего ключа, оно также контролирует изменения данных в таблице первичного ключа. Например, если строка для продавца удалена из таблицы Sales.SalesPerson , а идентификатор продавца используется для заказов на продажу в Таблица Sales.SalesOrderHeader , реляционная целостность между двумя таблицами нарушена; заказы на продажу удаленного продавца теряются в таблице SalesOrderHeader без ссылки на данные в таблице SalesPerson .

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

Каскадная ссылочная целостность

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

НЕТ ДЕЙСТВИЙ
Компонент Database Engine выдает ошибку, и действие удаления или обновления строки в родительской таблице откатывается.

CASCADE
Соответствующие строки обновляются или удаляются в ссылочной таблице, когда эта строка обновляется или удаляется в родительской таблице. CASCADE не может быть указан, если 9Столбец 0013 timestamp является частью либо внешнего ключа, либо ключа, на который указывает ссылка. ON DELETE CASCADE нельзя указать для таблицы с триггером INSTEAD OF DELETE. ON UPDATE CASCADE нельзя указать для таблиц с триггерами INSTEAD OF UPDATE.

SET NULL
Все значения, составляющие внешний ключ, устанавливаются в NULL, когда соответствующая строка в родительской таблице обновляется или удаляется. Чтобы это ограничение выполнялось, столбцы внешнего ключа должны иметь значение NULL. Нельзя указать для таблиц с триггерами INSTEAD OF UPDATE.

SET DEFAULT
Все значения, составляющие внешний ключ, устанавливаются в значения по умолчанию, если соответствующая строка в родительской таблице обновляется или удаляется. Чтобы это ограничение выполнялось, все столбцы внешнего ключа должны иметь определения по умолчанию. Если столбец допускает значение NULL и не задано явное значение по умолчанию, NULL становится неявным значением по умолчанию для столбца. Нельзя указать для таблиц с триггерами INSTEAD OF UPDATE.

CASCADE, SET NULL, SET DEFAULT и NO ACTION могут быть объединены в таблицах, которые имеют ссылочные отношения друг с другом. Если компонент Database Engine обнаруживает NO ACTION, он останавливается и откатывает связанные действия CASCADE, SET NULL и SET DEFAULT. Когда оператор DELETE вызывает комбинацию действий CASCADE, SET NULL, SET DEFAULT и NO ACTION, все действия CASCADE, SET NULL и SET DEFAULT применяются до того, как компонент Database Engine проверит наличие NO ACTION.

Триггеры и каскадные ссылочные действия

Каскадные ссылочные действия запускают триггеры AFTER UPDATE или AFTER DELETE следующим образом:

• Все каскадные ссылочные действия, непосредственно вызванные исходным DELETE или UPDATE, выполняются первыми.

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

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

• Триггер AFTER для таблицы, которая является прямой целью действия UPDATE или DELETE, срабатывает независимо от того, затронуты ли какие-либо строки. В этом случае нет других таблиц, затронутых каскадированием.

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

• Выполнение операций CREATE, ALTER, DELETE или других операций языка определения данных (DDL) внутри триггеров может привести к срабатыванию триггеров DDL. Это может впоследствии выполнять операции DELETE или UPDATE, которые запускают дополнительные каскадные цепочки и триггеры.

• Если в какой-либо конкретной каскадной цепочке ссылочных действий возникает ошибка, возникает ошибка, триггеры AFTER в этой цепочке не срабатывают, а операция DELETE или UPDATE, создавшая цепочку, откатывается.

• Таблица с триггером INSTEAD OF не может также иметь предложение REFERENCES, указывающее каскадное действие. Однако триггер AFTER для таблицы, на которую нацелено каскадное действие, может выполнить оператор INSERT, UPDATE или DELETE для другой таблицы или представления, который запускает триггер INSTEAD OF, определенный для этого объекта.

Следующие шаги

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

Задача	Артикул
Описывает, как создать первичный ключ.	Создать первичные ключи
Описывает, как удалить первичный ключ.	Удалить первичные ключи
Описывает, как изменить первичный ключ.	Изменить первичные ключи
Описывает, как создавать отношения внешнего ключа	Создание связей по внешнему ключу
Описывает, как изменить отношения внешнего ключа.	Изменить отношения внешнего ключа
Описывает, как удалить отношения внешнего ключа.	Удалить отношения внешнего ключа
Описывает, как просматривать свойства внешнего ключа.	Просмотр свойств внешнего ключа
Описывает, как отключить ограничения внешнего ключа для репликации.	Отключить ограничения внешнего ключа для репликации
Описывает, как отключить ограничения внешнего ключа во время инструкции INSERT или UPDATE.	Отключение ограничений внешнего ключа с помощью инструкций INSERT и UPDATE

Что такое таблица базы данных?

Автор: Крис Венцель   | Обновлено: 4 марта 2023 г.  

Работает с:

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

Общая структура таблицы базы данных

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

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

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

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

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

Таким образом, столбец DateOfBirth, определенный как дата, может упоминаться в предложении order by как

.

 ЗАКАЗАТЬ ПО DateOfBirth 

И если вы попытаетесь добавить в столбец значение «Hello Kitty» в рамках его проверки, он распознает, что это не дата, и отклонит его.

Имена столбцов не могут дублироваться в таблице. Таким образом, иметь два столбца «имя» — это нет, нет. Хотя у вас может быть два столбца «имя», например, имя1 и имя2, позже вы узнаете, что это нахмурено, так как нарушает нормальную форму (я объясню это в другом посте).

Строки таблицы базы данных

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

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

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

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