W Cat - SQL за 24 часа

На рис. 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.

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

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