Puc. 4-2, Договорные значения требуют дополнительн1х пуст1х записей для поддержания сс1лочной целостности

Теперь подсчитаем, сколько представителей службы клиентского сервиса (CSRs) работает компании. На одного меньше, чем содержится в таблице CSRs, так как одна из записей является пустой*. Каково среднее число клиентов, приходящееся на одного CSR? Оно равно числу записей в таблица ш?отег минус число записей, соответствующих UNASSIGNED CSR, деленных на число, равное числу записей в таблице CSR минус 1.

Договорные ния , тем не менее, весьма дабны для создания отчетов. Например, вы можете подставите toown (неизвестно) вместо значение №/f и Not Applicable (не определено) - вместо пустых величин. Разумеется, такой подход сильно отличается от хранения договорных значений в базе данных, где, как мы увидели, они серьезно затрудняют обработку данных.

Возможно, значения Null вредны, и конечно, выглядят безобразно, но это лучший способ тать с неопределенными значениями. Ищите альтернативу использование там, где это имеет смысл, и применяйте где альтернативные пути неприемлемы.

Одна из проблем, связанных с такова: для доменов, содержа-Null (за исключением строковых или текстовых типов данных), значения Null могут иметь двойной смысл. Поле, объявленное как DateTime.. может содержать либо даты, либо Null. Если соответствующий атрибут содержит и неизвестные, и несуществующие неличины, и обе представляются как значения Null, нет способа определить, означает ли конкретное значение неизвестную или несуществующую величину. Эта проблема не возникает для строковых или текстовых типов данных! iv как вы можете использовать пустые строки нулевой длины для обозначения иесуществующи.\ величин, а Null - для представления неизвестных значений.

На практике такие ситуации не столь уж часты. Еще несколько видов доменов (не строковые данные или текст) допус-

кают представление несуществующих величин, поэтому в таких доменах значение Null всегда можно интерпретировать как неизвестную величину. Для доменов, которые допускают представление нссуще-величин, часто можно подобрать подходящую альтернативу Null. Заметьте, я говорю о неких реальных величинах, а не о договорных . Например, хотя отношение Product (Продукт) имеет атрибут Weight (Вес), для продукта Service Call (Звонок в сервисную службу), который, очевидно, не обладает весом, можно использовать О (этот способ подходит для представления отсутствующих данных в

большинстве случаев).

Вторая и значительно более серьезная проблема Null - очень

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

Я не отношусь к значениям Null чересчур легкомысленно, и даже когда существует альтернатива, рекомендую использовать именно их. Пе ломайте модель данных, чтобы облегчить жизнь программистам. Помните об этом, и если система требует использовать значения /Vu - используйте их.

Реакции на нарушения целостности

Проектируя схему базы данных, вы должны не только найти способ

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

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

ти. Мы будем детально обсуждать реакции системы на ошибочные

действия в части 3.

Декларативная и процедурная целостность

Серверы реляционных -> ; данных обеспечивают поддержку целостности двумя способами: декларативно и процедурно. Поддержка декларативной целостности явно определяется (декларируется) как часть схемы базы данных. И механизм баз данных Microsoft Jet, и SQL Server обеспечивают определенную поддержку декларативной целостности. Декларативная целостность - предпочтительный способ для организации целостности данных. Ее следует использовать везде, где это возможно.

SQL Server поддерживает процедурную целостность путем использования триггеров - процедур, которые выполняются, когда запись вставляется, изменяется или удаляется. Механизм баз данных Microsoft Jet не поддерживает триггеры или какую-либ т ую форму процедурной целостности. Когда ограничение целостности нельзя обеспечить средствами декларативное стности, поддержку этого ограничения следует возложить на пользовательское приложение.

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

Целостность на уровне домена

SQL Server обеспечивает поддержку ограниченного ряда доменов в виде определяемые ватсле.м типов данные DDTs), Поля, типами которых являются DTs. наследуют объявления типов данных, также как и ограничения целостности уровня доменов UDDT, Столь же что SQL Server сравнивать между со-

бой поля доленные с помощью разных UDDTs, даже когда сравниваемые UDDTs основаны на одном и том же базовом типе даннь(Х. Например, хотя домены CityName (Название города) и CompanyName (Наименование компании) определены как char(30). SQL Server отвергнет выражение CityName = CompanyName как неверное. -Это можно преодолеть, используя функцию преобразования CityName = CONVERT(char(30), CompanyName). Но тогда вам придется задумы-