Ключом таблицы называется поле
или группа полей, содержащие уникальные в рамках
данной таблицы значения. Ключ однозначно
определяет соответствующую строку таблицы. Если
ключ состоит из одного поля, его часто называют простым,
если из нескольких — составным. В
приведенном выше примере ключом является поле
ИНН (мы считаем известным тот факт, что ИНН в
пределах страны являются уникальными). Потенциальные ключи.Потенциальным ключом будем называть такую
комбинацию столбцов, которая обладает следующими свойствами:
- УникальностьюВ таблице нет двух разных строк с
одиноковыми
значениями в нашем потенциальном ключе.
- Неизбыточностью.Нельзя убрать один из столбцом
из ключа, так,
чтобы он не потерял уникльности.
Рассмотрим, например, такую таблицу:
|
№ паспорта |
Фамилия |
Имя |
Отчество |
Должность |
|
123456 |
Иванов |
Иван |
Иванович |
Директор |
|
234567 |
Петров |
Петр |
Иванович |
Его зам |
|
345678 |
Сидорова |
Мария |
Ивановна |
Секретарша |
В данной
таблице
в качестве потенциального ключа можно рассматривать любой столбец.
Но она
у нас будет расширяться, так что будем смотреть в будущее.
Понятно, что отчество не может быть потенциальным ключом - есть
совпадения. Фамилия - может, если только мы не планируем появления
новых
строк в таблице. Можно взять комбинацию фамилии и должности,
врядли у нас
будет два директора-однофамильца. Номер паспорта также подходит на
роль
потенциального ключа. Выбор делается каждый раз
заново для
каждой ситуации.
Первичные ключи.Итак с потенциальными ключами
определились.
Первичный ключ - это один из потенциальных ключей. Тот, который
нам больше
понравится. Вам какой больше нравиться? В реальной ситуации,
новичок
выберет номер паспорта. А что выберет профессионал? Профессионал
добавит
еще одно поле-счетчик, которое будет содержать уникальное для
каждой
записи значение. В Delphi такой тип поля называется AutoIncrement,
в SQL
Server есть целых 2 варианта - TimeStamp и свойтсво Identity поля.м
Альтернативные ключи.Первичный ключ может быть только
один на
всю таблицу! После выбора первичного ключа из набора потенциальных
ключей,
оставшиеся ключи называются альтенативными.
Внешние ключи.
Когда мы
создаем
какую-нибудь базу данных, например для начисления зарплаты, нам не
удобно
всех работников упоминать в одной таблице. Если, например,
какой-нибудь из
них упоминается там не один раз (зарплата, премия, надбавки,
снятия,
налоги и пр.), то при изменении его/ее фамилии надо будет
пробежаться по
всем строкам, и поменять все вхождения.
Когда мы
создаем
какую-нибудь базу данных, например для начисления зарплаты, нам не
удобно
всех работников упоминать в одной таблице. Если, например,
какой-нибудь из
них упоминается там не один раз (зарплата, премия, надбавки,
снятия,
налоги и пр.), то при изменении его/ее фамилии надо будет
пробежаться по
всем строкам, и поменять все вхождения. Это неудобно. Есть и
другие поводы
разделить такую таблицу, о них читайте в следующем уроке, а пока
просто
примем как факт необходимость ее разделения. Так вот, имеем две
таблицы:
|
Код работника |
Вид движения |
Сумма |
|
1 |
Оклад |
100 |
|
1 |
Премия |
30 |
|
1 |
Налоги |
-25 |
|
2 |
Оклад |
90 |
| ... |
... |
... | |
|
Код работника |
Фимилия |
Имя |
Отчество |
|
1 |
Иванов |
Иван |
Иванович |
|
2 |
Петров |
Петр |
Иванович |
|
3 |
Сидорова |
Мария |
Ивановна | |
В первой таблице - с деньгами - столбец "Код работника" называется
внешним ключом. Ясно, что он не может существовать без
соответствующей строки из второй таблицы, в которой столбец "Код
работника" - уже знакомый нам обычный первичный ключ. Вторая
таблица - с
фамилиями - является как бы "справочником фамилий" для первой.
Хотя
чистая реляционная теория требует, чтобы внешние ключи всегда
ссылались на
первичные ключи, мы это требование низведем до простой
рекомендации:
бывают ситуации, когда одна и та же таблица может служить
справочником
разным другим, причем в разном качестве. А первичный ключ, как мы
знаем,
пожет быть только один.
|