Реляционная форма, очевидно, удобнее с точки зрения автоматизированной обработки информации. Пусть Сидоров О.О. так же, как и Петров С.Н. увлекся игрой в снежки. Зафиксировать эти данные в реляционной таблице очень легко: достаточно просто добавить новую строку с полями «Сидоров О.О.», «Игра в снежки». Такое действие достаточно легко программируется – его программная реализация гораздо проще, чем переразбиение строк на подстроки. Другой пример. Если окажется, что Петров С.Н. разочаровался в компьютерах, нужно будет убрать из БД сведения о том, что Петров С.Н. увлекается компьютерами. СУБД для этого должна будет выполнить элементарную операцию: удалить из таблицы строку с полями «Петров», «Компьютеры». Таким образом, все базовые операции АИС по обработке информации при использовании реляционных СУБД фактически сводятся к операциям над строками таблиц: их добавлению, удалению, обновлению и поиску.
2.1.2. Базовые и дополнительные требования целостности
В реляционной модели существуют два базовых требования целостности.
1. Требование целостности сущности.
В отношении может существовать простой или составной атрибут, значения которого позволяют однозначно идентифицировать каждый кортеж. Такой атрибут называется потенциальным ключом отношения. В том случае, если потенциальный ключ является составным атрибутом, имеет место требование компактности: ни одно подмножество атрибутов в потенциальном ключе не образует потенциального ключа.
Отношение может обладать несколькими потенциальными ключами. К примеру, если в БД ведется учет сотрудников некоторого предприятия и регистрируются паспорта и ИНН, то потенциальным ключом является как ИНН, так и номер паспорта.
Для любого потенциального ключа существует требование уникальности: его значения должны быть различными для различных кортежей в каждый момент времени.
Из всего множества потенциальных ключей разработчик при создании таблицы выбирает один первичный ключ, на который накладывается дополнительное требование целостности: он не должен содержать пустых значений. Потенциальные ключи, которые не выбраны в качестве первичного ключа, называются альтернативными ключами.
Перечисленные требования – уникальность ключевых атрибутов, плюс определенность первичного ключа – в совокупности составляют требование целостности сущности. В классическом варианте реляционной модели предполагалось, что каждое отношение должно обладать первичным ключом. Дубликаты кортежей запрещались, поэтому первичный ключ можно было найти всегда, даже если его образовывали все атрибуты отношения вместе. В современных СУБД дублирование кортежей допускается, поэтому разработчик базы данных имеет право самостоятельно решать, будет ли та или иная таблица иметь первичный ключ.
2. Требование ссылочной целостности.
Реляционная БД всегда состоит из множества таблиц, взаимосвязанных между собой по внешнему ключу.
Внешний ключ – это простой или составной атрибут, который соответствует потенциальному (чаще – первичному) ключу другого отношения.
На рис. 2.3 показан пример связи между таблицами СПЕЦИАЛЬНОСТИ и ГРУППЫ. Первичные ключи таблиц – идентификаторы специальности и группы соответственно. Связь осуществляется с помощью внешнего ключа отношения ГРУППЫ, в качестве которого выступает номер специальности: группа УПП-501 относится к специальности УПП, КИБ-508 и КИБ-409 – к специальности КИБ, БТС-509 – к специальности БТС.
Рисунок 2.3 – Связь таблиц по внешнему ключу
В приведенном примере связь между таблицами СПЕЦИАЛЬНОСТИ и ГРУППЫ отражает связь между соответствующими сущностями предметной области. Тип этой связи – многие-к-одному.
При связывании таблиц возможна рефлексивность, когда внешний ключ соответствует первичному ключу той же самой таблицы.
Отношение, на которое ведет ссылка по внешнему ключу, называется независимым отношением, а отношение, в котором определен внешний ключ, - зависимым. В приведенном примере независимым является отношение ГРУППЫ, а зависимым – СПЕЦИАЛЬНОСТИ.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.