Правила трехзначной логики

Таблица истинности оператора and

and	true	false	Null
true	true	false	Null
false	false	false	False
null	null	false	Null

Таблица истинности оператора or

or	true	false	Null
true	true	true	True
false	true	false	Null
null	true	null	Null

Таблица истинности оператора not.

not	true	false	Null
	false	true	Null

Лекция 4. Нормализация таблиц реляционных баз данных

1. Принципы нормализации.

2. Нормальные формы

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

4.1 Принципы нормализации

1. Принцип одноразового ввода и безъизбыточного хранения данных.

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

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

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

2. Принцип атомарности (неделимости) всех полей базы данных.

Каждое поле должно включать только один реквизит, не делимый на поля самостоятельных реквизитов.

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

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

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

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

3. Принцип отсутствия повторяющихся групп полей.

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

4. Принцип зависимости всех неключевых полей от первичного ключа.

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

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

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

6. Принцип отсутствия в таблицах вычисляемых полей.

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

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

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

Практическое применение принципов нормализации.

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

Журнал поставок

№№ пп	Наименование поставщика	Город	Поставка продукции вида							Сумма поставки
			I		II		III
			кол-во	цена	к	ц	к	ц

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

Виды продукции
Код вида продукции	…	…

В таблице “Поставки” поля “Количество” и “Цена” будут в единственном числе.

Поставки
…	Количества	Цена	…

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

В таблице не соблюден принцип одноразового ввода и хранения информации и одновременно не соблюдается принцип независимости неключевых полей между собой. Несоблюдение этих принципов вызвано следующими особенностями структуры таблицы: для каждой поставки указываются наименование поставщика, город и банковские реквизиты; атрибуты “Город” и “Банковские реквизиты” функционально зависят от наименование поставщика. Чтобы рассматриваемые принципы нормализации были соблюдены, исходную таблицу нужно разбить на две: “Поставщики” и “Поставки” (рис. 4.1.1).

Рис. 4.1.1 Схема структуры предметной области Поставки

В таблице «Журнал поставок» соблюден только принцип зависимости всех неключевых полей от первичного ключа.

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