|
требуется ссылок по внешнему ключу на кортежи этого же отношения). Рассмотрим ряд примеров. Пример 9. Ограничение целостности сущности, задаваемое потенциальным ключом отношения, является ограничением отношения, т.к. для его проверки необходимо иметь информацию обо всех кортежах отношения (более точно, обо всех занятых в данный момент значениях потенциального ключа). Пример 10. Ограничение целостности, определяемые наличием функциональных, многозначных зависимостей и зависимостей соединения, являются ограничениями отношения. Пример 11. Предположим, что в отношении PERSON (см. пример 1) задано следующее ограничение в каждом отделе должно быть не менее двух сотрудников. Это ограничение можно сформулировать так количество строк с одинаковым значением Dept_Id должно быть не меньше 2. Замечание. Для того чтобы ввести в действие (объявить) это ограничение, необходимо, чтобы в отношение уже были вставлены некоторые кортежи. Пример 12. Ограничение целостности, определяемое требованием, что некоторая таблица должна быть не пуста, являются ограничениями отношения. Проверка ограничения. К моменту проверки ограничения отношения должны быть проверены ограничения целостности кортежей этого отношения. Ограничение отношения может быть как немедленно проверяемым ограничением, так и ограничением с отложенной проверкой. Ограничение отношения, являющееся ограничением потенциального ключа (пример 9) является немедленно проверяемым ограничением. Ограничение, определенное наличием функциональной зависимости атрибутов также является немедленно проверяемым ограничением. Ограничения же, определенные многозначной зависимостью или зависимостью соединения |
При изменении логики расчета надобность в некоторых атрибутах может исчезнуть, зато может появиться потребность в новых атрибутах. Это потребует перестройки структуры отношения, что является весьма болезненной операцией для работающей системы. Структура отношения становится более сложной и запутанной. Увеличивается объем базы данных. Увеличивается трафик сети. Как видим, оба решения имеют свои достоинства и недостатки. Важно то, что программный код, содержащий эти формулы, не исчезает ни в каком из этих решений (да и куда он денется, раз такова предметная область!). Только в одном случае код хранится в одном месте, а в другом может быть "размазан" по всему приложению. На самом деле данный пример сильно упрощен, т.к. еще одной неприятной особенностью наших бухгалтерий является то, что все расчеты должны вестись с определенной точностью, а именно до копеек. Возникает проблема округления, а это еще более усложняет формулы для расчетов цен. Простой пример вычисление НДС содержит операцию деления, следовательно может приводить к бесконечным дробям типа 15,519999… Такую дробь необходимо округлить до 15.52. Если продается одна единица товара, то это не страшно, но если продается несколько единиц товара, то сумму НДС на все количество можно считать по разным формулам: 1. S4 = N* ROUND(P2*NDS/100) СНАЧАЛА округлить при вычислении НДС на единицу товара, а ПОТОМ умножить на все количество, или 2. S4 = ROUND(N*P2*NDS/100) СНАЧАЛА умножить на все количество, а ПОТОМ округлить до требуемого знака. Лирическое отступление. Автор, как математик по образованию (к.ф.-м.н.), считает, что верной, безусловно, является первая формула. Действительно, вычисляя по первой формуле, мы получим одну и ту же сумму НДС независимо от того, продали мы одну партию товара, содержащую 50 единиц, или продали 50 партий по одной единице в каждой. При вычислениях по второй формуле сумма НДС в партии, состоящий из 50 единиц товара отличается от суммы НДС по 50 партиям по одной единице товара в каждой. Разработав несколько складских программ, автор получал разные ответы на этот вопрос в разных бухгалтерия, разные ответы на этот вопрос в одной бухгалтерии в разное время, и разные ответы на этот вопрос в разных налоговых инспекциях. В конечном итоге, автор пришел к грустному выводу, что для того, чтобы стать бухгалтером, его способностей и образования недостаточно. Другие решения. Можно попытаться использовать и другие решения, для облегчения разработки и сопровождения в данном случае. Например, можно хранить в базовом отношении только базовые атрибуты, а для работы бухгалтерии использовать заранее подготовленные представления (динамические отношения, задаваемые оператором SQL). Тогда логика расчетов будет храниться в одном SQL-операторе, определяющем это представление. Другим вариантом может быть сохранение формул в виде хранимых процедур и функций базы данных. Проверка ограничения. К моменту проверки ограничения кортежа должны быть проверены ограничения целостности атрибутов, входящих в этот кортеж. Ограничение кортежа является немедленно проверяемым ограничением. Действительно, ограничение кортежа не зависит ни от каких других объектов базы данных, кроме атрибутов, входящих в состав кортежа. Поэтому никакие изменения в других объектах не могут повлиять на истинность ограничения. Ограничения отношения Определение 11. Ограничения целостности отношения представляют ограничения, накладываемые только на допустимые значения отдельного отношения, и не являющиеся ограничением целостности кортежа. Требование, что ограничение относится к отдельному отношению, означает, что для его проверки не требуется информации о других отношениях (в том числе не требуется ссылок по внешнему ключу на кортежи этого же отношения). Пример 9. Ограничение целостности сущности (см. гл. 3), задаваемое потенциальным ключом отношения, является ограничением отношения, т.к. для его проверки необходимо иметь информацию обо всех кортежах отношения (более точно, обо всех занятых в данный момент значениях потенциального ключа). Пример 10. Ограничение целостности, определяемые наличием функциональных, многозначных зависимостей и зависимостей соединения, являются ограничениями отношения. Пример 11. Предположим, что в отношении PERSON (см. пример 1) задано следующее ограничение в каждом отделе должно быть не менее двух сотрудников. Это ограничение можно сформулировать так количество строк с одинаковым значением Dept_Id должно быть не меньше 2. Замечание. Для того чтобы ввести в действие (объявить) это ограничение, необходимо, чтобы в отношение уже были вставлены некоторые кортежи. Пример 12. Ограничение целостности, определяемое требованием, что некоторая таблица должна быть не пуста, являются ограничениями отношения. Проверка ограничения. К моменту проверки ограничения отношения должны быть проверены ограничения целостности кортежей этого отношения. Ограничение отношения может быть как немедленно проверяемым ограничением, так и ограничением с отложенной проверкой. Ограничение отношения, являющееся ограничением потенциального ключа (пример 9) является немедленно проверяемым ограничением. Ограничение, определенное наличием функциональной зависимости атрибутов также является немедленно проверяемым ограничением. Ограничения же, определенные многозначной зависимостью или зависимостью соединения являются ограничениями с отложенной проверкой. Действительно, эти ограничения требуют, чтобы кортежи вставлялись и удалялись целыми группами (см. гл. 7). Это невозможно сделать, если выполнять проверку после каждой одиночной вставки или удаления кортежа. Ограничение в примере 11 кажется немедленно проверяемым. Действительно, можно сразу после вставки или удаления кортежа проверить, выполняется ли ограничение, и, если оно не выполняется, то откатить операцию. Но, однако, в этом случае, невозможно вставить ни один новый кортеж для нового отдела. В новый отдел необходимо вставить сразу не менее двух сотрудников. Таким образом, это ограничение с отложенной проверкой. Ограничение из примера 12 имеет смысл проверять только при удалении кортежей из отношения. Это ограничение может быть как немедленно проверяемым, так и отложенным. Ограничения базы данных Определение 12. Ограничения целостности базы данных представляют ограничения, накладываемые на значения двух или более связанных между собой отношений (в том числе отношение может быть связано само с собой). Пример 13. Ограничение целостности ссылок (см. гл. 3), задаваемое внешним ключом отношения, является ограничением базы данных. Пример 14. Ограничение на таблицы DEPART и PERSON из примера 1 является отношением базы данных, т.к. оно связывает данные, размещенные в различных таблицах. Проверка ограничения. К моменту проверки ограничения базы данных должны быть проверены ограничения целостности отношений. Ограничение базы данных может быть как немедленно проверяемым ограничением, так и ограничением с отложенной проверкой. Ограничение отношения, являющееся ограничением внешнего ключа может быть как немедленно проверяемым ограничением, так и отложенным ограничением. Действительно, в простейшем случае, если кортеж отношения должен ссылаться на кортеж отношения , то проверку ограничения ссылочной целостности можно производить сразу после любой из операций вставки, обновления или удаления в любом из отношений или . В более сложном случае, предположим, что кортеж отношения должен ссылаться на кортеж отношения , а кортеж отношения должен в свою очередь ссылаться на кортеж отношения (циклическая ссылка). Очевидно, что сразу после вставки кортежа отношение ссылочная целостность обязательно нарушена, т.к. кортежа еще нет в отношении . Проверку ссылочной целостности можно провести только посл завершения транзакции, состоящей из последовательности операций: 1. вставки кортежа в отношение с нулевой ссылкой на отношение , 2. вставки кортежа отношение со ссылкой на кортеж отношения , 3. исправления ссылки в кортеже с NULL на ссылку на кортеж . Ограничение, приведенное в примере 1, может быть только ограничением с отложенной проверкой. Реализация декларативных ограничений целостности средствами SQL Общие принципы реализации ограничений средствами SQL Стандарт SQL не предусматривает процедурных ограничений целостности, реализуемых при помощи триггеров и хранимых процедур. В стандарте SQL 92 отсутствует понятие "триггер", хотя триггеры имеются во всех промышленных СУБД SQL-типа. Таким образом, реализация ограничений средствами конкретной СУБД обладает большей гибкостью, нежели с использованием исключительно стандартных средств SQL. Стандарт SQL позволяет задавать декларативные ограничения следующими способами: Как ограничения домена. Как ограничения, входящие в определение таблицы. Как ограничения, хранящиеся в базе данных в виде независимых утверждений (assertion). Допускаются как немедленно проверяемые, так и ограничения с отложенной проверкой. Режим проверки отложенных ограничений можно в любой момент изменить так, чтобы ограничение проверялось: |