Условия целостности данных. Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворе­чивой, в реляционной модели устанавливаются некоторые ограничительные усло­вия

Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворе­чивой, в реляционной модели устанавливаются некоторые ограничительные усло­вия. Ограничительные условия – это правила, определяющие возможные значе­ния данных. Они обеспечивают логическую основу для поддержания корректных значений данных в базе. Ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных. Важнейшими ограничениями целостности данных являются: О – категорийная целостность; G – ссылочная целостность.

Ограничение категорийной целостности заключается в следующем. Кортежи отно­шения представляют в базе данных элементы определенных объектов реального мира или, в соответствии с терминологией реляционных СУБД, категорий. Например, строка таблицы СТУДЕНТЫ представляет конкретного студента. Первичный ключ таблицы однозначно определяет каждый кортеж и, следовательно, каждый элемент категории. Таким образом, для извлечения данных, содержащихся в строке табли­цы, или для манипулирования этими данными необходимо знать значение ключа для этой строки. Поэтому строка не может быть занесена в базу данных до тех пор, пока не будут определены все атрибуты ее первичного ключа. Это правило называ­ется правилом категорийной целостности и кратко формулируется следующим об­разом: никакой атрибут первичного ключа строки не может быть пустым.

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

Если две таблицы связаны между собой, то внешний ключ таблицы должен содер­жать только те значения, которые уже имеются среди значений ключа, по которо­му осуществляется связь. Если корректность значений внешних ключей не конт­ролируется СУБД, то может нарушиться ссылочная целостность данных. Это можно пояснить на рассматриваемом примере следующим образом. Если удалить из таблицы СТУДЕНТЫ строку (например, при отчислении студента), имеющую хотя бы одну связанную с ней строку в таблице УСПЕВАЕМОСТЬ, то это приве­дет к тому, что в таблице УСПЕВАЕМОСТЬ останутся записи об успеваемости студента, который уже отчислен. Такая же ситуация будет наблюдаться и в том случае, если внешнему ключу таблицы УСПЕВАЕМОСТЬ ошибочно будет при­своено значение, отсутствующее в значениях ключа связанной таблицы.

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

– первый подход заключается в том, что запрещается производить удаление кор­тежа, на который существуют ссылки (то есть сначала нужно либо удалить ссы­лающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа);

– при втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически стано­вится неопределенным;

– третий подход (называемый также каскадным удалением ) состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающего­ся отношения автоматически удаляются все ссылающиеся кортежи.

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

Хотя большинство современных СУБД обеспечивает ссылочную целостность дан­ных, все же следует помнить, что существуют реляционные СУБД, в которых не вы­полняются ограничения ссылочной целостности. Это, как правило, ранние разра­ботки локальных реляционных СУБД – FoxPro версии 2.6 и ниже, версии dBase для DOS.

Типы связей между таблицами

При установлении связи между двумя таблицами одна из них будет являться глав­ной (master), а вторая – подчиненной (detail). Различие между ними несколько уп­рощенно можно пояснить следующим образом. В главной таблице всегда доступны все содержащиеся в ней записи. В подчиненной же таблице доступны только те за­писи, у которых значение атрибутов внешнего ключа совпадает со значением соот­ветствующих атрибутов текущей записи главной таблицы. Причем изменение теку­щей записи главной таблицы приведет к изменению множества доступных записей подчиненной таблицы, а изменение текущей записи в подчиненной таблице не вы-, зовет никаких изменений ни в одной из таблиц.

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

Различают четыре типа связей между таблицами реляционной базы данных:

– один к одному – каждой записи одной таблицы соответствует только одна за­пись другой таблицы;

– один ко многим – одной записи главной таблицы могут соответствовать несколь­ко записей подчиненной таблицы;

– многие к одному – нескольким записям главной таблицы может соответство­вать одна и та же запись подчиненной таблицы;

– многие ко многим – одна запись главной таблицы связана с несколь­кими запи­сями подчиненной таблицы, а одна запись подчиненной таблицы связана с не­сколькими записями главной таблицы.

Различие между типами связей «один ко многим» и «многие к одному» зависит от того, какая из таблиц выбирается в качестве главной, а какая – в качестве подчиненной. Например, если из связанных таблиц СТУДЕНТЫ и УСПЕВАЕМОСТЬ в качестве глав­ной выбрать таблицу СТУДЕНТЫ, то получим тип связи «один ко многим». Если же выбрать в качестве главной таблицу УСПЕВАЕМОСТЬ, получится тип связи «многие к одному».

Не нашли, что искали? Воспользуйтесь поиском: