WWW.DISSERS.RU

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

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

Pages:     || 2 | 3 | 4 | 5 |   ...   | 6 |
-- [ Страница 1 ] --

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

Р45 Основы реляционных баз с англ. — М.:

дом «Русская 2001. — 384 ил.

ISBN 5-7502-0150-3 Книга посвящена вопросам проектирования и внедрения современ ных компьютерных систем, с базами данных. Автор дит и теоретические и по разработке и нию таких систем. Содержится подробный анализ ситуаций, часто на практике. Особое внимание уделено созданию проектной документации, проектированию пользовательского интерфейса и блемам безопасности. В качестве примеров рассматриваются СУБД Microsoft.

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

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

УДК 32.973.26-018. Подготовлено к изданию по лицензионному договору с Microsoft Corpo ration, Редмонд, Вашингтон, США.

ActiveX, Microsoft, Microsoft Press, Outlook, PowerPoint, Visual Basic, Visual SourceSafe, Visual Studio и Windows являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft США и/ или других странах. Все другие товарные знаки являются собственнос тью фирм.

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

© Оригинальное издание на языке, Ребекка Райордан, © Перевод на русский язык, Microsoft Corporation, ISBN 0-7356-0634-Х (англ) © Оформление и подготовка к изданию, издатель ISBN 5-7502-0150-3 дом «Русская 200!

Оглавление Предисловие XIII От автора XVI Введение XVII О прилагаемом к книге XIX Часть Теория реляционных баз данных Глава Основные понятия Что такое база данных Инструменты работы с базами данных Механизм СУБД Объектная модель доступа к данным Средства для разработки клиентской части приложений Реляционная модель Термины, используемые в реляционной теории Модель данных Сущности Атрибуты Домены Связи Диаграмма «сущности - Итоги..... Глава 2. Структура базы данных Основные принципы Декомпозиция потерь Ключи-кандидаты и первичные ключи Функциональная зависимость Первая нормальная форма Вторая нормальная форма Третья нормальная форма Дальнейшая нормализация Нормальная форма Четвертая нормальная форма Оглавление Пятая нормальная форма Итоги 3. Связи Основные и определения Моделирование Связи к одному» Реализация сущностей как классов-наследников Связи ко многим» Связи ко многим» Унарные связи Тройные связи Связи определенной мощности Итоги данных Ограничения целостности Целостность доменов Целостность на уровне Целостность на уровне сущности Ссылочная целостность Целостность на уровне данных Целостность на уровне транзакций Реализация целостности данных Неопределенные несуществующие величины Реакции на нарушения целостности Декларативная и процедурная целостность Целостность на уровне домена Целостность на уровне сущности Ссылочная целостность Другие виды целостности Итоги Глава 5. Реляционная алгебра Значения Null (еще трехзначной логике) Реляционные операторы Ограничение Проекция Соединение Естественные соединения Оглавление Внешние соединения Деление Операции над Объединение Пересечение Разность Декартово произведение Дополнительные реляционные операторы Агрегирование Расширение Переименование Оператор TRANSFORM Оператор CUBE Итоги Часть II. Проектирование реляционных систем баз данных Процесс проектирования Модели жизненного цикла Проектирование базы данных Определение параметров системы рабочих процессов Построение концептуальной модели данных Подготовка схемы базы данных Проектирование пользовательского интерфейса Замечания о стандартах и технологиях проектирования 7. Определение параметров системы Цели и границы применения системы Определение критериев разработки Критерии, выражаемые в измеряемых единицах Критерии, определяемые внешним окружением Основные направления разработки Определение масштаба и границ системы Стоимостный анализ Итоги...

Оглавление Определение рабочих процессов Выявление существующих рабочих процессов Беседы с пользователями задач Анализ рабочих процессов Документирование рабочих процессов Пользовательские сценарии Итоги Концептуальная данных объектов данных Определение связей Мощность связи Обязательность связи связи ограничения Повторный анализ сущностей между сущностью и предметной областью Рабочие влияющие на сущности Взаимодействие между сущностями Бизнес-правила и ограничения Атрибуты Анализ доменов, Выбор типа данных Ограничения на данных Определение формата Нормализация Итоги Глава 10. Схема базы данных Системная архитектура Программная Трехуровневая архитектура Четырехуровневая архитектура и данных Архитектура данных Одноуровневая архитектура Двухуровневая архитектура Многоуровневая архитектура Интернет и Компоненты схемы базы данных Таблицы и связи Ограничения Связи Индексы Представления и запросы Защита данных Уровни защиты данных Отслеживание и регистрация системных событий Итоги Глава Сотрудничество при проектировании Общение с заказчиком Структура документа Введение Обзор системы Рабочие процессы Концептуальная модель данных Схема базы данных Интерфейс пользователя Прототип Спецификации интерфейса Контроль за изменениями Специальные средства Итоги Часть III. Проектирование интерфейса Глава Интерфейс как посредник между пользователем и системой Роль пользовательского интерфейса в системе Модели интерфейса Уровни подготовки пользователей Начинающий пользователь Опытный пользователь Эксперт на пользователя ответственность за действия Не перегружайте память пользователя! Оглавление Будьте последовательны! Итоги Глава 13. Архитектура пользовательского интерфейса Поддержка рабочих процессов и многодокументный интерфейс архитектура Рабочая книга Интерфейс, использующий стиль приложения Microsoft Outlook Многодокументная архитектура «Классическая» архитектура MDI панель управления Проект Мастер, Итоги Глава 14. Связь между сущностями и формами системы Простые сущности Связи «один к одному», Связи «один ко многим» Иерархические структуры Связи «многие ко многим» Итоги Глава Выбор элементов управления пользовательского интерфейса Логические Наборы значений Выбор значения Выбор нескольких значений из диапазона Числовые данные и даты Текстовые данные Итоги Глава 16. Поддержка целостности базы данных Классы ограничений целостности Внутренние ограничения Ограничения, налагаемые на тип данных налагаемые на формат данных Ограничения, налагаемые на длину данных Оглавление Ограничения, налагаемые на диапазон возможных значений Ограничения на уровне сущностей и ссылочная целостность, Случайные ошибки при вводе данных Модель системы и реальность Итоги Глава 17. Создание отчетов Сортировка, поиск и использование фильтров Сортировка данных Фильтр по выделенному фрагменту в одном поле Фильтр по заданным значениям в нескольких полях Расширенный фильтр Средство построения запросов Microsoft English Query Стандартные отчеты Отчеты в виде списков и подробные отчеты использующие агрегированные данные Отчеты на форм пользовательского интерфейса Интерфейс для создания отчетов Обработка ошибок принтера Печать автоматическая и по команде пользователя Пользовательские отчеты Средства создания отчетов Настраиваемые пользовательские отчеты Стандартные письма Итоги Глава 18. Поддержка пользователя Пассивные механизмы Запоминающиеся клавиш Всплывающие подсказки Строка состояния Реактивные механизмы поддержки пользователя Контекстная справка, вызываемая пользователем Подсказки типа «Что это такое» Звуковые сигналы Сообщения об ошибках Активная помощь Обучение пользователя Итоги... Словарь терминов Рекомендуемая литература Предметный указатель Об авторе Предисловие Перед вами книга, которая как бы перекидывает мостик между ака демической теорией и проектирования баз данных в ре альных условиях. Вы найдете в ней полезную которая пригодится на всех стадиях разработки приложений для баз данных - от начального этапа проектирования базы данных до создания пользовательского интерфейса, составления пользовательской доку ментации и планирования курсов подготовки пользователей.

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

Даже экспертам в области СУБД будет интересно и полезно прочи тать ее.

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

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

Реализовать пользовательскую систему на основе СУБД зачастую весьма не просто, но практические задачи, которые она должна решить, и добиться, чтобы проектируемая система дей ствительно служила этой цели, — еще сложнее. Вторую часть своей книги Ребекка Райордан посвящает практическим вопросам реализа ции систем на основе баз данных. Она щедро делится с читателями своим богатым опытом, подсказывает, как избежать «подводных кам много внимания уделяет работе с пользователями. Прислушай тесь к ее советам, и ваша система действительно будет удовлетворять всем требованиям заказчика и послужит примером подхода к проектированию.

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

Уделяя основное внимание разработки базы данных, ав тор не на этом. Книга содержит немало ценных прак тических рекомендаций по организации управления проектом в те чение всего разработки, эффективному взаимодействию с раз работчиками и будущими системы, а также ряд сове тов относительно формы и содержания различных документов, здаваемых в процессе разработки. Автор подсказывает, как но выбрать элементы управления для пользовательского интерфейса, рассматривает несколько готовых решений на основе стандартных элементов управления Microsoft Windows, подробно описывает, ка ким типам данных какой элемент соответствует. В главе 16, посвя поддержке целостности базы данных, изложен один из наи более реалистичных подходов к этой сложной проблеме, какие я ког да-либо встречал. И, наконец, автор рассказывает о том, как наиболее рационально спланировать и реализовать систему помощи пользова телю, применив самые передовые интерактивные средства.

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

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

Я от всего сердца хочу поблагодарить своих друзей и Прежде всего, членов моей семьи: мужа, Марка РаЙордана, кото рый верит в меня, в мои силы и возможности, моих родителей Диану и Харлоу Райт — они поддерживали меня и не давали унывать ни при каких Большое спасибо Майку Ми, давшему положительный отзыв об этой книге и написавшему предисловие.

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

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

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

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

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

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

И наконец, хочу добавить: все которые заметит в этой книге, принадлежат Еще раз благодарю всех, (Rebecca Введение Реляционные базы данных — один из самых сложных типов коммер ческих приложений. Все остальные типы систем, как правило, имеют более-менее близкие аналогии в реальном мире. С точки зрения прак тического использования, текстовые процессоры — это усовершен ствованная пишущая машинка. Электронные таблицы, несомненно, легко освоит не только бухгалтер, но и любой другой пользователь. А работа с почтой достаточно похожа на обычную отправ ку корреспонденции. При создании парадигмы Windows Desktop была использована аналогия с письменным столом, за которым ра ботает сотрудник — весьма приблизительная, но все же довольно близкая к реальности.

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

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

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

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

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

Вопросам реализации также будет уделяться значительное внима ние на протяжении всей книги, но все же ее нельзя назвать том, как базы данных». Хотя я и включила в нее при меры кода, но постаралась, чтобы книга не была перегружена ими Как правило, это достаточно простые примеры, и даже если вы толком не знаете ни одного языка вы в них разберетесь. При которые я привожу, используют базу данных постав ляемую вместе с Microsoft Access. (Версия базы данных Northwind, по ставляемая вместе с SQL Server 7.0, очень похожа на нее).

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

Ребекка О прилагаемом к книге Прилагаемый к книге компакт-диск содержит тематические статьи из обзоров, публикуемых Microsoft, а также из сборника Microsoft Know ledge Base, посвященные разработке баз данных. Кроме того, пред ряд документов и шаблонов Microsoft — они предназ начены для создания описывающей процесс разработ ки баз данных. Вы также найдете там базу данных, используемую в качестве примера процесса разработки, Тематические статьи из обзоров Microsoft и Microsoft Knowledge Base Microsoft и Microsoft Knowledge Base содержат мно жество статей и обзоров, посвященных различным аспектам разра ботки баз данных. Некоторые из них включены в прилагаемый ком пакт-диск, в структурированный по главам книги. Полный список обзоров и статей — в файле Readme.txt.

Формы Компакт-диск содержит формы, которые могут использоваться в про цессе разработки. Формы представлены в виде документов и шабло нов Word.

Документы Word Возможно, вы захотите использовать формы, приведенные в качестве примеров в этой книге. Они могут пригодиться вам при обсуждении деталей проекта с заказчиком или просто в качестве черновиков при работе над какой-нибудь похожей системой. Копии всех форм содер жит каталог Forms. Для вывода форм на печать используйте Microsoft О прилагаемом к книге Word 97 или Microsoft Word 2000. Если на вашем компьютере не уста новлен Microsoft Word, то для просмотра и печати форм воспользуй тесь Microsoft Word Viewer. по установке и этого приложения находятся в файле Readme.txt.

Шаблоны Кроме документов Word содержит также шаблоны Word, куда включены все формы. Шаблоны Word находятся в ката логе Forms компакт-диска. Для установки шаблонов на вашу систему следуйте инструкциям в файле Readme.txt.

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

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

База используемая в качестве примера Каталоги Access 97 Database и Access 2000 Database содержат базу дан ных, поставляемую вместе с версиями Microsoft Access 97 и Microsoft Access 2000 и отформатированную соответствующим образом Эта база данных использовались в качестве примера в процессе модели рования.

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

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

системы Сама по себе система не включает разработку схемы базы данных.

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

Система также не включает средства для выполнения стоимост ного анализа.

О прилагаемом к книге Если вы работаете над созданием сложных систем совместно с большой группой разработчиков, вам придется предусмотреть сред ство для контроля версий. Для этого нужно либо расширить функци ональность системы, либо интегрировать систему с системой конт роля версий. Если пользователи будут работать с базой данных по сети, стоит разделить пользовательские компоненты и компоненты механизма базы данных. Это несложно сделать при Access Database Splitter Wizard.

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

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

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

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

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

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

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

Требования к системе Для работы с базой данных на вашем компьютере должен быть уста новлен Access 97 или Access 2000.

Чтобы работать с формами в Word в электронном виде, установи те также Word 97 или Word 2000. Или воспользуйтесь для просмотра и печати форм Microsoft Word Viewer.

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

microsofl.com/supporS Все замечания, вопросы и предложения, касающиеся этой книги и прилагаемого к ней компакт-диска, вы можете отправить по следу адресам.

Почтовый адрес «Microsoft Press»:

Designing Relational Database Systems Editor One Microsoft Way Redmond, WA 98052- Адрес электронной почты: msinput@microsoft.com Обратите особое внимание на то, что Microsoft не предоставляет технической по своим продуктам адресу. Ком пакт-диск, прилагаемый к книге, содержит базу данных в форматах Microsoft Access 97 и Microsoft Access 2000. Техническая поддержка Microsoft Access доступна по следующему адресу:

com/support/.

ЧАСТЬ Теория реляционных баз данных Основные понятия ГЛАВА Итак, что же такое база данных? Говоря коротко, это ство для и эффективного хранения информации. Ины ми словами, такая база обеспечивает надежную защиту данных от слу чайной потери или порчи, экономно использует ресурсы (как людские.

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

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

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

ГЛАВА Что такое база данных Терминология, используемая в области баз данных, включает множе ство нюансов, столь же тонких, как например, употребление термина «объектно-ориентированное программирование». Само понятие данных» может обозначать как отдельный набор данных (например, список телефонов), так и гораздо более сложную систему (например.

Server).

Можно привести множество примеров, не столь простых, как адресная книга, и не столь сложных, как SQL Server, и тем не менее, объединенных одним общим названием «база данных». Такая нечет кость определений отнюдь не является недостатком — это просто свойство языка.

Попытаемся ясность в этот вопрос — на рис. 1-1 показана взаимосвязь между которые будут обсуждаться далее.

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

Под термином модель данных договоримся понимать концептуаль ное описание предметной области. Она включает определения сущ ностей и их атрибутов: например, сущность (Покупатель) может иметь атрибуты Name (Имя) и Address (Адрес). Сюда входят так же определяемые для сущностей ограничения: например, не может допускать «пустых» значений.

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

ЧАСТЬ 1 Теория данных СУБД База данных схемы базы данных и на уровне Схема базы данных содержит модели данных, базой данных Модель данных — это концептуальное описание области Предметная это определенная часть реального мира Рис. 1-1. используемые в области реляционных баз данных ГЛАВА 1 Основные понятия Определение физической модели — создаваемых таблиц и представ лений, называется схемой базы данных или просто схемой. Схема — это перевод концептуальной модели в физическое представление, осуще ствляемое, как правило, средствами системы управления базами ных. Схема — это понятие, относящееся к концептуальному, а не к физическому уровню. Это все та же модель данных, описываемая в терминах, используемых механизмом СУБД (database engine) — таб лицы, триггеры и т. п. Механизм СУБД хорош и тем, что при его ис пользовании не приходится иметь дело с физической модели;

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

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

В понятие «база данных» не входят состоящее, как правило, из форм и отчетов, с которыми работают пользователи, а средства, обеспечивающие связь между серверной и клиентс кой частями клиент-серверных приложений (например, связующее программное обеспечение или Microsoft Transaction Server). Кроме того, в базу данных не входит механизм СУБД. Например, файл Access с расширением — это база данных, a Microsoft Jet — механизм СУБД. На самом деле файл помимо базы данных, может содер жать множество других объектов (форм, отчетов и т. д.), однако сей час мы не будем останавливаться на этом вопросе, отложив его для дальнейшего обсуждения.

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

Инструменты для работы с базами данных Эта книга посвящена, главным образом, вопросам разработки, а не реализации баз данных;

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

Средства разработки определения данных приложений Microsoft Access средства разработки Microsoft Access данных Visual Basic Microsoft Query HTML SQL Enterprise Manager ASP модель к данным ADO DAO/Jet DAO/ODBCDirect RDO Механизм СУБД SQL Microsoft Рис. 1-2. Инструменты для работы с базами данных Механизм СУБД На самом нижнем уровне находится механизм СУБД. Его часто на зывают частью», однако это неточно, поскольку данный термин подразумевает существование определенной физической ар хитектуры, о которой подробнее будет рассказываться в главе 10.

Механизм базы данных — это специальные средства, предназначен ные для физического манипулирования данными: хранением их на ГЛАВА 1 Основные диске и извлечением по запросу. Механизмов СУБД множество, но мы подробно рассмотрим только два из них — Microsoft Jet и SQL Server. Вы удивились, не в этом списке Microsoft Access? Од нако здесь нет никакой ошибки. Access использует механизм баз дан ных Microsoft Jet для манипулирования данными, хранимыми в фай лах.mdb, а также может подключаться к любому источнику данных ODBC и манипулировать данными, хранимыми в таком источнике данных, в том числе и в SQL Server. Механизм Microsoft Jet всегда использовался Access, хотя Microsoft и не выделяла механизм баз дан ных как отдельную сущность до появления Microsoft Visual Basic 3.

После того как Access 97 стал поддерживать ODBCDirect, a Access 2000 — Microsoft разделила клиентскую часть Access и ме ханизм баз данных Microsoft Jet. Я полагаю, что в версиях эта тенденция сохранится;

однако это лишь мое личное мнение.

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

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

Объектная модель доступа к данным И Access, и Visual Basic предоставляют простые и удобные инструмен тальные средства для непосредственной связи между элементами уп равления и источником данных. Эти средства позволяют избежать прямого взаимодействия с механизмом баз данных. Однако по раз личным причинам, которые мы рассмотрим далее, такой способ не всегда реализуем на практике. Порой более эффективно использовать объектные модели доступа к данным для манипулирования данными непосредственно в коде.

Объектная модель доступа к данным представляет собой своего рода «промежуточный слой» между средой программирования и ме ханизмом СУБД. Она содержит набор объектов, свой ствами и методами, которыми можно манипулировать в коде. Сейчас Microsoft разработала и предлагает три объектных моде ли доступа к данным:

ЧАСТЬ 1 Теория баз данных • Data Access Objects (DAO) — имеет две разновидности: и • Data Objects (RDO) — используется в основном для досту па к источникам данных ODBC;

• Microsoft ActiveX Data Objects (ADO) — ближайшем будущем пол ностью заменит DAO и RDO.

DAO — старейшая из трех перечисленных выше моделей, это соб ственный интерфейс механизма СУБД Microsoft Jet. RDO похож на DAO, но оптимизирован для доступа к источникам данных например SQL Server и Oracle. По сравнению с первыми двумя моде лями, ADO использует меньшую иерархию объектов, все го лишь из четырех основных уровней, и предоставляет некоторые существенные расширения — поддержку разобщенных наборов данных (disconnected recordsets) и группы объектов и мето дов, создавать иерархический набор данных.

Поскольку эта книга посвящена разработке, а не внедрению баз данных, мы не будем подробно рассматривать преимущества каждой из этих моделей. Всем, кого интересует вопрос, я могу поре комендовать статью Уильяма Вогна (William Vaughn) в Guide to Visual Basic and SQL Server», а также ряд других статей и до кументов, опубликованных на Web-узле Microsoft. Объектные моде ли не единственный способ доступа к данным, существует множество альтернативных средств, например Visual Basic Library для (VBSQL) и OLE DB.

Средства для разработки клиентской части приложений Microsoft Jet и SQL Server берут на себя манипулирование данными на физическом уровне, однако необходимо им четкие указания, каким образом эти должны быть структурированы. Microsoft предоставляет богатейший арсенал средств решения этой задачи, но мы подробно рассмотрим только два: Access и Microsoft Visual Da tabase Tools. Лично я предпочитаю именно их, тем более что ные методы предоставляют приблизительно те же возможности. По няв основные механизмы действия Access и Microsoft Visual Database Tools, вы можете выбрать для себя те средства, которые сочтете наи более удобными для решения конкретной задачи.

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

После того как базы данных на физическом уров не будет завершено, вам потребуются инструменты для создания форм и отчетов, с которыми будут работать пользователи. Мы рас смотрим два таких средства: Access и Visual Basic. В главе мы кос немся также средств просмотра Web, однако непосредственно о язы ке HTML в этой книге говорить не будем.

Реляционная модель Реляционная модель основывается на математических принципах, непосредственно из теории множеств и логики преди катов. Эти принципы впервые были применены в области моделиро вания данных в конце 60-х гг. доктором Е.Ф. в то время ра ботавшим в IBM, а впервые опубликованы — в 1970 Реляционная модель определяет способ представления данных (структуру данных), методы зашиты данных (целостность данных), а также вы полняемые с данными (манипулирование данными).

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

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

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

• Все значения являются скалярами. Это означает, что для любой строки и столбца любого отношения существует одно и только одно значение.

Е. F. A Relational Model of Data for Shared Banks. Communications of the ACM. Vol. 13. No. 6 1970).

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

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

Если у вас имеется опыт работы с базами данных Microsoft Access, вы, конечно, догадались, что в данном случае представляет собой ношение — это набор записей или, в терминах SQL Server, набор резуль татов. Формулируя принципы реляционной модели, доктор выбрал термин «отношение» потому что он однозначен (в то время как, например, термин «таблица» имеет множество допол нительных значений). Весьма распространено следующее заблужде ние: реляционная модель так потому, что она определяет от ношения таблицами. деле название этой модели про исходит от отношений, в ее основе.

В рамках реляционной модели данные представлены в виде отно шения на концептуальном уровне;

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

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

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

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

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

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

представление данных зависит от выбранного варианта реализации системы.

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

Заголовок ртеж Атрибут | Leka Trading Fried de Cabras' di Dried Apples New England Seafood New Clam Chowder -Тело New Orleans Cajun Delights Louisiana Fiery Hot Sauce (21. G'day, Dried Apples New Cajun Delighls • Louisiana Hot Pepper (21. $21. Pasta s г Angelo $19. Рис. 1-3. Компоненты отношения ЧАСТЬ Как мы условились ранее, называется вся структура в целом. Каждая строка, содержащая является кортежем. Стро го говоря, каждая строка является однако как пра вило, опускается. Число кортежей в отношении определяет мощность отношения- В приведенном на рис. 1-3 примере мощность отноше ния равна П. Каждый столбец отношения называется атрибутом.

Число атрибутов в отношении определяет этого отноше ния, для проиллюстрированного примера она равняется трем.

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

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

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

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

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

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

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

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

Приведем простейший пример: покупают товары.

Сотрудники продают товары покупателям. поставляют товары». Существительные «покупатели», «товары», и вне всякого сомнения, будут являться сущностями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

состоит из обращения имени (Jane), первой буквы второго име ни (Q) и фамилии (Public). Значит, при разработке системы можно ограничиться сущностями — Title (обращение), First Name (имя), Middle Initial (первая буква второго имени) и (фами не ли?

Нет, не так. Во-первых, в разных странах существуют разные пра вила, что следует указывать первым — имя или фамилию. Поэтому лучше использовать (имя, данное при рождении) и Surname (фамилия или прозвище). Во-вторых, как в таком случае ввести в базу данных, например, такое громкое имя как сэр Джеймс Смит, лорд Данстэйбл James Lord Можно ли считать, что Педдингтон Смит (Peddington Smy the) — это фамилия лорда? Или, может быть, Педдингтон (Peddington) это второе имя? И что, наконец, делать с этой неудобной после дней имени: «лорд Данстэйбл» (Lord А что вы ска жете о певце по имени Стинг Какая из сущностей будет ально представлять собой имя Стинг — (имя, данное при рождении) или Surname (фамилия или прозвище)? И наконец, как быть с таким сложным именем, как The Artist Formerly Known as Prince вы раетесь выходить из такого положения?

ЧАСТЬ 1 Теория реляционных баз данных вопрос был задан совсем не Скорее всего, письмо, адресованное сэру Джеймсу Смиту (Sir James не вызовет раздражения у самого обладателя ти тула и не собьет с толку его слугу или личного разбираю щего почту. Однако нельзя обратиться к упомянутому джентльмену «сэр правильное обращение — «сэр Джеймс» или «лорд Однако давайте выясним у нашего заказчика, много ли у него которые носят титулы или леди. Большинство ком паний все же не могут похвастаться обилием титулованной клиенту ры. Во всяком случае, тот рок-клуб, о котором мы уже вряд ли поблагодарит вас за систему ввода и поиска информации, если та будет содержать форму, подобную показанной на рис.

Рис. Чрезмерно форма ввода адреса.

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

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

И все же преимущества подобного способа весьма сомнительны.

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

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

Понятие «домен» часто путают с понятием «тип данных».

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

Сущности (название улицы) и Surname могут быть реализованы как текстовые поля;

однако совершенно очевидно, что это разные виды текстовых полей, и принадлежат они к разным доменам.

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

{ВА, BS, MA, MS, PhD, MD}.

ЧАСТЬ Безусловно, не все домены можно определить, просто перечислив допустимые значения. Например, домен Age (возраст) содержит око ло сотни значений, если речь идет о человеке, и несколько тысяч если говорим о музейных экспонатах. В подобных в делении домена, как правило, используются правила, проверяюшие принадлежность конкретного значения к области допустимых значе ний. домен физического можно определить как число в интервале от 0 до 120, a (воз раст выставочного экспоната) — просто как неотрицательное число, большее 0.

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

Вы, очевидно, уже заметили, что все эти определения ссылаются на вид хранимых данных или строка), Это описание очень похоже тип данных, между ними существуют различия. Как я уже упоминала, типы данных — это физические они определяются и реализуются в терминах механизма СУБД. Если при разработке модели данных вы определите как (сим вольную константу переменной длины, с числом символов, не пре 30) или Long (длинное целое), это будет ошибкой.

поскольку и и Integer — это описания, к механизму СУБД.

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

Домены EmployeelD и имеют совместимые типы. Но по пытавшись соединить отношения по вы вряд ли получите даже если в определения двух доменов заложен один и тот же тип данных.

ГЛАВА Orders • et Chevalier 10249 Toms В 10251 en stock...Sales Represent alive 2 Fuller Andrew President, Sales...Janet Sales Representative 4 Margaret Representative 5: Buchanan Steven Sales Manager Employees и Orders К сожалению, механизмы СУБД Microsoft Jet и SQL Server не пре доставляют более строгой внутренней поддержки доменов, чем типы данных. Однако даже там, где речь идет о типах данных, ни один из упомянутых механизмов СУБД не строгой проверки.

оба они выполняют преобразования данных незаметно для пользова теля. Рассмотрим конкретный пример, обратившись к базе данных поставляемой Microsoft Access в качестве примера. Если вы определили в таблице Employees как длинное а в таблице — как currency (валюта), то можете на писать запрос, соединяющий эти две таблицы при помощи критерия WHERE = Microsoft Jet успешно выполнит этот запрос и вернет вам результат — список сотрудников, иденти фикационный номер которых будет совпадать с указанной в счете (InvoiceTotal). Совершенно очевидно, что два эти атрибута не являются совместимыми по типу данных, однако мы ни как не можем «объяснить» это механизму СУБД Microsoft Jet, Итак, стоит ли вообще иметь дело с доменами? Ответ однознач ный: да, стоит. Во второй части книги мы рассмотрим домены более подробно, и увидим, что это чрезвычайно мощные и эффективные инструменты. При разработке баз данных часто возникают «Являются ли эти атрибуты или ли правила, применимые к одному атрибуту, но не применимые к Анализ доменов позволяет получить ответы.

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

Большинство связей — двойные, в них два участника. Пример та кой связи — связь между (Покупатели) и ducts (Продукты). Однако существуют и другие виды связей, напри мер, на существование неявной тройной связи указывает утвержде ние «Сотрудники фирмы продают товары покупателям». Определе ние двух двойных связей не позволяет определить, кто именно из со трудников продал товары покупателям, и какие именно товары ка ким именно покупателям он продал. Для этого нужно определять тройные связи.

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

Существует несколько типов связей между двумя это связи «один к «один ко многим» и «многие ко многим».

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

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

ГЛАВА Участие каждой сущности в определенной может быть тичным или данной сущности полнос тью определяется ее участием в то такое участие будет в противном случае частичным.

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

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

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

Диаграмма «сущности - связи» В г. Питер Пин Шань Чен (Peter Pin Shan Chen) внес существен ный вклад в теорию моделирования данных, разработав модель ности — связи», в которой реализовано описание данных в терминах атрибутов и он Предложил новый метод диаграмм — диаграммы «сущности — связи» (Entity diagrams, или E/R diagrams), который вскоре стал широко применяться разработ чиками баз данных. На диаграммах — связи» сущности изображаются в виде прямоугольников, атрибуты — эллипсов, а от — ромбов (рис. 1-6).

Pin Chen. The Relationship a Unified of Data? ACM TODS I. №. I ЧАСТЬ 1 Теория реляционных баз данных Рас. 1-6. — связи» ГЛАВА Вид связи между сущностями («один к ко многим» или «многие ко на разных диаграммах может изображаться по-разному. Некоторые разработчики используют обозначения и М или и со для обозначения понятий и «много»;

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

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

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

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

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

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

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

Robert 10523 Robert Jane!

Рис. 2-1. Набор содержит ЧАСТЬ 1 баз Как видите, в этой значения и Telephone одинаковы в записях, в которых совпадает имя работника компании.

Такая организация данных имеет несколько последствий.

каждый раз при создании новой записи вы должны вместе с именем сотрудника занести значения в поля HireDate и даже если уже вносили их раньше (разумеется, каждый раз вы рискуете ошибиться). Например, на основании дан ных на рис. 2-2, сможете ли вы определить, в каком году сотрудник по имени Стивен (Steven Buchanan) был принят на работу — в или Кроме того, такая структура данных не позволяет ввести дату найма и внутренний телефон сотрудника, до тех пор пока он не со вершит хотя бы одной сделки. И наконец, если счета-фактуры за оп ределенный год удаляются из базы данных и архивируются, то дан ные о телефоне и дате найма определенных сотрудников могут быть утеряны.

La Buchanan Giovanni " " 2-2. Дублирование данных может привести в том числе и к их рассогласованию Такие проблемы обычно называют аномалиями обновления. Они могут приводить к еше более серьезным последствиям, если избыточ ные данные хранятся не в одном, а одновременно в нескольких от ношениях.

Рассмотрим пример на рис. 2-3 (как и прежде мы видим жимое реально а не результаты выполнения запросов). Если телефонный номер компании «Around the Horn» из менился, вам придется поменять его в наборе записей Customer и не забыть обновить телефонный номер в каждой записи набора относящейся к этой компании.

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

ГЛАВА 2 Структура Отношение Customers 030- у helados [5) 555- Antonio Moreno I [5) 1he Horn Отношение Invoices Alfreds 10952 Alfreds Ana у helados (5) 555- Trujillo Emparedados у helados (5) у Around 555- Around 555- Around Horn Around the Horn ) Bergiunds 10875 Bergiunds snabbkop Bergiunds snabbkop 2-3. данные могут присутствовать в нескольких отношениях Однако, предположив, что некоторые атрибуты в отношении яв ляются избыточными, не торопитесь делать поспешные выводы. Не обходимо убедиться, что атрибуты, которые кажутся избыточными, являются таковыми на самом деле.

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

Атрибут UnitPrice в отношении отражает текущую цену продажи товара. Атрибут UnitPrice в отношении Orders — это цена, по которой товар продан. Для товара например, в Orders ет запись, где значение а в отношении Products -запись, где UnitPrice товар сей час по цене $23,25, никак не может изменить то, что некоторое время назад он продавался по $18,60. Оба атрибута определены в одном и том же домене, но являются различными по смыслу величинами.

ЧАСТЬ 1 баз Отношение Products Cabrales S21 41 Jack's New England Chowder Hokkien Apples (53. 57;

Ravioli Louisiana Fiery Hot Sauce 66 Spiced Okra Отношение Orders Hokkien Fried Mee DI di Giovanni BO 10249 Manjimup Apples 40;

Manjimup Dried Apples Hot Pepper New Clam Chowder (7. 10251 $15.60 15!

10251 Hot Pepper Sauce $16.80 20!

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

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

Обратимся вновь к примеру из главы 1, где речь шла об именах адресатов — допустим, именно их список отображен на рис. 2-5. Пол ное имя из значений полей верхнего отношения легко: дос таточно записать выражение:

& S LastName & Title ГЛАВА 2 базы 1 Ms.

2 Dr. Vice President, Sales 4 Mrs. Sales Representative 5;

Mr. Buchanan Sales 1 Ms. Sales Representative Fuller, Sales Ms. Sales Representative Л Mrs. Sales Representative 5 Mr Buchanan, Sales Manager Рас. Полное имя адресатов представлено в виде отдельных атрибутов — в и как один атрибут — в нижнем А вот для того, чтобы фамилию из поля ниж него отношения, нужно обработать строковые данные:

Function (FullName as String) as String ( Dim as String титул убрать вежливое обращение InStr(lastname, убрать имя lastname = Function Уязвимое место такого подхода — его чувствительность к измене ниям содержимого поля FullName;

например, естественно ожидать.

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

Второй принцип, используемый при создании модели данных, способной эффективно предоставлять необходимую — избегать дублирования одной и той же информации во множестве полей (рис. 2-6 и 2-7), 1 Теория баз данных Отношение Enrollments Рис. 2-6, Такая структура затрудняет ответов некоторые вопросы Enrollments 1 i 2 Andrew Fuller i Physical Education 3 Janet Levelling : 1 Physical Education 4 Margaret 5 6 Michael 1 French 7: Robert King Nancy 2 French 2. 2. Biology A Margaret 2. Physical 5 Steven i 6 2 Education 7 Robert 2 French Э English 2. Andrew Fuller 3 French 2- 7. Данная структура содержит больше но для нее формулировать Чтобы получить ответ на вопрос «Кто из студентов в этом году изучает с первого отношения, придется искать записи со значением в шести различных полях. Соответству ющее выражение SELECT языка SQL будет выглядеть так:

SELECT FROM Enrollments WHERE "Biology" OR = "Biology" OR "Biology" OR = OR = "Biology" OR "Biology" А при использовании отношения, показанного на рис. 2-7, требу ется выполнить поиск только в одном поле SELECT StudentID FROM WHERE Class "Biology" Оба этих подхода вполне работоспособны, но второй очевидно и вероятность ошибки при его меньше, не говоря уже о том, что его не нужно долго обдумывать.

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

как им пользоваться — совершенно очевидно, но только когда вам это уже показали.

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

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

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

Перед тем, как мы вернемся к нормализации, ознакомимся с несколь кими принципами, лежащими в ее основе.

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

ЧАСТЬ 1 Теория баз 59 rue de 1024Э.

do de 2V Boulevard Tirou, отношение Customers ANATR de я Отношение Invoices. Отношение с рис. 2-8 можно на эти два отношения без потери данных двух отношений вместо одного устраняет избыточ ность адресных данных заказчика, но позволяет при необходимости найти адрес, связав отношения Customers и Invoices по содержащему ся в них полю Ключи-кандидаты и первичные ключи В главе 1 я определила содержимое отношения как неупорядоченное множество, из 0 или более кортежей, и указала, что по оп ределению каждый множества кортежей должен быть уника лен. В таком случае для любого отношения должна ком бинация атрибутов, однозначно определяющая каждый кортеж. Такой набор из одного или более атрибутов называют ключом-кандидатом.

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

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

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

Если буквально следовать определению, то каждое отношение должно иметь, по меньшей мере, один ключ-кандидат — набор всех атрибутов, составляющих кортеж. Ключ-кандидат может состоять из единственного атрибута (простой или множества атрибутов (со ставной Тем не менее, дополнительное требование к ключу кандидату такое: он должен состоять из минимального набора атри бутов, однозначно кортеж, поэтому полный на бор атрибутов отношения не является ключом-кандида том. Для отношения, показанного на рис. 2-10, атрибут Л) яв ляется ключом-кандидатом, а набор хотя и уникален для каждого кортежа, не является им, так как атрибут Cate goryName необязателен для однозначной идентификации кортежа.

Beverages drinks, coffees, teas, beers, and ales 2 Condiments Sweet sauces, relishes, seasonings Desserts, Cheeses and Prepared Dried fruit 8: Seafood and fish 2-10. Ключ-кандидат должен быть минимальным, чему соответствует но не соответствует набор Иногда, хотя и не часто, отношение имеет несколько возможных ключей-кандидатов. В этом случае проектировщик должен по своему усмотрению выбрать один ключ-кандидат в качестве первичного клю ча, а ключи-кандидаты будут являться альтернативными ключами. Это особенность логической модели довольно удобна. (На помню, что логическая модель данных — абстрактное понятие). Что бы различать модель и ее физическую я предпочитаю использовать термин «ключ-кандидат» для логической модели дан ных и приберечь ключ» для использования в физичес кой реализации модели.

ПРИМЕЧАНИЕ Когда единственно возможный ключ-кандидат чересчур громоздок (например, состоит из слишком многих атрибутов или слиш ком велик), вы можете использовать специальный тип данных, который механизм баз данных Jet и Microsoft SQL Server поддерживают для создания искусственных ключей. В таких искусственных ключах хранятся значения, генерируемые самой системой. Называемые Auto Number в Microsoft Jet и Identity в SQL Server, поля этого типа очень удобны для создания строк. При этом подразумевает ся, что вы не будете пытаться связать поле этого типа с какой-нибудь конкретной сущностью предметной области. Такие поля не более чем ярлыки. Ничто не гарантирует, что значения содержащихся в них вели чин будут строго последовательными, вы практически не можете конт процесс их генерации системой. Так что не пытайтесь ис пользовать их для чего-либо еще, кроме нумерации, иначе столкнетесь с массой Хотя выбор является семантической проблемой, не надейтесь, что атрибуты, с которых вы моделируете сущ ности реального мира, всегда позволят вам построить подходящий ключ-кандидат. Люди обычно отзываются на свои имена;

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

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

зависимость Концепция функциональной зависимости чрезвычайно удобна для анализа структуры данных. Рассматривая любой кортеж Т и два на ГЛАВА 2 Структура данных бора атрибутов этого кортежа и (множества X и Y не обязательно являются взаимоисключающими) говорят, что Y зависит от X, если для каждого возможного значения X существует единственно возможное значение Y.

в отношении на рис. 2-10, все кортежи с одним и тем же значением будут иметь одинаковое значение Поэтому мы вправе сказать, что атрибут функционально определяет множество Desc Учтите, что обратной зависимости может и не быть: зная величину нельзя однознач но величину Вы можете указать на функциональную зависимость между атри бутами так, как это сделано на рис. В тексте следует записать функциональную зависимость в виде выражения X Y, что читается как «X зависит от Рис. 2-11. Диаграмма и интуитивно понятна зависимость привлекает ученых-математиков, поскольку это понятие является основой для развития математичес ких подходов к моделированию данных. Если вы склонны к теорети ческим изысканиям, то можете исследовать, например, свойства реф лексивности и транзитивности функциональной зависимости.

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

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

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

| j Items | 1 3 Zaanse, 1 au ;

2 Рис. 2-12. Атрибут Items в данном отношении не является скалярным Не так просто определить, является ли атрибут скалярным — мы сталкивались с этим, когда рассматривали моделирование имен и ад ресов в главе Можно и другие примеры «коварных» доменов. Например, дата состоит из трех различных дня, месяца и года. Как лучше хранить дату: три различных атри бута или как единое целое? Как всегда, ответ зависит от особеннос тей предметной области, которую вы моделируете. Если в вашей сис теме дата используется исключительно или даже просто в большин стве случаев как отдельная то она — скалярная величина.

Но если система часто работает с отдельными даты.

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

или только месяц и день, но не год). Такие случаи не очень часто встречаются, но нельзя сказать, что их нет совсем.

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

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

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

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

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

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

Например, программирование с помощью Windows в значитель ной степени основывается на такой технологии. В общем случае та кой подход вполне оправдан, но в реляционной модели данных это не так. Здесь он не только нарушает принципы первой нормальной формы — вы просто не сможете его так как ни меха низм СУБД ни версии языка SQL для SQL Server не поддержи вают битовые операции. Выполняйте такие операции, используя собственные функции в приложениях баз данных, но только в Mic ЧАСТЬ rosoft Access (Microsoft Visual Basic не позволяет использовать в зап росах написанные самим пользователем). Такой подход требует дополнительно обрабатывать результаты выполнения запро сов на локальном компьютере.

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

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

1 Cabrales Angela 2 Louisiana Fiery Hot Pepper Sauce Эта модель данных ограничивает число покупок, которые может Другой пример повторяющихся групп приведен на рис. 2-14. Оши бочность этого подхода не столь очевидна, и на его основе было со здано множество вполне работоспособных баз данных. Однако это всего лишь вариант подхода к организации данных, показанного на рис. и он имеет те же самые недостатки. Чтобы убедиться в этом, попытайтесь составить запрос с целью определить, для какого из то варов результаты продаж запланированную величину на в I квартале.

Syrup Рис. 2-14. Здесь присутствуют повторяющиеся группы ГЛАВА 2 Структура базы данных Вторая нормальная форма Отношение во второй нормальной форме, если оно нахо дится в первой нормальной форме, и кроме того, все его атрибуты зависят от полного набора атрибутов Например, ключом отношения на рис. является Supplier но поле Supplier Phone Number определяется только значением поля а не полным набором атрибутов составного ключа.

555- (171) 555- flrJO) Рисунок 2- 75. Все атрибуты отношения должны зависеть от полного ключа Мы уже видели, что такая зависимость между атрибутами приводит к избыточности данных, а избыточность, в свою очередь, к возмож ным неприятностям в процессе поддержки базы. Более совершенной с этой точки зрения является модель, изображенная на рис. 2-16.

Отношение 2 Beverages Aniseed 4 Chef Anton's Cajun Seasoning 5 Anton's Gumbo Mix Отношение 1 Exotic Liquids !

2 New Orleans Cajun 3| Grandma Kelly's Homestead Traders 5 de Quesos 76 6 431 - (03) 8 Biscuits, 9 PB 2-16. Эти два отношения находятся во второй нормальной форме Данная модель является следствием декомпозиции исходного от ношения на два независимых отношения: и Suppliers. При такой вы не только устраняете избыточность данных, но также позволяете записать информацию о поставщике, до того как ЧАСТЬ 1 реляционных баз станет известно что-либо о поставляемых им продуктах. Этого было сделать в исходном отношении, так как ни одна из составляю щих первичного ключа не может быть пустой.

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

Каждый из поставщиков может иметь несколько адресов Третья нормальная форма Отношение находится в третьей нормальной форме, если оно нахо дится во второй нормальной форме, и кроме того, все неключевые атрибуты совершенно независимы. Давайте возьмем в качестве при мера некую компанию, расположенную в США, у которой в каждом из штатов имеется единственный офис продаж, а в каждом из офисов работает один сотрудник. В отношении, показанном рис. су ществует зависимость атрибутами Region и Salesperson, но ни один из этих атрибутов не является ключом-кандидатом данного от ношения.

ГЛАВА Peacock SP Laura 10347 SP Laura 10386 Arquibaldo SP SP Laura Callahan Lakes Food OR Suyama Great Lakes Food Market OR Suyama DF.. Nancy 10266 DF i Nancy Carnes RJ -Janet Leverling 10925 Carnes RJ Janet Leverling RJ Davolio Carnes RJ Leverling 10415 Hungry Import iMichael Coyote Import Store OR •Michael Suyama Hungry Coyote Import Store OR Suyama Ни атрибут Region, ни атрибут не являются ключами-кандидатами, хотя и полностью друг от друга Расскажу о третьей нормальной форме подробней. Например, для большинства населенных пунктов вы можете задать в качестве иден тификатора величину (Почтовый индекс), основанную на сочетании величин City (Город) и Region (Район), так что отношение, показанное на рис. 2-19, не находится в третьей нормальной форме.

Ana у Bolide " ' Puc. 2-19. Отношение не в третьей форме Два отношения на рис. 2-20 технически более корректны с точки зрения теории то, что на рис. На самом деле единственным преимуществом, которое вы получите в результате произведенной декомпозиции исходного отношения, будет возмож ность автоматического поиска нужного почтового индекса, избавляю пользователей от нескольких лишних нажатий клавиш. Это не такое уж незначительное к тому же достичь его мож но и иными способами, не требующими выполнять соединение от ношений каждый раз, когда нужно получить адрес.

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

Mineiro A» 25 Paulo SP SP Gourmet SP Fco: 2732 Baker OR OF Напгп Carnas de Janeiro 22 con San Cristobal Plaza Elgin OR of Wight de Janeiro Sin 2-20. Эти два отношения находятся в нормальной форме Решение, когда и как вводить в третью нормальную му, может приниматься только с учетом семантики моде ли (впрочем, как и любое другое решение в ходе построения модели данных). Как правило, отдельные отношения проектируются только для моделирования наиболее важных сущностей предметной облас ти, или когда предполагается частое изменение каких-то данных, или когда вы получаете в результате создания конкретного отношения технологические выгоды. Почтовые индексы изменяются, но не часто;

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

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

Нормальная форма Бойса-Кодда Нормальная форма Бойса-Кодда рассматривается как вариант тре тьей нормальной формы. Она имеет дело со специальной разновид ностью отношений, для которых существует несколько ГЛАВА Фактически, чтобы применять нормализацию по ду, нужно сочетание нескольких условий:

• отношение должно иметь не менее ключей-кандидатов;

• по крайней мере два ключа-кандидата должны быть составными;

• ключи-кандидаты должны иметь перекрывающиеся атрибуты.

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

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

5 11 12 $14. 14 r I 72 5 $34. Trading 42 24 Mate Отношение находится в третьей форме, но не удовлетворяет нормальной форме В данном случае имеется два ключа-кандидата Pro и Name, а диаграмма функциональной за висимости показана на рис.

К сожалению, это утверждение неточно. Обычно формальным R находится в нормальной форме Бойса-Кодда тогда и только тогда, для любой нетривиальной зависимости a между атрибутами R множество (называемое детерминантом функцио нальной зависимости) всегда содержит При этом на не налагается никаких ограничений. Поэтому в нормальной форме Бойса-Кодда ключи-кандидаты могут зависеть друг от друга или часть атрибутов од ного может зависеть от — Прим.

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

ЧАСТЬ 1 Теория реляционных данных Рис. зависимости для отношения, показанного на рис. 2- Как вы можете функциональная зависимость {SupplierName}, которая нарушает нормальную форму Бойса-Кодда. модель показана рис. 2-23.

Отношение Suppliers Leka Formaggi & 24 Male Отношение Products 20 5 11 " 5 $34. 2-23. Полностью нормализованный вариант модели, изображенной на рис.

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

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

ГЛАВА Четвертая нормальная форма Четвертая нормальная форма подводит теоретическую базу под инту итивно очевидный принцип: независимые группы данных не следует размещать в одном и том же отношении. Предпо ложим, что собственная продукция компании Traders» в тару нескольких размеров, что эта тара поставляется несколькими поставщиками, и что каждый поставщик обеспечивает компанию тарой всех необходимых размеров. Ненормализованный вариант отношения Products мог бы выглядеть так, как показано на рис. 2-24.

'•' Chai Exotic Liquids Chef Anton's Cajun New Delights 8 oz, 16 32 oz Pavlova Ltd 8 oz, oz 2-24. Отношение не является нормализованным Первым шагом будет устранение составного атри бута в результате чего мы получим отношение, показанное на рис. 2-25.

Chai Exotic Liquids Chai oz Chai Chef Anton's Cajun Seasoning New Orleans Cajun Delights Chef Anton's New Chef New Cajun Delights Pavlova Ltd. 16 рг Pavlova, Ltd. 12 oz Pavlova Ltd 2-25. Вариант показанного на рис. 2-24, в нормальной форме Бойса-Кодда Забавно то, что отношение на рис. 2-25 находится в нормальной форме Бойса-Кодда, так как полный набор ее атрибутов образует ключ. Однако данные в отношении явно избыточны, и поддержание их целостности может показаться ночным кошмаром тому, кто этим будет заниматься. Решение проблемы базируется на концепции мно гозначных зависимостей и четвертой нормальной формы.

Многозначная зависимость — это два совершенно независимых множества атрибутов. На рис. 2-24 многозначная зависимость запи сывается как {PackSize} | {SupplierName}, что озна чает: две множественные зависимости поставщиков упаковки и размеров упаковки от наименования продукта». Упрошен ЧАСТЬ 1 Теория баз данных но, до четвертой нормальной формы состоит в выде лении многозначных в разные отношения (рис. 2-26).

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

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

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

.

Chai Chef Cajun Cajun.

.

Pavlova Chai Liquids Cajun Delights Chef Cajun Chef Anton's Cajun Seasoning Cajun Pavlova, Ltd.

Pavlova Pavlova, 2-26, Отношения, многозначные должны быть подвергнуты декомпозиции Пятая нормальная форма Пятая нормальная форма имеет дело с чрезвычайно редко щимся случаем зависимостей соединения. Зависимости соединения подчиняются принципу: сущность i зависит от сущности 2, сущность 2 зависит от 3, а сущность 3 в свою очередь зависит от сущности то все три обязательно долж ны входить в один и тот же кортеж».

ГЛАВА 2 Структура базы Если перевести это на нормальный язык, то получится следующее:

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

«Если поставщик поставляет товар, этот товар интересует заказчика, и заказчик работает с поставщиком, то заказчик непременно ет товар у поставщика».

В такой ситуации недостаточно ограничиться созданием одного единственного отношения (Поставщик, Продукт, Покупатель), так как при обновлении данных могут возник нуть проблемы, связанные с избыточностью. если рас сматривать связь, изображенную на рис. 2-27 и придерживаться сфор мулированного выше принципа о связи поставщика, продукта и за казчика, то внесение записи Maison, Aniseed Syrup, потребует также внесения второй записи Liquids, Aniseed Syrup, Berglunds В самом деле, заказчик решил, что ему не хватает продукта Aniseed Syrup (анисо вый сироп). Он решил покупать его у поставщика Ma Maison (Мама ша Мейсон). Но его поставщиком уже является компания Liquids» («Экзотические Следовательно, согласно сформу лированному принципу, придется «Экзотическим напиткам» постав лять «Berglunds еше и анисовый сироп.

Exotic Aniseed Liquids 2-27. Данное отношение не находится в пятой нормальной форме Декомпозиций на три различных отношения: Supplier Product, Pro и (Поставщик — Продукт, Продукт Покупатель и Покупатель — устраняет проблему избы точности, но приводит к возникновению иных трудностей. Если вам нужно получить исходные данные, то придется соединить меж ду собой все три новых Если попытаться соединить толь ЧАСТЬ ко два отношения, в результате будут получены совершенно невер ные данные.

С точки зрения системного архитектора, это сложная проблема.

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

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

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

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

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

Основные понятия и определения Прежде всего, дадим определения основных терминов. Сущности, между которыми существуют связи, называются участниками (par ticipants), а число участников связи — размерностью (degree) связи.

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

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

ЧАСТЬ 1 баз данных Тот же самый принцип часто используется при как слабых (то есть таких, участие которых в связи являет ся или обычных (участие их в связи является частичным).

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

Подобная классификация положена в основу метода составления ди аграмм «сущности — связи», предложенного (Chen).

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

Рис. 3-1. Различия между слабыми и В некоторых случаях полезно разделить все связи на два типа — А» или «входит в А») и Принцип такого разделения весьма прост, мы проиллюстрируем его на примере сущнос тей В и С: В либо IsA С, либо С. Например, для сущностей Employee (Сотрудник) и (Баскетбольная команда) может быть оп ределена связь BasketballTeam (сотрудник является членом баскетбольной команды);

для сущностей Employee и Address (Адрес) мо жет быть определена связь Employee Address. Конечно, английс кие термины и «Has» не всегда правильно описывают природу зи между сущностями. Например, если связь между Employee и (Счет-фактура) определена как Employee HasA SalesOrder, это отнюдь не означает, что сотрудник обладает счетом — на самом деле он выписыва ет счет. Но все же при семантическом анализе очевидно, что связь меж ду Employee и SalesOrder не может быть IsA SalesOrder — это допущение слишком далеко от реальности.

Кроме того, классификация участия в связи подразумевает указа ние связи: является ли для сущности участие в данной связи обязательным. Здесь возникают сложности, посколь ГЛАВА ку проектируемой системы, осуществляемая механизмом СУБД, существенно отличается от домена предметной области. Мы увидим, какие трудности могут при этом возникнуть, когда перейдем к рассмотрению методов реализации целостности данных в главе 4.

Максимальное число экземпляров одной сущности, которое мо жет быть связано с экземпляром другой сущности, мы будем назы вать мощностью данной связи. (Следует отметить, что применитель но к связям понятия и имеют несколько иной смысл, чем применительно к Существуют три основных разновидности мощности связей: «один к одному», «один ко многим» и «многие ко Для указания мощности и обязательности связей я использую ус ловные обозначения, показанные на рис. 3-2. На мой взгляд, техника представления связей между сущностями «птичья лапа» (о которой рассказывалось в главе 1) — наиболее простой и понятный из всех способов представления, им удобно пользоваться при обсуждении проекта системы с заказчиком. Конечно, существуют и другие мето ды представления, имеющие свои преимущества, и вы можете выб рать тот, который вам больше нравится.

Связи изображаются в виде линий между Сущности изображены в прямоугольниках Одна черточка на линии, связь, означает «один» Знак «птичья лапа» означает Кружком отмечена необязательная связь (иногда этот символ читается как «ноль») Символы могут быть скомбинированы:

это сочетание символов или много» Рас. 3-2. Так обозначают обязательность и связей па ЧАСТЬ 1 Теория баз Моделирование связей После того как вы определили, что данная связь существует в систе ме, приступайте к ее моделированию, включая атрибуты одного от ношения (ссылочное отношение, primary relation) в другое ся отношение, foreign relation), как показано на рис. 3-3.

Рис. 3-3. Атрибуты ссылочного отношения (Orders) включаются в отношение Вы, несомненно, заметили некоторые различия между этой и фор диаграммой «сущности — рис. 1-6. Во-первых, ат рибуты не представлены как отдельные объекты. На этом этапе про ектирования нас интересуют связи между сущностями, а не их струк тура. Обозначение же на диаграмме атрибутов усложняет схему, перегружает ее лишними деталями.

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

Как я уже упоминала, данный диаграмм очень удобен при обсуждении с клиентами деталей реализации системы. Такие диаг раммы легко строить вручную с помощью различных средств постро ения диаграмм, например Visio Professional или Flowcharter 7. В состав Microsoft Access, Microsoft SQL Server и Microsoft Visual Basic входят средства построения диаграмм, которыми вы мо жете воспользоваться вместо или дополнительно к описанной здесь методике.

Использование интерактивных инструментов: окна связей между сущностями в Access (для файла механизма базы данных Mic rosoft Jet) или диаграмм баз данных (в том случае, если база данных реализуется средствами SQL Server). — обладает очевидными ГЛАВА 3 Связи Не женат Женат Разведен Вдовец (разведена) (вдова) Рис. 3-5. Диаграмма состояний перехода: возможные варианты семейного положения Но разрабатываемая модель должна отражать лишь семейное реализовать сущности абстрактного отноше ния, чтобы проследить изменения семейного положения и прове рить их правильность, совершенно излишне. Если же все-таки для вас важна что Джон и Мери Смит поженились в и развелись в 1972 г., после чего Мери снова вышла замуж в 1975 и овдовела в г., то потребуется использовать сущности абстракт ного отношения.

Связи «один к одному» Это, пожалуй, самый простой тип связей. «один к одному» между сущностями X и Y — это такие связи, при которых каждый экземпляр X может быть связан только с одним ром сущности Y. Большинство связей типа являются связями «один к одному», другие примеры весьма редки. Если при проекти ровании системы вы решили выбрать связь «один к одному» между некоторыми сущностями, убедитесь, что эта связь не будет изменять ся на протяжении всего срока эксплуатации системы, или что подоб ное изменение окажется несущественным и эта связь не будет инте ресовать вас в дальнейшем. Предположим, вы создаете базу данных служебных в некоем здании, где в каждом кабинете на ходится только один сотрудник. Такая связь будет связью к одному» (рис. 3-6).

Employee Office Building Рис. 3-6. Между сущностями Office (кабинет) и Employee (сотрудник) существует связь к одному» ЧАСТЬ 1 Теория данных Но подобная связь между Office (Кабинет) и Employee (Сотрудник) будет правильной лишь до определенного момента вре мени. Очевидно, что рано или поздно в кабинете соберется не сколько сотрудников. (Расположение кабинетов в здании также мо жет измениться, но мы сейчас не берем это во внимание). Используя связь «один к одному», как показано на рис. 3-6, вы получите про стую модель служебных помещений, имеющихся в. здании, однако проследить историю сотрудников из одного кабинета в другой в рамках этой модели не сможете. Возможно, подобная про блема вас просто не волнует. Например, если вы разрабатываете сис тему для рассылки все. что необходимо знать куда направлять корреспонденцию, адресованную Джейн (Jane Doe), а информация о том, куда направлялась эта корреспонденция три месяца тому назад, для вас совершенно бесполезна. Но если вы проектируете систему для агентства, работающего с недвижимостью, информация о том, кто и когда занимал данное помещение, окажет ся очень нужной для составления различных отчетов — надо же знать, насколько часто сменяются арендаторы помещения.

Хотя «один к одному» в реальном мире встречаются доволь но редко, в баз данных они широко используются, например, чтобы уменьшить число атрибутов в отношении, а также при моделировании подклассов сущностей. Существует ограничение числа полей в таблице: для механизма СУБД Microsoft Jet оно не дол жно превышать 255, а для SQL Server — 250. Обычно модели данных не выходят за рамки этих ограничений, поскольку таблицы с таким огромным числом полей встречаются крайне редко. Однако мне при ходилось сталкиваться с системами (они были предназначены для медицинских и научных учреждений), где у одной имелось более 255 уникальных И у разработчиков не было иного выбора, как создать новое отношение с некоторым произвольным подмножеством и определить связи «один к одному» меж ду этим и исходным отношением.

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

Такую структуру проще всего однако она далека от идеала. Атрибуты сущности Answer (Ответ) представляют собой повто ряющуюся группу, и поэтому нельзя считать, что отношение находит ся в первой нормальной форме. Модель на рис. 3-8 намного удачней.

3- 7. для создания моделей тестов и опросных листов, далеко не идеальна D Description Picture Рис. 3-8. Эта структура, хотя с точки зрения реализации, лучше для моделирования тестов и опросных листов Реализация сущностей как ков интересный случай применения отношений «один к — классы-наследники для Эта концепция заимствована из объектно-ориентированного программирования. Чтобы наглядней представить себе преимущества классов-наследников, сначала рас смотрим наиболее простой и пример их применения.

В базе данных которая входит в комплект поставки Microsoft Access, каждый продукт связан с категорией продукта (рис. 3-9).

Рис. 3-9. В базе данных Northwind каждый продукт связан с категорией продукта Наличие связи с отношением Categories позволяет сгруппировать продукты, например, для получения отчетов. Однако при реализации системы, представленной на рис. 3-9, вы можете иметь дело только с ЧАСТЬ 1 Теория баз данных продуктом как таковым, а не с сущностью его отдельной категории.

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

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

Г) Beverages Condiments Products Meat/Poultry Seafood Grains/ Confections Produce Cereas Рис. 3-Ю. Данная модель позволяет все атрибуты, свойственные категории Представьте себе, например, процесс проверки, правильно ли пользователь ввел код продукта. В данной модели он выражается сле дующим образом: «если данный код присутствует в отношении или в отношении у, Это ничуть не лучше, чем запрос к повторяю щимся группам о которых шла речь в главе 2. Кроме того, в процессе реализации могут возникнуть нарушения целостности дан ных, когда некоторые атрибуты применимы только к одной катего рии продуктов. Например, (число бутылок или дру гой тары е упаковке) — атрибут, применимый к категории продуктов 3 Связи Beverages совершенно не применим к категории Dairy (Молочные продукты) — и категория отдельного продукта изменяется. Что делать в подобной ситуации? Удалять все старые зна чения? А если изменение было сделано по ошибке, и пользователь хочет немедленно его отменить?

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

Beverages Condiments DairyProducts Seafood Grains/ Confections Produce Cereals Рис. 3-11. Модель, в которой используется классов, сочетает в себе все преимущества моделей, показанных рис. 3-9 и Бесспорно, реализация как классов-наследников весьма изящный прием. Но ее практическая реализация может ока заться весьма непростым делом. Приведу только один пример: для отчета, который содержит сведения о продукте, ная условная обработка данных, чтобы отображались только поля, от к данному классу-наследнику. Задача в принципе разре шимая, но прежде чем приступать к ее реализации, нужно подумать, стоит ли вообще это делать.

1 Теория В большинстве случаев я стараюсь не допускать чрезмерного уп модели данных лишь для того, чтобы облегчить задачу про граммистам. Но нельзя и в другую крайность — усложнять модель, когда в этом нет никакой необходимости. Если нужно всего лишь создать возможность группировать сущности или распределять их по категориям для составления отчетов, то очевидно, излишне ре ализовать сущности в виде В этом случае струк тура, представленная на рис. 3-9, будет адекватной.

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

ПРИМЕЧАНИЕ В таких случаях внешний ключ, для клас сов-наследников, часто является поскольку не име ет смысла определять для собственные идентифи каторы.

Pages:     || 2 | 3 | 4 | 5 |   ...   | 6 |



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

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