Модификация данных и целостность базы

Модификация данных и целостность базы

3.3.1. Внесение изменений и целостность базы

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

В литературе [4] отмечена разница между терминами отношение и связь (класс эквивалентных отношений). Ниже эти термины будут считаться синонимами, так как до рассмотрения инфологического этапа проектирования моделей баз данных [31] это различие несущественно. Так же несущественно для дальнейшего изложения различие между доменом и атрибутом (домен вместе с именем); они также будут считаться синонимами.

Для пользователей реляционных СУБД отношения обычно представляются в виде таблиц; столбцы таблиц - это домены, а строки - кортежи. Таковы все таблицы, приведенные в качестве примеров предметной области.

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

Напомним, что множество нормализованных отношений составляет замкнутую систему относительно следующих операций [30]: объединение, пересечение, вычитание, произведение, проекция, ограничение, деление и соединение, которые имеют свои аналоги в языке манипулирования данными (например, в SQL).

Эти операции уже описаны в литературе и в [30], однако для удобства и однозначности использования в данном пособии еще раз приведем некоторые операции и покажем их применение в SQL на насколько модифицированном примере нормализованной реляционной модели из [6].

Теоретико-множественные операции над отношениями практически совпадают с обычными теоретико-множественными операциями. Различие состоит в том что, теоретико-множественные операции над отношениями производятся подоменно, и отношения-операнды должны быть определены на одинаковых доменах. Например, операция объединения (результат операции представлен на рис. 72, где также приведено предложение SQL, реализующее данную операцию) выполнена на таблицах, показанных на рис. 70 и 71 соответственно.

Фирма	Филиал	Страна	Наименование_детали
S2	D1	T2	A1
S3	D1	T2	A2
S1	D1	T1	A1
S4	D1	T2	A3
S1	D2	T1	B1

Рис. 70. Отношение R15 - ИЗГОТОВИТЕЛЬ

Фирма	Филиал	Страна	Наименование_детали
S1	D2	T1	B1
S1	D2	T4	B1

Рис. 71. Отношение R16 - ИЗГОТОВИТЕЛЬ1

Фирма Филиал Страна Наименование_детали S2 D1 T2 A1 S3 D1 T2 A2 S1 D1 T1 A1 S4 D1 T2 A3 S1 D2 T1 B1 S1 D2 T4 B1

SELECT *   FROM R15   UNION   SELECT *   FROM R16;

Рис. 72. Отношение R17 = ИЗГОТОВИТЕЛЬ ∪ ИЗГОТОВИТЕЛЬ1

Отношение, приведенное на рис. 70, описывает ситуацию открытого (зарегистрированного) производства деталей, т.е., например, когда фирма офоциально декларирует, что выпцскаемые ею детали производятся на ее филиалах в определенных странах. Отношение же на рис. 71, описывает ситуацию закрытого (спрятанного) производства деталей, когда фирма по каким-то причинам скрывает, например, от потребителя, что у нее есть дополнительные филиалы, на которых она производит детали.

В принципе любая фирма, может иметь несколько филиалов с одинаковым названием в разных странах, и у разных фирм имена филиалов могут совпадать. Заметим, что последнее предположение вполне реально, т.к. фирма может называть свой филиал как ей нравится. Однако название фирмы (хотя бы в примере) должно позволять отличать одну фирму от другой. Для удобства длинные имена отношений заменим идентификаторами, например ИЗГОТОВИТЕЛЬ будем обозначать R15; ИЗГОТОВИТЕЛЬ1 - R16 и т.д.

Результаты операций пересечения, разности и декартова (прямого) произведения представлены на рис. 73, 74 и 75 соответственно.

Фирма Филиал Страна Наименование_детали S1 D2 T1 B1

SELECT *   FROM R15   WHERE Фирма IN   (SELECT *   FROM R16);

Рис. 73. Отношение R18 = ИЗГОТОВИТЕЛЬ ∩ ИЗГОТОВИТЕЛЬ1

Фирма Филиал Страна Наименование_детали S2 D1 T2 A1 S3 D1 T2 A2 S1 D1 T1 A1 S4 D1 T2 A3

SELECT *   FROM R15   WHERE Фирма NOT IN   (SELECT *   FROM R16);

Рис. 74. Отношение R19 = ИЗГОТОВИТЕЛЬ \ ИЗГОТОВИТЕЛЬ1

Операция прямого (декартова) произведения двух отношений состоит в приписывании всех строк второго операнда ко всем строкам первого операнда или, как говорят, конкатенации строк. Например, отношение R22, показанное на рис. 75, является декартовым произведением отношений R21 и R20 этого же рисунка.

Наименование_детали A1 A2 A3 B1

Филиал D1 D2

R22 = R20 x R21

Наименование_детали Филиал A1 D1 A2 D1 A3 D1 B1 D1 A1 D2 A2 D2 A3 D2 B1 D2

Отношение R20

Отношение R21

Отношение R22

Рис. 75. R22 = R20 x R21

Операция прямого произведения на языке SQL может быть реализована, например с помощью предложения

SELECT R20.*, R21.* FROM R20, R21;

Унарная операция проекции отношений на один домен или на несколько доменов состоит в выделении этих доменов в отдельную таблицу и вычеркивании повторяющихся строк. Так, проекция отношения R15 на домен "Название детали" даст отношение из таблицы R20 (рис. 75). На языке SQL подобный результат может быть получен с помощью предложения:

SELECT DISTINCT Наименование_детали FROM R15;

Бинарная операция соединения определена для двух отношений, на выделенных доменах которых можно задать двухместный предикат λ:

λ = {=, <, >, <=, >=, < > (не равно)}.

Для λ-соединения сначала выполняется операция прямого произведения, а затем в результирующем отношении остаются те строки, в которых значение предиката λ для выделенных доменов истинно. Например, λ-соединение по предикату равенства отношений R15 (рис.70) и R23 (рис. 76), даст отношение ПОСТАВКА - R24, показанное на рис. 77.

Потребитель	Страна	Наименование_детали
P1	T2	A1
P2	T2	B1
P3	T1	A2
P1	T2	A3

Рис. 76. Отношение R23 - ПОТРЕБИТЕЛЬ

Здесь следует отметить, что таблицы, представленные на рис. 70, 71, 76, и составляют собственно хранимую базу данных. Они должны быть явно специфицированы с помощью команды CREATE TABLE [30], в которой обязательно должны быть указаны атрибуты, являющиеся первичными (primary) ключами таблицы.

Таблицы, приведенные на рис. 72, 73, 74, 75, относятся к категории виртуальных [30] и физически могут не храниться в базе данных.

Соединения по предикату равенства имеют особое значение в алгебре Е.Ф. Кодда и называются эквисоединениями. Пример эквисоединения отношений R15 и R24 по атрибуту (домену) Наименование_детали приведен на рис. 77.

Изготовитель Филиал Страна Наименование_детали Страна Потребитель S2 D1 T2 A1 T2 P1 S3 D1 T2 A2 T1 P3 S1 D1 T1 A1 T2 P1 S4 D1 T2 A3 T2 P1 S1 D2 T1 B1 T2 P2

SELECT *   FROM R15, R23   WHERE   R15.Наименование_детали =   R23.Наименование_детали;

Рис. 77. Отношение R24 - ПОСТАВКА = R15 [Наименование_детали=Наименование_детали] R23.

Кодд [12] установил, что эквисоединение семантически верных отношений может дать семантически ложное отношение (названное им ловушкой соединения); при этом пользователь не в состоянии выявить момент появления в базе данных ложной информации.

Примером ловушки соединения является отношение R26 (рис. 79) - эквисоединение отношений, представленных на рис. 70 и 78. В самом деле, поставка деталей может быть специализированной, и из того, что фирма S1 изготавливает изделие А1 (рис. 70), а предприятие Р1 потребляет это изделие, не следует, что данному предприятию его поставляет именно фирма S1, т.е., что S1 и Р1 связаны между собой отношением поставки.

Потребитель	Страна	Наименование_детали
P1	T2	A1
P2	T2	B1
P3	T1	A2
P1	T2	A3
P2	T2	A1

Рис. 78. Отношение R25 - ПОТРЕБИТЕЛЬ1

Примечание. Отношение R25 получено из отношения R23 (рис. 76) с помощью следующего оператора языка SQL [30]

INSERT INTO R23 VALUSE('P2', 'T2', 'A1');

Например, в предметной области должно существовать отношение R24 (рис. 77), а не отношение R26 = R15 [Название_детали=Название_детали] R25, изображенное на рис. 79. Результат эквисоединения семантически ошибочен.

Изготовитель Филиал Страна Наименование_детали Страна Потребитель S2 D1 T2 A1 T2 P1 S3 D1 T2 A2 T1 P3 S1 D1 T1 A1 T2 P1 S4 D1 T2 A3 T2 P1 S1 D2 T1 B1 T2 P2 S2 D1 T2 A1 T2 P2 S1 D1 T1 A1 T2 P2

SELECT *   FROM R15, R25   WHERE   R15.Наименование_детали =   R25.Наименование_детали;

Рис. 79. Ловушка соединения отношение R26 - ПОСТАВКА1 = R15 [Наименование_детали=Наименование_детали] R25.

Можно показать, что ловушка соединения может произойти при любом предикате λ. Возможность получения ложной информации в результате истинной операции над истинными отношениями это свойство ловушки λ-соединения.

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

Однако Е. Ф. Коддом и его последователями были найдены средства преодоления ловушки λ-соединения. Такими средствами стало поддержание структуры функциональных зависимостей (ФЗ), многозначных (MЗ), а затем и других зависимостей в отношениях реляционной модели, а также нормализованная форма представления и хранения отношений.

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

Например, если требуется ввести в отношение СПИСОК_ПОЛЕТОВ (рис. 4) Пилота, для которого к моменту введения его в базу данных не определена его работа, то без неопределенных элементов обойтись нельзя:

< Николаев, ---, ---, --- >.

Введение неопределенных элементов ведет к теоретическим сложностям: затрудняется интерпретация запросов к базе данных, так как фактически приходится иметь дело с несколькими разновидностями неопределенностей. Если же перейти к более высокой нормальной форме отношений (например, 3НФ), то трудности вроде бы снимаются. Однако при этом необходимо тщательно следить за ограничениями целостности, связывающими отношения.

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

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

SELECT №_зачетки, Семестр, Предмет, Оценка, Шифр_Преподавателя FROM R3, R13 WHERE R3.Предмет = R13.Предмет;

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