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

Атрибуты

В разрабатываемой системе будут храниться записи об определенных параметрах каждой из сущностей. Эти параметры называются атрибутами сущностей имер, если в вашей системе присутствует такая сущность, как Customer (Покупатель), вам, скорее всего, потребуется хранить имена и и возможно, род деятельности клиентов.

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

Определение атрибутов, которые нужно включить в разрабатываемую модель - это семантический процесс. Рещая эту задачу, нужно основываться на том, что реально означают хранимые данные и как они будут использоваться. Возьмем простейший пример - адрес. Определите ли вы адрес как одну сущность (Address) или как несколько сущностей {HouseNumber- номер дома. Street - улица. City - город, ZipCode. почтовый индекс)? Больщинство разработчиков баз данных (в том числе и автоматически разобьют адрес на несколько атрибутов - ведь структурированными данными обычно легче манипулировать. Но порой это не так, а значит, данное правило отнюдь нельзя считать непреложным.

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

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

и если да, то на какие? В Соединенных Штатах код щтата имеет четко определенные мат, ровать этот код как отдельную

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

На первый взгляд кажется, что простого набора атрибутов: House-Number (номер дома). Street (название улииы). City (город), State .(штат), Z/>Corfe (почтовый индекс), - вполне достаточно. Но ведь существуют еще номера квартир многоэтажных жилых домов и номера почтовых ящиков, на которые приходит корреспонденция для частных лиц или небольших фирм. А как учесть возможность заявки на приобретение товара на чужое имя? И конечно же, нужно подумать о Нотенпиальных возможностях расширения бизнеса, Что если клиентом компании станет человек, проживающий за пределами США, или иностранная компания? В последнем случае недостаточно знать только название страны и почтовый код клиента - форматы почтового кода в США и в других странах могут существенно различаться. Не исключено, что потребуется существенно изменить уже имеющиеся сущности. Например, шинстве стран Европы при написании адреса номер дома указывается после названия улицы. Подобную проблему легко решить при вводе данных, но есть головоломки и посложнее. Например, многие ли пользователи вашей системы знают, что в австралийском адресе 4/32 Griffen Avenue, Bondi Beach, Australia ры 4/32 означают номер квартиры (4) и номер дома (32)?

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

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

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

ЧАСТЬ 1 Теория баз данных

зультата и старайтесь по возможности ь модель, а не усложнять ее.

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

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

Кроме того, следует уделить особое внимание вопросам, которые пользователь мог задать, если бы знал, что это принципиально возможно. Это особенно важно, когда вы проектируете систему, автоматизирующую действия, ранее выполнявшиеся вручную. Попробуйте, например, обратиться к библиотекарю с просьбой дать справку: какое количество книг из 4 млн., находящихся в его ведении, было выпущено в Чикаго до 1900 г. Скорее всего, библиотекарь предложит вам выяснить это самостоятельно, воспользовавшись картотекой. А хорошо спланированная база данных позволит получить ответ за несколько секунд.

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

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