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

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

Microsoft Access 97 версии этой статьи См 100139.
Для доступа К Microsoft версия данной статьи в 2002 г. см. 283878.
Развернуть все | Свернуть все

В этой статье

Аннотация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нормализация пример таблицы

Следующие шаги описывают процесс нормализации вымышленной Таблица студента.
  1. Таблица до нормализации:
    Свернуть эту таблицуРазвернуть эту таблицу
    Student #Помощник по настройке ядраAdv-RoomClass1Class2Класс_3
    1022Джонс412101-07143-01159-02
    4123Иванов216201-01211-02214-01
  2. Первая нормальная форма: Нет повторяющихся групп

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

    Электронные таблицы часто используют третье измерение, но таблиц не следует. Другой способ просмотра Такая ситуация с отношением «один ко многим», не помещайте одной стороны и Многие стороны в той же таблице. Вместо этого создайте другую таблицу в первый обычный форма, устранив повторяющуюся группу (Class #), как показано ниже:
    Свернуть эту таблицуРазвернуть эту таблицу
    Student #Помощник по настройке ядраAdv-RoomКласс #
    1022Джонс412101-07
    1022Джонс412143-01
    1022Джонс412159-02
    4123Иванов216201-01
    4123Иванов216211-02
    4123Иванов216214-01
  3. Вторая нормальная форма: Устранение избыточных данных

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

    Демонстрируются следующие две таблицы во второй обычной форме:

    Студенты

    Свернуть эту таблицуРазвернуть эту таблицу
    Student #Помощник по настройке ядраAdv-Room
    1022Джонс412
    4123Иванов216

    Регистрация

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

    В последнем примере — Adv-Room (номер помощник по office) функционально зависимо от атрибута Advisor. Решение заключается в перемещении атрибут из таблицы «Студенты» факультета таблицу, как показано ниже:

    Студенты

    Свернуть эту таблицуРазвернуть эту таблицу
    Student #Помощник по настройке ядра
    1022Джонс
    4123Иванов

    Факультет

    Свернуть эту таблицуРазвернуть эту таблицу
    ИмяКомнатыОтдел
    Джонс41242
    Иванов21642

Ссылки

Ahlo м. Гамильтон, Рэнди Браун и Питер Colclough. FoxPro 2: Руководство для разработчиков: экспертную поддержку для промышленного программирования. John Wiley & сыновьями, октябрь 1991 года. 220 Страниц-225.

Jennings, Роджер. С помощью Access 1.1 для Windows. Корпорация QUE июля 1993 г. 799 Страниц-800.

Свойства

Код статьи: 209534 - Последний отзыв: 17 сентября 2011 г. - Revision: 6.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft Access 2000 Standard Edition
Ключевые слова: 
kbdatabase kbdesign kbinfo kbusage kbmt KB209534 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:209534

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

 

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