Понятия базы данных, отношения, ключи и др

Сергей Катков, http://www.lab.hop.ru/delphi/sql/les2/les2.shtml

Для начала нам следут разобраться с понятиями - весьма модная нынче тема. Я имею ввиду разборки и понятия. ;) Нам следует убедиться, что мы будем правильно понимать друг друга и называть одинаковые вещи одинаковыми именами. Поэтому определимся с терминами. В нашем случае мы будем рассматривать упрощенный набор терминов. Вообще, реляционная теория в чистом виде содержит очень много терминов и понятий. Но в реальных системах управления базами данных (СУБД) никто никогда ее полностью не придерживался. Всегда что-то упрощается, что-то добавляется свое. Так как мы рассматриваем не голую теорию, а реально работающие Delhi, или MS SQL Server, то нас интересует теория, которая относится именно к ним. Для желающих изучить теорию реляционных баз данных в чистом виде могу порекомендовать книжку "Введение в системы баз данных." Автор К. Дж. Дейт

Таблица

Таблица для нас - совокупность строк и столбцов. Почти полная аналогия с таблицами на бумаге. Важные уточнения: Каждый столбец должен иметь имя, уникальное в пределах этой таблицы. А строки, в теории баз данных, могут следовать в любом порядке, и не имеют номеров. Хотя Delphi, FoxPro и другие добавляют к каждой строке номер, но при выборке данных в SQL, вы его, в общем случае, не получите. Поэтому к каждой строке принято добавлять какой-нибудь идентификатор, для того, чтобы потом можно было легко найти ее.

Отношение

В реляционной теории баз данных, разделяют понятия таблицы и отношения. Например, в отношении не оговаривается порядок столбцов, а только их набор. Еще для отношений определены ограничения типа невозможности содержать две совершенно одинаковые строки. Различия мы сформулируем в одной фразе: Отношение - довольно абстрактный вид объекта, а таблица - его конкретное изображение. Поэтому мы, в дальнейшем, для упрощения, будем считать, что это одно и то же. Но важно не забывать, что в чистой теории баз данных - это разные понятия.

Ключи

Что такое ключ? Набор столбцов. Он может состоятьиз одного столбца, или охватывать все столбцы таблицы. Для чего нам нужны ключи? Для идентификации строк таблицы. В чистой реляционной теории баз данных это единственный способ сослаться на строку. Ключи бывают разные - потенциальные, первичные, альтенативные, внешние, индексные, хеш-ключи, ключи сортировки, вторичные ключи, ключи шифрование и расшифровки и т.д. Но мы договаривались, что будем рассматривать только то, что нам понадобится в работе, вот и рассмотрим. Желающим углибить свои знания могу посоветовать прочитать уже упоминавшуюся выше книгу Дейта.

Потенциальные ключи.Потенциальным ключом будем называть такую комбинацию столбцов, которая обладает следующими свойствами: УникальностьюВ таблице нет двух разных строк с одиноковыми значениями в нашем потенциальном ключе. Неизбыточностью.Нельзя убрать один из столбцом из ключа, так, чтобы он не потерял уникльности.

Рассмотрим, например, такую таблицу:

№ паспорта

Фамилия

Имя

Отчество

Должность

Табличка у нас простая и небольшая. Но нам хватит.
В данной таблице в качестве потенциального ключа можно рассматривать любой столбец. Но она у нас будет расширяться, так что будем смотреть в будущее.

Понятно, что отчество не может быть потенциальным ключом - есть совпадения. Фамилия - может, если только мы не планируем появления новых строк в таблице. Можно взять комбинацию фамилии и должности, врядли у нас будет два директора-однофамильца. Номер паспорта также подходит на роль потенциального ключа. Я думаю вы поняли мою мысль - к каждой конкретной таблице потенциальнх ключей может быть много. Выбор потенциального ключа - дело программиста. Тот же номер паспорта может не подойти, если мы ожидаем кого-нибудь с поддельным паспортом ;) Выбор делается каждый раз заново для каждой ситуации.

Первичные ключи.Итак с потенциальными ключами определились. Первичный ключ - это один из потенциальных ключей. Тот, который нам больше понравится. Вам какой больше нравиться? В реальной ситуации, новичок выберет номер паспорта. А что выберет профессионал? Профессионал добавит еще одно поле-счетчик, которое будет содержать уникальное для каждой записи значение. В Delphi такой тип поля называется AutoIncrement, в SQL Server есть целых 2 варианта - TimeStamp и свойтсво Identity поля. Подробнее этот момент мы рассмотрим в уроках по в взаимодействию с SQL Server'ом. Про полезность введения дополнительного поля, так называемого "суррогатного ключа", можно почитать здесь. Мы ведь собрались стать профессионалами? Вот и поучимся у умных людей.
Лиричекое отступление - умный человек, а тем более профессионал никогда не скажет "Я и так все знаю, ничему меня не научишь". Потому что он знает - всегда есть чему учиться.

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

Внешние ключи.Эта тема тесно связана со следующей - "Некоторые правилами построения баз данных" В частности с понятием нормализации Это будет потом, а сейчас только некоторые моменты.
Когда мы создаем какую-нибудь базу данных, например для начисления зарплаты, нам не удобно всех работников упоминать в одной таблице. Если, например, какой-нибудь из них упоминается там не один раз (зарплата, премия, надбавки, снятия, налоги и пр.), то при изменении его/ее фамилии надо будет пробежаться по всем строкам, и поменять все вхождения. Это неудобно. Есть и другие поводы разделить такую таблицу, о них читайте в следующем уроке, а пока просто примем как факт необходимость ее разделения. Так вот, имеем две таблицы:

В первой таблице - с деньгами - столбец "Код работника" называется внешним ключом. Ясно, что он не может существовать без соответствующей строки из второй таблицы, в которой столбец "Код работника" - уже знакомый нам обычный первичный ключ. Вторая таблица - с фамилиями - является как бы "справочником фамилий" для первой.
Хотя чистая реляционная теория требует, чтобы внешние ключи всегда ссылались на первичные ключи, мы это требование низведем до простой рекомендации: бывают ситуации, когда одна и та же таблица может служить справочником разным другим, причем в разном качестве. А первичный ключ, как мы знаем, пожет быть только один.

Ссылочная целостность.В предыдущем параграфе мы обошли вопрос "А что будет, если не найдется работника с кодом, который мы использовали?" Ничего хорошего не будет. Такой ситуации надо всячески избегать.
Ссылочной целостностью, по-английски Refential Integriyr, называется такое состояние, когда у нас все что надо правильно находится. Контроль ссылочной целостности - обеспечение такого состояния.
А если пользователь захочет удалить одно из работников? По ситуации смотреть надо - когда просто запретить такие действия, когда удалить все соответствующие записи из другой таблицы (так называемое "каскадное удаление"). Этот момент очень важен - ни при каких ситуациях нельзя допускать нарушения ссылочной целостности.

База данных.Ну вот, наконец, и добрались. А что же такое база данных? Базой данных мы будем называть совокупность таблиц, индексов, хранимых процедур, триггеров и всего остального, что касается нашего проекта. В Access'е, например, так вообще все это в одном файле хранится.