Бизнес-ключ и суррогатный ключ нужны оба
Схема данных, обеспечивающая связь бизнес-ключей с суррогатным ключом
Пару дней назад я агитировал всеми уважаемого эксперта в хранилищах данных за новый стандарт суррогатных ключей UUIDv7 для высоконагруженных систем, и получил от него ответ:
«На самом деле, и, по моему скромному мнению, НИКАКОЙ суррогатный ключ не является достаточно хорошим, или его не следует использовать. По моему скромному мнению, настоящие и истинные бизнес-ключи (буквенно-цифровые значения с понятным для человека значением) — это путь вперед и правильный способ проектирования, идентификации, архитектуры и связывания данных вместе. Примером этого может быть vehicle identification number (глобальный стандартный идентификатор с понятным для человека значением). Да, он содержит порядковые номера как составную часть, но сам ключ — это гораздо больше.
Для меня все суррогаты (сгенерированные машиной идентификаторы) — бесполезные бессмысленные биты данных. Они служат только для «уникальной идентификации строки/набора данных». После «отсоединения» от данных, которые он представляет, значение ключа становится абсолютно бессмысленным, тогда как настоящий бизнес-ключ (как описано выше) по-прежнему сохраняет свою ценность для людей, даже в качестве отдельного ключа.»
Пришлось писать ответное письмо, из которого родилась эта статья.
Действительно, было бы замечательно, если бы один и тот же буквенно-цифровой код мог применяться и для ссылки на внешние данные (например, реестры или классификаторы), и для связи строк в разных таблицах базы данных. Но примеры таких бизнес-ключей (естественных ключей) в виде буквенно-цифровых кодов очень трудно найти, и при ближайшем рассмотрении они оказываются негодными. Например, для меня было неприятной неожиданностью, что российский ИНН неуникален (в редких случаях). Кроме того, внешние идентификаторы время от времени изменяются (пример — смена фамилии), и поэтому их невозможно использовать в базах данных без ухищрений. А когда возникла необходимость объединить в одной таблице все виды залогов, то в столбец c VIN (vehicle identification number, идентификационный номер транспортного средства) пришлось добавить кадастровый номер недвижимости, и возникли сомнения в уникальности смешанного идентификатора в столбце. Кроме того, японские автомобили не имеют VIN! У них другая маркировка. Это может быть номер шасси, либо кузова, либо рамы. Вместо общепринятого VIN из 17 цифр и букв, он содержит от 9 до 12 символов.
Идентификатор, как правило, имеет двойственную природу. С одной стороны, идентификатор должен указывать на объекты реального мира, отображать как есть значения из внешних классификаторов и справочников и изменяться при изменениях во внешних классификаторах и справочниках (это бизнес-ключ). С другой стороны, для связи строк в разных таблицах базы данных идентификатор должен быть абсолютно стабилен (это суррогатный ключ). Попытка совместить эти несовместимые требования в одном идентификаторе всегда приводит к огромным проблемам в базах данных (дефекты данных, перекодировки, чрезмерное увеличение количества полей бизнес-ключа и т.д.). Поэтому всегда должна сохраняться связь бизнес-ключей с суррогатным ключом. Каждый вид ключа должен выполнять только одну свою узкую функцию.
Предпочтительная схема данных, обеспечивающая связь бизнес-ключей с суррогатным ключом, помещена в начале этой статьи. Хаб — это таблица базы данных, относящаяся к какой-то одной сущности (люди или автомобили и т.п.). Хаб содержит связь бизнес-ключей с суррогатным ключом. Одному суррогатному ключу может соответствовать несколько разных бизнес-ключей. Например, человек может идентифицироваться по ИНН, или по ФИО, дате и месту рождения, или по номеру паспорта. Изменчивость бизнес-ключа обеспечивается атрибутами историчности (изменения в реальности) и версионности (изменения в учете), например, datetime_from, datetime_before, record_datetime. Бизнес-ключ может состоять из нескольких атрибутов, например, из фамилии, имени и отчества. Остальные таблицы, содержащие атрибуты сущности или связи данной сущности с другими сущностями, соединяются с хабом по суррогатному ключу.
Когда необходимо составить отчет для бизнес-пользователей и внешних организаций, должны применяться не суррогатные, а актуальные на отчетную дату бизнес-ключи.
Что касается лучшего типа суррогатного ключа, то теперь это несомненно UUIDv7. Читайте мою статью «Встречайте UUID нового поколения для ключей высоконагруженных систем» и ждите продолжение.
Если же в дополнение к реальному миру и к информационной системе возникает третья сторона — человек (аналитик и пользователь хранилища данных), то возникает необходимость в человекочитаемых идентификаторах. При небольшом количестве возможных значений часто в качестве ключа применяют короткие буквенные или буквенно-цифровые коды, создаваемые вручную, в которых легко возникает путаница. Для UUIDv7 же легко получить человекочитаемый идентификатор длиной 26 символов путем применения кодировки Crockford’s Base32. Вот пример такого идентификатора: 01H7K17QKJ5ND32CQS0NB03FXW. Может быть, произносить это и долго, но зато можно легко найти похожий идентификатор, скопировать в буфер обмена, сравнить с другим идентификатором на глаз.
