"Проектирование реляционных баз данных." - читать интересную книгу автора (Джен Л. Харрингтон)

¦ Уникальность. В отношении не может быть повторяющихся строк.
В большинстве СУБД ограничение уникальности строк не устанавливается автоматически. Однако, как будет показано ниже, уникальности строк можно добиться другим способом.
¦ Первичный ключ. Первичный ключ (primary key) — это столбец или комбинация столбцов, однозначно определяющих каждую строку. Пока существуют уникальные первичные ключи, можно быть уверенным в уникальности строк. О том, что такое хороший первичный ключ, рассказывается ниже.
Типы таблиц
В реляционных базах данных применяются таблицы двух типов. Базовые таблицы wase tables) — это отношения, реально хранящиеся в базе данных. Именно такие таб-лиЦы составляют схему. Однако в результате выполнения над таблицами реляционных ераций создаются дополнительные таблицы, которые существуют только в оперативной памяти компьютера и называются виртуальными таблицами (virtual tables). ^и могут не являться настоящими отношениями (так, у них могут отсутствовать типичные ключи), но благодаря тому что виртуальные таблицы никогда не хранятся V^e данных, они не вызывают каких-либо проблем с точки зрения структуры базы.
it
ш
36
Часть первая • Теория
В языке SQL, используемом для работы с большинством реляционных СУБД, поддерживаются также "временные базовые таблицы". Такие таблицы, хотя и называются "базовыми , являются временными и фактически виртуальными потому, что существуют непродолжительное время только в оперативной памяти и никогда не записываются в физическую базу данных.
Обозначение отношений
Примеры отношений приводятся на протяжении всей книги. Однако при документировании отношения данные в его состав обычно не включаются. Одним из способов записи отношений является следующий:
имя_отношения (первичный_ключ, столбец_не_первичного_ключа, ...)
Например, отношение customers (рис. 3.1), можно записать следующим образом:
customers (customer_numb, first_riame, last_name, phone)
Первичные ключи
Как было отмечено, уникальный первичный ключ позволяет однозначно идентифицировать каждую строку таблицы. Почему же это так важно? Ответ на этот вопрос аналогичен тому, который был дан при рассмотрении идентификаторов сущностей: необходима возможность выбора любого единичного фрагмента данных, помещенных в базу.
Что касается реляционных баз данных, то можно сказать, что для считывания любого конкретного элемента данных нужно знать три информационных компонента: имя таблицы, имя столбца и первичный ключ строки. Если для каждой строки первичные ключи уникальны, можно быть уверенным в выборе именно той строки, которая нужна. Если же эти ключи не уникальны, считываться будет только одна из строк с данным значением первичного ключа, которая может и не быть строкой, содержащей искомые данные.
Кроме того, что первичный ключ должен быть уникальным, он не может содеР' жать null-значение. Null — специальное значение базы данных, "неизвестное значение. Это не то же самое, что нуль или пустое значение. Если null-значение присвоен первичному ключу одной строки, то все в порядке. Однако в тот момент, когда появ ляется второе такое значение, свойство уникальности теряется. Именно поэтому нал чие null-значений в любых столбцах первичных ключей запрещается. Всякий раз пр вводе или изменении данных в СУБД устанавливается соответствующее ограничени > называемое сущностной целостностью (entity integrity).

Глава 3 • Реляционная модель данных
37
Выбор хорошего первичного ключа может оказаться довольно трудной задачей. п главе 2 было отмечено, что некоторые сущности обладают естественными первичными ключами, например номера заказов на продажу. Идентификаторы других сущностей уникальные, произвольные и без определенного смысла, например номера, присваиваемые компанией заказам при направлении их поставщикам; такие идентификаторы являются идеальными первичными ключами.
Первичные ключи для идентификации людей
Что можно сказать о первичных ключах, применяемых для идентификации людей? Первое, что возникает при этом в памяти,— номер службы социальной защиты (США.— Прим. пер.) (SSN — social security number). Каждый проживающий в США человек, достигший возраста 12 месяцев, имеет такой номер? И правительство США присваивает эти номера так, чтобы они были уникальны? К сожалению, ответ на оба этих вопроса отрицательный.
Известно, что администрация, ведающая социальной защитой, назначает всем жителям населенного пункта один и тот же номер SSN; спустя некоторое время номера SSN используются повторно. Однако эта проблема — пустяк по сравнению с той ситуацией, когда номера службы социальной защиты являются null-значениями.
Посмотрим, что произойдет в некотором учебном заведении, где номера службы социальной защиты используются в качестве номеров студентов, при зачислении на учебу иностранцев. По приезде в страну иностранные студенты не имеют номеров SSN. Поскольку первичные ключи не могут быть null-значениями, иностранные студенты не имеют возможности зарегистрироваться в учебных группах и даже быть внесенными в список колледжа до тех пор, пока им не будет назначен номер SSN определенного вида.
Для этого иностранцам назначаются так называемые "фиктивные" номера формата 999-999-ХХХХ, где ХХХХ — некоторое число, не используемое в текущий момент. Затем, когда студент получает "настоящий" номер SSN от правительства *~ША, колледж заменяет фиктивное значение настоящим. Однако порой эта процедура не срабатывает. Например, оценки выпускника за первый семестр хранятся под фиктивным номером SSN, а остальные оценки — под его настоящим номером (вместо изменения первоначальных сведений кто-то создал для этого студента абсолютно но-¦ Ую характеристику). Когда наступает время проверки характеристики и студент хочет Узнать, соответствуют ли его оценки ожидаемым, ему сообщают, что он пропустил Целый семестр учебных курсов. Этот пример показывает важность двух свойств перяных ключей:
* Первичный ключ должен быть значением, вероятность которого стать когда-либо null-значением мала.
¦ Первичный ключ никогда не должен изменяться.
38
Часть первая • Теория
Хотя на первый взгляд номера службы социальной защиты кажутся вполне нор. мальными естественными идентификаторами, для идентификации людей в течение длительного периода времени гораздо лучше применять произвольные числа (напри, мер, номера студентов или номера счетов).
Стоит отметить еще один важный момент — охрана частной жизни пользователя при работе с номерами SSN в среде, где не нужно сообщать о доходах. Это не оказывает никакого влияния на структуру базы данных, но нередко весьма существенно с социальной точки зрения.
О смысловой значимости первичных ключей
Порой возникает желание внести в обозначение первичного ключа определенный смысл. Предположим, что компания Lasers Only хочет присваивать своим оптовым поставщикам не произвольные номера, а некоторые коды, например TLC для The Laser Club и JS для Jones Services. На первый взгляд, это довольно неплохая идея: коды коротки и по ним можно сразу определить соответствующего поставщика.
Но что произойдет, если одна из этих компаний поменяет свое название? Скажем; Jones Services станет Jones Distribution House? Нужно ли менять первичный ключ таблицы оптовых поставщиков или код, чтобы тот стал JDH? И если бы дело было только в таблице поставщиков, решить задачу было бы не так уж сложно.
Предположим, в таблице, описывающей товары, содержатся коды поставщиков, что позволяет Lasers Only знать, какая именно из компаний поставляет тот или иной товар (см. ниже). При изменении кода поставщика необходимо изменить код каждого товарного пункта, предоставляемого этим поставщиком, иначе не удастся установить соответствие между кодом и поставщиком и получить сведения о последнем. Будет казаться, что товар поступает от несуществующего поставщика!
Об этом же шла речь в главе 1, когда рассматривались идентификаторы клиентов Lasers Only.
Ключи, обладающие определенным смыслом, могут меняться, и поэтому иХ использование может привести к серьезным несоответствиям информации нескольких таблиц. Не поддавайтесь искушению применять такие ключи. Отсюда вытекает еЩе одно свойство хорошего первичного ключа:
¦ Избегайте использования в первичном ключе информации, обладающей каким-либо смыслом. По мере возможности применяйте произвольные идентификаторы или их комбинации.

Глава 3 • Реляционная модель данных
39
Однако не всегда удается использовать абсолютно ничего не значащие первичные кл1очи. Может возникнуть ситуация, когда необходимо, скажем, включить в первичней ключ дату или время, чтобы отличать одно событие от другого. Таким образом, предложение не использовать смысловые первичные ключи — это не жесткое правило, а просто рекомендация, которой следует придерживаться в реальной ситуации.
Составные первичные ключи
В некоторых таблицах нет такого одного столбца, значения которого никогда не дублируются. В качестве примера рассмотрим таблицу партий заказов (order_Iines), изображенную на рис. 3.2. Поскольку в заказе более одного пункта, номера заказов повторяются; номера пунктов повторяются потому, что один и тот же пункт может фигурировать более чем в одном заказе. Следовательно, ни один из столбцов самостоятельно не может служить первичным ключом этой таблицы.
Order number Item number Quantity
10991 0022 1
10991 0209 2