W Cat - SQL за 24 часа

• Каким образом данные в базе данных должны быть сгруппированы?

• К каким данным доступ будет требоваться чаще всего?

• Как данные будут связаны?

• Какие меры следует принять для того, чтобы обеспечить правильность данных?

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

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

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

Обычно в процессе нормализации используются следующие три нормальные формы.

• Первая нормальная форма.

• Вторая нормальная форма.

• Третья нормальная форма.

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

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