ГЛАВА датгуаяьна* модель даннш

определить домен Event Dale (Дата события), который содержит даты наступление ых событий. С одной стороны диапазон лих

ограничен датой начала деятельности компании. Так, датюво го заказа: Order Dale (Дата заказа) и Shipping Dale (Дата постаики), -могут быть определены в домене Event Date. Атрибут Shipping Date должен содержать дату более позднюю, чем егDate. Это ограничение на уровне ости, и оно должно быть отражено в ее описании.

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

Определение формата

Определение формата представления данных не всегда обязательно,

но часто полезно. Если однажды определить, что дата представляется в формате то не придется делать это повторно.

Нормализация

Вы удивлены, что я нигде не упомянула здесь о нормализации данных? Если вы правильно организовали устранив повторяющиеся группы данных и отношения многие ко многим , то эти

сущности, скорее всего, находятся в третьей нормальной форме.

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

Итоги

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

В следующей главе мы рассмотрим реализацию концептуальной

схемы в физической схемы для конкретного сервера баз данных.

Схема базы данных

ГЛАВА

В предыдущей главе мы рассмотрели модель данных,

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

Системная архитектура

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

друг с другом, модели. Чтобы различать эти понятия, я введу два термина: программная архитектура (code architecture) и архитектура данных (data architecture). Подчеркиваю, что это моя собственная терминология и в другой специальной литературе она не встречается.

Программная архитектура

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

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