Правила, которые определяют задания, выполняемые с использованием баз bix, являются ограничениями рабочие ссов, а не ограничениями базы данных. Рабочие адессы оказывают огромное влияние на структуру модели ых, но не могут быть ее частью (см, главу 8)

Не всегда ясно, является ли данное бизнес-правило ограничением

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

С другой стороны, если в предметной области часто меняются правила игры. и это приводит к частым изменениям бизнес-пра- вероятно, удобнее систему, в которой правила являют-

ся частью схемы базы данных. Тогда изменение отдельного элемента повлечет за собой изменения (но не крах) во всех связанных с этим элементом системах.

Целостность на уровне транзакций

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

Транзакции тесно связаны с рабочими процессами. Фактически,

эта концепция предполагает, что данный рабочий процесс может

включать в себя одну или несколько транзакций, и наоборот. Не со-

все но удобно представлять себе рабочий процесс как некую

абстракциго ( добавить заказ ), а транзакцию - как физическое действие ( обновить таблицу OrderDetails}.

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

ЧАСТЬ 1 Теории баз

Классический пример транзакции - перевод денег с одного банковского счета на Если система снимет деньги со счета А, но не сможет зачислить их на счет В, деньги будут потеряны. Очевидно, зачислить деньги не удалось, то и снятие денег со счета нужно отменить. На языке баз данных это называется откатом (rolling hack).

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

Как механизм баз данных Microsoft Jet, так и SQL Server обеспечивают средства для поддержания целостности транзакций путем использования команд BEGIN TRANSACTION, COMMIT TRANSACTION и ROLLBACK TRANSACTION. Как и можно было ожидать, реализация целостности транзакций в SQL Server более 1>аботоспо-собна и лучше обрабатывает ошибки, возникающие из-за сбоев оборудования и программного обеспечения. Впрочем, это уже вопрос реализации, а они не являются предметом нашего рассмотрения. Что действительно важно с точки зрения проектирования - это умение сформулировать и создать цнонные зависимости, наполнив неконкретное выражение логическая единица работы практическим содержанием,

Реализация целостности данных

Вплоть до этого момента мы концентрировали внимание на концептуальном, абстрактном моделировании предметной области. А сейчас рассмотрим несколько вопросов, возникающих при создании физической модели предметной области, конкретно - при создании схем fe.u.! - Переход от одного этапа к другому сопровождается в первую очередь изменением терминологии - отношения становятся таблицами, а атрибуты - полями осы, касающиеся целостности данных, однако, возникаюа каждом из этапов.

Неопределенные и несуществующие величины

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

Проблема отсутствующей информации возникла тогда же, когда была предложена первая ионная модель. Как показать, что какая-то часть информации либо неизвестна (заказчик в действительности имеет фамилию, мы только не знаем, какую), либо отсутствует (у заказчика нет второго имени)? Большинство реляционных баз данных, включая как Microsoft Jet, так и и SQL Server, поддерживают возможность использовать пустое значение - так называемый Null - как способ работы с неопределенными и несуществующими значениями.

Будет, вероятно, преувеличением назвать значение Null решением проблемы, так как с ним связан ряд дополнительных трудностей. Некоторые эксперты в области баз данных полностью отвергают концепцию Null. К. Дж. Дейт заявляет, что Null разрушает и я уже не помню, сколько раз я слышала в адрес слово вредная . Любые замечания о сложности обработки Null1ени и всегда сводятся в конечном итоге к выводу: О Боже! Вам не следует их использовать. Их нужно выкинуть .

В качестве альтернативы те, кто считают, что значения Null вредны, рекомендуют использовать специфические величины, описанные для домена, чтобы показать, что величина не оп-

ределена или не существует (или все вместе). Я называю это подходом договорных значений (conventional value approach).

На мой взгляд, этот подход имеет ряд недостатков. Во-первых, во многих случаях договорное значение условно. Дата 9/9/1900 на самом деле не означает, что значение даты неизвестно, мы просто согласились, что будем интерпретировать эту дату как неопределенное значение.

Я не вижу здесь никаких преимуществ по сравнению с ниями. Разумеется, является значением , но

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

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

Возьмем, например, необязательную связь между заказчиком и

представителями отдела обслуживания клиентов (CSR): каждый CSR, однажды обслужив клиента, должен быть занесен в таблицу CSR. Подход договорн1х значений требует, чтобы запись, которая добавляется в таблицу CSR, соответствовала договорному значению , выбранному, чтобы показать, что CSR не связан ни с одним клиентом (рис. 4-2).