Понятие сущности, связи и целостности базы данных

Связь вида 1:М в реляционных СУБД используется наиболее часто, поэтому ее мы рассмотрим наиболее подробно.

Пусть мы имеем две таблицы следующего вида:

1. Клиент (Номер_клиента, ФИО_клиента, Счет_клиента)

2. Продажи (Номер_клиента, Наименование_товара, Количество_товара)

Таблицы связанны отношением 1:М, т.е. один клиент может совершить много покупок, каждая покупка совершается только одним клиентом. В таблицах хранятся следующие данные:

 

Клиент

Номер_клиента	ФИО_клиента	Счет_клиента
	Сидоров И.И.
	Петров А.Б.
	Федоров Н.Г.

 

Продажи

Номер_клиента	Наименование_товара	Количество_товара
	Шоколад «Корона»
	Шейки Куринные	1,5
	Крупа манная

 

Очевидно, что поле «Номер_клиента» в обеих таблицах имеет одинаковый смысл - оно обозначает номер, присвоенный клиенту. В случае если таблицы не имеют связи друг с другом, ничего не мешает нам добавить в таблицу «Продажи» строку, например, (8, «Хлеб белый»,1), несмотря на то, что в таблице «Клиент» нет покупателя с номеров 8. Это нарушение целостности данных, так как такая строка может быть занесена, но она не соответствует действительности. Чтобы подобная ситуация стала невозможной, необходимо установить связь между таблицами по полю «Номер_клиента». В этом случае сервер БД автоматически проследит, чтобы поле «Номер_клиента» из вставляемой строки существовало в таблице «Клиенты».

Подобной проверки достаточно, чтобы условие целостности данных выполнялось при добавлении данных в таблицы. Но его недостаточно при манипулировании данными. Рассмотрим ситуацию, когда мы удаляем из таблицы «Клиент» некоторую запись, например клиента с номером 1. В случае если таблицы не связанны, удаление клиента повлечет за собой изменение только одной таблицы. В таблице «Продажи» останутся сведения о покупках покупателя с номером 1. Такая ситуация - также нарушение целостности данных, так как о данном покупателе, после его удаления, базе данных ничего не известно. В случае если таблицы связанны, удаление покупателя может повлечь за собой удаление всех его покупок (говорят, что удаление каскадируется).

Такая же ситуация с модификацией данных в родительской таблице. Если покупатель с номером 1 изменил номер на 5, то в связанных таблицах изменение родительской таблицы повлечет за собой автоматическое изменение дочерних таблиц.

Кроме арности связи и ограничений целостности различают также идентифицирующие и не идентифицирующие связи. С помощью идентифицирующей связи устанавливается взаимосвязь между зависимыми сущностями (клиент и его покупки). Не идентифицирующая связь устанавливает взаимосвязь между независимыми сущностями (автомобиль и его цвет). Разница между идентифицирующей и не идентифицирующей связью состоит в том, что при идентифицирующей связи внешний ключ является частью первичного ключа дочерней сущности, а при не идентифицирующей связи внешний ключ не входит в первичный ключ дочерней сущности. Идентифицирующая связь изображается непрерывной линией, не идентифицирующая - пунктирной.

Последнее, о чем осталось упомянуть - это о допустимости NULL значений во внешнем ключе. Например, если сущности "Работник" и "Загранпаспорт" связаны не идентифицирующей связью 1:М таким образом:

 

Работник

(Номер_Работника, ФИО_работника, Номер_загранпаспорта(FK))

 

Загранпаспорт

(Номер_загранпаспорта, Дата_выдачи, Срок_действия)

 

Т.е. каждый работник может иметь ноль, один или несколько загранпаспортов.

Поле "Номер_загранпаспорта" в таблице "Работники" является внешним ключом из таблицы "Загранпаспорт". Не у каждого работника есть загранпаспорт. Если его нет, в поле "Номер_загранпаспорта" подставляется NULL. Это пример не идентифицирующей связи, допускающей значение NULL.

Примером связи, не допускающей неопределенные значения, является связь между родителем и ребенком. Не бывает ребенка без родителя. В таблице "Ребенок" поле "Номер_родителя" должно быть определено обязательно.

Допустимость NULL-значений связи на диаграмме указывается ромбиком.

Связь таблиц в реляционной БД устанавливается при создании таблиц с помощью описателя FOREIGEN KEY.

Приведем также пояснения к стандартной нотации ER-диаграмм, в которой представлены варианты к лабораторной работе.

 

Сущности

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

- PK - первичный ключ

- AK - альтернативный ключ

- FK - внешний ключ

- IE - inversion entry, говорит о том, что по данному полю должен быть создан индекс.

Связи

Связь между двумя отношениями изображается с помощью линии. Идентифицирующая связь изображается сплошной линией, не идентифицирующая - пунктирной. Арность связи указывается следующим образом: со стороны "многие" ставится жирная точка, со стороны "один" точка не ставится. Допустимость Null -значений изображается ромбиком с той стороны связи, где позволяются Null -значения.

Категории

В случае, если у нас есть некоторая общая сущность (например – люди), и необходимо хранить информацию о некоторых разновидностях данной сущности (например – родители и дети, мужчины и женщины, работающие и безработные и т.д.) имеет место понятие категории. Поясним на примере. Допустим, нам необходимо хранить следующую информацию о родителях и детях:

Родитель(Номер, ФИО, Адрес, Образование)

Ребенок(Номер, ФИО, Адрес, Номер_детского_садика)

ЯвляетсяРебенком(Номер_родителя, Номер_ребенка)

Схема данных:

Родитель ------- 1:М -------> Ребенок

Очевидно, что для ребенка поле «Образование» не имеет смысла, как и поле «Номер_детского_садика» для родителя. Кроме того, в случае, если подобную информацию хранить в виде двух таблиц, то возникает дублирование информации и проблемы с целостностью данных. Например, адрес ребенка совпадает с адресом родителей, и если данные вводятся вручную, то можно ввести адрес ребенка отличный от адреса родителя.

Подобная проблема решается следующим образом: вводится обобщающая категория «Личность», в нее выносятся общие поля из двух дочерних таблиц. Дочерние таблицы привязываются к родительской связью один к одному. Пример:

Личность (Номер, ФИО);

Родитель (Номер, Адрес, Образование);

Ребенок (Номер, Номер_детского_садика);

ЯвляетсяРебенком(Номер_родителя, Номер_ребенка)

 

Схема:

Родитель --------1:1--------> Личность<--------1:1-------- Ребенок

 

Для того, чтобы добавить данные о ребенке, нужно занести данные в две таблицы – «личность» и «ребенок». Например:

ISERT INTO Личность VALUES (2,‘Иванов И.И.’)

ISERT INTO Ребенок VALUES (2,‘д/с №23’)

 

Нумерация в таблицах сквозная! На схеме категориальная связь изображается так, как показано на рисунке 5.1.

 

 

Рисунок 5.1 – Категориальная связь между сущностями базы данных