Реляционные базы данных - таблицы, страница 2

 Первичный ключ

Первичный ключ в СУРДБ выполняет больше чем одну работу. Мы сказали уже, что он используется, чтобы определить отношения; но его первичная роль в том, чтобы уникально идентифицировать каждую запись в таблице.

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

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

Примечание: Хотя это и не требование, хорошей практикой считается иметь первичный ключ в каждой таблице; фактически, многие СУРБД  предупреждают  Вас, если Вы создаете таблицу без того, чтобы назначить первичный ключ. Некоторые пуристы(программисты) идут даже далее, говоря, что первичный ключ бессмысленен в смысле, что они использовали бы некоторое сгенерированное уникальное значение (подобно EMPLOYEE_ID) вместо, скажем, Social Security numbers {числа Социального обеспечения} (несмотря на то что он также является уникальным).

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

Примечание: В мире СУРБД, только таблицы, которые имеют первичные ключи, могут быть связаны. Хотя первичный ключ - краеугольный камень для определения отношений в СУРБД, системы управления (особенно ранние) не всегда обеспечивали встроенную поддержку для этой логической концепции. Практически, задача предписания уникальности выбранного первичного ключа была ответственность программистов (например требование, проверки существующих значений перед вставкой новых записей). Сегодня все основные системы управления  базами данных имеют встроенную поддержку первичных ключей; это означает, что база данных делает собственную проверку на нарушение уникальности ключей и выдает ошибку всякий раз, когда сделана попытка создать повторяющуюся запись.

Вторичный ключ

Давайте вернемся к нашим таблицам CUSTOMER и ORDER_HEADER. В настоящее время Вы понимаете, почему CUST_ID_N обозначен как первичный ключ -  CUST_ID_N имеет уникальное значение, никакой заказчик не может иметь больше чем один ID, и никакой ID не может быть назначен больше чем одному заказчику. Чтобы прослеживать какой из заказчиков что либо  заказывает, мы нуждаемся в кое-чем, что обеспечит связь между заказчиками и их заказами.

Таблица ORDER_HEADER имеет собственный первичный ключ - ORDHDR_ID_N, который уникально идентифицирует заказы; в дополнение к этому она имеет вторичный ключа - ORDHDR_CUSTID_FN. Значения в этом поле совпадают с значениями в первичном ключе CUST_ID_N в таблице CUSTOMER. Обратите внимание, что, в отличие от первичного ключа, не требуется чтобы вторичный ключ был уникальным - один заказчик может размещать несколько заказов.

Теперь, изучая таблицу ORDER_HEADER вы можете найти тех заказчиков, которые поместили специфические заказы. Таблица ORDER_HEADER теперь связанна с таблицей CUSTOMER. Теперь просто найти заказчика по его заказам, или находить заказы относительно заказчика. Вы больше не должны знать структуру базы данных, порядок записей в таблице, или владеть некоторым составляющими языка программирования низкого уровня, чтобы сделать запрос данных; теперь возможно выполнить запросы для данного случая, сформулированные на стандартном, подобному английскому языку, языке - the Structured Query Language.(SQL) {Структурированный Язык Запроса}.