Tooprogram.ru

Компьютерный справочник
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Нормализация базы данных access

Нормализация данных с помощью анализа таблиц

Примечание: Мы стараемся как можно оперативнее обеспечивать вас актуальными справочными материалами на вашем языке. Эта страница переведена автоматически, поэтому ее текст может содержать неточности и грамматические ошибки. Для нас важно, чтобы эта статья была вам полезна. Просим вас уделить пару секунд и сообщить, помогла ли она вам, с помощью кнопок внизу страницы. Для удобства также приводим ссылку на оригинал (на английском языке).

Иногда при импорте исходные данные неправильно разбиваются на связанные таблицы. Чтобы использовать Access максимально эффективно, нужно нормализовать данные, то есть разделить их на таблицы, каждая из которых посвящена чем-то одному и которые связаны между собой ключевыми сведениями. Средство анализа таблиц позволит вам решить эту критическую задачу. Откройте на ленте вкладку Работа с базами данных, а затем в группе Анализ нажмите кнопку Анализ таблицы. Запустится мастер, который поможет вам выполнить этот процесс.

Примечание: Сведения в этой статье применяется только к классической базы данных Microsoft Access (MDB или ACCDB).

1. исходная таблица

2. таблицы, созданные средством анализа таблиц

3. запрос, созданный средством анализа таблиц

4. список подстановки

Если в вашей База данных Microsoft Access есть таблица, в одном или нескольких полях которой повторяются сведения, разбейте ее на связанные таблицы с помощью средства анализа таблиц, чтобы хранить информацию более безопасно и эффективно. Этот процесс называется нормализацией.

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

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

Если вы измените поле, которое повторяется в запросе, все строки с таким значением обновятся автоматически, потому что на самом деле вы изменяете одно из полей базовой таблицы запроса.

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

Формы и отчеты, которые были ранее на основе исходной таблицы будет автоматически основан запрос сейчас, поскольку мастер назначает имя исходной таблицы для запроса и переименовывает таблицы.

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

Теория проектирования баз данных

Ссылочная целостность

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

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

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

Многие СУБД блокируют действия пользователя, которые могут привести к нарушению связей. Нарушение хотя бы одной такой связи делает информацию в БД недостоверной. Если мы, например, удалили Иванова И.И., то теперь номер 1 принадлежит Петрову П.П.. Имеющиеся связи указывают, что он сдал экзамены по математике и физике, но не сдавал экзаменов по русскому языку и литературе. Достоверность данных нарушена. Конечно, в таких случаях в качестве ключа обычно используют счетчик — поле автоинкрементного типа. Если удалить запись со значением 1, то другие записи не изменят своего значения, значение 1 просто невозможно будет присвоить какой-то другой записи, оно будет отсутствовать в таблице. Путаницы в связях не случится, однако все равно подчиненная таблица будет иметь «потерянные» записи, не связанные ни с какой записью главной таблицы. Механизм ссылочной целостности должен запрещать удаление записи в главной таблице до того, как будут удалены все связанные с ней записи в дочерней таблице .

Читать еще:  Запросы в access

Нормализация базы данных

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

Процесс нормализации данных заключается в устранении избыточности данных в таблицах.

Существует несколько нормальных форм, но для практических целей интерес представляют только первые три нормальные формы.

Первая нормальная форма ( 1НФ ) требует, чтобы каждое поле таблицы БД было неделимым (атомарным) и не содержало повторяющихся групп.

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

Под понятием повторяющиеся группы подразумевают поля, содержащие одинаковые по смыслу значения. Взгляните на рисунок:

Верно, такую таблицу можно сделать, однако она нарушает правило первой нормальной формы. Поля «Студент 1», «Студент 2» и «Студент 3» содержат одинаковые по смыслу объекты, их требуется поместить в одно поле «Студент», как в рисунке 1.4. Ведь в группе не бывает по три студента, правда? Представляете, как будет выглядеть таблица , содержащая данные на тридцать студентов? Это тридцать одинаковых полей ! В приведенном выше рисунке поля описывают студентов в формате «Фамилия И.О.». Однако если оператор будет вводить эти описания в формате «Фамилия Имя Отчество», то нарушается также правило неделимости. В этом случае каждое такое поле следует разбить на три отдельных поля, так как поиск может вестись не только по фамилии, но и по имени или по отчеству.

Вторая нормальная форма ( 2НФ ) требует, чтобы таблица удовлетворяла всем требованиям первой нормальной формы, и чтобы любое не ключевое поле однозначно идентифицировалось полным набором ключевых полей . Рассмотрим пример: некоторые студенты посещают спортивные платные секции, и ВУЗ взял на себя оплату этих секций. Взгляните на рисунок:

В чем здесь нарушение? Ключом этой таблицы служат поля «№ студента» — «Секция». Однако данная таблица также содержит отношение «Секция» — » Плата «. Если мы удалим запись студента № 110, то потеряем данные о стоимости секции по скейтборду. А после этого мы не сможем ввести информацию об этой секции, пока в нее не запишется хотя бы один студент. Говорят, что такое отношение подвержено как аномалии удаления , так и аномалии вставки.

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

Мы получили две таблицы, в каждой из которых не ключевые данные однозначно зависят от своего ключа.

Третья нормальная форма ( 3НФ ) требует, чтобы в таблице не имелось транзитивных зависимостей между не ключевыми полями, то есть, чтобы значение любого поля, не входящего в первичный ключ , не зависело от другого поля, также не входящего в первичный ключ . Допустим, в нашей студенческой базе данных есть таблица с расходами на спортивные секции:

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

Читать еще:  Запрос на выборку в ms access

Поле «Общая стоимость » в данном примере можно спокойно убрать из таблицы, ведь если потребуется вывести такие данные, нетрудно будет перемножить значения полей » Плата » и «Кол-во студентов», и создать для вывода вычисляемое поле .

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

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

Нормализация базы данных и ее формы

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

Приступая к изучению данного материала, рекомендуется ознакомиться с описанием учебной БД.

Материал этой статьи напрямую не относиться к изучению языка SQL, так как имеет отношение к проектированию баз данных (БД), но для общего понимания взаимосвязи хранимой в системе информации она будет полезна.

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

Нормализация баз данных заключается в приведении структуры хранения данных к нормальным формам (NF). Всего таких форм существует 8, но часто достаточным является соблюдение первых трех. Рассмотрим их более подробно на примере учебной базы данных. Примеры будут строится по принципу «что было бы, если было иначе, чем сейчас».

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

Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.

Рассмотрим таблицы сотрудников и телефонных линий.

Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:

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

Организации структуры таблиц с применением дополнительной связывающей избавляет от подобных проблем.

Помимо атомарности к первой нормальной форме относятся следующие правила:

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

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

Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.

Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.

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

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

Читать еще:  Условия отбора в запросах access

Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.

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

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

На приведенном примере таблицы сотрудников видно, что столбец «Супервайзер» имеет зависимость от столбца «Группа», а это значит, что при изменении значения поля группы, потребуется изменить значение поля супервайзера.

Все риски, которые были рассмотрены для 2NF, так же относятся к 3NF и устраняются переносом зависимых полей в отдельную таблицу.

Денормализация базы данных

Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.

Для баз данных, предназначенных для аналитики, часто выполняют денормализацию, чтобы укорить выполнение запросов.

Нормализация базы данных access

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

Все данные в реляционной базе данных хранится в однородных таблицах. Термин «однородный» означает, что в одной таблице все строки имеют одинаковую структуру. От правильности проектирования таблиц зависит простота эксплуатации созданной базы данных, возможность её развития в дальнейшем. Для получения «правильных» таблиц используется процесс нормализации.

      • Первая нормальная форма.
      • Вторая нормальная форма.
      • Третья нормальная форма.

Нормализация отношений — это процесс построения оптимальной структуры таблиц и связей в реляционной БД (процесс уменьшения избыточности информации).

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

Цели, которые преследуются при построении наиболее эффективной структуры данных:

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

Теория нормализации отношений работает с 5 нормальными формами таблиц. Каждая последующая форма должна отвечать требованиям предыдущих плюс некоторые дополнительные требования.


Первая нормальная форма (1НФ)

Таблица, находящаяся в первой нормальной форме должна отвечать следующим требованиям :

      • таблица не должна иметь повторяющихся записей;
      • в таблице должны отсутствовать повторяющиеся группы полей.

Для приведения к 1НФ можно использовать следующий алгоритм:

      1. Определить поле, которое можно назначить первичным ключом. Если такого поля нет, то добавить новое уникальное ключевое поле.
      2. Определить группы повторяющихся полей.
      3. Вынести группы повторяющихся полей в отдельные таблицы, в основной таблице остается одно поле для организации связи между таблицами.
      4. Назначить первичные ключи в новых таблицах . (В качестве ключевых полей можно использовать поля таблицы или добавить новое поле. Если ключевое поле имеет большой размер, предпочтительней добавлять новое поле.)
      5. Определить тип отношения между таблицами .

Пример. Пусть дана однотабличная БД

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

Приведем БД к 1НФ.

1. Добавим в таблицу поле Номер заказа, что позволит однозначно идентифицировать каждый из заказов.

2. Таблица содержит три группы повторяющихся полей:

Вынесем их в отдельную таблицу Клиенты

Вынесем их в отдельную таблицу Товары

    • Поля характеризующие производителя:
      • Фирма производитель,
      • Индекс фирмы производителя,
      • Адрес фирмы производителя.

Вынесем их в отдельную таблицу Производители

3. В таблицу Клиенты добавим новое поле Номер клиента, которое будет однозначно идентифицировать каждую запись таблицы.

    • В таблицу Товары добавим новое поле Номер товара.
    • В таблицу Производители также добавим новое поле Номер производителя.

4. Т.к. связь между таблицами происходит по совпадающим полям, добавим в таблицу Заказы поля Номер клиента и Номер товара, а в таблицу Товары поле Номер производителя для организации связи.

Ссылка на основную публикацию
Adblock
detector