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

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

Рубрика Программирование, компьютеры и кибернетика
Вид контрольная работа
Язык русский
Дата добавления 25.12.2013
Размер файла 23,7 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://allbest.ru

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра технологии геологической разведки

Самостоятельная работа №2

Основные нормальные формы таблиц БД

Выполнил студент группы ГИС-09-1:

Солобутов В.А.

Проверил: Попова М.А.

Иркутск 2013г

Оглавление

Введение

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

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

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

Нормальная форма Бойса - Кодда (BCNF)

Четвертая нормальная форма (4NF)

Пятая нормальная форма (5NF)

Доменно - ключевая нормальная форма (DKNF)

Шестая нормальная форма (6NF)

Введение

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

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

· исключение некоторых типов избыточности;

· устранение некоторых аномалий обновления;

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

· упрощение процедуры применения необходимых ограничений целостности.

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

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

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

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

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

Код сотрудника

ФИО

Должность

Проекты

1

Иванов Иван Иванович

Программист

· ID: 123; Название: Система управления паровым котлом; Дата сдачи: 30.09.2011

· ID: 231; Название: ПС для контроля и оповещения о превышениях ПДК различных газов в помещении; Дата сдачи: 30.11.2011

· ID: 321; Название: Модуль распознавания лиц для защитной системы; Дата сдачи: 01.12.2011

Легко заметить, что не все атрибуты этого отношения атомарны (неделимы). В частности, атрибут «Проекты» можно разделить на три более простых атрибута: «Код проекта», «Название», «Дата сдачи», а значение этого атрибута для сотрудника Иван Иванович Иванов содержит несколько кортежей -- информацию о трёх проектах. Примечание: с некоторой точки зрения атрибут «ФИО» можно также считать неатомарным и в таком случае его также следует разделить на более простые, как «Фамилия», «Имя», «Отчество». Теперь настало время рассмотреть алгоритм нормализации отношения до 1НФ.

1. Создать новое отношение, схема которого будет получена путём слияния основной и подчинённой схем исходного отношения в одну.

2. Для каждого кортежа исходного отношения включить в новое столько строк, сколько кортежей содержится в подчинённом отношении этого кортежа.

3. Заполнить значения атрибутов нового отношения, соответствующих атрибутам подчинённого отношения.

4. Заполнить строки нового отношения значениями атомарных атрибутов исходного.

Применим этот алгоритм к приведённому выше отношению. Схема нового отношения будет состоять из 6 атрибутов: «Код сотрудника», «ФИО», «Должность», «Код проекта», «Название», «Дата сдачи». Для одного единственного кортежа заданного отношения, добавим в новое три строки, по одной для каждого проекта (по количеству кортежей в подчинённом отношении). Теперь можно заполнить значения разделённых атрибутов кортежами из подчинённого отношения. Затем перенесём в каждую из этих строк значения атомарных атрибутов: «Код сотрудника», «ФИО», «Должность» (как Вы уже догадались, все три строки будут содержать одинаковые значения этих атрибутов). Результат будет выглядеть так:

Код сотрудника

ФИО

Должность

Код проекта

Название

1

Иванов Иван Иванович

Программист

123

Система управления паровым котлом

1

Иванов Иван Иванович

Программист

231

ПС для контроля и оповещения о превышениях ПДК различных газов в помещении

1

Иванов Иван Иванович

Программист

321

Модуль распознавания лиц для защитной системы

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

нормализация избыточность модель

Ясно, что отношение, находящееся в 1НФ, также может обладать избыточностью. Для её устранения предназначена вторая нормальная форма. Но прежде чем приступить к её описанию, сначала следует выявить недостатки первой. Пусть исходное отношение содержит информацию о поставке некоторых товаров и их поставщиках.

Код поставщика

Город

Статус города

Код товара

Количество

1

Москва

20

1

300

1

Москва

20

2

400

1

Москва

20

3

100

2

Ярославль

10

4

200

3

Ставрополь

30

5

300

3

Ставрополь

30

6

400

4

Псков

15

7

100

Заранее известно, что в этом отношении содержатся следующие функциональные зависимости: { {Код поставщика, Код товара} -> { Количество},

{Код поставщика} -> {Город},

{Код поставщика} -> {Статус},

{Город} -> {Статус} }

Первичный ключ в отношении: {Код поставщика, Код товара}. Очевидно, что отношение обладает избыточностью: оно описывает две сущности -- поставку и поставщика. В связи с этим возникают следующие аномалии:

· Аномалия вставки. В отношение нельзя добавить информацию о поставщике, который ещё не поставил ни одного товара.

· Аномалия удаления. Если от поставщика была только одна поставка, то при удалении информации о ней будет удалена и вся информация о поставщике.

· Аномалия обновления. Если необходимо изменить какую-либо информацию о поставщике (например, поставщик переехал в другой город), то придётся изменять значения атрибутов во всех записях о поставках от него.

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

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

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

В итоге будут получены два отношения:

Код поставщика

Код товара

Количество

1

1

300

1

2

400

1

3

100

2

4

200

3

5

300

3

6

400

4

7

100

Первому отношению теперь соответствуют следующие функциональные зависимости: {Код поставщика, Код товара} -> {Количество}

Код поставщика

Город

Статус города

1

Москва

20

2

Ярославль

10

3

Ставрополь

30

4

Псков

15

Второму отношению соответствуют: { {Код поставщика} -> {Город}, {Код поставщика} -> {Статус}, {Город} -> {Статус} } Такое разбиение устранило аномалии, описанные выше: можно добавить информацию о поставщике, который ещё не поставлял товар, удалить информацию о поставке без удаления информации о поставщике, а также легко обновить информацию в случае если поставщик переехал в другой город. Теперь можно сформулировать определение второй нормальной формы, до которого, скорее всего, читатель уже смог догадаться самостоятельно: отношение находится во второй нормальной форме (сокращённо 2НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его не ключевой атрибут неприводимо зависим от первичного ключа.

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

Основные критерии:

§ Таблица находится во второй нормальной форме.

§ Любой её не ключевой атрибут функционально зависит только от первичного ключа.

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

Рассмотрим в качестве примера следующее отношение:

R1

Марка автомобиля

Тип кузова

Количество дверей

Toyota Ipsum

Универсал

5

Toyota Mark II

Седан

4

Toyota Isis

Универсал

5

В отношении атрибут «Марка автомобиля» является первичным ключом. Количество дверей зависит от типа кузова.

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

Зависимость Марка автомобиля > Количество дверей является транзитивной, следовательно, отношение не находится в 3NF.

В результате декомпозиции отношения R1 получаются два отношения, находящиеся в 3NF

R2

R3

Тип кузова

Количество дверей

Марка автомобиля

Тип кузова

Универсал

5

Toyota Ipsum

Универсал

3Седан

4

Toyota Mark II

Седан

Toyota Isis

Универсал

Исходное отношение R1 при необходимости легко получается в результате операции соединения отношений R2 и R3.

Нормальная форма Бойса-Кодда (BCNF)

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

Четвертая нормальная форма (4NF)

Таблица находится в 4NF, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей.

Пятая нормальная форма (5NF)

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

Доменно-ключевая нормальная форма (DKNF)

Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения.

Ограничение домена - ограничение, предписывающее использовать для определённого атрибута значения только из некоторого заданного домена. Ограничение по своей сути является заданием перечня (или логического эквивалента перечня) допустимых значений типа и объявлением о том, что указанный атрибут имеет данный тип.

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

Любая переменная отношения, находящаяся в ДКНФ, обязательно находится в 5НФ. Однако не любую переменную отношения можно привести к ДКНФ.

Шестая нормальная форма (6NF)

Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.

Размещено на Allbest.ru


Подобные документы

  • Понятие нормализации таблиц базы данных и ее цели. Этапы процесса нормализации. Пример ненормализованных данных. Нормальные формы, к которым приводятся таблицы. Реляционная алгебра над учебной базой. База данных для предметной области "Учебные пособия".

    контрольная работа [216,1 K], добавлен 30.07.2010

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

    реферат [25,5 K], добавлен 30.11.2014

  • Использование нормализации. Вторая и третья нормальные формы. Нормальная форма Бойса-Кодда. Четвертая и пятая нормальная форма. Семантическое моделирование данных, ER-диаграммы. Основные понятия модели Entity-Relationship.

    контрольная работа [43,0 K], добавлен 07.08.2007

  • Понятие базы данных в Microsoft Access, описание таблицы как объекта. Назначение запросов, форм, отчетов и страниц. Макросы и модули в СУБД. Порядок создания базы данных, ввод описания поля. Свойства полей таблиц. Построение реляционной модели данных.

    презентация [389,6 K], добавлен 18.01.2014

  • Построение инфологической модели данных каталога магазина цифровых дисков. Окно создания новых файлов. Типы данных в Visual FoxPro. Список типов индекса. Структура таблиц, связи между ними. Настройка внешнего вида формы. Выбор поля для сортировки данных.

    курсовая работа [4,3 M], добавлен 24.09.2013

  • Построение концептуальной модели. Проектирование реляционной модели данных на основе принципов нормализации: процесс нормализации и глоссарий. Проектирование базы данных в Microsoft Access: построение таблиц, создание запросов в том числе SQL – запросов.

    курсовая работа [35,9 K], добавлен 08.11.2008

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

    курсовая работа [4,9 M], добавлен 26.07.2013

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

    курсовая работа [981,4 K], добавлен 05.11.2011

  • Структура простейшей базы данных и свойства полей. Характеристика типов данных. Описание процесса создания базы данных, таблиц и связей между ними, простых и составных форм, запросов в Microsoft Access. Пример составления подчинённых отчетов и макросов.

    курсовая работа [2,9 M], добавлен 14.11.2016

  • Понятие реляционной модели данных, целостность ее сущности и ссылок. Основные этапы создания базы данных, связывание таблиц на схеме данных. Проектирование базы данных книжного каталога "Books" с помощью СУБД Microsoft Access и языка запросов SQL.

    курсовая работа [838,9 K], добавлен 25.11.2010

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.