Вы ознакомились с примерами использования команды CREATE TABLE и с ее опциями, среди которых, в частности, параметры выделения таблице памяти. Вы научились модифицировать структуру уже созданной таблицы с помощью команды ALTER
TABLE. Хотя процесс управления таблицами базы данных и нельзя отнести к основным задачам использования SQL, мы считаем, что если вы узнаете больше о структуре и природе таблиц, вам легче будет освоить принципы доступа к таблицам, лежащие в основе манипуляций данными или осуществления запросов. Из следующих уроков вы узнаете об управлении с помощью SQL другими объектами базы данных, в частности, индексами таблиц и представлениями.
Вопросы и ответы
При создании таблицы обязательно ли в ее имени использовать суффикс _твь?
Определенно нет. Вас ничего не принуждают его использовать. Например, таблице с информацией о служащих можно назначить либо одно из следующих имен, либо любое другое, которое будет соответствовать хранимым в этой таблице данным:
EMPLOYEE EiMP_TBL EMPLOYEE TBL EMPLOYEE^TABLE WORKER
Почему при удалении таблицы так важно указывать имя соответствующей схемы?
Вот вам непридуманная история о молодом администраторе базы данных, удалившем таблицу. Один программист создал в рамках своей схемы таблицу с именем точно таким же, как у таблицы с производственной информацией. Прошло некоторое время и он из компании уволился. При попытке ликвидации его учетной записи оператор DROP USER вернул ошибку из-за каких-то принадлежащих программисту объектов, оставшихся в базе данных. Исследование проблемы показало, что таблица, созданная тем программистом, не нужна и по отношению к ней был применен оператор DROP TABLE.
Все прошло прекрасно, но возникла другая проблема - оказалось, что администратор применил оператор DROP TABLE, войдя в базу данных под именем производственной схемы. Как было бы хорошо, если бы администратор указал имя схемы или владельца удаляемой таблицы1 Да, была удалена не та таблица из не той схемы. На восстановление производственной базы данных потребовалось почти восемь часов.
Практикум
Задания практических занятий разделены на тесты и упражнения. Тесты предназначены для проверки общего уровня понимания рассмотренного материала. Упражнения дают возможность применить на практике идеи, обсуждавшиеся в ходе текущего урока, в комбинации с идеями из предыдущих уроков. Мы рекомендуем ответить на тестовые вопросы и выполнить упражнения прежде, чем продолжать дальнейшее чтение книги. Ответы можно проверить по Приложению Б, "Ответы".
Тесты
1. Будет ли работать следующий оператор CREATE TABLE? Если нет, то что нужно в нем исправить?
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. Первая нормальная форма