На этом уроке вы ознакомитесь с процессом разделения сырой базы данных на логические единицы, называемые таблицами. Этот процесс называют процессом нормализации.
Мы обсудим преимущества и недостатки нормализованных баз данных, в частности, получение вследствие нормализации гарантий целостности данных за счет скорости работы базы данных.
Основными на этом уроке будут следующие темы.
• Что такое нормализация?
• Преимущества нормализации
• Преимущества денормализации
• Инструкции по проведению нормализации
• Три нормальные формы
• Проектирование баз данных
Нормализация — это процесс сокращения повторений информации в базе данных. Нормализуются в базе данных не только данные, но и имена, включая имена объектов и форм.
Ненормализованная база данных может содержать данные, содержащиеся в нескольких таблицах без всяких на то причин. Это может быть неприемлемо, например, с точки зрения безопасности, использования дискового пространства, удобства обновления базы данных и, что более важно, с точки зрения целостности данных. Ненормализованная база данных — это база данных, не разделенная на меньшие, логически единые и более управляемые таблицы.
На рис. 4.1 показана используемая в этой книге база данных до ее нормализации.
Рис. 4.1. "Сырая" база данных
Логическая организация базы данных
Любая база данных должна планироваться с учетом потребностей конечного пользователя. Логическая организация базы данных, выполняемая на основе логической модели, является процессом реорганизации данных в логично организованные группы легко управляемых объектов. Логическая организация данных должна помочь сократить повторения данных в-базе данных, а в идеале вообще избавиться от них. В конце концов, зачем одни и те же данные хранить в двух разных местах? Используемые в базе данных имена тоже должны быть стандартными и логичными.
Что нужно конечному пользователю?
Потребности конечного пользователя должны учитываться при планировании базы данных прежде всего. Ведь именно конечный пользователь будет с ней работать. Пользователю необходимо обеспечить простоту использования базы данных с помощью интерфейсного приложения (программы, дающей пользователю возможность обращаться к базе данных), а этого, как и оптимальной скорости доступа пользователя к данным, невозможно добиться, если потребности пользователя не учитываются.
Вот список некоторых из соответствующих вопросов, на которые нужно иметь четкие ответы при планировании базы данных.
• Какие данные должны храниться в базе данных?
• Каким образом пользователь будет осуществлять доступ к базе данных?
• Какие привилегии получит пользователь?
• Каким образом данные в базе данных должны быть сгруппированы?
• К каким данным доступ будет требоваться чаще всего?
• Как данные будут связаны?
• Какие меры следует принять для того, чтобы обеспечить правильность данных?
Данные не должны быть избыточными, и это значит, что повторения данных должны быть сведены к минимуму по нескольким причинам. Например, нет необходимости хранить домашний адрес в нескольких таблицах. При дублировании данных для них требуется дополнительное пространство. Кроме того, повышается вероятность ошибок, когда, например, адрес служащего в одной таблице не совпадает с его же адресом в другой. Как тогда решить, какая из таблиц содержит верные данные? Имеется ли у вас документ, по которому можно уточнить текущий адрес служащего? Даже если бы управление данными само по себе было простым делом, избыточность данных сделала бы его сложным.
В следующих разделах обсуждаются нормальные формы, лежащие в основе процесса нормализации баз данных.
Нормальная форма — это мера глубины, до которой должна быть выполнена нормализация базы данных.
Обычно в процессе нормализации используются следующие три нормальные формы.
• Первая нормальная форма.
• Вторая нормальная форма.
• Третья нормальная форма.
В этой последовательности нормальных форм каждая последующая зависит от результатов нормализации, выполненных
предыдущей. Например, чтобы выполнить нормализацию, используя вторую нормальную форму, необходимо сначала выполнить нормализацию, используя первую нормальную форму.
Целью первой нормальной формы является разделение базы данных на логические единицы, называемые таблицами. После того как таблицы будут сформированы, для большинства из них будут назначены ключевые поля. Посмотрите на рис. 4.2, и вы увидите, как была преобразована с помощью первой нормальной формы сырая база данных, показанная на предыдущем рисунке.
Как видите, чтобы прийти к первой нормальной форме, база данных была разбита на несколько логических единиц, в каждой из которых определен ключ и нет повторяющихся групп. Вместо одной большой таблицы теперь имеются более простые таблицы EMPLOYEEJTBL, CUSTOMER_TBL И PRODUCTSJTBL. КЛЮЧИ В Таблицах
размещаютася первыми: в данном случае это EMP_ID, CUST_ID и PROD_ID.
Целью второй нормальной формы является выделение данных, только отчасти зависящих от ключа, и помещение этих данных в другую таблицу. Вторая нормальная форма показана на рис. 4.3.
Рис. 4.2. Первая нормальная форма
Из рисунка видно, что вторая нормальная форма получается из первой нормальной формы в результате дальнейшего разделения еще двух таблиц на более мелкие.
Таблица EMPLOYEE_TBL была разделена на таблицы. EMPLOYEE_TBL и EMPLOYEE_PAY_TBL. Персональная информация о служащем зависит от ключа (EMP_ID), поэтому эта информация осталась в таблице EMPLOYEE_TBL (EMP_ID,
LAST_NAME, MIDDLE_NAME, ADDRESS, CITY, STATE, ZIP, PHONE И PAGER). ОстаВШЭЯ-ся информация, которая только отчасти зависит от EMP_ID (каждого конкретного служащего), размешена в таблице EMPLOYEE_PAY_TBL (EMP_ID, POSITION,
POSITION_DESC, DATE_HIRE, PAY_RATE, DATE_LAST_RAISE). Обратите внимание на то, что обе таблицы содержат столбец EMP_ID. Для каждой из этих таблиц он является ключевым и используется для связывания данных в этих таблицах.
Таблица CUSTOMER_TBL была разделена на две таблицы, названные CUSTOMER_TBL и ORDERSJTBL. При этом было сделано то же самое, что и с таблицей EMPLOYEE_TBL. Столбцы, слабо зависящие от ключа, были выделены в отдельную таблицу. Информация о заказах клиента зависит от CUST_ID, но не зависит напрямую от общей информации о клиенте из исходной таблицы.
Целью третьей нормальной формы является удаление из таблиц данных, не зависящих от ключа. Третья нормальная форма представлена на рис. 4.4.
Для демонстрации возможностей третьей нормальной формы таблица EMPLOYEE_PAY_TBL была разделена на две таблицы, одна из которых содержит действительную информацию об оплате работы служащего, а во второй содержится описание его должности, которому совсем нет необходимости размещаться в таблице EMPLOYEE_PAY_TBL. Столбец POSITION_DESC теперь оказывается совсем не зависящим от ключа EMP_ID.
Соглашения о присвоении имен оказываются исключительно важными для проведения нормализации. Имена баз данных должны быть информативными и соответствовать типу хранимой в них информации. Могут быть установлены и внутрикорпоративные соглашения об именах, которые могут касаться не только имен таблиц внутри базы данных, но и имен пользователей, файлов и других подобных объектов. Разработка и внедрение соглашений об именах должно быть одним из первых шагов компании в направлении успешного управления базами данных.
Нормализация имеет целый ряд. преимуществ. Среди них отметим следующие.
• Лучшая общая организация базы данных.
• Сокращение числа ненужных повторений данных.
• Согласованность данных внутри базы данных.
• Более гибкая структура базы данных.
• Эффективные возможности обеспечения безопасности и надежности базы данных.
Процесс нормализации улучшает организацию базы данных, облегчая работу с базой данных всем, начиная от простых пользователей до администратора, который отвечает за общее управление объектами базы данных. Уменьшается число повторений данных, что упрощает структуру данных и экономит дисковое пространство. Из-за сокращения дублирования данных уменьшается вероятность их несогласованности. Например, в одной таблице имя персоны может храниться в виде STEVE SMITH, а в другой — STEPHEN R. SMITH. Поскольку в результате нормализации база данных разделяется на ряд более мелких таблиц, модифицировать существующие структуры становится проще. Гораздо проще изменить небольшую таблицу с малым количеством данных, чем большую таблицу, содержащую все жизненно важные для базы данных значения. Наконец, повышается безопасность в том смысле, что администратор базы данных получает возможность разрешить различным пользователям доступ только к ограниченному списку таблиц. Нормализация упрощает управление безопасностью.
Целостность данных — это гарантия согласованности и надежности данных в базе данных.
Ссылочная целостность попросту означает зависимость значений столбца одной таблицы от значений столбца другой таблицы. Например, чтобы разместить информацию о клиенте в таблице ORDERS_TBL, нужно, чтобы уже имелась запись о нем в таблице CUSTOMER_TBL. С помощью требований целостности можно также задавать ограничения на диапазон допустимых для столбца значений. Требования целостности должны задаваться при создании таблицы. Ссылочная целостность обеспечивается обычно с помощью ключевых полей и внешних ключей.
Как правило, внешний ключ представляет собой столбец таблицы, непосредственно ссылающийся на ключ другой таблицы с целью обеспечения ссылочной целостности. В предыдущем разделе столбец CUST_ID таблицы ORDERS_TBL является внешним
КЛЮЧОМ, ССЫЛаЮЩИМСЯ на CUST_ID ТабЛИЦЫ CUSTOMER_TBL.
Хотя большинство успешно работающих баз данных в некоторой степени нормализованы, нормализация имеет один существенный недостаток: замедление работы базы данных. Выполнение запроса или транзакции предполагает использование центрального процессора компьютера, памяти и операций ввода-вывода. Попросту говоря, в нормализованной базе данных для выполнения транзакций или запросов более интенсивно используется центральный процессор, требуется больше памяти и большее число операций ввода-вывода, чем в ненормализованной. В нормализованной базе данных требуется находить соответствующие таблицы и связывать данные для того, чтобы извлечь нужную информацию или обработать ее. Более подробно вопросы производительности баз данных обсуждаются в ходе урока 18, "Управление доступом к базе данных".
Денормализация — это процесс модификации структуры таблиц нормализованной базы данных с целью повышения производительности за счет допущения некоторой управляемой избыточности данных. Единственным оправданием денормализации является попытка повышения скорости работы базы данных. Де-нормализованная база данных — это не то же самое, что ненормализованная. Денормализация базы данных представляет собой процесс понижения нормализации на один-два уровня. Нормализация может существенно снизить скорость доступа к данным вследствие частых операций связывания таблиц. (Связывание таблиц обсуждается в ходе урока 13, "Объединение таблиц в запросах".) Денормализация предполагает объединение некоторых из ранее разделенных таблиц и создание таблиц с дубликатами данных с целью уменьшения числа связываемых таблиц при доступе к данным, что должно уменьшить число требуемых операций ввода-вывода и нагрузку на центральный процессор.
Однако за денормализацию нужно платить. В денормализованной базе данных повышается избыточность данных, что может повысить производительность, но потребует больше усилий для контроля за связанными данными. Усложнится процесс создания приложений, поскольку данные будут повторяться и их труднее будет отслеживать. Кроме того, осуществление ссылочной целостности оказывается не простым делом — связанные данные оказываются разделенными по разным таблицам. Существует золотая середина между нормализацией и денормализацией, но чтобы найти ее, требуется знание и природы хранимых данных, и специфических требований бизнеса соответствующей компании.
Относительно структуры базы данных необходимо принять непростое решение: нормализовать или не нормализовать — вот в чем вопрос. Всегда имеет смысл до некоторой степени нормализовать базу данных. Но насколько можно нормализовать базу данных без заметного ухудшения производительности? Ответ на этот вопрос зависит от конкретного приложения. Насколько велика база данных? Каковы ее цели и задачи? Кто будет ее использовать?
На этом уроке были рассмотрены три наиболее часто используемые нормальные формы, лежащие в основе нормализации концепции и целостности данных. Процесс нормализации складывается из многих этапов, по большей части необязательных, но важных с точки зрения производительности и надежности базы данных. Независимо от глубины нормализации, она всегда будет компромиссом между простотой управления и производительностью системы в целом. Конечное решение остается за теми, кто разрабатывает базу данных, они и будут ответственны за принятое решение.
Почему так уж необходимо учитывать интересы конечных пользователей при планировании базы данных?
Именно конечные пользователи являются теми экспертами, которые оценивают реальные данные базы данных, и именно поэтому интересы конечных пользователей должны учитываться в первую очередь при разработке любой базы данных. Проектировщики базы данных лишь помогают организовать данные.
Мне кажется, что нормализация все же предпочтительнее денормализации. Разве не так?
Нормализация может быть предпочтительной. Но, в зависимости от ситуации, может быть более предпочтительной и Денормализация. Не забывайте, что здесь выбор зависит от очень большого числа факторов. Наверное, вы сначала нормализуете свою базу данных, чтобы уменьшить число повторений, но после этого так же вероятно, что вы проведете частичную денормализацию, чтобы улучшить производительность.
Задания практических занятий разделены на тесты и упражнения. Тесты предназначены для проверки общего уровня понимания рассмотренного материала. Упражнения дают возможность применить на практике идеи, обсуждавшиеся в ходе текущего урока, в комбинации с идеями из предыдущих уроков. Мы рекомендуем ответить на тестовые вопросы и выполнить упражнения прежде, чем продолжать дальнейшее чтение книги. Ответы можно проверить по Приложению Б, "Ответы".
1. Верно ли следующее утверждение: "Нормализация — это процесс группировки данных в логически связанные группы?"
2. Верно ли следующее утверждение: "Отсутствие повторяющихся и избыточных данных и, таким образом, нормализация базы данных — в любом случае лучше всего?"
3. Верно ли следующее утверждение: "Если данные находятся в третьей нормальной форме, они автоматически находятся и в первой, и во второй нормальной формах?"
4. Какое главное преимущество имеет денормализованная база данных по сравнению с нормализованной?
5. Каковы основные недостатки денормализации?
1. Предположим, вам нужно организовать новую базу данных для небольшой компании. Возьмите следующие данные и нормализуйте их. Но не забывайте, что даже в малой компании данных бывает значительно больше, чем представлено здесь.
Служащие:
Анжела Смит, секретарь, 317-545-6789, просп. Широкий, 1, п. я. 73, Гринс-бург, шт. Индиана, 47890, $9,50 в час, приступила к работе 22 января 1996 г., идент. код 323149669.
Джек Ли Нельсон, продавец, ул. Главная, 3334, Браунсбург, шт. Индиана, 45687, 317-852-9901, $35000 в год, идент. код 312567342, работает с 28.10.95. Клиенты:
Дичь и охотничьи аксессуары Роберта, просп. Лафайет, 5612, Индианапо-лис, шт. Индиана, 46224, 317-291-7888, код клиента 432А.
Молочный бар Рида, 10-я Западная улица, Индианаполис, шт. Индиана, 46245, 317-271-9823, код клиента 117А.
Заказы:
Код клиента 117А, дата последнего заказа 20 декабря 1999 г., заказанный товар — салфетки, код товара — 661.