Проектирование базы данных начинается с концептуальной модели данных (такой как диаграмма отношений сущностей) и заканчивается схемой или схемами базы данных. Объекты отображаются в таблицы; в этом процессе одна сущность может быть разделена на несколько таблиц, несколько сущностей могут быть объединены в одну таблицу, и могут возникнуть новые таблицы (например, таблицы пересечений для реализации отношений «многие ко многим»).
В ERD сущности имеют первичные ключи. Это естественные ключи, то есть они являются атрибутами сущности. Для объекта PERSON это может быть SocialSecurityNumber. Для объекта ORDER if может быть OrderRef Для объекта INVOICE это может быть InvoiceNo. В первом случае это реальный идентификатор; во втором случае это смарт-ключ в ужасном формате (2010 / DEF / 000023); в третьем случае это монотонно увеличивающееся число, потому что это то, что использует текущая бумажная система.
Натуральные ключи могут быть причудливыми. Однажды я работал над дизайном базы данных, в котором аналитик указал сущность CUSTOMER с ключом (FullName, Address, Sex, DateOfBirth, DistinguishingCharacteristics), исходя из того, что два человека с одинаковым именем, датой рождения и полом могут жить в одном месте. адрес.
Характеристики первичного ключа объекта:
- уникальный
- 1012 * знакомый *
- стабильный (предполагаемый)
- минимальный (один или несколько атрибутов, но столько, сколько необходимо)
Когда речь идет о первичных ключах для таблиц базы данных, естественные ключи не всегда подходят.
Есть много причин не использовать SSN в качестве физического первичного ключа. Защита личных данных гражданина на самом деле является наиболее важной, но это также тот случай, когда номер человека может измениться. Первичные ключи должны быть неизменными.
Умные клавиши тупые. На самом деле это составные ключи, сжатые в один столбец. Они лучше представлены в виде отдельных столбцов, не в последнюю очередь потому, что часто требуется выполнять поиск по отдельным элементам ключа. Также формат таких клавиш может меняться.
В общем случае составные ключи - это боль в качестве первичных ключей, потому что мы должны каскадировать несколько столбцов в качестве внешних ключей. Это усугубляется, когда первичный ключ ребенка определяется как серийный номер в первичном ключе родителя. Существуют системы, в которых зависимые таблицы наследуют внешний ключ из девяти столбцов от родительского, когда у них мало двух собственных столбцов данных. Иногда такого рода наследование может быть полезным, но в основном это просто хлопот.
Характеристики первичного ключа объекта:
- уникальный
- уместно (бессмысленно)
- гарантированная стабильность
- минимальный, обычно один столбец (кроме таблиц пересечений)
Таким образом, если ключ-кандидат не является бессмысленным идентификатором (например, InvoiceNo), таблица должна иметь синтетический ключ (суррогатный ключ AKA). Это может быть монотонно увеличивающееся число или GUID в соответствии с вашими потребностями. Что касается таблиц пересечений, если у них нет других атрибутов или зависимых таблиц, нет смысла заменять составной первичный ключ (составной ключ AKA) синтетическим.
Самое важное: мы все еще применяем ключи-кандидаты . Это означает применение ограничений UNIQUE для этих столбцов - SSN, OrderRef - в родительской таблице. Это связано с тем, что синтетический ключ однозначно идентифицирует строку в таблице, но не уникально идентифицирует данные.
По поводу знакомства
Знакомство кудрявое. Это важный момент, когда речь идет о том, что мы идентифицируем первичные ключи в концептуальной модели данных, но он менее полезен, когда речь идет о проектировании базы данных.
В комнете @bbadour предоставляет два контрастных примера:
{3296013,840082470,Bob Badour,745} versus {840082470,Bob Badour,PE,CA}
и ставит вопрос:
«Чего добивается 3296013, чего еще не достиг 840082470, который является основным ключом для моих академических достижений в любой или каждой средней школе в Канаде».
Ну, 840082470 похоже на номер счета. Само по себе это бессмысленная цепочка цифр. Если система, которую мы разрабатываем, относится к области высшего образования Канады, то она, безусловно, приемлема в качестве ключа кандидата. Однако, поскольку он является ключом, очевидно принадлежащим внешней центральной системе (простите, что я не понимаю канадскую академическую систему), он открыт для некоторых возражений против SSN в качестве первичного ключа. Мы полагаемся на эту внешнюю систему, чтобы гарантировать уникальность, гарантировать стабильность и проверять идентификацию.
Что касается 745 против PE, CA , это явно неверно. Канадская почтовая аббревиатура «Остров Принца Эдуарда» и документ ISO для «Канады» идентифицируют две разные части информации и происходят из разных источников, поэтому их следует представлять в виде двух отдельных столбцов. Но давайте сосредоточимся на том, делает ли 745 или PE лучший первичный ключ.
Во-первых, базе данных не важно, какой тип данных мы используем для кода, который представляет «Остров Принца Эдуарда». Он просто хочет гарантированной уникальности.
Во-вторых, обращенная к пользователю часть системы, скорее всего, будет отображать полное расширение «Остров Принца Эдуарда», и в этом случае приложение в любом случае должно будет выполнить поиск. Это связано с тем, что пользователи системы, которая также содержит адреса из страны Перу или штата Калифорния, оценят четкость расширенных имен [1]. Конечно, если мы пойдем дальше нескольких сложных случаев (таких как сокращения состояний), приложение всегда должно расширять коды при отображении их пользователям.
Таким образом, единственное преимущество использования PE , а не 745 , состоит в том, что это упрощает специальные запросы.
В-третьих, если расширение кода изменится, мы можем захотеть различать записи, которые используют более новую версию. Это намного проще, если 745='Prince Edward Island' и 746='Prince Edward Is.', чем если мы используем PE в качестве первичного ключа.
В-четвертых, есть соображения по программированию. Например, если разработчики приложений должны предоставить раскрывающиеся списки с использованием перечислений Java, им нужны числовые коды.
Короче говоря, знакомство с естественными ключами не так полезно, как практичность суррогатных ключей.
[1] Канадцы будут знать, что CA означает Канаду. Но стоит ли МО за Марокко, Монако, Молдову, Черногорию, Монголию или Монтсеррат? На самом деле ни один из них: это Макао.