Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Ключ суррогатного (или синтетический ключ , pseudokey , идентификатор лица , ключ генерируется система , порядковый номер базы данных , неподтвержденный ключ , технический ключ , или произвольным уникальный идентификатор ) в базе данных представляет собой уникальный идентификатор либо для лица в моделируемом мире или объект в базе данных. Суррогатный ключ не выводится из данных приложения, в отличие от естественного (или бизнес- ключа), который выводится из данных приложения. [1]

Определение [ править ]

Есть как минимум два определения суррогата:

Суррогат (1) - Холл, Олетт и Тодд (1976)
Суррогат представляет собой сущность во внешнем мире. Суррогат генерируется внутри системы, но, тем не менее, виден пользователю или приложению. [2]
Суррогат (2) - Виринга и Де Йонге (1991)
Суррогат представляет собой объект в самой базе данных. Суррогат создается внутри системы и невидим для пользователя или приложения.

Определение 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 может содержать временную информацию для отслеживания рабочих часов по контракту. Бизнес-ключ для одного контракта будет идентичным (неуникальным) в обеих строках, однако суррогатный ключ для каждой строки уникален.

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

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

Подходы к созданию суррогатов включают:

  • Универсальные уникальные идентификаторы (UUID)
  • Глобальные уникальные идентификаторы (GUID)
  • Идентификаторы объекта (OID)
  • Столбец идентификаторов Sybase или SQL ServerIDENTITY ИЛИIDENTITY(n,n)
  • Oracle SEQUENCE , или GENERATED AS IDENTITY(начиная с версии 12.1) [3]
  • SQL Server SEQUENCE (начиная с SQL Server 2012) [4]
  • PostgreSQL или IBM Informix серийный
  • MySQL AUTO_INCREMENT
  • SQLite AUTOINCREMENT
  • Тип данных AutoNumber в Microsoft Access
  • AS IDENTITY GENERATED BY DEFAULTв IBM DB2
  • Столбец идентичности (реализованный в DDL ) в Teradata
  • Последовательность таблиц, когда последовательность вычисляется процедурой и таблицей последовательностей с полями: id, sequenceName, sequenceValue и incrementValue

Преимущества [ править ]

Стабильность [ править ]

Суррогатные ключи обычно не меняются, пока существует строка. Это дает следующие преимущества:

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

Изменения требований [ править ]

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

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

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

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

Производительность [ править ]

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

Совместимость [ править ]

При использовании нескольких систем разработки приложений баз данных, драйверов и систем объектно-реляционного сопоставления , таких как Ruby on Rails или Hibernate , гораздо проще использовать целочисленные или суррогатные ключи GUID для каждой таблицы вместо естественных ключей для поддержки базы данных. независимые от системы операции и сопоставление строк.

Единообразие [ править ]

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

Проверка [ править ]

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

Недостатки [ править ]

Диссоциация [ править ]

Значения сгенерированных суррогатных ключей не имеют никакого отношения к реальному значению данных, содержащихся в строке. При проверке строки, содержащей ссылку внешнего ключа на другую таблицу с использованием суррогатного ключа, значение строки суррогатного ключа невозможно отличить от самого ключа. Каждый внешний ключ должен быть объединен, чтобы увидеть связанный элемент данных. Если соответствующие ограничения базы данных не были установлены или данные импортированы из устаревшей системы, в которой ссылочная целостность не использовалась, возможно иметь значение внешнего ключа, которое не соответствует значению первичного ключа и, следовательно, является недопустимым. (В этом отношении CJ Date считает бессмысленность суррогатных ключей преимуществом. [5] )

Чтобы обнаружить такие ошибки, необходимо выполнить запрос, который использует левое внешнее соединение между таблицей с внешним ключом и таблицей с первичным ключом, показывая оба ключевых поля в дополнение к любым полям, необходимым для различения записи; все недопустимые значения внешнего ключа будут иметь столбец первичного ключа как NULL. Необходимость выполнения такой проверки настолько распространена, что Microsoft Access фактически предоставляет мастер «Найти несогласованный запрос», который генерирует соответствующий SQL-запрос после того, как пользователь проведет пользователя через диалоговое окно. (Однако составить такие запросы вручную не так уж сложно.) Запросы «Найти несогласованные» обычно используются как часть процесса очистки данных при наследовании унаследованных данных.

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

Когда суррогатные ключи заменяют естественные ключи, тогда ссылочная целостность, зависящая от домена, будет нарушена. Например, в основной таблице клиентов один и тот же клиент может иметь несколько записей под разными идентификаторами клиентов, даже если естественный ключ (комбинация имени клиента, даты рождения и адреса электронной почты) будет уникальным. Чтобы предотвратить компромисс, НЕЛЬЗЯ вытеснять естественный ключ таблицы: он должен быть сохранен как ограничение уникальности , которое реализовано как уникальный индекс для комбинации полей с естественным ключом.

Оптимизация запросов [ править ]

Реляционные базы данных предполагают, что к первичному ключу таблицы применяется уникальный индекс . Уникальный индекс служит двум целям: (i) для обеспечения целостности объекта, поскольку данные первичного ключа должны быть уникальными для всех строк, и (ii) для быстрого поиска строк при запросе. Поскольку суррогатные ключи заменяют идентифицирующие атрибуты таблицы - естественный ключ - и поскольку идентифицирующие атрибуты, скорее всего, будут запрашиваемыми, то оптимизатор запросов вынужден выполнять полное сканирование таблицы при выполнении вероятных запросов. Средство от полного сканирования таблицы - применить индексы к идентифицирующим атрибутам или их наборам. Если такие наборы сами являются ключом-кандидатом , индекс может быть уникальным индексом.

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

Нормализация [ править ]

Суррогатные ключи могут приводить к дублированию значений в любых естественных ключах . Чтобы предотвратить дублирование, необходимо сохранить роль естественных ключей как уникальных ограничений при определении таблицы с помощью оператора SQL CREATE TABLE или оператора ALTER TABLE ... ADD CONSTRAINT, если ограничения добавлены запоздало.

Моделирование бизнес-процессов [ править ]

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

Случайное раскрытие [ править ]

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

Есть несколько способов решить эту проблему:

  • Увеличьте порядковый номер на случайную величину.
  • Сгенерируйте случайный ключ, такой как UUID

Случайные предположения [ править ]

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

См. Также [ править ]

  • Натуральный ключ
  • Идентификатор объекта
  • Постоянный идентификатор объекта

Ссылки [ править ]

Цитаты [ править ]

  1. ^ «Что такое суррогатный ключ? - Определение из Техопедии» . Techopedia.com . Проверено 21 февраля 2020 .
  2. ^ PAV Hall, J Owlett, SJP Тодд, "Отношения и Сущности", Моделирование в системах управления базами данных (ред GM Nijssen) , Северная Голландия 1976.
  3. ^ http://docs.oracle.com/database/121/SQLRF/statements_7002.htm#SQLRF01402
  4. ^ https://msdn.microsoft.com/en-us/library/ff878091.aspx
  5. ^ Дата CJ. Примат первичных ключей. Из «Написание реляционных баз данных, 1991–1994 годы. Аддисон-Уэсли, Ридинг, Массачусетс».

Источники [ править ]

  • Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или новее.
  • Нейссен, GM (1976). Моделирование в системах управления базами данных . Паб Северная Голландия. Co. ISBN 0-7204-0459-2.
  • Энглс, Р. У .: (1972), Учебное пособие по организации баз данных , Ежегодный обзор автоматического программирования, том 7, часть 1, Pergamon Press, Oxford, стр. 1–64.
  • Лангефорс, Б. (1968). Elementary Files and Elementary File Records , Proceedings of File 68, Международный семинар IFIP / IAG по организации файлов, Амстердам, ноябрь, стр. 89–96.
  • Wieringa, R .; де Йонге, В. (1991). «Идентификация объектов и ролей: еще раз об идентификаторах объектов». CiteSeerX  10.1.1.16.3195 . Цитировать журнал требует |journal=( помощь )
  • Дата, CJ (1998). «Главы 11 и 12». Написание реляционных баз данных 1994–1997 . ISBN 0201398141.
  • Картер, Брек. «Интеллектуальные ключи против суррогатных» . Проверено 3 декабря 2006 .
  • Ричардсон, Ли. «Create Data Disaster: избегайте уникальных индексов - (ошибка 3 из 10)» . Архивировано из оригинала на 2008-01-30 . Проверено 19 января 2008 .
  • Беркус, Джош. «Суп базы данных: первичный ключевой порок, часть I» . Проверено 3 декабря 2006 .