НОРМАЛИЗАЦИЯ  ДАННЫХ  В  MICROSOFT  ACCEESS

Салмиярова  Мария  Юрьевна

студент  2  курса,  экономического  факультета  СФ  БашГУ,  РФ,  Республика  Башкортостан,  г.  Стерлитамак

E-mail:  msalmiyarova@mail.ru

Юсупова  Расима  Разимовна

студент  3  курса,  экономического  факультета  СФ  БашГУ,  РФ,  Республика  Башкортостан,  г.  Стерлитамак

E-mail:  urasima93@mail.ru

Берзина  Дина  Владимировна

научный  руководитель,  ассистент  БашГУ,  РФ,  Республика  Башкортостан,  г.  Стерлитамак

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

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

Для  поддержания  баз  данных  (БД)  в  надежном  состоянии  используются  средства  поддержки  целостности.  Они  применяются  как  на  этапе  проектирования  (статистические)  так  и  в  процессе  работы  с  БД  (динамические).  Смысл  этих  ограничений  прост:  каждый  факт,  хранимый  в  БД,  должен  храниться  один-единственный  раз,  поскольку  дублирование  может  привести  к  несогласованности  между  копиями  одной  и  той  же  информации.  Устранение  избыточности  данных  является  одной  из  важнейших  задач  при  проектировании  БД  и  обеспечивается  нормализацией.

Нормализация  —  это  ограничения  на  формирование  таблиц,  которые  позволяют  устранить  дублирование,  обеспечивают  непротиворечивость  данных  и  уменьшает  трудозатраты  на  ведение  базы  данных  [1,  c.  21].  Смысл  процесса  нормализации  состоит  в  разложении  исходных  отношений  БД  на  более  простые.

При  использовании  ненормализованных  таблиц  возникают  проблемы,  приводящие  к  нарушению  целостности  данных:

·Избыточность  данных:  в  нескольких  записях  таблицы  повторяется  одна  и  та  же  информация.

·Аномалия  обновления:  несоответствие  информации  возникающее,  если  исправление  вносится  не  во  все  записи.

·Аномалия  удаления:  возникает  при  удалении  записей  из  ненормализованной  таблицы.

·Аномалия  ввода:  возникает  при  добавлении  в  таблицу  новых  записей  [2,  c.  27].

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

·Каждая  следующая  нормальная  форма  лучше  предыдущей  нормальной  формы.

·При  переходе  к  следующей  начальной  форме  свойства  предыдущих  форм  сохраняются  [2,  c.  26].

  Выделяют  следующие  нормальные  формы: 

·первая  нормальная  форма;

·вторая  нормальная  форма;

·третья  нормальная  форма;

·нормальная  форма  Бойса-Кода;

·четвертая  нормальная  форма;

·пятая  нормальная  форма.

Для  нормального  функционирования  база  данных  должна  удовлетворять  как  минимум  первым  трем  нормальным  формам.  Рассмотрим  их  более  подробно.

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

Переменная  отношения  находится  в  первой  начальной  форме,  если  все  его  атрибуты  имеют  единственное  значение  [1,  c.  22].

Например,  задано  следующее  отношение:

Поставка  (Поставщик,  Фамилия,  Город,  Регион,  Детали,  Названия_деталей,  Количество).

Это  отношение  не  находится  в  первой  начальной  форме,  так  как  атрибут  Детали  подразумевает  возможность  наличия  нескольких  деталей  в  записи,  относящейся  к  какому-то  конкретному  поставщику.

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

Атрибуты  с  повторяющимися  значениями  переведем  в  новые  атрибуты,  которые  не  будут  допускать  наличия  нескольких  значений  в  одной  записи.  Так  атрибут  Детали  заменит  атрибутом  №_детали,  а  Поставщик  заменим  №_поставки.

В  результате  получим  новую  сущность:

Поставка  (№_поставщика,  ФИО,  Город,  Регион,  №_детали,  Цвет,  Название,  Количество).

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

Рисунок  1.  Результат  приведения  к  первой  нормальной  форме

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

Переменная  отношения  находится  во  второй  нормальной  форме,  если  она  уже  находится  в  первой  форме,  и  каждый  его  описательный  атрибут  зависит  от  ее  потенциального  ключа  [1,  c.  23].

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

Определение  второй  начальной  формы  для  нашего  примера  не  соблюдается,  так  как  первым  ключом  является  {№_Поставщика,  №_Детали},  а  атрибут  Количество  зависит  от  отдельных  частей  первичного  ключа.  Нам  необходимо  разбить  таблицу  так,  чтобы  левые  части  функциональных  зависимостей  стали  первичными  ключами  новых  таблиц.  В  результате  выделятся  три  взаимосвязанные  сущности: 

Поставщик  (№_поставщика,  ФИО,  город,  регион);

Деталь  (№_детали,  название,  цвет);

Поставки  (№_поставщика,  №_детали,  количество).

Тогда  функциональная  зависимость  примет  следующий  вид,  представленный  на  рисунке  2.

Рисунок  2.  Результат  приведения  ко  второй  нормальной  форме

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

База  данных  находится  в  третьей  нормальной  форме,  если  она  уже  находится  во  второй  нормальной  форме,  и  каждый  не  ключевой  столбец  не  зависим  друг  от  друга  [1,  c.  23].

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

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

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

Рисунок  3.  Результат  приведения  к  третьей  нормальной  форме

В  результате  выделятся  четыре  взаимосвязанных  сущности:

Поставщик  (№_поставщика,  ФИО,  город).

Деталь  (№_детали,  название,  цвет).

Поставки  (№_поставщика,  №_детали,  количество).

Регионы  (Регион,  город).

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

Список  литературы:

1.Базы  даны:  учеб.  пособие  для  студ.  высш.  учеб.  заведений/  А.В.  Кузин,  С.В.  Левонисов.  2-е  изд.,  стер.  М.:  Издательский  центр  «Академия»,  2008.  —  320  с.

2.Базы  данных:  Учебно-методическое  пособие  для  студентов  высших  учебных  заведений,  обучающихся  по  направлениям  подготовки  «010400.62  —  Прикладная  математика  и  информатика»,  «010500.62  —  Математическое  обеспечение  и  администрирование  информационных  систем»,  «050100.62  —  Педагогическое  образование»  (профиль  подготовки  —  математика)/Авт.сост.  Г.Я.  Хусаинова.  Стерлитамак:  Стерлитамакский  филиал  БашГУ,  2013.  —  68  с.

3.Дейт  К.Дж.  Введение  в  системы  базы  данных,  8-е  издание.:  Пер.  с  анг.  М.:  Издательский  дом  «Вильяме»,  2005.  —  1328  с.