CREATE TABLE EMPLOYEEJTBL AS (SSN NUMBER(9) NOT NULL,
LAST_NAME VARCHAR2(20) NOT NULL
FIRST_NAME VARCHAR2(20) NOT NULL,
MIDDLE_NAME VARCHAR2(20) NOT NULL, ST ADDRESS VARCHAR2(30) NOT NULL, CITY CHAR(20) NOT NULL, STATE CHAR2) NOT
NULL, ZIP NUMBER(4) NOT NULL, DATE HIRED DATE) STORAGE
(INITIAL 3K, NEXT IK ) ;
2. Можно ли удалить столбец из таблицы?
3. Что будет, если в оператор CREATE TABLE не включить ключевое слово STORAGE?
1. Ознакомьтесь с Приложением В, "Операторы CREATE TABLE для примеров книги" и проанализируйте приведенные там операторы.
4-й час Процесс нормализации
На этом уроке вы ознакомитесь с процессом разделения сырой базы данных на логические единицы, называемые таблицами. Этот процесс называют процессом нормализации.
Мы обсудим преимущества и недостатки нормализованных баз данных, в частности, получение вследствие нормализации гарантий целостности данных за счет скорости работы базы данных.
Основными на этом уроке будут следующие темы.
• Что такое нормализация?
• Преимущества нормализации
• Преимущества денормализации
• Инструкции по проведению нормализации
• Три нормальные формы
• Проектирование баз данных
Нормализация - это процесс сокращения повторений информации в базе данных. Нормализуются в базе данных не только данные, но и имена, включая имена объектов и форм.
Ненормализованная база данных может содержать данные, содержащиеся в нескольких таблицах без всяких на то причин. Это может быть неприемлемо, например, с точки зрения безопасности, использования дискового пространства, удобства обновления базы данных и, что более важно, с точки зрения целостности данных. Ненормализованная база данных - это база данных, не разделенная на меньшие, логически единые и более управляемые таблицы.
На рис. 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.