См. также
- База данных
- Нормальная форма Бойса—Кодда (BCNF) — модификация третьей нормальной формы.
- Суперключ
Нормальные формы
Первая нормальная форма • Вторая нормальная форма • Третья нормальная форма • Нормальная форма Бойса — КоддаЧетвёртая нормальная форма • Пятая нормальная форма • Доменно-ключевая нормальная форма • Шестая нормальная форма
| Файл:Computer template.gif | Это незавершённая статья о программировании. Вы можете помочь проекту, исправив и дополнив её. |
cs:Třetí normální forma
de:Normalisierung (Datenbank)#Dritte_Normalform_.283NF.29
en:Third normal form
es:Tercera forma normal
vi:Dạng chuẩn 3
zh:第三正規化
Определение сущностей
На этом этапе вам необходимо определить сущности, из которых будет состоять база данных.
Сущность — это объект в базе данных, в котором хранятся данные. Сущность может представлять собой нечто вещественное (дом, человек, предмет, место) или абстрактное (банковская операция, отдел компании, маршрут автобуса). В физической модели сущность называется таблицей.
Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).
Обычно базы данных состоят из нескольких основных сущностей, связанных с большим количеством подчиненных сущностей. Основные сущности называются независимыми: они не зависят ни от какой-либо другой сущности. Подчиненные сущности называются зависимыми: для того чтобы существовала одна из них, должна существовать связанная с ней основная таблица.
На диаграммах сущности обычно представляются в виде прямоугольников. Имя сущности указывается внутри прямоугольника:
Любая таблица имеет следующие характеристики:
- в ней нет одинаковых строк;
- все столбцы (атрибуты) в таблице должны иметь разные имена;
- элементы в пределах одной колонки имеют одинаковый тип (строка, число, дата);
- порядок следования строк в таблице может быть произвольным.
На этом этапе вам необходимо выявить все категории информации (сущности), которые будут храниться в базе данных.
Определение третьей нормальной формы
Третья нормальная форма (3NF) — это , используемая в нормализация базы данных. 3NF был первоначально определен Э. Ф. Кодд в 1971 г.
Определение Кодда утверждает, что таблица находится в 3NF тогда и только тогда, когда выполняются оба следующих условия:
- Отношение R (таблица) находится в второй нормальной форме (2NF).
- Каждый непростой атрибут R нетранзитивно зависит от каждого ключа R.
Не -prime атрибут R — это атрибут, который не принадлежит ни одному ключу-кандидату R.A транзитивная зависимость — это функциональная зависимость, в которой X → Z ( X определяет Z) косвенно, в силу X → Y и Y → Z (где Y → X не так).
Было дано определение 3NF, которое эквивалентно определению Кодда, но выражается иначе. Карло Заниоло в 1982 г. Это определение утверждает, что таблица находится в 3NF тогда и только тогда, когда для каждой из ее функциональных зависимостей X → A выполняется хотя бы одно из следующих условий:
- X содержит A (то есть A является подмножество X, что означает, что X → A является тривиальной функциональной зависимостью),
- X — это суперключ,
- для каждого элемента A \ X, t он между A и X, является основным атрибутом (т.е. каждый атрибут в A \ X содержится в некотором ключевом кандидате ).
Определение Заниоло дает четкое представление о разнице между 3NF и более строгая нормальная форма Бойса – Кодда (BCNF). BCNF просто исключает третью альтернативу («Каждый элемент A \ X, установленная разница между A и X, является основным атрибутом»).
«Ничего, кроме ключа»
Аппроксимация определения 3НФ, данного Коддом, параллельная традиционному приносить присягу Билл Кент дал правдивое свидетельство в суде: « неключевой должен содержать факт о ключе, весь ключ и ничего, кроме ключа». Распространенная вариация дополняет это определение присягой: «так помогите мне Codd «.
Требование наличия «ключа» гарантирует, что таблица находится в 1NF; требование, чтобы неключевые атрибуты зависели от «всего ключа», обеспечивает 2NF; дальнейшее требование, чтобы неключевые атрибуты зависели от «ничего, кроме ключа», обеспечивает 3NF. Хотя эта фраза является полезной мнемоникой, тот факт, что в ней упоминается только один ключ, означает, что она определяет некоторые необходимые, но не достаточные условия для удовлетворения 2-й и 3-й нормальных форм. И 2НФ, и 3НФ в равной степени связаны с все возможные ключи таблицы, а не только один ключ.
Крис Дата называет резюме Кента «интуитивно привлекательной характеристикой» 3NF и отмечает, что с небольшой адаптацией оно может служить определением немного более сильного Нормальная форма Бойса – Кодда: «Каждый атрибут должен представлять факт о ключе, весь ключ и ничего, кроме ключа». Версия определения 3NF слабее, чем вариант BCNF Дейта, поскольку первая касается только обеспечения того, чтобы неключевой атрибуты зависят от ключей. Основные атрибуты (которые являются ключами или их частями) вообще не должны быть функционально зависимыми; каждый из них представляет собой факт о ключе в смысле предоставления части или всего ключа. (Это правило применяется только к функционально зависимым атрибутам, так как его применение ко всем атрибутам неявно запрещает составные ключи-кандидаты, поскольку каждая часть любого такого ключа нарушает предложение «весь ключ».)
Пример таблицы 2NF, которая не удовлетворяет требованиям 3NF:
| Турнир | Год | Победитель | Дата рождения победителя |
|---|---|---|---|
| Индиана Invitational | 1998 | Аль Фредриксон | 21 июля 1975 г. |
| Кливленд Опен | 1999 | Боб Альбертсон | 28 сентября 1968 г. |
| Де-Мойн Мастерс | 1999 | Аль Фредриксон | 21 июля 1975 г. |
| Индиана Invitational | 1999 | Чип Мастерсон | 14 марта 1977 г. |
Поскольку каждая строка в таблице должна сообщать нам, кто выиграл конкретный турнир в конкретный год, составной ключ {Tournament, Year} представляет собой минимальный набор атрибутов, гарантирующих уникальную идентификацию строки. То есть {Tournament, Year} — это кандидатный ключ для таблицы.
Нарушение 3NF происходит из-за того, что непервичный атрибут (дата рождения победителя) транзитивно зависит от ключа кандидата {Tournament, Year} через непервичный атрибут Winner. Тот факт, что дата рождения Winner функционально зависит от Winner, делает таблицу уязвимой для логических несоответствий, поскольку ничто не мешает одному и тому же человеку отображаться с разными датами рождения в разных записях.
Чтобы выразить одни и те же факты, не нарушая 3НФ, необходимо разделить таблицу на две части:
|
|
В этих таблицах не могут возникнуть аномалии обновления, потому что, в отличие от ранее, Победитель теперь является кандидатом в ключ во второй таблице, что позволяет использовать только одно значение Даты рождения для каждого Победителя.
Как выполнить нормализацию?
Чтобы привести БД к нормальной форме, необходимо:
1. Объединить имеющиеся данные в группы.
2. Выяснить логические связи между группами. Чтобы обеспечить правильность связей, связываемые поля должны иметь один тип.
Если таблица не нормализована, она может хранить информацию о нескольких сущностях и включать в себя повторяющиеся столбцы, а они, в свою очередь, могут хранить дублируемые значения. Если же нормализована, то каждая таблица хранит информацию лишь об одной сущности.
При нормализации предполагается использование нормальных форм по отношению к структуре имеющихся данных. Есть несколько правил нормализации. Каждое из них носит название «нормальная форма» (НФ). Каждая такая форма, кроме первой, предполагает, что к данным уже применили предыдущую нормальную форму. При выполнении первого правила БД представлено в первой нормальной форме (1НФ), при выполнении трех правил — в третьей нормальной форме (3НФ).
Таких форм (уровней) — семь, однако на практике для большей части приложений вполне достаточно нормализовать БД до третьей нормальной формы (строго говоря, БД и будет считаться нормализованной, когда к ней применяется 3НФ и выше).
Да, обеспечить полное соответствие правилам и спецификациям — задача не всегда выполнимая, ведь для нормализации придется создавать дополнительные таблицы, а это не всегда приемлемо или не находит отклика у клиентов. Но если правила приходится нарушать, надо понимать, что все, связанные с этим проблемы, включая несогласованные зависимости и избыточность, будут учтены, и что это допустимо для приложения, не нарушит его работоспособность.
Пример приведения таблиц базы данных к третьей нормальной форме
Для рассмотрения примера давайте возьмем нашу таблицу с сотрудниками, которую в предыдущем материале мы привели ко второй нормальной форме путем добавления в нее дополнительного атрибута «Табельный номер», который в результате стал первичным ключом.
Таблица сотрудников во второй нормальной форме.
| Табельный номер | ФИО | Должность | Подразделение | Описание подразделения |
| 1 | Иванов И.И. | Программист | Отдел разработки | Разработка и сопровождение приложений и сайтов |
| 2 | Сергеев С.С. | Бухгалтер | Бухгалтерия | Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности |
| 3 | John Smith | Продавец | Отдел реализации | Организация сбыта продукции |
Чтобы определить, находится ли эта таблица в третьей нормальной форме, мы должны проверить все неключевые столбцы, каждый из них должен зависеть только от первичного ключа, и никаким образом к другим неключевым столбцам он не должен относиться.
Однако, в результате проверки мы выясняем, что столбец «Описание подразделения» не зависит напрямую от первичного ключа. Мы это выяснили, когда задали себе один вопрос «Каким образом описание подразделения связано с сотрудником?». И наш ответ звучит следующим образом: «Атрибут описание подразделения содержит детальные сведения того подразделения, в котором работает сотрудник».
Отсюда следует, что столбец «Описание подразделения» не связан на прямую с сотрудником, он связан напрямую со столбцом «Подразделение», который напрямую связан с сотрудником, ведь сотрудник работает в каком-то конкретном подразделении. Это и есть транзитивная зависимость, когда один неключевой столбец связан с первичным ключом через другой неключевой столбец.
Чтобы привести эту таблицу к третьей нормальной форме, мы должны сделать что? Правильно, декомпозицию!
Мы должны эту таблицу разбить на две: в первой хранить сотрудников, а во второй подразделения. А для реализации связи в таблице сотрудников создать ссылку на таблицу подразделений, т.е. добавить внешний ключ.
Таблица сотрудников в третьей нормальной форме.
| Табельный номер | ФИО | Должность | Подразделение |
| 1 | Иванов И.И. | Программист | 1 |
| 2 | Сергеев С.С. | Бухгалтер | 2 |
| 3 | John Smith | Продавец | 3 |
Таблица подразделений в третьей нормальной форме.
| Идентификатор подразделения | Подразделение | Описание подразделения |
| 1 | Отдел разработки | Разработка и сопровождение приложений и сайтов |
| 2 | Бухгалтерия | Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности |
| 3 | Отдел реализации | Организация сбыта продукции |
Таким образом, в наших таблицах отсутствует транзитивная зависимость, и они находятся в третьей нормальной форме.
После того как мы привели таблицы базы данных к третьей нормальной форме, мы можем переходить к приведению таблиц до следующей нормальной формы, в частности до нормальной формы Бойса-Кодда (BCNF). Описание, требования и пример приведения таблиц до нормальной формы Бойса-Кодда мы рассмотрим в следующем материале.
На сегодня это все, надеюсь, материал был Вам полезен, пока!
Нравится348Не нравится11
Нормализация базы данных
Нормализация базы данных – это рекомендации по проектированию.
Преимущества нормализованной базы данных:
- Возможность существенно упростить выборки. Получение данных из базы относительно простыми запросами.
- Целостность данных. Избежание потерь или искажения информации в базе данных.
- Отсутствие избыточности. Данные в таблице не дублируются, что существенно снижает её размер.
- Благоприятные предпосылки к росту базы.
Как привести базу данных к нормальной форме?
Для приведения базы к нормальной форме необходимо выполнить следующие действия:
- Постараться объединить данные в группы.
- Найти логические связи между этими группами данных. Для установки связей связываемые поля должны быть одного типа и таблица формата InnoDB.
Существует 3 нормальные формы базы данных:
- Первая нормальная форма
В одной ячейке одно значение. Исключение тип данных SET
Таблица представляет сущность которая в ней размещена (например клиенты, заказы и т.д.) Причём в каждой таблице имеется уникальное поле (первичный ключ) например id и каждая таблица состоит из наименьшего количества полей.
В примере №1. Представлена не удачная структура таблицы, где в поле languages указано перечисление.
В примере №2 тоже не верная структура таблицы для поля languages.
Правильная структура таблиц для решения данной задачи:
Таблица языков программирования
Таблица связей между пользователями и языками программирования
Вторая нормальная формаДля второй нормальной формы требуется первая нормальная форма.
Поля с не первичным ключом не должны быть зависимы от первичного ключа.
В примере №4 мы видим дублирование некоторых марок автомобилей (Данные избыточны). Требуется сделать разделение на несколько таблиц как в примере №3. На первый взгляд создание новых таблиц кажется более затратным чем реализация в примере №4, но это только до тех пор когда таблица состоит всего из нескольких строк.
Правильная структура таблиц для решения данной задачи:Третья нормальная формаТребуется вторая нормальная форма. Согласно третьей нормальной форме данные не должны храниться в таблице, которые могут быть получены из не ключевых полей.
Таблица цен и цен с НДС
Так как цену с НДС можно получить из поля price, то данную задачу нужно переложить на язык программирования.
28 декабря 2017 /
Типы данных в MySQL
Основные операции SQL
Ilya Web developer
«Всегда пишите код так, будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.» Martin Golding
Нормализация отношений. Шесть нормальных форм +7
- 02.04.15 15:53
•
DevilAngel
•
#254773
•
Хабрахабр
•
•
18339
MySQL, SQL
Рекомендация: подборка платных и бесплатных курсов создания сайтов — https://katalog-kursov.ru/
В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.
Процесс проектирования БД с использование метода НФ является итерационным и заключается в последовательном переводе отношения из 1НФ в НФ более высокого порядка по определенным правилам. Каждая следующая НФ ограничивается определенным типом функциональных зависимостей и устранением соответствующих аномалий при выполнении операций над отношениями БД, а также сохранении свойств предшествующих НФ.
Используемые термины
АтрибутДомен атрибутаКортежОтношениеСхема отношенияПроекцияФункциональная зависимостьНормальная формаМетод нормальных форм (НФ)Цель нормализацииАномалиейАномалии-модификацииАномалии-удаленияАномалии-добавления
| Фирма | Модели |
| BMW | M5, X5M, M1 |
| Nissan | GT-R |
| Фирма | Модели |
| BMW | M5 |
| BMW | X5M |
| BMW | M1 |
| Nissan | GT-R |
Вторая нормальная форма
| Модель | Фирма | Цена | Скидка |
| M5 | BMW | 5500000 | 5% |
| X5M | BMW | 6000000 | 5% |
| M1 | BMW | 2500000 | 5% |
| GT-R | Nissan | 5000000 | 10% |
| Модель | Фирма | Цена |
| M5 | BMW | 5500000 |
| X5M | BMW | 6000000 |
| M1 | BMW | 2500000 |
| GT-R | Nissan | 5000000 |
| Фирма | Скидка |
| BMW | 5% |
| Nissan | 10% |
Третья нормальная форма
| Модель | Магазин | Телефон |
| BMW | Риал-авто | 87-33-98 |
| Audi | Риал-авто | 87-33-98 |
| Nissan | Некст-Авто | 94-54-12 |
Риал-авто
87-33-98
Риал-авто
87-33-98
Некст-Авто
94-54-12
| Модель | Магазин |
| BMW | Риал-авто |
| Audi | Риал-авто |
| Nissan | Некст-Авто |
Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)
| Номер стоянки | Время начала | Время окончания | Тариф |
| 1 | 09:30 | 10:30 | Бережливый |
| 1 | 11:00 | 12:00 | Бережливый |
| 1 | 14:00 | 15:30 | Стандарт |
| 2 | 10:00 | 12:00 | Премиум-В |
| 2 | 12:00 | 14:00 | Премиум-В |
| 2 | 15:00 | 18:00 | Премиум-А |
- «Бережливый»: стоянка 1 для льготников
- «Стандарт»: стоянка 1 для не льготников
- «Премиум-А»: стоянка 2 для льготников
- «Премиум-B»: стоянка 2 для не льготников.
Имеет льготыТарифы
| Тариф | Номер стоянки | Имеет льготы |
| Бережливый | 1 | Да |
| Стандарт | 1 | Нет |
| Премиум-А | 2 | Да |
| Премиум-В | 2 | Нет |
Бронирование
| Тариф | Время начала | Время окончания |
| Бережливый | 09:30 | 10:30 |
| Бережливый | 11:00 | 12:00 |
| Стандарт | 14:00 | 15:30 |
| Премиум-В | 10:00 | 12:00 |
| Премиум-В | 12:00 | 14:00 |
| Премиум-А | 15:00 | 18:00 |
Шестая нормальная форма
Работники
| Таб.№ | Время | Должность | Домашний адрес |
| 6575 | 01-01-2000:10-02-2003 | слесарь | ул.Ленина,10 |
| 6575 | 11-02-2003:15-06-2006 | слесарь | ул.Советская,22 |
| 6575 | 16-06-2006:05-03-2009 | бригадир | ул.Советская,22 |
Должности работников
| Таб.№ | Время | Должность |
| 6575 | 01-01-2000:10-02-2003 | слесарь |
| 6575 | 16-06-2006:05-03-2009 | бригадир |
Домашние адреса работников
| Таб.№ | Время | Домашний адрес |
| 6575 | 01-01-2000:10-02-2003 | ул.Ленина,10 |
| 6575 | 11-02-2003:15-06-2006 | ул.Советская,22 |
Рекомендации
- Кодд, Э. Ф. «Дальнейшая нормализация реляционной модели базы данных», стр. 34.
- Кодд, Э. Ф. «Дальнейшая нормализация реляционной модели базы данных». (Представлено на Courant Computer Science Symposia Series 6, «Системы баз данных», Нью-Йорк, 24–25 мая 1971 г.) Отчет об исследованиях IBM RJ909 (31 августа 1971 г.). Переиздано в Randall J. Rustin (ed.), Системы баз данных: Симпозиумы Куранта по информатике, серия 6. Прентис-Холл, 1972.
- Кодд, стр. 43.
- Кодд, стр. 45–46.
- Заниоло, Карло. «Новая нормальная форма для проектирования схем реляционных баз данных». Транзакции ACM в системах баз данных 7 (3), сентябрь 1982 г.
- Авраам Зильбершатц, Генри Ф. Корт, С. Сударшан, (5-е издание), стр. 276–277.
- Автор книги 1989 года по управлению базами данных благодарит одного из своих студентов за то, что он придумал приложение «Помоги мне, Кодд». Дир, Джордж. Управление базами данных (Скотт, Foresman, 1989), стр. 331.
- Дата, К. Дж. Введение в системы баз данных (7-е изд.) (Addison Wesley, 2000), стр. 379.
Нормализация базы данных и ее формы
Примечание: Во всех статьях текущей категории уроков по SQL используются примеры и задачи, основанные на учебной базе данных.
Приступая к изучению данного материала, рекомендуется ознакомиться с описанием учебной БД.
Материал этой статьи напрямую не относиться к изучению языка SQL, так как имеет отношение к проектированию баз данных (БД), но для общего понимания взаимосвязи хранимой в системе информации она будет полезна.
По поводу того, как должна быть спроектирована база нет 100% решения, потому что конкретный вариант может удовлетворять либо не удовлетворять различным бизнес-процессам и целям
Но не принимать во внимание элементарные правила нельзя, так как их соблюдение сохранит много времени, нервов и денег при работе с данными
Нормализация баз данных заключается в приведении структуры хранения данных к нормальным формам (NF). Всего таких форм существует 8, но часто достаточным является соблюдение первых трех. Рассмотрим их более подробно на примере учебной базы данных. Примеры будут строится по принципу «что было бы, если было иначе, чем сейчас».
Первая нормальная форма
Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.
Рассмотрим таблицы сотрудников и телефонных линий.
Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:
Но подобная структура не является надежной. Представьте, что Вам необходимо поменять некоторым сотрудникам подключенные линии. Потребуется осуществить разбор составного поля, чтобы определить наличие id сотрудника в каждой записи линий, затем скорректировать перечень. Получается слишком сложный и долгий процесс для такой простой операции.
Организации структуры таблиц с применением дополнительной связывающей избавляет от подобных проблем.
Помимо атомарности к первой нормальной форме относятся следующие правила:
- Строки таблиц не должны зависеть друг от друга, т.е. первая запись не должна влиять на вторую и наоборот, вторая на третью и т.д. Размещение записей в таблице не имеет никакого значения.
- Аналогичная ситуация со столбцами записей. Их порядок не должен влиять на понимание информации.
- Каждая строка должна быть уникальна, поэтому для нее определяется первичный ключ, состоящий из одного либо нескольких полей (составной ключ). Первичный ключ не может повторяться в пределах таблицы и служит идентификатором записи.
Вторая нормальная форма
Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.
Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.
На представленной диаграмме столбцы описания и приоритета зависят от столбца «Линия», входящего в составной ключ. Это значит, что для каждой линии, подключенной разным сотрудникам, потребуется повторно указывать описание и приоритетность. Подобная структура приводит к избыточности данных.
Также велика вероятность возникновения противоречивой информации. Изменяя приоритет или описание для линии, можно по ошибке оставить некоторые строки не обработанными. В таком случае, для одного и того же идентификатора линии значения зависимых полей будут различными.
Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.
Третья нормальная форма
3NF схожа по логике с 2NF, но с некоторым отличием. Если 2 форма ликвидирует зависимости неключевых полей от части ключа, то третья нормальная форма исключает зависимость неключевых полей от других неключевых полей.
На приведенном примере таблицы сотрудников видно, что столбец «Супервайзер» имеет зависимость от столбца «Группа», а это значит, что при изменении значения поля группы, потребуется изменить значение поля супервайзера.
Все риски, которые были рассмотрены для 2NF, так же относятся к 3NF и устраняются переносом зависимых полей в отдельную таблицу.
Денормализация базы данных
Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.
Для баз данных, предназначенных для аналитики, часто выполняют денормализацию, чтобы укорить выполнение запросов.
Проектирование базы данных (7) Третья нормальная форма (3NF)
http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>style=»clear:both;»>
In our last tutorial, we learned about the second normal form and even normalized our Score table into the 2nd Normal Form.
So let’s use the same example, where we have 3 tables, Student, Subject and Score.
Score Table
In the Score table, we need to store some more information, which is the exam name and total marks, so let’s add 2 more columns to the Score table.
Requirements for Third Normal Form
For a table to be in the third normal form,
- It should be in the Second Normal form.
- And it should not have Transitive Dependency.
What is Transitive Dependency?
With and added to our Score table, it saves more data now. Primary key for our Score table is a composite key, which means it’s made up of two attributes or columns → student_id + subject_id.
Our new column depends on both student and subject. For example, a mechanical engineering student will have Workshop exam but a computer science student won’t. And for some subjects you have Prctical exams and for some you don’t. So we can say that is dependent on both and .
And what about our second new column ? Does it depend on our Score table’s primary key?
Well, the column depends on as with exam type the total score changes. For example, practicals are of less marks while theory exams are of more marks.
But, is just another column in the score table. It is not a primary key or even a part of the primary key, and depends on it.
This is Transitive Dependency. When a non-prime attribute depends on other non-prime attributes rather than depending upon the prime attributes or primary key.
How to remove Transitive Dependency?
Again the solution is very simple. Take out the columns and from Score table and put them in an Exam table and use the wherever required.
The new Exam table
Advantage of removing Transtive Dependency
The advantage of removing transtive dependency is,
- Amount of data duplication is reduced.
- Data integrity achieved.
Интеллектуальная рекомендация
1. Введение 1.1 Определение CSS (лист стиля каскадного стиля) слои слоев слоев, это язык, используемый для украшения страницы и макета страницы управления. Нет визуализации CSS Используйте визуализаци…
O (1) Время удалить указанный узел связанного списка (с полной программой) Обычно удаляют узел в связанном списке только путем перехода к удаляемому узлу, а затем удаляют его. Тогда временная сложност…
Когда набор или массив, который необходимо сортировать, является не просто цифровым типом, обычно можно использовать компаратор или сопоставимый для достижения сортировки объекта или пользовательской …
О VPN и построении VPN VPN: функция виртуальной частной сети заключается в создании частной сети в общедоступной сети и использовании ее для зашифрованной связи. Он широко используется в корпоративных…
Пример использования TOWDown True, впервые пройденный верхний каталог, в противном случае подкаталог верхней части (по умолчанию открыт) является предпочтительным. …
Вам также может понравиться
Разница между скрарию и скрарию-рулизом Scrapy-это универсальная рамка Crawler, но не поддерживает распределенные формулы. Scrapy-Redis-это более удобное достижение распределенного скалолазания скраск…
Любой, у кого есть небольшой опыт программирования JS, знает, что функции в JS не будут сообщать об ошибках, даже если параметры отсутствуют, например addВ функцию не передаются параметры, но она може…
Код: Двумерные массивы, использующие двойной цикл for для решения, горизонтальное отражение с помощью reverse (), реверс с помощью a =!…
…
Разные или операции (⊕ ⊕ или расчет) определение: 1 ⊕ 1 = 0 0 ⊕ 0 = 0 1 ⊕ 0 = 1 0 ⊕ 1 = 1 Основная формула: Этическая скорость: x⊕0 = x Нулевая скорость…
2НФ – вторая нормальная форма
Вторая нормальная форма (2НФ) означает, что выполнены требования 1НФ, при этом все атрибуты целиком зависят от составного ключа и не зависят ни от какой его части.
На первый взгляд кажется, что нарушения 2НФ практически невозможны, потому что чаще всего в качестве первичных ключей используются автоинкрементные целочисленные значения или иные суррогаты для реализации ссылок. Однако, в определении говорится о ключах вообще, а не только о первичных. В отношении может быть несколько ключей, и некоторые из них могут являться составными. Такие ключи следует подвергнуть проверке в первую очередь.
Ассоциативная таблица — таблица, имеющая ключевые связи с двумя и более таблицами
Например, если каждая операция сбыта мебельной продукции в таблице продаж однозначно характеризуется колонками идентификатора товарной позиции, даты продажи и идентификатором покупателя, то нахождение в той же таблице столбца «Тип материала», зависящего непосредственно от товарной позиции, должно немедленно привлечь ваше внимание. Аномалия в данном случае приведёт только к избыточности хранения в виде размера идентификатора, помноженного на число строк таблицы (без учёта индексов)
Но если в той же таблице обнаружится ещё и колонка «Контактный телефон», присущая атрибутике покупателя, то последствия окажутся более серьёзными. Кроме избыточности хранения при ошибке ввода придётся исправлять номер телефона во всех записях о продажах данному покупателю
Аномалия в данном случае приведёт только к избыточности хранения в виде размера идентификатора, помноженного на число строк таблицы (без учёта индексов). Но если в той же таблице обнаружится ещё и колонка «Контактный телефон», присущая атрибутике покупателя, то последствия окажутся более серьёзными. Кроме избыточности хранения при ошибке ввода придётся исправлять номер телефона во всех записях о продажах данному покупателю.
Кроме приведённых примеров, при наличии в таблицах нескольких ключей необходимо, с позиций логики предметной области, определить, являются ли эти ключи присущими данной сущности или же они суть внешние ключи другой сущности, пока ещё не выделенной в процессе проектирования.
Третья нормальная форма
Значения, входящие в запись и не являющиеся частью ключа этой записи, не принадлежат таблице. Если содержимое группы полей может относиться более чем к одной записи в таблице, попробуйте поместить эти поля в отдельную таблицу.
Например, в таблицу Employee Recruitment (наем сотрудников) можно включить адрес кандидата и название университета, в котором он получил образование. Однако для организации групповой почтовой рассылки необходим полный список университетов. Если сведения об университетах будут храниться в таблице Candidates, составить список университетов при отсутствии кандидатов не получится. Таким образом, создайте вместо этого отдельную таблицу Universities и свяжите ее с таблицей Candidates при помощи ключа — кода университета.
ИСКЛЮЧЕНИЕ: выполнять нормализацию баз данных до третьей нормальной формы теоретически желательно, но не всегда практично. Например, для устранения всех возможных зависимостей между полями таблицы Customers придется создать отдельные таблицы для хранения сведений о городах, почтовых индексах, торговых представителях, категориях клиентов и любых других сведений, которые могут дублироваться в нескольких записях. С теоретической точки зрения нормализация желательна. Однако значительное увеличение числа маленьких таблиц может привести к снижению производительности СУБД или исчерпанию памяти и числа дескрипторов открытых файлов.
Выполнять нормализацию до третьей нормальной формы может быть целесообразно только для часто изменяемых данных. Если при этом сохранятся зависимые поля, спроектируйте приложение так, чтобы при изменении одного из этих полей пользователь должен был проверить все связанные поля.
Ключи
Ключом (key) называется набор атрибутов, однозначно определяющий запись. Ключи делятся на два класса: простые и составные.
Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с одинаковым номером.
Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан страны» может быть составной ключ со следующими атрибутами:
фамилия, имя, отчество, дата рождения. Это — как пример, т. к. этот составной ключ, теоретически, не обеспечивает гарантированной уникальности записи.
Также существует несколько типов ключей, о которых рассказано далее.
Возможный ключ
Возможный ключ представляет собой любой набор атрибутов, однозначно идентифицирующих запись в таблице. Возможный ключ может быть простым или составным.
Каждая сущность должна иметь, по крайней мере, один возможный ключ, хотя таких ключей может быть и несколько. Ни один из атрибутов первичного ключа не может принимать неопределенное (NULL) значение.
Возможный ключ называется также суррогатным.
Первичные ключи
Первичным ключом называется совокупность атрибутов, однозначно идентифицирующих запись в таблице (сущности). Один из возможных ключей становится первичным ключом. На диаграммах первичные ключи часто изображаются выше основного списка атрибутов или выделяются специальными символами. Сущность на рисунке имеет как ключевые, так и обычные атрибуты.
Альтернативные ключи
Любой возможный ключ, не являющийся первичным, называется альтернативным ключом. Сущность может иметь несколько альтернативных ключей.
Внешние ключи
Внешним ключом называется совокупность атрибутов, ссылающихся на первичный или альтернативный ключ другой сущности. Если внешний ключ не связан с первичной сущностью, то он может содержать только неопределенные значения. Если при этом ключ является составным, то все атрибуты внешнего ключа должны быть неопределенными.
На диаграммах атрибуты, объединяемые во внешние ключи, обозначаются специальными символами. На рисунке изображены две связанные сущности (Дома и их Хозяева) и образованные ими внешние ключи (ведь один человек может владеть больше, чем одним домом).
Ключи являются логическими конструкциями, а не физическими объектами. В реляционных базах данных предусмотрены механизмы, обеспечивающие сохранение ключей.
Заключение
Продолжать заниматься нормализацией можно и дальше: существуют 4NF, 5NF и DKNF (Domain Key Normal Form). Использование четырех уровней нормализации, рассмотренных в этой статье, является вполне достаточным в большинстве случаев проектирования баз данных. Таблицы могут быть нормализованы и до более высоких типов, но на практике это бывает не всегда возможно. Недостатком при стремлении к более высоким уровням нормализации является то, что таблицы могут быть разложены на более меньшие, чтобы отразить все возможные зависимости.
В результате получается, что даже для простого поиска по базе данных, требуется делать множество операций объединения таблиц. Это является слишком «дорогостоящей» процедурой и приводит к снижению производительности. Тем не менее, использовать четыре уровня нормализации баз данных, описанные в этой статье, не только желательно, но и необходимо в большинстве случаев.
Источник статьи — Источник статьи — http://www.developer.com/db/understanding-database-normalization.html
