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

Переводы статьи Переводы статьи
Код статьи: 100139 - Vizualiza?i produsele pentru care se aplic? acest articol.
Начинающий пользователь: Требует знания интерфейса пользователя для однопользовательского режима.

Развернуть все | Свернуть все

В этой статье

Аннотация

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

ПРИМЕЧАНИЕ: Корпорация Майкрософт также предлагает веб-трансляцию, посвященную основам нормализации баз данных. Для просмотра этой веб-трансляции, посетите следующий веб-узел корпорации Майкрософт:ПРИМЕЧАНИЕ: Для просмотра этих сведений для Microsoft Access 2000, обратитесь к следующей статье Microsoft Knowledge Base:
209534 ACC2000: Основы нормализации баз данных

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ: В описаниях ниже приведены примеры.

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

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

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

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

  • Создайте отдельные таблицы для наборов значений, которые применяются к нескольким записи.
  • Свяжите эти таблицы с внешним ключом.
Записи не должны зависеть от ничего, кроме первичного ключа таблицы (составного ключа, если это необходимо). Например рассмотрим заказчика адрес в системе учета. Адрес необходим для Таблицу Customers, но также путем заказов, доставки, накладных, счетов Расчеты с клиентами и коллекции таблиц. Вместо сохранения клиента адрес как отдельный элемент в каждой из этих таблиц, поместить его в один можно поместите в таблицу клиентов или в отдельной таблице Addresses.

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

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

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

ИСКЛЮЧЕНИЕ: Соблюдение до третьей нормальной формы теоретически желательно, но не всегда практично. Если у таблицы Customers и вы хотите исключить все возможные зависимости представителях, необходимо создать отдельные таблицы для города, ПОЧТОВЫЕ индексы, продажи Представители, классы клиентов и фактор, который может дублирование в нескольких записях. В теории является нормализация стоит использования; Тем не менее много маленьких таблиц может привести к снижению производительности или превышать открытые емкости памяти и файлов.

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

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

Четвертая нормальная форма, также называемый Бойса Codd обычная форма (BCNF), и существует пятая нормальная форма, но редко рассматриваются в практику Дизайн. Несоблюдение этих правил может привести к менее чем идеально подходит проектирование базы данных, но не влияют на функциональность.
               **********************************
                 Examples of Normalized Tables
               **********************************

 Normalization Examples:

 Unnormalized table:

    Student#   Advisor   Adv-Room  Class1   Class2   Class3
    -------------------------------------------------------
    1022       Jones      412      101-07   143-01   159-02
    4123       Smith      216      201-01   211-02   214-01
				
  1. Первой нормальной форме: Нет ГРУПП ПОВТОРЯЕТСЯ

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

    Электронные таблицы часто используются третье измерение, но таблиц не следует. Другой способ, чтобы рассмотреть эту проблему: с один ко многим связь, следует размещать в одном одной стороны и разные стороны Таблица. Вместо этого создайте другую таблицу в первой нормальной форме устраняя повторяющуюся группу (Class #), как показано ниже:
           Student#   Advisor   Adv-Room    Class#
           ---------------------------------------
           1022      Jones      412       101-07
           1022      Jones      412       143-01
           1022      Jones      412       159-02
           4123      Smith      216       201-01
           4123      Smith      216       211-02
           4123      Smith      216       214-01
    					
  2. Вторая нормальная форма: Устранение ИЗБЫТОЧНЫХ данных

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

    Вторую нормальную форму представляют следующие две таблицы:
        Students:   Student#    Advisor   Adv-Room
                    ------------------------------
                    1022        Jones       412
                    4123        Smith       216
    
        Registration:   Student#    Class#
                        ------------------
                        1022        101-07
                        1022        143-01
                        1022        159-02
                        4123        201-01
                        4123        211-02
                        4123        214-01
    					
  3. Третья нормальная форма: ИСКЛЮЧИТЬ все данные, не ЗАВИСЯЩИХ от ключа

    В последнем примере — Adv-Room (номер помощник по office) функционально зависимо от атрибута Advisor. Решение заключается в Перемещение этого атрибута из таблицы «Студенты» факультет как показано ниже:
        Students:   Student#    Advisor
                    -------------------
                    1022        Jones
                    4123        Smith
    
        Faculty:    Name    Room    Dept
                    --------------------
                    Jones   412     42
                    Smith   216     42
    					

Ссылки

Для получения дополнительных сведений о разработке базы данных щелкните следующий номер статьи базы знаний Майкрософт:
234208 ACC2000: «Общее представление О разработке реляционной базы данных» документ доступен в центре загрузки
«Руководство разработчика FoxPro 2», Гамильтон м. Ahlo мл et al. страниц 220-225, M & T книг, 1991 г.

«С помощью доступа для Windows,» Роджер Jennings страниц Que 799-800 Корпорации, 1993 года

Свойства

Код статьи: 100139 - Последний отзыв: 1 июня 2011 г. - Revision: 4.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft Access 1.0 Standard Edition
  • Microsoft Access 1.1 Standard Edition
  • Microsoft Access 2.0 Standard Edition
  • Microsoft Access 97 Standard Edition
Ключевые слова: 
kbinfo kbusage kbmt KB100139 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:100139
Заявление об отказе относительно содержимого статьи о продуктах, поддержка которых прекращена
Эта статья содержит сведения о продуктах, поддержка которых корпорацией Майкрософт прекращена. Поэтому она предлагается как есть и обновляться не будет.

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

 

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