Описание основных приемов нормализации базы данных

Переводы статьи Переводы статьи
Код статьи: 283878 - Vizualiza?i produsele pentru care se aplic? acest articol.
Целевая аудитория — малоопытные пользователи. Материал, изложенный в этой статье, требует знания пользовательского интерфейса на компьютерах с одним пользователем.

Версия данной статьи для Microsoft Access 2000: 209534 (Эта ссылка может указывать на содержимое полностью или частично на английском языке).
Версия данной статьи для Microsoft Access 95 и Microsoft Access 97: 100139 (Эта ссылка может указывать на содержимое полностью или частично на английском языке).
Развернуть все | Свернуть все

В этой статье

Аннотация

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

Примечание. Корпорация Майкрософт также предлагает веб-трансляцию, посвященную основам нормализации баз данных. Чтобы просмотреть ее, посетите веб-узел Майкрософт по следующему адресу:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

Дополнительная информация

Описание нормализации

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

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

Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.

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

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

В описаниях ниже приведены соответствующие примеры.

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

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

Что произойдет при добавлении третьего поставщика? Добавление третьего поля нежелательно, так как для этого нужно изменять программу и таблицу, поэтому данный способ плохо адаптируется к динамическому изменению числа поставщиков. Вместо этого можно поместить все сведения о поставщиках в отдельную таблицу Vendors (поставщики) и связать товары с поставщиками с помощью кодов товаров или поставщиков с товарами с помощью кодов поставщиков.

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

  • Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям.
  • Свяжите эти таблицы с помощью внешнего ключа.
Записи могут зависеть только от первичного ключа таблицы (составного ключа, если необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.

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

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

Например, в таблицу Employee Recruitment (наем сотрудников) можно включить адрес кандидата и название университета, в котором он получил образование. Однако для организации групповой почтовой рассылки необходим полный список университетов. Если сведения об университетах будут храниться в таблице Candidates, составить список университетов при отсутствии кандидатов не получится. Таким образом, создайте вместо этого отдельную таблицу Universities и свяжите ее с таблицей Candidates при помощи ключа — кода университета.

Исключение. Выполнять нормализацию баз данных до третьей нормальной формы теоретически желательно, но не всегда практично. Например, для устранения всех возможных зависимостей между полями таблицы Customers придется создать отдельные таблицы для хранения сведений о городах, почтовых индексах, торговых представителях, категориях клиентов и любых других сведений, которые могут дублироваться в нескольких записях. С теоретической точки зрения нормализация желательна. Однако значительное увеличение числа маленьких таблиц может привести к снижению производительности СУБД или исчерпанию памяти и числа дескрипторов открытых файлов.

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

Другие нормальные формы

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

Пример нормализации таблицы

Ниже приведен пример нормализации таблицы с вымышленными данными о студентах.
  1. Таблица до нормализации:

    Свернуть эту таблицуРазвернуть эту таблицу
    Student#AdvisorAdv-RoomClass1Class2Class3
    1022Петров412101-07143-01159-02
    4123Иванов216201-01211-02214-01
  2. Первая нормальная форма: устранение повторяющихся групп

    Таблицы должны иметь только два измерения. Так как один студент изучает несколько курсов, эти курсы следует указать в отдельной таблице. Наличие полей Class1, Class2 и Class3 в приведенных выше записях свидетельствует о неудачном проектировании таблицы.

    Электронные таблицы часто включают третье измерение, но в таблицах баз данных оно использоваться не должно. Рассмотреть эту проблему можно также с помощью отношения «один — множество», тогда совет можно сформулировать следующим образом: не включайте в одну таблицу элементы, представляющие обе стороны данного отношения. Вместо этого создайте другую таблицу в первой нормальной форме, устранив повторяющуюся группу (Class#):

    Свернуть эту таблицуРазвернуть эту таблицу
    Student#AdvisorAdv-RoomClass#
    1022Петров412101-07
    1022Петров412143-01
    1022Петров412159-02
    4123Иванов216201-01
    4123Иванов216211-02
    4123Иванов216214-01
  3. Вторая нормальная форма: устранение избыточных данных

    Обратите внимание на то, что в приведенной выше таблице каждое значение Student# сопоставлено с несколькими значениями Class#. Значения Class# функционально не зависят от значений Student# (первичный ключ), а это означает, что данное отношение не нормализовано до второй нормальной формы.

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

    Таблица Students:

    Свернуть эту таблицуРазвернуть эту таблицу
    Student#AdvisorAdv-Room
    1022Петров412
    4123Иванов216


    Таблица Registration:

    Свернуть эту таблицуРазвернуть эту таблицу
    Student#Class#
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Третья нормальная форма: устранение данных, не зависящих от ключа

    В последнем примере значения Adv-Room (номер кабинета научного руководителя) функционально зависят от атрибута Advisor. Решить эту проблему можно, переместив данный атрибут из таблицы Students в таблицу Faculty (факультет):

    Таблица Students:

    Свернуть эту таблицуРазвернуть эту таблицу
    Student#Advisor
    1022Петров
    4123Иванов


    Таблица Faculty:

    Свернуть эту таблицуРазвернуть эту таблицу
    NameRoomDept
    Петров41242
    Иванов21642

Свойства

Код статьи: 283878 - Последний отзыв: 16 июля 2013 г. - Revision: 6.4
Информация в данной статье относится к следующим продуктам.
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Ключевые слова: 
kbinfo kbdesign kbdatabase kbhowto KB283878

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com