Войти
Ключ суррогата (или синтетический ключ, pseudokey, идентификатор сущности, неподтвержденный ключ или технический ключ) в базе данных является уникальным идентификатором, либо для лица в моделируемом мире или объект в базе данных. Суррогатный ключ не является производным от данных приложения, в отличие от естественного (или бизнес- ключа).
Есть как минимум два определения суррогата:
Определение Surrogate (1) относится к модели данных, а не к модели хранения, и используется в этой статье. См. Date (1998).
Важное различие между суррогатом и первичным ключом зависит от того, является ли база данных текущей или временной. Поскольку текущая база данных хранит только действительные на данный момент данные, существует взаимно однозначное соответствие между суррогатом в моделируемом мире и первичным ключом базы данных. В этом случае суррогатный ключ может использоваться в качестве первичного ключа, в результате получается термин суррогатный ключ. Однако во временной базе данных между первичными ключами и суррогатом существует отношение «многие к одному». Поскольку в базе данных может быть несколько объектов, соответствующих одному суррогату, мы не можем использовать суррогат в качестве первичного ключа; требуется еще один атрибут в дополнение к суррогату, чтобы однозначно идентифицировать каждый объект.
Хотя Hall et al. (1976) ничего не говорят об этом, другие утверждали, что суррогатная мать должна иметь следующие характеристики:
В текущей базе данных суррогатный ключ может быть первичным ключом, сгенерированным системой управления базой данных и не полученным из каких-либо данных приложения в базе данных. Единственное значение суррогатного ключа - действовать как первичный ключ. Также возможно, что суррогатный ключ существует в дополнение к UUID, сгенерированному базой данных (например, номер HR для каждого сотрудника, кроме UUID каждого сотрудника).
Суррогатный ключ часто представляет собой последовательный номер (например, «столбец идентификации» Sybase или SQL Server, PostgreSQL или Informix serial, Oracle или SQL Server SEQUENCE или столбец, определенный AUTO_INCREMENTв MySQL ). Некоторые базы данных предоставляют UUID / GUID в качестве возможного типа данных для суррогатных ключей (например, PostgreSQLUUID или SQL ServerUNIQUEIDENTIFIER ).
Наличие ключа, независимого от всех других столбцов, изолирует отношения базы данных от изменений значений данных или структуры базы данных (что делает базу данных более гибкой ) и гарантирует уникальность.
Во временной базе данных необходимо различать суррогатный ключ и бизнес-ключ. Каждая строка будет иметь как бизнес-ключ, так и суррогатный ключ. Суррогатный ключ идентифицирует одну уникальную строку в базе данных, бизнес-ключ идентифицирует одну уникальную сущность моделируемого мира. Одна строка таблицы представляет собой отрезок времени, содержащий все атрибуты объекта в течение определенного периода времени. Эти срезы отражают всю продолжительность жизни одного бизнес-объекта. Например, таблица EmployeeContracts может содержать временную информацию для отслеживания рабочих часов по контракту. Бизнес-ключ для одного контракта будет идентичным (неуникальным) в обеих строках, однако суррогатный ключ для каждой строки уникален.
| SurrogateKey | BusinessKey | Имя сотрудника | Рабочие часы в неделю | RowValidFrom | RowValidTo |
|---|---|---|---|---|---|
| 1 | BOS0120 | Джон Смит | 40 | 2000-01-01 | 2000-12-31 |
| 56 | P0000123 | Боб Браун | 25 | 1999-01-01 | 2011-12-31 |
| 234 | BOS0120 | Джон Смит | 35 год | 2001-01-01 | 2009-12-31 |
Некоторые разработчики баз данных используют суррогатные ключи систематически, независимо от пригодности других ключей-кандидатов, в то время как другие будут использовать ключ, уже присутствующий в данных, если он есть.
Некоторые из альтернативных имен («генерируемый системой ключ») описывают способ генерации новых суррогатных значений, а не природу суррогатной концепции.
Подходы к созданию суррогатов включают:
IDENTITY ИЛИIDENTITY(n,n)SEQUENCE, или GENERATED AS IDENTITY(начиная с версии 12.1)SEQUENCE (начиная с SQL Server 2012)AUTO_INCREMENTAUTOINCREMENTAS IDENTITY GENERATED BY DEFAULTв IBM DB2 Суррогатные ключи обычно не меняются, пока существует строка. Это дает следующие преимущества:
Атрибуты, которые однозначно идентифицируют объект, могут измениться, что может сделать недействительными естественные ключи. Рассмотрим следующий пример:
В этих случаях обычно к естественному ключу должен быть добавлен новый атрибут (например, столбец original_company). С суррогатным ключом должна быть изменена только таблица, которая определяет суррогатный ключ. С естественными ключами все таблицы (и, возможно, другое связанное программное обеспечение), которые используют естественный ключ, должны будут измениться.
Некоторые проблемные области четко не определяют подходящий естественный ключ. Суррогатные ключи избегают выбора естественного ключа, который может быть неправильным.
Суррогатные ключи, как правило, представляют собой компактный тип данных, например четырехбайтовое целое число. Это позволяет базе данных запрашивать один ключевой столбец быстрее, чем несколько столбцов. Более того, неизбыточное распределение ключей приводит к полной сбалансированности результирующего индекса b-дерева. Суррогатные ключи также дешевле объединять (меньше столбцов для сравнения), чем составные ключи.
При использовании нескольких систем разработки приложений баз данных, драйверов и систем объектно-реляционного сопоставления, таких как Ruby on Rails или Hibernate, гораздо проще использовать целочисленные или суррогатные ключи GUID для каждой таблицы вместо естественных ключей для поддержки базы данных. независимые от системы операции и сопоставление строк.
Когда каждая таблица имеет единый суррогатный ключ, некоторые задачи можно легко автоматизировать, написав код независимым от таблицы способом.
Можно создавать пары "ключ-значение", следуя хорошо известному шаблону или структуре, которая может быть проверена автоматически. Например, ключи, которые предназначены для использования в каком-либо столбце какой-либо таблицы, могут быть разработаны так, чтобы «выглядеть иначе», чем те, которые предназначены для использования в другом столбце или таблице, тем самым упрощая обнаружение ошибок приложения, в которых ключи были неуместны. Однако эта характеристика суррогатных ключей никогда не должна использоваться для управления какой-либо логикой самих приложений, поскольку это нарушит принципы нормализации базы данных.
Значения сгенерированных суррогатных ключей не имеют никакого отношения к реальному значению данных, содержащихся в строке. При проверке строки, содержащей ссылку внешнего ключа на другую таблицу с использованием суррогатного ключа, значение строки суррогатного ключа невозможно отличить от самого ключа. Каждый внешний ключ должен быть объединен, чтобы увидеть связанный элемент данных. Если соответствующие ограничения базы данных не были установлены или данные импортированы из устаревшей системы, в которой не использовалась ссылочная целостность, возможно иметь значение внешнего ключа, которое не соответствует значению первичного ключа и, следовательно, является недопустимым. (В этом отношении CJ Date считает бессмысленность суррогатных ключей преимуществом.)
Чтобы обнаружить такие ошибки, необходимо выполнить запрос, который использует левое внешнее соединение между таблицей с внешним ключом и таблицей с первичным ключом, показывая оба ключевых поля в дополнение к любым полям, необходимым для различения записи; все недопустимые значения внешнего ключа будут иметь столбец первичного ключа как NULL. Необходимость в выполнении такой проверки настолько распространена, что Microsoft Access фактически предоставляет мастер «Найти несогласованный запрос», который генерирует соответствующий SQL-запрос после того, как пользователь проведет пользователя через диалоговое окно. (Однако составить такие запросы вручную не так уж сложно.) Запросы «Найти несоответствующие» обычно используются как часть процесса очистки данных при наследовании унаследованных данных.
Суррогатные ключи неестественны для данных, которые экспортируются и используются совместно. Особая трудность заключается в том, что таблицы из двух идентичных схем (например, схемы тестирования и схемы разработки) могут содержать записи, эквивалентные с точки зрения бизнеса, но имеющие разные ключи. Это можно смягчить, НЕ экспортируя суррогатные ключи, за исключением временных данных (наиболее очевидно, при выполнении приложений, которые имеют «живое» соединение с базой данных).
Когда суррогатные ключи заменяют естественные ключи, тогда ссылочная целостность, специфичная для домена, будет скомпрометирована. Например, в основной таблице клиентов один и тот же клиент может иметь несколько записей с разными идентификаторами клиентов, даже если естественный ключ (комбинация имени клиента, даты рождения и адреса электронной почты) будет уникальным. Чтобы предотвратить компромисс, НЕЛЬЗЯ заменять естественный ключ таблицы: он должен быть сохранен как ограничение уникальности, которое реализовано как уникальный индекс для комбинации полей с естественным ключом.
Реляционные базы данных предполагают, что к первичному ключу таблицы применяется уникальный индекс. Уникальный индекс служит двум целям: (i) для обеспечения целостности объекта, поскольку данные первичного ключа должны быть уникальными для всех строк, и (ii) для быстрого поиска строк при запросе. Поскольку суррогатные ключи заменяют идентифицирующие атрибуты таблицы - естественный ключ - и поскольку идентифицирующие атрибуты, скорее всего, будут запрашиваемыми, то оптимизатор запросов вынужден выполнять полное сканирование таблицы при выполнении вероятных запросов. Средство от полного сканирования таблицы - применить индексы к идентифицирующим атрибутам или их наборам. Если такие наборы сами являются ключом-кандидатом, индекс может быть уникальным индексом.
Однако эти дополнительные индексы будут занимать дисковое пространство и замедлять вставку и удаление.
Суррогатные ключи могут приводить к дублированию значений в любых естественных ключах. Чтобы предотвратить дублирование, необходимо сохранить роль естественных ключей как уникальных ограничений при определении таблицы с помощью оператора SQL CREATE TABLE или оператора ALTER TABLE... ADD CONSTRAINT, если ограничения добавлены запоздало.
Поскольку суррогатные ключи неестественны, при моделировании бизнес-требований могут появиться ошибки. Затем бизнес-требования, основанные на естественном ключе, необходимо преобразовать в суррогатный ключ. Стратегия состоит в том, чтобы провести четкое различие между логической моделью (в которой суррогатные ключи не появляются) и физической реализацией этой модели, чтобы гарантировать, что логическая модель верна и достаточно хорошо нормализована, а также гарантировать, что физическая модель является правильной. правильная реализация логической модели.
Конфиденциальная информация может просочиться, если суррогатные ключи генерируются последовательно. Вычитая ранее сгенерированный последовательный ключ из недавно сгенерированного последовательного ключа, можно узнать количество строк, вставленных в течение этого периода времени. Это может показать, например, количество транзакций или новых счетов за период. Например, см. Проблему с немецким танком.
Есть несколько способов решить эту проблему:
Последовательно сгенерированные суррогатные ключи могут означать, что события с более высоким значением ключа произошли после событий с более низким значением. Это не обязательно верно, потому что такие значения не гарантируют временную последовательность, поскольку вставки могут выйти из строя и оставить пробелы, которые могут быть заполнены позже. Если важна хронология, дату и время необходимо записывать отдельно.
|journal=( помощь )