Ограничения таблиц
- 15 мин
Ограничения таблицы базы данных позволяют не только управлять тем, что и как хранить данные, но и определять связи между таблицами.
Используя ограничения и связи таблиц, вы можете удовлетворить конкретные правила карточной игры, связанные с качеством данных, без повторяющихся строк. Важно исключить повторяющиеся строки, так как они не только вызывают проблемы с производительностью, они также удаляют возможность иметь полные, согласованные и точные данные (также называемые целостностью данных).
Научившись использовать ограничения и связи таблиц, вы можете обеспечить целостность данных в приложении.
Назначьте уникальные значения с помощью первичных ключей
Классификация помогает при поиске определенного элемента путем ограничения выбора и представления меньшего набора результатов. Реляционная база данных содержит первичные ключи, которые являются столбцами или комбинацией столбцов, содержащих значения, однозначно определяющие каждую строку в таблице. С помощью карточной игры можно ограничить результат поиска по типу или цвету карты, но при назначении также первичного ключа база данных может мгновенно извлечь все сведения об этой карте, используя одно уникальное значение.
При определении и создании таблиц можно объединить столбец первичного ключа с столбцом удостоверения. Объединение двух столбцов не только гарантирует уникальное значение, но и обеспечивает автоматическое применение и создание этих уникальных значений в SQL Azure. Обратите внимание, что таблица может содержать только один первичный ключ, и этот столбец или набор столбцов никогда не может содержать пустые или пустые значения NULL. В нашем сценарии таблица карточек будет иметь первичный ключ в столбце card_id, предоставляя прямой указатель на определенную карточку, которую ищет пользователь.
Определение связей таблиц с внешними ключами
Требование для приложения на основе карточек в Интернете заключается в поддержке карточек с переводом на несколько языков. Вы можете просто добавить столбцы для каждого языка в основной таблице карточек, но в конечном итоге это станет трудноуправляемым. Кроме того, необходимо добавить новый столбец в таблицу каждый раз, когда требуется новый перевод. Лучшим решением будет использовать отдельную таблицу для переводов, которую можно связать обратно с таблицей карточек в столбце card_id. Это то место, где внешние ключи играют важную роль.
Внешний ключ — это столбец или сочетание столбцов, которые можно использовать для принудительного применения ссылки или связи между двумя таблицами. Внешние ключи помогают контролировать данные, которые могут храниться с помощью этой связи, обеспечивая хранение только данных из столбца первичного ключа в связанной таблице в столбце внешнего ключа. В сценарии карточной игры вы бы использовали связь внешнего ключа в таблице переводов с первичным ключом таблицы основных карт. Эта связь будет допускать ввод значений только из столбца первичного ключа таблицы карточек в столбец внешнего ключа таблицы переводов, чтобы всегда поддерживать связь между ними, предотвращая появление потерянных строк или неточных данных. Например, в таблице переводов не было строки для card_id 52, если в таблице карточек не существовало card_id 52.
схема
Применение целостности данных с использованием ограничений
Значения NULL, значения по умолчанию и ограничения проверки
Управление данными, хранящимися в таблицах карточек игры, может помочь сохранить нежелательные значения и обеспечить целостность данных (полные, согласованные и точные наборы данных). На самом простом уровне есть столбцы, в которых всегда нужно вводить значение (например, card_name), предотвращая пропуск ключевых частей данных. При создании таблиц можно задать столбцы для разрешения или запрета пустых значений или значений NULL. База данных SQL Azure будет видеть, когда кто-то не предоставляет все необходимые элементы данных путем передачи значений NULL. При возникновении этой ситуации база данных будет препятствовать вводу записи.
Sql Azure также может помочь нам управлять допустимыми значениями в столбце, назначив одно или несколько значений по умолчанию. База данных может даже ограничить данные, разрешенные набором значений. Значения по умолчанию со столбцом позволяют базе данных знать, какое значение следует использовать, если значение не определено. Один из примеров использования приложения для ссылок на карточки — это работа со столбцом состояния. Здесь можно назначить значение по умолчанию для ввода данных в карточку, что облегчает быстрый ввод данных и использование элементов пользовательского интерфейса по умолчанию.
Ограничения проверки могут ограничить допустимые значения столбца. В сценарии применения карточной ссылки цвет карты и тип карточки должны иметь определенный набор значений; это идеальное условие для ограничения проверки, чтобы значения, не соответствующие этим критериям, были отклонены.
Могут возникнуть ситуации, когда определение набора значений по умолчанию нереалистично. Представьте себе столбец, который разрешает только числа от одного до 10000. Создание списка значений для 10000 отдельных чисел было бы ненужным и трудоемким. Вы можете создать ограничение проверки с любым логическим (булевым) выражением, возвращающим TRUE или FALSE на основе логических операторов, например, диапазон значений, используя операторы больше и меньше. Вы можете иметь несколько ограничений проверки для одного столбца, и вы можете применить одно ограничение проверки к нескольким столбцам.
Уникальные ограничения
Так же, как первичный ключ обеспечивает уникальность, существуют ситуации, когда столбец должен иметь уникальные значения, но не первичный ключ (помните, что для каждой таблицы существует только один первичный ключ). Создав столбец с уникальным ограничением, SQL Azure может разрешить ввод уникальных значений, разрешить значения NULL, если это необходимо в отличие от первичного ключа, и использовать в качестве внешнего ключа при необходимости. Мы могли бы использовать уникальное ограничение в приложении для карт в таблице set_lists. Здесь можно задать уникальное ограничение для столбцов card_id и set_id, чтобы убедиться, что карточка не добавляется в набор более одного раза.