Моделирование ссылочной целостности


В отличие от БД первого и второго поколения, где были иерархические БД, где считывание данных производилось, по сути, по указателям, то есть по физическому месту хранения этих данных, в отличие от них хранение в реляционных БД основано на самих данных, то есть, и связь между таблицами осуществляется на основе тех данных, которые лежат в таблице, а не какими-то другими путями.

Например, в ЖЭКе можно писать список жильцов по фамилиям, Иванов, Сидоров, Петров. И дети Сидоров, Петров и т.д. Соединяться они должны по коду, номеру, например. Потому что Ивановых в России как нерезаных собак на поворотах, то есть море, если просто сказать Ивановых это много, ну и Сидоровых, Петровых, Козловы там, это самые часто используемые фамилии, остальные чуть пореже, поэтому чтобы как-то не спутать детей всех Ивановых, в кучу их не снести, чтобы не было, что Ивановы настрогали, вместе это же пол страны будет, как в Китае все Ли, их там полтора миллиарда, разве много наберешь фамилий на две буквы, они там миллионами на каждую фамилию, сотнями миллионов на каждую фамилию. Поэтому соотношение между какими-то фамилиями и какими-то детьми, принадлежащими данной семье делать в каком-то другом виде, ну, например, по номеру, то есть не указатель какой-то на конкретную запись, а вот циферка 1 – Ивановы, 1.1 – Катя с Петей Ивановы. 2 – это фамилия Сидоровы, значит на двоечку второй, третий, четвертый, сколько там они могли настрогать за свою жизнь, все дети Сидоровых.

Это самый известный, официально описанный в литературе способ получения детей. Ну папа Карло строгал. Другого прямого способа я не видел. Объективно. Вот строгать я читал. Папа Карло он из чурки… Про некоторые способы пишут, а про некоторые просто умалчивают.

Итак, рассмотрим, как моделируется ссылочная целостность между главной, родительской (parent) таблицей и подчиненной, дочерней (child). Как это дело делается. При этом еще надо учесть, что некоторые связи бывают факультативные или необязательные (пунктиром проводящиеся). Рассмотрим некоторый пример, так называемую тернарную связь. Когда две условно как бы родительские таблицы есть и одна подчиненная.


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

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

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

restrict – запрещение. Если имеются сведения в подчиненной таблице, то нельзя удалять главную запись.

none, no action – ничего не делать.

SetDefault – установить значение по умолчанию. Либо 0, либо что-то другое, не мешающее работать БД.

SetNull – установка пустого значения.

Две последние опции возможны когда связь факультативная и еще установлено NullAllow – нуль разрешен.

Как установить опции ссылочной целостности.

Правая кнопка по связи. Relationship properties. RI Actions. Установить соответствующие опции на связь.

Чтение опции ссылочной целостности.

Опции должны стоять не только у дочерней, но и у главной таблицы.

ParentDelete ChildDelete
ParentInsert ChildInsert
ParentUpdate ChildUpdate

Когда моделируете связь, вам нужно обосновать и установить соответствующую опцию как на родительском конце, так и на дочернем.

Не должно появляться детей у которых нет родителей. Запрещено добавление подчиненной записи, если нет соответствия ни одной родительской записи. Система должно проверять и запрещать.

На одну связь должно быть установлено 6 опций.
Для того чтобы отобразить установленные опции ссылочной целостности нужно правой клавишей по полю проектирования. Relationship display. Referential integrity включить (галочку).


Комментарии запрещены.




Статистика