ев, не в рамки определяемых форматов. И наконец,

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

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

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

На первый взгляд, правильно указать имя не такая уж сложная задача. Ведь в этом случае большинство данных укладываются приблизительно в одну и ту же схему. Например, имя Ms. Jane Q. Public состоит из обращения (Ms.), имени (Jane), первой буквы второго имени (Q) и фамилии (Public). Значит, при разработке системы можно ограничиться четырьмя сущностями - Title (обращение), First Name (имя), Middle Initial (первая буква второго имени) и Last Name (фашя-лия), не так ли?

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

и Surname (фамилия или прозвище). Во-вторых, как в таком случае ввести в базу данных, например, такое громкое имя как сэр Джеймс Педпингтон Смит, лорд Данстэйбл ( Si: James Peddington Smythe, Lord Dunstable)! Можно ли считать, что Неддингтон Смит (Peddington Smythe) - это фамилия лорда? Или, может быть, Педдингтон (Peddington) - это второе имя? И что, наконец, делать с этой неудобной последней частью имени: лорд Данстэйбл (Lord Dunstable)!К что вы скажете о певце по имени Стинг (Л/л,?)? Какая из сущностей будет реально представлять собой имя Стинг - (имя, данное при

рождении) или Surname (фамилия или прозвище)? И наконец, как

быть с таким сложным именем, как The Artist Formerly Known as Prince

раетесь выходить из такого положения?

Последний вопрос был задан совсем айно. Скорее всего, письмо, адресованное сэру Джеймсу Пелдингт( 1У Смиту (Sir James не вызовет раздражения у самого обладателя титула и не собьет с толку его слугу или личного разбирающего почту. Однако нельзя обратиться к упомянутому джентльмену сэр Смит ; правильное обращение - сэр Джеймс или лорд Дан-стэйб.ч . Однако давайте выясним у нашего заказчика, много ли у него клиентов, которые носят титул лов или леди. Большинство компаний все же не могут похвастаться обилием титулованной клиентуры. Во всяком случае, тот рок-клуб, о котором мы уже вряд ли поблагодарит вас за систему ввода и поиска информации, если та будет содержать форму, подобную показанной на рис. 1-4.

Рис-4. Чрезмерна жненная форма ввода адреса.

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

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

ГЛАВА 1

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

И все же преимущества подобного способа весьма сомнительны. Маловероятно, что адреса сотрудников и клиентов будут использоваться одними и теми же пользователями в одних и тех же целях. Вряд ли, например, массовая рассылка сообщений сотрудникам компании будет производиться с помощью обычной почты, а не корпоративная сети. А значит, и моделирование адресов сотрудников и клиентов компании должны принципиально различаться. Сложная форма ввода адреса, показанная на рис. 1-4, вполне оправдана для хранения только адресов клиентов. Однако если как одна сущность будут реализованы все адреса (и сотрудников, и вам поневоле придется использовать ту же форму для ввода адресов сотрудников компании, что вряд ли имеет смысл.

Домены

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

Понятие домен часто путают с понятием тип данных . Необходимо четко различать эти два понятия. Тип данных - это физическая а домен - логическая. Например, целое число - это тип данных, а возраст - это домен. Приведу еще один пример. Сущности i/ree/yVame (название улипы) и Surname (фамили;!! могут быть реализованы как текстовые поля; однако совершенно очевидно, что это разные виды текстовых полей, и принадлежат они к разным доменам.

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

волов, которых не превосходит трех, а одно из следующих зна-

чепий; {ВА, BS, МА, MS, PhD, LLD, MD}.