WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 || 3 | 4 |   ...   | 6 |

«Press Riordan DESIGNING Relational Database Systems Press Ребекка Райордан реляционных баз данных Москва 2001 Р УДК 004 32.973.26-018.2 Р45 Р. ...»

-- [ Страница 2 ] --

С другой стороны, если отношения «один к одному» используют ся с целью решить проблему с ограничениями на число полей (и сле довательно, атрибутов сущности в системе), либо в предметной обла сти между сущностями существуют уникальные отношения «один к одному», выбор ссылочного отношения зачастую произволен. Пожа луй, единственный случай, когда выбор ссылочного отношения оп ределяется особым правилом — когда связь является необязательной.

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

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

Связи «один ко многим» — также достаточно любопытный слу чай, требующий внимательного отношения. Здесь легко ошибиться при определении, для какого из участников данная связь будет нео бязательной. Существует довольно распространенное заблуждение, что таковой она будет для отношения, участвующего в связи со сто роны однако посмотрите на рис. 3-12 и вы поймете, что это не так.

Рис. 3-12, Эта связь является необязательной в обоих направлениях Связь между сущностями и CustomerServiceRep является нео бязательной в обоих направлениях. Это означает, что у Customer ServiceRep может быть произвольное число клиентов, в том числе и ни одного. Атрибут клиента CustomerServiceRep, если таковой опреде лен, должен присутствовать в отношении CustomerServiceRep. Опреде ление необязательного участника «один ко многим» важно, как для так и для эксплуатации системы. Подробнее об этом мы поговорим в главах 4 и 14, а сейчас просто запомните, что реля ционная теория отнюдь не предписывает, чтобы связь была обяза тельной для одного из отношений, участвующих в связи «один ко многим».

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

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

Связи ко многим» Связи «многие ко многим» часто встречаются в реальном мире, На пример, студенты посещают множество лекций, причем каждый от дельный курс посещает множество студентов. Покупатели приобре тают товары в разных магазинах, и в каждом магазине приобретает товары множество покупателей. Но в реляционной базе данных реа лизовать связь «многие ко многим» невозможно. При моделировании таких связей разработчики используют промежуточную связь «один ко многим» с каждым из отношений — участников связи «многие ко ЧАСТЬ 1 Теория многим» (рис. 3-13). Такое промежуточное отношение промежуточной таблицей table);

этот термин используется и при создании модели данных, где речь, конечно же, идет об отноше ниях, а не о Эта связь ко многим» Сущность Сущность будет представлена в модели данных так:

Промежуточная I Сущность Сущность 1 •'..

таблица 3-13. Для моделирования связи «многие ко многим» используется промежуточная таблица Поскольку при моделировании связи «многие ко многим» заме няются двумя связями «один ко то совершенно ясно, какое из отношений будет ссылающимся, а какое — ссылочным. Как уже говорилось, отношение, в связи «один ко со стороны «один», всегда является ссылочным. Это означает, что все первоначальные сущности, то есть сущности, участвующие в связи «многие ко многим», замененной двумя связями ко многим», в данной модели будут ссылочными отношениями, а промежуточная таблица — Ключи-кандидаты промежуточной табли цы включают первоначальных отношений, связан ных с промежуточной таблицей.

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

Унарные связи Итак, мы подробно рассмотрели различные типы двойных связей, то есть связей, в которых участвуют два отношения. В унарных связях существует только один участник — отношение, связанное с самим собой. Классический пример — связь между сущностями Employee и Manager. Если сотрудники, не являющиеся менеджерами, подчиня ются кому-либо из то менеджер, как правило, подчиня ется самому себе, а также вышестоящему менеджеру.

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

Employees EmployeelD К FirstName Title Courtesy Date Address City Region PostalCode Country HomePhone Extension Photo Notes ManagerlD 3-14. Унарная связь существует, когда отношение с самим собой Унарные связи иметь любую Унарные связи «один ко многим» помогают иерархии. Пример — орга низационная структура компании, ясно прослеживаемая в связи Унарные связи ко многим», как и двойные связи этого типа, реализуются с промежуточных таблиц.

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

Тройные связи Как правило, тройные связи представляют собой связи вида няет Как и связи «многие ко многим», их невозможно непос 1 баз редственно в базе данных. Но для трой ных связей не существует единых правил моделирования, и в этом их отличие от отношений ко многим».

Рассмотрим пример на рис. 3-15. Продукт который закупает компания et alcools поставляют две компании — и d'erables». Однако не возможно узнать, какой именно из поставщиков поставил определен ную партию этого продукта компании «Vins et alcools Chevalier». Ины ми словами, тройная связь в модели данных утеряна. Однако при раз работке моделей баз данных следует учитывать, что поставщики не просто поставляют имеющиеся у них в наличии продукты — они по ставляют их конкретным клиентам.

VINET el alcools Chevalier VINET VINET 10248 Fried VINET di di Giovanni Fortini s.r.l.

di d'erables Рас. 3-15. Отношения не позволяют у какого поставщика компания et alcools Chevalier» приобрела продукты Чтобы полностью разъяснить ситуацию, рассмотрим отношения в типичной проблемной области (рис. 3-16). На этой диаграмме каж дый продукт поставляется только одним поставщиком, и поддержи вается тройная связь. Вы всегда можете узнать, какой именно постав шик поставил определенный продукт.

Suppliers Products К OrderDetails Orders Customers Рис. 3-16. Типичная цепочка связей между сущностями, используемыми для моделирования процесса заказа ГЛАВА 3 Связи Посмотрим теперь на рис. каждый продукт может быть по лучен от разных поставщиков, и тройная связь отсутствует.

Рис, 3-17. Тройная связь отсутствует Один из способов решить проблему — выяснить направление свя зи «один ко многим». Для каждой отдельной сущности, участвующей в связи со стороны «многие», можно однозначно определить соответ ствующую сущность, участвующую в связи со стороны Так, для каждого конкретного значения атрибута 3-16) можно определить, к какому из значений атрибута Orders он принад лежит;

зная значение Orders, нетрудно определить значение Customers.

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

Однако в обратном направлении связи «один ко многим» подоб ный подход применить не удастся, поскольку каждой сущности, уча ствующей в связи со стороны «один», невозможно сопоставить ственную сущность, участвующую в связи со стороны «многие». Рас смотрим пример на рис. 3-17. По определенному значению атрибута OrderDetails невозможно определить, какой продукт был заказан. Если же это известно, нельзя определить, с какой именно сущностью связан этот продукт, или другими словами, выяснить, кто поставил.

Отсюда следует упрощенное правило: в цепочке связей нельзя ме нять направления связей с ко многим» на «многие к одному» ЧАСТЬ 1 баз данных более одного раза. В цепочке связей на рис. 3-16 направление изме няется только один раз, на сущности В цепочке связей на рис. 3-17 направление меняется дважды — один раз на а второй — на Products.

Проблему можно решить, исключив сущность Products из цепочки связей (рис. 3-18).

Рис. 3-18. связи сохранены В получившейся направление связи меняется только один раз — на сущности OrderDetails, и таким образом связь поддержива ется. При этом сущность Products отнюдь не исключена из модели, Скорее всего, заказы будут оформляться на продукты (сущность Pro ducts), а не на поставщиков (сущность и сущность Products позволит учитывать это при разработке пользовательского интерфейса.

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

Важно, что модель на рис. ничуть не «лучше» и не «правильнее» модели на рис. 3-17. Выбор модели определяется прежде всего семан тикой предметной области.

Связи определенной мощности Часто число кортежей отношения, участвующего в связи ко многим» со стороны можно оценить заранее: известно ми ГЛАВА максимальное или точное число таких записей. Напри мер, у школьников младших классов каждый день бывает не больше пяти уроков, скелет взрослого человека состоит из 200 костей, а на шахматном турнире каждый из участников соревнований должен сыг рать определенное число партий, В подобной ситуации появляется искушение построить модель дан ных таким образом, чтобы включить ключ-кандидат каждого кортежа как атрибут отношения с одной стороны (рис. 3-19). Но у такого спо соба два серьезных недостатка, Первый в подобной модели суще ствуют повторяющиеся группы атрибутов, второй — она не надежна.

Модель для связи с мощностью (неверный подход) атрибуты на рис. 3-19 легко выявить по именам, однако все они определены на одном домене — Когда в модели несколько атрибутов определяются на одном домене, весьма вероятно, что значения категории или типа будут ошибочно приняты за имена атрибутов.

К тому же, как уже говорилось, структуры, организованные по этому принципу, не надежны. Допустим, компания проводит такую кадровую политику;

за каждым менеджером закрепляется не более пяти служащих, отчитывающихся непосредственно перед ним. Увы, политика и реальность — это разные вещи. Закладывая политику в модель данных, вы тем самым реализуете ее как жесткое системное ограничение, которое не может быть изменено впоследствии. Могу поспорить, что при вводе реальных данных хотя бы за одним менеджером в компании закреплено шесть а не пять. Что произойдет в этом случае? Будет ли одному из служащих назначен другой менеджер? Будет ли продублирована запись, иден тифицирующая менеджера в базе данных, и соответственно увеличит ся ли заработная плата, начисляемая менеджеру? Или же дело огра ничится что сотрудник отдела информационных технологий, к которому обратился озадаченный пользователь, позвонит вам и выс кажет все, что он думает о таком разработчике баз данных?

Подобные ограничения, налагаемые на связи, должны реализоваться как системные и никак не влиять на структуру данных в проектируемых отношениях. Кроме того, следует очень тщательно ЧАСТЬ продумать последствия, к которым приведут ограничения на ность связи, вне зависимости от способа их реализации (подробнее — в главе 16).

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

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

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

Целостность данных ГЛАВА Создание и связей между ними — это только часть про моделирования предметной области. Вы должны записать пра вила, которые система будет использовать для поддержания данных, физически хранящихся в базе данных, в согласованном состоянии.

Другими словами, вам нужно создать модель целостности данных.

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

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

Ограничения целостности Иногда ограничения целостности отождествляют с бизнес-правила ми. На самом деле, понятие «бизнес-правила» имеет значительно бо лее широкий смысл: оно включает все ограничения модели, а не голь ЧАСТЬ 1 баз ко ограничения целостности данных. В частности, безопасность сис темы (то есть правила, кто, что и при каких обстоя тельствах может делать с системой) — задача системного админист рирования, а не поддержания целостности данных. Однако систем ная безопасность — это требование бизнеса, и она включает в себя ряд бизнес-правил. Мы рассмотрим системную безопасность в главе 8.

Целостность данных реализуется на нескольких уровнях.

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

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

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

Когда вы определите логический тип данных, может потребовать ся дополнительно задать размер и точность числового типа данных или строкового типа. Это очень похоже на спе ГЛАВА 4 данных физического типа данных, но вам все еще следует мыс лить категориями логической модели. Очевидно, вы не будете возра жать, если я скажу, что логический тип данных «строка, состоящая не более чем из 30 можно коротко записать как физичес кий тип Но чем более абстрактно вы будете описывать логи ческую тем больше пространства для маневра у вас останется в и тем меньше вероятность, что придется налагать на сис тему дополнительные ограничения.

Еще один аспект целостности который надо учитывать — может ли домен содержать неопределенные или несуществующие величины. Мы еще не раз будем обсуждать этот вопрос в этой и сле главах книги. А сейчас достаточно упомянуть о разнице меж ду несуществующей и неопределенной величинами. Также следует помнить: могут ли такие величины храниться в домене, часто (но не всегда) поддается явному определению.

На логическом уровне различие между «несуществующей» и «нео пределенной» величиной понять несложно. (Помните, что модель данных — логическая конструкция.) «У моего отца нет второго име ни» — пример несуществующей величины. «Я не знакома со своими соседями» — пример неопределенной величины. Вопросы реализа ции нас пока не касаются, но логические различия необходимо по нимать.

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

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

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

Допустим, вы определили домен и объявили, что атрибуты (Имя), (Второе имя), (Фамилия), и (Название компании) определены в этом домене. Та ЧАСТЬ 1 баз кой подход имеет свои преимущества;

общие правила (или множе ство правил) для атрибутов определяются в одном месте.

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

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

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

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

Целостность на уровне переходов Ограничения целостности переходов состояния, через ко торые может проходить кортеж. Диаграмма «состояния-переходы» казывает состояния, через которые может проходить заказ (рис. 4-1).

Ограничения переходов помогут убедиться, что статус данного за каза никогда не изменится с «Введен» на «Выполнен», если заказ не прошел через стадии, или предотвратить изменение стату са отмененного заказа.

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

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

ГЛАВА Отправлен Введен Обработан Принят заказчику Отменен Выполнен Рис. 4-1. Диаграмма состояний, через которые может проходить заказ Например, статус заказчика может меняться только с (Обычный) на Preferred (Привилегированный), если его кредит выше определенной величины и он являлся заказчиком компании не менее года. Состояние счета заказчика лучше используя со ответствующий отношения Customers. А длительность отно шений компании с заказчиком и вовсе не нужно нигде не хранить явно, ее можно вычислять на основе даты наиболее раннего заказа, которая содержится в отношении Orders.

Целостность на уровне сущности Ограничения на уровне сущности (entity constraints) направлены на обеспечение целостности моделируемой сущности. На простейшем уровне существование первичного ключа является ограничением сущности, налагающим на нее правило «каждая сущность должна быть уникальной».

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

на уровне отдельного атрибута определяется в пер вую очередь с помощью ограничений домена этого атрибута. Атрибут отношения наследует ограничения целостности своего домена. На уровне сущности эти наследуемые ограничения часто формулируют более строго, но менее гибко. Иными словами, ограничение на уров ЧАСТЬ 1 Теория баз не сущности может быть подмножеством ограничений на уровне до мена, но не надмножеством, Например, на атрибут опре деленный в домене Date, допустимо дополни тельное ограничение, он содержал только даты текущего года, в то время как домен разрешает хранить любую дату от начала работы компании до сегодняшнего дня. Но ограничение на уровне сущности расширит диапазон хранимых в OrderDate значений по сравнению с диапазоном, определенным на уровне домена.

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

ПРИМЕЧАНИЕ часто определяют правила проверки значений и хранения величин именно на уровне сущ ности, а не на уровне домена. Обычно они аргументируют свое реше ние тем, что эти ограничения используются только на уровне сущно сти. Для такой позиции есть некоторые основания, но я рекомендую определять как можно больше ограничений на уровне домена. Это об легчит дальнейшую работу по спецификации Кроме того, в процессе сужения диапазона разрешенных значе ний для единственного атрибута ограничения на уровне могут влиять на другие атрибуты. Пример такого ограничения — тре бование, чтобы дата поставки в заказе не предшество вала дате самого заказа (OrderDate). Ограничения на уровне сущнос ти, тем не менее, не могут ссылаться на другие отношения. Неприем лемо, например, определять ограничение на уровне сущности, кото рое задает скидки для заказчика отно шения Customer) на основании значения общей суммы сделанных за казов (которое вычисляется с помощью суммирования дан ных из множества записей отношения Ограничения, за висящие от множества определяются на уровне базы дан ных (подробнее — далее в этой главе).

Будьте осторожны с ограничениями, связанными с несколькими атрибутами: необходимость их использования может свидетельство вать, что модель плохо нормализована. Если вы ограничиваете или вычисляете значение одного атрибута на основании другого, то веро ятно, все в порядке. на уровне которое зву чит как не можег иметь значение Preferred (Привилегирован ГЛАВА ный), до тех пор пока самой записи о заказе клиента не ис полнится по крайней мере один год» выглядит прекрасно. Но если значение одного атрибута определяет значение другого: например, «Если запись о заказе была сделана более года назад, тогда значение статуса равно Preferred то имеется функ циональная зависимость и отношение не находится в третьей нор мальной форме.

Ссылочная целостность В главе 3 мы рассмотрели декомпозицию отношений, выполняемую с минимизировать избыточность данных, и внешние ключи, используемые для организации связей между отношениями. Если эти связи будут разрушены, система станет в лучшем случае ненадежной, а в худшем — откажется работать. целостности (referential integrity constraints) поддерживают и защищают эти связи.

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

• кортеж, добавленный в таблицу, содержит значение внешнего ключа, которому не соответствует ни одно значение ключа-кан дидата в ссылочной таблице;

• изменилось значение в ссылочной таблице;

• запись, на которую ссылается внешний ключ, удалена из ссылоч ной таблицы.

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

Второй случай осиротевших сущностей — изменение значения ключа-кандидата в ссылочном отношении наблюдается не очень часто. Я рекомендую не изменять значение ключа-кандидата везде, где это возможно, то есть использовать на уровне сущности ограни чение типа: «Значения изменять». Но если модель позволяет менять значения ключе вы дол ЧАСТЬ 1 реляционных баз данных быть уверены, что соответствующие изменения вносятся во вне шние ключи. Такой подход известен как каскадное обновление. И Microsoft Jet, и Microsoft SQL Server обеспечивают простые механиз мы поддержки.

Последний случай «сиротства» внешнего ключа — удаление запи си из ссылочной таблицы. Например, если кто-то удалит запись из отношения что при этом с заказами удаляемого покупателя? Как и в случае изменения значения ключа-кандидата, ре — использовать запреты. Следует удаление за писей из таблиц везде, где это возможно. Это самое про стое и ясное решение проблемы, если, ваша система позво ляет его применить. Если же это невозможно, используйте каскадное удаление.

есть одна возможность, которая несколько более сложна с точки зрения В любом случае, ее нельзя реали зовать автоматически. Вам может понадобиться «переместить» ссыл ки с одной записи на другую. Потребность в этом возникает нечасто, но иногда это необходимо. Допустим, заказчик А приобрел нию — заказчика Б. Тогда может потребоваться удалить запись о за казчике Б и связать все записи о заказах, сделанных заказчиком Б, с заказчиком А.

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

В модели данных такие правила как «Менеджеры могут иметь не бо лее пяти подчиненных» определяются как ограничения ссылочной целостности.

Целостность на базы данных Наиболее общая форма ограничения целостности - целостность базы данных. Ограничения на уровне базы данных определяются не скольких отношений: «Заказчик не может иметь статус Preferred (При если он не является заказчиком компании в тече по крайней мере, Большинство ограничений на уровне базы данных имеют подобную форму.

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

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

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

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

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

Транзакции тесно связаны с рабочими процессами.

эта концепция предполагает, что данный рабочий процесс может включать в себя одну или несколько транзакций, и наоборот. Не со всем но удобно представлять себе рабочий процесс как некую абстракцию («добавить заказ»), а - как физическое дей ствие («обновить таблицу Транзакцию определяют как единицу рабо ты», что я всегда бесполезным и риторическим.

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

ЧАСТЬ 1 Теории баз Классический пример транзакции — перевод денег с одного бан ковского счета на Если система снимет деньги со счета А, но не сможет зачислить их на счет В, деньги будут потеряны. Очевидно, зачислить деньги не удалось, то и снятие денег со счета нужно На языке баз данных это называется откатом (rolling hack).

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

Как механизм баз данных Microsoft Jet, так и SQL Server обеспе чивают средства для поддержания целостности транзакций путем ис пользования команд BEGIN TRANSACTION, COMMIT TRANS ACTION и ROLLBACK TRANSACTION. Как и можно было ожидать, реализация целостности транзакций в SQL Server более собна и лучше обрабатывает возникающие из-за сбоев обо рудования и программного обеспечения. Впрочем, это уже вопрос реализации, а они не являются предметом нашего рассмотрения. Что действительно важно с точки зрения проектирования — это умение сформулировать и создать зависимости, наполнив неконкретное выражение «логическая единица работы» практичес ким содержанием, Реализация целостности данных Вплоть до этого момента мы концентрировали внимание на концеп туальном, абстрактном моделировании предметной области. А сей час рассмотрим несколько вопросов, возникающих при создании физической модели предметной области, конкретно — при создании схемы Переход от одного этапа к другому сопровождается в пер вую очередь изменением терминологии — отношения становятся таб лицами, а атрибуты — полями. касающиеся целостности данных, однако, возникают каждом из этапов.

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

ГЛАВА «Проблема отсутствующей информации» возникла тогда же, ког да была предложена первая модель. Как показать, что какая-то часть информации либо неизвестна (заказчик в ности имеет фамилию, мы только не знаем, какую), либо отсутствует (у заказчика нет имени)? Большинство реляционных баз дан ных, включая как Microsoft Jet, так и и SQL Server, воз можность использовать «пустое значение» — так называемый Null — как способ работы с неопределенными и несуществующими значе ниями.

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

Некоторые эксперты в области баз данных полностью отвергают кон цепцию Null. К. Дж. Дейт заявляет, что Null «разрушает и я уже не помню, сколько раз я слышала в адрес слово «вредная». Любые замечания о сложности обработки Null- и всегда сводятся в конечном итоге к выводу: «О Боже! Вам не следует их использовать. Их нужно выкинуть».

В качестве альтернативы те, кто считают, что значения Null вред ны, рекомендуют использовать специфические величины, описанные для домена, чтобы показать, что величина не оп ределена или не существует (или все вместе). Я называю это подходом (conventional value approach).

На мой взгляд, этот подход имеет ряд недостатков. Во-первых, во многих случаях «договорное значение» условно. Дата 9/9/1900 на са мом деле не означает, что значение даты неизвестно, мы просто со гласились, что будем интерпретировать эту дату как неопределенное значение.

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

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

Возьмем, например, необязательную связь между заказчиком и представителями отдела обслуживания клиентов (CSR): каждый CSR, однажды обслужив клиента, должен быть занесен в таблицу CSR.

Подход договорных значений требует, чтобы запись, которая добав ляется в таблицу CSR, соответствовала «договорному значению», выб ранному, чтобы показать, что CSR не связан ни с одним клиентом (рис. 4-2).

ЧАСТЬ 1 Теория Customers Anne.

Peacock e! f\\s ' BSBEV para Centra a Laura Chinese Janet C.o Holdings CSRs Andrew Janet Steven Michael Robert Anne 4-2, «Договорные значения» требуют дополнительных «пустых» записей для поддержания ссылочной целостности Теперь подсчитаем, сколько представителей службы клиентского сервиса (CSRs) работает компании. На одного меньше, чем жится в таблице CSRs, так как одна из записей является Каково среднее число клиентов, приходящееся на одного CSR? Оно равно числу записей в таблице минус число записей, соот ветствующих «UNASSIGNED» CSR, деленных на число, равное чис лу записей в таблице CSR минус 1.

«Договорные тем не менее, весьма для созда ния отчетов. Например, вы можете подставить (неизвестно) вместо значений Not Applicable (не определено) — вместо «пус тых» величин. Разумеется, такой подход сильно отличается от хране ния «договорных значений» в базе данных, где, как мы увидели, они серьезно затрудняют обработку данных.

ГЛАВА Возможно, значения Null вредны, и конечно, выглядят безобраз но, но это лучший способ с неопределенными значениями.

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

Одна из проблем, связанных с такова: для доменов, содержа Null (за исключением строковых или текстовых типов данных), значения Null могут иметь двойной смысл. Поле, объявленное как может содержать либо даты, либо Null. Если соответствую атрибут содержит и неизвестные, и несуществующие неличины, и обе представляются как значения Null, нет способа определить, оз начает ли конкретное значение неизвестную или несуществую щую величину. Эта проблема не возникает для строковых или тек стовых типов данных, как вы можете использовать пустые строки нулевой длины для обозначения величин, a — для представления неизвестных значений.

На практике такие ситуации не столь уж часты. Еще несколько видов доменов (не строковые данные или текст) допус кают представление несуществующих величин, поэтому в таких до менах значение Null всегда можно интерпретировать как неизвестную величину. Для доменов, которые допускают представление величин, часто можно подобрать подходящую альтернати ву Null. Заметьте, я говорю о неких реальных величинах, а не о «дого ворных». Например, хотя отношение Product (Продукт) имеет атри бут Weight (Вес), для продукта Service Call (Звонок в сервисную служ бу), который, очевидно, не обладает весом, можно использовать О (этот способ подходит для представления отсутствующих данных в большинстве случаев).

Вторая и значительно более серьезная проблема Null — очень сложная обработка таких данных. Логическое сравнение величин ус ложняется, а результаты выполнения запросов становятся трудными для понимания. Мы будем детально рассматривать эти проблемы в главе 5.

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

Реакции на нарушения целостности Проектируя схему базы данных, вы должны не только найти способ эффективно реализовать ограничения но и решить, ка кие действия предпримет механизм баз данных в ответ на нарушения ЧАСТЬ 1 баз целостности. Конечно, в большинстве случаев, база данных просто отвергнет команду-нарушителя, отправив пользователю сообщение об ошибке. Но иногда СУБД выполняет самостоятельную коррекцию команды. Примеры: величины по умолчанию для атри бутов, которые не разрешают пустые значения, или операции ного обновления и удаления для обеспечения ссылочной ти. Мы будем детально обсуждать реакции системы на ошибочные действия в части 3.

Декларативная и процедурная целостность Серверы реляционных данных обеспечивают поддержку ности двумя способами: декларативно и процедурно. Поддержка дек ларативной целостности явно определяется (декларируется) как часть схемы базы данных. И механизм баз данных Microsoft Jet, и SQL Server обеспечивают определенную поддержку декларативной целос тности. Декларативная целостность — способ для организации целостности данных. Ее следует использовать везде, где это возможно.

SQL Server поддерживает процедурную целостность путем использо вания триггеров — процедур, которые выполняются, когда запись вставляется, изменяется или удаляется. Механизм баз данных Microsoft Jet не поддерживает триггеры или какую-либо форму проце дурной целостности. Когда ограничение целостности нельзя обеспе чить средствами декларативной поддержку этого ограни чения следует возложить на пользовательское приложение.

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

Целостность на уровне домена SQL Server обеспечивает поддержку ограниченного ряда доменов в виде определяемых типов данных Поля, ти пами которых являются наследуют объявления типов дан ных, также как и ограничения целостности уровня доменов Столь же что SQL Server сравнивать между со бой поля, с помощью разных UDDTs, даже когда срав ниваемые UDDTs основаны на одном и том же базовом типе Например, хотя домены CityName (Название города) и CompanyName (Наименование компании) определены как SQL Server от вергнет выражение CityName = CompanyName как неверное.

можно преодолеть, используя преобразования CityName = CompanyName). Но тогда вам придется ГЛАВА ваться об этом каждый раз, когда вы сравниваете поля, объявленные в различных доменах (хотя чаще всего такое сравнение не имеет смысла).

UDDT создается либо с помощью SQL Server Enterprise Manager, либо с помощью системной хранимой процедуры В лю бом случае для указывается имя, тип данных и определяется, могут ли они содержать значения Null. Когда UDDT создан, вы впра ве определить для него значения по умолчанию и правила проверки.

SQL Server является логическим выражением, которое опре деляет значения, приемлемые для UDDT (или для поля, если прави ло относится к полю, а не к UDDT). (Значение по умолчанию — это просто величина, которую система подставляет в поле, если пользо ватель не задал значение этого поля явно).

Привязка правила или величины по умолчанию к UDDT состоит из двух шагов. Сначала нужно создать правило или величину по умол чанию, а потом — привязать их к UDDT (или полю). Целесообраз ность такой сложной двухступенчатой процедуры объясняют, как правило, следующим образом: будучи однажды определенной, вило по умолчанию может быть использовано повтор но. Я нахожу это утомительным, так как такие объекты повторно ис пользуются редко. Когда определяется таблица, SQL Server обеспе чивает возможность декларации значений по умолчанию и ограниче ний CHECK в самом определении таблицы. (Ограничения CHECK во многом подобны правилам, но обладают большими возможностя ми). К сожалению, такая простая декларация недоступна для объяв ления UDDT — для них нужно использовать метод «создать, потом Было бы желательно, чтобы корпорация Microsoft добавила в будущие версии SQL Server поддержку значений по умолчанию и ограничений CHECK в объявления UDDTs.

Второй способ реализации ограничений целостности на уровне домена — использовать просмотровые таблицы. Этот способ приме ним как для Microsoft Jet, так и для SQL Server. В качестве примера возьмем домен Теоретически вы можете создать правило, значения всех 50 штатов. Реально это мучительный про цесс, в частности для механизма баз данных Microsoft Jet, где такое правило пришлось бы переписывать для каждого поля, определенно го в этом домене. Намного легче создать таблицу USStates и исполь ссылочную целостность, которая будет гарантировать, что поле содержит только значения из таблицы.

Целостность на уровне сущности В схеме базы данных ограничения на уровне сущности управляют конкретным полем, множеством полей или таблицей в целом. И ме ЧАСТЬ 1 баз баз данных Microsoft Jet, и SQL Server предоставляют сред ства, гарантирующие целостность на уровне сущности. SQL Server обеспечивает более богатый спектр возможностей (и это не тельно), впрочем, разница не столь уж велика.

Самое фундаментальное ограничение целостности на уровне от полей — это, конечно, тип данных. Механизм баз данных Microsoft Jet и SQL Server обеспечивают богатый спектр типов дан ных (табл. 4-1).

Типы данных Jet и SQL Server Логический Тип данных Тип данных Хранимый Размер тип данных SQL Server Microsoft Jet диапазон значений Integer Long integer Целые числа от 4 байта -2 147 483 648 до 2 147 483 Smallint He определен от 2 байта -32 768 до 32 Tinyint Целые числа от 1 байт 0 до Точное Decimal Number Целые или байт числовое (различные дробные числа от значение до (exact numeric) Числа с Float (до 15 Действительные 8 байт плавающей числа от точкой после до положи десятичной тельные числа от точки) отрицательные числа от Real Single Действительные 4 байта числа от до положи тельные числа от числа до ГЛАВА (продолжение) Строка Char He Не более 255 сим- 1 байт на символов определен волов для Microsoft символ фиксирова- Jet;

8000 символов нной длины для SQL Server 7. (255 — в более ран них версиях) Строка Text Не более 255 сим- 1 байт на символов волов в Microsoft символ переменной Jet, 8000 символов длины для SQL Server 7. (255 — в ранних версиях) Денежный Money Currency Числа с точностью 8 байт до четырех знаков после десятичной точки в диапазоне от -922 337 208 477,5808 до 922 208 Smallmoney He определен Числа с точностью 4 байта до четырех знаков после десятичной точки в диапазоне от -214 до Дата и От 1 января г. 8 байт время до 31 декабря 9999 г.

для SQL Server;

от 1 января 100 до 31 декабря для Microsoft Jet Не От 1 января 1900 г. 4 байта определено до 6 июня 2079 г.

Двоичные Binary Не Не более 8000 байт Количество определено данные фик- байт плюс сированной 4 байта длины Двоичные Поддержива- Не более 8000 байт Количество данные ется только байт плюс переменной для присое- 4 байта диненных длины таблиц ЧАСТЬ Логический Тип данных данных Хранимый тип SQL Server Jet значений Большие Text Memo Строковые данные двоичные до 2 Гб для плюс SQL Server или 1 Гб байт или текс товые для Microsoft Jet Логический Bit Yes/No 0 или 1 1 байт, но в SQL Server тип битовые зна чения комби нируются в байт Как я уже упоминала, SQL Server также разрешает определять поля, используя Поля типа наследуют возможность хранить Null, значения по умолчанию и правила, которые были опре делены для типа, но могут быть переопределены на уровне Ло гически ограничение на уровне поля должно сужать ограничения для но фактически SQL Server просто заменяет определения для на те, что определены для полей. То есть можно разрешить хранение Null для поля, даже если UDDT, в котором определено поле, не позволяет этого.

SQL Server и механизм баз данных Microsoft Jet позволяют конт могут ли поля хранить значения Когда определяют поле в SQL Server, просто специфицируют как NULL или NOT NULL или щелкают элемент управления Enterprise Manager.

Для механизма баз данных Microsoft Jet значений Null можно задать двумя способами — используя Null или поле Required. Кроме в механизме баз данных Microsoft Jet существу ет флаг который определяет, можно ли хранить в полях типа Text или Memo пустые строки В SQL Server для этого используют ограничение СН ЕСК.

Задание соответствующего свойства при определении поля позво ляет определить значения по умолчанию в механизме баз данных Microsoft Jet. В Server можно определить свойство Default при создании поля или связать некое значение, генерируемое системой, со свойством Default, как это описано для UDDT. Я рекомендую объявлять значение по умолчанию в определении если вы не можете сделать этого на уровне домена.

ГЛАВА Наконец, и Microsoft Jet, и SQL Server позволяют специфициро вать ограничения на уровне сущности. Microsoft Jet обеспечивает два свойства поля — Validation и SQL Server разрешает создать ограничения CHECK на уровне поля или привязать ное правило к полю позднее, но первый метод предпочтительнее.

На первый взгляд, правила Microsoft Jet и ограничения CHECK сервера SQL Server выглядят но между ними есть несколько отличий. Оба имеют форму логических вы ражений, и никогда не позволяют сослаться на другие или таблицы. Однако правила проверки Microsoft Jet должны давать оцен ку True для проверяемой величины. Ограничения CHECK сервера SQL Server не должны давать оценку False. Это важно: как True, так и Null являются для CHECK значениями, для правил проверки Microsoft Jet приемлемо только True.

Кроме того, для одного поля можно определить много ограниче ний CHECK. Фактически, одно правило и любое ограни чений CHECK можно применить для одного поля в SQL Server, в то время как поле в Microsoft Jet имеет единственное свойство Vali dation Rule. Кстати, использование свойства в Microsoft Jet позволяет возвращать в клиентское приложение сообщение об ошибке. Microsoft Access показывает текст в окне сообщений, и этот текст доступен в Microsoft Visual Basic и других средствах программи рования через обработку строковых величин в коллекции объектов Errors.

Ограничения на уровне сущности, которые ссылаются на множе ство столбцов одной таблицы, реализуются в качестве правил про верки на уровне таблицы в Jet и табличных ограничений CHECK в SQL Server. Несмотря на что объявляются они в другом месте, такие ограничения на уровне таблиц функционируют точно так же, как соответствующие ограничения на уровне полей.

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

все другие правила в основном представляют со бой то, на что ссылаются как на ограничения целостности на уровне сущности. Microsoft и SQL Server ограничения уни кальности, но разными способами. Оба продукта реализуют ограни чение, используя индексы, но SQL Server скрывает это от теля. Создает ли сервер индекс явным образом (Microsoft Jet) или объявляет ограничение (SQL Server) — это технические детали.

ЧАСТЬ 1 баз И Microsoft и SQL Server поддерживают наборы полей. Оба также поддерживают первичные ключи, состоящие из не скольких полей, что подразумевает такого набора. Для таблицы может быть определен только один ключ, порой состоящий из нескольких полей. Ограничений уникальности может быть сколь ко угодно.

Еще одно важное различие между ограничениями уникальности и первичными ключами: уникальные индексы могут содержать Null, a первичные ключи — нет. Серверы баз данных обрабаты вают Null в уникальных индексах. Microsoft Jet поддерживает свой ство который предотвращает добавление информации о записях, содержащих Null в индексных полях, в индексы. Записи до бавляются в но содержимое индекса не изменяется. Эта воз можность не реализована в SQL Server.

Кроме того, SQL Server разрешает добавить в таблицу только одну запись, содержащую Null в поле. Это логически не оправдано, так как позволяет рассматривать записи, содержащие как одинаковые, хотя они, конечно, таковыми не являются. Null не эквивалент чего бы то ни было, не исключая «другого» Интересно, что ни Microsoft Jet, ни SQL Server не требуют обяза тельного определения первичного ключа для таблицы или даже су ществования уникального набора полей. Другими словами, можно создавать таблицы, которые не являются отношениями (кортежи в отношениях должны быть уникальны, а записи в таблицах — не зательно). Почему разработчики остановились на этом решении, я не понимаю, но такая возможность существует.

SQL Server также обеспечивает процедурные механизмы обеспече ния целостности на уровне сущности, чего не может Microsoft Jet.

(triggers) — это небольшие элементы кода (на языке для SQL Server), которые автоматически выполняются, когда происхо дит определенное событие. Для каждого события INSERT, UPDATE, или DELETE можно определить множество триггеров, и один триггер может быть определен для нескольких событий.

Ссылочная целостность Хотя Microsoft Jet и SQL Server поддерживают ссылочную целостность практически одинаковым образом, они используют для этого различ ные парадигмы.

SQL Server позволяет объявлять внешние ключи на уровне опре деления таблицы. Ограничение внешнего ключа задает ссылку на ключ кандидат другой, ссылочной таблицы. Когда ссылка определена, SQL ГЛАВА Server создание «осиротевших» записей, отменяя опе вставки, если такой записи не соответствует ни одна запись в ссылочной таблице.

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

Microsoft Jet поддерживает ссылочную целостность, используя объект внутри базы данных. Терминология Microsoft здесь неуместна — объект в Microsoft Jet является физическим представлением связи между двумя сущностями. Не путайте объект Relation с логическими отношениями, которые определяются в ли данных.

всего создать объект Relation, используя интерфейс базы данных Access (с помощью команды Relationships в меню Tools), но это можно сделать и программным способом. Свой ства Table и Table Relation библиотеки Data Access Object (DAO) определяют две таблицы, участвующие в то вре мя как набор объектов Fields определяет для каждой из таблиц поля, по которым устанавливается связь.

Способ, которым Microsoft Jet будет поддерживать ссылочную це лостность для отношения, определяется через свойство Attributes от ношения:

• — связь «один к одному»;

• — связь не установлена (не поддерживается ссылочная целостность);

• — связь существует в другой базе данных, кото рая содержит две связанные таблицы;

• — поддерживается каскадное обновление;

• — поддерживается каскадное удаление.

Обратите внимание на флаги dbRelationUpdateCascade и Delete Cascade. Если определен флаг для обновления и ссылочное поле изменяется, Microsoft Jet автоматически обновит поля в связан ной таблице.

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

ЧАСТЬ 1 баз Другие виды целостности В модели данных мы определяем три дополнительных вида ности: базы данных, преобразования и транзакции. Некоторые огра ничения достаточно просто объявить с помощью пра вил проверки. Большинство их, тем не менее, как и все ограничения базы данных и транзакции, реализуют процедурно. Для баз данных SQL Server это означает применение триггеров. Microsoft Jet не под держивает триггеры, эти ограничения нужно реализовать в клиентс ком приложении.

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

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

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

Реляционная алгебра ГЛАВА Отношения могут быть базовыми или производными. В предшеству главах мы дали определение базового которому со ответствует представление в базе данных. Производное отношение (derived relation) — это отношение, определяемое через другие отношения, а не через атрибуты. Реляционная позво ляет создавать различные виды производных отношений.

На схеме базы данных базовое представлено Производные отношения существуют в виде представлений (views) в Microsoft SQL Server и запросов (queries) в механизме СУБД Microsoft Jet. Я буду термин «представления» для обозначения этих понятий, поскольку этот широко применяется в реляционной а также термин «набор записей* (в основном, когда речь пойдет о запросах или представлениях).

в терминах реляционных операций, которым эта глава. Microsoft Access и SQL Server Enterprise предоставляют графический интерфейс для создания пред ставлений. Однако представления можно также создавать при помо щи операторов SQL SELECT.

SQL (читается как — это язык структурированных сов (Structured Query для опи реляционных операций. Microsoft Jet и SQL Server поддержи специфичные, несколько отличающиеся Друг от друга, диалек ты SQL. Впрочем во всем, что касается реляционной разли чия минимальны. В этой главе мы обсудим вопросы алгебры, и там, где синтаксис версий SQL будет я приве ду примеры для обоих вариантов.

Оператор SELECT — это очень мощное средство, однако пользо им не так просто, как кажется на первый взгляд. Я не буду ЧАСТЬ 1 Теория данных подробно описывать этот оператор и углубляться в его применения, а приведу в качестве примера его простейшую структу ру. Вот синтаксис оператора SELECT:

SELECT FROM JOIN WHERE GROUP BY HAVING ORDER BY <Список_полей> в операторе SELECT - это список, из одного или более полей, которые будут включены в результирую набор записей, оператором. Поля могут быть взя ты из нижележащих наборов записей либо вычислены.

в выражении FROM — это, как вы, наверное, уже догадались, перечисление таблиц и представлений, па которых осно вывается оператор SELECT. Ключевые слова SELECT и FROM обя зательны для SELECT, все остальные ключевые сло ва — нет.

Оператор JOIN определяет связь между наборами записей, пере численными в <списке_наборов_записей>. Более подробно об опе раторе я расскажу в этой главе. Ключевое слово WHERE логическое выражение ограничи вающее число записей, которые будут включены в результирующий набор. Об условии WHERE мы также подробно поговорим далее.

Оператор GROUP BY объединяет в одну те записи, в которых ука занные поля имеют одинаковые значения. Ключевое слово HAVING используется для задания критериев отбора записей, полученных в результате выполнения оператора GROUP BY. Опера тор ORDER BY сортирует набор записей в том порядке, в котором они указаны в Значения Null (еще раз о трехзначной логике) Для выполнения большинства реляционной алгебры ис пользуются логические операторы, то есть операторы, возвращающие, как правило, булевы значения — True или Я не оговорилась, ког да «как правило», поскольку значения используемые в реляционной модели, существенно усложняют дело.

Null — особые значения, используемые наряду с булевыми. По этому вам придется иметь дело с тремя значениями — True, False и ГЛАВА 5 алгебра Null. Это объясняет происхождение термина трехзначная логика. Зна чения известных логических операторов трехзначной логики при водятся в табл.

Табл. Значения логических операторов And, и для трехзначной логики AND True False True True False Null False False Null Null Null Null OR True False Null True False True False Null Null Null Null Null XOR True False Null True False True Null True Null Null Null Null Null Проанализировав табл. 5-1, легко заметить, что результатом вы полнения любой логической над Null и любым другим зна чением False или Null) является В виде формулы это мож но выразить так: OP любое_значение = Null, где OP — логичес кий оператор. Это же правило выполняется и для логических опера сравнения (табл. 5-2).

Табл. 5-2. Логические значения операторов сравнения (= и ?) для трехзначной логики True False True True False Null False False Null Null Null Null Null ? True False Null True True False True False Null Null Null SQL Server обрабатывает трехзначную логику неоднозначно. В до полнение к стандартному режиму обработки трехзначной логики, он ЧАСТЬ 1 баз предоставляет «расширение» стандартных логических операций.

Если стандартный режим обработки трехзначной логики NULLS) отключен (SET OFF), то результатом ции будет True, а результатом операции Null = — любое значе ние, кроме будет False. (Несомненно, это связано с тем, что для уникальных индексов SQL Server присутствие в каждом индексе единственного значения Null).

Для обработки значений Null в SQL два унарных опе ратора — IS NULL и IS NOT NULL. Результаты выполнения этих операторов над различными значениями показаны в табл. 5-3. Как и в примере, — это любое чение, кроме Null.

5-3. Значения операторов IS NULL и IS NOT NULL Is Is Not Null False True True False False True Null True False Реляционные операторы Мы знакомство с операторами реляционной алгебры с четы рех типов таких операторов: ограничение (restriction), проекция (pro соединение (join) и деление (divide).

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

Оператор соединения — это один из основных операторов в реляци онной модели, он задает правила объединения двух наборов записей.

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

ГЛАВА 5 алгебра Ограничение Оператор ограничения только те записи, которые удов летворяют заданному критерию выборки. Он реализуется при помо щи выражения WHERE оператора SELECT, например:

SELECT * FROM Employees WHERE Для базы данных этот оператор возвращает запись, от носящуюся к сотруднику Нэнси Даволио (Nancy Davolio), поскольку однофамильцев в этой компании у нее нет (символ подставленный вместо списка полей оператора SELECT, означает «все Критерий выборки, задаваемый в условии WHERE, может быть сколь угодно сложным. Допускаются операции AND и OR над логи ческими выражениями. Выражение проверяется для каждой отдель ной записи из набора. В результирующий набор включаются все за писи, для которых результатом проверки условия WHERE будет True.

Записи, для которых результат проверки условия WHERE — значе ние Null, не включаются в результирующий набор.

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

Эта операция выполняется в SQL простым перечислением полей в оператора SELECT. В результирующий набор за писей включаются только те поля, которые есть в списке. Например, чтобы получить список сотрудников компании, можно использовать следующий оператор:

SELECT Extension FROM ORDER BY LastName, Оператор ORDER BY сортирует данные. В нашем примере полу ченный список будет отсортирован в алфавитном порядке: сначала по полю LastName, затем по Соединение Операции соединения, пожалуй, наиболее распространены из всех ре операций. Вряд ли я переоценю их значение, если скажу, что эти составляют фундамент реляционной модели — ведь без них декомпозиция данных не имела бы никакого смысла ЧАСТЬ 1 баз данных невозможности вновь соединить данные, разбитые на множество от ношений. Оператор соединения как раз и выполняет эту работу:

объединяет наборы записей, на сравнении значений од ного или нескольких их полей..

Соединения реализуются при помощи оператора в операто ре SELECT. В зависимости от типа сравнения полей, указываемых в а также от каким образом обрабатываются результа ты сравнения, соединения можно разделить на несколько видов. Рас смотрим каждый из них.

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

Рассмотрим типичный случай связанных таблиц, полученных в результате процесса нормализации. — первичный ключ таб лицы Orders и внешний ключ таблицы Order Details (рис. 5-1).

Orders OrderlD Employee ID ShipVia 5-1, Эти соединить, используя JOIN Чтобы соединить (и таблицы, используйте следующий оператор SELECT:

SELECT OrderlD, [Order FROM Orders INNER JOIN [Order Details] ON = [Order WHERE ГЛАВА 5 аягебра II] После выполнения этого оператора вы получите набор записей, показанный на рис. 5-2.

VINET Рис. 5-2. Этот набор записей является соединения таблиц Orders и Order Details ПРИМЕЧАНИЕ Если вы выполните этот запрос к базе данных Access 2000, то в наборе результатов увидите имя клиента, а не его иден тификатор В Access возможность отображать не то, что непосредственно хранится в полях если при создании таб лицы использовался элемент управления, позволяющий просматривать и преобразовывать значения (lookup control). Это, несомненно, облегчает интерактивную работу с Access, однако может доставить много дополни тельных трудностей тем, кто хочет с помощью этой базы данных проил люстрировать выполнение какого-либо оператора.

Естественные соединения Естественные соединения (natural joins) — это частный случай эквисо единений;

соединения, удовлетворяющие следующим условиям:

• основаны на операторе равенства;

• в них участвуют все общие поля;

• в результирующий набор записей включен только один набор об щих полей.

Естественные соединения ничем не выделяются среди остальных видов соединений — они не представляют собой особых случаев об работки данных, и механизм СУБД не предусматривает для них спе циальной поддержки. Это всего лишь наиболее распространенный вид соединений, что отражено в их названии.

Один особый случай естественных соединений достаточно инте ресен с точки зрения его обработки механизмом СУБД Microsoft Jet.

Если между двумя таблицами существует связь «один ко многим», и включенные в представление, находятся на стороне «многие» этой связи, механизм СУБД Microsoft Jet выполнит стан дартную автоматического исправления записей (Row Fix Up или Если в курсоре используются поля, которые со держатся в критерии соединения, механизм СУБД Microsoft Jet авто матически общие поля — эффектный «трюк», весьма об легчающий жизнь программистам.

ЧАСТЬ 1 реляционных данных Формально все соединения являются если соединение на операторе равенства, его обычно зывают или просто соединением. ос нованное на другом операторе кроме равенства называется На встречаются редко, одна ко они представляют собой очень и изящный метод реше ния определенных Как правило, эти задачи с поиском записей, для которых значение некоторых полей превосхо дит или значение, либо записей, которых зна чение некоторых полей укладывается в определенный диапазон.

Предположим, создали два представления, одно из содержит среднее единиц проданного товара для каждой кате гории товаров (рис. 5-3). Далее в этой расскажу, как создать такое же просто договоримся, что оно уже су ществует.

Condiments Dairy _ Produce................... 2;

4 • 5 Chef Mix Grandma's 7 Bob's Organic " ГЛАВА Этот оператор SELECT, на операторе сравнения получить список продуктов, лидирующих по продажам в каждой категории:

SELECT ProductCategoryAverages INNER ProductTotals ON = CategorylD AND > Результат выполнения этого оператора показан на рис. 5-4.

Beverages Steeleye Stout Beverages Outback Lager Beverages Beverages Chef Cajun Malacca Condiments Simp Condiments Fiery Hot Sauce Condiments Frankfurter Confections 5-4. Набор записей В приведенном примере представление можно создать, использо вав условие WHERE в операторе выборки. Но на самом деле Access изменит синтаксис SQL-запроса, если вы оставите его в таком виде:

SELECT DISTINCTROW FROM ProductCategoryAverages INNER JOIN ProductTotals ON = WHERE С технической точки зрения, все соединения, в том числе эквисо единения и естественные, можно переформулировать, переписав в виде операторов SELECT с ограничениями. (С точки зрения баз данных, тета-соединение не является атомарным В случае тета-соединений, такая формулировка запро ЧАСТЬ сов предпочтительна, так как механизмы СУБД лучше оптимизируют выполнение запросов, Внешние соединения До сих пор мы рассматривали внутренние соединения, то есть соеди нения, записи, для которых выполняется условие со единения (результат выполнения соответствующей логической опе рации — значение True). Часто внутреннее соединение определяют как операцию, возвращающую записи, у которых совпадают значе ния определенных полей. Однако это не так: данное определение предполагает, что соединение основывается на операторе равенства, а как мы видели, далеко не для всех соединений это утверждение справедливо.

В реляционной алгебре поддерживается также другой вид соеди нений — внешние соединения (outer joins). Внешнее воз вращает все записи, которые возвращает внутреннее соединение, плюс все записи из одного или обоих наборов данных, участвующих в соединении. значения (те, для которых не существу ет соответствия) замещаться значениями Внешние соединения разделить на несколько групп: левые, правые и полные — в зависимости от того, какие именно дополни тельные записи включены в них. Левое внешнее соединение (left outer join) возвращает все записи из отношения, находящегося на стороне связи «один ко многим», а правое внешнее соединение (right outer join) — все записи из отношения, на стороне такой связи. В механизме СУБД Microsoft Jet и SQL Server порядок, в котором наборы записей перечисляются в операторе SE LECT, различается для левого и правого внешнего соединения. Так, два оператора возвращают все записи из таблицы X, а так же те записи из таблицы Y, для которых значение логического выра жения <условие> — True:

SELECT FROM X LEFT JOIN Y ON <услозие> SELECT - FROM Y RIGHT CUTER X ON Полное внешнее соединение (full outer join) возвращает все записи из обоих наборов, комбинируя те, для которых выполняется условие данного соединения. В SQL для полного внешнего соединения используется следующий оператор:

SELECT * X FULL OUTEP JOIN Y ON ГЛАВА Механизм СУБД Microsoft Jet не предоставляет прямой поддерж ки полных внешних соединений, однако выполнив операцию объе динения левого и правого внешних соединений, можно получить набор аналогичный полному внешнему соеди нению. мы подробно рассмотрим в одном из следующих разделов.

Деление Последний из рассматриваемых реляционных операторов — реляци онное деление. Этот оператор (названный так для того, чтобы отличать его от математического деления) возвращает те записи из первого набора, которые совпадают с записями из другого набора.

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

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

Формулировку «список поставщиков, поставляющих продукты всех трудно реализуемую средствами стандартного SQL запроса, можно заменить эквивалентной;

«список поставщиков, для которых число поставляемых ими категорий продуктов равно числу всех категорий продуктов». Это пример операции расширения, о ко торой мы подробно далее. Данный метод, однако, не все гда применим, и там, где он не реализуют реляционное деление, как правило, при помощи связанных запросов (correlated queries). Связанные запросы мы рассматривать не будем. В библио графическом указателе в конце книги есть несколько ссылок на ли тературу, где связанные запросы обсуждаются достаточно подробно.

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

ЧАСТЬ 1 баз данных Объединение Реляционное объединение union) — это результат выполне ния операции над двумя наборами записей. Эту опера цию можно представить как реляционную сложения (разу меется, данное утверждение не совсем точно). Результат операции объединения набора записей А и набора записей В простое добав ление записей из набора А в набор В.

Например, нужно составить список всех хранящихся в базе данных, для рассылки почтовых сообщений. В базе данных наборы записей Customers и Employees содержат ад реса покупателей и компании, поэтому список всех адресов, хранимых в базе данных, можно получить, вы полнив операцию объединения над двумя этими наборами записей.

Для этого мы используем оператор UNION:

AS Address, PostalCode FROM Customers UNION SELECT ft & [LastName] AS Address, PostalCode FROM Employees BY name;

Поле CompanyName было переименовано в а над полями FirstName и таблицы Employees выполнена операция конка тенации. Поле, полученное в результате конкатенации, также назы вается Name. Для запроса, выполняющего объединение, совсем не требуется, чтобы все поля в каждого оператора SE LECT имели одинаковые имена. Нужно только, чтобы в каждом зап росе было одинаковое число полей и чтобы типы этих полей были одинаковыми совместимыми). Результаты выполнения объеди нения в Access показаны на рис. 5-5.

Obere 57 Ana у de la 2222 W Capital Way Anne 7 F'd Anlonio Moreno Taqueria Mataderas Around the 120 Sq Berglunds I preparadas Bon -12, rue des 5-5. Оператор UNION объединяет записи из таблиц ГЛАВА Пересечение Операция пересечения (intersection operator) возвращает записи, общие для двух наборов. Очевидно, что пересечение можно для поиска записей, что и происходит чаще всего. Пере сечение реализуется при помощи внешних соединений, Рассмотрим такой пример. Есть несколько списков клиентов, по лученных из разных источников — старых систем (рис. 5-6). Как правило, в таких таблицах есть повторяющиеся записи.

' Alfreds ANATR Emparedados у ANTON Moreno Around the BERGS See Delikatessen Blondel Ana у helados ANTON Moreno AROUT Around the Horn FISSA FISSA Inter.

5-6. Таблица с повторяющимися Оператор SELECT возвратит повторяющиеся записи:

SELECT FROM DuplicateCustomersI LEFT JOIN ON AND WHERE IS NOT ЧАСТЬ Результаты выполнения этого оператора показаны на рис. 5-7.

•4 ! ! I Ana у ANTON Antonio Moreno Around the Horn 5-7, Внешнее в с оператором IS NOT NULL выполняет операцию пересечения Разность Операция пересечения используется для поиска повторяющихся за писей, а операция разности — наоборот, для поиска уте рянных (осиротевших) строк. Реляционная разность diffe rence) для двух наборов записей будет содержать все записи, которые принадлежат к одному набору записей, но не принадлежат к другому.

Например, для двух наборов записей на рис. 5-6 следующий опе ратор SELECT возвратит все записи, не являющиеся общими для этих двух наборов записей:

SELECT FROM LEFT ON AND = IS NULL);

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

Если описанный способ кажется вам слишком сложным, попро буйте выполнить эту операцию в два шага;

сначала создайте соединение как представление, а затем ограничьте число записей, задав условие WHERE (рис. 5-8).

ГЛАВА Шаг Создать внешнее соединение Ana у ANTON BERGS See fiis Select LEFT JOIN ON = Шаг 2. Ограничить число записей теми, которые содержат Null в Blauer See Delikatessen et Select FROM DuplicateCustomersl LEFT ON = WHERE CustomerlD) IS NULL Операцию можно выполнить в два шага Декартово произведение Последняя из рассматриваемых операций над множествами — декар тово произведение. Как и аналогичная операция в классической тео рии множеств, декартово произведение двух наборов записей пред ставляет собой соединение каждой записи из одного набора записей с каждой записью из другого набора.

Декартово произведение (называемое также просто произведени двух наборов записей составив оператор SELECT без оператора JOIN. Например, объединить записи о каждом из покупа телей с соответствующими записями о торговых представителях, об служивающих покупателей, можно образом:

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

например, если, программируя на Access, вы забудете ЧАСТЬ 1 баз чить в SQL-запрос соединение. Подобные ошибки часты, поэтому на первых порах не удивляйтесь, если вместо ожидаемого результата у вас будет получаться декартово произведение.

Дополнительные реляционные операторы С тех пор как впервые были сформулированы принципы, положен ные в основу реляционной модели, прошло достаточно много време ни. Появились некоторые дополнительные операции, расширившие рамки реляционной алгебры. Мы рассмотрим три такие операции, наиболее часто на практике: агрегирование (summa rize), расширение (extend) и переименование (rename). Кроме того, я опишу три дополнительных оператора, поддерживаемых продуктами Microsoft: TRANSFORM, ROLLUP и CUBE.

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

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

Операция агрегирования реализуется при выражения GROUP BY оператора SELECT. Для каждого уникального значения указанного поля или нескольких полей возвращается одна запись.

Если указано несколько полей, группы будут рим следующий оператор:

SELECT AS FROM INNER Products ON = INNER JOIN [Order Details:

ON = [Order GROUP BY Этот оператор возвращает по одной записи для каждого продукта в БД сгруппированные по категориям и содержащие три поля: CategoryName, и (число для каждого продаваемого товара), как показано на рис. 5-9.

Поля, перечисленные в оператора SELECT, должны либо входить в либо являться аргументом агрегатной функции SQL. Агрегатные функции SQL (SQL aggregate functions) вычисляют суммарные значения для ГЛАВА 5 алгебра каждой записи. Наиболее широко используются агрегатные функции AVERAGE, SUM, MAXIMUM и MINIMUM.

. здймуодш.

i Chartreuse Beverages de Beverages Lumberjack Beverages Outback Lager Beverages Ale Steeleye Stout Condiments Aniseed Syrup i 5-9. Оператор BY возвращает агрегированные данные Агрегирование — это еще один «камень преткновения», где чения Null могут доставить дополнительные неудобства. Значения участвуют в агрегированных значений — они обра зуют группу. Однако значения игнорируются агрегатными функ циями. Как правило, это единственная проблема, возникающая, если использовать поле из в качестве параметра агрегатной функции.

Расширение Операция (extend) позволяет задать виртуальные поля, значения которых вычисляются на основании констант, хранимых в базе данных, но не хранятся в базе данных как определенные значе ния, записываемые в файл БД на физическом уровне. Чтобы создать виртуальное поле, можно просто задать формулу для его вычисления в оператора SELECT, например:

SELECT AS FROM [Order Вычисления, на которых основываются определения виртуальных полей, могут быть как сложными, так и простыми. Как правило, они выполняются настолько быстро, что хранить значения вычисляемых полей в таблице бессмысленно.

Переименование И наконец, последняя из рассматриваемых здесь дополнительных операций — переименование (rename). Операция переименования жет выполняться как над набором записей из ЧАСТЬ 1 данных писей>, так и над отдельными полями из <списка_полей>. В меха низме баз данных Microsoft Jet используется следующий синтаксис для переименования набора записей:

SELECT AS FROM SELECT FROM записей> Переименование полей применяется, как правило, когда создается представление или выполняется самосоединение таблицы, например;

SELECT FROM Employees AS Employee INNER JOIN Employees AS Manager ON Этот синтаксис позволяет разделить на логическом уровне каж дый из вариантов использования поля.

Оператор TRANSFORM Оператор TRANSFORM — это одно из расширений, добавленных Microsoft коперациям реляционной алгебры. Оператор TRANSFORM выполняет операцию поворота на 90" над результатами операции аг регирования (GROUP Этот оператор часто называют кросс-таб личным запросом (crosstab query), он поддерживается механизмом баз данных Microsoft Jet, в SQL Server до сих пор не реализован.

Вот синтаксис оператора TRANSFORM:

TRANSFORM SELECT FROM GROUP BY PIVOT [IN Оператор TRANSFORM определяет агре гированные данные, которые войдут в набор записей. Оператор SE LECT должен содержать выражение GROUP BY, но в нем недопус тимо выражение HAVING.

может включать несколько полей. (В операторе TRANSFORM <спи ГЛАВА 5 алгебра сок_полей> и как правило, совпадают).

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

Сравнив результаты выполнения оператора TRANSFORM из сле дующего примера с результатами выполнения операции агрегирова ния (рис. 5-9), можно убедиться, что они практически AS ID SELECT FROM Suppliers INNER JOIN (Categories INNER JOIN Products ON = ON = GROUP BY PIVOT Результат выполнения этого оператора показан на рис.

Рис. 5-10. TRANSFORM выполняет поворота на над результатами операции агрегирования Оператор ROLLUP Операция агрегирования, реализованная при помощи оператора GROUP BY, генерирует записи, которые содержат агрегированные данные. Оператор ROLLUP — это логическое расширение операции ЧАСТЬ 1 Теория баз данных GROUP BY, получить суммарные значения. Он поддер живается только SQL Server:

SELECT AS FROM INNER JOIN Products ON INNER JOIN [Order Details] ON [Order BY WITH На рис. показан результирующий набор записей, полученный после выполнения этого оператора.

Chartreuse Cote de Laughing Lager Outback Lager Ale eye " eye Condiments Aniseed Syrup 5-11. Оператор ROLLUP позволяет суммарные значения Как видите, набор записей на рис. фактически тот же, что и на рис. 5-9, к лишь добавлены дополнительные записи. Записи, где есть значения Null (одна из таких записей показана на рис.

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

Оператор CUBE Оператор CUBE, как и ROLLUP, реализован только в SQL Server как расширение оператора GROUP BY. Оператор CUBE агрегирует каж дый столбец в по всем осталь ным столбцам. Концептуально оператор CUBE похож на ROLLUP, но в отличие от него, вычисляет суммарные значения для дополни тельных групп, а не значения для каждого столбца, пере численного в ГЛАВА 5 Реляционная Предположим, что состоит из трех полей — А, В, и С. Тогда оператор CUBE вернет следующие семь агрегированных значений:

• суммарное значение для всех значений столбца С;

• суммарное значение для всех значений столбца С, сгруппирован ных по А;

• суммарное значение для всех значений столбца С, сгруппирован ных по С в А;

• суммарное значение для всех значений столбца С, сгруппирован ных по В в А;

• суммарное значение для всех значений столбца С, сгруппирован ных по В;

• суммарное значение для всех значений столбца С, сгруппирован ных по А в В;

• суммарное значение для всех значений столбца С, сгруппирован ных по С в В.

Итоги Эта глава была посвящена различным операциям над базовыми от реализованным при помощи операторов и расширений этих реализованных в языке SQL. Кроме того, мы обсудили некоторые особенности реляционных операторов и их расширений, связанные с трехзначной логикой и значениями Null.

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

Кроме того, мы рассмотрели несколько дополнительных операто ров. Агрегирование и расширение относятся к операциям, выполняю щим различные вычисления с данными. Переименование позволяет ввести заголовки столбцов, отображаемые в проекции. Операторы TRANSFORM, и CUBE — это расширения языка SQL, реа лизованные Microsoft. Каждый из этих операторов представляет со бой отдельный способ агрегирования и представления данных.

Итак, этим обзором реляционной алгебры мы завершаем первую часть книги. Реляционная теория достаточно сложна, и конечно, я ЧАСТЬ осветила не все ее вопросы. Подробное рассмотрение реляци онной теории баз выходит за рамки этой книги, однако все основные положения этой теории изложены в первых пяти главах.

Далее мы перейдем к практическим аспектам разработки СУБД и пользовательского интерфейса.

ЧАСТЬ Проектирование реляционных систем баз данных Процесс проектирования ГЛАВА В первой части книги мы рассмотрели основные принципы проекти рования реляционных баз данных. Однако структура данных — это критически важная, но все-таки всего лишь одна из многих базы данных. Рассмотрим другие аспекты проектирования базы данных.

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

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

Модели жизненного цикла До последнего времени системные аналитики использовали в своей работе парадигму, известную как модель водопада. Существует не сколько реализаций такой модели, один из наиболее простых изоб ражен на рис. 6-1.

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

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

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

Модель не также вносить изменения в бизнес требования на этапе создания системы. Но полагать, что система, которая удовлетворяла всем бизнес-требованиям в начале проекти рования, будет все еще удовлетворять им в конце двухлетнего перио да разработки — безрассудство. Заказчику совсем не понравится, если ЧАСТЬ 2 систем баз вы поставите ему систему, которую нельзя даже если вы уложитесь в сроки и бюджет.

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

Есть несколько альтернативных моделей. Спиральная модель пред лагает осуществлять итерации, то есть каждая последующая стадия позволяет уточнить результаты (рис. 6-2).

Окончание Выпуск версии системы Выпуск окончательной Проектирование версии системы Начало системы проекта Составление бюджета Составление бюджета Рис. 6-2. Спиральная Недостаток спиральной модели в что нельзя предвидеть из менения, которые возникнут на поздних стадиях разработки — а они, вполне вероятно, могут сделать бесполезной всю предыдущую работу. Результат — перерасход бюджета и разочарованные разработ ГЛАВА б Процесс чики. Такая крайне опасна для проектов баз где расширение требований может изменить семантику данных, а изме нения в схеме базы данных — повлечь за собой изменения, катастро фические для системы в целом.

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

Предварительный анализ Детальное Выпуск версии системы Рис. 6-3. Эволюционная разработка В этой модели, которая чаше всего является просто вариантом спиральной модели, предварительный анализ выполняется для сис темы в целом, а не для ее части. За этим следует проектирование ар хитектуры — опять же для системы в целом. Цель этого этапа — оп ределить отдельные компоненты, которые можно реализовать более или менее независимо от остальных системы, а затем описать зависимости и способы взаимодействия этих компонентов.

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

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

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

А ведь кроме того, есть вероятность, что компонент ActiveX так никогда и не будет реализован: не выделят денег на его создание, или вы обнаружите, что он не нужен. Тогда придется создать компонент, чьей единственной функцией будет поддержка работы других компо нентов. Не очень элегантное решение, и вам определенно не захочет ся рассказывать об этом специалисту по технической поддержке.

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

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

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

Определение параметров системы В идеале, необходимо ясно представлять: чего, зачем и как вы хотите достичь. Формулирование проекта — самая первая стадия со здания системы. Определив цель проекта, вы сможете четко очертить его то есть обозначить задачи, которые нужно решить в ходе проекта. Тогда станут яснее способы реализации, то есть как вы бу дете создавать систему. Все этих аспекты: цели, задачи, средства, обсуждаются в главе 7.

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

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

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

Подготовка схемы базы данных Схема базы данных является, по сути, переводом логической модели данных на язык физической реализации. Она включает описание таб которые будут созданы в системе, а также физическую структуру данных. Физические структуры данных и схемы баз данных подроб но обсуждаются в главе 10.

Проектирование пользовательского интерфейса Независимо от того, насколько технически совершенна ваша систе ма, если пользовательский интерфейс выполнен грубо, непонятен или неудобен, проект вряд ли будет успешен. Все-таки для большинства ЧАСТЬ 2 данных пользователей именно интерфейс является системой, с которой они работают. Проектирование пользовательского интерфейса обсужда ется в части 3.

Замечания о стандартах и проектирования Я не большая поклонница четко очерченных методов проектирова ния компьютерных систем. По-настоящему хорошо спроектирован ные системы — это где аналитик с самого начала активно включа ется в работу с пользователями.

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

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

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

Определение параметров системы ГЛАВА «Любая система для решения а отнюдь не всех задач». Эти слова принадлежат Роберту Холлу (Robert Hall), сотруд нику известной американской компании «North American Говорят, что эту фразу Роберт Холл в разговоре с вице президентом пытавшимся расширить границы его проек та сверх разумных пределов, и это возражение едва не стоило Холлу работы. (В системном проектировании, как и в любой другой облас ти, следует учитывать, к какой аудитории вы обращаетесь). Как бы то ни было, я целиком разделяю мнение Холла о процессе разработки систем. Если вы намерены успешно выполнить свой про ект, то должны его рамки. Без четкого понимания, что имен но вы хотите сделать, серьезные трудности.

Итак, прежде чем к работе, определите параметры си стемы, а именно:

• цели — не то, создается данная система, а цели проекта как целого;

» — они будут использоваться в процес се оценки компромиссов (которые неизбежны при разработке и внедрении а также возможностей ее реализации;

• границы применения — какие функции будут реализованы в дан ной а нет.

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

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

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

Но отнюдь не это является целью создания данной системы. Цель — это фактор или набор факторов, необходимость ре ализации данного проекта.

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

Для повышения точности и сохранности вводимых Для сни жения накладных расходов? Чтобы поднять авторитет компании сре ди пользователей этой системы? Чтобы менеджер чувствовал, что «идет в ногу со временем»? Вполне вероятно, что в данном случае создание системы будет преследовать все эти цели, а также множе ство других.

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

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

Кроме того, может потребоваться уточнить несколько моментов, которые менеджеры по продажам и сотрудники отдела маркетинга, как правило, скрывают за неопределенными выражениями, напри ГЛАВА 7 Определение системы мер продукта» и «удовлетворение нужд и запро сов клиента». К счастью, это довольно легко — вы можете просто рас спросить об этом представителя фирмы — заказчика проекта.

Четко сформулировать цели очень важно — ведь потом вам при дется перевести их на язык простых и понятных исполь зуемых в процессе разработки. Порой достаточно всего лишь задать несколько дополнительных вопросов. Например, сформулиро ванная как «помощь в удовлетворении нужд и запросов клиента», обычно что в компании существуют проблемы с обслужи ванием клиентов, которые легко перевести на язык вполне опреде ленных критериев. Либо вовсе не учитывать, если они никак не свя заны с разрабатываемой системой или не могут быть решены с ее помощью.

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

Не все нечетко сформулированные цели легко перевести на язык вполне определенных критериев. Яркий пример — «позиционирова ние». Например, вас могут попросить создать Web-сайт, чтобы «по зиционировать компанию на уровне современных требований». По добные фразы, как правило, означают лишь то, что самого факта на личия системы достаточно для достижения цели. Это легко прове рить — просто спросите заказчика, каким образом можно определить, достигнута ли цель. В большинстве случаев окажется, что цель дос тигнута, когда достигнуты все цели, связанные с конкретными пара метрами — например, производительностью и функциональностью системы. И тогда нечетко сформулированные цели достигаются ав томатически.

ЧАСТЬ 2 баз данных Часто при постановке используют слова «увеличить» или «снизить». Говорят, например, что целью разрабатываемой системы является «повышение эффективности» и «увеличение производитель — согласитесь, довольно расплывчатая формулировка. Воп рос: «Как определить, что цель — выручит и здесь. Один клиент как-то рассказал мне забавную историю, наглядно демонст рирующую, сколь важны количественные критерии оценки выпол няемой работы для достижения адекватного результата. (Критерии, которыми пользуется разработчик, и критерии оценки выполненной работы во многом — ведь схожи и конечные цели, которым они служат). История такова: в начале своей карьеры, будучи торго вым агентом, рассказчик получал указания от менеджера. Менеджер объяснил молодому торговому агенту, что в его служебные обязанно сти входит «продвижение товаров и услуг компании». Выйдя за дверь, торговый агент начал громко выкрикивать нечто вроде «Покупайте наши товары, они самые качественные!» Очевидно, инструктируя подчиненного, менеджер имел в виду совсем не это.

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

Здесь вы снова можете столкнуться с неожиданными затруднени ями. Конечно, принцип, что каждая цель должна в конечном итоге быть выражена некоторой измеряемой величиной, звучит весьма убе дительно. Цель «уменьшить время, необходимое для обработки зака за, с 10 до 3 минут» гораздо более ясная, чем абстрактное «увеличе ние эффективности». Но в таком случае предполагается, что вам уже известно, сколько времени требуется для обработки заказа. А ведь выяснение этого может потребовать немало времени и сил. тому же нередко подобные исследования весьма недешевы и их стоимость превышает риск сделать ошибку. В случае, подобном тому, о котором мы сейчас говорим (автоматизация регистрации за казов) вряд ли стоит нанимать команду аналитиков, чтобы точно вы яснить, сколько времени занимает ввод заказа. А вот несколько лет назад я участвовала в проекте, где было потрачено около 50 тыс. дол ларов, чтобы определить, оправдано ли приобретение коробочного программного продукта по розничной цене 2,5 тыс.

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

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

Но вдруг результат, которого вам удастся достичь, будет отличать ся от того, на что ориентировался заказчик? Очевидно, если вас про вдвое сократить среднее время обработки заказа, то придется сде лать все возможное, чтобы достичь желаемого результата. Но если вы точно знаете, что на самом деле необходимо сократить время обра ботки лишь на 25%, то обстоятельства гораздо менее вас стесняют, и вы можете пожертвовать «чистой» производительностью, немного увеличив среднее время обработки заказа. Зато система будет удоб нее в эксплуатации или повысится ее надежность.

Вряд ли заказчики предъявят вам чрезмерные или невыполнимые требования, станут сознательно вводить в заблуждение или же в вину просчеты, в которых вы не виноваты. Но в любом случае вы обязаны помочь клиенту уяснить, какие проблемы разрабатывае мая система решит, а какие — нет. Программисты и аналитики часто считают, что жизнь была бы прекрасна, если бы заказчики точно зна ли, чего хотят. На самом деле, заказчики действительно знают, чего хотят, они не знают только одного — как перевести то, чего они хо тят, на язык компьютерной системы. Как раз в этом и заключается ваша Я также часто слышала о заказчиках, которые встречают вас с товыми набросками экранных форм и отчетов. В этом случае вам со общается уже готовое решение, а не сама проблема. Такая ситуация ЧАСТЬ 2 систем требует немало такта и терпения: нужно «нащупать» проблему, ни разу при этом не намекнув, что тот, кто рисовал эти экранные фор мы, либо полный профан, либо изначально выбрал неверный путь.

Я рекомендую нащупать брод, прежде чем переправляться через реку. Если заказчик упорно не желает отвечать на ваши вопросы, объясните ему, что ваша работа принесет пользу только в том случае, если вы вникнете в бизнес-процессы компании. Если же и это не по может, придется либо реализовать систему так, как того желает за казчик, либо отказаться от проекта (последнее, не всегда Самое большее, на что вы можете рассчитывать — это пе ресмотр готового которое вам предложили. Если вы обна ружите в нем серьезные обсудите их с заказчиком. Скажи те, например: «Я не могу этого сделать;

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

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

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

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

Когда мы обсуждали понятие «атомарные значения», я говорила, что в рамках определенной модели адрес может быть реализован в ГЛАВА 7 системы виде большого двоичного объекта — набора символов, которые про сто выводятся на печать при подготовке конвертов для массовой рас сылки, Реализация адреса как одного или атрибутов за висит от семантики системы, и при создании списка адресов для ме стного рок-клуба разумно реализовать адрес как один атрибут. Но если эти данные предполагается использовать еще, то ско рее всего, адрес будет представлен в виде нескольких атрибутов. Это усложнит систему, зато позволит избежать повторного ввода одной и той же Если вы действительно решили внести небольшие изменения, дует тщательно взвесить все и «против». Этот подход приемлем, только если не потребует значительных усилий по переделке систе мы, и если использование одних и тех же данных для разных целей действительно возможно. Я сталкивалась с не оптимально спланиро ванными системами, где пользователю приходилось вводить значи тельный объем данных, не имеюших прямого отношения к тому про цессу, в котором он непосредственно участвовал. А все из-за того, что эти данные, по всей вероятности, будут еще где-то.

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

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

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

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

ЧАСТЬ 2 баз данных Определение критериев разработки После того как обозначены все цели проекта, можно приступать к определению критериев разработки. Как правило, сохранить строгую последовательность изначально, не уда ется и критерии разработки частично будут определяться еше на эта пе определения Но мы, для простоты, договоримся, что у вас есть готовый список целей и теперь необходимо составить список критериев.

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

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

Как правило, критерии разработки формулируются в одной из сле дующих форм.

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

• внешним окружением, например «Система должна работать в существующей компьютерной сети».

• Основные разработки, например «Предоставление пользователю контекстно-зависимой справки».

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

ПРИМЕЧАНИЕ В какой бы форме ни выражались определяемые вами критерии, следует остановиться, как только они будут выполнены проект закончен, можно отдохнуть. На первый взгляд, совет тривиа лен. Но давайте рассмотрим конкретный пример. Представим себе, что вы оптимизируете фрагмент программного кода. Чтобы выполня лись критерии разработки, некоторая функция должна вычислять оп ределенное значение за время, не превышающее секунд. Вам уда ГЛАВА лось добиться того, что значение вычисляется за время, не щее 9 секунд, но вы уверены, что стоит приложить еше немного уси лий — и вы сократите время вычисления вдвое. Не делайте этого. Или если в этом возникнет необходимость, сделайте это позже. Как только система начала всем определенным критериям, все работы должны прекратиться, иначе вы никогда не за вершите проект.

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

На этой стадии проекта очень важно не к опреде ленному решению или архитектуре. Возможно, вы уверены, что буде те использовать Microsoft Transaction Server для обеспечения масшта бируемости системы, но это архитектурное решение, а не критерий разработки. Критерием разработки является то, что система должна поддерживать х пользователей одновременно.

Если у вас возникают какие-либо сомнения в правильности опре деления критериев разработки спросите себя, например, можно ли считать систему полностью завершенной, если вы будете использо вать Microsoft Transaction Server? Может быть и но о том, что сис тема полностью завершена, вы едва ли будете судить на основании того факта, что она реализована при Microsoft Transaction Server. Скорее всего, решение об окончании работ будет зависеть от ответа на другой вопрос: система успешно поддерживает одно временную работу х можно ли считать, что она завер шена?» Положительный ответ на этот вопрос, скорее всего, будет оз начать, что для данной системы выполняются и остальные критерии разработки.

Критерии, выражаемые в измеряемых единицах Я уже упоминала, насколько важно определить критерии, выражае мые в измеряемых единицах. Если вы успешно справитесь с этой за дачей, многие оставшиеся критерии определятся сами собой. Напри мер, если цель — сократить время вычисления в два раза, и на дан ный момент время вычисления составляет 10 минут, очевидно, что ЧАСТЬ 2 систем баз критерий разработки будет формулироваться так: «Обеспечить время вычисления, не превышающее Иногда сложно различить определяемые конкретными зна чениями параметров, и выражаемые в измеряе мых Однако я не помню случаев, чтобы подобная путани приводила к сколько-нибудь серьезным последствиям для проек та. Безусловно, никто не будет системной специфика где некоторая величина будет выступать одновременно и в ка честве цели, и в качестве критерия. Но если вы обнаружите, что для нескольких целей проекта, определяемых конкретными значениями системных параметров, не удается определить соответствующие кри терии, выражаемые в измеряемых это должно послужить сигналом, что в проектируемой системе, очевидно, что-то не так.

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

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

Очень важно правильно оценить объем обрабатываемых данных.

Однажды, работая независимым консультантом в региональном пред ставительстве компании, занимавшейся продажей компьютеров и к ним, я допустила серьезнейшую ошибку. Требова лось составить техническое предложение для разработки системы ре гистрации и учета числа продаж. Обсудив с заказчиком требования к системе, я составила предложение с описанием системы на основе Microsoft Access 2.0, позволяющей регистрировать число продаж в региональном представительстве. Но затем выяснилось, что нужно было разработать систему, позволяющую вести учет продаж в рамках всей компании, к тому времени насчитывавшей более ГЛАВА 7 Определение параметров системы представительств и имевшей оборот в несколько десятков мил лионов долларов — такую систему, очевидно, было невозможно реа лизовать при Microsoft Access 2.0. Я ошиблась, предположив, что заказчику требовалось лишь регистрировать и учитывать объемы региональных продаж. Полагаю, излишне говорить, что после этого фирма расторгла контракт со мной.

При оценке объема обрабатываемых данных следует внимание на два основных фактора. Первый — это «чистый» объем данных, а второй — объема данных и его динамика. На пример, в библиотеке находится несколько миллионов томов, но дый день ее фонд пополняется лишь несколькими книгами. Поэто му, хотя общий объем записей библиотечной картотеки весьма зна чителен, ежедневно в базу будет добавляться лишь несколько новых записей. Для системы заказов все может быть с точнос тью до наоборот. Каждый день в эту систему добавляется несколько сотен записей, однако архивироваться эти записи будут только после завершения фактических сделок, и таким образом общий объем данных не превысит нескольких тысяч записей. что основные направления разработки для этих двух систем будут ственно различаться.

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

Эти 10% будут использоваться для выполнения различных служебных операций по поддержке данных. Для систем меньшего масштаба сле дует предусмотреть «резерв» в от основного объема данных.

Чем больше масштаб системы, тем меньшую роль, как правило, иг рает объем данных. Хорошо спланированная клиент-серверная сис тема может поддерживать объемы и в и в тыс. записей без заметного изменения производительности. А вот распределенная многопользовательская система, реализованная на Access, рассчита на на поддержку лишь нескольких десятков тысяч записей, и, веро ятнее всего, вам не удастся масштабировать ее до нескольких милли онов записей, вне зависимости от того, насколько хорошо она спла нирована.

Основной фактор оценки критериев, определяемых внешним ок ружением — число пользователей системы. Для большинства систем важны несколько различных категорий пользователей, и очевид ЧАСТЬ 2 баз данных но, потребуется системные требования для каждой.

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

Число пользователей, подключенных к системе, и число пользо вателей, активно работающих с ней, как правило, существенно раз личаются, Например, механизм баз данных Microsoft Jet может под держивать не более 255 пользователей, одновременно подключенных к базе данных, то есть база данных может быть открыта не более чем 255 пользователями одновременно. Однако это не что все 255 человек смогут одновременно обновлять эту базу данных.

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

Но и игнорировать такие цели нельзя, их надо просто иначе сфор мулировать: не как выражаемые в измеряемых а как направления разработки. Например, так: «Повысить точность ввода данных, используя везде, где только возможно, не ввод данных вручную, а списки, из которых пользователь будет выбирать ние». Или так: «Снизить вероятность отказа в кредите, реализовав со ответствующие средства для проверки платежеспособности клиента перед принятием заказа».

Так же, как и при определении критериев, выражаемых в измеря емых единицах, при определении основных направлений разработки не следует слишком сильно углубляться в детали — ведь пока вы не занимаетесь собственно разработкой системы. В приведенных при мерах говорится, что использовать некоторый стандартный элемент интерфейса следует «везде, где это только возможно», и надлежит «ре ализовать соответствующие средства проверки возможности предос тавления кредита». Детали: где именно использовать стандартные эле менты интерфейса и как реализовать средства проверки кредитоспо ГЛАВА 7 Определение собности клиента, — будут определяться на более поздних стадиях проектирования системы, когда станут ясней требования к ней.

При определении основных направлений избегайте пустых фраз.

Конечно, сложно спорить с утверждением, что «Система должна быть разработана с учетом требований пользователя и предоставлять дру жественный интерфейс» — в концов, вряд ли пользователи бу дут рады получить систему с враждебным для них интерфейсом. Но эта фраза не содержит абсолютно никакой полезной информации. В то же время критерий должна быть разработана с учетом требований, изложенных в руководстве «Windows Interface Guidelines for Software Design» по разработке интерфейса для ставит перед разработчиком четкие грани цы, которых он должен Вопрос о том, предоставля ет ли система дружественный интерфейс, может оказаться спорным.

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

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

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

В некоторых случаях приходится переопределять цели системы:

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

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

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

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

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

Pages:     | 1 || 3 | 4 |   ...   | 6 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

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