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

3.5.1 Обязательные данные

Необходимо установить, какие из атрибутов всегда должны содержать одно из допустимых значений. Другими словами, нас интересуют атрибуты, которые всегда должны иметь конкретные значения, отличные от NULL. Например, атрибуты Раб_№ и Полное_Имя (Имя, Фамилия) сущности Работник всегда должны иметь конкретные значения, отличные от пустого. Однако на атрибут Тел_№ этой же сущности данное требование не распространяется, и этот атрибут вполне может иметь значение NULL, означающее, что у работника либо нет телефона, либо номер его неизвестен.

Условие обязательного наличия данных реализовано практически во всех коммерческих СУБД. Это условие целостности требует, чтобы некоторые столбцы не содержали значение NULL. Пользователю предоставляется возможность самостоятельно решить вопрос о том, каким столбцам присваивать значение NULL и каким нет. Это делается при создании таблицы в инструкции CREATE TABLE. Если столбец не может содержать значение NULL, то в этой инструкции на него накладывается ограничение NOT NULL

СУБД обрабатывающая столбец с ограничением NOT NULL проверяет, чтобы ни одна инструкция INSERT или UPDATE не добавляла и не обновляла строку со значением NULL

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

3.5.2 Ограничения для доменов атрибутов

Домен атрибута устанавливает набор допустимых значений, которые могут присваиваться атрибуту. Примеры доменов атрибутов логической модели данных пользователя Менеджер были приведены при выполнении этапа 2.6 и представлены в Таблице 2.6.

3.5.3 Целостность таблицы

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

СУБД автоматически проверяет уникальность первичного ключа и поэтому всякая попытка добавить строку с уже существующим значением первичного ключа или обновить строку таким образом, что первичный ключ потеряет свою уникальность, завершится сообщением об ошибке. Условие уникальности могут накладываться и на другие столбцы таблицы. Так например можно потребовать, чтобы в таблице Работник не было двух служащих с одинаковыми именами и фамилиями. СУБД, обеспечивающая выполнение этого условия, должна проконтролировать атрибут Полное_Имя (Имя, Фамилия) и пресечь всякую попытку, нарушающую условие уникальности.

Особым случаем условия уникальности является значение NULL в столбце первичного ключа или в столбце объявленном уникальным. СУБД не может разобраться является ли NULL дубликатом уже существующего первичного ключа или нет. Правильным может оказаться и то, и другое. По этой причине любой столбец являющийся частью первичного ключа, и любой столбец на который наложено условие уникальности, должен быть объявлен с ограничением NOT NULL.

3.5.4 Ссылочная целостность

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

Существуют четыре типа изменений в базе данных, которые могут привести к нарушению ссылочной целостности отношении предок/потомок. К ним относятся:

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

2. Обновление внешнего ключа в строке-потомке. Эта операция допустима, если новое значение внешнего ключа таблицы-потомка будет равно одному из значений первичного ключа таблицы-предка.

3. Удаление строки-предка. Если из таблицы-предка будет удалена строка у которой есть хотя бы один потомок, то строки-потомки станут сиротами (удаление же строки-потомка не вызывает никаких проблем).

4. Обновление первичного ключа в строке-предке. Если происходит изменение первичного ключа в таблице-предке, то все потомки, ссылающиеся на этот ключ, становятся сиротами.

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

В стандарте SQL задаются соответствующие правила удаления и обновления строк для каждого отношения предок/потомок.

Рассмотрим вначале правило удаления строк. Каковы действия СУБД при попытке пользователя удалить строку из таблицы-предка? Для ответа на этот вопрос необходимо выбрать одно из четырех возможных правил удаления:

1. RESTRICT - запрещает удаление строки из таблицы-предка, если строка имеет потомков. Применительно к нашей базе данных это правило формулируется следующим образом: "нельзя удалить данные об отделе, если за ним закреплен хотя бы один работник".

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

3. SET NULL - устанавливает, что при удалении строки-предка внешним ключам во всех ее строках-потомках присваивается значение NULL. Применительно к нашей базе данных это правило может звучать как "при удалении данных об отделе необходимо указать, что пока неизвестно, в какой отдел переводятся его работники".

4. SET DEFAULT - устанавливает, что при удалении строки-предка, внешним ключам во всех ее строках-потомках присваивается определенное значение, установленное по умолчанию для этого столбца.

Если пользователь не задал ни одного правила удаления, то по умолчанию применяется правило RESTRIСТ. Правило RESTRIСТ оставляет меньше шансов для случайного разрушения или изменения информации в базе данных.

Когда пользователь пытается обновить значение первичного ключа в таблице-предке. то реакция СУБД на эти действия определяется правилами обновления, принятыми в соответствующей базе данных. Здесь как и в случае с правилами удаления используются четыре правила обновления:

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

2. CASCADЕ - определяет, что, при изменении значения первичного ключа в строке-предке, соответствующее значение внешнего ключа в таблице-потомке автоматически изменяется во всех строках-потомках таким образом чтобы соответствовать новому значению первичного ключа.

3. SET NULL - определяет, что, при обновлении значения первичного ключа в строке-предке, внешним ключам во всех ее строках-потомках автоматически присваивается значение NULL. Таким образом, изменение первичного ключа в

таблице-предке вызывает установку значений NULL в некоторых столбцах таблицы-потомка.

4. SET DEFAULT - определяет, что, при обновлении значения первичного ключа в строке-предке, внешним ключам во всех ее строках-потомках по умолчанию присваивается определенное значение, установленное для данного столбца. Таким образом, изменение первичного ключа в таблице-предке вызывает выполнение "установки по умолчанию" в некоторых столбцах таблицы-потомка.

Правила удаления и обновления бывают "одноуровневые", "двухуровневые" и "многоуровневые". Так например правило RESTRIСТ являются "одноуровневым", так как в отношении предок/потомок оно затрагивает только таблицу-предок. Правила SЕТ NULL и SЕТ DEFAULT являются "двухуровневыми" правилами так как их влияние заканчивается на таблице-потомке, а правило САSCADE - "многоуровневым", так как оно затрагивает все таблицы участвующие в отношениях.

Otdel (Otdel_№, Otdel_Imya, Tel_№, Fax_№)

Primary Key Otdel_№

Alternate Key Tel_№

Rabotnik (Rab_№, Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№)

Primary Key Rab_№

Foreign Key Otdel_№ reference Otdel (Otdel_№) on delete SET NULL on update CASCADE

Object (Object_№, Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec_№)

Primary Key Object_№

Foreign Key Otdel_№ reference Otdel (Otdel_№) on delete SET NULL on update CASCADE

Foreign Key Vladelec_№ reference Vladelec (Vladelec_№) on delete RESTRICT on update CASCADE

Vladelec (Vladelec_№, Nazvanie, Adres, Tel_№, Kontakt)

Primary Key Vladelec_№

Klient (Klient_№, Imya, Familiya, Adres, Tel_Kl, Object_Tip, S_Max, Cena_Max)

Primary Key Klient_№

Dogovor (Dogovor_№, Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№)

Primary Key Dogovor_№

Foreign Key Object_№ reference Object (Object_№) on delete RESTRICT on update CASCADE

Foreign Key Rab_№ reference Rabotnik (Rab_№) on delete SET NULL on update CASCADE

Foreign Key Klient_№ reference Klient (Klient_№) on delete RESTRICT on update CASCADE

Objyavlenie (Objyavlenie_№, Data, Cena, Object_№, SMI_№)

Primary Key Objyavlenie_№

Foreign Key Object_№ reference Object (Object_№) on delete RESTRICT on update CASCADE

Foreign Key SMI_№ reference SMI (SMI_№) on delete RESTRICT on update CASCADE

SMI (SMI_Imya, Adres, Tel_№, Kontakt)

Primary Key SMI_№

Alternate Key Tel_№

Osmotr (Data_Os, Kommentarii, Klient_№, Object_№)

Primary Key Klient_№, Object_№, Data_Os

Foreign Key Object_№ reference Object (Object_№) on delete RESTRICT on update CASCADE

Foreign Key Klient_№ reference Klient (Klient_№) on delete CASCADE on update CASCADE

Sobesedovanie (Data_Sob, Kommentarii, Rab_№, Klient_№)

Primary Key Klient_№, Rab_№, Data_Sob

Foreign Key Rab_№ reference Rabotnik (Rab_№) on delete RESTRICT on update CASCADE

Foreign Key Klient_№ reference Klient (Klient_№) on delete CASCADE on update CASCADE

3.5.5 Требования данного предприятия

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

Бизнес-правила для представления Менеджер приложения Реалтэкс

1. Каждый менеджер в любой момент времени должен руководить работой не менее четырех, но и не более восьми рядовых сотрудников.

2. Каждый агент в любой момент времени может вести не менее 5, но не более 15 клиентов.

3. Период между датой заключения договора и датой внесения аванса не может быть больше 10 рабочих дней.

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

5. Цена одного рекламного объявления не должна превышать 2800 руб.

3.5.6 Документирование всех ограничений целостности данных

Все установленные требования поддержки целостности данных для локальной модели данных пользователя Менеджер должны быть детально отображены в документации.

3.6 Обсуждение разработанных локальных логических моделей данных с конечными пользователями