ЧАСТЬ 1 Теория }еляцис1ннь1х баз аэнныя

продумать последствия, к которым приведут ограничения на мощность связи, вне зависимости от способа их реализации (подробнее - в главе 16).

Итоги

Эта глава была посвящена связям межд стями. Мы подробно рассмотрели каждый из видов связей: к один ко мно-

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

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

Целостность данных

ГЛАВА

Создание и связей между ними - это только часть про-

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

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

Мэри Смит купила 17 пил 15 июл Ч г. СУБД может проверить, что Мэри Смит и вправду является заказчиком компании, что компания и вправду торгует пилами, и что она принимала заказы июля 1999 г. Можно даже убедиться, что у Мэри Смит достаточно денег на счете, чтобы заплатить за 17 пил. Чего СУБД точно не может проверить, так это того, действительно ли миссис Смит заказала 17 пил, а не семь и не одну, и что она заказала именно пилы, а не отвертки. Лучшее из того, что может сделать система: предупредить пользователя, что 17 пил - слишком большой заказ для розничного покупателя, хотя выгоды от реализации такой функции могут не оправдать затраченных усилий,

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

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

Ограничения целостности

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

ЧАСТЬ 1 баз

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

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

Целостность доменов

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

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

Тем не менее, тип данных может служить подходящим ограничением при моделировании, поэтому выбор логического типа данных часто является первым шагом при создании ограничения домена. Под логическим типо ыхя подразумеваю типы date (дата), string izTyio-ка), image (изображение). Пример, наиболее полно раскрывающий преимущества такого подхода - тип date. Я не рекомендую присваивать домену Transaction Date TwnDateTime. который отражает физический способ хранения данных. Тем не менее, определив его как date, вы получите возможность сформулировать для него ограничение домен содержит значения дат, со дня начала работы компании до настоящего момента включительно и пренебречь другими нудными правилами.

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