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

Поскольку строки в реляционной таблице не упорядочены, нельзя выбрать строку по ее номеру в таблице. В таблице нет «первой», «последней» или «тридцатой» строки. Тогда каким же образом можно выбрать в таблице конкретную строку, например, строку для офиса, расположенного в Инзе?

В правильно построенной базе данных в каждой таблице есть один или несколько столбцов, значения которых во всех строках разные. Этот столбец (столбцы) называется первичным ключом таблицы. В нашей учебной базе данных на первый взгляд, первичным ключом таблицы OFFISY могут служить и столбец ID_OFC, и столбец CITY. Однако если компания будет расширяться и откроет в каком-либо городе второй офис, столбец CITY больше не сможет исполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как идентификатор офиса (ID_OFC в таблице OFFISY), служащего (ID_OFC в таблице SLUZHASCHIE) и клиента (ID_CLN в таблице CLIENTY ). А в случае с таблицей нет выбора – единственным столбцом, содержащим уникальные значения, является номер заказа (ID_ORDER).

Таблица TOVARY является примером таблицы, в которой первичный ключ представляет собой комбинацию столбцов. Такой первичный ключ называется составным. столбец ID_MFR содержит идентификаторы производителей всех товаров, перечисленных в таблице, а столбец ID_PRD содержит номера, присвоенные товарам производителями. Может показаться, что столбец ID_PRD мог бы и один исполнять роль первичного ключа, однако ничто не мешает двум разным производителям присвоить своим изделиям одинаковые номера. Таким образом, в качестве первичного ключа таблицы TOVARY необходимо использовать комбинацию столбцов ID_MFR и ID_PRD. Для каждого из товаров, содержащихся в таблице, комбинация значений в этих столбцах будет уникальной. Первичный ключ для каждой строки таблицы является уникальным, поэтому в таблице с первичным ключом нет двух совершенно одинаковых строк.

2.2.3 Отношения предок/потомок

Одним из отличий реляционной модели от первых моделей представления данных было то, что в ней отсутствовали явные указатели, используемые для реализации отношений предок/потомок в иерархической модели данных. Однако вполне очевидно, что такие отношения существуют и в реляционных базах данных. Например, в нашей учебной базе каждый из служащих закреплен за конкретным офисом, поэтому ясно, что между строками таблицы OFFISY и таблицы SLUZHASCHIE существует отношение. Не приводит ли отсутствие явных указателей в реляционной модели к потере информации?

Ответ на этот вопрос будет отрицательным. На Рис. 2.9 изображено несколько строк из таблиц OFFISY и SLUZHASCHIE. Обратите внимание на то, что в столбце ID_OFC таблицы SLUZHASCHIE содержится идентификатор офиса, в котором работает служащий. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов офисов, содержащихся в столбце ID_OFC таблицы OFFISY. Узнать в каком офисе работает Иванов Иван, можно, определив значение столбца ID_OFC в строке таблицы SLUZHASCHIE для Иванов Иван (число 11) и затем отыскав в таблице OFFISY строку с таким же значением в столбце ID_OFC (это строка для офиса в Буинске). Таким же образом, чтобы найти всех служащих Буинского офиса, следует запомнить значение ID_OFC для Буинска (число 11), а потом просмотреть таблицу SLUZHASCHIE и найти все строки, в столбце ID_OFC которых содержится число 11 (это строки для Иванова Ивана и Уткина Дениса).

Рис. 2.9 - Отношения предок/потомок в реляционной базе данных

Отношение предок/потомок, существующее между офисами и работающими в них людьми, в реляционной модели не потеряно; просто оно реализовано в виде одинаковых значений данных, хранящихся в двух таблицах, а не в виде явного указателя. Все отношения, существующие между таблицами реляционной базы данных, реализуются таким способом. Одним из главных преимуществ языка SQL является возможность извлекать данные, связанные между собой, используя эти отношения.