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

Первая нормальная форма

Отношение находится в первой нормальной форме, если домены, в которых определены его атрибуты ются скалярными величинами. Понятие скалярное шч 11111,1 - одновременно самое простое и самое сложное в моделировании данных. Принцип таков: каждый атрибут кортежа должен содержать отдельную величину. Но что это означает? В отношении, изображенном на рис. 2-12, атрибут Items несомненно содержит составные величины и поэтому отношение не находится в первой нормальной форме. Но окончательный вывод не всегда столь очевиден.

ВШШШ I j .QnlKaetBj -Ч*-er I:. &ГТШ j

1 еАСТу ,. 1/1/99 3 Zaanse kaeken, 1 Tarte ausycra $89 70 2b3QEv1S/9B4MDZ7arelladiGiDvanni J139 2D .........2 SUPRD . . . . ЬПтъ Ravicli Angela, В fuTy . iH. 06 J

Рис. 2-12. Атрибут Items в данном отношении не является скалярным

Не так просто определить, является ли атрибут скалярным - мы сталкивались с этим, когда рассматривали моделирование имен и адресов в главе I. Можн таести и другие примеры коварных кидов доменов. Например, дата состоит из трех различных компонентоц; дня, месяца и года. Как лучше хранить дату .i;.. три различных атрибута или как единое целое? Как всегда, ответ зависит от особенностей предметной области, которую вы моделируете. Если в вашей системе дата используется исключительно или даже просто в большинстве случаев как отдельная то она - скалярная величина. Но если система часто работает с отдельными даты. лучше хранить ее в качестве набора из трех разных атрибутов мер, если вас интересует только месяц и год, а не конкретный день: или только месяц и день, но не год). Такие случаи не очень часто встречаются, но нельзя сказать, что их нет совсем.

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

ГЛАВА у(Г7>ра базы данных

вы содержимому поля значения, воз-

вращаемые функцией Now (VBA): величину, содержащую и дату, и время. Если потом вы попытаетесь сравнить содержимое поля с результатом, возврашаемым функцией Date(). то получите неверный результат (эта функция возвращает только дату). Даже если вы никогда не показываете значение времени пользователям, оно все равно хранится вместе с датой, а величины 1/1/1999 12:30:19 АМ и 1/ очевидно не совпадают.

Часто проблемы, связанные с составными данными, возникают при моделировании кодов и флагов. Множество компаний используют для ведения учета ссылочные номера, часто представляющие бой некоторую последовательность символов, например Это может означать, например, что учетная запись с таким номером является первой записью в марте 1998 г. Так как маловероятно, что вам удастся изменить учетную политику вряд

ли стоит манипулировать отдельными компонентами учетного номера в модели данных.

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

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

Другой тип составных данных, также вызывающий сложности при моделировании - битовый флаг. В принятой повсеместно практике программирования множество булевых величин сохраняют в виде значений индивидуальных битов в слове, а затем используют побитовые операции, чтобы проверять и извлекать эти значения. Например, программирование с помощью WindowPl в значительной степени основывается на такой технологии. В общем случае такой подход вполне оправдан, но в реляционной модели данных это не так. Здесь он не только нарушает принципы первой нормальной формы - вы просто не сможете его использовать, так как ни механизм СУБ . ни версии языка SQL для SQL Server не поддерживают битовые операции. Выполняйте такие операции, используя собственные функции в приложениях баз данных, но только в Mic-

rosoft Access (Microsoft Visual Basic не позволяет использовать в запросам ци и, написанные самим пользователем). Такой подход требует дополнительно обрабатывать результаты выполнения запросов на локальном компьютере.

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

Существуют другие виды составных данных, о которых следует позаботиться, когда речь идет о приведении к первой нормальной форме: это повторяющиеся группы данных. На рис. 2-13 изображено отношение Invoices. Кто-то где-то решил, что заказчикам нельзя позволить покупать более пяти наименований товара за один раз. (Я буду страшно удивлена, если окажется, что этот кто-то согласовал свое решение с менеджером по продажам). А если серьезно, то такое ограничение всегда налагается на систему оно не обусловлено особенностями ведения бизнеса. Искусственное ограничение

всегда вредно, а в данном случае и несомненно ошибочно. W

1 АМТОМ Cabrales

U5i Louisiana Fiery Hot Pepper Sauce

Puc. 2-13. Эта модель данн1х ограничивает число покупок, которые может сделать покупатель

Другой пример повторяющихся групп приведен на рис. 2-14. Ошибочность этого подхода не столь очевидна, и на его основе было создано множество вполне работоспособных баз данных. Однако это всего лишь вариант подхода к организации данных, показанного на рис13, и он имеет те же самые недостатки. Чтобы убедиться в этом, попытайтесь составить запрос с целью определить, для какого из товаров результаты продаж июили запланированную величину на 10% в I квартале.

Рис. 2-14. Здесь присутствуют повторяющиеся группы