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

кий тип char(30}. Но чем более абстрактно вы будете описывать логическую тем больше пространства для маневра у вас останется в и тем меньше вероятность, что придется налагать на систему дополнительные ограничения.

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

помнить: могут ли такие величины храниться в домене, часто (но не всегда) поддается явному определению.

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

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

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

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

на. До некоторой степени решение зависит от того, какое количество сущностей предметной области можно описать в рамках домена.

Допустим, вы определили домен Namen объявили, что атрибуты 6/vf)i/Va;Ht(Имя), Л/Ш/еЛа/к(Второе имя), 5 гЛГдте (Фамилия), и Сот/)дя/Уате (Название компании) определены в этом домене. Та-

ЧАСТЬ 1 баз

кой подход имеет свои преимущества; общие правила (или множество правил) для атрибутов определяются в одном месте.

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

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

Иногда можно просто перечислить величины, разрешенные для домена. Домен, определяющий обычные выходные дни полностью, описывается множеством ulкрессiibcj. В другом случае проще сформулировать для домена ряд правил, ограничивающих множество возможных значений, как для TransactionDate.

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

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

Ограничения целостности переходов еделяют состояния, через которые может проходить кортеж. Диаграмма состояния-переходы показывает состояния, через которые может проходить заказ (рис. 4-1).

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

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

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

Отправлен

Введен Обработан Принят заказчику Отменен Выполнен

к>

Гис. 4-1. Диаграмма состояний, через которые может проходить заказ

Например, статус заказчика может меняться только с (Обычный) на Preferred (Привилегированный), если его кредит выше определенной величины и он являлся заказчиком компании не менее года. Состояние счета заказчика лучш ировать, используя соответствующий атрибу] отнощения Customers. А длительность отношений компании с заказчиком и вовсе не нужно нигде не хранить явно, ее можно вычислять на основе даты наиболее раннего заказа, которая содержится в отношении Orders.

Целостность на уровне сущности

Ограничения на уровне сущности (entity constraints) направлены на

обеспечение целостности моделируемой сущности. На простейшем

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

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

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