W Cat - SQL за 24 часа

Целью второй нормальной формы является выделение данных, только отчасти зависящих от ключа, и помещение этих данных в другую таблицу. Вторая нормальная форма показана на рис. 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.

Рис. 4.3. Вторая нормальная форма

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

Нормализация имеет целый ряд. преимуществ. Среди них отметим следующие.

• Лучшая общая организация базы данных.

• Сокращение числа ненужных повторений данных.

• Согласованность данных внутри базы данных.

• Более гибкая структура базы данных.

• Эффективные возможности обеспечения безопасности и надежности базы данных.

Рис, 4.4. Третья нормальная форма Процесс нормализации улучшает организацию базы данных, облегчая работу с базой данных всем, начиная от простых пользователей до администратора, который отвечает за общее управление объектами базы данных. Уменьшается число повторений данных, что упрощает структуру данных и экономит дисковое пространство. Из-за сокращения дублирования данных уменьшается вероятность их несогласованности. Например, в одной таблице имя персоны может храниться в виде STEVE SMITH, а в другой - STEPHEN R. SMITH. Поскольку в результате нормализации база данных разделяется на ряд более мелких таблиц, модифицировать существующие структуры становится проще. Гораздо проще изменить небольшую таблицу с малым количеством данных, чем большую таблицу, содержащую все жизненно важные для базы данных значения. Наконец, повышается безопасность в том смысле, что администратор базы данных получает возможность разрешить различным пользователям доступ только к ограниченному списку таблиц. Нормализация упрощает управление безопасностью.

Целостность данных - это гарантия согласованности и надежности данных в базе данных.

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

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

КЛЮЧОМ, ССЫЛаЮЩИМСЯ на CUST_ID ТабЛИЦЫ CUSTOMER_TBL.

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

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

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

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

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

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

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