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

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

Как и в других главах Практического руководства по SQL, в этой главе в качестве примера мы будем использовать базу данных bookbiz- Чтобы освоить материал этой главы и разобраться в структуре базы bookbiz, вам потребуется изучить команду SQL CREATE и познакомиться с процессом определения данных.

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

Как подходить к проектированию базы данных

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

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

Мы попытаемся объяснить вам, как нужно проектировать базы данных на интуитивном уровне, а также кратко обсудим такие методы проектирования, как нормализация (normalization) и моделирование зависимостей (entity-relationship modeling).

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

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

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

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

быть собраны вместе с помощью операции объединения. Этот процесс называется декомпозицией без потерь (non-loss decomposition) и просто означает разделение таблицы на несколько меньших таблиц без потери информации.

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

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

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

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

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

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

3. В ходе работы обязательно записывайте все свои конструктивные решения либо на бумаге, либо с помощью текстового редактора. Разработчики баз данных обычно начинают с чистого листа, постепенно создавая макет таблиц и связей между ними, называемый структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).

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

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

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

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

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

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

Что такое хорошая структура

Хорошая структура - это, в первую очередь, прозрачная структура. Проще говоря, хорошая структура

максимально упрощает ваше взаимодействие с базой данных;

гарантирует непротиворечивость данных;

выжимает максимум производительности из вашей системы.

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

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

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